Изменение высокой доступности и устойчивости сайтов по сравнению с предыдущими версиями

Область действия: Exchange Server 2013 с пакетом обновления 1 (SP1)

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

  • Сокращение количества операций ввода-вывода в секунду в Exchange 2010. Это позволяет максимально эффективно использовать большие диски с точки зрения емкости и операций ввода-вывода в секунду.

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

  • Управляемое хранилище: Управляемое хранилище — это имя перезаписанного процесса хранилища информации в Exchange 2013. Новое управляемое хранилище написано на языке C# и тесно интегрировано со службой репликации Microsoft Exchange (MSExchangeRepl.exe), чтобы обеспечить более высокий уровень доступности за счет повышения устойчивости.

  • Поддержка нескольких баз данных на диск: Exchange 2013 включает усовершенствования, позволяющие поддерживать несколько баз данных (комбинации активных и пассивных копий) на одном диске, тем самым максимально эффективно используя большие диски с точки зрения емкости и операций ввода-вывода в секунду.

  • AutoReseed: возможность автоматического изменения размера позволяет быстро восстановить избыточность базы данных после сбоя диска. В случае сбоя диска копия базы данных, сохраненная на диске, копируется из активной копии базы данных на резервный диск того же самого сервера. Если на отказавшем диске хранилось несколько копий баз данных, их можно автоматически повторно заполнить на свободном диске. Это ускоряет повторное заполнение, так как активные базы данных, скорее всего, располагаются на нескольких серверах и данные копируются параллельно.

  • Автоматическое восстановление после сбоев хранилища. Эта функция продолжает инновации, появившиеся в Exchange 2010, чтобы позволить системе восстанавливаться после сбоев, влияющих на устойчивость или избыточность. Помимо поведения при проверке ошибок Exchange 2010, Exchange 2013 включает дополнительные поведения восстановления в течение длительного времени ввода-вывода, чрезмерное потребление памяти MSExchangeRepl.exe и серьезные случаи, когда система находится в таком плохом состоянии, что потоки не могут быть запланированы.

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

  • Усовершенствования оповещений об одном копировании. Оповещение об одном копировании, появившихся в Exchange 2010, больше не является отдельным запланированным сценарием. Теперь оно интегрируется с компонентами управляемой доступности системы и входит в состав Exchange.

  • Автоматическая настройка сети DAG: сети DAG могут быть автоматически настроены системой на основе параметров конфигурации. Помимо вариантов ручной настройки, группы обеспечения доступности баз данных могут различать сети MAPI и сети репликации, а также автоматически настраивать сети групп.

Снижение IOPS на Exchange 2010

В Exchange 2010 пассивные копии базы данных имеют низкую глубину контрольных точек, которая необходима для быстрой отработки отказа. Кроме того, пассивная копия выполняет агрессивное предварительное чтение данных, чтобы справиться с глубиной контрольных точек в 5 МБ. В результате при использовании низкой глубины контрольных точек и выполнении этих агрессивных операций предварительного чтения количество операций ввода-вывода в секунду для пассивной копии базы данных равнялось значению для активной копии в Exchange 2010.

В Exchange 2013, система способна предоставить быструю обработку ситуаций отказа при использовании большой глубины контрольной точки для пассивной (100 Мбайт). Поскольку пассивные копии имеют глубину контрольных точек 100 МБ, они повторно настроены на менее агрессивное выполнение операций. В результате при увеличении глубины контрольных точек и повторной настройки агрессивных операций предварительного считывания количество операций ввода-вывода в секунду для пассивной копии составляет около 50 % от этого значения для активной копии Exchange 2013.

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

Было внесено еще одно изменение, относящееся к процессу фонового обслуживания баз данных (BDM). BDM теперь обрабатывает около 1-2 МБ в секунду для каждой копии.

В результате всех этих изменений Exchange 2013 обеспечивает существенное сокращение количества операций ввода-вывода по сравнению с Exchange 2010.

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

Управляемая доступность — это интеграция встроенного активного мониторинга и платформы высокой доступности Exchange 2013. Благодаря управляемой доступности система может определить время для отработки отказа базы данных на основе работоспособности службы. Управляемая доступность — это внутренняя инфраструктура, развернутая в ролях серверов клиентского доступа и почтовых ящиков в Exchange 2013. Управляемая доступность состоит из трех основных асинхронных компонентов, которые постоянно работают. Первый компонент — это механизм проверки, ответственный за выполнение измерений на сервере и сбор данных. Результаты этих измерений поступают во второй компонент — монитор. Монитор содержит всю используемую системой бизнес-логику на основе того, что считается работоспособным состоянием собранных данных. Подобно подсистеме распознавания шаблонов, монитор ищет различные шаблоны среди всех собранных измерений, а затем принимает решение, можно ли считать компонент работоспособным. Наконец, существует подсистема ответа, которая несет ответственность за действия по восстановлению. Если что-то не работает, первое действие — попытка восстановления соответствующего компонента. Это могут быть действия по многоуровневому восстановлению (например, сначала последовательно перезапускаются пул приложений, служба и сервер, а в самом конце сервер переводится в автономный режим и не может принимать трафик). Если действия по восстановлению не помогают, система уведомляет о проблеме оператора-человека через журнал.

Управляемая доступность реализуется в форме две службы:

  • Служба Диспетчера работоспособности Exchange (MSExchangeHMHost.exe): это процесс контроллера, используемый для управления рабочими процессами. Он используется для построения, выполнения, запуска и остановки рабочих процессов по мере необходимости. Он также используется для восстановления рабочих процессов при сбоях, чтобы рабочие процессы не становились единственной точкой отказа.

  • Рабочий процесс Диспетчера работоспособности Exchange (MSExchangeHMWorker.exe): это рабочий процесс, который отвечает за выполнение задач среды выполнения.

Управляемая доступность использует постоянное хранилище для выполнения своих функций:

  • XML-файл конфигурации используются для инициализации определений рабочих элементов при запуске рабочего процесса.

  • Реестр используется для хранения данных среды выполнения, например закладок.

  • Инфраструктура журнала событий канала Crimson используется для хранения результатов рабочих элементов.

Дополнительные сведения о высоком уровне доступности см. в разделе Управляемая доступность.

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

Все предыдущие версии Exchange Server, от Exchange Server 4.0 до Exchange Server 2010, поддерживали запуск единого экземпляра процесса хранилища данных (Store.exe) на роли сервера почтовых ящиков. В этом едином хранилище размещены все базы данных на сервере: активные, пассивные, изолированные и базы данных восстановления. В предыдущих архитектурах Exchange существует незначительная изоляция между различными базами данных, размещенными на сервере почтовых ящиков. Проблемы с единой базой данных почтовых ящиков могут негативно сказаться на всех остальных базах данных, а аварийное завершение в результате повреждения почтового ящика может повлиять на работу служб для всех пользователей, базы данных которых размещены на таком сервере.

Еще одна трудность при использовании единого экземпляра хранилища в предыдущих версиях Exchange состоит в том, что расширенный обработчик хранилищ (ESE) хорошо масштабируется для 8–12 процессорных ядер, а кроме этого взаимодействие между процессорами и проблемы синхронизации кэша могут привести к отрицательному масштабированию. Учитывая современные серверы, на которых доступно более 16 основных систем, это приведет к административной проблеме управления сходством 8–12 ядер для ESE и использованием других ядер для процессов, отличных от Store (например, Помощники, Search Foundation, управляемая доступность и т. д.). Кроме того, предыдущая архитектура ограничивала увеличение масштаба для процессов хранилища.

За многие годы процесс Store.exe был значительно усовершенствован, как и Exchange Server, но в конечном итоге его масштабируемость как одного процесса ограничена и представляет единственную точку отказа. Из-за этих ограничений в Exchange 2013 процесс Store.exe заменен на управляемое хранилище.

Дополнительные сведения см. в разделе Управляемое хранилище.

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

Хотя улучшения системы хранения в Exchange 2013 в основном предназначены только для конфигураций групп дисков (JBOD), они доступны для использования во всех поддерживаемых конфигурациях хранилища. Одной из таких функций является возможность размещения нескольких баз данных на одном и том же томе. Эта функция предназначена для больших дисков о Exchange оптимизация. Эти улучшения позволяют использовать большие диски по емкости с гораздо большей эффективностью в показателях емкости, количества операций ввода-вывода в секунду и времени повторного заполнения, а также призваны устранить следующие проблемы, связанные с выполнением задач в конфигурации хранилища JBOD.

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

  • Операции повторного заполнения должны быть быстрыми и надежными.

  • Хотя емкость хранилища увеличивается, количество операций ввода-вывода в секунду не растет.

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

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

  • Гибкость ограничивается для восстановления в условиях нехватки места на диске.

Продолжается тенденция увеличения емкости хранилища: скоро в продаже появятся диски на 8 ТБ. Согласно рекомендациям по максимальному размеру данных Exchange (2 ТБ), при использовании дисков на 8 ТБ теряется более 5 ТБ дискового пространства. Одним из решений является увеличение размера баз данных, но это препятствует управляемости, так как оно приводит к длительному повторному хранимому времени, в том числе в некоторых случаях, неуправляемым временем обработки и надежность копирования этого объема данных по сети скомпрометирована.

Кроме того, в модели Exchange 2010 диск, на котором хранится пассивная копия, используется не в полной мере в плане количества операций ввода-вывода в секунду. В случае с изолированной пассивной копией, диск не только используется недостаточно эффективно с точки зрения количества операций ввода-вывода в секунду, но и является асимметричным в плане размера относительно дисков, используемых для хранения активных и неизолированных пассивных копий.

Продолжая давнюю практику, мы оптимизировали Exchange 2013, что позволяет более эффективно использовать большие диски (8 ТБ) в конфигурации JBOD. Поскольку в Exchange 2013 на одном диске хранится несколько баз данных, на дисках одного размера можно хранить несколько (в том числе изолированных) копий баз данных. Цель состоит в том, чтобы максимально способствовать распределению пользователей по существующим томам и обеспечить симметричный дизайн, при котором во время обычных операций в каждом члене группы обеспечения доступности баз данных размещается ряд активных, пассивных и дополнительных изолированных копий в одном томе.

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

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

Приведенная выше конфигурация обеспечивает симметричный дизайн. Все четыре базы данных четырех серверах установлены одинаковые все размещены на одном диске на каждый сервер. Ключевой момент — количество копий каждой имеющейся базы данных равно числу копий базы данных на диск. В приведенном выше примере существует четыре копии каждой базы данных: одна активная копия и две пассивных копии, одной изолированной копии. Поскольку каждая база данных имеет четыре копии, правильной считается конфигурация с четырьмя копиями на том. Кроме того, приоритет активации сбалансирован в группе обеспечения доступности баз данных и на каждом сервере. Например, активная, первая пассивная, вторая пассивная и изолированная копии будут иметь значение приоритета активации 1, 2, 3 и 4 соответственно.

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

По мере увеличения размера базы данных повторное ее заполнение занимает больше времени. Например, для повторного копирования базы данных размером 2 терабайта может потребоваться 23 часа, а для базы данных размером 8 терабайт — до 93 часов (почти четыре дня). В обоих случаях повторное заполнение выполняется со скоростью около 20 МБ в секунду. Обычно это значит, что очень большую базу данных невозможно заполнить в разумный срок.

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

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

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

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

  • Копии базы данных должны иметь одних соседей. (Например, они все должны размещаться на одном диске на каждом сервере).

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

AutoReseed

Автоматическое повторное заполнение, или AutoReseed — это функция, которая заменяет обычное действие администратора в ответ на отказ диска, повреждение базы данных или другую проблему, требующую повторного заполнения копии базы данных. Функция Autoreseed была создана для автоматического восстановления избыточности базы данных после сбоя диска с помощью запасных дисков, настроенных в системе.

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

Автоматическое восстановление после сбоев для хранения

Автоматическое восстановление после сбоев на хранение в Exchange 2010 нововведение позволяющий системе восстановления после сбоев, затрагивающих избыточность и отказоустойчивость. Помимо поведения при проверке ошибок Exchange 2010, Exchange 2013 включает дополнительные поведения восстановления в течение длительного времени ввода-вывода, чрезмерное потребление памяти службой репликации Microsoft Exchange (MSExchangeRepl.exe) и серьезные случаи, когда потоки не могут быть запланированы.

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

Имя Проверка Действие Порог
Обнаружение зависания ввода-вывода базы данных ESE Проверка незавершенных операций ввода-вывода с помощью обработчика ESE Создание элемента сбоя в канале Crimson для перезапуска сервера 240 с
Периодический сигнал канала элемента сбоя Обеспечение возможности записи и чтения отказавших элементов в канале Crimson Служба репликации сервера периодического сигнала канала Crimson на сбои и перезапуск 30 с
Периодический сигнал системного диска Проверка состояния диска серверной системы Периодическая отправка небуферизованных операций ввода-вывода на системный диск; перезапуск сервера по истечении времени ожидания периодического сигнала 120 с

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

Имя Проверка Действие Порог
Неправильное состояние системы Нет потоков, включая неуправляемые потоки, которые можно запланировать Перезапустите сервер 302 с
Длительное время операций ввода-вывода Измерения задержки операций ввода-вывода Перезапустите сервер 41 с
Использование памяти службы репликации Измерение рабочего множества MSExchangeRepl.exe
  1. Занесите событие 4395 в журнал канала Crimson с запросом на прекращение работы службы
  2. Завершите работу MSExchangeRepl.exe
  3. Если при завершении работы службы возникает ошибка, перезапустите сервер
4 гигабайта (ГБ)
Системное событие 129 (сброс шины) Проверка наличия записи о событии 129 в журнале системных событий Перезапустите сервер Время события
Зависание базы данных кластера Обновления диспетчера глобального обновления заблокированы Перезапустите сервер Время события

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

Улучшения изолированной копии включают в себя интеграцию изолированной копии с функцией "страховочной сети" и автоматическое воспроизведение файлов журнала в определенных сценариях. "Страховочная сеть" — это функция транспорта, которая заменяет функцию Exchange 2010, которая называлась транспортной корзиной. Функция "страховочной сети" сходна с транспортной корзиной в том, что является очередью доставки, сопоставленной с транспортной службой на сервере почтовых ящиков. Магазины копий сообщения в этой очереди, были успешно переданы на активной базы данных почтовых ящиков на сервере почтовых ящиков. У каждой активной базы данных почтовых ящиков есть своя очередь на сервере почтовых ящиков, в которой хранятся копии доставленных сообщений. Можно указать, как долго функция "страховочной сети" хранит копии успешно доставленных сообщений до истечения их срока действия и автоматического удаления.

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

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

Теперь изолированные копии могут позаботиться о себе сами, вызывая автоматическое воспроизведение журналов в определенных сценариях:

  • При достижении порога нехватки места на диске.

  • Если изолированная копия физически повреждена и требуется исправить страницу.

  • При наличии менее трех доступных работоспособных копий (активных или пассивных; изолированные копии не учитываются) в течение более 24 часов.

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

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

Set-DatabaseAvailabilityGroup <DAGName> -ReplayLagManagerEnabled $true

После включения воспроизведение происходит при наличии менее трех копий. Можно изменить значение по умолчанию, равное 3, изменив следующее значение DWORD в реестре.

HKLM\Software\Microsoft\ExchangeServer\v15\Replay\Parameters\ReplayLagManagerNumAvailableCopies

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

HKLM\Software\Microsoft\ExchangeServer\v15\Replay\Parameters\ReplayLagLowSpacePlaydownThresholdInMB

После настройки какого-либо из этих параметров реестра перезапустите службу управления DAG Microsoft Exchange, чтобы изменения вступили в силу.

В качестве примера рассмотрим среду, где у базы данных есть 4 копии (3 копии с высоким уровнем доступности и 1 изолированная копия), а для параметра ReplayLagManagerNumAvailableCopies используется значение по умолчанию. Если неизолированная копия по какой-либо причине недоступна (например, приостановлена и т. д.), то изолированная копия автоматически воспроизводит файлы журналов через 24 часа.

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

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

В Exchange 2010 представлен сценарий CheckDatabaseRedundancy.ps1. Он позволяет отследить избыточность реплицированных баз данных почтовых ящиков путем проверки наличия по крайней мере двух настроенных, работоспособных и актуальных копий, а также оповещает администратора с помощью журнала событий, если существует только одна работоспособная копия реплицированной базы данных. В этом случае при определении избыточности учитываются и активная, и пассивные копии.

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

  • Ошибка репликации активной копии в любую пассивную копию.

  • Сбой всех пассивных копий, включая состояния FailedAndSuspended и Failed, а также работоспособные состояния, когда копия не принимает участия в копировании или воспроизведении журналов. Обратите внимание, что изолированные копии не считаются просроченными, если не прошел десятиминутный период задержки при воспроизведении их журналов.

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

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

Встроенная функция по-прежнему оповещает администраторов с помощью уведомлений журнала событий, а чтобы различать оповещения Exchange 2013 и Exchange 2010, Exchange 2013 использует следующие коды событий:

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

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

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

Автоматическая настройка сети DAG

Сеть DAG состоит из одной или нескольких подсетей, используемых для трафика репликации или трафика MAPI. Каждая группа DAG содержит максимум одну сеть MAPI и ни одной или несколько сетей репликации. В Exchange 2010 начальные сети DAG (например, DAGNetwork01 и DAGNetwork02) были созданы системой на основе подсетей службы кластеров. В средах с несколькими сетями, в которых интерфейсы указанной сети (например, сети MAPI) располагались в одной подсети, администратору требовалось выполнить дополнительную незначительную настройку. Однако в средах, в которых интерфейсы указанной сети находились в нескольких подсетях, администратору приходилось выполнять задачу, известную как свертывание сетей группы обеспечения доступности баз данных.

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

Кроме того, теперь по умолчанию сетями DAG автоматически управляет система. Чтобы просмотреть свойства сети DAG с помощью Центра администрирования Exchange (EAC), необходимо настроить DAG для управления сетью вручную, изменив свойства DAG с помощью EAC или с помощью командлета Set-DatabaseAvailabilityGroup , чтобы задать для параметра ManualDagNetworkConfiguration Trueзначение .

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

Выбор оптимальной копии (BCS) — это внутренний алгоритм поиска наилучшей копии отдельной базы данных для активации при наличии списка потенциальных копий, их работоспособности и состояния. Активный диспетчер выбирает лучшую доступную (и незаблокированную) копию в качестве новой активной копии базы данных, если существующая активная копия базы данных не работает или администратор выполняет переключение без целевой точки. В Exchange 2010 процесс BCS оценивал ряд свойств всех копий баз данных, чтобы определить "оптимальную" для активации копию. К ним относятся:

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

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

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

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

В Exchange 2013 активный диспетчер выполняет одинаковые проверки и этапы BCS для определения работоспособности репликации, но теперь он также использует ограничение в порядке убывания состояний работоспособности. В результате таких изменений алгоритм BCS теперь называется и выбором оптимальной копии и сервера (BCSS).

BCSS включает несколько новых проверок работоспособности, которые являются частью встроенных управляемых компонентов мониторинга доступности в Exchange 2013. Активный диспетчер теперь выполняет четыре новых дополнительных проверки (перечисленных ниже в порядке выполнения).

  1. Все работоспособно: проверяет наличие сервера, на котором размещена копия затронутой базы данных со всеми компонентами мониторинга в работоспособном состоянии.

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

  3. Все лучше, чем источник: проверяет наличие сервера, на котором размещена копия затронутой базы данных с компонентами мониторинга в состоянии, которое лучше, чем текущий сервер, на котором размещена затронутая копия.

  4. То же, что и источник: проверяет наличие на сервере, на котором размещена копия затронутой базы данных с компонентами мониторинга в состоянии, которое совпадает с текущим сервером, на котором размещена затронутая копия.

Если BCSS запускается в результате отработки отказа, которая инициируется компонентом мониторинга управляемой доступности (например, с помощью отвечающего устройства отработки отказов), применяется дополнительное принудительное ограничение, согласно которому работоспособность компонента целевого сервера должна превышать работоспособность компонента сервера, на котором выполнялась отработка отказа. Например, если сбой Outlook Web App инициирует отработку отказа управляемой доступности с помощью отвечающего средства отработки отказа, BCSS должен выбрать сервер, на котором размещена копия затронутой базы данных, на которой Outlook Web App работоспособен.

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

Накопительный пакет обновления 2 (CU2) для окончательной первоначальной версии (RTM) Exchange 2013 содержит новую службу на серверах почтовых ящиков, являющихся членами DAG. Данная служба называется службой управления DAG Microsoft Exchange (MSExchangeDAGMgmt). Эта служба включает внутреннюю функцию мониторинга DAG, которая ранее выполнялась в службе репликации Microsoft Exchange (MSExchangeRepl).

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

Всем группам обеспечения доступности баз данных под управлением Windows Server 2008 R2 или Windows Server 2012 требуется по крайней мере один IP-адрес в каждой подсети, включенной в сеть MAPI. IP-адреса, назначенные группе обеспечения доступности баз данных, используются кластером этой группы с административной точкой доступа кластера (которая также называется сетевым именем кластера), чтобы включить разрешение имен и подключение к кластеру (или, что более точно, подключение к элементу кластера, который в настоящее время владеет группой ресурсов ядра кластера) с использованием имени кластера. Windows Server 2012 R2 позволяет создать отказоустойчивый кластер без административной точки доступа. Отказоустойчивые кластеры Windows без административных точек доступа отличаются приведенными ниже характеристиками.

  • Кластеру не назначен IP-адрес, поэтому в группе ресурсов ядра кластера отсутствует ресурс "IP-адрес".

  • Кластеру не назначается сетевое имя, поэтому в группе основных ресурсов кластера отсутствует ресурс "Сетевое имя".

  • Имя кластера не зарегистрировано в DNS, поэтому не разрешается в сети.

  • В Active Directory не создается объект имени кластера (CNO).

  • Отказоустойчивым кластером Windows невозможно управлять с помощью средства управления отказоустойчивым кластером. Управлять им нужно с помощью Windows PowerShell, а командлеты Windows PowerShell должны выполняться в отношении отдельных элементов кластера.

При запуске на Windows Server 2012 R2 или более поздней версии пакет обновления 1 (SP1) для Exchange 2013 и более поздних версий позволяет создать DAG без точки административного доступа кластера. Вы можете создать DAG без точки административного доступа с помощью Центра администрирования Exchange или оболочки. Дополнительные сведения см. в разделе "Создание групп доступности daG и создание группы доступности базы данных".