6 étapes pour migrer ses données sans stress

Étape 1 : Collecte des données avant la migration

La première étape d’une migration de données consiste à collecter et à corréler toutes les données de l'hôte et de la baie nécessaires à la migration.

Les tâches à accomplir dans ce contexte sont les suivantes :

• Identifier les hôtes pour la migration ;
• Collecter les données de l'hôte de migration (audit de l'hôte) ;
• Collecter des données de la baie de stockage (audit de la baie) ;
• Regrouper les informations relatives aux zones et masques ;
• Corréler l’ensemble des données.

Étape 2 : Etablir les règles de remédiation

Il est nécessaire d’évaluer les besoins en termes de remédiation et de remise en état du stockage avant de commencer la migration des données. Ce processus minimise les erreurs, tout en mettant en place des procédures pour traiter les bons correctifs.

Les trois tâches à réaliser sont :

• Analyser la migration et l'assainissement de la cible ;
• Remédiation de l'hôte ;
• Documenter les versions et la compatibilité des logiciels sources et des baies de stockage cibles, et corriger les éventuelles incompatibilités.

Étape 3 : Phase de préparation

Cette étape consiste à préparer les hôtes et les systèmes de stockage sources et cibles pour la migration. Les 18 tâches impliquées sont :

• Configurer la source et la baie de stockage cible pour faciliter la migration ;
• Créer le lien entre la source et la baie cible ;
• Collecter toutes les informations de configuration du stockage hôte, y compris le système d'exploitation installé, l'état du cluster et le système de reprise après sinistre ;
• Collecter la configuration de chaque baie, y compris le RAID, le port FA (Front-end) et l'état de chaque réplication locale et à distance ;
• Collecter la configuration du réseau SAN, y compris les directeurs, switches et passerelles ;
• Planifier l'agencement de l'espace de stockage sur les baies cibles ;
• Créer les scripts de configuration de migration et d'appariement des baies sources et cibles ;
• Créer les scripts de configuration pour le mappage des ports FA et l'affectation des LUN des baies cibles ;
• Créer les scripts de masquage LUN des baies cibles ;
• Création des scripts de définition des alias de périphériques ;
• Préparer le zonage SAN de l'hôte ;
• Regrouper les migrations des hôtes en coopération avec les unités opérationnelles ;
• Mettre à jour tous les scripts de sauvegarde et de restauration ;
• Exécuter tous les audits des hôtes avant la migration ;
• Créer et exécuter les scripts d'appariement des relations R1 à R2 ;
• Créer et exécuter les scripts de mappage et de masquage des baies cibles ;
• Appliquer toutes les configurations de zonage des hôtes ;
• Confirmer les connexions de l'hôte à la baie de stockage cible.

Étape 4 : Lancer le processus de migration

Toutes les tâches suivantes sont nécessaires à la migration des données vers une nouvelle baie de stockage. Elles vont de la sauvegarde ou de la protection des données à l'arrêt des applications, en passant par l'arrêt des hôtes et la création de scripts pour créer les liens vers la nouvelle baie. Une fois la migration terminée, les tâches sont inversées. Cela permet de redémarrer les applications des hôtes. Les tâches spécifiques à suivre sont les suivantes :

• Début de la migration des données vers la nouvelle baie ;
• Capturer, répliquer ou sauvegarder toutes les anciennes configurations d'hôtes ;
• Mettre en veille (arrêt) les applications, puis arrêter les hôtes ;
• Créer puis exécuter les scripts qui vont répartir les nouvelles relations entre les baies 1 et 2 dès que les données ont été synchronisées ;
• Vérifier et valider les données à partir des sauvegardes des hôtes;
• Redémarrer les applications ;
• Obtenir une validation des départements métiers afin que la migration des données soit considérée comme terminée.

Étape 5 : Validation, redémarrage et nettoyage

Validez la migration, remettez en production toutes les applications sur le nouveau stockage cible et désactivez l'ancien système de stockage. Recherchez, corrigez, nettoyez les erreurs. Pour cela, vous devez effectuer les tâches suivantes :

• Vérifier s'il y a eu des activités sur les anciennes baies ;
• Créer et exécuter les scripts de suppression des liens entre la baie 1 et la baie 2 ;
• Créer et exécuter les scripts pour supprimer tous les périphériques des FA sur la baie source ;
• Créer et exécuter les scripts pour effacer les méta-configurations sur les baies sources ;
• Créer et exécuter les scripts pour démasquer les périphériques sources des hôtes migrés ;
• Redémarrer les hôtes et confirmer la visibilité des nouveaux périphériques cibles ;
• Nettoyer les zones et éliminer toutes les zones inutilisées ;
• Vérifier la table de connexion finale sur les anciennes baies ;
• Mettre à jour des groupes de périphériques, le cas échéant.

Étape 6 : Documentation finale

• Achever, documenter et valider la migration
• Créer les rapports et les mettre à jour en documentant l'ensemble des processus réalisés.

Migration manuelle contre approche avec des scripts

La majorité des projets de migration de données sont gérés manuellement, et généralement à l'aide de tableurs Excel. Cette approche exige des processus, et surtout, de la discipline. En effet, une feuille Excel de migration des données doit être continuellement mise à jour, et ce par plusieurs administrateurs.

Les scripts sont une alternative courante. L'avantage des scripts est qu'ils peuvent être personnalisés en fonction de l'environnement, du stockage, des serveurs, des applications, des fournisseurs et de l'infrastructure. Néanmoins, le mauvais point : ces scripts sont rarement documentés, testés, corrigés ou mis à jour. Ils doivent généralement être réécrits pour chaque projet de migration de données SAN. Les scripts ont toujours l'air d'être une bonne idée… jusqu'à ce qu'ils soient implémentés.

Ces technologies de migration de données qui font gagner du temps

Il est possible de mettre en œuvre quatre technologies différentes afin de limiter les tâches manuelles d’une migration de données. Bien que chacune comporte des compromis, elles peuvent toutes réduire considérablement les charges de travail et les erreurs :

• Utilisez des appliances de stockage physiques programmables ou des appliances SDS virtuelles (VSA).
• Assurez-vous que le nouveau SAN est une version ou un modèle plus récent de l'ancien SAN et activez une réplication des données entre eux.
• Utilisez un système SAN évolutif.
• Utilisez VMware vSphere Storage vMotion.

On considère généralement que les appliances SDS simplifient la migration des données SAN. Cette solution permet de migrer les systèmes de stockage derrière l'appliance SDS ou le VSA sans toucher les serveurs ou l'infrastructure devant l'appliance ou le système de virtualisation. L'inconvénient :  ces appliances ajoutent des coûts très significatifs qui augmentent le coût total de possession. De plus, la complexité est accrue par le fait d'avoir à gérer l'ensemble des appliances SDS ou VSA, les ressources de l'hyperviseur pour le VSA et les baies de stockage back-end.

En outre, cela ajoute de la complexité  lors d'un rafraîchissement technique de l'appliance SDS - bien que cela soit généralement géré par la migration séquentielle des appliances actives-actives ou des appliances scale-out. Ce n'est pas un problème pour les VSA.

Rester chez le même fournisseur de solutions de stockage et utiliser la dernière version du SAN en cours de migration est une approche relativement courante, mais pas nécessairement parfaite. Cela nécessite une licence de réplication sur les deux systèmes et tous les serveurs connectés au stockage doivent être reconnectés au nouveau stockage. C'est généralement une solution de contournement solide.

L'utilisation d'un système SAN évolutif a gagné en popularité. Avec ces systèmes, le traitement et la capacité peuvent être mis à niveau de manière transparente dans le datacenter. Après la migration des données, l'ancien nœud est tout simplement retiré. On nettoie puis on répète l’opération jusqu'à ce que tous les nœuds soient mis à niveau. Les applications, serveurs, machines virtuelles (VM) et containers connectés ne sont pas perturbés par cette approche et cela permet d’éliminer la nécessité de migrer les données. Il suffit d'ajouter un nouveau nœud et de retirer l'ancien. Les données sont rapidement reconstruites sur les nouveaux nœuds restants.

Storage vMotion de VMware est devenu une alternative populaire. La solution proposée par VMware migre les données de chacun des LUN de la baie SAN affectés à ce serveur VMware vers les LUN de la nouvelle baie SAN. Les LUN virtuels des VM ne changent pas, masquant le changement physique réel dans les baies de stockage. L'inconvénient de cette approche est que cela ne fonctionne que pour les machines virtuelles fonctionnant dans une infrastructure VMware. La solution ne fournit pas non plus de remédiation de pathing SAN, ni de remédiation d'hôte VMware. De plus, elle ne déplace pas les données des LUN qui ne sont pas affectées à cet hôte VMware particulier. Il n'y a pas non plus de test ou de validation de migration de données.

Bien entendu, ces quatre solutions de rechange supposent toutes un engagement envers son fournisseur. La première exige un engagement envers le fournisseur de SDS, la deuxième envers le fournisseur de baie de stockage, la troisième envers le fournisseur de stockage évolutif et la quatrième envers VMware.