シャドウ移行

Figure 14-1  シャドウ移行

シャドウ移行は介入を使用しますが、ZFSSA に組み込まれているため、個別の物理マシンは必要ありません。シェアが作成されると、それらはオプションで、ローカルに、または NFS を介して既存のディレクトリの「シャドウを作成」できます。このシナリオでは停止時間が一度スケジュールされ、その時間にソース ZFSSA X が読み取り専用モードになり、シャドウプロパティーが設定されたシェアが作成され、Sun Storage 7000 ZFSSA でクライアントがその新しいシェアを指すように更新されます。その後、クライアントは読み取り/書き込みモードで ZFSSA にアクセスできます。

シャドウプロパティーが設定されると、データはローカルでソース ZFSSA からバックグラウンドで透過的に移行されます。まだ移行されていないファイルのリクエストがクライアントから出された場合、ZFSSA はそのリクエストに応答する前にこのファイルをローカルサーバーに自動的に移行します。この操作では、一部のクライアントリクエストで初期遅延が発生することがありますが、ファイルが移行されると、すべてのアクセスが ZFSSA に対してローカルになり、パフォーマンスが回復します。ファイルシステムの現在の作業セットは合計サイズに比べてかなり小さいことが多いため、この作業セットが移行されると、ソース上の元の合計サイズに関係なく、パフォーマンスへの影響は認められなくなります。

シャドウ移行の欠点はデータの移行が完了する前に確定が必要なことですが、このことはどの介入方法にも当てはまります。移行中は、データ部分は 2 つの場所に存在するため、バックアップがより複雑になり、スナップショットが不完全になったり、1 つのホストにしか存在しなかったりすることがあります。このため、2 つのホスト間の移行を最初に十分にテストして、アイデンティティー管理やアクセス制御が正しく設定されていることを確認することがきわめて重要です。データ移行全体をテストする必要はありませんが、新しいシステム上で、ワールドリーダブルでないファイルまたはディレクトリが正しく移行されていること、ACL (存在する場合) が保持されていること、およびアイデンティティーが適切に表現されていることを検証するようにしてください。

シャドウ移行はファイルシステム内のディスク上のデータを使用して実装されるため、ストレージプールの外側にローカルに格納される外部データベースやデータはありません。クラスタ内でプールがフェイルオーバーされた場合、または両方のシステムディスクが故障して新しいヘッドノードが必要になった場合、割り込みなしでシャドウ移行を続行するのに必要なすべてのデータはストレージプールで保持されます。