従来のデータ移行

通常、従来のファイル移行は反復同期または外部介入のどちらかの方法で行われます。

同期による移行

この方法では、アクティブなホスト X を取り、X をアクティブにしたままデータを新しいホスト Y に移行します。この移行の進行中も、クライアントは引き続き元のホストに対して読み取り/書き込みを行います。データが最初に移行されると、差分が 1 回の停止時間帯で送信できるほど小さくなるまで増分変更が繰り返し送信されます。この時点で、元のシェアは読み取り専用になり、最後の差分が新しいホストに送信されて、すべてのクライアントが新しい場所を指すように更新されます。これを実行するもっとも一般的な方法は再同期ツールを使用することですが、ほかの統合ツールも存在します。このメカニズムにはいくつかの欠点があります。

• 差分が小さくなる間、予測される停止時間を簡単に定量化できません。スケジュールされた停止時間の直前にユーザーが大量の変更を確定した場合は、停止時間帯が長くなる可能性があります。

• 移行中は、新しいサーバーがアイドル状態になります。通常、新しいサーバーでは新しい機能が追加されたりパフォーマンスが向上したりしているため、長期間に及ぶ可能性のある移行中にリソースが浪費されることなります。

• 複数のファイルシステム間での調整には手間がかかります。何十または何百ものファイルシステムを移行する場合、各移行にかかる時間はさまざまで、ファイルシステム全体にわたって停止時間をスケジュールする必要があります。

外部介入による移行

この方法では、アクティブなホスト X を取り、データを新しいホスト Y に移行する新しい ZFSSA M を挿入します。すべてのクライアントはただちに M を指すように更新され、データはバックグラウンドで自動的に移行されます。これにより、移行オプションの柔軟性が向上し (将来は停止時間なしに新しいサーバーに移行できるなど)、移行済みのデータに新しいサーバーを利用できますが、重大な欠点もあります。

• 移行 ZFSSA は新しい物理マシンを表し、関連コスト (初期投資、サポート費用、電力、および冷却) と追加の管理オーバーヘッドがかかります。

• 移行 ZFSSA は、システム内の新しい障害点を表します。

• 移行 ZFSSA は移行済みのデータに介入するため、多くの場合、永続的に追加の待機時間を発生させます。通常、これらの ZFSSA は所定の場所に置かれますが、別の停止時間帯をスケジュールしたり、移行 ZFSSA を廃止したりできます。