Storage-Teams, die Infrastrukturen für KI entwickeln, haben zahlreiche Möglichkeiten, Daten schneller zu übertragen. Zunehmend stellt sich ihnen jedoch eine andere Frage: Sind die Daten, die für Training, Retrieval-Augmented Generation (RAG) und Inferenz benötigt werden, weiterhin erreichbar und unversehrt, wenn ein Knoten ausfällt, eine Wiederherstellung länger dauert, ein Agent sich fehlerhaft verhält oder jemand Datenverkehr abfängt, auf den er keinen Zugriff haben sollte?
Wir bei F5 sind überzeugt, dass Ausfallsicherheit und Sicherheit zentrale Aspekte der Architektur von KI-Speicherinfrastrukturen sind. Sie bilden eine gemeinsame Designaufgabe, und der richtige Ort, um beides zu lösen, ist ein zentraler Zugangspunkt, der S3 versteht. Dieser Beitrag erläutert, warum wir diese Auffassung vertreten, wie F5 diese Herausforderung angeht und wo wir unsere Argumente kürzlich der Entwickler-Community für Speicherlösungen vorgestellt haben.
Ausfallsicherheit und Sicherheit sind ein und dasselbe Problem
Jede Stufe der Retrieval-Augmented Generation (RAG) – von nativem über fortgeschrittenes und modulares RAG bis hin zu Graph RAG – liefert umfassendere Antworten, indem mehr Vektoren und Dokumente aus dem Objektspeicher abgerufen werden. Dadurch sind Speicherverfügbarkeit und Zugriffslatenz für die Zeit bis zur Ausgabe des ersten Tokens ebenso entscheidend wie die Generierungsgeschwindigkeit.
Gleichzeitig bedeutet S3-kompatibler Speicher selbst nach all diesen Jahren noch immer nicht, dass er interoperabel ist. Das ist ein praktisches Argument dafür, dem Speicher einen einheitlichen Zugang vorzuschalten, damit der Client stets mit einem verlässlichen Endpunkt kommuniziert und sich nie darum kümmern muss, welches Anbietersystem dahinter antwortet. Speichercluster können zudem aus vielen Gründen an Leistung verlieren oder ausfallen – von Knotenausfällen und Netzwerkfehlern bis hin zu längeren Wiederherstellungszeiten bei Laufwerken mit höherer Speicherdichte. In solchen Fällen muss ein Traffic-Manager Speicheranfragen an die weiterhin fehlerfrei und leistungsfähig arbeitenden Knoten weiterleiten, sodass die Clients davon nichts bemerken.
“Sobald die Traffic-Schicht S3 versteht, sind Ausfallsicherheit und Sicherheit nicht mehr zwei getrennte Projekte, sondern werden zu einem zentralen Kontrollpunkt.”
Autonome Agenten greifen inzwischen ebenfalls direkt auf den Speicher zu. Sobald nicht menschliche Aufrufer eigenständig einen Bucket öffnen können, müssen die Zugriffskontrollen direkt auf der S3-Ebene angesiedelt sein – und nicht erst an einer nachgelagerten Stelle, nachdem die Anfrage bereits bedient wurde. Das Problem besteht darin, dass die meisten Load Balancer, die derzeit vor Objektspeicher-Clustern eingesetzt werden, nie für S3 konzipiert wurden und daher nichts davon erkennen können. Sobald die Traffic-Ebene S3 versteht, sind Ausfallsicherheit und Sicherheit nicht länger zwei getrennte Projekte, sondern werden zu einem zentralen Kontrollpunkt.
Daten während der Übertragung schützen, bevor die Speicherplattform es kann
Ein Beispiel ist „Harvest now, decrypt later“ – ein Angriffsmuster, bei dem ein Angreifer heute verschlüsselten Datenverkehr aufzeichnet, um ihn später zu entschlüsseln, sobald Quantencomputing dies praktisch ermöglicht. Die meisten Objektspeicherplattformen können Daten während der Übertragung noch nicht mit quantenresistenter Verschlüsselung schützen. F5 BIG-IP mit Post-Quanten-Kryptografie kann dem Speicher vorgeschaltet werden und diese Sicherheitslücke schließen, ohne darauf warten zu müssen, dass jeder Speicheranbieter eine eigene Implementierung bereitstellt. Dies ist ein anschauliches Beispiel für Sicherheit, die direkt in den Speicherpfad integriert ist, statt an anderer Stelle im Stack hinzugefügt zu werden. Zudem handelt es sich um eine Kontrollmaßnahme, die ein Speicherteam einführen kann, ohne Änderungen am dahinterliegenden Cluster vornehmen zu müssen.
“Sobald die Leistungseinbußen beim Durchsatz wegfallen, ist der Proxy keine Belastung für die Pipeline mehr.”
Dies ist dank der Forschungsarbeiten und Labortests möglich, die F5 zur Entwicklung S3-spezifischer TCP-Profile für BIG-IP durchgeführt hat. Unabhängig bestätigt wurde dies, als SecureIQLab BIG-IP vor einem Dell ObjectScale-Cluster validierte. Mit S3-optimierten TCP-Profilen liegt der S3-Durchsatz bei allen getesteten Kombinationen aus Objektgröße und Netzwerklatenz nur um einen niedrigen einstelligen Prozentsatz unter dem Referenzwert ohne BIG-IP im Datenpfad. Gleichzeitig fing dieselbe Bereitstellung störenden Client-Datenverkehr ab und hielt den S3-Dienst während eines simulierten DDoS-Angriffs aufrecht. Sobald die Durchsatzeinbußen beseitigt sind, ist der Proxy keine Belastung für die Pipeline mehr, sondern wird zu der Stelle, an der Fehlerdomänen, Verschlüsselung und Richtlinien zentral im Datenpfad gesteuert werden.
Optimierte TCP-Datenströme und Testtools, denen das Ökosystem vertraut
Die jetzt auf BIG-IP definierten S3-TCP-Profile sind eher als Ausgangspunkt denn als feste Einstellung zu verstehen. Sie können weiter an die Eigenschaften einer bestimmten Produktionsumgebung angepasst und optimiert werden. Genau das möchten Speicherentwickler vor allem hören, wenn sie erwägen, BIG-IP in den Datenpfad einzubinden, um die TCP-Datenströme zwischen ihren verschiedenen S3-Datenverkehrsquellen und ihrem Objektspeicher zu optimieren.
F5 beabsichtigt außerdem, einen Beitrag zu den Testmethoden und Open-Source-Tools zu leisten, auf die sich Anbieter von S3-Speicherlösungen und deren Kunden bei der Erzeugung von S3-Datenverkehr verlassen. Denn ein Proxy, der in jedem S3-Datenpfad eingesetzt werden soll, sollte mit denselben Tools gemessen werden, denen auch der Rest des Ökosystems vertraut.
Was dies für den Architekten bedeutet, der die Pipeline entwirft
All dies deutet auf eine Prioritätenfolge hin, die die meisten Storage-Architekten unserer Ansicht nach bereits intuitiv anwenden: Ausfallsicherheit steht an erster Stelle, Sicherheit an zweiter, und Performance ist eine Anforderung, die jede Komponente im Datenpfad erfüllen muss, statt ein Grund dafür zu sein, eine weitere hinzuzufügen. Die Führungsebene möchte von den Storage-Teams wissen, welchen Gegenwert ihre Organisation für die Ausgaben für jede Komponente im I/O-Datenstrom erhält und welchen Beitrag die jeweilige Komponente unter den oben beschriebenen Ausfall- und Angriffsbedingungen leistet.
Die breitere Branchendiskussion über Data Fabrics und Data Intelligence kommt aus einer anderen Perspektive zum selben Schluss: Sobald nicht mehr die Frage im Mittelpunkt steht, wo Daten gespeichert sind, sondern wie sie gefunden, verwaltet und genutzt werden, wird ein zentraler Zugang, der einen einzigen Endpunkt und eine einheitliche Richtlinienebene für alle S3-kompatiblen Backends bereitstellt, zur Voraussetzung – unabhängig davon, welche Speicherplattform sich im nächsten Beschaffungszyklus durchsetzt.
Dieses Problem bezeichnet F5 als KI-Datenbereitstellung. Ein Application Delivery Controller, der S3 versteht, hat seinen Platz im Datenpfad nicht als weiteres Performance-Feature, das um Aufmerksamkeit konkurriert, sondern als zentrale Instanz, an der Verfügbarkeit, Zugriffskontrolle und Verschlüsselung für die Daten durchgesetzt werden, auf die Training, RAG und Inferenz angewiesen sind.
KI-Daten verfügbar und vertrauenswürdig halten
Aus diesem Grund setzen weltweit tätige Unternehmen F5 vor S3-kompatiblen Speichersystemen ein, um eine ausfallsichere und sichere Bereitstellung von KI-Daten zu gewährleisten. BIG-IP sorgt dafür, dass der Objektspeicher auch bei Knotenausfällen oder Lastspitzen bei der Datenaufnahme erreichbar bleibt, implementiert Sicherheitskontrollen auf der S3-Ebene, sodass schädlicher Datenverkehr die Daten gar nicht erst erreicht, und bewältigt beides, ohne die Pipeline zu verlangsamen. Dies wurde durch die unabhängigen Tests von SecureIQLab mit Dell ObjectScale bestätigt. Für Speicherarchitekten bedeutet dies eine zentrale Ebene im Datenpfad, die dafür sorgt, dass KI-Pipelines zuverlässig mit vertrauenswürdigen Unternehmensdaten ausgeführt werden.
Wir haben diese Ideen kürzlich auf der SNIA SDC 2026 vorgestellt
F5 stellte diese Argumentation auf der SNIA Storage Developer Conference in Santa Clara einem Fachpublikum aus der Speicherentwicklung vor. Dort erläuterte Paul Pindell, Principal Solutions Architect bei F5, wie ein optimierter Proxy im S3-Pfad Ausfallsicherheit, die Kontrolle über Fehlerdomänen und TLS-Offloading ohne Durchsatzeinbußen ermöglicht.
Die anschließenden Fragen zu S3-TCP-Profilen, zum Post-Quanten-Schutz für Daten während der Übertragung und dazu, wie ein Proxy mithilfe von Testtools aus dem Ökosystem bewertet werden sollte, bestätigten, dass Storage-Teams bereits einen zentralen Zugangspunkt fordern, der S3-kompatiblen Storage versteht. Weitere Informationen dazu, wie F5 einen ausfallsicheren und sicheren Zugriff auf Storage-Cluster ermöglicht, finden Sie auf der Seite zum Anwendungsfall für die Bereitstellung von KI-Daten.
Über die Autoren
Florin Meilescu ist Senior Principal Software Engineer und Test Architect bei F5. Dort ist er als Solution Test Architect für BIG-IP auf Hardware- und Softwareplattformen sowie in Public-Cloud-Umgebungen tätig. Er verfügt über mehr als 20 Jahre Erfahrung im Markt für Application Delivery Controller (ADC), unter anderem bei Citrix NetScaler. Seine Expertise reicht von L2- bis L7-Protokollen und den Systemen, über die sie übertragen werden, von Linux-Servern bis hin zu Netzwerkgeräten, die er zu Beginn seiner Karriere betreute. Florin hat einen Bachelorabschluss in Ingenieurwissenschaften von der Polytechnischen Universität Bukarest.
Weitere Blogbeiträge von Florin MeilescuPaul Pindell ist Principal Architect bei F5. Dort ist er im Bereich Technology Alliances tätig und verantwortet technische Partnerschaften im gesamten Produktportfolio von F5. Seit 2019 spielt er zudem eine zentrale Rolle bei Initiativen zur Unternehmensstrategie und war unter anderem an der Einführung des ersten Innovationsprojekts von F5 beteiligt. Paul leitete das Tiger-Team für die KI-Strategie von F5, das sich mit der Frage befasste, wie die bestehenden Produkte von F5 zur sicheren Bereitstellung von KI-Anwendungen beitragen können. Später wirkte er an der Entwicklung der KI-Referenzarchitektur von F5 mit, die die zentralen Bausteine, Herausforderungen, Risiken und Partnerlösungen beschreibt, die für die Bereitstellung und Absicherung von KI-Anwendungen erforderlich sind. Paul hält regelmäßig Keynotes und Fachvorträge auf Branchenveranstaltungen, darunter der OPI Summit, der OCP Global Summit, Intel InnovatiON, der Open Source Summit, die Red Hat Tech Exchange sowie mehrere VMworld-Konferenzen in den USA und der EMEA-Region. Darüber hinaus ist er Gründer und Maintainer von Open-Source-Projekten, Vorsitzender des Outreach Committee des Open Programmable Infrastructure Project und war zuvor für den Betrieb der Antivirus Response Data Centers und der Testlabore für Sicherheitssoftware von Symantec verantwortlich.
Weitere Blogbeiträge von Paul PindellSandeep Agarwal ist Senior Software Architect bei F5 und verantwortet dort die Kerninfrastruktur und Netzwerksicherheit für hochleistungsfähige verteilte Systeme und KI-Pipelines in Unternehmen. Er treibt Architekturen für KI-Training und -Inferenz mit niedriger Latenz sowie Token-Governance und dynamische KI-Lastverteilung voran. Darüber hinaus ist er für hardwarebeschleunigte Datenpipelines mit eBPF, FPGA-Offloading und DPUs verantwortlich und gibt die architektonische Richtung für Kubernetes, Cloud-native Netzwerkfunktionen und L2–L7-Sicherheit vor. Zuvor war er als Staff Software Engineer bei Juniper Networks, als Senior Principal Software Engineer bei Symantec und als Member of Technical Staff bei Sun Microsystems tätig. Sandeep hat einen Masterabschluss in Computer Engineering von der Oregon State University und einen Bachelorabschluss in Electronics & Communication vom Birla Institute of Technology, Mesra.
Weitere Blogbeiträge von Sandeep AgarwalJonathan Chen ist Softwareentwicklungsarchitekt für SSL Orchestrator bei F5. Dort leitet er die Arbeit an TLS-Interception, Forward-Proxy-Richtlinien und der Verkettung von Diensten für Sicherheitsgeräte von Drittanbietern. Zudem ist er für die Integration von Data Loss Prevention und einer neuen Programmierbarkeits-Laufzeitumgebung in die Datenebene von BIG-IP verantwortlich und gibt für beide Bereiche die Architektur und Roadmap vor. Zuvor war er als US-Architekt bei Trend Micro tätig, mit Schwerpunkt auf der Erkennung und Verhinderung von Sicherheitsverletzungen. Während seiner ersten Zeit bei F5 arbeitete er an leistungsstarken SSL-VPN-Lösungen, Proxys zur Anpassung von Anwendungen, Netzwerkoptimierung und sicheren Web-Gateways. Jonathan besitzt einen Master- und einen Bachelorabschluss mit besonderer Auszeichnung in Informatik von der University of Texas at Austin.
Weitere Blogbeiträge von Jonathan ChenÄhnliche Blogbeiträge
Vier Gründe, warum Sie den F5 Post-Mythos Security Summit nicht verpassen sollten
Holen Sie sich Expertenrat, um Ihre Apps, APIs und Modelle in der Post-Mythos-Welt zu schützen.
Von einer App zu einer ganzen Agentenflotte: Ein 90-Tage-Framework für KI-Sicherheit
Vermeiden Sie den kostspieligen Ansatz „Jetzt bereitstellen, später absichern“ – mit einem umfassenden Framework zum Schutz von KI-Modellen, Anwendungen und autonomen Agenten.
Fünf Stufen antifragiler Cyberresilienz verwandeln Praxis in Ergebnisse
Erfahren Sie, wie fünf Stufen antifragiler Resilienz Störungen in adaptive Verhaltensweisen überführen, die Ausfälle begrenzen und hybride Multicloud-Architekturen stärken.
Warum Ihre KI-Richtlinien, Governance und Leitplanken nicht warten können
KI-Richtlinien und -Governance dürfen nicht länger als reine Formalitäten oder Zukunftsthemen betrachtet werden. Sie müssen durch praktische, durchsetzbare Leitplanken ergänzt werden.
Wenn „privat“ nicht privat ist: Wie ChatGPT-Unterhaltungen öffentlich wurden
KI verändert die Arbeitsabläufe in Unternehmen, doch eine übersehene Einstellung hat bereits Tausende vertraulicher Unterhaltungen öffentlich zugänglich gemacht
KI-Nutzung verstehen: Warum Unternehmen Transparenz brauchen
Anstatt einen zu laxen oder zu strengen Ansatz zu verfolgen, können Unternehmen durch mehr Transparenz bei der KI-Nutzung fundierte und durchsetzbare Entscheidungen treffen.