Inicio > personal, desarrollo, programación, menéame > Cómo montamos Menéame en Amazon EC2

Cómo montamos Menéame en Amazon EC2

diciembre 30, 2009

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.

  1. diciembre 30, 2009 en 5:32 am

    Justo hoy discutía con un amigo si eras un bot o realmente sigues a estas horas conectado por Twitter. Excelente artículo.

  2. Ktzar
    diciembre 30, 2009 en 5:46 am

    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.

  3. diciembre 30, 2009 en 6:06 am

    muy bien, interesante post/articulo y muy útil.

  4. Arnau
    diciembre 30, 2009 en 9:13 am

    Magnífico post, como todos los técnicos de Ricardo. En los de opinión no me meto, por algo son de opinión :)

  5. diciembre 30, 2009 en 9:30 am

    ¡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 :)

  6. Mikep
    diciembre 30, 2009 en 9:30 am

    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

  7. diciembre 30, 2009 en 9:49 am

    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!

  8. diciembre 30, 2009 en 9:50 am

    Gracias.

  9. diciembre 30, 2009 en 10:28 am

    muy bueno! muy útil!

    Muchas gracias por atender a mi petición (supongo que alguien mas te lo pidió)

  10. diciembre 30, 2009 en 10:29 am

    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?

  11. diciembre 30, 2009 en 10:29 am

    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 ;-)

  12. diciembre 30, 2009 en 10:45 am

    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.

  13. diciembre 30, 2009 en 10:45 am

    Un apunt fantàstic Ricardo, gràcies per postejar-ho i per obrir camí.

  14. diciembre 30, 2009 en 10:52 am

    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

  15. diciembre 30, 2009 en 10:53 am

    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.

  16. diciembre 30, 2009 en 11:39 am

    YoNoSoyTu: que yo sepa, Amazon es “safe harbor”: http://www.stoel.com/showarticle.aspx?Show=1878

  17. diciembre 30, 2009 en 11:41 am

    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.

  18. diciembre 30, 2009 en 12:05 pm

    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!

  19. diciembre 30, 2009 en 12:23 pm

    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.

  20. diciembre 30, 2009 en 12:43 pm

    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! ;-)

  21. diciembre 30, 2009 en 1:27 pm

    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.

  22. diciembre 30, 2009 en 2:18 pm

    Fua! Vaya apunte más rico! :-D 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.

  23. diciembre 30, 2009 en 2:27 pm

    @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.

  24. peeper
    diciembre 30, 2009 en 4:10 pm

    Hola Ricardo, muy buena explicación. Creo que en los gastos mensuales te faltó incorporar el costo de AuthSMTP, que plan incorporaron?

    Saludos

  25. Jose
    diciembre 30, 2009 en 4:27 pm

    Impecable, gracias por compartir este tesoro de info!

  26. joffer
    diciembre 30, 2009 en 4:53 pm

    Muy interesante, gracias por compartirlo.

  27. diciembre 30, 2009 en 4:54 pm

    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).

  28. Santi
    diciembre 30, 2009 en 5:37 pm

    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.

  29. diciembre 30, 2009 en 5:57 pm

    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.

  30. aa
    diciembre 30, 2009 en 6:51 pm

    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…

  31. diciembre 30, 2009 en 8:08 pm

    después de esto, sólo puedo decir una cosa…. “sólo sé que no sé nada” :)

  32. diciembre 30, 2009 en 8:19 pm

    @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

  33. diciembre 30, 2009 en 8:23 pm

    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

  34. diciembre 30, 2009 en 8:33 pm

    Una muy buena explicación, una tecnología muy interesante.

  35. diciembre 30, 2009 en 8:59 pm

    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.

  36. Antonio
    diciembre 30, 2009 en 9:11 pm

    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”. :-D

    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. :-)

  37. El_Senor_Oscuro
    diciembre 30, 2009 en 11:33 pm

    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.

  38. Menda
    diciembre 30, 2009 en 11:38 pm

    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.

  39. diciembre 31, 2009 en 1:24 am

    Felicidades Ricardo por el cambio y buen año.

  40. diciembre 31, 2009 en 4:02 am

    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. ;)

  41. Gabriel
    diciembre 31, 2009 en 9:02 am

    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. :-(

  42. diciembre 31, 2009 en 10:01 am

    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.

  43. diciembre 31, 2009 en 11:15 am

    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.

  44. hommer
    diciembre 31, 2009 en 12:12 pm

    a pesar DE que nos cobraron. Se dice a pesar DE algo, no a pesar algo. A pesar algo vas a la báscula.

  45. crises
    diciembre 31, 2009 en 6:34 pm

    @kadekilo

    OVH no dispone de datacenters en España. Como mucho te dan una IP failover geolocalizada en España.

  46. enero 1, 2010 en 6:53 pm

    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.

  47. enero 1, 2010 en 6:58 pm

    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.

  48. enero 1, 2010 en 7:15 pm

    @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.

  49. enero 3, 2010 en 2:38 am

    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.

  50. enero 3, 2010 en 4:57 am

    Muy intereante…
    Gracias

  51. enero 3, 2010 en 10:10 am

    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.

  52. enero 3, 2010 en 7:50 pm

    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

  53. dsutil
    enero 4, 2010 en 5:40 pm

    Gracias por mostrarnos las entrañas del EC2 a los que no tenemos tiempo/ganas de investigar por nuestra cuenta.

  54. eloygbm
    enero 5, 2010 en 7:44 pm

    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!!

  55. enero 5, 2010 en 11:04 pm

    @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.

  56. Francisco Alonso
    enero 7, 2010 en 5:51 pm

    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 :).

  57. Francisco Alonso
    enero 7, 2010 en 6:51 pm

    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 :P

  58. enero 7, 2010 en 6:13 pm

    @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: http://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).

  59. enero 7, 2010 en 7:13 pm

    @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.

  60. Francisco Alonso
    enero 8, 2010 en 9:52 am

    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.

  61. Francisco Alonso
    enero 8, 2010 en 10:31 am

    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.

  62. enero 8, 2010 en 10:17 am

    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 :-)

  63. Francisco Alonso
    enero 8, 2010 en 1:10 pm

    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.

  64. Francisco Alonso
    enero 8, 2010 en 2:47 pm

    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.

  65. enero 8, 2010 en 1:59 pm

    @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 ;-)

  66. enero 8, 2010 en 4:02 pm

    > 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.

  67. Francisco Alonso
    enero 9, 2010 en 12:36 am

    @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 :).

  68. enero 12, 2010 en 4:43 pm

    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

  69. enero 12, 2010 en 6:39 pm

    Me contesto:

    http://ec2-downloads.s3.amazonaws.com/BootFromEBSGSGGuide.pdf

    hay que crear un segundo volumen EBS que es el que persiste, el asociado a la AMI desaparece con la instancia.

  70. enero 12, 2010 en 6:52 pm

    @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

  71. enero 13, 2010 en 3:34 am

    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.

  72. enero 13, 2010 en 11:23 pm

    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?

  73. enero 13, 2010 en 11:29 pm

    @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.

  1. diciembre 30, 2009 en 5:22 am
  2. diciembre 30, 2009 en 10:34 am
  3. diciembre 31, 2009 en 2:49 pm
  4. enero 1, 2010 en 1:08 am
  5. enero 3, 2010 en 8:24 am
  6. enero 10, 2010 en 7:26 pm
  7. enero 10, 2010 en 11:05 pm
  8. enero 12, 2010 en 12:33 pm
Los comentarios están cerrados.
Seguir

Recibe cada nueva publicación en tu buzón de correo electrónico.

Únete a otros 470 seguidores

%d personas les gusta esto: