Présentation du basculement SMTP et de l’équilibrage de charge dans le transport

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

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

Si vous disposez de plusieurs serveurs de transport Hub dans votre organisation, Exchange répartit automatiquement le trafic des messages entre eux. La charge est répartie de manière égale lorsque tous les serveurs sont disponibles. Toutefois, si un ou plusieurs serveurs ne sont pas disponibles, il se peut que la répartition soit inégale entre les serveurs restants, notamment si votre organisation comprend plusieurs sites Active Directory.

Dans Microsoft Exchange Server 2010 Service Pack 1 (SP1), des améliorations ont été apportées au mécanisme de prise de décision permettant de répartir la charge entre les serveurs de transport Hub.

Souhaitez-vous rechercher les tâches de gestion relatives au routage des messages ? Consultez la rubrique Gestion du routage des messages.

Contenu de cette rubrique

Comportement de la version de publication d’Exchange Server 2010

Améliorations apportées à Exchange 2010 SP1

Solutions d’équilibrage de la charge réseau Windows ou de tiers avec serveurs de transport

Comportement de la version de publication d’Exchange Server 2010

Dans la version de publication (RTM) d’Exchange 2010, si un serveur de transport a besoin de router plusieurs messages vers la même destination, il détermine initialement le saut suivant pour ces messages. Si ce saut correspond à de multiples serveurs cibles, il assure un équilibrage de charge de la connexion utilisée pour distribuer les messages entre les serveurs cibles de type tourniquet fourni par le système DNS (Domain Name System) amélioré. Prenons l’exemple d’une topologie comprenant deux sites Active Directory dotés chacun de trois serveurs de transport Hub (comme le montre l’illustration suivante). Lorsqu’un serveur de transport Hub du site A, par exemple Hub02, doit envoyer des messages au site B, le saut suivant pour ce message est le site B. Il y a trois cibles possibles dans le saut suivant : Hub04, Hub05 et Hub06. Le serveur répartit le nombre de connexions de manière égale sur ces trois cibles comme le montre l’illustration suivante. Ainsi, les messages sont répartis de manière régulière et constante entre les connexions.

Équilibrage de la charge dans la version de publication d’Exchange Server 2010

De même, les serveurs de transport Hub du site B répartissent le nombre de messages envoyés aux destinataires du site A de manière égale sur Hub01, Hub02 et Hub03. En outre, du fait que Edge01 est abonné au site A, les cibles du saut suivant pour les messages envoyés sur Internet sont Hub01, Hub02 et Hub03.

L’indisponibilité d’un ou de plusieurs serveurs sur le saut suivant génère un problème. Supposons par exemple que le serveur Hub04 du Site B n’est pas disponible suite à une opération de maintenance planifiée. Les serveurs du site A ne gèrent pas la disponibilité de chacun des serveurs du site B. Ils répartissent la charge destinée au site B entre les trois serveurs de transport Hub de ce site. Toutefois, le tiers des connexions envoyées à Hub04 échoue. Ces connexions basculent sur le serveur disponible suivant, et l’un des serveurs de transport Hub du site B gère une charge beaucoup plus importante que l’autre serveur, comme le montre l’illustration suivante.

Équilibrage de la charge non équitable

Cette situation non souhaitable peut se produire chaque fois qu’un serveur indisponible sur le saut suivant a plus de deux cibles. Le saut suivant peut être un autre site Active Directory comme illustré dans l’exemple précédent, ou un connecteur disposant de multiples serveurs de transport Hub répertorié comme étant le serveur source (par exemple, le connecteur d’envoi au serveur de transport Edge dans la topologie illustrée précédemment).

Cela n’est pas un problème pour les envois de messages depuis les serveurs de boîtes aux lettres. Le service d’envoi de messages détecte les serveurs de transport Hub non disponibles dans un site, et ne tente pas de remise à ces serveurs. Dans l’exemple précédent, même si l’un des serveurs de transport Hub du site B risque de gérer une charge plus lourde due au trafic intersite, la charge générée par les serveurs de boîtes aux lettres du site B est répartie de façon égale entre Hub05 et Hub06.

Comportement de la version de publication d’Exchange Server 2010

Améliorations apportées à Exchange 2010 SP1

Pour résoudre le problème décrit dans la section précédente, un nouveau composant appelé Sélecteur de serveur intègre a été ajouté dans Exchange 2010 SP1. Le sélecteur de serveur intègre gère une liste de serveurs non disponibles. Cette liste est utilisée par le serveur DNS amélioré pour éliminer tout serveur indisponible lorsqu’un équilibrage de la charge de type tourniquet est appliqué. Pour prouver que le sélecteur de serveur intègre facilite l’équilibrage de la charge, revenons à la situation problématique décrite dans l’illustration précédente. Dans Exchange 2010 SP1, le DNS amélioré commence par compiler la liste des cibles potentielles sur le saut suivant, qui est le site B. Il demande ensuite au sélecteur de serveur intègre de filtrer la liste. Le sélecteur de serveur intègre signale que cette cible Hub04 pour le saut suivant, le site B, n’est pas en bon état. Le DNS amélioré va supprimer Hub04 de la liste des cibles potentielles pour le site B et recourir à l’équilibrage de charge de type tourniquet uniquement entre Hub05 et Hub06, comme le montre l’illustration suivante.

Équilibrage de la charge avec le sélecteur de serveur intègre

Sélecteur de serveur intègre

Dans sa forme la plus simple, le sélecteur de serveur intègre assure le suivi des serveurs considérés comme non sains, de sorte que ces serveurs sont exclus du service d’équilibrage de la charge de type tourniquet. Du point de vue du sélecteur de serveur intègre, un serveur en mauvais état se caractérise par le fait qu’il renvoie un code d’erreur de socket (Winsock) Windows lorsqu’on tente de s’y connecter.

Pour chaque serveur en mauvais état, le sélecteur de serveur intègre conserve les informations suivantes :

• Adresse IP du serveur

• Nombre de tentatives

• Heure de la dernière tentative

Paramétrage du nombre de tentatives

Lorsqu’un serveur est marqué comme non sain, le sélecteur de serveur intègre garantit que plusieurs tentatives de connexions sont établies à ce serveur, afin de détecter quand il est mis en ligne. Pour déterminer la fréquence des tentatives de connexion à un serveur non sain, le sélecteur de serveur intègre utilise les paramètres suivants :

• QueueGlitchRetryInterval et QueueGlitchRetryCount   Ces paramètres définissent le nombre et la fréquence des tentatives de connexion par le sélecteur de serveur intègre à un serveur lorsque ce dernier est marqué comme non sain. Ces paramètres sont spécifiés dans le fichier EdgeTransport.exe.config. Les valeurs correspondantes par défaut sont : 1 minute et 4 tentatives. Cela implique que dans une configuration par défaut, quatre tentatives de connexion à un serveur non sain seront établies par minute.

• TransientFailureRetryInterval et TransientFailureRetryCount   Si le serveur non sain n’est pas disponible, le sélecteur de serveur intègre utilise ces paramètres pour déterminer la fréquence de la prochaine série de tentatives. Ces paramètres sont spécifiés sur chaque serveur de transport. Les valeurs par défaut sont 5 minutes (10 minutes sur un serveur de transport Edge) et 6 tentatives de connexion. Cela implique que dans une configuration par défaut, six nouvelles tentatives de connexion à un serveur non sain seront établies toutes les cinq minutes à partir de la quatrième minute suivant la première tentative de connexion.

• OutboundConnectionFailureRetryInterval   Si le serveur non sain n’est pas disponible, le sélecteur de serveur intègre continue à établir des tentatives de connexion à la fréquence spécifiée via ce paramètre. Ce paramètre est spécifié pour chaque serveur de transport. La valeur par défaut est 10 minutes (30 minutes sur un serveur de transport Edge). Cela implique que dans une configuration par défaut, une nouvelle tentative de connexion à un serveur non sain sera établie toutes les dix minutes à partir de la trente-quatrième minute suivant la première tentative de connexion.

Pour des instructions détaillées sur la configuration de ces paramètres, voir Configurer des intervalles de nouvelle tentative de message, de nouvelle soumission et d’expiration.

Au moment d’effectuer une nouvelle tentative de connexion, le sélecteur de serveur intègre autorise une seule tentative au serveur non sain. Si la connexion aboutit, le composant SMTP sortant en informe le sélecteur de serveur intègre. À ce stade, le sélecteur de serveur intègre supprime le serveur en question de la liste des serveurs en mauvais état.

Sélecteur de serveur intègre et redondance des clichés instantanés

Le composant de transport Redondance des clichés instantanés inclut une fonctionnalité de pulsation. La pulsation est une simple connexion SMTP permettant de demander le statut des messages envoyés précédemment à un serveur cible. Le filtrage opéré par le sélecteur de serveur intègre n’empêche pas le gestionnaire de redondance des clichés instantanés d’émettre des tentatives de connexion de pulsation. Si un serveur a des messages instantanés qui ont été envoyés à un serveur en mauvais état, il tentera d’établir des connexions de pulsation à ce serveur. Si une connexion de pulsation à un serveur non sain aboutit, le sélecteur de serveur intègre supprime immédiatement ce serveur cible de la liste des serveurs en mauvais état.

Pour en savoir plus sur la redondance des clichés instantanés et la pulsation, voir Présentation de la redondance des clichés instantanés.

Informations de diagnostic

Dans Exchange 2010 SP1, les journaux de connectivité contiennent des informations de diagnostic pour le sélecteur de serveur intègre et les fonctionnalités d’équilibrage de charge améliorées. Lorsqu’un serveur est ajouté à la liste des serveurs en mauvais état par le sélecteur de serveur intègre, l’événement est consigné dans le journal de connectivité. Pour identifier cet événement, recherchez le terme MarkedUnhealthy dans le journal de connectivité. La ligne contenant ce terme comprend également les informations suivantes :

• Adresse IP de l’hôte cible

• Nom de domaine complet (FQDN) de l’hôte cible

• Erreur Winsock reçue

• État : MarkedUnhealthy

• Nombre actuel d’échecs

• Heure de la prochaine tentative

Grâce au code d’erreur Winsock, cette entrée vous permet d’identifier l’origine de l’erreur. Pour obtenir une liste complète des codes d’erreur Winsock et leurs définitions, voir Windows Sockets Error Codes.

Pour connaître le nombre d’échecs de tentatives de connexion et la prochaine tentative de connexion au serveur cible planifiée, vous pouvez vous reporter également aux champs Current Failure Count et Next Retry Time.

Pour que ces informations de diagnostic soient visibles, l’enregistrement de la connectivité doit être activé sur vos serveurs de transport. Par défaut, l’enregistrement dans le journal de connectivité est désactivé sur les serveurs de transport Hub ou de transport Edge. Pour plus d’informations sur la configuration de l’enregistrement de la connectivité, voir Configurer l’enregistrement de la connectivité.

Comportement de la version de publication d’Exchange Server 2010

Solutions d’équilibrage de la charge réseau Windows ou de tiers avec serveurs de transport

Comme expliqué plus haut dans cette rubrique, Exchange 2010 équilibre automatiquement la charge du trafic intra-organisationnel des messages entre les serveurs de transport Edge, Hub et de boîtes aux lettres à l’aide d’un DNS amélioré. Toutefois, cette fonctionnalité ne couvre pas l’équilibrage de la charge des messages provenant de sources non-Exchange telles que les serveurs de messagerie externes, les solutions anti-spam ou antivirus de tiers, tout serveur de messagerie interne hors de votre organisation Exchange, les applications sectorielles et les clients de messagerie basés sur POP ou IMAP.

Si vous disposez d’une ou de plusieurs de ces sources de messages, vous pouvez choisir d’équilibrer la charge du trafic SMTP entrant à l’aide d’un espace nom SMTP unifié (tel que as smtp.contoso.com) qui distribue les courriers électroniques externes entre les serveurs de transport répartis au sein de l’organisation. L’équilibrage de la charge réseau Windows et les solutions d’équilibrage de la charge réseau d’éditeurs tiers sont prises en charge. Pour obtenir la liste des équilibreurs de charge qui ont été testés par le fournisseur et revus par Microsoft en vue de répondre aux exigences d’Exchange 2010, consultez la page Déploiement de l’équilibreur de charge Microsoft Unified Communications.

Important :
L’utilisation d’une solution d’équilibrage de charge pour traiter le trafic de messages entre les serveurs Exchange de votre organisation n’est pas prise en charge. Vous devez exclure le trafic de messages entre les serveurs Exchange de toute solution d’équilibrage de charge que vous déployez dans votre environnement.

Équilibrage de la charge des messages Internet entrants entre vos serveurs de transport Edge

Le traitement des messages entrants provenant d’Internet est la situation la plus courante. Il n’est pas nécessaire de déployer une solution d’équilibrage de la charge pour répartir la charge entre vos serveurs de transport Edge. Pour ce faire, utilisez le tourniquet DNS et les enregistrements de serveur de messagerie (MX) qui possèdent la même valeur préférée, comme l’illustre la figure suivante.

Équilibrage de la charge des messages Internet à l’aide du tourniquet DNS et des enregistrements MX

Si vous choisissez d’utiliser l’équilibrage de la charge réseau Windows ou une solution d’équilibrage de charge matérielle pour distribuer les messages Internet entrants, vous devez publier un enregistrement MX unique qui pointe vers votre solution d’équilibrage de charge. L’équilibreur de charge va distribuer les messages entrants à tous les serveurs de transport répertoriés dans sa configuration, comme illustré dans la figure suivante.

Distribution des messages Internet à l’aide d’une solution d’équilibrage de charge

Équilibrage de la charge des messages non-Exchange entre vos serveurs de transport Hub

Exchange 2010 utilise les connecteurs de réception pour accepter les messages entrants. Par défaut, quand un serveur de transport Hub Exchange 2010 reçoit un message électronique via SMTP sur le port TCP 25, il est traité par le connecteur de réception nommé Connecteur de réception par défaut.

Lorsqu’un client POP ou IMAP soumet un message électronique à un serveur de transport Hub Exchange 2010, le message est soumis sur le port TCP 587 par défaut. Cela signifie que les messages électroniques soumis à partir des clients POP ou IMAP sont traités par un connecteur de réception distinct nommé Connecteur de réception client par défaut.

Si vous envisagez de placer une solution d’équilibrage de charge face à vos serveurs de transport Hub, vous devez créer un connecteur de réception distinct dans ce but et vous assurer que seul le trafic traité par ce connecteur spécifique est soumis à l’équilibrage de charge. Pour ce faire, ajoutez une adresse IP supplémentaire au serveur de transport Hub et associez cette adresse IP au nouveau connecteur de réception. En outre, l’option Authentification d’Exchange Server doit être désactivée sur le connecteur de réception pour que le trafic Exchange ne soit pas routé via ce connecteur. La figure suivante illustre une configuration dans laquelle un équilibreur de charge est utilisé pour distribuer les messages provenant des clients POP3 ou IMAP4 et des serveurs SMTP non-Exchange à deux serveurs de transport Hub.

Équilibrage de la charge des messages non-Exchange entre les serveurs de transport Hub

Équilibrage de la charge réseau Windows

L’équilibreur de charge Windows est l’équilibreur logiciel le plus courant utilisé pour les serveurs Exchange. Le déploiement de l’équilibreur de charge Windows avec les serveurs de transport Hub Exchange 2010 présente certaines restrictions :

• L’équilibreur de charge Windows ne peut pas être utilisé sur des serveurs dont les rôles serveur de boîtes aux lettres et de transport Hub Exchange coexistent et qui sont membres d’un groupe de disponibilité de base de données.

  En effet, l’équilibreur de charge Windows est incompatible avec le basculement de cluster Windows. Si vous utilisez un groupe de disponibilité de base de données Exchange 2010 et que vous souhaitez utiliser l’équilibrage de la charge réseau Windows, vous devez avoir le rôle serveur de transport Hub et le rôle serveur de boîte aux lettres s’exécutant sur des serveurs distincts. En outre, l’équilibreur de charge Windows a une incidence sur le routage des messages lorsque le membre du groupe de disponibilité de base de données et le serveur de transport Hub coexistent sur le même serveur. Pour en savoir plus, consultez la rubrique Coexistence des rôles serveur de transport Hub et de boîtes aux lettres lors de l’utilisation de groupes de disponibilité de base de données.

• Nous déconseillons l’installation de plus de huit serveurs de transport Hub dans un ensemble dont la charge est équilibrée par l’équilibreur de charge Windows. Si vous devez équilibrer la charge de plus de huit serveurs de transport Hub, déployez une solution matérielle.

• L’équilibreur de charge Windows ne détecte pas les interruptions de service.

  Il détecte uniquement les interruptions de serveur par adresse IP. En cas d’échec du service de transport Exchange, mais si le serveur fonctionne toujours normalement, l’équilibreur de charge Windows ne détecte pas l’erreur et achemine toujours les messages électroniques entrants à ce serveur de transport Hub. L’intervention manuelle est requise pour retirer du groupe d’équilibrage de charge le serveur de transport Hub rencontrant la panne.

• La configuration de l’équilibreur de charge réseau Windows peut entraîner un débordement des ports de connexions, ce qui risque de provoquer la saturation des réseaux.

  En effet, l’équilibreur de charge réseau Windows a été conçu de façon à distribuer simultanément tous les paquets client entrants à tous les ports du commutateur. Même si ce comportement permet à l’équilibreur de charge réseau Windows d’offrir un très haut débit, il est susceptible de générer un haut niveau d’occupation du commutateur.

Pour obtenir la procédure détaillée de configuration de Windows, consultez la rubrique Configurer l’équilibrage de la charge réseau Microsoft Windows pour les serveurs de transport Hub.

Équilibrage de la charge matérielle

Si vous disposez de plus de huit serveurs de transport Hub dont vous souhaitez équilibrer la charge du trafic des messages non-Exchange, il vous faut une solution d’équilibrage de charge plus évolutive. Bien qu’il existe des solutions fiables d’équilibrage de charge logiciel, une solution d’équilibrage de la charge matérielle offre une plus grande capacité.

À l’inverse de l’équilibreur de charge réseau Windows, qui détecte uniquement les pannes de serveur par adresse IP, un équilibreur de charge matériel permet de détecter les défaillances du service de transport Exchange et peut router les messages électroniques entrants à d’autres serveurs de transport Hub sans aucune intervention manuelle.

Pour obtenir la procédure détaillée de configuration d’une solution d’équilibrage de la charge matérielle, voir Configurer l’équilibrage de la charge matérielle pour les serveurs de transport Hub.

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