Provozování clusteru MariaDB Galera bez nástrojů pro orchestraci kontejnerů:Část první

Nástroje pro orchestraci kontejnerů zjednodušují běh distribuovaného systému nasazením a přemístěním kontejnerů a řešením případných selhání. Možná bude potřeba přesouvat aplikace, např. kvůli zpracování aktualizací, škálování nebo základních selhání hostitele. I když to zní skvěle, ne vždy to funguje dobře se silně konzistentním databázovým clusterem, jako je Galera. Databázové uzly nemůžete jen tak přesouvat, nejsou to bezstavové aplikace. Velký význam má také pořadí, ve kterém provádíte operace na clusteru. Například restartování clusteru Galera musí začít od nejpokročilejšího uzlu, jinak ztratíte data. Proto vám ukážeme, jak spustit Galera Cluster na Dockeru bez nástroje pro orchestraci kontejnerů, abyste měli úplnou kontrolu.

V tomto blogovém příspěvku se podíváme na to, jak spustit MariaDB Galera Cluster na kontejnerech Docker pomocí standardního obrazu Docker na více hostitelích Docker, bez pomoci nástrojů pro orchestraci, jako je Swarm nebo Kubernetes. Tento přístup je podobný spuštění Galera Clusteru na standardních hostitelích, ale správa procesů se konfiguruje pomocí Dockeru.

Než přejdeme k podrobnostem, předpokládáme, že jste nainstalovali Docker, deaktivovali SElinux/AppArmor a vyčistili pravidla uvnitř iptables, firewalld nebo ufw (podle toho, co používáte). Následují tři vyhrazení hostitelé Docker pro náš databázový cluster:

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

Síť pro více hostitelů

Za prvé, výchozí síť Dockeru je vázána na místního hostitele. Docker Swarm představuje další síťovou vrstvu nazvanou překryvná síť, která rozšiřuje mezisíťovou komunikaci kontejneru na více hostitelů Docker v clusteru zvaném Swarm. Dlouho předtím, než tato integrace vstoupila do praxe, bylo vyvinuto mnoho síťových pluginů, které to podporují – Flannel, Calico, Weave jsou některé z nich.

Zde budeme používat Weave jako síťový plugin Docker pro vícehostitelské sítě. To je způsobeno především jednoduchostí instalace a spuštěním a podporou DNS resolveru (kontejnery běžící pod touto sítí si mohou vzájemně překládat hostitelské jméno). Weave lze spustit dvěma způsoby – systemd nebo prostřednictvím Dockeru. Chystáme se ji nainstalovat jako systémovou jednotku, takže je nezávislá na démonu Docker (jinak bychom museli nejprve spustit Docker, než se aktivuje Weave).

1. Stáhněte a nainstalujte Weave:

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

2. Vytvořte soubor systemd unit pro 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. Definujte IP adresy nebo název hostitele protějšku v /etc/sysconfig/weave:

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

4. Spusťte a povolte Weave při spuštění:

   $ systemctl start weave
   $ systemctl enable weave

Opakujte výše uvedené 4 kroky na všech hostitelích Docker. Po dokončení ověřte pomocí následujícího příkazu:

$ weave status

Počet vrstevníků je to, o co se staráme. Mělo by to být 3:

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

Spuštění clusteru Galera

Nyní je síť připravena, je čas spustit naše databázové kontejnery a vytvořit cluster. Základní pravidla jsou:

• Kontejner musí být vytvořen pod --net=weave, aby bylo možné připojit více hostitelů.
• Porty kontejneru, které je třeba publikovat, jsou 3306, 4444, 4567, 4568.
• Obraz Dockeru musí podporovat Galera. Pokud chcete používat Oracle MySQL, získejte verzi Codership. Pokud byste chtěli Percona, použijte tento obrázek. V tomto příspěvku na blogu používáme MariaDB.

Důvody, proč jsme vybrali MariaDB jako dodavatele clusteru Galera, jsou:

• Galera je začleněna do MariaDB, počínaje MariaDB 10.1.
• Obrázek MariaDB udržují týmy Docker a MariaDB.
• Jeden z nejpopulárnějších obrázků Docker.

Bootstrapping Galera Cluster musí být prováděn postupně. Za prvé, nejaktuálnější uzel musí začínat "wsrep_cluster_address=gcomm://". Poté spusťte zbývající uzly s úplnou adresou sestávající ze všech uzlů v clusteru, např. "wsrep_cluster_address=gcomm://node1,node2,node3". K provedení těchto kroků pomocí kontejneru musíme provést několik dalších kroků, abychom zajistili, že všechny kontejnery běží homogenně. Takže plán je:

1. Potřebovali bychom začít se 4 kontejnery v tomto pořadí – mariadb0 (bootstrap), mariadb2, mariadb3, mariadb1.
2. Kontejner mariadb0 bude používat stejný datadir a configdir jako mariadb1.
3. Pro první bootstrap použijte mariadb0 na hostiteli1, poté spusťte mariadb2 na hostiteli2 a mariadb3 na hostiteli3.
4. Odstraňte mariadb0 na hostiteli1 a uvolněte místo mariadb1.
5. Nakonec spusťte mariadb1 na hostiteli1.

Na konci dne byste měli tříuzlový cluster Galera (mariadb1, mariadb2, mariadb3). První kontejner (mariadb0) je přechodný kontejner pouze pro účely bootstrapingu, s adresou clusteru "gcomm://". Sdílí stejný datadir a configdir s mariadb1 a bude odstraněn po vytvoření clusteru (mariadb2 a mariadb3 jsou aktivní) a synchronizaci uzlů.

Ve výchozím nastavení je Galera v MariaDB vypnutá a je třeba ji povolit pomocí příznaku wsrep_on (nastaveno na ON) a wsrep_provider (nastaveno na cestu knihovny Galera) plus řada parametrů souvisejících s Galera. Potřebujeme tedy definovat vlastní konfigurační soubor pro kontejner, abychom mohli Galera správně nakonfigurovat.

Začněme prvním kontejnerem, mariadb0. Vytvořte soubor pod /containers/mariadb1/conf.d/my.cnf a přidejte následující řádky:

$ 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

Protože obrázek není dodáván se zálohou MariaDB (což je preferovaná metoda SST pro MariaDB 10.1 a MariaDB 10.2), zůstaneme prozatím u xtrabackup-v2.

Chcete-li provést první bootstrap pro cluster, spusťte bootstrap kontejner (mariadb0) na hostiteli1 s mariadb1 s "datadir" a "conf.d":

$ 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

Parametry použité ve výše uvedeném příkazu jsou:

• --name , vytvoří kontejner s názvem "mariadb0",
• --hostname , přiřadí kontejneru název hostitele "mariadb0.weave.local",
• -net , umístí kontejner do sítě weave pro podporu síťování s více hostiteli,
• -publikovat , zpřístupní hostiteli porty 3306, 4444, 4567, 4568 na kontejneru,
• $(weave dns-args) , nakonfiguruje DNS resolver pro tento kontejner. Tento příkaz lze přeložit do běhu Dockeru jako "--dns=172.17.0.1 --dns-search=weave.local.",
• --env MYSQL_ROOT_PASSWORD , heslo root MySQL,
• --env MYSQL_USER , vytvoří uživatele "proxysql", který bude později použit s ProxySQL pro směrování databáze,
• --env MYSQL_PASSWORD , uživatelské heslo „proxysql“,
• --volume /containers/mariadb1/datadir:/var/lib/mysql , vytvoří /containers/mariadb1/datadir, pokud neexistuje, a namapuje jej pomocí /var/lib/mysql (datadir MySQL) kontejneru (pro uzel bootstrap to lze přeskočit),
• --volume /containers/mariadb1/conf.d:/etc/mysql/mariadb.conf.d , připojí soubory v adresáři /containers/mariadb1/conf.d hostitele Dockeru do kontejneru na adrese /etc/mysql/mariadb.conf.d.
• mariadb:10.2.15 , používá obrázek MariaDB 10.2.15 odtud,
• --wsrep_cluster_address , Připojovací řetězec Galera pro cluster. "gcomm://" znamená bootstrap. Pro zbytek kontejnerů budeme místo toho používat úplnou adresu.
• --wsrep_sst_auth , ověřovací řetězec pro uživatele SST. Použijte stejného uživatele jako root,
• --wsrep_node_address , název hostitele uzlu, v tomto případě použijeme FQDN poskytované Weave.

Bootstrap kontejner obsahuje několik klíčových věcí:

• Název, název hostitele a adresa_uzlu wsrep je mariadb0, ale používá svazky mariadb1.
• Adresa clusteru je "gcomm://"
• Existují dva další parametry --env – MYSQL_USER a MYSQL_PASSWORD. Tyto parametry vytvoří dalšího uživatele pro naše účely monitorování proxysql.

Ověřte pomocí následujícího příkazu:

$ docker ps
$ docker logs -f mariadb0

Jakmile uvidíte následující řádek, znamená to, že proces bootstrap je dokončen a Galera je aktivní:

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

Vytvořte adresář pro načtení našeho vlastního konfiguračního souboru do zbývajících hostitelů:

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

Poté zkopírujte soubor my.cnf, který jsme vytvořili pro mariadb0 a mariadb1, do mariadb2 a 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

Dále vytvořte další 2 databázové kontejnery (mariadb2 a mariadb3) na hostiteli2 a hostiteli3:

$ 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

** Nahraďte ${NAME} mariadb2 nebo mariadb3.

Má to však háček. Skript vstupního bodu kontroluje službu mysqld na pozadí po inicializaci databáze pomocí kořenového uživatele MySQL bez hesla. Protože Galera při spouštění automaticky provádí synchronizaci prostřednictvím SST nebo IST, heslo uživatele root MySQL se změní a bude zrcadlit uzel s bootstrapem. Při prvním spuštění se tedy zobrazí následující chyba:

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.

Trik je restartovat neúspěšné kontejnery ještě jednou, protože tentokrát by byl vytvořen datadir MySQL (při prvním pokusu o spuštění) a přeskočil by část inicializace databáze:

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

Po spuštění ověřte na následujícím řádku:

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

V tomto okamžiku běží 3 kontejnery, mariadb0, mariadb2 a mariadb3. Vezměte na vědomí, že mariadb0 se spouští pomocí příkazu bootstrap (gcomm://), což znamená, že pokud bude kontejner v budoucnu automaticky restartován Dockerem, mohl by se potenciálně oddělit od primární komponenty. Proto musíme tento kontejner odstranit a nahradit jej mariadb1 pomocí stejného připojovacího řetězce Galera se zbytkem a použít stejný datadir a configdir s mariadb0.

Nejprve zastavte mariadb0 odesláním SIGTERM (abyste zajistili, že uzel bude řádně vypnut):

$ docker kill -s 15 mariadb0

Poté spusťte mariadb1 na hostiteli1 pomocí podobného příkazu jako mariadb2 nebo 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

Tentokrát nemusíte trik restartovat, protože datadir MySQL již existuje (vytvořen mariadb0). Po spuštění kontejneru ověřte, že velikost clusteru je 3, stav musí být Primární a místní stav je synchronizován:

$ 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                                                                        |
+---------------------------+-------------------------------------------------------------------------------+

V tuto chvíli naše architektura vypadá asi takto:

Přestože je příkaz run poměrně dlouhý, dobře popisuje vlastnosti kontejneru. Pravděpodobně je dobré zabalit příkaz do skriptu, aby se zjednodušily kroky provádění, nebo místo toho použít nový soubor.

Směrování databáze pomocí ProxySQL

Nyní máme spuštěny tři databázové kontejnery. Jediným způsobem, jak nyní získat přístup ke clusteru, je přístup k publikovanému portu MySQL jednotlivého hostitele Docker, což je 3306 (mapa na 3306 do kontejneru). Co se tedy stane, když jeden z databázových kontejnerů selže? Musíte ručně převzít připojení klienta k dalšímu dostupnému uzlu při selhání. V závislosti na aplikačním konektoru můžete také zadat seznam uzlů a nechat konektor provést převzetí služeb při selhání a směrování dotazů za vás (Connector/J, PHP mysqlnd). V opačném případě by bylo dobré sjednotit zdroje databáze do jediného zdroje, který lze nazvat službou.

Zde přichází na scénu ProxySQL. ProxySQL může fungovat jako směrovač dotazů a vyvažovat zátěž databázových připojení podobně, jako to umí „Služba“ ve světě Swarm nebo Kubernetes. Pro tento účel jsme vytvořili obraz ProxySQL Docker a budeme jej udržovat pro každou novou verzi s maximálním úsilím.

Než spustíme ProxySQL kontejner, musíme připravit konfigurační soubor. Následující je to, co jsme nakonfigurovali pro proxysql1. Vytvoříme vlastní konfigurační soubor pod /containers/proxysql1/proxysql.cnf na hostiteli1:

$ 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"
        }
)

Výše uvedená konfigurace:

• nakonfigurujte dvě skupiny hostitelů, skupinu single-writer a multiwriter, jak je definováno v části "mysql_servers",
• odesílat čtení do všech uzlů Galera (hostitelská skupina 20), zatímco operace zápisu půjdou na jediný server Galera (hostitelská skupina 10),
• naplánujte proxysql_galera_checker.sh,
• použijte monitor_username a monitor_password jako přihlašovací údaje k monitorování vytvořené při prvním zavedení clusteru (mariadb0).

Zkopírujte konfigurační soubor do hostitele2 pro redundanci ProxySQL:

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

Poté spusťte kontejnery ProxySQL na hostiteli1 a hostiteli2:

$ 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

** Nahraďte ${NAME} za proxysql1 nebo proxysql2.

Zadali jsme --restart=always aby byl vždy dostupný bez ohledu na stav ukončení, stejně jako automatické spuštění při spuštění démona Docker. To zajistí, že kontejnery ProxySQL budou fungovat jako démon.

Ověřte stav serverů MySQL monitorovaný oběma instancemi ProxySQL (u skupiny hostitelů s jedním zapisovačem se očekává OFFLINE_SOFT):

$ 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       |
+--------------+----------------------+--------------+

V tuto chvíli naše architektura vypadá asi takto:

Všechna připojení přicházející ze sítě 6033 (buď ze sítě hostitele1, hostitele2 nebo kontejneru) budou zátěžově vyvážena k backendovým databázovým kontejnerům pomocí ProxySQL. Pokud byste chtěli přistupovat k jednotlivému databázovému serveru, použijte místo toho port 3306 fyzického hostitele. Neexistuje žádná virtuální IP adresa jako jeden koncový bod nakonfigurovaný pro službu ProxySQL, ale mohli bychom ji získat pomocí Keepalived, což je vysvětleno v další části.

Virtuální IP adresa s Keepalived

Protože jsme nakonfigurovali kontejnery ProxySQL tak, aby běžely na hostiteli1 a hostiteli2, použijeme kontejnery Keepalived ke spojení těchto hostitelů a poskytování virtuální IP adresy prostřednictvím hostitelské sítě. To umožňuje jednomu koncovému bodu pro aplikace nebo klienty připojit se k vrstvě vyrovnávání zátěže podporované ProxySQL.

Jako obvykle vytvořte vlastní konfigurační soubor pro naši službu Keepalived. Zde je obsah /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
}

Zkopírujte konfigurační soubor do hostitele2 pro druhou instanci:

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

Změňte prioritu ze 101 na 100 v zkopírovaném konfiguračním souboru na host2:

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

**Instance s vyšší prioritou bude uchovávat virtuální IP adresu (v tomto případě hostitel1), dokud nebude komunikace VRRP přerušena (v případě výpadku hostitele1).

Poté spusťte následující příkaz na hostiteli1 a hostiteli2:

$ 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

** Nahraďte ${NAME} za keepalived1 a keepalived2.

Příkaz run říká Dockeru:

• --name , vytvořte kontejner s
• -cap-add=NET_ADMIN , přidejte možnosti systému Linux pro rozsah správce sítě
• -net=host , připojte kontejner k hostitelské síti. To poskytne virtuální IP adresu na hostitelském rozhraní, ens33
• --restart=always , vždy udržujte kontejner v chodu,
• --volume=/containers/${NAME}/keepalived.conf:/usr/local/etc/keepalived/keepalived.conf , namapujte vlastní konfigurační soubor pro použití kontejneru.

Po spuštění obou kontejnerů ověřte existenci virtuální IP adresy pohledem na fyzické síťové rozhraní uzlu MASTER:

$ 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

Klienti a aplikace mohou nyní používat virtuální IP adresu 192.168.55.160 pro přístup k databázové službě. Tato virtuální IP adresa v tuto chvíli existuje na hostiteli 1. Pokud hostitel1 selže, keepalived2 převezme IP adresu a zobrazí ji na hostiteli2. Mějte na paměti, že konfigurace pro tento keepalived nemonitoruje kontejnery ProxySQL. Sleduje pouze reklamu VRRP vrstevníků Keepalived.

V tuto chvíli naše architektura vypadá asi takto:

Shrnutí

Nyní tedy máme MariaDB Galera Cluster s vysoce dostupnou službou ProxySQL, vše běžící na kontejnerech Docker.

Ve druhé části se podíváme na to, jak toto nastavení spravovat. Podíváme se na to, jak provádět operace, jako je elegantní vypnutí, bootstrapping, detekce nejpokročilejšího uzlu, převzetí služeb při selhání, obnova, škálování nahoru/dolů, upgrady, zálohování a tak dále. Budeme také diskutovat o výhodách a nevýhodách tohoto nastavení pro naši službu klastrované databáze.

Šťastné balení kontejnerů!