Active directory сайты и службы

Active directory сайты и службы

Область применения. Windows Server 2016, Windows Server 2012 R2, Windows Server 2012 Applies To: Windows Server 2016, Windows Server 2012 R2, Windows Server 2012

Топология сайта существенно влияет на производительность сети и возможность доступа пользователей к сетевым ресурсам. Your site topology significantly affects the performance of your network and the ability of your users to access network resources. Прежде чем приступить к проектированию топологии сайта, ознакомьтесь с функциями для сайтов в Windows Server 2008, различных сетевых топологий, которые часто используются организациями, роли владельца топологии сайта и некоторых Active Directory репликации. понятия. Before you begin to design your site topology, become familiar with the functions for sites in Windows Server 2008 , the different network topologies that organizations commonly use, the role of the site topology owner, and some Active Directory replication concepts.

Технический блог специалистов ООО"Интерфейс"

  • Главная
  • Active Directory — от теории к практике. Часть 1 — общие вопросы.

Active Directory — от теории к практике. Часть 1 — общие вопросы.

  • Автор: Уваров А.С.
  • 05.05.2012

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

Перед тем как создавать ваш первый контроллер домена необходимо определиться с режимом его работы. Режим работы определяет доступные возможности и зависит от версии применяемой операционной системы. Мы не будем рассматривать все возможные режимы, кроме тех которые имеют актуальность на текущий момент. Таких режимов три: Windows Server 2003, 2008 и 2008 R2.

Режим Windows Server 2003 следует выбирать только тогда, когда в вашей инфраструктуре уже развернуты сервера на данной ОС и планируется использовать один или несколько таких серверов в качестве контроллеров домена. В остальных случаях нужно выбирать режим Windows Server 2008 или 2008 R2 в зависимости от купленных лицензий. Следует помнить, что режим работы домена можно всегда повысить, а вот понизить уже не удастся (разве что восстановив из резервной копии), поэтому подходите к данному вопросу осмотрительно, с учетом возможных расширений, лицензий в филиалах и т.д. и т.п.

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

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

В итоге наша сеть должна принять следующий вид:

Вопреки распространенному мнению, все контроллеры в домене равнозначны, т.е. каждый контроллер содержит полную информацию о всех объектах домена и может обслужить клиентский запрос. Но это не значит, что контроллеры взаимозаменяемы, непонимание этого момента зачастую приводит к отказам AD и простою сети предприятия. Почему так происходит? Самое время вспомнить про роли FSMO.

Читайте также:  Ajax запрос на чистом javascript

Когда мы создаем первый контроллер, то он содержит все доступные роли, а также является глобальным каталогом, с появлением второго контроллера ему передаются роли хозяина инфраструктуры, хозяина RID и эмулятора PDC. Что будет если администратор решил временно вывести из строя сервер DC1, например чтобы почистить от пыли? На первый взгляд ничего страшного, ну перейдет домен в режим "только чтение", но работать то будет. Но мы забыли про глобальный каталог и если в вашей сети развернуты приложения требующие его наличия, например Exchange, то вы узнаете об этом раньше, чем снимете крышку с сервера. Узнаете от недовольных пользователей, да и руководство вряд ли придет в восторг.

Из чего следует вывод: в лесу должно быть не менее двух глобальных каталогов, а лучше всего по одному в каждом домене. Так как у нас домен в лесу один, то оба сервера должны быть глобальными каталогами, это позволит вам без особых проблем вывести любой из серверов на профилактику, временное отсутствие каких либо ролей FSMO не приводит к отказу AD, а лишь делает невозможным создание новых объектов.

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

Проходит время, ваша организация растет и у нее появляется филиал в другом конце города и возникает необходимость включить их сеть в общую инфраструктуру предприятия. На первый взгляд ничего сложного, вы настраиваете канал связи между офисами и размещаете в нем дополнительный контроллер. Все бы хорошо, но есть одно но. Данный сервер вы контролировать не можете, а следовательно не исключен несанкционированный доступ к нему, да и местный админ вызывает у вас сомнения в его квалификации. Как быть в такой ситуации? Для этих целей специально существует особый тип контроллера: контроллер домена доступный только на чтение (RODC), данная функция доступна в режимах работы домена начиная с Windows Server 2008 и выше.

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

Настраиваем в филиале RODC, все работает, вы спокойны, но пользователи начинают жаловаться на долгий вход в систему и счета за трафик в конце месяца показывают превышение. Что происходит? Самое время еще раз вспомнить про равнозначность контроллеров в домене, клиент может направить свой запрос к любому контроллеру домена, даже находящемуся в другом филиале. Примите во внимание медленный и, с большой вероятностью, загруженный канал связи — вот и причина задержек входа.

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

Читайте также:  3D моделирование людей программа

Здесь мы вплотную подошли к понятию сайтов AD, которые не следует путать с интернет сайтами. Сайты Active Directory представляют способ физического деления структуры службы каталогов на области отделенные от других областей медленными и/или нестабильными каналами связи. Сайты создаются на основе подсетей и все клиентские запросы отправляются в первую очередь контроллерам своего сайта, также крайне желательно иметь в каждом сайте свой глобальный каталог. В нашем случае потребуется создать два сайта: AD Site 1 для центрального офиса и AD Site 2 для филиала, точнее один, так как по умолчанию структура AD уже содержит сайт, куда входят все ранее созданные объекты. Теперь рассмотрим как происходит репликация в сети с несколькими сайтами.

Будем считать, что наша организация немного подросла и главный офис содержит целых четыре контроллера домена, репликация между контроллерами одного сайта называется внутрисайтовой и происходит моментально. Топология репликации строится по схеме кольца с условием, чтобы между любыми контроллерами домена было не более трех шагов репликации. Схема кольца сохраняется до 7 контроллеров включительно, каждый контроллер устанавливает связь с двумя ближайшими соседями, при большем числе контроллеров появляются дополнительные связи и общее кольцо как бы превращается в группу наложенных друг на друга колец.

Межсайтовая репликация происходит иначе, в каждом домене автоматически выбирается один из серверов (сервер-плацдарм) который устанавливает связь с аналогичным сервером другого сайта. Репликация по умолчанию происходит раз в 3 часа (180 минут), однако мы можем установить собственное расписание репликации и для экономии трафика все данные передаются в сжатом виде. При наличии в сайте только RODC репликация происходит однонаправленно.

Безусловно, затронутые нами темы весьма глубоки и в данном материале мы только слегка их коснулись, однако это тот необходимый минимум знаний, который нужно иметь перед практическим внедрением Active Directiry в инфраструктуру предприятия. Это позволит избежать глупых ошибок при развертывании и авральных ситуаций при обслуживании и расширении структуры, а каждая из поднятых тем еще будет обсуждаться более подробно.

Управление сайтами и службами.

При размещении леса Active Directory в нескольких отдельных, территориально распределенных сетях, появляется необходимость управления репликацией данных между доменами леса и оптимизацией трафика, создаваемого службами Active Directory. Для этих целей используется консоль управления Active Directory — сайты и службы — в меню Пуск выберите Администрирование -> Active Directory — сайты и службы.

Консоль управления Active Directory — сайты и службы позволяет управлять параметрами сайтов и репликации всего леса доменов Active Directory.

Структура сайтов по умолчанию.

После установки первого контроллера первого домена леса Active Directory автоматически создается новый сайт с именем Default-First-Site. Все контроллеры любых доменов леса после установки автоматически добавляются в этот сайт. После установки первого контроллера домена структура объектов в консоли Active Directory — сайты и службы должна выглядеть следующим образом:

Дерево консоли Active Directory — сайты и службы может содержать две ветви:

  • Sites — здесь сосредоточены объекты, предназначенные для управления сайтами Active Directory и параметрами репликации;
  • Services — здесь сосредоточены объекты, предназначенные для управления параметрами различных служб, использующих Active Directory для хранения данных, либо интегрирующихся в службу каталога, например, Microsoft Exchange Server 2000.

Ветви, которые содержит узел Sites, приведены в таблице.

Ветвь

Описание

Одна или более ветвей, представляющих отдельные сайты, например, Default-First-Site

Каждая такая ветвь описывает отдельный сайт. Содержит в себе объекты Licensing Site Settings , NTDS Site Settings и один и более объектов контроллеров домена, собранных в узле Servers. Объекты этой ветви определяют, какие сайты какие контроллеры доменов содержат. Также они определяют параметры репликации внутри сайта

Читайте также:  44 Телефонный код какой страны снимают деньги

Содержит в себе два контейнера: IP и SMTP . В этих контейнерах сгруппированы объекты, определяющие параметры репликации между отдельными сайтами

Содержит в себе объекты подсетей, определяющих IP-сети, покрываемые сайтами Active Directory. Каждый объект подсети содержит ссылку на единственный объект сайта

Чтобы создать новый сайт, в дереве консоли управления Active Directory — сайты и службы щелкните ветвь Sites правой кнопкой мыши и в контекстном меню выберите Новый сайт. Также можно выбрать ветвь Sites и щелкнуть правой кнопкой мыши пустое место в списке объектов слева.

В появившемся окне введите имя нового сайта (в поле Имя ) и укажите, какой объект межсайтовой связи будет использоваться для связи с новым сайтом (он уже должен быть создан к этому моменту).

При задании имен сайтов следует придерживаться требований к именам DNS, т. к. каждый объект сайта регистрируется в DNS-зоне.

Изменение свойств сайта.

Чтобы просмотреть и изменить свойства сайта, в дереве консоли управления Active Directory — сайты и службы щелкните нужный объект сайта правой кнопкой мыши и в контекстном меню выберите Свойства.
На вкладке Сайт вы можете ввести или изменить произвольное описание сайта. Обычно здесь указывается, какие сети и домены обслуживает сайт.

На вкладке Размещение можно указать данные о том, где размещаются контроллеры доменов, составляющие сайт.

Рекомендуется использовать следующие данные:

  • код страны (если необходимо);
  • код города (если необходимо);
  • название или код офиса, в котором расположены компьютеры;
  • номер этажа и номер помещения.

Вкладки Объект и Безопасность стандартны для всех объектов Active Directory.

На вкладке Групповая политика вы можете управлять групповыми политиками уровня сайта. Работа с ними будет рассмотрена позже.

Изменение параметров лицензирования сайта.

Администратор может убедиться в соблюдении организацией лицензионных соглашений по использованию программных продуктов, входящих в состав Microsoft BackOffice, путем наблюдения за покупками лицензий, их использованием и удалением. Эти сведения о лицензиях собираются на сервере службой учета лицензий Windows Server 2003.

Эта служба, расположенная на каждом сервере сайта, реплицирует сведения о лицензиях в централизованную базу данных на сервере, который называется Сервером лицензий сайта. Администратор сайта или администратор сервера лицензий сайта может использовать программу Лицензирование из папки Пуск -> Администрирование для просмотра истории лицензирования всего сайта, хранящейся на сервере лицензий сайта.

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

Чтобы просмотреть и изменить свойства лицензирования сайта, в дереве консоли управления Active Directory — сайты и службы выберите объект сайта, в списке справа щелкните объект лицензирования Licensing Site Settings правой кнопкой мыши и в контекстном меню выберите Свойства.

На вкладке Лицензированные параметры вы можете указать произвольное описание объекта лицензирования сайта (в поле Описание ) и указать, какой компьютер выполняет функции сервера лицензирования в сайте.

Для изменения сервера лицензирования сайта щелкните кнопку Изменить. В окне выбора укажите нужный сервер. При изменении сервера лицензирования придерживайтесь следующих правил:

  • сервер лицензирования должен работать под управлением Windows 2000 Server или более поздней версии серверной редакции Windows;
  • сервер лицензирования должен быть расположен в том же сайте для оптимизации быстродействия службы лицензирования.

Если при изменении сервера лицензирования вы хотите сохранить историю лицензирования организации, непосредственно перед изменением выполните следующее:

  • остановите Службу учета лицензий на новом сервере лицензирования;
  • скопируйте следующие файлы со старого сервера в те же папки на новом:

Файл

Описание

Содержит историю покупки лицензий для организации

Ссылка на основную публикацию
Adblock detector