Как распределяется память на сервере ESXi?

У нас есть сервер ESXi 4.1 с 48 ГБ оперативной памяти.

Для каждой виртуальной машины мы выделяем 4 ГБ памяти. Поскольку на сервере будет 13 виртуальных машин, мой менеджер считает, что это неправильно.

Я собираюсь объяснить им, что ESXi фактически будет управлять самой памятью, но они спросили меня, сколько памяти я выделил для самого сервера ESXi.

Я не выделил ничего (я даже не слышал о возможности выделения памяти для самого сервера ESXi).

Как распределяется память для сервера ESXi? Как это перераспределить / распределить оперативную память между виртуальными машинами без проблем?

Здесь гораздо больше, чем просто ESXi,

1. Каждая виртуальная машина потребляет до 4 ГБ + «накладные расходы», что описано здесь . Это зависит от vCPU, + выделенной памяти. Как минимум, каждая виртуальная машина будет использовать 4261,98 МБ (4096 + 165,98).
2. Издержки памяти собственной ESXi, это зависит от оборудования. Самый простой вариант - посмотреть на использование системной памяти в клиенте vSphere. Насколько я помню, это около 1,3 ГБ, но, как указано, это очень зависит от аппаратного обеспечения.

Выделение памяти и чрезмерная ответственность

Обратите внимание, что гипервизор не будет выделять всю эту память заранее , это зависит от использования виртуальной машины. Однако стоит понять, что произойдет, если виртуальные машины попытаются выделить и использовать всю выделенную им память.

Максимальное количество попыток использования хоста VM + будет примерно равно 55 мегабайтам.

• 1,3 ГБ, используемых ESXi
• 4261,98 МБ * 13, используемых виртуальными машинами

Есть еще один аспект, который необходимо учитывать, и это пороги памяти. По умолчанию VMware будет стремиться освободить 6% (высокий порог памяти). Таким образом, 55 ГБ используемой памяти необходимо сократить до ~ 45 ГБ.

Это означает, что хост будет иметь приблизительно 10 500 МБ памяти, которые ему необходимо вернуть откуда-то, если виртуальные машины будут использовать выделенную память. ESX делает три вещи, чтобы найти дополнительные 10,5 ГБ.

Методы восстановления памяти

1. Прозрачный общий доступ к страницам
2. Воздушный шар памяти
3. Замена гипервизора

Вы должны прочитать и понять Общие сведения об управлении ресурсами памяти в VMware® ESX ™ Server .

В зависимости от большого количества факторов, комбинация всех трех может / может произойти на переназначенном хосте. Вы должны проверить свою среду и контролировать эти показатели, чтобы понять влияние чрезмерных обязательств.

Некоторые грубые правила, которые стоит знать (все в статье выше и других источниках).

1. Прозрачный общий доступ к страницам не происходит для виртуальных машин, которые используют страницы размером 2/4 МБ. Поскольку вы выделили 4096 МБ для своих виртуальных машин Windows, они по умолчанию будут использовать страницы размером 2/4 МБ (в зависимости от PAE). Только под давлением памяти VMware будет разбивать большие страницы до 4 КБ страниц, которые могут быть разделены. TPS использует циклы простоя процессора и сканирует страницы памяти с определенной скоростью. Он возвращает память относительно медленно (подумайте час, а не минуты). Таким образом, шторм загрузки означает, что TPS не поможет вам. Из этих трех это оказывает самое низкое влияние на производительность. Больше из документа,

В системах аппаратной виртуализации памяти (например, в системах Intel EPT Hardware Assist и AMD RVI Hardware Assist [6]) ESX автоматически создает резервные копии гостевых физических страниц с большими физическими страницами хоста (непрерывная область памяти 2 МБ вместо 4 КБ для обычных страниц) для лучшая производительность благодаря меньшему количеству промахов TLB. В таких системах ESX не будет совместно использовать эти большие страницы, потому что: 1) вероятность нахождения двух больших страниц с одинаковым содержимым низкая, и 2) накладные расходы при выполнении побитового сравнения для страницы размером 2 МБ намного больше, чем для страницы 4KB. Тем не менее, ESX по-прежнему генерирует хэши для страниц размером 4 КБ в пределах каждой большой страницы. Поскольку ESX не будет выгружать большие страницы, во время замены хоста большая страница будет разбита на маленькие страницы, так что эти предварительно сгенерированные хеши могут быть использованы для обмена маленькими страницами перед их заменой. Короче говоря, мы не можем наблюдать какой-либо общий доступ к страницам для систем виртуализации памяти с аппаратным обеспечением, пока память хоста не будет перегружена.

1. Далее следует всплывающая подсказка (пороговые значения настраиваются, по умолчанию это когда на хосте менее 6% свободной памяти (между высоким и программным обеспечением)). Обязательно установите драйвер и следите за Java и управляемыми приложениями в целом. ОС не имеет представления о том, что будет делать сборщик мусора дальше, и в конечном итоге попадет на страницы, которые были перенесены на диск. Для серверов, работающих исключительно с Java-приложениями, нередко практикуют полное отключение свопинга, чтобы гарантировать, что этого не произойдет. Взгляните на страницу 17 из vSphere Memory Management, SPECjbb

2. Обмен из гипервизора из трех методов является единственным, который гарантирует доступность «памяти» для гипервизора в установленное время. Это будет использоваться, если 1 и 2 не дают достаточно памяти, чтобы оставаться под жестким порогом (по умолчанию 2% свободной памяти). Когда вы прочитаете метрики производительности (выполните свои собственные), вы поймете, что это худший результат из трех. Старайтесь избегать этого любой ценой, поскольку влияние на производительность будет очень заметным почти во всех приложениях. Двузначный процент

3. Есть еще одно состояние, которое нужно знать о низком уровне (по умолчанию 1%). Из руководства это может резко сократить вашу производительность,

В редком случае, когда объем свободной памяти хоста падает ниже нижнего порога, гипервизор продолжает восстанавливать память путем замены и сжатия памяти и дополнительно блокирует выполнение всех виртуальных машин, которые потребляют больше памяти, чем их целевые выделения памяти.

Резюме

Ключевым моментом, на котором стоит подчеркнуть, является то, что невозможно предсказать из технических описаний, как ваша среда будет вести себя.

1. Сколько может дать TPS? (Зависит от того, насколько похожи ваши виртуальные машины с их ОС, пакетом обновления и запущенными приложениями)
2. Как быстро ваши виртуальные машины выделяют вашу память? Чем быстрее они это сделают, тем выше вероятность того, что вы перейдете к следующему порогу, прежде чем менее эффективная схема восстановления памяти сможет удержать вас в вашем текущем пороге.
3. В зависимости от приложения каждая схема восстановления памяти будет иметь различное влияние.

Протестируйте свои средние сценарии, у вас 95% -ный сценарий и, наконец, ваш максимум, чтобы понять, как будет работать ваша среда.

Редактировать 1

Стоит добавить, что в vSphere 4 (или 4.1 не может быть вызван) теперь можно размещать подкачку гипервизора на локальном диске, но при этом все же использовать виртуальную машину . Если вы используете общее хранилище, я настоятельно рекомендую переместить файл подкачки гипервизора на локальный диск по умолчанию. Это гарантирует, что когда один хост находится под серьезным давлением памяти, он не оказывает влияния на все другие хосты / виртуальные машины vSphere в одном и том же общем хранилище.

Редактировать 2

На основании комментариев сделан тот факт, что ESX не выделяет память заранее жирным шрифтом ...

Редактировать 3

Объяснил немного больше о порогах памяти.

VMware (и другие технологии виртуализации) распределяют ресурсы (память, процессорное время, ввод-вывод различных типов) между виртуальными машинами в соответствии с различными алгоритмами.

Это posssible к overcommit ресурсов, потому что не все виртуальные машины будут использовать все обработки, памяти или ввода / вывода , что им нужно все время. Руководство по управлению ресурсами VMware, вероятно, является лучшим местом для ознакомления с тем, что возможно в ESXi.

Вы также можете управлять эффектом алгоритмов, взвешивая разные виртуальные машины для разных ресурсов - например, вы можете назначить виртуальной машине сервера приложений более высокую нагрузку на процессор, чем виртуальной машине файлового сервера. Однако стандартные настройки отлично справятся с большинством требований. В некоторых случаях выполнения некоторой конфигурации здесь достаточно, чтобы успокоить менеджеров, которые не совсем понимают это, но, конечно, будьте осторожны и прочитайте документы для своей версии VMware и поймите, что вы делаете. Если ваш менеджер не нуждается в дальнейшем размещении, просто используйте значения по умолчанию.

Обратите внимание, что чрезмерное обязательство не всегда является хорошей идеей, особенно если вы виртуализировали на одном сервере. Вы должны следить за использованием ресурсов в своем имуществе ESXi и, при необходимости, добавлять дополнительные хосты / ресурсы, если вы часто используете все один или несколько ресурсов.

Пусть ваша установка VMWare ESXi справится с этим. Вы можете перезаписывать ресурсы ОЗУ в системах VMWare благодаря использованию методов раздувания памяти, сжатия и дедупликации .

Если виртуальные машины используют аналогичную операционную систему, то есть некоторая экономия. Обязательно включите инструменты VMWare внутри гостевой виртуальной машины, чтобы в полной мере использовать эти функции.