Die Datenserver sind speziell für Novus entwickelte ONTAP Cluster. Sie implementieren die Novus Datenebene, speichern Dateidaten und stellen sie den NFS-Clients zur Verfügung. Ein Novus Namespace kann seine Dateidaten auf mehrere ONTAP Cluster verteilen; ein Cluster kann viele verschiedene Namespaces bedienen. Diese Flexibilität ermöglicht es, Kapazität und Performance durch das bedarfsgerechte Hinzufügen von Datenservern zu erweitern.

Clients greifen mit einem Standard NFS-Client auf die ONTAP Datenserver zu, ohne dass eine benutzerdefinierte NetApp Software erforderlich ist. Nachdem ein Client vom Novus Data Director ein Dateilayout erhalten hat, kann er Dateidaten direkt auf den ONTAP Datenservern über NFSv3 und optional über RDMA lesen und schreiben. Große Datenmengen werden nie über den Novus Data Director geleitet, sodass der Datenverkehr parallel über die Datenserver verläuft.

Die Datenserver nehmen nicht an der Verwaltung des Namespace teil. Sie speichern die Daten jeder Datei als Backing-Dateien in ONTAP Volumes. Ein ONTAP Datenserver verwaltet die Novus Namespace-Metadaten nicht, etwa die Verzeichnisstruktur oder wie Dateien per Striping über Datenserver verteilt werden.

Das AFF A90 für NetApp Novus ist eine Version des AFF A90, die für Novus mit ONTAP entwickelt wurde. Zu den Merkmalen gehören:

Standard ONTAP Cluster können nicht als Novus-Datenserver verwendet werden; nur speziell für Novus entwickelte Plattformen werden unterstützt.

Der Novus Data Director (NDD) ist eine Implementierung der Rolle des Metadatenservers (MDS) in der pNFS-Architektur und stellt die Novus Metadaten-Ebenen bereit. Ein MDS host ist ein physischer Server, auf dem Linux sowie die MDS-Protokoll-Services und Metadatenspeicher ausgeführt werden.

Das NDD präsentiert den Clients jeden Namespace als ein einzelnes Dateisystem. Es verwaltet die Namespace-Metadaten: Dateien und Verzeichnisse, Dateiattribute, die Zuordnung, wo die Daten jeder Datei gespeichert sind, sowie den Protokollstatus, der zur Koordination des Clientzugriffs erforderlich ist. Clients hängen einen Namespace über seine virtuelle IP-Adresse ein und kommunizieren mit dem NDD über NFSv4.2 mit parallel NFS (pNFS). Das NDD verarbeitet alle Metadatenoperationen wie Suchvorgänge, das Erstellen von Dateien und Attributänderungen. Wenn ein Client eine Datei öffnet, stellt das NDD ein pNFS Flexible File Layout bereit, das dem Client mitteilt, welche Datenserver die Dateidaten enthalten. Der Client kann dann Lese- und Schreibvorgänge direkt mit den ONTAP Datenservern durchführen; das NDD befindet sich im Metadatenpfad, aber nicht im Datenpfad.

Das NDD ist als Software implementiert, die auf einem Cluster aus mindestens drei dedizierten Servern ausgeführt wird. Es kombiniert die Metadatenserverprozesse mit einer replizierten, verteilten Datenbank, die die Namespace-Metadaten auf verschlüsseltem lokalem Storage speichert. Jeder Namespace führt seine eigenen Metadatenserverprozesse auf mehreren dieser Server aus. Alle funktionsfähigen Server kündigen die virtuelle IP-Adresse des Namespace an, wodurch die Clientlast verteilt wird und Clients ein Failover ohne erneutes Mounten ermöglicht wird. Da die maßgeblichen Metadaten in der replizierten Datenbank gespeichert sind, kann ein Server ausfallen und neu gestartet werden, ohne dass der Namespace-Status verloren geht.

Die Platzierung von Daten auf den ONTAP Clustern wird durch den NDD gesteuert. Er führt eine Registrierung der Datenserver, stellt mithilfe einfacher NFS-Prüfungen sicher, dass jeder Datenserver verfügbar ist, und überwacht die freie Kapazität auf jedem Server. Wenn eine Datei erstellt wird, wählt der NDD die Datenserver aus, erstellt die Backing-Dateien über NFS und zeichnet deren Speicherorte auf. Wenn ein Datenserver nicht mehr verfügbar ist, platziert der NDD dort keine neuen Daten mehr und ruft Client Layouts zurück, die darauf verweisen.

Die folgende Abbildung veranschaulicht auf hoher Ebene ein typisches Novus Deployment. Zu den wichtigsten Aspekten gehören ein einzelner Namespace mit mehreren Novus Data Directors und ONTAP-Datenserverknoten. Diese Architektur bietet hohe Verfügbarkeit und geringe Latenz zur Unterstützung der Backend-GPU-Server.