Estou considerando um armazenamento para e-mail. Este sistema de armazenamento é executado em minha própria nuvem privada (já replicada), então não me importo com replicação.
Estou pensando em 2 opções:
1- Vou criar alguns "disco" (volume na nuvem), e criar um sistema de arquivos Btrfs em multi-disco; e quando o sistema de arquivos estiver cheio, criarei mais "disco" e o adicionarei ao sistema de arquivos btrfs:
btrfs device add /dev/vdX /mnt
btrfs filesystem balance /mnt
Este ponto de montagem (/mnt) será exposto por NFS, e meu servidor Dovecot montará esta exportação e armazenará e-mails nela.
2- Vou criar alguns "disco" (volume na nuvem), e criar um volume distribuído GlusterFS entre esses discos; e quando o sistema de arquivos estiver cheio, criarei mais "disco" e adicionarei novo(s) "disco"(s) ao volume distribuído do GlusterFS, e o reequilibrarei. Meu Dovecote montará esse volume usando glusterfs-client e armazenará e-mails nele.
(Repita: não preciso replicar, porque meu "disco", volume na nuvem privada, é replicado no subsolo)
Você acha qual opção é melhor:
- desempenho? (muitos pequenos E/S de leitura/gravação)
- estábulo?
- flexível?
Responder1
Você deve considerar o padrão de E/S de um servidor de e-mail: leitura/gravaçãomuitosarquivos pequenos o mais rápido possível. Ambas as suas variantes são realmente inadequadas para isso ao lidar com um grande número de clientes, IMHO.
Nenhum dos FS é rápido o suficiente, e acho que especialmente a sobrecarga de bloqueio do GlusterFS será significativa. Em seguida, você adiciona outra camada com o NFS, que possui sua própria sobrecarga. Em vez disso, eu tentaria conectar o armazenamento de correio com a menor sobrecarga possível e com um sistema de arquivos rápido. Normalmente, isso significa conectar-se o mais diretamente possível ao armazenamento físico, mas como você esconde 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 então usar um FS que seja rápido com muitos arquivos pequenos e talvez, se for realmente importante, usar LVM para poder adicionar facilmente espaço a esse FS no forma de volumes iSCSI adicionais (o que adiciona alguma sobrecarga).
Faça o que fizer: você deve avaliar as diferentes variantes e ver se obtém o desempenho necessário.
Responder2
Se você precisar escolher um dos dois acima, então o NFS é preferível, eu acho.
GlusterFS perde todos os seus benefícios como sistema de arquivos distribuído em sua configuração, pois os volumes OpenStack ainda são montados a partir de um armazenamento central. Não é mais estável nem mais inteligente, pois deve se preocupar com o bloqueio distribuído de arquivos enquanto o bloqueio NFS é feito em um servidor único.
Não tenho certeza de que combinar o armazenamento de vários dispositivos seja uma boa ideia. Como alternativa, você pode considerar ignorar a funcionalidade do serviço de volume OpenStack de alto nível e expor seu volume LVM (/ZFS/SAN) formatado diretamente de armazenamento e exportado pelo NFS. Seguindo esse caminho, você eliminará o nível iSCSI desnecessário e poderá aumentar o espaço de armazenamento de correio sob demanda, desde que o armazenamento principal tenha espaço livre suficiente.