Después de una larga pausa vuelvo a la carga con otro examen para completar mi RHCA. Este ha sido el examen más difícil que he hecho hasta ahora, fundamentalmente por la variedad de temas que toca y por el poco margen de error que hay durante el mismo — cualquier despiste leyendo el enunciado o acordándose de en qué unidad está expresado cierto parámetro dará al traste con el ejercicio.

Los contenidos del curso y examen están disponibles en la web de Red Hat, y muy resumidamente son:

• Tuning de red
• Tuning de disco (planificadores, etc)
• Tuning de memoria (buffers, swappiness, NUMA)
• Servicios confinados (cgroups)
• SystemTap
• Gestión de energía
• Tuned

De los cursos que he hecho con Red Hat, es el que menos me ha gustado. Si bien es cierto que el temario es completo, siempre se queda uno con la sensación de haber sacado menos cosas en claro que antes de empezar 🙂 .

Al final todo se reduce a medir, cambiar un parámetro, y medir otra vez a ver si ese parámetro ha causado una mejora en el sistema que estamos analizando. Y, por supuesto, quien vaya esperando encontrar recetas mágicas para arreglar un problema, que se vaya olvidando… (más allá del net.ipv4.low_latency = 1). Quizá se echan en falta algunos ejemplos más de qué es “lo normal” en el mundo real (ej, cuantas IOPS se pueden esperar de un cierto almacenamiento, …) y algún parámetro más.

En definitiva, un examen exigente donde hay que llevar las cosas muy claras y que me alegro de haberme quitado de encima 🙂 . Y para acabar, una reflexión:

– Por favor, ¿la unidad de pediatría?
– niños por segundo.

Estos días estoy cacharreando con Red Hat Cluster Server en RHEL6. En su momento configuré una buena cantidad de clusters con RHEL5, pero hasta el momento no había podido meterme con esta nueva versión y disfrutar de las mejoras que trae.

Las cosas más reseñables que he visto hasta ahora:

• Soporte de comunicación intra-cluster en HA. Hasta el momento, sólo se podía definir un único interfaz de red por el que los nodos del cluster se comunicaba entre sí (típicamente el interfaz de producción con un bonding ó un cable cruzado si solo son 2 nodos). Si ese mecanismo falla (fallo de tarjeta de red, diseño de red inadecuado, escenario de fallo de red no suficientemente probado, etc), los nodos del cluster pierden conexión entre sí y se produce un escenario de split-brain o de particionamiento del cluster. Para remediar esto, se puede configurar un segundo interfaz por el que los nodos del cluster se comunican entre sí.
• Soporte de nuevos mecanismos de fencing. En el escenario anterior de split-brain, los miembros del cluster intentan “apagar” (Shoot the other node in the head – STONITH) a los miembros que no cooperan (están particionados o colgados) para evitar que multiples nodos accedan simultáneamente a los datos y se produzcan corrupciones de datos. Pues bien, RHEL6 soporta power fences como UCS, iLo, Drac y también han añadido soporte para Vmware vSphere, RHEV, etc.
• Soporte (limitado) de snapshots LVM dentro de un cluster. Hasta ahora, no se podían hacer snapshots de un volumen LVM en cluster; con la versión 6 ya se pueden realizar aunque existe la limitación de que el LV ha de estar activado exclusivamente en el nodo que realiza el mismo; en el resto de nodos hay que inactivar el LV manualmente.
• tgtd no soporta (aún) reconfiguración en caliente. tgtd es el demonio que permite ofrecer dispositivos (ej: volúmenes LVM) a través de iSCSI a clientes. En el caso de querer añadir LUNs o tener que reiniciar el servicio por cualquier motivo, no se dejará al tener clientes conectados. Al no tener posibilidad de iniciar múltiples instancias, no tendremos un HA iSCSI real. Así que de momento a seguir usando nuestras cabinas iSCSI de toda la vida 😉
• ccs está mucho más maduro que antes. Incluso podríamos configurar un cluster desde 0 sin usar el GUI web ni editar el cluster.conf a mano. Un ejemplo aquí: Creating a cluster with CCS .
• En GFS2 por fín se pueden añadir copias de los metadatos en caliente. En versiones anteriores, era necesario planificar cuántas máquinas iban a acceder al filesystem de forma simultánea y disponer una copia de los metadatos para uno. Dado que esto se tenía que hacer en el momento de la creación del filesystem, era un engorro encontrarte más tarde que te habías quedado corto.
• GlusterFS: En general todo ha sido una novedad para mi, pues no había usado nunca antes este sistema de ficheros distribuido. La sensación es que, aun teniendo un producto comercial basado sobre él (Red Hat Storage Server), está un poco verde a nivel de documentación. En todo caso, es una alternativa interesante para replicación de ficheros low-cost, especialmente teniendo en cuenta que soporta geo-replicación.

También incluyo unos cuantos recursos interesantes que encontré preparando el examen de certificación:

• Taste of Training – Exploring Red Hat Enterprise Clustering and Storage Management.
• Presentación en el Red Hat Summit 2012 de Thomas Cameron sobre clustering. Incluye también scripts para crear y desconfigurar el entorno.
• Por supuesto, la guía de contenidos del curso oficial, y el detalle de los objetivos del examen.

La preparación del examen se puede hacer en entornos virtuales; en mi caso lo hice bajo Fedora 17 con KVM. La parte de storage se puede hacer con RHEL6 “pelado”, la parte de GlusterFS se puede hacer con los paquetes de gluster de EPEL y la parte de cluster se puede excepto la configuración de dispositivos de fencing.

Happy hacking 😉