Почему вам нужно проверить конфигурацию NUMA вашего хоста виртуализации
Еще во времена Windows Server 2012, когда Hyper-V впервые начал полностью поддерживать архитектуру NUMA, в большинстве руководств по передовому опыту, которые я читал, говорилось, что виртуальные машины не должны охватывать несколько узлов NUMA. Причина для этой конкретной передовой практики заключалась в том, что растягивание виртуальной машины между узлами NUMA может привести к снижению ее производительности. Хотя определенно есть что сказать о том, как добиться оптимальной производительности ваших виртуальных машин, существуют определенные ситуации, в которых может быть выгодно разрешить виртуальной машине охватывать несколько узлов NUMA.
Проблемы с производительностью узла NUMA
Как упоминалось ранее, обычно рекомендуется настроить Hyper-V таким образом, чтобы по возможности запрещалось использование NUMA. Если хост-сервер Hyper-V содержит несколько физических процессоров, сокеты памяти располагаются таким образом, который имитирует архитектуру ЦП. Например, система с двумя физическими процессорами будет иметь два (или более) узла NUMA. Причина, по которой это важно, заключается в том, что каждый процессор имеет память, которая считается локальной для процессора. Процессор, конечно, может получить доступ к нелокальной памяти (памяти, которая является локальной для другого процессора в системе), но при этом возникает значительная задержка, поскольку процессор не может получить доступ к этой памяти напрямую. Таким образом, виртуальная машина Hyper-V будет иметь наилучшую производительность, если она будет ограничена использованием памяти, которая является локальной для ядер ЦП, на которых работает виртуальная машина.
Зачем охватывать узлы NUMA?
Hyper-V настроен по умолчанию, чтобы позволить виртуальным машинам охватывать узлы NUMA, как показано на рисунке ниже. Это, конечно, поднимает вопрос о том, почему Microsoft решила включить охват NUMA по умолчанию, когда отключение охвата NUMA обычно приводит к повышению производительности.
Есть по крайней мере три причины, по которым по умолчанию допускается охват узлов NUMA. Во-первых, тот факт, что виртуальным машинам разрешено охватывать несколько узлов NUMA, не означает, что так и будет. Основываясь на моем собственном опыте (я не могу найти документацию, подтверждающую или опровергающую это), кажется, что Hyper-V растягивает виртуальную машину между узлами NUMA только в том случае, если у нее нет другого выбора. Большую часть времени Hyper-V, кажется, прилагает согласованные усилия, чтобы избежать того, чтобы виртуальные машины занимали несколько узлов NUMA.
Во-вторых, запрет охвата NUMA ограничивает общий объем памяти, который может быть выделен виртуальной машине (при условии, что используется динамическая память). Рассмотрим, например, что мой лабораторный сервер содержит 256 ГБ оперативной памяти, разделенной на два узла NUMA. Если бы я отключил охват узлов NUMA, то Hyper-V не позволил бы динамически назначать виртуальной машине более 128 ГБ ОЗУ (на самом деле предел был бы немного ниже из-за накладных расходов операционной системы хоста). Позвольте мне показать вам пример.
Если вы посмотрите на рисунок ниже, вы увидите, что я отключил NUMA spanning и создал новую виртуальную машину со 130 ГБ оперативной памяти. Помните, что на хосте установлено 256 ГБ оперативной памяти, поэтому я выделил чуть больше половины памяти хоста. Никакие другие виртуальные машины в настоящее время не работают.
Если я попытаюсь запустить виртуальную машину, Hyper-V выдаст сообщение об ошибке, подобное показанному ниже, указывающее, что виртуальную машину не удалось запустить из-за нехватки памяти. Вы также заметите, что диспетчер задач указывает, что на хосте достаточно памяти. Единственное, что мешает запуску виртуальной машины, это то, что я запретил Hyper-V распределять виртуальную машину по узлам NUMA.
Третья причина, по которой вы можете не захотеть отключать охват NUMA, заключается в том, что это может снизить общую плотность виртуальных машин. Как я только что показал вам, Hyper-V предотвратит запуск виртуальной машины, если ее память выделяется динамически, а требования к памяти виртуальной машины превышают объем памяти, доступный в пределах одного узла NUMA. Имея это в виду, представьте ситуацию, в которой у сервера Hyper-V достаточно памяти и он может с комфортом разместить дополнительные виртуальные машины, но доступная память разбросана по узлам NUMA. Эти дополнительные виртуальные машины не смогут запуститься, потому что если на отдельных узлах NUMA не останется достаточно памяти для удовлетворения потребностей виртуальной машины. Конечным результатом будет недостаточно загруженный сервер. Хост имеет дополнительные ресурсы памяти, но его политика охвата NUMA не позволяет использовать эту память.
Если вы не пытаетесь активно достичь максимально возможной плотности виртуальных машин на своих хостах, то идея иметь часть памяти, которую ваши виртуальные машины не могут использовать, может показаться не такой уж большой проблемой. Однако вполне возможно, что при правильных обстоятельствах запрещение охвата NUMA может привести к сбою динамической миграции. Для этого виртуальная машина, которая подвергается динамической миграции, должна быть настроена на использование динамического выделения памяти, а на целевом узле должно быть слишком мало памяти, оставшейся на любом узле NUMA, чтобы разместить виртуальную машину.
Взвесьте все за и против
Хотя некоторые уже давно заявляют, что вам никогда не следует распределять виртуальную машину по узлам NUMA, есть несколько вполне законных вариантов использования для этого. Таким образом, важно взвесить все за и против охвата NUMA, а не жестко придерживаться идеи о том, что охват узлов NUMA — плохая идея. С одной стороны, предотвращение использования объединения узлов NUMA может помочь обеспечить оптимальную производительность виртуальной машины. С другой стороны, разрешение охвата узлов NUMA может позволить вам создавать более крупные виртуальные машины, а также позволит вашему узлу Hyper-V достичь более высокой общей плотности виртуальных машин.
Кроме того, теоретически возможно, что охват NUMA действительно улучшит производительность ВМ. Представьте, что для виртуальной машины выделено совершенно недостаточное количество памяти. Виртуальная машина не будет работать очень хорошо из-за нехватки памяти. Если бы той же виртуальной машине было разрешено охватывать узлы NUMA, администратор мог бы выделить для нее больше памяти, чем это было возможно ранее, тем самым преодолевая узкое место памяти.