Migration traditionnelle des données

Généralement, la migration traditionnelle des fichiers fonctionne de l'une des deux manières suivantes : synchronisation répétée ou interposition externe.

Migration par synchronisation

Cette méthode consiste à prendre un hôte actif X et à migrer les données sur le nouvel hôte Y pendant que X reste actif. Les clients continuent à lire et écrire sur l'hôte d'origine alors que cette migration est en cours. Une fois que les données sont migrées, des changements progressifs sont envoyés de manière répétée, jusqu'à ce que le delta soit assez réduit pour être envoyé dans une seule fenêtre d'indisponibilité. A ce stade, le partage initial est en lecture seule, le delta final est envoyé au nouvel hôte et tous les clients sont mis à jour pour pointer vers le nouvel emplacement. La façon la plus courante de procéder est d'utiliser l'outil rsync, bien que d'autres outils intégrés existent. Ce mécanisme a plusieurs inconvénients :

• Il est difficile d'évaluer précisément la durée de l'indisponibilité mais elle est courte. Si un utilisateur effectue de nombreux changements juste avant l'indisponibilité planifiée, cela peut en allonger la durée.

• Lors de la migration, le nouveau serveur est inactif. Etant donné qu'un nouveau serveur apporte généralement de nouvelles fonctions ou des améliorations en matière de performances, de longues périodes de migration représentent un gaspillage des ressources.

• La coordination de plusieurs systèmes de fichiers est une opération fastidieuse. Lors de la migration de dizaines ou centaines de systèmes de fichiers, chaque migration a une durée différente et il convient de planifier le temps d'indisponibilité en fonction de tous les systèmes de fichiers.

Migration par interposition externe

Cette méthode consiste à prendre un hôte actif X et insérer un nouveau ZFSSA M qui migre les données vers un nouvel hôte Y. Tous les clients sont mis à jour en même temps de façon à pointer vers M et les données sont migrées automatiquement en arrière-plan. Cela permet de donner une plus grande flexibilité en termes d'options de migration (par exemple, pouvoir migrer un nouveau serveur dans le futur sans entraîner d'indisponibilité) et d'utiliser le nouveau serveur contenant les données déjà migrées. Cependant, cette méthode présente des inconvénients importants :

• L'appareil ZFSSA de migration est considéré comme une nouvelle machine physique, ce qui implique des coûts associés (investissement de départ, coûts de maintenance, alimentation et refroidissement) et autres frais de gestion.

• Il représente également un nouveau point de panne au sein du système.

• Il s'interpose entre des données déjà migrées, provoquant la mise en place d'une période de latence plus longue, souvent de manière permanente. En général, ces appareils ne sont pas retirés, bien qu'il soit possible de prévoir une autre fenêtre d'indisponibilité et d'éliminer l'appareil de migration.