Load balancing er afgørende for at opbygge pålidelige distribuerede systemer og optimere arbejdsbyrdeallokering på tværs af forskellige computerressourcer som computere, klynger og netværksforbindelser. Formålet er at forbedre ressourceudnyttelsen , maksimere gennemløbshastigheden, minimere svartid og forhindre overbelastning af en enkelt ressource. Brug af flere komponenter med load balancing øger pålideligheden og tilgængeligheden gennem redundans. Typisk involverer load balancing specialiseret software eller hardware, såsom en flerlagsswitch eller en Domain Name System- serverproces.
I sin kerne sidder en load balancer mellem klienter og backends og udfører nøglefunktioner:
Tjenesteopdagelse
Identificering af tilgængelige backends og deres adresser til kommunikation.
Sundhedstjek
Evaluering af backends' tilstand og parathed til at acceptere anmodninger.
Belastningsbalance
Distribution af individuelle anmodninger på tværs af sunde backends ved hjælp af algoritmer. Udnyttelse af load balancing i distribuerede systemer tilbyder flere fordele:
Navneabstraktion
Klienter kan adressere load balancer i stedet for at kende alle backends og delegere navneløsning.
Fejltolerance
Gennem sundhedstjek og algoritmer kan en load balancer omgå problemer med funktionsfejl eller overbelastede backends, så operatører kan håndtere problemer, når det passer dem.
Ydeevne og omkostningsfordele
Load balancing kan lokalisere anmodningstrafik inden for zoner, hvilket reducerer latenstid og minimerer de samlede systemomkostninger ved at optimere båndbreddeforbruget.
Load balancer versus proxy
I diskussioner om netværksbelastningsbalancere bruges udtrykkene "belastningsbalancer" og "proxy" ofte i flæng i branchen. Dette indlæg vil betragte disse udtryk som generelt ækvivalente. Selvom ikke alle proxyer fungerer som belastningsbalancere, fungerer størstedelen af proxyer primært som belastningsbalancere.
L4 Load Balancing
I dagens diskurs om load balancing i branchen opdeles løsninger almindeligvis i to hovedkategorier: L4 og L7. Disse refererer til henholdsvis lag 4 og 7 i OSI- modellen. Men selvom denne model giver en ramme, indfanger den ikke fuldt ud kompleksiteten af moderne load balancing-løsninger.
L4-load balancers fungerer typisk på TCP/UDP -forbindelses-/sessionsniveau og blander i bund og grund bytes for at sikre, at de når den korrekte backend. De tager dog ikke højde for de specifikke applikationsdetaljer for disse bytes, som kan komme fra forskellige protokoller som HTTP, Redis eller MongoDB.
L7 Load Balancing
Efterhånden som alle moderne protokoller udvikler sig mod multiplexing og persistente forbindelser for effektivitet, især med overheaden ved at oprette krypterede TLS-forbindelser, bliver uoverensstemmelsen med L4-load balancers mere tydelig over tid. Dette problem løses af L7-load balancers, som tilbyder betydelige fordele ved at muliggøre inspektion af applikationstrafik.
L7 omfatter ifølge OSI-modellen forskellige lag af load balancing-abstraktion. For eksempel, når vi beskæftiger os med HTTP-trafik, har vi følgende underlag:
Valgfri Transport Layer Security (TLS), som vi vil betragte som L7 i denne diskussion på trods af igangværende debatter blandt netværkseksperter.
Den fysiske HTTP-protokol (HTTP/1 eller HTTP/2).
Den logiske HTTP-protokol, inklusive headere, kropsdata og trailere.
Beskedprotokoller som gRPC, RESTOsv
Sofistikerede L7-load balancers kan tilbyde funktioner til hvert af disse underlag, mens andre kan fokusere på en mindre delmængde og stadig placere dem inden for L7-kategorien. Sammenlignet med L4-kategorien er landskabet for L7-load balancers meget mere komplekst set fra et funktionsperspektiv. Og det er vigtigt at bemærke, at denne diskussion udelukkende har fokuseret på HTTP; andre L7-applikationsprotokoller som Redis, Kafka, MongoDB osv. drager også fordel af L7-load balancing.
Relevansen af L4 Load Balancers
Trods forventningen om, at L7 load balancers i sidste ende vil erstatte L4 load balancers til service-to-service kommunikation, er L4 load balancers fortsat yderst relevante, især i udkanten af store distribuerede arkitekturer.
Placering af dedikerede L4 load balancers før L7 load balancers i kanten giver flere fordele:
L7-load balancers håndterer en mindre andel af rå trafikbelastning sammenlignet med optimerede L4-load balancers på grund af deres sofistikerede analyse, transformation og routing af applikationstrafik. Dette gør L4-load balancers til mere effektiv i håndteringen af visse typer DoS angreb, såsom SYN-oversvømmelser og generiske pakkeoversvømmelsesangreb.
L7-load balancers gennemgår mere aktiv udvikling, implementering og fejlforekomster sammenlignet med L4-load balancers. At have en L4-load balancer foran forenkler implementeringen processer under L7 load balancer-implementeringer.
På grund af kompleksiteten af L7 load balancers funktionalitet er de mere tilbøjelige til fejl. At have en L4 load balancer, der kan omgå fejl og anomalier, bidrager til et mere stabilt samlet system.
Load Balancer-topologier
mellemste proxy Topologi er ofte den mest ligetil at implementere. Den er dog sårbar over for at være et enkelt fejlpunkt, har begrænsninger i skalerbarhed og fungerer uigennemsigtigt.
kant proxy Topologien deler ligheder med den midterste proxy, men er normalt uundgåelig.
integreret klientbibliotek Topologien kan prale af overlegen ydeevne og skalerbarhed. Ikke desto mindre kræver den implementering i alle sprog og nødvendiggør biblioteksopgraderinger på tværs af alle tjenester.
sidevogns-proxy Topologien matcher muligvis ikke ydeevnen af den integrerede klientbibliotekstopologi, men er fri for dens begrænsninger.
Global belastningsbalancering
Udviklingen af load balancing vil se et skift i retning af at behandle individuelle load balancers som standardiserede varer. Den sande innovation og det kommercielle potentiale vil være koncentreret i kontrolplanGlobale load balancers vil i stigende grad have muligheder ud over dem, som en enkelt load balancer kan tilbyde. For eksempel:
Automatisk identificering og omdirigering af trafik uden om fejl i bestemte zoner.
Implementering af globale sikkerhedsprotokoller og routingpolitikker.
Identificering og afbødning af uregelmæssige trafikmønstre, såsom DDoS-angreb, ved hjælp af maskinlæring og neurale netværk.
Tilbyder centraliserede brugergrænseflader og visualiseringer for omfattende forståelse og styring af hele det distribuerede system.
For at muliggøre global load balancing skal de load balancers, der fungerer som dataplan, have avancerede dynamiske konfigurationsfunktioner.
Nogle konklusioner
Load balancers spiller en afgørende rolle i moderne distribuerede systemer. De er typisk kategoriseret i to klasser: L4 og L7. Både L4 og L7 load balancers har betydning i moderne arkitekturer. L4 load balancers udvikler sig mod horisontalt skalerbare distribuerede, konsistente hashingløsninger, mens L7 load balancers i øjeblikket oplever betydelige investeringer, drevet af den udbredte anvendelse af dynamiske mikroservicearkitekturer.
Fremtiden for load balancing ligger i global load balancing og opdelingen mellem kontrolplanet og dataplanet. Det er her, de fleste af de kommende innovationer og kommercielle perspektiver vil opstå.
Branchen er i hastig overgang til at bruge open source-software (OSS) og standardhardware til netværksløsninger.
Konventionelle load balancing-udbydere vil være de første, der bliver erstattet af OSS-software og cloud- leverandører.
RELIANOID løsningen er egnet til ethvert behov, med en Multilayer Application Delivery ControllerKomplet Application Delivery Controller-løsning med evnen til at fungere som en load balancer og have høj tilgængelighed på forskellige lag (L2, L3, L4 og L7) og leveret on-premise, virtuelt og cloud-baseret.
Relaterede blogs
