Развертывание многосайтовых CCR кластеров Exchange 2007 – что нужно и чего не нужно делать (часть 4)

В предыдущей части этого цикла статей мы рассматривали стратегии транспортной корзины, а также размещение и настройку свидетеля файлового ресурса.

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

Поведение обхода отказа между двумя узлами кластера

Если доступны два голоса, обход отказа сервера CMS на пассивный узел в резервном центре данных произойдет автоматически. Это означает, что в отличие от SCR, не требуется никакого вмешательства и ручной работы в этом процессе. Сначала это может показаться отличной идеей, поскольку потребуется выполнить на один шаг меньше во время обхода отказа сайта. Но уверены ли вы, что вам действительно нужно выполнить обход отказа сервера CMS на резервный центр данных таким образом? Этот вопрос зависит от таких моментов, как количество пользователей, пропускная способность сети между центрами данных, количество баз данных групп хранения/почтовых ящиков. Представьте, что на основном центре данных возникает незапланированный незначительный сбой сети, в результате чего срабатывает процесс автоматического перевода CMS на аварийный центр данных. В худшем случае перевод сервера CMS при отказе займет 30 минут. Помимо всего прочего возникает ситуация, в которой все серверы Exchange HT и CAS, контроллеры домена /серверы глобальных каталогов, а также клиенты Outlook должны теперь взаимодействовать с сервером CMS, который расположен в аварийном центре данных. Если вы не хотите допускать возникновения автоматического обхода отказа сервера CMS в ситуации, когда IP адрес или сетевое имя кластера недоступно, вам нужно приостановить службу кластера на пассивном узле.

Примечание: Причина, по которой нужно лишь приостановить, а не полностью останавливать службу кластера на пассивном узле, заключается в том, что если поставить узел на паузу, существующие группы и ресурсы останутся в режиме онлайн, а дополнительные группы и ресурсы не смогут выйти в режим онлайн на этом узле. В результате служба кластеров не остановит запись логов, которая происходит между узлами кластера. Однако остановка службы кластеров на пассивном узле прекратит работу кластера и прервет запись логов до тех пор, пока служба кластера не будет снова запущена.

Поставьте службу кластера на узле аварийного кластера Windows Server 2008 на паузу, откройте консоль управления аварийным кластером > разверните объект кластер (cluster), а затем Узлы (Nodes). Теперь нажмите правой клавишей на пассивном узле и выберите опцию Пауза (Pause) в контекстном меню, как показано на рисунке 1 ниже.

Можно также приостановить кластер с помощью cluster.exe. Для этого воспользуйтесь следующей командой:

CLUSTER.EXE <name of WFC> NODE <name of node> /PAUSE

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

Вдобавок, если службы ядра кластера не принадлежали пассивному узлу в резервном центре данных, когда мы поставили кластер на этом узле на паузу, необходимо принудительно запустить ресурсы ядра кластера в режим онлайн, прежде чем снова запускать узел кластера после потери активного узла кластера в основном центре данных. Чтобы посмотреть, какому кластеру принадлежат ресурсы ядра кластера, нажмите на кластере под Failover Cluster Management, а затем разверните Cluster Core Resources в средней панели. Здесь вы увидите текущего владельца ресурсов ядра кластера, как показано на рисунке 4. Чтобы в принудительном порядке вывести ресурсы ядра кластера в режим онлайн на пассивном узле, нажмите правой клавишей на IP адресе, назначенном приостановленному узлу, и выберите опцию Вывести эти ресурсы в режим онлайн (Bring this resource online) в контекстном меню.

Хотя пассивный узел был поставлен на паузу, когда активный узел вышел из строя, пассивный узел стал текущим владельцем ресурсов кластера/Exchange.

Чтобы вернуть ресурсы в режим онлайн, нажмите правой клавишей на пассивном узле и выберите опцию Возобновить (Resume) в контекстном меню (рисунок 5).

Теперь откройте оболочку Exchange Management Shell и введите следующую команду, чтобы включить CMS на пассивном узле:

Start-ClusteredMailboxServer <CMS Name>

Ресурсы кластера и Exchange теперь будут возвращены в режим онлайн, и клиенты Outlook смогут подключиться к почтовому ящику.

Как обход отказа влияет на пользователей Outlook 2007

Итак, теперь, когда мы настроили свой многосайтовый CCR кластер в соответствии с рекомендациями к лучшим методикам, давайте попробуем сымитировать ситуацию обхода отказа сервера CMS на аварийный центр данных. Давайте посмотрим, как это влияет на пользователей Outlook в организации. На рисунке 7 ниже у нас есть снимок клиента Outlook 2007, подключенного (в режиме кэша) к почтовому ящику, хранящемуся на нашем сервере CMS, который в настоящее время находится в режиме онлайн на узле кластера основного центра данных.

Давайте переместим сервер CMS на пассивный узел кластера в резервном центре данных. Для этого можно воспользоваться следующей командой:

Move-ClusteredMailboxServer <CMS> -TargetMachine < passive cluster node> -MoveComment Test

Рисунок 8: Перемещение сервера CMS на пассивный узел кластера в резервном центре данных

Как показано на рисунке 9 ниже, сервер CMS сейчас недоступен, поскольку он перемещается на пассивный узел резервного центра данных.

Когда CMS возвращен в режим онлайн, запись DNS необходимо обновить IP адресом, который был назначен серверу CMS в подсети резервного центра данных. По умолчанию эта запись имеет значение TTL в 20 минут. Но как вы видели ранее в этой статье, мы изменили TTL значение записи DNS на 5 минут. Однако это не означает, что Outlook возобновит работу после пяти минут. Слияние клиента Outlook составляет (10 минут на издание обновления, поскольку многосайтовый кластер Windows 2008 задерживает обновление записи на сервере DNS на 10 минут) + (задержка репликации сервера DNS) + (оставшееся или полное время в КЭШе преобразователя на истечение TTL), поэтому следует ожидать от 10 до 30 минут (последнее подходит для больших или медленных сред с большим количеством DNS серверов).

Хорошая новость заключается в том, что когда Outlook 2003/2007 работает в режиме кэширования, пользователь может продолжить работу и может даже не заметить, что Outlook работает в автономном режиме. Также конечным пользователям не придется перезапускать клиента Outlook, он автоматически восстановит подключение.

Как большинство из вас знает, Outlook 2007 использует службу доступности/автообнаружения (availability/autodiscover). После обхода отказа клиент Outlook 2007 просто выберет CAS сервер в резервном центре данных для службы availability/autodiscover.

На рисунке 11 видно, что Outlook не может подключиться к двум серверам CAS в основном центре данных и переходит к серверу CAS в резервном центре данных, когда мы тестируем Autodiscover.

Если вы используете Outlook 2003, то OAB и поиски free/busy полагаются на ваши системные папки в базе данных публичной папки. Если у вас установлены клиенты Outlook 2003, убедитесь, что у вас есть копия иерархии публичной папки (PF) на резервном центре данных.

Выполнение резервного копирования на резервном центре данных

Еще одна вещь, в которой необходимо убедиться и которая включена в ваш план восстановления после экстренных ситуаций, это резервное копирование сервера CMS на резервном центре данных. Готовы ли вы к этому, когда сервер CMS переведен на другой узел? Я хочу сказать, что в худшем случае вы потеряете свой основной центр данных и будете ограничены использованием только одной точки восстановления. Это сделает такие дополнительные резервные копии очень важными, поскольку воссоздание утраченного центра данных может занять недели или даже месяцы, в зависимости от степени повреждений.

Заключение

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