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

Опубликовано: 20 Апреля, 2023

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

Введение

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

Устранение путаницы

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

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

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

Отказоустойчивый кластер необходим для поддержания виртуальных машин в рабочем состоянии в производственной среде. На самом деле Microsoft поддерживает использование отказоустойчивых кластеров для виртуальных машин с тех пор, как Hyper-V впервые был представлен в Windows Server 2008.

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

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

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

Это две вещи, для которых отказоустойчивая кластеризация действительно хороша. Со времен Windows Server 2008 можно было выполнять аварийное переключение. Возможность запускать мигрированные виртуальные машины для обслуживания или балансировки нагрузки появилась в Windows Server 2008 R2 и Hyper-V 2.0.

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

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

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

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

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

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

Вывод

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

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