pmxcfs(8)

名前

pmxcfs - Proxmox クラスタファイルシステム

SYNOPSIS

pmxcfs [OPTIONS］

ヘルプオプション：

-h,--help: ヘルプオプションの表示

アプリケーションオプション：

-d,--debug: デバッグメッセージをオンにします。
-f,--foreground: サーバーをデーモン化しない
-l,--local: ローカルモードを強制 (corosync.conf を無視し、クォーラムを強制)

このサービスは通常 systemd ツールセットを使って起動・管理されます。このサービスはpve-cluster と呼ばれます。

systemctl start pve-cluster

systemctl stop pve-cluster

systemctl status pve-cluster

説明

Proxmox Clusterファイルシステム("pmxcfs")は、設定ファイルを保存するためのデータベース駆動型のファイルシステムで、corosyncを使用してすべてのクラスタノードにリアルタイムでレプリケートされます。Proxmox VEに関連するすべての設定ファイルを保存するために使用します。

ファイルシステムはすべてのデータをディスク上の永続データベース内に格納しますが、データのコピーはRAMに存在します。このため、最大サイズには制限があり、現在は128メガバイトです。これでも数千台の仮想マシンの設定を保存するには十分です。

このシステムには次のような利点があります：

すべての設定をリアルタイムで全ノードにシームレスにレプリケーション
VM IDの重複を避けるための強力な一貫性チェックを提供します。
ノードがクォーラムを失った場合の読み取り専用
全ノードへのcorosyncクラスタ構成の自動更新
分散ロック機構付き

POSIX 互換性

ファイルシステムはFUSEをベースにしているので、動作はPOSIXライクです。しかし、いくつかの機能は単に実装されていません：

通常のファイルやディレクトリは生成できますが、シンボリックリンクは生成できません。
空でないディレクトリの名前は変更できません（この方がVMIDが一意であることを保証しやすくなるからです）。
ファイルのパーミッションは変更できません。
O_EXCLの作成は（古いNFSのように）アトミックではありませんでした。
O_TRUNCの作成はアトミックではありません（FUSEの制限）。

ファイルアクセス権

すべてのファイルとディレクトリはユーザーrootによって所有され、グループwww-dataを持っています。rootのみが書き込み権限を持ちますが、グループwww-dataはほとんどのファイルを読むことができます。以下のパス以下のファイルは、rootによってのみアクセス可能です：

/etc/pve/priv//etc/pve/nodes/${NAME}/priv/。

テクノロジー

クラスタ通信にはCorosync Cluster Engineを、データベースファイルにはSQliteを使用しています。ファイルシステムはFUSEを使用してユーザ空間に実装されています。

ファイルシステムレイアウト

ファイルシステムは

/etc/pve

ファイル

authkey.pub

チケットシステムで使用される公開鍵

ceph.conf

Ceph構成ファイル(注意: /etc/ceph/ceph.confはこれへのシンボリックリンクです)

corosync.conf

Corosyncクラスタ設定ファイル(Proxmox VE 4.x以前はcluster.conf)

datacenter.cfg

Proxmox VEのデータセンター全体の設定（キーボードレイアウト、プロキシ、...）

domains.cfg

Proxmox VE認証ドメイン

ファイアウォール/クラスタ.fw

すべてのノードに適用されるファイアウォール設定

ファイアウォール/<NAME>.fw

各ノードのファイアウォール設定

ファイアウォール/<VMID>.fw

VMとコンテナのファイアウォール設定

ha/crm_commands

CRM が現在実行している HA オペレーションを表示します。

ha/manager_status

クラスタ上のHAサービスに関するJSON形式の情報

ha/resources.cfg

高可用性によって管理されるリソースとその現在の状態

nodes/<NAME>/config

ノード固有の設定

nodes/<NAME>/lxc/<VMID>.conf

LXCコンテナのVM構成データ

nodes/<NAME>/openvz/です。

Proxmox VE 4.0以前では、コンテナ設定データに使用されていました。

nodes/<NAME>/pve-ssl.key

pve-ssl.pemのSSL秘密鍵

nodes/<NAME>/pve-ssl.pem

ウェブサーバ用のパブリックSSL証明書（クラスタCAによって署名されたもの）

nodes/<NAME>/pveproxy-ssl.key

pveproxy-ssl.pemの SSL 秘密鍵 (オプション)

nodes/<NAME>/pveproxy-ssl.pem

ウェブサーバの公開SSL証明書(チェーン) (pve-ssl.pemのオプションのオーバーライド)

nodes/<NAME>/qemu-server/<VMID>.conf

KVMのVM設定データ

priv/authkey.key

チケットシステムで使用される秘密鍵

priv/authorized_keys

認証用クラスタメンバーのSSHキー

priv/ceph*

Ceph認証キーと関連機能

priv/known_hosts

検証用クラスタ・メンバーのSSH鍵

priv/lock/*

クラスタ全体の安全な運用を保証するために、さまざまなサービスで使用されるファイルをロックします。

priv/pve-root-ca.key。

クラスタCAの秘密鍵

priv/shadow.cfg

PVE Realmユーザー用シャドウパスワードファイル

priv/storage/<ストレージID>.pw

ストレージのパスワードがプレーンテキストで格納されています。

priv/tfa.cfg

Base64 エンコードされた二要素認証設定

priv/token.cfg

すべてのAPIトークンの秘密

pve-root-ca.pem

クラスタ CA のパブリック証明書

pve-www.key

CSRF トークンの生成に使用される秘密鍵

sdn/*

ソフトウェア・デファインド・ネットワーキング（SDN）のための共有設定ファイル

ステータス.cfg

Proxmox VEの外部メトリクス・サーバー構成

storage.cfg

Proxmox VEのストレージ構成

ユーザー設定

Proxmox VEのアクセス制御設定(ユーザー/グループ/...)

仮想ゲスト/cpu-models.conf

カスタムCPUモデル保存用

vzdump.cron

クラスタ全体のvzdumpバックアップジョブスケジュール

シンボリックリンク

クラスタ・ファイル・システム内の特定のディレクトリは、ノード独自の設定ファイルを指すためにシンボリックリンクを使用します。したがって、以下の表で指すファイルはクラスタの各ノードで異なるファイルを指します。

ローカル

ノード/<LOCAL_HOST_NAME

エルエックス

nodes/<LOCAL_HOST_NAME>/lxc/

オープンベッツ

nodes/<LOCAL_HOST_NAME>/openvz/(非推奨、近日削除)

qemu-server

nodes/<LOCAL_HOST_NAME>/qemu-server/ です。

デバッグ用の特別なステータスファイル (JSON)

バージョン

ファイルのバージョン（ファイルの変更を検出）

メンバー

クラスタメンバーに関する情報

.vmlist

すべてのVMのリスト

クラスタログ

クラスターログ（直近50件）

.rrd

RRDデータ（最新のもの）

デバッグの有効/無効

で冗長なsyslogメッセージを有効にできます：

echo "1" >/etc/pve/.debug

で、冗長なsyslogメッセージを無効にします：

echo "0" >/etc/pve/.debug

リカバリー

ハードウェアの問題など、Proxmox VEホストに大きな問題がある場合、pmxcfsデータベースファイル/var/lib/pve-cluster/config.dbをコピーして、新しいProxmox VEホストに移動すると便利です。新しいホスト (何も実行していない状態) では、pve-clusterサービスを停止してconfig.dbファイルを置き換える必要があります (必要なパーミッションは0600)。この後、/etc/hostnameと /etc/hostsを失ったProxmox VEホストに合わせ、再起動して確認します（VM/CTデータも忘れずに）。

クラスタ構成の削除

推奨される方法は、クラスタからノードを削除した後にノードを再インストールすることです。これにより、すべての秘密クラスタ/sshキーと共有設定データが破棄されます。

場合によっては、再インストールせずにノードをローカルモードに戻したいこともあります。

故障したノードからのゲストの回復/移動

nodes/<NAME>/qemu-server/(VM)およびnodes/<NAME>/lxc/(コンテナ)内のゲスト設定ファイルについて、Proxmox VEはそれぞれのゲストの所有者として含まれるノード<NAME>を認識します。このコンセプトにより、ゲスト設定の同時変更を防止するために、高価なクラスタ全体のロックの代わりにローカルロックを使用できます。

その結果、ゲストの所有ノードに障害が発生した場合(たとえば、停電、フェンシングイベントなど)、(オフラインの)所有ノードのローカルロックが取得できないため、(すべてのディスクが共有ストレージにある場合でも)通常のマイグレーションはできません。Proxmox VEの高可用性スタックには、フェンスで保護されたノードからのゲストの正しい自動回復を保証するために必要な（クラスタ全体の）ロックとウォッチドッグ機能が含まれているため、これはHA管理されたゲストの問題ではありません。

HA管理されていないゲストが共有ディスクのみを持つ場合 (そして、障害ノードでのみ利用可能な他のローカルリソースがない場合)、/etc/pve/内の障害ノードのディレクトリからオンラインノードのディレクトリにゲスト設定ファイルを移動するだけで、手動での復旧が可能です (これにより、ゲストの論理的な所有者または場所が変更されます)。

たとえば、ID100のVMをオフラインのノード1から別のノードnode2にリカバリするには、クラスタの任意のメンバーノードでrootとして次のコマンドを実行します：

mv /etc/pve/nodes/node1/qemu-server/100.conf /etc/pve/nodes/node2/qemu-server/

このようにゲストを手動でリカバリする前に、障害が発生したソースノードが本当に電源オフ/フェンスされていることを絶対に確認してください。そうしないと、Proxmox VE のロックの原則がmvコマンドによって破られ、予期しない結果を招く可能性があります。

ローカルディスク(またはオフラインノードでのみ利用可能なその他のローカルリソース)を持つゲストは、この方法では復旧できません。障害が発生したノードがクラスタに再参加するのを待つか、バックアップからそのようなゲストをリストアしてください。

著作権および免責事項

このプログラムはフリー・ソフトウェアです。あなたは、Free Software Foundationによって発行されたGNU Affero General Public Licenseのバージョン3、またはそれ以降のバージョンのいずれかに従って、このプログラムを再配布したり、変更したりすることができます。

このプログラムは有用であることを期待して配布されていますが、商品性や特定の目的への適合性についての暗黙の保証もなく、いかなる保証もありません。詳細はGNU Affero General Public Licenseをご覧ください。

あなたはこのプログラムとともにGNU Affero General Public Licenseのコピーを受け取っているはずです。そうでない場合は、https://www.gnu.org/licenses/をご覧ください。