Camino al RHCA: Cluster y Storage (EX436)

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:

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

Sobre análisis post mórtem

Una de las cosas que me fastidia de mi trabajo son las notificaciones de incidencia que recibimos, indicando que tal o cual sistema no funciona: Exchange, Blackberries, Intranet, web publica, VPNs, etc. No por la incidencia en sí misma, si no porque todos los correos acaban con una frase del tipo: "Estamos investigando la causa raíz de la incidencia y ya daremos más detalles".

Tal notificación nunca se produce, y como usuario de esos servicios, se queda uno con la sensación de oscurantismo, de incertidumbre y un cierto grado de desconfianza hacia la gente que opera dichos servicios. Además, como ingeniero de sistemas, quiero saber qué ha fallado, cómo ha fallado y cómo se va a evitar que eso pase en el futuro.

Empresas tan importantes como Google o Amazon AWS hacen públicos análisis post mórtem con unos elevados niveles de detalle que permiten aprender alguna cosa que otra:

Estos informes son especialmente interesantes de cara a evaluar distintos proveedores de servicio: cuando contratas algo, deseas saber el grado de transparencia de la empresa que hay detrás, si son capaces de entender los servicios que ofrecen, su grado de madurez y experiencia operando los mismos y qué has de esperar de ellos cuando las cosas vayan mal. Por ejemplo:

  • Que no haya documentación clara de cómo tratar una incidencia o desastre.
  • Que esa documentación exista, pero no esté actualizada, sea incompleta o parcialmente incorrecta.
  • Que el personal que ha de tratar la incidencia no conozca al dedillo dicha documentación y se tenga que poner a buscarla y leerla en el momento.
  • Que, durante un cambio programado, no exista un guión detallado con los pasos a seguir.
  • Que dicho guión no se haya seguido correctamente porque la persona encargada llevaba trabajando 12h seguidas en un turno sin fin (O porque la noche anterior estuvo de guardia y le llamaron 4 veces).
  • Que un sistema que aporta "mejor disponibilidad" (HA, cluster, redundancia hardware, ...) no se pruebe suficientemente y no se active cuando lo deseamos.
  • Que si se activa, no lo haga en el tiempo que esperamos.
  • O que se active, pero haya otros elementos que fallen y haya una indisponibilidad de servicio.

Las posibilidades de fallo son tantas que hay toda una ciencia encargada de estudiar la resiliencia ó resistencia en infraestructuras IT: Resilience Engineering (parte 1) y parte 2 (ojo, el segundo enlace es bastante denso).

En otro post hablaré algo mas sobre resilience engineering... cuando tenga las ideas más claras :-)

Camino al RHCA: Satellite (EX401)

Llevaba ya unos cuantos meses planteándome conseguir la certificación RHCA (Certified Architect) de Red Hat. Hoy he dado el primer paso presentándome al examen EX401 que cubre lo siguiente:

  • El propio RH Satellite, basado en el proyecto libre Spacewalk.
  • Cobbler, como herramienta de provisioning, usando servidores DHCP y TFTP.
  • Subversion para gestión de repositorios de datos.
  • Generación y firma de paquetes RPM, usando GPG.

Dado que me presentaba al examen sin atender al curso oficial, he tenido que tirar de diversos recursos encontrados en Internet, fundamentalmente:

Aunque lógicamente Red Hat no permite que se divulguen detalles del examen, aquí van algunas cosas a tener en cuenta.

  • Como en todos los exámenes prácticos, el tiempo es MUY limitado. Hay que ser consciente del tiempo empleado en cada ejercicio para que algo pequeño no nos agote todo el tiempo.
  • En relación con lo anterior: leerse detenidamente el examen, hacerse un esquema de todo lo que hay que hacer y sus pre-requisitos y ser consciente de completar el máximo de tareas dentro de cada ejercicio que se pueda. Siempre es mejor tener alguna tarea completa que todo el ejercicio a medio hacer.
  • La documentación online del Satellite está disponible. Pero claro, si la tienes que estar leyendo en el momento, tienes un problema... ;-)
  • Es muy muy recomendable hacerse varias instalaciones desde 0 para familiarizarse con el proceso, así como montar toda la infraestructura Cobbler, Kickstarts, canales, canales de configuración, etc. Spacewalk tiene una terminología un poco enrevesada que conviene conocer al dedillo para no liarse durante la prueba.

En fin, un examen exigente en el que he disfrutado un montón (soy el único que al que le pasa eso en los exámenes?), y, también he de decir, aprendido un par de cosas nuevas que no se me habían ocurrido en los laboratorios que me había diseñado o en el uso diario que le daba al Satellite.

La seguridad en la nube

El muy sonado caso del ataque a Mat Honan me ha hecho pensar sobre la clase de seguridad que tenemos en nuestros dispositivos conectados al cloud. (Resumen ejecutivo: Atacantes consiguen password de iCloud, borran remotamente TODO el contenido del iPhone/iPad/MacBook y toman el control de cuentas tipo Twitter, etc).

He de decir que siempre he sido un gran defensor de tener mis propias copias de "todo" en local; tengo almacenados correos de hace mas de 15 años, scripts/software, proyectos, textos, fotos, y prácticamente cualquier ristra de bits que haya generado en estos años.

Hasta el momento, estoy usando Gmail para tener una copia online y siempre disponible de estos correos. No es la "fuente primaria" de datos, si no meramente un backup de los mismos. Más por comodidad que por otra cosa; está bien poder localizar un cierto documento que te mandaron hace tiempo, o un enlace, o un correo con datos importantes.

Sin embargo, el hackeo antes mencionado me hace plantearme si realmente es tan buena idea tenerlo todo en la nube: una vez que un dato ha salido de tu ordenador has de considerarlo dominio público. De ahí el adagio de "No subas a Internet nada que no quieras que tu madre vea" :-) . Y no solamente eso, si no que te pueden privar de acceder a esos datos. Pierdes tu agenda, tus contactos, las direcciones de correo, fotos irreemplazables, ... A todos los efectos, borrar tu presencia digital es casi como borrar tu vida real de un plumazo

Me hace especial gracia esta cita del artículo:

In short, the very four digits that Amazon considers unimportant enough to display in the clear on the Web are precisely the same ones that Apple considers secure enough to perform identity verification.

Las conclusiones que saco de esto son :

  • Haz un backup local de tus datos. Nadie sabe mejor que tú lo que los valoras y qué repercusiones puede tener el perderlos.
  • No subas a Internet nada que no puedas asumir que se haga público. Ya sean fotos, documentos, tarjetas de crédito y DNIs/Pasaportes escaneados, ...
  • Plantéate a cuantas cosas pueden acceder si pierdes una sola cuenta. En el caso de Mat, al perder su cuenta iCloud el atacante tuvo acceso a todas sus demás cuentas en otros servicios. La seguridad del email se ha vuelto crítica en los últimos tiempos.
  • Revisa las políticas de verificación de identidad de tus proveedores. La doble autenticación de Gmail ("algo que sabes , algo que tienes") añade un punto más de dificultad para poder asaltar una cuenta, pero no es definitivo. En el caso de Apple, bastó con "marear" un poco a los empleados de su call centre hasta que uno de ellos cometió una indiscreción y reveló un dato crítico.
  • Cambia tus contraseñas periódicamente. Quizás no mensualmente, pero sí una vez al año como mínimo. No es necesario que te sepas todas ellas; basta con que estén apuntadas en un sitio seguro (como Keepassx) y que tu navegador las recuerde. Por supuesto, no compartas contraseñas entre servicios. Es buena idea usar también generadores de passwords como pwgen y apg .
  • No asumas que no te han hackeado ya. Quién sabe si ya hay algun exploit para Gmail, Outlook et al, y alguna panda de criminales chinos, rusos, etc no tiene ya todos tus datos ( sí, me gusta la paranoia ;-) )

Está claro que aún nos queda mucho por aprender a todos, pero a base de ejemplos como este supongo que iremos espabilando :-)

Configurar mDNS en RHEL6

Por alguna razón que no alcanzo a comprender, RHEL6 no incluye de forma predeterminada el paquete nss-mDNS necesario para que el DNS multicast funcione (Avahi/Zeroconf et al).

Aquí va una pequeña guía de instalación y configuración, incluyendo el repositorio externo EPEL:

[root@rhel6 ~]# yum install -y avahi avahi-tools  
[root@rhel6 ~]# yum install -y --nogpgcheck http://download.fedora.redhat.com/pub/epel/6/i386/epel-release-6-5.noarch.rpm  
[root@rhel6 ~]# yum install -y nss-mdns

Modificar en el /etc/nsswitch.conf :

# grep hosts /etc/nsswitch.conf  
hosts: files dns4_minimal [NOTFOUND=return] mdns4_minimal [NOTFOUND=return] dns

Y finalmente reiniciar DBus y Avahi-daemon:

[root@rhel6 ~]# chkconfig messagebus on  
[root@rhel6 ~]# chkconfig avahi-daemon on  
[root@rhel6 ~]# service messagebus restart  
Stopping system message bus: [FAILED]  
Starting system message bus: [ OK ]  
[root@rhel6 ~]# /etc/init.d/avahi-daemon restart  
Shutting down Avahi daemon: [FAILED]  
Starting Avahi daemon... [ OK ]

De esta forma, todos los dispositivos que estén directamente conectados en nuestra red local (VLAN) serán capaces de conocernos bajo el nombre rhel6.local , o el hostname que tengamos configurado y .local . Muy cómodo si no tenemos ningún servidor DNS en nuestra red o para dispositivos itinerantes :-)

Construir entornos de compilación con rinse y debootstrap

Para poder generar de forma sencilla nuestros paquetes RPM para diferentes distribuciones, podemos usar un chroot que contenga las versiones de software necesarias.

Básicamente, chroot permite ejecutar software cuyo directorio de ejecución esté enjaulado; significando que el directorio root (/) de estas aplicaciones será otro.

Dado que generar un entorno chroot manualmente es bastante tedioso debido a que tenemos que trasladar todas los ejecutables que nos sean necesarios, más las librerías correspondientes, existen dos herramientas que nos permiten automatizar esto.

Una de ellas es rinse, que nos permite construir entornos basados en Fedora y CentOS en nuestra distribución Debian.

La forma de uso sería :

[ root@minime : /opt ] # mkdir -p /opt/centos5/dev
[ root@minime : /opt ] # mount --bind /dev /opt/centos5/dev
[ root@minime : /opt ] # rinse --distribution centos-5 --directory /opt/centos5

Una vez realizado esto, tendríamos un entorno básico en /opt/centos5 . En caso necesario, tendremos que editar los siguientes ficheros para hacerlos coincidir con los UIDs y GIDs de fuera del chroot:

/etc/passwd
/etc/shadow
/etc/group

Una vez hecho esto, podemos entrar en el chroot y empezar a instalar el software que nos sea necesario para nuestra labor :

[ root@minime : /opt ] # chroot /opt/chroot /bin/bash
(chroot) # yum install -y rpm-build sudo vim-enhanced tar gzip wget man make gcc gcc-c++

La ventaja de este método es que podemos tener varias distribuciones simultáneamente sin necesidad de necesitar pesadas máquinas virtuales, desperdiciar espacio en el disco duro creando discos virtuales; y sin ningún tipo de pérdida de rendimiento.

Si queremos construir un entorno Debian, deberemos usar la herramienta debootstrap .

Si estamos en Debian y queremos un chroot de Fedora o CentOS, podemos usar mach. (Nada que ver con GNU Mach ! ;-) )