Я пытаюсь понять избыточное выделение виртуальных ЦП по сравнению с избыточной подпиской на виртуальные ЦП.
Для целей вопроса предположим, что хост, который я буду использовать, имеет 16-ядерный Xeon (2,1 ГГц).
На основании моего исследования подписки, виртуальные машины подписаны на большее количество ресурсов, чем доступно на узле ESXi. Таким образом, обычно предпочтительнее соотношение ресурсов к подписке 1: 1, но можно рекомендовать соотношение 1: 3. Поэтому, если у меня включена гиперпоточность, у меня будет всего 32 виртуальных ЦП, а рекомендуемая дополнительная подписка будет равна 32 * 3 = 96 виртуальных ЦП в сумме для всех виртуальных машин на хосте. Правильно ли я смотрю на это, или при подписке не следует учитывать гиперпоточность?
Когда я смотрю на распределение ресурсов vCPU, я вижу, что вы можете зарезервировать, ограничить или установить приоритеты ресурсов vCPU. Предполагая, что мой хост резервирует минимальный ресурс виртуальных ЦП на 339 МГц, правильно ли предположить следующее:
1) vCPU без гиперпоточности (16) -> Всего 336000 Mhz -> 99 одиночных vCPU VM
2) vCPU с гиперпоточностью (32) -> Всего 672000 Mhz -> 198 одиночных vCPU VM
Что произойдет в приведенном выше сценарии, когда несколько из этих виртуальных машин имеют разные максимальные ограничения и им одновременно требуется ресурс vCPU? Представляется ли избыточное выделение использованием большего количества ресурсов, чем может предоставить один виртуальный ЦП? Например, у vCPU 2,1 ГГц, но для одной виртуальной машины я резервирую 2,5 ГГц, так что он должен «заимствовать» ресурсы у другого vCPU.
Вы пытаетесь понять проблему с самого сложного - ресурсов процессора. Подойдите к нему по памяти, и это будет немного легче понять.
Хост имеет x количество памяти, а хост резервирует y количество памяти для своих гнусных целей (что, кстати, следует формуле a MB изначально и b MB для каждой включенной виртуальной машины). Если вы не разрешаете избыточную подписку / выделение, вы назначаете своим виртуальным машинам всего x - y, и каждая виртуальная машина всегда может получить выделенную память. Однако это очень неэффективно, поэтому вы обычно чрезмерно выделяете память своим машинам. Если в вашей политике указано, что 3: 1 в порядке, вы можете назначить 3 * (x-y) своим виртуальным машинам (или практически 3x, поскольку объем, необходимый VMware ESXi, ничто по сравнению с общим объемом памяти).
Если у хоста заканчивается память, он сначала пытается раздуть (который начинается с 95% использования), где он через VMtools начинает запрашивать память у гостевой ОС, а затем удаляет все страницы, которые он получает (как и все, что ОС дает балуну драйвер в настоящее время не используется ОС, поэтому его можно безопасно удалить). Если это не помогает, ESXi делает то, что делает любая другая операционная система, когда у нее заканчивается память, она начинает перекачивать память на диск. ESXi делает это для каждой виртуальной машины (поскольку он должен учитывать общие ресурсы, резервирование и ограничения).
vCPU работают немного по-другому, поскольку технически это не ресурс, как память и диск (я имею в виду, что 20-ядерный ЦП 2 ГГц - это не то же самое, что 1-ядерный ЦП 40 ГГц, не так ли?). Прежде всего, Hyperthreading не дает вам вдвое больше ядер, по официальным данным VMware, HT дает прирост производительности примерно на 10-30%. Во-вторых, vCPU мультиплексируются, поэтому планировщик выделяет временные интервалы на pCPU для различных vCPU. Таким образом, если у вас есть 8-ядерный ЦП на вашем хосте, он может запускать либо 8 виртуальных машин с 1 виртуальным ЦП за один такт, либо 1 8-виртуальный ЦП. Это создает проблему, заключающуюся в том, что на сильно загруженном хосте вы можете увидеть падение производительности из-за назначения большего количества ядер виртуальной машине, поскольку планировщику сложно найти достаточно большой временной интервал для запуска более крупной виртуальной машины.
Доли, оговорки и ограничения - это способ обойти некоторые из этих проблем.
Бронирование являются гарантией, иначе. если вы дадите виртуальной машине зарезервировать 500 МГц, гипервизор предоставит ей 500 МГц независимо от того, что происходит на хосте. Однако, если резервирование в данный момент не используется, оно пока что передаст ресурсы другой виртуальной машине (так что вы никогда не тратите ресурсы, устанавливая резервирования).
Пределы с другой стороны установить жесткую «крышу» или заглушку на ресурс. Это полезно, если вы хотите, чтобы виртуальная машина считала, что у нее больше ресурсов, чем она может получить на самом деле. На самом деле это не имеет практического применения (оно использовалось в более ранних версиях ESXi как способ горячего добавления памяти путем снятия ограничения) сегодня, кроме обмана поставщиков программного обеспечения, и в этом тоже не очень полезно. Ограничения вводятся безжалостно, поэтому, если вы назначите ограничение в 1 ГБ памяти для машины с настроенными 4 ГБ, эта машина никогда не получит более 1 ГБ физической памяти.
Акции немного отличаются, они позволяют «взвесить» «важность» конкретной виртуальной машины, когда дело касается различных ресурсов. В ESXi все виртуальные машины равны, и при конкуренции за ресурсы 2 виртуальные машины с 1000 общими ресурсами каждая будут получать ресурсы в 50% случаев. Изменив доли, чтобы сказать 3000 против 1000, вы можете изменить деление на 75% / 25%. Общие ресурсы используются только тогда, когда виртуальные машины конкурируют за ресурсы.
Итак, чтобы на самом деле ответить на ваш вопрос, избыточное выделение означает, что вы назначаете, например, 32 виртуальных ЦП (2 ГГц каждый) своим виртуальным машинам на хосте, который имеет 16-ядерный ЦП без HT. У вашего ЦП 32 ГГц «доступно», но вы назначили 64 ГГц своим виртуальным машинам. Это перераспределение / подписка 2 к 1. Но если вы что-то знаете о серверах, так это то, что они большую часть времени простаивают, поэтому ваш хост может не видеть нагрузки более 16 ГГц. Но теоретически такая установка может вызвать потребность в частоте 64 ГГц, что приведет к задержке вашего хоста. HT не очень полезен для этих расчетов, но вы могли бы добавить 25% к своему значению «non-HT» ГГц, чтобы получить некоторое представление о его преимуществах.