Анализ производительности облачных приложений с помощью сетей массового обслуживания
Облачные сервисы предоставляют пользователям разнообразные услуги, такие как предложение программного обеспечения, платформ и инфраструктуры для различных задач бизнеса. При выборе архитектуры для приложений, размещаемых на облачных платформах, важно учитывать специфику задач, которые компания планирует решить с их помощью. Для различных видов бизнес‑задач требуются разные архитектуры облачных приложений. Например, для выполнения ресурсоемких вычислительных задач, таких как имитационное моделирование и обработка больших объемов числовых данных используют архитектуру «Большие вычисления», позволяющую реализовать использование вычислительной мощности тысячи ядер. Для относительно простых задач, которые могут быть требовательны к вычислительным ресурсам, используют тип архитектуры «Веб‑интерфейс — очередь — рабочая роль». Для обычных бизнес‑приложений, не требующих частых обновлений, подходит N‑уровневая архитектура с горизонтальными уровнями, разделенными подсетью.
Центры обработки данных, в которых размещаются службы облачных вычислений, часто имеют неоднородные среды с серверами разных поколений и аппаратными конфигурациями. Неоднородность облачных платформ непосредственно влияет на общую производительность центра обработки данных. Колебания рабочей нагрузки являются обычным явлением в средах облачных вычислений, что затрудняет точное прогнозирование рабочей нагрузки. Современные облачные приложения переходят к сервис‑ориентированной архитектуре, развертывая автономные сервисы вместо монолитных модулей. Ключевая особенность облачной архитектуры — масштабируемость, позволяющая динамически выделять и извлекать ресурсы в зависимости от требований рабочей нагрузки. Однако колебания рабочей нагрузки могут повлиять на качество обслуживания, предоставляемого пользователям. Качество обслуживания определяется соглашениями об уровне обслуживания между клиентами и поставщиками облачных услуг и оценивается с использованием системных показателей, таких как время отклика, задержка, средние значения рабочей нагрузки и количество отказов в обслуживании. Анализ качества обслуживания в облачных вычислениях часто включает в себя теорию массового обслуживания для имитационного моделирования и анализа. Поскольку архитектуры облачных приложений становятся более сложными, моделей одной очереди может быть недостаточно, что приводит к принятию моделей систем массового обслуживания с конечным числом узлов для уровней многосерверных приложений или систем массового обслуживания для отдельных уровней. Очень важно обращать внимание на различия в скорости и возможностях центрального процессора в разных облачных виртуальных машинах. В настоящее время теория массового обслуживания широко используется при моделировании облачных сервисов, но большинство исследований всё ещё преимущественно касаются однородных характеристик, игнорируя сложности, связанные с неоднородностью облачных инфраструктур.
Рассмотрим облачный сервис типа «Инфраструктура как услуга», предоставляющий компании вычислительные ресурсы для различных задач бизнеса прямо из облака. В рамках данной услуги клиент получает в аренду виртуальные сервера, сетевую инфраструктуру, защиту канала связи, балансировщик нагрузки и доступ к панели администратора, с помощью которой можно управлять доступом и правами пользователей, а также масштабировать мощности, например, изменять объем облачного хранилища.
Архитектура системы обслуживания облачной инфраструктуры
Рисунок 1 — Архитектура системы обслуживания облачной инфраструктуры
Ресурсы виртуализации предоставляются в виде виртуальных машин, различающихся по технических характеристикам, таким как производительность процессора, объём памяти и интенсивность обработки запросов. Приложение в облаке можно развернуть на кластере неоднородных виртуальных машин. Клиенты могут выбирать виртуальные машины в соответствии с решаемыми ими задачами бизнеса. Поставщики услуг часто стремятся улучшить качество обслуживания предоставляемых услуг. Отслеживание ключевых показателей производительности, таких как время отклика, среднее количество запросов и пропускная способность, позволяет выявить узкие места и определить оптимальное количество виртуальных машин, выделенных для приложений. Центр обработки данных, предоставляющий услуги облачных вычислений, имеет неоднородную среду, поскольку содержит серверы нескольких поколений с разными конфигурациями оборудования, размером и скоростью процессора. Эти серверы добавляются в дата‑центр постепенно и предназначены для замены уже имеющихся машин. Неоднородность серверных платформ влияет на производительность центра обработки данных. Колебания рабочей нагрузки часто происходят в среде облачных вычислений. Это влияет на качество обслуживания, даже несмотря на то, что архитектура масштабируема — возможность динамического распределения и извлечения ресурсов в зависимости от текущих требований рабочей нагрузки. Мониторинг производительности отвечает за принятие решений контроллера доступа и политики динамического предоставления ресурсов, что обеспечивает отказоустойчивость при поломке виртуальных машин. Информация, полученная на этапе мониторинга производительности, используется для анализа, планирования будущих требований к используемой мощности и подготовки к необходимым инструкциям в случае необходимости корректировки предоставляемых ресурсов. На каждой виртуальной машине кластера, использующейся в приложении, установлен локальный агент, запрашивающий текущие параметры производительности, такие как загрузка центрального процессора и объем свободной памяти. Если виртуальная машина достигает критического уровня по отслеживаемым параметрам, то она исключается из распределения ресурсов пока соответствующие параметры не придут в норму.
Многоуровневая архитектура облачного приложения
Рассмотрим многоуровневую архитектуру облачного приложения, развернутого на кластере виртуальных машин. Такая архитектура схематично представлена на рисунке 2 и 3.
Рисунок 2 — Схема трехуровневого облачного приложения
Схема трехуровневого облачного приложенияСтандартная архитектура N‑уровневого облачного приложения состоит из трех обобщенных уровней: внешнего, логического и уровня хранения данных. На самом деле, логический уровень может состоять из нескольких физических или логических уровней в зависимости от решаемых задач бизнеса. Для каждого логического уровня входными данными результаты обработки на предыдущем уровне. Переходы возможны только на иерархично нижестоящие уровни. Архитектура данного приложения является гибкой. Виртуальные машины могут иметь разную интенсивность обработки, измеряемую в единицах в секунду. Интенсивность обработки запросов зависит от технических характеристик виртуальной машины, таких как производительность процессора и память. Запросы, поступающие в первый логический уровень, представляющих из себя балансировщик нагрузки, могут исходить как от фактического пользователя, так и от другого веб‑приложения. Время выполнения запроса может варьироваться от миллисекунд до минут. Балансировщик нагрузки принимает на себя все входящие запросы и распределяет их между виртуальными машинами логического уровня используя различные алгоритмы, учитывающие различную интенсивность обработки в узлах, загрузку каждого из узлов и выход из строя виртуальных машин. Балансировщик нагрузкой владеет актуальной информацией об активных в данный момент виртуальных машинах и имеет возможность прекратить направление трафика на поломанную виртуальную машину, распределяя входящий трафик между остальными узлами логического уровня. Как только виртуальная машина снова будет работать, балансировщик нагрузки начнёт использоваться её. В приложении могут использовать различные политики балансировки, например, случайное распределение, наименьшее количество распределений и циклический перебор (алгоритм балансировки «Карусель»). Когда кластер состоит из виртуальных машин различных мощностей, то политика распределения рабочей нагрузки должна учитывать интенсивность обработки в узлах.
Рисунок 3 — Схема трехуровневого облачного приложения
Алгоритм балансировки «Карусель»
Рисунок 4 — Схема алгоритма планировщика ресурсов «Карусель»
В отличие от других алгоритмов планирования ресурсов, которые просто ставят процессы в очередь и исполняют их никаким образом не меняя состояние исполняемого процесса, алгоритм балансировки «Карусель» имеет возможность вытеснения. Это значит, что планировщик может взять процесс, находящийся на исполнении, и поставить его обратно в очередь, то есть поменять состояние процесса «выполняется» на состояние «ожидает выполнения». Планировщик «Карусель» включается определенное количество тактов, и если процесс выполняется и он ещё не перешёл в состояние ожидания или в состояние завершения, тогда он ставит этот процесс обратно в состояние готовности и выполняет следующий процесс. Схема работы данного алгоритма приведена на рисунке 4.
Сеть массового обслуживания, описывающая работу трехуровневого облачного приложения
Рисунок 5 — Сеть массового обслуживания, описывающая работу трехуровневого облачного приложения
Приложение трехуровневое. Первый уровень состоит из одной виртуальной машины, выполняющей роль балансировщика нагрузки. Балансировщик нагрузки с помощью специального алгоритма распределяет входящий трафик между пятью виртуальными машинами, находящимися на втором уровне. Балансировщик нагрузки играет важную роль в обеспечении эффективности работы приложения Второй уровень состоит из пяти виртуальных машин и представляет из себя различные бизнес‑процессы, являющиеся реализацией логики и функциональности приложения. Использование нескольких виртуальных машин обеспечивает отказоустойчивость в случае поломки одного из узлов бизнес‑уровня. Третий уровень — хранилище данных, в данной работе представлен в виде реплицированной базы данных.
Каждый из узлов моделируют работу виртуальной машины, поднятой на облачном сервере. Виртуальные машины соединены в кластер. Заявки могут обрабатываться на и покидать систему на втором и третьем уровне, сообщение между первым и третьим уровнем без второго уровня исключено. Каждый узел представляет из себя систему массового обслуживания M/M/1 с пуассоновским входным потоком, показательным временем обслуживания и неограниченной очередью ожидания. Вероятность перехода из состояния i в состояние i — 1 процесса (t), представляющего из себя количество заявок, находящихся в системе в момент времени t, для i >= 1 определяется по формуле:
Переход из из состояния i в состояние i — 1 означает, что количество поступивших заявок за время на 1 меньше, чем количество обработанных заявок за это же время. Вероятность перехода из состояния i в состояние i + 1 определяется по формуле:
Вероятность остаться в состоянии i равна:
Геометрическое распределение количества находящихся в системе заявок определяется загрузкой системы:
Зная производящую функцию P (z) можно определить среднее число заявок в системе, которое определяется как математическое ожидание процесса:
C помощью rij описаны вероятности переходов из узла i в узел j. Заявка, поступающая в узел j из узла i начинает обрабатываться сразу. Заяка, обслуженная в узле j, сразу после завершения обслуживания и независимо от других заявок, направляется в узел j+1 с вероятностью pj, j+1. Для удобства описания вероятностей заявок, покинувших систему, вводится нулевой узел, поэтому вероятность того, что заявка обслужится в узле j и покинет систему, то есть попадет в нулевой узел, равна pj0.
Рисунок 6 — СеМО облачного приложения
Для удобства описания вероятностей переходов вводятся стохастические матрицы размерности N+1 на N+1, где N — количество узлов в системе массового обслуживания с конечным числом узлов. Стохастическая матрица переходов обслуженных заявок записывается так:
Соотношения для веротностей переходов:
Среднее количество запросов, находящихся в очереди i‑го узла, который представляет из себя систему M/M/1 с пуассоновским входным потоком и экспоненциальным временем обслуживания вычисляется по формуле:
Общее количество запросов, поступивших в систему на обслуживания, но находящихся в ожидании:
Среднее время обслуживания запроса в i‑ой очереди i‑ой виртуальной машины рассчитывается по формуле:
Общее среднее время обслуживания в системе не может быть равно сумме средних значений времени обслуживания в узла.
Результаты имитационного моделирования
Производительность процессора измеряется в количестве инструкций, обрабатываемых в секунду. Аббревиатура MIPS расшифровывается как «Million Instructions Per Second» и обозначает меру быстродействия, измеряемую количеством инструкций, обрабатываемым процессором за 10^-3 секунды.
В предложенной системе массового обслуживания каждый узел имеет различную интенсивность обработки поступающих запросов. В таблице 1 приведены интенсивности обслуживания в i‑ой виртуальной машине.
Таблица 1. Интенсивность обслуживания заявок в узлах системы
Таблица 1. Интенсивность обслуживания заявок в узлах системы:
В таблице 2 представлено одно из возможных, рассматриваемых в эксперименте, значений интенсивности поступления заявок в каждый узел:
Таблица 2. Интенсивность поступления заявок в i‑ый узел
Используя интенсивность входящего потока в узел и интенсивность обслуживания в узле можно определить процент загруженности узла (см. таблицу 3), представляющего виртуальную машину. Это очень важный показатель, используемый при планировании использования ресурсов.
Таблица 3. Вычисление вероятности состояния i‑ого узла
Используя все вычисленные ранее значения можно рассчитать самый важный для анализа производительности параметр — время ожидания заявки в системе. Будем учитывать факт того, что одна из виртуальных машин логического уровня может выйти из строя на некоторое время. Вычисленные значения для переменной интенсивности поступления заявок от 160 до 250 единиц в мс представлены в таблице 4.
Таблица 4. Время ожидания заявки в i‑ой очереди
На основе полученных данных построим график (см. рис. 7), который будет иллюстрировать разброс времени ожидания заявки в очереди для каждого узла в системе, состоящей из семи узлов с пуассоновским входящим процессом и экспоненциально распределенным временем обслуживания. Рассчитаем общее время пребывания заявки в системе для различных значений входящего потока (см. рис. 8).
Рисунок 7 — Время ожидания заявки в очереди в i‑ом узле
Рисунок 8 — Изменение времени пребывания заявки в системе с увеличением интенсивности поступления заявок
Список литературы
1. Chien Nguyen Khac, Khiet Bui Thanh, Hung Ho Dac, Son Nguyen Hong Vu Pham Tran, Hung Tran Cong An open Jackson Network Model for Heterogeneous Infrastructure as a Service on Cloud Computing. — International Journal of Computer Network and Communications, 2019. — v. 11, p. 63–67.
2. Chiang, Yi‑Ju and Ouyang, Yen‑Chieh Profit optimization in SLA‑aware cloud services with a finite capacity queuing model. — Mathematical Problems in Engineering, 2014. — p. 1 — 11.
3. H. Khazaei, J. Misic, V.B. Misic Performance analysis of cloud computing centers using m/g/m/m+ r queuing systems. — IEEE Transactions on parallel and distributed systems, 2012. — v. 23, p. 936–943.
4. Vilaplana, Jordi, et al. A queuing theory model for cloud computing. — The Journal of Supercomputing, 2014. — v. 69, p. 492–507.
5. Бутов А. А., Савинов Ю.Г. Теория массового обслуживания: учебно‑методическое пособие. Ульяновск: УлГУ, 2007. с. 36–37.
6. Малинский Ю.В. Сети Джексона с однолинейными узлами и ограниченным временем пребывания или ожидания. — Автомат. и телемех. 2015. — в. 4, с. 67–79.
Habrahabr.ru прочитано 1378 раз
