Présentation de l’équilibrage de la charge dans Exchange 2010

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

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

L’équilibrage de charge permet de gérer la réception du trafic selon vos serveurs. L’équilibrage de charge fournit une redondance de basculement pour vous assurer que vos utilisateurs continuent à recevoir le service Exchange en cas d’échec de votre ordinateur. Il permet également à votre déploiement de traiter plus de trafic que ne peut traiter un serveur tout en offrant un seul nom d’hôte pour vos clients.

En plus de l’équilibrage de charge, Microsoft Exchange Server 2010 fournit plusieurs solutions au basculement et à la redondance de basculement. Ces solutions permettent :

• Une grande disponibilité et une résilience de site   Vous pouvez déployer deux sites Active Directory à des emplacements géographiques différents, conserver les données de boîtes aux lettres synchronisées entre les deux et avoir un des sites prenant toute la charge au cas ou l’autre échoue. Exchange 2010 utilise les groupes de disponibilité de base de données pour conserver plusieurs copies de vos boîtes aux lettres sur différents serveurs synchronisés.

• Des déplacements de boîte aux lettres en ligne   Dans un déplacement de boîte aux lettres en ligne, les utilisateurs finaux peuvent accéder à leurs comptes de messagerie au cours du déplacement. Les utilisateurs sont seulement déconnectés de leur compte pendant un court instant à la fin du processus lorsque la synchronisation finale se produit. Les déplacements de boîtes aux lettres en ligne sont pris en charge entre les bases de données Exchange 2010 et entre Exchange Server 2007 Service Pack 3 (SP3) ou une version ultérieure d’Exchange 2007 et les bases de données d’Exchange 2010. Vous pouvez effectuer des déplacements de boîtes aux lettres en ligne entre les forêts ou dans la même forêt.

• Une redondance des clichés instantanés   La redondance des clichés instantanés permet de protéger la disponibilité et la récupération des messages lorsqu’ils sont en transit. Grâce à la redondance des clichés instantanés, la suppression d’un message dans les bases de données de transport est retardée jusqu’à ce que le serveur de transport vérifie que les sauts suivants de ce message ont abouti. Si un saut échoue avant de signaler le succès de la remise du message, le message est soumis à nouveau pour livraison avec ce saut qui ne s’est pas effectué.

Contenu de cette rubrique

Présentation de l’équilibrage de charge

Présentation des charges de trafic Exchange 2010

Présentation des options d’équilibrage de charge

Recommandations relatives à l’équilibrage de charge

Options d’affinité

Présentation de l’équilibrage de charge

L’équilibrage de charge a deux objectifs principaux. Il réduit l’impact d’échec d’un serveur d’accès au client unique pour l’un de vos sites Active Directory. En outre, l’équilibrage de charge assure que la charge sur votre serveur d’accès au client et les ordinateurs de transport Hub est distribuée de manière égale.

Modifications architecturales de l’équilibrage de charge dans Exchange 2010

Plusieurs modifications dans Exchange 2010 rendent l’équilibrage de charge important pour votre organisation. Le service d’accès au client RPC Exchange et le service Carnet d’adresses Exchange sur le rôle serveur d’accès au client améliorent l’expérience utilisateur au cours des basculements de boîtes aux lettres en déplaçant les points finaux de connexion d’accès aux boîtes aux lettres à partir d’Outlook et les autres clients MAPI vers le rôle serveur d’accès au client à la place du rôle serveur de boîte aux lettres. Dans les versions plus récentes d’Exchange, Outlook connecté directement au serveur de boîtes aux lettres hébergeant la boîte aux lettres de l’utilisateur ainsi que les connexions au répertoire étaient déplacées via le rôle serveur de boîtes aux lettres ou reportés directement à un serveur de catalogue global Active Directory spécifique. Maintenant que ces connexions sont traitées par le rôle serveur d’accès au client, les connexions Outlook externe et interne doivent être équilibrées dans le groupe des serveurs d’accès au client dans un déploiement pour obtenir une tolérance de pannes.

Un groupe équilibré de serveurs d’accès au client est recommandé pour chaque site Active Directory et pour chaque version de Exchange. Il n’est pas possible de partager un groupe équilibré de serveurs d’accès au client pour plusieurs sites Active Directory ou de mélanger différentes versions d’Exchange ou de versions Service Pack d’Exchange avec le même groupe.

Lorsque vous installez Exchange 2010 dans votre organisation existante et que vous configurez un nom hérité pour coexistence avec des versions précédentes d’Exchange, vos clients se connecteront automatiquement au serveur d’accès au client Exchange 2010 ou au groupe de serveurs. Le serveur d’accès au client Exchange 2010 ou le groupe de serveurs d’accès au client traite ou redirige ensuite les demandes client pour des boîtes aux lettres sur d’anciennes versions d’Exchange aux serveurs frontaux Exchange 2003 ou aux serveurs d’accès au client Exchange 2007 qui correspondent à la version de boîte aux lettres. Pour plus d’informations, voir Présentation de la mise à niveau vers Exchange 2010.

Remarque :
Vous pouvez mélanger des correctifs QFE (Quick Fix Engineering ) et des correctifs cumulatifs lorsque vous les appliquer dans tout un groupe ou parties d’un groupe. Nous vous recommandons d’appliquer les correctifs QFE et les correctifs cumulatifs à tous les ordinateurs dans un groupe.

Votre configuration d’équilibrage de charge aura un effet direct sur les noms d’hôte utilisés par vos clients pour se connecter et sur les certificats SSL (Secure Sockets Layer) que vous utilisez. Pour plus d’informations sur les certificats Exchange 2010, voir Présentation des certificats numériques et de SSL.

Configuration du groupe de serveurs d’accès au client

Vous pouvez configurer un groupe de serveurs d’accès au client par site Active Directory. Dès que le groupe de serveurs d’accès au client a été configuré, vous pouvez configurer la base de données de boîtes aux lettres pour utiliser le groupe de serveurs d’accès au client comme point final MAPI au lieu d’utiliser un serveur d’accès au client spécifique.

Pour plus d’informations sur le groupe de serveurs d’accès au client et la manière de configurer la base de données de boîtes aux lettres pour utiliser le groupe de serveurs d’accès au client pour le site Active Directory spécifique, voir Présentation de l'accès au client RPC.

Présentation des charges de trafic Exchange 2010

Avant de configurer l’équilibrage de charge, vous devez comprendre les charges qui sont placées sur un serveur d’accès au client Exchange 2010. Un serveur d’accès au client Exchange 2010 reçoit les trois types de trafic suivants :

• Trafic des clients externes

• Trafic des clients internes

• Trafic proxy provenant d’autres serveurs d’accès au client

Le trafic proxy provenant d’autres serveurs d’accès au client est le trafic qui est envoyé à l’origine par un client externe ou interne à un serveur d’accès au client mais qui est ensuite déplacé vers un autre serveur d’accès au client. Cette action peut se produire pour plusieurs raison mais en général elle se produit car le client d’origine ne peut pas se connecter directement au serveur d’accès au client de destination. Elle peut se produire lorsqu’un utilisateur essaie d’accéder à une boîte aux lettres à partir d’Internet mais que la boîte aux lettres se trouve sur un site Active Directory non connecté à Internet. Pour plus d’informations sur le transfert du trafic par proxy, voir Présentation de la transmission par proxy et de la redirection.

Chacun des types de trafic reçus par les serveurs d’accès au client inclut des demandes d’une liste de protocoles et provient des périphériques et ordinateurs clients comportant des caractéristiques différentes. Ces différences affectent les stratégies d’équilibrage de charge.

Retour au début

Présentation des options d’équilibrage de charge

Il existe plusieurs technologies clés entre les différentes solutions d’équilibrage de charge.

• Performance   Nombre de demandes pouvant être traitées par seconde par la solution

• Facilité de gestion   Est-il simple de configurer et de déployer la solution d’équilibrage de charge ?

• Détection et automatisation de basculement L’équilibreur de charge permet-il la détection d’un échec de service ou de serveur d’accès au client ?

• Affinité Quelles sont les affinités de serveur d’accès au client prises en charge par la solution d’équilibrage de charge ?

Présentation des affinités

Lorsqu’une solution d’équilibrage de charge fournit une affinité entre le client et le serveur d’accès au client, cela signifie une association sur le long terme entre un client particulier et un serveur d’accès au client particulier. Le client peut être Outlook s’exécutant sur un ordinateur portable, Microsoft Exchange ActiveSync s’exécutant sur un périphérique mobile, Microsoft Office Outlook Web App, des services Web Exchange ou une autre application client.

Cette association sur le long terme, ou affinité, garantit que toutes les demandes provenant du client sont envoyées au même serveur d’accès au client. Certains protocoles Exchange 2010 requièrent cette affinité alors que les autres protocoles Exchange ne la requièrent pas.

Équilibrage de la charge réseau Windows

L’équilibrage de la charge réseau Windows est l’équilibreur de charge logiciel le plus courant utilisé pour les serveurs Exchange. Il existe plusieurs limitations associées au déploiement de l’équilibrage de la charge réseau Windows avec Microsoft Exchange.

• L’équilibrage de la charge réseau Windows ne peut pas être utilisé sur les serveurs Exchange où les groupes de disponibilité de base de données pour les boîtes aux lettres ont également été utilisés car l’équilibrage de la charge réseau Windows est incompatible avec le cluster de basculement Windows. Si vous utilisez un groupe de disponibilité de base de données Exchange 2010 et que vous ne souhaitez pas utiliser l’équilibrage de la charge réseau Windows, vous devez avoir un rôle serveur d’accès au client et le rôle serveur de boîte aux lettres s’exécutant sur des serveurs distincts.

• À cause de problèmes de performances, nous vous recommandons de ne pas mettre plus de huit serveurs d’accès au client dans un groupe équilibré par l’équilibrage de la charge réseau Windows.

• L’équilibrage de la charge réseau Windows ne détecte pas les interruptions de service. L’équilibrage de la charge réseau Windows détecte uniquement les interruptions de serveur par adresse IP. Cela signifie que si un service Web particulier, tel qu’Outlook Web App, échoue, mais que le serveur est toujours en fonctionnement, l’équilibrage de la charge réseau Windows ne détectera pas l’échec et routera toujours les demandes à ce serveur d’accès au client. L’intervention manuelle est requise pour retirer du groupe d’équilibrage de charge le serveur d’accès au client rencontrant la panne.

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

• Étant donné que l’équilibrage de la charge réseau Windows effectue uniquement l’affinité client en utilisant l’adresse IP source, cette solution n’est pas efficace lorsque le groupe d’IP source est trop petit. Cela peut se produire lorsque le groupe d’IP source se trouve sur un sous-réseau distant ou lorsque votre organisation utilise une traduction d’adresse réseau.

Recommandations relatives à l’équilibrage de charge

Plusieurs options d’équilibrage de charge sont disponibles. L’option que vous utilisez dépend de la taille et de la configuration de votre réseau.

Équilibrage de charge réseau Windows avec affinité d’IP source

La première option d’équilibrage de charge est l’équilibrage de charge réseau Windows avec affinité d’IP source. Cette solution est appropriée si vous avez plusieurs serveurs d’accès au client par site Active Directory mais moins de huit. Cette solution est intégrée à Windows et ne nécessite pas d’ordinateurs supplémentaires.

Il existe deux scénarios pour lesquels vous ne souhaiterez pas utiliser l’équilibrage de charge réseau Windows.

• Votre organisation dispose d’un serveur proxy inverse qui communique directement avec le serveur d’accès au client et non via l’adresse IP virtuelle d’équilibrage de charge réseau Windows. Le serveur proxy inverse masque l’adresse IP du client dans le groupe de serveurs d’accès au client. Par conséquent, l’affinité d’IP source ne fonctionnera pas comme prévu. Cependant, vous souhaitez peut-être toujours utiliser l’équilibrage de charge réseau Windows pour équilibrer la charge du trafic interne.

• Votre organisation dispose de nombreux clients accédant à vos serveurs d’accès au client via un très petit groupe d’adresses IP. L’équilibrage de charge réseau Windows essaie de mettre par affinité un sous-réseau entier de classe C avec un serveur d’accès au client.

Équilibrage de la charge matérielle

Si vous disposez de plus de huit serveurs d’accès au client dans un site Active Directory unique, votre organisation nécessitera une solution d’équilibrage plus fiable. 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é. Pour plus d’informations sur les solutions d’équilibrage de la charge des serveurs Exchange 2010, voir Microsoft Unified Communications Hardware Load Balancer Deployment (en anglais).

Les équilibreurs de la charge matérielle prennent en charge un débit élevé de trafic et peuvent être configurés pour un équilibrage de charge de plusieurs manières. La plupart des fournisseurs d’équilibreurs de la charge matérielle possèdent une documentation détaillée sur le fonctionnement de leur produit avec Exchange 2010. La manière la plus simple de configurer les équilibreurs de la charge matérielle est de créer une liste de secours des méthodes d’affinité qui seront appliquées par l’équilibreur de charge. Par exemple, l’équilibreur de charge va d’abord essayer l’affinité par cookie, puis l’ID de session SSL et ensuite l’affinité d’IP source.

Solutions de proxy inverse

Si vous disposez d’une solution de proxy inverse qui peut effectuer l’équilibrage de charge pour les serveurs publiés sur Internet, tels que Microsoft Forefront Threat Management Gateway (TMG) ou Forefront Unified Access Gateway (UAG), nous vous recommandons de l’utiliser.

Étant donné que le trafic passe par le serveur proxy inverse pour atteindre vos serveurs d’accès au client, l’adresse IP d’origine du client est remplacée par l’adresse IP du serveur proxy inverse. Cela interrompt l’affinité d’IP source. Il existe différentes manières de résoudre ce problème, incluant la configuration du serveur proxy inverse pour qu’il devienne la passerelle par défaut pour le sous-réseau auquel la connexion proxy est effectuée.

Cependant, la plupart des serveurs proxy inverse actuels peuvent effectuer l’équilibrage de charge pour les services qu’ils publient sur Internet. Ces serveurs proxy inverses prennent en charge l’équilibrage de charge de cookies créés par l’équilibrage de charge pour les services Exchange qui le supportent. Cette solution est plus fiable que l’équilibrage de charge IP source. Pour effectuer cette tâche, le serveur proxy inverse doit pouvoir lire et modifier le flux de données HTTP. Si vous utilisez SSL, cela signifie que le serveur proxy inverse doit déchiffrer le trafic pour lire le contenu et créer le cookie dans le flux. Ce déchiffrage est impossible dans certaines circonstances : lorsque vous utilisez une authentification de certificat client ou lorsque le client se connecte au serveur d’accès au client.

Retour au début

Options d’affinité

D’autres solutions d’équilibrage de charge offrent d’autres méthodes d’association de clients à un serveur d’accès au client spécifique. Il existe plusieurs types courants d’affinité disponibles dans différents produits d’équilibrage de la charge à la fois matérielle et logicielle. Tous les types d’affinité ne seront pas disponibles dans chaque option d’équilibrage de charge, comme décrit dans les exemples suivants :

• L’équilibrage de la charge réseau Windows prend uniquement en charge l’affinité d’IP source ou aucune affinité.

• Un équilibreur de charge logiciel dans un groupe de serveurs distinct peut utiliser des cookies créés par un équilibreur de charge pour les protocoles qui prennent en charge ces cookies et l’affinité d’IP source pour les protocoles restants.

• Les équilibreurs de la charge matérielle avec déchargement SSL vous permettent de configurer un comportement plus complexe. Par exemple, vous pouvez configurer un ensemble de cookies existants qui prendront effet pour les protocoles qui prennent en charge ces cookies, ainsi qu’un cookie créé par un équilibreur de charge, un ID de session SSL et un IP source.

En plus des options qui sont prises en charge par les différentes solutions d’équilibrage de charge, vous pouvez également configurer certaines de ces étapes pour les appliquer uniquement à certains protocoles et services Exchange. Étant donné que chaque protocole se comporte différemment, cela peut aider à optimiser les performances.

Cookies existants ou en-têtes HTTP

L’utilisation des en-têtes HTTP ou des cookies existants est la manière la plus fiable d’identifier un client et de l’associer à un serveur d’accès au client spécifique. Ces cookies et en-têtes sont créés par le client ou le serveur comme faisant partie du protocole de communications. En outre, cette option ne nécessite pas l’équilibreur de charge pour modifier le trafic, ce qui améliore les performances.

Lorsque vous utilisez cette option d’affinité, n’oubliez pas les éléments suivants :

• Votre équilibreur de charge doit supporter ce type de l’affinité. Actuellement, uniquement les équilibreurs de la charge matérielle prennent en charge cette affinité.

• Cette affinité ne fonctionne que pour les protocoles qui acheminent le trafic sur HTTP.

• Un en-tête ou un cookie existant doit rester constant au cours de la session client et doit être unique pour chaque client spécifique ou petit groupe de clients, dans le protocole.

• La solution de l’équilibreur de charge doit pouvoir lire et interpréter le flux de données HTTP. Si vous utilisez SSL, cela signifie que l’équilibreur de charge doit déchiffrer le trafic pour lire le contenu. Parfois, il en résulte une augmentation de la charge de l’équilibreur de charge. En outre, ce déchiffrage est impossible dans certaines circonstances : lorsque vous utilisez une authentification de certificat client avec la session SSL ou lorsque le client se connecte au serveur d’accès au client.

Les en-têtes HTTP et les cookies existants appropriés pour l’équilibrage de charge qui sont disponibles dans les protocoles Exchange 2010 sont les suivants :

• En-tête d’autorisation d’authentification de base HTTP   Cet en-tête s’active lorsque l’authentification de base HTTP est utilisée. L’authentification de base est celle par défaut et la plus fréquemment utilisée pour Exchange ActiveSync. Cet en-tête est rare pour les autres protocoles et méthodes d’authentification. L’en-tête d’autorisation d’authentification de base envoie tout le trafic qui utilise l’authentification de base et qui provient d’un utilisateur spécifique pour le même serveur d’accès au client. Cet en-tête est également utilisé lorsque le trafic Outlook est transmis complètement via HTTP et que les clients se trouvent derrière un serveur proxy inverse.

• Cookie HTTP OWA UserContext   Ce cookie fonctionne pour Outlook Web App, seul client à l’utiliser. Lorsque vous utilisez une authentification basée sur des formulaires avec Outlook Web App, qui est la configuration par défaut, un petit groupe de demandes est créé au début d’une session Outlook Web App avant la création du cookie UserContext. Pour garantir que ces demandes utilisent une affinité pour connecter le client au même serveur d’accès au client, nécessaire à l’activation de l’authentification basée sur des formulaires, une option d’affinité de secours existe lorsque vous utilisez le cookie UserContext. Nous vous recommandons d’utiliser l’ID de session SSL ou une affinité d’IP source comme solution de secours pour fournir une affinité à ces demandes initiales avant que l’équilibreur de charge n’utilise le cookie UserContext.

  Remarque :

  Les demandes Outlook Web App qui utilisent une connexion explicite pour l’accès à une boîte aux lettres spécifique entraînent l’utilisation d’un cookie UserContext avec un ID et un nom différent. Le cookie commence avec UserContext mais une chaîne qui identifie la boîte aux lettres individuelle est ajoutée. Ceci complique l’équilibrage de charge avec le cookie UserContext car l’équilibreur de charge doit d’abord trouver un cookie commençant par UserContext. Ce qui risque de diminuer les performances.

• Cookie HTTP Exchange Control Panel msExchEcpCanary   Ce cookie fonctionne uniquement pour le Panneau de configuration Exchange.

• Cookie HTTP Outlook 2010 OutlookSession   Les équilibreurs de la charge matérielle prennent en charge le cookie OutlookSession et d’autres cookies génériques. Le tableau suivant décrit les exigences de prise en charge du cookie client OutlookSession pour Outlook RPC/HTTP :

  	Windows XP	Windows Vista	Windows 7
  Outlook 2003	Non pris en charge	Non pris en charge	Non pris en charge
  Outlook 2007	Non pris en charge	Non pris en charge	Non pris en charge
  Outlook 2007 Pack d'hébergement (KB2544404)	Non pris en charge	Pris en charge	Pris en charge
  Outlook 2010	Non pris en charge	Pris en charge	Pris en charge

  Remarque :
  Microsoft Outlook exécuté sous Windows XP ne prend pas en charge le cookie d'équilibrage de charge. Dans ce scénario, nous recommandons l'utilisation de l'équilibrage de charge IP.

• Cookie HTTP Remote PowerShell MS-WSMAN   Cette méthode fonctionne uniquement pour Remote PowerShell.

Retour au début

Cookie créé par équilibreur de charge

La deuxième méthode la plus fiable pour associer une session client à un serveur d’accès au client consiste à utiliser un cookie créé par un équilibreur de charge. L’équilibreur de charge ajoute un cookie HTTP à la conversation de protocole client/serveur, puis il utilise ce cookie pour déterminer quel serveur d’accès au client doit traiter une demande entrante. Les applications Exchange 2010 qui prennent en charge cette méthode sont Outlook Web App, le Panneau de configuration Exchange et Remote PowerShell. Ce type de cookie a plusieurs limitations.

• L’équilibreur de charge doit prendre en charge ce type d’affinité. Actuellement, seuls les équilibreurs de la charge matérielle et logiciel qui s’exécutent sur un serveur tiers prennent en charge cette affinité.

• Cette méthode ne fonctionne que pour les protocoles qui acheminent le trafic sur HTTP. Vous ne pouvez pas utiliser cette méthode pour le service d’accès au client RPC, le service de carnet d’adresses Exchange, POP3, ou IMAP4.

• La solution de l’équilibreur de charge doit pouvoir lire et interpréter le flux de données HTTP. Si vous utilisez SSL, cela signifie que l’équilibreur de charge doit déchiffrer le trafic pour lire le contenu. Parfois il en résulte une plus grande charge sur l’équilibreur de charge. Dans d’autres cas, il est impossible pour l’équilibreur de charge d’interpréter le flux de données HTTP lorsque vous utilisez l’authentification de certificat client sur le serveur d’accès au client.

• Le client doit pouvoir recevoir les cookies arbitraires du serveur et ensuite les inclure dans des demandes futures envoyées du client au serveur. Les clients Exchange ActiveSync, Outlook Anywhere et certains clients du service Web Exchange tels que les périphériques Microsoft Office Communications Server 2007 ne prennent pas en charge cette opération.

ID de session SSL

L’équilibrage de charge basé sur l’ID de session SSL fournit plus de détails que l’affinité d’IP source et vous permet de fractionner le trafic venant de différents clients même si ces clients proviennent de la même adresse IP. L’équilibrage de charge d’ID de session SSL vous permet également d’équilibrer la charge sans déchiffrer le trafic SSL. Cette action est nécessaire lorsque vous utilisez l’authentification de certificat client et lorsque vous terminez la connexion SSL sur le serveur d’accès au client.

L’affinité d’ID de session SSL n’est pas recommandée dans les deux situations suivantes :

• Certains clients, tels que Internet Explorer 8, recréent leur session SSL pour chaque processus du navigateur qui s’exécute sur l’ordinateur client. Cela se traduit par une nouvelle session SSL pour chaque fenêtre Outlook Web App. Puisque cette opération interrompt l’affinité client pour Outlook Web App, le déploiement de l’équilibrage de charge de cette manière n’est pas pris en charge pour Exchange 2010. Certains périphériques mobiles, tels que Apple iPhone, créent également de nouvelles sessions SSL pour certaines parties de leur communication Exchange ActiveSync avec Exchange.

  Remarque :
  Lorsque vous utilisez l’authentification de certificat client, des navigateurs utilisent la même session SSL pour tout le trafic à un nom d’hôte donné. Tant que l’authentification de certificat client est activée, l’ID de session SSL est une option d’affinité valide pour Outlook Web App et le Panneau de configuration Exchange.

• Dans le cas d’Outlook Anywhere, les serveurs d’accès au client utilisent le composant Windows RPC Proxy pour jumeler les connexions RPC_DATA_IN et RPC_DATA_OUT. Cela peut affecter défavorablement les performances.

IP source

La méthode la plus courante pour fournir une affinité entre des clients et des serveurs d’accès au client est l’utilisation de l’affinité d’IP. L’équilibreur de charge examine une adresse d’IP client et envoie tout le trafic d’une IP source spécifique à un serveur d’accès au client spécifique. Il s’agit du seul type d’affinité pris en charge par l’équilibrage de la charge réseau. Il existe deux aspects à considérer lorsque vous utilisez l’affinité d’IP source.

• L’affinité s’interrompt lorsque le client modifie une adresse IP. Cela peut se produire lorsqu’un ordinateur portable passe d’une connexion filaire LAN à une connexion Wi-Fi ou qu’il est synchronisé entre deux réseaux Wi-Fi distincts. Il existe un impact utilisateur lorsque le client change d’adresse IP. Par exemple, lorsque les utilisateurs se servent d’Outlook Web App, ils doivent s’authentifier chaque fois que leur ordinateur obtient une nouvelle adresse IP.

• Si un grand nombre de vos clients accèdent à votre solution d’équilibrage de charge depuis la même adresse IP, la répartition de charge ne sera pas équitable. L’impacte de cette action dépend du nombre de clients masqués derrière une adresse IP donnée. Par exemple, si vous disposez de quatre serveurs d’accès au client et que 50 % de vos clients accèdent à votre équilibreur de charge à partir de la même adresse IP, au moins 50 % de votre trafic ira à un serveur d’accès au client et les trois autres serveurs d’accès au client traiteront le reste du trafic. Il existe deus raisons principales pour lesquelles la plupart des clients accèdent à votre organisation Exchange via une adresse IP unique.

  • Les traductions d’adresses réseau ou les serveurs proxy sortants, tels que Microsoft Forefront Threat Management Gateway (TMG). Lorsqu’il existe une traduction d’adresses réseau ou un serveur proxy sortant entre vos clients et vos serveurs d’accès au client, les adresses IP client d’origine sont masquées par la traduction d’adresses réseau ou l’adresse IP du serveur proxy sortant.

  • Trafic proxy de serveur à serveur. Dans certains scénarios, un serveur d’accès au client envoie du trafic à un autre serveur d’accès au client. En général, cela se produit entre les sites Active Directory car un client doit accéder au serveur d’accès au client dans le même site Active Directory où se trouve sa boîte aux lettres. Pour plus d’informations sur le transfert du trafic par proxy, voir Présentation de la transmission par proxy et de la redirection.

Aucune affinité

Le dernier type d’affinité est aucune affinité. Lorsque vous n’utilisez pas d’affinité, chaque demande d’un client est attribuée à un serveur d’accès au client aléatoire. Nous ne recommandons pas cette option pour les protocoles qui nécessitent une affinité ou ceux qui profitent de meilleures performances grâce à cette affinité.

Il est recommandé de ne pas utiliser l’affinité pour les protocoles qui ne nécessitent pas l’affinité lorsque le déchargement SSL est configuré.

Retour au début

Résumé des options d’équilibrage de charge

Le groupe suivant fournit un résumé des options d’équilibrage de charge disponibles.

Chacune de ces options présente des avantages et des inconvénients.

• Les équilibreurs de la charge matérielle sont en général performants et incluent une fonctionnalité de sécurité telle que le déchargement SSL et l’inspection de trafic.

• Les équilibreurs de la charge logicielle d’une couche serveur distincte font en général partie de packages logiciel plus importants avec des fonctionnalités de proxy inverse telles que la pré-authentification, le déchargement SSL et l’inspection de trafic étendu. Lorsque les équilibreurs de la charge logicielle pré-authentifient les utilisateurs, ceux-ci n’ont pas besoin de s’authentifier à nouveau si le serveur d’accès au client pour lequel ils ont des affinités échoue. Cependant, certains équilibreurs de la charge logicielle nécessitent une affinité entre le client et le serveur proxy inverse. Dans ce cas, vous avez besoin d’une couche d’équilibrage de charge supplémentaire en face des serveurs proxy inverses avant que ces derniers effectuent les tâches d’équilibrage de charge pour vos serveurs d’accès au client.

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