Archivo de la etiqueta: Amazon

Ajustar la hora en servidores Amazon EC2

[spanish]El reloj del sistema de los servidores virtuales de Amazon EC2 está sincronizado con el del servidor anfitrión, pero algunos servidores parece que no tienen bien la hora. Estoy trabajando en un cluster de cuatro servidores (que crecerá a ocho cuando salgamos a producción) y mientras que tres de ellos estaban perfectamente sincronizados, el cuarto iba retrasado varios minutos.

Por defecto no se puede ajustar la hora ni con date ni ntp, los comandos se ejecutan pero no hacen nada. Para “desengancharse” del reloj del servidor anfitrión y poder ajustar la hora del sistema hay que ejecutar lo siguiente:

echo 1 > /proc/sys/xen/independent_wallclock

Sin embargo, hay que tener en cuenta tal y como se explica aquí que tras ejecutar esto ya no es posible volver a la sincronización con el servidor anfitrión, el reloj de tu sistema ya es independiente para siemre.[/spanish]

[english]Amazon EC2 virtual servers’ internal clock is synchronized with that of their host server. But some host servers seems to be off-date: I’m working on a four-server cluster (will grow to eight when we go into production) and while three of them were perfectly synchronized, the fourth one lagged behind a couple of minutes.

By default you can’t adjust the date with either date nor ntp, the commands execute but do nothing. In order to decouple the VM’s clock from the host’s one and being able to set the time on your system you need to run the following command:

echo 1 > /proc/sys/xen/independent_wallclock

Bear in mind that, as pointed out here, after decoupling your clock from the host’s you can’t go back, you’ll be on your own forever.[/english]

Parche para autenticar nginx con Amazon S3

Vuelvo tras el paréntesis del CCNA (4 módulos aprobados, sólo me falta el examen final de certificación) con algo que he estado haciendo esta semana en el curro: un parche poder usar la autenticación de S3 al hacer de proxy con nginx.

En el curro estamos montando una arquitectura de servidores con EC2, S3 y ELB: los EC2 están distribuidos por capas, con servidores nginx (web y proxy) delante de los servidores de aplicaciones Tomcat, y aparte en S3 tenemos todo el material “pesado” (fotos, vídeos, descargas, etc.) Como nginx puede hacer de proxy, en lugar de mandar a los usuarios directamente a S3 hacemos de proxy y mapeamos el contenido en nuestro propio dominio, con lo que además nos ahorramos unas pelillas (S3 aparte de por ancho de banda y espacio ocupado, cobra por número de conexiones).

El problema viene porque tenemos una gran mayoría de archivos que son públicos (imágenes, iconos y otros elementos del diseño y archivos multimedia) y otros que sólo queremos que los puedan descargar los usuarios registrados en la página. Un paso hacia la solución es usar el parche Secure Download, que genera URL que expiran tras unos minutos con lo que los elementos privados estarían asegurados, pero sólo a través de nuestra página. Si alguien descubre el nombre de nuestro bucket y el esquema de URL (y no es muy complicado….) podría descargar cualquier cosa directamente de S3.

Con este parche se puede acabar de securizar las descargas: se hacen privadas en el bucket de S3, de forma que sólo autenticándose puedan descargarse (el usuario final ya no podría descargarlas aunque averigüe la URL), y nginx si que puede acceder autenticándose a la vez que protege en local las URL con el Secure Download.

El parche está disponible aquí: nginx proxy – Amazon S3 autentication

nginx, memcached y HTTP 304

[spanish]Estoy trabajando en la arquitectura de servidores para una nueva versión de un portal web. Va a estar basada en servidores Amazon-EC2, con un front end con nginx y varios tomcat de back end. Los servidores nginx harán de proxy-caché para ciertas páginas dinámicas (resultados de búsquedas, consultas a los web-services internos) y también tendrá una caché de páginas estáticas gestionada por nosotros en código con memcached.

Al empezar a integrar memcached en esta estructura vi que ya no se enviaban respuestas HTTP 304, todo lo que se servía del memcached eran HTTP 200. Después de usar el comodín de Google parece que es el resultado esperado, ya que memcached no almacena la fecha de modificación de las páginas para poder servir la cabecera HTTP “last-modified”, con lo que los clientes tampoco envían la “if-modified-since” y no hay 304. Así que le he metido mano al código, el parche está aquí.

Estoy bastante sorprendido de lo sencillo que ha sido y lo simple que es el parche, ya que no he tenido que desarrollar la lógica para ver si la página en memcache es más reciente que la que tiene el cliente en su caché y devolver 304 ó 200. Una vez que desde nginx-memcached devuelvo la cabecera “last-modified”, parece que nginx se encarga el sólo de comparar cabeceras y devolver 304 ó 200 según corresponda. ¡Y funciona!

He estado probando esto esta mañana en el trabajo y parece que todo funciona como toca. Mañana haré más pruebas y modificaré el parche si hace falta. Mientras tanto si alguien se anima a probarlo y le funciona (o no), soy todo oídos. :-)[/spanish]

[english]I’m working on the server architecture for a new web portal. It’s going to be Amazon-EC2based and will have a nginx front end to several tomcat back end servers. The nginx servers will proxy-cache some dynamic pages (search results, internal web-services queries) and will also have a static page cache based on memcached.

While starting to roll memcached into the solution I noticed that I stoped receiving HTTP 304 responses, everything served off memcached where 200. After digging a little bit on Google I found out it was the expected behavior as memcached doesn’t store the timestamp (last-modified) of the files. So I’ve given it a try and developed a quick patch. You can find it here.

I’m quite puzzled at the simplicity of the patch, as I didn’t need to code the logic to check if the cached page is more recent than the client’s one and return 302 or 200. After successfully returning the last-modified header from memcached, nginx seems to do the rest of the job somewhere on its own!

I have tested the patch today at work and everything seems to work OK. Will do more extensive testings tomorrow and update the path if needed. In the meantime, if someone gives it a try and works for them (or doesn’t), I’m waiting for your feedback.[/english]