your123 - stock.adobe.com
Entscheidungshilfe: SAN oder NAS für KI, VMs und Container
Wir vergleichen Block- und Dateispeicher für moderne Workloads. Oft geht es im Wesentlichen um einen Kompromiss zwischen Kosten, Komplexität und Leistungsniveau, der zur Firma passt.
SAN und NAS sind unterschiedliche Möglichkeiten, Speicher bereitzustellen. Sie unterscheiden sich auf grundlegenden Ebenen der Speicherarchitektur, entsprechend ihrer Beziehung zum Dateisystem sowie Block- und physischer Adressierung, aber auch dem Netzwerk (oder der Fabric), über das Input/Output (I/O) läuft.
Hier betrachten wir die wichtigsten Unterschiede in der Performance und die Anwendbarkeit zwischen Block- und Dateispeicher, mit Fokus auf moderne Workloads wie künstliche Intelligenz (KI), virtuelle Maschinen und containerisierte Umgebungen.
Den Unterschied zwischen Network Attached Storage (NAS) – also Dateispeicher – und Storage Area Network (SAN) – bekannt als Blockspeicher – kann man so beschreiben, dass sie zwei Wege bieten, auf gespeicherte Daten zuzugreifen.
In beiden Fällen ist Dateisystem erforderlich, das zwischen der Anwendung, die die Daten anfordert, und den Daten in ihrem physischen Speicher vermittelt. Wo die beiden Methoden sich unterscheiden, ist, wie das umgesetzt wird.
In NAS-Systemen sind Dateisystem und Speicher im selben Gehäuse gebündelt. Benutzer und Anwendungen fordern Daten zum Beispiel von einem buchstabenbasierten Laufwerk an, wie dem C:-Laufwerk, das üblicherweise auf PCs referenziert wird. Die Anforderung geht ans Dateisystem im NAS-Gerät, wird in physische Adressierung übersetzt, und die Datei wird abgerufen.
In SAN-Systemen wird die Arbeit des Dateisystems woanders erledigt. Die Anwendung oder Datenbank fordert Daten an, wobei die Kommunikation außerhalb des SAN in physische Adressierung übersetzt wird, und Daten werden in Blöcken abgerufen.
Hier liegt der Hauptunterschied, und wie der Name suggeriert, präsentiert Dateispeicher ganze Dateien, während Block-Speicher Blöcke liefert.
Welche Performance-Folgen haben NAS und SAN?
NAS-Server führen alle ihre Dateisystem-Verarbeitung intern durch. Sie kommunizieren auch mit Clients über Protokolle wie SMB und NFS im Standard-IP-Netzwerk. Aus diesen Gründen sind sie generell weniger leistungsfähig als ein SAN-Speicher.
SANs müssen nicht mit diesem Verarbeitungsaufwand umgehen und werden oft mit den besten Netzwerkverbindungen ausgestattet, einschließlich dedizierter Hochgeschwindigkeitsnetzwerke – oder Fabrics im korrekten SAN-Jargon – wie Fibre Channel (FC).
Aus diesen Gründen war NAS historisch die erste Wahl für Dateizugriffe auf Abteilungsebene, während SAN für Performance-hungrige Arbeiten wie Transaktionsverarbeitung bevorzugt wurde.
Beide können jedoch für moderne Workloads wie KI, containerisierte Anwendungen und virtuelle Maschinen (VMs) genutzt werden – und tatsächlich können sehr performante und skalierbare Dateizugriffsspeichersysteme aus Scale-out-NAS-Hardware aufgebaut werden.
SAN vs. NAS für KI
SANs bieten die beste Performance insgesamt, und das wirkt sich auch auf KI-Workloads aus. Hohe IOPS, geringe Latenz und schneller Throughput – besonders unter Verwendung von NVMe-over-Fabrics – können hungrige GPU-Cluster versorgen, die anhaltende Bandbreite benötigen. Das ist besonders nützlich für Performance-fordernde Datensätze in Formaten wie TFRecord, Parquet und LMDB, zum Beispiel.
SANs übertreffen bei Hochgeschwindigkeits-Parallel-Schreibvorgängen mit weniger Protokoll-Overhead als NAS-Systeme und bringen in der Regel fortschrittliche Multipathing- und Quality-of-Service-(QoS)-Mechanismen mit. SANs eignen sich gut für Model-Checkpointing.
Der Nachteil von SANs für KI-Workloads ist, dass sie relativ teuer und komplex sind und Fachkentnisse in SAN-Management und NVMe-over-Fabrics verlangen, die nicht immer verfügbar sind.
Offensichtlich braucht Ihr KI-Stack auch eine Dateisystem-Schicht wie Lustre, GPFS oder BeeGFS.
NAS bietet einfacheres Datei-Sharing über mehrere Compute Nodes und bessere Metadaten-Handhabung als SAN. Der Vorteil von NAS bei KI-Workloads ist die Inferenz, wo Performance-Anforderungen wahrscheinlich etwas weniger extrem sind als beim Training. Generell ist es einfacher einzurichten als ein SAN.
I/O-Overheads wie die Handhabung von SMB/NFS-Protokollen können zu langsameren Throughput führen, während NAS-Systeme bei großen sequentiellen Lesevorgängen, beim Schreiben von Checkpoints und beim Umgang mit Datensätzen mit Millionen kleiner Dateien an ihre Grenzen kommen können.
SAN vs. NAS für virtuelle Server
SAN-Speicher kann erfolgreich für eine Reihe von Hypervisoren eingesetzt werden, wobei VMware ESXi, Hyper-V und KVM alle Block-Speicher nutzen können – allerdings über unterschiedliche Protokolle –, um virtuelle Festplatten zu speichern.
Mit hoher Performance über Netzwerk/Fabric eignen sich SANs gut für VMs, die transaktionale I/Os für SQL-Server und darauf angewiesene Anwendungen wie ERP benötigen.
Block-Speicher ist ideal für mehrere VMs, die gleichzeitig auf schwere Workloads zugreifen müssen. SANs offerieren generell fortschrittliche Speicherdienste wie Thin Provisioning, Snapshots, Replikation und High-Availability-(HA)-Controller-Failover.
Wie bei jeder Workload sind die Nachteile von SAN seine Kosten, Komplexität und höheren Anforderungen an den Administrator.
NAS-Systeme können VM-Workloads ebenfalls unterstützen, mit Hypervisoren, die über NFS (VMware, KVM) oder SMB3 (Hyper-V) mounten, und VM-Images auf NFS speichern sowie Anwendungsdaten über SMB/NFS teilen.
Nochmals zeigen sich die Stärken und Schwächen von SAN und NAS bei VM-Workloads: Einfachheit und relativ niedrigere Performance bei NAS, Performance und relative Komplexität bei SAN.
SAN vs. NAS für containerisierte Workloads
Block-Speicher punktet ebenso bei der Performance für containerisierte Workloads, die Datenbanken in Containern ausführen – wie PostgreSQL, MySQL und MongoDB – oder KI-Trainingsdatensätze und Checkpoints in Pods.
Hohe IOPS und niedrige Latenz zeichnen SANs aus, und sie funktionieren gut mit Hoch-Throughput-Sequentiellen oder Random-I/Os. Die meisten SAN-Hardware-Produkte unterstützen Snapshots, Cloning und Replikation.
Ein Nachteil ist, dass Standard-Block-Geräte nicht gleichzeitig über Nodes via ReadWriteMany gemountet werden können – eine Funktion von Kubernetes Persistent Volumes –, ohne ein Clustered Dateisystem oder CSI-Treiber, die die Attach/Detach-Logik richtig handhaben müssen.
SANs sind kostspielig und können für leichte oder ephemere Container-Workloads überdimensioniert sein.
NAS-Speicher kann über Kubernetes Persistent Volumes eingebunden werden, die auf NFS oder SMB basieren, wobei häufig ein CSI-Treiber zum Einsatz kommt. NAS unterstützt ReadWriteMany nativ, im Gegensatz zu den meisten Block-Speichern, sodass mehrere Pods über Nodes auf dasselbe Volume gleichzeitig zugreifen können.
Wie üblich ist NAS einfacher zu provisionieren und skalieren als SAN, während Protokoll-Overhead (NFS, SMB) den Throughput reduzieren und Flaschenhälse auftreten können, wenn mehrere Pods große Dateien gleichzeitig lesen oder schreiben.
Dieser Artikel ist im Original in englischer Sprache auf Computerweekly.com erschienen.
