sistema de arquivos espelhado em alguns servidores


13

Estou procurando uma solução para espelhar ou replicar um diretório (ou um sistema de arquivos) em alguns servidores Linux. A solução ideal seria uma que permita a todos os servidores acesso de leitura e gravação. Eu também quero que ele seja resistente, se um dos servidores cair, o resto ainda funcionará sem perder nenhum dado.

Eu estive procurando algumas soluções:

  • DRBD : replicações em nível de bloco, parece um pouco exagerado;
  • lsyncd : parece muito simples, mas tenho dúvidas sobre desempenho;
  • GlusterFS : parece que seria uma boa combinação, ainda não descobrimos exatamente como o modo de replicação funciona. Será que ele tem características que eu preciso?

Quaisquer outras sugestões são bem-vindas.


Você está procurando uma configuração de nada compartilhado ou conectará todos os servidores à mesma SAN de back-end?
HampusLi 6/05

logicamente ele não compartilhou nada (fisicamente é EC2 com EBS).
Vartec 6/06

Respostas:


6

A primeira pergunta que gostaria de fazer é que você deseja que isso seja replicado para dois servidores ou mais do que dois servidores? Para dois servidores eu iria com DRDB, para três ou mais eu iria com gluster.

Se a latência de E / S não for uma preocupação crítica, eu iria com gluster. É muito fácil de configurar e pode claramente fazer o que você precisa. Tudo o que você precisa fazer é criar um servidor gluster exibindo os arquivos nas três caixas e também fazer com que cada caixa atue como um cliente gluster que monta os arquivos.

O DRDB será complicado para trabalhar no modo mestre <-> mestre com 3 ou mais servidores. Você precisa definir uma configuração baseada em anel e eu não a recomendaria. No entanto, para dois servidores, o DRDB é fantástico. Mestre <-> O modo mestre não é complicado de configurar e você não precisa aprender nada do sistema de arquivos.

O lsycd é ótimo para uma configuração mestre / escravo, mas você não parece querer isso.

O Ceph ainda é bastante novo, da última vez que verifiquei, ele ainda não tinha suporte ao fsck. Prefiro basear minha infraestrutura em algo mais estável.

O Luster é um produto fantástico para implantações em larga escala, mas você precisa configurar a pulsação e o failover para o servidor mds ou ele terá um único ponto de falha. Dado o número limitado de servidores de que ele está falando, suspeito que seja um exagero nesse caso.


Inicialmente, começarei com apenas 2 servidores por cluster, mas quero ter a opção de ter mais de 2 servidores para expansão; A configuração de gluster que você está descrevendo, lidaria com um dos servidores travando? seria fácil adicionar servidor extra?
Vartec 6/06

2

Que tal Ceph ou Lustre ?


O Luster suporta o Ubuntu Server? Estou verificando Ceph agora, obrigado pela sugestão.
Vartec 6/06

No wiki do ceph: "O Ceph está em desenvolvimento pesado e ainda não é adequado para outros usos que não sejam comparações e análises
Jeff Busby

2

Você deve examinar o OpenAFS - é um sistema de arquivos distribuído principalmente que permite a existência de várias cópias de dados distribuídas pelo cluster e todos podem ler / gravar no FS ao mesmo tempo.

Também possui vários outros recursos úteis (boa autenticação, criptografia on the wire, armazenamento em cache local interno em clientes, cliente nativo do Windows, portátil em várias versões do unix, etc.)

É um pouco pesado para configurar, no entanto.


mesma pergunta do NFS: "permite várias cópias". OK, mas ele realmente se encarrega de sincronizar essas cópias?
vartec

Sim. E é possível, embora irritante, recuperar-se da perda do mestre principal. Mas é trivial ter vários gravadores e os blocos resultantes armazenados em vários hosts.
Chris

A chave para entender o OpenAFS é que é um sistema de gerenciamento de cache - existe um espaço para nome (existe apenas um "arquivo" no IE), mas existem cópias em cache do arquivo em todos os lugares e um protocolo para garantir que todas as cópias em cache sejam consistentes . Se você perder o mestre, poderá transformar uma das cópias em cache no mestre, mas não é ideal estar nessa situação.
Chris

1

O NFS também pode funcionar bem, dependendo de suas necessidades.


AFAIK, NFS não fornece maneira de montar servidores replicados, mas não a replicação em si. Mas eu não uso o NFS há muito tempo, então talvez isso tenha mudado. Você poderia criar um link para os documentos do NFS que descrevem essa configuração?
Vartec 6/05

Uma maneira absurda seria replicar os diretórios para vários servidores nfs, um dos quais com um vip primário, e migrar o vip entre os servidores, se um deles cair. Ou round robin dns talvez. O próprio NFS pode não fazer tudo o que você precisa, mas em conjunto com os serviços de pulsação ou cluster do red hat, pode ser o que você precisa. Não sei se a pergunta original tinha todos os requisitos. Você pode até fazer o rsync em vários servidores, digamos a cada hora, para uma solução realmente rápida e fácil.
Lsd

Pule a parte sobre o rsync. Seria a replicação, mas é principalmente para configurações somente leitura, que não atendem aos seus requisitos. Eu pretendia editar meu comentário acima, mas não me deixou.
Lsd

1

Fazer com que isso funcione com o DRBD será realmente difícil - o problema não é que o n8whnp pareça pensar em um problema relacionado à replicação de várias maneiras (você apenas faz todas as faixas de nós em um conjunto de espelhos), mas tem controle de concorrência - você ' d precisa executar um sistema de arquivos em cluster em cima do espelhamento em cima do DRBD.

O lsyncd é ainda pior, pois não há solução prática para o controle de simultaneidade.

Eu recomendaria uma solução do tipo AFS (AFS, OpenAFS) como uma solução madura, estável e aberta. Eu ficaria sem brilho desde que a Oracle o desligou. Não familiarizado com o glusterfs, mas como ele se baseia no armazenamento distribuído e não no replicado, recomendo que você analise muito bem como ele se comportará na operação de cérebro dividido (o AFS OTOH foi projetado para funcionar no modo desconectado).

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.