Exigences de migration des conteneurs de nœuds StorageGRID pour Linux
Suggérer des modifications
PDF
La fonctionnalité de migration de nœuds permet de déplacer manuellement un nœud d'un hôte à un autre. Généralement, les deux hôtes se trouvent dans le même centre de données physique.
|
« Linux » désigne un déploiement RHEL, Ubuntu ou Debian. Pour obtenir la liste des versions prises en charge, consultez le "Outil de matrice d'interopérabilité (IMT) NetApp". |
La migration de nœuds permet d'effectuer la maintenance de l'hôte physique sans interrompre le fonctionnement du grid. Vous déplacez tous les nœuds StorageGRID, un par un, vers un autre hôte avant de mettre l'hôte physique hors ligne. La migration des nœuds ne nécessite qu'une courte interruption pour chaque nœud et ne devrait pas affecter le fonctionnement ni la disponibilité des services du grid.
Si vous souhaitez utiliser la fonctionnalité de migration de nœuds StorageGRID, votre déploiement doit répondre à des exigences supplémentaires :
-
Noms d'interface réseau cohérents entre les hôtes d'un même centre de données physique
-
Stockage partagé pour les volumes de métadonnées et de référentiel d'objets StorageGRID, accessible par tous les hôtes d'un même centre de données physique. Par exemple, vous pouvez utiliser des systèmes de stockage E-Series NetApp.
Si vous utilisez des hôtes virtuels et que la couche d'hyperviseur sous-jacente prend en charge la migration des machines virtuelles, vous pouvez privilégier cette fonctionnalité à la fonctionnalité de migration des nœuds dans StorageGRID. Dans ce cas, vous pouvez ignorer ces exigences supplémentaires.
Avant d'effectuer une migration ou une maintenance de l'hyperviseur, arrêtez les nœuds correctement. Consultez les instructions pour "${post_edited_translations.segment}".
VMware Live Migration non pris en charge
Lors de l'installation bare-metal sur des machines virtuelles VMware, la migration en direct OpenStack Live Migration et VMware live vMotion provoquent un saut de l'heure de l'horloge de la machine virtuelle et ne sont pas prises en charge pour les nœuds de grille de tout type. Bien que rares, des heures d'horloge incorrectes peuvent entraîner une perte de données ou de mises à jour de configuration.
La migration à froid est prise en charge. Lors d'une migration à froid, vous arrêtez les nœuds StorageGRID avant de les migrer entre les hôtes. Consultez les instructions pour "${post_edited_translations.segment}".
Noms d'interface réseau cohérents
Pour déplacer un nœud d'un hôte à un autre, le service d'hôte StorageGRID doit s'assurer que la connectivité réseau externe dont dispose le nœud à son emplacement actuel peut être dupliquée au nouvel emplacement. Il obtient cette certitude grâce à l'utilisation de noms d'interface réseau cohérents dans les hôtes.
Supposons, par exemple, que StorageGRID NodeA exécuté sur Host1 ait été configuré avec les mappages d'interface suivants :
La partie gauche des flèches correspond aux interfaces traditionnelles telles qu'elles apparaissent depuis un conteneur StorageGRID (c'est-à-dire les interfaces Grid, Admin et Client Network, respectivement). La partie droite des flèches correspond aux interfaces hôtes réelles qui fournissent ces réseaux, à savoir trois interfaces VLAN subordonnées à la même agrégation d'interfaces physiques.
Supposons maintenant que vous souhaitiez migrer NodeA vers Host2. Si Host2 possède également des interfaces nommées bond0.1001, bond0.1002 et bond0.1003, le système autorisera la migration, en supposant que ces interfaces offrent la même connectivité sur Host2 que sur Host1. Si Host2 ne possède pas d'interfaces portant les mêmes noms, la migration ne sera pas autorisée.
Il existe de nombreuses façons d'obtenir une dénomination cohérente des interfaces réseau sur plusieurs hôtes ; voir "Configurer le réseau hôte" pour quelques exemples.
Stockage partagé
Pour permettre des migrations de nœuds rapides et peu gourmandes en ressources, la fonctionnalité de migration de nœuds de StorageGRID ne déplace pas physiquement les données des nœuds. La migration s’effectue plutôt par une paire d’opérations d’exportation et d’importation, comme suit :
-
Lors de l'opération d'exportation de nœud, une petite quantité de données d'état persistantes est extraite du conteneur de nœud exécuté sur HostA et mise en cache sur le volume de données système de ce nœud. Ensuite, le conteneur de nœud sur HostA est désinstancié.
-
Lors de l'opération d'importation de nœud, le conteneur de nœud sur HostB qui utilise la même interface réseau et les mêmes mappages de stockage bloc que ceux en vigueur sur HostA est instancié. Ensuite, les données d'état persistantes mises en cache sont insérées dans la nouvelle instance.
Dans ce mode de fonctionnement, tous les volumes de données système et de stockage d’objets du nœud doivent être accessibles à la fois depuis HostA et HostB pour que la migration soit autorisée et fonctionne. De plus, ils doivent avoir été mappés dans le nœud à l’aide de noms garantissant qu’ils font référence aux mêmes LUN sur HostA et HostB.
L'exemple suivant illustre une solution de mappage de périphériques de stockage bloc pour un nœud de stockage StorageGRID, où le multipathing DM est utilisé sur les hôtes et où le champ alias a été utilisé dans /etc/multipath.conf pour fournir des noms de périphériques de stockage bloc cohérents et conviviaux disponibles sur tous les hôtes.
