Unbeabsichtigte Folgen: Proxys unter Last

Lori Mac VittieDistinguished Engineer und Chief Evangelist | F5

Die Notwendigkeit der Skalierbarkeit steht heutzutage außer Frage. Die Antwort lautet immer: Ja, sie wird benötigt. Unternehmenswachstum hängt von der operativen Skalierung der Anwendungen ab, die schließlich ein wesentlicher Bestandteil heutiger Geschäftsmodelle sind – unabhängig von der Branche. Daher werden Systeme in der Regel von vornherein mit den Komponenten bereitgestellt, die erforderlich sind, um die nötige Skalierung zu erreichen, sobald – und nicht falls – sie benötigt wird. Das bedeutet üblicherweise den Einsatz eines Proxys. Die für die Skalierung zuständigen Proxys (in der Regel Load Balancer) sind daher äußerst wichtige Komponenten jeder modernen Architektur.

Diese Proxys dienen nicht nur als Mechanismus für die Skalierung, sondern sollen dies dank der Möglichkeiten der automatischen Skalierung zunehmend wie von selbst erledigen. Hinter diesem einfachen Begriff verbirgt sich eine Menge – etwa die Möglichkeit, ein System programmgesteuert anzuweisen, nicht nur zusätzliche Kapazitäten bereitzustellen, sondern auch sicherzustellen, dass der für die Skalierbarkeit zuständige Proxy davon Kenntnis erhält und Anfragen dorthin weiterleiten kann.

Man kann davon ausgehen, dass jeder brauchbare Proxy über die erforderlichen Programmierschnittstellen verfügt. Schließlich geht es bei der API-Ökonomie nicht nur um den Austausch zwischen Anwendungen und Menschen, sondern auch um den Austausch zwischen Systemen – ob lokal oder extern in der Cloud. Was wir jedoch oft übersehen: Das Hinzufügen einer neuen Ressource zu einem Load-Balancing-Proxy erfolgt auf der Management- oder Steuerungsebene, nicht auf der Datenebene.

Das leuchtet ein. Schließlich wollen wir den laufenden Betrieb des Systems nicht beeinträchtigen, während wir Statistiken erfassen oder seine Konfiguration ändern. Das ist ein absolutes Tabu – insbesondere dann, wenn wir zusätzliche Kapazitäten bereitstellen möchten, weil das System unter Volllast läuft und Apps an erwartungsvolle Nutzer ausliefert.

Aber was passiert, wenn der umgekehrte Fall eintritt? Wenn der laufende Betrieb des Systems dessen Verwaltung beeinträchtigt?

Ihre automatische Skalierung (oder auch die manuelle Skalierung) wird fehlschlagen. Das bedeutet, dass die Anwendungskapazität nicht erhöht wird und das Unternehmen darunter leiden wird.

Das ist schlecht – als müsste ich Ihnen das noch sagen.

Der Grund dafür ist, dass viele Proxys (die nicht im Hinblick auf dieses Paradoxon entwickelt wurden) Systemressourcen sowohl für die Steuerungs- als auch für die Datenebene gemeinsam nutzen. Es gibt keine Trennung zwischen ihnen. Dasselbe Netzwerk, über das die Apps bereitgestellt werden, wird auch zur Verwaltung des Proxys verwendet. Derselbe Arbeitsspeicher und dieselbe Rechenleistung, die für die Bereitstellung der Apps vorgesehen sind, werden auch für die Verwaltung des Proxys eingesetzt. Unter Last erhält nur eine dieser beiden Ebenen die Ressourcen. Wenn Sie versuchen, dem Proxy App-Ressourcen hinzuzufügen, um zu skalieren, aber nicht auf das System zugreifen können, um dies zu tun, stecken Sie so gut wie in Schwierigkeiten.

Deshalb ist es wichtig, bei der Auswahl von Proxys auch deren Verwaltbarkeit zu berücksichtigen. Dabei geht es nicht nur darum, wie einfach sie zu verwalten sind. Es geht auch nicht nur um ihre API- und Skripting-Funktionen, sondern um ihre Verwaltbarkeit unter Last. Proxys, die speziell für eine massive Skalierung konzipiert wurden, sollten über separate, für die Verwaltung vorgesehene Ressourcen verfügen. So ist sichergestellt, dass sie weiterhin verwaltet und überwacht werden können – unabhängig davon, wie stark die Datenebene durch die Bereitstellung von Anwendungen ausgelastet ist.

In der Netzwerkwelt bezeichnen wir dies als Out-of-Band-Management, da es außerhalb des Datenpfads stattfindet – also außerhalb des primären, kritischen Pfads.

Die Möglichkeit, einen Proxy unter Last außerhalb des Datenpfads zu verwalten, ist entscheidend für die Skalierbarkeit der Anwendungen – ob automatisch oder manuell – und damit auch des Unternehmens.

Ü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