Сегодня доступно приличное количество интерфейсов, каждый из которых претендует на полезность и необходимость. Традиционный Ethernet с 1G, 10G, 40G; InfiniBand FDR 56G и QDR 40G; FibreChannel 8G, 16G, обещанный 32G.
Все обещают счастье и рассказывают про свою крайнюю необходимость и полезность в быту. Как с этим быть, что выбрать и где подводные камни?
Как тестировали:
Принимали участие традиционный для всех гигабит, который есть в каждом сервере, 40G Ethernet, QDR и FDR InfiniBand, 10G не стали брать. Сразу надо отметить, что мы считаем FC уходящим интерфейсом, сейчас в тренде конвергенция. 32G пока что недоступен, а 16G вне лиги высокоскоростных решений.
Для выяснения пределов испытания провели на достижение минимальных задержек и максимальной пропускной способности, что удобно сделать с помощью HPC методик, заодно проверили пригодность 40G Ethernet для HPC приложений.
Неоценимую помощь оказали и провели натурные испытания коллеги из ЦКО, которым один коммутатор на базе Intel ONS был передан на тестирование.
Кстати, раздача коммутатора в самый интересный проект продолжается.
Аппаратное обеспечение:
- Коммутатор с поддержкой 40G Ethernet
- Коммуникационный адаптер Mellanox ConnectX-3 VPI adapter card; single-port QSFP; FDR IB (56Gb/s) and 40GigE; PCIe3.0 x8 8GT/s
- Двухпроцессорная система с Intel® Xeon® E5-2680 v2
- OFED-3.5 (драйвера и низкоуровневые библиотеки для Mellanox)
- ConnectX® EN 10 and 40 Gigabit Linux Driver
Программное обеспечение:
- Замер производительности проводили с помощью синтетического теста pingpong из набора тестов Intel MPI Benchmark v3.2.3
- Версия используемой MPI библиотеки S-MPI v1.1.1 – клон Open MPI.
В процессе подготовки выяснился нюанс адаптеров Mellanox — они требуют принудительного перевода в режим Ethernet. Заявленный функционал автоматического определения типа подключенной сети почему-то не работает, может поправят.
Для оценки производительности «традиционно» смотрим на значения времени задержки (latency) при передаче сообщений длиной 4 байта и полосы пропускания при передаче сообщения длиной 4 МБ.
Начало опытов:
Используется обычный для Ethernet режим. В нашей терминологии, использовалась tcp фабрика. То есть MPI библиотека использует socket интерфейс для передачи сообщений. Конфигурация драйверов, коммутатора, и MPI по-умолчанию.
В таблице слева результаты для 1G ethernet, справа для 40G (с нашим коммутатором). Видим «провалы» в полосе для сообщений длиной 256К-1М и максимальный результат, подходящий для 10G Ethernet. Очевидно, что нужно настраивать ПО. Задержка, понятное дело, очень велика, но при прохождении через стандартный TCP стек много ожидать и не стоит. Надо отдать должное, в три раза лучше 1G Ethernet.
Mpirun –n 2 –debug-mpi 4 –host host01,host02 –nets tcp --mca btl_tcp_if_include eth0 IMB-MPI1 PingPong |
mpirun -n 2 -debug-mpi 4 -host host01,host02 -nets tcp --mca btl_tcp_if_include eth4 IMB-MPI1 PingPong |
Продолжаем:
Обновляем драйвера. Берем драйвер с сайта Mellanox.
Для уменьшения «просадки» в диапазоне 256К-1М увеличиваем размер буферов через настройки MPI:
export S_MPI_BTL_TCP_SNDBUF=2097152
export S_MPI_BTL_TCP_RCVBUF=2097152
mpirun -n 2 -debug-mpi 4 -host host1,host2 -nets tcp --mca btl_tcp_if_include eth4 IMB-MPI1 PingPong
В результате улучшение в полтора раза и уменьшение провалов, но всё равно мало, да еще подросли задержки на малых пакетах.
Конечно же, для улучшения полосы пропускания при применении высокоскоростных Ethernet интерфейсов имеет смысл использовать сверхдлинные Ethernet-кадры (Jumbo frames). Конфигурируем коммутатор и адаптеры на использование MTU 9000, и получаем заметно более высокую полосу пропускания, которая всё равно остается на уровне 20 Гбит/с.
Опять растет латентность на малых пакетах.
Пробовали другие параметры «покрутить», но принципиальных улучшений не получили. В общем, решили, что «не умеем их готовить».
В какую сторону смотреть?
Безусловно, если искать производительность, то нужно это делать в обход TCP стека. Очевидное решение — попробовать RDMA технологии.
Суть технологии:
- Доставка данных непосредственно в окружение пользователя, без переключения контекста приложения между режимами ядра и пользователя.
- Данные от адаптера помещаются сразу в память приложения, без промежуточных буферов.
- Сетевые контроллеры обрабатывают транспортный уровень без привлечения процессора.
Одно из следствий – значительное снижение латентности доступа.
Есть два конкурирующих стандарта, Internet Wide Area RDMA Protocol (iWARP) и RDMA over Converged Ethernet (RoCE), их соревнование и попытки сторонников утопить друг друга достойны отдельного холивара и объемного материала. Картинки приведены для iWARP, но суть общая.
Адаптерами Mellanox поддерживается RDMA over Converged Ethernet (RoCE), используем OFED-3.5.2.
В результате, получили отличные цифры. Задержку 1.9 мкс и полосу 4613.88 Мбайт/с (это 92.2% от пика!) при использовании Jumbo frames. Если размер MTU оставить по умолчанию, то полоса будет ниже, примерно 4300 Мбайт/с.
mpirun -n 2 -debug-mpi 4 -host host1,host2 --mca btl openib,self --mca btl_openib_cpc_include rdmacm IMB-MPI1
Для Pingpong теста время задержки можно улучшить до 1.4 мкс, для этого процессы нужно разместить на CPU «близких» к сетевому адаптеру. Какое практическое значение это имеет в реальной жизни? Ниже небольшая сравнительная табличка Ethernet vs InfiniBand. В принципе, такой «трюк» возможно применить к любому интерконнекту, поэтому в таблице ниже приведен диапазон значений для некоторых сетевых фабрик.
1G Ethernet (TCP) | 40G Ethernet (TCP) | 40G Ethernet (RDMA) | InfiniBand QDR | InfiniBand FDR | |
Latency, usec | 24.5 | 7.8 | 1.4-1.9 | 1.5 | 0.86-1.4 |
Bandwidth, Mbytes/s | 112 | 1126 | 4300-4613 | 3400 | 5300-6000 |
Данные для 40G и FDR плавают в зависимости от близости ядер, на которых исполняются процессы, к ядрам, ответственным за сетевой адаптер, почему-то на QDR этот эффект был почти не виден.
40G Ethernet значительно обогнал IB QDR, но до IB FDR не догнал по абсолютным цифрам, что не удивительно. Однако по эффективности 40G Ethernet лидирует.
Что из этого следует?
Торжество конвергентных Ethernet технологий!
Недаром Microsoft усиленно продвигает возможности SMB Direct, который полагается на RDMA, в NFS поддержка RDMA также встроена.
Для работы с блочным доступом есть технологии iSCSI offload на сетевых контроллерах и протокол iSCSI Extensions for RDMA (iSER), эстеты могут попробовать FCoE :-)
При использовании таких коммутаторов:
Можно построить кучу интересных высокопроизводительных решений.
Например, программно-конфигурируемая СХД наподобие FS200 G3 с 40G интерфейсом и ферма серверов с 10G адаптерами.
При таком подходе отпадает необходимость строить выделенную сеть для данных, значительно экономя как средства на второй набор коммутаторов, так и время на развертывание решения, ведь кабелей тоже требуется вдвое меньше подключить и проложить.
Итого:
- На Ethernet можно построить высокопроизводительную сеть со сверхмалыми задержками.
- Активное использование современных контроллеров с поддержкой RDMA значительно повышает производительность решения.
- 3. Матрица Intel с уровнем задержки в 400 ns cut-through помогает получить отличный результат :-)
Автор: ETegro_Technologies