Средства для работы с электронной почтой — это жизненно важное приложение, поэтому инженеры Microsoft на протяжении последних лет прилагали большие усилия, а корпорация выделила немало средств для того, чтобы наделить Microsoft Exchange Server устойчивостью к отказам различных типов и способностью предоставлять услуги с высокой степенью доступности. Во многих отношениях версия Exchange Server 2007 стала своеобразным водоразделом в обеспечении высокой доступности, поскольку именно в этой версии была реализована технология репликации журналов в форме локальной непрерывной репликации (local continuous replication, LCR), непрерывной репликации кластера (cluster continuous replication, CCR) и резервной непрерывной репликации (standby continuous replication, SCR). И вот теперь разработчики Exchange Server 2010 предлагают новый подход к обеспечению высокого уровня доступности — на основе групп доступности баз данных Database Availability Group (DAG), которые базируются на многих из упомянутых выше методах репликации журналов.

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

Параметры высокой доступности для Exchange 2010

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

Если не обращать внимания на эти ограничения, базовая технология включает в себя все виды работ: копирование журналов транзакций с исходного сервера на целевой, проверку правильности их содержимого и далее повторное воспроизведение этого содержимого с целью обновления пассивных копий баз данных. Решение Microsoft сосредоточить внимание разработчиков Exchange 2010 на непрерывной репликации журналов, которая должна стать основой высокой доступности, вполне понятно, и надо сказать, что специалисты корпорации создали более удобный в управлении и полнофункциональный продукт. Exchange 2010 не поддерживает операций типа LCR, CCR и SCR, но, как мы увидим далее, внедрение DAG в полной мере компенсирует это.

Вторая цель разработчиков Microsoft сводилась к реализации в версии Exchange 2010 достаточного объема функций, чтобы заказчики могли создавать инфраструктуры с высоким уровнем доступности и им не приходилось бы при этом вкладывать средства в дорогостоящие дополнительные продукты от независимых поставщиков. Спору нет, технологию независимых поставщиков отличает собственный набор полезных средств обеспечения доступности, особенно эффективных, когда эти средства используются в сочетании с высококлассными системами хранения данных. Но надо иметь в виду, что Microsoft располагает широкой и неоднородной клиентской базой Exchange и не все клиенты могут позволить себе финансовые и административные затраты на развертывание дополнительных технологий. Наличие богатого набора средств обеспечения высокого уровня доступности, встроенных в продукт и управляемых стандартными механизмами — Exchange Management Console (EMC) и Exchange Management Shell (EMS), — повышает привлекательность Exchange как платформы, устраняет избыточную сложность и избавляет от лишних расходов клиентов из сегмента малого и среднего бизнеса, а также корпоративных клиентов.

Наконец, разработчики Microsoft хотели предоставить клиентам возможность поэтапного развертывания серверов высокой доступности. В предшествующих версиях системы Exchange перед развертыванием решений высокой доступности клиентам приходилось выполнять значительный объем подготовительной работы. К примеру, если вы хотите развернуть серверы Exchange, объединенные в кластеры, следует прежде всего позаботиться о наличии соответствующего оборудования, затем установить кластер Windows, после чего установить Exchange с правильно подобранными параметрами. Это позволит создать виртуальные серверы Exchange, выполняемые на кластере и подключенные к ресурсам кластера, таким как общее хранилище. Такие процессы не осуществляются без предварительного планирования.

Концепция поэтапного развертывания в том виде, в каком она реализована в Exchange 2010, сводится к следующему. Сначала вы можете развернуть типичные серверы Exchange Mailbox, а затем, когда возникнет необходимость обеспечить более высокий уровень доступности среды, принять решение о введении этих серверов в состав DAG. Кроме того, вы можете постепенно расширять группу DAG, включая в нее новые серверы и новые копии баз данных; таким образом повышается устойчивость системы к различным сбоям в соответствии с теми возможностями, которые открываются с учетом имеющегося времени, денег и аппаратных средств.

Группы хранения данных в качестве основы механизма управления базами данных Microsoft были реализованы в версии Exchange 2000. Базы данных размещались внутри групп хранения данных, которые относились к тем или иным серверам. Все базы данных в группе хранения располагали общим набором журналов транзакций; причем транзакции всех баз данных группы хранения данных фиксировались в журналах вперемешку. Иногда работать с группами хранения данных было удобно, но в конечном итоге специалисты Microsoft пришли к заключению, что с точки зрения администраторов эти группы являли собой дополнительный уровень сложности, и с выходом версии Exchange 2007 начался процесс изъятия групп хранения из продукта. Иными словами, нет ничего удивительного в том, что в версии Exchange 2010 группы хранения данных не представлены.

Определение группы DAG

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

Серверы внутри DAG могут поддерживать и другие роли, однако на каждом сервере должна быть установлена роль Mailbox, потому что он должен иметь возможность размещения базы данных почтовых ящиков. Кроме того, серверы могут располагаться в различных подсетях и охватывать разные сайты Active Directory (AD); главное, чтобы была обеспечена достаточная полоса пропускания. Microsoft рекомендует размещать DAG в сети с задержкой приема-передачи в 250 миллисекунд или менее. Сервер Exchange 2010, на котором выполняется редакция Enterprise, может взаимодействовать с 50 активными базами данных, но редакция Standard не может поддерживать более пяти баз данных. При включении пассивных баз данных, которые размещаются на сервере для обслуживания других серверов, этот показатель для редакции Enterprise увеличивается до 100 баз данных.

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

Механизм кластеризации Windows

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

Зависимость от кластеров Windows проявляется в том, что администратор может добавлять в группу DAG серверы почтовых ящиков только в том случае, если они выполняются в среде Exchange 2010 Enterprise Edition на Windows 2008 (SP2 или R2) Enterprise Edition. Кроме того, все серверы — члены DAG должны быть частью одного домена. Наряду с этим на всех серверах — членах DAG следует устанавливать операционную систему одной версии; возможность использования Windows 2008 SP2 и Windows 2008 R2 внутри одной и той же группы DAG исключается. Правильным решением считается установка на всех серверах организации программного обеспечения одного уровня.

Репликация журналов транзакций

Внутри группы DAG система Exchange обслуживает копии баз данных с помощью процесса репликации журналов. Журналы транзакций, генерируемые на активном сервере, копируются службой репликации Microsoft Exchange (MSExchangeRepl), которая выполняется на каждом сервере, где размещаются пассивные копии баз данных почтовых ящиков. Там журналы проверяются и затем воспроизводятся для обновления пассивных копий. DAG представляет собой границу репликации данных для журналов транзакций. Иными словами, мы не можем реплицировать журналы на сервер в другой группе DAG и обеспечить их воспроизведение системой Exchange в размещенную там реплику базы данных. Из этого следует, что, прежде чем мы сможем создавать копию базы данных, она должна быть размещена в DAG, и целевой сервер должен входить в состав той же DAG.

Рисунок. Архитектура групп хранения DAG

На рисунке показана группа DAG, состоящая из трех серверов, каждый из которых содержит две базы данных. Каждая база данных реплицируется на один из двух серверов; таким образом обеспечивается базовый уровень устойчивости на случай отказа сервера. Если из строя выходит сервер 1, в результате чего прекращается обслуживание баз данных 1 и 2, процесс Active Manager, который будет описан ниже, перенаправит подключения пользователей таким образом, чтобы они обращались к копиям баз данных на серверах 2 и 3. Пользователи, подключенные к базе данных 1, перенаправляются на сервер 2, а пользователи, подключенные к базе данных 2, попадают на сервер 3. Подобным же образом, если происходит отказ диска, содержащего базу данных 2 на сервере 1, Active Manager обнаруживает проблему и перенаправляет трафик на сервер 3.

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

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

Рассмотрим в качестве примера группу DAG, состоящую из 15 серверов. В сети эксплуатируется 110 активных баз данных, каждая из них имеет две пассивные копии, так что всего в сети размещается 330 баз данных. Эти базы данных и их копии равномерно распределены по всем серверам, то есть каждый сервер содержит 22 базы данных. Некоторые из этих баз данных являются активными и поддерживают пользователей; другие представляют собой копии, воспроизводящие транзакции из основных баз данных. Вместимость хранилища каждого сервера — 18 Тбайт. В такой ситуации наличие трех копий каждой базы данных обеспечивает достаточную устойчивость к различным отказам, но не забывайте планировать схему DAG таким образом, чтобы отказ, выводящий из строя серверную стойку, не был препятствием для обслуживания базы данных. Иными словами, не следует размещать в одной стойке все серверы, в которых размещается и активная база данных, и все ее пассивные копии.

Active Manager

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

Компонент Active Manager выполняется на всех серверах внутри DAG. Один из серверов DAG является основным активным диспетчером primary active manager (PAM), тогда как остальные играют роль резервного активного диспетчера standby active manager (SAM). Функционируя в любом режиме (PAM или SAM), серверы постоянно отслеживают работу баз данных как на уровне банка данных Information Store, так и на уровне движка хранилища Extensible Storage Engine (ESE); в результате они могут обнаруживать аварийные сбои. При выявлении сбоя сервер предлагает основному активному диспетчеру выполнить аварийное переключение. Сервер, на котором выполняется основной активный диспетчер, направляет запрос, выясняя, доступен ли этот компонент; если это не так, роль перехватывается другим сервером, который делает основным свой активный диспетчер и активирует копии баз данных.

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

Автоматическое перемещение баз данных

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

Для этого активный диспетчер создает отсортированный список имеющихся копий. При этом недоступные серверы, а также серверы, где активация временно заблокирована, игнорируются. При наличии списка активный диспетчер применяет набор критериев для принятия окончательного решения; каждый набор критериев применяется до тех пор, пока не будет выбрана та или иная база данных. Для обнаружения лучшей из имеющихся копий баз данных выполняется до 12 проверок. Если заданным критериям отвечают несколько баз данных, для окончательного выбора одного из имеющих равные шансы претендентов применяется значение Activation Preference.

Activation Preference — это численный коэффициент, связанный с копией базы данных, который администраторы используют для управления порядком, в котором Exchange активирует копии. Так, если фиксируется отказ базы данных и имеется две копии, причем у одной параметр activation preference имеет значение 2, а у второй — 3, Exchange активирует копию с более низким показателем — 2. Принимая такое решение, система исходит из того, что обе копии находятся в исправном состоянии (то есть они реплицируют и воспроизводят журналы транзакций, с тем чтобы база данных всегда отражала последние изменения); при наличии исправной копии Exchange никогда не активирует неисправную базу данных.

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

Выбрав лучшую копию для активации, активный диспетчер предписывает службе репликации на данном сервере предпринять попытку скопировать все отсутствующие журналы транзакций из имеющихся источников. При условии что данные всех журналов транзакций могут быть извлечены, хранилище Store на выбранном сервере может подключить соответствующую базу данных без потери данных и затем принять соединения клиентов. При отсутствии некоторых журналов хранилище применяет настройку AutoDatabaseMountDial для принятия решения по поводу того, следует ли устанавливать базу данных. AutoDatabaseMountDial — это свойство сервера почтовых ящиков, управлять которым можно с помощью составной команды Set-MailboxServer. По умолчанию применяется значение BestAvailability; это значит, что базу данных можно подключать, если отсутствует не более 12 журналов транзакций.

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

Как только данные о перемещении поступают на уровень RPC сервера Client Access, он начинает перенаправлять клиенты на вновь активированную базу данных. Реакция клиента на перемещение базы данных зависит от платформы и версии клиента.

Функционирующие в режиме Cached Exchange Mode клиенты Microsoft Office Outlook направляют извещение о потере связи с базой данных и затем вновь подключаются к базе данных, когда она опять переводится в диалоговый режим. Реакция Outlook 2010 несколько иная; этот продукт подавляет сообщения о потере связи по причинам, которые считаются незначительными (например, сбой в работе сети), поэтому пользователи получают извещения лишь после восстановления соединений.

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

Когда неполадка в исходном сервере устраняется и он возвращается в строй, размещенная на этом сервере копия базы данных является пассивной; понятно, что хранящиеся в ней данные не столь актуальны, как те, что хранятся в других копиях. Хранилище инициирует процесс выявления расхождений и затем выполняет добавочное заполнение, чтобы актуализировать содержимое базы данных. Первый этап — определение точки расхождения; эта задача выполняется посредством сравнения журналов транзакций на сервере с журналами, размещенными на сервере, который содержит актуальную копию. Хранилище определяет, какие страницы базы данных претерпели изменения после точки расхождения, и далее запрашивает копии измененных страниц у актуальной копии базы данных. Эти страницы повторно воспроизводятся до тех пор, пока восстановленная копия не синхронизируется со всеми остальными. Цель в том, чтобы вся эта работа была выполнена в течение 30 секунд и за это же время было возобновлено обслуживание пользователей. Восстановленная база данных сохраняет статус пассивной копии до тех пор, пока администратор не решит вновь превратить ее в основную копию.

Новые горизонты DAG

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

Тони Редмонд (exchguru@windowsitpro.com) — редактор журнала Windows IT Pro, старший технический редактор Exchange & Outlook Administrator, вице-президент и главный технолог HP Services