Avere una configurazione multi-datacenter è una topologia comune per un piano di ripristino di emergenza (DRP), ma ci sono alcune limitazioni nell'implementazione di questo tipo di ambiente.
Dovresti prima risolvere la comunicazione tra i data center utilizzando l'accesso SSH o configurando una VPN. Quindi, hai la latenza che (a seconda della configurazione) potrebbe influenzare il tuo cluster di database. Infine, dovresti pensare a come eseguire il failover. L'applicazione può accedere al nodo remoto in caso di errore del master?
In questo blog, mostreremo come implementare una configurazione multi-datacenter per PostgreSQL coprendo tutti questi punti menzionati in precedenza, alcuni dei quali utilizzando ClusterControl. Per non renderlo troppo noioso, lo divideremo in due parti. Nella prima parte tratteremo la connettività tra i data center. Il secondo riguarderà la distribuzione e la configurazione stessa, quindi iniziamo!
Obiettivo
Supponiamo che tu voglia avere la seguente topologia:
Dove hai la tua applicazione connessa a un sistema di bilanciamento del carico, un nodo database primario e un nodo standby in un data center e un altro nodo standby in un data center secondario per scopi di ripristino di emergenza. Questa potrebbe essere una configurazione minima per avere un ambiente multi-datacenter. Puoi evitare di utilizzare il bilanciamento del carico, ma in caso di failover, dovresti riconfigurare la tua applicazione per connettersi al nuovo master, quindi per evitare che ti consigliamo di usarlo, o addirittura usarne due (uno su ogni controller di dominio) per evitare punto di fallimento.
Per rendere più chiaro, assegniamo alcuni indirizzi IP pubblici sia al datacenter 1 che al 2 come esempio.
Nel datacenter 1, la rete pubblica è 35.166.37.0/24, quindi assegniamo i seguenti indirizzi IP in questo modo:
APP: 35.166.37.10
Load Balancer + ClusterControl: 35.166.37.11
Primary Node: 35.166.37.12
Standby 1 Node: 35.166.37.13Nel datacenter 2, la rete pubblica è 18.197.23.0/24, quindi:
Standby 2 Node: 18.197.23.14Connettività data center
Il primo problema potrebbe essere questo. Puoi configurare una VPN tra di loro, e questo deve essere il modo più sicuro, ma poiché abbiamo trattato una configurazione VPN in un blog precedente e per renderla il più breve possibile, li collegheremo tramite accesso SSH utilizzando chiavi private/pubbliche .
Creiamo un utente chiamato 'remoto' in tutti i nodi (per evitare di usare root):
$ useradd remote
$ passwd remote
Changing password for user remote.
New password:
Retype new password:
passwd: all authentication tokens updated successfully.E puoi aggiungerlo al file sudoers per assegnare i privilegi:
$ visudo
remote ALL=(ALL) ALLOra, nel server di bilanciamento del carico (che sarà anche il server ClusterControl), genera la coppia di chiavi per il nuovo utente:
$ su remote
$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/remote/.ssh/id_rsa):
Created directory '/home/remote/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/remote/.ssh/id_rsa.
Your public key has been saved in /home/remote/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:hgVe/unld9+r/Ynk1HM+t089A41bwxFlPYt5/q+ZyL8 [email protected]
The key's randomart image is:
+---[RSA 3072]----+
| . . .=|
| . + oo|
| . o o.o|
| o . . o+o.|
| . S o .oo= |
| . . o =.o|
| . .+.=*|
| [email protected]|
| o=EB/|
+----[SHA256]-----+
Now you will have a new directory in the homeCopia la chiave pubblica su ciascun nodo utilizzando l'indirizzo IP pubblico remoto:
$ ssh-copy-id 35.166.37.12
/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/home/remote/.ssh/id_rsa.pub"
/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
[email protected]'s password:
Number of key(s) added: 1
Now try logging into the machine, with: "ssh '35.166.37.12'"
and check to make sure that only the key(s) you wanted were added.Questo comando copierà la tua chiave pubblica sul nodo remoto nel file authorized_keys, quindi potrai accedervi utilizzando quella privata.
Quindi, prova ad accedervi:
$ ssh 35.166.37.12Assicurati di avere il traffico SSH consentito nel tuo firewall e, per renderlo più sicuro, dovresti consentirlo solo da una fonte nota (ad esempio da 35.166.37.0/24).
Ad esempio, se stai utilizzando AWS, dovresti consentire il traffico da 35.166.37.0/24 alla porta SSH in questo modo:
Oppure se stai usando IPTABLES, dovresti eseguire qualcosa del genere:
$ iptables -A INPUT -p tcp -s 35.166.37.0/24 --destination-port 22 -j ACCEPTO un comando simile se stai utilizzando una soluzione firewall diversa.
Per renderlo un po' più sicuro, consigliamo di utilizzare una porta SSH diversa da quella predefinita e potrebbe anche essere utile utilizzare uno strumento per vietare più tentativi di accesso non riusciti, come fail2ban.
Conclusione
A questo punto, se tutto è andato bene, avrai la comunicazione SSH tra i tuoi data center, quindi il passaggio successivo è distribuire il tuo cluster PostgreSQL e gestire il failover in caso di guasto, come vedremo nella seconda parte di questo blog.
