Partager via

Présentation de la haute disponibilité et de la résilience de site

  • Article

 

S’applique à : Exchange Server 2010 SP2, Exchange Server 2010 SP3

Dernière rubrique modifiée : 2016-11-28

Les bases de données de boîtes aux lettres, ainsi que les données qu’elles contiennent, sont l’un des composants les plus importants (si ce n’est le plus important) de toute organisation Exchange. Dans Microsoft Exchange Server 2010, vous pouvez protéger les bases de données de boîtes aux lettres et les données qu’elles contiennent en configurant vos bases de données de boîtes aux lettres pour la haute disponibilité et la résilience de site. Exchange 2010 réduit les coûts et la complexité du déploiement d’une solution de messagerie à haute disponibilité et résilience de site, tout en fournissant des niveaux de disponibilité de bout en bout élevés et en prenant en charge les boîtes aux lettres volumineuses. En s’appuyant sur les capacités de réplication native introduites dans Exchange Server 2007, la nouvelle architecture à haut niveau de disponibilité d’Exchange 2010 fournit un cadre d’applications simplifié et unifié à la haute disponibilité et à la résilience de site. Exchange 2010 intègre une haute disponibilité dans l’architecture principale d’Exchange pour permettre aux clients de toutes tailles et de tous segments de déployer économiquement un service de messagerie en continu dans leur organisation.

Souhaitez-vous rechercher des tâches de gestion liées à la haute disponibilité et la résilience de site ? Consultez la rubrique Gestion de la haute disponibilité et de la résilience de site.

Contenu de cette rubrique

Terminologie clé

Caractéristiques clés de la solution Exchange Server 2010

Mobilité de la base de données

Déploiement incrémentiel

Groupes de disponibilité de base de données

Copies de bases de données de boîtes aux lettres

Active Manager

Modifications apportées à la haute disponibilité par rapport aux versions antérieures d’Exchange

Haute disponibilité pour des rôles serveur autre que le rôle serveur de boîtes aux lettres

Résilience de site

Disponibilité de bout en bout

Terminologie clé

Les termes suivants s’appliquent :

  • Service de carnet d’adresses
    Service disponible sur le serveur d’accès au client, qui fournit un point de terminaison d’accès à l’annuaire pour les clients Microsoft Outlook.
  • Mode Réplication continue - blocage
    Nouveau mode de réplication continue du SP1 selon lequel toute mise à jour écrite vers le tampon journal actif de la copie de base de données active est également envoyée vers un tampon journal sur chacune des copies de boîtes aux lettres passives. Lorsque le tampon journal est plein, chaque copie de base de données génère, inspecte et crée le fichier journal suivant de la séquence de génération.
  • Mode Réplication continue - fichier
    Nom du mode de réplication continue d’origine de la version de publication (RTM) d’Exchange 2010, selon lequel les fichiers journaux de transactions fermés sont acheminés de la copie de base de données active vers une ou plusieurs copies de bases de données passives.
  • Groupe de disponibilité de base de données (DAG)
    Groupe de 16 serveurs de boîtes aux lettres Exchange 2010 qui héberge un ensemble de bases de données répliquées.
  • Mobilité de la base de données
    Possibilité qu’une base de données de boîtes aux lettres individuelle Exchange 2010 soit répliquée et montée sur d’autres serveurs de boîtes aux lettres Exchange 2010.
  • Récupération d’urgence
    Tout processus utilisé pour récupérer manuellement suite à une défaillance. Il peut s’agir d’une défaillance qui affecte un seul élément ou un emplacement physique complet.
  • API de réplication tierce Exchange
    API fournie par Exchange qui permet d’utiliser une réplication synchrone tierce pour un groupe de disponibilité de base de données au lieu de la réplication continue.
  • Disponibilité élevée
    Solution qui fournit la disponibilité du service et des données et qui récupère automatiquement suite à des défaillances affectant le service ou les données (telle qu’une défaillance du réseau, de stockage ou du serveur).
  • Déploiement incrémentiel
    Possibilité de déployer la haute disponibilité et la résilience de site après l’installation d’Exchange 2010.
  • Copie retardée de la base de données de boîtes aux lettres
    Copie d’une base de données de boîtes aux lettres dont le retard de relecture du journal est supérieur à zéro.
  • Copie de base de données de boîtes aux lettres
    Base de données de boîtes aux lettres (fichier .edb et journaux) active ou passive.
  • Résilience de boîte aux lettres
    Nom d’une solution unifiée à haute disponibilité et de résilience de site dans Exchange 2010.
  • Service d’accès au client RPC
    Service disponible sur le serveur d’accès au client, qui fournit un point de terminaison MAPI pour les clients Microsoft Outlook.
  • Résilience de site
    Processus manuel de récupération d’urgence utilisé pour activer un centre de données supplémentaire ou de secours lorsque le centre de données principal n’est plus en mesure d’offrir un niveau de service suffisant pour répondre aux besoins de l’organisation. Inclut également le processus de réactivation d’un centre de données principal qui a été récupéré, restauré ou recréé. Vous pouvez configurer votre solution de messagerie pour la haute disponibilité et activer la résilience de site à l’aide des fonctions intégrées et de la fonctionnalité dans Exchange 2010.
  • Redondance des clichés instantanés
    Fonctionnalité du serveur de transport qui fournit la redondance des messages pendant toute la durée de leur transit.
  • *over (prononcé « étoile-over »)
    Abréviation de switchovers et de failovers (basculements). Un switchover est une activation manuelle d’une ou de plusieurs copies de bases de données. Un failover est une activation automatique d’une ou de plusieurs copies de bases de données.

Retour au début

Caractéristiques clés de la solution Exchange Server 2010

Exchange 2007 a réduit le coût de la haute disponibilité et a rendu la résilience de site bien plus abordable grâce à l’introduction de nouvelles technologies telles que la réplication continue en cluster (CCR) et la réplication continue de secours (SCR). Cependant, certains défis restaient à relever :

  • Le clustering avec basculement Windows pouvait s’avérer perturbant en raison de sa complexité.

  • L’obtention d’un niveau élevé de temps disponible pouvait demander un niveau d’intervention élevé de l’administrateur.

  • Chaque type de réplication continue était géré différemment et séparément.

  • La récupération consécutive à la défaillance d’une seule base de données sur un serveur de boîtes aux lettres de grande taille pouvait entraîner une interruption de service temporaire pour tous les utilisateurs du serveur de boîtes aux lettres.

  • La fonction de conteneur de dépôt de transport du serveur de transport Hub assurait seulement la protection des messages destinés à des boîtes aux lettres placées dans un environnement de réplication en cluster. La défaillance d’un serveur de transport Hub pendant le traitement des messages, sans récupération possible, pouvait aboutir à une perte de données.

Exchange 2010 inclut des changements structurels majeurs qui intègrent la haute disponibilité dans l’architecture, pour un coût encore plus réduit et une facilité de déploiement et de maintenance plus grande que les versions précédentes d’Exchange. Exchange 2010 inclut une nouvelle plateforme unifiée pour la haute disponibilité et la résilience de site.

Grâce aux améliorations structurelles majeures apportées à Exchange 2010, la taille maximale recommandée de la base de données de boîtes aux lettres lors de l’utilisation de la réplication continue est passée de 200 gigaoctets (Go) dans Exchange 2007 à 2 téraoctets (To) dans Exchange 2010. Du fait que de plus en plus d’entreprises se rendent compte de la valeur ajoutée apportée par les boîtes aux lettres volumineuses (de 2 Go à 10 Go), il n’y a qu’un pas avant que les tailles des bases de données considérablement plus volumineuses ne deviennent réalité. La prise en charge de bases de données plus imposantes entraîne l’abandon des mécanismes de récupération hérités, tels que la sauvegarde et la restauration, au profit de nouvelles formes de protection plus rapides, telles que la réplication de données et la redondance de serveur. Finalement, la taille de vos bases de données de boîtes aux lettres dépend de multiples facteurs que vous déterminez au cours du processus de planification d’Exchange 2010. Pour obtenir des instructions détaillées sur la planification de boîtes aux lettres et de serveurs de boîtes aux lettres, voir Conception du stockage de serveur de boîtes aux lettres.

Exchange 2010 comporte des fonctionnalités essentielles de disponibilité et de résilience des réplications continues locale et en cluster dans une solution unique qui est en mesure de gérer la réplication des données à la fois sur site et hors site. Les serveurs de boîtes aux lettres peuvent être définis comme faisant partie d’un groupe de disponibilité de base de données afin que la récupération automatique se fasse au niveau de la base de données de boîtes aux lettres et non pas du serveur. D’autres nouveaux concepts de haute disponibilité ont été introduits dans Exchange 2010, par exemple, la mobilité de base de données et le déploiement incrémentiel.

Retour au début

Mobilité de la base de données

Exchange 2007 a introduit de nombreux changements d’architecture qui étaient destinés à déployer des solutions de haute disponibilité et de résilience de site pour Exchange plus rapidement et plus facilement. Ces améliorations incluaient un programme d’installation intégré, des paramètres de configuration optimisés et une capacité de gestion de la plupart des aspects de la solution de haute disponibilité à l’aide d’outils de gestion Exchange natifs.

Cependant, la gestion d’une solution de haute disponibilité Exchange 2007 exigeait certains concepts de clustering, par exemple le déplacement d’identités de réseau et la gestion des ressources de cluster. Par ailleurs, lorsque des problèmes de dépannage concernaient un serveur de boîtes aux lettres en cluster, les outils Exchange et les outils de clustering devaient être utilisés pour examiner et corréler les journaux et les événements à partir de deux sources différentes : depuis Exchange d’une part, et depuis le cluster, d’autre part.

Deux autres aspects restrictifs de l’architecture Exchange 2007 ont également été réévalués et révisés sur la base des commentaires des clients :

  • Les serveurs Exchange 2007 en cluster nécessitent un matériel dédié. Seul le rôle serveur de boîtes aux lettres pouvait être installé sur un nœud du cluster. Cela signifiait qu’il fallait au minimum quatre serveurs Exchange pour obtenir une redondance totale des composants principaux d’un déploiement, par exemple les rôles serveur principaux (boîte aux lettres, transport Hub et accès au client).

  • Dans Exchange 2007, le basculement d’un serveur de boîtes aux lettres en cluster se produit au niveau du serveur. Par conséquent, en cas de défaillance d’une seule base de données, l’administrateur devait basculer la totalité du serveur de boîtes aux lettres en cluster sur un autre nœud du cluster (entraînant une brève interruption de service pour la totalité des utilisateurs du serveur, et non pas seulement pour les utilisateurs disposant d’une boîte aux lettres sur la base de données affectée) ou l’administrateur devait laisser les utilisateurs hors connexion sur la base de données basculée (potentiellement pendant des heures) pendant la restauration de la base de données à partir de sa sauvegarde.

Exchange 2010 a été conçu autour du concept de mobilité de base de données qui élargit l’utilisation de la réplication continue par le système en permettant la réplication d’une base de données dans plusieurs serveurs différents regroupés. Ce modèle permet que la base de données soit ainsi mieux protégée et sa disponibilité accrue. Dans ce modèle, la protection par basculement automatique et le contrôle par basculement manuel est fournie au niveau de la base de données de boîtes aux lettres au lieu du serveur.

En cas de défaillance, les autres serveurs disposant de copies de cette base de données peuvent la monter. Grâce à cette mobilité et à d’autres changements dans l’architecture, les actions de basculement sont désormais réalisées plus rapidement qu’elles ne l’étaient avec les versions antérieures d’Exchange. Par exemple, il faut environ 2 minutes pour réaliser le basculement d'un serveur de boîtes aux lettres en cluster dans un environnement de réplication continue en cluster fonctionnant avec Exchange 2007 Service Pack 1 (en supposant une défaillance intra-site où l'adresse IP du serveur de boîtes aux lettres en cluster ne change pas). Par comparaison, le basculement d’une base de données de boîtes aux lettres dans un environnement Exchange 2010 prend 30 secondes (intervalle de temps mesuré entre le moment où la défaillance est détectée et le moment où la base de données est montée, sous réserve de copie intègre et à jour avec relecture des journaux). Cette combinaison de basculement au niveau des bases de données et d'accélération significative du temps de basculement permet d'améliorer le temps disponible d'une organisation.

Retour au début

Déploiement incrémentiel

Exchange 2010 introduit le concept de déploiement incrémentiel qui vous permet de déployer la disponibilité de services et de données sur l’ensemble de vos serveurs de boîtes de lettres et de vos bases de données après l’installation d’Exchange. La redondance des services et des données est obtenue en utilisant les nouvelles fonctionnalités d’Exchange 2010, comme les groupes de disponibilité des bases de données et les copies de base de données.

Dans les versions antérieures d’Exchange, la disponibilité de service pour les rôles serveur de boîte aux lettres était obtenue en déployant Exchange dans un cluster de basculement Windows. Pour déployer Exchange dans un cluster, il fallait commencer par créer un cluster de basculement, puis installer les fichiers du programme Exchange. Ce processus créait un serveur de boîtes aux lettres spécial, appelé serveur de boîtes aux lettres en cluster (ou encore serveur virtuel Exchange dans les versions précédentes d’Exchange). Si vous aviez déjà installé les fichiers du programme Exchange sur un serveur non configuré en cluster et souhaitiez avoir un serveur de boîtes aux lettres en cluster, vous deviez créer un cluster avec une nouvelle configuration matérielle ou supprimer Exchange sur le serveur existant, puis installer le clustering de basculement et réinstaller Exchange.

Retour au début

Groupes de disponibilité de base de données

Un groupe de disponibilité de base de données est le composant de base de l’architecture de haute disponibilité et de résilience de site intégrée à Exchange 2010. Un groupe de disponibilité des bases de données est un groupe formé d’un maximum de 16 serveurs de boîtes aux lettres qui hébergent un ensemble de bases de données et assurent une récupération automatique au niveau de la base de données à la suite de défaillances affectant des bases de données individuelles. N’importe quel serveur d’un groupe de disponibilité de base de données peut héberger une copie de base de données de boîtes aux lettres provenant d’un serveur quelconque du groupe de disponibilité de base de données. Lorsqu’un serveur est ajouté à un groupe de disponibilité de base de données, il fonctionne avec les autres serveurs du groupe pour assurer la récupération automatique à la suite de défaillances affectant des bases de données de boîtes aux lettres, par exemple la défaillance d’un disque ou d’un serveur.

Exchange 2007 a introduit une technologie de réplication de données intégrée appelée réplication continue. La réplication continue est disponible sous trois formes : locale, en cluster et de secours, ce qui a réduit de manière significative le coût de déploiement d’une infrastructure Exchange à disponibilité élevée et assuré un déploiement et une gestion nettement améliorée par rapport aux versions précédentes d’Exchange. Malgré ces économies et ces améliorations, l'exécution d'une infrastructure Exchange 2007 à disponibilité élevée nécessite encore beaucoup de temps et d'expertise du fait que l'intégration du clustering avec basculement entre Exchange et Windows n'était pas transparente. De plus, les clients voulaient une méthode plus simple pour répliquer leurs données de messagerie sur un emplacement distant, afin de protéger leur environnement Exchange contre les incidents au niveau du site.

Exchange 2010 utilise la même technologie de réplication continue existant dans Exchange 2007. Exchange 2010 combine la réplication des données sur site (CCR) et la réplication des données en dehors du site (SCR) dans une architecture unique appelée groupe de disponibilité de base de données. Une fois que les serveurs sont ajoutés au groupe de disponibilité de base de données, vous pouvez ajouter des copies de bases de données répliquées de manière incrémentielle (jusqu’à 16). Exchange 2010 bascule entre ces copies de manière automatique afin de conserver la disponibilité.

Contrairement à Exchange 2007, où les serveurs de boîtes aux lettres en cluster nécessitent un matériel dédié, les serveurs de boîtes aux lettres dans un groupe de disponibilité de base de données peuvent héberger d’autres rôles Exchange (accès au client, transport Hub et messagerie unifiée), offrant ainsi une redondance complète des services et données d’Exchange avec seulement deux serveurs.

La nouvelle architecture à disponibilité élevée fournit également une récupération simplifiée depuis une variété de défaillances (au niveau du disque, du serveur et du centre de données) et peut être déployée sur plusieurs types de stockages.

Pour plus d’informations sur les groupes de disponibilité de base de données, consultez la rubrique Présentation des groupes de disponibilité de base de données.

Retour au début

Copies de bases de données de boîtes aux lettres

Les fonctionnalités de haute disponibilité et de résilience de site, introduites pour la première fois dans Exchange 2007, sont utilisées dans Exchange 2010 pour créer et gérer des copies de base de données afin que vous puissiez atteindre vos objectifs de disponibilité dans Exchange 2010. Exchange 2010 introduit également le concept de mobilité de base de données, qui consiste en basculements au niveau base de données gérés par Exchange.

La mobilité de base de données permet de déconnecter des bases de données de leurs serveurs, de prendre en charge jusqu’à 16 copies d’une base de données individuelle et de fournir une expérience native pour l’ajout de copies de bases de données à une base de données. Dans Exchange 2007, la fonctionnalité de portabilité de base de données vous permettait également de déplacer une base de données de boîtes aux lettres entre les serveurs. Par rapport à la portabilité de base de données, la mobilité de base de données présente la différence essentielle d’attribuer le même GUID à toutes les copies d’une base de données.

La définition d’une copie de base de données en tant que base de données de boîtes aux lettres active est appelée également switchover (basculement). Quand une défaillance affectant une base de données se produit et qu’une nouvelle base de données devient la copie active, ce processus est appelé failover (basculement). Ce processus fait également référence à une défaillance du serveur dans laquelle un ou plusieurs serveurs mettent en ligne les bases de données précédemment en ligne sur le serveur défaillant. Lorsqu’un switchover ou un basculement se produit, d’autres rôles serveur Exchange 2010 en sont informés presque immédiatement et redirigent le trafic client et de messagerie vers la nouvelle base de données active.

Par exemple, si une base de données active dans un groupe de disponibilité de base de données échoue en raison d’une défaillance de stockage sous-jacente, Active Manager procédera à une récupération automatique en basculant une copie de base de données sur un autre serveur de boîtes aux lettres dans le groupe de disponibilité de base de données. Si la base de données se trouve en dehors des critères de montage et ne peut pas être montée automatiquement, vous pouvez effectuer un basculement de base de données manuellement.

Pour plus d’informations sur les copies de base de données de boîtes aux lettres, consultez la rubrique Présentation des copies de bases de données de boîtes aux lettres.

Retour au début

Active Manager

Dans Exchange 2007 et les versions précédentes, Exchange utilisait le modèle de gestion de ressources en cluster pour installer, implémenter et gérer la solution de serveur de boîtes aux lettres à haute disponibilité. Historiquement, la conception d’une serveur de boîtes aux lettres à disponibilité élevée impliquait au préalable de créer un cluster de basculement Windows, puis d’exécuter le programme d’installation d’Exchange en mode cluster. Dans ce mode, le fichier DLL de ressources de cluster Exchange, exres.dll, était inscrit et autorisait la création d’un serveur de boîtes aux lettres en cluster (appelé Serveur virtuel Exchange dans les versions héritées). Lors du déploiement de clusters de stockage partagé hérités ou de clusters de copie individuels, il était nécessaire d’exécuter d’autres étapes pour configurer le stockage avant et après la formation du cluster de basculement, et après la formation du serveur de boîtes aux lettres en cluster et du groupe de stockage.

Exchange 2010 inclut un nouveau composant appelé Active Manager qui propose une fonctionnalité remplaçant les fonctionnalités de gestion du modèle de ressources et du basculement fournies par l’intégration avec le service de cluster des versions précédentes d’Exchange. Pour plus d’informations sur Active Manager, voir Présentation du gestionnaire Active Manager.

Retour au début

Modifications apportées à la haute disponibilité par rapport aux versions antérieures d’Exchange

Plusieurs changements apportés à l’architecture de base d’Exchange 2010 ont une incidence directe sur la manière dont vous configurez Exchange pour la haute disponibilité, ainsi que sur l’exécution de la récupération de site. L’une des modifications importantes est la suppression des serveurs de boîtes aux lettres en cluster et l’utilisation du modèle de ressources du cluster de basculement Windows. Les autres modifications importantes comprennent la globalisation des bases de données et les améliorations apportées à la technologie de réplication continue intégrée d’abord introduite dans Exchange 2007.

Suppression des serveurs de boîtes aux lettres en cluster

Dans Exchange 2010, Exchange n’est plus une application en cluster et le modèle de ressources en cluster n’est plus utilisé pour la disponibilité élevée d’Exchange. Exres.dll ainsi que les ressources de cluster Exchange qu’il fournissait n’existent plus non plus, y compris les serveurs de boîtes aux lettres en cluster. Au lieu de cela, Exchange 2010 utilise son propre modèle interne de haute disponibilité. Certains composants du clustering de basculement Windows sont toujours utilisés, mais ils sont désormais intégrés dans une autre fonctionnalité par Exchange 2010.

Globalisation des bases de données

Dans Exchange 2010, une base de données est associée à un flux de journaux unique dédié qui est représenté par une série de fichiers journaux de 1 mégaoctet (Mo) nommés de manière séquentielle. Le concept des groupes de stockage a également été supprimé d’Exchange 2010. Par conséquent, les bases de données Exchange disposent d’un flux de journaux dédié et ne partagent plus les flux de journaux avec d’autres bases de données.

Contrairement aux versions précédentes d’Exchange, les liens étroits entre les bases de données et un serveur de boîtes aux lettres spécifique ont été supprimés. En outre, les bases de données ne sont plus identifiées par les serveurs de boîtes aux lettres sur lesquels elles résident, et les noms des serveurs ne font plus partie des identités de bases de données. Par conséquent, les bases de données sont désormais des objets globaux dans Active Directory et dans chaque organisation Exchange. Lors de l’utilisation de la console de gestion Exchange, les bases de données sont désormais gérées à partir du nœud Boîte aux lettres sous le nœud Configuration de l’organisation.

Chaque serveur de boîtes aux lettres peut héberger un maximum de 100 bases de données (nombre total combinant les bases de données actives et passives). Le nombre total de bases de données est égal au nombre combiné de bases de données actives et passives sur un serveur. La base de données de récupération ne compte pas par rapport à la limite de 100 bases de données.

Modifications apportées à la réplication continue dans Exchange 2010 RTM

La technologie de réplication continue introduite dans Exchange 2007 est également disponible dans Exchange 2010. Toutefois, cette fonctionnalité a considérablement évolué. Elle permet aujourd’hui de prendre en charge de nouvelles fonctionnalités de haute disponibilité et présente une meilleure évolutivité. Certaines de ces modifications d’architecture sont répertoriées ci-dessous :

  • Du fait que les groupes de stockage ont été supprimés d’Exchange 2010, la réplication continue s’effectue désormais au niveau de la base de données. Exchange 2010 utilise toujours une base de données ESE (Extensible Storage Engine) qui crée des journaux de transactions répliqués sur un ou plusieurs emplacements et relus dans une ou plusieurs copies de bases de données de boîtes aux lettres. Chaque base de données de boîtes aux lettres peut compter jusqu’à 16 copies.

  • L’envoi de journaux n’utilise plus le protocole SMB (Server Message Block) ni les notifications du système de fichiers Windows. L’envoi de journaux ne se base plus sur un modèle d’extraction de données (pull) où la copie passive extrait un fichier journal fermé de la copie active. Au lieu de cela, la copie passive utilise les notifications TCP pour notifier la copie active des fichiers journaux dont elle a besoin. La copie active envoie ensuite les fichiers journaux à chaque copie passive configurée via le socket TCP.

  • La réplication continue d’Exchange 2010 utilise 1 port TCP défini par l’administrateur pour le transfert de données. Exchange 2010 propose également des options intégrées de chiffrement de réseau et de compression du flux de données.

  • L’amorçage n’est plus limité à l’utilisation exclusive de la copie active de la base de données. Il est maintenant possible de spécifier des copies passives de base de données de boîtes aux lettres comme sources d’amorçage et de réamorçage de copies de base de données.

  • Les copies de bases de données s’appliquent uniquement aux bases de données de boîtes aux lettres. Nous vous recommandons d’utiliser la réplication de dossiers publics pour obtenir des bases de données de dossiers publics redondantes et à haut niveau de disponibilité. Contrairement à la réplication continue en cluster où plusieurs copies d’une base de données de dossiers publics ne pouvaient pas coexister dans un même cluster, vous pouvez utiliser la réplication de dossiers publics pour répliquer des bases de données de dossiers publics entre serveurs d’un groupe de disponibilité de base de données.

  • Dans Exchange 2007, le service de réplication Microsoft Exchange était responsable de la relecture des journaux dans des copies de base de données passives. Lorsque la copie passive était activée, le cache de base de données généré par le service de réplication Microsoft Exchange résultant d’une activité de relecture était perdu quand le service de banque d’informations Microsoft Exchange était monté sur la base de données. Le cache de la base de données était mis dans un état de démarrage. La mémoire cache de la base de données, utilisée pour mettre en cache les opérations de lecture/écriture, est de taille inférieure (vierge) pendant cette période-là. Elle a donc une capacité fortement diminuée pour réduire les opérations d’E/S de lecture. Dans Exchange 2010, la fonctionnalité de relecture de la copie passive effectuée précédemment par le service de réplication d’Microsoft Exchange a été déplacée dans le service de banque d’informations Microsoft Exchange. Par conséquent, un cache de la base de données est présent et quasi opérationnel après qu’un basculement (failover ou switchover) se soit produit.

Plusieurs concepts utilisés dans la réplication continue d’Exchange 2007 sont également conservés dans Exchange 2010, notamment les concepts de gestion du basculement, de divergence, l’utilisation de la numérotation de montage de base de données automatique et des réseaux de réplication et d’accès au client (MAPI).

Modifications apportées à la réplication continue dans Exchange 2010 SP1

Dans la version de publication (RTM) d’Exchange 2010 et dans toutes les versions d’Exchange Server 2007, la réplication continue fonctionne en envoyant des copies des fichiers journaux générés par la copie de base de données active vers les copies de bases de données passives. À partir d’Exchange 2010 SP1, cette forme de réplication continue est appelée Mode Réplication continue - fichier. Le SP1 introduit également un nouveau mode de réplication continue appelé Mode Réplication continue - blocage. En mode blocage, à chaque fois qu’une mise à jour est enregistrée dans le tampon journal actif de la copie de la base de données active, elle est envoyée dans le tampon journal de chacune des copies de base de données de boîte aux lettres passives. Lorsque le tampon journal est plein, chaque copie de base de données génère, inspecte et crée le fichier journal suivant de la séquence de génération. En cas de défaillance de la copie active, les copies passives sont mises à jour avec la plupart sinon l’intégralité des dernières mises à jour. La copie active n’attend pas la fin de la réplication pour empêcher les problèmes de réplication de nuire à l’expérience client.

Le mode blocage réduit considérablement la latence entre le moment où une modification est apportée sur la copie active et le moment où elle est répliquée sur les copies passives. En plus de répliquer les écritures de fichiers journaux individuelles, le mode blocage modifie également le processus d’activation d’une copie passive. Si une copie est en mode blocage au moment d’une défaillance, le système utilise tout contenu de journal partiel disponible durant le processus d’activation. Ainsi, le fichier journal actuel sur la copie active ne peut pas constituer un point de défaillance unique.

Le mode de fonctionnement initial est toujours le mode fichier. Le mode blocage est uniquement actif lorsque la réplication continue est à jour en mode fichier. L’activation et la désactivation du mode blocage sont automatiquement effectuées par le copieur de journaux. Lorsque la copie passive demande le fichier journal actuel, elle indique que la réplication continue est à jour (longueur de file d’attente de copie égale à 0), puis le système doit automatiquement passer du mode fichier au mode blocage.

Vous pouvez déterminer si une copie de base de données passive est en mode blocage en analysant le compteur de performances Mode Réplication continue - blocage Actif sous l’objet de performance Réplication MSExchange. Chaque copie de base de données a sa propre instance de ce compteur. La valeur du compteur est définie sur 1 lorsque la copie passive est en mode blocage et sur 0 lorsqu’elle est en mode fichier. Vous pouvez également déterminer la valeur de ce compteur en utilisant la cmdlet Get-Counter ou Get-WMIObject, comme illustré dans ces exemples :

Get-Counter -ComputerName <DAGMemberName> -Counter "\MSExchange Replication(*)\Continuous replication - block mode Active"
Get-WMIObject -ComputerName <DAGMemberName> Win32_PerfRawData_MSExchangeReplication_MSExchangeReplication | Where-Object {$_.ContinuousReplicationBlockModeActive -eq "1"} | Where-Object {$_.name -ne "_total"} | format-table Name,ContinuousReplicationBlockModeActive

Modifications apportées au conteneur de dépôt de transport depuis Exchange 2007

Le rôle serveur de transport Hub Exchange 2010 inclut une fonctionnalité appelée conteneur de dépôt de transport, introduite en premier dans Exchange 2007. Le conteneur de dépôt de transport est conçu pour se prémunir contre les pertes de données en conservant une file d’attente de tous les messages électroniques récents envoyés aux utilisateurs dont les boîtes aux lettres étaient protégées par la réplication continue en cluster (CCR) ou locale (LCR). Quand une défaillance avec perte se produisait dans l’un ou l’autre de ces environnements, le bloc de données qui aurait d’ordinaire été perdu en raison de la défaillance est récupéré automatiquement par le conteneur de dépôt de transport.

Le conteneur de dépôt de transport est utilisé pour les bases de données de boîtes aux lettres répliquées uniquement. Elle ne protège pas les messages envoyés sur des dossiers publics, pas plus que ceux envoyés aux destinataires de bases de données de boîtes aux lettres non répliquées. La file d’attente du conteneur de dépôt de transport pour une base de données de boîtes aux lettres spécifique se trouve sur tous les serveurs de transport Hub dans les sites Active Directory contenant le groupe de disponibilité de base de données.

Dans Exchange 2007, les messages étaient conservés dans le conteneur de dépôt de transport tant que la limite de temps définie par l’administrateur ou la taille limite n’était pas atteinte. Dans Exchange 2010, le conteneur de dépôt de transport reçoit désormais des commentaires du pipeline de réplication pour déterminer quels messages ont été remis et répliqués. Lorsqu’un message passe par les serveurs de transport Hub pour atteindre une base de données de boîtes aux lettres répliquée dans un groupe de disponibilité de base de données, une copie est conservée dans la file d’attente de transport (mail.que) jusqu’à ce que les journaux de transactions représentant le message aient été correctement répliqués sur (et inspectés par) toutes les copies de la base de données de boîtes aux lettres. Une fois que les journaux ont été répliqués sur (et inspectés par) toutes les copies de bases de données, les messages qu’ils contiennent sont tronqués à partir du conteneur de dépôt. Cela permet de garder une file d'attente du conteneur de dépôt de transport plus petite en conservant uniquement les copies des messages dont les journaux de transactions n'ont pas encore été répliqués.

Le gestionnaire Active Manager de chaque groupe de disponibilité de base de données effectue le suivi de la valeur de la dernière heure d’inspection du journal sur chaque copie de base de données passive. Le client Active Manager s’exécutant sur le serveur de transport Hub obtient cette information du gestionnaire Active Manager de secours (SAM) du groupe de disponibilité de base de données et la convertit en filigrane temporel. Le serveur de transport Hub compare ensuite l’heure de remise des messages dans le conteneur de dépôt de transport au filigrane. Si l’heure de remise d’un message est postérieure au filigrane, alors le message dans le conteneur de dépôt de transport est tronqué.

Le conteneur de dépôt de transport a également été amélioré pour tenir compte des modifications apportées au rôle serveur de boîtes aux lettres qui active une base de données de boîtes aux lettres unique pour se déplacer entre les sites Active Directory. Les groupes de disponibilité de base de données peuvent être étendus sur plusieurs sites Active Directory, par conséquent, une base de données de boîtes aux lettres unique d’un site Active Directory peut basculer sur un autre site Active Directory. Quand cela se produit, toutes les demandes de remise du conteneur de dépôt de transport sont envoyées aux deux sites Active Directory : le site d’origine et le nouveau site.

Changements apportés au comportement de routage lorsque les serveurs de transport Hub et de boîtes aux lettres se trouvent au même endroit dans le groupe de disponibilité de base de données

Lorsque le serveur de transport Hub se trouve au même endroit qu'un serveur de boîtes aux lettres, membre d'un groupe de disponibilité de base de données, des modifications sont apportées au comportement de routage pour garantir que les fonctions de résilience au sein des deux rôles serveur fournissent la protection nécessaire aux messages envoyés et reçus par les utilisateurs sur ce serveur. Le rôle serveur de transport Hub a été modifié pour qu’il tente maintenant de re-router un message, destiné à un serveur local de boîtes aux lettres, vers un autre serveur de transport Hub du même site dans les cas où ce serveur de transport Hub est également membre d’un groupe de disponibilité de base de données et possède une copie de la base de données de boîtes aux lettres montée localement. Ce saut supplémentaire a été ajouté pour déposer le message dans un conteneur de dépôt de transport d’un serveur de transport Hub différent.

Par exemple, EX1 héberge le rôle serveur de transport Hub et de boîtes aux lettres et appartient à un groupe de disponibilité de base de données. Lorsqu’un message est transporté vers EX1 pour un destinataire dont la boîte aux lettres se trouve aussi sur EX1, le serveur de transport va re-router le message vers un autre serveur de transport Hub (par exemple, X2) qui déposera le message dans la boîte aux lettres sur EX1.

Un deuxième changement de comportement similaire a été apporté au service de dépôt de courrier d'Microsoft Exchange. Ce service a été modifié pour qu’il préfère ne pas envoyer de messages à un serveur de transport Hub local si le serveur de boîtes aux lettres et de transport Hub appartient à un groupe de disponibilité de base de données. Dans ce scénario, le comportement de transport consiste à équilibrer la charge des demandes de dépôt entre les serveurs de transport Hub du même site Active Directory et de revenir au serveur de transport Hub local, s’il n’y pas d’autre serveur de transport Hub disponible dans le même site.

Retour au début

Haute disponibilité pour des rôles serveur autre que le rôle serveur de boîtes aux lettres

La disponibilité élevée pour les rôles serveur de transport Hub, de transport Edge, d’accès au client et de messagerie unifiée, est atteinte par une combinaison de redondance de serveur, d’équilibrage de la charge, de tourniquet DNS, ainsi qu’une gestion de serveur, de service et d’infrastructure proactive. En général, vous pouvez obtenir une haute disponibilité pour les rôles serveur d’accès au client, serveur de transport Hub, serveur de transport Edge et serveur de messagerie unifiée à l’aide des stratégies et technologies suivantes :

  • Transport Edge   Vous pouvez déployer plusieurs serveurs de transport Edge et utiliser plusieurs enregistrements DNS MX pour assurer l’équilibrage de la charge sur ces serveurs. Vous pouvez également utiliser l’équilibrage de la charge réseau pour équilibrer la charge et assurer une disponibilité élevée sur les serveurs de transport Edge.

  • Accès au client   Vous pouvez utiliser l’équilibrage de la charge réseau ou un autre périphérique matériel d’équilibrage de charge réseau tiers pour assurer une disponibilité élevée du serveur d’accès au client.

  • Transport Hub   Vous pouvez déployer plusieurs serveurs de transport Hub pour assurer une disponibilité élevée du transport interne. La tolérance de panne a été conçue dans le rôle serveur de transport Hub comme suit :

    • De serveur de transport Hub à serveur de transport Hub (intra-organisation)   La communication de serveur de transport Hub à serveur de transport Hub à l’intérieur d’une organisation équilibre automatiquement la charge entre les serveurs de transport Hub disponibles dans le site Active Directory cible.

    • De serveur de boîtes aux lettres à serveur de transport Hub (intra-site Active Directory)   Le service de dépôt du courrier Microsoft Exchange sur des serveurs de boîtes aux lettres équilibre automatiquement la charge entre tous les serveurs de transport Hub disponibles dans le même site Active Directory.

    • De serveur de messagerie unifiée à serveur de transport Hub   Le serveur de messagerie unifiée équilibre automatiquement la charge des connexions entre tous les serveurs de transport Hub disponibles dans le même site Active Directory.

    • De serveur de transport Edge à serveur de transport Hub   Le serveur de transport Edge équilibre automatiquement la charge du trafic SMTP (Simple Mail Transfer Protocol) entrant sur tous les serveurs de transport Hub dans le site Active Directory auquel le serveur de transport Edge est abonné.

    Pour assurer une redondance supplémentaire (par exemple, d’applications nécessitant un relais SMTP), vous pouvez créer un enregistrement DNS (par exemple, relais.société.com), affecter une adresse IP et utiliser un programme d’équilibrage de la charge matérielle pour rediriger cette adresse IP vers plusieurs serveurs de transport Hub. Vous pouvez également utiliser l’équilibrage de la charge du réseau pour les connecteurs clients sur les serveurs de transport Hub. En cas d’utilisation d’un programme d’équilibrage de la charge matérielle, vous devez vérifier qu’aucun trafic intra-organisation ne croisera le programme d’équilibrage de la charge matérielle car le trafic intra-organisation utilise des algorithmes d’équilibrage de charge intégrés (comme décrit précédemment).

  • Messagerie unifiée   Les déploiements de messagerie unifiée peuvent être plus résilients en déployant plusieurs serveurs de messagerie unifiée lorsqu’il y en a deux ou plusieurs dans un seul plan de commutation des appels. Les passerelles voix sur IP (VoIP) prises en charge par la messagerie unifiée peuvent être configurées pour router des appels vers des serveurs de messagerie unifiée à la manière de tourniquets. En outre, ces passerelles peuvent récupérer la liste des serveurs d’un plan de numérotation à partir de DNS. Dans tous les cas, les passerelles voix sur IP passent un appel sur un serveur de messagerie unifiée et si l'appel n'est pas accepté, l'appel est passé sur un autre serveur, fournissant la redondance à l'heure d'établissement de l'appel.

Retour au début

Résilience de site

Exchange 2010 inclut une plateforme unifiée pour la haute disponibilité et la résilience de site. En alliant la prise en charge de la résilience de site native d’Exchange 2010 à une planification adéquate, vous pouvez rapidement activer un centre de données secondaire pour desservir les clients d’un centre de données défaillant. La défaillance d’un centre de données ou d’un site ne se gère pas de la même façon que les types de pannes susceptibles de provoquer un basculement de serveur ou de base de données. Dans une configuration à haute disponibilité, la récupération automatique est initiée par le système et la défaillance n’a généralement aucun impact sur la fonctionnalité du système de messagerie. En revanche, la défaillance d’un centre de données est considérée comme un événement de récupération d’urgence. En tant que tel, la récupération doit être effectuée manuellement pour que le service client soit restauré et la panne résolue. Ce processus est appelé permutation de centre de données. Comme dans de nombreux scénarios de récupération d’urgence, la planification et la préparation préliminaires d’une permutation de centre de données permettent de simplifier le processus de récupération et de réduire la durée de la panne.

Pour plus de détails sur la planification et le déploiement de la résilience de site, voir Planification d'une haute disponibilité et d'une résilience de site, Déploiement de haute disponibilité et de résilience de site et Switchovers de centre de données.

Retour au début

Disponibilité de bout en bout

Exchange 2010 inclut également de nombreuses fonctionnalités conçues pour accroître la disponibilité de bout en bout du système. Ces fonctionnalités sont les suivantes :

  • Redondance des clichés instantanés

  • Déplacement de boîte aux lettres en ligne

  • Protection flexible des boîtes aux lettres

  • Resynchronisation incrémentielle

  • API de réplication tierce

Redondance des clichés instantanés

En plus de la fonction de conteneur de dépôt de transport et des améliorations du comportement de routage décrites précédemment, une nouvelle fonctionnalité de serveur de transport Hub a été ajoutée ; il s’agit de la redondance des clichés instantanés. Cette fonctionnalité assure la redondance des messages pendant toute la durée de leur transfert. La solution implique une technologie similaire au conteneur de dépôt de transport. Avec la redondance des clichés instantanés, la suppression d’un message provenant de la base de données de transport est retardée jusqu’à ce que le serveur de transport vérifie l’arrivée à destination de tous les sauts de message suivants. Si un saut échoue avant de signaler le succès de la remise du message, le message est resoumis pour livraison avec ce saut. Pour plus d’informations sur la redondance des clichés instantanés, consultez la rubrique Présentation de la redondance des clichés instantanés.

Déplacement de boîte aux lettres en ligne

Exchange 2010 inclut une nouvelle fonctionnalité permettant le déplacement asynchrone des boîtes aux lettres. Dans Exchange 2007, lorsque vous utilisiez la cmdlet Move-Mailbox pour déplacer une boîte aux lettres, la cmdlet se connectait à la fois à la base de données source et à la base de données cible et déplaçait le contenu d’une boîte aux lettres à l’autre. L’utilisation des cmdlets pour effectuer le déplacement présentait plusieurs inconvénients :

  • Les déplacements de boîtes aux lettres duraient généralement des heures et les utilisateurs ne pouvaient pas accéder à leur boîte aux lettres pendant l’exécution du déplacement.

  • Si la fenêtre d’invite de commande servant à exécuter la cmdlet Move-Mailbox était fermée, le déplacement était annulé et il fallait recommencer l’opération depuis le début.

  • L’ordinateur utilisé pour effectuer le déplacement participait au transfert des données. Si un administrateur exécutait les cmdlets depuis son poste de travail, les données de la boîte aux lettres étaient transférées depuis le serveur source jusqu'au poste de travail de l'administrateur, puis vers le serveur cible.

La cmdlet New-MoveRequest dans Exchange 2010 peut être utilisée pour exécuter des déplacements asynchrones. Contrairement à Exchange 2007, les cmdlets n'effectuent pas le déplacement réel. Celui-ci est réalisé par le service de réplication de boîtes aux lettres de Microsoft Exchange, qui est un nouveau service s’exécutant sur un serveur d’accès au client. La cmdlet New-MoveRequest envoie des demandes vers le service de réplication de boîtes aux lettres Microsoft Exchange. Pour plus d’informations sur les déplacements de boîtes aux lettres en ligne, voir Présentation des demandes de déplacement.

Protection flexible des boîtes aux lettres

Plusieurs changements apportés à l’architecture de base d’Exchange 2010 ont une incidence directe sur la manière dont vous protégez vos bases de données de boîtes aux lettres et les boîtes aux lettres qu’elles contiennent.

Une modification significative est la suppression des groupes de stockage. Dans Exchange 2010, chaque base de données est associée à un flux de journaux unique qui est représenté par une série de fichiers journaux de 1 mégaoctet (Mo). Chaque serveur peut héberger jusqu’à 100 bases de données.

Un autre changement significatif apporté par Exchange 2010 est la disparition des liens étroits entre les bases de données et un serveur de boîtes aux lettres spécifique. La fonction de mobilité de base de données élargit l'utilisation de la réplication continue par le système en permettant la réplication d'une base de données dans plusieurs serveurs différents. La base de données est ainsi mieux protégée et sa disponibilité est accrue. En cas de défaillance, les autres serveurs disposant de copies de cette base de données peuvent la monter.

La capacité d’hébergement de plusieurs copies d’une base de données dans plusieurs serveurs signifie que si vous disposez d’un nombre suffisant de copies de base de données, vous pouvez les utiliser comme des sauvegardes. Pour plus d’informations sur cette stratégie, voir Présentation de la sauvegarde, de la restauration et de la récupération d'urgence.

Resynchronisation incrémentielle

Exchange 2007 a introduit les concepts de résilience à la perte de journaux et de réamorçage incrémentiel. La capacité de résilience à la perte de journaux est un composant interne d’ESE (Extensible Storage Engine), qui permet de récupérer des bases de données de boîtes aux lettres Exchange, même en cas de perte ou d’endommagement d’un ou plusieurs des fichiers journaux de transactions les plus récents. La résilience à la perte de journaux permet le montage d’une base de données de boîtes aux lettres même si des fichiers journaux récemment générés sont indisponibles. La résilience à la perte de journaux opère en retardant les écritures dans la base de données jusqu’à ce que le nombre spécifié de générations de journal ait été créé. Elle retarde les mises à jour récentes du fichier de la base de données pendant une courte période. La durée de retard des écritures dépend de la rapidité de génération des journaux.

Exchange 2007 a également introduit le concept de réamorçage incrémentiel, qui offrait la possibilité de corriger des divergences dans le flux des journaux de transactions entre les groupes de stockage source et cible en faisant appel à la fonction de relecture retardée de la capacité de résilience à la perte de journaux. Le réamorçage incrémentiel ne permettait pas de corriger les divergences dans la copie passive de la base de données après la relecture de journaux divergents, obligeant ainsi à refaire un nouvel amorçage complet. Contrairement à Exchange 2007, dans Exchange 2010, aucune quantité de perte de journaux ne requiert de réamorçage complet.

Dans Exchange 2010, cette fonctionnalité a été rebaptisée resynchronisation incrémentielle. Elle corrige automatiquement les divergences présentes dans les copies de base de données dans les cas suivants :

  • Après un basculement automatique de toutes les copies configurées d’une base de données.

  • Lorsqu’une nouvelle copie est activée et que certains fichiers de bases de données et de journaux existent déjà à l’emplacement de la copie.

  • Lors de la reprise de la réplication à la suite d’une suspension ou du redémarrage du service de réplication Microsoft Exchange.

Suite à ces modifications, la capacité de résilience à la perte de journaux est codée en dur dans un fichier journal pour toutes les bases de données de boîtes aux lettres Exchange 2010.

Lorsque des divergences sont détectées entre la base de données active et sa copie, la resynchronisation incrémentielle exécute les tâches suivantes :

  • Elle effectue une recherche historique dans le flux des fichiers journaux pour localiser le point de divergence.

  • Elle localise les pages modifiées de la base de données sur la copie divergente.

  • Elle lit les pages modifiées de la copie active à partir de laquelle elle les recopie dans les fichiers journaux concernés.

  • Elle applique les modifications apportées aux pages de la base de données sur la copie divergente.

  • Elle exécute une récupération de données sur la copie divergente et relit les fichiers journaux concernés dans la copie de la base de données.

API de réplication tierce

Exchange 2010 comprend également une nouvelle API de réplication tierce qui permet aux organisations d’utiliser des solutions de réplication synchrone tierces à la place de la fonctionnalité intégrée de réplication continue. Microsoft prend en charge les solutions tierces qui utilisent cette API tant qu’elles fournissent les fonctionnalités nécessaires pour remplacer toutes les fonctionnalités de réplication continue natives désactivées à cause de l’utilisation de l’API. Ces solutions sont uniquement prises en charge lorsque l’API est utilisée au sein d’un groupe de disponibilité de base de données pour gérer et activer les copies de bases de données de boîtes aux lettres. L’utilisation de l’API dans d’autres conditions n’est pas prise en charge. De plus, la solution doit satisfaire les exigences de prise en charge matérielle Windows applicables (validation des tests non requise pour la prise en charge).

Lors du déploiement d’une solution qui utilise l’API de réplication tierce intégrée, sachez que le fournisseur de la solution est responsable du support technique principal de cette solution. Microsoft prend en charge les données Exchange à la fois pour les solutions répliquées et non répliquées. Les solutions qui utilisent la réplication de données doivent adhérer à la stratégie de support Microsoft à ce sujet, telle qu’elle est décrite dans l’article 895847 de la Base de connaissances Microsoft intitulé Prise en charge de la réplication des données multisites pour Exchange Server. De plus, les solutions qui utilisent le modèle de ressources Cluster de basculement Windows doivent satisfaire les exigences en matière de capacités de prise en charge des clusters Windows, telles que décrites dans l’article 943984 de la Base de connaissances Microsoft intitulé Stratégie de support Microsoft pour les clusters à basculement Windows Server 2008.

La stratégie de support Microsoft en matière de sauvegarde et de restauration pour les déploiements qui utilisent des solutions API de réplication tierces est la même que pour les déploiements de réplication continue natifs.

Si vous êtes un partenaire à la recherche d’informations sur l’API de réplication tierce, veuillez contact votre représentant Microsoft. Pour obtenir des informations sur les produits partenaires pour Exchange 2010, consultez le site Web Partenaires Exchange 2010.

Retour au début

 © 2010 Microsoft Corporation. Tous droits réservés.