Migration shadow

Figure 14-1  Migration shadow

La migration shadow utilise l'interposition mais est intégrée dans l'appareil ZFSSA 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 ZFSSA 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 ZFSSA Sun Storage 7000. Les clients peuvent ensuite accéder à l'appareil en mode lecture-écriture.

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 ZFSSA source. Si un client envoie une requête pour un fichier qui n'a pas été encore été migré, l'appareil ZFSSA 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.