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

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

1. Введение

Облачные вычисления — важнейший элемент современной инфраструктуры, обеспечивающий доступные вычислительные ресурсы и мощность. Он охватывает различные модели обслуживания, включая локальные облачные сервисы, владельцы которых несут ответственность за настройку всех процессов, от сетевого уровня до стека приложений. Инфраструктура как услуга (IaaS) позволяет использовать реальные вычислительные ресурсы посредством виртуализации на уровне системы. Эта модель предоставляет пользователям контроль над виртуальной облачной инфраструктурой, включая виртуальные процессоры, память (ОЗУ), сеть и хранилище. Это позволяет им управлять как инфраструктурой, так и программным обеспечением, а также дополнительными инструментами. Платформа как услуга (PaaS) касается операционной системы, промежуточного программного обеспечения и среды выполнения, устраняя необходимость для пользователей управлять этими компонентами и позволяя им сосредоточиться на управлении своими данными и приложениями. Программное обеспечение как услуга (SaaS) предлагает полностью управляемые облачные приложения от поставщиков услуг.

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

Миграция виртуальных машин между серверами в системе облачных вычислений — важнейший аспект управления современной облачной инфраструктурой. Этой теме посвящено множество недавних научных работ. Обзор этих работ можно найти в разделе 2 . В этой статье основное внимание уделяется модели очередей для анализа миграции виртуальных машин между серверами в системе облачных вычислений. Опираясь на механизм миграции виртуальных машин, описанный в [ 1 ], мы адаптируем подход использования ресурсов для миграции к перспективе обработки задач. Это позволяет также учитывать стохастический характер использования ресурсов в виде случайного поступления задач и случайной продолжительности обработки задач.

Основные результаты нашего исследования заключаются в следующем:

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

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

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

Оставшаяся часть теста организована следующим образом. В разделе 2 представлен обзор сопутствующей работы в области миграции виртуальных машин. В разделе 3 подробно описана формализация модели с точки зрения использования ресурсов на основе [ 1 ]. В разделе 4 представлена модель массового обслуживания с точки зрения обработки задач и некоторых представляющих интерес показателей. В разделе 5 мы представляем наглядные численные результаты для этих метрик, анализируя влияние скорости поступления задач на серверы и их средней продолжительности. Выводы сделаны в заключительном разделе 6 .

2. Миграция виртуальных машин в облачных вычислениях

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

2.1. Типы миграции виртуальных машин

Миграция ВМ — это процесс переноса ВМ с одного сервера на другой [ 2 ]. Это включает в себя перемещение памяти виртуальной машины, дискового хранилища и сетевых подключений. Существует два основных типа миграции: статическая и динамическая. Статическая миграция основана на предварительном знании шаблонов рабочей нагрузки и влечет за собой решение проблемы размещения виртуальных машин для всех виртуальных машин и доступных хостов. И наоборот, динамическая миграция позволяет перемещать виртуальные машины после их первоначального распределения. Этот процесс требует постоянного мониторинга для обнаружения конфликтов за ресурсы и потенциальных сбоев в обслуживании. Динамическая миграция облегчается динамическим распределением ресурсов — сложным подходом, позволяющим управлять непредсказуемыми рабочими нагрузками [ 3 ]. Динамическую миграцию можно разделить на периодическую и миграцию в реальном времени. Периодическую миграцию можно планировать вручную или запускать при изменении состояния системы, например при добавлении или удалении сервера [ 4 ].

Кроме того, миграцию виртуальных машин можно разделить на офлайновую и онлайновую (живую) [ 5 ]. Автономная миграция требует остановки или завершения работы виртуальной машины перед переносом на другой хост, что может привести к перебоям в обслуживании и отрицательно повлиять на удобство работы пользователей и соглашения об уровне обслуживания (SLA) [ 6 ]. Напротив, живая миграция позволяет виртуальной машине оставаться в рабочем состоянии во время передачи, сохраняя доступ к ее оперативной памяти, хранилищу и состояниям сети. Динамическая миграция направлена на минимизацию времени простоя и общего времени миграции, обеспечивая при этом качество обслуживания и доступность услуг [ 7 ]. В зависимости от последовательности, в которой страницы памяти передаются от источника к хосту назначения, живая миграция может быть дополнительно классифицирована как предварительное копирование или посткопирование [ 8 ].

Живая миграция предлагает различные преимущества по сравнению с автономной миграцией. Одним из заметных преимуществ является возможность быстрого масштабирования центров обработки данных без нарушения качества обслуживания (QoS) [ 9 ]. Живая миграция перед копированием обычно выполняется быстрее, чем после копирования, поскольку она непрерывно переносит страницы памяти с исходного компьютера без перерывов [ 10 ]. Альтернативно, миграция после копирования изначально отправляет только минимальный набор страниц памяти и передает дополнительные страницы по запросу от целевого сервера [ 11 ].

Предварительная живая миграция состоит из шести отдельных фаз, как описано в [ 12 ]. Первый этап включает в себя выбор виртуальной машины для миграции и выбор для нее нового хоста. Второй этап, резервирование, требует подтверждения от целевого хоста, что он может выполнить миграцию. На третьем этапе, итеративном предварительном копировании, вся оперативная память виртуальной машины копируется на новый хост. Четвертый этап — остановка и копирование — предполагает закрытие исходной виртуальной машины и перенос состояния ее центрального процессора (ЦП). На пятом этапе (обязательство) новый хост подтверждает успешную миграцию и проверяет наличие каких-либо вмешательств. Заключительный этап — активация — происходит, если не обнаружено никакого вмешательства, что позволяет полностью активировать виртуальную машину на новом хосте. После этого исходная ВМ выводится из эксплуатации со старого сервера.

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

2.2. Перегруженные и недогруженные серверы

Миграция виртуальных машин включает в себя две задачи: во-первых, определение оптимального размещения новой виртуальной машины в центре обработки данных и, во-вторых, оптимизация текущего распределения виртуальных машин. Это подчеркивает, что миграция виртуальных машин состоит из двух важнейших компонентов: (i) выявление перегруженных и недогруженных серверов в центре обработки данных и (ii) выбор виртуальных машин для миграции. Таким образом, процесс миграции ВМ между серверами неразрывно связан с состоянием серверов в дата-центре [ 1 , 13 ]. Целесообразно инициировать миграцию при наличии перегруженных или недогруженных серверов. Перегруженные серверы приводят к более высоким показателям энергопотребления, а недогруженные серверы приводят к неэффективному использованию центров обработки данных и потерям энергии [ 14 ].

Определение перегруженных и недогруженных серверов обычно основано на заранее определенных пороговых значениях рабочей нагрузки. Эти пороговые значения могут устанавливаться статически или динамически, причем преобладают оба метода. В алгоритмах статического порога пороговые значения постоянны на протяжении всего процесса миграции [ 15 ]. Реактивные контроллеры обнаруживают любое избыточное использование ресурсов на сервере на основе этих пороговых значений [ 3 ]. Если использование системных ресурсов превышает установленный порог, сервер считается перегруженным, что запускает алгоритм миграции.

И наоборот, алгоритмы динамического порога корректируют пороговые значения с течением времени в соответствии с общей рабочей нагрузкой [ 16 ]. Здесь сервер считается перегруженным, если использование его ресурсов (например, ЦП, ОЗУ, пропускной способности сети) достигает своей мощности и превышает верхнее пороговое значение [ 1 , 13 , 17 ]. Размещение перегруженного сервера может ухудшить качество обслуживания приложений, работающих на нем. Напротив, недогруженный сервер падает ниже нижнего порога, что указывает на неоптимальную загрузку.

2.3. Выбор ВМ для миграции

Для эффективного управления динамической миграцией виртуальных машин важно выявлять случаи дисбаланса использования как для текущего, так и для будущих периодов. Это включает в себя определение приоритета серверов с чрезмерным использованием для разгрузки виртуальных машин и рассмотрение альтернативных политик для недогруженных серверов. Миграция виртуальной машины запускается, когда состояние сервера угрожает деградацией ресурсов, что может привести к сбою в обслуживании. Например, перегруженный сервер может вызвать конфликт ресурсов и повлиять на производительность службы. Напротив, недогруженный сервер может привести к неэффективному использованию ресурсов, но представляет минимальный риск для непрерывности обслуживания. Следовательно, чрезмерное использование является основным стимулом для начала процедур ребалансировки [ 1 , 13 ].

Помимо пороговых значений использования ресурсов, при выборе виртуальной машины для миграции с сервера необходимо учитывать и другие факторы. Время миграции увеличивается линейно с размером ОЗУ виртуальной машины, поэтому предпочтительным является меньший объем ОЗУ [ 1 ]. Загрузка ЦП также может служить критерием выбора виртуальной машины, причем более желательным является более низкий коэффициент использования [ 18 ]. Этот метод, известный как политика наивысшего потенциального роста, позволяет повысить загрузку сервера без увеличения расходов на будущую миграцию [ 10 , 19 ].

Стратегия динамической консолидации виртуальных машин включает информацию от пользователей служб, размещенных в центре обработки данных. Как показано в [ 6 ], включение предоставленной пользователем информации, такой как время выпуска, указывающее, когда виртуальная машина больше не требуется для ее услуг, повышает энергоэффективность центра обработки данных. Это демонстрирует преимущества использования информации о пользователях в алгоритмах консолидации.

2.4. Сроки миграции виртуальных машин

Балансировка нагрузки виртуальных машин между серверами может быть вызвана различными факторами [ 20 ]. Одним из таких факторов является нарушение состояния системы, например, чрезмерное или недостаточное использование сервера. Еще одним триггером является размещение новой виртуальной машины. Процесс запуска алгоритмов балансировки нагрузки может быть инициирован отправителем или получателем [ 20 ]. Эти алгоритмы основаны на определениях перегруженных и недогруженных серверов [ 21 ]. Алгоритмы, инициируемые отправителем, переносят нагрузку с перегруженных серверов на недогруженные, тогда как алгоритмы, инициируемые получателем, распределяют нагрузку со всех недогруженных серверов, чтобы уменьшить общее количество активных серверов. Однако метод, инициируемый получателем, может привести к увеличению нагрузки на серверы, принимающие нагрузку от недогруженных серверов.

Методы балансировки нагрузки также можно разделить на статические и динамические типы [ 20 , 22 , 23 ]. Методы статической балансировки нагрузки, инициируемые состоянием системы, могут быть реализованы с помощью алгоритмов циклического перебора (RR) или взвешенного циклического перебора (WRR). Эти алгоритмы запускаются по расписанию. В RR виртуальные машины распределяются по серверам в зависимости от порядка их появления в системе. WRR учитывает характеристики виртуальных машин в процессе распределения, присваивая веса каждой виртуальной машине. Однако этот метод может занять больше времени, чем простой RR. Оппортунистическая балансировка нагрузки — ветвь, вытекающая из методов статической балансировки нагрузки [ 24 ], не учитывает текущую рабочую нагрузку узла и назначает виртуальные машины всем доступным серверам в свободном порядке. Другие типы включают алгоритмы min-max и max-min, основанные на времени выполнения задач.

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

Наиболее часто используемый тип миграции — это живая миграция перед копированием, при которой состояние виртуальной машины переносится, пока исходная виртуальная машина все еще работает [ 2 ]. Однако в тех случаях, когда встречаются измененные страницы памяти, изменения не отражаются сразу и их необходимо скопировать снова позже [ 12 ]. Если имеется значительное количество изменений и процесс передачи измененных страниц превышает определенное количество попыток, эти страницы будут пропущены [ 27 ]. Следовательно, время миграции становится непредсказуемым и может даже завершиться неудачей, если на виртуальной машине имеется большое количество часто записываемых страниц [ 28 ].

Остановка и копирование — это гибридный подход, при котором виртуальная машина ненадолго приостанавливается и передаются только определенные страницы памяти, например те, к которым виртуальная машина часто обращается [ 12 ]. Такой подход помогает сократить время простоя за счет ограничения количества передач. С другой стороны, при динамической миграции после копирования изначально передаются только данные, необходимые для запуска виртуальной машины в пункте назначения. Остальные страницы памяти затем отправляются за один шаг после запуска виртуальной машины. Хотя этот подход обеспечивает предсказуемое время миграции, он также имеет недостатки, такие как более длительное время миграции и более высокая вероятность ошибок сетевой передачи.

2.5. Выбор целевого сервера для миграции ВМ

Выбор наиболее подходящего сервера для конкретной виртуальной машины — решающий шаг в оптимизации производительности центра обработки данных. Это решение зависит от желаемой целевой функции, которая может варьироваться в зависимости от решаемой задачи оптимизации. Основной целью оптимизации центра обработки данных является сокращение общего количества активных серверов и минимизация энергопотребления [ 29 ]. В некоторых случаях основное внимание может быть сосредоточено исключительно на минимизации энергопотребления, при этом выбранный сервер будет иметь самое низкое энергопотребление в центре обработки данных [ 30 ].

Эвристические алгоритмы часто используются для поиска возможных решений NP-сложной проблемы размещения виртуальных машин. Многие из этих алгоритмов основаны на биоинспирированной популяционной метаэвристике [ 31 , 32 ]. Например, оптимизация роя частиц использует четыре ключевых компонента — начальное положение, скорость, вес и функцию приспособленности — для определения ее эффективности. Другие подходы могут быть направлены на минимизацию времени и стоимости миграции и оптимизацию глобального QoS [ 33 ] или сосредоточение внимания на распределении ресурсов и консолидации серверов в центре обработки данных [ 15 ].

Беспороговый метод является альтернативой определения статуса сервера. Этот подход избегает статических пороговых значений и вместо этого идентифицирует сильно загруженные серверы на основе текущих показателей использования, таких как параметры ЦП и ОЗУ. Миграция происходит только в том случае, если прогнозируемые значения превышают пороговое значение как в настоящее, так и в будущем. Ключевым преимуществом беспороговых алгоритмов является их эффективность по времени [ 6 ]. Однако некоторые алгоритмы также могут учитывать не только улучшение использования сервера, но и скорость снижения его производительности после миграции [ 4 ], тем самым поддерживая качество обслуживания для пользователей и одновременно оптимизируя использование ресурсов.

Методы на основе искусственного интеллекта могут контролировать производительность системы, управляя скоростью использования ресурсов [ 34 ]. Другая стратегия предполагает использование линейной регрессии для прогнозирования будущего потребления ЦП на сервере и принятия упреждающих решений о миграции, чтобы избежать нарушений SLA [ 35 ]. Эти методы очень точны, поскольку используют различные методы искусственного интеллекта или их комбинации. Тем не менее, они могут иметь такие недостатки, как высокая стоимость и высокие требования к вычислительной мощности. Марковский процесс принятия решений, оптимизированный с помощью обучения с подкреплением (RL), является еще одним методом, применяемым в этом контексте [ 36 ]. Кроме того, глубокое обучение можно комбинировать с RL для изучения характеристик данных и изучения стратегий планирования, или его можно применять непосредственно к проблеме размещения виртуальных машин [ 37 ]. Для этой цели также использовались цепи Маркова [ 18 ].

2.6. Снижение скорости обслуживания при миграции виртуальных машин

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

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

2.7. Краткое изложение последних избранных работ по миграции виртуальных машин

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

Процесс миграции включает в себя перенос виртуальных машин (ВМ) с перегруженных серверов на серверы с меньшим использованием ресурсов. Эта методология направлена на снижение энергопотребления в центрах обработки данных. Многочисленные исследования используют критерий высокого энергопотребления для определения перегруженного сервера [ 32 , 40 , 41 ]. Исследование в первую очередь подчеркивает необходимость оптимизации энергопотребления в средах с несколькими серверами, которые работают непрерывно, что приводит к значительному потреблению энергии. Более того, значительная часть исследователей характеризует перегруженность серверов на основании повышенной загрузки ЦП [ 42 , 43 ], общего потребления ресурсов на уровне отдельного сервера [ 44 ] и в целом кластера [ 45 ].

Таблица 1. Краткое описание последних избранных работ по миграции виртуальных машин.

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

3. Формализация модели с точки зрения использования ресурсов.

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

3.1. Общие предположения

Рассмотрим систему облачных вычислений, которая обеспечивает ИТ-инфраструктуру посредством ряда вычислительных ресурсов. Есть  Sзнак равно { 1 , … , S }

 серверы, на которых  Vзнак равно { 1 , … , V} Виртуальные машины работают, используя  R= { 1 , … , R } Ресурсы. Каждый s -сервер поддерживает минимальный объем  C0r sr -  ресурса , когда ни одна виртуальная машина не работает. Порог максимального объема r -ресурса, который может занять s -сервер, обозначается через  CМаксr s

.

Позволять  Vs( t ) ? V

 представляют собой набор виртуальных машин, работающих на s -сервере в момент времени t , и пусть  br v( t ) обозначаем объем r -ресурса, занимаемый v -VM в момент времени t . Общий объем r -ресурса, занимаемого всеми виртуальными машинами на s -сервере в момент времени t, определяется выражением

cr s( t ) =?v ?Vs( t )br v( t ) ,r ? R,s ? S,

а использование r -ресурса на s -сервере в момент времени t можно определить как

ur s( t ) =C0r s+cr s( t )CМаксr s,r ? R,s ? S.

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

3.2. Моделирование перегруженного сервера

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

Мы считаем s -сервер перегруженным в момент времени t , если для всех ресурсов выполняется неравенство  r ? R

:

ur s( t ) >UМаксr? r ? R.

Тогда сервер считается перегруженным в будущем.  t + 1 , … , t + n если для всех  i = 1 , … , n и для всех ресурсов имеет место следующее неравенство:

urs(t+i)>Umaxr?r?R,?i=1,?,n.

Следовательно, набор перегруженных серверов определяется следующим образом:

S?(t)={s?S:urs(t+i)>Umaxr,r?R,i=1,…,n}.

3.3. Критерии выбора сервера при миграции ВМ

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

r?s(t)=argmaxr?Rurs(t),s?S?(t).

Затем мы вычисляем квадрат отклонения коэффициента использования ресурсов от рекомендуемого порога.  Umaxr?s(t):

Ws(t)=W(Vs(t))=(ur?s(t),s(t)-Umaxr?s(t))2,s?S?(t).

Наконец, выбранная виртуальная машина должна удовлетворять следующему уравнению:

v?s(t)=argmaxv?Vs(t)W(Vs(t){v})mv(t),s?S?(t),

где  mv(t)

 — это память, занимаемая v -VM в момент времени t .

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

urs(t)+br,v?s(t)(t)Cmaxrs<=Umaxr?r?R,s?S?(t).

4. Модель массового обслуживания с точки зрения обработки задач

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

4.1. Общие предположения

Мы смещаем акцент с использования и использования ресурсов на серверах на количество задач, обрабатываемых серверами. Будем считать, что задания от пользователей поступают по пуассоновскому процессу с параметром  ?v

 для обработки v -VM. Время обработки задачи подчиняется экспоненциальному распределению со средним значением  ?-1v. Мы рассматриваем только один тип ресурса, обозначаемый как  R=1

. В Таблице 3 мы представляем соответствие между параметрами, используемыми в двух моделях, некоторые из которых будут описаны в следующем подразделе. На рис. 1 представлена схема соответствующей системы массового обслуживания.

4.2. Цепь Маркова с непрерывным временем

Мы описываем динамику системы с помощью цепи Маркова с непрерывным временем (CTMC).  X(t)

 с государствами  x=(n1,…,nk,s1,…,sv), где  n=(n1,…,nV) представляет количество задач, обрабатываемых всеми виртуальными машинами, и  s=(s1,…,sV) указывает назначение сервера для каждой виртуальной машины. Набор состояний CTMC определяется следующим образом:

X={x=(n,s)=(n1,…,nV,s1,…,sV):nv>=0,v=1,…,V,ms(x)=?v=1Vnv·1(sv=s)<=Ms,s=1,…,S}.

Для сценария с двумя серверами и тремя виртуальными машинами набор состояний следующий:

X={x=(n,s)=(n1,n2,n3,s1,s2,s3):nv>=0,v=1,2,3,ms(x)=n1·1(s1=s)+n2·1(s2=s)+n3·1(s3=s)<=Ms,s=1,2}.

Возможные распределения виртуальных машин по серверам следующие:  ??{1,2,3};  {1}?{2,3};  {2}?{1,3};  {3}?{1,2};  {1,2}?{3};  {1,3}?{2};  {2,3}?{1};  {1,2,3}??

.

Принцип миграции ВМ с одного сервера на другой при поступлении задачи показан на рисунке 2 . Как показано, в системе сначала должно быть достаточно места; то есть доступные ресурсы на сервере. Если хотя бы один сервер имеет свободные ресурсы и не перегружен, то задача будет обработана.

4.3. Скорость перехода между государствами CTMC

В Таблице 4 представлены скорости перехода CTMC вместе с их описаниями. Стационарное распределение вероятностей  ?(x)

 рассчитывается с помощью уравнений баланса. Вектор  ev - единичный вектор с 1 в  vth

 место.

4.4. Метрики интереса

Нас интересуют следующие показатели:

• Вероятность блокировки задачи:

  B=B1=B2=?x?B?(x),B={x?X:m1(x)+1>M1,m2(x)+1>M2}.

• Среднее количество задач, обрабатываемых v -VM:

  Nv=?x=(n1,n2,n3,s1,s2,s3)?Xnv?(x),v=1,2,3.

• Среднее количество задач, обрабатываемых на s -сервере:

  Ms=?x=(n1,n2,n3,s1,s2,s3)?Xms(x)?(x),s=1,2.

5. Численные результаты

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

5.1. Рассмотренные сценарии

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

В нашей статье мы рассмотрели случай SaaS, который позволяет пользователям получать доступ к программному обеспечению и использовать его через Интернет без необходимости устанавливать, настраивать и запускать приложение на физическом носителе. Мы рассмотрели стриминговые сервисы в игровом сегменте в связи с растущей тенденцией к облачным играм. Здесь применяется тот же принцип: SaaS позволяет игрокам получать доступ к широкому спектру онлайн-игр на разных устройствах. Существует множество примеров типовых приложений, например, все сервисы Google: пользователям достаточно создать учетную запись Google, чтобы получить полный доступ к сервисам; приложения для дизайнеров, такие как Figma, позволяющие нескольким людям вместе работать над одним проектом в режиме реального времени, при этом все файлы хранятся в облаке; и CRM-системы (управление взаимоотношениями с клиентами), например, «Insightly» — онлайн-программное обеспечение CRM и управления проектами для малого и среднего бизнеса, или «Salesforce», платформа, которая выполняет широкие функции CRM, такие как управление потенциальными клиентами, управление возможностями, и поддержка клиентов.

Мы исследуем влияние скорости поступления задач и средней продолжительности задач на такие показатели производительности, как вероятность блокировки, среднее количество задач в процессе по v -VM и среднее количество задач на s -сервере. Для нашего системного анализа мы определяем  V=3

 и  S=2. Численный анализ концентрируется на изучении взаимосвязей между скоростью поступления задач на серверы и скоростью их обработки ( ? и  ?

, соответственно).

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

5.2. Влияние скорости поступления задач

В исходном случае, сценарий 1А,  ?

 Параметр сильно варьируется, что отражает возможность быстрых колебаний количества активных пользователей игровых сервисов. Мы предполагаем одинаковую скорость поступления задач на все виртуальные машины, устанавливая  ?=?1=?2=?3=0.001,…,10

, при среднем времени обработки задачи 1 час.

Нашей первой точкой анализа является вероятность блокировки. Мы рассматриваем сценарий, в котором максимальное количество одновременных задач на всех виртуальных машинах на обоих серверах колеблется в пределах 25–30. Как показано на рисунке 3а , вероятность блокировки запросов возрастает с увеличением притока задач. Первоначально наблюдается незначительный рост вдоль оси X, но впоследствии вероятность достигает максимума при  M=25

. Что касается среднего количества задач на ВМ и сервер ( рис. 3 б,в), то мы наблюдаем линейный рост в обоих случаях.

Сценарий 1B исследует изменения в скорости поступления задач путем введения k -параметра в качестве множителя. Результирующие ставки определяются как  ?1=k2k2+k+1·?

,  ?2=kk2+k+1·?, и  ?3=1k2+k+1·?, где k варьируется от  0.1,0.2,…,0.9,1,2,…,10. В этом случае мы исправим  ?=10 и  ?=0.5

, что соответствует времени обработки 30 мин.

Рисунок 4а показывает интригующий результат: несмотря на рост входящего трафика, вероятность блокировки остается постоянной для разных мощностей M. Мы начнем с рассмотрения среднего количества задач на одну виртуальную машину ( рис. 4 б), отметив различия между виртуальными машинами. Более того, 1-VM и 2-VM демонстрируют схожие тенденции, вероятно, из-за работы алгоритма миграции. Первоначально 3-VM справляется с большинством задач до того, как произойдет перераспределение. В  k=1

, все три линии пересекаются, показывая одинаковое среднее количество задач. Среднее количество задач на 1 и 2 серверах одинаково за счет равного максимально допустимого количества задач, обрабатываемых на серверах ( рис. 4 в).

5.3. Влияние средней продолжительности задачи

Во втором сценарии, обозначенном 2А, мы поддерживаем постоянную скорость поступления задач на уровне  ?=30

 задач в час, чтобы оценить влияние изменения средней длительности задач на показатели производительности системы. Тарифы на услуги, обозначаемые  ?1=?2=?3

, одинаково настраиваются на всех виртуальных машинах и варьируются от 1/6 до 4, что указывает на скорость обработки задач.

Рисунок 5а иллюстрирует вероятность блокировки как функцию скорости обслуживания.  ?

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

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

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

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

В сценарии 2B мы исследуем, как система реагирует, когда средняя продолжительность задачи модулируется коэффициентом масштабирования k , что приводит к разным скоростям обслуживания между виртуальными машинами. Устанавливаем базовую стоимость услуг  ?=560

 ч, что эквивалентно 5 минутам на задачу, при этом тарифы на обслуживание для конкретной виртуальной машины определяются как  ?1=?2·2k,  ?2=?3·k, и  ?3=?

. Коэффициент масштабирования k варьируется от 0,1 до 10, обеспечивая для анализа широкий диапазон различий в скорости обслуживания.

На рисунке 6а показано заметное уменьшение вероятности блокировки при увеличении масштабного коэффициента k . Эта тенденция сохраняется независимо от мощности виртуальной машины и варьируется от M от 25 до 30, что указывает на то, что более высокая скорость обработки увеличивает способность системы управлять входящими задачами, тем самым уменьшая вероятность блокировки задач.

На рисунке 6b показано среднее количество задач на виртуальную машину. Более того, 1-VM имеет самую высокую скорость обслуживания благодаря  2k

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

На рис. 6c показано среднее количество задач на обоих серверах. В соответствии с данными VM, при повышении k наблюдается значительное снижение количества задач . Сервер, подключенный к 1-VM, который может похвастаться самой высокой скоростью обслуживания, первоначально демонстрирует более быстрое снижение, которое в конечном итоге стабилизируется. 2-сервер демонстрирует аналогичную, хотя и менее выраженную, нисходящую траекторию, отражающую влияние коэффициента масштабирования на продолжительность обработки задачи и связанную с ней скорость обслуживания.

Этот анализ подчеркивает решающее влияние продолжительности обработки задач на распределение ресурсов и общую пропускную способность системы. Управляя скоростью обслуживания с помощью параметра k , мы можем эмулировать результаты реализации стратегий определения приоритетов задач и оптимизации ресурсов в виртуальной среде. Исследование показывает, что динамическое регулирование скорости обслуживания в ответ на изменяющиеся условия рабочей нагрузки может привести к существенному повышению производительности системы.

5.4. Обсуждение

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

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

 приведет к увеличению затрат на электроэнергию; поэтому мы стремимся оптимизировать максимальное количество задач, которые разрешено обрабатывать на виртуальных машинах. Для анализа предложенной модели мы рассмотрели различные схемы обслуживания, варьируя максимально допустимое количество задач, скорость поступления и скорость обработки. Мы рассмотрели четыре случая: (i) скорость поступления от всех пользователей одинакова, (ii) скорость поступления изменяется пропорционально среди пользователей, в то время как общая скорость поступления остается постоянной, (iii) существует равная скорость обработки при постоянной скорости поступления. , (iv) скорость обработки пропорционально масштабируется при постоянной скорости поступления.

Вводя различные ограничения на вероятность блокировки, мы можем определить оптимальное количество M. Судя по рисунку 3а , мы можем поддерживать вероятность блокировки  10-2

 и  M=25 для значений  ?=0...7. Увеличение M до 30 позволило бы нам предоставлять услуги со скоростью поступления  ?=0...9. На рисунке 5а линии для разных значений М расположены достаточно близко. Кроме того, среднее количество задач на сервере за  ?=2

 равно 10. Это говорит о том, что количество активных серверов в данном случае можно уменьшить.

Еще одним критическим фактором для поставщиков услуг является загрузка серверов. На рисунке 3а , когда  ?=8

 и  M=25, среднее количество задач для обоих серверов равно 4, а вероятность блокировки — 0,015. Чтобы увеличить среднее количество задач для серверов, нам потребуется поднять  ?=10

, что приводит к резкому увеличению значения вероятности блокировки почти вдвое до 0,03.

Случай 2B, как показано на рисунке 6c , дает представление о поведении задач на трех виртуальных машинах при разных значениях коэффициента масштабирования k , выявляя две различные закономерности. Есть несколько интересных моментов, касающихся среднего количества задач. Мы наблюдаем 15 задач на ВМ1 и ВМ3 один раз и 25 задач на ВМ1 и ВМ2 дважды. Более того, наклон кривых вероятности блокировки быстро меняется при точных значениях k . Кроме того, среднее количество задач на обоих серверах демонстрирует одинаковое поведение в одном и том же диапазоне k . Благодаря этому анализу мы можем предсказать, как различные скорости обработки влияют на производительность системы в начале процедуры миграции.

6. Выводы

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

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

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

Вклад автора

Концептуализация, администрирование проектов, авторский надзор, методология, ИК; написание-рецензирование и редактирование, ИК и АГ; формальный анализ, расследование, АК, АС и ИК; программное обеспечение, валидация, визуализация, написание — первоначальный вариант, АК и АС. Все авторы прочитали и согласились с опубликованной версией рукописи.

Финансирование

Публикация выполнена при частичной поддержке Системы грантов научных проектов РУДН. 025319-2-000.

Заявление о доступности данных

В этом исследовании не было создано или проанализировано никаких новых данных. Совместное использование данных не применимо к этой статье.

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

Исследования проводились с использованием инфраструктуры Центра коллективного пользования «Высокопроизводительные вычисления и большие данные» (ЦКП «Информатика») Федерального исследовательского центра «Информатика и управление» Российской академии наук.

Конфликт интересов

Авторы заявляют никакого конфликта интересов.

Сокращения

В данной рукописи использованы следующие сокращения:

ИИ	искусственный интеллект
Процессор	центральное процессорное устройство
КТМС	цепь Маркова с непрерывным временем
IaaS	инфраструктура как услуга
ПааС	платформа как услуга
качество обслуживания	качество обслуживания
БАРАН	Оперативная память
RR	по-круговой
SaaS	программное обеспечение как сервис
Соглашение об уровне обслуживания	соглашение об уровне обслуживания
ВМ	виртуальная машина
ВРР	взвешенный циклический алгоритм

Источник: www-mdpi-com.translate.goog

Комментарии: