Lustre (sistema de archivos)

Lustre es un tipo de sistema de archivos distribuido paralelo, generalmente utilizado para computación en clúster a gran escala . El nombre Lustre es una palabra compuesta derivada de Linux y clúster . ^{[ 4 ]} El software del sistema de archivos Lustre está disponible bajo la Licencia Pública General GNU (solo versión 2) y proporciona sistemas de archivos de alto rendimiento para clústeres de computadoras que varían en tamaño desde pequeños clústeres de grupos de trabajo hasta sistemas multisitio a gran escala. Desde junio de 2005, Lustre ha sido utilizado consistentemente por al menos la mitad de las diez mejores y más de 60 de las 100 supercomputadoras más rápidas del mundo, ^{[ 5 ] [ 6 ] [ 7 ]} incluyendo la supercomputadora número 1 del mundo en el TOP500 en noviembre de 2022, Frontier , ^{[ 2 ]} así como supercomputadoras anteriores de alto rendimiento como Fugaku , ^{[ 8 ] [ 9 ]} Titan ^{[ 10 ]} y Sequoia . ^{[ 11 ]}

Los sistemas de archivos Lustre son escalables y pueden formar parte de múltiples clústeres de computadoras con decenas de miles de nodos cliente , cientos de petabytes (PB) de almacenamiento en cientos de servidores y decenas de terabytes por segundo (TB/s) de rendimiento de E/S agregado . ^{[ 12 ] [ 13 ]} Esto convierte a los sistemas de archivos Lustre en una opción popular para empresas con grandes centros de datos, incluidas aquellas en industrias como la meteorología , ^{[ 14 ] [ 15 ]} simulación , inteligencia artificial y aprendizaje automático , ^{[ 16 ] [ 17 ]} petróleo y gas, ^{[ 18 ]} ciencias de la vida , ^{[ 19 ] [ 20 ]} rich media y finanzas. ^{[ 21 ]} El rendimiento de E/S de Lustre tiene un amplio impacto en estas aplicaciones y ha atraído una gran atención. ^{[ 22 ] [ 23 ] [ 24 ]}

La arquitectura del sistema de archivos Lustre se inició como un proyecto de investigación en 1999 por Peter J. Braam , quien era miembro del personal de la Universidad Carnegie Mellon (CMU) en ese momento. Braam pasó a fundar su propia empresa Cluster File Systems en 2001, ^{[ 25 ]} partiendo del trabajo en el sistema de archivos InterMezzo en el proyecto Coda en CMU. ^{[ 26 ]} Lustre se desarrolló bajo el proyecto Accelerated Strategic Computing Initiative Path Forward financiado por el Departamento de Energía de los Estados Unidos , que incluía a Hewlett-Packard e Intel . ^{[ 27 ]} En septiembre de 2007, Sun Microsystems adquirió los activos de Cluster File Systems Inc. incluyendo su "propiedad intelectual". ^{[ 28 ] [ 29 ]} Sun incluyó Lustre en sus ofertas de hardware de computación de alto rendimiento , con la intención de llevar las tecnologías de Lustre al sistema de archivos ZFS de Sun y al sistema operativo Solaris . En noviembre de 2008, Braam dejó Sun Microsystems, y Eric Barton y Andreas Dilger tomaron el control del proyecto. En 2010, Oracle Corporation , mediante la adquisición de Sun, comenzó a gestionar y distribuir Lustre.

En diciembre de 2010, Oracle anunció que cesaría el desarrollo de Lustre 2.x y que Lustre 1.8 pasaría a recibir solo soporte de mantenimiento, lo que generó incertidumbre sobre el futuro desarrollo del sistema de archivos. ^{[ 30 ]} Tras este anuncio, surgieron varias organizaciones nuevas para brindar soporte y desarrollo en un modelo de desarrollo comunitario abierto, incluyendo Whamcloud, ^{[ 31 ]} Open Scalable File Systems, Inc. (OpenSFS) , EUROPEAN Open File Systems (EOFS) y otras. A finales de 2010, la mayoría de los desarrolladores de Lustre habían abandonado Oracle. Braam y varios asociados se unieron a Xyratex, empresa orientada al hardware , cuando adquirió los activos de ClusterStor, ^{[ 32 ] [ 33 ]} mientras que Barton, Dilger y otros formaron la startup de software Whamcloud, donde continuaron trabajando en Lustre. ^{[ 34 ]}

En agosto de 2011, OpenSFS adjudicó un contrato para el desarrollo de características de Lustre a Whamcloud. ^{[ 35 ]} Este contrato cubría la finalización de características, incluyendo la mejora del escalado del rendimiento de metadatos de servidor único, que permite a Lustre aprovechar mejor el servidor de metadatos de muchos núcleos; la comprobación en línea del sistema de archivos distribuido de Lustre (LFSCK), que permite la verificación del estado del sistema de archivos distribuido entre los servidores de datos y metadatos mientras el sistema de archivos está montado y en uso; y el Entorno de espacio de nombres distribuido (DNE), anteriormente Metadatos agrupados (CMD), que permite que los metadatos de Lustre se distribuyan entre varios servidores. El desarrollo también continuó en el almacenamiento de objetos de back-end basado en ZFS en el Laboratorio Nacional Lawrence Livermore . ^{[ 11 ]} Estas características estaban en la hoja de ruta de lanzamiento de la comunidad de Lustre 2.2 a 2.4. ^{[ 36 ]} En noviembre de 2011, se adjudicó un contrato separado a Whamcloud para el mantenimiento del código fuente de Lustre 2.x para garantizar que el código de Lustre recibiera suficientes pruebas y corrección de errores mientras se desarrollaban nuevas características. ^{[ 37 ]}

En julio de 2012, Whamcloud fue adquirida por Intel , ^{[ 38 ] [ 39 ]} después de que Whamcloud ganara el contrato FastForward del Departamento de Energía para preparar Lustre para su uso con sistemas de computación de exaescala en el plazo de 2018. ^{[ 40 ]} OpenSFS luego transfirió los contratos para el desarrollo de Lustre a Intel.

En febrero de 2013, Xyratex Ltd. anunció que adquirió la marca registrada, el logotipo, el sitio web y la propiedad intelectual asociada de Lustre de Oracle. ^{[ 32 ]} En junio de 2013, Intel comenzó a expandir el uso de Lustre más allá de la HPC tradicional, como dentro de Hadoop . ^{[ 41 ]} Para 2013 en su conjunto, OpenSFS anunció una solicitud de propuestas (RFP) para cubrir el desarrollo de características de Lustre, herramientas de sistemas de archivos paralelos , abordar la deuda técnica de Lustre e incubadoras de sistemas de archivos paralelos. ^{[ 42 ]} OpenSFS también estableció el Portal de la Comunidad Lustre, un sitio técnico que proporciona una colección de información y documentación en un área para referencia y orientación para apoyar a la comunidad de código abierto de Lustre . El 8 de abril de 2014, Ken Claffey anunció que Xyratex/Seagate estaba donando el dominio lustre.org de vuelta a la comunidad de usuarios, ^{[ 43 ]} y esto se completó en marzo de 2015.

En junio de 2018, el equipo y los activos de Lustre fueron adquiridos a Intel por DDN . DDN organizó la nueva adquisición como una división independiente, recuperando el nombre de Whamcloud para la nueva división. ^{[ 44 ]}

En noviembre de 2019, OpenSFS y EOFS anunciaron en el SC19 Lustre BOF que la marca registrada Lustre les había sido transferida conjuntamente por Seagate . ^{[ 45 ]}

El sistema de archivos Lustre se instaló por primera vez para uso de producción en marzo de 2003 en el clúster Linux MCR del Laboratorio Nacional Lawrence Livermore , ^{[ 46 ]} la tercera supercomputadora más grande en la lista Top500 en ese momento. ^{[ 47 ]}

Lustre 1.0.0 se lanzó en diciembre de 2003, ^{[ 1 ]} y proporcionó la funcionalidad básica del sistema de archivos Lustre, incluyendo la conmutación por error y la recuperación del servidor.

Lustre 1.2.0, lanzado en marzo de 2004, funcionaba con el kernel de Linux 2.6 y tenía una función de "vistazo de tamaño" para evitar la revocación de bloqueos en archivos que se estaban escribiendo, y contabilidad de caché de escritura diferida de datos del lado del cliente (grant).

Lustre 1.4.0, lanzado en noviembre de 2004, proporcionaba compatibilidad de protocolo entre versiones, podía usar redes InfiniBand y podía aprovechar las extensiones/mballoc en el sistema de archivos en disco ldiskfs .

Lustre 1.6.0, lanzado en abril de 2007, permitía la configuración de montaje ("mountconf"), lo que permitía configurar los servidores con "mkfs" y "mount", permitía la adición dinámica de destinos de almacenamiento de objetos (OST), habilitaba la escalabilidad del administrador de bloqueo distribuido de Lustre (LDLM) en servidores de multiprocesamiento simétrico (SMP) y proporcionaba gestión del espacio libre para la asignación de objetos.

Lustre 1.8.0, lanzado en mayo de 2009, proporcionó caché de lectura OSS, mejoró la recuperación ante múltiples fallos, añadió gestión básica de almacenamiento heterogéneo mediante grupos OST, tiempos de espera de red adaptativos y recuperación basada en versiones. Fue una versión de transición, interoperable con Lustre 1.6 y Lustre 2.0. ^{[ 48 ]}

Lustre 2.0, lanzado en agosto de 2010, se basó en una importante reestructuración interna del código para prepararse para los avances arquitectónicos más importantes. Los clientes de Lustre 2.x no pueden interoperar con servidores 1.8 o anteriores . Sin embargo, los clientes de Lustre 1.8.6 y posteriores sí pueden interoperar con servidores Lustre 2.0 y posteriores. El formato de disco Metadata Target (MDT) y OST de la versión 1.8 se puede actualizar a la versión 2.0 y posteriores sin necesidad de reformatear el sistema de archivos.

Lustre 2.1, lanzado en septiembre de 2011, fue una iniciativa de toda la comunidad en respuesta a la suspensión del desarrollo de las versiones Lustre 2.x por parte de Oracle. ^{[ 49 ]} Añadió la capacidad de ejecutar servidores en Red Hat Linux 6 y aumentó el tamaño máximo de OST basado en ext4 de 24  TB a 128  TB, ^{[ 50 ]} así como una serie de mejoras de rendimiento y estabilidad. Los servidores Lustre 2.1 siguieron siendo interoperables con los clientes 1.8.6 y posteriores.

Lustre 2.2, lanzado en marzo de 2012, se centró en proporcionar mejoras en el rendimiento de los metadatos y nuevas características. ^{[ 51 ]} Añadió operaciones de directorio paralelas que permiten a varios clientes recorrer y modificar un único directorio grande simultáneamente, una recuperación más rápida de fallos del servidor, un mayor número de franjas para un solo archivo (en hasta 2000 OST) y un rendimiento mejorado de recorrido de directorio de un solo cliente.

Lustre 2.3, lanzado en octubre de 2012, continuó mejorando el código del servidor de metadatos para eliminar los cuellos de botella de bloqueo interno en nodos con muchos núcleos de CPU (más de 16). El almacén de objetos agregó una capacidad preliminar para usar ZFS como sistema de archivos de respaldo. La función Lustre File System ChecK (LFSCK) puede verificar y reparar el índice de objetos MDS (OI) mientras el sistema de archivos está en uso, después de una copia de seguridad/restauración a nivel de archivo o en caso de corrupción de MDS. Las estadísticas de E/S del lado del servidor se mejoraron para permitir la integración con planificadores de trabajos por lotes como SLURM para realizar un seguimiento de las estadísticas por trabajo. El software del lado del cliente se actualizó para funcionar con kernels de Linux hasta la versión 3.0.

Lustre 2.4, lanzado en mayo de 2013, añadió una cantidad considerable de características importantes, muchas financiadas directamente a través de OpenSFS . El Entorno de Espacio de Nombres Distribuido (DNE) permite la escalabilidad horizontal de la capacidad de metadatos y el rendimiento para los clientes 2.4, al permitir que los árboles de subdirectorios de un único espacio de nombres se ubiquen en MDT separados. ZFS ahora se puede usar como sistema de archivos de respaldo tanto para el almacenamiento MDT como OST. La característica LFSCK agregó la capacidad de escanear y verificar la consistencia interna de los atributos FID y LinkEA de MDT. El Planificador de Solicitudes de Red ^{[ 52 ] [ 53 ]} (NRS) agrega políticas para optimizar el procesamiento de solicitudes de clientes para el ordenamiento de discos o la equidad. Los clientes pueden enviar opcionalmente RPC masivos de hasta 4  MB de tamaño. El software del lado del cliente se actualizó para funcionar con kernels de Linux hasta la versión 3.6, y sigue siendo interoperable con clientes 1.8.

Lustre 2.5, lanzado en octubre de 2013, incorporó la esperada función de Gestión de Almacenamiento Jerárquico (HSM). HSM, un requisito fundamental en entornos empresariales, permite a los clientes implementar fácilmente soluciones de almacenamiento por niveles en su entorno operativo. Esta versión es la rama de lanzamiento de mantenimiento designada por OpenSFS para Lustre. ^{[ 54 ] [ 55 ] [ 56 ] [ 57 ]} La versión de mantenimiento más reciente es la 2.5.3, lanzada en septiembre de 2014. ^{[ 58 ]}

Lustre 2.6, lanzado en julio de 2014, ^{[ 59 ]} fue un lanzamiento más modesto en cuanto a características, agregando la funcionalidad LFSCK para realizar comprobaciones de consistencia local en el OST, así como comprobaciones de consistencia entre objetos MDT y OST. Se agregó la política NRS Token Bucket Filter ^{[ 60 ]} (TBF). El rendimiento de E/S de un solo cliente mejoró con respecto a las versiones anteriores. ^{[ 61 ]} Este lanzamiento también agregó una vista previa de directorios con franjas DNE, lo que permite almacenar directorios grandes individuales en múltiples MDT para mejorar el rendimiento y la escalabilidad.

Lustre 2.7, lanzado en marzo de 2015, ^{[ 62 ]} agregó la funcionalidad LFSCK para verificar la coherencia DNE de los directorios remotos y distribuidos entre múltiples MDT. Dynamic LNet Config agrega la capacidad de configurar y modificar las interfaces de red, las rutas y los enrutadores de LNet en tiempo de ejecución. Se agregó una nueva función de evaluación para la asignación de UID / GID para clientes con diferentes dominios administrativos, junto con mejoras a la funcionalidad de directorio distribuido DNE.

Lustre 2.8, lanzado en marzo de 2016, ^{[ 63 ]} finalizó la función de directorio con franjas DNE, incluyendo soporte para migrar directorios entre MDT, y enlaces duros y renombrados entre MDT. Además, incluyó soporte mejorado para Security-Enhanced Linux ( SELinux ) en el cliente, autenticación Kerberos y cifrado RPC a través de la red, y mejoras de rendimiento para LFSCK.

Lustre 2.9 se lanzó en diciembre de 2016 ^{[ 64 ]} e incluyó varias características relacionadas con la seguridad y el rendimiento. El tipo de seguridad de clave secreta compartida utiliza el mismo mecanismo GSSAPI que Kerberos para proporcionar autenticación de nodos cliente y servidor, e integridad y seguridad (cifrado) de mensajes RPC. La función Nodemap permite categorizar los nodos cliente en grupos y luego asignar el UID/GID para esos clientes, lo que permite a los clientes administrados remotamente usar de forma transparente un sistema de archivos compartido sin tener un único conjunto de UID/GID para todos los nodos cliente. La función de montaje de subdirectorios permite a los clientes montar un subconjunto del espacio de nombres del sistema de archivos desde el MDS. Esta versión también agregó soporte para  RPC de hasta 16 MiB para un envío de E/S más eficiente al disco, y agregó la ladviseinterfaz para permitir que los clientes proporcionen sugerencias de E/S a los servidores para precargar datos de archivos en la caché del servidor o vaciar datos de archivos de la caché del servidor. Se mejoró la compatibilidad para especificar grupos OST predeterminados para todo el sistema de archivos, así como la herencia de grupos OST junto con otros parámetros de diseño de archivos, y se aumentó el tamaño máximo admitido de OST de ldiskfs a 256 TiB.

Lustre 2.10 se lanzó en julio de 2017 ^{[ 65 ]} y tiene una serie de mejoras significativas. La función LNet Multi-Rail (LMR) permite combinar múltiples interfaces de red ( InfiniBand , Omni-Path y/o Ethernet ) en un cliente y un servidor para aumentar el ancho de banda de E/S agregado. Los archivos individuales pueden usar diseños de archivos compuestos que se construyen a partir de múltiples componentes, que son regiones de archivos basadas en el desplazamiento del archivo, que permiten diferentes parámetros de diseño como el número de franjas, el grupo OST/tipo de almacenamiento, etc. El diseño de archivos progresivo (PFL) es la primera función en usar diseños compuestos, pero la implementación es flexible para usar con otros diseños de archivos como la duplicación y la codificación de borrado. El planificador del lado del servidor NRS Token Bucket Filter (TBF) ha implementado nuevos tipos de reglas, incluida la planificación de tipo RPC y la capacidad de especificar múltiples parámetros como JobID y NID para la coincidencia de reglas. Se han añadido herramientas para gestionar instantáneas ZFS de sistemas de archivos Lustre, con el fin de simplificar la creación, el montaje y la gestión de instantáneas ZFS MDT y OST como puntos de montaje Lustre independientes . El tamaño máximo admitido para OST de ldiskfs se ha aumentado a 512 TiB.

Lustre 2.11 se lanzó en abril de 2018 ^{[ 66 ]} y contiene dos características nuevas importantes, y varias características menores. La característica Redundancia a nivel de archivo (FLR) amplía la implementación PFL 2.10, agregando la capacidad de especificar diseños de archivos duplicados para mejorar la disponibilidad en caso de falla de almacenamiento o servidor y/o mejorar el rendimiento con lecturas altamente concurrentes. La característica Data-on-MDT (DoM) permite almacenar archivos pequeños (pocos MiB) en el MDT para aprovechar el almacenamiento RAID-10 típico basado en flash para una latencia más baja y una contención de E/S reducida, en lugar del almacenamiento RAID-6 HDD típico utilizado en OST. Además, la característica LNet Dynamic Discovery permite la autoconfiguración de LNet Multi-Rail entre pares que comparten una red LNet. La función LDLM Lock Ahead permite que las aplicaciones y bibliotecas modificadas adecuadamente obtengan previamente los bloqueos de extensión DLM de los OST para los archivos, si la aplicación sabe (o predice) que esta extensión de archivo se modificará en un futuro próximo, lo que puede reducir la contención de bloqueos para varios clientes que escriben en el mismo archivo.

Lustre 2.12 se lanzó el 21 de diciembre de 2018 ^{[ 67 ]} y se centró en mejorar la usabilidad y la estabilidad de Lustre, con mejoras en el rendimiento y la funcionalidad de las características FLR y DoM añadidas en Lustre 2.11, así como cambios menores en NRS TBF , HSM y JobStats. Añadió LNet Network Health Archived 2019-02-12 en Wayback Machine para permitir que la característica LNet Multi-Rail de Lustre 2.10 maneje mejor las fallas de red cuando un nodo tiene múltiples interfaces de red. La característica Lazy Size on MDT ^{[ 68 ]} (LSOM) permite almacenar una estimación del tamaño del archivo en el MDT para que la utilicen los motores de políticas, los escáneres del sistema de archivos y otras herramientas de administración que pueden tomar decisiones más eficientes sobre los archivos sin un tamaño de archivo o recuento de bloques completamente preciso sin tener que consultar los OST para obtener esta información. Esta versión también agregó la capacidad de redistribuir manualmente un directorio existente en varios MDT, para permitir la migración de directorios con gran cantidad de archivos para usar la capacidad y el rendimiento de varios nodos MDS. La suma de verificación de datos RPC de Lustre agregó sumas de verificación de datos integradas SCSI T10-PI ^{[ 69 ]} desde el cliente a la capa de bloques del kernel, el adaptador de host SCSI y las unidades duras habilitadas para T10 .

Lustre 2.13 se lanzó el 5 de diciembre de 2019 ^{[ 70 ]} y agregó nuevas características relacionadas con el rendimiento: Persistent Client Cache ^{[ 71 ]} (PCC), que permite el uso directo del almacenamiento NVMe y NVRAM en los nodos del cliente mientras mantiene los archivos como parte del espacio de nombres del sistema de archivos global, y OST Overstriping ^{[ 72 ]} que permite que los archivos almacenen múltiples franjas en un solo OST para aprovechar mejor el hardware OSS rápido. Además, la funcionalidad LNet Multi-Rail Network Health se mejoró para que funcione con los nodos del enrutador LNet RDMA. La funcionalidad PFL se mejoró con Self-Extending Layouts ^{[ 73 ]} (SEL) para permitir que los componentes de archivo tengan un tamaño dinámico, para manejar mejor los OST flash que pueden ser mucho más pequeños que los OST de disco dentro del mismo sistema de archivos. La versión también incluyó una serie de mejoras menores, como el equilibrio de la creación de directorios remotos DNE entre MDT, el uso de Lazy-size-on-MDT para reducir la sobrecarga de "lfs find", directorios con 10M archivos por fragmento para ldiskfs y tamaños de RPC masivos de hasta 64  MB. ^{[ 74 ]}

Lustre 2.14 se lanzó el 19 de febrero de 2021 ^{[ 75 ]} e incluye tres características principales. El cifrado de datos del cliente implementa fscrypt para permitir que los datos de los archivos se cifren en el cliente antes de la transferencia de red y el almacenamiento persistente en el OST y el MDT. Las cuotas de grupo de OST extienden el marco de cuotas para permitir la asignación y aplicación de cuotas en función de los grupos de almacenamiento de OST, y el tamaño máximo admitido de ldiskfs OST se aumentó a 1024 TiB. El rediseño automático de DNE ahora puede ajustar en cuántos MDT se distribuye un directorio grande en función de los umbrales de tamaño definidos por el administrador, de forma similar a los diseños de archivos progresivos para directorios.

Lustre 2.15 se lanzó el 16 de junio de 2022 ^{[ 76 ]} e incluye tres características principales. El cifrado de directorio del cliente ^{[ 77 ]} amplía el cifrado de datos fscrypt de la versión 2.14 para permitir también que los nombres de archivos y directorios se cifren en el cliente antes de la transferencia de red y el almacenamiento persistente en el MDT. El balanceo de espacio DNE MDT equilibra automáticamente la creación de nuevos directorios entre los MDT en el sistema de archivos en round-robin y/o en función de los inodos y el espacio disponibles, lo que a su vez ayuda a distribuir la carga de trabajo de metadatos del cliente entre los MDT de manera más uniforme. Para las aplicaciones que utilizan la interfaz NVIDIA GPU Direct Storage (GDS), el cliente Lustre puede realizar lectura y escritura RDMA de copia cero desde el servidor de almacenamiento directamente en la memoria de la GPU para evitar una copia de datos adicional de la memoria de la CPU y una sobrecarga de procesamiento adicional. ^{[ 78 ]} La política de selección definida por el usuario (UDSP) permite establecer políticas de selección de interfaz para nodos con múltiples interfaces de red.

Lustre 2.16 se lanzó el 8 de noviembre de 2024 ^{[ 79 ]} e incluye tres características principales. La compatibilidad con direcciones de red grandes ^{[ 80 ]} permite usar IPv6 y potencialmente otros formatos de direcciones grandes como GUID de Infiniband para el direccionamiento de nodos cliente y servidor, además de las direcciones IPv4 estándar . La característica de E/S directa híbrida y no alineada mejora el rendimiento para aplicaciones que realizan grandes operaciones de lectura/escritura con búfer y directas al evitar la sobrecarga en la caché de páginas del cliente. ^{[ 81 ]} La característica de recorrido de directorio optimizado (statahead por lotes) mejora las cargas de trabajo de las aplicaciones que recorren jerarquías de directorios y acceden a atributos de archivos en un patrón de acceso sistemático mediante la precarga de atributos de archivos en paralelo desde el/los MDS usando RPC masivos. ^{[ 82 ]}

Lustre 2.17 se lanzó el 28 de diciembre de 2025 ^{[ 83 ]} e incluye tres características principales, junto con numerosas otras mejoras. La configuración dinámica de NID permite a los servidores configurar y anunciar interfaces de red efímeras a los clientes en redes virtuales ( VLAN ) sin tener que cambiar permanentemente la configuración ni interrumpir los servicios en ejecución. Las mejoras en los Nodemaps simplifican el aislamiento de clientes y proporcionan controles adicionales de grano fino sobre el acceso de los clientes, permiten exportar múltiples conjuntos de archivos (opcionalmente de solo lectura) por nodemap e incluyen la segregación de permisos de root dentro de un nodemap. ^{[ 84 ]} Estas características son útiles para la virtualización de sistemas de archivos en entornos de computación en la nube y compartida. Las mejoras en la implementación de E/S híbrida mejoran el rendimiento y la flexibilidad para aplicaciones que realizan grandes cantidades de E/S.

Un sistema de archivos Lustre tiene tres unidades funcionales principales:

• Uno o más nodos de servidores de metadatos (MDS) que tienen uno o más dispositivos de destino de metadatos (MDT) por sistema de archivos Lustre que almacenan metadatos de espacio de nombres, como nombres de archivo, directorios, permisos de acceso y diseño de archivos. Los datos MDT se almacenan en un sistema de archivos de disco local. Sin embargo, a diferencia de los sistemas de archivos distribuidos basados ​​en bloques, como GPFS y PanFS , donde el servidor de metadatos controla toda la asignación de bloques, el servidor de metadatos de Lustre solo participa en comprobaciones de nombres de ruta y permisos, y no participa en ninguna operación de E/S de archivos , evitando cuellos de botella de escalabilidad de E/S en el servidor de metadatos. La capacidad de tener múltiples MDT en un solo sistema de archivos es una nueva característica en Lustre 2.4, y permite que los subárboles de directorios residan en los MDT secundarios, mientras que 2.7 y posteriores permiten que directorios únicos grandes se distribuyan también entre múltiples MDT.
• Uno o más nodos de servidor de almacenamiento de objetos (OSS) que almacenan datos de archivos en uno o más dispositivos de destino de almacenamiento de objetos (OST) . Según el hardware del servidor, un OSS suele dar servicio a entre dos y ocho OST, y cada OST gestiona un único sistema de archivos de disco local. La capacidad de un sistema de archivos Lustre es la suma de las capacidades proporcionadas por los OST.
• Clientes que acceden y utilizan los datos. Lustre ofrece a todos los clientes un espacio de nombres unificado para todos los archivos y datos del sistema de archivos, utilizando la semántica POSIX estándar , y permite el acceso concurrente y coherente de lectura y escritura a los archivos del sistema de archivos.

El MDT, el OST y el cliente pueden estar en el mismo nodo (generalmente para fines de prueba), pero en instalaciones de producción típicas estos dispositivos están en nodos separados que se comunican a través de una red. Cada MDT y OST puede ser parte de un solo sistema de archivos, aunque es posible tener varios MDT u OST en un solo nodo que sean parte de diferentes sistemas de archivos. La capa de red Lustre (LNet) puede usar varios tipos de interconexiones de red, incluidos verbos nativos de InfiniBand , Omni-Path , RoCE e iWARP a través de OFED , TCP/IP en Ethernet y otras tecnologías de red propietarias como la interconexión Cray Gemini. En Lustre 2.3 y versiones anteriores, también se admitían las redes Myrinet , Quadrics , Cray SeaStar y RapidArray, pero estos controladores de red quedaron obsoletos cuando estas redes dejaron de estar disponibles comercialmente, y la compatibilidad se eliminó por completo en Lustre 2.8. Lustre aprovechará las transferencias de acceso directo a memoria remota ( RDMA ), cuando estén disponibles, para mejorar el rendimiento y reducir el uso de la CPU.

El almacenamiento utilizado para los sistemas de archivos de respaldo MDT y OST normalmente se proporciona mediante dispositivos RAID de hardware , aunque también funciona con cualquier dispositivo de bloques. Desde Lustre 2.4, MDT y OST también pueden usar ZFS como sistema de archivos de respaldo, además de ext4 , lo que les permite usar almacenamiento JBOD en lugar de dispositivos RAID de hardware. Los servidores Lustre OSS y MDS leen, escriben y modifican datos en el formato impuesto por el sistema de archivos de respaldo y devuelven estos datos a los clientes. Esto permite a Lustre aprovechar las mejoras y características del sistema de archivos subyacente, como la compresión y las sumas de verificación de datos en ZFS. Los clientes no tienen acceso directo al almacenamiento subyacente, lo que garantiza que un cliente defectuoso o malicioso no pueda corromper la estructura del sistema de archivos.

Un OST es un sistema de archivos dedicado que exporta una interfaz a rangos de bytes de objetos de archivo para operaciones de lectura/escritura, con bloqueos de extensión para proteger la consistencia de los datos. Un MDT es un sistema de archivos dedicado que almacena inodos, directorios, atributos de archivo POSIX y extendidos , controla los permisos de acceso a archivos/ ACL y les indica a los clientes la estructura de los objetos que componen cada archivo regular. Los MDT y OST actualmente utilizan una versión mejorada de ext4 llamada ldiskfs , o ZFS /DMU para el almacenamiento de datos de back-end para almacenar archivos/objetos ^{[ 85 ]} utilizando el puerto de código abierto ZFS-on-Linux. ^{[ 86 ]}

El cliente monta el sistema de archivos Lustre localmente con un controlador VFS para el kernel de Linux que conecta al cliente con el/los servidor/es. Al montarse inicialmente, se le proporciona al cliente un identificador de archivo (FID) para el directorio raíz del punto de montaje. Cuando el cliente accede a un archivo, realiza una búsqueda del nombre de archivo en el MDS . Una vez completada la búsqueda del nombre de archivo en el MDS y si el usuario y el cliente tienen permiso para acceder o crear el archivo, se devuelve al cliente la estructura de un archivo existente o se crea un nuevo archivo en nombre del cliente, si así lo solicita. Para las operaciones de lectura o escritura, el cliente interpreta la estructura del archivo en la capa de volumen de objeto lógico (LOV) , que asigna el desplazamiento lógico y el tamaño del archivo a uno o más objetos . A continuación, el cliente bloquea el rango de archivos en el que se está operando y ejecuta una o más operaciones paralelas de lectura o escritura directamente en los nodos OSS que contienen los objetos de datos. Con este enfoque, se eliminan los cuellos de botella en las comunicaciones entre el cliente y el OSS, por lo que el ancho de banda total disponible para que los clientes lean y escriban datos aumenta de forma casi lineal con el número de OST en el sistema de archivos.

Tras la búsqueda inicial de la estructura de archivos, el MDS normalmente no interviene en las operaciones de E/S de archivos, ya que la asignación de bloques y la E/S de datos se gestionan internamente mediante el OST. Los clientes no modifican directamente los objetos ni los datos en los sistemas de archivos del OST, sino que delegan esta tarea a los nodos OSS. Este enfoque garantiza la escalabilidad para clústeres y supercomputadoras de gran tamaño, así como una mayor seguridad y fiabilidad. En cambio, los sistemas de archivos compartidos basados ​​en bloques, como GPFS y OCFS, permiten el acceso directo al almacenamiento subyacente por parte de todos los clientes del sistema de archivos, lo que requiere una gran SAN de back-end conectada a todos los clientes y aumenta el riesgo de corrupción del sistema de archivos por parte de clientes defectuosos o con un comportamiento anómalo.

En una instalación típica de Lustre en un cliente Linux, se carga un módulo controlador del sistema de archivos de Lustre en el kernel y el sistema de archivos se monta como cualquier otro sistema de archivos local o de red. Las aplicaciones cliente ven un único sistema de archivos unificado, aunque este pueda estar compuesto por decenas o miles de servidores individuales y sistemas de archivos MDT/OST.

En algunas instalaciones de procesadores masivamente paralelos (MPP), los procesadores computacionales pueden acceder a un sistema de archivos Lustre redirigiendo sus solicitudes de E/S a un nodo de E/S dedicado configurado como cliente Lustre. Este enfoque se utiliza en la instalación Blue Gene ^{[ 87 ]} en el Laboratorio Nacional Lawrence Livermore .

Otro enfoque utilizado en los primeros años de Lustre fue la biblioteca liblustre en el Cray XT3 usando el sistema operativo Catamount en sistemas como Sandia Red Storm , ^{[ 88 ]} que proporcionaba a las aplicaciones de espacio de usuario acceso directo al sistema de archivos. Liblustre era una biblioteca de nivel de usuario que permitía a los procesadores computacionales montar y usar el sistema de archivos Lustre como cliente. Usando liblustre, los procesadores computacionales podían acceder a un sistema de archivos Lustre incluso si el nodo de servicio en el que se ejecutaba el trabajo no era un cliente Linux. Liblustre permitía el movimiento de datos directamente entre el espacio de la aplicación y los OSS de Lustre sin requerir una copia de datos intermedia a través del kernel, proporcionando así acceso de los procesadores computacionales al sistema de archivos Lustre directamente en un entorno operativo restringido. La funcionalidad de liblustre se eliminó de Lustre 2.7.0 después de haber sido deshabilitada desde Lustre 2.6.0, y no se probó desde Lustre 2.3.0.

En la versión 4.18 del kernel de Linux, la adaptación incompleta del cliente Lustre se eliminó del área de pruebas del kernel para acelerar el desarrollo y la adaptación a kernels más recientes. ^{[ 89 ]} El cliente y el servidor Lustre fuera del árbol de código fuente siguen estando disponibles para los kernels de las distribuciones RHEL, SLES y Ubuntu , así como para los kernels estándar.

En un sistema de archivos de disco Unix tradicional, una estructura de datos de inodo contiene información básica sobre cada archivo, como la ubicación de los datos que contiene. El sistema de archivos Lustre también utiliza inodos, pero en los MDT, los inodos apuntan a uno o más objetos OST asociados al archivo, en lugar de a bloques de datos. Estos objetos se implementan como archivos en los OST. Cuando un cliente abre un archivo, la operación de apertura transfiere un conjunto de identificadores de objeto y su disposición desde el MDS al cliente, de modo que este pueda interactuar directamente con los nodos OSS que contienen los objetos. Esto permite que el cliente realice operaciones de E/S en paralelo en todos los objetos OST del archivo sin necesidad de comunicarse con el MDS, evitando así la contención derivada de la gestión centralizada de bloques y bloqueos.

Si solo un objeto OST está asociado a un inodo MDT, ese objeto contiene todos los datos del archivo Lustre. Cuando hay más de un objeto asociado a un archivo, los datos del archivo se distribuyen en fragmentos de forma rotativa entre los objetos OST, de manera similar a RAID 0, en fragmentos que suelen ser de 1  MB o más. La distribución de un archivo entre varios objetos OST proporciona importantes ventajas de rendimiento si se necesita un acceso de alto ancho de banda a un único archivo grande. Cuando se utiliza la distribución, el tamaño máximo del archivo no está limitado por el tamaño de un único destino. La capacidad y el ancho de banda de E/S agregado aumentan con el número de OST en los que se distribuye un archivo. Además, dado que el bloqueo de cada objeto se gestiona de forma independiente para cada OST, añadir más franjas (una por OST) aumenta proporcionalmente la capacidad de bloqueo de E/S del archivo. Cada archivo creado en el sistema de archivos puede especificar diferentes parámetros de diseño, como el número de franjas (cantidad de objetos OST que componen el archivo), el tamaño de la franja (unidad de datos almacenados en cada OST antes de pasar al siguiente) y la selección de OST, de modo que el rendimiento y la capacidad se puedan optimizar para cada archivo. Cuando varios subprocesos de la aplicación leen o escriben en archivos separados en paralelo, lo óptimo es tener una sola franja por archivo, ya que la aplicación proporciona su propio paralelismo. Cuando varios subprocesos leen o escriben simultáneamente en un único archivo grande, lo óptimo es tener al menos una franja en cada OST para maximizar el rendimiento y la capacidad de dicho archivo.

En la versión Lustre 2.10, se agregó la capacidad de especificar diseños compuestos para permitir que los archivos tengan diferentes parámetros de diseño para diferentes regiones del archivo. La función Diseño de Archivo Progresivo (PFL) utiliza diseños compuestos para mejorar el rendimiento de E/S de archivos en una gama más amplia de cargas de trabajo, así como para simplificar el uso y la administración. Por ejemplo, un archivo PFL pequeño puede tener una sola franja en la memoria flash para una baja sobrecarga de acceso, mientras que los archivos más grandes pueden tener muchas franjas para un ancho de banda agregado alto y un mejor equilibrio de carga OST. Los diseños compuestos se mejoraron aún más en la versión 2.11 con la función Redundancia a Nivel de Archivo (FLR), que permite que un archivo tenga múltiples diseños superpuestos, proporcionando redundancia RAID 0+1 para estos archivos, así como un rendimiento de lectura mejorado. La versión Lustre 2.11 también agregó la función Datos en Metadatos (DoM), que permite que el primer componente de un archivo PFL se almacene directamente en el MDT con el inodo. Esto reduce la sobrecarga para acceder a archivos pequeños, tanto en términos de uso de espacio (no se necesita ningún objeto OST) como de uso de red (se necesitan menos RPC para acceder a los datos). DoM también mejora el rendimiento para archivos pequeños si el MDT está basado en SSD , mientras que los OST están basados ​​en disco. En Lustre 2.13, la función de sobredistribución de OST permite que un solo componente tenga múltiples franjas en un OST para mejorar aún más el paralelismo del bloqueo, mientras que la función de diseño autoextensible permite que el tamaño del componente sea dinámico durante la escritura para que pueda gestionar que los OST individuales (flash) se queden sin espacio antes de que todo el sistema de archivos se quede sin espacio.

Cuando un cliente monta inicialmente un sistema de archivos, se le proporciona el identificador de archivo Lustre de 128 bits (FID, compuesto por el número de secuencia de 64 bits, el ID de objeto de 32 bits y la versión de 32 bits) del directorio raíz del punto de montaje. Al realizar una búsqueda de nombre de archivo, el cliente realiza una búsqueda de cada componente de la ruta asignando el número de secuencia FID del directorio padre a un MDT específico a través de la base de datos de ubicación FID (FLDB), y luego realiza una búsqueda en el MDS que administra este MDT utilizando el FID padre y el nombre de archivo. El MDS devolverá el FID para el componente de ruta solicitado junto con un bloqueo DLM . Una vez que se determina el MDT del último directorio en la ruta, las operaciones de directorio posteriores (para directorios no distribuidos) normalmente se realizarán en ese MDT, evitando la contención entre MDT.

Para los directorios con formato DNE, el diseño por directorio almacenado en el directorio padre proporciona una función hash y una lista de FID de directorio MDT a través de los cuales se distribuye el directorio. El Volumen de Metadatos Lógicos (LMV) en el cliente aplica un hash al nombre del archivo y lo asigna a una partición de directorio MDT específica , que gestionará las operaciones posteriores en ese archivo de manera idéntica a un directorio sin formato. Para las operaciones readdir() , las entradas de cada partición de directorio se devuelven al cliente ordenadas según el orden hash del directorio MDT local, y el cliente realiza una ordenación por fusión para intercalar los nombres de archivo en orden hash, de modo que se pueda utilizar una única cookie de 64 bits para determinar el desplazamiento actual dentro del directorio.

En Lustre 2.15, el cliente LMV implementa diseños de directorios predeterminados con balanceo de espacio y round-robin, de modo que los clientes puedan usar una gran cantidad de MDT en un solo sistema de archivos de manera más efectiva. Cuando se crea un nuevo subdirectorio cerca de la raíz del sistema de archivos (los tres niveles de directorio superiores por defecto), el cliente lo creará automáticamente como un directorio remoto en uno de los MDT disponibles (seleccionados en orden secuencial) para equilibrar el uso del espacio y la carga entre los servidores. Si el espacio libre en los MDT se desequilibra (diferencia superior al 5 % en espacio libre e inodos), el cliente que crea el directorio priorizará la creación hacia un MDT con más espacio libre para restablecer el equilibrio. ^{[ 90 ]}

El gestor de bloqueos distribuidos de Lustre (LDLM), implementado al estilo de OpenVMS , protege la integridad de los datos y metadatos de cada archivo. El acceso y la modificación de un archivo Lustre son completamente coherentes en caché entre todos los clientes. Los bloqueos de metadatos son gestionados por el MDT que almacena el inodo del archivo, utilizando el FID como nombre del recurso. Los bloqueos de metadatos se dividen en bits separados que protegen la búsqueda del archivo (propietario y grupo del archivo, permisos y modo, y lista de control de acceso (ACL)), el estado del inodo (tamaño del directorio, contenido del directorio, número de enlaces, marcas de tiempo), la estructura (striping de archivos, desde Lustre 2.4) y los atributos extendidos (xattrs, desde Lustre 2.5). Un cliente puede obtener varios bits de bloqueo de metadatos para un solo inodo con una sola solicitud RPC, pero actualmente solo se les concede un bloqueo de lectura para el inodo. El MDS gestiona todas las modificaciones del inodo para evitar la contención de recursos de bloqueo y actualmente es el único nodo que obtiene bloqueos de escritura en los inodos.

Los bloqueos de datos de archivos son gestionados por el OST en el que se distribuye cada objeto del archivo, utilizando bloqueos de extensión de rango de bytes . Se pueden otorgar a los clientes bloqueos de extensión de lectura superpuestos para una parte o la totalidad del archivo, lo que permite múltiples lectores concurrentes del mismo archivo, y/o bloqueos de extensión de escritura no superpuestos para regiones independientes del archivo. Esto permite que muchos clientes Lustre accedan a un único archivo simultáneamente para lectura y escritura, evitando cuellos de botella durante la E/S de archivos. En la práctica, dado que los clientes Linux gestionan su caché de datos en unidades de páginas , los clientes solicitarán bloqueos que siempre serán un múltiplo entero del tamaño de página (4096 bytes en la mayoría de los clientes). Cuando un cliente solicita un bloqueo de extensión, el OST puede otorgar un bloqueo para una extensión mayor que la solicitada originalmente, con el fin de reducir la cantidad de solicitudes de bloqueo que realiza el cliente. El tamaño real del bloqueo otorgado depende de varios factores, incluyendo la cantidad de bloqueos otorgados actualmente sobre ese objeto, si existen bloqueos de escritura conflictivos para la extensión de bloqueo solicitada y la cantidad de solicitudes de bloqueo pendientes sobre ese objeto. El bloqueo otorgado nunca es menor que la extensión solicitada originalmente. Los bloqueos de extensión OST utilizan el FID de Lustre del objeto como nombre del recurso para el bloqueo. Dado que el número de servidores de bloqueo de extensión aumenta con el número de OST en el sistema de archivos, esto también aumenta el rendimiento de bloqueo agregado del sistema de archivos y de un solo archivo si se distribuye entre varios OST.

La comunicación entre los clientes y servidores de Lustre se implementa mediante Lustre Networking (LNet), que originalmente se basaba en la interfaz de programación de aplicaciones (API) de programación de redes de Sandia Portals . El almacenamiento en disco se conecta a los nodos de servidor Lustre MDS y OSS mediante almacenamiento de conexión directa ( NVM_Express#NVMe-oF , SAS , FC , iSCSI ) o tecnologías de red de área de almacenamiento (SAN) tradicionales, que son independientes de la red cliente-servidor.

LNet puede utilizar muchos tipos de red comunes, como InfiniBand y Ethernet ( socket TCP en el puerto 988), y permite la disponibilidad simultánea en múltiples tipos de red con enrutamiento entre ellos. El acceso remoto directo a memoria (RDMA) se utiliza para la transferencia de datos y metadatos entre nodos cuando lo proporcionan las redes subyacentes, como InfiniBand Open Fabrics Enterprise Distribution (OFED Verbs), RoCE y Omni-Path , así como redes propietarias de alta velocidad como Cray Aries y Gemini, Atos BullSequana eXascale Interconnect ( BXI ) y Amazon Web Services Elastic Fabric Adapter ( EFA ). Las funciones de alta disponibilidad y recuperación permiten una recuperación transparente en conjunto con servidores de conmutación por error.

Desde Lustre 2.10, la función LNet Multi-Rail (MR) ^{[ 91 ]} permite la agregación de enlaces de dos o más interfaces de red entre un cliente y un servidor para mejorar el ancho de banda. Los tipos de interfaz LNet no necesitan ser del mismo tipo de red. En la versión 2.12, Multi-Rail se mejoró para aumentar la tolerancia a fallos si hay varias interfaces de red disponibles entre pares.

LNet proporciona un rendimiento de extremo a extremo sobre redes Gigabit Ethernet superior a 100  MB/s, ^{[ 92 ]} un rendimiento de hasta 11  GB/s utilizando enlaces InfiniBand de velocidad de datos mejorada (EDR) y un rendimiento superior a 11  GB/s a través de interfaces 100 Gigabit Ethernet . ^{[ 93 ]}

Las funciones de alta disponibilidad del sistema de archivos Lustre incluyen un sólido mecanismo de conmutación por error y recuperación, lo que hace que los fallos y reinicios del servidor sean transparentes. La interoperabilidad entre versiones menores sucesivas del software Lustre permite actualizar un servidor desconectándolo (o conmutándolo a un servidor de respaldo), realizando la actualización y reiniciándolo, mientras todos los trabajos activos continúan ejecutándose, experimentando un retraso mientras el servidor de respaldo toma el control del almacenamiento.

Los MDS de Lustre se configuran como un par activo/pasivo que exporta un único MDT, o como uno o más pares MDS activo/activo con DNE que exporta dos o más MDT separados, mientras que los OSS se implementan normalmente en una configuración activo/activo que exporta OST separados para proporcionar redundancia sin sobrecarga adicional del sistema. En los sistemas de archivos con un solo MDT, el MDS en espera para un sistema de archivos es el MGS o el nodo de monitorización, o el MDS activo para otro sistema de archivos, por lo que ningún nodo está inactivo en el clúster.

Lustre permite tener múltiples niveles de almacenamiento dentro de un mismo espacio de nombres de sistema de archivos. Permite que la funcionalidad HSM tradicional copie (archive) archivos del sistema de archivos principal a un nivel de almacenamiento de archivo secundario. Este nivel de archivo suele ser un sistema basado en cinta, a menudo con una caché de disco como prefijo. Una vez archivado un archivo, se puede liberar del sistema de archivos principal, dejando solo un fragmento que hace referencia a la copia archivada. Si se intenta abrir un archivo liberado, el Coordinador bloquea la apertura, envía una solicitud de restauración a una herramienta de copia y, una vez que esta ha finalizado la restauración, completa la apertura.

Además de la estratificación de almacenamiento externo, es posible tener múltiples niveles de almacenamiento dentro de un mismo espacio de nombres del sistema de archivos. Se pueden declarar OST de diferentes tipos (por ejemplo, HDD y SSD) en grupos de almacenamiento con nombre. Los grupos de OST se pueden seleccionar al especificar diseños de archivo, y se pueden usar diferentes grupos dentro de un mismo diseño de archivo PFL. Los archivos se pueden migrar entre niveles de almacenamiento de forma manual o bajo el control del motor de políticas. Desde Lustre 2.11, también es posible replicar un archivo en diferentes grupos de OST con un diseño de archivo FLR, por ejemplo, para precargar archivos en la memoria flash para una tarea de computación.

HSM incluye algunos componentes adicionales de Lustre para gestionar la interfaz entre el sistema de archivos principal y el archivo:

• Coordinador: recibe las solicitudes de archivo y restauración y las distribuye a los nodos de los agentes.
• Agente: ejecuta una herramienta de copia para copiar datos del almacenamiento principal al archivo y viceversa.
• Copytool: gestiona el movimiento de datos y las actualizaciones de metadatos. Existen diferentes copytools para interactuar con distintos sistemas de archivo. Hay un copytool POSIX genérico disponible para archivos que ofrecen una interfaz de usuario similar a POSIX. También hay copytools disponibles para el Sistema de Almacenamiento de Alto Rendimiento ^{[ 94 ]} (HPSS), Tivoli Storage Manager ^{[ 95 ]} (TSM), Amazon S3 ^{[ 96 ]} y Google Drive ^{[ 97 ]} .
• Motor de políticas: supervisa los registros de cambios del sistema de archivos en busca de nuevos archivos para archivar, aplica políticas para liberar archivos según su antigüedad o uso de espacio, y se comunica con MDT y el Coordinador. El motor de políticas también puede activar acciones como la migración, la purga y la eliminación. El motor de políticas más utilizado es RobinHood, ^{[ 98 ]} pero también se pueden usar otros.

HSM también define nuevos estados para archivos, incluidos: ^{[ 99 ]}

• Existe: Existe alguna copia, posiblemente incompleta, en un HSM.
• Archivo: Existe una copia completa en la sección de archivo del HSM.
• Sucio: La copia principal del archivo ha sido modificada y difiere de la copia archivada.
• Liberado: Existe un inodo stub en un MDT, pero los objetos de datos se han eliminado y la única copia existe en el archivo.
• Perdido: la copia de archivo del archivo se ha perdido y no se puede restaurar.
• Sin liberación: el archivo no debe liberarse del sistema de archivos.
• Sin archivo: el archivo no debe archivarse.

Lustre es utilizado por muchos de los TOP500 supercomputadores y grandes sitios multiclúster. Seis de los 10 mejores y más de 60 de los 100 mejores supercomputadores utilizan sistemas de archivos Lustre. Estos incluyen el  sistema de archivos Orion de 700PB y 13 TB/s para el supercomputador Frontier en el Laboratorio Nacional de Oak Ridge (ORNL), ^{[ 2 ] [ 100 ]} Fugaku y K Computer ^{[ 11 ]} en el Instituto Avanzado RIKEN para la Ciencia Computacional, Tianhe-1A en el Centro Nacional de Supercomputación en Tianjin, China , LUMI en CSC , Jaguar y Titan en ORNL, Blue Waters en la Universidad de Illinois y Sequoia y Blue Gene /L en el Laboratorio Nacional Lawrence Livermore (LLNL).

También hay grandes sistemas de archivos Lustre en el Centro Nacional de Computación Científica para la Investigación Energética , el Laboratorio Nacional del Noroeste del Pacífico , el Centro de Computación Avanzada de Texas , el Laboratorio Nacional Brasileño de Computación Científica, ^{[ 101 ]} y la NASA ^{[ 102 ]} en América del Norte, en Asia en el Instituto Tecnológico de Tokio , ^{[ 103 ]} en Europa en el CEA , ^{[ 104 ] [ 105 ]} y muchos otros.

El soporte técnico comercial para Lustre suele venir incluido con el sistema informático o el hardware de almacenamiento que vende el proveedor. Algunos proveedores son Hewlett-Packard (como HP StorageWorks Scalable File Share, aproximadamente entre 2004 y 2008), ^{[ 106 ]} ATOS y Fujitsu . ^{[ 107 ]} Entre los proveedores que venden hardware de almacenamiento con soporte para Lustre incluido se encuentran Hitachi Data Systems (2012), ^{[ 108 ]} DataDirect Networks (DDN), ^{[ 109 ]} Aeon Computing y otros. También es posible obtener soporte solo de software para sistemas de archivos Lustre de algunos proveedores, incluido Whamcloud. ^{[ 110 ]}

Amazon Web Services ofrece Amazon FSx para Lustre, ^{[ 111 ]} un servicio totalmente administrado, que facilita el lanzamiento y la ejecución de sistemas de archivos de alto rendimiento de forma rentable en su nube.

Microsoft Azure ofrece Azure Managed Lustre (AMLFS). ^{[ 112 ]} Azure Managed Lustre es un sistema de archivos totalmente administrado y de pago por uso para cargas de trabajo de computación de alto rendimiento (HPC) e IA en su nube.

• Lista de sistemas de archivos, la sección de sistemas de archivos distribuidos, paralelos y tolerantes a fallos

• Lustre en GitHub