VMはNAS共有をセカンダリデータディスクとして使用できますか？

はい。VMはゲスト内にNFSまたはSMB共有をマウントし、セカンダリファイルストレージとして使用できます。ハイパーバイザーによっては、NAS上のストレージに仮想ディスクを配置することもできますが、この場合はゲストにブロックストレージとして提供され、障害時の挙動も異なります。

設定する前にモデルを選択してください。ファイル共有は、ドキュメント、メディア、バックアップ、共有プロジェクトデータに適しています。一方、ローカルディスクのロック、レイテンシ、または起動時の可用性を必要とするデータベースやアプリケーションでは、仮想ディスクまたはローカルストレージが適している場合があります。この違いによって、安全な設定、検証方法、ロールバックポイントが決まります。

ファイルセマンティクスとブロックセマンティクスのどちらを選ぶか

ゲストにマウントしたNFSまたはSMB共有は、ネットワークストレージとして認識されます。他のクライアントと簡単に共有できますが、ゲスト側で認証情報、ネットワーク障害、マウントの復旧を処理する必要があります。

NFSまたはiSCSIデータストア上に保存された仮想ディスクは、ゲストからはローカルブロックデバイスのように見えます。ネットワーク依存性はハイパーバイザーが管理します。また、クラスタ対応でない通常のファイルシステムを、複数のゲストで同時にマウントしてはいけません。

設計を文書化する際、マッピングされた共有をディスクと呼ばないでください。復旧手順、スナップショット、権限、破損のリスクは、実際に導入したモデルによって異なります。

データを確定する前に障害の兆候を確認する

まず共有を手動でマウントし、作成、名前変更、ロック、大容量ファイルへの書き込み、権限の継承をテストします。空のNASを見て判断するのではなく、別のクライアントに負荷をかけた状態でスループットとレイテンシを記録してください。

VMを稼働させたままNASを再起動します。アプリケーションは一時停止するか、明確に失敗し、その後、共有パスにしか見えない空のローカルマウントポイントへ書き込むことなく復旧できる必要があります。

選択した構成が本番運用に適しているか、以下の表を使って判断してください。

ネットワークとIDの依存関係を明確にする

Linuxゲストでは、systemdのオートマウント、または_netdevに対応したマウントを使用し、アプリケーションがマウントユニットに依存するように設定します。SMBでは、認証情報をシェル履歴や広く読み取り可能な設定ファイルに埋め込むのではなく、rootのみが読み取れるファイルに保存してください。

NFSのUID/GIDマッピングを合わせるか、最小権限の専用SMBサービスアカウントを使用します。信頼できるコピーがスナップショットとバックアップの対象に含まれていることを確認してください。ゲストにマウントした共有上のデータは、VMスナップショットに含まれない場合があります。

ZimaSpaceのProxmox NASセットアップガイドでは、ホストストレージに関する全体的な背景を説明しています。

実用的な集中型ホームラボストレージガイドでは、VMやコンテナ内でのNFSとSMBのマウントを比較しています。

Featured

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

ZimaCube2

$799.00 - $2,499.00

Buy Now

元のワークロードとNAS障害を再テストする

代表的なデータをコピーし、実際のアプリケーションを実行してVMを再起動します。サービスが書き込みを行う前にマウントが存在することを確認してください。正常なNASメンテナンスと、突然のネットワーク切断の両方をテストします。

VMは個別に復元し、NAS上のデータがゲストイメージだけでなく、NASのバックアップ計画によって復元されることを運用担当者が理解しているか確認します。2つの独立した復元プロセスが同じデータセットを上書きしないようにしてください。

プロトコルがワークロードに適合し、起動時の依存関係が適用され、障害時の挙動が安全であれば進めてください。アプリケーションが気付かないうちにローカルストレージへフォールバックする場合、ロックに失敗する場合、またはデータベースベンダーが選択したネットワークファイルシステムをサポートしていない場合は中止してください。