Buscando armazenamento em bloco distribuído, tolerante a falhas e em rede [fechado]

Question

Estou procurando um sistema de armazenamento de rede distribuído tolerante a falhas que exponha dispositivos de bloco (não sistemas de arquivos) nos clientes.

• O dispositivo de bloco de um cliente deve gravar simultaneamente em vários nós de armazenamento
• O dispositivo de bloco de um cliente não deve falhar, desde que nem todos os nós de armazenamento que o fizeram cair
• O mestre deve redistribuir automaticamente os dados dos armazenamentos quando um nó de armazenamento falhar ou for adicionado / removido
• Um único mestre (que é apenas para metadados) está bem

Então, idealmente, a arquitetura seria muito semelhante a moosefs ( link ), mas em vez de expor um sistema de arquivos real montado usando um cliente de fusível, expor dispositivos de bloco nos clientes.

Eu sei de iscsi e drbd mas ambos não parecem oferecer o que eu estou procurando. Ou estou faltando alguma coisa?

    

Answer 1

Com base nos requisitos acima, Ceph pode ser o que você procura. link

O Ceph fornece um sistema de arquivos distribuído, compatível com POSIX, que você pode montar como um dispositivo de bloco usando o dispositivo de bloco Rados . Isso é implementado diretamente nos kernels modernos do Linux (2.6.37+).

Existe até mesmo um driver de armazenamento Qemu / KVM que significa que você pode montar sistemas de arquivos Ceph como um disco de máquina virtual.

Importante empresa de hospedagem na Web Dreamhost ( link ) confia no Ceph.

    

Answer 2

A primeira coisa que eu diria é que você pode precisar redefinir suas expectativas de complexidade. O assunto da sua pergunta inclui:

• distribuído
• tolerante a falhas
• dispositivo de bloco de rede

Cada um deles sozinho é geralmente um tópico de complexidade pelo menos moderada. Combinando todos os três, e você não vai conseguir sem um pouco de trabalho.

Acho que o que você está perdendo é algo que pode realizar todos os seus requisitos e ainda assim ser simples ou fácil. Algumas de suas necessidades são muito difíceis de implementar juntas, se não totalmente contraditórias. Individualmente pode ser realizado sem muita dificuldade, mas colocá-los todos juntos é onde fica complicado.

Vou analisar cada um dos requisitos e fornecer comentários:

A client's block device should write simultaneously to several storage nodes

Isso pode ser feito usando armazenamento redundante sob o capô. A redundância pode ser realizada no nível do "nó de armazenamento", usando armazenamento local redundante (RAID e outros) ou no nível da rede, duplicando os dados para vários nós.

A client's block device should not fail as long as not all storage nodes backing it went down

Junto com o anterior, isso é facilmente realizado com redundância no armazenamento. Esta parte exigiria que o armazenamento fosse implementado em uma configuração do tipo "rede RAID1".

The master should automatically redistribute storages' data when a storage node fails or gets added/ removed

Aqui é onde as coisas ficam difíceis. Você declarou especificamente que deseja um dispositivo de bloco exportado. Isso torna esse recurso muito mais difícil na parte de trás e, a menos que você esteja replicando o dispositivo de bloco inteiro. Com um dispositivo de bloco, a funcionalidade do lado do servidor não pode olhar para um arquivo e duplicar os blocos que compõem esse arquivo, como poderia quando apresenta uma interface de sistema de arquivos. Isso deixa o lado do servidor tratando o dispositivo de bloco inteiro como um todo e precisando replicar cada bloco em sua totalidade para um único local separado, ou ele precisa implementar muita inteligência peculiar para obter boa confiabilidade, consistência e desempenho. . Muito poucos sistemas implementam algo assim agora.

A single master (which is for metadata only) is fine

Como conceito, isso funciona muito melhor quando você está lidando com fragmentos de arquivos de um sistema de arquivos do que com dispositivos de bloco. A maioria dos sistemas que implementam algo assim faz isso com a interface do sistema de arquivos ou com uma interface pseudo-sistema de arquivos.

Geralmente, você está tomando uma decisão. Você obtém seu armazenamento remoto como um sistema de arquivos, e nesse caso você está acessando uma interface de alto nível e permitindo que o lado de armazenamento tome decisões e manipule os detalhes de baixo nível para você, ou você está obtendo o armazenamento como um bloquear dispositivo, caso em que você está assumindo a responsabilidade por esses recursos , ou pelo menos a maioria deles. Você está obtendo seu armazenamento em um nível inferior e isso deixa mais trabalho para você implementar esses recursos de baixo nível (distribuídos, tolerantes a falhas, etc.).

Além disso, você precisa lembrar que, como regra geral, a tolerância a falhas e o alto desempenho são extremidades opostas do mesmo espectro com um determinado conjunto de hardware. Conforme você aumenta a redundância, diminui o desempenho. O exemplo mais simples é se você tiver 4 discos. Você pode distribuir todos os 4 deles em um RAID0 para obter o máximo desempenho ou duplicar os mesmos dados 4 vezes em todos os discos. O primeiro lhe dará o máximo desempenho, a última redundância máxima. Entre há vários trade-offs, como um RAID5 de 4 discos, ou minha preferência pessoal, um RAID10 de 4 discos.

Se eu estivesse montando algo que atenda aos seus requisitos, provavelmente exportaria todos os discos com iSCSI ou ATA Over Ethernet (AoE) e usaria o RAID de software MD ou o espelhamento de LVM (ou uma combinação dos dois) para obter o nível de redundância que eu precisava.

Sim, há algum trabalho manual para configurá-lo e mantê-lo, mas ele oferece um controle preciso sobre as coisas para alcançar o nível de tolerância a falhas e o desempenho necessário. O DRBD é outra opção que poderia se encaixar nele, mas se você for lidar com mais de alguns "nós de armazenamento", eu provavelmente passaria adiante.

Atualização: O acima pressupõe que você está querendo criar sua própria solução. Se você tiver um orçamento grande o suficiente, poderá comprar uma solução SAN / NAS que, embora provavelmente não seja exatamente como descrito acima, pode ser tratada como uma caixa preta com o mesmo funcionalidade aproximada.

    

Answer 3

Você está descrevendo uma SAN. Se você quiser construir você mesmo, você provavelmente pode, mas não posso ajudá-lo mais do que apontar na direção do ZFS. Se você acabar comprando um de um fornecedor de armazenamento, você vai querer mudar a maneira de descrevê-lo. Aqui está um resumo do que você está pedindo:

• " Um dispositivo de bloco do cliente deve gravar simultaneamente em vários nós de armazenamento ": isso equivale a vários controladores em um ambiente multipath ativo / ativo. Cada gravação será enviada apenas para um único nó, no entanto, várias gravações tenderão a ter vários caminhos se você configurar o driver multipath local corretamente.
• " O dispositivo de bloco de um cliente não deve falhar, contanto que nem todos os nós de armazenamento que o fizeram cair ": Isso equivale a não ter um único ponto de falha. Cada nó deve ser capaz de manipular o tráfego de toda a infraestrutura, e deve haver duas redes distintas para enviar IO à caixa que não compartilha pontos de falha. Se você for com um dispositivo de armazenamento fibre channel, isso significará ter dois switches e não vinculá-los entre si.
• " O mestre deve redistribuir automaticamente os dados dos armazenamentos quando um nó de armazenamento falha ou é adicionado / removido ": Isso equivale a duas coisas. Primeiro, recupere a falha de unidade. Se uma unidade falhar, o armazenamento deverá recriar os dados de paridade ou cópias (dependendo se o armazenamento usar RAID ou algo parecido) e substituir o conteúdo do disco perdido em discos de boa qualidade. Em segundo lugar, também se refere à falha do controlador. Se um controlador falhar, os hosts devem poder continuar como se nada tivesse acontecido, e todo o IO em vôo deve ser tratado sem falhas. Isso é realizado por meio do espelhamento de cache ou da garantia de que uma gravação não seja confirmada até que seja salva com segurança em mais de um cache.

Eu adicionaria à sua lista se soubesse mais sobre seu ambiente, mas isso permitiria que você começasse.