En la primera parte, terminamos con un clúster HA cmon en funcionamiento:
[email protected]:~# s9s controller --list --long
S VERSION OWNER GROUP NAME IP PORT COMMENT
l 1.7.4.3565 system admins 10.0.0.101 10.0.0.101 9501 Acting as leader.
f 1.7.4.3565 system admins 10.0.0.102 10.0.0.102 9501 Accepting heartbeats.
f 1.7.4.3565 system admins 10.0.0.103 10.0.0.103 9501 Accepting heartbeats.
Total: 3 controller(s)Tenemos tres nodos en funcionamiento, uno actúa como líder y los demás son seguidores, que son accesibles (reciben latidos y les responden). El desafío restante es configurar el acceso a la interfaz de usuario de una manera que nos permita acceder siempre a la interfaz de usuario en el nodo líder. En esta publicación de blog, presentaremos una de las posibles soluciones que le permitirá lograr precisamente eso.
Configuración de HAProxy
Este problema no es nuevo para nosotros. Con cada clúster de replicación, MySQL o PostgreSQL, no importa, hay un solo nodo al que debemos enviar nuestras escrituras. Una forma de lograrlo sería usar HAProxy y agregar algunas comprobaciones externas que prueben el estado del nodo y, en función de eso, devuelvan los valores adecuados. Esto es básicamente lo que vamos a utilizar para resolver nuestro problema. Usaremos HAProxy como un proxy de capa 4 bien probado y lo combinaremos con comprobaciones HTTP de capa 7 que escribiremos precisamente para nuestro caso de uso. Lo primero es lo primero, instalemos HAProxy. Lo ubicaremos junto con ClusterControl, pero también se puede instalar en un nodo separado (idealmente, nodos, para eliminar HAProxy como único punto de falla).
apt install haproxyEsto configura HAProxy. Una vez hecho esto, tenemos que introducir nuestra configuración:
global
pidfile /var/run/haproxy.pid
daemon
user haproxy
group haproxy
stats socket /var/run/haproxy.socket user haproxy group haproxy mode 600 level admin
node haproxy_10.0.0.101
description haproxy server
#* Performance Tuning
maxconn 8192
spread-checks 3
quiet
defaults
#log global
mode tcp
option dontlognull
option tcp-smart-accept
option tcp-smart-connect
#option dontlog-normal
retries 3
option redispatch
maxconn 8192
timeout check 10s
timeout queue 3500ms
timeout connect 3500ms
timeout client 10800s
timeout server 10800s
userlist STATSUSERS
group admin users admin
user admin insecure-password admin
user stats insecure-password admin
listen admin_page
bind *:9600
mode http
stats enable
stats refresh 60s
stats uri /
acl AuthOkay_ReadOnly http_auth(STATSUSERS)
acl AuthOkay_Admin http_auth_group(STATSUSERS) admin
stats http-request auth realm admin_page unless AuthOkay_ReadOnly
#stats admin if AuthOkay_Admin
listen haproxy_10.0.0.101_81
bind *:81
mode tcp
tcp-check connect port 80
timeout client 10800s
timeout server 10800s
balance leastconn
option httpchk
# option allbackups
default-server port 9201 inter 20s downinter 30s rise 2 fall 2 slowstart 60s maxconn 64 maxqueue 128 weight 100
server 10.0.0.101 10.0.0.101:443 check
server 10.0.0.102 10.0.0.102:443 check
server 10.0.0.103 10.0.0.103:443 checkEs posible que desee cambiar algunas de las cosas aquí, como el nodo o los nombres de back-end que incluyen aquí la IP de nuestro nodo. Definitivamente querrás cambiar los servidores que vas a incluir en tu HAProxy.
Los bits más importantes son:
bind *:81HAProxy escuchará en el puerto 81.
option httpchkHemos habilitado la verificación de capa 7 en los nodos de back-end.
default-server port 9201 inter 20s downinter 30s rise 2 fall 2 slowstart 60s maxconn 64 maxqueue 128 weight 100La verificación de la capa 7 se ejecutará en el puerto 9201.
Una vez hecho esto, inicie HAProxy.
Configurando xinetd y Verificar Script
Vamos a utilizar xinetd para ejecutar la verificación y devolver las respuestas correctas a HAProxy. Los pasos descritos en este párrafo deben ejecutarse en todos los nodos de clúster HA cmon.
Primero, instale xinetd:
[email protected]:~# apt install xinetdUna vez hecho esto, tenemos que agregar la siguiente línea:
cmonhachk 9201/tcpa /etc/services:esto permitirá que xinetd abra un servicio que escuchará en el puerto 9201. Luego, debemos agregar el archivo del servicio. Debe estar ubicado en /etc/xinetd.d/cmonhachk:
# default: on
# description: cmonhachk
service cmonhachk
{
flags = REUSE
socket_type = stream
port = 9201
wait = no
user = root
server = /usr/local/sbin/cmonhachk.py
log_on_failure += USERID
disable = no
#only_from = 0.0.0.0/0
only_from = 0.0.0.0/0
per_source = UNLIMITED
}Finalmente, necesitamos el script de verificación que llama xinetd. Como se define en el archivo de servicio, se encuentra en /usr/local/sbin/cmonhachk.py.
#!/usr/bin/python3.5
import subprocess
import re
import sys
from pathlib import Path
import os
def ret_leader():
leader_str = """HTTP/1.1 200 OK\r\n
Content-Type: text/html\r\n
Content-Length: 48\r\n
\r\n
<html><body>This node is a leader.</body></html>\r\n
\r\n"""
print(leader_str)
def ret_follower():
follower_str = """
HTTP/1.1 503 Service Unavailable\r\n
Content-Type: text/html\r\n
Content-Length: 50\r\n
\r\n
<html><body>This node is a follower.</body></html>\r\n
\r\n"""
print(follower_str)
def ret_unknown():
unknown_str = """
HTTP/1.1 503 Service Unavailable\r\n
Content-Type: text/html\r\n
Content-Length: 59\r\n
\r\n
<html><body>This node is in an unknown state.</body></html>\r\n
\r\n"""
print(unknown_str)
lockfile = "/tmp/cmonhachk_lockfile"
if os.path.exists(lockfile):
print("Lock file {} exists, exiting...".format(lockfile))
sys.exit(1)
Path(lockfile).touch()
try:
with open("/etc/default/cmon", 'r') as f:
lines = f.readlines()
pattern1 = "RPC_BIND_ADDRESSES"
pattern2 = "[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}"
m1 = re.compile(pattern1)
m2 = re.compile(pattern2)
for line in lines:
res1 = m1.match(line)
if res1 is not None:
res2 = m2.findall(line)
i = 0
for r in res2:
if r != "127.0.0.1" and i == 0:
i += 1
hostname = r
command = "s9s controller --list --long | grep {}".format(hostname)
output = subprocess.check_output(command.split())
state = output.splitlines()[1].decode('UTF-8')[0]
if state == "l":
ret_leader()
if state == "f":
ret_follower()
else:
ret_unknown()
finally:
os.remove(lockfile)Una vez que cree el archivo, asegúrese de que sea ejecutable:
chmod u+x /usr/local/sbin/cmonhachk.pyLa idea detrás de este script es que prueba el estado de los nodos usando el comando "s9s controller --list --long" y luego verifica la salida relevante para la IP que puede encontrar en el nodo local. Esto permite que el script determine si el host en el que se ejecuta es un líder o no. Si el nodo es el líder, la secuencia de comandos devuelve el código "HTTP/1.1 200 OK", que HAProxy interpreta como que el nodo está disponible y enruta el tráfico hacia él. De lo contrario, devuelve "HTTP/1.1 503 Servicio no disponible", que se trata como un nodo, que no está en buen estado y el tráfico no se enrutará allí. Como resultado, no importa qué nodo se convierta en líder, HAProxy lo detectará y lo marcará como disponible en el backend:
Es posible que deba reiniciar HAProxy y xinetd para aplicar los cambios de configuración antes de que todos los las piezas comenzarán a funcionar correctamente.
Tener más de un HAProxy garantiza que tengamos una forma de acceder a la interfaz de usuario de ClusterControl, incluso si uno de los nodos de HAProxy falla, pero todavía tenemos dos (o más) nombres de host o IP diferentes para conectarnos a la interfaz de usuario de ClusterControl. Para hacerlo más cómodo, implementaremos Keepalived sobre HAProxy. Supervisará el estado de los servicios HAProxy y asignará una IP virtual a uno de ellos. Si ese HAProxy dejara de estar disponible, el VIP se moverá a otro HAProxy disponible. Como resultado, tendremos un único punto de entrada (VIP o un nombre de host asociado). Los pasos que daremos aquí deben ejecutarse en todos los nodos donde se haya instalado HAProxy.
Primero, instalemos keepalived:
apt install keepalivedLuego tenemos que configurarlo. Usaremos el siguiente archivo de configuración:
vrrp_script chk_haproxy {
script "killall -0 haproxy" # verify the pid existance
interval 2 # check every 2 seconds
weight 2 # add 2 points of prio if OK
}
vrrp_instance VI_HAPROXY {
interface eth1 # interface to monitor
state MASTER
virtual_router_id 51 # Assign one ID for this route
priority 102
unicast_src_ip 10.0.0.101
unicast_peer {
10.0.0.102
10.0.0.103
}
virtual_ipaddress {
10.0.0.130 # the virtual IP
}
track_script {
chk_haproxy
}
# notify /usr/local/bin/notify_keepalived.sh
}Debe modificar este archivo en diferentes nodos. Las direcciones IP deben configurarse correctamente y la prioridad debe ser diferente en todos los nodos. Configure también VIP que tenga sentido en su red. También puede cambiar la interfaz:usamos eth1, que es donde se asigna la IP en las máquinas virtuales creadas por Vagrant.
Inicie el keepalived con este archivo de configuración y debería estar listo para comenzar. Siempre que VIP esté activo en un nodo HAProxy, debería poder usarlo para conectarse a la interfaz de usuario de ClusterControl adecuada:
Esto completa nuestra introducción de dos partes a los clústeres de alta disponibilidad de ClusterControl. Como dijimos al principio, esto todavía está en estado beta, pero esperamos recibir comentarios de sus pruebas.
