Microsoft Exchange 2010 Server sera la septième version du système de messagerie de Microsoft qui, au fil des années, est devenu une référence en la matière. A chaque nouvelle version, on se demande ce que les développeurs de Redmond pourront ajouter à la version suivante.
Et bien, ils n’ont pas manqué d’imagination pour cette nouvelle mouture comme vous allez pouvoir le constater en lisant ces articles qui y sont consacrés. Oui, « ces articles », car contrairement à ce qui est pratiqué par la majorité des équipes de Microsoft, à savoir, une version majeure suivie d’une mineure, Exchange 2010 n’est pas la version R2 d’Exchange 2007 qui était présenté comme la version majeure. Avant de commencer, je souhaite juste vous préciser que ce qui est décrit est basé sur les versions bêta du produit et par conséquent, pourra évoluer au moment de la version finale.
Deux rôles sont touchés par les modifications du produit autour de la haute disponibilité : les serveurs de boîtes aux lettres (MBX) et les serveurs d’accès clients (CAS) Changements autour du rôle MBX Exchange 2007 n’a pas été avare d’acronymes : SCC (Single Copy Cluster), LCR (Local Continuous Replication) CCR (Cluster Continuous Replication) puis SCR (Standby Continuous Replication) avec l’arrivée du service pack 1.
Tout cela pour décrire des fonctions liées à la haute disponibilité. On peut également, y ajouter les solutions des constructeurs de stockage notamment avec la réplication synchrone des données pour faire un cluster géographique ou un standby cluster.
De ce fait, pour l’architecte du système de messagerie, il devient difficile de savoir quelle sera la meilleure implémentation pour son entreprise ou son client. Avec Exchange 2010, on oublie tout cela. Vous voulez la haute disponibilité de votre messagerie, que ce soit sur un site physique unique ou distant : alors ce sera du DAG et rien d’autre, DAG comme Database Availablility Group.
Rien qu’à la lecture de la signification de DAG, un mot a dû vous mettre sur la voie de cette nouvelle fonction : une disponibilité au niveau de la base de données et non plus au niveau du serveur. Avant de rentrer dans la description du DAG, remarquons que le cluster historique d’Exchange disparaît : le SCC. A partir d’Exchange 2010, il ne sera plus possible de construire un cluster basé sur un accès à des disques visibles d’un ensemble de serveurs Exchange.
La conséquence directe de cette disparition est que si vous voulez mettre en place un système Exchange hautement disponible, il faudra au minimum disposer de deux copies des données, comme c’est actuellement le cas du CCR d’Exchange 2007. Ce qui signifie qu’il faudra disposer de deux fois plus d’espace disque, d’où le changement de technologie de stockage dont nous avons parlé précédemment pour en diminuer le coût. L’autre disparition concerne le LCR qui est principalement due au fait que cette fonction a été très peu utilisée.
Certaines entreprises ont utilisé le LCR car il permet d’avoir une redondance des données sans avoir à installer quatre serveurs car c’est le prix d’entrée si l’on souhaite un système complet hautement disponible : deux serveurs de bases de données et deux serveurs HUB + CAS car ces rôles ne peuvent coexister sur un cluster SCC ou CCR, mais nous allons voir que ceci a évolué. Reste donc le CCR et le SCR. Certains vous diront que le DAG est une fusion du CCR et du SCR.
Bien que ce ne soit pas inexact, c’est un raccourci rapide. Disons que le DAG est basé sur le même principe que le CCR et le SCR, à savoir, la réplication des fichiers de Logs, mais la comparaison s’arrête là. Pour commencer, voici la définition d’un DAG : c’est un groupe de serveurs Exchange 2010 hébergeant des bases de données qui peuvent êtres répliquées entre chacun des serveurs membres du DAG.
Un DAG peut être composé de 16 serveurs. 16 serveurs, c’est la limite du nombre de noeuds dans un cluster Windows 2008. En effet, la fonction de DAG s’appuie sur la couche cluster de Windows, mais lorsque vous montez un DAG, vous n’avez rien à faire au niveau de la couche cluster ; tout est automatiquement configuré par Exchange.
Vous aurez par exemple, besoin d’un partage sur un serveur pour monter un FSW (File Share Witness), composant nécessaire à la gestion du quorum d’un cluster, mais la création et le partage du FSW seront effectués par Exchange lors de l’ajout des serveurs dans le DAG.
L’avantage du fait qu’Exchange 2010 se charge de toute la configuration du cluster réside dans le fait que vous n’avez pas à vous préoccuper de cette partie lors de l’installation d’Exchange. En effet, que vous souhaitiez installer une infrastructure Exchange hautement disponible ou non, l’installation d’Exchange sera identique à l’installation d’un serveur autonome.
Téléchargez cette ressource
Guide inmac wstore pour l’équipement IT de l’entreprise
Découvrez les dernières tendances et solutions IT autour des univers de Poste de travail, Affichage et Collaboration, Impression et Infrastructure, et notre dossier Green IT sur les actions engagés par inmac wstore pour réduire son impact environnemental
