En mi apunte sobre los que nos pasó con Amazon AWS dejaron todo tipo de comentarios, la mayoría razonable, pero otros simplemente comentan de oídas, sin conocer las características, precios, limitaciones de la arquitectura de AWS… e incluso temas básicos de costes. El siguiente comentario es un estereotipo del que repite blablás con mucha autoridad sin conocer a fondo el problema de lo que ocurrió, por lo que aprovecharé para contestar:
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.
Vamos por el punto 1.
Por supuesto que Amazon fallará, por ello teníamos planes de contingencia, con backups en múltiples sitios y rehacer prácticamente la infraestructura completa en 4 horas, como expliqué en el apunte. Lo que no pensábamos que podía ocurrir es que los 4 EBS (repito, vendidos como sistema de alta disponibilidad y persistencia) de una instancia fallasen al mismo tiempo, y que además Amazon fuese incapaz de recuperar los datos de 3 de ellos.
¿Que podríamos haber pensado que esto iba a ocurrir? Sí, por eso el plan de 4 horas máximo estimado.
¿Por qué no se pudo hacer? Porque nunca pensé se llegaría a este extremo, y en el peor de los casos posibles. Ese fue mi error.
Mi otro error es no haber dejado una «chuleta» para que podamos recurrir a una persona externa (Menéame no puede pagar otro sysadmin experto en Amazon AWS para hacerlo, ni Benjamí u otros admins se pueden dedicar a perder semanas para adquirir experiencia) pudiese hacerlo si yo no estoy disponible. Esto sí debe solucionarse, por eso anoche ya hablé con las tres personas más expertas en Amazon AWS que conozco (además son de Mallorca y amigos desde hace muchos años, Guillem Cantallops, Antoni Aloy y Bernardo Cabezas) para que puedan hacerlo ellos en situaciones de emergencia similares (que espero nunca ocurran otra vez, si no, es para dejar Amazon espantados y sin duda alguna).
Pero vayamos a la frase matadora que indica una carencia total de economía básica, de evaluación de riesgos y del sentido común más elemental:
la caida de abril no afectó a Netflix
¿Cuánto deja de facturar Netflix si está un día «offline»? La módica suma de 8.5 millones de dólares.
¿Cuánto deja de facturar Menéame si está un día «offline»? Con [mala] suerte, la impresionante suma de 500 euros.
Creo que no hace falta seguir discutiendo sobre la cantidad de dinero que puede u debe invertir una y otra, o la cantidad de servidores que tiene cada una, o la cantidad de expertos y contacto directo con Amazon que puede tener una u otra, o la importancia que da Amazon a una empresa como Netflix y a Menéame.
Independientemente de eso, está claro que Menéame tiene que invertir los mismos recursos que empresas como Netflix para asegurar el mismo nivel de disponibilidad </sarcasmo>
El siguiente punto:
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.
La primera parte propone tener el slave en otra región, sí, pero eso hubiese implicado un coste adicional de unos 200 € adicionales al mes si queremos que sirva de failback, y en este caso no nos hubiese solucionado nada, porque no hubo problemas con la base de datos ni con sus backups (que toman 110 minutos en recuperarse). Es decir, no es gratis, y no hubiese ayudado.
Sin embargo, sí estamos pensando (si seguimos en Amazon) en usar RDS con multi-AZ y failback automático. Eso rebajaría las dos horas de recuperación a unos pocos minutos, con un coste adicional de unos 300 € mensuales (pero nos quita todo el trabajo de administración de la base de datos y su replicación). A estos costes adicionales, si se quiere dar tolerancia a los servidores webs, hay que tener en cuenta el coste adicional de las instancias webs autobalanceadas que deben arrancarse al menos a pares en dos zonas diferentes, lo que implica un coste adicional de unos 200 € mensuales (estimación aproximada).
Sólo con esto ya subimos el coste de 1300 € al mes a 1800 €, con un sistema más complejo de administrar (lo que incrementa también costes). ¿Vale la pena hacerlo? Posiblemente, en eso estamos pensando, porque en esta caída, el sistema RDS con fallback automático (Multi AZ) también falló en muchas instancias.
Aún así, eso no hubiese solucionado el problema, y viene la segunda parte, el servidor NFS (que fue el fallo más gordo) con DRB. Dice:
duplicando la partición que exportas por NFS con DRBD basta. Económico y rápido de implementar.
Lo siento, pero no tiene idea de lo que está hablando. Es lo que tiene el hablar basado en el boca oreja sin experiencia.
Para tener una idea de la complejidad de montar un DRBD con múltiples zonas en Amazon, este documento, hecho en colaboración con gente de Amazon AWS (que lo ha «bendecido») Aún así, la arquitectura propuesta no soluciona el problema de que una zona completa quede fuera de servicio, como ha pasado. La solución que propone consiste de 2 servidores para el DRBD en distintas zonas, y un tercer servidor NFS que hace el failover. Ya hay un problema evidente muy relacionados: costes y mayores latencias.
El acceso a un fichero remoto implica el doble de tráfico por red (sin contar con el tráfico al EBS, que también va por red), del cliente al NFS y del NFS al nodo DRBD (además si está en otra región la latencia es mayor). Además la interface de red de cada instancia se comparte con las demás en el mismo hardware, por lo que van priorizadas según el tamaño de la instancia (y con una variabilidad enorme). Es decir, para aproximarnos al máximo al rendimiento actual deberíamos tener dos servidores adicionales de 200 € cada uno, 400 € más de costes mensuales.
Pero eso no es lo peor, si miráis la arquitectura, el punto de fallo sigue siendo uno, por lo que toca agregar como mínimo un segundo servidor NFS de 200 € al mes, e incrementar aún más la complejidad de la arquitectura y la dificultad de mantenimiento bastante elevada de hacer que las instancias «auto balanceadas» hagan el failover automático a otro servidor NFS. Aún así se podrían hacer trucos, como que las imágenes de arranque (AMI) o el «user data» sean diferentes para cada zona, y las instancias web usen siempre el NFS de su propia zona (lo que implica además inconsistencias temporales que hay que gestionar en la aplicación, i.e. modificar el código de Menéame para tenerlo en cuenta). Con estos «trucos» se incrementaría el coste en 600 € mensuales, por lo que estaríamos hablando de un total de 2400 €, y con un rendimiento NFS bastante peor.
Pero vale, supongamos es asumible. También supongamos que en el peor de los casos admitamos como admisible la inadmisible [pun intended] probabilidad de que estas caídas generalizadas ocurran una vez al año, y que puedan dejarnos 24 horas desconectados en el peor de los casos (que yo esté fuera, sin conexión, y que no haya nadie que pueda hacerlo).
Estaríamos pagando un sobrecoste de 13.200 € al año sólo en arquitectura (sin contar sobrecostes de administración)… para evitar pérdidas de 500 € en un sistema que no es crítico para nadie [*].
[*] Salvo para la salud de sus administradores, que sufren como condenados cuando no funciona.
¿Estamos locos? ¿De verdad que algún informático o sysadmin puede proponer algo así y quedarse tan ancho? Como informático, es algo que no puedo aceptar, todavía. Que profesionales no usen el sentido común para analizar las cosas en perspectivas, y no dejarse llevar por el hype o palabras mágicas que leen por allí. Administrar un par de ordenadores es una cosa, administrar una red con fuertes interdependencias entre componentes diversos, y con limitaciones de «distribución y consistencia» es algo completamente diferente. Por eso ocurren los desastres, sistemas carísimos de mantener, pero que al ser muy complejos fallan aún más si no se tiene un equipo de expertos que sean capaces de hacer un mínimo análisis de riesgos y costes.
Pero es lo que hay. Pero aportemos algo al tema, por si a alguien le sirve.
¿Cuál es la solución al problema de sistemas de ficheros replicados?
La verdad, y como me dijo hoy Guillem Cantallops después de discutirlo anoche, el panorama es bastante deprimente. Sencillamente compatibilizar alto rendimiento con replicación y coherencia es muy complicado. El NFS (versión 3, la 4 va bastante peor en latencia y tráfico) es el sistema de ficheros remoto con mejor rendimiento. Si tienes un sistema web con mucho tráfico y que hace varias operaciones stat() y open() para generar cada página, es la único opción si quieres hacerlo en el orden de centésimas de segundos, y ajustando bien los parámetros de cache en los clientes, por ejemplo como usamos nosotros:
nfs-server:/home /home nfs …, noatime, async, nocto, ac, acregmin=20
nfs-server:/cache /cache nfs …, noatime, async, nocto, ac, acregmin=30, acregmax=180
Si no tienes estos requerimientos de cache local y latencias muy bajas, puedes usar GlusterFS. Es una solución «limpia» y en user space, pero tiene su coste (además de los servidores adicionales), el rendimiento con los stat() y open() ni se aproximan al de un NFS bien configurado.
Si en cambio quieres reemplazar al NFS por un distribuido, la única solución razonable parece ser CEPH, pero el código todavía está en experimental y no todas las distros disponibles en AWS incluyen el módulo para el kernel. La última de Ubuntu ya las incluye, no así la LTS que usamos en Menéame (10.4). Pero es la opción que estoy estudiando y en poco tiempo haré mediciones en EC2 (aunque esperaremos por la siguiente LTS, 11.10, para ponerlo en producción, si lo hacemos).
Si no quieres recurrir a sistemas replicados para reemplazar el super fiable y eficiente NFS, ¿qué harías? Fácil y obvio, crear una imagen de arranque de una instancia preparada para servir NFS, tener varios backups e incluso regeneración automática desde S3. Todo eso lo teníamos, y cuando intentamos arrancar esa instancia, el snaphot estaba corrupto por otro bug que descubrieron durante esta última caída. Sí, me dio ganas de cometer las peores sodomías a los de Amazon, pero estaban lejos, y tampoco hubiese ganado nada.
Shit happens, ante emergencias en sistemas complejos es mejor dedicar la adrenalina en solucionar el problema que cagarse en los demás. Por eso mismo, por la complejidad a gestionar y el sentido común que se requiere, los buenos arquitectos y sysadmins ganan más que los programadores.
Nota: Si tienen problemas de fiabilidad de los EBS, la mejor solución es que Amazon implemente «Multi AZ EBS» similar a como hacen con las bases de datos en RDS. Si un EBS queda inutilizado, hacer el failover automático a la copia en otra zona. Es lo más limpio, y dado que lo han hecho con bases de datos, seguro que lo pueden hacer con los EBS.
Ricardo Galli, de software 
Pingback: Diseñar y administrar un sistema requiere mucho de sentido común, aunque no lo creas
Qué dices del punto 3?
Pingback: Lecciones que se pueden extraer de la caída de Amazon | La Pastilla Roja
/cry 2.0
Está más que demostrador que eres un gran programador y administrador. No creo que sea necesario que le demuestres nada a nadie porque todo el mundo conoce lo que vales.
Aplaudo todas las clases gratis que estás dando a los que siguen tu blog pero contestar así a un troll porque «un rayo» paró tu web 2 días me parece un poco exagerado.
Vanéale la IP y listo.
@Pepe
Ya está contestado en los demás. Todo lo no «replicado» es un SPOF, y si quieres eliminarlos, cuesta dinero, más complejidad y muchas veces menor rendimiento. Es lo que expliqué 😉
@zarza
No lo hice de cabreado, ni porque lo considere un troll. Simplemente porque era el súmun de mantras, mitos y falta de perspectiva bastante típica entre informáticos. Tampoco me tengo por qué banearle, ni considerarle un troll, más bien una víctima (del «hype»).
Muy bien contestado. Siempre hay listillos de este tipo que ante los problemas de los demás solo saben criticar y proponer tonterías.
en mi empresa tienen sistemas criticos y donde se pierde bastante mas dinero y quitando lo basico de redundancia y cosillas asi ya te puedes ir a zurrar mierdas como quieras pedir mas dinero para estas cosas.
«Total pa’ un par de veces que se cae en to’a la vida»
Clase gratis. Muchas gracias =)
He aprendido un monton de este articulo 😉 Gracias.
Mmm, facturando 500€ al día, ¿no da para contratar a un sysadmin de apoyo?
Otra cosa es que hiciese falta contratarlo por necesidad real, pero ¿por no poder pagarlo?
Está hablando de facturación, no de beneficios diarios. Aparte de que un sysadmin que domine AWS no aparece de debajo de las piedras.
Ricardo, espero que lo acontecido con Amazon en los últimos días no te hayan quitado las ganas de escribir ese libro que anunciaste por G+. Algunos lo esperamos con ganas.
@angelitomagno @Miguel Angel
Y eso en los mejores días.
Tampoco tiene sentido pagar a un sysadmin bueno (tiene que ser muy bueno), i.e miles de euros al mes. Como si fuese fácil hacerlo y cumplir la ley… porque Amazon te hizo una putada enorme.
Desde «fuera» todo se suele ver muy fácil, si en sistemas web las cosas siempre fuesen «2+2=4″…
Y más hablando de las complejidades de Amazon. Cuando las cosas se ponen mal, efectivamente, gestionar un sistema así no es como manejar un servidor dedicado al uso, gracias como siempre por la información aportada (en este y en el anterior post) y vaya, para echar un cable ya sabes donde estamos.
Un abrazo -;)
No hacen falta más explicaciones @gallir, meneame es lo que es y no necesita la extrema redundancia de otros sistemas de multinacionales que su volumen de negocio y clientes así lo requieren.
Gracias por los detalles y el análisis de lo ocurrido y de la infraestructura de meneame.
Los buenos sysadmins son los que con poco hacen mucho.
Un saludo.
Tras leer sólo la primera parte, en la que responde al comentario con los tres puntos, mi intuición (completamente indocumentada) es que posiblemente las ‘recomendaciones’ vinieran de alguien que no ha pagado ni ha gestionado la parte económica de un proyecto en la vida o que lo ha hecho de manera poco eficiente.
Has entrado en mucho detalle, pero el argumento de «si no sabes cuanto cuesta, no puedes proponer alternativas» me hubiera parecido suficiente.
Muy cuco el post, aparte.
* La primera parte propone tener el slave en otra región, sí, pero eso hubiese implicado un coste adicional de unos 200 € adicionales al mes si queremos que sirva de failback, y en este caso no nos hubiese solucionado nada, porque no hubo problemas con la base de datos ni con sus backups (que toman 110 minutos en recuperarse). Es decir, no es gratis, y no hubiese ayudado.
Quiza no me he explicado bien pero no me referia a montar alta disponibilidad con failback para toda la arquitectura sino a tener copia de lo esencial para levantar todo desde otra zona.
Un backup tarda 110 minutos en recuperarse desde un dump pero desde un snapshot son minutos. Échale un ojo a mylvmbackup.
* << duplicando la partición que exportas por NFS con DRBD basta. Económico y rápido de implementar.
* Lo siento, pero no tiene idea de lo que está hablando. Es lo que tiene el hablar basado en el boca oreja sin experiencia.
No hables sin saber. Administro una plataforma que tiene un NFS encima de DRBD y en los tres años que lleva en producción no hemos tenido ni un problema. Cierto, no es un failover de NFS sobre AWS y ni se me ocurriría pensarlo. Duplicando los datos a otra zona la caida no hubiera sido de dos dias y medio sino de horas, contando que estabas fuera. Es más, apenas deberias escribir en el NFS (imágenes, cacheo de las templates?) asi que el tráfico hacia la otra zona no deberia ser nada del otro mundo.
* Pero eso no es lo peor, si miráis la arquitectura, el punto de fallo sigue siendo uno
Falso. Tienes un par: NFS y MySQL (master). Si se cae el master se cae el site entero y tienes que conectarte para cambiar a mano el fichero de configuración para que apunte al slave. Si los tienes dimensionados como en el gráfico es mas que posible que la instancia small que te hace de slave no pueda con todo el tráfico que se come la large. Un consejo: si vas a hacer un plan de contingencia piensa en que pierdes máquinas enteras, no servicios.
Es posible que la caida de memcached degrade el sistema, quiza hasta el punto de tirarlo pero no tengo datos suficientes para asegurarlo. Tienes suficiente memoria para ello en el slave?
Por otra parte y, aunque no es crítico, si se cayese Sphinx deberias levantarlo a mano porque solo tienes una copia del índice.
* Si no tienes estos requerimientos de cache local y latencias muy bajas, puedes usar GlusterFS. Es una solución “limpia” y en user space, pero tiene su coste (además de los servidores adicionales), el rendimiento con los stat() y open() ni se aproximan al de un NFS bien configurado.
Cada herramienta tiene su uso. GlusterFS va de maravilla si aceptas sus limitaciones, también tengo experiencia en eso, dos años en producción. En el contexto que nos ocupa NFS encima de GlusterFS es una burrada.
—
En cuanto a costes, lo que propuse implica una instancia small (es solo io), un volumen EBS en otra zona y el tráfico. Serian unos 100 euros mensuales para levantar en otra zona a mano. Eso pondria los costes de meneame en 1400 euros, hasta los 12-15000 que debeis facturar, vale la pena.
Soy administrador de sistemas desde hace 29 años y siempre aplico los mismos principios y me ha ido bien:
– Sentido común
– Transferencia del conocimiento (KB)
– Backup y
– KISS ( Kepp It Simple, Stupid)
Los problemas ocurren y se trata de estar lo mejor preparados para solucionarlos.
José María
Este post me ha recordado tus clases de SO, ASO y ADSO 😉 Gracias por tu lección magistral Ricardo.
Un saludo y suerte con Menéame.
@Oriol: crees en serio q «pues a mi no me ha dado problemas» es un argumento?
Solo por cantidad de trafico no creo que puedas comparar ni en broma
Escribo bastante en DRBD, cuanto escribe meneame en el NFS? un iostat nos sacaria de dudas. Pero el caso no es el tráfico que soporta sino lo cercanos que estan los nodos entre si y lo fiable del link ya que en AWS la posibilidad de un split es mucho mayor y aun asi, bajo mi punto de vista, vale la pena. Otra vez: no estoy hablando de failover sino de una copia remota en «tiempo real» o con una latencia mínima. Como bien dice @gallir montario y administrarlo encima de AWS con failover es otra película, pero no hablabla de eso.
Me quedo con la parte del sentido común. En muchas instalaciones se ignora esa parte. Se invierte un verdadero dineral en soluciones de alta disponibilidad que a la hora de la verdad no son imprescindibles o son más caras que el trastorno que produce la no-disponibilidad.
En serio. Esa parte deberían incluirla en los planes de estudio .
@oriol
> Quiza no me he explicado bien pero no me referia a montar alta disponibilidad con failback para toda la arquitectura sino a tener copia de lo esencial para levantar todo desde otra zona.
Hombre, no, de estadística básica. Poner un servidor en otra zona diferente (i.e. un CPD) diferente *aumenta* la probabilidades de fallo (1/3 a 2/3 en el caso de Dublin) y no agregas redundancia (además de los fallos agregados por la interconexión entre CPDs). Es como proponer que monte un RAID0 para aumentar la fiabilidad. Si se hubiese caído el CPD donde está el NFS, y nos hubiesen arruinado la imagen de arranque de uno nuevo (que es lo que pasó), hubiésemos tenido exactamente el mismo problema: tendría que estar yo para arrancar una nueva desde cero, que es lo que hice.
Me parece que todavía no entiendes toda la cadena de lo que pasó, y porqué estuvimos 50 horas fuera (entre otras cosas porque las primeras 24 no podíamos hacer nada por fallo del API, ni teníamos información de qué estaba pasando).
> No hables sin saber. Administro una plataforma que tiene un NFS encima de DRBD y en los tres años que lleva en producción no hemos tenido ni un problema
Conviertes una anécdota personal en una regla. Yo llevo 20 años administrando sistemas y nunca se me jodierons 3 discos a la vez, ni nunca tuve un servidor caído más de 2 ó 3 horas. ¿Se te ha «quemado» el CPD donde tienes el servidor NFS? Porque sigue siendo tu punto único de fallo, aunque tengas los datos replicados. Para eliminarlo necesitas dos NFS, uno en cada zona (o CPD), y para disminur probabilidades deberían estar en la misma zona donde hay un nodo del DRBD. Si no, no sirve de nada el DRBD si el servidor NFS (y uno de los nodos del DRDB) quedan inutilizados.
Esta configuración mínima es la que deberías tener, y los costes que te pasé es para esto (y tiene problemas todavía, no es la más elegante).
> https://gallir.files.wordpress.com/2009/12/meneame-in-ec2-before.png
Falso. Tienes un par: NFS y MySQL (master).
…
> Si los tienes dimensionados como en el gráfico es mas que posible que la instancia small que te hace de slave no pueda con todo el tráfico que se come la large.
Antes de decir eso basándote en un diagrama de hace casi dos años, deberías preguntar. Ha cambiado mucho por el aumento de carga y optimizaciones. Entre otras cosas: son 2 servidores large, uno de ellos dedicado exclusivamente a máster de la BBDD, los DNS ya no lo llevamos nosotros, están en Route53, ya no hay dos balanceadores ni dos servidores web, están unificados y usando sólo nginx, etc…. cosas como esa ya están explicadas en https://gallir.wordpress.com/2010/05/12/cuando-el-problema-del-hardware-se-convierte-en-solo-de-software/ y otros apuntes, incluso pasé capturas donde se ven completa la arquitectura:
http://ow.ly/i/fFK1
> Es posible que la caida de memcached degrade el sistema, quiza hasta el punto de tirarlo pero no tengo datos suficientes para asegurarlo. Tienes suficiente memoria para ello en el slave?
El memcached no se ejecuta en ninguno de los servidores, sino en cada instancia. Pero aunque está configurado y funcionando, tampoco lo usamos, usamos la memoria compoartida del php5-xache que elimina latencias de red (y la variabilidad de la red en AWS). Lo pudes ver en el código de Menéame, que es configuirable para usar el memcached o xcache, i.e.:
$globals[‘xcache_enabled’] = true;
Aquí tienes la captura de las variables compartidas del xache de una instancia, que reemplazan al memcache:
http://ow.ly/i/fFLa
> Un consejo: si vas a hacer un plan de contingencia piensa en que pierdes máquinas enteras, no servicios.
Por eso la mayoría de servicios (como el memached + xcache, incluso el svn para el web) están distribuidos en cada instancia autoescalada.
Por otro lado, perder una máquina EBS en Amazon se arregla en 4 minutos máximo, se arranca otra instancia del mismo EBS… si no falla el EBS raíz. O lo puedes arrancar desde el AMI que has generado… si no te falla el AMI. Nos fallaron ambas soluciones, y no por culpa nuestra, ni está especificado en los servicios. De hecho aseguraban que el EBS tenía más fiabilidad que discos normales, similares a la de RAID por hardware.
> Cada herramienta tiene su uso. GlusterFS va de maravilla si aceptas sus limitaciones,
Es lo que dije, para Menéame no sirve, de hecho no nos sirve ni el NFS v4, con el que tuvimos problemas muy graves por saturación de interrupciones en el servidor (genera consultas por cada stat() y open()) y bloqueaba a los servidores web.
> también tengo experiencia en eso, dos años en producción. En el contexto que nos ocupa NFS encima de GlusterFS es una burrada.
No hablé en ningún momento de GlusterFS sobre NFS (sino sobre EBS).
> En cuanto a costes, lo que propuse implica una instancia small (es solo io), un volumen EBS en otra zona y el tráfico.
Las instancias small no soportan mucho tráfico, especialmente en horas pico o si tienes a otro servidor por lo que comentaba de la priorización de tráfico. También lo comenté, y es una de las mierdas con la que tienes que lidiar en Amazon.
De hecho, cuando ejecutamos comandos que procesas muchos ficheros tenemos que ir con cuidado, usamos mucho el ionice. Por ejemplo:
31 2 * * * sudo nice ionice -c 3 tar -cz -X meneame/backups/nobackups -f /mnt/backups/home.tgz /home/ >& /dev/null
(y poner el destino en un disco «local», que no va por red -el /mnt)
¿Te está quedando claro que no es tan simple y que tienes una idea errónea de cómo está la arquitectura? Pues eso, deberías preguntar los datos básicos antes de hacer afirmaciones tan bestias.
Nunca pierdo la oportunidad de aprender de otros sysadmins, porque mi profesión me lo exige, y cuanto más complejos son los sistemas con los que lidias, mayor es la exigencia y la necesidad de aprender y rodearse de gente que sepa…
dicho esto, se hace dificil el mantener la concentración de una lectura barnizada con la bilis del que la ha escrito. Seamos sinceros, como dice la mítica frase meneanta, gallir no acepta las críticas.
Amazon, Amazon, Amazon culpable… pero la mayor realidad es que de los más de dos días que estuvo caído meneáme, un día es imputable exclusivamente a ese SPOF que es gallir. Así de simple
Excusarse en el dinero que costaría otro administrador es eso mismo, una excusa, y al mismo tiempo otra muestra más de ego.
Administrar un sistema complejo del que dependen muchas personas o una web como meneáme requiere tanto de sistema común como delegación y colaboración.
Pero esa última parte pareces desconocerla, gallir.
@gallir, yo si fuera tu…bajaba todos los servicios durante 3 días de meneáme, con una página que indicara que estoy de vacaciones y por supuesto me iba de vacaciones.
Al volver, ¿qué sucedería? Pues nada, nada de nada, todo seguiría en su sitio…los tontacos en su sitio, lo que no somos tontacos y miramos de aprender en su sitio, los que dominais el tema en su sitio, todo en su sitio…
@astounding
Cuando escribo un apunte largo, justificando y explicando el porqué creo una opinión es errónea, en un lenguaje correcto, sin insultar a nadie, reconociendo mis errores y justificando cada uno de mis argumentos, pero me salen con el típico: «el ego, no acepta críticas, etc. etc…» estoy seguro se trata de https://gallir.wordpress.com/2011/04/01/resumen-de-estudio-de-las-discusiones-en-foros-y-twitter/
o simplemente de justificar la mediocridad e ignorancia propia.
Si además se repite -sin argumentar nada- «es tu culpa, Amazon no la tiene», estoy más seguro que se trata de lo segundo. En fin, pero me entristece pierdas el tiempo criticando a alguien que no acepta críticas, ni tiene idea de lo que habla 🙄
@gallir:
* Hombre, no, de estadística básica. Poner un servidor en otra zona diferente (i.e. un CPD) diferente *aumenta* la probabilidades de fallo (1/3 a 2/3 en el caso de Dublin) y no agregas redundancia (además de los fallos agregados por la interconexión entre CPDs). Es como proponer que monte un RAID0 para aumentar la fiabilidad. Si se hubiese caído el CPD donde está el NFS, y nos hubiesen arruinado la imagen de arranque de uno nuevo (que es lo que pasó), hubiésemos tenido exactamente el mismo problema: tendría que estar yo para arrancar una nueva desde cero, que es lo que hice.
El problema es que, por segunda vez este año falló EBS. No podias acceder a algunos de tus volumenes, entre los que estaba el del NFS. Otra vez: con una copia remota tendrias mas cartas en tu mano porque hasta el momento nunca han caido EBS en varias zonas simultáneamente. Puede pasar, claro, pero es difícil. Si cae el EBS de la copia remota, al fin y al cabo, no pasa nada. Si bien es cierto que no eliminas puntos de fallo estos no son críticos. Imaginalo como un backup del EBS, simplemente. Y si, tendrias que levantarlo tu, pero la caida hubiese sido más corta.
* Conviertes una anécdota personal en una regla. Yo llevo 20 años administrando sistemas y nunca se me jodierons 3 discos a la vez, ni nunca tuve un servidor caído más de 2 ó 3 horas. ¿Se te ha “quemado” el CPD donde tienes el servidor NFS? Porque sigue siendo tu punto único de fallo, aunque tengas los datos replicados. Para eliminarlo necesitas dos NFS, uno en cada zona (o CPD), y para disminur probabilidades deberían estar en la misma zona donde hay un nodo del DRBD. Si no, no sirve de nada el DRBD si el servidor NFS (y uno de los nodos del DRDB) quedan inutilizados.
Con el debido respeto, cuantos de esos 20 años has administrado sistemas a jornada completa? Los fallos en EBS no son nuevos y casi todo el mundo coincide en que es una buena práctica duplicar los datos (sea como sea) en otra AZ. El resto tan solo se queja de amazon y con razón.
Discrepo, no necesitas dos copias vivas. Mi propuesta era duplicar todos los volumenes EBS en otra AZ y en caso de caida levantar las maquinas en esa zona. Si consigues eso el único problema que tendrás es la latencia.
* ¿Te está quedando claro que no es tan simple y que tienes una idea errónea de cómo está la arquitectura?
Lo que dije inicialmente es una opción: tu crees que es poco fiable y yo creo que, aunque feo, hubiera minimizado el tiempo de caida sin suponer un coste enorme. Es una cuestión de puntos de vista.
Por desgracia para tu salud, es muy interesante que pasen cosas a alguien que sabe averiguar el porqué y el como solucionarlas 🙂
@oriol
> El problema es que, por segunda vez este año falló EBS
No en Dublin, sólo pasó en un CPD y no fue el mismo problema. Sí, mi error fue pensar que las probabilidades de que tengan otro problema eran aún más bajas.
Nota: los EBS son funcionalmente equivalentes al DRBD que dices es fiable, es un «raid por red», ni más ni menos. Si estás tan seguro que los EBS son males «per sé», deberías ir a revisar tu DRBD. En serio.
Nota: el problema es otro, y seguro fue humano, nada que ver con el rayo.
> con el debido respeto, cuantos de esos 20 años has administrado sistemas a jornada completa?
¿Empezamos con la de autoridad? Y tú ¿cuántos sistemas llevas administrando en AWS? Por ejemplo..
> Los fallos en EBS no son nuevos
Los EBS apenas tienen sólo dos años. Y el error mío fue fiarme en lo fiabilidad que ellos afirman. Si es un orden de magnitud mayor que la de discos (equivalente a raids potentes), esto no debería haber ocurrido, menos en el 75% de los EBS.
> Discrepo, no necesitas dos copias vivas. Mi propuesta era duplicar todos los volumenes EBS en otra AZ
Por amor de dios Oriol, ¡los datos estaban accesibles a golpe de clics! El que no estaba accesible para levantar esas instancias desde cero [*] era yo. ¿Lo tengo que repetir? ¿De dónde crees que salieron los datos si los EBS no se recuperaron y no se perdió ni una letra?
[*] Porque se cargaron también la imagen, y porque soy el único en Menéame que tiene experiencia en AWS. Ese «único» fue el error, no lo de no tener un EBS en otra zona, que no hubiese solucionado NADA.
* Nota: los EBS son funcionalmente equivalentes al DRBD que dices es fiable, es un “raid por red”, ni más ni menos. Si estás tan seguro que los EBS son males “per sé”, deberías ir a revisar tu DRBD. En serio.
No es comparable, el cable cruzado que conecta los dos nodos lo puse yo. Si lees la respuesta a jordi prats veras que soy perfectamente consciente de que no es una solución perfecta. El riesgo de split brains entre zonas esta ahi. Pero es mucho mejor que nada.
* ¿Empezamos con la de autoridad? Y tú ¿cuántos sistemas llevas administrando en AWS? Por ejemplo..
Buf, no puede ser que quieras medirtela. En fin.
* Por amor de dios Oriol, ¡los datos estaban accesibles a golpe de clics! El que no estaba accesible para levantar esas instancias desde cero [*] era yo. ¿Lo tengo que repetir? ¿De dónde crees que salieron los datos si los EBS no se recuperaron y no se perdió ni una letra?
* [*] Porque se cargaron también la imagen, y porque soy el único en Menéame que tiene experiencia en AWS. Ese “único” fue el error, no lo de no tener un EBS en otra zona, que no hubiese solucionado NADA.
Por pura suerte pudiste hacer los snapshots pero imagina que te fallan, como te paso en un caso.. que hubieses hecho? Y lo más importante, aparte darle acceso a otra gente, has pensado en algo técnico que hacer aparte de quejarte de AWS?
Joder, esto se alarga tanto que estoy apunto de dar la razón a Godwin.. xD
Sobre lo que comentas que lo unico que se pierde por dejar sin conexion un dia meneame son 500€, eso es simplemente el rendimiento que se puede sacar con publicidad, sumale usuarios que por esa caida dejarán de visitar el sitio o cambiarán sus hábitos, perdida de confianza usuarios, bajada en posicionamiento etc… creo que tendrias que multiplicar esa cifra x3 o x4 por cada día que meneme esté inaccesible.
Por otro lado en el tema de servidores que seas tu la unica persona con conicimientos para levantar meneame en un caso critico como este es el gran error quw has cometido. Yo administro servidores linux y nada que ver con la complejidad de sistemas como amazon con una curva de aprendiaje exageradisima, yo lo imtente probar y desistí justamente por esta complejidad.
Un saludo
@oriol
> Por pura suerte pudiste hacer los snapshots pero imagina que te fallan, como te paso en un caso.. que hubieses hecho?
No te equivoques, tan gordo (tampoco sé a qué caso te refieres que perdí datos):
http://twitter.com/#!/gallir/status/102030482929238016
http://ow.ly/i/fG7I
http://ow.ly/i/fG7L
Y estas son copias de backup en S3, que no tienen nada que ver con los EBS, y nunca han perdido un datos (también están muy replicadas).
Y estos están en un disco local, que tampoco son EBS:
$ ls -lR /mnt/backups/
/mnt/backups/:
total 210172
-rw-r–r– 1 root root 214993662 2011-08-12 02:32 home.tgz
drwxrwxrwx 2 root root 4096 2011-08-10 04:07 slave
/mnt/backups/slave:
total 1795900
-rw-r–r– 1 gallir gallir 1837191652 2011-08-12 04:17 meneame-2011-08.sql.gz
-rw-r–r– 1 gallir gallir 857 2011-08-12 04:07 meneame_slave_status
Es decir: los datos están copiados 4 veces, en 2 EBS diferentes, a un disco local y a S3. El código tiene 3 copias diferentes, una de ellas en EBS, otra en el EBS del svn, otra en casa (y varios ordenadores más que sincronizan). Las imágenes y avatares están en un EBS y con copia en tiempo real a S3.
No digas que es «pura suerte» cuando está bien, y sólo error mío cuando fallaron todos los sistemas que no dependen de mi, collons, que esto no parece diálogo de sysadmins.
@gallir
* No digas que es “pura suerte” cuando está bien, y sólo error mío cuando fallaron todos los sistemas que no dependen de mi, collons, que esto no parece diálogo de sysadmins.
No he dudado en ningún momento de que tuvieras backups y en el peor de los casos tendrias que haber reconstruido la plataforma a partir del último. Ahi pierdes datos (dependiendo de cada cuanto hagas backup) y un tiempo considerable de reconstrucción. Lo que está claro es que puedes vivir con ello, al fin y al cabo nadie muere si meneame se cae.
Aunque esto es un off topic creo que puede ser interesante.
Si decides dejar de trabajar de Amazone ¿Como te sales?
¿tienes oferta alternativa que cumpla las necesidades que tu tienes a un precio tan bajo como el que te ofrece amazon?
Volver a una plataforma «tradicional» te multiplicaría el presupuesto mínimo por 3 y al no poder «autoaprovisionar maquinas» creo que pocos ISP podrían seguir tu ritmo de trabajo.
¿Realmente tienes la posibilidad de dejar de usar amazon o estas condenado a seguir con ellos pase lo que pase?
Es complicado Amazon facilita muchos las cosas precio coste oportunidad
Yo no sé del asunto. Pero creo que Oriol es más troll que los trolls o no sabe de lo que habla.
Por cierto, realmente si meneame no tiene dependecía de un tercero más vale que no te calientes tanto la cabeza Gallir y por un día o dos sin meneame no creo que tuvieras que cogerlo tan apecho.
Por último indicar y espero que no este equivocado sino que me corrijan los expertos, que en los entornos web de alta disponibilidad y mucho tráfico siempre los problemas vienen por los la distribución de contenidos. Ya que no existen sistemas eficientes y simples que proporcionen redundancia y rendimiento en un contexto de alta disponibilidad (es decir, que los fallos que puedan existir no los note el usuario). Es decir, si quieres mejorar un parámetro lo más seguro que empeores otro.
Este comentario es sobretodo para gente que no entienda el tema que con tanta discusión técnica supongo que se ha perido.
Como puede ser que sin saber del asunto digas que soy un troll? He argumentado mis puntos de vista en todo momento y sin faltar al respeto a nadie. Mi sueldo no viene de especular con tonterias por internet sino de diseñar, implementar y administrar soluciones para entornos similares a este. A ver si os cae el mito: aqui no se ha inventado la coca-cola.
Lo mismo te digo me pareces un troll y es una opinión. Por lo tanto es mi opinión, si te gusta te la quedas y sino pues mira
La argumentación de lo que digo esta en este parrafo:
«No es comparable, el cable cruzado que conecta los dos nodos lo puse yo. Si lees la respuesta a jordi prats veras que soy perfectamente consciente de que no es una solución perfecta. El riesgo de split brains entre zonas esta ahi. Pero es mucho mejor que nada.»
Esto lo único que indica es que vas de sobrado y no haces O con un canuto.
O un troll a un flipado de la vida.
Mientras el gurú da la cara y muestra su estatura, usted es un simple nick con nombre común, que a mi humilde parecer solo dice gilipolleces, pero nadie te tiene por qué privar de decirlas, al y al cabo solo te perjudica a ti, que quedas en evidencia.
Tantos años en Internet y los que controlan siguen alimentado especímenes solitarios XDD
Y recuerda, la próxima vez hazte el interesante primero.
Otro nick anónimo mas de los que juzgan por Internet.
De sysadmin no entiendo ni papa, asi que todas las explicaciones a mi me suenan a chino avanzado… pero por el articulo anterior creí entender que el problema de Meneame caído durante 2 días fue que Gallir estaba de vacaciones, sin internet, en el medio de la nada, con la familia «a cuestas», o sea sin equipo, tiempo ni conexion para resolver los multiples problemas.
Pingback: de la red – 15/08/2011 | Notas tecnológicas
En realidad, precisando un poco noma, chino avanzado nivel 3 y me voy a la farmacia para comprar ibuprofeno 😥
Aunque, todo este lio me suena a que alguien del entorno cercano de gallir sabiendo que se encontraba de vacaciones y su status unplugged, se cargo meneame.net adrede.
Siento el off-topic, pero no me pude contener… con lo que le gustan a Galli los buenos tomates…
http://bit.ly/qHcHOY
Saludos.
Pingback: Peguntas y 10 puntos claves de Amazon EC2 « Ricardo Galli, de software libre
Pingback: De como un rayo se cargó una nube | Saasmania