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

Область применения: 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 Health Manager Service (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 МБ в секунду. Обычно это значит, что очень большую базу данных невозможно заполнить в разумный срок.

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

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

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

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

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

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

AutoReseed

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

Дополнительные сведения см. в разделе AutoReseed. Подробные инструкции по настройке функции AutoReseed см. в разделе Configure AutoReseed for a database availability group.

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

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

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

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

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

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

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

С появлением Safety Net активация отстающей копии базы данных становится проще. Например, рассмотрим изолированную копию с 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 с помощью центра администрирования Exchange или командлета 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).

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

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

• Кластеру не назначен IP-адрес, и, следовательно, в группе основных ресурсов кластера нет ресурса IP-адреса.

• Кластеру не назначено сетевое имя, и, следовательно, в основной группе ресурсов кластера нет ресурса сетевого имени.

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

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

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

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