6.4. Ajuste del rendimiento con GFS2

Por lo general, es posible alterar la forma en que una aplicación problemática almacena sus datos para obtener una considerable ventaja de rendimiento.

Un ejemplo típico de aplicación problemática es un servidor de correo electrónico. Estos suelen estar dispuestos con un directorio spool que contiene archivos para cada usuario (mbox), o con un directorio para cada usuario que contiene un archivo para cada mensaje (maildir). Cuando las peticiones llegan a través de IMAP, lo ideal es dar a cada usuario una afinidad con un nodo concreto. De esta forma, sus peticiones para ver y borrar mensajes de correo electrónico tenderán a ser servidas desde la caché de ese nodo. Obviamente, si ese nodo falla, la sesión puede reiniciarse en un nodo diferente.

Cuando el correo llega por medio de SMTP, de nuevo los nodos individuales pueden ser configurados para pasar el correo de un determinado usuario a un nodo particular por defecto. Si el nodo por defecto no está activo, entonces el mensaje puede ser guardado directamente en el spool de correo del usuario por el nodo receptor. Una vez más, este diseño está pensado para mantener determinados conjuntos de archivos en caché en un solo nodo en el caso normal, pero para permitir el acceso directo en caso de fallo del nodo.

Esta configuración permite el mejor uso de la caché de páginas de GFS2 y también hace que los fallos sean transparentes para la aplicación, ya sea imap o smtp.

Las copias de seguridad suelen ser otra área complicada. De nuevo, si es posible, es muy preferible hacer una copia de seguridad del conjunto de trabajo de cada nodo directamente desde el nodo que está almacenando en caché ese conjunto concreto de inodos. Si tienes un script de copia de seguridad que se ejecuta en un punto regular en el tiempo, y que parece coincidir con un pico en el tiempo de respuesta de una aplicación que se ejecuta en GFS2, entonces hay una buena posibilidad de que el clúster no esté haciendo el uso más eficiente de la caché de páginas.

Obviamente, si usted está en la posición de poder detener la aplicación para realizar una copia de seguridad, entonces esto no será un problema. Por otro lado, si una copia de seguridad se ejecuta desde un solo nodo, después de que se haya completado una gran parte del sistema de archivos se almacenará en caché en ese nodo, con una penalización de rendimiento para los accesos posteriores desde otros nodos. Esto se puede mitigar hasta cierto punto eliminando la caché de páginas VFS en el nodo de copia de seguridad después de que se haya completado la copia de seguridad con el siguiente comando:

echo -n 3 >/proc/sys/vm/drop_caches

Sin embargo, esta solución no es tan buena como asegurarse de que el conjunto de trabajo de cada nodo sea compartido, de sólo lectura en el clúster, o que se acceda a él principalmente desde un solo nodo.