Lastbalansering på tvers av servere

En lastbalanserer mottar klientforespørsler på én felles virtuell IP-adresse (VIP) på front-end-siden og videresender hver forespørsel til én av back-end-serverne. Klientene kommuniserer bare med VIP-en og vet ikke hvor mange servere som finnes bak den. Lastbalansereren kan være en dedikert maskinvareenhet eller programvare, og den gjøres ofte selv redundant for å unngå å bli et SPOF.

Lastbalanserere bruker algoritmer for å velge en server. Round robin går gjennom serverne i tur og orden. Færrest forbindelser velger serveren med færrest aktive økter. Vektede metoder favoriserer kraftigere servere. Ved å velge riktig algoritme tilpasses trafikken serverkapasiteten, slik at servergruppen holdes jevnt og effektivt belastet.

En lastbalanserer utfører kontinuerlig helsesjekker ved å undersøke hver server for å bekrefte at den svarer. Hvis en server ikke består kontrollen, slutter lastbalansereren å sende forespørsler til den til den er tilbake i drift. Dette er grunnen til at lastbalansering også er et verktøy for høy tilgjengelighet: Servere som svikter, fjernes automatisk fra rotasjonen, slik at brukerne aldri sendes til en server som er nede.

Noen applikasjoner krever at en brukers forespørsler fortsetter å gå til samme server, for eksempel for å bevare en handlekurv som ligger i minnet på den serveren. Øktpersistens (eller «sticky sessions») knytter en klient til én server så lenge økten varer. Uten dette kan en bruker som flyttes mellom servere, miste tilstanden midt i en oppgave.

Lastbalanserere opererer på ulike lag. En lag 4-lastbalanserer fordeler trafikk basert på IP-adresse og TCP-/UDP-port. Den er rask, men kjenner ikke innholdet. En lag 7-lastbalanserer leser applikasjonsdata, for eksempel HTTP-URL-er, og kan derfor utføre intelligent ruting ved å sende /images til én servergruppe og /api til en annen. Lag 7 er kraftigere, men gjør mer arbeid for hver forespørsel.

Lastbalanserere utfører ofte SSL/TLS-avlastning (terminering): De håndterer krypteringsarbeidet for klientene og dekrypterer trafikken, slik at back-end-serverne slipper å gjøre det. Dette frigjør CPU-kapasitet på serverne til applikasjonen og samler sertifikathåndteringen på lastbalansereren. Det er en vanlig grunn til at organisasjoner plasserer en intelligent lag 7-lastbalanserer foran webserverne.

Hvis all trafikk går gjennom én lastbalanserer, blir denne en enkeltfeilskilde. Derfor distribueres lastbalanserere i par, enten active-active eller active-passive, med failover mellom dem. Verktøyet som sørger for tilgjengelighet, må selv ha høy tilgjengelighet. Et redundant lastbalansererpar gjør hele front-end-løsningen robust.

Skyleverandører tilbyr lastbalansering som en administrert tjeneste som skaleres automatisk etter behov. Kombinert med automatisk skalerte servergrupper kan skyen legge til og fjerne servere bak lastbalansereren basert på belastningen, og deretter fordele trafikken mellom serverne som kjører. Denne elastiske modellen er en viktig grunn til at skyapplikasjoner kan håndtere svært varierende og omfattende trafikk på en god måte.

Lastbalansering og redundans utfyller hverandre for å gi god ytelse og høy tilgjengelighet. Redundans gir ekstra kapasitet og komponenter, mens lastbalansering aktivt utnytter denne kapasiteten ved å fordele arbeidet og styre trafikken rundt feil i sanntid. Sammen gjør de at en tjeneste kan forbli rask under høy belastning og være tilgjengelig selv når enkeltservere svikter. Dette er en grunnpilar i robust design.

De har lært om lastbalansering. Viktige punkter:

• Lastbalansering fordeler trafikk mellom servere for å gi skalerbarhet og tilgjengelighet.
• Klientene når en virtuell IP-adresse, og lastbalansereren velger en back-end-server.
• Algoritmene omfatter round robin, færrest forbindelser og vektede metoder.
• Helsesjekker fjerner servere som har sviktet, mens persistens holder øktene knyttet til samme server.
• Lag 4 kontra lag 7; lastbalansererne gjøres selv redundante.