Общие сведения о высоком уровне доступности и устойчивости сайта к сбоям

  • Статья

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

Последнее изменение раздела: 2009-12-07

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

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

Содержание

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

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

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

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

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

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

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

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

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

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

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

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

  • Группа обеспечения доступности баз данных
    Группа, содержащая до 16 серверов почтовых ящиков Exchange 2010, в которой размещается набор реплицированных баз данных.
  • Мобильность баз данных
    Способность отдельной базы данных почтовых ящиков Exchange 2010 к репликации и подключению на других серверах почтовых ящиков Exchange 2010.
  • Аварийное восстановление
    Любой процесс, используемый для ручного восстановления после сбоя. Это может быть сбой, затрагивающий как отдельный объект, так и все физическое расположение.
  • Интерфейс API Exchange для сторонней репликации
    Представленный в Exchange интерфейс API, который позволяет использовать для группы обеспечения доступности баз данных стороннюю синхронную репликацию вместо непрерывной репликации.
  • Высокая доступность
    Решение, которое обеспечивает доступность служб и данных, а также автоматическое восстановление после сбоев, затрагивающих службы или данные (например, сбой сети, хранилища или сервера).
  • Добавочное развертывание
    Возможность развертывания функций высокой доступности и устойчивости к сбоям после установки Exchange 2010.
  • Изолированная копия базы данных почтовых ящиков
    Пассивная копия базы данных почтовых ящиков, у которой время запаздывания преобразования журнала больше нуля.
  • Копия базы данных почтовых ящиков
    База данных почтовых ящиков (файл EDB и журналы), которая находится в активном или пассивном состоянии.
  • Устойчивость почтовых ящиков
    Название объединенного решения по обеспечению высокой доступности и устойчивости к сбоям в Exchange 2010.
  • Служба клиентского доступа RPC
    Новая служба, предоставляющая клиентам Microsoft Outlook конечную точку MAPI.
  • Устойчивость сайта к сбоям
    Процесс ручного аварийного восстановления, который используется для восстановления после сбоя, затронувшего весь сайт. Для настройки высокой доступности решения по обмену сообщениями и включения функции устойчивости сайта к сбоям можно использовать встроенные компоненты и функциональные возможности 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 баз данных не учитывается.

Изменения в непрерывной репликации по сравнению с версией Exchange Server 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 2007

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

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

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

В транспортную корзину также внесены улучшения, которые позволяют учитывать изменения в роли сервера почтовых ящиков, разрешающие перемещение отдельной базы данных почтовых ящиков между сайтами 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 также включает в себя множество функций, предназначенных для повышения сквозной доступности системы. В эти функции входят:

  • теневая избыточность;
  • оперативный режим перемещения почтового ящика;
  • гибкая защита почтовых ящиков;
  • добавочная повторная синхронизация;
  • сторонний интерфейс 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 2010 добавочная повторная синхронизация — это новое название функции автоматического исправления расхождений в копиях баз данных в следующих ситуациях:

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

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

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

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

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

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

В начало