Présentation de la migration shadow

La migration shadow utilise l'interposition mais est intégrée dans l'appareil et ne requiert pas de machine physique séparée. Lorsque des partages sont créés, ils peuvent éventuellement "masquer" un répertoire existant, en local ou sur NFS. Dans ce scénario, le temps d'indisponibilité est programmé, l'appareil source X est placé en mode lecture seule puis un partage est créé, dans lequel la propriété shadow est définie. Les clients sont ensuite mis à jour pour pointer vers un nouveau partage sur l'appareil Oracle ZFS Storage Appliance. Les clients peuvent ensuite accéder à l'appareil en mode lecture-écriture.

Figure 5-11  Migration shadow

Une fois que la propriété shadow est définie, les données sont migrées localement en arrière-plan à partir de l'appareil source. Si un client envoie une requête pour un fichier qui n'a pas été encore été migré, l'appareil migre automatiquement ce fichier vers un serveur local avant de répondre à la requête. Au début, cela peut causer une latence pour certaines requêtes client mais, dès qu'un fichier est migré, tous les accès sont effectués en local sur l'appareil et ont des performances natives. Il arrive souvent que la taille de la mémoire de travail d'un système de fichiers soit inférieure à la taille totale. Ainsi, une fois que cette mémoire de travail a été migrée, il n'y a aucun impact perceptible sur les performances, quelle que soit la taille native totale sur la source.

Toutefois, la migration shadow présente un inconvénient : elle requiert une validation avant la fin de la migration des données. Cela dit, c'est le cas de toutes les méthodes d'interposition. Pendant la migration, certaines parties des données existent à deux endroits, ce qui signifie que les sauvegardes sont difficiles et qu'il est possible que les instantanés soient incomplets et/ou qu'ils n'existent que sur un seul hôte. C'est pourquoi il est très important que toutes les migrations effectuées entre deux hôtes soient d'abord testées minutieusement afin de s'assurer que la gestion des identités et les contrôles d'accès sont définis correctement. Cela n'implique pas de tester la totalité de la migration des données mais il faut vérifier que les fichiers ou les répertoires qui ne sont pas lisibles par tous sont migrés correctement, que les ACL (si elles existent) sont préservées et enfin que les identités sont représentées correctement dans le nouveau système.

La migration shadow étant implémentée à l'aide de données sur disque dans le système de fichiers, il n'y a pas de base de données externe et aucune donnée n'est stockée en local hors du pool de stockage. Si un pool bascule dans un cluster ou que les deux disques système subissent une défaillance et qu'un nouveau noeud de tête est requis, toutes les données nécessaires pour poursuivre la migration shadow sans interruption sont conservées dans le pool de stockage.

Le paragraphe suivant liste les restrictions applicables à la source shadow :

• Afin de migrer les données correctement, le système de fichiers ou le répertoire source *doit être en lecture seule*. Les modifications apportées à la source des fichiers peuvent ou non être propagées selon le moment et les modifications apportées à la structure de répertoires peuvent provoquer des erreurs irréversibles sur l'appareil.

• La migration shadow prend uniquement en charge la migration à partir de sources NFS. Ce sont les partages NFSv4 qui donnent les meilleurs résultats. Les migrations NFSv2 et NFSv3 sont possibles, mais les ACL seront perdues au cours du processus et les fichiers trop volumineux pour NFSv2 ne peuvent pas être migrés à l'aide de ce protocole. La migration à partir de sources SMB n'est pas prise en charge.

• La migration shadow des LUN n'est pas prise en charge.

Au cours de la migration, si le client accède à un fichier ou à un répertoire qui n'a pas encore été migré, cela a des conséquences visibles. Le paragraphe suivant liste les sémantiques de système de fichiers shadow :

• Pour les répertoires, les requêtes des clients sont bloquées jusqu'à ce que la totalité du répertoire soit migré. Pour les fichiers, seule la partie du fichier faisant l'objet de la requête est migré et plusieurs clients peuvent migrer différentes parties d'un fichier au même moment.

• Les fichiers et les répertoires peuvent être arbitrairement renommés, supprimés ou remplacés sur le système de fichiers shadow sans que cela ait un effet sur le processus de migration.

• Pour les fichiers qui sont des liens physiques, il est possible que le nombre de liens physiques ne corresponde pas à la source tant que la migration n'est pas terminée.

• La majorité des attributs de fichier sont migrés à la création du répertoire mais la taille sur disque (st_nblocks dans la structure stat UNIX) n'est pas disponible tant qu'une opération de lecture ou d'écriture n'est pas effectuée sur le fichier. La taille logique est correcte mais une commande du(1) (disk usage) ou toute autre commande signale une valeur de taille nulle jusqu'à ce que le contenu des fichiers soit effectivement migré.

• Si l'appareil est réinitialisé, la migration reprend là où elle s'est arrêtée. Alors qu'il n'est pas nécessaire de migrer les données à nouveau, il peut être nécessaire de parcourir certaines parties du système de fichiers déjà migrées et il est possible que cette interruption ait un impact sur la durée totale de la migration.

• La migration des données fait appel à des attributs étendus privés sur les fichiers. En règle générale, ils ne sont pas visibles sauf sur le répertoire root du système de fichiers ou par le biais des instantanés. L'ajout, la modification ou la suppression d'attributs étendus qui commencent par SUNWshadow peuvent avoir des effets inconnus sur le processus de migration et peuvent entraîner un état endommagé ou incomplet. De plus, l'état filesystem-wide est stocké dans le répertoire .SUNWshadow à la racine du système de fichiers. Toute modification apportée à ce contenu aura le même effet.

• Au terme de la migration d'un système de fichiers, une alerte est envoyée et l'attribut shadow est supprimé, de même que toutes les métadonnées applicables. A ce stade, le système de fichiers est similaire à un système de fichiers normal.

• Les données peuvent être migrées depuis plusieurs systèmes de fichiers dans un seul système de fichiers en utilisant les montages des clients automatiques NFSv4 (parfois appelés "montages en miroir") ou les montages locaux imbriqués.

Afin de migrer des informations d'identité des fichiers, y compris les ACL, il est nécessaire de respecter les règles suivantes :

• Les appareils de migration source et cible doivent avoir la même configuration de service de noms.

• Les appareils de migration source et cible doivent avoir le même domaine mapid NFSv4.

• L'appareil de migration source doit prendre en charge NFSv4. L'utilisation de NFSv3 est possible, mais cela peut entraîner une perte d'informations. Les informations d'identité de base (propriétaire et groupe) et les autorisations POSIX sont conservées, mais toutes les ACL sont perdues.

• La source de la migration peut être exportée avec les autorisations root vers l'appareil.

Si vous voyez des fichiers ou des répertoires "sans propriétaire", cela signifie en général que les services de noms ne sont pas définis correctement sur l'appareil ou que le domaine mapid NFSv4 est différent. Si des messages d'erreurs s'affichent indiquant "autorisation refusée" lorsque vous parcourez les systèmes de fichiers auxquels le client devrait avoir accès, ceci est probablement dû à l'échec de l'exportation de la source de migration avec les autorisations root.