V první části jsme skončili s fungujícím HA clusterem cmon:
[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)Máme spuštěny tři uzly, jeden funguje jako vedoucí a zbývající jsou sledující, kteří jsou přístupní (přijímají srdeční signály a odpovídají na ně). Zbývající výzvou je nakonfigurovat přístup k uživatelskému rozhraní způsobem, který nám umožní vždy přistupovat k uživatelskému rozhraní na vedoucím uzlu. V tomto příspěvku na blogu představíme jedno z možných řešení, které vám to umožní.
Nastavení HAProxy
Tento problém pro nás není nový. U každého replikačního clusteru, MySQL nebo PostgreSQL, na tom nezáleží, existuje jediný uzel, kam bychom měli posílat své zápisy. Jedním ze způsobů, jak toho dosáhnout, by bylo použít HAProxy a přidat nějaké externí kontroly, které otestují stav uzlu a na základě toho vrátí správné hodnoty. To je v podstatě to, co použijeme k vyřešení našeho problému. HAProxy použijeme jako osvědčenou proxy vrstvy 4 a zkombinujeme ji s kontrolami HTTP vrstvy 7, které napíšeme přesně pro náš případ použití. Nejprve si nainstalujme HAProxy. Přiřadíme jej k ClusterControl, ale lze jej také nainstalovat na samostatný uzel (ideálně na uzly – pro odstranění HAProxy jako jediného bodu selhání).
apt install haproxyToto nastaví HAProxy. Jakmile to bude hotové, musíme představit naši konfiguraci:
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 checkMožná zde budete chtít změnit některé věci, jako jsou názvy uzlu nebo backendu, které zde zahrnují IP našeho uzlu. Určitě budete chtít změnit servery, které budete mít součástí HAProxy.
Nejdůležitější bity jsou:
bind *:81HAProxy bude naslouchat na portu 81.
option httpchkNa backendových uzlech jsme povolili kontrolu vrstvy 7.
default-server port 9201 inter 20s downinter 30s rise 2 fall 2 slowstart 60s maxconn 64 maxqueue 128 weight 100Kontrola vrstvy 7 bude provedena na portu 9201.
Jakmile to uděláte, spusťte HAProxy.
Nastavení xinetd a kontrolního skriptu
Budeme používat xinetd k provedení kontroly a vrácení správných odpovědí do HAProxy. Kroky popsané v tomto odstavci by měly být provedeny na všech Cmon HA clusterových uzlech.
Nejprve nainstalujte xinetd:
[email protected]:~# apt install xinetdJakmile to uděláme, musíme přidat následující řádek:
cmonhachk 9201/tcpdo /etc/services - to umožní xinetd otevřít službu, která bude naslouchat na portu 9201. Poté musíme přidat samotný soubor služby. Měl by být umístěn v /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
}Nakonec potřebujeme kontrolní skript, který volá xinetd. Jak je definováno v souboru služby, je umístěn v /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)Jakmile soubor vytvoříte, ujistěte se, že je spustitelný:
chmod u+x /usr/local/sbin/cmonhachk.pyMyšlenka tohoto skriptu spočívá v tom, že testuje stav uzlů pomocí příkazu „s9s controller --list --long“ a poté kontroluje výstup relevantní pro IP, který může najít na místní uzel. To umožňuje skriptu určit, zda je hostitel, na kterém je spuštěn, vedoucí nebo ne. Pokud je uzel vedoucí, skript vrátí kód „HTTP/1.1 200 OK“, který HAProxy interpretuje jako uzel dostupný a směruje provoz do něj. V opačném případě vrátí „HTTP/1.1 503 Service Unavailable“, což je považováno za uzel, který není zdravý a nebude tam směrován provoz. Výsledkem je, že bez ohledu na to, který uzel se stane vedoucím, HAProxy jej detekuje a označí jej jako dostupný v backendu:
Možná bude nutné restartovat HAProxy a xinetd, aby bylo možné použít změny konfigurace před všemi části začnou správně fungovat.
Mít více než jedno HAProxy zajišťuje, že máme způsob, jak získat přístup k uživatelskému rozhraní ClusterControl, i když by jeden z uzlů HAProxy selhal, ale stále máme dva (nebo více) různé názvy hostitelů nebo IP pro připojení k uživatelskému rozhraní ClusterControl. Aby to bylo pohodlnější, nasadíme Keepalived nad HAProxy. Bude sledovat stav služeb HAProxy a jedné z nich přidělí virtuální IP. Pokud by se tato HAProxy stala nedostupnou, VIP bude přesunuta na jinou dostupnou HAProxy. V důsledku toho budeme mít jeden vstupní bod (VIP nebo název hostitele s ním spojený). Kroky, které zde provedeme, musí být provedeny na všech uzlech, kde bylo nainstalováno HAProxy.
Nejprve si nainstalujme keepalived:
apt install keepalivedPotom jej musíme nakonfigurovat. Použijeme následující konfigurační soubor:
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
}Tento soubor byste měli upravit na různých uzlech. IP adresy musí být správně nakonfigurovány a priorita by měla být na všech uzlech odlišná. Nakonfigurujte prosím také VIP, který má ve vaší síti smysl. Možná budete chtít změnit rozhraní – použili jsme eth1, což je místo, kde se IP přiděluje na virtuálních počítačích vytvořených Vagrantem.
Spusťte keepalived s tímto konfiguračním souborem a měli byste být připraveni. Dokud je VIP aktivní na jednom uzlu HAProxy, měli byste být schopni jej použít k připojení ke správnému uživatelskému rozhraní ClusterControl:
Tím je naše dvoudílné představení vysoce dostupných clusterů ClusterControl dokončeno. Jak jsme uvedli na začátku, je to stále ve stavu beta, ale těšíme se na zpětnou vazbu z vašich testů.