Lustre es un tipo de sistema de archivos distribuido en paralelo , generalmente utilizado para la computación en clúster a gran escala . El nombre Lustre es una palabra derivada de Linux y clúster . [5] El software del sistema de archivos Lustre está disponible bajo la Licencia Pública General GNU (solo versión 2) y proporciona sistemas de archivos de alto rendimiento para grupos de computadoras que varían en tamaño, desde grupos de grupos de trabajo pequeños hasta sistemas de sitios múltiples 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, [6] [7] [8]incluyendo la supercomputadora TOP500 número 1 del mundo en junio de 2020, Fugaku , [9] así como las supercomputadoras superiores anteriores como Titan [10] y Sequoia . [11]
Versión inicial | 16 de diciembre de 2003 [1] |
---|---|
Lanzamiento estable | |
Repositorio | |
Escrito en | C |
Sistema operativo | Kernel de Linux |
Tipo | Sistema de archivos distribuido |
Licencia | GPL v2 LGPL |
Sitio web | www |
Tipo | Privado |
---|---|
Fundado | 2001 |
Fundador | Peter J. Braam |
Sede | |
Gente clave | Andreas Dilger , Eric Barton (HPC) , Phil Schwan |
Productos | Sistema de archivos Lustre |
Introducido | Diciembre de 2003 con Linux |
---|---|
Estructuras | |
Contenidos del directorio | Hash, Hash intercalado con DNE en 2.7+ |
Tipo de archivo | archivo, directorio, enlace duro, enlace simbólico, especial de bloque, especial de carácter, socket, FIFO |
De arranque | No |
Limites | |
Min. tamaño del volumen | 32 MB |
Max. tamaño del volumen | 300 PB (producción), más de 16 EB (teórico) |
Max. tamaño del archivo | 3,2 PB (ext4), 16 EB (ZFS) |
Granularidad del tamaño de archivo | 4 KB |
Max. Número de archivos | Por meta de metadatos (MDT): 4 mil millones de archivos (backend ldiskfs), 256 billones de archivos (backend ZFS), [4] hasta 128 MDT por sistema de archivos |
Max. longitud del nombre de archivo | 255 bytes |
Max. longitud de dirname | 255 bytes |
Max. profundidad del directorio | 4096 bytes |
Caracteres permitidos en nombres de archivo | Todos los bytes excepto NUL ('\ 0') y '/' y los nombres de archivo especiales "." y ".." |
Características | |
Fechas registradas | modificación (mtime), modificación de atributo (ctime), acceso (atime), eliminar (dtime), crear (crtime) |
Rango de fechas | 2 ^ 34 bits (ext4), 2 ^ 64 bits (ZFS) |
Resolución de fecha | 1 s |
tenedores | No |
Atributos | 32bitapi, acl, suma de comprobación, bandada, 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+) |
Deduplicación de datos | Sí (solo ZFS) |
Copiar en escrito | Sí (solo ZFS) |
Otro | |
Apoyados sistemas operativos | Kernel de Linux |
Los sistemas de archivos Lustre son escalables y pueden formar parte de múltiples clústeres de computadoras con decenas de miles de nodos de cliente , decenas de petabytes (PB) de almacenamiento en cientos de servidores y más de un terabyte por segundo (TB / s) de I / O rendimiento . [12] [13] Esto hace que los sistemas de archivos Lustre sean una opción popular para las empresas con grandes centros de datos, incluidos los de industrias como meteorología , simulación , [14] petróleo y gas, ciencias biológicas , rich media y finanzas. [15] El rendimiento de E / S de Lustre tiene un impacto generalizado en estas aplicaciones y ha atraído una amplia atención. [16] [17] [18] [19]
Historia
La arquitectura del sistema de archivos Lustre se inició como un proyecto de investigación en 1999 por Peter J. Braam , que en ese momento formaba parte del personal de la Universidad Carnegie Mellon (CMU). Braam fundó su propia empresa Cluster File Systems en 2001, [20] a partir del trabajo en el sistema de archivos InterMezzo en el proyecto Coda en CMU. [21] Lustre se desarrolló en el marco del proyecto Path Forward de la Iniciativa de Computación Estratégica Acelerada , financiado por el Departamento de Energía de Estados Unidos , que incluía a Hewlett-Packard e Intel . [22] En septiembre de 2007, Sun Microsystems adquirió los activos de Cluster File Systems Inc., incluida su propiedad intelectual. [23] [24] Sun incluyó Lustre con sus ofertas de hardware informático 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 , mediante la adquisición de Sun, comenzó a administrar y lanzar Lustre.
En diciembre de 2010, Oracle anunció que dejarían de desarrollar Lustre 2.xy colocarían a Lustre 1.8 en soporte de solo mantenimiento, creando incertidumbre sobre el desarrollo futuro del sistema de archivos. [25] Tras este anuncio, surgieron varias organizaciones nuevas para brindar apoyo y desarrollo en un modelo de desarrollo comunitario abierto, como Whamcloud, [26] Open Scalable File Systems, Inc. (OpenSFS) , EUROPEAN Open File Systems (EOFS) y otros. . A finales de 2010, la mayoría de los desarrolladores de Lustre habían dejado Oracle. Braam y varios asociados se unieron al Xyratex orientado al hardware cuando adquirió los activos de ClusterStor, [27] [28] mientras que Barton, Dilger y otros formaron el inicio de software Whamcloud , donde continuaron trabajando en Lustre. [29]
En agosto de 2011, OpenSFS otorgó un contrato para el desarrollo de funciones de Lustre a Whamcloud. [30] Este contrato cubría la finalización de funciones, incluida la mejora de la escalabilidad del rendimiento de metadatos de servidor único, que permite a Luster aprovechar mejor el servidor de metadatos de muchos núcleos; verificació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 Entorno de espacio de nombres distribuido (DNE), anteriormente Metadatos en clúster (CMD), que permite que los metadatos de Lustre se distribuyan en varios servidores. El desarrollo también continuó en el almacenamiento de objetos back-end basado en ZFS en el Laboratorio Nacional Lawrence Livermore . [11] Estas características estaban en la hoja de ruta de lanzamiento de la comunidad Lustre 2.2 a 2.4. [31] En noviembre de 2011, se otorgó un contrato separado a Whamcloud para el mantenimiento del código fuente de Lustre 2.x para garantizar que el código de Lustre recibiera suficientes pruebas y corrección de errores mientras se desarrollaban nuevas funciones. [32]
En julio de 2012 , Intel adquirió Whamcloud , [33] [34] después de que Whamcloud ganara el contrato FastForward DOE para extender Lustre para sistemas informáticos de exaescala en el período de 2018. [35] OpenSFS luego transfirió los contratos para el desarrollo de Lustre a Intel.
En febrero de 2013, Xyratex Ltd. anunció que adquirió de Oracle la marca comercial, el logotipo, el sitio web y la propiedad intelectual asociada de Lustre originales. [27] En junio de 2013, Intel comenzó a expandir el uso de Lustre más allá de HPC tradicional, como dentro de Hadoop . [36] 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. [37] OpenSFS también estableció el Lustre Community Portal, un sitio técnico que proporciona una colección de información y documentación en un área como referencia y guía 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, [38] y esto se completó en marzo de 2015.
En junio de 2018, DDN adquirió el equipo y los activos de Lustre de Intel . DDN organizó la nueva adquisición como una división independiente, reviviendo el nombre de Whamcloud para la nueva división. [39]
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 . [40]
Historial de versiones
El sistema de archivos Lustre se instaló por primera vez para su uso en producción en marzo de 2003 en el clúster de Linux MCR en el Laboratorio Nacional Lawrence Livermore , [41] uno de los superordenadores más grandes de la época. [42]
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 la conmutación por error del servidor.
Lustre 1.2.0, lanzado en marzo de 2004, funcionaba en el kernel 2.6 de Linux y tenía una función de "vislumbre de tamaño" para evitar la revocación de bloqueos en archivos en proceso de escritura y contabilidad de caché de escritura diferida del lado del cliente (concesión).
Lustre 1.4.0, lanzado en noviembre de 2004, proporcionó compatibilidad de protocolo entre versiones, podría usar redes InfiniBand y podrí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 objetivos de almacenamiento de objetos (OST), habilitó el administrador de bloqueo distribuido de Lustre (LDLM ) escalabilidad en servidores de multiprocesamiento simétrico (SMP) y administración de espacio libre para asignaciones de objetos.
Lustre 1.8.0, lanzado en mayo de 2009, proporcionó OSS Read Cache, mejoró la recuperación ante múltiples fallas, agregó administración básica de almacenamiento heterogéneo a través de OST Pools, tiempos de espera de red adaptativos y recuperación basada en versiones. Fue una versión de transición, siendo interoperable tanto con Lustre 1.6 como con Lustre 2.0. [43]
Lustre 2.0, lanzado en agosto de 2010, se basó en un importante código reestructurado internamente para prepararse para los principales avances arquitectónicos. Los clientes de Lustre 2.x no pueden interoperar con servidores 1.8 o anteriores . Sin embargo, los clientes de Luster 1.8.6 y posteriores pueden interoperar con los servidores de Luster 2.0 y posteriores. El formato en disco de Metadata Target (MDT) y OST de 1.8 se puede actualizar a 2.0 y posterior sin la 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 que Oracle suspendiera el desarrollo en las versiones de Lustre 2.x. [44] Agregó 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, [45] así como una serie de mejoras de rendimiento y estabilidad. Los servidores Lustre 2.1 siguieron siendo interoperables con los clientes 1.8.6 y posteriores.
Lustre 2.2, lanzado en marzo de 2012, se centró en proporcionar mejoras de rendimiento de metadatos y nuevas funciones. [46] Agregó operaciones de directorio paralelo que permiten a varios clientes atravesar y modificar un único directorio grande al mismo tiempo, recuperación más rápida de fallas del servidor, mayor número de bandas para un solo archivo (hasta 2000 OST) y mejor desempeño transversal 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 internos en nodos con muchos núcleos de CPU (más de 16). El almacén de objetos agregó una capacidad preliminar para utilizar ZFS como sistema de archivos de respaldo. La función Lustre File System ChecK (LFSCK) puede verificar y reparar el índice de objetos MDS (OI) mientras el sistema de archivos está en uso, después de una copia de seguridad / restauración a nivel de archivo o en caso de corrupción de MDS. Las estadísticas de E / S del lado del servidor se mejoraron para permitir la integración con 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 que funcione con kernels de Linux hasta la versión 3.0.
Lustre 2.4, lanzado en mayo de 2013, agregó un número considerable de características principales, muchas financiadas directamente a través de OpenSFS . El entorno de espacio de nombres distribuido (DNE) permite la capacidad de metadatos horizontal y la escala de 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 sistema de archivos de respaldo para almacenamiento MDT y OST. La función LFSCK agregó la capacidad de escanear y verificar la consistencia interna de los atributos MDT FID y LinkEA. El Programador de solicitudes de red [47] [48] (NRS) agrega políticas para optimizar el procesamiento de solicitudes del cliente para el pedido de discos o la equidad. Los clientes pueden enviar opcionalmente RPC masivos de hasta 4 MB de tamaño. El software del lado del cliente se actualizó para que funcione con los kernels de Linux hasta la versión 3.6 y aún es interoperable con los clientes 1.8.
Lustre 2.5, lanzado en octubre de 2013, agregó la característica muy esperada, Hierarchical Storage Management (HSM). HSM, un requisito fundamental en los entornos empresariales, permite a los clientes implementar fácilmente soluciones de almacenamiento por niveles en su entorno operativo. Esta versión es la rama actual de la versión de mantenimiento designada por OpenSFS de Lustre. [49] [50] [51] [52] La versión de mantenimiento más reciente es 2.5.3 y se publicó en septiembre de 2014. [53]
Lustre 2.6, lanzado en julio de 2014, [54] fue una característica de lanzamiento más modesta, agregando 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 [55] (TBF). El rendimiento de E / S de un solo cliente se mejoró con respecto a las versiones anteriores. [56] Esta versión también agregó una vista previa de los directorios seccionados 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, [57] agregó la funcionalidad LFSCK para verificar la consistencia DNE de directorios remotos y seccionados entre múltiples MDT. Dynamic LNet Config agrega la capacidad de configurar y modificar interfaces, rutas y enrutadores de red LNet en tiempo de ejecución. Se agregó una nueva función de evaluación para el mapeo UID / GID para clientes con diferentes dominios administrativos, junto con mejoras en la funcionalidad de directorio seccionado de DNE.
Lustre 2.8, lanzado en marzo de 2016, [58] finalizó la función de directorio seccionado de DNE, incluida la compatibilidad con la migración de directorios entre MDT y el enlace duro entre MDT y el cambio de nombre. Además, incluyó soporte mejorado para Linux con seguridad mejorada ( SELinux ) en el cliente, autenticación Kerberos y cifrado RPC en la red, y mejoras de rendimiento para LFSCK.
Lustre 2.9 se lanzó en diciembre de 2016 [59] e incluía una serie de funciones relacionadas con la seguridad y el rendimiento. El tipo de seguridad de clave secreta compartida utiliza el mismo mecanismo GSSAPI que Kerberos para proporcionar autenticación de nodo de servidor y cliente, e integridad y seguridad de mensajes RPC (cifrado). La función Nodemap permite clasificar los nodos del 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 solo conjunto de UID / GID para todos los nodos del cliente. La función de montaje de subdirectorios permite a los clientes montar un subconjunto del espacio de nombres del sistema de archivos desde el MDS. Esta versión también agregó soporte para RPC de hasta 16MiB para un envío de E / S al disco más eficiente, y agregó la ladvise
interfaz para permitir que los clientes proporcionen sugerencias de E / S a los servidores para obtener datos de archivos en la caché del servidor o vaciar los datos de archivos de la caché del servidor. . Se mejoró el soporte para especificar grupos OST predeterminados en todo el sistema de archivos y se mejoró la herencia de grupos OST junto con otros parámetros de diseño de archivos.
Lustre 2.10 se lanzó en julio de 2017 [60] y presenta una serie de mejoras significativas. La función LNet Multi-Rail (LMR) permite vincular 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 utilizar diseños de archivos compuestos que se construyen con varios componentes, que son regiones de archivo basadas en el desplazamiento del archivo, que permiten diferentes parámetros de diseño, como el recuento de bandas, el grupo de OST / tipo de almacenamiento, etc. El diseño de archivo progresivo (PFL) es el La primera característica en usar diseños compuestos, pero la implementación es flexible para su uso con otros diseños de archivos, como la codificación de duplicación y borrado. El programador del lado del servidor del Filtro de depósito de tokens de NRS (TBF) ha implementado nuevos tipos de reglas, incluida la programación de tipo RPC y la capacidad de especificar varios parámetros como JobID y NID para la coincidencia de reglas. Se han agregado herramientas para administrar las instantáneas ZFS de los sistemas de archivos Lustre, para simplificar la creación, el montaje y la administración de las instantáneas MDT y OST ZFS como puntos de montaje independientes de Lustre.
Lustre 2.11 se lanzó en abril de 2018 [61] y contiene dos nuevas funciones importantes y varias funciones más pequeñas. La función File Level Redundancy (FLR) amplía la implementación 2.10 PFL, agregando la capacidad de especificar diseños de archivos reflejados para mejorar la disponibilidad en caso de falla de almacenamiento o servidor y / o rendimiento mejorado con lecturas altamente concurrentes. La función Data-on-MDT (DoM) permite almacenar archivos pequeños (pocos MiB) en MDT para aprovechar el almacenamiento RAID-10 basado en flash típico para una latencia más baja y una contención de IO reducida, en lugar del almacenamiento RAID-6 HDD típico utilizado en OST. Además, la función 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 debidamente modificadas obtengan previamente 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 un futuro cercano, lo que puede reducir la contención de bloqueos para varios clientes que escriben en el mismo archivo.
Lustre 2.12 se lanzó el 21 de diciembre de 2018 [62] y se centró en mejorar la usabilidad y estabilidad de Lustre, con mejoras en el rendimiento y la funcionalidad de las funciones FLR y DoM agregadas en Lustre 2.11, así como cambios más pequeños en NRS TBF , HSM y JobStats. Agregó el estado de la red LNet para permitir que la función LNet Multi-Rail de Lustre 2.10 maneje mejor las fallas de la red cuando un nodo tiene múltiples interfaces de red. La función Lazy Size on MDT [63] (LSOM) permite almacenar una estimación del tamaño de archivo en MDT para su uso por motores de políticas, escáneres de sistemas de archivos y otras herramientas de administración que pueden tomar decisiones de manera más eficiente sobre archivos sin un tamaño de archivo totalmente preciso o los bloques cuentan sin tener que consultar los OST para obtener esta información. Esta versión también agregó la capacidad de volver a crear manualmente un directorio existente en múltiples MDT, para permitir la migración de directorios con una gran cantidad de archivos para usar la capacidad y el rendimiento de varios nodos MDS. La suma de comprobación de datos Lustre RPC agregó sumas de comprobación de datos integrados SCSI T10-PI [64] desde el cliente a la capa de bloques del kernel, el adaptador de host SCSI y los discos duros habilitados para T10 .
Lustre 2.13 se lanzó el 5 de diciembre de 2019 [65] y agregó nuevas características relacionadas con el rendimiento Caché de cliente persistente [66] (PCC), que permite el uso directo del almacenamiento NVMe y NVRAM en los nodos cliente mientras mantiene los archivos como parte del el espacio de nombres del sistema de archivos global y OST Overstriping [67] que permite que los archivos almacenen múltiples bandas en un solo OST para utilizar mejor el hardware OSS rápido. Además, se mejoró la funcionalidad de estado de la red LNet Multi-Rail para que funcione con los nodos del enrutador LNet RDMA. La funcionalidad PFL se mejoró con diseños autoexpandibles [68] (SEL) para permitir que los componentes del archivo se dimensionen dinámicamente, para tratar mejor los OST flash que pueden ser mucho más pequeños que los OST de disco dentro del mismo sistema de archivos. La versión también incluyó una serie de mejoras menores, como el equilibrio de la creación de directorios remotos de DNE en MDT, el uso de Lazy-size-on-MDT para reducir la sobrecarga de "lfs find", directorios con 10 millones de archivos por fragmento para ldiskfs y RPC masivo. tamaños de hasta 64 MB. [69]
Lustre 2.14 se lanzó el 19 de febrero de 2021 [2] e incluye tres características principales. El cifrado de datos del cliente implementa fscrypt para permitir que los datos del archivo se cifren en el cliente antes de la transferencia de red y el almacenamiento persistente en OST y MDT. OST Pool Quotas amplía el marco de cuotas para permitir la asignación y el cumplimiento de cuotas sobre la base de los pools de almacenamiento OST. DNE Auto Restriping ahora puede ajustar cuántos MDT se seccionan en un directorio grande en función de los umbrales de tamaño definidos por el administrador, similar a los diseños de archivos progresivos para directorios.
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 espacio 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 Lustre solo participa en las verificaciones de permisos y nombres de ruta, y no participa en ninguna operación de E / S de archivos. , evitando cuellos de botella de escalabilidad de E / S en el servidor de metadatos. La capacidad de tener múltiples MDT en un solo sistema de archivos es una nueva característica en Lustre 2.4, y permite que los subárboles de directorio residan en los MDT secundarios, mientras que 2.7 y posteriores permiten que grandes directorios individuales también se distribuyan entre múltiples MDT.
- Uno o más nodos de servidor de almacenamiento de objetos (OSS) que almacenan datos de archivo en uno o más dispositivos de destino de almacenamiento de objetos (OST) . Dependiendo del hardware del servidor, un OSS generalmente sirve entre dos y ocho OST, y cada OST administra 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 en el sistema de archivos, utilizando la semántica POSIX estándar , y permite el acceso de lectura y escritura simultánea y coherente a los archivos en el sistema de archivos.
El MDT, OST y el cliente pueden estar en el mismo nodo (generalmente con fines de prueba), pero en instalaciones de producción típicas, estos dispositivos se encuentran en nodos separados que se comunican a través de una red. Cada MDT y OST pueden ser parte de un solo sistema de archivos, aunque es posible tener múltiples MDT u OST en un solo nodo que son parte de diferentes sistemas de archivos. La capa Lustre Network (LNet) puede utilizar varios tipos de interconexiones de red, incluidos los verbos nativos InfiniBand , Omni-Path , RoCE e iWARP a través de OFED , TCP / IP en Ethernet y otras tecnologías de red patentadas como la interconexión Cray Gemini. En Lustre 2.3 y versiones anteriores, las redes Myrinet , Quadrics , Cray SeaStar y RapidArray también eran compatibles, 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 remoto directo a memoria ( 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á con cualquier dispositivo de bloque. Desde Lustre 2.4, MDT y OST también pueden usar ZFS para el sistema de archivos de respaldo además de ext4 , lo que les permite usar de manera efectiva 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 que Lustre aproveche las mejoras y funciones del sistema de archivos subyacente, como la compresión y las sumas de comprobación de datos en ZFS. Los clientes no tienen acceso directo al almacenamiento subyacente, lo que garantiza que un cliente malintencionado o que funcione mal 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 coherencia 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 back-end para almacenar archivos / objetos [70] usando el puerto ZFS-on-Linux de código abierto. [71]
El cliente monta el sistema de archivos Lustre localmente con un controlador VFS para el kernel de Linux que conecta al cliente con los servidores. Tras el montaje inicial, se 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 MDS y el usuario y el cliente tienen permiso para acceder y / o crear el archivo, el diseño de un archivo existente se devuelve al cliente o se crea un nuevo archivo en nombre del cliente, si así lo 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 tamaño y el desplazamiento lógico del archivo a uno o más objetos . Luego, el cliente bloquea el rango de archivos en el que se opera y ejecuta una o más operaciones de lectura o escritura en paralelo directamente en los nodos OSS que contienen los objetos de datos. Con este enfoque, se eliminan los cuellos de botella para las comunicaciones de cliente a OSS, por lo que el ancho de banda total disponible para que los clientes lean y escriban datos escale casi linealmente con el número de OST en el sistema de archivos.
Después de la búsqueda inicial del diseño del archivo, el MDS normalmente no participa en las operaciones de E / S de archivo, ya que el OST gestiona internamente toda la asignación de bloques y E / S de datos. Los clientes no modifican directamente los objetos o 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 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 SAN de back-end grande adjunta a todos los clientes, y aumenta el riesgo de corrupción del sistema de archivos por parte de todos los clientes. Clientes que se portan mal / defectuosos.
Implementación
En una instalación típica de Lustre en un cliente Linux, un módulo de controlador del sistema de archivos Lustre se carga en el kernel y el sistema de archivos se monta como cualquier otro sistema de archivos local o de red. Las aplicaciones cliente ven un único sistema de archivos unificado, aunque puede estar compuesto por decenas a 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 [72] en el Laboratorio Nacional Lawrence Livermore .
Otro enfoque utilizado en los primeros años de Lustre es la biblioteca liblustre en el Cray XT3 usando el sistema operativo Catamount en sistemas como Sandia Red Storm , [73] que proporcionaba a las aplicaciones de espacio de usuario acceso directo al sistema de archivos. Liblustre era una biblioteca a nivel de usuario que permite a los procesadores computacionales montar y usar el sistema de archivos Lustre como cliente. Con liblustre, los procesadores computacionales pueden acceder a un sistema de archivos Lustre incluso si el nodo de servicio en el que se inició 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 Luster sin requerir una copia de datos intermedia a través del kernel, proporcionando así acceso desde procesadores computacionales al sistema de archivos Luster 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 migración a kernels más nuevos. [74] El cliente y servidor Lustre fuera del árbol todavía está disponible para los núcleos de distribución RHEL, SLES y Ubuntu, así como para los núcleos vanilla.
Objetos de datos y creación de bandas 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 usa inodos, pero los inodos en 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 objeto y su diseño desde el MDS al cliente, de modo que el cliente puede interactuar directamente con el nodo OSS donde se almacena el objeto. Esto permite al cliente realizar E / S en paralelo a través de todos los objetos OST en el archivo sin más comunicación con el MDS.
Si solo un objeto OST está asociado con un inodo MDT, ese objeto contiene todos los datos en el archivo Lustre. Cuando más de un objeto está asociado con un archivo, los datos del archivo se "seccionan" en fragmentos de forma rotatoria en los objetos OST de forma similar a RAID 0 en fragmentos, normalmente de 1 MB o más. La división de un archivo en varios objetos OST proporciona importantes beneficios de rendimiento si se necesita un acceso de gran ancho de banda a un solo archivo grande. Cuando se utiliza la creación de bandas, el tamaño máximo de archivo no está limitado por el tamaño de un solo objetivo. Capacidad y escala de ancho de banda de E / S agregada con la cantidad de OST sobre las que se divide un archivo. Además, dado que el bloqueo de cada objeto se gestiona de forma independiente para cada OST, la adición de más franjas (una por OST) escala la capacidad de bloqueo de E / S del archivo de forma proporcional. Cada archivo creado en el sistema de archivos puede especificar diferentes parámetros de diseño, como el recuento de bandas (número de objetos OST que componen ese archivo), el tamaño de la banda (unidad de datos almacenados en cada OST antes de pasar al siguiente) y la selección de OST, por lo que que el rendimiento y la capacidad se pueden ajustar de manera óptima para cada archivo. Cuando muchos subprocesos de aplicaciones 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 al mismo tiempo, entonces es óptimo tener una franja en cada OST para maximizar el rendimiento y la capacidad de ese archivo.
En la versión Lustre 2.10, se agregó la capacidad de especificar diseños compuestos para permitir que los archivos tengan diferentes parámetros de diseño para diferentes regiones del archivo. La función Progressive File Layout (PFL) utiliza diseños compuestos para mejorar el rendimiento de E / S de archivos en una gama más amplia de cargas de trabajo, así como para simplificar el uso y la administración. Por ejemplo, un archivo PFL pequeño puede tener una sola franja en la memoria flash para reducir la sobrecarga de acceso, mientras que los archivos más grandes pueden tener muchas franjas para un gran ancho de banda agregado y un mejor equilibrio de carga OST. Los diseños compuestos se mejoran aún más en la versión 2.11 con la función File Level Redundancy (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 Lustre 2.11 también agregó la función Data-on-Metadata (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 varias rayas en un OST, mientras que la función Self-Extender Layout permite que el tamaño del componente sea dinámico durante la escritura para que pueda hacer frente a OST (flash) que se quedan sin espacio antes todo el sistema de archivos no tiene espacio.
Objetos de metadatos y directorios remotos o seccionados 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 ID de objeto de 32 bits y la versión de 32 bits) del directorio raíz del punto de montaje. Al realizar una búsqueda de nombre de archivo, el cliente realiza una búsqueda de cada componente de 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 luego realiza una búsqueda en el MDS que administra este MDT utilizando el principal FID y 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 principal, se realizan más operaciones de directorio (para directorios no seccionados) exclusivamente en ese MDT, evitando la contención entre MDT. Para los directorios seccionados de DNE, el diseño por directorio almacenado en el directorio principal proporciona una función hash y una lista de los FID de directorio MDT a través de los cuales se distribuye el directorio. El Volumen de metadatos lógicos (LMV) en el cliente aplica un hash al nombre de archivo y lo asigna a un fragmento de directorio MDT específico , que manejará las operaciones adicionales en ese archivo de manera idéntica a un directorio sin franjas. Para las operaciones readdir () , las entradas de cada fragmento de directorio se devuelven al cliente ordenadas en el orden de hash del directorio MDT local, y el cliente realiza una clasificación de combinación para intercalar los nombres de archivo en orden de hash de modo que una sola cookie de 64 bits pueda ser utilizado para determinar el desplazamiento actual dentro del directorio.
Cierre
El administrador de bloqueo distribuido 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 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, usando 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 ), diseño (creación de bandas de archivos, desde Lustre 2.4) y atributos extendidos (xattrs, desde Lustre 2.5). Un cliente puede obtener varios bits de bloqueo de metadatos para un solo inodo con una sola solicitud de RPC, pero actualmente solo se les otorga un bloqueo de lectura para el inodo. El MDS gestiona 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 cada objeto del archivo está seccionado, 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 todo el 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 para lectura y 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 son siempre 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 por una extensión mayor que la solicitada originalmente, para reducir el número de solicitudes de bloqueo que realiza el cliente. El tamaño real del bloqueo concedido depende de varios factores, incluido el número de bloqueos concedidos actualmente en ese objeto, si hay bloqueos de escritura en conflicto para la extensión de bloqueo solicitada y el número de solicitudes de bloqueo pendientes en ese objeto. El bloqueo concedido nunca es menor que la extensión solicitada originalmente. Los bloqueos de extensión OST utilizan el FID de brillo del objeto como nombre de recurso para el bloqueo. Dado que el número de servidores de bloqueo de extensión se escala con el número de OST en el sistema de archivos, esto también escala el rendimiento de bloqueo agregado del sistema de archivos y de un solo archivo si está dividido en varios OST.
Redes
La comunicación entre los clientes y servidores de Lustre se implementa mediante Luster 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 del servidor Luster MDS y OSS mediante el almacenamiento de conexión directa ( SAS , FC , iSCSI ) o las tecnologías tradicionales de red de área de almacenamiento (SAN), que es independiente de la red de cliente a servidor.
LNet puede utilizar muchos tipos de redes de uso común, como las redes InfiniBand y TCP (comúnmente Ethernet ), y permite la disponibilidad simultánea en varios tipos de redes con enrutamiento entre ellas. El acceso directo a memoria remota (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 las redes patentadas de alta velocidad como Cray Aries y Gemini. y Atos BXI. Las funciones de alta disponibilidad y recuperación permiten una recuperación transparente junto con los servidores de conmutación por error.
Desde Lustre 2.10, la función LNet Multi-Rail (MR) [75] 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. No es necesario que los tipos de interfaz LNet sean del mismo tipo de red. En 2.12, se mejoró Multi-Rail 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, [76] 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 100 Gigabit Interfaces Ethernet . [77]
Alta disponibilidad
Las características de alta disponibilidad del sistema de archivos Lustre incluyen un robusto mecanismo de recuperación y conmutación por error, lo que hace que los reinicios y fallas del servidor sean transparentes. La interoperabilidad de versiones entre versiones secundarias sucesivas del software Lustre permite actualizar un servidor desconectándolo (o transfiriéndolo a un servidor en espera), realizando la actualización y reiniciándolo, mientras todos los trabajos activos continúan ejecutándose, experimentando un retraso mientras que 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 de MDS activos / activos con DNE exportando dos o más MDT separados, mientras que los OSS se implementan típicamente en una configuración activa / activa exportando OST separados para proporcionar redundancia sin gastos generales adicionales del sistema. En sistemas de archivos de MDT único, el MDS en espera para un sistema de archivos es el MGS y / 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árquica)
Lustre proporciona la capacidad de tener múltiples niveles de almacenamiento dentro de un solo espacio de nombres del sistema de archivos. Permite que la funcionalidad HSM tradicional copie (archive) archivos del sistema de archivos primario a un nivel de almacenamiento de archivos secundario. El nivel de archivo suele ser un sistema basado en cinta, que a menudo tiene una caché de disco. Una vez que se archiva un archivo, se puede liberar del sistema de archivos principal, dejando solo un código auxiliar 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 completado la restauración del archivo.
Además del almacenamiento en niveles externo, es posible tener varios niveles de almacenamiento dentro de un solo espacio de nombres del sistema de archivos. Los OST de diferentes tipos (por ejemplo, HDD y SSD) se pueden declarar en grupos de almacenamiento con nombre. Los grupos de OST se pueden seleccionar al especificar diseños de archivos, y se pueden usar diferentes grupos dentro de un solo diseño de archivo PFL. Los archivos se pueden migrar entre niveles de almacenamiento de forma manual o bajo el control de Policy Engine. Desde Lustre 2.11, también es posible duplicar un archivo en diferentes grupos OST con un diseño de archivo FLR, por ejemplo, para preconfigurar archivos en flash para un trabajo informático.
HSM incluye algunos componentes de 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 de agentes.
- 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 herramientas de copia para interactuar con diferentes sistemas de archivo. Una herramienta de copia POSIX genérica está disponible para archivos que proporcionan una interfaz de usuario similar a POSIX. Las herramientas de copia también están disponibles para High Performance Storage System [78] (HPSS), Tivoli Storage Manager [79] (TSM), Amazon S3 , [80] y Google Drive . [81]
- Motor de políticas: observa los registros de cambios del sistema de archivos en busca de nuevos archivos para archivar, aplica políticas para liberar archivos según la antigüedad o el uso del espacio y se comunica con MDT y el Coordinador. El motor de políticas también puede desencadenar acciones como la migración, purga y eliminación. 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 archivos que incluyen: [82]
- 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 se ha modificado y difiere de la copia archivada.
- Liberado: existe un inodo stub en un MDT, pero los objetos de datos se han eliminado y la única copia existe en el archivo.
- Perdido: la copia de archivo del archivo se ha perdido y no se puede restaurar
- Sin liberación: el archivo no debe liberarse del sistema de archivos
- Sin archivo: el archivo no debe archivarse
Despliegues
Lustre es utilizado por muchas de las supercomputadoras TOP500 y grandes sitios de múltiples clústeres. Seis de las 10 principales y más de 60 de las 100 supercomputadoras principales utilizan sistemas de archivos Lustre. Estos incluyen: computadora K en el Instituto Avanzado de Ciencias Computacionales RIKEN , [11] el Tianhe-1A en el Centro Nacional de Supercomputación en Tianjin, China , el Jaguar y Titan en el Laboratorio Nacional Oak Ridge (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 de Cómputo Nacional de Investigación de Energía Científica , Pacific Northwest National Laboratory , de Texas Advanced Computing Center , Laboratorio Nacional de Computación Científica de Brasil , [83] y la NASA [84] en América del Norte, en Asia en Tokio Instituto de Tecnología , [85] en Europa en CEA , [86] [87] y muchos otros.
Soporte técnico comercial
El soporte técnico comercial para Lustre a menudo se incluye junto con el sistema informático o el hardware de almacenamiento que vende el proveedor. Algunos proveedores incluyen Dell , [88] Hewlett-Packard (como HP StorageWorks Scalable File Share, entre 2004 y 2008), [89] Groupe Bull , Fujitsu . [90] Los proveedores que venden hardware de almacenamiento con soporte Lustre incluido incluyen Hitachi Data Systems , [91] DataDirect Networks (DDN), [92] NetApp y otros. También es posible obtener soporte solo de software para los sistemas de archivos Lustre de algunos proveedores, incluido Whamcloud . [93]
Amazon Web Services ofrece Amazon FSx para Lustre, [94] un servicio totalmente administrado, lo que facilita el lanzamiento y la ejecución de sistemas de archivos de alto rendimiento de manera rentable en la nube.
Ver también
- Sistema de archivos distribuido
- Lista de sistemas de archivos, la sección del sistema de archivos tolerante a fallas en paralelo distribuido
Referencias
- ↑ a b Corbet, Jonathon (17 de diciembre de 2003). "Lanzamiento de Lustre 1.0" . Noticias semanales de Linux . LWN.net . Consultado el 15 de marzo de 2015 .
- ^ a b "Versión 2.14.0" . Lustre Wiki . OpenSFS . 19 de febrero de 2021 . Consultado el 19 de febrero de 2021 .
- ^ "Lustre 2.12.6 lanzado" . Lustre.org . 9 de diciembre de 2020 . Consultado el 9 de diciembre de 2020 .
- ^ Oracle Corporation / Intel Corporation (4 de agosto de 2002). "Manual de operaciones de la versión 2.x del software Lustre *" (PDF) . Manual de instrucciones . Intel . Consultado el 19 de mayo de 2015 .
- ^ "Lustre Inicio" . Archivado desde el original el 31 de marzo de 2001 . Consultado el 23 de septiembre de 2013 .
- ^ "Lustre File System, versión 2.4 publicada" . Sistemas de archivos escalables abiertos . Consultado el 18 de octubre de 2014 .
- ^ "Lustre de código abierto obtiene aprobación de supercomputación" . Consultado el 18 de octubre de 2014 .
- ^ "Xyratex captura el brillo de Oracle" . HPCWire . Consultado el 18 de octubre de 2014 .
- ^ "Información Post-K (Fugaku)" . Fujitsu . Consultado el 23 de junio de 2020 .
- ^ "Descripción general del sistema Titan" . Laboratorio Nacional de Oak Ridge. Archivado desde el original el 13 de febrero de 2018 . Consultado el 19 de septiembre de 2013 .
- ^ a b c Brian Behlendorf. "ZFS en Linux para Lustre" (PDF) . Laboratorio Nacional Lawrence Livermore. Archivado desde el original (PDF) el 31 de octubre de 2014 . Consultado el 23 de junio de 2020 .
- ^ "Sistema de archivos Spider Center-Wide" . Instalación de Computación de Liderazgo de Oak Ridge. Archivado desde el original el 4 de marzo de 2016 . Consultado el 2 de febrero de 2012 .
- ^ "Lustre duro como una roca: tendencias en escalabilidad y calidad" (PDF) . Nathan Rutman, Xyratex . Consultado el 2 de febrero de 2012 .
- ^ Wang, Teng; Byna, Suren; Dong, Bin; Tang, Houjun (septiembre de 2018). "UniviStor: almacenamiento jerárquico y distribuido integrado para HPC". 2018 IEEE International Conference on Cluster Computing (CLUSTER) . IEEE. págs. 134-144. doi : 10.1109 / CLUSTER.2018.00025 . ISBN 978-1-5386-8319-4. S2CID 53235423 .
- ^ Presentación de Lustre File System, noviembre de 2007 en YouTube por Peter Braam, 10 de noviembre de 2007
- ^ Wang, Teng; Byna, Suren; Lockwood, Glenn K .; Snyder, Shane; Carns, Philip; Kim, Sunggon; Wright, Nicholas J. (mayo de 2019). "Un análisis de zoom de los registros de E / S para detectar las causas raíz de los cuellos de botella en el rendimiento de E / S". 2019 19o Simposio Internacional IEEE / ACM sobre Computación en Cluster, Cloud y Grid (CCGRID) . IEEE. págs. 102-111. doi : 10.1109 / CCGRID.2019.00021 . ISBN 978-1-7281-0912-1. S2CID 195832257 .
- ^ "Caracterización comparativa de la carga de trabajo de E / S de dos clústeres de almacenamiento de clase líder" (PDF) . ACM. Noviembre de 2015.
- ^ Wang, Teng; Snyder, Shane; Lockwood, Glenn; Carns, Philip; Wright, Nicholas; Byna, Suren (diciembre de 2018). "IOMiner: marco de análisis a gran escala para obtener conocimientos de registros de E / S". 2018 IEEE International Conference on Cluster Computing (CLUSTER) . IEEE. págs. 466–476. doi : 10.1109 / CLUSTER.2018.00062 . ISBN 978-1-5386-8319-4. S2CID 53235850 .
- ^ 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 de Lustre y NASA en Pléyades". 2012 XIX Congreso Internacional de Computación de Alto Rendimiento . IEEE. págs. 1-10. doi : 10.1109 / HiPC.2012.6507507 . ISBN 978-1-4673-2371-0. S2CID 14323627 .
- ^ "Empresa" . sitio web antiguo . Cluster File Systems, Inc. Archivado desde el original el 12 de agosto de 2007.CS1 maint: bot: estado de URL original desconocido ( enlace )
- ^ Peter J. Braam (4 de agosto de 2002). "Lustre, el sistema de archivos intergaláctico" (PDF) . Diapositivas de presentación . Laboratorio Nacional Lawrence Livermore . Consultado el 23 de septiembre de 2013 .
- ^ R. Kent Koeninger (junio de 2003). "El sistema de archivos ultraescalable HPTC Lustre" (PDF) . Diapositivas para su presentación en Cluster World 2003 . Consultado el 23 de septiembre de 2013 .
- ^ Britta Wülfing (13 de septiembre de 2007). "Sun asimila el sistema de archivos de brillo" . Revista Linux . Consultado el 23 de septiembre de 2013 .
- ^ "Sun Microsystems amplía la cartera de informática de alto rendimiento con un acuerdo definitivo para adquirir activos de sistemas de archivos de clúster, incluido el sistema de archivos Lustre" . Comunicado 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 .
- ^ "Oracle ha pateado Lustre a la acera" . Dentro de HPC. 2011-01-10.
- ^ J. Leidel (20 de agosto de 2010). "Whamcloud tiene como objetivo asegurarse de que Lustre tenga futuro en HPC" . Dentro de HPC . Consultado el 23 de septiembre de 2013 .
- ^ a b "Xyratex avanza la iniciativa Lustre®, asume la propiedad de los activos relacionados" . Comunicado 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 .
- ^ Rich Brueckner (9 de noviembre de 2010). "Bojanic & Braam recuperando la banda de brillo en Xyratex" . Dentro de HPC . Consultado el 23 de septiembre de 2013 .
- ^ Rich Brueckner (4 de enero de 2011). "Personal de Whamcloud para un brillo más brillante" . Dentro de HPC . Consultado el 18 de septiembre de 2013 .
- ^ "Whamcloud firma contrato de desarrollo de brillo de varios años con OpenSFS" . Comunicado de prensa . Alambre HPC. 16 de agosto de 2011. Archivado desde el original el 25 de enero de 2013 . Consultado el 23 de septiembre de 2013 .
- ^ Galen Shipman (18 de noviembre de 2011). "Actualización de OpenSFS" (PDF) . Presentación de Diapositivas para Supercomputación 2011 . Sistemas de archivos escalables abiertos . Consultado el 23 de septiembre de 2013 .
- ^ Whamcloud (15 de noviembre de 2011). "Acuerdo de desarrollo de árbol comunitario de OpenSFS y Whamcloud Sign Lustre" . Comunicado de prensa . Consultado el 23 de septiembre de 2013 .
- ^ Joab Jackson (16 de julio de 2012). "Intel adquiere proveedor de brillo Whamcloud" . Mundo PC.
- ^ Timothy Prickett Morgan (16 de julio de 2012). "Intel engulle experto en sistema de archivos Lustre Whamcloud" . El registro.
- ^ Timothy Prickett Morgan (11 de julio de 2012). "DOE reparte efectivo a AMD, Whamcloud para una investigación a exaescala" . El registro.
- ^ Nicole Hemsoth (12 de junio de 2013). "Intel talla la autopista Mainstream para brillo" . Alambre HPC . Consultado el 23 de septiembre de 2013 .
- ^ Brueckner, Rich. "Con la nueva RFP, OpenSFS para invertir en tecnologías críticas de código abierto para HPC" . insideHPC . Consultado el 1 de octubre de 2013 .
- ^ "Seagate dona Lustre.org a la comunidad de usuarios" . Consultado el 9 de septiembre de 2014 .
- ^ Daniel Robinson (27 de junio de 2018). "DDN da nueva vida al sistema de archivos Lustre" .
- ^ "Marca comercial de Lustre lanzada a la comunidad de usuarios" . InsideHPC. 24 de noviembre de 2019 . Consultado el 5 de diciembre de 2019 .
- ^ "Lustre ayuda a alimentar la tercera supercomputadora más rápida" . DSStar. Archivado desde el original el 3 de febrero de 2013.
- ^ "MCR Linux Cluster Xeon 2.4 GHz - Quadrics" . Top500.Org.
- ^ Peter Bojanic (15 de junio de 2008). "Hoja de ruta del brillo y planes futuros" (PDF) . Presentación al Consorcio Sun HPC . Sun Microsystems . Consultado el 23 de septiembre de 2013 .
- ^ "OpenSFS anuncia esfuerzo colaborativo para apoyar la distribución comunitaria Lustre 2.1" . Sistemas de archivos escalables abiertos. 8 de febrero de 2011. Archivado desde el original el 23 de mayo de 2011 . Consultado el 13 de diciembre de 2016 .
- ^ "Lanzamiento de Lustre 2.1" . Consultado el 2 de febrero de 2012 .
- ^ "Lanzamiento de Lustre 2.2" . Yahoo! Finanzas . Consultado el 8 de mayo de 2012 .
- ^ "Un programador de solicitudes de red novedoso para un sistema de almacenamiento a gran escala" (PDF) . Lustre Wiki . OpenSFS . Junio de 2009.
- ^ "Un programador de solicitudes de red novedoso para un sistema de almacenamiento a gran escala" . Lustre Wiki . OpenSFS . Junio de 2009.
- ^ Prickett Morgan, Timothy. "OpenSFS anuncia la disponibilidad de Lustre 2.5" . EnterpriseTech.
- ^ Brueckner, Rich. "Video: la nueva versión Lustre 2.5 ofrece capacidades HSM" . Dentro de Big Data . Consultado el 11 de diciembre de 2013 .
- ^ Hemsoth, Nicole. "Lustre obtiene una actualización de clase empresarial con HSM" . HPCwire. Archivado desde el original el 17 de diciembre de 2013 . Consultado el 11 de diciembre de 2013 .
- ^ "Lustre 2.5" . Mundo de la Computación Científica . Consultado el 11 de diciembre de 2013 .
- ^ Jones, Peter (9 de septiembre de 2014). "Lustre 2.5.3 lanzado" . Archivo de listas de correo de HPDD-Discusión . Consultado el 21 de octubre de 2014 .Morrone, Chris (7 de diciembre de 2015). "Terminología de lanzamiento retirado" . Lustre Wiki . Consultado el 18 de enero de 2016 .
- ^ "Lanzamiento de Lustre 2.6.0" . Archivo de listas de correo de HPDD-Discusión . 30 de julio de 2014 . Consultado el 21 de octubre de 2014 .
- ^ Ihara, Shuichi (14 de octubre de 2014). "Lustre QoS basado en la política de NRS de Token Bucket Filter" (PDF) .
- ^ Uselton, Andrew. "Demostración de la mejora en el rendimiento de un cliente de Single Lustre de la versión 1.8 a la versión 2.6" (PDF) . Consultado el 18 de octubre de 2014 .
- ^ Jones, Peter (13 de marzo de 2015). "Lustre 2.7.0 lanzado" . Archivo de listas de correo de HPDD-Discusión . Consultado el 15 de marzo de 2015 .
- ^ Jones, Peter (16 de marzo de 2016). "Lustre 2.8.0 lanzado" . Archivo de listas de correo de Lustre -nounce . OpenSFS . Consultado el 28 de marzo de 2016 .
- ^ "Lista de cambios de Lustre 2.9.0" . Lustre Wiki . OpenSFS . 7 de diciembre de 2016 . Consultado el 8 de diciembre de 2016 .
- ^ "Lista de cambios de Lustre 2.10.0" . Lustre Wiki . OpenSFS . 13 de julio de 2017 . Consultado el 3 de octubre de 2017 .
- ^ "Versión 2.11.0" . Lustre Wiki . OpenSFS . 3 de abril de 2018 . Consultado el 4 de abril de 2018 .
- ^ "Versión 2.12.0" . Lustre Wiki . OpenSFS . 21 de diciembre de 2018 . Consultado el 11 de febrero de 2019 .
- ^ Li Xi, DDN (junio de 2018). "Tamaño perezoso en MDS" (PDF) . Lustre Wiki . Consultado el 5 de diciembre de 2019 .
- ^ Shuichi Ihara, DDN (junio de 2018). "Protección de integridad de datos de extremo a extremo T10PI para Lustre" (PDF) . Lustre Wiki . Consultado el 5 de diciembre de 2019 .
- ^ "Versión 2.13.0" . Lustre Wiki . OpenSFS . 5 de diciembre de 2019 . Consultado el 5 de diciembre de 2019 .
- ^ Li Xi, Whamcloud (junio de 2018). "Caché de cliente persistente de Lustre" (PDF) . Lustre Wiki . Consultado el 5 de diciembre de 2019 .
- ^ Patrick Farrell, Whamcloud (abril de 2019). "Overstriping: Extracción del rendimiento máximo de archivos compartidos" (PDF) . Lustre Wiki . Consultado el 5 de diciembre de 2019 .
- ^ Patrick Farrell, Cray (15 de marzo de 2019). "Espacio de desbordamiento: Diseños autoexpandibles HLD" (PDF) . Consultado el 5 de diciembre de 2019 .
- ^ "Lista de cambios de Lustre 2.13.0" . Lustre Wiki . 5 de diciembre de 2019.
- ^ "Lustre para ejecutar en ZFS" . Noticias de informática del gobierno. 2008-10-26.
- ^ "ZFS en Lustre" . 2011-05-10. Archivado desde el original el 5 de diciembre de 2011 . Consultado el 25 de noviembre de 2011 .
- ^ "DataDirect seleccionado como tecnología de almacenamiento que impulsa BlueGene / L" . Alambre HPC . 15 de octubre de 2004. Archivado desde el original el 14 de junio de 2013 . Consultado el 9 de mayo de 2012 .
- ^ Suzanne M. Kelly (2006). "Arquitectura de software de Catamount con extensiones de doble núcleo" (PDF) . Consultado el 16 de febrero de 2016 .
- ^ "Notas de la versión de Linux Kernel 4.18rc1" .
- ^ Shehata, Amir. "Multi-Rail LNet para brillo" (PDF) . Grupo de usuarios de Lustre, abril de 2016.
- ^ Lafoucrière, Jacques-Charles. "Experiencia Lustre en CEA / DIF" (PDF) . Foro HEPiX, abril de 2007. Archivado desde el original (PDF) el 2012-02-08.
- ^ Caldwell, Blane (9 de marzo de 2016). "Tecnologías de redes de brillo: Ethernet frente a Infiniband" (PDF) . Centro de excelencia OLCF Lustre . Consultado el 6 de diciembre de 2019 .
- ^ Aurélien Degrémont (17 de septiembre de 2013). "¡LA ENCUADERNACIÓN LUSTER / HSM ESTÁ ALLÍ!" (PDF) .
- ^ Thomas Stibor (20 de septiembre de 2016). "TSM Copytool para Lustre HSM" (PDF) .
- ^ Robert Read (24 de marzo de 2015). "Lustre HSM en la nube" (PDF) .
- ^ Stéphane Thiell. "Herramienta de copia de Google Drive Lustre / HSM" .
- ^ Aurélien Degrémont; Thomas Leibovici (16 de abril de 2009). "Proyecto Lustre HSM — Seminarios avanzados para usuarios de Lustre" (PDF) . Archivado (PDF) desde el original el 25 de mayo de 2010 . Consultado el 5 de mayo de 2018 .
- ^ "LNCC - Laboratório Nacional de Computação Científica" . Lncc.br . Consultado el 27 de mayo de 2015 .
- ^ "Supercomputadora Pléyades" . www.nas.nasa.gov. 2008-08-18.
- ^ "Lista TOP500 - noviembre de 2006" . TOP500.Org.
- ^ "Lista TOP500 - junio de 2006" . TOP500.Org.
- ^ "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 4 de febrero de 2012 . Consultado el 15 de junio de 2012 .
- ^ "Soluciones Dell HPC" . 2015-04-14.
- ^ "Recursos compartidos de archivos escalables HP StorageWorks" . Hewlett Packard. Archivado desde el original el 12 de junio de 2008 . Consultado el 13 de diciembre de 2016 .
- ^ "Fujitsu lanza el sistema de archivos de mayor rendimiento del mundo: software de sistema de archivos escalable FEFS para sistemas de clúster HPC x86 avanzados" . 2015-06-13.
- ^ "Soluciones de almacenamiento de alto rendimiento con brillo" . 2015-04-14.
- ^ "Exascaler: Dispositivo de sistema de archivos Lustre masivamente escalable, de alto rendimiento" . 2015-04-14.
- ^ "Soporte de brillo" . 2018-11-27.
- ^ "Amazon FSx para Lustre" . 2019-06-11.
enlaces externos
- Página web oficial
Wikis de información
- Wiki de la comunidad de Lustre
- Wiki de Lustre (DDN)
- Wiki de Lustre (OpenSFS)
Fundaciones comunitarias
- OpenSFS
- EOFS - Sistema de archivos abierto europeo
Proveedores de hardware / software
- Redes DataDirect (DDN)
- Hewlett Packard Enterprise / Cray (incluidos ex empleados de Xyratex [1] )
- NetApp
- Computación Aeon
- ^ Negro, Doug. "Cray se mueve para adquirir la línea Seagate ClusterStor" . HPCWire . HPCWire . Consultado el 1 de diciembre de 2017 .