Cómo utilizar HAProxy configurar el equilibrio de carga HTTP en una Ubuntu VPS

HAProxy(Proxy de alta disponibilidad) es un equilibrador de carga de código abierto que puede equilibrar la carga de cualquier servicio TCP. Es especialmente adecuado para el equilibrio de carga HTTP ya que soporta la persistencia de sesión y la capa de 7 tratamiento.

Requisitos previos:

Vamos a utilizar tres servidores aquí:

Servidor 1 - equilibrador de carga
Nombre de host: haproxy
OS: Ubuntu
IP pública: 192.168.1.1
IP privada: 172.22.10.100

servidor2 - Lampl
Nombre de host: lamp1
OS: LAMP en Ubuntu
IP privada: 172.22.10.101

Server3 - lamp2
Nombre de host: lamp2
OS: LAMP en Ubuntu
IP privada: 172.22.10.102

Instalación HAProxy

Utilice el comando apt-get para instalar HAProxy.
apt-get install haproxy

Tenemos que permitir que HAProxy ser iniciado por el script de inicio.

nano / etc / default / haproxy

Ajuste la opción habilitada para 1

ENABLED = 1

Para comprobar si este cambio se realiza ejecutar correctamente el guión de inicio de HAProxy sin ningún parámetro. Debería ver la siguiente.

root @ haproxy: ~ # servicio haproxy
Uso: /etc/init.d/haproxy {start | stop | recarga | reinicio | status}

Configuración HAProxy

Vamos a pasar el archivo de configuración por defecto y crear nuestro propio.

mv /etc/haproxy/haproxy.cfg{,.original}

Crear y editar un nuevo archivo de configuración:

/etc/haproxy/haproxy.cfg nano

Comencemos añadiendo bloque de configuración en el bloque a este archivo:

global
Iniciar sesión 127.0.0.1 aviso local0
maxconn 2000
haproxy usuario
grupo haproxy

La directiva de registro menciona un servidor syslog a la que ingrese se enviarán mensajes. En Ubuntu rsyslog ya está instalada y funcionando pero no se escucha en cualquier dirección IP. Vamos a modificar los archivos de configuración de rsyslog tarde.

La directiva maxconn especifica el número de conexiones simultáneas en el frontend. El valor predeterminado es 2000 y debe ser sintonizado según la configuración de su VPS'.

Las directivas de usuario y grupo cambia el proceso HAProxy al usuario / grupo especificado. Estos no deben ser cambiados.

por defecto
ingrese mundial
modo http
opción httplog
opción dontlognull
reintentos 3
opción de reexpedición
tiempo de espera de la conexión 5000
tiempo de espera del cliente 10000
servidor de tiempo de espera 10000

Estamos especificando los valores por defecto en esta sección. Los valores que pueden modificar son las diversas directivas de tiempo de espera. La opción de conexión especifica el tiempo máximo de espera para un intento de conexión a un VPS para tener éxito.

Los tiempos de espera de cliente y servidor se aplican cuando se espera que el cliente o el servidor para reconocer o enviar datos durante el proceso de TCP. HAProxy recomienda ajustar los tiempos de espera de cliente y servidor al mismo valor.

La directiva reintentos define el número de reintentos para llevar a cabo en un VPS después de un fallo en la conexión.

La opción de reexpedición permite la redistribución sesión en caso de fallos en la conexión. Así sesión stickness está anulado si un VPS baja.

escuchar nombreaplic 0.0.0.0: 80
modo http
estadísticas permiten
Estadísticas URI / haproxy? estadísticas
Estadísticas ámbito estrictamente privado
Estadísticas de autenticación A_Username: YourPassword
Estadísticas de autenticación Another_User: passwd
equilibrio roundrobin
opción httpclose
opción forwardfor
lamp1 servidor 172.22.10.101: 80 cheque
lamp2 servidor 172.22.10.102: 80 cheque

Este contiene la configuración tanto para el frontend y backend. Estamos configurando HAProxy para escuchar en el puerto 80 para nombreaplic que es sólo un nombre para identificar una aplicación. Las directivas estadísticas permiten la página de estadísticas de conexión y la protege con autenticación básica HTTP utilizando las credenciales especificadas por la directiva las estadísticas de autenticación.

Esta página se ve con la URL mencionado en las Estadísticas uri por lo que en este caso, es http://192.168.1.1/haproxy?stats;
una demostración de esta página se puede ver aquí.

La directiva equilibrio especifica el balanceo de carga algoritmo para utilizar. Las opciones disponibles son Round Robin (roundrobin), Estático Round Robin (RR-estática), Conexiones menores (leastconn), Fuente (fuente), URI (URI) y el parámetro de URL (url_param).

La información sobre cada algoritmo puede ser obtenida de la documentación oficial.

La directiva del servidor declara un servidor back-end, la sintaxis es:

servidor

[: Puerto] [parám *]

El nombre mencionamos aquí aparecerá en registros y alertas. Hay muchos paratmeters soportados por esta directiva y que va a utilizar los parámetros de la comprobación y de la galleta en este artículo. La opción de verificación se habilita el control sanitario de los VPS de otro modo, el VPS es
considerado siempre disponibles.

Una vez que haya terminado la configuración de iniciar el servicio HAProxy:

puesta en servicio haproxy

 

Las pruebas de equilibrio de carga y conmutación por error

Para probar esta configuración, crear un script PHP en todos los servidores web (servidores back-end - LÁMPARA1 y LÁMPARA2 aquí).

/var / www / archivo.php

header ( 'Content-Type: text / plain');
echo "Server IP: ".$_SERVER['SERVER_ADDR'];
echo "nClient IP: ".$_SERVER['REMOTE_ADDR'];
echo "nX-Forwarded-for: ".$_SERVER['HTTP_X_FORWARDED_FOR'];
?>

Ahora vamos a utilizar rizo y solicitar este archivo varias veces.

> rizo http://192.168.1.1/file.php

Servidor IP: 172.22.10.101
IP del cliente: 172.22.10.100
X-reenvío para: 117.213.X.X

> rizo http://192.168.1.1/file.php

Servidor IP: 172.22.10.102
IP del cliente: 172.22.10.100
X-reenvío para: 117.213.X.X

> rizo http://192.168.1.1/file.php

Servidor IP: 172.22.10.101
IP del cliente: 172.22.10.100
X-reenvío para: 117.213.X.X

Note aquí cómo HAProxy alternativamente conmutar la conexión entre LÁMPARA1 y LÁMPARA2, así es como funciona el Round Robin. La IP del cliente que vemos aquí es la dirección IP privada del equilibrador de carga y la cabecera X-reenviado-A es su IP.

Para ver cómo funciona la conmutación por error, ir a un servidor web y detener el servicio:

lamp1 @ haproxy: ~ # parada de servicio apache2

Enviar solicitudes con el enrollamiento de nuevo para ver cómo funcionan las cosas.

sesión pegajosidad

Si su aplicación web sirve contenido dinámico basado en sesiones de conexión de los usuarios (que la aplicación no lo hace), los visitantes podrán experimentar cosas extrañas debido a la conmutación continua entre VPS. Sesión adherencia asegura que el visitante se pega a la SPV que sirvió su primera solicitud. Esto es posible mediante el etiquetado de cada servidor back-end con una galleta.

Usaremos el siguiente código PHP para demostrar cómo funciona la sesión de la pegajosidad.

/var / www / session.php

header ( 'Content-Type: text / plain');
session_start ();
if (! isset ($ _ SESSION [ 'visita']))
{
echo "This is the first time you're visiting this server";
$_SESSION [ 'visitar'] = 0;
}
más
echo "Your number of visits: ".$_SESSION['visit'];

$_SESSION [ 'visitar'] ++;

echo "nServer IP: ".$_SERVER['SERVER_ADDR'];
echo "nClient IP: ".$_SERVER['REMOTE_ADDR'];
echo "nX-Forwarded-for: ".$_SERVER['HTTP_X_FORWARDED_FOR']."n";
print_r ($ _ COOKIE);
?>

Este código crea un sesssion PHP y muestra el número de páginas vistas en una sola sesión.

método de inserción de la galleta

En este método, todas las respuestas de HAProxy al cliente contendrá un Set-Cookie: cabecera con el nombre de un servidor back-end como su valor de la cookie. Así que en el futuro el cliente (navegador web) incluirá esta cookie con todas sus peticiones y HAProxy remitirá la petición al servidor backend derecho basado en el valor de la cookie.

Para este método, tendrá que añadir la directiva de galletas y modificar las directivas de servidor bajo escuchar

SRVNAME inserción de cookies
lamp1 servidor 172.22.10.101: Verificación S1 80 galletas
lamp2 servidor 172.22.10.102: Verificación S2 80 galletas

Esto hace que HAProxy añadir un Set-Cookie: cabecera con una cookie llamada SRVNAME tener su valor como S1 o S2 en base al cual respondió la solicitud de back-end. Una vez que esto se añade el reinicio del servicio:

Reiniciar servicio haproxy

y el uso de rizo para comprobar cómo funciona esto.

> rizo -i http://192.168.1.1/session.php
HTTP / 1.1 200 DE ACUERDO
Fecha: mar, 24 Sep 2013 13: 11: 22 GMT
Servidor: Apache / 2.2.22 (Ubuntu)
X-Powered-By: PHP / 5.3.10-1ubuntu3.8
Set-Cookie: PHPSESSID = l9haakejnvnat7jtju64hmuab5; path = /
Expira: Jue, 19 Nov 1981 08: 52: 00 GMT
Cache-Control: no-store, no-cache, hay que revalidar, post-check = 0, pre-check = 0
Pragma: no-cache
Vary: Accept-Encoding
Largancia de contenido: 143
Connection: close
Content-Type: text / plain
Set-Cookie: SRVNAME = S1; path = /

Esta es la primera vez que visite este servidor
Servidor IP: 172.22.10.101
IP del cliente: 172.22.10.100
X-reenvío para: 117.213.X.X
Formación
(
)

Esta es la primera petición que hicimos y fue respondida por LÁMPARA1 como podemos ver en Set-Cookie: SRVNAME = S1; path = /. Ahora, para emular lo que un navegador web haría por la siguiente solicitud, añadimos estas galletas a la solicitud utilizando el parámetro --cookie de rizo.

> curl -i http://192.168.1.1/session.php --cookie "PHPSESSID=l9haakejnvnat7jtju64hmuab5;SRVNAME=S1;"
HTTP / 1.1 200 DE ACUERDO
Fecha: mar, 24 Sep 2013 13: 11: 45 GMT
Servidor: Apache / 2.2.22 (Ubuntu)
X-Powered-By: PHP / 5.3.10-1ubuntu3.8
Expira: Jue, 19 Nov 1981 08: 52: 00 GMT
Cache-Control: no-store, no-cache, hay que revalidar, post-check = 0, pre-check = 0
Pragma: no-cache
Vary: Accept-Encoding
Largancia de contenido: 183
Connection: close
Content-Type: text / plain

Su número de visitas: 1
Servidor IP: 172.22.10.101
IP del cliente: 172.22.10.100
X-reenvío para: 117.213.87.127
Formación
(
[PHPSESSID] => l9haakejnvnat7jtju64hmuab5
[SRVNAME] => S1
)

> curl -i http://192.168.1.1/session.php --cookie "PHPSESSID=l9haakejnvnat7jtju64hmuab5;SRVNAME=S1;"
HTTP / 1.1 200 DE ACUERDO
Fecha: mar, 24 Sep 2013 13: 11: 45 GMT
Servidor: Apache / 2.2.22 (Ubuntu)
X-Powered-By: PHP / 5.3.10-1ubuntu3.8
Expira: Jue, 19 Nov 1981 08: 52: 00 GMT
Cache-Control: no-store, no-cache, hay que revalidar, post-check = 0, pre-check = 0
Pragma: no-cache
Vary: Accept-Encoding
Largancia de contenido: 183
Connection: close
Content-Type: text / plain

Su número de visitas: 2
Servidor IP: 172.22.10.101
IP del cliente: 172.22.10.100
X-reenvío para: 117.213.87.127
Formación
(
[PHPSESSID] => l9haakejnvnat7jtju64hmuab5
[SRVNAME] => S1
)

Ambas solicitudes fueron servidos por LÁMPARA1 y la sesión se mantuvo adecuadamente. Este método es útil si se desea la adherencia para todos los archivos en el servidor web.
Método Prefijo de galletas

Por otra parte, si desea que la pegajosidad sólo para las cookies concretas o no se quiere tener una cookie separada para la sesión de la pegajosidad, la opción de prefijo es para usted.

Para utilizar este método, usar la siguiente directiva de galletas:

prefijo de la galleta PHPSESSID

El PHPSESSID se puede sustituir con su propio nombre de la cookie. La directiva del servidor sigue siendo la misma que la configuración anterior.

Ahora vamos a ver cómo funciona esto.

> rizo -i http://192.168.1.1/session.php
HTTP / 1.1 200 DE ACUERDO
Fecha: mar, 24 Sep 2013 13: 36: 27 GMT
Servidor: Apache / 2.2.22 (Ubuntu)
X-Powered-By: PHP / 5.3.10-1ubuntu3.8
Set-Cookie: PHPSESSID = S1 ~ 6l2pou1iqea4mnhenhkm787o56; path = /
Expira: Jue, 19 Nov 1981 08: 52: 00 GMT
Cache-Control: no-store, no-cache, hay que revalidar, post-check = 0, pre-check = 0
Pragma: no-cache
Vary: Accept-Encoding
Largancia de contenido: 143
Content-Type: text / plain

Esta es la primera vez que visite este servidor
Servidor IP: 172.22.10.101
IP del cliente: 172.22.10.100
X-reenvío para: 117.213.X.X
Formación
(
)

Observe cómo el servidor S1 de galletas se antepone a la cookie de sesión. Ahora, vamos a enviar dos peticiones más con esta cookie.

> curl -i http://192.168.1.1/session.php --cookie "PHPSESSID=S1~6l2pou1iqea4mnhenhkm787o56;"
HTTP / 1.1 200 DE ACUERDO
Fecha: mar, 24 Sep 2013 13: 36: 45 GMT
Servidor: Apache / 2.2.22 (Ubuntu)
X-Powered-By: PHP / 5.3.10-1ubuntu3.8
Expira: Jue, 19 Nov 1981 08: 52: 00 GMT
Cache-Control: no-store, no-cache, hay que revalidar, post-check = 0, pre-check = 0
Pragma: no-cache
Vary: Accept-Encoding
Largancia de contenido: 163
Content-Type: text / plain

Su número de visitas: 1
Servidor IP: 172.22.10.101
IP del cliente: 172.22.10.100
X-reenvío para: 117.213.X.X
Formación
(
[PHPSESSID] => 6l2pou1iqea4mnhenhkm787o56
)

> curl -i http://192.168.1.1/session.php --cookie "PHPSESSID=S1~6l2pou1iqea4mnhenhkm787o56;"
HTTP / 1.1 200 DE ACUERDO
Fecha: mar, 24 Sep 2013 13: 36: 54 GMT
Servidor: Apache / 2.2.22 (Ubuntu)
X-Powered-By: PHP / 5.3.10-1ubuntu3.8
Expira: Jue, 19 Nov 1981 08: 52: 00 GMT
Cache-Control: no-store, no-cache, hay que revalidar, post-check = 0, pre-check = 0
Pragma: no-cache
Vary: Accept-Encoding
Largancia de contenido: 163
Content-Type: text / plain

Su número de visitas: 2
Servidor IP: 172.22.10.101
IP del cliente: 172.22.10.100
X-reenvío para: 117.213.X.X
Formación
(
[PHPSESSID] => 6l2pou1iqea4mnhenhkm787o56
)

Podemos ver claramente que tanto las peticiones fueron atendidas por LÁMPARA1 y la sesión está perfectamente trabajando.

Configurar el registro de HAProxy

Cuando comenzamos a configurar HAProxy, hemos añadido una línea: log 127.0.0.1 local0 notificación que envía mensajes de registro del sistema para la dirección IP localhost. Pero por defecto, rsyslog en Ubuntu no escucha en cualquier dirección. Así que tenemos que hacer que funcione.

Editar el archivo de configuración de rsyslog.

/etc/rsyslog.conf nano

Añadir / editar / Descomentar las siguientes líneas:

$imudp MODLOAD
$UDPServerAddress 127.0.0.1
$UDPServerRun 514

Ahora rsyslog funcionará en el puerto UDP 514 en la dirección de 127.0.0.1 pero todos los mensajes HAProxy irán a / var / log / syslog así que tenemos que separarlos.

Crear una regla para los registros HAProxy.

/etc/rsyslog.d/haproxy.conf nano

Agregue la línea siguiente a la misma.

if ($ ProgramName == 'haproxy'), entonces - / var / log / haproxy.log

Ahora reinicie el servicio rsyslog:

reinicio del servicio rsyslog

Esto escribe todos los mensajes HAProxy y registros de acceso a /var/log/haproxy.log.

Keepalives en HAProxy

Bajo la directiva listen, utilizamos httpclose opción que añade un Connection: close cabecera. Esto le dice al cliente (navegador web) para cerrar una conexión después de que se reciba una respuesta.

Si desea habilitar HTTP abiertas sobre HAProxy, reemplazar la línea httpclose opción con:

http opción de servidor estrecha
tiempo de espera http-keep-alive 3000

Establecer el tiempo de espera de mantenimiento de conexión sabiamente para que algunas conexiones no drenan todos los recursos del equilibrador de carga.

Las pruebas Keepalives

Keepalives pueden ser probados usando enrollamiento mediante el envío de varias solicitudes al mismo tiempo. salida innecesaria se omitirá en el siguiente ejemplo:

rizo -v http://192.168.1.1/index.html http://192.168.1.1/index.html
A punto de conectar () para 192.168.1.1 Puerto 80 (# 0)
Molesto 192.168.1.1... conectado
GET /index.html HTTP / 1.1
User-Agent: rizo / 7.23.1 (x86_64-pc-win32) libcurl / 7.23.1 OpenSSL / 0.9.8r zlib / 1.2.5
Anfitrión: 192.168.1.1
Aceptar: */*
;
......[Salida omitida] .........
* Conexión #0 para acoger 192.168.1.1 izquierda intacta
* Reutilizando conexión existente! (# 0) con el anfitrión 192.168.1.1
* Conectado a 192.168.1.1 puerto (192.168.1.1) 80 (# 0)
GET /index.html HTTP / 1.1
User-Agent: rizo / 7.23.1 (x86_64-pc-win32) libcurl / 7.23.1 OpenSSL / 0.9.8r zlib / 1.2.5
Anfitrión: 192.168.1.1
Aceptar: */*
.......[Salida omitida] .........
* Conexión #0 para acoger 192.168.1.1 izquierda intacta
* el cierre de la conexión #0

En esta salida, tenemos que buscar la línea: La reutilización de conexión existente! (# 0) con el anfitrión 192.168.1.1, lo que indica que enrollamiento utiliza la misma conexión para realizar solicitudes posteriores.

Publicación relacionada

8 comentarios

Deja una respuesta

Este sitio utiliza para reducir el spam Akismet. Aprender cómo se procesa sus datos comentario.