RDMA – аббревиатура, достаточно известная благодаря частым упоминаниям в технических статьях и спецификациях на оборудование. Многим, скорее всего, известно, что означает она Remote Direct Memory Access или прямой доступ к памяти на удаленном хосте. Но что скрывается за ней на самом деле? В чем суть этой технологии, особенно в контексте систем хранения данных? Давайте разберемся в этом. Тем более, что поддержка данной технологии недавно появилась в СХД Qsan.
Основное назначение RDMA – это возможность доступа к содержимому ОЗУ удаленного хоста. То есть, если у нас есть два хоста (сервер1 и сервер2), то при помощи RDMA сервер1 может получить доступ к содержимому ОЗУ сервера2 без каких-либо промежуточных звеньев. Для этого потребуется поддержка протокола RDMA в ОС обоих хостов и сетевом оборудовании, при помощи которого и осуществляется обмен. Напомним, что классический случай обмена данными между хостами состоит из большего количества компонентов в виде программных модулей, драйверов, протоколов и прочего. В результате применения RDMA мы можем потенциально снизить задержки при доступе к данным и, тем самым, повысить общую производительность.
Неудивительно, что впервые массово RDMA стали использовать в вычислительных кластерах HPC, поскольку именно там данный протокол максимально раскрывает себя из-за многочисленного обмена промежуточными вычислениями между нодами. Однако, со временем RDMA стал распространяться на другие задачи, где так или иначе используется интенсивный обмен по сети. Последним бастионом пала область хранения данных.
Как правило, контроллер СХД — это фактически тот же сервер, просто работающий под управлением специфического ПО. Зачастую даже используется хорошо знакомая архитектура x86. Поэтому применение протокола RDMA позволяет получить доступ с хоста к ОЗУ контроллера СХД, где в том числе расположен кэш, максимально быстрым путем. А использование NVMe в качестве накопителей на стороне СХД открывает более широкие перспективы. Не секрет, что собственные задержки NVMe накопителей гораздо ниже по сравнению с классическими SAS/SATA SSD. Поэтому и итоговая задержка при работе с массивом (назовем ее внутренней задержкой СХД) также будет ниже. Но так как сама СХД является внешним устройством по отношению к хосту, существует еще задержка протоколов передачи. И эта задержка для AFA NVMe будет уже заметной, ведь речь идет о каких-то долях миллисекунд. Так что протокол RDMA здесь как раз сыграет значимую роль.
Но давайте пока отвлечемся от вопросов производительности в разрезе использования RDMA и взглянем на ситуацию немного с другой стороны. Исключение многих звеньев в случае обмена данными при прямом доступе к памяти подразумевает также отсутствие необходимости задействовать CPU сервера для обработки всех сопутствующих вводу/выводу процессов. В целом современные модели процессоров обладают достаточной вычислительной мощностью, чтобы нивелировать эти накладные расходы. Однако, с ростом интенсивности ввода/вывода эти накладные расходы становятся весьма заметными.
Чтобы вы понимали масштаб «бедствия», приведем пример из нашей практики. При выполнении теста IOmeter на сервере со стареньким Intel Xeon Bronze для обработки ~700K IOPS на томах СХД потребовалось почти 30% мощности CPU. Это, заметьте, только лишь ввод/вывод. Понятно, что на современном многоядерном процессоре результат будет не столь плачевным, но все равно достаточно заметным на общем фоне.
А теперь представим задачу, где одновременно требуется и интенсивный ввод/вывод, и значительные вычислительные мощности. Становится понятно, что любое значимое высвобождение ресурсов CPU благотворно скажется на итоговом результате. Одним из таких примеров являются вычисления на базе GPU, где помимо самих вычислений необходимо постоянное обращение к дисковому ресурсу, где хранятся исходные данные и промежуточные результаты. Именно для этих целей компания nVidia разработала технологию GPU Direct Storage (GDS), использующую RDMA как раз с целью максимально разгрузить CPU от задач обработки ввода/вывода.
Для иллюстрации процесса кратко изложим принцип обработки вычислений:
В случае использования «классического» подхода
Приложение запрашивает данные с NVMe SSD/NFS в кэш CPU;
CPU копирует данные в буфер обмена, расположенный в RAM;
CPU отправляет данные из буфера в GPU RAM через шину PCIe;
GPU выполняет расчеты.
В случае использования RDMA
GPU выполняет DMA запрос;
Данные копируются напрямую с NVMe SSD/NFS в GPU RAM.
Как не трудно догадаться, подход с использованием RDMA куда как эффективнее. Чтобы понять, что это дает в цифрах, приведем результаты тестов.
Тестовый стенд
Сервер с GPU NVIDIA RTX A2000, сетевой картой Mellanox ConnectX-4 Lx RoCE под управлением Ubuntu 22.04.5 LTS
СХД Qsan XN5112S, FW 4.1.5, встроенные порты 10GbE
Так как речь в тесте идет не о производительности дисковой подсистемы, на стороне СХД в пуле использовались обычные NL-SAS HDD. В качестве дискового ресурса использовалась сетевая папка NFS, примонтированная к серверу с помощью протокола NFS v4 over RDMA.
В качестве тестового ПО на сервере использовалась утилита gdsio. Пример выполнения команды:
taskset -c 0 gdsio -d 0 -I 0 -i 64K -s 128M -w 4 -x 0 -D /mnt/nfs -T 10
где один из параметров означает:
-x 0 = Storage → GPU Direct
-x 1 = Storage → CPU
-x 2 = Storage → CPU → GPU
Результаты тестирования приведены ниже.
Вполне очевидно, что использование RDMA дает кратное снижение нагрузки на CPU сервера, высвобождая его ресурсы для выполнения прочих задач.
Мы не случайно затронули тему RDMA в данной статье, поскольку поддержка протокола с недавних пор стала доступна не только в новейшем поколении AFA от Qsan, но и в более доступных Unified моделях. Конечно же, практическое применение протокола прямого доступа к памяти как правило не выглядит максимально дружелюбным по отношению к пользователю из-за различных нюансов, как программного, так и порой аппаратного характера. Однако, мы, имея огромный опыт в технической поддержке массивов Qsan, всегда готовы помочь нашим заказчикам и партнерам в решении задач любой сложности.
