July 10th, 2012 
admin
Однако в теории накладные расходы имеют место быть: если какая-то ВМ хочет изменить разделяемую с другими страницу памяти, с помощью технологии 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 с.: ил.
Опубликовано в рубрике