Lastenausgleich
Zwei grundlegende Anforderungen machen bei Berechnungen einen Lastenausgleich erforderlich. Erstens: Durch Replikation kann die Hochverfügbarkeit verbessert werden. Zweitens: Durch Parallelverarbeitung kann die Leistung verbessert werden. Hochverfügbarkeit bedeutet, dass ein Dienst nahezu 100 % der Zeit zur Verfügung steht, in der ein Client versucht, darauf zuzugreifen. Die Dienstqualität (Quality of Service, QoS) eines bestimmten Diensts umfasst in der Regel Überlegungen zu beispielweise Durchsatz- und Latenzanforderungen.
Was ist ein Lastenausgleich?
Die bekannteste Art des Lastenausgleichs stellt das „Roundrobin-DNS“ dar, das von vielen großen Webdiensten für eine gleichmäßige Verteilung von Anforderungen auf eine Reihe von Servern verwendet wird. Mehrere Front-End-Webserver mit jeweils einer eindeutigen IP-Adresse verwenden dabei einen gemeinsamen DNS-Namen. Große Unternehmen wie Google verwalten und erstellen einen Pool mit IP-Adressen, die den einzelnen DNS-Einträgen zugeordnet werden, um die Anzahl der Anforderungen gleichmäßig auf die Webserver zu verteilen. Wenn ein Client eine Anforderung sendet (z. B. an die Domäne www.google.com), wählt das DNS von Google eine der verfügbaren Adressen aus dem Pool aus und sendet sie an den Client. Die einfachste Möglichkeit zur Verteilung von IP-Adressen ist die Verwendung einer einfachen Roundrobin-Warteschlange, bei der nach jeder DNS-Antwort die Liste der Adressen umgestellt wird.
Vor dem Aufkommen der Cloud stellte der DNS-Lastenausgleich eine einfache Möglichkeit zur Verringerung der Latenz bei Fernverbindungen dar. Der Verteiler auf dem DNS-Server wurde so programmiert, dass er mit der IP-Adresse des Servers antwortete, der dem Client geografisch am nächsten war. Dies sollte dadurch erreicht werden, dass die IP-Adresse im Pool, die der IP-Adresse des Clients numerisch am nächsten war, für die Antwort verwendet wurde. Da IP-Adressen jedoch nicht global hierarchisch verteilt werden, war diese Methode zwangsläufig unzuverlässig. Die aktuelle Vorgehensweise ist komplexer: Sie beruht auf einer Softwarezuordnung zwischen IP-Adressen und Standorten, die auf physischen Karten von Internetdienstanbietern (ISPs) basiert. Diese Methode führt zu genaueren Ergebnissen, ist in der Berechnung jedoch teuer, da sie als kostenaufwändige Softwaresuche implementiert wird. Die Kosten für eine langsame Suche amortisieren sich jedoch, da eine DNS-Suche nur dann ausgeführt wird, wenn die erste Verbindung zu einem Server vom Client hergestellt wird. Die nachfolgende Kommunikation erfolgt dann direkt zwischen dem Client und dem Server, der die verteilte IP-Adresse besitzt. Die folgende Abbildung zeigt das Beispielschema eines DNS-Lastenausgleichs.
Abbildung 4: Lastenausgleich in einer Cloudhoustingumgebung
Der Nachteil dieser Methode zeigt sich bei einem Serverfehler, da der Wechsel zu einer anderen IP-Adresse von der konfigurierten Gültigkeitsdauer (TTL) des DNS-Caches abhängt. DNS-Einträge besitzen eine lange Gültigkeitsdauer, und die Weitergabe von Updates über das Internet dauert bekanntermaßen länger als eine Woche. Daher ist es schwierig, Serverfehler schnell vor dem Client zu verbergen. Das Verkürzen der Gültigkeitsdauer einer IP-Adresse im Cache kann hier zwar Abhilfe schaffen, führt jedoch zu Leistungseinbußen und einer höheren Anzahl von Suchvorgängen.
Moderne Load Balancer verwenden häufig eine dedizierte Instanz (oder ein Instanzenpaar), um eingehenden Datenverkehr an die Back-End-Server weiterzuleiten. Bei jeder an einem angegebenen Port eingehenden Anforderung leitet der Load Balancer den Datenverkehr gemäß einer Verteilungsstrategie an einen der Back-End-Server um. Dabei verwaltet der Load Balancer die Metadaten der Anforderung, wie etwa Anwendungsprotokollheader (z. B. HTTP-Header). Da jede Anforderung den Load Balancer durchläuft, spielen veraltete Informationen hier keine Rolle.
Wenngleich sämtliche Arten von Lastenausgleichsmodulen für Netzwerke die Benutzerinformationen an die Back-End-Server zusammen mit jeglichem Kontext einfach weiterleiten, stehen ihnen beim Zurücksenden der Antwort an den Client zwei grundlegende Strategien zur Verfügung:1
- Proxyfunktion: Bei dieser Vorgehensweise empfängt der Load Balancer die Antwort vom Back-End und leitet sie an den Client weiter. Der Load Balancer verhält sich wie ein Standardwebproxy und ist an beiden Teilen der Netzwerktransaktion beteiligt, d. h. an der Weiterleitung der Anforderung an den Client und am Zurücksenden der Antwort.
- TCP-Übergabe: Hier wird die TCP-Verbindung mit dem Client an den Back-End-Server übergeben. Der Server sendet die Antwort also direkt an den Client, ohne Durchlaufen des Load Balancers.
Abbildung 5: Schema der TCP-Übergabe vom Verteiler zum Back-End-Server
Auswirkungen auf die Verfügbarkeit und Leistung
Der Lastenausgleich ist eine wichtige Methode zum Verschleiern von Fehlern in einem System. Wird der Client des Systems auf einem einzelnen Endpunkt, der die Last auf mehrere Ressourcen verteilt, verfügbar gemacht, können Fehler in einzelnen Ressourcen vor dem Client verborgen werden, indem die Anforderung einfach an eine andere Ressource geleitet wird. Beachten Sie jedoch, dass nun der Load Balancer einen „Single Point of Failure“ (eine einzelne Fehlerquelle) für den Dienst darstellt. Bei einem beliebigen Fehler im Load Balancer können keine Clientanforderungen mehr verarbeitet werden, und dies bei voller Funktionsfähigkeit der Back-End-Server. Daher werden Load Balancer zur Gewährleistung von Hochverfügbarkeit häufig als Paar implementiert.
Über den Lastenausgleich kann ein Dienst Workloads auf mehrere Computeressourcen in der Cloud verteilen. Eine einzelne Compute-Instanz in der Cloud weist mehrere Einschränkungen auf. Die physische Leistungseinschränkung haben Sie bereits kennengelernt: Für eine größere Anzahl von Workloads sind mehr Ressourcen erforderlich. Durch Verwendung des Lastenausgleichs kann eine größere Anzahl von Workloads auf mehrere Ressourcen verteilt werden, sodass jede Ressource ihre Anforderungen zeitgleich und unabhängig ausführen kann, wodurch der Durchsatz der Anwendung erhöht wird. Damit werden auch die durchschnittlichen Verarbeitungszeiten verkürzt, da die Workload von einer größeren Anzahl von Servern verarbeitet wird.
Für ein Gelingen des Lastenausgleichs ist das Überprüfen und Überwachen der Dienste entscheidend. Ein Load Balancer muss die Ausführung jeder Anforderung gewährleisten, indem er sicherstellt, dass alle Ressourcenknoten verfügbar sind. Andernfalls wird der Datenverkehr nicht an diesen speziellen Knoten weitergeleitet. Eine der beliebtesten Methoden zur Überprüfung der Integrität eines bestimmten Ressourcenknotens ist die Ping-Echoüberwachung. Neben der Integrität eines Knotens erfordern einige Lastenausgleichsmethoden zusätzliche Informationen, etwa zum Durchsatz, der Latenz und der CPU-Auslastung, um die geeignetste Ressource zum Weiterleiten des Datenverkehrs zu bestimmen.
Load Balancer müssen häufig Hochverfügbarkeit garantieren. Die einfachste Möglichkeit hierfür besteht im Erstellen mehrerer Load Balancer-Instanzen (jeweils mit einer eindeutigen IP-Adresse), die jeweils mit einer einzigen DNS-Adresse verknüpft werden. Tritt bei einer Load Balancer-Instanz ein Fehler auf, wird sie durch eine neue ersetzt, und der gesamte Datenverkehr wird mit geringen Leistungseinbußen an die Failoverinstanz übergeben. Gleichzeitig kann eine neue Load Balancer-Instanz als Ersatz für die fehlerhafte Instanz konfiguriert werden, und die DNS-Einträge sollten sofort aktualisiert werden.
Lastenausgleichsstrategien
In der Cloud stehen mehrere Strategien für den Lastenausgleich zur Verfügung.
Gleichmäßige Verteilung
Bei dieser statischen Methode für den Lastenausgleich wird ein einfacher Roundrobin-Algorithmus verwendet, um den Datenverkehr gleichmäßig auf alle Knoten zu verteilen. Dabei werden weder die Auslastung der einzelnen Ressourcenknoten im System noch die Ausführungszeit der Anforderungen berücksichtigt. Bei dieser Vorgehensweise sollen alle Knoten im System ausgelastet sein. Diese Methode lässt sich einfach implementieren. Ein entscheidender Nachteil besteht darin, dass umfangreiche Clientanforderungen aggregiert werden und in denselben Rechenzentren landen könnten, was bei einigen Knoten zu einer Überlastung, bei den anderen zu einer Unterauslastung führen würde. Voraussetzung dafür ist jedoch ein sehr spezifisches Auslastungsmuster, das bei einer großen Anzahl von Clients und Servern mit relativ gleichmäßiger Verteilung der Verbindungen und der Kapazität in der Praxis unwahrscheinlich ist. Bei dieser Methode ist es jedoch schwierig, in den Rechenzentren Cachingstrategien zu implementieren, die Überlegungen wie etwa die räumliche Position berücksichtigen (für einen Vorabruf und die Zwischenspeicherung von Daten in der Nähe von aktuell abgerufenen Daten). Dies liegt daran, dass die nächste Anforderung desselben Clients möglicherweise auf einem anderen Server ausgeführt wird.
AWS verwendet diese Methode für seine ELB-Funktion (Elastic Load Balancer). Der Elastic Load Balancer von AWS stellt Load Balancer bereit, die den Datenverkehr über angefügte EC2-Instanzen verteilen. Load Balancer stellen im Wesentlichen selbst EC2-Instanzen dar, die den speziellen Dienst enthalten, Datenverkehr weiterzuleiten. Werden die Ressourcen hinter dem Load Balancer horizontal skaliert, werden die IP-Adressen der neuen Ressourcen im DNS-Eintrag des Load Balancers aktualisiert. Dieser Vorgang dauert einige Minuten, da hierfür sowohl Überwachungs- als auch Bereitstellungszeit erforderlich ist. Diese Skalierungszeit (also die Wartezeit, bis der Load Balancer die höhere Last verarbeiten kann) wird als „Aufwärmphase“ des Load Balancers bezeichnet.
Zur Integritätsprüfung überwachen die Elastic Load Balancer von AWS zudem alle Ressourcen, die ihnen zur Verteilung der Workload angefügt wurden. Mithilfe eines Ping-Echomechanismus wird sichergestellt, dass alle Ressourcen fehlerfrei funktionieren. ELB-Benutzer können die Parameter der Integritätsprüfung durch Angabe der Verzögerungen und der Anzahl der Wiederholungen konfigurieren.
Hashbasierte Verteilung
Bei diesem Ansatz soll sichergestellt werden, dass Anforderungen eines Clients über dieselbe Verbindung immer an denselben Server weitergeleitet werden. Zur gleichmäßigen Verteilung des Datenverkehrs von Anforderungen geschieht dies in zufälliger Reihenfolge. Diese Vorgehensweise besitzt gegenüber der Roundrobin-Verteilung mehrere Vorteile. So ist sie etwa für Anwendungen geeignet, die für Sitzungen aktiviert sind, für die einfachere Strategien zur Statuspersistenz und Zwischenspeicherung ausreichen. Aufgrund der zufälligen Verteilung ist sie auch weniger anfällig für Datenverkehrsmuster, die zu einer Überlastung auf einem einzelnen Server führen könnten. Ein Restrisiko besteht jedoch weiterhin. Da jedoch für jede Anforderung die Verbindungsmetadaten ausgewertet werden müssen, um sie an den entsprechenden Server weiterzuleiten, wird für jede Anforderung eine geringe zusätzliche Latenz erzeugt.
In Azure Load Balancer wird zur Verteilung der Last ein hashbasierter Verteilungsmechanismus verwendet. Dabei wird für jede Anforderung ein Hash erstellt basierend auf Quell-IP, Quellport, Ziel-IP, Zielport und Protokolltyp. So wird sichergestellt, dass jedes Paket derselben Verbindung immer an denselben Server weitergeleitet wird. Durch die Hashfunktion erfolgt die Verteilung der Verbindungen auf die Server relativ zufällig.
Azure stellt drei verschiedene Arten von Integritätsprüfungen bereit: Überprüfung des Gast-Agents (auf virtuellen PaaS-Computern), benutzerdefinierte HTTP-Überprüfung und benutzerdefinierte TCP-Überprüfung. Bei allen drei Möglichkeiten erfolgt die Integritätsprüfung der Ressourcenknoten über einen Ping-Echomechanismus.
Weitere gängige Strategien
Es gibt noch weitere Möglichkeiten, die Last gleichmäßig auf mehrere Ressourcen zu verteilen. Diese unterscheiden sich in den Metriken zur Bestimmung des geeignetsten Ressourcenknotens für eine bestimmte Anforderung:
- Ausführungszeit der Anforderung: Bei diesen Strategien wird ein Algorithmus zur Prioritätsplanung verwendet, der anhand der Ausführungszeiten der Anforderungen die geeignetste Reihenfolge bei der Lastenverteilung vornimmt. Das schwierigste dabei ist die möglichst genaue Vorhersage der Ausführungszeit einer bestimmten Anforderung.
- Ressourcenauslastung: Bei diesen Strategien wird die Last mithilfe der CPU-Auslastung auf den einzelnen Ressourcenknoten gleichmäßig zwischen den Knoten verteilt. Load Balancer leiten Anforderungen anhand einer nach der jeweiligen Auslastung sortierten Ressourcenliste an den Knoten mit der geringsten Auslastung weiter.
Weitere Vorteile
Ein zentralisierter Load Balancer bietet sich für verschiedene Strategien zur Leistungsoptimierung eines Diensts an. Beachten Sie jedoch, dass diese Strategien nur funktionieren, solange der Load Balancer nicht überlastet ist. Sonst wird der Load Balancer selbst zum Engpass. Zu den verfügbaren Strategien zählen folgende:
- SSL-Auslagerung: Netzwerktransaktionen über SSL (Secure Sockets Layer) sind mit zusätzlichen Kosten verbunden, da sie für die Verschlüsselung und Authentifizierung zusätzliche Verarbeitungsprozesse benötigen. Anstatt alle Anforderungen über SSL zu verarbeiten, wird SSL nur für die Verbindung zwischen Client und Load Balancer verwendet, während Umleitungsanforderungen an die einzelnen Server über eine HTTP-Verbindung gesendet werden. Dadurch kann die Serverlast deutlich verringert werden. Die Sicherheit bleibt zudem erhalten, solange Umleitungsanforderungen nicht über ein offenes Netzwerk ausgeführt werden.
- TCP-Pufferung: Bei dieser Strategie werden Clients mit einer langsamen Verbindung in den Load Balancer ausgelagert, um die Server zu entlasten, die Antworten an diese Clients senden.
- Zwischenspeicherung: In bestimmten Szenarios kann der Load Balancer einen Cache für die häufigsten Anforderungen beibehalten (oder für Anforderungen, die ohne Kommunikation mit den Servern verarbeitet werden können, wie statische Inhalte), um die Serverlast zu verringern.
- Strukturierung des Datenverkehrs: Bei einigen Anwendungen kann mit einem Load Balancer der Fluss der Pakete so verzögert bzw. neu priorisiert werden, dass der Datenverkehr an die Serverkonfiguration angepasst werden kann. Dies wirkt sich zwar auf die Dienstqualität einiger Anforderungen aus, stellt jedoch sicher, dass die eingehende Last verarbeitet werden kann.
Literatur
- Aron, Mohit and Sanders, Darren and Druschel, Peter and Zwaenepoel, Willy (2000). Scalable content-aware request distribution in cluster-based network servers (Skalierbare inhaltsabhängige Anforderungsverteilung auf clusterbasierten Netzwerkservern) aus „Proceedings of the 2000 Annual USENIX technical Conference“