Nginx es un software de servidor y servidor proxy inverso gratuito, de código abierto y de alto rendimiento. También puede actuar como proxy para servidores IMAP y POP3. Con su alto rendimiento, estabilidad y ricas funciones. La mayoría de los operadores prefieren una estructura simple y un bajo consumo de recursos.
Nginx, a diferencia de los servidores tradicionales, no depende de subprocesos para procesar solicitudes. En cambio, utiliza una arquitectura basada en eventos más escalable (asíncrona). Esta estructura consume menos recursos pero, lo que es más importante, puede soportar cargas de solicitudes más grandes. Incluso si no espera manejar miles de solicitudes, aún puede beneficiarse del alto rendimiento y la pequeña huella de memoria de Nginx, así como de su rica funcionalidad.
Proxy inverso Nginx:
El proxy inverso se refiere al uso de un servidor proxy para aceptar solicitudes de conexión en Internet y luego reenvía la solicitud al servidor en la red interna y transfiere el solicitud del servidor al servidor Los resultados obtenidos se devuelven a Internet para solicitar una conexión al cliente. En este momento, el servidor proxy aparece como un servidor para el mundo exterior, y este modo de trabajo es similar al LVS-. modelo NETO.
El proxy inverso también puede entenderse como aceleración del servidor web. Es un servidor de búfer web de alta velocidad agregado entre un servidor web ocupado y la red externa para reducir la carga del servidor web real. El proxy inverso es para mejorar la función de aceleración del servidor web. Todas las solicitudes de todas las redes externas para acceder al servidor deben pasar a través de él. De esta manera, el servidor proxy inverso es responsable de recibir la solicitud del cliente y luego obtener el contenido. el servidor de origen y devolver el contenido al usuario, y guardar el contenido localmente, de modo que cuando reciba la misma solicitud de información en el futuro, envíe directamente el contenido en la caché local al usuario, lo que ha reducido el tiempo. presión sobre el servidor web back-end y mejoró la velocidad de respuesta. Por lo tanto, Nginx también tiene capacidades de almacenamiento en caché.
El flujo de trabajo del proxy inverso:
1) El usuario emite una solicitud de acceso a través de un nombre de dominio y el nombre de dominio se resuelve en la dirección IP del servidor proxy inverso;
2) El servidor proxy inverso recibe la solicitud del usuario;
3) El servidor proxy inverso busca en el caché local para ver si el contenido solicitado por el usuario actual existe y, si lo encuentra, devuelve el contenido directamente al usuario;
4) Si el contenido solicitado por el usuario no está disponible localmente, el servidor proxy inverso utilizará su propia identidad para solicitar el mismo contenido de información del servidor back-end y envíe el contenido de la información al usuario. Si el contenido de la información se puede almacenar en caché, entonces El contenido se almacenará en la caché local del servidor proxy.
Beneficios del proxy inverso:
1) Resuelva el problema de que el servidor del sitio web sea visible para el mundo exterior y mejore la seguridad del servidor del sitio web; 2) Ahorre dinero Con recursos de direcciones IP limitados, los servidores back-end pueden usar direcciones IP privadas para comunicarse con servidores proxy.
3) Acelere la velocidad de acceso al sitio web y reduzca la carga en el servidor web real; .
(1) Algoritmo de programación
La instrucción ascendente de Nginx se usa para especificar el servidor back-end utilizado por proxy_pass y fastcgi_pass, es decir, la función de proxy inverso de nginx, por lo que los dos se pueden usar en combinación para lograr el equilibrio de carga, y Nginx también admite una variedad de algoritmos de programación:
1. Sondeo (predeterminado)
Cada solicitud se asigna a diferentes servidores en orden cronológico. Si el servidor backend deja de funcionar, el servidor se omitirá y se asignará al siguiente servidor monitoreado. Y no necesita registrar el estado de todas las conexiones actuales, por lo que es una programación sin estado.
2. Peso
Especifica agregar peso según el sondeo. El peso es proporcional a la relación de acceso, que se utiliza para indicar el rendimiento del servidor back-end. el back-end Si el rendimiento del servidor es bueno, la mayoría de las solicitudes se le pueden asignar, logrando lo que puede hacer.
Por ejemplo:
Configuración de mi servidor backend 172.23.136.148: CPU E5520*2, memoria 8G
Configuración del servidor backend 172.23.136.148: Xeon(TM ) 2,80 GHz * 2, memoria 4G
Espero que cuando lleguen 30 solicitudes al front-end, 20 de ellas se entreguen a 172.23.136.148 para su procesamiento y las 10 solicitudes restantes se entreguen a 172.23.136.149 para procesar Realice la siguiente configuración
upstream web_poll {
servidor 172.23.136.148 peso=10;
servidor 172.23.136.149 peso=5;
}
3. ip_hash
Cada solicitud se asigna de acuerdo con el resultado hash de la IP de acceso. Cuando llega una nueva solicitud, su IP de cliente es la primera. hash a través del algoritmo hash Un valor, siempre que el valor hash de la IP del cliente en solicitudes posteriores sea el mismo, se asignará al mismo servidor backend. Este algoritmo de programación puede resolver el problema de la sesión, pero a veces conducirá. a una distribución desigual y no puede garantizar el equilibrio de carga.
Por ejemplo:
web_pool ascendente {
ip_hash;
servidor 172.23.136.148:80;
servidor 172.23.136.149:80;
}
4. justo (tercero)
Asigne solicitudes de acuerdo con el tiempo de respuesta del servidor back-end. El tiempo de respuesta es corto.
web_pool ascendente {
servidor 172.23.136.148;
servidor 172.23.136.149;
justo;
}
5. url_hash (tercero)
Distribuya las solicitudes de acuerdo con el resultado hash de la URL accedida, de modo que cada URL se dirija al mismo servidor back-end. El servidor back-end está almacenado en caché. Más efectivo.
Ejemplo: agregue una declaración hash al flujo ascendente. Otros parámetros, como el peso, no se pueden escribir en la declaración del servidor. hash_method es el algoritmo hash utilizado
web_pool ascendente {
servidor squid1:3128;
servidor squid2:3128;
hash $request_uri;
hash_method crc32;
}
El estado de cada dispositivo se establece en:
1.down significa que el servidor actual no participa en la carga y se usa en ip_hash
2.weight El valor predeterminado es 1. El peso excede Cuanto mayor sea, mayor será el peso de la carga.
3.max_fails El número predeterminado de errores de solicitud permitidos es 1. Establecerlo en 0 significa desactivar esta función. Cuando se excede el número máximo, se devolverá el error definido por el módulo proxy_next_upstream.
4. fail_timeout es el tiempo de pausa después de la cantidad de fallas definidas por max_fails.
5. La copia de seguridad puede entenderse como una máquina en espera. Cuando todas las demás máquinas que no son de copia de seguridad están inactivas o ocupadas, las solicitudes se asignarán a la máquina de copia de seguridad. Entonces esta máquina tendrá la menor presión.
nginx admite la configuración de múltiples grupos de equilibrio de carga al mismo tiempo para que los utilicen servidores no utilizados.
(2) Uso de instrucciones
1. upstream
Declare un grupo de servidores a los que se puede hacer referencia mediante proxy_pass y fastcgi_pass; estos servidores pueden usar diferentes puertos; y también puede utilizar Unix Socket; también es posible especificar diferentes pesos para el servidor.
Por ejemplo:
web_pool ascendente {
servidor coolinuz.9966.org peso=5;
servidor 172.23.136.148:8080 max_fails=3 fail_timeout=30s;
servidor unix:/tmp/backend3;
}
2. servidor
Sintaxis: nombre del servidor [parámetros]
El nombre puede ser FQDN, dirección de host, puerto o socket Unix; si el resultado de la resolución de FQDN son varias direcciones, se utilizará cada dirección.
3. proxy_pass
Sintaxis: proxy_pass URL;
Esta directiva se utiliza para especificar la URL o dirección y el puerto al que se dirigirá la dirección y la URL del servidor proxy. ser mapeado. Es decir, se utiliza para especificar la dirección o URL [puerto] del servidor backend.
4. proxy_set_header
Sintaxis: valor del encabezado proxy_set_header;
Esta directiva permite redefinir y agregar cierta información del encabezado de la solicitud que se transferirá al servidor proxy.
Por ejemplo:
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded- Para $proxy_add_x_forwarded_for;
Nota: $proxy_add_x_forwarded_for contiene "X-Forwarded-For" en el encabezado de la solicitud del cliente, separado por una coma de $remote_addr si no hay una solicitud "X-Forwarded-For". encabezado, entonces $ proxy_add_x_forwarded_for es igual a $remote_addr
Por cierto, agregue las variables integradas de Nginx:
$args, los parámetros en la solicitud;
$is_args, si se ha establecido $args, entonces el valor de esta variable es "?"; de lo contrario, es "".
$content_length, "Content-Length" en el encabezado de la solicitud HTTP;
$content_type, "Content-Type" en el encabezado de la solicitud;
$document_root , la ruta del directorio raíz establecida para la directiva raíz a la que pertenece la solicitud actual;
$document_uri, lo mismo que $uri;
$host, el "Host" en la solicitud información, si no hay una línea de Host en la solicitud, es igual al nombre del servidor establecido;
$limit_rate, el límite en la velocidad de conexión;
$request_method, el método de solicitud, como "GET", "POST" "Espera;
$remote_addr, dirección del cliente;
$remote_port, número de puerto del cliente;
$ usuario_remoto, nombre de usuario del cliente, utilizado para la autenticación;
$request_filename, el nombre de la ruta del archivo de la solicitud actual
$request_body_file, el nombre del archivo temporal del cuerpo de la solicitud del cliente.
$request_uri, el URI solicitado, con parámetros;
$query_string, lo mismo que $args;
$scheme, el protocolo utilizado, como por ejemplo $1 redirigir
$server_protocol, la versión del protocolo solicitado, "HTTP/1.0" o "HTTP/1.1";
$server_addr, la dirección del servidor, si no se especifica la dirección del servidor. con listening, usa this La variable iniciará una llamada al sistema para obtener la dirección (lo que resultará en un desperdicio de recursos);
$server_name, el nombre del servidor al que llega la solicitud;
$server_port, el número de puerto del servidor al que llega la solicitud;
p>
$uri, el URI solicitado, puede ser diferente del valor original, como a través de la redirección.
5. proxy_read_timeout
Sintaxis: proxy_read_timeout time;
Este comando configura Nginx después de establecer una conexión con el servidor back-end. Esperando el tiempo de respuesta del servidor backend
6. proxy_send_timeout
Sintaxis: proxy_send_timeout time;
Este comando especifica el tiempo de espera para transferir la solicitud al backend servidor. La transferencia completa no requiere más que el período de tiempo de espera, sino sólo entre dos operaciones de escritura. Si después de este tiempo el servidor backend no acepta datos nuevos, nginx cerrará la conexión.
7. proxy_connect_timeout
Sintaxis: proxy_connect_timeout time;
Este comando se utiliza para configurar el tiempo de espera de conexión asignado al servidor back-end.
8. proxy_buffers
Sintaxis: proxy_buffers the_number is_size;
Esta instrucción establece el número y el tamaño de los buffers. De forma predeterminada, el tamaño de un buffer es igual que. tamaño de página.
9. proxy_buffer_size
Sintaxis: proxy_buffer_size buffer_size;
Búfer proxy, esta instrucción se utiliza para guardar la información del encabezado del usuario.
10. proxy_busy_buffers_size
Sintaxis: proxy_busy_buffers_size tamaño;
Se utiliza cuando la carga del sistema es pesada y el búfer no es suficiente, puede solicitar proxy_buffers más grandes
p>11. proxy_temp_file_write_size
Sintaxis: proxy_temp_file_write_size tamaño;
Se utiliza para especificar el tamaño de los archivos temporales almacenados en caché
(3), funciones completas
p>Instalar y configurar módulos de terceros para implementar la detección del estado de salud del servidor web back-end en sentido ascendente:
Dirección de descarga del módulo: /cep21/healthcheck_nginx_upstreams; nombre: ngx_http_healthcheck_module
Método de instalación y configuración:
1 Primero descomprima el módulo Healthcheck en una ruta determinada, que aquí se supone que es /tmp/healthcheck_nginx_upstreams
#. tar -xvf cep21-healthcheck_nginx_upstreams-16d6ae7.tar.gz -C /tmp/healthcheck_nginx_upstreams
2. Parche nginx
Primero descomprima nginx e ingrese al directorio de origen de nginx:
# tar xf nginx-1.3.tar.gz
# cd nginx-1.0.11
# parche -p1 < /tmp/healthcheck_nginx_upstreams/nginx.patch
Luego compila nginx, agrega opciones similares a las siguientes al ejecutar configure:
--add-module=/tmp/healthcheck_nginx_upstreams
Entonces, usa el siguiente comando aquí:
# ./configure \
--prefix=/usr/local/nginx \
--sbin-path=/usr/sbin/ nginx \
- -conf-path=/etc/nginx/nginx.conf \
--lock-path=/var/lock/nginx.lock \
--user=nginx \
--group=nginx \
--con-http_ssl_module \
--con-http_flv_module \
--con-http_stub_status_module \
--con-http_gzip_static_module \
--http-proxy-temp-path=/var/tmp/nginx/proxy/ \
-- http-fastcgi-temp-path=/var/tmp/nginx/fcgi/ \
--con-pcre \
-- add-module=/tmp/healthcheck_nginx_upstreams
# make && make install
Cómo utilizar el módulo ngx_http_healthcheck_module:
1. :
healthcheck_enabled
##Habilite este módulo
healthcheck_delay
##El intervalo de tiempo entre dos comprobaciones del mismo servidor backend, en milisegundos, el valor predeterminado es 1000;
healthcheck_timeout
##El tiempo de espera para una verificación de estado, en milisegundos, el valor predeterminado es 2000;
healthcheck_failcount
##Para un servidor back-end ¿Cuántos veces la prueba tiene éxito o falla antes de que se determine que es exitosa o fallida, y el servidor está habilitado o deshabilitado;
healthcheck_send
##Enviado para detectar el estado de salud del backend Solicitud de detección del servidor, como por ejemplo: healthcheck_send "GET /health HTTP/1.0" 'Host: coolinuz.9966.org';
healthcheck_expected
##Se espera recibir desde atrás; contenido de respuesta del servidor final; si no se establece, significa que el código de estado 200 recibido del servidor back-end es correcto;
healthcheck_buffer
##El tamaño del espacio de búfer utilizado para verificar el estado de salud;
healthcheck_status
Envía información de detección de manera similar a stub_status. El método de uso es el siguiente:
ubicación /stat {
healthcheck_status;
}
(4) Configuración e implementación
El código de configuración es el siguiente:
http {
web_pool ascendente {
servidor 172.23.136.148:80 peso=10;
servidor 172.23.136.149:80 peso=5;
healthcheck_enabled;
healthcheck_delay 1000;
healthcheck_timeout 1000;
healthcheck_failcount 2;
healthcheck_send "GET /.health HTTP/1.0 ";
}
servidor {
escucha 80;
ubicación / {
proxy_set_header Host $http_host ;
proxy_set_header X-Real -IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_pass http://web_pool;
proxy_connect_timeout 3;
}
ubicación /stat {
healthcheck_status;
}
}
}
El parámetro "proxy_set_header" se establece aquí porque cuando Nginx realiza un proxy inverso, necesita acceder al servidor en nombre del cliente. El paquete pasa a través del proxy inverso, el paquete de datos IP aquí en el servidor proxy. Se modifica el encabezado IP y finalmente el servidor web back-end obtiene la fuente del encabezado del paquete de datos.
La dirección IP es la dirección IP del servidor proxy. De esta manera, la función estadística de IP proporcionada por el programa del servidor back-end no tiene significado cuando hay varios hosts virtuales basados en nombres de dominio en la web back-end. servidor, es necesario agregar un encabezado de encabezado. El host de información se utiliza para especificar el nombre de dominio solicitado para que el servidor web backend pueda identificar qué host virtual maneja la solicitud de acceso de proxy inverso.
(5) Resumen
A través de lo anterior podemos ver que la configuración de Nginx es en realidad relativamente simple en comparación con otro software de servidor web, pero las funciones que implementa son bastante poderosas y rico de. El proxy inverso de Nginx ya admite la coincidencia flexible de expresiones regulares, que puede realizar la separación de sitios web dinámicos y estáticos, permitiendo que php dinámico y otras páginas web de programas accedan al servidor web php y permitiendo páginas en caché, imágenes, javascript, css y flash para acceder al servidor de caché o al servidor de archivos como Squid. Junto con el alto rendimiento y la alta concurrencia de contenido estático de Nginx, Nginx como equilibrio de carga de proxy front-end se ha convertido en la primera solución para cada vez más arquitectos.