Очень часто бывает так, что есть очевидные, вроде бы, понятия, но, как только начинаешь их с кем-то обсуждать, выясняется, что вы понимаете их совсем по разному. Сегодня я хочу поговорить о таком понятии, как связи между сайтами в доменных службах 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 репликации только со связями в виде стрелочек.
АПД: Последняя диаграмма была изменена после получения ценных замечаний от ildarz в комментариях.
Если вы хотите узнать, почему я считаю такие диаграммы вредными (хотя и признаю их удобство), то добро пожаловать под кат.
В чём же проблема? Дело в том, что такие диаграммы закрепляют очень серьёзный стереотип — связь сайтов связывает два сайта в рамках домена.
Совсем недавно, ко мне обратились за рекомендациями по организации топологии Active Directory домена. У заказчика используется классический вариант звезды, с одним центральным сайтом в основном дата центре и несколькими удалёнными филиалами. У заказчика появилось желание организовать второй основной сайт в той же локации (у хостинга появился второй дата центр в том же городе, соединённый с первым очень хорошим каналом) для повышения надёжности инфраструктуры. Соответственно встал вопрос, как правильно добавить новый сайт в текущую структуру сайтов. После нескольких минут беседы я, с удивлением, понял, что человек вообще не знает, что можно связать несколько сайтов одной и той же связью между сайтами. То есть, если его спросить, то он вспомнит, что в оснастке управления вам дают выбрать список сайтов, входящих в связь, но в его сознании топология домена всегда представлена вот такой диаграммой, где связи это линии соединяющие два сайта.
Я не отрицаю удобство такого представления и факта, что чаще всего большего и не нужно. Просто жаль, что закрепляя такой стереотип, люди лишают себя части возможностей, предоставляемых этим инструментом. Не забывайте, что даже Microsoft в своей статье о репликации в Active Direcotry отмечает, что связь сайтов может включать несколько сайтов, если все они соединены друг с другом одинаково хорошо («all the sites are equally well connected», если будете искать по фразе).
Конкретно в этой истории, используя эту возможность можно было выбрать два варианта организации связей между сайтами, которые обеспечивали принципиально разное поведение системы.
Ключевым вопросом, для понимания того, как правильно организовать структуру сайтов заказчика здесь является следующий — будет ли второй основной сайт stand-by DR локацией, которая должна использоваться только если возникли проблемы с первым или первый и второй основные сайты станут равноправными и должны разделять нагрузку.
В варианте stand-by DR локации нам, действительно, достаточно связей сайтов парами. Всё что нам нужно для того, чтобы добавить новый сайт это связать его только с основным с весом связи меньше чем для любого удалённого сайта (ну и, конечно, выбрать опцию Bridge All Site Links). Таким образом, если в первом основном сайте произойдёт сбой, то для контроллеров во всех удалённых сайтах именно второй основной сайт станет партнёром по репликации и сможет помочь с аутентификацией, если и в удалённом сайте начнутся проблемы.
Однако, заказчик хотел именно равноправные сайты. Он собирался размещать многие сервисы во втором дата центре. В этом случае такой вариант будет не правильным. Чтобы этого достичь, помимо создания новой связи нам нужно изменить каждую из существующих, добавив в неё новый сайт. Линии на диаграмме нам теперь не помогут. Это можно изобразить как-то так.
Согласитесь, такую диаграмму связей в домене вы видите гораздо реже? Что нам дает такой вариант? В целом, примерно то же, что и предыдущий:
- Удалённые филиалы репродуцируются данные через одну из основных локаций
- Если одна из основных локаций станет недоступной, то удалённые филиалы будут использовать другую
Но есть одно важное отличие. При такой организации, контроллеры второго дата центра используются даже тогда, когда первый работает нормально. Это даёт нам два полноценных основных сайта, разделяющих нагрузку между собой и прикрывающих друг друга на случай отказа.
В этой статье нет каких-то откровений. Я думаю, что большинство читателей и так всё это знали. Тем не менее, я уверен, что были и те, кто до сих пор, зная, что оснастка создания связи сайтов позволяет добавить туда больше двух объектов, мысленно рисовали себе диаграммы топологии Active Directory репликации только со связями в виде стрелочек.
АПД: Последняя диаграмма была изменена после получения ценных замечаний от ildarz в комментариях.
Комментарии (20)
osipov_dv
04.04.2016 10:07Не совсем понятна фраза " Нам достаточно добавить новый сайт в каждую из существующих." Что-то пропущено.
Aivendil
04.04.2016 10:10нам вообще не нужны новые связи. Нам достаточно добавить новый сайт в каждую из существующих.
Я думал, очевидно, что "… в каждую из сущесвующих (связей)". Считаете стоит перефразировать?
ildarz
04.04.2016 12:21Ключевым вопросом, для понимания того, как правильно организовать структуру сайтов заказчика здесь является следующий — будет ли второй основной сайт stand-by DR локацией, которая должна использоваться только если возникли проблемы с первым или первый и второй основные сайты станут равноправными и должны разделять нагрузку.
Слово "равноправный" тут не совсем точно. "Равноправными" они будут только в одном смысле — в случае отказа всех КД в одной из локаций, помеченных у вас как "Remote Site X", их нагрузку в равной мере примут КД из Primary и Secondary Site. И есть побочный эффект — если будут недоступны КД в Primary или Secondary, то нагрузка пойдет не только к соседу, но и на Remote Sites.
Если надо (и канал связи позволяет) сделать две локации равноправными в полном смысле этого слова, их надо в один сайт объединять. Чем проще, тем лучше. :)
Вообще связи сайтов — это, по сути, такой уровень абстракции для описания топологии L2/L3 сети. Несколько связей нужны в случаях, когда сеть не является полностью маршрутизируемой, или же разделена на несколько сегментов, связанных медленными и/или дорогими каналами связи.Aivendil
04.04.2016 12:31Возможно "равноправные" — не совсем верное слово. Но более точного у еня придумать не получается. "Равноправные" они в том смысле, что в отличие от первого варианта, где КД второго сайта будут использоваться ТОЛЬКО ЕСЛИ в первом ни один КД не доступен, во втором варианте КД удалённых сайтов моугт и будут постоянно использовать КД из первого и второго основных сайтов. Это довольно существенная разница — запасный КД на случай отказа основных или КД полностью разделяющие нагрузку основных, т.е. по сути тоже основные.
Если откажут КД в Primary и Secondary сайте (т.е. если случится масштабный сбой в обоих основных дата центрах), то вопрос того, куда пойдет нагрузка Active Directory будет далеко не самым важным для заказчика:)
Не всегда есть возможность объединить локации в одие сайт, ведь механизмом сайтов помимо Active Directory среды пользуются и другие приложения.
LoadRunner
04.04.2016 13:13Возможно, под "равноправием" Вы подразумевали master-master или active\active?
Aivendil
04.04.2016 13:16Active Directory всегда master-msater и active\active (ну кроме RODC). Т.е. лаже в варианте, когда конроллеры второго основного сайта не используются контроллерами удалённых сайтов, они всё равно остаются и master и acitve. Так что, так подходит ещё меньше.
ildarz
04.04.2016 13:18+1во втором варианте КД удалённых сайтов моугт и будут постоянно использовать КД из первого и второго основных сайтов.
Я не очень понимаю эту фразу. Зачем они будут их использовать? Варианта только два — роли FSMO и репликация. Первый никак не зависит от топологии. Второй обычно некритичен в плане нагрузки (плюс надо смотреть на реальную топологию сети).
Если откажут КД в Primary и Secondary сайте (т.е. если случится масштабный сбой в обоих основных дата центрах), то вопрос того, куда пойдет нагрузка Active Directory будет далеко не самым важным для заказчика:)
Я не об этом. Я о том, что при подобной топологии не только primary и secondary сайты равноценны для всех удаленных, но и, например, удаленные равноценны с secondary для primary. И, если будет сбой в одном датацентре, то в вашей топологии нагрузка с него уйдет не во второй датацентр (как это было бы в случае наличия между ними отдельной связи с низкой стоимостью), а на все сайты, включая удаленные. Чтобы этого избежать, надо либо объединить их в один сайт, либо, если по каким-то причинам такое нежелательно, всё-таки создать эту отдельную связь в дополнение к остальным.Aivendil
04.04.2016 13:25Зачем они будут их использовать?
Репликация, аутентификация пользователей в случае отказа удалённого сайта. Если ваша сеть достаточно хороша, чтобы все эти моменты вообще не играли роли, то можно её вообще на AD сайты не делить.
всё-таки создать эту отдельную связь в дополнение к остальным.
А вот это очень хорошее дополнение! Спасибо.
LoadRunner
Не исключаю, что мой комментарий глупее некуда, но это выглядит, как простая репликация AD с балансировкой. Разве нет? Просто домены географически разнесены.
Aivendil
Во первых, не домены а сайты. Во вторых, идея в том, что когда обсуждают топологию, почему-то всегда говорят только о связи точек, хотя, на самом деле, связь сайтов это не линия соединяющая две точки между собой, а некое множество точек.
LoadRunner
Ну то есть я прав? Это банальная репликация (с балансировкой), добавляющая отказоустойчивости? То есть, тоже вполне обычное дело при обсуждении топологии.
Или не прав и в статье описано совершенно иное?
Aivendil
Расскажите мне что такое репликация с балансировкой и я отвечу на ваш вопрос.
Статья о том, что добавить отказоустойчивость можно двумя разными способами. Первый из которых — точечные связи, даёт одни преимущества, а второй — связи множеств объектов — другие. И очень жаль, что второй вариант почти нигде и никогда не упоминаются и не все вообще знают, что так тоже можно.
LoadRunner
Ну я репликацию понимаю, как полное дублирование домена\леса\сайта\иного функционала (в зависимости от того, что реплицируем), но физически в другом расположении. А балансировка — это некое распределение нагрузки в определённом соотношении (50\50, 80\20 или ещё какие другие варианты).
А добавление отказоустойчивости я вижу лишь двумя путями: дублирование узлов и повышение качества и надёжности каждого узла.
И при обсуждении топологии в моменте "а вот здесь у нас будет дублированный узел" могут подробную схему дублирования узла заменить лишь на один узел (если обсуждают всю схему, а не сам узел), но зная, что там сложная схема дублирования и распределения нагрузки.
То есть, содержимое статьи я воспринимаю лишь как "никто не рисует подробных схем узлов с репликацией". И в комментарии и уточняю — правильно ли я понял. Если нет, то мне хотелось бы разобраться, где я не прав и в чём ошибаюсь, так как эта тема имеет определённое для меня значение.
Aivendil
Смотрите, вся система сайтов и их связей в Active Directory это инструмент, который вы используете чтобы рассказать доменной службе как физически устроена ваша сеть. Исходя из того, как вы её опишете доменная служба будет строить топологию репликации для разделов данных.
Репликация, по крайней мере в случае Active Directory, это НЕ дублирование домена/леса/сайта в другом физическом расположении. Это синхронизаций данных в распределённой системе. Т.е. в системе, где данные хранятся на большом количестве узлов и каждый из них может эти данные одновременно изменять.
Касательно содержания статьи, дело не в том, что никто не рисует такие схемы. Дело в том, что многие мыслят неправильными категориями. Представляя связь сайтов в виде связи двух точек, мы ограничиваем системы в вариантах автоматического построения сязей между ними. Чувствуете разницу между фразами "Точка А связана с точкой Б, а точка Б связана с точкой В" и "Точки А, Б и В связаны в единое множество"? В первом случае, для точки А есть одна непосредственно связанная с ней и, ещё одна опосредованно. Во втором, все три точки связаны между собой. Это даёт системе больше гибкости при построении репликационных связей в случае отказов отдельных элементов.
Цель этого материала — напомнить людям, что инструмент, которым они пользуются более функционален чем они привыкли.
LoadRunner
Ну синхронизация данных — это всего лишь механизм, позволяющий реплицировать данные. Просто в этом случае репликация двусторонняя.
И такое построение топологии не только в AD, мне ещё DFS сразу на ум приходит.
Но мне кажется сомнительным, что люди забыли. Может просто многие сценарии не так популярны?
Aivendil
Я тоже так думал, пока в беседе с коллегой не обнаружил, что он оказывается и не знал что так можно. Быстрый опрос по нескольким знакомым показал, что большинство из них тоже не знают этого.
LoadRunner
Для меня это звучит странно (я с Вами не спорю, я верю, что есть такие люди), поскольку когда системный администратор в первый раз сталкивается с чем-то новым, то внимательно читает всё, что на экране пишется (или на бумаге). А уж там-то всё это написано, все возможности и области применения. Особенно радуют "Мастеры чего-угодно", когда не через консоль настраиваешь, а в GUI с подробными пояснениями просто выбираешь. Ну а дальше уже в памяти хранится (или забывается — но должно вспоминаться в случае возвращения к настройке таких вещей).
Ничего плохого не хочу сказать о Ваших знакомых, но в чём причина их незнания? Может Вам так просто повезло с кругом знакомых (в плане совпадения причин незнания)?
И тогда уже становится интереснее — если причина одна.
Aivendil
Не переживайте, мне нравится этот диалог!:)
Причина на самом деле простая. Вбейте в гугл "Active Directory сайты диаграма" и найдите хотя бы одну, на которой показана связь включающая больше двух сайтов. Визуальная память — сильная вещь. А если человек один раз когда-то прочитал, что связь может объединять произвольное число сайтов, а потом годами сам использовал только вариант с двумя, то эта информация просто вылетает у него из головы.
LoadRunner
Довольно странное решение — в гугле искать. Точнее, доверяться диаграммам на сторонних сайтах, а не MSDN и Technet. Допускаю, что и на этих ресурсах такие диаграммы есть, но уверен, что они сопровождаются подробным описания сценария использования.
Хотя я вот пытался вспомнить, каким образом я сам узнал все эти вещи…
Сначала я узнал о существовании AD, что это такое и зачем нужно, потом узнал, что можно поднять два DC (по привычке я сокращаю до "домен" как раз Контроллер Домена с ролью AD). Соответственно, когда дошло до того, что самому пришлось организацию с рабочих групп переводить на доменную схему, столкнулся и с тем, как это реализовать и обеспечить хоть какую-нибудь отказоустойчивость. То есть при таком прогрессе знаний сложно упустить момент "а ещё в AD можно сделать так". Точнее, видя, какой прогресс сделан Майкрософтом в серверных операционных системах за эти годы (сравниваю гигантскую пропасть между 2003 и 2012 R2), я часто задаю себе вопрос: "А какие ещё возможности здесь есть, интересно было бы узнать". Ну и я знаю, что в моём случае задача типовая, значит кто-то её уже решал, а значит в серверных продуктах есть полная поддержка большинства сценариев, свойственных организациям различного уровня (от маленьких до гигантских корпораций). Остаётся только выбрать нужный — вот тут изучаются помимо нужного и другие.
И мне кажется, что вот этот самый вопрос — "а как ещё можно решить задачу, какие средства есть для её решения" — помогает не забыть или хотя бы использовать правильный механизм поиска решения.
Видимо, у Ваших знакомых всё было иначе, если возникает вопрос "а что, так можно было?".
P. S. Мне тут предстоит в филиале ещё поднимать домен (там до сих пор рабочие группы, так уж сложилось) и настраивать наследование, поэтому я и начал такой диалог :)