Высокая доступность и устойчивость сайтов

Область применения: Exchange Server 2013 г.

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

Exchange 2013 позволяет клиентам любого размера и во всех сегментах экономично развертывать службу непрерывности обмена сообщениями в своей организации, используя собственные возможности репликации и архитектуру высокого уровня доступности, представленные в Exchange 2010. Список изменений в Exchange 2010 и Exchange 2007 см. в разделе Changes to high availability and site resilience over previous versions.

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

Следующие ключевые понятия важно понимать высокой доступности и устойчивости сайта:

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

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

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

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

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

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

• Центр обработки данных. Обычно это относится к сайту Active Directory; однако он также может ссылаться на физический сайт. В контексте этой документации центр обработки данных равен сайту Active Directory.

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

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

• API репликации сторонних поставщиков Exchange. Api, предоставляемый Exchange, который позволяет использовать стороннюю синхронную репликацию для DAG вместо непрерывной репликации.

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

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

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

• Копирование базы данных почтового ящика: база данных почтового ящика (EDB-файл и журналы), которая является активной или пассивной.

• Устойчивость почтовых ящиков. Имя единого решения для обеспечения высокого уровня доступности и устойчивости сайтов в Exchange 2013.

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

• *over (произносится как "star over"): сокращение для переключений и отработок отказа. Переключение представляет собой ручную активацию одной или нескольких копий базы данных. Отработка отказа представляет собой автоматическую активацию одной или нескольких копий базы данных после сбоя.

• Safety Net: ранее известная как транспортная мусорная корзина, это функция транспортной службы, которая хранит копию всех сообщений в течение X дней. Значение по умолчанию: 2 дня.

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

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

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

DAG — это базовый компонент платформы высокого уровня доступности и устойчивости сайта, встроенной в Exchange 2013. Группа обеспечения доступности баз данных — это группа серверов почтовых ящиков (до 16 серверов), которые содержат набор баз данных и обеспечивают автоматическое восстановление на уровне базы данных после сбоя, затрагивающего отдельные серверы и базы данных. На любом сервере в группе обеспечения доступности баз данных можно разместить копию базы данных почтовых ящиков с любого другого сервера в группе обеспечения доступности баз данных. Если сервер добавлен в группу обеспечения доступности баз данных, он вместе с другими серверами в этой группе обеспечивает автоматическое восстановление после сбоев, затрагивающих базы данных почтовых ящиков, например сбоев дисков или серверов. Дополнительные сведения о группах обеспечения доступности баз данных см. в разделе Database availability groups (DAGs).

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

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

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

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

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

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

Active Manager

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

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

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

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

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

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

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

В Exchange 2013 пространство имен не нужно перемещать вместе с DAG. Exchange использует отказоустойчивость, встроенную в пространство имен через несколько IP-адресов, распределения нагрузки (и в случае необходимости, возможность введения серверов в эксплуатацию и их выведения из эксплуатации). Современные HTTP-клиенты работают с этой избыточностью автоматически. Стек HTTP может принимать несколько IP-адресов для полного доменного имени (FQDN), и если первый IP-адрес, который он пытается выполнить, не удается (то есть не удается подключиться), он попытается получить следующий IP-адрес в списке. При обратимом сбое (подключение теряется после установки сеанса, возможно, из-за периодических сбоев в службе, когда, например, устройство удаляет пакеты и должно быть удалено из службы), пользователю может потребоваться обновить браузер.

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

Одно из изменений в Exchange 2013 заключается в том, что клиенты могут иметь несколько мест для работы. Предположим, что клиент может использовать несколько мест (почти все протоколы клиентского доступа в Exchange 2013 основаны на HTTP (например, Outlook, Outlook Anywhere, EAS, EWS, OWA и EAC), а все поддерживаемые HTTP-клиенты имеют возможность использовать несколько IP-адресов), тем самым обеспечивая отработку отказа на стороне клиента. Вы можете настроить DNS для передачи нескольких IP-адресов клиенту в процессе разрешения имен. Клиент запрашивает mail.contoso.com и получает, например, 2 или 4 IP-адреса. Клиент использует все полученные им IP-адреса. Это делает клиент намного лучше, потому что в случае сбоя одного из IP-адресов у клиента есть один или несколько других IP-адресов, к которому нужно подключиться. Если клиенту не удается подключиться по одному из IP-адресов, он ожидает приблизительно 20 секунд, а затем пытается использовать следующий IP-адрес в списке. Таким образом, если вы потеряете виртуальный IP-адрес для массива серверов клиентского доступа, восстановление для клиентов происходит автоматически и примерно через 21 секунду.

Ниже перечислены связанные с этим преимущества.

• В Exchange 2010 при потере подсистемы балансировки нагрузки в главном центре обработки данных (и при этом на данном сайте отсутствовала другая подсистема) приходилось выполнять переключение центра обработки данных. В Exchange 2013 при потере подсистемы балансировки нагрузки на главном сайте ее (или, возможно, важный компонент) просто необходимо отключить, а затем отремонтировать или заменить. В клиентах, в которых уже не используется важный компонент в дополнительном центре обработки данных, будет выполнена автоматическая отработка отказа на дополнительный важный компонент без изменения пространства имен и DNS. Благодаря этому не только отпадает необходимость в переключении, но и экономится время, которое обычно тратится на переключение центра обработки данных. В Exchange 2010 приходилось обрабатывать задержку DNS (поэтому рекомендовалось установить срок жизни (TTL) в 5 минут, а также ввести URL-адрес для обработки отказа). В Exchange 2013 эти операции не требуются благодаря быстрой обработке отказа (20 секунд) пространства имен между важными компонентами (центрами обработки данных).

• Благодаря быстрой обработке пространства имен между центрами обработки данных все, что требуется для обработки отказа центра обработки данных, — механизм обработки отказа роли сервера почтовых ящиков в центрах обработки данных. Для автоматической обработки отказа для группы обеспечения доступности баз данных необходимо просто разработать решение, при котором группа равномерно распределяется между двумя центрами обработки данных, а затем разместить следящий сервер в третьем расположении для его арбитража членами группы обеспечения доступности баз данных в каждом центре обработки данных (вне зависимости от состояния сети между центрами обработки данных с членами этой группы). Если у вас есть только два центра обработки данных и третье физическое расположение недоступно, вы можете разместить следящий сервер на виртуальной машине Microsoft Azure. Дополнительные сведения см. в разделе Using a Microsoft Azure VM as a DAG witness server.

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

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

Exchange 2013 также обеспечивает функциональность, позволяет администраторам разобраться с периодическим сбоям. Прерывистый сбой происходит, если, например, ничего не происходит после установки начального TCP-соединения. Непредвиденный сбой требует некоторой дополнительной административные взыскания, так как это может быть в результате ввода в эксплуатацию нового устройства. В ходе восстановления устройство может быть включено и принимать некоторые запросы, но оно фактически не готово к обслуживанию клиентов, пока не будут выполнены необходимые действия по настройке. В этом сценарии, администратор может выполнять пространства имен, просто удалив VIP переключение для заменяемого устройства от DNS. Затем в течение этого периода, нет клиентов будут пытаться подключиться к нему. После замены администратор может добавить важный компонент обратно в DNS, а клиенты в конечном итоге начнут использовать его.

Дополнительные сведения о планировании и развертывании см. в разделе Планирование высокой доступности и устойчивости сайтов или Развертывание с высоким уровнем доступности и устойчивости сайта.

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

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

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

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

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

Документация высоким уровнем доступности и устойчивости сайта

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