Sistema de arquivos geograficamente distribuído com local preferido

9

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:

  1. Cada site pode armazenar arquivos em um "namespace" compartilhado. Ou seja, todos os arquivos apareceriam no mesmo sistema de arquivos.
  2. Cada site não envia dados pela WAN, a menos que seja necessário. Ou seja, haveria armazenamento local em cada lado da WAN que seria "mesclado" no mesmo sistema de arquivos lógico.
  3. Linux e amp; Grátis ($$$) é um Plus

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:

  • Nós do servidor: 2 ou 3 para iniciar. Cada servidor teria dezenas de clientes simultâneos de leitura / gravação conectados.
  • A topologia da WAN é completa e confiável. (grande corporação, o custo não é tão limitado quanto a burocracia)
  • Failover de cliente: na verdade, eu não tinha pensado em ter o failover de clientes (principalmente porque nossa aplicação atual não faz isso em apenas um site). Suponho que a resposta prática seja que os servidores em cada site geograficamente distribuído devem ser pontos únicos de falhas para os clientes que estão atendendo. Porém, se você está pensando em algo específico aqui, acho que seria bastante pertinente para a discussão.
  • Roll-my-own: Eu tenho pensado sobre rsync / unison, no entanto, eu precisaria de um pouco de lógica extravagante para fazer a parte "dinâmica" deste trabalho sem problemas. Ou seja, o arquivo parece ser local, mas é recuperado somente sob demanda.
  • MS-DFS: Certamente parece ser algo que eu deveria investigar. Meu principal problema seria potencialmente não ter certeza sobre configuração / confiabilidade / desempenho do servidor NFS no Windows, já que muitos dos clientes que se conectam são clientes NFS.
por dpb 25.03.2010 / 01:36

9 respostas

5

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.

    
por 25.03.2010 / 01:43
3

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.

    
por 25.03.2010 / 02:12
3

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.

    
por 25.03.2010 / 06:57
1

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.

    
por 25.03.2010 / 14:20
1

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.

    
por 25.03.2010 / 14:21
0

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:

  1. Apenas dois nós podem ser configurados
  2. A WAN pode não ser confiável para manter o DRBD robusto.
por 25.03.2010 / 02:42
0

Se você quiser mantê-lo simples, dê uma olhada no rsync, resolva muitos problemas e possa ser roteirizado.

    
por 25.03.2010 / 02:52
0

Verifique em chironfs .

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

    
por 25.03.2010 / 12:34
0

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)

    
por 01.08.2013 / 01:25