シャドウ移行について

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

図 5-11  シャドウ移行

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

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

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

次に、シャドウソースの制限事項を一覧表示します。

• データを適切に移行するためには、ソースのファイルシステムまたはディレクトリが「読み取り専用である必要があります」。ファイルソースに加えられた変更が反映されるかどうかはタイミングによって異なり、ディレクトリ構造に対する変更はアプライアンスで回復不可能なエラーを発生させる可能性があります。

• シャドウ移行は NFS ソースからの移行のみをサポートします。NFSv4 シェアは最適な結果をもたらします。NFSv2 および NFSv3 移行も可能ですが、その過程で ACL が失われ、NFSv2 に対して大きすぎるファイルはそのプロトコルを使って移行できません。SMB ソースからの移行はサポートされません。

• LUN のシャドウ移行はサポートされません。

移行中に、クライアントがまだ移行されていないファイルまたはディレクトリにアクセスする場合、動作への影響を確認できます。次に、シャドウファイルシステムのセマンティクスを一覧表示します。

• ディレクトリの場合、クライアントリクエストはディレクトリ全体が移行されるまでブロックされます。ファイルの場合、ファイルの要求されている部分だけが移行されるため、複数のクライアントが同時にファイルのさまざまな部分を移行できます。

• シャドウファイルシステムでのファイルおよびディレクトリの名前変更、削除、または上書きは、移行プロセスに影響を及ぼすことなく任意に実行できます。

• ハードリンクを持つファイルの場合、移行が完了するまでハードリンク数がソースと一致しないことがあります。

• ファイル属性のほとんどはディレクトリが作成されるときに移行されますが、ディスク上のサイズ (UNIX stat 構造体の st_nblocks) はそのファイルに対する読み取りまたは書き込み操作が完了するまでわかりません。論理サイズは正しくなりますが、ファイルの内容が実際に移行されるまで、du(1) などのコマンドはサイズ 0 を報告します。

• アプライアンスをリブートした場合、移行はアプライアンスがもともと中止された場所を取り出します。データを再移行する必要はありませんが、場合によってはローカルファイルシステムの移行済みの部分をトラバースする必要があり、その割り込みのために移行の合計時間にいくらか影響が及ぶ可能性があります。

• データ移行では、ファイルに対して非公開の拡張属性を使用します。これらは通常、ファイルシステムのルートディレクトリ上で、またはスナップショットを通じてしか確認できません。SUNWshadow で始まる拡張属性の追加、変更、または削除は、移行プロセスに予測できない影響を及ぼし、不完全な状態または破壊された状態をもたらします。また、ファイルシステム全体の状態はファイルシステムのルートにある .SUNWshadow ディレクトリに格納されます。この内容に何らかの変更を加えると、同様の影響があります。

• ファイルシステムの移行が完了すると、警告が送信され、シャドウ属性が適切なメタデータとともに削除されます。その後、このファイルシステムは通常のファイルシステムと見分けがつかなくなります。

• NFSv4 自動クライアントマウント (「ミラーマウント」と呼ばれることもある) または入れ子のローカルマウントを使用すると、データを複数のファイルシステムから 1 つのファイルシステムに移行できます。

ファイルのアイデンティティー情報 (ACL を含む) を移行するには、次の規則を使用します。

• 移行元と移行先のアプライアンスのネームサービス構成が同じである必要があります。

• 移行元と移行先のアプライアンスの NFSv4 mapid ドメインが同じである必要があります

• 移行元で NFSv4 がサポートされている必要があります。NFSv3 も使用できますが、いくらかの情報の損失が発生します。基本的なアイデンティティー情報 (所有者とグループ) および POSIX アクセス権は保持されますが、ACL はすべて失われます。

• 移行元が root アクセス権を使ってアプライアンスにエクスポートされる必要があります。

「nobody」によって所有されているファイルまたはディレクトリが見つかった場合は、アプライアンスのネームサービス設定が正しくなかったり、NFSv4 mapid ドメインが異なっていたりする可能性があります。クライアントが本来ならアクセスできるはずのファイルシステムをトラバースしているときに「アクセス権が拒否されました」エラーが発生した場合、もっとも起こりうる問題は root アクセス権を使った移行元のエクスポートに失敗することです。