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]
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]
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.
Un sistema de archivos Lustre tiene tres unidades funcionales principales:
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.
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.
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.
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]
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.
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]
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.
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:
HSM también define nuevos estados para los archivos, incluidos: [93]
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.
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.
.svg/1280px-Free_and_open-source_software_logo_(2009).svg.png){kind=logo}
{{cite web}}: CS1 maint: varios nombres: lista de autores ( enlace ){{cite web}}: CS1 maint: varios nombres: lista de autores ( enlace ){{citation}}: CS1 maint: varios nombres: lista de autores ( enlace ){{cite web}}: CS1 maint: bot: estado de URL original desconocido ( enlace )