Применимо к: Exchange Server 2010 SP1

Последнее изменение раздела: 2011-04-12

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

Необходимы сведения о задачах, связанных с высоким уровнем доступности и устойчивостью сайтов к сбоям? См. раздел Управление высокой доступностью и устойчивостью сайтов.

Содержание

Основные термины

Основные характеристики решения Exchange Server 2010

Мобильность баз данных

Добавочное развертывание

Группы обеспечения доступности баз данных

Копии базы данных почтовых ящиков

Активный диспетчер

Изменения высокого уровня доступности по сравнению с предыдущими версиями Exchange

Высокая доступность для ролей сервера, отличных от сервера почтовых ящиков

Устойчивость сайтов к сбоям

Сквозная доступность

Основные термины

В данной теме используются следующие термины:

Служба адресной книги

Служба сервера клиентского доступа, которая используется в качестве конечной точки доступа к каталогам для клиентов Microsoft Outlook.

Непрерывная репликация — режим блокировки

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

Непрерывная репликация — режим файла

Название исходной формы непрерывной репликации в окончательной первоначальной версии (RTM) Exchange 2010, благодаря которой файлы журналов закрытых транзакций передаются из активной копии базы данных в одну или несколько пассивных копий базы данных.

Группа обеспечения доступности баз данных

Группа, содержащая до 16 серверов почтовых ящиков Exchange 2010, в которой размещается набор реплицированных баз данных.

Мобильность баз данных

Способность отдельной базы данных почтовых ящиков Exchange 2010 к репликации и подключению на других серверах почтовых ящиков Exchange 2010.

Аварийное восстановление

Любой процесс, используемый для ручного восстановления после сбоя. Это может быть сбой, затрагивающий как отдельный объект, так и все физическое расположение.

Интерфейс API Exchange для сторонней репликации

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

Высокая доступность

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

Добавочное развертывание

Возможность развертывания функций высокой доступности и устойчивости к сбоям после установки Exchange 2010.

Изолированная копия базы данных почтовых ящиков

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

Копия базы данных почтовых ящиков

База данных почтовых ящиков (файл EDB и журналы), которая находится в активном или пассивном состоянии.

Устойчивость почтовых ящиков

Название объединенного решения по обеспечению высокой доступности и устойчивости к сбоям в Exchange 2010.

Служба клиентского доступа RPC

Служба сервера клиентского доступа, которая используется в качестве конечной точки MAPI для клиентов Microsoft Outlook.

Устойчивость сайта к сбоям

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

Теневая избыточность

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

*over (произносится «звездочка over»)

Сокращение от терминов переключение (switchover) и отработка отказа (failover). Переключение представляет собой ручную активацию одной или нескольких копий базы данных. Отработка отказа представляет собой автоматическую активацию одной или нескольких копий базы данных после сбоя.

В начало

Основные характеристики решения Exchange Server 2010

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

  • Сложность реализации отказоустойчивости кластеров Windows может вызывать трудности.

  • Для достижения высокого уровня безотказной работы иногда требовалось серьезное вмешательство со стороны администратора.

  • Управление каждым типом непрерывной репликации осуществлялось по-разному и отдельно.

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

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

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

Благодаря указанным улучшениям Exchange 2010 максимальный рекомендуемый размер базы данных почтовых ящиков при использовании непрерывной репликации вырос с 200 гигабайт (ГБ) в Exchange 2007 до 2 терабайт в Exchange 2010. Поскольку все больше компаний понимают важное значение больших почтовых ящиков (от 2 ГБ до 10 ГБ и более), базы данных значительно больших размеров могут стать реальностью очень быстро. Поддержка таких крупных баз данных означает уход от устаревших механизмов восстановления, таких как резервное копирование и восстановление, и переход к новым и более быстрым формам защиты, таким как репликация данных и избыточность серверов.

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

В начало

Мобильность баз данных

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

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

На основе отзывов пользователей также были пересмотрены и переработаны два других ограничения в архитектуре Exchange 2007:

  • Кластерные серверы Exchange 2007 требуют установки специального оборудования. Для узла в кластере может быть установлена только роль сервера почтовых ящиков. Таким образом, для достижения полной избыточности основных компонентов развертывания, например основных ролей сервера (сервер почтовых ящиков, транспортный сервер-концентратор и сервер клиентского доступа), требовалось не менее четырех серверов Exchange.

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

Система Exchange 2010 создавалась с учетом концепции мобильности баз данных. Мобильность баз данных затрагивает и способ использования непрерывной репликации системой: база данных реплицируется на несколько разных серверов, объединенных в группу. Такая модель обеспечивает лучшую защита базы данных и повышает доступность. В ней автоматическая защита через отработку отказов и ручное управление переключением стали реализовываться на уровне базы данных почтовых ящиков, а не на уровне сервера.

В случае сбоев база данных может быть подключена к другим серверам, имеющим ее копию. В результате этого и других изменений в архитектуре отработка отказов теперь происходит намного быстрее, чем в предыдущих версиях Exchange. Например, отработка отказа кластерного сервера почтовых ящиков в среде непрерывной репликацией в кластере, работающем под управлением Exchange 2007 с пакетом обновления 1 (SP1), длится приблизительно 2 минуты (имеется в виду внутренний сбой сайта, при котором IP-адрес кластерного сервера почтовых ящиков не меняется). Для сравнения, отработка отказа базы данных почтовых ящиков в среде Exchange 2010 длится не более 30 секунд (измерения выполнялись с момента обнаружения сбоя до момента завершения подключения копии базы данных с учетом того, что эта копия является работоспособной, а ее последняя версия соответствует преобразованию журнала). Сочетание отработки отказов на уровне базы данных и уменьшение временных затрат на нее улучшает общую безотказность работы в организации.

В начало

Добавочное развертывание

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

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

В начало

Группы обеспечения доступности баз данных

Группа обеспечения доступности баз данных является базовым компонентом платформы высокой доступности и устойчивости к сбоям, встроенной в Exchange 2010. Группа обеспечения доступности баз данных — это набор до 16 серверов почтовых ящиков, используемых для размещения набора баз данных и обеспечивающих автоматическое восстановление на уровне базы данных после сбоя, затрагивающего отдельные базы данных. На любом сервере в группе обеспечения доступности баз данных можно разместить копию базы данных почтовых ящиков с любого другого сервера в группе обеспечения доступности баз данных. Если сервер добавлен в группу обеспечения доступности баз данных, он вместе с другими серверами в этой группе обеспечивает автоматическое восстановление после сбоев, затрагивающих базы данных почтовых ящиков, например сбоев дисков или серверов.

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

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

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

Эта новая архитектура высокой доступности также упрощает восстановление после определенных видов сбоев (на уровне диска, на уровне сервера и на уровне центра данных) и может быть развернута для разных типов хранилищ.

Дополнительные сведения о группах обеспечения доступности баз данных см. в разделе Общие сведения о группах обеспечения доступности баз данных.

В начало

Копии базы данных почтовых ящиков

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

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

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

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

Дополнительные сведения о копиях баз данных почтовых ящиков см. в разделе Общие сведения о копиях базы данных почтовых ящиков.

В начало

Активный диспетчер

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

Exchange 2010 содержит новый компонент, называемый активным диспетчером, который по функциональным возможностям заменяет модель ресурсов и компоненты управления отработкой отказов, доступные благодаря интеграции со службой кластеров в предыдущих версиях Exchange. Дополнительные сведения об активном диспетчере см. в разделе Общие сведения об Active Manager.

В начало

Изменения высокого уровня доступности по сравнению с предыдущими версиями Exchange

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

Удаление кластерных серверов почтовых ящиков

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

Глобализация баз данных

В Exchange 2010 каждая база данных связана с единым выделенным потоком журналов, который представлен серией последовательно именуемых файлов журнала, размер каждого из которых составляет 1 мегабайт (МБ). Из Exchange 2010 также была удалена концепция групп хранения. Благодаря этим изменениям базы данных Exchange имеют выделенный поток журналов и больше не используют потоки журналов совместно с другими базами данных.

В отличие от предыдущих версий Exchange базы данных больше не связаны с определенным сервером почтовых ящиков. Кроме того, базы данных больше не определяются по серверам почтовых ящиков, на которых они размещаются, а имена серверов перестали входить в состав идентификаторов баз данных. Благодаря этим изменениям базы данных теперь являются глобальными объектами в Служба каталогов Active Directory и в каждой организации Exchange. При использовании консоли управления Exchange базы данных теперь управляются из узла «Почтовый ящик» в узле «Конфигурация организации».

Каждый сервер почтовых ящиков позволяет разместить до 100 баз данных (это совокупное количество активных и пассивных баз данных). Общее число баз данных равно совокупному количеству активных и пассивных баз данных на сервере. База данных восстановления при определении этого ограничения в 100 баз данных не учитывается.

Изменения в непрерывной репликации в RTM-версии Exchange 2010

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

  • Так как в Exchange 2010 удалены группы хранения, непрерывная репликация теперь выполняется на уровне баз данных. В Exchange 2010 по-прежнему используется база данных расширенного обработчика хранилищ, создающая журналы транзакций, которые реплицируются в одно или несколько других расположений и преобразуются в одну или несколько копий базы данных почтовых ящиков. Каждая база данных почтовых ящиков может иметь до 16 копий.

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

  • Функция непрерывной репликации в Exchange 2010 использует для передачи данных отдельный заданный администратором TCP-порт. Кроме этого, система Exchange 2010 включает в себя встроенные параметры сетевого шифрования и сжатия для потока данных.

  • Заполнение больше не ограничивается использованием только активной копии базы данных. Пассивные копии баз данных почтовых ящиков могут указываться в качестве источников для заполнения и повторного заполнения копий баз данных.

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

  • В Exchange 2007 служба репликации Microsoft Exchange отвечала за преобразование журналов в пассивные копии баз данных. При активации пассивной копии выполнялось построение кэша базы данных службой репликации Microsoft Exchange, из-за чего действия по преобразованию терялись при подключении базы данных службой банка данных Microsoft Exchange. В связи с этим кэш базы данных находился в состоянии, которое называется холодным режимом. Размер кэша базы данных, используемого для кэширования операций чтения и записи, во время этого периода небольшой. Поэтому возможность кэша уменьшить операции чтения очень невелика. В Exchange 2010 функциональная возможность преобразования пассивной копии, ранее обеспечиваемая службой репликации Microsoft Exchange, перенесена в службу банка данных Microsoft Exchange. В результате был введен «теплый режим» кэша базы данных, при котором кэш становится доступен для использования сразу же после отработки отказа или переключения.

Несколько принципов, используемых в системе непрерывной репликации Exchange 2007, также присутствуют в Exchange 2010. Например, понятия управления отработкой отказов, отклонения, использования автоматического подключения базы данных и использования репликации и сетей клиентского доступа (MAPI).

Изменения в непрерывной репликации в Exchange 2010 SP1

В RTM-версии Exchange 2010 и во всех версиях Exchange Server 2007 непрерывная репликация осуществляется путем передачи копий файлов журнала, созданных активной копией базы данных, в пассивные копии базы данных. Начиная с Exchange 2010 SP1, такая форма непрерывной репликации называется непрерывная репликация — режим файла. В SP1 также вводится новая форма непрерывной репликации, которая называется непрерывная репликация — режим блокировки. В режиме блокировки при каждой записи обновления в буфер активного журнала активной копии базы данных обновление также передается в буфер журнала каждой пассивной копии почтового ящика. После заполнения буфера журнала каждая копия базы данных строит, проверяет и создает следующий файл журнала по порядку номера версии. В случае сбоя, затрагивающего активную копию, в пассивные копии будут введены самые последние или все обновления. Активная копия не будет дожидаться завершения репликации, поэтому ошибки репликации не повлияют на работу клиента.

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

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

Чтобы определить, находится ли пассивная копия базы данных в режиме блокировки, проверьте активный счетчик производительности Непрерывная репликация — режим блокировки для объекта производительности Репликация MSExchange. У каждой копии базы данных свой экземпляр этого счетчика. Значение счетчика равно 1, когда пассивная копия находится в режиме блокировки, и 0 — когда пассивная копия в режиме файла. Для определения значения этого счетчика можно также использовать командлеты Get-Counter или Get-WMIObject, как показано в следующих примерах:

Скопировать код 
Get-Counter -ComputerName <DAGMemberName> -Counter "\MSExchange Replication(*)\Continuous replication - block mode Active"
Get-WMIObject -ComputerName <DAGMemberName> Win32_PerfRawData_MSExchangeReplication_MSExchangeReplication | Where-Object {$_.ContinuousReplicationBlockModeActive -eq "1"} | Where-Object {$_.name -ne "_total"} | format-table Name,ContinuousReplicationBlockModeActive

Изменения в транспортной корзине по сравнению с Exchange 2007

Роль транспортного сервера-концентратора Exchange 2010 включает компонент, называемый транспортной корзиной, который впервые появился в Exchange 2007. Транспортная корзина предназначена для защиты от потери данных с помощью хранения очереди всех сообщений электронной почты, недавно отправленных пользователям, почтовые ящики которых защищены с помощью непрерывной репликации в кластере или резервной непрерывной репликации. Когда в одной из этих сред происходит сбой с потерей данных, массив данных, которые в обычной ситуации были бы потеряны при сбое, автоматически восстанавливается транспортной корзиной.

Транспортная корзина используется только для реплицированных баз данных почтовых ящиков. Она не защищает сообщения, отправленные в общие папки, а также сообщения, отправленные получателям, которые расположены в нереплицируемых базах данных почтовых ящиков. Очередь транспортной корзины для определенной базы данных почтовых ящиков находится на всех транспортных серверах-концентраторах на сайтах Служба каталогов Active Directory, содержащих группу обеспечения доступности баз данных.

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

Каждый диспетчер Active Manager группы обеспечения доступности баз данных отслеживает значение момента последней проверки журнала на каждой пассивной копии базы данных. Клиент Active Manager, работающий на транспортном сервере-концентраторе, получает эти сведения от резервной службы Active Manager (SAM) группы обеспечения доступности баз данных и преобразует их в водяной знак с отметкой времени. Затем транспортный сервер-концентратор сравнивает время доставки сообщений в транспортной корзине с водяным знаком. Если время доставки сообщения является более ранним, чем отметка в водяном знаке, то сообщение будет удалено из транспортной корзины.

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

Изменения в способе маршрутизации при совместном расположении транспортного сервера-концентратора и сервера почтовых ящиков в одной группе обеспечения доступности баз данных

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

Например, на сервере EX1 размещается роль транспортного сервера-концентратора и сервера почтовых ящиков, причем этот сервер входит в группу обеспечения доступности баз данных. Когда сообщение поступает в транспорт для EX1, предназначенный для получателя, чей почтовый ящик также находится на сервере EX1, транспорт перенаправляет этот сообщение на другой транспортный сервер-концентратор на сайте (например, EX2), и этот сервер доставляет сообщение в почтовый ящик на сервере EX1.

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

В начало

Высокая доступность для ролей сервера, отличных от сервера почтовых ящиков

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

  • Пограничный транспортный сервер   Можно развернуть несколько пограничных транспортных серверов и использовать несколько записей MX DNS для работы балансировки нагрузки на этих серверах. Для балансировки нагрузки и обеспечения высокой доступности пограничных транспортных серверов также можно использовать функцию балансировки сетевой нагрузки.

  • Клиентский доступ   Для обеспечения высокого уровня доступности сервера клиентского доступа можно использовать балансировку сетевой нагрузки или стороннее устройство балансировки сетевой нагрузки.

  • Транспортный сервер-концентратор   Можно развернуть несколько транспортных серверов-концентраторов для достижения высокой доступности внутреннего транспорта. Устойчивость реализована в роли транспортного сервера-концентратора, как описано ниже.

    • Связь между транспортными серверами-концентраторами (внутри организации). Связь между транспортными серверами-концентраторами внутри организации автоматически обеспечивает балансировку нагрузки между доступными транспортными серверами-концентраторами на целевом сайте Служба каталогов Active Directory.

    • Связь сервера почтовых ящиков с транспортным сервером-концентратором (внутри сайта Active Directory)   Служба отправки почты Microsoft Exchange на серверах почтовых ящиков автоматически выполняет балансировку нагрузки между всеми транспортными серверами-концентраторами на том же сайте Служба каталогов Active Directory.

    • Связь сервера единой системы обмена сообщениями с транспортным сервером-концентратором   Сервер единой системы обмена сообщениями автоматически выполняет балансировку нагрузки между всеми транспортными серверами-концентраторами на том же сайте Служба каталогов Active Directory.

    • Связь транспортного сервера-концентратора с пограничным транспортным сервером   Пограничный транспортный сервер автоматически выполняет балансировку входящего трафика SMTP между всеми транспортными серверами-концентраторами на сайте Служба каталогов Active Directory, на который подписан пограничный транспортный сервер.

    Для обеспечения дополнительной избыточности (например, для приложений, которым требуется ретрансляция SMTP), можно создать запись DNS (например, relay.company.com), назначить IP-адрес и перенаправлять его на несколько транспортных серверов-концентраторов с помощью устройства для балансировки нагрузки. Можно также использовать балансировку нагрузки сети на клиентских соединителях транспортных серверов-концентраторов. При использовании устройства балансировки нагрузки необходимо убедиться, что внутриорганизационный трафик не будет пересекать это устройство, так как для этого трафика используются встроенные алгоритмы балансировки сетевой нагрузки (как описано выше).

  • Единая система обмена сообщениями   Отказоустойчивость развернутых экземпляров единой системы обмена сообщениями можно повысить посредством развертывания нескольких серверов единой системы обмена сообщениями, по два и более для одной абонентской группы. Шлюзы VoIP, поддерживаемые единой системой обмена сообщениями, можно настроить на маршрутизацию звонков на серверы единой системы обмена сообщениями с использованием метода циклического перебора. Кроме того, эти шлюзы могут получать список серверов для абонентской группы от DNS. При использовании любого из вышеописанных методов шлюзы VoIP будут направлять звонок на сервер единой системы обмена сообщениями, и если звонок не принят, он будет перенаправлен на другой сервер, обеспечивающий избыточность в момент поступления звонка.

В начало

Устойчивость сайтов к сбоям

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

Подробные сведения о планировании и развертывании функции устойчивости сайтов к сбоям см. в разделах Планирование высокой доступности и устойчивости сайтов, Развертывание высокой доступности и устойчивости сайтов и Переключения центра обработки данных.

В начало

Сквозная доступность

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

  • теневая избыточность;

  • оперативный режим перемещения почтового ящика;

  • гибкая защита почтовых ящиков;

  • добавочная повторная синхронизация;

  • сторонний интерфейс API репликации.

Теневая избыточность

Кроме функции транспортной корзины и описанных выше улучшений способа маршрутизации, у транспортного сервера-концентратора появилась новая функция, которая называется теневая избыточность. Функция теневой избыточности обеспечивает избыточность сообщений на протяжении всей пересылки. Это решение включает методику, аналогичную транспортной корзине. Благодаря теневой избыточности удаление сообщения из базы данных транспорта откладывается до тех пор, пока транспортный сервер не установит, что на всех следующих переходах для данного сообщения доставка завершена. Если произошел сбой какого-либо перехода до сообщения об успешной доставке, то сообщение повторно подается для доставки в этот следующий переход. Дополнительные сведения о теневой избыточности см. в разделе Общие сведения о теневой избыточности.

Оперативный режим перемещения почтового ящика

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

  • Операция перемещения почтовых ящиков обычно длилась несколько часов, при этом пользователи не могли получить доступ к своим почтовым ящикам.

  • Если окно командной строки, используемое для запуска командлета Move-Mailbox, закрывалось, то перемещение прерывалось, и его нужно было запускать заново.

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

Для выполнения асинхронных перемещений можно использовать командлет New-MoveRequest в Exchange 2010. В отличие от Exchange 2007, фактическое перемещение с помощью этих командлетов выполнить нельзя. Перемещение выполняется с помощью службы репликации почтовых ящиков Microsoft Exchange — новой службы, которая запускается на сервере клиентского доступа. Запросы в службу репликации почтовых ящиков Microsoft Exchange отправляются с помощью командлета New-MoveRequest. Дополнительные сведения о перемещении почтового ящика в оперативном режиме см. в разделе Общие сведения о запросах на перемещение.

Гибкая защита почтовых ящиков

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

Одним из значительных изменений является удаление групп хранения. В Exchange 2010 каждая база данных связана с единым потоком журналов, который представлен серией файлов журнала по 1 мегабайту (МБ) каждый. Каждый сервер позволяет размещать до 100 баз данных.

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

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

Добавочная повторная синхронизация

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

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

В Exchange 2010 добавочная повторная синхронизация — это новое название функции автоматического исправления расхождений в копиях баз данных в следующих ситуациях:

  • после автоматической отработки отказа для всех настроенных копий базы данных;

  • если новая копия включена, а база данных и некоторые файлы журнала уже существуют в местоположении копии;

  • при возобновлении репликации после приостановки или повторного запуска службы репликации Microsoft Exchange.

Благодаря этим изменениям устойчивость к потере файлов журнала имеет жестко заданный предел: один файл журнала для всех баз данных почтовых ящиков Exchange 2010.

При обнаружении расхождения между активной базой данных и копией этой базы данных функция добавочной повторной синхронизации выполняет указанные ниже задачи:

  • выполняет хронологический поиск в потоке файлов журнала для определения момента расхождения;

  • находит измененные страницы базы данных в копии, отличающейся от оригинала;

  • выполняет чтение измененных страниц из активной копии, затем копирует необходимые файлы журнала из активной копии;

  • применяет изменения страниц базы данных к копии, отличающейся от других;

  • запускает восстановление отличающейся копии базы данных и преобразует необходимые файлы журнала в нее.

Сторонний интерфейс API репликации

Система Exchange 2010 также включает в себя новый сторонний интерфейс API репликации, позволяющий организациям использовать сторонние решения по синхронной репликации вместо функции встроенной непрерывной репликации. Майкрософт поддерживает решения сторонних производителей, использующие этот интерфейс API, при условии что решение содержит необходимые функции, заменяющие все встроенные функции непрерывной репликации, которые отключены из-за использования интерфейса API. Поддержка решений обеспечивается, только когда интерфейс API используется в группе обеспечения доступности баз данных для управления и активации копий базы данных почтовых ящиков. Использование интерфейса API для других целей не поддерживается. Кроме того, решение должно отвечать требованиям к поддержке оборудования Windows (проверочное тестирование для поддержки не требуется).

При развертывании решения, использующего встроенный интерфейс API репликации сторонних производителей, учтите, что поставщик решения несет ответственность за основную поддержку решения. Майкрософт поддерживает данные Exchange для решений с репликацией и без нее. Решения, использующие репликацию данных, должны соответствовать политике Майкрософт в области поддержки репликации данных, как указано в статье 895847 базы знаний Майкрософт Репликация данных на нескольких узлах для приложений Exchange Server (может быть на английском языке). Кроме того, решения, использующие модель ресурсов отказоустойчивого кластера Windows, должны отвечать требованиям поддержки кластеров Windows, как указано в статье 943984 базы знаний Майкрософт Политика поддержки Майкрософт для отказоустойчивых кластеров Windows Server 2008 (может быть на английском языке).

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

Партнеры корпорации Майкрософт могут получить сведения о стороннем интерфейсе API репликации в любом местном представительстве. Дополнительные сведения о продуктах наших партнеров для сервера Exchange 2010 см. на странице Партнеры Microsoft Exchange (на английском языке).

В начало