Введение

В октябре 2022 г. Gartner опубликовала свое очередное исследование – Magic Quadrant for Distributed File Systems and Object Storage (Published 19 October 2022 – ID G00760026), в котором представила основных игроков рынка консолидированных платформ для сервисов неструктурированных данных в глобальных центрах обработки данных. Хотелось бы сразу подчеркнуть, термин “платформа” в настоящее время более правильный по сравнению с СХД/хранилище, т.к. идет стремительное насыщение подобных решений процессорной мощностью (например, за счет интеграции GPU, FPGA, in-memory обработки, сервисами на основе стандарта Computational Storage и др.). Более того, ряд технологий, используемых в составе таких решений позиционируется для применения реализации HPC-решений (high-performance computing). Т.е. в настоящее время это совсем не те “хранилки”, которые были представлены на рынке для неструктурированного контента 15-20 лет назад.

В данной серии обзоров будут представлены наиболее инновационные распределенные кластерные хранилища, вобравшие в себя последние техно логические достижения. Среди них: Vast Data (среди лучших по присутствию на рынке), WEKA (среди лучших по “видению” рынка),  Lightbits Labs (основной разработчик стандарта NVMeoF/TCP и первая компания, реализовавшая распределенное кластерное хранилище на его основе), Excelero (в настоящее время часть компании NVIDIA), Samsung (один из ключевых разработчиков стандарта для key-value доступа), SK hynix (совместно с Los Alamos National Laboratory добилась очень больших успехов в повышении эффективности по показателю производительности key-value решений). Возможно, список будет расширен.

Немного предыстории

В качестве предшественников хранилищ неструктурированных данных (www.storagenews.ru/31/CAS_312.pdf, “CAS-решения: особенности и применение”) можно отметить – EMC Centera (доступность – апрель 2002 г.), Hitachi Content Archive Platform (CAP, доступность – июнь 2006 г.), HP StorageWorks Reference Information Storage System (RISS, доступность – июнь 2004 г.).

Термин “CAS” (Content Addressable Storage) появился в конце весны 2002 г., когда компания ЕМС анонсировала новый класс устройств – EMC Centera, ориентированный на работу с неизменяемым (фиксированным/постоянным) контентом в составе справочно-информационных и архивных систем. Одновременно с термином “CAS” стал широко использоваться и новый способ доступа к файлам (блоку данных) – не по имени файла или номеру блока данных, а по уникальному идентификатору файла, вычисляемому на основе содержимого файла. При этом к CAS-решениям относились и другие разработки данного класса, непосредственно неиспользующие контентно-адресуемый доступ к файлам.

Рис. 1. Gartner Magic Quadrant for Distributed File Systems and Object Storage (Published 19 October 2022 – ID G00760026).

Среди основных особенностей хранилищ для неструктурированного контента следующие:

• гораздо менее производительный на front-end (в разы и десятки раз) доступ к хранилищу в сравнении с СХД того времени для бизнес-критичных приложений (например, ЕМС Symmetrix);
• стоимость за гигабайт была сопоставима с высокопроизводительными СХД, высокая масштабируемость, доступ к объекту измерялся секундами и более, многосайтовость (не для всех);
• высокая физическая неубиваемость (отказоустойчивость) подобных решений. Например, со слов сотрудников EMC, Centera в прямом смысле расстреливалась, оставаясь при работоспособной.

Современные (то, что уже было доступно лет 8-10 назад) хранили ща подобного класса уже имели гораздо более высокую производительность. Например, на базе hadoop поддерживались бизнес критичные приложения банковского сектора, а объектный доступ служил базой (например, в составе разработки EMC DSSD) для организации блочного доступа. В настоящее время объектный доступ по протоколу S3 реализуется на основе блочного доступа.

С осени 2022 г. начинает возрастать интерес к Key-Value устройствам/хранилищам, например, в составе решений SK hynix, которые на реальном кэйсе давали увеличение производительности в 1000 раз при прямом обмене данными (без CPU) с NVIDIA GPU.

Объектный доступ

Объектный доступ стал активно развиваться с 2006 г., когда AWS запустила Amazon S3 в США, а затем в Европе в ноябре 2007 г. (https://en.wikipedia.org/wiki/Amazon_S3#Sources).

Amazon S3 или Amazon Simple Storage Service – это сервис, предлагаемый Amazon Web Services (AWS), который предоставляет объектное хранилище через интерфейс веб-сервиса. Amazon S3 может хранить объекты любого типа, что позволяет использовать их в качестве хранилища для интернет-приложений, резервного копирования, аварийного восстановления, архивов данных, озер данных для аналитики и гибридного облачного хранилища.

Amazon S3 управляет данными с помощью архитектуры объектного хранилища, целью которой является обеспечение масштабируемости, высокой доступности и низкой задержки с высокой надежностью. Основные единицы хранения Amazon S3 – это объекты, организованные в сегменты (buckets). Каждый объект идентифицируется уникальным ключом, назначаемым пользователем. Сегментами можно управлять с помощью консоли, предоставляемой Amazon S3, программно с помощью AWS SDK или интерфейса прикладного программирования REST. Размер объектов может достигать пяти терабайт.

Семантика файловой системы Amazon S3 отличается от семантики файловой системы POSIX, поэтому файловая система может вести себя не совсем так, как ожидается.

Amazon S3 предлагает восемь различных классов хранилищ с раз личными уровнями требований к надежности, доступности и производительности:

• Amazon S3 Standard (используется по умолчанию). Это хранилище общего назначения для часто используемых данных;
• Amazon S3 Standard-Infrequent Access (Standard-IA) предназначен для менее часто используемых данных, таких как резервные копии и данные аварийного восстановления;
• Amazon S3 One Zone-Infrequent Access (One Zone-IA) работает так же, как Standard-IA, но хранит данные только в одной зоне доступности;
• Amazon S3 Intelligent-Tiering автоматически перемещает объекты в хранилище более экономичного класса;
• Amazon S3 на Outposts предоставляет хранилище для установок, не размещенных на Amazon;
• Amazon S3 Glacier Instant Retrieval – это недорогое хранилище для редко используемых данных, которые по-прежнему требуют быстрого извлечения;
• Amazon S3 Glacier Flexible Retrieval также является недорогим вариантом для долгоживущих данных; он предлагает 3 скорости извлечения, от минут до часов;
• Amazon S3 Glacier Deep Archive – еще один недорогой вариант.

Приведенные выше классы хранилищ Amazon S3 Glacier отличаются от Amazon Glacier, который представляет собой отдельный продукт с собственными API.

Размер объекта в S3 может составлять от 0 байт до 5 ТБ. Если раз мер объекта превышает 5 ТБ, его необходимо разделить на куски перед отправкой. При загрузке Amazon S3 допускает максимум 5 ГБ за одну операцию загрузки; следовательно, объекты размером более 5 ГБ должны быть загружены через API загрузки S3 с несколькими компонентами.

Key Value устройства/хранилища/доступ

Набор команд NVM Express^® Key Value (NVMe-KV), ратифицированный в июне 2020 года, обеспечивает доступ к данным на пространство имен NVMe^® SSD используя ключ, а не адрес логического блока [1]. Набор команд NVMe-KV получил свое название, потому что его данные обрабатываются ключом, который позволяет пользователям получить доступ к значению переменного размера (например, объекту) и обойти накладные расходы хоста, поддерживающего таблицу преобразования. Набор команд NVMe-KV позволяет указать ключ, а затем этот ключ обращается к фрагменту данных переменной длины. Этот ключ может обращаться к чему угодно, от одного байта до значительно большого объема данных (например, мегабайт).

Одним из первопроходцев и инициаторов разработки key-value SSD (а также стандартов для этого типа доступа) была компания Samsung.

При традиционном блочном хранении диск хранит блоки фиксированного размера, и они идентифицируются по адресам логических блоков. При использовании набора команд NVMe-KV имеется только ключ, который указывает на то, где находятся данные, и эти данные называются значением. Этот ключ передается непосредственно на устройство, что позволяет иметь ключ к физическому сопоставлению, которое происходит на устройстве, вместо сопоставления на хосте от ключа к нескольким логическим блокам, а за тем сопоставлению на устройстве от логических блоков к физическим блокам. Такой подход увеличивает количество транзакций в секунду, экономит вычисления на хосте и удаляет уровень трансляции, что приводит к повышению производительности.

Еще одним преимуществом является то, что набор команд NVMe-KV устраняет накладные расходы на провижининг. Для логического блочного устройства с over provisioned, то есть в наличии больше логических адресов, чем есть физического пространства, необходимо выделять логические блоки, когда вы хотите использовать их повторно. Хранилище KV позволяет обойти этот шаг. При удалении пары ключ-значение физическое дисковое пространство становится непрерывным физическим хранилищем и может быть использовано снова для другой пары ключ-значение, не беспокоясь о том, что для него повторно используется тот же механизм адресации.

Рис. 2. Сравнение и преимущества Key-Value хранилища/устройства с блочным устройством.

Табл. 1. Сравнение блочного и объектного доступа/хранилища с key-value.

Key Value — это эффективный способ поддержки различных протоколов объектного хранилища на уровне устройства и архитектуры. Все приложения, использующие формат объектного хранилища, получат выгоду от Key Value — примерами этого являются Ceph, RocksDB и другие приложения такого рода, имеющие дело с объектами. Если хранятся записи, связанные с уникальным идентификатором, таким как медицинская карта или номер сотрудника, то ключом становится номер медицинской карты или номер сотрудника, и он индексируется непосредственно ко всей записи для этой конкретной информации.

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

Характеристики хранилища Key-Value:

• Key:
  • переменная длина – от 1 байта до 32 байтов и более;
  • уникальный ключ для устройства Key-Value;
• Value: переменная длина (от 1 байта до 4 Гбайт [2], длина может быть равна 0).

Операции Key-Value:

• хранение (Storing) – данные хранятся как одно значение, связанное с ключом (not updatable in place, not extendable in place, complete value);
• получение (Retrieving) – данные извлекаются как одно значение (value), связанное с ключом (может быть частью value);
• удаление – пара ключ-значение может быть удалена;
• листинг (Listing) – возможность представить список всех ключей, хранящихся на устройстве.

Сравнение Key-Value хранилища/доступа с блочным и объектным доступом представлено в табл. 1. Визуальное сравнение Key-Value доступа (и его преимущество) при использовании Key-Value API (при организации доступа через хост) с блочным дано на рис. 2.

ПО управления KV SSD

Пакет ПО с открытым исходным кодом KV SSD включает программное обеспечение хоста, которое работает с KV SSD. Пакет включает в себя библиотеку API, эмулятор, драйвер устройства ядра и набор для оценки производительности под названием kvbench. С помощью пакета пользователи могут оценить производительность нескольких приложений (например, RocksDB, Aerospike и т.д.) на блочном устройстве в дополнение к производительности прямого стека ключ-значение на KV SSD (https://github.com/OpenMPDK/KVRocks).

SNIA KV API (https://www.snia.org/sites/default/files/technicalwork/kvsapi/release/SNIAKeyValueStorageAPIv1.1.pdf, https:// www.snia.org/keyvalue):

• согласован с набором команд NVMe KV;
• предоставляет синхронные и асинхронные функции:
  • Grouping (группировка):
  • выполнено в пользовательской библиотеке (в настоящее время не поддерживается в наборе команд NVMe KV, требуется уточнение, прим. ред.);
  • ключи фиксированной длины;
  • позволяет использовать часть ключа для группировки ключей;
  • требуется создать группу (обходит (walks) дерево, чтобы поместить ключи в группу; помещает ключи в группу при сохранении);
  • функции, активируемые группой:
  • список (List) внутри группы;
  • удалить (Delete) всю группу;
• открыть (Open) устройство;
• получить (Retrieve) информацию об устройстве (емкость, максимальная длина ключа, максимальная длина значения и др.);
• Create/DeleteKeyspace (эквивалент пространства имен NVMe,связанного с набором команд NVMeKV);
• Retrieve Key Value Pair information;
• Store;
• Retrieve;
• Delete;
• List;
• Delete Group.

KVCeph

KVCeph предоставляет новое хранилище объектов CEPH под на званием KvsStore. Он интегрирован с твердотельными накопителями Samsung KeyValue, перенося уровень управления объекта ми с CEPH на устройство. KvsStore снижает накладные расходы на операции ввода-вывода и вычисления в расчете на одно устройство в хост-системе и, таким образом, повышает производительность и масштабируемость – можно использовать большее количество твердотельных накопителей в одной хост-системе без снижения производительности. Этот проект также демонстрирует использование (https://github.com/OpenMPDK/KVCeph).

KVCeph — это ответвление системы хранения объектов Ceph, основанное на выпуске CEPH Luminous и оптимизированное для поддержки Samsung Key-Value SSD. Он предоставляет новое хранилище объектов под названием KvsStore со следующими двумя вспомогательными компонентами: onode prefetcher и планировщиком, управляемым событиями, которые могут исключить синхронизацию операций IO на пути данных к устройствам, повышая эффективность KVSSD (https://usermanual.wiki/Document/ KVCEPH20v0820User20guide.484920695.pdf).

На рис. 3 показана структура управляемого событиями планировщика, который управляет очередью для каждой группы размещения (PG, placement group) и уведомляет о событиях воркеров с помощью сигналов и системного вызова epoll. Это устраняет статическую связь между группой очередей запросов и исполнителями OP. В случае планировщика Sharded по умолчанию в Ceph эта ассоциация приводит к недостаточному использованию, поскольку в некоторых случаях все операторы могут не использоваться. Предварительная выборка Onode предназначена для более эффективного использования пропускной способности SSD за счет преобразования блокирующих операций чтения атрибутов внутри OP воркеров в неблокирующие операции чтения. Предварительная выборка происходит, когда рабочий процесс OP извлекает элемент из очереди для каждой PG, и объект в очереди динамически выбирается на основе текущего времени обработки. Наконец, KvsStore обрабатывает транзакции, чтение и все другие запросы объектов, такие как запросы атрибутов и ls, взаимодействуя с KVSSD.

Open Source код:

• SNIA KV API, Kernel driver и эмулятор:
  • public github – https://github.com/OpenMPDK/KVSSD;
  • KV userspace driver – https://github.com/OpenMPDK/uNVMe;
• KV Ceph: Ceph object storage designed for Samsung Key-Value SSD (https://github.com/OpenMPDK/KVCeph);
• NetworkKV: API-интерфейсы на уровне ПО хоста, абстрагирующие несколько напрямую подключенных или удаленных KVSSD (скоро появится NVMeoF, требуется уточнение, прим. ред.) – https://github.com/OpenMPDK/NKV;
• KVRocks: совместимое с RocksDBkeyvaluestore и совместимый с MyRocks механизм хранения, разработанный для KVSSD – https://github.com/OpenMPDK/KVRocks.

Samsung High Performance Object Storage (HPOS)

С 2022 г. Samsung стала активно продвигать HPOS-решение – высокопроизводительное объектное хранилище с интегрированным в KV SSD встроенным акселератором. За счет этого есть возможность обращаться не ко всему объекту, а только к его части – отдельным строкам/столбцам. HPOS позиционируется для приложений с доступом к данным по интерфейсу S3, которые работают с аналитикой в реальном времени. Среди них: Spark, hadoop, presto, TensorFlow, PyTorch, Caffe, Keras и др. Архитектура HPOS представлена на рис. 4, 4а.

Стек High Performance Object Storage (HPOS) обеспечивает дезагрегированное хранилище на нескольких SmartSSD (вычислительных накопителях Samsung). Это простое в масштабировании решение, ориентированное на данные и абстрагирующее, какая вы числительная функция выполняется на каком уровне ускорителя (т. е. CPU, GPU, XPU или SmartSSD). Решение Samsung HPOS представляет собой эталонное решение для приложений видео AI, требующих предварительной обработки видео в хранилище. Также это решение позиционируется для Data Analytics, обеспечивая высокую производительность для неструктурированных/объектных данных в озере данных (https://samsungmsl.com/dfs/).

Рис. 3. Структура KVCEPH OSD.

Рис. 4. Архитектура HPOS.

Рис. 4а. HPOS S3 SELECT с Computational SSD акселератором [5].

Среди других областей применения, для которых позиционируется HPOS: крупномасштабная (Large scale) аналитика в реальном времени, умный город, умный дом, электронное здравоохранение, Интернет вещей, обработка изображений/видео, безопасность. Среди преимуществ HPOS [5] (рис. 4б):

• более быстрые запросы;
• меньший сетевой трафик;
• снижение совокупной стоимости владения из-за снижения нагрузки на ЦП и сетевой трафик.

Сравнение методов доступа к данным AWS S3 Select и HPOS S3 Select показывает, что HPOS превосходит стандартный доступ AWS S3 Select по пропускной способности в 6 раз, а по задержкам – в 5 раз, потребляя при этом менее 0,5% ресурсов CPU (рис. 4в, по оценкам Samsung).

HPOS развивается Samsung на базе DSS (Disaggregated Storage Solution, https://github.com/OpenMPDK/DSS; в дальнейшем – disaggregated computational storage – DCS), – масштабируемое в стойку, оптимизированное для чтения с очень высокой пропускной способностью, совместимое с Amazon S3 решение для хранения объектов (рис. 4в). Оно использует дезагрегированную архитектуру, обеспечивающую независимое масштабирование хранилища и вычислений, а также имеет сквозной семантический коммуникационный стек KV, полностью исключающий устаревший программный стек хранения. Вся связь с хранилищем использует протокол NVMeOf-KV-RDMA, представленный Samsung с от крытым исходным кодом. Благодаря передаче без копирования достигается высокая сквозная производительность. Клиентский стек DSS включает в себя высокопроизводительную библиотеку оболочку для простой интеграции приложений. Приложения, использующие клиентскую библиотеку DSS, устраняют необходимость в семантике сегментов, распределении ключей и балансировке нагрузки между конечными точками S3 на стороне сервера.

Решение проблем производительности SSD с помощью дезагрегированного хранилища

Лаборатория решений для памяти Samsung – (MSL – Memory Solutions Lab, https://samsungmsl.com/) специализируется на изучении проблем системного уровня, влияющих на современные решения для хранения данных, и в настоящее время участвует в нескольких проектах, связанных с дезагрегированной/компонуемой архитектурой, ускорением вычислений, хранилищем для машинного обучения и потоковой передачи, сетевыми гетерогенными вычисления ми и виртуализацией хранилищ/контейнеров, которые включают CXL, вычислительные системы хранения, Ethernet SSD, объектные хранилища и крупномасштабные хранилища [6].

По словам старшего директора, MSL Маянка Саксена (Mayank Saxena), существует несколько критических проблем с файловыми системами на основе POSIX и даже с параллельными файловыми системами (pNFS). «Большинство проблем связано с мета данными и сложностью масштабирования для размещения многих петабайт данных», — сказал он. – Хотя NFS может хорошо работать в небольших масштабах — например, менее 1 петабайта — они начинают давать сбои по мере увеличения емкости системы хранения». В табл. 2 показано относительное ухудшение производительности для типов доступа и масштабировании.

Стремясь решить эту проблему, MSL изучает альтернативные решения для хранения данных с одним заказчиком в своем крупно масштабном (сотни петабайт) учебном проекте AI/ML, для которого потребуется очень высокая устойчивая пропускная способность в высокоскоростной сети с возможностью масштабироваться с течением времени. Заказчику требуется решение, которое не только обеспечивает производительность и емкость, но и занимает мало места. Как оказалось, решение Samsung с открытым исходным кодом для дезагрегированного хранилища (DSS, Disaggregated Storage Solution, https://github.com/OpenMPDK/DSS) способно удовлетворить эти требования. Этот проект предоставляет стандартный интерфейс, совместимый с Amazon S3, для объектного хранилища, который разработан с учетом масштабируемости на уровне эксабайтов, чтобы максимально использовать обычное оборудование и SSD большой емкости.

Почему MSL выбрала объектное хранилище? Многие из новейших приложений ИИ обрабатывают данные, сгенерированные машиной, которые часто хранятся в виде объектов. Вместо того, чтобы бороться со сложностями управления одним пространством имен на нескольких узлах хранения, MSL протестировала другой подход: оставив каждому узлу собственную файловую систему и управляя данными через единое хранилище объектов. Таким образом, внешняя система оркестрации, такая как Kubernetes, может координировать распределение данных.

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

Рис. 4б. Сравнение современного состояния (базовый уровень) и HPOS (оценкам Samsung, прим. ред.).

Рис. 4в. Сравнение методов доступа AWS S3 Select и HPOS S3 Select (оценкам Samsung, прим. ред.).

Табл. 2. Относительная производительность при масштабировании для разных способов доступа к данным.

Samsung развивает DSS в интеграции с MinIO.

MinIO — это высокопроизводительная объектная система, выпущенная под лицензией GNU Affero General Public License v3.0. Это API, совместимый с сервисом облачного хранилища Amazon S3. Он может обрабатывать не структурированные данные, такие как фотографии, видео, файлы журналов, резервные копии и образы контейнеров, с текущим максимальным поддерживаемым размером объекта 5 ТБ (https://en.wikipedia.org/wiki/MinIO).

Стек хранилища MinIO состоит из трех основных компонентов: MinIO Server, MinIO Client и MinIO Client SDK, который может использоваться разработчиками приложений для взаимодействия с любым сервером, совместимым с Amazon S3.

Сервер облачного хранилища MinIO спроектирован так, чтобы быть минималистичным и масштабируемым. Он достаточно легкий, чтобы его можно было связать со стеком приложений, аналогично NodeJS и Redis.

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

Сервер MinIO не зависит от оборудования, поэтому его можно установить как на физические, так и на виртуальные машины или запустить в виде контейнеров Docker и развернуть на платформах оркестровки контейнеров, таких как Kubernetes.

DSS расширяет архитектуру MinIO за счет дезагрегации уровней вычислений и хранения данных, что дает возможность их независимого масштабирования [6a] (рис. 5). Пример представления развертывания DSS дан на рис. 5а.

Разработка DSS проводится на основе open source кода https://github.com/OpenMPDK/DSS:

• https://github.com/OpenMPDK/DSS/dsssdk;
• https://github.com/OpenMPDK/DSS/dssansible;
• https://github.com/OpenMPDK/DSS/dssminio;
• https://github.com/OpenMPDK/DSS/dssecosystem.

Также поддерживается полная экосистема DSS:

• AIBenchmarkingFramework, поддерживающий предпочтительное обучение и модели пользователей;
• клиентские оболочки (Client Wrappers), поддерживающие Pytorch и TensorFlow;
• хост и целевой стек.

Рис. 5. DSS расширяет архитектуру MinIO за счет дезагрегиции уровней вычислений и хранения данных, что дает возможность независимого масштабирования как уровня вычислений, так и хранения данных [6a].

Рис. 5а. Пример развертывания DSS.

Проверка производительности DSS при масштабировании

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

Были протестированы два разных решения для хранения данных на идентичных конфигурациях узлов: DSS S3 и NFS (рис. 5б).

Результаты были следующими:

Затем MSL провела тесты с использованием шести серверов в двух разных конфигурациях серверов без какого-либо кодирования стирания или RAID:

– DSS v0.6 — CentOS 7.8.2003 (ядро 3.10.0-1127.el7.x86_64);

– NFS v4 — Ubuntu 20.04.3 LTS (ядро 5.4.0-100 — универсальное).

Было важно сравнить решение не только на уровне хранилища, но и на уровне приложений (т.е. обучения ИИ). Команда использовала инструмент сравнительного анализа ИИ для решений для хранения данных с использованием Tensorflow и PyTorch — двух известных сред ИИ — для измерения производительности хранилища с точки зрения времени загрузки данных, совокупного времени листинга, пропускной способности, задержки и других параметров по сравнению с алгоритмом обучения ИИ клиента и набор данных. Количество обучающих экземпляров ИИ на клиентский узел менялось, чтобы продемонстрировать производительность по мере увеличения параллельных рабочих нагрузок (рис. 6).

Во время теста производительность DSS была значительно выше и оставалась высокой, даже несмотря на увеличение количества тренировок ИИ, а также количества клиентских узлов, на которых выполнялись тренировки ИИ.

Была протестирована производительность решения при масштабировании до полной стойки с 10 узлами хранения, оставив достаточно места и мощности для сетевого оборудования, результаты – рис. 7.

DSS удалось достичь пропускной способности около 270 ГБ/с на полной стойке узлов хранения, предполагая, что даже при увеличении общей емкости системы решение будет поддерживать высокую производительность без необходимости постоянной перебалансировки данных.

Также был проведен тест, чтобы увидеть, как DSS будет работать при масштабировании для каждого узла. Как показано на рис. 8, пропускная способность масштабируется линейно с количеством узлов хранения, что упрощает масштабирование дезагрегированным способом. Используя DSS, клиент может использовать весь потенциал крупномасштабных твердотельных накопителей, чтобы снизить риск того, что хранилище станет узким местом в производительности.

Рис. 5б. Тестовая конфигурация.

Рис. 6. Сравнение производительности на Linux NFS и DSS S3 при разном числе узлов и экземпляров обучения ИИ.

Рис. 7. Производительность решения при масштабировании до полной стойки с 10 узлами хранения.

Рис. 8. Производительность DSS при масштабировании каждого узла.

Дополнительные рекомендации для повышения эффективности системы:

– проведите дополнительное крупномасштабное тестирование с различными параметрами данных (размер набора данных, разнообразие, количество клиентских узлов и т.д.);

– протестируйте систему с серверами GPU, выполняющими реальные операции машинного обучения, поскольку учебные нагрузки AI/ML не похожи на другие рабочие нагрузки;

– увеличьте емкость SSD/хост одним из двух способов:

• увеличьте емкости SSD с 32 до 64 ТБ;
• применяйте серверы, которые будут использовать 24 или более SSD, а не только 16, что может оказаться сложной задачей;

– выполните обновление до новых поколений CPU, чтобы проверить потолок и определить влияние новых скоростей, поддерживающих Samsung PCIe Gen 5 SSD и память DDR5 на серверах.

Тестирование HPOS

HPOS разрабатывается Samsung на основе нового интерфейса доступа к данным – HPOS S3 Select, когда к объекту можно обращаться не целиком, а только к его части, а также выполнять обработку данных внутри SSD. Интересующиеся данные могут, например, содержать столбцы или фрагменты внутри них. HPOS S3 Select является дополнением к стандартным интерфейсам доступа S3. Среди прикладных платформ, которым необходим такой расширенный (более гранулированный) доступ к объектным данным, например – Spark, hadoop, presto, TensorFlow, PyTorch (см. рис. 4). Для этого Samsung развивает новый класс KV SSD – KV SSD с интегрированным акселератором.

Рис. 9. Схема тестирования HPOS S3 Select со стандартным запросом AWS S3 Select.

Рис. 10. Структурная схема обработки запроса HPOS S3 Select к Smart SSD с акселератором.

Рис. 11. Результаты сравнительного тестирования стандартного запроса AWS S3 Select и HPOS S3 Select.

Рис. 12. Сравнение потребляемой мощности без и с использованием акселератора.

Схема тестирования HPOS S3 Select в сравнении со стандартным запросом S3 Select представлена на рис. 9. При тестировании выполнялся SQLзапрос: S3_Select Query (‘Select COUNT(*) FROM S3Object s WHERE dayofyear < 55’).

Структурная схема всего стека ПО обработки запроса HPOS S3 Select к Smart SSD с акселератором дана на рис. 10.

Результаты сравнительного тестирования стандартного запроса AWS S3 Select и HPOS S3 Select даны на рис. 11. Пропускная способность увеличилась более чем в 100 раз, а задержка уменьшилась в 250 раз (с 77,32 сек до 0,26 сек, т.е. запрос обрабатывался почти в реальном времени). При этом загрузка CPU HPOS составила всего 0,12%.

Также было замерено снижение потребляемой мощности при использовании HPOS. В среднем при использовании одного Smart SSD была установлена экономия ~6 Вт/ч, что составляет ~2 % от общей потребляемой мощности (рис. 12).

SK hynix – Key Value Store Computational Storage Device (KV-CSD)

На 2022 Flash Memory Summit (август 2022 г.) Los Alamos National Laboratory и SK hynix продемонстрировали первое в мире Key-value Store Computational Storage Device [3, 4] (рис. 13).

Отличительной особенностью KV-CSD является то, что в отличие от “простого” key-value SSD в него интегрировано вычислительное устройство (на основе CPU/FPGA), которое позволяет производить обработку данных (value). В данном случае их индексировать.

SK hynix заявила, что ее исследователи продемонстрировали возможность внедрения индексации в свой прототип KV-CSD, и это ускоряет работу некоторых приложений LANL для анализа данных моделирования в тысячу раз [3]. Причина этого в том, что LANL переносит ввод-вывод крупномасштабного моделирования из файлов в форматы на основе записей и столбцов, чтобы аналитику можно было выполнять с использованием стандартных инструментов сообщества аналитиков больших данных. Внедрение возможностей индексирования в сами устройства хранения означает, что данные можно индексировать по мере их записи.

Одной из миссий LANL является проектирование и обслуживание ядерного арсенала США, что требует чрезвычайно сложных симуляций.

Руководитель подразделения высокопроизводительных вычислений LANL Гэри Грайдер (Gary Grider) сказал, что перенос крупно масштабного физического моделирования объекта с ввода-вывода на основе файлов на ввод-вывод с индексацией записей и столбцов уже продемонстрировал невероятное ускорение анализа результатов моделирования.

Грайдер рассказал нам, что более ранние KV-CSD, который LANL развернул от Samsung пару лет назад, не давали возможности индексации значений (value). KV-CSD с индексацией позволяет выполнять запросы по диапазонам значений (где вы не знаете ключ, но знаете диапазон значений).

«Это важное различие, потому что заказной KV-CSD гораздо сложнее сделать, но гораздо полезнее для более широкого рынка — на пример, это аппаратное решение делает то же самое, что и программные продукты, такие как LevelDB и RocksDB. И этот рынок большой и обширный», — сказал Гридер.

Исследование различных схем подключения GPU к KVSSD

Компания SK hynix совместно с университетом Sogang (Seoul, Re public of Korea) провела исследования различных вариантов подключения GPU к KVSSD [7] и добилась в этом направлении больших успехов, что иллюстрирует совместный анонс с LANL. В исследовании рассматривались 4 схемы подключения:

• GPUKV – GPU напрямую связывается с KVSSD через P2Pсо единение (одноранговая связь PCIe). Ядро GPU запускается только один раз, поскольку операции ввода-вывода с ключом и значением выполняются во время выполнения ядра графического процессора;

Рис. 13. Key Value Store Computational Storage Device (KVCSD).

• KVSSD – приложение хоста может напрямую взаимодействовать с KVSSD, что позволяет ему обходить файловую систему. Одна ко, в отличие от GPUKV, он должен использовать cudaMemcpy для передачи данных в память графического процессора каждый раз, когда это требуется ядру GPU;
• RocksDB(C) – RocksDB работает в файловой системе Ext Входные данные для ядер GPU необходимо скопировать с помощью cudaMemcpy центрального процессора хоста. Подобно KVSSD, данные должны передаваться в GPU каждый раз, когда они нужны ядру GPU. Кэш RockDB включен и используется буфери зованный ввод-вывод;
• RocksDB(NC) – то же самое, что и RocksDB(C), за исключением того, что кеш RocksDB отключен и используется directIO.

Среди систем, представленных выше, GPUKV является репрезентативной моделью вычислений на базе GPU, в то время как другие системы, такие как KVSSD, RocksDB (C) и RocksDB (NC), являются репрезентативными моделями вычислений на GPU на базе CPU, в которых приложение хоста отвечает за перемещение данные с устройств хранения на GPU.

Когда данные загружаются из хранилища «ключ-значение» в GPU в традиционной вычислительной модели, управляемой GPU, это влечет за собой накладные расходы на все стеки ввода-вывода хранилища «ключ-значение» и файловой системы. Модель вычислений GPUKV устраняет эти накладные расходы за счет меньшего использования ресурсов на стороне хоста, таких как CPU и па мять. GPUKV имеет следующие три функции: (i) GPUKV обеспечивает абстракцию хранилища ключей и значений для GPU; (ii) в GPUKV при загрузке данных из хранилища «ключ-значение» в GPU она выполняется через одноранговую (P2P) связь PCIe без копирования в память пользователя и пространства ядра; и (iii) GPUKV использует KVSSD, который реализует хранилище ключей-значений внутри SSD, полностью исключая взаимодействие с хранилищем ключей-значений и файловой системой для связи P2P. Модель вычислений GPUKV с KVSSD была реализована на платформе Cosmos+OpenSSD в среде Linux. Оценки показывают, что GPUKV сокращает время выполнения до 18,7 раз и снижает использование циклов CPU хоста до 175 раз по сравнению с обычными моделями вычислений (по данным [7] на момент проведения исследований – март 2021 г.).

Массивно-параллельная обработка GPU ускоряет скорость обработки приложений, интенсивно использующих данные, в различных областях, таких как глубокое обучение, моделирование и обработка графов. Обработка данных с использованием GPU состоит из следующих шагов: во-первых, хост-приложение загружает входные данные с устройств хранения в память пользовательского пространства через файловую систему. Во-вторых, он копирует загруженные входные данные из памяти пользовательского пространства в память GPU. В-третьих, после этого, когда входные данные будут подготовлены в памяти графического процессора, хост-приложение может начать выполнение ядра графического процессора. Таким образом, хост-приложение управляет процессом выполнения ядра графического процессора в традиционной модели программирования графического процессора. Этот под ход называется вычислительной моделью GPU, управляемой CPU.

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

Для минимизации накладных расходов было предложено использовалась одноранговую связь PCIe (P2P). P2P позволяет двум устройствам PCIe напрямую передавать данные друг другу без использования ресурсов на стороне хоста. GPU от NVIDIA и от AMD поддерживают API для PCIe P2P связи. Однако для выполнения P2P адрес блока файла должен быть известен заранее.

Это преобразование адресов из файла в блок включает взаимодействие с файловой системой, потребляя циклы CPU на стороне хоста. Хуже того, когда входные данные, используемые ядром GPU, хранятся в хранилище ключей и значений в файловой системе, P2P может не обеспечить никакого прироста производительности. Это связано с тем, что накладные расходы на “тяжелые” стеки ввода вывода из хранилища ключей и файловой системы могут свести на нет преимущества снижения накладных расходов на перемещение данных с помощью P2P.

Например, рассмотрим приложение для анализа графов, которое использует базу данных для извлечения данных графа и их обработки ядром на GPU. Чтобы передавать данные графа напрямую с устройств хранения на GPU с использованием P2P, приложению сначала необходимо найти файлы базы данных и смещения файлов для данных графа. Затем приложение должно обратиться к файловой системе, чтобы найти адреса логических блоков (LBA) файлов. Затем, используя эту информацию LBA, приложение делает запрос к устройствам хранения и инициирует прямую пере дачу данных на GPU через P2P.

В моделях вычислений на GPU, управляемых CPU, вмешательство CPU для поиска файлов в базе данных и преобразования адресов из файлов в блоки, описанные выше, неизбежно и для P2P. Для решения этих проблем была предложена модель GPUKV – управляемый GPU фреймворк, в котором ядро GPU может инициировать запросы ввода-вывода во время выполнения ядра, на прямую получать входные данные с устройств хранения и обрабатывать их. GPUKV реализуется на устройствах хранения объектов, таких как KeyValue SSD (KVSSD). KVSSD реализует хранилище ключей и значений внутри SSD. Следовательно, нет необходимости взаимодействовать с хранилищем ключей и файловой системой для преобразования адресов файлов в LBA для P2P на хосте. Таким образом, исключается использование ресурсов хоста. P2P также позволяет напрямую передавать данные с KVSSD на GPU без вмешательства процессора в хост.

Модель вычислений на базе GPU (GPUKV) была реализована за счет расширения GPUfs на KVSSD, прототип которого был создан на платформе Cosmos+OpenSSD (OpenSSD. 2017. Cosmos Plus OpenSSD Platform, http://openssd.io/) в среде Linux. Для оценки эффективности подходов использовались два типа серверных сред – мощный высокопроизводительный сервер и менее мощный низкопроизводительный сервер, их оценивали как для синтетических, так и для реалистичных рабочих нагрузок GPU.

В расширенной оценке GPUKV продемонстрировал улучшение производительности в 9,1 и 18,7 раз по сравнению с KVSSD и RocksDB (C/NC) как для синтетических, так и для реальных рабочих нагрузок. Кроме того, GPUKV потребляет в 176 раз и в 35 раз меньше циклов ЦП, чем традиционные подходы к вычислениям на основе ЦП с синтетическими рабочими нагрузками на высокопроизводительных и низкопроизводительных серверах соответственно.

Передача данных из хранилища ключей и значений в GPU

На рис. 14 показаны два разных подхода к передаче входных данных из хранилища «ключ-значение» в GPU. Традиционный под ход включает в себя выполнение нескольких операций копирования памяти с устройств хранения в память графического процессора при отправке входных данных в графический процессор. С другой стороны, подход передачи данных P2P заключается в прямой передаче входных данных с устройств хранения в память графического процессора без вмешательства ЦП во время передачи данных.

Традиционный подход

Чтобы четко сформулировать накладные расходы на передачу данных в традиционном подходе, было использовано хранилище ключей RocksDB. RocksDB управляет несколькими файлами SSTable в файловой системе. В одном SSTable хранится набор пар ключ-значение. В дополнение к блокам данных, содержащим значения, SSTable поддерживает bloomфильтр для проверки существования ключа и блок индекса для поиска смещения блока данных. Чтобы получить соответствующий ключ-значение, RocksDB сначала выбирает SSTable-кандидаты и проверяет их bloomфильтры. Для каждого SSTable, если bloom-фильтр возвращает положительный результат, он проверяет индексный блок на наличие ключа. Если ключ присутствует, он, наконец, извлекает соответствующие значения. Поскольку RocksDB работает поверх файловой системы, файлы SSTable необходимо загрузить в основную память, а затем оценить. Затем значения, соответствующие ключам, будут скопированы в память GPU.

Рис. 14 (a) показывает вышеупомянутый поток передачи данных с точки зрения управления и пути данных. Хост-приложение отвечает за получение пар ключ-значение из RocksDB, их копирование в память графического процессора и запуск ядра графического процессора. (1) Сначала приложение отправляет GETзапрос к RocksDB. (2) Чтобы получить значения, соответствующие ключам, RocksDB считывает файлы-кандидаты SSTable, включая фильтры Блума, через файловую систему. Файловая система определяет LBA файлов и отправляет запрос на чтение с LBA файлов на SSD через драйвер NVMe. (A) После того, как запрос на чтение с LBA достигает SSD, контроллер SSD передает данные LBA в буферы пространства ядра файловой системы, используя прямой доступ к памяти (DMA). (B) Файловая система снова копирует данные обратно в буферы пользовательского пространства RocksDB, а затем RocksDB тестирует фильтры Блума. Затем RocksDB ищет индексы и блоки данных. (3) После извлечения значений запрос RocksDB GET завершается. (4) Теперь входные данные готовы к отправке в память графического процессора, и хост-приложение запрашивает у драйвера графического процессора копирование данных. (C) Поскольку драйвер графического процессора фактически копирует данные, входные данные временно сохраняются в буфере ядра системной памяти. (D) Наконец, входные данные копируются в память GPU через DMA.

Рис. 14. Обычный поток передачи данных из хранилища ключ-значение (RocksDB) в GPU.

Передача данных с использованием P2P-связи

Прямая передача данных с использованием связи PCIe-P2P может снизить нагрузку на CPU и память из-за многократных операций копирования памяти по сравнению с традиционным подходом. Однако на практике применение P2P-передачи данных в системе с использованием хранилища «ключ-значение» не так просто и по-прежнему влечет за собой значительную загрузку CPU на стороне хоста. На рис. 14 (b) показан сценарий передачи данных P2P с помощью RocksDB. Выдача запроса GET, проверка bloom-фильтров и поиск блоков индекса работают одинаково в обычном подходе ((1), (2), (A), (B)).

Однако есть дополнительные пути ((3), (4), см. красные сплошные стрелки на рис. 14 (b). (3) Когда механизм RocksDB находит значение, соответствующее ключу, он должен “проконсультироваться” с файловой системой, используя такие инструменты, как FIBMAP ioctl, чтобы определить LBA-значения. Чтобы передать значение с помощью P2P, необходимо указать информацию LBA в команде NVMe для контроллера SSD. (4) Запрос на передачу данных P2P с LBA отправляется на контроллер SSD через драйвер NVMe. Затем C контроллер SSD напрямую передает данные, соответствующие LBA, в память графического процессора без вмешательства ЦП на стороне хоста. Наконец, (5) о завершении команды NVMe сообщается хост-приложению, и 6 приложение запускает ядро графического процессора. Несмотря на то, что P2P-связь обеспечивает прямую передачу данных, структура файлов на диске должна быть извлечена из файловой системы. Кроме того, данные должны быть согласованы для передачи P2P как в RocksDB, так и в файловой системе.

Тестирование

Было проведено несколько экспериментов для выявления проблем с производительностью при реализации передачи данных с использованием P2P с SSD на GPU в хранилище «ключ-значение».

Была измерена задержка передачи данных типа «ключ-значение» размером 4 КБ с SSD на GPU для RocksDB [19] как с P2P, так и без него. Сравнивались три конфигурации — RocksDB, RocksDB с P2P и GPUKV (ideal). RocksDB и RocksDB с P2P c потоками передачи данных представлены на рис. 14 (a) и (b) соответственно. GPUKV (идеальный вариант) — это идеальная ситуация, которая может быть достигнута только путем удаления всех накладных расходов стека ввода-вывода хранилища ключей и значений и файловой системы в GPUKV. Для объективной оценки были отключены все функции кэширования RocksDB и использовался DirectIO для операций с файловой системой.

На рис. 15 показаны результаты разбивки по задержкам с RocksDB Get, P2Pсвязью, извлечением плана данных (Extract Layout) и cudaMemcpy. Было установлено, что для RocksDB большая часть задержки связана с операциями ввода-вывода для RocksDB Get, которые включают чтение файлов RocksDB, таких как bloom фильтры, индексные блоки и блоки данных с SSD. RockDB использует cudaMemcpy для копирования данных из памяти хоста в память GPU. Вклад cudaMemcpy в задержку незначителен. С другой стороны, удивительно, что RocksDB с P2P имеет более высокую задержку, чем RocksDB.

RocksDB с P2P имеет почти такое же количество операций ввода вывода для RocksDB Get, как и RocksDB. Это связано с тем, что RocksDB должен читать блоки метаданных файлов SSTable, таких как блоки bloomфильтра, чтобы проверить, существуют ли значения, соответствующие ключам, и он должен читать целые файлы SSTable. RocksDB с P2P использует P2P для передачи данных. Передача P2P добавляет значительную задержку по сравнению с Rock sDB. RocksDB с P2P должен фактически считывать данные с флэш памяти NAND твердотельного накопителя. Обратите внимание, что чтение NAND происходит намного медленнее, чем чтение DRAM. Однако RocksDB перемещает данные из памяти хоста в память GPU, что намного быстрее, чем P2Pсвязь между SSD и GPU.

Кроме того, RocksDB с P2P имеет некоторые накладные расходы для извлечения LBA данных, которые должны быть переданы для P2P. Это приводит к незначительной задержке, поскольку информация о макете находится в индексном узле файла, а большинство индексных дескрипторов уже кэшировано в основной памяти предыдущими операциями ввода-вывода файловой системы для файлов SSTable. По сравнению с RocksDB и RocksDB с P2P, GPUKV (Ideal) имеет самую низкую задержку, менее половины их задержки.

GPUKV не требует взаимодействия с базой данных и файловой системой для P2P за счет использования SSD типа «ключ-значение». Задержка GPUKV близка к идеальному варианту.

Рис. 15. Сравнение задержек вызовов ввода-вывода для RocksDB с P2P и без него, а также NVMe SSD с P2P (идеальный вариант).

Поскольку KVSSD управляет парами ключ-значение внутри SSD, накладные расходы на извлечение LBA намного меньше, и хост приложению не нужно заботиться о выравнивании данных для P2P. Кроме того, GPUKV предназначен для прямой отправки запросов ключ-значение (GET, PUT) при выполнении ядра графического процессора. Таким образом, он позволяет выполнять вычисления на GPU, исключая CPU.

Дизайн и реализация платформы GPUKV – фреймворк GPUKV

GPUKV состоит из следующих трех технологий: (i) абстракция ключ-значение для графического процессора, которая позволяет запрашивать ключ-значение при выполнении ядра графического процессора, (ii) встраивание хранилища значений ключа в SSD и (iii) ядро с нулевым копированием. обходить связь по P2P при загрузке данных из KVSSD в GPU.

GPUKV обеспечивает абстракцию хранилища ключей и значений для графического процессора, поэтому ядро графического процессора может отправлять запросы на ключ-значение к KVSSD во время его работы. Основные операции ключ-значение — это точечные запросы, которые представляют собой команды ключ-значение, такие как GET, PUT и DELETE. В табл. 1 (на март 2021 г.) показан прототип API GPUKV. Все операции API принимают ключ в качестве общего параметра, в то время как gpukv_get и gpukv_put требуют value_size и буфера. Кроме того, буфер — это адрес памяти графического процессора с поддержкой PCIe P2P для значения. Команды ключ-значение отправляются в KVSSD через драйвер GPUKV.

На рис. 16 показана передача данных с помощью P2P из KVSSD в GPU и спецификация команды «ключ-значение» для KVSSD. В частности, на рис. 16(а) показана схема архитектуры системы для GPUKV.

Драйвер GPUKV — это основной модуль, который передает команды «ключ-значение» от графического процессора к KVSSD и подготавливает передачу данных P2P. Драйвер GPUKV передает команды «ключ-значение» драйверу «ключ-значение» с помощью удаленного вызова процедур (RPC, remote procedure call), реализованного с использованием общей памяти графического процессора. Драйвер Linux NVMe был расширен для поддержки команд KeyValue NVMe и передачи данных P2P. Драйвер “ключ-значение” выдает команды NVMe для KVSSD от имени драйвера GPUKV. Целевые адреса команды NVMe заполняются адресами памяти GPU с поддержкой P2P. Поэтому ядро GPU получает данные «ключ-значение» непосредственно из KVSSD в адресах памяти GPU с поддержкой P2P.

Запросы ключ-значение обрабатываются асинхронно в пакетах. Драйвер GPUKV реализован с использованием двух потоков ЦП: потока выпуска (Issue thread) и потока завершения (Completion thread). Поток выпуска пакетирует не более чем по 32 запроса ключ значение и выдает команды NVMe асинхронно. Размер пакета определяется на основе количества потоков в одной “деформации” (warp) GPU. Тем временем поток завершения ожидает завершения команд NVMe. Когда поток завершения замечает завершение любой выданной команды NVMe, он немедленно информирует драйвер GPUKV, чтобы можно было вернуть RPC от GPU и возобновить вычисления со значением запроса.

Драйвер “ключ-значение”, работающий на хосте, передает запросы “ключ-значение” от драйвера GPUKV в KVSSD. Для поддержки запросов «ключ-значение» и передачи данных P2P был расширен протокол NVMe для поддержки операций «ключ-значение» и изменен драйвер Linux NVMe. На рис. 16 (б) показан расширенный протокол NVMe для команд «ключ-значение». Область кода операции определяет операции GET, PUT и DELETE с использованием кодов операций конкретного поставщика в протоколе NVMe. Была использована начальная область LBA в командах NVMe для указания ключа длиной 8 байт. Команды PUT и GET используют спи сок страниц для значения. Однако из-за переменного размера дли на значения не может быть выражена размером блока и количеством блоков. Чтобы решить эту проблему, была использована зарезервированная область команды NVMe, чтобы указать длину значения для PUT и размер буфера для GET.

Между тем, список страниц физического региона (PRP, Physical Region Page) в команде NVMe включает адреса страниц данных. Для P2P с графическим процессором список PRP необходимо заполнить физическими адресами областей, доступных для P2P, в памяти GPU. С этой целью была использована команда nvidia_p2p_get_pages, чтобы закрепить (to pin) предварительно вы деленную память GPU и сопоставления закрепленной памяти GPU с адресным пространством DMA для связи P2P. Кроме того, API NVIDIA предоставляет таблицу страниц закрепленной памяти GPU. Драйвер KeyValue сохраняет эту таблицу страниц вовремя инициализации. Затем он транслирует буфер, переданный от ядра GPU, в физический адрес, чтобы заполнить список PRP в команде NVMe.

(а) P2P потоки данных от KVSSD к GPU.

(б) key-value команды расширения NVMeпротокола.

Рис. 16. P2P потоки данных от KVSSD к GPU в GPUKV.

Функциональный поток операции Get

На рис. 17 показана функциональная схема того, как GPUKV обрабатывает gpukv_get. Когда поток GPU вызывает gpukv_get, информация о запросе помещается в очередь запросов в разделяемой памяти GPU. Очередь запросов — это общая память, которую могут видеть потоки CPU и GPU. Поток GPU ожидает завершения запроса, опрашивая статус запроса RPC. Тем временем поток Issue на стороне хоста ожидает новых запросов ключ-значение, опрашивая очередь запросов. Когда поток Issue получает пакет запросов «ключ значение», он выдает команды драйверу «ключ-значение». Затем драйвер «ключ-значение» создает запросы NVMe на основе буфера и размера значения в информации о запросе. Он заполняет списки (PRP), используя таблицу страниц закрепленной памяти графического процессора. После этого команды NVMe передаются KVSSD, и KVSSD передает значения на GPU напрямую через P2P, что представляет собой взаимодействие без копирования и обхода ядра.

По завершении команды NVMe KVSSD запускает поток завершения. Затем поток завершения обновляет статус запросов RPC. На конец, ядро графического процессора замечает завершение и про должает свои вычисления. Тем временем ядро графического процессора ожидает завершения запроса RPC путем опроса. В настоящее время GPUKV поддерживает P2P только для операции Get. Операция размещения выполняется асинхронным буферизованным вводом-выводом через ЦП.

Рис. 17. Функциональный поток GPUKV.

Экспериментальная установка и оценка GPUKV

Реализация. Была (i) расширена GPUfs для создания фреймворка для GPUKV, который выполняет операции ключ-значение для KVSSD при выполнении ядра GPU, и (ii) разработан KVSSD на основе хэш-карты на платформе Cosmos+OpenSSD, подробные характеристики которого приведены в табл. 2. Эксперименты про водились на сервере Intel 4 Core, оснащенном NVIDIA Quadro P4000. Сведения об аппаратном обеспечении сервера и GPU по казаны в табл. 3 и 4 соответственно.

В частности, чтобы оценить производительность/эффективность использования ресурсов GPUKV в зависимости от производительности ЦП хоста, мы изменили настройки ЦП сервера для двух разных конфигураций: сервер высокого класса (4 ядра, процессор 3,5 ГГц) и сервер низкого уровня (2 ядра, процессор 800 МГц). Обратите внимание, что сервер начального уровня имеет более низкую тактовую частоту процессора и меньшее количество процессоров, чем сервер высокого класса.

Нагрузка. Были использованы как синтетические, так и реалистичные рабочие нагрузки для оценки GPUKV. Был разработан собственный тест для синтетической рабочей нагрузки, который может имитировать различные шаблоны доступа к данным приложений GPU. Шаблон доступа к данным приложений GPU делится на потоковый и динамический. Потоковая передача имеет предсказуемые схемы доступа к данным. Следовательно, ядро GPU может рассчитывать на увеличение производительности ввода-вывода за счет предварительной выборки следующего набора входных данных. Напротив, Dynamic имеет непредсказуемые модели доступа к данным, поэтому предварительная выборка не повышает производительность ввода-вывода.

Для реалистичных рабочих нагрузок был использован тест обработки графов – GARDENIA [8]. Среди различных рабочих нагрузок GARDENIA были выбраны две репрезентативные рабочие нагрузки: Page Rank (PR) и поиск в ширину (BFS, BreadthFirst Search). PR — это рабочая нагрузка, которая оценивает релевантность веб-страниц. PR обновляет оценки страниц в течение не скольких раундов, используя информацию об их подключении и оценки, рассчитанные в предыдущих раундах. PR имеет шаблон доступа к потоковым данным. В рабочей нагрузке при обновлении оценок страницы вершин обновляются коллективно.

Напротив, BFS — это шаблон динамического доступа к данным, поскольку следующий набор вершин непредсказуем и может быть известен только после завершения текущего шага поиска. Мы хранили наборы данных графа для PR и BFS в KVSSD, используя идентификатор вершины в качестве ключа и список информации о ребрах (пара ID вершины назначения и вес ребра) в качестве его значения. Для входного набора данных использовался roadNetCA из репозитория графов [9]. RoadNetCA — это граф дорожной сети Калифорнии с 1 971 281 вершиной и 5 533 214 ребрами. Общий размер данных графа в хранилище ключей и значений составляет около 7,5 ГБ.

Сравнивались четыре схемы подключения: GPUKV, KVSSD, RocksDB(C) и RocksDB(NC), представленные выше.

Рис. 17. Подробные характеристики.

Анализ производительности

Синтетические рабочие нагрузки. Проводились эксперименты с шаблонами потоковой передачи и динамическими шаблонами пар “ключ-значение” для 4 млн. значений размером 4 КБ. На рис. 18 и 19 показаны измерения общего времени выполнения для потоковых и динамических рабочих нагрузок, соответственно.

В частности, для моделей вычислений на GPU, управляемых CPU (KVSSD, RocksDB(C) и RocksDB(NC)), были проведены эксперименты с увеличением числа потоков ввода/вывода ЦП (на рис. 18, 19 они называются традиционным подходом – Conv. Approach). Увеличение количества потоков ввода-вывода ускоряет перемещение данных в GPU и сокращает время выполнения ядра GPU, но увеличивает использование CPU. GPUKV не использует потоки ввода-вывода для перемещения данных на ЦП, поскольку ядра графического процессора и KVSSD могут передавать данные напрямую через P2Pсвязь. GPUKV просто использует два потока обработки команд ввода-вывода — поток выполнения и поток завершения, которые не являются потоками ввода-вывода, которые фактически перемещают данные в память графического процессора.

Результаты рабочей нагрузки шаблона потоковой передачи. На рис. 18 (a) и (b) показаны результаты для потоковых рабочих нагрузок

(W_Streaming) на серверах highend и lowend уровня соответственно. На рис. 18 (а) KVSSD и RocksDB(C/NC) имеют меньшее время выполнения по мере увеличения количества потоков ввода-вывода CPU. Это связано с тем, что параллельный ввод-вывод может перекрывать операции копирования памяти из памяти хоста в па мять графического процессора, тем самым сокращая время, затрачиваемое на ввод-вывод. Этот эффект конвейера между ними максимизирует производительность каждой системы. Например, когда количество потоков ввода-вывода равно 256, KVSSD и RocksDB(C/NC) достигают такого же времени выполнения, как и GPUKV. Однако для KVSSD и RocksDB(C/NC) требуется 256 потоков, а для GPUKV — нет. С другой стороны, даже если GPUKV использует два потока команд ввода/вывода, он превосходит KVSSD и RocksDB(C/NC). Замечание: эта I/O команда issues потоков может быть устранена, если ядро GPU может напрямую управлять драйвером NVMe и выдавать команды NVMe для KVSSD. Это наблюдение объясняет, почему GPUKV требует меньше ресурсов на стороне хоста, таких как процессорный цикл и па мять, чем KVSSD и RocksDB(C/NC).

На рис. 18 (b) показаны результаты на lowend сервере. В целом, наблюдались тенденции производительности, аналогичные рис.18 (a). Однако по сравнению с рис. 18 (а) KVSSD и RocksDB(C/NC) имели более высокое время выполнения. Это связано с менее мощными центральными процессорами.

Рис. 18. Потоковая нагрузка (W_Streaming).

Рис. 19. Динамическая нагрузка (W_Dynamic).

KVSSD показывает небольшое падение производительности в среднем на 19%, в то время как RocksDB(C) и RocksDB(NC) демонстрируют значительное падение производительности в сред нем на 41% и 50% соответственно. KVSSD и RocksDB(C/NC) используют цикл CPU и память хоста, поэтому их производительность сильно зависит от производительности CPU хоста. Производительность KVSSD меньше зависит от производительности центрального процессора, чем RocksDB(C/NC). Это связано с тем, что KVSSD обходит файловую систему.

Однако в RocksDB(C/NC) он должен пройти через тяжелый программный стек ввода-вывода, такой как файловая система и кэш страниц, поэтому он требует высокой зависимости от производительности ЦП хоста. С другой стороны, GPUKV, который редко использует ресурсы хоста, имеет незначительное снижение производительности.

Результаты рабочей нагрузки динамического шаблона. На рис. 19 (а) показаны результаты для динамических рабочих нагрузок на высокопроизводительном сервере. Установлено, что прирост производительности GPUKV намного выше в W_Dynamic, чем в W_Streaming. Это связано с тем, что модели вычислений на GPU, управляемые CPU (KVSSD и RocksDB(C/NC)) вообще не могут перекрывать время вычислений и время ввода-вывода в рабочих нагрузках схемы динамического доступа к данным. В отличие от потоковых рабочих нагрузок, следующий загружаемый набор данных в динамических рабочих нагрузках может быть известен только после завершения текущего выполнения ядра. Таким образом, предварительная выборка не помогает при динамической рабочей нагрузке. В частности, установлено, что KVSSD имеет меньшее время выполнения, чем RocksDB(C). На рис. 19 (b) показаны результаты lowend системы. В целом, было установлено, что модели вычислений на GPU с управлением от CPU (KVSSD и RocksDB(C/NC)) увеличили время выполнения из-за меньшей мощности CPU.

Таким образом, на рис. 18 и 19 видно, что GPUKV имеет наименьшее время выполнения на высокопроизводительных и низкопроизводительных серверах. Другие модели вычислений на GPU, управляемые CPU, требуют большого количества потоков ввода-вывода для достижения времени выполнения, аналогичного GPUKV. Другими словами, в нашем прототипе GPUKV позволяет выполнять вычисления на GPU с очень небольшой зависимостью от ЦП хоста.

Реалистичные рабочие нагрузки. На рис. 20, 21 показаны результаты для рабочих нагрузок PR и BFS. Обратите внимание, что PR — это рабочая нагрузка потокового шаблона, тогда как BFS — рабочая нагрузка динамического шаблона. На рис. 20 показаны результаты для PR. У нас есть аналогичные наблюдения, как на рис. 18. На рис. 20 (a) показаны результаты на высокопроизводительном сервере. Он ясно показывает разницу в производительности между GPUKV и моделями вычислений на GPU с использованием CPU (KVSSD и RocksDB(C/NC)). RocksDB имеет более низкое время выполнения при увеличении количества потоков ввода-вывода, но все же имеет более высокое время выполнения, чем GPUKV. При использовании 256 потоков ввода-вывода у RocksDB(C) время выполнения в 1,3 раза, а у RocksDB(NC) в 1,6 раза больше, чем у GPUKV. С другой стороны, KVSSD, который имеет более простой программный стек ввода-вывода, чем RocksDB, имеет такое же время выполнения, как и GPUKV, когда число потоков ввода-вывода равно 256. На рис. 20 (b) показаны результаты на lowend сервере. В целом KVSSD и RocksDB увеличили время выполнения по срав нению с сервером высокого класса. В частности, мы заметили, что даже при количестве потоков ввода-вывода 256 KVSSD имеет боль шее время выполнения, чем GPUKV.

Рис. 20. Page Rank (PR).

Рис. 21. BreadthFirst Search (BFS).

На рис. 21 представлены результаты для BFS. Интересно, что на рис. 21(a) замечено, что RocksDB(C) имеет меньшее время выполнения, чем GPUKV, когда используется более 16 потоков ввода/вывода. Это связано с тем, что в BFS размер данных невелик, а в RocksDB(C) имеется большое преимущество кэширования из-за небольшого размера рабочей нагрузки. Однако на рис. 21(b), где используется низкопроизводительный сервер, кэширование не дает никаких преимуществ, а GPUKV имеет наименьшее время выполнения.

Анализ использования ресурсов

В предыдущих экспериментах было подтверждено, что производительность GPUKV не зависит от производительности CPU хоста. С другой стороны, было установлено, что производительность KVSSD и RocksDB очень чувствительна к производительности CPU хоста. В этом эксперименте проводилась оценка, насколько мало GPUKV использует циклы CPU хоста по сравнению с KVSSD и RocksDB. Для оценки использовались синтетические потоковые рабочие нагрузки (W_syntetic).

На рис. 22 показан результат разбивки циклов CPU, потребляемых каждой конфигурацией сервера, в соответствии с I/O Request Handling, Thread Management, Polling, и Others (обработкой запросов ввода-вывода, управлением потоками, опросом и другими параметрами). Обработка запросов ввода-вывода относится к циклам CPU, потребляемым при обработке запросов ввода-вывода в каждой конфигурации сервера. Управление потоками относится к циклам CPU, потребляемым при создании потоков, объединении и т. д. при обработке ввода-вывода с несколькими потоками в KVSSD и RocksDB. Опрос относится к циклам CPU, потребляемым при опросе общей памяти для связи RPC.

Другие диаграммы показывают циклы ЦП, используемые для переключения контекста, синхронизации потоков и других накладных расходов программного обеспечения. На рис. 22 KVSSD и Rocks использовали 256 потоков ввода-вывода на высокопроизводительном сервере и 4 потока ввода-вывода на низкоуровневом сервере. В отличие от этого, GPUKV использует только два потока обработки команд ввода-вывода ЦП. На рис. 22 все результаты нормализованы для циклов ЦП, используемых GPUKV.

Рис. 22. Нормализовано использование ЦП по отношению к GPUKV для рабочих нагрузок потоковой передачи wynthetic (^W_syntetic). Циклы ЦП GPUKV, измеренные на серверах highend и lowend, составляют 2,07 х 10¹¹ и 4,78 х 10¹⁰, соответственно.

Во-первых, были проанализированы циклы ЦП, потребляемые GPUKV. Циклы ЦП, потребляемые GPUKV на рис. 22 (а), при мерно в 4,3 раза выше, чем на рис. 22 (b). Это связано с тем, что у высокопроизводительного сервера больше ядер ЦП и более высокая скорость ЦП, чем у низкопроизводительного сервера.

GPUKV ожидает запросов ключ-значение от графического процессора через драйвер GPUKV. Кроме того, поскольку между хостом и графическим процессором нет поддержки прерываний, хост должен опрашивать общую память между хостом и графическим процессором и ждать запроса. Однако в опросе нет необходимости, если (i) запрос может быть отправлен непосредственно с графического процессора на контроллер SSD или (ii) разрешено прерывание между хостом и графическим процессором. На рис. 22 (а) опрос занимает 96% потребляемых циклов ЦП, а на рис. 9(б) — 70%. Из этих результатов видно, что в нашем прототипе GPUKV значительно потребляет такты ЦП при опросе. Однако мы отмечаем, что накладные расходы на опрос можно устранить, если принять вышеупомянутые методы.

Затем были проанализированы циклы ЦП, потребляемые KVSSD и RocksDB. Как и ожидалось, на обработку запросов ввода-вывода приходится более половины всех циклов ЦП в KVSSD и RocksDB. Они потребляют гораздо больше циклов процессора, чем GPUKV. Обратите внимание, что KVSSD и RocksDB использовали 256 потоков ввода-вывода. Судя по результатам на рис. 5(а), время выполнения KVSSD и RocksDB при использовании 256 потоков ввода-вывода близко к GPUKV. Однако, как видно на рис. 22, KVSSD и RocksDB потребляют от 2 до 117 раз больше циклов ЦП, чем GPUKV.

Сопутствующие работы

P2P-коммуникация. Были проведены исследования по разрешению прямого доступа к файловой системе с GPU. GPUfs использует общую память для связи между хостом и графическим процессором, что позволяет ядру, работающему на графическом процессоре, выполнять операции ввода-вывода с использованием API файловой системы. SPIN [10] также расширяет GPUfs для реализации передачи данных на GPU с использованием кеша страниц CPU. В частности, SPIN предложил гибридный алгоритм, который при необходимости использует как страничный кеш, так и P2P-связь при передаче данных с SSD на GPU. Однако и GPUfs, и SPIN полагаются на файловую систему хоста, чтобы найти расположение блоков файла при выполнении P2P, поэтому они значительно используют ресурсы хоста.

SSD с обработкой в хранилище (ISP, In-Storage-Processing). Summarizer [11] и GraphSSD [12] переносят задачи ЦП хоста на SSD и выполняют их, используя его аппаратные ресурсы. Summarizer снижает накладные расходы на обмен данными между хост-процессором и твердотельными накопителями за счет анализа запросов TPCH и переноса на процессор твердотельных накопителей только задач обработки запросов с интенсивным использованием данных. Кроме того, был предложен метод правильной установки коэффициента разгрузки запросов с учетом вычислительной эффективности SSD и коммуникационных издержек. GraphSSD — это SSD, который распознает семантику графа и может выполнять обработку графа внутри SSD, сводя к минимуму накладные расходы на связь между хостом и SSD. При сохранении необработанных данных процессор SSD преобразует данные в формат, учитывающий семантику графа, и сохраняет его.

SSD типа “ключ-значение”. В нескольких работах [13, 14, 15] предложены KVSSD, использующие интернет-провайдеров для реализации хранилища ключей и значений внутри SSD. Хранилище ключей-значений хоста выгружается на SSD и работает внутри SSD. KVSSD расширяет команду NVMe для отправки запроса на ключ-значение на SSD. В частности, в Transaction [14] была предложена составная команда, которая может минимизировать накладные расходы интерфейса ввода-вывода с SSD за счет объединения нескольких пар ключ-значение в одной операции NVMe.

iLSM [15] реализует дерево слияния структуры журнала в прошивке для управления парами ключ-значение. Эти KVSSD полностью избавляются от накладных расходов файловой системы, упрощая стек ввода-вывода. Pink [13] сравнил и проанализировал различные структуры данных, такие как хэш и LSM, для проектирования KVSSD.

Гетерогенные вычисления. Гетерогенные вычисления относятся к системе, состоящей из высокоскоростных основных хост-процессоров и медленных, но крупномасштабных параллельных со процессоров (CPUGPU). В этой системе ЦП и ГП могут совместно выполнять рабочую нагрузку, повышая производительность [16-20]. Однако в этих системах, когда GPU и CPU совместно используют данные в кэше страниц, возникают такие проблемы, как несогласованность данных и ложное совместное использование. Цилинь [19] автоматизировал вычислительное картографирование, распределяя работу внутри гетерогенных систем. Солрос [20] использовал сопроцессор Xeon Phi и предложил операционную систему, которая может эффективно использовать его, делегируя сложный стек ввода-вывода высокоскоростному хост-процессору. GAIA [16] решила проблему ложного совместного использования и несогласованности данных за счет интеграции памяти графического процессора и кэша страниц ОС.

Заключение по решению с GPUKV

В системной среде, где хранилище ключей-значений работает в файловой системе хоста, обращение к данным должно пройти через сложный стек ввода-вывода, чтобы предоставить входные данные ядру GPU. Предложенная ранее связь P2P, позволяющая GPU и SSD обмениваться данными напрямую без операций копирования памяти, не позволяет для копирования данных из хранилища «ключ-значение» (в котором хранятся неструктурированные данные) в память GPU избежать вмешательства CPU для взаимодействия с базой данных или файловой системой.

Предложенный в исследовании [7] GPUKV фреймворк, в котором KVSSD и GPU выполняют прямое P2P-взаимодействие, дает возможность обойти сложные стеки ввода-вывода для загрузки данных в память GPU. В GPUKV ядро графического процессора отправляет запросы ключ-значение непосредственно на KVSSD. Затем KVSSD могут передавать данные напрямую на графические процессоры без вмешательства центрального процессора, обеспечивая полноценные вычисления, управляемые графическим процессором. Для оценки использовались как синтетические, так и реалистичные рабочие нагрузки. Обширные результаты оценки показывают, что для большинства рабочих нагрузок GPUKV приводит к наименьшему времени выполнения с минимальным использованием ресурсов хоста, таких как цикл ЦП и память, по сравнению с обычными моделями вычислений на GPU с использованием CPU.

 

Источники, доп. ресурсы

[1] NVMe® Key Value Command Set Provides the Key to Storage Efficiency. By Bill Martin, SSD I/O Standards, Samsung. Posted on: July 18, 2022 – https://nvmexpress.org/nvme-key-value-command-set-provides-the-key-to-storage-efficiency/.

[2] The Key to Value: Understanding the NVMe Key-Value Standard. Live Webcast. September 1, 2020 – https://www.snia.org/sites/default/files/ESF/Key-Value-Storage-Standard-Final.pdf.

[3] Los Alamos National Laboratory and SK hynix to demonstrate first_of_a_kind ordered Key-value Store Computational Storage Device. Demonstration at 2022 Flash Memory Summit in Santa Clara. JULY 28, 2022 – https://discover.lanl.gov/news/0728storage-device/.

[4] SK hynix and Los Alamos Labs to demo key-value store accelerating SSD. 1 Aug 2022 – https://www.theregister.com/2022/08/01/sk_hynix_lanl_kv_csd/.

[5] SNIA PM+CS’22: Accelerating Near Real_time Algorithms Using Disaggregated Computational Storage. Mayank Saxena, Sr. Director, Engineering, Samsung. 8 june 2022 – https://www.youtube.com/watch?v=lWzmj6_rMkw, https://www.snia.org/pmcs-summit2022, https://www.snia.org/educational-library/accelerating-near-real-time-algorithms-using-disaggregated-computational-storage, https://youtu.be/zM65yF6ejGs, https://www.openfabrics.org/wp-content/uploads/2022-workshop/2022-workshop-presentations/108_MSaxena.pdf.

[6] High-Capacity SSDs for AI/ML using Disaggregated Storage Solution: Performance Test Results Show Promise. Jun 29, 2022 – https://semiconductor.samsung.com/us/newsroom/tech-blog/high-capacity-ssds-for-ai-ml-using-disaggregated-storage-solution-performance-test-results-show-promise/.

[6а] Storage for a New Generation of AI/ML. Somnath Roy – Principle Engineer – Samsung Memory Solutions Lab. SNIA Persistent Memory and Computational Storage Summit 2022 – https://www.snia.org/sites/default/files/PM_Summit/2022/PMCS22_Roy_Evolving_Storage_For_New_Generation.pdf, https://www.youtube.com/watch?v=uMCoYgpmDDU.

[7] GPUKV: An Integrated Framework with KVSSD and GPU Through P2P Communication Support. SAC ’21, March 22–26, 2021, Virtual Event, Republic of Korea – https://nona1314.github.io/pubs/gpukv-jung-sac21.pdf.

[8] Zhen Xu, Xuhao Chen, Jie Shen, Yang Zhang, Cheng Chen, and Canqun Yang. 2019. GARDENIA: A Graph Processing Bench mark Suite for Next Generation Accelerators. ACM Journal on Emerging Technologies in Computing Systems (JETC) 15, 1 (2019), 1–13 – http://people.csail.mit.edu/xchen/docs/jetc_2018.pdf.

[9] Ryan A. Rossi and Nesreen K. Ahmed. 2013. Graph Repository – http://www.graphrepository.com.

[10] Shai Bergman, Tanya Brokhman, Tzachi Cohen, and Mark Silberstein. 2017. SPIN: Seamless Operating System Integration of Peer to peer DMA between SSDs and GPUs. In In Proceedings of the USENIX Annual Technical Conference (USENIX ATC’17). 167–179. – https://www.usenix.org/system/files/conference/atc17/atc17_bergman.pdf.

[11] Summarizer: Trading Communication with Computing Near Storage. 2017. – https://intra.engr.ucr.edu/~htseng/files/MICRO2017_Summarizer.pdf.

[12] GraphSSD: Graph Semantics Aware SSD. 2019 22 june – https://dl.acm.org/doi/pdf/10.1145/3307650.3322275.

[13] Junsu Im, Jinwook Bae, Changwoo Chung, Avind, and Sungjin Lee. 2020. PinK: High-speed-In-storage Key-value Store with Bounded Tails. In In Proceedings of the USENIX Conference on File and Storage Technologies (USENIX FAST ’20). 173 – 187. – https://www.usenix.org/system/files/atc20–im–0.pdf.

[14] Sang Hoon Kim, Jinhong Kim, Kisik Jeong, and Jin Soo Kim. 2019. Transaction Support Using Compound Commands in Key-value SSDs. In In Proceedings of the 11th USENIX Workshop on Hot Topics in Storage and File Systems (HotStorage ’19). – https://www.usenix.org/system/files/hotstorage19-paper-kim.pdf.

[15] Chang-Gyu Lee, Hyeongu Kang, Donggyu Park, Sungyong Park, Youngjae Kim, Jungki Noh, Woosuk Chung, and Kyoung Park. 2019. iLSM SSD: An Intelligent LSM Tree Based Key-value SSD for Data Analytics. In In Proceedings of the IEEE 27th International Symposium on Modeling, Analysis, and Simulation of Computer and Telecommunication Systems (MASCOTS ’19). 384–395. – https://discos.sogang.ac.kr/file/2019/intl_conf/IEEE_MASCOTS_2019_CGLee.pdf.

[16] Tanya Brokhman, Pavel Lifshits, and Mark Silberstein. 2019. GAIA: An OS Page Cache for Heterogeneous Systems. In In Proceedings of the USENIX Annual Technical Conference (USENIX ATC ’19). 661–674.

[17] Prince Hamandawana, Awais Khan, Chang-Gyu Lee, Sungyong Park, and Young-jae Kim. 2020. Crocus: Enabling Computing Resource Orchestration for Inline Cluster_wide Deduplication on Scalable Storage Systems. IEEE Transactions on Parallel & Distributed Systems 31, 08 (August 2020), 1740–1753.

[18] Anakhi Hazarika, Soumyajit Poddar, and Hafizur Rahaman. 2020. Survey on Memory Management Techniques in Heterogeneous Computing Systems. IET Computers & Digital Techniques 14, 2 (February 2020), 47–60.

[19] Chi-Keung Luk, Sunpyo Hong, and Hyesoon Kim. 2009. Qilin: Exploiting Parallelism on Heterogeneous Multiprocessors with Adaptive Mapping. In In Proceedings of the 42nd Annual IEEE/ACM International Symposium on Microarchitecture (MICRO ’09). 45–55.

[20] Changwoo Min, Woonhak Kang, Mohan Kumar, Sanidhya Kashyap, Steffen Maass, Heeseung Jo, and Taesoo Kim. 2018. Solros: A Datacentric perating System Architecture for Heterogeneous Computing. In Proceedings of the 13th EuroSys Conference (EuroSys ’18). 1–15.

Авторы: Гантимуров А.П., Калашник А.Г.

Отслеживать