Lustre: Параллельная файловая система для суперкомпьютеров

Введение

Параллельная распределенная файловая система

Lustre — это тип параллельной распределенной файловой системы, обычно используемый для крупномасштабных кластерных вычислений. Название Lustre образовано путем объединения слов Linux и cluster. Программное обеспечение файловой системы Lustre распространяется под лицензией GNU General Public License (только версия 2) и обеспечивает высокую производительность для компьютерных кластеров, начиная от небольших рабочих групп и заканчивая крупномасштабными многосайтовыми системами. С июня 2005 года Lustre постоянно используется как минимум половиной из десяти самых быстрых и более чем 60 из 100 самых быстрых суперкомпьютеров в мире, включая суперкомпьютер №1 в рейтинге TOP500 в ноябре 2022 года, Frontier, Titan и Sequoia. Файловые системы Lustre масштабируемы и могут быть частью нескольких компьютерных кластеров, состоящих из десятков тысяч клиентских узлов, сотен петабайт (PB) хранилища на сотнях серверов и пропускной способностью ввода-вывода до десятков терабайт в секунду (TB/с). Это делает файловые системы Lustre популярным выбором для компаний с крупными центрами обработки данных, в таких отраслях, как метеорология, моделирование, искусственный интеллект и машинное обучение, нефтегазовая промышленность, биологические науки, индустрия развлечений и финансы. Производительность ввода-вывода Lustre оказывает значительное влияние на эти приложения и привлекает широкое внимание.

История релизов

Файловая система Lustre была впервые установлена для производственного использования в марте 2003 года на кластере MCR Linux в Национальной лаборатории Лоуренса Ливермора, третьем по величине суперкомпьютере в списке Top500 на тот момент. Lustre 1.0.0 был выпущен в декабре 2003 года и обеспечивал основные функции файловой системы Lustre, включая отказ сервера и восстановление. Lustre 1.2.0, выпущенный в марте 2004 года, работал на Linux kernel 2.6 и имел функцию "предварительного просмотра размера", чтобы избежать отмены блокировки файлов, находящихся в процессе записи, а также ведение учёта кэша обратной записи данных на стороне клиента (grant). Lustre 1.4.0, выпущенный в ноябре 2004 года, обеспечивал совместимость протоколов между версиями, мог использовать сети InfiniBand и мог использовать расширения/mballoc в ldiskfs на дисковой файловой системе. Lustre 1.6.0, выпущенный в апреле 2007 года, позволил конфигурировать монтирование ("mountconf"), позволяя настраивать серверы с помощью "mkfs" и "mount", динамически добавлять объекты хранения (OST), масштабировать распределенный менеджер блокировок Lustre (LDLM) на серверах с симметричной многопроцессорной обработкой (SMP) и обеспечивал управление свободным пространством для выделения объектов. Lustre 1.8.0, выпущенный в мае 2009 года, обеспечивал OSS Read Cache, улучшил восстановление после множественных сбоев, добавил базовое управление неоднородным хранилищем через OST Pools, адаптивные сетевые тайм-ауты и восстановление на основе версий. Это был переходный релиз, совместимый как с Lustre 1.6, так и с Lustre 2.0. Lustre 2.0, выпущенный в августе 2010 года, был основан на значительной внутренней реструктуризации кода для подготовки к основным архитектурным улучшениям. Клиенты Lustre 2.x не могут взаимодействовать с серверами 1.8 или более ранними. Однако клиенты Lustre 1.8.6 и более поздних версий могут взаимодействовать с серверами Lustre 2.0 и более поздних версий. Формат дисковых метаданных (MDT) и OST версии 1.8 можно обновить до 2.0 и более поздних версий без необходимости переформатирования файловой системы. Lustre 2.1, выпущенный в сентябре 2011 года, был инициативой сообщества в ответ на приостановку разработки версий Lustre 2.x компанией Oracle. Он добавил возможность запуска серверов на Red Hat Linux 6 и увеличил максимальный размер OST на основе ext4 с 24 ТБ до 128 ТБ, а также ряд улучшений производительности и стабильности. Серверы Lustre 2.1 оставались совместимыми с клиентами 1.8.6 и более поздних версий. Lustre 2.2, выпущенный в марте 2012 года, был сосредоточен на улучшении производительности метаданных и добавлении новых функций. Он добавил параллельные операции с каталогами, позволяющие нескольким клиентам одновременно обходить и изменять один большой каталог, более быстрое восстановление после сбоев сервера, увеличение количества полос для одного файла (до 2000 OST) и улучшение производительности обхода каталогов одним клиентом. Lustre 2.3, выпущенный в октябре 2012 года, продолжил улучшать код сервера метаданных для устранения внутренних узких мест блокировки на узлах с большим количеством ядер CPU (более 16). В хранилище объектов была добавлена предварительная возможность использования ZFS в качестве базовой файловой системы. Функция Lustre File System ChecK (LFSCK) может проверять и восстанавливать индекс объектов MDS (OI) во время работы файловой системы, после резервного копирования/восстановления на уровне файлов или в случае повреждения MDS. Статистика ввода-вывода на стороне сервера была улучшена для интеграции с планировщиками пакетных заданий, таких как SLURM, для отслеживания статистики по заданиям. Клиентское программное обеспечение было обновлено для работы с ядрами Linux до версии 3.0. Lustre 2.4, выпущенный в мае 2013 года, добавил значительное количество основных функций, многие из которых финансировались непосредственно через OpenSFS. Распределенная среда пространства имен (Distributed Namespace Environment, DNE) позволяет горизонтально масштабировать метаданные и производительность для клиентов 2.4, позволяя размещать деревья подкаталогов одного пространства имен на отдельных MDT. ZFS теперь может использоваться в качестве базовой файловой системы как для MDT, так и для OST-хранилища. Функция LFSCK добавила возможность сканирования и проверки внутренней согласованности атрибутов MDT FID и LinkEA. Планировщик сетевых запросов (NRS) добавляет политики для оптимизации обработки клиентских запросов для упорядочивания диска или обеспечения справедливости. Клиенты могут отправлять необязательные RPC размером до 4 МБ. Клиентское программное обеспечение было обновлено для работы с ядрами Linux до версии 3.6 и остаётся совместимым с клиентами 1.8. Lustre 2.5, выпущенный в октябре 2013 года, добавил долгожданную функцию, иерархическое управление хранилищем (Hierarchical Storage Management, HSM). Являясь основным требованием в корпоративных средах, HSM позволяет клиентам легко внедрять многоуровневые решения для хранения данных в своей операционной среде. Этот релиз является текущей веткой Maintenance Release, обозначенной OpenSFS, для Lustre. Последняя версия обслуживания — 2.5.3, выпущенная в сентябре 2014 года. Lustre 2.6, выпущенный в июле 2014 года, был более скромным релизом с точки зрения функций, добавляя функциональность LFSCK для выполнения локальных проверок согласованности на OST, а также проверок согласованности между объектами MDT и OST. Была добавлена политика Token Bucket Filter (TBF) NRS. Производительность ввода-вывода одним клиентом была улучшена по сравнению с предыдущими релизами. Этот релиз также добавил предварительный просмотр полосатых каталогов DNE, позволяя хранить большие каталоги на нескольких MDT для повышения производительности и масштабируемости. Lustre 2.7, выпущенный в марте 2015 года, добавил функциональность LFSCK для проверки согласованности DNE удаленных и полосатых каталогов между несколькими MDT. Dynamic LNet Config добавляет возможность конфигурировать и изменять сетевые интерфейсы, маршруты и маршрутизаторы LNet во время выполнения. Была добавлена новая оценочная функция для сопоставления UID/GID для клиентов с разными административными доменами, а также улучшения функциональности полосатых каталогов DNE. Lustre 2.8, выпущенный в марте 2016 года, завершил функцию полосатых каталогов DNE, включая поддержку миграции каталогов между MDT, а также жесткие ссылки и переименование между MDT. Кроме того, он включал улучшенную поддержку Security Enhanced Linux (SELinux) на клиенте, аутентификацию Kerberos и шифрование RPC по сети, а также улучшения производительности для LFSCK. Lustre 2.9 был выпущен в декабре 2016 года и включал ряд функций, связанных с безопасностью и производительностью. Механизм безопасности Shared Secret Key использует тот же механизм GSSAPI, что и Kerberos, для обеспечения аутентификации узлов клиента и сервера, а также целостности и безопасности сообщений RPC (шифрования). Функция Nodemap позволяет категоризировать клиентские узлы в группы, а затем сопоставлять UID/GID для этих клиентов, позволяя удаленно администрируемым клиентам прозрачно использовать общую файловую систему без единого набора UID/GID для всех клиентских узлов. Функция монтирования подкаталогов позволяет клиентам монтировать подмножество пространства имен файловой системы из MDS. Этот релиз также добавил поддержку RPC размером до 16 МБ для более эффективной отправки ввода-вывода на диск и добавил интерфейс ladvise, позволяющий клиентам предоставлять серверу подсказки ввода-вывода для предварительной загрузки данных файлов в кэш сервера или очистки данных файлов из кэша сервера. Улучшена поддержка указания общесистемных пулов OST по умолчанию и улучшено наследование пулов OST в сочетании с другими параметрами макета файлов. Lustre 2.10 был выпущен в июле 2017 года и содержит ряд значительных улучшений. Функция LNet Multi Rail (LMR) позволяет объединять несколько сетевых интерфейсов (InfiniBand, Omni Path и/или Ethernet) на клиенте и сервере для увеличения общей пропускной способности ввода-вывода. Отдельные файлы могут использовать составные макеты файлов, которые строятся из нескольких компонентов, представляющих собой области файлов на основе смещения файла, которые позволяют использовать различные параметры макета, такие как количество полос, пул/тип хранилища OST и т. д. Progressive File Layout (PFL) является первой функцией, использующей составные макеты, но реализация является гибкой для использования с другими макетами файлов, такими как зеркалирование и кодирование стирания. Серверный планировщик Token Bucket Filter (TBF) NRS реализовал новые типы правил, включая планирование по типу RPC и возможность указать несколько параметров, таких как JobID и NID, для сопоставления правил. Были добавлены инструменты для управления снимками ZFS файловых систем Lustre, чтобы упростить создание, монтирование и управление снимками ZFS MDT и OST в качестве отдельных точек монтирования Lustre.

Lustre file system was first installed for production use in March 2003 on the MCR Linux Cluster at the Lawrence Livermore National Laboratory, the third largest supercomputer in the Top500 list at the time. Lustre 1.0.0 was released in December 2003, and provided basic Lustre filesystem functionality, including server failover and recovery. Lustre 1.2.0, released in March 2004, worked on Linux kernel 2.6, and had a "size glimpse" feature to avoid lock revocation on files undergoing write, and client side data write back cache accounting (grant). Lustre 1.4.0, released in November 2004, provided protocol compatibility between versions, could use InfiniBand networks, and could exploit extents/mballoc in the ldiskfs on disk filesystem. Lustre 1.6.0, released in April 2007, allowed mount configuration (“mountconf”) allowing servers to be configured with "mkfs" and "mount", allowed dynamic addition of object storage targets (OSTs), enabled Lustre distributed lock manager (LDLM) scalability on symmetric multiprocessing (SMP) servers, and provided free space management for object allocations. Lustre 1.8.0, released in May 2009, provided OSS Read Cache, improved recovery in the face of multiple failures, added basic heterogeneous storage management via OST Pools, adaptive network timeouts, and version based recovery. It was a transition release, being interoperable with both Lustre 1.6 and Lustre 2.0. Lustre 2.0, released in August 2010, was based on significant internally restructured code to prepare for major architectural advancements. Lustre 2. x clients cannot interoperate with 1.8 or earlier servers. However, Lustre 1.8.6 and later clients can interoperate with Lustre 2.0 and later servers. The Metadata Target (MDT) and OST on disk format from 1.8 can be upgraded to 2.0 and later without the need to reformat the filesystem. Lustre 2.1, released in September 2011, was a community wide initiative in response to Oracle suspending development on Lustre 2. x releases. It added the ability to run servers on Red Hat Linux 6 and increased the maximum ext4 based OST size from 24 TB to 128 TB, as well as a number of performance and stability improvements. Lustre 2.1 servers remained inter operable with 1.8.6 and later clients. Lustre 2.2, released in March 2012, focused on providing metadata performance improvements and new features. It added parallel directory operations allowing multiple clients to traverse and modify a single large directory concurrently, faster recovery from server failures, increased stripe counts for a single file (across up to 2000 OSTs), and improved single client directory traversal performance. Lustre 2.3, released in October 2012, continued to improve the metadata server code to remove internal locking bottlenecks on nodes with many CPU cores (over 16). The object store added a preliminary ability to use ZFS as the backing file system. The Lustre File System ChecK (LFSCK) feature can verify and repair the MDS Object Index (OI) while the file system is in use, after a file level backup/restore or in case of MDS corruption. The server side IO statistics were enhanced to allow integration with batch job schedulers such as SLURM to track per job statistics. Client side software was updated to work with Linux kernels up to version 3.0. Lustre 2.4, released in May 2013, added a considerable number of major features, many funded directly through OpenSFS. Distributed Namespace Environment (DNE) allows horizontal metadata capacity and performance scaling for 2.4 clients, by allowing subdirectory trees of a single namespace to be located on separate MDTs. ZFS can now be used as the backing filesystem for both MDT and OST storage. The LFSCK feature added the ability to scan and verify the internal consistency of the MDT FID and LinkEA attributes. The Network Request Scheduler

(NRS) adds policies to optimize client request processing for disk ordering or fairness. Clients can optionally send bulk RPCs up to 4 MB in size. Client side software was updated to work with Linux kernels up to version 3.6, and is still interoperable with 1.8 clients. Lustre 2.5, released in October 2013, added the highly anticipated feature, Hierarchical Storage Management (HSM). A core requirement in enterprise environments, HSM allows customers to easily implement tiered storage solutions in their operational environment. This release is the current OpenSFS designated Maintenance Release branch of Lustre. The most recent maintenance version is 2.5.3 and was released in September 2014. Lustre 2.6, released in July 2014, was a more modest release feature wise, adding LFSCK functionality to do local consistency checks on the OST as well as consistency checks between MDT and OST objects. The NRS Token Bucket Filter
(TBF) policy was added. Single client IO performance was improved over the previous releases. This release also added a preview of DNE striped directories, allowing single large directories to be stored on multiple MDTs to improve performance and scalability. Lustre 2.7, released in March 2015, added LFSCK functionality to verify DNE consistency of remote and striped directories between multiple MDTs. Dynamic LNet Config adds the ability to configure and modify LNet network interfaces, routes, and routers at runtime. A new evaluation feature was added for UID/GID mapping for clients with different administrative domains, along with improvements to the DNE striped directory functionality. Lustre 2.8, released in March 2016, finished the DNE striped directory feature, including support for migrating directories between MDTs, and cross MDT hard link and rename. As well, it included improved support for Security Enhanced Linux (SELinux) on the client, Kerberos authentication and RPC encryption over the network, and performance improvements for LFSCK. Lustre 2.9 was released in December 2016
and included a number of features related to security and performance. The Shared Secret Key security flavour uses the same GSSAPI mechanism as Kerberos to provide client and server node authentication, and RPC message integrity and security (encryption). The Nodemap feature allows categorizing client nodes into groups and then mapping the UID/GID for those clients, allowing remotely administered clients to transparently use a shared filesystem without having a single set of UID/GIDs for all client nodes. The subdirectory mount feature allows clients to mount a subset of the filesystem namespace from the MDS. This release also added support for up to 16 MiB RPCs for more efficient I/O submission to disk, and added the ladvise interface to allow clients to provide I/O hints to the servers to prefetch file data into server cache or flush file data from server cache. There was improved support for specifying filesystem wide default OST pools, and improved inheritance of OST pools in conjunction with other file layout parameters. Lustre 2.10 was released in July 2017
and has a number of significant improvements. The LNet Multi Rail (LMR) feature allows bonding multiple network interfaces (InfiniBand, Omni Path, and/or Ethernet) on a client and server to increase aggregate I/O bandwidth. Individual files can use composite file layouts that are constructed of multiple components, which are file regions based on the file offset, that allow different layout parameters such as stripe count, OST pool/storage type, etc. Progressive File Layout (PFL) is the first feature to use composite layouts, but the implementation is flexible for use with other file layouts such as mirroring and erasure coding. The NRS Token Bucket Filter (TBF) server side scheduler has implemented new rule types, including RPC type scheduling and the ability to specify multiple parameters such as JobID and NID for rule matching. Tools for managing ZFS snapshots of Lustre filesystems have been added, to simplify the creation, mounting, and management of MDT and OST ZFS snapshots as separate Lustre mountpoints. Lustre 2.11 was released in April 2018
and contains two significant new features, and several smaller features. The File Level Redundancy (FLR) feature expands on the 2.10 PFL implementation, adding the ability to specify mirrored file layouts for improved availability in case of storage or server failure and/or improved performance with highly concurrent reads. The Data on MDT (DoM) feature allows small (few MiB) files to be stored on the MDT to leverage typical flash based RAID 10 storage for lower latency and reduced IO contention, instead of the typical HDD RAID 6 storage used on OSTs. As well, the LNet Dynamic Discovery feature allows auto configuration of LNet Multi Rail between peers that share an LNet network. The LDLM Lock Ahead feature allows appropriately modified applications and libraries to pre fetch DLM extent locks from the OSTs for files, if the application knows (or predicts) that this file extent will be modified in the near future, which can reduce lock contention for multiple clients writing to the same file. Lustre 2.12 was released on December 21, 2018 and focused on improving Lustre usability and stability, with improvements the performance and functionality of the FLR and DoM features added in Lustre 2.11, as well as smaller changes to NRS TBF, HSM, and JobStats. It added LNet Network Health to allow the LNet Multi Rail feature from Lustre 2.10 to better handle network faults when a node has multiple network interfaces. The Lazy Size on MDT (LSOM) feature allows storing an estimate of the file size on the MDT for use by policy engines, filesystem scanners, and other management tools that can more efficiently make decisions about files without a fully accurate file sizes or blocks count without having to query the OSTs for this information. This release also added the ability to manually restripe an existing directory across multiple MDTs, to allow migration of directories with large numbers of files to use the capacity and performance of several MDS nodes. The Lustre RPC data checksum added SCSI T10 PI integrated data checksums from the client to the kernel block layer, SCSI host adapter, and T10 enabled hard drives. Lustre 2.13 was released on December 5, 2019 and added a new performance related features Persistent Client Cache (PCC), which allows direct use of NVMe and NVRAM storage on the client nodes while keeping the files part of the global filesystem namespace, and OST Overstriping which allows files to store multiple stripes on a single OST to better utilize fast OSS hardware. As well, the LNet Multi Rail Network Health functionality was improved to work with LNet RDMA router nodes. The PFL functionality was enhanced with Self Extending Layouts (SEL) to allow file components to be dynamically sized, to better deal with flash OSTs that may be much smaller than disk OSTs within the same filesystem. The release also included a number of smaller improvements, such as balancing DNE remote directory creation across MDTs, using Lazy size on MDT to reduce the overhead of "lfs find", directories with 10M files per shard for ldiskfs, and bulk RPC sizes up to 64 MB. Lustre 2.14 was released on February 19, 2021 and includes three main features. Client Data Encryption implements fscrypt to allow file data to be encrypted on the client before network transfer and persistent storage on the OST and MDT. OST Pool Quotas extends the quota framework to allow the assignment and enforcement of quotas on the basis of OST storage pools. DNE Auto Restriping can now adjust how many MDTs a large directory is striped over based on size thresholds defined by the administrator, similar to Progressive File Layouts for directories. Lustre 2.15 was released on June 16, 2022 and includes three main features. Client Directory Encryption
expands on the fscrypt data encryption in the 2.14 release to also allow file and directory names to be encrypted on the client before network transfer and persistent storage on the MDT. DNE MDT space balancing automatically balances new directory creation across MDTs in the filesystem in round robin and/or based on available inodes and space, which in turn helps distribute client metadata workload over MDTs more evenly. For applications using the NVIDIA GPU Direct Storage interface (GDS),
the Lustre client can do zero copy RDMA read and write from the storage server directly into the GPU memory to avoid an extra data copy from CPU memory and extra processing overhead. User Defined Selection Policy (UDSP) allows setting interface selection policies for nodes with multiple network interfaces.

Реализация

В типичной установке Lustre на клиенте Linux в ядро загружается модуль драйвера файловой системы Lustre, и файловая система монтируется как любая другая локальная или сетевая файловая система. Клиентские приложения видят единую, унифицированную файловую систему, даже если она может состоять из десятков или тысяч отдельных серверов и файловых систем MDT/OST. На некоторых установках с массивно-параллельными процессорами (MPP) вычислительные процессоры могут получить доступ к файловой системе Lustre, перенаправляя свои запросы ввода-вывода на выделенный узел ввода-вывода, сконфигурированный как клиент Lustre. Этот подход используется в установке Blue Gene в Национальной лаборатории Лоуренса Ливермора. Другой подход, использовавшийся в первые годы существования Lustre, – это библиотека liblustre на Cray XT3, использующая операционную систему Catamount на таких системах, как Sandia Red Storm, которая предоставляла приложениям, работающим в пользовательском пространстве, прямой доступ к файловой системе. Liblustre была библиотекой пользовательского уровня, позволявшей вычислительным процессорам монтировать и использовать файловую систему Lustre как клиент. С помощью liblustre вычислительные процессоры могли получить доступ к файловой системе Lustre, даже если сервисный узел, на котором выполнялась задача, не являлся клиентом Linux. Liblustre обеспечивала передачу данных непосредственно между адресным пространством приложений и Lustre OSS без необходимости промежуточного копирования данных через ядро, тем самым предоставляя вычислительным процессорам прямой доступ к файловой системе Lustre в ограниченной операционной среде. Функциональность liblustre была удалена из Lustre 2.7.0 после отключения, начиная с Lustre 2.6.0, и не тестировалась с Lustre 2.3.0. В версии Linux Kernel 4.18 незавершенный порт клиента Lustre был удален из области тестирования ядра для ускорения разработки и портирования на новые ядра. Клиент и сервер Lustre, находящиеся вне дерева исходного кода, по-прежнему доступны для ядер RHEL, SLES и Ubuntu, а также для ванильных ядер.

Объекты данных и стриптиз файлов

В традиционной дисковой файловой системе Unix структура данных inode содержит основную информацию о каждом файле, например, место хранения данных в файле. Файловая система Lustre также использует иноды, но иноды на MDT указывают на один или несколько объектов OST, связанных с файлом, а не на блоки данных. Эти объекты реализованы как файлы на OST. Когда клиент открывает файл, операция открытия файла передает набор идентификаторов объектов и их схему из MDS клиенту, чтобы клиент мог напрямую взаимодействовать с узлом OSS, хранящим объекты. Это позволяет клиентам выполнять операции ввода-вывода параллельно по всем объектам OST в файле без дальнейшего обращения к MDS, избегая блокировок, связанных с централизованным управлением блоками и блокировками. Если к иноду MDT привязан только один объект OST, этот объект содержит все данные файла Lustre. Если к файлу привязано несколько объектов, данные в файле разбиваются на фрагменты и распределяются по объектам OST циклически, подобно RAID 0, с размером фрагментов обычно 1 МБ или больше. Разбиение файла по нескольким объектам OST обеспечивает значительное повышение производительности при необходимости высокой пропускной способности доступа к одному большому файлу. При использовании разбиения максимальный размер файла не ограничивается размером одного целевого объекта. Вместимость и общая пропускная способность ввода-вывода масштабируются с количеством OST, по которым распределен файл. Кроме того, поскольку блокировка каждого объекта управляется независимо для каждого OST, увеличение количества фрагментов (по одному на каждый OST) пропорционально увеличивает пропускную способность блокировки ввода-вывода файла. Каждый файл, созданный в файловой системе, может указывать различные параметры схемы, такие как количество фрагментов (число объектов OST, составляющих файл), размер фрагмента (объем данных, хранящихся на каждом OST перед переходом к следующему) и выбор OST, чтобы оптимально настроить производительность и емкость для каждого файла. Если множество потоков приложений параллельно читают или записывают отдельные файлы, оптимально использовать один фрагмент на файл, поскольку приложение обеспечивает свой собственный параллелизм. Если множество потоков одновременно читают или записывают один большой файл, то оптимально иметь как минимум один фрагмент на каждом OST для максимальной производительности и емкости этого файла. В версии Lustre 2.10 добавлена возможность указания составных схем, позволяющая файлам иметь разные параметры схемы для разных областей файла. Функция Progressive File Layout (PFL) использует составные схемы для повышения производительности операций ввода-вывода с файлами в более широком диапазоне рабочих нагрузок, а также упрощает использование и администрирование. Например, небольшой файл PFL может иметь один фрагмент на флэш-памяти для минимизации накладных расходов на доступ, в то время как большие файлы могут иметь множество фрагментов для высокой общей пропускной способности и лучшего балансирования нагрузки на OST. Составные схемы были дополнительно улучшены в версии 2.11 с помощью функции File Level Redundancy (FLR), которая позволяет файлу иметь несколько перекрывающихся схем, обеспечивая избыточность RAID 0+1 для этих файлов, а также повышая производительность чтения. В версии Lustre 2.11 также добавлена функция Data on Metadata (DoM), которая позволяет хранить первый компонент файла PFL непосредственно на MDT вместе с инодом. Это снижает накладные расходы на доступ к небольшим файлам как с точки зрения использования пространства (не требуется объект OST), так и использования сети (требуется меньше RPC для доступа к данным). DoM также повышает производительность для небольших файлов, если MDT основан на SSD, а OST — на диске. В Lustre 2.13 функция OST Overstriping позволяет одному компоненту иметь несколько фрагментов на одном OST для дальнейшего повышения параллелизма блокировки, а функция Self Extending Layout позволяет динамически изменять размер компонента во время записи, чтобы он мог справиться с нехваткой места на отдельных (флэш) OST до того, как вся файловая система заполнится.

In a traditional Unix disk file system, an inode data structure contains basic information about each file, such as where the data contained in the file is stored. The Lustre file system also uses inodes, but inodes on MDTs point to one or more OST objects associated with the file rather than to data blocks. These objects are implemented as files on the OSTs. When a client opens a file, the file open operation transfers a set of object identifiers and their layout from the MDS to the client, so that the client can directly interact with the OSS node(s) that hold the object(s). This allows the client(s) to perform I/O in parallel across all of the OST objects in the file without further communication with the MDS, avoiding contention from centralized block and lock management. If only one OST object is associated with an MDT inode, that object contains all the data in the Lustre file. When more than one object is associated with a file, data in the file is "striped" in chunks in a round robin manner across the OST objects similar to RAID 0 in chunks typically 1 MB or larger. Striping a file over multiple OST objects provides significant performance benefits if there is a need for high bandwidth access to a single large file. When striping is used, the maximum file size is not limited by the size of a single target. Capacity and aggregate I/O bandwidth scale with the number of OSTs a file is striped over. Also, since the locking of each object is managed independently for each OST, adding more stripes (one per OST) scales the file I/O locking capacity of the file proportionately. Each file created in the filesystem may specify different layout parameters, such as the stripe count (number of OST objects making up that file), stripe size (unit of data stored on each OST before moving to the next), and OST selection, so that performance and capacity can be tuned optimally for each file. When many application threads are reading or writing to separate files in parallel, it is optimal to have a single stripe per file, since the application is providing its own parallelism. When there are many threads reading or writing a single large file concurrently, then it is optimal to have at least one stripe on each OST to maximize the performance and capacity of that file. In the Lustre 2.10 release, the ability to specify composite layouts was added to allow files to have different layout parameters for different regions of the file. The Progressive File Layout (PFL) feature uses composite layouts to improve file IO performance over a wider range of workloads, as well as simplify usage and administration. For example, a small PFL file can have a single stripe on flash for low access overhead, while larger files can have many stripes for high aggregate bandwidth and better OST load balancing. The composite layouts are further enhanced in the 2.11 release with the File Level Redundancy (FLR) feature, which allows a file to have multiple overlapping layouts for a file, providing RAID 0+1 redundancy for these files as well as improved read performance. The Lustre 2.11 release also added the Data on Metadata (DoM) feature, which allows the first component of a PFL file to be stored directly on the MDT with the inode. This reduces overhead for accessing small files, both in terms of space usage (no OST object is needed) as well as network usage (fewer RPCs needed to access the data). DoM also improves performance for small files if the MDT is SSD based, while the OSTs are disk based. In Lustre 2.13 the OST Overstriping feature allows a single component to have multiple stripes on one OST to further improve parallelism of locking, while the Self Extending Layout feature allows the component size to be dynamic during write so that it can cope with individual (flash) OSTs running out of space before the whole filesystem is out of space.

Объекты метаданных и удаленные или полосатые каталоги DNE

Когда клиент первоначально монтирует файловую систему, ему предоставляется 128-битный идентификатор файла Lustre (FID, состоящий из 64-битного номера последовательности, 32-битного идентификатора объекта и 32-битной версии) корневого каталога для точки монтирования. При поиске имени файла клиент выполняет поиск каждого компонента пути, сопоставляя номер последовательности FID родительской директории с конкретным MDT через базу данных местоположений FID (FLDB), а затем выполняет поиск в MDS, управляющем этим MDT, используя родительский FID и имя файла. MDS возвращает FID запрошенного компонента пути вместе с блокировкой DLM. После определения MDT последнего каталога в пути, дальнейшие операции с каталогами (для неполосатых каталогов) обычно выполняются на этом MDT, что позволяет избежать конкуренции между MDT. Для полосатых каталогов DNE, схема размещения каталога, хранящаяся в родительской директории, предоставляет хеш-функцию и список FID каталогов MDT, по которым каталог распределен. Логический том метаданных (LMV) на клиенте хеширует имя файла и сопоставляет его с конкретным фрагментом каталога MDT, который обрабатывает дальнейшие операции с этим файлом аналогично неполосатому каталогу. Для операций readdir записи из каждого фрагмента каталога возвращаются клиенту, отсортированные в порядке хеширования локального каталога MDT, и клиент выполняет сортировку слиянием для упорядочивания имен файлов в порядке хеширования, чтобы можно было использовать один 64-битный cookie для определения текущего смещения в каталоге. В Lustre 2.15 клиент LMV реализует схемы размещения каталогов по умолчанию с круговым и сбалансированным использованием пространства, что позволяет клиентам более эффективно использовать большое количество MDT в одной файловой системе. Когда новый подкаталог создается вблизи корня файловой системы (по умолчанию первые 3 уровня каталога), он автоматически создается как удаленный каталог на одном из доступных MDT (выбираемых последовательно), чтобы сбалансировать использование пространства и нагрузку на серверы. Если свободное пространство на MDT становится несбалансированным (разница в свободном пространстве и inode превышает 5%), клиенты будут отдавать предпочтение созданию новых подкаталогов на MDT с большим объемом свободного пространства, чтобы восстановить баланс.

When a client initially mounts a filesystem, it is provided the 128 bit Lustre File Identifier (FID, composed of the 64 bit Sequence number, 32 bit Object ID, and 32 bit Version) of the root directory for the mountpoint. When doing a filename lookup, the client performs a lookup of each pathname component by mapping the parent directory FID Sequence number to a specific MDT via the FID Location Database (FLDB), and then does a lookup on the MDS managing this MDT using the parent FID and filename. The MDS will return the FID for the requested pathname component along with a DLM lock. Once the MDT of the last directory in the path is determined, further directory operations (for non striped directories) will normally take place on that MDT, avoiding contention between MDTs. For DNE striped directories, the per directory layout stored on the parent directory provides a hash function and a list of MDT directory FIDs across which the directory is distributed. The Logical Metadata Volume (LMV) on the client hashes the filename and maps it to a specific MDT directory shard, which will handle further operations on that file in an identical manner to a non striped directory. For readdir operations, the entries from each directory shard are returned to the client sorted in the local MDT directory hash order, and the client performs a merge sort to interleave the filenames in hash order so that a single 64 bit cookie can be used to determine the current offset within the directory. In Lustre 2.15, the client LMV implements round robin and space balanced default directory layouts, so that clients can use a large number of MDTs in a single filesystem more effectively. When a new subdirectories is created near the root of the filesystem (the top 3 directory levels by default), it will automatically be created as a remote directory one of the available MDTs (selected in sequential order) to balance space usage and load across servers. If the free space on the MDTs becomes imbalanced (more than 5% difference in free space and inodes) then the clients will bias new subdirectory creation toward MDTs with more free space in order to restore balance.

Закрытие

Распределенный менеджер блокировок Lustre (LDLM), реализованный в стиле OpenVMS, защищает целостность данных и метаданных каждого файла. Доступ и изменение файла Lustre полностью когерентны между всеми клиентами. Метаданные блокируются MDT, который хранит inode для файла, используя FID в качестве имени ресурса. Блокировка метаданных разделена на отдельные биты, которые защищают поиск файла (владелец и группа файла, разрешения и режим, а также список контроля доступа (ACL)), состояние inode (размер каталога, содержимое каталога, количество ссылок, временные метки), структуру (полоса файла, начиная с Lustre 2.4) и расширенные атрибуты (xattrs, начиная с Lustre 2.5). Клиент может запросить несколько битов блокировки метаданных для одного inode в рамках одного RPC-запроса, но в настоящее время ему предоставляется только блокировка чтения для inode. MDS управляет всеми изменениями inode, чтобы избежать конфликтов при использовании блокировок, и в настоящее время является единственным узлом, получающим блокировки записи на inode. Блокировка данных файла управляется OST, на котором размещен каждый объект файла, с использованием блокировок по диапазону байтов. Клиентам могут быть предоставлены перекрывающиеся блокировки чтения по диапазону для части или всего файла, что позволяет нескольким клиентам одновременно читать один и тот же файл, и/или неперекрывающиеся блокировки записи по диапазону для независимых областей файла. Это позволяет многим клиентам Lustre одновременно получать доступ к одному файлу для чтения и записи, избегая узких мест при операциях ввода-вывода. На практике, поскольку клиенты Linux управляют своим кэшем данных страницами, клиенты запрашивают блокировки, которые всегда являются целым кратным размера страницы (4096 байт на большинстве клиентов). Когда клиент запрашивает блокировку по диапазону, OST может предоставить блокировку для большего диапазона, чем было запрошено, чтобы уменьшить количество запросов блокировки от клиента. Фактический размер предоставленной блокировки зависит от нескольких факторов, включая количество в настоящее время предоставленных блокировок для этого объекта, наличие конфликтующих блокировок записи для запрошенного диапазона и количество ожидающих запросов блокировки для этого объекта. Предоставленная блокировка никогда не меньше первоначально запрошенного диапазона. Блокировки OST используют Lustre FID объекта в качестве имени ресурса для блокировки. Поскольку количество серверов блокировки по диапазону масштабируется вместе с количеством OST в файловой системе, это также масштабирует общую производительность блокировки файловой системы и отдельного файла, если он распределен по нескольким OST.

The Lustre distributed lock manager (LDLM), implemented in the OpenVMS style, protects the integrity of each file's data and metadata. Access and modification of a Lustre file is completely cache coherent among all of the clients. Metadata locks are managed by the MDT that stores the inode for the file, using FID as the resource name. The metadata locks are split into separate bits that protect the lookup of the file (file owner and group, permission and mode, and access control list (ACL)), the state of the inode (directory size, directory contents, link count, timestamps), layout (file striping, since Lustre 2.4), and extended attributes (xattrs, since Lustre 2.5). A client can fetch multiple metadata lock bits for a single inode with a single RPC request, but currently they are only ever granted a read lock for the inode. The MDS manages all modifications to the inode in order to avoid lock resource contention and is currently the only node that gets write locks on inodes. File data locks are managed by the OST on which each object of the file is striped, using byte range extent locks. Clients can be granted overlapping read extent locks for part or all of the file, allowing multiple concurrent readers of the same file, and/or non overlapping write extent locks for independent regions of the file. This allows many Lustre clients to access a single file concurrently for both read and write, avoiding bottlenecks during file I/O. In practice, because Linux clients manage their data cache in units of pages, the clients will request locks that are always an integer multiple of the page size (4096 bytes on most clients). When a client is requesting an extent lock the OST may grant a lock for a larger extent than originally requested, in order to reduce the number of lock requests that the client makes. The actual size of the granted lock depends on several factors, including the number of currently granted locks on that object, whether there are conflicting write locks for the requested lock extent, and the number of pending lock requests on that object. The granted lock is never smaller than the originally requested extent. OST extent locks use the Lustre FID of the object as the resource name for the lock. Since the number of extent lock servers scales with the number of OSTs in the filesystem, this also scales the aggregate locking performance of the filesystem, and of a single file if it is striped over multiple OSTs.

Сетевые связи

Связь между клиентами и серверами Lustre реализована с использованием Lustre Networking (LNet), изначально основанной на сетевом прикладном программном интерфейсе Sandia Portals. Дисковое хранилище подключается к узлам серверов Lustre MDS и OSS с использованием прямого подключения (SAS, FC, iSCSI) или традиционных технологий сети хранения данных (SAN), что не зависит от клиентской и серверной сети. LNet может использовать множество распространенных типов сетей, таких как InfiniBand и TCP (обычно Ethernet), и обеспечивает одновременную доступность по нескольким типам сетей с маршрутизацией между ними. Удаленный прямой доступ к памяти (RDMA) используется для передачи данных и метаданных между узлами, когда это поддерживается базовыми сетями, такими как InfiniBand, RoCE, iWARP и Omni Path, а также проприетарными высокоскоростными сетями, такими как Cray Aries и Gemini, и Atos BXI. Функции высокой доступности и восстановления обеспечивают прозрачное восстановление в сочетании с серверами резервирования. Начиная с Lustre 2.10, функция LNet Multi Rail (MR) позволяет агрегировать каналы двух или более сетевых интерфейсов между клиентом и сервером для повышения пропускной способности. Типы интерфейсов LNet не обязательно должны быть одного типа сети. В версии 2.12 Multi Rail была улучшена для повышения устойчивости к сбоям при наличии нескольких сетевых интерфейсов между узлами. LNet обеспечивает сквозную пропускную способность в сетях Gigabit Ethernet более 100 МБ/с, до 11 ГБ/с при использовании каналов InfiniBand с расширенной скоростью передачи данных (EDR) и более 11 ГБ/с через интерфейсы 100 Gigabit Ethernet.

Высокая доступность

Файловая система Lustre обладает надежными функциями обеспечения высокой доступности, включая отказоустойчивый механизм переключения и восстановления, что делает сбои серверов и перезагрузки прозрачными. Совместимость версий между последовательными минорными версиями программного обеспечения Lustre позволяет обновлять сервер, выводя его из эксплуатации (или переключая на резервный сервер), выполняя обновление и перезапуская его, в то время как все активные задания продолжают выполняться, испытывая лишь кратковременную задержку во время передачи обслуживания резервному серверу. Lustre MDS настроены как активная/пассивная пара, экспортирующая один MDT, или как одна или несколько активных/активных пар MDS с DNE, экспортирующих два или более отдельных MDT, в то время как OSS обычно развертываются в активной/активной конфигурации, экспортируя отдельные OST для обеспечения избыточности без дополнительной системной нагрузки. В файловых системах с одним MDT, резервный MDS для одной файловой системы является узлом MGS и/или мониторинга, либо активным MDS для другой файловой системы, что обеспечивает отсутствие простаивающих узлов в кластере.

Развертывание

Lustre используется многими суперкомпьютерами из списка TOP500 и крупными многокластерными вычислительными комплексами. Шесть из десяти и более шестидесяти из ста лучших суперкомпьютеров используют файловые системы Lustre. Среди них — файловая система Orion объемом 700 ПБ и пропускной способностью 13 ТБ/с для суперкомпьютера Frontier в Национальной лаборатории Оук-Ридж (ORNL), суперкомпьютеры Fugaku и K Computer, NASA в Северной Америке, Токийский технологический институт в Азии, CEA в Европе и многие другие.

Коммерческая техническая поддержка

Коммерческая техническая поддержка Lustre часто поставляется в комплекте с вычислительной системой или аппаратным обеспечением для хранения данных, продаваемым поставщиком. Некоторые поставщики, такие как Hewlett Packard (в виде HP StorageWorks Scalable File Share, примерно с 2004 по 2008 год), ATOS и Fujitsu, предлагают такую поддержку. Поставщики, продающие аппаратное обеспечение для хранения данных с предустановленной поддержкой Lustre, включают Hitachi Data Systems (2012), DataDirect Networks (DDN), Aeon Computing и другие компании. Также возможно приобрести только программную поддержку файловых систем Lustre у некоторых поставщиков, включая Whamcloud. Amazon Web Services предлагает Amazon FSx for Lustre – полностью управляемый сервис, который позволяет легко и экономично запускать и использовать высокопроизводительные файловые системы в их облаке.