Em um de nossos , dedicado ao planejamento da infraestrutura para a implementação do Zimbra Collaboration Suite nas empresas, foi mencionado que a principal limitação ao trabalhar com essa solução é a velocidade de leitura e gravação dos dispositivos de armazenamento nas caixas de correio. De fato, quando várias centenas de funcionários acessam simultaneamente a mesma caixa de correio, a largura de banda para leitura e gravação em discos rígidos pode não ser suficiente para garantir um serviço responsivo. Enquanto em pequenas instalações do Zimbra isso pode não ser um grande problema, em grandes empresas e para provedores de SaaS, isso pode resultar em um desempenho lento do e-mail, consequentemente reduzindo a eficiência dos colaboradores e violando acordos de nível de serviço (SLA). Por isso, ao projetar e operar grandes instalações do Zimbra, é crucial dedicar atenção especial à otimização do desempenho dos discos rígidos nas caixas de correio. Vamos analisar 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 em larga escala do Zimbra
Na fase de projeto de uma instalação de alta carga do Zimbra, o administrador deve escolher qual sistema de armazenamento utilizar. Para decidir sobre essa questão, é importante saber que a principal carga nos discos rígidos é gerada pelos bancos de dados MariaDB, pelo sistema de busca Apache Lucene, além do armazenamento de objetos BLOB, que fazem parte do Zimbra Collaboration Suite. Por isso, para o funcionamento desses produtos em condições de alta carga, é necessário utilizar hardware rápido e confiável.
Em condições normais, o Zimbra pode ser instalado tanto em RAID de discos rígidos quanto em armazenamentos conectados via protocolo NFS. Em instalações muito pequenas, o Zimbra pode ser instalado em um disco SATA comum. No entanto, em grandes instalações, todas essas tecnologias apresentam diferentes desvantagens em termos de baixa velocidade de gravação ou baixa confiabilidade, o que é inaceitável, tanto para grandes empresas quanto para provedores de SaaS.
É por isso que, em meio a grandes infraestruturas, o uso de SAN é a melhor opção para o Zimbra. Atualmente, ela é capaz de proporcionar a maior largura de banda para dispositivos de armazenamento e, devido à capacidade de conectar uma grande quantidade de cache, seu uso praticamente não traz riscos significativos para a empresa. Uma boa ideia é usar NVRAM, que é aplicada em muitos SAN para acelerar a operação durante a gravação. Já a cacheação dos dados gravados nos próprios discos deve ser desativada, pois isso pode causar danos irreparáveis aos meios de armazenamento e perda de dados em caso de problemas de energia.
No que diz respeito à escolha do sistema de arquivos, a melhor opção é usar os padrões do Linux, Ext3/Ext4. O principal detalhe relacionado ao sistema de arquivos é que ele deve ser montado com o parâmetro -noatime. Esse parâmetro desabilita a função de registro da última hora de acesso aos arquivos, diminuindo significativamente a carga de leitura e gravação. De maneira geral, ao criar um sistema de arquivos ext3 ou ext4 para o Zimbra, devem ser utilizados os seguintes parâmetros da ferramenta mke2fs:
-j — Para criar o diário do sistema de arquivos. Crie o sistema de arquivos com um diário ext3/ext4.
-L NOME — Para criar um nome de volume, que poderá ser utilizado em /etc/fstab.
-O dir_index — Para usar uma árvore de pesquisa hash, acelerando a busca de arquivos em grandes diretórios.
-m 2 — Para reservar 2% do volume em grandes sistemas de arquivos para o diretório raiz.
-J size=400 — Para criar um grande diário.
-b 4096 — Para definir o tamanho do bloco em bytes.
-i 10240 — Para o armazenamento de mensagens, esse parâmetro deve corresponder ao tamanho médio das mensagens. Deve-se ter cuidado com esse parâmetro, pois seu valor não poderá ser alterado posteriormente.
Além disso, recomenda-se habilitar dirsync para o armazenamento de objetos BLOB, armazenamento de metadados de busca Lucene e armazenamento de filas MTA. Essa ação deve ser realizada porque, geralmente, o Zimbra utiliza a ferramenta fsync para garantir a gravação de blobs de dados no disco. No entanto, quando o armazenamento de e-mails Zimbra ou MTA criam novos arquivos durante a entrega de mensagens, há a necessidade de gravar no disco as alterações ocorridas nas pastas correspondentes. É por isso que, mesmo que o arquivo já tenha sido gravado no disco por meio de fsync, a gravação sobre sua adição no diretório pode não ter a chance de ser gravada no disco e, como resultado, pode ser perdida devido a uma falha súbita no servidor. Graças ao uso de dirsync esses problemas podem ser evitados.
2. Otimização com infraestrutura Zimbra em funcionamento
Frequentemente acontece que, após vários anos de operação do Zimbra, o número de seus usuários aumenta significativamente e o funcionamento do serviço se torna, dia após dia, menos responsivo. A solução para essa situação é óbvia: basta adicionar novos servidores à infraestrutura, para que o serviço volte a operar com a mesma velocidade de antes. Entretanto, nem sempre é possível adicionar novos servidores à infraestrutura de imediato, a fim de aumentar seu desempenho. Muitas vezes, os gerentes de TI têm que esperar para aprovar a aquisição novos servidores com o departamento de contabilidade ou o departamento de segurança; além disso, muitas vezes os fornecedores atrasam, podem entregar um novo servidor com demora ou até mesmo trazer o que não é necessário.
É claro que o ideal é construir sua infraestrutura Zimbra com folga, para sempre ter espaço para expansão e não depender de ninguém, mas se um erro já foi cometido, o gerente de TI deve fazer o possível para atenuar suas consequências. Assim, por exemplo, o gerente de TI pode conseguir um pequeno aumento de desempenho desativando temporariamente os serviços do sistema Linux, que regularmente acessam os discos rígidos e, como resultado, podem impactar negativamente a velocidade do Zimbra. Portanto, pode-se desativar temporariamente:
autofs, netfs — Serviços de descoberta de sistemas de arquivos remotos
cups — Serviço de impressão
xinetd, vsftpd — Serviços embutidos do *NIX, que provavelmente você não precisará
portmap, rpcsvcgssd, rpcgssd, rpcidmapd — Serviços de chamada de procedimento remoto, que são geralmente usados em conjunto com sistemas de arquivos de rede
dovecot, cyrus-imapd, sendmail, exim, postfix, ldap — Duplicatas das principais utilidades incluídas no Zimbra Collaboration Suite
slocate/updatedb — Como o Zimbra armazena cada mensagem em um arquivo separado, a execução diária do serviço updatedb pode causar problemas, e, portanto, isso pode ser feito manualmente durante os períodos de menor carga nos servidores.
A economia de recursos do sistema resultante da desativação desses serviços pode não ser muito significativa, mas mesmo isso pode ser bastante útil em condições próximas de força maior. Após adicionar um novo servidor à infraestrutura do Zimbra, é recomendável reativar os serviços que foram desativados anteriormente.
Também é possível otimizar o funcionamento do Zimbra ao transferir o serviço syslog para um servidor separado, para que durante a operação ele não sobrecarregue os discos rígidos dos repositórios de e-mail. Para esses fins, qualquer computador, até mesmo um barato Raspberry Pi, pode servir.
Fonte: habr.com
