Netwerktaakverdeling. Wat is loadbalancing? Waar uit te kiezen

Over de kwestie van de laadplanning moet in een vroeg stadium van de ontwikkeling van elk webproject een besluit worden genomen. De “val” van een server (en het gebeurt altijd onverwacht, op het meest ongelegen moment) heeft zeer ernstige gevolgen - zowel moreel als materieel. In eerste instantie kunnen problemen met onvoldoende serverprestaties als gevolg van toenemende belasting worden opgelost door het vermogen van de server te vergroten of door de gebruikte algoritmen, programmacodes, enzovoort te optimaliseren. Maar vroeg of laat komt er een moment waarop deze maatregelen onvoldoende blijken te zijn.

We moeten onze toevlucht nemen tot clustering: verschillende servers worden gecombineerd tot een cluster; de belasting wordt tussen hen verdeeld met behulp van een reeks speciale methoden die balancering worden genoemd. Naast het oplossen van het probleem van hoge belastingen, helpt clustering er ook voor te zorgen dat servers redundant zijn ten opzichte van elkaar.
De efficiëntie van clustering hangt rechtstreeks af van hoe de belasting wordt verdeeld (gebalanceerd) tussen de clusterelementen.

Load-balancing kan worden gedaan met behulp van zowel hardware als softwarehulpmiddelen. In dit artikel willen we het hebben over de belangrijkste methoden en algoritmen voor balanceren.

Evenwichtsniveaus

De balanceringsprocedure wordt uitgevoerd met behulp van een hele reeks algoritmen en methoden die overeenkomen met de volgende niveaus van het OSI-model:

netwerk;
vervoer;
toegepast

Laten we deze niveaus in meer detail bekijken.

Balanceren op netwerkniveau

Balanceren op netwerk niveau omvat het oplossen van het volgende probleem: u moet ervoor zorgen dat verschillende servers verantwoordelijk zijn voor één specifiek IP-adres fysieke machines. Dit evenwicht kan op veel verschillende manieren worden bereikt.

Balanceren op transportniveau

Dit type balancering is het eenvoudigst: de klant neemt contact op met de balancer, die het verzoek doorstuurt naar een van de servers, die het zal verwerken. De selectie van de server waarop het verzoek zal worden verwerkt, kan worden uitgevoerd in overeenstemming met een verscheidenheid aan algoritmen (dit wordt hieronder besproken): door eenvoudig round-robin zoeken, door de minst belaste server uit de pool te selecteren, enz.

Soms balanceren op transport laag moeilijk te onderscheiden van balancering op netwerkniveau. Laten we eens overwegen volgende regel Voor overspanningsbeveiliging pf in BSD-systemen: bijvoorbeeld formeel hier waar we het over hebben over het balanceren van verkeer op een specifiek punt TCP-poort(voorbeeld voor pf-netwerkfilter op BSD-systemen):

Web_servers = "( 10.0.0.10, 10.0.0.11, 10.0.0.13 )" komt overeen met $ext_if proto tcp naar poort 80 rdr-naar $web_servers round-robin sticky-adres

Het gaat over het balanceren van verkeer op een specifieke TCP-poort.

Laten we nu naar een ander voorbeeld kijken:

Geef $int_if door vanuit $lan_net \route-to ( ($ext_if1 $ext_gw1), ($ext_if2 $ext_gw2) )\ round-robin

Deze regel heeft betrekking op het balanceren van uitgaand verkeer op netwerkniveau. Er wordt geen specifieke poort of specifiek protocol gespecificeerd.

Het verschil tussen balanceringsniveaus kan als volgt worden verklaard. Het netwerkniveau omvat oplossingen die gebruikerssessies niet beëindigen. Ze leiden eenvoudigweg het verkeer om en werken niet in de proxymodus.
Op netwerkniveau beslist de balancer eenvoudigweg naar welke server pakketten moeten worden doorgestuurd. De sessie met de client wordt uitgevoerd door de server.

Op de transportlaag is de communicatie met de klant beperkt tot de balancer, die als proxy werkt. Het communiceert namens zichzelf met servers en geeft informatie over de client door in aanvullende gegevens en headers. Zo werkt bijvoorbeeld de populaire software balancer HAProxy.

Balanceren op applicatieniveau

Bij het balanceren op toepassingsniveau De balancer werkt in de ‘smart proxy’-modus. Het analyseert klantverzoeken en stuurt deze door naar verschillende servers, afhankelijk van de aard van de gevraagde inhoud. Dit is bijvoorbeeld hoe de Nginx-webserver werkt, waarbij verzoeken worden verdeeld tussen de frontend en de backend. De Upstream-module is verantwoordelijk voor het balanceren in Nginx. U kunt meer lezen over de kenmerken van Nginx-balancering op basis van bijvoorbeeld verschillende algoritmen.

Een ander voorbeeld van een balanceringstool op applicatieniveau is pgpool - een tussenlaag tussen de client en de PostgreSQL DBMS-server. Met zijn hulp kunt u verzoeken naar databaseservers distribueren, afhankelijk van hun inhoud: leesverzoeken worden bijvoorbeeld naar de ene server gestuurd en schrijfverzoeken naar een andere. U kunt meer lezen over pgpool en de specifieke kenmerken van het werken ermee in dit artikel).

Balanceren van algoritmen en methoden

Er zijn veel verschillende algoritmen en methoden voor taakverdeling. Wanneer u een specifiek algoritme kiest, moet u in de eerste plaats uitgaan van de specifieke kenmerken van een bepaald project en ten tweede van de doelstellingen. die wij van plan zijn te verwezenlijken.

Van de doelen waarvoor balancering wordt gebruikt, moet het volgende worden benadrukt:

gerechtigheid: U moet ervoor zorgen dat er middelen worden toegewezen om elk verzoek te verwerken. systeembronnen en voorkomen dat er situaties ontstaan waarin één verzoek wordt verwerkt en alle andere op hun beurt wachten;
efficiëntie: alle servers die verzoeken verwerken moeten 100% bezet zijn; het is raadzaam om een situatie te vermijden waarin een van de servers inactief is en wacht op verzoeken om verwerking (laten we meteen een voorbehoud maken dat dit doel in de praktijk niet altijd wordt bereikt);
vermindering van de uitvoeringstijd van query's: u moet zorgen voor een minimale tijd tussen het begin van de verwerking van een verzoek (of het in een wachtrij plaatsen voor verwerking) en de voltooiing ervan;
verminderde responstijd: we moeten de responstijd op een gebruikersverzoek minimaliseren.

Het is ook zeer wenselijk dat het balanceringsalgoritme de volgende eigenschappen heeft:

voorspelbaarheid: u moet duidelijk begrijpen in welke situaties en onder welke belasting het algoritme effectief zal zijn bij het oplossen van de toegewezen problemen;
schaalbaarheid: Het algoritme moet operationeel blijven naarmate de belasting toeneemt.

Ronde Robin

Round Robin, of het circulaire service-algoritme, is een round-robin-zoekopdracht: het eerste verzoek wordt naar de ene server verzonden, vervolgens wordt het volgende verzoek naar een andere verzonden, enzovoort totdat laatste server, en dan begint alles opnieuw.

De meest gebruikelijke implementatie van dit algoritme is uiteraard de Round Robin DNS-balanceringsmethode. Zoals u weet, slaat elke DNS-server een “hostnaam – IP-adres”-paar op voor elke machine in een specifiek domein. Deze lijst kan er bijvoorbeeld zo uitzien:

Voorbeeld.com xxx.xxx.xxx.2 www.voorbeeld.com xxx.xxx.xxx.3

Aan elke naam in de lijst kunnen meerdere IP-adressen zijn gekoppeld:

Voorbeeld.com xxx.xxx.xxx.2 www.voorbeeld.com xxx.xxx.xxx.3 www.voorbeeld.com xxx.xxx.xxx.4 www.voorbeeld.com xxx.xxx.xxx.5 www.voorbeeld. com xxx.xxx.xxx.6

De DNS-server doorloopt alle vermeldingen in de tabel en keert naar elke vermelding terug nieuw verzoek het volgende IP-adres: bijvoorbeeld voor het eerste verzoek - xxx.xxx.xxx.2, voor het tweede - xxx.xxx.xxx.3, enzovoort. Hierdoor ontvangen alle servers in het cluster hetzelfde aantal verzoeken.

Een van de onbetwiste voordelen van dit algoritme is ten eerste de protocolonafhankelijkheid hoog niveau. Om met het Round Robin-algoritme te werken, wordt elk protocol gebruikt waarin de server op naam wordt benaderd.
Het balanceren op basis van het Round Robin-algoritme is op geen enkele manier afhankelijk van de serverbelasting: het cachen van DNS-servers helpt bij het omgaan met een eventuele toestroom van clients.

Het gebruik van het Round Robin-algoritme vereist geen communicatie tussen servers en kan dus worden gebruikt voor zowel lokale als mondiale balancering.
Ten slotte zijn oplossingen gebaseerd op het Round Robin-algoritme goedkoop: ze hoeven alleen maar een paar vermeldingen aan de DNS toe te voegen om te beginnen werken.

Het Round Robin-algoritme heeft er ook een aantal aanzienlijke tekortkomingen tekortkomingen. Om ervoor te zorgen dat de belastingverdeling met behulp van dit algoritme voldoet aan de bovengenoemde criteria voor eerlijkheid en efficiëntie, moet elke server over dezelfde set bronnen beschikken. Alle bewerkingen moeten ook dezelfde hoeveelheid bronnen gebruiken. In de praktijk wordt aan deze voorwaarden in de meeste gevallen niet voldaan.

Bovendien wordt bij het balanceren met behulp van het Round Robin-algoritme helemaal geen rekening gehouden met de werklast van een bepaalde server in het cluster. Laten we ons de volgende hypothetische situatie voorstellen: een van de knooppunten is 100% belast, terwijl de andere slechts 10 - 15% belast zijn. Het Round Robin-algoritme houdt geen rekening met de mogelijkheid dat een dergelijke situatie zich voordoet, dus een overbelast knooppunt zal nog steeds verzoeken ontvangen. In dit geval kan er geen sprake zijn van enige rechtvaardigheid, efficiëntie of voorspelbaarheid.

Vanwege de hierboven beschreven omstandigheden is het toepassingsgebied van het Round Robin-algoritme zeer beperkt.

Verzwaarde Round Robin

Dit is een verbeterde versie van het Round Robin-algoritme. De essentie van de verbeteringen is als volgt: aan elke server wordt een wegingscoëfficiënt toegewezen in overeenstemming met zijn prestaties en vermogen. Dit helpt de belasting flexibeler te verdelen: servers met een groter gewicht verwerken meer verzoeken. Dit lost echter niet alle problemen met fouttolerantie op. Een effectievere balancering wordt geboden door andere methoden, waarbij met een groter aantal parameters rekening wordt gehouden bij het plannen en verdelen van de belasting.

Minste verbindingen

In de vorige sectie hebben we de belangrijkste nadelen van het Round Robin-algoritme opgesomd. Laten we er nog één noemen: er wordt geen rekening gehouden met het aantal actieven op dit moment verbindingen.

Laten we eens naar een praktisch voorbeeld kijken. Er zijn twee servers, laten we ze A en B noemen. Er zijn minder gebruikers verbonden met server A dan met server B. Tegelijkertijd is server A meer overbelast. Hoe is dit mogelijk? Het antwoord is vrij simpel: verbindingen met server A blijven langer behouden dan verbindingen met server B.

Het beschreven probleem kan worden opgelost met behulp van een algoritme dat bekend staat als least Connections (afgekort als leastconn). Er wordt rekening gehouden met het aantal verbindingen dat momenteel door servers wordt ondersteund. Elke volgende vraag wordt naar de server met de minste actieve verbindingen gestuurd.

Er is een verbeterde versie van dit algoritme, voornamelijk bedoeld voor gebruik in clusters bestaande uit servers met verschillende technische kenmerken En verschillende prestaties. Het heet Weighted Least Connections en houdt bij het verdelen van de belasting niet alleen rekening met het aantal actieve verbindingen, maar ook met de wegingscoëfficiënt van de servers.

Andere geavanceerde versies van het Least Connections-algoritme zijn onder meer Locality-Based Least Connection Scheduling en Locality-Based Least Connection Scheduling met replicatieplanning.

De eerste methode is speciaal gemaakt voor het cachen van proxyservers. De essentie ervan is als volgt: grootste aantal verzoeken worden verzonden naar servers met de minste actieve verbindingen. Achter elk client-servers er wordt een groep client-IP's toegewezen. Verzoeken van deze IP's worden naar de "native" server gestuurd als deze niet volledig is geladen. Anders wordt het verzoek doorgestuurd naar een andere server (deze moet minder dan half geladen zijn).

In het Locality-Based Least Connection Scheduling with Replication Scheduling-algoritme wordt niet elk IP-adres of elke groep IP-adressen toegewezen aan aparte server, maar achter een hele groep servers. Het verzoek wordt verzonden naar de minst belaste server in de groep. Als alle servers uit de “native” groep overbelast zijn, wordt er een nieuwe server gereserveerd. Deze nieuwe server wordt toegevoegd aan de groep die het IP-adres bedient van waaruit het verzoek is verzonden. Op zijn beurt wordt de meest belaste server uit deze groep verwijderd - dit voorkomt redundante replicatie.

Bestemmingshashplanning en bronhashplanning

Het Destination Hash Scheduling-algoritme is gemaakt om te werken met een cluster van caching-proxy's, maar wordt vaak in andere gevallen gebruikt. In dit algoritme wordt de server die het verzoek verwerkt, geselecteerd uit een statische tabel op basis van het IP-adres van de ontvanger.

Het Source Hash Scheduling-algoritme is gebaseerd op dezelfde principes als het vorige, alleen de server die het verzoek zal verwerken, wordt uit de tabel geselecteerd op basis van het IP-adres van de afzender.

Kleverige sessies

Sticky Sessions is een algoritme voor het distribueren van inkomende verzoeken, waarbij verbindingen worden overgedragen naar dezelfde server in de groep. Het wordt bijvoorbeeld gebruikt in de Nginx-webserver. Gebruikerssessies kunnen aan een specifieke server worden toegewezen met behulp van de IP-hash-methode ( gedetailleerde informatie hierover, zie de officiële documentatie). Met deze methode worden verzoeken naar servers gedistribueerd op basis van het IP-adres van de klant. Zoals vermeld in de documentatie (zie link hierboven), "zorgt de methode ervoor dat verzoeken van dezelfde client naar dezelfde server worden verzonden." Als de server die aan een specifiek adres is toegewezen niet beschikbaar is, wordt het verzoek doorgestuurd naar een andere server. Voorbeeld van een configuratiebestandsfragment:

Upstream backend ( ip_hash; server backend1.example.com; server backend2.example.com; server backend3.example.com; server backend4.example.com; )

Vanaf versie 1.2.2 in Nginx kunt u voor elke server een gewicht opgeven.

Er zijn enkele problemen met deze methode. Er kunnen problemen optreden met sessiebinding als de client een dynamisch IP-adres gebruikt. In een situatie waarin groot aantal aanvragen gaan via één proxyserver, de balancering is nauwelijks effectief en eerlijk te noemen. De beschreven problemen kunnen echter worden opgelost door gebruik te maken van cookies. IN commerciële versie Nginx heeft een speciale sticky-module die cookies gebruikt voor het balanceren. Dat heeft hij ook gratis analogen- bijvoorbeeld nginx-sticky-module.
Je kunt in HAProxy de sticky-sessions-methode gebruiken, hierover lees je bijvoorbeeld meer

Conclusie

Dit artikel is in wezen een inleiding tot taakverdeling. We zullen onze discussie over dit onderwerp in toekomstige publicaties voortzetten. Als u vragen, opmerkingen of aanvullingen heeft, welkom bij de opmerkingen. We zullen het ook op prijs stellen als u niet-triviaal deelt praktische voorbeelden het organiseren van loadbalancing voor diverse projecten.

Lezers die om de een of andere reden hier geen commentaar kunnen achterlaten, worden uitgenodigd op onze blog.

Tags:

taakverdeling
Selecteer
selecteer

Tags toevoegen

Load-balancing kan worden gedaan met behulp van zowel hardware- als softwaretools. In dit artikel willen we het hebben over de belangrijkste methoden en algoritmen voor balanceren.

Evenwichtsniveaus

De balanceringsprocedure wordt uitgevoerd met behulp van een hele reeks algoritmen en methoden die overeenkomen met de volgende niveaus van het OSI-model:

netwerk;
vervoer;
toegepast

Laten we deze niveaus in meer detail bekijken.

Balanceren op netwerkniveau

Balanceren op netwerkniveau betekent het oplossen van het volgende probleem: u moet ervoor zorgen dat verschillende fysieke machines verantwoordelijk zijn voor één specifiek server-IP-adres. Dit evenwicht kan op veel verschillende manieren worden bereikt.

Balanceren op transportniveau

Soms is balanceren op de transportlaag moeilijk te onderscheiden van balanceren op de netwerklaag. Beschouw de volgende regel voor het pf-netwerkfilter in BSD-systemen: formeel hebben we het bijvoorbeeld over het verdelen van verkeer op een specifieke TCP-poort (voorbeeld voor het pf-netwerkfilter in BSD-systemen):

Web_servers = "( 10.0.0.10, 10.0.0.11, 10.0.0.13 )" komt overeen met $ext_if proto tcp naar poort 80 rdr-naar $web_servers round-robin sticky-adres

Het gaat over het balanceren van verkeer op een specifieke TCP-poort.

Laten we nu naar een ander voorbeeld kijken:

Geef $int_if door vanuit $lan_net \route-to ( ($ext_if1 $ext_gw1), ($ext_if2 $ext_gw2) )\ round-robin

Deze regel heeft betrekking op het balanceren van uitgaand verkeer op netwerkniveau. Er wordt geen specifieke poort of specifiek protocol gespecificeerd.

Balanceren op applicatieniveau

Bij het balanceren op applicatieniveau werkt de balancer in de ‘smart proxy’-modus. Het analyseert klantverzoeken en stuurt deze door naar verschillende servers, afhankelijk van de aard van de gevraagde inhoud. Dit is bijvoorbeeld hoe de Nginx-webserver werkt, waarbij verzoeken worden verdeeld tussen de frontend en de backend. De Upstream-module is verantwoordelijk voor het balanceren in Nginx. U kunt meer lezen over de kenmerken van Nginx-balancering op basis van bijvoorbeeld verschillende algoritmen.

Balanceren van algoritmen en methoden

Van de doelen waarvoor balancering wordt gebruikt, moet het volgende worden benadrukt:

gerechtigheid: we moeten ervoor zorgen dat systeembronnen worden toegewezen om elk verzoek te verwerken en voorkomen dat er situaties ontstaan waarin één verzoek wordt verwerkt terwijl alle andere in de rij staan te wachten;
efficiëntie: alle servers die verzoeken verwerken moeten 100% bezet zijn; het is raadzaam om een situatie te vermijden waarin een van de servers inactief is en wacht op verzoeken om verwerking (laten we meteen een voorbehoud maken dat dit doel in de praktijk niet altijd wordt bereikt);
vermindering van de uitvoeringstijd van query's: u moet zorgen voor een minimale tijd tussen het begin van de verwerking van een verzoek (of het in een wachtrij plaatsen voor verwerking) en de voltooiing ervan;
verminderde responstijd: we moeten de responstijd op een gebruikersverzoek minimaliseren.

Het is ook zeer wenselijk dat het balanceringsalgoritme de volgende eigenschappen heeft:

voorspelbaarheid: u moet duidelijk begrijpen in welke situaties en onder welke belasting het algoritme effectief zal zijn bij het oplossen van de toegewezen problemen;
schaalbaarheid: Het algoritme moet operationeel blijven naarmate de belasting toeneemt.

Ronde Robin

Round Robin, of round-robin-algoritme, is een round-robin-zoekopdracht: het eerste verzoek wordt naar de ene server verzonden, vervolgens wordt het volgende verzoek naar een andere verzonden, enzovoort totdat de laatste server wordt bereikt, en dan begint alles opnieuw.

Voorbeeld.com xxx.xxx.xxx.2 www.voorbeeld.com xxx.xxx.xxx.3

Aan elke naam in de lijst kunnen meerdere IP-adressen zijn gekoppeld:

Voorbeeld.com xxx.xxx.xxx.2 www.voorbeeld.com xxx.xxx.xxx.3 www.voorbeeld.com xxx.xxx.xxx.4 www.voorbeeld.com xxx.xxx.xxx.5 www.voorbeeld. com xxx.xxx.xxx.6

De DNS-server doorloopt alle gegevens in de tabel en geeft voor elk nieuw verzoek het volgende IP-adres: bijvoorbeeld voor het eerste verzoek - xxx.xxx.xxx.2, voor het tweede - xxx.xxx.xxx.3, enzovoort. Hierdoor ontvangen alle servers in het cluster hetzelfde aantal verzoeken.

Een van de onbetwiste voordelen van dit algoritme is in de eerste plaats de onafhankelijkheid van het protocol op hoog niveau. Om met het Round Robin-algoritme te werken, wordt elk protocol gebruikt waarin de server op naam wordt benaderd.
Het balanceren op basis van het Round Robin-algoritme is op geen enkele manier afhankelijk van de serverbelasting: het cachen van DNS-servers helpt bij het omgaan met een eventuele toestroom van clients.

Het Round Robin-algoritme heeft ook een aantal belangrijke nadelen. Om ervoor te zorgen dat de belastingverdeling met behulp van dit algoritme voldoet aan de bovengenoemde criteria voor eerlijkheid en efficiëntie, moet elke server over dezelfde set bronnen beschikken. Alle bewerkingen moeten ook dezelfde hoeveelheid bronnen gebruiken. In de praktijk wordt aan deze voorwaarden in de meeste gevallen niet voldaan.

Vanwege de hierboven beschreven omstandigheden is het toepassingsgebied van het Round Robin-algoritme zeer beperkt.

Verzwaarde Round Robin

Minste verbindingen

In de vorige sectie hebben we de belangrijkste nadelen van het Round Robin-algoritme opgesomd. Laten we er nog één noemen: deze houdt helemaal geen rekening met het aantal momenteel actieve verbindingen.

Er is een verbeterde versie van dit algoritme, voornamelijk bedoeld voor gebruik in clusters bestaande uit servers met verschillende technische kenmerken en verschillende prestaties. Het heet Weighted Least Connections en houdt bij het verdelen van de belasting niet alleen rekening met het aantal actieve verbindingen, maar ook met de wegingscoëfficiënt van de servers.

Andere geavanceerde versies van het Least Connections-algoritme zijn onder meer Locality-Based Least Connection Scheduling en Locality-Based Least Connection Scheduling met replicatieplanning.

De eerste methode is speciaal gemaakt voor het cachen van proxyservers. De essentie is als volgt: het grootste aantal verzoeken wordt verzonden naar servers met het kleinste aantal actieve verbindingen. Aan elke clientserver wordt een groep client-IP's toegewezen. Verzoeken van deze IP's worden naar de "native" server gestuurd als deze niet volledig is geladen. Anders wordt het verzoek doorgestuurd naar een andere server (deze moet minder dan half geladen zijn).

In het Locality-Based Least Connection Scheduling with Replication Scheduling-algoritme wordt elk IP-adres of elke groep IP-adressen niet aan een individuele server toegewezen, maar aan een hele groep servers. Het verzoek wordt verzonden naar de minst belaste server in de groep. Als alle servers uit de “native” groep overbelast zijn, wordt er een nieuwe server gereserveerd. Deze nieuwe server wordt toegevoegd aan de groep die het IP-adres bedient van waaruit het verzoek is verzonden. Op zijn beurt wordt de meest belaste server uit deze groep verwijderd - dit voorkomt redundante replicatie.

Bestemmingshashplanning en bronhashplanning

Kleverige sessies

Sticky Sessions is een algoritme voor het distribueren van inkomende verzoeken, waarbij verbindingen worden overgedragen naar dezelfde server in de groep. Het wordt bijvoorbeeld gebruikt in de Nginx-webserver. Gebruikerssessies kunnen aan een specifieke server worden toegewezen met behulp van de IP-hash-methode (zie de officiële documentatie voor details). Met deze methode worden verzoeken naar servers gedistribueerd op basis van het IP-adres van de klant. Zoals vermeld in de documentatie (zie link hierboven), "zorgt de methode ervoor dat verzoeken van dezelfde client naar dezelfde server worden verzonden." Als de server die aan een specifiek adres is toegewezen niet beschikbaar is, wordt het verzoek doorgestuurd naar een andere server. Voorbeeld van een configuratiebestandsfragment:

Upstream backend ( ip_hash; server backend1.example.com; server backend2.example.com; server backend3.example.com; server backend4.example.com; )

Vanaf versie 1.2.2 in Nginx kunt u voor elke server een gewicht opgeven.

Er zijn enkele problemen met deze methode. Er kunnen problemen optreden met sessiebinding als de client een dynamisch IP-adres gebruikt. In een situatie waarin een groot aantal verzoeken via één proxyserver gaat, kan balancering nauwelijks effectief en eerlijk worden genoemd. De beschreven problemen kunnen echter worden opgelost door gebruik te maken van cookies. De commerciële versie van Nginx heeft een speciale sticky-module, die cookies gebruikt voor het balanceren. Het heeft ook gratis analogen, bijvoorbeeld nginx-sticky-module.
Je kunt in HAProxy de sticky-sessions-methode gebruiken, hierover lees je bijvoorbeeld meer

Conclusie

Dit artikel is in wezen een inleiding tot taakverdeling. We zullen onze discussie over dit onderwerp in toekomstige publicaties voortzetten. Als u vragen, opmerkingen of aanvullingen heeft, welkom bij de opmerkingen. We zullen het ook op prijs stellen als u niet-triviale praktijkvoorbeelden deelt van het organiseren van load-balancing voor verschillende projecten.

Lezers die om de een of andere reden hier geen commentaar kunnen achterlaten, worden uitgenodigd op onze blog.

Tags: tags toevoegen

In de terminologie van computernetwerken is taakverdeling (nivellering) de verdeling van het taakuitvoeringsproces over verschillende netwerkservers om het gebruik van bronnen te optimaliseren en de rekentijd te verkorten.

Soorten servers die in balans moeten zijn:

serverclusters;

firewalls;

servers voor inhoudinspectie (zoals AntiVirus- of AntiSpam-servers).

Server-taakverdelingssystemen maken doorgaans gebruik van L4-mogelijkheden (UDP/TCP). In dit geval wordt de beschikbaarheid van de server gecontroleerd aan de hand van het IP-adres en poortnummer en wordt er een beslissing genomen: welke van de beschikbare servers het verzoek moet worden doorgestuurd. Meestal wordt een round-robin-algoritme gebruikt om een server te selecteren. Bij deze optie wordt ervan uitgegaan dat alle aanvragen dezelfde laad- en uitvoeringsduur genereren. Meer geavanceerde versies van het algoritme maken gebruik van de serverbezettingsgraad en het aantal actieve verbindingen.

Voorheen waren load-balancing-mogelijkheden ingebouwd in de applicatieprogramma of besturingssysteem. Moderne load-balancing-systemen moeten aan de volgende eisen voldoen:

voorzien verkeersmanagement het garanderen van de beschikbaarheid van applicaties en de verdeling van de belasting in een serverfarm (een groep servers die zijn verbonden via een datanetwerk en als één eenheid werken);

de uitvoering van applicaties meerdere keren versnellen;

garantie applicatie bescherming, gegevensbeveiliging en verkeersmonitoring.

Belangrijk hierbij is dat de beschikbaarheid van een IP-adres en poort geen garantie biedt voor toegang tot de applicatie.

De laatste tijd wordt de applicatielaag steeds vaker gebruikt om het probleem van load-balancing op te lossen. Bij het besluitvormingsproces wordt rekening gehouden met het type client, de gevraagde URL, informatie uit de cookie, de mogelijkheden van de specifieke server en het type applicatieprogramma, waardoor het gebruik van systeembronnen kan worden geoptimaliseerd.

Het GSLB-systeem (Global Server Load Balancing) kan behoorlijk aanzienlijke voordelen bieden, dat in staat is het probleem van het balanceren van willekeurig geplaatste serverfarms op te lossen, rekening houdend met hun afstand tot de client. Dit systeem kan verschillende load-balancing-algoritmen ondersteunen en optimale service bieden aan klanten over de hele wereld. Voor beheerders maakt het systeem het mogelijk om een flexibel resourcemanagementbeleid te creëren.

Een manier om de service te versnellen is caching. In het geval van een goed geconfigureerde cache kan het percentage verzoeken dat door de cache wordt voldaan oplopen tot 40%. Tegelijkertijd kan de serviceversnelling 30 keer worden verbeterd.

Een andere methode om de service te versnellen is data-archivering, omdat deze optie de congestie op netwerkkanalen vermindert.

Het taakverdelingsbeheer kan worden gecombineerd met de applicatiefirewallfunctie (70% van de succesvolle inbraken maakt gebruik van kwetsbaarheden in applicaties) en het gebruik van SSL via een VPN-tunnel. SSL – Secure Sockets Layer – is een cryptografisch protocol dat zorgt voor het tot stand brengen van een veilige verbinding tussen een client en een server.

Om maximale doorvoer en fouttolerantie te bereiken, kunt u met firewalls de belasting verdelen of balanceren via alle beschikbare internetkanalen (servers) tegelijk. U kunt bijvoorbeeld een situatie vermijden waarin pakketten die via het netwerk worden verzonden via de ene provider gaan, terwijl de toegang tot internet via een andere provider inactief is. Of distribueer diensten en stuur verkeer via alle beschikbare internetkanalen. Het is mogelijk om de taakverdeling te configureren als verbindingen met providers tot stand worden gebracht met verschillende verbindingstypen (Statisch IP, PPPoE, PPTP/L2TP), en om het verkeer dat door VPN-tunnels gaat die op verschillende fysieke interfaces zijn geïnstalleerd, te balanceren.

Rijst. 4.12. Load-balancing over meerdere routes

De firewalls uit de D-Link NetDefend-serie bieden een functie die is ontworpen om de netwerkbelasting over verschillende routes te verdelen - Route Laden Balanceren (RLB) , waarvan de mogelijkheden bieden:

het balanceren van verkeer tussen interfaces op basis van beleid;

verkeersbelastingverdeling met gelijktijdige meervoudige internettoegang, waarbij gebruik wordt gemaakt van de diensten van twee of meer providers;

het balanceren van verkeer dat door VPN-tunnels gaat die op verschillende fysieke interfaces zijn geïnstalleerd.

De taakverdelingsfunctie in NetDefend-firewalls wordt ingeschakeld op basis van de routeringstabel door een RLB-object te maken Aanleg, waarin twee parameters zijn gedefinieerd: de routeringstabel en het RLB-algoritme. Er kan slechts één Instance-object aan een routeringstabel worden gekoppeld.

Rijst. 4.13. Een taakverdelingsalgoritme selecteren in NetDefend-firewalls

Het is mogelijk om een van de lastverdelingsalgoritmen tussen internetinterfaces te kiezen:

Algoritme Ronde Robin verdeelt de belasting opeenvolgend (afwisselend) tussen WAN1- en WAN2-interfaces. Elke keer dat er een nieuwe uitgaande sessie plaatsvindt vanaf de LAN-interface, wordt de WAN1- of WAN2-interface geselecteerd om pakketten te verzenden.

Algoritme In de toekomst zullen pakketten van deze sessie de eerder gedefinieerde WAN-interface gebruiken. Een TCP-sessie wordt geopend en gesloten op dezelfde WAN-interface. Bestemming

voorkomt problemen met sommige protocollen bij het gebruik van balancering, bijvoorbeeld FTP. Dit algoritme werkt op dezelfde manier als het Round Robin-algoritme, behalve dat alle gegevens naar de externe host via de interface gaan waarmee de verbinding tot stand is gebracht. Betekenis definieert de belastingslimiet voor de belangrijkste WAN-poort ( Routing → Routetaakverdeling > Algoritme-instellingen). Wanneer deze belasting binnen de opgegeven periode wordt bereikt, wordt de tweede WAN-poort gebruikt (voor nieuwe sessies). Zodra de belasting op het hoofdkanaal afneemt, worden er nieuwe sessies op geopend.

RondeRobin

De standaardstatistiek van elke route is nul. Bij het gebruik van onderling verbonden algoritmen Ronde Robin En In de toekomst zullen pakketten van deze sessie de eerder gedefinieerde WAN-interface gebruiken. Een TCP-sessie wordt geopend en gesloten op dezelfde WAN-interface. U kunt verschillende metrische waarden instellen om een prioriteit te creëren bij het kiezen van routes. Routes met een minimale metrische waarde worden vaker geselecteerd dan routes met een hogere metrische waarde.

Als u in een scenario met twee internetproviders (de uitdrukking "ISP" wordt vaak gebruikt), d.w.z. een internetprovider, wilt dat het merendeel van het verkeer via een van de ISP-verbindingen gaat, moet u RLB inschakelen en een lagere metriek toewijzen waarde voor de route van de hoofd-ISP-verbinding (bijvoorbeeld 90) ten opzichte van de tweede (bijvoorbeeld 100).

Als het de taak is om het verkeer tussen twee internetproviders gelijkmatig te verdelen, moet de metrische waarde voor beide routes hetzelfde worden toegewezen.

Routestatistieken gebruiken met een algoritmeBetekenis

Bij gebruik van het algoritme Betekenis Voor elke route moet een metriek worden gedefinieerd. In dit geval kiest NetDefendOS altijd de route met de laagste metrische waarde. Het algoritme is niet ontworpen om met dezelfde metrische waarden van routes te werken, dus de beheerder moet verschillende metrische waarden instellen voor alle routes waarop het algoritme wordt toegepastBetekenis.

De metrische waarde bepaalt de volgorde waarin verkeer wordt omgeleid naar een andere route nadat de geselecteerde route de verkeerslimiet overschrijdt.

U kunt verschillende alternatieve routes maken met verschillende metrische waarden, waarvoor voor elk een drempelwaarde voor de algoritme-instellingen is gedefinieerd - Betekenis Instelling– voor elke interface. Eerst wordt de route met de minimale metriek geselecteerd; Zodra de toegestane drempelwaarde voor algoritme-instellingen wordt overschreden, wordt de volgende route geselecteerd.

Als alle alternatieve routes de drempelwaarden voor de Spillover-instelling hebben bereikt, verandert de route niet.

AANDACHT: De metrische waarde op interfaces (routes) die worden gebruikt bij het balanceren moet hoger worden ingesteld dan voor andere interfaces (routes). Hoe lager de metrische waarde op een interface (route), hoe vaker deze interface (route) zal worden gebruikt om een verbinding tot stand te brengen, ten opzichte van de interface (route) met een hogere metrische waarde. Het aandeel van het gebruik van interfaces (routes) zal evenredig zijn aan het verschil tussen de metrische waarden op deze interfaces (routes).

Netwerktaakverdeling en NA-clustering (apparaatredundantie) van firewallsNetDefend

Een hoog niveau van netwerkfouttolerantie wordt bereikt door het gebruik van twee NetDefend-firewalls: het hoofdapparaat (master) en back-upapparaat(slaaf). De primaire en back-upfirewalls zijn met elkaar verbonden en vormen een logisch HA-cluster.

NetDefend-firewalls ondersteunen niet loadbalancing in HA-clustering apparaten, d.w.z. belastingverdeling daartussen niet voorzien, aangezien het ene apparaat altijd actief is, terwijl het andere in de stand-bymodus staat (passief).

Rijst. 4.14. HA-clustering van NetDefend-firewalls

Wat is loadbalancing? In feite is dit de distributie van binnenkomend verkeer netwerkverbindingen tussen meerdere computerknooppunten. Tegelijkertijd kan het gebruik van hardware of software-oplossingen, evenals het algoritme dat wordt gebruikt om de essentie te verspreiden, verandert helemaal niet. Maar dankzij de verdeling van de belasting kunnen twee behoorlijk ernstige problemen worden opgelost.
Ten eerste is het de verdeling van de belasting tussen computerknooppunten in een situatie waarin de bronnen van één server niet voldoende zijn en verticale uitbreiding van de kracht ervan niet langer mogelijk is. In dit geval is het noodzakelijk om nog een rekeneenheid toe te voegen en een van de soorten balancering te gebruiken.
Ten tweede: het garanderen van de toegankelijkheid. Zoals bekend is de fouttolerantie van elk systeem, zij het hardware-oplossing of software wordt bereikt door de hoofdcomponenten te dupliceren. Helaas is er absoluut geen betrouwbaar hard schijven, RAID-controllers en andere apparatuur, en modern niveau programmering garandeert niet de afwezigheid van fouten in de software. Om deze reden wordt bij het bouwen van fouttolerante services alles gedupliceerd: netwerkcontrollers, switches en uiteindelijk de computerknooppunten zelf. Zo mag de belasting die op één server ontstaat niet groot zijn, maar tegelijkertijd wil je er zeker van zijn dat het uitvallen van één of meerdere knooppunten niet leidt tot downtime van de dienstverlening. Ook in dit geval kan een load balancer de oplossing zijn.

Basistypen en technieken van balanceren

In wezen alles bestaande soorten Het balanceren kan in drieën worden verdeeld mondiale groepen ze verschillen in de “diepte” van de analyse van inkomende verzoeken en de mate van verificatie van de serverbeschikbaarheid.

Primitieve methoden

Deze groep omvat balanceringsmethoden die op geen enkele manier worden geanalyseerd inkomend verkeer en controleer niet de beschikbaarheid van computerknooppunten die zich daarachter bevinden. Meest heldere vertegenwoordiger gegeven groep, dit is de verdeling van verzoeken met met behulp van DNS waarover hieronder.

Round Robin-DNS

Misschien wel de meest gebruikelijke methode. Dit is gebaseerd op het feit dat de DNS-specificatie het aanmaken van meerdere identieke A-records met verschillende IP-adressen mogelijk maakt. U kunt bijvoorbeeld twee vermeldingen maken voor het knooppunt srv-01.company.com met verschillende IP-adressen die behoren tot: verschillende servers. Bovendien moet er een speciale optie (Round Robin) zijn ingeschakeld op de DNS-server. Als gevolg hiervan zullen bij elke nieuwe aanvraag voor het srv-01.company.com-record verschillende IP-adressen worden opgegeven, wat zal leiden tot een gelijkmatige verdeling van verbindingen tussen knooppunten.
Maar ondanks al het gemak en de goedkope prijs dit besluit, zijn er een aantal beperkingen. Ten eerste zijn er geen methoden om de beschikbaarheid van knooppunten te controleren. Dat wil zeggen dat de server mogelijk faalt, maar DNS zal nog steeds zijn IP-adres aan clients geven. Ten tweede wordt er geen rekening gehouden met het aantal huidige sessies op een bepaald knooppunt. Er kan zich een situatie voordoen waarin een van de servers aanzienlijk meer open sessies heeft dan de andere, maar de verbindingen nog steeds gelijkmatig worden verdeeld. En ten derde houdt DNS geen rekening met met welke server de gebruiker de vorige keer verbonden was. Het is mogelijk dat bij elke nieuwe verbinding met bijvoorbeeld een terminal of een webserver een nieuwe sessie op een ander knooppunt wordt geopend, wat niet wenselijk is.
Afzonderlijk zou ik op dit punt diensten als Amazon Route 53 willen benadrukken. Dit is een cloud-DNS-hosting waarmee u uitzonderingen kunt maken standaard kenmerken geeft u het “gewicht” aan van identieke A-records, waardoor u binnenkomende verzoeken flexibeler kunt verdelen. Bovendien is het mogelijk om te integreren met de Elastic Load Balancing cloud load balancer die beschikbaar is in Amazon Web Services, waardoor u een nog fijnere balancering kunt bereiken.

Primitieve methoden omvatten ook handmatig balanceren.

De essentie van de methode is om alle gebruikers in verschillende groepen te verdelen en met hen te verbinden diverse servers. Een organisatie heeft er bijvoorbeeld twee in dienst terminal-servers identieke prestaties. De helft van de gebruikers heeft een snelkoppeling op hun bureaublad om verbinding te maken met de eerste server, en de overige gebruikers met de tweede. Bovendien wordt er, in het geval van een storing van het huidige knooppunt, een snelkoppeling gemaakt om verbinding te maken met een andere server, die als back-up zal dienen. Misschien is een dergelijke methode alleen toepasbaar in kleine organisaties, en het doel van een dergelijke distributie is juist fouttolerantie en niet balanceren. In dit geval is dat niet nodig extra uitrusting En software, maar je zult wat handmatig werk moeten doen.

Transportniveaubalancering (L4)

Dit is het meest universele en wijdverbreide mechanisme. Hetzelfde geldt voor TCP en UDP-protocollen, en dienovereenkomstig kunnen ze verkeer van vrijwel elke dienst distribueren. Op dit niveau worden alleen het IP-adres en het poortnummer van de bestemming gecontroleerd in inkomende pakketten. Als het overeenkomt met een van de regels, wordt het verkeer eenvoudigweg doorgestuurd gespecificeerde servers, met behulp van het sNAT-mechanisme in op de voorgeschreven manier. De inhoud van de pakketten wordt niet gecontroleerd. Er zijn ook geen speciale technieken om de beschikbaarheid van computerknooppunten te controleren. In uitvoering eenvoudige controle beschikbaarheid van adres en poort. Als de poort open is, wordt de server als toegankelijk beschouwd en worden er nog steeds verzoeken naartoe gestuurd.
De meeste populaire software- en hardwarebalancers werken met dit mechanisme, inclusief Network Load Balancing (NLB) dat wordt gebruikt in Windows-server. Deze categorie omvat ook momenteel populaire clouddiensten zoals de hierboven genoemde Elastic Load Balancing van Amazon.

Balans op applicatieniveau (L7)

Een dynamisch evoluerende vorm van load-balancing op applicatieniveau. Dergelijke balancers worden ook wel application delivery controllers genoemd. Gericht op het werken met protocollen op hoog niveau. Voornamelijk HTTP\HTTPS. Hier worden, net als in het geval van de vorige weergave, de regels beschreven. Wanneer op een bepaalde poort een verbinding tot stand wordt gebracht, worden pakketten doorgestuurd opgegeven adressen en poorten van computerknooppunten. Maar bij het kiezen van een specifieke server om het verkeer ernaar door te sturen, wordt rekening gehouden met het type client, de URL, de cookie-inhoud, de gevraagde inhoud en enkele andere parameters. Bovendien wordt het controleren van de beschikbaarheid van een dienst op rekenknooppunten veel intelligenter gecontroleerd. Er kan bijvoorbeeld een bepaalde URL worden opgevraagd en de inhoud ervan worden gecontroleerd.
Nog één onderscheidend kenmerk Dit type vanaf L4 houdt in dat de servers in het cluster niet identiek mogen zijn. Sommige knooppunten kunnen bijvoorbeeld statische gegevens zoals foto's en video's leveren, terwijl andere servers inhoud kunnen leveren met behulp van scripts, HTML en CSS. In dit geval kunnen voor elk type inhoud regels worden gemaakt met speciale algoritmen voor het omleiden van verkeer diverse groepen servers. In deze categorie is er ook een andere klasse profielbalancers, zoals Citrix NetScaler. Deze oplossing is gespecialiseerd in load-balancing en het verbeteren van de prestaties van Citrix-producten (XenApp, XenDesktop), evenals webapplicaties. Naast geavanceerde balancering kan het inhoudscompressie, krachtige caching uitvoeren, encryptie bieden, evenals verkeersanalyse en filtering. Het is gewoon klein deel zijn mogelijkheden, die een apart artikel verdienen.

Wanneer de servercapaciteit niet meer voldoende is, rijst de vraag welke kant we nu op moeten. Een upgrade zorgt vaak niet voor een proportionele verhoging en bovendien niet voor de benodigde fouttolerantie. Daarom het meest de juiste stap Er komt een tweede server die een deel van de belasting op zich neemt. Het enige dat overblijft is het kiezen van een applicatie die voor balancering zorgt.

Waaruit te kiezen?

Netwerktaakverdelingsoplossingen zien er op het eerste gezicht hetzelfde uit. In feite zijn er veel technologieën en algoritmen bij het proces betrokken, dus het is onmogelijk om twee identieke producten te vinden. Niet voor de hand liggende kenmerken zijn mogelijk ondersteuning voor bepaalde protocollen (bijvoorbeeld alleen HTTP of een ander), er zijn nog veel meer parameters.

Bovendien kunnen load balancers op verschillende manieren clientverkeer naar een voorkeursserver routeren. Meest populair: uitzending netwerkadressen(Network Address Translation) en verzending via TCP-gateway. In het eerste geval vervangt de balancer de IP-adressen in het pakket direct, waardoor het server-IP voor de client wordt verborgen en omgekeerd. Als het IP-adres van de client nodig is voor de eindapplicatie voor statistieken of andere bewerkingen, wordt dit meestal opgeslagen in de X-Forwarded-for HTTP-header. Als u een ander protocol gebruikt, moet u ervoor zorgen dat deze functie is geïmplementeerd. In het geval van een TCP-gateway kan de balancer verkeer beheren op L4-niveau (transport) en zelfs op applicatieniveau (L7). Om dit te doen, brengt het een verbinding tot stand en kijkt het in het pakket. Normaal gesproken wisselen de client en de applicatie informatie uit via een balancer. Maar de laatste tijd is een serverconfiguratie met direct return (DSR) steeds populairder geworden, waarbij de reactie van de server rechtstreeks naar de client gaat, en niet via een load-balancing-apparaat. Het gebruik van DSR vermindert de belasting van de balancer, maar staat het gebruik van cookies en SSL-decodering niet toe. Deze methode is een orde van grootte sneller dan het gebruik van NAT-balancering en stelt services in staat de echte IP-adressen van clients te zien.

Ook in systemen kun je ze vinden verschillende methoden balanceren. Laten we eens kijken naar het doel van enkele ervan. In productinstellingen kunnen ze verschillende namen hebben of hun eigen implementatiekenmerken, maar vaak is hun essentie hetzelfde.
Het eenvoudigste is Round Robin DNS, dit is een speciale DNS-server die meerdere A-records en hun gewicht bevat (optioneel) en verschillende IP-adressen uitgeeft wanneer klanten daarom vragen. De nadelen liggen voor de hand. Het heeft absoluut geen informatie over de huidige belasting en status van de backends, en houdt geen rekening met eerdere clientverbindingen (de DNS-cache verzacht de situatie een beetje).

Er is een algoritme dat qua naam vergelijkbaar is, maar middels gerealiseerd de balancer zelf - Round Robin. Alle clients zijn gelijkmatig verdeeld over de backends en er wordt meestal geen rekening gehouden met andere parameters. Het Round Robin Weighted-algoritme houdt rekening met de Weight-parameter die voor elke server is opgegeven. Door meer gewicht toe te kennen aan een krachtigere server, kunnen we er meer klanten naartoe leiden. Prioriteitsverdeling werkt enigszins anders. In dit algoritme werkt alleen de server met hoge prioriteit; de rest is in de regel alleen verbonden als deze uitvalt. Met deze optie kunt u er een cluster mee bouwen actief knooppunt, bijvoorbeeld wanneer de tweede server een andere rol vervult en alleen een back-up maakt van de eerste. Een andere optie is Least Connection (Least Session) - de verbinding wordt geaccepteerd door de server die het kleinste aantal verbindingen (sessies) bedient, maar de verbindingen kunnen verschillend zijn (de gebruiker is actief of passief) en dienovereenkomstig een andere belasting vormen de server. Maar het Least Bandwidth-algoritme houdt rekening met de werkelijke netwerkbelasting.

Hash sticky client - de client is hierbij gebonden aan één server, een hash-string die zijn IP aangeeft, wordt in een speciale tabel geplaatst; Variaties zijn mogelijk. De client gaat altijd naar één server en als deze weggaat, is de verbinding onmogelijk. Of, wanneer de ‘native’ niet reageert, maakt deze verbinding met andere systemen.

De beschikbaarheid van backends wordt door twee bepaald: actief (keepalives, de balancer zelf pollt de servers) en passief (In-Band, huidige verbindingen en servicereacties worden gemonitord).

BalansNG

Project nummer één op de lijst – BalanceNG, is een ontwikkeling Open bron Balance-oplossingen, maar worden gedistribueerd onder een dubbele licentie (commercieel en vrij Basislicentie). IN gratis versie je kunt één virtuele server en twee knooppunten verbinden, wat, gezien de mogelijkheden, voldoende is om gemakkelijk met een gemiddelde om te gaan, en soms zware belasting. Het is een IP-taakverdelingsoplossing die IPv6 ondersteunt en verschillende backend-selectiecontrolemethoden biedt (Round Robin, Random, Weighted Random, Least Session, Least Bandwidth, Hash, Agent en Randomized Agent).

Het product maakt gebruik van een originele engine die draait op Layer 2 (Ethernet), de balans is gebaseerd op het IP-adres van de klant en kan met elke service werken zonder gebonden te zijn aan poorten. Ondersteunt DNS GSLB (Global Server Load-Balancing) en Direct Server Return (DSR) serverconfiguratie, waarbij het antwoord van de server rechtstreeks naar de client gaat in plaats van via een load balancer. Bevat een aangepaste UDP-inspectieagent en ondersteunt VRRP om zeer beschikbare configuraties op meerdere knooppunten te installeren. Met ingebouwde mechanismen kunt u pakketten vastleggen en opslaan met behulp van pcap voor verder onderzoek. Er zijn verschillende opties om de functionaliteit te controleren eindsystemen: agent, ping, TCP Open, script en andere tools zoals wget.

Het is mogelijk om een balancer te reserveren met replicatie van NAT-statussen tussen de hoofd- en back-upknooppunten; bij het opnieuw verbinden maakt de client verbinding met dezelfde server. Om de sessie op te slaan, worden het IP-adres en de bestemmingspoort van de client gebruikt. Linux-binding wordt ondersteund. Alle tabellen worden opgeslagen in RAM, maar de vereisten zijn klein; 512 MB geheugen is voldoende voor 4 miljoen sessies.
Kan draaien op Linux (met behulp van de PF_PACKET API-socket) en SPARC/Intel Solaris (Streams/DLPI API). Voor installatie worden rpm (Red Hat RHEL 6 / CentOS) en deb (Debian/Ubuntu) pakketten en een tarball voor andere distributies aangeboden. Er is ook een kant-en-klaar beeld beschikbaar virtuele machine(gebaseerd op Ubuntu 8.04), waarmee u snel de benodigde functionaliteit kunt implementeren. Tijdens het downloaden worden alle inlogwachtwoorden getoond. De agent (bngagent) is open source en ondersteunt Linux, Solaris, OS X, HP-UX en anderen.
Er is geen interface voor configuratie; alle instellingen worden gemaakt met behulp van het configuratiebestand /etc/bng.conf. In principe is het niet complex te noemen, vooral gezien het feit dat er meer dan een dozijn beschikbaar zijn op de projectwebsite kant-en-klare voorbeelden, vaak hoeft u alleen maar de meest geschikte te kiezen en deze zelf te bewerken.

HAProxy

Werkt op verschillende x86-, x86_64-, Alpha-, SPARC-, MIPS-, PARISC-architecturen. Ondersteunt officieel Linux 2.6.32+ (aanbevolen voor maximale prestaties) en 2.4, Solaris 8–10, FreeBSD, OpenBSD. Installatie en configuratie zijn triviaal, hoewel het pakket niet aanwezig is in de repositories. Het project biedt broncode gelicentieerd onder GPL v2 en kant-en-klare binaire bestanden voor Linux/x86 Glibc 2.2 en Solaris8/Sparc.

Pond - proxy en balancering van HTTP en HTTPS

Het oorspronkelijke doel van het Pound-project was om de belasting over meerdere Zope-servers te verdelen, wat resulteerde in een zeer gerichte tool die een reverse proxy en load balancer is voor HTTP en HTTPS.

Het balanceren gebeurt op basis van de sessiestatus en andere parameters (URL, authenticatie, cookies, HTTP-headers). Volledige ondersteuning WebDAV. In tegenstelling tot HAProxy verwerkt het SSL. Ontwikkeld door een IT-bedrijf dat zich bezighoudt met beveiliging, wat ook de mogelijkheden van het product beïnvloedde. Bijzonder is de aanwezigheid van basic Webfuncties Application Firewall, Pound kan de juistheid van HTTP- en HTTPS-headers controleren en onjuiste headers negeren. Standaard worden alle verzoeken genegeerd, maar u kunt URL-patronen en verzoektypen (standaard, geavanceerd, RPC en WebDAV) maken die op overeenkomsten worden gecontroleerd. Op basis van de resultaten wordt de uiteindelijke server geselecteerd of wordt de verbinding geblokkeerd. Het ontwerp zorgt in eerste instantie voor minimale interferentie met verkeer (bijvoorbeeld het insluiten van cookies), maar kan X-Forwarded-for specificeren om het IP-adres van de gebruiker naar de backend-server te verzenden.

Ondersteunt IPv6, kan IPv6-clients overbrengen naar IPv4-servers. De sessie-informatie wordt opgeslagen en de client maakt vervolgens verbinding met zijn server.

Uit de details blijkt dat het niet alleen mogelijk is om een verbinding naar de backend te sturen, maar ook om door te sturen naar een andere URL.

Pound heeft niet veel bronnen nodig; het is opmerkelijk dat de daemon, afgezien van het lezen van SSL-certificaten, geen toegang heeft tot de harde schijf. Kan in chroot worden uitgevoerd en setuid/setgid gebruiken. Er zijn geen ingebouwde fouttolerantiemechanismen. Backend-functionaliteit wordt altijd gecontroleerd via HTTP.

Op een Pentium D-level processor kan deze ongeveer 600–800 HTTP- en 200–300 HTTPS-verbindingen per seconde realiseren. Het sterke punt van Pound zijn dan ook kleine projecten met de nadruk op bereikbaarheid, veiligheid en meer controle boven het verkeer. Voor meer hoge belasting De Pound-ontwikkelaars raden zelf aan andere oplossingen te gebruiken.

Installatie en configuratie zijn niet erg moeilijk, hoewel ze worden gedaan met behulp van configuratiebestanden (de documentatie is zeer gedetailleerd). Officieel getest op Linux, Solaris en OpenBSD. Het project biedt alleen broncodes; kant-en-klare pakketten zijn te vinden in de SUSE-, Debian- en Ubuntu-repository's; daarnaast bevat de site links voor Red Hat en een kant-en-klare distributie gebouwd op FreeBSD.