Ter uma configuração de vários datacenters é uma topologia comum para um Plano de Recuperação de Desastres (DRP), mas há algumas limitações na implementação desse tipo de ambiente.
Você deve primeiro resolver a comunicação entre os data centers usando o acesso SSH ou configurando uma VPN. Então, você tem a latência que (dependendo da configuração) pode afetar seu cluster de banco de dados. Por fim, você deve pensar em como executar o failover. O aplicativo pode acessar o nó remoto em caso de falha do mestre?
Neste blog, mostraremos como implementar uma configuração multi-datacenter para PostgreSQL cobrindo todos esses pontos mencionados anteriormente, alguns deles usando ClusterControl. Para não ficar muito chato, vamos dividi-lo em duas partes. Na primeira parte, abordaremos a conectividade entre os data centers. O segundo será sobre a implantação e configuração em si, então vamos começar!
Objetivo
Digamos que você queira ter a seguinte topologia:
Onde você tem seu aplicativo conectado a um balanceador de carga, um nó de banco de dados primário , e um nó em espera em um datacenter e outro nó em espera em um datacenter secundário para fins de DR. Essa pode ser uma configuração mínima para ter um ambiente de vários datacenters. Você pode evitar o uso do load balancer, mas em caso de failover, você deve reconfigurar sua aplicação para se conectar ao novo master, então para evitar que recomendamos usá-lo, ou até mesmo usar dois deles (um em cada DC) para evitar um único ponto de falha.
Para deixar mais claro, vamos atribuir alguns endereços IP públicos aos datacenters 1 e 2 como exemplo.
No datacenter 1, a rede pública é 35.166.37.0/24, então vamos atribuir os seguintes endereços IP desta forma:
APP: 35.166.37.10
Load Balancer + ClusterControl: 35.166.37.11
Primary Node: 35.166.37.12
Standby 1 Node: 35.166.37.13No datacenter 2, a rede pública é 18.197.23.0/24, portanto:
Standby 2 Node: 18.197.23.14Conectividade do data center
O primeiro problema pode ser este. Você pode configurar uma VPN entre eles, e essa deve ser a maneira mais segura, mas como abordamos uma configuração de VPN em um blog anterior, e para torná-lo o mais curto possível, vamos conectá-los via acesso SSH usando chaves privadas/públicas .
Vamos criar um usuário chamado 'remote' em todos os nós (para evitar o uso de root):
$ useradd remote
$ passwd remote
Changing password for user remote.
New password:
Retype new password:
passwd: all authentication tokens updated successfully.E você pode adicioná-lo ao arquivo sudoers para atribuir privilégios:
$ visudo
remote ALL=(ALL) ALLAgora, no servidor load balancer (que também será o servidor ClusterControl), gere o par de chaves para o novo usuário:
$ 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 a chave pública para cada nó usando o endereço IP público 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.Este comando irá copiar sua chave pública para o nó remoto no arquivo authorized_keys, então você irá acessá-la usando a chave privada.
Em seguida, tente acessá-los:
$ ssh 35.166.37.12Certifique-se de ter o tráfego SSH permitido em seu firewall e, para torná-lo mais seguro, permita apenas de uma fonte conhecida (por exemplo, de 35.166.37.0/24).
Por exemplo, se você estiver usando a AWS, deverá permitir o tráfego de 35.166.37.0/24 para a porta SSH desta forma:
Ou se você estiver usando IPTABLES, você deve executar algo assim:
$ iptables -A INPUT -p tcp -s 35.166.37.0/24 --destination-port 22 -j ACCEPTOu um comando semelhante se você estiver usando uma solução de firewall diferente.
Para torná-lo um pouco mais seguro, recomendamos usar uma porta SSH diferente da padrão, e também pode ser útil usar alguma ferramenta para banir várias tentativas falhadas de acessá-lo, como fail2ban.
Conclusão
Neste ponto, se tudo correu bem, você terá comunicação SSH entre seus data centers, então o próximo passo é implantar seu cluster PostgreSQL e gerenciar o failover em caso de falha, como veremos na segunda parte deste blog.
