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

Однако в теории накладные  расходы имеют место быть: если какая-то ВМ хочет изменить  разделяемую с другими  страницу  памяти,  с помощью  технологии  Copy-on-write делается копия страницы, которая и отдается приватно данной ВМ. Это медленнее,  чем просто дать записать  в неразделяемую страницу.  Насколько заметен эффект  в реальной жизни, сказать очень сложно.

Официальные данные по влиянию Page Sharing  на производительность следующие (рис. 6.27).

На этом рисунке каждая тройка столбцов – разная задача.

Первый в каждой тройке столбец – производительность задачи в виртуальной машине, когда page sharing для нее не используется.

Второй столбец – производительность при использовании page sharing, с настройками  по умолчанию.

Третий  столбец в каждой тройке – используется page sharing, с уменьшенной  частотой сканирования памяти.

За единицу  выбраны  данные тестов с отключенным  page sharing.  Как видно, средний  столбец – со включенным  page sharing   и параметрами по умолчанию  – не хуже, а иногда лучше по производительности. Улучшение связывают  с тем, что memory footprint у виртуальной машины становится меньше и лучше помещается  в кеш. В любом случае, разницу по производительности можно назвать несущест-

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

Рис. 6.27. Сравнение производительности трех задач относительно применения к ним Page Sharing

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

Эффект  от работы данного механизма легко обнаружить на вкладке Summary

для пула ресурсов (рис. 6.28).

Рис. 6.28. Выделение памяти для пяти ВМ

В пуле ресурсов с рисунка пять ВМ. Каждой выделено по 1 Гб памяти. Из 5 Гб выделенной на эти пять  ВМ памяти  на 3,5 Гб распространяется механизм  page sharing.

На закладке Resource Allocation для виртуальной машины можно увидеть эту информацию применительно к ней одной (рис. 6.29).

Рис. 6.29. Выделение памяти для одной ВМ

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

Этот же показатель  Shared  можно увидеть на закладке  Performance, выбрав соответствующий счетчик для памяти (рис. 6.30).

Отличие  shared  common и shared  в следующем: когда у трех ВМ одна общая страница, то shared common – объем этой одной страницы, а shared total – трех.

Для настройки процесса сканирования памяти пройдите Home ? Configuration

? Advanced Settings сервера. Здесь есть возможность указать следующие параметры:

Q  Mem.ShareScanTime – как много времени можно тратить на сканирование;

Q  Mem.ShareScanGHz –  сколько  ресурсов  можно  тратить  (если  0,  то  эта функция не будет работать на этом сервере).

Для  отключения этого механизма  для отдельной  ВМ добавьте в ее файл  настроек (*.vmx) параметр

sched.mem.pshare.enable = false

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

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

Рис. 6.30. Shared и Shared Common счетчики

Перераспределение памяти. Balloon driver, memory compression и vmkernel swap

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

В таких ситуация  нас выручат настройки limit, reservation и shares – с их помощью мы заранее указали, каким ВМ дать больше памяти. Но получается, у менее приоритетных ВМ память  потребуется  отнять,  чтобы отдать ее более приоритетным.  Само собой, просто так отнять память  у ВМ нельзя  – можно часть ее данных  вытеснить  в файл  подкачки.  Вот механизмы  vmmemctl (balloon  driver),  memory compression и vmkernel swap этим и занимаются.

Balloon Driver

Один из компонентов  VMware  tools – это драйвер  устройства  vmmemctl. По команде ESX(i) он начинает  запрашивать у гостевой  ОС память,  так же как это делают приложения гостевой ОС. То есть этот драйвер раздувает тот самый «баллон» внутри, запрашивая (то есть отнимая) память у гостя.

Зачем это надо? Для решения двух задач.

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

Посмотрите на рис. 6.31 – страницы  памяти, гостем для себя помеченные  как

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

Рис. 6.31. Иллюстрация отъема ранее запрошенной, но неиспользуемой памяти механизмом Balloon

Вторая задача – когда гостю выделено, например, 2 Гб, а 1 Гб из них надо отнять. Характерный пример – когда памяти сервера перестало хватать резко увеличившемуся  числу виртуальных машин. А число их резко увеличилось из-за сбоя одного из серверов и рестарта его ВМ на другом.

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

То есть balloon driver – это способ гипервизору задействовать механизм подкачки гостя.

Кстати, в моем примере  гипервизор  отдаст команду  отнять  гигабайт. А весь ли гигабайт баллон отнимет?  Может быть, и не весь – гость вполне может отказать ему в памяти,  если сочтет, что другим приложениям память  нужнее.  Если баллон  не справился,  то гипервизор  доотнимет  оставшееся  с помощью  memory compression и vmkernel swap.

Когда механизм баллона может не справиться:

Q  когда в ВМ не установлены VMware  tools. vmmemctl  – это часть VMware  tools;

Q  когда vmmemctl не загружен. Например, при старте ВМ, до того как загру-

зилась гостевая ОС;

Q  когда vmmemctl не способен отнять память достаточно быстро;

Q  по умолчанию баллон отнимает не более 65% памяти ВМ. Кроме того, можно эту настройку  поменять  индивидуально для ВМ, прописыванием в ее файле настроек

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

sched.mem.maxmemctl  = <разрешенное  к отъему количество мегабайт>

Проверить,  что для ВМ недоступен  механизм  balloon, можно следующим образом: запустите esxtop, переключитесь на экран Memory нажатием «m», нажмите

«f» и отметьте столбец «MCTL». Нажмите Enter. Значение «N» в этом столбце для какой-то ВМ означает, что драйвер vmmemctl в ней не работает.

В ваших интересах, чтобы этот механизм  был доступен для всех ВМ. В частности,  потому  что он используется не только  для  отъема  и  перераспределения памяти  в случае нехватки  ресурса  (как  в примере  выше). Еще он используется, чтобы вытеснить ВМ из части физической оперативной памяти, когда та ей уже не используется. Это намного более частая операция, и с использованием balloon она проходит безболезненно и неощутимо для производительности ВМ.

Memory compression

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

Рис. 6.32. Иллюстрация работы Memory Compression

Состояние «а» – надо выгрузить две страницы памяти из реальной оперативки. Состояние «b» – решение вопроса «по старинке», механизмами подкачки. Состояние «с» – модерновое решение вопроса. Страницы сжаты и помещены

в ранее зарезервированную область памяти сервера.

Идея  в том, что сжать и записать  данные в память, или прочитать  и разжать, быстрее, чем без сжатия читать или писать с диска, из файла подкачки.

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

Какие-то настройки для данного механизма доступны только через Advanced Options для ESX(i).

VMkernel swap

Чуть  выше я описал  vmmemctl(balloon) – механизм  для  вытеснения части оперативной памяти гостя в файл/раздел подкачки.

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

А теперь поговорим про последний  механизм для той же самой цели – отъема реальной памяти у виртуальной машины.

При включении каждой виртуальной машины гипервизор создает файл .vswp – файл подкачки vmkernel для этой ВМ.

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

Чтобы  проиллюстрировать отличие  между  механизмами balloon  и vmkernel swap, давайте взглянем  на рис. 6.33.

Рис. 6.33. Уровни работы с оперативной памятью

Вы видите три уровня оперативной памяти.

Верхний, Application  memory, – это память, которую видят приложения внутри ВМ. Адресоваться эта память может в оперативную  память (которую  гостевая ОС считает аппаратной) плюс файл подкачки гостевой ОС.

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

Второй уровень, Guest memory, – это та память, которую показывает гипервизор для гостевой ОС. Адресоваться он может в физическую память сервера и файл подкачки  гипервизора.  Это тот самый  файл,  который  создается при включении  ВМ и размер которого равен hardware  memory минус reservation.

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

Так вот, balloon – это способ вытеснить гостя из реальной оперативной памяти  в его внутренний файл подкачки, а vmkernel swap – вытеснить  гостя из реальной оперативной памяти во внешний файл подкачки, который гипервизор создал для этой виртуальной машины.

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

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

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

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

Итак, из чего может взяться  ситуация,  когда у одной ВМ память надо отнять, чтобы отдать другой? Я вижу несколько вариантов.

Когда у нас memory  overcommitment и сразу  у многих  ВМ наступили пики нагрузки,  что привело  к загрузке сервера на 100% по памяти. Это, кстати говоря, причина пользоваться memory overcommitment аккуратно.  Впрочем, совсем отказываться  от memory overcommitment, как призывает  нас делать Майкрософт, по моему мнению, тоже не стоит.

Когда у нас ломается  один из серверов кластера HA. Например, у нас 10 серверов, все загружены  по памяти  (днем, в будни)  процентов  на 70. Однако после отказа одного из серверов есть вероятность,  что один или несколько оставшихся  окажутся  загруженными на 100% – HA хоть и выбирает  для включения каждой из упавших виртуальных машин наименее  загруженный сервер, но гарантий  достаточности ресурсов не дает.

Далее ситуация разветвляется. Если у вас есть DRS, то он быстренько разнесет ВМ по разным серверам, и перераспределять память не придется.

А вот если DRS  нет, или он не в автоматическом режиме  – вот тут мы приходим к нехватке на все ВМ физической памяти (на одном или нескольких серве-

рах). И гипервизор  отнимет память у части машин с помощью баллона или оставшихся двух механизмов.

Таким  образом, если в вашей инфраструктуре выполняются следующие  условия:

Q  ресурсов  серверов  достаточно  для всех виртуальных машин, с учетом их

пиков и с учетом плановых и неплановых простоев части серверов. Это самое главное условие;

Q  у вас есть кластер DRS, и он настроен на автоматический режим баланси-

ровки нагрузки.

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

Вывод: наличие механизмов перераспределения памяти – это способ значительно сократить негативный эффект от недостатков планирования инфраструктуры.

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

«остаться  на коне» за счет опускания других ВМ в еще большее «свопирование» (в настройке  приоритета  виртуальных машин нам помогут настройки reservation и shares).

И по большому счету, это и есть эффект от работы и сам смысл существования описываемых  функций перераспределения памяти.

Отсюда вывод: наличие Balloon driver, memory compression и vmkernel swap  – это несомненный  плюс для инфраструктуры, но не панацея  от нехватки  памяти. Лучше планировать инфраструктуру, нагрузку на нее и увеличение доступных ресурсов так, чтобы эти механизмы  не пригождались вообще, – иначе часть виртуальных машин будет испытывать нехватку ресурсов.

Нехватка памяти на всех – какой механизм будет использован?

У ESX(i) есть счетчик – процент свободной памяти. Его пороговые значения. Судя по документации, это: Q  >6% = high. Нормальное состояние сервера;

Q  >4% = soft. Памяти осталось меньше, чем считается нормальным, но острой нехватки нет;

Q  >2% = hard. Ситуация с памятью становится критичной;

Q  >1% = low. Все, приехали.

Однако, по некоторым данным, эти константы  слегка другие:

Q  High = свободно свыше 64% памяти;

Q  Soft = свободно от 64% до 32%; Q  Hard = свободно от 32% до 16%; Q  Low = свободно менее 16%.

Как ESX(i) реагирует на смену состояния этого счетчика:

Q  Состояние High. Задействуется только page sharing;

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

Q  Состояние Soft. Свободной памяти меньше, чем хотелось бы. Начинаем использовать  balloon;

Q  Состояние Hard. Свободной  памяти  мало. Используем еще и compression и vmk swap;

Q  Состояние Low. Гипервизор  использует  все доступные механизмы  и плюс к тому может остановить  выполнение виртуальных машин, требующих память сверх выделенной в данный момент.

Обратите внимание. Если для какой-то виртуальной машины следует отключить работу механизмов Balloon driver и VMkernel swap, то простой способ это сделать – указать значение  reservation для памяти равным значению Hardware memory этой виртуальной машины.

Balloon, memory  compression  и vmkernel  swap и делают одну и ту же работу. Но balloon  делает ее более оптимально – позволяет  гостю самому выбрать,  что помещать  в своп. Данные  тестов приведены  на следующих рисунках,  первый  из которых – рис. 6.34.

Рис. 6.34. Время выполнения компиляции

при отъеме памяти с помощью balloon или vmkernel swap

Столбцами отображается объем отбираемой  у виртуальной машины памяти. Красная линия с ромбами – скорость компиляции, зеленая с квадратами – только vmkernel swap. Как видно, когда из 512 Мб памяти у гостя оставалось только 128, при использовании для отъема памяти  balloon  скорость выполнения бенчмарки  практически не снижалась.

Специфика данного теста, компиляции, – в том, что самому процессу память особо не нужна – основной объем занят под кеш данных. Так вот, в случае balloon гость понимал, что в своп лучше положить сначала данные, чем ядро ОС или ядро приложения. А в случае vmkernel swap такой выбор сделать нельзя, и в своп идет «что-то».

А вот данные  при похожих  условиях  для базы данных  Oracle, нагруженной соответствующей утилитой  (рис. 6.35).

Рис. 6.35. Количество транзакций в секунду для БД Oracle при отъеме памяти с помощью balloon или vmkernel swap

Обратите  внимание: пока balloon отнимал меньше чем 1792 Мб из 3840, производительность практически не падала. Это опять же специфика приложения, но приложения характерного.

А вот для каких-то приложений разницы не будет (рис. 6.36).

Рис. 6.36. Количество транзакций в секунду для SPECjbb при отъеме памяти с помощью balloon или vmkernel swap

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

И в начальном  диапазоне  vmkernel  swap даже меньше негатива оказывает на производительность ВМ. Впрочем, процент  приложений, вот так использующих память, мал, в общем случае. Здесь использовалась бенчмарка SPECjbb – утилита  для нагрузочного  тестирования, имитирующая нагрузку на серверную часть Javaприложений.

А вот для Exchange разница кардинальна (рис. 6.37).

Рис. 6.37. Задержки при обработке почты сервером Exchange при отъеме памяти с помощью balloon или vmkernel swap

Если отнять 9 из 12 Гб памяти баллоном, то это даст удвоение latency, в то время как отнятие 2 Гб из 12 при помощи vmkernel swap – утридцатиение (!). Опять  же Exchange использует  всю доступную память для кеширования данных с целью минимизации обращения  к дискам.

Таким образом, если использование подкачки  неизбежно,  balloon – это меньшее зло. Однако  еще разок замечу – по моему мнению, вам редко придется  оказаться  в ситуации,  когда balloon  будет работать  из-за  нехватки памяти.  И даже если такая ситуация  случится,  balloon даст снижение производительности, просто почти всегда меньшее снижение, чем использование vmkernel swap.

А теперь сравним это еще и с compression.

Как видим,  при  использовании механизма  balloon  довольно  безболезненно можно отобрать 8 из 32 Гб памяти, а с memory compression – еще 2 Гб.

Как видно, compression – не панацея, но если уж памяти жестко не хватает, то с compression лучше, чем без него (лучше, чем только с vmkernel swap сразу после balloon, если быть точным). Нагрузка на процессоры  увеличивается на 1–2%, что неощутимо.

Первоисточник данных  тестирования –  документ  «Understanding  Memory Resource  Management in VMware  ESX  4.1»  (http://www.vmware.com/resources/ techresources/10129).

Рис. 6.38. Отъем памяти у сервера SharePoint механизмами memory compression и vmkernel swap

6.2.3. Disk

Одним  из механизмов  управления ресурсами дисковой  подсистемы  у ESX(i) можно  рассматривать настойки  Multipathing. Подробно  о них  рассказывалось в главе 3.

В версии  4.1 появился механизм  Storage  IO Control – о нем рассказывается в разделе 6.1.4.

6.2.4. Net

Из механизмов управления ресурсами сетевой подсистемы у ESX(i) есть только поддержка группировки контроллеров (NIC Teaming)  и ограничения пропускной способности канала (traffic shaping). Подробно о них рассказывалось в главе 2.

Кроме того, в версии 4.1 появился механизм  Network  IO Control,  о нем рассказано в разделе 6.1.5.

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

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

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

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