Når et website eller en applikation bliver langsom under høj belastning, er afhængig af én enkelt server eller kræver nedetid ved vedligeholdelse, kan en load balancer være en del af løsningen.
En load balancer fordeler trafik mellem flere servere og kan samtidig kontrollere, om de enkelte servere fungerer. Hvis én server bliver utilgængelig, kan trafikken i stedet sendes til en anden.
Det kan give bedre oppetid, mere fleksibel vedligeholdelse og mulighed for at håndtere voksende belastning.
Hvad er en load balancer?
En load balancer fungerer som et fordelingspunkt (en reverse proxy) foran to eller flere servere. Brugerne rammer load balanceren, som sender trafikken videre til en server, der er klar til at håndtere forespørgslen.
Formålet er typisk at forbedre oppetid, performance og mulighed for skalering af løsningen.
Hvornår giver en load balancer mening?
Et af de tydeligste tegn er, at hele løsningen afhænger af én server.
Hvis jeres webshop, kundeportal eller applikation stopper, når én bestemt server fejler, har I et såkaldt single point of failure.
Med flere servere bag en load balancer kan trafikken fordeles mellem de servere, der er tilgængelige. Load balanceren kan samtidig udføre såkaldte health checks, som løbende kontrollerer, om serverne svarer korrekt.
Hvis en server ikke længere svarer, kan den tages ud af den aktive trafik, indtil den fungerer igen.
Performance kan være et andet tegn. En løsning fungerer måske fint det meste af dagen, men bliver langsom, når mange brugere logger ind samtidig, under kampagner eller ved andre spidsbelastninger.
Her kan flere servere bag en load balancer være et alternativ til hele tiden at gøre den samme server større.
“En load balancer handler ikke kun om at håndtere meget trafik. Den kan være mindst lige så vigtig, når man vil reducere afhængigheden af én enkelt server.”
Kan load balancing mindske nedetid?
Ja, og det er en af de vigtigste anvendelser og fordele ved teknologien.
Hvis to webservere ligger bag en load balancer, kan den ene eksempelvis tages ud af drift under patching, opdatering eller genstart. Imens kan den anden så fortsætte med at håndtere trafikken.
Når arbejdet er færdigt, sættes serveren tilbage i drift. Derefter kan den anden server vedligeholdes.
Load balancing er derfor ikke kun relevant for meget store websites med enorme trafikmængder. Det kan også give god mening for mere almindelige forretningskritiske løsninger, hvor nedetid er et problem.
Skal serveren bare have mere CPU og RAM?
Nogle gange er svaret ja.
Hvis en server ganske enkelt mangler CPU eller RAM, kan det være både billigere og enklere at tilføre flere ressourcer. Det bør derfor normalt undersøges først.
Men hvis I igen og igen er nødt til at gøre den samme server større, kan det være et tegn på, at arkitekturen bør ændres.
I stedet for én stadig større server kan applikationen måske fordeles på flere servere, som arbejder sammen. Load balanceren sørger herefter for at fordele trafikken mellem dem.
Det giver mulighed for både mere kapacitet og mindre afhængighed af den enkelte server.
5 tegn på at load balancing er værd at undersøge
- Hele løsningen stopper hvis én server fejler
- Performance falder ved høj belastning
- Vedligeholdelse kræver ofte nedetid
- I bliver ved med at tilføre mere CPU og RAM
- Løsningen skal kunne vokse markant
Hvad løser en load balancer ikke?
En load balancer løser ikke automatisk alle performance- eller driftsproblemer.
Hvis et langsomt website skyldes en dårlig databaseforespørgsel, hjælper flere webservere ikke nødvendigvis.
Og hvis alle webserverne stadig er afhængige af den samme database, kan databasen fortsat være et single point of failure.
Derfor bør man se på hele infrastrukturen og ikke kun på den server, brugeren rammer først.
Selve applikationen skal også kunne fungere på flere servere. Sessions, uploads og andre data skal eksempelvis kunne håndteres korrekt, når trafikken fordeles mellem forskellige systemer.
Hvordan bruger vi load balancing hos Rackhosting?
Hos Rackhosting ser vi normalt load balancing som en del af den samlede infrastruktur frem for et isoleret produkt.
Det kan eksempelvis indgå i web- og applikationsmiljøer, Virtual Private Cloud, Private Cloud og Kubernetes hosting, hvor flere systemer skal arbejde sammen.
På vores Virtuozzo/OpenStack-baserede cloudplatform kan load balancing indgå sammen med blandt andet virtuelle netværk, routing, firewall og NAT.
Et relativt enkelt miljø kan bestå af en load balancer foran to webservere. I større løsninger kan den indgå i en bredere arkitektur med flere applikationsservere, database, storage, firewall og andre redundante komponenter.
Vi starter derfor normalt med problemet:
Er det performance, der er udfordringen? Er én server blevet for kritisk? Skal vedligeholdelse kunne gennemføres med mindre påvirkning? Eller skal løsningen kunne skaleres i takt med, at behovet vokser?
Har du brug for en load balancer?
Ikke nødvendigvis.
Nogle gange er den rigtige løsning blot flere ressourcer på den eksisterende server. Andre gange ligger problemet i databasen, storage, netværket eller selve applikationen.
Men hvis én server er blevet kritisk for hele løsningen, performance svinger markant, eller nedetid er blevet et problem, er load balancing værd at undersøge.
Det vigtigste er ikke at få en load balancer. Det vigtigste er at finde ud af, hvad der skaber problemet – og bygge infrastrukturen derefter.
Hvad kan du selv undersøge?
Start med at finde ud af, hvor flaskehalsen faktisk ligger. Er det CPU, RAM, storage, database eller netværk?
Vurder derefter konsekvensen af nedetid. Er 30 minutters utilgængelighed acceptabelt, eller betyder det tabt omsætning eller utilgængelige kundesystemer?
Det er også værd at spørge jeres udvikler eller softwareleverandør, om applikationen er bygget til at kunne køre på flere servere.
Hvad kan Rackhosting hjælpe med?
Vi kan blandt andet hjælpe med at vurdere:
- serverkapacitet og belastning
- netværk og trafikfordeling
- redundans og single points of failure
- health checks og tilgængelighed
- den samlede hostingarkitektur
Hvis selve applikationen skal ændres for at fungere på flere servere, sker det typisk i samarbejde med kunden eller dennes udvikler.
