que sistema de arquivos distribuído para uma configuração de failover de dois nós?

Question

Estou tentando configurar uma configuração redundante que consiste em dois servidores que possuem tudo redundante:

• o banco de dados (mestre mestre MySQL no modo ativo / passivo)
• o sistema de arquivos (distribuído / replicado)
• nosso software aplicativo (mantido em sincronia usando o sistema de arquivos distribuído)

Principalmente, um dos dois servidores será o servidor "principal" e o outro replicará todos os seus dados e também será usado para distribuir a carga de trabalho (Gearman). No caso do servidor principal falhar, tudo é colocado no servidor "em espera", que se tornará o servidor "ativo" e continuará funcionando.

Para reduzir o risco de falha completa de ambos os servidores, eles são separados geograficamente em dois data centers distantes (mesmo país / conexões diretas).

Eu leio muito sobre sistemas de arquivos distribuídos, mas ainda não tenho idéia de qual solução é adequada para apenas dois nós ...

Mais alguns requisitos para o sistema de arquivos distribuídos:

• deve ser compatível com POSIX
• deve replicar tudo (todos os dados devem estar disponíveis em ambos os servidores o tempo todo) em ambas as direções (todos os dados podem ser alterados em qualquer lugar)
• estatísticas atuais relacionadas aos dados já existentes que devem ser replicados no futuro:
  • sobre 30 GB de dados , em constante crescimento desde 3 anos
  • sobre 3 milhões de arquivos em 7.500 diretórios
  • tamanho médio do arquivo aprox. 5-10 kb ; existem alguns arquivos grandes em torno de 10 a 50 MB
  Os arquivos
  • são geralmente adicionados periodicamente ao longo do dia e movidos para outro diretório depois de processados (semelhante ao servidor de e-mail baseado em arquivo)
  • uma vez por dia, alguns milhares de arquivos (recebidos no dia anterior) são arquivados em vários arquivos TAR e deixados lá "para sempre"
  • ao adicionar arquivos, os dados são gravados primeiro em um arquivo temporário que começa com um ponto "." e depois renomeado quando completo. Apenas raramente um arquivo existente está sendo alterado.
• o sistema deve lidar bem com perdas de conexão inesperadas, reinicializações de um servidor, etc.
• não há problema se a replicação atrasar 1-2 segundos, mas deve estar sempre em um estado consistente
• como dito, o distr. filesys. será composto por apenas dois nós, mas seria um grande bônus se eu pudesse adicionar nós / servidores adicionais , se eu precisasse de mais poder de computação no futuro

Atualizar / mais detalhes:

• Eu só preciso de redundância no sentido de "arquivos armazenados em ambos os servidores, sincronizados imediatamente". Ao acessar arquivos, não preciso do sistema de arquivos para ler dados do outro servidor apenas porque os discos rígidos locais falham. Quando o HDD local falha, toda a máquina do servidor é considerada "quebrada" e, portanto, deve parar o seu trabalho.

Qual sistema de arquivos seria adequado nesse cenário?

    

Answer 1

XtreemFS parece ser o que você quer alcançar. Você provavelmente pode fazer praticamente as mesmas coisas com CephFS .

    

Answer 2

Tente o DRBD. Este não é um sistema de arquivos, mas um dispositivo de bloco.

De link

Protocol A: Writes are considered to complete as soon as the local disk writes have completed, and the data packet has been placed in the send queue for the peers. In case of a node failure, data loss may occur because the data to be written to remote node disk may still be in the send queue. However, the data on the failover node is consistent, but not up-to-date. This is usually used for geographically separated nodes.

...

Single Primary: The primary designation is given to one cluster member. Since only one cluster member manipulates the data, this mode is useful with conventional filesystems such as ext3 or XFS.

Veja também o link para obter mais detalhes.