Proxmox VEのクラスタ構成と手動マイグレーション

# 概要
2台のProxmox VEを利用して、クラスタを構成してみます。
さらに、手動でマイグレーション（ストレージvMotion）をしてみます。

## 構成
1台目: Proxmox VE on 物理サーバ
ホスト名: pve
IPアドレス: 192.168.11.45/24, 192.168.11.57/24

2台目: Proxmox VE on Hyper-V
ホスト名: pve2
IPアドレス: 192.168.12.45/24, 192.168.12.57/24

# クラスタ作成
1台目の管理画面から、クラスタを作成します。
折角ですので、2本のNICをともに利用します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3789581/61dbaa1b-b317-ae08-4daa-3b90ba13e4cb.png)

コマンドの実行結果を見ると、クラスタはcorosyncを利用しているようです。
```
Corosync Cluster Engine Authentication key generator.
Gathering 2048 bits for key from /dev/urandom.
Writing corosync key to /etc/corosync/authkey.
Writing corosync config to /etc/pve/corosync.conf
Restart corosync and cluster filesystem
TASK OK
```

クラスタが出来ました。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3789581/933c9c38-01d0-8191-9301-ad7819acc01a.png)

Join情報をクリックすると、クラスタに参加するためのJoin情報が得られます。

# クラスタに参加
2台目の管理画面からクラスタに参加します。

クラスタに参加をクリックし、Join情報を貼り付けます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3789581/82496c11-f9da-8822-50ef-9dc24f46825b.png)

正しいJoin情報を入力すると、Peerのパスワード及びネットワーク情報を選択可能となりますので、入力してクラスタに参加します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3789581/578c6ef8-0ac9-3e46-c02a-0b8c39ffe1a1.png)

クラスタ参加結果が表示されます。
```
Establishing API connection with host '192.168.11.45'
Login succeeded.
check cluster join API version
Request addition of this node
```

接続エラーと表示されましたが、再度管理画面にログインするとクラスタに参加できていました。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3789581/150ee89a-3475-085c-3fd5-fe733ebe9d0c.png)

# 注意点
クラスタに参加すると、2台目のデータストアとしてマウントしていたCIFS領域が見えなくなり、1台目でマウントしているZFS Poolが見えるようになりました。どうやら、クラスタは同じストレージ構成となってしまうようです。

# 参考
1台目にログインしてcorosync.confを見てみました。

```
root@pve:~# cat /etc/corosync/corosync.conf
logging {
  debug: off
  to_syslog: yes
}

nodelist {
  node {
    name: pve
    nodeid: 1
    quorum_votes: 1
    ring0_addr: 192.168.11.45
    ring1_addr: 192.168.12.45
  }
  node {
    name: pve2
    nodeid: 2
    quorum_votes: 1
    ring0_addr: 192.168.11.57
    ring1_addr: 192.168.12.57
  }
}

quorum {
  provider: corosync_votequorum
}

totem {
  cluster_name: pvecluster
  config_version: 2
  interface {
    linknumber: 0
  }
  interface {
    linknumber: 1
  }
  ip_version: ipv4-6
  link_mode: passive
  secauth: on
  version: 2
}
```

Pacemakerやheartbeatは動いていないようですので、ChatGPTに仕組みを質問したところ、以下の回答が得られました。

Proxmox VE (PVE) クラスタでは、クラスタ内のリソース管理にPacemakerは使用されていません。Proxmox VEは以下の技術を利用してリソース管理を行います：

1. **Corosync**: クラスタノード間の通信と投票（quorum）の管理を担当します。
2. **Proxmox Cluster File System (pmxcfs)**: ファイルベースの分散クラスタファイルシステムで、クラスタの設定情報を各ノードに同期させます。これはCorosyncをバックエンドとして使用しています。
3. **QEMU/KVMとLXC**: 仮想マシンとコンテナの管理を行います。ProxmoxのGUIやCLIを通じて管理します。

Proxmox VEは、Pacemakerのような高可用性（HA）リソースマネージャを使用せず、独自のHAスタックを持っています。このHAスタックは、クラスタ内の仮想マシンとコンテナの自動再配置を行い、ノードの障害時にリソースが他のノードに自動的に移動するように設計されています。

ProxmoxのHA機能は、次のコンポーネントで構成されています：

- **pve-ha-manager**: ProxmoxのHA管理デーモンで、リソースの監視とフェイルオーバーを制御します。
- **pve-ha-crm**: クラスタリソースマネージャで、クラスタ全体の状態を監視し、リソースの配置と再配置を決定します。
- **pve-ha-lrm**: ローカルリソースマネージャで、個々のノード上のリソースを管理します。

これにより、Proxmox VEクラスタは、高可用性とリソース管理の両方を一元的に管理することができます。

# マイグレーション（ストレージvMotion）
手動でマイグレーションしてみました。
16GBのローカルストレージを持つ仮想マシンを移動したところ、3分程度で移動できました。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3789581/54b3ba60-0c01-2026-775d-ee4035373ccf.png)