Всем привет! Как и обещали, публикуем результаты нагрузочного теста системы хранения данных российского производства – 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 года

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


  1. Cobolorum
    13.05.2019 08:43

    А можно поподробней с п.1, что в вашей системе российского?


    1. Viacheslav_V Автор
      13.05.2019 12:09

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

      Чуть более подробно можно почитать в первой части нашей первой статьи: habr.com/ru/company/tssolution/blog/425309


  1. vdem
    13.05.2019 08:53

    Выжмите из интернета еще больше, и загрузите в качестве КДПВ не 3 Мб малоинформативную картинку, а 30 Мб.


    1. Viacheslav_V Автор
      13.05.2019 14:18

      Большое спасибо. По ошибке загрузили не сжатую картинку. Исправились :-)


  1. SAAE
    13.05.2019 10:18

    Напишите, пожалуйста, модели дисков, которые участвовали в тестировании. Либо ТТХ.


    1. Viacheslav_V Автор
      13.05.2019 10:25

      Конечно
      image


      1. SAAE
        13.05.2019 11:27

        Спасибо. Производитель диска говорит что скорость случайной записи с блоками по 4 кБ равна 400KIOPS. В одном LUN 12 дисков в RAID10. (12*400000)/2=1200KIOPS. Ваш же тест показал всего 438KIOPS. Где же остальное?


        1. Viacheslav_V Автор
          13.05.2019 11:57

          Это номинальная заводская характеристика диска. То есть если в идеальных условиях напрямую пустить в диск нагрузку, то он покажет с одного диска 400к IOPS. Чтобы эти условия создать, нужно исключить влияние файловой системы хостовой ОС, мультипасинга ОС, таргета СХД, защиты RAID СХД, а также псевдофайловой системы СХД, которая делит пулы на чанки. Если всего этого не будет, то с одного диска можно получить 400k IOPS. Но без всех этих прослоек не будет ни избыточности, ни мониторинга, ни отказоустойчивости, ни интеллекта. Будет просто диск в вакууме, который дает 400k IOPS, что никакой полезной функции в себе не несет.


          1. Hardened
            17.05.2019 08:03

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


            1. Viacheslav_V Автор
              17.05.2019 12:42

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


        1. Hardened
          17.05.2019 08:00

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


          1. Viacheslav_V Автор
            17.05.2019 12:16

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


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


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


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


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


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


  1. Andrew225
    13.05.2019 10:25

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


    1. Viacheslav_V Автор
      13.05.2019 10:28

      Добрый день.

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

      2)Этот сценарий мы тоже покажем, но на другом продукте. У нас есть гиперконвергентная система AERODISK vAIR, в которой есть свой облагороженный KVM.


  1. pup51k
    16.05.2019 07:22

    Скажите, пожалуйста, как вы на одном хосте с двумя FC 16 Гбит/с в тестах 2 и 3 получили пропускную способность более 5 ГБ/с? Ведь два FC 16G дают максимум 3,2 ГБ/с.


    1. Viacheslav_V Автор
      16.05.2019 07:26

      Спасибо за замечание. На картинке была небольшая неточность (уже исправили), хотя в тексте было написано правильно. В сервере две двух портовые карты 16G (4 порта на сервер) и в СХД две двухпортовые карты 16G (4 порта на СХД)


      1. pup51k
        16.05.2019 07:41

        Ок, а тогда в тесте 3 вы не уперлись ли в пропускную способность FC-адаптеров, а не в лимит СХД?


        1. Viacheslav_V Автор
          16.05.2019 11:09

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


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



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


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


          1. pup51k
            16.05.2019 11:49

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


            1. Viacheslav_V Автор
              16.05.2019 12:17

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


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


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


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


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


              1. Hardened
                17.05.2019 08:08

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


                1. Viacheslav_V Автор
                  17.05.2019 12:43

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