Резервная непрерывная репликация (SCR) — это новый режим репликации, появившийся в Microsoft Exchange Server 2007 с пакетом обновления 1 (SP1). Как видно из названия, резервная непрерывная репликация предназначена для сценариев, в которых используются серверы резервного восстановления. Режим репликации SCR расширяет возможности непрерывной репликации окончательной первоначальной версии (RTM) Exchange Server 2007 и позволяет с помощью серверов с пакетом обновления 1 (SP1) реализовывать новые сценарии конфигурации серверов почтовых ящиков с высоким уровнем доступности данных. При репликации SCR используются те же технологии доставки и воспроизведения журнала, что при локальной непрерывной репликации (Local Continuous Replication, LCR) и при непрерывной репликации кластеров (Cluster Continuous Replication, CCR). Это позволяет расширить возможности развертывания и настройки кластеров.
Резервная непрерывная репликация позволяет разделить задачи повышения уровня доступности (как доступности данных, так и доступности служб) и обеспечения надежности узлов. В частности резервную непрерывную репликацию можно использовать совместно с непрерывной репликацией кластеров. При этом группы хранения будут реплицироваться локально в основном центре данных (высокая доступность обеспечивается за счет репликации CCR) и удаленно в дополнительном резервном центре данных (репликация SCR обеспечивает надежную работу узла). Дополнительный центр данных может иметь пассивный узел в отказоустойчивом кластере для размещения реплицируемых с помощью SCR копий БД. Такой кластер называется резервным, поскольку он не содержит кластерных серверов почтовых ящиков, но в случае сбоя с помощью такого кластера можно быстро восстановить данные кластерного сервера почтовых ящиков. Если основной центр данных выходит из строя или становится недоступным по каким-либо другим причинам, копии SCR, размещенные в резервном кластере, можно быстро активировать.
Источники и цели
Подобно моделям локальной непрерывной репликации и непрерывной репликации кластера режим резервной непрерывной репликации использует понятия активных и пассивных копий групп хранения. Но в данном случае они называются источниками и целями. Как и в случае непрерывной репликации кластера пути к базам данных и файлам журналов при резервной непрерывной репликации должны совпадать для источника и цели.
Ключевым понятие модели репликации SCR является источник. К источникам могут относиться любые группы хранения в следующих объектах:
- изолированный сервер почтовых ящиков;
- кластерный сервер почтовых ящиков в кластере с единым
хранилищем
- кластерный сервер почтовых ящиков в среде кластера с
непрерывной репликацией
Примечание.При резервной непрерывной репликации нельзя использовать группы хранения для восстановления.
Как и в случае локальной непрерывной репликации и непрерывной репликации кластера, группы хранения, реплицируемые с помощью резервной непрерывной репликации, не могут содержать более одной базы данных. Репликацию SCR нельзя включить для групп хранения с более чем одной базой данных, а если для группы хранения уже используется репликация SCR, то добавить к этой группе хранения дополнительные БД также невозможно.
Если исходный компьютер резервной непрерывной репликации не является кластерным, на нем можно разместить другие роли сервера, такие как роли транспортного сервера-концентратора, сервера клиентского доступа и сервера единой системы обмена сообщениями.
Конечная точка при резервной непрерывной репликации называется целью. В качестве цели может использоваться один из следующий объектов:
- изолированный сервер почтовых ящиков, не использующий локальную
непрерывную репликацию ни для одной из групп хранения;
- резервный отказоустойчивый кластер, на котором установлена роль
пассивного кластерного хранилища почтовых ящиков, но не установлен
кластерный сервер почтовых ящиков (например, роль активного
кластерного хранилища почтовых ящиков).
При резервной непрерывной репликации на целевом компьютере должна быть установлена роль сервера почтовых ящиков, даже если на сервере нет рабочих почтовых ящиков. Это требование связано с тем, что роль сервера почтовых ящиков включает службу репликации Microsoft Exchange и другие компоненты, необходимые для работы резервной непрерывной репликации. Если конечный компьютер резервной непрерывной репликации не является кластерным, на нем можно разместить другие роли сервера, такие как роли транспортного сервера-концентратора, сервера клиентского доступа и сервера единой системы обмена сообщениями.
Функция резервной непрерывной репликации входит в состав пакета обновления 1 (SP1) для Exchange 2007 Standard Edition. Если же в качестве источника при репликации SCR используются среды с кластером единой копии или непрерывной репликацией кластера, необходимо устанавливать выпуск Enterprise Edition сервера Exchange 2007 с пакетом обновления 1 (SP1), поскольку для построения кластерных решений обязательно требуется выпуск Exchange 2007 Enterprise Edition. Если в качестве цели при репликации SCR используется резервный кластер, также необходима установка выпуска Enterprise Edition сервера Exchange 2007 с пакетом обновления 1 (SP1).
Сравнение резервной непрерывной
репликации с локальной непрерывной репликацией и непрерывной
репликацией кластера
Резервная непрерывная репликация похожа на локальную непрерывную репликацию и непрерывную репликацию кластера, но имеет и некоторые особенности:
- репликация SCR поддерживает несколько целей для одной группы
хранения. Модели LCR и CCR поддерживают только одну цель для группы
хранения (пассивная копия);
- механизм репликации SCR позволяет указывать время задержки для
воспроизведения журнала. Это бывает полезно во многих случаях.
Например, при повреждении логической структуры активной базы данных
установленная администратором задержка воспроизведения позволит
избежать повреждения логической структуры целевой базы данных.
Модели репликации LCR и CCR не поддерживают такую задержку;
- резервной непрерывной репликацией можно управлять только с
помощью командной консоли Exchange. Для управления многими
параметрами репликации LCR и CCR можно использовать консоль
управления Exchange, но она совершенно неприменима для управления
репликацией SCR;
Активация копии резервной
непрерывной репликации
Процесс использования конечной базы данных резервной непрерывной репликации называется активацией. Способ активации базы данных зависит от характера сбоя. Если сбой повлиял на работу одной или нескольких баз данных на исходном компьютере резервной непрерывной репликации, при выполнении активации для конечных баз данных резервной непрерывной репликации можно использовать доступную в Exchange 2007 функцию переносимости баз данных. Если сбой повлиял на работу всех баз данных на исходном сервере резервной непрерывной репликации или осуществляется восстановление всего сервера или кластерного сервера почтовых ящиков, при выполнении активации можно использовать функции восстановления сервера, поддерживаемые командой (Setup /m:RecoverServer для автономного сервера и Setup /RecoverCMS для кластерного сервера почтовых ящиков).
| Примечание. |
|---|
| Если планы восстановления включают использование команды Setup /RecoverCMS для восстановления кластерного сервера почтовых ящиков (в среде кластера с непрерывной репликацией или среде с резервной непрерывной репликацией), на котором для одной или нескольких групп хранения включена резервная непрерывная репликация, перед выполнением команды Setup /RecoverCMS необходимо отключить резервную непрерывную репликацию. |
Дополнительные сведения об активации и восстановлении в среде с резервной непрерывной репликацией см. в разделе Активация целей резервной непрерывной репликации.
Сценарии развертывания резервной
непрерывной репликации
Модель репликации SCR позволяет выполнять непрерывную репликацию данных одного или нескольких серверов почтовых ящиков в средах с кластером единой копии или с непрерывной репликацией кластеров. На следующих рисунках показано несколько возможных вариантов конфигурации SCR.
На этом рисунке показана конфигурация SCR, позволяющая реплицировать несколько групп хранения с одного сервера почтовых ящиков на другой сервер почтовых ящиков. В приведенном примере серверы почтовых ящиков не являются кластерными серверами и оба выступают как в качестве источников, так и в качестве целей SCR. В этом примере серверы расположены в разных центрах обработки данных и относятся к разным сайтам Active Directory. В зависимости от причин сбоя для восстановления группы хранения или сервера можно воспользоваться переносимостью базы данных или параметром /RecoverServer программы установки.
На рисунке показана модель репликации CCR-SCR один-к-одному. В этом примере EXCLUS1 — это кластерный сервер почтовых ящиков в среде CCR, относящийся к сайту REDMOND в Active Directory. EXCLUS1DR — это резервный кластер, относящийся к сайту QUINCY в Active Directory. В данном случае для восстановления всех групп хранения на целевом сервере SCR можно применить параметр /RecoverCMS команды Setup. Если требуется восстанавливать не все группы хранения, а одну или несколько групп, можно воспользоваться переносимостью баз данных.
На рисунке показана модель репликации CCR-SCR один-ко-многим. Компьютеры в левой части рисунка изображают два физических узла CCR в одном и том же центре данных. Компьютеры в правой части рисунка изображают две цели SCR в другом центре данных. В данном примере одна группа хранения реплицируется на несколько целей SCR на двух компьютерах. Для восстановления группы хранения на любом из целевых компьютеров SCR можно воспользоваться одним из следующих способов:
- параметром /RecoverCMS можно воспользоваться лишь в том
случае, если восстанавливаются группы хранения одного источника
CCR;
- для восстановления групп хранения различных источников CCR
следует использовать переносимость баз данных.
На рисунке показана модель репликации SCC-SCR один-ко-многим. Компьютеры в левой части рисунка изображают два физических узла SCC в одном центре данных. Компьютеры в правой части рисунка изображают цели SCR в другом центре данных. В данном примере одна группа хранения реплицируется на две отдельные цели в другом центре данных. В этом случае для восстановления группы хранения на целевом сервере SCR следует воспользоваться параметром /RecoverCMS команды Setup.
Изменения командлетов, связанные
с репликацией SCR
Для управления репликацией SCR служит командная консоль Exchange. В пакете обновления 1 (SP1) появился новый параметр StandbyMachine, который можно использовать с различными командлетами командной консоли Exchange, позволяющими управлять непрерывной репликацией и настраивать ее параметры. Параметр StandbyMachine и резервная непрерывная репликация поддерживаются следующими командлетами:
- Suspend-StorageGroupCopy
- Resume-StorageGroupCopy
- Update-StorageGroupCopy
- Restore-StorageGroupCopy
- Get-StorageGroup
- Get-StorageGroupCopyStatus
Обновления, связанные с включением поддержки репликации SCR, коснулись также командлетов New-StorageGroup и Enable-StorageGroupCopy. В Exchange 2007 с пакетом обновления 1 (SP1) с помощью командлета New-StorageGroup можно создавать группы хранения с включенной репликацией SCR, а с помощью командлета Enable-StorageGroupCopy можно включать репликацию SCR для уже существующих групп хранения. Эти командлеты поддерживают запуск со следующими параметрами:
- -StandbyMachine Параметр определяет имя целевого
компьютера SCR.
- -ReplayLagTime Параметр определяет время ожидания,
по истечении которого служба репликации Microsoft Exchange
должна начать воспроизведение файлов журнала, скопированных на
целевой компьютер SCR. Параметр имеет следующий формат:
(дни.часы:минуты:секунды). Значение по умолчанию — 24 часа
(1.0:0:0). Максимальное допустимое значение — 7 дней. Минимальное
допустимое значение — 0 секунд, Тем не менее даже при установке
этого параметра равным 0 стандартные 50 файлов журнала будут
накапливаться без воспроизведения. Изменить значение этого
параметра без отключения и повторного включения резервной
непрерывной репликации невозможно.
- -TruncationLagTime Параметр определяет время
ожидания, по истечении которого служба репликации
Microsoft Exchange должна начать усечение файлов журнала,
скопированных на целевой компьютер SCR. Отсчет времени начинается с
момента успешного воспроизведения журнала для копии базы данных.
Параметр имеет следующий формат: (дни.часы:минуты:секунды).
Максимальное допустимое значение — 7 дней. Минимальное допустимое
значение — 0 секунд. Тем не менее установка этого параметра равным
0 позволяет выполнять усечение файлов журнала без задержки.
Изменить значение этого параметра без отключения и повторного
включения резервной непрерывной репликации невозможно.
Помимо настраиваемого администратором с помощью параметра ReplayLagTime времени задержки воспроизведения, существует также фиксированное число файлов журнала, которые не воспроизводятся сервером Exchange независимо от значения параметра ReplayLagTime. Это фиксированное число определяется по следующей формуле: Максимум из («число журналов, воспроизводимых за время ReplayLagTime» или «X файлов журнала»), где X=50. Это дополнительная мера безопасности, позволяющая защититься от случаев, когда необходимо заново заполнить источник SCR в средах с непрерывной репликацией (например, LCR или CCR) при масштабных сбоях, при которых сервер восстанавливается с помощью командлета Restore-StorageGroupCopy. Задержка воспроизведения журналов на целевых серверах резервной непрерывной репликации в большинстве случаев позволяет избежать необходимости заново заполнять копии баз данных резервной непрерывной репликации в случае масштабных сбоев источника резервной непрерывной репликации, поскольку потеря данных не успевает реплицироваться на целевом сервере.
| Важно! |
|---|
| Встроенная задержка воспроизведения 50 файлов журнала и стандартное время задержки в 24 часа накладывают ограничения на создание начальной копии целевой базы данных SCR. Начальная копия целевой базы данных SCR будет создана только после репликации 50 файлов журнала транзакций и по истечении времени, определенном параметром ReplayLagTime (по умолчанию через 24 часа). |
Изменения команды Setup,
связанные с репликацией SCR
Механизм резервной непрерывной репликации в первую очередь предназначен для защиты от масштабных сбоев, таких как полный выход из строя узла. В таких случаях требуется выполнение некоторых операций по восстановлению вручную, например активации резервного центра данных или передачи управления обратно основному центру данных.
В приведенной ранее в этом документе схеме Несколько удаленных целей резервной непрерывной репликации для одного кластера с единым хранилищем объяснялось, что происходит при выходе из строя основного центра обработки данных (сайта с кластером с единым хранилищем) и активации второго центра обработки данных. При активации второго центра данных конфигурация исходного центра данных остается в Active Directory, и именно она используется вторым центром данных после активации. Конфигурация кластерного сервера почтовых ящиков для репликации SCC также остается в исходном кластере. Чтобы снова сделать исходный кластер доступным, необходимо удалить конфигурацию кластерного сервера почтовых ящиков с узлов кластера, не затронув при этом конфигурацию кластерного сервера почтовых ящиков в Active Directory (поскольку она используется вторым центром данных).
Команда Setup была изменена в Exchange 2007 с пакетом обновления 1 (SP1), чтобы сделать возможным использования этого и других сценариев повышения надежности узла. В частности появился новый параметр /ClearLocalCMS, позволяющий удалить сведения о конфигурации кластерного сервера почтовых ящиков с узлов исходного узла, не повредив при этом сведения о конфигурации в Active Directory. Например, чтобы очистить данные о локальной конфигурации кластерного сервера почтовых ящиков EXCLUS1, необходимо на всех узлах исходного кластера, с которых нужно удалить кластерный сервер почтовых ящиков, локально выполнить следующую команду:
 Копировать код |
|
|---|---|
Setup /ClearLocalCMS |
|
При использовании параметра /ClearLocalCMS следует помнить о следующих требованиях и ограничениях:
- этот параметр можно использовать только локально;
- этот параметр можно использовать только на узлах, на которых
расположен кластерный сервер почтовых ящиков (например, на активных
узлах); его нельзя применять на пассивных узлах;
- этот параметр не позволяет удалить файлы программ
Microsoft Exchange или обновить сведения о конфигурации в
Active Directory;
- параметр можно использовать только в случаях, когда локальный
кластерный сервер почтовых ящиков отключен от сети, а локальный
узел не входит в список RedundantMachines локального
кластерного сервера почтовых ящиков;
- учетной записи пользователя, выполняющего очистку сведений о
конфигурации кластерного сервера почтовых ящиков, необходимо
делегировать полномочия администратора сервера Exchange на
кластерном сервере почтовых ящиков.
- Если узлы кластера работают под управлением
Windows Server 2008, после выполнения команды
Setup /ClearLocalCMSобъект виртуального компьютера будет отключен. Его необходимо включить.
Дополнительные сведения
Дополнительные сведения о планировании резервной непрерывной репликации см. в разделе Планирование резервной непрерывной репликации. Дополнительные сведения об управлении резервной непрерывной репликацией, в том числе подробные инструкции по включению и отключению такой репликации для группы хранения, см. в разделе Управление резервной непрерывной репликацией.