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

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

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

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

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

Содержание

Жизненный цикл группы обеспечения доступности баз данных

Использование группы обеспечения доступности баз данных для обеспечения высокого уровня доступности

Использование группы обеспечения доступности баз данных для устойчивости сайта

Работа клиентов при использовании групп обеспечения доступности баз данных

Жизненный цикл группы обеспечения доступности баз данных

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

Группа обеспечения доступности баз данных создается с помощью командлета New-DatabaseAvailabilityGroup. Изначально группа обеспечения доступности баз данных создается как пустой объект в Служба каталогов Active Directory. Этот объект каталога используется для хранения необходимых сведений о группе обеспечения доступности баз данных, например сведений о членстве сервера. При добавлении первого сервера в группу доступности баз данных для нее автоматически создается отказоустойчивый кластер. Этот отказоустойчивый кластер используется исключительно для группы обеспечения доступности баз данных; кластер должен быть выделен для этой группы. Поддержка этого кластера для любых других целей не поддерживается.

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

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

В этом примере показана группа обеспечения доступности баз данных, в которую включены три сервера. Два сервера (EX1 и EX2) находятся в одной подсети (10.0.0.0), а третий сервер (EX3) расположен в другой подсети (192.168.0.0).

Скопировать код 
New-DatabaseAvailabilityGroup -Name DAG1 -DatabaseAvailabilityGroupIPAddresses 10.0.0.5,192.168.0.5
Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer EX1
Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer EX2
Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer EX3
Примечание.
Чтобы для получения IP-адресов или ресурсов IP-адресов группа обеспечения доступности баз данных (кластер) использовала DHCP-сервер, присвойте параметру DatabaseAvailabilityGroupIPAddresses значение 0.0.0.0.

При добавлении сервера EX1 в группу обеспечения доступности баз данных создается кластер для группы DAG1. В ходе создания кластера командлет Add-DatabaseAvailabilityGroupServer получает IP-адреса, настроенные для серверов группы обеспечения доступности баз данных, и игнорирует те из них, которые не соответствуют ни одной подсети, указанной на сервере EX1. В этом примере для группы DAG1 создается кластер с IP-адресом 10.0.0.5, а адрес 192.168.0.5 — игнорируется.

Затем добавляется сервер EX2 и командлет Add-DatabaseAvailabilityGroupServer снова получает IP-адреса, указанные в конфигурации группы обеспечения доступности баз данных. IP-адреса кластера не изменяются, поскольку серверы EX2 и EX1 находятся в одной подсети.

Затем добавляется сервер EX3 и командлет Add-DatabaseAvailabilityGroupServer снова получает IP-адреса, указанные в конфигурации группы обеспечения доступности баз данных. Поскольку на сервере EX3 присутствует подсеть, соответствующая IP-адресу 192.168.0.5, IP-адрес 192.168.0.5 добавляется в качестве ресурса IP-адреса в кластерной группе. Дополнительно для каждого ресурса IP-адреса автоматически настраивается зависимость OR для ресурса сетевого имени. При перемещении кластерной группы на сервер EX3 кластер будет использовать адрес 192.168.0.5.

При переводе ресурса сетевого имени в оперативный режим отказоустойчивый кластер Windows регистрирует IP-адреса кластера в службе DNS. Кроме того, в Служба каталогов Active Directory создается сетевой объект кластера. Имя, IP-адреса и сетевой объект кластера используются только внутри системы для обеспечения безопасности группы обеспечения доступности баз данных и осуществления внутренней связи. Администраторам и конечным пользователям нет необходимости обращаться или подключаться к имени группы обеспечения доступности баз данных или IP-адресу.

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

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

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

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

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

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

Режимы кворума группы обеспечения доступности баз данных

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

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

  • Разрешение конфликтов   Ресурс-свидетель кворума используется в группах обеспечения доступности баз данных с четным количеством членов для предотвращения синдрома разделенности и обеспечения официального признания только одного набора членов группы обеспечения доступности баз данных. Если для кворума нужен сервер-свидетель, любой член группы обеспечения доступности может связаться с сервером-свидетелем и поместить блокировку SMB на файл witness.log этого сервера. Член группы обеспечения доступности, который блокирует сервер-свидетель (называется блокирующим узлом) сохраняет дополнительный голос для кворума. Члены группы обеспечения доступности баз данных, поддерживающие связь с блокирующим узлом, представляют собой большинство и тем самым поддерживают кворум. Любые члены группы обеспечения доступности баз данных, которые не могут связаться с блокирующим узлом, являются меньшинством и теряют кворум.

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

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

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

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

В начало

Использование группы обеспечения доступности баз данных для обеспечения высокого уровня доступности

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


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

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

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

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

Скопировать код 
Move-ActiveMailboxDatabase -Server EX2

В этом примере активной является только одна база данных почтовых ящиков на сервере EX2 (DB4), поэтому перемещается только одна копия базы данных почтовых ящиков. Если параметр ActivateOnServer в предыдущей команде не указан, система самостоятельно выбирает самую новую активную копию. Система выбирает копию на сервере EX5, как показано на следующем рисунке.

Группа обеспечения доступности баз данных с сервером, переведенным в автономный режим для обслуживания

Группа доступности базы данных с сервером в автономном режиме

При выполнении обслуживание сервера EX2 на сервере EX3 происходит аппаратный сбой и сервер переходит в автономный режим. До перехода в автономный режим на сервере EX3 размещалась активная копия базы данных DB2. Чтобы восстановить сервер после сбоя, система автоматически активирует копию базы данных DB2, размещенную на сервере EX1, в течение 30 сек. Это процесс показан на следующем рисунке.

Группа доступности базы данных с сервером в автономном режиме для обслуживания и неисправным сервером

Группа доступности базы данных (DAG) с сервером в автономном режиме и неисправным сервером

После завершения запланированного обслуживания сервера EX2 он возвращается в оперативный режим. После запуска сервера EX2 другие члены группы обеспечения доступности баз данных получают уведомление, а копии базы данных DB1, DB4 и DB5, размещенные на сервере EX2, автоматически синхронизируются с активной копией каждой базы данных. Это процесс показан на следующем рисунке.

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

Группа доступности базы данных (DAG) с восстановленными базами данных повторной синхронизации сервера

После сбоя на сервере EX3 аппаратный компонент был заменен на новый, а сервер EX3 переведен в оперативный режим. После запуска сервера EX3 другие члены группы обеспечения доступности баз данных получают уведомление, а копии базы данных DB2, DB3 и DB4, размещенные на сервере EX3, автоматически синхронизируются с активной копией каждой базы данных. Это процесс показан на следующем рисунке.

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

Группа доступности базы данных (DAG) с копиями базы данных повторной синхронизации участников

В начало

Использование группы обеспечения доступности баз данных для устойчивости сайта

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

Группа обеспечения доступности базы данных, расширенная на два сайта Active Directory

Группа доступности базы данных (DAG) расширенная на два сайта Active Directory

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

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

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

Использование нескольких групп обеспечения доступности баз данных для устойчивости сайта

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

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

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

В начало

Работа клиентов при использовании групп обеспечения доступности баз данных

Группы обеспечения доступности баз данных могут быть использованы для обеспечения высокой доступности и отказоустойчивости на уровне сайтов. Работа клиентов при использовании этих групп обеспечения доступности зависит от типа и версии клиента, а также протокола, который используется клиентом для получения доступа к данным в почтовом ящике. Например, если возникает переход базы данных на другой ресурс при сбое между сайтами, поведение и логика повторного подключения клиентов POP3 или IMAP4 отличается от поведения и логики повторного подключения клиента Microsoft Outlook 2010.

В следующих разделах описано поведение клиентов и логика при различных сценариях. При описании поведения предполагается следующее.

  • В среде присутствует один массив серверов клиентского доступа в каждом сайте Служба каталогов Active Directory, каждый сайт содержит хотя бы два сервера клиентского доступа.

  • Перед массивом серверов клиентского доступа установлен и настроен надлежащий аппаратный или программный балансировщик нагрузки.

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

Поведение и логика Microsoft Outlook

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

  • При выполнении перехода базы данных на другой ресурс при сбое Outlook остается подключенным к одному серверу в массиве серверов клиентского доступа. При этом клиент Active Manager, работающий на сервере клиентского доступа, определяет у службы Active Manager группы обеспечения доступности баз данных, какой член группы содержит активную копию базы данных. Затем сервер клиентского доступа подключается к серверу почтовых ящиков. Клиент Outlook показывает, что он подключен к серверу Exchange.

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

Все версии Outlook также ведут себя при переключении центров данных, которые возникают между двумя центрами данных и двумя сайтами Служба каталогов Active Directory. Переключения центров данных включают изменения IP-адресов, которые используются пространствами имен клиентского доступа (например, Microsoft Office Outlook Web App, SMTP, POP3, IMAP4, Autodiscover, веб-службы Exchange или клиентский доступ через удаленный вызов процедур) с IP-адресов основного центра данных на IP-адреса второго центра данных. В результате пространство имен, используемое в профиле пользователя Outlook, не изменяется и функция автоматического обнаружения продолжает указывать клиентам на то же пространство имен массива серверов клиентского доступа.

Поведение Outlook после перехода базы данных на другой ресурс при сбое между сайтами отличается от поведения при переходе базы данных на другой ресурс в одном сайте Служба каталогов Active Directory или при переключении центров данных.

Пример поведения версий Outlook

В следующих примерах показано поведение Outlook 2010, Office Outlook 2007 и Office Outlook 2003 после перехода базы данных на другой ресурс между сайтами. Топология, использованная в каждом примере, состоит из группы обеспечения доступности баз данных, в которую входят четыре члена. Группа размещена в двух сайтах Служба каталогов Active Directory: Редмонд и Портленд. Почтовый ящик пользователя находится в базе данных DB1, которая реплицируется на каждый из серверов. В каждом примере активная копия DB1 переходит при сбое с MBX2 на MBX3.


Поведение Outlook с группами обеспечения доступности баз данных

Каждый клиент настроен на использование сервера клиентского доступа CAS1, что делает Редмонд сайтом профиля Outlook. Так как клиенты расположены в Редмонде, свойство RPCClientAccessServer для базы данных DB1 настроено для сервера CAS1, что делает Редмонд сайтом предпочитаемой базы данных. Так как база данных DB1 перестала быть доступной на MBX2 вследствие сбоя и стала активной на MBX3, Портленд является сайтом подключенной базы данных.

Пример с использованием Outlook 2010 и Outlook 2007

Если сервер клиентского доступа доступен на сайте Редмонда, то приложения Outlook 2010 и Outlook 2007 будут продолжать подключаться к массиву серверов клиентского доступа RPC на сайте Редмонда. Сервер клиентского доступа, используемый клиентом, будет устанавливать связь с помощью протокола MAPI RPC с сервером почтовых ящиков пользователя на сайте Портленда.

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

Пример с использованием Outlook 2003

При попытке Outlook 2003 подключиться к серверу CAS1 также возникает сообщение ecWrongServer. В отличие от Outlook 2010 и Outlook 2007 Outlook 2003 не содержит функции автоматического обнаружения и должен использовать другие способы обновления профиля пользователя. Перенаправление профиля MAPI – это механизм, который используется клиентом Outlook 2003. Перенаправление профиля MAPI нуждается в работающем состоянии исходного сервера. Если сервер CAS1 недоступен или все серверы клиентского доступа в массиве также недоступны (или если массив состоит только из сервера CAS1), Outlook 2003 не может выполнить перенаправление MAPI или подключиться к базе данных почтовых ящиков, в которой хранится почтовый ящик пользователя, без вмешательства пользователя.

Поведение и логика Outlook при использовании общих папок

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

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

Поведение и логика прочих клиентов (не Outlook)

В целом, поведение клиентов и протоколов, отличных от Outlook и MAPI, зависит от используемого приложения и причины сбоя. В целом, как и при использовании Outlook, типичные приложения и клиенты Exchange (такие как Outlook Web App, Microsoft Exchange ActiveSync, POP3, IMAP4 и веб-службы Exchange) ведут себя одинаково при переходе баз данных на другой ресурс при сбое в рамках одного центра данных и одного сайта Служба каталогов Active Directory. Все клиенты и протоколы (включая SMTP и Windows PowerShell) ведут себя так же, как и Outlook при переключении между центрами данных.

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

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

Клиент или протокол Поведение

Outlook Web App

Перенаправление вручную. В этом сценарии пространство имен клиента изменяется с http://mailred.contoso.com на http://mailpdx.contoso.com. После ввода пользователем учетных данных для входа он перенаправляется на сервер CAS2 с сайта Портленда через страницу перенаправления вручную, на которой объясняется, что был использован недопустимый URL-адрес и что правильным URL-адресом является https://mailpdx.contoso.com/owa.

Exchange ActiveSync

Прокси-сервер или перенаправление. В этом сценарии поведение клиента определяется реализацией и версией протокола Exchange ActiveSync на устройстве клиента.

Протоколы POP3 и IMAP4

Прокси-сервер. Этот сценарий всегда включает использование прокси-сервера между двумя серверами клиентского доступа.

Веб-службы Exchange

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

В начало


Пример топологии, демонстрирующей поведение Outlook при переходе базы данных на другой ресурс при сбое между сайтами
Группа обеспечения доступности баз данных с пятью членами