company_banner

Нагрузочное тестирование CPU и SSD облачных хостеров: сравниваем Selectel, Servers, MCS и Я.Облако



    Мы постоянно работаем с интернет-магазинами и сервисами и периодически у наших клиентов встает вопрос, где же им хостить свои проекты. Вопросы эти более чем обыденные: какой хостинг выбрать, в каком регионе, что решать с конфигурацией. В последние годы все большее предпочтение отдается облачным хостингам; процент аренды полноценных стоек в упоминаемом нами сегменте для новых проектов становится все меньше и меньше, да и уже работающие компании постепенно переводят свое добро на облачные платформы. Причина проста — кроме вычислительных мощностей бизнесу уже недостаточно одной лишь командной строки для управления «хозяйством». Нужно и удобство управления инфраструктурой и, что немаловажно, возможность его автоматизации. Это обычная ситуация как для мирового, так и для российского рынка. Если угодно — тренд.

    За последние два года в нашей стране появилось два новых крупных игрока на рынке облачного хостинга: Яндекс.Облако и Mail Cloud Solutions. Нам стало интересно, на что способно железо каждой из представленных компаний и насколько реально производительны предоставляемые конфигурации ресурсов. Мы решили это выяснить, а после — сопоставить данные с озвученными ценовыми предложениями.

    Так как сами хостинг мы не продаем, а лишь периодически консультируем наших клиентов и подбираем им оптимальное по цене-качеству решение, то в этом вопросе мы сможем быть сравнительно объективны.

    Тесты


    Для анализа были выбраны три основные характеристики: производительность вычислительных ресурсов, производительность дисковой подсистемы и стоимость хранения/передачи данных. Мы не стали перебирать все возможные десятки вариантов облачного хостинга, а сразу остановились на четырех наиболее очевидных и популярных отечественных решениях. Это облачные услуги от Selectel, MCS, Я.Облака и Servers.ru.

    Начнём с рассмотрения стоимости хранения и передачи одного Гб данных в месяц:

    Selectel: всё ясно и просто, без дополнительных условий.
    Диски/месяц
    Базовый диск 7,45 ₽/ГБ
    Быстрый диск 44,68 ₽/ГБ
    Универсальный диск 29,79 ₽/ГБ
    Локальный диск 15,05 ₽/ГБ
    Исходящий трафик/месяц
    до 10 Tb 1,02 ₽/ГБ
    до 90 Tb 0,92 ₽/ГБ
    до 900 Tb 0,82 ₽/ГБ
    свыше 1000 Tb 0,71 ₽/ГБ
    Servers, к сожалению, не указывает точных цен на диски, только общую цену на готовые сборки.

    Mail не берут денег за трафик, только за занимаемое место по типу используемых дисков. А также предоставляет готовые решения по определенным ценам.
    HDD 7₽/ГБ
    SSD 19 ₽/ГБ
    У Яндекса тоже всё просто:
    Диски/месяц
    HDD 2,0847₽/ГБ
    SSD 7,4441 ₽/ГБ
    Исходящий трафик
    до 10 Tb 1,5254 ₽/ГБ
    до 50 Tb 1,272
    до 150 Tb 1,08 ₽/ГБ
    свыше 150 Tb 0,9 ₽/ГБ
    Для объективной оценки предлагаемого софта, сравнения производительности, а также оценки соотношения цена/качество было решено провести стресс-тест на показатель IOPS таких параметров, как CPU и быстродействие SSD.

    В случае с Я.Облаком для расчета стоимости использована цена SSD NVMe, поэтому общий ценник отличается в большую сторону. Помимо Я.Облака спецификацию NVMe предлагают и Selectel, но в нашем случае для сборки использована цена обычного SSD.

    В качестве тестируемой платформы была выбрана сборка со следующими характеристиками:
    CPU 2 core
    RAM 4 Gb
    SSD 80 Gb
    Посмотрите сводную таблицу со стоимостью данной сборки у всех рассматриваемых дата-центров:
    Selectel Servers MCS Я.Облако (SSD NVMe)
    5521,78 ₽
    (3 Гб трафика бесплатно)
    2440,68 ₽
    (включая 4 Тб трафика, до 10 Гбит/с)
    3 300 ₽ (включая безлимитный канал до 1 Гбит/с) 8557,0224 ₽
    Тестирование проводилось инструментами stress-ng и sysbench. Для CPU нагрузка давалась в 1, 2 и 4 потока.

    Тест CPU утилитой stress-ng (условных операций/сек, bogo ops/sec):
    1 поток 2 потока 4 потока
    Selectel 11476 22888 22019
    Servers 9174 18233 18093
    Я.Облако 8280 17586 17620
    MCS 7911 15926 14107




    Тест CPU утилитой sysbench:
    1 поток 2 потока 4 потока
    Selectel 731,45 1471 1457,71
    Servers 707,9 1406,32 1406,31
    Я.Облако 707,81 1381,74 1379,83
    MCS 683,04 1344,15 1344,54








    Из вышеприведенных данных можно сделать вывод, что сборка полноценно использует 2 ядра процессора, показатель количества операций ввода/вывода возрастает вдвое при увеличении количества используемых ядер. Наиболее высокий показатель, а, соответственно, и более высокую производительность показывает процессор Selectel.

    Selectel предлагает три варианта процессоров на выбор, в отличие от остальных дата-центров:

    • Intel Xeon E5-2670 v3 2,3 ГГц;
    • Intel Xeon E5-2680 v4 2,4 ГГц;
    • Intel Xeon Scalable 6140 2,3 ГГц.

    Наименьшую производительность показал процессор компании Mail (Intel Xeon E5-2660 v4 2 ГГц). Процессоры Servers и Я.Облако показали под нагрузкой примерно сравнимые результаты, но процессор Servers был чуточку лучше, при двух использующихся ядрах — 18233 и 17586 операций соответственно.

    Для SSD тестирование проводилось на проверку количества IOPS случайным чтением пакетов размером 512 байт с ограничением по объему 4Гб и чтением/записью (эмуляцией БД) пакетов размером 4кб при параметрах 75% чтения и 25% записи с ограничением по объему в 16Гб.

    Результаты тестов SSD:
    Чтение Чтение/Запись
    Selectel 12800 12300/4122
    Servers 106000 8367/2799
    Я.Облако 6228 2841/947
    MCS 23200 6152/2061




    Из результатов тестирования можно заключить, что наилучшие по быстродействию чтения SSD предлагает компания Servers — с результатами в 106 тысяч IOPS.

    Хороший показатель на чтение с диска показывает SSD, предлагаемый компанией MCS, с показателем 23200 IOPS. Следующим идёт SSD Selectel со значением в 12800. И самый неудовлетворительный показатель у SSD, предоставляемом Я.Облаком: значение IOPS в 6228 совершенно никуда не годится :-( То же самое можно сказать про SSD Я.Облака в тесте не только на чтение с диска, но и на запись. Показатель очень мал — 2841/947. Лучше ситуация обстоит у SSD Mail, но тем не менее, результат тоже не особенно вдохновляет — 6152/2061 IOPS.

    В этом тесте лидируют жесткие диски, использующиеся Selectel и Servers. Их показатели на чтение/запись — 12300/4122 и 8367/2799, соответственно.

    Из тестов становится ясно, что для чтения с диска однозначно лучше использовать SSD, предоставляемые дата-центром Servers, а остальные варианты рассмотреть в зависимости от необходимых нужд компании и доступности цен.

    Объектное хранилище


    Для тех, кто в своей деятельности также любит использовать S3-совместимые объектные хранилища, их ценники мы тоже сравнили.

    Selectel
    Хранение данных
    до 1 ТБ 1.43 ₽/ГБ
    от 1 до 10 ТБ 1.33 ₽/ГБ
    от 10 до 100 ТБ 1.23 ₽/ГБ
    более 100 ТБ 1.01 ₽/ГБ
    Исходящий трафик
    до 10 ТБ 1,02 ₽/ГБ
    до 90 ТБ 0,92 ₽/ГБ
    до 900 ТБ 0,82 ₽/ГБ
    более 1000 ТБ 0,71 ₽/ГБ
    Servers предлагает цены в диапазоне от 2,27₽/ГБ до 4,53₽/ГБ, в зависимости от местоположения. В таблице приведена цена хранения за 1ГБ в Москве:
    Хранение данных
    Первые 1 TB 2,54 ₽/ГБ
    Следующие 50 TB 2,34 ₽/ГБ
    Следующие 100 TB 2,14 ₽/ГБ
    Свыше 151 TB 1,93 ₽/ГБ
    У них можно взять и хранилище в Амстердаме по ~2,27 ₽, но надо понимать, что для него стоимость привязана к курсу евро, плюс, как и для любой другой зарубежной площадки Servers в Люксембурге, Далласе или Сингапуре, не учтен 20% НДС. Так что, условно, предложение в Москве все же самое выгодное, потому что тут цена указана уже с НДС.
    Исходящий трафик
    до 3 TB 0,81 ₽/ГБ
    до 20 TB 0,76 ₽/ГБ
    до 100 TB 0,71 ₽/ГБ
    более 100 TB 0,66 ₽/ГБ
    Mail Cloud Solutions не ранжируют стоимость хранения по объему данных, только по типу хранилища, а также рассчитывают стоимость не по объему исходящего трафика, а по количеству операций ввода/вывода:
    Хранение данных
    Горячее хранилище 2,5 ₽/ГБ
    Холодное хранилище 2,3 ₽/ГБ
    Количество операций ввода/вывода
    Горячее хранилище
    1 000 IOPS PUT, META, LIST
    0,295 ₽/ГБ
    Горячее хранилище
    10 000 IOPS GET и др.
    0,295 ₽/ГБ
    Холодное хранилище
    1 000 IOPS PUT, META, LIST
    0,295 ₽/ГБ
    Холодное хранилище
    10 000 IOPS GET и др.
    0,59 ₽/ГБ
    У Яндекса тоже всё просто: стоимость зависит не от объёмов занятого пространства, а от типа хранилища:
    Хранение данных
    Стандартное хранилище 1,261 ₽/ГБ
    Холодное хранилище 0,6712 ₽/ГБ
    Исходящий трафик
    до 10 TB 1,5254 ₽/ГБ
    до 50 TB 1,272 ₽/ГБ
    до 150 TB 1,08 ₽/ГБ
    более 150 TB 0,9 ₽/ГБ

    API


    Что касается автоматизации процесса управления инфраструктурой, то у всех перечисленных выше операторов есть доступные механизмы API.

    У троих из них API OpenStack-совместимое, т.к. внутри, собственно, используется именно он в том или ином виде. Яндекс же пошёл дальше и делает свою собственную альтернативу OpenStack. Как итог их API потеряло совместимость со всем, кроме хранилища файлов. Его, видимо в силу большой популярности и распространённости формата, решили оставить S3-совместимым, по заветам Амазона.

    Ссылки на соответствующую документацию:

    Selectel VPC
    Servers.ru
    MailCloudSolutions
    Cloud.Yandex

    Выводы


    В силу того, что разные сервисы по-разному ранжируют свои услуги, свести воедино все вышеперечисленные данные довольно сложно. Поэтому мы решили соотнести перечисленные ценники с конфигурацией одного среднего уровня интернет-магазина, находящегося у нас на поддержке. И по итогу получили примерно следующие данные о стоимости месячной аренды сервера на разных площадках:



    Это что касается финансово-практической стороны дела. Что же до производительности, то тут, мы думаем, вы и сами всё поняли. По производительности процессоров в лидеры с хорошим запасом вырывается Selectel. Тогда как MCS ещё предстоит поработать над предоставляемыми вычислительными ресурсами. По производительности дисковой подсистемы Servers.ru и Mail Cloud Solutions же, наоборот, явно обгоняют товарищей.

    Знание об этих сильных и слабых сторонах, плюс сводная информация по ценам, как мы надеемся, помогут выбрать правильного поставщика облачных услуг под конкретные задачи.
    ITSumma
    350,00
    Собираем безумных людей и вместе спасаем интернет
    Поделиться публикацией

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

      +3
      Статья ни о чем.
      Во-первых, тот же Селектел предлагает несколько разных услуг. Начиная от простых ВМ vScale и кончая полными «облачными инфраструктурами». Причем последние есть как на базе OpenStack (по сути полностью публичное облако Селектела), так и на vmware (не тестировал плотно).
      Дополнительно — ценники и спецификации на OpenStack тут selectel.ru/services/cloud/vpc/?dedicatedab=true
      Что понравилось — действительно IOPS на накопители ограничиваются и они насколько это возможно гарантированы VM. Понятно, что между IOPS и скоростью (чтения, записи, в МБ/сек) есть прямая зависимость, но возможен кейс, когда софт не полностью утилизирует пропускную способность, хотя IOPSы в потолок. Поэтому тут нужно подходить очень аккуратно.

      Касательно возможности выбора процов — вообще впервые слышу, никогда особо это проблемой не было.
        +2
        Во-первых, тот же Селектел предлагает несколько разных услуг. Начиная от простых ВМ vScale и кончая полными «облачными инфраструктурами». Причем последние есть как на базе OpenStack (по сути полностью публичное облако Селектела), так и на vmware (не тестировал плотно).

        Вскейл, конечно, аффилированная с селектелом контора, но это скорее просто бюджетный хостер виртуалок, чем полноценное облако. В статье рассматривается именно VPC.

        Касательно возможности выбора процов — вообще впервые слышу, никогда особо это проблемой не было.

        Не то, чтобы их можно было выбирать у каждого хостера из разных вариантов, конечно. Но понимать, какое железо крутится под твоей виртуалкой бывает полезно. И, возможно, кому-то будет важно выбрать более производительный проц.
          0
          Я уж не говорю про
          до 10 Tb

          простите — терабит, терабайт или терибайт (ТиБ)?
          Все-таки мы в русскоязычной среде и логично использовать кириллические аббревиатуры, желательно — максимально однозначные. И так по всей статье. Говорю же — сырая.

          P.S. уже поправили, но все равно в одном месте — «более 150 TB», в другом — «до 10 ТБ», а в таблице в конце — «Тб»
            +1
            В свою очередь, когда под конец речь идет про конфигу «среднего уровня интернет-магазина, находящегося у нас на поддержке», зачем говорить по облако, если задача как раз отлично ложится на виртуалку, или на выделенный сервер (возможно, с намазанной сверху виртуализацией)? Я рассуждаю в пределах запрошенных ресурсов и в пределах указанных цен.

            И, да, облака в России есть не только у перечисленных компаний, более того, у некоторых из них облака — не основной вид бизнеса. В то же время МТС (купивший ИТ-Град за 2,5 млрд рублей), например, как-то забыли привести — а у них, на сегодня, есть и облако МТС, и облако ИТ-Града (сужу как внешний наблюдатель).

            По поводу простоты администрирования: арендованный виртуальный или физический сервер выдаётся в руки точно так же, как виртуалка в облаке, и администрируется сравнимо (т.е. облако не сказать чтобы проще, т.к. внутри тот же линукс, грубо говоря). А если учитывать дополнительный объем навыков работы с самим облаком (хотя в описываемом подходе это и не сильно критично: по описанию ничем «облачным», вроде автомасштабирования, мы тут не связаны), то, в чем-то, облако покажется и сложнее.

            Облака суперинтересны, когда всплывает разговор про API, про автоматизацию, но — про это как раз ни в описании, ни в тесте не говорится. Вот тест того, как скоро сервер при проблемах облака оживает — это, да, было бы интересно. Правда, осталось еще смоделировать проблему, чтобы облако смогло отработать! *смайлик*
              –1
              Облака суперинтересны, когда всплывает разговор про API, про автоматизацию, но — про это как раз ни в описании, ни в тесте не говорится.

              Об этом говорит первый же абзац, если вам довелось его прочитать:
              Причина проста — кроме вычислительных мощностей бизнесу уже недостаточно одной лишь командной строки для управления «хозяйством». Нужно и удобство управления инфраструктурой и, что немаловажно, возможность его автоматизации.


              Про доступность API и соответствующие релевантные ссылки написано ещё чуть дальше в отдельном подразделе.

              Цель статьи — именно сравнение соотношения мощность/ценник, чтобы понимать, куда податься тому, кто знает, зачем ему облако. А не затем, чтобы объяснить, кому оно нужно, а кому нет.

              И в данном контексте, честно говоря, плохо понимаю зачем уводить дискуссию в совершеннейший оффтоп.
                0
                И, да, облака в России есть не только у перечисленных компаний, более того, у некоторых из них облака — не основной вид бизнеса. В то же время МТС (купивший ИТ-Град за 2,5 млрд рублей), например, как-то забыли привести — а у них, на сегодня, есть и облако МТС, и облако ИТ-Града (сужу как внешний наблюдатель).

                хочу еще добавить, что в МТС еще внутри есть куча с одной стороны конкурирующих, а с другой — взаимодополняющих продуктов. Стоит сказать про AzureStack, например. А еще тут на подходе Сберклауд. Незаслуженно пропустили ActiveCloud — они еще 10 лет назад были. Ну, и есть, конечно, все еще облака от КРОК, Техносерв и пр. — легион им имя.
              0
              Поддержу.
              Товарищ fwm, у меня несколько вопросов:
              1. Сколько было итераций для получения каждой цифры?
              2. Сколько машин проверялось в каждом клауде?
              Плюс, у вас цифры со скриншотов не бьются с теми, что в таблице. Посмотрите на stress-ng тест, значений со скрина нет в таблице. Что это было?
              Сомнения у меня большие в этом тесте, ой большие. Не заказуха ли?
              Кстати, у меня есть некоторое кол-во машинок (в разных зонах доступности) в Я.Облаке для одного проекта и я решил прогнать ваши тесты (отдельное «спасибо» за ключи запуска на скриншотах вместо текста).
              Все машинки 100%, 2CPU/2GB, нагрузка в виде Kubernetes-мастеров со всей обвязкой не выгружалась. Машинки в разных зонах доступности.
              Вот что получилось:
              #### 1 CPU, Server 1, iter 1
              stress-ng --cpu 1 --cpu-method matrixprod --metrics-brief -t 60
              ...
              stress-ng: info:  [29104] stressor      bogo ops real time  usr time  sys time   bogo ops/s   bogo ops/s
              stress-ng: info:  [29104]                          (secs)    (secs)    (secs)   (real time) (usr+sys time)
              stress-ng: info:  [29104] cpu               9577     60.00     59.54      0.24       159.61       160.20
              #### 1CPU, Server 1, iter 2
              stress-ng --cpu 1 --cpu-method matrixprod --metrics-brief -t 60
              ...
              stress-ng: info:  [1585] stressor      bogo ops real time  usr time  sys time   bogo ops/s   bogo ops/s
              stress-ng: info:  [1585]                          (secs)    (secs)    (secs)   (real time) (usr+sys time)
              stress-ng: info:  [1585] cpu               9616     60.00     59.54      0.24       160.26       160.86
              #### 2 CPU, Server 1, iter 1
              stress-ng --cpu 2 --cpu-method matrixprod --metrics-brief -t 60
              ...
              stress-ng: info:  [31641] stressor      bogo ops real time  usr time  sys time   bogo ops/s   bogo ops/s
              stress-ng: info:  [31641]                          (secs)    (secs)    (secs)   (real time) (usr+sys time)
              stress-ng: info:  [31641] cpu               8795     60.01    111.70      0.69       146.56        78.25
              #### 2CPU, Server 1, iter 2
              stress-ng --cpu 2 --cpu-method matrixprod --metrics-brief -t 60
              ...
              stress-ng: info:  [32419] stressor      bogo ops real time  usr time  sys time   bogo ops/s   bogo ops/s
              stress-ng: info:  [32419]                          (secs)    (secs)    (secs)   (real time) (usr+sys time)
              stress-ng: info:  [32419] cpu               8743     60.01    112.04      0.67       145.70        77.57
              

              Для второго сервера:
              #### 1CPU, Server 2, iter 1
              # stress-ng --cpu 1 --cpu-method matrixprod --metrics-brief -t 60
              stress-ng: info:  [27228] dispatching hogs: 1 cpu
              ..
              stress-ng: info:  [27228] stressor      bogo ops real time  usr time  sys time   bogo ops/s   bogo ops/s
              stress-ng: info:  [27228]                          (secs)    (secs)    (secs)   (real time) (usr+sys time)
              stress-ng: info:  [27228] cpu              10142     60.00     59.71      0.07       169.03       169.66
              #### 1CPU, Server 2, iter 2
              stress-ng --cpu 1 --cpu-method matrixprod --metrics-brief -t 60
              ...
              stress-ng: info:  [27944] stressor      bogo ops real time  usr time  sys time   bogo ops/s   bogo ops/s
              stress-ng: info:  [27944]                          (secs)    (secs)    (secs)   (real time) (usr+sys time)
              stress-ng: info:  [27944] cpu              10121     60.01     59.92      0.00       168.67       168.91
              #### 2CPU, Server 2, iter 1
              stress-ng --cpu 2 --cpu-method matrixprod --metrics-brief -t 60
              ...
              stress-ng: info:  [29059] stressor      bogo ops real time  usr time  sys time   bogo ops/s   bogo ops/s
              stress-ng: info:  [29059]                          (secs)    (secs)    (secs)   (real time) (usr+sys time)
              stress-ng: info:  [29059] cpu               9055     60.01    111.35      1.04       150.90        80.57
              #### 2CPU, Server 2, iter 2
              stress-ng --cpu 2 --cpu-method matrixprod --metrics-brief -t 60
              ...
              stress-ng: info:  [29702]                          (secs)    (secs)    (secs)   (real time) (usr+sys time)
              stress-ng: info:  [29702] cpu               9084     60.00    111.53      0.95       151.39        80.76
              

              Сводными данными:
              1. В один поток на одном сервере 9596 средняя, на другом 10131. Даже с учетом фоновой ненулевой нагрузки.
              2. В два потока на двухядерных машинах даже МЕДЛЕННЕЕ, чем в один. Вероятно потому, что продаются потоки исполнения процессоров, а не честные физические ядра.
              Расскажете, как получились ваши результаты?
              P.S. На этих машинках какой то Haswell с 2ГГц на ядро, точнее из системы не видно.
                0
                Плюс, у вас цифры со скриншотов не бьются с теми, что в таблице. Посмотрите на stress-ng тест, значений со скрина нет в таблице. Что это было?

                КДПВ, скрины только для примера того, как вообще выглядят утилиты. Все полезные данные в таблицах.

                По методике проведения тестирования чуть позже сегодня черкнём деталей
                  0
                  КДПВ, скрины только для примера того, как вообще выглядят утилиты

                  ну, это вообще, извините, звучит смешно. Могли их либо вообще отдельно вынести (парни, поглядите как выглядят утилиты!) или хотя бы снять их с реальных тестов )
                    0
                    Отдельно куда, в отдельную статью?:) С реальных тестов конечно неплохая идея, но не сложилось, картинки готовили уже после завершения всех тестов, когда уже и площадки отключили.

                    Сорян за невольную мискоммуникацию.
                      0
                      Отдельно куда, в отдельную статью?:)

                      в отдельный раздел — «Использованный инструментарий»
                      Сорян за невольную мискоммуникацию

                      Я-то прощаю ) а вот сообщество — недовольно и гудит как пчелиный улей.
              +5
              Это не нагрузочное тестирование, а синтетические тесты.
              Мне кажется более показательно было бы развернуть какое-то популярное приложение и через него уже подавать нагрузку.
                –2
                Да, с «живым» битриксом (например, да хоть wordpress), конечно, было бы чуть интереснее, но всё равно синтетика, т.к. это либо его встроенным бенчмарком гонять, который довольно сильно далёк от объективности, либо гонять копию какого-то настоящего проекта по реплею логов. Чуть правдивее, но тоже характер нагрузки может сильно не совпадать с реальным.

                Для максимально жизненного тестирования было бы круто настоящий живой проект раскидать по четырём одинаковым виртуалкам и балансить поровну запросы ко всем. И уже тогда смотреть по нагрузке. Но на такие эксперименты почему-то не сильно хотят соглашаться:)

                Поэтому мы решили отбенчить непосредственно железо, какое предоставляют хостеры и сравнить между собой.
                  +1
                  Согласен, что на такие тесты надо согласовывать. Просто этими тестами для себя вы какое-то впечатление получили о производительности конкретных виртуалок, но выборка крайне мала. Мне не понятно как эти тесты помогут ответить на эти вопросы
                  Вопросы эти более чем обыденные: какой хостинг выбрать, в каком регионе, что решать с конфигурацией.

                  Стандартный клиент не сможет сопоставить IOPS-ы о которых вы им скажете в понятную ему производительность и доступность его сервиса.
                  Про доступность и вовсе отдельный вопрос. Как будут меняться времена отклика от сервиса в зависимости от времени суток/дня недели/месяца и т.п. На такие тесты было бы интересно посмотреть, да и Вам было бы что аргументированно отвечать клиентам.
                    –1
                    Стандартный клиент не сможет сопоставить IOPS-ы о которых вы им скажете в понятную ему производительность и доступность его сервиса.

                    Конкретно в нашем случае это решается тем, что у нас уже есть данные о том, как ведёт себя система клиента, какие там узкие места. Даже для только пришедших новых клиентов мы всегда заявляем, что хотя бы неделю-две надо помониторить все сервисы, посмотреть, где во что упирается проект. И уже на основе этих данных и того, что мы заранее потестировали у хостеров, можем как-то рекомендовать, куда бы лучше переехать. Если конечно такая потребность имеется.

                    Про доступность и вовсе отдельный вопрос. Как будут меняться времена отклика от сервиса в зависимости от времени суток/дня недели/месяца и т.п. На такие тесты было бы интересно посмотреть, да и Вам было бы что аргументированно отвечать клиентам.

                    Это прямо очень классный запрос! Но, к сожалению, пока многие опасаются держать прод на мало пока известных и проверенных площадках, поэтому выборка лично у нас получится не очень репрезентативной на данный момент.

                    Но, возможно, в том числе и эта статья поможет людям понять, что, на самом деле, нет явно плохих или явно хороших площадок, у каждой свои плюсы и минусы. И, возможно, чуть позже мы сможем и долгосрочную статистику по доступности/надёжности собрать:)
                      +1
                      Но, возможно, в том числе и эта статья поможет людям понять, что, на самом деле, нет явно плохих или явно хороших площадок, у каждой свои плюсы и минусы.

                      золотые слова. А если еще учесть старания маркетологов, то мы поймем, что качество каждой площадки в рамках одного региона будет в прямой зависимости от стоимости услуг.

                      Самое интересное, что я тоже делал синтетические тесты. Т.е. брал сферическую в вакууме монгу, натравливал на нее github.com/brianfrankcooper/YCSB и смотрел разницу. Ну, в целом — что виртуалка в локальном частном облаке на vmware, что селектел, что yandex давали ± одну производительность. Единственный, кто вырвался вперед — мой рабочий ноутбук )))) Т.е. получается, что все эти виртуальные инфраструктуры можно измерять в неких стандартных единицах неких стандартных серверов.
                0
                Тестирование IOPS блоками в 512 очень странно. Стандартный размер блока 4К. Учитывая сколько IOPS показали servers и яндекс, думаю предлагаемые технологии внутри очень различны. Servers предоставляет трехкратную репликацию в разные зоны доступности? Если нет, то сравнение и выводы тем более некорректны.
                  0
                  Учитывая сколько IOPS показали servers и яндекс, думаю предлагаемые технологии внутри очень различны. Servers предоставляет трехкратную репликацию в разные зоны доступности?

                  Совершенно не исключаем того, что внутри оно может быть устроено различно. Но, к сожалению, в информационных и рекламных материалах о таких деталях пишут крайне редко. У вас есть какие-то данные более подробные на эту тему? Которые могли бы подтвердить соответствующие представители компаний, перечисленных в статье? С радостью дополним, в таком случае, статью:)
                    0
                    Про яндекс у них была презентация, видео и тп. Поэтому нет смысла спрашивать их комментарии.
                    Селектел вроде ceph использовал, но могу уже подзабыть. MCS на сколько помню, вроде тоже Ceph. А вот что с servers не знаю.
                      0
                      Мне кажется, что потребителю от того, как устроено облако внутри ни тепло, ни холодно. Потребителя интересуют «внешние интерфесы» облака — насколько удобна и стабильна панель, охват услуг, стоимость и пр. А внутри — хоть техподдержка руками пускай виртуалки запускает ))))
                      Другой вопрос — риски и их оценка. Но это больше вопрос договорных отношений, чем технологичности.
                      p.s. меня как «гика» естественно интересует наиболее полная информация, т.е. ВСЕ, но это частный случай.
                        0
                        Это зависит от технической грамотности потребителя. Как правильно заметили, локальный комп с ссд даст иопсов больше, так может всех надо на таких размещать? Только когда один ссд сдохнет, поздно будет оправдываться тем, что я же не знал как оно устроено.
                          0
                          Вы не правы. Потому что потребитель — он должен выставлять требования. Ну, там по отказоустойчивости, по доступности и пр. Только он знает свою предметную область на 100%. А мы как технические специалисты можем посоветовать как эти требования удовлетворить и за какую сумму.
                          Условно — локальный ноутбук для целей разработки вполне подойдет. Сломается? Да и пофиг, запустим разработку/тесты на соседнем. А продакшн — да, на такое страшно тащить.

                          Касательно облака — вот все думают, что оно прям отказоустойчиво, все данные бекапятся и т.д. Это обывательская и неверная точка зрения. Потому что действительно разработчики и провайдеры облака предусмотрели многие кейсы, но вот все равно те же бекапы (хотя бы подключение их как услуги) — лежит на плечах потребителя.
                  +3
                  Да, облака… Если сравнить с арендой серваков (тем же chipcore от Селектела), получается тройной ценник за более низкую производительность.
                    +1
                    Да, действительно, чисто за производительность железки выходят экономичнее виртуалок любого рода. Но железки и обслуживать конечному пользователю сложнее.

                    Но безотносительно этого всего, конкретно на чипкоре я бы держать прод не рекомендовал бы. Это очень явный лоукост с соответствующим уровнем предоставляемых услуг.
                      0
                      Что вы имеете в виду под «обслуживать»? По чипкору я так понимаю это тот же селектел, но ограничены методы оплаты и конфигурации на десктопных процах (еще меньше трафика, чем в обычном Селектеле), не думаю, что там есть какая-то разница в уровне услуг…
                        +1
                        Что вы имеете в виду под «обслуживать»

                        Всё, что, собственно, можно под этим подразумевать. Чинить, апгрейдить, даунскейлить. Условно говоря, управления конфигурацией в железках никакого, а когда они ещё и ломаться начинают, это только наполовину головная боль хостера.

                        По чипкору я так понимаю это тот же селектел, но ограничены методы оплаты и конфигурации на десктопных процах (еще меньше трафика, чем в обычном Селектеле), не думаю, что там есть какая-то разница в уровне услуг…

                        Если сами не пробовали, то как пытаетесь оценивать?:) Это такой же селектел, как и vscale. По факту, отдельная организация в рамках холдинга. Железо совершенно другое и по назначению и по стабильности, команда поддержки совершенно другая и спектр вопросов, которые они могут помочь вам решить мал просто до неприличия. По факту, зачастую ограничиваются исключительно перезагрузкой сервера в любой непонятной ситуации.
                          0
                          Понятно. Интересно было бы как контрольный образец взять какой-нибудь lowend (Xeon E3) физический сервер в ваших бенчмарках — например, для тех, кто планирует переезд в облака или обратно.
                            +1
                            Не надо брать Xeon E3, он быстрее чем Xeon E5, которые ставят крупные хостеры (E5 позволяет более плотно набивать стойки). Тот же chipcore использует десктопные Core i7, которые на голой числодробилке порвут и E5 и даже E3 (за счёт TurboBoost). Так что всё сложно с процессорами у хостеров.
                        0
                        Могу ответить  Metal-as-a-Service: maas.io
                        +1
                        Виртуальные сервера это не всегда про то что дешевле.
                        Чаще всего в виртуальных серверах есть почасовой/поминутный билинг, снапшоты, миграции, блочные устройства и еще много разных плюшек за которые и приходится платить.

                        Большую часть из этого можно и на железе самому сделать. Но это уже затраты тех же денег или времени.
                          0

                          Облако создано для "ленивых" на бюджетах. Если у тебя хоть какая-то потребность в нормальных ресурсах ценник становится просто космос. И аренда х5 серверов с настройкой кластера под ключ и обслуживанием выйдет дешевле, чем такое "облако". В статье совершенно дохлая виртуалка… В селектеле аналогичный сервер за 990 рублей сдавали по акции.

                            0
                            Ну, я с вами не соглашусь. Бывают ситуации, когда свое железо дешевле конечно, но это от кейса к кейсу.
                            Могу вам озвучить реальную стоимость одной инфраструктуры в GKE, обслуживающей достаточно крупную команду заработки (частный бизнес, никаких бюджетов), состоящей из вот чего:
                            1. Два независимых K8s кластера, каждому по балансеру для Ingress. На обоих активно используются preemptible-ноды,:
                            — Один — 3 машины, в сумме 5 CPU и 14 Гб памяти в статике, иногда надувается до 11 CPU и около 30 Гб памяти.
                            — Второй — 9 машин, в сумме 9 CPU и 34 ГБ памяти в статике, надувается в пике до 30 CPU и почти 100 ГБ памяти (больше разрешено, но ни разу не видел).
                            2. 12 назависимых, но мелких PostgreSQL баз, в которых лежат всякие не очень критичные штуки, поэтому без включенного HA.
                            3. Еще одна достаточно база PostgreSQL, тоже мелкая, но с включенным HA.
                            4. Около 3.2 ТБ архивов в cold storage.
                            5. Около 500 Гб в региональном сторадже, куда кладутся первичные бэкапы, где живет Docker Registry и еще всяких штук по мелочи.

                            По обслуживанию — всегда последние security патчи без даунтайма и даже без просадки производительности, полностью автоматизированное управление.
                            Профит — нулевая очередь на сборку при любых нагрузках, максимальное ожидание — 3-4 минуты, пока автоскейл ноду инициализирует, все данные удобно бэкапятся, можно выключать\менять размер любых нод в течении 15 минут, убирать-добавлять сервисы по желанию вот прям тогда, когда нужно, ресурсы аллоцируются автоматически (ну то есть вообще нет вопроса «ой, какой то ресурс заканчиваеся»), сервисы изолированы друг от друга(сеть + физически разнесены на разные инстансы самые критичные штуки), можно при желании выдавать права на управление-администрирование (не в панельку, а вот прям внутрь) с градацией до сервиса, все легко переподнимается в любом другом месте в течении пары часов, т.к k8s + helm + дампы баз + где надо дампы статики с диска.
                            На обслуживание именно инфраструктуры тратится 30 минут в месяц, когда надо ткнуть апдейт для тех групп машин, для которых автоапдейт запрещен да кубик на мастерах обновить.
                            Обходится это все добро по данным биллинга в 650-700 долларов в месяц в зависимости от активности разработчиков.
                            И да, админа на окладе тут нет, потому что для этого он не нужен.
                            Да, за эти деньги можно взять 3 жирных машинки где-то в приличном месте, но обслуживание их будет стоить далеко не 100 баксов в пересчете на все простои, тупняки и зарплату специалистов.
                            +1
                            Более того, виртуальные сервера ВСЕГДА дороже ) В пересчете на производительность. Виртуалки хороши в двух случаях:
                            1. Вам нужно значительно меньше, чем один физический сервер (и нет смысла переплачивать).
                            2. Вам не очень важна разница в цене и важнее удобство администрирования и меньше косты на поддержку

                            Если же нужен большой объем, то точно выгоднее железо. Я например арендую десяток серверов, поверх которых развернуто примитивное private cloud, которое уже нарезано виртуалками удобным способом под разные проекты и задачи. Я думаю, получается раза в 3 дешевле, чем если бы я виртуалки брал.
                              0
                              Ну, всегда есть три категории пользователей. Или больше.
                              1. стартап. Вкладываться в свое железо не выгодно, выгодно платить по схеме pay as you go. Виртуалки.
                              2. средний бизнес — пока еще до скидок в амазоне не дорос, но уже может позволить себе своих технарей. Можно использовать как облако (дорого), так и баре метал (стоимость железа по сравнению с ФОТ копейки, хотя и труд, считай, что дармовой).
                              3. большой бизнес — может прогибать поставщиков под выгодные условия. Вертит такими масштабами, что ему нужна возможность срочно аллоцировать ресурсы. Выгодный сценарий — или облако, или гибрид.
                                +1
                                Ещё мой случай опишу, который вроде как малый бизнес.

                                — Нет своего админа, который занимался бы серверами, мои возможности поддерживать и масштабировать собственные сервера ограничены. Как пример, 5 лет назад брал железку, ещё без SSD, теперь не знаю куда её девать, так как скорость работы дисков уже не удовлетворяет, а замена дисков например на тот же SSD — знатный геморрой.
                                — Растёт число клиентов, а следовательно постоянно требуется больше ресурсов. Отмасштабировать имеющиеся виртуалки можно вообще мгновенно, по API, добавить новую виртуалку — пара кликов. Наверное арендовать железки с ресурсами про запас было бы дешевле, но собственные железки сложнее нарезать на виртуалки, можно просто не угадать с пропорциями.

                                Плюс часть задач по обеспечению аптайма всё-таки перекидывается на хостера. Хотя с Selectel был негативный опыт: у них осенью было 2 подряд сбоя дисков, когда виртуалки лежали сперва около 12 часов, а затем и вообще около 30 часов.

                                Но всё равно простота и незаморочность при ограниченном количестве ресурсов на поддержку инфраструктуры подкупает.
                                  +1

                                  Имхо. Аренда серверов вас спасет.
                                  Облако реально переоценено. Виртуалки — да. Стоят адекватно и растут. Тут же 2 ядра и 80 гигов ssd с 4 гигами памяти + трафик. За цену выделенного сервера с 100мбит безлимитом.

                                    0
                                    Вот вы говорите «спасет», а расскажите реальный кейс-более менее крупной инфраструктуры где она реально спасет, с учетом всех накладных расходов?
                                    Я с облаками уже давно работаю и если учитывать не только прямые расходы, вроде стоимость ядра в месяц, то в большинстве (не во всех, но большинстве) сценариев облако выигрывает по совокупности и не особо то бьет по карману.
                                    0

                                    Добавить SSD в качестве кеша к существующим дискам и этого скорее всего будет достаточно.

                                      0
                                      И главный вопрос.
                                      Все вот пишут — нет своего админа.
                                      А виртуалки типа сами разворачиваются? А-ля нажал кнопочку, а там уже кластер? Виртуалка и машина в облаке ничем не отличаются от выделенного сервака у того же селектела или OVH — выдается за 5 минут, система накатывается в 2 клика…
                                      Аптайм — да в том же датацентре у того же хостера…
                                      Разве что бекапы проще — клик в панели вместо баш скрипта…
                              +1
                              Из результатов тестирования можно заключить, что наилучшие по быстродействию чтения SSD предлагает компания Servers — с результатами в 106 тысяч IOPS.

                              Хороший показатель на чтение с диска показывает SSD, предлагаемый компанией MCS, с показателем 23200 IOPS. Следующим идёт SSD Selectel со значением в 12800. И самый неудовлетворительный показатель у SSD, предоставляемом Я.Облаком: значение IOPS в 6228 совершенно никуда не годится :-( То же самое можно сказать про SSD Я.Облака в тесте не только на чтение с диска, но и на запись. Показатель очень мал — 2841/947. Лучше ситуация обстоит у SSD Mail, но тем не менее, результат тоже не особенно вдохновляет — 6152/2061 IOPS.

                              В этом тесте лидируют жесткие диски, использующиеся Selectel и Servers. Их показатели на чтение/запись — 12300/4122 и 8367/2799, соответственно.


                              Ничего не понял. У Servers 106000 iops или 8367?
                              Больший iops на практике означает, что на него нет лимитов, и человек с тяжелой виртуалкой может ухудшить жизнь соседям.
                                0
                                лучший коммент!
                                  +1
                                  Жаль, не могу плюсануть в карму!)))

                                  По существу отвечу, что 106к ёпсов — это на чистое чтение, а если давать нагрузку 75%/25% чтение/запись, то результаты станут 8367/2799.

                                  Очень похоже, что они или используют огромный кэш на чтение, либо не ограничивают машинки по ёпсам вообще.
                                  +1
                                  Вроде статью назвали «Нагрузочное тестирование», а по факту получилось «сравнение цен». Где хотя бы одна табличка с результатами измерения именно производительности?
                                    +1
                                    опс, потеряли в пылу битвы с редактором хабра. Вернули, куда следует, спасибо за замечание!
                                    +1
                                    Блин.
                                    4 раза перечитал, так и не увидел сравнения производительности. Also, не увидел используемые цены на CPU, а у я.облака очень сильно по цене (и производительности) отличаются выделенные ядра и те, что с 5% гарантии.
                                      0
                                      У меня еще вопрос — абсолютно за кадром остался момент какие именно ВМ тестировали в Яндексе. Там есть две категории — по гарантии на ресурсы. Я не очень понял, что это значит (что-то вроде спотовых инстансов у Амазона?), но явно, что это как минимум влияет на цену. А в худшем случае — еще и на быстродействие.
                                        +1
                                        Привет! Мы тестили 100%-ные серваки.
                                          0
                                          Спот в Амазоне не про это.

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

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