Que vergonha sobre o requisito do Linux. Isso é exatamente o que o Windows DFS faz. Desde 2003 R2, ele também é feito em nível de bloco.
Estou criando um aplicativo que precisa distribuir um servidor de arquivos padrão em alguns sites em uma WAN. Basicamente, cada site precisa escrever muitos arquivos miscelânea de tamanhos variados (alguns na faixa dos 100s MB, mas os mais pequenos), e o aplicativo é escrito de tal forma que as colisões não são um problema. Gostaria de ter um sistema configurado que atenda às seguintes qualificações:
Basicamente, algo como um compartilhamento NFS central atenderia a maioria dos requisitos, no entanto, não permitiria que os dados gravados localmente permanecessem locais. Todos os dados dos lados remotos da WAN seriam copiados localmente o tempo todo.
Examinei o Lustre e executei alguns testes bem-sucedidos com ele, no entanto, parece distribuir arquivos de maneira bastante uniforme em todo o armazenamento distribuído. Eu examinei a documentação e não encontrei nada que automaticamente "preferisse" o armazenamento local ao armazenamento remoto. Mesmo algo que foi com o menor armazenamento de latência seria bom. Funcionaria na maior parte do tempo, o que atenderia aos requisitos desta aplicação.
Algumas respostas para algumas perguntas abaixo:
Que vergonha sobre o requisito do Linux. Isso é exatamente o que o Windows DFS faz. Desde 2003 R2, ele também é feito em nível de bloco.
Algumas perguntas:
Quantos nós "servidor" você está pensando em participar dessa coisa?
Qual é a topologia de conectividade da WAN como - hub e spoke, malha completa? Quão confiável é isso?
Você espera que os clientes façam failover em um servidor geograficamente não local, caso o servidor local falhe?
O Windows DFS-R certamente seria o que você está procurando, apesar de alguns custos de licenciamento potencialmente pesados.
Você diz que as colisões não são um problema e você não precisa de um gerenciador de bloqueio distribuído, então você poderia fazer isso com ferramentas de usuário como rsync ou Unison e apenas exportar o corpus de arquivos resultante com o NFS para os clientes locais. É feio, e você teria que lidar com algum tipo de sistema para lidar com a geração de uma topologia de replicação e realmente rodar as ferramentas do usuário, mas certamente seria barato com o custo de licenciamento.
Você já considerou o AFS ?
The Andrew File System (AFS) is a distributed networked file system which uses a set of trusted servers to present a homogeneous, location-transparent file name space to all the client workstations.
Pelo que entendi, a maior parte do desenvolvimento recente está por trás do projeto OpenAFS .
Não posso fingir estar familiarizado o suficiente com o projeto para saber se o recurso de "localidade preferencial" está disponível, mas, caso contrário, parece um bom ajuste.
Você analisou os pools de OST no Lustre?
Não será automático, mas com os pools OST você pode atribuir diretórios / arquivos a OST / OSSes específicos - basicamente alocação de armazenamento baseada em políticas, em vez do padrão round-robin / striping em OSTs.
Assim, você pode configurar um diretório por site e atribuir esse diretório aos OSTs locais para esse site, que direcionará todo o I / O para os OSTs locais. Ainda será um espaço de nomes global.
Há muito trabalho para melhorar as conexões do Lustre sobre a WAN (servidores de cache local e coisas do tipo), mas tudo ainda está sob strong desenvolvimento da AFAIK.
Talvez o NFS, mas com Cachefs nos servidores de aplicativos, cumpra sua parte de sua meta. Pelo que entendi tudo escrito ainda vai para o servidor central, mas pelo menos lê pode acabar sendo armazenado em cache localmente. Isso pode levar muito tempo a atrasar as leituras dependendo dos seus padrões de uso.
Além disso, vale a pena investigar o mabye UnionFS. Com isso, acho que cada local seria uma exportação do NFS e, em seguida, você poderia usar o UnionFS em cada local para ter isso e todas as outras montagens do NFS do local apareceriam como um sistema de arquivos. Eu não tenho experiência com isso.
Você pode procurar no DRBD para replicar os discos. link . Esta é uma solução de alta disponibilidade do Linux que acaba de chegar ao Kernel.
No entanto, isso tem algumas limitações:
Se você quiser mantê-lo simples, dê uma olhada no rsync, resolva muitos problemas e possa ser roteirizado.
Verifique em chironfs .
Talvez você possa fazer o que quiser, com base no sistema de arquivos.
O Btsync é outra solução com a qual tive uma boa experiência. Ele usa o protocolo BitTorrent para transferir os arquivos, então quanto mais servidores você tiver, mais rápido será sincronizando novos arquivos.
Diferentemente da solução baseada em rsync, ela detecta quando você renomeia os arquivos / pastas e os renomeia em todos os nós, em vez de excluir / copiar.
Os clientes btsync do Yout podem compartilhar as pastas em uma rede local.
A única desvantagem que encontrei (em comparação com o MS DFS) é que ele não detectará uma cópia de arquivo local. Em vez disso, ele será interpretado como um novo arquivo enviado para todos os pares.
Até agora, o btsync parece ser a melhor solução de sincronização e pode ser instalado em dispositivos Windows, Linux, Android e ARM (por exemplo, NAS)