Etiquetas
La primera vez que alquilamos servidores dedicados para Menéame fue en ThePlanet.com. Aunque funcionaba muy bien y no tuvimos problemas decidimos traerlos a España para mejorar el ping y apostar por hosting español. Así nos fuimos a Ferca, que nos atendieron muy bien y no tuvimos problemas hasta que fueron absorbidos por Acens. Allí cambió, a peor, con caidas frecuentes de la red, problemas con sus firewalls que bloqueaban conexiones, desaparición del servicio de emergencias, imposibilidad de ver nuestras estadísticas… y lo que colmó nuestra paciencia es que a pesar que nos cobraron religiosamente los meses de noviembre y diciembre no nos enviaron las facturas (aún esperamos respuesta).
El tema del hosting suele ser un dolor de cabeza, y si además necesitas una arquitectura sofisticada, o escalable debes sacar el talonario y prepararte a gastar dinero que desde mi punto de vista no tiene justificación. Como llevaba probando y «jugando» con Amazon EC2 desde hace tiempo decidí hacer pruebas. Después de horas de cálculadora y viendo que nos costaría sólo un poco más que Acens (pero menos que otras ofertas que recibimos) pero nos daría mucha más flexibilidad y fiabilidad decidimos hacer la migración.
La arquitectura básica es la que se muestra en la siguiente imagen (prohido reirse de mi dibujo a mano con la mejor voluntad y dedicación):
Actualización: Britxardo me envió un par de parches con los esquemas:
Tenemos dos servidores (instancias) permanentes, aws0 y aws1, y un número variable de instancias que sólo atienden a las peticiones web. Todos los servidores ejecutan Ubuntu Karmic, de las imágenes (AMI) oficiales de Ubuntu para EC2.
El kernel que se ejecuta en cada instancia debe ser compatible con el «anfitrión» de Amazon, Canonical tiene un convenio con Amazon para validar su kernel, que son mucho más modernos que otras distribuciones (estas imágenes –AMI– se encuentran en «Community AMIs» de EC2). También nos interesaba Ubuntu Karmic porque en la migración cambiaríamos el tipo de motor de la base de datos a MyISAM a InnoDB y la versión de InnoDB del MySQL 5.1 está muy mejorada con respecto a la 5.0 de la última Ubuntu LTS (08.04).
Servidor principal: aws0
Es el «servidor central», del tamaño large (m1.large) de 64 bits, cuesta $ 0.38 por hora, con 7.5GB de RAM y además la imagen está montada y arranca de un EBS (Elastic Block Service, un «disco persistente» con mejor rendimiento). Además de las ventajas obvias de persistencia de datos permite que en cualquier momento detengamos la instancia y la volvamos a iniciar con otros parámetros, por ejemplo más CPU y memoria RAM.
Los servicios que da este servidor son:
- Servidor MySQL: Aprovechando la migración hemos pasado a usar InnoDB y usar las transacciones/commit donde más hacían falta.
- Servidor NIS y NFS: Todo el software del Menéame y las cuentas de usuario están exportadas por NFS que son usadas por aws1 y las instancias web. Para centralizar la gestión de cuentas usamos el NIS.
- Servidor principal DNS: Es el primario de la zona meneame.net y notame.net.
- Servidor memcache: Usado por todas las instancias web.
- Servidor SVN para la gestión del software.
- Servidor SSH
- Servidor SMTP: Recibe todos los correos desde las otras instancias. Debido a las restricciones de Amazon EC2 para el correo saliente, todos los correos lo enviamos vía AuthSMTP (más adelante lo explicamos)
Teníamos muchas dudas de cómo se iba a comportar con carga real a la base de datos, y estamos gratamente sorprendidos, durante el funcionamiento normal no supera el 50% de uso de la CPU como se puede ver en la imagen (los picos de madrugadas son por el cálculo del karma y otras tareas como generación de «summaries»)
Mysql
Es fundamental la configuración mínimamente correcta del servidor MySQL, en caso de InnoDB es muy crítico el tamaño del buffer, como tenemos un total de 7.5 GB le asignamos 5 GB de RAM.
[mysqld] default-character-set=utf8 server-id=1 set-variable=max_connections=1000 set-variable=query_cache_wlock_invalidate=True table_cache=1024 innodb_buffer_pool_size = 5G innodb_flush_method = O_DIRECT innodb_flush_log_at_trx_commit = 0 innodb_additional_mem_pool_size = 16M innodb_log_buffer_size = 8M innodb_file_per_table = True join_buffer_size = 1M sort_buffer_size = 1M read_buffer_size = 1M read_rnd_buffer_size = 2M thread_cache_size = 64 thread_concurrency = 8 query_cache_size = 96M query_cache_limit = 16K query_cache_type = 2 tmp_table_size = 64M max_heap_table_size = 64M wait_timeout = 60
Servidor secundario y de backups: aws1
Esta es una instancia m1.small, de 32 bits, cuesta $0.095 por hora, con 1.7 GB de RAM, un sistema raiz de 10 GB y otro adicional (en /mnt) de 150 GB (ninguno de los dos es persistente)
- Secundario DNS
- Réplica en tiempo real de la base de datos (slave)
- Sphinx para las búsquedas
Esta instancia ya la teníamos funcionando desde noviembre como secundario DNS, ahora simplemente la reaprovechamos para hacer más cosas. Las fundamental es la réplica en tiempo real de la base de datos, que nos sirve para hacer backups a discreción sin afectar al servicio web, también lo usamos para muchos scripts de control que son «pesados» en consultas (en MyISAM era imprescindible hacerlo así porque bloquea todos los updates, con el InnoDB ya no se nota, de todas formas seguimo usando el slave para estas tareas).
También estamos usando (no acabamos de configurar todo) el S3Sync para hacer backups diarios a S3. El S3Sync emula de alguna forma el tradicional rsync, pero para trabajar sobre el sistema de S3.
Réplicas con balanceo de carga y escalado automático
Decidimos poner todo el servicio web en un sistema que se autoescale automáticamente, no sólo por la cuestión de precios sino por la tranquilidad que en momentos de mucha carga no habrá problemas de saturación (como nos ocurrió durante la Eurocopa, que tuvimos que montar un servidor adicional en EC2, pero al hacer réplica en EEUU de un servidor en España no iba muy fino por las enormes latencias).
La decisión fue poner todos los servicios web en una misma imagen:
- Apache con PHP para HTTP y HTTPS (puerto 80 y 443)
- Lighttpd para los ficheros estáticos (puerto 81)
Desde hace tiempo usamos mnmstatic.net como dominio para los ficheros estáticos, esto mejora la carga desde el navegador y evita que el navegador envíe los cookies de meneame.net [*] cada vez que se baja una imagen, en las pruebas que habíamos hecho se ahorra hasta 14KB de tráfico de subida en cada página.
[*] No son sólo los nuestros, que son sólo dos, sino también todos los que definen vía javascript los medidores como Google Analytics, podéis verificarlo en vuestros navegadores.
Cada instancia al arrancarse monta por NFS el directorio donde tiene acceso a todo el software y las imágenes (estáticas y dinámicas). Esto se hace el el fstab, pero hay que tener cuidado con las opciones, fundamentalmente la opción bg para que que bloqueada al arranque, y otras para aumentar la eficiencia y tolerancia a errores.
# /etc/fstab: static file system information. proc /proc proc defaults 0 0 /dev/sda3 None swap defaults 0 0 /dev/sda1 / ext3 defaults 0 0 /dev/sda2 /mnt ext3 defaults 0 0 x.x.x.amazonaws.com:/home /home nfs rw,bg,noatime,soft,nolock,intr,async,nodev,nocto,ac,actimeo=15 0 0
Balanceo (Load Balancer)
Como tenemos que balancear del puerto 80 dos tráficos diferentes (al Apache y al Lighttpd) tuvimos que definir dos baleanceadores diferentes (web-balancer y static-balancer). Cada balanceador te da una dirección IP y nombre DNS. Uno de los balanceadores –web-balancer– redirecciona a los puertos 80 y 443 y el otro –static-balancer– redirecciona del puerto 80 al 81 del lighttpd.
Para cada una de las réplicas elegimos primero el tamaño pequeño (m1.small), pero el primer día de funcionamiento (el lunes) y a pesar que durante las fiestas el tráfico es bastante menor que lo habitual vimos que el AutoScaler creaba cinco instancias para poder atender a la demanda, y durante las horas de menor tráfico no bajaba de dos. Me soprendió bastante, no esperaba que el consumo del Apache fuese tan elevado.
Me puse a estudiar y comparar con el vmstat, ví que las estadísticas del monitor de EC2 (CloudWatch) no se correspondían con estas. Investigando más me di cuenta del problema, el vmstat –al menos con el kernel de Ubuntu– no toma en cuenta la «capacidad» real de CPU asignada sino la del procesador. La asignada es un 40% de la total de la CPU (fácil de comprobar, se pone un proceso que consuma el 100% de cpu –por ejemplo yes > /dev/null— y se mira la columna idle del vmstat, en este caso el idle indicaba 60%).
Entonces tenía que buscar una solución más barata, y encontré una solución muy buena, bonita, potente y barata, usar una instancia orientada a CPU para el Apache. EC2 ofrece este tipo de instancias, las High-CPU Instances. Con la c1.medium y por sólo el doble de precio ($0.19/hora) podía tener una máquina con la misma memoria y algo menos de prioridad de E/S (que es muy poca, sólo los logs del Apache) pero con 5 veces la capacidad de CPU.
Así que reconfiguré el AutoScaler para que cree las instancias del tipo c1.medium y problema solucionado: desde que lo pusimos en marcha no ha creado ninguna instancia adicional, nunca superó al 80% de CPU:
AutoScaler
La configuración del escalador automático es casi lo último que se hace, necesitas tener definido los balanceadores y la imagen (AMI) que se usará para arrancar las réplicas. A diferencia de lo anterior, que se puede crear y modificar con la consola web del Amazon AWS, todavía no existe esa opción para el AutoScaler (aunque seguro que la agregan en las próximas semanas).
Por ahora toca hacer con los scripts, se necesitan definir tres cosas que están mostradas en el código de abajo:
# Crea la configuración para lanzar las instancias as-create-launch-config web01cpu --image-id ami-ami-d3fad1a7 --instance-type m1.small --group default,www # Define el grupo de autoscale llamado web-group # Se "conecta" a los dos balanceadores # Después de tomar una decisión no hace nada durante 180 segundos as-create-auto-scaling-group web-group --launch-configuration web01cpu --availability-zones eu-west-1a --min-size 1 --max-size 6 --load-balancers web-balancer,static-balancer --cooldown 180 # Define los parámetros para crear o destruir # Crea cuando consume más del 80% de cpu durante dos minutos # Destruye cuando baja del 30% as-create-or-update-trigger web-trigger --auto-scaling-group web-group --namespace "AWS/EC2" --measure CPUUtilization --statistic Average --dimensions "AutoScalingGroupName=web-group" --period 60 --lower-threshold 30 --upper-threshold 80 --lower-breach-increment=-1 --upper-breach-increment 1 --breach-duration 120
Con todo lo comentado anteriormente, esta es la situación habitual de funcionamiento del Menéame:
Para mostrar el funcionamiento del escalador puse la CPU de la instancia web al 100% (ejecutando dos yes > /dev/null para poner al 100% cada una de las CPU) para obligar a crear otra instancia.
Aquí se puede ver como el trigger indica HighBreaching, es decir que se superó el límite superior
$ as-describe-triggers web-group --headers TRIGGER TRIGGER-NAME GROUP STATUS NAMESPACE MEASURE STATISTIC PERIOD TRIGGER web-trigger web-group HighBreaching AWS/EC2 CPUUtilization Average 60
Aquí se oberva como la «capacidad deseada» es de 2 y que inició la creación y arranque de una nueva instancia:
$ as-describe-auto-scaling-groups web-group --headers AUTO-SCALING-GROUP GROUP-NAME LAUNCH-CONFIG AVAILABILITY-ZONES LOAD-BALANCERS MIN-SIZE MAX-SIZE DESIRED-CAPACITY AUTO-SCALING-GROUP web-group web01cpu eu-west-1a static-balancer,web-balancer 1 6 2 INSTANCE INSTANCE-ID AUTO-SCALING-GROUP AVAILABILITY-ZONE STATE INSTANCE i-04ef2c73 web-group eu-west-1a InService INSTANCE i-4e7dbe39 web-group eu-west-1a Pending
Finalmente las dos instancias ya están activas y accesibles:
$ as-describe-auto-scaling-groups web-group --headers AUTO-SCALING-GROUP GROUP-NAME LAUNCH-CONFIG AVAILABILITY-ZONES LOAD-BALANCERS MIN-SIZE MAX-SIZE DESIRED-CAPACITY AUTO-SCALING-GROUP web-group web01cpu eu-west-1a static-balancer,web-balancer 1 6 2 INSTANCE INSTANCE-ID AUTO-SCALING-GROUP AVAILABILITY-ZONE STATE INSTANCE i-04ef2c73 web-group eu-west-1a InService INSTANCE i-4e7dbe39 web-group eu-west-1a InService
Así es como se ve en la consola:
Problemas encontrados
Tuvimos dos problemas fundamentales.
HTTP SSL detrás del balanceador
El primero es que las instancias sólo «ven» la IP privada del balanceador y envía una cabecera HTTP para indicar la original, esto no ocasionó gran problema porque el software del Menéame ya estaba preparado. Pero con el SSL (o HTTPS) la cosa es muy distinta, en estos caso la conexión entre el balanceador y la instancia no es vía HTTP, sino TCP (por razones obvias, la comunicación va cifrada) por lo que no se recibe nada de información de la IP del cliente.
Esto obligó a modificaciones y agregar campos de control en los formularios de registro y login vía el servidor seguro. No fue nada importante, pero me obligó a pensar bastante en una solución razonablemente segura (digo razonable porque seguro que se le pueden encontrar problemas si se le dedica tiempo).
Envío de correo por AuthSMTP
El segundo problema fue inesperado y el que nos retrasó la migración del día sábado al domingo. El viernes recibimos un email de Amazon indicándones que estábamos enviando correo saliente (nuestras pruebas de envío de validación de cuenta y recuperación de contraseña) y que nos iban a bloquear la salida. Además vimos que agregan automáticamente nuestras IPs al Spamhause.
Aunque te envían el URL de un formulario para pedir la autorización decían que hay que esperar por lo menos dos días hábiles (hoy nos enviaron un email diciendo que ya estudiaron el caso y nos autorizan, pero las IPs siguen apareciendo en Spamhause). Fue un momento de depresión, además ví que es un problema en Amazon por las medidas que tomaron para evitar spammers en su servicio.
Pero encontré una solución buena, bonita y barata: AuthSMTP.
Por un precio muy razonable ellos se encargan de enviar el correo de tus usuarios o todo el dominio. Funciona muy bien y muy rápido, te olvidas del problema que las IPs de tus servidores de correo aparezcas en esas demoníacas bases de datos de spammers.
En nuestro caso la configuración del Postfix de aws0 fue muy sencilla, sólo tuvimos que agregar las siguientes líneas al main.cf:
relayhost = mail.authsmtp.com:2525 smtp_connection_cache_destinations = mail.authsmtp.com smtp_sasl_auth_enable = yes smtp_sasl_password_maps = static:USUARIO:PASSWORD smtp_sasl_security_options = noanonymous default_destination_concurrency_limit = 4 soft_bounce = yes
Con esto se solucionó el problema más grave que encontramos y pudimos hacer la migración.
Costes mensuales
- 1 m1.large: $ 273
- 1 m1.small: $ 64.8
- 1, 2 instancias c1.medium web de media (máxima): $ 164.16
- 2 TB transferencia de datos: $ 340
- 1 EBS de 50GB almacenamiento + aproximadamente 50 Mops= $ 11
- 3 instancias medias medidas con Cloudwatch: $32.4
- 2 Balanceadores: $40.32 + $16 de 2 TB de tráfico, $56.32
Coste total estimado: $ 941.68, al cambio actual del euro queda en 649 € mensuales
Fin
Sí, se pueden encontrar ofertas más baratas, y es un poco más de lo que pagamos a Acens (pero mucho menos que otras ofertas que recibimos), pero te olvidas de estar atado por una arquitectura, de tener que hacer engorrosas y largas negociaciones si necesitas un nuevo servidor, de abrir averías por la red (en Amazon está todo monitorizado y es público, una caída afecta a muchos servidores, así que no tardan nada en resolver).
Y lo más importante, es el futuro, mucho más sofisticado, pero también más divertido (y creo que además más ecológico, el hardware está mucho mejor aprovechado) y como administrador de sistemas/programador/CTO tienes una libertad y flexibilidad impensable hace pocos años.
Como conclusión, por ahora muy positivo. Ya veremos como evoluciona, conociendo la historia de EC2 no dudo que agregarán cada vez más servicios y que bajarán los precios una vez al año.
PS: Son las cinco de la mañana, lo publico como está, disculpad los errores que haya, ya los corregiré luego.
Ricardo Galli, de software 
Pingback: Cómo montamos Menéame en Amazon EC2
Justo hoy discutía con un amigo si eras un bot o realmente sigues a estas horas conectado por Twitter. Excelente artículo.
Un post la mar interesante que me ha entorpecido coger el sueño en un desvelo. Da gusto ver como se apuesta por arquitecturas del futuro de forma tan transparente. Esperemos que funcione como la seda ya que visto lo visto la flexibildad que dan es enorme (no me había metdo a mirar Amazon ec y me ha sorprendido), vaya, que tendiendo al cloud computing los hosting tradicionales se quedan cortos para muchas situaciones en las que el uso de CPu no es constante. Perdonen la ortografía, iPhone dixit.
muy bien, interesante post/articulo y muy útil.
Magnífico post, como todos los técnicos de Ricardo. En los de opinión no me meto, por algo son de opinión 🙂
¡Muchas gracias por compartir la experiencia Ricardo! Es un auténtico placer ver en funcionamiento el gran servicio que ofrece Amazon. Nosotros empezaremos a montar nuestra arquitectura en Enero y estamos deseosos de empezar a cacharrear 🙂
Es muy interesante y se nota la emoción en el relato, pero es carillo. Vale que es el futuro, pero hay soluciones libres que te puedes montar en un cluster en un cpd en España, puede no ser el de Acens, XD, y que son casi compatibles con el protocolo de EC2, al menos en el manejo de las instancias, y mas barato. Vale que ecológicamente está aprovechado al máximo en Amazon, pero si los micros no están a 100% tb consumen menos y el hard bueno es barato ahora mismo. Requeriría de una pequeña inversión en hard pero es algo que a bien seguro os podéis permitir y no dependeríais de nadie, y menos de Amazon . Cuestión de gustos supongo.
Salu2
Gracias por tomarte el tiempo de contar lo aprendido en la experiencia 🙂
No es «tan caro» como imaginaba pero da algo de miedo el depender del cambio dolar/euro.
También imagino que de momento no te planteas los costes con instancias reservadas, pero si todo va bien y os planteáis como «estable» esta arquitectura, la reducción de costes en las instancias fijas sería bastante.
Gracias de nuevo!
Gracias.
muy bueno! muy útil!
Muchas gracias por atender a mi petición (supongo que alguien mas te lo pidió)
Ricardo, ¿os habéis planteado el utilizar Amazon RDS? Lo único malo que veo es que las instancias no están disponibles en Europa, pero exceptuando esto… ¿qué otra desventaja habéis encontrado?
¿Qué tal el tiempo de respuesta de la arquitectura sobre AWS en comparación con la de Acens?
Ricardo realmente sorprendido del gran trabajo que has hecho :)) Amazon tiene mucho que decir a futuro y seguro que muchos copiarán (y están copiando) su modelo 🙂
Feliz navidad 😉
Pingback: Linkpost: Cloud computing en estado puro | Saasmania
Efectivamente, no es mucho más caro que un servidor dedicado «tradicional»; sin embargo podeís bajar algo la factura:
Si estaís contentos con Amazon, podeís pensar en utilizar una «instancia permanente» de EC2 para los servidores que vayaís a tener funcionando 24/7 durante un año y conseguís un 30% de descuento aprox.
Un apunt fantàstic Ricardo, gràcies per postejar-ho i per obrir camí.
Los costes mensuales de instancias se pueden reducir considerablemente comprando instancias permanentes anuales, ya que tienes histórico parece tener sentido. Por cierto, ¿Has conseguido que Amazon te pueda facturar como empresa y no como particular? Yo lo he dado por imposible.
Gracias por compartir
Muchas gracias por la explicación (se nota la experiencia).
Una pregunta que no me ha quedado clara desde el anuncio hace un par de días, y que ni Google ni los foros de AWS me han conseguido resolver es si Amazon garantiza “Safe Harbor” en las instancias de EC2.
Según el registro quedan cubiertos todos los servicios de Amazon (sin nombrar específicamente a AWS) y estándo los servidores en Irlanda técnicamente no habéis sacado los datos de la Unión Europea, pero me preguntaba si habíais tenido en cuenta la privacidad de los datos de los usuarios (yo no utilizo nótame y mi teléfono no lo tenéis, pero mi correo sí).
‘chas gracias.
YoNoSoyTu: que yo sepa, Amazon es «safe harbor»: http://www.stoel.com/showarticle.aspx?Show=1878
Nunca había pensado lo de utilizar otro dominio para los ficheros estáticos para ahorrarte la transferencia de las cookies (entre otras cosas), estais en todo.
Muy interesante la arquitectura usada para menéame.
Tengo algunas dudas:
¿La instancia es instantánea, arrancada desde un snapshot del SO o algo así o tienes que esperar a que se ejecute todo el proceso de arranque?
¿El cambio a InnoDB ha mejorado o empeorado el rendimiento, en general, de la base de datos?
Gracias!
Muchas Gracias Ricardo, todo este detalle va a ayudar mucho a la extensión de EC2 por aquí. Lo sigo viendo aún complejo para pequeños sistemas (no tocará seguir pegándonos con Acens y otros) pero a la que crezca un poco el camino lo tengo claro.
Un apunte interesantisimo Ricardo, de esos que ya se echaban de menos en tu blog. Muchas gracias por compartir vuestra experiencia.
De paso, aprovecho para preguntarte si habéis notado mucho el bajón de rendimiento al pasar de MyISAM a InnoDB. ¿Habéis pasado todas las tablas de un tipo a otro o sólo algunas?
Un saludo y muchas gracias de nuevo! 😉
Juan Lupión: Lo siento, el enlace que incluí ha desaparecido del texto.
http://www.export.gov/safehrbr/companyinfo.aspx?id=6162 es el registro de Amazon en el Departamento de Comercio estadounidense. Su registro Safe Harbor está en regla, pero solo comenta aspectos relativos a la tienda en sí (amazon.com), nada de los AWS.
Más abajo hay además una frase extraña: «Do you agree to cooperate and comply with the European Data Protection Authorities? No»
Sigue sin quedarme claro. Sería genial tener una respuesta en las FAQ de AWS, pero nada de nada.
Fua! Vaya apunte más rico! 😀 Me lo he comido letra por letra.
¿Qué tal una comparativa de rendimiento MyISAM vs InnoDB de postre?
En cuanto a la decisión de usar o no EC2, sigo pensando que tuvisteis una mala experiencia con Acens (yo también la tuve, aunque a menor escala) por lo burocratizado de sus procesos, pero que hay otros servicios de calidad mucho más ágiles y baratos (por unos 300 lo tendríais en hetzner.de, un Core i7 con 8GB = 49€/mes)
Aunque, visto lo visto, ¡Cojonudo! Nos has puesto un artículo de esos para meter en los bookmarks y leerlo cada vez que se quiera montar algo.
Muchas gracias.
@mikep
No queremos meternos en hardware, es otro mundo, muy duro, necesita de inversiones y mucho mantenimiento. Sobre el precio: las ofertas que hemos recibido para salir de Acens era más caras que la de Amazon y no tenían los mismos servicios ni de lejos
Nota: Arsys está ofrenciendo también servidores virtuales, pero no sé cómo funcionan.
@fernando serer @iñigo @pedrosp @iñigo
Si las cosas van bien y dicidimos quedarnos (eso parece por ahora) ya pagaremos las instancias.
@iñigo
Nos facturan normal, con el IVA.
@ariel
Sí probé el RDS, por ahora sólo en EEUU. Entre otras cosas es equivalente al que tenemos nosotros, al mismo precio y no tiene todavía funcionalidades de replicación.
Pero lo determinante fue que no hay disponible en Europa, y los pings con EEUU son muy altos.
@YoNoSoyTu
Sobre el tema del SafeHarbor, no tengo idea, ¿debería preocuparme?
Sobre la LOPD, aunque no soy abogado entiendo que Irlanda además de estar en la UE tiene los mismos niveles de protección que España (de hecho es uno de los que proponen el estándar internacional con España, Francia, etc..).
@nenillo
Las instancias se arrancan de un AMI que decidas, puede ser alguno de los disponibles o un personalizado. En nuestro caso es personalizado, por lo que arrancas una instancia, la personalizas y haces el «bundle» y lo registras como AMI.
@nenillo @skarcha
Me parece que el cambio a InnoDB ha mejora el rendimiento. De hecho se comporta mejor en tiempos de respuyestas cuando votas una noticia o comentario, pero no sé qué parte era problema de la red de Acens y cuál la de MySQL.
De todas formas, no sé por qué no lo hemos usado antes. Con suficiente memoria en general se comporta mucho mejor incluso para backups y los scripts del «backend» que hacen consultas pesadad.
Hola Ricardo, muy buena explicación. Creo que en los gastos mensuales te faltó incorporar el costo de AuthSMTP, que plan incorporaron?
Saludos
Impecable, gracias por compartir este tesoro de info!
Muy interesante, gracias por compartirlo.
IANAL pero según tengo entendido si quieres cumplir con la LOPD (y supongo que queréis), los sistemas de almacenamiento de datos (MySQL, memcached? y los backups) deberían estar garantizados como «safe harbor».
Como dices, los servidores están en Irlanda, dentro de la UE, y en teoría deberían cumplir las leyes de protección de datos europeas (y por lo tanto ser compatibles con la LOPD).
Podían ponerlo más a mano esta información, tanto Amazon como AppEngine no lo dejan muy claro (AppEngine al menos lo nombra en sus páginas).
Muchas gracias. Coincido en que la exposición de vuestra experiencia ayudará a expandir el uso de EC2.
Conocer vuestras decisiones a la hora de configurar mysql, nfs son de mucha utilidad.
Excelente artículo, Ricardo.
Un sólo pero a tu planteamiento. AuthSMTP es bonita y barata, pero ¿buena?.
He pedido recuperar mi contraseña en meneame a mi cuenta de hotmail y ¡me ha entrado en la carpeta de Correo NO deseado!
Eso quizá no te afecte en meneame, pero en otros proyectos web eso sería mortal.
Una pregunta que se me ocurre a bote pronto… ¿y google que piensa de todo esto?.
¿No serian capaces de ofrecer este servicio, incluso mejorado, mas barato que Amazon?, 7788 euros anuales es mucho dinero…
después de esto, sólo puedo decir una cosa…. «sólo sé que no sé nada» 🙂
@vicent
Debe ser que el anti spam de ONO es muy malo y ni siquiera verifica SPF. Mira las cabeceras de Gmail en un mail entrante:
Received: from outmail137140.authsmtp.com (outmail137140.authsmtp.com [62.13.137.140])
by gmr-mx.google.com with ESMTP id 11si1833375ewy.5.2009.12.30.04.18.08;
Wed, 30 Dec 2009 04:18:08 -0800 (PST)
Received-SPF: pass (google.com: domain of xxx@meneame.net designates 62.13.137.140 as permitted sender) client-ip=62.13.137.140;
Received: from mail-c193.authsmtp.com (mail-c193.authsmtp.com [62.13.128.118])
by punt7.authsmtp.com (8.14.2/8.14.2/Kp) with ESMTP id nBUCI8mN085316
for ; Wed, 30 Dec 2009 12:18:08 GMT
Magnifico aporte, para la comunidad Hispana, mis mejores deseos son que todo resulte como se espera para tener mas opciones cuando de encontrar un buen servidor se trata.
Adelante y Feliz Año Nuevo
Carlos Arredondo
http://www.decideganar.com
Una muy buena explicación, una tecnología muy interesante.
Agradecerte el currazo de escribir este post la verdad que es muy claro y conciso. Por otro lado me parece que es un salto muy importante que un proyecto como meneame plantee soluciones tan innovadoras, en lo que respecta a su infraestuctura
Espero que estas migraciones les cuestione en alguna medida la forma de funcionar a las empresas de hosting clásicas.
Como ejemplo Arsys ha puesto un sevicio cloud. No se puede ni comparar con respecto a Amazon. Con decirte que hasta hace cosa de 2 meses no se pueden gestionar las instancias mas que con Windows xp he internet explorer 6 (solo hay un plugin activeX)
Lo único como ves el riesgo de concentración de «poder» que pueden generar estos servicios?
Sea como sea gracias por molestarte en contar vuestro trabajo a mi me va a servir para empezar a plantearme Amazon.
Cachis… ¡así que censurando el humor!… claro, psicológicamente leemos prohibido pero pone prohido, es decir, está prohibido reirse del dibujo pero no lo está «en el sentido estricto». 😀
Por el resto, es muy valiente hacer una publicación de los grandes rasgos de las infraestructuras de vuestros servicios… Mis felicitaciones por ser tan abiertos.
Y lo de «Safe Harbor» sólo os debería preocupar si tenéis gente que os quiera mal. 🙂
aa
Es que App Engine es totalmente diferente a lo de Amazon.
La ventaja es que la escabilidad es de «grano fino», no pagas por instancias, sino por recursos utilizados. No tienes que preocuparte de balancear, ni de que quedas sin memoria RAM, ni que el almacenamiento no es permanente. De todo ello se ocupa Google.
Desventajas: has de acomodarte a lo que ofrece google: su SDK con Python o Java y su Sistema de Bases de Datos, que no es relacional. Por tanto, migrar una aplicación no es trivial.
Vaya, un gran articulo del que se puede aprender mucho. No te tenia en mucha estima como censor pero te acabas de ganar mi respeto como sysadmin.
Ademas me ha sorprendido el coste de alojamiento que esperaba muy superior (concretamente un par de ceros mas) y la arquitectura (tambien esperaba mas maquinas).
Recibe mi mas sincera felicitacion por una migracion de esta envergadura sin incidencias y tomate una birra de mi parte que te la has ganado 😉
Muchas gracias por compartir estos datos con nosotros.
Felicidades Ricardo por el cambio y buen año.
No dudo que en la nube está el presente y futuro inmediato de la «computación» y gestión de datos, ya lo decía Pau y como el muchos otros que lo vaticinaban tiempo atrás cuando era mas una cuestión de estar que de tener los datos en la red. Yo sigo aferrado a lo tangible y miedo me da esa gestión de altos vuelos y de la volatilidad de los datos.
Te leo de cuando en cuando mr. Galli, aunque desde que me negaron la existencia en meneamé.net pasaste al lado oscuro de quienes sigo, no se porque tengo esta tendencia a poner rostro a las frustraciones.
Me ha gustado tu artículo y celebro que a altas horas estés en el mundo de los conectados.
Saludos y no creo que de momento me atraiga la nube, aunque hasta Panda apueste ya por ella. 😉
Fantástico post. No entiendo como los ISP Españoles no se ponen las pilas. Lo de ACENS es de juzgado de guardia, yo tambien lo sufro. FERCA!!!! por que os dejasteis comprar… con lo bien que funcionabais. 😦
Aunke te parezca mentira, acabas de encontrar la solución para un problema casi idéntico ke tengo yo. Me ha molado el dibujo a mano, ¿por ké iba a reirme?, tengo muchos de esos, incluso en servilletas de papel :D.
El tema de la latencia es serio, he probado con grandes servidores ke por lejanía daban malos resultados desde España pero no dudes ke probaré Amazon. Igualmente ke tu tuve ke migrar desde acens (tras ferca) por problemas idénticos (y mas). Ahora tengo montado algo parecido con ovh, ke dispone de datacenters en españa (madrid) aunke es una empresa francesa.
Ante todo gracias por tus aportaciones, no dejes de escribir. TE NECESITAMOS.
Gran articulo. Prove AWS por junio y no tenia ni la mitad de funcionalidades que tiene ahora, solo lo usaba de VPS. Dentro de poco tengo que montar una infraestructura minimanente grande y me interesan los temas que has tocado.
Una duda respecto al autoscaler. Ya que cobran por horas. No sería recomendable, antes de parar las instancias, algun tipo de control para comprobar el tiempo que han estado levantadas?
Es decir, si levantas una instancia 5 minutos, pagas lo mismo que si la levantas 50. Por lo tanto, no la apagues hasta que vayan a cobrarte la 2º hora.
a pesar DE que nos cobraron. Se dice a pesar DE algo, no a pesar algo. A pesar algo vas a la báscula.
Pingback: Cómo montamos Jonéame 2.0 | Jonéame
@kadekilo
OVH no dispone de datacenters en España. Como mucho te dan una IP failover geolocalizada en España.
Pingback: Top Posts — WordPress.com
Excelente artículo, Ricardo.
Sólo una duda: Si ya estáis usando lighttpd para servir contenido estático… ¿Por qué no usarlo también para el dinámico?
¿Os ha dado mejor resultado Apache? ¿Os ata algún tipo de tecnología como SSI o htaccess?
Gracias. Abrazos.
Ah, si, otra cosa:
No entiendo a qué te refieres exactamente cuando dices que «la conexión entre el balanceador y la instancia no es vía HTTP, sino TCP (por razones obvias, la comunicación va cifrada) por lo que no se recibe nada de información de la IP del cliente».
¿En HTTPS no hay info de la IP de cliente? ¿HTTP no funciona sobre TCP también? Son capas diferentes.
¿Se cifra sólo hasta el balanceador o hasta el apache?
Gracias por tu tiempo. Abrazos.
@queru
1. Sobre lighttp: lo que más gasta es la ejecución del PHP, no hay diferencias si los mides. Por otro lado se desarrolló y ajustó sobre Apache y algunas de sus características (como los el módulo de rewrite). Para cambiar de Apache a otro debería aprender y probar cosas nuevas, para no ganar nada (o muy poco).
2. En el caso de HTTP el balanceador hace de proxy a nivel HTTP (i.e. modifica cabeceras http). En el caso de HTTPS el proxy es a nivel TCP y por lo tanto el servidor no se entera de la IP del cliente. Como es a nivel TCP el cifrado es hasta el Apache, el balanceador sólo replica.
@paco ros
Después de varios días puedo decir que el InnoDB va muy bien, igual o más rápido que el MyISAM (se nota que no hay «row lock»).
Por otro lado, sí, puedes conseguir más barato, pero si empiezas a pedir IP privadas, balanceadores, agregar o actualziar servidores ya empieza a ser complicado/burocrático o muy caro.
Genial, de verdad, aunque el servidor de subversion ahí entremezclado me daría mal rollo.
Otra cosa, los esquemas en servilletas son los mejores, las mejores ideas surgen en un bar con un café caliente.
Muy intereante…
Gracias
Pingback: Week-Log.346 « RSS2Blogs
Ricardo, excelente articulo. No se si evaluaste otras alternativas de SMTP como SendGrid. Puedes obtener tus propios IPs sin tener que depender en la reputacion de otros o ser afectado por lo mismo.
Interesante artículo. Tuve el mismo problema de envío de emails que comentas. Evalué authSMTP pero al final opté por http://sailthru.com/ ya que el servicio que dan es mucho más seguro contra el spam. Escribí sobre mi experiencia con ellos aquí: http://ieyara.blogspot.com/2009/06/spam-un-problema-no-deseado.html
Gracias por mostrarnos las entrañas del EC2 a los que no tenemos tiempo/ganas de investigar por nuestra cuenta.
Buen artículo!!
Una duda, por lo que dices entiendo que lo montas a partir de las AMIs «oficiales» de Canonical, no?
http://uec-images.ubuntu.com/releases/karmic/release/
Luego hablas de que «…además la imagen está montada y arranca de un EBS…»
¿Cómo es posible? las AMIs de Canonical son Instance-store ….
Igual te lo has hecho «a mano», alguna URL al respecto? 😉
gracias!!
@aloygbm
Arrancas el AMI en una instancia normal, y allí creas la imagen para un EBS. Hay varios tutoriales, ya ni recuerdo cuál he usado.
Buenas gallir,
Me gustaría discutir/conocer algunas cosas de tu infraestructura.
1. Me he fijado que las maquinas están desplegadas en EU. Esta claro que Meneame esta destinado a usuarios hispanohablantes y supongo que muchos de ellos se encontraran fuera de Europa/España. Si lo que buscáis es velocidad el peering es algo importante.
2. ¿Lighttpd para los estaticos?. Creo que eso es un punto importante a mejorar. Lo ideal seria que usarais el servicio S3 de Amazon para contenido estatico. Es más rapido, es un frontal Web distribuido (¿peering?), solo pagas ancho de banda y te quitas consumo de CPU/Memoria/Disco/Mantenimiento del servicio y es más escalable sin necesidad de que hagas nada más que pagar el ancho de banda. Soporta ACL, subdominios. Ideal + CloudFront.
3. NFS. Habría que ver las medidas de seguridad que usan en EC2 para la aislar las maquinas. Yo personalmente no me fio de protocolos en texto plano y más si estas compartiendo ficheros importantes (configuraciones, usuarios/claves..).
4. Rsync no emula realmente el protocolo Rsync. Es una pena no poder usar Rsync con S3, aunque hay empresas que ofrecen un servicio «similar» Rsyncs3.com por ejemplo.
5. Replicas MySQL Master-Slave. ¿Usas cifrado en las replicas?. ¿Como gestionas los errores en la replica?. ¿Has probado maakit?. Es importante monitorizar esto.
6. ¿Todos los servicios críticos corren solo en Amazon?. ¿Existe alguna replica fuera de Amazon?.
7. Me gustaría conocer como gestionas los parches de seguridad y actualizaciones en tu instancia. Es algo problemático ya que requiere ir creando nuevas AMI cada muy poco tiempo. Sobre todo y como mencionas siempre es importante usar imágenes oficiales ya que se suben muchas que no lo son tipo LAMP y nadie ha comprobado si hay rootkits, etc.
8. mnmstatic.net ¿Esto no afecta al posicionamiento?. Parece una chorrada y tal vez lo sea pero es bueno plantearselo.
9. ¿Solo es necesario escalar servicios Web?. ¿Como lo harías con MySQL? ¿Mas Slaves? ¿Y las Escrituras?.
10. Monitorizas las 4 CPU de tu maquina Ubuntu ¿y de tus instancias? ¿El monitor solo da el AVG total no?. ¿Monitorizas los servicios? (Consumo de CPU, Red, Memoria, Disco..).
Gracias por tu tiempo :).
1. Me refería para la gente de fuera de Europa también. Sobre todo si enfocas un servicio Global.
2. Comparas una instancia + Nginx con el servicio S3 + CloudFront (si, seria bueno este como CDN). Las imágenes son pequeñas lo se, aún así es bueno optimizar al máximo. Pagas por eso mismo, por tener muchos frontales en un único servicio, con EC2 no lo tienes en una única instancia. La API de S3 es muy sencilla, incluso hay bastantes librerías para java, python, php, perl, etc.
3. Aisladas dentro de la misma maquina física por software.¿no?.
4.Cierto esta enfocado a peticiones, pero el precio es mínimo.. Perdon la web es http://www.s3rsync.com. (real parcial file transfer, Preserve file permisión, preserve synbolic links) Cada hora de Rsync cuesta 0.05 US$.
5. No sale por internet pero si se mueve por la red de Amazon donde hay muchas mas maquinas y clientes. Es importante el cifrado. Prueba las utilidades de maakit para monitorizar replicas, sincronizar tablas, etc.
6. ¿Y si se quema el datacenter? ¿Un empleado molesto le da una patada a la fibra?..
7. ¿Algun Firewall de aplicaciones Web?¿IDS?
8. No dudo en cuanto a la carga, pero me refería si no es mejor usar un subdominio.
9. Interesante, ¿Has probado drbd, Heartbeat, HAproxy ClusterFS?
10. Puedes usar el report de EBS para crearte una gráfica RRD, es cierto que aun esta todo un poco en estado beta..
Añado una pregunta más 🙂
11. ¿Tienes contratado soporte o te conformas con el soporte online en los foros?
De nuevo, gracias por tu tiempo 😛
@francisco Alonso
Mis respuestas:
1. Sí, era importante y las de EEUU tienen un ping bastante más elevado con Europa.
2. Ya hemos cambiado todo a NGinx + php-cgi: https://gallir.wordpress.com/2010/01/02/cambiamos-de-apache-y-lighttpd-a-nginx/ El renidmiento es el mismo, pero simplifica. Respecto a S3, al tener la instancia dentro de EC2 no le veo la ventaja, salvo pagar un poco más. Tendría sentido si la usásemos como CDN, pero dado que tenemos imágenes pequeñas no tiene sentido. Por otro lado la gestión por software sería algo más compleja.
3. Las máquinas estás aisladas entre clientes diferentesm y entre máquinas de la misma cuenta que no pertenezcan al mismo grupo de seguridad.
4. Por eso puse explícitamente «de alguna forma». Pero está bien para su cometido, el ancho de banda desde una instancia EC2 a S3 es muy alto, y no cobran tráfico. Además la facturación del S3 está oriendado a peticiones, no sólo que haría imposible un rsync «completo», sino que costaría mucho más.
5. ¿Para que cifrado si va por red «privada»? El tráfico no sale en ningún momento por Internet. No he probado Maakit, gracias por la info (por ahora lo hacemos simple: nos daremos cuenta que falla la réplica porque no funcionará el buscador ni recibiremos el correo periódico de reportes. Por otro lado hacemos backups frecuentes con información de estado del máster y del slave).
6. Todo está en Amazon, salvo el nagios que monitoriza desde fuera.
7. Sí, tienes que crear nuevas AMIs, pero lo tengo casi automatizado y es rápido. Afortunadamente desde la instancia sólo tenemos expuesto el puerto 80, que es un NGinx que no tuvo actualizaciones durante semanas. Luego el kernel tampoco tuvo ninguna, ya que es un kernel mínimo para ejecutarse sobre el anfitrión.
8. No, no afecta para nada, ahorra tráfico y carga más rápido en el navegador.
9. Por ahora el servidor de la bbdd no supera el 30% de uso, así que puede crecer bastante. Para crecer tenemos dos copciones:
a) Cambiar una opción del Menéame para que use slaves para las consultas y el master para las actualizaciones (ya lo usamos antes y funciona)
b) Escalar verticalmente a una instancia más grande, sólo hay que parar la instancia (es una sobre EBS) y arrancarla nuevamente.
10. El monitor te da de CPU, tráfico de red y operaciones de disco (salvo las de EBS que todavía no las da).
@francisco
1. El 80% del tráfico de menéame está en Europa.
2. CloudFront es un servicio adicional. El menéame funciona hace tiempo con S3 (lo hizo/usa Chuza) pero no le veo sentido, agrega complejidad y «demoras» para actualizar los avatares, por ejemplo. Aún así no se descarta.
3. Eso aseguran. Y en nmaps de prueba no puedo encontrar nada en el «vencidario».
5. Para que el cifrado tuviese algún sentido (dentro de Amazon) debería cifrar hasta el sistema de ficheros y la RAM. No veo el coste-beneficio, aunque cifrarlo a S3 es sencillo.
6. El EBS del servidor de base de datos ya está replicado y te ofrecen alta disponibilidad/fiabilidad. Además tenemos backups diarios en el disco de otra instancia (vía rsync y mysqldump), y luego a S3 (también diario).
7. El acceso web se hace a través del balanceador de carga, las IPs de estos servidores no están «publicadas». No teemos control sobre el balanceador más allá de especificar los dos puertos que admite y redirecciona.
8. No, es mejor un dominio diferente para evitar el tráfico de las cookies que comenté en el apunte. Hasta Google lo recomienda, mira el dominio de sus imágenes estáticas (creo que era gstatic.com).
11. Por ahora ni siquiera necesité el soporte de los foros. Tuve una sóla duda que pregunté en el foro y me autocontesté a la media hora.
1. No te olvides de ese 20% si quereis que meneame no sea tan solo español y se posicione/de un servicio mejor fuera de EU.
2. ¿Demoras en que sentido?
3. Un Nmap tampoco muestra datos de una Vlan :). Prueba Yersinia (http://www.yersinia.net/). Me refiero a que alguien dentro de esa red puede capturar trafico y el tuyo esta en texto plano. No tiene porque ser EC2, lo mismo acceden a una maquina que no es una AMI.
5. cifrar el disco y la ram seria nada ya que tendría que ser admin de tu maquina y ya entramos en cosas mayores. Eso es comprensible y mas complejo para un atacante, pero conseguir acceso a una red lo veo bastante más sencillo.
6. No me refiero a alta disponibilidad y redundancia de datos, me refiero como método de obtener replicas en tiempo real sin usar maestro-esclavo/esclavo.n
7. El firewall de aplicaciones puede estar en la misma maquina haciendo de proxy inverso. El balanceador da igual.
8. Gracias por la info 🙂 me lo anoto.
11. En eso estamos de acuerdo hay mucha documentación y las dudas suelen ser más bien errores propios en las AMI. Pero también se ha visto el caso de Volumenes que se han perdido, instancias que se han terminado, etc.
6. Con drbd puedes escalar y te ahorras muchos de los problemas que solo se pueden solucionar a mano haciendo master-slave/slaves. Perdidas de sincronismo, incoherencia de datos..
7. Complicarse es aprender y mejorar :). Un firewall de aplicaciones funcionando como un Proxy Inverso, no me refiero para balancear peticiones HTTP. Hay bastantes : mod_security, Lighttpd+ mod_magnet.. (Sorry por la URL->http://www.securitybydefault.com/2010/01/mas-alla-del-ips-waf-web-application.html). Es bueno añadir capas de seguridad.
2. Cuando se actualizan avatares se graba inmeditamente y está disponible, con S3 hay que hacer las llamadas y verificaciones de que existe. Con el update del subversion está todo disponible, con S3 deberíamos hacer script para sincronizar lo estático.
6. No entiendo, hablabas de réplica fuera de Amazon luego de si le dan una patada al disco…
7. Tienes tendencia a complicarte la vida, ¿para qué hacer eso si no necesitas? ¿para qué proxy inverso si tienes un balanceador? (que además es «mandatory» para el escalado). Recuerda, KISS, aunque sea guapo trastear 🙂
Siento ser pesado 🙂 pero te paso algunas URL :
Algo sobre drbd y sus diferencias con la replicación y cluster internos de MySQL :
http://dev.mysql.com/doc/refman/5.1/en/drbd-mysql-replication-scale.html
http://www.mysqlperformanceblog.com/2008/04/28/mysql-replication-vs-drbd-battles/
Algo sobre Multimaster MySQL (Yo no lo usaría pero te lo paso)
http://mysql-mmm.org/
y también algo sobre Nginx + Memcached :
http://www.igvita.com/2008/02/11/nginx-and-memcached-a-400-boost/
De paso te comento algo más :
– Cambiaria Subversion por Git, es más rapido, reduce espacio en disco y trafico de red (así te ahorras dinero), mezcla ramas, historio de ficheros… Mejor echale un ojo a esto :http://git.or.cz/gitwiki/GitSvnComparsion
PS: Gracias por lo de twitter 🙂 ahora toca escribir una entrada del tipo «¿Como mejoraríais la infraestructura de meneame?». Seguro que todos aprenderíamos bastante. Y lo siento, soy Admin de sistemas y como tal doy por culo.
6. No he dicho por fuera de internet, digo a nivel escalar para no usar replicas slave. Te repito que no quiero un raid ESB :), hablamos de nodos disponibles para escalar no de replicas de disco para asegurar los datos, ya se que eso te lo «garantiza» amazon en los ESB. Si tu quieres centralizar todo en Amazon, y quieres escalar MySQL o al menos tener una infraestructura de fácil escalado creo que la opción más segura y cómoda es drbd. Como tu has dicho las replicas fallan y hay que arreglarlas a mano. ¿Estas disponible 24h/365d? la solución no es reparar rápido un problema, es que no exista dicho problema y si existe que sea transparente para el usuario y te de una franja de tiempo para trabajar.
7. La probabilidad de fallo que he puesto creo que es mínima en cualquier sistema donde quieres proveer un servicio continuo. Esta claro que podemos añadir capas de forma infinita, pero estas capas son fundamentales.
Eso es un grave error, Nginx como cualquier otro programa tiene bugs y pueden ser explotados/vulnerados y debe tener su capa de seguridad. En este sentido por ejemplo Mod_security es capaz de detectar/parar/alertar de un Buffer Overflow, inclusión de ficheros remotos, ejecución de código, inyecciones SQL, etc. (http://www.buayacorp.com/archivos/sql-injection-en-meneame/). ¿Como esto no aporta seguridad? ¿security theater?.
El uso de un firewall de aplicación Web es casi transparente para un uso normal de cualquier sitio. Se deben ajustar reglas, por lo demás claro que añade una capa de seguridad. Y no hablamos de Modulos de terceros sin soporte y que no deben estar en producción. El consumo de este tipo de capas no es más que un modulo de rewrite como el que antes usabas en apache. Obviamente con las reglas justas y necesarias.
En ningún momento he hablado de hacer hardening (http://en.wikipedia.org/wiki/Hardening) del sistema operativo. Esto claro que es mas complejo y requiere un trabajo muy dedicado. Un claro ejemplo es este, Inmutable Services Containers de OpenSolaris : http://kenai.com/projects/isc/pages/OpenSolaris . Esto requiere de un mayor consumo y va en relevancia con la seguridad necesaria que requieren los servicios que ofrece. ¿Meneame los requiere? Yo creo que un mínimo de seguridad al menos en sus servicios sí. Siendo un portal de noticias importante como es hoy en día, maneja una información que puede ser alterada para beneficio de personas/empresas. – La información es poder – .
Muchas cosas a veces pueden parecer «chorradas» como este http://www.securitybydefault.com/2008/11/meneame-insecure-by-default.html . Que un nombre de usuario de Meneame sea el mismo que usa para identificarse a simple vista no parece «malo». Pero si alguien decide enumerar usuarios y si encima como es muy común esos usuarios usan claves típicas.. Una votación «falsa» es sencilla y rápida. Con el Firewall de Aplicación Web podrías haber detectado eso en tiempo real, tal vez si aporta algo de seguridad al final.
Al final es eso, la relación calidad-precio. Meneame no es un banco pero si un referente de noticias diarias y como no uno de los portales más visitados. Por lo tanto porque no un mínimo de seguridad y fiabilidad de servicio.
Ahora te contesto :
@gallir : No existe la seguridad absoluta. La “seguridad” es un proceso donde impera el coste-beneficio.
– Claro que no existe la seguridad absoluta, ni el conocimiento absoluto. Pero solo el adquirir más conocimiento te pondrá un paso por delante.
@gallir: Los “security theater” sólo cuestan dinero.
Una mala publicidad cuesta aún más dinero. Si comprometen a tus usuarios hablales del «security theater».
@gallir: Los “security theater” agregan complejidad.
Toda mejora siempre aporta complejidad. La seguridad también es sencillez.
@gallir: La compejidad aumenta la probabilidad de fallos.
No si esa seguridad aporta estabilidad y garantías.
@gallir: Los fallos cuestan dinero y recursos humanos.
Me repito de nuevo -> Una mala publicidad cuesta aún más dinero. Si comprometen a tus usuarios hablales del «security theater».
@gallir: Los experimentos con soda y en casa
Los experimentos en casa, la realidad en producción.
@francisco alonso
6. No entiendo cómo es que quieres hacer DRBD por Internet fuera de Amazon (mira el inicio de este tema 6), es absurdo. Incluso hacerlo dentro de Amazon no es simple y le penalización de escrituras será alto. Para eso mejor montar RAID con EBS.
7. Es el problema típico de informático que le gusta trastear y agregan complejidad y probabilidad de fallo. En un sistema de producción la complejidad siempre tiene que estar reducida al mínimo, y el tema de seguridad es siempre análisis de coste-beneficio.
Las instancias web del menéame sólo tienen abierto el puerto del NGInx y éste llama al php-cgi. El punto crítico de seguridad está en los programas PHP del Menéame, no en el NGinx. Estos posibles problemas no lo solucionas poniendo más proxies, porque para ajustar filtros allí es más complicado que revisar lo que tienen en el PHP (y las mismas probabilidades que falles).
Así que no siempre es bueno agregar capas si estas no aportan seguridad, es el típico «security theater» (http://en.wikipedia.org/wiki/Security_theater) que no mejora nada, y empeora la administración aumentando costes.
Por otro lado, para meter filtros a nivel IP en las instancias estás jodido, porque éstas sólo ven la IP privada del balanceador.
Sobre el multimáster, como dicen en todos los sitios, es tricky.
Sobre el memcached, el Menéame usa memcached allí donde se puede o no se necesita verificar la base de datos o datos «tiempo real» (más votadas, populares, candidatas, nubes de categorías y palabras claves).
Sobre GIT, a la largca cambiaremos, pero el subversion no es un problema para nosotros todavía (soy el único que suele hacer commits) y tiene otras ventajas que usamos, como el checkout parcial (mira en el svn los direcotorios www, scripts)
Por otro lado, que el Menéame estar fuera de línea media o una hora para recuperar un máster o datos perdidos no es un problema importante (no somos un banco, ni nos pagan por el uso, ni tenemos contratos), no necesitamos una disponibilidad tan alta, menos cuando hay que pagar mucho dinero. Ni de coña.
Repito:
– No existe la seguridad absoluta. La «seguridad» es un proceso donde impera el coste-beneficio.
– Los «security theater» sólo cuestan dinero.
– Los «security theater» agregan complejidad.
– La compejidad aumenta la probabilidad de fallos.
– Los fallos cuestan dinero y recursos humanos.
– Los experimentos con soda y en casa 😉
> Eso es un grave error, Nginx como cualquier otro programa tiene bugs y pueden ser explotados/vulnerados y debe tener su capa de seguridad
Y hay actualizaciones de seguridad, y es ejecutarlo como usuario sin privilegios… Lo siento, pero no veo que el NGinx sea «inseguro» a este punto.
> En este sentido por ejemplo Mod_security es capaz de detectar/parar/alertar de un Buffer Overflow, inclusión de ficheros remotos, ejecución de código, inyecciones SQL, etc. (http://www.buayacorp.com/archivos/sql-injection-en-meneame/).
Sí… pero esto es de hace más de 3 años, se corrigió antes de que se avise (gracias a que es software libre), nunca fue explotable en Menéame (ya usábamos la versión 5.0). El ejemplo no es demasiado bueno para el caso.
De todas formas, lo que hay que corregir es la aplicación, este era un error gordo de programación. [*]
[*] Hay otro problema del balanceador que es importante, pero no lo voy a comentar aquí, si quieres por email te lo cuento.
> Muchas cosas a veces pueden parecer “chorradas” como este http://www.securitybydefault.com/2008/11/meneame-insecure-by-default.html .
Se controla de otra forma, en el artículo lo han explicado, y hemos agregado más controles con el https/ssl
> Por lo tanto porque no un mínimo de seguridad y fiabilidad de servicio.
¿Y no lo tiene comparado con lo que te -y nos- cuesta? ¿O le has encontrado un problema al montaje actual? (hablas como si lo hubiera de verdad, no digo que no lo haya, pero no veo que justifiques los costes adicionales y complejidad que implicarían –no olvides el autoescalado–)
> Una mala publicidad cuesta aún más dinero.
En todo caso el problema de mala publicidad es por el código que es libre y todo el mundo puede mirarlo.
PS: Casi cada día tenemos ataques duros (esta madrugada intentos de «envenenar» los registros MX [*], supongo para pedir recuperación de contraseña por email), pero sólo un ataque que funcionó, hace 4 años… y luego el DDoS, sobre el que no podemos hace nada.
[*] Para estos ataques al BIND, que me fío menos, sí debería encontrar algo.
@gallir : Y hay actualizaciones de seguridad, y es ejecutarlo como usuario sin privilegios… Lo siento, pero no veo que el NGinx sea “inseguro” a este punto.
Aunque se ejecute sin privilegios 1º se ejecuta como root para abrir el puerto 80 y luego hace un drop de privilegios. Que no tenga ciertos privilegios no determina que no se pueda acceder a ejecutar comandos en el sistema. Para eso se enjaulan los procesos dentro de un contenedor seguro, si se accede al servicio ya necesitas salir de la jaula para llegar al host principal. En linux puedes usar chroots, vservers.. en FreeBSD están las jails, en OpenBSD systrace/chroot, en Solaris/Opensolaris las Zonas… Aunque existen los parches también existen los 0day.
@gallir : Sí… pero esto es de hace más de 3 años, se corrigió antes de que se avise (gracias a que es software libre), nunca fue explotable en Menéame (ya usábamos la versión 5.0). El ejemplo no es demasiado bueno para el caso.
Esta claro que tener el código fuente a largo plazo es mejor para la seguridad de una aplicación, pero tampoco garantiza la misma. Proyectos como gnupg, openssl, que son opensource y se han encontrado bugs graves que llevaban años en el código. Eso pasa porque el código realmente aunque sea abierto no tiene porque haber sido auditado de forma correcta, y de la misma forma día tras día aparecen técnicas nuevas para vulnerar aplicaciones. Además era simplemente un ejemplo, no creo que importe que sea de hace 3 años, lo mismo alguien ha visto (o verá) un bug y no lo ha reportado en el código de meneame.
@gallir : [*] Hay otro problema del balanceador que es importante, pero no lo voy a comentar aquí, si quieres por email te lo cuento.
Ahí tienes mi mail :).
@gallir : Se controla de otra forma, en el artículo lo han explicado, y hemos agregado más controles con el https/ssl
He visto las recomendaciones no los cambios que se hicieron en meneame :).
@gallir : ¿Y no lo tiene comparado con lo que te -y nos- cuesta? ¿O le has encontrado un problema al montaje actual? (hablas como si lo hubiera de verdad, no digo que no lo haya, pero no veo que justifiques los costes adicionales y complejidad que implicarían –no olvides el autoescalado–)
Has escrito una entrada hablando de la misma para dar a conocer como funciona y desde mi punto de vista es mejorable en muchos aspectos. Todo tiene costes adicionales, como si abres una tienda de informática y decides que no es importante poner una alarma antirrobo. Yo no lo veo tan complejo la verdad, e implantarlo lo único que añade es facilidad y fiabilidad de uso diario.
@gallir: En todo caso el problema de mala publicidad es por el código que es libre y todo el mundo puede mirarlo.
Y por el servicio.
@gallir: Casi cada día tenemos ataques duros (esta madrugada intentos de “envenenar” los registros MX [*], supongo para pedir recuperación de contraseña por email), pero sólo un ataque que funcionó, hace 4 años… y luego el DDoS, sobre el que no podemos hace nada.
Me centraba en otros servicios 🙂 pero para evitar envenenamiento de cache de DNS también hay soluciones. Para un DDoS la única solución es tener paciencia y muchos recursos.
PS: Si el código de meneame es abierto y piensas que esto añade seguridad gracias a que todos pueden mirar y cambiar, no deberías tener una política «open» para la infraestructura de meneame donde la opinión de los demás también vale :). Si la economía es el problema yo te presto 64€ para una nueva instancia :).
Pingback: BeraLibre Como montamos Meneame en Amazon EC2 « Archivo de la lista pública solar.general
Pingback: Cómo montamos Menéame en Amazon EC2 | DbRunas
Pingback: Cómo se montó menéame en Amazon EC2 | Nosolocodigo
Hola, me estoy iniciando en AWS y hay algo que has hecho que no veo claro
Cuando dices de aws01 «… la imagen está montada y arranca de un EBS (Elastic Block Service, un “disco persistente” con mejor rendimiento). Además de las ventajas obvias de persistencia de datos permite que en cualquier momento detengamos la instancia y la volvamos a iniciar con otros parámetros, por ejemplo más CPU y memoria RAM… »
no he conseguido hacer algo parecido, dices que tienes una instancia que arranca de un EBS y que paras para poder pasar de small a large ¿cómo hiciste esto?
Gracias
Me contesto:
Haz clic para acceder a BootFromEBSGSGGuide.pdf
hay que crear un segundo volumen EBS que es el que persiste, el asociado a la AMI desaparece con la instancia.
@Rafael
No hace falta, paras (stop) la instancia, luego cambias el tipo con el ec2-modify-instance-attribute, por ejemplo
ec2-modify-instance-attribute i-xyzxyz69 –instance-type m1.xlarge
Y la vuelves a arrancar
Bueno yo no entiendo nada de códigos (solo lo básico), pero estaría genial un meneame de p2p… y todos enviemos nuestros enlaces o cosas interesantes que encontremos p2p (osea solo contenido)
Y tb me encantaría un p2p literario… (con todos los textos que los autores metan y votación)…
Seguro que con el tiempo aparecerán cosas parecidas…
Un abrazo.
No encuentro el comando «ec2-modify-instance-attribute» solo veo «ec2-modify-image-attribute», instalé ya ec2-api-tools y ec2-ami-tools y relacionados con las instancias solo encuentro estos:
ec2-bundle-instance
ec2-confirm-product-instance
ec2-describe-instances
ec2-describe-reserved-instances
ec2-describe-reserved-instances-offerings
ec2-monitor-instances
ec2-purchase-reserved-instances-offering
ec2-reboot-instances
ec2-run-instances
ec2-terminate-instances
ec2-unmonitor-instances
otra duda, ¿se puede aumentar el tamaño del disco persistente una vez puesto en marcha con datos y programas?
@rafael
Bájate la última versión de las utilidades ec2, seguro que tienes una antigua.
Sí que se puede aumentar, he visto un tutorial, pero me pareció un rollo.