Em um de nossos , dedicado ao planejamento de infraestrutura na implementação do Zimbra Collabortion Suite em uma empresa, foi dito que a principal limitação na operação desta solução é a velocidade de E/S dos dispositivos de disco em armazenamentos de correio. Com efeito, numa altura em que várias centenas de funcionários de uma empresa acedem simultaneamente ao mesmo armazenamento de correio, a largura do canal para escrever e ler informação de discos rígidos pode não ser suficiente para o funcionamento responsivo do serviço. E se para pequenas instalações do Zimbra isso não for um problema particular, então no caso de grandes empresas e provedores de SaaS, tudo isso pode levar à falta de resposta de e-mails e, como resultado, a uma diminuição na eficiência dos funcionários, bem como a uma violação de SLAs. É por isso que, ao projetar e operar instalações Zimbra em grande escala, atenção especial deve ser dada à otimização do desempenho dos discos rígidos no armazenamento de correio. Vejamos dois casos e tentemos descobrir quais métodos de otimização da carga no armazenamento em disco podem ser aplicados em cada um deles.
1. Otimização ao projetar uma instalação Zimbra em grande escala
Durante a fase de projeto de uma instalação Zimbra de alta carga, o administrador terá que escolher qual sistema de armazenamento usar. Para decidir sobre esta questão, você deve saber que a carga principal nos discos rígidos vem do DBMS MariaDB incluído no Zimbra Collaboration Suite, do mecanismo de busca Apache Lucene e do armazenamento de blob. É por isso que, para operar esses produtos de software sob condições de alta carga, é necessário utilizar equipamentos confiáveis e de alta velocidade.
Em condições normais, o Zimbra pode ser instalado tanto em discos rígidos RAID quanto em armazenamentos conectados via protocolo NFS. Para instalações muito pequenas, você pode instalar o Zimbra em uma unidade SATA normal. No entanto, no contexto de grandes instalações, todas estas tecnologias apresentam várias desvantagens sob a forma de velocidade de gravação reduzida ou baixa fiabilidade, o que não é inaceitável nem para grandes empresas nem, especialmente, para fornecedores de SaaS.
É por isso que em infraestruturas Zimbra de grande escala é melhor usar uma SAN. É esta tecnologia que atualmente é capaz de fornecer o maior rendimento para dispositivos de armazenamento e ao mesmo tempo, graças à capacidade de conectar uma grande quantidade de cache, a sua utilização praticamente não apresenta riscos significativos para a empresa. É uma boa ideia usar NVRAM, que é usada em muitas SANs para acelerar as coisas durante as gravações. Mas é melhor desabilitar o cache dos dados gravados nos próprios discos, pois isso pode causar danos irreparáveis à mídia e perda de dados se ocorrerem problemas de energia.
Quanto à escolha de um sistema de arquivos, a melhor opção seria usar o padrão Linux Ext3/Ext4. A principal nuance associada ao sistema de arquivos é que ele deve ser montado com o parâmetro -noatime. Esta opção desabilitará a função de registrar o horário 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 Zimbra, você deve usar os seguintes parâmetros de utilitário esposa2fs:
-j — Para criar um 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 para usar em /etc/fstab
-O dir_index - Para usar uma árvore de pesquisa com hash para acelerar pesquisas de arquivos em diretórios grandes
-m2 — Para reservar 2% do volume em sistemas de arquivos grandes para o diretório raiz
-J tamanho = 400 — Para criar uma revista grande
-b 4096 — Para determinar o tamanho do bloco em bytes
-i10240 - Para armazenamento de mensagens, esta configuração deve corresponder ao tamanho médio da mensagem. Você deve prestar muita atenção a este parâmetro, pois seu valor não pode ser alterado posteriormente.
Também é recomendado ativar dirsync para armazenamento de blob, armazenamento de metadados de pesquisa Lucene e armazenamento de fila MTA. Isso deve ser feito porque o Zimbra geralmente usa o utilitário fsync para gravação garantida de um blob com dados no disco. Porém, quando o armazenamento de correio Zimbra ou MTA cria novos arquivos durante a entrega da mensagem, torna-se necessário gravar no disco as alterações que ocorrem nas pastas correspondentes. É por isso que, mesmo que o arquivo já tenha sido gravado no disco usando fsync, o registro de sua adição ao diretório pode não ter tempo de ser gravado no disco e, como resultado, pode ser perdido devido a uma falha repentina do servidor. Graças ao uso dirsync esses problemas podem ser evitados.
2. Otimização com infraestrutura Zimbra em execução
Muitas vezes acontece que após vários anos de uso do Zimbra, o número de seus usuários aumenta significativamente e o serviço se torna cada vez menos responsivo a cada dia. A saída para esta situação é óbvia: basta adicionar novos servidores à infraestrutura para que o serviço volte a funcionar com a mesma rapidez de antes. Entretanto, nem sempre é possível adicionar imediatamente novos servidores à infraestrutura para aumentar o seu desempenho. Os gerentes de TI muitas vezes precisam gastar muito tempo coordenando a compra de novos servidores com o departamento de contabilidade ou segurança; além disso, muitas vezes são decepcionados por fornecedores que podem entregar um novo servidor com atraso ou até mesmo entregar a coisa errada.
Claro que o melhor é construir sua infraestrutura Zimbra com reserva para ter sempre uma reserva para sua expansão e não depender de ninguém, porém, se já tiver sido cometido um erro, o gestor de TI só poderá amenizar suas consequências como tanto quanto possível. Por exemplo, um gerente de TI pode obter um pequeno aumento de produtividade desabilitando temporariamente os serviços do sistema Linux que acessam regularmente os discos rígidos durante a operação e podem, portanto, impactar negativamente o desempenho do Zimbra. Portanto, você pode desativar temporariamente:
autofs, netfs - Serviços de descoberta remota de sistema de arquivos
copos – 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 geralmente são usados em conjunto com sistemas de arquivos de rede
pombal, cyrus-imapd, sendmail, exim, postfix, ldap — Duplicatas dos principais utilitários incluídos no Zimbra Collaboration Suite
slocate/atualizadodb - Como o Zimbra armazena cada mensagem em um arquivo separado, executar o serviço updateb todos os dias pode causar problemas, então você pode fazer isso manualmente quando os servidores estiverem menos ocupados
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 de força maior. Assim que o novo servidor for adicionado à infraestrutura Zimbra, é recomendável reativar os serviços desabilitados anteriormente.
Você também pode otimizar a operação do Zimbra movendo o serviço syslog para um servidor separado para que durante a operação ele não carregue os discos rígidos dos armazenamentos de correio. Quase qualquer computador é adequado para esses fins, até mesmo um Raspberry Pi barato de placa única.
Fonte: habr.com