Avoir une configuration multi-centre de données est une topologie courante pour un plan de reprise après sinistre (DRP), mais il existe certaines limitations concernant la mise en œuvre de ce type d'environnement.
Vous devez d'abord résoudre la communication entre les centres de données en utilisant un accès SSH ou en configurant un VPN. Ensuite, vous avez la latence qui (selon la configuration) pourrait affecter votre cluster de bases de données. Enfin, vous devez réfléchir à la manière d'effectuer le basculement. L'application peut-elle accéder au nœud distant en cas de défaillance du maître ?
Dans ce blog, nous montrerons comment implémenter une configuration multi-centre de données pour PostgreSQL couvrant tous ces points mentionnés précédemment, certains d'entre eux utilisant ClusterControl. Pour ne pas le rendre trop ennuyeux, nous le diviserons en deux parties. Dans la première partie, nous aborderons la connectivité entre les centres de données. Le second concernera le déploiement et la configuration elle-même, alors commençons !
Objectif
Supposons que vous souhaitiez avoir la topologie suivante :
Où votre application est connectée à un équilibreur de charge, un nœud de base de données primaire , et un nœud de secours dans un centre de données, et un autre nœud de secours dans un centre de données secondaire à des fins de DR. Cela pourrait être une configuration minimale pour avoir un environnement multi-centre de données. Vous pouvez éviter d'utiliser l'équilibreur de charge, mais en cas de basculement, vous devez reconfigurer votre application pour vous connecter au nouveau maître, afin d'éviter que nous vous recommandons de l'utiliser, voire d'en utiliser deux (un sur chaque DC) pour éviter un seul point d'échec.
Pour que ce soit plus clair, attribuons quelques adresses IP publiques aux centres de données 1 et 2 à titre d'exemple.
Dans le centre de données 1, le réseau public est 35.166.37.0/24, attribuons donc les adresses IP suivantes de cette manière :
APP: 35.166.37.10
Load Balancer + ClusterControl: 35.166.37.11
Primary Node: 35.166.37.12
Standby 1 Node: 35.166.37.13Dans le centre de données 2, le réseau public est 18.197.23.0/24, donc :
Standby 2 Node: 18.197.23.14Connectivité du centre de données
Le premier problème pourrait être celui-ci. Vous pouvez configurer un VPN entre eux, et cela doit être le moyen le plus sûr, mais comme nous avons couvert une configuration VPN dans un blog précédent, et pour le rendre aussi court que possible, nous allons les connecter via un accès SSH en utilisant des clés privées/publiques .
Créons un utilisateur appelé "remote" dans tous les nœuds (pour éviter d'utiliser root) :
$ useradd remote
$ passwd remote
Changing password for user remote.
New password:
Retype new password:
passwd: all authentication tokens updated successfully.Et vous pouvez l'ajouter au fichier sudoers pour attribuer des privilèges :
$ visudo
remote ALL=(ALL) ALLMaintenant, dans le serveur d'équilibrage de charge (qui sera également le serveur ClusterControl), générez la paire de clés pour le nouvel utilisateur :
$ 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 homeCopiez la clé publique sur chaque nœud à l'aide de l'adresse IP publique distante :
$ 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.Cette commande copiera votre clé publique sur le nœud distant dans le fichier authorized_keys, vous y accéderez donc en utilisant la clé privée.
Ensuite, essayez d'y accéder :
$ ssh 35.166.37.12Assurez-vous que le trafic SSH est autorisé dans votre pare-feu, et pour le rendre plus sécurisé, vous devez l'autoriser uniquement à partir d'une source connue (par exemple, à partir de 35.166.37.0/24).
Par exemple, si vous utilisez AWS, vous devez autoriser le trafic de 35.166.37.0/24 vers le port SSH de cette manière :
Ou si vous utilisez IPTABLES, vous devriez exécuter quelque chose comme ceci :
$ iptables -A INPUT -p tcp -s 35.166.37.0/24 --destination-port 22 -j ACCEPTOu une commande similaire si vous utilisez une autre solution de pare-feu.
Pour le rendre un peu plus sécurisé, nous vous recommandons d'utiliser un port SSH différent de celui par défaut, et il pourrait également être utile d'utiliser un outil pour interdire plusieurs tentatives infructueuses d'y accéder, comme fail2ban.
Conclusion
A ce stade, si tout s'est bien passé, vous aurez une communication SSH entre vos centres de données, la prochaine étape consiste donc à déployer votre cluster PostgreSQL et à gérer le basculement en cas de panne, comme nous le verrons dans la deuxième partie de ce blog.
