Archivo de la etiqueta: EC2

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]

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]