Examensarbete
Lastbalanseringsalgoritmer
En utvärdering av lastbalanseringsalgoritmer i ett
LVS-kluster där noderna har olika operativsystem
Abstrakt
Denna rapport behandlar en undersökning av olika lastbalanseringsalgoritmer i Linux Virtual Server. Undersökningen har gjorts i ett webbkluster (Apache var webbservern som användes) med tre heterogena noder, där
operativsystemet var den detalj som skiljde dem åt. Operativsystemen som ingick i undersökningen var Windows Server 2008 R2, CentOS 6.2 och FreeBSD 9.0. De faktorer som undersöktes mellan de olika algoritmerna var klustrets genomsnittliga svarstid vid olika belastning och hur många
anslutningar som kunde hanteras av klustret, detta gjordes med verktyget httperf.
Undersökningen ger svar på hur ett heterogent webbklusters genomsnittliga svarstid och arbetskapacitet kan skilja sig åt beroende på vilken algoritm som används för lastbalansering. Resultatet visar att den genomsnittliga svarstiden håller sig låg tills en hastig stigning inträffar. Shortest Expected Delay och Weighted Least-Connection Scheduling kunde hantera störst antal
anslutningar.
Nyckelord: Kluster, lastbalansering, svarstid, Linux Virtual Server, Round Robin, Least-Connection Scheduling, Shortest Expected Delay, httperf
Abstract
This report covers an investigation of different load balancing algorithms in Linux Virtual Server. The investigation was done in a web cluster (with Apache as the software being used) consisting of three heterogeneous nodes, where the operating system was the detail that differentiated the nodes. The operating systems that were used in the investigation were Windows Server 2008 R2, CentOS 6.2 and FreeBSD 9.0. The factors examined were average response time at different load and how many connections the cluster could cope with, these factors were examined by measurements taken with the tool httperf.
The investigation gives an answer to how a heterogeneous web clusters average response time and working capacity can be affected by the choice of load balancing algorithm. The result shows that the average response time stays low until a sudden rise occurs. Shortest Expected Delay and Weighted Least-Connection Scheduling could handle the largest number of
connections.
Keywords: Clustering, load balancing, response time, Linux Virtual Server, Round Robin, Least-Connection Scheduling, Shortest Expected Delay, httperf.
Innehållsförteckning
1 Introduktion ... 1
1.1 Ämnesområde och relevans ... 1
1.2 Problemformulering och frågor ... 2
1.3 Målformulering och nytta ... 2
1.4 Ansats och syfte ... 3
1.5 Avgränsningar ... 3
2 Bakgrund ... 4
2.1 Svarstid ... 4
2.2 Linux Virtual Server ... 4
2.3 Keepalived ... 5
2.4 Lastbalanseringstekniker i LVS ... 5
2.5 Lastbalanseringsalgoritmer som utreds ... 7
3 Metod ... 10
3.1 Ansats & urval ... 10
3.2 Experimentmiljö ... 10
3.3 Mätverktyg ... 11
3.4 Genomförande ... 12
3.5 Metoddiskussion ... 14
4 Resultat ... 16
4.1 Observationer ... 16
4.2 Resultatanalys ... 20
5 Avslutning ... 24
5.1 Sammanfattning och slutsatser ... 24
5.2 Bidrag ... 25
5.3 Fortsatt forskning ... 25
6 Referenser ... 26
1 Introduktion
Detta kapitel introducerar arbetets ämnesområde som är klustring av datorer.
Detta mynnar sedan ut i en problemformulering som innehåller två frågor som detta arbete skulle besvara. Efter det följer en målformulering, ansats och syfte, och avgränsningar.
1.1 Ämnesområde och relevans
Detta arbete adresserar ämnesområdet klustring. Klustring av datorer innebär att flera datorer används tillsammans för samma ändamål. Datorkluster delas vanligtvis in i grupperna High Availability (HA), Load Balancing (LB) och High Performance Computing (HPC) [1]. High Availability syftar till att öka redundansen på en tjänst genom att ha flera datorer som är förberedda för att tillhandhålla samma tjänst, om en dator slutar att fungera kan en annan snabbt ta över för att säkerhetsställa att tjänsten fortfarande är tillgänglig. Load Balancing (sv. lastbalansering) liknar HA med skillnaden att en arbetsbörda fördelas mellan klustrets datorer, det vill säga att flera datorer aktivt
tillhandhåller samma tjänst. Arbetskapaciteten hos ett LB-kluster ökar ju fler datorer som används, till skillnad från ett HA-kluster där arbetskapaciteten är begränsad till vad en dator kan göra. High Performance Computing-kluster är till för tillämpningar där extrem beräkningskraft fordras. Datorer i ett HPC- kluster delar resurser som arbetsminne och CPU-tid i större grad och används som ett alternativ till så kallade superdatorer.
Tillämpningsområdet i detta arbete är ett enkelt lastbalanserat webbkluster baserat på Linux Virtual Server Project (LVS). Målet med projektet beskrivs enkelt att vara att skapa en server med hög prestanda och god tillgänglighet med hjälp av klustringsteknik, vilket möjliggör god skalbarhet, tillförlitlighet och serviceability (vilket syftar på möjligheten att konfigurera och underhålla systemet) [2]. Skalbarhet uppnås genom möjligheten att transparent lägga till eller ta bort noder medan tillförlitlighet uppnås genom förmågan att upptäcka om en nod inte är operativ, och baserat på den informationen göra en
omkonfiguration av klustret [3].
B. Ji et al skriver att allteftersom efterfrågan på nätverkstjänster ökar hos webbsidor så uppstår problem med kapaciteten hos den utrustning som ska leverera tjänsterna, speciellt under de perioder då aktiviteten är som högst.
Därför bör egenskaper som tillgänglighet och skalbarhet tas i beaktande när en nätverkstjänst ska tillhandhållas. Även kostnadseffektivitet blir en viktig aspekt [4]. W. Zhang skriver att Linux Virtual Server hjälper till med att uppnå dessa krav [3].
1.2 Problemformulering och frågor
Y. M. Teo et al. gjorde ett arbete som inkluderade en utvärdering av lastbalanseringsalgoritmer i webbkluster med homogena noder, dessa var Round Robin, och Least-Connection [5]. Arbetet visade att valet av lastbalanseringsalgoritm påverkade webbklustrets genomsnittliga svarstid över ett visst antal anslutningar. Arbetet visade också att den genomsnittliga svarstiden för webbklustret ökade med antalet anslutningar till klustret.
C. A. Bohn skriver att med heterogena kluster har man möjligheten att utöka klustret med maskiner som är mer kraftfulla än de existerande. Nackdelen med detta är att det blir svårare att fördela uppgifterna mellan noderna [6].
LVS har flera algoritmer för ändamålet men ingen undersökning som ställer algoritmerna mot varandra kunde hittas.
Baserat på detta har en frågeställning om valet av algoritm på webbkluster byggda på LVS med heterogena noder utarbetats. De frågor som ställs är:
Hur skiljer sig webbklustrets genomsnittliga svarstid beroende på vilken algoritm som används för lastbalansering?
Hur påverkar valet av algoritm hur många anslutningar klustret kan hantera?
De algoritmer i LVS som utreds är Round Robin, Weighted Round Robin, Least-Connection Scheduling, Weighted Least-Connection Scheduling och Shortest Expected Delay Scheduling.
1.3 Målformulering och nytta
Arbetet förväntas att från en undersökning i en kontrollerad experimentmiljö ge information om hur valet av lastbalanseringsalgoritm kan påverka klustrets genomsnittliga svarstid vid olika belastning (förfrågningar/s).
Denna undersökning utgick från rapporten som skrevs av Y. M. Teo et al.
Resultatet tillför ytterligare kunskap eftersom fler algoritmer ingår i denna undersökning, dessutom har undersökningen gjorts på ett kluster med heterogena noder istället för homogena noder. Resultatet kommer att hjälpa de som redan innehar eller överväger att skaffa ett webbkluster byggt på LVS med heterogena noder med att välja vilken algoritm som ska användas för lastbalansering.
1.4 Ansats och syfte
Ett antal tester kommer att genomföras på ett lastbalanserat webbkluster med tre heterogena noder byggt på LVS och Apache. Noderna är heterogena i form av att de har olika operativsystem (Windows, Unix och Linux) men hårdvaran är densamma. Apache används för att det är den webbserver som har störst andel av marknaden [7]. Samma versionsnummer av Apache används på de tre noderna eftersom det strävas efter att operativsystemet är den enda faktorn som skiljer sig.
För att belasta webbklustret och mäta dess genomsnittliga svarstid används httperf [8] från ett flertal klientmaskiner, detta används för att man kan välja hur många förfrågningar per sekund man vill belasta en webbserver med.
Tester kommer att utföras vid olika hård belastning.
1.5 Avgränsningar
Att använda en (och endast en) lastbalanserare gör att den blir en single point of failure, det vill säga att om den går ner så blir klustret oåtkomligt. Detta löses normalt genom att ha flera lastbalanserare [3]. Eftersom detta arbete inte går ut på att undersöka feltolerans så kommer endast en lastbalanserare att användas.
2 Bakgrund
Detta kapitel förklarar de tekniska delar som behövs för att förstå hur undersökningen har gjorts. Kapitlet börjar med att förklara vad svarstid är, sedan berättar det om vad LVS är och hur det fungerar, det förklarar de sätt man kan välja att bygga klustret på och till slut förklaras de olika
lastbalanseringsalgoritmerna som har ingått i undersökningen.
2.1 Svarstid
Svarstiden är den tid det tar från när det första paketet skickas från klienten, tills att det första datapaketet (innehållande webbsidan som efterfrågas) kommer tillbaka till klienten. Detta innefattar trevägshandskakningen i TCP, sedan skickar klienten ett HTTP GET och webbservern svarar med att skicka webbsidan [9]. Detta förlopp illustreras i Figur 2.1.
Figur 2.1: Händelseförlopp
2.2 Linux Virtual Server
Linux Virtual Server är en programvara som är till för att bygga
lastbalanserade datorkluster. Namnet på programvaran syftar på att den är gjord för att vara helt transparent från en användares perspektiv, det vill säga att en användare ansluter till klustret som om det vore en helt vanlig server utan någon speciell konfiguration på användarens sida. Ett kluster baserat på LVS består av en eller flera lastbalanserare, och så kallade real servers [2].
En lastbalanserare tar hand om inkommande anslutningar till klustrets virtuella IP-adress och vidarebefordrar varje anslutning till en real server, ett stort antal anslutningar kan hanteras samtidigt eftersom funktionaliteten är implementerad i kernelspace, detta medför också att ett stort antal real servers kan användas innan lastbalanseraren blir en flaskhals. En real server är en av de datorer i klustret som konfigurerats för att tillhandhålla en tjänst, det är denna grupp av datorer som utför arbetet som klustret är ämnat att göra.
Vanligtvis är alla real servers identiskt konfigurerade, material som används
kan antingen replikeras mellan dessa datorer eller finnas på en gemensam lagring. [3]
2.3 Keepalived
Keepalived är en tjänst som utför två uppgifter som inte är implementerade direkt i LVS. Den första är att kontrollera status på noderna i ett LVS-kluster för att dynamiskt kunna konfigurera om LVS när en nod slutar svara eller när en nod blir tillgänglig igen. Den andra uppgiften är att implementera ett system för redundans mellan lastbalanserare, detta med hjälp av protokollet VRRP (Virtual Router Redundancy Protocol). Eftersom keepalived är ett program som styr och övervakar LVS kan det också användas som ett konfigurationsgränssnitt för ett LVS-kluster. [10]
2.4 Lastbalanseringstekniker i LVS
Detta kapitel förklarar tre olika sätt som man kan bygga sitt LVS-kluster på.
Dessa kallas VS/NAT, VS/TUN och VS/DR.
2.4.1 VS/NAT
W. Zhang skriver att många nätverk använder privata adresser på grund av att det finns ett begränsat antal IPv4-adresser och på grund av säkerhetsskäl. För att klienter i nätverk med privata adresser ska kunna kommunicera med internet används NAT (Network Adress Translation). Det går i korthet ut på att modifiera pakethuvuden så att klienter tror de kommunicerar med en IP- adress medan servrar vid andra IP-adresser tror att de kommunicerar direkt med klienterna. Detta kan utnyttjas för att bygga en virtuell server som nås på en virtuell IP-adress. När en klient skickar en förfrågan till den virtuella IP- adressen kommer det fram till lastbalanseraren som kontrollerar om
destinationsadressen och destinationsporten matchar för den tjänst som levereras av den virtuella servern. Om det matchar avgör
lastbalanseringsalgoritmen vilken real server som ska ta hand om
anslutningen. Destinationsadressen och destinationsporten skrivs om så att paketet sedan skickas till den real server som har valts. Denna server skickar sitt svar tillbaka till lastbalanseraren som ändrar källadressen och källporten så att det matchar den tjänst som levereras av den virtuella servern [3]. Figur 2.2 visar vilken väg en förfrågan (grön) och ett svar (rött) tar när man
använder VS/NAT, förutsatt att lasbalanseringsalgoritmen har bestämt att anslutningen ska skickas till den webbserver som är nederst i bilden.
Lastbalanserare
Internet
Figur 2.2: VS/NAT
2.4.2 VS/TUN
IP-tunnling är en teknik där man kapslar in IP-datagram inuti IP-datagram.
Detta gör att datagram som har en viss destination kan kapslas in och skickas till en annan destination. Detta kan användas för att bygga en virtuell server där lastbalanseraren tunnlar förfrågningar till de servrar som finns i klustret.
När en server mottager ett inkapslat paket tas inkapslingen bort och den läser av den ursprungliga destinationsadressen. Detta medför att servrarna måste ha ett interface med den virtuella IP-adressen för tjänsten, i tillägg till en vanlig adress som lastbalanseraren använder som destination vid
inkapslingen. När en server svarar på en förfrågan skickar den svaret direkt till den ursprungliga klienten det kom ifrån. En fördel med denna teknik är att servrarna kan vara geografiskt spridda [3]. Figur 2.3 visar vilken väg en förfrågan (grön) och ett svar (rött) tar när man använder VS/TUN, förutsatt att lasbalanseringsalgoritmen har bestämt att anslutningen ska skickas till den webbserver som är nederst i bilden. IP-tunneln visas med en blå
cylinderform.
Lastbalanserare
Internet
Figur 2.3: VS/TUN
2.4.3 VS/DR
Denna teknik liknar VS/TUN men istället för att skicka förfrågningarna via en IP-tunnel ändras MAC-adressen på inkommande trafik för att matcha den server som har valts ut av lastbalanseringsalgoritmen. Detta medför att alla servrar måste ligga på samma nätverkssegment. Även här måste servrarna ha en virtuell IP-adress som är samma som den för den virtuella tjänsten [3].
Eftersom servrarna och lastbalanseraren har samma virtuella IP konfigurerat och de delar nätverkssegment måste man se till att endast lastbalanseraren svarar på ARP-förfrågningar gällande den virtuella IP-adressen, annars skulle en konflikt uppstå och klustret sluta fungera tillfredsställande. Detta problem förekommer även vid VR/TUN om servrarna och lastbalanseraren ligger på samma nätverkssegment [11].
2.5 Lastbalanseringsalgoritmer som utreds
Detta avsnitt förklarar de fem lastbalanseringsalgoritmer som har varit med i undersökningen. Dessa är Round Robin, Least-Connection Scheduling, Weighted Round Robin, Weighted Least-Connection Scheduling och Shortest Expected Delay Scheduling.
2.5.1 Round Robin
Round Robin är den enklaste av algoritmerna som utreds då den inte tar hänsyn till belastning eller beräkningskapacitet hos olika noder. Antalet anslutningar delas lika mellan klustrets noder genom att de skickas i tur och ordning till den ena noden efter den andra. Efter att en anslutning har skickats till den sista noden skickas nästa till den första. Algoritmens sätt att arbeta kan beskrivas som en cykel, en händelse som återupprepas hela tiden. I ett
kluster med tre noder, A B och C schemaläggs förfrågningar till noderna enligt Figur 2.4, där varje ruta representerar en anslutning som schemaläggs till en nod. [12]
A B C A B C A B C
Figur 2.4: Round Robin
2.5.2 Least-Connection Scheduling
Least-Connection Scheduling arbetar dynamiskt utefter hur många
anlutningar som är öppna till de olika noderna i ett kluster. Lastbalanseraren skickar alltid en ny förfrågan till den noden som har minst antal aktiva anslutningar. Information om öppna anslutningar sparas på lastbalanseraren.
Least-Connection Scheduling ägnar sig dåligt om noders beräkningskapacitet skiljer sig mycket, detta på grund av att tillståndet TIME_WAIT i TCP innebär att anslutningar inte registreras som stängda förrän efter en timeout.
Under den tiden kan lastbalanseraren välja att skicka nya förfrågningar till en mindre kraftfull och högt belastad nod istället för en mer kraftfull som har många anslutningar i tillståndet TIME_WAIT. Läsaren hänvisas till RFC 793 [13] för mer information om vilken funktion TIME_WAIT uppfyller i TCP.
Figur 2.5 beskriver hur en anslutning hanteras när Least-Connection
Scheduling används, den gröna linjen illustrerar anslutningens väg från klient till server. [14]
Windows
CentOS
FreeBSD
Nod Anslutningar
Windows 42
CentOS 66
FreeBSD 38
Vilken nod har minst antal öppna anslutningar?
XX
Skicka anslutningen till FreeBSD.
1
2
3
Figur 2.5: Least-Connection Scheduling
2.5.3 Weighted Round Robin
Weighted Round Robin bygger vidare på Round Robin och introducerar en variabel som kallas vikt. Vikten är ett heltal som ställs in för varje nod och används för att ställa in förhållandet mellan noder med olika
beräkningskapacitet [15]. Om en nod A har vikten 1 och nod B har vikten 2 innebär det att för varje anslutning som skickas till nod A skickas två till nod B. Figur 2.6 visar hur förhållandet mellan anslutningar i ett kluster ser ut om nod A har vikten 2, medan noderna B och C har vikten 1. [16]
A A B C A A B C
Figur 2.6: Weighted Round Robin
2.5.4 Weighted Least-Connection Scheduling
Weighted Least-Connection Scheduling bygger vidare på Least-Connection Scheduling men har en ställbar vikt för varje nod. Vikten används för att kompensera för olika beräkningskraft på de olika noderna, noder med hög vikt får fler anslutningar. Till skillnad från Least-Connection Scheduling kan algoritmen alltså lämpa sig i kluster med större skillnader i
beräkningskapacitet mellan noderna. [17]
2.5.5 Shortest Expected Delay Scheduling
Målet med Shortest Expected Delay Scheduling är att skicka en förfrågan till den nod som kommer att svara snabbast, det vill säga den med lägst
förväntad fördröjning. Precis som för Weighted Round Robin och Weighted Least-Connection Scheduling används en vikt för att kompensera för olika beräkningskapacitet på noder. Den förväntade fördröjningen D för en nod i räknas ut på följande vis där C är antalet öppna anslutningar till noden och U är vikten: [18]
3 Metod
Detta kapitel handlar om arbetets ansats, experimentmiljön som byggdes upp, mätverktyget som användes och sedan själva genomförandet av
undersökningen. Kapitlet avslutas med en metoddiskussion.
3.1 Ansats & urval
Empiriska data är uppgifter om ett fenomen som studeras. Under arbetets gång görs en undersökning för att samla in empiriska data som används som grund för arbetet. Arbetet följer därmed en induktiv ansats [19]. I relation till detta arbete innebär det att information om genomsnittlig svarstid för olika lastbalanseringsalgoritmer samlas in för att sedan göra observationer och dra slutsatser utifrån den information som samlades in, det vill säga att
undersökningen går från empiri till teori.
3.2 Experimentmiljö
Ett webbkluster med flera klienter, en lastbalanserare och tre noder (webbservrar) byggdes upp. Lastbalanseringstekniken som valdes var VS/NAT eftersom den har visat sig vara den som används mest [20].
Maskinerna som användes till lastbalanseraren och noderna var av typen Dell PowerEdge 1850, dessa valdes eftersom de var servermaskiner och således hade nätverkskort med Gigabit Ethernet. Klienterna var 20 till antalet och dessa var virtuella maskiner spridda på 5 fysiska maskiner, detta gav 4 virtuella maskiner på varje fysisk maskin. Klienterna anslöts till en switch som också anslöts till lastbalanserarens ena nätverkskort. Lastbalanseraren anslöts sedan via sitt andra nätverkskort till backbone-nätverket som bestod av en switch dit de tre noderna var anslutna. Båda switcharna använde Gigabit Ethernet. För att underlätta installation av programvara användes en gateway till internet men denna kopplades bort innan testerna utfördes. Figur 3.1 visar den topologi som användes när mätningarna gjordes.
4 klienter
Lastbalanserare Switch
Windows
CentOS
FreeBSD 4 klienter
4 klienter 4 klienter
Switch 4 klienter
Figur 3.1: Topologi
På noden Windows installerades Windows Server 2008 R2, på noden CentOS installerades CentOS 6.2 och på noden FreeBSD installerades FreeBSD 9.0.
För att inte introducera flera linuxdistributioner än nödvändigt valdes CentOS även på klienterna och lastbalanseraren.
På lastbalanseraren installerades keepalived version 1.2.2. I dess konfigurationsfil skapades en virtuell server med en eller flera noder (beroende på vilken mätning som utfördes) som så kallade real servers.
På de tre noderna installerades Apache 2.2.22, denna version valdes eftersom det var den nyaste som fanns tillgänglig för Windows. I Windows tankades en installationsfil med förkompilerade binärer. I CentOS och FreeBSD kompilerades programmet från källkod, detta medförde även att eventuell modifikation från utgivarna till de specifika distributionerna kringgicks. De tre noderna konfigurerades för att presentera en webbsida som fanns sparad lokalt på varje nod. De lokala kopiorna av webbsidan var identiska med varandra. Webbsidan var totalt 666 kilobyte stor, för en förhandsgranskning och källkod se [21]. Förutom den konfiguration som behövdes för webbsidan gjordes ingen extra konfiguration i syfte att optimera programmet för de olika operativsystemen, liknande gjordes ingen konfiguration i operativsystemen som hade för syfte att optimera för Apache.
3.3 Mätverktyg
För att mäta klustrets genomsnittliga svarstid installerades programmet httperf på klienten. Som tidigare nämnt valdes detta verktyg eftersom det ger möjligheten att ange hur många anslutningar per sekund som ska skickas från klienten mot klustret, alltså ett sätt att välja hur mycket klustret ska belastas.
Inget annat verktyg som hanterade belastningen på samma sätt kunde hittas.
För att utföra mätningarna exekverades följande kommando:
httperf --hog --server www.test.se --num-conn 300 - -ra 10
Där alternativet --hog tillåter att portar utanför spannet 1024-5000 får
användas. Med alternativet --server anges vilken webbadress som efterfrågas.
Alternativet --num-conn anger det totala antalet anslutningar som skickas och --ra anger hur många anslutningar som skapas per sekund [22]. Varje test konfigurerades så att det varade i 30 sekunder, detta gjordes genom att multiplicera det valda värdet på --ra med 30 vilket gav värdet som skulle sättas på --num-conn. I ovanstående exempel valdes 10 anslutningar per sekund, detta multiplicerades med 30 vilket gav totalt 300 anslutningar.
Alla 20 klientmaskiner hade httperf installerat och alla 20 maskiner användes under alla tester med en jämnt fördelad last. Till exempel för att uppnå 1000 förfrågningar per sekund skickade varje klient 50 förfrågningar per sekund (50 * 20 klienter = 1000). Mätresultatet togs från en klient (och alltid samma klient) eftersom httperf inte kunde startas exakt samtidigt på alla klienter. De klienter som endast användes för att belasta konfigurerades att köra i mer än 30 sekunder så att den klient som resultatet togs ifrån hann både starta och stoppa innan någon av de andra klienterna stoppade (detta för att säkerställa att mätningarna gjordes med korrekt antal anslutningar under hela
mätperiodens 30 sekunder).
Manualen till httperf hävdar att en instans av programmet klarar att skicka upp till 1000 förfrågningar per sekund men att det i praktiken sällan kommer upp till den siffran eftersom fildeskriptorerna kan ta slut. Om detta händer får man felet fd-unavail i httperf [22]. För att komma undan detta problem utökades det maximala antalet möjliga fildeskriptorer per process på
klienterna [23]. Efter utökningen gjordes en testmätning där det framgick att 1000 förfrågningar per sekund fungerade utan att felet fd-unavail uppstod.
Mätningarna med httperf utfördes med minst två minuters väntetid innan nästa mätning påbörjades. Detta på grund av tillståndet TIME_WAIT som nämndes i kapitel 2.5.2.
3.4 Genomförande
Genomförandet består av två faser. Först görs referensmätningar för varje enskild nod i klustret och sedan görs mätningar där alla tre noder är aktiva och lasten fördelas med hjälp av de utvalda lastbalanseringsalgoritmerna.
3.4.1 Referensmätning
Först görs en referensmätning för varje enskild server. Denna mätning görs i samma topologi och med keepalived aktiverat, med den skillnaden att endast en real server är konfigurerad. Detta görs för att fördröjningen i
nätverksutrustningen är tänkt att vara densamma som vid mätningarna med flera noder.
Varje test börjar på 1000 anslutningar per sekund. Sedan höjs belastningen på steg om 1000 tills det område påträffas där den genomsnittliga svarstiden gör en markant stigning, denna stigning indikerar att en server närmar sig
överbelastning [5]. För att noggrannare utröna denna stigning kan mindre intervall tilläggas.
3.4.2 Mätningar med olika algoritmer
Efter referensmätningarna konfigureras klustret för att använda alla noderna.
Den första algoritmen som undersöks är Round Robin, sedan undersöks Weighted Round Robin, Least-Connection Scheduling, Weighted Least- Connection Scheduling och slutligen Shortest Expected Delay Scheduling.
Valet av algoritm sker i konfigurationsfilen keepalived.conf med hjälp av följande parameter:
lb_algo [rr|wrr|lc|wlc|sed]
Där alternativen för algoritmerna visas inom hakparentes i samma ordning som de nämndes ovan.
Varje test börjar på 1000 anslutningar per sekund. Sedan höjs belastningen på steg om 1000.
Persistent Connections är en teknik som gör att nya sessioner från en klient skickas till samma nod i klustret som tidigare. En del applikationer och dynamiska webbsidor kan kräva att anlutningar kommer till samma nod för att fungera korrekt, ett exempel kan vara att en kundvagn sparas på en nod och inte finns tillgänglig på de andra. Tekniken avaktiverades eftersom den kringgår den lastbalansering som utförs av lastbalanseraren samt att ett förhållandevis litet antal datorer användes i testerna. [24]
Weighted Round Robin, Weighted Least-Connection Scheduling och Shortest Expected Delay använder sig av viktning av noderna. Denna vikt används för att kompensera för olika beräkningskraft mellan de olika noderna [15]. För att avgöra förhållandet mellan noderna användes resultatet från referensmätningarna. Vikterna sattes utefter hur många förfrågningar/s som
utgjorde den sista mätningen innan kurvan i linjediagrammen steg hastigt (eftersom denna hastiga stigning indikerar överbelastning [5]). Se Figur 4.1, Figur 4.2 och Figur 4.3 som visar att stigningen inträffade vid 2700, 7000 och 4300 förfrågningar/s. Varje tal delades med hundra, detta ändrade inget på förhållandet och tog bara bort onödiga nollor (till exempel skulle vikterna 1, 1 och 1 ge precis samma resultat som vikterna 10, 10 och 10. Det är
förhållandet mellan dem som räknas). Detta gjorde att vikten för Windows sattes till 27, för CentOS sattes vikten 70 och för FreeBSD sattes vikten 43.
För att verifiera att detta gav en god balansering av lasten användes Performance Monitor i Windows och System Monitor i CentOS och
FreeBSD för att kontrollera att CPU-belastningen var likvärdig på alla noder.
Med System Monitor kontrollerades även lastbalanseraren, både CPU- belastning och nätverksbelastning var mycket låg under mätningarna.
3.5 Metoddiskussion
Anledningen till att tjugo klienter valdes var för att det gav enkla tal vid multiplikation, till exempel 50 * 20 = 1000 istället för 62 * 16 = 992. Tio klienter hade också gett enkla tal, men på grund av osäkerhet kring httperfs maxkapacitet valdes det säkrare före det osäkra. Förvisso hade man kunnat lägga till fler klienter efterhand, men att alltid använda samma antal klienter gjorde att experimentmiljön var densamma under alla mätningar. Tanken bakom att just fyra virtuella maskiner valdes på varje fysisk maskin var att de fysiska maskinerna hade fyrkärniga processorer och därmed kunde använda en kärna per virtuell maskin (varje virtuell maskin konfigurerades till att vara entrådig).
Undersökningen använder sig endast av ett mätverktyg för att mäta den genomsnittliga svarstiden. Om flera verktyg hade använts hade det kunnat ge mer trovärdiga resultat. Anledningen till att inte fler verktyg användes var att httperf var det enda verktyget som hittades där man kunde ställa in lasten genom att sätta hur många förfrågningar per sekund som skulle skickas. Det kan också diskuteras hur verklighetstrogen trafiken som genereras är, httperf skickar samma förfrågning i en bestämd takt. I ett verkligt scenario är det troligt att trafiken varierar i större grad, där antalet användare varierar och även förfrågningarna varierar, där användare surfar på en sida och till exempel öppnar olika delar av den.
Det kan ifrågasättas varför varje test bara utfördes en gång. En diskussion kring detta uppkom och argumentet mot att upprepa testerna var att httperf räknar ut ett medelvärde på tusentals anslutningar och att det därmed inte skulle leda till mycket att göra om mätningarna ett par gånger till och beräkna medelvärdet av ett värde som redan är ett medelvärde. Testmätningar
utfördes som visade att resultaten skilde sig åt i liten grad om samma test utfördes flera gånger.
4 Resultat
Följande kapitel presenterar först resultatet från mätningarna som gjordes, sedan görs en analys av resultatet. Kapitlet omnämner den genomsnittliga svarstiden endast som svarstid för att göra texten lättare att läsa.
4.1 Observationer
Resultaten från mätningarna visas i detta avsnitt i linjediagram, på y-axeln visas svarstiden i millisekunder och på x-axeln visas förfrågningar per sekund.
Figur 4.1: Windows
0 5 10 15 20 25 30 35 40 45 50
1000 2000 3000 4000 5000 6000 7000 8000
Förfrågningar/s
Windows
Svarstid (ms)
Figur 4.2: CentOS
Figur 4.3: FreeBSD
0 5 10 15 20 25 30 35 40 45 50
1000 2000 3000 4000 5000 6000 7000 8000
Förfrågningar/s
CentOS
Svarstid (ms)
0 5 10 15 20 25 30 35 40 45 50
1000 2000 3000 4000 5000 6000 7000 8000
Förfrågningar/s
FreeBSD
Svarstid (ms)
Figur 4.4: Round Robin
Figur 4.5: Least-Connection Scheduling
0 5 10 15 20 25 30 35 40 45 50
1000 2000 3000 4000 5000 6000 7000 8000 9000 10000 11000 12000 13000 14000
Förfrågningar/s
Round Robin
Svarstid (ms)
0 5 10 15 20 25 30 35 40 45 50
1000 2000 3000 4000 5000 6000 7000 8000 9000 10000 11000 12000 13000 14000
Förfrågningar/s
Least-Connection Sch.
Svarstid (ms)
Figur 4.6: Weighted Round Robin
Figur 4.7: Weighted Least-Connection Scheduling
0 5 10 15 20 25 30 35 40 45 50
1000 2000 3000 4000 5000 6000 7000 8000 9000 10000 11000 12000 13000 14000
Förfrågningar/s
Weighted Round Robin
Svarstid (ms)
0 5 10 15 20 25 30 35 40 45 50
1000 2000 3000 4000 5000 6000 7000 8000 9000 10000 11000 12000 13000 14000
Förfrågningar/s
Weighted Least-Connection Sch.
Svarstid (ms)
Figur 4.8: Shortest Expected Delay
4.2 Resultatanalys
I detta avsnitt analyseras resultaten. Genomförandet av arbetet bestod av två faser, referensmätningar och mätningar med de olika algoritmerna. De två faserna analyseras i varsitt avsnitt.
4.2.1 Referensmätningar
Resultaten från referensmätningarna visar att det var stora skillnader mellan noderna när det gäller hur många anslutningar som kunde hanteras innan svarstiden ökade kraftigt (som tidigare nämnt indikerar denna stigning överbelastning [5]). Windows kunde hantera 2700 förfrågningar/s innan svarstiden började stiga nämnvärt, efter detta steg svarstiden väldigt snabbt och redan innan 2800 förfrågningar/s passerade svarstiden 50ms. CentOS kunde hantera 7000 förfrågningar/s och nådde en svarstid på 50ms vid
ungefär 8000 förfrågningar/s. På FreeBSD började svarstiden stiga efter 4300 förfrågningar/s, den högsta svarstiden som noterades var ungefär 30ms vid 4500 förfrågningar/s.
Windows var den som kunde hantera minst antal förfrågningar, medan CentOS kunde hantera mer än dubbelt så många förfrågningar med låg svarstid. FreeBSD kunde hantera fler förfrågningar än Windows men långt färre än CentOS.
Skillnaden i svarstid mellan noderna innan den kraftiga stigningen förekom var väldigt liten och höll sig under denna period under 5 ms, CentOS visade
0 5 10 15 20 25 30 35 40 45 50
1000 2000 3000 4000 5000 6000 7000 8000 9000 10000 11000 12000 13000 14000
Förfrågningar/s
Shortest Expected Delay
Svarstid (ms)
knappt märkbart något lägre svarstid än de två andra innan den kraftiga stigningen började. Det kan därmed se ut som att valet av operativsystem egentligen har liten inverkan på svarstiden men istället påverkas det i stor grad när servern blir överbelastad (som i sin tur gör att svarstiden stiger kraftigt).
Det är oklart varför så stora skillnader påvisades mellan de olika
operativsystemen. I arbetet Webbserveranalys [9] undersöker Hedbrant och Gustavsson svarstiden mellan två olika webbservrar, testerna innefattar bland annat Apache på Windows Server 2008 R2 och Apache på CentOS 5.6. De verktyg som användes, ApacheBench och http_load, arbetar genom att simulera ett antal användare och ett antal anslutningar för varje användare.
Httperf som används i denna rapport utgår från att skicka ett visst antal förfrågningar per sekund, undersökningarna är således ej direkt jämförbara.
Hedbrant och Gustavssons mätningar visar att svarstiden är högre när Windows används jämfört med när CentOS används. Skillnaden mellan de båda operativsystemen blir tydligare i samband med att lasten blir högre.
Hedbrandt och Gustavsson nämner det faktum att inget grafiskt gränssnitt användes på CentOS som en möjlig fördel för CentOS i deras tester. I detta arbete användes grafiska gränssnitt i alla operativsystem och till trots för skillnader i både mätverktyg och testmiljö syns liknande skillnader mellan Windows och CentOS i detta arbete.
4.2.2 Algoritmer
Precis som på de enskilda noderna höll sig svarstiden under 5 på alla mätningar tills den punkt nåddes där svarstiden steg kraftigt. När Round Robin användes hände detta mellan 8 000 och 9 000 förfrågningar/s.
Eftersom Round Robin fördelar lasten jämnt borde en ökning av svarstiden förekomma när den långsammaste noden når sin kapacitetsgräns. För att undersöka om detta kunde stämma gjordes en uträkning med ungefärliga siffror baserade på mätningens resultat. Eftersom klustret med Round Robin nådde sin gräns för överbelastning någonstans mellan 8 000 och 9 000 förfrågningar/s gjordes följande uträkning:
Av detta framgår att varje nod vid detta tillfälle får 2 833 förfrågningar/s.
Detta är väldigt nära den punkt där den sämsta noden visade sin hastiga stigning i svarstid (enligt mätningarna mellan 2 700 och 2 800
förfrågningar/s).
Least-Connection Scheduling skilde sig från de andra algoritmerna genom att den inte i samma grad visade en kraftig ökning. Istället skedde en
långsammare ökning där svarstiden nådde 5 ms vid 9 000 förfrågningar/s och 35 ms vid 13 000 förfrågningar/s. Detta kan tyda på att algoritmen i viss grad kan kompensera för att noder har olika beräkningskraft trots att den inte är designad för detta. Det ser ut som att algoritmen lyckas hålla nere svarstiden när belastningen ökar, men inte såpass mycket att svarstiden håller sig på samma låga nivå som med de algoritmerna som är gjorda för att hantera heterogena noder (eftersom de fördelar lasten på ett bättre sätt). Round Robin är den andra algoritmen i undersökningen som inte är designad för
heterogena noder, orsaken till att den inte visar samma beteende kan vara att den fungerar fullständigt statiskt, därmed kommer en hastig ökning i svarstid när den svagaste noden blir överbelastad.
Weighted Round Robin presterade inte mycket bättre än Round Robin. Där sistnämnda hade sin stora ökning mellan 8 000 och 9 000 anslutningar per sekund hade den viktade varianten sin stora ökning mellan 9 000 och 10 000 förfrågningar/s.
Weighted Least-Connection Scheduling visade inte samma långsamma ökning som Least-Connection Scheduling. Istället gick svarstiden snabbt uppåt mellan ungefär 12 000 och 13 000 förfrågningar/s. En bit innan 13 000 förfrågningar/s ser det ut som att den hastiga ökningen avtar något. Detta kan bero på att alla tre noder inte blir överbelastade exakt samtidigt och att linjediagrammet därför visar en ”trappstegseffekt” (som skulle kunna visa upp till tre ”trappsteg” eftersom klustret har tre noder). Även de andra algoritmerna visar denna effekt i större eller mindre grad.
Shortest Expected delay Scheduling presterade likt Weighted Least- Connection Scheduling och ökade hastigt mellan 12 000 och 12 500 förfrågningar/s.
Optimalt sett borde ett webbkluster klara av att hantera lika många
anslutningar som alla dess noder tillsammans klarar var för sig, eftersom alla noder då går på maximal belastning och därmed har fått en optimal
lastbalansering. Genom att välja approximerade värden där den stora stigningen i svarstid började enligt referensmätningarna ges en bild av vad klustret skulle kunna klara av med en optimal fördelning av lasten:
Enligt mätresultaten var Weighted Least-Connection Scheduling och Shortest Expected Delay de algoritmer som kom närmst detta teoretiska värde, där båda algoritmerna gav en stor stigning i svarstid vid ungefär 12000
förfrågningar/s. Om ett antagande görs om att 14000 är en korrekt siffra för klustrets beräkningskapacitet skulle det innebära att de algoritmer som presterade bäst i detta fall kunde utnyttja ungefär 86% av den
beräkningskapacitet som fanns tillgänglig.
Det kan tyckas konstigt att valet av algoritm i liten grad påverkar svarstiden och i större grad påverkar när klustret når sin kapacitetsgräns. Detta fenomen beror möjligtvis på att det är de olika operativsystemen som utgör klustrets heterogena natur. Hade det varit hårdvaran som skiljde noderna åt hade resultatet kanske sett annorlunda ut, då det i sanning skulle medföra olika beräkningskapacitet. Istället kan det vara så att att det ”tar stopp” på grund av att operativsystemen är olika konfigurerade och att detta gör att de inte nödvändigtvis utnyttjar all den kapacitet som finns i hårdvaran.
5 Avslutning
Detta kapitel innehåller en sammanfattning om arbetet som har gjorts och vilken slutsats som drogs, vidare ges några förslag på vidare forskning.
5.1 Sammanfattning och slutsatser
Denna rapport behandlade en undersökning där olika
lastbalanseringsalgoritmer i Linux Virtual Server ställdes mot varandra.
Undersökningen gjordes i ett webbkluster med tre heterogena noder. Noderna hade samma hårdvara men var heterogena i den meningen att olika
operativsystem användes. Operativsystemen som ingick i undersökningen var Windows Server 2008 R2, CentOS 6.2 och FreeBSD 9.0.
Serverprogramvaran som användes på noderna var Apache. Den ena faktorn som undersöktes och jämfördes mellan de olika algoritmerna var klustrets genomsnittliga svarstid beroende på hur stor belastning det utsattes för. Den andra faktorn var hur valet av algoritm påverkade hur många anslutningar som kunde hanteras av klustret. Dessa faktorer undersöktes med hjälp av mätningar som gjordes med verktyget httperf. Undersökningen gav svar på hur ett heterogent webbklusters genomsnittliga svarstid och arbetskapacitet kan skilja sig åt beroende på vilken algoritm som används för lastbalansering.
Resultaten i de olika mätningarna visade att den genomsnittliga svarstiden höll sig mycket låg (under 5 ms) tills en hastig stigning inträffade. Stigningen inträffade vid olika belastning beroende på vilken algoritm som användes.
Least-Connection Scheduling avvek något från detta då stigningen inte var lika kraftig. Det är möjligt att algoritmerna hade betett sig annorlunda om klustret hade varit heterogent i form av olika hårdvara. Det skulle också kunna ha sett annorlunda ut om klustret belastades på ett annat sätt, till exempel med variabel belastning.
Slutsatsen är att Weighted Least-Connection Scheduling och Shortest Expected Delay Scheduling fungerade bäst i denna experimentmiljö där de kunde hantera många förfrågningar innan den genomsnittliga svarstiden gjorde sin hastiga ökning. Least-Connection visade sig också fungera vid ett stort antal förfrågningar men på bekostnad av en högre genomsnittlig
svarstid. Round Robin gjorde som väntat (på grund av hur den fungerar) att klustret presterade sämre, men även Weighted Round Robin visade sig prestera sämre i jämförelse med de andra algoritmerna.
5.2 Bidrag
Denna undersökning utgick från rapporten som skrevs av Y. M. Teo et al.
Resultatet tillför ytterligare kunskap eftersom fler algoritmer ingår i denna undersökning, dessutom har undersökningen gjorts på ett kluster med
heterogena noder istället för homogena noder. Förhoppningen är att resultatet kommer att hjälpa de som redan innehar eller avväger att skaffa ett
webbkluster byggt på LVS med heterogena noder med att välja vilken algoritm som ska användas för lastbalansering.
5.3 Fortsatt forskning
Eftersom att det var de olika operativsystemen som utgjorde klustrets heterogena natur är det naturligt att föreslå en liknande undersökning där endast hårdvaran skiljer sig åt på noderna. Även andra faktorer i ett kluster skulle kunna ändras, man skulle till exempel kunna bygga ett kluster av typen VS/TUN med geografiskt spridda noder och undersöka detta närmare.
Det skulle kunna vara av intresse att göra ett arbete som reder ut varför så stora skillnader förekommer mellan olika operativsystem när det gäller svarstid och hur många anslutningar som kan hanteras av Apache. Ett sådant arbete skulle kunna vara till hjälp för att optimera miljöer som av någon anledning kräver att ett visst operativsystem används.
Det är även naturligt att föreslå undersökningar av annan klustringsmjukvara än LVS.
Ett ytterligare förslag kan vara att finna andra mätmetoder än httperf, där det går att generera en mer verklighetstrogen belastning (en som varierar i större grad).
6 Referenser
[1] L. Perkov, N. Pavković and J. Petrović, "High-Availability Using Open Source Software," in 2011 Proceedings of the 34th International Convention MIPRO, Opatija, 2011.
[2] "What is virtual server?," 28 May 1998. [Online]. Available:
http://www.linuxvirtualserver.org/whatis.html. [Accessed 29 May 2012].
[3] W. Zhang, "Linux Virtual Server for Scalable Network Services," in Linux Symposium, Ottawa, 2000.
[4] B. Ji, J. Zhou, Q. Liping and C. Kangsheng, "An implementation of LVS- based highly-available Radius server," in IET International Conference on Wireless Mobile and Multimedia Networks Proceedings, Hangzhou, 2006.
[5] Y. M. Teo and R. Ayani, "Comparison of Load Balancing Strategies on Cluster-based Web Servers," Transactions of the Society for Modeling and Simulation, pp. 185-195, 2001.
[6] C. A. Bohn, "Asymmetric Load Balancing on a Heterogeneous Cluster of PCs," Defense Technical Information Center, Washington, 1999.
[7] "March 2012 Web Server Survey," Netcraft Ltd, 5 March 2012. [Online].
Available: http://news.netcraft.com/archives/2012/03/05/march-2012-web- server-survey.html. [Accessed 31 May 2012].
[8] "httperf," [Online]. Available: http://code.google.com/p/httperf/. [Accessed 26 June 2012].
[9] J. Hedbrandt and M. Gustavsson, "Webbserveranalys," Linnéuniversitetet, Kalmar, 2011.
[10] A. Cassen, "User Guide," [Online]. Available:
http://www.keepalived.org/pdf/UserGuide.pdf. [Accessed 14 August 2012].
[11] "ARP problem in VS/TUN and VS/DR," [Online]. Available:
http://www.linuxvirtualserver.org/docs/arp.html. [Accessed 24 August 2012].
[12] "Round-Robin Scheduling," 3 February 2006. [Online]. Available:
http://kb.linuxvirtualserver.org/wiki/Round-Robin_Scheduling. [Accessed 11 August 2012].
[13] J. Postel, "RFC 793 - Transmission Control Protocol," University of Southern California, Marina del Rey, 1981.
[14] "Least-Connection Scheduling," 1 October 2005. [Online]. Available:
http://kb.linuxvirtualserver.org/wiki/Least-Connection_Scheduling.
[Accessed 11 August 2012].
[15] "Server Weight and Scheduling," Red Hat, [Online]. Available:
https://access.redhat.com/knowledge/docs/en-
US/Red_Hat_Enterprise_Linux/4/html/Virtual_Server_Administration/s2- lvs-sched-weight-VSA.html. [Accessed 9 August 2012].
[16] "Weighted Round-Robin Scheduling," 5 November 2005. [Online].
Available: http://kb.linuxvirtualserver.org/wiki/Weighted_Round- Robin_Scheduling. [Accessed 11 August 2012].
[17] "Weighted Least-Connection Scheduling," 17 December 2006. [Online].
Available: http://kb.linuxvirtualserver.org/wiki/Weighted_Least- Connection_Scheduling. [Accessed 11 August 2012].
[18] "Shortest Expected Delay Scheduling," 13 April 2007. [Online]. Available:
http://kb.linuxvirtualserver.org/wiki/Shortest_Expected_Delay_Scheduling . [Accessed 11 August 2012].
[19] L. T. Erikson and F. Wiedersheim-Paul, Att utreda forska och rapportera, Malmö: Liber, 2006.
[20] "LVS Survey," [Online]. Available:
http://www.linuxvirtualserver.org/survey/survey_200101.html. [Accessed 25 August 2012].
[21] "flashmo.com," [Online]. Available:
http://www.flashmo.com/preview/flashmo_146_dark_night. [Accessed 22 June 2012].
[22] "httperf(1)," 27 May 2007. [Online]. Available:
http://www.hpl.hp.com/research/linux/httperf/httperf-man-0.9.txt.
[Accessed 5 July 2012].
[23] "Increase the number of file descriptors on Centos and Fedora Linux,"
[Online]. Available: http://pro.benjaminste.in/post/318453669/increase- the-number-of-file-descriptors-on-centos-and. [Accessed 26 August 2012].
[24] "LVS: Persistent Connection (Persistence, Affinity in cisco-speak),"
[Online]. Available: http://www.austintek.com/LVS/LVS-
HOWTO/HOWTO/LVS-HOWTO.persistent_connection.html. [Accessed 18 August 2012].
[25] L. Perkov, N. Pavković och J. Petrović, ”High-Availability Using Open Source Software,” i 2011 Proceedings of the 34th International Convention MIPRO, Opatija, 2011.
[26] "LVS Scheduling Overview," Red Hat, [Online]. Available:
https://access.redhat.com/knowledge/docs/en-
US/Red_Hat_Enterprise_Linux/4/html/Virtual_Server_Administration/s1- lvs-scheduling-VSA.html. [Accessed 9 August 2012].
[27] "Red Hat Enterprise Linux AS 2.1: The Official Red Hat Enterprise Linux AS Installation Guide," [Online]. Available:
http://docs.redhat.com/docs/en-
US/Red_Hat_Enterprise_Linux/2.1/html/AS_Install_Guide/s1-lvs-
scheduling.html#S2-LVS-SCHED-WEIGHT. [Accessed 9 August 2012].
