Работа с репликами в Hyper-V 3.0 (часть 6)

• Работа с репликами в Hyper-V 3.0 (часть 3)
• Работа с репликами в Hyper-V 3.0 (часть 4)
• Работа с репликами в Hyper-V 3.0 (часть 5)

Введение

В самом начале этой серии статей я объяснил, что реплики Hyper-V предоставляются в первую очередь как механизм для создания относительно актуальных копий виртуальных машин. Реплики не предоставляют возможности автоматического перехода на другой ресурс, которые вы получаете при развертывании настоящего кластера Hyper-V. Точно так же реплики Hyper-V не являются решением для обеспечения высокой доступности. Несмотря на это, реплики Hyper-V предоставляют некоторые ограниченные возможности аварийного восстановления. В этой статье я хочу завершить обсуждение реплик Hyper-V, показав, как использовать реплики Hyper-V для аварийного переключения.

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

Реплики Hyper-V обеспечивают два разных типа отработки отказа. Вы можете выполнить запланированную отработку отказа или выполнить незапланированную отработку отказа.

Выполнение запланированного аварийного переключения

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

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

Первым шагом в выполнении запланированного перехода на другой ресурс является проверка работоспособности процесса репликации. Самый простой способ сделать это — открыть диспетчер Hyper-V на сервере, на котором в данный момент размещена основная копия виртуальной машины. Оттуда вы должны выбрать виртуальную машину, а затем щелкнуть вкладку «Репликация» в нижней части экрана. Если в поле «Работоспособность репликации» указано состояние «Здорово», значит, все готово. В противном случае вам придется немного поработать, прежде чем выполнять отработку отказа.

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

Если состояние репликации имеет статус «Предупреждение», возможно, на самом деле у вас нет проблемы. Это особенно верно, если вы недавно восстановились после ошибки репликации. Hyper-V долго хранит статистику репликации. Поэтому, если ранее произошел сбой репликации, и вы с тех пор устранили проблему, вы можете увидеть состояние «Предупреждение». В такой ситуации предупреждение генерируется, потому что репликация вроде бы работает в данный момент, но в прошлом у нее были проблемы.

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

Вы можете сбросить статистику работоспособности репликации виртуальной машины, щелкнув правой кнопкой мыши виртуальную машину и выбрав Репликация | Просмотрите команды Replication Health из контекстных меню. Когда появится диалоговое окно «Работоспособность репликации», нажмите кнопку «Сбросить статистику», как показано на рисунке A. Если вы хотите сохранить текущую статистику перед ее удалением, вы можете сделать это, нажав кнопку «Сохранить как». Это позволит вам экспортировать статистику репликации в файл CSV.

Рисунок A: Если вы получаете предупреждение о репликации, рекомендуется сбросить статистику репликации, чтобы вы могли просмотреть самые последние данные о работоспособности репликации.

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

Рисунок B: Щелкните правой кнопкой мыши виртуальную машину и выберите Репликация | Запланированные команды аварийного переключения из контекстного меню.

На этом этапе вы увидите диалоговое окно, похожее на то, что показано на рис. C. В этом диалоговом окне объясняется, что процесс отработки отказа будет реплицировать любые изменения на основной виртуальной машине, которые еще не были реплицированы. Диалоговое окно также предоставляет список предварительных проверок и действий, которые должны быть выполнены в рамках процесса отработки отказа. Чтобы выполнить отработку отказа, убедитесь, что установлен флажок «Запустить реплику виртуальной машины после отработки отказа», а затем нажмите кнопку «Отработка отказа».

Рисунок C. Нажмите Failover, чтобы выполнить запланированную отработку отказа.

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

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

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

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

Чтобы выполнить незапланированный переход на другой ресурс, откройте диспетчер Hyper-V на сервере-реплике. Когда консоль откроется, щелкните правой кнопкой мыши виртуальную машину, для которой требуется выполнить отработку отказа, и выберите Репликация | Команды аварийного переключения из результирующих контекстных меню, как показано на рисунке D.

Рисунок D: Чтобы выполнить незапланированный переход на другой ресурс, откройте Диспетчер Hyper-V на сервере-реплике, щелкните правой кнопкой мыши виртуальную машину, для которой требуется выполнить переход на другой ресурс, и выберите Репликация | Команды аварийного переключения из контекстного меню.

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

Вывод

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

• Работа с репликами в Hyper-V 3.0 (часть 3)
• Работа с репликами в Hyper-V 3.0 (часть 4)
• Работа с репликами в Hyper-V 3.0 (часть 5)