Использование RDMA для уменьшения задержки в распределенных СХД

В одной из предыдущих статей нашего блога рассматривался вопрос о степени влияния транспорта (фабрики ЦОД) на время отклика СХД. А в этой статье, как я и обещал, будет рассмотрен еще один подход, не зависящий явно от возможностей фабрики. Этот подход предусматривает более близкое знакомство с тем, каким образом операционная система взаимодействует с сетью.

Для примера, рассмотрим общение между клиентом и сервером по протоколу iSCSI (рис. 1):

Рис. 1

Роль приложения выполняет iscsi-initiator на клиенте, и iscsi-daemon на сервере. Как видно, с точки зрения контрольных потоков, для того, чтобы клиенту записать данные на сервер, необходимо обратиться к сокету операционной системы, который в свою очередь общается с драйвером сетевой карты. Собственно сами данные копируются между буферами user-space и kernel-space. Аналогичные процессы происходят и на стороне сервера, когда тот получает данные в буфер сетевого адаптера. Заметна избыточность действий – данные копируются дважды, и дважды идет обмен контрольными сообщениями, прежде чем пакеты попадут в сеть. Если найти вариант уменьшить эту избыточность – делать все по одному разу – то можно было бы вдвое уменьшить задержку, вносимую на этом этапе.

Способ передать данные по сети, реализующий эту идею, существует. Он получил распространение в высокопроизводительных кластерах, и лишь относительно недавно (2010г) появились документы, описывающие его использование в пределах фабрики Ethernet/IP. Речь идет как раз о том, чтобы дать приложению (в нашем случае — iSCSI) возможность напрямую читать и писать данные в буфер памяти сетевой карты. Пример отражен на рис. 2:

Рис. 2

Технология носит название RDMA. А ее реализация для фабрики Ethernet/IP выразилась в двух проектах: RDMA over Converged Ethernet (RoCE) и iWARP.

Предвижу резонный вопрос — что нужно для того, чтобы это все заработало?

Со стороны клиента и сервера — нужна поддержка RDMA в приложении, а также поддержка в драйвере сетевой карты. От фабрики, в общем случае, не требуется особых умений, рекомендуется лишь минимизировать количество сбросов пакетов. Но, все по порядку. Начнем с требований к приложению.

Для iSCSI существует реализация — iSCSI Extensions over RDMA, или iSER. То есть, можно сказать, что с точки зрения приложения (как клиентской, так и серверной частей) есть готовность к использованию.

На стороне сетевой карты (и драйверов к ней) также существуют реализации у производителей оборудования. Как я уже говорил ранее, здесь поле делят две технологии — iWARP (поддержка в адаптерах Intel, QLogic) и RoCE (поддержка в адаптерах Mellanox, QLogic). В этой статье я не ставил задачи фокусироваться на отличиях этих технологий, однако в комментариях к ней можно поговорить об их особенностях. На рисунках 3 и 4 я представлю только стек протоколов каждой из технологий.

Рис. 3.  RoCEv2 транспорт для сообщений протокола iSCSI

Рис. 4.  iWARP транспорт для сообщений протокола iSCSI

Что же касается требований к фабрике, то здесь, как я уже упоминал, желательно для трафика СХД минимизировать сброс пакетов. Подходы к решению этой задачи описаны в одной из статей нашего блога. Стоит учитывать, однако, особенности технологий RoCE и iWARP. Первая использует UDP в качестве транспорта и, следовательно, для него не будет работать подход ECN в том виде, в каком он описан в статье (а именно, для TCP). Однако, RoCEv2 имеет собственный механизм Congestion Management, основанный на ECN и использующий те же поля в заголовке пакета IP.

Для iWARP же нет фиксированного порта TCP, что не позволит идентифицировать его пакеты заранее, на этапе настройки. Однако здесь может помочь контроллер, способный на лету определять потоки с “интересным” трафиком и отдавать команду коммутаторам на применение политик к этим потокам.

Однако, достаточно теоретизировать. Несмотря на то, что на качественном уровне технология RDMA должна увеличить производительность при обращении к СХД, важно оценить и количественные параметры.

У себя в лаборатории мы собрали стенд, состоящий из сервера СХД, клиента СХД и фабрики (рис. 5):

Рис. 5

Серверы оборудованы сетевыми адаптерами, поддерживающими RoCEv2 (у нас в лаборатории – это адаптеры Mellanox ConnectX-4 LX). Роль iSCSI target выполняет сервер с Centos7.4 и пакетом scst. Клиент — тоже CentOS 7.4 со стандартным linux iscsi initiator.

В качестве дисковых ресурсов в сервере используются диски SSD, производительность доступа к СХД измеряется на клиенте утилитой vdbench.

Результаты измерений приведены на рис. 6:

Рис. 6

Комментируя результаты, можно отметить, что прирост в производительности действительно заметный, улучшение по времени задержки и IOPS — в два раза. В дополнение, загрузка процессора в случае использованияRDMA уменьшается из-за того, что теперь всю работу по перемещению данных выполняет сетевой адаптер.

Важно отметить, что эти результаты достижимы и заметны только в случаях, когда время задержки при доступе к СХД меньше 1 мс. Если, к примеру, в вашей СХД задействованы механические диски со временем доступа около 10 мс, то RDMA, конечно, по-прежнему ускорит обращения к такой СХД. Однако, на итоговый результат это мало повлияет, т.к. для клиента, по большому счету, неважно, получит он ответ через 10 мс или через 9.9 мс, разница слишком мала чтобы ее заметить.

Однако, учитывая тот факт, что диски SSD становятся все дешевле, а на горизонте уже маячит новое поколение накопителей — NVM Express (NVMe), вопрос об ускорении доступа к СХД, подключенной к фабрике IP уже через небольшое время может стать очень актуальным.