> Tech > Le secret d’une bonne mise en oeuvre d’Exchange

Le secret d’une bonne mise en oeuvre d’Exchange

Tech - Par Brien Posey - Publié le 24 juin 2010
email

Tout le monde peut utiliser Exchange Setup sur un serveur etcompatibilité matérielle (HCL, Hardware Compatibility List) de Microsoft existe pour une bonne raison : elle contient la liste du matériel que Microsoft a testé en profondeur et jugé compatible à 100 % avec l’OS Windows Server. Je vous conseille de n’utiliser que du matériel certifié Microsoft, d’abord pour éviter des problèmes de compatibilité mais aussi pour obtenir plus facilement l’assistance technique en cas de besoin. Pour vous guider dans votre achat du matériel serveur, tenez compte de la politique de Microsoft à propos du matériel recensé HCL. Bien que la HCL ne contienne que des composantes individuelles (cartes système, contrôleurs SCSI, adaptateurs vidéo, par exemple), Microsoft ne certifie que des systèmes complets. Même si vous construisiez un serveur en ignorant les composantes certifiées par Microsoft, le serveur ne serait pas pris en charge. En revanche, Microsoft vous permet de démarrer avec un serveur certifié et de lui ajouter progressivement d’autres composantes de la liste HCL.

Le secret d’une bonne mise en oeuvre d’Exchange

La phase de planning est la plus importante dans le déploiement d’Exchange. Pour tout savoir sur la planification du déploiement, il faudrait au moins un livre. Concentrons-nous donc sur deux aspects majeurs : la tolérance aux pannes et la reprise après sinistre. En effet, quelle que soit la qualité de la planification de votre organisation Exchange, il faut toujours s’attendre à une défaillance. Et il faut fixer le niveau de défaillance acceptable par l’entreprise. Clustering.

 Si la messagerie électronique est une application primordiale dans l’entreprise, n’acceptant aucun degré de défaillance, il faut envisager de regrouper en clusters les serveurs de base de données : si l’un des serveurs est défaillant, un autre serveur du cluster peut prendre le relais. De plus, cet agencement permet d’arrêter certains serveurs pour la maintenance, sans affecter la disponibilité du courriel. Il existe deux modèles de clustering : actif/actif et actif/ passif. Dans le modèle actif/actif, tous les serveurs sont utilisés simultanément, tandis dans le modèle actif/passif, un serveur au moins est en standby en prévision d’une éventuelle défaillance. Le modèle actif/passif est préférable.

En effet, en cas de défaillance dans un cluster actif/ actif, il n’y a pas de serveur de rechange en mesure de prendre le relais pour assumer la charge de travail. Il incombe alors au noeud de clusters restant d’effectuer à la fois son propre travail et celui du serveur défaillant. Au mieux, la performance sera réduite, mais il se peut aussi que la charge de travail submerge complètement le noeud de clusters restant. Sachez qu’un cluster actif/passif peut comporter plus de deux noeuds de clusters. Par conséquent, le pourcentage de matériel cluster qui reste inutilisé diminue au fur et à mesure que le nombre de noeuds de clusters augmente – sauf si des noeuds multiples sont destinés à être passifs.

Les administrateurs d’Exchange débutants croient, à tort, que les serveurs de base de données en cluster les protègeront contre tout genre de défaillance. En réalité, la mise en cluster d’un serveur de base de données ne protège que contre une défaillance dudit serveur. L’organisation Exchange comporte beaucoup d’autres points de défaillance unique – par exemple, un serveur DNS, un serveur Global Catalog (GC), un serveur Exchange frontal ou même une liaison WAN. Heureusement, tous ces obstacles peuvent être surmontés par la redondance.

De la même manière qu’un serveur de base de données Exchange peut être mis en cluster, un serveur frontal Exchange le peut aussi. Mais, dans ce cas, les modèles actif/ actif et actif/passif ne s’appliquent pas, parce qu’un serveur Exchange frontal n’est rien d’autre qu’un serveur Microsoft IIS qui se trouve héberger Outlook Wab Access (OWA). Donc, pour mettre en cluster un serveur Exchange frontal, il faudra utilisera le service Network Load Balacing (NLB), de la même manière que vous mettriez en cluster tout autre serveur Web. Consolider AD, DNS et GC.

Rappelons qu’Exchange dépend complètement de l’AD, lequel peut lui aussi constituer un point de défaillance. Or, si l’AD était défaillant ou s’il devenait inaccessible à Exchange, ce dernier serait lui aussi frappé. Peut-être pensez-vous que la présence de multiples DC (domain controllers) vous immunise contre une défaillance de l’implémentation d’AD. Bien vu, mais il faut aussi considérer les dépendances d’AD. La plus connue d’entre elles est probablement le fait qu’AD ne peut pas fonctionner sans un serveur DNS. Il faut donc absolument avoir au moins un serveur DNS secondaire afin que, en cas de défaillance du serveur DNS principal, AD puisse continuer à fonctionner.

Téléchargez gratuitement cette ressource

GTM Cloud Hybride 1,2,3 Partez !

GTM Cloud Hybride 1,2,3 Partez !

Ce guide d’achat pour les dirigeants présente une approche en cinq étapes avec des listes de vérification qui vous permettront, ainsi qu’à votre équipe informatique, de réussir votre transition vers le Cloud hybride. Il vous permettra de documenter vos besoins au moment d’adopter un modèle opérationnel du Cloud pour automatiser et optimiser la fourniture de tous vos services informatiques en vue de prendre en charge toute application sur tout type de Cloud.

Tech - Par Brien Posey - Publié le 24 juin 2010