Временная изоляция между виртуальными машинами
 | Эта статья написана как личное размышление, личное эссе или аргументативное эссе , в котором излагаются личные чувства редактора Википедии или представлен оригинальный аргумент по определенной теме. ( февраль 2023 г. ) |
Временная изоляция или изоляция производительности между виртуальными машинами (ВМ) означает возможность изолировать временное поведение (или ограничивать временные взаимодействия) нескольких виртуальных машин друг с другом, несмотря на то, что они работают на одном физическом хосте и совместно используют набор физических ресурсов, таких как как процессоры, память и диски.
Введение в проблему
[ редактировать ]Одним из ключевых преимуществ использования виртуализации при консолидации серверов является возможность беспрепятственно «упаковать» несколько недостаточно используемых систем в один физический хост, тем самым достигая лучшего общего использования доступных аппаратных ресурсов. Фактически, вся операционная система (ОС) вместе с работающими в ней приложениями может быть запущена на виртуальной машине (ВМ). Однако когда несколько виртуальных машин одновременно работают на одном физическом хосте, они совместно используют доступные физические ресурсы, включая процессор (ы), сетевой адаптер (ы), диск (и) и память. Это добавляет уровень непредсказуемости производительности, которую может проявлять каждая отдельная виртуальная машина по сравнению с ожидаемой. Например, виртуальная машина с временным пиком вычислительной мощности может помешать работе других работающих виртуальных машин, что приведет к значительному и нежелательному временному снижению их производительности. В мире вычислений, который смещается в сторону парадигм облачных вычислений , где ресурсы (вычисления, хранилища, сети) можно удаленно арендовать в виртуализированной форме в соответствии с точными соглашениями об уровне обслуживания, было бы крайне желательно, чтобы производительность виртуализированных ресурсов была такой же стабильной. и максимально предсказуемо.
Возможные решения
[ редактировать ]Для решения вышеупомянутой проблемы можно использовать несколько методов. Они стремятся достичь некоторой степени временной изоляции между одновременно работающими виртуальными машинами на различных критических уровнях планирования : планирование ЦП, планирование сети и планирование диска.
Что касается ЦП, можно использовать правильные методы планирования на уровне гипервизора, чтобы ограничить объем вычислений, которые каждая виртуальная машина может налагать на общий физический ЦП или ядро. Например, на гипервизоре Xen были предложены планировщики BVT, Credit-based и S-EDF для управления распределением вычислительной мощности между конкурирующими виртуальными машинами. [1] Чтобы получить стабильную производительность в виртуализированных приложениях, необходимо использовать конфигурации планировщика, не экономящие работу . Кроме того, в гипервизоре KVM некоторые предложили использовать стратегии планирования на основе EDF. [2] для поддержания стабильной и предсказуемой производительности виртуализированных приложений. [3] [4] Наконец, при наличии многоядерного или многопроцессорного физического хоста можно развернуть каждую виртуальную машину на отдельном процессоре или ядре, чтобы временно изолировать производительность различных виртуальных машин.
В сети можно использовать методы формирования трафика , чтобы ограничить объем трафика, который каждая виртуальная машина может наложить на хост. Кроме того, на одном физическом хосте можно установить несколько сетевых адаптеров и настроить уровень виртуализации так, чтобы каждая виртуальная машина могла предоставлять эксклюзивный доступ к каждому из них. Например, это возможно с помощью доменов драйверов гипервизора Xen. Существуют сетевые адаптеры с несколькими очередями, которые поддерживают несколько виртуальных машин на аппаратном уровне, имея отдельные очереди пакетов, связанные с разными размещенными виртуальными машинами (посредством IP-адресов виртуальных машин), например устройства очереди устройств виртуальной машины (VMDq) от Intel. . [5] Наконец, планирование ЦП в реальном времени также можно использовать для улучшения временной изоляции сетевого трафика от нескольких виртуальных машин, развернутых на одном ЦП. [6]
При использовании планирования в реальном времени для управления количеством ресурсов ЦП, зарезервированных для каждой виртуальной машины, одной сложной проблемой является правильный учет времени ЦП, применимого к общесистемным действиям. Например, в случае планировщика Xen службы Dom0 и доменов драйверов могут использоваться несколькими виртуальными машинами, имеющими к ним доступ. Аналогичным образом, в случае с гипервизором KVM рабочая нагрузка, налагаемая на ОС хоста из-за обслуживания сетевого трафика для каждой отдельной гостевой ОС, может быть нелегко различима, поскольку она в основном затрагивает драйверы устройств уровня ядра и сетевую инфраструктуру (на хосте). ОС). Для случая Xen были предложены некоторые методы смягчения таких проблем. [7]
В рамках адаптивного резервирования можно применять стратегии управления с обратной связью для динамической адаптации объема ресурсов, зарезервированных для каждой виртуальной машины, для поддержания стабильной производительности виртуализированных приложений. [8] Следуя тенденции адаптивности, в тех случаях, когда виртуализированная система не соответствует ожидаемому уровню производительности (либо из-за непредвиденного вмешательства других одновременно работающих виртуальных машин, либо из-за плохой стратегии развертывания, которая просто подхватила машину с недостаточными аппаратными ресурсами). ), можно выполнять миграцию виртуальных машин во время их работы, чтобы разместить их на более мощном (или менее загруженном) физическом хосте.
Ссылки
[ редактировать ]- ^ Людмила Черкасова; Дивакер Гупта; Амин Вахдат (3 сентября 2007 г.), «Сравнение трех планировщиков ЦП в Xen» (PDF) , Обзор оценки производительности. Том 35, номер 2 , получено 30 июня 2010 г.
- ^ Фабио Чеккони, Томмазо Кучинотта, Дарио Фаджиоли, Джузеппе Липари, Иерархическое резервирование многопроцессорных процессоров для ядра Linux , Материалы 5-го международного семинара по платформам операционных систем для встраиваемых приложений реального времени (OSPERT 2009), Дублин, Ирландия, июнь 2009 г.
- ^ Томмазо Кучинотта, Гаэтано Анастази, Лука Абени, Уважая временные ограничения в виртуализированных сервисах , Материалы 2-го международного семинара IEEE по сервис-ориентированной архитектуре и приложениям реального времени (RTSOAA 2009), Сиэтл, Вашингтон, июль 2009 г.
- ^ Томмазо Кучинотта, Гаэтано Анастази, Лука Абени, Виртуальные машины реального времени , Материалы 29-го симпозиума по системам реального времени (RTSS 2008) - сессия «Работа в процессе», Барселона, декабрь 2008 г.
- ^ Шефали Чинни, Радхакришна Хиремане, Очереди устройств виртуальных машин , Технический документ по технологии виртуализации Intel, 2007 г.
- ^ Томмазо Кучинотта, Дхавал Джани, Дарио Фаджиоли и Фабио Чеккони, Обеспечение гарантий производительности виртуальных машин с использованием планирования в реальном времени , Материалы 5-го семинара по виртуализации и высокопроизводительным облачным вычислениям (VHPC 2010), Искья (Неаполь), Италия, Август 2010.
- ^ Дивакер Гупта, Люси Черкасова, Роберт Гарднер, Амин Вахдат, Обеспечение изоляции производительности виртуальных машин в Xen , Материалы 7-й Международной конференции по промежуточному программному обеспечению (Middleware 2006), Конспекты лекций по информатике, том 4290/2006, стр. 342–362, Мельбурн, Австралия, ноябрь 2006 г.
- ^ Рипал Натуджи; Аман Кансал и Алиреза Гаффарха (апрель 2010 г.), «Q-Clouds: управление эффектами помех производительности для облаков с поддержкой QoS» , Proc. 5-й Европейской конференции по компьютерным системам (EuroSys 2010) , Париж, Франция