Сравнительный анализ производительности дисковых подсистем серверов с применением SSD. Часть II

    В тестовой лаборатории DEPO Computers продолжаются исследования производительности дисковых подсистем в серверах. Первая часть доступна по ссылке.

    В обсуждении предыдущих наших публикаций про SSD многие откликнувшиеся жаловались на низкий ресурс записи SSD MLC, который и являлся основным ограничением по применению. Это действительно так, в SSD MLC предыдущего поколения ресурс записи был на уровне 5-30ТБ, что может быть достаточно для десктопов, но крайне мало для серверов.

    В настоящем обзоре мы приводим результаты тестирования новых SSD накопителей Intel 710, имеющих ресурс записи (в зависимости от модели) от 600 до 1500ТБ, что вполне достаточно для большинства приложений.


    Тестировались SSD Intel 710 серии емкостью 100G в следующих конфигурациях:

    1. в RAID1 на контроллере LSI 9260 с включенной и выключенной опцией FASTPAth
    2. в RAID1 на контроллере ICH10R
    3. в качестве кэша контроллера LSI 9260 в RAID1 на чтение/запись (основной массив на контроллере сделать RAID5 на дисках SAS, (4 диска SAS Seagate ST3300657SS 15K в RAID5))


    Измерения проводились с помощью программы IOmeter, шкала по горизонтали – производительность MB/c, по вертикали – данные для потокового и случайного чтения, потоковой и случайной записи для блоков разного размера.



    (Указана производительность в MB/c)



    Основные выводы


    По RAID1: при выборе контроллера при конфигурации RAID1 разумнее всего использовать простой onboard Intel контроллер, т. к:

    1. Технология FastPath в LSI не дает ни какого прироста при использовании всего двух SSD, тем более в RAID1.
    2. По тестам видно, что на интегрированном Intel контроллере скорость даже немного больше (хотя при тестах SSD замеры скорости субъективны, из-за внутренних алгоритмов SSD, но факт остается фактом).
    3. Цена LSI 9260 не соразмерна с со стоимостью интегрированного контроллера Intel. Это высокопроизводительный кэш-контроллер с поддержкой разных типов RAID, в том числе и 6, понятно, что использовать его только как RAID1 контроллер экономически нецелесообразно, его собственный кэш при подключении SSD значительного выигрыша не дает.

    По использованию технологии LSI CacheCade 2.0 (кэширование при чтении и записи с использованием SSD): при использовании SSD на LSI 9260 в виде кэша для тома из SAS дисков были получены очень хорошие результаты.

    1. Можно собрать SSD в RAID1(большая отказоустойчивость) или RAID0(большая скорость).
    2. Помимо READ Cache, работает WRITE Cache (и, по результатам тестирования, работает очень неплохо).
    3. Алгоритм CacheCade 2.0 отточен и все работает достаточно быстро по сравнению с первой версией.

    Т. к. ресурс записи 600-1500ТБ достаточен для большинства приложений в серверах, мы планируем использовать диски Intel SSD 710-й серии в новых моделях DEPO Storm 3350 на процессорах Intel Xeon E5-2600, поставки которых начнутся с мая 2012г.

    senko,
    ведущий менеджер по продукции DEPO Computers
    DEPO Computers
    88,00
    Компания
    Поделиться публикацией

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

      +2
      Простите за глупый вопрос: а как сейчас дела с TRIM обстоят в RAID0 и 1?
      Я что-то слышал про Intel RST 11.5, но на практике-то как?
        +3
        Спасибо за вопрос, TRIM в накопителях Intel 710 поддерживается, для ответа про поддержку Intel RST 11.5 надо немного больше времени
          –2
          Когда ж вы научитесь не мегабайты а иопсы мерить, а? Вы сами-то из этих цифр что-то понимаете?
            +5
            iops'ы в общем случае тоже никого не волнуют. Что лучше — система, которая выдаёт 2к IOPS при latency в 1мс или система, которая выдаёт 20к IOPS при latency в 300мс?
              0
              ты меня честно говоря поставил в тупик ) у меня левел по стореджам сильно ниже конечно, но вот уж кто точно бесполезен в обзоре SSD — это мегабайты/сек. Мне в моей работе с высоконагруженными SQL серверами и хостами на Hyper-V всегда хватало тестирования по иопсам чтобы спланировать нагрузку.

              так что же лучше? и что почитать про латенси?
                +3
                Понимаете, тут есть две стороны планирования: планирование СХД с точки зрения поставщика (того, кто смотрит на итоговую загрузку на хост) и с точки зрения потребителя (приложения), которого волнует только то, «насколько оно тормозить будет».

                Правило большого пальца — latency на СХД не должна превышать 20мс для (70-90)% запросов. Если превышает, то сколько бы IOPS не показывала система, она не даёт адекватной скорости большинству приложений.
                  0
                  Ну умом я это понимаю, но откуда это правило? Есть гайдлайны, бестпрактисы от вендоров?
                  И как разумнее всего ее оптимизировать, от чего она зависит?
                    +1
                    Нет никаких гайдлайнов. В этом-то и проблема. Половина вендоров вообще ни сном ни духом. Когда я адаптек спросил, в каком режиме их контроллер даст наименьшую latency, то мне вообще ответили ахинею про 50к IOPS на контроллер и скорость работы.

                    … Как оптимизировать latency? Я бы много дал за хороший ответ на этот вопрос. Пока что ограничиваюсь эмпирическим анализом — пробую варианты, какой даёт меньше latency, тот и использую.
                      0
                      А как понять что приложение тормозит? Ну то есть есть у меня виртуальная машина, в которой я допустим запускаю некое приложение, которое при старте активно использует диск. Я же не знаю насколько быстро оно должно работать? Ну то есть я конечно могу увидеть, что очередь запросов к диску вырастает, то есть запросы не успевают обрабатываться. Глупо оптимизировать СХД или наращивать мощности до тех пор, пока очередь не перестанет возникать — нужен же некоторый компромисс между стоимостью и откликом.

                      Ну то есть например гугл говорит, что если веб-страница отдается меньше чем за две секунды — это очень хорошо, а секунда — вообще супер. То есть на этом этапе можно прекращать оптимизации и жить спокойно, зная что у тебя все хорошо. А вот как понять что СХД медленнее, чем «рекомендуется» — не ясно.
                        +1
                        В отношении конкретных приложений — специфично для приложения (т.е. это программист должен сказать «если мы не успели за это время сделать вот это — значит тормозим). Общее же правило — смотреть на latency запроса. Как только запрос болтается в очереди и не исполняется (или исполняется долго) — это повод считать данный запрос „лагающим“ (интутитивно, правда?). Более менее разумной цифрой является 20мс (хотя это неким образом произвол, например, можно для себя установить лимит в 5мс или в 500).

                        То есть следует различать „быстро работает“ и „не справляется“. Первое — субъективно и определяется потребителем. Второе — объективно и означает, что входящих данных в приложение больше, чем возможности по записи (пример — периодическое скидывание базы типа redis, если оно не управляется за время между периодами — значит, дисковая подсистема не соответствует запросам редиса — либо поднимать время, либо ускорять СХД).
                +1
                latensy это обратная величина от IOPS. То есть количество операций ввода-вывода обратно пропорционально величине задержки.
                  +1
                  количество операций ввода-вывода в единицу времени
                    +2
                    Не совсем так. Поскольку запросы могут приходить в параллель, итоговая производительность (не планируемая!) определяется как iops=1/latency*queue_depth. В принципе, в условиях «неограниченно большой очереди» (что правда для большинства СХД) можно было бы говорить о том, что недобор по latency компенсируется глубиной очереди. Однако, в реальной жизни, когда мы говорим про субъективное «тормозит или нет», некоторые операции являются зависимыми (т.е. следующая операция будет выполнена после успешного выполнения текущей), таким образом для этих операций «торможение» определяется именно latency, причём довольно драматично. Например, 10мс при очереди в 30 даёт нам 3к IOPS, а 5 мс при глубине очереди в 15 — те же 3к IOPS. При этом для конкретного приложения рост производительности будет (в худшем случае) двухкратным (например, если у нас хитрая БД, которая все транзакцию выполняет за один IO и ждёт подтверждения перед выполнением следующей). В реальной жизни всё зависит от параллелизма операций со стороны приложений и как часто они используют барьеры.
                +1
                Почему нет графика IOPS?
                  +2
                  И время доступа тоже покажите. Пока что это не обзор, а огрызок.
                  +2
                  Количество IOPS которое выдает зависит от размера блока, мы указываем на графике размер блока и потоковую производительность при операциях с этим блоком. Действительно, можно было указать размер блока и IOPS, но графики при этом не сильно изменятся. Пожелание насчет показать время доступа тоже — учтем.
                    +1
                    Вы в курсе, что iometer (точнее, dynamo) безбожно врёт под линуксом? Используйте fio, там куда более разумные показатели раз, два, оно может писать лог latency, что куда интереснее, чем попугаи в секунду.
                      +1
                      Спасибо, обязательно сравним с fio под linux. В данных тестах использовался Iometer, под Windows.
                        +2
                        Так что вы сравнивать будете? Мб/с? Да у меня на любой супермикровской коробке минимум 2-3Гб/с raw read.

                        Где реальные-то цифры производительности?
                      0
                      «Т. к. ресурс записи 600-1500ТБ достаточен для большинства приложений в серверах мы планируем использовать диски Intel SSD 710...»

                      это откуда такие цифры если не секрет? Одна MLC ячейка по 25нм технологии имеет ресурс перезаписей всего порядка нескольких тысяч раз. Типа перезапись 100 гигабайт 6000 раз это 600TБ? А ведь как правило весь диск полностью не перезаписывается, есть часть диска на котором лежит редко изменяемая информация, и часть диска на котором лежит часто изменяемая информация… При соотношении этих частей в пользу первой ресурс записи окажется катастрофически мал.
                        +1
                        Данные по ресурсу записи — Intel SSD 710 — официальные, для дисков емкостью 100GB — это 600ТБ, для диска 400GB до 1500ТБ. Это новые диски с технлогией MLC NAND cм — www.intel.com/content/www/us/en/solid-state-drives/solid-state-drives-710-series.html
                          0
                          ох не верю я в эти чиселки, после того как три диска из предыдущей модели показали по 50 реаллоков после всего одного записаного терабайта (на все три, то есть по 330гиг на брата)

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

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