Flux de migration du stockage des machines virtuelles d'un disque local vers un NAS

Conservez le disque local de la VM comme copie de restauration vérifiée jusqu’à ce que le datastore NAS ait réussi les tests de démarrage, de charge de travail, de redémarrage et de sauvegarde.

Déplacer un disque virtuel change bien plus que son emplacement : le protocole, le réseau, le comportement de synchronisation du NAS, la chaîne de cache, le format d’allocation, l’ordre de montage et le domaine de défaillance font désormais partie de chaque écriture de l’invité. Établissez une référence avec des données jetables, protégez la source, déplacez une VM témoin via le chemin pris en charge par l’hyperviseur, puis comparez la charge de travail d’origine avant de migrer une autre VM. Revenez en arrière au lieu de réparer les deux copies si l’identité du disque ou la cohérence de l’application change.

Valider le datastore NAS avant de déplacer un disque

Consignez le protocole, l’adresse du NAS, le chemin réseau, la MTU, l’authentification, les autorisations d’exportation, le système de fichiers, la stratégie de synchronisation, les instantanés, l’espace libre et le comportement en cas de défaillance. Mesurez la latence et les écritures soutenues depuis l’hyperviseur avec des données jetables, et non depuis un ordinateur portable qui emprunte un autre chemin.

Une présentation actuelle des options de datastore local et partagé distingue les datastores locaux des options NFS et iSCSI partagées, ainsi que la portabilité qu’elles permettent. Utilisez cette comparaison pour définir la cible, tout en fondant l’acceptation sur ce NAS, ce réseau et cette charge de travail de VM.

Arrêtez-vous si la destination se déconnecte sous charge, accuse réception des écritures sans durabilité certaine, ne dispose pas de la capacité nécessaire à la migration et aux instantanés, ou dépend du même disque local qui doit être retiré. La simple accessibilité du stockage ne suffit pas à rendre la destination prête à héberger des images de VM actives.

Protéger la source et choisir la méthode de migration

Effectuez ou vérifiez une sauvegarde indépendante et consignez le format du disque virtuel source, son allocation, son contrôleur, le mode de cache, le paramètre discard, l’ordre de démarrage et la configuration de la VM. Mettez en pause les bases de données applicatives ou arrêtez la VM lorsque la méthode choisie ne garantit pas un déplacement en ligne cohérent.

Dans une réponse du personnel de Proxmox à une proposition de déplacement manuel de NFS vers iSCSI, il est recommandé d’utiliser la sauvegarde et la restauration plutôt que les déplacements manuels, au lieu de déplacer manuellement les fichiers d’image et de modifier la configuration. Considérez ce cas historique comme un principe de sécurité : utilisez la méthode de déplacement ou de sauvegarde et restauration prise en charge par la plateforme et adaptée à l’hyperviseur actuel.

Choisissez une VM témoin peu risquée avec un schéma d’accès au disque représentatif. Après la bascule, conservez le disque d’origine détaché mais intact lorsque la plateforme le permet ; ne laissez jamais les copies source et destination démarrer en mode inscriptible simultanément.

Migrer la VM témoin et vérifier son identité avant le démarrage

Lancez le déplacement de stockage ou la restauration pris en charge tout en surveillant les journaux de l’hôte, la latence du NAS, les erreurs réseau, la croissance de l’allocation et l’espace libre de destination. Enregistrez les identifiants des tâches et les vérifications finales. Si le transfert échoue, ne supprimez pas les données partielles avant d’avoir compris l’état de la plateforme et le chemin de restauration.

Comparez la configuration de la VM avant et après : bus du disque, indicateur de démarrage, format, taille, numéro de série, prise en charge des instantanés, comportement du cache et du discard. Utilisez le guide ZimaSpace associé pour configurer les caches de stockage de la VM uniquement après que le disque se trouve sur le stockage NAS ; le réglage du cache ne doit pas être mélangé à la migration elle-même.

Démarrez d’abord la VM témoin sur un réseau isolé. Vérifiez l’intégrité du système de fichiers, la cohérence de l’application, l’heure et l’identité attendue du disque virtuel. Si l’invité passe en mode récupération, signale des volumes manquants ou détecte un ordre de disques différent, arrêtez-le et rattachez la source vérifiée au lieu de réparer les deux copies.

-15% OFF

ZimaBoard 2 - Mini serveur domestique pour votre grande idée

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Valider la charge de travail d’origine et conserver la restauration

Exécutez la charge de travail importante pour la VM : validation de base de données, opérations sur de petits fichiers d’un serveur de fichiers, sauvegarde, tâche multimédia ou tâche de compilation. Comparez la latence, le débit, la mise en file d’attente, le comportement de synchronisation du NAS et l’utilisation du processeur de l’hôte avec la référence locale. Ne testez le redémarrage d’un service NAS que pendant une fenêtre de maintenance protégée.

Redémarrez une fois la VM et l’hyperviseur, vérifiez l’ordre de montage automatique du datastore, puis restaurez un petit fichier ou une transaction à partir de la sauvegarde suivante. Une migration n’est pas terminée si la VM ne fonctionne que jusqu’au redémarrage de l’hôte ou si les sauvegardes ciblent encore l’ancien disque.

Ne migrez les VM supplémentaires qu’une à une, après que la VM témoin a supporté la charge normale et un cycle de sauvegarde. Conservez le disque local en lecture seule jusqu’à la fin de la période de restauration ; revenez en arrière si la latence ou la durabilité n’atteint pas l’objectif défini, et transmettez les erreurs répétées de transport ou de stockage avec des horodatages relevés aux deux extrémités.