Lustre es un sistema de archivos distribuido Open Source, normalmente utilizado en clusters a gran escala. El nombre es una mezcla de Linux y clusters. El proyecto intenta proporcionar un sistema de archivos para clusters de decenas de miles de nodos con petabytes de capacidad de almacenamiento, sin comprometer la velocidad o la seguridad, y está disponible bajo la GNU GPL.

Cluster File Systems son los diseñadores, desarrolladores y mantenedores de Lustre con colaboraciones de otras compañías y particulares.

Muchos de los superordenadores más rápidos del mundo son clusters que utilizan el sistema de archivos Lustre como almacenamiento, como los sistemas en ORNL, PNNL, LLNL y LANL.

Se considera a cada archivo almacenado en el sistema de archivos Lustre un objeto. Lustre presenta a todos los clientes una semántica POSIX estándar y acceso concurrente lectura y escritura para los objetos compartidos. Un sistema de archivos Lustre tiene cuatro unidades funcionales. Estas son: Meta data server (MDS) para almacenar los metadatos; un Object storage target (OST) para guardar los datos reales; un Object storage server (OSS) para manejar los OSTs; cliente(s) para acceder y utilizar los datos. Los OSTs son dispositivos de bloques. Un MDS, OSS, y un OST pueden residir en el mismo nodo o en nodos diferentes. Lustre no administra directamente los OSTs, y delega esta responsabilidad en los OSSs para asegurar la escalabilidad para grandes clusters y supercomputadores.

En un Massively Parallell Processor (MPP), los procesadores pueden acceder al sistema de archivos Lustre redirigiendo sus peticiones I/O hacia el nodo con el servicio lanzador de tareas si está configurado como un cliente Lustre. Aunque es el método más sencillo, en general proporciona un bajo rendimiento. Una manera ligeramente más complicada de proporcionar un rendimiento global muy bueno consiste en utilizar la biblioteca liblustre. Liblustre es una biblioteca de nivel de usuario que permite a los procesadores montar y utilizar el sistema de archivos Lustre como un cliente, sorteando la redirección hacia el nodo de servicio. Utilizando liblustre, los procesadores pueden acceder al sistema de archivos Lustre, incluso si el nodo de servicio en el que se lanzó el trabajo no es un cliente Lustre. Liblustre proporciona un mecanismo para mover datos directamente entre el espacio de aplicación y los OSSs de Lustre sin necesidad de realizar una copia de datos a través del núcleo ligero, logrando así una baja latencia, y gran ancho de banda en el acceso directo de los procesadores al sistema de archivos Lustre.

Gracias a su gran rendimiento y escalabilidad características, utilizar Lustre en sistemas MPP es lo más adecuado. Liblustre es la mayor diferencia de diseño entre Lustre en un MPP como el Cray XT3 y los clusters convencionales.

Arquitectura Lustre

La arquitectura Lustre escalable tiene los siguientes componentes:

Servidor de Gestión (MGS) Un MGS almacena información de configuración para uno o más sistemas de archivos Lustre y proporciona esta información a otros hosts Lustre. Este recurso global puede soportar varios sistemas de archivos. Uno o más nodos de servidores de metadatos (MDS) que tienen uno o más dispositivos de destino de metadatos (MDT) por sistema de archivos Lustre que almacena metadatos de espacios de nombres, como nombres de archivos, directorios, permisos de acceso y diseño de archivos. Los datos de MDT se almacenan en un sistema de archivos de disco local. Sin embargo, a diferencia de los sistemas de archivos distribuidos basados en bloques, como GPFS y PanFS, donde el servidor de metadatos controla toda la asignación de bloques, el servidor de metadatos de Lustre solo participa en las verificaciones de permisos y nombres de ruta, y no participa en ninguna operación de E/S de archivos, lo que evita cuellos de botella de escalabilidad de E/S en el servidor de metadatos. La capacidad de tener múltiples MDT en un solo sistema de archivos es una característica nueva en Lustre 2.4 y permite que los subárboles de directorios residan en los MDT secundarios, mientras que 2.7 y versiones posteriores también permiten distribuir grandes directorios individuales en múltiples MDT. Servidores de Almacenamiento de Objetos (OSS) Un OSS proporciona el almacenamiento masivo de datos para todo el contenido de archivos en un sistema de archivos Lustre. Cada OSS proporciona acceso a un juego de volúmenes de almacenamiento, llamados destinos de almacenamiento de objetos (OST). Cada OST contiene varios objetos binarios que representan los datos de archivos en Lustre. Los archivos de Lustre están compuestos por uno o más objetos OST, además del inodo de metadatos almacenado en el MDS, 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 solo sistema de archivos de disco local. La capacidad de un sistema de archivos Lustre es la suma de las capacidades proporcionadas por los OST. Clientes de Lustre Los clientes son instancias informáticas que acceden al sistema de archivos Lustre, estos acceden y utilizan los datos dentro del sistema de archivos. Lustre presenta a todos los clientes un espacio de nombres unificado para todos los archivos y datos del sistema de archivos, utilizando la semántica POSIX estándar , y permite el acceso de lectura y escritura simultáneo y coherente a los archivos del sistema de archivos. Red virtual en la nube (VCN) y subredes Una VCN es una red definida por software que se configura en una región Oracle Cloud Infrastructure. Las VCN se pueden segmentar en subredes, que pueden ser específicas de una región o de un dominio de disponibilidad. Tanto las subredes específicas de cada región como las específicas de dominio de disponibilidad pueden coexistir en la misma VCN. Una subred puede ser pública o privada. Listas de seguridad Para cada subred, puede crear reglas de seguridad que especifiquen el origen, destino y tipo de tráfico que se debe permitir dentro y fuera de la subred. Dominios de disponibilidad Los dominios de disponibilidad son centros de datos independientes e independientes dentro de una región. Los recursos físicos en cada dominio de disponibilidad están aislados de los recursos en los otros dominios de disponibilidad, lo que proporciona tolerancia a fallos. Los dominios de disponibilidad no comparten infraestructura, como energía o refrigeración, o la red de dominio de disponibilidad interna. Por lo tanto, es poco probable que un fallo en un dominio de disponibilidad afecte a los otros dominios de la región. 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 JBOD de manera efectiva.almacenamiento en lugar de dispositivos RAID de hardware. Los servidores Lustre OSS y MDS leen, escriben y modifican datos en el formato impuesto por el sistema de archivos de respaldo y devuelven estos datos a los clientes. Esto permite que Lustre aproveche las mejoras y funciones del sistema de archivos subyacente, como la compresión y las sumas de verificación de datos en ZFS. Los clientes no tienen acceso directo al almacenamiento subyacente, lo que garantiza que un cliente malintencionado o que funcione mal no pueda corromper la estructura del sistema de archivos.

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, a partir del trabajo en el sistema de archivos InterMezzo en el proyecto Coda en CMU. 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 . En septiembre de 2007, Sun Microsystems adquirió los activos de Cluster File Systems Inc., incluida su propiedad intelectual. 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.x y colocarían a Lustre 1.8 en soporte de solo mantenimiento, creando incertidumbre sobre el desarrollo futuro del sistema de archivos. Tras este anuncio, surgieron varias organizaciones nuevas para brindar apoyo y desarrollo en un modelo de desarrollo comunitario abierto, como Whamcloud, 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, mientras que Barton, Dilger y otros formaron el inicio de software Whamcloud , donde continuaron trabajando en Lustre.

En agosto de 2011, OpenSFS otorgó un contrato para el desarrollo de características de Lustre a Whamcloud. Este contrato cubría la finalización de funciones, incluida la mejora del escalado del rendimiento de metadatos de servidor único, que permite a Lustre aprovechar mejor el servidor de metadatos de muchos núcleos; la verificación del sistema de archivos distribuido Lustre en línea (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 Distributed Namespace Environment (DNE), anteriormente Clustered Metadata (CMD), que permite que los metadatos de Lustre se distribuyan entre varios servidores. El desarrollo también continuó en el almacenamiento de objetos back-end basado en ZFS en el Laboratorio Nacional Lawrence Livermore . Estas características estaban en la hoja de ruta de lanzamiento de la comunidad de Lustre 2.2 a 2.4. En noviembre de 2011, se otorgó un contrato por separado 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 funciones.

En julio de 2012, Whamcloud fue adquirida por Intel , después de que Whamcloud ganara el contrato FastForward DOE para preparar Lustre para su uso con sistemas informáticos de exaescala en el plazo de 2018. OpenSFS luego transfirió los contratos para el desarrollo de Lustre a Intel.