Cisco SLB


Tagek: Cisco,
Írta: toshy
Publikálva: 2008-07-27 18:38:10

Cisco Service load balance (Cisco SLB).

Azon a hálózaton amit adminisztrálok, többek közt van két 6500 -ös Multi Layer switch/rouer.

Mint ilyen természetesen az egyik alhálózat routerei. Mivel itt folyik a routing gondoltam egyet, és belőttünk egy SLB -t először próbaképen. Volt egy SQUID proxy, és csináltam egy másikat, csakis azzal a céllal, hogy ezt az SLB-t kipróbáljam.

Valahogy így néz ez ki:



Na ez azt hiszem egy kis magyarázatra szorul.

Szóval:

Adott a két router R1, R2 ezekhez dot1q trunk módban kapcsolódik a négy switch SW1, SW2, SW3, SW4. A két router HSRP -vel dönti el hogy melyik az éppen aktív. Mint látjátok a switch-ek mindkét router-hez kapcsolódnak. Adott ugye három hálózat, legalábbis a mi példánkban, a 10.1.1.0 /29 amit nevezzünk VLAN5-nek vagy “szerver vlan-ak, és a két másik hálózatot mondjuk VLAN6, és VLAN7 azaz legyen “pénzügy vlan”, és “hr vlan” mindkettő 24 bites hálózati mask-al . Van ott egy zölddel mutatott valamint áthúzott IP cím az 5-ös vlan-ból a 10.1.1.4 , erről had meséljek később, és vegyük úgy, hogy az nincs ott. Nagyjából ennyit szánnék a rajzom magyarázatához.

A squid szervereken RHEL 4-es fut, az alap RedHat-el jött squid-al, és egy egy ethernet interface van bennük. Ahhoz hogy belőjük az SLB-t, ahhoz fel kell vennünk a saját IP címük mellé egy virtuális IP címet ami közös lesz mindkét gépen. A jövőben ezt kell majd megszólítanunk mint proxyt. Tehát legyen ez az IP cím a 10.1.1.3 . Úgynevezett “interface alias-ra” lesz szükség ami az eth0 aliasa lesz, vagyis az eth0:1. Tenni kell róla, hogy újra boot-kor is feljöjjön. Szerver oldalon készen is vagyunk ott már nincs más dolgunk, jöjjön hát a hálózati config.

Először csak az R1-en dolgozunk , és ha minden rendben megy akkor megcsináljuk az R2-n is. Az SLB -nek három fő része van:

PROBE


SERVER FARM


VIRTUAL SERVER


A probe-nak az a lényege, hogy ellenőrizgesse a szerveren a kapcsolatot, és ha esetleg nem működne, akkor annak a státuszát módosíttassa.

A szerver farmba vannak felvéve az úgynevezett REAL IP címek. De itt lehet megadni a load balancing típusát is roundrobin/leastconns. Vagy ha egy szinttel beljebb lépunk akkor a real szerverek-et lehet configolni.

A virtual szerverbe pedig a virtuális ip cím van.

De lássuk hogy néz ki az ide tartozó config:

ip slb probe KEEPALIVE_PROXY tcp
port 3128
!

ip slb serverfarm PROXYFARM
probe KEEPALIVE_PROXY
real 10.1.1.1
weight 255
inservice
!
real 10.1.1.2
weight 1
inservice
!

ip slb vserver PROXY
virtual 10.1.1.3 tcp 3128
serverfarm PROXYFARM
inservice standby hsrp-Vl5-1
!


Így néz ki a config.

A real szervereknél a weight parancs a súlyozást jelenti, vagyis a config szerint a 10.1.1.1-es proxy1-re megy 255 kapcsolat míg a 10.1.1.2-es proxy2-re 1 kapcsolat. Nincs megadva a load balancing típusa ezért ez roundrobin típusú, és így lehet súlyozni. Ez a példa nem a terhelés elosztásról szól, hiszen akkor nem kellet volna súlyozni, itt csak annyi a lényeg, hogy az elsődleges proxy-t használja , és ha esetleg nem működne az egyik akkor nyílván csak a másikat tudja használni.
Ellenőrzésre több parancs is van mint például a “show ip slb real” ez a real szerverek státuszát listázza ki, vagy a “show ip slb vserver” ez meg a virtuális szerverek státuszát, vagy a “show ip slb connections“. Sok van még de had ne soroljam itt fel mindet, ha valakit esetleg mégis érdekelné az nézzen utána CISCO-éknál, vagy nézze meg a router helpjét, vagy kérdezzen meg engem, és privátban nagyon szívesen elküldöm.

Látható még a configban az “inservice” parancs is, ezzel a paranccsal lehet aktiválni az éppen adott real szervert. Természetesen a “no inservice” paranccsal meg ínaktivá tenni. A vszerver configjában az inserevice parancs után meg kell/lehet adni, hogy standby-t vagyis azt hogy éppen melyik routeren aktív a load balancing, azt honnan vegye. Itt ugye, mivel HSRP -ről van szó ezért a hsrp group név kell, ebben az esetben pedig a “hsrp-Vl5-1″ volt az.

A vserver-nél van megadva a port amire szétossza a kapcsolatokat, de itt meg lehet adni azt is, hogy ne nézze milyen portról van szó hanem az összes portra érkező kapcsolatot ossza szét, és mint mindig CISCO-éknál most is az “any” a bűvös paraméter.

Itt jegyezném meg, hogy mióta ezt a proxy-s esetett megcsináltam azóta több, dolgot is load balancing-olunk, teljes sikerrel, és azoknak a configja majdnem mindnek így néz ki, DE sajnos így a proxy-s load balance nem működött, és többféle próbálkozás után úgy sikerült működésre bírni, hogy ki vettük a szerver farmból a probe-ot. Láss csodát működött. A real szerverek státusza azért még update-ve van, de csak abban az esetben ha egy connection-t nem tud kiszolgálni, így kicsit lassabb lett az “error detection”. Az összes többi SLB-és configunkban jól működik a probe csak ennél nem, és nem tudom, hogy miért. Ha valaki esetleg tudja a választ azt szívesen fogadnám.

Akkor végezetül arról a zöld áthúzott IP címről. Hogy ez működjön a PC1 és a PC2 megcímzi a proxy dns nevet, amit felvettünk a DNS szerverbe. A DNS szerver vissza adja a virtuális IP címet a host ezt le cache-eli, és felveszi vele a kommunikációt. Elindul a kommunikáció a virtuális IP-re ami keresztül megy a routeren és dobja az éppen aktuális real szervernek. De mi van ha, ha mondjuk aki a kommunikációt kezdeményezi, legyen a PC1, az ugyanabban a hálózatban van mint a proxy szerver ?

Akkor az van, hogy nem történik routing, mert hálózaton belül ugye nem kell, így nem jut el a kérés a router-ig, így a böngésző csak teker, és teker, és teker, és jön a telefon a luser-től, hogy nem megy az INTERNET.
Ez ugye nem fordulhat elő nagyon sűrűn, de higyétek el nekem volt rá példám.

Köszönöm szépen a figyelmet, és ha esetleg valamit elrontottam, vagy nem jól írtam, vagy megválaszolnád a kérdésemet, esetleg csak hozzászólnál, vagy csak vitát indítanál a témáról, kérlek tedd meg és szóljál hozzá.

Köszi

Szólj hozzá

Hozzászólások(0)