Mais à propos, d’un point de vue ADC ou répartiteur de charge, un même client ça se matérialise comment ? Si vous le voulez bien mettons-nous 2 minutes à la place d’un répartiteur de charge qui reçoit de tous les coins du monde des requêtes clients.
A la place d’un répartiteur de charge…
Pas facile mais essayons.
Comment reconnaître de façon certaine un client précis.
- La première solution est d’utiliser son adresse IP. Facile, efficace, simple. Bref la solution… presqu’idéale. Sauf que … si le réseau distant sur lequel est connecté une partie de vos clients est naté vers le vôtre, l’ensemble de vos clients auront tous la même adresse IP. Impossible de les distinguer. Cela peut être le cas au sein de vos réseaux internes comme pour certains de vos clients qui utiliseraient des réseaux extérieurs pour se connecter vers vos infrastructures. Certains pays font cela, allez savoir pourquoi …. ?
D’autre part, certains applicatifs MAPI comme les services Blackberry concentrent toutes les requêtes de vos terminaux mobiles Blackberry depuis un seul point représenté par votre ou vos serveurs BES. Ils seront donc quasiment impossibles à répartir correctement. - La seconde solution consiste à utiliser un cookie de session. Deux options sont possibles. La première consiste à faire en sorte que l’application génère le cookie, la seconde que cela soit l’ADC qui s’en charge. Si vous envisagez d’utiliser le cookie de session généré par le répartiteur de charge (ce que je vous conseille) il sera nécessaire de décrypter le flux SSL. La liste suivante précise les protocoles Exchange qui supportent la génération du cookie de session par le répartiteur de charge. La seconde liste référence les noms des cookies générés.
Liste des protocoles qui supporte la génération de cookie par le répartiteur de charge :
- Outlook Web Access
- Panneau de contrôle Exchange
- Remote Powershell
Nom des Cookies de session par protocoles :
- Exchange Control panel : msExchEcpCanary
- Outlook 2010 Http : Outlooksession
- Remote powershell : PowerShell MS-WSMAN
- Outlook Web Access : UserContext OWA
L’autre mécanisme est d’utiliser également l’indentification de session SSL ID. Attention tout de même, car certains browsers (Internet Explorer 8) ont la fâcheuse tendance à renégocier toutes les 2 minutes la session SSL. D’autre part, certains téléphones mobiles comme l’Iphone ont aussi ce comportement.
Le tableau 2 liste en fonction du protocole utilisé, les méthodes de gestion de persistance que vous devrez utiliser si votre répartiteur de charge le permet.
| Trafic | Méthode de gestion de persistance préconisée |
| Post Office Protocol (POP3) | Pas d’affinité/Persistance |
| Internet Message Access Protocol (IMAP4) | Pas d’affinité/Persistance |
| Outlook Web App | 1. Adresse IP du client 2. Cookie applicatif « UserContext » |
| Exchange Control Panel | 1. Adresse IP du Client 2. Cookie applicatif « mxExchEcpCanary » |
| Exchange ActiveSync | 1. Adresse IP du client 2. Authorization HTTP header |
| Exchange Web Services | 1. Cookie 2. SSL ID |
| Outlook Anywhere | 1. Adresse IP du client 2. Pas d’affinité/Persistance 3. Cookie applicatif « OutlookSession » |
| Offline Address Book | 1. Adresse IP du client 2. SSL ID |
| Autodiscover | Pas d’affinité/Persistance |
| RPC Client Access | 1. Adresse IP du client |
| Exchange Address Book | 1. Adresse IP du client |
| RPC Endpoint Mapper | 1. Adresse IP du client |
Téléchargez cette ressource
Guide inmac wstore pour l’équipement IT de l’entreprise
Découvrez toutes nos actualités à travers des interviews, avis, conseils d'experts, témoignages clients, ainsi que les dernières tendances et solutions IT autour de nos 4 univers produits : Poste de travail, Affichage et Collaboration, Impression et Infrastructure.
Les articles les plus consultés
A travers cette chaîne
A travers ITPro
