InfiniBand-свитч SX6005. 12 FDR 56Gb/s портов на одном юните, коммутация 1.3Тб/с.
Многие считают, что InfiniBand — это «космос». То есть считается, что дорого и нужно только для «суперкомпьютеров» (HPC) производительностью в 1-2 Петафлопа и с гиганскими объмами обрабатываемых данных. Тем не менее, с помощью этой технологии можно организовывать не только самые скоростные межсистемные соединения в кластерах, но и радикально снижать задержки в работе критичных приложений. Конкретно – делать то, что может решаться и с помощью Ethernet, но экономичнее и быстрее. Вот пример.
Задача
У одного нашего крупного заказчика из финансовой сферы была проблема в скорости работы двух приложений. Специфика приложений заключалась в том, что необходимо было обрабатывать большое количество транзакций с минимальной задержкой. 6-7 мкс latency – это лучшие результаты, которые они достигли путем апгрейда серверов и максимальной софтверной доработкой. Дальнейшие возможные оптимизации сулили улучшения на уровне 0,3-0,5 мкс. Мы же пришли и сообщили, что сможем уменьшить задержки в два раза.
Решение
Мы предложили сделать коммуникации между сереверами с помощью InfiniBand. Разумеется, специалисты заказчика слышали об этой технологии, но им нужны были конкретные тесты на площадке, чтобы проверить всё лично. Для этого мы приготовили комплекс демо-аппаратуры, а они выделили несколько серверов под неё. «Боевые» сервера трогать не хотелось по понятным причинам. Итак, мы построили фрагмент живой сети, используя IB-соединения на площадке заказчика.
Для решения данной задачи мы взяли оборудование производства Mellanox. Главными критериями выбора именно этого производителя стало то, что коммутаторы Mellanox имеют «универсальные порты», которые программно определяются либо как порт InfiniBand либо как обычный Ethernet – что позволит потом беспроблемно интегрироваться в существующую Ethernet-сеть заказчика. Кроме того Mellanox производит весь спектр оборудования (включая свитчи, сетевые карты для любых серверов, интерфейсные кабели и так далее), что в последующем позволит собрать решение целиком вне зависимости от типа и производителя имеющихся в наличии серверов у заказчика.
Заказчики установили свои приложения на сервера и прокатали тесты (кажется, используя реальные задачи чуть ли не предыдущего финансового дня) и началось тестирование.
Результаты тестов
Архитектура первого теста:
Оборудование IB: ConnectX-3 HCA, SX6025 FDR switch, сервера HP Proliant DL380 G7, ОС RHEL 6.4 MRG 2.2.
Шаги тестирования:
Выполнить тест IB Read latency:
На 1-ом узле:ib_read_lat -a
На 2-ом узле:ib_read_lat –a <node1_ip>
Выполнить тест IB Write latency:
На 1-ом узле:ib_write_lat -a -R
На 2-ом узле:ib_write_lat –a -R <node1_ip>
Выполнить тест IB Send latency:
На 1-ом узле:ib_send_lat -a -R
На 2-ом узле:ib_send_lat –a -R <node1_ip>
Результаты
ib_read_lat —
#bytes #iterations t_min[usec] t_max[usec] t_typical[usec]
2 1000 2.34 9.90 2.36
4 1000 2.34 95.75 2.37
8 1000 2.34 14.15 2.37
16 1000 2.35 14.27 2.37
32 1000 2.37 12.02 2.40
64 1000 2.38 15.85 2.42
128 1000 2.49 14.03 2.52
256 1000 2.67 11.69 2.69
512 1000 2.98 15.09 3.02
1024 1000 3.62 14.01 3.66
2048 1000 4.90 94.37 4.95
4096 1000 6.09 16.45 6.13
8192 1000 8.42 14.42 8.47
16384 1000 13.10 20.04 13.15
32768 1000 22.44 26.07 22.98
65536 1000 41.66 53.00 41.72
131072 1000 79.52 82.96 79.65
262144 1000 155.42 160.17 155.51
524288 1000 307.13 372.69 307.26
1048576 1000 610.54 619.63 610.89
2097152 1000 1217.37 1305.74 1217.84
4194304 1000 2431.34 2466.40 2431.94
8388608 1000 4859.15 4928.79 4860.07
ib_write_lat —
#bytes #iterations t_min[usec] t_max[usec] t_typical[usec]
2 1000 1.26 6.29 1.28
4 1000 1.26 7.44 1.28
8 1000 1.27 5.87 1.28
16 1000 1.27 47.73 1.29
32 1000 1.34 5.79 1.35
64 1000 1.34 5.25 1.36
128 1000 1.48 5.36 1.50
256 1000 2.22 7.44 2.26
512 1000 2.94 47.86 2.98
1024 1000 3.58 7.95 3.63
2048 1000 4.88 8.22 4.91
4096 1000 6.06 9.99 6.09
8192 1000 8.39 11.21 8.43
16384 1000 13.07 15.25 13.48
32768 1000 22.82 27.43 22.89
65536 1000 41.95 45.60 42.04
131072 1000 79.88 85.01 79.93
262144 1000 155.75 160.06 155.84
524288 1000 307.50 332.07 307.65
1048576 1000 610.99 628.83 611.27
2097152 1000 1218.10 1227.02 1218.48
4194304 1000 2432.72 2475.44 2433.46
8388608 1000 4989.11 5025.70 4991.06
ib_send_lat –
#bytes #iterations t_min[usec] t_max[usec] t_typical[usec]
2 1000 1.32 5.74 1.34
4 1000 1.32 5.18 1.34
8 1000 1.32 5.33 1.34
16 1000 1.33 5.40 1.35
32 1000 1.35 5.79 1.37
64 1000 1.40 5.43 1.42
128 1000 1.53 5.52 1.55
256 1000 2.28 5.60 2.31
512 1000 2.92 7.45 2.95
1024 1000 3.56 7.79 3.59
2048 1000 4.85 8.94 4.88
4096 1000 6.03 13.98 6.07
8192 1000 8.36 16.11 8.40
16384 1000 13.02 20.84 13.09
32768 1000 22.39 30.22 23.21
65536 1000 41.93 66.03 42.02
131072 1000 79.84 92.94 79.92
262144 1000 155.72 164.96 155.81
524288 1000 307.49 321.99 307.68
1048576 1000 610.97 626.82 611.27
2097152 1000 1218.05 1241.91 1218.48
4194304 1000 2432.68 2473.29 2433.54
8388608 1000 4968.03 4994.76 4991.17
Следующий тест (производительность протокола IPoIB):
1. Выполнить тест Sockperf UDP:
На 1-ом узле:sockperf sr -i
На 2-ом узле: sockperf pp -t 10 –i
2. Выполнить тест Sockperf TCP:
На 1-ом узле: sockperf sr -i --tcp
На 2-ом узле: sockperf pp -t 10 –i --tcp
Результаты второго тестаТест Sockperf UDP:
Для пакета 16 байтов: avg-lat= 9.133 (std-dev=1.226)
Для пакета 64 байта: avg-lat= 9.298 (std-dev=1.268)
Для пакета 256 байтов: avg-lat= 9.605 (std-dev=1.031)
Для пакета 1024 байта: avg-lat= 10.791 (std-dev=1.066)
Для пакета 4096 байтов: avg-lat= 17.107 (std-dev=1.548)
Для пакета 16384 байта: avg-lat= 34.512 (std-dev=2.098)
Для пакета 65506 байтов: avg-lat= 96.502 (std-dev=3.181)
Тест Sockperf TCP:
Для пакета 16 байтов: avg-lat= 10.509 (std-dev=1.185)
Для пакета 64 байта: avg-lat= 10.506 (std-dev=1.154)
Для пакета 256 байтов: avg-lat= 11.552 (std-dev=1.128)
Для пакета 1024 байта: avg-lat= 12.409 (std-dev=1.168)
Для пакета 4096 байтов: avg-lat= 18.991 (std-dev=1.506)
Для пакета 16384 байта: avg-lat= 32.937 (std-dev=1.952)
Для пакета 65506 байтов: avg-lat= 76.926 (std-dev=3.066)
Итоговый результат - 2,36 – 2,37 мкс. На запись лучшие результаты около 2 мкс. Удалось добиться большего, чем требовалось заказчику.
А ещё после тестов я увидел то самое чувство глубокого морального удовлетворения, которое испытывают люди, знающие, что сейчас их система будет работать эффективнее. Без замены серверов.
Ethernet и InfiniBand
Сразу скажу: одно – это не замена другому. Это как сравнивать легковой автомобиль с танком: один удобный и быстрый, а на втором можно съездить в Европу. Важно, что от IB не стоит ждать большого количества сервисов и возможности построения сложной схемы маршрутизации – это безусловный удел Ethernet. Архитектура IB - «плоская».
При этом как результат простоты - InfiniBand очень легко модернизируется и масштабируется. Наша практика развёртывания локальных сетей после монтажа оборудования – пройти и воткнуть контакты, а затем час посидеть у терминала, и из этого часа 40 минут уйдёт на проверку уже готового решения. В случае с перестройкой Ethernet требуются изменения архитектуры, где есть очень много шагов – и в силу гибкости и некоторой мстительности технологии по отношению к тем, кто не знает всех-всех тонкостей, процедура похожа на подписание контракта с кучей пунктов мелким шрифтом. И есть некоторые шансы, что сложная архитектура преподнесет сюрпризы в будущем.
Отстроить Ethernet-сеть с параметрами как у IB займёт в 3-4 раза больше времени в среднем. Скорость решения задач по восстановлению IB-сети – максимум 4 часа в любое время суток. Этот показатель можно легко прописывать в SLA - мы ещё ни разу не сталкивались с тем, чтобы даже в сложных случаях время хоть как-то давило. Конечно, можно прописать такое же время и для Ethernet – но тогда на место должна выезжать целая бригада сисадминов.
Ну и главное отличие – это скорость.
Ethernet как и FibreChannel – это «ограниченные» технологии. Конечно можно обеспечить на Ethernet пропускную способность 100Gb путем агрегации энного количества 10Gb-линков. Но! Во-первых – это предел. Во-вторых – какова будет стоимость этого решения? А если ещё добавить стоимость эксплуатации? Надо ещё понимать сколько места, электроэнергии и затрат на отвод тепла в ЦОДе потребует 100 Gb коммутатор уровня ядра — а их нужно далеко не один. На IB – 100 Гб/сек – это не предел, и затраты на это решение (как CAPEX, так и OPEX) будут в разы меньше, так как меньше места, меньше потерь, меньше кабелей, меньше электричества и затрат на кондиционирование, меньше человекочасов на эксплуатацию и так далее. В общем, IB болучается просто быстрее и дешевле для задач такого класса.
Нужен практический пример?
Пожалуйста. Наш облачный ЦОД в какой-то момент потребовал больших скоростей. Архитектура при этом должна быть очень гибкая, быстро и безболезненно модернизируемая, перенастраиваемая под конкретные индивидуальные требования клиента (это один из козырей «облака» КРОК). Рассчитав скорость изменений, мы, безусловно, выбрали IB.
Производители
Раньше было четыре основных производителя - Qlogic, Mellanox, Voltaire и Topspin. Mellanox купил Voltaire примерно 3 года назад. Topspin стал частью Cisco в 2005-м, а Intel приобрёл Qlogic в 2012-м (сейчас оборудование, основном, ОЕР). В результате сейчас есть профильный игрок - Mellanox, обеспечивающий наиболее полный ассортимент. Его ОЕМ’ят HP, IBM, Violin и так далее.
Перспективы
Среди «космических» высокоскоростных решений InfiniBand получается весьма экономичным как в стоимости внедрения, так и по обслуживанию. Всего лишь 2-3 года на назад такие решения были нужны только для очень серьёзных задач с отраслевым значением, но сейчас всё больше и больше проектов enterprise класса. Всё очень просто: увеличивается количество данных, растут нагрузки от приложений, растет производительность серверов и как результат, требуются другие скорости обмена данными между серверами и скорости работы приложений.
Заказчики говорят так: «Мы ничего не теряем, мы не меняем технологию, не выкидываем Ethernet, но мы хотим дополнить наше инфраструктуру InfiniBand».
Почему с такими вопросами приходят к нам?
Многих заказчиков очень радует, что во-первых, можно посмотреть на оборудование вживую (мы с ним постоянно работаем на своих проектах и у себя в ЦОДах), сделать тесты на своих площадках (как я приводил пример выше), ввести пилотную систему и потом всё внедрить. Ещё у нас есть люди, которые умеют оптимизировать ПО под конкретные масштабные задачи с учётом всех особенностей сетей – это следующий виток работы с highload. И мы стараемся максимально подробно и профессионально рассказать о всех возможных технологических вариантах решения поставленной задачи, никому ничего не навязывая.
UPD. Судя по комментариям, не совсем ясно, почему было выбрано именно такое решение. Резюмируя: заказчику нужно было решить задачу снижения задержек с 7 мкс до 3 мкс на конкретных приложениях. Можно было решить это путём установки low-latency Ethernet-оборудования, что заказчик смог посчитать сам. При этом технические специалисты заказчика решили сравнить IB со своим вариантом.
Мы провели тесты на площадке заказчика, а его специалисты подтвердили следующее:
- IB в полной мере решает задачу и даже превосходит ожидания заказчика.
- Решение очень просто разворачивается на боевых серверах с непрерывными сервисами.
- Решение удобно эксплуатировать.
- Стоимость внедрения и стоимость обслуживания получаются куда меньше, чем для Ethernet-решений.
При этом заказчик использовал IB-совместимые модули, что определило выбор вендора.
P.S. Если вам интересна эта тема, то 12 сентября я буду вести вебинар, подключайтесь. Если сразу нужно рассчитать что-то или понять, можно ли провести тесты прямо на вашей площадке – пишите на AFrolov@croc.ru.
