Apache con nginx
Usted puede mejorar el funcionamiento del servidor web que aloja los sitios web del cliente (Apache) usando nginx, un servidor web complementario de alto rendimiento que suele usarse como servidor proxy inverso. Este servidor web ha sido diseñado específicamente para entregar grandes cantidades de contenido estático (como imágenes, vídeos, CSS, XML, etc). Al contrario que Apache, nginx es mucho más eficiente a la hora de gestionar un gran número de conexiones concurrentes. Otra de las ventajas destacadas de este servidor web en comparación con Apache es que nginx consume mucho menos memoria por conexión de cliente.
Para sacar partido a todos los beneficios de nginx, Plesk lo configura como un servidor proxy inverso que se sitúa entre Internet y Apache tal y como puede ver en el diagrama que aparece a continuación. Esto significa que nginx se convierte en un servidor web frontend que procesa todas las peticiones entrantes de los visitantes del sitio. Las peticiones se envían a Apache y este, a su vez, distingue las peticiones de contenido estático de las peticiones de contenido dinámico. Si se solicita un archivo estático (como por ejemplo JPG, CSS, HTML, etc.), Apache pasa la petición a través de todos los controladores (aplica la configuración a nivel del directorio .htaccess
, vuelve a escribir una URL, etc.) y devuelve una respuesta a nginx que sólo contiene la ubicación del archivo solicitado en el sistema de archivos. nginx localiza el archivo y lo envía al cliente. Si se solicita un archivo dinámico (como un script de PHP), Apache ejecuta el archivo y envía la respuesta a nginx, quien la entrega al cliente.
Esta combinación de nginx y Apache proporciona las siguientes ventajas:
- Aumento del número máximo de conexiones concurrentes a un sitio web.
- Reducción del consumo de recursos de memoria y CPU del servidor. Máxima efectividad en el caso de sitios web con una gran cantidad de contenido estático (como pueden ser galerías de fotos, sitios de streaming de vídeo, etc).
- Mayor eficacia a la hora de prestar servicio a visitantes con velocidades de conexión lentas (GPRS, EDGE, 3G, etc.). Por ejemplo, un cliente con una conexión de 10 KB/s solicita un script de PHP, lo que genera una respuesta de 100 KB. Si no se dispone de nginx en el servidor, la respuesta la entrega Apache. Durante los 10 segundos requeridos para entregar la respuesta, Apache y PHP siguen consumiendo todos los recursos del sistema para esta conexión abierta. Si se tiene instalado nginx, Apache reenvía la respuesta a nginx (la conexión nginx-a-Apache es muy rápida porque ambos se encuentran en el mismo servidor) y libera los recursos del sistema. Como nginx consume menos memoria, se reduce la carga total en el sistema. Si tiene un número elevado de este tipo de conexiones lentas, el uso de nginx mejorará de forma substancial el rendimiento del sitio web.
Más adelante en esta sección se proporcionan los detalles técnicos acerca de cómo Plesk procesa las peticiones HTTP con la ayuda de nginx. Si desea más información acerca de cómo activar el soporte para nginx en Plesk, consulte la sección Instalación de nginx. Si no desea usar nginx, convierta Apache en su servidor web frontend realizando los pasos detallados en la sección Desactivación de nginx. Si desea que nginx procese todas las peticiones HTTP para contenido web, consulte Edición de la configuración del servidor web Apache.
¿Cómo Plesk con nginx procesa las peticiones HTTP?
Para disfrutar de una perfecta integración de nginx con Apache, Plesk usa dos módulos Apache adicionales:
-
mod_aclr2 Este módulo configura un controlador que se ejecuta después de los controladores de todos los demás módulos de Apache (mod_rewrite,
.htaccess
related modules, mod_php, etc.). Así, si la petición es para contenido dinámico, mod_aclr2 nunca la recibirá, ya que la petición será servida por controladores de nivel superior de determinados módulos de Apache (mod_php, mod_perl, mod_cgi, etc). La única excepción son las peticiones SSI: una vez estas llegan a mod_aclr2, este las redirecciona a los controladores apropiados. Si la petición es para un archivo estático, mod_aclr2 busca la ubicación exacta del archivo en el sistema de archivos y envía la ubicación a nginx. - mod_rpaf o mod_remoteip Desde el punto de vista de Apache, todos sus clientes disponen de la misma dirección IP - la dirección del servidor nginx (vea el diagrama mostrado aquí previamente). Esto ocasiona problemas con los sitios web y aplicaciones web que utilizan las direcciones IP de los clientes para autenticación, finalidades estáticas, etc. mod_rpaf (en Apache 2.2) o mod_remoteip (en Apache 2.4) resuelven el problema reemplazando la dirección IP del servidor nginx en todas las peticiones por las direcciones IP de los clientes. Más concretamente, el módulo usa el encabezado especial X-Forwarded-For, en el que nginx incluye la dirección IP de un cliente.
Examinemos más de cerca de qué forma Plesk procesa las peticiones de contenido estático y dinámico con la ayuda de estos módulos.
La secuencia de procesamiento de una petición HTTP para un archivo estático es la siguiente (vea el diagrama):
- Un cliente envía una petición a un servidor web.
- nginx añade los encabezados X-Accel-Internal (usado por mod_aclr2) y X-Forwarded-For (que contiene la dirección IP del cliente) a la petición y envía la petición a Apache.
- Apache recibe la petición y empieza a procesarla mediante controladores registrados (aplica la configuración
.htaccess
, vuelve a escribir la URL, etc). En este paso, mod_rpaf reemplaza la dirección IP del servidor nginx en la variable de Apache REMOTE_ADDR por la dirección del cliente del encabezado X-Forwarded-For. - Una vez procesada la petición por todos los controladores registradores, esta llega a mod_aclr2. El controlador compruebe la presencia del encabezado X-Accel-Internal. De estar presente, el módulo envía una respuesta a nginx con una longitud de contenido cero y el encabezado X-Accel-Redirect. Este encabezado contiene la ubicación exacta del archivo tal y como lo determina mod_aclr2.
- Una vez nginx recibe la respuesta, este localiza el archivo y lo entrega al cliente.
El diagrama que se muestra a continuación muestra un ejemplo de la forma en la que Plesk gestiona la petición de un archivo GIF de 2 KB.
En el caso de procesar peticiones de contenido dinámico, los pasos 1 a 3 son los mismos. A continuación, la petición pasa al controlador del módulo Apache apropiado (mod_php, mod_perl, mod_cgi, etc.). La petición nunca llega a mod_aclr2 (a excepción de las peticiones SSI). El controlador genera una respuesta y la envía a nginx, que, a su vez, entrega la respuesta al cliente. El diagrama que puede ver a continuación ilustra de qué forma Plesk procesa una petición de un archivo de PHP.
Instalación de nginx
Si realiza una instalación limpia de Plesk, nginx se activará de forma predeterminada. Si actualiza una versión anterior, puede instalar el componente «Nginx web server» en cualquier momento tras la actualización en Herramientas y configuración > Actualizaciones (en «Plesk») > Adición/eliminación de componentes. Una vez añadido el componente, inicie el servicio Servidor proxy inverso (nginx) en Herramientas y configuración > Administración de servicios (en «Administración del servidor»).
Puede consultar la versión del servidor nginx instalado en Herramientas y configuración > Componentes del servidor (en «Administración del servidor»).
Desactivación de nginx
Para volver a la configuración con un único servidor web Apache, detenga el servicio Servidor proxy inverso (nginx) en Herramientas y configuración > Administración de servicios (en «Administración del servidor»).
Para que nginx vuelva a ser el servidor web frontend, inicie el servicio Servidor proxy inverso (nginx).
Nota: las operaciones de inicio y detención para el servicio Servidor proxy inverso (nginx) no solo inician y detienen nginx, sino que de hecho cambian la configuración del servidor web (la combinación de nginx y Apache o solo Apache como servidor web frontend). La operación de reinicio funciona de igual forma que para todos los demás servicios: el servicio nginx se reinicia.