Quais são os métodos típicos usados para expandir / desativar os servidores de armazenamento de e-mail?

Question

O que eu tentei:

• Eu tenho duas arquiteturas de armazenamento de email. Velho e novo.

Antigo:

• courier-imapds em vários servidores de armazenamento de 1 TB (18+).
• Se um deles mostrar sinais de falta de espaço em disco, migramos algumas contas de email para outro servidor.
• os servidores não possuem réplicas. nenhum backup também.

Novo:

• dovecot2 em um único servidor enorme com armazenamento de 16 TB (SATA) e alguns SSDs
• armazenamos novos e-mails nos SSDs e executamos uma limpeza do doveadm para mover os e-mails com mais de um dia para os discos SATA
• há um servidor idêntico que tem um backup de rsync de no máximo 15 minutos do servidor principal
• os superiores / gerentes queriam armazenar o máximo de armazenamento possível por servidor para minimizar o custo de SSDs por servidor
• o rsync'ing é feito porque o GlusterFS não estava replicando bem sob esse alto IO pequeno / aleatório.
Esperava-se que o dimensionamento de
• fosse feito com o provisionamento de outro par de servidores enormes
• ao enfrentar problemas como a arquitetura antiga, a movimentação manual de contas de e-mail seria feita.

Preocupações / dúvidas:

• Não estou convencido de que a ideia do sistema de arquivos replicado sincronamente funcione bem para o IO pesado aleatório / pequeno. O GlusterFS não está funcionando para nós ainda, não tenho certeza se existe outro sistema de arquivos disponível para este caso de uso. A ideia era manter pares idênticos e usar round-robin de DNS para entrega de e-mail e acesso IMAP / POP3. E se um dos servidores caísse por qualquer motivo (planejado / não planejado), nós moveríamos o IP para o outro servidor do par.
• Nos sistemas de arquivos como o Lustre, tenho a vantagem de um único namespace, pelo qual não preciso me preocupar com a migração manual de contas e a atualização de caminhos MAILHOME e outros metadados / dados.

Perguntas:

• Quais são os métodos típicos usados para ampliar / desativar o software tradicional (courier-imapd / dovecot)?
• O software tradicional que armazena em um sistema de arquivos montado localmente representa um obstáculo a ser dimensionado com o mínimo de "problemas"? Alguém precisa reescrever (partes deles) para trabalhar com um objeto de armazenamento de algum tipo - como o armazenamento de objetos do OpenStack?

Answer 1

O que eu vi em empresas de médio a grande porte é dispositivos de armazenamento redundantes, como a NetApp ou a EMC. Na verdade, eu estava conversando com um representante da EMC sobre o armazenamento de e-mails há pouco tempo, e ele disse que grandes servidores de e-mail são uma venda muito comum para eles.

Basicamente, eles eliminam todos os problemas de armazenamento do aplicativo. O desempenho de muitas leituras aleatórias curtas é obtido com o SSD ou o cache de memória com bateria. Todo o armazenamento está em um local com vários caminhos para módulos de servidor redundantes, portanto, não há latência de replicação.

Os servidores de aplicativos acessam o armazenamento usando o NFS ou o iSCSI, que é menos flexível, mas às vezes é necessário que o aplicativo não se comporte bem com o NFS. Isso permite que o armazenamento seja compartilhado por qualquer número de servidores em Ethernet de alta velocidade, para que você possa escalar até o desempenho máximo de E / S da caixa de armazenamento, que pode ser expandida conforme necessário.

No que diz respeito à redundância nos servidores de aplicativos, o mais barato é um pacote de clustering de software. Há também dispositivos como o Big-IP que lidam com isso no nível da rede e são independentes do sistema operacional. Depende muito se o aplicativo puder trabalhar de forma confiável sobre o NFS em paralelo com outras instâncias.

    

Answer 2

Estou um pouco desconfiado da grande abordagem do ferro - muitas vezes é difícil escalar e as pessoas tendem a adotar a abordagem de construir uma solução de failover e esperar que ela funcione quando ocorrer uma interrupção. A maioria das pessoas parou de aplicar essa abordagem a componentes como discos e placas de rede há muito tempo, mas aplicá-la a servidores é um pouco mais complicada. Você pode fragmentar os dados dividindo os usuários por meio do LDAP - mas isso resolve diretamente o problema de replicação; no entanto, ao executar, digamos, 8 pares de servidores com balanceamento de carga, a contenção provavelmente seria significativamente menor. Certamente glusterFS IMHO não funciona bem em sistemas altamente transacionais. Também não acho que um sistema de tipo nearline (por exemplo, AFS) seja uma boa ideia. O problema é que há muitas pequenas mudanças que precisam ser realizadas em todos os espelhos de forma síncrona - e realmente isso é feito da melhor forma no nível do aplicativo para manter a consistência /

Embora o Dovecot tenha a intenção de funcionar com o servidor multiplo no armazenamento compartilhado, uma abordagem do tipo NFS / iscsi ainda implica um tipo de abordagem de SPOF ou failover em vez de balanceamento de carga. Eu ouço muitas coisas boas sobre o GFS2 para cargas de trabalho transacionais - e reduzindo para sistemas menores, então executar isso em cima do DRBD daria a replicação necessária. Mas tente isolar os pares em switches dedicados (ou usar conexões Ethernet cruzadas) para manter o ruído da rede principal.

i.e. Lamento dizer que, embora o dovecot seja provavelmente muito melhor do que courier para esse tipo de operação, acho que sua nova arquitetura é um passo atrás.

(Eu estou supondo que você está usando maildir em vez de mbox)

Eu concordaria que ter um conjunto fixo de mapeamentos de usuários para clusters é um pouco sobrecarregado - e não o uso mais eficiente do recurso disponível - talvez o melhor compromisso seja o LVS em cima de uma SAN GFS2 e deixar o identificador de SAN para material de replicação. Para uma solução mais barata, embora isso seja um grande trabalho de adivinhação, exigiria alguma investigação / teste, talvez executando um sistema de arquivos FUSE com um backend de banco de dados - e usando a funcionalidade de replicação de banco de dados (por exemplo, mysqlfs)

    

Answer 3

Além do trabalho de backend que você está fazendo, você pode querer investigar o proxy imap no Nginx. Ele foi projetado para permitir que você direcione conexões de usuários para servidores de back-end específicos. Isso pode ser mais fácil do que tentar migrar os dados de um usuário em um esforço para equilibrar o tráfego e o carregamento de E / S.