Серверные и десктопные гипервизоры (Часть 1)

Введение

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

В этой серии статей, состоящей из трех частей, я расскажу о некоторых функциях, которые имеют первостепенное значение в каждом сценарии. В этой части 1 я сосредоточусь в первую очередь на серверной части уравнения.

Типы гипервизоров

Хотя вы, как правило, не будете болтать на эту тему со своими друзьями по виртуализации, академическое понимание различных типов гипервизоров полезно для рассмотрения. В целом все гипервизоры — платформы виртуализации — можно отнести к одной из двух категорий: тип 1 и тип 2. Гипервизоры типа 1 включают VMware ESX и часто называются «голыми металлическими гипервизорами» из-за того, что гипервизор работает напрямую. на оборудовании без базовой промежуточной операционной системы. В этом случае гипервизор сам является операционной системой и контролирует доступ к оборудованию. Отдельные операционные машины работают в виртуальных машинах, расположенных поверх гипервизора, поэтому между аппаратным обеспечением и виртуальной машиной существует только один программный уровень. Гипервизоры типа 2, с другой стороны, работают в собственной операционной системе, такой как Windows, Linux или Mac OS X. Примерами гипервизоров типа 2 являются Virtual PC и VirtualBox. Базовая операционная система по-прежнему запускает другие приложения — в дополнение к программному обеспечению гипервизора — и управляет распределением ресурсов. Виртуальные машины работают поверх уровня гипервизора, а это означает, что между каждой виртуальной машиной и оборудованием существует два уровня программного обеспечения — гипервизор и основная операционная система.

С точки зрения чистой «плотности» — то есть огромного количества виртуальных машин, которые могут работать на каждом виде платформы — в общих чертах гипервизоры типа 1 выигрывают день из-за того, что уровень гипервизора почти всегда тоньше и больше. эффективнее, чем сравнительно раздутый полный аналог ОС. Если подумать, это действительно имеет смысл. Полная операционная система, которая находится под гипервизором типа 2, намеренно предназначена для универсального использования; обслуживание гипервизора — лишь одна из многих обязанностей, за которые отвечает ОС. Гипервизоры типа 1 существуют для одной и только одной цели — для обслуживания потребностей отдельных виртуальных машин. Таким образом, виртуальным машинам доступно больше ресурсов, поскольку общий уровень ОС отсутствует.

Другой способ понять разницу между гипервизорами типа 1 и типа 2 заключается в следующем: гипервизоры типа 2, по сути, являются не чем иным, как приложениями, которые устанавливаются в операционной системе точно так же, как и другое программное обеспечение, такое как Microsoft Office. Гипервизоры типа 1 — это специально созданные операционные системы, предназначенные для размещения других операционных систем.

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

Что касается гипервизоров корпоративного уровня, то большинство из них относятся к типу 1. Существует распространенное заблуждение, что Hyper-V — это гипервизор типа 2, потому что он работает поверх Windows. Однако это ошибочно. Hyper-V просто использует виртуализированный родительский раздел Windows, который управляет гипервизором. Гипервизор загружается перед этой управляющей операционной системой. Созданные вами виртуальные машины работают в гипервизоре, а не в операционной системе родительского раздела.

Потребности и возможности серверного гипервизора

В наши дни большинство организаций используют виртуализированные серверы в своих центрах обработки данных. За исключением, возможно, самых маленьких сред, используемые продукты считаются продуктами уровня «предприятие» и включают в себя такие продукты, как VMware vSphere, Microsoft Hyper-V и Citrix XenServer. Эти продукты предназначены для выполнения даже самых ресурсоемких рабочих нагрузок и справляются с ними хорошо. Эти продукты обладают мощными функциями, предназначенными для обеспечения того, чтобы рабочие нагрузки, которые они несут, оставались доступными, продолжали работать должным образом и выполняли это с минимальным вмешательством администратора.

Каковы некоторые из наиболее важных потребностей и функций, присущих серверным гипервизорам производственного класса? Здесь только несколько:

Высокая доступность

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

Корпоративные гипервизоры должны поддерживать методы высокой доступности, и крупные игроки делают это таким образом, чтобы свести к минимуму количество необходимого оборудования. Я начну с обсуждения некоторых механизмов высокой доступности vSphere:

• Автоматический перезапуск виртуальных машин даже между хостами. В случае сбоя виртуальной машины, будь то из-за сбоя узла vSphere или из-за сбоя внутри самой виртуальной машины, vSphere может автоматически предпринять шаги для перезапуска затронутой виртуальной машины. В случае сбоя одного из узлов vSphere vSphere перезапустит виртуальную машину на другом узле vSphere. Обратите внимание, что это не то же самое, что vMotion. Это просто механизм высокой доступности, включенный в каждую редакцию vSphere — VMware HA. Hyper-V также имеет аналогичную функцию. Если хост-компьютер перезапущен, а для виртуальных машин сохранены настройки по умолчанию, каждая виртуальная машина перезапустится (или возобновит работу) после завершения процесса загрузки. Если вы хотите узнать, как манипулировать параметрами запуска для отдельных виртуальных машин на основе Hyper-V, взгляните на эту запись в блоге, которую я написал по этой теме. Обратите внимание, что VMware называет этот механизм доступности HA, в то время как аналог Microsoft можно считать их функцией быстрой миграции. Самое главное, поймите, что эти механизмы доступности влекут за собой штраф за время простоя, хотя и непродолжительное. Существует время простоя, по крайней мере, для перезагрузки виртуальной машины, не говоря уже о времени, которое может потребоваться для ее переноса на другой хост. Для некоторых (но не для многих!) это «достаточно хороший» механизм.
• Миграция рабочих нагрузок между хостами. Хотя хорошо, что гипервизор автоматически перезапускает рабочие нагрузки в случае сбоя, также приятно иметь возможность просто перемещать текущую рабочую нагрузку с одного хоста на другой без простоев. Например, предположим, что вам нужно выполнить техническое обслуживание узла vSphere или Hyper-V. Хотя вы можете выключить работающую виртуальную машину, переместить ее на другой хост, а затем перезапустить виртуальную машину, этот процесс налагает штраф за время простоя, что для многих неприемлемо. На это тоже есть ответ, и это обязательная функция в программном обеспечении для виртуализации корпоративного класса. Например, VMware vSphere предоставляет эту функцию под названием vMotion, а Microsoft предоставляет функцию под названием Live Migration. В мире Citrix это называется XenMotion. Все достигают одинаковых целей; нулевая миграция работающей виртуальной машины между хостами.
• Миграция рабочей нагрузки между устройствами хранения. Еще одна функция, ставшая обязательной, — это возможность переноса рабочих нагрузок с одного устройства хранения на другое. Эта функция может служить одной или двум различным целям. Во-первых, он выводит концепцию высокой доступности на совершенно новый уровень. Теперь администраторы хранилища могут безопасно работать с устройствами хранения так же, как администраторы узлов гипервизора. Во-вторых, возможно, эта функция позволит использовать более распространенные и менее дорогие хранилища, хотя я считаю, что большинство организаций будут — и это правильно — продолжать развертывать виртуальную среду с использованием надежных сред хранения. В настоящее время только VMware предлагает надежный способ сделать это без ощутимого простоя для пользователя. Эта функция, получившая название Storage vMotion, обеспечивает динамическую миграцию дисковых файлов виртуальных машин между различными массивами хранения. Storage vMotion включен в редакции vSphere Enterprise и Enterprise Plus. Microsoft предоставляет функцию под названием SAN Migration (ранее известную как Quick Storage Migration), которая выполняет аналогичную задачу, но требует короткого периода простоя, когда затем виртуальная машина переводится в состояние сохранения, пока процесс завершается. Этот механизм миграции хранилища также невероятно полезен, когда приходит время заменить SAN.

Расширенные механизмы доступности

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

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

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

И у VMware, и у Microsoft есть функции именно для этой цели. VMware называет эту функцию планировщиком распределенных ресурсов (DRS), который использует vMotion для динамического перемещения отдельных виртуальных машин между хостами vSphere, чтобы сбалансировать рабочие нагрузки между хостами. DRS доступен в редакциях vSphere Enterprise и Enterprise Plus. Основная цель DRS — помочь снизить административную нагрузку на лицо, ответственное за виртуальную инфраструктуру, и сделать среду максимально самодостаточной.

С введением Virtual Machine Manager 2008 и R2 у Microsoft появилась аналогичная функция под названием «Оптимизация производительности и ресурсов» (PRO). Это служба, которая обеспечивает автоматическое размещение рабочей нагрузки на основе информации о производительности и работоспособности, собранной пакетами управления PRO, загруженными в System Center Operations Manager.

Резюме

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