Главная > Active Directory > Планирование Active Directory Domain Services. Часть 1

Планирование Active Directory Domain Services. Часть 1

Всем мы знаем о том, что успех внедрения любого приложения в инфраструктуру требует тщательного планирования. Ведь от этого зависит насколько приложение или целая система будут функциональны. Во время планирования стоит всегда учитывать все факторы, которые могут повлиять на работу инфраструктуры, и не стоит забывать о том, что любая система должна быть отказа устойчивой. Если система не будет построена как отказа устойчивая, то в выходе из строя системы последствия могут быть весьма плачевными. Также не стоит забывать и о возможности её масштабирования и при построении системы нужно учитывать то, что со временем потребуется её масштабирование. Исходя из этого, внедрение любой системы должно быть вначале тщательно спланировано и проверено в тестовой среде. Так как, развиваясь, инфраструктура увеличивается в размерах, становиться вопрос о возможности масштабирования, поэтому планируя Active Directory Domain Services необходимо учитывать этот факт.

Когда мы говорим о планировании Active Directory Domain Services, мы должны понять какие существуют важные моменты в планирование Active Directory Domain Services. Не стоит, забывает то, что Active Directory Domain Services одна из самых важных систем в вашей инфраструктуре, так как на неё ложится важная роль аутентификации пользователей и не только. Как любит говорить один из лучших специалистов компании Microsoft Игорь Шаститко о Active Directory Domain Services – «Это наше всё».

Если смотреть на Active Directory Domain Services с точки Microsoft Infrastructure Optimization model, то данная система должна присутствовать на всех уровнях зрелости, начиная со стандартного, а это еще рациональный и динамический уровень зрелости инфраструктуры.

У компании Microsoft существует целый цикл документации, которая помогает специалистам в построении инфраструктуры, один из таких циклов сокращенно называется IPD. В этом цикле рассказывает о планировании базовых сервисов в инфраструктуре. Данная статья основывается на документации из этого цикла.

Давайте рассмотрим, как должно проходить планирование Active Directory Domain Services. Как пример давайте возьмём какую-то придуманную компанию и попытаемся спланировать для неё Active Directory Domain Services.Пускай этой компанией будет некая компания “Pupkin Company”, у которой 5 основных офисов и 11 филиалов. Офисы пускай находятся в Киеве, Львове, Одессе, Москве, Санкт-Петербурге, также по два филиала в каждом из выше перечисленных городов и один в Харькове. В целом численность сотрудников, которые постоянно работают с компьютером в основных офисах 4 тысячи и 500 человек в филиалах.

Теперь давайте приступим непосредственно к планированию. Исходя из документации компании Microsoft касательно планирования Active Directory Domain Services, вначале нам не обходимо определится с количеством лесов. На самом-то деле нам необходимо определится, будем ли мы использовать много лессовую структуру. Есть несколько основных причин использования много лессовой инфраструктуры. Во первых это разница в схемах, как пример слияние двух компаний которые используют свои приложения которым необходима определенная схема, или в разных отделах используют разное программное обеспечение работоспособность которого напрямую зависит от схемы. И как следствие может возникнуть конфликт схем. Одной из причин может быть требование безопасно использования двух лесов, или опять же при слиянии 2 компаний ни одна из компаний не желает передавать управление своей инфраструктурой Active Directory Domain Services ИТ отделу другой компании. Так же существуют примеры использование отдельного леса для разворачивания в нём ресурсов. Для данной ситуации необходимо определится, будет ли компания дальше развивать. Так как при развитии компании база Active Directory Domain Services будет неуклонно расти, а при больших размерах базы её репликация может оказаться большой проблемной. Если компания планирует дальше развиваться и открывать свои представительства в других городах, то стоит задуматься о создании нескольких лесах. Так как мы планируем развиваться и в других городах, и нашей компании не требуется специфические настройки Active Directory Domain Services, и всё устраивает отдел безопасности, мы можем использовать один лес. Но хочу обратить ваше внимание на то, что с самого начало необходимо всё согласовать, начиная от программного обеспечения которое будет использовать Active Directory Domain Services для своих нужд, до отдела безопасности, и только после этого принимать решение о количестве лесов в вашей компании. Также не стоит забывать что много лёссовая инфраструктура требует больше финансовых затрат, как на оборудование, так в прочем и на персонал который будет этим заниматься.

После этого мы должны преступить к шагу, в котором мы будем определиться с количества доменов в нашем лесу или лесах, всё зависит от решения, которое вы приняли на предыдущем шаге. Для любой начинающей компании достаточно будет одного домена, обслуживание такого инфраструктуры Active Directory Domain Services менее затратное, так как не требует покупки дополнительного программного обеспечения и оборудования, но такой вариант не всегда может отвечать требованиям, которые выдвигает бизнес, служба безопасности и т.д. Также используя один домен ресурсы на его управления намного меньше. Но как я уже говорил раньше не всегда подходит однодоменная структура. Обычно необходимость в создании дополнительных доменов связана с проблемами в репликации. Основные проблемы это или большой размер реплицируемых данных и часто меняющиеся атрибуты. Когда мы говорим о репликации данных, необходимо учитывать каналы для обеспечения репликация. Также необходимость в создании нового домена может быть связана с необходимостью использовать разные уровни домов. Иногда потребность много доменной структуре вызвана необходимостью создания автономных подразделений и предоставления для них отдельного подразделения (OU) в домене не достаточно. Некоторые компании создают N+1 доменов. Это связано с тем, что один домен является корневым и используется исключительно для управления инфраструктурой и предоставления некоторых ресурсов. Такое решение бесспорно является более затратным, но помогает достичь более высокого уровня безопасности.

Для нашего примера я бы посоветовал использовать 3 домена, один из них был-бы корневым и в нем находились общие ресурсы, и два по названию стран в которых они находятся. Хотя построить такую структуру не с нуля, требует больших финансовых затрат и является весьма трудоёмкой. В данном случае корневая зона физически должна находиться на основной площадке, но с точки зрения безопасности и построения отказоустойчивости, её желательно реплицировать на другую площадку. В данной ситуации подразумевается, что существует 2 тех площадки, одна в Украине, а другая в России, и наш домен получается размазанным между двумя площадками. Хотя можно обойтись и двумя домена, но в таком случае они будут не равноправными. Что может повлечь за собой нежелательные последствия.

После чего нам необходимо определиться с именами наших доменов в лесу. У домена есть два имени, первое это NetBIOS имя, для преобразования которого используется служба WINS, второе это DNS имя, для преобразования которого и используется служба DNS. Поэтому при планировании, на этом шаге, мы должны руководствоваться исходя из некоторых ограничений и советов. Основным ограничением является длина NetBIOS имени, которое не может превышать 15 символов, и не может включаться в себя следующие символы (\), (/),(:), (*), (?), ("), (<), (>), (|). Также стоит сразу же определиться с именем, и оно должно быть уникальным, чтобы при объединении с другой компанией не начались конфликты имен. По этой причине не стоит давать доменам NetBIOS имена, такие как firma, corp, company. Когда мы говорим о DNS имени нам стоит помнить то, что нам необходимо выбрать уникальное доменное имя, для этого можно пойти двумя путями. Первый путь это купить домен, что является более приемлемым решением. Второй способ это создавать домен в не существующей зоне, как пример это может быть зона local или my, но в этом случае могут возникнуть проблемы, когда мы будем разворачивать свой центр сертификации, и делать публикации сервисов во внешний мир. В целом может быть много таких проблем. Опять же может возникнуть проблема при объединении с другой компанией, если окажется что у вас одинаковое именное пространство. Как показывает практика, очень часто используются имена доменов, такие как firma.local, corp.local, company.local, что является в корне не правильным и указывает на отсутствие планирования Active Directory Domain Services в организации. Когда мы выбираем DNS имя, мы должны помнить что в его имени не могут присутствовать некоторые символы, а именно (,), (~), (:), (!), (@), (#), ($), (%), (^), (&), (‘), (()), ({}), (_)

Для нашего случая я рекомендовал бы сделать выдать следующие DNS имена, корневому домену дать имя pupkin.com. Напомню что из него идет управления другими доменами. И соответственно два других домена назовём Ukraine.pupkin.com и Russia.pupkin.com. Каждый из этих доменов будет являться дочерним доменом pupkin.com. Если мы говорим о NetBIOS именах, но у корневого домен контролера оно будет pupkin, и соответственно Ukraine и Russia у двух других доменов в нашей инфраструктуре.

На этом я хотел бы закончить эту часть статьи. В ней мы рассмотрели основные причины, которые влияют на выбор количества лесов и доменов, а также рассмотрели, как стоит производить наименования доменов в нашей инфраструктуре. Решили, что в нашей гипотетической инфраструктуре будет один лес и 3 домена. В следующей статье я продолжу рассказывать о планировании инфраструктуры Active Directory Domain Services.

Данный материал был подготовлен опираясь на информацию, размешенную на сайте http://www.microsoft.com/ipd и technet.com.

Дополнительный материалы для изучения http://technet2.microsoft.com/windowsserver/en/library/fba18139-1168-4259-82b3-c3b4c81945981033.mspx?mfr=true

http://technet.microsoft.com/ru-ru/library/cc759036(WS.10).aspx

  1. Артем
    Март 9, 2012 в 13:31

    «Решили, что в нашей гипотетической инфраструктуре будет один лес и 3 домена… » мб 1 дерево в которое входят 3 домена? не?

  2. Март 9, 2012 в 14:38

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

  1. No trackbacks yet.

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s

%d такие блоггеры, как: