Sistema de arquivos distribuídos geograficamente com localidade preferida

Estou criando um aplicativo que precisa distribuir um servidor de arquivos padrão em alguns sites por uma WAN. Basicamente, cada site precisa gravar muitos arquivos variados de tamanho variado (alguns na faixa dos 100s MB, mas os mais pequenos), e o aplicativo é gravado de modo que as colisões não sejam um problema. Eu gostaria de ter um sistema configurado que atenda às seguintes qualificações:

1. Cada site pode armazenar arquivos em um "espaço para nome" compartilhado. Ou seja, todos os arquivos apareceriam no mesmo sistema de arquivos.
2. Cada site não enviaria dados pela WAN, a menos que necessário. Ou seja, haveria armazenamento local em cada lado da WAN que seria "mesclado" no mesmo sistema de arquivos lógico.
3. Linux & Free ($$$) é um Plus

Basicamente, algo como um compartilhamento central do NFS atenderia à 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.

Eu examinei o Luster e executei alguns testes bem-sucedidos, no entanto, ele parece distribuir arquivos de maneira bastante uniforme no armazenamento distribuído. Examinei a documentação e não encontrei nada que "preferisse" o armazenamento local automaticamente ao armazenamento remoto. Mesmo algo que acompanha o armazenamento de menor latência seria bom. Funcionaria na maioria das vezes, atendendo aos requisitos desse aplicativo.

Algumas respostas para algumas perguntas abaixo:

• Nós do servidor: 2 ou 3 para iniciar. Cada servidor teria dezenas de clientes simultâneos de leitura / gravação se conectando.
• A topologia da WAN é de malha completa e confiável. (grande empresa, o custo não é tão limitador quanto a burocracia)
• Failover de cliente: na verdade, eu não tinha pensado em fazer o failover de clientes (principalmente porque nosso aplicativo atual não faz isso em apenas um site). Suponho que a resposta prática seja que se espera que os servidores em cada site distribuído geograficamente sejam pontos únicos de falhas para os clientes que estão atendendo. No entanto, se você estiver pensando em algo específico aqui, acho que seria bastante pertinente para a discussão.
• Roll-my-own: pensei em rsync / unison, no entanto, precisaria de um pouco de lógica sofisticada para tornar a parte "dinâmica" deste trabalho perfeitamente. Ou seja, o arquivo parece ser local, mas é recuperado somente sob demanda.
• MS-DFS: Certamente parece ser algo que eu deveria procurar. Meu principal problema seria não ter certeza sobre a configuração / confiabilidade / desempenho do servidor NFS no Windows, pois muitos dos clientes conectados são clientes NFS.

Vergonha sobre o requisito do Linux. É exatamente isso que o Windows DFS faz. Desde 2003 R2, ele também faz isso em nível de bloco.

Algumas perguntas:

• Em quantos nós de "servidor" você está pensando em participar dessa coisa?

• Como é a topologia de conectividade WAN - hub e spoke, malha completa? Quão confiável é?

• 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 não precisa de um gerenciador de bloqueios distribuídos; portanto, você pode fazer isso com ferramentas da terra do usuário como rsync ou Unison e apenas exportar o corpus resultante de arquivos com NFS para os clientes locais. É feio, e você teria que lidar com a combinação de algum tipo de sistema para gerar uma topologia de replicação e realmente executar as ferramentas da terra do usuário, mas certamente seria barato conforme o custo do licenciamento.

Você já considerou o AFS ?

O Andrew File System (AFS) é um sistema de arquivos em rede distribuído que usa um conjunto de servidores confiáveis ​​para apresentar um espaço de nome de arquivo homogêneo e transparente ao local para todas as estações de trabalho clientes.

Pelo que entendi, a maior parte do desenvolvimento recente está por trás do projeto OpenAFS .

Não posso fingir que estou familiarizado o suficiente com o projeto para saber se o recurso "localidade preferida" está disponível, mas, caso contrário, parece um bom ajuste.

Você já viu os pools OST em Luster?

Não será automático, mas com os pools OST, você pode atribuir diretórios / arquivos a OST / OSSes específicos - basicamente a alocação de armazenamento baseada em políticas, em vez do rodízio / distribuição padrão nos OSTs.

Portanto, você pode configurar um diretório por site e atribuir esse diretório aos OSTs locais desse site, que direcionarão todas as E / S aos OSTs locais. Ainda será um espaço para nome global.

Há muito trabalho para melhorar as conexões Luster over WAN (servidores de cache local e coisas assim), mas tudo ainda está sob forte desenvolvimento do AFAIK.

Talvez NFS mas com CacheFS sobre os servidores de aplicativos irá realizar a sua parte do seu objetivo. Pelo que entendi, tudo o que foi escrito ainda vai para o servidor central, mas pelo menos as leituras podem acabar sendo armazenadas 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 examinar o UnionFS mabye. Com isso, acho que cada local seria uma exportação NFS e, em seguida, você poderia usar o UnionFS em cada local para que essa e todas as outras montagens NFS do local apareçam como um sistema de arquivos. Eu não tenho experiência com isso, no entanto.

Você pode procurar no DRBD para replicar os discos. http://www.drbd.org/ . Esta é uma solução Linux de alta disponibilidade que acabou de entrar no Kernel.

No entanto, isso tem algumas limitações:

1. Apenas dois nós podem ser configurados
2. A WAN pode ser muito confiável para manter o DRBD robusto.

Se você quiser simplificar, consulte o rsync, resolva muitos problemas e pode ser script.

Verifique chironfs .

Talvez ele possa fazer o que quiser, com base no sistema de arquivos.

Btsync é outra solução com a qual tive uma boa experiência. Ele usa o protocolo BitTorrent para transferir os arquivos; portanto, quanto mais servidores você tiver, mais rápido será o sincronismo de 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 e enviado a 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)