I computernetværks terminologi er belastningsbalancering eller belastningsbalancering ( eng. load balancing ) en metode til at fordele opgaver mellem flere netværksenheder (for eksempel servere ) for at optimere ressourceanvendelsen, reducere forespørgselstjenestetiden, horisontal klyngeskalering ( dynamisk tilføjelse/fjernelse af enheder), samt sikring af fejltolerance ( redundans ).
På computere fordeler belastningsbalancering belastningen på tværs af flere computerressourcer såsom computere, computerklynger , netværk, CPU'er eller diske. Formålet med belastningsbalancering er at optimere ressourceforbruget, maksimere gennemløbet, forbedre responstiden og forhindre, at en enkelt ressource bliver overbelastet. Brug af flere belastningsbalanceringskomponenter i stedet for en enkelt komponent kan forbedre pålideligheden og tilgængeligheden gennem redundans . Lastbalancering involverer normalt tilstedeværelsen af speciel software eller hardware, såsom en flerlagsswitch eller et domænenavnssystem, som en serverproces.
Lastbalancering adskiller sig fra en fysisk forbindelse ved, at lastbalancering deler trafikken mellem netværksgrænseflader i en netværkssocket (OSI lag 4-model), mens linkforbindelse involverer opdeling af trafik mellem fysiske grænseflader på et lavere niveau eller i en pakke (OSI) modellag 3) eller over en kommunikationskanal (OSI modellag 2).
Eksempler på enheder, som afbalancering kan anvendes til:
Load balancing kan bruges til at styrke en serverfarm med mere end én server. Det kan også give dig mulighed for at fortsætte med at arbejde selv under forhold, hvor flere executive-enheder (servere) har svigtet. På grund af dette øges fejltolerancen, og det bliver muligt dynamisk at justere de brugte computerressourcer ved at tilføje/fjerne executive-enheder i klyngen .
En af de mest brugte belastningsbalanceringsapplikationer er at skabe en enkelt internettjeneste med flere servere , nogle gange kendt som serverfarme . Belastningsbalanceringssystemer omfatter typisk populære websteder , store onlinebutikker , FTP-websteder ( File Transfer Protocol ), Domain Name System (DNS) og databaser.
For internettet er en load balancer normalt et program, der lytter på den port, hvor eksterne klienter forbinder til tjenester. Loadbalanceren videresender anmodninger til en af serverens "servere", som normalt svarer på lastbalanceren. Dette gør det muligt for load balanceren at reagere på klienten uden at kende den interne adskillelse af bekymringer. Det giver også klienter mulighed for at kontakte back-end-servere direkte, hvilket kan have sikkerhedsfordele og skjule den interne netværksstruktur og forhindre angreb på kernen, netværksstakken eller ikke-relaterede tjenester, der kører på andre porte.
Nogle load balancere giver en mekanisme til at gøre noget særligt i tilfælde af, at hele serverens backend ikke er tilgængelig. Dette kan omfatte omdirigering til et backup-balanceringssystem eller visning af en fejlmeddelelse.
Det er også vigtigt, at load balanceren ikke bliver et enkelt fejlpunkt. Typisk implementeres belastningsbalancere i høj tilgængelighed , som også kan replikere persistenssessioner, hvis det kræves til en bestemt applikation. [en]
En alternativ metode til belastningsbalancering, der ikke nødvendigvis kræver speciel værtssoftware eller hardware, kaldes DNS robin round . I denne teknik er flere IP-adresser knyttet til det samme domænenavn ; klienter skal vælge en server at oprette forbindelse til. I modsætning til at bruge en dedikeret belastningsbalancer, giver denne teknik klienter mulighed for at have flere servere. Teknikken har sine fordele og ulemper, afhængigt af graden af kontrol over DNS-serverne og granulariteten af den krævede belastning.
En anden, mere effektiv metode til belastningsbalancering ved hjælp af DNS er at uddelegere www.example.org som et underdomæne, hvor zonen vedligeholdes af hver af de samme servere, der betjener webstedet. Denne teknik fungerer særligt godt, hvor individuelle servere er spredt geografisk på internettet. For eksempel:
one.example.org A 192.0.2.1 two.example.org A 203.0.113.2 www.example.org NS one.example.org www.example.org NS two.example.orgZonefilen for www.example.org på hver server er dog forskellig på en sådan måde, at hver server bestemmer, hvordan IP-adressen skal bruges som en A-record. På enkelt zone filserver til rapportering www.example.org:
@ i en 192.0.2.1På server to indeholder den samme zonefil:
@i en 203.0.113.2Når den første server er nede, reagerer dens DNS således ikke, og webtjenesten modtager ingen trafik. Hvis linjen på én server er overbelastet, giver den upålidelige DNS-tjeneste mindre http-trafik til at nå den server. Derudover løses det hurtigste DNS-svar næsten altid fra netværket på den nærmeste server, på grund af geo-følsom load balancing. En kort TTL til en A-record giver dig mulighed for hurtigt at omdirigere trafik, hvis serveren går ned. Muligheden for, at denne teknik kan resultere i, at individuelle klienter kan skifte mellem separate servere midt i en session, skal overvejes.
Mange planlægningsalgoritmer bruges af belastningsbalancere til at bestemme, hvilken server der skal sendes en anmodning til. Simple algoritmer inkluderer tilfældig udvælgelse eller round robin . Mere sofistikerede belastningsbalancere kan tage højde for yderligere faktorer, såsom hvilke servere der rapporterede belastning, langsommere svartider, op/ned status (bestemt af en eller anden form for pollingovervågning), antal aktive forbindelser, geografisk placering, muligheder eller hvor meget trafik han blev for nylig udnævnt.
Et vigtigt problem, når du kører en belastningsbalanceringstjeneste, er, hvordan man håndterer information, der skal gemmes på tværs af flere anmodninger i en brugersession. Hvis disse oplysninger er gemt lokalt på en enkelt backend-server, vil efterfølgende anmodninger, der kommer fra forskellige backend-servere, ikke kunne finde dem. Dette kan være cacheoplysninger, der kan genberegnes, i hvilket tilfælde en belastningsbalanceringsanmodning til en anden backend-server løser ydeevneproblemet.
Ideelt set bør klyngen af servere bag load balanceren være sessionsbevidst, så hvis en klient opretter forbindelse til en server på et hvilket som helst tidspunkt, er brugerens historie med kommunikation med en bestemt server irrelevant. Dette opnås normalt ved hjælp af en delt database eller en databasesession i hukommelsen, såsom memcached .
En grundlæggende løsning på sessionsdataproblemet er at sende alle anmodninger i en brugers session sekventielt til den samme server. Dette kaldes vedholdenhed eller klæbrighed . En væsentlig ulempe ved denne teknologi er manglen på automatisk failover : hvis serveren går ned, bliver dens sessionsinformation utilgængelig, alle sessioner går tabt. Det samme problem gælder normalt for serverens centrale database; selvom webserverne er "stateless" (stateless) og ikke "sticky" (sticky), den centrale database (se nedenfor).
Tildelingen til en bestemt server kan være baseret på brugernavnet, klientens IP-adresse eller kan være tilfældig. På grund af ændringer i klientens opfattede adresse som følge af DHCP , Network Address Translation og Web Proxy kan denne metode være upålidelig. Tilfældige job skal huskes af lastbalanceren, som belaster lageret. Hvis belastningsbalanceren udskiftes eller går ned, kan disse oplysninger gå tabt, og job skal muligvis slettes efter et bestemt tidsrum eller i perioder med høj belastning for at undgå at overskride den tilgængelige plads til tildelingstabellen. Tilfældig tildelingsmetoden kræver også, at klienter understøtter nogle indstillinger, hvilket kan være et problem, for eksempel når webbrowseren har deaktiveret cookielagring. Komplekse belastningsbalancere bruger flere vedholdenhedsmetoder for at undgå nogle af ulemperne ved en metode.
En anden løsning er at gemme sessionsdata i en DB . Generelt er dette dårligt for ydeevnen, da det øger belastningen på databasen: databasen er bedre brugt til at gemme information, der er mindre flygtig end sessionsdata. For at forhindre databasen i at blive et enkelt fejlpunkt, og for at forbedre skalerbarheden , replikeres databaser ofte på tværs af flere maskiner, og belastningsbalancering bruges til at fordele belastningsindekset på tværs af disse replikaer. Microsoft ASP.net State Server - teknologien er et eksempel på en databasesession. Alle servere i webfarmen gemmer sessionsdata på Master State Server-serveren og enhver server i farmen kan hente dataene.
I meget almindelige tilfælde, hvor klienten er en webbrowser, er en enkel, men effektiv tilgang at gemme sessionsdata i selve browseren. En måde at opnå dette på er at bruge browsercookies , krypterede tidsstempler. En anden måde er URL-omskrivning. Lagring af sessionsdata på klienten er normalt den foretrukne løsning: Loadbalanceren kan derefter frit vælge enhver server til at behandle anmodningen. Denne metode til behandling af tilstandsdata er imidlertid ikke velegnet til nogle komplekse forretningslogiske scenarier, hvor sessionstilstanden er en stor nyttelast, og det ikke er muligt at genlæse den med hver anmodning til serveren. URL-omskrivning har alvorlige sikkerhedsproblemer, fordi slutbrugeren nemt kan ændre de indsendte URL'er og dermed ændre sessionsstrømmene.
En anden løsning til lagring af vedvarende data er at knytte et navn til hver datablok, bruge en distribueret hash-tabel til pseudo-tilfældigt at tildele et navn til en af de tilgængelige servere og derefter gemme denne blok af data på den udpegede server.
Hardware og software load balancere kan have forskellige specielle egenskaber. Hovedegenskaben ved en load balancer er at være i stand til at distribuere indgående anmodninger på tværs af flere servere i en klynge i henhold til en planlægningsalgoritme. De fleste af de leverandørspecifikke egenskaber, der er anført nedenfor:
Belastningsbalancering kan være nyttig i redundante linkapplikationer. For eksempel kan en virksomhed have flere internetforbindelser, hvilket giver adgang til netværket, hvis en af forbindelserne er nede. I fejlsikre systemer vil det betyde, at det ene link er til normal brug, og det andet kun bruges, hvis hovedlinket fejler.
Ved at bruge belastningsbalancering kan begge links være optaget hele tiden. Enheden eller programmet kontrollerer tilstedeværelsen af alle links og vælger stien til afsendelse af pakker. Brug af flere links på samme tid øger den tilgængelige båndbredde.
IEEE-standarden godkendte IEEE 802.1 rr-standarden i maj 2012 [2] er også kendt og dokumenteret i de fleste bøger som Shortest Path (SCP). KPC tillader, at alle links er aktive på tværs af flere stier af samme betydning, giver hurtigere konvergens, der reducerer nedetid og gør det nemmere at bruge belastningsbalancering i et mesh-netværk (delvist og/eller fuldt tilsluttet), hvilket tillader trafikken at belastningsbalancere på tværs af alle netværksstier . [3] [4] PPC'en er designet til praktisk talt at eliminere menneskelige fejl under opsætningsprocessen og bevarer plug-and-play-karakteren af plug-and-play, hvilket skaber Ethernet som de facto-protokollen i det andet lag. [5]
Mange teleselskaber har flere ruter gennem deres netværk eller til eksterne netværk. De bruger komplekse belastninger til at ændre trafik fra en sti til en anden for at undgå overbelastning af netværket på et bestemt link, og nogle gange for at minimere omkostningerne ved transit gennem eksterne netværk eller forbedre netværkets pålidelighed.
En anden måde at bruge netværksbelastningsbalancering på er med aktivitetsovervågning. Load balancers kan bruges til at opdele enorme datastrømme i flere understrømme og bruge flere netværksanalysatorer, hvor hver enkelt læser en del af de originale data. Dette er meget nyttigt til overvågning af hurtige netværk såsom 10gbe- eller STM64-porte, hvor kompleks databehandling muligvis ikke er mulig ved trådhastighed.
Belastningsbalancering bruges ofte til at implementere fejltolerance - fortsættelsen af en service efter svigt af en eller flere af dens komponenter. Komponenter overvåges konstant (for eksempel kan webservere styres af en stikprøve af kendte sider), og når man holder op med at svare, informeres load balancer og sender ikke længere trafik til den server. Når komponenten kommer online igen, begynder load balanceren at dirigere trafik til den igen. For at dette kan fungere, skal der være mindst én komponent ud over tjenestens kapacitet (N+1 reservationer). Dette er meget billigere og mere fleksibelt end failover-tilgange, hvor hver levende komponent er parret med en enkelt komponent backup, der tager over i tilfælde af en fejl (dobbelt modulær redundans). Nogle typer RAID- systemer kan også bruges som reservedele til en lignende effekt.