Nouvelles fonctionnalités de disponibilité élevée et de résilience de site

Article
03/02/2017

S’applique à : Exchange Server 2010 SP2

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

Microsoft Exchange Server 2010 réduit le coût et la complexité du déploiement d’une solution de messagerie électronique qui offre les niveaux les plus élevés de disponibilité de serveur et de résilience de site. 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écupération d’urgence. 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.

Leçons tirées d’Exchange Server 2007

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

Certains administrateurs étaient intimidés par la complexité du clustering avec basculement Windows.
L’obtention d’un niveau élevé de temps disponible peut 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.
Les solutions de résilience de site n’étaient pas transparentes.
La fonction de benne 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 continue locale ou 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 les profondeurs de son architecture, pour un coût encore plus réduit et une facilité de déploiement et de maintenance plus grande que Exchange 2007 pour tous les clients. Les entreprises peuvent maintenant déployer une organisation Exchange totalement redondante avec seulement deux serveurs et tirer parti des basculements opérés au niveau des bases de données. Les clients bénéficient des capacités de basculement automatique au niveau des bases de données, sans devoir être des experts du clustering avec basculement Windows. Une procédure moins complexe leur permet également d’ajouter la résilience de site à leurs déploiements actuels de la haute disponibilité.

Exchange 2007 avait 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 instantanément 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.

Pourtant, la gestion d’une solution de haute disponibilité Exchange 2007 exigeait que les administrateurs maîtrisent 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 administrateurs devaient utiliser les outils Exchange et les outils de clustering 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 reconfiguré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, c’est-à-dire 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.

Résilience de boîte aux lettres

Exchange 2010 a été remodelé pour s’articuler autour du concept de résilience de boîte aux lettres, en changeant l’architecture de manière que la protection automatique contre le basculement soit désormais appliquée au niveau d’une base de données de boîtes de lettres et non plus au niveau du serveur . Dans Exchange 2010, ce concept s’appelle la mobilité de base de données. Grâce à cette mobilité et à d’autres changements dans l’architecture du cache de base de données, 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 SP2. Par comparaison, le basculement d’une base de données de boîtes aux lettres dans un environnement Exchange 2010 prend 30 secondes ou moins (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 disponible, 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 considérablement le temps disponible d’une organisation.

L’architecture de résilience de boîte aux lettres intégrée à Exchange 2010 procure de nouveaux atouts aux organisations et aux administrateurs de leurs messageries :

Plusieurs rôles de serveur peuvent coexister sur les serveurs à haut niveau de disponibilité. Les organisations de petite taille peuvent ainsi déployer une configuration à deux serveurs qui leur fournit une configuration redondante de leurs données et services de boîtes aux lettres, mais aussi des services d’accès au client et de transport Hub.
Un administrateur n’a plus besoin de créer un cluster de basculement pour parvenir à une haute disponibilité. Les clusters de basculement sont maintenant créés par Exchange 2010 par le biais d’une procédure invisible pour l’administrateur. Contrairement aux versions précédentes de clusters Exchange qui utilisaient une DLL de ressource de cluster fournie par Exchange appelée ExRes.dll, Exchange 2010 n’a plus besoin, et n’utilise plus, de DLL de ressource de cluster. Exchange 2010 n’est pas une application en cluster et n’exploite qu’une petite partie des composants de cluster de basculement, à savoir ses capacités de pulsation et la base de données de clusters, pour fournir la mobilité de base de données.
Les administrateurs peuvent ajouter la fonctionnalité de haute disponibilité à leur environnement Exchange 2010 après le déploiement d’Exchange, sans devoir désinstaller Exchange et le redéployer dans une configuration à haut niveau de disponibilité.
Exchange 2010 fournit une vue du flux d’événements qui fusionne et combine les événements du système d’exploitation avec les événements d’Exchange.
Comme les objets de groupe de stockage n’existent plus dans Exchange 2010 et comme les bases de données de boîtes aux lettres sont portables entre tous les serveurs de boîtes aux lettres Exchange 2010, il est facile de déplacer les bases de données lorsque c’est nécessaire.

Pour plus d’informations, voir Haute disponibilité et résilience de site.

Protection flexible des boîtes aux lettres

Sous réserve d’un déploiement et d’une configuration effectués correctement, Exchange 2010 comporte plusieurs fonctionnalités nouvelles et des changements majeurs qui peuvent aboutir à une protection flexible des boîtes aux lettres et rendre inutiles les sauvegardes traditionnelles de vos données. En exploitant les fonctions de haute disponibilité intégrées à Exchange 2010 pour minimiser les temps morts et la perte de données en cas de récupération d’urgence, il est également possible de réduire le coût total de possession du système de messagerie. En associant ces fonctionnalités à d’autres fonctions intégrées, telles que la Conservation légale, les organisations peuvent réduire, voire éliminer leur dépendance aux sauvegardes ponctuelles traditionnelles et donc réaliser des économies.

En plus d’établir si Exchange 2010 vous permet de prendre vos distances avec les sauvegardes ponctuelles traditionnelles, nous vous recommandons également d’évaluer le coût de votre infrastructure de sauvegarde actuelle. Pensez aux coûts que représentent le temps mort pour l’utilisateur final et la perte de données engendrée pendant une tentative de récupération d’urgence avec votre infrastructure de sauvegarde actuelle. Votre évaluation doit également inclure les coûts du matériel, de l’installation et des licences, ainsi que les frais de gestion associés à la récupération des données et à la maintenance des sauvegardes. En fonction de la configuration requise pour votre organisation, il est fort probable qu’un environnement Exchange 2010 pur, constitué d’au moins trois copies de base de données de boîtes aux lettres, offre un coût total de possession inférieur à un environnement avec sauvegardes.

Pour plus d’informations sur la protection flexible des boîtes aux lettres, voir Présentation de la sauvegarde, de la restauration et de la récupération d'urgence.

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

Exchange 2010 comprend de nombreuses modifications apportées à son architecture de base. Exchange 2010 comporte des fonctionnalités essentielles de disponibilité et de résilience des réplications continues locale et en cluster et les intègre à une solution unique de haute disponibilité 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 (DAG) afin que la récupération automatique soit opérée au niveau d’une base de données de boîtes aux lettres et non pas au niveau du serveur. Chaque base de données de boîtes aux lettres peut avoir jusqu’à 16 copies. 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. Les concepts d’une organisation sans sauvegardes et technologie RAID vont également être introduits dans Exchange 2010.

En résumé, les caractéristiques principales de disponibilité des données et des services pour le rôle serveur de boîte aux lettres et pour les bases de données de boîtes aux lettres sont les suivantes :

Exchange 2010 utilise une version améliorée de la même technologie de réplication continue qui avait été introduite dans Exchange 2007. Pour plus d’informations, consultez la section Changements apportés à la réplication continue depuis Exchange Server 2007 plus loin dans cette rubrique.
Les groupes de stockage n’existent plus dans Exchange 2010. Ils sont remplacés simplement par des bases de données de boîtes aux lettres, des copies de base de données de boîtes aux lettres et des bases de données de dossiers publics. Au sein de la console de gestion Exchange, l’interface de gestion principale des bases de données Exchange est passée du nœud Boîte aux lettres sous Configuration du serveur au nœud Boîte aux lettres sous Configuration de l’organisation.
Une partie de la technologie de clustering de basculement Windows est utilisée par Exchange 2010, mais elle est désormais gérée en totalité par Exchange. Les administrateurs n’ont plus besoin d’installer, de créer ou de configurer les aspects d’un clustering de basculement lorsqu’ils déploient des serveurs de boîtes aux lettres à haut niveau de disponibilité.
Chaque serveur de boîtes aux lettres peut héberger jusqu’à 100 bases de données et chacune de ces bases peut avoir jusqu’à 16 copies.
En plus de la fonction de benne de transport, 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 fait appel à une technique similaire à celle de la benne 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 l’un des sauts suivants échoue avant de confirmer la remise du message, le message est renvoyé pour remise à ce saut suivant. Pour plus d’informations sur la redondance des clichés instantanés, voir Présentation de la redondance des clichés instantanés.

Déploiement incrémentiel

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 antérieures d’Exchange). Si vous aviez déjà installé les fichiers du programme Exchange sur un serveur non configuré en cluster et si vous souhaitez 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.

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.

Groupes de disponibilité de base de données

Un groupe de disponibilité des bases de données est un ensemble formé d’un maximum de 16 serveurs de boîtes aux lettres qui 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.

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

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.

Les autres caractéristiques principales de la mobilité de base de données sont les suivantes :

Comme les groupes de stockage ont été supprimés dans Exchange 2010, la réplication continue fonctionne désormais au niveau de la base de données. Dans Exchange 2010, les journaux de transactions sont répliqués dans un ou plusieurs serveurs de boîtes aux lettres et sont relus dans une copie de la base de données de boîtes aux lettres qui est stockée dans ces serveurs.
Un basculement est un processus d’activation automatique qui se produit au niveau de la base de données ou du serveur. Un déplacement est un processus d’activation manuel que vous exécutez au niveau de la base de données, du serveur ou du centre de données (site).
Les noms de base de données Exchange 2010 doivent être uniques au sein de l’organisation Exchange.
Lorsqu’une base de données de boîtes aux lettres a été configurée avec une ou plusieurs copies de base de données, le chemin d’accès à toutes les copies de base de données doit être identique sur tous les serveurs de boîtes aux lettres hébergeant une copie.
Il est possible de sauvegarder n’importe quelle copie de base de données de boîtes aux lettres (active ou passive) à l’aide d’une application de sauvegarde basée sur le service VSS et compatible avec Exchange.

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

Changements apportés à la réplication continue depuis Exchange Server 2007

Exchange 2010 conserve la technologie sous-jacente de réplication continue que l’on trouvait dans les fonctions de réplication continue en cluster (CCR) et de réplication continue de secours (SCR), et l’a fait évoluer pour prendre en charge de nouvelles fonctionnalités de haute disponibilité, comme les copies de base de données, la mobilité de base de données et les groupes de disponibilité de base de données (DAG). Une brève description de ces changements d’architecture est fournie ci-dessous :

Comme les groupes de stockage ont été supprimés dans Exchange 2010, la réplication continue fonctionne désormais au niveau de la base de données. Exchange 2010 utilise encore une base de données ESE (Extensible Storage Engine). Celle-ci génère des journaux de transactions qui sont répliqués dans une ou plusieurs copies d’une base de données de boîtes aux lettres.
La fonctionnalité de relecture de journal, qui était assurée par le service de réplication Microsoft Exchange dans Exchange 2007, a été transférée dans la version Exchange 2010 du service de banque d’informations Microsoft Exchange (store.exe). Par conséquent, le gain de performance associé aux basculements et aux déplacements (en raison de la mise en place d’un nouveau cache de base de données) n’existe plus. En cas de basculement ou de déplacement, la base de données activée dispose d’un cache quasi-opérationnel.
L’envoi de journaux et l’amorçage n’utilisent plus le protocole SMB (Server Message Block) pour transférer les données. La réplication continue d’Exchange 2010 utilise un seul port TCP, défini par l’administrateur, pour le transfert des 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’envoi de journaux ne se base plus sur un modèle d’extraction de données (pull) où la copie passive extrait les fichiers journaux fermés de la copie active. Désormais, la copie active envoie les fichiers journaux à chaque copie passive configurée.
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, chaque membre de DAG peut héberger une base de données de dossiers publics, et vous pouvez utiliser la réplication de dossiers publics pour répliquer des dossiers publics entre les bases de données de dossiers publics hébergées sur les membres du DAG.
Le composant LogReplayer du service de réplication Microsoft Exchange intègre une nouvelle logique permettant de suspendre la relecture des fichiers journaux si la longueur de la file d’attente de copie va au-delà d’un seuil spécifique. Si le nombre de fichiers journaux dans la file d’attente de copie est supérieur au nombre de fichiers journaux copiés dans la copie de base de données passive, mais non inspecté par la copie passive, le service de réplication Microsoft Exchange suspend alors la relecture des fichiers journaux pour la copie passive et consigne l’événement d’avertissement 4110 dans le journal des événements. Lorsque le nombre de fichiers journaux dans la file d’attente de copie passe au-dessous du nombre de fichiers journaux copiés et non inspectés, le service de réplication Microsoft Exchange reprend la relecture pour la copie passive et consigne l’événement informatif 4111 dans le journaux des événements.

Plusieurs concepts utilisés dans la réplication continue d’Exchange 2007 sont également conservés dans Exchange 2010, notamment les concepts de gestion des basculements, de divergence, le paramètre de numérotation de montage de base de données automatique et l’utilisation de réseaux publics et privés.

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 bases 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 une benne 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 de 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.

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 :

Résilience de transport
Déplacement de boîte aux lettres en ligne
Protection des données natives d’Exchange
Resynchronisation incrémentielle
API de réplication tierce

Résilience de transport

Exchange 2007 a introduit la fonctionnalité Benne de transport du serveur de transport Hub. La benne de transport gère une file d’attente de messages remis à des destinataires dont la boîte aux lettres se trouvait dans un environnement de réplication continue en cluster (et dans Exchange 2007 SP1, dans un environnement de réplication continue locale). Cette fonctionnalité avait été conçue dans l’optique d’une protection contre la perte de données en fournissant à l’administrateur la possibilité de mettre en ligne automatiquement un serveur de boîtes aux lettres en cluster sur un autre nœud tout en limitant la perte de données. Il s’agit d’un « basculement avec perte ». Lorsqu’un basculement avec perte se produisait, le système remettait automatiquement tous les messages électroniques récemment envoyés aux utilisateurs sur le serveur de boîtes aux lettres en cluster présentant le problème, à l’aide de la benne de transport stockant ces messages électroniques. Si cette solution aidait à réduire le volume de données perdues en cas de basculement avec perte, elle ne protégeait contre la perte des données que sur un seul site. Les messages en transit ne disposaient d’aucune protection.

Exchange 2010 introduit des changements architecturaux essentiels qui traitent les deux problèmes. Puisque les groupes de disponibilité de base de données peuvent être étendus entre des sites Active Directory, le déplacement d’une base de données de boîtes aux lettres individuelle entre des sites Active Directory devient possible. En raison de cette modification de conception, la demande de nouvelle remise de la benne de transport, consécutive à un basculement de base de données avec perte, est maintenant transmise aux serveurs de transport Hub qui sont présents à la fois dans le site d’origine de la base de données et dans les nouveaux sites Active Directory.

L’autre changement important apporté à la benne de transport est sa capacité de réception des informations du pipeline de réplication. Lorsque les messages de la benne de transport ont été répliqués dans toutes les copies de base de données de boîtes aux lettres, ils sont supprimés de la benne. Cette suppression garantit que seules les données non répliquées sont conservées dans la benne de transport.

En plus de la fonction de benne de transport, 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 à la benne (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 l’un des sauts suivants échoue avant de confirmer la remise du message, le message est renvoyé pour remise à ce saut suivant. 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 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 de 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.

Les nouvelles cmdlets de demande de déplacement dans Exchange 2010 peuvent 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 le serveur d’accès au client. La cmdlet New-MoveRequest envoie des demandes vers le service de réplication de boîtes aux lettres. Pour plus d’informations sur le déplacement de boîte aux lettres en ligne, voir Présentation des demandes de déplacement.

Protection des données natives Exchange

Plusieurs changements apportés à l’architecture de base de 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 (LLR) 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.

Remarque :
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.

Le réamorçage incrémentiel 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.

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.

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

Fonctionnalités d’Exchange Server 2007 supprimées

Les fonctionnalités suivantes de Exchange 2007 et Exchange 2007 SP1 n’existent plus dans Exchange 2010. Le tableau indique les éléments les remplaçant.

Fonctionnalité	Remplacement
Réplication continue en cluster (CCR)	Groupes de disponibilité de base de données et copies de base de données de boîte aux lettres
Réplication continue de secours (SCR)	Groupes de disponibilité de base de données et copies de base de données de boîte aux lettres
Réplication continue locale (LCR)	Groupes de disponibilité de base de données et copies de base de données de boîte aux lettres
Clusters à copie unique (SCC)	Groupes de disponibilité de base de données et copies de base de données de boîte aux lettres ; mise à disposition d’API synchrones tierces intégrées pour remplacer la réplication tierce de données utilisée avec les clusters à copie unique
Serveurs de boîtes aux lettres en cluster	Groupes de disponibilité de base de données et copies de base de données de boîte aux lettres
Groupes de stockage	Bases de données
Groupe de stockage de récupération	Base de données de récupération

Partager via