Тест-драйв облака: зачем он вам и как это делать
 Итак, вы “дозрели” до IaaS, изучили рынок, определились с провайдером облачных услуг и готовы к миграции - ну, или думаете, что готовы, а на самом деле нет. Вот так плавно мы и подошли к вопросу “зачем все это”.
Что же дает тест-драйв (и, строго говоря, тест-драйв only):
1. Прежде всего, это единственный способ узнать наверняка, будут ли ваши приложения в облаке работать (не вообще, а как надо).
2. Заодно вы сможете выявить потенциальные “слабые звенья” и подстраховаться на будущее.
3. По результатам вдумчивого тестирования вы также получите точные метрики производительности - и правильные цифры для SLA.
4. Это хорошая возможность “на берегу” изучить инструменты управления виртуальным ЦОД, оценить их удобство и функциональность, приноровиться и т.д.
5. Скорость создания и восстановления резервных копий ВМ - еще один немаловажный момент, который легко проясняется в рамках тест-драйва.
6. Ну и, конечно, качество работы service desk: согласитесь, проверять достоверность рекламных обещаний лучше до подписания контракта, а не после.
Уговорил? Тогда самое время разобраться, что есть правильный тест-драйв, как к нему подготовиться и куда вообще смотреть.
Начнем с конфигурации тестового пула. По каждому приложению, которое планируется перенести в облако, необходимы четко прописанные требования к производительности.
В случае, когда сервис разворачивается в облаке “с нуля”, к проработке первичного сайзинга при желании можно привлечь провайдера.
Если речь о миграции приложений с “железа”, в качестве отправной точки вполне сгодятся показатели текущей системы:
1. число пользователей и объем данных
2. загрузка основных элементов системы, к коим относятся:
- процессор
- память
- дисковая очередь
- сетевая активность
- 3. взаимосвязи между пунктами один и два.
Ну, а если имеются еще и данные мониторинга за какой-то внятный период, то вообще красота. Дополняем метрики “штатного режима” работы приложения прогнозом на периоды пиковых нагрузок - и отгружаем все это провайдеру в качестве ТЗ на тестовый пул ресурсов. Получив доступ к тестовому облачному стенду, первым делом проверяем, соответствуют ли ТЗ ключевые параметры: количество процессорных ядер, скорость и объем дисковой подсистемы, объем памяти и ширина сетевого канала.
Что именно будем тестировать? Производительность и функциональность облачного ЦОД.
Производительность: на что смотреть и как тестировать?
Приоритетные элементы инфраструктуры, понятно, определяются потребностями приложения, под которое “готовится” облако: если для БД критична работа дисковой подсистемы, то для целого ряда другого ПО важнее процессорная мощность и память в качестве кэша.
При этом есть параметры, легко изменяемые в процессе (память), а есть те, с которыми сложнее: дисковая подсистема, процессор и сеть. И вот с этими последними желательно разобраться уже на старте.
Как проверяется дисковая подсистема: здесь нам важны показатели ввода вывода и задержки (IOPS, Latency), для “замеров” можно использовать Iometer , SQLIO и FIO.
Процессор. При проведении нагрузочных тестов попросите поставщика отдельно указать значения CPU Ready (измеряется в %): это время, которое виртуальный процессор проводит “в очереди” за процессорным временем от физического хоста. CPU Ready выше 10% - гарантия того, что виртуальная машина будет “подтормаживать” в результате хронической нехватки процессорной мощности.
Сеть: здесь смотрим на ширину сетевого канала, стабильность и время отклика. Смотреть удобнее через Iperf&Jperf и ping.
Отдельно проверяем систему резервного копирования, а именно - ее функциональность, плюс скорость создания и восстановления резервных копий.
С производительностью разобрались. Что дальше?
Дальше проверяем функциональность и удобство управления облаком - то есть проясняем для себя, насколько удобно и легко вам будет создавать и удалять виртуальные машины, распределять между ними ресурсы, импортировать и экспортировать “виртуалки”, создавать и хранить шаблоны ВМ, управлять сетью и FireWall, создавать VPN и мониторить потребляемые ресурсы.
* * *
Если результаты тестирования производительности не вполне, так сказать, отражают - предъявляем их провайдеру и совместно решаем, как лучше “лечить” ту или иную проблему. Придумали? Обязательно протестируйте обновленную конфигурацию.
И, конечно, добившись наконец нужных показателей, именно эти цифры и включаем в SLA (Service Level Agreement).
У меня все. Удачного полета!
Эдуард Бавижев,
DataLine, руководитель группы виртуализации
Источник: Дайджест DataLine
|
ЛЕНТА НОВОСТЕЙ
