NFS em Btrfs em vários dispositivos .vs. Glusterfs em volume distribuído?

Question

Eu considero um armazenamento para e-mail. Este sistema de armazenamento é executado na minha própria nuvem privada (já replicado), então eu não me importo com a replicação.

Estou pensando em duas opções:

1- Vou criar alguns "disk" (volume na nuvem), e criar um filesystem em Btrfs multi-disk; e quando o sistema de arquivos estiver cheio, eu vou criar mais "disco" e adicioná-lo ao sistema de arquivos btrfs:

btrfs device add /dev/vdX /mnt

btrfs filesystem balance /mnt

Esse ponto de montagem (/ mnt) será exposto pelo NFS, e meu servidor Dovecot montará essa exportação e armazenará emails nela.

2- Vou criar poucos "discos" (volume na nuvem) e criar um volume distribuído do GlusterFS em todos esses discos; e quando o sistema de arquivos estiver cheio, eu vou criar mais "disco" e adicionar novos "discos" ao volume distribuído do GlusterFS, um reequilíbrio. Meu Dovecote montará este volume usando o glusterfs-client e armazenará emails nele.

(Repetir: não preciso de replicar, porque o meu "disco", o volume na nuvem privada, a replicação do underhood)

Você acha qual opção tem melhor:

• performance? (muitas pequenas E / S de leitura / gravação)
• estável?
• flexível?

Answer 1

Você deve considerar o padrão de E / S de um servidor de e-mail: Lê / grava muitos arquivos pequenos o mais rápido possível. Ambas as suas variantes são realmente inadequadas para isso quando se lida com um grande número de clientes, IMHO.

O FS não é rápido o suficiente, e eu acho que especialmente a sobrecarga de bloqueio do GlusterFS será significativa. Então você adiciona outra camada com o NFS, que tem sua própria sobrecarga. Em vez disso, tentaria conectar o armazenamento de email com o mínimo de sobrecarga possível e com um sistema de arquivos rápido. Geralmente, isso significa conectar-se o mais diretamente possível ao armazenamento físico, mas, como você oculta sua arquitetura atrás de termos de bingo como "nuvem privada", não sabemos o que seria possível.

Uma abordagem que você poderia tentar seria exportar o armazenamento via iSCSI para o servidor de e-mail e usar um FS rápido com muitos arquivos pequenos e, se for realmente importante, usar o LVM para poder adicionar espaço facilmente a esse FS na forma de volumes iSCSI adicionais (o que adiciona um pouco de sobrecarga).

Não importa o que você tente: você precisa comparar as diferentes variantes e ver se obtém o desempenho necessário.

    

Answer 2

Se você precisar escolher um dos dois acima, então o NFS é preferível, eu acho.

O GlusterFS perde todos os seus benefícios como sistema de arquivos distribuído em sua configuração desde o OpenStack os volumes ainda são montados a partir de um armazenamento central. Não é nem mais estável nem mais inteligente, pois deve se preocupar com o bloqueio de arquivos distribuídos durante o bloqueio de NFS é feito em um servidor sigle.

Não tenho certeza de que combinar seu armazenamento de vários dispositivos é uma boa ideia. alternativamente você pode considerar pular a funcionalidade de serviço de volume do OpenStack de alto nível e expor seu armazenamento de volume LVM (/ ZFS / SAN) diretamente formatado exportado pelo NFS. Dessa forma, você eliminará o nível desnecessário de iSCSI e poderá aumentar o espaço de armazenamento de mensagens sob demanda, desde que o armazenamento principal tenha espaço livre suficiente.