Группы обеспечения доступности баз данныхDatabase availability groups (DAGs)

Применимо к: Exchange Server 2013Applies to: Exchange Server 2013

Ознакомьтесь с группами обеспечения доступности баз данных в Exchange Server 2013. В этой статье описывается жизненный цикл групп обеспечения доступности базы данных доступности, а также их использование для обеспечения высокой доступности и устойчивости сайта.Learn about Exchange DAG in Exchange Server 2013. This article discusses the database availability group (DAG) lifecycle, as well as using a DAG for high availability and for site resilience.

Группа обеспечения доступности баз данных (DAG) — это основной компонент обеспечения высокого уровня доступности сервера почтовых ящиков и устойчивости сайта, встроенный в Microsoft Exchange Server 2013. Группа обеспечения доступности баз данных — это группа серверов почтовых ящиков (до 16 серверов), которая содержит набор баз данных и обеспечивает автоматическое восстановление на уровне базы данных после сбоя, затрагивающего отдельные серверы и базы данных.A database availability group (DAG) is the base component of the Mailbox server high availability and site resilience framework built into Microsoft Exchange Server 2013. A DAG is a group of up to 16 Mailbox servers that hosts a set of databases and provides automatic database-level recovery from failures that affect individual servers or databases.

Группы доступности базы данных — это граница для репликации базы данных почтовых ящиков, базы данных и сервера переключения и отработки отказа и внутренний компонент называется Active Manager. Активный диспетчер, который выполняется на каждом сервере почтовых ящиков, управляет переключения и отработки отказа в рамках групп DAG. Для получения дополнительных сведений о Active Manager видеть Active Manager.A DAG is a boundary for mailbox database replication, database and server switchovers and failovers, and an internal component called Active Manager. Active Manager, which runs on every Mailbox server, manages switchovers and failovers within DAGs. For more information about Active Manager, see Active Manager.

На любом сервере в группе обеспечения доступности баз данных можно разместить копию базы данных почтовых ящиков с любого другого сервера в группе обеспечения доступности баз данных. Если сервер добавлен в группу обеспечения доступности баз данных, он вместе с другими серверами в этой группе обеспечивает автоматическое восстановление после сбоев, затрагивающих базы данных почтовых ящиков, например после сбоев дисков, серверов или сетей.Any server in a DAG can host a copy of a mailbox database from any other server in the DAG. When a server is added to a DAG, it works with the other servers in the DAG to provide automatic recovery from failures that affect mailbox databases, such as a disk, server, or network failure.

СодержаниеContents

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

Использование группы обеспечения доступности баз данных для обеспечения высокого уровня доступностиUsing a database availability group for high availability

Использование группы обеспечения доступности баз данных для обеспечения устойчивости сайтаUsing a database availability group for site resilience

Жизненный цикл группы обеспечения доступности баз данныхDatabase availability group (DAG) lifecycle

Групп DAG использовать концепцию добавочное развертывание, которая является возможность развертывания доступностью служб и данных для всех баз данных и серверы почтовых ящиков после установки Exchange. После развертывания серверов почтовых ящиков Exchange 2013 можно создавать группы доступности базы данных, добавьте серверы почтовых ящиков для обеспечения доступности баз данных и затем репликации базы данных почтовых ящиков между членами группы доступности базы данных.DAGs leverage the concept of incremental deployment, which is the ability to deploy service and data availability for all Mailbox servers and databases after Exchange is installed. After you deploy Exchange 2013 Mailbox servers, you can create a DAG, add Mailbox servers to the DAG, and then replicate mailbox databases between the DAG members.

Примечание

Поддерживается для создания группы доступности базы данных, содержащий сочетание физических серверов почтовых ящиков и виртуальных серверов почтовых ящиков, при условии, что серверов и решений соответствовать требованиям, изложенным в и системные требования Exchange 2013 Виртуализация Exchange 2013. Как и для всех конфигураций высокой доступности Exchange, необходимо убедиться, что все серверы почтовых ящиков в группе DAG выбран соответствующий размер обрабатывать необходимые рабочей нагрузки во время запланированных и незапланированных простоев.It's supported to create a DAG that contains a combination of physical Mailbox servers and virtualized Mailbox servers, provided that the servers and solution comply with the Exchange 2013 system requirements and the requirements set forth in Exchange 2013 virtualization. As with all Exchange high availability configurations, you must ensure that all Mailbox servers in the DAG are sized appropriately to handle the necessary workload during scheduled and unscheduled outages.

Группа обеспечения доступности баз данных создается с помощью командлета New-DatabaseAvailabilityGroup. Изначально группа обеспечения доступности баз данных создается как пустой объект в Active Directory. Этот объект каталога используется для хранения необходимых сведений о группе обеспечения доступности баз данных, например сведений о членстве сервера и некоторых параметров конфигурации групп обеспечения доступности баз данных. При добавлении первого сервера в группу доступности баз данных для нее автоматически создается отказоустойчивый кластер. Этот отказоустойчивый кластер используется исключительно для группы обеспечения доступности баз данных; кластер должен быть выделен для этой группы. Поддержка этого кластера для любых других целей не поддерживается.A DAG is created by using the New-DatabaseAvailabilityGroup cmdlet. A DAG is initially created as an empty object in Active Directory. This directory object is used to store relevant information about the DAG, such as server membership information and some DAG configuration settings. When you add the first server to a DAG, a failover cluster is automatically created for the DAG. This failover cluster is used exclusively by the DAG, and the cluster must be dedicated to the DAG. Use of the cluster for any other purpose isn't supported.

Помимо создания отказоустойчивого кластера инициализируется инфраструктура, которая отслеживает сбои на серверах и в сети. Для отслеживания и обработки сведений о группе обеспечения доступности баз данных используется механизм периодических сигналов о подтверждении соединения с отказоустойчивым кластером и база данных кластера. Сведения о группе обеспечения доступности баз данных могут изменяться очень быстро, например сведения о состоянии подключения базы данных, состоянии репликации и о последнем подключении.In addition to a failover cluster being created, the infrastructure that monitors the servers for network or server failures is initiated. The failover cluster heartbeat mechanism and cluster database are then used to track and manage information about the DAG that can change quickly, such as database mount status, replication status, and last mounted location.

При создании каждая группа обеспечения доступности баз данных получает уникальное имя, а также один или несколько статических IP-адресов, настраивается для использования протокола DHCP или создается без точки административного доступа кластера. Группы обеспечения доступности баз данных без точки административного доступа кластера можно создать на серверах, на которых используется Exchange 2013 с пакетом обновления 1 (SP1) или более поздней версии под управлением Windows Server 2012 R2 Standard или Datacenter Edition. Группы обеспечения доступности баз данных без точки административного доступа кластера обладают следующими характеристиками:During creation, the DAG is given a unique name, and either assigned one or more static IP addresses or configured to use Dynamic Host Configuration Protocol (DHCP), or created without a cluster administrative access point. DAGs without an administrative access point can be created only on servers running Exchange 2013 Service Pack 1 or later on Windows Server 2012 R2 Standard or Datacenter edition. DAGs without cluster administrative access points have the following characteristics:

  • кластеру или группе обеспечения доступности баз данных не назначается IP-адрес, поэтому в группе основных ресурсов кластера отсутствует ресурс "IP-адрес";There is no IP address assigned to the cluster/DAG, and therefore no IP Address Resource in the cluster core resource group.

  • кластеру не назначается сетевое имя, поэтому в группе основных ресурсов кластера отсутствует ресурс "Сетевое имя";There is no network name assigned to the cluster, and therefore no Network Name Resource in the cluster core resource group

  • имя кластера/группы обеспечения доступности баз данных не зарегистрировано в DNS, оно неразрешимо в сети;The name of the cluster/DAG is not registered in DNS, and it is not resolvable on the network.

  • в Active Directory не создается объект имени кластера (CNO);A cluster name object (CNO) is not created in Active Directory.

  • управлять кластером с помощью средства управления отказоустойчивым кластером нельзя. Управлять им нужно с помощью Windows PowerShell, а командлеты Windows PowerShell должны выполняться в отношении отдельных элементов кластера;The cluster cannot be managed using the Failover Cluster Management tool. It must be managed using Windows PowerShell, and the PowerShell cmdlets must be run against individual cluster members.

В этом примере показано, как использовать командную консоль для создания группы обеспечения доступности баз данных с точкой административного доступа кластера, которая будет иметь три сервера. Два сервера (EX1 и EX2) находятся в одной подсети (10.0.0.0), а третий сервер (EX3) расположен в другой подсети (192.168.0.0).This example shows how to use the Shell to create a DAG with a cluster administrative access point that will have three servers. Two servers (EX1 and EX2) are on the same subnet (10.0.0.0), and the third server (EX3) is on a different subnet (192.168.0.0).

New-DatabaseAvailabilityGroup -Name DAG1 -WitnessServer EX4 -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

Команды для создания группы обеспечения доступности баз данных без точки административного доступа кластера очень похожи.The commands to create a DAG without a cluster administrative access point are very similar:

New-DatabaseAvailabilityGroup -Name DAG1 -WitnessServer EX4 -DatabaseAvailabilityGroupIPAddresses ([System.Net.IPAddress])::None
Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer EX1
Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer EX2
Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer EX3

При добавлении EX1 DAG создания кластера для с именем DAG1. При создании кластера командлет Add-DatabaseAvailabilityGroupServer получает IP-адресов, настроенных для обеспечения доступности баз данных и игнорирует из них, которые не соответствуют ни одной из подсетей, найденные на EX1. В первом примере выше кластера для создания с именем DAG1 с IP-адресом 10.0.0.5 и 192.168.0.5 игнорируется. В приведенном выше примере второй значение параметра DatabaseAvailabilityGroupIPAddresses указывает задач для создания отказоустойчивого кластера для группы доступности базы данных, для которого не точки административного доступа. Таким образом при создании кластера с IP-адрес или сетевой имя ресурсом в группе основных ресурсов кластера.The cluster for DAG1 is created when EX1 is added to the DAG. During cluster creation, the Add-DatabaseAvailabilityGroupServer cmdlet retrieves the IP addresses configured for the DAG and ignores the ones that don't match any of the subnets found on EX1. In the first example above, the cluster for DAG1 is created with an IP address of 10.0.0.5, and 192.168.0.5 is ignored. In the second example above, the value of the DatabaseAvailabilityGroupIPAddresses parameter instructs the task to create a failover cluster for the DAG that does not have an administrative access point. Thus, the cluster is created with an IP address or network name resource in the core cluster resource group.

Затем добавляется сервер EX2 и командлет Add-DatabaseAvailabilityGroupServer снова получает IP-адреса, указанные в конфигурации группы обеспечения доступности баз данных. IP-адреса кластера не изменяются, поскольку серверы EX2 и EX1 находятся в одной подсети.Then, EX2 is added, and the Add-DatabaseAvailabilityGroupServer cmdlet again retrieves the IP addresses configured for the DAG. There are no changes to the cluster's IP addresses because in EX2 is on the same subnet as EX1.

Затем добавляется сервер EX3 и командлет Add-DatabaseAvailabilityGroupServer снова получает IP-адреса, указанные в конфигурации группы обеспечения доступности баз данных. Поскольку на сервере EX3 присутствует подсеть, соответствующая IP-адресу 192.168.0.5, IP-адрес 192.168.0.5 добавляется в качестве ресурса IP-адреса в кластерной группе. Дополнительно для каждого ресурса IP-адреса автоматически настраивается зависимость OR для ресурса сетевого имени. При перемещении группы основных ресурсов кластера на сервер EX3 кластер будет использовать адрес 192.168.0.5.Then, EX3 is added, and the Add-DatabaseAvailabilityGroupServer cmdlet again retrieves the IP addresses configured for the DAG. Because a subnet matching 192.168.0.5 is present on EX3, the 192.168.0.5 address is added as an IP address resource in the cluster group. In addition, an OR dependency for the Network Name resource for each IP address resource is automatically configured. The 192.168.0.5 address will be used by the cluster when the cluster core resource group moves to EX3.

При переводе ресурса сетевого имени в оперативный режим средство отказоустойчивости кластеров Windows регистрирует IP-адреса кластера в службе DNS для групп обеспечения доступности баз данных с точками административного доступа кластера. Кроме того, когда к кластеру добавляется EX1, в Active Directory создается объект имени кластера (CNO). Для функций DAG сетевое имя, IP-адрес (IP-адреса) и CNO кластера не используются. Администраторам и конечным пользователям нет необходимости обращаться или подключаться к кластеру/имени группы обеспечения доступности баз данных или IP-адресу. Некоторые приложения сторонних производителей подключаются к точке административного доступа кластера для выполнения задач управления, например резервного копирования и мониторинга. Если вы не используете сторонние приложения, требующие наличия точки административного доступа кластера, а группа обеспечения доступа к базам данных запущена на Exchange 2013 с пакетом обновления 1 (SP1) или более поздней версии на Windows Server 2012 R2, рекомендуем создать группу обеспечения доступа к базам данных без точки административного доступа. Такой подход упрощает настройку DAG, устраняет необходимость в одном или нескольких IP-адресах и сокращает площадь атаки DAG.For DAGs with cluster administrative access points, Windows failover clustering registers the IP addresses for the cluster in the Domain Name System (DNS) when the Network Name resource is brought online. In addition, when EX1 is added to the cluster, a cluster name object (CNO) is created in Active Directory. The network name, IP address(es), and CNO for the cluster are not used for DAG functions. Administrators and end users don't need to interface with or connect to the cluster/DAG name or IP address for any reason. Some third party applications connect to the cluster administrative access point to perform management tasks, such as backup or monitoring. If you do not use any third party applications that require a cluster administrative access point, and your DAG is running Exchange 2013 SP1 or later on Windows Server 2012 R2, then we recommend creating a DAG without an administrative access point. This simplifies DAG configuration, eliminates the need for one or more IP addresses, and reduces the attack surface of a DAG.

Группы обеспечения доступа к базам данных также настраиваются для использования следящего сервера и следящего каталога. Следящий сервер и следящий каталог либо автоматически настраиваются системой, либо настраиваются администратором вручную. В приведенных выше примерах выполняется настройка EX4 (сервера, который не входит и не будет входить в DAG) в качестве следящего сервера DAG.DAGs are also configured to use a witness server and a witness directory. The witness server and witness directory are either automatically configured by the system, or they can be manually configured by the administrator. In the examples above, EX4 (a server that is not and will not be a member of the DAG) is being manually configured as the DAG’s witness server.

По умолчанию обеспечения доступности баз данных позволяет использовать функцию встроенной непрерывной репликации для репликации базы данных почтовых ящиков между серверами в группе DAG. Если вы используете репликация данных сторонних производителей, которая поддерживает API-Интерфейс репликации сторонних производителей в Exchange 2013, необходимо создать группы доступности базы данных в режиме сторонней репликации с помощью командлета New-DatabaseAvailabilityGroup с * ThirdPartyReplication* параметр. После включения этот режим не может быть отключен.By default, a DAG is designed to use the built-in continuous replication feature to replicate mailbox databases among servers in the DAG. If you're using third-party data replication that supports the Third Party Replication API in Exchange 2013, you must create the DAG in third-party replication mode by using the New-DatabaseAvailabilityGroup cmdlet with the ThirdPartyReplication parameter. After this mode is enabled, it can't be disabled.

После создания группы обеспечения доступности баз данных можно добавить серверы почтовых ящиков. После добавления в группу обеспечения доступности баз данных первого сервера для группы создается кластер. Группы обеспечения доступности баз данных используют функции, предоставляемые технологией отказоустойчивой кластеризации Windows: пульс кластера, сети кластера и база данных кластера (для хранения изменяющихся данных, например изменений состояния базы данных с активного на пассивное или наоборот либо с подключенного состояния на отключенное и наоборот). По мере добавления в группу обеспечения доступности баз данных серверы присоединяются к базовому кластеру, система Exchange автоматически настраивает модель кворума кластера, и серверы добавляются в объект группы обеспечения доступности баз данных в Active Directory.After the DAG is created, Mailbox servers can be added to the DAG. When the first server is added to the DAG, a cluster is formed for use by the DAG. DAGs make use of Windows failover clustering technology, such as the cluster heartbeat, cluster networks, and the cluster database (for storing data that changes, such as database state changes from active to passive or vice versa, or from mounted to dismounted and vice versa). As each subsequent server is added to the DAG, it's joined to the underlying cluster, the cluster's quorum model is automatically adjusted by Exchange, and the server is added to the DAG object in Active Directory.

После добавления серверов почтовых ящиков в группу обеспечения доступности баз данных можно настроить различные свойства группы обеспечения доступности баз данных, например указать, требуется ли шифрование и сжатие в сети при репликации базы данных в группе обеспечения доступности баз данных. Кроме того, можно настроить сети групп обеспечения доступности баз данных и при необходимости создать дополнительные сети групп обеспечения доступности баз данных.After Mailbox servers are added to a DAG, you can configure a variety of DAG properties, such as whether to use network encryption or network compression for database replication within the DAG. You can also configure DAG networks and create additional DAG networks.

После добавления членов в группу обеспечения доступности баз данных и настройки группы можно реплицировать активные базы данных почтовых ящиков на каждом сервере на других членов группы обеспечения доступности баз данных. Для отслеживания работоспособности и состояния созданных копий баз данных почтовых ящиков используются различные встроенные средства наблюдения. Кроме того, при необходимости можно выполнять переключение базы данных и сервера.After you add members to a DAG and configure the DAG, the active mailbox databases on each server can be replicated to the other DAG members. After you create mailbox database copies, you can monitor the health and status of the copies using a variety of built-in monitoring tools. In addition, you can perform database and server switchovers.

Дополнительные сведения о создании групп обеспечения доступности баз данных, управлении членством в группах, настройке свойств групп, создании и наблюдении за состоянием копий баз данных почтовых ящиков и выполнении переключения см. в разделе Управление высокой доступностью и устойчивостью сайтов.For more information about creating DAGs, managing DAG membership, configuring DAG properties, creating and monitoring mailbox database copies, and performing switchovers, see Managing high availability and site resilience.

Модели кворума группы обеспечения доступности баз данныхDatabase availability group (DAG) quorum models

Каждая группа обеспечения доступности баз данных основана на отказоустойчивом кластере Windows. Отказоустойчивые кластеры используют концепцию кворума, в которой согласованность участников кворума применяется для обеспечения того, что одновременно функционирует только одно подмножество членов кластера (куда могут входить все члены или большинство членов). Кворум не является новой концепцией Exchange 2013. Высокодоступные серверы почтовых ящиков в предыдущих версиях Exchange также работали в отказоустойчивых кластерах с использованием концепции кворума. Кворум представляет общее представление членов и ресурсов, а сам термин «кворум» также используется для описания физических данных, которые представляют конфигурацию в кластере, совместно используемую всеми членами кластера. В результате все группы обеспечения доступности баз данных требуют от базового отказоустойчивого кластера наличия кворума. Если кластер теряет кворум, все операции группы обеспечения доступности баз данных завершаются, а все подключенные базы данных, размещенные в этой группе, отключаются. В этом случае для исправления проблемы с кворумом и восстановления выполнения операций группы обеспечения доступности баз данных требуется вмешательство администратора.Underneath every DAG is a Windows failover cluster. Failover clusters use the concept of quorum, which uses a consensus of voters to ensure that only one subset of the cluster members (which could mean all members or a majority of members) is functioning at one time. Quorum isn't a new concept for Exchange 2013. Highly available Mailbox servers in previous versions of Exchange also use failover clustering and its concept of quorum. Quorum represents a shared view of members and resources, and the term quorum is also used to describe the physical data that represents the configuration within the cluster that's shared between all cluster members. As a result, all DAGs require their underlying failover cluster to have quorum. If the cluster loses quorum, all DAG operations terminate and all mounted databases hosted in the DAG dismount. In this event, administrator intervention is required to correct the quorum problem and restore DAG operations.

Кворум очень важен для обеспечения согласованности, разрешения конфликтов с целью предотвращения разделения и обеспечения отклика кластера.Quorum is important to ensure consistency, to act as a tie-breaker to avoid partitioning, and to ensure cluster responsiveness:

  • Проверка согласованности Основные требования для отказоустойчивого кластера Windows — это всех членов всегда имеет вид кластера, совместимые с другими участниками. Куст кластера действует как хранилище определенный для всех сведений о конфигурации, относящиеся к кластеру. Если куст кластера не удалось загрузить локально на члене, служба кластеров не запускается, так как он не будет гарантировать, что элемент удовлетворяет требование наличия view кластера, совместимые с другими участниками.Ensuring consistency A primary requirement for a Windows failover cluster is that each of the members always has a view of the cluster that's consistent with the other members. The cluster hive acts as the definitive repository for all configuration information relating to the cluster. If the cluster hive can't be loaded locally on a DAG member, the Cluster service doesn't start, because it isn't able to guarantee that the member meets the requirement of having a view of the cluster that's consistent with the other members.

  • В качестве разрешения конфликтов Ресурс-свидетель кворума используется в групп DAG с четным количеством участников во избежание split мозг синдром сценариев и убедитесь в том, что только одна коллекция членов в группы доступности базы данных рассматривается как официальный. При необходимости следящего сервера для кворума любого участника группы доступности базы данных, который может связаться с следящий сервер может заблокировать блок SMB (Server Message) файла witness.log следящий сервер. Член группы доступности базы данных, который блокирует следящий сервер (называется блокировки узел) сохраняет дополнительные голосование в целях кворума. Члены группы доступности базы данных с блокировки узел в большинстве и обслуживанию кворума. Все члены группы доступности базы данных, которые не удается связаться с блокировки узел в меньшей и поэтому теряют кворума.Acting as a tie-breaker A quorum witness resource is used in DAGs with an even number of members to avoid split brain syndrome scenarios and to make sure that only one collection of the members in the DAG is considered official. When the witness server is needed for quorum, any member of the DAG that can communicate with the witness server can place a Server Message Block (SMB) lock on the witness server's witness.log file. The DAG member that locks the witness server (referred to as the locking node) retains an additional vote for quorum purposes. The DAG members in contact with the locking node are in the majority and maintain quorum. Any DAG members that can't contact the locking node are in the minority and therefore lose quorum.

  • Обеспечение отклика   Чтобы обеспечить отклик, модель кворума гарантирует, что при функционировании кластера достаточно членов распределенной системы находятся в рабочем состоянии и поддерживают связь и что предоставляется хотя бы одна реплика текущего состояния кластера. Не требуется дополнительного времени для установки связи с членами или для определения наличия определенной реплики.Ensuring responsiveness To ensure responsiveness, the quorum model makes sure that, whenever the cluster is running, enough members of the distributed system are operational and communicative, and at least one replica of the cluster's current state can be guaranteed. No additional time is required to bring members into communication or to determine whether a specific replica is guaranteed.

Группы доступности баз данных с четным количеством членом используют режим кворума большинства узлов и общих файловых ресурсов, в котором разрешением конфликтов занимается внешний сервер-свидетель. В этом режиме кворума каждый член группы обеспечения доступности баз данных получает один голос. Кроме того, используется следящий сервер для предоставления одному члену группы взвешенный голос (то есть он получает два голоса вместо одного). Данные кворума кластера сохраняются по умолчанию на системном диске каждого члена группы обеспечения доступности баз данных и поддерживается в согласованном состоянии на всех дисках. Однако копия данных кворума не сохраняется на следящем сервере. Файл на следящем сервере используется для отслеживания того, какой член имеет наиболее обновленную копию данных, но сам следящий сервер не имеет копию данных кворума кластера. В этом режиме большинство голосующих членов (члены группы обеспечения доступности и сервер-свидетель) должны находиться в рабочем состоянии и поддерживать связь друг с другом для обеспечения кворума. Если большинство голосующих не может связаться друг с другом, кластер группы обеспечения доступности теряет кворум и группа обеспечения доступности баз данных будет нуждаться во вмешательстве администратора, чтобы снова стать работоспособной.DAGs with an even number of members use the failover cluster's Node and File Share Majority quorum mode, which employs an external witness server that acts as a tie-breaker. In this quorum mode, each DAG member gets a vote. In addition, the witness server is used to provide one DAG member with a weighted vote (for example, it gets two votes instead of one). The cluster quorum data is stored by default on the system disk of each member of the DAG, and is kept consistent across those disks. However, a copy of the quorum data isn't stored on the witness server. A file on the witness server is used to keep track of which member has the most updated copy of the data, but the witness server doesn't have a copy of the cluster quorum data. In this mode, a majority of the voters (the DAG members plus the witness server) must be operational and able to communicate with each other to maintain quorum. If a majority of the voters can't communicate with each other, the DAG's underlying cluster loses quorum, and the DAG will require administrator intervention to become operational again.

Группы обеспечения доступности баз данных с нечетных количеством членов используют режим кворума большинства узлов. В этом режиме каждый член получает голос, локальный системный диск каждого члена используется для хранения данных кворума кластера. При изменении конфигурации группы обеспечения доступности это изменение отражается на всех дисках. Изменение считается вступившим в силу и согласованным, если был внесено на дисках половины членов (с округлением в сторону понижения) плюс один. Например, в группе обеспечения доступности баз данных с пятью членами изменение должно быть внесено на двух членах плюс один, то есть на трех членах.DAGs with an odd number of members use the failover cluster's Node Majority quorum mode. In this mode, each member gets a vote, and each member's local system disk is used to store the cluster quorum data. If the configuration of the DAG changes, that change is reflected across the different disks. The change is only considered to have been committed and made persistent if that change is made to the disks on half the members (rounding down) plus one. For example, in a five-member DAG, the change must be made on two plus one members, or three members total.

Кворум собирается большинством голосующих членов, которые могут поддерживать связь друг с другом. Рассмотрим группу обеспечения доступности баз данных, состоящую из четырех членов. Так как эта группа имеет четное количество членов, внешний следящий сервер используется для предоставления одному из членов кластера пятого голоса для разрешения конфликтов. Чтобы обеспечить большинство голосующих (и, следовательно, наличие кворума), хотя бы три голосующих члена должны поддерживать связь друг с другом. В любое время не более двух голосующих члена может находиться в автономном режиме, не влияя на работу службы и доступа к данным. Если три и более голосующих члена находятся в автономном режиме, группа обеспечения доступности баз данных теряет кворум, служба и данные перестают быть доступными до устранения проблемы.Quorum requires a majority of voters to be able to communicate with each other. Consider a DAG that has four members. Because this DAG has an even number of members, an external witness server is used to provide one of the cluster members with a fifth, tie-breaking vote. To maintain a majority of voters (and therefore quorum), at least three voters must be able to communicate with each other. At any time, a maximum of two voters can be offline without disrupting service and data access. If three or more voters are offline, the DAG loses quorum, and service and data access will be disrupted until you resolve the problem.

В началоReturn to top

Использование группы обеспечения доступности баз данных для обеспечения высокого уровня доступностиUsing a database availability group (DAG) for high availability

Чтобы продемонстрировать, как группа обеспечения доступности баз данных может обеспечивать высокий уровень доступности баз данных почтовых ящиков, рассмотрим следующий пример группы, состоящей из 5 членов. Эта группа обеспечения доступности баз данных показана следующем рисунке.To illustrate how a DAG can provide high availability for your mailbox databases, consider the following example, which uses a DAG with five members. This DAG is illustrated in the following figure.

Группа обеспечения доступности баз данных с пятью членамиDAG with five members

![Группа доступности базы данных (DAG)] (images/Dd979799.21fcbf7b-cb10-49c0-8e32-bdf3c03f825d(EXCHG.150).gif "Группа доступности базы данных (DAG)")Database Availability Group (DAG)

На рисунке выше зеленым цветом показаны активные копии базы данных почтовых ящиков, а синим цветом — пассивные копии базы данных почтовых ящиков. В этом примере копии базы данных распространяются не на каждый сервер, а на несколько серверов. Это позволяет гарантировать, что в группе обеспечения доступности баз данных нет двух серверов с одинаковым набором копий баз данных, поэтому группа обеспечения доступности баз данных обеспечивает большую устойчивость к сбоям, включая сбои, возникающие при отключении других компонентов на плановое обслуживание.In the preceding figure, the green databases are active mailbox database copies and the blue databases are passive mailbox database copies. In this example, the database copies aren't mirrored across each server, but rather spread across multiple servers. This ensures that no two servers in the DAG have the same set of database copies, providing the DAG with greater resilience to failures, including failures that occur while other components are unavailable as a result of regular maintenance.

Рассмотрим следующий сценарий, используя предыдущий пример группы обеспечения доступности баз данных, который демонстрирует устойчивость к сбоям нескольких баз данных или серверов.Consider the following scenario, using the preceding example DAG, which illustrates resilience to multiple database and server failures.

Изначально все базы данных и серверы находятся в работоспособном состоянии. Необходимо установить определенные обновления операционной системы на EX2, поэтому переведите сервер в режим обслуживания. Это вызовет переключение сервера, в результате которого копия базы данных DB4 будет активирована на другом сервере почтовых ящиков. Переключение сервера служит для перемещения всех активных копий базы данных почтовых ящиков с текущего сервера на один или несколько других серверов почтовых ящиков в группе обеспечения доступности баз данных, чтобы подготовить текущий сервер к запланированному отключению. В этом примере активной является только одна база данных почтовых ящиков на сервере EX2 (DB4), поэтому перемещается только одна копия базы данных почтовых ящиков.Initially, all databases and servers are healthy. You need to install some operating system updates on EX2, so you put the server into maintenance mode. This causes a server switchover, which activates the copy of DB4 on another Mailbox server. A server switchover moves all active mailbox database copies from their current server to one or more other Mailbox servers in the DAG in preparation for a scheduled outage for the current server. In this example, there's only one active mailbox database on EX2 (DB4), so only one active mailbox database copy is moved.

Группа обеспечения доступности баз данных с сервером, переведенным в автономный режим для обслуживанияDAG with a server offline for maintenance

![Группа доступности базы данных (DAG) с сервером в автономном режиме] (images/Dd979799.f48f0e77-80e1-4f14-8c36-112393895bdc(EXCHG.150).gif "Группа доступности базы данных (DAG) с сервером в автономном режиме")Database Availability Group (DAG) with a Server Offline

При выполнении обслуживание сервера EX2 на сервере EX3 происходит аппаратный сбой и сервер переходит в автономный режим. До перехода в автономный режим на сервере EX3 размещалась активная копия базы данных DB2. Чтобы восстановить сервер после сбоя, система автоматически активирует копию базы данных DB2, размещенную на сервере EX1, в течение 30 сек. Это процесс показан на следующем рисунке.While you perform maintenance on EX2, EX3 experiences a catastrophic hardware failure and goes offline. Prior to going offline, EX3 hosted the active copy of DB2. To recover from the failure, the system automatically activates the copy of DB2 that's hosted on EX1 within 30 seconds. This is illustrated in the following figure.

Группа доступности базы данных с сервером в автономном режиме для обслуживания и неисправным серверомDAG with a server offline for maintenance and a failed server

![Группы доступности базы данных с сервером в автономном режиме и неисправным сервером] (images/Dd979799.9bbfd9e7-3881-4957-ae8d-32318cbc208b(EXCHG.150).gif "Группы доступности базы данных с сервером в автономном режиме и неисправным сервером")DAG with a server offline and a failed server

После завершения запланированного обслуживания для EX2 переведите сервер из режима обслуживания в оперативный режим. После запуска сервера EX2 другие члены группы обеспечения доступности баз данных получают уведомление, а копии базы данных DB1, DB4 и DB5, размещенные на сервере EX2, автоматически синхронизируются с активной копией каждой базы данных. Это процесс показан на следующем рисунке.After the scheduled maintenance is completed for EX2, you bring the server online and take it out of maintenance mode. As soon as EX2 is available, the other members of the DAG are notified, and the copies of DB1, DB4, and DB5 hosted on EX2 are automatically synchronized with the active copy of each database. This is illustrated in the following figure.

Группа обеспечения доступности баз данных с восстановленным сервером, синхронизирующим копии баз данныхDAG with a restored server synchronizing its database copies

![Группы доступности базы данных с базами данных повторной синхронизации восстановленного сервера] (images/Dd979799.58601531-e078-41d3-9287-e8e470ef7f41(EXCHG.150).gif "Группы доступности базы данных с базами данных повторной синхронизации восстановленного сервера")DAG with restored server resynchronizing databases

После сбоя на сервере EX3 аппаратный компонент был заменен на новый, а сервер EX3 переведен в оперативный режим. После запуска сервера EX3 другие члены группы обеспечения доступности баз данных получают уведомление, а копии базы данных DB2, DB3 и DB4, размещенные на сервере EX3, автоматически синхронизируются с активной копией каждой базы данных. Это процесс показан на следующем рисунке.After the failed hardware component in EX3 is replaced with a new component, EX3 is brought online. After EX3 is available, the other members of the DAG are notified, and the copies of DB2, DB3, and DB4 hosted on EX3 are automatically synchronized with the active copy of each database. This is illustrated in the following figure.

Группа обеспечения доступности баз данных с исправленным сервером, синхронизирующим копии баз данныхDAG with a repaired server synchronizing its database copies

![Группы доступности базы данных с помощью копий базы данных повторной синхронизации участников] (images/Dd979799.56259671-e840-4cf0-9ea2-3657dc36c035(EXCHG.150).gif "Группы доступности базы данных с помощью копий базы данных повторной синхронизации участников")DAG with Member Resynchronizing Database Copies

В началоReturn to top

Использование группы обеспечения доступности баз данных для обеспечения устойчивости сайтаUsing a database availability group (DAG) for site resilience

Помимо обеспечения высокой доступности в центре данных группу обеспечения доступности баз данных можно использовать в одном или нескольких центрах данных в конфигурации, которая обеспечивает устойчивость сайта для одного или нескольких центров данных. На рисунках, представленных в предыдущем примере, группа обеспечения доступности баз данных расположена в одном центре данных и одном сайте Active Directory. Для расширения этой группы обеспечения доступности баз данных на второй центр данных (и второй сайт Active Directory) можно использовать добавочное развертывание. Для этого необходимо развернуть сервер почтовых ящиков и ресурсы, требуемые для поддержки (один или несколько серверов Active Directory и службы DNS). Затем сервер почтовых ящиков добавляется в группу обеспечения доступности баз данных, как показано на следующем рисунке.In addition to providing high availability within a datacenter, a DAG can also be extended to one or more datacenters in a configuration that provides site resilience for one or multiple datacenters. In the preceding example figures, the DAG is located in a single datacenter and single Active Directory site. Incremental deployment can be used to extend this DAG to a second datacenter (and a second Active Directory site) by deploying a Mailbox server and the necessary supporting resources (one or more Active Directory servers, and DNS services). The Mailbox server is then added to the DAG, as illustrated in the following figure.

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

![Группы доступности базы данных, расширенная на два сайта Active Directory] (images/Dd979799.28e96e9d-d7d6-451a-b7b8-c06122c81dc9(EXCHG.150).gif "Группы доступности базы данных, расширенная на два сайта Active Directory")DAG extended across two Active Directory sites

В этом примере пассивная копия каждой активной базы данных в центре данных Редмонда хранится на сервере EX6 в центре данных Дублина. Однако существует множество других примеров конфигураций групп обеспечения доступности баз данных, обеспечивающих отказоустойчивость на уровне сайта. Например:In this example, a passive copy of each active database in the Redmond datacenter is configured on EX6 in the Dublin datacenter. However, there are many other examples of DAG configurations that provide site resilience. For example:

  • Вместо размещения только пассивных копий баз данных сервер EX6 может содержать все активные копии или сочетание активных и пассивных копий.Instead of hosting only passive database copies, EX6 could host all active copies, or it could host a mixture of active and passive copies.

  • В дополнение к серверу EX6 несколько членов группы обеспечения доступности баз данных могут быть развернуты в центре данных Дублина, что обеспечит защиту от дополнительных сбоев. Подобная конфигурация также обеспечивает дополнительные ресурсы, так что если в центре данных Редмонда произойдет неполадка, центр данных в Дублине сможет обслуживать большее количество пользователей.In addition to EX6, multiple DAG members could be deployed in the Dublin datacenter, providing protection against additional failures. This configuration also provides additional capacity, so that if the Redmond datacenter fails, the Dublin datacenter can support a much larger user population.

Использование нескольких групп обеспечения доступности баз данных для обеспечения устойчивости сайтаUsing multiple database availability groups (DAGs) for site resilience

В предыдущем примере одна группа обеспечения доступности располагалась в нескольких центрах данных, обеспечивая отказоустойчивость на уровне сайта для одного или обоих центров данных. При использовании одной группы обеспечения доступности баз данных для поддержания отказоустойчивости на уровне сайта в среде, где каждый центр данных, включенный в эту группу обеспечения доступности, имеет активных пользователей, существует единственная точка сбоя в подключении WAN. Причиной этому служит то, что кворум нуждается в большинстве голосующих членов, которые находятся в работоспособном состоянии и могут поддерживать связь друг с другом.In the preceding example, a single DAG extends across multiple datacenters, providing site resilience for either or both datacenters. When using a single DAG to provide site resilience in an environment where each datacenter to which you extend the DAG has an active user population, there is a single point of failure in the wide area network (WAN) connection. This is because quorum requires a majority of the voters to be active and able to communicate with each other.

В предыдущем примере большинство голосующих членов размещено в центре данных Редмонда. Если центр данных в Дублине содержит активные базы данных почтовых ящиков и поддерживает собственных пользователей, неполадки с подключением WAN может привести к перебою в службе обмена сообщениями для пользователей центра данных в Дублине. При разрыве подключения WAN только члены группы обеспечения доступности баз данных в центре данных Редмонда сохраняют кворум и продолжают предоставлять службу обмена сообщениями.In the preceding example, the majority of voters are located in the Redmond datacenter. If the Dublin datacenter hosts active mailbox databases, and it has a local user population, a WAN outage would result in a messaging service outage for the Dublin users. When WAN connectivity breaks, only the DAG members in the Redmond datacenter retain quorum and continue providing messaging service.

Чтобы подключение WAN не являлось единственной точкой отказа при обеспечении отказоустойчивости на уровне сайта для нескольких центров данных, каждый из которых имеет собственных пользователей, необходимо развернуть несколько групп обеспечения доступности баз данных, чтобы каждая группа имела большинство голосующих членов в отдельном центре данных. При перебое в подключении WAN репликация будет заблокирована до восстановления связи. Пользователи могут использовать службу обмена сообщениями, так как группа обеспечения доступности баз данных продолжает обслуживать местных пользователей.To eliminate the WAN as a single point of failure when you need to provide site resilience for multiple datacenters that each have an active user population, you should deploy multiple DAGs, where each DAG has a majority of voters in a separate datacenter. When a WAN outage occurs, replication will be blocked until connectivity is restored. Users will have messaging service, because each DAG continues to service its local user population.

В началоReturn to top