укажите дополнительные параметры репликации

Принудительная репликация между двумя контроллерами домена в Active Directory

Представьте, что в вашем доме всего одна дверь. Нет окон, нет двери патио, только одна дверь. Что произойдет, если вы не сможете открыть эту дверь? Дом и все в нем бесполезно для вас.

Контроллер домена, в некотором смысле, похож на дверь. Один с вышибалой на это. Это ворота, чтобы попасть внутрь к вещам, которые вы хотите. Active Directory (AD) — это вышибала у двери. Он проверяет ваши учетные данные, определяет, разрешено ли вам проходить через дверь, и к каким ресурсам вы можете получить доступ один раз внутри.

Если вы используете какую-либо сеть и имеете только один контроллер домена, вы живете в доме с одной дверью. Если что-то случится с этим контроллером домена, вся ваша система серверов развалится. Всегда иметь более одного контроллера домена (DC).

Но как убедиться, что оба контроллера домена имеют одинаковую информацию? Допустим, вы внесли изменения, связанные с безопасностью, на одном DC. Вы хотите, чтобы изменения немедленно реплицировались на другие контроллеры домена. Зачем ждать 15 минут или больше, чтобы это произошло по расписанию? Вам нужно форсировать репликацию контроллеров домена в Active Directory,

Есть 3 способа приблизиться к этому; через графический интерфейс пользователя (GUI), через интерфейс командной строки (CLI) или через PowerShell.

Принудительная репликация контроллера домена через графический интерфейс

Windows-серверы часто используют GUI, что хорошо для начинающих системных администраторов. Его легче учить, а иногда помогает визуализировать, что на самом деле происходит.

Принудительная репликация контроллеров домена с помощью командной строки

Если вы знакомы со старым добрым Windows CMD, то команда repadmin для вас. Это самый быстрый одноразовый способ принудительного дублирования DC. Если вы не знакомы, то сейчас самое время узнать о Windows CMD.

repadmin / syncall / AdeP

Принудительная репликация контроллера домена с помощью PowerShell

Если вы не используете PowerShell в своей повседневной жизни, вы пропустите. Вы действительно обязаны изучать PowerShell. Это облегчит вашу жизнь, а если вы являетесь младшим системным администратором, это поможет вам сделать карьеру следующим шагом.

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

Видите как он возвращает имена ДК? Теперь вы можете передать этот результат в следующий командлет. Канал — это символ вертикальной линии (|), который обычно находится на клавиатуре чуть выше клавиши Enter.

Команда должна выглядеть так, как показано на рисунке ниже. Запустить его. Он должен вернуть сообщение, подобное тому, которое было в разделе «Принудительная репликация контроллера домена через графический интерфейс выше». Если это заканчивается на «SyncAll завершен без ошибок». тогда это сработало.

Вы видели, как он также использует команду repadmin?

Результат должен напоминать изображение ниже. Внизу вы увидите точную дату и время последней репликации.

Keep’em Replicated

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

Источник

Репликация хранилища между серверами с помощью реплики хранилища

Область применения: Windows Server 2022, Windows Server 2019, Windows Server 2016

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

для управления репликой служба хранилища можно использовать центр администрирования Windows или PowerShell.

ниже приведено обзорное видео об использовании реплики служба хранилища в центре администрирования Windows.

Предварительные требования

В этом сценарии каждый сервер должен находиться на отдельном физическом или логическом узле. Для серверов нужно настроить обмен данными через сеть.

Windows Требования к центру администрирования

для совместного использования служба хранилища реплики и центра администрирования Windows необходимо следующее:

сейчас вы не можете использовать центр администрирования Windows на сервере для управления репликой служба хранилища.

Термины

В этом пошаговом руководстве в качестве примера используется следующая среда:

Два сервера с именами SR-SRV05 и SR SRV06.

Два логических расположения, которые представляют два разных центра обработки данных: Redmond и Bellevue.

Рис. 1. Межсерверная репликация

шаг 1. установка и настройка центра администрирования Windows на компьютере

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

Введите следующую команду, чтобы включить протокол WS-Management на локальном компьютере и настроить конфигурацию по умолчанию для удаленного управления на клиенте.

Шаг 2. предоставление операционной системы, компонентов, ролей, хранилища и сети

установите Windows server на обоих узлах сервера с типом установки Windows Server (возможности рабочего стола).

Сведения об использовании виртуальной машины Azure, подключенной к сети через ExpressRoute, см. в статье Добавление виртуальной машины Azure, подключенной к сети через expressroute.

начиная с Windows центра администрирования версии 1910 можно автоматически настроить целевой сервер в Azure. при выборе этого варианта установите Windows server на исходном сервере, а затем перейдите к шагу 3: настройка репликации «сервер-сервер».

добавьте сведения о сети, присоедините серверы к тому же домену, что и ваш компьютер управления Windows 10 (если вы используете его), а затем перезапустите серверы.

С этого момента вход в систему всегда нужно выполнять от имени пользователя домена, входящего в группу встроенной учетной записи администратора на всех серверах. Не забывайте повысить полномочия командных строк PowerShell и CMD, запуская их через графический интерфейс на компьютере с ОС Windows 10.

Подключение первый набор дискового корпуса JBOD, цели iSCSI, сети SAN FC или локального дискового накопителя (DAS) на сервер в сайте Redmond.

Подключение второй набор хранилища на сервер в site бельвью.

По возможности установите на обоих узлах все последние версии встроенного ПО и драйверов, предоставляемых поставщиками для полок дисков и хранилищ, HBA, BIOS или UEFI, а также для сетевых адаптеров и набора микросхем материнской платы. Перезапустите узлы при необходимости.

Для настройки общих хранилищ и сетевого оборудования обратитесь к документации поставщика оборудования.

Убедитесь, что для параметров BIOS или UEFI настроена высокая производительность, например отключено C-состояние, установлена скорость QPI, включена архитектура NUMA и установлена максимально возможная частота памяти. убедитесь, что для параметра управление питанием в Windows Server задана высокая производительность. При необходимости перезагрузите компьютер.

Настройте роли следующим образом.

Windows Метод центра администрирования

Метод диспетчер сервера

Запустите ServerManager.exe и создайте группу серверов, добавив все узлы сервера.

Установите роли и компоненты файлового сервера и реплики хранилища на всех узлах и перезапустите их.

метод Windows PowerShell

На компьютере SR-SRV06 или на компьютере удаленного управления выполните следующую команду в консоли Windows PowerShell. Она установит все необходимые компоненты и роли и перезапустит их.

Настройте хранилище следующим образом:

Полки дисков JBOD

Убедитесь, что каждый сервер может видеть только полки дисков своего расположения, и что подключения SAS правильно сконфигурированы.

Подготовьте хранилище с помощью дисковых пространств, выполнив шаги 1–3 из статьи Развертывание дисковых пространств на автономном сервере с помощью Windows PowerShell или диспетчера сервера.

Для хранилища iSCSI:

Убедитесь, что каждый кластер может видеть только полки дисков своего расположения. При работе с iSCSI следует использовать несколько сетевых адаптеров.

Подготовьте хранилище в соответствии с документацией поставщика. При использовании целей iSCSI для Windows изучите статью Блочное хранилище конечного сервера iSCSI, краткое руководство.

Для хранилища Fibre Channel в сети SAN:

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

Подготовьте хранилище в соответствии с документацией поставщика.

Для локального фиксированного дискового накопителя:

Убедитесь, что хранилище не содержит системный том, файл подкачки или файлы дампа.

Подготовьте хранилище в соответствии с документацией поставщика.

Запустите Windows PowerShell и используйте командлет Test-SRTopology, чтобы определить, все ли требования для реплики хранилища выполнены. Этот командлет можно запустить в режиме быстрой проверки требований или в режиме длительной оценки производительности.

Например, следующая команда проверит предложенное узлы на наличие томов F: и G:, а также запустит тест длительностью 30 минут:

рис. 2. отчет о топологии репликации служба хранилища

Шаг 3. Настройка репликации «сервер-сервер»

Использование Windows Admin Center

Добавьте исходный сервер.

На странице все подключения выберите исходный сервер.

выберите служба хранилища реплику на панели инструментов.

Выберите создать, чтобы создать новое партнерство. Чтобы создать виртуальную машину Azure, которая будет использоваться в качестве назначения для партнерства, выполните следующие действия.

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

Укажите сведения о партнерстве и нажмите кнопку создать (как показано на рис. 3).

Рис. 3. Создание новой связи

удаление партнерства из реплики служба хранилища в центре администрирования Windows не приводит к удалению имени группы репликации.

Использование Windows PowerShell

Теперь мы перейдем к настройке межсерверной репликации с помощью PowerShell. необходимо выполнить все приведенные ниже действия на узлах непосредственно или на удаленном компьютере управления, содержащем средства удаленного администрирования сервера Windows Server.

Не забывайте, что консоль Powershell должна иметь повышенные привилегии администратора.

Настройте межсерверную репликацию, указав исходный и конечный диски, журналы источника и назначения, узлы источника и назначения, а также размер журнала.

Чтобы узнать состояние источника и назначения репликации, используйте Get-SRGroup и Get-SRPartnership :

Ход репликации можно отслеживать следующим образом.

На исходном сервере введите следующую команду и изучите события 5015, 5002, 5004, 1237, 5001 и 2200.

На конечном сервере выполните следующую команду для просмотра событий реплики хранилища, которые показывают создание партнерства. Это событие сообщает количество скопированных байтов и время выполнения. Пример

Вот пример выходных данных:

Реплика хранилища отключает конечные тома и их буквы диска или точки подключения. Это сделано намеренно.

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

Пример контроля выполнения (не завершается самостоятельно):

На конечном сервере выполните следующую команду и проверьте события 5009, 1237, 5001, 5015, 5005 и 2200 для отслеживания хода обработки события. В этой последовательности не должно быть предупреждений или ошибок. Будет много событий 1237, которые указывают ход выполнения.

Шаг 4. Управление репликацией

Теперь можно приступить к управлению инфраструктурой межсерверной репликации и ее использованию. вы можете выполнить все приведенные ниже действия на узлах непосредственно или на удаленном компьютере управления, содержащем средства удаленного администрирования сервера Windows Server.

Для измерения производительности репликации выполните командлет Get-Counter на исходном и конечном узлах. Ниже перечислены имена счетчиков.

\Статистика ввода-вывода раздела реплики хранилища(*)\Количество раз приостановки записи на диск

\Статистика ввода-вывода раздела реплики хранилища(*)\Количество вводов-выводов записи на диск в ожидании

\Статистика ввода-вывода раздела реплики хранилища(*)\Количество запросов для последней записи в журнал

\Статистика ввода-вывода раздела реплики хранилища(*)\Средняя длина очереди записи на диск

\Статистика ввода-вывода раздела реплики хранилища(*)\Текущая длина очереди записи на диск

\Статистика ввода-вывода раздела реплики хранилища(*)\Количество запросов записи приложения

\Статистика ввода-вывода раздела реплики хранилища(*)\Среднее число запросов в операции записи в журнал

\Статистика ввода-вывода раздела реплики хранилища(*)\Средняя задержка записи приложения

\Статистика ввода-вывода раздела реплики хранилища(*)\Средняя задержка чтения приложения

\Статистика реплики хранилища(*)\Целевая RPO

\Статистика реплики хранилища(*)\Текущая RPO

\Статистика реплики хранилища(*)\Средняя длина очереди журнала

\Статистика реплики хранилища(*)\Длина очереди текущего журнала

\Статистика реплики хранилища(*)\Всего байт получено

\Статистика реплики хранилища(*)\Всего байт отправлено

\Статистика реплики хранилища(*)\Средняя время задержки исходящих данных в сети

\Статистика реплики хранилища(*)\Состояние репликации

\Статистика реплики хранилища(*)\Средняя задержка приема-передачи сообщения

\Статистика реплики хранилища(*)\Время, затраченное на последнее восстановление

\Статистика реплики хранилища(*)\Количество транзакций восстановления, записанных на диск

\Статистика реплики хранилища(*)\Количество транзакций восстановления

\Статистика реплики хранилища(*)\Количество транзакций репликации, записанных на диск

\Статистика реплики хранилища(*)\Количество транзакций репликации

\Статистика реплики хранилища(*)\Максимальный порядковый номер журнала

\Статистика реплики хранилища(*)\Количество полученных сообщений

\Статистика реплики хранилища(*)\Количество отправленных сообщений

Дополнительные сведения о счетчиках производительности, доступных в Windows PowerShell, см. в статье Get-Counter.

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

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

Замена репликации DFS на реплику хранилища

У многих клиентов корпорации Майкрософт репликация DFS развернута в качестве решения для аварийного восстановления таких неструктурированных пользовательских данных, как домашние папки и общие папки отделов. Репликация DFS входит в состав в Windows Server 2003 R2 и всех последующих выпусков операционных систем. Она хорошо показала себя в сетях с низкой пропускной способностью, благодаря чему является привлекательным решением для сред с высокой задержкой, малыми объемами изменений и большим числом узлов. Однако при использовании для репликации данных это решение имеет существенные ограничения:

Реплика хранилища отличается отсутствием этих ограничений. Но у нее есть несколько других ограничений, из-за которых она менее удобна для использования в некоторых сетевых средах.

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

установите Windows Server на двух серверах и настройте хранилище. Вы можете обновить существующий набор серверов или установить их заново.

Убедитесь, что все подлежащие репликации данные размещены на одном или нескольких томах данных, а не на диске C:. а. Чтобы сэкономить время, вы можете заранее передать эти данные на другой сервер, например, с помощью резервной копии или копирования файлов, или использовать хранилище с тонкой подготовкой. В отличие от репликации DSF здесь не требуется точное совпадение метаданных.

Предоставьте общий доступ к данным на исходном сервере и сделайте его доступным через пространство имен DFS. Это важно для того, чтобы пользователи сохранили доступ к данным в случае аварийного изменения имени сервера на имя резервного расположения. а. На целевом сервере можно создать соответствующие общие папки, которые будут недоступны во время обычной работы, b. Не добавляйте целевой сервер в пространство имен пространства имен DFS или, если это необходимо, убедитесь, что все целевые объекты папки отключены.

Включите репликацию реплики хранилища и завершите начальную синхронизацию. Репликация может быть как синхронной, так и асинхронной. а. Синхронная репликация более предпочтительна, так как она обеспечивает согласованность данных ввода-вывода на конечном сервере. b. Мы настоятельно рекомендуем включить теневое копирование томов и периодически создавать моментальные снимки с помощью VSSADMIN или других удобных для вас средств. Это гарантирует согласованную запись файлов приложений на диск. В случае аварии вы сможете восстановить из моментальных снимков на целевом сервере те файлы, для которых асинхронная репликация была выполнена лишь частично. Моментальные снимки реплицируются вместе с остальными файлами.

Теперь можно просто работать в обычном режиме, пока не случится авария.

Назначьте сервер назначения новым источником, и его реплицированные тома станут доступны для пользователей.

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

Добавьте сервер и его общие папки в качестве целевого объекта папки пространств имен DFS.

Теперь пользователи могут снова обратиться к своим данным.

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

Добавление виртуальной машины Azure, подключенной к сети через ExpressRoute

Рис. 4. ресурсы, связанные с ExpressRoute — запишите имя виртуальной сети.

Добавьте группу безопасности сети. При создании выберите идентификатор подписки, связанный с созданной службой ExpressRoute, и выберите только что созданную группу ресурсов.

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

Создайте виртуальную машину Azure со следующими параметрами (показаны на рис. 5):

Источник

Репликация Active Directory. Часть 1

Еще в 2014 году я начал писать статью о репликации Active Directory, так как тема важная и требует обязательного понимания для работы со службами каталогов. Увы, тогда работа не была завершена. Сегодня же увидел две статьи по данной тематике на ресурсе itband.ru и, с разрешения автора, делаю репост первой статьи.

Репликация Active Directory: Разговор на «Ты»

О дна из главных рекомендаций Microsoft касательно Active Directory Domain Services (ADDS) говорит о необходимости развертывания в производственной среде минимум двух контроллеров домена. Реальная же жизнь показывает, что в средних и крупных компаниях количество контроллеров может достигать нескольких десятков и даже сотен. Когда системный администратор начинает работать в крупной сети на базе ADDS одной из самых важных забот становится репликация Active Directory.

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

Впервые появившись в Windows Server 2000 технология Active Directory (это прежде всего транзакционная база данных содержащая информацию об объектах вашей сети и глубоко интегрированная с системой безопасности Windows) более чем за 9 лет претерпела некоторые изменения, но даже в Windows Server 2008 R2 работает на хорошо зарекомендовавшем себя движке Extensible Storage Engine ( ESE ). Если верить расчетам масштабируемости, данного решения должно хватить даже сетям с несколькими миллионами объектов, а вырасти база, может до 16 террабайт. Сердцем Active Directory является файл NTDS.DIT в котором, собственно говоря, вся информация и хранится. При добавлении второго и последующих контроллеров домена происходит создание копии данного файла, и размещение ее на введенном в строй новом контроллере. Т.е можно сделать четкий вывод: каждый контроллер домена хранит свою версию файла NTDS.DIT.

Важно понимать, что при открытии оснастки для работы с Active Directory, а это может быть Active Directory Пользователи и Компьютеры или как вариант Active Directory Сайты и Сервисы, вы всегда подключаетесь к конкретному контроллеру домена и при желании можете выбрать с каким контроллером работать – это означает, что выработаете с конкретной версией базы данных, которая в данный момент может отличаться от других копий. Естественно создавая учетную запись либо меняя конфигурацию, изменения вносятся только в один файл NTDS.DIT, который находится на контроллере, куда подключена оснастка (или любой другой инструмент управления). После внесения изменений критически важно оповестить другие контроллеры об изменениях и новых данных и как можно скорее произвести синхронизацию. В Active Directory этот процесс синхронизации называется репликацией и в дальнейшем я буду использовать именно этот термин. Особенно важно помнить эти факты, когда вы занимаетесь решением проблем с репликацией Active Directory и вносите изменения в контекст конфигурации AD. Это происходит тоже на конкретном контроллере и с конкретным файлом NTDS.DIT.

Физически NTDS.DIT это просто один файл, но логически он состоит из нескольких разделов (иногда их называют контекстами именования или контекстами репликации), каждый из которых содержит определенную информацию и реплицируется по-своему.

Раздел «Schema» – хранит в себе схему ActiveDirectory, которая описывает, какие объекты могут быть созданы, и что они из себя будут представлять. Меняется реже всего, как правило, при переходе контроллеров на новую операционную систему либо при установке в организации почтовой системы Exchange. Процесс изменения базы данных в контексте схемы чаще всего называют расширением схемы и это не случайно, т.к. отменить эти изменения (например, удалить созданные в этом контексте объекты) невозможно. Репликация раздела осуществляется на все контроллеры домена в лесу Active Directory. Единственный раздел, чья репликация не является мультимастерной. Репликация раздела «Schema» всегда односторонняя и выполняется от контроллера домена, владеющего ролью FSMO Хозяин Схемы, на все оставшиеся контроллеры домена. (Впоследствии оставшиеся контроллеры домена реплицируют информацию своим репликационным партнерам, но источником обновления в этой цепочке репликации всегда будет Хозяин схемы)

Рис. 1 Разделы базы Active Directory

Раздел «Configuration» – содержит информацию о конфигурации Active Directory, в частности описывает, какие и сколько доменов создано, как они между собой связанны, сколько существует сайтов, какие сервисы доступны в организации и просто системные настройки службы каталогов такие как квоты, политики LDAP-запросов, правила неточного поиска, разрешения имен объектов и т.п.. Раздел реплицируется между всеми контроллерами доменов в лесу и может быть изменен на любом контроллере домена. Изменения данного раздела связаны с конфигурированием и настройкой самой Active Directory.

Раздел «Domain» – или доменный. Все учетные записи пользователей, группы безопасности, организационные подразделения, объекты компьютеров и принтеров создаются и хранятся в данном разделе. Реплицируется раздел только между контролерами домена в том домене к которому принадлежит контроллер. Получается, что в организациях, имеющих несколько доменов, в каждом домене будет свой раздел «Domain».

Разделы «Application» – опциональные разделы. Зона репликации зависит от настройки. Как правило, создается два Application раздела, это ForestDNSZones и DomainDNSZones.

· ForestDNSZones – хранит SRV и CNAME записи для Леса AD и реплицируется на все контроллеры домена в лесу, являющиеся DNS серверами.

· DomainDNSZones – содержит DNS записи для зоны домена. Реплицируется на все контроллеры домена с установленным на них DNS сервером.

Посмотреть на каждый раздел каталога и данные в нем хранящиеся можно через утилиты ADSI Edit AdExplorer и LDP.exe. Утилиту (AdExplorer) можно скачать с сайта Microsoft, она входит в комплект утилит Sysinternals. А LDP.exe становится доступна после установки на контроллер домена Windows Support Tools. Следует отметить, что данный комплект не потерял своей актуальности и после выхода Windows Server 2008.

Рис. 2 Выбор раздела для подключения в утилите LDP.exe

Теперь важно уяснить следующее, когда клиент аутентифицируется на контроллере домена, и применяются групповые политики, образуется трафик (85 Кб на вход станции в домен (с Default Domain Policy) и 75Кб на вход пользователя (тоже с Default Domain Policy)). Более того репликация изменений между контроллерами доменов порождает свой репликационный трафик. Этим трафиком нужно управлять, представьте себе, что организация и естественно ваш домен Active Directory располагается в двух городах связанных WAN каналом и однажды все пользователи филиала в Ростове-на-Дону начнут обращаться к контроллеру, расположенному в центральном Московском офисе. А контроллеры домена начнут реплицировать информацию в любое время и по первому желанию. Минимум с чем Вам придется столкнуться это высокая утилизация WAN канала и медленный вход пользователей в домен.

Поэтому в Active Directory введено понятие Сайтов. Сайт это логическое объединение контроллеров домена и клиентов для управления служебным трафиком службы каталогов. Если ваш Лес Active Directory не распространяется за пределы одного сегмента локальной сети, следовательно, вы работаете с односайтовой структурой. Именно она является дефолтной и именно с неё мы начнем разговор.

При создании Active Directory и поднятии (имеется ввиду процедура dcpromo) первого контроллера домена формируется сайт по-умолчанию с именем «Default-First-Site-Namе». Если не создавать дополнительных сайтов и придерживаться односайтовой структуры, все новые контроллеры будут попадать в данных сайт. После появления второго и последующих контроллеров должны образоваться Репликационные связи (connection objects), указывающие на то какой контроллер и откуда должен реплицировать изменения. Посмотреть эти связи можно через оснастку «Active Directory Сайты и Службы».

На Рис.3 открыта оснастка «ActiveDirectoryСайты и Службы» и по имеющейся информации можно сказать, что в данном примере имеется единственный сайт по-умолчанию, в котором находится два контроллера домена Server1 и Server2. А так же, что Server1 имеет партнера по репликации Server2 и реплицирует с него изменения. Без наличия данных связей репликации между контроллерами работать не будет.

Нередки случаи когда системные администраторы, установив новый контроллер домена, не находят у него данных связей и начинают создавать их руками. Это распространенная ошибка. За создание связей, базируясь на определенной логике, отвечает служба KCC (Knowledge Consistency Checker). Созданию связей самостоятельно чревато возникновением ошибок и дальнейшей путаницей. Для тех же, кто не хочет ждать, пока KCC справится с задачей, существует способ ее поторопить.

Рис. 3 Свойства Репликационной связи.

Для этого необходимо использовать утилиту Repadmin с ключом kcc. Синтаксис будет выглядеть следующим образом:

repadmin /kcc server1.itband.ru (Вместо server1.itband.ru вы укажете FQDN вашего сервера)

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

repadmin /kccsite: «Default-First-Site-Name» (Если имя сайта было изменено «Default-First-Site-Name» заменяется реальны именем)

Можно так же запустить процесс генерации топологии на всех контроллерах леса командой repadmin /kcc *. Большинство опций команды repadmin поддерживают ключ /async, который дает задание контроллеру домена и при этом не ожидает его завершения.

Рис. 4 Принцип создание связей репликации службой KCC

Как только число контроллеров достигнет 8 штук, правило «трех прыжков» приведет к тому, что служба KCC выполнит «ход конем» и добавит дополнительные прямые связи, тем самым сокращая расстояние между двумя любыми контроллерами до допустимого значения «максимум в три прыжка». Данная ситуация хорошо проиллюстрирована на рисунке 4. Создание связей между контроллерами расположенными в разных сайтах выполняется с учетом топологии сайтов, сайт-линков и мостов между сайт-линками. Подробнее о построении межсайтовой репликации читайте в разделе «межсайтовая репликация». Следует отметить, что кольцо при построении топологии репликации строиться независимо для каждого контекста репликации (раздела Active Directory) далее эти кольца накладываются друг на друга и выясняется, где можно вместо нескольких репликационных связей – обойтись одной.

Внутрисайтовая репликация начинается, когда в Active Directory происходит изменение, это может быть изменение атрибута или создание учетной записи. Контроллер домена, в базе которого произошли изменения, ожидает 15 секунд, а затем отправляет ближайшему партнеру репликации уведомление о том, что на нем произошло какое-то обновление. При наличии двух и более партнеров по репликации, последующие уведомления отправляются каждому партнеру с 3-секундной задержкой (Верно для уровня леса Windows 2003 и выше, для Windows 2000 первичная задержка составляет 300 секунд, а последующие 45 секунд). После получения уведомления об изменении партнер репликации проверяет возможность репликации и список обновлений и выполняет процесс репликации с тем контроллером, который прислал уведомление. Трех секундная задержка предотвращает чрезмерную загрузку из-за одновременных запросов обновлений от множества партнеров по репликации. Периоды нотификаций можно настроить командой repadmin /notifyopt.

Следует обратить особое внимание читателей, что процесс репликации ВСЕГДА происходит в режиме pull, т.е. «стягивания» изменений и новых объектов, но не в режиме push. Это связано с тем, что только контроллер хозяин файла NTDS.DIT имеет право в нем что-то изменять и отвечает за целостность своей БД. Из этого так же следует, что ВСЕ линки репликации которые, создаются в ручную или службой KCC имеют однонаправленную природу, т.е. логически обозначают входящий поток репликационной информации.

Некоторые изменения реплицируются без 15-секундной задержки. Такая репликация, называемая срочной (urgent replication). В события ее вызывающие входят блокировки учетных записей, изменение пароля учетной записи. В официальных документах присутствует путаница. По сути это не репликация вовсе и механизм передачи этих изменений в коре отличается от процесса репликации. Хотя в качестве транспорта используется тоже протокол RPC. Такая репликация выполняется не обычным механизмом репликации, а специальными вызовами RPC. По сути это запросы аналогичные изменению объектов через ADSI. В зависимости от режима работы леса список событий может меняться.

Если внимательно присмотреться к свойствам репликационной связи, то можно найти расписание репликации, по умолчанию оно установлено на ежечасный запуск. Возникает вопрос: Зачем еще одно расписание если есть система уведомлений?

Рис. 5 Расписание репликации

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

При возникновении трудностей с репликацией можно используя утилиту replmon вручную запустить процесс репликации не дожидаясь расписания:

repadmin /replicate server2.itband.ru server1. itband.ru dc=itband,dc=ru

С ключем /replicate необходимо задать куда (server2.itband.ru ) и с какого контроллера (server1.itband.ru ) должны реплицироваться данные, а также какой раздел каталога нужно реплицировать (dc=itband,dc=ru).

Запустить репликацию всех разделов Active Directory в рамках всего леса (в рамках существующей топологии) довольно легко, для это следует выполнить: Repadmin /syncall /AeS. Учтите, что в крупных сетях такой запуск репликации может вызвать серьезный поток трафика, который пойдет не только по скоростным каналам.

Алгоритм распространения изменений

Любой контроллер домена ведет некий счетчик называемый «highestCommittedUSN», который увеличивается на единицу при любом атомарном изменении базы Active Directory. При этом у каждого контроллера домена этот счетчик свой и между контроллерами его значения не совпадают. Например, в 9 утра значение «highestCommittedUSN» у контроллера DC1 было равно 14879, а в 6 вечера 14896. Это значит, что за прошедшее время в базе этого контроллера произошло 17 изменений. Посмотреть значение «highestCommittedUSN» можно с помощью утилиты ldp просто подключившись к нужному контроллеру домена. При подключении выводиться состояние динамического системного объекта RootDSE, среди атрибутов которого как раз и присутствует «highestCommittedUSN».

Рис. 6 Просмотр значения «highestCommittedUSN» на контроллере домена.

После проведенной репликации каждый контроллер домена кэширует значения «highestCommittedUSN» своих репликационных партнеров. И когда в последствии контроллер домена DC1 получит уведомление от контроллера DC2 в нем будет информация о текущем «highestCommittedUSN» DC2. Контроллеру DC1 останется только сравнить текущий «highestCommittedUSN» с тем, который он закэшировал во время прошлой репликации. Если он вырос : значит в базе DC2 произошли изменения и необходимо произвести репликацию. Если остался прежним, то в ней нет необходимости.

Таблица, в которой хранится информация о «highestCommittedUSN» репликационных партнеров называется вектором обновления или «up-to-date vector». Посмотреть ее можно с помощью утилиты repadmin.

repadmin /showutdvec dc1 dc=lab,dc=itband,dc=ru

Default-First-Site-NameDC2 @ USN 16667 @ Time 2009-09-21 01:24:15

Default-First-Site-NameDC1 @ USN 20704 @ Time 2009-09-21 01:31:25

В данном примере результатом будет вывод значений «highestCommittedUSN» репликационных партнеров DC1 (а также актуальный USN его самого), при этом это будут значения, о которых DC1 знает, в действительности уже они могли вырасти по причине внесения изменения в базу на тех контроллерах. Следует помнить, что «highestCommittedUSN» увеличивается как после изменений внесенных в базу непосредственно на контроллере, так и после изменений прореплицированных с других контроллеров.

Рис. 7 Просмотр вектора обновлений на контроллере DC1.

Есть одно но, сам по себе «up-to-date vector» отвечает на вопрос «Были ли изменения?». Этого недостаточно, необходимо вычислить что изменилось. Давайте рассмотрим данный механизм на примере.

В нашей сети находится два синхронизированных контроллера домена (DC1и DC2 ). До изменений «highestCommittedUSN» у DC1 равен 20902, а у DC2 16940. На контроллере DC1 создается учетная запись пользователя Федя Рашпин. После создания учетной записи «highestCommittedUSN» на DC1 стал показывать 20909. Это говорит о том, что было произведено 7 изменений. Напоминаю, что считаются атомарные изменения, т.е создание учетной записи можно разложить на само создание плюс изменение ряда атрибутов, которые выполняет оснастка Active Directory Users and Computers.

Если подключиться через LDP.exe к нашему объекту пользователь, то можно увидеть два атрибута uSNCreated и uSNChanged.

Рис. 8 Просмотр атрибутов uSNCreated и uSNChanged для учетной записи.

uSNCreated будет говорить, какой «highestCommittedUSN» был в момент создания объекта на данном контроллере, а uSNChanged в момент последнего изменения. Получается, что первый показатель (uSNCreated) будет оставаться неизменным, а второй в свою очередь (uSNChanged) по мере обновлений объекта будет расти. Важно понимать, что uSNCreated и uSNChanged на каждом контроллере домена у объекта будут свои.

Посмотрим на пользователя Федя через утилиту repadmin. Для получения служебной информации, используемой при репликации задействуем ключ /showmeta.

repadmin /showmeta “CN=Федя Рашпин,OU=testou,DC=lab,DC=itband,DC=ru”

При этом нас интересует информация с каждого контроллера. Но начнем с DC1.

Рис. 9 Вывод метаданных о созданном пользователе на DC1.

Какую же информацию нам дает repadmin (Рис. 9). Данный список не что иное, как объект пользователя, разложенный по атрибутам.

По каждому атрибуту можно увидеть:

· Loc.USN это «highestCommittedUSN» контроллера DC1 в момент внесения последних изменений.

· Originating DC говорит о том, на каком контроллере были произведены последние действия с этим атрибутом, т.е откуда пошло распространение.

· Org.Usn это «highestCommittedUSN» контроллера автора изменений в момент внесения последних.

· Ver – версия атрибута, растет на единицу при каждом его изменении (локально или в результате репликации).

· Attribute – непосредственно название самого атрибута.

Взглянув на эту таблицу можно сделать вывод, что пользователь «Федя Рашпин» был создан (или изменен) на контроллере домена DC1, при этом увидеть, что «highestCommittedUSN» DC1 в процессе создания учетной записи рос от 20904 до 20909. (Org.USN)

Совпадение колонок Loc.USN и Org.USN говорит о том, что запуск repadmin /showmeta произведен на контроллере домена, который был автором изменений. Если выполнить тоже самое на втором контроллере, результат будет несколько другой.

Рис. 10 Вывод метаданных о созданном пользователе на DC2.

На DC2 четко просматривается, что автором всех изменений (кроме одного) был DC1 и его «highestCommittedUSN» (Org.Usn) в момент изменения каждого атрибута. А также «highestCommittedUSN» в момент внесения обновлений в базу контроллера DC2. (Loc.USN)

А вот теперь пора сделать небольшой вывод:

Когда контроллер домена рассылает репликационным партнерам уведомления об обновлении базы, он сообщает свой текущий «highestCommittedUSN». Партнер, получивший это уведомление, сравнивает этот «highestCommittedUSN» с тем, что он запомнил с прошлой процедуры репликации. Если он вырос, значит необходимо запускать репликацию. Например: DC2 получил от DC1 уведомление и текущий «highestCommittedUSN» равный 20912, он сравнивает с известным ему значением 20850. Делает вывод о необходимости репликации и запрашивает изменения, произошедшие в период роста «highestCommittedUSN» с 20850 до 20912.

DC1 осуществляет выборку из своей базы. Для этого просматривается Loc.USN и те атрибуты, которые менялись в заданном диапазоне «highestCommittedUSN» реплицируются на DC2.

Решение конфликтов

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

Правило первое: Можно было заметить в метаданных репликации параметр Ver. Как уже было сказано, он увеличивается на единицу каждый раз при изменении атрибута. Если сразу на двух контроллерах происходит изменение атрибута, в первую очередь будет произведено сравнение номера версии. Атрибут, имеющий более высокий номер версии, является приоритетным. И именно его значение будет использоваться.

Правило второе: Если номер версии совпадает, учитывается время изменения атрибута. Значение, установленное по времени последним выигрывает. В гипотетической ситуации, когда изменения атрибута на разных контролерах имеют один номер версии, да и сделаны в одно время победит тот контроллер, который имеет больший номер GUID. Возможно несколько любопытных ситуаций. Один администратор решает удалить пустое организационное подразделение, другой же на соседнем контроллере в это время создает учетную запись. Получается явный конфликт интересов.

В такой ситуации будет задействован скрытый контейнер LostAndFound, получить доступ, к которому можно только переключив оснастку «Active Directory – пользователи и компьютеры» в расширенный режим.

Рис. 11 Контейнер LostAndFound.

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

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

Рис. 12 Автоматическое разрешение конфликта

Большим преимуществом с точки зрения репликации является переход на режим работы домена Windows Server 2003 и более поздние. В них изменилась процедура репликации атрибутов типа «linked-valued» (пример «Членство в группах»). При добавлении разных пользователей на разных контроллерах в одну и туже группу результатом будет членство всхе добавленных пользователей в составе этой группы. В случае с Windows 2000 состав группы при таком конфликте определялся бы по ее членству на том контроллере, на котором изменения в группе были бы сделаны позже по времени.

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

Илья Рудь

Константин Леонтьев

Источник