Что такое репликация файлов
Репликация DFS представляет собой службу роли в Windows Server, которая позволяет эффективно реплицировать папки (включая те, ссылка на которые указывается по пути пространства имен DFS) между разными серверами и сайтами. Репликация DFS предоставляет эффективный механизм репликации между несколькими источниками, который поддерживает синхронизацию папок между серверами, соединенными сетевыми подключениями с ограниченной пропускной способностью. Она заменяет службу репликации файлов (FRS) в качестве подсистемы репликации для пространств имен DFS.
Рассмотрите возможность использования Синхронизация файлов Azure, чтобы сократить объем локального хранилища. Синхронизация файлов Azure может поддерживать синхронизацию нескольких файловых серверов Windows, и каждый из них должен хранить кэш только в локальной среде, пока полная копия данных находится в облаке. Синхронизация файлов Azure также имеет дополнительное преимущество облачного резервного копирования с интегрированными моментальными снимками. Дополнительные сведения см. в разделе "Планирование развертывания Синхронизация файлов Azure".
доменные службы Active Directory (AD DS) использует репликацию DFS для репликации папки SYSVOL в доменах, использующих режим работы домена Windows Server 2008 или более поздней версии. Дополнительные сведения о переходе с репликации SYSVOL на репликацию DFS см. в этой статье.
Репликация DFS использует алгоритм сжатия, называемый удаленным разностным сжатием (remote differential compression — RDC). Алгоритм удаленного разностного сжатия определяет изменение данных в файле, что позволяет репликации DFS реплицировать только измененные блоки файла, а не весь файл.
Чтобы использовать репликацию DFS, следует создать группы репликации и добавить в них реплицируемые папки. На следующем рисунке представлены группы репликации, реплицируемые папки и элементы.
На этом рисунке показано, что группа репликации представляет собой набор серверов, известных как члены, которые участвуют в репликации одной или нескольких реплицированных папок. Реплицируемая папка — это папка, содержимое которой постоянно синхронизируется между всеми элементами. На рисунке есть две реплицируемые папки: Projects и Proposals. При любом изменении данных в каждой реплицируемой папке все такие изменения реплицируются между элементами группы репликации по установленным подключениям. Подключения между всеми элементами формируют топологию репликации. Создание нескольких реплицируемых папок в одной группе репликации упрощает процесс развертывания реплицируемых папок, так как топология, расписание и регулирование пропускной способности для группы репликации автоматически применяются к каждой реплицируемой папке. Чтобы развернуть дополнительные реплицируемые папки, нужно с помощью программы Dfsradmin.exe или по инструкциям мастера определить локальный путь и разрешения для новой реплицируемой папки.
Каждая реплицируемая папка имеет уникальные параметры, в том числе фильтры файлов и вложенных папок, что позволяет исключать разные файлы и вложенные папки для каждой реплицируемой папки.
Реплицируемые папки, которые хранятся в каждом элементе, могут находиться на разных томах, и их не обязательно делать общими папками или включать в пространства имен. Но оснастка управления DFS позволяет легко предоставить общий доступ к реплицируемым папкам, а при желании — опубликовать их в существующем пространстве имен.
Для управления репликацией DFS можно использовать оснастку управления DFS, команды DfsrAdmin и Dfsrdiag, а также скрипты с вызовом WMI.
Репликация шаблонов Group Policy
Шаблон групповой политики (GPT) – это часть групповой политики, настройки которой хранятся в одном или нескольких файлах. Эта часть объекта групповой политики и связанные с ней файлы хранятся на контроллерах домена в каталоге Sysvol. По умолчанию они лежат по адресу: c:\Windows\Sysvol\Sysvol\>\Policies
Папка Sysvol на контроллерах домена используется для предоставления клиентам параметров групповой политики и сценариев входа/выхода в систему. И так как Sysvol используется для аутентификации пользователей и компьютеров, данные в ней должны быть актуальными на всех контроллерах домена. Когда в Sysvol на одном контроллере домена происходит изменение какой-либо информация, то это вызывает процесс репликации Sysvol на остальные контроллеры домена.
Sysvol реплицируется с использованием службы репликации файлов File Replication System (FRS). Служба FRS не использует репликацию по графику, вместо этого она использует механизм репликации по состоянию. Это означает, что как только происходит изменение в любом файле или структуре папок Sysvol, то запускается механизм репликации. Такое решение обеспечивает очень эффективную и быструю модель репликации для GPT.
В качестве примечания, стоит отметить, что репликация FRS не соотносится с границами сайта. Таким образом, такая репликация затронет все контроллеры домена в течение всего лишь нескольких минут, не зависимо в каком сайте (пусть даже удаленном) находятся эти DC.
Примечание: В Windows Server 2008 для репликации содержимого Sysvol может использовать как FRS так и DFS-R. Кстати, прочитайте статью о том, как можно задействовать репликацию FRS на отдельном порту.
Требования
До начала развертывания репликации распределенной файловой системы (DFS) необходимо настроить серверы следующим образом.
- Обновите схему доменных служб Active Directory (AD DS), чтобы включить в нее дополнения для Windows Server 2003 R2 или более поздней версии. Нельзя использовать реплицируемые папки, доступные только для чтения, с дополнениями схемы для Windows Server 2003 R2 или более ранних версий.
- Убедитесь, что все серверы в группе репликации находятся в одном и том же лесу. Репликация на серверах, находящихся в разных лесах, недоступна.
- Установите репликацию DFS на все серверы, которые будут членами группы репликации.
- Чтобы проверить совместимость антивирусного программного обеспечения с репликацией распределенной файловой системы (DFS), свяжитесь с поставщиком антивирусного программного обеспечения.
- Найдите все папки, которые требуется реплицировать, на томах, форматированных в файловой системе NTFS. Репликация DFS не поддерживает файловые системы ReFS (Resilient File System) и FAT. Также репликация DFS не поддерживает репликацию содержимого общих томов кластера.
Настройка пространства имен DFS в Windows Server 2012
Перейдем к описанию процедуры настройки пространство имен DFS, для чего необходимо открыть панель управления DFS Management tool.
Создадим новое пространство имен (New Namespace).
Необходимо указать имя сервера, который будет содержать пространство имен (это может быть как контроллер домена, так и рядовой сервер).
Затем следует указать имя создаваемого пространства имен DFS и перейти в расширенные настройки (Edit Settings).
Здесь следует указать имя пространства имен DFS и права доступа к данному каталогу. Обычно рекомендуется указать, что доступ к сетевой папке разрешен Всем (Everyone), в этом случае права доступа проверяются на уровне файловой системы NTFS.
Далее мастер предложит указать тип создаваемого пространства имен. Это может быть Domain-based namespace (доменное пространство имен) или Stand-alone namespace (отдельное пространство имен). Domain-based namespace обладает ряд преимуществ, но для его работы нужен, собственно домен Active Directory и права администратора домена (либо наличие делегированных прав на создание доменных пространств имен DFS).
После окончания работы мастера в ветке Namespaces консоли управления DFS появится созданное нами новое пространство имен DFS. Чтобы пользователи при доступе к DFS каталогам видели только те каталоги, к которым у них имеется доступ, включим для данного пространства DFS Access-Based Enumeration (подробнее о данной технологии в статье Access-Based Enumeration в Windows). Для этого откройте окно свойств созданного пространства имен.
И на вкладке Advanced включите опцию Enable access-based enumeration for this namespace.
Чтобы посмотреть содержимое нового пространства DFS, просто наберите в окне проводника UNC путь: \\имя_домена_или_сервера\DFS
Добавление нового каталога в существующее пространство имен DFS
Укажите наименование каталога в DFS пространстве и его реальное местоположение на существующем файловом сервере (Folder targets).
Взаимодействие с виртуальными машинами Azure
Использование репликации DFS на виртуальной машине в Azure протестировано для Windows Server. Однако существуют некоторые ограничения и требования, которые необходимо соблюдать.
- Использование снимков или сохраненных состояний для восстановления сервера, выполняющего репликацию DFS с целью реплицирования любых данных, кроме папки SYSVOL, приводит к отказу репликации DFS, что требует особых действий по восстановлению базы данных. Точно так же нельзя экспортировать, клонировать или копировать виртуальные машины. Дополнительные сведения см. в статье 2517913 в базе знаний Майкрософт и безопасной виртуализации DFSR.
- При резервном копировании данных в реплицированной папке, размещенной на виртуальной машине, необходимо использовать программы резервного копирования из гостевой виртуальной машины.
- Службе репликации DFS требуется доступ к физическим или виртуализованным контроллерам домена, так как она не может взаимодействовать непосредственно с AAD.
- Для репликации DFS требуется VPN-подключение между локальными членами группы репликации и другими элементами, размещенными на виртуальных машинах Azure. Необходимо также настроить локальный маршрутизатор (например, Forefront Threat Management Gateway), чтобы разрешить сопоставителю конечных точек RPC (порт 135) и случайным образом назначенному порту в диапазоне между 49152 и 65535 передачу через VPN-подключение. Для указания статического порта вместо случайного порта можно использовать командлет Set-DfsrMachineConfiguration или программу командной строки Dfsrdiag. Дополнительные сведения о способах указания статического порта для репликации DFS см. в разделе Set-DfsrMachineConfiguration. Сведения о связанных портах, используемых для управления Windows Server, см. в статье 832017 в базе знаний Майкрософт.
Дополнительные сведения о начале работы с виртуальными машинами Azure см. на веб-сайте Microsoft Azure.
Проверка репликации GPO
Самый простой инструмент диагностики репликации GPC и GPT является GPOTool. Этот инструмент является бесплатным и очень простым в использовании. Он поставляется вместе с операционной системой и может быть запущен из командной строки. Просто наберите в командной строке gpotool > /verbose .
Результатом выполнения этой команды будет отображение номеров версии GPT и GPC для каждого объекта групповой политики на всех перечисленных контроллерах домена.
Таким образом, если вы знаете, что GPO был изменен, но настройки не применяются, было бы хорошо убедиться, что GPO были реплицированы на контроллер домена, на котором вы были аутентифицированы.
Резюме
Репликация групповых политик контролируется двумя различными механизмами репликации: FRS и репликацией Active Directory. Для того, чтобы содержимое GPO было актуальным на всех контроллерах домена, должна быть осуществлена репликация обоих частей групповой политики — GPT и GPC, только при выполнении этого условия GPO будут функционировать корректно. С помощью утилиты GPOTool, вы всегда можете убедиться, что все данные объектов групповой политики были реплицированы на ваш контроллер домена.
Предыдущая статья Следующая статья
Запрос к Active Directory из Excel
Установка программ с помощью групповых политик в домене Active Directory
Управление репликацией Active Directory
Спасибо! Отличная статья. Вот только момент:
«В качестве примечания, стоит отметить, что репликация FRS не соотносится с границами сайта. Таким образом, такая репликация затронет все контроллеры домена в течение всего лишь нескольких минут, не зависимо в каком сайте (пусть даже удаленном) находятся эти DC.» Либо я неправильно понял, либо неточность=) Есть 2 сайта, расписание репликации — 15 минут(собственно, минимальное время, доступное из GUI). Уровень домена 2003, соответственно используется FRS репликация. Создал пустой текстовый документ в Sysvol на DC из одного сайта — внутри сайта на каждом DC файл реплицировался мгновенно. А вот на DC в другом сайте — через 15 минут. Соответственно, репликация между сайтами происходит согласно расписанию межсайтовой репликации. Или я неправильно понял фразу «репликация FRS не соотносится с границами сайта»?))
Рубрики сайта
Последние статьи
09.01.2020
itpro
Windows Server 2012
комментариев 57
Распределенная файловая система DFS ( Distributed File System) – это технология, обеспечивающая возможности упрощения доступа к общим файловым ресурсам и глобальной репликации данных. Благодаря DFS распределённые по различным серверам общие ресурсы (каталоги и файлы) можно объединить в единую логическую UNC структуру, которая для пользователя выглядит, как единый сетевой ресурс. Даже при изменении физического местоположения целевой папки, это не влияет на доступ пользователя к ней.
Реализация служб DFS в Windows Server 2012 отличается от предыдущих версиях Windows. В первую очередь отметим, что технологии DFS в Windows Server 2012 реализованы в виде двух отдельных, независимых друг от друга служб — DFS Namespaces и DFS Replication , включенных в роль файлового сервера (File and Storage Services).
-
DFS Namespaces (DFSN или DFS-N) – пространство имен DFS. Позволяет объединять в единую логическую структуру общие папки, расположенные на различных серверах организации. Каждое пространство имен для пользователя выглядит как единая сетевая папка с подкаталогами. Реальная структура данного пространства имен DFS является скрытой от пользователя, и может включать в себя различные сетевые папки, расположенные на различных серверах и сайтах.
Репликация контейнера групповой политики
Контейнеры групповых политик (Group Policy Container -GPC) хранятся в Active Directory. В принципе GPC не содержит никаких настроек, т.к. вся параметры групповой политики хранятся в GPT. Контейнер Group Policy содержит всю ссылочную информацию для GPO, а именно путь к GPT, в том числе GUID объекта групповой политики, а также всю информацию о GPC в Active Directory.
Вы можете просмотреть все GPC и их свойства с помощью оснастки Active Directory Users and Computers (ADUC). В консоли ADUC, прежде всего необходимо включить отображение дополнительных функций (Advanced Features).
После чего, перейдите в раздел domainname>\System\Policies.
Здесь вы увидите полный список GUID, которые соответствуют GPC для каждого объекта групповой политики в домене.
Репликация GPC также вызывается любыми изменениями в настройках групповой политики, точно так же как в случае с GPT. Однако, репликация GPC не основана на проверке состояния объекта или на FRS. Репликация Group Policy Container, так же как и репликация других объектов Active Directory осуществляется при помощи механизма репликации Active Directory.
Репликации Active Directory по умолчанию использует два типа расписаний. Существует репликация между контроллерами домена, которые находятся в одном сайте, и межсайтовая репликация.
Для контроллеров домена в одном сайте репликация происходит каждые 15 секунд. Этот интервал не может быть изменен и контролируется механизмом проверки согласованности (Knowledge Consistency Checker — KCC).
Второй тип репликации по умолчанию происходит каждые 3 часа, и контролируется службой межсайтовой топологии — Intersite Topology Generator (ISTG). Этот интервал можно изменить, и в большинстве его нужно уменьшить для оптимизации распространения изменений между контроллерами доменов. Эти изменения можно произвести с помощью консоли Active Directory Sites and Services. Для этого нам нужно в ней выбрать требуемую связь между сайтами и настроить расписание.
Что такое репликация, и зачем она нужна
Само по себе, понятие репликации означает процесс синхронизации нескольких копий объекта. В нашем случае, таким объектом является сервер БД, а наибольшую ценность представляют собой сами данные. Если мы имеем два и более серверов, и любым возможным способом поддерживаем синхронизированный набор данных на них — мы реализовали репликацию системы. Даже ручной вариант с mysqldump -> mysql load — это также репликация.
Стоит понимать, что сама по себе репликация данных не имеет ценности, и является лишь инструментом решения следующих задач:
- повышение производительности чтения данных. С помощью репликации мы сможем поддерживать несколько копий сервера, и распределять между ними нагрузку.
- повышение отказоустойчивости. Репликация позволяет избавиться от единственной точки отказа, которой является одиночный сервер БД. В случае аварии на основном сервере, есть возможность быстро переключить нагрузку на резервный.
- распространение данных. В современную эпоху глобализации ваше приложение может обслуживать пользователей со всего мира, и мы хотим, чтобы жители и Сиднея, и Хельсинки имели минимальную задержку доступа к нему.
- распределение нагрузки. В случае, если БД обслуживает запросы разных типов (быстрые и легкие, медленные и тяжелые), может иметь смысл развести эти запросы по разным серверам, для увеличения эффективности работы каждого типа.
- тестирование новых конфигураций. С помощью репликации есть возможность проведения тестирования новых версий сервера БД, изменения параметров конфигурации, и даже изменения типов хранилища данных.
- резервное копирование. С помощью репликации есть возможность делать механизмы резервного копирования более гибкими и вносить меньше негативных эффектов в работающую систему.
Виды репликации
Существует два принципиально разных подхода к репликации: покомандная и построчная. В случае покомандной репликации, в журнал мастера протоколируются запросы изменения данных (INSERT, UPDATE, DELETE), а слейвы в точности воспроизводят те же команды у себя. При построчной же репликации в журнале окажутся непосредственно изменения строк в таблицах, и эти же фактические изменения применятся затем на слейве.
Как нет серебряной пули, так и каждый из этих методов имеет свои преимущества и недостатки. Покомандная репликация проще в реализации и понимании, снижает нагрузку на мастер и на сеть. Но тем не менее, покомандная репликация может приводить к непредсказуемым эффектам, при использовании недетерминированных функций, таких как NOW(), RAND(), и т.д. Могут быть также проблемы, вызванные рассинхронизацией данных между мастером и слейвом. Построчная же репликация приводит к более прогнозируемым результатам, так как фиксируются и воспроизводятся фактические изменения данных. Тем не менее этот метод может значительно увеличивать нагрузку на мастер-сервер, которому приходится фиксировать каждое изменение в журнале, и на сеть, через которую эти изменения распространяются.
В MySQL поддерживаются оба способа репликации, а дефолтный (можно сказать, что и рекомендуемый) изменялся в зависимости от версии. В современных версиях, например MySQL 8, по умолчанию используется построчная репликация.
Второй принцип разделения подходов к репликации — количество мастер-серверов. Наличие одного мастер сервера подразумевает, что только он принимает изменения данных, и является неким эталоном, с которого уже распространяются изменения на множество слейвов. В случае же с мастер-мастер репликацией мы получаем как и некоторый профит, так и проблемы. Один из плюсов, например, то, что мы можем давать удаленным клиентам из тех же Сиднея и Хельсинки одинаково быструю возможность записывать свои изменения в базу. Из этого исходит и главный недостаток, если оба клиента одновременно изменили одни и те же данные, чьи изменения считать окончательными, чью транзакцию коммитить, а чью откатывать.
Также, стоит отметить, что наличие мастер-мастер репликации в общем случае не может увеличить производительность записи данных в системе. Представим, что наш единственный мастер может обрабатывать до 1000 запросов в единицу времени. Добавив к нему реплицируемый второй мастер, мы не сможем обрабатывать по 1000 запросов на каждом из них, так как кроме обработки “своих” запросов, им придется применять изменения, сделанные на втором мастере. Что в случае покомандной репликации сделает суммарно возможную нагрузку на оба не больше, чем на самый слабый из них, а с построчной репликацией эффект не совсем предсказуемый, может быть как положительный, так и отрицательный, в зависимости от конкретных условий.
Установка репликации DFS с помощью Windows PowerShell
Откройте сеанс Windows PowerShell с правами привилегированного пользователя, после чего введите следующую команду, где — служба роли или компонент, которые требуется установить (см. следующую таблицу со списком соответствующих имен служб ролей или компонентов).
Служба роли или компонент | Название |
---|---|
Репликация DFS | FS-DFS-Replication |
Средства управления DFS | RSAT-DFS-Mgmt-Con |
Например, для установки средств распределенной файловой системы, включенных в компонент средств удаленного администрирования сервера, введите:
Для установки таких частей компонента средств удаленного администрирования сервера, как "Репликация DFS" и "Средства распределенной файловой системы", введите:
Редкая современная продакшн система обходится без репликации баз данных. Это мощный инструмент на пути к повышению производительности и отказоустойчивости системы, и современному разработчику очень важно иметь хотя бы общее представление о репликации. В данной статье я поделюсь базовыми знаниями о репликации, и покажу простой пример настройки репликации в MySQL с помощью Docker.
Запуск репликации GP по триггеру
Такой триггер репликации срабатывает в случае изменения настроек объекта GPO. Это может быть изменение любого из более чем 5000 параметров групповых политик в Windows Server 2008. Изменение может произойти как в секции конфигурации компьютера так и в секции конфигурации пользователя, любое такое изменение вызовет репликацию group policy!
Система раздельно отслеживает такой запуск при изменении настроек в политике компьютеров и пользователей. Если вы посмотрите на детали GPO в консоли управления групповыми политиками (GPMC), вы увидите, что существует список версий настроек компьютеров и пользователей.
Когда происходит изменение в любой части GPO, изменяется номер версии (он увеличивается) соответственной части групповой политики.
В том случае, если редактирование GPO ведется с помощью Group Policy Management Editor (GPME), тогда по умолчанию используется контроллер домена, выполняющий роль эмулятора PDC. Таким образом, все репликации будут вытекать из этого контроллера домена. Если выбран другой контроллер домена (его можно выбрать в консоли управления групповой политикой), в этом случае репликация начнется с этого контроллера домена.
Добавление дополнительного DFS сервера
В доменное пространство имен DFS можно добавить дополнительный сервер (пункт меню Add Namespace Server), который его будет поддерживать. Делается это для увеличения доступности пространства имен DFS и позволяет разместить сервер пространства имен в том же сайте, в котором находится пользователи.
Установка служб DFS в Windows Server 2012
Установить службы DFS можно с помощью консоли Server Manager или же при помощи Windows PowerShell.
Как мы уже говорили, службы DFS являются элементами роли Files and Storage Services:
Но проще и быстрее установить все DFS службы и консоль управления DFS с помощью PowerShell:
, где FS-DFS-Namespace – служба DFS Namespaces
FS-DFS-Replication – служба репликации DFS Replication
RSAT-DFS-Mgmt-Con– mmc консоль управления службами DFS — DFS Management Tools (также входит в состав Remote Server Administration Tools для Windows 10)
Установка репликации DFS
Репликация DFS входит в роль "Файловые службы и службы хранилища". Средства управления для DFS ("Управление DFS", модуль репликации DFS для Windows PowerShell, а также средства командной строки) устанавливаются отдельно в составе средств администрирования удаленного сервера.
Репликацию DFS можно установить с помощью Windows Admin Center, диспетчера сервера или PowerShell, как описано в следующих разделах.
Настройка DFS-репликации на Windows Server 2012
Технология репликации DFS-R предназначена для организации отказоустойчивости пространства имен DFS и балансировки нагрузки между серверами. DFS-R автоматически балансирует трафик между репликами в зависимости от их загрузки и в случае недоступности одного из серверов перенаправляет клиентов на другой сервер-реплику. Но прежде, чем говорить о DFS репликации и ее настройке в Windows Server 2012перечислим основные системные требования и ограничения:
- Служба DFS Replication должна быть установлена на всех серверах, которые планируется включить в группу репликации
- Все сервера в группе репликации должны находиться в одном лесу AD
- Уровень леса Active Directory должен быть как минимум Windows Server 2003 R2 (при установке первого домена контроллера на Windows Server 2012 схема обновляется автоматически).
- Функциональный уровень домена — как минимум Windows Server 2008
- Необходимо убедиться, что антивирусное обеспечение на файловых серверах совместимо с технологией репликации DFS
- Реплицируемые каталоги должны располагаться на томах с файловой системой NTFS (файловые системы ReFS и FAT не поддерживаются). Также не поддерживается репликация данных, хранящихся на on Cluster Shared Volumes
В консоли DFS Managment выберите нужный вам DFS Namespace и щелкните ПКМ по каталогу, для которого необходимо создать реплику и выберите пункт Add Folder Target.
И укажите полный (UNC) путь к сетевому каталогу другого сервера, в котором и будет храниться реплика.
На вопрос хотите ли вы создать группу репликации отвечаем Yes.
Запускается мастер настройки репликации. Проверяем имя группы репликации и каталог.
Указываем первичный (Primary) сервер. Именно этот сервер будет источником данных при инициальной (первичной) репликации.
Затем выбираем тип топологии (соединения) между членами группы репликации. В нашем примере выбираем Full Mesh (все со всеми).
И, наконец, указываем расписание репликации и параметры bandwidth throttling – ограничение доступной для репликации полосы пропускания.
После окончания работы мастера, запуститься первоначальная синхронизация.
В случае необходимости, настройки расширенных параметры расписания репликации и максимальную полосу пропускания под данный трафик, можно задать в ветке Replication.
04.09.2012
itpro
Active Directory
комментарий 41
Напомним, что каталог Sysvol присутствует на всех контроллерах домена Active Directory и используется для хранения логон скриптов и объектов групповых политик (подробнее о репликации в Active Directory можно почитать тут). В том случае, если вы развернули новый домен с нуля на функциональном уровне Windows Server 2008, то для репликации каталога SYSVOL используется механизм репликации DFS ( Особенности и преимущества DFS ).
Если же функциональный уровень домена Windows Server 2003 (или ниже), то для репликации SYSVOL используется служба FRS. После того, как функциональный уровень домена поднят до Windows Server 2008, то для репликации объектов AD можно использовать DFS, но только осуществив процедуру миграции, о которой мы и поговорим.
Узнаем текущий тип репликации
1.На контроллере домена с правами администратора домена откройте mmc консоль adsiedit.msc.
2. Жмем правой кнопкой по ADSIEdit и выбираем Connectto.
3. Указываем Select a well known Naming Context и Default naming context.
?
4. Жмем OK.?
5. Развернем элемент Default Naming Context -> Domain Name — > CN=System -> CN=File Replication Service
6. Т.е. сейчас для репликации SYSVOL используется механизм File Replication Service
- Все контроллеры домена должны быть обновлены до функционального уровня Windows Server 2008 или выше
- Перед процедурой миграции необходимо выполнить принудительную полную миграцию разделов Active Directory на каждом из контроллеров домена, выполнив команды:
Устанавливаем роль DFS
На всех контроллерах домена устанавливаем роль DFS командой:
Проверим состояние службы DFS, выполнив команды:
1. Установим флаг подготовки к миграции (global state:
Prepared), выполнив команду:
2. Текущее состояние контроллеров проверим командой:
В том случае, если хотя бы у одного из контролеров состояние не изменится на Prepared, не переходите к следующему шагу!
Принудительно запустить репликации DFS и AD, можно командами:
3. Запустите консоль ADSI Edit, и перейдите в
раздел
Default naming context ->Domain name-> CN=System — > CN=DFSR-GlobalSettings
Как вы видите, появился новый раздел, который будет использоваться для управления репликацией.
4. Запустите редактор реестра и перейдите в ключу
HKLM\SYSTEM\CurrentControlSet\Services\DFSR\Parameters\Sysvols\Migrating sysVols\Local State
Значение: Local State = 1 говорит о том, что текущий статус — Prepared.
5. Перейдем к ключу HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\SysVol
Как вы видите, AD все еще использует папку SYSVOL
6. Служба DFS в каталоге %WINDIR% должна создать полную копию каталога SYSVOL с именем SYSVOL_DFSR
Перенаправление продуктивной папки
-
Прежде чем перейди к следующему этапу миграции (состояние Redirected), необходимо убедиться что:
1. Перейдем к следующему этапу миграции, набрав
2. Убедимся, что все контроллеры домена находятся в статусе Redirected:
?3. В редакторе реестра проверим, что LocalState=2 и SYSVOL= C:\windows\SYSVOL_DFSR\sysvol.
?Удаляем старый каталог SYSVOL ?
Примечание ! Процесс удаления («Eliminated«) не может быть отменен!
Прежде чем перейди в режим Elminated, необходимо убедиться что:
- Все контроллеры домена находятся в статусе Redirected
- Шара SYSVOL все еще доступна
1. Набираем команду:
2. Проверяем статус командой:
?В результате каталог SYSVOL будет мигрирован в папку SYSVOL_DFSR. И теперь для репликации шары SYSVOL применяется механизм DFS.
Предыдущая статья Следующая статья
Запрос к Active Directory из Excel
Создание WMI фильтров для групповых политик (GPO) в домене AD
Установка программ с помощью групповых политик в домене Active Directory
Управление репликацией Active Directory
После проделанной работы по Вашей статье в журнале постоянно регистрируется ошибка с кодом 13575
«Этот контроллер домена был мигрирован с целью использования службы репликации DFS для репликации общего ресурса SYSVOL. Использование службы репликации файлов для репликации наборов содержимого, не являющегося содержимым SYSVOL, было отключено, и поэтому служба была остановлена. Для репликации папок, общего ресурса SYSVOL на контроллерах домена и объектов ссылок DFS рекомендуется использовать службу репликации DFS.»
Сергей Проверьте что на контроллере домена созданы и расшарены папки NETLOGON & SYSVOL.
Вопрос такой — была настроена довольно давно репликация по SYSVOL по DFS на 3-х контроллерах. Вылетел один контроллер, причем напрочь, пришлось чистить AD через ADSIedit. В общем ставился на чистую, так как ни system state ни точек восстановления не осталось. Теперь у меня на двух контроллерах папки DFSR_SYSVOL, а на восстановленом соотв. просто SYSVOL.
На запрос dfsrmig /getmigrationstate отвечает, что все контроллеры успешно перешли в глобальное состояние «Удалено», т.е. пройдена стадия 3. В ADSI тоже все прописано как репликация по DFS, но на восттановленом контроллере в реестре нет ветки DFSR вообще. Так вот вопрос — надо все-таки как-то добиваться появления папки DFSR_SYSVOL на восстановленом контроллере или нет? Репликация при этом идет прекрасно между всеми контроллерами.
Если состояние контроллеров домена — ELIMINATED, это означает, что репликация DFS станала единственным механизмом репликации, а FRS отключен. ИМХО, если репликация идет, и в логах ошибок нет, не парьтесь
Имеются лес (повышенный с 2003 до 2008 уровня) и 2 домена.
Все DC 2008 R2 и недавно был добавлен DC 2012 R2.
repadmin /replsum нет ошибок в реплике.
Вопрос: как проверить по какому протоколу реплики FSRили DFSR?
Достаточно ли комманды dfsrmig /GetGlobalState ?
И с какого DC ее запускать ,что бы проверить все контроллеры ?
На любом контроллере домена выполните команду:
dfsrmig /GetGlobalState
Если она вернет:
Current DFSR global state: ‘Eliminated’
Succeeded.
— все ОК за репликацию отвечает служба DFS.
Также можно определить текущего провайдера репликации как описано в статье: с помощью adsiedit.msc.
Windows 2012 R2 в качестве контроллеров домена
и …
C:\>ServerManagercmd -iFS-DFS
‘ServerManagercmd’ is not recognized as an internal or external command,
operable program or batch file.
и как? что не так делаю?
Командную строку с повышением прав попробуйте.
Просто спасибо за статью
Пошагово сделал — и наслаждаюсь
Спасибо ещё раз
Свою проблему решил случайно (коммент от 01.05.3013). В GPO в разделе «системные службы» остался, наверное, от старого КД автоматическй запуск и, не смотря на то, что frs была отключена, система всеравно пыталась ее запустить.
Вопрос такой: А зачем это вообще нужно. Что будет, если оставить репликацию в режиме FRS?
У меня контроллер домена повышен с 2003 до 2008. Репликация SYSVOL нормально работает в режиме FRS. По опыту знаю, что начнёшь что-то менять в такой сложной системе, как AD, поимеешь кучу проблем. Так стоит ли это делать, если и так всё работает?
Добрый день. Некоторые технологии, такие как DirecrAccess, требуют DFS-R. Также технология экономит трафик репликации между серверами. В принципе, если инфраструктура небольшая, FRS подходит.
кроме того на DC под 2016 фрс забанена окончательно
Windows Server 2016 RS3 no longer supports FRS: Windows Server 2016 RS3 can no longer be added as an Active Directory domain controller (DC) to an existing domain that is still using File Replication Service (FRS) for replication of the SYSVOL share.
Для перехода на DFS репликацию, можно ли сразу поднимать уровень работы домена и леса с 2003 до 2012 R2 или лучше сначала повысить до 2008, перейти на DFS и затем уже повышать до 2012 R2 ?
Можно сразу повысить уровень домена до 2012 R2, а после этого уже перейти на DFSR репликацию.
Ещё прошу помощи со следующей проблемой т.к. нагуглить ничего не смог.
Был домен с работающими контроллерами домена на Windows Server 2008 и 2008 R2, а ещё ранее видимо на 2003 т.к. режим работы домена 2003.
В строй введены новые контроллеры на Windows Server 2012 R2.
Старые контроллеры понижены в ролях и с них удалены службы AD, DNS, DHCP.
При понижении роли(через dcpromo) была ошибка удаления делегирования в DNS (видимо из-за того что первичным DNS на них был 127.0.0.1).
Теперь в записях DNS домена в разделах DomainDnsZones и ForestDnsZones наблюдаю записи с IP адресами старых контроллеров.
Вопросы:
Что это за записи и нужны ли они?
Можно ли удалять их вручную или делать это нужно через adsiedit ?
Если через adsiedit, то где именно их можно найти(я не смог найти подобных записей) ?
Буду благодарен за грамотный и полный ответ.
Спасибо!
В AD остались записи старых контроллеров домена (компьютеров)?
Попробуйте выполнить поиск удаленных DC по имени
dsquery * -filter «(Name=DC01)»
Если ничего не будет найдено, и у зон DomainDnsZones / ForestDnsZones имеются корректные настройки новых серверох, старые можно удалить руками в консоли DNS.
В AD есть записи о старых контроллерах, но они там в разделе «Computers», а не «Domain Controllers»
Один из контроллеров полностью отключен, второй работает в качестве сервера KSC(Kaspersky Security Center)
В DomainDnsZones/ForestDnsZones есть IP новых контроллеров тоже.
Просто удалите адреса старых DC из зон DomainDnsZones/ForestDnsZones. Ну и изучите подробнее журналы DC и ошибки репликации, может где еще и всплывут старые сервера.
Спасибо!
В журналах на данный момент нет ошибок.
Спасибо за статью, делал по ней, всё завелось. Одна из самых подробных в рунете!
Огромное спасибо за статью
Имеется единственный КД под 2016. Ести старые тачки под winxp в домене. Если я совершу миграцию на DFS, то смогут ли пользователи со старых тачек авторизороваться в домене?
Насколько я помню, Windows XP поддерживали DFS — мне кажется не будет проблем при миграции. Главное, чтобы на DC не отключали SMBv1
ServerManagercmd -iFS-DFS это полная лажа. Рекомендую как минимум убрать ее и сказать что необходима установка службы «Репликация DFS» из роли «Файловые службы».
Как максимум убедится что ServerManagercmd должен как минимум иметь аргумент «install»
dfsrmig /get/GlobalStatedfsrmig /getMigrationState ребята — тупая копи-паста еще никогда и никого до добра не доводила! Исправляем:
dfsrmig /getGlobalState
dfsrmig /getMigrationState
Некоторый команды поправил.Спасибо. Но! статья 2012 года, версия Windows Server 2008 🙂 Не актуализировал до сих пор… каюсь.
У вас явно что-то новее )
Статья хоть и старая, но до сих пор актуальная!
Немало доменов переехавших с 2003 не завершили миграцию до сих пор…
Я вот например о репликации «вспомнил» только при попытке добавить еще один DC на 2019 😉
Если скриншотики, команды и краткое описание новых для моментов пришлете — с удовольствием обновлю статью. 🙂
аналогично
repadmin /syncall Aed
меняем на
repadmin /syncall /Aed
Я тоже споткнулся на этом месте.
Озадачил вопрос необходимости установки роли FS-DFS (т.е. ролей «Пространства имен DFS» и «Репликация DFS»).
На всех контролерах домена 2008 R2 и 2012 R2, какие есть под рукой — эти две службы уже присутствуют и работают, а консоль Server Manager говорит, что роли не установлены.
По факту эти службы установились еще в момент повышения каждого контроллера домена
И поэтому вопрос — реально ли нужно устанавливать их еще раз именно как роли?
Не думаю, что это хорошая идея — не трогайте DFS на DC. 🙂
Так ведь статья призывает трогать:
На всех контроллерах домена устанавливаем роль DFS командой:
ServerManagercmd -i FS-DFS
А по факту службы DFS там уже есть. Отсюда и возник мой вопрос
Добрый день. Правильно ли я понимаю, что папка SYSVOL_DFSR появится только на DC , которые апгрейдились с 2003 режима? В домене, например, который изначально разворачивался на 2008 R2 я наблюдаю просто папку SYSVOL.
Да, SYSVOL_DFSR это следы от старого домена с FRS репликацией.
Начиная с 2008R2 используется DFSR для репликации sysvol
Добрый вечер!
Хочу перенастроить репликацию на DFS. Есть 2 контроллера на 2008 R2 (мигрировал с 2003).
Поднял функциональный уровень домена и леса до 2008 R2.
Начал миграцию, выполнил команды Dfsrmig /setglobalstate 1 и Dfsrmig /setglobalstate 2.
Сейчас имею такое состояние:
Dfsrmig /getmigrationstate
Все контроллеры домена успешно мигрировали в глобальное состояние («Перенаправлено»).
Состояние миграции согласовано на всех контроллерах домена.
Успешно.
Планирую переводить в состояние «Удалено», но хотелось уточнить пару моментов.
Можно ли посмотреть какой-нибудь командой или в логах, какие клиенты подключаются к КД используя протокол SMB1 (для доступа на SYSVOL)?
В сети имеем клиентов на windows XP, потеряют ли они возможность аутентификации при переходе на FRS?
Я так понимаю, что по умолчанию SMB1 включен на 2008 R2, специально я его не отключал.
Команда по проверке возвращает это:
sc.exe query mrxsmb10
Имя_службы: mrxsmb10
Тип : 2 FILE_SYSTEM_DRIVER
Состояние : 4 RUNNING
(STOPPABLE, NOT_PAUSABLE, IGNORES_SHUTDOWN)
Код_выхода_Win32 : 0 (0x0)
Код_выхода_службы : 0 (0x0)
Контрольная_точка : 0x0
Ожидание : 0x0
и так:
Get-Item HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters | ForEach-Object
PSPath : Microsoft.PowerShell.Core\Registry::HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Service
s\LanmanServer\Parameters
PSParentPath : Microsoft.PowerShell.Core\Registry::HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Service
s\LanmanServer
PSChildName : Parameters
PSProvider : Microsoft.PowerShell.Core\Registry
ServiceDll : C:\Windows\system32\srvsvc.dll
ServiceDllUnloadOnStop : 1
EnableAuthenticateUserSharing : 0
NullSessionPipes :
autodisconnect : 15
enableforcedlogoff : 1
enablesecuritysignature : 1
requiresecuritysignature : 1
restrictnullsessaccess : 1
Lmannounce : 0
Size : 3
AdjustedNullSessionPipes : 3
Guid :
Пример построения простой репликации в MySQL
А сейчас настало время создать простую конфигурацию репликации в MySQL. Для этого мы будем использовать Docker и MySQL образы из dockerhub, а также базу данных world.
Для начала, запустим два контейнера, один из которых позже настроим как мастер, а второй — как слейв. Объединим их в сеть, чтобы они могли обращаться друг к другу.
Для мастер контейнера указано подключение volume c дампом world.sql, для того, чтобы имитировать наличие некоторой начальной базы на нем. При создании контейнера, mysql загрузит и выполнит sql скрипты, размещенные в директории docker-entrypoint-initdb.d.
Для работы с конфигурационными файлами, нам потребуется текстовый редактор. Можно использовать любой удобный, я предпочитаю vim.
Первым делом, создадим учетную запись на мастере, которая будет использоваться для репликации:
Далее, изменим конфигурационные файлы для мастер-сервера:
В файл my.cnf в секции [mysqld] необходимо добавить следующие параметры:
При включении/выключении двоичного журнала необходима перезагрузка сервера. В случае с Docker перезагружается контейнер.
Убедимся, что двоичный журнал включен. Конкретные значения, такие как имя файла и позиция, могут отличаться.
Для того, чтобы начать репликацию данных, необходимо “подтянуть” слейв до состояния мастера. Для этого, нужно временно заблокировать сам мастер, чтобы сделать слепок актуальных данных.
Далее, с помощью mysqldump сделаем экспорт данных из базы. Конечно, в данном примере можно использовать тот же world.sql, но приблизимся к более реалистичному сценарию.
После этого, необходимо еще раз выполнить команду SHOW MASTER STATUS, и запомнить или записать значения File и Position. Это, так называемые координаты двоичного журнала. Именно от них мы далее укажем стартовать слейву. Начиная с MySQL 5.6 стало возможным использование глобальных идентификаторов транзакций GTID вместо координат в виде файл-позиция. Это упростило настройку репликации, а также повысило стабильность ее работы. Но рассмотрение этой темы выходит за рамки данной статьи, и с ней можно ознакомиться в документации.
Теперь можем снова разблокировать мастер:
Мастер настроен, и готов реплицироваться на другие сервера. Перейдем теперь к слейву. Первым делом, загрузим в него дамп, полученный с мастера.
А затем изменим конфиг слейва, добавив параметры:
После этого перезагрузим слейв:
И теперь нам нужно указать слейву, какой сервер будет являться для него мастером, и откуда начинать реплицировать данные. Вместо MASTER_LOG_FILE и MASTER_LOG_POS необходимо подставить значения, полученные из SHOW MASTER STATUS на мастере. Эти параметры вместе называются координатами двоичного журнала.
Запустим воспроизведение журнала ретрансляции, и проверим статус репликации:
Если все прошло успешно, ваш статус должен иметь аналогичный вид. Ключевые параметры здесь:
- Slave_IO_State, Slave_SQL_State — состояние IO потока, принимающего двоичный журнал с мастера, и состояние потока, применяющего журнал ретрансляции соотвественно. Только наличие обоих потоков свидетельствует об успешном процессе репликации.
- Read_Master_Log_Pos — последняя позиция, прочитанная из журнала мастера.
- Relay_Master_Log_File — текущий файл журнала мастера.
- Seconds_Behind_Master — отставание слейва от мастера, в секундах.
- Last_IO_Error, Last_SQL_Error — ошибки репликации, если они есть.
И проверить, появились ли они на слейве.
Отлично! Внесенная запись видна и на слейве. Поздравляю, теперь вы создали свою первую репликацию MySQL!
Как MySQL реплицирует данные
Процесс репликации подразумевает собой распространение изменений данных с главного сервера (обычно он называется как мастер, master), на один или более подчиненных серверов (слейв, slave). Существуют и более сложные конфигурации, в частности с несколькими мастер-серверами, но для каждого изменения на конкретном мастер-сервере остальные мастера условно становятся слейвами, и потребляют эти изменения.
В общем виде, репликация в MySQL состоит из трех шагов:
- Мастер-сервер записывает изменения данных в журнал. Этот журнал называется двоичным журналом (binary log), а изменения — событиями двоичного журнала.
- Слейв копирует изменения двоичного журнала в свой, который называется журналом ретрансляции (relay log).
- Слейв воспроизводит изменения из журнала ретрансляции, применяя их к собственным данным.
Чтобы установить DFS с помощью диспетчера серверов
Откройте диспетчер серверов, щелкните Управление, а затем нажмите кнопку Добавить роли и компоненты. Откроется мастер добавления ролей и компонентов.
На странице Выбор сервера выберите сервер или виртуальный жесткий диск автономной виртуальной машины, на который требуется установить DFS.
Выберите службы ролей и компоненты, которые следует установить.
Чтобы установить службу репликации DFS", на странице Роли сервера выберите Репликация DFS.
Чтобы установить только средства управления DFS, на странице Компоненты разверните узлы Средства администрирования удаленного сервера, Средства администрирования ролей, Средства файловых служб, а затем выберите Средства управления DFS.
Компонент Средства управления DFS устанавливает оснастку "Управление DFS", модули "Пространства имен DFS" и "Репликация DFS" для Windows PowerShell, а также средства командной строки, но не устанавливает на сервер никаких служб DFS.
Заключение
Надеюсь, что в рамках данной статьи мне удалось дать базовое понимание процессов репликации, ознакомить с применением данного инструмента, и попробовать самостоятельно реализовать простой пример репликации в MySQL. Тема репликации, и ее практического применения крайне обширна, и если вас заинтересовала данная тема, могу порекомендовать к изучению следующие источники:
09.01.2020
itpro
Active Directory, Групповые политики
Один комментарий
Репликация групповой политики в Active Directory контролируется двумя различными механизмами репликации: FRS и репликацией Active Directory. Попробуем поговорить об этих технологии поподробнее.
Групповые политики стали важным и удобным инструментом управления парком ПК и серверов в Active Directory, в связи с чем системный администратор должен разбираться в тонкостях работы групповых политик ( Смотри статью о типовых проблемах при применении GPO). В состав технологии групповых политик входят различные составляющие, в том числе такие клиентские расширения, как файлы ADM/ADMX файлы, GPC, GPT и многие другое. При каком-либо изменении групповой политики, это изменение происходит только на одном контроллере домена, а следовательно, информация об этом изменении в объекте групповой политики должны быть скопирована на все оставшиеся контроллеры домена. Такой механизм репликации задействует несколько различных технологий репликации, и в случае некорректного завершения, может вызвать существенные проблемы. В этой статье мы обсудим процесс репликации групповых политик, и так же действия, позволяющие удостовериться в корректности выполнения репликации.
Читайте также: