На графике – тесты производительности виртуальных машин пяти крупнейших игроков на рынке IaaS-«облаков» от cloudspectator.com и замер скорости нашего «облака» КРОК по той же методике. Разбивка по дням с 20.06.13 по 29.06.13.
Несмотря на наш приятный высокий результат, выводы данного тестирования показались нам несколько односторонними. Да и сама задача вызвала много споров среди наших коллег: ведь оценить производительность «облака» — вопрос нетривиальный. И мы решили разобраться поглубже.
«Облако» состоит, грубо говоря, из оборудования, которое позволяет этому «облаку» работать, и оборудования на котором запускаются виртуальные машины заказчиков. Производительность самих виртуалок зависит от производительности тех физических серверов, на которых они запущены. Единого стандарта нет: все на рынке предлагают совершенно абстрактные виртуальные процессоры, соответственно, совершенно разные конфигурации этих виртуралок.
Свои технологии, использующиеся для построения «облака», особо никто не раскрывает. Некоторые даже идут на то, что разрабатывают свою собственную архитектуру ЦОД под свое «облако» — но это делают лишь очень большие игроки, например, Amazon. Если вы видели их ЦОДы, то знаете, что они размером с аэродром.
Для начала мы поспрашивали своих коллег и клиентов про то, как и за что они выбирают «облако». Выяснилось, что «одного числа» как такового нет, но сценарий у подавляющего большинства примерно схожий. Для начала заказчик хочет убедиться, что единичная виртуалка достаточно быстрая (то есть что ему предлагают, например, не четверть ядра вместо целого: тут важны процессоры, память и дисковая подсистема). Затем встают сетевые вопросы: (ping до «облака», пропускная способность каналов связи с Интернетом, пропускная способность стыка облако-физика, а также пропускная способность канала между нашими ЦОД-ами).
Для крупного бизнеса главной становится скорость взаимодействия между виртуальными сетями и скорость интерконнектов ЦОДов. Дополнительно появляются вопросы SLA, бекапа как сервиса, безопасности, мониторинга, надёжности ЦОДа и так далее. У нас с этим полный порядок, поэтому основным моментом выбора остаётся производительность. Итак, чтобы адекватно сравнивать себя с остальными «облаками», мы решили не отходить от способа и условий тестирования, предложенных стартапом и начали измерять скорость работы собственных виртуальных машин. И здесь тоже есть нюансы.
Если смотреть на ситуацию глазами заказчика, то результаты таких тестов единичных виртуальных машин могут быть полезны для того, чтобы оценить необходимый размер виртуального сервера, на который можно смигрировать текущие физические сервера.
Суть исходного теста проста: во всех «облаках» берется одинаковый по размеру обычно самый распространенный тип виртуалки (1 vCPU, 4 Гб RAM), на котором в течение какого-то времени запускается одна и та же утилита, производящая замеры производительности. В данном конкретном случае это открытая утилита UnixBench, которая позволяет в численном эквиваленте оценить производительность работы того ядра, который выделен виртуалке, от физического процессора. Ок, отлично, мы сделаем так же.
Примеры конфигураций виртуалок из того же отчёта:
«Накрутки» теста
Учитывая тот факт, что мы хотели получить реальные результаты по нашему «облаку», мы постарались максимально приблизить условия к боевым. Чем отличаются тесты при реальной нагрузке от синтетических, думаю, объяснять не надо.
Для начала встаёт вопрос тюнинга инфраструктуры под тест. Настройками, безусловно, можно «подкрутить» результаты на несколько десятков процентов. Равно как можно и под конкретные задачи определённого заказчика провести тюнинг физической инфрастуктуры облака. Например, зная точно нагрузку на CPU и соотношение операций чтения-записи приложений крупного заказчика, можно изменяя настройки обеспечить большую производительность. Однако, каждый раз, когда стоит выбор между покупкой дополнительных серверов или «тюном» под конкретную задачу, мы выбираем добавление дополнительных серверов. Связано это с тем, что чем больше «облако» – тем больше физического оборудования нужно поддерживать. А поддерживать однотипную инфраструктуру значительно проще. Если увлечься тюнингом, потеряется гибкость и могут пойти сбои. Поэтому для теста никакой оптимизации физических серверов, а также виртуальных машин нами не выполнялось.
Во-вторых, очевидно, нет смысла мерить производительность виртуалки, например в три часа ночи. Поскольку в «облаке» производительность физического сервера делится между всеми заказчиками, виртуалки которого на нем расположены. Ночью все виртуалки конечно же работают, но совсем не нагружены. То есть тест будет показывать куда большие значения, чем в момент, когда «облако» работает с более или менее высокой нагрузкой. У нас основная нагрузка приходится примерно на 17:00. Такая ситуация достаточно постоянна, и поэтому мы стали выполнять замеры в это время. Тестировали в течении полутора недель. Каждый тест выполняется около 10-15 минут.
Тестирование сети
Итак, мы получили практические данные по скорости виртуальных машин и сравнили себя с другими «облаками». Следующий наш шаг – сетевые тесты: на них определяется скорость сети между виртуалками, стабильность работы вашей виртуальной инфраструктуры, скорость и стабильность работы сети на стыке нашего «облака» и физического оборудования заказчика, которое располагается на другой площадке (или, например, физических систем хранения данных заказчика, пристыкованных к его виртуальной инфраструктуре), а так же скорость каналов связи, которые обеспечивают интерконнект между ЦОДами.
Почему это нужно? Потому что, например, если у вас есть две active-active системы в двух разных ЦОДах, либо основная система и копия высокой доступности на случай отказа первой, то канал между этими точками очень важен. Мы специализируемся на таких решениях для крупного бизнеса. И скоро мои коллеги в отдельном топике расскажут, как мы воевали для одного клиента за критически важное снижение задержек с 7 мс до 5 мс для транзакций между ЦОДами.
Итог
Тесты прошли в нашем «облаке», расположенном в дата-центре «Компрессор». UnixBench на конфигурации 1 vCPU, 4Gb RAM. Сами же результаты проведенных тестов нас приятно удивили: они показали, что производительность виртуальных машин в «облаке» КРОК ничуть не хуже, чем у лидера списка полученных нами результатов Windows Azure – инфраструктурной облачной платформы компании Microsoft.
Результаты вот такие:
Итоговая таблица тестирования:
| Дата |
CROC Cloud |
Amazon |
HP Cloud |
Rackspace |
SoftLayer |
Windows Azure |
| 20.06.2013 |
1468,9 |
337,9 |
1350,4 |
561,6 |
1137,2 |
1437,6 |
| 21.06.2013 |
1454,4 |
375 |
1338,6 |
569,5 |
1139,4 |
1446,1 |
| 22.06.2013 |
1459,8 |
421,2 |
1352,7 |
568,7 |
1140,7 |
1444,5 |
| 23.06.2013 |
1446,7 |
378,6 |
1333,5 |
469,1 |
1137,1 |
1451 |
| 24.06.2013 |
1470,1 |
378,5 |
1344,9 |
568 |
1137,5 |
1433,2 |
| 25.06.2013 |
1467,8 |
381,5 |
1326,4 |
565,2 |
1142,3 |
1447,1 |
| 26.06.2013 |
1465,8 |
380,2 |
1338,2 |
563,6 |
1134,1 |
1449,3 |
| 27.06.2013 |
1439,9 |
375,8 |
1328,8 |
574,1 |
1140 |
1442,6 |
| 28.06.2013 |
1430,2 |
376,5 |
1327,7 |
537,3 |
1139 |
1434 |
| 29.06.2013 |
1419,1 |
373,2 |
1341,6 |
575,2 |
1135 |
1442,2 |
