Diese Referenzarchitektur nutzt separate Fabrics für den Compute-Cluster-Interconnect- und Storage-Zugriff, wobei die InfiniBand (IB) mit 400 GB/s zwischen den Computing-Nodes verbunden ist. Die Abbildung unten zeigt die allgemeine Lösungstopologie von NetApp AIPod mit DGX H100 Systemen.

NetApp AIPOD-Lösungstopologie

In dieser Konfiguration verwendet die Computing-Cluster-Fabric ein Paar QM9700-400-GB/s-IB-Switches, die miteinander verbunden sind, um Hochverfügbarkeit zu gewährleisten. Jedes DGX H100-System ist über acht Verbindungen mit den Switches verbunden, wobei die Ports mit geraden Nummern mit einem Switch verbunden sind und die Ports mit ungeraden Nummern mit dem anderen Switch verbunden sind.

Für den Zugriff auf das Speichersystem, das bandinterne Management und den Client-Zugriff wird ein Paar SN4600 Ethernet-Switches verwendet. Die Switches sind mit Verbindungen zwischen Switches verbunden und mit mehreren VLANs konfiguriert, um die verschiedenen Datenverkehrstypen zu isolieren. Bei größeren Implementierungen kann das Ethernet-Netzwerk nach Bedarf durch zusätzliche Switch-Paare für Spine-Switches und zusätzliche Leaves zu einer Leaf-Spine-Konfiguration erweitert werden.

Neben dem Compute Interconnect und High-Speed-Ethernet-Netzwerken sind alle physischen Geräte zur Out-of-Band-Verwaltung auch mit einem oder mehreren SN2201 Ethernet-Switches verbunden. Weitere Informationen zur Konnektivität des DGX H100-Systems finden Sie im "NVIDIA BasePOD-Dokumentation".

Jedes DGX H100-System verfügt über zwei Dual-Port-ConnectX-7-Adapter für Management- und Storage-Datenverkehr. Bei dieser Lösung werden beide Ports auf jeder Karte mit demselben Switch verbunden. Ein Port von jeder Karte wird dann in einer LACP MLAG-Verbindung konfiguriert, wobei ein Port mit jedem Switch verbunden ist. VLANs für in-Band-Management, Client-Zugriff und Speicherzugriff auf Benutzerebene werden auf dieser Verbindung gehostet.

Der andere Port auf jeder Karte wird für die Verbindung zu den AFF A900 Storage-Systemen verwendet und kann je nach Workload-Anforderungen in mehreren Konfigurationen verwendet werden. Bei Konfigurationen, die NFS over RDMA zur Unterstützung von NVIDIA Magnum IO GPUDirect Storage verwenden, werden die Ports in einer aktiv/Passiv-Verbindung konfiguriert, da RDMA auf keinem anderen Bond-Typ unterstützt wird. Für Implementierungen, die kein RDMA erfordern, können die Storage-Schnittstellen auch mit LACP Bonding konfiguriert werden, um Hochverfügbarkeit und zusätzliche Bandbreite zu gewährleisten. Mit oder ohne RDMA können Clients das Storage-System mit pNFS und Session-Trunking für NFS v4.1 mounten, um parallelen Zugriff auf alle Storage Nodes im Cluster zu ermöglichen.

Jedes AFF A900 Storage-System ist über vier 100 GbE-Ports von jedem Controller verbunden. Zwei Ports von jedem Controller werden für den Workload-Datenzugriff aus den DGX-Systemen verwendet. Zwei Ports von jedem Controller werden als LACP-Schnittstellengruppe konfiguriert, um den Zugriff über die Server der Managementebene für Cluster-Managementartefakte und Benutzer-Home Directorys zu unterstützen. Der gesamte Zugriff auf die Daten aus dem Storage-System erfolgt über NFS, wobei eine Storage Virtual Machine (SVM) dediziert für den KI-Workload-Zugriff und eine separate SVM für das Cluster-Management vorgesehen ist.

Die Workload-SVM ist mit insgesamt acht logischen Schnittstellen (LIFs) konfiguriert, wobei zwei LIFs an jedem physischen Port vorhanden sind. Diese Konfiguration bietet maximale Bandbreite sowie die Möglichkeit für jede LIF ein Failover auf einen anderen Port desselben Controllers, sodass bei einem Netzwerkausfall beide Controller weiterhin aktiv bleiben. Diese Konfiguration unterstützt auch NFS über RDMA, um den GPUDirect-Storage-Zugriff zu aktivieren. Die Storage-Kapazität wird in Form eines einzigen großen FlexGroup Volume bereitgestellt, das alle Storage Controller im Cluster umfasst und 16 zusammengehörige Volumes auf jedem Controller enthält. Auf diese FlexGroup kann über alle logischen Schnittstellen auf der SVM zugegriffen werden. Mithilfe von NFSv4.1 mit pNFS und Session-Trunking richten Clients Verbindungen zu allen logischen Schnittstellen in der SVM ein. Dadurch können parallel auf die Daten der einzelnen Storage-Nodes zugegriffen werden, um die Performance erheblich zu steigern. Die Workload-SVM und jede DatenLIF sind zudem für den RDMA-Protokollzugriff konfiguriert. Weitere Informationen zur RDMA-Konfiguration für ONTAP finden Sie im "ONTAP-Dokumentation".

Die Management SVM benötigt nur eine einzelne LIF, die sich auf den auf jedem Controller konfigurierten 2-Port-Schnittstellengruppen befindet. Andere FlexGroup Volumes werden auf der Management-SVM bereitgestellt, um Artefakte im Cluster-Management wie Cluster-Node-Images, Systemüberwachungsdaten und Home Directories der Endbenutzer zu beherbergen. Die nachfolgende Abbildung zeigt die logische Konfiguration des Storage-Systems.

NetApp A900 logische Konfiguration des Storage-Clusters

Diese Referenzarchitektur enthält außerdem fünf CPU-basierte Server für die Nutzung der Verwaltungsebene. Zwei dieser Systeme werden als Hauptknoten für NVIDIA Base Command Manager für die Cluster-Implementierung und -Verwaltung verwendet. Die anderen drei Systeme werden verwendet, um zusätzliche Cluster-Services wie Kubernetes-Master-Nodes oder Login-Nodes für Implementierungen bereitzustellen, die Slurm für die Jobplanung verwenden. Implementierungen mit Kubernetes können den NetApp Astra Trident CSI-Treiber nutzen, um automatisierte Bereitstellung und Datenservices mit persistentem Storage für Management- und KI-Workloads auf dem AFF A900 Storage-System bereitzustellen.

Jeder Server ist physisch mit den IB-Switches und Ethernet-Switches verbunden, um Cluster-Implementierung und -Management zu ermöglichen. Er ist zur Speicherung von Clustermanagement-Artefakten wie oben beschrieben mit NFS-Mounts zum Storage-System konfiguriert.