Environnement et traitement du système de stockage Novus
Suggérer des modifications
PDF
Il existe plusieurs aspects importants de l'environnement Novus et de son traitement que vous devriez comprendre.
Communication interne entre Novus Data Director et le serveur de données ONTAP
Les Novus Data Directors communiquent avec les serveurs de données ONTAP pour prendre en charge l'accès aux fichiers et leur gestion. La plupart de ces opérations sont initiées par le NDD plutôt que par les serveurs ONTAP.
Découverte du serveur de données ONTAP
Les Novus Data Directors doivent découvrir quels serveurs de données sont disponibles. ONTAP n'initie jamais de communication avec le Novus Data Director. Un opérateur ou un outil enregistre chaque serveur de données via le fichier de configuration mds.conf, qui est utilisé au démarrage ; les serveurs de données peuvent également être ajoutés manuellement à l'aide de la commande mds-admin ds add. Chaque serveur de données est représenté par une ligne dans le magasin de métadonnées distribué, comprenant son hôte, son export, ses ports, son état et sa capacité.
Disponibilité du serveur de données ONTAP
Plusieurs processus sont utilisés pour déterminer la disponibilité de chaque serveur de données ONTAP.
- Signal de pulsation
-
Le MDS envoie un appel RPC NFSv3 NULL via TCP à chaque serveur de données en ligne. Par défaut, il effectue cet appel toutes les 5 secondes à l'aide d'un message de pulsation.
- Mise hors ligne
-
Après un certain nombre d'échecs consécutifs, le serveur de données est marqué comme hors ligne. Le MDS cesse alors d'y placer de nouveaux fichiers et demande aux clients de renvoyer les layouts qui pointent vers ce serveur.
- Retour
-
Après plusieurs sondages réussis consécutifs, le système se remet en ligne. Une période de temporisation empêche les allers-retours incessants.
- Les erreurs du client ne sont pas prises en compte
-
Lorsqu'un client signale une erreur, celle-ci est simplement consignée. L'état du serveur de données ONTAP est déterminé uniquement par les sondes.
- Le basculement ONTAP est invisible
-
Si une paire haute disponibilité ONTAP effectue une prise de contrôle, le MDS ne le remarque qu'au moyen des délais d'expiration des sondes.
Contenu des données du serveur de données ONTAP
Le NDD ne demande pas à ONTAP ce qu'il stocke. Il le sait déjà, car il crée chaque fichier de support :
-
Lors de la création d'un fichier, le MDS sélectionne les serveurs de données, y crée les fichiers de support et enregistre le résultat dans la table de correspondance des bandes du magasin de métadonnées distribué. Cette table indique quel serveur de données et quel descripteur de fichier NFS hébergent chaque bande et chaque miroir.
-
Les fichiers de sauvegarde sur ONTAP ont un format de nom spécifique dans le NDD.
-
La capacité est la seule valeur opérationnelle que le NDD lit à partir d’ONTAP en utilisant statvfs() sur chaque export monté.
-
La taille du fichier n'est pas vérifiée auprès d'ONTAP. Elle est déterminée à partir du commit de layout du client.
Haute disponibilité et résilience pour le cluster NDD
Le plan de métadonnées, ancré par les Novus Data Directors, garantit une haute disponibilité et une grande résilience du système.
Conception du cluster
Novus utilise un cluster multi-hôtes pour garantir une haute disponibilité et une tolérance aux pannes pour les services NDD.
- Trois hôtes avec trois domaines de défaillance
-
Le cluster NDD minimal comprend trois hôtes physiques ou machines virtuelles (VMs) déployés sur des serveurs distincts. Chaque hôte exécute un processus MDS et un nœud de stockage des métadonnées. Le cluster est conçu pour survivre à la perte d'un hôte.
- Toutes les répliques servent
-
Chaque réplique MDS gère simultanément les clients, aucune n'étant en veille. Toutes les répliques opérationnelles annoncent la même adresse IP virtuelle (VIP) via BGP. La détection rapide des pannes de liaison (BFD) est nécessaire, car les temporisateurs de BGP ne constituent pas à eux seuls un mécanisme de basculement pleinement satisfaisant. Une réplique annonce la VIP uniquement lorsque son service NFS, sa passerelle et sa connexion au magasin de métadonnées sont tous prêts à gérer les clients.
- Réplication des métadonnées
-
Le système de stockage de métadonnées distribué conserve trois copies synchrones. Un arbitre empêche un scénario de split-brain en se rendant indisponible plutôt que de permettre aux deux côtés d'écrire simultanément.
- Les redémarrages sont sans risque
-
Les processus MDS ne conservent aucun état propre; le magasin de métadonnées distribué contient les métadonnées faisant autorité.
Limitations et précautions
Vous devez également prendre en compte les limitations et précautions suivantes :
-
La propriété des sous-arbres ne bascule pas automatiquement en cas de défaillance. Le namespace peut être divisé en sous-arbres, chacun appartenant à un MDS. Si un propriétaire tombe en panne, son sous-arbre reste bloqué jusqu'à son retour, même si le VIP a déjà été déplacé.
-
Une panne d'hôte affecte tous les locataires de cet hôte, car chaque locataire dispose d'une réplique par hôte.
-
Les clients doivent monter l’adresse IP virtuelle (VIP) et non l’adresse IP de l’hôte. Sinon, le basculement côté client sera impossible.
-
Les montages stricts peuvent se bloquer pendant la récupération. Un montage bloqué ne signifie pas que des données ont été perdues.
-
Effectuez toujours la maintenance d'une réplique à la fois. Retirez d'abord la réplique du VIP et drainez-la.