Шифрованный vMotion уже много лет остаётся одним из краеугольных камней защиты рабочих нагрузок в средах VMware. Он гарантирует, что данные виртуальной машины защищены при передаче каждый раз, когда ВМ перемещается между хостами, и для большинства продуктивных сред это попросту обязательное требование. С выходом VMware Cloud Foundation (VCF) 9.1 эта защита становится ещё эффективнее: криптографическая работа перекладывается на Intel QuickAssist Technology (QAT) — аппаратный ускоритель, встроенный в современные процессоры Intel Xeon. В VCF 9.1 функция включена по умолчанию и не требует какой-либо настройки. Команде инженеров было важно понять, сколько именно вычислительной мощности CPU возвращается заказчику, когда шифрованием занимается QAT, а не процессор. Тесты были проведены, и результаты дают вполне однозначную картину.
Как работает разгрузка на QAT
Когда запускается миграция vMotion, данные ВМ шифруются на исходном хосте и расшифровываются на целевом. При использовании разгрузки на QAT в VCF 9.1 работа по шифрованию и расшифровке выполняется аппаратным ускорителем QAT, а не центральным процессором. Процессоры на обеих сторонах освобождаются и могут заниматься выполнением рабочих нагрузок. Для администратора функция прозрачна и на поддерживаемом оборудовании Intel Xeon включена по умолчанию. Подробнее о разгрузке шифрованного vMotion на Intel QAT в VCF 9.1 рассказывается в отдельной статье.
Стенд для тестирования
Для испытаний требовалась нагрузка, чувствительная к доступности CPU, — такая, на которой было бы отчётливо видно, что происходит с производительностью приложения, когда процессор получает обратно такты, ранее уходившие на шифрование. Выбор пал на базу данных Oracle под управлением HammerDB — OLTP-нагрузку с интенсивным профилем дисковых операций. Основной метрикой состояния системы на протяжении всех испытаний служила пропускная способность транзакций Oracle (операций в секунду).
Методика миграции была следующей: на этапе измерений в установившемся режиме выполнялось восемь последовательных операций vMotion с паузой в 120 секунд между соседними миграциями. Восемь прогонов дают статистически честную картину вместо одной-единственной точки данных.
Тестировались три конфигурации:
Шифрование отключено: теоретический потолок без каких-либо криптографических накладных расходов.
QAT Off: шифрованный vMotion полностью выполняется программно силами CPU.
QAT On: шифрованный vMotion разгружен на аппаратный ускоритель Intel QAT.
Результаты
Медианные значения по всем восьми миграциям:
Метрика
Шифрование отключено
QAT OFF
QAT ON
Время миграции (секунды)
57,22
86,97
84,71
Пропускная способность предварительного копирования (МБ/с)
10 871
7 592
7 146
CPU исходного хоста (среднее число одновременно занятых ядер)
7,8*
20,1
7,7
CPU целевого хоста (среднее число одновременно занятых ядер)
18,8*
13,6
10,5
Пропускная способность Oracle (операций/с)
51 319
44 306
50 634
Время простоя ВМ (секунды)**
0,42
0,33
0,78
* Эта конфигурация завершает миграции за существенно меньшее астрономическое время, поэтому её показатель среднего числа одновременно занятых ядер отражает ту же фоновую работу CPU, сжатую в более короткое окно, и не является корректной точкой сравнения с конфигурациями QAT On и QAT Off. Приводится исключительно для справки.
** Время простоя в обеих конфигурациях оставалось близким к целевому, а наблюдаемый разброс обусловлен характером передачи страниц (page-in) на конкретно этой нагрузке, а не работой QAT. Разгрузка шифрования не оказывает причинно-следственного влияния на время простоя.
Экономия CPU на исходном хосте
Загрузка CPU исходного хоста падает с примерно 20,1 ядра при QAT Off до примерно 7,7 ядра при QAT On — это около 62% сокращения вычислительной мощности, расходуемой на шифрование vMotion на стороне источника. Процессорные ресурсы, ранее занятые шифрованием, теперь могут быть отданы работе Oracle. Целевой хост тоже выигрывает: накладные расходы на расшифровку сокращаются примерно на 23% (с ~13,6 до ~10,5 ядра). Больший выигрыш достаётся исходному хосту, поскольку шифрование из этих двух операций вычислительно более затратно.
Пропускная способность Oracle
При QAT Off пропускная способность Oracle в окне миграции составляла 44 306 операций в секунду. При QAT On она восстановилась до 50 634 операций в секунду, что на 14% больше, чем при чисто программном шифровании. Для OLTP-среды, где темп транзакций напрямую отражается на бизнес-результате, эта возвращённая пропускная способность имеет вполне ощутимую ценность.
Время миграции
Конфигурации QAT On и QAT Off дают практически одинаковое время миграции — 84,71 против 86,97 секунды. Разгрузка на QAT и не рассчитана на то, чтобы ускорять саму миграцию. Операции копирования по сети и работы с памятью занимают одинаковое время в обоих случаях. Меняется другое — сколько процессорного запаса остаётся работающей нагрузке, пока идёт эта передача.
Стабильность и джиттер
Разгрузка на QAT полностью развязывает шифрование и планирование выполнения на CPU, и это проявляется в измеримо меньшем разбросе как времени миграции, так и пропускной способности гостевой системы при повторяющихся миграциях. Для нагрузок, работа которых регламентирована SLA, такая предсказуемость имеет вполне реальную эксплуатационную ценность.
Результаты при одновременных миграциях vMotion
Результаты по одиночной ВМ показывают лишь часть картины. Сценарии эвакуации хоста подразумевают множество одновременных миграций. Такие тесты также были проведены.
При невысокой степени параллелизма (от 4 до 6 ВМ одновременно на каналах 25–50 GbE) QAT обеспечивает сокращение нагрузки на CPU на 40–45% без изменения времени завершения миграций. При более высокой степени параллелизма, характерной для полной эвакуации хоста, миграции завершаются практически с той же скоростью, что и без QAT, тогда как потребление CPU на исходном хосте снижается вплоть до ~39%. Плановое обслуживание или аварийная эвакуация — в обоих случаях QAT возвращает задействованным хостам заметный запас процессорной мощности.
Возврат CPU рабочим нагрузкам
Основная ценность разгрузки на QAT состоит не в скорости миграции. Она в том, что именно возвращается системе. Каждое ядро вычислительной мощности, которое QAT удерживает от работы по шифрованию, — это ядро, которое рабочая нагрузка забирает себе для полезной работы. В проведённых тестах это выразилось в 14% приросте пропускной способности Oracle, удерживаемом на протяжении всего окна миграции, и примерно 62% сокращении вычислительной мощности, потребляемой шифрованием на исходном хосте, что эквивалентно примерно 12 освободившимся ядрам во время миграции.
Для команд, эксплуатирующих плотные OLTP-среды, эти возвращённые такты могут стать разницей между сохранением темпа транзакций в окне обслуживания и его проседанием. Для более широкого класса смешанных нагрузок профиль выигрыша аналогичен. Процессор хоста может уделять больше внимания выполнению рабочих нагрузок, пока шифрованием занимается QAT.
Есть и эксплуатационный аспект. Поскольку QAT снимает с исходного хоста основную часть «процессорного налога» во время миграций, хосты с частой активностью vMotion — активные кластеры DRS или площадки с насыщенным графиком обслуживания и эвакуаций — сохраняют больший запас CPU для продуктивных нагрузок на протяжении всех этих операций, вместо того чтобы закладывать дополнительный резерв под накладные расходы на шифрование.
Что это значит на практике
Если VCF 9.1 уже работает на поддерживаемом оборудовании Intel Xeon, разгрузка на QAT уже активна. В среде виртуализации настраивать ничего не требуется. Практический вопрос в другом — что именно дадут конкретной инфраструктуре возвращённые процессорные такты. Для нагрузок с интенсивным OLTP-профилем вроде Oracle ответ очевиден: это пропускная способность транзакций, которую QAT возвращает приложению. Для других чувствительных к CPU нагрузок профиль выигрыша схож.
Итоги
Разгрузка на QAT в VCF 9.1 даёт примерно на 62% меньше накладных расходов CPU на исходном хосте, на 14% более высокую пропускную способность Oracle, удерживаемую в течение окна миграции, и меньший разброс времени миграции и производительности приложения при повторяющихся прогонах. Всё это происходит прозрачно на уровне инфраструктуры, на оборудовании, которое уже присутствует в большинстве развёртываний на Intel Xeon. Шифрованный vMotion продолжает делать ровно то же, что делал всегда: защищать рабочие нагрузки при передаче. Разгрузка на QAT лишь позволяет ему делать это, одновременно возвращая процессорные ресурсы тем нагрузкам, которым они нужны.
Тем, кто ещё не перешёл на VCF 9.1, это даёт конкретный измеримый повод для обновления. Для тех, кто уже работает на этой версии, описанный механизм уже действует в их среде. Проверить, поддерживает ли конкретная модель Intel Xeon технологию QAT, можно на ark.intel.com — и начать возвращать процессорные такты уже сегодня.
RSS
