Вопрос: vSphere education - Каковы недостатки настройки виртуальных машин с * слишком большим количеством ОЗУ?


Управление памятью VMware кажется сложным балансирующим действием. С кластерным ОЗУ, пулами ресурсов, методами управления VMware (TPS, воздушным шаром, перестановкой хоста), использованием ОЗУ в оперативной памяти, заменой, резервированием, долями и ограничениями, существует множество переменных.

Я в ситуации, когда клиенты используют выделенные ресурсы кластера vSphere. Тем не менее, они настраивают виртуальные машины так, как если бы они находились на физическом оборудовании. В свою очередь, это означает, что стандартная сборка VM может иметь 4 vCPU и 16 ГБ или более ОЗУ. Я исхожу из школы, начинающей небольшую (1 vCPU, минимальную ОЗУ), проверяя использование в реальном времени и при необходимости настраивая. К сожалению, многие требования к поставщикам и люди, незнакомые с виртуализацией, запрашивают больше ресурсов, чем необходимо ... Я заинтересован в количественном определении влияния этого решения.


Некоторые примеры из «проблемного» кластера.

Резюме пула ресурсов - выглядит почти 4: 1 overcommitted. Обратите внимание на большое количество развернутой RAM. enter image description here

Распределение ресурсов. Столбец «Самый худший случай» показывает, что эти виртуальные машины будут иметь доступ к менее чем 50% их сконфигурированной ОЗУ в ограниченных условиях. enter image description here

График использования памяти в реальном времени верхней виртуальной машины в приведенном выше списке. 4 выделенных vCPU и 64GB RAM. Он в среднем используется под 9 ГБ. enter image description here

Резюме одной и той же виртуальной машины enter image description here


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

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

  • Каков контраргумент: «если VM имеет 16 ГБ ОЗУ, но использует только 4 ГБ, в чем проблема?»«Например, нужно ли получать информацию о том, что VM - это не то же самое, что физическое оборудование?

  • Какую конкретную метрику (ы) следует использовать для измерения использования ОЗУ. Отслеживание пиков «Активного» и времени? Просмотр «Потребляемый»?


Обновить: я использовал vCenter Operations Manager для профилирования этой среды и получения подробной информации о статистике кластера, указанной выше. В то время как вещи определенно перегружены, виртуальные машины на самом деле так перенастроены с ненужной ОЗУ, что реальный (крошечный) объем памяти не отражает конфликтов памяти на уровне кластера / хоста ...

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

Обновление 2: Некоторые из этих виртуальных машин начинают сбой:

kernel:BUG: soft lockup - CPU#1 stuck for 71s! 

VMware описывает это как симптом избыточного избытка памяти, Поэтому я думаю, что это отвечает на вопрос.

enter image description here


vCops Отчет «Негабаритные виртуальные машины» ... enter image description here

vCops Граф «Исправляемые отходы» ...

enter image description here


54
2017-08-02 15:14


Источник




Ответы:


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


43
2017-08-02 17:09



Я понимаю, что больше ОЗУ, выделенной для виртуальной машины, означает, что DRS сложнее перенастроить виртуальную машину - для миграции между узлами требуется больше времени, поскольку для копирования ОЗУ требуется больше времени; и чем больше требуется RAM, тем меньше вероятность того, что DRS сможет найти достаточно большой кусок, который является бесплатным. Это может быть особенно проблематичным (я полагал, что если верить), если у вас есть событие (например, аппаратный сбой), который снижает емкость в кластере. Маленькие виртуальные машины легко перемешать и вряд ли заметят много сбоев, большие виртуальные машины могут быть сложными. Правильно ли я был проинформирован? - James Polley
@James - только активная (т. Е. Используемая) память переносится во время vMotion, поэтому объем оперативной памяти, который вы выделяете своим виртуальным машинам, не имеет значения. Справка: vmware.com/files/pdf/VMware-VMotion-DS-EN.pdf - Craig Watson
Отличный ответ. Я обновил свой вопрос более подробно из этого конкретного кластера. Однако ваши баллы хороши. Оказывается, виртуальные машины в этой установке сильно переконфигурированы. Активное использование ОЗУ значительно ниже физических ресурсов кластера, поэтому нет никаких споров ... Просто тяжелый взлет / замена / уродство. Я подозреваю, что правильная калибровка виртуальных машин облегчит это давление. - ewwhite


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

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

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

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


19



Хорошее наблюдение за воздействием на хранилище подкачки. Это объясняет некоторые проблемы производительности VNX, которые я видел ... - ewwhite
Блестящий момент, я никогда не думал, чтобы взять аргумент IO хранения, - Dan