Итак, вы “дозрели” до 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
