Mein Interesse an der Suche nach dem perfekten Load Balancer wurde geweckt, als wir bei der Arbeit eine Reihe von Vorfällen hatten, bei denen ein Dienst mit einer Datenbank kommunizierte, die sich unregelmäßig verhielt. Obwohl wir uns zunächst darauf konzentrierten, die Datenbank stabiler zu machen, war mir klar, dass die Auswirkungen auf den Dienst erheblich geringer hätten sein können, wenn wir in der Lage gewesen wären, die Lastverteilung zwischen den verschiedenen Leseendpunkten der Datenbank effektiver zu gestalten.

Je mehr ich mich mit dem Stand der Technik beschäftigte, desto überraschter war ich, dass dieses Problem noch lange nicht gelöst ist. Es gibt eine Vielzahl von Load Balancern, aber viele verwenden Algorithmen, die nur für eine oder zwei Ausfallarten funktionieren - und bei diesen Vorfällen hatten wir eine Vielzahl von Ausfallarten gesehen.

In diesem Beitrag beschreibe ich, was ich über den aktuellen Stand des Lastausgleichs für Hochverfügbarkeit gelernt habe, wie ich die problematische Dynamik der gängigsten Tools einschätze und wie es meiner Meinung nach weitergehen sollte.

(Haftungsausschluss: Dies beruht in erster Linie auf Gedankenexperimenten und zufälligen Beobachtungen, und ich hatte nicht viel Glück, einschlägige wissenschaftliche Literatur zu finden. Kritiken sind sehr willkommen!)

TL;DR

Was ich Ihnen mit auf den Weg geben möchte:

• Der Zustand des Servers kann nur im Zusammenhang mit dem Zustand des Clusters verstanden werden
• Load Balancer, die aktive Gesundheitsprüfungen verwenden, um Server aus dem Verkehr zu ziehen, können unnötig Verkehr verlieren, wenn die Gesundheitsprüfungen nicht repräsentativ für den tatsächlichen Zustand des Verkehrs sind.
• Durch die passive Überwachung des tatsächlichen Datenverkehrs können Latenz- und Ausfallratenmetriken an einer gerechten Lastverteilung beteiligt werden.
• Wenn kleine Unterschiede im Zustand der Server zu großen Unterschieden im Lastausgleich führen, kann das System wild und unvorhersehbar schwanken
• Zufälligkeit kann Mobbing und andere unerwünschte korrelierte Verhaltensweisen unterbinden

GRUNDLAGEN

Eine kurze Anmerkung zur Terminologie: In diesem Beitrag beziehe ich mich auf Clients, die mit Servern sprechen, ohne Verweise auf "Verbindungen", "Knoten" usw. Zwar kann ein bestimmtes Softwareprodukt sowohl als Client als auch als Server fungieren, sogar zur gleichen Zeit oder im gleichen Anforderungsfluss, doch in dem von mir beschriebenen Szenario sind die Anwendungsserver Clients der Datenbankserver, und ich werde mich auf diese Client-Server-Beziehung konzentrieren.

Im allgemeinen Fall haben wir also N Clients, die mit M Servern sprechen:

Ich werde auch die Spezifika der Anfragen ignorieren. Der Einfachheit halber werde ich sagen, dass die Anfrage des Kunden nicht optional ist und dass ein Fallback nicht möglich ist; wenn der Anruf fehlschlägt, erfährt der Kunde eine Verschlechterung des Dienstes.

Die große Frage ist also: Wenn ein Client eine Anfrage erhält, wie soll er einen Server auswählen, den er anrufen soll?

(Bitte beachten Sie, dass ich mich auf Anfragen beziehe und nicht auf langlebige Verbindungen, die gleichmäßige Datenströme, Verkehrsstöße oder Anfragen in unterschiedlichen Abständen übertragen können. Außerdem sollte es für die allgemeinen Schlussfolgerungen keine Rolle spielen, ob pro Anfrage eine Verbindung hergestellt wird oder ob Verbindungen wiederverwendet werden).

SIDEBAR: CLIENT-SEITE VS. DEDICATED

Sie fragen sich vielleicht, warum ich jeden Client mit jedem Server kommunizieren lasse, was gemeinhin als "clientseitiger Lastausgleich" bezeichnet wird (obwohl in der Terminologie dieses Beitrags der Lastausgleicher auch als Client bezeichnet wird). Warum sollen die Clients diese Arbeit machen? Es ist durchaus üblich, alle Server hinter einen dedizierten Load Balancer zu stellen.

Der Haken an der Sache ist, dass Sie mit nur einem dedizierten Load-Balancer-Knoten einen Single-Point-of-Failure haben. Aus diesem Grund ist es üblich, mindestens drei solcher Knoten einzurichten. Aber beachten Sie, dass die Clients nun wählen müssen, mit welchem Load Balancer sie sprechen wollen... und jeder Load Balancer-Knoten muss immer noch wählen, an welchen Server er jede Anfrage sendet! Dadurch wird das Problem nicht einmal verlagert, sondern nur verdoppelt. ("Jetzt haben Sie zwei Probleme.")

Ich will damit nicht sagen, dass dedizierte Load Balancer schlecht sind. Das Problem, mit welchem Load Balancer man sprechen soll, wird üblicherweise mit DNS-Lastverteilung gelöst, was in der Regel in Ordnung ist, und es spricht viel dafür, einen zentraleren Punkt für Routing, Protokollierung, Metriken usw. zu verwenden. Aber sie erlauben es nicht wirklich, das Problem zu umgehen, da sie immer noch bestimmten Fehlermodi zum Opfer fallen können, und sie sind im Allgemeinen weniger flexibel als der clientseitige Lastausgleich.

WERTEN

Worauf legen wir also Wert bei einem Load Balancer? Wofür optimieren wir?

In einer bestimmten Reihenfolge, je nach unseren Bedürfnissen:

• Verringerung der Auswirkungen von Server- oder Netzwerkausfällen auf die Gesamtverfügbarkeit unserer Dienste
• Geringe Service-Latenzzeiten
• Gleichmäßige Verteilung der Last auf die Server
  • Belasten Sie einen Server nicht übermäßig, wenn die anderen freie Kapazitäten haben.
  • Vorhersagbarkeit: Leichter zu erkennen, wie viel Spielraum der Dienst hat
• Last verteilen ungleichmäßig wenn die Server unterschiedliche Kapazitäten haben, die zeitlich oder nach Server variieren können (gerechte Verteilung statt Gleichverteilung)
  • Ein plötzlicher Spitzenwert oder eine große Menge an Datenverkehr direkt nach dem Start des Servers gibt dem Server möglicherweise keine Zeit zum Aufwärmen. Ein allmählicher Anstieg des Verkehrsaufkommens auf das gleiche Niveau ist möglicherweise genau richtig.
  • CPU-Belastungen, die keine Dienste betreffen, wie z. B. die Installation von Updates, können die auf einem einzelnen Server verfügbare CPU-Menge verringern.

NAIVE LÖSUNGEN

Bevor wir versuchen, alle Probleme zu lösen, sollten wir uns einige einfache Lösungen ansehen. Wie verteilen Sie die Anfragen gleichmäßig, wenn alles in Ordnung ist?

• Ringversuch
  • Client durchläuft Server
  • Garantiert gleichmäßige Verteilung
• Zufällige Auswahl
  • Statistische Annäherung an eine gleichmäßige Verteilung, ohne Verfolgung des Zustands (Koordinierung/CPU-Kompromiss)
• Statische Auswahl
  • Jeder Kunde wählt nur einen Server für alle Anfragen
  • Dies wird durch den DNS-Lastausgleich erreicht: Die Kunden lösen den Domänennamen des Dienstes in eine oder mehrere Adressen auf, und der Netzwerk-Stack des Kunden wählt eine aus und speichert sie im Cache. Auf diese Weise wird der eingehende Datenverkehr bei den meisten dedizierten Load Balancern ausgeglichen; ihre Kunden müssen nicht wissen, dass es mehrere Server gibt.
  • Ähnlich wie beim Zufallsprinzip, funktioniert gut, wenn 1) die DNS-TTLs eingehalten werden und 2) es deutlich mehr Clients als Server gibt (mit ähnlichen Anforderungsraten)

Und was passiert, wenn einer der Server in einer solchen Konfiguration ausfällt? Wenn es 3 Server gibt, schlägt 1 von 3 Anfragen fehl. Eine Erfolgsquote von 67 % ist ziemlich schlecht (nicht einmal eine einzige "Neun"!) Die bestmögliche Erfolgsquote in diesem Szenario liegt bei 100 %, wenn man von einem perfekten Load Balancer und ausreichender Kapazität auf den beiden übrigen Servern ausgeht. Wie können wir das erreichen?

GESUNDHEIT DEFINIEREN

Die übliche Lösung sind Gesundheitsprüfungen. Healthchecks ermöglichen es einem Load Balancer, bestimmte Server- oder Netzwerkausfälle zu erkennen und zu vermeiden, dass Anfragen an Server gesendet werden, die die Prüfung nicht bestehen.

Im Allgemeinen möchten wir wissen, wie "gesund" die einzelnen Server sind, was auch immer das heißen mag, denn es kann einen Vorhersagewert für die Beantwortung der Kernfrage haben: "Wird dieser Server wahrscheinlich eine schlechte Antwort geben, wenn ich ihm diese Anfrage sende?" Es gibt auch noch eine übergeordnete Frage: "Wird dieser Server wahrscheinlich ungesund werden, wenn ich ihm mehr Datenverkehr schicke?" (Oder wird er wieder gesund, wenn ich ihm weniger schicke.) Mit anderen Worten: Einige Fälle von Ungesundheit können von der Last abhängen, während andere lastunabhängig sind; die Kenntnis des Unterschieds ist wichtig für die Vorhersage, wie der Verkehr weitergeleitet werden soll, wenn Ungesundheit beobachtet wird.

Im Großen und Ganzen ist "Gesundheit" also eine Methode zur Modellierung des äußeren Zustands im Dienste der Vorhersage. Aber was gilt als ungesund? Und wie messen wir es?

AUSWAHL EINES AUSSICHTSPUNKTS

Bevor wir ins Detail gehen, ist es wichtig zu erwähnen, dass es zwei sehr unterschiedliche Sichtweisen gibt, die wir verwenden können:

• Die intrinsische Gesundheit des Servers: Ob die Serveranwendung läuft, ob sie reagiert, ob sie in der Lage ist, mit allen ihren eigenen Abhängigkeiten zu kommunizieren, und ob sie nicht unter schwerwiegenden Ressourcenproblemen leidet.
• Der vom Client beobachtete Zustand des Servers: Der Zustand des Servers, aber auch der Zustand des Hosts des Servers, der Zustand des dazwischenliegenden Netzes und sogar die Frage, ob der Client mit einer gültigen Adresse für den Server konfiguriert ist.

Aus praktischer Sicht ist der eigentliche Zustand des Servers unwichtig, wenn der Client ihn nicht einmal erreichen kann. Daher werden wir uns hauptsächlich mit dem Zustand des Servers befassen, der vom Client aus beobachtet wird. Allerdings gibt es hier einige Feinheiten: Wenn die Anforderungsrate an den Server steigt, ist wahrscheinlich die Serveranwendung der Engpass, nicht das Netzwerk oder der Host. Wenn sich die Latenzzeit oder die Ausfallrate des Servers erhöht, könnte dies bedeuten, dass der Server unter der Last der Anfragen leidet, was bedeutet, dass sich sein Zustand durch zusätzliche Anfragen verschlechtern könnte. Es kann aber auch sein, dass der Server über genügend Kapazität verfügt und der Client nur ein vorübergehendes, lastunabhängiges Netzwerkproblem beobachtet, das vielleicht auf ein nicht optimales Routing zurückzuführen ist. In diesem Fall ist es unwahrscheinlich, dass zusätzlicher Datenverkehr etwas an der Situation ändert. Da es im allgemeinen Fall schwierig sein kann, zwischen diesen Fällen zu unterscheiden, werden wir im allgemeinen die Beobachtungen des Kunden als Gesundheitsstandard verwenden.

WAS IST DAS MASS DER GESUNDHEIT?

Was kann ein Client also über den Zustand eines Servers aus seinen Anrufen erfahren?

• Latenzzeit: Wie lange dauert es, bis eine Antwort zurückkommt? Dies kann weiter aufgeschlüsselt werden: Verbindungsaufbauzeit, Zeit bis zum ersten Byte der Antwort, Zeit bis zur vollständigen Antwort; Minimum, Durchschnitt, Maximum, verschiedene Perzentile. Beachten Sie, dass hier die Netzbedingungen und die Serverlast - lastunabhängige bzw. lastabhängige Quellen - zusammengeführt werden (in den meisten Fällen).
• Misserfolgsquote: Welcher Anteil der Anfragen endet mit einem Fehlschlag? (Mehr dazu, was Misserfolg bedeutet, in Kürze.)
• Gleichzeitigkeit: Wie viele Anfragen sind derzeit im Umlauf? Hier werden die Auswirkungen des Server- und des Client-Verhaltens zusammengefasst: Es können mehr Anfragen an einen Server laufen, entweder weil der Server überlastet ist oder weil der Client beschlossen hat, ihm aus irgendeinem Grund einen größeren Teil der Anfragen zu überlassen.
• Größe der Warteschlange: Wenn der Client eine Warteschlange pro Server und nicht eine einheitliche Warteschlange unterhält, kann eine längere Warteschlange entweder auf einen schlechten Zustand oder (wiederum) auf eine ungleiche Belastung durch den Client hinweisen.

Anhand der Größe der Warteschlange und der Anzahl der gleichzeitigen Anfragen sehen wir, dass nicht alle Messungen den Zustand an sich betreffen, sondern auch auf die Auslastung hinweisen können. Sie sind nicht direkt vergleichbar, aber die Kunden wollen vermutlich mehr Anfragen an gesündere und weniger ausgelastete Server weiterleiten, so dass diese Messgrößen neben eher intrinsischen Werten wie Latenz und Ausfallrate verwendet werden können.

Dies sind alles Messungen, die aus der Sicht des Kunden vorgenommen werden. Es ist auch möglich, dass der Server die Auslastung selbst meldet, aber das wird in diesem Beitrag nicht behandelt.

Alle diese Werte können auch über verschiedene Zeitintervalle hinweg gemessen werden: Jüngster Wert, gleitendes Fenster (oder gleitender Bereich), abnehmender Durchschnitt oder mehrere dieser Möglichkeiten in Kombination.

SCHEITERN DEFINIEREN

Von diesen Zustandsindikatoren ist die Fehlerquote vielleicht von größter Bedeutung: In den meisten Anwendungsfällen würde ein Aufrufer lieber einen langsamen Erfolg als einen Fehler irgendeiner Art erhalten. Es gibt jedoch verschiedene Arten von Fehlern, und sie können unterschiedliche Aussagen über den Zustand des Servers machen.

Wenn ein Anruf in die Länge gezogen wird, kann es zu Netzwerk- oder Routing-Problemen kommen, die eine hohe Latenzzeit verursachen, oder der Server ist stark belastet. Wenn der Anruf jedoch schnell abbricht, hat das ganz andere Auswirkungen: DNS-Fehlkonfiguration, defekter Server, schlechte Route. Ein schneller Ausfall ist weniger wahrscheinlich von der Last abhängig, es sei denn, der Server nutzt eine Lastabschaltung, um bei hoher Last absichtlich schnell auszufallen - in diesem Fall ist es möglich, dass er durch weitere Last nicht weiter belastet wird.

Wenn Sie Fehler auf der Anwendungsebene und nicht nur auf der Transportebene betrachten, ist es wichtig, die Kriterien für die Kennzeichnung eines Aufrufs als fehlgeschlagen sorgfältig zu wählen. So ist beispielsweise ein HTTP-Aufruf, der nicht zurückkehrt (aufgrund einer Zeitüberschreitung usw.), eindeutig ein Fehler, aber eine wohlgeformte Antwort mit einem Fehlerstatuscode (4xx oder 5xx) weist möglicherweise nicht auf ein Serverproblem hin. Eine einzelne Anfrage kann einen datenabhängigen 500 Server Error auslösen, der nicht repräsentativ für den allgemeinen Zustand des Servers ist. Eine Häufung von 404- oder 403-Antworten aufgrund eines Anrufers mit schlecht formulierten Anfragen ist üblich, aber nur dieser Anrufer ist betroffen; den Server nur auf dieser Basis als ungesund zu beurteilen, wäre unklug. Andererseits ist es etwas unwahrscheinlicher, dass eine Lesezeitüberschreitung auf eine fehlerhafte Anfrage zurückzuführen ist.

WAS IST MIT GESUNDHEITSCHECKS?

Bisher haben wir vor allem über Möglichkeiten gesprochen, wie ein Client passiv Informationen über den Zustand des Servers aus bereits gestellten Anfragen gewinnen kann. Ein anderer Ansatz ist die Verwendung aktiver Gesundheitsprüfungen.

Die Elastic Load Balancer (ELB) Healthchecks von AWS sind ein Beispiel dafür. Sie können den Load Balancer so konfigurieren, dass er alle 30 Sekunden einen HTTP-Endpunkt auf jedem Server aufruft. Wenn der ELB zwei Mal hintereinander eine 5xx-Antwort oder eine Zeitüberschreitung erhält, wird der Server für normale Anfragen nicht mehr berücksichtigt. Wenn der Server jedoch 10 Mal in Folge normal antwortet, wird er wieder in die Rotation aufgenommen.

Dies ist ein Beispiel für den Einsatz von Hysterese, um sicherzustellen, dass der Host nicht zu schnell ein- und ausgeschaltet wird. (Ein bekanntes Beispiel für Hysterese ist die Art und Weise, wie der Thermostat einer Klimaanlage ein "Toleranzfenster" um die gewünschte Temperatur herum aufrechterhält.) Dies ist ein gängiger Ansatz, der in Szenarien, in denen ein Server entweder völlig gesund oder ungesund ist und seinen Zustand nicht häufig ändert, recht gut funktionieren kann. In der weniger häufigen Situation anhaltender, niedriger Ausfallraten von weniger als 40 %, die sich sowohl auf die Gesundheitsprüfung als auch auf den normalen Datenverkehr auswirken, würde ein ELB in der Standardkonfiguration nicht häufig genug aufeinanderfolgende Ausfälle feststellen, um den Host außer Betrieb zu setzen.

Healthchecks müssen sorgfältig konzipiert werden, damit sie nicht die falschen Auswirkungen auf den Load Balancer haben. Im Folgenden sind einige der Arten von Antworten aufgeführt, die ein Healthcheck-Aufruf liefern könnte:

• Smoke-Test: Tätigen Sie einen realistischen Anruf und prüfen Sie, ob die erwartete Antwort zurückkommt.
• Prüfung der funktionalen Abhängigkeiten: Der Server ruft alle seine Abhängigkeiten auf und gibt einen Fehler zurück, wenn eine von ihnen fehlschlägt.
• Verfügbarkeit prüfen: Prüfen Sie einfach, ob der Server auf jede Aufruf, z.B. GET /ping ergibt 200 OK und einen Antwortkörper von pong

Es ist wichtig, dass der Gesundheitscheck so repräsentativ wie möglich für den tatsächlichen Datenverkehr ist. Andernfalls kann es zu inakzeptablen falsch-positiven oder falsch-negativen Ergebnissen kommen. Wenn der Server beispielsweise eine Reihe von API-Routen hat und nur eine dieser Routen aufgrund einer fehlgeschlagenen Abhängigkeit defekt ist, ist dieser Server dann gesund? Wenn Ihr Smoke-Test nur auf diese Route zutrifft, wird Ihr Client den Server als völlig defekt ansehen; ist diese Route jedoch die einzige, die funktioniert, kann Ihr Client den Server als völlig gesund ansehen.

Funktionsprüfungen können umfassender sein, aber das ist nicht unbedingt besser, da dies leicht dazu führen kann, dass ein Server (oder alle Server!) als ausgefallen markiert wird, wenn auch nur eine einzige, optionale Abhängigkeit ausgefallen ist. Das ist nützlich für die Betriebsüberwachung, aber gefährlich für den Lastausgleich; daher konfigurieren viele Leute nur einfache Verfügbarkeitsprüfungen.

Aktive Zustandsüberprüfungen liefern im Allgemeinen eine binäre Ansicht des Zustands eines Servers, selbst wenn sie über einen längeren Zeitraum verfolgt werden, da sich ein Server in einem degradierten Zustand befinden kann, in dem er durchweg einige Anfragen beantworten kann, andere jedoch nicht. Die passive Überwachung des Zustands des Datenverkehrs bietet dagegen eine skalare (oder sogar nuanciertere) Ansicht des Zustands, da der Client zumindest weiß, bei welchem Anteil der Anfragen Fehler auftreten - und, was besonders wichtig ist, diese passive Überwachung bietet eine umfassende Ansicht des Zustands des Datenverkehrs. (Beide Arten der Überprüfung können natürlich Latenzinformationen verfolgen; einige dieser Unterscheidungen gelten nur für die Fehlerratenmetrik).

BINÄRE GESUNDHEITSPRÜFUNGEN UND ERKENNUNG VON ANOMALIEN

Diese binäre Sichtweise kann zu ernsthaften Problemen führen, da sie keinen Vergleich des Gesundheitszustands zwischen den Servern zulässt. Sie werden einfach als "hoch" oder "niedrig" gruppiert, basierend auf einem einzigen Aufruftyp, der möglicherweise nicht repräsentativ ist. Selbst wenn Sie mehrere Aufrufe zur Zustandsüberprüfung haben, gibt es keine Garantie, dass diese für den Zustand Ihres Servers repräsentativ bleiben, wenn seine API erweitert wird und sich die Anforderungen der Kunden ändern. Noch schlimmer ist jedoch, dass korrelierte Ausfälle zu einem unnötigen Kaskadenausfall führen können. Betrachten Sie diese Szenarien:

• Wenn 100 % Ihrer Hosts aktive Healthchecks bestanden haben, sollte ein idealer Load Balancer zu allen Hosts routen.
• Wenn 90 % erfolgreich sind, sollten Sie nur diese 90 % weiterleiten - es spielt keine Rolle , warum die 10 % nicht funktionieren, da der Rest des Clusters die Last zweifellos bewältigen kann.
• Wenn nur 10 % die Prüfungen bestehen... leiten Sie zu allen Hostsweiter - es ist besser, darauf zu setzen, dass die Gesundheitsprüfung falsch (oder irrelevant) ist, als die 10 % zu vernichten, die die Prüfungen bestehen.
• Wenn 0 % durchkommen, leiten Sie an alle Hosts weiter - 100 % der Anfragen, die Sie nicht weiterleiten, schlagen fehl, wie man sagt.

Je näher der Anteil der Hosts, die die Prüfung bestehen, gegen Null geht, desto wahrscheinlicher ist es, dass ein Fehler außerhalb der Hosts oder sogar ein Fehler in der Gesundheitsprüfung vorliegt. Stellen Sie sich vor, dass Ihr Healthcheck von einem Testkonto abhängt und das Testkonto gelöscht wird. Oder vielleicht fällt eine Abhängigkeit aus, aber die meisten Anfragen können noch bedient werden. Trotzdem schlagen alle Healthchecks fehl; die ELB nimmt jeden einzelnen Ihrer Hosts außer Betrieb, obwohl die eingehenden Anfragen einwandfrei bedient wurden.

Daraus wird ersichtlich, dass Gesundheit relativ ist: Ein Server kann gesünder sein als seine Nachbarn, auch wenn alle von ihnen ein Problem haben. Und es ist einfacher, das zu erkennen, wenn man Skalare statt Boolesche Werte verwendet.

Im Grunde möchten Sie, dass Ihr Load Balancer eine Art einfache Anomalieerkennung durchführt. Wenn sich nur ein kleiner Teil Ihrer Server seltsam verhält, schließen Sie diese einfach aus und senden eine Warnung an Ops. Wenn sich die meisten oder alle merkwürdig verhalten? Machen Sie die Sache nicht noch schlimmer, indem Sie die gesamte Last auf eine kleine Handvoll von Servern - oder noch schlimmer, auf keinen von ihnen - verteilen.

Der Schlüssel liegt hier darin, den Zustand der Server im Hinblick auf den gesamten Cluster zu bewerten und nicht atomar. Das, was dem bisher am nächsten kommt, ist der Load Balancer von Envoy, der einen "Panic Threshold" hat, der standardmäßig alle Hosts in Betrieb hält, wenn 50% oder mehr von ihnen fehlerhafte Healthchecks haben. Wenn Sie Healthchecks in Ihrem Load Balancer verwenden, sollten Sie einen solchen Ansatz in Betracht ziehen.

Sie werden feststellen, dass ich die Frage übersprungen habe, was zu tun ist, wenn 30-70 % der Server die Prüfungen nicht bestehen. Diese Situation kann auf ein echtes Versagen hindeuten und kann entweder lastabhängig oder lastunabhängig sein. Ich bin mir nicht sicher, ob es für einen Load Balancer möglich ist, herauszufinden, welche Situation zutrifft, selbst wenn er bereit ist, clevere A/B-Verkehrsbelastungsexperimente durchzuführen, um dies herauszufinden. Schlimmer noch, wenn die gesamte Last auf eine relativ kleine Anzahl von Servern verteilt wird, können diese Server ausfallen. Abgesehen von der Lastverteilung kann in dieser Situation nicht viel getan werden, und ich bin mir nicht sicher, ob ich ein Design bemängeln könnte, das diese Server in Betrieb hält, oder eines, das sie ausschaltet, wenn sie sich in diesem mittleren Bereich befinden - denn ich war einer der Menschen, die während eines solchen Produktionsvorfalls in die Schleife eingeweiht waren, und es war uns zu diesem Zeitpunkt auch nicht klar.

SIDEBAR: HUNGERFALLE

Ein weiterer Unterschied zwischen diesen aktiven und passiven Ansätzen besteht darin, dass bei der aktiven Überprüfung die Informationen über den Zustand des Servers unabhängig vom Datenverkehr in gleichmäßigen Abständen aktualisiert werden. Dies kann ein Vorteil sein, wenn der Datenverkehr langsam ist, oder ein Nachteil, wenn er hoch ist. (Fünf Sekunden Ausfallzeit können eine lange Zeit sein, wenn Sie 10.000 Anfragen pro Sekunde haben.) Bei der passiven Prüfung hingegen ist die Geschwindigkeit der Fehlererkennung proportional zur Anforderungsrate.

Aber es gibt einen großen Nachteil bei der rein passiven Zustandsüberprüfung. Wenn ein Server ausfällt, wird der Load Balancer ihn schnell aus dem Dienst nehmen. Das bedeutet, dass kein Datenverkehr mehr stattfindet, und kein weiterer Datenverkehr bedeutet, dass sich die Ansicht des Clients über den Zustand des Servers nie ändert: Er bleibt für immer bei Null.

Es gibt natürlich Möglichkeiten, damit umzugehen, von denen einige auch andere Randfälle ohne Daten betreffen, wie das Starten des Clients oder das Ersetzen eines einzelnen Servers in der Serverliste des Clients. Alle diese Fälle müssen bei der passiven Prüfung besonders berücksichtigt werden.

GESUNDHEITSZUSAMMENFASSUNG

Zusammenfassend lässt sich sagen, dass

• Die passive Überwachung des Verkehrs gibt zwangsläufig einen umfassenderen und differenzierteren Überblick über den Gesundheitszustand als aktive Kontrollen.
• Es gibt mehrere Achsen, anhand derer die Gesundheit bewertet werden kann
• Der Zustand eines Servers kann nur im Verhältnis zum Cluster verstanden werden

Aber was machen wir mit diesen Informationen? Wie können all diese realen Zahlen kombiniert werden, um unsere Ziele - geringere Latenzzeiten, minimale Ausfälle und gleichmäßig verteilte Last - zu erreichen?

Ich möchte zunächst einen Exkurs zu einer Familie von Fehlermodi machen, dann einige gängige Ansätze für einen gesundheitsbewussten Lastausgleich erörtern und schließlich einige mögliche zukünftige Richtungen aufzeigen.

SIDEBAR: DIE SUBTILEN GEFAHREN DER KORRELATION

Unkoordiniertes Handeln kann überraschende Folgen haben. Stellen Sie sich vor, ein großes Unternehmen verschickt eine E-Mail an seine Mitarbeiter: "Wir bieten heute Massagen für alle Mitarbeiter im Hörsaal 2 an! Kommen Sie vorbei, wann immer Sie wollen." Was glauben Sie, wann die Leute kommen werden? Ich vermute, dass es zu einigen wenigen Tageszeiten einen großen Andrang geben wird:

• Sofort
• Nach dem Mittagessen
• Später Nachmittag vor der Heimreise

Bei dieser ungleichmäßigen Verteilung haben die Masseure manchmal niemanden, den sie bearbeiten können; manchmal sind die Schlangen so lang, dass die Leute aufgeben und es vielleicht später nicht einmal mehr versuchen. Beides ist nicht wünschenswert. Ohne jegliche Koordination - denn es gibt keine Koordination - tauchen die Leute irgendwie trotzdem in Gruppen auf! Das zufällige korrelierte Verhalten in diesem Szenario lässt sich mit einem alltäglichen Hilfsmittel leicht verhindern: Der Anmeldebogen. (In der Softwarebranche wäre das nächstliegende Analogon ein Stapelverarbeitungssystem, das Aufträge annimmt, sie nach eigenem Gutdünken plant und die Ergebnisse asynchron zurückgibt).

Es hat sich herausgestellt, dass es beim API-Verkehr eine Reihe ähnlicher Phänomene gibt, die oft unter dem Namen " Thundering Herd"-Problem zusammengefasst werden. Ein klassisches Beispiel ist ein Cache-Dienst, der von Hunderten von Anwendungsknoten konsultiert wird. Wenn der Cache-Eintrag abläuft, muss die Anwendung den Wert mit frischen Daten neu erstellen, was sowohl zusätzliche Arbeit als auch (wahrscheinlich) zusätzliche Netzwerkanrufe bei anderen Servern erfordert. Wenn Hunderte von Anwendungsknoten gleichzeitig feststellen, dass ein beliebter Cache-Eintrag abläuft (weil sie alle ständig Anfragen für diese Daten erhalten), dann werden sie alle gleichzeitig versuchen, ihn neu zu erstellen, und gleichzeitig die Backend-Dienste aufrufen, die für die Erzeugung neuer Daten zuständig sind. Dies ist nicht nur verschwenderisch (im besten Fall sollte nur ein einziger App-Knoten diese Aufgabe durchführen, und zwar einmal pro Cache-Lebensdauer), sondern könnte sogar die Backend-Server überlasten, die normalerweise hinter dem Cache geschützt sind.

Die klassische Lösung für das Herdenproblem beim Ablauf des Cache besteht darin, den Cache-Eintrag pro Aufruf mit einer gewissen Wahrscheinlichkeit vorzeitig ablaufen zu lassen, anstatt ihn überall zum gleichen Zeitpunkt ablaufen zu lassen. Der einfachste Ansatz ist das Hinzufügen eines Jitters, einer kleinen Zufallszahl, die vom Verfallsdatum abgezogen wird, sobald der Client den Cache aufruft. Eine Verfeinerung dieser Technik, XFetch, verzögert die Aktualisierung auf den letztmöglichen Zeitpunkt.

Ein weiteres bekanntes Problem tritt auf, wenn eine große Anzahl von Nutzern eines Dienstes eine regelmäßige Aufgabe zum Aufrufen einer API einrichtet. Vielleicht installiert jeder Nutzer eines Sicherungsdienstes einen Cron-Job, um um Mitternacht ein Backup hochzuladen (entweder in seiner lokalen Zeitzone oder, was wahrscheinlicher ist, in UTC). Der Sicherungsserver wird dann um Mitternacht UTC überlastet und ist tagsüber weitgehend ungenutzt.

Auch hierfür gibt es eine Standardlösung: Erzeugen Sie bei der Einführung eines neuen Benutzers eine vorgeschlagene crontab-Datei, die er zu einem zufällig gewählten Zeitpunkt installieren kann. Dies kann sogar ohne eine zentrale Koordinierungsstelle funktionieren, wenn die Sicherungssoftware die crontab-Datei selbst schreibt und bei der Erstinstallation einen zufälligen Zeitpunkt wählt. (Vielleicht fällt Ihnen auf, dass ein ähnlicher Ansatz auch für das Massageszenario funktionieren könnte, wenn aus irgendeinem Grund keine zentrale Anmeldeliste verwendet werden kann: Jeder Mitarbeiter wählt nach dem Zufallsprinzip eine Tageszeit aus, zu der er frei ist, und geht zu dieser Zeit hin, auch wenn es nicht unbedingt die optimale Zeit für seinen eigenen Zeitplan ist).

Diese beiden Lösungen - zeitlich gestaffeltes Auslaufen und randomisierte Planung - nutzen beide den Zufall als Mittel gegen unkoordiniertes, aber korreliertes Verhalten. Dies ist ein wichtiges Prinzip: Zufall hemmt Korrelation. Wir werden dies bei der Behandlung einiger Herausforderungen im Zusammenhang mit dem Lastenausgleich wieder aufgreifen.

Anhand des Massageszenarios sehen wir auch einen alternativen Ansatz, der sich auf einen zentralen Koordinierungspunkt stützt. Dies ist ein Vorteil der Verwendung eines kleinen Clusters leistungsstarker Server für einen dedizierten Lastausgleich - jeder Server hat einen besseren Überblick über den Verkehrsfluss als jeder einzelne einer größeren Anzahl von Clients. Eine andere Möglichkeit, die Koordination zu verbessern, besteht darin, dass die Server die Auslastung als parasitäre Metadaten in ihren Antworten selbst melden. Dies ist nicht immer möglich, aber die vom Server gemeldete Auslastung liefert den Clients aggregierte Informationen, auf die sie sonst keinen Zugriff hätten. Dies könnte clientseitigen Load Balancern einen umfassenderen Überblick verschaffen, wie ihn ein dedizierter Load Balancer haben könnte. Als Bonus kann es manchmal helfen, zwischen Server- und Netzwerkausfällen zu unterscheiden, was wiederum Auswirkungen auf lastabhängige und lastunabhängige Interpretationen hat.

Mit diesem Aspekt der Systemdynamik im Hinterkopf wollen wir uns nun ansehen, wie Load Balancer Gesundheitsinformationen nutzen.

NUTZUNG DES GESUNDHEITSZUSTANDS BEIM LASTAUSGLEICH

Load Balancer trennen die Nutzung von Gesundheitsinformationen in der Regel in zwei Bereiche:

1. Entscheidung, welche Server für Anfragen in Frage kommen, und dann
2. Entscheidung darüber, welcher Kandidat für jede Anfrage ausgewählt werden soll

Beim klassischen Ansatz werden diese als zwei völlig getrennte Ebenen behandelt. ELB, ALB und NLB von AWS verwenden beispielsweise eine Reihe von Algorithmen zur Lastverteilung (zufällig, Round-Robin, deterministisch zufällig und Least-Outstanding), aber es gibt einen separaten Mechanismus, der weitgehend auf aktiven Gesundheitsprüfungen basiert, um zu bestimmen, welche Server an diesem Auswahlprozess teilnehmen können. (Aus den Unterlagen geht hervor, dass NLBs auch eine passive Überwachung nutzen, um zu entscheiden, ob ein Server aus dem System geworfen wird, aber es gibt kaum Details).

Zufalls-, Round-Robin- und deterministische Zufallsverfahren (wie Flow-Hash) ignorieren den Gesundheitszustand vollständig: Ein Server ist entweder in oder out. Der Least-Outstanding-Algorithmus hingegen verwendet eine passive Gesundheitsmetrik. (Beachten Sie, dass auch dieser Algorithmus für die Serverauswahl völlig getrennt von den aktiven Überprüfungen ist, die für das Herausnehmen von Servern aus dem Cluster verwendet werden). Least-outstanding ("wähle den Server mit der geringsten Gleichzeitigkeit der Anfragen") ist einer von mehreren Ansätzen für die Verwendung passiver Gesundheitsmetriken für die Zuweisung von Anfragen, die jeweils auf der Optimierung einer der oben genannten Metriken basieren: Latenz, Ausfallrate, Gleichzeitigkeit, Größe der Warteschlange.

AUSWAHLALGORITHMEN

Einige Auswahlalgorithmen für den Lastausgleich wählen den Server mit dem besten Wert für eine Metrik. Oberflächlich betrachtet ist dies sinnvoll: So hat die aktuelle Anfrage die beste Chance, schnell zum Erfolg zu kommen. Allerdings kann dies zu dem führen, was ich als Mobbing bezeichne: Wenn die Latenz die bevorzugte Gesundheitsmetrik ist und ein Server eine geringfügig niedrigere Latenz aufweist als die anderen (von allen Clients aus gesehen), dann werden alle Clients ihren gesamten Datenverkehr an diesen einen Server senden - zumindest so lange, bis er unter der Last zu leiden beginnt und möglicherweise sogar ausfällt. Wenn der Server zu leiden beginnt, erhöht sich seine effektive Latenzzeit, und möglicherweise gewinnt ein anderer Server den Titel des weltweit gesündesten. Dieser Vorgang kann sich zyklisch wiederholen und durch nichts anderes als einen sehr geringen Unterschied im anfänglichen Zustand ausgelöst werden.

Mobbingverhalten ist ein Zusammentreffen mehrerer Fehler im System:

• Die Latenz ist eine verzögerte Zustandsmetrik. Würde man stattdessen die Gleichzeitigkeit (Anzahl der Anfragen während des Flugs) verwenden, würden die Kunden nicht mobben, da die Gleichzeitigkeitsmetrik auf der Kundenseite sofort aktualisiert wird, sobald einem Server mehr Anfragen zugewiesen werden. Verzögerte Messungen, selbst mit Dämpfung, können zu unerwünschten Schwingungen oder Resonanzen führen.
• Die Kunden haben keinen Gesamtüberblick über die Situation und handeln daher unkoordiniert, was zu unerwünschtem, korrelierendem Verhalten führt.
• Ein kleiner Unterschied im Zustand der Server führt zu einem großen Unterschied im Lastausgleichsverhalten. Da es Rückkopplungen von letzterem zu ersterem gibt, entspricht dies einer Beschreibung chaotischer Systeme, die sehr empfindlich auf die Anfangsbedingungen reagieren.

Die Abhilfemaßnahmen, wie ich sie sehe:

• Verwenden Sie, wenn möglich, schnelle Zustandsmetriken. Ein sehr verbreiteter Algorithmus zur Lastverteilung besteht darin, alle Anfragen an den Server mit den wenigsten laufenden Anfragen zu senden. (Manchmal wird dies auch als "least-connections" oder "least-outstanding" bezeichnet, je nachdem, ob es sich um eine verbindungs- oder eine anforderungsorientierte Methode handelt - einige Verbindungen sind langlebig und führen während ihrer Lebensdauer viele Anforderungen aus.) Im Gegensatz dazu glaube ich nicht, dass ich einen Pick-Least-Latency-Algorithmus gesehen habe, wahrscheinlich aus genau diesem Grund.
• Versuchen Sie entweder, sich einer globalen Sicht der Situation anzunähern (indem Sie einen dedizierten Load Balancer mit einer kleinen Anzahl von Servern verwenden oder die von den Servern gemeldete Auslastung einbeziehen) oder verwenden Sie Zufälligkeiten, um unerwünschtes korreliertes Verhalten zu verhindern.
• Verwenden Sie Algorithmen, die für annähernd gleiche Eingaben annähernd das gleiche Verhalten aufweisen. Sie müssen kein kontinuierlich veränderliches Verhalten aufweisen, sondern können mit Hilfe von Zufälligkeit eine Annäherung erreichen.

Es gibt eine beliebte Alternative zum Pick-the-Best-Verfahren namens Two-Choice, die in dem Dokument The Power of Two Random Choices beschrieben wird, in dem ein allgemeiner Ansatz für die Ressourcenzuweisung erörtert wird (nicht spezifisch für Load Balancer oder sogar auf diese ausgerichtet, aber sicherlich relevant). Bei diesem Ansatz werden zwei Kandidaten ausgewählt und derjenige mit dem besseren Gesundheitszustand wird verwendet. Dies führt zu einer annähernd gleichmäßigen Verteilung, wenn sich der langfristige Gesundheitszustand aller Server einem identischen Wert annähert, aber selbst ein kleiner dauerhafter Unterschied im Gesundheitszustand kann die Lastverteilung erheblich aus dem Gleichgewicht bringen. Eine vereinfachte Simulation ohne Rückkopplungen veranschaulicht dies:

;; Select the index of one of N servers with health ranging ;; from 1000 to 1000-N, +/-N (defn selecttc [n] (let [spread n ;; top and bottom health ranges overlap by ~half ;; Compute health of a server, by index health (fn [i] (+ (- 1000 i spread) (* 2 spread (rand)))) ;; Randomly choose two servers, without replacement [i1 i2] (take 2 (shuffle (range n)))] ;; Pick the index of the healthier server (if (< (health i1) (health i2)) i2 i1)))

;; Führen Sie 10.000.000 Versuche mit 5 Hosts durch und berichten Sie, wie oft ;; jeder Hostindex ausgewählt wurde (sort-by key (frequencies (repeatedly 10000000 #(selecttc 5)))) ;;= ([0 2849521] [1 2435167] [2 2001078] [3 1566792] [4 1147442])

Unter der Annahme, dass sich die erhöhte Last nicht auf die Gesundheitsmetrik auswirkt, würde dies zu einem 2,5-fachen Unterschied in der Anfragelast zwischen dem gesündesten und dem ungesündesten Host führen, wenn die Hosts auch nur eine ungefähre Rangfolge der Gesundheit haben. Beachten Sie, dass der Gesundheitsbereich von Host 0 bei 995-1005 und der von Host 4 bei 991-1001 liegt. Obwohl die beiden Hosts in absoluten Zahlen nur 1-2 % voneinander entfernt sind, wird diese leichte Abweichung zu einem großen Ungleichgewicht in der Last vergrößert.

Während Two-Choice Mobbing reduziert (und recht gut funktioniert, wenn keine Verzerrung vorliegt, was durchaus der Fall sein kann, wenn Rückkopplungen auftreten), ist es klar, dass dies kein geeigneter Auswahlmechanismus ist, um mit verzögerten Gesundheitsmetriken zu arbeiten. Darüber hinaus scheint sich die Arbeit auf die maximale Lastreduzierung bei einer identischen Anzahl von Optionen zu konzentrieren, was bei gesundheitsbewussten Load Balancern nicht der Fall ist.

Andererseits funktioniert Two-Choice gut mit Least-Outstanding, weil die Rückkopplung sowohl unmittelbar als auch selbstkorrigierend ist. Least-Outstanding ist selbst eine Herausforderung, da es potenziell kleine, quantisierte Werte gibt. Ist ein Server mit einer offenen Verbindung doppelt so gesund wie ein Server mit zwei? Wie sieht es mit Null und Eins aus? Least-Outstanding ist einfacher zu handhaben, wenn es im Verhältnis zur Anfragelast relativ wenige Clients gibt (z. B. in einem dedizierten Load Balancer), was zu einfacheren Vergleichen führt (z. B. 17 vs. 20). Bei kleinen Durchschnittswerten wird die Randomisierung als Tie-Breaker sehr wichtig, damit der erste Server in der Liste nicht standardmäßig immer Anfragen erhält - wenn jeder Client nur eine Verbindung offen hat, es aber 300 Clients gibt, können sie gemeinsam diesen einen Server mobben. Two-Choice mit seiner Randomisierung stellt ein natürliches Gegenmittel gegen Mobbing dar, das aus den kleinen diskreten Werten von Least-Outstanding resultiert.

Eine vielversprechende, wenn auch noch akademische Option ist die gewichtete Zufallsauswahl. Jedem Server wird eine Gewichtung zugewiesen, die sich aus seinen Gesundheitsmetriken ergibt, und ein Server wird entsprechend dieser Gewichtung ausgewählt. Hätten die Server beispielsweise die Gewichtung 7, 3 und 1, würde die Wahrscheinlichkeit, dass sie jedes Mal ausgewählt werden, bei 70 %, 30 % bzw. 10 % liegen. Bei der Verwendung dieses Algorithmus ist Vorsicht geboten, um die Hungerfalle zu vermeiden, und bei der Ableitung der Gewichte muss eine gut gewählte nichtlineare Funktion verwendet werden, damit ein Server, der 90 % der Gesundheit der anderen hat, ein stark reduziertes Gewicht erhält, vielleicht nur 20 % relativ. Bei der Arbeit experimentiere ich mit diesem Ansatz, und nach einigen lokalen Integrationsexperimenten setze ich große Hoffnungen in ihn, aber ich habe ihn noch nicht mit echtem Verkehr getestet. Wenn es sich bewährt, werde ich wahrscheinlich in einem zukünftigen Beitrag über einen neuen Lastausgleichsalgorithmus mehr ins Detail gehen.

KOMBINATION VON GESUNDHEITSMETRIKEN

Ich habe die Frage, wie man mehrere Gesundheitsmetriken verwenden kann, aufgeschoben. Meiner Meinung nach ist dies der schwierigste Teil und trifft den Kern der ganzen Angelegenheit: Wie definieren Sie den Gesundheitszustand für Ihre Anwendung?

Nehmen wir an, Sie verfolgen Latenz, Ausfallrate und Gleichzeitigkeit, denn all das ist für Sie wichtig. Wie kombinieren Sie sie? Ist eine Ausfallrate von 5 % genauso schlimm wie eine 10-fach erhöhte Latenz? (100x?) Ab welchem Punkt würden Sie es lieber mit einem zu 90 % verfügbaren Server versuchen, wenn der andere massive Latenzspitzen aufweist? Zwei allgemeine Strategien kommen mir in den Sinn.

Sie könnten einen abgestuften Ansatz wählen, indem Sie für jede Kennzahl Schwellenwerte für die Akzeptanz festlegen und nur Server mit akzeptablen Ausfallquoten auswählen; wenn es keine gibt, wählen Sie diejenigen mit akzeptablen Latenzzeiten usw. Vielleicht haben Sie auch einen Spillover-Schwellenwert definiert, so dass, wenn der akzeptable Pool zu klein ist, auch die Server der nächstniedrigeren Ebene berücksichtigt werden. (Diese Idee hat eine gewisse Ähnlichkeit mit den Prioritätsstufen von Envoy).

Alternativ können Sie auch kombinierte Metriken verwenden, bei denen die Metriken nach einer kontinuierlichen Funktion kombiniert werden. Vielleicht gewichten Sie einige davon stärker. Ich experimentiere derzeit mit der Ableitung eines [0,1]-Gewichtungsfaktors für jede Gesundheitsmetrik und multipliziere sie miteinander, wobei einige auf höhere Potenzen (quadriert oder kubiert) angehoben werden, um ihnen mehr Gewicht zu verleihen. (Ich vermute, dass sehr große Potenzen verwendet werden könnten, um so etwas wie den abgestuften Ansatz zu implementieren, selbst wenn man einen kombinierten Metrikkombinierer verwendet).

Es lohnt sich auch, darüber nachzudenken, wie diese Metriken zusammenhängen könnten, was auf mögliche Vorteile einer erweiterten Modellierung des Server- und Verbindungszustands hindeutet. Stellen Sie sich einen Server vor, der in einen schlechten Zustand geraten ist und sehr schnell Fehlerantworten ausgibt. Wenn die einzige Gesundheitsmetrik die Latenzzeit ist, sieht dieser Server nun wie der gesündeste im Cluster aus und erhält daher einen größeren Teil des Datenverkehrs. rachelbythebay nennt dies den Load-Balanced Capture-Effekt. Schnell ist nicht immer gesund! Je nach Ihrer Konfiguration kann ein gemischter Ansatz den Datenverkehr zu diesem abtrünnigen Server ausreichend unterdrücken, während ein abgestufter Ansatz, der eine niedrige Ausfallrate priorisiert, ihn vollständig ausschließen würde.

Latenz und Ausfallrate sind im Allgemeinen auf nicht offensichtliche Weise miteinander verknüpft. Neben dem Szenario "schnelle Fehlermeldungen" gibt es auch die Frage der Timeout- und Nicht-Timeout-Fehler. Unter hohen Latenzbedingungen wird der Client eine Reihe von Timeout-Fehlern produzieren. Handelt es sich dabei um "Ausfälle" per se oder nur um Antworten mit übermäßig hoher Latenz? Sollten sie die Latenzmetrik, die Fehlerratenmetrik oder beides beeinflussen? Vergleichen Sie dies mit Fehlern aufgrund fehlerhafter DNS-Einträge und anderen schnellen Verbindungsfehlern. Ich empfehle, nur Latenzzahlen von Erfolgen oder von Fehlern aufzuzeichnen, von denen Sie wissen, dass sie auf eine Zeitüberschreitung hindeuten, wie z. B. SocketTimeoutException und ähnliche in Java. (Ein Kollege schlägt als Alternative vor, nur Latenzwerte für Fehlschläge aufzuzeichnen, wenn sich dadurch der Latenzdurchschnitt verschlechtert.)

LEBENSZYKLUS

Die obigen Ausführungen gehen davon aus, dass der Client mit einer statischen Sammlung von Servern kommuniziert. Server werden jedoch ausgetauscht, entweder einzeln oder in großen Gruppen. Wenn ein neuer Server zum Cluster hinzugefügt wird, sollte der Load Balancer ihn nicht sofort mit dem gesamten Datenverkehr belasten, sondern den Datenverkehr über einen gewissen Zeitraum langsam hochfahren. Diese Aufwärmphase ermöglicht es dem Server, sich vollständig zu optimieren: Erwärmung des Festplatten- und Befehlscaches, Hotspot-Optimierung in Java usw. HAProxy führt zu diesem Zweck einen langsamen Start durch. Über die Aufwärmphase hinaus ist dies auch eine Zeit der Unsicherheit: Der Client hat keine Erfahrung mit dem Server, so dass die Abhängigkeit von ihm das Risiko begrenzen kann.

Wenn Sie einen Ansatz mit einer Kombination von Metriken verwenden, kann es sinnvoll sein, das Serveralter als Pesudo-Gesundheitsmetrik zu verwenden, indem Sie mit einem Wert nahe Null beginnen und im Laufe einer Minute oder so auf den vollen Gesundheitszustand ansteigen. (Bei genau Null anzufangen, kann je nach Algorithmus gefährlich sein; der Client könnte vom vollständigen Austausch einer Reihe von Servern auf einmal erfahren oder so umkonfiguriert werden, dass er auf einen anderen Cluster verweist, und kurzzeitig alle Server als null gesund betrachten). Es ist wahrscheinlich, dass jeder Mechanismus für den Umgang mit dem vollständigen Austausch der Serverliste auch für den Start des Clients ausreicht.

LADUNGSVERSCHIEBUNG

Ich habe das Thema Lastabwurf nur kurz gestreift, bei dem ein Dienst, der mit vielen Anfragen belastet ist, versucht, einige oder alle Anfragen sehr schnell mit Ausfällen zu beantworten, um die CPU-Last und andere Ressourcenkonflikte zu verringern. Manchmal reicht die beste Anstrengung nicht aus, oder man muss den Dienst nur lange genug am Leben erhalten, um ihn zu skalieren. Lastabwurf ist ein Glücksspiel, das auf der Idee beruht, dass die Behebung von Fehlern bei 50 % des Datenverkehrs es Ihnen ermöglichen könnte, später erfolgreich auf 100 % des Datenverkehrs zu reagieren, und dass der Versuch, den gesamten Datenverkehr jetzt zu bewältigen, den Dienst vollständig zum Erliegen bringen könnte. Aber woher weiß man, wann und in welchem Umfang man es tun sollte?

Ich vermute, dass es sich hierbei weitgehend um ein trennbares Problem handelt: Wenn der Load Balancer die Last gut genug verteilt, könnte es ausreichen, einfach etwas wie Hystrix oder Gleichzeitigkeitsbegrenzungen vorzuschalten. Der einzige Punkt, an dem ich einen Nutzen sehen könnte, wäre die Verwaltung der zusätzlichen Last auf gesunden Servern, wenn einige Server ungesund sind. Wenn nur 20 % der Server gesund sind, ist es dann vernünftig, dass sie das Fünffache ihres normalen Anteils an der Last übernehmen? Ein Load Balancer könnte vernünftigerweise beschließen, die Überschreitung auf das 10-fache oder so zu begrenzen und niemals einen Server aufzufordern, den "Lastanteil" von 9 Servern zu übernehmen, die als ungesund markiert wurden. Dies ist zwar machbar, aber ist es auch wünschenswert? Ich bin mir nicht sicher. Es ist nicht vollständig anpassungsfähig, da eine Überlastungsgrenze immer noch konfiguriert werden muss, und diese Konfiguration kann leicht veraltet sein (oder irrelevant, z. B. in einer Zeit mit geringem Datenverkehr).

SCHLUSSFOLGERUNGEN

Auf der Grundlage der obigen Ausführungen bin ich der Meinung, dass viele der bestehenden Optionen für die Lastverteilung in allgemeinen Umgebungen mit hoher Verfügbarkeit zwar unter normalen Bedingungen und unter einer Reihe ausgewählter Fehlerbedingungen gut funktionieren, unter anderen Bedingungen jedoch aufgrund von Mobbing, unzureichender Reaktion auf Ausfälle und übermäßiger Reaktion auf korrelierte degradierte Zustände versagen.

Ein idealer Hochverfügbarkeits-Load-Balancer würde für seinen normalen Betrieb auf aktive Gesundheitsprüfungen verzichten und stattdessen passiv eine Reihe von Gesundheitsmetriken verfolgen, einschließlich aktueller Anfragen während des Flugs und abnehmender (oder rollierender) Metriken für Latenz und Ausfallrate. Ein Client, der diese Metriken verfolgt, ist in einer weitaus besseren Position, um Anomalien zu erkennen, als ein Client, der nur die Ergebnisse der regelmäßigen aktiven Gesundheitsprüfungen beobachtet.

Natürlich würde ein wirklich idealer Load Balancer eine perfekte Effizienz verkörpern, bei der selbst bei steigender Last alle Anfragen so erfolgreich und schnell wie möglich bearbeitet werden... bis das System seine theoretische Grenze erreicht, an der es plötzlich ausfällt (oder anfängt, Last abzuwerfen), anstatt allmählich zunehmenden Stress zu zeigen. Ich würde dies zwar unter "Probleme, die ich gerne hätte" ablegen, aber es zeigt, dass es notwendig ist, die Überwachungstools zu überprüfen, wenn der Load Balancer besonders gut darin ist, Serverausfälle vor der Außenwelt zu verbergen.

Die wichtigste offene Frage ist meines Erachtens, wie diese Gesundheitsmetriken kombiniert und bei der Serverauswahl so eingesetzt werden können, dass chaotisches Verhalten und die anderen in diesem Beitrag erwähnten Probleme minimiert werden, aber dennoch allgemein anwendbar bleiben. Ich setze derzeit auf eine multifaktorielle, gewichtete Zufallsauswahl, aber es bleibt abzuwarten, wie sie sich in der Praxis bewährt.