Dans la première partie, nous nous sommes retrouvés avec un cluster cmon HA fonctionnel :
[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)Nous avons trois nœuds opérationnels, l'un agit en tant que leader et les autres sont des suiveurs, qui sont accessibles (ils reçoivent des battements de cœur et y répondent). Le défi restant consiste à configurer l'accès à l'interface utilisateur de manière à nous permettre de toujours accéder à l'interface utilisateur sur le nœud principal. Dans cet article de blog, nous présenterons l'une des solutions possibles qui vous permettra d'accomplir exactement cela.
Configurer HAProxy
Ce problème n'est pas nouveau pour nous. Avec chaque cluster de réplication, MySQL ou PostgreSQL, peu importe, il n'y a qu'un seul nœud vers lequel nous devons envoyer nos écritures. Une façon d'y parvenir serait d'utiliser HAProxy et d'ajouter des vérifications externes qui testent l'état du nœud et, sur cette base, renvoient les valeurs appropriées. C'est essentiellement ce que nous allons utiliser pour résoudre notre problème. Nous utiliserons HAProxy comme un proxy de couche 4 bien testé et nous le combinerons avec des vérifications HTTP de couche 7 que nous écrirons précisément pour notre cas d'utilisation. Tout d'abord, installons HAProxy. Nous le colocaliserons avec ClusterControl, mais il peut également être installé sur un nœud séparé (idéalement, des nœuds - pour supprimer HAProxy comme point de défaillance unique).
apt install haproxyCela configure HAProxy. Une fois cela fait, nous devons introduire notre configuration :
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 checkVous voudrez peut-être changer certaines des choses ici comme les noms de nœud ou de backend qui incluent ici l'IP de notre nœud. Vous voudrez certainement changer les serveurs que vous allez avoir inclus dans votre HAProxy.
Les éléments les plus importants sont :
bind *:81HAProxy écoutera sur le port 81.
option httpchkNous avons activé la vérification de la couche 7 sur les nœuds principaux.
default-server port 9201 inter 20s downinter 30s rise 2 fall 2 slowstart 60s maxconn 64 maxqueue 128 weight 100La vérification de la couche 7 sera exécutée sur le port 9201.
Une fois cela fait, démarrez HAProxy.
Configuration de xinetd et du script de vérification
Nous allons utiliser xinetd pour exécuter la vérification et renvoyer les réponses correctes à HAProxy. Les étapes décrites dans ce paragraphe doivent être exécutées sur tous les nœuds de cluster cmon HA.
Tout d'abord, installez xinetd :
[email protected]:~# apt install xinetdUne fois cela fait, nous devons ajouter la ligne suivante :
cmonhachk 9201/tcpà /etc/services - cela permettra à xinetd d'ouvrir un service qui écoutera sur le port 9201. Ensuite, nous devons ajouter le fichier de service lui-même. Il devrait être situé dans /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
}Enfin, nous avons besoin du script de vérification appelé par xinetd. Comme défini dans le fichier de service, il se trouve dans /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)Une fois le fichier créé, assurez-vous qu'il est exécutable :
chmod u+x /usr/local/sbin/cmonhachk.pyL'idée derrière ce script est qu'il teste l'état des nœuds à l'aide de la commande "s9s controller --list --long", puis il vérifie la sortie relative à l'IP qu'il peut trouver sur le nœud local. Cela permet au script de déterminer si l'hôte sur lequel il est exécuté est un leader ou non. Si le nœud est le leader, le script renvoie le code "HTTP/1.1 200 OK", que HAProxy interprète comme le nœud est disponible et y achemine le trafic. Sinon, il renvoie "HTTP/1.1 503 Service Unavailable", qui est traité comme un nœud, qui n'est pas sain et le trafic n'y sera pas acheminé. Par conséquent, quel que soit le nœud qui deviendra leader, HAProxy le détectera et le marquera comme disponible dans le backend :
Vous devrez peut-être redémarrer HAProxy et xinetd pour appliquer les modifications de configuration avant tous les les pièces commenceront à fonctionner correctement.
Avoir plus d'un HAProxy garantit que nous avons un moyen d'accéder à l'interface utilisateur de ClusterControl même si l'un des nœuds HAProxy échoue, mais nous avons toujours deux (ou plusieurs) noms d'hôte ou IP différents pour se connecter à l'interface utilisateur de ClusterControl. Pour le rendre plus confortable, nous allons déployer Keepalived sur HAProxy. Il surveillera l'état des services HAProxy et attribuera une adresse IP virtuelle à l'un d'entre eux. Si ce HAProxy devenait indisponible, le VIP serait déplacé vers un autre HAProxy disponible. En conséquence, nous aurons un point d'entrée unique (VIP ou un nom d'hôte qui lui est associé). Les étapes que nous allons suivre ici doivent être exécutées sur tous les nœuds où HAProxy a été installé.
Tout d'abord, installons keepalived :
apt install keepalivedEnsuite, nous devons le configurer. Nous utiliserons le fichier de configuration suivant :
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
}Vous devez modifier ce fichier sur différents nœuds. Les adresses IP doivent être configurées correctement et la priorité doit être différente sur tous les nœuds. Veuillez également configurer le VIP qui a du sens dans votre réseau. Vous pouvez également modifier l'interface - nous avons utilisé eth1, qui est l'endroit où l'adresse IP est attribuée sur les machines virtuelles créées par Vagrant.
Démarrez le keepalived avec ce fichier de configuration et vous devriez être prêt à partir. Tant que VIP est activé sur un nœud HAProxy, vous devriez pouvoir l'utiliser pour vous connecter à l'interface utilisateur ClusterControl appropriée :
Ceci termine notre introduction en deux parties aux clusters hautement disponibles de ClusterControl. Comme nous l'avons indiqué au début, il s'agit toujours d'un état bêta, mais nous attendons avec impatience les commentaires de vos tests.
