Comments 21
Не исключаю, что мой комментарий глупее некуда, но это выглядит, как простая репликация AD с балансировкой. Разве нет? Просто домены географически разнесены.
Во первых, не домены а сайты. Во вторых, идея в том, что когда обсуждают топологию, почему-то всегда говорят только о связи точек, хотя, на самом деле, связь сайтов это не линия соединяющая две точки между собой, а некое множество точек.
Ну то есть я прав? Это банальная репликация (с балансировкой), добавляющая отказоустойчивости? То есть, тоже вполне обычное дело при обсуждении топологии.
Или не прав и в статье описано совершенно иное?
Или не прав и в статье описано совершенно иное?
Расскажите мне что такое репликация с балансировкой и я отвечу на ваш вопрос.
Статья о том, что добавить отказоустойчивость можно двумя разными способами. Первый из которых — точечные связи, даёт одни преимущества, а второй — связи множеств объектов — другие. И очень жаль, что второй вариант почти нигде и никогда не упоминаются и не все вообще знают, что так тоже можно.
Статья о том, что добавить отказоустойчивость можно двумя разными способами. Первый из которых — точечные связи, даёт одни преимущества, а второй — связи множеств объектов — другие. И очень жаль, что второй вариант почти нигде и никогда не упоминаются и не все вообще знают, что так тоже можно.
Ну я репликацию понимаю, как полное дублирование домена\леса\сайта\иного функционала (в зависимости от того, что реплицируем), но физически в другом расположении. А балансировка — это некое распределение нагрузки в определённом соотношении (50\50, 80\20 или ещё какие другие варианты).
А добавление отказоустойчивости я вижу лишь двумя путями: дублирование узлов и повышение качества и надёжности каждого узла.
И при обсуждении топологии в моменте "а вот здесь у нас будет дублированный узел" могут подробную схему дублирования узла заменить лишь на один узел (если обсуждают всю схему, а не сам узел), но зная, что там сложная схема дублирования и распределения нагрузки.
То есть, содержимое статьи я воспринимаю лишь как "никто не рисует подробных схем узлов с репликацией". И в комментарии и уточняю — правильно ли я понял. Если нет, то мне хотелось бы разобраться, где я не прав и в чём ошибаюсь, так как эта тема имеет определённое для меня значение.
А добавление отказоустойчивости я вижу лишь двумя путями: дублирование узлов и повышение качества и надёжности каждого узла.
И при обсуждении топологии в моменте "а вот здесь у нас будет дублированный узел" могут подробную схему дублирования узла заменить лишь на один узел (если обсуждают всю схему, а не сам узел), но зная, что там сложная схема дублирования и распределения нагрузки.
То есть, содержимое статьи я воспринимаю лишь как "никто не рисует подробных схем узлов с репликацией". И в комментарии и уточняю — правильно ли я понял. Если нет, то мне хотелось бы разобраться, где я не прав и в чём ошибаюсь, так как эта тема имеет определённое для меня значение.
Смотрите, вся система сайтов и их связей в Active Directory это инструмент, который вы используете чтобы рассказать доменной службе как физически устроена ваша сеть. Исходя из того, как вы её опишете доменная служба будет строить топологию репликации для разделов данных.
Репликация, по крайней мере в случае Active Directory, это НЕ дублирование домена/леса/сайта в другом физическом расположении. Это синхронизаций данных в распределённой системе. Т.е. в системе, где данные хранятся на большом количестве узлов и каждый из них может эти данные одновременно изменять.
Касательно содержания статьи, дело не в том, что никто не рисует такие схемы. Дело в том, что многие мыслят неправильными категориями. Представляя связь сайтов в виде связи двух точек, мы ограничиваем системы в вариантах автоматического построения сязей между ними. Чувствуете разницу между фразами "Точка А связана с точкой Б, а точка Б связана с точкой В" и "Точки А, Б и В связаны в единое множество"? В первом случае, для точки А есть одна непосредственно связанная с ней и, ещё одна опосредованно. Во втором, все три точки связаны между собой. Это даёт системе больше гибкости при построении репликационных связей в случае отказов отдельных элементов.
Цель этого материала — напомнить людям, что инструмент, которым они пользуются более функционален чем они привыкли.
Репликация, по крайней мере в случае Active Directory, это НЕ дублирование домена/леса/сайта в другом физическом расположении. Это синхронизаций данных в распределённой системе. Т.е. в системе, где данные хранятся на большом количестве узлов и каждый из них может эти данные одновременно изменять.
Касательно содержания статьи, дело не в том, что никто не рисует такие схемы. Дело в том, что многие мыслят неправильными категориями. Представляя связь сайтов в виде связи двух точек, мы ограничиваем системы в вариантах автоматического построения сязей между ними. Чувствуете разницу между фразами "Точка А связана с точкой Б, а точка Б связана с точкой В" и "Точки А, Б и В связаны в единое множество"? В первом случае, для точки А есть одна непосредственно связанная с ней и, ещё одна опосредованно. Во втором, все три точки связаны между собой. Это даёт системе больше гибкости при построении репликационных связей в случае отказов отдельных элементов.
Цель этого материала — напомнить людям, что инструмент, которым они пользуются более функционален чем они привыкли.
Ну синхронизация данных — это всего лишь механизм, позволяющий реплицировать данные. Просто в этом случае репликация двусторонняя.
И такое построение топологии не только в AD, мне ещё DFS сразу на ум приходит.
Но мне кажется сомнительным, что люди забыли. Может просто многие сценарии не так популярны?
И такое построение топологии не только в AD, мне ещё DFS сразу на ум приходит.
Но мне кажется сомнительным, что люди забыли. Может просто многие сценарии не так популярны?
Я тоже так думал, пока в беседе с коллегой не обнаружил, что он оказывается и не знал что так можно. Быстрый опрос по нескольким знакомым показал, что большинство из них тоже не знают этого.
Для меня это звучит странно (я с Вами не спорю, я верю, что есть такие люди), поскольку когда системный администратор в первый раз сталкивается с чем-то новым, то внимательно читает всё, что на экране пишется (или на бумаге). А уж там-то всё это написано, все возможности и области применения. Особенно радуют "Мастеры чего-угодно", когда не через консоль настраиваешь, а в GUI с подробными пояснениями просто выбираешь. Ну а дальше уже в памяти хранится (или забывается — но должно вспоминаться в случае возвращения к настройке таких вещей).
Ничего плохого не хочу сказать о Ваших знакомых, но в чём причина их незнания? Может Вам так просто повезло с кругом знакомых (в плане совпадения причин незнания)?
И тогда уже становится интереснее — если причина одна.
Ничего плохого не хочу сказать о Ваших знакомых, но в чём причина их незнания? Может Вам так просто повезло с кругом знакомых (в плане совпадения причин незнания)?
И тогда уже становится интереснее — если причина одна.
Не переживайте, мне нравится этот диалог!:)
Причина на самом деле простая. Вбейте в гугл "Active Directory сайты диаграма" и найдите хотя бы одну, на которой показана связь включающая больше двух сайтов. Визуальная память — сильная вещь. А если человек один раз когда-то прочитал, что связь может объединять произвольное число сайтов, а потом годами сам использовал только вариант с двумя, то эта информация просто вылетает у него из головы.
Причина на самом деле простая. Вбейте в гугл "Active Directory сайты диаграма" и найдите хотя бы одну, на которой показана связь включающая больше двух сайтов. Визуальная память — сильная вещь. А если человек один раз когда-то прочитал, что связь может объединять произвольное число сайтов, а потом годами сам использовал только вариант с двумя, то эта информация просто вылетает у него из головы.
Довольно странное решение — в гугле искать. Точнее, доверяться диаграммам на сторонних сайтах, а не MSDN и Technet. Допускаю, что и на этих ресурсах такие диаграммы есть, но уверен, что они сопровождаются подробным описания сценария использования.
Хотя я вот пытался вспомнить, каким образом я сам узнал все эти вещи…
Сначала я узнал о существовании AD, что это такое и зачем нужно, потом узнал, что можно поднять два DC (по привычке я сокращаю до "домен" как раз Контроллер Домена с ролью AD). Соответственно, когда дошло до того, что самому пришлось организацию с рабочих групп переводить на доменную схему, столкнулся и с тем, как это реализовать и обеспечить хоть какую-нибудь отказоустойчивость. То есть при таком прогрессе знаний сложно упустить момент "а ещё в AD можно сделать так". Точнее, видя, какой прогресс сделан Майкрософтом в серверных операционных системах за эти годы (сравниваю гигантскую пропасть между 2003 и 2012 R2), я часто задаю себе вопрос: "А какие ещё возможности здесь есть, интересно было бы узнать". Ну и я знаю, что в моём случае задача типовая, значит кто-то её уже решал, а значит в серверных продуктах есть полная поддержка большинства сценариев, свойственных организациям различного уровня (от маленьких до гигантских корпораций). Остаётся только выбрать нужный — вот тут изучаются помимо нужного и другие.
И мне кажется, что вот этот самый вопрос — "а как ещё можно решить задачу, какие средства есть для её решения" — помогает не забыть или хотя бы использовать правильный механизм поиска решения.
Видимо, у Ваших знакомых всё было иначе, если возникает вопрос "а что, так можно было?".
P. S. Мне тут предстоит в филиале ещё поднимать домен (там до сих пор рабочие группы, так уж сложилось) и настраивать наследование, поэтому я и начал такой диалог :)
Хотя я вот пытался вспомнить, каким образом я сам узнал все эти вещи…
Сначала я узнал о существовании AD, что это такое и зачем нужно, потом узнал, что можно поднять два DC (по привычке я сокращаю до "домен" как раз Контроллер Домена с ролью AD). Соответственно, когда дошло до того, что самому пришлось организацию с рабочих групп переводить на доменную схему, столкнулся и с тем, как это реализовать и обеспечить хоть какую-нибудь отказоустойчивость. То есть при таком прогрессе знаний сложно упустить момент "а ещё в AD можно сделать так". Точнее, видя, какой прогресс сделан Майкрософтом в серверных операционных системах за эти годы (сравниваю гигантскую пропасть между 2003 и 2012 R2), я часто задаю себе вопрос: "А какие ещё возможности здесь есть, интересно было бы узнать". Ну и я знаю, что в моём случае задача типовая, значит кто-то её уже решал, а значит в серверных продуктах есть полная поддержка большинства сценариев, свойственных организациям различного уровня (от маленьких до гигантских корпораций). Остаётся только выбрать нужный — вот тут изучаются помимо нужного и другие.
И мне кажется, что вот этот самый вопрос — "а как ещё можно решить задачу, какие средства есть для её решения" — помогает не забыть или хотя бы использовать правильный механизм поиска решения.
Видимо, у Ваших знакомых всё было иначе, если возникает вопрос "а что, так можно было?".
P. S. Мне тут предстоит в филиале ещё поднимать домен (там до сих пор рабочие группы, так уж сложилось) и настраивать наследование, поэтому я и начал такой диалог :)
Не совсем понятна фраза " Нам достаточно добавить новый сайт в каждую из существующих." Что-то пропущено.
Ключевым вопросом, для понимания того, как правильно организовать структуру сайтов заказчика здесь является следующий — будет ли второй основной сайт stand-by DR локацией, которая должна использоваться только если возникли проблемы с первым или первый и второй основные сайты станут равноправными и должны разделять нагрузку.
Слово "равноправный" тут не совсем точно. "Равноправными" они будут только в одном смысле — в случае отказа всех КД в одной из локаций, помеченных у вас как "Remote Site X", их нагрузку в равной мере примут КД из Primary и Secondary Site. И есть побочный эффект — если будут недоступны КД в Primary или Secondary, то нагрузка пойдет не только к соседу, но и на Remote Sites.
Если надо (и канал связи позволяет) сделать две локации равноправными в полном смысле этого слова, их надо в один сайт объединять. Чем проще, тем лучше. :)
Вообще связи сайтов — это, по сути, такой уровень абстракции для описания топологии L2/L3 сети. Несколько связей нужны в случаях, когда сеть не является полностью маршрутизируемой, или же разделена на несколько сегментов, связанных медленными и/или дорогими каналами связи.
Возможно "равноправные" — не совсем верное слово. Но более точного у еня придумать не получается. "Равноправные" они в том смысле, что в отличие от первого варианта, где КД второго сайта будут использоваться ТОЛЬКО ЕСЛИ в первом ни один КД не доступен, во втором варианте КД удалённых сайтов моугт и будут постоянно использовать КД из первого и второго основных сайтов. Это довольно существенная разница — запасный КД на случай отказа основных или КД полностью разделяющие нагрузку основных, т.е. по сути тоже основные.
Если откажут КД в Primary и Secondary сайте (т.е. если случится масштабный сбой в обоих основных дата центрах), то вопрос того, куда пойдет нагрузка Active Directory будет далеко не самым важным для заказчика:)
Не всегда есть возможность объединить локации в одие сайт, ведь механизмом сайтов помимо Active Directory среды пользуются и другие приложения.
Если откажут КД в Primary и Secondary сайте (т.е. если случится масштабный сбой в обоих основных дата центрах), то вопрос того, куда пойдет нагрузка Active Directory будет далеко не самым важным для заказчика:)
Не всегда есть возможность объединить локации в одие сайт, ведь механизмом сайтов помимо Active Directory среды пользуются и другие приложения.
Возможно, под "равноправием" Вы подразумевали master-master или active\active?
во втором варианте КД удалённых сайтов моугт и будут постоянно использовать КД из первого и второго основных сайтов.
Я не очень понимаю эту фразу. Зачем они будут их использовать? Варианта только два — роли FSMO и репликация. Первый никак не зависит от топологии. Второй обычно некритичен в плане нагрузки (плюс надо смотреть на реальную топологию сети).
Если откажут КД в Primary и Secondary сайте (т.е. если случится масштабный сбой в обоих основных дата центрах), то вопрос того, куда пойдет нагрузка Active Directory будет далеко не самым важным для заказчика:)
Я не об этом. Я о том, что при подобной топологии не только primary и secondary сайты равноценны для всех удаленных, но и, например, удаленные равноценны с secondary для primary. И, если будет сбой в одном датацентре, то в вашей топологии нагрузка с него уйдет не во второй датацентр (как это было бы в случае наличия между ними отдельной связи с низкой стоимостью), а на все сайты, включая удаленные. Чтобы этого избежать, надо либо объединить их в один сайт, либо, если по каким-то причинам такое нежелательно, всё-таки создать эту отдельную связь в дополнение к остальным.
Зачем они будут их использовать?
Репликация, аутентификация пользователей в случае отказа удалённого сайта. Если ваша сеть достаточно хороша, чтобы все эти моменты вообще не играли роли, то можно её вообще на AD сайты не делить.
всё-таки создать эту отдельную связь в дополнение к остальным.
А вот это очень хорошее дополнение! Спасибо.
дубль
В свое время пришли к той же схеме. Только на сайтлинке, объединяющем центральные сайты звезды, дополнительно включили Notification.
Sign up to leave a comment.
Связи сайтов в Active Directory. Разрушаем стереотип