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

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

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

Streams and Threads

Чтобы понять, как мы можем улучшить производительность vMotion и тем самым сократить время живой миграции, нам сначала нужно понять концепцию потоков vMotion (vMotion Streams). Архитектура потоков в vMotion впервые была представлена ​​в vSphere 4.1 и с тех пор была доработана и улучшена. Одним из предварительных условий для выполнения живых миграций является настроенная для vMotion сеть. Для работы vMotion вам необходим как минимум один интерфейс VMkernel, для которого включен vMotion трафик, на соответствующих ESXi хостах.

Если у вас есть интерфейс 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

У нас есть некоторые способы минимизировать риск быть ограниченными одним ядром процессора. Наиболее простым решением является создание большего количества потоков vMotion (vMotion Stream), которые содержат stream helper’ы. Для этого у нас есть два варианта.

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

Возможно, самый простой способ добиться этого — настроить несколько 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 интерфейса

У нас есть другой вариант. Применение этого варианта позволит избежать увеличения количества VMkernel интерфейсов и требуемых IP-адресов, как в первом варианте. Однако, это действительно продвинутый вариант, который требует ручной настройки каждого ESXi хоста. У нас есть возможность задать как количество vMotion stream helper’ов, так и количество Rx-очередей для VMkernel интерфейсов, для которых включен vMotion.

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.

Результат

В результате мы получили сценарий, при котором мы можем эффективно использовать доступную пропускную способность для vMotion. Это также означает, что у нас и загрузка CPU более равномерная, потому что теперь мы используем несколько потоков и, следовательно, несколько ядер ЦП. Особенно при серьезных рабочих нагрузках, настройка vMotion может помочь значительно сократить время живой миграции.

Итог

Приятно осознавать, что сегодня у нас есть несколько вариантов полной утилизации сетей с высокой пропускной способностью для vMotion. Однако оба варианта требуют ручной настройки. И хотя вы можете автоматизировать соответствующие операции, мы предпочли бы сделать это более простым для вас. Вот почему мы думаем о том, чтобы сделать все это более удобным способом. Было бы замечательно, если бы следующий релиз vSphere мог бы определить пропускную способность сети и сетевого адаптера и самостоятельно изменить соответствующие параметры для vMotion. Сегодня вы можете настроить их вручную.