Déploiements de grande disponibilité

S’applique à : Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007

Dernière rubrique modifiée : 2008-01-17

Un des thèmes de développement principal pour la haute disponibilité dans Microsoft Exchange Server 2007 étaient de comparer les pratiques de haute disponibilité et les options de configuration présentes dans des versions précédentes d'Exchange Server. En suivant un processus de planification structuré avec Exchange 2007, vous pourrez peut-être diminuer les coûts de fonctionnement et de déploiement, tout en offrant plus de services aux utilisateurs finaux.

Les solutions haute disponibilité dans Exchange Server 2003 ont été correctement déployées dans des environnements de production par Microsoft et de nombreux clients pour fournir un environnement de messagerie haute disponibilité. En outre, de nombreux clients ont correctement déployé une technologie de réplication partenaire et ont créé des solutions basculant des données vers une deuxième copie lorsqu'une défaillance se produit. Exchange 2007 apporte des améliorations aux solutions haute disponibilité d'Exchange 2003, ainsi que de nouvelles fonctionnalités haute disponibilité qui éliminent le recours à des technologies de réplication tierces et réduisent les coûts et la complexité de la solution globale. Des améliorations ont été apportées notamment grâce aux commentaires des utilisateurs ayant indiqué que :

• Les exigences de stockage partagé pour la solution ont augmenté les coûts, ainsi que sa complexité. Par exemple, le matériel pour la solution entière devait être sélectionné à partir de la catégorie Solution de cluster du catalogue Windows Server des produits testés. Dans Exchange 2007, les clusters à copie unique (SCC) ont les mêmes exigences, contrairement aux serveurs de boîtes aux lettres en cluster configurés dans un environnement de réplication continue (CCR).

• L'utilisation d'une copie unique des données de la boîtes aux lettres signifiait que des défaillances de cette copie ou son stockage étaient perturbants, et provoquait souvent des interruptions prolongées et parfois des pertes de données.

• Un manque d'intégration de gestion et d'installation entre le service de clusters et Exchange Server obligeait les administrateurs Exchange à comprendre les concepts de clusters et leurs fonctionnalités. Cela représentait une courbe d'apprentissage importante pour certains administrateurs Exchange.

• Les paramètres de configuration par défaut prêts à l’emploi n'étaient pas configurés pour des comportements de récupération optimaux. Les administrateurs devaient configurer manuellement les ressources de clusters et les paramètres de clusters par défaut pour répondre aux recommandations relatives aux meilleures pratiques.

• Tous les services Exchange (accès au client, transport et stockage) étaient gérés à l'aide de la même stratégie de disponibilité, même si, d'un point de vue architectural, il existait des différences majeures, notamment des stratégies haute disponibilité différentes.

• Certains clients devaient recourir à des technologies partenaires pour que la solution puisse gérer deux copies de leurs boîtes de données. Ces solutions augmentaient les coûts et la complexité du déploiement.

Les solutions haute disponibilité dans Exchange 2007 sont conçues pour répondre à toutes les insuffisances de l'approche haute disponibilité Exchange 2003. Exchange 2007 répond à ces insuffisances par des modifications de l'architecture, la prise en charge de nouvelles configurations, une modification des modèles de gestion et l'ajout de nouvelles approches relatives à la haute disponibilité. Le résultat est une solution flexible qui permet à chaque organisation de choisir une solution en fonction de ses besoins.

Options de déploiement haute disponibilité

La haute disponibilité doit être conçue aussi bien au niveau du composant individuel que dans le contexte d'une solution ou d'un système complet. Généralement, il existe deux types d'options de déploiement de haute disponibilité pour Exchange 2007:

• Le déploiement d'un seule centre de données avec une redondance permettant de récupérer automatiquement de certaines défaillances résultant d'une courte interruption. En cas de défaillance du site, une solution basée sur un unique centre de données unique compte sur des procédures de récupération d'urgence pour revenir à un état opérationnel.

• Le déploiement de plusieurs centres de données avec une redondance permettant de récupérer automatiquement de la plupart des défaillances individuelles. Une solution basée sur plusieurs centres de données permet à l'organisation de se remettre d'une défaillance de la base de données sans recourrir à des procédures de récupération d'urgence. Les défaillances non récupérables, telles qu'une défaillance totale du site, nécessitent une intervention de récupération manuelle.

Ces deux options de déploiement sont décrites plus en détail ci-après dans cette rubrique.

Configurations d'un centre de données unique

Les configurations basées sur un seul centre de données pour la messagerie unifiée, le transport Hub, l'accès au client et les rôles serveur de transport Edge requièrent des serveurs redondants configurés à l'identique. Pour les serveurs de boîtes aux lettres, il existe trois configurations haute disponibilité fournissant une disponibilité du service et des données dans un unique centre de données. SCC, CCR et la réplication continue locale (LCR). La figure suivante présente un déploiement général pour une configuration totalement redondante basée sur un centre de données unique.

Configuration totalement redondante basée sur un unique centre de données

Dans la figure précédente, la configuration de redondance pour le rôle serveur de boîtes aux lettres est abstraite. En effet, une organisation a à sa disposition plusieurs options, notamment une grande variété de configurations utilisant SCC et CCR.

Clusters à copie unique

La configuration de cluster de stockage dans Exchange 2007 est appelée cluster à copie unique (SCC). Un SCC utilise le service de clusters et le stockage partagé pour héberger un serveur de boîtes aux lettres en cluster. Un serveur de boîtes aux lettres en cluster est un ordinateur logique qui se déplace entre des noeuds physiques au cours de sa durée de vie. Cela est possible grâce à la capacité du service de clusters à créer et gérer une identité réseau flottante. L'identité réseau flottante est utilisée comme identité réseau du serveur de boîtes aux lettres en cluster. Le programme d'installation d'Exchange crée automatiquement cette identité réseau à l'aide du nom d'hôte et de l'adresse IP fournis par l'administrateur. L'identité réseau flottante se déplace entre les noeuds du cluster en fonction de la disponibilité du noeud et des besoins de maintenance. Ces mécanismes permettent à l'administrateur d'accéder aux données de leur boîte aux lettres si le stockage est disponible et au moins un des deux noeuds est opérationnel. Pour s'assurer que la récupération après défaillance fonctionne, Exchange et le service de clusters interagissent pour mettre le serveur de boîtes aux lettres en ligne sur un noeud disponible après une défaillance.

Vous trouverez ci-après des informations sur les améliorations clés apportées dans Exchange 2007 aux clusters de stockage partagé présents dans des versions antérieures d'Exchange Server :

• Seul le rôle serveur de boîtes aux lettres prend en charge les clusters et peut être installé dans un cluster avec basculement.

• Le comportement de basculement prêt à l'emploi a été optimisé pour basculer uniquement lorsqu'il existe une forte probabilité pour qu'un basculement améliore la disponibilité. Seule une défaillance totale du noeud ou son incapacité à communiquer avec des clients peut provoquer un basculement.

• La plupart de l'administration a été déplacée de l'Administrateur de clusters vers les outils Exchange, tels que l'environnement de ligne de commande Exchange Management Shell. Cela réduit la courbe d'apprentissage des administrateurs SCC.

• L'installation des serveurs de boîtes aux lettres en cluster a été intégrée dans le programme d'installation, offrant les mêmes possibilités qu'une installation autonome.

La figure suivante présente une configuration typique pour un SCC. Un SCC prend en charge des clusters possédant jusqu'à 8 nœuds, dont un noeud passif.

Figure 2  Architecture de base d'un cluster à copie unique

Dans la figure précédente, les deux noeuds étaient associés dans un cluster de basculement. Un disque partagé est utilisé par le cluster pour gérer la ressource de quorum de cluster représentée par le quorum de disque. Le noeud actif détient actuellement les ressources de disque hébergeant les fichiers journaux et de bases de données du serveur de boîtes aux lettres en cluster. Cette propriété est illustrée par les lignes bleues du noeud actif aux disques. Dans cette configuration, les disques sont accessibles par le noeud actif mais pas simultanément par le noeud passif.

Les noeuds actifs et passifs sont connectés par deux réseaux minimum (privé et mixte). Seul un des deux réseaux est utilisé par les communications clientes (réseau mixte). Le service de clusters vérifie régulièrement l’intégrité des communications entre les réseaux.

Pour plus d'informations sur SCC, consultez la rubrique Clusters à copie unique.

Réplication continue en cluster

Comme son nom l’indique, un cluster à copie unique contient une seule copie des données de boîte aux lettres. La défaillance d’un stockage hébergeant les données de boîte aux lettres ne déclenche pas automatiquement une récupération. En fait, une telle défaillance déclenche en général une perte de données et une interruption étendues. Les améliorations apportées au SCC par rapport aux solutions de cluster antérieures répondent à la plupart des commentaires émis par les clients sur les solutions haute disponibilité antérieures. Toutefois, SCC conserve la complexité inhérente à l’utilisation du stockage partagé. Il dispose au minimum de deux points uniques de défaillance : le disque quorum unique et la copie unique des données Exchange. Dans Exchange 2007, il existe un deuxième type de configuration haute disponibilité qui fournit une redondance complète sans recourir au matériel de la catégorie Solution de cluster du catalogue Windows Server des produits testés. Cette solution est appelée réplication continue en cluster (CCR).

CCR utilise l’envoi asynchrone de journaux intégré pour répliquer les données de boîtes aux lettres entre deux serveurs dans un cluster de basculement. L’intégration des clusters et de la réplication fournit une solution sans point de défaillance et une récupération automatique des défaillances du serveur. En outre, elle élimine la nécessité de disposer d’un stockage partagé, réduisant ainsi les coûts et la complexité du déploiement. CCR ne prend en charge que les clusters à deux noeuds et deux copies des données (la copie active et la copie passive). La figure suivante présente un environnement de CCR typique.

Déploiement de base de la réplication continue en cluster

Deux modifications majeures illustrées dans la figure précédente sont le manque de disque quorum partagé et la présence d’un partage de fichiers sur un ordinateur tiers hors du cluster. Le partage de fichiers fait partie de nouvelles fonctionnalités de quorum de clusters introduites avec la mise à jour décrite dans l'article 921181 de la Base de connaissances Microsoft relatif à la mise à jour disponible qui permet ajoute la fonctionnalité de témoin de partage de fichiers et de pulsations de cluster configurable aux clusters de serveurs Windows Server 2003 Service Pack 1. La mise à jour permet au service de cluster d’utiliser une ressource de quorum utilisant un partage de fichiers plutôt qu’un noeud votant dans le cluster. Sans la mise à jour, les seules options de quorum disponibles sont l’utilisation d’une configuration de disque partagé ou de jeu de noeud majoritaire traditionnel, les deux ayant des inconvénients et augmentant les coûts :

• L’utilisation d’un disque partagé signifie le retour à une solution complexe en raison du stockage partagé.

• Les quorums jeu de noeud majoritaire requièrent trois noeuds au minimum. Dans cette configuration, un noeud supplémentaire ou noeud votant est requis pour agir en tant que noeud votant dans le cluster.

Pour plus d'informations sur la CCR, consultez la rubrique Réplication continue en cluster.

Réplication continue locale

CCR fournit une redondance complète des services et des données et SCC fournit une redondance des services. Pour les organisations requérant une redondance de données sans redondance de service, il existe la réplication continue locale (LCR). LCR n’est pas une solution de clusters et ne fournit donc pas de disponibilité du service. La figure suivante présente un environnement de LCR typique.

Déploiement de base de la réplication continue locale

LCR utilise la technologie de réplication continue intégrée décrite dans la section précédente relative aux CCR pour créer une deuxième copie (ou copie passive) d’un groupe de stockage sur l’ordinateur local. L’ordinateur doit être un serveur de boîtes aux lettres autonome. Dans un environnement LCR, l’administrateur décide quels groupes de stockage ont une copie passive et configure un deuxième emplacement pour la copie passive sur le même serveur.

Lorsqu’il utilise LCR, l’administrateur doit explicitement définir quels groupes de stockage ont des copies passives. Les administrateurs peuvent décider de créer une copie passive d’un groupe de stockage existant, ou activer LCR pour un nouveau groupe de stockage au cours du processus de création. L’administrateur doit configurer un deuxième emplacement pour les fichiers journaux et de bases de données pour les groupes de stockage pour lesquels LCR est activé.

Dans LCR, l'activation de la deuxième copie est manuelle. Il n’y a aucun basculement dans LCR car le basculement est une opération de clusters et LCR n’est pas une solution en cluster. L’administrateur doit décider à quel moment la copie active n’est plus viable, puis activer manuellement la copie passive, qui devient alors la nouvelle copie active. Le processus d’activation de la copie passive est simple et rapide.

À tout moment, un administrateur peut décider d’activer LCR et de créer une copie passive d’une base de données existante, ou d’activer immédiatement LCR lors de la création d’une nouvelle base de données. Après l’activation de LCR, une copie de base est créée à l’aide d’un processus appelé amorçage, puis la réplication (envoi de journaux) est lancée. Une meilleure pratique consiste à placer la copie passive sur des disques ou une délimitation de stockage isolés de la copie active. Cette pratique réduit la probabilité de défaillances simultanées multiples. LCR a un impact de ressource sur le serveur de boîtes aux lettres en cluster. Le serveur de boîtes aux lettres exécute tous les processus associés à la réplication continue, et la planification de la capacité pour le serveur doit être pris en compte. La charge d'entrée/sortie (E/S) sur la copie active est limitée car la plupart de l’activité d’E/S pour le noeud passif est associée aux fichiers journaux et de bases de données de la copie passive.

LCR prend en charge les sauvegardes de la copie passive à l’aide du Service VSS (Volume Shadow Copy Service) Exchange. Lorsque les volumes de disque contenant la copie active sont séparés de manière appropriée de la copie passive, les sauvegardes VSS basées sur le matériel sont une bonne option. Les sauvegardes de copie passive décharge l’E/S de sauvegarde des volumes de disque de la copie active. La copie passive ne requérant pas de réponse en temps réel au client, elle peut tenir compte des coûts associés à l’utilisation d’un enregistreur VSS basé sur le logiciel. En outre, en fonction de votre planification de capacité, il peut être pratique d’étendre la fenêtre de sauvegarde sur le serveur avec LRC. Le facteur clé est de répondre à la charge d’UC de l’agent de sauvegarde via la fenêtre de sauvegarde.

La copie passive représente la première ligne de défense contre les endommagements et les défaillances de données. Avec LCR, il se peut que la récupération suite à la première défaillance dispose d'un contrat SLA relativement court. Une double défaillance requiert une restauration à partir de la sauvegarde. Avec ce modèle, un contrat SLA pour une double défaillance peut être beaucoup plus long. Il est donc recommandé de recourir à une stratégie de sauvegardes complètes hebdomadaires et des sauvegardes incrémentielles quotidiennes. Cette stratégie réduit également le contenu total déplacé vers le support de sauvegarde.

En résumé, la LCR est une option excellente pour les organisations qui doivent disposer d'une solution de récupération rapide à la suite d'une défaillance ou d'un endommagement de données mais qui peuvent tolérer des interruptions de serveur pour des raisons programmées ou non programmées. Les avantages de la LCR sont les suivants :

• récupération rapide, en deux étapes, suite à un endommagement ou une défaillance d'une base de données active ;

• sélectivité des administrateurs, afin de protéger les utilisateurs qui en ont le plus besoin ;

• disponibilité du serveur de boîtes aux lettres, peu importe sa taille, et de tous les produits ;

• impact minimal sur la base de données active et les E/S de journal ;

• capacité à décharger les E/S de sauvegarde de la base de données active et des volumes de journal ;

• possibilité de réduire la quantité totale de données déplacées vers un support de sauvegarde, lors de l'extension de la fenêtre de sauvegarde ;

• Abstraction de l’administration au niveau d’Exchange via l’utilisation de la console de gestion Exchange ou l’environnement de ligne de commande Exchange Management Shell.

Pour plus d'informations sur la LCR, consultez la rubrique Réplication locale en continu.