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

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

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

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

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

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

Интерфейс управления командной строки Cluster.exe и графический интерфейс пользователя для администратора кластера поддерживают перемещение кластерного сервера почтовых ящиков. Использование этих методов запускает логику очистки репликации. Однако рекомендуется не использовать эти методы по следующим причинам:

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

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

• Запланированное отключение успешно завершилось без сбоев во время перемещения, связанного с запланированным отключением, и все базы данных были успешно возвращены в оперативный режим. В этом случае администратор выполнил запланированное отключение способом, гарантирующим наличие на обоих узлах согласованных групп хранения и баз данных. В результате узел сможет приступить к работе и сразу продолжить репликацию данных. Копия может быть доведена до актуального состояния посредством воспроизведения журналов. Никаких специальных действий выполнять не требуется.
  
  
• Запланированное отключение было лишь частично успешным, либо некоторые базы данных были повреждены до запланированного отключения. В этом случае во время запланированного отключения невозможно было убедиться, что все журналы в источнике были доступны для целевого объекта до подключения им своих баз данных. Обычно данная ситуация возникает в результате сбоя до запланированного отключения или позже в ходе выполнения операции запланированного отключения. Поэтому исходная и целевая базы данных не согласованы. В некоторых случаях кластерная непрерывная репликация автоматически устраняет несогласованность. В этом случае репликация запускает и обрабатывает все доступные журналы. Если репликация не может завершить автоматическое восстановление, копия будет помечена как поврежденная, и будет создано событие, описывающее неисправность. Если предположить, что хранилище является жизнеспособным, основное действие восстановления запишет в копию стартовые значения. Дополнительные сведения об исправлении этих неполадок см. в разделе Инициализация копии непрерывной репликации кластера.
  
  

Для управления серверами в случаях незапланированного отключения используются средства администрирования. Кластерная непрерывная репликация обеспечивает серверы почтовых ящиков атрибутом, который можно использовать для определения поведения при восстановлении после незапланированных отключений. Атрибут AutoDatabaseMountDial может принимать три значения: Lossless, Good availability и Best availability.

• Lossless   Значение «Lossless» не допускает потери файлов журнала. Если атрибут имеет значение «Lossless», в большинстве случаев перед подключением баз данных система ожидает возвращения неисправного узла в оперативный режим. Даже в таком случае система должна восстановиться, сохранив доступными и неповрежденными все журналы. После сбоя пассивный узел становится активным, а служба банка данных Microsoft Exchange переходит в оперативный режим. Затем он проверяет возможность подключения баз данных без потерь данных. Если это возможно, то базы данных подключаются. В противном случае система периодически пытается скопировать журналы. Если сервер возвращается с неповрежденными журналами, эти попытки завершатся успешно и базы данных будут подключены. Если сервер возвращается без неповрежденных журналов, оставшиеся журналы не будут доступны и затронутые базы данных не будут подключены.
  
  

  Примечание.

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

• Good availability   Значение «Good availability» допускает потерю трех файлов журнала. Значение «Good availability» обеспечивает полностью автоматическое восстановление при обычной работе репликации и стандартном времени создания журналов репликации.
  
  
• Best availability   Значение «Best availability» допускает потерю шести файлов журнала (значение по умолчанию). Это значение атрибута похоже на значение «Good availability», но позволяет выполнять автоматическое восстановление при несколько больших задержках репликации. Таким образом, после перехода на другой ресурс при сбое новый активный узел может иметь несколько большее отставание от старого активного узла, что повышает вероятность возникновения в базе данных отклонения, для устранения которого потребуется полное повторное заполнение.
  
  

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