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

В Exchange Server 2013 и более поздних версий используются копии баз данных DAG и почтовых ящиков (наряду с другими функциями, такими как восстановление отдельных элементов, политики хранения и копии баз данных изолированной) для обеспечения высокой доступности, устойчивости сайта и собственной защиты данных Exchange.Exchange Server 2013 and later 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. Платформа высокой доступности, банк данных Exchange и расширенный обработчик хранилищ (ESE) были усовершенствованы, начиная с Exchange 2010, обеспечивая доступность и менее сложное управление, а также сокращая затраты.The high availability platform, Exchange Information Store and Extensible Storage Engine (ESE) have all been enhanced since Exchange 2010 to provide availability and less complex management, and to reduce costs. Эти усовершенствования включают в себя:These enhancements include:

  • Сокращение количества операций ввода-вывода в секунду: Это позволяет использовать большие диски в терминах емкости и операций ввода-вывода максимально эффективно.Reduction in IOPS: 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 rewritten Information Store processes in Exchange 2013 or later. Управляемое хранилище написано на языке C# и тесно интегрировано со службой репликации Microsoft Exchange (MSExchangeRepl. exe), чтобы обеспечить более высокую доступность с помощью улучшенной устойчивости.The Managed Store is written in C# and tightly integrated with the Microsoft Exchange Replication service (MSExchangeRepl.exe) to provide higher availability through improved resiliency.

  • Поддержка нескольких баз данных на диске: расширения позволяют поддерживать несколько баз данных (смесь активных и пассивных копий) на одном диске, что позволяет эффективно использовать большие диски в терминах емкости и операций ввода-вывода.Support for multiple databases per disk: Enhancements 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 that was introduced in Exchange 2010 to allow the system to recover from failures that affect resiliency or redundancy. Exchange теперь включает дополнительные возможности восстановления для длительных операций ввода-вывода, чрезмерного потребления памяти с помощью MSExchangeRepl. exe и серьезных случаев, когда система находится в таком состоянии, что потоки не могут быть запланированы.Exchange now 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.

Сокращение числа операций ввода-выводаReduction in IOPS

В 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 МБ).In Exchange 2013 or later, the system is able to provide fast failover while using a high checkpoint depth on the passive copy (100 MB). Поскольку пассивные копии имеют глубину контрольных точек 100 МБ, они повторно настроены на менее агрессивное выполнение операций.Because passive copies have 100-MB checkpoint depth, they've been de-tuned to no longer be so aggressive. В результате увеличения глубины контрольных точек и отмены настройки агрессивных предварительных операций ввода-вывода в секунду для пассивной копии составляет около 50 процентов активных операций копирования.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.

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

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

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

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

Управляемая доступность — это интеграция встроенного, активного мониторинга и платформы высокой доступности Exchange.Managed Availability is the integration of built-in, active monitoring and the Exchange 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 in the Client Access (frontend) services and backend services on Mailbox servers. Управляемая доступность включает три основных асинхронных компонента, которые постоянно выполняют работу:Managed Availability includes three main asynchronous components that are constantly doing work:

  1. Первый компонент — это механизм проверки, ответственный за выполнение измерений на сервере и сбор данных.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.

  2. Монитор содержит всю используемую системой бизнес-логику на основе того, что считается работоспособным состоянием собранных данных.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.

  3. Наконец, существует подсистема ответа, которая несет ответственность за действия по восстановлению.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:

  1. Перезапустите пул приложений.Restart the application pool.

  2. Перезапустите службу.Restart the service.

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

  4. Переведите сервер в автономный режим, чтобы он больше не принимал трафик.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 2010 и более ранние версии поддерживают выполнение одного экземпляра процесса банка данных (Store. exe) на роли сервера почтовых ящиков.Exchange 2010 and earlier versions support 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. В этих архитектурах Exchange мало (при изоляции) между различными базами данных, размещенными на сервере почтовых ящиков.In these 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.

Еще одна проблема с одним экземпляром хранилища заключается в нехватке масштабируемости процессора с помощью расширенного обработчика хранилищ (ESE).Another challenge with a single Store instance is the lack of processor scalability with the Extensible Storage Engine (ESE). Подсистема ESE масштабируется хорошо до 8-12 ядер процессоров, но помимо этого, проблемы с синхронизацией между процессорами и кэшированием приводят к снижению производительности.ESE scales well to 8-12 processor cores, but beyond that, cross-processor communication and cache synchronization issues lead to negative performance. Заданные современные серверы с 16 + основными системами, это может привести к административному административному управлению сходством с ядром 8-12 для ESE и использованию других ядер для процессов, не являющихся хранилищами (например, помощников, служб поиска, управляемых Доступность и т. д.).Given today's servers with 16+ core systems available, this would 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, но в конечном итоге его масштабируемость как одного процесса ограничена и представляет единственную точку отказа.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. Из-за этих пределов файл Store. exe был удален в Exchange 2013 и заменен управляемым хранилищем.Because of these limits, Store.exe was removed in Exchange 2013 and replaced by the Managed Store.

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

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

Несмотря на то что улучшения хранилища в Exchange предназначены в основном только для JBOD конфигураций, они доступны для использования всеми поддерживаемыми конфигурациями хранилища.Although the storage improvements in Exchange 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. Эта функция предназначена для больших дисков о Exchange оптимизация.This feature is about Exchange optimizing for large disks. Эти улучшения позволяют использовать большие диски по емкости с гораздо большей эффективностью в показателях емкости, количества операций ввода-вывода в секунду и времени повторного заполнения, а также призваны устранить следующие проблемы, связанные с выполнением задач в конфигурации хранилища JBOD.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.

Тенденция увеличения емкости хранилища продолжается.The trend of increasing storage capacity continues. Например, рекомендация по использованию Exchange для максимального размера базы данных (2 терабайта) на 8 терабайтах означает, что вы затратите больше 5 терабайт дискового пространства.For example, the Exchange best practice guideline for maximum database size (2 terabytes) on an 8 terabyte drive means you would waste more than 5 terabytes of disk space.

Ссолутион бы просто увеличить размер баз данных, но это будет препятствовать управлению, так как это может привести к длительному времени повторного заполнения (в том числе для последующей перегрузки унманагабле) и скомпрометированной надежности копирования этого объема данных в сети.A ssolution would be to simply grow the databases larger, but that inhibits manageability because it might introduce long reseed times (including operationally unmanagable reseed times) and compromised reliability of copying that amount of data over the network.

Кроме того, в модели 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 and later has been optimized to use large disks (8 terabytes) in a JBOD configuration more efficiently. Теперь, когда несколько баз данных на одном диске, вы можете использовать одни и те же диски для хранения нескольких копий базы данных, в том числе копий изолированной.With multiple databases per disk, you can now 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

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

Конфигурация на схеме обеспечивает симметричную архитектуру.The configuration in the diagram 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 configuration in the diagram, 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:

  • Значение приоритета активации для активной копии будет равно 1.The active copy will have an activation preference value of 1.

  • Для первой пассивной копии будет задано значение приоритета активации 2.The first passive copy will have an activation preference value of 2.

  • Значение приоритета активации второго пассивного экземпляра будет равно 3.The second passive copy will have an activation preference value of 3.

  • Для копии изолированной будет задано значение приоритета активации 4.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 a reduction in the amount of time to restore data protection for failures that require a reseed (for example, disk failure).

По мере увеличения размера базы данных повторное ее заполнение занимает больше времени.As a database gets bigger, reseeding the database takes longer. Например, для повторного заполнения в базе данных 2 ТБ может потребоваться до 23 часов, в то время как база данных 8 ТБ может занять до 93 часов (почти 4 дня).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). В обоих случаях повторное заполнение выполняется со скоростью около 20 МБ в секунду.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 you use multiple databases per volume, we recommend that you follow these 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) — это замена действий, выполняемых администратором, в ответ на сбой диска, событие повреждения базы данных или другие проблемы, требующие повторного заполнения копии базы данных.Automatic reseed (also known as AutoReseed) is the replacement for what is normally an administrator-driven action in response to a disk failure, database corruption event, or other issue that requires a reseed of a database copy. Функция Autoreseed была создана для автоматического восстановления избыточности базы данных после сбоя диска с помощью запасных дисков, настроенных в системе.AutoReseed is designed to automatically restore database redundancy after a disk failure by using spare disks that have been provisioned on the system.

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

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

Автоматическое восстановление после сбоев хранилища позволяет системе восстанавливаться после сбоев, влияющих на устойчивость или избыточность.Automatic recovery from storage failures allows the system to recover from failures that affect resiliency or redundancy. В дополнение к режимам отладки, представленным в Exchange 2010, Exchange теперь включает дополнительные характеристики восстановления для длительных операций ввода-вывода, чрезмерного потребления памяти службой репликации Microsoft Exchange (MSExchangeRepl. exe) и серьезными случаями, в которых потоки не могут быть запланированы.In addition to the bugcheck behaviors introduced in Exchange 2010, Exchange now 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 могут возникнуть проблемы с контроллерами массивов хранения, такие как сбой или зависание.Even in JBOD environments, storage array controllers can have issues, such as crashing or hanging. В следующей таблице перечислены функции, обеспечивающие зависание ввода-вывода и функции восстановления, обеспечивающие повышенную устойчивость.The following table lists features that provide hung I/O detection and recovery features that provide enhanced resilience.

ИмяName ПроверкаCheck ДействиеAction Пороговое значение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 and later enhances server and storage resilience by including behaviors for other serious conditions. Эти условия и режимы описаны в таблице ниже.These conditions and behaviors are described in the following table.

ИмяName ПроверкаCheck ДействиеAction Пороговое значение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 с запросом на завершение работы службы1: Log event 4395 in the crimson channel with a service termination request
2: запуск завершения работы MSExchangeRepl. exe2: Initiate termination of MSExchangeRepl.exe
3: в случае сбоя завершения службы перезапустите сервер.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

Улучшения изолированной копии включают в себя интеграцию изолированной копии с функцией "страховочной сети" и автоматическое воспроизведение файлов журнала в определенных сценариях.Lagged copy enhancements include integration with Safety Net and automatic play down of log files in certain scenarios. В Exchange 2013 появился протокол безопасности, заменяющий компонент Exchange 2010, который называется транспортной корзиной.Safety Net was introduced in Exchange 2013 to replace the Exchange 2010 feature known as the transport dumpster. Сеть безопасности аналогична транспортной корзине, в том, что это очередь доставки, связанная со службой транспорта на сервере почтовых ящиков.Safety Net is similar to the 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.

Благодаря сети безопасности активация копии базы данных изолированной значительно упрощается.With Safety Net, activating a lagged database copy becomes significantly easier. Например, рассмотрим изолированную копию с 2-дневной задержкой преобразования.For example, consider a lagged copy that has a 2-day replay lag. В этом случае "страховочную сеть" необходимо настроить на срок в 2 дня.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:

  1. Приостановите репликацию.Suspend replication to it.

  2. Скопируйте его дважды (чтобы сохранить природу базы данных изолированной и создать дополнительную копию в случае необходимости).Copy it twice (to preserve the lagged nature of the database and to create an extra copy in case you need it).

  3. Создайте копию и удалите все файлы журналов, кроме тех, которые находятся в требуемом диапазоне.Take a copy and discard all the log files, except for those in the required range.

  4. Подключите копию, после чего в функции "страховочной сети" запустится автоматический запрос на повторную доставку почты в последние два дня.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 не поддерживалось исправление страниц для изолированных копий.In Exchange 2010, page patching wasn't available for lagged copies. В Exchange 2013 или более поздней версии обновление страниц доступно для изолированной копий с помощью этой функции автоматического проигрывания.In Exchange 2013 or later, 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\Software\Microsoft\ExchangeServer\v15\Replay\Parameters\ReplayLagManagerNumAvailableCopiesHKLM\Software\Microsoft\ExchangeServer\v15\Replay\Parameters\ReplayLagManagerNumAvailableCopies

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

HKLM\Software\Microsoft\ExchangeServer\v15\Replay\Parameters\ReplayLagLowSpacePlaydownThresholdInMBHKLM\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

Обеспечение надежной работы серверов и работоспособности копий базы данных почтовых ящиков — это основные цели ежедневных операций обмена сообщениями.Ensuring that your servers are operating reliably and that your mailbox database copies are healthy are primary objectives of daily Exchange messaging operations. Необходимо вести активное наблюдение за оборудованием, операционной системой Windows и службами Exchange.You must actively monitor the hardware, the Windows operating system, and the Exchange services.

Однако в среде обеспечения устойчивости почтовых ящиков Exchange важно следить за работоспособностью и состоянием группы DAG и копии базы данных почтовых ящиков.But in an Exchange 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. Это чрезвычайно важно в средах, в которых не используются диски RAID, а вместо этого развертываются конфигурации JBOD.This is particularly critical in environments that don't use Redundant Array of Independent Disks (RAID) and instead deploy JBOD configurations. В среде RAID сбой одного диска не повлияет на активную копию базы данных почтовых ящиков.In a RAID environment, a single disk failure doesn't affect an active mailbox database copy. Однако в среде JBOD сбой одного диска вызовет отработку отказа базы данных.However, in a JBOD environment, a single disk failure will trigger a database failover.

Сценарий Чеккдатабасередунданци. ps1 появился в Exchange 2010.The CheckDatabaseRedundancy.ps1 script was introduced in Exchange 2010. Он позволяет отследить избыточность реплицированных баз данных почтовых ящиков путем проверки наличия по крайней мере двух настроенных, работоспособных и актуальных копий, а также оповещает администратора с помощью журнала событий, если существует только одна работоспособная копия реплицированной базы данных.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 теперь использует следующие коды событий:The native functionality still alerts administrators through event log notifications, and to distinguish Exchange 2013 or later alerts from Exchange 2010, Exchange now uses the following Event IDs:

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

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

Встроенные функции были усовершенствованы для сокращения шума оповещений, возникающих при условии, что несколько баз данных на одном сервере находятся в одном условии копирования.The native functionality has been enhanced to reduce alert noise that occurs when multiple databases on the same server enter into a single copy condition. В Exchange 2010 предупреждения об одной копии создавались на уровне отдельной базы данных.In Exchange 2010, single copy alerts were generated on a per-database level. В результате проблемы на уровне сервера, которые затронули несколько баз данных и нескольких копий базы данных, могут привести к сбоям оповещений.As a result, a server-wide issue that affected multiple databases and multiple database copies could cause alert storms. Из-за нескольких отказов на уровне сервера (например, проблем с контроллером или памятью) существовала вероятность того, что для каждого инцидента сервера возникало оповещение.Because several failures are server-wide (for example, controller or memory problems), there was a good chance that an alert storm would occur for each server incident.

Теперь оповещения создаются отдельно для каждого сервера.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 per-server alert is generated.

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

Сеть DAG — это коллекция из одной или нескольких подсетей, используемых либо для трафика репликации, либо для трафика MAPI. Каждая группа DAG содержит не более одной сети MAPI и 0 или более сетей репликации.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.

В Exchange 2010 начальные сети DAG (например, DAGNetwork01 и DAGNetwork02) были созданы системой на основе подсетей, перечисленных службой кластеров.In Exchange 2010, the initial DAG networks (for example, DAGNetwork01 and DAGNetwork02) were created by the system based on the subnets that were enumerated by the Cluster service. Если у вас несколько сетей и интерфейсов для указанной сети (например, сеть MAPI) находятся в одной подсети, требуется немного дополнительной настройки.If you had multiple networks and the interfaces for a specified network (for example, the MAPI network) were on the same subnet, there was little additional configuration required. Тем не менее, если интерфейсы указанной сети находятся в нескольких подсетях, необходимо выполнить задачу, известную как свертывание сетей DAG.However, if the interfaces for a specified network were on multiple subnets, you needed to perform a task known as collapsing DAG networks.

В Exchange 2013 или более поздней версии свертывание сетей DAG больше не требуется.In Exchange 2013 or later, collapsing DAG networks is no longer necessary. Exchange по-прежнему использует те же механизмы обнаружения, чтобы различать сети MAPI и репликации, но теперь автоматически сворачивает сети DAG соответствующим образом.Exchange 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 или более поздней версии Active Manager выполняет те же проверки и этапы BCS для определения работоспособности репликации, но в настоящее время она также включает в себя ограничение порядка уменьшения состояния работоспособности.In Exchange 2013 or later, 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. В результате таких изменений алгоритм BCS теперь называется и выбором оптимальной копии и сервера (BCSS).As a result of these changes, BCS is now called best copy and server selection (BCSS).

BCSS включает несколько новых проверок работоспособности, которые теперь входят в состав встроенных компонентов мониторинга управляемой доступности в Exchange.BCSS includes several new health checks that are now part of the built-in managed availability monitoring components in Exchange. Active Manager выполняет четыре дополнительные проверки (перечисленные в том порядке, в котором они выполнены).There are four 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 в Интернете (прежнее название — Outlook Web App) инициирует отработку отказа управляемой доступности с помощью ответчика отработки отказа, BCSS должен выбрать сервер, на котором размещена копия затронутой базы данных, на которой Аулук в Интернете является работоспособным.For example, if a failure of Outlook on the web (formerly known as 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 Oulook on the web is healthy.

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

Exchange 2013 CU2 или более поздней версии включает службу управления DAG Microsoft Exchange (MSExchangeDAGMgmt).Exchange 2013 CU2 or later includes the Microsoft Exchange DAG Management Service (MSExchangeDAGMgmt). Эта служба содержит внутренние функции мониторинга DAG, которые ранее были в службе репликации Microsoft Exchange (MSExchangeRepl).This service contains the internal DAG monitoring functionality that was previously inside the Microsoft Exchange Replication service (MSExchangeRepl).

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

Все DAG на серверах Exchange с Windows Server 2008 R2 или Windows Server 2012 требуют по крайней мере один IP-адрес в каждой подсети, входящей в сеть MAPI.All DAGs on Exchange servers running Windows Server 2008 R2 or Windows Server 2012 require at least one IP address on every subnet included in the MAPI network. IP-адреса, назначенные группе обеспечения доступности баз данных, используются кластером этой группы с административной точкой доступа кластера (которая также называется сетевым именем кластера), чтобы включить разрешение имен и подключение к кластеру (или, что более точно, подключение к элементу кластера, который в настоящее время владеет группой ресурсов ядра кластера) с использованием имени кластера.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 или более поздней версии позволяет создать отказоустойчивый кластер без административной точки доступа.Windows Server 2012 R2 or later enables you to create a failover cluster without an administrative access point. Отказоустойчивые кластеры Windows без административных точек доступа отличаются приведенными ниже характеристиками.Windows failover clusters without administrative access points have the following characteristics:

  • Кластеру не назначены никакие IP-адреса, поэтому в группе ресурсов ядра кластера отсутствует ресурс "IP-адрес".No IP address is assigned to the cluster, so there's no IP Address Resource in the cluster core resource group.

  • Кластеру не назначено сетевое имя, поэтому в группе ресурсов ядра кластера отсутствует ресурс "Сетевое имя".No network name is assigned to the cluster, so there's no Network Name Resource in the cluster core resource group.

  • Имя кластера не зарегистрировано в DNS, и его имя не разрешается в сети.The name of the cluster isn't registered in DNS and the cluster name isn't resolvable on the network.

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

  • Вы не можете управлять отказоустойчивым кластером Windows с помощью средства управления отказоустойчивым кластером.You can't manage the Windows failover cluster using the Failover Cluster Management tool. Вместо этого необходимо использовать Windows PowerShell и запускать командлеты PowerShell для отдельных членов кластера.Instead, you need to use Windows PowerShell and you need to run the PowerShell cmdlets against the individual cluster members.

Exchange 2013 с пакетом обновления 1 (SP1) или более поздней версии на Exchange в Windows Server 2012 R2 или более поздней версии можно создать группу обеспечения доступности баз данных без точки административного доступа кластера.Exchange 2013 SP1 or later running on Exchange on Windows Server 2012 R2 or later enables you to create a DAG without a cluster administrative access point. Дополнительные сведения см. в статье Создание DAG и Создание группы обеспечения доступности баз данных.For more information, see Creating DAGs and Create a database availability group.