Высокий уровень доступности и устойчивость сайта в Exchange Server

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

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

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

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

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

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

AutoDatabaseMountDial

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

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

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

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

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

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

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

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

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

Datacenter

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

Режим координации активации центра данных

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Имя единого решения для обеспечения высокого уровня доступности и устойчивости сайта в Exchange Server.

Управляемая доступность

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

*over (произносится "star over")

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

Система безопасности

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

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

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

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

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

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

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

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

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

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

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

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

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

Active Manager

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

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

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

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

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

В Exchange Server клиенты имеют несколько мест. Почти все протоколы клиентского доступа в Exchange Server основаны на HTTP. Примеры — Outlook, EAS, EWS, Outlook в Интернете и Центр администрирования Exchange. У всех поддерживаемых клиентов HTTP имеется возможность использовать несколько IP-адресов, что позволяет выполнить отработку отказов на стороне клиента. Вы можете настроить DNS для передачи нескольких IP-адресов клиенту в процессе разрешения имен. Клиент запрашивает mail.contoso.com и получает, например, 2 или 4 IP-адреса. Клиент использует все полученные им IP-адреса. Это повышает эффективность работы клиента, так как при сбое одного из IP-адресов у клиента будет еще один или несколько IP-адресов, по которым он может попытаться подключиться. Если клиенту не удается подключиться по одному из IP-адресов, он ожидает приблизительно 20 секунд, а затем пытается использовать следующий IP-адрес в списке. Таким образом, если вы потеряете виртуальный IP-адрес для массива служб клиентского доступа, то восстановление для клиентов будет выполнено автоматически приблизительно через 21 секунду.

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

• В Exchange Server, если вы потеряете подсистему балансировки нагрузки на основном сайте, вы просто отключите его (или, возможно, отключите виртуальный ip-адрес) и восстановите или замените его. В клиентах, в которых уже не используется виртуальный IP-адрес в дополнительном центре обработки данных, будет выполнена автоматическая отработка отказа на дополнительный важный компонент без изменения пространства имен и DNS. Благодаря этому не только отпадает необходимость в переключении, но и экономится время, которое обычно тратится на переключение центра обработки данных. В Exchange 2010 приходилось обрабатывать задержку DNS (поэтому рекомендовалось установить срок жизни [TTL] в 5 минут, а также ввести URL-адрес для обработки отказа). В Exchange 2016 и Exchange 2019 это не требуется, так как вы получаете быструю отработку отказа (20 секунд) пространства имен между ВИРТУАЛЬНЫми IP-адресами (центрами обработки данных).

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

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

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

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

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

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

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

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

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

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

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

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