Новый взгляд на кластеры Hyper-V (часть 2)

• Свежий взгляд на кластеры Hyper-V (часть 3)
• Свежий взгляд на кластеры Hyper-V (часть 4)
• Свежий взгляд на кластеры Hyper-V (часть 5)
• Свежий взгляд на кластеры Hyper-V (часть 6)
• Свежий взгляд на кластеры Hyper-V (часть 7)
• Свежий взгляд на кластеры Hyper-V (часть 8)

Введение

В первой статье этой серии я рассказал о некоторых последних изменениях, внесенных корпорацией Майкрософт в отношении модели кворума, используемой в отказоустойчивых кластерах. Конечно, заголовок этой статьи — «Новый взгляд на кластеры Hyper-V», и изменения в модели кворума влияют на все типы отказоустойчивых кластеров. Поскольку до сих пор я почти не упоминал Hyper-V, я хочу посвятить эту статью некоторым улучшениям, связанным с виртуализацией, которые Microsoft внесла в отказоустойчивый кластер в Windows Server 2012 R2.

Прежде чем я начну

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

Слив при выключении

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

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

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

Стоит отметить, что, несмотря на улучшения, внесенные Microsoft, Microsoft по-прежнему рекомендует переводить узлы кластера в режим обслуживания перед выполнением завершения работы.

Обнаружение состояния сети виртуальной машины

Еще одно улучшение в Windows Server 2012 R2 — определение работоспособности сети на уровне виртуальной машины. В Windows Server 2012, если виртуальная машина потеряет связь с виртуальной сетью, виртуальная машина продолжит работу, как будто все в порядке.

В Windows Server 2012 R2 Microsoft предоставила Windows возможность отслеживать подключения к виртуальной сети. Если виртуальная машина теряет связь с виртуальной сетью, для виртуальной машины может быть выполнена автоматическая динамическая миграция в надежде, что виртуальная машина сможет восстановить подключение к виртуальной сети, как только она достигнет целевого узла кластера.

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

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

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

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

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

Теперь найдите виртуальный сетевой адаптер, подключенный к сегменту сети, для которого вы хотите включить мониторинг работоспособности. Разверните список сетевого адаптера и выберите контейнер «Дополнительные функции». Теперь вы можете защитить сегмент сети, установив флажок «Защищенная сеть», как показано на рисунке A.

Рисунок A. Вы можете включить защиту сети для каждого сегмента виртуальной сети.

Общий виртуальный жесткий диск

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

Windows Server 2012 позволял создавать гостевые кластеры, но для полной поддержки эти узлы гостевого кластера должны были подключаться к хранилищу iSCSI или Fibre Channel. Проблема с этим заключается в том, что в средах с несколькими арендаторами или средах самообслуживания пользователей вы, вероятно, не захотите раскрывать детали своей физической архитектуры хранения.

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

Вывод

Как видите, Microsoft внесла некоторые улучшения в отказоустойчивую кластеризацию в Windows Server 2012 R2, которые действительно полезны для сред Hyper-V. В следующей статье этой серии мы настроим отказоустойчивый кластер Hyper-V и начнем изучение некоторых передовых методов обеспечения отказоустойчивости виртуальных машин.

• Свежий взгляд на кластеры Hyper-V (часть 3)
• Свежий взгляд на кластеры Hyper-V (часть 4)
• Свежий взгляд на кластеры Hyper-V (часть 5)
• Свежий взгляд на кластеры Hyper-V (часть 6)
• Свежий взгляд на кластеры Hyper-V (часть 7)
• Свежий взгляд на кластеры Hyper-V (часть 8)