Компьютеры и Интернет
Аппаратная виртуализация – это система, которая использует один процессор для работы, как если бы это было несколько разных компьютеров. Основное использование аппаратной виртуализации – предоставить нескольким пользователям доступ к процессору. Это означает, что каждый пользователь может иметь отдельный монитор, клавиатуру и мышь и независимо запускать свою операционную систему. Что касается пользователей, то все они будут эффективно работать на своём компьютере. Такая настройка может значительно сократить расходы, поскольку несколько пользователей могут использовать одно и то же основное оборудование.
Можно сказать, что кто-то обращается к компьютеру с помощью аппаратной виртуализации и использует виртуальный рабочий стол. Существует риск того, что это может вызвать путаницу. Это связано с тем, что фраза «виртуальный рабочий стол» в некоторых операционных системах также используется для описания функций, которые позволяют пользователю эффективно расширять свой рабочий стол за пределы видимой области на своём экране.
Теперь, когда виртуализация x86 является основным элементом производственной инфраструктуры, проблемы управления, которые ранее не рассматривались, теперь начинают появляться. В следующих нескольких вопросах я буду использовать этот вопрос для решения некоторых проблем, которые я слышу в отношении управления виртуализацией. Хотя разработка инструментов начинает облегчать бремя управления, появляющиеся технологии – аппаратная виртуализация, виртуализация одно- и многокорневого ввода-вывода и виртуализация хранения – угрожают ещё больше усугубить трудности управления, лежащие в основе виртуализации.
Аппаратная виртуализация была введена AMD и Intel несколько лет назад. Она известна как AMD Virtualization и Intel Virtualization Technology, соответственно, и требуется для некоторых гипервизоров, а именно Xen и Hyper-V. VMware в своей первой итерации не использовала аппаратную виртуализацию, поскольку технология бинарного перевода VMware, обеспечивающая перехват и эмуляцию, необходимые для команд ЦП в привилегированном режиме в гостевой виртуальной машине (ВМ), может превзойти то, что могли сделать обе компании.
Аппаратно-вспомогательная архитектура
Одним из основных элементов виртуализации первого поколения с аппаратным обеспечением было создание нового уровня в архитектуре кольцевых процессоров x86, известной как Ring -1. При аппаратной виртуализации гипервизоры, поддерживающие эту технологию, могут загружаться в кольцо -1, а гостевые ОС могут обращаться к ЦП в кольцо 0, как обычно при работе на физическом хосте. Таким образом, гостевые ОС VM могут быть виртуализированы без каких-либо необходимых изменений гостевой ОС. Ранее паравиртуализация ядра гостевой ОС, принятая основными поставщиками Linux, использовалась для преодоления задержки производительности, связанной с перехватом и эмуляцией привилегированного процессора.
Всё было хорошо во вселенной виртуализации с аппаратным обеспечением, когда технология была первоначально поставлена. Организации развернули её, и технология работала, как и ожидалось, на гипервизорах Xen и Hyper-V. VMware не начала внедрять аппаратную виртуализацию до выпуска ESX Server 3.5 Update 2 летом 2008 года, в которой официально поддерживались такие аппаратные функции виртуализации второго поколения от AMD, как аппаратная виртуализация памяти, известная как Rapid Virtualization Indexing (RVI). ) и иногда упоминается как вложенный пейджинг. AMD RVI позволила существенно повысить производительность многопоточных корпоративных приложений, таких как Exchange, Oracle и XenApp.
Нет смешивания и сопоставления
Наличие нескольких поколений виртуализации с аппаратным обеспечением в одном и том же кластере физических хостов может вызвать серьезные проблемы с мобильностью, такие как невозможность живой миграции виртуальной машины с одного физического хоста на другой. Смешивание поколений ЦП в одном и том же физическом кластере проблематично, поскольку гипервизор не эмулирует ЦП, поэтому ЦП, видимый гипервизором, представляется гостевой ОС ВМ. Отсутствие эмуляции важно, поскольку оно позволяет приложениям в гостевой ОС виртуальной машины использовать преимущества низкоуровневых функций ЦП. Однако смешивание поколений ЦП в одном и том же физическом кластере может привести к непредвиденным проблемам, таким как невозможность виртуальных виртуальных машин с миграцией или необходимость реактивировать приложение, активация которого связана с конкретным типом ЦП.
Intel и AMD подумали о потенциальных проблемах, вызванных смешанным поколением процессоров в одном физическом кластере, и разработали Extended Migration (AMD) и Flex Migration (Intel). Расширенная миграция и гибкая миграция позволяют гипервизору маскировать базовый физический ЦП и представлять его гостевой ОС ВМ как более раннее поколение ЦП. По сути, это позволяет различным поколениям процессоров находиться в одном физическом кластере. Но есть и компромисс: возможности ЦП оборудования кластера работают с наименьшим общим знаменателем. Обратите внимание, что расширенная миграция и гибкая миграция не обеспечивают функциональную совместимость с процессором, поэтому вы все равно должны использовать AMD или Intel в любом кластере; Смешивание Intel и AMD вместе в одном физическом кластере не допускается никаким гипервизором.
Теперь давайте предположим, что конкретный кластер ESX подвергается обновлению оборудования или что бюджетные ограничения вынуждают вас масштабировать кластер гипервизора в течение года. В любом случае вы можете столкнуться с наличием нескольких поколений ЦП в кластере. В этой ситуации первый вопрос, на который нужно ответить: «Поддерживает ли мой гипервизор расширенную или гибкую миграцию?» ESX Server 3.5 Update 2 – один из немногих гипервизоров, который поддерживает эту функцию; однако вам необходимо включить маскирование ЦП на каждой виртуальной машине в кластере. Это можно сделать с помощью клиента инфраструктуры VMware, открыв Свойства виртуальной машины, перейдя на вкладку «Параметры» и нажав кнопку «Скрыть флаг Nx от гостя».
Конечно, включение маскировки идентификатора ЦП для каждой виртуальной машины может быть трудной задачей, если не сказать больше, и VMware предложила решение на основе сценариев для автоматизации процесса в больших масштабах.
Отключение функции
Теперь давайте рассмотрим еще одну потенциальную проблему управления с автоматическим отключением функции аппаратной виртуализации. RVI от AMD продемонстрировал существенное улучшение производительности для многих приложений, в то время как некоторые приложения будут работать лучше без включенной функции. При этом RVI может быть включен или отключен для каждой виртуальной машины.
Рисунок 1. Включение маскировки идентификатора процессора на виртуальной машине VMware ESX Server.
Теперь вот проблема. Предположим, что виртуальная машина с включенным RVI запущена на сайте аварийного восстановления организации после серьезного сбоя. Оборудование на сайте восстановления не поддерживает RVI, различие обнаруживается гипервизором, и RVI автоматически отключается при запуске виртуальной машины на сайте восстановления. Конечно, приложение может работать медленнее без RVI, но, по крайней мере, оно все еще доступно.
Суть в том, что хотя обработка RVI по умолчанию гипервизора позволяла виртуальной машине работать на сайте восстановления, несмотря на разницу в аппаратных функциях, что произойдет, если виртуальная машина вернется на исходный рабочий сайт? Ты угадал. RVI останется отключенным. Таким образом, чтобы снова использовать RVI, необходимо вручную включить его, или процедуры восстановления после сбоя включают восстановление исходного файла конфигурации рабочей виртуальной машины – файла .VMX – для каждой виртуальной машины из резервной копии. Таким образом, хотя поведение гипервизора по умолчанию предназначено для того, чтобы помочь вам преодолеть бедствие, оно также может создать некоторые проблемы с производительностью после восстановления виртуальных машин обратно на исходный сайт или на новый сайт с использованием нового оборудования.
RVI – это всего лишь один пример. Многие новые аппаратные функции виртуализации уже на пороге, и гипервизорам по-прежнему придется решать проблемы взаимодействия, отключая функции, которые недоступны для всех физических узлов в кластере. Инструментам управления гипервизором также понадобится интеллект для предупреждения администраторов о невозможности использования определенных функций из-за ограничений аппаратного обеспечения кластера. Для инструментов восстановления после сбоя сайта, таких как VMware Site Recovery Manager, потребуются аналогичные возможности. Я предпочел бы знать, что я потеряю определенную функцию производительности до того, как произойдет сбой, вместо того, чтобы предоставить гипервизору автоматическое отключение этой функции для меня.
Реализации аппаратной виртуализации, поставляемые поставщиком гипервизора, начинают развиваться вместе с предложениями AMD и Intel в этой области. Когда эти новые функции появятся и станут частью вашей виртуальной инфраструктуры, вам нужно будет изучить процессы развертывания, чтобы убедиться, что приложения используют преимущества таких функций, как RVI, когда это имеет смысл. Вам также необходимо убедиться, что процедуры восстановления после сбоя и восстановления после отказа вашей организации учитывают различия аппаратной платформы и то, как гипервизор реагирует на эти различия. Конечно, я даже не упомянул проблемы с перемещением виртуальной машины в «облако». Если рассматривать физическую инфраструктуру поставщика услуг как облако на бумаге, то отличия в аппаратной виртуализации делают это невозможным. Вместо этого виртуальным машинам потребуется использовать стандарты, такие как открытый формат виртуализации, для объявления своих требований к аппаратной виртуализации поставщику облачных услуг.
Аппаратная виртуализация является важной технологией. В дальнейшем это позволит нам виртуализировать приложения, рабочие нагрузки которых делали мысль о виртуализации смехотворной. Тем не менее, новые проблемы управления, вызванные аппаратной виртуализацией, не являются предметом смеха, и игнорирование этих проблем может привести к ревам со стороны высшего руководства, чего не хочет слышать ни один ИТ-администратор.
