Тестирование производительности облачных инфраструктур

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

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

Главная причина этого понятна - производительность классической программной системы оценивают при определенной рабочей нагрузке для фиксированной конфигурации. Но обеспечить стабильную нагрузку и конфигурацию ресурсов в публичном облаке не получится в принципе - чтобы динамически адаптироваться к меняющимся условиям арендаторов, поставщики облачных вычислений автоматически выделяют и освобождают ресурсы (вычислительные узлы) «на лету».

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

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

• с различными возможностями;
• с отличающимися гарантиями;
• со своими параметрами сервиса, прописанными в договоре SLA.

Как говорят, приходится сравнивать яблоки с апельсинами.

О чём важно помнить до начала тестирования

• технологии распределенных вычислений быстро развиваются и существует множество несовместимых между собой реализаций;
• рынок облачных IaaS молод и находится на стадии разработок, экспериментов;
• пользователь не имеет непосредственного контакта с оборудованием провайдера и взаимодействует с арендованными ресурсами системы удалённо, через веб-интерфейс;
• профессиональные пакеты ПО для тестирования стоят немалых денег.

Можно ли применить «железные» тесты к облаку?

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

В подобном скепсисе есть смысл, поскольку для получения рекордных результатов оборудование зачастую переводится в режим, далекий от нормального (приемлемого для ежедневной работы). Перед тестированием нередко выполняются «разгоны» процессоров и памяти с организацией дополнительного охлаждения, рискованные эксперименты с тонкими настройками BIOS, бета-версиями драйверов устройств и т.д. Возможно, полученные цифры обрадуют победителей, но смогут ли они стабильно работать и дальше с такими настройками оборудования и ПО? Что касается виртуальных сред, то там «разгон» компонентов невозможен.

Очевидно, что принцип работы ВМ существенно отличается от привычного для пользователей физического, реального оборудования. Если процессорное ядро физического компьютера однозначно локализуется на кристалле CPU, то в IaaS это - организованная гипервизором имитация квоты, выделенной из общей процессорной мощности облака. Несмотря на то, что каждому пользователю провайдер предоставляет заказанный объём ресурсов, реальное состояние и статус облачной инфраструктуры все время изменяется:

• при добавлении и удалении запущенных «инстансов» – абстракций сред выполнения, виртуальных машин;
• после запуска и остановки работающих приложений;
• за счет колебаний пользовательской загрузки;
• во время выполнения бекапов, восстановления данных.

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

Учитывая изложенное выше, ответ на вопрос о применимости тестов для физического оборудования к тестированию облачных инфраструктур представляется таким: применять «железные» тесты к облаку, в принципе, можно - но практическая польза от этого невелика.

Практика и инструменты тестирования облачных инфраструктур

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

Тестирования производительности отдельных подсистем (процессоров, памяти, дисков) для всесторонней оценки облака явно недостаточно (в отличие от подобных тестов настольных компьютеров). Но для самой начальной проверки работоспособности IaaS их все же используют.

Экономическая целесообразность для бизнеса – вот один из главных факторов, которые стимулируют развитие облачных вычислений. А это включает в себя и доступность услуги, и стабильную работу при колебаниях нагрузки, и безопасность в публичном облаке (включая бекап) и многое другое. То, что не всегда оценивается цифрами производительности, но реально очень влияет на комфортное и предсказуемое использование услуги пользователем. Таким образом, при оценке параметров облака не стоит ограничиваться формальным проведением теста с применением даже самого мощного ПО.

Минимальным (и достаточным, в большинстве случаев) сценарием тестирования перед началом работы с облаком, может быть такой перечень:

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

Для профессионального исследования и оценки производительности облачных ресурсов, можно предложить выбор из нескольких альтернативных пакетов тестового ПО:

• SPEC Cloud (TM) IaaS 2016 Benchmark;
• Hewlett Packard Enterprise StormRunner Load;
• LoadStorm;
• SOASTA CloudTest;
• LoadImpact;
• BlazeMeter;
• SmartBear LoadComplete;
• Spirent Blitz;
• SendGrid Loader.

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

В любом случае, необходимо иметь тщательно продуманный план - сценарий подготовки и запуска измерений, сбора и получения результатов (бенчмарок). При этом, используется понятие SUT (System Under Test, система в состоянии тестирования) – набор обязательных компонентов для запуска сценария измерения. Этот набор включает в себя те компоненты облачной инфраструктуры, параметры которых интересуют пользователя и все остальные, без функционала которых нельзя обойтись при тестировании и параметры которых должны быть известны заранее. Кроме того, пакет ПО содержит драйверы, имитирующие рабочую нагрузку для тестируемой инфраструктуры IaaS.

В заключение, кратко о главном (при тестировании публичного облака)

Готовясь к тестированию, обсудите с техподдержкой своего провайдера облачных сервисов намерение запустить тот или иной тест на их ресурсах (оборудовании и ПО). Это позволит вам получить квалифицированную консультацию заранее, избежать недоразумений из-за возможной несовместимости аппаратных ресурсов / системы виртуализации провайдера с выбранным вами для своего проекта пакетом тестового ПО.

LIKE THE ARTICLE? SHARE VIA: