Etiquetas
El viernes 5 de agosto me voy con toda la familia a un pueblo de Extremadura cerca de la frontera con Portugal (Valencia de Alcántara) a visitar a unos amigos. Regresábamos el martes 9 a la tarde, ¿qué podía pasar en Menéame que no se pudiese solucionar con una navegador y la consola web de AWS si nunca habíamos tenido problemas graves? Si necesitaba algo más, podía instalar las herramientas de AWS en otro ordenador y solucionarlo en pocos minutos. Así que por primera vez viajo sin mi portátil, sólo mi tablet Android con conexión 3G Vodafone (además de mi teléfono también con 3G).
Pues ocurrió el desastre en Amazon, les falló todo lo que podía fallar, todos nuestros planes de contingencia no podía aplicarse (salvo el «rehacer desde cero» con los bakups) y yo sin mi portátil y con el 3G completamente inestable, prácticamente como si no tuviese conexión. Si no hubiese sido así Menéame no habría estado «off line» tanto tiempo, quizás sólo unas pocas horas. Fue una pesadilla.
Amazon tuvo varios fallos: primero el corte completo de la conectividad a todas las instancias, luego la desincronización del API de gestión, luego los EBS que quedaron totalmente inaccesibles y bloqueando la gestión de las instancias que los usaban, y para rematar un fallo en el software de creación de los «snapshots» (backups por bloques en S3) que borraba datos de algunos bloques (lo descubrieron durante la crisis, y nos afectó a nosotros).
Nota: es un relato rápido, ya corregiré erratas, ahora me voy a duchar, que la última vez fue en Valencia de Alcántara 😉
Arquitectura y planes de contingencia de Menéame
- Los servidores webs de Menéame se crean y destruyen automáticamente, monitorizados por Amazon CloudWatch y el LoadBalancer. Además desarrollé otro programa que se asegura que todos estén en funcionamiento correcto, caso contrario los destruye y obliga a la creación de nuevas instancias, así no tengo que preocuparme siquiera de mirar el estado, se «auto reparan» vía dos sistemas de control independientes. Pero estos no fallaron en ningún momento.
- Además tenemos dos servidores críticos para los servicios: el de base de datos (awsb) y el de NFS+autentificación+réplica base de datos (aws0). awsb es el máster de la base de datos, el más crítico y costoso de levantar, pero tiene una réplica en tiempo real en aws0. Cambiar para que aws0 se convierta en máster (failback) es sólo cuestión de cambiar una línea en un fichero de configuración local.php (y otra más para los programas «offline» en Python y Perl).
- Se hacen backups diarios de las base de datos que se guardan en otro EBS independiente, y que sincroniza automáticamente los ficheros en S3.
- Las imágenes y avatares se guardan en un EBS independiente, con copia automática a S3. En caso de fallo del EBS sólo hace falta crear uno nuevo, las imágenes se bajan automáticamente bajo demanda.
- En caso de fallo del EBS con el código fuente y las utilidades necesarias tienen backup diario en otro EBS, que sincroniza automáticamente con S3.
- Además teníamos (sí, pretérito, porque también se jodieron con el fallo de Amazon, otro bug que descubrieron ahora) imágenes en «snapshots» de cada una de las dos máquinas. Si una se moría y perdía todos los datos súbitamente, era cuestión de arrancar otra desde el snapshot, recuperar los datos de backups (desde otro EBS o S3) y asignarle la «IP elástica» para que vuelva a la normalidad.
- Con todos estas precauciones y planes de contingencias, el tiempo de recuperación era desde unos pocos minutos hasta un máximo de 120 minutos, que es lo que se tarda en recuperar completamente la base de datos desde un el «dump» diario (la importación de datos tarda exactamente 110 minutos).
Para hacer cualquiera de las operaciones previas, basta la consola web y comandos básicos de la consola de GNU/Linux, como hacer un tar, o importar los datos a mysql desde un dump de backup. Es decir, nada que no pudiese cualquier otro sysadmin de Menéame. El tiempo estimado en el peor de los casos era de 120 minutos, supongamos que tome el doble. Cuatro horas en cálculos pesimistas para volver online ante un evento de bajísima probabilidad me parecía más que razonable para un sistema que no es crítico para nadie, ni cobra a sus clientes, ni tenemos contratos de servicios con terceros.
Pero lo que no se nos había ocurrido era que fallasen todos los EBS al mismo tiempo, y que los «snapshots» también estuviesen corruptos. No sé si es estupidez o no, pero prometo que no se me pasó por la cabeza, mucho menos que ocurriese mientras yo estuviese en un pueblo casi aislado, sin casi conexión a Internet, ni mi portátil con todas las herramientas. Lo pasé fatal.
La crisis
El domingo a las 19:40 se desconectan todas las instancias, el Menéame es inaccesible por web, tampoco podíamos acceder a las instancias. Aproximadamente a las 20 hs me avisan por SMS. Voy a verificar, no me puedo conectar (usando el ConnectBot de Android) a ninguna de las instancias, sin embargo en la consola web aparecían en estado normal. Abrimos un ticket de soporte web, pocos minutos después Amazon publica que tiene problemas de conectividad en una de sus regiones (i.e. un centro de datos), que es justamente la que estábamos usando. Nos responden que el problema es general y que están trabjando en ello. Me avisan además que hasta Paypal estaba caído. Es decir, una emergencia. Me quedo más tranquilo, ya lo solucionarán. Me voy a cenar con toda la familia, además ese noche era el festejo de la «Boda Regia».
Durante toda la cena iba probando conectarme desde el móvil. Como a la 1 de la mañana, estando bebiendo unos gintonics en el castillo (@bufetameida y @pixspain en Twitter pueden ratificar lo que cuento, fueron testigos de primera mano) logro entrar por ssh a ambos servidores, aws0 y awsb. El segundo (el máster de la base de datos) estaba perfecto, la base de datos intacta, pero el kernel de aws0 daba errores graves de acceso a los EBS. Tampoco había conectividad entre ellos (ni con ping).
Volvemos a la casa del pueblo (de Carlos Almeida), me conecto con el tablet. La conexión variaba de GPRS a 3G y HDSPA cada pocos segundos, por lo que la conexión ssh era una pesadilla. Intento arreglarlo desmontando los EBS, pero el umount se quedaba bloqueado, es decir, el fallo era muy importante, no había «comunicación» con esos dispositivos.
Hago un reboot de aws0, el reboot se bloquea en mitad del proceso según se veía en la consola web de Amazon AWS. No importa, pienso, tenía un «snapshot» con su AMI correspondiente (para poder arrancar una instancia idéntica directamente) de hacía pocos meses (el 1 de marzo). Desde la consola web hago que arranque una nueva instancia, me da error del snapshot. ¡Mierda! lo que me faltaba, pensé, había hecho algo mal durante la creación del AMI. Al día siguiente nos avisarían que había sido otro problema:
Separately, and independent from the power issue in the affected availability zone, we’ve discovered an error in the EBS software that cleans up unused snapshots. During a recent run of this EBS software in the EU-West Region, one or more blocks in a number of EBS snapshots were incorrectly deleted. The root cause was a software error that caused the snapshot references to a subset of blocks to be missed during the reference counting process. This process compares the blocks scheduled for deletion to the blocks referenced in customer snapshots. As a result of the software error, the EBS snapshot management system in the EU-West Region incorrectly thought some of the blocks were no longer being used and deleted them. We’ve addressed the error in the EBS snapshot system to prevent it from recurring. We have now also disabled all of the snapshots that contain these missing blocks.
En pocas palabras, que los snapshots de los discos también estaban corruptos por un error en el software que los gestiona.
En la imagen se pueden ver los snapshots, el último (con el nombre «slave») era el básico para levantar aws0. el Día 8 de agosto Amazon lo detectó como afectado por el error -y otro más- por lo que nos avisó crearía esas copas:
We are in the process of creating a copy of the affected snapshots where we’ve replaced the missing blocks with empty block(s). Customers can then create a volume from that copy and run a recovery tool on it (e.g. a file system recovery tool like fsck); in some cases this may restore normal volume operation. We will email affected customers as soon as we have the copy of their snapshot available. You can tell if you have a snapshot that has been affected via the DescribeSnapshots API or via the AWS Management Console. The status for the snapshot will be shown as «error.» Alternately, if you have any older or more recent snapshots that were unaffected, you will be able to create a volume from those snapshots without error. We apologize for any potential impact it might have on customers applications.
A la mierda, las cosas no podían ser peor (todavía no sabía los que acabo de contar sobre los errores de «snapshots», ni los marcaba como erróneos en ese momento). En primer lugar, los EBS son dispositivos SAN con replicación automática, se supone (y así lo anuncian y venden) que fallan menos que los discos duros (pero se paga un precio además de las tarifas por operaciones, son muy lentos, no más de 25.000 bloques E/S por segundo, con una variabilidad enorme) y que al estar replicados los datos no se pierden. Pero esta vez no sólo que los datos eran inaccesibles, también bloqueaban a las instancias que lo usaban… y además se habían cargado las imágenes de backups.
Me voy a dormir, sin poder hacer nada (y con una conexión que se me cortaba cada minuto, en el mejor de los casos) más o menos a las 4:30 de la madrugada del lunes. Benjamí se queda trabajando y abriendo tickets de soporte, horas después me entero que le cortaron la luz en su pueblo a las 8 de la mañana y por varias horas. Sí, de verdad, no exagero.
Me levanto a las 10hs, me habían conseguido un portátil con Windows 7 (qué horror de usabilidad, al menos para este tipo de trabajo, no encontraba ni la consola), pongo el tablet en modo servidor de wifi. Me conecto, sigue todo igual que el día anterior, no habían solucionado nada. Incluso estaba peor, no podía acceder a aws0 ni awsb por ssh. Tenía varios mensajes de Carme contándome básicamente que no podía hacer nada, y que no había soluciones desde el soporte de Amazon.
Intento reiniciar aws0 por la consola, no hace nada. Entonces hago lo primero «peligroso»: detengo la instancia para intentar hacer otro snapshot completo y se ser posible volver a arrancarla. Se detiene correctamente, al indicar que la arranque otra vez, pasa a «pendientes» durante unos minutos y enseguida vuelve a ponerse en estado «stopped».
Intento crear un AMI (la imagen de arranque), pero inmediatamente da «Internal Server error». Me pongo a hacer snapshots independientes de cada uno de los tres EBS. Me funcionan los dos importantes, el del NFS y la copia de base de datos del slave (son los dos primeros backups que se observan en la imagen anterior) pero falla el del cache (el que se regenera automáticamente desde S3). Intento varias veces hacer un «detach» de ese EBS para ver si desbloqueaba la instancia, pero era imposible:
Así que estaba sin poder conectarme por ssh, ni quitarnos de encima el EBS que parecía ser el problema. Me estiraba de los pelos, no podía creer todo lo que estaba pasando.
Carlos Almeida y mi familia me piden me tranquilice, y casi me llevan a rastras a comer a Portugal (a Castelo de Vide) y con el roaming de datos deshabilitado. Volvemos como a las 19hs, la situación sigue igual, aws0 sigue muerta, sin poder arrancar, aunque puedo ya entrar a awsb. Tomo la decisión de recuperar la instancia desde los backups de EBS que tenía, creo una nueva instancia «limpia» de Ubuntu 10.4. Me bajo la clave privada RSA desde mi copia en Dropbox para poder hacer ssh con el usuario por defecto (ubuntu). No pude hacerla funcionar en putty. Me estaba frustrando, además con la conexión errante. Vi que había herramientas para convertirla a putty, hice lo que pude, pero fue infructuoso (quizás también la cabeza no me daba para mucho más).
Además el portátil con Windows 7 iba de esa forma, cada pocos minutos el puntero del ratón de ponía como una lupa, y no podía moverlo, sólo hacía zoom del escritorio o del navegador web. Tenía que reiniciarlo frecuentemente, y usando sólo el teclado. Lo importante en este punto es que si hubiese tenido mi portátil con las herramientas de AWS (lineas de comando en Java) habría podido recuperar Menéame en pocas horas (como así sucedió cuando regresé a casa). Todavía no termino de arrepentirme de no haberlo llevado.
Al día siguiente, martes 9, a las 18:10 hs teníamos el vuelo de Sevilla a Palma. El viaje en coche desde Valencia de Alcántara a Sevilla son cuatro horas, teníamos pensado salir a la mañana temprano para visitar Mérida, que está a medio camino. Cancelamos la visita así podía quedarme hasta más tarde, saldríamos a las 12hs directamente hacia Sevilla. Me quedé intentando recuperar aws0 y entrar a la instancia nueva hasta las 4 de la mañana. Me voy a dormir, que tenía que conducir. Me levanto a las 10hs, me conecto, sigue todo exactamente igual.
Teníamos varios avisos sobre los EBS y los snapshots, y que tomarían tiempo arreglarlos (entre 24 y 48 hs), que estaban modificando el API y la consola web para agregar el estado «error» en los EBS y snapshots -sí, no tenían previsto que fallasen de esta manera-. Además nos avisan que ya podríamos hacer el «detach» de las instancias, pero no funcionaba. Estaba igual que horas antes.
Salimos a las 12:15hs después de desayunar y tomar un café adicional (yo estaba hecho polvo). Mi mujer prepara unos bocatas así no teníamos que parar a comer. Llegamos a las 15:30 al aeropuerto de Sevilla, en los últimos 20 km no encontré ninguna gasolinera para llenar el depósito antes de devolver el coche. En el aeropuerto pregunto donde hay una, cojo la autovía hacia Sevilla Este, encuentro cerca la gasolinera, cargamos, a las 16hs estábamos en facturación. Veo que el vuelo que estaba programado a las 18:10 hs estaba retrasado, la hora prevista era a las 19:05. No me dejan facturar todavía porque estaban atendiendo sólo a los del vuelo a Lanzarote. Esperamos casi una hora, aprovecho para seguir intentando recuperar, sin éxito, aws0, voy a facturación, paso los DNI… y la chica me dice que nuestro vuelo era para el 9 de setiembre, no para agosto.
Me cago en la madre del primer homosapiens.
¿Qué otra cagada me faltaba por descubrir? Creo que mi mujer estaba por pedirme el divorcio en ese mismo momento. Yo sólo me reía. Nos vamos al mostrador de Air Europa, hay cuatro plazas disponibles. La chica me dice que le penalización por cambio de fechas y clase me sale más caro que comprar los cuatro billetes. Compro cuatro billetes nuevos (casi 300 euros, contando el descuento del 50% por residentes en Balears) y facturamos, allí nos dicen que el vuelo se retrasaría todavía una hora más. Me cago en la madre de neardentales y cromagnones, nunca iba a llegar a Palma.
Pasamos el control, nos instalamos en un bar a dar de comer a las niñas y tomarme un par de cafés. Recibo un correo del director de «social media» de Air Europa, se ofrecen de devolverme el importe de los billetes del 9 de setiembre, ya que recordaba que había tenido muchos problemas con la página web cuando los compré. Al menos una buena noticia, se lo digo a mi mujer, y al menos me puedo vengar de todos los insultos que me había dedicado (y supongo que se calló la mayoría) en los últimos minutos.
Pero la alegría duró poco, en las pantallas sale que la hora estimada de salida era a las 22 horas. A tomar por culo, el cuerpo ya no aguantaba. Me instalo en uno de esos bancos sexagonales del aeropuerto de Sevilla y duermo una siesta con mis piernas haciendo un ángulo perfecto de 120 grados con la espalda. Raquel me despierta poco antes de las 21hs porque los de Air Europa nos dieron unos tickets para que cenemos, vamos a cenar, luego al avión, subimos, nos explican el retraso se debe a que el avión venía de Lanzarote (sí, parece el mismo que embarcaba cuando llegamos al aeropuerto) y de tres secciones de controladores en Canarias sólo funcionaban dos por falta de personal. Y que para rematar ahora teníamos otro retraso por saturación al aeropuerto de Palma. Resultado, llegamos a las 0:45hs a casa.
Enciendo los ordenadores, la Nespresso, me tomo un par de cafés, un vaso de zumo de naranja y me siento a trabajar. La situación estaba exactamente igual que la noche anterior. Así que decido continuar trabajando en la instancia nueva que había creado estando en Valencia de Alcántara. A las 3 de la mañana Menéame ya funcionaba, a las 4:30 ya había recuperado todos los servicios, incluido la reconstrucción del slave de la base de datos desde el último backup que se había hecho el domingo a la madrugada (para estar más seguro no se perdían datos).
Lecciones aprendidas
Resumen breve: si hay probabilidades de morir por una vaca caída desde el cielo, mira para arriba.
Amazon vende a los EBS como sistemas muy fiables, tanto en su fallo anterior como en este, han sido el problema fundamental y que degeneró todo (de hecho las instancias webs, que sólo usan «almacenamiento volatil» no tuvieron ningún problema, sus datos estaba intactos).
Entiendo lo del rayo y que haya provocado un incendio. Lo que se me hace muy difícil de creer que ese corte haya forzado la resincronización de fase manual (ya en mi época de estudiante del grado de técnico electromecánico, hace 20 años, los sistemas de sincronización de fase eran automáticos), y que justamente haya afectado sólo a los sistemas más críticos (los EBS) y no a la alimentación de las instancias que seguían funcionando normalmente. También entiendo la enorme complejidad de los sistemas de Amazon, pero que además haya habido un bug que destruía los datos de los backups de los EBS me suena a la mayor de las putadas divinas después de la inundación en la que se salvó Noé y muchas parejas más. En el mejor de los casos parece que estamos pagando todos por la baja calidad de las subcontratas de Amazon, sobre todo teniendo en cuenta que los EBS fueron los que ocasionaron los problemas de la caída de hace unos meses en EEUU. Yo pensaba que no podía ocurrir dos veces lo mismo, y menos que fallen tantas cosas del mismo sistema: la alimentación, la sincronización, la pérdida de control desde el API, el bloqueo de instancias, los backups corruptos, la falta de automatización para recuperar la consistencia de datos (dijeron que estaban haciéndolo manualmente), y que haya afectado a todos los volúmenes de una región. ¿Todo por culpa de un rayo? Algo no cuadra.
Si la fiabilidad de EBS es la que hay ahora mismo, Amazon AWS no tiene sentido. Si tuviésemos que hacer un sistema completamente tolerante a todos estos fallos tendríamos que gastar más del doble para tener duplicado en tiempo real en otras regiones (y más complejidad si se hace el fallback automático o acceso distribuido), el tráfico entre regiones se paga, y la latencia es mayor.
Si hay que construir todo el sistema pensando en que los EBS pueden generar todos estos problemas, no sólo hay problemas de coste, también de administración de sistemas más complejos. Es decir, estamos pagando un sobreprecio importante (en dinero y rendimiento) por la supuesta fiabilidad de los EBS. Por menos de la mitad de precio se puede contruir la misma infraestructura en proveedores de hosting normales. En Menéame pagamos unos $1.300 euros mensuales de AWS, si tuviésemos que tener todo replicado y distribuido para sobrevivir a fallos generales de los EBS deberías gastar como mínimo el doble. Por mucho menos de ese precio podría tener una arquitectura igual de redundante y más eficiente (los discos duros más cutres son mucho más rápidos que un EBS, y por lo visto, mucho más fiables) en cualquier hosting tradicional.
Amazon debería re-estructurar y definir bien las condiciones de servicio de los EBS. Si estos problemas generalizados y «bloqueantes» pueden volver a ocurrir, acabaremos migrando a otro proveedor. No se puede vivir tranquilo con esta espada en la nuca por fallos catastróficos de los sistemas que te venden como «tolerantes a fallos y replicados» y sobre el que no pueden basar para construir los «planes de contingencia». Teníamos varios de esos planes, todos fallaron. Nuestra estimación en el peor de los casos no llegaba a más de dos horas aún con la mayor catástrofe… si estoy disponible para hacer las tareas más complejas y que requieren mucha experiencia (es reconstruir la arquitectura casi desde cero, y con comandos del API no accesibles desde la consola web). Por lo tanto no disponible para la mayoría de las startups y empresas pequeñas, y mucho menos tener personal duplicado por si uno de ellos está desconectado en un pueblo de la Extremadura profunda cerca de la frontera con Portugal.
Si eres el único que puede recuperar un sistema cuando fallan todos los planes de contingencia anteriores, nunca viajes sin tu ordenador preparado, e incluso con 3G de varias empresas (que manda huevos, también tengo otro SIM de ONO que va por Movistar, y no lo había llevado). ¿Suena ridículo si estás pagando un sobreprecio para estar tranquilo? Pues sí, por eso acabo de ver y/o entender el modelo de negocio para solucionar emergencias de empresas que no pueden tener dos personas expertas en «la nube» para solucionar estas emergencias graves. Pero sigue siendo ridículo que haya que pagar otro sobreprecio para dar tolerancia a fallos a un sistema que te venden como tolerante a fallos.
Creo en «la nube», y que es el futuro, pero Amazon ha fallado -dos veces- en asegurar el funcionamiento correcto del servicio crítico de un sistema que sirve de pilar a todo lo demás. No sé si tiene solución, ni cómo lo tomará Amazon. Pero si no hay aclaración de por qué no cumplen con sus condiciones de servicio y cómo será en el futuro, habrá que pensar en abandonarlo. Por ahora y mientras no haya esa aclaración técnica de cómo será en el futuro, no aconsejaría a ninguna startup que se mudara allí: te pueden arruinar las vacaciones, y afectar a la familia. Me ha pasado, en el peor momento posible
Sólo me queda pedir otra vez disculpas. Y prometo no volver a viajar sin mi portátil, al menos hasta que tengamos sistemas de fallback automáticos repartidos en al menos dos continentes y tres centros de datos.
Ricardo Galli, de software 
Pingback: La crisis con Amazon AWS
Te parecerá normal que un auto-denominado gurú de la computación (no directamente, que ya sé que me harás buscar cita) no haya pensado que Amazon podría fallar en un momento dado y no tuviera un mínimo sistema de failover que mostrase una captura de la última portada.
No sólo eso, si no que el servicio está interrumpido unos dos días y medio y el dominio no mostraba nada, cuando se podría haber colocado una redirección a la explicación.
Luego resulta que guardas la clave privada de SSH en Dropbox. Muy profesional.
Entre esto, los fakes que te cuelan por Twitter y que todavía te das aires de chulería («que me voy con bufetealmeida», «que me tomo unos cubatas en un castillo y ellos pueden dar fe»)… te mereces lo que te pasa.
Atte. Troll (ya te ahorro el esfuerzo).
Gallir, te van a indemnizar en amazón? Cual sería la alternativa? OVH?
Vaya aventura jajaja
No es porque sea mi pueblo, pero lo de anular la visita a Mérida, no tiene perdón.
->;D.
No te preocupes, estas cosas pasan, lo que tienes que hacer es recompensar a tu mujer y a las niñas.
Así que si menéame se cae y tu estás lejos de un ordenador con internet, no hay nadie mas que pueda arreglarlo? no puedes coger vacaciones?
Absolutamente de todo se aprende 😀
Disculpado estás hobre. Nada mas faltaría. Ya se sabe: si se tienen que torcer las cosas, se tuercen bién. Torcerlas por trocerlas es tontería.
Dios mio … si haces una peli con esto y la llamas «The Shinning 2» te forras …. que te recuperes ….
que putada…
solo puedo decir eso… «si las cosas pueden fallar, van a fallar»
las disculpas, evidentemente, están más que aceptadas, y no solo eso… sinó que hay que darte las gracias por esas horas dedicadas y la pasta gastada.
Saludos!
PD. En las fiestas de San Froilán (Lugo) deberías de tener el pulpo pagado… jeje
Los sistemas de backup, los venda quien los venda siempre hay que probaron y por molesto que sea o por peligroso que resulte la única prueba válida es restaurar todo.
Pero vamos… Menuda historia.
Para los amantes del TL;DR: Murphy es un maldito resabido y nos persigue hasta en nuestras vacaciones
Más que «The Shining» en este caso se debería llamar «The Shanking» a juzgar por cómo quedó ese asiento… 😉
¿Qué pasa si cae el rayo y además tienes un accidente de coche? A todo lo que has dicho, añado que aparentemente el factor bus de Meneame es muy, muy alto.
Una cosa a tener en cuenta ser tu solo el que puede reparar este gran proyecto te hará siempre esclavo del mismo.
Y algo importante es tener un vnc en alguna maquina remota de la cual poder trabajar con un cierto nivel.
Pero creo que lo solucionaste mas que bien, y es el costo de tener un sitio tan grande.
Creo que el estrés que habrás vivido necesitaras un nuevo viaje!!! ( si, sin nada electrónico)
Pese a lo trágico de esta incidencia no he podido evitar (a toro pasado) un esbozo de sonrisa ante los guiños humorísticos que dejas caer «entiendo la enorme complejidad de los sistemas de Amazon, pero que además haya habido un bug que destruía los datos de los backups de los EBS me suena a la mayor de las putadas divinas después de la inundación que se salvó Noé».
Murphy sabía lo que decía
Evidentemente es fácil dar consejos a toro pasado, pero la próxima vez que no te lleves tu portátil, llévate una imagen en Virtualbox por si tienes una emergencia.
Aunque dudo que te vuelvas a dejar el portátil 😉
No quisiera meterme en la vida privada de nadie (más bien temo que me pase a mí) pero si, como bien dices, es «…un sistema que no es crítico para nadie, ni cobra a sus clientes, ni tenemos contratos de servicios con terceros…», ¿no crees que has hecho demasiado (cancelando planes, teniendo que ser obligado por tu familia a disfrutar de los que hay en pie…) para recuperar menéame?
Viva la prrofesionalidad y demás, pero si no ponemos un muro de veinte (o más) metros de alto, entre nuestras horas de trabajo y nuestras horas de ocio, acabaremos perdiendo lo uno, lo otro, o los dos.
¡Gracias en todo caso por recuperar meneame!
Le veo relajado despues de todo.
Yo que tenia muchas ganas de probar esto de Amazon y se me han quitado de golpe.
Jamás habia visto tantos despropositos juntos, y cuando lei que se borraban los snapshots me morí de vergüenza ajena. Tendriamos que saber cuantos técnicos son y cuanto cobran.
Aamazon es un proveedor low cost.
Deberías probar dejando la API y la base de datos en Amazon replicando los datos a uno de los centros de datos en EEUU y tener servidores web en dos ISP diferentes. Más barato y fiable.
Yo soy partidario de proveedores epañoles que tienen unas obligaciones que no tienen Amazon ni OVH. Ponte a reclamar a Irlanda o Francia siendo una Pyme, particular o autónomo.
Lo peor, que te jodieran las vacaciones y el rato para disfrutar con la familia. Sin Meneame podemos vivir unos días 😉
ESPERO que puedas tener unos días más de vacaciones para desconectar y que Amazon dé explicaciones.
Gracias por el esfuerzo y por un post tan completo.
Solo pagáis 1.300$ en servidores? Si es así, creo que por ese precio, demasiado tiempo on-line sin problemas esta meneame.
Podrías aclarar el coste real de los servidores?
La gente suele criticar lo que no entiende; y por eso los hay que creen que la culpa es «de la nube» – porque es lo nuevo. Efectivamente la culpa está en quienes la pusieron a punto, y eso da mucho de pensar… Porque cuando un sistema falla justo en su punto fuerte…
En cualquier caso, esto es lo de siempre: no es algo por lo que vaya a desaparecer ni Amazon, ni Paypal, ni meneame…, es lo que opino: se convierte en una mera anécdota a medida que vaya pasando el tiempo.
La mejor política de todas: nunca depender de los demás. Nunca se sabe si ése será el sujeto sin identificar que te putee.
Vaya fue una putada, y la verdad es que yo también tenia pensado en mudarme a Amazon. Si meneame esta en Amazon, eso quiere decir que son de calidad y buenos.
Y creo que muchos de nosotros te seguimos, por las explicaciones técnicas que das, como la explicación de la estructura de meneame en amazon o de los join en la base de datos, este tipo de clases se agradecen mucho.
Saludos
¿disculpas? ¿ por la no disponibilidad durante unos días de un servicio gratuito que es meneame ? para nada, disculpado desde el primer momento. Ahora a disfrutar después del zafarrancho.
También el portátil puede fallar en un momento clave, no hay que darle muchas vueltas, estas situaciones son inevitables, tarde o temprano algo de esto termina pasando.
Pingback: Texto casi Diario: María Pilar Clau & Mariano Gistaín » YA funciona ‘Menéame’
A los trolls ni caso, la transparencia contando estas cosas se agradece, la verdad. Entre otras cosas porque no tenías ninguna obligación de dar una explicación detallada como esta.
Eso te pasa por hacer:
var += 2;
En lugar de:
var++;
var++;
Para otra vez, preparas mejor las cosas!
Sin meterme en la primera causa del problema, me hubiera gustado un poco más de autocrítica sobre el factor humano. Es cierto que Meneame es lo que es y hay quien hay, pero conociendo que hay más de uno gestionando, lo que veo muy crítico es que todo este tema técnico dependa de una sola persona, y que esa persona, temporalmente (vacaciones) o definitivamente (no hay que ponerse tremendo, simplemente en una empresa ese alguien se puede ir a otro lado) no esté disponible.
Vale, que puede ser que las otras personas no tengan el conocimiento suficiente para resolver el problema, pero para eso hay que ser previsor y por lo menos dejar algo documentado en caso de contingencias para que otra persona disponible pueda hacerse cargo.
Y tu santa esposa te lo agradecerá 😉
Me parece increible que la gente piense que meneame es una aplicación/servicio de vida o muerte. Que es una simple página de noticias/opiniones y entiendo que viven de la publicidad…no tienen clientes, ni prestan servicios a terceros (creo). Así que si se cae durante unos días, no creo que pase nada.
El tema de las vacaciones…pues es sencillo «si no quieres recibir pelotazos no te pongas de portero…»
Saludos,
Creo que te mereces unas vacaciones.
@Jose Luis Infante
Sí, es verdad que hace falta otra persona, pero tenerla sólo para estos casos extremos es imposible, por lo caro y porque es extremadamente improbable (en teoría). No es problema de documentación, sino de la complejidad de levantar una arquitectura desde cero, o de modificarla radicalmente. Yo lo puedo hacer rápido porque tengo mucha experiencia, y no estamos en condiciones de pagar a otro para lo mismo.
Lo que nos tocaría hacer es intentar automatizarlo si falla el backup (como nos falló, era lo que faltaba), pero como es complejo y muchas interdependencias que llevaría mucho tiempo… y obviamente «dinero».
Si hasta paypal tuvo problemas (y filmin lo sigue teniendo, hasta hace unas horas), imagina el coste.
Lo que sí voy a empezar a diseñar es una arquitectura redundante para ficheros, pero tendrá que ser con CEPH, ya que los otros sistemas son limitados (como MogileFS) o de rendimiento muy bajo como GlusterFS. Por supuesto, eso no saldrá gratis, significarán unos cuantos de cientos de euros al mes.
Es evidente que el EBS está muy verde y no es para nada lo que están vendiendo. Venden las especificaciones, pero luego te dan una implementación que está muy por debajo.
Dos veces ha petado Amazon EC2 este año (en USA por un fallo de enrutado de red, creo, y en EU por el rayo que mayormente afectó las comunicaciones) y lo que ha respondido peor que fatal y ha amplicado los problemas destruyendo datos ha sido lo que se supone que los protege: el montaje este del EBS, que debería ser distribuido, redundante y tolerante a fallos y en la práctica falla más que un disco duro corriente. O está mal pensado o mal implementado, pero ahora mismo no es muy fiable. Es software, por cierto no libre, y tiene mucho margen para mejorar.
Por pura suerte no me afectó nada importante la catástrofe del EBS, pero por el tiempo y espacio y tráfico perdidos espero algunos descuentos en la próxima factura. Pero eso no es todo. Es que ya no me planteo meter datos importantes en EBS ni crecer en según qué aspectos dentro de Amazon, y sinceramente paso de lo que dice Ricardo de montar sistemas redundantes por encima porque es tonto y caro.
Ejem, resumiendo… que Amazon está quedando un pelín mal. Es hora de que se pongan las pilas, y desde luego nadie sensato debería confiar solo en ellos, porque al menos por ahora toda la redundancia está en sus textos comerciales, no en sus sistemas 😛
Pingback: Sobre el trabajo en Internet y la valoración que hace la sociedad “pre internet” « El viento rozando mi cara
Pingback: Sin conectividad en Amazon Irlanda « menéame
Conozco lo básico de Amazon AWS pero nuestra instalación está muy bien tuneada por Ricardo. Me ofrecí a seguir sus instrucciones por teléfono, paso a paso, para montarlo desde cero con nuevas instancias al ver que todo fallaba –como explica Ricardo. Pero no hay guión;es una cuestión de mucha experiencia y entrenamiento en el tema –tal como Ricardo comenta. Me ofrecí a seguir sus instrucciones por teléfono pero no podía ser; era como intentar hacer malabarismos mientras un experto me dicta por teléfono dónde poner las manos en cada momento.
Por eso me limité a intentar que Amazon recuperase los EBS para montarlos en las instancias. Hasta esta mañana no lo hicieron. Podía haber estado listo en cualquier momento y sin Ricardo menéame habría vuelto. Esperando respuestas (del servicio Premium de Amazon) no dormí más de 10h los ultimos 3 días, incluyendo lunes por la mañana cuando a las 7:30 cortaron la luz en mi barrio de Alaró (Mallorca) hasta las 12h.
Lo de la luz era una interrupción programada por GESA-Endesa desde días antes, recibí la nota. Pero ya no la recordaba cuando todo se apagó. 20 minutos después me quedé sin bateria en el movil y sin la posibilidad de cargarlo. Sucedió que las primeras horas de la caida (domingo a las 19:30) me pillaron fuera de casa en una zona de muy mala cobertura 3G en Mallorca (primero playa, luego cena en casa de mis padres… era domingo). Intentaba ver algo con el móvil (tampoco me llevo el portátil a la playa; ni el tablet) y tanta actividad con mala cobertura drenó toda la batería + media bateria de repuesto (tengo dos). Al volver a casa olvidé cargarlo (no recordaba el corte de luz) y a las 7:30 estaba sin un solo watio para ningún acceso a internet.
Bueno, todo pasó. Hoy me recuperé durmiendo 8 horas 🙂
Pingback: 1ª Semana de Agosto 11 - RubenDomFer.com
Hace tiempo me pasó algo que sin ser parecido podría asimilarse. Me encontraba gestionando un curso online con 250 alumnos entre España e Iberoamérica. En pleno agosto se fue todo el Moodle de la universidad a pique. Nadie de sistemas disponible. Todos de vacaciones.
Solución de bajo coste: enviar un correo electrónico a todos los alumnos y que se tomaran vacaciones obligadas en el curso hasta nuevo aviso.
No sé si es la solución más adecuada, pero… hay veces que la familia y amigos llevan razón. Espero que ese estrés acumulado no te pase factura.
Ah, y mira que eres un tipo optimista. Este post lo demuestra.
Gracias por la información que suministráis de lo ocurrido, creo que los temas personales tendríais que dejarlos fuera del problema, vuestras familias lo agradecerán.
Si me gustaría conocer (no exacto pero si aproximado) el coste que tiene para Menéame la solución que os ofrece Amazón, ya que los 1.300$ que puso Gallir me sonó a un precio muy muy bajo.
Yo dirijo una web dentro de las 300 más visitadas de España, utilizamos un Cluster, alojado en Canadá y pagamos más de 3.000$ mensuales, teniendo un servicio técnico que soluciona cualquier incidencia sin ni siquiera tener que abrir un ticket,
Espero que no os vuelva a ocurrir
Un saludo
Porqué no usais Geocities??? Otro galli cantaríi… 😀
Pingback: La crisis de Menéame con Amazon AWS
Ricardo.. si te mueres ¿se acaba Menéame?
Ricardo,
Necesitas a) un segundo de a bordo y b) delegar. Sino cualquier día te da un síncope chico.
Bueno, Ricardo joder ahora que estas montado en el dólar y que podrías haber pasado unas vacaciones trankilas con la santa y los churumbeles, vas a valorar una verbo: delegar.
Por otro lado, como toda nueva nueva tecnología estas padeciendo los sinsabores de pasarte a la nube sin ser una cosa madura y a prueba de «rayos», es que donde se ponga un hosting tantas moderneces dentro de 5 añitos.
En fin, de todas formas tu relato me gustó y te deseo mejor suerte para tus próximas escapadas vacacionales.
Ricardo, ¿Y lo bien que te lo has pasado? eh!!! ¿Eso no cuenta? Que emoción por Dios!!!!!!!! Tecnología, Lugares inhóspitos, Viajes al extrangero, Imprevistos en el Aeropuerto, Fiestas, Alcohol, hasta Pasión con mujeres!!!!!! Joder si parece una película de espias!!!!!! Jajajajaja.
Hala chavalote, la 1º Ley de Murphy te acaba de pegar un repaso. Si algo puede salir mal, saldrá.
Me parto!!!!!
Por curiosidad, que compensaciones ofrece amazon y que responsabilidades teneis con los anunciantes?
Si te vuelve a ocurrir algo asi en VdeA tienes un CAPI con linex en el castillo y wifi en casi todos los bares.
Ricardo, olvidaste el corolario de Finagle a la ley de Murphy:
Algo que pueda ir mal, irá mal en el peor momento posible.
También digo que si eres el único experto que lo puede solucionar, deberías dejar bien documentadas todas las instrucciones a seguir en cada escenario posible que se pueda dar en tu ausencia.
Murphy hizo de las suyas, y contra eso poco se puede hacer. Los «Y si» quedan bien, pero… cuando todo se empeña en salir mal, sale mal. No hay más. Todos lo podemos ver más fácil, sencillo y cómodo desde fuera, pero… no es así. Lo que está claro es que Ricardo hizo lo imposible por resolverlo rápidamente, no lo consiguió pero en el camino aprendió muchas cosas. Hay que quedarse con eso. 🙂
Y chapeau por la transparencia contando todo lo que pasaba en la trastienda mientras mucha gente estaba en un sinvivir sin menéame. Posiblemente eso debería hacer reflexionar a las personas sobre su «adicción» a una web. El «peta» está ahí por algo.
Creo que te podría interesar algún gestor cloud como RightScale o una opción híbrida AWS + Cloud.com (CloudStack) tambien gestionado todo desde un solo panel RightScale (http://is.gd/1H9rqo). El ahorro de tiempo de administración de sistemas parece que es significativo. También es interesante seguir el progreso de http://www.nebula.com, va a cambiarlo todo…
Un saludo.
Jajajajajajaja.
Me he partido leyendo la crónica de la catástrofe.
Y ya la guinda de tener que usar un portátil con Windows 7, para decojonarse.
Gracias por alegrarme el día.
Lo malo pasó por fin… Me pongo en tu situación y tuvo que ser desesperante… Te mereces unas nuevas vacaciones…
Un abrazo.
Llevo más de un año usando Cloud Computing para alojar nuestra web (entre las 20 más visitadas en España). Utilizo Windows Azure, el servicio que ofrece Microsoft y, toco madera, hasta ahora nunca he tenido la más mínima caída de servicio. En todo caso tengo todos los servidores redundantes en previsión de posibles errores. Sólo tuve que llamar una vez a Soporte y me atendieron fantásticamente de forma muy profesional y además en castellano. A todos aquellos que tienen dudas de Amazon les invitaría aunque sea a probar este servicio y luego comparar.
Muchas gracias por contarnos tu experiencia.
Por desgracia estas cosas pasan, pero como tu bien dices ni se cobra a los clientes ni hay contratos con terceros, lo has hecho lo mejor que has podido y seguro que te sirve para ampliar tu experiencia. En esas condiciones estoy totalmente de acuerdo contigo en que no puedes pagar otro sueldo y si la redundancia total vale tan cara pues es un riesgo que hay que asumir. Esta vez ha tocado la lotería, pero no es algo que pase muy a menudo (para suerte en este caso).
Saludos.
Venía a poner un comentario en plan «serio», pero vista la clase de respuestas, directamente me voy a cagar en la puta madre de (casi) todos los comentaristas. No por nada, sino porque, como han dicho, Menéame ofrece un servicio no esencial y de forma gratuita (que por si fuera poco, el código de menéame es libre: si lo sabes hacer mejor, coge su código y monta tú un server). Si no puedes aguantar una semana sin él, ¡tienes un problema! Encima el señor gallir se ha quedado sin vacaciones (porque sí, se ha ido, pero no las ha disfrutado) para que tú, señor o señora comentarista pudiera rascarse el pie mientras pone un comentario en menéame. Al señor gallir, por tanto, le recomiendo que se vaya de vacaciones sin portátil ni móvil. Si fuera un servidor de, yo que sé, un hospital, pues lo podría entender, pero como no es el caso, las vacaciones están para disfrutarlas. Aunque haya que quedarse una semana (¡o dos!) sin menéame.
Ahora sí, el comentario serio:
Vaya tela con Amazon, pero como bien dicen, bastante tiempo está online por el coste que tiene aunque yo pensaba que un hosting tradicional para la cantidad de visitas que recibe menéame sería más caro (si el «Efecto menéame» afecta a otras webs, ¿cómo no va a afectar el «Efecto menéame» al propio «Menéame»? 🙂 )
Como te comentaba por twitter y comentarios tu mismo en este artículo una lección muy muy importante que podemos aprender los demás es:
– Por ahora y mientras no haya esa aclaración técnica de cómo será en el futuro, no aconsejaría a ninguna startup que se mudara allí.
Y yo añadiría ni cualquier pyme a no ser que tuviera personal («abundante») altamente especializados en estos sistemas.
Después de la tormenta llega la calma asi que de resto desearte que tengas unos días más tranquilos y puedas disfrutar de la familia 😉
Me he leído ahora toda la aventura y he terminado agotado……. que pesadilla!!!.
Se ve que el post está escrito cuando todo está muy reciente. A donde van todos los argumentos positivos que había en posts anteriores sobre los servicios que Amazon presta? Ni de lejos una infraestructura que montes en un hosting tradicional te costará menos que lo que pagas ahora por Amazon, y encima será mucho peor! Además, te dará más trabajo ya que o pagas un mantenimiento o tendrás que desplazarte físicamente a solucionar problemas. No podrás escalar con tanta faclidad y rapidez como tu mismo dijiste, etc. Que Amazon es inestable ( EBS )? Si. Pero además de estar seguro de que esto no volverá a suceder y que habrán aprendido mucho todas las partes, tanto proveedor como clientes; estoy más seguro aún de que Amazon representa una importantísima evolución en cuanto a Hosting, ofreciéndonos un servicio económico que antes era impensable tener! Recuerdo presupuestos sin SAN/NAS, de 4 servidores y balanceador por unos 6000 euros mensuales… y en un solo datacenter, sin ninguna garantía, ni escalabilidad!!! Además, con toda la experiencia que tienes, como pudiste creer que eso del 100% de uptime existía? En serio ideaste un «peor escenario» tan optimista??? Por otra parte, como tu dices, la gente puede vivir sin Amazon, por que no haber sacado un backup diario a otro hosting externo y haber restaurado ese backup? Total, ya llevabas horas de downtime, que más da que se hubiesen perdido unas horas de datos si como tu mismo dijiste meneame no es un servicio crítico? Esto no es un trolleamiento, y nisiquiera soy un experto en administración de sistemas, pero quizás sería bueno pensar algunas de estas cosas. Con tus conclusiones y decisiones seguro que nos volverás a ilustrar y seguiremos aprendiendo de tus consejos y desarrollos.
Ley de Murphy para Amazon: falló todo lo que podía fallar, y un poco más
Gracias por compartir, yo también sufrí la caída de Amazon aunque nos recuperamos mas rápido , porque estaba de vacaciones pero no de viaje ( aun así toda la familia me ha mirado muy mal). Estoy de acuerdo en todo lo que has contado, pero no veo lógico en que no tengas replica en otro cpd de Amazon, (no puedes poner la slave en otra zona? El coste no creo que sea muy alto).
En mi caso, gasto bastante mas al mes en Amazon, ya que tengo desarrollos Java que cosumen muchos recursos, y uso s3 para servir objetos. Y sigo sin ver una alternativa de hosting con balanceador viable.
El soporte Premiun lo contratasteis en la avería o ya lo teníais?
Muchas gracias por la explicación, ha sido muy didáctica. Es una suerte que haya profesionales como tu que de manera altruista compartan experiencias tan «especiales» como ésta.
Estoy estupefacta con tu relato, nosotros estamos probando un sistema piloto y tenemos nuestros servidores en AWS en Dublin , pero milagrosamente no nos ha pasado nada, gracias a dios porque nuestra configuración y planes de contingencia nada tiene que ver con los vuestros, asi que no se que hubiesemos hecho, mas que tirar de Backups, yo no estaba de vacances, pero hubiese sido bastante lio volverlo a poner todo en marcha! Ahora me estoy pensando usarlo cuando pasemos a produccion, tus lessons learned me han servido mucho, tenia mis dudas, por la falta de acceso a consola y algunas cosillas mas pero esto ha acabado de convencerme, creo en el Cloud , of course, pero algo private/public tendremos que utilizar para un tener buen performance en produccion! gracias por compartirlo!
Chorradas…
No ha sido para tanto. La gente se -desintoxica- un poquito de tanta fisgona y a otra cosa mariposa.
Creo que los mayores perjudicados, fueron tus familiares.
Por otra lado, y en base a lo que citas, yo buscaría proveedores por el mercado germano, por honradez, robustez en sistemas y por precio, por supuesto.
Queda claro que actualmente la nube no es la solución-
Nubenauta.. para ser tan experto usando cloud computing, deberias saber que Azure y lo que ofrece amazon no es lo mismo.
Un /cry de los buenos.
Pingback: ES AMAZON Y EL CLOUD COMPUTING LA PANACEA? | ICM
Sobre las herramientas de shell de aws, podías haberlas instalado en una maquina virtual de amazon 😉
Como siempre gracias por compartir la experiencia.
Bajando el tema a los «humanos de la calle», o sea los que tenemos contratado un servidor y alojados allí páginas webs de clientes o proyectos personales, a veces me pregunto que pasaría si el proveedor de alojamiento tiene una perdida total de sus instalaciones… mejor tener una copia en casita, pero que tan viable es estar haciendo copias via FTP de 30 o 40 páginas web… 😕
Pingback: De como un rayo se cargó una nube | Saasmania
Todas las recomendaciones se agradecen,
Si en algo soy experto, es en perdida de datos. Desde mis inicios en la informática hace 19 años he tenido desde perdidas en trabajos escolares (Te extraño Word Perfect de MS DOS) hasta borrar archivos importantes de 2 GB de datos.
Y la única recomendación que yo me atrevería a ofrecer es:
1. Calma
2. Calma
3. Si no están las herramientas completas se complica el trabajo y no salen las cosas
5. Mas calma.
Suena nefasto.. pero las cosas estaran cuando tengan que estar por mucho que el usuario final presione.
Dónde compraste los billetes de avión? 🙂
Perdón si soy un poco insensible.
Las vacaciones espero que bien, lo digo por que soy de «La Codosera» un pueblo al lado de «Valencia de Alcántara» y la verdad es que esto es bonito, una pena que no pudieras disfrutar con todos tus sentidos.
De todos modos piensa que siempre podría haber sido peor, si te hubiera pillado todo ese follón un día como el de hoy, ahora mismo (19:50) estamos a 40º, entonces si que hubieras querido morirte. Siempre podría haber sido peor.
Suerte y un saludo desde Extremadura.
@pindi
No, si a pesar de todo lo pasé muy bien. Buena comida, buenas bebidas y muchas mujeres guapas 😉
La cuestión es: ¿Quién tiene cojones ahora a dejar algo valioso en una nube? 🙂
Gracias por tus amables y educadas palabras.
No fue un rayo… 😀
http://www.siliconrepublic.com/strategy/item/23094-transformer-caused-amazon/
Efectivamente Shine, Windows Azure es un servicio PaaS mientras que Amazon es fundamentalmente IaaS. En mi caso prefiero siempre PaaS ya que me permite centrarme en mi aplicación (en este caso desarrollada en PHP) y no tener que preocuparme de aspectos de infraestructura como actualizar el SO, instalarme un cluster de BBDD, etc.; tareas que a menudo SÍ tienes que hacer en Amazon. Encima me sale a menor coste que Amazon y el Soporte Técnico es 100% gratis llamando a un 900. Por cierto, además tienen 2 datacenters en Europa por lo que en caso de tener problemas en el de Dublín puedo moverme al de Holanda y asegurar siempre a mis clientes que sus datos no salen de la Unión Europea.
Varias cosas:
1. AWS falló, falla y fallará. Algunos caisteis pero muchos otros aguantaron. Por poner un ejemplo, la caida de abril no afectó a Netflix. Es una cuestión de arquitectura pero sobretodo de previsión. Al «chaos monkey» me remito.
2. No es necesario comerte tanto el coco en redundarlo todo. Con tener una máquina en otra AZ como slave y duplicando la partición que exportas por NFS con DRBD basta. Económico y rápido de implementar.
3. Tienes varios SPOF en la arquitectura pero el más evidente eres tu. Lo primero que debes buscar es una solución a eso.
Saludos.
Pingback: Diseñar y administrar un sistema requiere mucho de sentido común, aunque no lo creas « Ricardo Galli, de software libre
@Oriol,
has dicho tal barbaridad, que contesto en un apunte: https://gallir.wordpress.com/2011/08/12/disenar-y-administrar-un-sistema-requiere-mucho-de-sentido-comun-aunque-no-lo-creas/
Nunca me fié de las nubes. Me parecen poco sólidas.
Si algo puede fallar fallará, pero nunca de forma previsible, y si es imposible que falle también lo hará. Cualquier fallo tiende a producir el mayor daño posible, y las únicas leyes infalibles son las de nuestro amado y venerado Murphy.
Lo de llevarte el portátil la próxima vez es una idea, pero no te garantiza la dexconexión de ciertas tareas puramente administrativas cuando necesites tomarte unos días. Piénsatelo, porque igual no basta con eso.
Pingback: Reflexiones sobre el Cloud Computing « elaragon
Pingback: Abierto por trabaciones | El Secreto de las Pymes que crecen
Buenas !!
Creo que conozco la situación por la que ha pasado Ricardo. Estoy en la misma situación, por ahora no he tenido tiempo de buscar un compañero de viaje en el cual delegar todo lo que llevo, por lo que me veo obligado a estar conectado estando de vacaciones. Yo también he tenido un accidente con mi proveedor de servicios,… y ante eso ajo, agua y a levantar todo cuando se han solucionado los problemas de las capas mas bajas. Luego tocará hablar con el Proveedor para ver temas de SLA y las bonificaciones correspondientes. Pero mientras tanto hay que dar el callo y sufrirlo,… por ahora no nos queda otra 🙂
Ricardo,… creo que a nivel nacional has sido puntero a la hora de echarle valor al poner en producción a Meneame en AWS. De tus artículos hemos aprendido todos. Y de este vamos a aprender mucho mas, por lo que tu sufrimiento no ha sido en vano,…. ni muchísimo menos.
Yo también uso AWS para servidores que temporalmente necesito levantar cerca del usuario final para mejorar en latencia con mis servidores de juegos Online. Pero tras hacer pruebas de rendimiento con EBS me dí cuenta de que SOLO tendría los servidores de juegos y el resto a buen recaudo en otro proveedor que también,…… Falla !!! 🙂 jajaja
Creo en soluciones mixtas de Hosting,… hay servicios que encajan mas en Cloud y otros que menos. El abanico actual de posibilidades es grandísimo y poco a poco seguro que va siendo mas robusto, no me cabe duda.
Muchísimas Gracias por compartir tu experiencia !!
Un Saludo !!
Pingback: Peguntas y 10 puntos claves de Amazon EC2 « Ricardo Galli, de software libre