Для ЛЛ: Мало кто знает, например, что у слова "дно" есть форма множественного числа - и это не "днища", а "донья".
С пару лет назад я почти перестал читать Хабр, а с год назад читать перестало иметь смысл – ну окей, печатный орган министерства по борьбе с ИТ репостит статьи «Как мы в едином порыве одобряем устаревание серверов Гугля» или «депутат, которому интернет приносят в папке, сказал что-то». Добавить унылые копроблоги с песнями «у нас все хорошо, вовсе мы и не валялись неделю, ваш МТС» и «приходите к нам, у нас есть откаты» (это не МТС и статью уже удалили).
Фоном идут комментаторы вида «я увидел вашу статью в два ночи и немедленно вспомнил пароль от аккаунта, который не использовал три года, вот насколько мерзотная ваша статья».
Однако, наш дурдом зажигает огни, и к статьям про похудение, поведение, дистанционное управление добавили статьи от маркетологов, которым статью писал ЯндексЖПТ. Ничем иным объяснить такой упешный поиск на ровном месте, на бильярдном столе, ямы с г, объяснить невозможно.
Статья называется “Я проверил, сколько вы платите за одинаковое железо в разных облаках”, и такого донного уровня я не видел с тех пор, как Гилева в очередной раз тыкали носом в абсолютное не понимание того, как работают виртуальные среды. Довели беднягу Гилева – он и комментарии удалил, и профиль удалил.
Что же в статье не так? Для начала, это статья в копроблоге «H3LLO.CLOUD» - то есть, никакой адекватности от нее ждать не приходится, но это еще ладно.
Шутки начинаются с самого начала:
Чем короче полоска, тем, вероятно, больше вас переподписывают или более старое железо предлагают. Что это за график — ниже
Идея очень простая: покупаю одинаковые тарифы на одинаковом железе
Так все же, автор заказывает одинаковое железо или не совсем одинаковое? Похоже, что автор вообще не понимает, что он покупает в облаке, и дальше наглядно это демонстрирует.
Но, перед тем как идти дальше, будет немного Пикабу образовательного.
Образовательное будет обязательно содержать ошибки и опечатки. Я недавно смог спутать Эдди Мерфи и Орландо Джонса, и нет мне оправдания. Ну хоть не спутал с Кетрин Зета Джонс.
Серверная виртуализация работает (в части управления процессорами) очень просто.
Сначала все процессорное время разбивается на слоты (слайсы). Примерно по 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 или, возможно, разнородное железо в кластерах облака. Но, ничего этого не сделано.
В очередной раз убедиться в том, что есть корреляция "компания дно" и "компания ведет дноблог на хабре" - бесценно.
