Российская СХД AERODISK: нагрузочное тестирование. Выжимаем IOPS-ы


    Всем привет! Как и обещали, публикуем результаты нагрузочного теста системы хранения данных российского производства – AERODISK ENGINE N2.


    В прошлой статье мы ломали СХД (т.е. выполняли краш-тесты) и результаты краш-теста были положительными (то есть, СХД мы так и не сломали). С результатами краш-теста можно ознакомиться ЗДЕСЬ.


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


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


    Ниже список ближайших мероприятий и даты работы центров компетенций.


    • Екатеринбург. 16 мая 2019 года. Обучающий семинар. Зарегистрироваться можно по ссылке: https://aerodisk.promo/ekb/
    • Екатеринбург. 20 мая – 21 июня 2019 года. Центр компетенций. Приходите в любое рабочее время на живую демонстрацию СХД AERODISK ENGINE N2. Точный адрес и ссылка на регистрацию будет позднее. Следите за информацией.
    • Новосибирск. СЛЕДИТЕ ЗА ИНФОРМАЦИЕЙ НА НАШЕМ САЙТЕ или на ХАБРЕ.
      октябрь 2019 года
    • Казань. СЛЕДИТЕ ЗА ИНФОРМАЦИЕЙ НА НАШЕМ САЙТЕ или на ХАБРЕ.
      октябрь 2019 года
    • Красноярск. СЛЕДИТЕ ЗА ИНФОРМАЦИЕЙ НА НАШЕМ САЙТЕ или на ХАБРЕ.
      ноябрь 2019 года

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


    Тестовый стенд


    Итак, возвращаемся к тестам. Мы модернизировали нашу лабораторную СХД ENGINE N2, установив в неё дополнительные SAS SSD диски, а также Front-end адаптеры Fibre Channel 16G. Симметричным образом мы модернизировали сервер, с которого будем пускать нагрузку, добавив туда адаптеры FC 16G.


    В итоге у нас в лабе 2-х контроллерная СХД с 24-мя дисками SAS SSD 800GB, 3 DWPD, которая подключена через SAN-коммутаторы к физическому Linux-серверу по FC 16G.
    Схема тестового стенда на рисунке ниже.



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


    Для самой хорошей производительности на блочном доступе мы будем использовать пулы DDP (Dynamic Disk Pool), которые мы в свое время создавали как раз для ALL-FLASH систем.
    Для тестирования мы создали два LUN-а объемом по 1 TB каждый с уровнем защиты RAID-10. Каждый LUN мы «размажем» по 12 дискам (всего 24), чтобы полностью использовать потенциал каждого из установленных дисков в СХД.


    LUN-ы презентуем серверу через разные контроллеры, чтобы максимально утилизировать ресурсы СХД.


    Каждый из тестов будет длиться один час, а тесты будут выполняться программой Flexible IO (FIO), данные FIO автоматически выгружаются в Excel, в котором уже строятся графики, для наглядности.


    Профили нагрузки


    Всего мы выполним три теста по одному часу без учета времени прогрева, на которое отводим 15 минут (именно столько нужно чтобы прогреть массив из 24-х ССД дисков). Данные тесты эмулируют самые часто встречаемые нами профили нагрузки, в частности это те или иные СУБД, системы видеонаблюдения, трансляции медиа-контента и резервное копирование.


    Также во всех тестах мы сознательно отключили возможность кэширования в оперативную память на СХД и на хосте. Результаты, само собой, это ухудшит, но, на наш взгляд, в таких условиях тест будет более честным.


    Результаты тестов


    Тест №1. Случайная нагрузка маленькими блоками. Эмуляция работы высоконагруженной транзакционной СУБД.


    • Размер блока = 4k
    • Чтение/запись = 70%/30%
    • Количество работ = 16
    • Глубина очереди = 32
    • Характер нагрузки = Full Random



    Результаты теста:



    Итого с младшей mid-range системы Engine N2 мы получили 438k IOPS при задержках 2,6 миллисекунд. Учитывая класс системы, на наш взгляд, результат вполне достойный. Чтобы понять, является ли это пределом для системы, мы посмотрим на утилизацию ресурсов контроллеров СХД.


    Нас, в первую очередь, интересует CPU, поскольку, как указано выше, RAM-кэш мы сознательно отключили, чтобы не искажать результаты тестов.


    На обоих контроллерах СХД мы видим примерно одну и ту же картину.



    То есть нагрузка на CPU 50%. Это говорит о том, что это ещё далеко не предел данной системы хранения и можно ещё спокойно её масштабировать. Забежим немного вперед: все следующие тесты также показали нагрузку на процессоры контроллеров в районе 50%, поэтому приводить их повторно не будем.


    Исходя из наших лабораторных тестов, комфортным пределом системы AERODISK Engine N2, если считать случайные IOPS-ы при блоках 4k является значение ~700 000 IOPS. Если этого недостаточно и нужно стремиться к миллиону, то у нас есть старшая модель ENGINE N4.


    То есть история про миллионы IOPS — это ENGINE N4, а если миллион для вас слишком много, то спокойно используйте N2.


    Возвращаемся к тестам.


    Тест №2. Последовательная запись большими блоками. Эмуляция систем видеонаблюдения, загрузки данных в аналитическую СУБД или запись резервных копий.


    В этом тесте нас уже не интересуют IOPS-ы, поскольку при последовательной нагрузке большими блоками они не имеют никакого смысла. Нам, в первую очередь, интересны: поток записи (мегабайты в секунду) и задержки, которые при больших блоках, само собой, будут выше, чем при маленьких.


    • Размер блока = 128k
    • Чтение/запись = 0%/100%
    • Количество работ = 16
    • Глубина очереди = 32
    • Характер нагрузки – Sequential




    Итого: имеем запись пять с половиной гигабайт в секунду при задержках в одиннадцать миллисекунд. Если сравнивать с ближайшими зарубежными конкурентами, то результат, на наш взгляд, отличный, и также не является пределом системы ENGINE N2.


    Тест №3. Последовательное чтение большими блоками. Эмуляция трансляции медиа-контента, генерации отчетов из аналитической СУБД или восстановления данных из бэкапов.


    Как и в прошлом тесте нам интересны поток и задержки.


    • Размер блока = 128k
    • Чтение/запись = 100%/0%
    • Количество работ = 16
    • Глубина очереди = 32
    • Характер нагрузки – Sequential




    Показатели потокового чтения прогнозируемо чуть лучше показателей потоковой записи.


    Интересно, что показатель задержек во всем тесте идентичен (прямая линия). Это не ошибка, при последовательном чтении большими блоками в нашем случае это обычная ситуация.


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


    Выводы


    С двухконтроллерной системы AERODISK ENGINE N2 мы смогли выжать достаточно серьезные показатели (~438 000 IOPS и ~5-6 гигабайт в секунду). Нагрузочные тесты показали, что за нашу СХД нам точно не стыдно. Наоборот, показатели очень достойные и соответствуют хорошей СХД.


    Хотя, как мы писали выше, Engine N2 — это младшая модель, и к тому же показанные в этой статье результаты не являются её пределом. Позже мы опубликуем аналогичный тест с нашей старшей системы ENGINE N4.


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


    Кроме того, напоминаем, в этом году мы активно занимаемся обучением, поэтому приглашаем вас в наши центры компетенции, где вы сможете пройти обучение по СХД AERODISK, ну и заодно интересно и весело провести время.


    Дублирую информацию о ближайших обучающих мероприятиях.


    • Екатеринбург. 16 мая 2019 года. Обучающий семинар. Зарегистрироваться можно по ссылке: https://aerodisk.promo/ekb/
    • Екатеринбург. 20 мая – 21 июня 2019 года. Центр компетенций. Приходите в любое рабочее время на живую демонстрацию СХД AERODISK ENGINE N2. Точный адрес и ссылка на регистрацию будет позднее. Следите за информацией.
    • Новосибирск. СЛЕДИТЕ ЗА ИНФОРМАЦИЕЙ НА НАШЕМ САЙТЕ или на ХАБРЕ.
      октябрь 2019 года
    • Казань. СЛЕДИТЕ ЗА ИНФОРМАЦИЕЙ НА НАШЕМ САЙТЕ или на ХАБРЕ.
      октябрь 2019 года
    • Красноярск. СЛЕДИТЕ ЗА ИНФОРМАЦИЕЙ НА НАШЕМ САЙТЕ или на ХАБРЕ.
      ноябрь 2019 года
    AERODISK
    48,64
    AERODISK — российский производитель СХД.
    Поделиться публикацией

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

      +1
      А можно поподробней с п.1, что в вашей системе российского?
        0
        В первую очередь программное обеспечение, во вторую – проектная и рабочая документация, элементная база, процессы производства, тестирования и технической поддержка. В общем, также как у всех производителей в разных странах :-)

        Чуть более подробно можно почитать в первой части нашей первой статьи: habr.com/ru/company/tssolution/blog/425309
        0
        Выжмите из интернета еще больше, и загрузите в качестве КДПВ не 3 Мб малоинформативную картинку, а 30 Мб.
          0
          Большое спасибо. По ошибке загрузили не сжатую картинку. Исправились :-)
          0
          Напишите, пожалуйста, модели дисков, которые участвовали в тестировании. Либо ТТХ.
            0
            Конечно
            image
              0
              Спасибо. Производитель диска говорит что скорость случайной записи с блоками по 4 кБ равна 400KIOPS. В одном LUN 12 дисков в RAID10. (12*400000)/2=1200KIOPS. Ваш же тест показал всего 438KIOPS. Где же остальное?
                0
                Это номинальная заводская характеристика диска. То есть если в идеальных условиях напрямую пустить в диск нагрузку, то он покажет с одного диска 400к IOPS. Чтобы эти условия создать, нужно исключить влияние файловой системы хостовой ОС, мультипасинга ОС, таргета СХД, защиты RAID СХД, а также псевдофайловой системы СХД, которая делит пулы на чанки. Если всего этого не будет, то с одного диска можно получить 400k IOPS. Но без всех этих прослоек не будет ни избыточности, ни мониторинга, ни отказоустойчивости, ни интеллекта. Будет просто диск в вакууме, который дает 400k IOPS, что никакой полезной функции в себе не несет.
                  0

                  Полоса 6GB на 4x 16G FC очень достойно. Расскажите про свой Multipath, он все линки утилизирует даже с соседнего контроллера? Или я не разобрался и это с двух лун, каждая под своим контроллером?

                    0

                    Спасибо, старались :-).
                    Используется обычный асимметричный acitve-active (ALUA). Линки второго контроллера до LUN-а, который зацеплен за первым контроллером используются, но только "по праздникам", поскольку это не оптимальный путь. И да вы правы, LUN-ы мы тут раскидали по двум контроллерам, чтобы оптимально утилизировать контроллеры, поэтому к сожалению никакой магии :-) просто корректная настройка.

                  0

                  Вы классическую ошибку заказчиков совершаете. Люди складывают номиналы и цены дисков, на основе этого ТЗ выставляют. Даже в случае локального RAID все будет уже не так радужно. А в случае сетевой СХД и подавно?

                    0

                    В нашей практике заказчики указывают требования к производительности по-разному, бывают сразу оба варианта (номинал и при условиях настроенной СХД).


                    При этом проверяются на приёмке оба варианта тоже по-разному.


                    Сумму номинальных IOPS-ов в ТЗ пишут, как требования к именно носителям (это гарантия чтобы производитель плохие диски не поставил, т.к. не все ССД одинакового объема и DWPD одинаково полезны). Это подтверждается с помощью оригинального описания изготовителя диска, ну и при желании заказчика, с помощью запуска теста на один диск без прослоек.


                    IOPS-ы в ТЗ, которые получаются с самой СХД, обычно пишут отдельно, указывая соотношение чтения и записи, размер блока и прочие условия.


                    Частный пример ниже:


                    Этот вариант уже проверяется в живую на настроенной СХД.

              0
              Блочный доступ это конечно интересно, но намного интереснее на мой взгляд файловый.
              Интересуют следующие сценарии
              1) Файловый сервер CIFS/SMB с клиентами на Win и Lin
              2) Хранение виртуальных машин с доступом по NFS + какая нибудь отечественная виртуализация на OS+KVM
                0
                Добрый день.

                1)Производительность файлового доступа обязательно покажем в одной из следующих статей. Только наверное лучше сделаем связки SMB>Windows, NFS>Linux

                2)Этот сценарий мы тоже покажем, но на другом продукте. У нас есть гиперконвергентная система AERODISK vAIR, в которой есть свой облагороженный KVM.
                0
                Скажите, пожалуйста, как вы на одном хосте с двумя FC 16 Гбит/с в тестах 2 и 3 получили пропускную способность более 5 ГБ/с? Ведь два FC 16G дают максимум 3,2 ГБ/с.
                  0
                  Спасибо за замечание. На картинке была небольшая неточность (уже исправили), хотя в тексте было написано правильно. В сервере две двух портовые карты 16G (4 порта на сервер) и в СХД две двухпортовые карты 16G (4 порта на СХД)
                    0
                    Ок, а тогда в тесте 3 вы не уперлись ли в пропускную способность FC-адаптеров, а не в лимит СХД?
                      0

                      Уперлись в 4 порта 16G на хосте (на СХД можно ещё 4 добавить).


                      16Гбит\сек = 1,6 ГБ\сек * 4 = 6,4 ГБ\сек максимум. У нас 6,28.



                      на всякий случай источник


                      https://fibrechannel.org/wp-content/uploads/2017/04/FCIA-SpeedMap-Final.pdf

                        0
                        Да, я в курсе, не зря же я вам выше про 3,2 ГБ/с на два интерфейса писал (1,6 ГБ/с * 2). Просто значения очень близки к потолку пропускной способности, мало ли. А контроллеры СХД работают в пол силы. Так может стоило ввести в тестирование второй хост, чтобы еще IOPS-ов выжать? Может быть вы все уже проверили и померили, и больше от СХД не получить, ну тогда вопросов нет.
                          0

                          Спасибо. Как раз на следующий тест ENGINE (и не только) для Хабра мы добавим дополнительных серверов.


                          Сейчас есть проблема в свободных мощностях.


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


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


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

                            0

                            А поверх Ethernet работаете, с плюшками типа RoCE? На каких нибудь Mellanox 40/10G в режиме прямого включения сервер — СХД

                              0

                              Просто использовать 40G, 100G можно, но RoCE пока не поддерживается, ещё до этого не дошли.

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

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