Высокая доступность и устойчивость сайтовHigh availability and site resilience

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

Можно защитить базы данных почтовых ящиков Exchange Server 2013 и содержащиеся в них данные, настроив для серверов и баз данных почтовых ящиков высокую доступность и устойчивость к сбоям. Exchange 2013 минимизирует стоимость и сложность развертывания решения по обмену сообщениями с функциями высокой доступности и устойчивости к сбоям, а также обеспечивает повышенную доступность данных и служб и поддержку крупных почтовых ящиков.You can protect your Exchange Server 2013 mailbox databases and the data they contain by configuring your Mailbox servers and databases for high availability and site resilience. Exchange 2013 minimizes the cost and complexity of deploying a highly available and resilient messaging solution while providing high levels of service and data availability and support for very large mailboxes.

Exchange 2013 позволяет предприятиям любого размера и в любой отрасли выполнять экономичное развертывание службы непрерывного обмена сообщениями в организации на основе функций репликации и высокодоступной архитектуры в Exchange 2010. Список изменений в Exchange 2010 и Exchange 2007 см. в разделе Изменение высокой доступности и устойчивости сайтов по сравнению с предыдущими версиями.Exchange 2013 enables customers of all sizes and in all segments to economically deploy a messaging continuity service in their organization by building on the native replication capabilities and high availability architecture introduced in Exchange 2010. For a list of changes over Exchange 2010 and Exchange 2007, see Changes to high availability and site resilience over previous versions.

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

Следующие ключевые понятия важно понимать высокой доступности и устойчивости сайта:The following key terms are important to understand high availability or site resilience:

  • Active Manager: внутренний компонент Exchange, который выполняется в службе репликации Microsoft Exchange, ответственный за мониторинг сбоев и корректирующие действия с помощью отработки отказа в группе обеспечения доступности баз данных (DAG).Active Manager: An internal Exchange component which runs inside the Microsoft Exchange Replication service that's responsible for failure monitoring and corrective action through failover within a database availability group (DAG).

  • AutoDatabaseMountDial: параметр свойства сервера почтовых ящиков, который определяет, будет ли пассивная копия базы данных автоматически подключаться в качестве новой активной копии, на основе количества файлов журнала, отсутствующих в смонтированной копии.AutoDatabaseMountDial: A property setting of a Mailbox server that determines whether a passive database copy will automatically mount as the new active copy, based on the number of log files missing by the copy being mounted.

  • Непрерывная репликация режим блокировки: в режиме Block, так как каждое обновление записывается в активный буфер журнала активной копии базы данных, он также передается в буфер журнала на каждой пассивной копии почтовых ящиков в режиме Blocking.Continuous replication - block mode: In block mode, as each update is written to the active database copy's active log buffer, it's also shipped to a log buffer on each of the passive mailbox copies in block mode. После заполнения буфера журнала каждая копия базы данных строит, проверяет и создает следующий файл журнала по порядку номера версии.When the log buffer is full, each database copy builds, inspects, and creates the next log file in the generation sequence.

  • Непрерывная репликация: режимфайлов: в режиме файлов закрытые файлы журнала транзакций перемещаются из активной копии базы данных в одну или несколько пассивных копий базы данных.Continuous replication - file mode: In file mode, closed transaction log files are pushed from the active database copy to one or more passive database copies.

  • Группа доступности базы данных: группа до 16 серверов почтовых ящиков Exchange 2013, в которой размещается набор реплицированных баз данных.Database availability group: A group of up to 16 Exchange 2013 Mailbox servers that hosts a set of replicated databases.

  • Мобильность базы данных: возможность репликации базы данных почтовых ящиков Exchange 2013 и монтирования на других серверах почтовых ящиков Exchange 2013.Database mobility: The ability of an Exchange 2013 mailbox database to be replicated to and mounted on other Exchange 2013 Mailbox servers.

  • Центр обработки данных: обычно это относится к сайту Active Directory; Однако он также может ссылаться на физический сайт.Datacenter: Typically this refers to an Active Directory site; however, it can also refer to a physical site. В контексте этой документации центр обработки данных равен сайту Active Directory.In the context of this documentation, datacenter equals Active Directory site.

  • Режим координации активации центра обработки данных: свойство параметра DAG, которое при включении заставляет службу репликации Microsoft Exchange получать разрешение на подключение баз данных при запуске.Datacenter Activation Coordination mode: A property of the DAG setting that, when enabled, forces the Microsoft Exchange Replication service to acquire permission to mount databases at startup.

  • Аварийное восстановление: любой процесс, используемый для восстановления после сбоя вручную.Disaster recovery: Any process used to manually recover from a failure. Это может быть сбой, затрагивающий как отдельный объект, так и все физическое расположение.This can be a failure that affects a single item, or it can be a failure that affects an entire physical location.

  • API репликации стороннего производителя: API-интерфейс, предоставляемый Exchange, который позволяет использовать сторонние синхронные репликации для группы DAG вместо непрерывной репликации.Exchange third-party replication API: An Exchange-provided API that enables use of third-party synchronous replication for a DAG instead of continuous replication.

  • Высокая доступность: решение, которое обеспечивает доступность служб, доступность данных и автоматическое восстановление после сбоев, влияющих на службу или данные (например, из-за сбоя сети, хранилища или сервера).High availability: A solution that provides service availability, data availability, and automatic recovery from failures that affect the service or data (such as a network, storage, or server failure).

  • Добавочное развертывание: возможность развертывания высокой доступности и устойчивости сайтов после установки Exchange 2013.Incremental deployment: The ability to deploy high availability and site resilience after Exchange 2013 is installed.

  • Копия базы данных почтовых ящиков изолированной: пассивная копия базы данных почтовых ящиков с временем задержки преобразования журнала больше нуля.Lagged mailbox database copy: A passive mailbox database copy that has a log replay lag time greater than zero.

  • Копия базы данныхпочтовых ящиков: база данных почтовых ящиков (EDB-файл и журналы), которая является активной или пассивной.Mailbox database copy: A mailbox database (.edb file and logs), which is either active or passive.

  • Устойчивостьпочтовых ящиков: имя унифицированного решения по обеспечению высокой доступности и устойчивости сайтов в Exchange 2013.Mailbox resiliency: The name of a unified high availability and site resilience solution in Exchange 2013.

  • Управляемая доступность: набор внутренних процессов, состоящих из зондов, мониторов и ответчиков, которые включают мониторинг и высокую доступность для всех ролей сервера и всех протоколов.Managed availability: A set of internal processes made up of probes, monitors, and responders that incorporate monitoring and high availability across all server roles and all protocols.

  • ** *over** (произносится "звездочка над"): Short для переключения и отработки отказа.*over (pronounced "star over"): Short for switchovers and failovers. Переключение представляет собой ручную активацию одной или нескольких копий базы данных.A switchover is a manual activation of one or more database copies. Отработка отказа представляет собой автоматическую активацию одной или нескольких копий базы данных после сбоя.A failover is an automatic activation of one or more database copies after a failure.

  • Сеть безопасности: ранее называлась транспортной корзиной, это функция транспортной службы, в которой хранятся копии всех сообщений в течение X дней.Safety Net: Formerly known as transport dumpster, this is a feature of the transport service that stores a copy of all messages for X days. Значение по умолчанию: 2 дня.The default setting is 2 days.

  • Теневая избыточность: транспортный сервер, обеспечивающий избыточность сообщений для всего времени, когда они находятся в пути.Shadow redundancy: A transport server feature that provides redundancy for messages for the entire time they're in transit.

  • Устойчивость сайта: конфигурация, которая расширяет инфраструктуру обмена сообщениями на несколько сайтов Active Directory для обеспечения непрерывности работы системы обмена сообщениями в случае сбоя, затрагивающих один из сайтов.Site resilience: A configuration that extends the messaging infrastructure to multiple Active Directory sites to provide operational continuity for the messaging system in the event of a failure affecting one of the sites.

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

Группа обеспечения доступности баз данных является базовым компонентом платформы высокой доступности и устойчивости к сбоям, встроенной в Exchange 2013. Группа обеспечения доступности баз данных — это группа серверов почтовых ящиков (до 16 серверов), которые содержат набор баз данных и обеспечивают автоматическое восстановление на уровне базы данных после сбоя, затрагивающего отдельные серверы и базы данных. На любом сервере в группе обеспечения доступности баз данных можно разместить копию базы данных почтовых ящиков с любого другого сервера в группе обеспечения доступности баз данных. Если сервер добавлен в группу обеспечения доступности баз данных, он вместе с другими серверами в этой группе обеспечивает автоматическое восстановление после сбоев, затрагивающих базы данных почтовых ящиков, например сбоев дисков или серверов. Дополнительные сведения о группах обеспечения доступности баз данных см. в разделе Группы обеспечения доступности баз данных.A DAG is the base component of the high availability and site resilience framework built into Exchange 2013. A DAG is a group of up to 16 Mailbox servers that host a set of databases and provides automatic, database-level recovery from failures that affect individual databases, networks, or servers. 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 failure or server failure. For more information about DAGs, see Database availability groups (DAGs).

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

Высокий уровень доступности и устойчивость сайта компонентов, выпущенного в Exchange 2010 используются в Exchange 2013 для создания и поддержания копий баз данных. Exchange 2013 также используется концепция мобильности базы данных, которая является Exchange-управляемый отработки отказов на уровне базы данных.The high availability and site resilience features used first introduced in Exchange 2010 are used in Exchange 2013 to create and maintain database copies. Exchange 2013 also leverages the concept of database mobility, which is Exchange-managed database-level failovers.

Функция мобильности базы данных обеспечивает отключение баз данных от серверов и добавление поддержки до 16 копий одной базы данных. Она также отвечает за взаимодействие при создании копий базы данных.Database mobility disconnects databases from servers and adds support for up to 16 copies of a single database. It also provides a native experience for creating copies of a database.

Настройка копии базы данных в качестве активной базы данных почтовых ящиков называется переключением.Setting a database copy as the active mailbox database is known as a switchover. Ситуация, когда происходит сбой, затрагивающий базу данных, а новая база данных становится активной копией, называется отработкой отказа.When a failure affecting a database or access to a database occurs and a new database becomes the active copy, this process is known as a failover. Этот процесс также затрагивает сбой сервера, при котором один или несколько серверов переводят в оперативный режим базы данных, которые ранее находились на неисправном сервере.This process also refers to a server failure in which one or more servers bring online the databases previously online on the failed server. Когда происходит переключение или отработка отказа, другие роли сервера Exchange 2013 оповещаются об этом практически немедленно и перенаправляют клиентский трафик и трафик обмена сообщениями к новой активной базе данных.When either a switchover or failover occurs, other Exchange 2013 servers become aware of the switchover almost immediately and redirect client and messaging traffic to the new active database.

Например, если происходит сбой активной базы данных в группе обеспечения доступности баз данных из-за сбоя соответствующего хранилища, активный диспетчер выполняет автоматическое восстановление, переходя на копию базы данных на другом сервере почтовых ящиков в группе обеспечения доступности баз данных. В Exchange 2013 управляемая доступность обеспечивает добавление новых реакций на события для восстановления доступа к базе данных по протоколу, в том числе перезапуск рабочих пулов приложений, служб и серверов, а также введение отработки отказов в базах данных.For example, if an active database in a DAG fails because of an underlying storage failure, Active Manager will automatically recover by failing over to a database copy on another Mailbox server in the DAG. In Exchange 2013, managed availability adds new behaviors to recover from loss of protocol access to a database, including recycling application worker pools, restarting services and servers, and initiating database failovers.

Дополнительные сведения о копиях баз данных почтовых ящиков см. в разделе Копии базы данных почтовых ящиков.For more information about mailbox database copies, see Mailbox database copies.

Active ManagerActive Manager

Exchange 2013 использует активный диспетчер, появившийся в Exchange 2010, для управления работоспособностью, состоянием, непрерывной репликацией и другими аспектами баз данных и копий базы данных для обеспечения высокой доступности сервера почтовых ящиков. Дополнительные сведения об активном диспетчере см. в разделе Активный диспетчер.Exchange 2013 leverages the Active Manager component introduced in Exchange 2010 to manage the database and database copy health, status, continuous replication, and other aspects of Mailbox server high availability. For more information about Active Manager, see Active Manager.

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

Хотя в Exchange 2013 и дальше используются группы обеспечения доступности баз данных и отказоустойчивая кластеризация Windows для обеспечения высокой доступности роли сервера почтовых ящиков и устойчивости сайта, устойчивость сайта не одинакова в Exchange 2013. Устойчивость сайта находится гораздо лучше, так как он был в Exchange 2013 упрощенная. Базовые архитектурные изменения, которые были сделаны в Exchange 2013 восстановление значительно повлиять на аспекты конфигурации устойчивости сайтов.Although Exchange 2013 continues to use DAGs and Windows Failover Clustering for Mailbox server role high availability and site resilience, site resilience isn't the same in Exchange 2013. Site resilience is much better in Exchange 2013 because it has been simplified. The underlying architectural changes that were made in Exchange 2013 have significant impact on the recovery aspects of a site resilience configuration.

В Exchange 2010 восстановление серверов почтовых ящиков (группа обеспечения доступности баз данных) и клиентского доступа (массив серверов клиентского доступа) были связаны друг с другом. В случае потери всех серверов клиентского доступа, важного компонента массива или значительной части группы обеспечения доступности баз данных требовалось выполнить переключение центра данных. Это хорошо задокументированный и, как правило, понятный процесс, хотя и занимает много времени, а также требует вмешательства человека для его запуска.In Exchange 2010, mailbox (DAG) and client access (Client Access server array) recovery were tied together. If you lost all of your Client Access servers, the VIP for the array, or a significant portion of your DAG, you were in a situation where you needed to do a datacenter switchover. This is a well-documented and generally well-understood process, although it takes time to perform, and requires human intervention to begin the process.

В Exchange 2013 при потере массива серверов клиентского доступа по каким-либо причинам (например, вследствие сбоя подсистемы балансировки нагрузки) не нужно выполнять переключение центра данных. При правильной настройке переключение происходит на уровне клиента, а клиенты автоматически перенаправляются на второй центр данных с работающими серверами клиентского доступа. Эти серверы клиентского доступа по прокси-соединению передают данные обратно на сервер почтовых ящиков пользователя, на который не повлиял сбой (поскольку не выполняется переключение). Выполняется автоматическое восстановление службы, и пользователь может сосредоточиться на решении основной проблемы (например, замене вышедшей из строя подсистемы балансировки нагрузки).In Exchange 2013, if you lose your Client Access server array for whatever reason (for example, the load balancer fails), you don't need to perform a datacenter switchover. With the proper configuration, failover happens at the client level and clients are automatically redirected to a second datacenter that has operating Client Access servers, and those operating Client Access servers proxy the communication back to the user's Mailbox server, which remains unaffected by the outage (because you don't do a switchover). Instead of working to recover service, the service recovers itself and you can focus on fixing the core issue (for example, replacing the failed load balancer).

Кроме того, благодаря упрощению пространства имен, консолидации ролей сервера, разъединению требований к роли сервера сайта Active Directory, разделению массива серверов клиентского доступа, восстановлению группы обеспечения доступности баз данных и изменению подсистемы балансировки нагрузки в Exchange 2013 внесены изменения, которые обеспечивают раздельное, автоматическое восстановление сервера клиентского доступа и группы обеспечения доступности баз данных на всех сайтах, что делает доступными сценарии отработки отказа центра данных при наличии трех расположений.Furthermore, with the namespace simplification, consolidation of server roles, de-coupling of Active Directory site server role requirements, separation of Client Access server array and DAG recovery, and load balancing changes, there are changes in Exchange 2013 that now enable both Client Access server and DAG recovery to be separate and automatic across sites, thereby providing datacenter failover scenarios, if you have three locations.

В Exchange 2010 можно было развернуть группу обеспечения доступности баз данных в двух центрах обработки данных, в третьем разместить следящий сервер и включить отработку отказа для роли сервера почтовых ящиков в каждом центре обработки данных. При этом отработка отказа не выполнялась для самого решения, поскольку требовалось вручную изменить пространство имен для ролей сервера, отличных от роли сервера почтовых ящиков.In Exchange 2010, you could deploy a DAG across two datacenters and host the witness in a third datacenter and enable failover for the Mailbox server role for either datacenter. But you didn't get failover for the solution itself, because the namespace still needed to be manually changed for the non-Mailbox server roles.

В Exchange 2013 пространство имен не нужно перемещать с группой обеспечения доступности баз данных. отказоустойчивость рычаги Exchange встроенные в пространство имен через несколько IP-адресов, распределения нагрузки (и в случае необходимости, возможность использования серверов и исходящая служба). Современные клиенты HTTP автоматически работают с такой избыточностью. Стек HTTP способен принять несколько IP-адресов для полного доменного имени. При устойчивом отказе первого IP-адреса (то есть невозможности подключения) используется следующий IP-адрес в списке. При "мягком" отказе (потере соединения после установки сеанса, возможно, вследствие прерывистого сбоя службы, например, если устройство сбрасывает пакеты и нуждается в снятии с эксплуатации) может понадобиться обновить браузер.In Exchange 2013, the namespace doesn't need to move with the DAG. Exchange leverages fault tolerance built into the namespace through multiple IP addresses, load balancing (and if need be, the ability to take servers in and out of service). Modern HTTP clients work with this redundancy automatically. The HTTP stack can accept multiple IP addresses for a fully qualified domain name (FQDN), and if the first IP address it tries fails hard (that is, it can't connect), it will try the next IP address in the list. In a soft failure (connection is lost after the session is established, perhaps due to an intermittent failure in the service where, for example, a device is dropping packets and needs to be taken out of service), the user might need to refresh their browser.

Это означает, что пространство имен больше не является единой точкой отказа, как в Exchange 2010. В Exchange 2010, пожалуй, основная критической точки отказа системы обмена сообщениями-это полное доменное имя, которое вы даете пользователям, поскольку это говорит пользователь куда идти. В парадигме Exchange 2010 изменить полное доменное имя для обозначения адресата не так просто, поскольку необходимо изменить DNS, а затем обработать задержки DNS, что иногда является трудной задачей. Кроме того, также в обработке нуждаются кэши имен в браузерах, что обычно занимает около 30 минут или более.This means the namespace is no longer a single point of failure as it was in Exchange 2010. In Exchange 2010, perhaps the biggest single point of failure in the messaging system is the FQDN that you give to users because it tells the user where to go. In the Exchange 2010 paradigm, changing where that FQDN goes isn't easy because you have to change DNS, and then handle DNS latency, which in some parts of the world is challenging. And you have name caches in browsers that are typically about 30 minutes or more that also have to be handled.

Одно из изменений в Exchange 2013 состояло в том, чтобы клиенты имели несколько пунктов назначения. Предположим, что для клиента можно использовать несколько пунктов назначения (в основе почти всех протоколов клиентского доступа в Exchange 2013 лежит HTTP (примеры — Outlook, мобильный Outlook, EAS, EWS, OWA и Центр администрирования Exchange), а все поддерживаемые клиенты HTTP могут использовать несколько IP-адресов), что обеспечивает отработку отказа на стороне клиента. Можно настроить DNS, чтобы рука нескольких IP-адресов на клиенте во время разрешения имен. Клиент запрашивает почту Contoso.com и вернется. два IP-адреса, или четырех IP-адресов, например. Однако клиент получает много IP-адресов будет надежно использоваться назад клиенту. Это значительно улучшает возможности клиента, поскольку при сбое одного IP-адреса клиент может выполнить попытку подключения по другим адресам. При сбое одного из адресов клиент ожидает в течение 20 секунд, а затем выполняет попытку подключения по следующему адресу в списке. Таким образом, при потере важного компонента массива серверов клиентского доступа в течение около 21 секунды выполняется автоматическое восстановление клиентов.One of the changes in Exchange 2013 is to enable clients to have more than one place to go. Assuming the client has the ability to use more than one place to go (almost all the client access protocols in Exchange 2013 are HTTP based (examples include Outlook, Outlook Anywhere, EAS, EWS, OWA, and EAC), and all supported HTTP clients have the ability to use multiple IP addresses), thereby providing failover on the client side. You can configure DNS to hand multiple IP addresses to a client during name resolution. The client asks for mail.contoso.com and gets back two IP addresses, or four IP addresses, for example. However many IP addresses the client gets back will be used reliably by the client. This makes the client a lot better off because if one of the IP addresses fails, the client has one or more other IP addresses to try to connect to. If a client tries one and it fails, it waits about 20 seconds and then tries the next one in the list. Thus, if you lose the VIP for the Client Access server array, recovery for the clients happens automatically, and in about 21 seconds.

Ниже перечислены связанные с этим преимущества.The benefits include the following:

  • В Exchange 2010 при потере подсистемы балансировки нагрузки в главном центре обработки данных (и при этом на данном сайте отсутствовала другая подсистема) приходилось выполнять переключение центра обработки данных. В Exchange 2013 при потере подсистемы балансировки нагрузки на главном сайте ее (или, возможно, важный компонент) просто необходимо отключить, а затем отремонтировать или заменить. В клиентах, в которых уже не используется важный компонент в дополнительном центре обработки данных, будет выполнена автоматическая отработка отказа на дополнительный важный компонент без изменения пространства имен и DNS. Благодаря этому не только отпадает необходимость в переключении, но и экономится время, которое обычно тратится на переключение центра обработки данных. В Exchange 2010 приходилось обрабатывать задержку DNS (поэтому рекомендовалось установить срок жизни (TTL) в 5 минут, а также ввести URL-адрес для обработки отказа). В Exchange 2013 эти операции не требуются благодаря быстрой обработке отказа (20 секунд) пространства имен между важными компонентами (центрами обработки данных).In Exchange 2010, if you lose the load balancer in your primary datacenter and you don't have another one in that site, you had to do a datacenter switchover. In Exchange 2013, if you lose the load balancer in your primary site, you simply turn it off (or maybe turn off the VIP) and repair or replace it. Clients that aren't already using the VIP in the secondary datacenter will automatically fail over to the secondary VIP without any change of namespace, and without any change in DNS. Not only does that mean you no longer have to perform a switchover, but it also means that all of the time normally associated with a datacenter switchover recovery isn't spent. In Exchange 2010, you had to handle DNS latency (hence, the recommendation to set the Time to Live (TTL) to 5 minutes, and the introduction of the failback URL). In Exchange 2013, you don't need to do that because you get fast failover (20 seconds) of the namespace between VIPs (datacenters).

  • Благодаря быстрой обработке пространства имен между центрами обработки данных все, что требуется для обработки отказа центра обработки данных, — механизм обработки отказа роли сервера почтовых ящиков в центрах обработки данных. Для автоматической обработки отказа для группы обеспечения доступности баз данных необходимо просто разработать решение, при котором группа равномерно распределяется между двумя центрами обработки данных, а затем разместить следящий сервер в третьем расположении для его арбитража членами группы обеспечения доступности баз данных в каждом центре обработки данных (вне зависимости от состояния сети между центрами обработки данных с членами этой группы). Если при наличии только двух центров обработки данных третье физическое расположение недоступно, можно разместить следящий сервер на виртуальной машине Microsoft Azure. Дополнительные сведения см. в разделе Использование виртуальной машины Microsoft Azure в качестве следящего сервера DAG.Because you can fail over the namespace between datacenters, all that's needed to achieve a datacenter failover is a mechanism for failover of the Mailbox server role across datacenters. To get automatic failover for the DAG, you simply architect a solution where the DAG is evenly split between two datacenters, and then place the witness server in a third location so that it can be arbitrated by DAG members in either datacenter, regardless of the state of the network between the datacenters that contain the DAG members. If you only have two datacenters and a third physical location isn't available, you can place the witness server on a Microsoft Azure virtual machine. See Using a Microsoft Azure VM as a DAG witness server for more information.

  • В этом сценарии администратор пытается просто решить проблему, а не восстановить службу. При этом просто ошибка просто исправляется; служба продолжает работать, и сохраняется целостность данных. При восстановлении службы вы ощущаете намного меньшие стресс и нехватку времени, чем при ремонте неисправного устройства. Работа пользователя и администратора значительно упрощается.In this scenario, the administrator's efforts are geared toward simply fixing the problem, and not spent restoring service. You simply fix the thing that failed; while service has been running and data integrity has been maintained. The urgency and stress level you feel when fixing a broken device is nothing like the urgency and stress you feel when you're working to restore service. It's better for the end user, and less stressful for the administrator.

Вы можете разрешить выполнение отработки отказа без необходимости обратного подключения (иногда ошибочно зовется восстановлением размещения). Если вы потеряете серверы клиентского доступа в главном центре обработки данных, что приведет к 20-секундному перерыву в работе клиентов, можно даже не заботиться о восстановлении после сбоя. На данный момент основная задача состоит в решении ключевой проблемы (например, замене вышедшей из строя подсистемы балансировки нагрузки). После того как она подключится к сети и продолжит работу, одни клиенты начнут ее использование, а другие будут функционировать через второй центр обработки данных.You can allow failover to occur without having to perform switchbacks (sometimes mistakenly referred to as failbacks). If you lose Client Access servers in your primary datacenter and that results in a 20 second interruption for clients, you might not even care about failing back. At this point, your primary concern would be fixing the core issue (for example, replacing the failed load balancer). After it's back online and functioning, some clients will start using it, and other clients might remain operational through the second datacenter.

Exchange 2013 также обеспечивает функциональность, позволяет администраторам разобраться с периодическим сбоям. Прерывистый сбой происходит, если, например, ничего не происходит после установки начального TCP-соединения. Непредвиденный сбой требует некоторой дополнительной административные взыскания, так как это может быть в результате ввода в эксплуатацию нового устройства. В ходе восстановления устройство может быть включено и принимать некоторые запросы, но оно фактически не готово к обслуживанию клиентов, пока не будут выполнены необходимые действия по настройке. В этом сценарии, администратор может выполнять пространства имен, просто удалив VIP переключение для заменяемого устройства от DNS. Затем в течение этого периода, нет клиентов будут пытаться подключиться к нему. После замены администратор может добавить важный компонент обратно в DNS, а клиенты в конечном итоге начнут использовать его.Exchange 2013 also provides functionality that enables administrators to deal with intermittent failures. An intermittent failure is where, for example, the initial TCP connection can be made, but nothing happens afterward. An intermittent failure requires some sort of extra administrative action to be taken because it might be the result of a replacement device being put into service. While this repair process is occurring, the device might be powered on and accepting some requests, but not really ready to service clients until the necessary configuration steps are performed. In this scenario, the administrator can perform a namespace switchover by simply removing the VIP for the device being replaced from DNS. Then during that service period, no clients will be trying to connect to it. After the replacement process has completed, the administrator can add the VIP back to DNS, and clients will eventually start using it.

Дополнительные сведения о планировании и развертывании см. в разделе Планирование высокой доступности и устойчивости сайтов или Развертывание с высоким уровнем доступности и устойчивости сайта.For details about planning and deploying site resilience, see Planning for high availability and site resilience and Deploying high availability and site resilience.

сторонний интерфейс API репликацииThird-party replication API

Система Exchange 2013 также включает в себя новый сторонний интерфейс API репликации, позволяющий организациям использовать сторонние решения по синхронной репликации вместо функции встроенной непрерывной репликации. Корпорация Майкрософт поддерживает решения сторонних производителей, использующие этот интерфейс API, если решение содержит необходимые функции, заменяющие все встроенные функции непрерывной репликации, которые отключены из-за использования интерфейса API. Поддержка решений обеспечивается, только когда интерфейс API используется в группе обеспечения доступности баз данных для управления и активации копий базы данных почтовых ящиков. Использование интерфейса API для других целей не поддерживается. Кроме того, решение должно удовлетворять соответствующие требования к поддержке оборудования Windows. (Для поддержки не требуется тестовая проверка)Exchange 2013 also includes a third-party replication API that enables organizations to use third-party synchronous replication solutions instead of the built-in continuous replication feature. Microsoft supports third-party solutions that use this API, provided that the solution provides the necessary functionality to replace all native continuous replication functionality that's disabled as a result of using the API. Solutions are supported only when the API is used within a DAG to manage and activate mailbox database copies. Use of the API outside of these boundaries isn't supported. In addition, the solution must meet the applicable Windows hardware support requirements. (Test validation isn't required for support.)

При развертывании решения, использующего встроенный API репликации от сторонних производителей, учтите, что поставщик этого решения несет ответственность за основную его поддержку. Корпорация Майкрософт поддерживает данные Exchange для решений с репликацией и без нее. Решения, использующие репликацию данных, должны соответствовать политике Майкрософт, касающейся поддержки репликации данных. Эта политика указана в статье Поддержка репликации данных в нескольких сайтах для Exchange Server (статье 895847 из базы знаний Майкрософт). Кроме того, решения, использующие модель ресурсов Windows Failover Cluster, должны отвечать требованиям, касающимся поддержки кластеров Windows. Эти требования можно найти в статье 943984 из базы знаний Майкрософт, Политика Майкрософт в отношении поддержки отказоустойчивых кластеров для Windows Server 2008 и Windows Server 2008 R2 или Политика Майкрософт в отношении поддержки отказоустойчивых кластеров для Windows Server 2012.When deploying a solution that uses the built-in third-party replication API, be aware that the solution vendor is responsible for primary support of the solution. Microsoft supports Exchange data for both replicated and non-replicated solutions. Solutions that use data replication must adhere to the Microsoft support policy for data replication, as described in Microsoft Knowledge Base article 895847, Multi-site data replication support for Exchange Server. In addition, solutions that utilize the Windows Failover Cluster resource model must meet Windows cluster supportability requirements as described in Microsoft Knowledge Base article 943984, The Microsoft Support Policy for Windows Server 2008 or Windows Server 2008 R2 Failover Clusters or The Microsoft Support Policy for Windows Server 2012 Failover Clusters.

Политика Майкрософт в области поддержки резервного копирования и восстановления для развертываний, использующих решения по репликации на основе интерфейсов API сторонних производителей, аналогична политике для развертываний со встроенной непрерывной репликацией.Microsoft's backup and restore support policy for deployments that use third-party replication API-based solutions is the same as for native continuous replication deployments.

Партнеры корпорации Майкрософт могут получить сведения о стороннем интерфейсе API в любом местном представительстве.If you're a partner seeking information about the third-party API, contact your Microsoft representative.

Документация высоким уровнем доступности и устойчивости сайтаHigh availability and site resilience documentation

В следующей таблице приведены ссылки на разделы, помогающие ознакомиться и управлять группами доступности баз данных, копии баз данных почтовых ящиков, и для резервного копирования и восстановления для Exchange 2013.The following table contains links to topics that will help you learn about and manage DAGs, mailbox database copies, and backup and restore for Exchange 2013.

СтатьяTopic ОписаниеDescription

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

Сведения о группах DAG, активном диспетчере, режиме DAC и копиях базы данных почтовых ящиков.Learn about DAGs, Active Manager, Datacenter Activation Coordination (DAC) mode, and mailbox database copies.

Планирование высокой доступности и устойчивости сайтовPlanning for high availability and site resilience

Сведения об общих требованиях, включая требования к оборудованию, сети, программному обеспечению, следящему серверу и другим компонентам, а также рекомендации для групп обеспечения доступности баз данных.Learn about the general, hardware, network, software, witness server, and other requirements and best practices for DAGs.

Развертывание с высоким уровнем доступности и устойчивости сайтаDeploying high availability and site resilience

Исследовать пример сценария развертывания для развертывания и настройки групп DAG.Explore an example deployment scenario for deploying and configuring DAGs.

Управление высокой доступностью и устойчивостью сайтовManaging high availability and site resilience

Подробнее о задачах управления DAG, переключениями и отработками отказа, и режим обслуживания.Learn about DAG management tasks, switchovers and failovers, and maintenance mode.

Наблюдение за группами обеспечения доступности баз данныхMonitoring database availability groups

Описание встроенных командлетов и сценариев для группы доступности базы данных и копии базы данных наблюдения.Learn about the built-in cmdlets and scripts for monitoring DAGs and database copies.

Резервное копирование, восстановление и аварийное восстановлениеBackup, restore, and disaster recovery

Сведения о резервном копировании и восстановлении баз данных Exchange, восстановления базы данных, и восстановления серверов.Learn about backing up and restoring Exchange databases, recovery databases, and server recovery.