Pensando en Devops

No sé si os lo he comentado ya varias veces pero me encanta la nueva mentalidad alrededor de las tendencias Devops y las Operaciones Web ágiles. Creo que es un cambio de mentalidad necesario y un gran avance para nuestra profesión pero que implica cambios a todos los niveles. Ya llevaba tiempo pensando en escribir sobre el tema ya que los recursos en inglés sobre el mismo son inagotables, pero creo que no hay tanto en español, así que os voy a dejar un batiburrillo de reflexiones que últimamente me dan vueltas en la cabeza.

El otro día estuve en el London Puppet User Group meeting y disfruté bastante de las charlas especialmente la segunda en la que mostraron un enfoque diferente en la definición de recursos orientado a provisionar varios servidores a través de Open Nebula y dejarlos configurados y operativos, todo ello a través de Puppet. Pena que todavía no he tenido la suerte de poder acercarme a London Devops y me alegro infinito de que Madrid Devops siga viento en popa, desde aquí mis felicitaciones a Mari Carmen por el empeño que está poniendo y a todos los que os acercáis a compartir por ese foro, ¿se nota que os echo de menos? 😀

Una de las primeras cosas que me vinieron a la cabeza es que no estoy seguro de si la orientación que está tomando la gente de Puppet Labs va muy en la línea de lo que yo busco en su producto. Por un lado, mantener dos desarrollos separados para la edición Enterprise y la edición Comunidad y por otro, el enfoque hacia grandes corporaciones y hacia la incorporación de elementos cómo gestión de CMDB, Workflows, etc para mí rompe un poco con la mentalidad Unix: pequeñas herramientas que hacen muy bien su trabajo y que en conjunto te dan una gran flexibilidad. Personalmente me gustaria que se trabajara más en la parte de orquestación y en romper el enfoque nodista, decidir el estado de mis nodos, por uno mucho más orientado a conjunto o a servicio.

Me encanta mcollective, creo que es una herramienta muy potente, pero no dejo de verla cómo un loop ssh para ejecutar un comando en el resultado de la busqueda de nodos que cumplen ciertas características y no lo termino de enlazar con una orquestación más basada en estados cómo es puppet sino en acciones.

Por cierto, si tenéis tiempo libre y os interesa el tema de Puppet os recomiendo que le echéis un vistazo a los videos de la pasada Puppet Conf y también a este repositorio Git que ha compartido la gente de Wikimedia con los manifiestos que ellos están usando para gestionar su infraestructura.

Otra reflexión sobre puppet, antes de pasar a otro tema, me vino del descubrimiento que en las plantillas para ficheros tipo erb podía utilizar todo el código Ruby que quisiera y esto solucionó algunos de los problemas que me estaban rondando últimamente para definir algunas plantillas algo complejas. Desde entonces un run-run en mi cabeza no para de decirme si aplicando el mismo concepto no sería mucho más potente el uso de Chef que utiliza una sintaxis más amplia y te permite utilizar el juego completo de instrucciones de ruby en tus manifiestos. Hace tiempo que no pruebo Chef, pero comentando esto con gente de la conferencia me comentaban que la orientación de Chef no cambia únicamente en eso sino que también hay que tener en cuenta que al contrario que Puppet, la ejecución de la configuración en Chef en varias ocasiones consecutivas sobre el mismo entorno en el mismo estado podría no dar lugar a los mismos efectos. Aquí me vendría bien ayuda de gente que se haya pegado más con los dos sistemas, ¿cómo véis el estado del arte los Chefistas y los Puppeteros?

Y de paso aprovecho también para volcar a texto otra de mis inquietudes de los últimos meses. Hace ya tiempo que quiero ampliar mis habilidades aprendiendo y cogiendo práctica con un lenguaje de scripting que me ayude a ser más eficiente y amplie mis posibilidades. Al principio python parecía el camino adecuado, pero cada día que pasa siento que hay más y más herramientas de administración escritas en ruby, con lo que me crece la duda, por ahora sigo poco a poco la senda de python y ya sé que la respuesta a la pregunta es: aprende los dos, pero cómo el tiempo es limitado habrá que dividir los esfuerzos o priorizarlos, ¿cómo lo véis?

Una parte de la charlas posteriores entre cervezas y pizza que me encantó era lo que comentaba uno de los asistentes: «Yo no quiero a los desarrolladores anden tocando en mis servidores», pero estuve pensando y creo que no sólo es la idea correcta sino que habría que ampliarla «No quiero a nadie rondando en mis servidores, ya sean de los equipos de desarrollo u operaciones y menos aún alguien de fuera», si hay que hacer retoques en los entornos de producción estos deberían hacerse siempre desde las herramientas de gestión de configuración y cambios de tus entornos y a través de unos workflows definidos y probados ampliamente, nunca tener que realizar acciones directas sobre las máquinas. Otro de los comentarios fue que «los equipos de desarrollo quieren estar modificando continuamente lo subido y a veces van demasiado rápido», y creo que aquí está otro de los puntos clave del cambio que estamos intentando llevar a cabo con mentalidades ágiles y devops: nuestro objetivo debe ser el de habilitar el cambio y potenciarlo, eso sí poniendo los mecanismos necesarios para asegurar el éxito: integración continua, desarrollo guiado por pruebas, automatización del despliegue, paso rápido entre entornos de pre y pro o despliegue continuo son los habilitadores para ello y tenemos que encontrar la mejor manera de integrarlos en nuestros ciclos para ganar en agilidad.

Y en el terreno herramientas, no puedo dejar de comentar una de mis favoritas en los últimos días es Vagrant, si no la habéis probado no tardéis mucho en hacerlo. Hace tiempo que estaba buscando un sistema que me permitiera gestionar facilmente máquinas virtuales en mi portátil de forma que si necesito probar algo en una Debian, Redhat o lo que sea pueda levantarla rapidamente tener un entorno configurado rápidamente y hacer la prueba y destruir la máquina. Para ello Vagrant es ideal, es un conjunto de scripts en Ruby, elo aquí de nuevo, que usan Virtualbox por debajo normalmente en modo no gráfico y que te permite levantar una serie de plantillas de máquinas virtuales (os recomiendo vagrantbox.es para descargarlas), además tiene integración con puppet y chef de forma que puedes indicarle que ejecute un manifiesto al arrancar y que te deje el entorno ya configurado según unos parámetros. Impresionantes las posibilidades también para los equipos de desarrollo a los que se puede pasar un entorno similar al de producción y ellos pueden ejecutarlo en sus máquinas para desarrollar, hacer pruebas, etc… Vamos, no hay día que no me levante al ritmo de un comandazo «vagrant up»!

Por último voy a dejar a continuación tres juegos de transparencias que me han gustado bastante en los últimos días y que creo que son bastante explicativas de todo esto al rededor del movimiento Devops:

Y lo más importante, si has llegado hasta aquí por favor deja tu comentario en la entrada para que generemos algo de debate al rededor del tema. Muchas gracias a todos. 😀

En el openstack EMEA day

Son las 6:30 de la mañana y el despertador ya está sonando, por la ventana hace ya tiempo que empezó a entrar la luz del sol y el OpenStack EMEA day me está esperando en Londres. Antes aún me quedaba pedalear hasta la estación de tren de Cambrdige, dejar mi bici apelotonada junto a la de otros cientos de commuters que para su desgracia hacen esto a diario, tomar el tren hasta King Cross y luego el metro hasta London Bridge. Luego descubrí que mi trayecto que parecía cansado no era nada en comparación con otra gente que vino de España en avión o incluso en tren de París, pero a mí me había confirmado la idea que ya me iba haciendo que Londres no está tan cerca de Cambridge cómo lo estaba Madrid de Getafe 😀 .

La ubicación del evento, aka la «venue» para los angloparlanchines, era bastante chula y la sala estaba abarrotada cuando llegué, tarde a pesar de mi madrugón. Me perdí la primera charla introductoria, pero no me dolió mucho porque había estado en alguna anteriormente dónde se había visto lo básico de la tecnología.

A modo de introducción y para los que no lo conozcáis openstack, se trata de un proyecto que persigue la creación de una implementación libre y altamente escalable de «la nube», principalmente en los temas relacionados con las infraestructuras cómo servicio (IaaS). El proyecto fue iniciado por RackSpace y la NASA pero últimamente está teniendo una gran aceptación y un gran número de empresas cómo Citrix o Ubuntu están participando activamente en el proyecto. OpenStack se divide en varios subproyectos que intentan abarcar los diferentes elementos necesarios para la construcción de estas nubes cómo son la provisión de máquinas virtuales, de almacenamiento o el servicio de imágenes junto entre muchos otros una consola de gestión web. Uno de los puntos fuertes de openstack es su API, o sus APIs ya que tb tiene una versión compatible con Amazon, que nos van a permitir relacionarnos de forma altamente flexible con nuestra nube.

Después de la introducción, las siguientes charlas cubrieron temas variados como por ejemplo cómo están contribuyendo las distribuciones al desarrollo y la integración de Nova con la intervención de la gente de Citrix (Xen Server), Ubuntu y los compatriotas de StackOps a los que fue un gustazo poder saludar por tierras inglesas y que a día de hoy han desarrollado una de las distribuciones de OpenStack más interesantes sobretodo si no quieres complicarte la vida en la instalación. La verdad fue una alegría ver que Ubuntu ya ha incorporado en varias de sus últimas versiones paquetes oficiales de OpenStack y también cómo Citrix también apuesta por openstack para su implementación de nubes, y en gran parte el exito es debido a la independencia de openstack del hypervisor elegido permitiendo así elegir el que más se ajuste a tus necesidades.

También fue curioso las varias referencias que hubo a temas cómo devops o al uso que hacen internamente para el despliegue de múltiples nodos mediante puppet o chef distintas empresas que están trabajando en la implementación de openstack. En Andago llevamos ya bastante tiempo siguiendo la pista de OpenStack y está en el roadmap migrar nuestra nuble interna de computación de un desarrollo previo a medida de IaaS sobre Xen a OpenStack sobre KVM, pero esperamos poder tener el primer piloto disponible en breve.

La charla de seguridad en la nube entre otros nos recordó lo importante que es en los casos que estas ofreciendo servicios de computación a clientes externos mediante virtualización la relación que existe entre el servidor anfritión físico y las máquinas virtuales. Hay bastantes iniciativas en este aspecto tanto desde fabricantes de hardware cómo intel a otras basadas en software cómo el uso de SE-Linux para conseguir una independencia total del host anfitrión y sus ahijadas virtuales. Por cierto, mencionaron un tipo de ataque que no conocía llamadobluepill.

Otro de los aspectos importantes que se comentaron durante la sesión fue cómo poder particpar en la comunidad de openstack y cómo se está organizando el desarrollo que muestran una comunidad robusta y sana y con una de las mayores proyecciones dentro del espectro del software libre. Por ahora y hasta no consiga elevar algo más mi nivel de programación en python mi granito de arena en el proyecto ha sido la traducción de gran parte de las cadenas de texto de Nova del inglés al español, aunque aún quedan unas cuantas nuevas que van aparecinedo cada día y os animo a contribuir.

Mudanza virtual de servicios a la devops

Hace un par de meses al llegar a UK y aprovechando que Amazon tiene envío a domicilio gratuito para algunos libros, aproveché para pillar un par de libros: «Web Operations» y «Continous Delivery«. Con todo el lío no había tenido tiempo para empezarlos, pero se me ocurrió comentar un día en twitter la pena que me daba tenerlos ahí sin leer cuando @trek1s me recomendó que leyera cuanto antes el de Web operations porque le había gustado bastante, así que me puse a la tarea y lo llevo bastante avanzado (prometo poner una reseña en el blog porque la verdad el libro la amerita).

Web Operations

En uno de los capítulos dedicado a la infraestructura como código nos cuenta cómo el reconstruir todos los servicios de una empresa ante una catástrofe debería ser tan sencillo como provisionar infraestructura en un proveedor de cloud no afectado por la catástrofe, aplicar sobre ella nuestra herramienta de gestión de la configuración para configurar todo lo necesario y rescatar del backup, aquel que estaba offsite y no fue afectado por la catástrofe, la versión más actualizada para los datos. Y si uno lo piensa bien, el tema debería ser así y nuestros esfuerzos como sysadmins deben de estar dirigidos en gran parte a objetivos tan loables cómo salvar a la empresa de la quiebra ante una catástrofe.

Cuando empezamos a implementar la plataforma de salud de Andago, uno de los primeros objetivos que me marqué y que hace tiempo llevaba intentando poner en práctica fue el de tener una buena política de la gestión de la configuración y del despliegue de las aplicaciones. En algunos de los proyectos internos ya se llevaba tiempo trabajando en esto pero normalmente en los proyectos y servicios de cliente no se había podido avanzar tanto como se debería, así que como siempre decimos una oportunidad para empezar de cero es una oportunidad para no volver a cometer los mismos errores.

Una vez definida la política, siempre sujeta a cambios y mejoras, nos pusimos a implementarla. Abriendo nuestro maletín de herramientas devops (marca Acme) decidimos utilizar subversion, puppet y los servicios de Amazon EC2. No voy a ahondar en cómo fue la implementación pero un punto que sí me ha resultado muy interesante ha sido el cambio en el modo de trabajar que hemos tenido que sufrir como equipo. Hace tiempo que venimos practicando Scrum como metodología ágil para los proyectos nuevos a desarrollar pero esta vez le sumamos el cambio que supone trabajar con la infraestructura como código. El trabajo habitual de un proyecto en la parte de configurar servicios en Linux suele ser de trastear mucho en la consola e ir documentando en nuestro wiki de referencia. En este caso el tema cambió y nos dedicamos a escribir el código de Puppet que se encargaría luego de hacer la configuración y además, con unos buenos comentarios, cubre una parte importante de la documentación del servicio.

Por otro lado sumamos que estamos trabajando de forma distribuida tanto en ubicaciones como en horarios, yo desde Reino Unido y luego equipos en España y Panama, el reto era bastante interesante. Lo bueno es que en lugar de estar toqueteando cada uno servidores en remoto lo que estabamos produciendo es código que se iba almacenando en nuestro subversion y que luego puede ser testeado, aplicado y pulido múltiples veces hasta llegar al punto deseado. A través de rsync empujábamos el código a instancias de Amazon y comprobando que todo funcionaba bien. Curiosas las sesiones de despliegue en la que todos en remoto estábamos conectados por ssh al mismo screen y viendo cómo desplegaba nuestra criatura mientras comentábamos la jugada por skype.

El siguiente reto será ir por la integración continua y las pruebas automáticas, es decir todas aquellas cosas que siempre les estamos pidiendo a los desarrolladores pero que luego nosotros no estábamos aplicando a nuestro trabajo.

Por ahora no hemos sufrido ninguna catástrofe para comprobar lo narrado por el libro pero sí hubo un punto de prueba muy interesante. El equipo de negocio decidió que, debido a que nuestro público objetivo en gran medida estaría en Estados Unidos, el despliegue que inicialmente se había realizado en la zona de Irlanda habría que migrarlo a la zona de la costa este de gringolandia. Ciertamente aún no estábamos en producción y seguíamos en las fases tempranas del proyecto y eso facilita las cosas, pero la transición fue bastante parecido a lo descrito al inicio lo cuál no hace más que reafirmar que vamos avanzando por el camino correcto.

Aplicando devops en una empresa TIC

No me había percatado que no había puesto en el blog las transparencias de la charla «Aplicando devops en una empresa TIC» que dí en Madriddevops en las oficinas de Tuenti en Mayo. Aquí os las dejo:

Presentar en madriddevops era una espinita que tenía clavada ya que es uno de los grupos que más he disfrutado los últimos meses que estuve por Madrid. Las charlas suelen tener un gran nivel en los asistentes con preguntas y comentarios de un altisimo nivel, que incluso se ve incrementado en la tertulia posterior frente a las cañas, dicho sea de paso otro gran acierto del evento.

En la charla conté un poco cómo intentamos aplicar técncias de devops en Andago y entre otras cosas las dificultades para conseguirlo, lo que nos ha aportado y cómo algunas han sido exitosas y otras no tanto, pero que en general son una serie de prácticas revolucionarias en la forma de llevar a cabo nuestro trabajo y que lo han mejorado en gran medida.

Ahora estoy deseando que se celebre la próxima edición de Londondevops, uno de los grupos más activos en este sentido, y ver que se cuece por esta isla, a ver si con eso me quito la morriña de los grandes momentos pasados en madriddevops. Si estáis por Madrid os aconsejo no perder la oportunidad de participar en la próxima charla.

Experiencias en la administración de sistemas con Software Libre

Este es el título, aunque no el orginial que más bien era Experiencias del Software Libre en las empresas TIC, de la charla que dí el pasado Viernes en el curso de Arquitectura de servidores con Software Libre que está realizando LibreSoft y la Universidad Rey Juan Carlos en el centro Madrid On Rails y en el que Andago participa cómo colaborador. En un principio pensé que no podría dar la charla al estar en Reino Unido pero al final conseguimos cuadrar las fechas con los días que ibamos a estar por España arreglando papeles. El curso que ha montado la gente de LibreSoft me parece superinteresante, de hecho tuvimos suerte de pillar una plaza para uno de los compañeros del departamento de IT, y es el tipo de formación del que siempre me he quejado que no ofrezca la Universidad cómo parte de su temario habitual. Esperemos que se les reconozca el éxito y puedan repetirlo en siguientes ediciones.

El caso es que cuando me puse a pensar sobre qué podía contar sobre el tema me llegaron muchísimas ideas de golpe y no sabía muy bien cuales serían más interesantes y cuales descartar. Entre ellas había muchísimas experiencias e historietas de distinto ambito, desde cuando empezaba a utilizar mis primeras distribuciones de Linux en casa, las cosas aprendidas en la Universidad y en LinuxAlbacete, cómo montamos la infraestructura de un pequeño ISP en mi primer trabajo y luego todos los proyectos, metodologías, infraestructuras y lecciones que he ido adquiriendo durante los últimos años en mis distintos puestos dentro de Andago. Así que al final intenté incluir un poquito de cada cosa con la idea de dar muchas ideas y conceptos, sin profundizar en el cómo (HOWTO), de forma que sirvieran de puntero para que la gente del curso, en caso de que le resultaran interesantes o de utilidad, pudieran investigar un poco más.

A continuación os dejo las transparencias por si os interesa echar un vistazo:

La audiencia era gente con experiencia en la administración de sistemas así que intenté profundizar en los temas menos comunes o con los que pudieran estar menos familiarizados. Finalmente me pasé un cuarto de hora de la hora y media que tenía asignada, cosa que ya me estaba temiendo cuando terminé de preparar la charla, pero espero no haber aburrido demasiado a nadie. Yo cómo siempre disfruté cómo un enano contando cosas e intentando contestar las preguntas que me fueron hiciendo.

También había pensado en incluir un resumen de todo lo que conté en la charla en este post, pero pensándolo mejor voy a ver si saco tiempo y hago una serie de posts sobre ello porque hay demasiada chicha para un sólo día.

Gestionando servidores con Puppet

Aquí os dejo las transparencias de la charla «Gestionando servidores con Puppet» que impartí en los cursos del GUL de la Universidad Carlos III de Madrid el pasado 09 de Noviembre:

Las transparencias se liberan cómo Creative Commons Reconocimiento 2.5 de España respetando la licencia de las imágenes utilizadas cómo fondo, podéis ver un listado de los autores y la licencia de sus obras al final de las transparencias.

La charla se dividió principalmente en 3 partes: describir el problema que encaramos cuando intentamos administrar el creciente número de servidores que requiere cualquier entidad que consuma servicios de IT, algunas de las posibles soluciones que podemos encontrar así cómo qué características debe tener una solución a este problema y por último cómo Puppet puede ser esta solución y una pequeña introducción a cómo funciona.

Como siempre el auditorio estuvo bastante participativo y las preguntas hicieron más amena la exposición. Como siempre la parte de la demo siempre es la más complicada, de nuevo el bendito Android y la conexión 3G me facilitaron las cosas, pero sirvió para hacer una demostración de los conceptos mostrados en la parte teórica. Muchas gracias a todos los que os acercasteis a la charla y gracias por los comentarios positivos sobre la misma que hicisteis en el blog, así da gusto prepararse cualquier tema.

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.

Amazon lanza un servicio de supercomputación mediante GPUs

Parece que en los laboratorios de Amazon no paran ni un sólo momento y aplican constantemente el principio de mejora continua a sus servicios. Esta mañana nos hemos despertado con un sorprendente anuncio: podremos disponer de instancias de Amazon Web Services orientadas a montar clusters de computación mediante GPUs, es decir utilizando la potencia de calculo de la tarjeta gráfica. Un paso realmente interesante ya que últimamente la capacidad de cálculo de estas tarjetas supera a la que nos provee la CPU del sistema.

Las instancias de Amazon Cluster GPU disponen de:

22 Gb de memoria
33,5 unidades de computación EC2 (2 x Intel Xeon X5570, quad-core)
2 NVIDIA Tesla M2050

Con esta configuración podemos alcanzar hasta un trillón de operaciones en coma flotante de doble precisión por segundo. La idea es muy interesante y se une a la oferta que ya disponía Amazon de instancias orientadas a HPC (Computación de altas prestaciones) y que dispara las opciones cuando planteamos si nos merece la pena montar un cluster de computación en nuestro CPD o usar uno en la nube bajo demanda. A día de hoy el coste por hora de la instancia, sin contar otros costes indirectos cómo Ips fijas, almacenamiento persistente y demás, es de 2,10$ y el servicio cómo en otras ocasiones sólo está disponible inicialmente si usamos la zona de EEUU, aunque lo estará proximamente en todas las demás.