Demandes de renvoi et messages de renvoi

Dernière rubrique modifiée : 2005-07-17

Le « renvoi » se produit lorsqu'une banque de dossiers publics détermine qu'elle n'a pas reçu toutes les mises à jour d'un dossier répliqué (ou de la hiérarchie) et qu'elle doit, par conséquent, récupérer les mises à jour manquantes auprès d'une autre banque.

Pour optimiser le processus de renvoi, Exchange Server 2003 stocke les informations sur les mises à jour manquantes dans la pile de renvoi.

Les événements suivants peuvent avertir une banque de dossiers publics que des mises à jours sont manquantes et doivent être renvoyées :

• Les informations d'état contenues dans un message de réplication entrant indiquent que le réplica situé dans la banque de dossiers publics à l'origine du message possède des mises à jour manquantes dans la banque de réception. La banque de réception identifie les numéros de modification manquants et les stocke dans sa pile de renvoi.
• Une banque de dossiers publics démarre pour la première fois. La nouvelle banque envoie des demandes d'état pour obtenir des informations sur les autres banques de la hiérarchie. Une fois les messages d'état correspondants arrivés, la banque remplit sa table des états de réplication et, au besoin, la pile de renvoi également. Cette dernière peut contenir des entrées pour la hiérarchie et tous les réplicas de contenu que la banque doit héberger.
• Un message de hiérarchie entrant indique qu'un nouveau réplica de contenu doit être placé dans la banque de dossiers publics. La nouvelle banque envoie des demandes d'état pour obtenir des informations sur le contenu éventuellement disponible de ce réplica dans les autres banques de la hiérarchie. Une fois les messages d'état correspondants arrivés, la banque remplit la table des états de réplication et, au besoin, la pile de renvoi également.

La pile de renvoi stocke ces informations pendant une durée spécifiée (appelée « délai de renvoi »). Si les mises à jour manquantes arrivent dans d'autres messages de réplication au cours de cette période, elles sont supprimées de la pile de renvoi. Le tableau suivant répertorie les valeurs de délai de renvoi par défaut, qui dépendent de l'emplacement des mises à jour manquantes et de leur éventuelle demande précédente.

Délais par défaut utilisés pour les demandes de renvoi

Si le délai de renvoi expire et si les mises à jour sont toujours manquantes, Exchange Server 2003 crée une ou plusieurs demandes de renvoi, puis détermine les serveurs à utiliser comme sources de renvoi.

Pour sélectionner un (ou plusieurs) serveur à utiliser comme source de renvoi, Exchange Server 2003 crée d'abord une liste de tous les serveurs possédant des réplicas du dossier, puis trie cette liste en fonction de la séquence de critères suivante :

1. Tri en fonction de l'état du serveur. Les serveurs hors service ou non disponibles sont relégués en fin de liste.
2. Tri en fonction du serveur de renvoi préféré (le cas échéant). Exchange Server 2003 vérifie si l'objet de banque de dossiers publics dans Active Directory contient un serveur de renvoi préféré. Ce paramètre est rarement utilisé. Dans la plupart des cas, le processus de renvoi fonctionne de manière optimale si Exchange Server 2003 sélectionne automatiquement un serveur de renvoi. La plupart des déploiements d'Exchange Server 2003 ne nécessitent pas de serveur de renvoi préféré. Les services du Support Technique de Microsoft peuvent fournir un script qui définit un serveur de renvoi préféré si cela s'avère nécessaire pour votre déploiement.
3. Tri en fonction du coût de transport (du plus faible au plus élevé). Les serveurs d'un même groupe de routage sont prioritaires par rapport à des serveurs de groupes de routage distants. Le coût de transport d'un serveur est calculé par le moteur de routage Exchange Server 2003 et sert généralement à déterminer la méthode la plus efficace de remise d'un message.
4. Tri en fonction de la version d'Exchange (de la plus récente à la plus ancienne).
5. Tri en fonction du nombre des modifications nécessaires disponibles sur le serveur (du plus important au moins important). Les serveurs qui ne possèdent aucune des modifications manquantes sont exclus de la liste.

Si un serveur ne possède pas toutes les modifications requises, Exchange Server 2003 sélectionne le prochain serveur dans la liste triée, puis envoie également une demande de renvoi à ce serveur. Ce processus est répété jusqu'à ce que toutes les modifications aient été demandées.

Si le serveur sélectionné ne répond pas à la demande de renvoi, la banque le signale comme étant hors service, puis recommence le processus de sélection. Les serveurs signalés comme étant hors service sont relégués en fin de liste.

Avantages du processus de renvoi d'Exchange Server 2003

Le processus de renvoi est plus efficace dans Exchange Server 2003 que dans les versions précédentes d'Exchange. Cette efficacité accrue s'explique par l'optimisation du coût de transport dans les critères de sélection des serveurs de renvoi, ainsi que par la possibilité d'envoyer des demandes de renvoi à plusieurs serveurs à la fois. Vous trouverez ci-après le détail des améliorations apportées :

• Le coût de transport est prioritaire par rapport à la version d'Exchange.
  Prenons l'exemple d'un déploiement de plusieurs sites Exchange Server 5.5 qui doivent être mis à niveau vers Exchange Server 2003. Chaque site contient plusieurs serveurs qui répliquent chacun des dossiers publics. Ajoutez un serveur exécutant Exchange Server 2003 à chaque site. Dans chaque site, le serveur Exchange Server 2003 renvoie ses dossiers publics à partir des serveurs Exchange Server 5.5 locaux, au lieu de chercher un serveur plus récent sur l'un des sites distants.
• Le coût de transport est prioritaire par rapport au nombre de mises à jour disponibles.
  Par exemple, si certaines mises à jour sont disponibles sur un serveur à moindre coût de transport, celui-ci est sélectionné pour renvoyer ces mises à jour, même si les autres mises à jour doivent être récupérées auprès d'autres serveurs au coût de transport plus élevé. Dans les versions précédentes d'Exchange, un serveur hébergeant toutes les mises à jour nécessaires est toujours préféré à un serveur n'en hébergeant que certaines, quel que soit le coût de transport.

Une autre amélioration du processus de renvoi d'Exchange Server 2003 réside dans la possibilité d'envoyer simultanément des demandes de renvoi à différents serveurs une fois le délai initial de 6 heures (ou 12 heures pour l'envoi de demandes à des serveurs situés sur des sites distants) écoulé. Ce processus est beaucoup plus rapide que dans les versions précédentes d'Exchange où il consiste à envoyer les demandes de renvoi à un serveur à la fois si aucun serveur ne possède à lui seul toutes les mises à jour manquantes d'un dossier spécifique. Après chaque demande, les versions précédentes d'Exchange attendent l'expiration du délai avant une nouvelle tentative (de 24 à 48 heures) pour envoyer la demande suivante. Pour plus d'informations sur les délais de renvoi, voir le tableau des délais par défaut utilisés pour les demandes de renvoi plus haut dans cette rubrique.

Exemples de cycles de réplication

La figure suivante représente un scénario simplifié basé sur deux serveurs, qui illustre la séquence des événements déclenchés lorsque vous ajoutez un réplica de contenu à une banque de dossiers publics. Cette action permet d'ajouter la banque de dossiers publics à la liste des réplicas du dossier. Remarquez que la séquence des étapes dépend de facteurs tels que le moment des intervalles de réplication et la topologie du routage.

Les détails du processus sont les suivants :

1. En travaillant sur ServEx01, un administrateur ajoute ServEx01 à la liste de réplicas d'un dossier.
2. ServEx01 envoie un message de hiérarchie.
3. ServEx02 ajoute ServEx01 à la copie locale de la liste de réplicas du dossier.
4. ServEx01 envoie une demande d'état à ServEx02.
5. ServEx02 envoie un message d'état à ServEx01 qui comprend le CNSet complet du dossier.
6. ServEx01 détermine que l'ensemble du contenu du dossier est manquant et enregistre les entrées appropriées dans la pile de renvoi.
7. Si le contenu est toujours manquant lors de l'expiration du délai de renvoi, ServEx01 crée une demande de renvoi qu'il adresse à ServEx02.
8. ServEx02 compile les messages de contenu et les envoie à ServEx01.
9. ServEx01 utilise les messages de contenu entrants pour mettre à jour le contenu du dossier et les informations de suivi connexes.
10. Si des numéros de modification semblent encore être manquants, ServEx01 attend 24 heures, puis envoie une demande de renvoi mise à jour. Si un serveur autre que ServEx02 est disponible, ServEx01 peut envoyer la demande à ce serveur.

La figure suivante représente un scénario simplifié basé sur deux serveurs, qui illustre la séquence des événements déclenchés lorsque vous supprimez un réplica d'une banque de dossiers publics. (Cette action permet de supprimer la banque de dossiers publics de la liste des réplicas du dossier.) Notez que la séquence des étapes dépend de facteurs tels que le nombre de serveurs présents dans la topologie.

Les détails du processus sont les suivants :

1. En travaillant sur ServEx01, un administrateur supprime ServEx01 de la liste de réplicas d'un dossier.
2. ServEx01 marque son réplica (copie du dossier sur ServEx01) comme suppression suspendue.
   Les clients ne peuvent plus accéder au dossier à l'aide de cette banque.
3. ServEx01 envoie un message de hiérarchie.
4. ServEx02 met à jour sa copie de la liste de réplicas du dossier pour indiquer que la suppression du dossier est suspendue sur ServEx01.
   ServEx02 ne renvoie plus à ServEx01 les clients qui recherchent ce dossier.
5. ServEx01 envoie une demande d'état à ServEx02.
6. ServEx02 envoie un message d'état à ServEx01. Si le réplica présent sur ServEx02 n'est pas à jour, ServEx02 place les entrées appropriées dans la pile de renvoi. Dans les cinq minutes qui suivent, ServEx02 transmet la demande de renvoi correspondante à ServEx01.
7. ServEx01 vérifie que le réplica du dossier sur ServEx02 contient toutes les informations du réplica dont la suppression est suspendue. Si ce n'est pas le cas, ServEx01 envoie les mises à jour de contenu appropriées et retourne à l'étape 5. Sinon, ServEx01 passe à l'étape 8.
   Ce processus permet de s'assurer que tant que d'autres réplicas existent, la suppression de l'un d'entre eux ne risque pas d'entraîner une perte de contenu.
8. ServEx01 marque son réplica comme élément à supprimer maintenant. Le cycle de maintenance suivant supprime le réplica de ServEx01.
9. ServEx01 envoie un message de hiérarchie.
10. ServEx02 supprime ServEx01 de sa copie de la liste de réplicas du dossier.