Servidor de caché con proxy inverso de nginx

Etiquetas relacionadas: 1.Nginx Ingress Controller
2. Analizar los registros de nginx

Resumen: se utiliza como proxy de las solicitudes de conexión (como VPN/NAT) de la red interna hacia internet.

Los servicios de proxy se pueden dividir de forma sencilla en proxy directo y proxy inverso:

Proxy directo: el cliente especifica el servidor proxy y envía a este la solicitud HTTP que originalmente iba dirigida directamente al servidor web de destino; a continuación, el servidor proxy accede al servidor web y devuelve la respuesta del servidor web al cliente:

Proxy inverso: al contrario del proxy directo, si la red de área local (LAN) ofrece recursos a internet y permite que otros usuarios de internet accedan a los recursos de la red de área local, también puede configurar un servidor proxy, y el servicio que ofrece es un proxy inverso. El servidor proxy inverso acepta conexiones desde internet, reenvía la solicitud al servidor de la red interna y devuelve la respuesta a

Clientes en internet que solicitan una conexión:

1. Proxy inverso de nginx: el planificador del servidor web

1. Proxy inverso significa que el servidor proxy acepta la solicitud de conexión del cliente y, a continuación, reenvía la solicitud al servidor web (puede ser apache, nginx, tomcat, iis, etc.) de la red, y envía la solicitud desde el servidor web. El resultado obtenido de esta forma se devuelve al cliente que solicita la conexión, y el servidor proxy actúa como servidor frente al mundo exterior.

Como se puede ver en la figura anterior: el servidor de proxy inverso que actúa como proxy del sitio web recibe la solicitud HTTP y la reenvía. Además, como servidor de proxy inverso, nginx puede reenviar solicitudes a distintos servidores web de backend según el contenido de la solicitud del usuario, como la separación de contenido estático y dinámico; por ejemplo, puede crear varios hosts virtuales en nginx para que en el navegador se acceda correctamente a distintos servidores web o clústeres web de backend al introducir diferentes nombres de dominio (URL).

2. ¿Cuál es la función del proxy inverso?

①Proteger la seguridad del sitio web: cualquier solicitud procedente de internet debe pasar primero por un servidor proxy;

wKioL1jsz9yAHyulAABvTU4R-Ew435.png-wh_50

②Acelerar las solicitudes web mediante la configuración de la función de caché: algunos recursos estáticos del servidor web real se pueden almacenar en caché para reducir la presión de carga del servidor web real;

wKiom1jsz-nwYDqSAABjrKK3l5E661.png-wh_50

③ Implementar el balanceo de carga: actúa como servidor de balanceo de carga para distribuir las solicitudes de manera equilibrada y equilibrar la presión de carga de cada servidor del clúster;

wKiom1jsz__Q7RpoAAJQnYSWdA8640.png-wh_50

2. ¿Qué es nginx?

1. Introducción a nginx

Nginx es un servidor web ligero, un proxy inverso y un servidor proxy de correo. Es conocido por su estabilidad, su amplio conjunto de funciones, sus archivos de configuración de ejemplo y su bajo consumo de recursos del sistema. Nginx (se pronuncia como engine x) fue desarrollado por el programador ruso Igor Sysoev. Originalmente lo utilizaba el gran portal ruso y motor de búsqueda Rambler (en ruso: Рамблер). Este software se publica bajo un acuerdo de tipo BSD y puede ejecutarse en UNIX, GNU/Linux, BSD, Mac OS X, Solaris y Microsoft Windows.

Estado de adopción de Nginx

Nginx ya funciona en Rambler Media (www.rambler.ru), el portal más grande de Rusia, y más del 20 % de las plataformas de alojamiento virtual de Rusia utilizan Nginx como servidor de proxy inverso.

En China, muchos sitios web como Taobao, Sina Blog, Sina Podcast, Netease News, Liujianfang, 56.com, Discuz!, Shuimu Community, Douban, YUPOO, Domestic, Xunlei Online, etc., ya utilizan Nginx como servidor web o servidor de proxy inverso.

2. Las características principales de Nginx

(1) Multiplataforma: Nginx se puede compilar y ejecutar en la mayoría de los sistemas operativos, y también existe una versión para Windows;

(2) La configuración es muy sencilla: es muy fácil comenzar.

(3) Conexiones simultáneas sin bloqueo y de alta concurrencia: la prueba oficial admite 50,000 conexiones simultáneas y, en el entorno de producción real, alcanza de 20,000 a 30,000 conexiones simultáneas. (Esto se debe a que Nginx utiliza el modelo epoll más reciente);

Nota:

En un servidor web, primero observe el proceso básico de una solicitud: establecer una conexión - recibir datos - enviar datos; desde la base del sistema: el proceso anterior (establecer una conexión - recibir datos - enviar datos) es un evento de lectura y escritura en la base del sistema.

Si se utiliza el método de llamada con bloqueo, cuando los eventos de lectura y escritura no están listos, la única opción es esperar: el hilo actual se suspende y los eventos de lectura y escritura solo se pueden realizar cuando los eventos están listos.

Si se utiliza un método de llamada sin bloqueo: el evento devuelve una respuesta de inmediato, indica que el evento aún no está listo y que debe volver más tarde. Después de un momento, vuelva a comprobar el evento hasta que esté listo; mientras tanto, puede hacer primero otras cosas y regresar después para ver si el evento ya está correcto. Aunque no hay bloqueo, debe comprobar el estado del evento de vez en cuando; puede hacer más cosas, pero la sobrecarga no es pequeña. Una llamada sin bloqueo significa que la llamada no bloquea el hilo actual aunque el resultado no esté disponible de inmediato

(4) Orientado a eventos: el mecanismo de comunicación adopta el modelo epoll para admitir más conexiones simultáneas.

El método sin bloqueo determina si realiza las operaciones de lectura y escritura comprobando constantemente el estado de los eventos, lo que genera mucha sobrecarga; por ello existe un mecanismo asíncrono de procesamiento de eventos sin bloqueo. Este mecanismo permite monitorear varios eventos al mismo tiempo. Las llamadas son sin bloqueo, pero puede establecer un tiempo de espera. Dentro del tiempo de espera, si un evento está listo, devuelve la respuesta. Este mecanismo resuelve los dos problemas anteriores de las llamadas con bloqueo y sin bloqueo.

Tomemos el modelo epoll como ejemplo: cuando el evento no está listo, se coloca en epoll (cola). Si un evento está listo, se gestiona; cuando el evento no está listo, espera en epoll. De esta forma, podemos procesar una gran cantidad de solicitudes al mismo tiempo. Por supuesto, las solicitudes simultáneas a las que se hace referencia aquí son solicitudes sin procesar. Solo hay un hilo, de modo que solo se puede procesar una solicitud al mismo tiempo. Es únicamente un cambio constante entre solicitudes. El cambio también se produce de forma activa porque el evento asíncrono no está listo. Aquí el cambio no tiene costo; puede entenderlo como un bucle a través de varios eventos preparados.

En comparación con el método multiproceso, este método de procesamiento de eventos tiene grandes ventajas. No necesita crear hilos y cada solicitud ocupa muy poca memoria. No hay cambio de contexto. El procesamiento de eventos es muy ligero y la concurrencia es alta. Tampoco provoca un desperdicio innecesario de recursos (cambio de contexto). En el servidor apache, cada solicitud tendrá un hilo worker exclusivo y, cuando la concurrencia alcanza varios miles, habrá varios miles de hilos procesando solicitudes al mismo tiempo. Esto representa un gran desafío para el sistema operativo: como el uso de memoria que provoca el hilo es muy grande y la sobrecarga de CPU causada por el cambio de contexto del hilo es muy elevada, el rendimiento no puede mejorar de forma natural, lo que provoca una caída grave del rendimiento en escenarios de alta concurrencia.

Resumen: mediante el mecanismo asíncrono de procesamiento de eventos sin bloqueo, Nginx hace que el proceso trate de forma cíclica varios eventos preparados y, de este modo, logra alta concurrencia y ligereza.

(5) Estructura Master/Worker: un proceso master genera uno o más procesos worker.

Nota: el modo de diseño Master-Worker incluye principalmente dos componentes, Master y Worker. El Master mantiene la cola de Workers y envía solicitudes a varios Workers para su ejecución en paralelo. El Worker realiza principalmente los cálculos de lógica reales y devuelve los resultados al Master.

¿Qué ventajas tiene que nginx adopte este modelo de procesos? El uso de procesos independientes evita que se afecten entre sí. Cuando un proceso termina, los demás siguen trabajando y el servicio no se interrumpe. El proceso Master reiniciará rápidamente el nuevo proceso Worker. Por supuesto, la salida anómala del proceso Worker debe deberse a un bug del programa. La salida anómala hará que fallen todas las solicitudes del Worker actual, pero no afectará a todas las solicitudes, de modo que el riesgo se reduce.

(6) Bajo consumo de memoria: el consumo de memoria al procesar un gran número de solicitudes simultáneas es muy bajo. Con 30,000 conexiones simultáneas, 10 procesos de Nginx consumen únicamente 150M de memoria (15M*10=150M).

(7) Función de verificación de salud integrada: si un servidor web en el backend del proxy de Nginx sufre una caída, no afectará el acceso en el frontend.

(8) Ahorro de ancho de banda: admite compresión GZIP y se puede agregar la cabecera Header almacenada en caché de forma local por el navegador.

(9) Alta estabilidad: cuando se usa como proxy inverso, la probabilidad de tiempo de inactividad es mínima.

3. Nginx+apache crea el balanceo de carga de clústeres de servidores web

Configurar el proxy inverso de nginx

Configure nginx como proxy inverso y balanceador de carga, y utilice su función de caché para almacenar en caché las páginas estáticas en nginx, a fin de reducir la cantidad de conexiones a los servidores backend y comprobar la salud de los servidores web backend.



wKiom1js0B-iFnITAACVfFt6894317.png-wh_50

1. Instalar nginx

entorno:

SO: centos7.2

nginx: 192.168.31.83

apache1:192.168.31.141

apache2:192.168.31.250

Instalar dependencias como zlib-devel y pcre-devel

[root@www ~]# yum -y install gcc gcc-c++ make libtool zlib zlib-devel pcre pcre-devel openssl openssl-devel

Nota:

Combinar los módulos proxy y upstream para lograr el balanceo de carga web en el backend

Almacenamiento en caché de archivos estáticos mediante el módulo proxy

Combinado con los módulos predeterminados de nginx ngx_http_proxy_module y ngx_http_upstream_module

Para implementar la verificación de salud del servidor backend, también puede utilizar el módulo de terceros nginx_upstream_check_module

Utilice el módulo de extensión nginx-sticky-module para implementar la fijación de sesión por cookie (mantener la sesión)

Utilice ngx_cache_purge para lograr una función de purga de caché más potente

Los dos módulos mencionados arriba son módulos de extensión de terceros. Debe descargar el código fuente con anticipación e instalarlos junto con --add-moudle=src_path al compilar.



instalar nginx

[root@www ~]# groupadd www #Agregar el grupo www

[root@www ~]# useradd -g www www -s /sbin/nologin #Crear la cuenta www con la que se ejecuta nginx y agregarla al grupo www; no se permite que los usuarios www inicien sesión directamente en el sistema

#tar zxf nginx-1.10.2.tar.gz

#tar zxf ngx_cache_purge-2.3.tar.gz

#tar zxf master.tar.gz

# cd nginx-1.10.2/

[root@www nginx-1.10.2]# ./configure --prefix=/usr/local/nginx1.10 --user=www --group=www --with-http_stub_status_module --with-http_realip_module --with- http_ssl_module --with-http_gzip_static_module --http-client-body-temp-path=/var/tmp/nginx/client --http-proxy-temp-path=/var/tmp/nginx/proxy --http-fastcgi- temp-path=/var/tmp/nginx/fcgi --with-pcre --add-module=../ngx_cache_purge-2.3 --with-http_flv_module --add-module=../nginx-goodies-nginx-sticky -module-ng-08a395c66e42

[root@www nginx-1.10.2]# make && make install

Nota: todos los módulos de nginx deben agregarse en tiempo de compilación y no se pueden cargar de forma dinámica en tiempo de ejecución.

4. Otros esquemas de planificación para el balanceo de carga:

A continuación se presentan otros algoritmos de planificación admitidos por el módulo de balanceo de carga de nginx:

Sondeo (predeterminado): cada solicitud se asigna una por una a distintos servidores backend en orden cronológico. Si un servidor backend sufre una caída, el sistema con fallos se elimina de forma automática, de modo que el acceso de los usuarios no se ve afectado. Weight especifica el peso del sondeo. Cuanto mayor es el valor de Weight, mayor es la probabilidad de acceso asignada. Se utiliza principalmente cuando el rendimiento de cada servidor del backend es desigual.

ip_hash: cada solicitud se asigna según el resultado del hash de la IP de acceso, de modo que los visitantes de la misma IP puedan acceder a un mismo servidor backend, lo que resuelve eficazmente el problema del uso compartido de sesiones en páginas web dinámicas. Por supuesto, si este nodo no está disponible, se enviará al siguiente nodo y, si en ese momento no hay sincronización de sesiones, se cerrará la sesión.

least_conn : la solicitud se envía al realserver con menos conexiones activas en ese momento. Se considerará el valor de weight.

url_hash : este método asigna las solicitudes según el resultado del hash de la URL de acceso, de modo que cada URL se dirija al mismo servidor backend, lo que puede mejorar aún más la eficiencia del servidor de caché de backend. Nginx por sí solo no admite url_hash. Si necesita utilizar este algoritmo de planificación, debe instalar el paquete hash de Nginx nginx_upstream_hash .

fair : es un algoritmo de balanceo de carga más inteligente que los dos anteriores. Este algoritmo puede realizar el balanceo de carga de forma inteligente según el tamaño de la página y el tiempo de carga; es decir, asigna las solicitudes según el tiempo de respuesta del servidor backend y da prioridad a las que tienen un tiempo de respuesta corto. Nginx por sí solo no admite fair. Si necesita utilizar este algoritmo de planificación, debe descargar el módulo upstream_fair de Nginx.

5. Balanceo de carga y verificación de salud:

En rigor, nginx no tiene una verificación de salud para los nodos de backend del balanceo de carga, pero se puede realizar mediante las directivas correspondientes de los módulos predeterminados ngx_http_proxy_module y ngx_http_upstream_module. Cuando el nodo de backend falla, cambia de forma automática al siguiente nodo para proporcionar acceso.

weight : el peso del sondeo también se puede utilizar en ip_hash; el valor predeterminado es 1

max_fails : la cantidad de veces que se permite que fallen las solicitudes; el valor predeterminado es 1. Cuando se supera la cantidad máxima de veces, se devuelve un error definido por el módulo proxy_next_upstream.

fail_timeout: tiene dos significados; uno es permitir hasta 2 fallos en 10s y el otro es no asignar solicitudes a este servidor durante 10s después de 2 fallos.

6. Usos de la caché de proxy de nginx:

El almacenamiento en caché consiste en guardar en caché los archivos js, css, de imagen y otros archivos estáticos del servidor backend en el directorio de caché especificado por nginx, lo que no solo reduce la carga del servidor backend, sino que también acelera la velocidad de acceso; sin embargo, limpiar la caché a tiempo se vuelve un problema, por lo que se necesita el módulo ngx_cache_purge para limpiar manualmente la caché antes del tiempo de vencimiento.

Las directivas que se usan con frecuencia en el módulo proxy son proxy_pass y proxy_cache.

La función de caché web de nginx se realiza principalmente mediante el conjunto de instrucciones proxy_cache, fastcgi_cache y conjuntos de instrucciones relacionados. La instrucción proxy_cache se encarga del contenido estático del servidor backend en la caché del proxy inverso, y fastcgi_cache se utiliza principalmente para gestionar la caché del proceso dinámico FastCGI.