Exchange Server 2010

Статья
08/22/2016

Обеспечение высокой доступности в Microsoft Exchange Server 2010

Уильям Р. Станек

• Функции обеспечения высокого уровня доступности в Exchange Server 2010
• Изучение групп доступности базы данных

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

В Exchange Server 2010 используется совершенно другой подход к обеспечению высокого уровня доступности, потому что высокая доступность интегрируется в архитектуру ядра, создавая комплексное решение, обеспечивающее доступность служб, данных и автоматическое восстановление. В результате одно, ключевое решение высокой доступности заменяет большое количество разных решений, используемых до этого. Это решение – группа доступности базы данных (DAG).

Группы DAG обеспечивают автоматическую отработку отказа и восстановление на уровне базы данных (а не на уровне сервера), для чего не требуется наличие кластеров, если вы разворачиваете несколько серверов почтовых ящиков с несколькими копиями баз данных почтовых ящиков. В силу этих изменений создание сервера почтовых ящиков с высоким уровнем доступности больше не требует кластерного оборудования или расширенных настроек кластера. Вместо этого, группы DAG предоставляют базовый компонент для обеспечения высокого уровня доступности, а обеспечение отказоустойчивости является автоматическим для баз данных почтовых ящиков, которые являются частью одной группы DAG. Группы DAG можно расширить до нескольких узлов Active Directory, а соответствующие изменения архитектуры в серверах почтовых ящиков предоставляют возможность перемещения базы данных почтовых ящиков между узлами Active Directory. В результате, при отказе база данных почтовых ящиков в одном узле Active Directory может перейти на другой узел Active Directory.

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

Перед тем, как пускаться в подробное описание групп DAG, давайте рассмотрим другие способы обеспечения высокой доступности в Exchange 2010.

Краткий обзор функций обеспечения высокого уровня доступности в Exchange Server 2010

В предыдущих версиях Exchange работал как приложение кластера, которое использовало модель управления ресурсами кластера. При данном подходе вы реализовывали высокий уровень доступности для серверов почтовых ящиков, сначала создавая отказоустойчивый кластер Windows, а затем запуская установку Exchange в кластерном режиме. В рамках процесса установки, регистрируется DLL-ресурс кластера Exchange (exres.dll), позволяющий создать кластерный сервер почтовых ящиков. В отличие от этого, Exchange 2010 не работает как кластеризованное приложение, модель управления ресурсами кластера больше не используется для обеспечения высокого уровня доступности. DLL-ресурс кластера Exchange и все предоставляемые им ресурсы кластера больше не существуют. Вместо этого в Exchange 2010 используется внутренняя модель обеспечения высокого уровня доступности. Хотя некоторые компоненты отказоустойчивой кластеризации Windows еще используются в данной модели, сейчас они управляются исключительно средствами Exchange 2010.

Что интересно, многие из основных технологий репликации остаются – просто они доработаны и работают совершенно по-разному. В виду того, что группы хранения были удалены из Exchange 2010, постоянная репликация запускается на уровне базы данных. Вместо использования протокола Server Message Block (SMB) для доставки и распространения журнала, в Exchange 2010 используется один определенный администратором порт TCP для передачи данных. Вместо того, чтобы пассивные копии вызывали закрытый файл журнала из активной копии, активная копия передает файлы журналов пассивным копиям, а безопасность потока данных обеспечивается с помощью шифрования, или производится его сжатие для уменьшения размера реплицированных данных. Хотя можно было использовать только активную копию базы данных в ранних версиях Exchange для распространения и повторного распространения, в Exchange Server 2010 как пассивные, так и активные копии баз данных почтовых ящиков можно определять как источники распространения и повторного распространения, что позволяет вам упростить процесс добавления копии базы данных на другой почтовый сервер.

Другим значительным изменением является способ репликации данных. В Exchange 2007, служба репликации Microsoft Exchange воспроизводила журналы в пассивных копиях базы данных и создавала кэш операций чтения/записи для уменьшения операций ввода/вывода. Если активировалась пассивная копия базы данных, то кэш базы данных терялся, так как службе хранилища информации Microsoft Exchange, которая монтировала базу данных, данный кэш был не доступен. Это означало, что пассивная копия активировалась и становилась доступной в «холодном состоянии» без подготовленного кэша. «Холодное состояние» — это состояние, в котором находился бы кэш базы данных перед последующей перезагрузкой сервера или служб, выполняющих кэширование. Нахождение в «холодном состоянии» означало, что сервер не имел кэшированных операций чтения/записи, условие, обычно увеличивающее количество операций ввода/вывода, необходимых для уменьшения времени доступа к данным на диске сервера. В Exchange 2010, служба хранилища информации Microsoft Exchange воспроизводит журналы и обрабатывает операции присоединения, обеспечивая факт того, что кэш будет доступен, если пассивная копия активируется и становится доступной. В результате, вероятнее всего, сервер сможет использовать кэш для уменьшения операций ввода/вывода после переключения сервера или обеспечения отказоустойчивости.

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

В Exchange 2010 эти недостатки решаются несколькими способами. Сейчас транспортная корзина имеет обратную связь для определения того, какие сообщения были доставлены и реплицированы. Транспортные серверы-концентраторы хранят копии сообщений, отправленных в реплицированную базу данных почтового ящика, в группе DAG. Копия хранится в базе данных транспортных запросов (mail.que), пока транспортный сервер-концентратор не будет оповещен о том, что журналы транзакций, представляющие сообщение, были успешно реплицированы и проверены всеми копиями базы данных почтового ящика. Затем журналы могут быть удалены из транспортной корзины, обеспечивая факт того, что запросы транспортной корзины использовались для того, чтобы хранить только копии тех сообщений, чьи журналы еще не были реплицированы. Дополнительно, если база данных почтового ящика в одном узле Active Directory переходит на другой узел Active Directory, запросы повторной доставки транспортной корзины отправляются как на исходный, так и новый узел.

Для обеспечения резервирования сообщений во время передачи в Exchange 2010 добавлена функция теневого резервирования. Теневое резервирование использует подход, схожий с транспортной корзиной, за исключением задержки удаления сообщений из транспортных баз данных до тех пор, пока транспортный сервер не проверит, что все сообщения доставлены. Если транспортный сервер не может проверить факт доставки, сообщение отправляется повторно. Данный подход использует меньше пропускной способности сети, не дублируя копии сообщений на нескольких серверах. Здесь дополнительный трафик образуется лишь при обмене сообщениями о состоянии отклонения между транспортными серверами. Сообщения о состоянии отклонения создаются диспетчером теневого резервирования и отображают то, что электронное сообщение готово к отклонению из транспортной базы данных.

Теневое резервирование является расширением службы протокола SMTP и используется до тех пор, пока оба сервера в SMTP-соединении поддерживают данную функцию. Если у вас имеются пути резервированного сообщения в вашей топологии маршрутизации, теневое резервирование делает доступным любой транспортный сервер, устраняя зависимость от состояния определенного транспортного сервера-концентратора или пограничного транспортного сервера. В данном случае, если происходит отказ транспортного сервера или вы хотите провести его автономное техническое обслуживание, вы можете сделать это в любое время, удалив, заменив или обновив его, не удаляя запросы и не беспокоясь о том, что сообщения будут потеряны.

Диспетчер теневого резервирования использует принцип синхронизации при определении доступности серверов, для которых теневые сообщения помещаются в очередь. Исходный сервер выдает сообщение XQUERYDISCARD, а в ответ целевой сервер возвращает уведомления об отклонении. Данный обмен уведомлениями является синхронным.

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

Изучение групп DAG

Хотя большинство усовершенствований, описанных мною, и являются важными, ни одно из них не оказало такого влияния на управление Exchange 2010, как группы доступности базы данных. Группы DAG являются основными компонентами обеспечения высокого уровня доступности в Exchange 2010. Правила для групп DAG просты. Каждая группа DAG может иметь в качестве членов до 16 почтовых серверов. Каждый почтовый сервер может быть членом только одной группы DAG и может размещать только одну копию базы данных. Размещенная копия может быть активной или пассивной. Основное отличие активной от пассивной копии заключается в том, что активная копия используется, и пользователи получают доступ к ней интерактивно, а не в автономном состоянии. Вы не можете создать две копии одной базы данных на одном сервере. На основе этого, любой сервер в группе DAG может размешать копию любой базы данных почтовых ящиков из любого сервера группы DAG. Хотя одновременно несколько баз могут быть активными, только одна копия базы данных может быть активной в конкретный момент времени, а до 15 пассивных копий этой базы данных могут находиться на других серверах группы DAG.

Если вы создаете вашу первую группу DAG в организации Exchange, Exchange создает отказоустойчивый кластер Windows, но там не присутствуют группы кластера для Exchange и не имеются ресурсы хранения в кластере. Группа DAG использует только синхронизацию кластера, сети кластера и функции баз данных отказоустойчивого кластеров Windows. Синхронизация кластера используется для обнаружения отказов. Каждой группе DAG требуется, по крайней мере, одна сеть для трафика репликации и одна сеть для MAPI и другого трафика. В базе данных кластера хранятся изменения состояния базы данных и другая важная информация. При добавлении других серверов в группу DAG, серверы присоединяются к основному кластеру, а модель кворума кластера автоматически изменяется в зависимости от количества серверов, входящих в домен.

Active Manager является компонентом Exchange 2010, предоставляющим модель управления ресурсами и обеспечения отказоустойчивости. Active Manager работает на всех серверах, входящих в группу DAG, которые работают в качестве держателя ролей (Основной диспетчер Active Manager) или второстепенного держателя ролей (Резервный диспетчер Active Manager) определенной базы данных. Основной диспетчер решает, какие копии базы данных будут активными, а какие копии необходимо активировать. Основной диспетчер получает сообщения об изменениях топологии и реагирует на отказы сервера. Основной диспетчер также имеет права владения на кворум ресурсов кластера. Если на сервере, работающем в качестве основного, происходит сбой, роль основного автоматически переходит другому серверу в группе DAG и этот сервер получает права владения на кворум ресурсов кластера.

Резервный диспетчер обнаруживает реплицированные, локальные базы данных и локальное хранилище информации, а также посылает уведомления о сбоях основному диспетчеру с запросом на начало обхода отказа. Резервный диспетчер не решает, от какого сервера принимать права, а также не обновляет состояние местоположения базы данных. Этими вопросами занимается основной диспетчер. При отказе активной базы данных, диспетчер Active Manager использует алгоритм Best Copy Selection (Выбор лучшей копии) для того, чтобы выбрать копию базы данных для активации. Данный алгоритм определяет лучшую копию базы данных для активации на основе состояния базы данных, состояния индекса содержимого, длины очереди копии и длины очереди воспроизведения копии базы данных. Если более одной базы данных соответствует критериям выбора, во внимание принимается предпочтительное значение активации, и база данных с наименьшим предпочтительным значением активируется и подключается.

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

Настоящее упрощение

Как я объяснил в данной статье, Exchange 2010 имеет множество важных усовершенствований в области доступности, включая интеграцию функций высокой доступности в ядро, повышающих уровень доступности изменения архитектуры и многое другое. Среди всех новых функций моими любимыми являются группы DAG . Группы DAG действительно упрощают реализацию кластеризации и позволяют вам сконцентрироваться на самом важном аспекте — на данных. Надеюсь, что эта статья покажется вам полезной и вы поищите мои новые книги «Карманный консультант администратора по Exchange Server 2010», «Карманный консультант администратора по Windows 7» и «Карманный консультант администратора по Windows Server 2008, второе издание».

Уильям Р. Станек (William R. Stanek) (williamstanek.com) — ведущий специалист-технолог, великолепный преподаватель и отмеченный наградами автор более 100 книг. Книги, которые уже имеются в продаже или скоро там появятся: «Карманный консультант администратора по Active Directory», «Карманный консультант администратора по групповой политике», «Карманный консультант администратора по Windows 7», «Карманный консультант администратора по Exchange Server 2010» и «Windows Server 2008. Взгляд изнутри». Заходите в чат Twitter на WilliamStanek https://twitter.com/WilliamStanek.