Red Line Software - мы помогаем вам управлять эффективностью работы вашего офиса.

Возможно, самой важной чертой Exchange 2007 Service Pack 1 является резервная непрерывная репликация (Standby Continuous Replication - SCR). Вкратце SCR дает возможность репликации информации от базы данных Exchange на вашем рабочем сервере на резервный сервер, который вводится в действие, когда теряется информация с рабочего сервера. Хотя существующие технологии Exchange 2007, такие как непрерывная кластерная репликация (Clustered Continuous Replication – CCR), предлагают высокую работоспособность, наилучшая устойчивость обеспечивается с помощью SCR. Это происходит из-за того, что может стать проблематичным применить CCR между центрами данных из различных IP-подсетей, так как члены CCR кластера обязаны быть в одной подсети при использовании Windows 2003 в качестве операционной системы. И хотя иногда к этому требованию обращаются, многие организации используют SCR в центре резервного копирования данных и предпочитают вручную инициализировать серверы SCR в случае отказа рабочего центра данных. Довольно часто желательно вручную вмешаться для переноса системы Exchange на резервный центр данных, а не полагаться на автоматические процессы.

В трех частях этой серии статей мы проследим за процессом реализации SCR между двумя CCR средами. Идея этой статьи зародилась тогда, когда я заинтересовался сутью процедуры перемещения кластеризованного сервера почты (Clustered Mailbox Server - CMS) из одной среды CCR на другую и обратно. Очевидно, в реальном мире эти среды CCR были бы в различных центрах данных, но для целей данной статьи все сервера будут представлять собой виртуальные серверы, сконфигурированные на одной и той же сети. Для простоты я буду использовать термины рабочий центр данных (production datacenter) and резервный центр данных(backup datacenter), чтобы не возникало сомнений, с какой средой мы работаем в конкретный момент времени. В этой статье мы рассмотрим процессы:

• Включение SCR между двумя CCR средами. В действительности, CCR среда в резервном центре данных представляет собой резервный кластер и является, таким образом, парой пассивных узлов, готовых взять во владение и запустить CMS.
• Симулирование потери рабочей среды CCR и, следовательно, необходимости переноса CMS на резервный кластер в резервном центре данных.
• Перемещение CMS обратно в CCR среду в рабочем центре данных, когда работоспособность этого центра будет восстановлена.

Конфигурация сервера

Давайте посмотрим на те 5 серверов, которые есть в моей виртуальной среде и которые будут использоваться для создания и тестирования SCR сценария. Вот они:

• NH-W2K3-SRV02, комбинированный контроллер доменов, сервер клиентского доступа и транспортный сервер-концентратор.
• NH-W2K3-SRV03, в начальном состоянии установленный как активный узел рабочей CCR среды.
• NH-W2K3-SRV04, в начальном состоянии установленный как пассивный узел рабочей CCR среды.
• NH-W2K3-SRV01, первый пассивный узел резервного кластера.
• NH-W2K3-SRV05, второй пассивный узел резервного кластера.

Поскольку в именах серверов содержатся инкрементальные номера, было бы хорошо не ставить сервера NH-W2K3-SRV01 и NH-W2K3-SRV05 в качестве резервного кластера, но, к сожалению, я уже настроил CCR среду на сервер NH-W2K3-SRV04, и, следовательно, не хотел переустанавливать всю среду. На самом деле, сервер NH-W2K3-SRV01 использовался в качестве пограничного транспортного сервера (Edge Transport server), поэтому и сервер NH-W2K3-SRV02 использовался как комбинированный контроллер доменов, сервер клиентского доступа и транспортный сервер-концентратор.

Также необходимо назвать еще несколько имен:

• Текущий рабочий кластер - E2K7CLU01.
• Резервный кластер для резервного центра данных - E2K7CLU02.
• Имя CMS - CCREX01. Именно к этому имени обращаются клиенты Outlook.

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

Кроме того, еще необходимо добавить, что все серверы работают с Windows 2003, то есть все рекомендации данной статьи годны для Windows 2003, а не для Windows 2008. Если вы работаете с Windows 2008, нужны немного другие действия, которые не будут объясняться в этой статье. Возможно, это будет темой одной из следующих статей на msexchange.org, как только Windows 2008 начнут развертывать.

Установка резервного кластера

Как я уже упоминал, необходимо отметить разницу между рабочей CCR средой и резервным кластером в резервном центре данных. Рабочая среда устанавливается согласно статье Хенрика Вальтера, Installing, Configuring and Testing an Exchange 2007 CCR Based Mailbox Server на MSExchange.org. Резервный кластер устанавливается немного другим образом, поскольку он не проектируется на работу с CMS в начале. Короче говоря, основное различие состоит в том, что вместо установки роли Active Clustered Mailbox Role на один кластерный узел и роли Passive Clustered Mailbox Role на другой кластерный узел (как в случае с CCR), оба резервных кластера будут устанавливаться только с ролью Passive Clustered Mailbox Role. Поэтому в моей тестовой сети серверы NH-W2K3-SRV01 и NH-W2K3-SRV05 настраиваются на роль Passive Clustered Mailbox Server. Это настраивается в процессе установки Exchange 2007, что показано на Рисунке 1.

Рисунок 1: Установка Passive Clustered Mailbox Server

Стоит заметить одну вещь в процессе установки резервного кластера SCR: пути для файлов базы данных и журнала должны быть одинаковыми и для источника SCR, и для целевой машины SCR. Другими словами, если CCR среда настраивается на то, чтобы помещать все файлы базы данных в E:\Databases, тогда расположение баз данных для резервных кластерных узлов также будет установлено в E:\Databases, когда SCR будет включаться.

Активация SCR

Поскольку это статья по использованию SCR для обработок отказа между двумя CCR средами, первое, что необходимо сделать – включить SCR для обеих групп хранения на CMS. Это можно сделать с помощью команды Enable-StorageGroupCopy с важным параметром 'StandbyMachine. Так как целевая SCR представляет собой резервный кластер, состоящий из двух пассивных узлов, любой из них можно установить с параметром 'StandbyMachine и сделать, соответственно, активным узлом с CMS, когда его восстановят. В этой статье я выберу NH-W2K3-SRV01 в качестве целевого сервера SCR. Также была обновлена команда Enable-StorageGroupCopy так, чтобы включать параметр 'ReplayLagTime, который используется для указания количества времени, которое должно истечь, прежде чем файлы журнала, которые были реплицированы на целевой сервер SCR, в действительности сменяются в базе данных. Это полезно в некоторых ситуациях, например, когда базы данных в рабочей среде подвергаются логическому повреждению, вы имеете время для проверки того, что повреждения не происходит на целевом сервере. По умолчанию значение параметра 'ReplayLagTime установлено на 1 день, а я хочу сменить это значение в тестовой среде и сделать его равным 0. Вот список всех команд для включения SCR для обеих групп хранения:

Enable-StorageGroupCopy 'CCREX01\First Storage Group' 
'StandbyMachine NH-W2K3-SRV01 'ReplayLagTime 0.0:0:0

Enable-StorageGroupCopy 'CCREX01\Second Storage Group' 
'StandbyMachine NH-W2K3-SRV01 'ReplayLagTime 0.0:0:0

Исполнение этих команд показано на Рисунке 2.

Рисунок 2: Команды Enable-StorageGroupCopy

После выполнения всех вышеуказанных команд создаются копии двух групп хранения на машине NH-W2K3-SRV01. На Рисунке 3 ниже вы можете увидеть содержимое папки First Storage Group на NH-W2K3-SRV01. Поскольку в моей тестовой среде я выбрал хранение файлов баз данных и журнала транзакций в одной папке, вы можете заметить отсутствие, по крайней мере, одного файла в этой папке: текущего файла базы данных. Причину этого я объясню во второй части этой серии статей.

Рисунок 3: Содержимое папки первой группы хранения

Заключение

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

Автор: Нейл Хобсон (Neil Hobson)

Нейл является основным консультантом в Silverslands (www.silversands.co.uk), Золотом партнере Microsoft в Великобритании и отвечает за разработку, применение и поддержку приложений для многих крупных клиентов по всей Европе. В IT отрасли он трудится с 1987 года и специализируется на отправке сообщений с 1995. Он начинал работать еще с Exchange 4.0. Он также обладает званием Exchange MVP и уделяет некоторую часть своего личного времени на помощь различным пользователям Exchange, ведет блоги, посвященные Exchange. Эти блоги вы можете найти по адресу www.msexchangeblog.com. С Нейлом можно связаться по адресу neil.hobson@silversands.co.uk.