• Del autor
  • Principios y algoritmos de concurrencia

Ricardo Galli, de software

~ De software libre, internet, legales

Ricardo Galli, de software

Archivos de etiqueta: ec2

Amazon EC2: actualizar Ubuntu 10.04 a 12.04, y a 14.04

28 lunes Jul 2014

Posted by gallir in menéame, trucos

≈ Comentarios desactivados en Amazon EC2: actualizar Ubuntu 10.04 a 12.04, y a 14.04

Etiquetas

ec2, lts, ubuntu, upgrade

Este es un apunte rápido y corto ya que a algunos les vendrá bien. Estoy preparando la migración del servidor principal (el que hace de control, repositorio de software e imágenes) de Menéame. Es una instancia EBS (con dos volúmenes adicionales) con Ubuntu 10.04 y ya toca migrar a la 12.04 o 14.04 por su antigüedad y porque se quedará sin soporte.

En general no tuve problemas, pero hay que tener un poco de cuidado cuando se migra de 12.04 a 14.04. Los pasos a hacer desde la consola web son los siguientes (no hace falta hacer nada con comandos):

  1. Crear un AMI del servidor a actualizar: esto generará una imagen arrancable idéntica al servidor, hay que seleccionar que cree también la imagen para los otros volúmenes montados.
  2. Arrancar una nueva instancia con ese AMI creado. Esta instancia debe ser idéntica a la original. Ten cuidado de deshabilitar los procesos que puedan interferir con la otra, por ejemplo los que tengan en cron. Verás que creó un AMI y los snapshots correspondientes a cada volumen.
  3. Ejecutar do-release-upgrade -d para actualizar a 12.04. Esto pasará a la siguiente versión LTS. Como comencé con 10.04 se actualiza a 12.04. Es un proceso que tarda pocos minutos y no me dio ningún problema. Luego hay que hacerlo nuevamente para actualizar a la versión 14.04, antes es mejor reiniciarlo para estar seguro que todo funciona correctamente (mira los mensajes de arranque con el dmesg).
  4. Ejecutar de nuevo do-release-upgrade -d para actualizar a 14.04. Como el anterior, pero si no vas con cuidado, luego no arrancará porque no encontrará los dispositivos EBS. El problema es sencillo, en la 14.04 se renombran de dispositivos, por ejemplo, el /dev/sda1 se renombra a /dev/vxda1, el /dev/sdc a /dev/vxdc, etc. Antes de reiniciar con la versión 14.04 debes cambiar el /etc/fstab para indicar esos nuevos nombres. Si te olvidas -como yo- no hay problemas, más abajo te explico cómo arreglarlo rápidamente si la instancia no te arranca.
  5. Ya está, es relativamente sencillo. Ahora debes verificar que las configuraciones te funcionan, reinstalar los módulos que han instalado con herramientas como el pip (Python), o pecl (PHP). Verifica también la configuración del PHP (si lo usas), ya que cambió la estructura de directorios en /etc/php5. Te aconsejo crear otro AMI de este nuevo servidor y probar que arranque correctamente.

Cómo reparar el /etc/fstab (o cualquier otra configuración que impide arrancar una instancia)

Si en el paso #4 te olvidaste de cambiar los nombres de los dispositivos, o lo hiciste pero te equivocaste (o falla cualquier otro fichero), la instancia no arrancará, pero es relativamente sencillo de arreglarlo:

  1. Detén el servidor que no arranca (Stop desde la consola web).
  2. Arranca otra instancia (si no tienes ninguna en marcha) con una imagen que funcione, incluso con una Ubuntu oficial. Cualquiera sirve.
  3. En la ventana de Volumes haz un deattach del volumen raíz de ese disco (no te olvides de apuntar el nombre de /dev con el que estaba enlazado, habitualmente /dev/sda1 o /dev/sda).
  4. Haz un attach de ese dispositivo a la otra instancia de trabajo, te sugerirá nombres, usa alguno que no tengas en esa instancia, por ejemplo /dev/sdc.
  5. Monta el dispositivo en la instancia, por ejemplo: mkdir /work; mount /dev/sdc /work (ojo, si estás trabajando en una Ubuntu 14.04 será mount /dev/vxdc).
  6. Ahora puedes modificar el /work/etc/fstab (o el fichero que tengas que reparar).
  7. Desmonta el dispositivo (umount /work) y el deattach del volumen a esa instancia.
  8. Ya puedes hacer el attach del mismo volumen a la instancia que habías detenido y hacer el start.

 

Las instancias m3 de EC2 no son lo que prometen

13 jueves Mar 2014

Posted by gallir in menéame

≈ 4 comentarios

Etiquetas

amazon, ec2, instancias m3

Actualización: sigo estudiando el tema porque es muy raro, si pongo un proceso en bucle no consume el 100% de CPU, sino el 50%. Parece que hay un problema de medición (tanto localmente como lo que mide Amazon CloudWatch). Si descubro algo más lo pondré.

En enero de este año Amazon habilitó el uso general de sus nuevas instancias «m3» (las originales son m1). Además del almacenamiento SSD, estas instancias tienen -según ellos- más CPU (3 ECU vs 2 ECU de las m1). Para los servidores web de Menéame usamos instancias m1.medium, pero las m3.medium parecían más adecuadas, nos podíamos ahorrar alrededor del 50% del coste. No las cambié inmediatamente porque el espacio disponible en /mnt en las m3 es muy pequeño (sólo 4GB) y allí es donde generábamos los logs del NGInx.

Pero estos días Amazon también empezó a ofrecer almacenar los logs del balanceador de carga (ELB) en S3, por lo que habilté estos y deshabilité los generados por NGInx en las instancias. Así, ya no hacían faltan varias decenas de GB por cada 24 horas de funcionamiento de cada instancia y podíamos pasar a usar las instancias m3 sin ningún otro cambio. Lo hice a partir de las 12 de la noche, tal como es visible en el siguiente gráfico.

Sigue leyendo →

Preguntas y 10 puntos claves de Amazon EC2

19 viernes Ago 2011

Posted by gallir in internet, trucos

≈ 15 comentarios

Etiquetas

amazon, aws, claves, ec2, trucos

Recibo muchos emails con consultas por tema de Amazon AWS, cuando son breves y concretas las contesto, cuando no, que paguen una consultoría. Una cosa es contar las experiencias para todos, otra muy distinta solucionar gratis  los problemas de una empresa con la que no tengo relación.Hace unas horas recibí uno largo, pero como tiene preguntas interesantes lo contesto, pero para todo el mundo 😉

Sigue leyendo →

Dos podcasts dos: Amazon EC2 y #nolesvotes

17 jueves Mar 2011

Posted by gallir in internet

≈ 7 comentarios

Etiquetas

#nolesvotes, amazon aws, ec2, podcast

Ultimamente estoy aprovechando mis virtudes, entre ellas mi voz, mi tono pausado, mi atractivo acento.

Dabo publicó hoy «“Kernel Panic” especial Amazon EC2 con Ricardo Galli (Menéame, UIB) y Raúl Naveiras», un podcast de 1:47 horas dedicado exclusivamente a comentar detalles de los servicios de Amazon AWS. Propuse a David hacer este podcast debido a la cantidad de consultas sobre temas básicos de Amazon que recibía casi cada día. Así que lo hicimos conjuntamente con Raún Naveiras. Damos un repaso introductorio a casi todos los servicios, comento costes reales y algunas limitaciones que tuvimos con Menéame.

Por otro lado, en Luz de Gas me hicieron hoy una larga entrevista sobre la ley Sinde y #nolesvotes, el audio está disponible en el blog, también en ivoox.

Cuando el problema del hardware se convierte en sólo de software

12 miércoles May 2010

Posted by gallir in desarrollo, internet, menéame

≈ 23 comentarios

Etiquetas

amazon, aws, ec2, menéame

Disclaimer: No pensaba escribir este apunte porque me parece que es publicidad gratuita a Amazon (y sus servicios AWS), que ya es una empresa de las gordas y dominantes en el mercado… y no me regalaron, ni me regalarán, ni una triste pegatina. Pero lo escribo para compartir experiencia, y que conste en acta que no recibiremos ni unas gracias por este apunte.

Hace un tiempo escribí cómo montamos Menéame a Amazon AWS, y cómo decidimos cambiar de Apache+lighttpd a NGinx, ahora llevamos casi cinco meses de funcionamiento en Amazon AWS y la experiencia no podría haber sido más satisfactoria (aunque con pequeños problemas, relatados al final).

Ejemplos de cambios en servidores

Creo que lo últimos cambios que hicimos son ejemplos claros de las ventajas de no tener que lidiar con hardware y limitarnos a solucionar problemas de software (que siempre tiene solución, si sabes programar).

Nuestra intención era migrar los servidores a Ubuntu Lucid en cuando esta saliese por tres razones fundamentales: es LTS (soporte a largo plazo), el PHP 5.3 que trae soporta conexiones persistentes a MySQL usando las nuevas librerías mysqli (que son las que usamos, más eficientes y elegantes que la anterior) y el arranque es mucho más rápido (importante para las instancias web que se crean dinámicamente según la carga –con el AutoScaler–).

El primer paso fue migrar las instancias webs, para ello tuve que arrancar un instancia con la nueva imagen (AMI) oficial de Ubuntu Lucid para Amazon, instalar los paquetes necesarios (básicamente NGInx y php5), configurarlas (fundamentalmente el NFS y el servicio SMTP), generar una nueva AMI y cambiar la configuración del AutroScaler (dos líneas de comandos). Todo eso me llevó unos dos horas de trabajo y ya teníamos la Lucid con 0 segundos de interrupción (diría que con 0 conexiones fallidas)… a un coste de 0.18€ por las dos horas de instancia adicionales.

El segundo paso fue más gordo, migrar el servidor secundario (aws1) que hace de slave del MySQL (para backups e indexación del Sphinx), de buscador (el Sphynx), DNS secundario y backups diarios a S3. Esta instancia estaba antes como «normal», es decir sin almacenamiento persistente (EBS, o Elastic Block Storage), la idea era ponerla con EBS dado la complejidad de los servicios que presta. Pues la sorpresa fue que Canonical ya genera imágenes oficiales de Ubuntu preparadas para EBS (antes era un proceso manual un poco tedioso, es espectacular el servicio de Canonical sobre Amazon EC2 y la smejoras que introducen).

Este cambio también llevó poco tiempo, menos de dos horas para preparar todo (lo que más tiempo llevó fue la preparación del slave de MySql) y un par de horas más de pruebas. Cuando estuvo preparada lo único que hubo que hacer fue cambiar la IP fija (Elastic IP) para la nueva instancia, et voilà. Cero segundos de interrupción, a un coste de unos 0.36€.

Hace sólo uno días me decidí a optimizar la gestión de cache de imágenes (miniaturas y avatares). Estas se guardan en S3, pero como el coste de conexión es demasiado elevado para ficheros pequeños no tiene sentido –y es extremadamente caro– servirlas desde S3, así que se guarda una copia cache (que se genera/regenera automáticamente a partir de los originales en S3) en un disco montado por NFS. El servidor de NFS lo hacía la misma instancia que el servidor central de base de datos (aws0), la idea era moverlo a aws1 y así descargar el tráfico de red para ganar unos microsegundos con las conexiones de mysql y distribuir mejor el NFS del código fuente PHP (que sigue en aws0) con las imágenes estáticas (que además pueden tener más tiempo de cache NFS, configurable con los parámetros acregmin, aregmax, acdirmin, acdirmax o actimeo).

Lo único que hubo que hacer es generar una nueva AMI para las instancias web con el nuevo punto de montaje (es menor de media hora de trabajo, a 0.09€ la hora o fracción), forzar al arranque con las nuevas instancias y cuando todas ya eran la nueva cambiar un enlace simbólico en aws0 para apuntar el cache al nuevo directorio. Et voilà. Funciona así ahora, ganamos unos pocos microsegundos, con cero segundos de interrupción.

Situación general

Aquí tenéis la carga de aws0 (servidor de base de datos). Veréis que la carga es baja, muy estable y predecible.

Carga 24hs de aws0

Esta es la carga de aws1, los picos son de la indexación del Sphinx para las búsquedas (casi 7 millones de comentarios, casi 1 millón de enlaces y más de 100.000 notas):

Carga aws1

Carga 24hs de aws1

El siguiente es el estado de las instancias a estas horas (0 hs del miércoles). Se puede ver las dos instancias EBS (aws0 la large, aws1 la small) y las cuatro instancias de servidores web en marcha.

Instancias EC2

Y este es el gráfico de carga de un día de una instancia web.

Carga 24hs de una instancia web

Nota: me hice un pequeño script para poder monitorizar al minuto el estado de las instancias webs desde mi teléfono, es públicamente accesible: m.meneame.net/ec2.php

Rendimiento general

Una de las grandes dudas (y pegas) que teníamos para migrar a Amazon es que al estar situado en Dublin aumenta la ditancia, el número de saltos por routers y quizás las latencias introducidas por las redes virtuales, firewalls y balanceadores de carga. De hecho sólo el ping hacia una instancia casi triplica lo que teníamos en España (Ferca, luego Acens), pasó de 20 y pico milisegundos a unos 60 a EC2 Dublin.

Sin embargo creo que nadie se quejará de la velocidad de acceso y visualización de Menéame.

Tiene mucho que ver las optimizaciones que hemos hecho, como la separación de imágenes estáticas en dominio independiente, mejoras en el código, en las consultas a la base de datos, ajuste del NGInx, php-fastcgi, compresión del HTML, y cache de PHP (XCache). Pero también ayuda a que los balanceadores de carga (usan varios para cada «dominio») de Amazon funcionan muy bien, tienen conexiones persistentes y unos firewall muy bien configurados que no sólo lo hacen ir rápido, sino que es de un rendimiento predecible que evita que haya conexiones más lentas que son las que más dan la impresión de «lentitud».

En este sentido estamos también muy satisfechos. Sí, tienes que ir con cuidado porque no tiene sentido sobredimensionar el «hardware virtual» –además creo que no se ganaría casi nada– para solventar los problemas del software o mal diseño de base de datos, pero una vez hallados y solucionados los pocos cuellos de botella, funciona todo como una seda.

Servicios y costes

Cuando estábamos en Ferca/Acens teníamos dos servidores, uno muy potente (2 Quad Core) y otro menos (Duo). Teníamos un muy buen precio, unos 700€/mes todo incluido. Pero teníamos problemas muy difíciles de solucionar:

  • Aunque íbamos muy sobrados, en horas picos o eventos excepcionales el Apache nos saturaba ambas máquinas, como en las finales de la Copa de Europa de fútbol que tuvimos que alquilar temporalmente servidores en Amazon EC2, aunque con latencias muy altas a la base de datos –estaba replicada en Amazon, pero las actualziaciones iban al central en Ferca/Acens–.
  • No teníamos servicio de «backups externos» y cifrados.
  • Poner un balanceador de carga dedicado nos hubiese costado mucho dinero.
  • Teníamos problemas en poner más servidores conectados a la misma red privada (por que no había espacio en el rack, porque había que ir y poner un switch específico, porque obligaba a paradas… etc.).
  • Cada vez que necesitábamos algo puntual era un largo proceso de conversaciones y negociaciones, a tal punto que muchas de las cosas eran imposibles de contratar porque se escapaba a lo que considerábamos un presupuesto razonable.
  • Problemas constantes de «mala configuración» del firewall del CPD que nos bloqueaba conexiones (suponemos porque el número de conexiones era más elevada que la media considerada «normal», aunque nunca lo supimos bien del todo).

Al momento que migramos a Amazon todos esos problemas se solucionaron:

  • Tenemos S3 para copias, backups y almacenamiento permanente.
  • Tenemos balanceador de carga de muy buena calidad, incluso configurable con «session stickiness».
  • Podemos habilitar un CDN con los mismos costes que las conexiones S3 (no la usamos).
  • Podemos escalar automáticamente para dar buen servicio sin malgastar el dinero.
  • Disponemos de los servidores que nos hacen falta en no más de un par de minutos, a muy bajo coste.
  • Sistemas de discos (EBS) de muy alta fiabilidad.
  • Control de las IPs (Elastic IPs) y a qué servidor le asignas, puedes cambiarla en cualquier momento, e incluso puedes solicitar la resolución DNS inversa para cada una de ellas.
  • Sistema de seguridad/firewall muy potente, seguro y casi transparente de usar (por ejemplo, las instancias que están en un mismo grupo automáticamente tienen conectividad entre ellas). Al mismo tiempo todas tus instancias están aisladas del resto de instancias.
  • Absolutamente todo es controlable con software (la consola web para la mayoría, para cosas muy específicas las líneas de comandos, el API disponible en varios lenguajes para los scripts de monitorización y control).
  • No tenemos que negociar nada con nadie, todos los servicios –para todo el mundo– están bien claros y especificados, y los precios no son negociables, por nadie.
  • En todo este tiempo no tuvimos ninguna incidencia (salvo problemas de conectividad Internet esporádicos con algunas regiones o ISPs, pero esto pasa con cualquier hosting).

Todos estos servicios disponibles, con la flexibilidad de usarlos como mejor te parezca nos permitió implementar nuevas funcionalidades en Menéame que antes se nos hacían cuesta arriba por la necesidad de tener más hardware [infrautilizado]:

  1. Buscador extendido a comentarios y notas (algo que hace tiempo pedían los usuarios).
  2. Almacenamiento de imágenes y avatares en S3 que generación automática de cache en nuestros discos, los que nos hizo olvidar del problema de almacenar y hacer backups de ficheros.
  3. Cambios en la infraestructura (como de Apache a lighttpd, luego a NGInx con fastcgi, versiones de Ubuntu, etc.) y programas o configuración sin tener que interrumpir el servicio: se hace de forma paralela y luego se hace el switch.
  4. Compramos tranquilidad: duermo mucho más tranquilo, y aunque España llegue a la final del mundial no tendré que preocuparme de buscar estresado y bajo presión una solución a la sobrecarga de la hora posterior del partido.

Todo el que llegó hasta aquí seguramente se pregunta, ¿cuánto nos cuesta todo este tinglado adicional? Aquí tenéis la «factura» del mes de abril, en dólares, haced la conversión a euros 🙂 [1]

Pagos Amazon abril 2010

Por eso suelo decir, ¿qué hacéis todavía lidiando con hardware y negociando interminablemente para tener un servicio de backup o de balanceo de carga?

Nota: Esto funciona porque Amazon AWS está muy bien diseñado y su servicio es de calidad constante y predecible. Sé que hay varios más, pero no conozco cómo funcionan.

Los problemas

Por supuesto no todos fueron ventajas, tuvimos algunos problemas:

  1. La infraestructura del balanceador de carga es sofisticada, no es sólo un «cacharro» con una IP, son balanceadores distribuidos y se selecciona el mejor dependiendo desde la zona de conexión y el estado de la infraestructura de Amazon. Eso hace que cuando asignas un balanceador no te dan una dirección IP, sino un hostname que debes usarlo como CNAME. Eso impide que puedas usar una zona de primer nivel –el estándar de DNS no lo admite–por ello tuvimos que migrar el web de meneame.net a http://www.meneame.net (con la consiguiente penalización que sufrimos de Google, una caída de visitas –menos del 10% de visitas vienen de Google por búsquedas que no sean «meneame»–, hasta en el PageRank –creo que bajó hasta 6, no sé cómo está ahora–, supongo que con el tiempo y las redirecciones permanentes se recuperará, afortunadamente no nos afectó tanto ya que creo nunca superamos el 12-15% de visitas desde Google).
  2. Como Amazon sufrió abusos de spammers que alquilaban instancias sólo para envíos masivos de emails. La misma Amazon dió de alta todas sus direcciones IP en las organizaciones de listas negras e impedía enviar más de unos pocos correos desde sus instancias. Aunque puedes solicitar la apertura, seguían apareciendo las IPs en Spamhaus, lo que nos impidió enviar correos directamente. Ahora creo que ya lo han cambiado [2] (incluso ya resuelven la inversa de Elastic IP al dominio quele indiques, porbado por ejemplo la inversa de 79.125.22.108). Nosotros hemos tenido que hacerlo vía SMTPAuth.com que funciona muy bien, por lo que todavía no hemos pensado en hacerlo desde nuestros servidores (también tenemos cuenta en SendGrid.com, hablan muy bien de ellos y ofrecen hasta gráficas y estadísticas de quiénes leen los correos o los clics de los receptores).
  3. Desde el servidor web detrás del balanceador no son visibles directamente las IP de los navegadores (es crítico para el control de abusos del Menéame), sino a través de la cabecera HTTP X-Forwarded-For. Afortunadamente en Menéame ya hacíamos control de proxies para permitir votos desde ordenadores detrás de los proxies transparentes de Telefónica y de los teléfonos con conexión IP que salen por proxies (como todos los de Vodafone). Así que sólo usamos la misma función, pero simplificada para que sea más rápida:
  4. function check_ip_behind_load_balancer() {
        // It's similar to behind_proxy but faster and only takes in account
        // the last IP in the list.
        // Used to get the real IP behind a load balancer like Amazon ELB
        // WARN: does not check for valid IP, it must be a trusted proxy/load balancer
        if ($_SERVER["HTTP_X_FORWARDED_FOR"]) {
            $ips = preg_split('/[, ]/', $_SERVER["HTTP_X_FORWARDED_FOR"],
                                             -1, PREG_SPLIT_NO_EMPTY);
            $ip = array_pop($ips);
            if ($ip) return $ip;
        }
        return $_SERVER["REMOTE_ADDR"];
    }
    
  5. En el caso de servidores web seguros (SSL) el problema anterior es más difícil de solucionar. Como la conexión es cifrada el balanceador no puede agregar cabeceras HTTP, por lo que es imposible averiguar la IP desde el servidor. Aquí hay tres opciones: 1) no preocuparte de la IP, 2) dejar el servidor seguro fuera del balanceador, 3) buscar otro método. Como en Menéame se necesita la IP para control y soy un purista de arquitecturas –todos o ninguno– me decidí por la tercera. Cuando se necesita pasar por conexión segura se hace un formulario desde el servidor normal donde se incluye la IP de origen más un hash para controlar que no se manipula. Así el servidor seguro siempre recibe la IP –verificable– como un campo oculto del formulario (y esta es la razón que no se «salta» directamente al servidor seguro sino desde el «action» en un formulario).
  6. Los umbrales y reglas del AutoScaler funcionan bien, salvo para el escalado hacia abajo. Las reglas se definen con un umbral bajo y uno alto. Si la carga seleccionada (en nuestro caso uso de CPU) supera el umbral alto, cre nuevas instancias, si es inferior al bajo mata instancias. El problema es el siguiente, en nuestro caso el bajo es 30% y el alto 75%. Supongamos que hay cuatro instancias al 40% (carga total = 160%), el autoescalador no decrementará hasta llegar al 30% aunque si quita una queda muy por debajo del 75% (con tres quedaría en 53% cada una). Así no se optimiza muy bien el uso de recursos, ni los costes. Amazon dice que introducirá «reglas de usuarios», mientras tanto yo lo solucioné con un script bastante simple que hace esos cálculos. Si la carga total con una instancia menos es inferior a un «umbral intermedio» (60% en nuestro caso) y hay más de dos instancias en marcha, entonces ordena al AutoScaler que baje termine una instancia. Estos cálculos son visibles en m.meneame.net/ec2.php, esos valores son generados por este script adicional de control de escalado.
  7. No dan factura oficial, hasta ahora no hemos tenido problemas con ellas, al menos Benjamí, nuestras contables ni Hacienda no se quejaron todavía, creo 😉

Esos son los seis problemas fundamentales que hemos tenido, salvo el sexto, los demás son todos solucionables con un poco de programación.

[1] Tenemos tres instancias «reservadas», es decir se paga una cantidad por adelantado (uno o tres años) y se obtienen muchos mejores precios. El ahorro anual es exactamente el 30% sobre el precio de lista.

[2] Acabo de confirmarlo (12/mayo), ya no aparecen nuestras IPs en las listas de Spamhaus.

Probando Amazon EC2, es todo GNU/Linux, con Xen

09 miércoles Ene 2008

Posted by gallir in empresas, internet, software libre

≈ 19 comentarios

Etiquetas

amazon, cloud computing, ec2, s3

Tenía la intriga de saber cómo funciona Amazon Elastic Compute Cloud por varios motivos, fundamentalmente académico —dicen que es la siguiente «revolución» y que Google no tardará en imitarlos– y ver también si podría servir para el Menéame –sí, sirve– y para los que quieran comenzar con proyectos en Internet –es genial–.

Tenía el interés en aprender porque la información que se encuentra en los blogs o en las noticias en general se habla muy poco de los detalles técnicos. Así que anoche me puse en ellos y no me acosté hasta las 6 de la mañana hasta tener bien claro como funciona.

Así me pude dar cuenta que en realidad se trata del bien conocido Linux con el Xen. Nada más y nada menos. Pero con una diferencia fundamental: te puedes crear nuevas instancias –i.e. máquinas virtuales– o destruirlas en cuestión de segundos desde tu propio ordenador con las utilidades de línea de comando Java que te bajas de Amazon.

Además tiene otras ventajas, puedes elegir la «potencia» y «tamaño» de la máquina que quieres, y se facturará de acuerdo a ella. Por ejemplo la más simple es una equivalente más o menos a un núcleo Opteron de 1.2 GHZ (en las pruebas que hize me va un 30% más rápida que un Xeon 3 GHz de 64 bits que tenemos de backup para el Menéame). Hay tres tamaños diferentes, la simple mencionada (de 32 bits), una «dual» de 64 bits y una equivalente a cuatro núcleos de 64 bits.

La facturación es por hora, la simple son unos 0.1 dólares por hora que esté en marcha, la siguiente a 0.4 dólares y la de cuatro núcleos a 0.8 dólares (más impuestos/IVA).

Por defecto y si sigues las intrucciones de instalación te instala una Fedora Core 4. Pero puedes usar otras imágenes de colaboradores y no oficiales y que incluyen hasta Ubuntu Gutsy de 32 o 64 bits.

Cada «imagen» está definida por un XML (llamado «manifiesto») almacenado en el sistema S3 de Amazon, estos «bundles» son llamados AMI. Para poner en marcha una nueva instancia sólo tienes que indicar el AMI que quieres usar, por ejemplo para la Ubuntu de 32 bits sólo he tenido que ejecutar desde casa el comando;

ec2-run-instances ami-ed22c784 -k keypair1

Nota: el «keypar1» es una clave RSA para poder acceder luego como root vía ssh a la nueva instancia, el usuario root no tiene password.

Otra ventaja importante es que una vez has personalizado la imagen con el software y las configuraciones necesarias es muy fácil crear una nueva imagen y su AMI correspondiente, almacernalo directamente en S3 (te facturan por espacio) y luego usar ese AMI personalizado para poner en marcha nuevas instancias.

En resumen, el servicio EC2 es de servidores virtuales Linux-Xen, pero gestionado enteramente por tí, ellos te cobrarán por el uso que haga de CPU, almacenamiento (si guardas AMIs o datos en S3) y trafico de Internet.

Si lo que buscas es un servidor para inciar un proyecto, es tu opción. Pero haz los cálculos, la máquina simple te costará por mes:

0.10 dólares * 24 * 30 = 72 dólares ~= 52 euros

A eso debes sumar el tráfico, si transfieres unos 500 GB te costará 90 dólares (unos 65 euros).

Y ahora como siempre la opinión. Esto explicado así no parece gran cosas, sobre todo para los que conocíamos el Xen. Pero la forma de administrarlo y crear y destruir «maquinas virtuales» en pocos minutos –además se puede automatizar con scripts que analicen la carga, por ejemplo– es otra innovación importante. Y todo junto seguramente cambiará radicalmente la forma en que trabajamos con «servidores» en Internet. Ya lo dicen los blogs y la ya conocida frase cloud computing.

Y todo esto se hizo con software libre.

Es más, creo que hubiese sido imposible llegar a este nivel y escala con software privativo. Pero claro, siempre habrá alguno que diga «con el software libre se copia, no se innova, larga vida al software privativo» sólo porque está alucinando con el iPhone (y posiblemente con las bellas nalgas de Steve Jobs).

Actualización: Leyendo los foros me dí cuenta de un problema importante. Los datos de cada máquina virtual sólo persisten durante la existencia de la misma, si ésta se detiene se pierden todos los datos. Han reportado casos de algunas «desapariciones» de instancias (una persona reportó tres en varios meses). Por lo tanto estás obligado a mantener copias de seguridad o datos replicados en otras instancias.

Comprar el libro

Principios y algoritmos de concurrencia

gallir@twitter

  • RT @jpartej: Un Airbus interceptado esta tarde por un falsa alarma de bomba. Seguramente un F-18 del Ala 15. 23 hours ago
  • Siglos de educación pública y universidades y todavía estamos discutiendo si hay que becar (también) al talento. 1 day ago
  • No es tema del dinero público, todo lo que hace un gobierno es a costa de nuestro dinero. Es la frivolidad del tema… twitter.com/i/web/status/1… 1 day ago
Follow @gallir

RSS Notas recientes

  • Se ha producido un error; es probable que la fuente esté fuera de servicio. Vuelve a intentarlo más tarde.

Archivos

Comentarios recientes

PM en Cuidado con las «clever soluti…
Me matan si no traba… en Cuando el periodismo cede el c…
surco en Cuando el periodismo cede el c…
pancho pérez (@lonch… en Cuando el periodismo cede el c…
Fernando en Cuando el periodismo cede el c…
@beoxman en Cuando el periodismo cede el c…
gallir en Cuando el periodismo cede el c…
Jan Smite en Cuando el periodismo cede el c…
Alejandro en Cuando el periodismo cede el c…
Galletor en Cuando el periodismo cede el c…

Meta

  • Registro
  • Acceder
  • Feed de entradas
  • Feed de comentarios
  • WordPress.com

Licencia

Creative Commons License
Esta obra está bajo una licencia de Creative Commons.

Crea un blog o un sitio web gratuitos con WordPress.com.

  • Seguir Siguiendo
    • Ricardo Galli, de software
    • Únete a 28.667 seguidores más
    • ¿Ya tienes una cuenta de WordPress.com? Accede ahora.
    • Ricardo Galli, de software
    • Personalizar
    • Seguir Siguiendo
    • Regístrate
    • Acceder
    • Denunciar este contenido
    • Ver sitio web en el Lector
    • Gestionar las suscripciones
    • Contraer esta barra
 

Cargando comentarios...