名前を変更したデータセットと安定したファイルハンドルのためのNFS移行チェックリスト

エヴァ・ウォン

IceWhale author

エヴァ・ウォン は テクニカルライター であり ZimaSpaceの常駐ティンカーでもあります。 生涯のオタクであり、 ホームラボとオープンソースソフトウェアに情熱を持っています。彼女は複雑な技術的概念をわかりやすく、 実践的なガイドに翻訳することを専門としています。エヴァはセルフホスティングは楽しくあるべきで、怖がるものではないと信じています。彼女のチュートリアルを通じて、コミュニティが ハードウェアのセットアップを解明する手助けをしています。初めてのNAS構築からDockerコンテナの習得まで。

NFS Migration Checklist for Renamed Datasets and Stable File Handles - Zima Store Online

安全なアプローチでは、可能な限りクライアント向けの名前空間を維持し、ハンドルの識別情報が変わる場合は意図的にクライアントを再マウントする、一時停止状態でのエクスポート移行を、単一のコマンドではなく、観測可能なゲートの連続として扱います。

ホームサーバークライアントが使用するNASデータセットをLinux NFSサーバー上で移行する場合、エクスポートされたデータセットの名前変更や移動によって、クライアントに古いNFSファイルハンドルや再マウント失敗が残る可能性があります。現在の識別情報と復旧ポイントを記録し、最も影響の小さい判別手順から開始して、別の変数を変更する前に成功・失敗の結果を解釈します。ストレージが不安定になった場合や、復旧可能なコピーしか公開できなくなった場合は停止します。以下のワークフローは、元のワークロードが成功するか、証拠がエスカレーションの境界に達するまで続きます。

エクスポートとファイルハンドルの依存関係を調査する

ソースのファイルシステムまたはデータセットの識別情報、サーバー側のパス、NFSv4擬似ルート、エクスポートオプション、明示的なfsid値、クライアントのマウントパス、autofsまたはsystemdのユニット、そしてマウントを使用するすべてのコンテナやアプリケーションを記録します。ダウンタイムを計画する前に、アクティブなマウントと開いているファイルを取得します。

NFSファイルハンドルには、サーバーが選択したオブジェクトの識別情報が含まれるため、パス文字列が変わっていなくても、ファイルシステムの移動後にハンドルが安定しているとは限りません。独立したNFSの古いファイルハンドルの仕組みでは、ディレクトリが見た目上存在していても、削除、再作成、または再マッピングされたエクスポートによって古いハンドルが生成される仕組みを説明しています。

目標が名前空間の安定性なのか、稼働中のハンドルの継続性なのかを決めます。クライアント向けのパスを維持すれば設定変更は減りますが、データを別のファイルシステムへ移動する場合は、すべてのクライアントでアンマウントして新しいハンドルを取得する必要がある可能性があります。

クライアントをソースに接続したままターゲットを準備する

ターゲットデータセットを作成し、ACL、所有者、拡張属性、ハードリンク、スパースファイル、タイムスタンプを保持した状態でデータをコピーして、件数と代表的なハッシュを比較します。ターゲットを本番クライアントに公開する前に、エクスポートのセキュリティ設定とIDマッピングを一致させます。

NFSv4 IDマッピングガイドのZimaSpaceガイドを使用して、Linuxサーバー間でNFSv4の識別情報を揃えます。安定したファイルハンドルだけでは、数値所有者や名前ドメインの不一致は解決しないため、ファイル識別情報の層とユーザー識別情報の層をそれぞれ個別に検証します。

コピー方法が対応している場合に限り、ソースが稼働中の状態で初回同期を実行し、その後に停止状態で最終差分を同期する計画を立てます。同じクライアント名前空間で両方のコピーを読み書き可能な状態でエクスポートしないでください。明確な障害がないまま書き込み内容が分岐する可能性があります。

クライアントを停止してエクスポートを切り替える

すべてのクライアントで、アプリケーションの書き込み処理、コンテナ、スケジュール済みジョブを停止し、重要なプロセスがマウント配下のファイルを保持していないことを確認します。クライアントを正常にアンマウントします。最終同期後、ソースをアンエクスポートするか読み取り専用にし、サーバー側のマウントまたはエクスポートをターゲットに切り替えて、エクスポートを再読み込みします。

GitLabによるNFSの名前変更と古い状態に関する事例では、名前変更や委任の動作によって、クライアント側で古い、または一貫性のない状態が観測される可能性が示されています。安全な運用上の対応は、アプリケーションが書き込みを続けている間にキャッシュクリアコマンドを繰り返すことではなく、計画的に処理を停止して再マウントすることです。

ターゲットによってファイルシステムの識別情報が変わる場合は、新しいハンドルが生成されることを想定し、クライアントを新たにマウントします。元のエクスポートは本番以外の復旧用の名前で利用できる状態にしておきますが、古いツリーと新しいツリーの両方で競合する書き込みを受け付けないでください。

Featured

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

ZimaCube2

すべてのクライアントを再マウントして新しい識別情報を確認する

まずカナリアクライアントを1台だけ再マウントし、一覧表示、読み取り、作成、名前変更、削除、ファイルロック、所有権をテストします。依存するアプリケーションを再起動し、元のワークロードを確認します。その後、残りのクライアントを順番に切り替え、マウント元、NFSバージョン、古いハンドルのエラーがないことを記録します。

カナリアで再起動またはオートマウントを再起動し、永続的な設定が安定したクライアント向け名前空間を指していることを確認します。サーバーログ、クライアントカーネル、バックアップジョブ、コンテナを確認し、古いパスが隠れて残っていないか調べます。手動マウントが成功しても、起動順序やサービス依存関係が正しいとは限りません。

すべてのクライアントが再マウントされ、通常のジョブが成功し、バックアップが成功して、さらに1回のリストアをテストできるまで、ソースを廃止しないでください。カナリアが失敗した場合は、新しい書き込みを受け付ける前にロールバックします。ターゲットへの書き込みが始まった後は、エクスポートを何度も切り替えるのではなく、停止して意図的に内容を突き合わせます。