ЛЕНТА НОВОСТЕЙ

24 марта

17 марта

16 марта

15 марта

14 марта

10 марта

09 марта

07 марта

02 марта

Для клиентов ЦОД / Полезные советы / Тест-драйв облака: зачем он вам и как это делать

Тест-драйв облака: зачем он вам и как это делать

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

 

Регистрация
 
Каталог ЦОД | Инженерия ЦОД | Клиентам ЦОД | Новости рынка ЦОД | Вендоры | Контакты | О проекте | Реклама
©2015 «AllDC.RU Новости отрасли ЦОД, инженерных систем дата-центра, каталоги ЦОД и производителей оборудования для datacenters»