Sicherstellen, dass ausreichend Rechenleistung vorhanden ist, ohne dass der Speicher zum versteckten Flaschenhals wird
KI-Training, Inferenz, Simulation und Analyse bewegen Daten auf sehr unterschiedliche Weise. Die richtige Architektur bietet ein ausgewogenes Verhältnis zwischen dauerhaftem Durchsatz, Metadaten-Reaktionsfähigkeit, Checkpoint-Schreibvorgängen, Kapazitätserweiterung und Wiederherstellung – anstatt eine Architektur anhand eines einzelnen Benchmarks auszuwählen
Jede Lane für ihr eigenes Parallelitäts-, Schutz- und Wachstumsverhalten entwerfen
Beginnen Sie mit der Art und Weise, wie die Anwendung Daten verschiebt
Kapazität und Bandbreite geben keine Auskunft über Dateianzahl, Wiederverwendung, Parallelität, Prüfpunktfrequenz oder die Kosten eines blockierten Rechenknotens
Viele Worker werden wiederholt gefüttert
- Parallele Leser greifen über viele Epochen hinweg auf große Datensätze zu
- Millionen kleiner Stichproben können zu einer Namensraum- und Metadaten-Workload führen
- Checkpoint-Schreibvorgänge konkurrieren mit Lesevorgängen im Vordergrund, sofern diese nicht separat geplant sind
Modelle, Indizes und Live-Daten mischen
- Das Laden von Modellen ist nur ein Teil des Servicepfads
- Vektordatenbanken, Dokumentensammlungen und Objektdaten können unterschiedliche Speicherzugriffe verwenden
- Die Latenz am Ende des Prozesses kann wichtiger sein als die maximale Übertragungsgeschwindigkeit
Langlaufende Berechnungen schützen
- Gemeinsam genutzte Dateien, temporäre Ergebnisse und Checkpoint-/Neustart-Datenverkehr können stoßweise auftreten
- Verzeichnisoperationen und kleine Dateien können Workflows einschränken, die keinem Bandbreitentest entsprechen
- Die Wiederherstellungszeit muss die Datenvalidierung und den Neustart des Jobs umfassen
Scannen, Transformieren und Aufbewahren
- Große Scans und parallele Pipelines verbrauchen kontinuierliche Bandbreite
- S3 und der Zugriff auf gemeinsam genutzte Dateien eignen sich für unterschiedliche Anwendungsökosysteme
- Richtlinien für die Datenerfassung, -transformation und -aufbewahrung beeinflussen die nutzbare Kapazität
Anforderungen vor Plattformwahl trennen
Worker mit Daten versorgen
Gleichzeitige Lesevorgänge, Wiederverwendung, Stichprobengröße und Vorverarbeitungseffekte messen – nicht nur einen einzelnen sequenziellen Datenstrom
Metadaten-Reaktionsfähigkeit schützen
Dateierstellung, -suche, Verzeichnisnavigation und Berechtigungen können Workflows mit vielen kleinen Dateien dominieren
Schreiben ohne Job-Blockierung
Checkpoint-Größe, -Intervall, -Aufbewahrungsdauer und gleichzeitiges Schreiben mehrerer Worker definieren
Datenbanken und Protokolle nicht außer Acht lassen
Scheduler, Kataloge, Vektordatenbanken und Telemetrie benötigen neben großen Datenmengen oft vorhersehbare geringe I/O-Latenzen
Ein sinnvoller Test bildet die gesamte Pipeline nach: Datenladen, Vorverarbeitung, Worker-Parallelität, Checkpointing, Hintergrundschutz und eingeschränkter Betrieb sollten gemeinsam gemessen werden
Passen Sie den Datenpfad an die Anwendungsschnittstelle an
Kein Transport ist automatisch optimal für KI oder HPC. Die Anwendung, das Betriebssystem und das Datenlayout müssen den Pfad effektiv nutzen können
| Datenpfad | Passt oft | Potenzieller Vorteil | Vor dem Einsatz validieren |
|---|---|---|---|
| Lokales NVMe | Knotenlokaler Cache, Scratch-Speicher und Staging | Sehr kurzer E/A-Pfad und hohe lokale Bandbreite | Datensatzverteilung, Knotenausfall, Rehydratisierung, Konsistenz und Kapazitätsduplizierung |
| NVMe über RDMA | Latenzempfindlicher Zugriff auf gemeinsam genutzte Blöcke und qualifizierte Hochleistungs-Fabrics | Geringer Transportaufwand und effizienter Remote-NVMe-Zugriff | RoCE/RoCEv2 oder InfiniBand Design, Adapter, Switches, Multipathing, Topologie- und Anwendungsunterstützung |
| NVMe über TCP | Gemeinsamer Blockspeicher in bekannten gerouteten IP-Netzwerken | NVMe-Semantik mit allgemein verständlichen Ethernet-Operationen | CPU-Auslastung, Überlastung, Warteschlangendesign, Host-Unterstützung und Latenz bei realer Workload |
| NFS oder SMB | Gemeinsame Datensätze, Modell-Repositories und kollaborative Workflows | Gemeinsame Dateischnittstelle und zentral verwalteter Namensraum | Client-Parallelität, Metadatenrate, Sperrung, Caching und anwendungsspezifische Unterstützung |
| S3-kompatibles Objekt | Data Lakes, Trainingskorpora, Modellartefakte, Archiv- und Pipeline-Austausch | API-basierte Skalierung, unabhängige Clients und flexible Kapazitätsstufen | Anwendungsunterstützung für S3, Objektgröße, Anforderungsrate, Konsistenzerwartungen und lokales Caching |
Block-, Datei- und Objektspeicher ergänzen sich: Ein gängiges Muster verwendet S3 für dauerhafte Datensätze, gemeinsamen Dateizugriff für aktive Zusammenarbeit und Blockspeicher für Datenbanken oder latenzempfindliche Anwendungsvolumes
RDMA impliziert keinen direkten Zugriff auf GPU-Speicher
NVMe über RDMA ermöglicht effizienten Remote-Speicherzugriff über ein RDMA-Fabric. Technologien, die Daten direkt zwischen Speicher und GPU-Speicher übertragen, erfordern einen separaten, vollständig qualifizierten Software- und Hardware-Stack
Klarer Anwendungsbereich: Die auf dieser Website beschriebenen Funktionen von euroNAS, NVMe-oF und RDMA dürfen nicht als validierte NVIDIA GPUDirect-Unterstützung für Storage interpretiert werden. Direkte Übertragungen in den GPU-Speicher werden nicht als Funktion von euroNAS dargestellt
Qualifizierte RDMA-Projekte können NVIDIA/Mellanox-Adapter und Enterprise-Server von Anbietern wie Supermicro oder HPE verwenden. Die erforderlichen Firmware-, Treiber-, Netzwerkkarten-, Switch- und PCIe-Kombinationen müssen für jede Implementierung überprüft werden
Große Datensätze können durch sehr kleine Operationen weiterhin eingeschränkt sein
KI- und HPC-Workflows kombinieren häufig große Datenmengen mit Dateiabfragen, Verzeichnisscans, Scheduler-Datenbanken und Objektmetadaten
Dateisystemmetadaten
Ein separater CephFS-Metadatenpool enthält Namespace-Informationen wie Dateinamen, Verzeichnisse und Berechtigungen. Die Platzierung dieses latenzempfindlichen Pools auf schnellen SSD- oder NVMe-Medien kann metadatenintensive Workflows verbessern, während große Dateidaten auf Speichermedien mit hoher Kapazität verbleiben
Besonders relevant für- Viele kleine Trainingsbeispiele
- Große Verzeichnisstrukturen
- Häufige Erstellungs-, Lösch- und Suchvorgänge
Platzierung der OSD-Datenbank/WAL
Bei Ceph-OSDs mit Festplattenunterstützung kann die interne Datenbank- und Write-Ahead-Log-Aktivität von deutlich schnelleren Speichermedien profitieren. Dies beschleunigt die interne Objektmetadatenverarbeitung und ist eine separate Entscheidung unabhängig vom CephFS-Metadatenpool
Besonders relevant für- Kapazitätsorientierte HDD-Knoten
- Gemischte Objekt- und Dateiaktivität
- Designs, die eine reaktionsschnelle Metadatenverarbeitung erfordern
Klare Unterscheidung beachten: DB/WAL beschleunigt interne OSD-Arbeiten; der Metadatenpool CephFS dient Dateisystem-Namespace-Operationen. eEKAS bietet beide Optionen über geführte grafische Workflows, ohne dass Kenntnisse der Ceph-Befehlszeile erforderlich sind
Verwaltung der verteilten Schicht ohne Befehlsblockade
eEKAS bietet grafische Workflows für die Clustererstellung, Laufwerksauswahl, Schutzprofile, DB/WAL-Platzierung, Dateisystemmetadaten und Service-Endpunkte. Administratoren benötigen für die routinemäßige Bereitstellung und Überwachung keine Vorkenntnisse in Ceph oder der Befehlszeile
euroNAS-Plattformen als Implementierungsbeispiele verwenden
Das geeignete Modell hängt von Skalierung, Fehlergrenzen, Anwendungsschnittstellen und Betriebsverantwortung ab
Fokussierter Hochleistungsspeicher
Ein dediziertes Speichersystem für eine kompakte Umgebung mit dem erforderlichen Block- oder Dateizugriff. Verfügbarkeit und vollständige Serverwiederherstellung müssen durch das umgebende Design gewährleistet werden
- NVMe-oF, iSCSI, Fibre Channel oder Dateidienste je nach Host-Unterstützung
- Kann auch als Virtual Storage Appliance bereitgestellt werden
- Geeignet, wenn kein Scale-Out-Speicher erforderlich ist
Zwei-Knoten-Speicherverfügbarkeit
Ein lokales Zwei-Knoten-Design für gemeinsam genutzte Block- oder Dateidienste, die ein automatisches Speicher-Failover erfordern, entweder mit einem synchronen Spiegel oder mit zwei Controllern mit gemeinsam genutztem Speicher
- Multipath-Zugriff für unterstützte Blockprotokolle
- Synchrone lokale Kontinuität und separate asynchrone Wiederherstellungsoptionen
- Optimal für eine definierte lokale Skalierung anstatt verteilter Erweiterung
Unabhängige Scale-Out-Datenplattform
Verteilter Speicher für große gemeinsam genutzte Datensätze und mehrere Verbrauchergruppen, der Block-, Datei- und S3-Dienste bereitstellt, während Kapazität und Leistung über qualifizierte Knoten
- Ceph-Schutz über definierte Fehlerdomänen hinweg
- Replikation oder Erasure Coding je nach Workload
- Grafische DB/WAL- und Metadatenplatzierung
Virtuelle Dienste rund um die Datenpipeline
eEVOS kann die unterstützenden virtuellen Dienste rund um eine KI- oder Analyseumgebung hosten und sich mit internem, externem gemeinsam genutztem oder Ceph-Speicher verbinden. Die Anforderungen des Beschleunigers müssen separat validiert werden
- VM-Hochverfügbarkeit und Live-Migration
- Integriertes Backup & Disaster Recovery
- Instant Backup & Recovery für geschützte virtuelle Workloads
Fragen, die den wahren Engpass aufdecken
Wie viele Dateien oder Objekte existieren, wie groß sind sie und wie oft werden sie wiederverwendet?
Wie viele Worker lesen und schreiben gleichzeitig und greifen sie auf dieselben Daten zu?
Wie groß sind Checkpoints, welches Intervall wird festgelegt, wie lange werden sie aufbewahrt und wann ist ein Neustart zulässig?
Welche Treiber, Bibliotheken, Dateisysteme, Blockgeräte und S3-Schnittstellen werden von der Anwendung unterstützt?
Welcher Durchsatz ist bei einem Knotenausfall, -neuaufbau oder Datenausgleich akzeptabel?
Wachsen Kapazität, Rechenknoten und Clientanzahl gemeinsam oder müssen sie unabhängig skaliert werden?
Unabhängige technische Beratung
Validieren Sie das endgültige Design anhand der aktuellen Anwendungs-, Transport- und Speicherdokumentation
NVM Express: NVMe über RDMA
Offizielle Beschreibung des RDMA-Transports für die Datenübertragung zwischen Computer und Speicher über ein Fabric
Open NVM Express-Anleitung →CephFS-Architektur
Ceph-Dokumentation, die separate Dateidaten- und Metadatenpools sowie deren Rolle im Betrieb gemeinsam genutzter Dateisysteme beschreibt
Ceph-Dokumentation öffnen →Datenpipeline einbringen – nicht nur die Kapazitätsangaben
Wir können Datensatzstruktur, Parallelverarbeitung, Netzwerkoptionen, Metadatenverhalten, Checkpointing, Ausfallsicherheit und Wachstum für ein KI-, HPC- oder Analyseprojekt im Business-Bereich überprüfen