3 Dinge, die das Betriebsteam über Lastverteilung wissen muss

Lori Mac VittieDistinguished Engineer und Chief Evangelist | F5

Lastverteilung. Es ist allgemein anerkannt, dass wir sie benötigen, uns auf sie verlassen und sie täglich nutzen, um Anwendungen hoch- und – hoffentlich – auch herunterskalieren zu können. Sie ist zu einer kritischen Infrastruktur geworden, die nicht nur für die bedarfsgerechte Skalierung verantwortlich ist, sondern auch die kontinuierliche Verfügbarkeit von Anwendungen und Diensten sicherstellt, auf die Unternehmen sowohl für ihre Produktivität als auch für ihren wirtschaftlichen Erfolg angewiesen sind.

Deshalb müssen wir uns erneut damit befassen. Denn Load Balancing sollte nicht so sehr als taktische Maßnahme betrachtet werden, wie es zunehmend von den IT-Betriebsteams gehandhabt wird, die diese magischen Dienste mittlerweile meist bereitstellen, konfigurieren und implementieren müssen. Strategisch eingesetzt kann Load Balancing die Leistung verbessern, Risiken reduzieren und dazu beitragen, die für die Bereitstellung von Anwendungen benötigten Ressourcen effizienter zu nutzen. Load Balancer sind intelligenter, als es die Bezeichnung „Klempnerarbeit“ vermuten lässt, auf die sie häufig reduziert werden. Das Verständnis einiger wichtiger Aspekte hilft Betriebsteams dabei, bewusster darüber nachzudenken, wie sie Load Balancing zur Unterstützung von Anwendungen einsetzen.

Kommen wir also ohne weitere Umschweife zu den drei Dingen, die das Betriebsteam unbedingt über Lastverteilung wissen muss.

1. Algorithmen sind relativ

Zunächst möchte ich erwähnen, dass Round Robin der letzte Algorithmus ist, den man überhaupt in Betracht ziehen sollte – aber das wussten Sie bereits, oder? Überspringen wir ihn also und befassen uns mit intelligenteren Algorithmen wie den wenigsten Verbindungen und der kürzesten Antwortzeit. Diese sind natürlich deutlich besser geeignet, wenn es darum geht, Leistung und effiziente Ressourcennutzung miteinander in Einklang zu bringen. Beide berücksichtigen Anwendungseigenschaften (oder zumindest die Eigenschaften der Plattformen, über die die Anwendungen bereitgestellt werden), die für die Entscheidung ausschlaggebend sind, welche Anwendungsinstanz (oder welcher Container, wenn Ihnen das lieber ist) die nächste Anfrage erhalten soll. Bei der Methode mit den wenigsten Verbindungen wird davon ausgegangen, dass eine Instanz mit weniger Verbindungen über mehr Kapazität verfügt und daher besser in der Lage ist, die aktuelle Anfrage sofort zu bearbeiten. Dabei wird die effiziente Kapazitätsauslastung gegenüber der Leistung bevorzugt.

Kürzeste Antwortzeit hingegen bedeutet, dass Anfragen leistungsabhängig weitergeleitet werden. Je schneller die Instanz ist, desto häufiger wird sie ausgewählt. Da die üblichen Betriebsgrundsätze gelten (mit zunehmender Last sinkt die Leistung), wird letztlich ein weniger ausgelasteter Server schneller antworten und daher ausgewählt werden. Auch wenn damit die effiziente Kapazitätsnutzung bis zu einem gewissen Grad berücksichtigt wird, gibt dieser Algorithmus der Leistung stets den Vorrang vor der Kapazität.

Beachten Sie nun aber die Bezeichnungen der Algorithmen: geringste Anzahl und schnellste. Stellen Sie sich nun vor, zwei Schildkröten liefern sich auf dem Gehweg ein Rennen. Eine von ihnen ist schneller, obwohl sich beide mit einer Geschwindigkeit fortbewegen, die wir alle als „langsam“ bezeichnen würden. Dasselbe gilt für die geringste Anzahl von Verbindungen. Wenn man die Wahl zwischen 99 und 100 hat, ist 99 eindeutig die geringere der beiden Zahlen.

Warum das wichtig ist

Die Art und Weise, wie der Lastenausgleich Anfragen verarbeitet, wirkt sich direkt und unmittelbar auf Leistung und Verfügbarkeit aus. Beides sind entscheidende Faktoren, die letztlich die Kundenbindung und die Produktivität der Mitarbeitenden beeinflussen. Die Optimierung von Architekturen unter Einbeziehung des Lastenausgleichs trägt dazu bei, den Geschäftserfolg zu sichern und die Ziele hinsichtlich höherer Produktivität und Gewinne zu erreichen.

Vertiefung:

• Zurück zu den Grundlagen: Die Theorie der (Performance-)Relativität
• Zurück zu den Grundlagen: Die wenigsten Verbindungen bedeuten nicht die geringste Auslastung

2. Sofortiges Fehlschlagen ist (oft) ein Mythos

Seit dem Aufstieg der Cloud und softwaredefinierter Rechenzentren ist Elastizität zum bevorzugten Ansatz für die Skalierung von Anwendungen geworden. Elastizität erfordert eine bedarfsgerechte Auf- und Abskalierung, um Ressourcen (und Budgets) optimal zu nutzen. Warum sollte man überdimensionieren, wenn man bei Bedarf einfach hochskalieren kann? Ebenso sind Hochverfügbarkeitsarchitekturen (HA), die auf dem Prinzip der Redundanz beruhen, beinahe aus der Mode gekommen. Warum ungenutzte Ressourcen in Bereitschaft halten, falls die primäre Anwendungsinstanz – wider Erwarten – ausfällt? Welch eine Verschwendung von Investitions- und Betriebsbudgets! Fort, fort, verdammter Standby!

Ausfallabsicherung und Skalierung nach Bedarf sind zwar in der Theorie ein überzeugendes Konzept, in der Praxis ist es jedoch nicht ganz so einfach. Tatsächlich benötigen selbst virtuelle Server (oder Cloud-Server oder welchen Begriff Sie auch immer bevorzugen) eine gewisse Zeit zum Hochfahren. Wenn Sie (oder Ihr automatisiertes System) mit dem Start eines weiteren Servers warten, bis der primäre Server ausfällt oder seine Kapazitätsgrenze erreicht, ist es bereits zu spät. Die Kapazitätsplanung in Cloud-Umgebungen kann nicht auf denselben Berechnungen basieren, die in herkömmlichen Umgebungen funktioniert haben. Bei der Festlegung von Kapazitätsschwellenwerten müssen nun sowohl die Verbrauchsrate als auch die Zeit berücksichtigt werden, die zum Starten eines weiteren Servers benötigt wird, damit die Kapazität nahtlos mit der Nachfrage skaliert werden kann.

Dasselbe gilt für das Failover. Fällt der primäre Server aus, dauert es eine Weile, bis ein Ersatz gestartet ist. In dieser Zeit werden Verbindungen unterbrochen, Anfragen laufen in Timeouts und die Nutzer wechseln wahrscheinlich zu einem Mitbewerber oder schauen sich das neueste Katzenvideo an. Eine ungenutzte Reserve mag zwar wie eine Verschwendung erscheinen – ähnlich wie eine Versicherung –, doch wenn sie gebraucht wird, ist man froh, sie zu haben. Insbesondere wenn die Anwendung für die Kundeninteraktion oder den Umsatz verantwortlich ist, können das Risiko selbst weniger Minuten Ausfallzeit und die daraus entstehenden Kosten die Kosten für das Vorhalten eines Ersatzservers mehr als rechtfertigen.

Interessanterweise scheinen Container diese Probleme dank blitzschneller Startzeiten lösen zu können. Wenn Verfügbarkeit, Leistung und Kosten gleichermaßen wichtig sind, ist es möglicherweise an der Zeit, sich näher damit zu befassen, welchen Beitrag Container dazu leisten können, diese drei Aspekte in Einklang zu bringen.

Warum das wichtig ist

Ausfallzeiten sind kostspielig. Die Ursache eines Ausfalls ist bei Weitem nicht so wichtig wie seine Vermeidung. Um die für den Geschäftserfolg entscheidende kontinuierliche Verfügbarkeit auch im Fehlerfall aufrechtzuerhalten, müssen unbedingt die richtige Architektur und geeignete Failover-Pläne vorhanden sein.

Vertiefung:

• Grundlagen der Lastverteilung: Skalieren statt scheitern

3. Die Client-IP ist nicht die tatsächliche Client-IP.

Von allen Problemen, die beim Übergang einer App von der Entwicklungs- in die Produktionsumgebung auftreten, ist dies wahrscheinlich das häufigste und zugleich am einfachsten zu vermeidende. Die meisten Load-Balancing-Dienste (zumindest alle guten) sind nämlich Proxys. Das bedeutet, dass der Client eine Verbindung zum Proxy herstellt und der Proxy wiederum eine Verbindung zu Ihrer App. Beide verwenden TCP zur Übertragung von HTTP, weshalb die Regeln der Netzwerktechnik gelten. Die Quell-IP-Adresse (die Sie für die Client-IP-Adresse halten) ist in Wirklichkeit die IP-Adresse des Proxys. Wenn Sie Sicherheitsmaßnahmen, Authentifizierung oder Verbrauchsmessung auf Grundlage der IP-Adresse durchführen, stellt dies ein ernstes Problem dar. Der Wert, den Sie aus dem HTTP-Header auslesen, ist nicht der gewünschte.

Die Branche hat sich im Umgang damit weitgehend auf die Verwendung benutzerdefinierter HTTP-Header geeinigt. Der X-Forwarded-For -Header ist wahrscheinlich das, wonach Sie eigentlich suchen – dort trägt ein Proxy beim Weiterleiten von Anfragen die echte, tatsächliche IP-Adresse des Clients ein. Leider handelt es sich dabei nicht um einen offiziellen Standard, sondern eher um einen De-facto-Standard nach dem Motto „Wir haben uns irgendwie alle darauf geeinigt“. Daher sollten Sie dies überprüfen.

Der Punkt ist, dass die gesuchte Client-IP-Adresse nicht die ist, für die Sie sie halten. Entwickler müssen dies daher berücksichtigen, bevor Anwendungen, die diese Information benötigen, in eine Produktionsumgebung überführt werden und plötzlich nicht mehr funktionieren.

Warum das für das Unternehmen wichtig ist

Die Behebung von Problemen in der Produktionsumgebung ist weitaus kostspieliger als in Entwicklungs- oder Testumgebungen. Sowohl die Fehlersuche als auch die Fehlerbehebung wirken sich negativ auf Projektzeitpläne aus und verzögern die Markteinführung, die in einer von Anwendungen geprägten Welt für Wettbewerbsvorteile und Geschäftserfolg entscheidend ist. Wird dieses häufig auftretende Problem frühzeitig erkannt und bereits in der Entwicklungs- oder Testphase behoben, lässt sich eine schnellere, reibungslose Bereitstellung in der Produktionsumgebung und Markteinführung gewährleisten.

Vertiefung:

• In arger (Load-Balancing-)Not: Ich will meine Client-IP

Über den Autor

Lori Mac VittieDistinguished Engineer und Chief Evangelist | F5

Lori MacVittie ist Distinguished Engineer und Chief Evangelist im Office of the CTO von F5 und verfügt über umfassende Expertise in den Bereichen Anwendungsbereitstellung, Automatisierungsstrategie und Infrastruktur. Sie ist dafür bekannt, Komplexität verständlich zu machen – ob sie Leitplanken für KI-Agenten definiert, fragile Multicloud-Architekturen analysiert oder die Grenzen skalierbarer Systeme auslotet. Sie verfügt über mehr als dreißig Jahre Branchenerfahrung in der Anwendungsentwicklung, IT-Architektur sowie im Netzwerk- und Systembetrieb. Bevor sie zu F5 kam, war sie als mehrfach ausgezeichnete Technologie-Redakteurin tätig. MacVittie hat einen Masterabschluss in Informatik und ist eine produktive Autorin, deren Veröffentlichungen die Bereiche Sicherheit, Cloud und Unternehmensarchitektur abdecken. Außerdem spielt sie leidenschaftlich gern Brett- und Videospiele und vertritt mit voller Überzeugung klare Ansichten zum Thema Käse.

Weitere Blogbeiträge von Lori Mac Vittie