Configuration d’équilibrage de la charge requise pour les protocoles Exchange

  • Article

 

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

Dernière rubrique modifiée : 2011-11-02

Les protocoles et services d’accès client Microsoft Exchange présentent des exigences différentes en matière d’équilibrage de charge. Certains protocoles et services d’accès client Microsoft Exchange exigent que le client présente une affinité avec le serveur d’accès au client. D’autres fonctionneront sans cette affinité, mais au détriment des performances. D’autres protocoles Exchange ne demandent pas d’affinité entre le client et le serveur d’accès au client, sans que cela n’ait d’incidence sur les performances.

Contenu de cette rubrique

Protocoles Exchange nécessitant une affinité entre le client et le serveur d’accès au client

Protocoles Exchange bénéficiant de l’affinité entre le client et le serveur d’accès au client

Protocoles Exchange n’exigeant pas d’affinité

Présentation des ports IP

Protocoles Exchange nécessitant une affinité entre le client et le serveur d’accès au client

Les protocoles Exchange suivants requièrent une affinité entre le client et le serveur d’accès au client. L’affinité doit durer pendant une session cliente.

  • Outlook Web App et le Panneau de configuration Exchange   Microsoft Office Outlook Web App et le Panneau de configuration Exchange requièrent tous deux une affinité entre le client et le serveur d’accès au client. Lorsque vous utilisez l’authentification basée sur les formulaires, définie par défaut dans Microsoft Exchange Server 2010, Outlook Web App et le Panneau de configuration Exchange doivent être mis en affinité avec le même serveur d’accès au client. Cela s’explique par le fait qu’ils partagent le même cookie d’authentification et que ce cookie ne peut être déchiffré que par un serveur d’accès client spécifique.

  • Services Web Exchange   Seul un sous-ensemble de services Web Exchange exige une affinité. Les demandes du service de disponibilité ne requièrent pas d’affinité, contrairement aux abonnements. Les services Web Exchange voient leurs performances s’améliorer sous tous leurs aspects grâce à l’affinité. Nous ne prenons pas en charge l’utilisation des services Web Exchange sans affinité.

  • Outlook RPC sur TCP sur Intranet   Les clients Outlook sur Intranet considèrent que toutes les connexions RPC sont établies avec le même serveur. Outlook emploie plusieurs sessions par utilisateur et suppose que toutes les sessions sont ouvertes auprès du même serveur.

Protocoles Exchange bénéficiant de l’affinité entre le client et le serveur d’accès au client

Les protocoles et services Exchange suivants peuvent fonctionner sans affinité. Toutefois, leurs performances sont considérablement réduites lorsqu’ils sont déployés sans affinité.

  • Outlook Anywhere   Les connexions Outlook Anywhere sont unidirectionnelles et divisent une seule connexion aux données RPC en deux connexions HTTP. Une connexion est dédiée aux données entrantes, l’autre aux données sortantes. Lorsqu’aucune affinité n’existe entre ces deux types de connexion, Outlook Anywhere essaye de mettre en corrélation les connexions en les coordonnant avec d’autres membres du groupe de serveurs d’accès au client. Cette opération augmente le trafic entre les serveurs d’accès au client d’environ 50 % sur un groupe à deux serveurs et jusqu’à 100 % sur un groupe doté d’un grand nombre de serveurs.

  • Exchange ActiveSync   Microsoft Exchange ActiveSync transmet les notifications de nouveaux messages à travers une demande HTTPS à long terme, du client au serveur. Lorsqu’un client Exchange ActiveSync est attribué à un nouveau serveur d’accès au client, ce serveur doit recréer l’abonnement aux notifications sur la boîte aux lettres de l’utilisateur. Cela entraîne une baisse importante des performances.

  • Service du carnet d’adresses Exchange   Il s’agit d’un nouveau service Exchange 2010 fournissant aux clients un accès à l’annuaire. Ne pas utiliser d’affinité permet un niveau de communication beaucoup plus élevé entre le client et les serveurs d’accès au client.

  • PowerShell à distance Sans affinité, les utilisateurs doivent s’authentifier de nouveau en cas d’interruption de connexion.

Protocoles Exchange n’exigeant pas d’affinité

Plusieurs protocoles et services Exchange ne requièrent aucune affinité du fait de leur nature transactionnelle. Cela signifie que la connexion est établie, que la transaction est effectuée, puis que la connexion est fermée. Ces protocoles ne bénéficient d’aucune amélioration des performances avec une affinité.

  • Carnet d’adresses en mode hors connexion

  • Service de découverte automatique

  • POP3

  • IMAP4

Présentation des ports IP

La plupart des services Exchange 2010 sont construits sur HTTP et utilisent le port 443 pour l’accès SSL (Secure Sockets Layer) et le port 80 pour l’accès non-SSL. Outlook Web App,Exchange ActiveSync,OutlookAnywhere et les services Web Exchange sont des services de ce type. POP3 et IMAP4 utilisent respectivement les ports 110 et 143 en cas d’absence de chiffrement SSL, et les ports 995 et 993 en cas de chiffrement SSL.

D’autres services Exchange, tels que le service d’accès au client RPC et le service Carnet d’adresses Exchange, sont des services RPC. Lorsqu’un client Outlook se connecte directement au serveur d’accès au client à l’aide de ces protocoles, au lieu d’utiliser Outlook Anywhere, les ports TCP de terminaison pour ces services sont attribués par le gestionnaire de points de terminaison RPC. L’attribution se produit lorsque les services sont démarrés. Cette opération exige de configurer une large plage de ports de destination pour l’équilibrage de charge, sans la capacité à cibler spécifiquement le trafic de ces services basés sur un numéro de port. Vous pouvez mapper de manière statique ces services à des numéros de port spécifiques pour simplifier l’équilibrage de charge. Si les ports de ces services sont mappés de manière statique, le trafic sera restreint au port 135 et aux deux ports spécifiques sélectionnés pour ces services.

Configuration du mappage du port statique pour les services basés sur RPC

Le port statique du service d’accès au client RPC est configuré dans le Registre. La clé de Registre suivante doit être configurée sur chaque serveur d’accès au client. Définissez la clé sur la valeur du port que vous souhaitez utiliser pour les connexions TCP au service d’accès au client RPC.

Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeRPC\ParametersSystem
Value: TCP/IP Port
Type: DWORD
RemarqueRemarque :
Cette modification affecte uniquement les connexions internes via TCP, mais pas les connexions Outlook Anywhere utilisant le tunneling RPC/HTTP. Les connexions Outlook Anywhere au service d’accès au client RPC se produisent sur le port 6001, lequel n’est pas configurable.

Ce processus doit également être effectué sur tous les serveurs de dossiers publics de votre organisation.

Les ports statiques des deux points de terminaison RPC conservés par le service Carnet d’adresses Exchange sont configurés dans un fichier intitulé Microsoft.Exchange.AddressBook.Service.Exe.config. Ce fichier se trouve dans le répertoire bin du chemin d’installation Exchange, sur chaque serveur d’accès au client. La valeur RpcTcpPort du fichier de configuration doit être définie sur la valeur du port que vous souhaitez utiliser pour les connexions TCP de ce service. Ce port s’occupe des connexions pour l’interface de redirection du carnet d’adresses (ABREF) et l’interface NSPI (Name Service Provider Interface).

RemarqueRemarque :
Ne modifiez pas les valeurs des options de configuration NspiHTTPPort et RfrHTTPPort. Par défaut, Outlook est configuré pour utiliser ces ports. La modification de ces valeurs provoquerait un retard indésirable lorsque les clients essaieraient d’établir des connexions Outlook Anywhere. Les ports par défaut sont 6002 pour NspiHTTPPort et 6004 pour RfrHTTPPort.

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