Recherche


imprimer pdf

Loadbalancing simple sur équipement Cisco ACE avec persistance de session


Ce guide explique comment configurer un Load Balancer simple en activant la persistance des sessions. Dans cet exemple, nous utiliserons la fonctionnalité HTTP-cookie pour faire cela.

Cisco ACE: configuration


Les éléments requis sont identiques à ceux du guide VrackLoadBalancingACESimple:

- 2 serveurs de gamme EG/MG/HG pour faire le Load Balancer
- les serveurs doivent posséder l'option utilisation professionnelle (nous aurons besoin d'une baie virtuelle pour configurer la connexion entre les hôtes et le boîtier ACE)
- vous devez posséder un Load Balancer ACE : http://www.ovh.com/fr/items/ace_load_balancing.xml
- vous devez posséder un bloc d'IP RIPE

Certaines sections de ce guide sont présentées sans explications (à venir).

Tester le réseau privé


Configurez les deux serveurs en suivant le guide baie virtuelle.
Nous configurons au préalable l'ip 172.16.0.1 sur la première machine puis 172.16.0.2 sur la seconde machine etc.

IMPORTANT !!
Vous pouvez configurer 172.16.0.0/12 à l'exception des IP listées ci-dessous, vous ne devez en AUCUN CAS ajouter les IP suivantes comme interface sur votre machine:
  • 172.16.0.0 => IP Network
  • 172.31.255.250 => IP réservée utilisée dans notre exemple
  • 172.31.255.251 => IP réservée utilisée dans notre exemple
  • 172.31.255.252 => IP réservée utilisation interne OVH
  • 172.31.255.253 => IP reservée utilisation interne OVH
  • 172.31.255.254 => IP Gateway de votre baie de virtuelle


Vérifiez ensuite si vos serveurs arrivent à communiquer :

serveura:~# ping -c3 172.16.0.2
PING 172.16.0.2 (172.16.0.2) 56(84) bytes of data.
64 bytes from 172.16.0.2: icmp_seq=1 ttl=64 time=0.277 ms
64 bytes from 172.16.0.2: icmp_seq=2 ttl=64 time=0.261 ms
64 bytes from 172.16.0.2: icmp_seq=3 ttl=64 time=0.275 ms

serveurb:~# ping -c3 172.16.0.1
PING 172.16.0.1 (172.16.0.1) 56(84) bytes of data.
64 bytes from 172.16.0.1: icmp_seq=1 ttl=64 time=0.277 ms
64 bytes from 172.16.0.1: icmp_seq=2 ttl=64 time=0.261 ms
64 bytes from 172.16.0.1: icmp_seq=3 ttl=64 time=0.275 ms



Se connecter au Cisco ACE


Nous allons maintenant configurer le Load Balancer ACE. Connectez-vous à celui-ci avec les codes d'accès que vous avez reçu par mail :

user@machine ~ ssh admin@ip_du_load_balancer
Password:
Cisco Application Control Software (ACSW)
TAC support: http://www.cisco.com/tac
Copyright (c) 2002-2009, Cisco Systems, Inc. All rights reserved.
The copyrights to certain works contained herein are owned by
other third parties and are used and distributed under license.
Some parts of this software are covered under the GNU Public
License. A copy of the license is available at
http://www.gnu.org/licenses/gpl.html.
rbx-99-6k-ace-1/vrack1234#

Entrez dans le mode de configuration:
rbx-99-6k-ace-1/vrack1234# configure
Enter configuration commands, one per line. End with CNTL/Z.
rbx-99-6k-ace-1/vrack1234(config)#

Astuce !
Pour la suite, quand vous voyez "(config)" comme ci-dessus, vous devez faire ceci : Tapez "conf t" ou "configure" pour entrer dans le mode configuration puis quittez ensuite avec CTRL+Z une fois la configuration entrée.



Configurer le réseau privé


IMPORTANT !!
Nous utilisons un vlan dont le tag est proche du vôtre pour configurer l'accès au boitier ACE. Pour le vlan 2045, nous utilisons généralement le vlan 245. Il est cependant possible qu'il soit différent. Vous le retrouverez en faisant un "show running-config". Ne supprimez surtout pas l'interface vlan 245 ! Si vous faites cela, vous perdrez l'accès au Load Balancer et vous serez facturé pour la remise en état de la configuration par nos administrateurs.


Astuce !
Vous pouvez annuler une ligne entrée par erreur. Par exemple si pour la translation de port vous avez indiqué une mauvaise gateway, vérifiez votre configuration avec "show running interface" puis faites :
rbx-99-6k-ace-1/vrack1234# configure
rbx-99-6k-ace-1/vrack1234(config)# no ip address 72.16.0.10 255.255.255.255
Puis entrez la bonne règle :
rbx-99-6k-ace-1/vrack1234# configure
rbx-99-6k-ace-1/vrack1234(config)# ip address 172.16.0.10 255.240.0.0


D'abord, ajoutez "ANY" à l'acces-list pour autoriser l'icmp (le ping) et le tcp pour tout le monde :
rbx-99-6k-ace-1/vrack1234(config)# access-list ANY line 8 extended permit icmp any any
rbx-99-6k-ace-1/vrack1234(config)# access-list ANY line 16 extended permit ip any any

Ensuite, définissez l'interface de la baie virtuelle pour l'utilisation interne.
OVH vous conseille d'utiliser l'ip 172.31.255.251. Nous faisons ici une translation de port vers les serveurs réels en NAT:
rbx-99-6k-ace-1/vrack1234(config)# interface vlan 1234 # remplacez 1234 par le tag de votre baie virtuelle
ip address 172.31.255.251 255.240.0.0
access-group input ANY
nat-pool 1 172.31.255.250 172.31.255.250 netmask 255.240.0.0 pat
no shutdown



Vérifier cette configuration


Vérifiez si vos serveurs A et B sont accessibles via la baie virtuelle depuis l'ACE :
rbx-s1-ace/vrack2199# ping 172.16.0.1
Pinging 172.16.0.1 with timeout = 2, count = 5, size = 100 ....

Response from 172.16.0.1 : seq 1 time 0.295 ms
Response from 172.16.0.1 : seq 2 time 0.161 ms
Response from 172.16.0.1 : seq 3 time 0.080 ms
Response from 172.16.0.1 : seq 4 time 0.160 ms
Response from 172.16.0.1 : seq 5 time 0.176 ms
5 packet sent, 5 responses received, 0% packet loss

rbx-s1-ace/vrack2199# ping 172.16.0.2
Pinging 172.16.0.2 with timeout = 2, count = 5, size = 100 ....

Response from 172.16.0.2 : seq 1 time 0.392 ms
Response from 172.16.0.2 : seq 2 time 0.378 ms
Response from 172.16.0.2 : seq 3 time 0.338 ms
Response from 172.16.0.2 : seq 4 time 0.302 ms
Response from 172.16.0.2 : seq 5 time 0.276 ms
5 packet sent, 5 responses received, 0% packet loss



Créer une ferme de serveur


Avant tout, nous demandons à l'ACE de verifier le fonctionnement de vos machines, nous définissons alors PROBE_TCP avec un intervalle de 30 secondes et 60 secondes en cas d'erreur:
rbx-99-6k-ace-1/vrack1234(config)# probe tcp PROBE_TCP
interval 30
passdetect interval 60


Déclarez les serveurs dédiés. Nous annoncons les machines du loadbalancing, ainsi que leurs ip et le protocole de connexion à suivre.
Dans cet exemple, nous mettons une limite de connexion de 50000 pour prévenir les surcharges:
rbx-99-6k-ace-1/vrack1234(config)# rserver host SERVER1 # remplacez SERVER1 par le nom de votre premier serveur
ip address 172.16.0.1
conn-limit max 50000 min 40000
inservice
rbx-99-6k-ace-1/vrack1234(config)# rserver host SERVER2 # remplacez SERVER2 par le nom de votre second serveur
ip address 172.16.0.2
conn-limit max 50000 min 40000
inservice


Créez une Ferme de serveur
Dans cet exemple, la ferme s'appelera FARM_WEB, nous utiliserons la méthode "predictor leastconns" qui crée un Load Balancer basé sur le nombre de connexion. Nous utilisons ici le PROBE_TCP configuré plus tôt:
rbx-99-6k-ace-1/vrack1234(config)# serverfarm host FARM_WEB
predictor leastconns
probe PROBE_TCP
rserver SERVER1 # remplacez SERVER1 par le nom de votre premier serveur
inservice
rserver SERVER2 # remplacez SERVER2 par le nom de votre second serveur
inservice


Configuration de la persistance des sessions


L'ACE va utiliser un cookie pour enregistrer les connexions. Nous configurons notre groupe StickyGroup1? d'utiliser un cookie appellé CookieACE. Le cookie a une durée de vie de 3600 minutes. Notre groupe inclue toutes les machines de notre ferme FARM_WEB :

sticky http-cookie CookieACE StickyGroup1?
timeout 3600
serverfarm FARM_WEB


Nous appliquons la précédente confiration sur la configuration de loadbalancing, et nous inserons l'IP source du client dans dans l'entête HTTP :
policy-map type loadbalance http first-match WEB_L7_POLICY
class class-default
sticky-serverfarm StickyGroup1?
insert-http x-forward header-value "%is"


Comme dans le guide VrackLoadBalancingACESimple, nous créons une classe pour relier tous les éléments de la configuration :
policy-map multi-match WEB-to-vIPs
description Ties 4-WEB-IP class-map, WEB_L7_POLICY maps together and applies HTTP_PARAMETER_MAP. Uses NAT.
class L4-WEB-IP
loadbalance vip inservice
loadbalance policy WEB_L7_POLICY
loadbalance vip icmp-reply active
nat dynamic 1 vlan 2070
appl-parameter http advanced-options HTTP_PARAMETER_MAP


Il ne nous reste plus qu'à appliquer la règle service-policy et access-list sur l'interface VLAN d'entrée :
rbx-99-6k-ace-1/vrack2070(config)# interface vlan 270
service-policy input WEB-to-vIPs
access-group input ANY


Paramètres de cookie du serveur


Pour tester la persistance, nous devons configurer des cookies sur le site web concerné.
Créons un fichier cookie.php dans le répertoire racine de votre site web.
Cela va générer un cookie appelé CookieACE avec une valeur aléatoire ou simplement l'afficher s'il est déjà présent sur la navigateur web:
<html>
<head>
<?php
$n = 'CookieACE';
if( ! $_COOKIE["$n"]) {
$cookie=rand(1,10000);
echo '<meta http-equiv="Set-Cookie" content="'.$n.'='.$cookie.'; path=/" />';
}
?>
</head>
<body>
Hello from SERVER1
<?php
if($_COOKIE["$n"])
echo "Got cookie: $n = $cookie";
else
echo "New cookie set: $n = $cookie";
?>
</body>
</html>

Faites de même sur le second serveur mais indiquez "Hello from SERVER2" au lieu de "Hello from SERVER1" pour bien voir la différence entre les deux.

Test du Loadbalancing


Pour tester la persistance de votre session, rendez-vous sur http://188.165.125.115/cookie.php (ip.du.serveur.1/cookie.php). Nous verrons par exemple :
Hello from SERVER1 set a new cookie: CookieACE = 3028

Maintenant, si votre navigateur accepte les cookies, après avoir rafraîchit votre page, vous devez toujours voir la réponse du serveur A:
Hello from SERVER1 Got cookie: CookieACE = 3028

Hello from SERVER1 Got cookie: CookieACE = 3028

Hello from SERVER1 Got cookie: CookieACE = 3028

Hello from SERVER1 Got cookie: CookieACE = 3028

Jetons un oeil à la base des sessions sur le Loadbalancing ACE:
rbx-99-6k-ace-1/vrack2070# show sticky database
sticky group : StickyGroup1?
type : HTTP-COOKIE
timeout : 3600 timeout-activeconns : FALSE
sticky-entry rserver-instance time-to-expire flags
-----------------------------------------------------------------+-------+
12411268269029278684 SERVER1:0 215995 -

Nous voyons que le http-cookie est actiof pour StickyGroup1?. Vous retrouvez ici le timeout, le type de cookie, le nom et la liste des instances en cours sur les serveurs.

Il est possible de voir la session pendant qu'elle TCP est active :
rbx-99-6k-ace-1/vrack2070# show conn port 80

conn-id np dir proto vlan source destination state

383186 1 in TCP 270 78.8.249.77:39277 188.165.125.115:80 ESTAB
230973 1 out TCP 2070 10.20.70.101:80 10.20.70.254:14013 ESTAB

Dans le navigateur, vous pouvez vois les détails du cookie:
1 cookie set:
Name CookieACE
Value 3028
Server 188.165.125.115
path /
secure No
expires End of session

Enfin, après avoir supprimé et désactivé les cookies, nous pouvons constater que que nos différentes requêtes sont prises en charge par différents serveurs de notre ferme (server-farm).
La session TCP expire et chque nouvelle session est traitée par un nouveau serveur réel.

Exemple de requêtes avec cookies désactivés:
Hello from SERVER1 set a new cookie: CookieACE = 6077

Hello from SERVER1 set a new cookie: CookieACE = 4231

Hello from SERVER2 set a new cookie: CookieACE = 4199

Hello from SERVER1 set a new cookie: CookieACE = 926


Documents complémentaires

-Cisco Application Control Engine Module Load Balancing Guide