Очень часто бывает так, что есть очевидные, вроде бы, понятия, но, как только начинаешь их с кем-то обсуждать, выясняется, что вы понимаете их совсем по разному. Сегодня я хочу поговорить о таком понятии, как связи между сайтами в доменных службах Active Directory. Посмотрите, пожалуйста, на следующую диаграмму. Вы могли видеть подобные диаграммы для представляющие топологию домена много раз.
Если вы хотите узнать, почему я считаю такие диаграммы вредными (хотя и признаю их удобство), то добро пожаловать под кат.
В чём же проблема? Дело в том, что такие диаграммы закрепляют очень серьёзный стереотип — связь сайтов связывает два сайта в рамках домена.
Совсем недавно, ко мне обратились за рекомендациями по организации топологии Active Directory домена. У заказчика используется классический вариант звезды, с одним центральным сайтом в основном дата центре и несколькими удалёнными филиалами. У заказчика появилось желание организовать второй основной сайт в той же локации (у
Я не отрицаю удобство такого представления и факта, что чаще всего большего и не нужно. Просто жаль, что закрепляя такой стереотип, люди лишают себя части возможностей, предоставляемых этим инструментом. Не забывайте, что даже Microsoft в своей статье о репликации в Active Direcotry отмечает, что связь сайтов может включать несколько сайтов, если все они соединены друг с другом одинаково хорошо («all the sites are equally well connected», если будете искать по фразе).
Конкретно в этой истории, используя эту возможность можно было выбрать два варианта организации связей между сайтами, которые обеспечивали принципиально разное поведение системы.
Ключевым вопросом, для понимания того, как правильно организовать структуру сайтов заказчика здесь является следующий — будет ли второй основной сайт stand-by DR локацией, которая должна использоваться только если возникли проблемы с первым или первый и второй основные сайты станут равноправными и должны разделять нагрузку.
В варианте stand-by DR локации нам, действительно, достаточно связей сайтов парами. Всё что нам нужно для того, чтобы добавить новый сайт это связать его только с основным с весом связи меньше чем для любого удалённого сайта (ну и, конечно, выбрать опцию Bridge All Site Links). Таким образом, если в первом основном сайте произойдёт сбой, то для контроллеров во всех удалённых сайтах именно второй основной сайт станет партнёром по репликации и сможет помочь с аутентификацией, если и в удалённом сайте начнутся проблемы.
Однако, заказчик хотел именно равноправные сайты. Он собирался размещать многие сервисы во втором дата центре. В этом случае такой вариант будет не правильным. На самом деле, в этом случае нам вообще не нужны новые связи. Нам достаточно добавить новый сайт в каждую из существующих. Линии на диаграмме нам теперь не помогут. Это можно изобразить как-то так.
Согласитесь, такую диаграмму связей в домене вы видите гораздо реже? Что нам дает такой вариант? В целом, примерно то же, что и предыдущий:
- Удалённые филиалы репродуцируются данные через одну из основных локаций
- Если одна из основных локаций станет недоступной, то удалённые филиалы будут использовать другую
Но есть одно важное отличие. При такой организации, контроллеры второго дата центра используются даже тогда, когда первый работает нормально. Это даёт нам два полноценных основных сайта, разделяющих нагрузку между собой и прикрывающих друг друга на случай отказа.
В этой статье нет каких-то откровений. Я думаю, что большинство читателей и так всё это знали. Тем не менее, я уверен, что были и те, кто до сих пор, зная, что оснастка создания связи сайтов позволяет добавить туда больше двух объектов, мысленно рисовали себе диаграммы топологии Active Directory репликации только со связями в виде стрелочек.
Автор: Aivendil