HAProxy en load balancing-concepten: de basis

Introductie

High Availability Proxy (HAProxy), is een populaire open-source proxy- en TCP/HTTP-load balancer-oplossing die kan draaien op Solaris, FreeBSD, en Linux. Het wordt het meest gebruikt om de betrouwbaarheid en prestaties van een serveromgeving te verbeteren door te zorgen voor een evenredige verdeling van de werklast over meerdere servers. Dit type tool wordt gebruikt in veel bekende omgevingen zoals Instagram, GitHub, Twitter en Imgur.

Deze gids introduceert u in HAProxy, maakt u vertrouwd met de load-balancingterminologie en geeft voorbeelden van hoe het kan worden ingezet om zowel de prestaties als de betrouwbaarheid van serveromgevingen te verbeteren.

Essentiële HAProxy-termen

Voordat we ingaan op de details van load balancing en proxying, zijn er enkele belangrijke termen en concepten waarmee u vertrouwd moet raken. We beginnen met het doornemen van deze concepten in de volgende secties.

ACL (Access Control List)

Als het gaat om load balancing, ACL's worden gebruikt om een specifieke voorwaarde te testen en een actie uit te voeren op basis van het resultaat. Dit biedt de mogelijkheid om verkeer optimaal door te sturen op basis van factoren zoals backend-verbindingen en patroonherkenning, evenals vele andere. Hier is een voorbeeld van een ACL in gebruik:

In dit geval is er een match voor de ACL als het door de gebruiker opgevraagde pad begint met /blog. Dit overeenkomstige verzoek zou bijvoorbeeld verwijzen naar http://yourdomain.com/blog/blog-entry-1. De HAProxy Configuration Manual bevat een gedetailleerde gids voor het gebruik van ACL's.

De Backend

Doorgestuurde verzoeken worden ontvangen door een set servers die de backend wordt genoemd. De verzoeken worden gedefinieerd in de backend-sectie van de HAProxy-configuratie. In de meest eenvoudige bewoordingen kan een backend worden gedefinieerd door de te gebruiken load balancing-algoritmen en een lijst van poorten en servers. Een backend kan bestaan uit een enkele server of meerdere servers. Naarmate er meer servers aan de backend worden toegevoegd, neemt de potentiële capaciteit toe, waarbij de verwerking over meerdere servers wordt verdeeld. Als sommige backend-servers offline gaan, dienen de andere als back-up voor het verwerken van de verzoeken.

Laten we’s kijken naar een voorbeeld van een configuratie met twee backends. In dit geval zijn dat een blog-backend en een web-backend. Elk heeft twee webservers die luisteren op poort 80:

De regel balance roundrobin is bedoeld om het load balancing-algoritme te specificeren. De details zijn te vinden in de volgende sectie Algorithms for Load Balancing, terwijl mode http het gebruik van layer 7-proxying instelt. Dit leggen we uit in de sectie Load Balancing Types. Bovendien geeft de optie check na de serverdefinities aan dat er statuscontroles worden uitgevoerd op die specifieke backend-servers.

De Frontend

De definitie van hoe verzoeken naar de backend worden doorgestuurd, wordt de frontend genoemd. De verzoeken worden gedefinieerd in de frontend-sectie van de HAProxy-configuratie. Ze bestaan uit ACL's, een poort, een set IP-adressen en een regel die bepaalt welke backends moeten worden gebruikt op basis van de voldane ACL-voorwaarden, de zogenaamde use_backend-regel. Daarnaast bestaat er ook een default_backend-regel voor alle andere gevallen. In de volgende sectie wordt uitgelegd hoe een frontend kan worden geconfigureerd voor verschillende soorten netwerkverkeer.

Typen load balancing

Nu de basiscomponenten voor load balancing zijn vastgesteld, kunnen we overgaan naar de basistypen van load balancing.

Geen load balancing

In de meest rudimentaire vorm kan een gebrek aan load balancing als volgt worden geïllustreerd:

In dit scenario maakt een gebruiker rechtstreeks verbinding met de webserver op yourdomain.com. Er is geen load balancing aanwezig. Omdat er slechts één databaseserver is, wordt de toegang tot de informatie daarop volledig afgesneden als deze offline gaat. Als veel gebruikers tegelijkertijd verbinding proberen te maken met een enkele webserver en deze de belasting die dat met zich meebrengt niet aankan, zullen alle verbindingen vertragen of helemaal mislukken.

Load Balancing (laag 4)

Een van de eenvoudigste, meest pragmatische manieren om netwerkverkeer over meerdere servers te verdelen, is door gebruik te maken van transportlaag- of laag 4-balancingmethoden. Deze manier van load balancing stuurt elke verbindende gebruiker door op basis van de poort en de IP-reeks waar hun IP-adres binnen valt. Met andere woorden, als http://yourdomain.com/anything de plek is waar het verzoek vandaan komt, zal de backend die is gedefinieerd om deze verzoeken af te handelen degene zijn die ze uiteindelijk verwerkt. Deze zal die verzoeken voor yourdomain.com doorsturen op poort 80.

De basisopstelling van laag 4 load balancing ziet er als volgt uit:

Zodra de gebruiker toegang krijgt tot de load balancer, worden hun verzoeken doorgestuurd naar de web-backend servergroep. De geconfigureerde backendserver zal rechtstreeks reageren op het verzoek van de gebruiker. Om te voorkomen dat de gebruiker inconsistente gegevens te zien krijgt, moeten alle web-backendservers identieke inhoud serveren. Zoals in het bovenstaande diagram te zien is, zijn beide webservers uiteindelijk gekoppeld aan dezelfde databaseserver.

Load Balancing (Laag 7)

Er is nog een andere, complexere methode om netwerkverkeer te verdelen. Dat is door gebruik te maken van niveau 7, of applicatielaag, load balancing. Deze aanpak maakt het mogelijk om gebruikersverzoeken door te sturen naar verschillende backendservers, afhankelijk van de inhoud van de gebruikersverzoeken. Deze methode maakt het mogelijk om load balancing uit te voeren over meerdere webapplicatieservers via dezelfde poort en hetzelfde domein. Kijk voor meer details over deze laag in de HTTP-subsectie van onze The Nitty Gritty of Networking: Learn about Terminology, Interfaces, and Protocols tutorial.

Het volgende diagram illustreert laag 7 load balancing:

In dit geval vraagt een gebruiker yourdomain.com/blog op, en wordt hun verzoek doorgestuurd naar de blog-backend. Dit is een backend-serverset die specifiek is toegewezen aan het draaien van de blog-applicatie. Ondertussen worden andere verzoeken doorgestuurd naar de web-backend. Beide backends leiden echter uiteindelijk naar dezelfde databaseserver.

Een voorbeeld van een klein stukje frontend-configuratie voor laag 7 load balancing zou eruitzien als de volgende commando's. Ze configureren de http-frontend om inkomend verkeer via poort 80 af te handelen:

Als het pad van het verzoek van de gebruiker begint met /blog, zal de acl url_blog path_beg /blog overeenkomen met het verzoek.

use_backend blog backend if url_blog proxiet het verkeer naar blog-backend met behulp van ACL.

defaut_backen web_backend stuurt al het andere verkeer door naar web-backend.

Algoritmen voor load balancing

Wanneer load balancing wordt uitgevoerd, is het het load balancing-algoritme dat bepaalt welke backend-server voor dit doel wordt geselecteerd. Er zijn verschillende algoritme-opties die door HAProxy worden aangeboden. Het is daarnaast mogelijk om een gewichtsparameter aan de servers toe te wijzen om te beïnvloeden hoe vaak een server wordt geselecteerd in vergelijking met andere. Er zijn simpelweg te veel algoritmen beschikbaar om ze allemaal te beschrijven. Daarom zal deze gids zich alleen richten op de meest voorkomende. Je kunt de HAProxy Documentation Converter raadplegen om de volledige lijst te bekijken. De meest gebruikte zijn onder andere:

• roundrobin: Het standaardalgoritme dat servers om de beurt selecteert.
• leastconn: De server met de minste verbindingen wordt automatisch geselecteerd. De servers binnen dezelfde backend moeten echter op een round-robin-manier worden geroteerd.
• source: Het algoritme kiest de server op basis van het IP-adres van waaruit het gebruikersverzoek afkomstig is. Dit is een methode om ervoor te zorgen dat de gebruiker altijd verbinding maakt met dezelfde server.

Sticky Sessions

Voor sommige applicaties is het een vereiste dat gebruikers die verbinding maken, dit doen door altijd naar dezelfde server te worden geleid. Via ‘sticky sessions’ en door gebruik te maken van de appsession-parameter in de backend die dit vereist, kan een dergelijke persistentie worden bereikt.

Health checks verwerken

HAProxy heeft een methode nodig waarmee het kan bepalen of een backend-server in staat is om verzoeken te verwerken. Dit dient om een server uit de backend te verwijderen als deze offline gaat. Er wordt standaard een 'health check' uitgevoerd die probeert een TCP-verbinding tot stand te brengen. Dit gebeurt door te luisteren op het geconfigureerde IP-adres en de poort.

Als de health check voor de server mislukt, kan de server geen verzonden verzoeken verwerken. Op dat moment wordt de server automatisch uitgeschakeld in de backend, waarbij er geen verkeer meer naar wordt doorgestuurd totdat deze weer actief en operationeel (gezond) is. In bepaalde gevallen blijkt het bepalen van de gezondheid van de server via de standaard health check echter onvoldoende.

Alternatieve oplossingen

HAProxy kan te geavanceerd blijken te zijn voor jouw specifieke behoeften. In dat geval zijn er een paar goede alternatieven die efficiënter kunnen blijken te zijn:

• Nginx: Dit is een betrouwbare en snelle webserver die kan worden ingezet voor load balancing en proxy-doeleinden. In feite wordt Nginx vaak gebruikt in combinatie met HAProxy, dat gebruikmaakt van de compressie- en cachingmogelijkheden ervan.
• Linux Virtual Servers (LVS): Dit is een eenvoudige layer 4 load balancer die op veel Linux-systemen is inbegrepen.

Hoge beschikbaarheid

Tot nu toe hebben we het gehad over layer 4 en layer 7 load balancing. Beide maken gebruik van een load balancer om te bepalen welke van de vele backend-servers de taak krijgt om te reageren op het verzoek van de gebruiker. Maar het is belangrijk om rekening te houden met de beperkingen van een load balancer. Namelijk dat het een ‘single point of failure’ is. Dit betekent dat als deze offline zou gaan, of overbelast raakt met gebruikersverzoeken, dit zal leiden tot respectievelijk downtime of vertraging in de verwerking van verzoeken. Een HA-setup (high availability of hoge beschikbaarheid) biedt echter een infrastructuur die geen enkel storingspunt heeft. Dit voorkomt downtime als gevolg van serveruitval door redundantie te introduceren op elk niveau van de systeemarchitectuur. Hoewel de load balancer helpt om de redundantie van de backend te faciliteren, moeten de load balancers zelf ook redundantie toepassen.

Het volgende diagram toont een basisvorm van een high availability-setup:

Deze infrastructuur heeft verschillende load balancers (één actieve, de rest passief) die gekoppeld zijn aan een statisch IP-adres. Dit IP-adres kan naar een andere server worden omgeleid als de situatie dat vereist. Het gebruikersverzoek verloopt via het externe IP-adres naar de momenteel actieve load balancer. Als de load balancer op dat moment offline is, zal het failsafe-mechanisme de status ervan detecteren en het IP-adres opnieuw toewijzen aan de passieve server(s).

Conclusie

Het fundamentele begrip van load balancing en kennis van enkele manieren waarop HAProxy kan voldoen aan de load balancing-behoeften van uw systeem, zouden u een solide basis moeten geven om aan de slag te gaan met het optimaliseren van de betrouwbaarheid en prestaties van uw huidige serveromgevingen. U kunt ook onze tutorial bekijken Nginx HTTP-proxying, load balancing, buffering en caching: een overzicht om meer te leren over de load balancing-eigenschappen van Nginx.

Veel computerplezier!