Een MariaDB Galera-cluster uitvoeren zonder tools voor containerorkestratie:deel één

Hulpprogramma's voor het orkestreren van containers vereenvoudigen de werking van een gedistribueerd systeem door containers te implementeren en opnieuw te implementeren en eventuele storingen op te lossen. Mogelijk moet u applicaties verplaatsen, bijvoorbeeld om updates, schaling of onderliggende hoststoringen af ​​te handelen. Hoewel dit geweldig klinkt, werkt het niet altijd goed met een sterk consistent databasecluster zoals Galera. U kunt databaseknooppunten niet zomaar verplaatsen, het zijn geen staatloze toepassingen. Ook is de volgorde waarin u bewerkingen op een cluster uitvoert, van groot belang. Het herstarten van een Galera-cluster moet bijvoorbeeld starten vanaf het meest geavanceerde knooppunt, anders verliest u gegevens. Daarom laten we u zien hoe u Galera Cluster op Docker kunt uitvoeren zonder een tool voor het orkestreren van containers, zodat u volledige controle heeft.

In deze blogpost gaan we onderzoeken hoe een MariaDB Galera Cluster op Docker-containers kan worden uitgevoerd met behulp van de standaard Docker-image op meerdere Docker-hosts, zonder de hulp van orkestratietools zoals Swarm of Kubernetes. Deze aanpak is vergelijkbaar met het draaien van een Galera Cluster op standaard hosts, maar het procesbeheer wordt geconfigureerd via Docker.

Voordat we verder in details treden, gaan we ervan uit dat je Docker hebt geïnstalleerd, SElinux/AppArmor hebt uitgeschakeld en de regels in iptables, firewalld of ufw hebt gewist (wat je ook gebruikt). Hieronder volgen drie speciale Docker-hosts voor ons databasecluster:

• host1.local - 192.168.55.161
• host2.local - 192.168.55.162
• host3.local - 192.168.55.163

Multi-host netwerken

Allereerst is het standaard Docker-netwerk gebonden aan de lokale host. Docker Swarm introduceert een andere netwerklaag, overlay-netwerk genaamd, die de container-internetworking uitbreidt naar meerdere Docker-hosts in een cluster genaamd Swarm. Lang voordat deze integratie tot stand kwam, waren er veel netwerkplug-ins ontwikkeld om dit te ondersteunen - Flannel, Calico, Weave zijn er enkele.

Hier gaan we Weave gebruiken als de Docker-netwerkplug-in voor multi-host-netwerken. Dit komt voornamelijk door de eenvoud om het te installeren en te laten werken, en ondersteuning voor DNS-resolver (containers die onder dit netwerk draaien, kunnen elkaars hostnaam oplossen). Er zijn twee manieren om Weave te laten werken:systemd of via Docker. We gaan het installeren als een systemd-eenheid, dus het is onafhankelijk van de Docker-daemon (anders zouden we Docker eerst moeten starten voordat Weave wordt geactiveerd).

1. Download en installeer Weave:

   $ curl -L git.io/weave -o /usr/local/bin/weave
   $ chmod a+x /usr/local/bin/weave

2. Maak een systemd-eenheidsbestand voor Weave:

   $ cat > /etc/systemd/system/weave.service << EOF
   [Unit]
   Description=Weave Network
   Documentation=http://docs.weave.works/weave/latest_release/
   Requires=docker.service
   After=docker.service
   [Service]
   EnvironmentFile=-/etc/sysconfig/weave
   ExecStartPre=/usr/local/bin/weave launch --no-restart $PEERS
   ExecStart=/usr/bin/docker attach weave
   ExecStop=/usr/local/bin/weave stop
   [Install]
   WantedBy=multi-user.target
   EOF

3. Definieer IP-adressen of hostnaam van de peers in /etc/sysconfig/weave:

   $ echo 'PEERS="192.168.55.161 192.168.55.162 192.168.55.163"' > /etc/sysconfig/weave

4. Start en schakel Weave bij opstarten in:

   $ systemctl start weave
   $ systemctl enable weave

Herhaal de bovenstaande 4 stappen op alle Docker-hosts. Verifieer met het volgende commando als je klaar bent:

$ weave status

Het aantal peers is waar we naar kijken. Het moet 3:

          ...
          Peers: 3 (with 6 established connections)
          ...

Een Galera-cluster runnen

Nu het netwerk klaar is, is het tijd om onze databasecontainers af te vuren en een cluster te vormen. De basisregels zijn:

• Container moet worden gemaakt onder --net=weave om connectiviteit met meerdere hosts te hebben.
• Containerpoorten die moeten worden gepubliceerd, zijn 3306, 4444, 4567, 4568.
• De Docker-image moet Galera ondersteunen. Als u Oracle MySQL wilt gebruiken, download dan de Codership-versie. Als je Percona's wilt, gebruik dan deze afbeelding. In deze blogpost gebruiken we MariaDB's.

De redenen waarom we MariaDB hebben gekozen als de Galera-clusterverkoper zijn:

• Galera is ingebed in MariaDB, vanaf MariaDB 10.1.
• De MariaDB-image wordt onderhouden door de Docker- en MariaDB-teams.
• Een van de meest populaire Docker-afbeeldingen die er zijn.

Het bootstrappen van een Galera-cluster moet in volgorde worden uitgevoerd. Ten eerste moet het meest actuele knooppunt worden gestart met "wsrep_cluster_address=gcomm://". Start vervolgens de resterende knooppunten met een volledig adres dat bestaat uit alle knooppunten in het cluster, bijvoorbeeld "wsrep_cluster_address=gcomm://node1,node2,node3". Om deze stappen met container te voltooien, moeten we een aantal extra stappen uitvoeren om ervoor te zorgen dat alle containers homogeen worden uitgevoerd. Dus het plan is:

1. We zouden moeten beginnen met 4 containers in deze volgorde - mariadb0 (bootstrap), mariadb2, mariadb3, mariadb1.
2. Container mariadb0 gebruikt dezelfde datadir en configdir als mariadb1.
3. Gebruik mariadb0 op host1 voor de eerste bootstrap en start vervolgens mariadb2 op host2, mariadb3 op host3.
4. Verwijder mariadb0 op host1 om plaats te maken voor mariadb1.
5. Start ten slotte mariadb1 op host1.

Aan het eind van de dag zou je een Galera-cluster met drie knooppunten hebben (mariadb1, mariadb2, mariadb3). De eerste container (mariadb0) is een tijdelijke container voor alleen bootstrapping-doeleinden, waarbij het clusteradres "gcomm://" wordt gebruikt. Het deelt dezelfde datadir en configdir met mariadb1 en wordt verwijderd zodra het cluster is gevormd (mariadb2 en mariadb3 zijn actief) en knooppunten zijn gesynchroniseerd.

Galera is standaard uitgeschakeld in MariaDB en moet worden ingeschakeld met een vlag genaamd wsrep_on (ingesteld op AAN) en wsrep_provider (ingesteld op het Galera-bibliotheekpad) plus een aantal Galera-gerelateerde parameters. We moeten dus een aangepast configuratiebestand voor de container definiëren om Galera correct te configureren.

Laten we beginnen met de eerste container, mariadb0. Maak een bestand aan onder /containers/mariadb1/conf.d/my.cnf en voeg de volgende regels toe:

$ mkdir -p /containers/mariadb1/conf.d
$ cat /containers/mariadb1/conf.d/my.cnf
[mysqld]

default_storage_engine          = InnoDB
binlog_format                   = ROW

innodb_flush_log_at_trx_commit  = 0
innodb_flush_method             = O_DIRECT
innodb_file_per_table           = 1
innodb_autoinc_lock_mode        = 2
innodb_lock_schedule_algorithm  = FCFS # MariaDB >10.1.19 and >10.2.3 only

wsrep_on                        = ON
wsrep_provider                  = /usr/lib/galera/libgalera_smm.so
wsrep_sst_method                = xtrabackup-v2

Aangezien de afbeelding niet wordt geleverd met MariaDB Backup (wat de SST-methode is die de voorkeur heeft voor MariaDB 10.1 en MariaDB 10.2), blijven we voorlopig bij xtrabackup-v2.

Om de eerste bootstrap voor het cluster uit te voeren, voert u de bootstrap-container (mariadb0) uit op host1 met de "datadir" en "conf.d" van mariadb1:

$ docker run -d \
        --name mariadb0 \
        --hostname mariadb0.weave.local \
        --net weave \
        --publish "3306" \
        --publish "4444" \
        --publish "4567" \
        --publish "4568" \
        $(weave dns-args) \
        --env MYSQL_ROOT_PASSWORD="PM7%[email protected]^1" \
        --env MYSQL_USER=proxysql \
        --env MYSQL_PASSWORD=proxysqlpassword \
        --volume /containers/mariadb1/datadir:/var/lib/mysql \
        --volume /containers/mariadb1/conf.d:/etc/mysql/mariadb.conf.d \
        mariadb:10.2.15 \
        --wsrep_cluster_address=gcomm:// \
        --wsrep_sst_auth="root:PM7%[email protected]^1" \
        --wsrep_node_address=mariadb0.weave.local

De parameters die in de bovenstaande opdracht worden gebruikt zijn:

• --naam , maakt de container met de naam "mariadb0",
• --hostnaam , wijst de container een hostnaam toe "mariadb0.weave.local",
• --net , plaatst de container in het weefnetwerk voor ondersteuning van multi-host netwerkondersteuning,
• --publiceren , stelt poorten 3306, 4444, 4567, 4568 op de container bloot aan de host,
• $(weave dns-args) , configureert DNS-resolver voor deze container. Deze opdracht kan in Docker worden vertaald als "--dns=172.17.0.1 --dns-search=weave.local.",
• --env MYSQL_ROOT_PASSWORD , het MySQL-rootwachtwoord,
• --env MYSQL_USER , maakt een "proxysql"-gebruiker aan om later te gebruiken met ProxySQL voor databaserouting,
• --env MYSQL_PASSWORD , het "proxysql" gebruikerswachtwoord,
• --volume /containers/mariadb1/datadir:/var/lib/mysql , maakt /containers/mariadb1/datadir aan als deze niet bestaat en wijs deze toe met /var/lib/mysql (MySQL-datadir) van de container (voor bootstrap-knooppunt kan dit worden overgeslagen),
• --volume /containers/mariadb1/conf.d:/etc/mysql/mariadb.conf.d , koppelt de bestanden onder directory /containers/mariadb1/conf.d van de Docker-host, in de container op /etc/mysql/mariadb.conf.d.
• mariadb:10.2.15 , gebruikt MariaDB 10.2.15 afbeelding van hier,
• --wsrep_cluster_address , Galera-verbindingsreeks voor het cluster. "gcomm://" betekent bootstrap. Voor de rest van de containers gaan we in plaats daarvan een volledig adres gebruiken.
• --wsrep_sst_auth , authenticatiereeks voor SST-gebruiker. Gebruik dezelfde gebruiker als root,
• --wsrep_node_address , de hostnaam van het knooppunt, in dit geval gaan we de FQDN gebruiken die door Weave wordt geleverd.

De bootstrap-container bevat een aantal belangrijke dingen:

• De naam, hostnaam en wsrep_node_address is mariadb0, maar het gebruikt de volumes van mariadb1.
• Het clusteradres is "gcomm://"
• Er zijn twee extra --env parameters - MYSQL_USER en MYSQL_PASSWORD. Deze parameters zullen een extra gebruiker creëren voor onze proxysql-monitoringdoeleinden.

Verifieer met het volgende commando:

$ docker ps
$ docker logs -f mariadb0

Zodra u de volgende regel ziet, geeft dit aan dat het bootstrap-proces is voltooid en dat Galera actief is:

2018-05-30 23:19:30 139816524539648 [Note] WSREP: Synchronized with group, ready for connections

Maak de map om ons aangepaste configuratiebestand in de resterende hosts te laden:

$ mkdir -p /containers/mariadb2/conf.d # on host2
$ mkdir -p /containers/mariadb3/conf.d # on host3

Kopieer vervolgens de my.cnf die we hebben gemaakt voor mariadb0 en mariadb1 naar respectievelijk mariadb2 en mariadb3:

$ scp /containers/mariadb1/conf.d/my.cnf /containers/mariadb2/conf.d/ # on host1
$ scp /containers/mariadb1/conf.d/my.cnf /containers/mariadb3/conf.d/ # on host1

Maak vervolgens nog 2 databasecontainers (mariadb2 en mariadb3) op respectievelijk host2 en host3:

$ docker run -d \
        --name ${NAME} \
        --hostname ${NAME}.weave.local \
        --net weave \
        --publish "3306:3306" \
        --publish "4444" \
        --publish "4567" \
        --publish "4568" \
        $(weave dns-args) \
        --env MYSQL_ROOT_PASSWORD="PM7%[email protected]^1" \
        --volume /containers/${NAME}/datadir:/var/lib/mysql \
        --volume /containers/${NAME}/conf.d:/etc/mysql/mariadb.conf.d \
        mariadb:10.2.15 \
        --wsrep_cluster_address=gcomm://mariadb0.weave.local,mariadb1.weave.local,mariadb2.weave.local,mariadb3.weave.local \
        --wsrep_sst_auth="root:PM7%[email protected]^1" \
        --wsrep_node_address=${NAME}.weave.local

** Vervang ${NAME} door respectievelijk mariadb2 of mariadb3.

Er is echter een vangst. Het entrypoint-script controleert de mysqld-service op de achtergrond na initialisatie van de database met behulp van MySQL root-gebruiker zonder wachtwoord. Aangezien Galera bij het opstarten automatisch synchronisatie uitvoert via SST of IST, zal het MySQL-rootgebruikerswachtwoord veranderen, waarbij het bootstrap-knooppunt wordt gespiegeld. U ziet dus de volgende fout tijdens de eerste keer opstarten:

018-05-30 23:27:13 140003794790144 [Warning] Access denied for user 'root'@'localhost' (using password: NO)
MySQL init process in progress…
MySQL init process failed.

De truc is om de mislukte containers opnieuw te starten, omdat deze keer de MySQL-datadir zou zijn gemaakt (bij de eerste poging) en het initialisatiegedeelte van de database zou overslaan:

$ docker start mariadb2 # on host2
$ docker start mariadb3 # on host3

Eenmaal gestart, verifieer door naar de volgende regel te kijken:

$ docker logs -f mariadb2
…
2018-05-30 23:28:39 139808069601024 [Note] WSREP: Synchronized with group, ready for connections

Op dit moment zijn er 3 containers actief, mariadb0, mariadb2 en mariadb3. Houd er rekening mee dat mariadb0 wordt gestart met het bootstrap-commando (gcomm://), wat betekent dat als de container in de toekomst automatisch opnieuw wordt gestart door Docker, deze mogelijk uit elkaar kan vallen met de primaire component. We moeten deze container dus verwijderen en vervangen door mariadb1, met dezelfde Galera-verbindingsreeks als de rest en dezelfde datadir en configdir gebruiken met mariadb0.

Stop eerst mariadb0 door SIGTERM te sturen (om ervoor te zorgen dat het knooppunt netjes wordt afgesloten):

$ docker kill -s 15 mariadb0

Start vervolgens mariadb1 op host1 met een vergelijkbare opdracht als mariadb2 of mariadb3:

$ docker run -d \
        --name mariadb1 \
        --hostname mariadb1.weave.local \
        --net weave \
        --publish "3306:3306" \
        --publish "4444" \
        --publish "4567" \
        --publish "4568" \
        $(weave dns-args) \
        --env MYSQL_ROOT_PASSWORD="PM7%[email protected]^1" \
        --volume /containers/mariadb1/datadir:/var/lib/mysql \
        --volume /containers/mariadb1/conf.d:/etc/mysql/mariadb.conf.d \
        mariadb:10.2.15 \
        --wsrep_cluster_address=gcomm://mariadb0.weave.local,mariadb1.weave.local,mariadb2.weave.local,mariadb3.weave.local \
        --wsrep_sst_auth="root:PM7%[email protected]^1" \
        --wsrep_node_address=mariadb1.weave.local

Deze keer hoef je de herstarttruc niet uit te voeren omdat MySQL-datadir al bestaat (gemaakt door mariadb0). Nadat de container is gestart, controleert u of de clustergrootte 3 is, de status in Primair moet staan ​​en de lokale status is gesynchroniseerd:

$ docker exec -it mariadb3 mysql -uroot "-pPM7%[email protected]^1" -e 'select variable_name, variable_value from information_schema.global_status where variable_name in ("wsrep_cluster_size", "wsrep_local_state_comment", "wsrep_cluster_status", "wsrep_incoming_addresses")'
+---------------------------+-------------------------------------------------------------------------------+
| variable_name             | variable_value                                                                |
+---------------------------+-------------------------------------------------------------------------------+
| WSREP_CLUSTER_SIZE        | 3                                                                             |
| WSREP_CLUSTER_STATUS      | Primary                                                                       |
| WSREP_INCOMING_ADDRESSES  | mariadb1.weave.local:3306,mariadb3.weave.local:3306,mariadb2.weave.local:3306 |
| WSREP_LOCAL_STATE_COMMENT | Synced                                                                        |
+---------------------------+-------------------------------------------------------------------------------+

Op dit moment ziet onze architectuur er ongeveer zo uit:

Hoewel het run-commando vrij lang is, beschrijft het goed de kenmerken van de container. Het is waarschijnlijk een goed idee om de opdracht in een script in te pakken om de uitvoeringsstappen te vereenvoudigen, of in plaats daarvan een samengesteld bestand te gebruiken.

Databaseroutering met ProxySQL

Nu hebben we drie databasecontainers lopen. De enige manier om nu toegang te krijgen tot het cluster, is door toegang te krijgen tot de gepubliceerde MySQL-poort van de individuele Docker-host, die 3306 is (kaart naar 3306 naar de container). Dus wat gebeurt er als een van de databasecontainers uitvalt? U moet de verbinding van de client handmatig overzetten naar het volgende beschikbare knoop punt. Afhankelijk van de toepassingsconnector kunt u ook een lijst met knooppunten specificeren en de connector de failover en queryrouting voor u laten doen (Connector/J, PHP mysqlnd). Anders zou het een goed idee zijn om de databasebronnen te verenigen in een enkele bron, die een service kan worden genoemd.

Dit is waar ProxySQL in beeld komt. ProxySQL kan fungeren als de query-router, waarbij de databaseverbindingen worden verdeeld, vergelijkbaar met wat "Service" in de Swarm- of Kubernetes-wereld kan doen. We hebben voor dit doel een ProxySQL Docker-image gebouwd en zullen de image voor elke nieuwe versie zo goed mogelijk onderhouden.

Voordat we de ProxySQL-container uitvoeren, moeten we het configuratiebestand voorbereiden. Het volgende is wat we hebben geconfigureerd voor proxysql1. We maken een aangepast configuratiebestand onder /containers/proxysql1/proxysql.cnf op host1:

$ cat /containers/proxysql1/proxysql.cnf
datadir="/var/lib/proxysql"
admin_variables=
{
        admin_credentials="admin:admin"
        mysql_ifaces="0.0.0.0:6032"
        refresh_interval=2000
}
mysql_variables=
{
        threads=4
        max_connections=2048
        default_query_delay=0
        default_query_timeout=36000000
        have_compress=true
        poll_timeout=2000
        interfaces="0.0.0.0:6033;/tmp/proxysql.sock"
        default_schema="information_schema"
        stacksize=1048576
        server_version="5.1.30"
        connect_timeout_server=10000
        monitor_history=60000
        monitor_connect_interval=200000
        monitor_ping_interval=200000
        ping_interval_server=10000
        ping_timeout_server=200
        commands_stats=true
        sessions_sort=true
        monitor_username="proxysql"
        monitor_password="proxysqlpassword"
}
mysql_servers =
(
        { address="mariadb1.weave.local" , port=3306 , hostgroup=10, max_connections=100 },
        { address="mariadb2.weave.local" , port=3306 , hostgroup=10, max_connections=100 },
        { address="mariadb3.weave.local" , port=3306 , hostgroup=10, max_connections=100 },
        { address="mariadb1.weave.local" , port=3306 , hostgroup=20, max_connections=100 },
        { address="mariadb2.weave.local" , port=3306 , hostgroup=20, max_connections=100 },
        { address="mariadb3.weave.local" , port=3306 , hostgroup=20, max_connections=100 }
)
mysql_users =
(
        { username = "sbtest" , password = "password" , default_hostgroup = 10 , active = 1 }
)
mysql_query_rules =
(
        {
                rule_id=100
                active=1
                match_pattern="^SELECT .* FOR UPDATE"
                destination_hostgroup=10
                apply=1
        },
        {
                rule_id=200
                active=1
                match_pattern="^SELECT .*"
                destination_hostgroup=20
                apply=1
        },
        {
                rule_id=300
                active=1
                match_pattern=".*"
                destination_hostgroup=10
                apply=1
        }
)
scheduler =
(
        {
                id = 1
                filename = "/usr/share/proxysql/tools/proxysql_galera_checker.sh"
                active = 1
                interval_ms = 2000
                arg1 = "10"
                arg2 = "20"
                arg3 = "1"
                arg4 = "1"
                arg5 = "/var/lib/proxysql/proxysql_galera_checker.log"
        }
)

De bovenstaande configuratie zal:

• configureer twee hostgroepen, de single-writer en multi-writer-groep, zoals gedefinieerd in de sectie "mysql_servers",
• stuur leesbewerkingen naar alle Galera-knooppunten (hostgroep 20) terwijl schrijfbewerkingen naar een enkele Galera-server gaan (hostgroep 10),
• plan de proxysql_galera_checker.sh,
• gebruik monitor_username en monitor_password als de controlegegevens die zijn gemaakt toen we het cluster voor het eerst opstartten (mariadb0).

Kopieer het configuratiebestand naar host2, voor ProxySQL-redundantie:

$ mkdir -p /containers/proxysql2/ # on host2
$ scp /containers/proxysql1/proxysql.cnf /container/proxysql2/ # on host1

Voer vervolgens de ProxySQL-containers uit op respectievelijk host1 en host2:

$ docker run -d \
        --name=${NAME} \
        --publish 6033 \
        --publish 6032 \
        --restart always \
        --net=weave \
        $(weave dns-args) \
        --hostname ${NAME}.weave.local \
        -v /containers/${NAME}/proxysql.cnf:/etc/proxysql.cnf \
        -v /containers/${NAME}/data:/var/lib/proxysql \
        severalnines/proxysql

** Vervang ${NAME} door respectievelijk proxysql1 of proxysql2.

We hebben --restart=always . gespecificeerd om het altijd beschikbaar te maken, ongeacht de afsluitstatus, evenals automatisch opstarten wanneer Docker-daemon start. Dit zorgt ervoor dat de ProxySQL-containers zich als een daemon gedragen.

Controleer de status van de MySQL-servers die wordt bewaakt door beide ProxySQL-instanties (OFFLINE_SOFT wordt verwacht voor de hostgroep met één schrijver):

$ docker exec -it proxysql1 mysql -uadmin -padmin -h127.0.0.1 -P6032 -e 'select hostgroup_id,hostname,status from mysql_servers'
+--------------+----------------------+--------------+
| hostgroup_id | hostname             | status       |
+--------------+----------------------+--------------+
| 10           | mariadb1.weave.local | ONLINE       |
| 10           | mariadb2.weave.local | OFFLINE_SOFT |
| 10           | mariadb3.weave.local | OFFLINE_SOFT |
| 20           | mariadb1.weave.local | ONLINE       |
| 20           | mariadb2.weave.local | ONLINE       |
| 20           | mariadb3.weave.local | ONLINE       |
+--------------+----------------------+--------------+

Op dit moment ziet onze architectuur er ongeveer zo uit:

Alle verbindingen die afkomstig zijn van 6033 (ofwel van het host1-, host2- of containernetwerk) worden met behulp van ProxySQL load-balanced naar de backend-databasecontainers. Als u toegang wilt tot een afzonderlijke databaseserver, gebruikt u in plaats daarvan poort 3306 van de fysieke host. Er is geen virtueel IP-adres als enkel eindpunt geconfigureerd voor de ProxySQL-service, maar we zouden dat kunnen hebben door Keepalive te gebruiken, wat in de volgende sectie wordt uitgelegd.

Virtueel IP-adres met Keepalive

Omdat we ProxySQL-containers hebben geconfigureerd om op host1 en host2 te draaien, gaan we Keepalive-containers gebruiken om deze hosts aan elkaar te koppelen en een virtueel IP-adres te bieden via het hostnetwerk. Hierdoor kan een enkel eindpunt voor applicaties of clients verbinding maken met de load balancing-laag die wordt ondersteund door ProxySQL.

Maak zoals gewoonlijk een aangepast configuratiebestand voor onze Keepalive-service. Hier is de inhoud van /containers/keepalived1/keepalived.conf:

vrrp_instance VI_DOCKER {
   interface ens33               # interface to monitor
   state MASTER
   virtual_router_id 52          # Assign one ID for this route
   priority 101
   unicast_src_ip 192.168.55.161
   unicast_peer {
      192.168.55.162
   }
   virtual_ipaddress {
      192.168.55.160             # the virtual IP
}

Kopieer het configuratiebestand naar host2 voor de tweede keer:

$ mkdir -p /containers/keepalived2/ # on host2
$ scp /containers/keepalived1/keepalived.conf /container/keepalived2/ # on host1

Wijzig de prioriteit van 101 naar 100 in het gekopieerde configuratiebestand op host2:

$ sed -i 's/101/100/g' /containers/keepalived2/keepalived.conf

**De instantie met hogere prioriteit houdt het virtuele IP-adres vast (in dit geval host1), totdat de VRRP-communicatie wordt onderbroken (voor het geval host1 uitvalt).

Voer vervolgens de volgende opdracht uit op respectievelijk host1 en host2:

$ docker run -d \
        --name=${NAME} \
        --cap-add=NET_ADMIN \
        --net=host \
        --restart=always \
        --volume /containers/${NAME}/keepalived.conf:/usr/local/etc/keepalived/keepalived.conf \ osixia/keepalived:1.4.4

** Vervang ${NAME} door keepalived1 en keepalived2.

Het run-commando vertelt Docker om:

• --naam , maak een container met
• --cap-add=NET_ADMIN , voeg Linux-mogelijkheden toe voor netwerkbeheerders
• --net=host , koppel de container aan het hostnetwerk. Dit levert een virtueel IP-adres op de hostinterface, ens33
• --restart=altijd , laat de container altijd draaien,
• --volume=/containers/${NAME}/keepalived.conf:/usr/local/etc/keepalived/keepalived.conf , wijs het aangepaste configuratiebestand toe voor het gebruik van de container.

Nadat beide containers zijn gestart, controleert u het bestaan ​​van het virtuele IP-adres door naar de fysieke netwerkinterface van het MASTER-knooppunt te kijken:

$ ip a | grep ens33
2: ens33: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    inet 192.168.55.161/24 brd 192.168.55.255 scope global ens33
    inet 192.168.55.160/32 scope global ens33

De clients en applicaties kunnen nu het virtuele IP-adres 192.168.55.160 gebruiken om toegang te krijgen tot de databaseservice. Dit virtuele IP-adres bestaat op dit moment op host1. Als host1 uitvalt, neemt keepalived2 het IP-adres over en brengt het naar host2. Houd er rekening mee dat de configuratie voor deze keepalive de ProxySQL-containers niet bewaakt. Het controleert alleen de VRRP-advertentie van de Keepalive-peers.

Op dit moment ziet onze architectuur er ongeveer zo uit:

Samenvatting

Dus nu hebben we een MariaDB Galera-cluster met een hoog beschikbare ProxySQL-service, allemaal uitgevoerd op Docker-containers.

In deel twee gaan we kijken hoe we deze setup kunnen beheren. We zullen bekijken hoe u bewerkingen kunt uitvoeren zoals gracieus afsluiten, bootstrapping, het detecteren van de meest geavanceerde node, failover, herstel, op-/afschalen, upgrades, back-up enzovoort. We zullen ook de voor- en nadelen bespreken van deze configuratie voor onze geclusterde databaseservice.

Veel plezier met containervervoer!