> Tech > A la place d’un répartiteur de charge…

A la place d’un répartiteur de charge…

Tech - Par iTPro - Publié le 17 février 2012
email

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. Pas facile

A la place d’un répartiteur de charge…

mais essayons. Comment reconnaître de façon certaine un client précis.

  1. 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.
  2. 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 gratuitement cette ressource

*** SMART DSI *** VERSION NUMÉRIQUE

*** SMART DSI *** VERSION NUMÉRIQUE

Découvrez SMART DSI, la nouvelle revue du Décideur IT en version numérique. Analyses et dossiers experts pour les acteurs de la transformation numérique de l'entreprise, Gagnez en compétences et expertise IT Professionnelle avec le contenu éditorial premium de SMART DSI.

Tech - Par iTPro - Publié le 17 février 2012