pvecm(1)

Datacenter → Cluster］で、［Create Cluster］をクリックします。クラスタ名を入力し、ドロップダウン・リストからメインのクラスタ・ネットワーク（リンク0）として使用するネットワーク接続を選択します。デフォルトは、ノードのホスト名で解決されたIPです。

Proxmox VE 6.2では、クラスタに最大8つのフォールバックリンクを追加できます。冗長リンクを追加するには、Addボタンをクリックし、それぞれのフィールドからリンク番号とIPアドレスを選択します。Proxmox VE 6.2以前では、フォールバックとして2つ目のリンクを追加するには、Advancedチェックボックスを選択し、追加のネットワークインターフェース（リンク1、Corosyncの冗長性も参照）を選択します。

最初のProxmox VEノードにssh経由でログインし、以下のコマンドを実行します：

新しいクラスタの状態を確認するには、次のコマンドを使用します：

同じ物理ネットワークまたは論理ネットワークに複数のクラスタを作成することができます。この場合、クラスタ通信スタックでの衝突を避けるため、各クラスタに一意の名前を付ける必要があります。さらに、クラスタを明確に区別できるようにすることで、人間の混乱を避けることができます。

corosyncクラスタの帯域幅要件は比較的低いものの、パッケージのレイテンシと1秒あたりのパッケージ（PPS）レートが制限要因となります。同じネットワーク内の異なるクラスタは、これらのリソースをめぐって互いに競合する可能性があるため、大規模なクラスタには別の物理ネットワークインフラを使用することが理にかなっている場合があります。

既存のクラスタ・ノードでWebインタフェースにログインします。Datacenter → Clusterで、上部のJoin Informationボタンをクリックします。次に、［情報をコピー］ボタンをクリックします。または、［情報］フィールドの文字列を手動でコピーします。

次に、追加するノードのWebインタフェースにログインします。Datacenter → Clusterで、Join Clusterをクリックします。情報]フィールドに、先ほどコピーした[参加情報]テキストを入力します。 クラスタへの参加に必要なほとんどの設定が自動的に入力されます。セキュリティ上の理由から、クラスタのパスワードは手動で入力する必要があります。

Joinボタンをクリックすると、クラスタ参加プロセスが直ちに開始されます。ノードがクラスタに参加すると、現在のノード証明書はクラスタ認証局(CA)から署名されたものに置き換えられます。 つまり、現在のセッションは数秒後に機能しなくなります。この場合、Webインタフェースを強制的にリロードし、クラスタ認証情報を使用して再度ログインする必要があります。

これで、Datacenter → Clusterにノードが表示されるはずです。

既存のクラスタに参加させたいノードにsshでログインします。

IP-ADDRESS-CLUSTERには、既存のクラスタ・ノードのIPまたはホスト名を使用します。 IPアドレスを使用することをお勧めします(「リンク・アドレスの種類」を参照)。

クラスタの状態を確認するには

全ノードのリストだけが必要な場合は、次のようにします：

クラスタ・ネットワークが分離されているクラスタにノードを追加する場合は、link0パラメータを使用してそのネットワーク上のノードのアドレスを設定する必要があります：

クロノスネットのトランスポート・レイヤーに内蔵されている冗長性を使用したい場合は、link1パラメータも使用してください。

GUIを使用して、Cluster Joinダイアログの対応するLink Xフィールドから正しいインターフェイスを選択できます。

ノードを最初から再インストールせずに、クラスタからノードを分離することもできます。ただし、クラスタからノードを削除した後も、そのノードは共有ストレージにアクセスできます。これは、クラスタからノードの削除を開始する前に解決しておく必要があります。Proxmox VEクラスタは他のクラスタとまったく同じストレージを共有することはできません。さらに、VMIDの競合につながる可能性もあります。

分離したいノードだけがアクセスできる新しいストレージを作成することをお勧めします。例えば、NFS上の新しいエクスポートや新しいCephプールなどです。まったく同じストレージが複数のクラスタからアクセスされないようにすることが重要です。このストレージを設定したら、すべてのデータとVMをノードからそのストレージに移動します。これで、クラスタからノードを分離する準備が整いました。

まず、ノードのcorosyncとpve-clusterサービスを停止します：

クラスタファイルシステムをローカルモードで再度起動します：

corosync設定ファイルを削除します：

これで、ファイルシステムを通常のサービスとして再開できます：

これでノードはクラスタから切り離されました。クラスタの残りのノードから削除するには

残りのノードのクォーラムが失われたためにコマンドが失敗した場合、回避策として予想得票数を1に設定することができます：

そしてpvecm delnodeコマンドを繰り返します。

次に、分離したノードに戻り、そのノードに残っているクラスタファイルをすべて削除します。これにより、ノードを問題なく別のクラスタに追加できるようになります。

他のノードの設定ファイルがまだクラスタ ファイル システムに残っているため、それらもクリーンアップします。ノード名が正しいことを確認したら、/etc/pve/nodes/NODENAMEからディレクトリ全体を再帰的に削除します。

Proxmox VEクラスタスタックを安定して動作させるには、全ノード間のレイテンシが5ミリ秒（LANパフォーマンス）以下の信頼性の高いネットワークが必要です。ノード数が少ないセットアップでは、より高いレイテンシのネットワークでも動作する可能性がありますが、これは保証されておらず、ノード数が3つ以上、レイテンシが約10ミリ秒を超えると、むしろ可能性が低くなります。

corosyncはあまり帯域幅を使用しませんが、レイテンシのジッターの影響を受けやすいので、ネットワークは他のメンバーによって多用されるべきではありません。 特に、corosyncとストレージに共有ネットワークを使わないでください（冗長構成で優先順位の低いフォールバックの可能性を除いて）。

クラスタをセットアップする前に、ネットワークがその目的に適しているかどうかを確認することは良い習慣です。クラスタ・ネットワーク上でノードが互いに接続できることを確認するには、pingツールでノード間の接続性をテストします。

Proxmox VEファイアウォールが有効な場合、corosyncのACCEPTルールが自動的に生成されます。

パラメータなしでクラスタを作成する場合、corosyncクラスタのネットワークは通常、WebインタフェースおよびVMのネットワークと共有されます。セットアップによっては、ストレージトラフィックも同じネットワーク上で送信されるかもしれません。corosyncはタイムクリティカルでリアルタイムなアプリケーションなので、これを変更することをお勧めします。

corosyncリンクアドレス（後方互換性のため、corosync.confでは ringX_addrと表記）は、2つの方法で指定できます：

ホスト名を優先する場合は、corosync専用の別個の静的ホスト名を推奨します。また、クラスタ内のすべてのノードがすべてのホスト名を正しく解決できることを確認してください。

Proxmox VE 5.1以降、サポートされている間は、ホスト名は入力時に解決されます。解決されたIPのみが設定に保存されます。

以前のバージョンでクラスタに参加したノードは、corosync.confで未解決のホスト名をまだ使用している可能性があります。上記のように、IPまたは別のホスト名で置き換えるのが良いかもしれません。

実行中のコンフィギュレーションに新しいリンクを追加するには、まずcorosync.confファイルの編集方法を確認してください。

次に、nodelistセクションのすべてのノードに新しいringX_addr を追加します。Xはどのノードに追加しても同じで、各ノードで一意であることを確認してください。

最後に、Xを上記で選択したリンク番号に置き換えて、下図のような新しいインターフェイスを トーテムセクションに追加します。

1番のリンクを追加したと仮定すると、新しい設定ファイルは次のようになります：

最後の手順でcorosync.confファイルを編集すると、すぐに新しいリンクが有効になります。再起動は必要ありません。corosyncが新しいリンクを読み込んだかどうかは、次のようにして確認できます：

1つのノードで古いリンクを一時的に切断し、切断中もステータスがオンラインであることを確認して、新しいリンクをテストするのがよいでしょう：

健全なクラスタ状態が表示された場合は、新しいリンクが使用されていることを意味します。

Proxmox VEシステムでは、SSH設定/セットアップに以下の変更が行われます：

カスタム.bashrc や、設定されたシェルによってログイン時に実行される類似の ファイルがある場合、セッションが正常に確立されると、sshは自動的にそれを 実行します。これは予期せぬ動作を引き起こす可能性があります。 なぜなら、これらのコマンドは上記のどの操作に対しても root 権限で実行される可能性があるからです。これは問題となる副作用を引き起こす可能性があります！

このようなややこしいことを避けるためには、/root/.bashrcに、セッションが対話型であることを確認するチェックを追加し、その上で.bashrcコマンドを実行することをお勧めします。

このスニペットを.bashrcファイルの先頭に追加してください：

Corosync Quorum Device (QDevice)は、各クラスタノード上で動作するデーモンです。外部で実行されるサードパーティのアービトレーターの決定に基づいて、クラスタのクォーラムサブシステムに設定された投票数を提供します。 このデバイスの主な用途は、標準のクォーラムルールが許容するよりも多くのノード障害をクラスタが維持できるようにすることです。外部デバイスはすべてのノードを見ることができるため、これは安全に行うことができます。 これは、サードパーティの投票を受け取った後、そのノードのセットがクォーラムを（再び）持つことができる場合にのみ行われます。

現在、QDevice Netのみがサードパーティ・アービトレーターとしてサポートされています。これは、ネットワーク経由でパーティションメンバーに到達できる場合、クラスタのパーティションに投票を提供するデーモンです。複数のクラスタをサポートするように設計されており、設定やステートはほとんど不要です。新しいクラスタは動的に処理され、QDeviceを実行しているホスト上に設定ファイルは必要ありません。

外部ホストの唯一の要件は、クラスタへのネットワークアクセスが必要であることと、corosync-qnetdパッケージが利用可能であることです。私たちはDebianベースのホスト用のパッケージを提供していますが、他のLinuxディストリビューションでもそれぞれのパッケージマネージャから利用可能なパッケージがあるはずです。

偶数ノード数のクラスタではQDeviceをサポートし、2ノードクラスタではより高い可用性を提供する場合に推奨しています。 奇数ノード数のクラスタでは、現在のところQDeviceの使用を推奨していません。その理由は、クラスタタイプごとにQDeviceが提供する投票数に差があるためです。偶数のクラスタには追加の票が1票入りますが、これは可用性を高めるだけで、QDevice自体に障害が発生した場合は、QDeviceをまったく使用しない場合と同じ状態になるからです。

一方、クラスタサイズが奇数の場合、QDeviceは(N-1)票を提供します。この代替動作は理にかなっています。もしQDeviceに1票しか追加の票がなかったら、クラスタは脳が分裂したような状況に陥る可能性があります。このアルゴリズムでは、1つのノード（当然QDevice自体も）を除くすべてのノードが失敗することができます。しかし、これには2つの欠点があります：

欠点とその意味を理解すれば、奇数クラスタのセットアップでこの技術を使うかどうかを自分で決めることができます。

corosync-qdeviceへの投票を提供するデーモンは、非特権ユーザーとして実行することをお勧めします。Proxmox VEとDebianにはそのように設定されたパッケージが用意されています。 Proxmox VEにQDeviceを安全かつセキュアに統合するには、デーモンとクラスタ間のトラフィックを暗号化する必要があります。

まず、外部サーバーにcorosync-qnetdパッケージをインストールします。

とcorosync-qdeviceパッケージを全クラスタノードにインストールします。

これを実行した後、クラスタ内のすべてのノードがオンラインであることを確認します。

Proxmox VEノードの1つで以下のコマンドを実行して、QDeviceをセットアップできます：

クラスタのSSHキーが自動的にQDeviceにコピーされます。

すべてのステップが正常に完了すると、「完了」と表示されます。でQDeviceがセットアップされたことを確認できます：

corosync.confファイルの編集は必ずしも簡単ではありません。各クラスタ・ノードに2つあり、1つは/etc/pve/corosync.confに、もう1つは/etc/corosync/corosync.confにあります。クラスタ・ファイル・システムにあるものを編集すると、ローカルのものに変更が伝搬しますが、その逆はできません。

ファイルが変更されるとすぐに、設定は自動的に更新されます。 つまり、実行中のcorosyncに統合できる変更はすぐに反映されます。従って、編集中にファイルを保存する際に意図しない変更を引き起こさないように、常にコピーを作成し、代わりにそれを編集する必要があります。

次に、すべてのProxmox VEノードにプリインストールされているnanoやvim.tinyなどのお気に入りのエディタで設定ファイルを開きます。

必要な変更を行った後、現在の作業用設定ファイルのコピーをもう1つ作成します。これは、新しい設定の適用に失敗したり、その他の問題が発生した場合のバックアップとして機能します。

そして、古い設定ファイルを新しいものに置き換えます：

変更が自動的に適用されるかどうかは、以下のコマンドで確認できます：

変更が自動的に適用されない場合は、corosyncサービスを再起動する必要があります：

エラーについては、以下のトラブルシューティングのセクションを確認してください。

移行タイプは、移行データを暗号化された(安全な) チャネルで送信するか、暗号化されていない(安全でない) チャネルで送信するかを定義します。 移行タイプを安全でないに設定すると、仮想ゲストの RAM コンテンツも暗号化されずに転送されることになり、ゲスト内部の重要なデータ (パスワードや暗号化キーなど) の情報漏えいにつながる可能性があります。

従って、ネットワークを完全に制御できず、誰にも盗聴されていないことを保証できない場合は、安全なチャネルを使用することを強くお勧めします。

暗号化には多くの計算能力が必要なため、この設定はより良いパフォーマンスを得るために、しばしば安全でない設定に変更されます。最近のシステムはハードウェアでAES暗号化を実装しているため、その影響は小さくなっています。パフォーマンスへの影響は、10Gbps以上の転送が可能な高速ネットワークで特に顕著です。

デフォルトでは、Proxmox VEはクラスタ通信が行われるネットワークを使用して移行トラフィックを送信します。これは、機密性の高いクラスタトラフィックが中断される可能性があることと、このネットワークがノードで利用可能な最良の帯域幅を持たない可能性があるため、いずれも最適ではありません。

移行ネットワークパラメータを設定すると、すべての移行トラフィックに専用ネットワークを使用できます。メモリに加えて、これはオフライン移行のストレージトラフィックにも影響します。

移行ネットワークはCIDR表記を使用したネットワークとして設定されます。これには、各ノードに個別のIPアドレスを設定する必要がないという利点があります。Proxmox VEは、CIDR形式で指定されたネットワークから移行先ノードの実アドレスを判断できます。これを有効にするには、各ノードがそれぞれのネットワークで正確に1つのIPを持つようにネットワークを指定する必要があります。