Taakverdeling

U kunt uitschalen door nieuwe virtuele machines online te brengen wanneer het verkeer toeneemt; dit is een efficiënte strategie om de schaal aan te passen aan de vraag. Het feit dat VM's snel kunnen worden ingericht, is essentieel voor het bereiken van elasticiteit. Het online brengen van extra servers is echter alleen nuttig wanneer het verkeer tussen deze servers wordt gedistribueerd. Over het algemeen zorgt u er zo wel voor dat het systeem de hogere belasting kan verwerken. Daarom is taakverdeling zo essentieel voor de elasticiteit, omdat u het aantal resources dat aan een taak wordt besteed dynamisch kunt aanpassen.

Aan de behoefte aan taakverdeling liggen twee basisvereisten ten grondslag. Ten eerste is de doorvoer verbeterd door parallelle verwerking. Als één server 5000 aanvragen per tijdseenheid kan verwerken, kunnen 10 servers met gelijke taakverdeling 50.000 aanvragen per tijdseenheid verwerken. Ten tweede leveren resources met gelijke taakverdeling een hogere beschikbaarheid. In plaats van een aanvraag door te sturen naar een server die de belasting al nauwelijks aankan, kan een load balancer de aanvraag doorsturen naar een server met een lichtere workload. Als een server vervolgens offline gaat en de load balancer dit herkent, kan deze bovendien aanvragen doorsturen naar andere servers.

Wat is taakverdeling?

Een bekende vorm van taakverdeling is round robin DNS, die veel grote webservices gebruiken om aanvragen tussen verschillende servers te distribueren. Met name meerdere front-endservers, elk met een uniek IP-adres, kunnen een DNS-naam delen. Om het aantal aanvragen op elke webserver te verdelen, moeten grote bedrijven zoals Google een pool met IP-adressen onderhouden en cureren voor elk DNS-item. Wanneer een client een aanvraag indient (bijvoorbeeld om te www.google.com), selecteert de DNS van Google een van de beschikbare adressen uit de groep en verzendt deze naar de client. De eenvoudigste strategie die wordt gebruikt voor het verzenden van IP-adressen is het gebruik van een round robin-wachtrij, waarbij na elke DNS-reactie de lijst met adressen wordt gepermuteerd.

Vóór de komst van de cloud was DNS-taakverdeling een eenvoudige manier om de latentie van verbindingen over lange afstanden te verminderen. De dispatcher van de DNS-server was geprogrammeerd om te reageren met het IP-adres van de server die zich geografisch het dichtst in de buurt van de client bevond. De eenvoudigste manier hiervoor was reageren met het IP-adres uit de pool die zich numeriek het dichtst bij het IP-adres van de client bevond. Deze methode was onbetrouwbaar, omdat IP-adressen niet worden gedistribueerd in een globale hiërarchie. De huidige technieken zijn geavanceerder en zijn afhankelijk van een softwaretoewijzing van IP-adressen aan locaties op basis van fysieke toewijzingen van internetproviders (ISP's). Omdat deze toewijzing is geïmplementeerd als een dure softwarezoekopdracht, levert deze methode betere resultaten op, maar is het kostbaar om te berekenen. De kosten voor een langzame zoekactie worden echter afgeschreven omdat de DNS-zoekopdracht alleen plaatsvindt wanneer de eerste verbinding met een server door de client wordt gemaakt. Alle volgende communicatie vindt direct plaats tussen de client en de server die eigenaar is van het verzonden IP-adres. Een voorbeeld van een schema voor DNS-taakverdeling wordt weergegeven in afbeelding 9.

Afbeelding 9: Taakverdeling in een cloudomgeving.

Het nadeel van deze methode is een serverfout; de overschakeling naar een ander IP-adres is afhankelijk van de TTL-configuratie (Time-To-Live) van de DNS-cache. Van DNS-vermeldingen is bekend dat ze een lange levensduur hebben en dat het uitvoeren van updates meer dan een week kan duren. Dit betekent dat het lastig is om een serverfout snel te verbergen voor de client. Door de geldigheid (TTL) van een IP-adres in de cache te beperken, worden de kosten voor prestaties verbeterd en wordt het aantal zoekopdrachten verhoogd.

Moderne taakverdeling verwijst vaak naar het gebruik van een toegewezen instantie (of een paar instanties) om binnenkomende aanvragen naar back-endservers te verzenden. Voor elke binnenkomende aanvraag op een opgegeven poort stuurt de load balancer het verkeer, op basis van een distributiestrategie, naar een van de back-endservers. Hierdoor beheert de load balancer de metagegevens van de aanvraag, inclusief informatie zoals toepassingsprotocolheaders (bijvoorbeeld HTTP-headers). In deze situatie hoeft u zich geen zorgen te maken over verouderde informatie, aangezien elke aanvraag via de load balancer verloopt.

Hoewel alle typen netwerktaakverdelers aanvragen samen met elke context naar de back-endservers doorsturen, kunnen ze, wanneer het gaat om het leveren van het antwoord aan de client, een van de twee basisstrategieën¹ gebruiken:

• Via een proxy verzenden: bij deze methode ontvangt de load balancer de reactie van de back-end en stuurt deze de reactie terug naar de client. De load balancer gedraagt zich als een standaardwebproxy en is betrokken bij beide delen van een netwerktransactie, namelijk bij het doorsturen van de aanvraag naar de client en bij het terugsturen van het antwoord.

• TCP-overdracht: bij deze methode wordt de TCP-verbinding met de client aan de back-endserver doorgegeven en stuurt de server het antwoord rechtstreeks naar de client, zonder dit via de load balancer te laten lopen.

De laatste van deze strategieën wordt geïllustreerd in afbeelding 10.

Afbeelding 10: TCP-overdrachtsmechanisme van de dispatcher naar de back-endserver.

Voordelen van taakverdeling

Een van de voordelen van taakverdeling is dat hiermee fouten in een systeem kunnen worden gemaskeerd. Zolang de client wordt blootgesteld aan één eindpunt dat meerdere resources vertegenwoordigt, worden fouten in afzonderlijke resources voor de client verborgen door aanvragen te sturen die gebruikmaken van andere resources. Nu wordt de load balancer echter zelf een Single Point of Failure. Als het om wat voor reden dan ook mislukt, worden er geen clientaanvragen verwerkt, zelfs als alle back-endservers nog steeds functioneren. Voor een hoge beschikbaarheid worden de load balancers vaak in paren geïmplementeerd.

Belangrijker is dat met taakverdeling de reactiesnelheid wordt verbeterd door workloads te verdelen over verschillende rekenresources in de cloud. Wanneer u maar één rekeninstantie in de cloud hebt, gelden er verschillende beperkingen. In eerdere modules werden de fysieke beperkingen wat prestaties betreft besproken, waarbij er meer resources nodig zijn voor het vergroten van workloads. Door taakverdeling te gebruiken, worden grotere workloads gedistribueerd over meerdere resources, zodat elke resource de aanvragen onafhankelijk en parallel kan uitvoeren, waardoor de doorvoer van de toepassing wordt verbeterd. Taakverdeling verbetert ook de gemiddelde reactietijden omdat er meer servers zijn om de workload te verwerken.

Statuscontroles zijn essentieel voor het implementeren van succesvolle taakverdelingsstrategieën. Een load balancer moet weten wanneer een resource niet meer beschikbaar is, zodat er geen verkeer naar die resource kan worden doorgestuurd. Ping-echobewaking, waarbij de load balancer een 'ping' met ICMP-aanvragen (Internet Control Message Protocol) naar servers stuurt, is een van de populairste tactieken die worden gebruikt om de status van specifieke resources te controleren. Niet alleen wordt rekening gehouden met de status van een resource bij het doorsturen van verkeer; ook andere strategieën voor taakverdeling spelen een rol bij andere metrische gegevens zoals doorvoer, latentie en CPU-gebruik.

Load balancers moeten vaak hoge beschikbaarheid garanderen. De eenvoudigste manier om dit te doen is door meerdere taakverdelingsinstanties (elk met een uniek IP-adres) te maken en deze te koppelen aan één DNS-adres. Wanneer een load balancer om een of andere reden mislukt, wordt deze vervangen door een nieuwe en wordt al het verkeer doorgegeven aan de failoverinstantie, met minimale gevolgen voor de prestaties. Er kan tegelijkertijd een nieuwe load balancer-instantie worden geconfigureerd om de mislukte load balancer te vervangen, en DNS-records moeten onmiddellijk worden bijgewerkt.

Naast het distribueren van aanvragen naar back-endservers gebruiken load balancers vaak mechanismen om de belasting op de servers te verminderen en de algehele doorvoer te verbeteren. Enkele van deze mechanismen zijn:

• SSL-offload : VOOR HTTPS-verbindingen worden extra prestatiekosten in rekening gebracht omdat verkeer via deze verbindingen is versleuteld. In plaats van alle aanvragen via SSL (Secure Sockets Layer) te laten lopen, kan de clientverbinding met de load balancer via SSL tot stand worden gebracht, terwijl aanvragen via niet-versleutelde HTTP naar elke server worden omgeleid. Door deze techniek wordt de belasting op de servers aanzienlijk verminderd. Daarnaast wordt de beveiliging gehandhaafd zolang de aanvragen voor omleiding niet worden uitgevoerd via een open netwerk.

• TCP-buffering: een strategie om clients met trage verbindingen naar de load balancer over te hevelen om servers die deze clients van antwoorden voorzien te ontlasten.

• Caching : in bepaalde scenario's kan de load balancer een cache onderhouden voor de populairste aanvragen (of aanvragen die kunnen worden verwerkt zonder naar de servers te gaan, zoals statische inhoud) om de belasting op de servers te verminderen.

• Het vormgeven van verkeer : een load balancer kan deze techniek gebruiken om de stroom van pakketten te vertragen of te herpriritiseren om het verkeer voor de serverconfiguratie te optimaliseren. Dit heeft weliswaar invloed op de QoS voor sommige aanvragen, maar zorgt er wel voor dat de binnenkomende belasting kan worden verwerkt.

Het is belangrijk om te onthouden dat taakverdeling alleen werkt als er geen onveranderbare belasting op de load balancer is. Anders wordt de load balancer het knelpunt. Gelukkig vindt op load balancers weinig verwerking plaats van de aanvragen die ze ontvangen, maar wordt gebruikgemaakt van back-endservers om het werkelijke werk van het omzetten van aanvragen in reacties uit te voeren.

Evenwichtige verzending

Er worden verschillende taakverdelingsstrategieën in de cloud gebruikt. Een van de meest voorkomende is rechtvaardige verzending, die gebruikmaakt van een eenvoudig round robin-algoritme om verkeer gelijkmatig te verdelen tussen alle knooppunten. Er wordt geen rekening gehouden met het gebruik van afzonderlijke resources in het systeem. Ook speelt de uitvoeringstijd van de aanvraag geen rol. Bij deze methode wordt geprobeerd elk knooppunt in het systeem bezet te houden; dit is een van de eenvoudigste implementaties.

AWS maakt gebruik van deze methode in de aanbieding voor elastische load balancers (ELB). Met ELB worden load balancers ingericht die verkeer verdelen over gekoppelde EC2-instanties. Load balancers zijn in wezen zelf ook EC2-instanties met als specifieke taak verkeer om te leiden. Wanneer de resources achter de load balancer worden uitgeschaald, worden de IP-adressen van de nieuwe resources bijgewerkt in de DNS-record van de load balancer. Dit proces duurt enkele minuten, omdat zowel de monitoring als de inrichting tijd kost. Deze periode van schalen, de wachttijd totdat de load balancer gereed is voor het verwerken van de hogere belasting, wordt aangeduid als het 'opwarmen' van de load balancer.

Ook worden met load balancers van AWS de resources bewaakt die aan de load balancer zijn gekoppeld, voor de verdeling van workloads om een statuscontrole te onderhouden. Een ping-echo-mechanisme wordt gebruikt om ervoor te zorgen dat alle resources in orde zijn. ELB-gebruikers kunnen de parameters van de statuscontrole configureren door de vertragingen en het aantal nieuwe pogingen op te geven.

Hash-distributie

Met deze methode wordt geprobeerd ervoor te zorgen dat aanvragen van dezelfde client voor de duur van een sessie steeds naar dezelfde server worden omgeleid door metagegevens van een hash te voorzien, zodat elke aanvraag wordt gedefinieerd en de hash wordt gebruikt om een server te kiezen. Als een hash op de juiste manier wordt toegewezen, worden aanvragen relatief gelijkmatig over servers verdeeld. Een voordeel van deze methode is dat deze uitermate geschikt is voor sessiebewuste toepassingen, waardoor sessiegegevens in het geheugen kunnen worden opgeslagen in plaats van deze naar een gedeeld gegevensarchief, zoals een database of Redis-cache, te schrijven. Een nadeel is dat elke aanvraag van een hash moet worden voorzien, waardoor een geringe latentie ontstaat.

Azure Load Balancer gebruikt een op hash-codes gebaseerd mechanisme voor het distribueren van belasting. Met dit mechanisme wordt voor elke aanvraag een hash gemaakt op basis van bron-IP, bronpoort, doel-IP, doelpoort en protocoltype om ervoor te zorgen dat onder normale omstandigheden elk pakket uit dezelfde sessie op dezelfde back-endserver komt. De hash-functie is gekozen, zodat de distributie van verbindingen met servers willekeurig is.

Andere strategieën voor taakverdeling

Als een bepaalde server vastloopt terwijl er een aanvraag (of een set aanvragen) werd verwerkt, worden aanvragen alsnog naar die server doorgestuurd door load balancers die gebruikmaken van round robin of op hash-gebaseerde algoritmen voor het verzenden van gegevens. Er zijn nog andere, geavanceerdere strategieën voor het verdelen van de belasting over meerdere resources die rekening houden met capaciteit. Twee van de meest gebruikte metrische gegevens voor het meten van de capaciteit zijn:

• Uitvoeringstijd aanvragen : strategieën op basis van deze metrische gegevens maken gebruik van een algoritme voor prioriteitsplanning, waarbij uitvoeringstijden van aanvragen worden gebruikt om de bestemming voor afzonderlijke aanvragen te kiezen. De belangrijkste uitdaging bij het gebruik van deze methode is om de uitvoeringstijden nauwkeurig te meten. Een load balancer kan uitvoeringstijden raden door een tabel in het geheugen te gebruiken (en continu bij te werken) waarin de verschillen worden opgeslagen tussen de tijd waarop een aanvraag wordt doorgestuurd naar elke server en de tijd waarop de aanvraag wordt geretourneerd.

• Resourcegebruik : strategieën op basis van deze metrische waarde gebruiken CPU-gebruik om het gebruik over knooppunten te verdelen. De load balancer houdt een geordende lijst met resources bij op basis van het gebruik en stuurt elke aanvraag die wordt ontvangen door naar de resource die de minste belasting ondervindt.

Taakverdeling is van cruciaal belang voor het implementeren van schaalbare cloudservices. Zonder een doeltreffend middel voor het distribueren van verkeer tussen back-endresources, is de elasticiteit die wordt bereikt door resources te maken wanneer ze nodig zijn en ze te verwijderen wanneer ze niet meer nodig zijn, aanzienlijk beperkt.

Verwijzingen

1. Aron, Mohit en Sanders, Darren en Druschel, Peter en Zwaenepoel, Willy (2000). 'Schaalbare inhoudsbewuste aanvraagdistributie in netwerkservers op basis van clusters'. Proceedings of the 2000 Annual USENIX technical Conference.