Когда обслуживание сервера должно влиять на решения по внедрению? - PullRequest
Новая
       17

Когда обслуживание сервера должно влиять на решения по внедрению?

6 голосов
/ 23 апреля 2009

Вот моя ситуация ...

Я пишу систему безопасности .Net / C # (авторизация и аутентификация) для большой коллекции веб-приложений, требующих единой регистрации. Я использую Active Directory в качестве хранилища данных и написал очень хороший прототип, который взаимодействует с AD через LDAP. Этот компонент извлекает информацию о зарегистрированном пользователе, которую я сохранил в AD, и затем использую ее для установки их ролей безопасности при проверке подлинности на основе форм .Net.

1) Все хорошо.

Не будучи системным администратором или сетевым инженером, я не был знаком с объемом системного администрирования, связанным с настройкой экземпляра AD. Я не знал, что для каждого домена мне нужен отдельный сервер и контроллер домена. Оказывается, что моей команде нужно настроить 9 разных доменов для всех разных сред, к которым мы собираемся обращаться в AD ...

  • env1.dev.mycompany.com
  • env1.qa.mycompany.com
  • env1.stage.mycompany.com
  • env2.dev.mycompany.com
  • и т.д.

... Так что теперь я наложил на себя административную головную боль, потому что мне придется обслуживать все эти машины (или виртуальные машины), что я не обязательно уверен, что хочу делаем.

2) Все не хорошо.

Прототип действительно солидный, и AD делает его очень хорошей базой данных для решения, но теперь мне интересно, стоит ли мне отказаться от кода и написать провайдер данных SQL Server (я знаю, что .Net уже предоставляет такой, но это не соответствует моим бизнес-требованиям для авторизации).

В любом случае, поэтому я пытаюсь обдумать эту проблему с точки зрения высокого уровня. В общем, я продолжаю сомневаться в том, что я бы выбрал действительно хорошее решение только из-за некоторого обслуживания сервера? Мне интересно, сталкивался ли кто-нибудь здесь со сценарием, подобным этому, и что именно вы решили сделать.

Не должен быть специфичным и для AD, просто ситуация, в которой вы должны были оценить между хорошим программным решением и его ограничениями на обслуживание сервера.

Ответы [ 4 ]

4 голосов
/ 23 апреля 2009

В целом, удобство использования продукта - это то, что заставляет людей выбирать между ним и аналогичными продуктами. Если продукт имеет плохое юзабилити, пользователям будет все равно, насколько качественно его код - все, что для него важно, это то, насколько легко и эффективно его использовать и насколько хорошо он отвечает их потребностям.

Техническое обслуживание можно рассматривать как один из аспектов удобства использования. Я бы сделал приоритетом иметь легко обслуживаемый продукт. В долгосрочной перспективе это сэкономит много часов работы администраторов.

Один из способов подумать об этом - сначала спроектировать наиболее подходящее решение с точки зрения конечного пользователя / администратора, а затем создать интеллектуальную задачу для реализации этого оптимального решения. Вероятно, это потребует больше усилий от программиста, но конечный результат будет лучше.

Например, ZFS - это один продукт, в котором об обслуживании заботятся хорошо (хотя я не использовал его лично). Когда он разрабатывался, было приложено немало усилий, чтобы упростить администрирование файловой системы с помощью инструментов командной строки ZFS - и эти проектные решения влияют на все уровни ZFS (например, пулы хранения).

В качестве другого примера, я недавно планировал, как выполнить обслуживание в моем будущем проекте - распределенной базе данных и сервере приложений. Размышления о том, как будут выполняться типичные задачи администрирования (установка / обновление приложений, добавление / удаление серверов в кластере, устранение аппаратных сбоев и т. Д.), Помогли мне разобраться в некоторых дизайнерских решениях. Некоторые из них достаточно глубоко погружаются в архитектуру системы (например, как приложения и расширения загружаются во время выполнения и как серверы находят другие серверы в кластере).

1 голос
/ 23 апреля 2009

Используйте шаблон провайдера и абстрагируйте свои вызовы источника данных.

Затем вы можете настроить его для использования AD или SQL на лету. 

public abstract SSODataProvider {
     public bool AuthenticateUser(string u, string p);
}

public ADSSODataProvider : SSODataProvider {
    public override AutheticateUser(string u, string p) {
       //do auth here
    }
}

public SQLSSODataProvider : SSODataProvider {
    public override AuthenticateUser(String u, string p) {
      //call DB
    }
}

public static SSODataProvider dataProvider;

if (ConfigurationSettings.AppSettings["SSODataProvider"] == "SQL")
   dataProvider = new SQLSSODataProvider();
else
   dataProvider = new ADSSODataProvider();

....

dataProvider.AuthenticateUser("sss","sss");
1 голос
/ 23 апреля 2009

Почему бы просто не использовать OU вместо отдельных доменов при тестировании? То есть иметь один домен, но указать, что пользователи для определенных версий должны находиться в определенном подразделении внутри этого домена. Что бы вы делали в своих функциях поиска для поиска пользователей, вы бы указали конкретное подразделение в качестве корня поиска вместо корня домена. В каждом подразделении у вас могут быть идентификаторы, которые включают в себя среду для сохранения их уникальности, например, user_env1_dev, user_env2_dev, user_env1_qa, ...

Я часто использую AD для своих приложений и никогда не настраиваю отдельные домены для разработки / тестирования.

1 голос
/ 23 апреля 2009

Если я настраиваю систему единого входа для системы Windows, мне очень нравится использовать AD. В качестве системного администратора. Я стараюсь следовать политике единого источника данных. AD уже хранит большую часть моих данных о пользователях и безопасности Windows. Я бы предпочел иметь все, а не вторую систему.

При настройке сред dev / test / prod я стараюсь, чтобы они максимально соответствовали среде Prod, особенно в той области, над которой работаем (где ведется разработка и т. Д.). Поэтому, если бы я настраивал систему для разработки интерфейса с AD, у меня, вероятно, было бы несколько серверов AD.

Какие опции могли бы упростить админ?

Можете ли вы иметь 1 главный сервер, который вы поддерживаете стандартным образом, и использовать что-то вроде процесса копирования VMware для поддержки всех или большинства других? Вместо того, чтобы что-то делать с 9 серверами, оставьте остальные 8 в качестве копий этого зеркала мастера, за исключением изменений, внесенных для поддержки dev / test?

Можно ли запустить несколько доменов разработки или тестирования с 1 сервера AD?

Можете ли вы сценарий действий?

Можете ли вы уменьшить количество сред, особенно на более высоком конце теста? Например. обеспечить несколько сред разработки и выпусков ролей в одном тестовом?

...