История DAOS

DAOS (Distributed Asynchronous Object Storage, https://docs.daos.io/) — это масштабируемое хранилище объектов с открытым исходным кодом, разработанное с нуля для обеспечения чрезвычайно высокой пропускной способности/операций ввода-вывода с малой задержкой для самых требовательных данных, интенсивные нагрузки. Он направлен на поддержку рабочих процессов HPC следующего поколения, которые сочетают моделирование, большие данные и искусственный интеллект на одном уровне хранения. DAOS представляет собой богатый и масштабируемый интерфейс хранилища, который позволяет эффективно хранить как структурированные, так и неструктурированные данные. DAOS поддерживает несколько интерфейсов приложений, включая параллельную файловую систему, коннектор Hadoop/Spark, TensorFlow-IO, собственные привязки словарей Python, HDF5, MPIIO, а также модели данных для конкретной предметной области, такие как SEGY [1].

Проект DAOS (cтек программно-определяемого хранилища с открытым исходным кодом) был инициирован в 2012 г., основной целью которого было расширение возможностей существующих СХД в части производительности и масштабирования (http://www.storagenews.ru/74/Intel_DAOS_74.pdf). Можно выделить три этапа его развития (рис. 1, [3]):

Рис. 1. История развития DAOS [3].

• 2012–2014 гг. – разработка двухуровневого прототипа параллельной СХД на основе Lustre и PLFS;
• 2015–2017 гг. – разработка автономного прототипа DAOS (“обход” ОС, использование persistent memory, поддержка репликации и самовосстановления);
• 2018–2022 гг. – продуктизация DAOS для суперкомпьютеров Exascale уровня производительности с применением технологий Intel^® Optane™ (DC Persistent Memory и DC SSD) и Intel^® QLC 3D NAND SSD, а также второго поколения процессоров Intel Xeon Scalable (кодовое название – Cascade Lake).

Ключевой особенностью 3-го этапа является и то, что сфера применения DAOS расширена (к параллельным FS), и теперь проект охватывает как традиционное HPC, так и направления Data Science

Analytics и Artificial Intelligence

Одна из ключевых архитектурных концепций DAOS – полный отказ от использования HDD и переходом на флэш-технологии, а также отдельное хранение (но на одном уровне) данных и метаданных. Для метаданных использовалась технология Intel^® Optane™ DC Persistent Memory (с побайтной адресацией), для данных – SSD с блочной адресацией. Т.к. в конце июля 2022 г. Intel сообщила о прекращении развития технологии Intel^® Optane™ и о продаже ее производства, то вопрос в настоящее время вопрос о ее замене (речь идет об Intel^® Optane™ DC Persistent Memory) – один из актуальных. Intel предлагает в течение нескольких лет переходить с Intel^® Optane™ PMem на CXL-память, подключаемую через CXL™ Bridge (рис. 2). В настоящее время DAOS, например, получила реализацию в решениях на базе серверов Lenovo и SuperMicro. На рис. 2 отражены планы по дальнейшему развитию проекта DAOS [2] с учетом этого обстоятельства.

Рис. 2. Программа развития DAOS до конца 2024 г. [2] (https://daosio.atlassian.net/wiki/spaces/DC/pages/4836661105/Roadmap).

Планируется поддержка интерконнектов HPE Slingshot, OmniPath Express, а также в версии 3.0 – MultiHomed Network (подключение узлов хранения DAOS к вычислительным узлам через несколько сетей, например, через IB и Ethernet, рис. 2а). В настоящее время поддерживаются InfiBand фабрики и TCP для других фабрик.

Рис. 2а. Миграция с Intel^® Optane™ PMem на CXL-память, подключаемую через CXL™ Bridge [4].

До 2022 г. проект DAOS (платформа/хранилище DAOS) развивался с блочным и побайтным доступом к данным. С версии 2.2 для DAOS стал развиваться интерфейс хранения «ключ-значение» (поверх стандартного оборудования), который предоставляет такие функции, как транзакционный неблокирующий ввод-вывод, улучшенная защита данных с самовосстановлением, сквозная целостность данных, детальный контроль данных и эластичное хранилище (хранилище с высокой простой масштабируемостью) для оптимизации производительности и затрат (https://docs.daos.io/v2.2/).

Рис. 3. Варианты реализации опции DAOS Multi-Homed Network [2].

Активное участие в развитии этого направления принимает компания Seagate, интегрировав свободно распространяемый интерфейс объектного доступа S3 CORTX в программный стек DAOS.

Много полезной информации о прошедших/будущих событиях, текущем состоянии разработок и др. на сайте сообщества DAOS: https://daosio.atlassian.net/wiki/spaces/DC/overview?homepageId=4783639579 и DAOS User Group (DUG) – https://daosio.atlassian.net/wiki/spaces/DC/pages/4836659682/.

Среди основных особенностей платформы DAOS v 2.2 (рис. 4, 5):

• полностью распределенное многопользовательское глобальное пространство имен;
• платформа для инноваций:
  • модульный API и многоуровневость;
  • возможность использовать новейшие аппаратные и программные технологии;
• создана для высокой производительности – задержка 10 мкс, миллиарды операций ввода-вывода в секунду, пропускная способность от ТБ/с до ПБ/с;
• полная модель пользовательского пространства (работает локально или в облаке);
• растущее сообщество открытого исходного кода.

В конце октября 2022 г. была представлена версия DAOS 2.2.0 (https://docs.daos.io/v2.2/release/release_notes/):

• добавлена поддержка Rocky Linux 8 и Alma Linux 8;
• поддержка CentOS Linux 8 была удалена и заменена поддержкой Rocky Linux 8 и Alma Linux RedHat больше не поддерживает RHEL 8.5; RHEL 8.6 и RHEL 8.4 EUS по-прежнему поддерживаются;
• добавлена поддержка UCX (предварительная версия технологии — не поддерживается в производственных средах);
• добавлена поддержка libfabric/tcp (замена libfabric/sockets).

Рис. 4. DAOS: открытая платформа хранения нового поколения [3].

Рис. 5. Экосистема ПО DAOS [3].

Полный список поддерживаемого оборудования и программного обеспечения в таблице поддержки – https://docs.daos.io/v2.2/release/support_matrix/.

DAOS версии 2.2 была проверена в следующих масштабах:

• клиентские узлы DAOS в системе DAOS: 256;
• серверы DAOS в системе DAOS: 128;
• механизмы DAOS на сервер DAOS: 1, 2 и 4;
• цели DAOS на движок DAOS: 416;
• устройства хранения SCM на ядро DAOS: 6 (Optane PMem 100),8 (Optane PMem 200);
• устройства хранения NVMe на механизм DAOS: 0 (пулы только для PMem), 4–12;
• пулы DAOS в системе DAOS: 100;
• контейнеры DAOS в пуле DAOS: 100;
• объекты DAOS в контейнере DAOS: 6 миллиардов (в тестах mdtest);
• задачи приложений, обращающиеся к контейнеру DAOS: 3072 (с использованием глаголов).

Это тестовое покрытие будет расширено в последующих выпусках DAOS.

DAOS версии 2.2 поддерживает архитектуру x86_64. Клиенты DAOS не имеют конкретных аппаратных зависимостей.

Каждому клиенту DAOS нужен сетевой порт на том же высокоскоростном межсоединении, к которому подключены серверы DAOS. Поддерживается несколько высокоскоростных сетевых портов для каждого клиента DAOS. Одна задача на клиенте DAOS всегда будет использовать один сетевой порт, но, когда используется несколько задач на клиентский узел, агент DAOS распределяет нагрузку, выделяя разные сетевые порты для разных задач.

DAOS остается ключевой частью технологической стратегии Intel HPC/AI. Проект продолжает продвигаться в запланированном темпе выпуска релизов. Последний выпуск DAOS 2.2 состоялся в конце октября 2022 г. DAOS в лидерах по совокупности реализаций списка Top500 (среди первых 20) в тестах IO500 (https://io500.org/).

Компания Lenovo и Intel объединили усилия для создания решения для хранения данных DAOS на базе серверов Lenovo ThinkSystem с процессорами Intel Xeon.

Еще одно партнерство по поддержке DAOS, созданное Croit GmbH (https://croit.io/), делится своим опытом в области управления и поддержки программно-определяемых хранилищ с открытым исходным кодом, выпустив свою платформу Croit для DAOS. Это позволит пользователям легко развертывать кластеры DAOS и управлять ими, а также использовать дополнительные методы доступа, обычно используемые в традиционных корпоративных продуктах, таких как NVMeOF, S3 и NFS. Croit также объявляет о создании дочерней компании в США для улучшения обслуживания и расширения присутствия на рынке США. Эти два партнерства по стратегической поддержке помогут ускорить внедрение решений DAOS в HPC, AI, HPDA и конвергентных корпоративных ИТ услугах [5].

Google Cloud предлагает DAOS для оптимизации производительности и производительности хранилища/$

DAOS появился в Google Cloud, что позволяет быстро и легко оптимизировать затраты и производительность/$ для проектов Google Cloud. Спрос на производительность хранения растет в облачной инфраструктуре HPC. В то время как Lustre является основой высокопроизводительных параллельных файловых систем в HPC, традиционные HPC, AI, HPDA и корпоративные развертывания с DAOS растут из-за его высокой пропускной способности, низкой задержки и высокой производительности IOPS, не обходимой для рабочих нагрузок в этих доменах. В связи с расширением объема данных в вычислениях и растущим использованием Google Cloud для высокопроизводительных вычислений интеграция DAOS в Cloud HPC Toolkit (https://cloud.google.com/blog/products/compute/new–google–cloud–hpc–toolkit) стала важным шагом на пути к дальнейшему предоставлению высокопроизводительной облачной инфраструктуры для различных рабочих нагрузок.

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

DAOS также может принести пользу обучению ИИ, поскольку набор обучающих данных запускается из высокопроизводительного хранилища DAOS, сохраняя при этом данные на дисках. Google рассматривает другие варианты использования, в которых DAOS дополнит свои традиционные предложения в Google Cloud для клиентов.

Архитектура DAOS

DAOS — это программно-определяемое масштабируемое хранилище объектов с открытым исходным кодом, которое предоставляет приложениям контейнеры хранения с высокой пропускной способностью и высокой скоростью ввода-вывода в секунду и обеспечивает рабочие процессы нового поколения, ориентированные на данные, сочетающие моделирование, анализ данных и машинное обучение (https://docs.daos.io/v2.2/overview/architecture/).

DAOS и традиционные хранилища

В отличие от традиционных стеков хранения, которые в первую очередь были разработаны для вращающихся носителей, DAOS с нуля спроектирована для использования новых технологий NVM и чрезвычайно легковесна, поскольку работает в режиме End-to-End (E2E) в пользовательском пространстве с полным обходом ОС.

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

Задержка в традиционном хранилище

В традиционном решении для хранения метаданные информируют операционную систему (ОС) о расположении данных в кластере хранения. Каждый раз, когда система обращается к данным для операций чтения или записи, она также должна создавать или изменять коррелирующие метаданные в блоке ввода-вывода на базовом носителе данных. В вычислительных кластерах нескольким узлам может потребоваться доступ к одному и тому же блоку, поэтому традиционное хранилище временно блокирует блок, чтобы предотвратить конфликты записи. При репликации миллионов операций чтения/записи этот процесс создает значительную задержку хранилища, которая ограничивает ввод-вывод приложений (https://www.intel.com/content/www/us/en/high-performance-com-puting/daos.html).

Задержки записи в микросекундах в DAOS

В конфигурации DAOS модули энергонезависимой памяти Intel® Optane™ (или аналоги) хранят метаданные для всего кластера побайтно, а не по блокам, поэтому нет необходимости блокировать блок, как в традиционном хранилище. Кроме того, использование твердотельных накопителей NVMe позволяет вводам-выводам хранилища насыщать шину PCIe большим конвейером данных по сравнению с твердотельными накопителями SATA¹). В результате DAOS может обеспечивать ввод-вывод хранилища, который на несколько порядков быстрее — от миллисекунд (мс) до десятков микросекунд (мкс) — по сравнению с традиционным хранилищем²). Постоянная память также сохраняет метаданные при выключении или перезагрузке системы и может поглощать небольшие операции записи, чтобы обеспечить бесперебойную работу системы и доступность для строгих соглашений об уровне обслуживания. В развертываниях DAOS с хранилищем 3D QLC NAND энергонезависимая память также может помочь снизить влияние на производительность нагрузки записи в кластере хранения.

ПО с открытым исходным кодом и проверенные выпуски DAOS

В дополнение к аппаратному уровню поставщикам решений потребуется программное обеспечение DAOS с открытым исходным кодом для завершения стека. Разработчики могут скачать и скомпилировать код прямо с GitHub. Для упрощения развертывания протестированные и проверенные бинарные версии доступны на веб-сайте сообщества daos.io. Intel активно сотрудничает с партнерами и поставщиками решений, чтобы их продукты DAOS получали техническую поддержку L3.

HPC и большие данные: хранилище DAOS, изменяющее будущее

В кластерах больших данных и HPC вычислительные узлы тесно связаны с уровнями хранения, и специалисты по обработке и анализу данных обычно имеют дело с различными типами холодных, горячих и горячих данных. Будущее конфигураций хранения будет зависеть от гибридного подхода, при котором DAOS подключается к файловым системам, которые также используют оптимизированные по стоимости диски SATA. Академические и государственные лаборатории уже наблюдают результаты высокой загрузки вычислительных ресурсов в кластерах высокопроизводительных вычислений, которые способствуют быстрому обнаружению.

Например, радиологический исследовательский центр Вашингтонского университета развернул программно-определяемую систему хранения (https://www.intel.com/content/dam/www/central-libraries/us/en/documents/intel-croit-white-paper-9de.pdf) с поддержкой DAOS для хранения до 13 петабайт данных при сниженной стоимости на 1500 долларов США за узел хранения³). Коммерческие развертывания HPC также демонстрируют большой потенциал, особенно в секторах энергетики и здравоохранения, которые зависят от рабочих нагрузок HPC AI, аналитики и моделирования. В бенчмарке IO-500, рейтинге самых быстрых систем хранения в мире, половина из 10 лучших позиций в настоящее время принадлежит конфигурациям DAOS⁴).

Хранилище DAOS для экстремальной производительности

DAOS — это файловая система, выбранная для суперкомпьютера Aurora Аргоннской национальной лаборатории (ANL, https://www.intel.com/content/www/us/en/customer–spotlight/stories/argonne–aurora–customer–story.html), первой запланированной системы высокопроизводительных вычислений, нацеленной на экзафлопсную вычислительную производительность, с хранилищем до 230 петабайт с поддержкой DAOS и пропускной способностью > 25 ТБ/с при чтении/записи. ANL и Texas Advanced Computing Center (TACC), еще один партнер Intel в области высокопроизводительных вычислений с поддержкой DAOS, также вошли в пятерку лучших в списке IO-500 по состоянию на сентябрь 2020 года. Эти успехи также вызвали интерес со стороны CSP, таких как Google Cloud. Platform, которая в настоящее время планирует интегрировать DAOS в свои облачные службы хранения данных.

Низкие задержки чтения, даже при наличии давления записи

Даже для экономичных носителей, которые подходят для рабочих нагрузок с интенсивным чтением, DAOS может оказать положительное влияние. При тестировании с твердотельными накопителями Intel^® QLC 3D NAND вместо твердотельных накопителей NVMe конфигурация DAOS смогла обеспечить задержку чтения в пять девяток (P99,999) между 200 и 300 мкс, что означает, что 99,999% всех запросов были доставлены менее 300 мкс. ²⁾  При скорости записи до 2500 МБ/с тот же тест показал, что DAOS может поддерживать соглашения об уровне обслуживания файловой системы для достижения пяти девяток менее чем за 5 мс. ²⁾

Масштабируемые процессоры Intel® Xeon® и производительность DAOS

Производительность процессора в узле хранения положительно повлияет на производительность DAOS. Улучшения количества каналов памяти, пропускной способности на канал, а также скорости PCIe (PCIe 4 по сравнению с PCIe 3) существенно повышают эффективность DAOS. В эталонном тесте IOR конфигурация с масштабируемыми процессорами Intel^® Xeon^® 3-го поколения и энергонезависимой памятью Intel^® Optane™ серии 200 показала 58-процентное увеличение производительности записи по сравнению с ЦП и энергонезависимой памятью предыдущего поколения. ⁵⁾  Ожидается, что PCIe Gen 5 в будущих поколениях процессоров обеспечит еще более высокий уровень производительности DAOS. Получите предварительное представление об удивительной производительности высокопроизводительных вычислений, которую DAOS обеспечит на масштабируемых процессорах Intel^® Xeon^® 4-го поколения (https://www.intel.com/content/www/us/en/high- performance-computing/performance-evolution-of-daos-servers.html).

1) Configurations: Performance claims obtained from data sheet, sequential read/write at 128K block size for NVMe and SATA, 64K for SAS. Intel® SSD DC P3700 Series 2 TB, SAS Ultrastar SSD1600MM, Intel® SSD DC S3700 Series SATA 6 Gbps. Intel® Core™ i7-3770K CPU @ 3.50 GHz, 8 GB of system memory, Windows Server 2012, IOMeter. Random performance is collected with four workers each with 32 QD.

2) “Achieve High-Performance Storage with DAOS,” intel.com, June 2021.

3) “Washington University: Deploying High-Speed Storage with Intel® Technologies,” intel.com, October 2021.

4) IO500.org as of October 2021.

5) Test by Intel® as of October 15, 2020. Baseline configuration: Platform: S2600WFO, 1 node with 2x8260L Platinum Intel® Xeon® 2nd Gen Scalable CPUs, microcode 0x400002c, HT and turbo on, performance mode, system BIOS SE5C620.86B.02.01.0008.031920191559, PMem Firmware 01.00.00.5127, system DRAM config 12 slots / 16 GB / 2666 (192 GB total memory), system PMem Config 12 slots / 512 GB / 2666 (6 TB total PMem), 1x Intel® SATA SSD, 2x Intel® OPA100 NIC, PCH Intel® C621, OS openSUSE Leap 15.2, Kernel 5.3.18lp152.44default, workload DAOS 1.1.0. New configuration: Platform: WLYDCRB1, 1 node with 2x ICX24C Intel® Xeon® 3rd Gen Scalable CPUs (Ice Lake preproduction), microcode 0x8b000260, HT and turbo on, performance mode, sys tem BIOS WLYDCRB1.SYS.0017.D75.2007020055, PMem Firmware 02.01.00.1110, system DRAM Config 16 slots / 16 GB / 3200 run at 2933 (256 GB total memory), system PMem config 16 slots / 512 GB / 2933 (8 TB total PMem), 1x Intel® SATA SSD, 2x Intel® OPA100 NIC, PCH Intel® C621, OS openSUSE Leap 15.2, Kernel 5.3.18-lp152.44-default, workload DAOS 1.1.0.

Особенности DAOS

DAOS использует интерфейс Open Fabric (OFI, https://openfabrics.org/downloads/ofiwg/Industry_presentations/2015_HotI23/paper.pdf) для связи с малой задержкой и хранит данные как в памяти класса хранения (SCM, storage-class memory), так и в хранилище NVMe. DAOS представляет собственный интерфейс хранения данных типа «ключ массив-значение», который предлагает унифицированную модель хранения, поверх которой переносятся модели данных, специфичные для предметной области, такие как HDF5 (https://docs.daos.io/v2.2/user/hdf5/), MPIIO (https://docs.daos.io/v2.2/user/mpiio/) и Apache Hadoop (https://docs.daos.io/v2.2/user/spark/). Также доступен уровень эмуляции ввода-вывода POSIX, реализующий файлы и каталоги через собственный API DAOS.

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

Хранилище SCM сопоставляется с памятью непосредственно в адресное пространство службы DAOS, которая управляет постоянным индексом посредством прямой загрузки/сохранения. В зависимости от характеристик ввода-вывода служба DAOS может принять решение о хранении ввода-вывода либо в хранилище SCM, либо в хранилище NVMe. Как показано на рис. 6, операции ввода-вывода, чувствительные к задержкам, такие как метаданные приложений и данные с гранулярным представлением байтов, обычно хранятся в первом, а контрольные точки и объемные данные — во втором. Этот подход позволяет DAOS предоставлять не обработанную пропускную способность NVMe для массовых данных путем потоковой передачи данных в хранилище NVMe и поддержания внутреннего индекса метаданных в SCM. Комплект Persistent Memory Development Kit (PMDK) позволяет управлять транзакционным доступом к SCM, а Storage Performance Development Kit (SPDK) обеспечивает ввод-вывод в пользовательском пространстве для устройств NVMe (рис. 6).

Рис. 6. Хранилище DAOS.

DAOS обеспечивает:

• высокую пропускную способность и IOPS при произвольном выравнивании (arbitrary alignment) и размере;
• высоко гранулированные операции ввода-вывода с true zero-copy I/O в SCM;
• поддержку массивно распределенного хранилища NVM посредством масштабируемой коллективной связи между серверами хранения;
• неблокирующие операции с данными и метаданными, позволяющие перекрывать операции ввода-вывода и вычислений;
• расширенное размещение данных с учетом доменов сбоя;
• резервирование, управляемое программным обеспечением, поддерживающее как репликацию, так и стирание кода с онлайн-восстановлением;
• сквозную целостность данных;
• масштабируемые распределенные транзакции с гарантированной согласованностью данных и автоматическим восстановлением;
• снапшот набора данных;
• платформу безопасности для управления контролем доступа к пулам хранения;
• программно-определяемое управление хранилищем для предоставления (provision), настройки, изменения и мониторинга пулов хранения данных на оборудовании COTS;
• встроенную поддержку для Hierarchical Data Format (HDF)5, MPI-IO и пространства имен POSIX в модели данных DAOS;
• инструменты аварийного восстановления;
• полную интеграцию с параллельной файловой системой Lustre;
• поддержку агента перемещения для переноса наборов данных между пулами DAOS и из параллельных файловых систем в DAOS и наоборот.

DAOS-система

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

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

Сервер DAOS — это мультитенантный демон, работающий на экземпляре Linux (либо изначально на физическом узле, либо в виртуальной машине, либо в контейнере) каждого узла хранения. Его под процессы Engine экспортируют локально подключенные хранилища SCM и NVM через сеть. Он прослушивает порт управления (адресуемый по IP-адресу и номеру TCP-порта), а также одну или несколько конечных точек структуры (адресуемые по сетевым URI). Сервер DAOS настраивается через файл YAML в /etc/daos, включая конфигурацию его подпроцессов Engine. Запуск сервера DAOS можно интегрировать с различными средами управления или оркестрации демонов (например, скриптом systemd, службой Kubernetes или даже с помощью параллельного средства запуска, такого как pdsh или srun).

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

Модули SCM настроены в режиме AppDirect interleaved. Таким образом, они представляются операционной системе как единое пространство имен PMem для каждого сокета (в fsdax режиме).

Когда настроено N целей на движок (engine), каждая цель использует 1/N емкости fsdax SCM этого сокета, независимо от других целей.

Каждая цель также использует часть емкости NVMe дисков NVMe, подключенных к этому сокету. Например, в движке с 4 дисками NVMe и 16 целями каждая цель будет управлять 1/4 одного диска NVMe.

Цель не реализует какой-либо внутренний механизм защиты данных от сбоя носителя. В результате цель представляет собой единую точку отказа и единицу отказа. С каждой целью связано динамическое состояние: ее состояние может быть либо «включено и работает», либо «недоступно и недоступно».

Цель — это единица измерения производительности. Аппаратные компоненты, связанные с целью, такие как внутренний носитель данных, ядра ЦП и сеть, имеют ограниченные возможности и емкость.

Количество целей, экспортируемых экземпляром ядра DAOS, настраивается и зависит от базового оборудования (в частности, от количества модулей SCM и количества твердотельных накопителей NVMe, обслуживаемых этим экземпляром ядра). Рекомендуется, чтобы количество целей ядра было целым числом, кратным количеству дисков NVMe, обслуживаемых этим ядром.

SDK и инструменты

Приложения, пользователи и администраторы могут взаимодействовать с системой DAOS через два разных клиентских API. API управления предлагает возможность администрирования системы DAOS и предназначен для интеграции со специфическими для поставщика системами управления хранилищем и платформами оркестровки с открытым исходным кодом. Инструмент dmg CLI построен на основе API управления DAOS. С другой стороны, библиотека DAOS (libdaos) реализует модель хранения DAOS. Он в первую очередь предназначен для разработчиков приложений и промежуточного программного обеспечения ввода-вывода, которые хотят хранить наборы данных в системе DAOS. Пользовательские утилиты, такие как daos-команда, также построены на основе API, чтобы пользователи могли управлять наборами данных из интерфейса командной строки.

Приложения могут получать доступ к наборам данных, хранящимся в DAOS, либо напрямую через собственный API DAOS, через библиотеку промежуточного программного обеспечения ввода вывода (например, эмуляцию POSIX, MPI-IO, HDF5), либо через такие платформы, как Spark или TensorFlow, которые уже интегрированы с собственным хранилищем DAOS.

Агент

Агент DAOS — это демон, находящийся на клиентских узлах, который взаимодействует с библиотекой DAOS для аутентификации процессов приложений. Это доверенное лицо, которое может подписывать учетные данные библиотеки DAOS с помощью сертификатов. Агент может поддерживать различные платформы проверки подлинности и использует сокет домена Unix для связи с библиотекой DAOS.

Модель хранения

На рис. 7 представлены основные абстракции модели хранения DAOS.

Рис. 7. Модель хранилища DAOS.

Пул DAOS — это резервирование хранилища, распределенное по набору целей. Фактическое пространство, выделенное пулу на каждой цели, называется сегментом пула (pool shard). Общее пространство, выделенное для пула, определяется во время создания. Со временем его можно расширить, изменив размер всех сегментов пула (в пределах емкости хранилища, выделенной для каждой цели) или охватив больше целей (добавив больше сегментов пула). Пул предлагает виртуализацию хранилища и является единицей подготовки и изоляции. Пулы DAOS не могут охватывать несколько систем.

Пул может содержать несколько хранилищ транзакционных объектов, называемых контейнерами DAOS. Каждый контейнер представляет собой адресное пространство частного объекта, которое может быть изменено транзакциями и независимо от других контейнеров, хранящихся в том же пуле. Контейнер — это единица управления моментальными снимками и данными. Объекты DAOS, принадлежащие контейнеру, могут быть распределены по любой цели пула как для повышения производительности, так и для обеспечения устойчивости, и к ним можно получить доступ через различные API для эффективного представления структурированных, полу-структурированных и неструктурированных данных.

Табл. 1. Целевой уровень масштабируемости для каждого уровня/концепта DAOS.

Пул DAOS

Пул идентифицируется уникальным UUID пула и поддерживает целевое членство в постоянном версионном списке, называемом картой пула (pool map). Членство является окончательным и последовательным, а изменения членства последовательно нумеруются. Карта пула не только записывает список активных целей, но также содержит топологию хранилища в виде дерева, которое используется для идентификации целей, использующих общие аппаратные компоненты. Например, первый уровень дерева может представлять цели, использующие одну и ту же материнскую плату, затем второй уровень может представлять все материнские платы, использующие одну и ту же стойку, и, наконец, третий уровень может представлять все стойки в одном корпусе. Эта структура эффективно представляет иерархические домены сбоя, которые затем используются, чтобы избежать размещения избыточных данных на целевых объектах, подверженных коррелирующим сбоям. В любой момент времени на карту пула можно добавить новые цели, а неудачные цели можно исключить. Более того, карта пула полностью версионная.

Сегмент пула (pool shard) — это зарезервированная постоянная память, которая может быть дополнительно объединена с предварительно выделенным пространством в хранилище NVMe для определенной цели. Он имеет фиксированную емкость и не работает при заполнении. Текущее использование пространства может быть запрошено в любое время и сообщает об общем количестве байтов, используемых любым типом данных, хранящимся в сегменте пула.

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

При создании пула необходимо определить набор системных свойств для настройки различных функций, поддерживаемых пулом. Кроме того, пользователи могут определить свои атрибуты, которые будут постоянно храниться.

Пул доступен только для аутентифицированных и авторизованных приложений. Может поддерживаться несколько сред безопасности, от списков управления доступом NFSv4 до аутентификации на основе третьих сторон (например, Kerberos). Безопасность обеспечивается при подключении к пулу. При успешном подключении к пулу контекст подключения возвращается в процесс приложения.

Как подробно описано ранее, в пуле хранится множество различных видов постоянных метаданных, таких как карта пула, информация об аутентификации и авторизации, атрибуты пользователя, свойства и журналы перестроения. Такие метаданные имеют решающее значение и требуют высочайшего уровня отказоустойчивости. Поэтому метаданные пула реплицируются на несколько узлов из отдельных доменов сбоя высокого уровня. Для очень больших конфигураций с сотнями тысяч узлов хранения только очень небольшая часть этих узлов (порядка десятков) запускает службу метаданных пула. Имея ограниченное количество узлов хранения, DAOS может позволить себе полагаться на алгоритм консенсуса для достижения согласия, гарантировать согласованность при наличии сбоев и избежать синдрома “расщепленного мозга” (split-brain).

Чтобы получить доступ к пулу, пользовательский процесс должен подключиться к этому пулу и пройти проверку безопасности. После предоставления соединение пула может использоваться совместно (посредством local2global() и global2local() операциями) с любым или всеми одноранговыми процессами приложения (аналогично openg() расширению POSIX). Этот механизм коллективного подключения помогает избежать бурного потока запросов метаданных, когда в центре обработки данных выполняется массово распределенное задание. Соединение с пулом отменяется, когда исходный процесс, выдавший запрос на соединение, отключается от пула.

DAOS-контейнер

Контейнер представляет собой адресное пространство объекта внутри пула и идентифицируется UUID контейнера. На рис. 8 показано, как пользователь (промежуточное ПО ввода-вывода, формат данных для предметной области, большие данные или платформа искусственного интеллекта и др.) может использовать концепцию контейнера для хранения связанных наборов данных.

Рис. 8. Контейнеры DAOS.

Как и пулы, контейнеры могут хранить пользовательские атрибуты. Набор свойств должен быть передан во время создания контейнера для настройки различных функций, таких как контрольные суммы.

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

Объекты в контейнере могут иметь разные схемы распределения данных и избыточности по целевым объектам. Динамическое или статическое чередование, репликация или код стирания — вот не которые параметры, необходимые для определения схемы объекта. Класс объектов определяет общие атрибуты схемы для набора объектов. Каждому классу объектов присваивается уникальный идентификатор, и он связан с заданной схемой на уровне пула. Новый класс объектов может быть определен в любое время с помощью настраиваемой схемы, которая затем остается неизменной после создания (или, по крайней мере, до тех пор, пока все объекты, при надлежащие классу, не будут уничтожены). Для удобства несколько наиболее часто используемых классов объектов будут предопределены по умолчанию при создании пула, как показано в табл. 2.

Табл. 2. Пример предопределенных классов объектов.

Каждый объект идентифицируется в контейнере уникальным 128-битным адресом объекта (рис. 9). Старшие 32 бита адреса объекта зарезервированы для DAOS для кодирования внутренних метаданных, таких как класс объекта. Остальные 96 бит управляются пользователем и должны быть уникальными внутри контейнера. Эти биты могут использоваться верхними уровнями стека для кодирования своих метаданных, если гарантируется уникальность. Распределитель 64-битного масштабируемого идентификатора объекта для каждого контейнера предоставляется в DAOS API. Идентификатор объекта, который должен храниться приложением, представляет собой полный 128-битный адрес, который предназначен только для одноразового использования и может быть связан только с одной схемой объекта.

Рис. 9. Каждый объект идентифицируется в контейнере уникальным 128-битным адресом объекта – структура DAOS Object ID.

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

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

Как и в случае с пулом, доступ к контейнеру контролируется дескриптором контейнера. Чтобы получить действительный дескриптор, процесс приложения должен открыть контейнер и пройти проверку безопасности. Затем этот дескриптор контейнера можно использовать совместно с другими одноранговыми процессами приложения через контейнерные local2global()и global2local() операции.

DAOS объект

Чтобы избежать проблем с масштабированием и накладных расходов, характерных для традиционной системы хранения, объекты DAOS намеренно упрощаются. Никаких метаданных объекта по умолчанию, кроме типа и схемы, не предоставляется. Это означает, что система не поддерживает время, размер, владельца, разрешения и даже не отслеживает открытие. Для достижения высокой доступности и горизонтальной масштабируемости предусмотрено множество схем объектов (код репликации/удаления, статическое/динамическое чередование и другие). Платформа схемы является гибкой и легко расширяемой, чтобы в будущем можно было использовать новые настраиваемые типы схем. Макет генерируется алгоритмически на открытом объекте из идентификатора объекта и карты пула. Сквозная целостность обеспечивается за счет защиты данных объектов с помощью контрольных сумм во время передачи и хранения по сети.

Доступ к объекту DAOS можно получить через различные API:

• многоуровневый API массива ключей (Multilevel keyarray) — это нативный объектный интерфейс с функцией локализации. Ключ делится на ключ распределения (dkey) и ключ атрибута (akey). И dkey, и akey могут иметь переменную длину и тип (строка, целое число или даже сложная структура данных). Все записи под одним и тем же ключом dkey гарантированно будут размещены на одной и той же цели. Значение, связанное с ключом, может быть либо одним значением переменной длины, которое не может быть частично перезаписано, либо массивом значений фиксированной длины. И akeys, и dkeys поддерживают перечисление;
• API “ключ-значение” (Key-value) предоставляет простой интерфейс ключа и значения переменной длины. Он поддерживает традиционные операции размещения, получения, удаления и перечисления;
• Array API реализует одномерный массив элементов фиксированного размера, адресованных 64-битным смещением. Массив DAOS поддерживает операции чтения, записи и перфорации произвольных экстентов.

Модель поддержания отказоустойчивости

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

Иерархические домены сбоя

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

Метаданные пула реплицируются на нескольких узлах из разных доменов сбоя высокого уровня для обеспечения высокой доступности, в то время как данные объектов могут быть реплицированы или закодированы стиранием по различному количеству доменов сбоя в зависимости от выбранного класса объектов.

Обнаружение неисправности

Механизмы DAOS контролируются в системе DAOS с помощью основанного на “слухах” протокола (gossip-based protocol) SWIM (https://doi.org/10.1109/DSN.2002.1028914), который обеспечивает точное, эффективное и масштабируемое обнаружение неисправностей. Хранилище, подключенное к каждой цели DAOS, отслеживается с помощью периодической локальной оценки работоспособности. Всякий раз, когда на сервер DAOS возвращается ошибка ввода-вывода локального хранилища, автоматически вызывается внутренняя процедура проверки работоспособности. Эта процедура выполнит общую оценку работоспособности путем анализа кода ошибки ввода-вывода и данных SMART/Health устройства. Если результат отрицательный, цель будет помечена как неисправная, а дальнейшие операции ввода-вывода к этой цели будут отклонены и перенаправлены.

Локализация отказов

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

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

Этот механизм гарантирует глобальное вытеснение узла и то, что все узлы в конечном итоге будут иметь одинаковое представление о жизнеспособности цели.

Восстановление после сбоя

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

Этот процесс восстановления выполняется в режиме онлайн, в то время как приложения продолжают обращаться к объектам и обновлять их.

Тестирование, применения DAOS

Появившаяся доступность DAOS в облаке Google помогает пользователям реализовать преимущества высокопроизводительных вычислений в облаке. Это включает в себя возможность создавать и демонтировать целые кластеры высокопроизводительных вычислений за считанные минуты. С помощью Google HPC-toolkit (https://github.com/GoogleCloudPlatform/hpc–toolkit), частью которого является DAOS, пользователи могут перенести свои локальные рабочие нагрузки HPC в Google Cloud. Как хорошо известно пользователям высокопроизводительных вычислений, объединение множества вычислительных устройств приводит к необходимости в высокопроизводительном хранилище с высокой пропускной способностью, малой задержкой и большим количеством операций ввода-вывода в секунду — в противном случае хранилище становится узким местом [6].

Андрей Кудрявцев (менеджер по продуктам DAOS в Intel) отмечает: «Google и Intel сотрудничают уже почти два года, чтобы упростить перенос рабочих нагрузок HPC в облако. Операторы связи ценят возможности хранения данных DAOS, потому что они расширяют их предложения услуг, обеспечивают высокую производительность в коммуникационных сетях Ethernet и, поскольку они работают в пользовательском пространстве, могут быть легко конвейеризированы. DAOS, естественно, поддерживает вариант использования облачного экземпляра, заключающийся в развертывании сервера хранения, выполнении быстрого ввода-вывода, а затем переносе данных на менее дорогой уровень хранения — вариант использования, который также становится все более распространенным в локальных центрах обработки данных.”

Производительность на узле и в распределенном кластере доказывает успех DAOS

Lustre является предпочтительным хранилищем для многих инсталляций высокопроизводительных вычислений (последний список SC22 IO500, ноябрь 2022 г. [https://io500.org/] говорит об обратном – на первом месте среди первых 28 самых высокопроизводительных компьютеров – DAOS с долей 46%, а Lustre занимает всего 7%, рис. 9а, прим. ред.). В 2022 году на ISC демонстрация Intel DAOS включала интеграцию TensorFlow для приложений ИИ. Результаты, представленные Intel (https://www.youtube.com/watch?v=TfJf0ayqNto), показывают, что DAOS превосходит Lustre при загрузке большого набора данных ИИ в TensorFlow в приложении Cosmoflow (рис. 10). При этом интеграция ввода-вывода DAOS и Tensorflow была достигнута полностью в пользовательском пространстве. Никаких модификаций ядра не потребовалось, что является преимуществом как для интернет-провайдеров, так и для локальных центров обработки данных.

Рис. 9а. Список IO500 SC22 (io500.org октябрь 2022 г.).

Рис. 10. Результаты сравнительного тестирования DAOS и Lustre на TensorFlow в приложении CosmoFlow [3].

В Кембриджском университете DAOS перешла из исследовательского проекта в открытой лаборатории Zettascale Кембриджского университета в производственную испытательную лабораторию на суперкомпьютере Cumulus, работающем в рамках University of Cambridge’s Service for Data Driven Discovery (CSD3, https://www.hpc.cam.ac.uk/high–performance–computing). Результаты, представленные на ISC’22, продемонстрировали преимущества DAOS по сравнению с Lustre в распределенной среде высокопроизводительных вычислений [7] (рис. 11).

Рис. 11. Производственная установка DAOS в Кембриджском университете. Сравнение производительности про водилось на одних и тех же узлах хранения, подробная конфигурация доступна на сайте io500.org.

Иван Поддубный (менеджер по разработке ПО, Intel): «Автоматизация очень важна для Google и подчеркивает преимущества их конвейера, а также простоту внедрения для пользователей. Пример использования Google демонстрирует успешное включение DAOS в набор инструментов HPC. Упрощенная установка DAOS облегчает перенос рабочих нагрузок HPC в облако и между локальными системами. DAOS — это то, что улучшает работу набора инструментов, обеспечивая производительность хранилища, необходимую для рабочих нагрузок HPC. Сотрудничество Google и Intel было разумным шагом обеих компаний, поскольку оно устраняет разрыв в производительности хранения — даже в средах облачных вычислений на основе TCP».

Изменения в программе DAOS!

Для тех пользователей, которые привержены Intel Optane Pmem, Intel по-прежнему планирует выпустить устройства Intel Optane Pmem следующего поколения под кодовым названием Crows Pass. Корпорация Intel стремится поддерживать клиентов и партнеров по экосистеме и будет продолжать оказывать поддержку существующим продуктам памяти и хранения данных до конца срока службы. Компания также будет поддерживать разработку Compute Express Link (CXL) для будущих процессоров и платформ, поскольку они считают, что это будет будущее и стандарт решений с многоуровневой памятью [6] (рис. 12).

Рис. 12. DAOS вводит два возможных направления развития: 1. Оставаться на Pmem с переходом на сторонние продукты энергонезависимой памяти CLX 2.0; Реализовать DRAM/CXL.mem 1.0 + NVMe Write Ahead Log для метаданных.

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

[1]  DAOS Momentum Demonstrated with New IO500 Rankings and Community DAOS Traction. 06-03-2022 – https://community.intel.com/t5/Blogs/Products-and-Solutions/HPC/DAOS-Momentum-Demonstrated-with-New-IO500-Rankings-and-Community/post/1389619.

[2]  DAOS 2.4 and beyond. Johann Lombardi, DAOS Chief Architect, Intel AXG. 02 Dec 2022, DUG22_Johann.pdf – https://daosio.atlassian.net/wiki/spaces/DC/pages/11248861216/DUG22.

[3]  DAOS Technical/Strategy Update. Johann Lombardi, Senior Principal Engineer, AXG, Intel. HPC User Forum, Paris, October 2022 – https://www.hpcuserforum.com/wp-content/uploads/2022/10/Intel-J.Lombardi.pdf.

[4]  Migration from Direct-Attached Intel^® Optane™ Persistent Memory to CXL™ — Attached Memory. Dec. 2022 – https://www.intel.com/content/dam/www/centrallibraries/us/en/documents/2022-11/optane-pmem-to-cxl-tech-brief.pdf.

[5]  DAOS Momentum Demonstrated with New IO500 Rankings and Community DAOS Traction. 06-03-2022 – https://community.intel.com/t5/Blogs/Products-and-Solutions/HPC/DAOS-Momentum-Demonstrated-with-New-IO500-Rankings-and-Community/post/1389619.

[6]  DAOS Performance Expands Beyond Intel Optane and Into the Google Cloud. By Rob Farber. October 17, 2022 – https://www.hpcwire.com/2022/10/17/daos-performance-expands-be-yond-intel-optane-and-into-the-google-cloud/.

[7]  DAOS Momentum Demonstrated with New IO500 Rankings and Community DAOS Traction. – https://community.intel.com/t5/Blogs/Products-and-Solutions/HPC/DAOS-Momentum-Demonstrated-with-New-IO500-Rankings-and-Community/post/1389619.

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

Отслеживать