В Exchange Server 2007 RTM и Windows Server 2003 у нас есть два инструмента, которые обеспечивают высокую степень доступности: SCC (Single Copy Cluster) и CCR (Cluster Continuous Replication) (Рисунок 01), однако, в одном сценарии у нас может и не быть высокой степени доступности и устойчивости сайта одновременно.
Рисунок 01: Решения, обеспечивающие высокую степень доступности в Exchange Server 2007 RTM Windows 2008 с отказоустойчивым кластером (failover cluster) имеет новую возможность, которая позволяет установить CCR или SCC на различные IP подсети, что было невозможно при использовании Windows Server 2003. С помощью Windows 2008 мы можем использовать два центра данных, каждый с узлом CMS (Clustered Mailbox Server) CCR. Однако, в таком сценарии мы не будем обладать локальным решением с высокой степенью доступности.
Примечание: Чтобы использовать устойчивость сайта с помощью кластера Windows Server 2003 Cluster, оба узла у нас должны быть в одной и той же подсети, даже если они располагаются в различных местах. Единственный способ реализовать это, заключается в использовании виртуальных (Virtual) LAN для расширения сети между узлами.
При использовании Exchange Server 2007 RTM мы можем выбрать либо сценарий с высокой степенью доступности, либо устойчивости сайта, но не оба. Однако, с выходом пакета обновления Service Pack 1, появилась возможность SCR, с помощью которой мы можем удовлетворить обоим этим требованиям (высокая доступность и устойчивость сайта), используя лишь Exchange Server 2007. Например, мы можем иметь основной сайт с почтовым сервером, который может быть либо одним почтовым сервером, CCR или SCC и моделью групп хранения в готовом сайте; в случае аварии на основном сайте мы можем использовать реплицированные данные на дополнительном сайте для быстрого восстановления пользовательских сообщений.
SCR добавляет больше параметров к решениям, обеспечивающим высокую доступность, которые можно найти в RTM версии, и расширяет их, позволяя среде иметь копию базы данных основного сайта на дополнительном сайте, что обеспечивает дополнительный уровень безопасности в случае аварийного восстановления.
SCR использует концепцию источника (Source) и приемника (Target). Источниками SCR могут быть любые установки Exchange Server 2007 Mailbox, такие как почтовый сервер (mailbox server), Single Copy Cluster (SCC) или Cluster Continuous Replication (CCR). С другой стороны приемником SCR может быть единственный почтовый сервер (single mailbox server) или пассивный узел CMS.
SCR использует ту же самую технологию репликации, которая используется CCR и LCR, но реализована она иначе. С помощью SCR у нас есть концепция источника Source (Active copy – активная копия) и приемника Target (Passive Copy – пассивная копия), которые обладают некоторыми требованиями, а именно:
- Операционная система, используемая источником и приемником, должна быть одной и той же.
- И на источнике и на приемнике должен быть установлен пакет обновления Exchange Server 2007 SP1.
- Они должны быть в одном домене Active Directory.
- Приемник может обрабатывать 50 групп хранения (Storage Group) для корпоративной версии и 5 групп хранения (Storage Group) в стандартной версии.
- На приемнике должна быть установлена, по крайней мере, роль почтового сервера (Mailbox Server).
- На принимающем сервере нет признаков репликации при использовании консоли управления Exchange Management Console.
- Пути к базе данных и группам хранения должны быть одинаковы на приемнике и источнике. Это означает, что указывать пути следует внимательно. Например, два источника не могут использовать один и тот же путь для базы данных и групп хранения на одном приемнике.
- Служба репликации (Replication service) поддерживает базу данных, журнальные файлы и пути на SCR приемника, не нужно создавать папку или что-то еще, перед ее включением.
- Один источник может иметь несколько приемников; один приемник может иметь несколько источников.
- Microsoft рекомендует использовать не более 4 приемников для одного источника.
И еще, нельзя создать резервную копию приемника SCR, только источника SCR.
Включение SCR
В этой статье мы будем использовать два сервера с тремя ролями: Client Access Server (сервер для доступа клиентов), Mailbox Server (почтовый сервер) и Hub Transport (транспортный хаб), и все они будут работать на Windows Server 2008 RTM. Сценарий, который будет использоваться в этой статье, можно увидеть на рисунке 02.
Рисунок 02
Сервер, расположенный на основном сайте (srv-ex01), имеет группу хранения (Storage Group) под названием UsersSG и почтовую базу данных под названием UsersSG. Все журнальные файлы и базы данных будут храниться в c:\UsersSG, как показано на рисунке 03.
Примечание: В этой статье мы сфокусируемся на демонстрации работы SCR. Размещение базы данных и журнальных файлов на одном диске, а также на одном диске с операционной системой не рекомендуется, поэтому не следует делать так в промышленной среде.
Рисунок 03
Давайте откроем оболочку для управления Exchange Management Shell на сервере srv-ex01 и откроем список всех существующих групп хранения Storage Groups с помощью команды Get-StorageGroup ‘Server
Enable-StorageGroupCopy ‘Identity
Команда выше позволяет включить приемник SCR в существующей группе хранения (Storage Group). С помощью этой команды мы можем указать важные параметры, используемые в SCR:
-
‘Standbymachine: название приемника SCR, где будет храниться пассивная копия текущей группы хранения
-
‘ReplayLagTime: файлы будут скопированы на приемник SCR, после этого службы репликации (Replication Service) будет ждать в течение интервала времени, указанного в этом параметре, а затем поместит скопированные журнальные файлы в пассивную копию базы данных. Даже если указать 0, существует жестко прописанный лимит в 50 журнальных файлов – это значит, что приемник SCR Target будет отставать от промышленной среды по крайней мере на 50 журнальных файлов. По умолчанию этот период времени составляет 24 часа.
-
‘TruncationLagTime : мы можем указать период времени, после которого журнальные файлы, скопированные в пассивную базу данных, будут удалены с приемника SCR Target.
Примечание: ReplayLagTime и TruncationLagTime нельзя изменить, только отключение и подключение репликации позволит изменить эти значения.
Примечание: Существует неизменное значение отставания по умолчанию, которое равно 50 журнальным файлам, чтобы избежать дублирования в случае аварии.
Этапы для просмотра групп хранения и создания модели UsersSG показаны на рисунке.
Рисунок 04
Через несколько минут мы увидим новый элемент в окне Event Viewer приемника SCR. Этот новый элемент имеет EventID 2114 и источник MSExchangeRepl – обычно это информация является признаком того, что была запущена группа хранения, что показано на рисунке 05.
Рисунок 05
Мы также можем использовать команду Get-StorageGroupCopyStatus для просмотра текущей информации о нашей SCR, чтобы получить информацию лишь о SCR, мы можем использовать параметр ‘StandbyMachine и далее имя приемника SCR Target, что показано на рисунке 06.
Рисунок 06
Мы можем проверить журнальный файл репликации (Рисунок 07) на приемнике SCR target (srv-ex02), как мы видели ранее, путь, используемый источником, должен быть таким же, как и на приемнике. Единственное, что мы не можем еще увидеть – это база данных на приемнике SCR Target. Это нормальное поведение, т.к. база данных будет создана на приемнике SCR только после того, как будет создано 50 журналов на источнике SCR, либо после того, как будет достигнуто значение, указанное в параметре replaylagtime.
Рисунок 07
Наконец, давайте посмотрим на srv-ex02 (Рисунок 08) и мы не увидим изменений в количестве хранилищ почтовых ящиков и групп хранения. Единственный способ для управления SCR заключается в использовании оболочки управления Exchange Management Shell. Помните, что srv-ex02 получит все журнальные файлы по пути c:\UsersSG, но в консоли управления Exchange Management Console об этом не будет никакой информации.
Рисунок 08
Заключение
В этой статье мы продемонстрировали, как включить SCR, а также описание источника и приемника. Мы также проверили изменения на источнике и приемнике после включения SCR. В следующей части этой статьи мы протестируем возможные сценарии, в которых SCR позволяет использовать другие параметры для аварийного восстановления, а также посмотрим, как использовать SCR для восстановления.
