У нас есть сервер ESXi 4.1 с 48 ГБ оперативной памяти.
Для каждой виртуальной машины мы выделяем 4 ГБ памяти. Поскольку на сервере будет 13 виртуальных машин, мой менеджер считает это неправильным.
Я собираюсь объяснить им, что ESXi фактически будет управлять памятью, но они спросили меня, сколько памяти я выделил для самого сервера ESXi.
Я не выделял (я даже не слышал о возможности выделения памяти для самого сервера ESXi).
Как распределяется память для сервера ESXi? Как без проблем перераспределять / перераспределять оперативную память между виртуальными машинами?
Речь идет не только о ESXi,
Объяснение распределения памяти и чрезмерной нагрузки
Обратите внимание, что гипервизор не будет выделять всю эту память заранее, это зависит от использования виртуальной машины. Однако стоит понять, что произойдет, если виртуальные машины попытаются выделить и использовать всю выделенную им память.
Максимум, который ваш хост VM + попытается использовать, будет примерно 55 ГБ пробег может отличаться
Есть еще один аспект, который следует учитывать, и это пороги памяти. По умолчанию VMware стремится иметь 6% свободной памяти (высокий порог памяти). Так что 55 ГБ используемой памяти необходимо уменьшить до ~ 45 ГБ
Это означает, что у хоста будет примерно 10 500 МБ памяти, которую он должен откуда-то вернуть, если виртуальные машины будут использовать выделенную им память. ESX делает три дополнительных действия, чтобы найти эти дополнительные 10,5 ГБ.
Методы восстановления памяти
Вы должны прочитать и понять Общие сведения об управлении ресурсами памяти на сервере VMware® ESX ™.
В зависимости от большого количества факторов, комбинация всех трех будет / может произойти на чрезмерно активном хосте. Вам необходимо протестировать свою среду и отслеживать эти показатели, чтобы понять влияние чрезмерной фиксации.
Некоторые грубые правила, которые стоит знать (все в указанной выше статье и в других источниках).
В системах виртуализации памяти с аппаратной поддержкой (например, Intel EPT Hardware Assist и AMD RVI Hardware Assist [6]) ESX автоматически поддерживает гостевые физические страницы с большими физическими страницами хоста (2 МБ непрерывной области памяти вместо 4 КБ для обычных страниц) для лучшая производительность за счет меньшего количества промахов TLB. В таких системах ESX не будет совместно использовать эти большие страницы, потому что: 1) вероятность обнаружения двух больших страниц с одинаковым содержимым мала и 2) накладные расходы на побитовое сравнение для страницы 2 МБ намного больше, чем для страницы размером 4 КБ. Однако ESX по-прежнему генерирует хэши для страниц размером 4 КБ на каждой большой странице. Поскольку ESX не заменяет большие страницы, во время обмена хостами большая страница будет разбита на маленькие страницы, чтобы эти заранее сгенерированные хэши можно было использовать для совместного использования маленьких страниц, прежде чем они будут заменены. Короче говоря, мы не можем наблюдать какое-либо совместное использование страниц для систем виртуализации памяти с аппаратной поддержкой, пока память хоста не будет чрезмерно загружена.
Полеты на воздушном шаре начинается следующее (пороговые значения настраиваются, по умолчанию это происходит, когда на узле меньше 6% свободной памяти (между высоким и программным)). Убедитесь, что вы установили драйвер, и следите за Java и удалось приложения в целом. ОС не имеет представления о том, что сборщик мусора будет делать дальше, и в конечном итоге попадет на страницы, которые были перенесены на диск. Не редкость, когда серверы, на которых запускаются приложения Java, полностью отключают свопинг, чтобы гарантировать, что этого не произойдет. Взгляните на страницу 17 vSphere Memory Management, SPECjbb
Замена гипервизора, из трех методов единственный, гарантии «память», доступная гипервизору в установленное время. Это будет использоваться, если 1 и 2 не дают достаточно памяти, чтобы оставаться под жесткий порог (по умолчанию 2% свободной памяти). Когда вы прочитаете метрики производительности (сделаете свои собственные), вы поймете, что это худшая из трех показателей. Стремитесь избежать этого любой ценой, поскольку влияние на производительность будет очень заметно почти во всех приложениях. двузначный процент
Есть еще одно состояние, о котором нужно знать низкий (по умолчанию 1%). Из руководства это может резко снизить вашу производительность,
В редком случае, когда объем свободной памяти хоста падает ниже нижнего порога, гипервизор продолжает восстанавливать память посредством подкачки и сжатия памяти и дополнительно блокирует выполнение всех виртуальных машин, которые потребляют больше памяти, чем их целевые распределения памяти.
Резюме
Ключевым моментом для стресса является то, что невозможно предсказать из технических документов, как будет вести себя ваша среда.
Протестируйте свои средние сценарии, ваш 95% -ный процентильный сценарий и, наконец, ваш максимум, чтобы понять, как будет работать ваша среда.
Редактировать 1
Стоит добавить, что с vSphere 4 (или 4.1 не могу вспомнить) теперь можно разместить своп гипервизора на локальном диске, но все же vmotion ВМ. Если вы используете общее хранилище, я настоятельно рекомендую вам переместить файл подкачки гипервизора по умолчанию на локальный диск. Это гарантирует, что когда один хост испытывает серьезную нехватку памяти, это не повлияет на все остальные хосты / виртуальные машины vSphere в том же общем хранилище.
Редактировать 2
На основании комментариев сделан тот факт, что ESX не выделяет память заранее жирным шрифтом ...
Редактировать 3
Разъяснил еще немного о порогах памяти.
VMware (и другие технологии виртуализации) Поделиться ресурсы (память, время процессора, различные виды ввода-вывода) между виртуальными машинами по различным алгоритмам.
Возможно чрезмерно усердствовать ресурсов, потому что не все виртуальные машины будут использовать всю необходимую им обработку, память или ввод-вывод все время. Руководство VMware по управлению ресурсами вероятно, лучшее место, чтобы узнать о возможностях ESXi.
Вы также можете управлять эффектом алгоритмов, взвешивая разные виртуальные машины для разных ресурсов - например, вы можете дать виртуальной машине сервера приложений больший вес для процессора, чем виртуальной машине файлового сервера. Однако стандартные настройки очень хорошо справятся с большинством требований. В некоторых случаях здесь достаточно выполнить некоторую настройку, чтобы успокоить менеджеров, которые этого не совсем понимают, но, конечно, будьте осторожны, прочтите документацию для своей версии VMware и поймите, что вы делаете. Если ваш менеджер не нуждается в дальнейшем усмирении, просто используйте настройки по умолчанию.
Обратите внимание, что чрезмерное использование не всегда является хорошей идеей, особенно если вы виртуализировали на одном сервере. Вам следует контролировать использование ресурсов в вашем ESXi-состоянии и при необходимости добавлять дополнительные хосты / ресурсы, если вы часто потребляете все один или несколько ресурсов.
Позвольте вашей установке VMWare ESXi справиться с этим. Вы можете чрезмерно использовать ресурсы ОЗУ в системах VMWare из-за использования методы раздува памяти, сжатия и дедупликации.
Если на виртуальных машинах используется аналогичная операционная система, это дает некоторую экономию. Обязательно включите инструменты VMWare внутри гостевой виртуальной машины, чтобы в полной мере использовать эти функции.