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

В 2006 году, во времена Exchange 2007 RTM и Exchange 2007 SP1 RTW, в группе Exchange Product механизм Cluster Continuous Replication (CCR) считался не только решением для локального центра высокой доступности, но и жизнеспособным решением для устойчивости сайтов. Более того, CCR предоставлял базовую функциональность для обеспечения устойчивости сайтов. Конечно, альтернативы существовали. Вы могли (и можете) использовать Single Copy Clusters вместе с третьесторонним решением для репликации, можете передать функцию репликации данных на уровне хранилища вендору хранилища. Некоторые вендоры также позволяли совмещать CCR с репликацией на уровне хранилища, но почему бы не воспользоваться базовой функциональностью вместо того, чтобы тратить средства на разработку дополнительных решений?

Примерно годом позже вышел Exchange 2007 SP1, а вместе с ним – новая функция под названием Standby Continuous Replication (SCR). Механизм SCR разрабатывался специально для сценариев устойчивости сайтов. Но в Exchange 2007 SP1 также была улучшена функция CCR путем создания возможности расположения узлов обхода ошибки кластеров Windows на отдельных подсетях. Поэтому, хотя SCR работает вполне хорошо, некоторые проектировщики Exchange по тем или иным причинам хотят развертывать многосайтовые CCR-кластеры. Это особенно верно теперь, когда вам не нужно растягивать подсети. Честно говоря, многосайтовые CCR-кластеры могут оказаться хорошим решением в случае, если их грамотно развернуть, а также при наличии инфраструктуры и топологии, хорошо работающей как раз с такими технологиями. Вы должны понять, что многосайтовые CCR-кластеры могут обернуться сплошным кошмаром при развертывании в инфраструктуре, для того не предназначенной, или если это развертывание некачественно проведено. В этой статье я объясню особенности развертывания многосайтовых CCR-кластеров, а также дам несколько практических рекомендаций.

Важно: Этот четырехчастный цикл не является пошаговым руководством по развертыванию многосайтовых CCR-кластеров. Для CCR-кластеров в общем пошаговое руководство можно найти в моем цикле статей по развертыванию CCR на серверах Windows Server 2003/2008:

• CCR в Windows Server 2003
• CCR в Windows Server 2008

Какой операционной системой нужно пользоваться?

Итак, на какой операционной системе нужно устанавливать узлы многосайтового CCR кластера? Если бы мне этот вопрос задали год назад, я бы, скорее всего, порекомендовал бы Windows Server 2003, но в Windows Server 2008 также присутствуют некоторые полезные улучшения, касающиеся CCR-кластеров. Более того, теперь, когда у нас есть обновление Exchange 2007 Rollup Update 7 (RU7), большинство багов и проблем при установке Exchange 2007 SP1 на Windows Server 2008 исправлены.

Среди улучшений, касающихся CCR-кластеров, нельзя не упомянуть и кластеры обхода ошибок во множественных подсетях и более быстрая передача файла журнала. Как вы, возможно, знаете, служба Exchange Replication Service использует SMB для передачи файлов журнала. В Windows Server 2008 представлена вторая версия SMB, выполняющая свою работу на 30-40% быстрее первой.

Работа по развертыванию кластера обхода отказа в Windows 2008 теперь намного проще, чем в случае с Windows Server 2003. Более того, вы, должно быть, понимаете, что Windows Server 2003 исчезнет в ближайшую пару лет (более подробно об этом можно почитать здесь). Наконец, вы должны помнить о том, что вам не удастся на месте обновить серверы Exchange 2007 на Windows Server 2003 до Windows Server 2008, если вы решите устанавливать Exchange 2007 на Windows Server 2003. Вместо этого вы должны заменить существующие серверы на новые серверы Exchange 2007 SP1 на основе Windows Server 2008. Или вы можете удалить Exchange 2007 с машин, затем обновить их до Windows Server 2008, после чего переустановить Exchange 2007 SP1. После установки Exchange 2007 SP1 можно восстановить почтовые ящики и общие папки из резервной копии, переподсоединить отключенные LUNы, скопировать файлы EDB обратно на почтовые серверы; либо вы можете воспользоваться какой-нибудь другой стратегией. Более подробно о переходе с серверов Exchange 2007, базировавшихся на Windows Server 2003, на серверы Exchange 2007 SP1, базирующиеся на Windows Server 2008, можно почитать в этой статье на Microsoft TechNet.

Принимая во внимание вышесказанное, рекомендую устанавливать узлы многосайтового CCR-кластера (и сопутствующие серверные роли в Exchange 2007) на машины с Windows Server 2008.

Растянутые или нерастянутые подсети?

Если вы устанавливаете узлы многосайтового CCR-кластера на машины Windows Server 2003, кластерные узлы должны располагаться в одной и той же подсети. Факт тот, что в Windows Server 2003 не поддерживается расположение узлов кластера на разных подсетях. И в таком случае вам нужно растянуть две подсети на два центра данных сетей, используемых кластерными узлами. Растягивание подсети означает, что широковещательный трафик будет направляться с помощью WAN между центрами данных. Принимая во внимание возможное количество людей в сети организации, существует достаточно большая вероятность того, что данное требование остановит всю работу. Однако лично я работал в нескольких проектах, где это не стало проблемой: в организации была 10ГБ связь между центрами данных. Мы просто создавали сеть VLAN и растягивали ее между центрами данных.

В Windows Server 2008 отсутствует требование растянутости подсетей, т.к. в Windows Server 2008 маршрутизируемые сети полностью поддерживаются. Как вы видите в Create Cluster Wizard на Рисунке 1, теперь у нас есть возможность указать два IP-адреса для кластера Windows Server 2008 Failover Cluster; один принадлежит подсети основного центра данных, а второй – подсети резервного центра данных.

ЗамечаниеИнтерфейс частной подсети не располагается в растянутой подсети, вам необходимо использовать маршрутизацию между двумя различными подсетями на каждом физической сайте. Для такого случая есть специальные требования, когда дело доходит до настройки интерфейса для частной подсети. Поскольку Тим Макмайкл (Tim McMichael – специалист по отправке сообщений в предприятиях из Microsoft) создал целый блог на ту тему, я не буду углубляться в подробности здесь.

На Рисунке 2 вы видите дерево зависимостей со структурой зависимостей, основанной на ‘OR’ для двух IP-адресов (расположенных в разделенных подсетях), приписанных в качестве ресурса имени сети кластера. В традиционных кластерах поддерживалось ‘AND’, но кластер Windows Server 2008 также поддерживает ‘OR’, используемое в моменты, когда многосайтовые кластеры имеют IP-адреса в разных подсетях.

Для создания отчета о зависимостях щелкните правой кнопкой мыши на наименовании сети кластера и выберите Dependency Report в контекстном меню (Рисунок 3).

После создания кластера Windows Server 2008 Failover Cluster и установки роли Exchange 2007 Active Mailbox на кластерном узле в основном центре данных у вас появляется возможность указать IP-адрес, который приписывается серверу Clustered Mailbox Server (CMS) каждой подсети (Рисунок 4). Хотя я и не рекомендую этого, вы можете использовать даже IP-адреса, выделенные DHCP, и адреса IPv6, если хотите.

Хотя вы можете установить роли Active Mailbox server и Passive Mailbox server с помощью мастера Exchange 2007 Setup Wizard, при этом вы столкнетесь с некоторыми сложностями. Поэтому вместо этого я рекомендую использовать командную строку при установке нового CMS. Для установки роли Active Clustered Mailbox через Setup.com на кластерном узле в основном центре данных, воспользуйтесь следующей командой:

Setup.com /Mode:install /Roles:mailbox /NewCMS /CMSName:<CMS name> -CMSIPv4Addresses:<IP1>,<IP2>

Для установки роли Passive Mailbox на кластерном узле в резервном центре данных воспользуйтесь следующей командой:

Setup.com /Roles:mailbox

Сетевые карты

Самый лучший вариант – иметь 4 сетевых карты (или более) на каждом узле CCR-кластера. Обычно я устанавливаю 5 сетевых карт на каждом узле. Два сетевых интерфейса в общей сети (настроенные в режиме отказоустойчивой работы. Не делайте балансировку нагрузки между ними, так как, по опыту, это приводит к различным проблемам). Два сетевых интерфейса для передачи журнала (с целью реализации избыточности при передаче журнала). И, наконец, один сетевой интерфейс для резервного копирования (неиспользуемый кластером), чтобы вам не нужно было создавать резервные копии баз данных через общую сеть. Это дает нам 3 независимых пути для репликации и 3 независимых пути для активного взаимодействия между кластерными узлами. Когда вы установите все эти сетевые карты на каждом узле кластера, крайне рекомендуется дать им осмысленные имена с помощью консоли Failover Cluster Management (Рисунок 7). Просто щелкните правой кнопкой мыши на них и выберите rename из контекстного меню.

Хотя для CCR-кластеров это не возбраняется, все же я рекомендую отключить IPv6 на всех серверах Exchange и контроллерах доменов (если вы, конечно, не один из немногих использующих IPv6). Подробно об отключении IPv6 можно прочитать здесь.

Также вам следует задуматься о влиянии функции Scalable Networking Pack, которую можно найти на серверах Exchange 2007, поставленных на Windows 2003, в вашей среде. Подробную информацию о функции Scalable Networking Pack и о ее влиянии на Exchange вы найдете здесь: http://msexchangeteam.com/archive/2007/07/18/446400.aspx. Обычно лучше отключить функцию Scalable Networking Pack на всех серверах Exchange 2007 вашей организации.