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 cette ressource
Comment lutter contre le Phishing ?
Dans un environnement cyber en constante mutation, le phishing évolue vers des attaques toujours plus sophistiquées combinant IA, automatisation et industrialisation. Découvrez les réponses technologiques préconisées par les experts Eviden et les perspectives associées à leur mise en œuvre.
