L'implémentation de toute solution informatique au sein d'une entreprise commence par la conception. À cette étape, le responsable informatique doit évaluer le nombre de serveurs et leurs caractéristiques, afin qu'ils soient suffisants pour tous les utilisateurs et que le rapport qualité-prix de ces serveurs soit optimal, sans que le coût de création de l'infrastructure informatique pour le nouveau système d'information n'engendre un sérieux trou dans le budget IT de l'entreprise. Voyons donc comment concevoir l'infrastructure pour l'implémentation de Zimbra Collaboration Suite dans l'entreprise.
La principale caractéristique de Zimbra par rapport à d'autres solutions est que, dans le cas de ZCS, la puissance processeur ou la mémoire vive ne deviennent rarement un « goulot d'étranglement ». La vitesse d'entrée et de sortie du disque dur constitue généralement la principale contrainte, c'est pourquoi il est crucial de se concentrer sur les systèmes de stockage. Les exigences minimales officiellement déclarées pour Zimbra en environnement de production sont un processeur 64 bits à 4 cœurs avec une fréquence d'horloge de 2 GHz, 10 Go pour les fichiers système et les journaux, ainsi qu'au moins 8 Go de RAM. Ces caractéristiques suffisent généralement à assurer un fonctionnement réactif du serveur. Mais que faire si vous devez déployer Zimbra pour 10 000 utilisateurs ? Quels serveurs et comment les déployer dans ce cas ?
Commençons par le fait que l'infrastructure pour 10 000 utilisateurs doit être multi-serveurs. Une infrastructure multi-serveurs permet d'une part de rendre Zimbra évolutif, et d'autre part d'assurer un fonctionnement réactif du système d'information même en cas de forte affluence d'utilisateurs. Il est souvent assez difficile de prédire combien d'utilisateurs un serveur Zimbra pourra gérer de manière optimale, car cela dépend beaucoup de l'intensité de leur usage des calendriers et des courriels, ainsi que du protocole utilisé. C'est pourquoi, à titre d'exemple, nous allons mettre en place 4 stockages de messagerie. En cas de manque ou d'excès considérable de capacités, nous pourrons soit désactiver, soit ajouter un autre serveur.
Ainsi, lors de la conception d'une infrastructure pour 10 000 personnes, il sera nécessaire de créer des serveurs LDAP, MTA et Proxy, ainsi que 4 stockages de messagerie. Notons que les serveurs LDAP, MTA et Proxy peuvent être virtualisés. Cela permettra de réduire les coûts liés au matériel serveur et facilitera la sauvegarde et la restauration des données. En revanche, en cas de panne d'un serveur physique, vous risquez de vous retrouver sans MTA, LDAP et Proxy. C'est pourquoi le choix entre des serveurs physiques ou virtuels doit être fait en fonction du temps d'arrêt que vous pouvez vous permettre en cas de situation d'urgence. Les stockages de messagerie devraient plutôt être hébergés sur des serveurs physiques, car c'est là que se produira la majorité des cycles d'écriture, qui limitent la performance de Zimbra, et donc un plus grand nombre de canaux de transmission de données permettra d'augmenter considérablement la performance de Zimbra.
En principe, après la création serveurs des serveurs LDAP, MTA, Proxy, des stockages en réseau et leur intégration dans une infrastructure unique, Zimbra Collaboration Suite pour 10 000 utilisateurs est prête à être mise en service. Le schéma de fonctionnement de cette configuration sera assez simple :
Le schéma montre les principaux nœuds du système et les flux de données qui circuleront entre eux. Avec cette configuration, l'infrastructure sera complètement non protégée contre la perte de données, le temps d'arrêt dû à la défaillance d'un serveur, etc. Voyons comment protéger votre infrastructure contre ces problèmes.
Le principal moyen est la redondance matérielle. Des nœuds MTA et Proxy supplémentaires peuvent, en cas de défaillance des serveurs principaux, assumer temporairement le rôle de serveurs principaux. Dupliquer les nœuds de l'infrastructure critique est presque toujours une excellente idée, mais cela n'est pas toujours réalisable dans l'ampleur désirée. Un exemple marquant est la sauvegarde des serveurs où les emails sont stockés. Actuellement, Zimbra Collaboration Suite Open-Source Edition ne prend pas en charge la création de stockages redondants, donc en cas de défaillance de l'un de ces serveurs, il ne sera pas possible d'éviter les arrêts, et pour réduire le temps d'arrêt causé par la défaillance du stockage de messagerie, le responsable informatique peut déployer sa copie de sauvegarde sur un autre le serveur.
Étant donné qu'il n'y a pas de système de sauvegarde intégré dans Zimbra OSE, nous aurons besoin de Zextras Backup, qui prend en charge la sauvegarde en temps réel, ainsi qu'un stockage externe. Comme Zextras Backup, en effectuant des sauvegardes complètes et incrémentales, stocke toutes les données dans le dossier /opt/zimbra/backup, il serait judicieux de monter un stockage externe, réseau ou même cloud, afin qu'en cas de panne de l'un des serveurs, nous disposions d'un support contenant une sauvegarde à jour au moment de l'incident. Il peut être restauré sur un serveur physique de secours, sur une machine virtuelle ou dans le cloud. Il serait également judicieux d'installer un MTA avec un filtre anti-spam devant le serveur Zimbra Proxy pour réduire le volume de trafic indésirable entrant sur le serveur.
En fin de compte, l'infrastructure protégée de Zimbra ressemblera à ceci :
Avec cette configuration, l'infrastructure Zimbra pourra non seulement fournir des services de qualité à 10.000 utilisateurs, mais également permettre une réponse rapide en cas de situation d'urgence.
Source : habr.com
