Лига Сисадминов

Шутки начинаются с самого начала:
Чем короче полоска, тем, вероятно, больше вас переподписывают или более старое железо предлагают. Что это за график — ниже
Идея очень простая: покупаю одинаковые тарифы на одинаковом железе

Так все же, автор заказывает одинаковое железо или не совсем одинаковое? Похоже, что автор вообще не понимает, что он покупает в облаке, и дальше наглядно это демонстрирует.

Но, перед тем как идти дальше, будет немного Пикабу образовательного.

Образовательное будет обязательно содержать ошибки и опечатки. Я недавно смог спутать Эдди Мерфи и Орландо Джонса, и нет мне оправдания. Ну хоть не спутал с Кетрин Зета Джонс.

Серверная виртуализация работает (в части управления процессорами) очень просто.
Сначала все процессорное время разбивается на слоты (слайсы). Примерно по 0.05 секунды.
Каждые 2-30 миллисекунд (1/1000 секунды) планировщик проверяет нагрузку на физических ядрах, и выдает таймслот (слайс) для исполнения vCPU <> pCPU.
для ESXi таймслот (слайс) по умолчанию – 50 миллисекунд.
vSphere 6.7 U2 & later CPU Scheduler modes: Default, SCA v1 and SCA v2
Performance of vSphere 6.7 Scheduling Options, 2019

Для Hyper-V размеры этого слота в открытой документации где-то были, но это не точно.
Для KVM и Xen мне лень искать.

Дальше начинается магия. Для тех, кто документацию и книги не читает, вся жизнь наполнена чудесами и магией, но, впрочем, как говорил один покойник, any sufficiently advanced technology is indistinguishable from magic.

Все современные сервера идут с преднастройками High performance \ Balanced \ Optimal power, плюс с возможностью авторазгона части ядер, плюс с вариантом «как именно спит процессор» - в C1 или C6, с mwait или без. И заодно угадайте, настраивает ли клауд провайдер свои сервера оптимальным образом, а точнее, проверяет ли их настройки, особенно после обновлений BIOS, и обновляет ли он этот BIOS.

У виртуальных машин могут быть приоритеты. Для процессорных ядер желательно, чтобы данные были в пределах Numa ноды. Для многопроцессорных машин желательно удерживать Strict Co–Scheduling или хотя бы Relaxed Co-scheduling. Дальше есть Latency Sensitivity. И все это время никакой жесткой привязки контекста исполнения процесса виртуальной машины к ядру – нет.

И только после этой магии, раздачи задач на CPU scheduler, начинается явление «переподписки» или соотношение:
«сколько всего виртуальных ядер выделено на все виртуальные машины хоста : сколько ядер (физических) у нас есть. При этом, поскольку у нас (обычно, так то сделать можно) нет никакого жесткого прибивания «этот контекст исполняется здесь», то переподписка может нас волновать, а может и не волновать. Если у вас сервер набит только базами данных, то лучше не надо, если какие-то веб сервисы, то и 4:1 нормально. Если VDI, то и 10:1 ок.
Статьи и заметки по теме:
Acceptable logical CPU oversubscription and vCPU ready time ;
CPU Oversubscription.
Дальше начинается общеизвестный факт, что CPU планировщик в ESXi будет получше планировщика в Linux – KVM (Red hat), что и дает ощутимые бонусы при переподписке. Если же у инженеров облака руки не кривые, то какие-то настройки KVM они покрутят. Но это не точно.

Теперь, вспомнив базу, вернемся к методике измерений в статье.

В качестве тестов был использован Geekbench 6, но не указано – он был взят «из коробки» или собран. Если из коробки, то из какой? Если собран, то как?

Как легко заметить из текста ниже, автор вообще не заморочился привести модель процессора, которую ему, кстати, гипервизор в виртуальную среду отдает. Как и не показал фактическую рабочую частоту процессора при тестах.

Не менее интересно, что автор вместо попыток анализа, написал про ощущение переподписки. Не попытку оценить CPU ready \ Cpu Steal Time. Ничего. Только «ощущения» и «чувствуется». В отрыве от частоты и каких-то метрик, кроме выполнения рандом теста.

В комментариях творится парад бреда, вида “Shared/Dedicated CPU”. Azure, например, оперирует только Azure Dedicated Hosts, в AWS тоже такого странного выбора нет – см. Supported CPU options for Amazon EC2 instance types.

Или де в комментариях автор статьи (km1337) пишет

Это когда физический CPU распределяется между несколькими виртуальными машинами так, что каждая использует достаточно малую его часть.

Как легко заметить, никакого разделения физических ядер \ CPU по частям нет. Есть очередь исполнения, есть планировщик набивания очереди исполнения. Конечно, при богатой фантазии это можно представить и как «разделение».

Огня в комментариях добавляет и Timeweb_Cloud с их:
У нас не OpenStack, а собственный KVM еще с 2016 года. Все компоненты кастомные и запатентованные.

OpenStack все же оркестратор, а KVM – гипервизор. В переводе на русский, звучит как-то на уровне «у нас управление движением автобусов идет не на автостанции, у нас свой автобус».

Далее надо сказать, что даже для трех серверов можно настроить DRS, Distributed Resource Scheduler, который будет пытаться отбалансировать виртуальный машины так, чтобы нагрузка была сделана более-менее равномерно в пределах кластера. Поскольку у автора статьи за сутки ничего не произошло, то вопрос, который можно было поднять, это именно работа DRS или, возможно, разнородное железо в кластерах облака. Но, ничего этого не сделано.

Модная концовка.

В очередной раз убедиться в том, что есть корреляция "компания дно" и "компания ведет дноблог на хабре" - бесценно.