Caxarreo – PÃ¡gina 2

Rescatando una instancia con EBS en Amazon

Este domingo, tras una increible fiesta mexicana la noche anterior, se me ocurre echar un vistazo al mail y me encuentro con un correo de Amazon indicándome que tienen problemas con el servidor anfitrión que alberga una de mis instancias de servidores virtuales, por cierto la que conseguí de forma gratuita.

We have noticed that one or more of your instances are running on a host degraded due to hardware failure.

i-55624c22

The host needs to undergo maintenance and will be taken down at 12:00 GMT on 2010-11-22. Your instances will be terminated at this point.

The risk of your instances failing is increased at this point. We cannot determine the health of any applications running on the instances. We recommend that you launch replacement instances and start migrating to them.

Feel free to terminate the instances with the ec2-terminate-instance API when you are done with them.

Sincerely,
The Amazon EC2 Team

El correo me dice que mi instancia está funcionando en un host degradado debido a un problema de hardware y que mi instancia será terminada en una operación de mantenimiento esta misma noche… al principio ni siquiera me lo podía creer ¿dónde quedó lo de la ubicuidad de la nube y el abstraerse de los problemas físicos? Dado que la instancia dispone de un almacenamiento persistente EBS, no podrían simplemente migrarla en vivo a otro servidor y santas pascuas. ¿Tendrá algo que ver con que se trata de una micro instancia, que está paravirtualizada o a que estemos en el pool de servicio gratuito? Igual han dedicado todos los servidores a punto de romperse a esta campaña de marketing… quién sabe.

Anteriormente cuando no disponíamos de imágenes con el almacenamiento directamente sobre EBS si una instancia era terminada todos los datos de la instancia que no salvaras explicitamente en un bloque EBS especialmente montado para ese propósito eran eliminados, ahora cuando terminas una instancia con EBS simplemente el EBS se queda almacenado para que lo anexes a otra instancia o para que lo borres si ya no vas a hacer uso de él. Así que bastaría con esperar a que pararan la imagen y levantar una nueva con ese EBS, pero al ir a conectarme comprobé que la instancia ya ni si quiera estaba en funcionamiento y no podía acceder a ella por web o por ssh, así que me lanzé ¡AL RESCATE!

El primer paso era parar la instancia que estaba fallando para poder liberar el EBS, pero sorpresa… la instancia no se para por mucho que se lo pidas, supongo que debido a los temibles problemas de hardware. Tras esperar veinte minutos decidí buscar un plan alternativo. Y aquí es dónde sacamos provecho de la potencia de los snapshots, así que simplemente hacemos un snapshot, es decir una copia, de nuestro EBS y creamos un nuevo EBS a partir del snapshot con lo que tendremos una copia exacta de nuestro almacenamiento disponible.

El siguiente paso es arrancar una instancia y asignarle el nuevo EBS que hemos sacado del snapshot. Me parecía recordar que podías hacer eso en un sólo paso pero a través del API y la línea de comando pero no encontré forma de hacerlo a través de la consola web así que hubo que hacerlo en varios pasos. Arrancamos la nueva instancia con un EBS por defecto, luego la paramos, desligamos el EBS de la instancia y lo borramos para a continuación enlazar el EBS que sacamos del snapshot con la instancia en la ubicación /dev/sda1 y ya estamos listos para arrancar una instancia clonada desde la original que estaba fallando.

Por otro lado, es posible que tengas que hacer alguna adaptación interna de tu servidor ya que tu dirección ip pública y privada en Amazon habrán cambiado, en mi caso a este nivel tuve que cambiar el /etc/hosts del servidor. Si dispones de una ip elástica para ofrecer los servicios te bastará con cambiar la instancia a la que apunta esta a la nueva instancia que hemos creado y tu servicio debería volver a la vida y responder de forma correcta a los dominios que la apunten. Cómo yo no dispongo a día de hoy de ip elástica, no entraba en el pack gratuito de Amazon, estaba usando la ip pública de Amazon cómo entrada a mis servicios y alguno de ellos cómo wordpress dependen de ella me tocó arreglarlos en la base de datos:

update wp_options set option_value=Â»http://minuevaippublicaamazon/miwordpressÂ» where option_name=Â»stieurlÂ»;
update wp_options set option_value=Â»http://minuevaippublicaamazon/miwordpressÂ» where option_name=Â»homeÂ»;

La verdad es que se destapan dos temas igualmente de importantes respecto al servicio de Amazon: la fiabilidad de la nube y la felxibilidad de la que nos provee. Cada uno que saque sus conclusiones y vea hacia dónde se inclina la balanza.

Sorteo en el departamento de IT

Con la escusa de que habíamos acumulado algo de merchandising de los distintos eventos en los que hemos participado, decidimos hacer un pequeño sorteo dentro del departamento de IT para ver quién se quedaba cada cosa. Cómo no, el sorteo no podía ser por los medios tradicionales, lease papelitos o piedra-papel-tijera, así que me aventuré a tirar unas líneas de python que resolvieran el problema de forma sencilla, aunque como veréis luego decidimos complicarlo un pelín más. El sorteo lo proyectamos en la tele que tenemos para la monitorización justo al lado del departamento:

La primera versión del código era realmente sencilla y muestra lo fácil que es hacer algo con python, simplemente declara un array de personas y otro de regalos, recorre los regalos y va eligiendo una persona de forma aleatoria como ganador de cada regalo y eliminando esa persona del array de personas:

sorteo-simple.py (Pincha sobre el enlace para ver o descargar el código)

Pero así quedaba un poco simplón por lo que añadí alguna opción más para hacerlo más interesante. La idea es que había gente que sólo estaba interesada en algunos regalos y tenía su orden de preferencia, así que modifiqué el código para que las tuviera en cuenta en caso de que te tocara un regalo a modo de Wish List:

sorteo-wish-list.py (Pincha sobre el enlace para ver o descargar el código)

Y por supuesto el código fue enviado a todos los participantes para que lo auditaran antes de su ejecución con el consiguiente debate de cómo se podría hacer mejor… además en el correo me colé y puse para vuestra audición y alguno quería ponerlo con el festival. Y claro, así no hay forma de hacer trampa, con lo que finalmente no me tocó ningún regalo cómo podéis ver si pincháis sobre la imagen de la tele, pero al menos me queda esta entrada del blog cómo recuerdo.

Novedades en RHEL 6

En el post anterior comentaba las primeras impresiones de la instalación de RHEL 6 y os prometía ampliar algunas de las novedades que trae esta nueva versión después de la presentación que nos realizaron en el evento de partners de Red Hat.

Cómo la descripción general podéis verla en la web de Red Hat sobre RHEL os dejo las notas que tomé porque me sorprendieron o interesaron durante la presentación:

* Mejoras en la eficencia energética: se incorporan comandos como powertop e iotop para medir el consumo de los distintos procesos así cómo tuned, un demonio que va adaptando los recursos del sistema para mejorar la eficiencia

* Con cgroups podremos establecer un límite de recursos sobre un proceso a nivel de número y porcentaje de cpu, memoria, disco y red de forma dinámica.

* Se de usar PAM a SSSD

* Respecto al temido SE-Linux se crean dos nuevos modos: SE-Linux kiosk para aplicar políticas a sesiones en modo kiosko cuando es un terminal de uso público y SE-Linux sandbox para confinar aplicaciones que no tienen todavía definida una política predefinida de SE-Linux

* En cuanto a IPSEC se pasa de usar OpenVPN a OpenSwan

* Dispondremos de System Tap para depurar aplicaciones, pero al parecer también nos va a permitir depurar aplicaciones Java

* KVM entre muchas otras mejoras permite añadir recursos físicos en caliente (CPU, disco, memoria, etc…)

* Yum permite hacer rollback de una instalación !!!

* Simplificado el reporte de errores ante fallos graves que captura el estado de la máquina y permite enviarlo a Red Hat para abrir un bug

* En la parte de Cluster podemos destacar el uso de corosync, unfencing y la interfaz conga rediseñada

También hay grandes cambios en el tema de subscripciones y se complica un poco el tema de saber cuál aplica a tu caso, además de estar fuertemente ligado a la virtualización, pero básicamente tendremos que sacarlo de cruzar los siguientes datos:

* Por cada par de sockets (zocalos utilizados) del servidor anfitrion
* Por el número de guest RHEL máximo que podemos correr en ese anfitrión (1, 4 o ilimitado)
* Por el número de extras que queramos contratar (alta disponibilidad, GFS, XFS, soporte extendido, etc…)

Un caso curioso es el de los clusters de virtualización que tengan migración en vivo, en cuyo caso todos los servidores a los que pueda ir un guest RHEL deben de tener una subscripción activa y el máximo de guests que podremos ejecutar en total en el cluster saldrá de sumar los guests permitidos en cada una de las subscripciones de los nodos anfitriones (1 o 4 o más si apilamos varias subscripciones en ese mismo anfitrión) o será ilimitado en caso de tener subscripciones de tipo ilimitado en todos los nodos del cluster, ya que estas no se pueden mezclar. Un poco lioso.

Lo que sigue estando verde es el tema de usar RHEL en nubes públicas aunque se están avanzando acuerdos con los proveedores de Cloud para que lo ofrezcan por ahora no hay subscripciones que puedas pagar por uso provenientes de la propia Red Hat.

ACTUALIZACIÓN: Se me había olvidado comentar el tema de formación y certificación que también tiene sus novedades. Cómo comentaba por twitter casi me enteré antes de que estaba RHEL 6 en la calle porque me llegó un correo indicando que en breve va a estar obsoleta mi certificación RHCE, la saqué con la versión 4, y que la RHCT, la renové a la versión 5 en el evento de partners de Valencia dónde hacían exámenes gratuitos, se convalida con la nueva certificación RHCSA (Red Hat Certified System Administrator) que será la nueva certificación previa a sacar el RHCE.

Probando la instalación de RHEL 6

Hace un par de días se lanzaba definitivamente la nueva versión de Red Hat Enterprise Linux: RHEL 6. Y aunque ya le había echado un ojo a alguna Release Candidate he sacado un rato para probar la instalación en una máquina virtual de KVM de la edición de servidor de RHEL 6 recien descargada de Red Hat Network. La instalación ha sido muy sencilla y aquí os dejo los pasos y algunos comentarios al respecto.

La instalación arranca con la selección del tipo de acciones que queremos realizar: instalar, instalar en modo texto, recuperar el sistema, arrancar desde el disco local o hacer el test de memoria. Nada nuevo por ahora en el horizonte, seleccionamos la opción de instalar:

A continuación haremos la típica selección de idioma y teclado, en mi caso me gusta mantener el idioma en inglés, sobretodo porque es más fácil rastrear los mensajes de error por internet, y el teclado en castellano:

Seleccionamos nuestra ubicación en Madrid:

Y pasamos a seleccionar el dispositivo de almacenamiento en el que queremos instalar, siendo las opciones básico o especializado, permitiendo esta última opciones muy interesantes para el modo servidor cómo instalar en una cabina de almacenamiento o añadir drivers de nuestro raid hardware:

…
Continuar leyendo Â«Probando la instalación de RHEL 6Â»

Zombie Howto

Hacía tiempo que no me disfrazaba para Halloween, y este año nos invitaron a una fiesta para la que había que disfrazarse, así que me puse a la tarea de buscar un disfraz. La verdad es que no quería comprarme nada hecho y cómo llevamos varios días con la coña de que la generación actual es la generación Zombie decidí disfrazarme de eso mismo.

En la tienda de disfraces de Getafe, el dueño de la tienda, un tipo bastante curioso, nos habló del Â«ingrediente secretoÂ» para hacer heridas y deformaciones de la piel: el Latex líquido y nos recomendó algunos trucos de cómo usarlo junto con materiales caseros cómo el papel del baño o migas de pan. También compramos algo de sangre y distintas ceras para pintar la ropa y la cara y algo de maquillaje.

Luego nos lanzamos a buscar algo más de información y ¿dónde buscar información hoy en día de cómo hacer algo? Pues en internet, y más concretamente en YouTube que ya me sacó del apuro de hacerme el nudo de la corbata en la última boda. Ahí podéis encontrar múltiples tutoriales de cómo hacer distintos trucos muy interesantes como los videos de este post, sobretodo el siguiente que nos enseña a usar el latex:

Un tema importante: reserva bastante tiempo para el proceso, a nosotros nos llevo más de dos horas y algo terminar el disfraz y llegamos bastante tarde a la fiesta, la mayor parte de este tiempo se fue en hacer las heridas y el maquillaje.

Así que nos pusimos manos a la obra, primero empezamos probando en un brazo y en la pierna ya que no teníamos ni idea de cómo iba a quedar. Y este fue un gran error… aquí viene el segundo gran consejo: si quieres evitar un doloroso final no apliques el latex encima de zonas con mucho pelo. Pero bueno, al menos nos sirvió para aprender algunos trucos para mejorar el efecto cuando lo hicimos en la cara.

Aquí tenemos una herida en el brazo a base de poner capas de latex y luego capas de papel del baño, luego se hace el corte de la herida y se le da forma para luego maquillarlo y aplicar sangre a gogo:

Y de ahí lo pasamos a la cara simulando una gran brecha en la frente que goteara sangre por la mejilla:

Después de hacer esta primera idea se me ocurrió utilizar un material nuevo: plástico de embalar de los de bolitas que me parecía podría tener un interesante efecto cómo granos asquerosos. Igualmente probamos primero en la pierna:

Para luego pasarlo a la cara:

No quedó del todo mal el invento, nos faltó ser capaces de igualar todo el maquillaje de la cara de forma más uniforme pero no nos dió tiempo a más.

Por último la vestimenta. Pilla ropa vieja que puedas pintarajear y llenar de sangre, sobretodo y tal cómo recomiendan por ahí, usa tonos claros para que no eclipsen los colores del maquillaje y para que sobre ellos se vea bien la sangre y demás. Y tachán, aquí está el resultado final:

Recuperación de desastres, algunas notas entre las llamas

¿Cuál es la probabilidad de que algo que es realmente muy improbable pase? No importa, porque por la ley del gafe terminará pasándote, así que aparte de intentar reducir la posibilidad de que esto pase el otro punto importante es estar preparado para cuando eso pase. Aquí va la historia:

Las dos semanas pasadas en el curro nos ha tocado a todo el equipo de IT ponernos el mono de bombero y apagar el incendio que provoca esa pequeña chispa tan realmente improbable. ¿Qué fue esta vez? Un fallo en los discos de la cabina central de almacenamiento, dónde tenemos la mayor parte de máquinas virtuales que son, cada día más, el centro de las operaciones de la compañía, decidieron romperse de forma coordinada. Los discos están en RAID 5 y disponemos de 3 discos de spare, discos listos para sustituir de forma automática a otro en caso de rotura, pero ¿qué pasa si cuando un disco ha fallado y está entrando uno de los de reserva y otro decide pasar también a mejor vida? El RAID ya no se puede reconstruir y en nuestro caso hay que tirar de backup. Lo siguiente ya os lo podéis imaginar, muchas horas sin dormir, carreras por los pasillos, gente preguntando cuando estará todo listo de nuevo y desesperación. Chicos, estamos en DEFCON 1.

Y aquí es dónde se debería sacar el libro Â«rojoÂ» del armario, el famoso plan de recuperación ante desastres, y todo debería ser coser y cantar. Pero ante la inexistencia de ese libro con el plan maestro, aquí van algunos consejos que me doy a mi mismo para la próxima vez que tenga que afrontar un fuego:

– Mantén la calma, hay que pensar con la cabeza fría y no actuar atropelladamente, ya que podemos agravar el problema por no pensar bien en las alternativas.

– Gestiona eficientemente la comunicación, especialmente la que Lili califica cómo comunicación en crisis como es esta, y las distintas fases en las que te encontrarás durante la recuperación: la sorpresa inicial, el fastidio de que todo no esté para ya, la sombra de las dudas y demás reacciones a favor y en contra. Yo en esta parte soy partidario de la transparencia y de intentar mantener al día a todos los implicados de cuál es la evolución de nuestro paciente, pero también hay que saber soportar el chaparrón de la mejor manera.

– Prioriza la recuperación, planificar la restauración del servicio y los datos estableciendo un sistema de prioridades hará más efectiva la recuperación, ¿qué servicios son más críticos para el negocio?

– Toma notas para el futuro, soy un gran defensor de la mejora continua, y cuando hemos llegado a una situación de desastre es un gran momento para analizar que ha podido fallar y cómo podríamos evitarlo en futuras ocasiones. Además tienes viento a favor por parte de dirección para acometer cambios y mejoras, así que hay que aprovechar la ocasión. En resumidas cuentas, como mínimo, ¿habrá libro rojo la próxima vez?

Hay mucho por hacer de ahora en adelante, pero ahora mismo sólo querría destacar el gran trabajo de todo mi equipo, ha sido increíble luchar con las llamas con vosotros y os doy las gracias porque sin vosotros y vuestra dedicación todo habría sido mucho más complicado. También gracias a todos los afectados por el problema, porque habéis sido muy comprensivos. Ahora a planificar el futuro.