クライアントから見えるエクスポートパスを変更せずにNFSデータセットを再編成する方法

クライアントから見えるエクスポート名前空間を安定させたまま、その背後でストレージを移動すれば、古いクライアントハンドルを発生させずにNFSデータセットを再編成できます。

予防的な設計では、クライアントがマウントするパスと、後から変更する可能性のある物理データセット名を分離します。安定したエクスポートツリーを構築し、データセットを意図的に割り当て、可能な限りファイルシステムの識別情報を維持し、破壊的な置換の前にクライアントを停止し、切り替え後も同じエクスポートパスを確認します。サーバー側でバッキングファイルシステムを破棄して再作成する必要がある場合は、これを識別情報の変更として扱い、見えないまま継続できると約束するのではなく、クライアントの協調的な再マウントを計画してください。

データセットの上位に安定したエクスポート名前空間を作成する

専用のNFSエクスポートルートを使用し、クライアントから見える名前が内部のZFSまたはBtrfsデータセット名をすべて反映しないようにします。これにより、ストレージ管理者は、すべてのクライアントに新しいマウントパスを教え直すことなく、バックエンドのデータセットを再編成できます。

NFSv4の設計に関する議論では、意図的に管理された擬似ファイルシステムの下で、バインドマウントによって安定したエクスポートを作成する方法が説明されています。

クライアントパスを互換性の契約として文書化します。内部のデータセット名は後から変更できますが、その前にエクスポート層を再割り当てし、同じパスに対してテストする必要があります。

検出順序に頼らず、エクスポートの識別情報を固定する

現在のサーバーで使用しているファイルシステムUUID、エクスポートパス、NFSバージョン、明示的なfsid設定を記録します。NFSサーバーが移動後に基盤となるファイルシステムを異なる方法で識別する場合、同じ表示ディレクトリ名だけでは不十分です。

SUSEは、NFSが各エクスポートファイルシステムを識別することを説明しており、エクスポートを単純なパス名のエイリアスとして扱っているわけではありません。

明示的な識別子は、NFS実装がサポートしている場合にのみ使用し、それぞれの値を一意に保ちます。2つの同時にエクスポートされるファイルシステムに同じfsidを割り当て、同一に見せかけようとしてはいけません。

同じエクスポートパスの背後に新しいデータセットを準備する

一時的なサーバー側パスに置換用のデータセットを作成または受信し、内容をコピーまたはレプリケートして権限を確認したうえで、メンテナンス時間中に安定したエクスポートツリーへ割り当てます。ロールバック用に古いデータセットは保持しますが、同じエクスポート識別情報でアクティブにしてはいけません。

NFSエクスポートの例では、1つのNFS名前空間の下に複数のファイルシステムが現れる場合に、マウントされたサブツリーを意図的にエクスポートする方法が示されています。

切り替えでは、クライアントのマウント定義とデータセットの識別情報を同時に変更するのではなく、サーバー側のマッピングを1つ変更するだけにします。これにより、新しいツリーに問題があった場合でも、トラブルシューティングの手がかりを維持できます。

Featured

ZimaCube 2 パーソナルクラウドホームNAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

バッキングファイルシステムを置き換える前に書き込みを停止する

NFSマウントを通じてアクティブに書き込んでいるサービスを停止または一時停止し、切り替え中に重要なクライアントが長時間のファイル操作を保持していないことを確認します。書き込みを停止した後に、最後の同期を完了させます。

IBMは、クライアント状態が継続性の一部であり、サーバー側のファイル内容だけに関係するものではないため、NFSv4の状態情報には安定したストレージが必要であることを説明しています。

ホームサーバーでは、クラスターフェイルオーバーほど複雑な対応は必要ありません。アクティブなアプリケーションの実行中にファイルの識別情報を変更しないことが重要です。短時間の計画的な停止のほうが、データベース、メディア、バックアップのクライアントに、稼働中のファイルシステム置換への対応を強いるより安全です。

クライアントの再マウントが避けられない場合を把握する

再編成によってファイルシステムを破棄して再作成する場合、新しいファイルシステムとしてスナップショットを復元する場合、またはサーバー側のファイルハンドル識別情報を変更する場合は、サーバーパスが安定した後に、計画的なアンマウントと再マウントを行います。

最新のNFSトラブルシューティングガイドでは、サーバーの識別情報の変更が古いハンドルを発生させることを説明し、問題が再発する場合はサーバーの識別情報が安定しているか確認するよう推奨しています。

基盤となる識別情報が実際に変わる場合に、「再マウント不要」のメンテナンスを謳わないでください。アプリケーションが通常の書き込み中にESTALEを検出するより、文書化された再マウント時間を設けるほうが適切です。

古いデータセットを廃止する前にクライアントパスをテストする

新しいクライアントと、既存の重要ではないクライアントの1台からエクスポートをマウントし、ディレクトリの識別情報、権限、代表的な読み取り、可逆的な書き込みを1回、そしてアプリケーションが想定するパスを比較します。クライアントを1台再起動し、永続的なマウント設定が変更されていないことを確認します。

Arch Linuxの事例では、安定したNFSルートによって、バックエンドのファイルシステム変更後もESTALEを回避できることが示されています。

クライアントが元のエクスポートパスを使い続け、隠れた参照なしに古いデータセットを廃止できれば、再編成は完了です。データセットの名前変更後に発生した古いハンドルへの対処に関するZimaSpaceの関連記事は、すでにESTALEが発生している場合の復旧手順です。