Les serveurs de données sont des clusters ONTAP spécialement conçus pour Novus. Ils implémentent le plan de données Novus, stockent les données de fichiers et les fournissent aux clients NFS. Un namespace Novus peut répartir ses données de fichiers sur plusieurs clusters ONTAP ; un cluster peut desservir de nombreux namespaces différents. Cette flexibilité permet d’accroître la capacité et les performances en ajoutant des serveurs de données selon les besoins.

Les clients accèdent aux serveurs de données ONTAP à l'aide d'un client NFS standard, sans avoir besoin d'un logiciel NetApp personnalisé. Une fois qu'un client obtient une disposition de fichier du Novus Data Director, il peut lire et écrire directement les données de fichier sur les serveurs de données ONTAP via NFSv3 et, en option, via RDMA. Les données en masse ne transitent jamais par le Novus Data Director, de sorte que le trafic de données circule en parallèle sur les serveurs de données.

Les serveurs de données ne participent pas à la gestion du namespace. Ils stockent les données de chaque fichier sous forme de fichiers de support dans des volumes ONTAP. Un serveur de données ONTAP ne gère pas les métadonnées du namespace Novus, telles que l'arborescence des répertoires ou la façon dont les fichiers sont répartis entre les serveurs de données.

L'AFF A90 pour NetApp Novus est une version de l'AFF A90 conçue pour Novus exécutant ONTAP. Ses caractéristiques comprennent :

Les clusters ONTAP standard ne peuvent pas être utilisés comme serveurs de données Novus ; seules les plateformes spécifiquement conçues pour Novus sont prises en charge.

Novus Data Director (NDD) implémente le rôle de serveur de métadonnées (MDS) dans l'architecture pNFS et fournit le plan de métadonnées Novus. Un hôte MDS est un serveur physique exécutant Linux, ainsi que les services du protocole MDS et les magasins de métadonnées.

Le NDD présente chaque namespace aux clients comme un système de fichiers unique. Il gère les métadonnées du namespace : fichiers et répertoires, attributs de fichier, mappage de l’emplacement de stockage des données de chaque fichier et état du protocole nécessaire pour coordonner l’accès des clients. Les clients montent un namespace via son adresse IP virtuelle et communiquent avec le NDD à l’aide de NFSv4.2 avec parallel NFS (pNFS). Le NDD prend en charge toutes les opérations de métadonnées, telles que les recherches, la création de fichiers et les modifications d’attributs. Lorsqu’un client ouvre un fichier, le NDD lui fournit une disposition Flexible File pNFS, qui indique au client quels serveurs de données détiennent les données du fichier. Le client peut alors effectuer ses opérations de lecture et d’écriture directement avec les serveurs de données ONTAP ; le NDD se trouve dans le chemin des métadonnées, mais pas dans le chemin d'accès aux données.

Le NDD est implémenté sous forme de logiciel s'exécutant sur un cluster d'au moins trois serveurs dédiés. Il combine les processus du serveur de métadonnées avec une base de données répliquée et distribuée qui stocke les métadonnées du namespace sur un stockage local chiffré. Chaque namespace exécute ses propres processus de serveur de métadonnées sur plusieurs de ces serveurs. Tous les serveurs sains annoncent l'adresse IP virtuelle du namespace, ce qui répartit la charge client et permet aux clients de basculer en cas de panne sans avoir à remonter le système de fichiers. Comme les métadonnées faisant autorité résident dans la base de données répliquée, un serveur peut tomber en panne et redémarrer sans perdre l'état du namespace.

Le placement des données sur les clusters ONTAP est contrôlé par le NDD. Il tient un registre des serveurs de données, s'assure que chaque serveur de données est disponible à l'aide de sondes NFS légères et suit la capacité libre de chacun. Lorsqu'un fichier est créé, le NDD choisit les serveurs de données, crée les fichiers de support via NFS et enregistre leur emplacement. Si un serveur de données devient indisponible, le NDD cesse d'y placer de nouvelles données et rappelle les layouts client qui pointent vers lui.

La figure suivante illustre dans les grandes lignes un déploiement Novus typique. Les aspects notables incluent un seul namespace avec plusieurs Novus Data Directors et nœuds de serveur de données ONTAP. Cette architecture offre une haute disponibilité et une faible latence pour prendre en charge les serveurs GPU du backend.