Terheléselosztás webkiszolgálókon
Terheléselosztás webkiszolgálóknál
Tartalomjegyzék |
1 Round Robin (változó) DNS
Talán a terheléselosztás legegyszerűbb módja.
Több különálló, önmagában működőképes webszerverek esetén használható megoldás. A szerverek speciális szoftvert nem tartalmaznak, mindegyiknek külön IP címe van. Mindegyik szerver IP címét felvesszük „A” rekordként a DNS-be, a DNS kiszolgáló mindig másik címet ad vissza megvalósítástól függően (Általában, de nem feltétlenül Round-robin algoritmus alapján, innen is a név).
nslookup www.cnn.com Server: 192.160.172.6 Address: 192.160.172.6#53 Non-authoritative answer: Name: www.cnn.com Address: 157.166.224.25 Name: www.cnn.com Address: 157.166.224.26 Name: www.cnn.com Address: 157.166.226.25 Name: www.cnn.com Address: 157.166.226.26 Name: www.cnn.com Address: 157.166.255.18 Name: www.cnn.com Address: 157.166.255.19 nslookup www.cnn.com Server: 192.160.172.6 Address: 192.160.172.6#53 Non-authoritative answer: Name: www.cnn.com Address: 157.166.255.19 Name: www.cnn.com Address: 157.166.224.25 Name: www.cnn.com Address: 157.166.224.26 Name: www.cnn.com Address: 157.166.226.25 Name: www.cnn.com Address: 157.166.226.26 Name: www.cnn.com Address: 157.166.255.18
Egyszerű a megvalósítása, és külön költséggel nem jár, (Legalábbis a forgalomszabályozás része), viszont vannak korlátai:
Alapesetben nincs visszacsatolás a szerverek állapotáról:
- Ha egy szerver kiesik, attól még a DNS a hibás szerver címét is visszaadja.
- Eltérő teljesítményű szerverek esetén nem tudjuk figyelembe venni a teljesítménykülönbségeket.
Ennek elkerülésére létezik megoldás, az LbNamed http://www.stanford.edu/~riepel/lbnamed/ A módosított DNS kiszolgáló a szerverek folyamatos lekérdezésével értesül azok terheléséről, ezeket az információkat felhasználja a DNS kérésre adott válasz előállítása során.
A kliensek cache-elését nem tudjuk biztosan befolyásolni, nincs mit tenni.
A DNS kiszolgálókban van némi konfigurációs lehetőségünk a sorrend meghatározását illetőleg, pl. BIND esetén:
rrset-order { order_spec ; [ order_spec ; ... ]
Vagy pl. klienstől függő preferenciát is meghatározhatunk:
sortlist
{
{// 1st preference block start
192.168.4/24; // 1st client IP selection matches any of these
{10.2/16; // return any of these response IPs as 1st preference
172.17.4/24; // 2nd preference
};
}; // end first block
{ // second preference block
192.168.5/24; // 1st client IP selection matches any of these
{192.168.4/24; // return any of these response IPs as 1st preference
172.17.4/24; // 2nd preference
10.2/16; // 3rd preference
};
}; // end second block
}; // end sortlist
Mivel előfordulhat, hogy a kliens egy munkamenetben más-más szerverekhez fordul, dinamikus web alkalmazások esetén problémát jelenthet a munkamenetek kezelése.
Megoldások:- Állapotinformációk tárolása a kliensnél (cookie, paraméterek küldése minden http kérésben) Gyors és olcsó, de csak akkor használható, ha nincs szükség biztonságra, hiszen a felhasználó azt küld vissza, amit akar. - Relációs adatbázis használata: Jó megoldás a problémára, biztonságos is, de a skálázhatóságot elrontja: újabb problémát okozunk (ha újabb webkiszolgálót teszünk be elég lesz az adatbázis szerver kapacitása?) - Állapotszerver használata: ASP.NET találmány, majdnem olyan, mint a relációs adatbázis, csak célirányos. A probléma is ugyanaz vele (skálázhatóság)
2 Layer 2 megoldások
Abban az esetben, ha olyan szolgáltatást nyújtunk, ahol a legszűkebb keresztmetszet a hálózati sávszélesség, tehát a szerverek többi erőforrása alkalmas lenne további felhasználók kiszolgálására, alkalmazhatunk többszörözési technikákat, mint pl.:
link aggregation, port aggregation, etherchannel, gigabit etherchannel port bundling.
Ezek lényege, hogy két, vagy több csatornát azok összefogásával egyetlen nagy sávszélességű csatornává alakítanak, az így kialakuló csatorna gyorsaságán kívül a megvalósítástól függő mértékben redundáns is lesz.
Jellegéből adódóan szintén nem csak webkiszolgáló célokra használható.
3 Layer 4 megoldások
A szállítási rétegbeli megoldások a TCP/IP csomagok szétválogatásán, és azok célszerverre való továbbításán alapulnak. Jellegéből adódóan szintén nem csak www célokra használhatóak.
Linuxon az LVS http://www.linuxvirtualserver.org ilyen megoldást nyújt.
A megoldás lényege, hogy a kliensek egy speciális szerverhez fordulnak, az ún. virtuális szerverhez. Ezen a szerveren egy forgalomszabályozó program fut, ami megvizsgálja a beérkező TCP/IP csomagokat, (pl. célport, forrás IP, stb.) és a benne található információk, valamint a konfiguráció alapján a csomagot a kéréseket valóban feldolgozó szerverek egyikéhez irányítja.A virtuális szerver működésének jellegéből adódóan layer2 alapú gyorsítással remekül növelhető a teljesítménye.
Az irányítás és a válasz módjától függően a megoldás további altípusokra bontható:
3.1 Virtual server VIA NAT
A megoldás lényege, hogy a virtuális szerver (VS) két interfésszel rendelkezik, az egyik a külső hálózathoz, a másik egy belső hálózathoz csatlakozik, és egy - a hálózati címfordításhoz nagyon hasonló - eljárást végez.
http://www.linuxvirtualserver.org/VS-DRouting.html
A belső hálózaton találhatóak a valódi kiszolgálók, a kérések a VS-hez érkeznek. A VS-en futó szoftver a konfiguráció alapján kiválasztja, hogy melyik valós szerver fogja kiszolgálni a kérést, és az IP csomagok célcímét, TCP/UDP portját ennek megfelelően írja át, majd továbbítja a belső hálózatra, valamint bejegyzést készít a kapcsolatról.
A valós szerver megkapja a csomagokat, azokra válaszol, mintha egyedüli szerver lenne, a válasz csomagok a routing tábla alpján a VS-en keresztül jutnak el a célhoz, azonban a VS a kimenő csomagok forrás címét saját címére módosítja.
Probléma: Mi történik akkor, ha a kliens ugyanazon a hálózaton van, mint a valós szerverek?
3.2 Virtual server via Tunneling
Abban az esetben, ha a szerverek földrajzilag elkülönítettek, célszerűbb a NAT eljárás helyett a tunneling módszert választani.
A külső kérések ebben az esetben is a VS virtuális IP címére (VIP) érkeznek. A VS a beérkező csomagokat a megfelelő valós szerverek egyikéhez irányítja, mégpedig úgy, hogy az eredeti csomagot egy kiegészítő IP fejléccel látja el (IP over IP, IPIP), majd ezt küldi tovább a valós szervernek:
A valós szerver megkapja a csomagot, leválasztja a kiegészítő fejlécet, és az így kapott csomagot úgy kezeli, mintha közvetlenül a klienstől érkezett volna, közvetlenül válaszol rá. Ahhoz, hogy ezt problémamentesen meg tudja tenni, (tudja, hogy neki szól a csomag, és forrás címként a VIP címet írja) definiálnia kell egy olyan interfészt, (általában loopback / dummy alias) amelynek IP címe a VIP. Ezzel lesz még probléma, ugyanis innentől kezdve az adott interfész válaszolni fog az ARP kérésekre, ami nem jó, különösen akkor, ha egy hálózaton van legalább egy valós szerver és a virtuális szerver. Később részletesebben foglalkozunk a kérdéssel.
3.3 Virtual Server via Direct Routing
Abban az esetben, ha a valódi szerverek egy hálózaton vannak, gyorsabb megoldást jelent a Direct Routing.
Ennek során a VS a beérkező csomagokat tovább irányítja a megfelelő valós szerverhez, mégpedig úgy, hogy a teljes TCP/IP csomagot tovább küldi a cél szerver MAC címére. A valós szervereken egy loopback alias-ként a VIP címet kell beállítani, így a szerverek felismerik, hogy nekik szól a csomag, és arra közvetlenül válaszolnak.
Természetesen itt is megjelenik az előbb is ismertetett probléma, a szerverek válaszolnak az ARP kérésekre.
3.4 Az ARP probléma
Abban az esetben, ha egy hálózaton van virtuális szerver, valamint legalább egy valós szerver és a 3.2, vagy 3.3 módszert használjuk, egy hálózaton több VIP című szerver lesz, a valós szerverek alapesetben válaszolni fognak az ARP kérésekre, ami nem jó, mert versenyhelyzet adódik.
Előfordulhat, hogy a külső kliensek közvetlenül a valós szerverekhez jutnak el, így a forgalomirányítás használhatatlanná válik.
- Régi kernel esetén (2.0.x) ha loopback aliasként konfiguráljuk a VIP címet nincsen gond, mivel nem válaszol a loopback alias és tunneling ARP kérésekre.
- 2.2.x kernel verziótól válaszol, egy lehetséges megoldás, hogy letiltjuk valahogyan:
#Start the hiding interface functionality echo 1 > /proc/sys/net/ipv4/conf/all/hidden # Hide all addresses for this interface echo 1 > /proc/sys/net/ipv4/conf/<interface_name>/hidden
Természetesen ez csak akkor használható, ha a szerverekben több hálózati csatoló van, mivel így
Vagy használhatjuk az iproute-ot: /etc/sysctl.conf:
net.ipv4.conf.all.arp_ignore = 1 net.ipv4.conf.eth0.arp_ignore = 1 net.ipv4.conf.all.arp_announce = 2 net.ipv4.conf.eth0.arp_announce = 2
# Insert the ipip module insmod ipip # Make the tunl0 device up ifconfig tunl0 up # Start the hiding interface functionality echo 1 > /proc/sys/net/ipv4/conf/all/hidden # Hide all addresses for this tunnel device echo 1 > /proc/sys/net/ipv4/conf/tunl0/hidden # Configure a VIP on an alias of tunnel device ifconfig tunl0:0 <VIP> up
4 Layer 7 módszerek
4.1 Selective Source NAT
A 3.1 módszer esetén problémát jelent, ha a kapcsolódó kliens egy hálózaton van a valós szerverekkel, ugyanis azok így közvetlenül a kliensnek küldik a választ, a virtuális szerver nem értesül a kapcsolat lezárásáról. Azt, hogy ilyen eset (egy hálózaton van a kliens a szerverekkel) miért fordul elő (ingyen van a belső célra használható IP, a switchek vagy tudnak VNAT-ot, vagy olcsók) kérdéses, mindenesetre van megoldás, a Selective SNAT. Bővebben: http://lbdigest.com/2009/03/11/best-of-both-worlds-selective-source-nat/
4.2 KTCPVS
A www szerverek általában 3 fő feladatot végeznek: tartalom (szöveg) betöltése, képek betöltése, alkalmazások futtatása.
Lehetséges, hogy ezeket a funkciókat szétválogassuk, és külön szerverekre helyezzük, így az egyes szerverek jobban optimalizálhatóak. A kliensek közvetlenül a load balancer-hez fordulnak, ahol kernel thread-ként fut az ütemező, a különböző kéréseket különböző szerverekhez továbbítja, a visszakapott válaszokat pedig visszaküldi a kliensnek:
Az adminisztráció egy user space beli programmal történhet, példa 3 szerverreweb1 (képek), web2 (html), web3 (többi)):
tcpvsadm -A -i http -s http tcpvsadm -a -i http -r web1:80 tcpvsadm -a -i http -r web2:80 tcpvsadm -a -i http -r web3:80 tcpvsadm --add-rule -i http --pattern=/images/.* -r web1:80 tcpvsadm --add-rule -i http --pattern=/html/.* -r web2:80 tcpvsadm --add-rule -i http --pattern=.* -r web3:80
4.3 SSL termination, SSL célhardverek
A https kapcsolatok kezelésénél a titkosítás nagy terhelést jelent a szerverek számára.
Érdemes lehet az SSL kapcsolatok kezelését a forgalomszabályozón elvégezni, így a szervereken kisebb a terhelés. Ezt célszerűen akkor érdemes elvégezni, ha a forgalomszabályozó cpu teljesítménye nagy, vagy tartalmaz olyan célhardvert, ami az SSL titkosítást gyorsítja.
4.4 Apache mod_proxy_balancer
xxx
5 Irodalom, további információk:
LVS: http://www.linuxvirtualserver.org KCTCPVS: http://www.linuxvirtualserver.org/software/ktcpvs/ktcpvs.html Szakácskönyv szerű LVS mini how-to: http://www.devshed.com/c/a/Administration/LoadBalanced-Clusters/ Apache proxy balancer: http://httpd.apache.org/docs/2.2/mod/mod_proxy_balancer.html SSL termination Cisco ACE: http://docwiki.cisco.com/wiki/SSL_Termination_on_the_Cisco_Application_Control_Engine_Without_an_Existing_Chained_Certificate_and_Key_in_Routed_Mode_Configuration_Example
