Warum Ihre KI-Strategie sowohl Shared- als auch Shared-Nothing-Storage benötigt

Da Unternehmen ihre KI-Initiativen vom zentralen Rechenzentrum bis zum Edge skalieren, werden viele Unternehmen durch schwache Datenpraktiken und fragmentierte Systeme ausgebremst. Der Versuch, einen pauschalen Architekturansatz für Workloads mit grundlegend unterschiedlichen Anforderungen zu nutzen, ist keine tragfähige Lösung mehr. Wenn Ihre KI-Ambitionen Ihre Speicherkapazitäten übersteigen, besteht die Lösung nicht einfach darin, mehr Kapazität hinzuzufügen, sondern darin, die richtige Architektur auf die richtige Phase des KI-Lebenszyklus abzustimmen.

Während dies für manche bedeutet, sich zwischen Shared-Everything- und Shared-Nothing-Architekturen entscheiden zu müssen, ist das richtige Portfolio jenes, das tatsächlich beide Ansätze wirksam nutzt.

Nicht alle KI-Workloads sind gleich

Eine KI-Pipeline ist kein einzelner monolithischer Prozess. Es ist ein Pfad, der von der massiven Datenerfassung und dem Modelltraining bis hin zu Echtzeit-Inferenz und lokalisierten Aktionen reicht. Jede Phase stellt andere Anforderungen an die Infrastruktur eines Unternehmens:

• Modelltraining (der Kern): Dies erfordert massive Parallelität und eine Single Source of Truth. Hier bleibt Shared Storage (d. h. Shared-Everything) eine bewährte architektonische Wahl. Dadurch wird sichergestellt, dass Tausende von GPUs gleichzeitig auf denselben Datensatz zugreifen können, ohne dass der Mehraufwand für Daten-Sharding anfällt. Dies verhindert I/O-Starvation und sorgt für eine kontinuierlich hohe Auslastung der Rechenressourcen.
• Echtzeit-Inferenz (der Edge-Bereich): Sobald ein Modell trainiert ist, muss es dort bereitgestellt werden, wo die Daten generiert werden. Hier zeichnet sich die Shared-Nothing-Architektur aus. Indem jedem Knoten eine eigene CPU sowie eigener Arbeitsspeicher und Speicher zugewiesen werden, wird die Netzwerkkoordination minimiert. Das Ergebnis sind die Reaktionszeiten im Sub-Millisekundenbereich, die für Betrugserkennung in Echtzeit, autonome Systeme oder personalisierte Kundeninteraktionen erforderlich sind.

Der Preis einer Pauschalarchitektur

Was passiert, wenn Unternehmen versuchen, den gesamten Lebenszyklus in eine einzige Architektur zu zwängen? Die Kosten bleiben oft unbemerkt, bis sie sich auf das Betriebsergebnis auswirken:

• Verschwendete GPU-Ausgaben: Wenn man sich im Core-Bereich ausschließlich auf Shared-Nothing verlässt, verbringen GPUs mehr Zeit damit, auf das Sharding und die Synchronisierung von Daten zu warten, als mit der eigentlichen Verarbeitung. Da GPU-Zeit derzeit extrem kostspielig ist, wird durch diese I/O-Wartezeit im Grunde Geld verbrannt.
• Der „stumme“ Edge-Bereich: Umgekehrt führt der Rückgriff auf zentralisierten Shared Storage für Edge-Inferenz zu einem Single Point of Failure. Wenn die Netzwerkverbindung zum Core ins Stocken gerät, fällt Ihre Echtzeit-KI aus. Dadurch entstehen „stumme“ Standorte, die nicht autonom arbeiten können, was zu verpassten Chancen und betrieblichen Ausfallzeiten führt.
• Architekturschulden: Die Skalierung von KI auf dem falschen Fundament führt später zu kostspieligen Forklift-Upgrades. Bis Teams erkennen, dass die Architektur die Parallelität nicht bewältigen kann, sind die Anwendungen oft schon darauf aufgebaut.

Die Vorteile einer Dual-Architektur-Strategie

Sich auf einen einzigen Anbieter zu stützen, der sowohl Shared-Nothing- als auch Shared-Everything-Architekturen anbietet, bietet einen strategischen Vorteil, der weit über reine Hardwarespezifikationen hinausgeht.

1. Workload-spezifische Optimierung

Indem Sie Shared Storage im Core-Bereich für das Training und Shared-Nothing für lokalisierte Microservices oder NoSQL-Datenbanken nutzen, optimieren Sie die Leistung auf jeder Ebene. Diese Hybridisierung ermöglicht es Ihnen, hocheffiziente Data Lakehouses aufzubauen, bei denen Speichereinfachheit auf Scale-out-Computing trifft. 

2. Vorhersehbare Skalierung und Ausfallsicherheit

Shared-Nothing-Konzepte ermöglichen eine lineare Skalierung von Kapazität und Leistung am Edge. Fällt in einer Shared-Nothing-Umgebung ein Knoten aus, wird der Ausfall isoliert, und eine automatisierte Wiederherstellung stellt sicher, dass die übergeordnete Umgebung unbeeinträchtigt bleibt.

3. Operative Flexibilität

Ein Dual-Architektur-Ansatz vermeidet die Falle von Forklift-Upgrades. Sie können für frühe Projektphasen mit unabhängigen Shared-Nothing-Bereitstellungen auf Standard-Hardware beginnen und zu Shared Arrays übergehen, sobald die Metadatenverwaltung komplexer wird. Diese Art von Flexibilität deckt sich auch mit den allgemeinen Vorteilen von Hybrid-Cloud-Speicher in puncto Zugänglichkeit, Sicherheit und Kosteneffizienz, wie CDW in seiner Übersicht über die Vorteile von Hybrid-Cloud-Speicher hervorhebt.

Shared-Everything- und Shared-Nothing-Architekturen in der Praxis

Denken Sie an ein weltweit agierendes Einzelhandelsunternehmen, das KI nutzt, um das Einkaufserlebnis zu revolutionieren. Dessen Vorhaben erfordert zwei unterschiedliche architektonische Stärken:

1. Im Core (Shared Storage): Der Einzelhändler fasst Milliarden von historischen Transaktionen und Kundenverhaltensdatenpunkten in einem zentralen Data Lake zusammen. Er verwendet VSP One Block- und File-Storage, um einen massiven GPU-Cluster zu speisen, der eine hochentwickelte Recommendation Engine trainiert. Da der Datensatz vereinheitlicht ist, können die GPUs Daten direkt verarbeiten, anstatt darauf warten zu müssen, dass sie verschoben oder synchronisiert werden.

2. Am Edge (Shared-Nothing): Sobald das Modell trainiert ist, wird es an Tausende einzelner Filialen verteilt. Jede Filiale betreibt eine eigene lokalisierte Instanz auf VSP One SDS. Wenn ein Kunde die Filiale betritt, verarbeitet das System Live-Video-Feeds und Sensordaten direkt vor Ort, um Bestandsbenachrichtigungen in Echtzeit sowie personalisierte mobile Angebote bereitzustellen. Sollte die Netzwerkverbindung zur Zentrale unterbrochen werden, bleibt die Filiale dennoch intelligent, da ihre Shared-Nothing-Architektur vollständige lokale Autonomie gewährleistet.

Wie VSP One die KI-Entwicklung orchestriert

Das Portfolio der Hitachi Virtual Storage Platform One (VSP One) wurde speziell entwickelt, um eine Brücke zwischen diesen Architekturwelten zu schlagen, sodass Sie immer das richtige Werkzeug für die jeweilige Aufgabe bereitstellen können:

• VSP One SDS (Software-defined Storage): Wendet Shared-Nothing-Prinzipien auf Standard-x86- und Hybrid-Cloud-Umgebungen an. Es ist die ideale Wahl für Echtzeit-Inferenz, Edge-Computing und unternehmenskritische Fehlerisolation, bei der Autonomie auf Knotenebene sicherstellt, dass lokale Ausfälle die globale Datenverfügbarkeit niemals beeinträchtigen.
• VSP One Object: Das Fundament für das KI-Data-Lakehouse. Es bietet die enorme, kostengünstige Skalierbarkeit, die für die Erfassung und Speicherung der riesigen Mengen unstrukturierter Daten erforderlich ist, die die Modellentwicklung antreiben.
• VSP One File und Block: Diese bieten die hochleistungsfähigen Shared-Tiers mit niedriger Latenz, die für die rechenintensiven Aufgaben des Modelltrainings erforderlich sind. Insbesondere VSP One File zeichnet sich dadurch aus, dass es den Zugriff mit hohem Durchsatz bietet, den moderne KI-Frameworks verlangen.
• VSP 360: Als Schaltzentrale des Betriebs bietet VSP 360 einheitliches Management und AIOps-gestützte Einblicke über Shared- sowie Shared-Nothing-Bereitstellungen hinweg und liefert so eine zentrale Managementkonsole (Single Pane of Glass) für Ihre gesamte Hybrid-Cloud-Infrastruktur.

Die Architektur entscheidet über KI-Ergebnisse

Die Speicherherausforderung, die KI im großen Maßstab einschränkt, ist architektonischer und nicht inkrementeller Natur. Für den Erfolg bedarf es der Flexibilität, Shared Storage dort einzusetzen, wo Konsistenz erforderlich ist, und Shared-Nothing-Storage dort, wo es auf Geschwindigkeit und Autonomie ankommt.

Sind Sie bereit, die richtige Architektur für Ihre Umgebung zu evaluieren? Erfahren Sie mehr über das VSP One-Portfolio, das eine echte Shared-Nothing-Block-Architektur für KI und Datenbanken bietet.