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

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

В этой части мы продолжим с того места, на котором остановились в предыдущей части. Мы рассмотрим стратегии растянутых сайтов Active Directory и рекомендуемые значения таймаута для сетевой задержки и тактовых импульсов (Network Latency и Heartbeat).

Растянутый сайт Active Directory

Независимо от того, используете ли вы Windows Server 2003 или Windows Server 2008 в качестве основной операционной системы для своих серверов Exchange 2007, узлы кластера CCR всегда должны располагаться на одном сайте Active Directory (AD). Это означает, что, хотя узлы могут находиться в разных подсетях, вам все равно нужно растянуть AD сайт, к которому они принадлежат, между двумя центрами данных. Некоторые из вас, вероятно, слышали, что кластеры Windows Server 2008 Failover Clusters поддерживают узлы, расположенные в различных сайтах AD, и хотя это правда, Exchange не может располагать узлы CCR кластера на различных сайтах AD.

Поскольку узлы кластера CCR должны принадлежать одному сайту AD, этот AD сайт необходимо растянуть между двумя центрами данных. Для роли сервера Hub Transport это может означать, что сообщения, отправляемые и принимаемые пользователями, чьи почтовые ящики хранятся на расположенном в основном центре данных CMS, могут теоретически приниматься с и отправляться на серверы Hub Transport (HT) в резервном центре данных. То же самое подходит и для таких клиентских запросов Exchange как автообнаружение (Autodiscover), OWA, EAS, POP3, и IMAP запросы/подключения к Client Access Servers (CAS). К тому же, LDAP/auth запросы на серверы глобальных каталогов (GCs) могут также передаваться на серверы в резервном центре данных. Как вы можете себе представить, это может генерировать большой объем трафика между центрами данных. Это особенно верно для серверов HT и CAS, а клиент Outlook использует MAPI по RPC для взаимодействия с серверами почтовых ящиков Exchange 2007 Mailbox.

Однако вы можете заблокировать подключения/запросы, идущие на серверы в резервном центре данных. Что касается подписки сообщений с CMS на любой HT сервер в сайте AD, вы можете использовать Set-MailboxServer команду с -SubmissionServerOverrideList параметром для указания того, какие серверы Hub Transport должны использоваться. Таким образом, вы сможете исключить HT серверы, расположенные в резервном центре данных, несмотря на то, что они принадлежат одному AD сайту.

Если/когда произойдет катастрофа в основном центре данных, в результате чего нужно будет обходить отказ на резервном центре данных, просто обновите список замены подписки, чтобы он включал лишь серверы HT в резервном центре данных.

Чтобы заблокировать запросы/подключения CAS сервера для отправки на серверы в резервном центре данных, вы можете воспользоваться механизмом компенсации нагрузки. Если у вас большая среда, велика вероятность того, что вам придется, либо применить решение на базе аппаратных средств, либо на основе WNLB (смотреть эту статью о том, как компенсировать нагрузку серверов CAS). Если дело обстоит именно так, вот, что нужно сделать:

• Создайте NLB массив, который включает все CAS серверы, расположенные в основном центре данных. Настройте внутренний URL для Autodiscover, OWA, OAB, EWS и UM, чтобы он указывал на FQDN (namespace.company.com) решения компенсации нагрузки. Все запросы, которые достигают указанного FQDN, затем будут передаваться на CAS серверы в основном центре данных.
• Теперь создайте другой NLB массив для CAS серверов резервного центра данных, используйте тот же FQDN, но воспользуйтесь IP адресом, отличным от того, который вы использовали для первого NLB массива. К тому же, необходимо убедиться в том, что вы лишь создаете запись в DNS для первого NLB массива, в противном случае запросы будут распределяться между двумя NLB массивами.
• Если/когда катастрофа поразит основной центр данных, в результате чего придется обходить отказ на аварийном центре данных, просто обновите NLB запись в DNS, чтобы она указывала на IP адрес массива NLB, созданного для CAS серверов, которые расположены в аварийном центре данных. Затем дождитесь, пока изменения не будут применены на всех серверах DNS в вашей организации.
• Что касается GCs, вы можете настроить Outlook клиентов на использование GCs, расположенных в основном центре данных. Эти шаги прописаны в данной статье базы знаний.
• Хотя вышеуказанная конфигурация блокирует запросы/подключения, не позволяя им доходить до серверов в резервном центре данных, она вносит больше сложности в вашу среду. Однако не стоит бояться, всегда есть иной способ, который я опишу в следующем разделе.

Использование двух сайтов Active Directory в резервном центре данных

Чтобы устранить возможность взаимодействия серверов и клиентов основного центра данных с серверами Exchange 2007 и GCs в резервном центре данных, вы можете создать дополнительный сайт AD в резервном центре данных, а затем переместить все серверы, за исключением Windows Failover Cluster, на котором установлена роль пассивного Mailbox, на этот сайт AD, как показано на рисунке 1.

Когда случится катастрофа, основной центр данных выполнит обход отказа на резервный центр данных. Далее нужно будет переместить серверы с второго сайта AD (AD сайт 2) на растянутый AD сайт (AD сайт 1), предоставив каждому серверу IP адрес в подсети растянутого AD сайта или путем изменения дефиниций AD сайта в оснастке Active Directory Sites and Services MMC. Некоторые из вас, возможно, подумают, что было бы проще переместить CMS на второй AD сайт, но это предоставит возможность HT серверу повторно предоставлять сообщения на CMS, что обернется потерей данных во время обхода отказа и не является поддерживаемым методом.

Значения таймаута для сетевой задержки и тактового импульса (Network Latency и Heartbeat)

Во время установки многосайтового CCR кластера вы должны попытаться удерживать сетевую задержку между центрами данных менее 500 миллисекунд (мс).

Учитывая вышесказанное, вы можете просто настроить агрессивность таймаутов тактовых импульсов, что поможет вам избежать бесполезных обходов отказа при возникновении временных сетевых проблем. По умолчанию количество пропущенных импульсов кластера настроено на 5 импульсов для обоих узлов, расположенных в одной подсети и узлов в различных подсетях (рисунок 2). При работе с многосайтовыми кластерами рекомендуется изменить это значение на 10 пропущенных импульсов (приблизительно 12 секунд).

Чтобы изменить предел CrossSubnetThreshold на десять пропущенных импульсов вместо стандартных пяти, используйте следующую команду:

cluster ClusterName /prop CrossSubnetThreshold=10

Можно проверить новое значение предела пропущенных импульсов с помощью следующей команды:

Cluster.exe /cluster:<ClusterName> /prop

Примечание: позже в этом цикле статей мы остановим пассивный узел кластера, что означает, что обход отказа не произойдет автоматически даже несмотря на то, что у вас есть два доступных узла (один узел кластера и File Share Witness (FSW)). Если вы не используете метод приостановки кластера, вышеупомянутые параметры импульсов настоятельно рекомендуются, ели вы не хотите, чтобы обход отказа возник из неоткуда.

Значения DNS Time to Live

При перемещении CMS (во время запланированного обхода отказа) с узла кластера в одной подсети на узел кластера в другой, и возвращении в рабочий режим IP адреса и ресурсного имени сети, кластер обхода отказа сбрасывает таймер. После десяти минут, когда ресурсное имя сети и IP адрес расположены на кластере, выполняется обновление DNS записи.

По умолчанию DNS Time to Live (TTL) значение для ресурсного имени сети составляет 20 минут. Это означает, что при достижении таймером значения в 10 минут, вам придется ждать еще 20 минут для получения DNS записи (рисунок 4). Добавьте к этому время, необходимое на применение обновлений ко всем контроллерам домена в организации. Кроме того кэшу преобразователя клиентской стороны на клиентах Outlook также потребуется некоторое время на обнаружение обновлений.

Плюс ко всему, 30 минут считается слишком длительным периодом в большинстве сред. Самой лучшей методикой считается смена значения DNS TTL на 5 минут. Для этого нужно сначала найти ресурсное имя сети кластера CMS. Это можно сделать с помощью следующей команды на одном из узлов кластера:

cluster /cluster:<Name of CMS> res

Теперь, когда у нас есть имя сети кластера, давайте изменим значение TTL на 5 минут. Для этого воспользуемся следующей командой:

Cluster.exe res <CMSNetworkNameResource> /priv HostRecordTTL=300

Остановка и запуск Clustered Mailbox Server (CMS) с помощью Stop-ClusteredMailboxServer и Start-ClusteredMailboxServer команд или мастера Manage Clustered Mailbox Server.

Примечание: хотя некоторые захотят так сделать, не стоит пытаться изменить DNS TTL через страницу свойств DNS записи в DNS диспетчере, поскольку параметры будут перезаписаны значением, настроенным для HostRecordTTL на узлах кластера при каждом обновлении DNS записи. Запись будет обновляться, когда CMS запускается, перемещается или возвращается в рабочий режим после отказа или обхода отказа.

Теперь давайте проверим, что TTL для DNS записи изменено с 20 на 5 минут. Для этого мы открываем страницу свойств DNS записи ресурсного имени сети кластера CMS в DNS диспетчере на сервере DNS, как показано на рисунке 7.

Итак, на этом закончим вторую часть этого цикла статей о том, что нужно и чего не нужно делать в многосайтовых кластерах CCR.