Давайте начнем с истории. До выхода Exchange 2007 функции отказоустойчивости и восстановления после сбоев, включенные в продукты Exchange Server, были весьма ограничены. Предыдущие версии Exchange (Exchange 2003 и ранее) могли использовать сервисы кластеров Microsoft Cluster Services (MSCS), но эта функция обеспечивала избыточность только на аппаратном уровне, поскольку узлы совместно использовали одну и ту же подсистему хранения. Если активный узел кластера внезапно становился недоступным, то виртуальный сервер Exchange Virtual Server (EVS) и все соответствующие ресурсы кластера переводились на пассивный узел, после чего конечные пользователи могли продолжать работу.

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

Большинство из нас согласится с тем, что с выходом Exchange 2007 эти возможности стали реальными! Exchange 2007 предоставил нам целый ряд принципиально новых функций отказоустойчивости и восстановления после сбоев, таких как функция локальной непрерывной репликации (Local Continuous Replication - LCR), которая предназначалась для малых организаций, и непрерывная кластерная репликация (Cluster Continuous Replication - CCR), предназначенная для средних и крупных предприятий. Позже (с выходом Exchange 2007 SP1) появилась функция непрерывной резервной репликации Standby Continuous Replication (SCR), которая предназначена для предприятий всех размеров. Все три функции использовали новую технологию асинхронной репликации, которая работала путем передачи файлов логов в пассивную копию группы хранения и после осмотра преобразовывала их в эту пассивную копию.

Хотя LCR обеспечивала избыточность на уровне хранилища, эта функция так и не получила широкого распространения. Причиной тому стало то, что поскольку копии групп хранения нужно хранить на локальном томе сервера почтовых ящиков (Mailbox), такая конфигурация представляла собой единую точку сбоя на аппаратном уровне. С выходом Exchange 2007 функция CCR стала очень успешной. Интересным моментом в CCR было то, что она сочетала использование новой технологии асинхронной репликации, представленной в Exchange 2007, с технологией кластеров обхода отказа (Windows Failover Clustering), тем самым обеспечивая избыточность на аппаратном уровне, равно как и на уровне хранилища, что делало ее истинным решением отказоустойчивости, не имеющим единой точки сбоя.

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

С выходом Exchange 2007 SP1 мы получили именно эту функциональность. Функция под названием Standby Continuous Replication (SCR) сделала возможным передачу файлов логов на другой сервер почтовых ящиков Exchange 2007 Mailbox Server. Поскольку функции SCR не требовалось использование Windows Failover Clustering, файлы журналов могли передаваться с кластерных и не-кластерных серверов почтовых ящиков (источник SCR) на кластерные и не-кластерные серверы почтовых ящиков (SCR цель). Интересным моментом в SCR было то, что можно было задавать время запаздывания преобразования журнала до 7 дней, что позволяло исправлять большинство проблем, связанных с базами данных/хранением, прежде чем они могли нанести ущерб SCR цели, расположенной в другом центре данных.

Примечание: Exchange 2007 Service Pack 2 – это в большей степени пакет обновления, который подготавливает существующие Exchange 2007 организации к переходу на Exchange 2010, поэтому в этом пакете отсутствуют какие бы то ни было значительные изменения или усовершенствования в области отказоустойчивости или гибкости на уровне сайтов.

В силу того, что функции CCR и SCR уже доступны, можно подумать, что в каких-либо изменениях или улучшениях в области отказоустойчивости или надежности сайтов нет необходимости в новой и лучшей версии Exchange 2010, не так ли?

Надо признать, что последние пару лет группа разработчиков продукции Exchange потратила на разработку Exchange 2010, при этом большая часть времени была затрачена на значительное усовершенствование функций отказоустойчивости и устойчивости сайтов.

Изменения функций отказоустойчивости в Exchange Server 2010

В версии Exchange 2010 уже отсутствуют такие понятия, как Local Continuous Replication (LCR), Single Copy Clusters (SCC), Cluster Continuous Replication (CCR) или Standby Continuous Replication (SCR). ЧТО!? Скажут некоторые из вас! Да, я не шучу. Но если говорить точнее, только LCR или SCC были полностью убраны из продукта Exchange Server. CCR и SCR были объединены и преобразованы в более унифицированную инфраструктуру отказоустойчивости, в которой новая группа доступности баз данных (Database Availability Group - DAG) выступает в качестве базового компонента. Это означает, что вы будете использовать DAG независимо от того, собираетесь ли вы установить локальное решение отказоустойчивости и восстановления после сбоев, или же решение на уровне сайтов. Чтобы прояснить свои мысли скажу, что в Exchange 2010 вашим единственным способом защиты баз данных почтовых ящиков будет использование DAG.

Основным компонентом в DAG является новый компонент под названием активный диспетчер (Active Manager). Вместо Exchange кластерного ресурса DLL (exres.dll) и связанных с кластерными службами ресурсов, которые требовались для кластера Exchange 2007 и предыдущих версий Exchange, Exchange 2010 теперь полагается на Active Manager при управлении переходом между серверами почтовых ящиков DAG. Active Manager работает на серверах почтовых ящиков в определенной DAG. У нас есть две активные роли диспетчера, основной активный диспетчер (Primary Active Manager - PAM) и аварийный активный диспетчер (Standby Active Manager - SAM). Для подробной информации о ролях PAM и SAM обратитесь к соответствующей Exchange 2010 Online документации на Microsoft TechNet.

Так что же интересного в DAG? Есть много вещей; самые примечательные перечислены ниже:

Ограниченная зависимость от Windows Failover Clustering - группа DAG использует лишь ограниченный набор кластерных функций, предоставляемых компонентом Windows Failover Clustering. DAG использует кластерную базу данных, импульсные сигналы и функцию свидетеля файлового ресурса. Exchange 2007 (и более ранние версии) работали под управлением Windows Failover Cluster. Exchange 2010 не работает под управлением этого компонента. Кластерный ресурс DLL (exres.dll) и все ресурсы кластера, создаваемые им при регистрации, были удалены из программы Exchange 2010.

Инкрементная установка - поскольку группы DAG все еще используют некоторые компоненты WFC, такие как база данных кластера, импульсный сигнал и свидетель файлового ресурса, Windows Server 2008 SP2 или R2 Enterprise версия необходима для настройки серверов Exchange 2010 Mailbox в DAG. Но Exchange 2010 поддерживает инкрементный подход установки, что означает, что нет необходимости в создании кластера до установки Exchange 2010. Можно установить серверы Exchange 2010 Mailbox, а затем создать DAG и добавить серверы и любые базы данных в DAG при необходимости.

Сосуществование с другими ролями Exchange - при использовании CCR у нас не было возможности установить другие роли сервера Exchange на серверы почтовых ящиков (узлы кластера), которые были защищены CCR. При использовании DAG на ее компонент серверов почтовых ящиков можно устанавливать другие роли Exchange. Это особенно полезно для малых предприятий. Поскольку теперь DAG защищенный сервер почтовых ящиков может работать совместно с другими ролями Exchange, это означает, что вы можете создавать полностью избыточное Exchange 2010 решение всего на двух машинах, выделенных под серверы Exchange. Конечно, вам придется настраивать свидетеля файлового ресурса, но им может стать любой в вашей среде. Свидетель файлового ресурса не обязательно должен работать под управлением той же версии Windows, что и серверы Exchange 2010. Он просто должен работать под управлением Windows сервер 2003 или выше. Еще одним моментом, который следует учитывать, является то, что если вы решите использовать два сервера Exchange 2010, и вам нужно полностью избыточное решение, вам необходимо использовать внешнее аппаратное оборудование или программное решение по компенсации нагрузки для служб Client Access.

Управляется на 100% посредством инструментов Exchange - с использованием CCR в Exchange 2007 нужно было настраивать и управлять кластерами CCR с помощью комбинации инструментов Exchange и инструментов управления кластерами. При использовании DAGs в Exchange 2010 вам больше не нужно использовать инструменты по управлению кластерами ни для начальной конфигурации, ни для управления. Вы можете управлять группами DAG, используя исключительно инструменты управления Exchange. Это означает, что администраторы Exchange на предприятии больше не нуждаются в опыте работы с кластерами (хотя этот опыт все еще полезен).

Репликация на уровне баз данных - для поддержки новой функции групп DAG базы данных в Exchange 2010 теперь перемещены на уровень организации, а не на уровень сервера, где они находились в предыдущих версиях Exchange. Это также означает, что Exchange 2010 более не использует концепцию групп хранения. Теперь это базы данных и поток журналов, связанный с каждой базой данных. Одним из слабых мест CCR было то, что даже если одна база данных давала сбой на активном узле кластера, все активные базы данных, расположенные на кластерном почтовом сервере, перемещались на пассивный CCR узел. Это влияло на всех пользователей, у которых почтовые ящики хранились на таком сервере CMS.

Поддержка до 16 членов в каждой группе DAG - теперь вы можете добавлять до 16 серверов почтовых ящиков в группу DAG и иметь 16 копий каждой базы данных Mailbox, Exchange 2010 поддерживает больше баз данных почтовых ящиков, чем Exchange 2007. Теперь верхний предел был поднят с 50 до 100 баз данных Mailbox в Exchange 2010 версии Enterprise. Однако версия Standard поддерживает лишь до 5 баз данных для каждого сервера Mailbox.

Переходы Switch/Fail-overs гораздо быстрее - благодаря улучшениям, внесенным в Exchange 2010 DAG, мы получили гораздо более быстрое переключение и переход (switches and fail-overs (*-overs)) между копиями баз данных почтовых ящиков. Этот переход будет осуществляться менее чем за 30 секунд по сравнению с несколькими минутами при использовании CCR в Exchange 2007. К тому же, поскольку Outlook MAPI клиенты теперь подключаются к службе RPC Client Access на серверах Client Access Servers, конечные пользователи не будут замечать эти процессы перехода и переключения.

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

Поддержка членов групп DAG в различных AD сайтах - в отличие от узлов CCR кластера, серверы-участники группы DAG могут располагаться на разных Active Directory сайтах. Это будет долгожданное дополнение для тех, у кого нет возможности использования одного AD сайта во всех офисах (центрах данных). Однако следует отметить, что вы не можете расположить серверы Mailbox, защищенные одной группой DAG, в разные домены вашего Active Directory леса.

Передача журналов через TCP - в Exchange 2007, служба репликации Microsoft Exchange Replication Service копировала файлы журналов в пассивную копию баз данных (LCR), на пассивный узел кластера (CCR) или SCR цель через Server Message Block (SMB), что означало, что вам нужно было открывать порт 445 на любой межсетевом экране между узлами кластера CCR (обычно при установке многосайтовых CCR кластеров) и/или SCR источником и целью. Те из вас, кто работает с или на большие предприятия, знает, что убедить сетевых администраторов открыть порт 445/TCP между двумя центрами данных было далеко непростой задачей. С использованием Exchange 2010 DAG технология асинхронной репликации больше не полагается на SMB. Exchange 2010 использует TCP/IP для копирования и передачи файлов журналов, более того, он дает возможность указывать, какой порт вы хотите использовать для репликации файлов журналов. По умолчанию, DAG использует порт 64327, но вы можете указать другой порт, если это нужно.

Сжатие файлов журналов - при использовании Exchange 2010 DAG вы можете включить сжатие передачи и репликации для одной или нескольких сетей в DAG. Это свойство самой группы DAG, а не сети DAG. Параметром по умолчанию будет InterSubnetOnly, здесь также доступны те же настройки, которые имеются в свойствах шифрования сети.

Шифрование файлов журналов - Exchange 2010 DAG поддерживает использование шифрования, в то время как в Exchange 2007 файлы журналов копируются по незашифрованному каналу (если не настроено IPsec). Если говорить точнее, DAG использует возможности шифрования Windows Server 2008, а именно, DAG использует Kerberos аутентификацию между всеми Mailbox серверами, принадлежащими к соответствующей группе DAG. Сетевое шифрование является свойством самой группы DAG, а не сети DAG. Параметры свойств сетевого шифрования DAG включают следующее: отключено - Disabled (сетевое шифрование не используется), включено - Enabled (сетевое шифрование включено для передачи и репликации для всех сетей, имеющихся в DAG), InterSubnetOnly (значение по умолчанию, которое означает, что сетевое шифрование используется для DAG сетей, расположенных в одной подсети), и SeedOnly (сетевое шифрование используется для передачи на всех сетях в DAG).

Копии с задержкой до 14 - с функцией Standby Continuous Replication, включенной в Exchange 2007 SP1, были представлены отсроченные копии баз данных. Благодаря этой функции мы могли осуществлять отсрочку того времени, после которого файлы журналов, копируемые в SCR цель, преобразовывались в базу данных на целевом сервере SCR. У нас также была возможность указания, так называемого, времени задержки усечения (truncation lag time), которая позволяла нам откладывать время, после которого файлы журналов, скопированные в SCR и преобразованные в копию базы данных, должны быть усечены. С помощью этих двух опций мы могли указывать время задержки до 7 дней. В Exchange 2010 DAG мы можем задавать время задержки усечения до 14 дней, что весьма полезно, если вы используете функцию минимального резервного копирования.

Передача из копии баз данных (DB copy) - в отличие от CCR в Exchange 2007 теперь мы можем выполнять передачу путем указания копии базы данных в качестве источника базы данных. Это означает, что новая передача или повторная передача существующих баз данных почтовых ящиков больше никак не влияет на копию активной базы данных.

Базы данных публичных папок не защищены группами DAG - в отличие от CCR в Exchange 2007, мы не можем защитить базы данных публичных папок с помощью групп DAG. Базы данных публичных папок должны быть защищены с использованием традиционных механизмов репликации баз данных публичных папок. Положительным моментом в этом является то, что мы больше не ограничены только одним хранилищем публичной базы данных в организации Exchange, если она храниться на сервере участнике группы DAG. При использовании CCR у нас могло быть только одно хранилище базы данных.

Улучшенная транспортная корзина - транспортная корзина, которая известна нам из Exchange 2007, также была улучшена, поэтому сообщения могут быть повторно доставлены даже после того, как возникает ситуация обхода отказа с потерями между копиями баз данных, хранящихся на различных сайтах Active Directory. Вдобавок к этому, когда все сообщения реплицированы во все копии баз данных, они будут удалены из транспортной корзины.

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