La diferencia entre clustering y equilibrio de carga nginx
Nginx se diferencia de los servidores tradicionales en que 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 mayores cargas de solicitudes. Incluso si no desea manejar miles de solicitudes, aún puede beneficiarse del alto rendimiento, la pequeña huella de memoria y la rica funcionalidad de Nginx.
Proxy inverso Nginx:
Proxy inverso significa que el servidor proxy acepta la solicitud de conexión en Internet y luego reenvía la solicitud al servidor en la red interna y desde el servidor. a Internet Devuelve el resultado de solicitar una conexión al cliente. En este momento, el servidor proxy aparece como un servidor para el mundo exterior. Este método de trabajo es similar al modelo de red LVS.
El proxy inverso también puede entenderse como aceleración del servidor web, que es una tecnología que reduce la carga del servidor web real agregando un servidor de búfer web de alta velocidad entre el servidor web ocupado y la red externa. El proxy inverso mejora la función de aceleración del servidor web. Todas las solicitudes de acceso al servidor desde la red externa 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 de la fuente. servidor, devolver el contenido al usuario y transferir el contenido al usuario. Guárdelo localmente, de modo que cuando se reciba la misma solicitud de información en el futuro, el contenido en el caché local se envíe directamente al usuario, reduciendo el tiempo. presión sobre el servidor web back-end y mejora de la velocidad de respuesta. Entonces Nginx también tiene función de almacenamiento en caché.
El flujo de trabajo del proxy inverso:
1) El usuario envía una solicitud de acceso a través del nombre de dominio, que se resuelve en la dirección IP del servidor proxy inverso
;2) Inverso Recibe la solicitud del usuario al servidor proxy;
3) El servidor proxy inverso busca en el caché local el contenido solicitado por el usuario actual y, si lo encuentra, lo devuelve directamente al servidor proxy. usuario;
4) Si no hay contenido solicitado por el usuario localmente, el servidor proxy inverso utilizará su propia identidad para ir al servidor backend para solicitar el mismo contenido de información y enviarlo al usuario. . Si el contenido del mensaje se puede almacenar en caché, se almacenará en la caché local del servidor proxy.
Ventajas del proxy inverso:
1) Resuelve el problema de que el servidor del sitio web sea visible para el mundo exterior y mejora la seguridad del servidor del sitio web
3) Acelera el acceso al sitio web y reduce la carga en el servidor web real .
(1) Algoritmo de programación
Las instrucciones ascendentes de Nginx se utilizan para especificar el servidor back-end utilizado por proxy_pass y fastcgi_pass, que es la función de proxy inverso de Nginx, por lo que Se puede combinar para lograr el equilibrio de carga. Nginx también admite varios algoritmos de programación:
1. Sondeo (predeterminado)
Cada solicitud se asigna una tras otra en orden cronológico. Si un servidor backend deja de funcionar, se omite y se asigna 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 aumentar el peso en función del sondeo. El peso es proporcional a la tasa de acceso, que se utiliza para indicar el rendimiento del servidor back-end. . Si el rendimiento del servidor backend es bueno, se le pueden asignar la mayoría de las solicitudes, lo cual es lo mejor.
Por ejemplo:
Mi servidor backend 172. 23. 136.148 configuración: CPU E5520*2, memoria 8G.
Configuración del servidor backend 172. 23. 136. 148: Xeon (TM) 2,80 GHz * 2, memoria 4G.
Se espera que cuando lleguen 30 solicitudes al front-end, 20 de ellas serán procesadas por 172.23.136.148 y las 10 solicitudes restantes serán procesadas por 172.23.136.149.
web_poll ascendente {
Servidor 172. 23. 136. 148 peso = 10;
Servidor 172. 23. 136. 149 peso = 5;
p>
}
3. Hash de IP
Cada solicitud se asigna en función del resultado del hash del acceso a IP. Cuando llega una nueva solicitud, se aplica un hash a la IP de su cliente para obtener un valor. Siempre que las solicitudes posteriores tengan el mismo valor hash, se asignarán al mismo servidor backend. Este algoritmo de programación puede resolver el problema de las sesiones, pero a veces conduce a una distribución desigual, es decir, no se 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)
La solicitud se asigna en función del tiempo de respuesta del servidor backend y las solicitudes. Se da prioridad a aquellos con tiempos de respuesta cortos.
web_pool ascendente {
Servidor 172. 23. 136. 148;
Servidor 172. 23. 136. 149;
Aceptable ;
}
5.url_hash (tercero)
Distribuir solicitudes basadas en los resultados hash de las URL visitadas para que cada URL se dirija al mismo backend servidor, que es más eficiente al almacenar en caché el servidor backend.
Ejemplo: agregue una declaración hash en sentido ascendente. Otros parámetros, como los pesos, no se pueden escribir en la declaración del servidor. hash_method es el algoritmo hash utilizado.
web_pool ascendente {
Servidor Squid 1:3128;
Servidor Squid 2:3128;
Hash $request_uri
hash _ método crc32
}
El estado de cada dispositivo se establece en:
1.down significa que el servidor actual no participa en cargando. Utilizado en ip_hash.
2. El valor predeterminado de peso es 1. Cuanto mayor sea el peso, mayor será el peso de la carga.
3. De forma predeterminada, Max_failures permite que el número de solicitudes fallidas sea 1. Si se establece en 0, esta función se desactivará. Si se excede el número máximo, se devolverá un error definido por el módulo proxy_next_upstream.
4.fail_timeout es el tiempo de pausa después del número de fallas definidas por max_fails.
5. La copia de seguridad puede entenderse como una máquina en espera, y a todas las demás máquinas que no son de copia de seguridad se les asignarán solicitudes cuando estén inactivas o ocupadas. Entonces la presión sobre esta máquina será la más ligera.
Nginx admite la configuración de múltiples grupos de equilibrio de carga al mismo tiempo para servidores no utilizados.
(2) Instrucciones de uso
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; , También se pueden utilizar Unix Sockets; también puede especificar diferentes pesos para el servidor.
Por ejemplo:
web_pool ascendente {
Peso del servidor coolinuz.9966.org = 5
Servidor 172. 23. 136. 148: 8080 max_fails = 3 fail _ time out = 30s;
Servidor UNIX:/tmp/back end 3;
}
Servidor
Sintaxis. : nombre del servidor [parámetros]
Donde nombre puede ser un 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. Pase de proxy
Sintaxis: proxy_pass URL
Esta directiva se utiliza para especificar la dirección del servidor proxy y la URL o dirección a la que se dirige la URL. será mapeado el puerto. Es decir, se utiliza para especificar la dirección o URL [puerto] del servidor backend.
4. Encabezado del conjunto de proxy
Sintaxis: valor del encabezado proxy_set_header;
Esta directiva permite redefinir y agregar cierta información del encabezado de solicitud para transmitirla al servidor proxy.
Por ejemplo:
proxy_set_header Host $ host
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X -Reenviado-Para $ proxy _ add _ Y sepárelo de $remote_addr con una coma. Si no hay un encabezado de solicitud "X-Forwarded-For", $proxy_add_x_forwarded_for es igual a $remote_addr.
Por cierto, agreguemos las variables integradas de Nginx:
$args, parámetros en la solicitud.
$is_args, si se ha establecido $args, el valor de esta variable es "?", en caso 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 de la velocidad de conexión;
$request_method, el método de solicitud, como "GET" y "POST";
$remote_addr, dirección del cliente.
$remote_port, número de puerto del cliente;
$remote_user, 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, dirección del servidor. Si escucha no especifica una dirección del servidor. , el uso de esta 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.
El uri$URI solicitado puede ser diferente del valor original, como ser redirigido.
5. Tiempo de espera de lectura del proxy
Sintaxis: proxy _ read _ timeout time
Este comando configura Nginx para conectarse al servidor backend. Tiempo de espera para la respuesta del servidor backend
6. Tiempo de espera de envío del proxy
Sintaxis: proxy_send_timeout time
Este comando especifica que la solicitud se transmite al backend. período de tiempo de espera del servidor. La transferencia completa no dura más que el tiempo de espera, solo entre escrituras. Si el servidor backend ya no acepta datos nuevos después de este tiempo, nginx cerrará la conexión.
7. Tiempo de espera de la conexión del proxy
Sintaxis: proxy_connect_timeout
Este comando se utiliza para configurar el tiempo de espera de la conexión asignado al servidor back-end.
8. Búfer de proxy
Sintaxis: proxy_buffers el_número es_tamaño
Este comando establece el número y el tamaño del búfer. De forma predeterminada, el búfer tiene el mismo tamaño que la página.
9. Tamaño de caché de proxy
Sintaxis: proxy_buffer_size buffer_size
Búfer de proxy, utilizado para guardar la información del encabezado del usuario.
10. Tamaño del búfer ocupado del proxy
Sintaxis: proxy_ocupado_búferes_tamaño tamaño
Se utiliza cuando la carga del sistema es pesada y el búfer no es suficiente. Solicite proxy_buffers más grandes.
11. Tamaño de escritura del archivo temporal del agente
Sintaxis: Tamaño de escritura del archivo temporal del agente;
Se utiliza para especificar el tamaño de los archivos temporales de la caché.
(3), funciones completas
Instale y configure el módulo de terceros para realizar la detección del estado de salud del servidor web back-end ascendente;
Dirección de descarga del módulo: / CEP 21/health check _ Nginx _ Upstreams; nombre del módulo: ngx _ http _ healthcheck _ module
Método de instalación y configuración:
1. módulo healcheck a una ruta determinada. Se supone que esta ruta es /tmp/health check_nginx_upstreams.
# tar-xvf CEP 21-health check_nginx_upstreams-16d6ae 7 .gz-C/tmp/health check_nginx_upstreams
2. /p>
Primero descomprima nginx e ingrese al directorio fuente de nginx:
# tar xf nginx-1.3.4.tar.gz
# CD nginx-1. 11
# patch -p 1 lt; /tmp/health check _ nginx _ upstreams/nginx patch
Luego compila nginx y agrega opciones similares a las siguientes al ejecutar configure:
-add-module =/tmp/health check _ nginx _ upstreams
Entonces, aquí está el siguiente comando:
# ./config\
- prefix=/usr/local/nginx \
- sbin-path=/usr/sbin/nginx \
-conf-path =/etc/nginx/ nginx . conf \
-lock-path =/var/lock/nginx . / p>
- 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/\< / p>
-use-pcre\
-add-module=/tmp/health check_nginx_upstreams
#Fabricación y venta.
amp para instalar
Uso del módulo ngx_http_healthcheck_module:
1 Los comandos admitidos por este módulo son:
Health check_enabled
# #. Habilite este módulo
Health check_delay
# # El intervalo de tiempo entre dos detecciones del mismo servidor backend, en milisegundos, el valor predeterminado es 1000;
Health check_timeout
# # El tiempo de espera de una verificación de estado, en milisegundos, el valor predeterminado es 2000;
Recuento de fallas de verificación de salud
# # ¿Cuántas veces se realiza la verificación de estado? la prueba del servidor final tiene éxito o falla antes de determinar si tiene éxito o falla, y si el servidor está habilitado o deshabilitado;
Chequeo de estado_send
# #Enviar una solicitud de detección para detectar después del estado de salud del servidor final, como por ejemplo: chequeo de salud _ enviar "get/health http/1.0" 'host: coolinuz org'; El contenido de respuesta esperado del servidor backend; si no se establece, el código de estado 200 recibido del servidor backend es correcto;
Health check_buffer
# #Se utiliza para el tamaño del estado. comprobar el espacio del búfer;
Health check_status
Emite información de detección de forma similar a stub_status. El uso es el siguiente:
Ubicación/Estado{
Health check_status;
}
(4), configuración e implementación
El código de configuración es el siguiente:
http {
Upstream web_pool {
Servidor 172. 23. 136. 148: 80 peso = 10;
Servidor 172.23.136.149:80 peso=5;
HEALTH CHECK_ENABLED;
HEALTH CHECK_DELAY 1000;
health check_time out 1000;
Recuento de fallos de comprobación de estado 2;
healthcheck_send "GET /.Health HTTP/1.0";
}
Servidor {
Escuchar 80;
Ubicación/ {
proxy_set_header Host$ http_Host;
p>
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_X_Forwarded_For;
p>
proxy_pass http://web_pool;
proxy_connect_timeout3;
}
Ubicación/Estado {
Chequeo de salud_status;
}
}
}
El parámetro "proxy_set_header" se establece aquí porque cuando Nginx realiza un proxy inverso, necesita acceder al servidor en lugar del cliente. Por lo tanto, después de que el paquete de solicitud pasa a través del proxy inverso, el encabezado IP del paquete IP se modifica en el servidor proxy. Finalmente, la dirección IP de origen del encabezado del paquete obtenida por el servidor web back-end es la dirección IP del servidor proxy. servidor proxy.
No tiene sentido que el programa del servidor back-end proporcione la función de estadísticas de IP, o cuando hay varios hosts virtuales basados en nombres de dominio en el servidor web back-end, debe especificar el nombre de dominio solicitado agregando la información del encabezado del host. para que el servidor web back-end sea posible identificar qué host virtual está manejando las solicitudes de acceso de proxy inverso.
Resumen
De lo anterior podemos ver que la configuración de Nginx es en realidad más simple que otros software de servidor web, pero sus funciones son bastante poderosas y ricas. 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 de programas accedan al servidor web php y permitiendo el acceso a páginas en caché, imágenes, javascript, css y flash. Servidores de caché como Squid o File server. Junto con el alto rendimiento y la alta concurrencia de Nginx para contenido estático, Nginx como equilibrio de carga de proxy front-end se ha convertido en la solución preferida de cada vez más arquitectos.