Тестування продуктивності хмарних інфраструктур

Як правильно випробувати хмару перед розміщенням інфраструктури? У цій статті ми розповідаємо про основні складнощі під час тестування хмари та розглядаємо, які інструменти ефективні, а які – ні.

Які проблеми виникають під час тестування хмари?

Обираючи хмару для розміщення інфраструктури, користувачі часто просять тест-драйв, щоб оцінити зручність роботи і продуктивність ресурсів. Багато, навіть досвідчених фахівців представляють процес тестування спрощено, тому обмежуються запуском набору синтетичних чи робочих тестів. Подібні випробування використовуються для настільних комп'ютерів. На практиці, у таких дослідників виникають складності через відносну новизну хмарних технологій та відмінності віртуальних машин від «залізних» серверів. Навіть у IT-фахівців зі стажем часто не вистачає знань та досвіду тестування хмарних ресурсів, а загальноприйнятих стандартів не існує.

Ось у чому головна причина: продуктивність класичної програмної системи оцінюють за певного робочого навантаження для фіксованої конфігурації. Але забезпечити стабільне навантаження та конфігурацію ресурсів у громадській хмарі не вдасться. Щоб адаптуватися до мінливих умов орендарів, провайдери автоматично виділяють та звільняють ресурси «на льоту».

Замість того, щоб вимірювати середню продуктивність статичної системи при максимальному навантаженні, логічніше оцінити інші характеристики. Наприклад, здатність хмарних сервісів адаптуватися до змінних навантажень з погляду продуктивності та витрат. Додаткова метрика повинна охоплювати надійність цих сервісів при збоях окремих вузлів, а також повному відключенні ЦОД.

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

• з різними можливостями;
• з різними гарантіями;
• зі своїми параметрами сервісу, прописаними у договорі SLA.

Як то кажуть, доводиться порівнювати яблука з апельсинами.

Про що важливо пам'ятати до початку тестування:

• технології розподілених обчислень швидко розвивається та існує безліч несумісних реалізацій;
• ринок хмарних IaaS молодий і на стадії розробок, експериментів;
• у користувача немає безпосереднього контакту з обладнанням, тому він взаємодіє з орендованими ресурсами віддалено, через веб-інтерфейс;
• професійні пакети програмного забезпечення для тестування коштують чималих грошей

Чи можна застосувати "залізні" тести до хмари?

Для оцінки продуктивності настільного комп'ютера використовують кілька наборів тестів - окремо центрального та графічного процесорів, оперативної та дискової пам'яті, мережевих адаптерів. Результати випробувань новітніх процесорів та відеокарт стають об'єктами дискусій в інтернеті. Скепсис, який викликають такі тести, цілком обґрунтований.

Устаткування часто переводять у режим, який не використовується для щоденної роботи, щоб отримати рекордні результати. Перед тестуванням нерідко виконуються «розгони» процесорів та пам'яті з організацією додаткового охолодження, ризиковані експерименти з тонкими налаштуваннями BIOS, бета-версіями драйверів пристроїв тощо. Можливо, отримані цифри потішать переможців, але вони навряд чи зможуть стабільно працювати й надалі з такими налаштуваннями обладнання та ПЗ. Щодо віртуального середовища, там «розгін» компонентів неможливий.

Принцип роботи ВМ суттєво відрізняється від звичного для користувачів фізичного обладнання. Якщо процесорне ядро фізичного комп'ютера однозначно локалізується на кристалі CPU, то IaaS – це імітація квоти, виділеної із загальної потужності хмари. Ця віртуальна квота створюється за допомогою гіпервізора. Кожному користувачеві надають замовлений обсяг ресурсів, але реальний стан та статус хмарної інфраструктури постійно змінюється:

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

Відмінності в структурі фізичного CPU та віртуальної машини

Таким чином, є висока ймовірність того, що при повторних запусках одного і того ж тесту в різний час результати не будуть ідентичними.

Відповісти на питання про застосування тестів для фізичного обладнання до хмарних інфраструктур можна так: застосовувати «залізні» тести до хмари можна - але практична користь від цього невелика.

Як випробувати хмарні інфраструктури?

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

Тестування продуктивності окремих підсистем (процесорів, пам'яті, дисків) для всебічної оцінки хмари явно недостатньо, на відміну від подібних тестів настільних комп'ютерів. Але для найпершої перевірки працездатності 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.

На закінчення

Для тестування хмари варто використовувати спеціалізовані тести, а не застосовувати «залізні» через суттєві відмінності в принципах їхньої роботи. Найкращий спосіб оцінити можливості хмарної інфраструктури – використовувати тести, що симулюють реальну роботу систем. Більше того, недостатньо оцінити продуктивність компонентів. На ефективність роботи у хмарі впливають інші фактори, які не оцінити за допомогою апаратного тестування. Серед таких факторів – час відповіді підтримки провайдера, стійкість до відмов, захист даних і т.п.

Готуючись до тестування, обговоріть це з техпідтримкою провайдера. Так, ви отримаєте кваліфіковану консультацію заздалегідь, зможете уникнути непорозумінь через несумісність апаратних ресурсів або системи віртуалізації провайдера з обраним для проекту пакетом тестового програмного забезпечення.

Сподобалася стаття?