Механизмы перераспределения  ресурсов в ESX(i) – ЧАСТЬ 2

ступны  2099 Мб памяти, а у запущенных  на нем ВМ в сумме 4096 Мб.

Кстати говоря, и это важно, «потребляемая память»  в такой ситуации может быть как меньше (хороший случай), так и больше, чем память «доступная» (плохой

Рис. 6.25. Прикладная иллюстрация Memory Overcommitment

Механизмы перераспределения ресурсов в ESX(i)

случай).  Для иллюстрации – обратите внимание  на столбец Host Memory Usage на предыдущем рисунке. Как видим, при 4096 Мб показанной памяти виртуальные машины реально используют 553 Мб, что вполне помещается  в имеющихся  у сервера 2099 Мб. Это как раз пример «хорошего» случая memory overcommitment.

Memory Overcommitment достигается  на ESX(i) за счет нескольких  техноло-

гий. Перечислим их:

Q  выделение  по запросу;

Q  дедупликация оперативной памяти, transparent memory page sharing;

Q  механизм баллон, он же balloon driver или vmmemctl;

Q  сжатие памяти, memory compression (новинка 4.1);

Q  файл подкачки гипервизора,  VMkernel  swap.

Что  это?  Каково  место  этих  технологий? Насколько они  применимы?  Насколько они бесполезны? Давайте поразмышляем.

Вводная к размышлениям.

Мы будем рассуждать о потреблении памяти виртуальными машинами, а точнее – гостевыми ОС и приложениями.

Основная идея вот в чем – «показанная» серверу (тут не важно, физическому или виртуальному) оперативная память  никогда  не загружена  на 100%. Почему? У вас загружена именно так? Значит, вы плохо спланировали этот сервер, согласны?

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

1.    Нам следует стремиться к тому, что виртуальные машины не должны все время потреблять 100% от «показанной» им памяти. Таким образом, прочие соображения я буду основывать  на том, что у вас именно  так. То, что некоторые задачи занимают чем-то (например, кэшем)  всю свободную память, здесь не учитываем, так как разговор идет в общем.

2.    В разное время суток/дни недели наши приложения потребляют память по-разному. Большинство задач потребляют максимум ресурсов в рабочие часы в будни, с пиками утром или в середине дня, или <подставьте данные своей статистики>. Однако бывают приложения с нетипичным для нашей инфраструктуры профилем потребления памяти.

3.    В вашей инфраструктуре сделан запас по оперативной памяти серверов, то есть «доступной» памяти. Этот запас делается  из следующих  соображений:

•    архитектор опасается промахнуться с необходимым объемом. «Промахнуться» в смысле «продать меньше памяти, чем потребуется для оговоренных виртуальных машин»;

•    как запас на случай отказа сервера (или нескольких);

•    как запас на случай роста количества виртуальных машин или нагрузки на существующие виртуальные машины.

Далее.

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

Q  ВМ приложений – сколько  памяти  вы выделяете  («показываете» в моих определениях тут) своим серверам приложений? При опросах на курсах я слышу цифры  4–8, редко больше.   Вернее, для малого числа ВМ больше. Большинство таких приложений потребляет  ресурсы  в рабочие часы, однако бывают и исключения (например, серверы резервного  копирования, работающие по ночам).

Q  Инфраструктурные ВМ – всякие  DNS, DC  и т. п. Обычно гигабайт  или два. Потребляют ресурсов мало, пики, если вообще есть, – в рабочие часы.

Q  Тестовые ВМ – думаю, гигабайт или два в среднем по больнице, и больше по требованию, смотря что тестировать будем. Пики в рабочие часы, где-то бывает  куча тестовых  виртуальных машин, простаивающих подавляюще  большую часть времени  (как  крайний случай – кто-то создал и забросил, а удалить ВМ страшно – вдруг кому нужна).

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

Выделение по запросу

Далеко  не все ВМ  потребляют всю выделенную  память  все время  работы. И часто возникают  ситуации,  когда для ВМ выделены  10 (например) Гб, а она активно использует  лишь 7. Или один.

ESX(i) умеет определять,  сколько  памяти  ВМ использует,  а сколько не использует.  И из физической оперативной памяти  выделяет  каждой ВМ столько, сколько надо ей. Иными словами, в любой момент времени есть достаточно много доступной  для машин памяти, но ими не используемой.

Виртуальной машине  выделили   («показали») 2  Гб. Виртуальную  машину включили.  Что происходит дальше?

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

«потребляемая» память равна «показанной», в самом плохом случае.

Этап 2 – гость стартовал  все службы, службы начали работать, создавать нагрузку. Но не 100% памяти  потребляется, см. утверждение  1. Например, 1200 Мб из выделенных  2000. То есть гость 800 Мб пометил  у себя в таблице  памяти  как

«свободная».  По-хорошему  гипервизору надо бы ее забрать.  Он и забирает  (забегая вперед – для этого используется механизм balloon). Итак, баллон раздулся,  затем сразу сдулся. Что получилось: гостю 1200 Мб нужно, поэтому они баллоном  или не отнялись,  или сразу вернулись обратно. Но больше  памяти  гостю обычно не нужно – и он больше не запрашивает у гипервизора.  А раз не запрашивает,  гипервизор  этой виртуальной машине  больше страниц  физической памяти  и не выделяет.

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

Механизмы перераспределения ресурсов в ESX(i)

дически у гостя отбирается.  Следовательно, ранее выделенную  под это реальную оперативную  память гипервизор  может использовать под другие ВМ.

Работает   этот  механизм  всегда,  когда  виртуальная машина  потребляет  не 100% «показанной» памяти.  То есть всегда, кроме первых минут после включения и редких пиков, этот механизм работает и заметно экономит нам память.

Если виртуальная машина не потребляет  всю память часто – механизм очень полезен.

Для некоторых тестовых – 100% времени.

Для инфраструктурных – иногда бо?льшую часть времени.

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

Эффект  на производительность если и есть негативный, то несущественный.

transparent  memory page sharing

На серверах  ESX(i) работает  много виртуальных машин. Часто  у многих из них одинаковая операционная система. Иногда  на несколько  машин установле но одно и то же приложение. Это означает,  что для многих ВМ мы вынуждены хранить в оперативной памяти одни и те же данные: ядро операционной системы, драйверы,  приложения, dll. Даже внутри одной ВМ есть страницы  памяти, занятые одинаковыми данными.

На ESX(i) работает  фоновый  процесс  для нахождения одинаковых страниц памяти.  Одинаковые для нескольких  ВМ страницы  памяти  хранятся в физиче ской оперативной памяти в единственном экземпляре (разумеется, доступ к такой странице у виртуальных машин только на чтение).

Гипервизор  считает  контрольные суммы  страниц  оперативной памяти.  Находит  одинаковые (для  одной  или  нескольких  виртуальных машин)  страницы. И одинаковые страницы  из разных «виртуальных таблиц памяти» адресует в одну-единственную страницу в памяти реальной (рис. 6.26).

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

Получается, на пустом месте гипервизор делает «потребляемую» память меньше, чем она могла бы быть без данного механизма.  Ну, про «на пустом месте» я слегка соврал  – гипервизор  тратит ресурсы процессоров  сервера на подсчет контрольных  сумм. Но  с учетом того, что, как правило,  ресурсов процессора  у нас в избытке, этот обмен нам очень выгоден.

Насколько часто это применяется к разным группам виртуальных машин?

Сложный вопрос. Сложность – во все более широко используемом механизме Large Pages. Если у вас Windows 7/2008 + Nehalem и используются страницы  памяти по 2 Мб, теория гласит, что эффект  от page sharing будет маленьким.  Хотя в реальности  там довольно сложный  алгоритм:

ESX(i) разбивает  2 Мб страницу  на 4 Кб, считает их контрольные суммы, но

не использует  механизм page sharing, пока памяти сервера достаточно. А вот если памяти  сервера перестает хватать на все виртуальные машины, то, перед тем как

Рис. 6.26. Иллюстрация работы механизма Page Sharing Источник: VMware

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

А если большие страницы не используются вашей инфраструктурой – эффект  часто весьма значительный.

Производительность не испытывает негативного эффекта от применения данного механизма. Тем более что ESX(i) знает, что такое архитектура NUMA, и если сервер у нас этой архитектуры, то дедупликация страниц памяти идет внутри каждого одного  NUMA узла независимо, чтобы виртуальной машине не приходилось за отдельными, дедуплицированными страницами обращаться  в память  другого процессора.

Источник: Михеев М. О.  Администрирование VMware vSphere 4.1. – М.: ДМК Пресс, 2011. – 448 с.: ил.

Похожие посты:

Вы можете оставить комментарий, или ссылку на Ваш сайт.

Оставить комментарий