Про InfiniBand: как мы уменьшали пинг с 7 мкс до 2,4 мкс (и результаты тестов)

^{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>

Следующий тест (производительность протокола IPoIB):

1. Выполнить тест Sockperf UDP:
На 1-ом узле: sockperf sr -i <server ip>
На 2-ом узле: sockperf pp -t 10 –i <server ip>

2. Выполнить тест Sockperf TCP:
На 1-ом узле: sockperf sr -i <server ip> --tcp
На 2-ом узле: sockperf pp -t 10 –i <server ip> --tcp

Итоговый результат — 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. И мы стараемся максимально подробно и профессионально рассказать о всех возможных технологических вариантах решения поставленной задачи, никому ничего не навязывая.

Если вам интересна эта тема, то 12 сентября я буду вести вебинар, подключайтесь. Если сразу нужно рассчитать что-то или понять, можно ли провести тесты прямо на вашей площадке – пишите на AFrolov@croc.ru.

Автор: A_Frolov

Источник