Optimisation des performances des dépôts de mails dans Zimbra Collaboration Suite

Dans l'un de nos des articles précédents, dédié à la planification de l'infrastructure lors de la mise en œuvre de la suite de collaboration Zimbra, il a été mentionné que la principale limitation de cette solution est la vitesse d'entrée-sortie des dispositifs de stockage dans les entrepôts de courriers. En effet, au moment où plusieurs centaines d'employés d'une entreprise accèdent simultanément au même entrepôt de courriers, la bande passante pour l'écriture et la lecture des informations à partir des disques durs peut ne pas être suffisante pour un fonctionnement réactif du service. Et si, pour de petites installations Zimbra, cela ne pose pas de problème majeur, pour les grandes entreprises et les fournisseurs de SaaS, tout cela pourrait entraîner un service de messagerie non réactif et, par conséquent, une diminution de l'efficacité des employés, ainsi qu'une violation des SLA. C'est pourquoi, lors de la conception et de l'exploitation de grandes installations Zimbra, une attention particulière doit être accordée à l'optimisation du travail des disques durs dans les entrepôts de courriers. Examinons deux cas et essayons de déterminer quelles méthodes d'optimisation de la charge des stockages disques peuvent être appliquées dans chacun d'eux.

1. Optimisation lors de la conception d'une grande installation Zimbra

Lors de la phase de conception d'une installation à forte charge de Zimbra, l'administrateur devra choisir quel système de stockage de données utiliser. Pour se décider sur ce point, il convient de savoir que la charge principale sur les disques durs est générée par les bases de données MariaDB, le système de recherche Apache Lucene, ainsi que le stockage des objets BLOB, qui composent la suite de collaboration Zimbra. C'est pourquoi, pour le fonctionnement de ces produits logiciels sous forte charge, il est essentiel d'utiliser du matériel rapide et fiable.

Dans des conditions normales, Zimbra peut être installé soit sur un RAID de disques durs, soit sur des stockages connectés via le protocole NFS. Dans le cas de très petites installations, Zimbra peut être installé sur un disque SATA ordinaire. Cependant, dans le cadre de grandes installations, toutes ces technologies présentent divers inconvénients tels qu'une vitesse d'écriture réduite ou une faible fiabilité, ce qui est inacceptable tant pour les grandes entreprises que, bien sûr, pour les fournisseurs de SaaS.

C'est pourquoi, dans le cadre d'infrastructures à grande échelle, Zimbra sera mieux soutenu par l'utilisation d'un SAN. Ce dernier est actuellement capable d'offrir la plus grande bande passante pour les dispositifs de stockage et, grâce à la possibilité de connecter une grande quantité de cache, son utilisation présente pratiquement aucun risque substantiel pour l'entreprise. L'utilisation de NVRAM, souvent présente dans de nombreux SAN pour accélérer les opérations d'écriture, est également une bonne idée. En revanche, il est préférable de désactiver la mise en cache des données écrites sur les disques eux-mêmes, car cela peut entraîner des dommages irréparables aux supports et une perte de données en cas de problèmes d'alimentation.

En ce qui concerne le choix du système de fichiers, les options standard pour Linux, à savoir Ext3/Ext4, sont idéales. Le principal point à considérer avec le système de fichiers est qu'il doit être monté avec l'option -noatime. Cette option désactivera la fonction de journalisation de la dernière consultation des fichiers, ce qui réduira donc considérablement la charge en lecture et écriture. Globalement, lors de la création d'un système de fichiers ext3 ou ext4 pour Zimbra, les paramètres suivants de l'outil mke2fs:

-j — Pour créer un journal de système de fichiersCréer le système de fichiers avec un journal ext3/ext4.
-L NOM — Pour définir le nom du volume, afin de l'utiliser ensuite dans /etc/fstab
-O dir_index — Pour utiliser un arbre de recherche haché afin d'accélérer la recherche de fichiers dans de grands répertoires
-m 2 — Pour réserver 2 % de l'espace des grands systèmes de fichiers pour le répertoire racine
-J size=400 — Pour créer un grand journal
-b 4096 — Pour définir la taille du bloc en octets
-i 10240 — Pour le stockage des messages, ce paramètre doit correspondre à la taille moyenne des messages. Il est important de prêter attention à ce paramètre, car sa valeur ne pourra pas être modifiée par la suite.

De plus, il est recommandé d'activer dirsync pour le stockage des objets BLOB, le stockage des métadonnées de recherche Lucene et le stockage de la file d'attente MTA. Cela doit être fait car Zimbra utilise généralement l'outil fsync pour garantir l'enregistrement des blobs de données sur le disque. Cependant, lorsque le stockage de courrier Zimbra ou MTA crée de nouveaux fichiers lors de la livraison des messages, il devient nécessaire d'enregistrer sur le disque les modifications apportées aux dossiers correspondants. C'est pourquoi même si le fichier est déjà enregistré sur le disque grâce à fsync, l'enregistrement de son ajout dans le répertoire peut ne pas avoir le temps d'être enregistré sur le disque et peut ainsi être perdu en raison d'une défaillance soudaine du serveur. Grâce à l'utilisation de dirsync ces problèmes peuvent être évités.

2. Optimisation avec une infrastructure Zimbra opérationnelle

Il arrive souvent qu'après plusieurs années d'utilisation, le nombre d'utilisateurs de Zimbra augmente considérablement et le service devient de moins en moins réactif chaque jour. La solution est évidente : il suffit d'ajouter de nouveaux serveurs à l'infrastructure pour que le service fonctionne à nouveau aussi rapidement qu'auparavant. Toutefois, il n'est pas toujours possible d'ajouter immédiatement de nouveaux serveurs à l'infrastructure pour améliorer ses performances. Souvent, les responsables informatiques doivent passer beaucoup de temps à obtenir l'approbation de l'achat nouveaux serveurs avec la comptabilité ou le service de sécurité, en outre, les fournisseurs déçoivent souvent, qui peuvent livrer un nouveau serveur en retard ou ne pas livrer ce qui est nécessaire.

Il est évident qu'il est préférable de construire son infrastructure Zimbra avec une marge, pour toujours avoir une réserve pour son extension et ne dépendre de personne, cependant, si une erreur a déjà été commise, le responsable informatique doit se contenter d'atténuer au mieux ses conséquences. Par exemple, le responsable informatique peut obtenir une légère augmentation des performances en désactivant temporairement les services système Linux, qui accèdent régulièrement aux disques durs et peuvent ainsi avoir un impact négatif sur la vitesse de fonctionnement de Zimbra. Ainsi, on peut désactiver temporairement:

autofs, netfs — Services de découverte de systèmes de fichiers distants
cups — Service d'impression
xinetd, vsftpd — Services intégrés *NIX, qui ne vous seront probablement pas nécessaires
portmap, rpcsvcgssd, rpcgssd, rpcidmapd — Services d'appel de procédures distantes, généralement utilisés en conjonction avec des systèmes de fichiers en réseau
dovecot, cyrus-imapd, sendmail, exim, postfix, ldap — Doublons des utilitaires principaux compris dans Zimbra Collaboration Suite
slocate/updatedb — Étant donné que Zimbra stocke chaque message dans un fichier distinct, l'exécution quotidienne du service updatedb peut causer des problèmes, et il est donc préférable de le faire manuellement pendant les périodes de faible charge sur les serveurs.

L'économie des ressources système résultant de la désactivation de ces services ne sera pas très significative, mais cela peut être très utile dans des conditions proches de la force majeure. Une fois que le nouveau serveur est ajouté à l'infrastructure Zimbra, il est recommandé de réactiver les services précédemment désactivés.

Il est également possible d'optimiser le fonctionnement de Zimbra en déplaçant le service syslog sur un serveur distinct pour éviter qu'il ne surcharge les disques durs des stockages de messagerie pendant son fonctionnement. Pour ces besoins, presque n'importe quel ordinateur peut convenir, même un Raspberry Pi bon marché.

Source : habr.com