Применимо к: Exchange Server 2010 SP1

Последнее изменение раздела: 2011-04-20

Мобильность базы данных — это новая архитектура в Microsoft Exchange Server 2010, которая отвергает концепцию групп хранения и разъединяет базу данных почтовых ящиков Exchange 2010 и сервер почтовых ящиков. Так как в Exchange 2010 удалены группы хранения, непрерывная репликация теперь выполняется на уровне баз данных. В Exchange 2010 журналы транзакций реплицируются на один или несколько серверов почтовых ящиков и преобразуются в одну или несколько копий базы данных почтовых ящиков, хранящихся на этих серверах. Некоторые понятия, используемые при непрерывной репликации Exchange Server 2007, сохранились в Exchange 2010. Например, понятия отклонения, использования автоматического подключения базы данных и использования общедоступных и частных сетей.

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

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

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

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

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

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

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

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

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

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

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

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

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

В Exchange 2007 с помощью непрерывной репликации можно заполнить только копию базы данных. Для этого необходимо скопировать активную копию базы данных. В Exchange 2010 исправную копию базы данных можно использовать в качестве источника заполнения для дополнительной копии этой базы данных. Это может быть полезно, если группа доступности базы данных развернута в нескольких физических местоположениях. В качестве примера рассмотрим развертывание группы доступности базы данных из четырех участников, в которой два участника (MBX1 и MBX2) расположены в Портлэнде, штат Орегон, а другие два участника (MBX3 и MBX4) — в Нью-Йорке. База данных почтовых ящиков с именем DB1 активна в MBX1, а пассивные копии DB1 расположены в MBX2 и MBX3. При добавлении копии DB1 к MBX4 можно использовать копию в MBX3 в качестве источника для заполнения. В этом случае можно избежать заполнения между Портландом и Нью-Йорком через глобальную сеть.

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

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

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

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

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

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

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

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

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

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

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

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

  1. Из Служба каталогов Active Directory считываются свойства базы данных, чтобы проверить указанные базы данных и серверы и убедиться, что исходный и целевой серверы используют Exchange 2010, являются участниками одной группы доступности базы данных, а также что указанная база данных не является базой данных восстановления. Также считываются пути к файлам базы данных.

  2. Приготовления выполняются для проверки повторного заполнения из службы репликации Microsoft Exchange целевого сервера.

  3. Служба репликации Microsoft Exchange на целевом сервере проверяет наличие базы данных и файлов журнала транзакций в каталогах файлов, считанных при проверке Служба каталогов Active Directory на шаге 1.

  4. Служба репликации Microsoft Exchange возвращает сведения о состоянии из целевого сервера в интерфейс администратора, в котором запущен командлет.

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

  6. Операция заполнения начнется из службы репликации Microsoft Exchange целевого сервера.

  7. Служба репликации Microsoft Exchange приостановит репликацию базы данных для активной копии базы данных.

  8. Сведения о состоянии базы данных обновляются службой репликации Microsoft Exchange для отображения состояния заполнения.

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

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

  11. Служба репликации Microsoft Exchange на исходном сервере запускает потоковую архивацию расширенного обработчика хранилищ (ESE) с помощью интерфейса службы банка данных Microsoft Exchange.

  12. Служба банка данных Microsoft Exchange передает сведения базы данных в службу репликации Microsoft Exchange.

  13. Сведения базы данных перемещаются из службы репликации Microsoft Exchange исходного сервера в службу репликации Microsoft Exchange целевого сервера.

  14. Служба репликации Microsoft Exchange на целевом сервере записывает копию базы данных во временный каталог, расположенный в каталоге основной базы данных с именем temp-seeding.

  15. Операция потоковой архивации на исходном сервере заканчивается, когда достигается конец базы данных.

  16. Операция записи завершается на целевом сервере и база данных перемещается из каталога «temp-seeding» в конечное местоположение. Каталог «temp-seeding» удаляется.

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

  18. Служба репликации Microsoft Exchange на целевом сервере отправляет запрос на заполнение каталога службе репликации Microsoft Exchange на исходном сервере.

  19. На исходном сервере служба репликации Microsoft Exchange запрашивает сведения о каталоге из службы поиска Microsoft Exchange и отправляет запрос на приостановку индексации.

  20. Служба поиска Microsoft Exchange на исходном сервере возвращает сведения о каталоге из каталога поиска службе репликации Microsoft Exchange.

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

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

  23. Если в папке на целевом сервере существуют файлы каталога, служба репликации Microsoft Exchange на целевом сервере удалит их.

  24. Служба репликации Microsoft Exchange на целевом сервере записывает данные каталога во временную папку CiSeed.Temp, пока данные не будут полностью перемещены.

  25. Служба репликации Microsoft Exchange перемещает все данные каталога в конечное местоположение.

  26. Служба репликации Microsoft Exchange на целевом сервере возобновляет индексацию поиска в целевой базе данных.

  27. Служба репликации Microsoft Exchange на целевом сервере возвращает уведомление о состоянии завершения.

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

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

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

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

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

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

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

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

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

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

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

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

  • В отличие от пассивной непрерывной репликации (SCR) в Exchange 2007 с жестко заданным значением задержки преобразования, равным 50 файлам журнала, для изолируемых копий не существует жестко заданного количества изолируемых файлов журнала. Вместо этого, существует настраиваемое администратором значение времени задержки преобразования и по умолчанию оно отключено.

  • Для параметра времени задержки преобразования по умолчанию установлено значение 0 дней. Максимальное значение для этого параметра — 14 дней.

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

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

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

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

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

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

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

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

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

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

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

  • Файл журнала должен иметь архив или циклическое ведение журнала должно быть включено.

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

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

  • Для всех других копий (неизолированных) необходимо воспроизвести файл журнала.

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

  • Файл журнала должен быть ниже контрольной точки для базы данных.

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

  • Файл журнала должен быть усечен на активной копии.

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

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

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

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

  • При выполнении обслуживания или обновления сервера.

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

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

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

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

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

Сервер Количество активных баз данных Количество пассивных баз данных Количество подключенных баз данных Количество отключенных баз данных Список для подсчета приоритетов

EX1

5

11

5

0

4, 4, 3, 5

EX2

1

15

1

0

1, 8, 6, 1

EX3

12

4

12

0

13, 2, 1, 0

EX4

1

15

1

0

1, 1, 5, 9

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

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

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

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

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

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

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

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

Сервер Количество активных баз данных Количество пассивных баз данных Количество подключенных баз данных Количество отключенных баз данных Список для подсчета приоритетов

EX1

4

12

4

0

4, 4, 4, 4

EX2

4

12

4

0

4, 4, 4, 4

EX3

4

12

4

0

4, 4, 4, 4

EX4

4

12

4

0

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

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

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

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

Скопировать код
RedistributeActiveDatabases.ps1 -DagName DAG1 -ShowDatabaseDistributionByServer | Format-Table

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

Скопировать код
RedistributeActiveDatabases.ps1 -DagName DAG1 -BalanceDbsByActivationPreference

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

Скопировать код
RedistributeActiveDatabases.ps1 -DagName DAG1 -BalanceDbsByActivationPreference -ShowFinalDatabaseDistribution

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

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

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

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

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

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

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

Можно быстро определить, какой сервер почтовых ящиков является текущим хозяином базы данных почтовых ящиков. Для этого необходимо просмотреть столбец Состояние копии во вкладке Копии базы данных в консоли управления Exchange. Только активная копия будет иметь состояние Подключено. Все другие копии базы данных будут отображать текущее состояние репликации для копии базы данных. Переключение можно выполнить с помощью мастера перемещения хозяина базы данных почтовых ящиков в консоли управления Exchange или с помощью командлета Move-ActiveMailboxDatabase в командной консоли Exchange.

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

  • Выполняется проверка состояния копии базы данных. Если копия базы данных находится в состоянии сбоя, переключение будет заблокировано. Такое поведение можно переопределить и обойти проверку работоспособности с помощью параметра SkipHealthChecks командлета Move-ActiveMailboxDatabase. Этот параметр позволяет переместить активную копию в копию базы данных в состоянии сбоя.

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

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

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

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