Из Википедии, бесплатной энциклопедии
Перейти к навигации Перейти к поиску

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

Введение в проблему [ править ]

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

Возможные решения [ править ]

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

Для ЦП можно использовать надлежащие методы планирования на уровне гипервизора, чтобы ограничить объем вычислений, которые каждая виртуальная машина может наложить на общий физический ЦП или ядро. Например, для гипервизора Xen были предложены планировщики BVT, Credit-based и S-EDF для управления распределением вычислительной мощности между конкурирующими виртуальными машинами. [1] Чтобы получить стабильную производительность в виртуализированных приложениях, необходимо использовать конфигурации планировщика, не сохраняющие работу . Кроме того, в гипервизоре KVM некоторые предложили использовать стратегии планирования на основе EDF [2] для поддержания стабильной и предсказуемой производительности виртуализированных приложений. [3] [4] Наконец, смногоядерный или многопроцессорный физический хост , каждую виртуальную машину можно развернуть на отдельном процессоре или ядре, чтобы временно изолировать производительность различных виртуальных машин.

Для сети можно использовать методы формирования трафика , чтобы ограничить объем трафика, который каждая виртуальная машина может накладывать на хост. Кроме того, можно установить несколько сетевых адаптеров на одном физическом хосте и настроить уровень виртуализации так, чтобы каждая виртуальная машина могла предоставлять монопольный доступ каждому из них. Например, это возможно с доменами драйверов гипервизора Xen. Существуют сетевые адаптеры с несколькими очередями, которые поддерживают несколько виртуальных машин на аппаратном уровне, имея отдельные очереди пакетов, связанные с различными размещенными виртуальными машинами (посредством IP-адресов виртуальных машин), например устройства очереди виртуальных машин (VMDq) от Intel. . [5]Наконец, планирование ЦП в реальном времени также может использоваться для улучшения временной изоляции сетевого трафика от нескольких виртуальных машин, развернутых на одном ЦП. [6]

При использовании планирования в реальном времени для управления объемом ресурсов ЦП, зарезервированных для каждой виртуальной машины, одной сложной проблемой является правильный учет времени ЦП, применимого к общесистемной деятельности. Например, в случае планировщика Xen службы Dom0 и доменов драйверов могут совместно использоваться несколькими виртуальными машинами, обращающимися к ним. Точно так же в случае гипервизора KVM рабочая нагрузка, налагаемая на ОС хоста из-за обслуживания сетевого трафика для каждой отдельной гостевой ОС, может быть нелегко различимой, поскольку она в основном включает драйверы устройств уровня ядра и сетевую инфраструктуру (на хосте). ОПЕРАЦИОННЫЕ СИСТЕМЫ). Для случая Xen были предложены некоторые методы устранения таких проблем. [7]

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

Ссылки [ править ]

  1. ^ Людмила Черкасова; Дивакер Гупта; Амин Вахдат (3 сентября 2007 г.), «Сравнение трех планировщиков ЦП в Xen» (PDF) , Обзор оценки производительности. Том 35, номер 2 , получено 30 июня 2010 г. CS1 maint: обескураженный параметр ( ссылка )
  2. ^ Fabio Checconi, Tommaso Cucinotta, Dario Faggioli, Giuseppe Lipari, Hierarchical Multiprocessor CPU Reservations for the Linux Kernel , Proceedings 5-го Международного семинара по платформам операционных систем для встроенных приложений реального времени (OSPERT 2009), Дублин, Ирландия, июнь 2009 г.
  3. ^ Томмазо Кучинотта, Гаэтано Анастаси, Лука Абени, Уважение временных ограничений в виртуализированных сервисах , Труды 2-го Международного семинара IEEE по сервис-ориентированной архитектуре и приложениям в реальном времени (RTSOAA 2009), Сиэтл, Вашингтон, июль 2009 г.
  4. ^ Томмазо Кучинотта, Гаэтано Анастаси, Лука Абени, Виртуальные машины реального времени , Труды 29-го системного симпозиума реального времени (RTSS 2008) - рабочая сессия, Барселона, декабрь 2008 г.
  5. ^ Shefali Chinni, Радхакришна Hiremane, Virtual Machine Device Очереди , Intel Virtualization Technology White Paper, 2007
  6. ^ Томмазо Кучинотта, Дхавал Джани, Дарио Фаджоли и Фабио Чеккони, Обеспечение гарантий производительности виртуальным машинам с использованием планирования в реальном времени , Труды 5-го семинара по виртуализации и высокопроизводительным облачным вычислениям (VHPC 2010), Искья (Неаполь), Италия, Август 2010 г.
  7. ^ Дивакер Гупта, Люси Черкасова, Роберт Гарднер, Амин Вахдат, Обеспечение изоляции производительности на виртуальных машинах в Xen , Труды 7-й Международной конференции по промежуточному программному обеспечению (Middleware 2006), Лекционные заметки по компьютерным наукам, том 4290/2006, стр 342-362 , Мельбурн, Австралия, ноябрь 2006 г.
  8. ^ Рипал Натхуджи; Аман Кансал и Алиреза Гаффархах (апрель 2010 г.), «Q-Clouds: Управление эффектами помех производительности для облаков с поддержкой QoS» , Proc. 5-й Европейской конференции по компьютерным системам (EuroSys 2010) , Париж, Франция