Hur kan jag lastbalansera mellan två eller fler servrar?


Det finns flera olika tekniker som kallas för lastbalansering. Vi talar i regel inte om lastbalansering när vi pratar om funktioner som "vanlig hederlig round-robin". Känner du inte till Round-Robin, så strunta i det sista textstycket.

 

Med lastbalansering kan man göra mycket. Tex "bygga" ett kluster med mailservrar som "utför samma jobb" var och en för sig men när de "jobbar" tillsammans i en lastbalanserad "pool" eller "kluster" så blir driftsäkerheten högre.

Ungefär på samma sätt kan man göra med många olika tjänster. Det finns fördelar såväl sett från: Säkerhetsynpunkt som driftsäkerhet men även prestandamässigt.

Ett tydligt exempel är webplatser därför har vi nedan ett exempel med en weblösning, det kan vara egentligen vad som helst som är webbaserat, för enkelhetens skull utgår vi från en vanlig websida för ett företag.

 

I nedanstående exempel har vi tre servrar;

  1. En webserver, som använder ett webpubliceringsverktyg som exempelvis CCM III för enkelt underhåll av en webplats.
    Allt innehåll för webplatsen finns på denna webserver.
    Webservern har IP-adressen 172.16.0.1.
    Denna server kallas nedan för "backend".
    Backend-servern tillåter enbart trafik från spegelservrarna nedan.

    I brandväggskonfigurationen släpps dock trafik in från webmasterns dator så att denne kan underhålla webplatsen. All trafik loggas.

  2. En "spegel-server", som kan vara en webaccelererande, cachande proxyserver som har som uppgift att ta emot besök, utvärdera om besökaren är "godkänd" och i så fall leverera innehåll till besökaren direkt från sin cache. Är besökaren inte godkänd nekas besöket. "Osäkra" frågor till websidan tas ej emot. Spegel-servern gör med jämna mellanrum kontroller för att se om innehållet i backend-servern har uppdaterats. Om så är fallet så uppdateras cachen i proxyservern.
    Tack vare att innehåll som ska skickas till en besökare kan levereras blixtsnabbt från cache-minnet på proxyservern så blir användarupplevelsen bättre/snabbare för besökare på webplatsen. Backend-servern skyddas även från eventuella säkerhetshot ute på Internet.
    Spegelservern har IP-adressen 172.16.0.2 och kallas nedan för server2.

    Den tjänst som används för server2 kan exempelvis vara: Dedikerad Server eller en Virtuell Server.

  3. En ytterligare "spegel-server", server3, fungerar exakt som server2 ovan. Denna server kan vara en virtuell server eller en dedikerad server.

 

En lastbalanserare konfigureras nu med en lastbalanseringspool som består av:

 - server2

- server3

Backen-servern, den webserver med själva innehållet får inte vara med i vår lastbalanseringspool eftersom vi inte vill ha riktiga besökare in i detta system. All trafik mot backen-systemet går via server2 eller server3.

För ökad redundans och driftsäkerhet kan vi lägga till fler servrar som fungerar exakt som server2 och server3. Vi rekommenderar minst 2 men du får bättre flexibilitet och driftsäkerhet med minst 3st system.

I lastbalanseringspoolen ställer vi in att i normal drift ska 50% av besökarna hamna i server2 och 50% i server3. Om lastbalanseraren upptäcker att någon av de två medlemsservrarna i poolen skulle sluta fungera så "kastas" det krånglande systemet ut från poolen automatiskt.

Detta är en viktig inställning, om ni exempelvis behöver göra systemunderhåll på server3 så kan ni ju inte ta emot besökare under tiden, dessa skulle stöta på fel och problem utan under tiden ert underhållsarbete pågår så tar server2 hand om all trafik, den får automatiskt 100% av trafiken.

Skulle ni ha tre system skulle man ställa in det på detta vis istället, vi tänker oss tre servrar, a, b och c som i normal drift ska dela lika på belastningen, dvs:

a) 33%

b) 33%

c) 34%

 

Vid ett "fel" på tex server "c" så tar a & b -servrarna 50/50 av trafiken. Går även "b"-servern ned så tar a-servern 100% osv.

 

Vi har valt just cachande proxy-servrar i exemplet ovan för det är en typ av situation som du får extra många fördelar med lastbalansering. Nu kan du nämligen testa din lastbalanserare, när du ser att allt fungerar som du vill så ställer vi in funktioner i själva proxyservrarna.

Just http-proxy har flera roliga parametrar som vi kan "leka med" för att ni ska få er tjänst att fungera precis som ni vill, några exempel:

 - Låt en proxyserver vara "master" och de andra "slavar", dvs trafik mot backend-systemet minimeras i och med att bara en server sitter och belastar och "pollar" den hela tiden.

Skulle belastningen på er "master" proxy bli lite högre pga att den tar emot all trafik från övriga proxyservrar i ert kluster så kan man ändra fördelningen i lastbalanseraren så att det ser ut tex så här:

master: 20%

slav1: 40%

slav2: 40%

 

En annan finurlig funktion i många proxylösningar är att man kan låta proxy-servrarna hålla koll på varandra. Exempelvis en så kallad "heartbeat"-funktion låter varje proxy-server avgöra om de andra proxyservrarna i samma kluster/pool "lever" och hur de ska hanteras.

 

 

Inledningsvis nämnde vi round-robin. Denna teknik innebär att man på en "låg" nivå på Internet styr trafik åt ett eller ett annat håll på Internet. Tack vare att man jobbar på en så "låg" nivå så är det få saker som kan gå fel, det är effektivt, robust och snabbt.

Använder man ovanstående lastbalansering med tre servrar, en backend och två frontend-servrar och behöver förbättra såväl prestanda som driftsäkerheten så är det nu man är smart och kombinerar med round-robin.

Vi på compartment AB menar att Round-robin inte är "äkta" lastbalansering (svårt med ordval här, det ena är inte bättre än det andra utan bara annorlunda) men tack vare att denna, äldre, teknik går att "lägga på" så kan man nu göra såhär för vårt exempelföretag ovan:

Repetition: Sedan tidigare har man ett kluster som består av:

1. En backend (CMS med content).

2. En frontend (cache, acceleration).

3. En ytterligare frontend (cache, acceleration).

 

I denna lastbalanserade "pool" kan vi nu således ta ned backend-systemet och den ena frontenden utan att besökare märker av detta. Bra, men nu vill vi ha ännu bättre.

Nu lägger vi till ytterligare en "pool". Vi väljer här för enkelhetens skull två ytterligare frontend-system, båda kan tex vara virtuella servrar för att hålla kostnaden nere.

Dessa frontend-system placeras nu i en annan pool, i en annan serverhall hos oss på compartment. Nu har vi fysisk redundans, dvs systemen är inte ens placerade i nätet på samma plats och använder olika infrastrukturer och underliggande tjänster.

Vårt nya kluster ser ut så här:

4. frontend3, en cachande proxy-server.

5. frontend4, ytterligare en cachande proxyserver.

Systemen ställs in för att i första hand hämta data direkt från backend-servern i vårt första kluster. I andra hand får de hämta från frontend1 och i sista hand från frontend2 i den första poolen. Skulle ingen av dessa noder vara nåbara så skulle man även kunna låta frontend 4 hämta data från frontend 3, detta är dock lite riskabelt och kräver att man tänker igenom lösningen ordentligt, vi vill inte riskera att frontend 4 börjar cacha felsidor och felmeddelanden.

Alla frontend-systemen, på båda "poolerna", ställs in för att cacha innehåll. Detta innebär att varje nod nu fristående kan leverera innehåll oavsett om backend-servern är nåbar. Men vi kan även ta ned hela pool1 och pool2 kommer fortsätta leverera innehåll, och tvärt om. Det enda som inte får inträffa nu är att alla frontend-systemen samtidigt slutar fungera. Dock räcker det med att en enda frontend "lever" för att besökarna ska kunna använda tjänsten som vanligt. Troligtvis med lite längre svarstider om det är mycket trafik på webplatsen men hellre det än inget svar alls.

 

Med hjälp av Round Robin fördelar vi nu trafik på detta sätt:

pool1: 50%

pool2: 50%

 

Dvs i normal drift får hälften av webbesökarna svar från någon frontend på pool1.

Uppdatering kan ske varje minut eller mer sällan. Vi kan alltså styra om trafiken, i teorin så snabbt som på en minut, så att all trafik går till pool2 om vi tex får ett avbrott på pool1.

Eftersom det är flera olika system i båda poolerna så kan vi dessutom ha en lokal driftstörning i pool1 och/eller pool2, så länge något av systemen fungerar alls så fungerar webtjänsterna.

 

Har ni en större webbaserad tjänst, tex med mycket trafik, många användare, "tungt innehåll" eller liknande så är det extra viktigt att tänka på hur weblösningen ska lastbalanseras och inte minst levereras till besökaren. Vissa system klarar inte av proxylösnignar hur som helst och flera system som liknar CCM saknar helt möjlighet att "ställa" en skyddande vägg av lastbalanserade cachande webacceleratorer framför. CCM, såväl version 1.x, 2.x och 3.x har dock fullt stöd för detta och vi rekommenderar alltid detta för större webplatser.

 

Det kan lätt bli ganska tekniskt komplicerat så vi går inte in på en mer detaljerad nivå utan avrundar här och ber dig som vill veta mer kontakta vår säljavdelning så berättar vi mer om vilka tjänster som passar er bäst och erbjuder de funktioner ni är ute efter för att få er weblösning att fungera så bra som möjligt.

 

Läs mer om våra serverhostingtjänster här: http://compartment.se/serverhosting

Läs mer om våra proxytjänster här: http://compartment.se/proxy

Läs mer om CCM här: http://ccm.compartment.se/

 

Senast uppdaterad:
2013-06-26 11:03
Av: :
compartment AB
Ny version:
1.3
Resultat av röstning:0 (0 röster)

Du kan inte kommentera den här frågan

Chuck Norris has counted to infinity. Twice.

bannerbyte.eu