Tecnologías comunes de equilibrio de carga

La cuarta capa es responsable del equilibrio: se refiere principalmente a determinar a qué destino designado reenviar juzgando la dirección IP y el puerto del mensaje y utilizando un determinado algoritmo de equilibrio de carga. Funciona principalmente en la cuarta capa. capa del modelo OSI. El equilibrio de carga de cuatro capas solo desempeña una función de reenvío de datos para paquetes de datos y no interfiere con la comunicación de la capa de aplicación entre el cliente y el servidor (como el protocolo de enlace de tres vías, etc.). Por lo tanto, hay muy pocas operaciones que se pueden realizar con los datos, pero la eficiencia será mucho mayor que la del equilibrio de carga de siete capas

Equilibrio de carga de siete capas: también conocido como "cambio de contenido" , se refiere a El dispositivo de equilibrio de carga selecciona el servidor interno que llega al destino a través de la información de la capa de aplicación (URL, encabezado HTTP, etc.) en el mensaje y el algoritmo de equilibrio de carga. El equilibrio de carga de siete capas puede filtrar "inteligentemente" la información de la capa de aplicación en paquetes y luego realizar una programación de equilibrio de carga específica basada en información diferente. Este método mejora la flexibilidad del sistema de aplicación en la capa de red y también mejora la seguridad del sistema back-end hasta cierto punto. Debido a los ataques DoS comunes en Internet, estos ataques generalmente terminan en el dispositivo de equilibrio de carga en un entorno de equilibrio de carga de siete capas y no afectarán el funcionamiento normal del servidor backend.

El equilibrio de carga común en la red actual se divide principalmente en equilibrio de carga de hardware y equilibrio de carga de software. Los productos conocidos para el equilibrio de carga de hardware incluyen F5 Big-IP, Cirtix Netscaler, etc. Existen muchos proyectos de código abierto para el equilibrio de carga de software, los más comunes incluyen Haproxy, nginx, lvs, etc.

Haproxy:

lvs:

nginx:

Haproxy se puede utilizar como un servicio proxy y tiene muchas similitudes con nginx. Uni-President puede realizar un proxy de cuatro capas según el modo tcp o enviar una solicitud según el modo o un nombre de dominio que comience con z.cn, esta regla devuelve verdadero. De manera similar, la segunda regla significa que si el cliente envía una solicitud a través de. bbs.z.cn nombre de dominio, entonces esta regla devuelve verdadero, y la tercera regla significa que si el cliente contiene la cadena "buy_sid=" en la URL solicitada, entonces esta regla devuelve verdadero.

Las reglas cuarta, quinta y sexta definen qué backend enviar cuando las tres reglas de ACL www_policy, bbs_policy y url_policy devuelven verdadero. Por ejemplo, cuando la solicitud del usuario satisface la regla www_policy, HAProxy enviará. la solicitud del usuario directamente al backend llamado server_www, y así sucesivamente. Cuando la solicitud del usuario no cumple con ninguna regla de ACL, HAProxy enviará la solicitud al server_cache backend especificado por la opción default_backend.

Al igual que en el ejemplo anterior, en este ejemplo también se definen tres reglas de ACL url_static, host_www y host_static. Entre ellas, la primera regla define a través del parámetro path_end si el cliente termina en . Devuelve verdadero si termina en gif, .png, .jpg, .css o .js. La segunda regla define a través del parámetro hdr_beg (host) que si el cliente envía una solicitud con un nombre de dominio que comienza con www, devolverá verdadero. De manera similar, la tercera regla. Esta regla también se define a través del parámetro hdr_beg (host) para que devuelva verdadero si el cliente envía una solicitud con un nombre de dominio que comienza con img., video., download.

Las reglas cuarta y quinta definen qué backend enviar cuando se cumplen las reglas de ACL. Por ejemplo, cuando la solicitud del usuario satisface tanto la regla host_static como la regla url_static, o satisface las reglas host_www y url_static. , entonces la solicitud del usuario se enviará directamente al backend llamado static. Si la solicitud del usuario cumple con las reglas de host_www, la solicitud se enviará al backend llamado www. Si no se cumplen todas las reglas, la solicitud del usuario se enviará a. la programación predeterminada para este backend llamado server_cache.

log: configuración de registro global, local0 es el dispositivo de registro, info representa el nivel de registro. Los niveles de registro incluyen error, advertencia, información y depuración. Esta configuración indica el uso del dispositivo de registro local0 en el servicio rsyslog en 127.0.0.1 y el nivel de registro es info.

maxconn: establece el número máximo de conexiones simultáneas que cada proceso HAProxy puede aceptar. Esta opción es equivalente a la opción de línea de comando de Linux "ulimit -n".

usuario/grupo: establece el usuario y el grupo que ejecuta el proceso HAProxy. También puede utilizar los valores uid y gid del usuario y el grupo.

demonio: configura el proceso HAProxy para que se ejecute en segundo plano. Este es el modo de funcionamiento recomendado.

nbproc: establece la cantidad de procesos que se pueden crear cuando se inicia HAProxy. Este parámetro requiere configurar el modo de ejecución de HAProxy en demonio. De forma predeterminada, solo se inicia un proceso. La configuración de este valor debe ser menor que la cantidad de núcleos de CPU del servidor. La creación de múltiples procesos puede reducir la cola de tareas de cada proceso, pero demasiados procesos pueden provocar que el proceso falle.

pidfile: Especifica el archivo pid del proceso HAProxy. El usuario que inicia el proceso debe tener permiso para acceder a este archivo.

Modo: establece el modo de ejecución predeterminado de la instancia de HAProxy. Hay tres valores opcionales: tcp, http y salud.

reintentos: establece el número de reintentos fallidos para conectarse al servidor backend. Si el número de conexiones fallidas excede el valor establecido aquí, HAProxy marcará el servidor backend correspondiente como no disponible. Este parámetro también se puede configurar en una sección posterior.

tiempo de espera de conexión: establece el tiempo máximo de espera para una conexión exitosa a un servidor. La unidad predeterminada es milisegundos, pero también se pueden usar otros sufijos de unidades de tiempo.

tiempo de espera del cliente: establece el tiempo de espera máximo cuando el cliente que se conecta envía datos. La unidad predeterminada es milisegundos. También se pueden utilizar otros sufijos de unidades de tiempo.

servidor de tiempo de espera: establece el tiempo de espera máximo para que el servidor responda a la transmisión de datos del cliente. La unidad predeterminada es milisegundos y también se pueden utilizar otros sufijos de unidades de tiempo.

verificación de tiempo de espera: establece el tiempo de espera de detección para el servidor backend. La unidad predeterminada es milisegundos. También se pueden usar otros sufijos de unidades de tiempo.

bind: Esta opción sólo se puede definir en las secciones frontend y listening y se utiliza para definir uno o varios sockets de escucha. El formato de uso de bind es: bind [lt;addressgt;:lt;port_rangegt;] interface lt;interfacegt; Puede ser un nombre de host o una dirección IP. Si está configurado en "*" o "0.0.0.0", monitoreará todas las direcciones IPv4 actuales del sistema. port_range puede ser un puerto TCP específico o un rango de puertos menores que 1024 requieren usuarios con permisos específicos para usarlos.

La interfaz es una opción opcional que se utiliza para especificar el nombre de la interfaz de red y solo se puede utilizar en sistemas Linux.

opción httplog: de forma predeterminada, los registros de HAProxy no registran solicitudes HTTP, lo cual es muy inconveniente para solucionar y monitorear problemas de HAProxy. Esta opción permite el registro de solicitudes HTTP.

opción forwardfor: si el servidor backend necesita obtener la IP real del cliente, es necesario configurar este parámetro. Dado que HAProxy funciona en modo proxy inverso, la IP del cliente en la solicitud enviada al servidor real back-end es la IP del host HAProxy, no la dirección del cliente de acceso real. Esto da como resultado que el servidor real no pueda registrar el. Solicitud real de la IP de origen del cliente y X-Forwarded-For se pueden utilizar para resolver este problema. Al utilizar la opción forwardfor, HAProxy puede agregar un registro X-Forwarded-For a cada solicitud enviada al servidor real backend, de modo que el registro del servidor real backend pueda registrar la IP de origen del cliente a través de la información "X-Forwarded-For".

opción httpclose: esta opción indica que HAProxy cerrará activamente la conexión TCP después de que el cliente y el servidor completen una solicitud de conexión. Este es un parámetro muy útil para el rendimiento.

log global: indica el uso de la configuración de registro global. Aquí global se refiere al formato de configuración de opciones de registro definido en la sección global del archivo de configuración de HAProxy.

default_backend: especifique el grupo de servidores backend predeterminado, es decir, especifique un grupo de servidores reales backend, y estos grupos de servidores reales se definirán en la sección backend. El htmpool aquí es un grupo de servidores backend.

opción redispatch: Este parámetro se utiliza en el entorno donde se mantienen las cookies. De forma predeterminada, HAProxy insertará el ID del servidor del servidor backend que solicita en la cookie para garantizar la persistencia de la sesión. Y si el servidor back-end falla, la cookie del cliente no se actualizará, lo que causará problemas. En este momento, si se establece este parámetro, la solicitud del cliente se dirigirá por la fuerza a otro servidor back-end en buen estado para garantizar un servicio normal.

opción abortonclose: Si se establece este parámetro, las conexiones que tardan mucho en procesarse en la cola actual pueden finalizarse automáticamente cuando la carga del servidor es muy alta.

-balance: Esta palabra clave se utiliza para definir el algoritmo de equilibrio de carga. Actualmente, HAProxy admite una variedad de algoritmos de equilibrio de carga, los más utilizados son los siguientes:

Cookie: indica que SERVERID puede insertarse en cookies. El SERVERID de cada servidor se puede definir utilizando la palabra clave cookie. en la palabra clave del servidor a continuación.

opción httpchk: Esta opción indica habilitar la función de detección del estado del servicio HTTP. Como equilibrador de carga profesional, HAProxy admite comprobaciones de estado en los nodos de servicio de backend especificados en la parte de backend para garantizar que cuando un nodo en el backend no pueda funcionar, las solicitudes de los clientes provenientes del frontend se distribuyan al backend en otros nodos en buen estado para garantizar. la disponibilidad del servicio global.

El uso de la opción httpchk es el siguiente: option httpchk lt; Methodgt; urigt lt; : significa habilitar este servidor backend. Realizar una verificación del estado de salud.

inter: establece el intervalo de tiempo para la verificación del estado de salud, en milisegundos.

rise: establece el número de comprobaciones exitosas necesarias para pasar del estado de error al estado normal. Por ejemplo, "subida 2" significa que el servidor se considera disponible si 2 comprobaciones son correctas.

caída: establece el número de comprobaciones necesarias para que el servidor backend pase de un estado normal a un estado no disponible. Por ejemplo, "caída 3" significa que el servidor se considerará no disponible si falla 3 comprobaciones. .

Cookie: establece el valor de la cookie para el servidor backend especificado. El valor especificado aquí se comprobará cuando se solicite entrada. El servidor backend seleccionado para este valor por primera vez se utilizará en solicitudes posteriores. Seleccionado, su propósito es lograr la función de conexiones persistentes. El "servidor de cookies1" anterior indica que el ID del servidor de web1 es servidor1. De la misma manera, "servidor de cookies2" significa que el serverid de web2 es server2.

Peso: establece el peso del servidor real back-end. El valor predeterminado es 1 y el valor máximo es 256. Establezca en 0 para no participar en el equilibrio de carga.

copia de seguridad: configura el servidor de respaldo del servidor real backend, que solo se habilita cuando todos los servidores reales backend no están disponibles.

Utilice nginx para invertir el back-end de los dos hosts tomcat para separar lo dinámico y lo estático. Si termina en jsp, se enviará al back-end; de lo contrario, se entregará a. nginx para su procesamiento.

Cree aplicaciones en dos hosts Tomcat

Configuración de nginx

Luego se logra la separación de lo dinámico y lo estático, y también implementamos la rigidez de la sesión basada en uri