Как управлять копиями баз данных почтовых ящиков

Статья
04/04/2023

Область применения: Exchange Server 2013 г.

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

Управление копиями базы данных

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

Приостановка и возобновление работы копий базы данных

По ряду причин, таких как плановое обслуживание, может потребоваться приостановить и возобновить непрерывную репликацию для копии базы данных. Кроме того, для некоторых административных задач, таких как ввод, необходимо сначала приостановить копию базы данных. Рекомендуется приостановить все действия репликации при изменении пути к базе данных или ее файлам журнала. Действие копирования базы данных можно приостановить и возобновить с помощью EAC или командлетов Suspend-MailboxDatabaseCopy и Resume-MailboxDatabaseCopy в оболочке. Подробные инструкции по приостановке или возобновлению непрерывной репликации для копии базы данных см. в статье Приостановка или возобновление копирования базы данных почтового ящика.

Заполнение копии базы данных

Заполнение, также называемое обновлением, — это процесс, в котором база данных, пустая база данных или копия рабочей базы данных, добавляется в целевое расположение копии на другом сервере почтовых ящиков в том же daG, что и активная база данных. Эта база данных становится основной для копии, обслуживаемой сервером.

В зависимости от ситуации заполнение может быть автоматическим или ручным процессом, который вы инициируете. После добавления копия базы данных будет автоматически заполнена, если целевой сервер и его хранилище настроены правильно. Если вы хотите вручную заполнить копию базы данных и не хотите, чтобы при создании копии выполнялось автоматическое заполнение, можно использовать параметр SeedingPostponed при выполнении командлета Add-MailboxDatabaseCopy .

Копии базы данных редко требуют повторной вставки после начального заполнения. Но если требуется повторное выполнение или вы хотите вручную заполнить копию базы данных вместо того, чтобы система автоматически заполняла копию, эти задачи можно выполнить с помощью мастера обновления копирования базы данных почтовых ящиков в Центре администрирования Exchange или с помощью командлета Update-MailboxDatabaseCopy в оболочке. Подробное описание действий по заполнению копии базы данных см. в разделе Обновление копии базы данных почтовых ящиков.

После заполнения копии базы данных вручную репликация заполненной копии базы данных почтовых ящиков будет автоматически возобновлена. Если автоматическое возобновление репликации не требуется, необходимо использовать параметр ManualResume при запуске командлета Update-MailboxDatabaseCopy.

Выбор объекта заполнения

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

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

Выбор источника заполнения

Исправную копию базы данных можно использовать в качестве источника заполнения для дополнительной копии этой базы данных. Это может быть полезно, если группа доступности базы данных развернута в нескольких физических местоположениях. В качестве примера рассмотрим развертывание группы доступности базы данных из четырех участников, в которой два участника (MBX1 и MBX2) находятся в Москве, а другие два участника (MBX3 и MBX4) в Санкт-Петербурге. База данных почтовых ящиков с именем DB1 активна в MBX1, а пассивные копии DB1 расположены в MBX2 и MBX3. При добавлении копии DB1 в MBX4 вы можете использовать копию в MBX3 как источник для заполнения. При этом вы избегаете заполнения по каналу глобальной сети между Москвой и Санкт-Петербургом.

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

Используйте параметр SeedingPostponed при выполнении командлета Add-MailboxDatabaseCopy , чтобы добавить копию базы данных. Если параметр SeedingPostponed не используется , копия базы данных будет явно засеяна с использованием активной копии базы данных в качестве источника.
Можно указать исходный сервер, который нужно использовать в мастере копирования базы данных почтовых ящиков в Центре администрирования Exchange, или использовать параметр SourceServer при выполнении командлета Update-MailboxDatabaseCopy , чтобы указать нужный исходный сервер для заполнения. В предыдущем примере сервер MBX3 указан в качестве исходного сервера. Если параметр SourceServer не используется, копия базы данных будет явно засеяна из активной копии базы данных.

Заполнение и сети

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

Примечание.

Засеивание каталога индексов контекста возможно только по сети MAPI. Это верно, даже если вы используете -Network параметр в командлете Update-MailboxDatabaseCopy.

Чтобы указать сети, которые нужно использовать для заполнения, используйте параметр Network при выполнении командлета Update-MailboxDatabaseCopy и укажите сети DAG, которые вы хотите использовать. Если параметр Network не используется, система использует следующее поведение по умолчанию для выбора сети, используемой для операции заполнения:

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

Шифрование и сжатие данных настраивается на уровне группы DAG. Параметры по умолчанию используют шифрование и сжатие только для обмена данными в разных подсетях. Если исходный и целевой серверы находятся в разных подсетях и для группы DAG заданы значения параметров NetworkCompression и NetworkEncryption по умолчанию, вы можете переопределить эти значения, используя параметры NetworkCompressionOverride и NetworkEncryptionOverride соответственно при запуске командлета Update-MailboxDatabaseCopy.

Процесс заполнения

При запуске процесса заполнения с помощью командлетов Add-MailboxDatabaseCopy или Update-MailboxDatabaseCopy выполняются следующие задачи:

Свойства базы данных из Active Directory считываются для проверки указанной базы данных и серверов, а также для проверки того, что исходный и целевой серверы работают под управлением Exchange 2013, они оба являются членами одного daG и что указанная база данных не является базой данных восстановления. Также считываются пути к файлам базы данных.
Приготовления выполняются для проверки повторного заполнения из службы репликации Microsoft Exchange целевого сервера.
Служба репликации Microsoft Exchange на целевом сервере проверяет наличие базы данных и файлов журнала транзакций в каталогах файлов, считанных при проверке Active Directory на шаге 1.
Служба репликации Microsoft Exchange возвращает сведения о состоянии из целевого сервера в интерфейс администратора, в котором запущен командлет.
Если все предварительные проверки выполнены успешно, будет предложено подтвердить операцию перед продолжением. При подтверждении операции процесс продолжится. Если при предварительных проверках произошла ошибка, будет создан отчет об этой ошибке и произойдет сбой операции.
Операция заполнения начнется из службы репликации Microsoft Exchange целевого сервера.
Служба репликации Microsoft Exchange приостановит репликацию базы данных для активной копии базы данных.
Сведения о состоянии базы данных обновляются службой репликации Microsoft Exchange для отображения состояния заполнения.
Если на целевом сервере отсутствуют каталоги для файлов целевой базы данных и файлов журнала, они будут созданы.
Запрос на заполнение базы данных оправляется из службы репликации Microsoft Exchange на целевом сервере в службу репликации Microsoft Exchange на исходном сервере с помощью протокола TCP. Этот запрос и последующее подключения для заполнения базы данных выполняются в сети группы доступности базы данных, настроенной в качестве сети репликации.
Служба репликации Microsoft Exchange на исходном сервере запускает потоковую архивацию расширенного обработчика хранилищ (ESE) с помощью интерфейса службы банка данных Microsoft Exchange.
Служба банка данных Microsoft Exchange передает сведения базы данных в службу репликации Microsoft Exchange.
Сведения базы данных перемещаются из службы репликации Microsoft Exchange исходного сервера в службу репликации Microsoft Exchange целевого сервера.
Служба репликации Microsoft Exchange на целевом сервере записывает копию базы данных во временный каталог, расположенный в главном каталоге базы данных.
Операция потоковой архивации на исходном сервере заканчивается, когда достигается конец базы данных.
Операция записи завершается на целевом сервере, и база данных перемещается из каталога "temp-seeding" в конечное расположение. Каталог "temp-seeding" удаляется.
Служба репликации Microsoft Exchange на целевом сервере предоставляет запрос службе поиска Microsoft Exchange на подключение каталога индексов содержимого к копии базы данных, если она существует. Если существуют файлы каталога предыдущей копии базы данных с истекшим сроком действия, происходит сбой операции подключения, что приводит к необходимости репликации каталога с исходного сервера. Подобным образом, если каталог отсутствует в новом экземпляре копии базы данных на целевом сервере, требуется создать копию каталога. Служба репликации Microsoft Exchange указывает службе поиска Microsoft Exchange приостановить индексирование копии базы данных, пока новый каталог копируется из источника.
Служба репликации Microsoft Exchange на целевом сервере отправляет запрос на заполнение каталога службе репликации Microsoft Exchange на исходном сервере.
На исходном сервере служба репликации Microsoft Exchange запрашивает сведения о каталоге из службы поиска Microsoft Exchange и отправляет запрос на приостановку индексации.
Служба поиска Microsoft Exchange на исходном сервере возвращает сведения о каталоге из каталога поиска службе репликации Microsoft Exchange.
Служба репликации Microsoft Exchange на исходном сервере считывает файлы каталога из каталога.
Служба репликации Microsoft Exchange на исходном сервере перемещает данные каталога в службу репликации Microsoft Exchange на целевом сервере с помощью подключения в сети репликации. После считывания служба репликации Microsoft Exchange отправляет запрос на возобновление индексации исходной базы данных службе поиска Microsoft Exchange.
Если в папке на целевом сервере существуют файлы каталога, служба репликации Microsoft Exchange на целевом сервере удалит их.
Служба репликации Microsoft Exchange на целевом сервере записывает данные каталога во временный каталог CiSeed.Temp до полной передачи данных.
Служба репликации Microsoft Exchange перемещает все данные каталога в конечное местоположение.
Служба репликации Microsoft Exchange на целевом сервере возобновляет индексацию поиска в целевой базе данных.
Служба репликации Microsoft Exchange на целевом сервере возвращает уведомление о состоянии завершения.
Конечный результат операции проходит в интерфейс администратора, в котором был запущен командлет.

Настройка копий базы данных

Просмотреть информацию о конфигурации копии базы данных можно на ее странице Свойства в Центре администрирования Exchange. Вы можете просмотреть некоторые сведения о конфигурации, проверив на странице Свойства копию базы данных в EAC. Вы также можете использовать командлеты Get-MailboxDatabase и Set-MailboxDatabaseCopy в оболочке для просмотра и настройки параметров копирования базы данных, таких как время задержки воспроизведения, время усечения задержки и порядок предпочтений активации. в статье Настройка свойств копии базы данных почтовых ящиков.

Использование параметров задержки преобразования и задержки усечения

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

Время задержки преобразования

Время задержки воспроизведения — это свойство копии базы данных почтового ящика, указывающее время (в минутах) для задержки воспроизведения журнала для копии базы данных. Отсчет времени задержки воспроизведения начинается после репликации файла журнала в пассивную копию и успешного прохождения проверки. Задержка воспроизведения журналов в копию базы данных позволяет восстановить состояние базы данных в определенной точке времени в прошлом. Копия базы данных почтовых ящиков, для которой настроен интервал задержки воспроизведения больше 0, называется изолированной копией базы данных почтовых ящиков, или просто изолированной копией.

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

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

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

Отложенные копии могут заботиться о себе в Exchange 2013 при вызове автоматического воспроизведения журнала для воспроизведения файлов журнала в определенных сценариях:

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

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

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

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 часа.

Если вы решили использовать отстающие копии без включения ReplayLagManagerEnabled параметра, следует учитывать следующие последствия:

Существует настраиваемое администратором значение времени задержки преобразования, и по умолчанию оно отключено.
Для параметра времени задержки преобразования по умолчанию установлено значение 0 дней. Максимальное значение для этого параметра 14 дней.
Изолированные копии не считаются высокодоступными. Они разработаны для аварийного восстановления и защиты от логического повреждения хранилища.
Чем больше время задержки преобразования, тем дольше длится процесс восстановления базы данных. В зависимости от количества файлов журнала, которые необходимо преобразовать во время восстановления, и скорости, с которой оборудование их преобразовывает, восстановление базы данных может занять несколько часов.
Рекомендуется определить, критично ли использование изолированных копий для общей стратегии аварийного восстановления. Если их использование является критичным, рекомендуется использовать несколько изолированных копий или использовать резервный массив независимых дисков (RAID) для защиты отдельной изолированной копии при отсутствии нескольких изолированных копий. При потере или повреждении диска отложенная во времени точка не будет потеряна.
Отложенные копии не могут быть исправлены с помощью функции одностраничного восстановления ESE. Если при отложенной копии возникает повреждение страницы базы данных (например, ошибка -1018), ее придется повторно вставить (что приведет к потере отстающего аспекта копии).

Активация и восстановление отстающей копии базы данных почтового ящика — это простой процесс, если требуется, чтобы база данных воспроизводила все файлы журнала и делала копию базы данных актуальной. Если вы хотите воспроизвести файлы журнала до определенного момента времени, это более сложная операция, так как вы вручную управляете файлами журналов и запускаете Exchange Server служебных программ баз данных (Eseutil.exe).

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

Время задержки усечения

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

Копии базы данных и усечение журнала

Усечение журнала работает так же в Exchange 2013, как и в Exchange 2010. Поведение усечения зависит от параметров времени задержки преобразования и времени задержки усечения копии.

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

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

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

Файл журнала должен быть ниже контрольной точки для базы данных.
Время, прошедшее с момента создания файла журнала, должно превышать значение ReplayLagTime + TruncationLagTime.
Файл журнала должен быть усечен на активной копии.

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

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

Если включено свободное усечение, поведение усечения отличается. Каждая копия базы данных отслеживает собственное свободное место на диске и применяет свободное усечение, если свободное место заканчивается. Активная копия: самая старая пассивная копия базы данных (по дате воспроизведения журналов) игнорируется, усечение начинается со следующей самой старой пассивной копии. Глобальное усечение рассчитывается в активной копии базы данных. Пассивные копии будут пытаться выполнить решение об усечении, принятое для активной копии. Несмотря на значение имени MinCopiesToProtect, Exchange будет игнорировать только самый старый известный отставание на момент усечения. Для пассивной копии, если пространство становится небольшим, она независимо усекает свои файлы журнала с помощью настроенных параметров, описанных ниже.

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

Необходимое количество работоспособных копий, пороговое значение свободного места на диске и количество журналов для хранения — это настраиваемые параметры. По умолчанию порог свободного места на диске составляет 204800 МБ (200 ГБ), а количество журналов для хранения — 100 000 (100 ГБ) для пассивных копий и 10 000 (10 ГБ) для активных копий.

Включение свободного усечения и настройка параметров свободного усечения выполняется путем изменения реестра Windows в каждом элементе DAG. Существует три значения реестра, которые можно настроить, и все они хранятся в .HKLM\Software\Microsoft\ExchangeServer\v15\BackupInformation Ключ BackupInformation: следующие значения DWORD не существуют по умолчанию и должны быть созданы вручную. Значения реестра DWORD в разделе BackupInformation описаны в следующей таблице:

Значение реестра	Описание	Значение по умолчанию
LooseTruncation_MinCopiesToProtect	Этот раздел используется для включения свободного усечения. Он представляет собой количество пассивный копий, которые необходимо защитить от свободного усечения в активной копии базы данных. Если присвоить этому ключу значение 0, свободные усечения будут отключены.	0
LooseTruncation_MinDiskFreeSpaceThresholdInMB	Пороговое значение доступного места на диске (в МБ) для запуска свободных усечений. Если количество свободного места на диске падает ниже этого значения, происходит запуск свободных усечений.	Если этот параметр реестра не настроен, при свободном усечении используется параметр по умолчанию (200 ГБ).
LooseTruncation_MinLogsToProtect	Минимальное количество файлов журналов, сохраняемых в работоспособных копиях, к которым применяется усечение. Если данный параметр реестра настроен, его значение применяется к активным и пассивным копиям.	Если данный параметр реестра не настроен, используются значения по умолчанию (100 000 для пассивных копий базы данных и 10 000 для активных копий базы данных).

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

Политика активации базы данных

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

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

В каждом из указанных выше сценариев копии базы данных не должны автоматически активироваться системой. Чтобы предотвратить автоматическую активацию копии базы данных почтовых ящиков, можно настроить блокирование (приостановку) активации копии. Это позволяет системе обслуживать текущую базу данных с помощью доставки журнала и преобразования, но предотвращает автоматическую активацию и использование копии. Администратор должен вручную активировать заблокированные для активации копии. Политику активации базы данных можно настроить для всего сервера с помощью командлета Set-MailboxServer или отдельной копии базы данных с помощью командлета Set-MailboxDatabaseCopy , чтобы задать параметру DatabaseCopyAutoActivationPolicy значение Заблокировано.

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

Влияние перемещения почтовых ящиков на непрерывную репликацию

В интенсивно используемой базе данных почтовых ящиков с высокой скоростью создания журналов вероятность потери данных выше, если репликация в пассивные копии базы данных не успевает за созданием журналов. Скорость создания журналов возрастает при перемещении почтовых ящиков. Exchange 2013 включает API гарантии данных, который используется такими службами, как служба репликации почтовых ящиков Microsoft Exchange (MRS), для проверки работоспособности архитектуры копирования базы данных на основе значения параметра DataMoveReplicationConstraint , заданного системой или администратором. В частности, API Data Guarantee может использоваться для:

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

При выполнении API-интерфейса он возвращает следующие сведения о состоянии вызывающему приложению:

Повторная попытка. Указывает на наличие временных ошибок, которые препятствуют проверке условия в базе данных.
Удовлетворено. Означает, что база данных соответствует требуемым условиям или база данных не реплицируется.
NotSatisfied: означает, что база данных не соответствует требуемым условиям. Кроме того, вызывающему приложению предоставляется информация о причине возврата состояния NotSatisfied.

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

None: при создании базы данных почтовых ящиков это значение задается по умолчанию. Если задано это значение, условия интерфейса Data Guarantee API игнорируются. Этот параметр следует использовать только для баз данных почтовых ящиков, которые не реплицируются.
SecondCopy: это значение по умолчанию при добавлении второй копии базы данных почтовых ящиков. Если задано это значение, по крайней мере одна пассивная копия базы данных должна соответствовать условиям Data Guarantee API.
SecondDatacenter: если задано это значение, по крайней мере одна пассивная копия базы данных на другом сайте Active Directory должна соответствовать условиям API гарантии данных.
AllDatacenters: если задано это значение, по крайней мере одна пассивная копия базы данных на каждом сайте Active Directory должна соответствовать условиям API гарантии данных.
AllCopies: если задано это значение, все копии базы данных почтовых ящиков должны соответствовать условиям API гарантии данных.

Проверка работоспособности репликации

При выполнении Data Guarantee API для оценки работоспособности инфраструктуры копий баз данных, оцениваются несколько элементов.

Если для параметра DataMoveReplicationConstraint задано значение ...	Затем для данной базы данных...	Условия
`SecondCopy`	По крайней мере одна пассивная копия реплицированной базы данных должна соответствовать условиям в следующем столбце.	Пассивная копия базы данных должна: быть работоспособной; содержать очередь преобразования в течение 10 минут времени задержки преобразования; использовать очередь копирования длиной не менее 10 журналов; использовать среднюю очередь копирования длиной не менее 10 журналов. Средняя длина очереди копирования вычисляется на основе количества запросов состояния базы данных приложением.
`SecondDatacenter`	По крайней мере одна пассивная копия на другом сайте Active Directory должна соответствовать условиям в следующем столбце.
`AllDatacenters`	Активная копия должна быть подключена, а пассивная копия на каждом сайте Active Directory должна соответствовать условиям в следующем столбце.
`AllCopies`	Активную копию необходимо подключить, а все пассивные копии базы данных должны соответствовать условиям в следующем столбце.

Проверка очистки репликации

Data Guarantee API также можно использовать для проверки того, что требуемое число копий базы данных преобразовали необходимые журналы транзакций. Это делается за счет сравнения метки времени последнего преобразованного журнала с меткой времени вызывающей службы (в большинстве случаев это метка времени последнего файла журнала, который содержит необходимые данные), плюс дополнительные пять секунд (для учета рассогласования системного времени). Если метка времени воспроизведения больше метки времени фиксации, параметр DataMoveReplicationConstraint удовлетворяется. Если метка времени воспроизведения меньше метки времени фиксации, dataMoveReplicationConstraint не удовлетворяется.

Перед перемещением большого количества почтовых ящиков в базы данных репликации или из них в DAG рекомендуется настроить параметр DataMoveReplicationConstraint для каждой базы данных почтовых ящиков следующим образом:

Если вы развертываете...	Задайте для dataMoveReplicationConstraint значение...
Базы данных почтовых ящиков, которые не имеют каких-либо копий базы данных	`None`
Группа DAG на одном сайте Active Directory	`SecondCopy`
Группа DAG в нескольких центрах обработки данных с использованием растянутого сайта Active Directory	`SecondCopy`
DAG, который охватывает два сайта Active Directory, и у вас будут высокодоступные копии базы данных на каждом сайте.	`SecondDatacenter`
Группа DAG, в которую входят два сайта Active Directory, на втором сайте будут только изолированные копии базы данных	`SecondCopy` Это связано с тем, что Data Guarantee API не гарантирует фиксирование данных до воспроизведения файла журнала в копии базы данных и вследствие природы изолированной копии базы данных это ограничение не позволит выполнить запрос на перемещение, если значение ReplayLagTime этой изолированной копии базы данных меньше 30 минут.
Группа DAG, в которую входят три или больше сайтов Active Directory, при этом каждый сайт будет содержать копии базы данных с высокой доступностью	`AllDatacenters`

Балансировка копий баз данных

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

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

Сервер	Число активные базы данных	Число пассивные базы данных	Число подключенные базы данных	Список для подсчета приоритетов
EX1	5	11	5	4, 4, 3, 5
EX2	1	15	1	1, 8, 6, 1
EX3	12	4	12	13, 2, 1, 0
EX4	1	15	1	1, 1, 5, 9

В предыдущем примере для каждой базы данных существует четыре копии, и поэтому возможно только четыре значения для приоритета активации (1, 2, 3 или 4). В столбце Список для подсчета приоритетов приводится подсчет числа баз данных с каждым из этих значений. Например, на сервере EX3 имеется 13 копий баз данных с приоритетом активации 1, две копии с приоритетом 2, одна копия с приоритетом 3 и ни одной копии с приоритетом 4.

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

Вы можете использовать скрипт RedistributeActiveDatabases.ps1 для балансировки копий баз данных почтовых ящиков в группе обеспечения доступности баз данных. В этом сценарии базы данных перемещаются между своими копиями с целью попытки получения равных количеств подключенных баз данных на каждом сервере в группе DAG. При необходимости также выполняется попытка балансировки активных баз данных по сайтам.

В этом сценарии имеется два параметра для балансировки активных копий баз данных в группе DAG.

BalanceDbsByActivationPreference: если указан этот параметр, скрипт пытается переместить базы данных в наиболее предпочтительную копию (на основе предпочтений активации) без учета сайта Active Directory.
BalanceDbsBySiteAndActivationPreference: если указан этот параметр, скрипт пытается переместить активные базы данных в наиболее предпочтительную копию, а также пытается сбалансировать активные базы данных на каждом сайте Active Directory.

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

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

Сервер	Число активные базы данных	Число пассивные базы данных	Число подключенные базы данных	Список для подсчета приоритетов
EX1	4	12	4	4, 4, 4, 4
EX2	4	12	4	4, 4, 4, 4
EX3	4	12	4	4, 4, 4, 4
EX4	4	12	4	4, 4, 4, 4

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

В следующей таблице перечислены параметры скрипта RedistributeActiveDatabases.ps1.

Параметры сценария RedistributeActiveDatabases.ps1

Параметр	Описание
DagName	Указывает имя группы DAG, которую необходимо сбалансировать. Если этот параметр не указан, будет использоваться та группа обеспечения доступности баз данных, членом которой является данный локальный сервер.
BalanceDbsByActivationPreference	Указывает, что согласно сценарию базы данных должны перемещаться в их наиболее предпочтительную копию безотносительно сайта Active Directory.
BalanceDbsBySiteAndActivationPreference	При указании этого параметра в сценарии производится попытка переместить активные базы данных в их наиболее предпочтительную копию, а также сбалансировать активные базы данных в пределах каждого сайта Active Directory.
ShowFinalDatabaseDistribution	Указывает, что отчет по распределению текущей базы данных должен отображаться после перераспределения.
AllowedDeviationFromMeanPercentage	Указывает допустимую вариацию активных баз данных по сайтам, выраженную в процентах. Значение по умолчанию 20 %. Например, если между тремя сайтами было распределено 99 баз данных, то идеальным распределением будет по 33 базы данных на каждом сайте. Если допустимое отклонение составляет 20 %, то при выполнении сценария будет производиться попытка сбалансировать базы данных таким образом, чтобы количество баз данных на каждом сайте отклонялось не более чем на 10 % в ту или другую сторону от этого значения. 10 % от 33 составляют 3,3, это значение можно округлить до 4. Следовательно, в результате выполнения сценария на каждом сайте будет от 29 до 37 баз данных.
ShowDatabaseCurrentActives	Указывает, что в сценарии необходимо создать отчет для каждой базы данных с подробными сведениями о том, как перемещалась база данных и является ли она теперь активной в своей наиболее предпочтительной копии.
ShowDatabaseDistributionByServer	Указывает, что в сценарии необходимо создать отчет для каждого сервера со сведениями о распределении базы данных на нем.
RunOnlyOnPAM	Указывает, что сценарий должен выполняться только для того члена группы DAG, который имеет роль диспетчера PAM. В сценарии в таком случае проверяется, происходит ли его запуск из диспетчера PAM. Если это условие не выполнено, то происходит выход из сценария.
События LogEvents	Указывает, что в процессе выполнения сценария необходимо внести в журнал событие 4115 (MsExchangeRepl) со сводкой по действиям.
IncludeNonReplicatedDatabases	Указывает, что в сценарий во время определения способа перераспределения активных баз данных необходимо включить нереплицированные базы данных (базы данных без копий). Несмотря на то что нереплицированные базы данных перемещать невозможно, они могут влиять на распределение реплицированных баз данных.
Confirm	Переключатель Confirm можно использовать для отключения запросов на подтверждение, которые отображаются по умолчанию при запуске этого скрипта. Чтобы отключить запросы на подтверждение, используйте синтаксис -Confirm:$False. В синтаксисе необходимо использовать двоеточие ( : ).

Примеры RedistributeActiveDatabases.ps1

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

RedistributeActiveDatabases.ps1 -DagName DAG1 -ShowDatabaseDistributionByServer | Format-Table

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

RedistributeActiveDatabases.ps1 -DagName DAG1 -BalanceDbsByActivationPreference -Confirm:$False

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

RedistributeActiveDatabases.ps1 -DagName DAG1 -BalanceDbsByActivationPreference -ShowFinalDatabaseDistribution

Копии базы данных мониторинга

Копия базы данных является первой защитой при сбое, влияющем на активную копию базы данных. Поэтому крайне важно отслеживать работоспособность и состояние копий базы данных, чтобы убедиться, что они будут доступны при необходимости. Сведения о копии базы данных, в том числе длину очереди копирования, длину очереди воспроизведения, статус и информацию о состоянии индекса контента, можно просмотреть в Центре администрирования Exchange. Вы также можете использовать командлет Get-MailboxDatabaseCopyStatus в оболочке для просмотра различных сведений о состоянии копии базы данных.

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

Удаление копии базы данных

Копию базы данных можно удалить в любое время с помощью EAC или командлета Remove-MailboxDatabaseCopy в оболочке. После удаления копии базы данных необходимо вручную удалить все файлы журнала базы данных и транзакций на сервере, с которого была удалена база данных. Подробные инструкции по удалению копии базы данных см. в разделе Удаление копии базы данных почтового ящика.

Переключения базы данных.

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

Чтобы быстро определить, какой сервер является главным для базы данных почтовых ящиков, просмотрите правый столбец на вкладке Копии базы данных в Центре администрирования Exchange. Переключение можно выполнить с помощью ссылки Активировать в EAC или с помощью командлета Move-ActiveMailboxDatabase в оболочке.

Перед активацией пассивной копии будет выполнено несколько внутренних проверок:

Проверяется состояние копии базы данных. Если копия базы данных повреждена, переключение будет заблокировано. Это поведение можно переопределить и обойти проверку работоспособности с помощью параметра SkipHealthChecks командлета Move-ActiveMailboxDatabase . Этот параметр позволяет переместить активную копию в копию базы данных в состоянии сбоя.
Проверяется, является ли активная копия базы данных источником заполнения каких-либо пассивных копий базы данных. Если активная копия в данный момент используется как источник для заполнения, переключение блокируется. Это поведение можно переопределить и обойти проверку исходного кода с помощью параметра SkipActiveCopyChecks командлета Move-ActiveMailboxDatabase . Этот параметр позволяет переместить активную копию, используемую как источник заполнения. При применении этого параметра заполнение будет отменено и будет считаться неудачным.
Выполняется проверка значений длины очереди копирования и очереди преобразования копии базы данных на нахождение в пределах заданных критериев. Также выполняется проверка того, используется ли копия базы данных в качестве источника для заполнения. Если значения длины очередей не соответствуют заданным критериям или база данных является источником заполнения, переключение будет заблокировано. Это поведение можно переопределить и обойти эти проверки с помощью параметра SkipLagChecks командлета Move-ActiveMailboxDatabase . Этот параметр позволяет активировать копии, которые имеют значения очередей преобразования и копирования за пределами настроенных критериев.
Выполняется проверка состояния каталога поиска (индексов содержимого) для копии базы данных. Если каталог поиска устарел, неисправен или поврежден, переключение будет заблокировано. Это поведение можно переопределить и обойти проверку каталога поиска с помощью параметра SkipClientExperienceChecks командлета Move-ActiveMailboxDatabase . Этот параметр позволяет пропустить проверку работоспособности каталога поиска. Если каталог поиска для активируемой копии базы данных неисправен или нестабилен, и этот параметр используется для пропуска проверки работоспособности каталога и активации копии базы данных, необходимо повторно сканировать или заполнить каталог поиска.

При переключении базы данных вы также можете переопределить параметры набора номера подключения, настроенные для сервера, на котором размещается активируемая пассивная копия базы данных. Использование параметра MountDialOverride командлета Move-ActiveMailboxDatabase позволяет целевому серверу переопределить собственные параметры набора номера подключения и использовать параметры, заданные параметром MountDialOverride .

Дополнительные сведения о переключении копии базы данных см. в разделе Активация копии базы данных почтовых ящиков.

Поделиться через