Программы для репликации файлов
В этой статье объясняется, как с помощью программы командной строки Robocopy.exe выполнять предварительное заполнение файлов при настройке репликации распределенной файловой системы (DFS) (DFSR или DFS-R) в Windows Server. Предварительное заполнение файлов перед настройкой репликации DFS, репликация нового партнера или замена сервера ускоряют начальную синхронизацию и позволяют включить клонирование базы данных репликации DFS в Windows Server 2012 R2. Robocopy — это один из нескольких инструментов для предварительного заполнения (см. сведения о предварительном заполнении файлов для репликации DFS).
Программа командной строки Robocopy (Robust File Copy) входит в состав Windows Server. Программа предоставляет широкие возможности, в том числе копирование протоколов безопасности, поддержку API резервного копирования, преимущества повторных попыток и ведение журнала. Более поздние версии включают в себя поддержку многопоточности, а также операций ввода-вывода без буферизации.
Программа Robocopy не копирует монопольно заблокированные файлы. Если пользователи предпочитают блокировать множество файлов на файловых серверах на длительное время, попробуйте использовать другой метод предварительного заполнения. Предварительное заполнение не требует идеального соответствия между списками файлов на исходном и целевом серверах. Но чем меньше файлов существует при начальной синхронизации для репликации DFS, тем более эффективным будет предварительное заполнение. Чтобы избежать конфликтов блокировок, старайтесь использовать Robocopy в своей организации в нерабочее время. Чтобы узнать, какие файлы пропущены из-за монопольных блокировок, обязательно просматривайте журналы Robocopy после предварительного заполнения.
Для предварительного заполнения файлов для репликации DFS с помощью Robocopy выполните следующие действия:
Предварительные условия
Предварительное заполнение не подразумевает прямой репликации DFS. Поэтому важно выполнить требования к копированию файлов с помощью программы Robocopy.
Вам потребуется учетная запись участника локальной группы администраторов на исходном и целевом серверах.
Установите последнюю версию программы Robocopy на сервере, который будет использоваться для копирования файлов — или на исходном, или на целевом сервере. Необходимо также установить самую последнюю версию операционной системы. См. инструкции в разделе Шаг 2. Стабилизация файлов, которые будут реплицированы. Если вы выполняете предварительное заполнение файлов с сервера не под управлением Windows Server 2003 R2, программу Robocopy можно запустить на исходном или целевом сервере. На целевом сервере, на котором обычно установлена последняя версия операционной системы, предоставляется доступ к самой последней версии программы Robocopy.
Убедитесь, что на целевом диске достаточно места для хранения. Не создавайте папку с путем, по которому планируется копировать файлы. Программа Robocopy должна создать корневую папку.
Выбирая объем пространства, которое нужно выделить для предварительно заполненных файлов, следует учитывать ожидаемое увеличение объема данных с течением времени и требования к хранилищу для репликации DFS. Дополнительные сведения см. в статьях Edit the Quota Size of the Staging Folder and Conflict and Deleted Folde (Изменение размера квоты промежуточной папки и папки конфликтов и удаленных объектов) и Managing DFS Replication (Управление репликацией DFS).
На исходном сервере при необходимости установите монитор процессов или обозреватель процессов, чтобы использовать его для проверки приложений, блокирующих файлы. Сведения о скачивании см. в статье Process Monitor v3.53 (Монитор процессов версии 3.53) и Process Explorer v16.31 (Обозреватель процессов версии 16.31).
Шаг 1. Скачивание и установка последней версии программы Robocopy
Прежде чем выполнять предварительное заполнение файлов с помощью программы Robocopy, скачайте и установите последнюю версию файла Robocopy.exe. Таким образом репликация DFS не пропустит файлы из-за проблем в коммерческих версиях программы Robocopy.
Источник последней совместимой версии программы Robocopy зависит от версии Windows Server, которая работает на сервере. Сведения о скачивании исправления с последней версией программы Robocopy для Windows Server 2008 R2 или Windows Server 2008 см. в статье List of currently available hotfixes for Distributed File System (DFS) technologies in Windows Server 2008 and in Windows Server 2008 R2 (Список доступных исправлений для технологий распределенной файловой системы (DFS) в Windows Server 2008 и Windows Server 2008 R2).
Кроме того, выбрать и установить последнее исправление для операционной системы можно, выполнив следующие действия.
Поиск и установка последней версии программы Robocopy для конкретной версии Windows Server
В поле Поиск справки введите следующую строку, заменив <operating system version> соответствующей операционной системой, а затем нажмите клавишу ВВОД:
robocopy.exe kbqfe "<operating system version>"
Например, введите robocopy.exe kbqfe "Windows Server 2008 R2" .
Найдите и скачайте исправление с наибольшим номером идентификатора (то есть последнюю версию).
Установите исправление на сервере.
Шаг 2. Стабилизация файлов, которые будут реплицированы
После установки на сервере последней версии программы Robocopy не следует предотвращать копирование заблокированных файлов с помощью методов, описанных в таблице ниже. Большинство приложений не выполняют монопольную блокировку файлов. Но при нормальной работе на файловых серверах может быть заблокирован небольшой процент файлов.
Попробуйте временно установить доступ только для чтения к общим папкам, которые будут реплицироваться с помощью командлетов Windows PowerShell Grant-SmbShareAccess и Close-SmbSession. Если вы настроили разрешения на чтение для общей группы, например для всех пользователей или прошедших проверку подлинности, менее вероятно, что обычные пользователи будут открывать файлы и создавать монопольные блокировки (если их приложения обнаружат доступ только для чтения при открытии файлов).
Шаг 3. Копирование реплицированных файлов на целевой сервер
Сократив количество блокировок реплицируемых файлов, можно выполнить начальное заполнение файлов с исходного сервера на целевой.
Программу Robocopy можно запустить на исходном или целевом компьютере. Следующая процедура описывает запуск программы Robocopy на целевом сервере, который обычно работает под управлением операционной системы последней версии, что позволяет воспользоваться всеми самыми новыми возможностями Robocopy, доступными с такой ОС.
Предварительное заполнение реплицированных файлов на целевой сервер с помощью программы Robocopy
Войдите на целевой сервер, используя учетную запись участника локальной группы администраторов на исходном и целевом серверах.
Откройте командную строку с повышенными привилегиями.
Чтобы реализовать предварительное заполнение файлов с исходного на целевой сервер, выполните следующую команду, подставив собственные пути к источнику, назначению и файлам журналов вместо значений в квадратных скобках:
Эта команда копирует все содержимое исходной папки в целевую со следующими параметрами:
Например, следующая команда реплицирует файлы из исходной реплицированной папки, E:\RF01, на диск данных D на целевом сервере:
При предварительном заполнении файлов для репликации DFS с помощью программы Robocopy мы рекомендуем использовать параметры, описанные выше. Некоторые из значений можно изменить или можно добавить дополнительные параметры. Например, в ходе тестирования может оказаться, что вы можете установить более высокое значение (количество потоков) для параметра /MT. Кроме того, если вы в основном реплицируете файлы большего размера, можно увеличить производительность копирования, добавив параметр /j для операций ввода-вывода без буферизации. Дополнительные сведения о средстве Robocopy см. на странице справочника по командной строке Robocopy.
Чтобы избежать возможной потери данных предварительном заполнении файлов для репликации DFS с помощью программы Robocopy, не вносите в рекомендуемые параметры следующие изменения:
- Не используйте параметр /mir (который производит зеркальное отражение дерева каталогов) или параметр /mov (который перемещает файлы, а затем удаляет их из источника).
- Не удаляйте параметры /e, /b и /copyall.
После завершения копирования проверьте журнал на наличие ошибок или пропущенных файлов. Используйте программу Robocopy, чтобы скопировать пропущенные файлы по отдельности вместо копирования всего набора файлов. Если файлы пропущены из-за монопольных блокировок, попробуйте скопировать отдельные файлы с помощью программы Robocopy позже или учтите, что эти файлы потребуется реплицировать по проводной сети с помощью репликации DFS во время начальной синхронизации.
Далее
После начального копирования и последующего решения проблем с максимально возможным количеством пропущенных файлов с помощью программы Robocopy используйте командлет Get-DfsrFileHash в Windows PowerShell или команду Dfsrdiag. Это позволит проверить предварительно заполненные файлы путем сравнения хэшей файлов на исходном и целевом серверах. Подробные инструкции см. в статье Step 2: Шаг 2. Проверка предварительно заполненных файлов для репликации DFS.
Delphi site: daily Delphi-news, documentation, articles, review, interview, computer humor.
Программа RepliStor, разработанная компанией LEGATO (после приобретения компании Octopus), предназначена для синхронной репликации данных на уровне файлов и каталогов. Программа пытается копировать файлы (и синхронизировать их) для сохранения производительности и обеспечения отказоустойчивости. Кроме того, предоставляется возможность репликации разделов системного реестра.
Программа RepliStor поддерживает указание списков файлов, каталогов или общих ресурсов, а также исключений из этих списков, которые не будут подвергаться репликации. Кроме того, RepliStor поддерживает репликацию открытых файлов, если они были указаны до открытия другими приложениями. Также поддерживается репликация общих ресурсов распределенной файловой системы Windows NT 4.0, однако репликация общих ресурсов распределенной файловой системы Windows 2000 не обеспечивается. Версия RepliStor для Windows 2000 поддерживает интеграцию в Active Directory. После репликации файла RepliStor копирует только изменения, внесенные в файл.
Программа RepliStor может быть настроена на использование выделенного сетевого адаптера, что дает возможность изолировать сетевые данные RepliStor. Более того, передаваемые по сети данные шифруются, а каждый сетевой пакет поддерживает цифровую подпись. '
Описываемая программа поддерживает репликацию “точка-точка” или “точка-множество”. Точкой назначения может быть другой сервер под управлением Windows NT (работающий с другим аппаратным обеспечением) или член кластера. Источником репликации также может быть член кластера. Программа RepliStor проводит репликацию асинхронно, т.е. запросы записи на удаленный узел размещаются в очереди, а запросы записи на локальный узел выполняются без подтверждения с удаленного узла.
Программа RepliStor дополняет другие системы компании LEGATO, например Co-StandbyServer, которая не в состоянии зеркально отражать системные диски (диски, с которых загружается Windows NT). Поскольку RepliStor обеспечивает репликацию на уровне файлов и каталогов, поддерживается копирование и системных дисков.
Кроме все прочего, предоставляется настраиваемый таймер, по которому вторичная система отправляет тестовые эхо-пакеты системе-источнику. Если доставка тестового пакета завершится неудачно, вторичная система сначала отправляет тестовый эхо-пакет по протоколу ICMP; это позволяет убедиться, что основная система действительно неисправна.
Если обращение к основной системе завершилось неудачно, RepliStor предоставляет следующие настраиваемые варианты действий:
Рис. 9.21. Архитектура программы Co-StandbyServer
9.4.3 Программа Co-StandbyServer
Программа Co-StandbyServer от LEGATO представляет собой кластерную систему для платформы Windows NT. Каждый сервер в кластере может быть активным, и изменения каждого диска реплицируются в обе стороны. Если один из серверов в кластере откажет в работе, Co-StandbyServer перенаправляет такие параметры, как IP-адреса, общие ресурсы, имена серверов и другие ресурсы, работающему серверу.
Как показано на рис. 9.21, Co-StandbyServer обеспечивает двунаправленную синхронную репликацию на уровне блоков между двумя серверами Windows NT, которые могут находиться на расстоянии до 10 км друг от друга. Обратите внимание, что оба сервера могут быть активными и взаимозаменяемыми. Таким образом, на рис. 9.21 показано, что во время репликации одного диска слева направо, второй диск реплицируется справа налево.
Два сервера, между которыми выполняется зеркальное отражение на уровне блоков, не должны быть идентичными. Единственное требование заключается в работе серверов под управлением Windows NT и использовании аппаратного обеспечения, входящего в список совместимого с Windows NT. Функция зеркального отражения не может быть реализована для загрузочного диска.
Существуют определенные проблемы при использовании Co-StandbyServer совместно с конфигурациями чередования на базе Windows 2000 LDM. Программа Co-StandbyServer предоставляет возможности двух типов.
1. Зеркальное отражение, при котором записи на один сервер дублируются на другой сервер. 1
2. Режим совместного хранилища, при котором отказ в работе хранилища одного сервера приводит к предоставлению хранилища второго сервера первому серверу, что позволяет ему продолжать работу.
В числе преимуществ Co-StandbyServer можно выделить следующие:
В последнее время все больше заказчиков проявляют заинтересованность в развертывании тех или иных решений, позволяющих обеспечить защиту от катастроф. И это вовсе не пустая блажь, и не веяние моды: с годами растут объемы данных, повышаются требования по доступности сервисов.
Введение
Большинство сервисов не имеют встроенных средств катастрофоустойчивости, а для остальных сервисов настройка сопряжена с дополнительными затратами на оборудование и программное обеспечение. Кроме того, защита для каждого из сервисов обеспечивается разными механизмами, требующими различных настроек, поддержки и обслуживания. Виртуализация позволяет обеспечить единый подход к защите сервисов и централизованное управление процедурой восстановления.
Общая схема решения выглядит следующим образом: все сервисы работают внутри виртуальных машин (ВМ) на первой (основной) площадке. Дополнительная площадка, с установленным на ней оборудованием, исполняет роль холодного резерва.
В реальном времени или по расписанию выполняется копирование данных виртуальных машин с основной площадки на резервную. В случае отказа администратор инициирует процедуру восстановления сервисов, используя копии ВМ на резервной площадке.
Конфигурация сетевого оборудования, серверов и системы хранения данных на основной и резервной площадках не обязательно должны быть идентичными, однако важно, чтобы ресурсов, предоставляемых резервной площадкой, было достаточно для запуска и работы защищаемых сервисов.
При планировании катастрофоустойчивой инфраструктуры следует руководствоваться следующими критериями:
• RTO (RecoveryTimeObjective) – это время, которое требуется на восстановление работоспособности системы после сбоя;
• RPO (RecoveryPointObjective) – это интервал между операциями копирования данных с основного хранилища на резервное;
• TCO (TotalCostofOwnership) – совокупная стоимость владения решением, включающая затраты на оборудование и ПО, а также затраты на внедрение и поддержку.
Дальнейший обзор будет проводиться с учетом данных критериев. Для сравнения были выбраны следующие коммерческие решения:
• Microsoft Hyper-V Replica,
• VMware vCenter Site Recovery Manager,
• VMware vSphere Replication,
• Veeam Backup & Replication.
Для облегчения сравнения в таблице 1 (см. внизу текста) приведены основные критерии и функциональные возможности по всем четырем решениям.
Краткое описание и лицензирование
Hyper-V Replica представляет собой встроенный механизм репликации ВМ, предоставляемый гипервизором Hyper-V 3.0, который может быть установлен в качестве одной из ролей сервера Microsoft Windows Server 2012 либо в виде отдельного продукта MicrosoftHyper-VServer 2012. В обоих случаях Hyper-VReplica не требует покупки дополнительных лицензий.
Hyper-VReplica крайне прост в установке и настройке и не предъявляет к системе виртуализации Hyper-V каких-либо специфических требований.
VMware vCenterSiteRecoveryManager предназначен для организации катастрофоустойчивой виртуальной инфраструктуры для средних и крупных организаций. Основное назначение Site Recovery Manager – автоматизация процедуры переключения виртуальной инфраструктуры на резервный сайт, а также проведение тестирования планов восстановления.
Site Recovery Manager можно приобрести в составе набора VMwarevCloudSuiteEnterprise (лицензируется по процессорам сервера виртуализации) или отдельно (лицензируется по количеству защищаемых ВМ).
Site Recovery Manager доступен в двух редакциях: Standard и Enterprise. Различие двух редакций заключается в поддержке максимального количества защищаемых ВМ. Для версии Standard количество защищаемых ВМ не должно превышать 75, для Enterprise – до 1000.
VMwarevSphereReplication изначально являлся частью MwarevCenterSiteRecoveryManager и требовал покупки соответствующих лицензий, однако, начиная с версии 5.1, vSphereReplication входит во все редакции vSphere, за исключением vSphereEssentials.
VeeamBackup&Replication (VBR) представляет собой комплексное решение по резервному копированию и репликации ВМ, работающих как на гипервизоре VMwareESXi, так и на MicrosoftHyper-V.
ПО VBR лицензируется по числу физических процессоров (сокетов) хост-серверов виртуализации и доступен в двух версиях: Standard и Enterprise. Для организации катастрофоустойчивого решения разницы между редакциями нет.
Репликация
Репликация – процедура копирования данных с одного хранилища данных (исходного) на другое (целевое) по заданному расписанию. Репликация копирует только измененные блоки данных (размер блока может варьироваться у различных систем хранения и ПО репликации) и позволяет избежать необходимости каждый раз копировать измененные файлы ВМ целиком.
Условно можно разделить репликацию на два типа: синхронную и асинхронную.
Синхронная репликация выполняется в реальном времени. Подтверждение о записи отправляется клиенту только после получения подтверждения от целевого хранилища. Из-за возможных задержек при передаче данных, синхронная репликация имеет ограничение на максимальное расстояние между ЦОД. Многие вендоры поддерживают синхронную репликацию на расстояния не более 100 км. Обеспечивает минимальные значения RPO.
Асинхронная репликация выполняется по расписанию, через заданные промежутки времени. За счет использования сжатия - менее критична к задержкам, зачастую требует меньшей полосы пропускания, чем синхронная репликация. Многие производители поддерживают асинхронную репликацию на расстояния более 100 км. Обеспечивает RPO от нескольких минут до нескольких часов.
Hyper-VReplica, vSphereReplication и VeeamBackup&Replication выполняют репликацию собственными средствами и обеспечивают только асинхронную репликацию данных.
Для Hyper-VReplica интервал репликации составляет примерно 5 минут и не настраивается. Репликация осуществляется по Ethernet-сети самим гипервизором. ВМ и ее реплика не могут быть размещены в пределах одного хоста или одного кластера, в качестве цели для размещения реплики ВМ может быть указан сторонний хост или кластер из нескольких хостов Hyper-V.
Минимальный интервал репликации vSphereReplication составляет15 минут. Репликация данных осуществляется по Ethernet-сети между исходным сервером ESXi и специализированной ВМ vSphereReplicationAppliance, расположенной в резервном сайте. vSphereReplication позволяет размещать ВМ и ее реплику на серверах виртуализации, управляемых одним экземпляром VMwarevCenterServer (кроме случаев, когда vSphereReplication используется совместно с SiteRecoveryManager).
VeeamBackup&Replication позволяет запускать репликацию в режиме ContinuousProtection, при котором следующее задание на репликацию запускается сразу же после завершения предыдущего, что в зависимости от объема реплицируемых данных позволяет добиться RPO порядка 3-5 минут. Репликация данных выполняется сервером VeeamBackup&Replication и может осуществляться как по Ethernet-сети, так и по SAN-сети. VeeamBackup&Replication позволяет размещать реплику ВМ на любом хосте и любом хранилище, доступном в сети.
Для VMwareSiteRecoveryManager может использоваться репликация средствами VMwarevSphereReplication либо системы хранения данных. В случае использования репликации средствами системы хранения, помимо лицензий на SRM, может потребоваться приобрести дополнительные лицензии на репликацию от производителя СХД.
Для работы SiteRecoveryManager требуется, чтобы исходная ВМ и ее реплика размещались на серверах виртуализации, управляемых разными экземплярами VMwarevCenterServer.
Важным преимуществом программной репликации является возможность репликации отдельных ВМ, а также репликации ВМ, расположенных на локальных дисках серверов виртуализации, тогда как в случае с репликацией СХД реплицируется целиком весь том СХД со всеми ВМ, расположенными на нем.
Репликация, выполняемая на уровне СХД, использует отдельные интерфейсы системы хранения и не нагружает серверы виртуализации. Кроме того, репликация средствами СХД также поддерживает диски, подключаемые непосредственно в ВМ (т.н. RawDeviceMapping или Pass-through Disks), чего не позволяют сделать средства программной репликации.
Консистентные реплики
В случае асинхронной репликации источник передает измененные данные через заданные промежутки времени. В этом случае нет возможности гарантировать целостность данных в реплике, так как многие приложения, работающие внутри ВМ, такие как MicrosoftSQLServer или MicrosoftExchange, могут в этот момент иметь незавершенные транзакции записи в базы данных.
При репликации Hyper-V Replica использует механизм мгновенных VSS-снимков (снапшотов) для создания консистентных реплик. Минимальный интервал создания снимков – 1 час.
VMware SRM с vSphere Replication обеспечивает консистентные реплики на уровне файлов и приложений внутри ВМ, также используя механизм VSS-снимков и собственную технологию ChangeBlockTracking.
VeeamBackup&Replication обеспечивает консистентные реплики на уровне файлов и данных приложений, также используя VSS-снимки.
Для репликации средствами СХД консистентные реплики могут быть получены при использовании средств СХД, например, EMCSnapView, NetApp SnapManager и другие.
Тестирование
Средства тестирования позволяют запускать реплицированные ВМ из резервного сайта в изолированной от производственной инфраструктуры среде с целью проверки работоспособности механизмов репликации и корректности плана восстановления.
Hyper-V Replica позволяет создавать и запускать тестовую ВМ из копии реплицированной ВМ. По умолчанию такая ВМ запускается без подключения к виртуальной сети, чтобы исключить конфликт с исходной работающей ВМ.
SiteRecovery позволяет тестировать план восстановления путем запуска реплицированных ВМ в изолированной виртуальной сети без влияния на производственную инфраструктуру. В случае использование SRM вместе с СХД, поддерживающей клонирование томов, тестирование может выполняться без остановки репликации.
VeeamBackup&Replication также позволяет провести тестовый запуск реплицированной ВМ.
Автоматизация восстановления
Для реплицированной ВМ Hyper-V Replica позволяет задавать настройки сетевого адаптера, отличные от настроек исходной ВМ. Администратор должен запускать каждую реплицированную ВМ отдельно. Автоматизация запуска может выполняться с помощью сценариев PowerShell.
vSphereReplication не позволяет изменить сетевую конфигурацию (IP-адреса защищаемых ВМ, виртуальные коммутаторы) для реплицированной ВМ. При необходимости администратор самостоятельно должен внести изменения в сетевые настройки после включения реплицированной ВМ.
VMware SRM предоставляет широкие возможности по автоматизации плана восстановления ВМ, включая создание нескольких автоматизированных планов восстановления, назначение приоритета и последовательности запуска ВМ, настройка времени ожидания между запуском ВМ, изменение сетевой конфигурации для восстанавливаемых ВМ, запуск скриптов и сценариев внутри восстанавливаемых ВМ.
Veeam Backup & Replication может изменить сетевые настройки ВМ при восстановлении. Автоматизация запуска может выполняться с помощью средств PowerShell.
Плановое (Switchover) и внеплановое (Failover) переключение
В случае запланированного переключения, когда требуется провести какие-либо работы в основном сайте (например: отключить питание, перекоммутировать или перенести оборудование и т.п.), администратор заранее запускает процесс переноса ВМ в резервный сайт. Для этого требуется выключить все защищаемые виртуальные машины в основном сайте, запустить репликацию на СХД и проверить, что она успешно выполнилась, после чего запустить реплики ВМ в резервном сайте. Тем самым все ВМ переносятся в резервный сайт, и гарантируется целостность данных внутри ВМ, пускай и ценой некоторого кратковременного простоя.
В случае незапланированного переключения (например, при пожаре, отключении электроэнергии), когда основной сайт недоступен, администратор запускает ВМ, используя последнюю актуальную реплику данных в резервном сайте. В этом случае не может гарантироваться целостность данных, если не использовались специализированные механизмы (VSS-снимки).
Для Hyper-V Replica требуется запускать перенос для каждой ВМ в отдельности. Существует возможность автоматизации переноса с помощью powershell скриптов.
Для vSphereReplication администратор также запускает перенос для каждой ВМ в отдельности. Существует возможность автоматизации переноса с помощью сценариев.
VMware SRM предоставляет широкие возможности по автоматизации плана восстановления ВМ, включая приоритет и последовательность запуска ВМ, время ожидания, изменение сетевой конфигурации для восстанавливаемых ВМ, запуск скриптов и сценариев внутри восстанавливаемых ВМ.
VeeamBackup&Replication позволяет запускать ВМ по отдельности.
Настройка обратной репликации (Failback)
Помимо функционала восстановления инфраструктуры в резервном сайте, ПО репликации также может предоставлять возможность настройки репликации и переноса ВМ с резервного в основной сайт (Failback). Все рассматриваемые решения обладают подобной возможностью, однако в случае VMware SRM и VeeamBackup&Replication вам потребуется перенести лицензии с основного сайта в резервный либо приобрести дополнительные лицензии для защиты второго сайта.
Заключение
Рассмотренные выше средства репликации и организации катастрофоустойчивой виртуальной инфраструктуры позволяют обеспечить минимальные значения RTO и RPO при восстановлении инфраструктуры после катастрофы. Следует отметить, что катастрофоустойчивые решения не исключают других механизмов повышения доступности, таких как кластеризация, дублирование компонентов, резервное копирование данных, а, наоборот, дополняют их и позволяют обеспечить заданный уровень надежности бизнес сервисов организации.
Возможности программного обеспечения для репликации ВМ и организации катастрофоустойчивой виртуальной инфраструктуры
Подробности
Ведущий технический эксперт компании Helios IT, MCSE, MCITP, VCAP. Специализируется на виртуализации серверов и рабочих станций с использованием технологий следующих производителей: VMware, Microsoft, Citrix. Андрей имеет большой опыт по проектированию и внедрению решений, включая развертывание катастрофоустойчивые на базе VMware vCenter Site Recovery Manager и Veeam Backup & Replication.
Helios Information Technologies — универсальный интегратор инфраструктурных решений для корпоративных и государственных заказчиков. Компания образована в 1999 году, с 2006 года входит в группу компаний «Армада».
Helios IT предлагает широкий спектр услуг по следующим направлениям деятельности:
• системная интеграция, внедрение инфраструктурных решений, корпоративных сетей и инженерных систем;
• решения в области центров обработки данных, систем хранения и вычислительных комплексов;
• построение и обслуживание систем обеспечения информационной безопасности;
• оказание широкого спектра услуг в сфере ИТ на всех этапах жизненного цикла инфраструктуры.
AD — это база данных. По умолчанию каждый контроллер домена (DC) хранит ее копию в файле ntds.dit в локальном каталоге winnt tds. Логически база данных состоит из трех частей (трех разделов, трех контекстов именования — naming context, NC), а именно: контекста схемы (Schema NC), контекста конфигурации (Configuration NC) и контекста домена (Domain NC). Все контроллеры домена в лесу имеют один и тот же контекст схемы и конфигурации, поскольку эта информация, собственно, и описывает сам лес. Каждый DC одного и того же домена AD хранит одинаковую копию контекста домена. Если конкретный DC играет роль сервера — хранителя глобального каталога (Global Catalog, GC), то этот контроллер домена дополнительно содержит часть копий контекстов домена остальных доменов леса. В состав данной частичной копии входит описание всех объектов соответствующих доменов, но только некоторое подмножество их атрибутов.
Репликация — это механизм, который AD использует для синхронизации названных данных среди всех контроллеров в домене или в лесу. При этом AD задействует механизм проверки целостности Knowledge Consistency Checker (KCC), сайты (site), межсайтовые связи (site link) и объекты связи (connection object) при проведении репликации.
KCC является встроенным процессом, который запускается на всех контроллерах домена и создает топологию репликации леса. Сайты используются как структура для группировки хорошо связанных (в смысле близости в сети) контроллеров домена. Особенности используемой сети и построения AD определяют, можно ли считать произвольно выбранный контроллер домена хорошо связанным. Во многих компаниях принято считать, что DC, соединенные сетью со скоростью 100 Мбит/с, являются хорошо связанными. Для создания сайта AD конфигурируется с использованием подсетей IP. Если одна или несколько подсетей хорошо связаны между собой, их можно объединить в сайт. Репликация в рамках такого сайта называется внутрисайтовой репликацией (intrasite replication). Внутри сайта KCC автоматически создает объекты связи между различными DC. Объекты связи — это односторонние соединения, которые связывают между собой контроллеры домена внутри данного сайта. Каждая из таких связей — подобно полосе движения на автомагистрали — представляет собой соединение, ограниченное DC-источником и DC-приемником. Прежде чем два DC в сайте смогут реплицировать между собой данные каталога, необходимо установить два отдельных объекта связи.
Если некоторые из DC не подходят под категорию хорошо связанных, придется создать несколько сайтов. Репликация данных между различными сайтами носит название межсайтовой. Администратор AD использует оснастку Active Directory Sites and Services консоли Microsoft Management Console (MMC) для создания межсайтовых связей, которые формируют магистраль между сайтами. После того как все необходимые объекты связи установлены, KCC создает соединения между сайтами. Обычно не на всех контроллерах присутствуют одни и те же данные (например, контроллеры DC в отдельно взятом домене могут поддерживать некоторые специфичные данные). Следовательно, процессу KCC, возможно, придется устанавливать множество объектов связи, чтобы гарантировать, что каждое пространство имен любого контекста именования полностью синхронизировано (реплицировано). На Рисунке 1 приведен пример межсайтовых объектов связи. Сайт A и сайт B соединены между собой межсайтовыми связями, созданными вручную. В этом примере процесс KCC создал два односторонних соединения для репликации данных между двумя DC из одного домена.
Сервер-мост (bridgehead) — еще один компонент в топологии репликации. Тем, кому доводилось работать с Microsoft Exchange Server, этот компонент должен быть уже знаком. Для повышения эффективности репликации данных, KCC не создает индивидуальные объекты связи для передачи данных с каждого DC в одном сайте на каждый DC в другом сайте. Вместо этого KCC использует механизм store-and-forward, с промежуточным хранением, по правилам работы которого информация реплицируется между двумя серверами-мостами, по одному для каждого сайта. Для репликации информации на оставшиеся контроллеры в своем сайте сервер-мост использует уже внутрисайтовую репликацию. Подробнее об этом рассказано во врезке «Серверы Bridgehead».
Что происходит во время репликации?
Чтобы вносить изменения в объекты каталога DC, службы Active Directory должны иметь возможность определять, какие именно объекты изменились, и следует ли реплицировать произведенные изменения партнерам данного DC по репликации. Для отслеживания произошедших в каталоге изменений AD использует порядковые номера обновлений (update sequence number, USN). Номера USN представляют собой 64-разрядные счетчики, которые AD назначает для каждого DC индивидуально. Когда AD, пользователи, администраторы или приложения изменяют некоторые атрибуты, DC увеличивает текущее значение USN данного атрибута на единицу и присваивает обновленному объекту новое значение в качестве его локального USN.
В рамках репликационной топологии AD партнеры-участники используют значение high-watermark value (HWL) для проведения наиболее актуальных изменений, исходящих от различных DC-источников. Когда какой-либо DC-приемник собирается запросить изменения от DC-источника, он посылает свое значение HWL DC-источнику в качестве точки отсчета. В результате DC-источник перешлет лишь те изменения объектов каталога, HWL которых выше, нежели HWL приемника. В свою очередь, это снижает трафик репликации.
Чтобы свести к минимуму объем реплицируемых данных, можно задействовать еще один механизм — вектор обновления — up-to-dateness vector (UDV). Он непосредственно связан с HWL. Но если HWL привязан к объектам, то UDV занимается атрибутами. Во всем остальном работа этих механизмов одинакова. Во время обмена реплицируемыми данными DC-получатель посылает свой вектор UDV DC-отправителю. На основе значения вектора DC-отправитель устанавливает, насколько актуально значение конкретного атрибута на DC-получателе. Если значение вектора соответствует самому последнему изменению, DC-отправитель отфильтровывает это значение из потока репликации.
Шесть полезных инструментов
После развертывания AD следует обзавестись набором утилит, которые могут помочь в случае возникновения нештатной ситуации. Microsoft Windows 2000 Server Resource Kit предлагает множество соответствующих программ, и примерно 50 из них хранится в каталоге support ools на компакт-диске с Windows 2000. Сбои в репликации могут быть самыми неожиданными, поэтому надо быть готовым к применению различных утилит.
Event Viewer. Стандартная программа просмотра событий Windows запускается через Start, Programs, Administrative Tools. Event Viewer в первую очередь сигнализирует об отклонениях в работе системы. Если AD развернута, на станциях DC появляется новый журнал под названием Directory Services. Чтобы последние по времени инциденты в процессе репликации не прошли незамеченными, необходим мониторинг журналов Directory Services. Можно, конечно, поочередно подключаться к разным DC и просматривать журнал событий, но Event Viewer за один раз покажет администратору только один журнал. Для получения отчета о результатах репликации со всех контроллеров домена я рекомендую воспользоваться утилитой Replication Monitor.
Replication Monitor. Replmon.exe — графическая утилита, входит в состав Windows 2000 Support Tools и используется для получения сводной информации о репликации в рамках всей организации. Эти данные помогут установить, прошла ли репликация, когда именно это произошло, между какими DC возникал соответствующий трафик и многое другое.
Replmon позволяет собрать со всех станций DC все события, относящиеся к выполнению репликации. Чтобы запустить Replmon, нужно щелкнуть Start, Run и набрать:
Утилита открывает окно, в которое следует вручную добавить серверы, требующие мониторинга. Есть простой способ быстро добавить все нужные серверы — создать .ini-файл с указанием списка контроллеров домена, по одному в строке. Затем в меню Replmon нужно щелкнуть File, Open Script, найти созданный .ini-файл и нажать Open.
В результате в окне Replmon появятся все заданные серверы DC и хранящиеся на них контексты именования. На Экране 1 я вручную добавил сервер testdc01. Снизу testdc01 видны три контекста именования, хранящиеся на данном DC. Список задач, которые можно выполнить с помощью Replmon, открывается в контекстном меню сервера — достаточно просто щелкнуть на его имени правой кнопкой мыши. Необходимо внимательно изучить каждую из этих задач и уметь ориентироваться в собираемой информации для успешного решения проблем, связанных с репликацией.
Одной из наиболее ценных особенностей Replmon является способность утилиты быстро находить в журналах Directory Services записи, относящиеся к ошибкам репликации. Для этого в меню Replmon нужно открыть Action, Domain, Search Domain Controllers for Replication Errors, затем щелкнуть Run Search. Replmon предложит ввести имя домена, для которого будет выполняться операция поиска. Следует указать DNS-имя домена и щелкнуть ОК. Утилита пошлет запрос всем контроллерам домена и соберет записи об ошибках репликации с указанием DC, на котором возникла ошибка, затронутого раздела каталога или NC, вовлеченного DC-партнера по репликации, кода ошибки и ее причины. Replmon опрашивает каждый DC индивидуально.
Domain Controller Diagnostics. Dcdiag.exe, утилиту командной строки, можно отыскать на компакт-диске с Windows 2000 Server. Это мощная диагностическая программа, предоставляющая в распоряжение администратора громадный объем информации о DC, на котором утилита работает. Dcdiag запускает на DC набор тестовых задач, чтобы понять, возможно ли соединение DC с другими станциями, проверить статус репликации, целостность топологии, пользовательских разрешений, функций локатора, состояние перекрестных ссылок на уровне сайта, работу служб верификации доверительных отношений, состояние File Replication Service (FRS), а также состояние всех жизненно важных для работы DC служб. Запустив утилиту Dcdiag, нужно быть готовым к тому, что придется просмотреть огромное количество данных. Я рекомендую использовать следующий синтаксис вызова:
Repadmin. Repadmin.exe, утилита командной строки, также находится на компакт-диске с Windows 2000 Server и, вероятно, занимает центральное место в наборе рассматриваемых утилит. С ее помощью можно подробно узнать, что происходит во время проведения репликации, это поможет выяснить причину сбоя и восстановить работоспособность системы. Для просмотра параметров программы следует набрать в командной строке:
Одно из наиболее полезных свойств утилиты — показ партнеров по репликации для указанного DC. Наберите:
Repadmin можно использовать и для просмотра информации об отдельном объекте AD. Предположим, требуется посмотреть локальный USN объекта и источник самого последнего обновления его свойств. Для этого нужно вызвать Repadmin следующим образом:
На Экране 3 показаны результаты этого запроса. В крайней справа колонке приведены атрибуты пользователя Administrator. В крайней слева — локальный USN для каждого атрибута. Обратите внимание, что атрибуты nTSecurityDe и adminCount имеют большее значение USN, чем остальные. Это говорит о том, что значения этих двух атрибутов были изменены позже, чем у всех остальных.
Group Policy Verification. Gpotool.exe, утилита командной строки из Resource Kit, поможет решить вопросы, связанные с ошибками в репликации объектов Group Policy Objects (GPO) между контроллерами домена. Подробнее об этом рассказано во врезке «Служба Windows 2000 File Replication Service».
Статистика Directory Service Agent. Dsastat.exe, утилита командной строки, находится на компакт-диске Windows 2000 Server. Она сравнивает контексты имен на контроллерах домена и сообщает о различиях. Ею удобно пользоваться, когда все, казалось бы, работает нормально, но обнаруживается, что с различных контроллеров домена каталог выглядит по-разному. Это может означать, что база данных каталога испорчена. Dsastat гарантирует высокую степень непротиворечивости данных, сравнивая статистику каталога (скажем, объектов) сервер за сервером, байт за байтом, объект за объектом в каждой возможной паре контроллеров домена.
Итак, даже в небольших сетях AD требует тщательного анализа. Если однажды вы найдете время и разберетесь с тем, как работает репликация, все усилия окупятся сторицей, когда «грянет гром». Если же речь идет о сети гигантской компании, насчитывающей множество сайтов, то лучшее, что можно сделать, — это запастись терпением. Нужно помнить, что AD работает в среде с независимыми контроллерами домена. Когда происходит изменение на одном DC, может пройти несколько часов, пока волна ответных изменений прокатится по всему лесу. Поэтому лучше за один раз делать только одно изменение, документировать свои действия и предоставлять AD достаточное время для проведения репликации и реагирования на внесенное изменение.
Серверы Bridgehead
Bridgehead server — это контроллер домена, который работает как основной маршрутизатор во время репликации данных Active Directory за пределами сайта и внутри него. Если в лесу имеется более одного домена, то, вероятно, bridgehead-сервер также не один. Сервер-мост будет работать только с контекстами именования, в которых задействована локальная база данных AD (т. е. контексты именования Schema NC, Configuration NC и Domain NC; последний контекст относится к домену, в состав которого входит рассматриваемый DC). Даже в том случае, когда DC выполняет функцию сервера глобального каталога (GC) и хранит частичные копии контекстов имен других доменов, DC не авторизован для работы с «чужими» доменами в качестве маршрутизатора потока репликации. Отсюда следует, что для сайта, состоящего из нескольких доменов, требуется несколько серверов-мостов для поддержания трафика репликации.
Как же обычный DC становится bridgehead-сервером? По умолчанию, программа проверки целостности, Knowledge Consistency Checker (KCC), организует выборы на роль сервера-моста. Как только KCC выстроит топологию репликации, каждый DC в каждом сайте оценивается на предмет соответствия параметрам сервера-моста. По сути KCC пытается сформировать список из минимального числа DC для репликации всех трех контекстов именования между «родным» сайтом и любым соединенным с ним сайтом. Если на роль bridgehead подходит два и более серверов, KCC сортирует их по возрастанию глобального уникального идентификатора, GUID, и выбирает сервер с наименьшим значением GUID.
Администратор может назначить выбранные по своему усмотрению DC как предпочтительные серверы-мосты с тем, чтобы во время процедуры выборов KCC обратил на них особое внимание. Но необходимо помнить, что назначение серверов-мостов вручную повлияет на отказоустойчивость KCC. Если позволить KCC самостоятельно выбрать сервер-мост, то в случае сбоя KCC без труда решит проблему его быстрой замены. Если же администратор назначает серверы предпочтения, то выбор программы KCC ограничен только серверами предпочтения. Это означает, что, если в качестве предпочтительного сервера администратор указал только один DC, а он по каким-то причинам вышел из строя, программа KCC ничем вам помочь не сможет. Если уж назначать вручную кандидатов на роль серверов-мостов, следует указать для каждого контекста в каждом сайте по крайней мере два DC.
Для назначения предпочтительных серверов можно воспользоваться оснасткой Active Directory Sites and Services Microsoft Management Console (MMC). Открыв оснастку, нужно перейти к серверу DC, который планируется задействовать в качестве предпочтительного. Затем следует открыть контекстное меню объекта DC и выбрать Properties. После этого необходимо выбрать транспортный протокол (или RPC поверх IP, или SMTP) репликации и нажать Add. Если в сети используется несколько транспортных протоколов, и администратор хочет назначить для сайта предпочтительные серверы-мосты, то для каждого протокола также надо назначить по одному серверу.
Служба Windows 2000 File Replication Service
Windows 2000 Server использует службу File Replication Service (FRS) для репликации информации, хранящейся в каталоге системного тома ((sysvol). Кроме того, FRS нужна для синхронизации наборов реплик Distributed File System (Dfs). FRS — правопреемник службы LMRepl из состава Windows NT 4.0. Рассматривая вопросы, связанные с репликацией AD, упомянуть о FRS необходимо по двум причинам.
Во-первых, поскольку общий ресурс sysvol требуется реплицировать на все контроллеры домена, у него должно быть свое место в топологии репликации. Несколько упрощая ситуацию, можно сказать, что FRS «встраивается» в топологию репликации, создаваемую программой KCC для AD. Исключением из этого правила является набор реплик Dfs, которые настраиваются через оснастку Dfs консоли MMC. Репликация объектов в AD протекает иначе, чем репликация sysvol. Одно из различий состоит в том, что данные каталога реплицируются между сайтами в сжатом виде, в то время как реплицируемые файлы на томе sysvol не сжимаются.
Во-вторых, служба FRS очень важна для групповых политик Group Policy. Объекты групповой политики Group Policy Object (GPO) имеют два компонента — контейнер, Group Policy Container (GPC), и шаблон — Group Policy Template (GPT). GPC находится в AD и содержит все параметры свойств объекта, описанного для GPO. GPT находится на томе sysvol в каталоге, имя которого соответствует глобальному идентификатору политики GUID (см. Экран А). В этом каталоге хранится информация о настройках безопасности и административных политиках-шаблонах, здесь же находятся файлы-сценарии и приложения, которые Windows 2000 публикует или декларирует через ту или иную политику.
Читайте также: