Параллельдік таратылған файлдық жүйе: Lustre туралы

Кіріспе

Параллельді үлестірілген файл жүйесі

Lustre – параллельді үлестірілген файл жүйесінің бір түрі, көбінесе ірі масштабты кластерлік есептеулер үшін қолданылады. Lustre атауы Linux және кластер сөздерінің қосылуынан пайда болған. Lustre файлдық жүйе бағдарламалық жасақтамасы GNU General Public License (тек 2-ші нұсқасы) лицензиясы бойынша қолжетімді және кішкентай жұмыс тобы кластерлерінен бастап, үлкен масштабты, көп орынды жүйелерге дейінгі компьютер кластерлері үшін жоғары өнімділікке ие файлдық жүйелерді ұсынады. 2005 жылдың маусым айынан бері Lustre әлемдегі ең жылдам суперкомпьютерлердің кемінде жартысы және 100-ге жуық ең жылдам суперкомпьютерлердің 60-тан астамында тұрақты түрде қолданылып келеді, оның ішінде 2022 жылдың қараша айындағы TOP500 тізіміндегі бірінші орындағы Frontier, Titan және Sequoia суперкомпьютерлері де бар. Lustre файлдық жүйелері кеңейтілуге қабілетті және ондаған мың клиенттік түйіндері, жүздеген серверде жүздеген петабайт (PB) сақтау көлемі және секундтық ондаған терабайт (TB/с) жиынтық I/O өткізу қабілеті бар бірнеше компьютер кластерлерінің құрамына кіре алады. Бұл Lustre файлдық жүйелерін ірі деректер орталықтарына ие компаниялар үшін танымал таңдауға айналдырады, олар метеорология, модельдеу, жасанды интеллект және машиналық оқыту, мұнай және газ, өмір ғылымдары, мультимедиа және қаржы сияқты салаларды қамтиды. Lustre-дің I/O өнімділігі осы қолданбаларға кеңінен әсер етеді және көптеген мамандардың назарына ілігеді.

Шығару тарихы

Lustre файлдық жүйесі алғаш рет 2003 жылдың наурыз айында Лоуренс Ливермор ұлттық зертханасындағы MCR Linux кластерінде пайдалануға орнатылды, ол сол кезде Top500 тізіміндегі үшінші ірі суперкомпьютер болды. Lustre 1.0.0 2003 жылдың желтоқсанында жарық көрді және Lustre файлдық жүйесінің негізгі функционалдығын, соның ішінде сервердің істен шығуын және қалпына келтіруін қамтамасыз етті. 2004 жылдың наурыз айында шыққан Lustre 1.2.0 Linux ядросы 2.6-мен жұмыс істеді және жазу кезінде файлдардағы құлыптауларды болдырмау үшін "өлшемді көру" мүмкіндігіне ие болды, сондай-ақ клиенттік жақтан деректерді кэш-есепке (grant) қайта жазу мүмкіндігі болды. 2004 жылдың қарашасында шыққан Lustre 1.4.0 нұсқалары арасында протокол үйлесімділігі қамтамасыз етілді, InfiniBand желілерін қолдануға және дискідегі ldiskfs файлдық жүйесінде extents/mballoc пайдалануға мүмкіндік берді. 2007 жылдың сәуірінде шыққан Lustre 1.6.0 серверлерді "mkfs" және "mount" командаларымен конфигурациялауға мүмкіндік беретін монтаждау конфигурациясын (mountconf) енгізді, объект сақтау мақсаттарын (OST) динамикалық түрде қосуға, Lustre үлестірілген құлыптау басқарушысының (LDLM) симметриялық көппроцессорлық (SMP) серверлердегі кеңейтімділігін қамтамасыз етті және объекттарды бөлу үшін бос орынды басқаруды ұсынды. 2009 жылдың мамырында шыққан Lustre 1.8.0 OSS Read Cache-ті қамтамасыз етті, бірнеше сәтсіздік жағдайында қалпына келтіруді жақсартты, OST Pool арқылы гетерогенді сақтауды басқарудың негізгі мүмкіндіктерін қосты, желілік уақыт кешігуін бейімдеуге және нұсқаға негізделген қалпына келтіруге мүмкіндік берді. Бұл Lustre 1.6 және Lustre 2.0 екеуімен де өзара әрекеттесетін көшкінші релиз болды. 2010 жылдың тамызында шыққан Lustre 2.0 маңызды архитектуралық жетістіктерге дайындық үшін ішкі құрылымын толығымен өзгертіп жаңартқан кодқа негізделді. Lustre 2.x клиенттері 1.8 және одан ертерек нұсқадағы серверлермен өзара әрекеттесе алмайды. Дегенмен, Lustre 1.8.6 және одан кейінгі клиенттер Lustre 2.0 және одан кейінгі серверлермен өзара жұмыс істей алады. Метадеректер мақсаты (MDT) және OST дискідегі форматы 1.8 нұсқасынан 2.0 және одан кейінгі нұсқаларға файлдық жүйені қайта форматтау қажеттілігінсіз жаңартуға болады. 2011 жылдың қыркүйегінде шыққан Lustre 2.1 – Lustre 2.x нұсқасының дамуын тоқтатқан Oracle компаниясына жауап ретінде бүкіл қауымдастықтың бастамасы болды. Ол Red Hat Linux 6 серверлерін іске қосу мүмкіндігін қосты және ext4 негізіндегі OST-нің максималды көлемін 24 ТБ-тан 128 ТБ-ға дейін арттырды, сондай-ақ өнімділік пен тұрақтылықты жақсартулар енгізді. Lustre 2.1 серверлері 1.8.6 және одан кейінгі клиенттермен өзара әрекеттеседі. 2012 жылдың наурыз айында шыққан Lustre 2.2 метадеректердің өнімділігін жақсартуға және жаңа мүмкіндіктерді ұсынуға бағытталды. Ол бірнеше клиенттерге бір үлкен каталогты бір мезгілде қарауға және өзгертуге мүмкіндік беретін параллель каталог операцияларын қосты, сервердің істен шығуынан жылдам қалпына келтіруді қамтамасыз етті, бір файл үшін жолақтың санын арттырды (2000 OST-ге дейін) және бір клиенттің каталогты қарау өнімділігін жақсартты. 2012 жылдың қазан айында шыққан Lustre 2.3 көп ядролы процессорлары бар (16-дан астам) түйіндердегі ішкі құлыптаудың шектеулерін жою үшін метадеректер серверінің кодын жақсартуды жалғастырды. Объект сақтағышы ZFS файлдық жүйесін резервтік файлдық жүйе ретінде пайдаланудың алдын ала мүмкіндігін қосты. Lustre File System ChecK (LFSCK) мүмкіндігі файлдық жүйе жұмыс істеп тұрғанда, файл деңгейіндегі сақтық көшірмеден/қалпына келтіруден кейін немесе MDS зақымданған жағдайда MDS Object Index (OI) -ды тексеруге және жөндеуге мүмкіндік береді. Серверлік жақтан IO статистикасы SLURM сияқты жұмыс кестелеушілермен интеграциялануға мүмкіндік беру үшін жұмыстың статистикасын бақылауға мүмкіндік берді. Клиенттік бағдарламалық қамтамасыз ету Linux ядросының 3.0 нұсқасына дейінгі нұсқаларымен жұмыс істеу үшін жаңартылды. 2013 жылдың мамырында шыққан Lustre 2.4 көптеген маңызды мүмкіндіктерді қосты, олардың көпшілігі OpenSFS арқылы тікелей қаржыландырылды. Бөлінген атау кеңістігі ортасы (DNE) 2.4 клиенттері үшін көлденең метадеректер сыйымдылығы мен өнімділігін кеңейтуге мүмкіндік береді, өйткені бір атау кеңістігінің кіші каталог ағаштарын бөлек MDT-да орналастыруға мүмкіндік береді. ZFS енді MDT және OST сақтау үшін резервтік файлдық жүйе ретінде қолданылуы мүмкін. LFSCK мүмкіндігі MDT FID және LinkEA атрибуттарының ішкі сәйкестігін сканерлеу және тексеру мүмкіндігін қосты. Желілік сұрауды жоспарлаушы (NRS) дискіні реттеу немесе әділеттілік үшін клиенттік сұрауды өңдеуді оңтайландыру үшін ережелерді қосады. Клиенттер 4 МБ-қа дейінгі көлемде RPC-терді жіберуге мүмкіндік алады. Клиенттік бағдарламалық қамтамасыз ету Linux ядросының 3.6 нұсқасына дейінгі нұсқаларымен жұмыс істеу үшін жаңартылды және 1.8 клиенттерімен де үйлесімді. 2013 жылдың қазан айында шыққан Lustre 2.5 көптен күткен мүмкіндік – Иерархиялық сақтау басқаруын (HSM) қосты. Кәсіпорын ортасындағы маңызды талап болып табылатын HSM клиенттерге операциялық ортада деңгейлі сақтау шешімдерін оңай жүзеге асыруға мүмкіндік береді. Бұл релиз Lustre-дің ағымдағы OpenSFS белгіленген техникалық қолдау бөлімі болып табылады. Соңғы техникалық қолдау нұсқасы 2.5.3 және 2014 жылдың қыркүйегінде жарық көрді. 2014 жылдың шілдесінде шыққан Lustre 2.6 мүмкіндіктер жағынан шағын релиз болды, OST-де жергілікті сәйкестікті тексеруге және MDT және OST объектілері арасындағы сәйкестікті тексеруге мүмкіндік беретін LFSCK функционалдығын қосты. NRS Token Bucket Filter (TBF) саясаты қосылды. Бұрынғы релиздерге қарағанда бір клиенттік IO өнімділігі жақсартылды. Бұл релиз сонымен қатар DNE жолақты каталогтарының алдын ала қарауын қосты, бұл бір үлкен каталогты өнімділікті және кеңейтімділікті жақсарту үшін бірнеше MDT-да сақтауға мүмкіндік береді. 2015 жылдың наурыз айында шыққан Lustre 2.7 бірнеше MDT арасындағы қашық және жолақты каталогтардың DNE сәйкестігін тексеруге мүмкіндік беретін LFSCK функционалдығын қосты. Dynamic LNet Config LNet желілік интерфейстерін, маршруттарды және маршруттандырғыштарды жұмыс істеп тұрғанда конфигурациялауға және өзгертуге мүмкіндік береді. Әртүрлі әкімшілік домендері бар клиенттер үшін UID/GID бейнелеуін бағалауға жаңа мүмкіндік қосылды, сондай-ақ DNE жолақты каталог функционалдығы жақсартылды. 2016 жылдың наурыз айында шыққан Lustre 2.8 DNE жолақты каталог мүмкіндігін аяқтады, соның ішінде каталогтарды MDT арасында көшіруге және MDT арасындағы қатты сілтемелер мен қайта аталғандарды қолдауға мүмкіндік берді. Сонымен қатар, ол клиенттегі Security Enhanced Linux (SELinux) қолдауын, Kerberos аутентификациясын және желідегі RPC шифрлауын, сондай-ақ LFSCK өнімділігін жақсартты. Lustre 2.9 2016 жылдың желтоқсанында жарық көрді және қауіпсіздік және өнімділікке қатысты көптеген мүмкіндіктерді қамтыды. Shared Secret Key қауіпсіздік таңдауы клиент және сервер түйіндерін аутентификациялау және RPC хабарламаларының тұтастығы мен қауіпсіздігін (шифрлау) қамтамасыз ету үшін Kerberos сияқты GSSAPI механизмін пайдаланады. Nodemap мүмкіндігі клиенттік түйіндерді топтарға жіктеуге және содан кейін осы клиенттер үшін UID/GID-ді бейнелеуге мүмкіндік береді, бұл қашықтан басқарылатын клиенттерге барлық клиенттік түйіндер үшін жалғыз UID/GID жиынтығынсыз түсінікті файлдық жүйені пайдалануға мүмкіндік береді. Кіші каталогты орнату мүмкіндігі клиенттерге MDS-ден файлдық жүйенің атау кеңістігінің бір бөлігін орнатуға мүмкіндік береді. Бұл релиз дискіге тиімді I/O жіберу үшін 16 МиБ-қа дейінгі RPC-терді қолдауды қосты, сондай-ақ серверлік кэшке файлдық деректерді алдын ала жүктеуге немесе файлдық деректерді серверлік кэштен шығаруға клиенттерге кеңес беруге мүмкіндік беретін ladvise интерфейсін қосты. Файл жүйесі үшін әдепкі OST пулдерін белгілеуге жақсартылған қолдау және басқа файлдық макет параметрларымен байланыста OST пулдерін мұраға алу жақсартылды. Lustre 2.10 2017 жылдың шілдесінде жарық көрді және көптеген маңызды жақсартуларға ие. LNet Multi Rail (LMR) мүмкіндігі клиент пен сервердегі бірнеше желілік интерфейстерді (InfiniBand, Omni Path және/немесе Ethernet) байланыстыруға мүмкіндік береді, бұл агрегаттық I/O өткізу қабілетін арттырады. Жеке файлдар файлдық офсетке негізделген файлдық аймақтар болып табылатын, жолақтың саны, OST пулы/сақтау түрі және т.б. сияқты әртүрлі макет параметрларын құруға мүмкіндік беретін композиттік файлдық макеттерді пайдалана алады. Progressive File Layout (PFL) композиттік макеттарды пайдаланатын алғашқы мүмкіндік болып табылады, бірақ реализация басқа файлдық макеттармен, мысалы, көшірме жасау және өшіру кодтаумен пайдалану үшін икемді. Желілік сұрауды жоспарлаушы (NRS) Token Bucket Filter (TBF) серверлік жақтан жоспарлаушы жаңа ереже түрлерін, соның ішінде RPC түрінің жоспарлауын және ережелерді сәйкестендіру үшін JobID және NID сияқты бірнеше параметрлерді белгілеу мүмкіндігін енгізді. Lustre файлдық жүйесінің ZFS суретін басқару құралдары қосылды, бұл MDT және OST ZFS суреттерін жеке 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.

Іске асыру

Linux клиентіне Lustre орнатылғанда, Lustre файлдық жүйе драйвер модулі ядроға жүктеледі және файлдық жүйе кез келген басқа жергілікті немесе желілік файлдық жүйе сияқты орнатылады. Клиенттік қолданбалар бірыңғай, біріктірілген файлдық жүйені көреді, тіпті ол ондаған немесе мыңдаған жеке серверлер мен MDT/OST файлдық жүйелерінен құралған болса да. Кейбір үлкен параллель процессорлар (MPP) орналымдарында есептеу процессорлары Lustre клиенті ретінде конфигурацияланған арнайы I/O түйініне I/O сұраныстарын қайта бағыттау арқылы Lustre файлдық жүйесіне қол жеткізе алады. Бұл тәсіл Лоуренс Ливермор Ұлттық зертханасындағы Blue Gene орналымында қолданылады. Lustre-дің алғашқы жылдарында қолданылған тағы бір тәсіл – бұл Cray XT3-те Catamount операциялық жүйесін пайдаланатын liblustre кітапханасы, мысалы, Sandia Red Storm жүйелерінде, ол пайдаланушы кеңістігі қолданбаларына файлдық жүйеге тікелей қол жеткізуді қамтамасыз етті. Liblustre – Lustre файлдық жүйесін клиент ретінде орнатуға және пайдалануға мүмкіндік беретін пайдаланушы деңгейіндегі кітапхана. Liblustre-ді пайдалану арқылы есептеу процессорлары Lustre файлдық жүйесіне тіпті жұмыс іске қосылған қызмет түйіні Linux клиенті болмаса да, қол жеткізе алады. Liblustre деректерді қолданба кеңістігі мен Lustre OSS арасында тікелей жылжытуға мүмкіндік берді, ядро арқылы аралық дерек көшірмесін қажет етпей, осылайша есептеу процессорларынан Lustre файлдық жүйесіне шектеулі операциялық ортада тікелей қол жеткізуді қамтамасыз етті. Liblustre функционалы 2.6.0 нұсқасынан бастап өшірілді және 2.7.0 нұсқасында алынып тасталды, ал 2.3.0 нұсқасынан бері сынақтан өтпеді. Linux Kernel 4.18 нұсқасында Lustre клиентінің толық емеспелігі ядроның сатылатын аймағынан алынып тасталды, жаңа ядроларды әзірлеу және порттау процесін жеделдету үшін. Lustre клиенті мен серверінің ядродан тыс нұсқасы RHEL, SLES және Ubuntu дистрибутивтерінің ядролары үшін, сондай-ақ стандартты ядролар үшін әлі де қол жетімді.

Деректер объектілері мен файлдарды жолақтау

Дәстүрлі Unix дискілік файл жүйесінде inode дерек құрылымы әр файл туралы негізгі ақпаратты қамтиды, мысалы, файлдағы деректер қайда сақталады. Lustre файл жүйесі де inode-тарды қолданады, бірақ MDT-дегі inode-тар файлға қатысты бір немесе бірнеше OST нысанына сілтеме жасайды, дерек блоктарына емес. Бұл нысандар OST-де файл ретінде іске асырылады. Клиент файлды ашқанда, файлды ашу операциясы объектілердің идентификаторларын және олардың орналасуын MDS-тен клиентке жібереді, осылайша клиент объектіні сақтайтын OSS түйінімен тікелей өзара әрекеттесе алады. Бұл клиентке файлдағы барлық OST нысандарында параллель I/O операцияларын орындауға мүмкіндік береді, орталық блоктарды және құлыптауды басқарудан туындайтын кедергілерден аулақтап, қосымша байланыс қажет болмайды. Егер MDT inode-ымен бір ғана OST нысаны байланысты болса, онда бұл нысан Lustre файлындағы барлық деректерді қамтиды. Егер бір файлға бірнеше нысан қосылған болса, файлдағы деректер RAID 0 сияқты OST нысандары бойынша дөңгелек тәртіппен 1 МБ немесе одан да үлкен бөліктерге "бөлінеді". Бір файлды бірнеше OST нысанына бөлу, егер бір үлкен файлға жоғары өткізгіштікпен қол жеткізу қажет болса, өнімділіктің айтарлықтай артуын қамтамасыз етеді. Бөлу қолданылған кезде файлдың максималды көлемі бір нысанның көлемімен шектелмейді. Сыйымдылық және жиынтық I/O өткізгіштігі файл бөлінген OST нысандарының санымен пропорционалды түрде өседі. Сонымен қатар, әр нысанның құлыпталуы әр OST үшін дербес басқарылатындықтан, жолақтардың санын арттыру (әр OST үшін бір жолақ) файлдың I/O құлыптау қабілетін пропорционалды түрде арттырады. Файл жүйесінде құрылған әр файл әртүрлі орналасу параметрларын көрсетуі мүмкін, мысалы, жолақтардың саны (файлды құрайтын OST нысандарының саны), жолақтың көлемі (келесі OST-қа көшу алдында әр OST-да сақталатын деректердің бірлігі) және OST таңдауы, осылайша әр файл үшін өнімділікті және сыйымдылықты оңтайлы деңгейде реттеуге болады. Егер көптеген қолданба жіптері жеке файлдарды параллельде оқып немесе жазып жатса, файлға бір жолақ болғаны тиімді, себебі қолданба өзінің параллельдігін қамтамасыз етеді. Егер көптеген жіптер бір үлкен файлды бір уақытта оқып немесе жазып жатса, онда әр OST-да кемінде бір жолақ болғаны тиімді, бұл файлдың өнімділігі мен сыйымдылығын максималды деңгейге көтереді. Lustre 2.10 нұсқасында композиттік орналасуларды белгілеу мүмкіндігі қосылды, бұл файлдың әртүрлі аймақтары үшін әртүрлі орналасу параметрлерін беруге мүмкіндік береді. Прогрессивті файл орналасуы (PFL) мүмкіндігі кең ауқымдағы жұмыс жүктемелерінде файлдың I/O өнімділігін жақсарту үшін композиттік орналасуларды пайдаланады, сондай-ақ пайдалануды және басқаруды жеңілдетеді. Мысалы, кішкентай PFL файлында флэш-жадта төменгі кіру шығындары үшін бір жолақ болуы мүмкін, ал үлкен файлдарда жоғары жиынтық өткізгіштік пен жақсы OST жүктемесін теңестіру үшін көптеген жолақтар болуы мүмкін. Композиттік орналасу 2.11 нұсқасында файл деңгейіндегі резервтік көшірме (FLR) мүмкіндігімен толықтырылды, бұл файлдың бірнеше жапсарлас орналасуына ие болуына мүмкіндік береді, бұл файлдар үшін RAID 0+1 резервтік көшірмесін және оқу өнімділігін жақсартады. Lustre 2.11 нұсқасында метадеректердегі деректер (DoM) мүмкіндігі де қосылды, бұл PFL файлының бірінші компонентін тікелей MDT-да inode-мен бірге сақтауға мүмкіндік береді. Бұл кішкентай файлдарға қол жеткізу үшін шығындарды азайтады, кеңістікті пайдалану (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 File Identifier (FID, 64 биттік реттік нөмір, 32 биттік нысан идентификаторы және 32 биттік нұсқадан тұрады) орнату нүктесінің түбір каталогы беріледі. Файл атауын іздеу кезінде клиент, әрбір жол атауы компонентін іздеуді жүргізеді, аталық каталогтың FID реттік нөмірін FID орналасу дерекқоры (FLDB) арқылы белгілі бір MDT-ға сәйкестендіріп, содан кейін аталық FID және файл атауын пайдалана отырып, осы MDT-ді басқаратын MDS-де іздейді. MDS сұралған жол атауы компонентінің FID-ін DLM құлпымен бірге қайтарады. Жолдағы соңғы каталогтың MDT анықталғаннан кейін, басқа каталог операциялары (жолақталмаған каталогтар үшін) әдетте осы MDT-да орындалады, бұл MDT арасындағы қақтығыстарды болдырмайды. DNE жолақты каталогтар үшін, бас каталогта сақталған каталог макеті хэш функциясын және каталог бөлінген MDT каталог FID-терінің тізімін ұсынады. Клиенттегі Логикалық метадеректер томы (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.

Қалқалау

OpenVMS стилімен іске асырылған Lustre үлестірілген құлып менеджері (LDLM) әр файлдың деректері мен метадеректерінің тұтастығын қорғайды. Lustre файлына қол жеткізу және оны өзгерту барлық клиенттер арасында кэшпен толық үйлесімді болады. Метадеректер құлыптарын файлдың inode-ын сақтайтын MDT басқарады, ресурс атауы ретінде FID қолданылады. Метадеректер құлыптары файлды іздеуді (файл иесі мен тобы, рұқсаттары мен режимі және кіруді бақылау тізімі (ACL)), inode-тың күйін (директорияның өлшемі, каталогтың мазмұны, сілтемелер саны, уақыт белгілері), орналасуын (файлдың жолақтылығы, Lustre 2.4 нұсқасынан бастап) және кеңейтілген атрибуттарды (xattrs, Lustre 2.5 нұсқасынан бастап) қорғайтын жеке биттерге бөлінеді. Клиент бір RPC сұранысы арқылы бір inode үшін бірнеше метадеректер құлыптарын алуға болады, бірақ қазіргі уақытта оларға тек inode үшін оқу құлпы ғана беріледі. MDS ресурстарды құлыптау қақтығыстарын болдырмау үшін inode-қа барлық өзгерістерді басқарады және қазіргі уақытта inode-тарға жазу құлпын алатын жалғыз түйін болып табылады. Файл деректерінің құлыптарын OST басқарады, онда файлдың әрбір объектісі байттық диапазон бойынша құлыпталады. Клиенттерге файлдың бір бөлігіне немесе барлық бөлігіне қабаттасатын оқу құлыптары берілуі мүмкін, бұл бір файлды бірнеше рет оқуға мүмкіндік береді, және/немесе файлдың тәуелсіз аймақтарына қабаттаспайтын жазу құлыптары берілуі мүмкін. Бұл көптеген Lustre клиенттеріне файл I/O кезінде тұйықтардан аулақ болу үшін оқуға және жазуға бір мезгілде бір файлға қол жеткізуге мүмкіндік береді. Іс жүзінде, 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) желілері сияқты көптеген қолданылатын желі түрлерін пайдалана алады және олардың арасында маршрутизация арқылы бірнеше желі түрлерінде бір мезгілде қолжетімділікке мүмкіндік береді. Remote Direct Memory Access (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 МБ/с-тан жоғары өткізуді, InfiniBand кеңейтілген деректер жылдамдығы (EDR) байланыстарын пайдалана отырып 11 ГБ/с-қа дейін, ал 100 ГБ/с интерфейстер арқылы 11 ГБ/с-тан жоғары өткізуді қамтамасыз етеді.

Жоғары қол жетімділік

Lustre файлдық жүйесінің жоғары сенімділік мүмкіндіктеріне, сервердің істен шығуы мен қайта жүктелуін көзге көрінбей жасайтын, берік ауысу және қалпына келтіру механизмі кіреді. Lustre бағдарламалық қамтамасының екі бірге үйлесімді шағын нұсқалары арасындағы нұсқалардың өзара жұмыс істеуі, серверді жеке (немесе резервтік серверге ауыстырып) жаңартуға, жаңартуды орындауға және қайта іске қосуға мүмкіндік береді, ал барлық жұмыс істеп жатқан тапсырмалар үздірілмей жалғаса береді, тек резервтік сервер сақтауды қолға алғанда ғана қысқа уақытқа тоқтап қалады. Lustre MDS бір MDT экспорттайтын белсенді/пассивті жұп ретінде немесе DNE арқылы екі немесе одан көп жеке MDT экспорттайтын бір немесе бірнеше белсенді/белсенді MDS жұптары ретінде конфигурацияланады, ал OSS әдетте артықшылықты қамтамасыз ету үшін қосымша жүйелік жүктемесіз жеке OST экспорттайтын белсенді/белсенді конфигурацияда орналастырылады. Бір MDT файлдық жүйелерінде, бір файлдық жүйе үшін резервтік MDS – MGS және/немесе мониторинг торабы немесе басқа файлдық жүйе үшін белсенді MDS болып табылады, сондықтан кластерде ешбір торап бос тұрмайды.

Жұмысқа орналастыру

Lustre-ді көптеген TOP500 суперкомпьютерлері мен ірі көп кластерлік орталықтар пайдаланады. Топ-10 суперкомпьютерлердің 6-сы және топ-100 суперкомпьютерлердің 60-тан астамы Lustre файлдық жүйелерін қолданады. Олардың ішінде Оук Ридж Ұлттық зертханасының (ORNL) Frontier суперкомпьютері үшін құрылған 700ПБ, 13ТБ/с жылдамдығына ие Orion файлдық жүйесі, 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 және басқалары жатады. Сонымен қатар, кейбір сатушылардан, оның ішінде Whamcloud-тан Lustre файлдық жүйелеріне ғана бағдарламалық қолдау алуға болады. Amazon Web Services компаниясы толық басқарылатын Amazon FSx for Lustre қызметін ұсынады, бұл олардың бұлттық қызметінде жоғары өнімділікке ие файлдық жүйелерді тиімді пайдалануға және іске қосуға мүмкіндік береді.