Приложение B. Эффективное применение RDMA для служб ключ- значение

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

HERD обладает двумя нетрадиционными решениями: во- первых, он не применяет чтение RDMA, несмотря на общую привлекательность операций, которые полностью минуют удалённый ЦПУ. Во- вторых, он пользуется смесью глаголов (verb) RDMA и обмена сообщениями, несмотря на общепризнанное мнение что имеющиеся примитивы сообщений являются медленными. Некий клиент HERD записывает свои запросы в оперативную память сервера обработки; этот сервер вычисляет соответствующий отклик. Такой подход применяет некий единый путь в оба конца для всех запросов и поддерживает до 26 миллионов операций ключ- значение в секунду со средним временем задержки в 5 мкс. Следует отметить, что для небольших элементов ключ- значение наша полная пропускная способность системы аналогична присущей чтению RDMA пропускной способности и является почти в два раза выше чем предыдущие системы ключ- значение на основе RDMA. Мы полагаем, что HERD в дальнейшем послужит в качестве действенного шаблона для построения служб центра обработки данных на основе RDMA.

RDMA; InfiniBand; RoCE; Key-Value Stores

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

Основным мотивом для нашей работы послужил кажущийся контраст между имеющимися фундаментальными требованиями времени для обмена между узлами в сопоставлении с выборкой ЦПУ- оперативная память, а также теми недавно появившимися решениями, которые применяют множественные чтения RDMA (remote direct memory access - удалённого прямого доступа к памяти). С одной стороны, прохождение между узлами в грубом приближении требует 1- 3 мкс, в сравнении с 60- 120 нс для выборки из памяти, в предположении, что конструкция со множеством RTT {временем на передачу и подтверждение приёма, периодом кругового обращения}, как это было обнаружено в последних системах Pilaf [²¹] и FaRM [⁸] должна быть в целом медленнее чем построение с отдельным RTT. Однако, с другой стороны, некие чтение RDMA обходит множество потенциальных источников накладных расходов, таких как обслуживание прерывания и инициацию обменов управления, которые вовлекают в себя ЦПУ хоста. В данной статье мы показываем, что имеется лучший путь получения преимуществ RDMA для получения высокопроизводительного хранилища с низкой латентностью.

Некий вызов как для нашей, так и для предыдущих работ заключается в отсутствии богатства операций RDMA. Какая- то операция RDMA может всего лишь выполнять считывание или запись в удалённом местоположении. Последние работы построения хранилищ ключ- значение [²¹, ⁸] были сосредоточены исключительно на применении чтения RDMA для обхода удалённых структур данных, аналогично тому, как мы бы это выполняли если бы эти структуры располагались в локальной памяти. Такой подход неизменно требует множества двунаправленных обменов в имеющейся сетевой среде.

Рассмотрим некое идеальное хранилище ключ- значение на основе RDMA (или кэширования), в котором каждый запрос GET требует только одного небольшого чтения. Проектирование такого хранилища настолько же сложно, как и проектирование таблицы хэш- значений, в которой каждый запрос GET требует только одной произвольной выборки из памяти. Вместо этого мы предлагаем некое решение более простой проблемы: мы проектируем некий кэш ключ- значение, который предоставляет производительность, близкую к самому идеальному кэшированию. Однако, наше решение вовсе не применяет операции чтения RDMA.

В данной статье мы представляем HERD, некий кэш ключ- значение, который использует свойства RDMA для предоставления низкой латентности и высокой производительности. Позднее мы продемонстрируем, что операции чтения RDAM не могут быть приспособлены для получения полной производительности имеющегося оборудования RDMA. В HERD клиенты передают свои запросы в память сервера при помощи операций записи. Имеющийся ЦПУ сервера опрашивает свою память относительно получаемых запросов. При получении некоего нового запроса он исполняет операции GET и PUT в своих локальных структурах и отправляет соответствующий отклик обратно своему клиенту. Так как производительность операции записи RDMA не масштабируется вместе с имеющимся числом исходящих соединений, получаемый отклик отправляется как некое сообщение SEND померх соединения дейтаграмм.

Наша работа достигает три основные цели:

Наши последующий раздел представляют краткое введение в хранилища ключ- значение и RDMA, а также описывают последние усилия в построении хранилищ ключ- значение с использованием RDMA. Раздел 3 обсуждает обоснование наших проектных решений и демонстрирует что глаголы обмена сообщениями являются лучшим выбором чем операции чтения RDMA для систем ключ- значение. Раздел 4 обсуждает общие проект и реализацию нашего кэша ключ- значение. В Разделе 5 мы выполняем оценку нашей системы в кластере из 187 узлов и сопоставляем её с FaRM [⁸] и Pilaf [²¹].

Данный раздел предоставляет базовую информацию по хранилищам ключ- значение и системам кэширования, которые составляют сердцевину HERD. Затем мы предоставляем некий обзор RDMA, покольку он существенен для остального текста нашей статьи.

Основанные на оперативной памяти хранилища ключ- значение и системы кэширования широко распространены в крупномасштабных службах Интернет. Они используются как первичными хранилищами (такими как Redis [⁴] и RAMCloud [²³]), так и системами кэширования для интерфейса с лежащими в основе базами данных (например, Memcached [⁵]). На своём базовом уровне эти системы экспортируют некий традиционный интерфейс GET/PUT/DELETE. Внутри себя они используют разнообразные структуры данных для предоставления быстрого, с уровнем эффективности оперативной памяти доступом к лежащим в его основе данным (например, таблице хэширования или индексам на основе дерева).

В данной статье мы сосредоточимся на имеющейся архитектуре взаимодействия для поддержки обоих этих приложений; мы воспользуемся реализацией системы кэширования для повсеместной проверки своего получаемого в результате решения.

Хотя хранилища объектов в оперативной памяти последнего времени применяют как решения на основе деревьев, так и хэш- таблиц, данная статья сосредоточится на хэш- таблицах в качестве основной структуре индексации данных. Решения с хэш- таблицами имеют длинную и богатую историю и основное предпочтение, которое кто- то делает, в основном базируется на желательных целях оптимизации. В последние годы некоторые системы применяли развитые архитектуры таблиц хэширования, такие как хэширование Cuckoo [²⁴, ¹⁷, ⁹] и Hopscotch [¹²]. Таблицы хэширования Cuckoo являются привлекательным выбором для построения быстрых систем ключ- значение [⁹, ³¹, ¹⁷], потому что при K функциях хэширования (обычно K равен 2 или 3), они требуют только K выборок из памяти для операций GET плюс некоторое дополнительное развёртывание ссылки, если эти значения не хранятся в самой этой таблице. Во многих рабочих потоках GET составляют более 95% всех операций [⁶, ²²]. Это свойство делает хэширование Cuckoo привлекательной основой для хранилища ключ- значение на базе RDMA [²¹]. Архитектуры на основе Cuckoo и Hopscotch часто сосредотачиваются на рабочих потоках с интенсивным чтением: операции PUT требуют перемещения значений внутри имеющихся таблиц. В данной статье мы выполнили оценки и для сбалансированных рабочих потоков (по 50% PUT/GET), и для нагрузок с интенсивным чтением (95% GET).

Для обоих типов рабочих потоков без ограничений на свою производительность, HERD внутри себя применяет некую структуры данных cache, которая может выселять элементы при своём заполнении. Однако, мы сосредоточимся на самой архитектуре сетевого взаимодействия - наши результаты распространяются и на системы хэширования и на хранилища ключ- значение до тех пор, пока выполняемая реализация достаточно быстрая, чтобы нуждаться в архитектуре высокоскоростного взаимодействия. Архитектура кэширования HERD базируется на самой последней системе MICA [¹⁸], которая предоставляет как семантику кэширования, так и семантику хранения. Режим кэширования MICA применяет ассоциативную индексацию с потерями для установления соответствия от ключей к указателям и сохраняет все значения в некотором циклическом журнале, который является эффективным в отношении оперативной памяти, избегая фрагментации и не требуя затратного сбора мусора. Данное решение требует всего лишь двух произвольных доступов к памяти как для операций GET, так и для операций PUT.

RDMA (Remote Direct Memory Access - удалённый прямой доступ к памяти) позволяет одному компьютеру получать прямой доступ к памяти без привлечения самой операционной системы в любом из хостов. Это делает возможным обмены с нулевым копированием, а также снижение латентности и накладных расходов ЦПУ. В данной работе мы сосредоточимся на двух видах предоставляющего RDMA интерконнекта: InfiniBand и RoCE (RDMA over Converged Ethernet). Однако мы полагаем, что наш решение применимо и для прочих поставщиков RDMA, таких как iWARP, Quadrics и Myrinet {Прим. пер.: а также Ангара}.

InfiniBand является сетевой средой многопортовой коммутации широко применяемой в высокопроизводительных вычислительных системах. RoCE является относительно новым сетевым протоколом , который делает возможным прямой доступ к памяти поверх Ethernet. NIC InfiniBand и RoCE достигают низкой латентности за счёт реализации определённых уровней сетевого стека (с транспортного по физический уровни) в аппаратных средствах, а также предоставляя RDMA и обход ядра. В данном разделе мы представим некий обзор функциональности RDMA и терминологии, которые применяются на протяжении остальной части данной статьи.

Сопоставление со стандартным Ethernet

Чтобы отличать RoCE, мы будем именовать сетевые среды Ethernet без предоставления RDMA как "классический Ethernet". В отличии от NIC классического Ethernet, NIC RDMA (RNIC) предоставляет надёжную доставку в приложения за счёт употребления основанного на оборудовании повторного отправления утраченных пакетов. Кроме того, RNIC предоставляет для всех взаимодействий обход ядра. Эти два момента снижают всеобщую латентность а также загрузку ЦПУ в вашим взаимодействующих хостах. Типичным значением латентности (1/2 RTT) в InfiniBand/ RoCE является 1 мкс {Прим. пер.: задержка на хоп Ангара 130 нс}, в то время как классические решения на основе Ethernet [², ¹⁸] предоставляют 10 мкс. Основная часть этого зазора возникает за счёт различных акцентов в архитектуре самих NIC. По мере снижения стоимости соответствующего оборудования RDMA увеличивает своё присутствие в центрах обработки данных [²¹]. Стоимость RNIC 40 Gbps ConnectX-3 Mellanox составляет около $500, в то время как адаптеры 10 Gbps Ethernet стоят от $300 до $800. Предложение RoCE ещё форсировало присутствие RDMA, так как он позволяет сокетным приложениям работать в одной и той же сетевой среде совместно с приложениями RDMA.

Глаголы и пары очередей

Пространство пользователя программ осуществляет доступ RNIC напрямую при помощи функций, именуемых глаголами (verbs). Имеются различные типы глаголов. Наиболее существенными из них являются чтение RDMA (READ), запись RDMA (WRITE), SEND и RECEIVE. Глаголы отсылаются приложениями в очереди, которые поддерживаются внутри самой RNIC. Очереди всегда присутствуют в виде пар: некая очередь отправки (send queue) и очередь приёма (receive queue) формируют пару очередей (QP, queue pair). Каждая пара очередей имеет некую связанную с ней очередь завершения (CQ, completion queue), которую сам RNIC заполняет по мере завершения исполнения глагола.

Значение глагола формирует некое определение семантики самого интерфейса, предоставляемого RNIC. Существует два вида семантики глаголов: семантика памяти и семантика канала. {Прим. пер.: в современных реализациях RDMA также имеются атомарные глаголы Fetch и Add/ Cmp и Swap.}

Семантика памяти: Определённые глаголы RDMA (READ и WRITE) имеют семантику памяти: они определяют значения удалённых адресов памяти для переноса на них операций. Такие глаголы являются односторонними: ЦПУ отвечающей стороны не знает о происходящей операции. Такое отсутствие накладных расходов ЦПУ на отвечающей стороне делает привлекательными односторонние глаголы. Более того, они обладают среди всех глаголов самыми низкими значениями латентности и пропускной способности.

Семантика канала: SEND и RECEIVE (RECV) имеют семантику канала, т.е. полезная нагрузка SEND записывается в адреса удалённой памяти, которые определяются соответствующей отвечающей стороной в предварительно отправляемом RECV. Некоторой аналогией для этого может служить реализация небуферированных сокетов, которые требуют вызова read() перед появлением отправляемого пакета. SEND и RECV являются двусторонними, поскольку ЦПУ отвечающей стороны должен выставить некий RECV для обработки какого- то входящего SEND. В отличии от случая глаголов памяти, в общий процесс вовлечён ЦПУ отвечающей стороны. Двусторонние глаголы имеют слегка более высокую латентность и более низкую пропускную способность в сравнении с односторонними глаголами и отвергались как неблагоприятные для систем ключ- значение [²¹, ⁸].

Хотя глаголы SEND и RECV технически являются глаголами RDMA, мы отличаем их от READ и WRITE. Мы называем READ и WRITE глаголами RDMA, в то время как SEND и RECV именуем глаголами обмена сообщениями.

Глаголы обычно выставляются в очередь отправки QP (за исключением RECV, который выставляется в очередь приёма). Для выставления какого- то глагола в соответствующем RNIC некое приложение выполняет вызов в соответствующем драйвере RDMA пространства пользователя. Затем этот драйвер подготавливает некий WQE (Work Queue Element - элемент очереди исполнителя) в оперативной памяти соответствующего хоста и звонит в дверной звонок ответного RNIC через PIO (Programmed IO). Для ConnectX и более новых RNICs, соответствующий дверной звонок содержит весь WQE [²⁷]. Для глаголов WRITE и SEND, их WQE связывается с полезной нагрузкой, которая подлежит отправке в соответствующий удалённый хост. Некая полезная нагрузка вплоть до предельного размера PIO (в нашей установке 256 байт) может вкладываться в свой WQE, в противном случае она извлекается RNIC через чтение DMA. Вложенная отправка не вовлекает в себя операции DMA, снижая латентность и увеличивая пропускную способность для небольших полезных нагрузок.

Когда соответствующий RNIC выполняет необходимые шаги, относящиеся к данному глаголу, он помещает некое событие завершения в связанную со своей парой очередей очередь исполнения (CQ) через некую запись DMA. Применение завершающих событий добавляет дополнительные накладные расходы в шину PCIe своего RNIC. Эти накладные расходы могут быть уменьшены за счёт использования избирательных вызовов (selective signaling). При применении избирательных вызовов к очереди с размером S вплоть до S-1 последовательных глаголов могут не снабжаться сигналами, т.е. для этих глаголов могут не помещаться события исполнения. Очередь приёма не может применять избирательные вызовы. Так как S является большис (~ 128), взаимозаменяемо используем термины "избирательных вызовов" и "освобождения от сигналов" (selective signaling и unsignaled).

Виды доставки

Доставка RDMA может быть с выполнением соединения или без него (connected или unconnected). Доставка с соединением требует некоторого соединения между двумя парами очередей, которые взаимодействуют исключительно друг с другом. Современные реализации RDMA поддерживают два основных вида доставки с соединением: RC (Reliable Connection - достоверное соединение) и UC (Unreliable Connection - ненадёжное соединение). В UC нет никаких подтверждений приёма пакетов; пакеты могут теряться и находящиеся зависящие от них сообщения могут отбрасываться. Так как UC не вырабатывает пакетов ACK/ NAK, он вызывает меньший сетевой обмен чем RC.

При доставке без установления соединения одна пара очередей может взаимодействовать с любым числом прочих пар очередей. Имеющаяся в настоящее время реализация предоставляет только один вид транспорта без установления соединения: UD (Unreliable Datagram - ненадёжные дейтаграммы) {Прим. пер.: так в оригинале, на момент перевода реализации RDMA поддерживают достоверный обмен дейтаграммами - RD, Reliable Datagram, см., например, Обыкновенное чудо OmniPath, хотя отметим, что в этом релизе и описывается всего лишь эмуляция RDMA со стороны OmniPath. Сам OmniPath внутри себя применяет иной набор глаголов, но его микрокод эмулирует глаголы RDMA, хотя и при потере производительности.}. RNIC поддерживает состояние для каждой активной очереди в своём кэше контекста пар очередей, поэтому доставка дейтаграмм может лучше масштабироваться для приложений с топологией один- ко- многим.

InfiniBand и RoCE употребляют управление потоком на канальном уровне (link- level), а именно, управление потоком на основе доверительности и управление потоком с приоритетами (credit-based flow control и Priority Flow Control). Даже при ненадёжной доставке (UC/ UD) пакеты никогда не теряются из- за переполнения буферов. В качестве причин утраты пакетов могут выступать битовые ошибки в кабелях и аппаратные сбои, которые чрезвычайно маловероятны. По этой причине, наша разработка, аналогично выбору Facebook и прочих [²²], приносит в жертву транспортный уровень повторной доставки в угоду более часто востребованному варианту производительности за счёт редких повторов на уровне приложений.

Некоторые виды доставки поддерживают только какое- то подмножество из всех доступных глаголов. Таблица 1 перечисляет те глаголы, которые поддерживаются каждым видом доставки {Прим. пер.: в данном переводе таблица расширена столбцом RD и строкой с атомарными глаголами (Fetch и Add/ Cmp и Swap)}. Рисунок 1 отображает шаги DMA и сетевой среды, вовлечённые в выставлении глаголов.

 

Рисунок 1

Вовлекаемые в выставление глагола этапы. Показанные точками стрелки являются операции PCIe и PIO. Сплошные, прямые стрелки являются операциями DMA: тонкие линии обозначают записи событий завершения. Толстые волнистые линии представляют пакеты данных RDMA, а тонкие волнистые линии являются ACK.

Pilaf [²¹] является хранилищем ключ- значение, которое служит для целей высокой производительности и низкого использования ЦПУ. Для GET, доступа клиента и таблицы хэширований Cuckoo в его сервере используется READ, что в среднем требует 2.6 отправок с возвратом для отдельного запроса GET. Для PUT клиенты отправляют свои запросы в имеющийся сервер при помощи сообщения SEND. Для гарантии согласованности GET при наличии одновременных PUT, структуры данных Pilaf обладают самопроверкой: все записи таблицы хэширования дополняются двумя 64- битными контрольными суммами.

Второе хранилище ключ- значение, с которым мы проводили сопоставление, основывается на хранилище, разработанным в FaRM [⁸]. Важно отметить, что FaRM предназначена для более распространённой целевой аудитории платформ распределённых вычислений, которая выставляет память некоторого кластера машин как некое совместно используемое адресное пространство; мы проводили сравнение только с хранилищем ключ- значение, реализуемым поверх FaRM, которое мы именуем FaRM-KV. В отличии от архитектуры клиент- сервер в Pilaf и HERD, FaRM является симметричным, более приличествующим решениям в качестве кластерной архитектуры; каждая машина выступает и как сервер, и как клиент.

Решение FaRM предоставляет для сопоставления два компонента. Первым является решение хранения ключ- значение, которое применяет некий вариант хэширования Hopscotch [²²] для создания осведомлённых о местоположении хэш- таблиц. Для GET клиенты выполняют READ определённых последовательных слотов Hopscotch, один из которых скорее всего содержит необходимый ключ. Ещё одно выполнение READ требуется для выборки самого значения, если оно не хранится в внутри данной таблице хэширования. Для GET клиенты применяют операцию WRITE своих запросов в некий циклический буфер в оперативной памяти данного сервера. Сам сервер опрашивает это буфер для определения новых запросов. Такое решение не является особенным для FaRM - мы применили его только как некую сохранившуюся альтернативу архитектуре Pilaf на основе Cuckoo для выполнения более глубокого сравнения с HERD.

Второй важной стороной FaRM является его симметричность: в этом он отличается от Pilaf и HERD. Для небольших пар ключ- значение с фиксированным размером FaRM может "встраивать" такое значение в сам ключ. При встраивании архитектура FaRM на основе чтения всё же достигает меньшего максимума пропускной способности в сопоставлении с HERD, но при этом меньше использует ЦПУ. Этот компромисс может быть справедлив в тех кластерах, в которых все машины слишком заняты чтобы выполнять вычисления; здесь мы не проводили оценок симметричного варианта применения, однако он заслуживает внимания для пользователей любых решений.

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

Как мы уже советовали в Разделе 1, одним из центральных решений, которое предстоит выбрать, состоит в том, следует ли нам применять глаголы памяти (READ и WRITE RDMA), или глаголы обмена сообщениями (SEND и RECV). Последние работы в сообществе подобных систем и сетевых сред, к примеру, были сосредоточены на операция READ RDMA в качестве некоторого строительного блока, поскольку они целиком обходят имеющиеся удалённые сетевой стек и ЦПУ для GET [²¹, ⁸]. В противовес этому, однако, сообщество HPC более широко применяло обмен сообщениями, причём как для кэширующих ключ- значение [¹⁴], так и для взаимодействия с обычным назначением [¹⁶]. Эти последние системы масштабировались до тысяч машин, но предоставляли более низкую пропускную способность - менее одного миллиона операций в секунду при memcached [¹⁴]. Основная причина для низкой пропускной способности в [¹⁴] не очевидна, но мы подозреваем, что именно архитектура приложения делает данную систему неспособной выжимать всю производительность из имеющихся RNIC.

Всё ещё остаётся значительным зазор между этими двумя направлениями проведения работ и, согласно тому что нам известно, HERD является самой первой системой, которая предоставляет всё наилучшее из этих обоих миров: пропускную способность даже лучшую чем ту, которой обладают системы на базе RDMA при масштабировании до нескольких сотен клиентов.

HERD применяет гибридный подход, применяя и RDMA и обмен сообщениями для достижения наилучшего эффекта. Тем не менее чтение RDMA не являются привлекательными, поскольку они требуют множества доставок с возвратом. В HERD клиенты вместо этого применяют запись своих запросов в соответствующий сервер при помощи RDMA поверх UC (Unreliable Connection). Такая запись помещает все запросы PUT или GET в область памяти для каждого клиента в данном сервере. Сам сервер выполняет опрос этих областей относительно новых запросов. После получения одного из них, процесс данного сервера выполняется обычным образом применяя свои локальные структуры данных. Затем он отправляет некий ответ своему клиенту при помощи глаголов сообщений: SEND поверх Unreliable Datagram.

Чтобы пояснить почему мы применяем такой гибрид RDMA и обмена сообщениями мы описываем соответствующие эксперименты и анализы производительности, которые их поддерживают. В особенности мы поясняем почему мы предпочитаем применять записи RDMA вместо чтений, не затрагивая преимуществ аппаратных повторов при вариантах с ненадёжной доставкой, а также применяем глаголы обмена сообщениями в пренебрежении общепринятой мудростью что они медленнее RDMA.

На протяжении остальной части статью мы применяем для чтений RDMA термин READ, а для записей RDMA WRITE. В данном разделе мы предоставляем микробенчмарки кластера Apt Emulab [²⁹], большого современного тестового оборудования, снабжённого 56 Gbps InfiniBand. Так как Apt имеет только InfiniBand, в Разделе 5 мы также применяем кластер Susitna NSF PRObE [¹¹] для оценок c RoCE. Аппаратные конфигурации этих кластеров приводятся в Таблице 2.

Данные эксперименты используют одну машину сервера и несколько машин клиентов. Мы отмечаем машину сервера как M_S, а её RNIC как RNIC_S. Машина клиента i обозначается как C_i. Данные машины сервера и клиента могут соответственно исполнять множество процессов сервера и клиента. Мы называем некое сообщение от клиента к серверу запросом, а ответ сервера клиенту откликом. Вызывающий некий глагол хост является запрашивающей стороной, а его получатель стороной отклика. Для SEND и WRITE без сигнала поверх UC соответствующий хост получателя на самом деле не отправляет отклика, но мы всё ещё продолжаем именовать его стороной отклика.

Для экспериментов с пропускной способностью процессы сопровождают некое окно определённых невыполненных глаголов в их очередях отправки. Применение окон позволяет нам насыщать наши RNIC меньшим числом процессов. Во всех своих экспериментах пропускной способности мы вручную настраиваем размер такого окна для достижения максимальной агрегированной пропускной способности.

Для использования WRITE вместо READ имеется ряд преимуществ. WRITE может исполняться поверх доставки UC, которая сама по себе дарует определённые преимущества производительности. Поскольку стороне отклика не требуется отправлять пакеты обратно, его RNIC выполняет меньше обработки и тем самым может поддерживать более высокую производительность нежели вариант с READ. В конце концов, как можно ожидать, значение задержки WRITE без установки сигнала составляет примерно половину (1/2 RTT) от READ. Это позволяет заменить одну операцию READ на две WRITE, одну от- клиента- к- серверу и одну от- сервера- к- клиенту (формирующих пару запрос- отклик) без значительного увеличения латентности.

WRITE имеет меньшую латентность

Замер значения латентности WRITE без выставления сигнала не столь очевиден, поскольку соответствующая запрашивающая сторона не имеет индикации завершения. Тким образом, мы измеряем её косвенным образом через значение латентности ECHO. При некотором ECHO клиент передаёт какое- то сообщение в сервер, а этот сервер транслирует то же самое сообщение обратно своему клиенту. Если такое ECHO реализовать при помощи WRITE без выставления сигнала, оно составит почти половину значения задержки ECHO.

Мы также измерили значение латентности операций READ и WRITE с выставлением сигнала. Поскольку эти операции снабжены сигналом, для измерения латентности мы воспользовались их событием завершения. Для WRITE мы также замерили значение латентности с вложенной полезной нагрузкой.

Рисунок 2 отображает полученные средние значения латентности таких измерений. Для ECHO мы применяли WRITE с вложением и без выставления сигнала. В наших RNIC максимальный размер такой вложенной полезной нагрузки составляет 256 байт. Следовательно, значения графиков для WR-INLINE и ECHO показаны только до 256 байт.

 

Рисунок 2

 
(a) Настройка для измерения латентности глаголов и ECHO. Мы используем один процесс клиента для вызова операции в одном процессе сервера.

 
(b) Латентность односторонней WRITE составляет половину латентности ECHO Операции ECHO используются для глаголов без выставления сигнала.

Глаголы без выставления сигнала: Для полезных нагрузок вплоть до 64 байт, значение латентности ECHO близко к задержкам READ, что подтверждает, что значение латентности односторонней операции WRITE составяет примерно половину от значения задержки READ. Для ECHO большего размера значение латентности растёт, так как определённое время тратится на запись в соответствующий RNIC через PIO.

Глаголы с сигналом: Сплошные линии на Рисунке 2 показывают значения латентности для трёх глаголов с сигналом - WRITE, READ и WRITE с вложением (WR-INLINE). Значения латентности для READ и WRITE близки, поскольку общая длина пути перемещения по сетевой среде/ PCIe идентична. За счёт обхода одной операции DMA вложение существенным образом уменьшает значение задержек небольших WRITE.

У WRITE выше пропускная способность

Для оценки пропускной способности, во- первых, необходимо обратить внимание, что взаимодействии с одним сервером большого числа машин клиентов, разные глаголы действуют совершенно различным образом при их использовании в этих клиентах (общающихся с одним сервером) и в самом сервере (общающемся со множеством клиентов).

Входящая пропускная способность: Для начала мы измеряем значения пропускной способности для глаголов входа (inbound), т.е. общее число глаголов, которое множество удалённых машин (клиентов) могут выпускать к одной машине (серверу). Применяя указанную выше нотацию, C₁, ..., C_N вызывают операции в отношении M_S, как это показано на Рисунке 3a. Рисунок 3b показывает накапливаемую пропускную способность, наблюдаемую по всем активным машинам. Для полезных нагрузок вплоть до 128 байт, WRITE достигает 35 Mops, что примерно на 34% выше чем максимальное значение пропускной способности READ (26 Mops). Что интересно, надёжные WRITE доставляют значительно более высокие значения чем READ пренебрегая идентичностью их пути InfiniBand. Это объясняется следующим образом: записи требуют меньшего сопровождения состояния как на уровне RDMA, так и на уровне PCIe, так как инициатору не требуется ожидать какого бы то ни было отклика. Однако, для чтений такие запросы должны сопровождаться в памяти самого инициатора вплоть до появления отклика. На соответствующем уровне RDMA каждая пара очередей может обслуживать только несколько отложенных запросов READ (в наших RNIC 16). Аналогично, на уровне PCIe, чтения выполняются при помощи не откладываемых (non-posted) транзакций, в то время как записи применяют более экономичные транзакции с отсрочкой (posted).

 

Рисунок 3

 
(a) Настройка измерения входной пропускной способности. Каждый процесс клиента взаимодействует только с одним процессом сервера.

 
(b) Для полезных нагрузок с умеренным размером WRITE имеет намного более высокую пропускную способность чем READ.

Хотя значения пропускной способности WRITE поверх UC и RC примерно равны, применение UC всё- таки предпочтительнее: оно требует меньше обработки в отношении RNIC_S и HERD использует её, сберегая мощность на отклики SEND.

Исходящая пропускная способность: Далее мы змеряем пропускную способность для исходящих глаголов. В этом случае M_S вызывает операции в отношении C₁, ..., C_N. Как показано на Рисунке 4a, в M_S имеется N процессов. Процесс i^й взаимодействует только с C_i (основная проблема в масштабировании состоит во взаимодействии всех- со- всеми, что мы объясним в Разделе 3.3). Рисунке 4b отображает значения пропускной способности, достигаемые M_S для различных размеров полезной нагрузки. При малых размерах, WRITE и SEND с вложением имеют значительно более высокую пропускную способность нежели READ. При больших размерах значения всех вариантов WRITE и SEND ниже чем для READ, но они никогда не опускаются ниже 50% значения пропускной способности READ. Тем самым, даже для таких элементов с большим размером применение для откликов отдельного WRITE (или SEND) остаётся лучшим выбором по отношению к использованию множества READ для элементов ключ- значение.

 

Рисунок 4

 
(a) Настройка измерения исходящей пропускной способности. Каждый процесс сервера взаимодействует только с одним процессом клиента.

 
(b) Для небольших полезных нагрузок WRITE с вложением имеет более высокую исходящую пропускную способность чем READ.

Пропускная способность ECHO: представляет интерес по двум причинам. Во- первых, она предоставляет некое ограничение сверху для соответствующей величины кэширования ключ- значение на основе одного прохода в обе стороны при взаимодействии. Во- вторых, ECHO помогает охарактеризовать общую мощность обработки данного RNIC: хотя заявленная скорость обмена сообщениями 35 Mops, в обоих направлениях она может обрабатывать намного больше сообщений.

ECHO состоит из сообщения запроса и сообщения отклика. Изменение значений типов глаголов и доставки даёт совершенно различные реализации ECHO. Рисунок 5 отображает значения пропускной способности для некоторых возможных комбинаций и при полезных нагрузках в 32 байта. Данный рисунок также показывает, что использование вложений, избирательных вызовов и доставки UC значительно увеличивают общую производительность.

 

Рисунок 5

Пропускная способность ECHO при сообщениях длиной 32 байта. При WR-SEND соответствующий отклик отправляется поверх UD.

ECHO достигает максимальной пропускной способности (26Mops) когда и сам запрос, и отклик выполняются в виде записей RDMA. Тем не менее, как показывается в Разделе 3.3, такой подход не масштабируется при очень большом числе соединений. HERD применяет записи RDMA (поверх UC) для запросов и SEND (поверх UD) для откликов. Сервер ECHO с применением такого гибрида также достигает 26 Mops - это даёт значение производительности на уроне ECHO с WRITE, но с намного более лучшим масштабированием.

За счёт избегания значительных накладных расходов отправки RECV в свой сервер наш метод запросов на основе WRITE и откликов на базе SEND предоставляет лучшую производительность нежели ECHO с чистой основой на SEND. Тем не менее, интересно отметить, что после включения всех оптимизаций, общая производительность ECHO на основе SEND (без RDMA операций) составляет 21 Mops, что более трёх четвертей пикового значения входящей пропускной способности READ (26 Mops). И Pilaf, и FaRM отметили, что чтения RDMA в высшей степени превосходят ECHO на базе SEND, что находится в соответствии с нашими результатами если исключить наши оптимизации. При наличии данных оптимизаций, однако, SEND значительно превосходит READ в вариантах применения единого ECHO на основе SEND вместо множества READ для запроса.

Наши эксперименты показывают, что определённые решения ECHO, с различными степенями масштабируемости, могут выполняться лучше нежели решения со множественными READ. С точки зрения сосредоточения на сетевой среде это удача: это также означает, что решения, которые применяют только один RTT поперёк центра обработки данных, потенциально могут превосходить решения со множеством RTT как в отношении пропускной способности, так и касательно задержек.

Обсуждение пропускной способности глаголов: Карты ConneсtX-3 заявляют о поддержке 35 миллионов сообщений в секунду. Наши эксперименты показывают, что данная карта может достигать такой скорости для входящих WRITE (Рисунок 3b) и слегка превосходить его для очень маленьких исходящих WRITE (Рисунок 4b). Все прочие глаголы медленнее 30 Mops вне зависимости от размера операции. Хотя производитель и не декларирует двунаправленную пропускную способность обмена сообщениями, мы эмпирически знаем, что RNIC_S способен обслуживать 30 миллионов ECHO в секунду (ECHO на основе WRITE достигает 30 Mops при полезной нагрузке 16 байт; Рисунок 5 использует полезную нагрузку 32 байта), или, по крайней мере, 60 Mops в общем числе из входящих WRITE и исходящих SEND.

Снижения пропускной способности можно приписывать различным факторам:

Наши предыдущие эксперименты не показали что с ростом общего числа соединений скорость доставки в них начинает падать. Для снижения стоимости оборудования, энергопотребления и сложности проектирования, RNIC имеет на борту очень ограниченный объём оперативной памяти (SRAM) для кэширования таблиц трансляции адресов и содержимого контекста пар очередей [²⁶]. Непопадание в таком кэше требует некоторой транзакции PCIe для выборке требующихся данных из памяти данного хоста. Производительность начинает страдать при исчерпании нагрузочной способности на входе или на выходе в данном кэше. Потенциально важно избегать этот эффект как при масштабировании кластера, так и по той причине что он оказывает влияние на решения самого кэша или архитектуры хранения. К примеру, для выстраиваемого нами решения кэширования в разделах HERD, собственно пространство ключей между различными процессами сервера с целью достижения эффективной загрузки ЦПУ и оперативной памяти. Эти разделы в последующем увеличивает нагрузочные возможности на входе и на выходе соединений для некоторой отдельной машины.

Для оценки данного эффекта мы изменили свои эксперименты с пропускной способностью, разрешив взаимодействия всех- со- всеми. Мы применяем N процессов клиентов (по одному процессу для каждого из клиентов C₁, ..., C_N) и N процессов сервера в M_S. Для измерения производительности на входе некий процесс сервера выбирает случайным образом какого- то клиента и вызывает в нём WRITE. Результаты этих экспериментов сведены в Рисунке 6. Выделим некоторые результаты:

 

Рисунок 6

Сопоставление UD и UC для взаимодействия все- со- всеми при полезной нагрузке в 32 байта. Входящие WRITE поверх UC и исходящие SEND поверх UD хорошо масштабируются вплоть до 256 пар очередей. Исходящие WRITE поверх UC масштабируются недостаточно. Все операции с вложением и без выставления сигнала.

Бедное масштабирование исходящих WRITE: Для N = 16 имеется 256 активных пар очередей в RNIC_S и общая пропускная способность от сервера- к- клиенту деградирует на 21% от максимального значения пропускной способности исходящих WRITE (Рисунок 4b). При множестве активных пар каждый выставляемый глагол может взывать непопадание в кэш, определённым образом приводя к деградации кэширования.

Надлежащее масштабирование входящих WRITE: Пропускная способность от- клиента- к- серверу высокая даже для N = 16. Основной причиной для этого очереди операций исходящих глаголов обслуживаются на выполняющих запрос RNIC, а на осуществляющих отклик RNIC сопровождается очень небольшое состояние. Тем самым, RNIC отклика может поддерживать намного большее число активных пар очередей без залезания в промахи кэширования. Более высокие накладные расходы запрашивающей стороны компенсируются по причине того, что клиенты численно превосходят свой сервер.

В другом своём эксперименте мы воспользовались 1600 процессами клиентов, распределёнными по 16 машинам для вызова WRITE поверх UC к одному процессу сервера. HERD применяет такую конфигурацию многие- к- одному для снижения общего числа активных подключений на своём сервере (Раздел 4.2). Такая конфигурация также достигает 30 Mops.

Исходящие WRITE плохо масштабируются только потому, что RNIC_S должен управлять большим числом пар очередей соединений. Данную проблему невозможно решить если мы применяем доставку с соединением (RC/UC/XRC), поскольку для них требуется по крайней мере столько же пар очередей в M_S, каково общее число машин клиентов. Масштабирование исходящих взаимодействий, таким образом, обязывает применять дейтаграммы. Доставка UD поддерживает взаимодействие один- ко- многим, т.е. одна очередь UD может применяться для вызова операций во множестве очередей удалённых UD. Основной проблемой при применении UD в высокопроизводительных приложениях является то, что они поддерживают только глаголы обмена сообщениями и никаких глаголов RDMA.

К счастью, глаголы обмена сообщениями обкладывают высокими накладными расходами только сторону отправки. Отправители могут напрямую отправлять свои запросы; только сам отправитель должен предварительно выставлять некий RECV перед тем как можно будет обработать SEND. Для такого отправителя та подлежащая исполнению работа по вызову SEND идентична той, которая требуется для выставления некоторого WRITE. Рисунок 6 показывает, что при исполнении поверх доставки Unreliable Datagram, пропускная способность стороны SEND является высокой и хорошо масштабируется со значительным числом соединений клиентов.

Незначительная деградация пропускной способности SEND свыше 10 клиентов происходит из- за того, что SEND не выставляют сигналы, т.е. процессы сервера не получают указания о завершении глагола. Это приводит к тому, что такие процессы сервера переполняют RNIC_S очень большим числом незавершённых операций, что приводит к промахам в кэше внутри данного RNIC. Так как HERD применяет SEND для откликов на запросы, он может применять новые запросы в качестве индикации своего завершения старых SEND, тем самым избегая данную проблему.

Для оценки того, будут ли такие движимые сетевой средой архитектурные решения работать в приложениях ключ- значение из реальной жизни, мы реализовали некий кэш KV {ключ- значение} на базе RDMA с названием HERD, основываясь на самых последних высокопроизводительных решениях ключ- значение. Наша установка HERD состоит из одной машины сервера и некоторого числа машин клиентов. Имеющаяся машина сервера запускает N_S серверных процессов. N_C клиентских процессов единообразно распределяются по имеющимся машинам клиентов.

Основной фундаментальной целью данной статьи является оценка наших сетевых и архитектурных решений в соответствующем контексте систем ключ- значение. Мы не сосредотачиваемся на наилучших серверных структурах данных ключ- значение, а вместо этого следуем имеющимся в MICA [¹⁸] решениям.

MICA является близким к реальному времени решением кэширования и хранения ключ- значение для классического Ethernet. Мы ограничили своё решение для MICA его режимом кэширования. MICA использует индекс потерь для сопоставления ключей указателям и сохраняет фактические значения в циклическом журнале. При вставке элементы могут выселяться из данного индекса (тем самым производя соответствующий индекс потерь) или из соответствующего журнала неким FIFO образом. В HERD каждый процесс сервера выполняет индексацию для 64Mi ключей и циклический журнал 4 ГБ. И для GET, и для PUT мы применяем алгоритм MICA: каждый GET требует до двух случайных выборок из памяти, а каждый PUT одну.

MICA разбивает своё пространство ключей на определённые разделы на основании какого- то хэширования ключей. В его режиме "EREW" каждое ядро сервера имеет исключительный доступ на чтение и запись к одному разделу. MICA использует функциональность Flow Director [³] современных NIC Ethernet для прямого запроса соответствующему ядру отклика для конкретного заданного ключа. HERD достигает того же самого эффекта посредством выделения в данном сервере памяти запросов для каждого ядра и позволяя клиентам выполнять WRITE своих запросов напрямую в соответствующее ядро.

Маскирование латентности динамической памяти при помощи предварительной выборки

Для обслуживания GET некий сервер HERD должен выполнить две случайных выборки из оперативной памяти, подготовить соответствующий отклик SEND (с значением его ключа, встраиваемого в своём WQE), а затем выставить такой глагол SEND, при помощи функции post_send(). Именно эти выборка из памяти и функция post_send() являются двумя основными источниками задержек в данном сервере. Каждый случайный доступ к памяти занимает 60-120 нс, а функция post_send() требует около 150 нс. Хотя всё это и неизбежно, мы можем скрыть доступ к памяти одного запроса при помощи вычисления другого запроса.

MICA и CuckooSwitch [¹⁸, ³¹] маскируют латентность перекрытием извлечения и предварительной выборки или декодированием и предварительной выборкой запроса. HERD выбирает иной подход: мы перекрываем предварительную выборку при помощи функции post_send(), применяемой для доставки откликов. Для одновременной обработки множества запросов в отсутствии соответствующего драйвера, который сам по себе обрабатывает группу пакетов ([², ¹⁸, ³¹]), HERD создаёт некий конвейер запросов на соответствующем уровне приложений.

В HERD максимальное число выборок из памяти для каждого запроса равно двум. Таким образом, мы создаём некий конвейер запросов из двух стадий. Когда некий запрос находится на стадии i, данного контейнера, он выполняет свой i-й доступ к памяти для своего запроса и выдаёт некую предварительную выборку для своего следующего адреса памяти. При таком подходе запросы осуществляют только доступ к памяти, к которой уже была выполнена предварительная выборка. При обнаружении некоторого нового запроса, сервер вызывает предварительную выборку для необходимых групп индексов запроса, продвигает в имеющемся конвейере свои старые запросы, размещает свои новые запросы и, в конечном итоге, вызывает post_send() чтобы вызвать SEND для отклика для соответствующего выполненного запроса конвейера. Сам процесс сервера ожидает, что соответствующая выдача предварительной выборки завершится ко времени возврата post_send().

Рисунок 7 показывает действенность предварительной выборки. Мы используем сервер ECHO на основе WRITE/ SEND, однако в этот раз данный сервер выполняет N произвольных доступов к памяти перед отправкой своего запроса. Предварительная выборка делает возможной предоставление более высокой пропускной способности меньшим числом ядер: 5 ядер могут предоставить пиковую пропускную способность даже при N = 8. Мы пришли к выводу, что имеется значительный запас для реализации более сложных приложений ключ- значение, например, хранилищ ключ- значение, поверх механизма взаимодействия запрос- отклик HERD.

 

Рисунок 7

Воздействие предварительной выборки на пропускную способность

При большом числе серверных процессов такая конвейерная схема может приводить к некоторой тупиковой ситуации. Некий сервер не способен продолжить свою конвейерную обработку пока не получит некий новый запрос, а некий клиент не сможет продолжать свои запросы пока не получит отклика. Мы избегаем тупиковых ситуаций следующим образом. При выполнении опроса на наличие новых запросов, если некий сервер последовательно получает отказы для 100 итераций, он помещает в свой конвейер холостую команду (no-op).

Клиенты выполняют WRITE своих запросов GET и PUT в непрерывную область памяти своей машины сервера, которая выделяется при инициализации. Эта область памяти именуется областью запроса (request region) и совместно используется всеми имеющимися серверными процессами с установкой соответствия их использования shmget(). Данная область запроса подразделяется на слоты в 1 кБ (максимальный размер элемента ключ- значение в HERD установлен в 1 кБ).

Запросы форматируются следующим образом. Запрос GET составляется только из ключевых хэшей в 16 байт. Запрос PUT содержит 16 байт ключа хэша, поле LEN в 2 байта (определяющее длину значения) и до 1000 байт для самого значения. Для опроса входящих запросов мы применяем порядок слева- направо соответствующих записей DMA RNIC [¹⁶, ⁸]. Мы применяем соответствующее новое поле ключа хэша для опроса новых запросов; тем самым значение ключа записывается в самые правые 16 байт в имеющемся слоте 1 кБ. Некий ненулевой ключ хэша указывает на какой- то новый запрос, поэтому мы не разрешаем своим клиентам применять нулевое значение ключа хэширования. После отправки отклика наш сервер заполняет нулями соответствующее поле ключа хэша, высвобождая его обратно для нового запроса.

Рисунок 8 показывает схему такой области запроса в соответствующей машине сервера. Она состоит из отдельных фрагментов для каждого серверного процесса , которые далее подразделяются на фрагменты для каждого клиента. Каждый фрагмент клиента состоит из W слотов, т.е. каждый клиент может выполнять задержку до W запросов для каждого серверного процесса. Соответствующий размер такой области запроса равен NS · NC · W кБ. При NC = 200, NS = 16 и W = 2, это приблизительно 6 МБ и помещается внутри кэша L3 сервера. Каждый серверный процесс опрашивает свои фрагменты для клиентов на предмет новых запросов карусельным образом (round robin). Если процесс сервера s обнаружил r запросов от клиента с номером с, он опрашивает свою область запроса в соответствующем слоте запроса с номером s·(W · NC)+ (c·W)+r mod W.

 

Рисунок 8

Схема соответствующей области запроса в данном сервере

Некая сетевая конфигурация, применяющая двунаправленное взаимодействие все- ко- всем с доставкой при образовании соединения потребует NC · NS пар очередей в своём сервере. HERD, однако, применяет доставку с соединениями только для взаимодействия со со стороны своего запроса, и тем самым требует только NC подключённых пар очередей. Данная конфигурация работает следующим образом. Некий процесс инициализации создаёт необходимую область запроса, регистрирует её в RNICS, устанавливает соединение UC с каждым клиентом и переходит в спящее состояние. Соответствующий процесс сервера NS затем устанавливает соответствие этой области запроса в своём адресном пространстве при помощи shmget() и и не создаёт никаких соединений для приёмки запросов.

  Отклики

В HERD, отклики отправляются в виде SEND поверх UD. Каждый клиент создаёт NS пар очередей (QP) UD, в то время как процесс сервера применяет только одну UD QP. Прежде чем выполнить запись нового запроса в серверный процесс s, клиент выставляет RECV в свой UD QP с номером s. Этот RECV определяет необходимую область памяти в данном клиенте, в которую будет записан соответствующий отклик сервера. Каждый клиент выделяет некую область отклика (response region), содержащую W · NS слотов отклика: эта область в качестве целевой адресации для соответствующих RECV. После записи W запросов, наш клиент начинает проверять наличие откликов, опрашивая завершения RECV. При каждом успешном завершении он выставляет следующий запос.

Проектирование выполнено таким образом намеренно, чтобы переместить работу с RNIC сервера на клиентский RNIC, исходя из предположения, что машины клиентов обычно осуществляют прочую достойную работу, которая не имеет целью полностью насыщать полосу пропускания сетевой среды 40 или 56 гигабит. Серверы, однако, в таких приложениях как Memcached, зачастую целиком выделяются для этого и в них важно достигать наивысшей полосы пропускания.