Механизм адаптивной квантизации vCPU в платформе vStack¶
В слое программно-определяемых вычислений (SDC) платформы vStack присутствует механизм адаптивной квантизации виртуальных ядер (vCPU). Этот механизм позволяет:
- Решить проблему "шумного соседа" в облачной инфраструктуре.
- Исключить чрезмерное потребление ресурса CPU слоем SDC, при котором слоям SDS и SDN не останется ресурса CPU.
- Обеспечить корректную работу в условиях переподписки 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
[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.