Lustre (sistema de archivos)
Sistema de archivos distribuido en paralelo
Lanzamiento inicial16 de diciembre de 2003 ; hace 20 años [1] ( 16 de diciembre de 2003 )
Versión estable
2.15.0 (última versión principal), [2]

2.15.5 (última versión de mantenimiento), [3]

/ 28 de junio de 2024 ; hace 3 meses ( 28/06/2024 )
Versión preliminar
2.15.64 / 21 de junio de 2024
Repositorio
  • git.whamcloud.com/fs/lustre-release.git
Escrito endo
Sistema operativoNúcleo de Linux
TipoSistema de archivos distribuido
LicenciaLicencia GPL versión 2 , Licencia LGPL
Sitio webwww.lustre.org
Sistemas de archivos en clúster, Inc.
Tipo de empresaPrivado
Fundado2001
FundadorPeter J. Braam
Sede
Boulder, Colorado
Personas clave
Andreas Dilger, Eric Barton (HPC), Phil Schwan
ProductosSistema de archivos Lustre
Lustre
IntroducidoDiciembre de 2003 con Linux
Estructuras
Contenido del directorioHash, Hash intercalado con DNE en 2.7+
Tipo de archivoarchivo, directorio, enlace permanente, enlace simbólico, bloque especial, carácter especial, socket, FIFO
ArrancableNo
Límites
Tamaño mínimo del volumen32 MB
Tamaño máximo del volumen700 PB (producción), [4] más de 16 EB (teórico)
Tamaño máximo de archivo32 PB (ext4), 16 EB (ZFS)
Granularidad del tamaño del archivo4 KB
Número máximo de archivosPor objetivo de metadatos (MDT): 4 mil millones de archivos (backend ldiskfs), 256 billones de archivos (backend ZFS), [5] hasta 128 MDT por sistema de archivos
Longitud máxima del nombre de archivo255 bytes
Longitud máxima del nombre de directorio255 bytes
Profundidad máxima del directorio4096 bytes

Caracteres de nombre de archivo permitidos		Todos los bytes excepto NUL ('\0') y '/' y los nombres de archivo especiales "." y ".."
Características
Fechas registradasmodificación (mtime), modificación de atributo (ctime), acceso (atime), eliminación (dtime), creación (crtime)
Rango de fechas2^34 bits (ext4), 2^64 bits (ZFS)
Resolución de fecha1 segundo
TenedoresNo
Atributos32bitapi, acl, suma de comprobación, rebaño, lazystatfs, localflock, lruresize, noacl, nochecksum, noflock, nolazystatfs, nolruresize, nouser_fid2path, nouser_xattr, user_fid2path, user_xattr

Permisos del sistema de archivos		POSIX , POSIX.1e ACL , SELinux

Compresión transparente		Sí (solo ZFS)

Cifrado transparente		Sí (red, almacenamiento con ZFS 0.8+, fscrypt con Lustre 2.14.0+)
Desduplicación de datosSí (solo ZFS)
Copiar en escrituraSí (solo ZFS)
Otro
Sistemas operativos compatibles
Núcleo de Linux

Lustre es un tipo de sistema de archivos distribuido en paralelo, generalmente utilizado para computación en clúster a gran escala . El nombre Lustre es una palabra compuesta derivada de Linux y cluster . [6] El software del sistema de archivos Lustre está disponible bajo la Licencia Pública General GNU (solo la 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 constantemente por al menos la mitad de los diez primeros y más de 60 de los 100 superordenadores más rápidos del mundo, [7] [8] [9] incluyendo el superordenador número 1 del mundo clasificado en el TOP500 en noviembre de 2022, Frontier , [4] así como los superordenadores superiores anteriores como Fugaku , [10] [11] Titan [12] y Sequoia . [13]

Los sistemas de archivos Lustre son escalables y pueden ser parte de múltiples clústeres de computadoras con decenas de miles de nodos de 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 . [14] [15] Esto hace que los sistemas de archivos Lustre sean una opción popular para empresas con grandes centros de datos, incluidas las de industrias como meteorología , [16] [17] simulación , inteligencia artificial y aprendizaje automático , [18] [19] petróleo y gas, [20] ciencias de la vida , [21] [22] medios enriquecidos y finanzas. [23] El rendimiento de E/S de Lustre tiene un impacto generalizado en estas aplicaciones y ha atraído una amplia atención. [24] [25] [26]

Historia

La arquitectura del sistema de archivos Lustre fue iniciada como un proyecto de investigación en 1999 por Peter J. Braam , que era miembro del personal de la Universidad Carnegie Mellon (CMU) en ese momento. Braam fundó su propia empresa Cluster File Systems en 2001, [27] comenzando con el trabajo en el sistema de archivos InterMezzo en el proyecto Coda en CMU. [28] Lustre fue desarrollado bajo el proyecto Path Forward de la Iniciativa de Computación Estratégica Acelerada financiado por el Departamento de Energía de los Estados Unidos , que incluía a Hewlett-Packard e Intel . [29] En septiembre de 2007, Sun Microsystems adquirió los activos de Cluster File Systems Inc., incluida su "propiedad intelectual". [30] [31] Sun incluyó Lustre con sus ofertas de hardware de computación de alto rendimiento , con la intención de llevar las tecnologías 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 , a través de la adquisición de Sun, comenzó a administrar y lanzar Lustre.

En diciembre de 2010, Oracle anunció que dejaría de desarrollar Lustre 2.x y que dejaría Lustre 1.8 en soporte de solo mantenimiento, lo que creó incertidumbre en torno al desarrollo futuro del sistema de archivos. [32] Tras este anuncio, surgieron varias organizaciones nuevas para proporcionar soporte y desarrollo en un modelo de desarrollo comunitario abierto, incluidas Whamcloud, [33] Open Scalable File Systems, Inc. (OpenSFS) , EUROPEAN Open File Systems (EOFS) y otras. A fines de 2010, la mayoría de los desarrolladores de Lustre habían abandonado Oracle. Braam y varios asociados se unieron a Xyratex , orientada al hardware , cuando adquirió los activos de ClusterStor, [34] [35] mientras que Barton, Dilger y otros formaron la startup de software Whamcloud, donde continuaron trabajando en Lustre. [36]

En agosto de 2011, OpenSFS adjudicó un contrato para el desarrollo de características de Lustre a Whamcloud. [37] 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 múltiples 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 múltiples servidores. El desarrollo también continuó en el almacenamiento de objetos de back-end basado en ZFS en el Laboratorio Nacional Lawrence Livermore . [13] Estas características estaban en la hoja de ruta de lanzamiento de la comunidad de Lustre 2.2 a 2.4. [38] En noviembre de 2011, se adjudicó un contrato independiente a Whamcloud para el mantenimiento del código fuente de Lustre 2.x para garantizar que el código de Lustre recibiría suficientes pruebas y corrección de errores mientras se desarrollaban nuevas características. [39]

En julio de 2012, Intel adquirió Whamcloud , [40] [41] después de que Whamcloud ganara el contrato FastForward DOE para preparar Lustre para su uso con sistemas informáticos de exaescala en el período de 2018. [42] 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 originales de Lustre de Oracle. [34] En junio de 2013, Intel comenzó a expandir el uso de Lustre más allá de HPC tradicional, como dentro de Hadoop . [43] 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. [44] OpenSFS también estableció el Portal de la comunidad de 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 a la comunidad de usuarios, [45] y esto se completó en marzo de 2015.

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

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

Historial de versiones

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

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

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

Lustre 1.4.0, lanzado en noviembre de 2004, proporcionó compatibilidad de protocolos entre versiones, podía usar redes InfiniBand y podía explotar extensiones/mballoc en el sistema de archivos en disco ldiskfs .

Lustre 1.6.0, lanzado en abril de 2007, permitió la configuración de montaje ("mountconf") permitiendo que los servidores se configuraran con "mkfs" y "mount", permitió la adición dinámica de destinos de almacenamiento de objetos (OST), habilitó la escalabilidad del administrador de bloqueo distribuido Lustre (LDLM) en servidores de multiprocesamiento simétrico (SMP) y proporcionó administración de espacio libre para asignaciones de objetos.

Lustre 1.8.0, lanzado en mayo de 2009, proporcionó caché de lectura de OSS, mejoró la recuperación en caso de múltiples fallas, agregó administración de almacenamiento heterogéneo básico a través de grupos de OST, tiempos de espera de red adaptables y recuperación basada en versiones. Fue una versión de transición, interoperable con Lustre 1.6 y Lustre 2.0. [50]

Lustre 2.0, lanzado en agosto de 2010, se basó en un código reestructurado internamente para prepararse para los principales avances arquitectónicos. Los clientes de Lustre 2.x no pueden interoperar con servidores de la versión 1.8 o anteriores . Sin embargo, los clientes de Lustre 1.8.6 y posteriores pueden interoperar con servidores de Lustre 2.0 y posteriores. El formato en 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 por parte de Oracle del desarrollo de las versiones de Lustre 2.x. [51] 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, [52] así como una serie de mejoras de rendimiento y estabilidad. Los servidores de Lustre 2.1 siguieron siendo interoperables con los clientes de la versión 1.8.6 y posteriores.

Lustre 2.2, lanzado en marzo de 2012, se centró en proporcionar mejoras en el rendimiento de metadatos y nuevas características. [53] Añadió operaciones de directorio paralelas que permitían 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 único 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 el sistema de archivos de respaldo. La función Lustre File System ChecK (LFSCK) puede verificar y reparar el índice de objetos (OI) de MDS 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 programadores 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, agregó 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 capacidad de metadatos horizontal y el escalamiento del rendimiento para clientes 2.4, al permitir que los árboles de subdirectorios de un solo espacio de nombres se ubiquen en MDT separados. ZFS ahora se puede utilizar como el sistema de archivos de respaldo para el almacenamiento MDT y OST. La característica LFSCK agregó la capacidad de escanear y verificar la consistencia interna de los atributos LinkEA y FID de MDT. El programador de solicitudes de red [54] [55] (NRS) agrega políticas para optimizar el procesamiento de solicitudes de clientes para el ordenamiento o la equidad del disco. 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 Linux hasta la versión 3.6 y aún es interoperable con clientes 1.8.

Lustre 2.5, lanzado en octubre de 2013, agregó la característica muy esperada, Hierarchical Storage Management (HSM). Un requisito básico en entornos empresariales, HSM permite a los clientes implementar fácilmente soluciones de almacenamiento por niveles en su entorno operativo. Esta versión es la rama de versión de mantenimiento designada por OpenSFS actual de Lustre. [56] [57] [58] [59] La versión de mantenimiento más reciente es 2.5.3 y se lanzó en septiembre de 2014. [60]

Lustre 2.6, lanzado en julio de 2014, [61] fue una versión más modesta en cuanto a características, agregando la funcionalidad LFSCK para realizar verificaciones de consistencia local en el OST, así como verificaciones de consistencia entre MDT y objetos OST. Se agregó la política NRS Token Bucket Filter [62] (TBF). El rendimiento de IO de un solo cliente se mejoró con respecto a las versiones anteriores. [63] Esta versión también agregó una vista previa de directorios en franjas de 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, [64] agregó la funcionalidad LFSCK para verificar la consistencia de DNE de directorios remotos y segmentados entre múltiples MDT. Dynamic LNet Config agrega la capacidad de configurar y modificar las interfaces de red, rutas y 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 en la funcionalidad de directorio segmentado de DNE.

Lustre 2.8, lanzado en marzo de 2016, [65] finalizó la función de directorio en franjas de DNE, incluida la compatibilidad con la migración de directorios entre MDT y el enlace duro y el cambio de nombre entre MDT. Además, incluyó compatibilidad mejorada con 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 [66] e incluyó una serie de características relacionadas con la seguridad y el rendimiento. La variante de seguridad Shared Secret Key utiliza el mismo mecanismo GSSAPI que Kerberos para proporcionar autenticación de nodos de cliente y servidor, e integridad y seguridad de mensajes RPC (cifrado). La característica Nodemap permite categorizar los nodos de cliente en grupos y luego mapear el UID/GID para esos clientes, lo que permite que los clientes administrados de forma remota utilicen de forma transparente un sistema de archivos compartido sin tener un único conjunto de UID/GID para todos los nodos de cliente. La característica de montaje de subdirectorio 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 al disco más eficiente, y agregó la ladviseinterfaz para permitir que los clientes proporcionen sugerencias de E/S a los servidores para obtener previamente datos de archivos en la memoria caché del servidor o vaciar los datos de archivos de la memoria caché del servidor. Se mejoró el soporte para especificar grupos OST predeterminados para todo el sistema de archivos y se mejoró la herencia de los grupos OST junto con otros parámetros de diseño de archivos.

Lustre 2.10 se lanzó en julio de 2017 [67] y tiene una serie de mejoras significativas. La función LNet Multi-Rail (LMR) permite unir múltiples interfaces de red ( InfiniBand , Omni-Path y/o Ethernet ) en un cliente y servidor para aumentar el ancho de banda de E/S agregado. Los archivos individuales pueden usar diseños de archivos compuestos que se construyen con múltiples componentes, que son regiones de archivos basadas en el desplazamiento del archivo, que permiten diferentes parámetros de diseño como el recuento de franjas, el tipo de almacenamiento/pool OST, etc. El diseño de archivo progresivo (PFL) es la primera función que usa diseños compuestos, pero la implementación es flexible para su uso con otros diseños de archivos como duplicación y codificación de borrado. El programador del lado del servidor NRS Token Bucket Filter (TBF) ha implementado nuevos tipos de reglas, incluida la programación de tipo RPC y la capacidad de especificar múltiples parámetros como JobID y NID para la coincidencia de reglas. Se han agregado herramientas para administrar instantáneas ZFS de sistemas de archivos Lustre, para simplificar la creación, el montaje y la administración de instantáneas ZFS MDT y OST como puntos de montaje Lustre separados .

Lustre 2.11 se lanzó en abril de 2018 [68] y contiene dos nuevas características importantes y varias características más pequeñas. La característica File Level Redundancy (FLR) amplía la implementación de PFL 2.10, agregando la capacidad de especificar diseños de archivos reflejados para una mejor disponibilidad en caso de falla del servidor o del almacenamiento y/o un mejor 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 basado en flash típico 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 configuración automática de LNet Multi-Rail entre pares que comparten una red LNet. La función LDLM Lock Ahead permite que las aplicaciones y bibliotecas modificadas apropiadamente obtengan con anterioridad bloqueos de extensión DLM de los OST para archivos, si la aplicación sabe (o predice) que esta extensión de archivo se modificará en el futuro cercano, lo que puede reducir la contención de bloqueos para múltiples clientes que escriben en el mismo archivo.

Lustre 2.12 se lanzó el 21 de diciembre de 2018 [69] 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 agregadas en Lustre 2.11, así como cambios más pequeños en NRS TBF , HSM y JobStats. Agregó LNet Network Health Archivado el 12 de febrero de 2019 en Wayback Machine para permitir que la característica LNet Multi-Rail de Lustre 2.10 gestione mejor las fallas de red cuando un nodo tiene múltiples interfaces de red. La característica Lazy Size on MDT [70] (LSOM) permite almacenar una estimación del tamaño del archivo en el MDT para que lo usen los motores de políticas, los escáneres del sistema de archivos y otras herramientas de administración que pueden tomar decisiones más eficientemente sobre los archivos sin un tamaño de archivo o un recuento de bloques completamente precisos sin tener que consultar los OST para obtener esta información. Esta versión también agregó la capacidad de volver a dividir manualmente un directorio existente en varios MDT, para permitir la migración de directorios con una gran cantidad de archivos para utilizar la capacidad y el rendimiento de varios nodos MDS. La suma de comprobación de datos de Lustre RPC agregó sumas de comprobación de datos integradas SCSI T10-PI [71] desde el cliente a la capa de bloque del núcleo, el adaptador de host SCSI y los discos duros habilitados para T10 .

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

Lustre 2.14 se lanzó el 19 de febrero de 2021 [77] 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 amplían el marco de cuotas para permitir la asignación y aplicación de cuotas en función de los grupos de almacenamiento de OST. La redistribución automática de DNE ahora puede ajustar la cantidad de MDT en los que 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 [2] e incluye tres características principales. El cifrado de directorio de cliente [78] amplía el cifrado de datos fscrypt en 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 equilibrio de espacio de DNE MDT equilibra automáticamente la creación de nuevos directorios en los MDT del 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 en los MDT de manera más uniforme. Para las aplicaciones que utilizan la interfaz de almacenamiento directo de GPU NVIDIA (GDS), el cliente Lustre puede realizar lecturas y escrituras RDMA de copia cero desde el servidor de almacenamiento directamente a la memoria de la GPU para evitar una copia de datos adicional de la memoria de la CPU y una sobrecarga de procesamiento adicional. [79] 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.

Arquitectura

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 almacena metadatos de espacios de nombres, como nombres de archivos, directorios, permisos de acceso y diseño de archivos. Los datos de 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 las verificaciones de nombres de ruta y permisos, y no participa en ninguna operación de E/S de archivos, lo que evita 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 característica nueva en Lustre 2.4, y permite que los subárboles de directorios residan en los MDT secundarios, mientras que 2.7 y posteriores también permiten que directorios individuales grandes se distribuyan 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 prestar servicio a entre dos y ocho OST, y cada uno de ellos 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.
  • Cliente(s) que acceden y utilizan los datos. Lustre presenta 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 simultáneo 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 (normalmente con 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 único sistema de archivos, aunque es posible tener varios MDT u OST en un único nodo que sean parte de diferentes sistemas de archivos. La capa de red Lustre (LNet) puede utilizar varios tipos de interconexiones de red, incluidos verbos nativos 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 anteriores, también se admitían redes Myrinet , Quadrics , Cray SeaStar y RapidArray, pero estos controladores de red quedaron obsoletos cuando estas redes ya no estaban disponibles comercialmente y el soporte 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 lo proporcionan los dispositivos RAID de hardware , aunque funcionarán con cualquier dispositivo de bloque. Desde Lustre 2.4, MDT y OST también pueden utilizar ZFS para el sistema de archivos de respaldo además de ext4 , lo que les permite utilizar de forma eficaz el almacenamiento JBOD en lugar de los 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 comprobación de datos en ZFS. Los clientes no tienen ningún acceso directo al almacenamiento subyacente, lo que garantiza que un cliente que funcione mal o sea malintencionado no pueda dañar 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, POSIX y atributos de archivo extendidos , controla los permisos de acceso a archivos/ ACL y les dice a los clientes el diseño de los objetos que componen cada archivo regular. Los MDT y OST actualmente usan una versión mejorada de ext4 llamada ldiskfs o ZFS /DMU para el almacenamiento de datos de back-end para almacenar archivos/objetos [80] usando el puerto ZFS-on-Linux de código abierto. [81]

El cliente monta el sistema de archivos Lustre localmente con un controlador VFS para el núcleo Linux que conecta al cliente con el servidor o los servidores. Tras el montaje inicial, 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 de nombre de archivo en el MDS. Cuando se completa la búsqueda de nombre de archivo en el MDS y el usuario y el cliente tienen permiso para acceder al archivo o crearlo, se devuelve al cliente el diseño de un archivo existente o se crea un nuevo archivo en nombre del cliente, si se solicita. Para las operaciones de lectura o escritura, el cliente interpreta el diseño 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 de lectura o escritura paralelas 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 se escala casi linealmente con la cantidad de OST en el sistema de archivos.

Después de la búsqueda inicial del diseño de archivos, el MDS normalmente no participa en las operaciones de E/S de archivos, ya que toda la asignación de bloques y la E/S de datos se gestionan internamente por el OST. Los clientes no modifican directamente los objetos o los datos en los sistemas de archivos OST, sino que delegan esta tarea a los nodos OSS. Este enfoque garantiza la escalabilidad para clústeres y supercomputadoras a gran escala, así como una seguridad y una confiabilidad mejoradas. Por el contrario, 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 en el 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 debido a clientes defectuosos o con mal comportamiento.

Implementación

En una instalación típica de Lustre en un cliente Linux, se carga un módulo de controlador de sistema de archivos de Lustre en el núcleo y el sistema de archivos se monta como cualquier otro sistema de archivos local o de red. Las aplicaciones cliente ven un sistema de archivos único y unificado, aunque 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 [82] en el Laboratorio Nacional Lawrence Livermore .

Otro enfoque utilizado en los primeros años de Lustre es la biblioteca liblustre en Cray XT3 utilizando el sistema operativo Catamount en sistemas como Sandia Red Storm , [83] que proporcionaba a las aplicaciones de espacio de usuario acceso directo al sistema de archivos. Liblustre era una biblioteca de nivel de usuario que permite a los procesadores computacionales montar y utilizar 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 lanzó el trabajo no es un cliente Linux. Liblustre permitió 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 núcleo, proporcionando así acceso desde los procesadores computacionales al sistema de archivos Lustre directamente en un entorno operativo restringido. La funcionalidad 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, el puerto incompleto del cliente Lustre se eliminó del área de preparación del kernel para acelerar el desarrollo y la portabilidad a kernels más nuevos. [84] El cliente y servidor Lustre fuera del árbol aún están disponibles para los kernels de distribución RHEL, SLES y Ubuntu , así como para los kernels vanilla.

Objetos de datos y segmentación de archivos

En un sistema de archivos de disco Unix tradicional , una estructura de datos de inodo contiene información básica sobre cada archivo, como dónde se almacenan los datos contenidos en el archivo. El sistema de archivos Lustre también utiliza inodos, pero los inodos en los MDT apuntan a uno o más objetos OST asociados con el 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 de archivo transfiere un conjunto de identificadores de objetos y su diseño desde el MDS al cliente, de modo que el cliente puede interactuar directamente con los nodos OSS que contienen los objetos. Esto permite que los clientes realicen operaciones de E/S en paralelo en todos los objetos OST del archivo sin comunicación adicional con el MDS, lo que evita la contención de la gestión centralizada de bloques y bloqueos.

Si solo un objeto OST está asociado con un inodo MDT, ese objeto contiene todos los datos del archivo Lustre. Cuando más de un objeto está asociado con un archivo, los datos del archivo se "dividen" en fragmentos de manera rotatoria en todos los objetos OST de manera similar a RAID 0 en fragmentos que suelen tener 1 MB o más. Dividir un archivo en varios objetos OST proporciona importantes ventajas de rendimiento si se necesita un acceso de gran ancho de banda a un único archivo grande. Cuando se utiliza la división en fragmentos, 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 se escalan con la cantidad de OST en los que se divide un archivo. Además, dado que el bloqueo de cada objeto se administra de forma independiente para cada OST, agregar más divisiones (una por OST) escala la capacidad de bloqueo de E/S del archivo de manera proporcional. Cada archivo creado en el sistema de archivos puede especificar diferentes parámetros de diseño, como el recuento de franjas (número de objetos OST que componen ese archivo), el tamaño de 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 ajustar de forma óptima para cada archivo. Cuando muchos subprocesos de la aplicación leen o escriben en archivos separados en paralelo, es óptimo tener una sola franja por archivo, ya que la aplicación proporciona su propio paralelismo. Cuando hay muchos subprocesos que leen o escriben un solo archivo grande simultáneamente, entonces es óptimo tener al menos una franja en cada OST para maximizar el rendimiento y la capacidad de ese archivo.

En la versión 2.10 de Lustre, 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 de 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 flash para una menor sobrecarga de acceso, mientras que los archivos más grandes pueden tener muchas franjas para un alto ancho de banda agregado y un mejor equilibrio de carga de OST. Los diseños compuestos se mejoran aún más en la versión 2.11 con la función de redundancia a nivel de archivo (FLR), que permite que un archivo tenga múltiples diseños superpuestos para un archivo, lo que proporciona redundancia RAID 0+1 para estos archivos, así como un rendimiento de lectura mejorado. La versión 2.11 de Lustre también agregó la función de 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 OST Overstriping permite que un solo componente tenga múltiples stripes en un OST para mejorar aún más el paralelismo del bloqueo, mientras que la función Self-Extending Layout permite que el tamaño del componente sea dinámico durante la escritura para que pueda hacer frente a OST individuales (flash) que se quedan sin espacio antes de que todo el sistema de archivos se quede sin espacio.

Objetos de metadatos y directorios remotos o segmentados de DNE

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 identificador de objeto de 32 bits y la versión de 32 bits) del directorio raíz para el punto de montaje. Al realizar una búsqueda de nombre de archivo, el cliente realiza una búsqueda de cada componente de nombre de ruta asignando el número de secuencia de FID del directorio principal a un MDT específico a través de la base de datos de ubicación de FID (FLDB) y, a continuación, realiza una búsqueda en el MDS que administra este MDT utilizando el FID principal y el nombre de archivo. El MDS devolverá el FID para el componente de nombre 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 segmentados) normalmente se realizarán en ese MDT, lo que evita la contención entre MDT.

En el caso de los directorios segmentados de DNE, el diseño por directorio almacenado en el directorio principal proporciona una función hash y una lista de FID de directorio MDT en los que se distribuye el directorio. El volumen de metadatos lógicos (LMV) del cliente segmenta el nombre del archivo y lo asigna a un fragmento de directorio MDT específico , que gestionará las operaciones posteriores en ese archivo de manera idéntica a un directorio no segmentado. En el caso de las operaciones readdir() , las entradas de cada fragmento de directorio se devuelven al cliente ordenadas en el orden hash del directorio MDT local, y el cliente realiza una ordenación por combinació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 de equilibrio de espacio y round-robin, de modo que los clientes pueden 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 3 niveles de directorio superiores de manera predeterminada), se 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 (más del 5% de diferencia en espacio libre e inodos), entonces los clientes sesgarán la creación de nuevos subdirectorios hacia MDT con más espacio libre para restablecer el equilibrio. [85]

Cierre

El administrador de bloqueos distribuidos de Lustre (LDLM), implementado en el estilo OpenVMS , protege la integridad de los datos y metadatos de cada archivo. El acceso y la modificación de un archivo de Lustre es completamente coherente en caché entre todos los clientes. Los bloqueos de metadatos son administrados por el MDT que almacena el inodo para el archivo, utilizando FID como el nombre del recurso. Los bloqueos de metadatos se dividen en bits separados que protegen la búsqueda del archivo (propietario y grupo del archivo, permiso y modo, y lista de control de acceso (ACL)), el estado del inodo (tamaño del directorio, contenido del directorio, recuento de enlaces, marcas de tiempo), el diseño (división de archivos, desde Lustre 2.4) y los atributos extendidos (xattrs, desde Lustre 2.5). Un cliente puede obtener múltiples 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 administra todas las modificaciones al 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 archivo son administrados por el OST en el que se divide cada objeto del archivo, utilizando bloqueos de extensión de rango de bytes . A los clientes se les pueden otorgar bloqueos de extensión de lectura superpuestos para parte o la totalidad del archivo, lo que permite múltiples lectores simultáneos del mismo archivo, y/o bloqueos de extensión de escritura no superpuestos para regiones independientes del archivo. Esto permite que muchos clientes de Lustre accedan a un solo archivo simultáneamente tanto para lectura como para escritura, evitando cuellos de botella durante la E/S de archivos. En la práctica, debido a que los clientes de Linux administran su caché de datos en unidades de páginas , los clientes solicitarán bloqueos que siempre sean un múltiplo entero del tamaño de la 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, para reducir la cantidad de solicitudes de bloqueo que realiza el cliente. El tamaño real del bloqueo otorgado depende de varios factores, incluido el número de bloqueos actualmente otorgados en ese objeto, si hay bloqueos de escritura en conflicto para la extensión de bloqueo solicitada y la cantidad de solicitudes de bloqueo pendientes en ese objeto. El bloqueo otorgado nunca es más pequeño que la extensión solicitada originalmente. Los bloqueos de extensión OST utilizan el FID de Lustre del objeto como nombre de recurso para el bloqueo. Dado que la cantidad de servidores de bloqueo de extensión aumenta con la cantidad 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 está distribuido en múltiples OST.

Redes

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 de programación de red de Sandia Portals . El almacenamiento en disco se conecta a los nodos de servidor Lustre MDS y OSS mediante almacenamiento conectado directamente ( SAS , FC , iSCSI ) o tecnologías de red de área de almacenamiento (SAN) tradicionales, que son independientes de la red de cliente a servidor.

LNet puede utilizar muchos tipos de redes de uso común, como redes InfiniBand y TCP (comúnmente Ethernet ), y permite la disponibilidad simultánea en múltiples tipos de redes con enrutamiento entre ellas. El acceso directo remoto a memoria (RDMA) se utiliza para la transferencia de datos y metadatos entre nodos cuando lo proporcionan las redes subyacentes, como InfiniBand, RoCE , iWARP y Omni-Path , así como redes de alta velocidad patentadas como Cray Aries y Gemini, y Atos BXI. Las funciones de alta disponibilidad y recuperación permiten una recuperación transparente junto con servidores de conmutación por error.

Desde Lustre 2.10, la función LNet Multi-Rail (MR) [86] 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 2.12, Multi-Rail se mejoró para mejorar la tolerancia a fallas si hay múltiples interfaces de red disponibles entre pares.

LNet proporciona un rendimiento de extremo a extremo a través de redes Gigabit Ethernet de más de 100 MB/s, [87] un rendimiento de hasta 11 GB/s utilizando enlaces de velocidad de datos mejorada (EDR) InfiniBand y un rendimiento de más de 11 GB/s a través de interfaces de 100 Gigabit Ethernet . [88]

Alta disponibilidad

Las características de alta disponibilidad del sistema de archivos Lustre incluyen un sólido mecanismo de recuperación y conmutación por error, que permite que las fallas y reinicios del servidor sean transparentes. La interoperabilidad de versiones entre versiones menores sucesivas del software Lustre permite actualizar un servidor desconectándolo (o conectándolo a un servidor en espera), realizando la actualización y reiniciándolo, mientras todos los trabajos activos continúan ejecutándose, experimentando una demora mientras el servidor de respaldo se hace cargo del almacenamiento.

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

HSM (Gestión de almacenamiento jerárquico)

Lustre ofrece la posibilidad de tener múltiples niveles de almacenamiento dentro de un único espacio de nombres del sistema de archivos. Permite que la funcionalidad tradicional de HSM copie (archive) archivos del sistema de archivos principal a un nivel de almacenamiento de archivo secundario. El nivel de archivo es normalmente un sistema basado en cinta, que suele estar encabezado por una caché de disco. Una vez que se archiva un archivo, se puede liberar del sistema de archivos principal, dejando solo un fragmento que hace referencia a la copia del archivo. Si se abre un archivo liberado, el Coordinador bloquea la apertura, envía una solicitud de restauración a una herramienta de copia y luego completa la apertura una vez que la herramienta de copia ha terminado de restaurar el archivo.

Además de la organización en niveles del almacenamiento externo, es posible tener múltiples niveles de almacenamiento dentro de un único 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 archivos, y se pueden utilizar diferentes grupos dentro de un único diseño de archivo PFL. Los archivos se pueden migrar entre niveles de almacenamiento ya sea de forma manual o bajo el control del motor de políticas. Desde Lustre 2.11, también es posible reflejar un archivo en diferentes grupos de OST con un diseño de archivo FLR, por ejemplo, para preparar archivos en flash para un trabajo informático.

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

  • Coordinador: recibe solicitudes de archivo y restauración y las envía a los nodos del agente.
  • Agente: ejecuta una herramienta de copia para copiar datos del almacenamiento principal al archivo y viceversa.
  • Copytool: maneja el movimiento de datos y las actualizaciones de metadatos. Existen diferentes copytools para interactuar con diferentes sistemas de archivo. Hay disponible una copytool POSIX genérica para archivos que proporcionan una interfaz de usuario similar a POSIX. También hay copytools disponibles para el High Performance Storage System [89] (HPSS), Tivoli Storage Manager [90] (TSM), Amazon S3 [91] y Google Drive [92] .
  • 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 en función de su antigüedad o uso del espacio y se comunica con MDT y Coordinator. El motor de políticas también puede activar acciones como migraciones, purgas y eliminaciones. El motor de políticas más utilizado es RobinHood, pero también se pueden utilizar otros motores de políticas.

HSM también define nuevos estados para los archivos, incluidos: [93]

  • Existe: Existe alguna copia, posiblemente incompleta, en un HSM.
  • Archivo: existe una copia completa en el lado del archivo del HSM.
  • Sucio: La copia principal del archivo ha sido modificada y difiere de la copia archivada.
  • Liberado: existe un inodo auxiliar en un MDT, pero se han eliminado los objetos de datos 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

Despliegues

Lustre es utilizado por muchas de las supercomputadoras TOP500 y grandes sitios multi-clúster. Seis de las 10 principales y más de 60 de las 100 principales supercomputadoras utilizan sistemas de archivos Lustre. Estos incluyen el sistema de archivos Orion de 700PB 13 TB/s para la supercomputadora Frontier en el Laboratorio Nacional Oak Ridge (ORNL), [4] [94] Fugaku y K Computer [13] en el Instituto Avanzado de Ciencias Computacionales RIKEN , 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 Investigación Energética , el Laboratorio Nacional del Noroeste del Pacífico , el Centro de Computación Avanzada de Texas , el Laboratorio Nacional de Computación Científica de Brasil, [95] y la NASA [96] en América del Norte, en Asia en el Instituto de Tecnología de Tokio , [97] en Europa en el CEA , [98] [99] y muchos otros.

Soporte técnico comercial

El soporte técnico comercial para Lustre suele venir incluido junto con el sistema informático o el hardware de almacenamiento vendido por el proveedor. Algunos proveedores incluyen Hewlett-Packard (como HP StorageWorks Scalable File Share, circa 2004 a 2008), [100] ATOS , Fujitsu . [101] Los proveedores que venden hardware de almacenamiento con soporte Lustre incluido incluyen Hitachi Data Systems (2012), [102] DataDirect Networks (DDN), [103] Aeon Computing y otros. También es posible obtener soporte solo de software para sistemas de archivos Lustre de algunos proveedores, incluido Whamcloud. [104]

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

Microsoft Azure ofrece Azure Managed Lustre (AMLFS) [106] . Azure Managed Lustre es un sistema de archivos totalmente administrado y de pago por uso para cargas de trabajo de inteligencia artificial y computación de alto rendimiento (HPC) en su nube.

Véase también

Referencias

  1. ^ ab Corbet, Jonathon (17 de diciembre de 2003). "Lanzamiento de Lustre 1.0". Linux Weekly News . LWN.net . Consultado el 15 de marzo de 2015 .
  2. ^ ab "Versión 2.15.0". Wiki de Lustre . OpenSFS . 16 de junio de 2022 . Consultado el 17 de junio de 2022 .
  3. ^ "Lanzamiento de Lustre 2.15.5". lustre.org . 2024-06-28 . Consultado el 2024-06-28 .
  4. ^ abc "La supercomputadora Frontier debuta como la más rápida del mundo y rompe la barrera de la exaescala". Laboratorio Nacional de Oak Ridge. 30 de mayo de 2022.
  5. ^ Oracle Corporation / Intel Corporation (4 de agosto de 2002). "Manual de operaciones de Lustre* Software Release 2.x" (PDF) . Manual de instrucciones . Intel . Consultado el 25 de junio de 2024 .
  6. ^ "Lustre Home". Archivado desde el original el 31 de marzo de 2001. Consultado el 23 de septiembre de 2013 .
  7. ^ "Se lanzó Lustre File System, versión 2.4". Open Scalable File Systems . Consultado el 18 de octubre de 2014 .
  8. ^ "Lustre, un sistema de código abierto, recibe el visto bueno para la supercomputación" . Consultado el 18 de octubre de 2014 .
  9. ^ "Xyratex captura el brillo de Oracle". HPCWire. 21 de febrero de 2013. Consultado el 18 de octubre de 2014 .
  10. ^ "Información sobre el Post-K (Fugaku)". Fujitsu. Archivado desde el original el 8 de junio de 2020. Consultado el 23 de junio de 2020 .
  11. ^ "Supercomputadora Fugaku" (PDF) . Fujitsu.
  12. ^ "Descripción general del sistema Titán". Laboratorio Nacional de Oak Ridge. Archivado desde el original el 13 de febrero de 2018. Consultado el 19 de septiembre de 2013 .
  13. ^ abc Brian Behlendorf. "ZFS en Linux para Lustre" (PDF) . Laboratorio Nacional Lawrence Livermore. Archivado desde el original (PDF) el 2014-10-31 . Consultado el 2020-06-23 .
  14. ^ "Orion: el sistema de archivos masivo de Frontier". insideHPC. 2023-04-03.
  15. ^ Andreas Dilger, Whamcloud (20 de junio de 2019). "Lustre: los próximos 20 años" (PDF) . HPCIODC.
  16. ^ "Cray proporcionará a la NOAA dos supercomputadoras con tecnología AMD". HPC Wire. 24 de febrero de 2020.
  17. ^ Julian Kunkel, DKRZ (15 de junio de 2017). "Lustre en DKRZ" (PDF) . OpenSFS.
  18. ^ Chris Mellor (2 de mayo de 2023). "La supercomputadora de inteligencia artificial de Nvidia muestra su brillo en la nube de Oracle". Bloques y archivos.
  19. ^ Julie Bernauer, Prethvi Kashinkunti, NVIDIA (20 de mayo de 2021). "Aceleración de la IA a escala con Selene DGXA100 SuperPOD y Lustre Parallel Filesystem Storage" (PDF) . OpenSFS.{{cite web}}: CS1 maint: varios nombres: lista de autores ( enlace )
  20. ^ Raj Gautam (15 de mayo de 2019). "Comunicación de larga distancia" (PDF) . Exxon Mobil.
  21. ^ Cambridge-1: una historia de éxito de NVIDIA en YouTube
  22. ^ James Beal, Pavlos Antoniou, Sanger Institute (20 de mayo de 2021). "Actualización sobre Secure Lustre" (PDF) . OpenSFS.{{cite web}}: CS1 maint: varios nombres: lista de autores ( enlace )
  23. ^ Steve Crusan, Brock Johnson, Hudson River Trading (10 de mayo de 2022), Lustre in Finance (PDF) , OpenSFS{{citation}}: CS1 maint: varios nombres: lista de autores ( enlace )
  24. ^ Wang, Teng; Byna, Suren; Lockwood, Glenn K.; Snyder, Shane; Carns, Philip; Kim, Sunggon; Wright, Nicholas J. (mayo de 2019). "Un análisis de acercamiento de los registros de E/S para detectar las causas fundamentales de los cuellos de botella en el rendimiento de E/S". 19.° Simposio internacional IEEE/ACM sobre computación en clúster, en la nube y en red (CCGRID) de 2019. IEEE. págs. 102–111. doi :10.1109/CCGRID.2019.00021. ISBN . 978-1-7281-0912-1.S2CID 195832257  .
  25. ^ Gunasekaran, Raghul; Oral, Sarp; Hill, Jason; Miller, Ross; Wang, Feiyi; Leverman, Dustin (noviembre de 2015). "Caracterización comparativa de la carga de trabajo de E/S de dos clústeres de almacenamiento de clase líder" (PDF) . Actas del 10.º Taller de almacenamiento de datos en paralelo . ACM. págs. 31–36. doi :10.1145/2834976.2834985. ISBN . 9781450340083. Número de identificación del sujeto  15844745.
  26. ^ Saini, Subhash; Rappleye, Jason; Chang, Johnny; Barker, David; Mehrotra, Piyush; Biswas, Rupak (diciembre de 2012). "Caracterización del rendimiento de E/S de las aplicaciones Lustre y NASA en Pleiades". 2012 19.ª Conferencia internacional sobre informática de alto rendimiento (PDF) . IEEE. págs. 1–10. doi :10.1109/HiPC.2012.6507507. hdl :2060/20130001600. ISBN. 978-1-4673-2371-0.S2CID14323627  .​
  27. ^ "Compañía". Sitio web antiguo . Cluster File Systems, Inc. Archivado desde el original el 12 de agosto de 2007.{{cite web}}: CS1 maint: bot: estado de URL original desconocido ( enlace )
  28. ^ Peter J. Braam (4 de agosto de 2002). «Lustre, el sistema de archivos intergaláctico» (PDF) . Diapositivas de la presentación . Laboratorio Nacional Lawrence Livermore . Archivado desde el original (PDF) el 15 de mayo de 2013. Consultado el 23 de septiembre de 2013 .
  29. ^ R. Kent Koeninger (junio de 2003). "The Ultra-Scalable HPTC Lustre Filesystem" (PDF) . Diapositivas para la presentación en Cluster World 2003. Consultado el 23 de septiembre de 2013 .
  30. ^ Britta Wülfing (13 de septiembre de 2007). "Sun asimila el sistema de archivos Lustre". Linux Magazine . Consultado el 23 de septiembre de 2013 .
  31. ^ "Sun Microsystems amplía su cartera de productos informáticos de alto rendimiento con un acuerdo definitivo para adquirir activos de sistemas de archivos en clúster, incluido el sistema de archivos Lustre". Nota de prensa . Sun Microsystems. 12 de septiembre de 2007. Archivado desde el original el 2 de octubre de 2007 . Consultado el 23 de septiembre de 2013 .
  32. ^ "Oracle ha dejado a Lustre en el camino". Inside HPC. 10 de enero de 2011.
  33. ^ J. Leidel (20 de agosto de 2010). "Whamcloud pretende garantizar que Lustre tenga un futuro en HPC". Inside HPC . Consultado el 23 de septiembre de 2013 .
  34. ^ ab "Xyratex avanza con la iniciativa Lustre® y asume la propiedad de los activos relacionados". Nota de prensa . Xyratex. 19 de febrero de 2013. Archivado desde el original el 7 de septiembre de 2016 . Consultado el 18 de septiembre de 2013 .
  35. ^ Rich Brueckner (9 de noviembre de 2010). "Bojanic y Braam vuelven a juntar a Lustre Band en Xyratex". Dentro de HPC . Consultado el 23 de septiembre de 2013 .
  36. ^ Rich Brueckner (4 de enero de 2011). "Whamcloud Staffs up for Brighter Lustre". Inside HPC . Consultado el 18 de septiembre de 2013 .
  37. ^ "Whamcloud firma contrato de desarrollo multianual de Lustre con OpenSFS". Nota de prensa . HPC Wire. 16 de agosto de 2011. Archivado desde el original el 25 de enero de 2013 . Consultado el 23 de septiembre de 2013 .
  38. ^ Galen Shipman (18 de noviembre de 2011). "Actualización de OpenSFS" (PDF) . Diapositivas de la presentación Supercomputing 2011. Sistemas de archivos escalables abiertos . Consultado el 23 de septiembre de 2013 .
  39. ^ Whamcloud (15 de noviembre de 2011). «OpenSFS y Whamcloud firman un acuerdo de desarrollo del árbol comunitario Lustre». Nota de prensa . Archivado desde el original el 27 de abril de 2012. Consultado el 23 de septiembre de 2013 .
  40. ^ Joab Jackson (16 de julio de 2012). "Intel compra al proveedor de Lustre Whamcloud". PC World.
  41. ^ Timothy Prickett Morgan (16 de julio de 2012). "Intel se traga a Whamcloud, experto en sistemas de archivos Lustre". The Register.
  42. ^ Timothy Prickett Morgan (11 de julio de 2012). "El Departamento de Energía reparte dinero a AMD y Whamcloud para la investigación en exaescala". The Register.
  43. ^ Nicole Hemsoth (12 de junio de 2013). "Intel se abre paso hacia el mercado convencional para Lustre". HPC Wire . Consultado el 23 de septiembre de 2013 .
  44. ^ Brueckner, Rich (21 de febrero de 2013). "Con la nueva RFP, OpenSFS invertirá en tecnologías críticas de código abierto para HPC". insideHPC . Consultado el 1 de octubre de 2013 .
  45. ^ "Seagate dona Lustre.org a la comunidad de usuarios" . Consultado el 9 de septiembre de 2014 .
  46. ^ Daniel Robinson (27 de junio de 2018). "DDN insufla nueva vida al sistema de archivos Lustre".
  47. ^ "Se libera la marca registrada Lustre a la comunidad de usuarios". InsideHPC. 24 de noviembre de 2019. Consultado el 5 de diciembre de 2019 .
  48. ^ "Lustre ayuda a impulsar la tercera supercomputadora más rápida". DSStar. Archivado desde el original el 3 de febrero de 2013.
  49. ^ "MCR Linux Cluster Xeon 2.4 GHz – Quadrics". Top500.Org. Archivado desde el original el 20 de abril de 2012. Consultado el 14 de diciembre de 2023 .
  50. ^ Peter Bojanic (15 de junio de 2008). "Hoja de ruta y planes futuros de Lustre" (PDF) . Presentación ante el Sun HPC Consortium . Sun Microsystems . Consultado el 23 de septiembre de 2013 .
  51. ^ "OpenSFS anuncia un esfuerzo colaborativo para respaldar la distribución comunitaria Lustre 2.1". Open Scalable File Systems. 8 de febrero de 2011. Archivado desde el original el 23 de mayo de 2011. Consultado el 13 de diciembre de 2016 .
  52. ^ "Lanzamiento de Lustre 2.1" . Consultado el 2 de febrero de 2012 .
  53. ^ "Lanzamiento de Lustre 2.2". Yahoo! Finance . Consultado el 8 de mayo de 2012 .
  54. ^ "Un nuevo programador de solicitudes de red para un sistema de almacenamiento a gran escala" (PDF) . Lustre Wiki . OpenSFS . Junio ​​de 2009.
  55. ^ "Un nuevo programador de solicitudes de red para un sistema de almacenamiento a gran escala". Lustre Wiki . OpenSFS . Junio ​​de 2009.
  56. ^ Prickett Morgan, Timothy (5 de noviembre de 2013). "OpenSFS anuncia la disponibilidad de Lustre 2.5". EnterpriseTech.
  57. ^ Brueckner, Rich. "Video: La nueva versión de Lustre 2.5 ofrece capacidades de HSM". Inside Big Data. Archivado desde el original el 8 de diciembre de 2013. Consultado el 11 de diciembre de 2013 .
  58. ^ Hemsoth, Nicole. "Lustre obtiene una mejora a la clase ejecutiva con HSM". HPCwire. Archivado desde el original el 17 de diciembre de 2013. Consultado el 11 de diciembre de 2013 .
  59. ^ "Lustre 2.5". Scientific Computing World. 12 de noviembre de 2013. Consultado el 11 de diciembre de 2013 .
  60. ^ Jones, Peter (9 de septiembre de 2014). «Lanzamiento de Lustre 2.5.3». Archivo de la lista de correo HPDD-discuss . Archivado desde el original el 17 de octubre de 2014. Consultado el 21 de octubre de 2014 .Morrone, Chris (7 de diciembre de 2015). «Retired Release Terminology» (Terminología de versiones retiradas). Lustre Wiki . Consultado el 18 de enero de 2016 .
  61. ^ "Lanzamiento de Lustre 2.6.0". Archivo de la lista de correo HPDD-discuss . 30 de julio de 2014. Archivado desde el original el 17 de octubre de 2014. Consultado el 21 de octubre de 2014 .
  62. ^ Ihara, Shuichi (14 de octubre de 2014). "Calidad de servicio de Lustre basada en la política NRS del filtro de token bucket" (PDF) .
  63. ^ Uselton, Andrew. "Demostración de la mejora en el rendimiento de un único cliente Lustre de la versión 1.8 a la versión 2.6" (PDF) . Consultado el 18 de octubre de 2014 .
  64. ^ Jones, Peter (13 de marzo de 2015). «Lanzamiento de Lustre 2.7.0». Archivo de la lista de correo HPDD-discuss . Archivado desde el original el 2 de abril de 2015. Consultado el 15 de marzo de 2015 .
  65. ^ Jones, Peter (16 de marzo de 2016). «Lustre 2.8.0 lanzado». Archivo de la lista de correo Lustre-announce . OpenSFS . Consultado el 28 de marzo de 2016 .
  66. ^ "Registro de cambios de Lustre 2.9.0". Wiki Lustre . AbiertoSFS . 7 de diciembre de 2016 . Consultado el 8 de diciembre de 2016 .
  67. ^ "Registro de cambios de Lustre 2.10.0". Wiki de Lustre . OpenSFS . 13 de julio de 2017 . Consultado el 3 de octubre de 2017 .
  68. ^ "Versión 2.11.0". Wiki de Lustre . OpenSFS . 3 de abril de 2018. Consultado el 4 de abril de 2018 .
  69. ^ "Versión 2.12.0". Wiki de Lustre . OpenSFS . 21 de diciembre de 2018. Consultado el 11 de febrero de 2019 .
  70. ^ Li Xi, DDN (junio de 2018). "Lazy Size on MDS" (PDF) . Lustre Wiki . Consultado el 5 de diciembre de 2019 .
  71. ^ Shuichi Ihara, DDN (junio de 2018). "Protección de integridad de datos de extremo a extremo T10PI para Lustre" (PDF) . Wiki Lustre . Consultado el 5 de diciembre de 2019 .
  72. ^ "Versión 2.13.0". Wiki Lustre . OpenSFS . 5 de diciembre de 2019 . Consultado el 5 de diciembre de 2019 .
  73. ^ Li Xi, Whamcloud (junio de 2018). «Lustre Persistent Client Cache» (PDF) . Wiki de Lustre . Consultado el 5 de diciembre de 2019 .
  74. ^ Patrick Farrell, Whamcloud (abril de 2019). "Overstriping: extracción del máximo rendimiento de archivos compartidos" (PDF) . Lustre Wiki . Consultado el 5 de diciembre de 2019 .
  75. ^ Patrick Farrell, Cray (15 de marzo de 2019). "Spillover Space: Self-Extending Layouts HLD" (PDF) . Consultado el 5 de diciembre de 2019 .
  76. ^ "Registro de cambios de Lustre 2.13.0". Wiki Lustre . 5 de diciembre de 2019.
  77. ^ "Versión 2.14.0". Wiki de Lustre . OpenSFS . 19 de febrero de 2021 . Consultado el 19 de febrero de 2021 .
  78. ^ Sébastien Buisson (11 de mayo de 2022). "Cifrado de datos del cliente" (PDF) . Wiki Lustre . AbiertoSFS . Consultado el 17 de junio de 2022 .
  79. ^ "Guía general de almacenamiento NVIDIA Magnum IO GPUDirect". NVIDIA . Consultado el 17 de junio de 2022 .
  80. ^ "Lustre se ejecutará en ZFS". Government Computer News. 26 de octubre de 2008. Archivado desde el original el 2 de octubre de 2012. Consultado el 23 de febrero de 2011 .
  81. ^ "ZFS en Lustre". 10 de mayo de 2011. Archivado desde el original el 5 de diciembre de 2011. Consultado el 25 de noviembre de 2011 .
  82. ^ "DataDirect seleccionada como tecnología de almacenamiento para BlueGene/L". HPC Wire . 15 de octubre de 2004. Archivado desde el original el 14 de junio de 2013. Consultado el 9 de mayo de 2012 .
  83. ^ Suzanne M. Kelly (2006). "Arquitectura de software Catamount con extensiones de doble núcleo" (PDF) . Consultado el 16 de febrero de 2016 .
  84. ^ "Notas de la versión del kernel de Linux 4.18rc1".
  85. ^ Andreas Dilger (20 de mayo de 2021). "Lustre 2.15 y más allá" (PDF) . Sistemas de archivos abiertos y escalables.
  86. ^ Shehata, Amir. "Multi-Rail LNet para Lustre" (PDF) . Grupo de usuarios de Lustre, abril de 2016.
  87. ^ Lafoucrière, Jacques-Charles. "Lustre Experience at CEA/DIF" (PDF) . Foro HEPiX, abril de 2007. Archivado desde el original (PDF) el 8 de febrero de 2012.
  88. ^ Caldwell, Blane (9 de marzo de 2016). "Lustre Networking Technologies: Ethernet vs. Infiniband" (PDF) . Centro de excelencia Lustre de la OLCF . Consultado el 6 de diciembre de 2019 .
  89. ^ Aurélien Degrémont (17 de septiembre de 2013). "¡LA ENCUADERNACIÓN LUSTRE/HSM ESTÁ AHÍ!" (PDF) .
  90. ^ Thomas Stibor (20 de septiembre de 2016). "TSM Copytool para Lustre HSM" (PDF) .
  91. ^ Robert Read (24 de marzo de 2015). "Lustre HSM en la nube" (PDF) .
  92. ^ Stéphane Thiell (11 de abril de 2021). «Herramienta de copia de Google Drive Lustre/HSM». GitHub .
  93. ^ Aurélien Degrémont; Thomas Leibovici (16 de abril de 2009). "Lustre HSM Project—Lustre User Advanced Seminars" (PDF) . Archivado (PDF) desde el original el 25 de mayo de 2010 . Consultado el 5 de mayo de 2018 .
  94. ^ "El sistema de archivos Orion: configuración y rendimiento" (PDF) . Laboratorio Nacional de Oak Ridge. 3 de mayo de 2023.
  95. ^ "LNCC - Laboratório Nacional de Computação Científica". Lncc.br. ​Consultado el 27 de mayo de 2015 .
  96. ^ "Supercomputadora de las Pléyades". www.nas.nasa.gov. 18 de agosto de 2008.
  97. ^ "Lista TOP500 – Noviembre 2006". TOP500.Org. Archivado desde el original el 10 de mayo de 2012. Consultado el 29 de agosto de 2008 .
  98. ^ "Lista TOP500 – Junio ​​2006". TOP500.Org. Archivado desde el original el 12 de mayo de 2012. Consultado el 29 de agosto de 2008 .
  99. ^ "El grupo francés de energía atómica amplía el sistema de archivos HPC a 11 petabytes". HPCwire.com. 2012-06-15. Archivado desde el original el 2012-02-04 . Consultado el 2012-06-15 .
  100. ^ "Recurso compartido de archivos escalable HP StorageWorks". Hewlett-Packard. Archivado desde el original el 12 de junio de 2008. Consultado el 13 de diciembre de 2016 .
  101. ^ "Fujitsu lanza el sistema de archivos de mayor rendimiento del mundo: el software de sistema de archivos escalable FEFS para sistemas de clúster HPC x86 avanzados". 13 de junio de 2015.
  102. ^ "Soluciones de almacenamiento de alto rendimiento con Lustre". 14 de abril de 2015. Archivado desde el original el 27 de junio de 2015. Consultado el 14 de abril de 2015 .
  103. ^ "Exascaler: dispositivo de sistema de archivos Lustre de alto rendimiento y escalabilidad masiva". 14 de abril de 2015.
  104. ^ "Soporte de Lustre". 27 de noviembre de 2018.
  105. ^ "Amazon FSx para Lustre". 11 de junio de 2019.
  106. ^ "Azure Managed Lustre: sistema de archivos paralelos administrado | Microsoft Azure". azure.microsoft.com . Consultado el 14 de octubre de 2024 .
  • Sitio web oficial

Documentación

  • Comprensión de los componentes internos de Lustre, segunda edición
    • Funcionamiento interno del sistema de archivos Lustre y sus subsistemas principales

Wikis de información

  • Wiki de la comunidad de Lustre
  • Wiki de Lustre (DDN)
  • Wiki de Lustre (OpenSFS)

Fundaciones comunitarias

  • OpenSFS
  • EOFS – Sistema Europeo de Archivos Abiertos

Proveedores de hardware y software

  • Redes DataDirect (DDN)
  • Hewlett Packard Enterprise / Cray (incluidos antiguos empleados de Xyratex [1] )
  • Aplicación NetApp
  • Computación Aeon
  1. ^ Black, Doug (28 de julio de 2017). "Cray avanza para adquirir la línea ClusterStor de Seagate". HPCWire . Consultado el 1 de diciembre de 2017 .
Obtenido de "https://es.wikipedia.org/w/index.php?title=Lustre_(sistema_de_archivos)&oldid=1251137239"