Тестирование дисков облачных провайдеров

    После запуска в Скалакси новой системы хранения, мы выполнили миграцию на нее всех пользовательских данных со старой системы и решили сравнить скорость новой системы с существующими решениями на рынке. Под катом тест производительности систем хранения следующих облачных провайдеров: Amazon, Rackspace, Terremark, Скалакси, Селектел, Clodo.

    Для тех читателей, кто хочет сразу узнать результат не погружаясь в методику тестирования, резюме следующее: система хранения Скалакси — в целом наиболее производительная среди протестированных провайдеров, наихудшие же результаты показала система хранения Clodo.

    Ну а теперь подробнее.

    Выбор компаний


    Изначальный список компаний был следующим: Amazon, Rackspace, Terremark, Скалакси, Селектел, Clodo, Activecloud, VMco, IT-Grad vCloud, Slidebar.ru.

    Но, некоторые из них отвалились в силу следующих причин:

    Activecloud — отсутствие почасовой оплаты за ресурсы, что по нашему мнению является обязательным требованием.
    VMco и IT-Grad vCloud — российские представители платформы VMware и систем хранения NetApp, отсутствие почасовой оплаты и ручное создание машин.
    Slidebar.ru — облачный хостинг на платформе Microsoft Hyper-V, мы не смогли в течение недели установить здесь Linux, так как функция монтирования ISO образов не работала.

    Комментируем оставшихся.

    Скалакси — мы сами, IBRAID хранилище на шине Infiniband, решение на базе Xen.

    Иностранные:

    Amazon — лидер на мировом рынке cloud computing, задает планку остальным, тестировались максимально быстрые EBS диски (на которые все равно все жалуются, так как нагруженная БД на них работает с трудом), решение на базе Xen.
    Rackspace — также достаточно известный в мировых кругах хостер, который использует локальные диски в серверах, вместо сетевых хранилищ, решение на базе Xen.
    Terremark — достаточно крупная телекоммуникационная компания, главным отличием является платформа VMware и высокопроизводительные профессиональные системы хранения EMC.

    Честных российских облачных хостеров не так много, поэтому мы взяли их всех:

    Селектел — коллеги, работающие с iSCSI хранилищем, решение на базе Xen.
    Clodo — коллеги, работающие с первой версией нашей архитектуры 2008 года, IBM GPFS хранилище, решение на базе Xen.

    Методика тестирования


    Здесь мы конечно могли бы с помощью нашего коллеги расписать длинный и толстый матан, но ограничились более простым и практичным способом.

    У каждого провайдера, включая себя, мы создали три виртуальные машины с debian 6 (или ubuntu 10.10, в случае его отсутствия), дисками размером 15 ГБ и количеством оперативной памяти 512 МБ (исключение Amazon, их micro instance содержит 613 МБ), чтобы кэш в оперативной памяти не сильно влиял на результаты.

    На всех трех машинах мы одновременно запустили тестовый скрипт, который последовательно три раза подряд запускает iozone, признанного «убийцу» дисков, которого побаиваются и сами производители дисков. Запускали мы его со следующими параметрами: iozone -a -i0 -i1 -i2 -O -s8G, что означает выполнить тестирование на последовательные и случайные запись/чтение блоками данных от 4 КБ до 16 МБ на файле размером 8 ГБ.

    Далее результаты тестирования собирались, вносились и усреднялись в гугл-таблице. Таким образом каждый пункт теста выполнялся 9 раз (3 раза на каждой из 3 виртуальных машин). Исключение составил Clodo, в силу низкой производительности за неделю мы успели прогнать только 1 тест на каждой машине.

    Тесты были запущены в 12 часов дня, за несколько часов до пиковой загрузки по Москве. В целом тестирование в большинстве случаев длилось 2-3 суток.

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

    Отдельно стоит добавить, что в тестировании с нашей стороны участвовали две полностью заполненные реальными данными ноды нашего хранилища, полезной емкостью 20 ТБ и постоянной нагрузкой в 10 000 IOPS на чтение и запись, дабы не тестировать просто скорость сети и кэшей. Профиль клиентов — 90% веб-проекты малой и средней посещаемости (до 50000 уникальных посетителей в сутки). Об объемах и заполненности хранилищ других провайдеров мы можем судить лишь косвенно.

    Результаты


    Что бы изучить результаты более детально, мы предлагаем ознакомиться с публичным гугл-документом.

    А здесь статичные картинки с комментариями.

    В первую очередь произвольные чтение и запись. В соответствии с соображениями инженеров Intel стандартный профиль загрузки базы данных — 67% произвольных чтений, 33% произвольных записей блоками размером от 2 до 8 КБ. Вообще, реальные системы это в большинстве случаев произвольная запись и произвольное чтение, поэтому эти тесты самые важные.

    Стоить добавить, что обычный SATA диск выдает 120 произвольных IOPS (операций в секунду) на чтение и 60 произвольных IOPS на запись, SAS диск — 250 произвольных IOPS на чтение и 500 произвольных IOPS на запись (за счет кэширования записи).

    Произвольное чтение

    image

    Скалакси, Terremark и Селектел кэшируют данные, поэтому чтение у них в целом выше остальных. При этом Селектел использует 1 Гбит/с Ethernet, а Terremark и Скалакси, 8 Гбит/с FibreChannel и 40 Гбит/с Infiniband, соответственно. Clodo в теории тоже использует кэширование, но IBM GPFS на произвольном доступе аннигилирует все преимущество.

    При этом, очевидно, у Terremark, EMC или VMware какие-то проблемы с произвольным чтением малыми блоками.

    Произвольная запись

    image

    Кэшированная запись опять выводит в лидеры Скалакси, Terremark и Селектел. Amazon и Rackspace показывают максимально возможную скорость произвольной записи на массив SAS дисков. IBM GPFS у Clodo не предназначена для произвольных операций и показывает худшие результаты.

    Terremark в этом тесте в целом превзошел нашу систему хранения, но у нас сложилось впечатление, что узлы их системы хранения не полностью заняты и нагружены меньше.

    Последовательное чтение

    image

    В этом тесте Скалакси показывает лучшие результаты с устойчивыми 300 МБ/с за счет эффективности своей системы кэширования и алгоритма readahead, ближайший к нам по скорости Rackspace, показывает по сути скорость чтения с массива локальных дисков. Clodo встает в один ряд с остальными, так как GPFS кэширует данные на чтение и более-менее работает с последовательным чтением.

    Последовательная запись

    image

    И снова Terremark вырывается вперед. Значение Скалакси близки к результатам Rackspace, а именно последовательной записи на массив локальных дисков.

    Финальное резюме


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

    Terremark'у нужно потюнить настройки и все будет на высоте.

    Стратегия Amazon на сегодняшний день заключается в «количестве», а не в «качестве».

    Селектел — добротное решение на ethernet и iSCSI.

    Rackspace — локальные диски, что скажешь, но виртуальные сервера жестко привязаны к физическому серверу и любое изменение может вызвать длительную оффлайн миграцию.

    Clodo — слишком медленно, что бы использовать на реальных приложениях.

    Послесловие


    Продолжайте следить за нашим блогом и @твиттером, так как скоро:
    • отдельный шейпинг сети;
    • отдельный шейпинг для дисков;
    • VMware на базе Infiniband;
    • файловое хранилище;
    • и многое другое;
    • в том числе то, что вы предложите сами.

    Кроме того, как и всегда, неделя бесплатного тестирования при регистрации.
    Оверсан
    0.00
    Company
    Share post
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 127

      +6
      Он нас всех посчитал!
        0
        А можно промо код? :)
          0
          При регистрации на счёт автоматически начисляется 150 рублей без промокода.
          Этого достаточно, что протестировать все предоставляемые услуги.
            +2
            При регистрации и без промо кода денег дают. Примерно на неделю в минимальной конфигурации.
            +18
            Сами потестировали, сам заняли первое место :)
              0
              Сделали добротно, с учетом накопленного опыта и понимания особенностей облачных платформ, поэтому и результаты соответствующие.
                +9
                Судя по вашему описания системы хранения, ваш результат тестирования — это результат кэша 96 Гб на файловом сервере. У трех машин диски по 15 Гб целиком укладываются в этот кэш и за счет короткого времени проведения тестирования, все данные в этом кэше являются горячими.
                  0
                  Ключевой особенностью всех СХД является способ организации рейда и алгоритмы системы кэширования, диски-то все равно у всех одинаковые.

                  Данные являются горячими только для последовательных тестов. Время тестов с произвольным доступом на реально нагруженном хранилище показывает производительность системы в целом. А эти тесты ключевые.
                    +3
                    Вы выполнили последовательный тест и у вас все диски целиком осели в кэше. После этого произвольный доступ обращается уже к кэшу.
                      0
                      Нет. Алгоритм работы iozone следующий:

                      — последовательная запись;
                      — последовательное чтение (тут некоторая часть читается из кэша, так как реальные клиенты постоянно вытесняют своими данными);
                      — последовательная запись всего файла;
                      — последовательное чтение всего файла (за время двух последних тестов данные уже полностью вытесняются).
                        +4
                        за время двух последних тестов данные уже полностью вытесняются
                        Это вы так предполагаете и, скорее всего, ошибаетесь.
                        +1
                        С другой стороны, то, что у вас 96 Гб кэша в файлсервере, это дополнительная память в подарок всем клиентам — в среднем, несколько сотен Мб на каждую виртуальную машину. Конечно, этим кэшем больше всего пользуются VM с маленьким объемом памяти и интенсивным дисковым выводом — такие могут иметь постоянно занятую долю от этого кэша и несколько Гб.

                        В принципе, вы таким образом предоставляете очень хорошую возможность сокращения затрат для клиентов — держать самый минимальный размер оперативной памяти 512 Мб и свап где-нибудь на 8 или 16 Гб. Так как основная часть свапа находится в кэше на файл-сервере, это получается _очень быстрый_ свап. Интенсивность сваппинга в 100-200 Мб в секунду никаких ощутимых тормозов не дает.
                          0
                          иопсы то все равно платные?
                            0
                            У скалакси денег не стоят и, как было написано в посте, сейчас не лимитируются
                            0
                            Шейпинг выключен всего лишь временно =)
                              0
                              Даже если будет шейпинг 100 Мб/сек, это не страшно. Решает микросекундное время задержки сети и доступа к оперативной памяти вместо миллисекунд физического позиционирования головки на диске.
                                0
                                вы ничего не путаете? как раз сетевая задержка (между нодой и хранилищем) и доступ к памяти это микросекунды, а вот позиционирование головок диска это миллисекунды (механика все же..) и они ОЧЕНЬ решают.
                                  0
                                  ??? Я именно это и написал.
                                    0
                                    Вы написали что «Решает микросекундное время задержки сети и доступа к оперативной памяти», а я написал что «позиционирование головок диска это миллисекунды (механика все же..) и они ОЧЕНЬ решают» Или мы по-разному читаем…
                                      0
                                      Так и не пойму, с чем именно вы спорите. Если не трудно, распишите подробнее, не экономя на словах.
                                        0
                                        в вашем посте вы написали что важны задержки сети и доступа к памяти, я же написал что более важны задержки доступа к диску. но возможно вы просто описались или я неправильно понял ваш пост.
                                          0
                                          Думаю, вы неправильно понимаете.

                                          Мой коментарий о том, что важны задержки IO-операций, а не полоса, будь он 650 Мб/сек или 100. И уменьшение полосы не повлияет существенно на скорость работы свапа, если он весь осядет в кэше файлового сервера.
                  +3
                  Нежно слили всех конкурентов :)
                    +8
                    Все тормозят, один я — Д'Артаньян!
                    +9
                    «Сам себя не похвалишь — никто не похвалит.» ;)
                      0
                      Жаль нет VMco и IT-Grad vCloud, я бы почитал про реальную производительность хваленых СХД netapp.
                        +3
                        «реальную производительность хваленых СХД netapp» вы можете измерить только сами, и только их самих. Потому что способов убить производительность (любой системы хранения) существует десятки, и почем знать, какую из них выбрала данная конкретная компания.

                        ЗЫ. Ну по поводу самого поста тут уже многие высказались, не стану добавлять ;)
                          0
                          Зачем заранее боятся, что Netapp проиграет. Вот бы и увидели, как убили кривыми конфигами СХД. Или наоборот, как настоящий филер порвал бы решения почти на коленке от Селектела.
                            +7
                            Я не понимаю, почему использование IETD должно считаться «решением на колене». (обиделся)
                              0
                              Да я то не считаю, что решение Скалакси наколеночное, один Infiniband внушает. Просто вендоры СХД, при словах «мы построили СХД на linux, iscsi, SCST, md итд» криво как-то усмехаются. Не ынтерпрайз не решение.
                                +3
                                вендоры усмехаются, потому, что им не удалось впарить тебе то же самое, но в 10 раз дороже. вот и троллят :)
                                  +5
                                  Ага, ага, производители железа всегда усмехаются при упоминании софтых опенсорсных решений. Adaptec тоже усмехался, пока ему:

                                  а) не показали
                                  365883.382007] aacraid: SCSI bus appears hung
                                  [366011.032227] IRQ 26/aacraid: IRQF_DISABLED is not guaranteed on shared IRQs
                                  [453360.987916] aacraid: Host adapter abort request (0,0,0,0)
                                  [453360.988057] aacraid: Host adapter reset request. SCSI hang ?
                                  [453415.926534] aacraid: Host adapter abort request (0,0,0,0)
                                  [453415.926659] aacraid: Host adapter reset request. SCSI hang ?
                                  [453471.815273] aacraid: Host adapter abort request (0,0,0,0)
                                  [453471.815398] aacraid: Host adapter reset request. SCSI hang ?
                                  [453527.703998] aacraid: Host adapter abort request (0,0,0,0)
                                  [453527.704124] aacraid: Host adapter reset request. SCSI hang ?
                                  [453583.592740] aacraid: Host adapter abort request (0,0,0,0)
                                  [453583.592865] aacraid: Host adapter reset request. SCSI hang ?
                                  [453639.481478] aacraid: Host adapter abort request (0,0,0,0)
                                  [453639.481602] aacraid: Host adapter reset request. SCSI hang ?
                                  [453649.465609] sd 0:0:0:0: [sda] Unhandled error code
                                  [453649.465612] sd 0:0:0:0: [sda] Result: hostbyte=DID_OK driverbyte=DRIVER_TIMEOUT
                                  [453649.465616] sd 0:0:0:0: [sda] CDB: Write(10): 2a 00 3d e4 18 28 00 00 08 00
                                  [453649.465625] end_request: I/O error, dev sda, sector 1038358568
                                  [453649.465659] Buffer I/O error on device sda1, logical block 129794565
                                  [453649.465688] lost page write due to I/O error on sda1
                                  

                                  б) не спросили как сделать тройной raid1.

                                  С остальными вендорами ровно так же. У них никакие не волшебные диски, у них внутри всего лишь софт для управления операциями на диски. Софт, на который мы не можем влиять. В отличие от опенсорса, который можно и поправить, и пересобрать под задачу.
                                    +4
                                    Только к опенсорсу нужно прикладывать и amarao в комплекте. :)
                                      +3
                                      Гм… к netapp тоже надо прикладывать, multagor например.
                                        +2
                                        Дима, благодарю за комплимент :)
                                        +3
                                        нет, нужно прикладывать толковых спецов.

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

                                        Я помню, на курсах адаптека обсуждались idiot's case, там много рассказывали. Толковые спецы нужны в любом случае (хотя бы, чтобы выбрать правильного вендора и конфиг под задачу). А если спецы есть, нафига нам люди, которые хотят много денег за то, что и так есть в опенсорсе (я в курсе про фичи нетаппа).

                                        Главная же проблема с любым вендором — нельзя посмотреть «как оно работает». Когда у меня были проблемы с XCP, я посмотрел сырцы. И сделал с учётом того, что там написано, а не того, что написано в документации.

                                        Наша окончательная позиция — мы работаем без вендорлока.
                                          0
                                          Да, только в случае «вендора» это shared специалист (называется tech support), а в случае «опенсорса» — dedicated.

                                          И «дешевизна» опенсорса компенсируется затратами на оплату знаний такого «дедика» ;)
                                            +4
                                            тобишь для обслуживания СХД вендора «дедик» не нужен? Достаточно суппорта? Или оплачивать знания схд-админа уже не нужно, обучение того же netapp схд админа далеко не дешевое занятие. И если честно я дико сомневаюсь в том, что схд-админ+обучение_оного+платная_техподдержка будет сильно дешевле и качественней, чем ЗП того же amarao.
                                              +1
                                              Я знаю совсем не одну компанию, которая обходится при обслуживании системы хранения «сисадмином общей практики», не выделенным на эту задачу, а занимающегося всем подряд в организации, в пределах своего подразделения.

                                              Более того, это — нормально.
                                              Возможно пока это диковинно в России, но в мире как раз держать на зарплате админа в конторе на 15-30-50 рабочих мест — вот это диковина и типичное «русское расточительство».

                                              Использовать аутсорсного админа (и вендорский саппорт для решения специфических проблем конкретного оборудования), совсем не являющегося гуру в тематике вашей компании — это повседневный быт IT-отделов.

                                              Это совершенно точно дешевле, чем найм специализированного человека, и дальнейший «вендорлок» на него, сколь бы ни был он сам замечательный специалист и человек.
                                              0
                                              Нет, извините, техсаппорт вменяемого спеца в штате не заменяет.

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

                                              Техсаппорт полезен, но мой опыт показывает, что никто из них не может сказать что-то новое и важное по сравнению с common knowledge.

                                              Более того, мир вокруг меняется с такой скоростью, что данные годовалой давности уже не совсем точны, двухлетней устарели, а трёхлетней — ахинея. Особенно, в области сочетания виртуализации и технологий линукса.
                                                +3
                                                Дело не в этом. А в том, что люди, которые пропагандируют «опенсорс» часто, намеренно ли, случайно ли, забывают, что к такому «бесплатному» решению, «без вендорлока», должен прилагаться специалист с зарплатой куда выше среднерыночной. И без него, случись что, все встанет.
                                                Что такого специалиста и затраты на него нужно (равно как и все риски с этим связанные) учитывать в бизнесплане.

                                                Вот будьте честны, вот случилось так, что у вас внезапно возникла необходимость срочно выйти «из бизнеса», допусти на полгода-год. Вот прямо завтра. Ну мало ли. В больницу попали, семейные проблемы. Просто внезапная смена ориентиров в жизни. Всякое бывает.
                                                Сможет ли ваша компания продолжить жизнь без вас?
                                                Вот только если честно?
                                                Весь тот объем вашей ежедневной работы и знаний специфики решения можно передать завтра же свеженанятому специалисту?

                                                В хорошей организации «от вендора» — можно. (и не только «можно» — нужно!) А в вашем случае?

                                                Не кажется ли вам, что в вашем случае, вы, избавившись от «вендорлока» разных производителей железа и софта, получили вендорлок на своеобразного «вендора» по имени amarao?
                                                  +1
                                                  Во-первых, всё-таки нетактично в споре съезжать на личности.
                                                  Во-вторых, «вендорлок» на толкового специалиста лучше, чем на производителя — они, хоть под ногами и не валяются, но всё же заменяемы. В отличие от. Иначе можно дойти до «писать свой софт нельзя, вдруг программист, его писавший, заболеет».
                                                  В-третьих, люди надёжнее железа :)
                                                    +1
                                                    Ну если amarao сочтет себя оскорбленным таким «переходом на личности», то он сам скажет, не надо его защищать, он сам на кого хошь наедет себя защитит.

                                                    «Вендорлок» на конкретного человека _всегда_ хуже, чем на организацию, с которой возможны договорные обязательства, и которая несет за них юрответственность.
                                                    Потому что вот я уже выше пример привел. Идет вечером этот специалист домой, а навстречу — гопники. Результат — полгода в больнице. Реальный случай, кстати.
                                                    А в конторе все, оказывается, завязано на этого специалиста. Даже пароли от половины всех аккаунтов, админок и консолей — у него в голове, а он — в коме. И привет. Пишите письма.

                                                    Оказалось, что в конторе, так сильно озабоченной отсутствием «единой точки отказа» в оборудовании, самая главная «точка отказа» была на виду. Выяснилось, что случись что с одним человеком — и все, контора на грани остановки и попадания на большие деньги.

                                                    Думаете уникальный случай? Увы, нет.
                                                      0
                                                      Может быть, не нужно передёргивать? Пример, который вы привели («пароли в голове, голова в коме») — относится к неправильному случаю использования людских ресурсов, который вы пытаетесь сравнить с гипотетическим правильным случаем использования привязанного к вендору оборудования. Кроме того, при отказе маршрутизатора сеть падает; если же нормальный админ заболеет, ничего не упадёт.
                                                        0
                                                        Не уникальный. Потому-то у нас и сделано так, что все в команде (пусть хуже), но умеют делать всё, что делают другие.

                                                        Я более-менее ориентируюсь во всём, что наваяли наши спецы, они кое-как, но способны управляться с сервером и знают потроха xapi примерно как я (они его мучают с точки зрения XenAPI, я с точки зрения падучести deadbeef'овости).

                                                        Вопрос наличия или нет вендорлока на специалиста — вопрос производственной архитектуры, а не решения 'netapp или нет'. С netapp'ом ровно так же можно накрутить столько, что мало не покажется.
                                                      0
                                                      Вендорлок по имени amarao есть, разумеется. Но помимо amarao на свете есть ещё куча документации по lvm, iscsi, drbd, xen'у, xapi и т.д. Таким образом, смена специалиста, конечно, приведёт к проблемам с изучением того, как работает архитектура.

                                                      Но… Рассмотрим сценарий, в котором мы заменили связку lvm, drbd и iscsi на netapp с iscsi.

                                                      Вопрос: если amarao, обратившийся в веру netapp'а уйдёт, то решится ли проблема изучения всей архитектуры? Не думаю.

                                                      А проблема хранилища? Да сейчас конфиги iscsi и lvm вместе меньше 10кб в размере, из которых примерно половина — тривиально-очевидны. Их изучение по обширнейней документации — дело двух недель для любого спеца моего уровня и день-два для человека с большим уровнем. Изучение netapp'а в этом смысле ничем не лучше и не хуже, чем изучение iscsi (благо, у iscsi и опций-то меньше). А знание LVM у линуксоида как-бы подразумевается.

                                                      Если же вы хотите сказать, что купив netapp можно уволить квалифицированного специалиста и нанять таджика…

                                                      Скажите, вы это готовы сказать? «Решения netapp не требюет наличия в штате квалифицированного персонала, так как наш саппорт решает за клиента все проблемы, связанные с хранилищем, его конфигурацией и интеграцией в используемые системы». Так?
                                        +7
                                        Дело не в «заранее бояться».
                                        Дело в том, что тестирование «ни о чем».
                                        Вернее о том, что правильная методика — рулит. :)

                                        А так получается тестирование скорости автомобилей разных марок, выйдя на улицу, и с секундомером замерив скорость десятка проехавших мимо автомобилей, а затем делая глубокомысленные выводы на основе результатов: «А смотри ка, ВАЗ-классика-то — самый быстрый!» А он может быстрый, потому что вам попалось два подряд джихад-такси, которым пофиг на правила :)

                                        Это в случае самого Оверсана можно быть уверенным, что предоставлена максимальная производительность дисков, но отчего авторы решили, что какой-нибудь Amazon дает вот такой вот созданному «с улицы» инстансу вот прямо сразу всю производительность имеющихся у него дисков?
                                        Есть QoS, он, конечно же, у правильных сервисов, используется.
                                        Так что я думаю, что измерялся скорее порог дискового QoS «по умолчанию», а не «производительность дисков»

                                        Ну и в завершение темы:
                                        Rackspace использует NetApp с 2009 года. Я не могу гарантировать, что данные при создании первой же клиентской машины сразу окажутся на NetApp, контора там большая и сложная, и разных сервисов, в том числе и уровней использования много.
                                        Но тем не менее:

                                        Rackspace:
                                        «Rackspace relies on NetApp storage and data management technology for a variety of hosting options. NetApp is a key component in powering The Rackspace Cloud, our cloud division. With NetApp we can create a virtual, shared, and dynamic infrastructure with extremely high utilization. This allows us to provide industry-leading cost efficiencies to our customers. Rackspace also uses NetApp to provide Dedicated NAS services to Enterprise Managed Hosting customers seeking a dedicated file storage and data protection solution.»
                                        — John Engates, chief technology officer for Rackspace
                                        www.netapp.com/us/company/news/news-rel-20090825-cloud-partners.html
                                          0
                                          Я бы сказал, что это не тестирование авто, кто быстрей. А тестирование гостиниц. Вы клиент с улицы, то как вас быстро заселили показатель производительности персонала. Как клиенту в этих победили гостиницы Скалакси, terremark, rackspace.
                                            +3
                                            Вы конечно можете считать как вам угодно, моя задача только показать на дефектность методики, сводящая ценность результатов к нулю (всех, за исключением результатов самого Оверсана, возможно).

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

                                              Иначе в чем смысл тестирования.
                                                0
                                                Вот и я то же спрашиваю, в чем смысл? ;)
                                      0
                                      Кстати, да.
                                      Критерий отсева весьма странный: вы если техническую производительность тестируете, то какая разница по каким принципам происходят ее продажи?
                                        +6
                                        Мы тестируем облачных провайдеров, и, в соответствии с нашими представлениями и стандартом NIST, таковыми не являются компании где виртуальные машины создаются вручную системными администраторами.
                                      +3
                                      Хочется комментариев от amarao и damad, если честно (:
                                        +3
                                        А сколько активных клиентов было на сторадже Скалакси при тестировании?
                                          +4
                                          Как я уже сказал тестируемые VM работали на полностью заполненных узлах емкостью в 40 ТБ. Количество активных VM на этот объем — около тысячи.
                                          +6
                                          Ждем ответа от Clodo
                                            +3
                                            Вот наш ответ:


                                            Часть клиентов уже использует…
                                            Подробности скоро…
                                              0
                                              Часть

                                              Ключевое.

                                              Графики впечатляют, ждем подробностей.
                                              Остальные данные из изначального поста взяты, или всё своё?
                                                0
                                                Часть — действительно ключевое слово. Позже подробности. Все данные (кроме наших) из архива по ссылке в статье.
                                                0
                                                Коллеги, ключевой параметр в тестировании — нагруженное и заполненное хранилище. На пустых нодах произвольная запись у нас и поболее — на 4k под 100k IOPS, как и у терремарка.
                                                  +1
                                                  Я где то написал, что мы проводили тестирование на пустом хранилище? Около 400 клиентских ВМ + тестовых для генерации нагрузки столько же. Создали постоянную нагрузку около 10000 IOPS и тестировали. Правда, так же как и вы, временно отключили шейпинг.
                                              +12
                                              Не из-за этого ли теста вчера днём вы упали?
                                                +1
                                                Вчера днем мы не падали, часть клиентов испытывала задержки в сети в следствии начавшейся было DDoS-атаки, с которой мы справились.
                                                  0
                                                  Понятно. Мне повезло попасть в эту часть клиентов. Спасибо за ответ :)
                                                +8
                                                Если вы так уверены в себе, почему не заказали независимое тестирование?
                                                А так-объективность весьма сомнительная, чистый PR…
                                                  +5
                                                  Мы с удовольствием снабдим вас необходимыми ресурсами, если вы захотите объективно повторить подобный тест.
                                                    0
                                                    За предложение оплатить мне тестирование Amazon, Rackspace итд Спасибо! Наверно денег у вас и вправду много.)
                                                    А если серьезно.Если бы такой тест проводила независимая компания, даже по вашему заказу, доверия к его результатам было бы гораздо больше.
                                                      0
                                                      Это же облака и почасовая оплата, денег не много нужно.
                                                  +10
                                                  (от имени Селектела).

                                                  SAN у нас работает на 10G, а не на гигабите. У нас используется шейпинг (чтобы один клиент, решивший поиграться с iozone/bonnie++ не создал затруднений соседям). Шейпинг работает чуть дальше кеша (то есть вы сможете получить неожиданные пики по чтению/записи, но не сможете нагрузить нашу дисковую подсистему насмерть). Плюс, мы используем intellicache.

                                                  Ваши тесты меня очень озадачили, вы сильно увеличили нагрузку. График загрузки дисков (график уже после кеша, то, что кеш пробило):

                                                  Selectel disk load during IOZone test
                                                    0
                                                    тобишь по рукам клиенту не успели дать за такие iops'ы?
                                                      +1
                                                      зачем по рукам? чем больше клиент генерит иопсов, тем больше он их покупает. :)
                                                      вопрос только в том, что бы один плохой не мешал соседям с диском работать.
                                                        +4
                                                        Зачэм быт да? Лучше болше хади болше дэнга плати.

                                                        Ради этого и задумывалось — для нас нет плохих клиентов (кроме спамеров и т.д.) — что бы клиент в машине не вытворял, мы с этого деньги получим.

                                                        Взмен, клиенты, которые делают по 1к операций в день спокойно лежат и не платят лишнего.
                                                        0
                                                        Для уточнения, что есть до кеша, а то после — с какой стороны смотрите на кеш? «до кеша» — это ближе к дисками или ближе к вм-кам?
                                                          0
                                                          У нас несколько уровней кеширования — intellicache (локальный на хосте), кеш уровня iscsi, кеш уровня рейда. График показывает иопсы, прошедшие на рейд. Сколько из них прошло на диск я сказать не могу.
                                                        +9
                                                        Да, наоборот, шейпинг в облаке обязан быть. Я имея там виртуалку, совсем бы не хотел, что бы меня тормозили например ваши тесты. Пусть лучше вас ограничат в полосе, но у меня латентность дисковых операций не изменится.
                                                        Так что пока тесты не совсем адекватны, вы видите то, что происходит с высоконагружающей систему виртуалкой, но не видите, на сколько это влияет на соседей. Если получили рекордный иопс, но все соседи тормозили по страшному — то нафиг такой хостинг. А если получили умеренный, но соседи даже не почесались — вот это хорошее решение.
                                                          +1
                                                          Латентность изменится, увы, контролировать это сложно, но у нас есть некие рамки, которые мы более-менее можем сдерживать (то есть можно запросто получить 10мс вместо 2мс из-за засранца рядом). Увы, технологии контроля дисков только-только развиваются, и точного представления что с этим делать пока нет.

                                                          Какие-то наброски (идеи) есть, но в жизнь мы их пока не закодировали.
                                                            0
                                                            Мы написали, что шейпинг временно выключен и включится, когда мы сделаем отдельно регулируемую ширину канала для каждого диска.
                                                              +5
                                                              выключен он у вас (то есть в этот момент 1. можно было получить всю полосу 2. затормозить соседние виртуалки).
                                                              а включен (если есть) у других тестируемых участников он или нет — вы не знаете.

                                                              то есть у себя вы лимиты сняли и показали рекордный иопс, а что и как настроено у остальных — неизвестно. по этому обзор бессмысленный.
                                                                +2
                                                                ну не совсем бессмысленный — клиенты хоть знают, чего ждать…
                                                                  0
                                                                  а чего ждать от включения шейпинга у скалакси? может он после этого скатится в самый низ графика?
                                                                    +2
                                                                    После этого сколько купите, столько и будет. При это уровень гарантии будет на порядки выше остальных провайдеров.
                                                                      0
                                                                      я могу купить все, и увеличить латентность диска для всех соседей?
                                                                        +10
                                                                        Если вы купите все, мы сделаем для вас отдельный кластер, а курьером, который привезет вам договор будет Анджелина Джоли или любое другое существо по вашему выбору.

                                                                        На механических дисках — да, есть вероятность, что латентность у соседей по диску увеличится. На SSD соседи ничего не заметят. SSD дисков правда уже нет в панели, так как весь объем давно продан, но в будущем опять появятся.
                                                                          +1
                                                                          Так огласите сколько у вас стоит «купить всё». На Анджелину Джоли пол-хабра скинется. Ну или на Сашу Грей, коль уж вы кого-угодно обещаете. :)
                                                                  +2
                                                                  Еще раз повторю, в облачных СХД самое главное — производительность произвольных операций чтения и записи. Шейпить эти операции отдельно от последовательных никто не умеет — 100%. Ну а так как у всех провайдеров произвольные тесты сильно отличаются от последовательных, то значит на результат первых никакой шейпинг не влияет и они зависят только от общей производительности системы.

                                                                  Ну а поскольку основной профиль нагрузки интернет-проектов — произвольные операции в БД или с мелкими файлами, наша система очень хорошо решает эти задачи.
                                                              –4
                                                              Как по мне, так активная и бросающаяся в глаза антиреклама.
                                                                –1
                                                                Антиреклама Скалакси прежде всего. До сих пор мне как-то они казались более «вменяемыми» и понимающими предмет. :(

                                                                Но выкатывать на хабр такую шитую белыми нитками заказуху… Причем лучше бы если бы это была заказуха, потому что если люди в самом деле верят в то, что они «намеряли», вот в таком случае все куда хуже.
                                                                +1
                                                                Простите за глупость, но помогите разобраться, как вы получили итоговую таблицу данных? Помогите на примере:

                                                                screenlog.scalaxy.1:

                                                                  +3
                                                                  Случайно рано промахнулся кнопкой…

                                                                  screenlog.scalaxy.1:
                                                                  8388608 4 35733 26702 40831 35005 2038 14105
                                                                  8388608 4 77614 49849 78251 76950 3560 18524
                                                                  8388608 4 67363 34573 57054 61127 3115 20614
                                                                  screenlog.scalaxy.2:
                                                                  8388608 4 74578 27050 51325 64362 3197 10534
                                                                  8388608 4 67450 39465 69858 74963 3479 10003
                                                                  8388608 4 52392 28300 69194 62910 3364 7827
                                                                  screenlog.scalaxy.3:
                                                                  8388608 4 75524 31947 82384 77260 3511 8342
                                                                  8388608 4 59282 34287 93289 92944 3839 6957
                                                                  8388608 4 85223 39246 95587 89991 3771 12086

                                                                  Как из этих исходных данных вы получили те данные, которые у вас в гугл-таблице?
                                                                    0
                                                                    Для сравнения, вот данные с hetzner eq8:
                                                                    8388608 4 41963 38170 1514434 1525684 1004891 1847
                                                                      0
                                                                      Судя по 1514434, количество RAM на этой виртуалке много больше 512 МБ. Перечитайте методику теста.
                                                                        0
                                                                        Зная о eq8 то 24 GB DDR3 RAM
                                                                        К стати почему именно 512 у вас?
                                                                          0
                                                                          При объеме файла в тесте 15 ГБ он полностью укладывается в оперативную память виртуальной машины (24 ГБ в случае eq8), и тогда тест чтения показывает скорость чтения из оперативной памяти, а не из системы хранения.

                                                                          512 МБ мы выбрали как минимальный размер доступный у большинства провайдеров, чтобы память не влияла на тесты чтения.
                                                                          0
                                                                          Да, к сожалению забыл про это. Действительно, у hetzner всего 24GB. Но если всё пересчитать на деньги, то у вас за аналогичную стоимость будет 3.5GB. Во сколько раз, примерно, увеличатся исходные показатели из ваших тестов на 512MB?
                                                                        0
                                                                        Очень просто, берем столбцы 3 (линейная запись), 5 (линейное чтение), 6 (произвольная запись), 7 (произвольное чтение) и передаем функции AVERAGE в Google spreadsheets.
                                                                      +8
                                                                      Мне, эти «тесты», напоминают тесты от Microsoft, в котором IE9 всегда впереди. Хотя, вроде все правильно и наглядно.
                                                                        +4
                                                                        Ну-у-у, зайдите на блог EMC — там EMC впереди планеты всей и плевали они на всех с высокой колокольни. На блогах netapp — вам расскажут, что вы заплатите меньше получите больше, уникальный WAFL, супербыстрый flashcache и огого-и-эгегей. На мероприятии HP вам расскажут, что дескать мы уже порвали почти всех, винты у нас быстрее, кешы больше, фибра фибрастей и надо брать. Маркетинг. Он как религия.
                                                                        +9
                                                                        «слишком медленно, что бы использовать на реальных приложениях» — вы бы, коллеги, сначала спросили у реальных приложений. Это раз.

                                                                        Плюс к тому — небольшой логический реверанс: «коллеги, работающие с первой версией нашей архитектуры 2008 года» + «слишком медленно, что бы использовать на реальных приложениях» == «мы были неюзабельными и водили за нос клиентов, пока нас не клюнул жареный петух, и мы не поменяли архитектуру». Мы ценим ваше качественное развитие, скоро и у нас, что тут скрывать, ожидается обновление СХД. Но такие категоричные выводы вам совершенно не идут.

                                                                        Тем более, что есть разные методики тестирования и результаты какой из них говорят о реальных ощущениях клиента — это большой вопрос. Ну и еще один вопрос — это самочувствие клиентов-соседей при проведении тестов.
                                                                          +6
                                                                          Чувствую «топор войны» откопали-будем ждать «тестов Скалакси» от Селектел и Clodo.)
                                                                            +1
                                                                            Ага, нагрузка на все хранилище уже выросла в 6 раз с момента публикации поста.
                                                                              +1
                                                                              Черный Властелин атакует хранилище!
                                                                                0
                                                                                Ну и как? 300МБ/с держите?
                                                                                  0
                                                                                  300Мегабайт в секунду — это примерно три гигабита.

                                                                                  SAS-порт даёт шесть гигабит, тобишь держит на заявленных 300МБ/сек две виртуальные машинки. Ещё один SAS-порт держит те-же самые две машинки во второй половинке зеркала.

                                                                                  То-есть, чтобы держать 300Мб/сек. на тысяче, даже не клиентов, а виртуальных машин, без учёта кэширования, и с учётом зеркалирования, необходимо иметь:

                                                                                  500 SAS портов X 2 половинки зеркала == 1000 SAS-портов.
                                                                                  То-есть по одному SAS-порту на каждую виртуальную машину?
                                                                                    –1
                                                                                    МБ/с-единицы измерения на волшебных графиках(скорость чтения/записи), у автора поста!!!
                                                                                –2
                                                                                Честно говоря, лучший ответ на «наброс на вентилятор» — игнор.
                                                                                  +7
                                                                                  Нет, я не планирую меряться пиписьками. Собрать охрененно быстрое хранилище можно — его будет невозможно окупить. Основной момент — обеспечить требуемую производительность в разумные деньги и при этом ещё не потерять надёжность.
                                                                                  –12
                                                                                  А ты провел тестирование СХД конкурентов?
                                                                                    –6
                                                                                    бойдесь, блейды, он идет?!? ))
                                                                                    +1
                                                                                    Когда-то на Хабре пробегал такой слайд- «Есть ложь, наглая ложь и есть бенчмарки».

                                                                                    А по сути — мне просто интересно ЗАЧЕМ вбухали столько бабла а стореджи, интерконнект и IOPS'ы??
                                                                                    Дайте клиентам много дешевого RAM и guestOS сами накешат то что нужно.
                                                                                      +1
                                                                                      Не всё, увы. В рамках той теории, которую мы используем, есть т.н. «злые иопсы», которые в любом случае пройдут на самый низкий уровень хранения через все кеши.
                                                                                        +1
                                                                                        Какой процент «злых иопсов» в общем? Большинство клиентов держат web и небольшые db которые влазят в RAM. Но у вас RAM дорогой — поэтому берут 512 MB и засовуют в него систему и 2 гига db, что чревато нагрузкой на СХД.

                                                                                        Среди тех кому действительно нужно много IO — те кто криво настроил os и db или те у кого бизнес-логика на уровне db(но такие не юзают общественные cloud'ы).
                                                                                          0
                                                                                          У большинства проектов >20k уникальных посетителей в месяц БД в память не влазит, а диски являются самым узким местом.
                                                                                            0
                                                                                            >20к посетилелей в месяц и БД в память не влазит

                                                                                            ГМ, а сколько памяти в «большинства проектов», что при 700 хостах в день у них БД туда не влазит?

                                                                                            0
                                                                                            Любое уникальное чтение является «злым». До тех пор, пока у нас кеш меньше устройства хранения, то злые иопсы будут всегда. Даже запись можно закешировать (у нас intellicache на графике хорошо видно — записи много меньше, чем чтения), а вот рандомное первое чтение — нет.
                                                                                        0
                                                                                        Я недавно занимался переносом одного мелкого торент трекера с посещаемостью около 25к уников в день. Перенос осуществляли с hetzner eq8 на самосборный сервер, в который воткнули ssd и 12GB DDR3. MySQL база трекера занимает всего 3GB и легко уместилась в памяти. Установлен nginx (gzip,aio) + php-fpm (mysqli,apc), что позволило достичь отсутствие fail на ab -n 10000 -c 1000. К сожалению, в час пик уже не хватает мощности сервера. В связи с чем, ищем подходящую площадку. В данный момент расходы на сервер не превышают 3000р/месяц. Возможно ли имея такие исходные данные, захоститься у вас по аналогичной стоимости и получиться отсутствие 502 Bad Gateway в час пик?

                                                                                        Думал отправить в ЛС, но вдруг кто-нибудь другой подскажет, что лучше сделать в этой ситуации?
                                                                                          +1
                                                                                          При таких нагрузках долго масштабировать в лоб, вертикально, не получится. как минимум придется переходить к настоящему FastCGI и накапливать данные для обновлением пачкой за один запрос. Но рано или поздно придется трекер переписывать в самостоятельный постоянно работающий демон для нормального кэширования данных и минимизации обращений к внешней БД.

                                                                                          И да, посещаемость в униках для трекера не показательна, интереснее максимальное(пиковое) суммарное число активных торрентов по всем пользователям и время между анонсами.
                                                                                            0
                                                                                            Посещаемость, которую я указал выше — это данные из Google Analytics. Т.е. это статистика только по «главной страничке форума». А обычная статистика с анонсера такая: пиров >600к, раздающих >400к, скачивающих >150к. В дни, когда какая-нибудь «новинка» то +10-20%.

                                                                                            Думаете, всё-таки нужно начинать оптимизировать программную часть самого форума и анонсера?
                                                                                              0
                                                                                              Лично мое мнение — да. Даже если предположить довольно скромное время анонса 30 минут, получается около 350 запросов в секунду к трекеру, что выливается в 1-2 миллиона запросов в секунду к базе данных в зависимости от удачности архитектуры — это уже большая нагрузка, особенно учитывая что примерно половина запросов это запись.
                                                                                              Вообще, если база полностью в памяти — не совсем понятно, зачем вам SSD.

                                                                                              Для справки — трекер nnm-club(на C++) работает в 1 поток и потребляет меньше 1GB памяти.
                                                                                                0
                                                                                                Время анонса 30 минут. Запросов в секунду в обычном режиме около 450, в пике доходило до 800. На SSD OCZ Agility-2 файлы форума. А по софту — используем всем известный ppkbb3cker с оригинальным анонсером, который, по хорошему, надо заменить на xbtt.

                                                                                                Вообщем ясно. Будем значит оптимизировать программную часть. Спасибо.
                                                                                          +5
                                                                                          Они убили Кенни Clodo…
                                                                                            +12
                                                                                            Clodo — коллеги, работающие с первой версией нашей архитектуры 2008 года, IBM GPFS хранилище, решение на базе Xen.
                                                                                            Какой тонкий троллинг =)
                                                                                              +2
                                                                                              Вопрос к автору исследований.

                                                                                              Вот это ваше кеширование как отражается на целостности данных? К примеру, произведена транзакция и сервер кеширования падает. Транзакция на диске не запечатлена — только в ОЗУ на сервере кеширования? Получается нет гарантии целостности данных?
                                                                                                +1
                                                                                                Данные всегда сохраняются как минимум на два узла. Подробнее об этом можете прочитать в позапрошлой публикации нашего блога.
                                                                                                +1
                                                                                                Скорости не так интересны как средние/максимальные задержки случайного чтения/записи, так как именно они влияют на скорость формирования страниц и отзывчивость сайта в целом. Очень странно что вы их не указали…
                                                                                                  0
                                                                                                  Согласен, но это более ресурсоемкий тест. У нас самих на него ресурсы врядли найдутся, все же надо фичи выпускать.
                                                                                                  0
                                                                                                  Вводная информация не точна. IT-GRAD предлагает почасовую тарификацию (pay-as-you-go). Кроме того интерфейс vCloud позволяет самостоятельно создавать машины без обращений в службу поддержки + есть развитый API.
                                                                                                  А если говорить про сам топик — тестирование производительности дисковой подсистемы — то в нашем SLA содержатся специальные метрики — max Latency и min IOPS, которые могут быть оптимизированы под конкретных корпоративных заказчиков.

                                                                                                  Only users with full accounts can post comments. Log in, please.