Recomendações para substituir um cluster GFS?

Question

Eu tenho alguns clusters CentOS GFS (GFS como no Global File System) usando um disco compartilhado em uma SAN Fibre Channel. Eles estão maduros agora e chegou a hora de começar a planejar sua substituição.

Eles são um número ímpar de nós (3 ou 5) com cercas de nós defeituosos configurados com chaves de energia APC (PDU). Os nós estão todos ativos e lêem e escrevem simultaneamente no mesmo sistema de arquivos compartilhado. O sistema de arquivos é pequeno, atualmente menor que um TB, e nunca crescerá mais do que caberia em um disco rígido comum.

Eu tenho dois recursos exclusivos de endereço IP que são realocados quando um nó está inativo. (1 no cluster de 3 nós). Tudo funciona muito bem, mas o desempenho não é muito bom quando há muita atividade.

Então, o que eu poderia fazer de forma diferente no meu cluster de próxima geração?

O que eu preciso é de tempo de atividade e disponibilidade de dados. Possivelmente escalabilidade também, mas provavelmente não. Eu não espero que a carga cresça muito. Eu também preciso ser capaz de ler e escrever os arquivos como arquivos regulares em um sistema de arquivos regular. Não há necessidade de cotas ou ACLs. Apenas permissões regulares de unix, propriedade, mtime, tamanho em bytes e a capacidade de usar ln para criar um arquivo de bloqueio de uma maneira que falhe em todos, menos em 1 nó, caso eles tentem ao mesmo tempo.

Eu não quero aumentar o número de servidores físicos (o que significa que eu quero usar o armazenamento nos próprios servidores).

Não é obrigatório, mas acho que seria bom se não dependesse do disco compartilhado. Já passei por dois incidentes com armazenamento SAN de classe empresarial indisponíveis nos últimos cinco anos, por isso, por mais improvável que seja, gostaria de estar um passo à frente.

Como o tempo de atividade é muito importante, 1 servidor físico com 1 kernel em execução é muito pequeno. As máquinas virtuais dependem da SAN em nosso ambiente.

Meus pensamentos até agora:

• Todos os nós podem ser clientes NFSv3 simples (O ln funcionaria como esperado? Qual seria o servidor NFS então?)
• Ceph com o CephFS (Quando o FS estará pronto para produção?)
• XtreemFS (Por que há tão pouco escrito sobre isso em comparação com Ceph?)

Como você pode ver, estou interessado em armazenamento distribuído, mas preciso de conselhos de gurus experientes. Especialmente recomendações ou conselhos sobre Ceph ou XtreemFS seriam bem-vindos. Este não é um HPC com demandas insanas de largura de banda. Só preciso da disponibilidade e confiabilidade, e espero que a flexibilidade da minha solução antiga, idealmente em uma configuração "melhor" do que a atual.

EDITAR (ver comentário de Nils) A principal razão que penso sobre a substituição desta solução é que eu quero ver se é possível eliminar o único ponto de falha que o gabinete de armazenamento SAN é. Ou devo usar o espelhamento do LVM para manter os dados em dois sistemas de armazenamento diferentes na mesma malha SAN? Dois FC-HBAs e interruptores duplos devem ser suficientes, eu acho.

Ah, quase me esqueci ... Deveria ser tão barato quanto Open Source ...: -)

    

Answer 1

O Ceph e o GlusterFS são o local onde a tecnologia FS em cluster está atualmente em andamento. Como não estou familiarizado com o GlusterFS, falarei sobre os recursos do Ceph.

Ceph escala horizontalmente; quanto mais nós de baixo custo você adicionar, melhor será o desempenho. Ao contrário do GlusterFS, este é um benefício principal para o Ceph, uma vez que fragmenta os dados.

No entanto, o Ceph está em desenvolvimento ativo (ele está pronto para produção, exceto para o Ceph FS) e requer um kernel moderno (enquanto escrevo este, nem mesmo o kernel padrão do CentOS 6.5 pode aproveitar os recursos do RBD / CephFS). Para contornar isso, instalei o ELRepo kernel-lt .

Para dividir isso para você:

• O Cephs RBD é um substituto de SAN em cluster; você pode criar dispositivos "virtuais" que estão no cluster e podem ser montados em servidores. Nota: Apenas um servidor deve ter uma imagem RBD montada ao mesmo tempo (você não quer que vários sistemas operacionais montem uma unidade SATA)? Você formatará o disco RBD, mount como normal e, em seguida, disponibilizará o NFS / CIFS. Se o servidor que fornece o NFS / CIFS ficar inativo, nenhum dado será perdido.
• O Ceph FS é um repositório de NAS em cluster (embora não esteja pronto para produção); Ele fornece recursos de bloqueio de arquivos que são necessários para um FS em cluster compartilhado entre servidores (como, por exemplo, um servidor da Web).

O RBD é executado no espaço do kernel; por isso não há nenhum impacto no desempenho do fusível. O Ceph FS também é executado no espaço do kernel, mas pode ser executado com o FUSE.

O Ceph também é muito fácil de implantar:

1. pip install ceph-deploy em um nó admin (sua área de trabalho / estação de trabalho).
2. Adicione os repos do RPM Inktank e ceph-deploy install node1 node2 ... nodeN para instalar o ceph em todos os nós.

Answer 2

Encontrou este post como uma excelente análise de requisitos para casos avançados de uso de sistemas de arquivos distribuídos.

Procurando pelo sistema de arquivos distribuído final: link

Exemplo

• Confidentiality: Tahoe wins, hands down. Neither network sniffers nor storage nodes can see the contents of the stored files. They can't even find out about their name or the directory structure. XtreemFS encrypts the data on the network (but it is still stored in cleartext on the nodes). Ceph doesn't even try.

Pontos-chave dos requisitos

1. Disponibilidade e amp; redundância
2. Replicação e reequilíbrio automáticos
3. Confidencialidade: no mínimo, as comunicações de rede devem ser criptografadas e autenticadas
4. Desempenho: o desempenho do disco nativo pode não ser realisticamente acessível
5. Integração com o sistema: Eu quero um sistema de arquivos, não um sistema de armazenamento

Entre outras coisas, isso mostra as principais coisas que não são possíveis com o CephFS e o GlusterFS, no momento, apesar do apoio do setor.