Un servidor de upstream es un tipo de servidor al cual Nginx le sirve de proxy para la conexión, es decir que Nginx filtra las peticiones y solo le envía las que él puede procesar. Este tipo de servidores pueden estar en una máquina virtual, en una máquina física diferente o incluso ser servicios demonio en un entorno UNIX esperando ser llamados.
Esto en la práctica se traduce a que puede ser un servidor Apache configurado para solo servir peticiones específicas por un puerto TCP o puede ser un middleware que interpreta Ruby para una aplicación de Rails. Por ende Nginx puede manejar las peticiones iniciales y ser el reverse proxy de los servicios.
Servidores Upstream Únicos
Son servidores que tienen un único punto de subida como lo indica su nombre, un ejemplo de esto puede ser el servidor Apache, el cual en la mayoría de las configuraciones que encontramos no está optimizado para servir múltiples conexiones simultaneas, ya que al recargarse con los módulos de servir archivos estáticos, baja su efectividad.
Aquí entra Nginx quien se encarga de administrar las múltiples conexiones y de esta manera solo pasar a Apache los archivos que realmente este debe interpretar, como por ejemplo archivos de PHP.
Una configuración básica podría ser la siguiente:
Lo que vemos en la imagen es una configuración donde Nginx pasa directamente las peticiones a Apache, optimizando la finalización de las conexiones, sin embargo esto no es tan óptimo como la configuración que veremos en la siguiente imagen, donde le decimos a Nginx que sirva los archivos estáticos y los que no lo sean pasarlos a Apache, con esto si se logra una mayor diferencia en rendimiento:
Múltiples Servidores Upstream
Nginx también está en la capacidad de poder trabajar con varios servidores upstreams en caso que el servicio para el cual haga de reverse proxy solo pueda manejar pocas conexiones, evitando de esta forma que haya una sobrecarga en los mismos.
Vemos como definimos tres servidores en un bloque upstream llamado app, luego en nuestro bloque server hacemos un proxy_pass al bloque app, lo que va a hacer Nginx es utilizar el esquema de round robin para ir sirviendo las peticiones a los tres servidores upstream que definimos, logrando de esta manera el objetivo; Adicionalmente, Nginx también puede manejar otros algoritmos de balanceo de carga.
Finalizando este tutorial vemos una vez más como Nginx tiene capacidades que lo hacen ser una opción bastante viable en entornos de alta carga de peticiones.
Esto en la práctica se traduce a que puede ser un servidor Apache configurado para solo servir peticiones específicas por un puerto TCP o puede ser un middleware que interpreta Ruby para una aplicación de Rails. Por ende Nginx puede manejar las peticiones iniciales y ser el reverse proxy de los servicios.
Servidores Upstream Únicos
Son servidores que tienen un único punto de subida como lo indica su nombre, un ejemplo de esto puede ser el servidor Apache, el cual en la mayoría de las configuraciones que encontramos no está optimizado para servir múltiples conexiones simultaneas, ya que al recargarse con los módulos de servir archivos estáticos, baja su efectividad.
Aquí entra Nginx quien se encarga de administrar las múltiples conexiones y de esta manera solo pasar a Apache los archivos que realmente este debe interpretar, como por ejemplo archivos de PHP.
Una configuración básica podría ser la siguiente:
Lo que vemos en la imagen es una configuración donde Nginx pasa directamente las peticiones a Apache, optimizando la finalización de las conexiones, sin embargo esto no es tan óptimo como la configuración que veremos en la siguiente imagen, donde le decimos a Nginx que sirva los archivos estáticos y los que no lo sean pasarlos a Apache, con esto si se logra una mayor diferencia en rendimiento:
¿Cómo trabaja?
La forma en que trabaja este proceso es muy simple, la directiva try_files va a probar si encuentra y puede servir la petición del cliente, en caso de no hacerlo se la va a pasar a Apache para que haga el procesamiento correspondiente.
Múltiples Servidores Upstream
Nginx también está en la capacidad de poder trabajar con varios servidores upstreams en caso que el servicio para el cual haga de reverse proxy solo pueda manejar pocas conexiones, evitando de esta forma que haya una sobrecarga en los mismos.
¿Cómo lograr esto?
Para lograr esto vamos a seguir una estructura similar a lo que vimos con el upstream único, solo que ahora debemos definir un bloque personalizado con las rutas de los diferentes servidores y luego configurar nuestro proxy_pass hacia ellos. Veamos un ejemplo sencillo:
Vemos como definimos tres servidores en un bloque upstream llamado app, luego en nuestro bloque server hacemos un proxy_pass al bloque app, lo que va a hacer Nginx es utilizar el esquema de round robin para ir sirviendo las peticiones a los tres servidores upstream que definimos, logrando de esta manera el objetivo; Adicionalmente, Nginx también puede manejar otros algoritmos de balanceo de carga.
Finalizando este tutorial vemos una vez más como Nginx tiene capacidades que lo hacen ser una opción bastante viable en entornos de alta carga de peticiones.
