Pull to refresh

InfiniBand, RDMA и извечная борьба с ядром за сетевую производительность

С чего начинается любая борьба\война\противостояние? С недовольства, неудовлетворенности, желания достичь большего…

Так и ведомая мной война за микросекунды, война в отдельно взятой организации за «микрули» как конкурентное преимущество, началась с предрассудка о «Speed of Light Issue», мнения что сеть работает как работает и попытки ускорить ее это борьба за превышение скорости света (попытки гнать оптический сигнал быстрее остальных), т.е. благородная но бесполезная. Именно это выражение красовалось на всяческих встречах топ менеджмента и менеджеров среднего звена и становилось приговором, при виде которого все благоговейно кивали, и норовили списать неудачи…
Конечно я не бросился срочно паять варп-агрегат который будет передавать данные в виде частиц на любое расстояние за -1 секунду. Хоть и хочется но пока не придумал как ;). Посему не мудрствуя лукаво сел изучать структуру и состав сил противника и конечно-же диспозицию.
Стоит-ли напоминать что сеть характеризуется не только скоростью передачи информации но и задержками, которые характерны для любого участника цепочки передачи информации. Причем параметр задержки на столько важен что я считаю его ключевым. Приведу пример:

Два датацентра находятся на расстоянии в 100км нам необходимо передать данные и сделаем мы это с весьма приличной скоростью не смотря на отсутствие линий связи. Мы запишем наши данные на Blue Ray диски, много дисков — грузовик дисков. Предположим мы уместили все данные на 10 тысяч дисков BD-ROM односторонних 50ГБ каждый. Скажем группа админов записывала, маркировала, грузила а потом и разгружала-считывала эти диски в течении недели. Таким образом мы транспортировали данные со скоростью 7.1Gbps. Вроде результат очень даже неплохой, более того есть пространство для ускорения (пинать админов чтоб быстрее писали), но вот задержка в 7 дней это как-то не то совсем…

Вот задержки и были объявлены военными преступниками и приследуются беспощадно. Как всякий порядочный враг задержки захватили всё до чего смогли добраться:
К примеру типичный путь следования пакета, optimization: приложение->сокет->ядро->стек протоколов (UDP->IP, ARP резолв->Ethernet)->Сетевая карта(MAC уровень -> PHY уровень)->Свич->Сетевая карта(PHY уровень -> MAC уровень)->… прерывание....->ядро->стек протоколов (Ethernet->IP->UDP)->ядро->сокет->приложение. Как видите враг укрепился серьезно. Условно я склонен разделить этапы пути следования на:

1. Слабо контролируемые:
Ядро (Можем сделать предсказуемым при помощи rt расширений (линух), за известную цену стабильности) но обойти всяческие полезные объекты врятли удастся).
Стек протоколов (тут-уж и песни слова не выкинешь)
Сокет (раб ядра и стека)
Свич (не управляемый)
Сетевая карта (хоть мы и можем заменить ее на более шуструю контроля это не прибавит)

2. Хорошо контролируемые
Приложение (если код доступен)
Свич (управляемый и\или заменяемый)

Расстановка сил не в нашу пользу ?! Но даже при таком раскладе можно добиться значительного уменьшения задержек следуя разным подходам работая с каждым элементом (думаю сия тема раскрыта надежно и широко, хотя с удовольствием затрону вопрос при желании сообщества).
Затяжная позиционная война это развлечение на любителя и\или при соответствующей стратегической обстановке. Как говорится «Война-фигня, главное маневр» и маневр наш будет весьма не ординарным — мы заменим врага на друга, точнее на меньшего врага ;).

RDMA (Remote Direct Memory Access) да еще и в паре с InfiniBand — вот наше меньшее зло. Вероятно некоторые читатели, с этого места, начнут думать о дороговизне, проприетарности, экзотичности, переносимости и это их право. Скажу лишь что сводные затраты на оборудование основанное на инфини и высокопроизводительное\ с низкими задержками Ethernet оборудование будут сопоставимы притом инфини в ряде случаев более дешев. Сей вопрос достоен отдельного поста…
Вернемся к нашим новым враго-друзьям. RDMA. Принцип его работы довольно хорошо раскрывается его названием, он берет данные из памяти одной машины и записывает в память другой. Кто он? Адаптер! Да аппаратное устройство, совершенно без участия ОС, из одного не свопируемого буфера в другой.
Для сравнения худший случай традиционного соединения (от приложения до приложения) это порядка 100 микросекунд, из того что я наблюдал. Для RDMA — 30.

Осталась одна проблема — «языков не знаем» — не умеют наши программы говорить на RDMA, а переписывать дорого\лениво. (Должен сказать в моем случае переписывание оказалось выгодным.) Но проблему решили за нас при помощи библиотеки врапера заменяющго функции работы с сокетами — достаточно пере собрать вашу софтину с этой библиотекой. Она не заменит все вызовы на RDMA\InfiniBand только транспортировку данных, а для ОС всеравно будут отданы все соответствующие вызовы для поддержки работы соединения и тому подобное. Я намеренно не конкретизирую т.к. таковых существует несколько в том числе проприетарные например от Voltaire.

Примерно так выглядел один из маневров войны которая будет продолжаться пока я не спаяю варп-агрегат.
Tags:
Hubs:
You can’t comment this publication because its author is not yet a full member of the community. You will be able to contact the author only after he or she has been invited by someone in the community. Until then, author’s username will be hidden by an alias.