Cómo usar HAProxy para configurar el equilibrio de carga HTTP en un VPS de Ubuntu

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 admite la persistencia de sesiones y el procesamiento de capa 7.

Requisitos previos:

Usaremos tres servidores aquí:

Server1 - Load Balancer
Nombre de host: haproxy
OS: Ubuntu
IP pública: 192.168.1.1
IP privada: 172.22.10.100

Server2 - Lamp1
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

Instalando HAProxy

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

Necesitamos habilitar HAProxy para ser iniciado por el script de inicio.

nano / etc / default / haproxy

Establezca la opción ENABLED en 1

ENABLED = 1

Para verificar si este cambio se realiza correctamente, ejecute el script de inicio de HAProxy sin ningún parámetro. Deberías ver lo siguiente.

[Email protected]: ~ # servicio haproxy
Uso: /etc/init.d/haproxy {start | stop | reload | restart | status}

Configurando HAProxy

Moderaremos el archivo de configuración predeterminado y crearemos el nuestro propio.

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

Crea y edita un nuevo archivo de configuración:

nano /etc/haproxy/haproxy.cfg

Comencemos agregando la configuración bloque por bloque a este archivo:

narrativa
registrar el aviso 127.0.0.1 local0
maxconn 2000
usuario haproxy
grupo haproxy

La directiva de registro menciona un servidor syslog al que se enviarán los mensajes de registro. En Ubuntu rsyslog ya está instalado y ejecutándose, pero no escucha en ninguna dirección IP. Modificaremos los archivos de configuración de rsyslog más adelante.

La directiva maxconn especifica el número de conexiones concurrentes en la interfaz. El valor predeterminado es 2000 y debe ajustarse según la configuración de su VPS.

Las directivas de usuario y grupo cambian el proceso HAProxy al usuario / grupo especificado. Estos no deberían ser cambiados.

por defecto
registro global
modo http
opción httplog
opción dontlognull
reintenta 3
redispatch de opción
timeout connect 5000
tiempo de espera cliente 10000
servidor de tiempo de espera 10000

Estamos especificando valores predeterminados en esta sección. Los valores que se modificarán son las diversas directivas de tiempo de espera. La opción de conexión especifica el tiempo máximo que debe esperar un intento de conexión para que un SPV tenga éxito.

Los tiempos de espera de cliente y servidor se aplican cuando se espera que el cliente o servidor confirmen o envíen datos durante el proceso de TCP. HAProxy recomienda establecer los tiempos de espera del cliente y del servidor en el mismo valor.

La directiva retries establece el número de reintentos para realizar en un VPS después de una falla de conexión.

La opción redispatch habilita la redistribución de la sesión en caso de fallas de conexión. Por lo tanto, la validez de la sesión se anula si un VPS se cae.

escuchar el nombre de la aplicación 0.0.0.0: 80
modo http
las estadísticas habilitan
stats uri / haproxy? stats
ámbito de las estadísticas estrictamente privado
stats auth A_Username: YourPassword
stats auth Another_User: passwd
balance roundrobin
opción httpclose
opción forwardfor
servidor lamp1 172.22.10.101: 80 check
servidor lamp2 172.22.10.102: 80 check

Esto contiene la configuración para el frontend y back-end. Estamos configurando HAProxy para que escuche en el puerto 80 el nombre de la aplicación, que es solo un nombre para identificar una aplicación. Las directivas estadísticas habilitan la página de estadísticas de conexión y la protegen con autenticación HTTP básica utilizando las credenciales especificadas por la directiva de autenticación de estadísticas.

Esta página se puede ver con la URL mencionada 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 de equilibrio especifica el algoritmo de equilibrio de carga que se usará. Las opciones disponibles son Round Robin (roundrobin), Round Robin estático (static-rr), Least Connections (menosconn), Source (fuente), URI (uri) y el parámetro de URL (url_param).

La información sobre cada algoritmo se puede obtener de la documentación oficial.

La directiva del servidor declara un servidor backend, la sintaxis es:

servidor

[: puerto] [param *]

El nombre que mencionamos aquí aparecerá en registros y alertas. Hay muchos parámetros admitidos por esta directiva y utilizaremos los parámetros de verificación y cookies en este artículo. La opción de verificación habilita las verificaciones de estado en el VPS; de lo contrario, el VPS se
siempre considerado disponible.

Una vez que haya terminado de configurar el servicio HAProxy:

inicio de servicio haproxy

Prueba de equilibrio de carga y conmutación por error

Para probar esta configuración, cree una secuencia de comandos PHP en todos sus servidores web (servidores backend - LAMP1 y LAMP2 aquí).

/var/www/file.php

encabezado ('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 usaremos curl y solicitaremos este archivo varias veces.

> curl http: //192.168.1.1/file.php

IP del servidor: 172.22.10.101
Cliente IP: 172.22.10.100
X-Forwarded-for: 117.213.XX

> curl http: //192.168.1.1/file.php

IP del servidor: 172.22.10.102
Cliente IP: 172.22.10.100
X-Forwarded-for: 117.213.XX

> curl http: //192.168.1.1/file.php

IP del servidor: 172.22.10.101
Cliente IP: 172.22.10.100
X-Forwarded-for: 117.213.XX

Observe aquí cómo HAProxy alteró alternativamente la conexión entre LAMP1 y LAMP2, así es como funciona Round Robin. El IP de cliente que vemos aquí es la dirección IP privada del equilibrador de carga y el encabezado X-Forwarded-For es su IP.

Para ver cómo funciona la migración tras error, vaya a un servidor web y detenga el servicio:

[Email protected]: ~ # service apache2 stop

Envía solicitudes con curl nuevamente para ver cómo funcionan las cosas.

Pegajosidad de la sesión

Si su aplicación web ofrece contenido dinámico basado en las sesiones de inicio de sesión de los usuarios (que la aplicación no), los visitantes experimentarán cosas extrañas debido al cambio continuo entre VPS. La adherencia de la sesión asegura que un visitante se quede con el VPS que atendió su primera solicitud. Esto es posible etiquetando cada servidor back-end con una cookie.

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

/var/www/session.php

encabezado ('Content-Type: text / plain');
session_start ();
if (! isset ($ _ SESSION ['visita']))
{
echo "Esta es la primera vez que visita este servidor";
$ _SESSION ['visita'] = 0;
}
más
echo "Su número de visitas:". $ _ SESSION ['visita'];

$ _SESSION ['visita'] ++;

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 una sesión de PHP y muestra el número de visitas a la página en una sola sesión.

Método de inserción de cookies

En este método, todas las respuestas de HAProxy al cliente contendrán un encabezado Set-Cookie: con el nombre de un servidor backend como su valor de cookie. De modo que, en adelante, el cliente (navegador web) incluirá esta cookie con todas sus solicitudes y HAProxy reenviará la solicitud al servidor back-end correcto en función del valor de la cookie.

Para este método, deberá agregar la directiva de cookies y modificar las directivas del servidor bajo escucha

inserción de cookie SRVNAME
servidor lamp1 172.22.10.101: 80 cookie S1 check
servidor lamp2 172.22.10.102: 80 cookie S2 check

Esto hace que HAProxy agregue un conjunto de comandos: encabezado con una cookie llamada SRVNAME que tiene su valor como S1 o S2 según el servidor que respondió la solicitud. Una vez que esto se haya agregado, reinicie el servicio:

reinicio haproxy de servicio

y usa curl para verificar cómo funciona esto.

> curl -i http: //192.168.1.1/session.php
HTTP / 1.1 200 Aceptar
Fecha: martes, 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; camino = /
Expira: Jue 19 1981 08 noviembre: 52: 00 GMT
Cache-Control: no-store, no-cache, que hay que renovar, después de la verificación = 0, previa comprobación = 0
Pragma: no-cache
Vary: Accept-Encoding
Content-Length: 143
Conexión: cerrar
Content-Type: text / plain
Set-Cookie: SRVNAME = S1; camino = /

Esta es la primera vez que visita este servidor
IP del servidor: 172.22.10.101
Cliente IP: 172.22.10.100
X-Forwarded-for: 117.213.XX
Formación
(
)

Esta es la primera solicitud que hicimos y fue respondida por LAMP1, como podemos ver en Set-Cookie: SRVNAME = S1; ruta = /. Ahora, para emular lo que haría un navegador web para la próxima solicitud, agregamos estas cookies a la solicitud utilizando el parámetro -cookie de curl.

> curl -i http: //192.168.1.1/session.php -cookie "PHPSESSID = l9haakejnvnat7jtju64hmuab5; SRVNAME = S1;"
HTTP / 1.1 200 Aceptar
Fecha: martes, 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 1981 08 noviembre: 52: 00 GMT
Cache-Control: no-store, no-cache, que hay que renovar, después de la verificación = 0, previa comprobación = 0
Pragma: no-cache
Vary: Accept-Encoding
Content-Length: 183
Conexión: cerrar
Content-Type: text / plain

Su número de visitas: 1
IP del servidor: 172.22.10.101
Cliente IP: 172.22.10.100
X-Forwarded-for: 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 Aceptar
Fecha: martes, 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 1981 08 noviembre: 52: 00 GMT
Cache-Control: no-store, no-cache, que hay que renovar, después de la verificación = 0, previa comprobación = 0
Pragma: no-cache
Vary: Accept-Encoding
Content-Length: 183
Conexión: cerrar
Content-Type: text / plain

Su número de visitas: 2
IP del servidor: 172.22.10.101
Cliente IP: 172.22.10.100
X-Forwarded-for: 117.213.87.127
Formación
(
[PHPSESSID] => l9haakejnvnat7jtju64hmuab5
[SRVNAME] => S1
)

Ambas solicitudes fueron atendidas por LAMP1 y la sesión se mantuvo adecuadamente. Este método es útil si desea compatibilidad con todos los archivos en el servidor web.
Método de prefijo de cookie

Por otro lado, si desea mantener la adherencia solo para cookies específicas o no desea tener una cookie separada para la coherencia de la sesión, la opción de prefijo es para usted.

Para usar este método, use la siguiente directiva de cookies:

Prefijo de cookie PHPSESSID

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

Ahora veamos cómo funciona esto.

> curl -i http: //192.168.1.1/session.php
HTTP / 1.1 200 Aceptar
Fecha: martes, 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 1981 08 noviembre: 52: 00 GMT
Cache-Control: no-store, no-cache, que hay que renovar, después de la verificación = 0, previa comprobación = 0
Pragma: no-cache
Vary: Accept-Encoding
Content-Length: 143
Content-Type: text / plain

Esta es la primera vez que visita este servidor
IP del servidor: 172.22.10.101
Cliente IP: 172.22.10.100
X-Forwarded-for: 117.213.XX
Formación
(
)

Observe cómo la cookie del servidor S1 está prefijada a la cookie de sesión. Ahora, enviemos dos solicitudes más con esta cookie.

> curl -i http: //192.168.1.1/session.php -cookie "PHPSESSID = S1 ~ 6l2pou1iqea4mnhenhenkm787o56;"
HTTP / 1.1 200 Aceptar
Fecha: martes, 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 1981 08 noviembre: 52: 00 GMT
Cache-Control: no-store, no-cache, que hay que renovar, después de la verificación = 0, previa comprobación = 0
Pragma: no-cache
Vary: Accept-Encoding
Content-Length: 163
Content-Type: text / plain

Su número de visitas: 1
IP del servidor: 172.22.10.101
Cliente IP: 172.22.10.100
X-Forwarded-for: 117.213.XX
Formación
(
[PHPSESSID] => 6l2pou1iqea4mnhenhkm787o56
)

> curl -i http: //192.168.1.1/session.php -cookie "PHPSESSID = S1 ~ 6l2pou1iqea4mnhenhenkm787o56;"
HTTP / 1.1 200 Aceptar
Fecha: martes, 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 1981 08 noviembre: 52: 00 GMT
Cache-Control: no-store, no-cache, que hay que renovar, después de la verificación = 0, previa comprobación = 0
Pragma: no-cache
Vary: Accept-Encoding
Content-Length: 163
Content-Type: text / plain

Su número de visitas: 2
IP del servidor: 172.22.10.101
Cliente IP: 172.22.10.100
X-Forwarded-for: 117.213.XX
Formación
(
[PHPSESSID] => 6l2pou1iqea4mnhenhkm787o56
)

Podemos ver claramente que ambas solicitudes fueron atendidas por LAMP1 y la sesión está funcionando perfectamente.

Configurar el registro para HAProxy

Cuando comenzamos a configurar HAProxy, agregamos una línea: registra el aviso de 127.0.0.1 local0 que envía mensajes syslog a la dirección IP del host local. Pero de forma predeterminada, rsyslog en Ubuntu no escucha en ninguna dirección. Entonces tenemos que hacerlo así.

Edite el archivo de configuración de rsyslog.

nano /etc/rsyslog.conf

Agregar / Editar / Descomentar las siguientes líneas:

$ ModLoad imudp
$ UDPServerAddress 127.0.0.1
$ UDPServerRun 514

Ahora rsyslog funcionará en el puerto UDP 514 en la dirección 127.0.0.1, pero todos los mensajes HAProxy irán a / var / log / syslog, por lo que debemos separarlos.

Crea una regla para los registros HAProxy.

nano /etc/rsyslog.d/haproxy.conf

Agregue la siguiente línea a él.

if ($ programname == 'haproxy') luego - / var / log / haproxy.log

Ahora reinicie el servicio rsyslog:

servicio rsyslog restart

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

Keepalives en HAProxy

Bajo la directiva listen, utilizamos la opción httpclose que agrega una conexión: close header. Esto le dice al cliente (navegador web) que cierre una conexión después de recibir una respuesta.

Si desea habilitar keep-alives en HAProxy, reemplace la opción httpclose línea con:

opción http-server-close
timeout http-keep-alive 3000

Establezca el tiempo de espera de mantener vivo sabiamente para que algunas conexiones no agoten todos los recursos del equilibrador de carga.

Probando Keepalives

Keepalives se puede probar utilizando curl mediante el envío de varias solicitudes al mismo tiempo. La salida innecesaria se omitirá en el siguiente ejemplo:

curl -v http: //192.168.1.1/index.html http: //192.168.1.1/index.html
Acerca de conectar () al puerto 192.168.1.1 80 (#0)
Probando 192.168.1.1 ... conectado
GET /index.html HTTP / 1.1
User-Agent: curl / 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 alojar 192.168.1.1 dejado intacto
* Reutilizando la conexión existente! (#0) con el host 192.168.1.1
* Conectado al puerto 192.168.1.1 (192.168.1.1) 80 (#0)
GET /index.html HTTP / 1.1
User-Agent: curl / 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 alojar 192.168.1.1 dejado intacto
* Conexión de cierre #0

En esta salida, tenemos que buscar la línea: ¡Reutilizar la conexión existente! (#0) con el host 192.168.1.1, que indica que curl usó la misma conexión para realizar solicitudes posteriores.

Publicación relacionada

8 Comentarios

Deje un comentario.

Este sitio usa Akismet para reducir el correo no deseado. Descubra cómo se procesan los datos de sus comentarios.