| GFS2 | |
| Desarrollador | sombrero rojo |
|---|---|
| nombre inglés | Sistema de archivos global 2 |
| Introducción | 2005 ( Linux 2.6.19) |
| Identificador de partición | ? |
| Estructura | |
| Contenido de directorios | tabla hash (los directorios pequeños se colocan en el mismo bloque que el inodo) |
| Asignación de archivos | campo de bits (grupos de bloques) |
| Bloques malos | No |
| Limitaciones | |
| Tamaño máximo de archivo | ? |
| Número máximo de archivos | variable |
| Tamaño máximo del nombre de archivo | 255 bytes |
| Tamaño de volumen máximo | 100 TiB |
| Caracteres permitidos en nombres de archivos | todos los caracteres excepto NULL |
| Características | |
| Fechas grabadas | modificación de atributo (ctime), modificación (mtime), acceso (atime) |
| Rango de fechas | ? |
| Atributos | Sin tiempo, datos registrados por diario (solo archivos normales), datos heredados registrados por diario (solo directorios), escritura sincrónica, solo anexión, inmutable, exhash (solo directorios, solo lectura) |
| Permisos | Permisos Unix, ACL y atributos de seguridad elegidos arbitrariamente |
| Compresión integrada | No admitido |
| Cifrado integrado | No admitido |
| GFS | |
| Desarrollador | Red Hat (originalmente Sistina Software) |
|---|---|
| nombre inglés | Sistema de archivos global |
| Introducción | 1996 ( IRIX (1996), Linux (1997)) |
| Identificador de partición | ? |
| Estructura | |
| Contenido de directorios | tabla hash (los directorios pequeños se colocan en el mismo bloque que el inodo) |
| Asignación de archivos | campo de bits (grupos de bloques) |
| Bloques malos | No |
| Limitaciones | |
| Tamaño máximo de archivo | ? |
| Número máximo de archivos | Variable |
| Tamaño máximo del nombre de archivo | 255 bytes |
| Tamaño de volumen máximo | ? |
| Caracteres permitidos en nombres de archivos | Todos los caracteres excepto NULL |
| Características | |
| Fechas grabadas | modificación de atributo (ctime), modificación (mtime), acceso (atime) |
| Rango de fechas | ? |
| Atributos | no-atime, datos registrados en el diario (solo archivos normales), heredar datos registrados en el diario (solo directorios), escritura sincrónica, solo agregar, inmutable, exhash (solo directorios, solo lectura) |
| Permisos | Permisos de Unix, ACL |
| Compresión integrada | No admitido |
| Cifrado integrado | No admitido |
El sistema de archivos global (GFS) ( sistema de archivos global ) es un sistema de archivos compartido diseñado para el clúster de computadoras Linux e IRIX . GFS y GFS2 son diferentes de los sistemas de archivos distribuidos como AFS , Coda o InterMezzo porque permiten que todos los nodos tengan acceso simultáneo directo al mismo dispositivo de almacenamiento de tipo bloque. Además, GFS y GFS2 también se pueden utilizar como sistema de archivos local.
GFS no tiene un modo fuera de línea, no hay cliente ni servidor. Todos los nodos de un clúster GFS son iguales. El uso de GFS en un grupo de computadoras requiere hardware que permita el acceso a los datos compartidos y un administrador de bloqueo para controlar el acceso a los datos. La cerradura es un administrador de módulo separado, por lo tanto, GFS y GFS2 pueden usar un administrador de cerraduras distribuido ( Administrador de cerraduras distribuidas , DLM) para configuraciones de clúster y el administrador de cerraduras "nolock" para sistemas de archivos locales. Las versiones anteriores de GFS también son compatibles con GULM, un administrador de bloqueo basado en servidor que implementa redundancia de conmutación por error .
GFS y GFS2 son software gratuito , distribuidos bajo la licencia GPL .
GFS se desarrolló originalmente como parte de una tesis en la Universidad de Minnesota en 1997. Originalmente fue escrito para el sistema operativo IRIX de Silicon Graphics , pero se ha adaptado a Linux. En 1998 porque el código fuente abierto ("código fuente libre "en francés) proporcionó un mejor entorno de desarrollo. A finales de 1999 / principios de 2000, fue absorbida por la empresa Sistina Software, durante un tiempo como proyecto de código abierto . En 2001, Sistina decidió convertir GFS en un producto comercial, abandonando al mismo tiempo la gestión de código abierto.
Los desarrolladores tomaron OpenGFS de la última versión pública de GFS y lo mejoraron para incluir actualizaciones que lo hicieron funcionar con OpenDLM . Pero OpenGFS y OpenDLM desaparecieron cuando Red Hat compró Sistina endiciembre de 2003y fue GFS y en muchas partes infraestructura de cluster bajo licencia GPL finalJunio de 2004.
Posteriormente, Red Hat financió el desarrollo centrado en la corrección y estabilización de errores. Una versión posterior, GFS2 se deriva de GFS y luego se incluye con su Administrador de bloqueo distribuido (el mismo que el de GFS) en Linux 2.6.19. GFS2 se incluyó en Red Hat Enterprise Linux 5.2 como un módulo de kernel único para su evaluación. Con la versión 5.3, GFS2 ahora es parte del paquete del kernel.
En 2007, GFS se convirtió en parte de las distribuciones de Linux Fedora y CentOS . Los usuarios pueden comprar soporte de ventas para obtener soporte completo de GFS en Red Hat Enterprise Linux . A partir de la versión 5 de Red Hat Enterprise Linux , la compatibilidad con GFS se incluye con Red Hat Enterprise Linux sin costo adicional.
La siguiente lista resume algunos números de versión con las principales características introducidas:
GFS y GFS2 se diseñaron para funcionar en entornos SAN (o similares). Aunque es posible utilizarlos como sistemas de archivos para un nodo, se requiere una SAN para lograr la funcionalidad completa. Esto puede tomar la forma de un iSCSI , Fibre Channel , AoE o cualquier dispositivo que se pueda presentar en Linux como un dispositivo de bloque compartido por varios nodos.
DLM también requiere una red que admita IP para comunicarse. Puede que solo sea Ethernet , pero de nuevo, hay muchas otras soluciones. Dependiendo de la elección de SAN, esta red puede o no estar integrada con la SAN, aunque es más normal tener redes separadas para DLM y almacenamiento.
La última necesidad es la de un material para aislar ( vallar ) los elementos defectuosos. Este es un requisito de la infraestructura del clúster más que del propio GFS / GFS2, pero es un requisito para todos los clústeres. Las opciones comunes incluyen interruptores y controles remotos (por ejemplo , DRAC , IPMI o ILO ). El mecanismo de aislamiento se utiliza para garantizar que un nodo que el clúster cree que está fuera de servicio no pueda reiniciarse mientras otro nodo está recuperando su registro. El mecanismo de aislamiento también puede (opcionalmente) reiniciar el nodo fuera de servicio después de que se complete la recuperación.
Si bien el objetivo de GFS / GFS2 es ser lo más similar posible a un sistema de archivos local, existen muchas diferencias a tener en cuenta. Algunas se deben a las interfaces del sistema de archivos existentes, que no permiten que la información se pase por el clúster, y otras se deben a la dificultad de implementar de manera efectiva sistemas de archivos compartidos por clústeres. Estas son algunas de esas diferencias:
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 (se pronuncia: Ji-locks) para GFS / GFS2, tiene un efecto en todo el clúster. Cada Inode en el sistema de archivos tiene dos glocks asociados. El uno (llamado iopen glock ) solo se usa para realizar un seguimiento de qué proceso abrió el inodo. El otro, el inodo glock, controla la caché asociada con ese inodo. Un glock tiene cuatro estados, UN ( desbloqueado , desbloqueado ), SH ( compartido , compartido - un bloqueo de lectura), DF ( diferido , diferido - un bloqueo de lectura incompatible con SH) y EX ( exclusivo , exclusivo). Cada uno de estos cuatro modos corresponde directamente a un modo de bloqueo DLM.
Para garantizar la coherencia de los datos y metadatos en el clúster, se establecen ciertas restricciones. Cuando el glock está en modo EX, el inodo puede almacenar datos en caché, pero también metadatos (que pueden estar "sucios", es decir, esperando ser sobrescritos en el sistema de archivos). En el modo SH, el inodo puede almacenar en caché datos, pero también metadatos, que no deben estar sucios. En el modo DF, el inodo solo puede almacenar metadatos en caché y, nuevamente, no debería estar sucio. El modo DF solo se usa para E / S directa (es decir, eludir el caché del sistema operativo mediante el uso de un caché específico). En el modo UN, el inodo no debe almacenar en caché los metadatos.
El bloqueo EX se utiliza para que las operaciones que modifican los datos o metadatos de un inodo no interfieran entre sí. Esto significa que algunas operaciones, como crear o eliminar archivos en el "mismo" directorio o escribir en el "mismo" archivo, deberían, en general, limitarse a un nodo en el clúster. Obviamente, hacer estas operaciones desde diferentes nodos funcionará como esperamos, pero como es necesario vaciar las cachés con frecuencia, no será muy eficiente.
La pregunta más frecuente sobre el rendimiento de GFS / GFS2 es: ¿por qué puede ser deficiente el rendimiento de los servidores de correo? Debería ser relativamente obvio por lo anterior que la solución es dividir la cola de correo en directorios separados e intentar (tanto como sea posible) que cada nodo lea y escriba en un conjunto de directorios privados.
GFS y GFS2 son sistemas de archivos de registro por diario, y GFS2 admite un conjunto de modos de registro por diario 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 habilitar el registro de los datos individuales de un archivo, pero solo cuando su tamaño es cero. Los archivos registrados en GFS adolecen de una serie de limitaciones, como la falta de compatibilidad con llamadas al sistema mmapo sendfile. También utilizan un formato de disco diferente al de los archivos normales. También hay un atributo "heredar-diario" que, cuando se coloca en un directorio, establece todos los archivos (resp. Subdirectorios) creados en este directorio con el indicador "diario" (resp. "Inherit-diario"). Esto se puede usar en lugar de la opción de montaje data=journal, que ext3 admite (pero no GFS / GFS2).
GFS2 también admite el modo data=ordered, que es similar a data=writeback, excepto que los datos sucios se sincronizan antes del final de cada volcado de registro. Esto asegura que los bloques que se han agregado a un inodo tendrán su contenido escrito en el disco antes de que se actualicen los metadatos para guardar el nuevo tamaño y así evitar la aparición de bloques no inicializados en un archivo, si un nodo está fuera de servicio. El modo de registro predeterminado es data=orderedcoincidir con el modo predeterminado de ext3.
GFS2 aún no admite el modo data=journal, pero usa (a diferencia de GFS) el mismo formato de disco para archivos normales y archivos registrados por diario, y admite los mismos atributos "diario" y "heredado-diario". GFS2 también afloja las restricciones sobre cuándo se puede cambiar el atributo "diario" de un archivo: en cualquier momento, siempre que el archivo no esté abierto (de nuevo, como ext3 ).
Por motivos de rendimiento, cada nodo en GFS y GFS2 tiene su propio diario. En GFS, los registros son dominios de disco ( extensiones de disco ), en GF2 son solo archivos normales. La cantidad de nodos que pueden montar el sistema de archivos simultáneamente está limitada por la cantidad de registros disponibles.
GFS2 fue diseñado para que la actualización desde GFS sea un proceso sencillo. Para ello, la mayoría de las estructuras de disco permanecieron igual que en GFS, incluido el orden de bytes big-endian . Sin embargo, existen algunas diferencias:
Los sistemas de registro GFS y GFS2 no son compatibles entre sí. La actualización es posible mediante el uso de una herramienta ( gfs2_convert) que se ejecuta en sistemas de archivos (en frío) para actualizar los metadatos. Algunos bloques se reservan en los registros de GFS para crear archivos per_node(muy pequeños) que necesita GFS2 durante el proceso de actualización. La mayoría de los datos permanecen en su lugar.
El "metasistema" GFS2 no es un sistema de archivos completo, sino una raíz alternativa del sistema de archivos principal. Sin embargo, se comporta como un sistema de archivos "normal", que contiene los diversos archivos del sistema utilizados por GFS2 como contenido, y normalmente los usuarios no necesitan echarle un vistazo. Las utilidades de GFS2 montan y desmontan el metasistema bajo demanda, detrás de escena.