Тестирование производительности гиперконвергентных систем и SDS своими руками

    — Штурман, приборы!
    — 36!
    — Что 36?
    — А что приборы?

    Примерно так на сегодня выглядит большинство синтетических тестов систем хранения данных. Почему так?

    До относительно недавнего времени большинство СХД были плоскими с равномерным доступом. Что это означает?

    Общее доступное дисковое пространство было собрано из дисков с одинаковыми характеристиками. Например 300 дисков 15k. И производительность была одинаковой по всему пространству. С появлением технологии многоуровневого хранения, СХД стали неплоскими — производительность различается внутри одного дискового пространства. Причем не просто различается, а еще и непредсказуемо, в зависимости от алгоритмов и возможностей конкретной модели СХД.

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

    Привычные синтетические тесты резко дают маху, цифры от этих нагрузок потеряли практический смысл. Единственный способ всерьез оценить подходит ли система — это пилотная инсталляция с перенесением продуктива. Но что делать, если на перенос продуктива не дает добро безопасность или это просто слишком долго / трудоемко. Есть ли способ оценки?

    Сделаем вид, что мы продуктивная нагрузка, и нагрузим весь гиперконвергентный кластер. Смело вычеркиваем «100% random по всему объему» — этот тест не покажет ровным счетом ничего, кроме производительности самых нижних дисков. Т.е. 150-300 IOPS на узел (2-4 SATA).

    Что для этого требуется?

    1. Минимум по 1 машине с генератором нагрузки на узел.
    2. Профили нагрузки, приближенные к продуктиву.

    Для массовых нагрузок типа VDI необходимо создание репрезентативного количества машин. В идеале конечно полного, но поскольку большинство демо-систем — это 3-4 узла, то 3000-4000 ВМ на них конечно никак не запустить.

    В моих цепких лапах оказался кластер Nutanix NX-3460G4, но тест применим к любой платформе, доступной на рынке. Более того, те же самые тесты можно проводить и для классических СХД, технология никак не меняется.

    image

    В качестве генератора нагрузки я взял FIO под управлением CentOS 7. Профили нагрузок от Nutanix XRay 2.2. Почему CentOS? Был дистрибутив под рукой, можно использовать любой другой Linux по вкусу.

    Делаем несколько шаблонов ВМ под разный тип нагрузки.

    1. Управляющая FIO — 1 vCPU, 2GB RAM, 20GB OS
    2. DB — 1 vCPU, 2GB RAM, 20GB OS, 2*2 GB Log, 4*28 GB Data
    3. VDI — 1 vCPU, 2GB RAM, 20GB OS, 10 GB Data

    Создаем управляющую FIO. Ставим CentOS в минимальной установке на 20GB диск, остальные не трогаем.

    После минимальной установки CentOS ставим FIO
    # yum install wget
    # wget dl.fedoraproject.org/pub/epel/testing/7/x86_64/Packages/f/fio-3.1-1.el7.x86_64.rpm
    # yum install fio-3.1-1.el7.x86_64.rpm

    Повторяем то же самое для машин шаблонов нагрузки. И прописываем FIO в автозагрузку на них.
    Создаем файл /etc/systemd/system/fio.service

    [Unit]
    Description=FIO server
    After=network.target
    
    [Service]
    Type=simple
    ExecStart=/usr/bin/fio --server
    Restart=on-failure
    RestartSec=5
    
    [Install]
    WantedBy=multi-user.target

    # systemctl daemon-reload
    # systemctl enable fio.service
    # systemctl start fio.service
    # firewall-cmd --zone=public --permanent --add-port=8765/tcp

    Инфраструктура готова. Теперь нужна нагрузка.
    Создадим список серверов FIO.
    10.52.8.2 — 10.52.9.146

    Удобно использовать для этого Excel.

    image

    Загружаем этот список на управляющую машину. На нее же загружаем конфиг-файлы FIO c нагрузкой.
    fio-vdi.cfg

    [global]
    ioengine=libaio
    direct=1
    norandommap
    time_based
    group_reporting
    disk_util=0
    continue_on_error=all
    rate_process=poisson
    runtime=3600
    
    [vdi-read]
    filename=/dev/sdb
    bssplit=8k/90:32k/10,8k/90:32k/10
    size=8G
    rw=randread
    rate_iops=13
    iodepth=8
    percentage_random=80
    
    [vdi-write]
    filename=/dev/sdb
    bs=32k
    size=2G
    offset=8G
    rw=randwrite
    rate_iops=10
    percentage_random=20</code>
    
    <b>fio-oltp.cfg</b>
    <code>[global]
    ioengine=libaio
    direct=1
    time_based
    norandommap
    group_reporting
    disk_util=0
    continue_on_error=all
    rate_process=poisson
    runtime=10000
    
    [db-oltp1]
    bssplit=8k/90:32k/10,8k/90:32k/10
    size=28G
    filename=/dev/sdd
    rw=randrw
    iodepth=8
    rate_iops=500,500
    
    [db-oltp2]
    bssplit=8k/90:32k/10,8k/90:32k/10
    size=28G
    filename=/dev/sde
    rw=randrw
    iodepth=8
    rate_iops=500,500
    
    [db-oltp3]
    bssplit=8k/90:32k/10,8k/90:32k/10
    size=28G
    filename=/dev/sdf
    rw=randrw
    iodepth=8
    rate_iops=500,500
    
    [db-oltp4]
    bssplit=8k/90:32k/10,8k/90:32k/10
    size=28G
    filename=/dev/sdg
    rw=randrw
    iodepth=8
    rate_iops=500,500
    
    [db-log1]
    bs=32k
    size=2G
    filename=/dev/sdb
    rw=randwrite
    percentage_random=10
    iodepth=1
    iodepth_batch=1
    rate_iops=100
    
    [db-log2]
    bs=32k
    size=2G
    filename=/dev/sdc
    rw=randwrite
    percentage_random=10
    iodepth=1
    iodepth_batch=1
    rate_iops=100

    Запустим FIO в для проверки правильности настроек и первичного прогрева дисков.

    На управляющей ВМ

    # fio --client <fio.template.ip> vdi.cfg

    Минуты через 2-3 можно нажать Ctrl-C, иначе FIO отработает полный цикл из конфига — 2 часа.

    Теперь подготовим площадку под массовое развертывание VDI нагрузки. Я создал совершенно непересекающуюся сеть с IPAM — гипервизор AHV перехватывает DHCP и выдает адреса сам.

    image

    Поскольку AHV выдает адреса не по порядку, сделаем пул размером ровно под планируемую нагрузку — 400 ВМ (по 100 на хост).

    image

    Создаем нагрузочные 400 машин VDI.

    image

    image

    В принципе только создание сразу 400 машин уже интересный тест любой системы.
    Как у нас справился немолодой уже кластер Nutanix?

    image

    2 минуты. Мне кажется, отличный результат.

    Теперь включаем машины.

    На Nutanix CVM
    # acli vm.on fio-vdi-*

    Ну и теперь самое время врубить полный газ!
    С управляющей FIO
    # fio --client vdi.list vdi.cfg

    Примерно так ваша СХД будет себя чувствовать под 400 ВМ со средней офисной VDI нагрузкой.

    Так же в статье указаны профили для средней OLTP и DSS БД. Их, конечно не по 400, но штук 6-8 можно запустить и попробовать. Например для 8 OLTP и 2 DSS нам потребуется 10 машин из тех, что имеют по 6 дополнительных дисков.

    С двух терминалов сразу

    1. # fio --client oltp.list fio-oltp.cfg
    2. # fio --client dss.list fio-dss.cfg

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

    image

    Теперь наблюдаем как под нагрузкой система будет перестраиваться и как это изменит показатели. Особое внимание обратите на «умные» системы, которые откладывают перестроение и восстановление отказоустойчивости на час и более. Не, ну а что такого? А вдруг это ничего страшного нет, подумаешь узел вылетел. Зато на тестах красивые цифры останутся. Если не читать то, что мелким шрифтом в глубинах документации.

    Nutanix начинает процесс восстановления автоматически, через 30 секунд после недоступности CVM. Даже если это легитимная операция как например перезагрузка при обновлении.

    При помощи подобного нехитрого руководства можно попробовать — а подходит ли вам предлагаемая вендором / интегратором система.

    Ну или конечно, вы можете просто скачать Nutanix XRay, которая сделает все это в автоматическом режиме с красивыми графиками для платформ Nutanix AHV и VMware! :)

    Отдельная благодарность за помощь r0g3r

    Nutanix

    42,00

    Компания

    Поделиться публикацией

    Похожие публикации

    Комментарии 7
      0
      Правильно ли понимаю, что при запуске теста все 400 ВМ синхронно отрабатывают один и тот же сценарий?
        0
        Не синхронно, конечно же, но одинаковый в каждой VM.
        0

        Может это просто результат старой платформы Nutanix, почему то мне видится ажиотаж по переходу именно на платформу Nutanix… Или это кто-то умело вводит в заблуждение по поводу качества их систем...

          0
          Попробуйте теперь по-русски сформулировать.
            0
            Сформулируйте понятнее, пожалуйста, что именно вы хотели сказать, спросить, или в чем состоит предмет комментария.
            +1
            А почему бы не использовать специализированные тесты для гиперконвергентных систем (TPCx-HCI)?
              0
              Ну да, наконец появились такие, надеюсь, что они когда-нибудь станут общепринятыми, но пока (и в данном случае) они выглядят избыточными. TPC-HCI это бенчмарк. Основное преимущество бенчмарков — повторяемость для разных платформ и общепризнанность.
              В нашем случае куда понятнее, быстрее и проще померить общепринятым fio, и результаты интерпретировать проще.
              Это не значит, что я отрицаю пользу TPC, совсем нет. Сделаем и его, вероятно, как только будет понятно насколько он честен и принимаем индустрией.

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

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