|
Recherche |
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. 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). 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.
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 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)#
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é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 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 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 : 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 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. 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 -Cisco Application Control Engine Module Load Balancing Guide |
||||||||||||
