I den första delen slutade vi med ett fungerande cmon HA-kluster:
[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)Vi har tre noder igång, en agerar som ledare och de återstående är följare, som är tillgängliga (de tar emot hjärtslag och svarar på dem). Den återstående utmaningen är att konfigurera UI-åtkomst på ett sätt som gör att vi alltid kan komma åt UI på ledarnoden. I det här blogginlägget kommer vi att presentera en av de möjliga lösningarna som gör att du kan åstadkomma just det.
Konfigurera HAProxy
Det här problemet är inte nytt för oss. Med varje replikeringskluster, MySQL eller PostgreSQL spelar det ingen roll, det finns en enda nod dit vi ska skicka våra skrivningar till. Ett sätt att åstadkomma det skulle vara att använda HAProxy och lägga till några externa kontroller som testar nodens tillstånd och baserat på det returnerar korrekta värden. Detta är i princip vad vi ska använda för att lösa vårt problem. Vi kommer att använda HAProxy som en väl beprövad lager 4-proxy och vi kommer att kombinera den med lager 7 HTTP-kontroller som vi kommer att skriva just för vårt användningsfall. Först till kvarn, låt oss installera HAProxy. Vi kommer att samlokalisera den med ClusterControl, men den kan lika väl installeras på en separat nod (helst noder - för att ta bort HAProxy som den enda punkten för fel).
apt install haproxyDetta ställer in HAProxy. När det är klart måste vi introducera vår konfiguration:
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 checkDu kanske vill ändra några av sakerna här som nod- eller backend-namnen som här inkluderar IP:n för vår nod. Du kommer definitivt att vilja byta servrar som du kommer att ha inkluderad i din HAProxy.
De viktigaste bitarna är:
bind *:81HAProxy lyssnar på port 81.
option httpchkVi har aktiverat lager 7-kontroll på backend-noderna.
default-server port 9201 inter 20s downinter 30s rise 2 fall 2 slowstart 60s maxconn 64 maxqueue 128 weight 100Layer 7-kontrollen kommer att utföras på port 9201.
När detta är gjort, starta HAProxy.
Konfigurera xinetd och Check Script
Vi kommer att använda xinetd för att utföra kontrollen och returnera korrekta svar till HAProxy. Steg som beskrivs i detta stycke ska utföras på alla cmon HA-klusternoder.
Installera först xinetd:
[email protected]:~# apt install xinetdNär detta är gjort måste vi lägga till följande rad:
cmonhachk 9201/tcptill /etc/services - detta gör att xinetd kan öppna en tjänst som lyssnar på port 9201. Sedan måste vi lägga till själva tjänstefilen. Det bör finnas i /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
}Äntligen behöver vi kontrollskriptet som anropas av xinetd. Enligt definitionen i servicefilen finns den i /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)När du har skapat filen, se till att den är körbar:
chmod u+x /usr/local/sbin/cmonhachk.pyIdén bakom det här skriptet är att det testar statusen för noderna med kommandot "s9s controller --list --long" och sedan kontrollerar det utdata som är relevant för IP:n som det kan hitta på lokal nod. Detta gör att skriptet kan avgöra om värden som det körs på är en ledare eller inte. Om noden är ledaren returnerar skriptet "HTTP/1.1 200 OK"-kod, som HAProxy tolkar som att noden är tillgänglig och dirigerar trafiken till den. Annars returnerar det "HTTP/1.1 503 Service Unavailable", vilket behandlas som en nod, som inte är frisk och trafiken kommer inte att dirigeras dit. Som ett resultat, oavsett vilken nod som kommer att bli en ledare, kommer HAProxy att upptäcka den och markera den som tillgänglig i backend:
Du kan behöva starta om HAProxy och xinetd för att tillämpa konfigurationsändringar innan alla delar kommer att börja fungera korrekt.
Att ha mer än en HAProxy säkerställer att vi har ett sätt att komma åt ClusterControl UI även om en av HAProxy-noderna skulle misslyckas men vi har fortfarande två (eller flera) olika värdnamn eller IP att ansluta till ClusterControl UI. För att göra det mer bekvämt kommer vi att distribuera Keepalved ovanpå HAProxy. Den kommer att övervaka tillståndet för HAProxy-tjänster och tilldela virtuell IP till en av dem. Om den HAProxy skulle bli otillgänglig kommer VIP att flyttas till en annan tillgänglig HAProxy. Som ett resultat kommer vi att ha en enda ingångspunkt (VIP eller ett värdnamn kopplat till det). Stegen vi tar här måste utföras på alla noder där HAProxy har installerats.
Låt oss först installera Keepalive:
apt install keepalivedDå måste vi konfigurera det. Vi använder följande konfigurationsfil:
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
}Du bör ändra den här filen på olika noder. IP-adresser måste konfigureras korrekt och prioritet bör vara olika på alla noder. Vänligen konfigurera även VIP som är vettigt i ditt nätverk. Du kanske också vill ändra gränssnittet - vi använde eth1, vilket är där IP:n tilldelas på virtuella maskiner skapade av Vagrant.
Starta Keepalive med den här konfigurationsfilen och du bör vara igång. Så länge VIP är uppe på en HAProxy-nod bör du kunna använda den för att ansluta till rätt ClusterControl-gränssnitt:
Detta avslutar vår tvådelade introduktion till ClusterControl högt tillgängliga kluster. Som vi sa i början är detta fortfarande i betaläge men vi ser fram emot feedback från dina tester.