MariaDB
 sql >> Baza danych >  >> RDS >> MariaDB

Wdrożenie w wielu chmurach do replikacji MariaDB przy użyciu WireGuard

W tym poście na blogu przyjrzymy się, jak wdrożyć konfigurację replikacji MariaDB w środowisku wielu chmur. Załóżmy, że nasza główna aplikacja znajduje się w AWS, najlepszym pomysłem jest skonfigurowanie AWS jako głównego centrum danych obsługującego master MariaDB. Urządzenie podrzędne MariaDB będzie hostowane w GCP, a ClusterControl znajduje się w infrastrukturze chmury prywatnej firmy w biurze. Wszystkie są połączone za pomocą prostego i bezpiecznego tunelu WireGuard VPN w zakresie IP 192.168.50.0/24. ClusterControl użyje tego interfejsu VPN do zdalnego wdrażania, zarządzania i monitorowania wszystkich węzłów bazy danych.

Oto nasi gospodarze:

  • Amazon Web Service (AWS):
    • Host:Mistrz MariaDB
    • Publiczny adres IP:54.151.183.93
    • Prywatny adres IP:10.15.3.170/24 (VPC)
    • IPN VPN:192.168.50.101
    • System operacyjny:Ubuntu 18.04.4 LTS (Bionic)
    • Specyfikacja:t2.medium (2 vCPU, 4 GB pamięci)
  • Google Cloud Platform (GCP): 
    • Host:MariaDB slave
    • Publiczny adres IP:35.247.147.95
    • Prywatny adres IP:10.148.0.9/32
    • IPN VPN:192.168.50.102
    • System operacyjny:Ubuntu 18.04.4 LTS (Bionic)
    • Specyfikacja:n1-standard-1 (1 vCPU, 3,75 GB pamięci)
  • Prywatna chmura VMware (biuro):
    • Host:ClusterControl
    • Publiczny adres IP:3.25.96.229
    • Prywatny adres IP:192.168.55.138/24
    • IPN VPN:192.168.50.100
    • System operacyjny:Ubuntu 18.04.4 LTS (Bionic)
    • Specyfikacja:prywatna chmura VMWare (2 procesory, 2 GB pamięci RAM)

Nasza ostateczna architektura będzie wyglądać mniej więcej tak:

Mapowanie hostów w /etc/hosts na wszystkich węzłach to:

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

Konfiguracja mapowania hostów uprości nasze zarządzanie rozwiązywaniem nazw między hostami, gdzie podczas konfigurowania węzłów Wireguard będziemy używać nazwy hosta zamiast adresu IP.

Instalacja WireGuard dla VPN

Ponieważ wszystkie serwery znajdują się w trzech różnych miejscach, które są połączone tylko przez sieć publiczną, zamierzamy skonfigurować tunelowanie VPN między wszystkimi węzłami za pomocą Wireguard. Dodamy nowy interfejs sieciowy w każdym węźle dla tej komunikacji z następującą wewnętrzną konfiguracją IP:

  • 192.168.50.100 — ClusterControl (chmura prywatna Office)
  • 192.168.50.101 — Master MariaDB (AWS)
  • 192.168.50.102 — MariaDB slave (GCP)

Zainstaluj Wireguard, jak pokazano na tej stronie, na wszystkich trzech węzłach:

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

W przypadku hostów Ubuntu, po prostu zaakceptuj wartość domyślną, jeśli zostaniesz o to poproszony podczas instalacji wireguard. Pamiętaj, że bardzo ważne jest, aby zaktualizować system operacyjny do najnowszej wersji, aby Wireguard działał.

Uruchom ponownie hosta, aby załadować moduł jądra Wireguard:

$ reboot

Po uruchomieniu skonfiguruj mapowanie hostów w /etc/hosts na wszystkich węzłach na coś takiego:

$ 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

Konfiguracja Wireguard

** Wszystkie kroki opisane w tej sekcji należy wykonać na wszystkich węzłach, chyba że określono inaczej.

1) We wszystkich węzłach jako użytkownik root wygeneruj klucz prywatny i przypisz bezpieczne uprawnienia

$ umask 077
$ wg genkey > /root/private

2) Następnie dodaj nowy interfejs o nazwie wg0:

$ ip link add wg0 type wireguard

3) Dodaj odpowiedni adres IP do interfejsu wg0:

Dla hosta „cc”:

$ ip addr add 192.168.50.100/32 dev wg0

Dla hosta „aws1”:

$ ip addr add 192.168.50.101/32 dev wg0

Dla hosta „gcp2”:

$ ip addr add 192.168.50.102/32 dev wg0

4) Ustaw port nasłuchiwania na 55555 i przypisz wygenerowany klucz prywatny do interfejsu Wireguard:

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

5) Uruchom interfejs sieciowy:

$ ip link set wg0 up

6) Po uruchomieniu interfejsu zweryfikuj poleceniem „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

Teraz jesteśmy gotowi, aby je wszystkie połączyć.

Podłączanie hostów przez interfejs Wireguard

Teraz dodamy wszystkie węzły jako równorzędne i pozwolimy im komunikować się ze sobą. Polecenie wymaga 4 ważnych parametrów:

  • rówieśnik :Klucz publiczny dla hosta docelowego.
  • dozwolone-IP :adres IP hosta, z którym może się komunikować.
  • punkt końcowy :Host, Wireguard i port nasłuchiwania (tu konfigurujemy wszystkie węzły do ​​korzystania z portu 55555).
  • trwałe utrzymanie :Ponieważ NAT i zapory stanowe śledzą „połączenia”, jeśli peer za NAT lub zapora sieciowa chce odbierać przychodzące pakiety, musi zachować poprawność mapowania NAT/zapory, przez okresowe wysyłanie pakietów utrzymywania aktywności. Wartość domyślna to 0 (wyłączone).

Dlatego w cc hosta musimy dodać „aws1” i „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

Na hoście „aws1” musimy dodać cc i 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

Na hoście "gcp2" musimy dodać cc i 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

Z każdego hosta spróbuj pingować się nawzajem i upewnij się, że otrzymasz odpowiedzi:

(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

Sprawdź wyjście „wg”, aby zweryfikować aktualny stan. Oto wynik z punktu widzenia hosta 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

Cały status wygląda dobrze. Możemy zobaczyć punkty końcowe, status uzgadniania i status przepustowości między węzłami. Nadszedł czas, aby ta konfiguracja stała się trwała w pliku konfiguracyjnym, aby można ją było łatwo załadować przez WireGuard. Przechowamy go w pliku znajdującym się w /etc/wireguard/wg0.conf. Najpierw utwórz plik:

$ touch /etc/wireguard/wg0.conf

Następnie wyeksportuj konfigurację środowiska wykonawczego dla interfejsu wg0 i zapisz ją w wg0.conf za pomocą polecenia „wg-quick”:

$ wg-quick save wg0

Sprawdź zawartość pliku konfiguracyjnego (przykład dla hosta "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

Command wg-quick zapewnia kilka fajnych skrótów do zarządzania i konfiguracji interfejsów WireGuard. Użyj tego narzędzia, aby podnieść lub wyłączyć interfejs sieciowy:

(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

Na koniec instruujemy systemd, aby załadował ten interfejs bezpośrednio podczas uruchamiania:

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

W tym momencie nasza konfiguracja VPN jest zakończona i możemy teraz rozpocząć wdrażanie.

Wdrażanie replikacji MariaDB

Gdy każdy węzeł w architekturze będzie mógł się ze sobą komunikować, nadszedł czas, aby przejść do ostatniego kroku wdrażania naszej replikacji MariaDB za pomocą ClusterControl.

Zainstaluj ClusterControl na cc:

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

Postępuj zgodnie z instrukcjami, aż instalacja się zakończy. Następnie musimy skonfigurować bezhasłowe SSH z hosta ClusterControl do obu węzłów MariaDB. Najpierw wygeneruj klucz SSH dla użytkownika root:

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

Skopiuj zawartość klucza publicznego z katalogu /root/.ssh/id_rsa.pub do węzłów MariaDB w katalogu /root/.ssh/authorized_keys. Zakłada to, że root może łączyć się przez SSH z hostem. W przeciwnym razie skonfiguruj demona SSH, aby odpowiednio na to zezwolić. Sprawdź, czy protokół SSH bez hasła jest poprawnie skonfigurowany. W węźle ClusterControl wykonaj zdalne polecenie SSH i upewnij się, że otrzymasz poprawną odpowiedź bez pytania o hasło:

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

Możemy teraz wdrożyć naszą replikację MariaDB. Otwórz przeglądarkę internetową i przejdź do interfejsu użytkownika ClusterControl pod adresem http://public_ip_of_CC/clustercontrol, utwórz login superadministratora. Przejdź do Wdróż -> Replikacja MySQL i określ następujące dane:

Następnie wybierz „MariaDB” jako dostawcę w wersji 10.4. Podaj również hasło roota MariaDB. W sekcji „Definiuj topologię” określ adres IP Wireguard (wg0) węzłów MariaDB, podobnie jak na poniższym zrzucie ekranu:

Kliknij Wdróż i poczekaj na zakończenie wdrażania. Po zakończeniu powinieneś zobaczyć następujące informacje:

Nasza konfiguracja replikacji MariaDB działa teraz w trzech różnych lokalizacjach (biuro, AWS i GCP), połączonych bezpiecznym tunelowaniem VPN między węzłami.


  1. Database
    2.   
  2. Mysql
    3.   
  3. Oracle
    4.   
  4. Sqlserver
    5.   
  5. PostgreSQL
    6.   
  6. Access
    7.   
  7. SQLite
    8.   
  8. MariaDB

  1. MariaDB UCASE() Objaśnienie

  2. Jak działa WEIGHT_STRING() w MariaDB

  3. Jak zwrócić nazwy miesiąca i dnia w innym języku w MariaDB?

  4. Pierwsze kroki z MariaDB przy użyciu Dockera, Java Spring i JDBC

  5. Laravel:Określony klucz był za długi; maksymalna długość klucza to 767 bajtów