Запланированные и незапланированные отключения

 

Применимо к: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007

Последнее изменение раздела: 2007-10-29

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

Запланированные отключения

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

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

Примечание.

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

Административные задачи

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

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

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

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

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

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

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

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

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

Восстановление действия репликации после плановой остановки

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

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

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

Незапланированные отключения

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

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

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

При переходе на другой ресурс кластерная непрерывная репликация всегда будет делать сервер почтовых ящиков активным на оставшемся пассивном узле. Управление системой связано с тем, будут ли базы данных подключены на этом, теперь активном, узле. Кластерная непрерывная репликация обеспечивает административное управление для определения необходимости подключения баз данных. Значение по умолчанию — «Best availability». В этой позиции система будет автоматически подключать все базы данных, синхронизированные с предыдущей активной производственной базой данных. Этот атрибут позволяет больше вариантов несогласованности двух копий. Значение «Good availability» переведет базу данных в оперативный режим, если во время создания нового журнала последний созданный журнал был реплицирован. Атрибут «Lossless» гарантирует, что копия не будет переведена в оперативный режим, если не подтвердится отсутствие потерь данных. Если используется атрибут «Lossless», автоматическое восстановление произойдет только при возобновлении работоспособности исходного сервера и доступности всех неповрежденных данных журналов.

Примечание.
Использование параметра «Lossless» может привести к длительным отключениям. Администраторы могут использовать параметр Lossless, а затем принять решение о необходимости подключения баз данных. Этот параметр может привести к длительным отключениям при сбое.

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

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

Административное управление

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

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

  Примечание.

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

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

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

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