Elastic Cloud Serverless auf Azure Kubernetes Service (AKS) stellt eine innovative Plattform dar, die Elasticsearch-Services ohne Infrastrukturverwaltung ermöglicht und dabei automatisch skaliert. Während diese Lösung auf den ersten Blick eine hohe Leistungsfähigkeit verspricht, stieß das Site Reliability Engineering-Team (SRE) von Elastic während umfassender Lasttests auf unerwartete Netzwerkprobleme, die die Stabilität und den Durchsatz der Serverless-Plattform beeinflussten. Der Kern des Problems lag in Paketverlusten und Netzwerküberlastungen, die trotz der physischen 100 Gb/s Netzwerkschnittstellen auf den AKS-Knoten auftraten. Diese Herausforderung erforderte eine eingehende technische Analyse und Optimierung auf mehreren Ebenen, um ein zuverlässiges und performantes Erlebnis für die Nutzer sicherzustellen. Beim Start der Untersuchungen fiel den SRE-Teams auf, dass die Indizierungsraten von Elasticsearch auf Azure bei den durchgeführten Tests nicht nur insgesamt niedriger als erwartet waren, sondern auch starken Schwankungen unterlagen.
Diese Instabilität wurde begleitet von häufigen Fehlerantworten auf HTTP-Anfragen, die auf Netzwerkprobleme hinwiesen. Die Suche nach der Ursache konzentrierte sich zunächst auf das Netzwerk, das sich trotz moderner Hardware als der Hauptfaktor herausstellte. Die Besonderheit bei AKS auf Azure liegt in der Nutzung von Accelerated Networking, wodurch die Netzwerkpakete über SR-IOV (Single Root I/O Virtualization) direkt an die virtuellen Maschinen weitergeleitet werden. Das bedeutet, dass die virtuelle Maschine direkten Zugriff auf eine Virtual Function der physischen Netzwerkkarte erhält, wodurch der Hypervisor als Zwischenschicht übergangen wird. Diese Architektur verbessert zwar Latenz und Durchsatz, bringt jedoch Herausforderungen mit sich, wenn das Betriebssystem der VM die Bearbeitung der damit verbundenen Hardwareereignisse und Netzwerkpakete nicht schnell genug bewältigen kann.
Der Paketverlust wurde durch die Analyse der Netzwerkschnittstellenstatistiken auf den AKS-Knoten bestätigt. Besonders die SR-IOV-basierten Interfaces zeigten ungewöhnlich hohe Werte im sogenannten "missed"-Zähler, der darauf hinweist, dass Pakete nicht in den Empfangspuffer (RX Ring Buffer) aufgenommen werden konnten, weil dieser voll war. Dieses Verhalten weist auf eine Überlastung der Ringpuffer hin, die von der Netzwerkkarte und dem Betriebssystem genutzt werden, um eingehende Pakete zwischenzuspeichern, bevor sie weiterverarbeitet werden. Trotz der Geschwindigkeit der Hardwarenetzwerkverbindungen können mikroburschartige Zustände auftreten, in denen große Mengen Pakete innerhalb geringster Zeitspannen eintreffen und damit Puffer und Interruptverarbeitung überfordern. Um das Paketverlustproblem an der Quelle zu minimieren, wurde der erste Fokus auf die Netzwerk-Hardwareebene gelegt.
Die Standardgröße der RX-Ringpuffer der Netzwerkkarte auf den AKS-Knoten wurde mittels des Werkzeugs ethtool überprüft und mit der maximalen Unterstützung verglichen. Hier zeigte sich, dass der vom Betriebssystem verwendete RX-Puffer lediglich ein Achtel der maximal möglichen Ringpuffergröße betrug. Durch das Erhöhen dieser Puffergröße konnte das Netzwerk erheblich entlastet werden, indem mehr Pakete zwischengespeichert und so Verluste vermieden wurden. Die Umsetzung dieses Tunings erfolgte automatisiert über DaemonSets, die auf allen Knoten Änderungen mittels udev-Regeln durchsetzten. Nach der Anpassung der RX-Ringpuffer zeigte sich ein Rückgang der verlorenen Pakete von bis zu 99 Prozent, was die Indizierungsraten deutlich stabilisierte und verbesserte.
Dennoch war das Problem mit Paketverlusten noch nicht vollständig gelöst. Die tiefergehende Analyse offenbarte, dass auch auf der Kernel-Ebene und in der logischen Netzwerkebene der Pods weiterhin Paketverluste auftraten. Diese lagen in den virtuellen Ethernet-Schnittstellen, die im Kontext von Azure CNI mit Cilium für die Netzwerkimplementierung innerhalb der Kubernetes-Pods genutzt werden. Hier wurden Pakete vom Kernel aktiv verworfen, was auf eine Engpasssituation in der Verarbeitung hindeutete. Um die Ursache dieses Phänomens zu ergründen, setzte das SRE-Team auf Kernel-Tracing-Tools wie perf, um die Ursachen für das Freigeben (drop) von Socket Buffern (sk_buff) auf Kernel-Ebene nachzuvollziehen.
Durch die Erstellung von sogenannten Flamegraphs, die eine visuelle Darstellung der Aufrufstapel von Kernelfunktionen bieten, wurde deutlich, dass viele Paketverluste im Bereich der veth-Schnittstellen und bei der Warteschlangenverwaltung lagen. Im Speziellen war die Funktion enqueue_to_backlog häufig der Punkt, an dem Pakete aus Überlastung abgewiesen wurden. Die Warteschlange zur Entlastung von Netzwerkpaketspitzen wird durch den Kernel-Parameter net.core.netdev_max_backlog gesteuert.
Der Standardwert von 1000 war für die Traffic-Mengen und die Hardware nicht ausreichend dimensioniert. Nach dem Erhöhen dieses Parameters auf 32768 war eine weitere deutliche Reduktion der Paketverluste messbar. Dieses Kernel-Tuning trug gemeinsam mit dem bereits umgesetzten Hardware-Puffer-Update zu einer Steigerung der Elasticsearch-Indizierungsraten um bis zu 60 Prozent gegenüber dem Ausgangszustand bei. Die Stabilität des Systems verbesserte sich somit maßgeblich. Neben den technischen Maßnahmen war die enge Zusammenarbeit mit dem Azure-Team ein zentraler Erfolgsfaktor.
Azure konnte bestätigen, dass keine Paketverluste unterhalb der VM im Netzwerkfabric oder in der Hypervisor-Schicht auftraten, womit jeglicher Fokus auf die VM-internen Netzwerkprozesse gelegt werden konnte. Das gemeinsame Erarbeiten eines reproduzierbaren Testsetups, unter anderem basierend auf iperf3, erlaubte gezielte Analysen und Bestätigungen der vorgeschlagenen Konfigurationsänderungen. Die gesamte Untersuchung verdeutlicht, dass auch in hochabstrahierten und managed Cloud-Umgebungen wie AKS tiefes Verständnis der zugrunde liegenden Hardware, Betriebssystem-Einstellungen und Container-Netzwerkstrukturen nötig ist, um eine optimale Performance zu gewährleisten. Standardwerte und Voreinstellungen sind nicht immer für Hochleistungsanwendungen optimiert und müssen proaktiv überprüft und angepasst werden. Die Kombination aus profunder Systembeobachtung mit Elastic Observability, detaillierten Kernel-Traces und der Expertise von Cloud-Ingenieuren brachte den entscheidenden Durchbruch.
Abschließend zeigt das Beispiel Elastic Cloud Serverless auf Azure eindrucksvoll, dass selbst moderne 100 Gb/s Netzwerkhardware bei intensiven Belastungen durch Paketstürme an Grenzen stößt, wenn Betriebssysteme und Netzwerktreiber nicht passend konfiguriert sind. Die Optimierung von ring buffer Grössen auf der Netzwerkkarte und die Erhöhung der Kernel-Backlog-Parameter tragen entscheidend dazu bei, Netzwerkpacketverluste zu vermeiden und dadurch Latenzen sowie Fehlerquoten zu senken. Daraus resultiert eine merklich verbesserte und stabilere Elasticsearch-Performance. Dieses Wissen ist nicht nur relevant für Elastic Cloud Serverless Anwender, sondern generell für jedes Szenario, in dem Kubernetes-Cluster auf Azure unter hoher Netzwerklast betrieben werden. Die Kooperation und der Dialog zwischen Software-Herstellern wie Elastic und Cloud-Anbietern wie Microsoft Azure sind essentiell, um Low-Level-Problemstellungen transparent zu machen und gemeinsam Lösungen zu entwickeln.
Mit solchen Ansätzen lassen sich Managed Services weiterhin skalierbar, performant und zuverlässig betreiben – zur Zufriedenheit der großen Nutzergemeinschaft. Die Investition in umfassende Load-Tests, tiefgehende Beobachtungssysteme und präzise Abstimmung der Netzwerkparameter zahlt sich langfristig durch eine deutlich gesteigerte Nutzererfahrung sowie Betriebssicherheit aus.
