Archivo de la categoría: hosting

El health check del ELB de AWS y el contenido duplicado en Google

Publicado el por

Como ya había comentado anteriormente, la infraestructura de etece está en la nube de Amazon. Uno de los servicios que tenemos contratados es el de balanceador de carga (ELB) para distribuir el tráfico entre diferentes frontales y así poder autoescalar cuando tenemos picos de tráfico.

Como parte de la configuración del ELB se debe definir el health check. Esto es, una petición que realiza el balanceador a cada una de las máquinas virtuales (EC2) que tiene detrás para determinar si la máquina está funcionando bien o por el contrario tiene algún problema y debe sacarla del balanceo. Este health check se configura mediante:
– protocolo
– puerto
– path de la petición
– timeout de la respuesta
– intervalo entre peticiones
– umbral no sano. Indica el número de veces seguidas en que tolera una respueta incorrecta y a partir de la cuál saca la máquina del balanceador
– umbral sano. Indica el número de veces seguidas en que recibe una respuesta correcta que espera antes de volver a meter una máquina en el balanceador

En el caso de etece tenemos configurado que pida una página cada seis segundos, con un umbral no sano de 2 y un umbral sano de 4. Esto significa que si una máquina no responde adecuadamente durante doce segundos (umbral inferior de 2 con una petición cada 6 segundos), el ELB saca dicha máquina del balanceo. Cuando esa máquina responde correctamente durante 24 segundos (umbral superior de 4 con una petición cada 6 segundos), el ELB la vuelve a incluir en el balanceo.

La petición configurada la hace el ELB a cada una de las EC2 haciendo uso de su DNS público. Esto es un nombre público que tiene cada EC2 durante su tiempo de vida. Si paras la máquina y la vuelves a levantar, cambia su DNS público por lo que no puedes ni debes hacer ninguna configuración mediante ese nombre ya que va a cambiar. Además, si tus frontales autoescalan, todos ellos serán iguales, con la misma configuración pero con diferente DNS público.
Es decir, si yo tengo un EC2 sirviendo peticiones para el dominio midominio.com y ese EC2 tiene un DNS público que es ec2-xx-xx-xx-xx.eu-west-x.compute.amazonaws.com, el ELB va a hacer la petición http configurada en el parámetro path de la petición (por ejemplo /index.html) a este nombre público. Va a pedir http://ec2-xx-xx-xx-xx.eu-west-x.compute.amazonaws.com/index.html. Lo que comprueba el health check es el código de respuesta, dándo únicamente por válida una respuesta 200. Cualquier otra respuesta es considerada respuesta erronea. Por tanto, no puede haber ninguna redirección en esa respuesta.

Hasta aquí no he contado nada nuevo y seguro que muchos ya estáis pensando que soy un poco pesado. Pero cuando empiezas a tirar de la cuerda es cuando ves que hay más tela que cortar y que hay que hilar fino.

Configuración del virtual host de Apache
Si quieres que tu web responda correctamente al health check del ELB evitando las redirecciones, debes tener configurados los virtual host de Apache para que respondan por midominio.com y para el DNS público, que es un valor dinámico. Se podría resolver muy facilmente haciendo que el virtual host de midominio.com sea el virtual host por defecto y todo resuelto. Si pero no. Aquí es donde entra nuestro colega Google.

Si alguna vez, por comprobar el funcionamiento de tu EC2 o porque tienes el EC2 fuera del ELB, haces una petición de tu web por el DNS público, se van a imprimir todos los pixels de analítica, remarketing, conversión etc… que tengas en tu web, pero con un nombre de servidor que no es el de dominio. Google es muy listo y se guarda esa info en algún lugar para luego volver a ella y lo normal es que te indexe varias páginas iguales respondiendo por midominio.com y el DNS público. Total, mismo contenido con dos URLs y eso es penalización segura. Hay que corregirlo en cuanto te das cuenta. En el caso de etece, no somos tan listos como para habernos dado cuenta nosotros solos. Ha sido nuestra amiga Noe la que nos ha avisado del percal. Gracias Noe!!!!

Solución
Después de darle varias vueltas a las diferentes alternativas, hemos decidido que la que más nos gustaba era configurar el virtual host de midominio.com para que redirija todas las peticiones que gestione a midominio.com excepto cuando el user-agent de la petición es el que usa ELB para hacer las peticiones de health check (ELB-HealthChecker/1.0). En ese caso responde por el DNS público y en cualquier otro caso, hace una 301 a midominio.com. De esta manera evitamos que se respondan peticiones por dos URLs distintas y el ELB puede hacer el health check correctamente. Para ello hemos recurrido a la directiva RedirectRule en base a algunas condiciones expecificadas en la directiva RewriteCond, ambas del mod_rewrite de Apache.

Nuestra configuración ha quedado así:

RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} !ELB-HealthChecker
RewriteCond %{SERVER_NAME} !midominio.com
RewriteRule /(.*) http://midominio.com/$1 [L,R=301]

 

— ACTUALIZACIÓN 11-07-2013

Si usas CloudFront como CDN usando subdominios de tu dominio, que son servidos por el mismo server, la configuración que había publicado no funciona correctamente ya que, al no ser una petición con el SERVER_NAME midominio.com, al venir desde CloudFront, la regla le hace una 301 a midominio.com y por tanto estaría sirviendo todo el contenido estático nuestro servidor, perdiendo las virtudes del CDN. Por tanto, hay que incluir una nueva condición para evitar la redirección si quien lo pide es CloudFront.

Nuestra nueva configuración ha quedado así:

RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} !ELB-HealthChecker
RewriteCond %{HTTP_USER_AGENT} !Amazon\ CloudFront
RewriteCond %{HTTP_HOST} !midominio.com
RewriteRule /(.*) http://midominio.com/$1 [L,R=301]

Para el que no esté muy suelto con las directivas de Apache, esto lo que significa es:

Activamos el motor de reescritura
Si el user-agent de la petición NO es ELB-HealthChecker/1.0 Y….  –> Si es ELB-HealthChecker/1.0 entonces no se hace nada
Si el user-agent de la petición NO es CloudFront Y….  –> Si quien hace la petición es CloudFront entonces no se hace nada
Si el nombre de dominio pedido NO es midominio.com entonces…  –> Si el nombre de dominio ya es midominio.com no se hace nada, de esta manera se evitan los bucles de redirecciones
Se hace una 301 a midominio.com

Espero que este breve artículo le sirva a más de uno para evitar un problema de duplicidad de URLs. Es cierto que lo podía haber explicado de manera más breve pero creo que así se entiende mejor. Como siempre, cualquier comentario o corrección es bienvenida.

Impacto de salir en TV sobre la infraestructura de etece

Publicado el por

El pasado 13 de febrero de 2013 TVE emitió el programa Comando Actualidad hablando sobre consumo colaborativo. Una pequeña parte del programa mostró el funcionamiento de etece a través del día a día de nuestro trabajo y el de algunos solucionadores.
Con independencia del impacto en el negocio, quiero compartir el impacto que tuvo en nuestra infraestructura, cómo planificamos la escalabilidad y qué hicimos bien y mal, esperando que sea útil para otras empresas que vayan a pasar por situaciones similares.

Cómo está montada nuestra infraestructura
Tal y como comentaba en un post anterior, nuestra infraestructura está en la nube de Amazón. Una de las características que ofrece es la capacidad de auto escalado en función de la carga que están soportando las máquinas virtuales EC2. Para poderte beneficiar de esta característica, la arquitectura debe estar concebida para ello. No voy a entrar en detalle sobre cómo montar grupos de auto escalado porque ya hay mucha literatura al respecto y no es el propósito de este post. No obstante, si alguien quiere que lo detalle, lo haré sin problema.
Nuestro grupo de auto escalado está configurado para tener como mínimo una máquina, ya que normalmente tenemos poco tráfico, añadiendo una máquina cada vez que la CPU de las máquinas que forman el grupo supera el 75% de carga. Este chequeo de la carga de la CPU del grupo se hace cada minuto (no se puede configurar cada menos). Eso quiere decir que, ante un pico de carga, escalamos añadiendo una máquina por minuto. Teniendo en cuenta que en levantar una nueva máquina lleva entre 20 y 30 segundos, desde que se supera el umbral de carga, tardamos 30 segundos como mínimo y 90 como máximo en incrementar el número de máquinas.

Cómo nos preparamos para el presumible pico de tráfico
Presuponiendo que salir en TV nos iba a suponer un pico de tráfico, modificamos el grupo para que tuviera como mínimo 10 máquinas. En Amazón se paga por tiempo de uso de las máquinas (además de tráfico y alguna cosa más) por lo que tener muchas máquinas durante un rato sólo supone un sobrecoste de unos pocos euros. Además, al salir en TV se producen unos picos de carga muy agudos por lo que más valía prevenir que… morir de éxito.

Qué pasó
Pues pasó lo previsible. No soportamos el pico que se produjo, el escalado, añadiendo una máquina por minuto fue demasiado lento y estuvimos caídos durante unos tres minutos. A partir de ahí fuimos remontando y pudimos volver a estar operativos.
A toro pasado parece obvio que las cosas iban a suceder así, pero antes del momento no lo teníamos tan claro.

Conclusiones
Después de soltar la chapa, esta es la parte más interesante del post. Analizando lo sucedido e intentando aprender de los errores, estas son las conclusiones que hemos sacado:

  • Nuestra configuración de auto escalado está bien para el día a día, cuando no sales en prime time en TV pero no es correcta ante grades picos de carga muy agudos.
  • En este tipo de casos hubiera sido mucho más correcto escalar de cinco en cinco máquinas.
  • Tener un único umbral de auto escalado no es suficiente. Si quieres cubrir picos moderados y grandes sin matar moscas a cañonazos lo mejor es establecer tres umbrales: uno que levante una máquina, el segundo que levante dos máquinas y el último que levante cinco. Los valores de los umbrales podrían ser 60, 75 y 90% de carga de CPU aunque habría que verlo en cada caso.

Otro tema importante es cuándo parar las máquinas que se han levantado una vez que pasa el pico de carga. Nosotros paramos una máquina cada tres minutos siempre que la carga de CPU del grupo esté por debajo del 40%. Esto supone parar tres veces más lento que levantamos. Nos pareció un valor correcto aunque no hay ninguna ciencia detrás de ello y todavía tenemos pendiente optimizarlo.

El tema de la escalabilidad me parece apasionante así que iré escribiendo más sobre cómo afrontamos este tema en etece tanto a nivel de software como de hardware.

Infraestructura de etece en la nube de Amazon

Publicado el por

Hace pocas semanas que hemos lanzado etece.es, tiempo para los que no tienen tiempo. En los próximos posts iré comentando algunos aspectos que creo que merece la pena compartir por si a alguien le puede ayudar. El primero que voy a abordar es el relacionado con la infraestructura y cómo lo hemos montado en la nube de Amazon.

Antecedentes
La primera vez que analicé a fondo la nube de Amazon como alternativa al hosting tradicional fue en 2008 cuando era CTO de Toprural. En aquel momento estábamos planificando un cambio de CPD y Amazon fue una de las alternativas que estudiamos. En aquella época, los servicios de Amazon se limitaban a EC2, S3 y muy poco más lo que suponía demasiadas limitaciones para lo que Toprural necesitaba. Finalmente y hasta hace bien poco, dejamos Toprural funcionando en máquinas propias en una huella contratada en un CPD de Madrid.
El segundo contacto serio con la nube de Amazon lo tuve en Planeo. Toda la infraestructura de Planeo se montó en Amazon, aunque fue el equipo de sistemas de Medianet quien montó todo en base a los requisitos que les transmitimos. En cualquier caso, me permitió conocer de primera mano muchos de los servicios que ofrecen actualmente.

Infraestructura para etece
Tenía bastante claro que Amazon nos ofrecía todos los servicios de infraestructura que vamos a necesitar, al menos en los primeros años, y que lo podíamos montar de manera fácil y rápida. Por ello nos pusimos manos a la obra y hemos montado la infraestructura de etece usando lo siguiente:

  • EC2 (máquinas virtuales) para los servidores web donde básicamente corren los Apache con PHP
  • Los EC2 de la web están detrás de un balanceador ELB que permite añadir y quitar de manera muy fácil, rápida y dinámica (si tienes tiempo de configurarlo) servidores web en función de la demanda (autoscaling).
  • Como base de datos usamos RDS, servicio de base de datos relacional que puede correr Oracle, SQL Server o MySQL, nuestra elección.
  • ElastiCache, el servicio de Memcache que ofrece Amazon, para la caché de aplicación y la gestión de las sesiones de Apache, permitiendo así la alta disponibilidad de los servidores web.
  • CloudFront, CDN de Amazon, que sirve el contenido estático por diferentes dominios. En nuestro caso usamos subdominios distintos para estilos, imágenes y scripts.
  • SES, servicio de envío de emails (se terminaron los dolores de cabeza para mantener un SMTP que envíe correctamente sin llegar a spam) para los emails transaccionales de la aplicación.
  • Route 53, el DNS de Amazon, necesario si quieres apuntar un dominio directamente a un CNAME. Los balanceadores no tienen IP fija y si no usas este servicio necesitaras un subdominio por delante de tu dominio, por ejemplo www.
  • CloudWatch en conjunción con SNS (servicio de notificaciones) para la monitorizacion y alertas de todos los servicios anteriormente indicados. Asociado a alertas puedes lanzar acciones como levantar o parar más instancias de las mismas máquinas.

Amazon tiene más servicios pero a nosotros con esto nos basta y nos sobra.
Entrar al detalle de cómo hemos montado todos y cada uno de los elementos llevaría mucho tiempo y no es el objetivo de este post. No obstante, es posible que aborde algún aspecto en concreto bajo petición de algún lector.

Pros
Llevar tu infraestructura a la nube de Amazon tiene muchas ventajas. Algunas de las más significativas para etece son:

  • Alta disponibilidad nativa en muchos de los servicios como SES, ElastiCache, RDS, etc…
  • Escalabilidad horizontal muy sencilla si has definido todo bien desde la base.
  • Pago por uso. Puedes tener una infraestructura muy potente y pagar muy poco si tienes poco tráfico.
  • Servicios en continua mejora y evolución. Amazon está apostando fuerte por sus servicios web y se nota.
  • Olvidarte por completo de algunos servicios que son comodity y que causaban muchos dolores de cabeza como SMTP, réplicas de base de datos, rotación de backups, etc…

Contras
No todo puede ser prefecto y existen algunos puntos que hay que considerar. La mayoría tienen que ver con detalles de algunos servicios pero no por eso dejan de ser contras:

  • No es barato. La nube de Amazon te da muchas cosas pero las pagas. No es prohibitivamente caro pero si algo más que otras alternativas como VPSs de algunas empresas.
  • El servicio de base de datos relacional con MySQL (no se si pasa con los otros SGBD) sólo funciona con timezone UTC sin posibilidad de cambio lo que te obliga a tenerlo en cuenta en tus aplicaciones.
  • Si vas con Amazon es para ir con todo y no quedarse a medias tintas. Es la maneja de usar todo su potencial.
  • Debes controlar la calidad de tus emails para mantenerte dentro de unos criterios que define Amazon si quieres usar SES.
  • La invalidación de contenido servido por CloudFront es muy lenta, es mejor usar versionado de los elementos y controlar tu mismo su invalidación.
  • La consola web está muy bien pero hay cosas que se tienen que hacer mediante el uso del API a través de la SDK como el autoscaling lo que supone, en algunos casos, invertir más tiempo del deseable para dejar todo muy fino.
  • No existe a día de hoy un servicio de almacenamiento compartido. Hay gente que usa S3 para este propósito pero el tiempo de acceso a los recursos lo desaconseja totalmente. Nosotros hemos montado un servidor que comparte su almacenamiento por NFS y mientas las máquinas con las que comparte estén en la misma región, el tráfico es gratuito.

Operativa
Como parte de nuestras tareas básicas de operaciones hacemos algunas preventivas que se podrían automatizar pero de momento no tenemos tiempo:

  • Tenemos siempre una imagen actualizada de cada tipo de máquina que usamos. Así levantar nuevas imágenes clon manualmente y escalar a demanda es casi inmediato, aunque es manual.
  • Guardamos snapshots de cada máquina después de cada cambio para poder recuperar el último punto bueno conocido y poder crear nuestras propias imágenes cuando necesitemos.
  • Monitorizamos mediante CloudWatch todos los parámetros importantes de cada servicio y asociamos alarmas a los más importantes.

Todavía nos queda mucho camino que recorrer pero creo que tenemos un buen punto de partida. Espero que estas líneas puedan ayudara alguien y por supuesto, estaré encantado de contestar las preguntas relacionadas con el tema, siempre que conozca la respuesta.

Migración de hosting a Arsys

Publicado el por

Cuando empezamos con tagUin, hace más de un año, no teníamos muy claro cuál iba a ser el futuro y sin íbamos a poder sacar adelante la primera fase de dedicación en paralelo con nuestros trabajos por cuenta ajena. Por ello cuando elegimos un hosting para alojar lo que por aquel entonces era una versión de desarrollo sólo tuvimos en cuenta algunos factores muy básicos como precio, duración del compromiso, límite de transferencia y poco más.

Punto de partida

Tras hacer un estudio muy básico de alternativas, nos decidimos por Sliceshost y el plan Slice 256 que era el más pequeño y barato que podíamos contratar. Este plan se nos quedó pequeño enseguida y lo fuimos mejorando con el paso de los meses. Pero cuando hemos llegado a un punto de crecimiento sostenido y un tráfico más o menos decente, han salido varios problemas y defectos y nos hemos planteado buscar una alternativa que nos sirva como poco para el próximo año y a ser posible para muchos más años.

Requisitos

Antes de ponernos a buscar y tras analizar nuestras previsiones de crecimiento, dónde nos gustaría estar en un futuro y qué nos podíamos permitir, hicimos una pequeña lista de los requisitos que debía cumplir nuestro nuevo proveedor. Aquí os listo las más importantes:

  • Servidor físico dedicado. Ya se que estamos en pleno auge de la virtualización y que existen soluciones muy buenas que te dan grandes ventajas, pero tras pensarlo mucho y tras haber sufrido algunos problemas derivados de estar en un servidor virtual decidimos que queríamos nuestro propio servidor físico dedicado.
  • Ancho de banda simétrico y garantizado. En Slicehost teníamos un plan en donde teníamos un límite máximo de transferencia pero en donde no se garantizaba el ancho de banda y esto nos ha dado algunos problemas. Hemos dado muchas vueltas a este tema y tenemos claro que lo que queremos es un acceso con tráfico ilimitado y ancho de banda mínimo garantizado.
  • SLA’s. Buscamos un proveedor que nos garantizara niveles de servicio adecuados para un negocio de Internet. Además que estos SLA’s se aplicaran tanto para los servicios básicos de un data center como para acceso a Internet y sobre todo para soporte. Cuando te surgen problemas graves necesitas que el soporte de tu hosting responda en el mínimo tiempo posible.
  • Precio. Está claro que el precio es siempre un factor importante a tener muy en cuenta.

Opción contratada

Os podría contar por qué hemos rechazado muchas ofertas pero en casi todos los casos ha sido por no cumplir alguno o varios de los requisitos que nos habíamos planteado, prestando especial atención al soporte recibido durante el proceso de análisis y negociación de la oferta (si no te atienden bien cuando estás contratando, cómo lo harán cuando tengas problemas…).

Al final hemos contratado con Arsys, que tenía una oferta muy bien planteada, cumpliendo todos los requisitos y con un precio realmente competitivo. Además nos ha dado confianza cómo y cuándo han dado respuesta a nuestras dudas durante el análisis de la oferta teniendo muy claro que podemos crecer como nos gustaría y podemos seguir trabajando sin problemas con este proveedor.

Quiero aclarar que no tenemos ningún tipo de relación con Arsys, que no me han pedido que escriba este post y que no voy a tener ningún problema en hablar de los problemas que tengamos con ellos. Simplemente busco compartir el camino que hemos andado con todos los lectores por si a alguien le puede servir de ayuda.

¿Qué os parece el cambio?