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 ;-)