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

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

Введение

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

Приоритизация виртуальных машин

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

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

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

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

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

Итак, какое отношение все это имеет к отказоустойчивому кластеру или Hyper-V? Ну, на первый взгляд, последние несколько абзацев, вероятно, кажутся не более чем уроком истории или, возможно, поучительной историей. Однако, как всегда, у моего безумия есть метод.

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

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

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

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

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

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

Итак, каково решение этой проблемы? Добавить еще один узел в кластер и оставить его пустым? Едва. Хотя это решение будет работать, это огромная трата ресурсов.

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

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

Настроить приоритеты виртуальных машин очень просто. Чтобы установить приоритет виртуальной машины, откройте диспетчер отказоустойчивого кластера и щелкните правой кнопкой мыши виртуальную машину, для которой вы хотите установить приоритет. Когда появится контекстное меню, выберите команду «Изменить приоритет запуска» в контекстном меню, а затем выберите приоритет виртуальной машины, как показано на рисунке A.

Рисунок A. Откройте диспетчер отказоустойчивого кластера, щелкните правой кнопкой мыши виртуальную машину и выберите команду «Изменить приоритет запуска» в контекстном меню.

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

Вывод

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

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