Capítulo 2. Configuración de GFS2 consideraciones operacionales

GFS2 está basado en una arquitectura de 64 bits, la cual en teoría, acomoda un sistema de archivos de 8 EB. Sin embargo, el tamaño máximo de un sistema de archivos GFS2 para un hardware de 64 bits es de 100 TB y el tamaño máximo soportado actual de un sistema de archivos GFS2 para un hardware de 32 bits es 16 TB.

Observe que a pesar de que los sistemas de archivos GFS2 sean posibles, no significa que sean recomendables. La regla con con GFS2 es que entre más pequeño mejor: es mejor tener 10 sistemas de archivos de 1TB en lugar de un sistema de archivos de 10 TB.

Hay varias razones por las cuales se deben mantener sistemas de archivos GFS2 pequeños:

Además, menos grupos de recursos para mantener significa mejor rendimiento.

Claro está que si desea crear un sistema de archivos GFS2 demasiado pequeño, podría quedarse sin espacio, y esto tiene sus propias consecuencias. Debe considerar sus razones para decidir el tamaño.

A partir del lanzamiento de Red Hat Enterprise Linux 6, el comando mkfs.gfs2 intenta estimar un tamaño de bloque óptimo basado en la topología del dispositivo. En general, los bloques de 4K se prefieren porque 4K es el tamaño de página (memoria) predeterminada para Linux. A diferencia de otros sistemas de archivos, GFS2 realiza la mayoría de sus operaciones mediante búferes de kernel de 4k. Si su tamaño de bloque es de 4K, el kernel tiene menos trabajo para manipular los búferes.

Se recomienda usar el tamaño de bloque predeterminado, el cual produce el máximo rendimiento. Solo necesita usar un tamaño de bloque diferente si requiere almacenaje eficiente de varios archivos muy pequeños.

GFS2 requiere un diario para cada nodo en el clúster que necesite montar el sistema de archivos.Por ejemplo, si tiene un clúster de 16 nodos, pero solo necesita montar el sistema de archivos desde dos nodos, necesitará únicamente dos diarios. Si necesita montar un tercer nodo, siempre podrá añadir un diario con el comando gfs2_jadd. Con GFS2, usted puede añadir diarios sobre la marcha.

Cuando ejecute el comando mkfs.gfs2 para crear un sistema de archivos GFS2, especifique el tamaño de los diarios. Si no lo desea, se predeterminará a 128MB, el cual deberá ser óptimo para la mayoría de las aplicaciones.

Algunos administradores de sistemas podrían pensar que 128MB es excesivo y verse tentados a reducir el tamaño del diario a un mínimo de 8MB o al conservador de 32MB. Aunque esto podría funcionar, puede afectar gravemente el rendimiento. Al igual que muchos sistemas de diarios, cada vez que GFS2 escribe metadatos, los metadatos se envían al diario antes de ponerlo en su sitio. Esto garantiza que si el sistema se daña o pierde energía, usted recuperará todos los metadatos cuando el diario se reproduzca en tiempo de montaje. Sin embargo, no se necesita mucha actividad de sistema de archivos para llenar un diario de 8MB y, cuando el diario esté lleno, el rendimiento disminuirá porque GFS2 tiene que esperar a que se escriba al almacenaje.

Por lo general, se recomienda usar el tamaño predeterminado de 128 MB. Si su sistema de archivos es muy pequeño (por ejemplo de 5 GB), un diario de 128 MB no será práctico. Si tiene un sistema de archivos mayor y si puede disponer de más espacio, el uso de diarios de 256 MB podría mejorar el rendimiento.

Cuando un sistema de archivos GFS2 es creado con el comando mkfs.gfs2, divide el almacenaje en dos pedazos uniformes conocidos como grupos de recursos. Intenta estimar un tamaño de grupo de recursos óptimo (que va de 32 MB a 2 GB). Puede sobrescribir el predeterminado con la opción -r del comando mkfs.gfs2.

El tamaño óptimo del grupo de recursos depende de cómo va a utilizar el sistema de archivos. Considere qué tan lleno estará o si será severamente fragmentado.

Experimente con diferentes tamaños de grupos de recursos para ver qué resulta en rendimiento óptimo. Se recomienda experimentar con un clúster de prueba antes de implementarlo en plena producción.

Si su sistema de archivos tiene demasiados grupos de recursos (cada uno de los cuales es demasiado pequeño), las asignaciones de bloques perderán demasiado tiempo en la búsqueda de decenas de miles (o cientos de miles) de grupos de recursos de un bloque libre. Entre más lleno esté su sistema de recursos, más recursos de grupos serán buscados y cada uno de ellos requerirá un cerrojo en todo el clúster. Esto conducirá a un rendimiento bajo.

No obstante, si su sistema de archivos tiene muy pocos grupos de recursos (cada uno de los cuales es demasiado grande), la asignación de bloques podría pelear más a menudo por el mismo cerrojo de grupos de recursos, lo cual también impactará el rendimiento. Por ejemplo, si tiene un archivo de 10 GB que está repartido entre cinco grupos de recursos de 2 GB, los nodos en su clúster se luchará más a menudo por esos cinco grupos de recursos que si el mismo sistema de archivos estuviera repartido entre 320 grupos de recursos de 32 MB. El problema se exacerba si su sistema de archivos está casi lleno porque cada asignación de bloques podría tener que mirar a través de varios grupos de recursos antes de que encuentre uno con un bloque libre. GFS2 intenta mitigar este problema en dos formas:

El peor escenario es cuando hay un directorio central en el cual todos los nodos crean archivos, ya que todos los nodos lucharán constantemente por bloquear el mismo grupo de recursos.