Eu tenho um servidor que exporta um diretório contendo cerca de 7 milhões de arquivos (principalmente imagens) de seu disco local para clientes de rede viaNFS.
Preciso adicionar um segundo por causa do HA e mantê-lo sincronizado com o primeiro, com o mínimo de delta possível entre os dois.
Pesquisa sugere usarlsyncdou outronotificarsoluções baseadas em para isso, mas dado o número de arquivos que criam onotificarrelógios leva uma eternidade. A mesma coisa parasincronizar novamente.
Outras soluções possíveis parecem serdrdbou agrupamentosistemas de arquivoscomocephoubrilho, mas não tenho experiência com eles e não sei qual seria mais apropriado e lidaria bem com tantos arquivos e ainda forneceria um desempenho decente.
Observe que a atividade é principalmente lida, com pouca ocorrência de gravação.
Responder1
Estou inclinado a sugerir replicação independente de dados, como drbd. O grande número de arquivos fará com que qualquer coisa executada em um nível superior ao "armazenamento em bloco" gaste uma quantidade excessiva de tempo caminhando na árvore - como você descobriu usando o rsync ou criando relógios inotify.
A versão resumida da minha história pessoal confirma isso: não usei o Ceph, mas tenho quase certeza de que esse não é o principal alvo de mercado com base em sua semelhança com o Gluster. No entanto, tenho tentado implementar esse tipo de solução com o Gluster nos últimos anos. Ele está instalado e funcionando a maior parte do tempo, apesar de várias atualizações importantes de versão, mas não tive problemas sem fim. Se o seu objetivo é mais redundância do que desempenho, o Gluster pode não ser uma boa solução. Principalmente 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 estatísticas para volumes replicados vão para todos os nós replicados (na verdade, "tijolos", mas provavelmente você terá apenas um tijolo por host). Se você tiver uma réplica bidirecional, por exemplo, cada stat() de um cliente aguarda uma resposta de ambos os blocos para ter certeza de que está usando os dados atuais. Então você também tem a sobrecarga do FUSE e a falta de cache se estiver usando o sistema de arquivos gluster nativo para redundância (em vez de usar o Gluster como back-end com NFS como protocolo e montador automático para redundância, o que ainda é uma droga pelo motivo stat()) . O Gluster se sai muito bem com arquivos grandes, onde você pode espalhar dados por vários servidores; a distribuição e distribuição de dados funcionam bem, pois é para isso que serve. E a replicação do tipo RAID10 mais recente tem melhor desempenho do que os volumes replicados diretamente mais antigos. Mas, com base no que suponho ser o seu modelo de uso, desaconselho isso.
Tenha em mente que você provavelmente terá que encontrar uma maneira de fazer eleições de mestre entre as máquinas ou implementar bloqueio distribuído. As soluções de dispositivos de bloco compartilhados requerem um sistema de arquivos que seja compatível com vários mestres (como GFS) ou requer que apenas um nó monte o sistema de arquivos de leitura e gravação. Os sistemas de arquivos em geral não gostam quando os dados são alterados no nível do 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 acabar sendo um grande incômodo. Se o GFS e toda a sua infraestrutura de suporte forem uma opção, o drbd no modo multi-master (eles o chamam de "primário duplo") poderia funcionar bem. https://www.drbd.org/en/doc/users-guide-83/s-dual-primary-modepara obter mais informações sobre isso.
Independentemente da direção que você seguir, você provavelmente descobrirá que ainda é uma grande dor de cabeça fazer isso em tempo real, sem apenas dar a uma empresa SAN um caminhão de dinheiro.
Responder2
Mudei de rsync para ceph com a ajuda da configuração do Proxmox VE.
Agora estou gerenciando 14 TB em um cluster com replicação ao vivo. Por quase 4 anos.