Чем отличается SAN СХД от Nutanix?

После публикации о том, что в самой старшей модели, NX-8150, официально появилась поддержка 40GbE, стали часто задавать вопрос: «А почему нельзя заказать 40GbE и для остальных нод?» И для ответа надо немного более подробно рассказать о том, как именно работает устройство распределенного кластера Nutanix с точки зрения хранения данных, и почему нам не настолько важны «толстые» интерфейсы, особенно на не супермощных нодах-серверах.

Представим себе условную инфраструктуру, состоящую из 6 серверов, и SAN СХД. Допустим, для простоты иллюстрации, что на каждом из шести серверов работает прикладная задача, генерирующая около 2000 IOPS дискового трафика. Все эти серверы включены в SAN, и туда же включена и СХД.

Как мы видим на рисунке выше, это будет означать, что для обеспечения этих 2000 IOPS на каждом сервере, наша СХД будет должна обслужить и выдать 12 тысяч IOPS дискового трафика (без учета RAID penalty!). И чем больше будет становиться подключенных серверов, тем выше будет на нее нагрузка. Для такой СХД разумеется потребуется достаточно «толстый» интерфейс, иначе однажды серверы не смогут «протолкнуть» с СХД необходимый им трафик. В конечном счете производительность серверов будет определяться производительностью интерфейса к СХД и производительностью самой СХД, нагрузка на которую будет расти линейно увеличанию серверов или с ростом дискового трафика задач.

Другая ситуация в случае распределенного кластера хранения на Nutanix.
Представим такую же точно ситуацию, 6 серверов-нод, на каждом по 2000 IOPS. В отличие от «классической» SAN-инфраструктуры, у Nutanix нет единой консолидированной СХД, пространство хранения локально для каждой задачи, плюс каждая нода кластера хранит какую-то часть избыточных блоков. Избыточные блоки пересылаются на другие ноды с помощью канала 10GbE. Но этот канал не используется для доступа к дисковым данным у этого нода-сервера!

Каждый локальный диск отдает свои 2000 IOPS, что для современных SSD, совсем немного, и, при необходимости, может отдать и больше. Причем при увеличении инфраструктуры и добавлении еще серверов-нод, перегрузки какого-то отдельного компонента трафиком не возникает.
Вот здесь и кроется основная особенность распределенного хранилища Nutanix, вот почему нам не нужны на любой ноде сверхтолстые интерфейсы. Мы просто не гоняем по ним (весь) трафик. Да, бывают ситуации, когда толстый интерфейс нужен. Но это означает, не только то, что нода сама по себе высокопроизводительная, но и что задача на ней способна такой канал загрузить (прежде всего извне).

Давайте рассмотрим два крайних случая использования распределенного хранилища на шести нодах, по 2000 IOPS каждая: 100% чтение и 100% запись.
При 100% чтении все блоки данных будут читаться с локального хранилища, и межнодового трафика не будет практически совсем. Каждая нода дает 2000 IOPS и все.
Теперь наихудший с точки зрения межнодового трафика случай, 100% запись. При этом, как вы помните, каждый блок пишется локально, плюс, для избыточности, каждый этот блок записывается рандомно в одной или двух копиях, на одну или две ноды.

При этом вариант каждая нода пишет 2000 IOPS своего трафика, плюс 1/5 или 2/5 (в зависимости от RF=2 или RF=3) от этого трафика операций записи «чужих» блоков с пяти оставшихся нодов. В нашем случае это 2000+400 или +800 IOPS. То есть даже в наихудшем случае 100% рандомной записи, дисковый трафик на каждой ноде кластера не превысит 2400 или 2800 IOPS. Причем, отметьте, при увеличении числа нодов, эта «прибавка» будет падать, так как она будет размазана на все большее число нодов равномерно.
В реальной жизни, где объем трафика записи обычно ниже объема трафика чтения, значение прибавки в «1/5» в данном случае будет даже меньше.

Как совершенно справедливо заметил в комментариях один из читателей, написанный выше расчет относится к варианту, когда из 6 нод только одна делает 100% write, а остальные — read. В случае же, когда ВСЕ ноды делают 100% write (для простоты расчета возьмем, что все ноды делают равное число операций ввода-вывода), то наихудший случай даст нам на ноде 2x local IOPS. 2000 своих, плюс пять оставшихся нод пришлют нам на запись по одной пятой своих копий блоков, итого 4000 IOPS для RF=2 и 6000 для RF=3.

Вот почему ноды Nutanix, хотя и могут использовать новые «толстые» интерфейсы, чаще всего не нуждаются в них.

Практический пример?
Воспользуемся нашей демо-системой на demo.nutanix.com
Вот как выглядит ее загрузка на дашборде:

Как видите, 70 тысяч дисковых IOPS-ов на 4 нодах и 22 VM
Посмотрим, что делается при этом на сетевых портах нод и коммутаторе. Воспользуемся нашей новой фичей, Network Visualization:
Вот выше пример на одной ноде (на остальных трех ситуация аналогичная, трафикогенерирующие VM разбросаны по ним равномерно). Три-шесть мегаБАЙТА в секунду даже в пике!

А вот — статистика с порта коммутатора, соединяющего ноды вместе в кластер. Тоже семечки для 10GbE коммутатора, меньше миллиона пакетов в пике на порт.

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

UPD: Поправки, на которые обратил мое внимание в комментариях к посту коллега Nickolay.

Чем отличается SAN СХД от Nutanix?: 6 комментариев

  1. Maxim

    Рома, ты забыл основное написать — Нутаникс так мало грузит сеть за счет Data Locality собственно.

    Для того-же VSAN картинка будет совсем другая и в сеть упор реально будет.

    1. Nikolay

      Ох, опять эта священная Data Locality…
      Давайте воспользуемся вашей же математикой, только 70k IOPS с 4-х узлов что-то маловато, на мой взгляд. Давайте посчитаем 100K IOPS 4K с ноды (или 400k IOPS с 4-х узлов). Ну и «худший» случай, когда 100% данных не локальны для простоты.
      Пример 1. 100% чтение.
      ВМ суммарно запрашивают 400K IOPS, что означает, что 100K IOPS будут читаться с каждой ноды. 100K IOPS x 4KB = 400000 KB/s или 0.38GB/s или 3,05Gbit/s
      Пример 2. 100% запись.
      ВМ суммарно пишут 400K IOPS, что превращается в суммарно 800K IOPS на бекенде (при FTT=1, т.к. пишем две копии), значит на каждую ноду прилетает 200K IOPS. 200K IOPS x 4KB = 800000KB/s или 0,76GB/s или 6,1Gbit/s.

      Итого: 100K IOPS 4K на ноду не могут утилизировать один 10GbE интерфейс в vSAN даже в худшем случае. Разумеется, если нод будет больше, то общая производительность вырастет, а загрузка интерфейса не увеличится.

      Пример из жизни: гуглим «VMware Virtual SAN 6.2 All NVMe Flash Array with Intel SSD P3520 Sets New Record» там в конфигурации 8 нод, 900k IOPS 4K 70/30 R/W и всё на одной 10GbE карте в сервере.

      1. romx Автор записи

        > Давайте воспользуемся вашей же математикой, только 70k IOPS с 4-х узлов что-то маловато, на мой взгляд. Давайте посчитаем 100K IOPS

        «Пусть число танков равно N… Нет, N — мало, пусть число танков — M» :)

        1. Nikolay

          Ок, я перефразирую. ;)
          Чтобы утилизировать 10GbE под vSAN нужно >300k 4K IOPS на 100% чтение с узла (>1.2M IOPS с 4-х узлов) или >150k 4K IOPS с узла на 100% запись (>600k IOPS с 4-х узлов).
          Если кому-то нужно больше, то есть варианты:
          1.) Поставить еще одну двух портовую 10GbE карту
          2.) 25/40/50/100GbE карту. Это поддерживается и можно поставить в любую конфигурацию.

          Это я всё про «упор в сеть у vSAN из-за отсутствия Data Locality» :)

  2. Nikolay

    Роман, а вы не могли бы пояснить куда делись 9600 IOPS в вашем примере на 100% запись при RF=2?
    Ведь если каждая ВМ пишет по 2000 IOPS и таких ВМ 6, то они должно сгенерировать 12k IOPS на фронтенде и 24k IOPS на бекенде, т.к. каждая операция должна быть записана строго дважды для консистентности. В вашем же примере 2000+400=2400 на ноду или 14400 IOPS.
    Насколько я понимаю, каждый хост будет отправлять наружу 2000 IOPS (2000 IOPS пишем локально + 2000 IOPS удаленно), что дает нам 12000 IOPS дополнительного «внешних» IOPS, который нужно записать на все узлы. Если данные распределяются ровно по кластеру, то на каждый хост должно прилетать те самые дополнительные 2000 IOPS. И тогда формула будет 2000IOPS своих + 2000IOPS чужих, а не 2000+400. И при увеличении количества узлов ничего не измениться, будут те же самые +2000 IOPS, только увеличится суммарная производительность кластера.

    1. romx Автор записи

      Николай, вы, конечно же, правы. У автора беда с математикой ;)) Сейчас я внесу правки в текст. Разумеется, в случае 100% write на _ВСЕХ_ нодах (при случае равной нагрузки на всех нодах), если брать крайний худший случай, объем IOPS будет 2x от объема операций ввода-вывода на одну ноду (при RF=2).
      Написанный в посте вариант — это в случае, если только на одной ноде 100% write, а на остальных только read.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *