Guide de migration des jeux de données ZFS : déplacer les données sans modifier les chemins des conteneurs

L’approche sûre consiste à traiter la réplication, la vérification et le basculement atomique du point de montage d’origine, avec conservation d’un jeu de données de restauration, comme une séquence de contrôles observables plutôt que comme une commande unique.

Sur des jeux de données ZFS qui prennent en charge une pile de conteneurs sur un serveur personnel, le risque pratique consiste à devoir déplacer un jeu de données ZFS tout en préservant les chemins de montage bind utilisés par les conteneurs. Enregistrez l’identité actuelle et le point de récupération, commencez par le discriminateur le moins invasif, interprétez les résultats réussis et échoués avant de modifier une autre variable, et arrêtez-vous lorsque le stockage devient instable ou que la seule copie récupérable risque d’être exposée. Le flux de travail ci-dessous ne s’achève qu’une fois que la charge de travail d’origine fonctionne ou que les éléments disponibles atteignent une limite nécessitant une escalade.

Inventorier le jeu de données et le contrat de chemin

Enregistrez le jeu de données source, ses enfants, ses instantanés, son point de montage, la valeur de canmount, sa racine de chiffrement, ses quotas, ses réservations, le comportement de ses ACL et chaque montage bind de conteneur qui se trouve à l’intérieur. Le contrat correspond au chemin hôte visible par les conteneurs ; le nom du pool et celui du jeu de données peuvent changer sous-jacents à ce chemin.

La réplication ZFS peut préserver les instantanés et les propriétés ; un flux récursif nécessite donc un examen délibéré des propriétés plutôt qu’une réception aveugle. Une migration ZFS send et receive indépendante montre comment send et receive sont utilisés pour la migration interne d’un jeu de données et pourquoi la hiérarchie cible mérite d’être inspectée avant le basculement.

Créez une sauvegarde externe à jour ou prouvez qu’une restauration existante fonctionne avant la migration. Arrêtez-vous si la source contient des jeux de données enfants masqués, une dépendance inconnue à une clé de chiffrement ou un point de montage qui chevauche un autre jeu de données actif ; ces conditions peuvent faire monter un flux correct au mauvais endroit.

Recevoir la première copie sans la monter par-dessus la production

Créez un instantané récursif tel que zfs snapshot -r oldpool/apps@move-0, puis envoyez-le vers un jeu de données cible reçu avec le montage désactivé ou avec un point de montage temporaire. Utilisez les options adaptées à vos exigences de chiffrement et de propriétés ; ne supposez pas qu’un flux chiffré brut et une réception déchiffrée se comportent de la même manière avec les clés.

Après la réception, comparez zfs list -r -t filesystem,snapshot et zfs get -r mountpoint,canmount,encryptionroot,quota,reservation sur les deux arborescences. Une discussion de forum sur les propriétés de point de montage répliquées montre pourquoi ces propriétés peuvent surprendre lors d’une migration pourtant réussie.

La première copie est validée lorsque le jeu de données et la filiation des instantanés correspondent et que la cible reste isolée du chemin de production. Si elle se monte par-dessus la source ou modifie les fichiers visibles par les conteneurs, exportez ou démontez la cible et corrigez les propriétés avant tout envoi incrémentiel.

Combler l’écart d’écriture et basculer le point de montage

Prenez un autre instantané de la source et envoyez la différence incrémentielle pendant que l’application fonctionne encore. Pour le basculement final, arrêtez tous les processus d’écriture, confirmez qu’aucun processus n’a de fichiers ouverts sous le chemin de montage bind, prenez un instantané final et envoyez uniquement ce delta. Limitez l’interruption à la synchronisation finale et au changement de chemin.

Définissez la source sur un point de montage non destiné à la production ou sur canmount=noauto, puis attribuez le chemin hôte d’origine à la cible et montez-la. Ne laissez jamais deux jeux de données revendiquer le même point de montage. Démarrez la base de données et les services dépendants avant l’interface applicative afin que les erreurs indiquent la bonne couche.

Si l’envoi final échoue, remontez la source sur le chemin d’origine et redémarrez la pile ; ne mélangez pas de nouvelles écritures entre les deux copies. La condition de restauration est explicite : la source reste intacte et aucune écriture de production n’est acceptée sur la cible tant que le flux final et les vérifications des propriétés n’ont pas réussi.

Featured

ZimaCube 2 NAS personnel Cloud à domicile

ZimaCube2

$799.00 - $2,499.00

Buy Now

Valider les conteneurs sur le chemin inchangé

Inspectez les montages bind depuis le moteur de conteneurs, ouvrez des fichiers représentatifs, créez et supprimez un fichier temporaire via l’application, puis confirmez la propriété, les ACL, les attributs étendus et le rapport d’espace libre. Redémarrez la pile deux fois et vérifiez que les montages ZFS sont effectués avant le démarrage des conteneurs.

Exécutez un scrub ou une autre vérification de l’état du pool conformément à votre plan de maintenance, mais ne l’utilisez pas comme seule preuve de migration. Comparez les GUID d’instantané ou un manifeste de hachage représentatif, restaurez un petit élément et utilisez le test de ZimaSpace pour vérifier si la réplication ZFS peut reprendre après une interruption avant de retirer la filiation source.

Conservez la source en lecture seule jusqu’à la réussite d’au moins un cycle normal de sauvegarde et d’application. Retirez-la uniquement lorsque les conteneurs utilisent les chemins d’origine, que les tâches planifiées ciblent le nouveau jeu de données, que la réplication se poursuit à partir de la filiation prévue et que la restauration n’est plus nécessaire ; sinon, rétablissez le point de montage et préservez les deux historiques.