Изменение высокой доступности и устойчивости сайтов по сравнению с предыдущими версиямиChanges to high availability and site resilience over previous versions

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

В Exchange 2013 для обеспечения высокой доступности, устойчивости к сбоям, а также реализации собственной системы защиты данных Exchange используются группы обеспечения доступности баз данных и копии баз данных почтовых ящиков, а также другие функции, такие как восстановление отдельных элементов, политики хранения и копии баз данных с задержкой. Платформа высокой доступности, банк данных Exchange и расширенный обработчик хранилищ (ESE) усовершенствованы, чтобы повысить доступность, упростить управление и сократить издержки. Эти усовершенствования включают в себя:Exchange 2013 uses DAGs and mailbox database copies, along with other features such as single item recovery, retention policies, and lagged database copies, to provide high availability, site resilience, and Exchange native data protection. The high availability platform, Exchange Information Store and Extensible Storage Engine (ESE) have all been enhanced to provide greater availability and easier management, and to reduce costs. These enhancements include:

  • Сокращение количества операций ввода-вывода в секунду в Exchange 2010: Это позволяет использовать большие диски в терминах емкости и операций ввода-вывода, как можно быстрее.Reduction in IOPS over Exchange 2010: This enables you to leverage larger disks in terms of capacity and IOPS as efficiently as possible.

  • Управляемая доступность: с управляемой доступностью, внутренние функции мониторинга и восстановления тесно интегрированы для предотвращения сбоев, профилактического восстановления служб и автоматического запуска отработки отказа сервера или оповещения Администраторы для выполнения действий.Managed availability: With managed availability, internal monitoring and recovery-oriented features are tightly integrated to help prevent failures, proactively restore services, and initiate server failovers automatically or alert administrators to take action. Основное внимание уделяется мониторингу и управлению взаимодействием с пользователями, а не только отслеживанию времени работы серверов и компонентов для поддержания непрерывной доступности системы.The focus is on monitoring and managing the end-user experience rather than just server and component uptime to help keep the service continuously available.

  • Управляемое хранилище: управляемое хранилище — это имя Недавно перезаписанных процессов банка данных в Exchange 2013.Managed Store: The Managed Store is the name of the newly rewritten Information Store processes in Exchange 2013. Новое управляемое хранилище написано в C# и тесно интегрировано со службой репликации Microsoft Exchange (MSExchangeRepl. exe), чтобы обеспечить более высокую доступность с помощью улучшенной устойчивости.The new Managed Store is written in C# and tightly integrated with the Microsoft Exchange Replication service (MSExchangeRepl.exe) to provide higher availability through improved resiliency.

  • Поддержка нескольких баз данных на каждом диске: Exchange 2013 включает в себя дополнительные возможности, позволяющие поддерживать несколько баз данных (смесь активных и пассивных копий) на одном диске, что позволяет использовать большие диски в терминах емкости и операций ввода-вывода в качестве максимально эффективно.Support for multiple databases per disk: Exchange 2013 includes enhancements that enable you to support multiple databases (mixtures of active and passive copies) on the same disk, thereby leveraging larger disks in terms of capacity and IOPS as efficiently as possible.

  • AutoReseed: функция автоматического повторного заполнения позволяет быстро восстановить избыточность базы данных после сбоя диска.AutoReseed: Automatic reseeding capability enables you to quickly restore database redundancy after disk failure. В случае сбоя диска копия базы данных, сохраненная на диске, копируется из активной копии базы данных на резервный диск того же самого сервера.If a disk fails, the database copy stored on that disk is copied from the active database copy to a spare disk on the same server. Если на отказавшем диске хранилось несколько копий баз данных, их можно автоматически повторно заполнить на свободном диске.If multiple database copies were stored on the failed disk, they can all be automatically reseeded on a spare disk. Это ускоряет повторное заполнение, так как активные базы данных, скорее всего, располагаются на нескольких серверах и данные копируются параллельно.This enables faster reseeds, as the active databases are likely to be on multiple servers and the data is copied in parallel.

  • Автоматическое восстановление после сбоев хранилища: Эта функция продолжает инновации, описанные в Exchange 2010, что позволяет системе восстанавливаться после сбоев, влияющих на устойчивость и избыточность.Automatic recovery from storage failures: This feature continues the innovation introduced in Exchange 2010 to allow the system to recover from failures that affect resiliency or redundancy. Помимо реакций на события отладки Exchange 2010, в Exchange 2013 также входят дополнительные функции восстановления при длительном времени ввода-вывода, чрезмерном потреблении памяти программой MSExchangeRepl.exe, а также при тяжелых случаях, когда система находится в таком плохом состоянии, что не удается запланировать выполнение потоков.In addition to the Exchange 2010 bugcheck behaviors, Exchange 2013 includes additional recovery behaviors for long I/O times, excessive memory consumption by MSExchangeRepl.exe, and severe cases where the system is in such a bad state that threads can't be scheduled.

  • Усовершенствованные возможности копирования изолированной: изолированной копии теперь могут подключаться к определенным экстентам с помощью автоматического воспроизведения журнала.Lagged copy enhancements: Lagged copies can now care for themselves to a certain extent using automatic log play down. Отстающие копии автоматически дополняются по файлам журналов в ряде ситуаций, например при исправлении страниц или нехватке места на диске.Lagged copies will automatically play down log files in a variety of situations, such as page patching and low disk space scenarios. Если система обнаружит необходимость в исправлении страниц у отстающей копии, в отстающей копии автоматически воспроизводятся журналы, что и позволяет исправить страницы.If the system detects that page patching is required for a lagged copy, the logs will be automatically replayed into the lagged copy to perform page patching. Отстающие копии также используют это автоматическое воспроизведение при достижении нижнего порога доступного дискового пространства или обнаружении того, что эта копия является единственной доступной копией в течение определенного времени.Lagged copies will also invoke this auto replay feature when a low disk space threshold has been reached, and when the lagged copy has been detected as the only available copy for a specific period of time. Кроме того, отстающие копии могут использовать систему безопасности, что существенно упрощает восстановление и активацию.In addition, lagged copies can leverage Safety Net, making recovery or activation much easier.

  • Улучшение оповещений одной копии: одно оповещение о копии, появившиеся в Exchange 2010, больше не является отдельным запланированным сценарием.Single copy alert enhancements: The single copy alert introduced in Exchange 2010 is no longer a separate scheduled script. Теперь оно интегрируется с компонентами управляемой доступности системы и входит в состав Exchange.It's now integrated into the managed availability components within the system and is a native function within Exchange.

  • Автоматическая настройка сети DAG: сети DAG могут автоматически настраиваться системой на основе параметров конфигурации.DAG network auto-configuration: DAG networks can be automatically configured by the system based on configuration settings. Помимо вариантов ручной настройки, группы обеспечения доступности баз данных могут различать сети MAPI и сети репликации, а также автоматически настраивать сети групп.In addition to manual configuration options, DAGs can also distinguish between MAPI and replication networks and configure DAG networks automatically.

Снижение IOPS на Exchange 2010Reduction in IOPS over Exchange 2010

В Exchange 2010 пассивные копии базы данных имеют чрезвычайно низкую глубину контрольных точек, которая необходима для быстрой отработки отказа. Кроме того, пассивная копия выполняет агрессивное предварительное чтение данных, чтобы справиться с глубиной контрольных точек в 5 МБ. В результате при использовании низкой глубины контрольных точек и выполнении этих агрессивных операций предварительного чтения количество операций ввода-вывода в секунду для пассивной копии базы данных равнялось значению для активной копии в Exchange 2010.In Exchange 2010, passive database copies have a very low checkpoint depth, which is required for fast failover. In addition, the passive copy performs aggressive pre-reading of data to keep up with a 5-megabyte (MB) checkpoint depth. As a result of using a low checkpoint depth and performing these aggressive pre-read operations, IOPS for a passive database copy was equal to IOPS for an active copy in Exchange 2010.

В Exchange 2013, система способна предоставить быструю обработку ситуаций отказа при использовании большой глубины контрольной точки для пассивной (100 Мбайт). Поскольку пассивные копии имеют глубину контрольных точек 100 МБ, они повторно настроены на менее агрессивное выполнение операций. В результате при увеличении глубины контрольных точек и повторной настройки агрессивных операций предварительного считывания количество операций ввода-вывода в секунду для пассивной копии составляет около 50 % от этого значения для активной копии Exchange 2013.In Exchange 2013, the system is able to provide fast failover while using a high checkpoint depth on the passive copy (100 MB). Because passive copies have 100-MB checkpoint depth, they've been de-tuned to no longer be so aggressive. As a result of increasing the checkpoint depth and de-tuning the aggressive pre-reads, IOPS for a passive copy is about 50 percent of the active copy IOPS in Exchange 2013.

Наличие более высокой глубины контрольных точек для пассивной копии также приводит к другим изменениям. В переключаемых в Exchange 2010, кэш очищается база данных, в которой содержится база данных преобразуется из пассивной копии на активную копию. В Exchange 2013, ведение журнала ESE, чтобы кэш был переписанный заносится через переход от пассивного к активному. Поскольку подсистеме ESE не нужно очищать кэш, выполняется быстрая отработка отказа.Having a higher checkpoint depth on the passive copy also results in other changes. On failover in Exchange 2010, the database cache is flushed as the database is converted from a passive copy to an active copy. In Exchange 2013, ESE logging was rewritten so that the cache is persisted through the transition from passive to active. Because ESE doesn't need to flush the cache, you get fast failover.

Было внесено еще одно изменение, относящееся к процессу фонового обслуживания баз данных (BDM). BDM теперь обрабатывает около 1-2 МБ в секунду для каждой копии.One other change was made to the background database maintenance (BDM) process. BDM now processes around 1-2 MB per second per copy.

В результате всех этих изменений Exchange 2013 обеспечивает существенное сокращение количества операций ввода-вывода по сравнению с Exchange 2010.As a result of these changes, Exchange 2013 provides a significant reduction in IOPS over Exchange 2010.

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

Управляемая доступность — это интеграция встроенного активного мониторинга и платформы высокой доступности Exchange 2013. Благодаря управляемой доступности система может определить время для отработки отказа базы данных на основе работоспособности службы. Управляемая доступность — это внутренняя инфраструктура, развернутая в ролях серверов клиентского доступа и почтовых ящиков в Exchange 2013. Управляемая доступность состоит из трех основных асинхронных компонентов, которые постоянно работают. Первый компонент — это механизм проверки, ответственный за выполнение измерений на сервере и сбор данных. Результаты этих измерений поступают во второй компонент — монитор. Монитор содержит всю используемую системой бизнес-логику на основе того, что считается работоспособным состоянием собранных данных. Подобно подсистеме распознавания шаблонов, монитор ищет различные шаблоны среди всех собранных измерений, а затем принимает решение, можно ли считать компонент работоспособным. Наконец, существует подсистема ответа, которая несет ответственность за действия по восстановлению. Если что-то не работает, первое действие — попытка восстановления соответствующего компонента. Это могут быть действия по многоуровневому восстановлению (например, сначала последовательно перезапускаются пул приложений, служба и сервер, а в самом конце сервер переводится в автономный режим и не может принимать трафик). Если действия по восстановлению не помогают, система уведомляет о проблеме оператора-человека через журнал.Managed Availability is the integration of built-in, active monitoring and the Exchange 2013 high availability platform. With Managed Availability, the system can make a determination on when to fail over a database based on service health. Managed Availability is an internal infrastructure that's deployed on the Client Access and Mailbox server roles in Exchange 2013. Managed Availability includes three main asynchronous components that are constantly doing work. The first component is the probe engine, which is responsible for taking measurements on the server and collecting data. The results of those measurements flow into the second component, the monitor. The monitor contains all of the business logic used by the system based on what is considered healthy on the data collected. Similar to a pattern recognition engine, the monitor looks for the various different patterns on all the collected measurements, and then it decides whether something is considered healthy. Finally, there is the responder engine, which is responsible for recovery actions. When something is unhealthy, the first action is to attempt to recover that component. This could include multi-stage recovery actions; for example, the first attempt may be to restart the application pool, the second may be to restart the service, the third attempt may be to restart the server, and the subsequent attempt may be to take the server offline so that it no longer accepts traffic. If the recovery actions are unsuccessful, the system escalates the issue to a human through event log notifications.

Управляемая доступность реализуется в форме две службы:Managed availability is implemented in the form of two services:

  • Служба диспетчера работоспособности Exchange (мсексчанжехмхост. exe): этот процесс контроллера используется для управления рабочими процессами.Exchange Health Manager Service (MSExchangeHMHost.exe): This is a controller process that's used to manage worker processes. Он используется для построения, выполнения, запуска и остановки рабочих процессов по мере необходимости.It's used to build, execute, and start and stop the worker process as needed. Он также используется для восстановления рабочих процессов при сбоях, чтобы рабочие процессы не становились единственной точкой отказа.It's also used to recover the worker process in case that process crashes, to prevent the worker process from being a single point of failure.

  • Рабочий процесс диспетчера работоспособности Exchange (MSExchangeHMWorker. exe): это рабочий процесс, отвечающий за выполнение задач среды выполнения.Exchange Health Manager Worker process (MSExchangeHMWorker.exe): This is the worker process that's responsible for performing the runtime tasks.

Управляемая доступность использует постоянное хранилище для выполнения своих функций:Managed availability uses persistent storage to perform its functions:

  • XML-файл конфигурации используются для инициализации определений рабочих элементов при запуске рабочего процесса.XML configuration files are used to initialize the work item definitions during startup of the worker process.

  • Реестр используется для хранения данных среды выполнения, например закладок.The registry is used to store runtime data, such as bookmarks.

  • Инфраструктура журнала событий канала Crimson используется для хранения результатов рабочих элементов.The crimson channel event log infrastructure is used to store the work item results.

Дополнительные сведения о высоком уровне доступности см. в разделе Управляемая доступность.For more information about managed availability, see Managed Availability.

Управляемое хранилищеManaged Store

Все предыдущие версии Exchange Server, от Exchange Server 4.0 до Exchange Server 2010, поддерживали запуск единого экземпляра процесса хранилища данных (Store.exe) на роли сервера почтовых ящиков. В этом едином хранилище размещены все базы данных на сервере: активные, пассивные, изолированные и базы данных восстановления. В предыдущих архитектурах Exchange существует незначительная изоляция между различными базами данных, размещенными на сервере почтовых ящиков. Проблемы с единой базой данных почтовых ящиков могут негативно сказаться на всех остальных базах данных, а аварийное завершение в результате повреждения почтового ящика может повлиять на работу служб для всех пользователей, базы данных которых размещены на таком сервере.All previous versions of Exchange Server, from Exchange Server 4.0 to Exchange Server 2010, have supported running a single instance of the Information Store process (Store.exe) on the Mailbox server role. This single Store instance hosts all databases on the server: active, passive, lagged, and recovery. In the previous Exchange architectures, there is little, if any, isolation between the different databases hosted on a Mailbox server. An issue with a single mailbox database has the potential to negatively affect all other databases, and crashes resulting from a mailbox corruption can affect service for all users whose databases are hosted on that server.

Еще одна трудность при использовании единого экземпляра хранилища в предыдущих версиях Exchange состоит в том, что расширенный обработчик хранилищ (ESE) хорошо масштабируется для 8-12 процессорных ядер, а кроме этого взаимодействие между процессорами и проблемы синхронизации кэша могут привести к отрицательному масштабированию. В условиях использования современных серверов с системами с 16 и большим числом ядер это усложняет администрирование, ведь придется управлять сходством 8-12 ядер для ESE, а остальные ядра использовать для процессов, не связанных с хранилищем (например, для помощников, платформ поиска, управляемой доступности и т. п.). Кроме того, предыдущая архитектура ограничивала увеличение масштаба для процессов хранилища.Another challenge with a single Store instance in previous versions of Exchange is that the Extensible Storage Engine (ESE) scales well to 8-12 processor cores, but beyond that, cross-processor communication and cache synchronization issues lead to negative scale. Given today's much larger servers, with 16+ core systems available, this would mean impose the administrative challenge of managing the affinity of 8-12 cores for ESE and using the other cores for non-Store processes (for example, Assistants, Search Foundation, Managed Availability, etc.). Moreover, the previous architecture restricted scale-up for the Store process.

За многие годы процесс Store.exe был значительно усовершенствован, как и Exchange Server, но в конечном итоге его масштабируемость как одного процесса ограничена и представляет единственную точку отказа. Из-за этих ограничений в Exchange 2013 процесс Store.exe заменен на управляемое хранилище.The Store.exe process has evolved considerably throughout the years as Exchange Server itself evolved, but as a single process, ultimately its scalability is limited, and it represents a single point of failure. Because of these limits, Store.exe is gone in Exchange 2013 and replaced by the Managed Store.

Дополнительные сведения см. в разделе Управляемое хранилище.For more information, see Managed Store.

Несколько баз данных на томMultiple databases per volume

Хотя улучшения системы хранения в Exchange 2013 в основном предназначены только для конфигураций групп дисков (JBOD), они доступны для использования во всех поддерживаемых конфигурациях хранилища. Одной из таких функций является возможность размещения нескольких баз данных на одном и том же томе. Эта функция предназначена для больших дисков о Exchange оптимизация. Эти улучшения позволяют использовать большие диски по емкости с гораздо большей эффективностью в показателях емкости, количества операций ввода-вывода в секунду и времени повторного заполнения, а также призваны устранить следующие проблемы, связанные с выполнением задач в конфигурации хранилища JBOD.Although the storage improvements in Exchange 2013 are designed primarily for just a bunch of disks (JBOD) configurations, they're available for use by all supported storage configurations. One such feature is the ability to host multiple databases on the same volume. This feature is about Exchange optimizing for large disks. These optimizations result in a much more efficient use of large disks in terms of capacity, IOPS, and reseed times, and they're meant to address the challenges associated with running in a JBOD storage configuration:

  • Необходимость управления размерами баз данных.Database sizes must be manageable.

  • Операции повторного заполнения должны быть быстрыми и надежными.Reseed operations must be fast and reliable.

  • Хотя емкость хранилища увеличивается, количество операций ввода-вывода в секунду не растет.Although storage capacity is increasing, IOPS aren't.

  • Диски, на которых размещены пассивные копии базы данных, используются недостаточно эффективно в показателях количества операций ввода-вывода в секунду.Disks hosting passive database copies are underutilized in terms of IOPS.

  • Изолированные копии имеют асимметричные требования к хранилищу.Lagged copies have asymmetric storage requirements.

  • Гибкость ограничивается для восстановления в условиях нехватки места на диске.Limited agility exists to recover from low disk space conditions.

Продолжается тенденция увеличения емкости хранилища: скоро в продаже появятся диски на 8 ТБ. Согласно рекомендациям по максимальному размеру данных Exchange (2 ТБ), при использовании дисков на 8 ТБ теряется более 5 ТБ дискового пространства. Одно из решений — просто увеличить размер баз данных, но это чревато ухудшением их управляемости, поскольку возрастает время повторного заполнения, в том числе (в некоторых случаях) неуправляемое, а также снижается надежность копирования данных по сети.The trend of increasing storage capacity is continuing, with 8-terabyte drives expected to be available soon. When using 8-terabyte drives in conjunction with the Exchange maximum database size best practices guidelines (2 terabytes), you would waste more than 5 terabytes of disk space. One solution would be to simply grow the databases larger, but that inhibits manageability because it introduces long reseed times, including in some cases, operationally unmanageable reseed times, and the reliability of copying that amount of data over the network is compromised.

Кроме того, в модели Exchange 2010 диск, на котором хранится пассивная копия, используется не в полной мере в плане количества операций ввода-вывода в секунду. В случае с изолированной пассивной копией, диск не только используется недостаточно эффективно с точки зрения количества операций ввода-вывода в секунду, но и является асимметричным в плане размера относительно дисков, используемых для хранения активных и неизолированных пассивных копий.In addition, in the Exchange 2010 model, the disk storing a passive copy is underutilized in terms of IOPS. In the case of a lagged passive copy, not only is the disk underutilized in terms of IOPS, but it's also asymmetric in terms of its size, relative to the disks used to store the active and non-lagged passive copies.

Продолжая давнюю практику, мы оптимизировали Exchange 2013, что позволяет более эффективно использовать большие диски (8 ТБ) в конфигурации JBOD. Поскольку в Exchange 2013 на одном диске хранится несколько баз данных, на дисках одного размера можно хранить несколько (в том числе изолированных) копий баз данных. Цель состоит в том, чтобы максимально способствовать распределению пользователей по существующим томам и обеспечить симметричный дизайн, при котором во время обычных операций в каждом члене группы обеспечения доступности баз данных размещается ряд активных, пассивных и дополнительных изолированных копий в одном томе.Continuing a long-standing practice, Exchange 2013 is optimized so that it can use large disks (8 terabytes) in a JBOD configuration more efficiently. In Exchange 2013, with multiple databases per disk, you can have the same size disks storing multiple database copies, including lagged copies. The goal is to drive the distribution of users across the number of volumes that exist, providing you with a symmetric design where during normal operations each DAG member hosts a combination of active, passive, and optional lagged copies on the same volumes.

Пример конфигурации, в которой используется несколько баз данных на томе представлен ниже.An example of a configuration that uses multiple databases per volume is illustrated below.

Конфигурация, в которой используется несколько баз данных на томConfiguration that uses multiple databases per volume

![Несколько баз данных на том] (images/Dn789066.c5e7d6c8-3e77-4f72-a873-5e9aaded9aa3(EXCHG.150).gif "Несколько баз данных на том")Multiple databases per volume

Приведенная выше конфигурация обеспечивает симметричный дизайн. Все четыре базы данных четырех серверах установлены одинаковые все размещены на одном диске на каждый сервер. Ключевой момент — количество копий каждой имеющейся базы данных равно числу копий базы данных на диск. В приведенном выше примере существует четыре копии каждой базы данных: одна активная копия и две пассивных копии, одной изолированной копии. Поскольку каждая база данных имеет четыре копии, правильной считается конфигурация с четырьмя копиями на том. Кроме того, приоритет активации сбалансирован в группе обеспечения доступности баз данных и на каждом сервере. Например, активная, первая пассивная, вторая пассивная и изолированная копии будут иметь значение приоритета активации 1, 2, 3 и 4 соответственно.The above configuration provides a symmetrical design. All four servers have the same four databases all hosted on a single disk per server. The key is that the number of copies of each database that you have should be equal to the number of database copies per disk. In the above example, there are four copies of each database: one active copy, two passive copies, and one lagged copy. Because there are four copies of each database, the proper configuration is one that has four copies per volume. In addition, activation preference is configured so that it's balanced across the DAG and across each server. For example, the active copy will have an activation preference value of 1, the first passive copy will have an activation preference value of 2, the second passive copy will have an activation preference value of 3, and the lagged copy will have an activation preference value of 4.

Помимо более равномерного распределения существующих томов для пользователей, другим преимуществом использования нескольких баз данных на одном диске является то, что при этом снижается срок восстановления защиты данных в случае сбоя, который требует повторного заполнения (например, из-за сбоя диска).In addition to having a better distribution of users across the existing volumes, another benefit of using multiple databases per disk is that it reduces the amount of time to restore data protection in the event of a failure that necessitates a reseed (for example, disk failure).

По мере увеличения размера базы данных повторное ее заполнение занимает больше времени. Например, повторное заполнение базы данных на 2 ТБ может занять 23 часа, а базы данных на 8 ТБ — 93 часа (почти 4 дня). В обоих случаях повторное заполнение выполняется со скоростью около 20 МБ в секунду. Обычно это значит, что очень большую базу данных невозможно заполнить в разумный срок.As a database gets bigger, reseeding the database takes longer. For example, a 2-terabyte database could take 23 hours to reseed, whereas an 8-terabyte database could take as long as 93 hours (almost 4 days). Both seeds would occur at about 20 MB per second. This generally means that a very large database can't be seeded within an operationally reasonable amount of time.

Если используется сценарий с одной копией базы данных на диск, операция заполнения эффективно связана с источником, поскольку диск постоянно заполняется из одного источника. Вследствие разделения тома на несколько копий базы данных и наличия активной копии пассивных баз данных на определенном томе, который хранится у отдельных членов группы обеспечения доступности баз данных, система больше не будет связанной с источником в контексте повторного заполнения диска. При замене неисправного диска, он может быть повторно заполнен из нескольких источников. Это позволяет системе выполнить повторное заполнение и возобновить защиту данных для этих баз данных в более короткий срок.In the case of a single database copy per disk scenario, the seeding operation is effectively source-bound, because it's always seeding the disk from a single source. By dividing the volume into multiple database copies, and by having the active copy of the passive databases on a specified volume stored on separate DAG members, the system is no longer source bound in the context of reseeding the disk. When a failed disk is replaced, it can be reseeded from multiple sources. This allows the system to reseed and restore data protection for these databases in a much shorter amount of time.

При использовании нескольких баз данных на одном томе, мы советуем выполнить следующие рекомендации.When using multiple databases per volume, we recommend adhering to the following best practices and requirements:

  • Следует использовать один раздел логического диска на физический диск. Не создавайте на диске несколько разделов. Каждая копия базы данных и ее сопровождающие файлы (например, журналы транзакций и индекс контента) должны размещаться в уникальном каталоге на отдельном разделе.A single logical disk partition per physical disk must be used. Don't create multiple partitions on the disk. Each database copy and its companion files (such as transaction logs and content index) should be hosted in a unique directory on the single partition.

  • Число копий базы данных, созданных в том должно быть равно числу копий каждой базы данных. Например, если имеется четыре копии базы данных, необходимо использовать четыре копии базы данных на том.The number of database copies configured per volume should be equal to the number of copies of each database. For example, if you have four copies of your databases, you should use four database copies per volume.

  • Копии базы данных должны иметь одних соседей. (Например, они все должны размещаться на одном диске на каждом сервере).Database copies should have the same neighbors. (For example, they should all share the same disk on each server.)

  • Приоритет активации в группе обеспечения доступности баз данных должен быть сбалансирован таким образом, чтобы каждая копия базы данных на заданном диске имела уникальное значение приоритета активации.Activation preference across the DAG should be balanced, such that each database copy on a specified disk has a unique activation preference value.

AutoReseedAutoReseed

Автоматическое повторное заполнение, или AutoReseed — это функция, которая заменяет обычное действие администратора в ответ на отказ диска, повреждение базы данных или другую проблему, требующую повторного заполнения копии базы данных. Функция Autoreseed была создана для автоматического восстановления избыточности базы данных после сбоя диска с помощью запасных дисков, настроенных в системе.Automatic reseed, or AutoReseed, is a feature that's the replacement for what is normally administrator-driven action in response to a disk failure, database corruption event, or other issue that necessitates a reseed of a database copy. AutoReseed is designed to automatically restore database redundancy after a disk failure by using spare disks that have been provisioned on the system.

Дополнительные сведения см. в разделе AutoReseed. Подробные инструкции по настройке функции AutoReseed см. в разделе Настройка автоматического заполнения для группы обеспечения доступности баз данных.For more information, see AutoReseed. For detailed steps to configure AutoReseed, see Configure AutoReseed for a database availability group.

Автоматическое восстановление после сбоев для храненияAutomatic recovery from storage failures

Автоматическое восстановление после сбоев на хранение в Exchange 2010 нововведение позволяющий системе восстановления после сбоев, затрагивающих избыточность и отказоустойчивость. Помимо реакций на события отладки программы Exchange 2010, Exchange 2013 включает дополнительные действия по восстановлению для длинных операций ввода-вывода, чрезмерного потребления памяти службой репликации Microsoft Exchange (MSExchangeRepl.exe), а также тяжелых случаев, при которых невозможно запланировать потоки.Automatic recovery from storage failures continues the innovation introduced in Exchange 2010 to allow the system to recover from failures that affect resiliency or redundancy. In addition to the Exchange 2010 bugcheck behaviors, Exchange 2013 includes additional recovery behaviors for long I/O times, excessive memory consumption by the Microsoft Exchange Replication service (MSExchangeRepl.exe), and severe cases where threads can't be scheduled.

Даже в средах JBOD могут возникнуть проблемы с контроллерами массивов хранения, такие как сбой или зависание. В Exchange 2010 включены функции обнаружения зависших операций ввода-вывода и последующего восстановления, которые обеспечивают повышенную устойчивость. Эти функции перечислены в следующей таблице.Even in JBOD environments, storage array controllers can have issues, such as crashing or hanging. Exchange 2010 included hung I/O detection and recovery features that provided enhanced resilience. These features are listed in the following table.

ИмяName ПроверкаCheck ActionAction ПорогThreshold

Обнаружение зависания ввода-вывода базы данных ESEESE Database Hung IO Detection

Проверка незавершенных операций ввода-вывода с помощью обработчика ESEESE checks for outstanding I/Os

Создание элемента сбоя в канале Crimson для перезапуска сервераGenerates a failure item in the crimson channel to restart the server

240 с240 seconds

Периодический сигнал канала элемента сбояFailure Item Channel Heartbeat

Обеспечение возможности записи и чтения отказавших элементов в канале CrimsonEnsures failure items can be written to and read from crimson channel

Служба репликации сервера периодического сигнала канала Crimson на сбои и перезапускReplication service heartbeats crimson channel and restart server on failures

30 с30 seconds

Периодический сигнал системного дискаSystem Disk Heartbeat

Проверка состояния диска серверной системыVerifies server's system disk state

Периодическая отправка небуферизованных операций ввода-вывода на системный диск; перезапуск сервера по истечении времени ожидания периодического сигналаPeriodically sends unbuffered I/O to system disk; restarts server on heartbeat time out

120 с120 seconds

Exchange 2013 улучшает устойчивость сервера и хранилища, реализуя новые методы для других серьезных условий. Эти условия и режимы описаны в таблице ниже.Exchange 2013 enhances server and storage resilience by including new behaviors for other serious conditions. These conditions and behaviors are described in the following table.

ИмяName ПроверкаCheck ActionAction ПорогThreshold

Неправильное состояние системыSystem bad state

Нет потоков, включая неуправляемые потоки, которые можно запланироватьNo threads, including non-managed threads, can be scheduled

Перезапустите серверRestart the server

302 с302 seconds

Длительное время операций ввода-выводаLong I/O times

Измерения задержки операций ввода-выводаI/O operation latency measurements

Перезапустите серверRestart the server

41 с41 seconds

Использование памяти службы репликацииReplication service memory use

Измерение рабочего множества MSExchangeRepl.exeMeasure the working set of MSExchangeRepl.exe

  1. Занесите событие 4395 в журнал канала Crimson с запросом на прекращение работы службыLog event 4395 in the crimson channel with a service termination request

  2. Завершите работу MSExchangeRepl.exeInitiate termination of MSExchangeRepl.exe

  3. Если при завершении работы службы возникает ошибка, перезапустите серверIf service termination fails, restart the server

4 гигабайта (ГБ)4 gigabyte (GB)

Системное событие 129 (сброс шины)System Event 129 (Bus reset)

Проверка наличия записи о событии 129 в журнале системных событийCheck for Event 129 in System event log

Перезапустите серверRestart the server

Время событияWhen event occurs

Зависание базы данных кластераCluster database hang

Обновления диспетчера глобального обновления заблокированыGlobal Update Manager updates are blocked

Перезапустите серверRestart the server

Время событияWhen event occurs

Повышения изолированной копииLagged copy enhancements

Улучшения изолированной копии включают в себя интеграцию изолированной копии с функцией "страховочной сети" и автоматическое воспроизведение файлов журнала в определенных сценариях. "Страховочная сеть" — это функция транспорта, которая заменяет функцию Exchange 2010, которая называлась транспортной корзиной. Функция "страховочной сети" сходна с транспортной корзиной в том, что является очередью доставки, сопоставленной с транспортной службой на сервере почтовых ящиков. Магазины копий сообщения в этой очереди, были успешно переданы на активной базы данных почтовых ящиков на сервере почтовых ящиков. У каждой активной базы данных почтовых ящиков есть своя очередь на сервере почтовых ящиков, в которой хранятся копии доставленных сообщений. Можно указать, как долго функция "страховочной сети" хранит копии успешно доставленных сообщений до истечения их срока действия и автоматического удаления.Lagged copy enhancements include integration with Safety Net and automatic play down of log files in certain scenarios. Safety Net is a feature of transport that replaces the Exchange 2010 feature known as transport dumpster. Safety Net is similar to transport dumpster, in that it's a delivery queue that's associated with the Transport service on a Mailbox server. This queue stores copies of messages that were successfully delivered to the active mailbox database on the Mailbox server. Each active mailbox database on the Mailbox server has its own queue that stores copies of the delivered messages. You can specify how long Safety Net stores copies of the successfully delivered messages before they expire and are automatically deleted.

Функция "страховочной сети" частично отвечает за теневую избыточность в средах с группами обеспечения доступности баз данных. В этих средах для обеспечения теневой избыточности не нужно хранить другую копию доставленного сообщения в теневой очереди, пока ожидается репликация доставленного сообщения в пассивных копиях баз данных почтовых ящиков на других серверах почтовых ящиков в группе обеспечения доступности баз данных. Копия отправленного сообщения уже хранится в "страховочной сети", поэтому теневая избыточность позволяет при необходимости повторно доставить сообщение из "страховочной сети".Safety Net takes some responsibility from shadow redundancy in DAG environments. In DAG environments, shadow redundancy doesn't need to keep another copy of the delivered message in a shadow queue while it waits for the delivered message to replicate to the passive copies of mailbox databases on the other Mailbox servers in the DAG. The copy of the delivered message is already stored in Safety Net, so shadow redundancy can redeliver the message from Safety Net if necessary.

После внедрения функции "страховочной сети" активировать изолированную копию базу данных стало значительно проще. Например, рассмотрим изолированную копию с 2-дневной задержкой преобразования. В этом случае "страховочную сеть" необходимо настроить на срок в 2 дня. В случае возникновения ситуации, в которой требуется использовать изолированную копию, можно приостановить репликацию в нее и скопировать ее дважды (для сохранения изоляции базы данных и создания дополнительной копии, если она необходима). Затем создайте копию и удалите все файлы журналов, кроме файлов в требуемом диапазоне. Подключите копию, после чего в функции "страховочной сети" запустится автоматический запрос на повторную доставку почты в последние два дня. Благодаря "страховочной сети" отпадает необходимость отслеживания точки повреждения. Пользователь получает почту за последние два дня за исключением данных, которые обычно теряются при отработке отказа, вызвавшей потерю данных.With the introduction of Safety Net, activating a lagged database copy becomes significantly easier. For example, consider a lagged copy that has a 2-day replay lag. In that case, you would configure Safety Net for a period of 2 days. If you encounter a situation in which you need to use your lagged copy, you can suspend replication to it, and copy it twice (to preserve the lagged nature of the database and to create an extra copy in case you need it). Then, take a copy and discard all the log files, except for those in the required range. Mount the copy, which triggers an automatic request to Safety Net to redeliver the last two days of mail. With Safety Net, you don't need to hunt for where the point of corruption was introduced. You get the last two days mail, minus the data ordinarily lost on a lossy failover.

Теперь изолированные копии могут позаботиться о себе сами, вызывая автоматическое воспроизведение журналов в определенных сценариях:Lagged copies can now care for themselves by invoking automatic log replay to play down the log files in certain scenarios:

  • При достижении порога нехватки места на диске.When a low disk space threshold is reached

  • Если изолированная копия физически повреждена и требуется исправить страницу.When the lagged copy has physical corruption and needs to be page patched

  • При наличии менее трех доступных работоспособных копий (активных или пассивных; изолированные копии не учитываются) в течение более 24 часов.When there are fewer than three available healthy copies (active or passive only; lagged database copies are not counted) for more than 24 hours

В Exchange 2010 не поддерживалось исправление страниц для изолированных копий. В Exchange 2013 исправления страницы доступны для изолированных копий с помощью этой функции автоматического воспроизведения. Если возникнет необходимость в исправлении страниц для изолированной копии, в последней будут автоматически воспроизведены журналы, что позволит исправить страницы. Эта функция автоматического воспроизведения также запускается в изолированных копиях, если достигается нижний порог доступного дискового пространства или обнаружено, что изолированная копия является единственной доступной копией в течение определенного времени.In Exchange 2010, page patching wasn't available for lagged copies. In Exchange 2013, page patching is available for lagged copies through this automatic play down feature. If the system detects that page patching is required for a lagged copy, the logs are automatically replayed into the lagged copy to perform page patching. Lagged copies also invoke this auto replay feature when a low disk space threshold has been reached, and when the lagged copy has been detected as the only available copy for a specific period of time.

Воспроизведение изолированных копий по умолчанию отключено. Его можно включить с помощью следующей команды.Lagged copy play down behavior is disabled by default, and can be enabled by running the following command.

Set-DatabaseAvailabilityGroup <DAGName> -ReplayLagManagerEnabled $true

После включения воспроизведение происходит при наличии менее трех копий. Можно изменить значение по умолчанию, равное 3, изменив следующее значение DWORD в реестре.After being enabled, play down occurs when there are fewer than three copies. You can change the default value of 3, by modifying the following DWORD registry value.

\Программное\обеспечение\HKLM\ExchangeServer\V15 параметры\\преобразования реплайлагманажернумаваилаблекопиесHKLM\Software\Microsoft\ExchangeServer\v15\Replay\Parameters\ReplayLagManagerNumAvailableCopies

Чтобы включить воспроизведение для нижних порогов доступного дискового пространства, необходимо настроить следующую запись реестра.To enable play down for low disk space thresholds, you must configure the following registry entry.

\Программное\обеспечение\HKLM\ExchangeServer\V15 параметры\\преобразования реплайлагловспацеплайдовнсрешолдинмбHKLM\Software\Microsoft\ExchangeServer\v15\Replay\Parameters\ReplayLagLowSpacePlaydownThresholdInMB

После настройки какого-либо из этих параметров реестра перезапустите службу управления DAG Microsoft Exchange, чтобы изменения вступили в силу.After configuring either of these registry settings, restart the Microsoft Exchange DAG Management service for the changes to take effect.

В качестве примера рассмотрим среду, где у базы данных есть 4 копии (3 копии с высоким уровнем доступности и 1 изолированная копия), а для параметра ReplayLagManagerNumAvailableCopies используется значение по умолчанию.As an example, consider an environment where a given database has 4 copies (3 highly available copies and 1 lagged copy), and the default setting is used for ReplayLagManagerNumAvailableCopies. Если неизолированная копия по какой-либо причине недоступна (например, приостановлена и т. д.), то изолированная копия автоматически воспроизводит файлы журналов через 24 часа.If a non-lagged copy is out-of-service for any reason (for example, it is suspended, etc.) then the lagged copy will automatically play down its log files in 24 hours.

Усовершенствования оповещений для отдельных копийSingle copy alert enhancements

Обеспечение надежной работы серверов и работоспособности копий базы данных почтовых ящиков — это основные цели ежедневного использования системы обмена сообщениями Exchange 2013. Необходимо вести активное наблюдение за оборудованием, операционной системой Windows и службами Exchange. Но при работе в среде с устойчивой работой почтовых ящиков Exchange 2013 необходимо отслеживать работоспособность и состояние группы обеспечения доступности баз данных, а также копий баз данных почтовых ящиков. Особенно важно управлять рисками избыточности данных и выполнять мониторинг в течение периодов, когда реплицированная база данных имеет только одну копию. Это чрезвычайно важно в средах, в которых не используются диски RAID, а вместо этого развертываются конфигурации JBOD. В среде RAID сбой одного диска не повлияет на активную копию базы данных почтовых ящиков. Однако в среде JBOD сбой одного диска вызовет отработку отказа базы данных.Ensuring that your servers are operating reliably and that your mailbox database copies are healthy are primary objectives of daily Exchange 2013 messaging operations. You must actively monitor the hardware, the Windows operating system, and the Exchange services. But when running in an Exchange 2013 mailbox resiliency environment, it's important that you monitor the health and status of the DAG and your mailbox database copies. It's especially vital to perform data redundancy risk management and monitor for periods in which a replicated database is down to just a single copy. This is particularly critical in environments that don't use Redundant Array of Independent Disks (RAID) and instead deploy JBOD configurations. In a RAID environment, a single disk failure doesn't affect an active mailbox database copy. However, in a JBOD environment, a single disk failure will trigger a database failover.

В Exchange 2010 представлен сценарий CheckDatabaseRedundancy.ps1. Он позволяет отследить избыточность реплицированных баз данных почтовых ящиков путем проверки наличия по крайней мере двух настроенных, работоспособных и актуальных копий, а также оповещает администратора с помощью журнала событий, если существует только одна работоспособная копия реплицированной базы данных. В этом случае при определении избыточности учитываются и активная, и пассивные копии.In Exchange 2010, the script CheckDatabaseRedundancy.ps1 was introduced. As its name implies, the purpose of the script was to monitor the redundancy of replicated mailbox databases by validating that there is at least two configured, healthy, and current copies, and to alert an administrator through event log generation when only a single healthy copy of a replicated database exists. In this case, both active and passive copies are counted when determining redundancy.

Условия для создания единого хранилища включают следующие варианты, но не ограничиваются ими.Single copy conditions include, but aren't limited to:

  • Ошибка репликации активной копии в любую пассивную копию.Failure of an active copy to replicate to any passive copy.

  • Сбой всех пассивных копий, включая состояния FailedAndSuspended и Failed, а также работоспособные состояния, когда копия не принимает участия в копировании или воспроизведении журналов. Обратите внимание, что изолированные копии не считаются просроченными, если не прошел десятиминутный период задержки при воспроизведении их журналов.Failure of all passive copies, which includes FailedAndSuspended and Failed states in addition to healthy states where the copy is behind in log copying or replay. Note that lagged copies aren't considered behind if they're within ten minutes in replaying their logs to their lag period.

  • Сбой системы при определении создания текущего журнала активной копии.Failure of the system to accurately know the current log generation of the active copy.

Поскольку администраторы в первую очередь должны знать, когда осталась единственная работоспособная копия базы данных, сценарий CheckDatabaseRedundancy.ps1 заменен на встроенные интегрированные функции, которые входят в набор для контроля работоспособности DataProtection управляемой доступности.Because it's a top priority for administrators to know when they're down to a single healthy copy of a database, the CheckDatabaseRedundancy.ps1 script has been replaced with integrated, native functionality that's part of managed availability's DataProtection Health Set.

Встроенная функция по-прежнему оповещает администраторов с помощью уведомлений журнала событий, а чтобы различать оповещения Exchange 2013 и Exchange 2010, Exchange 2013 использует следующие коды событий:The native functionality still alerts administrators through event log notifications, and to distinguish Exchange 2013 alerts from Exchange 2010, Exchange 2013 uses the following Event IDs:

  • Событие 4138 (Red Alert)Event 4138 (Red Alert)

  • Событие 4139 (Green Alert)Event 4139 (Green Alert)

В Exchange 2013 встроенные функции были усовершенствованы для сокращения количества оповещений, которые могут возникать, когда несколько баз данных на одном сервере переходят в состояние с одной копией. В Exchange 2010 предупреждения об одной копии создавались на уровне отдельной базы данных. В результате при возникновении проблемы на сервере, которая влияет на несколько баз данных и несколько копий баз данных, могла возникать лавина предупреждений. Поскольку некоторые сбои, например ошибки контроллера или памяти, относятся ко всему серверу, существовала умеренно высокая возможность возникновения "лавины" оповещений для каждого инцидента с сервером. В Exchange 2013 тревоги теперь формируются для отдельных серверов. В настоящее время, если простой затрагивает весь сервер, а избыточность данных становится уязвимой на нескольких копиях базы данных, создается одно оповещение на сервер.In Exchange 2013, the native functionality has been enhanced to reduce the level of alert noise that can occur when multiple databases on the same server enter into a single copy condition. In Exchange 2010, single copy alerts were generated on a per-database level. As a result, when there was a server-wide issue that affected multiple databases and multiple database copies, alert storms could occur. Because several failures, such as controller or memory problems, are server-wide, there was a moderately high probability that such an alert storm would occur for each server incident. In Exchange 2013, alerts are now generated on a per-server basis. When an outage affects an entire server and data redundancy becomes at risk for multiple database copies, a single alert per server is now generated.

Автоматическая настройка сети DAGDAG network auto-configuration

Сеть DAG состоит из одной или нескольких подсетей, используемых для трафика репликации или трафика MAPI. Каждая группа DAG содержит максимум одну сеть MAPI и ни одной или несколько сетей репликации. В Exchange 2010 начальные сети DAG (например, DAGNetwork01 и DAGNetwork02) были созданы системой на основе подсетей службы кластеров. В средах с несколькими сетями, в которых интерфейсы указанной сети (например, сети MAPI) располагались в одной подсети, администратору требовалось выполнить дополнительную незначительную настройку. Однако в средах, в которых интерфейсы указанной сети находились в нескольких подсетях, администратору приходилось выполнять задачу, известную как свертывание сетей группы обеспечения доступности баз данных.A DAG network is a collection of one or more subnets used for either replication traffic or MAPI traffic. Each DAG contains a maximum of one MAPI network and zero or more replication networks. In Exchange 2010, the initial DAG networks (for example, DAGNetwork01 and DAGNetwork02) were created by the system based on the subnets enumerated by the Cluster service. In environments where multiple networks are used and the interfaces for a specified network (for example, the MAPI network) were on the same subnet, there was little additional configuration that an administrator needed to perform. However, in environments where the interfaces for a specified network were on multiple subnets, the administrator had to perform a task referred to as collapsing DAG networks.

В Exchange 2013 свертывание сетей группы обеспечения доступности баз данных больше не требуется. В Exchange 2013 по-прежнему используются те же механизмы обнаружения для различения сетей MAPI и сетей репликации, но сейчас свертывание сетей группы обеспечения доступности баз данных при необходимости выполняется автоматически.In Exchange 2013, collapsing DAG networks is no longer necessary. Exchange 2013 still uses the same detection mechanisms to distinguish between the MAPI and replication networks, but it now automatically collapses DAG networks as appropriate.

Кроме того, теперь по умолчанию сетями DAG автоматически управляет система.In addition, by default, DAG networks are now automatically managed by the system. Чтобы просмотреть свойства сети DAG с помощью центра администрирования Exchange, необходимо настроить группу DAG для управления сетью вручную, изменив свойства группы DAG с помощью центра администрирования Exchange или с помощью командлета Set-DatabaseAvailabilityGroup , чтобы задать * Параметр Мануалдагнетворкконфигуратион* для True.To view DAG network properties using the Exchange admin center (EAC), you must configure the DAG for manual network control by modifying the properties of the DAG using EAC, or by using the Set-DatabaseAvailabilityGroup cmdlet to set the ManualDagNetworkConfiguration parameter to True.

Изменения процесса выбора оптимальной копииChanges to best copy selection

Выбор оптимальной копии (BCS) — это внутренний алгоритм поиска наилучшей копии отдельной базы данных для активации при наличии списка потенциальных копий, их работоспособности и состояния. Активный диспетчер выбирает лучшую доступную (и незаблокированную) копию в качестве новой активной копии базы данных, если существующая активная копия базы данных не работает или администратор выполняет переключение без целевой точки. В Exchange 2010 процесс BCS оценивал ряд свойств всех копий баз данных, чтобы определить "оптимальную" для активации копию. К ним относятся:Best copy selection (BCS) is an internal algorithm process for finding the best copy of an individual database to activate, given a list of potential copies for activation and their health and status. Active Manager selects the best available (and unblocked) copy to become the new active database copy when the existing active database copy fails or when an administrator performs a targetless switchover. In Exchange 2010, the BCS process evaluated several aspects of each database copy to determine the best copy to activate. These included:

  • длина очереди копирования;Copy queue length

  • длина очереди воспроизведения;Replay queue length

  • состояние базы данных;Database status

  • состояние индекса содержимого.Content index status

В Exchange 2013 активный диспетчер выполняет одинаковые проверки и этапы BCS для определения работоспособности репликации, но теперь он также использует ограничение в порядке убывания состояний работоспособности. В результате таких изменений алгоритм BCS теперь называется и выбором оптимальной копии и сервера (BCSS).In Exchange 2013, Active Manager performs the same BCS checks and phases to determine replication health, but it now also includes the use of a constraint of the decreasing order of health states. As a result of these changes, BCS is now called best copy and server selection (BCSS).

BCSS включает ряд новых проверок работоспособности, которые входят во встроенные компоненты мониторинга управляемой доступности в Exchange 2013. Активный диспетчер теперь выполняет четыре новых дополнительных проверки (перечисленных ниже в порядке выполнения).BCSS includes several new health checks that are part of the built in managed availability monitoring components in Exchange 2013. There are four new additional checks performed by Active Manager (listed in the order in which they're performed):

  1. Все работоспособные: Проверка сервера, на котором размещается копия затронутой базы данных со всеми компонентами мониторинга в работоспособном состоянии.All Healthy: Checks for a server hosting a copy of the affected database that has all monitoring components in a healthy state.

  2. Нормально работоспособноесостояние: Проверка сервера, на котором размещается копия затронутой базы данных со всеми компонентами мониторинга с нормальным приоритетом в работоспособном состоянии.Up to Normal Healthy: Checks for a server hosting a copy of the affected database that has all monitoring components with Normal priority in a healthy state.

  3. Все лучше, чем исходный: Проверка сервера, на котором размещается копия затронутой базы данных, в котором находятся компоненты мониторинга, лучше, чем у текущего сервера, на котором размещается заданная копия.All Better than Source: Checks for a server hosting a copy of the affected database that has monitoring components in a state that's better than the current server hosting the affected copy.

  4. As source: Проверка сервера, на котором размещается копия затронутой базы данных, в которой компоненты мониторинга находятся в состоянии, то же, что и текущий сервер, на котором размещена заданная копия.Same as Source: Checks for a server hosting a copy of the affected database that has monitoring components in a state that's the same as the current server hosting the affected copy.

Если BCSS запускается в результате отработки отказа, которая инициируется компонентом мониторинга управляемой доступности (например, с помощью отвечающего устройства отработки отказов), применяется дополнительное принудительное ограничение, согласно которому работоспособность компонента целевого сервера должна превышать работоспособность компонента сервера, на котором выполнялась отработка отказа.If BCSS is invoked as a result of a failover that's triggered by a managed availability monitoring component (for example, via a Failover responder), an additional mandatory constraint is enforced where the target server's component health must be better than the server on which the failover occurred. Например, если сбой Outlook Web App вызывает отработку отказа управляемой доступности с помощью ответчика отработки отказа, BCSS должен выбрать сервер, на котором размещена копия затронутой базы данных, в которой Outlook Web App является работоспособным.For example, if a failure of Outlook Web App triggers a managed availability failover via a Failover responder, BCSS must select a server hosting a copy of the affected database on which Outlook Web App is healthy.

Служба управления группой обеспечения доступности баз данных (DAG)DAG Management Service

Накопительный пакет обновления 2 (CU2) для окончательной первоначальной версии (RTM) Exchange 2013 содержит новую службу на серверах почтовых ящиков, являющихся членами DAG. Данная служба называется службой управления DAG Microsoft Exchange (MSExchangeDAGMgmt). Эта служба включает внутреннюю функцию мониторинга DAG, которая ранее выполнялась в службе репликации Microsoft Exchange (MSExchangeRepl).Cumulative Update 2 (CU2) for the Release to Manufacturing (RTM) version of Exchange 2013 contains a new service on Mailbox servers that are members of a DAG. This service is called the Microsoft Exchange DAG Management Service (MSExchangeDAGMgmt). This new service contains internal DAG monitoring functionality that previously executed inside the Microsoft Exchange Replication service (MSExchangeRepl).

Группы обеспечения доступности баз данных без административной точки доступа кластераDAGs without a cluster administrative access point

Всем группам обеспечения доступности баз данных под управлением Windows Server 2008 R2 или Windows Server 2012 требуется по крайней мере один IP-адрес в каждой подсети, включенной в сеть MAPI. IP-адреса, назначенные группе обеспечения доступности баз данных, используются кластером этой группы с административной точкой доступа кластера (которая также называется сетевым именем кластера), чтобы включить разрешение имен и подключение к кластеру (или, что более точно, подключение к элементу кластера, который в настоящее время владеет группой ресурсов ядра кластера) с использованием имени кластера. Windows Server 2012 R2 позволяет создать отказоустойчивый кластер без административной точки доступа. Отказоустойчивые кластеры Windows без административных точек доступа отличаются приведенными ниже характеристиками.All DAGs running Windows Server 2008 R2 or Windows Server 2012 require at least one IP address on every subnet included in the MAPI network. The IP address(es) assigned to the DAG are used by the DAG's cluster with the cluster's administrative access point (also known as the cluster network name) to enable name resolution and connectivity to the cluster (or more precisely, connectivity to the cluster member that currently owns the cluster core resource group) using the cluster name. Windows Server 2012 R2 enables you to create a failover cluster without an administrative access point. Windows failover clusters without administrative access points have the following characteristics:

  • Кластеру не назначен IP-адрес, поэтому в группе ресурсов ядра кластера отсутствует ресурс "IP-адрес".There is no IP address assigned to the cluster, 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 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 невозможно управлять с помощью средства управления отказоустойчивым кластером. Управлять им нужно с помощью Windows PowerShell, а командлеты Windows PowerShell должны выполняться в отношении отдельных элементов кластера.The Windows failover 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.

При работе в Windows Server 2012 R2 или более поздней версии пакет обновления 1 (SP1) для Exchange 2013 и более поздних версий позволяет создать группу обеспечения доступности баз данных без административной точки доступа кластера.When running on Windows Server 2012 R2 or later, Service Pack 1 (SP1) for Exchange 2013 and later enable you to create a DAG without a cluster administrative access point. Вы можете создать группу DAG без административной точки доступа с помощью центра администрирования Exchange или командной консоли.You can create a DAG without an administrative access point using the Exchange admin center or by using the Shell. Дополнительные сведения см. в статье Создание DAG и Создание группы обеспечения доступности баз данных.For more information, see Creating DAGs and Create a database availability group.