GFSI2

En informática , el Sistema de archivos global 2 o 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 simultáneo directo al mismo almacenamiento en bloque compartido , en contraste con los sistemas de archivos distribuidos que distribuyen datos por todo el clúster. GFS2 también se puede utilizar como un sistema de archivos local en una sola computadora.

GFS2 no tiene un modo operativo 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 para permitir el acceso al almacenamiento compartido y un administrador de bloqueos para controlar el acceso al almacenamiento. El administrador de bloqueos funciona como un módulo independiente: por lo tanto, GFS2 puede utilizar el Administrador de bloqueos distribuidos (DLM) para configuraciones de clúster y el administrador de bloqueos "sin bloqueos" para sistemas de archivos locales. Las versiones anteriores de GFS también admiten GULM, un administrador de bloqueos basado en servidor que implementa redundancia a través de conmutación por error.

GFS y GFS2 son software libre , distribuidos bajo los términos de la Licencia Pública General 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] Originalmente 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 proporcionó una plataforma de desarrollo más conveniente. A fines de 1999/principios de 2000 llegó a Sistina Software , donde vivió por un tiempo como un proyecto de código abierto . En 2001, Sistina tomó la decisión de convertir a GFS en un producto propietario.

Los desarrolladores crearon un fork de OpenGFS a partir de la última versión pública de GFS y luego lo mejoraron aún más para incluir actualizaciones que le permitieran trabajar con OpenDLM. Pero OpenGFS y OpenDLM dejaron de existir cuando Red Hat compró Sistina en diciembre de 2003 y lanzó GFS y muchas partes de la infraestructura de clúster bajo la GPL a fines 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 administrador de bloqueo distribuido (compartido con GFS) en Linux 2.6.19. Red Hat Enterprise Linux 5.2 incluyó GFS2 como un módulo del núcleo para fines de evaluación. Con la actualización 5.3, GFS2 pasó a formar parte del paquete del núcleo.

GFS2 forma parte de las distribuciones Linux Fedora , Red Hat Enterprise Linux y CentOS asociadas . 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 en los que hay dispositivos de almacenamiento compartido disponibles. ^[7]

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

• v1.0 (1996) SGI IRIX solamente
• Puerto Linux v3.0
• Registro en diario v4
• v5 Administrador de bloqueo redundante
• v6.1 (2005) Administrador de bloqueo distribuido
• Linux 2.6.19: GFS2 y DLM se fusionaron en el núcleo de Linux
• Red Hat Enterprise Linux 5.3 lanza el primer GFS2 totalmente compatible

El diseño de GFS y GFS2 está orientado a entornos tipo SAN . Si bien es posible utilizarlos como un sistema de archivos de un solo nodo, el conjunto completo de características requiere una SAN. Esta puede adoptar la forma de iSCSI , FibreChannel , AoE o cualquier otro dispositivo que pueda presentarse en Linux como un dispositivo de bloque compartido por varios nodos, por ejemplo, un dispositivo DRBD .

El DLM requiere una red basada en IP a través de la cual comunicarse. Normalmente, se trata de Ethernet , pero hay muchas otras soluciones posibles. Según la SAN elegida, puede ser posible combinarlas, pero la práctica habitual ^{[ cita requerida ]} implica redes separadas para el DLM y el almacenamiento.

El GFS requiere un mecanismo de protección de algún tipo. 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 de múltiples nodos. Las opciones habituales incluyen interruptores de energía y controladores de acceso remoto (por ejemplo, DRAC , IPMI o ILO ). También se pueden utilizar mecanismos de protección virtuales y basados ​​en hipervisores. La protección se utiliza para garantizar que un nodo que el clúster cree que ha fallado no pueda comenzar a funcionar de repente de nuevo mientras otro nodo está recuperando el diario del nodo que ha fallado. También se puede reiniciar opcionalmente el nodo que ha fallado automáticamente una vez que se completa la recuperación.

Aunque los diseñadores de GFS/GFS2 intentaron emular de forma precisa un sistema de archivos local, hay una serie de diferencias que se deben tener en cuenta. Algunas de ellas se deben a que las interfaces del sistema de archivos existentes no permiten el paso de información relacionada con el clúster. Otras se deben a la dificultad de implementar esas características de manera eficiente de manera agrupada. Por ejemplo:

• La llamada al sistema blanket() en GFS/GFS2 no puede ser interrumpida por señales .
• La llamada al sistema fcntl() F_GETLK devuelve un PID de cualquier bloqueo. Dado que se trata de un sistema de archivos en clúster, ese PID puede hacer referencia a un proceso en cualquiera de los nodos que tienen montado el sistema de archivos. Dado que el propósito de esta interfaz es permitir que se envíe una señal al proceso de bloqueo, esto ya no es posible.
• Los arrendamientos no son compatibles con el módulo de bloqueo lock_dlm (clúster), pero sí son compatibles cuando se utilizan como un sistema de archivos local.
• dnotify funcionará en base al "mismo nodo", pero no se recomienda su uso con GFS/GFS2
• inotify también funcionará en base al "mismo nodo" y tampoco se recomienda (pero puede ser compatible en el futuro)
• El empalme solo es compatible con GFS2

La otra diferencia principal, que comparten 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, tiene un efecto en todo el clúster. Cada inodo del sistema de archivos tiene dos glocks asociados. Uno (llamado glock iopen) realiza un seguimiento de los procesos que tienen el inodo abierto. El otro (el glock inodo) 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 asigna directamente a un modo de bloqueo DLM .

En el modo EX, se permite que un inodo almacene en caché datos y metadatos (que pueden estar "sucios", es decir, esperando que se escriban nuevamente en el sistema de archivos). En el modo SH, el inodo puede almacenar en caché datos y metadatos, pero no deben estar sucios. En el modo DF, se permite que el inodo almacene en caché solo metadatos, y nuevamente no deben estar sucios. El modo DF se usa solo para E/S directa. En el modo UN, el inodo no debe almacenar en caché ningún metadato.

Para que las operaciones que modifican los datos o metadatos de un inodo no interfieran entre sí, se utiliza un bloqueo EX. Esto significa que ciertas operaciones, como la creación o desvinculación de archivos del mismo directorio y la escritura en el mismo archivo, deberían estar, en general, restringidas a un nodo del clúster. Por supuesto, realizar estas operaciones desde varios nodos funcionará como se espera, pero debido al requisito de vaciar las cachés con frecuencia, no será muy eficiente.

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

Tanto GFS como GFS2 son sistemas de archivos con registro en diario ; y GFS2 admite un conjunto similar de modos de registro en diario que ext3 . En el modo data=writeback , solo se registran en diario los metadatos. Este es el único modo admitido por GFS, sin embargo, es posible activar el registro en diario en archivos de datos individuales, pero solo cuando son de tamaño cero. Los archivos con registro en diario en GFS tienen una serie de restricciones impuestas sobre ellos, como la falta de soporte para las llamadas del sistema mmap o sendfile, también utilizan un formato en disco diferente al de los archivos normales. También hay un atributo "inherit-journal" que cuando se establece en un directorio hace que todos los archivos (y subdirectorios) creados dentro de ese directorio tengan establecido el indicador journal (o heritage-journal, respectivamente). Esto se puede utilizar en lugar de la opción de montaje data=journal que ext3 admite (y GFS/GFS2 no).

GFS2 también admite el modo data=ordered , que es similar a data=writeback, excepto que los datos sucios se sincronizan antes de que se complete cada vaciado del diario. Esto garantiza que los bloques que se han agregado a un inodo tendrán su contenido sincronizado nuevamente con el disco antes de que se actualicen los metadatos para registrar el nuevo tamaño y, por lo tanto, evita que aparezcan bloques no inicializados en un archivo en condiciones de falla del nodo. El modo de registro por defecto es data=ordered , para que coincida con el valor predeterminado de ext3 .

A partir de 2010 ^[actualizar], GFS2 aún no admite el modo data=journal , pero sí utiliza (a diferencia de GFS) el mismo formato en disco para archivos normales y registrados, y también admite los mismos atributos registrados y heredados. GFS2 también relaja las restricciones sobre cuándo se puede cambiar el atributo registrado de un archivo a cualquier momento en que el archivo no esté abierto (también lo mismo que ext3 ).

Por razones de rendimiento, cada nodo en GFS y GFS2 tiene su propio diario. En GFS, los diarios son extensiones de disco, mientras que en GFS2 son archivos normales. La cantidad de nodos que pueden montar el sistema de archivos en un momento dado está limitada por la cantidad de diarios disponibles.

GFS2 incorpora una serie de nuevas funciones que no se encuentran en GFS. A continuación, se incluye un resumen de las funciones que no se han mencionado en los cuadros que aparecen 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 meta GFS2 a continuación
• Los puntos de seguimiento específicos de GFS2 están disponibles desde el kernel 2.6.32
• La interfaz de cuotas de 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 fino/SCSI TRIM
• GFS2 admite barreras de E/S (activadas de manera predeterminada, siempre que el dispositivo subyacente las admita. Configurable desde el kernel 2.6.33 y versiones posteriores)
• FIEMAP ioctl (para consultar asignaciones de inodos en el disco)
• Soporte para Splice (llamada al sistema)
• Compatibilidad con mmap/splice para archivos registrados (habilitado mediante el uso del mismo formato en disco que para los archivos normales)
• Muchos menos elementos ajustables (lo que hace que la configuración sea menos complicada)
• Modo de escritura ordenada (según ext3, GFS solo tiene modo de escritura diferida)

GFS2 fue diseñado para que la actualización desde GFS fuera un procedimiento sencillo. Para ello, la mayor parte de la estructura en disco se mantuvo igual que en GFS, incluido el orden de bytes big-endian . Sin embargo, existen algunas diferencias:

• GFS2 tiene un "metasistema 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 registrados que para los archivos normales.
• GFS2 utiliza archivos (de sistema) regulares para los diarios, mientras que GFS utiliza extensiones especiales.
• GFS2 tiene algunos otros archivos de sistema " per_node "
• El diseño del inodo es (muy ligeramente) diferente
• La disposición de los bloques indirectos difiere ligeramente

Los sistemas de registro de GFS y GFS2 no son compatibles entre sí. Es posible realizar una actualización mediante una herramienta ( gfs2_convert ) que se ejecuta con el sistema de archivos fuera de línea para actualizar los metadatos. Algunos bloques de repuesto 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ía de los datos permanecen en su lugar.

El "meta sistema de archivos" de GFS2 no es un sistema de archivos en sí mismo, sino una raíz alternativa del sistema de archivos principal. Aunque se comporta como un sistema de archivos "normal", su contenido son los distintos archivos del sistema que utiliza GFS2 y, normalmente, los usuarios no necesitan consultarlo. Las utilidades de GFS2 montan y desmontan el meta sistema de archivos según sea necesario, en segundo plano.

• Comparación de sistemas de archivos
• GPFS , ZFS , VxFS
• Lustre
• GlusterFS
• Lista de sistemas de archivos
• OCFS2
• Sistema de archivos QFS
• Sistema de archivos SAN
• Esgrima
• OpenSharedroot (raíz compartida abierta)
• Ceph (software)

• Red Hat 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