Разработка универсального теста производительности для облачных вычислений
В. В. Самыкин, М. А. Макаров, А. М. Сухов
Самарский государственный аэрокосмический университет
Облачные вычисления являются перспективной технологией, позволяющей централизовать управление вычислительными ресурсами и оптимизировать их потребление по сравнению с традиционными схемами. Но в этом случае на первый план выступают такие проблемы, как производительность самих виртуальных сред и ограничения пропускной способности сети. В настоящее время широко используются специальные протоколы доступа к виртуальным рабочим местам, находящимся в «облаке» [1]. Это RDP (Remote Desktop Protocol), PCoIP (PC over IP Protocol), RGS и другие. Как показывают исследования, их использование может дать преимущество при выполнении конкретного сценария клиента. Однако тесты производительности протоколов VD проводят, обычно, с применением распространённых офисных, Интернет приложений и средств мультимедиа.
Поэтому встает вопрос: как измерить производительность и оценить нагрузку на компоненты «облачной» инфраструктуры в условиях выполнения тестовых задач, потребляющих значительные ресурсы системы? В настоящее время не существует универсальной методики тестирования производительности облачных приложений. В то же время устоявшиеся области вычислительных приложений, например, системы высокопроизводительных вычислений, тестируются на основе единых правил. Существует HPC Challenge Benchmark, набор тестов по производительности, который и служит платформой для сравнений таких систем. И хотя тест LINPACK, который лежит в основе системы, имеет ряд недостатков, тем не менее, преимущества универсального подхода налицо.
Цель данной работы – выработать методику тестирования облачных протоколов, разработать обобщенный критерий для их оценки, реализовать программно метод тестирования на основе реальной прикладной задачи. Основные критерии, по которым должно производиться сравнение – это производительность серверного процессора, размер оперативной памяти на сервере и пропускная способность канала связи. Соответственно, тест должен производить измерения загрузки ЦПУ, ОЗУ и передаваемого по каналу связи трафика.
Исследование Calyam [2] показало, что производительность протоколов различается для разных типов обрабатываемых данных. Для объективной оценки требуется получить комплексный критерий, который однозначно оценивал бы производительность протокола, а реализующая его программа выступала в качестве теста производительности (бенчмарка).
Обработка больших массивов данных табличным процессором хорошо зарекомендовала себя в нагрузке ресурсов, Calyam [2]. Поэтому в качестве языка для написания тестового ПО был выбран MS Visual Basic, а в качестве теста - работа с табличными данными в табличном процессоре MS Excel. Подобные действия сильно нагружают ЦПУ (до 100%) и занимают большие объемы ОЗУ. Кроме того, передача больших таблиц по сети обеспечивает большой трафик.
Введем описание основных компонентов тестовой системы.
Прикладная задача – сжатие изображений по алгоритму JPEG [3].
Входная функция – матрица исходного изображения несжатого формата.
Основной алгоритм – дискретное косинусное преобразование (ДКП).
Выходная функция – результирующий поток байт на окончательное сжатие.
Критерий оценки – комплексный критерий, позволяющий судить о производительности системы.
Для исследования поведения протоколов облачных вычислений в реальных условиях была использована специально подготовленная площадка для экспериментов. Она включает в себя сервера VMware vSphere, VMware View (Connection Broker), Quest Software vWorkspace (Connection Broker), два ESX-сервера (Гипервизоры).
За первоначальный критерий оценки скорости выполнения теста было принято время выполнения основных этапов тестового приложения на виртуальной машине в облаке на стороне сервера.
Анализируя структуру данного критерия, приходим к выводу, что главной компонентой является время видео вывода (его вклад 66…90%). Режим работы, когда видео вывод передается непрерывно на сторону клиента, назовем «тяжелым» режимом, при ограничениях получим «легкий» режим. Для «тяжёлых» сценариев полная нагрузка процессора сочетается со значительной нагрузкой на сеть.
Рис. 1 – Общее время выполнения теста: набор данных
На «лёгких» режимах все протоколы практически одинаковы, но если посмотреть на временные компоненты для «тяжёлых» режимов, то разница становится все более очевидной по мере роста нагрузки. На Рис. 1 приведены результаты измерений общего времени выполнения тестовой задачи для «тяжелых» режимов.
Как видно из Рис. 1, значительное преимущество по времени выполнения теста имеет протокол PCoIP – 208c против 383c и 630c у протоколов RDP Quest и RDP WmWare соответственно.
Рассмотрим время отработки основных циклов программы, основой которой является DCT-преобразование. Как видно из Рис. 2, эта компонента комплексного критерия примерно одинакова для всех протоколов (разница колеблется в пределах 8%).
Рис. 2 – Время выполнения основных циклов преобразования.
На Рис. 3 показан график объёма переданных данных для различных наборов данных.
Рис. 3 – Объём переданных данных (upload) из ВМ в консоль клиента, Мб
По скорости выполнения операций ввода-вывода несомненным лидером также является протокол PCoIP – 47,6кБ/с при обсчёте матрицы коэффициентов размером 48kB.
Говоря о загрузке ЦПУ, следует отметить, что во время передачи данных на тонкий клиент загрузка процессора становиться скачкообразной у протоколов семейства RDP, в то время как у PCoIP этого не происходит. Таким образом, у протокола PCoIP процессорные ресурсы при передаче используются наиболее эффективно.
Для оценки производительности протоколов удобно применять представление данных в виде диаграмм производительности (Рис. 4) [2].
Рис. 4 – Диаграмма производительности протоколов VDI
Для наглядности за 100% скорости сетевого трафика диаграммы выбрана скорость передачи данных 400 кбит/с.
Из приведенных диаграмм видно, что такой ресурс, как загрузка процессоров практически полностью (на 97-99%) используется только протоколом PCoIP. У протоколов RDP Quest и RDP WMware среднеинтегральная величина этого показателя составляет 54% и 47% соответственно. Использование ОЗУ различается незначительно для всех протоколов. Дальнейшее увеличение загрузки ОЗУ нецелесообразно ввиду значительного увеличения общего времени прохождения теста. А пропускную способность сети лучше всего использует протокол PCoIP, эффективно организуя передачу данных в прямом и обратном направлениях, что особенно сильно проявляется на тяжелых режимах тестирования.
Обобщенный критерий, по которому оценивались протоколы, показывает, что общее время прохождения теста в большинстве контрольных точек меньше всего у протокола PCoIP. Это даёт основание говорить о его большей производительности для выбранного EXCEL-сценария. Это обусловлено, в первую очередь, более эффективным использованием пропускной способности сети. При этом объём передаваемых данных для PCoIP получается меньше за счёт эффективного сжатия потока, причем это сжатие сбалансировано по входящему и исходящему направлениям.
Исходя из структуры обобщенного критерия, производительность виртуального рабочего места может быть определена из выражения
 (1)
где S – размер исходной матрицы, байт, ki – весовой коэффициент i-ой компонента структуры обобщённого критерия. Для различных сценариев, реализуемых клиентами, весовые коэффициенты могут, вообще говоря, различаться. В рамках данной работы не было возможности определить указанные коэффициенты.
ЗАКЛЮЧЕНИЕ
Время отработки основных циклов преобразования и производительность на стороне сервера для всех протоколов примерно одинаково. Различие в производительности протоколов проявляется, в первую очередь, при загрузке результирующего потока данных на тонкий клиент. А это немаловажно для облачных вычислений. При этом эффективнее всего нагружает CPU (97…99%) при меньшей загрузке RAM протокол PCoIP. Протоколы семейства RDP обнаруживают существенные недостатки. Во-первых, это значительное отставание по обобщенному критерию и другим параметрам производительности на тяжелых режимах тестирования. Во-вторых, скачкообразная загрузка CPU, что является причиной всего лишь половинной загрузки процессоров. В-третьих, невозможность напрямую передать в виртуальную машину локальные устройства, такие как USB Flash, принтеры, сканеры, веб-камеры. А все эти ограничения существенны для конечных пользователей.
СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ
Peter Mell, Timothy Grance, The NIST Definition of Cloud Computing, 2011, http://docs.ismgcorp.com/files/external/Draft-SP-800-145_cloud-definition.pdf
A. Berryman, P. Calyam, A. Lai, and M. Honigford. VDBench: A Benchmarking Toolkit for Thin-client based Virtual Desktop Environments., In Proc. of IEEE CloudCom, 2010
Ватолин Д.С. Алгоритмы сжатия изображений. М.: МГУ, 1999. 76 с.
|
