05 feb 11 Modificaciones en el servidor: fachada nginx
Estas semanas, cuando el trabajo y la salud me lo han permitido, he estado realizando algunos cambios en el servidor. Como comenté anteriormente, el más importante ha sido el cambio de su ubicación: ha pasado de ser un servidor virtual VMWare ubicado en Córdoba a ser un servidor físico emplazado en Sevilla. Y ya que estaba de cambios, me decidí a probar un servidor web del que llevaba tiempo escuchando hablar: nginx.
nginx es un servidor web/proxy inverso ligero de alto rendimiento y un proxy para protocolos de correo electrónico (IMAP/POP3). Es software libre y de código abierto, licenciado bajo la Licencia BSD simplificada. Es multiplataforma, por lo que corre en sistemas tipo Unix (GNU/Linux, BSD, Solaris, Mac OS X, etc.) y Windows.
El sistema es empleado en una larga lista de sitios web conocidos, como: WordPress, Hulu, GitHub, Ohloh, SourceForge y TorrentReactor. Originalmente, nginx fue desarrollado para satisfacer las necesidades de varios sitios web de Rambler que recibían unas 500 millones de peticiones al día en septiembre de 2008.
De acuerdo con el estudio de Netcraft, Netcraft’s May 2010 Web Server Survey, nginx fue el tercer servidor web más usado en todos los dominios (6.55% de los sitios estudiados) y el cuarto servidor web más usado en los sitios activos (8.77% de los sitios estudiados).
Sus características básicas son las siguientes:
- Servidor de archivos estáticos, índices y autoindexado
- Habilitado para soportar más de 10.000 conexiones simultáneas
- Proxy inverso con opciones de caché
- Balance de carga
- Tolerancia a fallos
- Soporte de HTTP sobre SSL
- Soporte para FastCGI con opciones de caché
- Servidores virtuales basados en nombre y/o en dirección IP
- Streaming de archivos FLV y MP4
- Soporte para autenticación
- Compresión gzip
- Capacidad de reescritura de URLs
- Sistema de log personalizable
- Soporte WebDAV
La arquitectura interna de nginx le permite servir más peticiones por segundo con menos recursos que sus principales alternativas. Ésta consiste en un proceso maestro que delega el trabajo en uno o varios procesos “worker”. Cada worker gestiona múltiples peticiones de modo basado en eventos, o bien asíncrono, haciendo uso de funcionalidades especiales del kernel Linux (epoll/select/poll). Esto permite a nginx gestionar un gran número de peticiones concurrentes de una manera rápida y con muy poca sobrecarga. Por ejemplo, un servidor Apache puede ser configurado para procesar las bien una petición por proceso (pre-fork) o bien una petición por cada hilo (worker). Aunque el modo basado en hilos de Apache tiene un rendimiento mucho mejor que el basado en procesos, sigue haciendo uso de mucha más memoria y CPU que la arquitectura basada en eventos de nginx.
En mi caso concreto, mi servidor web contiene las siguientes aplicaciones:
- Una bitácora. La que estás leyendo, que utiliza WordPress. Necesita PHP y una base de datos MySQL
- Un sistema de almacenamiento de fotografías. Utiliza Gallery2. También necesita PHP, MySQL, y una serie de molestas reescrituras
- Una serie de aplicaciones menores de mantenimiento y de gestión de logs. Por lo general, usan PHP, CGI, y alguna de ellas MySQL
Mi objetivo primordial era realizar un reemplazo completo del servidor Apache, motivado por las siguientes razones: el cambio del servidor me ha dejado con menos recursos hardware (en concreto, con menos RAM y con un procesador menos potente), y sobre todo, comprobar si nginx es tan bueno como lo vende.
A la hora de realizar el cambio, pude comprobar algo que es bastante importante: nginx es un servidor web de ficheros estáticos. Esto quiere decir que si estás pensando en sacar a través de él páginas web dinámicas tienes un problema. Por suerte es un problema fácilmente abordable, ya que al estar pensado desde el principio como un servidor proxy inverso, tienes la capacidad de delegar funcionalidades no soportadas en otros servidores adicionales. En mi caso, instalé en mi servidor Debian un servidor PHP externo, spawn-fcgi, que escucha peticiones por el puerto 9000.
La migración de WordPress no supuso mayor problema, una vez solucionado el tema anterior. Sin embargo, la de Gallery2 sí me ha planteado más dificultades, debido a una serie de reescrituras un tanto especiales que necesita para mantener funcionando el sistema. Tras varios días de pruebas, y viendo que no alcanzaba a migrar completamente esta aplicación, decidí darle un cambio de perspectiva: mantener el servidor Apache como un servidor web subordinado, y emplear nginx como servidor de fachada, con caché de contenido. No hay mal que por bien no venga, ya que me ha supuesto la oportunidad de realizar pruebas de esta funcionalidad, de cara a una línea de trabajo que estoy desarrollando para mi empresa.
Como consecuencia de lo anterior, decidí mover los puertos de servicio del servidor Apache al 81 (conexión http) y 444 (conexión https), que son sólo alcanzables desde la red interna de mi casa. Mediante una serie de reescrituras, las peticiones efectuadas al sistema Gallery2 son dirigidas al servidor Apache, procesadas por éste, y reenviadas por nginx al cliente, además de ser cacheadas para ganar en tiempo de respuesta. El resto de peticiones (WordPress, otras aplicaciones…) son servidas directamente por el servidor nginx. Un diagrama básico de lo expuesto hasta el momento sería el siguiente:
Diagrama de arquitectura
El resultado desde el punto de vista funcional es bastante bueno: las aplicaciones siguen siendo servidas de manera correcta, se ha ganado algo en tiempo de respuesta (por desgracia, la poca potencia del servidor y las limitaciones de la línea de datos no permiten grandes alegrías), y ha disminuido el consumo de memoria: pese a no haber eliminado el servidor Apache, se ha pasado de consumir unos 900 MB de RAM a unos 780, y con un comportamiento mucho más estable. Cada proceso nginx consume un máximo de 3 MB, mientras que cada proceso Apache ronda los 50 MB, con una gran fluctuación de memoria consumida. A esto hay que sumar los dos procesos configurados para spawn-fcgi, que también rondan los 50 MBs. La bajada en el consumo ha venido de haber podido reducir el número de procesos Apache que se mantienen en ejecución: he podido pasar de un mínimo de 10 procesos concurrentes a tan sólo 2.
En resumen: estoy bastante contento con el cambio. Estoy aprendiendo a gestionar servidores web de alto rendimiento, y creo que voy a poder sacarle bastante partido a este servidor nginx en el ámbito laboral. Esperemos que así sea.
Medidor de entropía
