vSphere education - Каковы недостатки настройки виртуальных машин с * слишком * большим объемом оперативной памяти?

Управление памятью vSphere довольно приличное, хотя используемые термины часто вызывают большую путаницу.

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

Каковы недостатки чрезмерного выделения и чрезмерной настройки ресурсов (в частности, ОЗУ) в средах vSphere?

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

Для раздува vSphere раздувает «воздушный шар» RAM в выбранной виртуальной машине, а затем передает эту раздуваемую RAM гостю, которому она нужна. Это не так уж плохо - виртуальные машины крадут оперативную память друг друга, поэтому подкачки дисков не происходит - но это может привести к ошибочным предупреждениям и искаженным показателям, если они полагаются на анализ использования ОЗУ виртуальной машины, поскольку ОЗУ выиграло. не должен быть помечен как «раздуваемый», просто он «используется» ОС.

Другая функция, которую может использовать vSphere, - это Transparent Page Sharing (TPS), которая по сути является дедупликацией RAM. vSphere будет периодически сканировать всю выделенную оперативную память в поисках дублированных страниц. Когда он будет найден, он будет дедуплицирован и освободит повторяющиеся страницы.

Взгляни на Технический документ vSphere по управлению памятью (PDF) - в частности, «Восстановление памяти в ESXi» (стр. 8) - если вам нужно более подробное объяснение.

Предполагая, что виртуальные машины могут работать с меньшим объемом оперативной памяти, справедливо ли говорить о накладных расходах на настройку виртуальных машин с большим объемом оперативной памяти, чем им нужно?

Нет видимых накладных расходов - вы можете выделить 100 ГБ ОЗУ на хосте с 16 ГБ (однако это не значит, что вы должен, по указанным выше причинам).

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

В этом разделе обсуждается разница между «Активным» и «Потребляемым» ОЗУ. Тема сообщества VMWare.

Что является контраргументом: "если виртуальной машине выделено 16 ГБ ОЗУ, но используется только 4 ГБ, в чем проблема ??"? Например. нужно ли обучать клиентов?

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

Клиенты должны быть обучены определять размер своих виртуальных машин в соответствии с тем, что они использовать, а не то, что они хотеть. Часто люди будут переоценивать свои виртуальные машины только потому, что они мощь нужно 16 ГБ оперативной памяти, даже если они исторически неуклюже скупались на 2 ГБ изо дня в день. Как администратор vSphere вы обладаете знаниями, показателями и возможностями, чтобы бросить им вызов и спросить, действительно ли им нужна выделенная ими оперативная память.

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

В дополнение к этому автоматизированный vMotion (называемый Распределенное планирование ресурсов by VMware), по сути, является балансировщиком нагрузки для ваших виртуальных машин - если одна виртуальная машина становится потребителем ресурсов, DRS следует перенести виртуальные машины, чтобы максимально использовать ресурсы кластера.

Какую конкретную метрику следует использовать для измерения использования ОЗУ. Отслеживание пиков «Активности» в зависимости от времени?

В основном рассмотрено выше - ваша основная проблема должна быть «Активным» использованием ОЗУ, хотя вы должны тщательно определять свои пороги превышения, чтобы при достижении определенного соотношения (это достойный пример, хотя, возможно, он немного устарел). Как правило, я бы определенно оставался в пределах 120% от общей оперативной памяти кластера, но вам решать, какое соотношение вам подходит.

Несколько хороших статей / дискуссий о чрезмерной фиксации памяти:

• Избыточное использование памяти в производстве? ДА ДА ДА
• vSphere - чрезмерное использование памяти?
• Избыточное использование памяти в vSphere

В дополнение к отличному ответу Крейга Ватсона я хотел бы добавить следующее:

Чрезмерное выделение памяти в VMware - это не то, что вам следует делать специально. Как правило, это показывает, что либо вы, либо ваш клиент слишком много подписываете на оборудование.

Если чрезмерное усердие - единственный выбор, тогда я сильно посоветуйте обеспечить соблюдение правил приоритета. Если кто-то хочет предоставить некритичной виртуальной машине 16 ГБ vRam, когда ей нужно всего 4 ГБ, по крайней мере поместите эту виртуальную машину в пул с низким уровнем ресурсов или дайте ей низкий приоритет. Вы действительно не хотите, чтобы критически важная производственная база данных была заменена гипервизором. Мало того, что производительность упадет насмарку, это также поглотит очереди ввода-вывода в вашем внутреннем хранилище.

Если вы используете невероятно быстрое хранилище (FusionIO, Violin, локальные твердотельные накопители и т. Д.), То замена может не представлять большой проблемы, но с традиционным хранилищем SAN вы в конечном итоге повлияете на каждую виртуальную машину и хост, подключенные к одному массиву / контроллеру.