Estou inclinado a sugerir replicação que é independente de dados, como drbd. O grande número de arquivos fará com que qualquer coisa que esteja sendo executada em um nível mais alto do que "armazenamento em bloco" gaste uma quantidade excessiva de tempo percorrendo a árvore - como você encontrou usando rsync ou criando relógios inotify.
A versão curta da minha história pessoal respalda: Eu não usei o Ceph, mas tenho certeza de que isso não está no alvo principal do mercado com base na semelhança com o Gluster. Tenho, no entanto, tentado implementar esse tipo de solução com a Gluster nos últimos anos. Tem sido instalado e funcionando a maior parte do tempo, embora várias atualizações de versão principais, mas eu não tive fim de problemas. Se seu objetivo é mais redundância do que desempenho, o Gluster pode não ser uma boa solução. Particularmente, se o seu padrão de uso tiver muitas chamadas stat (), o Gluster não se sai muito bem com a replicação. Isso ocorre porque as chamadas stat para volumes replicados vão para todos os nós replicados (na verdade, "bricks", mas você provavelmente só terá um bloco por host). Se você tiver uma réplica bidirecional, por exemplo, cada stat () de um cliente aguardará uma resposta de ambos os blocos para garantir que esteja usando os dados atuais. Então você também tem a sobrecarga do FUSE e falta de cache se estiver usando o sistema de arquivos nativo gluster para redundância (ao invés de usar o Gluster como backend com NFS como o protocolo e montador automático para redundância, o que ainda é uma droga) . O Gluster funciona muito bem com arquivos grandes, nos quais você pode espalhar dados em vários servidores; a distribuição e distribuição de dados funciona bem, já que é para isso que serve. E a nova replicação do tipo RAID10 tem um desempenho melhor do que os volumes replicados retos mais antigos. Mas, com base no que estou supondo, é o seu modelo de uso, eu aconselho contra isso.
Tenha em mente que você provavelmente terá que encontrar uma maneira de ter eleições mestras entre as máquinas ou implementar o bloqueio distribuído. As soluções de dispositivos de blocos compartilhados requerem um sistema de arquivos que seja multi-master aware (como o GFS), ou requer que apenas um nó monte o sistema de arquivos de leitura-gravação. Os sistemas de arquivos em geral não gostam quando os dados são alterados no nível de dispositivo de bloco abaixo deles. Isso significa que seus clientes precisarão saber qual é o mestre e direcionar solicitações de gravação para lá. Isso pode se tornar um grande incômodo. Se o GFS e toda a sua infra-estrutura de suporte for uma opção, o drbd no modo multi-master (eles chamam de "dual primary") pode funcionar bem. link para mais informações sobre isso.
Independente da direção que você seguir, você pode achar que isso ainda é um grande problema para se fazer em tempo real sem apenas dar uma carga de dinheiro a uma empresa SAN.