Как измерить производительность «облака»?


    На графике – тесты производительности виртуальных машин пяти крупнейших игроков на рынке 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


    Теперь мы ждём новые сервера в Виртуальный дата-центр КРОК. К осени производительность виртуалки вырастет ещё примерно на 50%.
    КРОК
    266,26
    №1 по ИТ-услугам в России
    Поделиться публикацией

    Комментарии 19

      +1
      Не могу не отметить, что домен cloudspectrator.com не существует. Это ошибка в тексте или дело в чем-то другом?
        +1
        Простите, cloudspectator.com
        +1
        Судя по табличке, только у Амазона 1 ядро, а у остальных по 2 (не очень понятно с HP Cloud только). Если запускать ваш тест на Амазоновских Small, Medium и Large инстансах, какую разницу в попугаях он показывает? В теории, они должны в 2 раза отличаться. И ещё в табличке цен не хватает.
          0
          По ценам на Azure и Amazon medium инстансы на линуксе стоят одинаково (у амазона цена немного варьируется в разных регионах)
            0
            Не совсем так. Все ВМ взяты примерно одинакового размера (соотношение 1 к 4-м между ядрами и оперативной памятью). Разница в показателях связана с типом процессора, использующегося на физических серверах, предназначенных для запуска ВМ, а также политикой конкретного «облака» по выделению вычислительных ресурсов (не все выделяют гарантированные мощности). Отличаться будет, но не в 2 раза. Опять же из-за политики выделения.
              0
              а еще, времени тестирования… Дата есть, а времени как раз нет, хотя упоминание есть.

              А еще — указания, сколько же клиентов на облаке КРОКа. Ибо Амазоновские и Ракспейсовские серверы как раз загружены (судя по количеству упоминаний их в качестве поставщика), а вот простаивающие КРОКи (и Азуры) вполне могут себе позволить выдавать больше попугаев.
              +5
              UnixBench — это очень сферические попугаи, я даже не знаю, зачем эту бесполезную утилиту придумали и что она в итоге меряет ))
              Покажите лучше, как у вас с дисками дела — iozone3, например.
                0
                У нас 2 тира (FC и SATA) дисков с онлайн миграцией между ними. С производительностью все хорошо. Обязательно покажем замеры дисковой и сетевой производительности как закончим цепочки тестов.
                +1
                Вот когда ваше облако станет размерами хотя бы в треть «тех» облаков, тогда и можно будет меряться. Да и чем-нибудь получше, чем unixbench, который меряет все что угодно, но не реальную нагрузку…
                  +1
                  Не соглашусь. Крок вывел продукт на рынок, который предоставляет услугу с хорошей производительностью. Клиент вправе выбирать сам: идти в большое, но задумчивое облако, или в маленькое, но ненагруженное и быстрое.
                  +11
                  Статья — маркетинговый %сами_знаете_что%

                  Почему:
                  1. Шейпы подобраны разные. По приведенной табличке, например, у AWS 1 vCore, у остальных по 2, у HP -4.
                  2. Вы сравнили только по 1 шейпу. Их производительность зависит от количества виртуалок на хосте. Например, если у вас медиум инстансов 10 на хосте, а у амазона 20, то сами понимаете, что результаты будет отличаться.
                  3. Много воды, мало конкретных команд. И, как сказали выше, только одна утилита использовалась, кторая не понятно что меряет вообще.
                    –2
                    Обратите внимание: мы выбрали такую методологию поскольку она предложена независимой стороной и может быть легко повторена для любого «облака». Дальше мы планируем проводить дополнительные тесты и расскажем об их результатах.
                      +5
                      Она ничего не меряет! Ну то есть совсем ничего полезного. Причем результаты теста, который в итоге ничего полезного не меряет, могут варьироваться в пределах 200% только из-за изменений нескольких параметров в sysctl.
                      Никакой картины о производительности эта утилита не дает.
                      Интересуют реальные замеры по разным группам параметров. Причем черт с ней памятью и CPU, с этим проблем давно ни у кого нет.
                      Покажите диски. Скорость I\O и латенси.
                        0
                        Ок. Уже ответил выше: закончим тесты и покажем. Наверняка у вас есть ещё вопросы по «облаку» — было бы здорово услышать все параметры, которые вам интересны для сравнения. Включая, может быть, не только сугубо технические.
                          +1
                          Опять же покажут конфетку и всё. Проблема в том, что не очень похоже на интерес к реальным показателям. Методика даже не своя, какой-то малопонятной группки людей.
                          По факту, единственный вариант замеров — оценка худших случаев для каждого показателя. Когда весь хост попилен и всё работает. Но и тут хватает своих камней, правда все лучше чем на голой машине мерить.
                      +8
                      Странно, что КРОК не быстрее Азуры. Скромные однако. :D
                        +2
                        Результаты исходного сравнения от cloudspectator.com можно посмотреть здесь.

                        Методика выбора виртуальных машин для сравнения непонятна. Выбираем виртуальные машины, приблизительно одного шейпа. На мой взгляд это игра в одни ворота. Как можно сравнивать 1 ядерный Amazon EC2 с 4-х ядерным HP Cloud. Если уж брать по честному, то лучше было бы сравнивать инстансы с одной стоимостью. К примеру до $0,35 за час вычислений. Вот тогда можно было бы сделать выводы, что за те же деньги вы получаете большое compute-ресурсов.

                        Думаю заказчика в первую очередь будут интересовать сколько денег он будет платить за конфигурацию, а не мегагерцы с мегабайтами. Все в жизни деньги. Это бизнес!
                          +1
                          Простите, не понял, в каких попугаях у вас по оси Y величины откладываются? И почему это одномерный график? Сколько процессора в одном иопсе? Как скорость доступа к памяти складывается с производительностью сети?

                          Тест выглядит так: мы изобрели попугаи, и эти попугаи показывают, что мы лучшие.
                            +1
                            Рекомендую заглянуть на cloudharmony.com/benchmarks Там есть сравнение почти всех облачных хостингов по огромному количеству различных бенчмарков.

                            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                            Самое читаемое