GFS2

En informática , el Sistema de Archivos Global 2 ( GFS2 ) es un sistema de archivos de disco compartido para clústeres de computadoras Linux . GFS2 permite que todos los miembros de un clúster tengan acceso directo y concurrente al mismo almacenamiento de bloques compartido , a diferencia de los sistemas de archivos distribuidos que distribuyen los datos por todo el clúster. GFS2 también se puede usar como un sistema de archivos local en una sola computadora.

GFS2 no tiene modo de operación desconectado ni roles de cliente o servidor. Todos los nodos de un clúster GFS2 funcionan como pares. El uso de GFS2 en un clúster requiere hardware que permita el acceso al almacenamiento compartido y un gestor de bloqueo para controlar dicho acceso. El gestor de bloqueo funciona como un módulo independiente: por lo tanto, GFS2 puede usar el gestor de bloqueo distribuido (DLM) para configuraciones de clúster y el gestor de bloqueo "nolock" para sistemas de archivos locales. Las versiones anteriores de GFS también admiten GULM, un gestor de bloqueo basado en servidor que implementa redundancia mediante conmutación por error.

GFS y GFS2 son software libre , distribuido bajo los términos de la Licencia Pública General de GNU . ^{[ 1 ] [ 2 ]}

El desarrollo de GFS comenzó en 1995 y fue desarrollado originalmente por el profesor de la Universidad de Minnesota, Matthew O'Keefe, y un grupo de estudiantes. ^{[ 3 ]} Inicialmente fue escrito para el sistema operativo IRIX de SGI , pero en 1998 fue portado a Linux (2.4) ^{[ 4 ]} ya que el código fuente abierto proporcionaba una plataforma de desarrollo más conveniente. A finales de 1999/principios de 2000 llegó a Sistina Software , donde permaneció durante un tiempo como un proyecto de código abierto . En 2001, Sistina decidió convertir GFS en un producto propietario.

Los desarrolladores bifurcaron OpenGFS a partir de la última versión pública de GFS y luego lo mejoraron aún más para incluir actualizaciones que permitieran su compatibilidad con OpenDLM. Sin embargo, OpenGFS y OpenDLM quedaron obsoletos, ya que Red Hat adquirió Sistina en diciembre de 2003 y lanzó GFS y muchos componentes de infraestructura de clúster bajo la licencia GPL a finales de junio de 2004.

Posteriormente, Red Hat financió un mayor desarrollo orientado a la corrección de errores y la estabilización. Un desarrollo posterior, GFS2 ^{[ 5 ] [ 6 ]} , deriva de GFS y se incluyó junto con su gestor de bloqueo distribuido (compartido con GFS) en Linux 2.6.19. Red Hat Enterprise Linux 5.2 incluyó GFS2 como módulo del kernel con fines de evaluación. Con la actualización 5.3, GFS2 pasó a formar parte del paquete del kernel.

GFS2 forma parte de Fedora , Red Hat Enterprise Linux y las distribuciones asociadas de CentOS Linux. Los usuarios pueden adquirir soporte comercial para ejecutar GFS2 con soporte completo sobre Red Hat Enterprise Linux . A partir de Red Hat Enterprise Linux 8.3, GFS2 es compatible con entornos de computación en la nube que disponen de dispositivos de almacenamiento compartido. ^{[ 7 ]}

La siguiente lista resume algunos números de versión y las principales características introducidas:

• v1.0 (1996) Solo para SGI IRIX
• Versión 3.0 para Linux
• v4 registro de diario
• Administrador de bloqueo redundante v5
• v6.1 (2005) Gestor de bloqueos distribuidos
• Linux 2.6.19 - GFS2 y DLM se fusionaron en el kernel de Linux.
• Red Hat Enterprise Linux 5.3 lanza la primera versión totalmente compatible con GFS2.

El diseño de GFS y GFS2 está orientado a entornos de red de área de almacenamiento (SAN). Si bien es posible utilizarlos como un sistema de archivos de nodo único, todas sus funcionalidades requieren una SAN. Esta puede ser iSCSI , Fibre Channel , ATA over Ethernet (AoE) o cualquier otro dispositivo que pueda presentarse en Linux como un dispositivo de bloques compartido por varios nodos, por ejemplo, un dispositivo DRBD .

El gestor de bloqueo distribuido (DLM) requiere una red IP para comunicarse. Normalmente se utiliza Ethernet , pero existen muchas otras soluciones posibles. Dependiendo de la SAN elegida, puede ser posible combinar ambas, pero lo habitual es utilizar redes separadas para el DLM y el almacenamiento.

GFS requiere algún tipo de mecanismo de aislamiento . Este es un requisito de la infraestructura del clúster, más que de GFS/GFS2 en sí, pero es necesario para todos los clústeres multinodo. Las opciones habituales incluyen conmutadores de alimentación y controladores de acceso remoto (por ejemplo, DRAC , IPMI o ILO ). También se pueden utilizar mecanismos de aislamiento virtuales y basados ​​en hipervisor. El aislamiento se utiliza para garantizar que un nodo que el clúster considera que ha fallado no pueda volver a funcionar repentinamente mientras otro nodo recupera el registro del nodo fallido. Opcionalmente, también puede reiniciar automáticamente el nodo fallido una vez completada la recuperación.

Aunque los diseñadores de GFS/GFS2 pretendían emular fielmente un sistema de archivos local, existen varias diferencias que conviene tener en cuenta. Algunas se deben a que las interfaces de los sistemas de archivos existentes no permiten el paso de información relacionada con el clúster. Otras se derivan de la dificultad de implementar esas características de forma eficiente en un entorno de clúster. Por ejemplo:

• La llamada al sistema flock() en GFS/GFS2 no es interrumpible por señales .
• La llamada al sistema fcntl() F_GETLK devuelve el PID de cualquier bloqueo. Dado que se trata de un sistema de archivos en clúster, ese PID podría corresponder a un proceso en cualquiera de los nodos que tienen el sistema de archivos montado. Como el propósito de esta interfaz es permitir el envío de una señal al proceso bloqueador, esto ya no es posible.
• Los arrendamientos no son compatibles con el módulo de bloqueo lock_dlm (cluster), pero sí lo son cuando se utilizan como un sistema de archivos local.
• dnotify funcionará en base a "mismo nodo", pero no se recomienda su uso con GFS/GFS2.
• inotify también funcionará sobre la base de "mismo nodo" y tampoco se recomienda (aunque podría llegar a ser compatible en el futuro).
• La función splice solo es compatible con GFS2.

La otra diferencia principal, común a todos los sistemas de archivos de clúster similares, es que el mecanismo de control de caché, conocido como glocks (pronunciado Gee-locks) para GFS/GFS2, afecta a todo el clúster. Cada inodo del sistema de archivos tiene dos glocks asociados. Uno (llamado iopen glock) registra qué procesos tienen el inodo abierto. El otro (el inode glock) controla la caché relacionada con ese inodo. Un glock tiene cuatro estados: UN (desbloqueado), SH (compartido – un bloqueo de lectura), DF (diferido – un bloqueo de lectura incompatible con SH) y EX (exclusivo). Cada uno de los cuatro modos se corresponde directamente con un modo de bloqueo DLM .

En el modo EX, un inodo puede almacenar en caché datos y metadatos (que pueden estar "sucios", es decir, esperando a ser escritos de vuelta al sistema de archivos). En el modo SH, el inodo puede almacenar en caché datos y metadatos, pero no debe estar sucio. En el modo DF, el inodo solo puede almacenar en caché metadatos, y de nuevo, no debe estar sucio. El modo DF se utiliza únicamente para E/S directa. En el modo UN, el inodo no debe almacenar en caché ningún metadato.

Para evitar que las operaciones que modifican los datos o metadatos de un inodo interfieran entre sí, se utiliza un bloqueo EX. Esto significa que ciertas operaciones, como la creación o eliminación de archivos del mismo directorio y la escritura en el mismo archivo, deben, en general, estar restringidas a un único nodo del clúster. Si bien realizar estas operaciones desde varios nodos funcionará correctamente, debido a la necesidad de vaciar las cachés con frecuencia, no resultará muy eficiente.

La pregunta más frecuente sobre el rendimiento de GFS/GFS2 es por qué puede ser deficiente con los servidores de correo electrónico. La solución consiste en dividir la cola de correo en directorios separados e intentar que cada nodo lea y escriba en un conjunto privado de directorios (en la medida de lo posible).

GFS y GFS2 son sistemas de archivos con registro de transacciones ; y GFS2 admite un conjunto de modos de registro similar al de ext3 . En el modo data=writeback , solo se registran los metadatos. Este es el único modo compatible con GFS; sin embargo, es posible activar el registro de transacciones en archivos de datos individuales, pero solo cuando tienen tamaño cero. Los archivos con registro de transacciones en GFS tienen varias restricciones, como la falta de compatibilidad con las llamadas al sistema mmap o sendfile, y utilizan un formato de disco diferente al de los archivos regulares. También existe un atributo "inherit-journal" que, al establecerse en un directorio, hace que todos los archivos (y subdirectorios) creados dentro de ese directorio tengan la bandera journal (o inherit-journal, respectivamente) establecida. Esto puede usarse en lugar de la opción de montaje data=journal que admite ext3 (y que GFS/GFS2 no admite).

GFS2 también admite el modo `data=ordered` , similar a `data=writeback`, con la diferencia de que los datos modificados se sincronizan antes de que se complete cada vaciado del registro. Esto garantiza que el contenido de los bloques añadidos a un inodo se sincronice con el disco antes de que se actualicen los metadatos para registrar el nuevo tamaño, evitando así que aparezcan bloques no inicializados en un archivo en caso de fallo del nodo. El modo de registro predeterminado es `data=ordered` , para que coincida con el predeterminado de ext3 .

A partir de 2010GFS2 aún no admite el modo data=journal , pero (a diferencia de GFS) utiliza el mismo formato en disco para archivos regulares y con registro, y también admite los mismos atributos journaled e inherit-journal. GFS2 también flexibiliza las restricciones sobre cuándo se puede cambiar el atributo journaled de un archivo, permitiendo que se pueda cambiar en cualquier momento en que el archivo no esté abierto (igual que ext3 ).

Por motivos de rendimiento, cada nodo en GFS y GFS2 tiene su propio registro de transacciones. En GFS, los registros son extensiones de disco; en GFS2, son archivos regulares. El número de nodos que pueden montar el sistema de archivos simultáneamente está limitado por el número de registros disponibles.

GFS2 añade varias características nuevas que no están presentes en GFS. A continuación, se presenta un resumen de las características que no se mencionan en los recuadros a la derecha de esta página:

• El sistema de archivos de metadatos (en realidad una raíz diferente): consulte Compatibilidad y el sistema de archivos de metadatos de GFS2 a continuación.
• Los puntos de rastreo específicos de GFS2 están disponibles desde el kernel 2.6.32.
• La interfaz de cuotas estilo XFS está disponible en GFS2 desde el kernel 2.6.33.
• Las ACL de almacenamiento en caché están disponibles en GFS2 desde la versión 2.6.33.
• GFS2 admite la generación de solicitudes de "descarte" para solicitudes de aprovisionamiento ligero/SCSI TRIM.
• GFS2 admite barreras de E/S (activadas por defecto, siempre que el dispositivo subyacente las admita. Configurables a partir del kernel 2.6.33).
• ioctl de FIEMAP (para consultar las asignaciones de inodos en el disco)
• Soporte para Splice (llamada al sistema)
• Compatibilidad con mmap/splice para archivos con registro de transacciones (habilitada mediante el uso del mismo formato de disco que para los archivos regulares).
• Muchos menos parámetros ajustables (lo que simplifica la configuración).
• Modo de escritura ordenada (al igual que ext3, GFS solo tiene modo de escritura diferida).

GFS2 se diseñó para que la actualización desde GFS fuera un procedimiento sencillo. Con este fin, la mayor parte de la estructura en disco se ha mantenido igual que en GFS, incluido el orden de bytes big-endian . Sin embargo, existen algunas diferencias:

• GFS2 tiene un "meta sistema de archivos" a través del cual los procesos acceden a los archivos del sistema.
• GFS2 utiliza el mismo formato en disco para los archivos con registro que para los archivos normales.
• GFS2 utiliza archivos regulares (del sistema) para los diarios, mientras que GFS utiliza extensiones especiales.
• GFS2 tiene otros archivos del sistema " per_node "
• La disposición del inodo es (muy ligeramente) diferente.
• La disposición de los bloques indirectos difiere ligeramente.

Los sistemas de registro de transacciones de GFS y GFS2 no son compatibles entre sí. La actualización se puede realizar mediante una herramienta ( gfs2_convert ) que se ejecuta con el sistema de archivos fuera de línea para actualizar los metadatos. Algunos bloques libres en los registros de GFS se utilizan para crear los archivos per_node (muy pequeños) que requiere GFS2 durante el proceso de actualización. La mayor parte de los datos permanece inalterada.

El "metasistema de archivos" de GFS2 no es un sistema de archivos independiente, sino una raíz alternativa del sistema de archivos principal. Aunque se comporta como un sistema de archivos "normal", su contenido son los diversos archivos del sistema que utiliza GFS2, y normalmente los usuarios no necesitan consultarlo. Las utilidades de GFS2 montan y desmontan el metasistema de archivos según sea necesario, de forma transparente para el usuario.

• Comparación de sistemas de archivos
• GPFS , ZFS , VxFS
• Lustre
• GlusterFS
• Lista de sistemas de archivos
• OCFS2
• QFS
• Sistema de archivos SAN
• Esgrima
• Ceph (software)

• Red Hat Enterprise Linux 6 - Sistema de archivos global 2
• Página de documentación de Red Hat Cluster Suite y GFS
• Página del proyecto GFS archivada el 15 de marzo de 2006 en Wayback Machine .
• Página del proyecto OpenGFS (obsoleta)
• El árbol git de desarrollo de GFS2
• El árbol git de desarrollo de utilidades de GFS2