Когда обслуживание сервера влияет на выполнение описаний внедрения?

Question

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

Я пишу систему безопасности .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, это просто ситуация, когда вам нужно было оценить хорошее программное решение и ограничения обслуживания сервера.

Answer 1

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

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

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

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

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

Answer 2

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

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

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

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

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

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

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

Answer 3

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

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

Answer 4

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

Затем вы можете настроить его для использования 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");