Вычислительная инфраструктура
Типы гипервизоров
Первые гипервизоры x86 были службами внутри хостовой ОС. Однако это вызывало проблемы как с точки зрения производительности, так и с точки зрения высокой доступности (High Availability), поскольку подобные службы весьма сложно кластеризовать в таком режиме.
В связи с этим появилась необходимость в типологизации гипервизоров, что позволило бы определить область применимости каждого.
Гипервизор VMware ESXi
VMware ESXi относится к типу гипервизоров 1+, которые не требуют ОС общего назначения. Сам гипервизор представляет собой монолит, который управляет как распределением вычислительных ресурсов, так и операциями ввода-вывода. В нулевом кольце защиты располагается микроядро, поверх которого работают все управляющие конструкции.
С точки зрения его архитектуры команды управления выполняются через API-агента, который работает поверх VMkernel. При этом прямой доступ к гипервизору отсутствует, что выгодно отличает этот тип гипервизора с точки зрения его безопасности.
Недостатком здесь можно отметить необходимость поддержания совместимости с северным оборудованием. Для обеспечения «тонкости» платформы и устранения излишних усложнений от версии к версии происходит ротация драйверов устройств, что делает физическую инфраструктуру зависимой от HCL (Hardware Compatibility List).
Гипервизор Yandex Cloud — QEMU/KVM
Гипервизор Yandex Cloud — QEMU/KVM, как и VMware ESXi, относится к типу 1+.
QEMU (Quick EMUlator) — универсальное ПО для эмуляции аппаратного обеспечения различных платформ, распространяемое по лицензии GPL v2. Помимо Intel x86 поддерживает и другие архитектуры процессоров.
Обладая универсальностью платформы с полной виртуализацией, QEMU не обладал достаточной производительностью, сравнимой с невиртуализованной системой, в связи с чем для ускорения работы QEMU на x86 был добавлен KVM (Kernel-based Virtual Machine) от Qumranet. QEMU/KVM имеет формат виртуальных дисков qcow2 (QEMU copy-on-write 2) для всех платформ, а также удобное управление синтетическими устройствами.
Особенности работы гипервизора: переподписка по ядрам
Переподпиской по ядрам (CPU Overcommintment) называют соотношение физических ядер хоста к выделенным на гипервизоре vCPU.
vCPU — это виртуальный процессор, который «отрезает» гипервизор от физического CPU при создании виртуальных машин. vCPU содержит минимум одно ядро. От количества ядер виртуального процессора зависит количество потоков, которые может использовать многопоточное приложение.
Задача гипервизора — распределение ресурсов (времени) между физическими и виртуальными CPU.
Переподписка по ядрам
|
VMware Cloud Director |
Yandex Cloud |
|
VMware vSphere позволяет очень гибко управлять переподпиской как в рамках кластера ESXi, так и в рамках одного физического ядра через настройки MaxVCPUsPerCore и MaxVCPUsPerCluster. Это реализует администратор облака на уровне vSphere. Как правило, сервис-провайдеры планируют целевую и допустимую переподписку. Такой подход позволяет увеличить плотность размещения ВМ, а планировщик обеспечивает оптимальную производительность. Стоит учитывать требования нагрузок к платформе виртуализации: не все приложения допускают переподписку по ядрам. Приложения, допускающие переподписку, предъявляют определенные требования по допустимому соотношению выделенных ядер к физическим в виртуальный среде. Например, практически все СУБД уровня Enterprise требуют переподписку 1 : 1, в то время как терминальные решения (например, VMware Horizon или Microsoft RDS) могут допускать переподписку 1 : 10. |
Yandex Cloud позволяет управлять переподпиской по vCPU при конфигурации ВМ до 4 ядер включительно. По умолчанию для ВМ устанавливается рекомендованная для производственных нагрузок переподписка 1 : 1. Число vCPU для ВМ кратно двум, маппинг каждой пары vCPU осуществляется в два SMT-потока в пределах одного физического ядра, что исключает возможность атаки Spectre/Meltdown со стороны ВМ другого заказчика. Подробнее — в документации. |
Переподписка по памяти
|
VMware Cloud Director |
Yandex Cloud |
|
VMware использует сложную систему аллокации памяти, где выделяются: Limit — максимальный размер памяти; Reservation — минимальный порог аллоцируемой памяти; Shares — доля от общего количества ресурсов хоста, выделенных виртуальной машине. В VMware реализован механизм оптимизации работы виртуальных машин с оперативной памятью — memory ballooning. Это техника гипервизора по работе с оперативной памятью, которая позволяет запустить на хосте ESX виртуальные машины, совокупная выделенная память которых больше суммарной памяти хоста. Таким образом, реальный объем выделенной памяти на гипервизоре и в облаках VMware может определяться динамически в зависимости от настроек и обладать свойством переподписки. Больше деталей — по ссылке. |
В Yandex Cloud используется статический механизм аллокации памяти без переподписки и memory ballooning — виртуальной машине доступна вся выделенная оперативная память, и она не может быть другими виртуальными машинами на том же хосте. Сумма выделенной памяти для виртуальных машин не превышает доступную физическую память на хосте. |
Живая миграция виртуальных машин
Live Migration (живая миграция) — это перенос виртуальной машины с одного физического сервера на другой без прекращения работы виртуальной машины и остановки запущенных сервисов. Эффект: снижение RTO (recovery time objective) до нуля для запланированных простоев, для обслуживания серверов и, как следствие, частичное исключение самих простоев.
|
VMware Cloud Director |
Yandex Cloud |
|
Облака на VMware Cloud Director требуют включения опции DRS (Dynamic Resource Scheduler) — автоматической балансировки ВМ по хостам в зависимости от нагрузки для снижения фрагментации ресурсов в кластере и обеспечения уровня обслуживания для ВМ. Так как рабочие нагрузки внутри ВМ могут быть чувствительны к потерям сетевых пакетов при живой миграции, как, например, некоторые сервисы IP-телефонии, размещение таких нагрузок рекомендуется на выделенных гипервизорах — при любом решении виртуализации или облака. vMotion vSphere позволяет оперативно мигрировать рабочие нагрузки с одного сервера на другой без простоев, не управляется Cloud Director. Настройка Affinity & Anti-Affinity Rules подразумевает живую миграцию по отдельным хостам, что удобно в некоторых сценариях лицензирования. Однако это усложняет администрирование, так как при отказе хоста виртуальная машина может нигде не запуститься, но исключит ее несогласованный переезд. В сценарии Cloud Director такой подход не совсем применим, так как в кластере обязателен DRS (Dynamic Resource Scheduler), и со стороны сервис-провайдеров это может потребовать ручного вмешательства персонала. В остальных случаях недоступность сети во время переключения, как правило, не превышает потери 1–2 пакетов. Это связано с переключением синтетического сетевого адаптера на виртуальный коммутатор другого хоста. |
В Compute Cloud используется механизм динамической миграции, который позволяет перемещать запущенные виртуальные машины между физическими серверами без остановки и перезагрузки. Пауза при этом обычно не превышает 10 секунд. Динамическая миграция не изменяет параметров виртуальных машин. Процесс миграции в реальном времени переносит работающую ВМ с одного сервера на другой в той же зоне доступности. Все свойства ВМ, в том числе внутренние и внешние IP-адреса, метаданные, память, состояние сетей, операционных систем и приложений остаются неизменными. Compute Cloud запускает динамическую миграцию в следующих случаях:
Размещение сервисов, чувствительных к потере пакетов (например, IP-телефония), настоятельно рекомендуется строго на Dedicated Hosts. |
NUMA-топология
NUMA (Non Uniform Memory Access) — архитектура с неравномерным доступом к памяти. В рамках данной архитектуры у каждого процессора есть своя локальная память, доступ к которой осуществляется напрямую, с низкими задержками. Доступ к памяти других процессоров осуществляется опосредованно, с более высокими задержками, что приводит к снижению производительности.
NUMA-топология в VMware ESXi (vNUMA)
vNUMA позволяет сообщить гостевой ОС в ВМ виртуальную топологию NUMA для машин, где vCPU или vRAM больше, чем узел NUMA или число виртуальных сокетов более одного.
Виртуальная архитектура NUMA, для которой требуется виртуальное оборудование версии 8 или более поздней, в некоторых случаях может обеспечить значительные преимущества в производительности для широких виртуальных машин (то есть виртуальных машин с бо́льшим количеством виртуальных ЦП, чем количество ядер в каждом физическом узле NUMA), хотя эти преимущества в значительной степени зависят от уровня оптимизации NUMA в гостевой операционной системе и приложениях.
Начиная с vSphere версии 6.5 и более поздних версий улучшена обработка vNUMA, которая автоматически определяет правильную топологию vNUMA для представления гостевой ОС на основе базового узла ESXi. В случаях, когда ВМ на нескольких узлах NUMA имеет нечетное число ядер, производительность гостевого сервиса резко падает, а шедулеру гипервизора тяжело управлять ресурсами процессора.
Кроме того, важно отметить, что vNUMA неприменима к ВМ с подключенной опцией vCPU Hot Add, а также в ситуациях, когда ресурсы ВМ выходят за пределы одной NUMA-ноды. В данных ситуациях могут возникнуть проблемы с производительностью гостевой ОС, что отрицательно повлияет на соседние ВМ.
Ниже приведена таблица конфигураций виртуальных машин для двухсокетного сервера с 10 физическими ядрами на сокет:
| Физический процессор | Число vCPU | Объем памяти, меньше или равно | Число сокетов | Ядер на сокет | Число NUMA-нод |
|---|---|---|---|---|---|
| Intel, 2 сокета, 10 ядер на сокет, 256GB RAM, 128GB RAM на сокет | 1 | 128 | 1 | 1 | 1 |
| 2 | 128 | 1 | 2 | 1 | |
| 3 | 128 | 1 | 3 | 1 | |
| 4 | 128 | 1 | 4 | 1 | |
| 5 | 128 | 1 | 5 | 1 | |
| 6 | 128 | 1 | 6 | 1 | |
| 7 | 128 | 1 | 7 | 1 | |
| 8 | 128 | 1 | 8 | 1 | |
| 9 | 128 | 1 | 9 | 1 | |
| 10 | 128 | 1 | 10 | 1 | |
| 11 | 128 | Не оптимально | Не оптимально | Не оптимально | |
| 12 | 128 | 1 | 6 | 2 | |
| 13 | 128 | Не оптимально | Не оптимально | Не оптимально | |
| 14 | 128 | 1 | 7 | 7 | |
| 15 | 128 | Не оптимально | Не оптимально | Не оптимально | |
| 16 | 128 | 2 | 8 | 2 | |
| 17 | 128 | Не оптимально | Не оптимально | Не оптимально | |
| 18 | 128 | 2 | 9 | 2 | |
| 19 | 128 | Не оптимально | Не оптимально | Не оптимально | |
| 20 | 128 | 2 | 10 | 2 |
NUMA-топология в Yandex Cloud
В Yandex Cloud аналог vNUMA отсутствует. Более того, при создании и редактировании виртуальной машины используются статически заданные конфигурации CPU/RAM, в связи с чем пользователи не могут создать машину с неоптимальной конфигурацией vCPU/RAM. Однако требования к поддержке NUMA со стороны сервиса в гостевой ОС остаются неизменными.
Виртуальные машины небольшого размера располагаются на одном сокете, виртуальные машины крупного размера равномерно распределяются по двум сокетам, при этом 50% памяти и ядер берется с NUMA0 и 50% — с NUMA1.
Таблица расположения ВМ по NUMA топологии для различных платформ:
| Платформа | Конфигурация с NUMA0 | Конфигурация с NUMA0 + NUMA1 |
|---|---|---|
| standard-v2 | меньше или равно 18 vCPU | больше 18 vCPU |
| standard-v3 | меньше или равно 32 vCPU | больше или равно 36 vCPU |
Компоненты интеграции с ВМ
|
VMware Cloud Director |
Yandex Cloud |
|
VMware Tools — набор драйверов синтетических устройств и служб для гостевых операционных систем. Компоненты интеграции посредством опроса служб VMware Tools со стороны хоста ESXi позволяют получать данные о гостевой ОС: hostname, IP-адреса сетевых адаптеров, а также информацию о состоянии ОС. Также VMware Tools позволяют через PowerCLI (модули PowerShell с поддержкой продуктов VMware) со стороны администратора виртуализации выполнять операции копирования файлов в ВМ и исполнять команды на стороне гостевой ОС с указанием пароля администратора без подключения к гостю через SSH/RDP. |
В Yandex Cloud компоненты интеграции являются опциональными. Централизованного пакета с IC нет. На текущий момент доступны следующие гостевые службы для взаимодействия с внешними сервисами облака:
|
Консольное подключение к виртуальным машинам
|
VMware Cloud Director |
Yandex Cloud |
|
VMware имеет инструменты и зарезервированные сетевые порты для доступа к локальной консоли виртуальных машин. Также VMware разработали возможность предоставления доступа через веб-интерфейс к консоли , трансляцию которой передают как vSphere, так и Cloud Director. Доступ к локальной консоли можно получить через приложение VMware Remote Console (VMRC). При этом доступ к гипервизору не требуется, достаточно авторизоваться в Cloud Director, и при успешной авторизации сервис Remote Console Proxy будет транслировать локальную консоль ВМ, что упрощает траблшутинг гостевой ОС в случае отказа. |
Yandex Cloud не имеет сервиса трансляции консоли и утилиты для ее отображения на компьютере пользователя, так как гипервизор QEMU/KVM требует доступ непосредственно к хосту, где запущена виртуальная машина, чтобы через сервис-транслятор передать изображение с локального «дисплея». В связи с этим в Yandex Cloud предлагается серийная консоль для локального доступа к виртуальной машине как инструмент локального текстового доступа к ВМ. Траблшутинг ОС в данном сценарии сложнее, но возможен. |