3 Dinge, die Ops über Load Balancing wissen müssen
Lastenausgleich. Es ist allgemein anerkannt, dass wir sie brauchen, uns darauf verlassen und sie täglich verwenden, um Anwendungen zu skalieren. Sie ist zu einer kritischen Infrastruktur geworden, die nicht nur für die Skalierung zur Deckung der Nachfrage verantwortlich ist, sondern auch für die Sicherstellung der kontinuierlichen Verfügbarkeit von Anwendungen und Diensten, auf die sich Unternehmen hinsichtlich ihrer Produktivität und ihres Gewinns verlassen.
Deshalb müssen wir das Thema noch einmal aufgreifen. Denn Lastenausgleich sollte nicht so taktisch behandelt werden, wie es die Betriebsteams heute oft tun, die diese komplexen Dienste häufig bereitstellen, konfigurieren und implementieren müssen. Wenn Sie Lastenausgleich strategisch angehen, verbessert er die Leistung, senkt Risiken und hilft dabei, Ressourcen für die Bereitstellung von Anwendungen effizienter zu nutzen. Lastenausgleich ist weit mehr als nur „Klempnerei“. Wenn Sie einige zentrale Aspekte verstehen, können Betriebsteams Lastenausgleich gezielter für die Unterstützung von Anwendungen einsetzen.
Also, ohne weitere Umschweife, hier sind drei Dinge, die der Betrieb wirklich über den Lastenausgleich wissen muss.
1. Algorithmen sind relativ
Ich würde damit anfangen zu sagen, dass Round Robin der schlechteste Algorithmus ist, den Sie nennen könnten – aber das wussten Sie sicher schon, oder? Also überspringen wir ihn und konzentrieren uns auf intelligentere Algorithmen wie wenigste Verbindungen und schnellste Antwortzeit. Diese sind deutlich besser, wenn Sie Performance mit effizienter Ressourcennutzung in Einklang bringen wollen. Jeder berücksichtigt Eigenschaften der Anwendung (oder zumindest der Plattformen, die sie bereitstellen), die entscheidend sind, um zu entscheiden, welche Anwendungsinstanz (oder welcher Container) als Nächstes die Anfrage bearbeiten sollte. Wenigste Verbindungen bedeutet, dass eine Instanz mit weniger Verbindungen noch Kapazität hat und deshalb gerade diese Anfrage am besten erfüllen kann. Hier zählt also Effizienz der Kapazitätsauslastung mehr als maximale Performance.
Die schnellste Reaktionszeit am anderen Ende des Spektrums ergibt sich aus der Entscheidung, Anfragen auf Grundlage der Leistung weiterzuleiten. Je schneller die Instanz, desto häufiger wird sie ausgewählt. Aufgrund der betrieblichen Grundsätze (mit zunehmender Belastung nimmt die Leistung ab) bedeutet dies, dass letztlich ein weniger belasteter Server schneller reagiert und daher ausgewählt wird. Dies bedeutet zwar einen Vorteil gegenüber der Kapazitätseffizienz, dieser Algorithmus entscheidet sich jedoch jedes Mal für die Leistung gegenüber der Kapazität.
Beachten Sie nun aber die Namen der Algorithmen: Am wenigsten und am schnellsten . Bedenken Sie nun, dass von zwei Schildkröten, die den Bürgersteig entlangrasen, eine von ihnen schneller ist, obwohl sie sich beide mit einer Geschwindigkeit fortbewegen, die wir alle als „langsam“ bezeichnen würden. Dasselbe gilt für die wenigsten Verbindungen. Wenn Sie die Wahl zwischen 99 und 100 haben, ist 99 definitiv der niedrigere Wert.
Warum es wichtig ist
Die Art und Weise, wie die Lastverteilung die Anforderungen verwaltet, hat direkte und unmittelbare Auswirkungen auf Leistung und Verfügbarkeit. Beides sind entscheidende Eigenschaften, die sich letztendlich auf die Kundenbindung und die Mitarbeiterproduktivität auswirken. Durch die Optimierung von Architekturen einschließlich Lastausgleich können Sie den Geschäftserfolg steigern und Ihre Produktivität und Ihren Gewinn steigern.
Tiefer tauchen:
- Zurück zu den Grundlagen: Die Theorie der (Leistungs-)Relativität
- Zurück zu den Grundlagen: Least Connections ist nicht Least Loaded
2. Sofortiges Scheitern ist (oft) ein Mythos
Seit dem Aufstieg der Cloud und softwaredefinierter Rechenzentren nutzt man Elastizität, um Anwendungen zu skalieren. Elastizität bedeutet, dass Sie die Kapazitäten bedarfsgerecht erhöhen und verringern, um Ressourcen und Budgets optimal einzusetzen. Warum Überkapazitäten vorhalten, wenn Sie einfach bei Bedarf skalieren können? Gleiches gilt für Hochverfügbarkeits-Architekturen, die auf Redundanz setzen – sie sind fast überholt. Warum Kapazitäten im Leerlauf bereithalten, falls die Hauptanwendung ausfällt, auch wenn das höchst unwahrscheinlich ist? Das verschwendet Kapital und Betriebsmittel. Weg mit dem unnötigen Standby!
Während Fehler und Skalierung auf Abruf eine schöne Theorie sind, ist es in der Praxis nicht ganz so einfach. Die Realität ist, dass selbst virtuelle Server (oder Cloud-Server oder welchen Begriff Sie auch immer verwenden möchten) einige Zeit bis zum Start benötigen. Wenn Sie (oder Ihr automatisiertes System) warten, bis dieser primäre Server ausfällt oder seine Kapazitätsgrenze erreicht hat, bevor Sie einen anderen starten, ist es bereits zu spät. Die Kapazitätsplanung in Cloud-Umgebungen kann nicht auf derselben Mathematik basieren, die in einer herkömmlichen Umgebung funktioniert hat. Bei Kapazitätsschwellenwerten muss nun die Verbrauchsrate sowie die zum Starten eines weiteren Servers benötigte Zeit in die Gleichung einbezogen werden, um eine nahtlose Skalierung entsprechend der Nachfrage zu ermöglichen.
Und das Gleiche gilt für das Failover. Wenn die Primärversion ausfällt, wird es einige Zeit dauern, bis ein Ersatz auf den Markt kommt. Zeit, in der die Leute die Verbindung verlieren, Zeitüberschreitungen erleiden und Sie wahrscheinlich für einen Konkurrenten oder das neueste Katzenvideo verlassen. Ein ungenutztes Ersatzrad mag zwar wie eine Verschwendung erscheinen (wie eine Versicherung), aber wenn Sie es brauchen, werden Sie froh sein, dass es da ist. Insbesondere wenn die App für die Kundenbindung oder den Umsatz verantwortlich ist, kann das Risiko einer Ausfallzeit von nur wenigen Minuten (und die damit verbundenen Kosten) die Kosten für die Vorhaltung einer Ersatzanwendung mehr als wettmachen.
Interessanterweise scheinen Container diese Probleme durch blitzschnelle Startzeiten möglicherweise zu lösen. Wenn Verfügbarkeit, Leistung und Kosten alle gleichermaßen wichtig sind, ist es vielleicht an der Zeit zu untersuchen, welchen Mehrwert Container hinsichtlich der Ausbalancierung aller drei Aspekte bieten können.
Warum es wichtig ist
Ausfallzeiten sind kostspielig. Die Ursache von Ausfallzeiten ist nicht annähernd so wichtig wie deren Vermeidung. Um die für den Geschäftserfolg entscheidende kontinuierliche Verfügbarkeit aufrechtzuerhalten, ist es zwingend erforderlich, im Falle eines Ausfalls die richtige Architektur und die richtigen Failover-Pläne bereitzustellen.
Tiefer tauchen:
3. Die Client-IP ist nicht die echte Client-IP.
Von allen Problemen, die beim Übergang einer App von der Entwicklung zur Produktion auftreten, ist dies wahrscheinlich das häufigste und am einfachsten zu vermeidende. Die meisten Lastausgleichsdienste (zumindest alle guten) sind Proxys . Das heißt, der Client stellt eine Verbindung zum Proxy her und der Proxy stellt eine Verbindung zu Ihrer App her. Beide verwenden TCP, um dieses HTTP zu transportieren, was bedeutet, dass es den Gesetzen der Vernetzung gehorchen muss. Die Quell-IP (was Sie für die Client-IP halten) ist tatsächlich die IP-Adresse des Proxys. Wenn Ihre Sicherheit, Authentifizierung oder Messung auf der IP-Adresse basiert, stellt dies ein ernstes Problem dar. Der Wert, den Sie aus dem HTTP-Header ziehen, ist nicht der gewünschte.
Die Branche hat den Umgang damit durch die Nutzung benutzerdefinierter HTTP-Header weitgehend standardisiert. Sie suchen wahrscheinlich wirklich nach dem Header „X-Forwarded-For“ . Dort fügt ein Proxy die echte, tatsächliche Client-IP-Adresse ein, wenn er Anfragen weiterleitet. Leider handelt es sich hierbei nicht um einen Standard, sondern eher um einen De-facto-Standard vom Typ „wir waren uns alle mehr oder weniger einig“, Sie müssen ihn also überprüfen.
Der Punkt ist, dass die gesuchte Client-IP-Adresse nicht die ist, die Sie vermuten. Daher müssen Entwickler dies berücksichtigen, bevor Apps, die diese Informationen benötigen, in eine Produktionsumgebung verschoben werden und plötzlich nicht mehr funktionieren.
Warum es für das Geschäft wichtig ist
Die Fehlerbehebung in der Produktion ist weitaus kostspieliger als in Entwicklungs- oder Testumgebungen. Sowohl die Zeit, die zum Finden und Beheben des Problems benötigt wird, wirkt sich negativ auf den Projektzeitplan aus als auch verzögert die Markteinführungszeit, die für Wettbewerbsvorteile und Geschäftserfolg in einer Anwendungswelt so entscheidend ist. Das Erkennen dieses häufigen Problems und seine Behebung in der Entwicklungs- oder Testphase kann eine schnellere und reibungslosere Bereitstellung in der Produktion und auf dem Markt gewährleisten.
Tiefer tauchen: