Lustre — это тип параллельной распределенной файловой системы , обычно используемой для крупномасштабных кластерных вычислений . Название Lustre — это слово-портманто, полученное из Linux и cluster . [6] Программное обеспечение файловой системы Lustre доступно по лицензии GNU General Public License (только версия 2) и обеспечивает высокопроизводительные файловые системы для компьютерных кластеров размером от небольших кластеров рабочих групп до крупномасштабных многосайтовых систем. С июня 2005 года Lustre постоянно используется по крайней мере половиной из первой десятки и более чем 60 из 100 самых быстрых суперкомпьютеров в мире, [7] [8] [9] включая суперкомпьютер № 1 в мире, занявший первое место в рейтинге TOP500 в ноябре 2022 года, Frontier , [4], а также предыдущие лучшие суперкомпьютеры, такие как Fugaku , [10] [11] Titan [12] и Sequoia . [13]
Файловые системы Lustre масштабируемы и могут быть частью нескольких компьютерных кластеров с десятками тысяч клиентских узлов, сотнями петабайт (ПБ) хранилища на сотнях серверов и десятками терабайт в секунду (ТБ/с) совокупной пропускной способности ввода-вывода . [14] [15] Это делает файловые системы Lustre популярным выбором для предприятий с крупными центрами обработки данных, в том числе в таких отраслях, как метеорология , [16] [17] моделирование , искусственный интеллект и машинное обучение , [18] [19] нефть и газ, [20] науки о жизни , [21] [22] мультимедиа и финансы. [23] Производительность ввода-вывода Lustre оказывает широкое влияние на эти приложения и привлекает широкое внимание. [24] [25] [26]
Архитектура файловой системы Lustre была начата как исследовательский проект в 1999 году Питером Дж. Браамом , который в то время был сотрудником Университета Карнеги-Меллона (CMU). Браам основал собственную компанию Cluster File Systems в 2001 году, [27] начав с работы над файловой системой InterMezzo в проекте Coda в CMU. [28] Lustre была разработана в рамках проекта Accelerated Strategic Computing Initiative Path Forward, финансируемого Министерством энергетики США , в который входили Hewlett-Packard и Intel . [29] В сентябре 2007 года Sun Microsystems приобрела активы Cluster File Systems Inc., включая ее «интеллектуальную собственность». [30] [31] Sun включила Lustre в свои предложения по высокопроизводительному вычислительному оборудованию с намерением внедрить технологии Lustre в файловую систему ZFS компании Sun и операционную систему Solaris . В ноябре 2008 года Браам покинул Sun Microsystems, а Эрик Бартон и Андреас Дилгер взяли под контроль проект. В 2010 году корпорация Oracle , путем приобретения Sun, начала управлять и выпускать Lustre.
В декабре 2010 года Oracle объявила, что прекратит разработку Lustre 2.x и переведет Lustre 1.8 в режим только поддержки обслуживания, что создало неопределенность относительно будущего развития файловой системы. [32] После этого объявления возникло несколько новых организаций, которые будут оказывать поддержку и разработку в открытой модели разработки сообщества, включая Whamcloud, [33] Open Scalable File Systems, Inc. (OpenSFS) , EUROPEAN Open File Systems (EOFS) и другие. К концу 2010 года большинство разработчиков Lustre покинули Oracle. Браам и несколько его коллег присоединились к ориентированной на аппаратное обеспечение Xyratex , когда она приобрела активы ClusterStor, [34] [35], в то время как Бартон, Дилгер и другие основали стартап программного обеспечения Whamcloud, где они продолжили работать над Lustre. [36]
В августе 2011 года OpenSFS заключила контракт на разработку функций Lustre с Whamcloud. [37] Этот контракт охватывал завершение функций, включая улучшенное масштабирование производительности метаданных единого сервера, что позволяет Lustre лучше использовать преимущества многоядерного сервера метаданных; онлайн-проверку распределенной файловой системы Lustre (LFSCK), которая позволяет проверять состояние распределенной файловой системы между серверами данных и метаданных, пока файловая система смонтирована и используется; и распределенную среду пространства имен (DNE), ранее кластеризованные метаданные (CMD), которая позволяет распределять метаданные Lustre по нескольким серверам. Разработка также продолжалась на основе хранилища объектов на основе ZFS в Ливерморской национальной лаборатории им. Лоуренса . [13] Эти функции были в дорожной карте выпуска сообщества Lustre 2.2 через 2.4. [38] В ноябре 2011 года с Whamcloud был заключен отдельный контракт на обслуживание исходного кода Lustre 2.x, чтобы гарантировать, что код Lustre получит достаточное тестирование и исправление ошибок, пока разрабатываются новые функции. [39]
В июле 2012 года Whamcloud была приобретена Intel [40] [ 41] после того, как Whamcloud выиграла контракт FastForward DOE на подготовку Lustre для использования с экзафлопсными вычислительными системами в период до 2018 года. [42] Затем OpenSFS передала контракты на разработку Lustre компании Intel.
В феврале 2013 года Xyratex Ltd. объявила о приобретении оригинальной торговой марки Lustre, логотипа, веб-сайта и связанной с ними интеллектуальной собственности у Oracle. [34] В июне 2013 года Intel начала расширять использование Lustre за пределы традиционных HPC, например, в Hadoop . [43] В 2013 году в целом OpenSFS объявила о запросе предложений (RFP) для охвата разработки функций Lustre, инструментов параллельной файловой системы , решения технической задолженности Lustre и инкубаторов параллельной файловой системы. [44] OpenSFS также создала портал сообщества Lustre, технический сайт, который предоставляет коллекцию информации и документации в одной области для справки и руководства для поддержки сообщества разработчиков ПО с открытым исходным кодом Lustre . 8 апреля 2014 года Кен Клаффи объявил, что Xyratex/Seagate жертвует домен lustre.org обратно сообществу пользователей, [45] и это было завершено в марте 2015 года.
В июне 2018 года команда и активы Lustre были приобретены у Intel компанией DDN . DDN организовала новое приобретение как независимое подразделение, возродив название Whamcloud для нового подразделения. [46]
В ноябре 2019 года OpenSFS и EOFS объявили на SC19 Lustre BOF, что торговая марка Lustre была передана им совместно от Seagate . [47]
Файловая система Lustre была впервые установлена для промышленного использования в марте 2003 года на кластере MCR Linux в Ливерморской национальной лаборатории имени Лоуренса [48] , третьем по величине суперкомпьютере в списке Top500 на тот момент. [49]
Lustre 1.0.0 был выпущен в декабре 2003 года [1] и обеспечивал базовую функциональность файловой системы Lustre, включая отказоустойчивость и восстановление сервера.
Lustre 1.2.0, выпущенный в марте 2004 года, работал на ядре Linux 2.6 и имел функцию «просмотра размера», которая позволяла избежать отмены блокировки файлов, находящихся в процессе записи, а также учет кэша обратной записи данных на стороне клиента (предоставление).
Lustre 1.4.0, выпущенный в ноябре 2004 года, обеспечивал совместимость протоколов между версиями, мог использовать сети InfiniBand и мог использовать extends/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. [50]
Lustre 2.0, выпущенный в августе 2010 года, был основан на существенно внутренне реструктурированном коде для подготовки к крупным архитектурным усовершенствованиям. Клиенты Lustre 2.x не могут взаимодействовать с серверами 1.8 или более ранними . Однако клиенты Lustre 1.8.6 и более поздние версии могут взаимодействовать с серверами Lustre 2.0 и более поздними версиями. Формат Metadata Target (MDT) и OST на диске с версии 1.8 можно обновить до 2.0 и более поздних версий без необходимости переформатирования файловой системы.
Lustre 2.1, выпущенный в сентябре 2011 года, был инициативой всего сообщества в ответ на приостановку Oracle разработки релизов Lustre 2.x. [51] Он добавил возможность запускать серверы на Red Hat Linux 6 и увеличил максимальный размер OST на основе ext4 с 24 ТБ до 128 ТБ, [52] а также ряд улучшений производительности и стабильности. Серверы Lustre 2.1 оставались совместимыми с клиентами 1.8.6 и более поздних версий.
Lustre 2.2, выпущенный в марте 2012 года, был сосредоточен на улучшении производительности метаданных и новых функциях. [53] Он добавил параллельные операции с каталогами, позволяющие нескольким клиентам одновременно просматривать и изменять один большой каталог, более быстрое восстановление после сбоев сервера, увеличенное количество полос для одного файла (до 2000 OST) и улучшенную производительность обхода каталогов одним клиентом.
Lustre 2.3, выпущенный в октябре 2012 года, продолжил улучшать код сервера метаданных для устранения внутренних блокировок узких мест на узлах с большим количеством ядер ЦП (более 16). Хранилище объектов добавило предварительную возможность использования ZFS в качестве резервной файловой системы. Функция Lustre File System ChecK (LFSCK) может проверять и восстанавливать индекс объектов MDS (OI) во время использования файловой системы, после резервного копирования/восстановления на уровне файлов или в случае повреждения MDS. Статистика ввода-вывода на стороне сервера была улучшена для обеспечения интеграции с планировщиками пакетных заданий, такими как SLURM, для отслеживания статистики по заданиям. Клиентское программное обеспечение было обновлено для работы с ядрами Linux до версии 3.0.
Lustre 2.4, выпущенный в мае 2013 года, добавил значительное количество основных функций, многие из которых финансировались напрямую через OpenSFS . Распределенная среда пространств имен (DNE) обеспечивает горизонтальное масштабирование емкости метаданных и производительности для клиентов 2.4, позволяя размещать деревья подкаталогов одного пространства имен на отдельных MDT. ZFS теперь можно использовать в качестве резервной файловой системы для хранения как MDT, так и OST. Функция LFSCK добавила возможность сканирования и проверки внутренней согласованности атрибутов FID и LinkEA MDT. Планировщик сетевых запросов [54] [55] (NRS) добавляет политики для оптимизации обработки клиентских запросов для упорядочивания или справедливости дисков. Клиенты могут по желанию отправлять массовые RPC размером до 4 МБ. Клиентское программное обеспечение было обновлено для работы с ядрами Linux до версии 3.6 и по-прежнему совместимо с клиентами 1.8.
Lustre 2.5, выпущенный в октябре 2013 года, добавил долгожданную функцию Hierarchical Storage Management (HSM). HSM, основное требование в корпоративных средах, позволяет клиентам легко внедрять многоуровневые решения для хранения в своей операционной среде. Этот выпуск является текущей ветвью Maintenance Release, обозначенной OpenSFS, Lustre. [56] [57] [58] [59] Последняя версия Maintenance — 2.5.3, выпущенная в сентябре 2014 года. [60]
Lustre 2.6, выпущенный в июле 2014 года, [61] был более скромным релизом с точки зрения функций, добавляя функциональность LFSCK для выполнения локальных проверок согласованности в OST, а также проверок согласованности между объектами MDT и OST. Была добавлена политика NRS Token Bucket Filter [62] (TBF). Производительность одноклиентского ввода-вывода была улучшена по сравнению с предыдущими выпусками. [63] В этом выпуске также был добавлен предварительный просмотр чередующихся каталогов DNE, что позволило хранить отдельные большие каталоги в нескольких MDT для повышения производительности и масштабируемости.
Lustre 2.7, выпущенный в марте 2015 года, [64] добавил функциональность LFSCK для проверки согласованности DNE удаленных и чередующихся каталогов между несколькими MDT. Dynamic LNet Config добавляет возможность настраивать и изменять сетевые интерфейсы, маршруты и маршрутизаторы LNet во время выполнения. Была добавлена новая функция оценки для сопоставления UID / GID для клиентов с различными административными доменами, а также улучшения функциональности чередующихся каталогов DNE.
Lustre 2.8, выпущенный в марте 2016 года, [65] завершил функцию DNE striped directory, включая поддержку миграции каталогов между MDT, а также cross-MDT hard link и rename. Также он включал улучшенную поддержку Security-Enhanced Linux ( SELinux ) на клиенте, аутентификацию Kerberos и шифрование RPC по сети, а также улучшения производительности для LFSCK.
Lustre 2.9 был выпущен в декабре 2016 года [66]
и включал ряд функций, связанных с безопасностью и производительностью. Вариант безопасности Shared Secret Key использует тот же механизм GSSAPI , что и Kerberos, для обеспечения аутентификации клиентских и серверных узлов, а также целостности и безопасности сообщений RPC (шифрования). Функция Nodemap позволяет классифицировать клиентские узлы по группам, а затем сопоставлять UID/GID для этих клиентов, позволяя удаленно администрируемым клиентам прозрачно использовать общую файловую систему без единого набора UID/GID для всех клиентских узлов. Функция монтирования подкаталога позволяет клиентам монтировать подмножество пространства имен файловой системы из MDS. В этом выпуске также добавлена поддержка RPC до 16 МиБ для более эффективной отправки ввода-вывода на диск и добавлен интерфейс ladvise, позволяющий клиентам предоставлять подсказки ввода-вывода серверам для предварительной выборки данных файлов в кэш сервера или очистки данных файлов из кэша сервера. Улучшена поддержка указания пулов OST по умолчанию для всей файловой системы, а также улучшено наследование пулов OST в сочетании с другими параметрами макета файла.
Lustre 2.10 был выпущен в июле 2017 года [67] и имеет ряд существенных улучшений. Функция LNet Multi-Rail (LMR) позволяет объединять несколько сетевых интерфейсов ( InfiniBand , Omni-Path и/или Ethernet ) на клиенте и сервере для увеличения совокупной пропускной способности ввода-вывода. Отдельные файлы могут использовать составные макеты файлов, которые состоят из нескольких компонентов, которые являются областями файлов на основе смещения файла, которые допускают различные параметры макета, такие как количество полос, пул/тип хранилища OST и т. д. Progressive File Layout (PFL) — первая функция, использующая составные макеты, но реализация гибка для использования с другими макетами файлов, такими как зеркалирование и кодирование стирания. Планировщик на стороне сервера NRS Token Bucket Filter (TBF) реализовал новые типы правил, включая планирование типа RPC и возможность указывать несколько параметров, таких как JobID и NID, для сопоставления правил. Добавлены инструменты для управления снимками ZFS файловых систем Lustre, чтобы упростить создание, монтирование и управление снимками MDT и OST ZFS как отдельными точками монтирования Lustre .
Lustre 2.11 был выпущен в апреле 2018 года [68] и содержит две существенные новые функции и несколько более мелких функций. Функция File Level Redundancy (FLR) расширяет реализацию PFL 2.10, добавляя возможность указывать зеркальные макеты файлов для улучшения доступности в случае сбоя хранилища или сервера и/или повышения производительности при высококонкурентном чтении. Функция Data-on-MDT (DoM) позволяет хранить небольшие (несколько МиБ) файлы на MDT для использования типичного флэш- хранилища RAID-10 для снижения задержек и снижения конкуренции ввода-вывода вместо типичного хранилища HDD RAID-6 , используемого в OST. Кроме того, функция LNet Dynamic Discovery позволяет автоматически настраивать LNet Multi-Rail между одноранговыми узлами, которые совместно используют сеть LNet. Функция LDLM Lock Ahead позволяет соответствующим образом модифицированным приложениям и библиотекам предварительно извлекать блокировки экстентов DLM из OST для файлов, если приложение знает (или предсказывает), что этот экстент файла будет изменен в ближайшем будущем, что может снизить количество конфликтов блокировок для нескольких клиентов, записывающих данные в один и тот же файл.
Lustre 2.12 был выпущен 21 декабря 2018 года [69] и был сосредоточен на улучшении удобства использования и стабильности Lustre, с улучшениями производительности и функциональности функций FLR и DoM, добавленных в Lustre 2.11, а также небольшими изменениями в NRS TBF , HSM и JobStats. Он добавил LNet Network Health Archived 2019-02-12 в Wayback Machine , чтобы позволить функции LNet Multi-Rail из Lustre 2.10 лучше обрабатывать сетевые сбои, когда узел имеет несколько сетевых интерфейсов. Функция Lazy Size on MDT [70] (LSOM) позволяет хранить оценку размера файла в MDT для использования механизмами политик, сканерами файловых систем и другими инструментами управления, которые могут более эффективно принимать решения о файлах без полностью точных размеров файлов или количества блоков, не запрашивая эту информацию у OST. В этом выпуске также добавлена возможность вручную перераспределять существующий каталог по нескольким MDT, чтобы разрешить миграцию каталогов с большим количеством файлов для использования емкости и производительности нескольких узлов MDS. Контрольная сумма данных Lustre RPC добавила интегрированные контрольные суммы данных SCSI T10-PI [71] от клиента до уровня блока ядра, адаптера хоста SCSI и жестких дисков с поддержкой T10 .
Lustre 2.13 был выпущен 5 декабря 2019 года [72] и добавил новые функции, связанные с производительностью: Persistent Client Cache [73] (PCC), который позволяет напрямую использовать хранилище NVMe и NVRAM на клиентских узлах, сохраняя файлы частью глобального пространства имен файловой системы, и OST Overstriping [74] , который позволяет файлам хранить несколько полос на одном OST для лучшего использования быстрого оборудования OSS. Кроме того, функциональность LNet Multi-Rail Network Health была улучшена для работы с узлами маршрутизатора LNet RDMA. Функциональность PFL была улучшена с помощью Self-Extending Layouts [75] (SEL), чтобы позволить компонентам файлов иметь динамический размер, чтобы лучше работать с флэш-OST, которые могут быть намного меньше дисковых OST в той же файловой системе. В релиз также вошло несколько небольших улучшений, таких как балансировка создания удаленного каталога DNE по всем MDT, использование Lazy-size-on-MDT для снижения накладных расходов «lfs find», каталоги с файлами размером 10 МБ на шард для ldiskfs и объемные размеры RPC до 64 МБ. [76]
Lustre 2.14 был выпущен 19 февраля 2021 года [77] и включает в себя три основные функции. Шифрование клиентских данных реализует fscrypt, чтобы разрешить шифрование данных файлов на клиенте перед передачей по сети и постоянным хранением в OST и MDT. Квоты пула OST расширяют структуру квот, позволяя назначать и применять квоты на основе пулов хранения OST. DNE Auto Restriping теперь может регулировать количество MDT, по которым большой каталог будет разделен, на основе пороговых значений размера, определенных администратором, аналогично Progressive File Layouts для каталогов.
Lustre 2.15 был выпущен 16 июня 2022 года [2] и включает в себя три основные функции. Шифрование клиентского каталога [78] расширяет шифрование данных fscrypt в выпуске 2.14, чтобы также позволить шифровать имена файлов и каталогов на клиенте перед передачей по сети и постоянным хранением на MDT. Балансировка пространства DNE MDT автоматически балансирует создание новых каталогов по MDT в файловой системе в циклическом режиме и/или на основе доступных inode и пространства, что, в свою очередь, помогает более равномерно распределять рабочую нагрузку метаданных клиента по MDT. Для приложений, использующих интерфейс NVIDIA GPU Direct Storage (GDS), клиент Lustre может выполнять чтение и запись RDMA с нулевым копированием с сервера хранения непосредственно в память GPU , чтобы избежать дополнительного копирования данных из памяти CPU и дополнительных накладных расходов на обработку. [79] Политика выбора, определяемая пользователем (UDSP), позволяет устанавливать политики выбора интерфейса для узлов с несколькими сетевыми интерфейсами.
Файловая система Lustre состоит из трех основных функциональных блоков:
MDT, OST и клиент могут находиться на одном узле (обычно для целей тестирования), но в типичных производственных установках эти устройства находятся на отдельных узлах, взаимодействующих по сети. Каждый MDT и OST может быть частью только одной файловой системы, хотя на одном узле может быть несколько MDT или OST, которые являются частью разных файловых систем. Уровень Lustre Network (LNet) может использовать несколько типов сетевых соединений, включая собственные команды InfiniBand , Omni-Path , RoCE и iWARP через OFED , TCP/IP на Ethernet и другие фирменные сетевые технологии, такие как соединение Cray Gemini. В Lustre 2.3 и более ранних версиях также поддерживались сети Myrinet , Quadrics , Cray SeaStar и RapidArray, но эти сетевые драйверы были объявлены устаревшими, когда эти сети перестали быть коммерчески доступными, и поддержка была полностью удалена в Lustre 2.8. Lustre будет использовать преимущества удаленного прямого доступа к памяти ( RDMA ) при наличии такой возможности для повышения пропускной способности и снижения загрузки ЦП.
Хранилище, используемое для резервных файловых систем MDT и OST, обычно предоставляется аппаратными RAID- устройствами, хотя будет работать с любыми блочными устройствами. Начиная с Lustre 2.4, MDT и OST также могут использовать ZFS для резервной файловой системы в дополнение к ext4 , что позволяет им эффективно использовать хранилище JBOD вместо аппаратных RAID-устройств. Серверы Lustre OSS и MDS считывают, записывают и изменяют данные в формате, налагаемом резервной файловой системой, и возвращают эти данные клиентам. Это позволяет Lustre использовать преимущества улучшений и функций в базовой файловой системе, таких как сжатие и контрольные суммы данных в ZFS. Клиенты не имеют прямого доступа к базовому хранилищу, что гарантирует, что неисправный или вредоносный клиент не сможет повредить структуру файловой системы.
OST — это выделенная файловая система, которая экспортирует интерфейс в байтовые диапазоны файловых объектов для операций чтения/записи с блокировками экстентов для защиты согласованности данных. MDT — это выделенная файловая система, которая хранит inodes, каталоги, POSIX и расширенные атрибуты файлов , управляет разрешениями на доступ к файлам/ ACL и сообщает клиентам структуру объекта(ов), которые составляют каждый обычный файл. MDT и OST в настоящее время используют либо расширенную версию ext4 , называемую ldiskfs , либо ZFS /DMU для внутреннего хранения данных для хранения файлов/объектов [80] с использованием порта ZFS-on-Linux с открытым исходным кодом. [81]
Клиент монтирует файловую систему Lustre локально с помощью драйвера VFS для ядра Linux , который подключает клиента к серверу(ам). При первоначальном монтировании клиенту предоставляется идентификатор файла (FID) для корневого каталога точки монтирования. Когда клиент обращается к файлу, он выполняет поиск имени файла в MDS. Когда поиск имени файла в MDS завершен и у пользователя и клиента есть разрешение на доступ и/или создание файла, клиенту возвращается макет существующего файла или создается новый файл от имени клиента, если это запрошено. Для операций чтения или записи клиент затем интерпретирует макет файла в слое логического тома объектов (LOV) , который сопоставляет логическое смещение и размер файла с одним или несколькими объектами. Затем клиент блокирует диапазон файлов, над которым выполняется операция, и выполняет одну или несколько параллельных операций чтения или записи непосредственно на узлах OSS, которые содержат объекты данных. При таком подходе устраняются узкие места в коммуникациях между клиентом и OSS, поэтому общая пропускная способность, доступная клиентам для чтения и записи данных, масштабируется почти линейно с количеством OST в файловой системе.
После первоначального поиска файловой структуры MDS обычно не участвует в операциях ввода-вывода файлов, поскольку все распределение блоков и ввод-вывод данных управляются изнутри OST. Клиенты не изменяют объекты или данные в файловых системах OST напрямую, а вместо этого делегируют эту задачу узлам OSS. Такой подход обеспечивает масштабируемость для крупномасштабных кластеров и суперкомпьютеров, а также повышает безопасность и надежность. Напротив, общие файловые системы на основе блоков, такие как GPFS и OCFS, обеспечивают прямой доступ к базовому хранилищу всем клиентам в файловой системе, что требует большой внутренней SAN, подключенной ко всем клиентам, и увеличивает риск повреждения файловой системы из-за неправильно работающих/неисправных клиентов.
В типичной установке Lustre на клиенте Linux модуль драйвера файловой системы Lustre загружается в ядро, а файловая система монтируется как любая другая локальная или сетевая файловая система. Клиентские приложения видят единую унифицированную файловую систему, хотя она может состоять из десятков или тысяч отдельных серверов и файловых систем MDT/OST.
На некоторых установках с массивно-параллельным процессором (MPP) вычислительные процессоры могут получать доступ к файловой системе Lustre, перенаправляя свои запросы ввода-вывода на выделенный узел ввода-вывода, настроенный как клиент Lustre. Этот подход используется в установке Blue Gene [82] в Ливерморской национальной лаборатории им. Лоуренса .
Другой подход, использовавшийся в ранние годы Lustre, — это библиотека liblustre на Cray XT3 с использованием операционной системы Catamount на таких системах, как Sandia Red Storm , [83] , которая предоставляла приложениям пользовательского пространства прямой доступ к файловой системе. Liblustre была библиотекой пользовательского уровня, которая позволяла вычислительным процессорам монтировать и использовать файловую систему Lustre в качестве клиента. Используя liblustre, вычислительные процессоры могли получать доступ к файловой системе Lustre, даже если узел службы, на котором запускалось задание, не был клиентом Linux. Liblustre позволял перемещать данные напрямую между пространством приложения и системами OSS Lustre, не требуя промежуточного копирования данных через ядро, тем самым обеспечивая доступ вычислительных процессоров к файловой системе Lustre напрямую в ограниченной операционной среде. Функциональность liblustre была удалена из Lustre 2.7.0 после того, как была отключена с Lustre 2.6.0, и не тестировалась с Lustre 2.3.0.
В ядре Linux версии 4.18 неполный порт клиента Lustre был удален из области подготовки ядра, чтобы ускорить разработку и портирование на новые ядра. [84] Клиент и сервер Lustre вне ветки по-прежнему доступны для ядер дистрибутивов RHEL, SLES и Ubuntu , а также для ванильных ядер.
В традиционной файловой системе Unix на диске структура данных inode содержит основную информацию о каждом файле, например, где хранятся данные, содержащиеся в файле. Файловая система Lustre также использует inode, но inode в MDT указывают на один или несколько объектов OST, связанных с файлом, а не на блоки данных. Эти объекты реализованы как файлы в OST. Когда клиент открывает файл, операция открытия файла передает набор идентификаторов объектов и их макет из MDS клиенту, так что клиент может напрямую взаимодействовать с узлом(ами) OSS, которые содержат объект(ы). Это позволяет клиенту(ам) выполнять ввод-вывод параллельно по всем объектам OST в файле без дальнейшего взаимодействия с MDS, избегая конкуренции со стороны централизованного управления блоками и блокировками.
Если с inode 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 с помощью inode. Это снижает накладные расходы на доступ к небольшим файлам, как с точки зрения использования пространства (не требуется объект OST), так и с точки зрения использования сети (меньше RPC, необходимых для доступа к данным). DoM также повышает производительность для небольших файлов, если MDT основан на SSD , а OST основаны на дисках. В Lustre 2.13 функция OST Overstriping позволяет одному компоненту иметь несколько полос на одном OST для дальнейшего улучшения параллелизма блокировки, в то время как функция Self-Extending Layout позволяет размеру компонента быть динамическим во время записи, чтобы он мог справиться с отдельными (флэш) OST, заканчивающимися до того, как вся файловая система закончится.
Когда клиент изначально монтирует файловую систему, ему предоставляется 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 становится несбалансированным (более 5% разницы в свободном пространстве и inodes), то клиенты будут смещать создание нового подкаталога в сторону MDT с большим свободным пространством, чтобы восстановить баланс. [85]
Распределенный менеджер блокировок 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.
Связь между клиентами и серверами 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) [86] позволяет объединять два или более сетевых интерфейсов между клиентом и сервером для улучшения пропускной способности. Типы интерфейсов LNet не обязательно должны быть одного и того же типа сети. В версии 2.12 Multi-Rail был улучшен для повышения отказоустойчивости, если между одноранговыми узлами доступно несколько сетевых интерфейсов.
LNet обеспечивает сквозную пропускную способность по сетям Gigabit Ethernet свыше 100 МБ/с, [87] пропускную способность до 11 ГБ/с с использованием каналов InfiniBand с улучшенной скоростью передачи данных (EDR) и пропускную способность более 11 ГБ/с по интерфейсам 100 Gigabit Ethernet . [88]
Функции высокой доступности файловой системы Lustre включают надежный механизм отказоустойчивости и восстановления, что делает сбои и перезагрузки сервера прозрачными. Совместимость версий между последовательными второстепенными версиями программного обеспечения Lustre позволяет обновлять сервер, переводя его в автономный режим (или переключая его на резервный сервер), выполняя обновление и перезапуская его, в то время как все активные задания продолжают выполняться, испытывая задержку, пока резервный сервер берет на себя хранение.
Lustre MDS настроены как активная/пассивная пара, экспортирующая один MDT, или одна или несколько активных/активных пар MDS с DNE, экспортирующим два или более отдельных MDT, в то время как OSS обычно развертываются в активной/активной конфигурации, экспортируя отдельные OST для обеспечения избыточности без дополнительных системных издержек. В файловых системах с одним MDT резервный MDS для одной файловой системы — это узел MGS и/или мониторинга или активный MDS для другой файловой системы, поэтому в кластере нет простаивающих узлов.
Lustre предоставляет возможность иметь несколько уровней хранения в одном пространстве имен файловой системы. Он позволяет традиционной функциональности HSM копировать (архивировать) файлы из первичной файловой системы на вторичный уровень архивного хранения. Уровень архива обычно представляет собой ленточную систему, которая часто предваряется дисковым кэшем. После архивации файла его можно освободить из основной файловой системы, оставив только заглушку, которая ссылается на архивную копию. Если открыт освобожденный файл, координатор блокирует открытие, отправляет запрос на восстановление в copytool, а затем завершает открытие после того, как copytool завершит восстановление файла.
Помимо внешнего многоуровневого хранения, возможно иметь несколько уровней хранения в одном пространстве имен файловой системы. OST разных типов (например, HDD и SSD) можно объявлять в именованных пулах хранения. Пулы OST можно выбирать при указании макетов файлов, а разные пулы можно использовать в одном макете файла PFL. Файлы можно переносить между уровнями хранения вручную или под управлением Policy Engine. Начиная с Lustre 2.11, также можно зеркально отображать файл в разных пулах OST с макетом файла FLR, например, для предварительной подготовки файлов во флэш-памяти для вычислительного задания.
HSM включает в себя некоторые дополнительные компоненты Lustre для управления интерфейсом между первичной файловой системой и архивом:
HSM также определяет новые состояния для файлов, включая: [93]
Lustre используется многими суперкомпьютерами из TOP500 и крупными многокластерными сайтами. Шесть из 10 лучших и более 60 из 100 лучших суперкомпьютеров используют файловые системы Lustre. К ним относятся файловая система Orion 700PB 13 TB/s для суперкомпьютера Frontier в Национальной лаборатории Оук-Ридж (ORNL), [4] [94] Fugaku и K Computer [13] в Институте передовых вычислительных наук RIKEN, Tianhe -1A в Национальном суперкомпьютерном центре в Тяньцзине, Китай , LUMI в CSC , Jaguar и Titan в ORNL, Blue Waters в Иллинойсском университете , а также Sequoia и Blue Gene /L в Ливерморской национальной лаборатории им. Лоуренса (LLNL).
Также имеются крупные файловые системы Lustre в Национальном центре научных вычислений в области энергетики , Тихоокеанской северо-западной национальной лаборатории , Техасском передовом вычислительном центре , Бразильской национальной лаборатории научных вычислений [95] и NASA [96] в Северной Америке, в Азии в Токийском технологическом институте [97] в Европе в CEA [98] [ 99] и многих других.
Коммерческая техническая поддержка для Lustre часто идет в комплекте с вычислительной системой или оборудованием для хранения данных, продаваемым поставщиком. Некоторые поставщики включают Hewlett-Packard (как HP StorageWorks Scalable File Share, примерно с 2004 по 2008 год), [100] ATOS , Fujitsu . [101] Поставщики, продающие оборудование для хранения данных с пакетной поддержкой Lustre, включают Hitachi Data Systems (2012), [102] DataDirect Networks (DDN), [103] Aeon Computing и другие. Также возможно получить только программную поддержку для файловых систем Lustre от некоторых поставщиков, включая Whamcloud. [104]
Amazon Web Services предлагает Amazon FSx для Lustre [105] — полностью управляемый сервис, позволяющий легко и экономически эффективно запускать и эксплуатировать высокопроизводительные файловые системы в облаке.
Microsoft Azure предлагает Azure Managed Lustre (AMLFS) [106] . Azure Managed Lustre — это полностью управляемая файловая система с оплатой по факту использования для высокопроизводительных вычислений (HPC) и рабочих нагрузок ИИ в их облаке.
.svg/1280px-Free_and_open-source_software_logo_(2009).svg.png){kind=logo}
{{cite web}}: CS1 maint: несколько имен: список авторов ( ссылка ){{cite web}}: CS1 maint: несколько имен: список авторов ( ссылка ){{citation}}: CS1 maint: несколько имен: список авторов ( ссылка ){{cite web}}: CS1 maint: бот: исходный статус URL неизвестен ( ссылка )