La première étape de la préparation consiste à identifier les LUN à migrer. Dans l'exemple illustré ici, deux systèmes de fichiers SAN sont montés sur /orabin et /backups.

Le nom du groupe de volumes peut être extrait du nom du périphérique, qui utilise le format (nom du groupe de volumes)-(nom du volume logique). Dans ce cas, le groupe de volumes est appelé sanvg.

Le pvdisplay Vous pouvez utiliser la commande suivante pour identifier les LUN qui prennent en charge ce groupe de volumes. Dans ce cas, 10 LUN constituent le sanvg groupe de volumes.

Les LUN ASM doivent également être migrés. Pour obtenir le nombre de LUN et de chemins de LUN depuis sqlplus en tant qu'utilisateur sysasm, exécutez la commande suivante :

L'environnement actuel contient 20 LUN à migrer. Mettez à jour le SAN actuel de sorte que ONTAP puisse accéder aux LUN actuelles. Les données n'ont pas encore été migrées, mais ONTAP doit lire les informations de configuration des LUN actuelles pour créer le nouveau home pour ces données.

Au moins un port HBA sur le système AFF/FAS doit être configuré en tant que port initiateur. En outre, les zones FC doivent être mises à jour de sorte que ONTAP puisse accéder aux LUN de la baie de stockage étrangère. Certaines baies de stockage ont configuré le masquage des LUN, ce qui limite les WWN pouvant accéder à une LUN donnée. Dans ce cas, le masquage de LUN doit également être mis à jour pour autoriser l'accès aux WWN de ONTAP.

Une fois cette étape terminée, ONTAP doit être en mesure d'afficher la baie de stockage étrangère avec le storage array show commande. Le champ de clé renvoyé est le préfixe utilisé pour identifier la LUN étrangère sur le système. Dans l'exemple ci-dessous, les LUN de la baie étrangère FOREIGN_1 Apparaissent dans ONTAP en utilisant le préfixe de FOR-1.

Vous pouvez lister les LUN en transmettant le array-name à la storage disk show commande. Les données renvoyées sont référencées plusieurs fois pendant la procédure de migration.

Les LUN étrangères sont initialement classées comme tout type de LUN particulier. Avant de pouvoir importer des données, les LUN doivent être marquées comme étrangères et par conséquent comme candidates au processus d'importation. Cette étape est terminée en transmettant le numéro de série au storage disk modify comme indiqué dans l'exemple suivant. Notez que ce processus balise uniquement la LUN comme étant étrangère dans ONTAP. Aucune donnée n'est écrite sur la LUN étrangère elle-même.

Un volume est nécessaire pour héberger les LUN migrées. La configuration exacte du volume dépend du plan global d'exploitation des fonctionnalités ONTAP. Dans cet exemple, les LUN ASM sont placées dans un volume et les LUN LVM sont placées dans un second volume. Vous pouvez ainsi gérer les LUN en tant que groupes indépendants à des fins telles que la hiérarchisation, la création de snapshots ou la définition de contrôles de QoS.

Réglez le snapshot-policy `to `none. Le processus de migration peut inclure une grande partie du transfert des données. Par conséquent, si des snapshots sont créés par accident, la consommation d'espace peut augmenter de façon importante, car des données indésirables sont capturées dans les snapshots.

Une fois les volumes créés, les nouvelles LUN doivent être créées. Normalement, la création d'une LUN nécessite que l'utilisateur indique des informations telles que la taille de LUN, mais dans ce cas, l'argument disque étranger est transmis à la commande. Par conséquent, ONTAP réplique les données de configuration actuelle du LUN à partir du numéro de série spécifié. Il utilise également la géométrie des LUN et les données de la table de partition pour ajuster l'alignement des LUN et établir des performances optimales.

Dans cette étape, les numéros de série doivent être référencés avec le tableau étranger pour s'assurer que le LUN étranger correct est associé au nouveau LUN correct.

Les LUN ont été créées, mais ne sont pas configurées en tant que destination de réplication. Avant de pouvoir réaliser cette étape, les LUN doivent d'abord être mises hors ligne. Cette étape supplémentaire est conçue pour protéger les données contre les erreurs de l'utilisateur. Si ONTAP permettait l'exécution d'une migration sur une LUN en ligne, une erreur typographique risquerait d'écraser les données actives. L'étape supplémentaire consistant à forcer l'utilisateur à mettre d'abord une LUN hors ligne permet de vérifier que la LUN cible correcte est utilisée comme destination de migration.

Une fois les LUN hors ligne, vous pouvez établir la relation d'importation en transmettant le numéro de série de la LUN étrangère à lun import create commande.

Une fois toutes les relations d'importation établies, les LUN peuvent être remis en ligne.

Un groupe initiateur (igroup) fait partie de l'architecture de masquage des LUN ONTAP. L'accès à une LUN nouvellement créée n'est pas accessible à moins qu'un hôte ne bénéficie au préalable d'un accès. Pour ce faire, vous devez créer un groupe initiateur qui répertorie les WWN FC ou les noms d'initiateurs iSCSI auxquels l'accès doit être accordé. Au moment de la rédaction de ce rapport, FLI était pris en charge uniquement pour les LUN FC. Cependant, la conversion en iSCSI après migration est une tâche simple, comme illustré dans la "Conversion de protocoles".

Dans cet exemple, un groupe initiateur est créé et contient deux WWN correspondant aux deux ports disponibles sur l'adaptateur HBA de l'hôte.

Après la création du groupe initiateur, les LUN sont ensuite mappées sur le groupe initiateur défini. Ces LUN sont uniquement disponibles pour les WWN inclus dans ce groupe initiateur. NetApp suppose, à ce stade du processus de migration, que l'hôte n'a pas été segmenté vers ONTAP. Cela est important, car si l'hôte est segmenté simultanément sur la baie étrangère et le nouveau système ONTAP, il est possible de détecter sur chaque baie des LUN portant le même numéro de série. Cette situation peut entraîner des dysfonctionnements des chemins d'accès multiples ou endommager les données.