Как оптимизировать vMotion для сокращения времени миграции?

Это перевод статьи Niels Hagoort How to Tune vMotion for Lower Migration Times?. Публикуется с разрешения автора.

В предыдущей статье, vMotion под капотом, мы рассмотрели как технически устроен процесс vMotion. Теперь, когда мы понимаем, как работает vMotion, давайте рассмотрим некоторые из имеющихся у нас возможностей, для сокращения времени живой миграции. По умолчанию, просто включив vMotion, все прекрасно работает. Однако, сети с высокой пропускной способностью быстро становятся все более популярными, что мы можем сделать, чтобы в полной мере использовать преимущества 25, 40 или даже 100GbE сетевых адаптеров? В этой статье подробно рассказывается о настройках vMotion и о том, как они могут помочь оптимизировать процесс.

Streams and Threads

Если у вас есть интерфейс VMkernel, для которого включен vMotion, у вас уже есть один vMotion поток (vMotion Streams). Один поток vMotion содержит три хелпера (Helper):

  • Completion helper; Поддерживает процесс vMotion.
  • Crypto helper; Предназначен для шифрования и дешифрования трафика при использовании Encrypted vMotion.
  • Stream helper; Ответственный за отправку данных в сеть.

Термин “Helper” используется командой разработки vMotion, но на самом деле это поток (Thread). Один thread может использовать только одно ядро ​​процессора. Что касается скорости живой миграции, её продолжительность в значительной степени зависит от полосы пропускания сети, которая используется модулем миграции для передачи памяти от исходного ESXi хоста к целевому. Однако мы ограничены только одним vMotion Stream Helper’ом, то есть одним thread’ом, соответствующим одному ядру CPU. Хотя это обычно не является проблемой, при использовании современных процессоров и сетей 10GbE, но это становится проблемой при использовании сетевых адаптеров и сетей с пропускной способностью 25GbE или выше. Сетевой адаптер 25GbE или выше не будет полностью утилизирован одним потоком vMotion (vMotion Stream).

Масштабирование производительности vMotion

Вариант 1: Несколько VMkernel интерфейсов

С каждым созданным VMkernel интерфейсом, для которого включен vMotion, запускается новый поток vMotion (vMotion Stream). Каждый поток содержит свои helper’ы. Несколько stream helper’ов позволяют передавать больше данных по vMotion сети и тем самым использовать большую пропускную способность для копирования страниц памяти по vMotion сети, тем самым сокращая время сходимости памяти между исходным и целевым ESXi хостами. В результате vMotion завершается быстрее.

Один поток vMotion имеет среднюю пропускную способность 15 GbE. Рассмотрим производительность для разных NIC:

  • 25 GbE : 1 stream = ~15 GbE
  • 40 GbE : 2 streams = ~30 GbE
  • 50 GbE : 3 streams = ~45 GbE
  • 100 GbE : 6 streams = ~90 GbE

Это означает, что вам потребуется шесть VMkernel интерфейсов для vMotion на одном ESXi хосте, чтобы иметь возможность эффективно использовать доступную полосу пропускания при использовании 100GbE сетевого адаптера.

Недостатком создания дополнительных VMkernel интерфейсов является высокие эксплуатационные затраты. Все VMkernel интерфейсы должны быть созданы на всех ESXi хостах и им должны быть назначены IP-адреса. Масштабирование такого решения может значительно увеличить сложность эксплуатации. Эту задачу можно довольно легко автоматизировать с помощью PowerCLI, но необходимость в дополнительных IP-адресах сохраняется.

Вариант 2: Улучшение производительности одного vMotion VMkernel интерфейса

Note: В первой версии этого поста я упомянул о необходимости использования vsi shell для изменения этих параметров. К счастью, у нас есть другой метод.

Для начала посмотрим текущие настройки:

На приведенном выше скриншоте показаны значения по умолчанию для обоих параметров в vsi shell’е. Поскольку изменения в vsi shell не перманентные и не рекомендуется, давайте найдем advanced параметры ESXi хоста, которые соответствуют параметрам vsi shell.

/net/tcpip/defaultNumRxQueue соответствует advanced параметру Net.TcpipRxDispatchQueues
/config/Migrate/intOpts/VMotionStreamHelpers
соответствует advanced параметру Migrate.VMotionStreamHelpers

Важно отметить, что по умолчанию для параметра VMotionStreamHelpers установлено значение “0”, для динамического выделения одного потока на IP. Так как это может измениться в следующих релизах, будьте внимательны, когда вы изменяете этот параметр. Если мы изменяем значение параметра VMotionStreamHelpers, параметр TcpipRxDispatchQueues должен быть изменен соответствующим образом. Обратите внимание, что увеличение значения TcpipRxDispatchQueues увеличит потребление памяти ESXi хоста.

Чтобы изменить эти параметры, мы можем воспользоваться графическим интерфейсом ESXi хоста. В этом примере мы увеличим количество Rx-очередей и stream helper до двух на VMkernel интерфейс.

По аналогии с графическим UI, вы также можете использовать PowerCLI для выполнения этой же задачи:

Get-AdvancedSetting -Entity <esxi host> -Name Net.TcpipRxDispatchQueues | Set-AdvancedSetting -Value '2'Get-AdvancedSetting -Entity <esxi host> -Name Migrate.VMotionStreamHelpers | Set-AdvancedSetting -Value '2'

После изменения обоих параметров, ESXi хост должен быть перезагружен, чтобы они вступили в силу. Теперь, у нас есть только один VMkernel интерфейс, но при живой миграции запускается несколько helper’ов.

Хотя это отличное решение, его реализация требует ручной настройки и перезагрузки хоста ESXi.

Результат

Итог

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

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