Présentation de la redondance des clichés instantanés

S'applique à : Exchange Server 2010

Dernière rubrique modifiée : 2010-01-25

Les stratégies haute disponibilité pour Exchange se concentrent sur la disponibilité et la récupération des données stockées dans les bases de données de boîtes aux lettres. Lorsque vous mettez en œuvre une solution à haute disponibilité pour vos serveurs de boîtes aux lettres, les messages électroniques ne sont pas perdus. Vous pouvez les récupérez à la suite d'une panne dès qu'ils se présentent dans une boîte aux lettres. 

Toutefois, ces stratégies ne s'appliquent pas aux messages en transit. Si un serveur de transport Hub tombe en panne pendant le traitement des messages, sans récupération possible de ce serveur, des données risquent d'être perdues. À mesure que le volume des messages traités par les serveurs de transport Hub augmente, le risque de perte de données est une préoccupation croissante pour les administrateurs.

Microsoft Exchange Server 2007 comporte la fonctionnalité Benne de transport pour le rôle serveur de transport Hub. Avec cette fonctionnalité, un serveur de transport Hub Exchange 2007 gère une file d'attente de messages remis récemment à des destinataires dont les boîtes aux lettres se trouvent sur un serveur de boîtes aux lettres en cluster. Lorsqu'un basculement se produit, le serveur de boîtes aux lettres en cluster interroge automatiquement chaque serveur de transport Hub dans le site Active Directory pour soumettre de nouveau le courrier présent dans la file d'attente de la benne de transport. Cela évite que des messages soient perdus au cours du basculement de cluster. Ce niveau de redondance de transport de base ne s'applique toutefois qu'à la remise de messages dans un environnement de réplication continue en cluster et ne permet pas d'éviter le risque de perte de courrier lorsque des messages sont en transit entre des serveurs de transport Hub et Edge.

Exchange Server 2010 comporte la fonctionnalité de redondance des clichés instantanés pour permettre la redondance des messages pendant toute la durée de leur transit. La solution a recours à une technologie similaire à la benne de transport. La redondance des clichés instantanés retarde la suppression d'un message dans les bases de données de transport jusqu'à ce que le serveur de transport vérifie que tous les sauts suivants de ce message ont abouti. Si l'un des sauts n'aboutit pas, le message est resoumis pour ce saut. 

Les avantages de la redondance des clichés instantanés sont les suivants :

• Élimine la dépendance vis à vis d'un serveur de transport Hub ou Edge. Si votre topologie de routage comporte des itinéraires de transfert de messages redondants, n'importe quel serveur de transport devient remplaçable.
• Si un serveur de transport tombe en panne, vous pouvez le retirer de l'environnement de production sans avoir besoin de vider ses files d'attente et sans courir le risque de perdre des messages.
• Si vous souhaitez mettre à niveau un serveur de transport Hub ou Edge, vous pouvez mettre ce serveur hors ligne à tout moment sans risquer de perdre des messages.
• Rend inutile la redondance du matériel de stockage pour les serveurs de transport.
• Consomme moins de bande passante que de créer des copies de messages sur plusieurs serveurs. La seule augmentation de trafic générée avec la redondance des clichés instantanés est due à l'échange de l'état de suppression entre serveurs de transport. L'état de suppression est une information fournie par chaque serveur. Il indique quand un message est prêt à être supprimé de la base de données de transport.
• Fournit un certain degré de résilience et simplifie la récupération des messages à la suite d'une panne d'un serveur de transport.

La mise en œuvre de la redondance des clichés instantanés s'effectue en étendant le service SMTP. Les extensions de service permettent aux hôtes SMTP de négocier la prise en charge de la redondance des clichés instantanés et d'échanger l'état de suppression des messages de cliché instantané.

Souhaitez-vous rechercher les tâches de gestion relatives à la gestion des serveurs de transport ? Voir Gestion des serveurs de transport.

Contenu de cette rubrique

Composants de la redondance des clichés instantanés

Flux de messages de redondance des clichés instantanés

Gestionnaire de redondance des clichés instantanés

Traitement des messages après une panne

Droits étendus requis pour la redondance des clichés instantanés

Composants de la redondance des clichés instantanés

Le tableau suivant décrit tous les composants de la redondance des clichés instantanés.

Composants de la redondance des clichés instantanés

Composant	Description
Message principal	Message d'origine envoyé au serveur de transport pour remise.
Message de cliché instantané	Copie d'un message qu'un serveur de transport conserve jusqu'à ce qu'il confirme que tous les sauts suivants de ce message ont abouti.
Serveur principal	Serveur de transport qui traite un message.
Serveur de clichés instantanés	Serveur de transport qui conserve des copies d'un message de cliché instantané après avoir remis ce message au serveur principal.
File d'attente de clichés instantanés	File d'attente utilisée par un serveur de transport pour stocker les messages de cliché instantané. Un serveur de transport disposera de files d'attente de clichés instantanés séparées pour chaque saut auquel il a remis le message principal.
État de suppression	Information concernant les messages de cliché instantané qu'un serveur de transport fournit pour indiquer quand un message peut être supprimé.
Notification de suppression	Réponse qu'un serveur de clichés instantanés reçoit d'un serveur principal et qui indique qu'un message peut être supprimé.
Gestionnaire de redondance des clichés instantanés	Composant de transport qui gère la redondance des clichés instantanés.
Pulsation	Processus auquel les serveurs de transport ont recours pour vérifier la disponibilité des autres serveurs de transport.

Retour au début

Flux de messages de redondance des clichés instantanés

Pour illustrer le flux de messages avec la redondance des clichés instantanés activée, prenons l'exemple d'un scénario simple dans lequel un serveur de transport Hub envoie un message à un serveur de messagerie tiers via un serveur de transport Edge dans le réseau de périmètre.

Flux des messages avec redondance des clichés instantanés

Dans ce scénario, le flux des messages passe par les étapes suivantes :

1. Le serveur de transport Hub remet un message au serveur de transport Edge.
   1. Le serveur de transport Hub ouvre une session SMTP avec le serveur de transport Edge.
   2. Le serveur de transport Edge annonce qu'il prend en charge la redondance de clichés instantanés.
   3. Le serveur de transport Hub indique au serveur de transport Edge de détecter les messages avec l'état de suppression.
   4. Le serveur de transport Hub envoie le message au serveur de transport Edge.
   5. Le serveur de transport Edge accuse réception du message et enregistre le nom du serveur de transport Hub pour lui transmettre les informations de suppression relatives au message.
   6. Le serveur de transport Hub transmet le message à la file d'attente de clichés instantanés du serveur de transport Edge et marque celui-ci comme serveur principal. Le serveur de transport Hub devient le serveur des clichés instantanés.
2. Le serveur de transport Edge remet le message au saut suivant.
   1. Le serveur de transport Edge envoie le message à un serveur de messagerie tiers.
   2. Le serveur de messagerie tiers accuse réception du message.
   3. Le serveur de transport Edge met à jour l'état de suppression du message dès sa remise.
3. Le serveur de transport Hub interroge le serveur de transport Edge pour savoir si l'état de suppression est associé au message (en cas de réussite de la remise du message).
   1. À la fin de chaque session SMTP avec le serveur de transport Edge, le serveur de transport Hub interroge le serveur de transport Edge pour savoir si l'état de suppression est associé aux messages déjà envoyés. Si le serveur de transport Hub n'a ouvert aucune session SMTP avec le serveur de transport Edge après l'envoi des messages, il ouvre une session SMTP avec le serveur de transport Edge pour vérifier si l'état de suppression est associé à des messages après un certain temps.
   2. Le serveur de transport Edge vérifie si l'état de suppression est associé à des messages, puis il renvoie une liste des messages livrés et supprime les informations de suppression.
   3. Le serveur de transport Hub supprime ces messages de sa file d'attente de clichés instantanés.
4. Le serveur de transport Hub interroge le serveur de transport Edge pour savoir si l'état de suppression est associé au message, et si c'est le cas, il renvoie le message (en cas d'échec de la remise du message).
   1. Si le serveur de transport Hub ne peut pas contacter le serveur de transport Edge, le serveur de transport Hub reprend son rôle de serveur principal et il renvoie les messages dans la file d'attente de clichés instantanés.
   2. Les messages renvoyés sont remis à un autre serveur de transport Edge et le flux de travail commence à l'étape 1.

      Remarque :
      Si aucun autre itinéraire n'est disponible pour un message de cliché instantané (comme le second serveur de transport Edge montré dans l'illustration précédente), il ne sera pas renvoyé et il restera dans la file d'attente de clichés instantanés.

Pour plus d'informations sur le flux des messages dans différents scénarios, voir Scénarios de flux de messagerie de redondance des clichés instantanés.

Scénario à plusieurs sauts

Si un message transite par plusieurs serveurs qui prennent en charge la redondance des clichés instantanés, le message est conservé sur un serveur jusqu'à ce que le serveur suivant confirme qu'il l'a reçu. Pour illustrer comment cela fonctionne, prenons le cas d'une organisation comportant cinq sites Active Directory disposant de serveurs de transport Hub. Les sites sont connectés comme le montre l'illustration suivante. Les sites de New York et de Londres de l'organisation sont configurés en tant que sites Hub, par conséquent les messages provenant de Chicago ou d'Atlanta doivent transiter par les serveurs de transport Hub des sites de New York et de Londres pour parvenir au site de Dublin.

Exemple de topologie pour un scénario à plusieurs sauts

Supposons qu'un message soit envoyé par un utilisateur se trouvant dans le site de Chicago à un utilisateur se trouvant dans le site de Dublin. Ce message devra transiter par les sites de New York et de Londres pour parvenir au site de Dublin. Dans ce cas, voici ce qui se produit :

1. Le serveur de transport Hub de Chicago envoie le message au serveur de transport Hub de New York et il conserve une copie du message.
2. Le serveur de transport Hub du site de New York envoie le message au serveur de transport Hub du site de Londres et il transmet un état de suppression à la file d'attente du serveur Hub du site de Chicago.
3. Le serveur de transport Hub de Chicago interroge le serveur de transport Hub de New York pour savoir si l'état de suppression est associé au message envoyé et il reçoit une notification de suppression pour le message. À ce stade, il peut supprimer le message de cliché instantané de sa base de données. La remise du message du site de Londres au site de Dublin n'a aucune incidence sur la suppression du message par le serveur de transport Hub de Chicago.

Interopérabilité

L'utilisation ou non de la redondance des clichés instantanés est décidée lorsqu'une nouvelle connexion SMTP est établie. Si les deux serveurs dans une connexion SMTP prennent en charge la redondance des clichés instantanés, le flux de travail mentionné précédemment est utilisé. Cependant, il peut arriver que des serveurs de transport Exchange 2010 échangent des messages avec des serveurs de messagerie qui ne prennent pas en charge la redondance des clichés instantanés. Il peut s'agir de serveurs de messagerie tiers ou de serveurs avec une version antérieure d'Exchange. Cela peut également être le cas lorsqu'une organisation Exchange 2010 n'a pas activé la redondance des clichés instantanés.

Lorsqu'un serveur de transport Exchange 2010 qui prend en charge la redondance des clichés instantanés établit une connexion avec un serveur qui ne prend pas en charge la redondance des clichés instantanés, voici ce qui se produit :

1. Exchange établit une connexion SMTP vers le serveur cible.
2. Le serveur cible n'annonce pas qu'il prend en charge la redondance des clichés instantanés.
3. Étant donné que le serveur cible ne prend pas en charge la redondance des clichés instantanés, Exchange effectue ce qui suit pour chaque message :
   1. Le message est remis au serveur cible.
   2. Le Gestionnaire de redondance des clichés instantanés marque le message comme étant remis au saut suivant.
   3. Le message est supprimé une fois qu'il est remis à tous les sauts suivants.

Lorsqu'un serveur qui ne prend pas en charge la redondance des clichés instantanés établit une connexion avec un serveur Exchange 2010, voici ce qui se produit :

1. Le serveur d'envoi établit une connexion SMTP avec Exchange.
2. Le serveur Exchange annonce qu'il prend en charge la redondance des clichés instantanés.
3. Le serveur d'envoi ne prend pas en charge la redondance des clichés instantanés et il ne l'utilisera donc pas. Il remet alors les messages au serveur Exchange.
4. Pour chaque message que le serveur Exchange reçoit, il effectue ce qui suit :
   1. Il transmet le message au saut suivant ou il en crée une copie.
   2. Il envoie un accusé de réception au serveur d'envoi.

Accusé de réception retardé

Le principe sur lequel repose la redondance des clichés instantanés est la conservation d'une copie d'un message sur le serveur précédent jusqu'à ce que ce serveur s'assure que le message a été remis à tous les sauts (ou serveurs) suivants. Cela n'est pas possible lorsqu'un serveur de transport Exchange 2010 reçoit un message d'un serveur de messagerie qui ne prend pas en charge la redondance des clichés instantanés. Il peut s'agir d'un serveur Exchange exécutant une ancienne version d'Exchange, d'un client SMTP standard ou d'un serveur de messagerie non Exchange sur Internet. Dans ce cas, le serveur Exchange tente de simuler la redondance des clichés instantanés en retardant l'envoi d'un accusé de réception au serveur de messagerie jusqu'à ce qu'il vérifie que le message a été remis à tous les sauts suivants en interne. De cette manière, si le serveur Exchange 2010 tombe en panne, le serveur de messagerie d'envoi supposera que le message n'a jamais été remis au serveur Exchange et il tentera de lui remettre de nouveau.

Cependant, la remise du message aux sauts suivants peut prendre un certain temps soit en raison de la complexité de votre infrastructure de routage, soit en raison d'une panne d'un des sauts suivants. Dans ce cas, pour empêcher l'expiration de la session SMTP, le serveur de transport Exchange 2010 envoie un accusé de réception au serveur de messagerie d'envoi. Dans ce cas, la redondance de la messagerie n'est pas garantie mais est tentée. Par exemple, il peut arriver qu'un message soit perdu dans le scénario suivant : Un serveur de messagerie Internet transmet un message à un serveur de transport Edge. Le serveur de transport Edge ne peut pas communiquer avec le serveur de transport Hub en raison d'un problème de réseau et il envoie un accusé de réception du message au serveur de messagerie Internet. Le serveur de transport Edge tombe en panne et ne peut pas être récupéré avant que le problème de réseau soit résolu. À ce stade, le message est perdu.

La valeur d'expiration de l'accusé de réception retardé est déterminée par l'attribut MaxAcknowledgementDelay de chaque connecteur de réception. La valeur par défaut est 30 secondes. Pour en savoir plus sur la configuration de cet attribut, voir Configurer la redondance des clichés instantanés.

Retour au début

Gestionnaire de redondance des clichés instantanés

Le Gestionnaire de redondance des clichés instantanés est le composant d'un serveur de transport Exchange 2010 qui est responsable de la gestion de la redondance des clichés instantanés.

Le Gestionnaire de redondance des clichés instantanés est responsable de la gestion des informations suivantes pour tous les messages principaux traités par un serveur :

• Serveur de clichés instantanés traitant chaque message principal
• État de suppression à envoyer aux serveurs de clichés instantanés

Le Gestionnaire de redondance des clichés instantanés est responsable de ce qui suit pour tous les messages de cliché instantané se trouvant dans les files d'attente de clichés instantanés d'un serveur :

• Gestion de la liste des serveurs principaux pour chaque message de cliché instantané
• Vérification de la disponibilité de chaque serveur principal pour lequel un message de cliché instantané est placé en file d'attente
• Traitement des notifications de suppression provenant des serveurs principaux
• Suppression des messages de cliché instantané de la base de données après réception de toutes les notifications de suppression
• Transmission de la propriété des messages de cliché instantané au serveur de clichés instantanés (celui-ci devenant le serveur principal)

En outre, le Gestionnaire de redondance des clichés instantanés est responsable de la gestion des compteurs de performances associés à la redondance des clichés instantanés.

Pulsation

Le Gestionnaire de redondance des clichés instantanés a recours à la pulsation des échanges entre serveurs pour déterminer la disponibilité des serveurs pour lesquels des messages de cliché instantané sont placés en file d'attente. Au cours de la session SMTP entre deux serveurs qui prennent en charge la redondance des clichés instantanés, le serveur qui initie la connexion interroge le serveur cible pour savoir si l'état de suppression est associé à des messages déjà envoyés à ce serveur. Le serveur à l'origine de la connexion y parvient en émettant une commande XQUERYDISCARD. En réponse, le serveur cible renvoie les notifications de suppression. L'échange entre les deux serveurs est utilisé comme pulsation de la redondance des clichés instantanés.

Une valeur d'expiration limite le délai de la pulsation. Si aucune connexion n'est établie avec le serveur pour lequel le Gestionnaire de redondance des clichés instantanés gère une file d'attente pendant ce délai, le serveur tente d'établir une connexion SMTP avec le serveur principal surtout pour vérifier si l'état de suppression est associé à des messages sur ce serveur et pour réinitialiser le délai. La valeur d'expiration est déterminée par le paramètre ShadowHeartbeatTimeoutInterval de la cmdlet Set-TransportConfig et elle est définie à 300 secondes par défaut.

Si le serveur ne peut pas établir une connexion avec le serveur principal lorsque la valeur d'expiration est atteinte, il redéfinit le délai et il effectue une nouvelle tentative. Si la valeur d'expiration est atteinte trois fois de suite, le serveur conclut que le serveur principal est tombé en panne et il devient propriétaire des messages. Il commence alors à générer des notifications de suppression pour les messages qui sont envoyées au serveur principal tombé en panne. Le nombre de tentatives que doit effectuer un serveur avant de décider qu'un serveur principal est tombé en panne est déterminé par le paramètre ShadowHeartbeatRetryCount de la cmdlet Set-TransportConfig.

Pour en savoir plus sur la configuration de la pulsation de la redondance des clichés instantanés, voir Configurer la redondance des clichés instantanés.

Retour au début

Traitement des messages après une panne

La redondance des clichés instantanés limite la perte des messages due à des pannes de serveur. Lorsqu'un serveur de transport revient en ligne après une panne, deux scénarios sont possibles :

• Le serveur revient en ligne avec une nouvelle base de données de transport   Dans ce scénario, la base de données de transport est irrécupérable en raison d'une panne de matériel ou parce que des données sont endommagées. Dans ce cas, étant donné que le serveur de transport a un nouvel ID de base de données, il est reconnu comme nouvel itinéraire par les autres serveurs de transport de l'organisation. Cela est également le cas lorsqu'un serveur est irrécupérable et qu'un nouveau serveur est installé en remplacement.
• Le serveur revient en ligne avec la même base de données de transport   Dans ce scénario, le serveur de transport n'est pas tombé en panne mais il a été mis hors ligne pour une durée prolongée. Par exemple, une panne de carte réseau ou une longue opération de maintenance sur le serveur peut être à l'origine de ce scénario.

Le tableau suivant détaille le comportement du transport dans ces deux scénarios lorsque la redondance des clichés instantanés est activée. Pour plus de clarté, nous supposerons que le serveur en panne est appelé Hub01.

Traitement des messages dans les scénarios de récupération

Scénario de récupération	Actions entreprises pour les messages qui ont des itinéraires alternatifs	Actions entreprises pour les messages sans aucun itinéraire alternatif
Hub01 revient en ligne avec une nouvelle base de données.	Lorsque Hub01 devient indisponible, chaque serveur qui a des messages en file d'attente pour Hub01 devient propriétaire de ces messages et les renvoie. Les messages sont alors remis à leurs destinations en utilisant d'autres itinéraires. Le retard total des messages est égal au produit de l'intervalle d'expiration de la pulsation et du nombre de tentatives de pulsation configuré dans votre organisation.	Les messages restent dans la file d'attente de clichés instantanés sur chaque serveur qui a placé des messages en file d'attente pour Hub01. Lorsque Hub01 revient en ligne avec un nouvel ID de base de données, les serveurs de clichés instantanés détectent qu'il s'agit d'une nouvelle base de données et ils renvoient les messages placés en file d'attente à Hub01. Cela revient à découvrir soudainement un itinéraire alternatif pour ces messages. Le retard total des messages dépend de la durée de la panne.
Hub01 revient en ligne avec la même base de données.	Hub01 remet les messages se trouvant dans ses files d'attente. Cela entraîne une remise en double de ces messages. Les utilisateurs de boîtes aux lettres Exchange ne verront pas les messages en double grâce à la détection des messages en double. Cependant, les destinataires sur des systèmes étrangers risquent de recevoir des messages en double. Le retard total des messages est égal au produit de l'intervalle d'expiration de la pulsation et du nombre de tentatives de pulsation configuré dans votre organisation.	Hub 01 remet les messages se trouvant dans ses files d'attente et il envoie des notifications de suppression aux serveurs de clichés instantanés. Le retard total des messages dépend de la durée de la panne.

Retour au début

Droits étendus requis pour la redondance des clichés instantanés

Exchange 2010 ajoute les deux droits étendus suivants requis pour la redondance des clichés instantanés :

• ms-Exch-SMTP-Accept-XSHADOW
• ms-Exch-SMTP-Send-XSHADOW

Lorsqu'une connexion SMTP est établie avec un serveur de transport Exchange 2010, celui-ci annonce qu'il prend en charge la redondance des clichés instantanés si le droit étendu ms-Exch-SMTP-Accept-XSHADOW existe sur le connecteur de réception utilisé. En outre, le mécanisme d'authentification sur le connecteur de réception doit être l'authentification Exchange Server ou il doit être sécurisé de l'extérieur.

Lorsqu'un serveur de transport Exchange 2010 établit une connexion SMTP avec un autre serveur qui annonce qu'il prend en charge la redondance des clichés instantanés, il émet une commande XSHADOW uniquement si le droit étendu ms-Exch-SMTP-Send-XSHADOW a été accordé à la session.

Par défaut, ces droits étendus sont accordés au groupe de serveurs Exchange sur tous les connecteurs d'envoi et de réception internes.

Remarque :

La redondance des clichés instantanés peut être activée ou désactivée pour l'organisation entière à l'aide du paramètre ShadowRedundancyEnabled de la cmdlet Set-TransportConfig. Ce paramètre remplace les droits étendus décrits dans cette section. Si la redondance des clichés instantanés est désactivée pour l'organisation, le serveur Exchange n'annoncera pas qu'il la prend en charge et il n'émettra pas de commandes XSHADOW même si les droits étendus nécessaires sont accordés à la session SMTP.

Retour au début