Otimize o armazenamento de mensagens no Zimbra Collaboration Suite

Em um de nossos artigos anteriores sobre planejamento de infraestrutura durante a implementação do Zimbra Collabortion Suite na empresa, foi dito que a principal limitação no trabalho desta solução é a velocidade de entrada / saída de dispositivos de disco nos armazenamentos de correio. De fato, no momento em que várias centenas de funcionários da empresa acessam simultaneamente o mesmo armazenamento de correio, a largura do canal para gravar e ler informações de discos rígidos pode não ser suficiente para o serviço responsivo. E se, para pequenas instalações do Zimbra, isso não se tornar um problema específico, no caso de grandes empresas e provedores de SaaS, tudo isso poderá levar a um trabalho de email sem resposta e, como resultado, redução da eficiência dos funcionários, bem como à violação do SLA. É por isso que ao projetar e operar instalações Zimbra em larga escala, atenção especial deve ser dada à questão de otimizar a operação de discos rígidos no armazenamento de mensagens. Vamos examinar dois casos e tentar descobrir quais métodos de otimização da carga nos armazenamentos de disco podem ser aplicados em cada um deles.



1. Otimização ao projetar uma instalação Zimbra em larga escala

No estágio de design de uma instalação Zimbra altamente carregada, seu administrador terá que escolher qual sistema de armazenamento de dados usar. Para decidir sobre esse problema, você deve saber que a carga principal nos discos rígidos é criada pelo MariaDB DBMS, pelo sistema de pesquisa Apache Lucene e pelo armazenamento de blobs que fazem parte do Zimbra Collaboration Suite. É por isso que, para a operação desses produtos de software sob altas cargas, é necessário o uso de equipamentos confiáveis ​​e de alta velocidade.

Sob condições normais, o Zimbra pode ser instalado no RAID a partir de discos rígidos e no armazenamento conectado via protocolo NFS. Em casos de instalações muito pequenas, você pode instalar o Zimbra em uma unidade SATA comum. No entanto, em grandes instalações, todas essas tecnologias demonstram várias desvantagens na forma de velocidade de gravação reduzida ou baixa confiabilidade, o que é inaceitável para grandes empresas e, principalmente, para provedores de SaaS.

É por isso que, em condições de infra-estruturas de grande escala, o Zimbra é melhor usar SAN. É ela quem, no momento, é capaz de fornecer a maior largura de banda para dispositivos de armazenamento e, ao mesmo tempo, devido à capacidade de conectar uma grande quantidade de cache, seu uso praticamente não acarreta riscos significativos para a empresa. Uma boa idéia seria usar a NVRAM, que é usada em muitas SANs para acelerar o desempenho da gravação. Mas é melhor desativar o armazenamento em cache de dados gravados nos próprios discos, pois isso pode causar danos irreparáveis ​​à mídia e perda de dados em caso de problemas de energia.

Quanto à escolha do sistema de arquivos, a melhor opção seria usar o padrão para Linux Ext3 / Ext4. A principal nuance associada ao sistema de arquivos é que ele deve ser montado com a opção -noatime . Este parâmetro desativará a função de fixar a hora do último acesso aos arquivos, o que significa que reduzirá bastante a carga de leitura e gravação. Em geral, ao criar um sistema de arquivos ext3 ou ext4 para o Zimbra, os seguintes parâmetros do utilitário mke2fs devem ser usados:

-j - Crie o sistema de arquivos com um diário ext3 / ext4.
-L TITLE - Para criar um nome de volume, use-o no / etc / fstab
-O dir_index - Para usar uma árvore de pesquisa com hash para acelerar as pesquisas de arquivo em grandes diretórios
-m 2 - Para reservar 2% do volume em sistemas de arquivos grandes no diretório raiz
-J size = 400 - Para criar um log grande
-b 4096 - Para determinar o tamanho do bloco em bytes
-i 10240 - Para o armazenamento de mensagens, esta opção deve corresponder ao tamanho médio da mensagem. Você deve considerar cuidadosamente esse parâmetro, pois posteriormente seu valor não pode ser alterado

Além disso, é recomendável habilitar o dirsync para armazenamento de blob, armazenamento de metadados de pesquisa Lucene e armazenamento de fila do MTA. Isso deve ser feito pelo motivo que normalmente o Zimbra usa o utilitário fsync para garantir que ele grave blob com dados no disco. No entanto, quando o Zimbra Mailbox ou o MTA cria novos arquivos durante a entrega da mensagem, torna-se necessário gravar no disco as alterações que ocorreram nas pastas correspondentes. É por isso que, mesmo no caso em que o arquivo já foi gravado no disco usando o fsync , o registro de adicioná-lo aos diretórios pode não ser capaz de ser gravado no disco e, como resultado, pode ser perdido devido a uma súbita falha do servidor. Usando o dirsync, esses problemas podem ser evitados.

2. Otimização com uma infraestrutura Zimbra em funcionamento

Muitas vezes acontece que, após vários anos de operação do Zimbra, o número de usuários aumenta significativamente e o serviço se torna cada vez menos responsivo a cada dia. A saída dessa situação é óbvia: você só precisa adicionar novos servidores à infraestrutura para que o serviço funcione novamente mais rápido do que antes. Enquanto isso, está longe de ser sempre possível adicionar imediatamente novos servidores à infraestrutura para aumentar sua velocidade. Freqüentemente, os gerentes de TI precisam coordenar por um longo período a compra de novos servidores com o departamento de contabilidade ou segurança; além disso, os fornecedores geralmente não conseguem atrasar o novo servidor ou não entregam o que é necessário.

Obviamente, é melhor criar sua infraestrutura Zimbra com uma margem para sempre ter uma margem para sua expansão e não depender de ninguém; no entanto, se o erro já tiver sido cometido, o gerente de TI poderá suavizar suas conseqüências. Por exemplo, um gerente de TI pode obter um pequeno aumento de produtividade desativando temporariamente os serviços do sistema Linux, que acessam regularmente discos rígidos durante a operação e, como resultado, podem afetar negativamente a velocidade do Zimbra. Então, por um tempo você pode desativar:

autofs, netfs - Serviços de descoberta remota de sistemas de arquivos
cups - Serviço de impressão
xinetd, vsftpd - Serviços * NIX integrados dos quais você provavelmente não precisará
portmap, rpcsvcgssd, rpcgssd, rpcidmapd - Serviços de chamada de procedimento remoto que são comumente usados ​​em conjunto com sistemas de arquivos de rede
dovecot, cyrus-imapd, sendmail, exim, postfix, ldap - Duplicatas dos principais utilitários incluídos no Zimbra Collaboration Suite
slocate / updatedb - Como o Zimbra armazena cada mensagem em um arquivo separado, iniciar o serviço updatedb diariamente pode causar problemas e, portanto, você pode fazê-lo manualmente durante o menor carregamento do servidor.

A economia de recursos do sistema como resultado da desativação desses serviços não será muito significativa, mas mesmo isso pode ser muito útil em condições próximas à força maior. Depois que o novo servidor é adicionado à infraestrutura do Zimbra, é recomendável reativar os serviços anteriormente desativados.

Também é possível otimizar a operação do Zimbra movendo o serviço syslog para um servidor separado para que ele não carregue os discos rígidos de armazenamento de email durante a operação. Para esses fins, quase qualquer computador, até um Raspberry Pi barato de placa única, é adequado.

Para todas as perguntas relacionadas ao Zextras Suite, você pode entrar em contato com o representante da empresa "Zextras" Katerina Triandafilidi pelo e-mail katerina@zextras.com