Содержание


Управление ресурсами на KVM-системах, поддерживающих overcommitment

Консолидация нагрузки за счет использования overcommitment при доступе к ресурсам

Comments

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

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

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

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

Проблемы, связанные с overcommitment

Всестороннее исследование применения overcommitment для работы с памятью в KVM на самом деле должно начаться с обзора менеджера памяти, используемого в Linux. Так как Linux построен на принципах виртуальной памяти, то в нем изначально используется overcommitment памяти.

Страницы памяти, запрашиваемые процессом, не выделяются до тех пор, пока они не начнут использоваться. Используя кэш страниц в Linux, несколько процессов могут экономить память, получая доступ к файлам через общие страницы. По мере того как объем свободной памяти уменьшается, система может освобождать память, выполняя свопинг редко используемых страниц на жесткий диск. Хотя это и не идеальное решение, подобные действия могут привести к тому, что количество выделенной памяти будет значительно отличаться от количества действительно используемой памяти.

Так как виртуальные машины KVM являются обычными процессами, то к ним применяются стандартные приемы экономии памяти. Но в отличие от обычных процессов, гостевые машины KVM содержат вложенные операционные системы, которые двумя способами воздействуют на распределение памяти в режиме overcommitment и поэтому обладают большими возможностями в этой области, нежели обычные процессы. Это связано с колебаниями уровня нагрузки, которые обеспечивают большой разрыв между минимальными и максимальными требованиями к памяти со стороны гостевой системы.

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

В Linux доступны дополнительные механизмы для работы с overcommitted-памятью в виртуализированной среде.

  • Memory ballooning – прием, когда базовая система отдает гостевой системе команду "освободить" некоторый объем выделенной ей памяти, так что она может использоваться для других целей. Этот способ помогает облегчить выделение памяти, переложив эту задачу с базовой системы на гостевую.
  • Kernel Same-page Merging (KSM) – технология, в которой поток ядра сканирует заранее определенный диапазон памяти для идентификации идентичных страниц, объединяет их и освобождает память, занимаемую дубликатами. Такой способ организации общего доступа к памяти может оказаться выгодным для систем, на которых запущено множество однородных виртуальных машин.
  • Другие возможности для управления ресурсам (например, Cgroups) также применяются для работы с памятью в режиме overcommitment и могут динамически распределять ресурсы между виртуальными машинами.

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

Например, отдельный qemu-процесс не может знать, что базовая система исчерпала ресурсы памяти и сколько памяти может быть «освобождено» гостевой системой без негативного воздействия на производительность. Эти решения могут приниматься, только тогда, когда административная политика сочетается с использованием актуальной информации о базовой и гостевых системах.

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

Использование механизма overcommitment оказывает фундаментальное влияние на то, как гостевая и базовая система управляют памятью. В результате одновременное использование нескольких механизмов может привести к возникновению побочных эффектов. На рисунке 1 показано, какое влияние memory ballooning оказывает на эффективность применения KSM.

Рисунок 1. Влияние memory ballooning на эффективность работы KSM
Рисунок 1. Влияние memory ballooning на эффективность работы KSM
Рисунок 1. Влияние memory ballooning на эффективность работы KSM

В данном примере из-за memory ballooning KSM не может эффективно объединить страницы. Драйверы memory ballooning на гостевой операционной системе выбирают, какие страницы необходимо отдать, без учета того, что эта страница в базовой системе может использоваться в режиме совместного доступа. Освобождение совместно используемой страницы является ошибкой, так как оно отнимает ресурсы у гостевой системы и при этом не ведет к экономии памяти. Для максимальной эффективности эти варианты поведения должны быть предусмотрены и обработаны.

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

Использование памяти в режиме overcommitment может повысить требования и к другим системным ресурсам. Частое обращение к кэш-памяти вызовет увеличение запросов ввода/вывода к дисковым или сетевым ресурсам, а возросшее количество операций по высвобождению страниц памяти (page reclaim) заставит гостевую систему потреблять больше ресурсов CPU.

Всех этих проблем можно избежать с помощью демона MOM (Memory Overcommitment Manager), специально спроектированного для решения данной задачи.

Динамическое управление с помощью MOM

The MOM (Memory Overcommitment Manager) daemon is shown in Figure 2.

Рисунок 2. Memory Overcommitment Manager
Рисунок 2. Memory Overcommitment Manager
Рисунок 2. Memory Overcommitment Manager

Технология MOM реализует гибкую инфраструктуру для сбора статистики о базовой и гостевой системах, механизм политик и контрольные точки для реализаций memory ballooning и KSM. C её помощью администратор может создавать политики для управления overcommitted-памятью в реальном времени, позволяющие динамически настраивать параметры системы для достижения еще большего уровня использования overcommitted-памяти.

Технология MOM использует библиотеку libvirt, чтобы создать список виртуальных машин, запущенных на системе. Данные о базовой и гостевых системах собираются через определенный интервал времени и могут поступать из разных источников (интерфейс /proc базовой системы, libvirt API, virtio-serial или сетевое подключение к гостевой системе). После сбора данные упорядочиваются для последующего использования механизмом политик. Технология virtio – это стандарт для драйверов сетевых и дисковых устройств, благодаря которому драйвер устройства на гостевой системе знает о том, что он работает в виртуальной среде и может взаимодействовать с гипервизором, чтобы обеспечить гостевой системе высокую производительность при выполнении операций с жестким диском или сетевой картой. В общем случае именно Virtio обеспечивает основные преимущества паравиртуализации в области производительности.

Механизм политик (policy engine) – это обычно небольшой интерпретатор, понимающий программы, написанные на простом языке политик. Периодически MOM пересматривает политику, предоставленную пользователем, с учетом накопленных данных. Политика может активировать изменения в конфигурации, например, увеличение balloon-памяти гостевой системы или изменение периода сканирования в KSM.

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

Оценка эффективности MOM

Чтобы оценить насколько эффективно технология MOM управляет overcommitted-памятью, можно рассмотреть два примера виртуализированной рабочей нагрузки.

  • в первом случае виртуальные машины настроены задействовать различное количество анонимной памяти, согласно предопределенному шаблону доступа;
  • второй пример использует эталонную LAMP-платформу (Linux Apache MySQL PHP), где на каждой виртуальной машине функционирует независимый экземпляр MediaWiki.

Для каждого типа нагрузки оценивается политика MOM, управляющая процессом memory ballooning и KSM. Чтобы избежать свопинга на базовой системе, memory balloon область на каждой гостевой платформе динамически регулируется в зависимости от нагрузки на память базовой и гостевой системы. В случае с KSM, используется такой же алгоритм, как и в ksmtuned, а его параметры регулируются в зависимости от нагрузки на память и количества доступной общей памяти.

Два примера виртуализированной нагрузки

В первом тестовом сценарии Memknobs используется простая программа Memknobs для создания нагрузки на память путем выделения и "пометки" страниц анонимной памяти согласно шаблону, который оказывает негативное воздействие на механизмы возврата памяти, имеющиеся в ядре. Программа Memknobs выделяет буфер фиксированного размера и выполняет итерацию по страницам буфера, записывая некие данные на каждой странице. Путем неоднократного вызова Memknobs с постепенным изменением размера буфера на каждой итерации, гостевая система может симулировать нагрузку на память без привлечения компонентов ввода/вывода. Чтобы заставить работать ovecommitment памяти на базовой системе, необходимо развернуть Memknobs на 32 виртуальных машинах, при этом каждый экземпляр должен использовать память согласно уникальному шаблону.

В сценарии Cloudy реалистичная нагрузка для дискового устройства ввода/вывода генерируется с помощью open source пакета Cloudy. Пакет Cloudy – это легконастраиваемая эталонная реализация LAMP-платформы, который измеряет масштабируемость виртуализации и показывает эффект от использования overcommitted-ресурсов. Виртуальные машины конфигурируются как MediaWiki-сервера, при этом каждый Wiki-экземпляр заполняется страницами из Wikipedia и случайно сгенерированными изображениями.

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

Политика

Стратегия memory ballooning специально спроектирована так, чтобы предотвратить свопинг на базовой системе, вместо этого перекладывая нагрузку на память на гостевые системы. Базовая система не обладает информацией о доступе гостевых систем к страницам памяти, и поэтому при выборе страниц для свопинга не может адекватно настроить LRU-алгоритмы. Более того, гостевая операционная система обладает большей информацией о том, как рабочая нагрузка использует память, и поэтому может принимать более качественные решения о том, какие страницы подлежат замене.

Политика использует memory ballooning для организации пула памяти базовой системы, готовой к освобождению. Данная область памяти (freeable memory) состоит из MemFree (свободной памяти), Buffers (буферов) и Cache (кэша), как указано в файле /proc/meminfo. Когда размера пул становиться меньше 20% общего количества памяти, запускается процесс memory ballooning. На гостевые системы оказывается "давление", соответствующее уровню "давления" на память базовой системы. Сначала освобождается свободная память, так что гостевые системы с большим количеством неиспользуемой памяти "накачиваются" сильнее всего. Когда достигается достаточное давление, гостевые системы удаляют закэшированные страницы и начинают свопинг. Когда нагрузка на память ослабевает, "пузыри" начинают "сдуваться" и память возвращается обратно гостевым системам.

Используемый алгоритм настройки KSM спроектирован так, чтобы соответствовать ksmtuned. Решение о запуске потока ядра принимается в зависимости от доступного количества свободной памяти (как минимум 20% от общего количества памяти) принимается. KSM может начать работу только при одновременном выполнении двух следующих условий:

  • количество свободной памяти отклонилось от порогового значения;
  • общий объем памяти меньше суммарного количества памяти, выделенного всем виртуальным машинам.

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

После того как ksmd был активирован, его поведение настраивается в зависимости от общего размера памяти и нагрузки на память. Период "сна" между сканированиями зависит от размера памяти базовой системы. Для базовой системы с 16ГБ памяти интервал по умолчанию составляет 10 секунд. Для больших объемов памяти интервал между сканированиями сокращается, а для меньших увеличивается. Количество страниц, сканируемых за один проход, уменьшается или увеличивается в зависимости от количества свободной памяти. Если количество свободной памяти меньше порогового значения, то объем сканирования увеличивается на 30 страниц, а в противном случае уменьшается на 50. Количество сканируемых страниц должно находиться в диапазоне от 64 до 1250.

Результаты

Практические эксперименты проводились на сервере IBM BladeCenter® HS22. Эта система содержит 16 логических процессоров с поддержкой EPT и 48ГБ RAM. Для увеличения емкости запоминающих устройств и скорости доступа к ним виртуальные машины размещались на внешнем NFS-устройстве, подключенном через частную сеть 10 gigabit Ethernet. В ходе опытов оценивалась эффективность политики MOM для нагрузочных сценариев Memknobs и Cloudy. Для измерения влияния на производительность для каждого сценария выполнялись одночасовые тесты с активированной MOM-политикой и без нее.

Нагрузочный сценарий Memknobs

В этом эксперименте использовались 32 виртуальные машины, каждая из которых имела 2ГБ RAM-памяти и один виртуальный CPU. Нагрузка на память в сценарии Memknobs (см. рисунок 3) была откалибрована для создания такого «давления» на память базовой системы, чтобы регулярно запускался процесс свопинга. Экспериментальным путем удалось получить модель, которая обеспечила поведение, требуемое от базовой системы.

Рисунок 3. Модель доступа к памяти, используемая в Memknobs
Рисунок 3. Модель доступа к памяти, используемая в Memknobs
Рисунок 3. Модель доступа к памяти, используемая в Memknobs

Программа Memknobs отслеживает количество страниц, которые она «затронула» за время итерации. Этот показатель пропускной способности определяется количеством мегабайт памяти, «затронутых» за секунду. Чтобы облегчить сравнение между различными экспериментами, было вычислено суммарное среднее значение пропускной способности путем вычисления средней пропускной способности каждой гостевой системы и последующего суммирования 32-ух полученных значений. В таблице 1 приведены значения, полученные при использовании различных политик Memory Overcommitment Manager.

Таблица 1. Результаты применения MOM-политик: суммарная средняя пропускная способность Memknobs
MOM-политикаРезультат
без политики4331.1
только KSM4322.6
KSM и ballooning5399.5

Эти результаты показывают, что использование memory ballooning обеспечивает 20% прироста пропускной способности. Хотя KSM и была крайне эффективна в распределении страниц при данной нагрузке, но не она обеспечила прирост производительности. На рисунке 4 приведено сравнение, сколько операций свопинга выполнялось в Memknobs при использовании memory ballooning и без него.

Рисунок 4. Сравнение интенсивности свопинга в Memknobs
Рисунок 4. Сравнение интенсивности свопинга в Memknobs
Рисунок 4. Сравнение интенсивности свопинга в Memknobs

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

Нагрузочный сценарий Cloudy

Для корректной настройки Cloudy под используемую среду были подготовлены 32 виртуальных машины с MediaWiki. Этот нагрузочный сценарий потребляет меньше памяти, нежели Memknobs. Чтобы реализовать ограничение по объему памяти для гостевых систем, для каждой из них было выделено по 1 ГБ RAM. Для компенсации уменьшения объема памяти, доступного виртуальным машинам, были зарезервированы 15174 "больших" страниц, что фактически уменьшило память, доступную базовой системе, до 16 ГБ.

План тестирования для JMeter был сконфигурирован таким образом, чтобы в среднем за минуту доставлять 16 запросов на каждую виртуальную машину. Это обеспечивает среднюю нагрузку без "узких" мест, когда система не находится в overcommitted-режиме. JMeter записывает статистику по каждому выполненному запросу, и исходя из этого оценивается метрика QoS (quality of service – качество обслуживания) – длительность обработки 95% запросов, выражаемая в миллисекундах. Средняя пропускная способность одной виртуальной машины будет равна отношению общего количества выполненных запросов (в килобайтах) к числу задействованных гостевых систем.

В таблице 2 приведены значения QOS и пропускной способности, полученные в результате запуска сценария с активированными KSM, memory ballooning и MOM-политикой и без них.

Таблица 2. Значения QOS и пропускной способности для сценария Cloudy
Количество виртуальных машин MOM-политикаQoSПропускная способность
1не активирована1669710007
32не активирована3240774555
32активирована3231764762

Результаты запуска сценария на одиночной виртуальной машине приведены, чтобы продемонстрировать производительность ничем неограниченной базовой системы. Главным результатом, полученным в ходе эксперимента, является тот факт, что MOM-политика, которая радикально улучшила производительность в сценарии Memknobs, не оказала никакого эффекта на сценарий Cloudy. При данной нагрузке использование памяти в основном связано с файловым вводом/выводом, а не анонимной памятью, и поэтому свопинг почти не наблюдается. Вместо этого, overcommitment памяти оказывает "давление" на кэш-память страниц базовой и гостевых систем, что приводит к увеличению количества запросов ввода/вывода, так как система старается "удержать" используемый набор данных в небольшом объеме памяти (см. рисунок 5).

Рисунок 5. Влияние memory ballooning на количество I/O-запросов в отдельной гостевой системе
Рисунок 5. Влияние memory ballooning на количество I/O-запросов в отдельной гостевой системе
Рисунок 5. Влияние memory ballooning на количество I/O-запросов в отдельной гостевой системе

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

Анализ результатов

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

Перспективы дальнейшего развития

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

Сегодня не существует стандартного способа для общения между базовой и гостевыми системами. Используемые подходы (например, сетевое взаимодействие между гостевой и базовой системами) зависят от конфигурации и настройки базовой и гостевых систем, которую необходимо выполнять вручную. При этом реализация данного процесса зависит от типа и версии операционных систем, конфигурации сетевых интерфейсов и модели сетевых устройств, используемой гостевой системой. Наша задача – это упростить эту задачу за счет интеграции коммуникационного механизма в qemu, чтобы обеспечить поддержку различных транспортных протоколов, включая virtio-serial и emulated serial. На стороне гостевой системы канал может поддерживаться мультиплатформенным open-source пакетом qemu-guest-tools. Такой механизм улучшает возможности MOM по сбору статистики о гостевых системах и может использоваться для copy / paste и задач администрирования.

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

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

Как только сообщество разработает новые функции, улучшающие возможности KVM в области overcommitment, их поддержка будет интегрирована в инфраструктуру MOM. Например, планируется добавить поддержку для RSS-ограничений на основе cgroups, чтобы контролировать действия memory ballooning и защищать систему от несогласованных или злонамеренных гостевых систем.

Заключение

Использование ресурсов в режиме overcomittment является ключом к получению максимальной выгоды от виртуализации и темой множества исследований и разработок. По мере развития виртуализации в Linux, также развиваются и приемы использования overcommitment. Глобальный подход к управлению overcommitment с помощью политик – это лучший способ повысить эффективность или внедрить улучшения.

Благодарность

Из большого списка коллег, автор хотел бы особенно поблагодарить Энтони Лигуори (Anthony Liguori) и Карла Ристера (Karl Rister). Их советы и технический опыт оказали неоценимую помощь в проектировании и разработке Overcommitment Manager и в написании этой статьи.


Ресурсы для скачивания


Похожие темы


Комментарии

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

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Linux
ArticleID=800761
ArticleTitle=Управление ресурсами на KVM-системах, поддерживающих overcommitment
publish-date=03062012