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.
Aus diesem Grund müssen wir uns noch einmal damit befassen. Denn die Lastverteilung sollte nicht so taktisch erfolgen, wie es zunehmend von den Betriebsleuten getan wird, die diese magischen Dienste heute immer häufiger bereitstellen, konfigurieren und einsetzen müssen. Strategisch betrachtet kann der Lastenausgleich die Leistung verbessern, Risiken verringern und zu einer effizienteren Nutzung der zur Bereitstellung von Anwendungen erforderlichen Ressourcen beitragen. Sie sind schlauer als der Spitzname „Klempner“, den man ihnen oft anheftet, und das Verständnis einiger wichtiger Punkte wird den Betriebsleitern dabei helfen, genauer darüber nachzudenken, wie sie Lastausgleich zur 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 zunächst erwähnen, dass Round Robin der letzte Algorithmus ist, den Sie jemals erwähnen sollten, aber das wussten Sie bereits, oder? Daher überspringen wir diesen Punkt und widmen uns intelligenteren Algorithmen wie den wenigsten Verbindungen und der schnellsten Reaktionszeit. Dies sind natürlich viel bessere Entscheidungen, wenn Sie eine Strategie zur Balance zwischen Leistung und effizienter Ressourcennutzung entwickeln. Bei jedem davon werden Anwendungsmerkmale (oder zumindest die Merkmale der Plattformen, die die Anwendungen bereitstellen) berücksichtigt, die für die Entscheidung darüber, welche Anwendungsinstanz (oder, wenn Sie so wollen, Container) die nächste Anforderung erhalten soll, von entscheidender Bedeutung sind. Am wenigsten Verbindungen bedeutet, dass eine Instanz mit weniger Verbindungen über mehr Kapazität verfügt und daher diese Anfrage hier jetzt besser erfüllen kann. Dabei wird die Kapazitätseffizienz der Leistung vorgezogen.
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 ist Elastizität die Methode zur Skalierung von Anwendungen geworden. Elastizität erfordert eine bedarfsgerechte Skalierung nach oben und unten, um die Nutzung von Ressourcen (und Budgets) zu optimieren. Warum überproportional bereitstellen, wenn Sie bei Bedarf einfach hochskalieren können? Ebenso sind Hochverfügbarkeitsarchitekturen (HA), die auf Redundanzprinzipien basieren, fast passé. Warum sollten im (unwahrscheinlichen) Fall eines Ausfalls der primären App-Instanz ungenutzte Ressourcen im Standby-Modus benötigt werden? Das ist eine Verschwendung von Kapital und Betriebsbudgets! Raus, raus, verdammte Bereitschaft!
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: