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.
O modelo SAN supõe que você tenha um serviço de armazenamento em bloco altamente disponível - você pode implementar o mesmo no nível do arquivo - mas isso significaria adicionar mais nós (ou colocar carga de trabalho adicional em seus hosts existentes). E tornar o NFS altamente disponível é um pouco complicado.
Outra opção para replicação em nível de bloco é usar o DRBD. Mas com sistemas de arquivos convencionais, não é uma boa ideia ter o sistema de arquivos montado por mais de um host. Pode ser usado em combinação com, por exemplo, GFS2. Mas isso ainda é bastante complexo e esotérico. Combinado com o cache HTTP no proxy reverso, você pode ter o cache como o local preferido, o servidor da Web "principal" em seguida e o armazenamento local como uma terceira opção de fallback, o que significa que você ainda está lidando com a maioria das leituras no sistema de arquivos local, mas só tem um problema de atraso de replicação se um nó estiver inativo.
Depois, há sistemas de arquivos que se replicam - o GlusterFS é provavelmente a melhor escolha aqui, e sua interpretação de como ele funciona parece precisa - mas suas preocupações não; é exatamente assim que o glusterFS deve ser usado.
Você mencionou o VPS: o hipervisor já pode fornecer um mecanismo para compartilhar um dispositivo de bloco em vários hosts (por exemplo, io2 na AWS, volumes compartilhados e armazenamento de diretório no Proxmox), mas você ainda precisaria usar um sistema de arquivos paralelo (GFS2) aqui.
Uma menção rápida aqui para a replicação do ZFS - o que é ótimo, mas só funciona entre 2 nós.
Mas, na verdade, sua escolha depende de 2 predicados específicos que você não abordou em sua pergunta: Com que rapidez os arquivos são alterados? Como eles são alterados? Talvez tudo o que você precisa seja algo como lsyncd (há links para outras soluções na documentação) ou talvez até rsync.