Capítulo 2. Configuración de GFS2 consideraciones operacionales
El Sistema de archivos global 2 (GFS2) permite a varios computadores (“nodos”) en un clúster compartir de forma cooperativa el mismo almacenaje. Para realizar esta cooperación y mantener la consistencia de datos entre los nodos, los nodos emplean un esquema de bloqueo de todo el clúster para recursos de sistemas de archivos. Este esquema de bloqueo usa protocolos de comunicación tales como TCP e IP para intercambiar información de bloqueo.
Para mejorar el rendimiento, siga las recomendaciones descritas en este capítulo, incluidas las recomendaciones para crear, usar y mantener un sistema de archivos GFS2.
Importante
Asegúrese de que la implementación de la adición de alta disponibilidad de Red Hat satisfaga sus necesidades y pueda recibir soporte. Consulte a un representante autorizado de Red Hat para verificar su configuración antes de implementarla.
2.1. Consideraciones de formateo
Esta sección proporciona recomendaciones sobre cómo formatear su sistema de archivos GFS2 para optimizar el rendimiento.
2.1.1. Tamaño del sistema de archivos: Entre más pequeño, mejor
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:
- Se requiere menos tiempo para hacer la copia de seguridad de cada sistema de archivo.
- Se requiere menos tiempo para chequear el sistema de archivos con el comando
fsck.gfs2. - Se requiere menos memoria para chequear el sistema de archivos con el comando
fsck.gfs2.
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.
2.1.2. Tamaño de bloque: El predeterminado es el preferido (4K)
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.
2.1.3. Número de diarios: uno por cada nodo que monte
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.
2.1.4. Tamaño de diario: El predeterminado suele ser óptimo (128MB)
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.
2.1.5. Tamaño y número de grupos de recursos
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:
- Primero, cuando un grupo de recursos está completamente lleno, este recuerda y trata de evitar chequearlo en futuras asignaciones (antes de que un bloque se libere de él). Si usted nunca borra archivos, la competencia será menos grave. No obstante, si su aplicación está constantemente borrando bloques y asignando nuevos bloques en un sistema de archivos que está en su mayoría lleno, la competencia será muy grande y esto tendrá un grave impacto de rendimiento.
- Segundo, cuando se añaden nuevos bloques a un archivo existente, GFS2 intentará agrupar los nuevos bloques en el mismo grupo de recursos que el archivo. Esto se realiza para incrementar el rendimiento: en un disco giratorio, las búsquedas toman menos tiempo cuando están físicamente juntos.
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.
