a configuração
Eu administro o back-end de um site que existe atualmente em um único nó usando Nginx (webserver), Neo4J (banco de dados) e Wildfly (servidor de aplicativos). O site está recebendo tráfego suficiente para que tenhamos recursos de armazenamento e memória limitados no nó 'all-in-one' atual, então instanciei mais dois nós VPS (3 no total) que executarão apenas o WildFly.
Eu configurei o Nginx com sucesso para usar o recurso de balanceamento de carga 'hash' nos 3 nós com base em um ID de usuário contido no URI do site para garantir que os usuários sejam roteados consistentemente para o mesmo nó VPS executando o Wildfly para otimizar o armazenamento em cache.
Cada um dos 3 nós tem seu próprio bloco de armazenamento de alta disponibilidade de 150 GB (mantido pelo provedor VPS) que contém um único /imagesdiretório montado no qual o aplicativo Wildfly estará lendo/gravando arquivos de imagem de/para seu respectivo nó.
Atualizar
Os arquivos de imagem devem ser escritos uma vez/ler muitos (pelo menos para o caso nominal) para que novas imagens sejam criadas o tempo todo, mas as imagens existentes raramente são atualizadas. Além disso, devido ao balanceamento de carga de hash do Nginx, cada nó do Wildfly deve ter todas as imagens necessárias para os clientes que são roteados para ele. A necessidade de replicação é realmente dupla:
- Ele torna a adição ou remoção de nós do Wildfly transparente, pois cada nó possui todos os dados dos outros nós
- Facilita o backup, pois tudo é consolidado em um só lugar
Além disso, cada um dos nós VPS faz parte de uma VLAN gigabit privada que o provedor VPS habilita para todos os nós no mesmo datacenter (dos quais estão todos os meus nós). Será esse link que os dados de replicação percorrerão.
O problema
Como o aplicativo agora está distribuído, desejo que cada um dos /imagesdiretórios nos 3 nós seja totalmente replicado. Embora o balanceamento de carga 'hash' do Nginx garanta o uso consistente do nó por usuário, quero que o conteúdo do /imagesdiretório seja uma união de todos os três nós no caso de um dos nós cair e os usuários precisarem ser redistribuídos entre os outros nós disponíveis.
A questão
Qual é a melhor maneira de resolver o problema acima? Pelo que entendi, rsyncnão é a ferramenta apropriada para este trabalho. Há esta pergunta de falha do servidor que é de natureza semelhante, mas tem 12 anos e tenho certeza de que houve alguns avanços na replicação de dados desde então.
Em minha pesquisa, encontrei o GlusterFS , que parece promissor, mas não está claro como configurar isso para resolver meu problema. Eu tornaria cada um dos dispositivos de armazenamento em bloco de alta disponibilidade em cada nó um único 'tijolo' e então combinaria isso em um único volume Gluster? Presumo que criei o /imagesdiretório neste único volume Gluster e o montei em cada um dos nós por meio do cliente FUSE nativo? Meu instinto diz que isso não está correto porque cada um dos nós são clientes e servidores simultaneamente, pois ambos estão contribuindo com um 'tijolo' e lendo/gravando no volume Gluster, o que parece não convencional.