Перейти к основному содержимому

9.5 Механизм адаптивной квантизации vCPU

В слое программно-определяемых вычислений (SDC) платформы vStack присутствует механизм адаптивной квантизации виртуальных ядер (vCPU). Этот механизм позволяет:

  1. Решить проблему "шумного соседа" в облачной инфраструктуре.
  2. Исключить чрезмерное потребление ресурса CPU слоем SDC, при котором слоям SDS и SDN не останется ресурса CPU.
  3. Обеспечить корректную работу в условиях переподписки CPU.

Бюджет vCPU — значение, уменьшающееся при использовании ресурса vCPU и увеличивающееся при его простаивании, т.е. когда vCPU бездействует.

При исчерпании бюджета vCPU предоставление квантов vCPU происходит с задержкой, определяемой параметром delay_ms. Процент квантов, определяемый параметром rate_limit, обслуживается без ограничений. При этом возможны всплески высокого потребления vCPU ресурса, в течение которых бюджет vCPU не потребляется. Длительность этого периода определяется параметром burst_secs.

По умолчанию виртуальной машине назначается vCPU-класс 1, параметры которого динамически изменяются системой исходя из утилизации ресурса CPU узла.

vCPU-класс 2 является классом, в который системой автоматически перемещаются виртуальные машины, чрезмерно (более X% в течение Y секунд) использующие ресурс vCPU (т.н. "шумный сосед"), поэтому конфигурация этого класса предполагает значимые ограничения. В случае прекращения подобного чрезмерного потребления ресурса vCPU такая виртуальная машина возвращается в vCPU-класс 1. Рестарт такой виртуальной машины тоже вернёт её в vCPU-класс 1.

В vCPU-классе 0 отсутствуют ограничения потребления ресурса vCPU. Этот класс предназначен для виртуальных машин, к которым не нужно применять механизм ограничений предоставления квантов vCPU.

Параметры классов 2-9 могут регулироваться владельцем системы исходя из модели потребления слоя SDC.

Рисунок 1. Конфигурация vCPU-класса 2

Эффект работы со стороны ВМ

Рассмотрим различные примеры функционирования одной и той же виртуальной машины с единственным vCPU.

На графике ниже показан бюджет vCPU виртуальной машины в vCPU-классе 1. Примерно к 21:23 бюджет был исчерпан в силу потребления ресурса vCPU, а примерно в 21:25:30 размер бюджета был восстановлен, так как потребление ресурса vCPU остановилось. Из-за достаточности ресурса CPU узла, на котором работала эта виртуальная машина, ограничений в отношении предоставления ей квантов vCPU не происходило.

Рисунок 2. Бюджет единственного ядра виртуальной машины в vCPU-классе 1

Рассмотрим тот же самый сценарий, переместив предварительно виртуальную машину в vCPU-класс 2.

Рисунок 3. Бюджет виртуальной машины в vCPU-классе 2

На графике появилась оранжевая область – ограничение потребления vCPU. Нетрудно заметить, что в данном случае в конфигурации vCPU-класса 2 определён rate_limit равный 25.

Со стороны гостевой операционной системы влияние ограничений этого механизма тождественно снижению производительности vCPU, что можно наблюдать даже в простейшем тесте, продемонстрированном ниже.

Производительность нашей виртуальной машины в первом случае, когда она находилась в vCPU-классе 1:

[root@AltLinux-vCPU-class-demo ~]# openssl speed -seconds 5 -evp md5
Doing md5 for 5s on 16 size blocks: 41716100 md5's in 5.00s
Doing md5 for 5s on 64 size blocks: 23288920 md5's in 4.99s
Doing md5 for 5s on 256 size blocks: 10440469 md5's in 5.00s
Doing md5 for 5s on 1024 size blocks: 3154491 md5's in 5.00s
Doing md5 for 5s on 8192 size blocks: 431544 md5's in 5.00s
Doing md5 for 5s on 16384 size blocks: 214734 md5's in 4.98s

Производительность виртуальной машины, которая была помещена в vCPU-класс 2:

[root@AltLinux-vCPU-class-demo ~]# openssl speed -seconds 5 -evp md5
Doing md5 for 5s on 16 size blocks: 8854027 md5's in 5.00s
Doing md5 for 5s on 64 size blocks: 5111982 md5's in 5.01s
Doing md5 for 5s on 256 size blocks: 2062322 md5's in 5.00s
Doing md5 for 5s on 1024 size blocks: 676658 md5's in 5.07s
Doing md5 for 5s on 8192 size blocks: 93456 md5's in 5.03s
Doing md5 for 5s on 16384 size blocks: 44711 md5's in 5.03s

Падение производительности составляет от 79% до 81%.

Эффект работы со стороны узла

На Узле кластера vStack функционирование этого механизма становится более интересным в силу различной интенсивности потребления ресурса CPU узла разными виртуальными машинами и дискретностью применения ограничений.

Рисунок 4. Утилизация узла кластера vStack с 40 ядрами

На данном узле работают 72 виртуальные машины с различной степенью утилизации своих ядер (первая панель сверху). На второй панели отображён график изменения системой параметра rate_limit vCPU-класса 1 данного узла. Во время значимого потребления ресурса CPU узла этот параметр уменьшается, тем самым снижая количество квантов vCPU, которые обслуживаются без ограничений.

ВАЖНО

Это снижение касается только виртуальных машин, израсходовавших свой бюджет vCPU.

График ограничений предоставления квантов vCPU предоставлен на самой нижней панели: из 72 виртуальных машин ограничениям предоставления квантов vCPU подверглись только 15. При этом значимым ограничениям подверглись только 3 виртуальные машины, 12 оставшихся подверглись ограничениям, сопоставимым с производительностью 0,1–0,5 vCPU. 57 остальных виртуальных машин работали без ограничений.

Заключение

Использование данного механизма не только упрощает технические моменты эксплуатации решения, но и обеспечивает возможность работы в условиях переподписки ресурса CPU, что повышает экономическую эффективность виртуальной инфраструктуры, построенной с помощью платформы vStack.