MariaDB
 sql >> Base de données >  >> RDS >> MariaDB

Déploiement multi-cloud pour la réplication MariaDB à l'aide de WireGuard

Dans cet article de blog, nous allons voir comment déployer une configuration de réplication MariaDB dans un environnement multi-cloud. Supposons que notre application principale soit située chez AWS, c'est la meilleure idée de configurer AWS en tant que centre de données principal hébergeant le maître MariaDB. L'esclave MariaDB sera hébergé sur GCP et ClusterControl est situé dans l'infrastructure de cloud privé de l'entreprise au bureau. Ils sont tous connectés via un tunnel VPN simple et sécurisé WireGuard dans la plage IP 192.168.50.0/24. ClusterControl utilisera cette interface VPN pour effectuer le déploiement, la gestion et la surveillance à distance sur tous les nœuds de la base de données.

Voici nos hôtes :

  • Amazon Web Service (AWS) :
    • Hôte :maître MariaDB
    • IP publique :54.151.183.93
    • IP privée :10.15.3.170/24 (VPC)
    • IP VPN :192.168.50.101
    • SE :Ubuntu 18.04.4 LTS (Bionic)
    • Spécification :t2.medium (2 processeurs virtuels, 4 Go de mémoire)
  • Google Cloud Platform (GCP) : 
    • Hôte :esclave MariaDB
    • IP publique :35.247.147.95
    • IP privée :10.148.0.9/32
    • IP VPN :192.168.50.102
    • SE :Ubuntu 18.04.4 LTS (Bionic)
    • Spécification :n1-standard-1 (1 processeur virtuel, 3,75 Go de mémoire)
  • Cloud privé VMware (bureau) :
    • Hôte :ClusterControl
    • IP publique :3.25.96.229
    • IP privée :192.168.55.138/24
    • IP VPN :192.168.50.100
    • SE :Ubuntu 18.04.4 LTS (Bionic)
    • Spécification :Cloud privé VMWare (2 processeurs, 2 Go de RAM)

Notre architecture finale ressemblera à ceci :

Le mappage d'hôte sous /etc/hosts sur tous les nœuds est :

3.25.96.229     cc clustercontrol office.mydomain.com
54.151.183.93   aws1 db1 mariadb1 db1.mydomain.com
35.247.147.95   gcp2 db2 mariadb2 db2.mydomain.com

La configuration du mappage des hôtes simplifiera notre gestion de résolution de noms entre les hôtes, où nous utiliserons le nom d'hôte au lieu de l'adresse IP lors de la configuration des pairs Wireguard.

Installer WireGuard pour VPN

Étant donné que tous les serveurs se trouvent à trois endroits différents, qui ne sont connectés que via un réseau public, nous allons mettre en place un tunnel VPN entre tous les nœuds à l'aide de Wireguard. Nous ajouterons une nouvelle interface réseau sur chaque nœud pour cette communication avec la configuration IP interne suivante :

  • 192.168.50.100 - ClusterControl (cloud privé Office)
  • 192.168.50.101 - Maître MariaDB (AWS)
  • 192.168.50.102 - Esclave MariaDB (GCP)

Installez Wireguard comme indiqué sur cette page sur les trois nœuds :

$ sudo add-apt-repository ppa:wireguard/wireguard
$ sudo apt-get upgrade
$ sudo apt-get install wireguard

Pour les hôtes Ubuntu, acceptez simplement la valeur par défaut si vous y êtes invité lors de l'installation de wireguard. Notez qu'il est très important de mettre à niveau le système d'exploitation vers la dernière version pour que Wireguard fonctionne.

Redémarrez l'hôte pour charger le module du noyau Wireguard :

$ reboot

Une fois activé, configurez notre mappage d'hôte dans /etc/hosts sur tous les nœuds à quelque chose comme ceci :

$ cat /etc/hosts
3.25.96.229     cc clustercontrol office.mydomain.com
54.151.183.93   aws1 db1 mariadb1 db1.mydomain.com
35.247.147.95   gcp2 db2 mariadb2 db2.mydomain.com
127.0.0.1       localhost

Configurer Wireguard

** Toutes les étapes de cette section doivent être effectuées sur tous les nœuds, sauf indication contraire.

1) Sur tous les nœuds en tant qu'utilisateur root, générez une clé privée et attribuez une autorisation sécurisée

$ umask 077
$ wg genkey > /root/private

2) Ensuite, ajoutez une nouvelle interface appelée wg0 :

$ ip link add wg0 type wireguard

3) Ajoutez l'adresse IP correspondante à l'interface wg0 :

Pour l'hôte "cc":

$ ip addr add 192.168.50.100/32 dev wg0

Pour l'hôte "aws1" :

$ ip addr add 192.168.50.101/32 dev wg0

Pour l'hôte "gcp2":

$ ip addr add 192.168.50.102/32 dev wg0

4) Définissez le port d'écoute sur 55555 et attribuez la clé privée générée à l'interface Wireguard :

$ wg set wg0 listen-port 55555 private-key /root/private

5) Affichez l'interface réseau :

$ ip link set wg0 up

6) Une fois l'interface en place, vérifiez avec la commande "wg":

(cc1)$ wg
interface: wg0
  public key: sC91qhb5QI4FjBZPlwsTLNIlvuQqsALYt5LZomUFEh4=
  private key: (hidden)
  listening port: 55555
(aws1) $ wg
interface: wg0
  public key: ZLdvYjJlaS56jhEBxWGFFGprvZhtgJKwsLVj3zGonXw=
  private key: (hidden)
  listening port: 55555
(gcp2) $wg
interface: wg0
  public key: M6A18XobRFn7y7u6cg8XlEKy5Nf0ZWqNMOw/vVONhUY=
  private key: (hidden)
  listening port: 55555

Nous sommes maintenant prêts à tous les connecter.

Connexion des hôtes via l'interface Wireguard

Nous allons maintenant ajouter tous les nœuds en tant que pairs et leur permettre de communiquer entre eux. La commande nécessite 4 paramètres importants :

  • pair :Clé publique pour l'hôte cible.
  • ips autorisées :adresse IP de l'hôte avec lequel il est autorisé à communiquer.
  • point de terminaison  :L'hôte et Wireguard et le port d'écoute (ici, nous configurons tous les nœuds pour utiliser le port 55555).
  • persistent-keepalive :Parce que NAT et les pare-feu avec état gardent une trace des "connexions", si un pair derrière NAT ou un pare-feu souhaite recevoir des paquets entrants, il doit garder le mappage NAT/pare-feu valide, en envoyant périodiquement des paquets keepalive. La valeur par défaut est 0 (désactiver).

Par conséquent, sur l'hôte cc, nous devons ajouter "aws1" et "gcp2":

$ wg set wg0 peer ZLdvYjJlaS56jhEBxWGFFGprvZhtgJKwsLVj3zGonXw= allowed-ips 192.168.50.101/32 endpoint aws1:55555 persistent-keepalive 25
$ wg set wg0 peer M6A18XobRFn7y7u6cg8XlEKy5Nf0ZWqNMOw/vVONhUY= allowed-ips 192.168.50.102/32 endpoint gcp2:55555 persistent-keepalive 25

Sur l'hôte "aws1", nous devons ajouter le cc et le gcp2 :

$ wg set wg0 peer sC91qhb5QI4FjBZPlwsTLNIlvuQqsALYt5LZomUFEh4= allowed-ips 192.168.50.100/32 endpoint cc:55555 persistent-keepalive 25
$ wg set wg0 peer M6A18XobRFn7y7u6cg8XlEKy5Nf0ZWqNMOw/vVONhUY= allowed-ips 192.168.50.102/32 endpoint gcp2:55555 persistent-keepalive 25

Sur l'hôte "gcp2", nous devons ajouter le cc et aws1 :

$ wg set wg0 peer sC91qhb5QI4FjBZPlwsTLNIlvuQqsALYt5LZomUFEh4= allowed-ips 192.168.50.100/32 endpoint gcp2:55555 persistent-keepalive 25
$ wg set wg0 peer ZLdvYjJlaS56jhEBxWGFFGprvZhtgJKwsLVj3zGonXw= allowed-ips 192.168.50.101/32 endpoint aws1:55555 persistent-keepalive 25

Depuis chaque hôte, essayez de vous pinger et assurez-vous d'obtenir des réponses :

(cc)$ ping 192.168.50.101 # aws1
(cc)$ ping 192.168.50.102 # gcp2
(aws1)$ ping 192.168.50.101 # cc
(aws1)$ ping 192.168.50.102 # gcp2
(gcp2)$ ping 192.168.50.100 # cc
(gcp2)$ ping 192.168.50.101 # aws1

Vérifiez la sortie "wg" pour vérifier l'état actuel. Voici la sortie du point de vue de l'hôte cc :

interface: wg0
  public key: sC91qhb5QI4FjBZPlwsTLNIlvuQqsALYt5LZomUFEh4=
  private key: (hidden)
  listening port: 55555

peer: M6A18XobRFn7y7u6cg8XlEKy5Nf0ZWqNMOw/vVONhUY=
  endpoint: 35.247.147.95:55555
  allowed ips: 192.168.50.102/32
  latest handshake: 34 seconds ago
  transfer: 4.70 KiB received, 6.62 KiB sent
  persistent keepalive: every 25 seconds

peer: ZLdvYjJlaS56jhEBxWGFFGprvZhtgJKwsLVj3zGonXw=
  endpoint: 54.151.183.93:55555
  allowed ips: 192.168.50.101/32
  latest handshake: 34 seconds ago
  transfer: 3.12 KiB received, 9.05 KiB sent
  persistent keepalive: every 25 seconds

Tous les statuts semblent bons. Nous pouvons voir les points de terminaison, l'état de la poignée de main et l'état de la bande passante entre les nœuds. Il est temps de rendre cette configuration persistante dans un fichier de configuration, afin qu'elle puisse être chargée facilement par WireGuard. Nous allons le stocker dans un fichier situé dans /etc/wireguard/wg0.conf. Tout d'abord, créez le fichier :

$ touch /etc/wireguard/wg0.conf

Ensuite, exportez la configuration d'exécution pour l'interface wg0 et enregistrez-la dans wg0.conf à l'aide de la commande "wg-quick" :

$ wg-quick save wg0

Vérifiez le contenu du fichier de configuration (exemple pour l'hôte "cc") :

(cc)$ cat /etc/wireguard/wg0.conf
[Interface]
Address = 192.168.50.100/24
ListenPort = 55555
PrivateKey = UHIkdA0ExCEpCOL/iD0AFaACE/9NdHYig6CyKb3i1Xo=

[Peer]
PublicKey = ZLdvYjJlaS56jhEBxWGFFGprvZhtgJKwsLVj3zGonXw=
AllowedIPs = 192.168.50.101/32
Endpoint = 54.151.183.93:55555
PersistentKeepalive = 25

[Peer]
PublicKey = M6A18XobRFn7y7u6cg8XlEKy5Nf0ZWqNMOw/vVONhUY=
AllowedIPs = 192.168.50.102/32
Endpoint = 35.247.147.95:55555
PersistentKeepalive = 25

La commande wg-quick fournit des raccourcis sympas pour gérer et configurer les interfaces WireGuard. Utilisez cet outil pour activer ou désactiver l'interface réseau :

(cc)$ wg-quick down wg0
[#] ip link delete dev wg0

(cc)$ wg-quick up wg0
[#] ip link add wg0 type wireguard
[#] wg setconf wg0 /dev/fd/63
[#] ip -4 address add 192.168.50.100/24 dev wg0
[#] ip link set mtu 8921 up dev wg0

Enfin, nous demandons à systemd de charger cette interface directement au démarrage :

$ systemctl enable [email protected]
Created symlink /etc/systemd/system/multi-user.target.wants/[email protected] → /lib/systemd/system/[email protected]

À ce stade, notre configuration VPN est terminée et nous pouvons maintenant commencer le déploiement.

Déploiement de la réplication MariaDB

Une fois que tous les nœuds de l'architecture peuvent communiquer entre eux, il est temps de passer à l'étape finale pour déployer notre réplication MariaDB à l'aide de ClusterControl.

Installez ClusterControl sur cc :

(cc)$ wget https://severalnines.com/downloads/cmon/install-cc
(cc)$ chmod 755 install-cc
(cc)$ ./install-cc

Suivez les instructions jusqu'à ce que l'installation soit terminée. Ensuite, nous devons configurer un SSH sans mot de passe depuis l'hôte ClusterControl vers les deux nœuds MariaDB. Tout d'abord, générez une clé SSH pour l'utilisateur root :

(cc)$ whoami
root
(cc)$ ssh-keygen -t rsa # press Enter for all prompts

Copiez le contenu de la clé publique dans /root/.ssh/id_rsa.pub sur les nœuds MariaDB sous /root/.ssh/authorized_keys. Cela suppose que root est autorisé à se connecter en SSH à l'hôte. Sinon, configurez le démon SSH pour autoriser cela en conséquence. Vérifiez que SSH sans mot de passe est correctement configuré. Sur le nœud ClusterControl, exécutez la commande SSH distante et assurez-vous d'obtenir une réponse correcte sans aucune invite de mot de passe :

(cc)$ ssh 192.168.50.101 "hostname"
aws1
(cc)$ ssh 192.168.50.102 "hostname"
gcp2

Nous pouvons maintenant déployer notre réplication MariaDB. Ouvrez un navigateur Web et accédez à l'interface utilisateur de ClusterControl à l'adresse http://public_ip_of_CC/clustercontrol, créez une connexion d'utilisateur super administrateur. Accédez à Déployer -> Réplication MySQL et spécifiez ce qui suit :

Ensuite, choisissez "MariaDB" comme fournisseur avec la version 10.4. Spécifiez également le mot de passe root MariaDB. Sous la section "Définir la topologie", spécifiez l'adresse IP Wireguard (wg0) des nœuds MariaDB, similaire à la capture d'écran suivante :

Cliquez sur Déployer et attendez que le déploiement soit terminé. Une fois cela fait, vous devriez voir ceci :

Notre configuration de réplication MariaDB s'exécute désormais sur trois emplacements différents (bureau, AWS et GCP), connectés à un tunnel VPN sécurisé entre les nœuds.