Tener una configuración de centro de datos múltiple es una topología común para un plan de recuperación ante desastres (DRP), pero existen algunas limitaciones en torno a la implementación de este tipo de entorno.
Primero debe resolver la comunicación entre los centros de datos utilizando acceso SSH o configurando una VPN. Luego, tiene la latencia que (dependiendo de la configuración) podría afectar su clúster de base de datos. Finalmente, debe pensar en cómo realizar la conmutación por error. ¿Puede la aplicación acceder al nodo remoto en caso de falla maestra?
En este blog, mostraremos cómo implementar una configuración de múltiples centros de datos para PostgreSQL que cubra todos estos puntos mencionados anteriormente, algunos de ellos usando ClusterControl. Para no hacerlo demasiado aburrido, lo dividiremos en dos partes. En la primera parte, cubriremos la conectividad entre los centros de datos. El segundo será sobre la implementación y la configuración en sí, ¡así que comencemos!
Objetivo
Digamos que desea tener la siguiente topología:
Donde tiene su aplicación conectada a un equilibrador de carga, un nodo de base de datos principal , y un nodo en espera en un centro de datos y otro nodo en espera en un centro de datos secundario para fines de recuperación ante desastres. Esta podría ser una configuración mínima para tener un entorno de varios centros de datos. Puede evitar el uso del equilibrador de carga, pero en caso de conmutación por error, debe volver a configurar su aplicación para conectarse al nuevo maestro, por lo que le recomendamos que lo use, o incluso use dos de ellos (uno en cada DC) para evitar uno solo. punto de falla.
Para que quede más claro, asignemos algunas direcciones IP públicas a los centros de datos 1 y 2 como ejemplo.
En el centro de datos 1, la red pública es 35.166.37.0/24, así que asignemos las siguientes direcciones IP de esta manera:
APP: 35.166.37.10
Load Balancer + ClusterControl: 35.166.37.11
Primary Node: 35.166.37.12
Standby 1 Node: 35.166.37.13En el centro de datos 2, la red pública es 18.197.23.0/24, entonces:
Standby 2 Node: 18.197.23.14Conectividad del centro de datos
El primer problema podría ser este. Puede configurar una VPN entre ellos, y esa debe ser la forma más segura, pero como cubrimos una configuración de VPN en un blog anterior, y para que sea lo más breve posible, los conectaremos a través del acceso SSH usando claves privadas/públicas. .
Vamos a crear un usuario llamado 'remoto' en todos los nodos (para evitar usar root):
$ useradd remote
$ passwd remote
Changing password for user remote.
New password:
Retype new password:
passwd: all authentication tokens updated successfully.Y puede agregarlo al archivo sudoers para asignar privilegios:
$ visudo
remote ALL=(ALL) ALLAhora, en el servidor del equilibrador de carga (que también será el servidor de ClusterControl), genere el par de claves para el nuevo usuario:
$ 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 homeCopie la clave pública a cada nodo utilizando la dirección IP pública remota:
$ 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.Este comando copiará su clave pública al nodo remoto en el archivo authorized_keys, por lo que accederá usando la privada.
Luego, intente acceder a ellos:
$ ssh 35.166.37.12Asegúrese de tener permitido el tráfico SSH en su cortafuegos y, para hacerlo más seguro, debe permitirlo solo desde una fuente conocida (por ejemplo, desde 35.166.37.0/24).
Por ejemplo, si usa AWS, debe permitir el tráfico de 35.166.37.0/24 al puerto SSH de esta manera:
O si está utilizando IPTABLES, debe ejecutar algo como esto:
$ iptables -A INPUT -p tcp -s 35.166.37.0/24 --destination-port 22 -j ACCEPTO un comando similar si está utilizando una solución de firewall diferente.
Para hacerlo un poco más seguro, recomendamos usar un puerto SSH diferente al predeterminado, y también podría ser útil usar alguna herramienta para prohibir múltiples intentos fallidos de acceder a él, como fail2ban.
Conclusión
En este punto, si todo salió bien, tendrá comunicación SSH entre sus centros de datos, por lo que el siguiente paso es implementar su clúster PostgreSQL y administrar la conmutación por error en caso de falla, como veremos en la segunda parte de este blog.
