Dell Unity : Comment réussir une migration IMT (corrigible par l’utilisateur)

L’outil Dell Unity Inband Mobility Tool (IMT) est un excellent outil pour migrer les données de votre ancienne baie VNX vers votre nouveau système Unity. Cependant, certaines choses peuvent être faites afin d’assurer vos meilleures chances de réussite de la migration.

Voici quelquesconditions préalables dont vous devez tenir compte lorsque vous décidez de commencer ou non votre migration vers l’IMT :

• IMT prend uniquement en charge les systèmes de stockage VNX1 ou VNX2. Les anciens systèmes Celerra ou VNX (systèmes VG ou NS) ne sont pas pris en charge en tant que systèmes sources.
• L’IMT utilise des protocoles de copie en mode fichier (NFS ou CIFS) pour copier les données.
• Un système de fichiers spécial sur VNX, tel que NMFS ou un système de fichiers WORM, n’est pas pris en charge en tant que système de fichiers source.
• Les systèmes de fichiers source multiprotocoles ne sont pas pris en charge ; SEUL CIFS OU NFS est copié.
• Désactivez les services FTP sur tous les serveurs NAS impliqués dans une migration IMT avant de démarrer cette migration.
• Assurez-vous d’avoir suffisamment d’espace sur votre destination pour héberger tous les fichiers sur votre source AVANT de commencer.  Ne comptez pas sur l’extension automatique ; Préconfigurez tout l’espace avant de commencer.
• Si les quotas sont activés sur le système de fichiers cible, assurez-vous qu’il y a suffisamment de quota disponible pour la taille étendue de tous les fichiers. 
• Le système de fichiers source compressé (déduplication ou DHSM) est développé lors de la migration.  Vous devez tenir compte de la taille étendue et de la surcharge lors de la planification de l’espace à allouer dans votre système de fichiers cible.
  • Vous devez également activer les rappels de fichiers sur votre baie source pour en tenir compte.
• Lors de l’exécution d’une migration de Data Mover virtuel, l’interface rattachée au serveur CIFS sur le Data Mover virtuel en cours de migration est basculée vers le système Unity. S’il s’agit de la seule interface du Data Mover virtuel, le Data Mover virtuel source est inaccessible. Assurez-vous de disposer d’au moins une interface supplémentaire configurée sur votre VDM source afin que les autres utilisateurs ne perdent pas la connectivité lors du basculement.

Les éléments suivants ont un impact sur le moment où une migration à l’aide de l’IMT peut être effectuée :

• Une fois que vous avez commencé votre migration, vous ne pouvez pas modifier la baie source, par exemple renommer les serveurs CIFS. Considérez que le VNX est verrouillé une fois la migration lancée, et gardez-le verrouillé jusqu’à ce que la migration soit terminée et que le basculement réussisse.
• Vous devez également envisager d’effectuer votre migration pendant une PÉRIODE DE FAIBLE I/O du système de fichiers source, ou envisager de fermer complètement l’accès au système de fichiers source.  Les fichiers ouverts peuvent avoir un impact sur leur capacité à être migrés, et si une telle défaillance se produit, il se peut que vous ne soyez pas informé que le fichier n’a pas été transféré.  Vous pouvez utiliser MMC pour voir s’il existe des fichiers ouverts avant la migration.

 

---

Voici quelques pratiques d’excellence à garder à l’esprit lors de la configuration initiale de l’IMT :

• Les sessions d’importation de CIFS IMT ne prennent en charge qu’un seul serveur CIFS sur le Data Mover virtuel source.  Vous devez reconfigurer votre VDM source de sorte qu’il n’y ait qu’un seul serveur CIFS sur celui-ci (la source de la migration).
• Si votre Data Mover virtuel source comporte également des exportations NFS, la création de votre session d’importation CIFS échoue. Assurez-vous d’annuler complètement l’exportation NFS avant de commencer la création d’un IMT CIFS.
• Les interfaces VNX et Unity doivent être opérationnelles et accessibles via une commande ping.  En outre, toutes les interfaces impliquées dans la migration doivent faire partie du même VLAN.
• Le DNS doit être configuré et une passerelle par défaut doit être définie.
• Votre VDM source doit disposer d’une nouvelle interface spécifique à la migration créée, avec un nom qui commence par « nas_migration_ », et cette interface doit être en ligne et « active ».  L’interface doit être valide et avoir une bonne communication avec le réseau.
  • L’interface « nas_migration » doit se trouver sur un domaine, ou sous-domaine, DNS différent de celui de l’interface CIFS de production. Vous devrez peut-être créer une nouvelle zone de domaine DNS.  Si vous utilisez le DNS dynamique, la création de l’interface lors de la spécification d’un nouveau sous-domaine créera automatiquement la nouvelle zone.
• La prise en charge des utilisateurs locaux doit être activée sur le serveur CIFS source et les informations d’identification de l’administrateur local sont requises pour créer une session d’importation.  Vous devez modifier manuellement le mot de passe d’administrateur local (il ne peut pas conserver la valeur par défaut).  Enfin, le compte administrateur local doit être ajouté au groupe local « Backup Operators » sur le logiciel de transfert de données (ou un utilisateur local standard doit être ajouté aux groupes locaux « Administrators » et « Backup Operators »).
• Si votre système Unity cible exécute un code antérieur à la version 4.4.1, la réduction des données n’est pas automatiquement activée lorsque la migration est lancée, sauf si la migration est démarrée à partir de l’interface UEMCLI.  Ce problème est corrigé dans la version 4.4.1 et les versions ultérieures.

---

Voici quelques bonnes pratiques concernant le basculement d’une migration IMT :

• Les fichiers en échec peuvent se produire pour plusieurs raisons.  La seule façon de voir les fichiers en échec est d’utiliser l’outil svc_imt à l’aide de l’interface UEMCLI.
  • Les fichiers dont la migration échoue peuvent également être classés comme « supprimés/ignorés », ce qui permet à la migration de se poursuivre (comme nous l’avons mentionné précédemment, vous ne serez pas averti si des fichiers ont été abandonnés ou ignorés).  D’autres échecs de fichier entraînent l’arrêt de la migration. L’état de la migration affiche « MIS_Waiting_For_Resync ».
  • Certains fichiers sont internes à l’équipe IMT et signalent également des échecs. Voir les remarques pour plus d’informations.
• Dans le cas d’un état MIS_FAILED, un message d’annulation doit être émis pour revenir à VNX.  Cela peut nécessiter l’aide de Dell.
• Au cours de la partie de synchronisation incrémentielle d’un basculement, il peut être utile d’ouvrir deux fenêtres côte à côte : le partage C$ sur le VNX et le partage de production actif Unity, afin de vous assurer que les deux sont disponibles et que les nouveaux fichiers écrits sur Unity sont immédiatement copiés au même emplacement sur le VNX.

Consultez les articles suivants pour plus d’informations sur ces conditions et d’autres problèmes que vous pouvez rencontrer lors de l’exécution d’une migration IMT : 

• Dell Unity : Problèmes et résolutions de NFS VDM Import/Block Import (IMT) (corrigible par l’utilisateur)
• Dell Unity : Problèmes d’importation de Data Mover virtuel CIFS (IMT) et résolutions (corrigible par l’utilisateur)

Notez que si « oplock » est activé sur le système de fichiers sur le VNX source, vous devez consulter la base de connaissances suivante :

• Dell Unity : Le verrouillage des opérations Unity est désactivé par défaut sur un système de fichiers migré et ne peut pas être activé pendant l’IMT (corrigible par Dell)