Proxmox VE 5.4 to 6.2 ライブアップグレード話 後半戦 - Ceph Luminous(12.x) to Nautilus(14.x)
Posted on 2020/08/13(Thu) 19:05 in technical
前書き
Proxmox VE 5.4 to 6.2 ライブアップグレード話 前半戦 でProxmox VEをアップグレードできました。
Proxmox VE 5.xではCeph Luminous(12.x)が使用されていたため、別途Nautilus(14.x)へのマイグレーションを行う必要があります。
そこで、今回はCephクラスタをLuminous(12.x)からNautilus(14.x)にアップグレードしていきます。
なお、現時点でCephクラスタはOSDの1台が壊れており、復旧から始まるものとします。
構成
- Proxmox VE 6.2 - 3 nodes cluster
- Ceph luminous cluster - 3 nodes cluster
- 2 OSD up
- 1 OSD down
- Hardware: TX1320 M2
- /dev/sda: system - 32GB SSD
- /dev/sdb: ceph data (bluestore) - 1000GB SSD
- /dev/sda と /dev/sdb は逆になっている場合もあります
- eno1: bond0 - 1GbE
- eno2: bond0 - 1GbE
- bond0
- Untagged: Admin and VM network
- VLAN 200: WAN network (for BBR)
- VMは大体15台くらい
実施手順
公式手順 https://pve.proxmox.com/wiki/Ceph_Luminous_to_Nautilus に沿って作業します。
The cluster must be healthy and working.
と書かれているのが不穏なので、アップグレードの前にLuminousパッケージが残っているうちに故障復旧から始めます。
故障OSDの交換
- Ceph Luminous to Nautilusのアップグレード前にCephクラスタを回復します
- ただし、PVE 6にアップグレードが終わっているので
pvecephコマンドは使えないものとします
お得な掲示板
- Cephクラスタが縮退した状態でPVEのアップグレードを始めない方がいい
- アップグレード中に不幸にもOSDが壊れてしまったと思って読もう
動作中のOSDの情報収集
当初クラスタ構成時（おそらくPVE 5.1）、どんなコマンドでOSDが作られたのか定かではないので、まずは現行マシンのOSD情報を拾います。（2号機の情報を取得）
BlueStoreで動作していてLVMが使われていない構成なので、今後のceph-volumeの標準的な構成とは違いそうです...が、強行します。
root@pve02:~# parted -s /dev/sda print
Model: ATA Crucial_CT1050MX (scsi)
Disk /dev/sda: 1050GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:
Number Start End Size File system Name Flags
1 1049kB 106MB 105MB xfs ceph data
2 106MB 1050GB 1050GB ceph block
root@pve02:~# ceph-volume simple scan
root@pve02:~# cat /etc/ceph/osd/1-0a5369a9-cff6-4781-8977-86791416a84c.json
{
"active": "ok",
"block": {
"path": "/dev/disk/by-partuuid/1d7a1aa2-4fd5-45fd-9ea9-0ae60cefed07",
"uuid": "1d7a1aa2-4fd5-45fd-9ea9-0ae60cefed07"
},
"block_uuid": "1d7a1aa2-4fd5-45fd-9ea9-0ae60cefed07",
"bluefs": 1,
"ceph_fsid": "379c9ad8-dd15-4bf1-b9fc-f5206a75fe3f",
"cluster_name": "ceph",
"data": {
"path": "/dev/sda1",
"uuid": "0a5369a9-cff6-4781-8977-86791416a84c"
},
"fsid": "0a5369a9-cff6-4781-8977-86791416a84c",
"keyring": "AQBENBhamM2oGhAAh7gwTk4IBvYyxSqtgZPlYw==",
"kv_backend": "rocksdb",
"magic": "ceph osd volume v026",
"mkfs_done": "yes",
"ready": "ready",
"require_osd_release": "",
"systemd": "",
"type": "bluestore",
"whoami": 1
}
root@pve02:~# ceph-bluestore-tool show-label --path /var/lib/ceph/osd/ceph-1/
infering bluefs devices from bluestore path
{
"/var/lib/ceph/osd/ceph-1//block": {
"osd_uuid": "0a5369a9-cff6-4781-8977-86791416a84c",
"size": 1050108661760,
"btime": "2017-11-25 00:01:24.771404",
"description": "main",
"require_osd_release": "\u000c"
}
}
OSDが壊れているDiskの交換
今回は削除して新しく作り直します。これはPVE 5.4のデフォルトのOSD構成とは異なるけど仕方ないのです。
なお、削除は早まってPVE 6.2のCeph管理画面から以下の手順で実施してしまっています。
- pve01: osd.0 Out
- pve01: osd.0 Stop
- pve01: osd.0 Destroy
- [ ] Cleanup disks （チェックを外す）
root@pve01:~# ceph-volume lvm batch --bluestore /dev/sdb
Total OSDs: 1
Type Path LV Size % of device
----------------------------------------------------------------------------------------------------
[data] /dev/sdb 931.51 GB 100%
--> The above OSDs would be created if the operation continues
--> do you want to proceed? (yes/no) Running command: vgcreate --force --yes ceph-a9030cf6-d213-46cd-8092-9d2eb8da2d93 /dev/sdb
stdout: Physical volume "/dev/sdb" successfully created.
stdout: Volume group "ceph-a9030cf6-d213-46cd-8092-9d2eb8da2d93" successfully created
Running command: lvcreate --yes -l 238467 -n osd-data-fef94980-4baf-4484-8213-d0e434263540 ceph-a9030cf6-d213-46cd-8092-9d2eb8da2d93
stdout: Logical volume "osd-data-fef94980-4baf-4484-8213-d0e434263540" created.
Running command: /usr/bin/ceph-authtool --gen-print-key
Running command: /usr/bin/ceph --cluster ceph --name client.bootstrap-osd --keyring /var/lib/ceph/bootstrap-osd/ceph.keyring -i - osd new 736c0073-a059-4f78-a067-aee96ca9627b
Running command: /usr/bin/ceph-authtool --gen-print-key
Running command: mount -t tmpfs tmpfs /var/lib/ceph/osd/ceph-0
--> Absolute path not found for executable: restorecon
--> Ensure $PATH environment variable contains common executable locations
Running command: chown -h ceph:ceph /dev/ceph-a9030cf6-d213-46cd-8092-9d2eb8da2d93/osd-data-fef94980-4baf-4484-8213-d0e434263540
Running command: chown -R ceph:ceph /dev/dm-12
Running command: ln -s /dev/ceph-a9030cf6-d213-46cd-8092-9d2eb8da2d93/osd-data-fef94980-4baf-4484-8213-d0e434263540 /var/lib/ceph/osd/ceph-0/block
Running command: ceph --cluster ceph --name client.bootstrap-osd --keyring /var/lib/ceph/bootstrap-osd/ceph.keyring mon getmap -o /var/lib/ceph/osd/ceph-0/activate.monmap
stderr: got monmap epoch 5
Running command: ceph-authtool /var/lib/ceph/osd/ceph-0/keyring --create-keyring --name osd.0 --add-key AQDIXzJfYZVLHhAAVb0SdEJM0bTesV67QXPYjA==
stdout: creating /var/lib/ceph/osd/ceph-0/keyring
added entity osd.0 auth auth(auid = 18446744073709551615 key=AQDIXzJfYZVLHhAAVb0SdEJM0bTesV67QXPYjA== with 0 caps)
Running command: chown -R ceph:ceph /var/lib/ceph/osd/ceph-0/keyring
Running command: chown -R ceph:ceph /var/lib/ceph/osd/ceph-0/
Running command: /usr/bin/ceph-osd --cluster ceph --osd-objectstore bluestore --mkfs -i 0 --monmap /var/lib/ceph/osd/ceph-0/activate.monmap --keyfile - --osd-data /var/lib/ceph/osd/ceph-0/ --osd-uuid 736c0073-a059-4f78-a067-aee96ca9627b --setuser ceph --setgroup ceph
--> ceph-volume lvm prepare successful for: ceph-a9030cf6-d213-46cd-8092-9d2eb8da2d93/osd-data-fef94980-4baf-4484-8213-d0e434263540
Running command: chown -R ceph:ceph /var/lib/ceph/osd/ceph-0
Running command: ceph-bluestore-tool --cluster=ceph prime-osd-dir --dev /dev/ceph-a9030cf6-d213-46cd-8092-9d2eb8da2d93/osd-data-fef94980-4baf-4484-8213-d0e434263540 --path /var/lib/ceph/osd/ceph-0
Running command: ln -snf /dev/ceph-a9030cf6-d213-46cd-8092-9d2eb8da2d93/osd-data-fef94980-4baf-4484-8213-d0e434263540 /var/lib/ceph/osd/ceph-0/block
Running command: chown -h ceph:ceph /var/lib/ceph/osd/ceph-0/block
Running command: chown -R ceph:ceph /dev/dm-12
Running command: chown -R ceph:ceph /var/lib/ceph/osd/ceph-0
Running command: systemctl enable ceph-volume@lvm-0-736c0073-a059-4f78-a067-aee96ca9627b
stderr: Created symlink /etc/systemd/system/multi-user.target.wants/ceph-volume@lvm-0-736c0073-a059-4f78-a067-aee96ca9627b.service → /lib/systemd/system/ceph-volume@.service.
Running command: systemctl enable --runtime ceph-osd@0
Running command: systemctl start ceph-osd@0
--> ceph-volume lvm activate successful for osd ID: 0
--> ceph-volume lvm create successful for: ceph-a9030cf6-d213-46cd-8092-9d2eb8da2d93/osd-data-fef94980-4baf-4484-8213-d0e434263540
root@pve01:~# ceph-bluestore-tool show-label --path /var/lib/ceph/osd/ceph-0/
infering bluefs devices from bluestore path
{
"/var/lib/ceph/osd/ceph-0//block": {
"osd_uuid": "736c0073-a059-4f78-a067-aee96ca9627b",
"size": 1000203091968,
"btime": "2020-08-11 18:07:22.002301",
"description": "main",
"bluefs": "1",
"ceph_fsid": "379c9ad8-dd15-4bf1-b9fc-f5206a75fe3f",
"kv_backend": "rocksdb",
"magic": "ceph osd volume v026",
"mkfs_done": "yes",
"osd_key": "AQDIXzJfYZVLHhAAVb0SdEJM0bTesV67QXPYjA==",
"ready": "ready",
"require_osd_release": "\u000c",
"whoami": "0"
}
}
この後 ceph health コマンドの結果が HEALTH_OK になるまで待ってから次の手順へ移ります。
Ceph upgrade Luminous to Nautilus
事前確認
全ノードで以下の2つのフラグがあることを確認します。
- recovery_deletes flag
- purged_snapdirs flag
# ceph osd dump | grep ^flags
flags noout,sortbitwise,recovery_deletes,purged_snapdirs
無い場合はスクラブをかけるようですが、私の環境では省略しました。
Cephコンフィグのkeyring修正
/etc/pve はPVEクラスタ環境では同期されているので1台だけで編集します。
# diff -u ceph.conf.bak /etc/pve/ceph.conf
--- ceph.conf.bak 2020-08-11 23:49:51.172051728 +0900
+++ /etc/pve/ceph.conf 2020-08-11 23:51:24.000000000 +0900
@@ -4,15 +4,14 @@
auth service required = cephx
cluster network = 192.168.122.0/24
fsid = 379c9ad8-dd15-4bf1-b9fc-f5206a75fe3f
- keyring = /etc/pve/priv/$cluster.$name.keyring
mon allow pool delete = true
osd journal size = 5120
osd pool default min size = 2
osd pool default size = 3
public network = 192.168.122.0/24
-[osd]
- keyring = /var/lib/ceph/osd/ceph-$id/keyring
+[client]
+ keyring = /etc/pve/priv/$cluster.$name.keyring
[mon.pve03]
host = pve03
Cephパッケージのアップデート
1台目のノードでリバランシングを無効にします。万が一忘れてもちょっと余分に読み書きが起きるだけで進行は可能と思われますが、念のため。
# ceph osd set noout
全ノードで実行します。
# echo "deb http://download.proxmox.com/debian/ceph-nautilus buster main" > /etc/apt/sources.list.d/ceph.list
# apt update
# apt dist-upgrade -y
ceph-monの再起動
全ノードのパッケージアップデートが完了したらモニタを再起動します。
# systemctl restart ceph-mon.target
その後、全ノードで nautilus が実行されていることを確認します。
# ceph mon dump | grep min_mon_release
dumped monmap epoch 6
min_mon_release 14 (nautilus)
ceph-mgrの再起動
全ノードのceph-monがNautilusで動作していることを確認したら、全ノードのceph-mgrを再起動します。
# systemctl restart ceph-mgr.target
# ceph -s
cluster:
id: 379c9ad8-dd15-4bf1-b9fc-f5206a75fe3f
health: HEALTH_WARN
noout flag(s) set
3 monitors have not enabled msgr2
services:
mon: 3 daemons, quorum pve01,pve02,pve03 (age 87s)
mgr: pve02(active, since 3s), standbys: pve03, pve01
osd: 3 osds: 3 up, 3 in
flags noout
data:
pools: 1 pools, 64 pgs
objects: 127.89k objects, 492 GiB
usage: 1.4 TiB used, 1.4 TiB / 2.8 TiB avail
pgs: 64 active+clean
ceph-osdの再起動
クラスタネットワークがIPv6 only networkの場合は追加手順があるようですが、今回はIPv4環境なので省略します。
一度にやると以下のように一時的にOSDが軒並みダウンします。実際は1台ずつupするまで待って作業した方が心理的には良いと思います。
（ceph -s は適当な間隔で叩いています）
# systemctl restart ceph-osd.target
# ceph -s
cluster:
id: 379c9ad8-dd15-4bf1-b9fc-f5206a75fe3f
health: HEALTH_WARN
noout flag(s) set
3 osds down
3 hosts (3 osds) down
1 root (3 osds) down
3 monitors have not enabled msgr2
services:
mon: 3 daemons, quorum pve01,pve02,pve03 (age 4m)
mgr: pve02(active, since 2m), standbys: pve03, pve01
osd: 3 osds: 0 up, 3 in
flags noout
data:
pools: 1 pools, 64 pgs
objects: 127.89k objects, 492 GiB
usage: 1.4 TiB used, 1.4 TiB / 2.8 TiB avail
pgs: 64 stale+active+clean
io:
client: 4.4 MiB/s rd, 891 KiB/s wr, 36 op/s rd, 29 op/s wr
# ceph -s
cluster:
id: 379c9ad8-dd15-4bf1-b9fc-f5206a75fe3f
health: HEALTH_WARN
noout flag(s) set
Degraded data redundancy: 172/383661 objects degraded (0.045%), 49 pgs degraded
3 monitors have not enabled msgr2
services:
mon: 3 daemons, quorum pve01,pve02,pve03 (age 5m)
mgr: pve02(active, since 3m), standbys: pve03, pve01
osd: 3 osds: 3 up, 3 in
flags noout
data:
pools: 1 pools, 64 pgs
objects: 127.89k objects, 492 GiB
usage: 1.4 TiB used, 1.4 TiB / 2.8 TiB avail
pgs: 172/383661 objects degraded (0.045%)
49 active+recovery_wait+degraded
15 active+clean
io:
client: 169 KiB/s rd, 1.6 MiB/s wr, 2 op/s rd, 41 op/s wr
recovery: 43 MiB/s, 10 objects/s
# ceph -s
cluster:
id: 379c9ad8-dd15-4bf1-b9fc-f5206a75fe3f
health: HEALTH_WARN
noout flag(s) set
3 monitors have not enabled msgr2
services:
mon: 3 daemons, quorum pve01,pve02,pve03 (age 5m)
mgr: pve02(active, since 3m), standbys: pve03, pve01
osd: 3 osds: 3 up, 3 in
flags noout
data:
pools: 1 pools, 64 pgs
objects: 127.89k objects, 492 GiB
usage: 1.4 TiB used, 1.4 TiB / 2.8 TiB avail
pgs: 64 active+clean
io:
client: 223 KiB/s rd, 649 KiB/s wr, 3 op/s rd, 14 op/s wr
recovery: 35 MiB/s, 8 objects/s
また、PVE 5.xの際に作成されたOSDは（おそらく）simpleモードで作られているので、次回起動時にOSDを自動的に認識させるためには以下のコマンド実行が必要です。
# ceph-volume simple scan
stderr: lsblk: /var/lib/ceph/osd/ceph-2: not a block device
stderr: Bad argument "/var/lib/ceph/osd/ceph-2", expected an absolute path in /dev/ or /sys or a unit name: Invalid argument
Running command: /sbin/cryptsetup status /dev/sda1
--> OSD 2 got scanned and metadata persisted to file: /etc/ceph/osd/2-4e3b5b29-5602-4f14-b06b-afba9b5277f0.json
--> To take over management of this scanned OSD, and disable ceph-disk and udev, run:
--> ceph-volume simple activate 2 4e3b5b29-5602-4f14-b06b-afba9b5277f0
# ceph-volume simple activate --all
--> activating OSD specified in /etc/ceph/osd/2-4e3b5b29-5602-4f14-b06b-afba9b5277f0.json
Running command: /bin/ln -snf /dev/sda2 /var/lib/ceph/osd/ceph-2/block
Running command: /bin/chown -R ceph:ceph /dev/sda2
Running command: /bin/systemctl enable ceph-volume@simple-2-4e3b5b29-5602-4f14-b06b-afba9b5277f0
stderr: Created symlink /etc/systemd/system/multi-user.target.wants/ceph-volume@simple-2-4e3b5b29-5602-4f14-b06b-afba9b5277f0.service → /lib/systemd/system/ceph-volume@.service.
Running command: /bin/ln -sf /dev/null /etc/systemd/system/ceph-disk@.service
--> All ceph-disk systemd units have been disabled to prevent OSDs getting triggered by UDEV events
Running command: /bin/systemctl enable --runtime ceph-osd@2
Running command: /bin/systemctl start ceph-osd@2
--> Successfully activated OSD 2 with FSID 4e3b5b29-5602-4f14-b06b-afba9b5277f0
調査用に以前叩いた事がある場合は、以下のように OSD metadata file exists なエラーが出ますが、内容に変更がなければそのままactivate可能です。
今回は、故障復旧前にOSDの設定を調査したりしたので、2台目では以下のようになりました。
# ceph-volume simple scan
stderr: lsblk: /var/lib/ceph/osd/ceph-1: not a block device
stderr: Bad argument "/var/lib/ceph/osd/ceph-1", expected an absolute path in /dev/ or /sys or a unit name: Invalid argument
Running command: /sbin/cryptsetup status /dev/sda1
--> RuntimeError: --force was not used and OSD metadata file exists: /etc/ceph/osd/1-0a5369a9-cff6-4781-8977-86791416a84c.json
# ceph-volume simple activate --all
--> activating OSD specified in /etc/ceph/osd/1-0a5369a9-cff6-4781-8977-86791416a84c.json
Running command: /bin/ln -snf /dev/sda2 /var/lib/ceph/osd/ceph-1/block
Running command: /bin/chown -R ceph:ceph /dev/sda2
Running command: /bin/systemctl enable ceph-volume@simple-1-0a5369a9-cff6-4781-8977-86791416a84c
stderr: Created symlink /etc/systemd/system/multi-user.target.wants/ceph-volume@simple-1-0a5369a9-cff6-4781-8977-86791416a84c.service → /lib/systemd/system/ceph-volume@.service.
Running command: /bin/ln -sf /dev/null /etc/systemd/system/ceph-disk@.service
--> All ceph-disk systemd units have been disabled to prevent OSDs getting triggered by UDEV events
Running command: /bin/systemctl enable --runtime ceph-osd@1
Running command: /bin/systemctl start ceph-osd@1
--> Successfully activated OSD 1 with FSID 0a5369a9-cff6-4781-8977-86791416a84c
また、今回1台目のノードではPVE 5.4から6.2にアップグレードした後にDisk交換を行っており、その際lvmモードでOSDを作っています。
その場合は上記手順は不要ですので ceph-volume simple scan を実行しても処理対象は見つかりません。
# ceph-volume simple scan
stderr: lsblk: /var/lib/ceph/osd/ceph-0: not a block device
stderr: Bad argument "/var/lib/ceph/osd/ceph-0", expected an absolute path in /dev/ or /sys or a unit name: Invalid argument
Running command: /sbin/cryptsetup status tmpfs
stderr: blkid: error: tmpfs: No such file or directory
stderr: lsblk: tmpfs: not a block device
stderr: lsblk: tmpfs: not a block device
stderr: blkid: error: tmpfs: No such file or directory
stderr: Bad argument "tmpfs", expected an absolute path in /dev/ or /sys or a unit name: Invalid argument
--> Ignoring /var/lib/ceph/osd/ceph-0 because it's not a ceph-disk created osd.
ceph-mdsの再起動（CephFS MDSのインストールで代用）
今回の環境ではCephFSは使われていません。また、インストール当時の環境のせいなのか ceph-mds 自体が入っていませんでした。
# ceph df
RAW STORAGE:
CLASS SIZE AVAIL USED RAW USED %RAW USED
ssd 2.8 TiB 1.4 TiB 1.4 TiB 1.4 TiB 50.46
TOTAL 2.8 TiB 1.4 TiB 1.4 TiB 1.4 TiB 50.46
POOLS:
POOL ID STORED OBJECTS USED %USED MAX AVAIL
rdb 1 484 GiB 127.89k 1.4 TiB 54.01 412 GiB
# ceph fs ls
No filesystems enabled
# systemctl status ceph-mds.target
Unit ceph-mds.target could not be found.
そこで、今回は全ノードでceph-mdsのインストールとサービスの起動だけを実施しました。
# apt install ceph-mds
# systemctl start ceph-mds.target
# systemctl status ceph-mds.target
● ceph-mds.target - ceph target allowing to start/stop all ceph-mds@.service instances at once
Loaded: loaded (/lib/systemd/system/ceph-mds.target; enabled; vendor preset: enabled)
Active: active since Wed 2020-08-12 00:28:33 JST; 56s ago
Aug 12 00:28:33 pve01 systemd[1]: Reached target ceph target allowing to start/stop all ceph-mds@.service instances at once.
Nautilusの新しい機能を全て有効化
作業は1台だけでOKです。
# ceph osd require-osd-release nautilus
nooutオプションの解除
作業は1台だけでOKです。
# ceph osd unset noout
# ceph -s
cluster:
id: 379c9ad8-dd15-4bf1-b9fc-f5206a75fe3f
health: HEALTH_WARN
3 monitors have not enabled msgr2
services:
mon: 3 daemons, quorum pve01,pve02,pve03 (age 35m)
mgr: pve02(active, since 34m), standbys: pve03, pve01
osd: 3 osds: 3 up, 3 in
data:
pools: 1 pools, 64 pgs
objects: 127.89k objects, 492 GiB
usage: 1.4 TiB used, 1.4 TiB / 2.8 TiB avail
pgs: 64 active+clean
io:
client: 5.6 KiB/s rd, 754 KiB/s wr, 0 op/s rd, 21 op/s wr
Upgrade Tunables
Tunablesに関するWARNINGは出ていないので、この手順は省略します。
msgrv2プロトコルの有効化
作業は1台だけでOKです。この時、連続してコマンドを打ちましたが ceph -s が成功するまで5秒くらいかかりました。
# ceph mon enable-msgr2
# ceph -s
cluster:
id: 379c9ad8-dd15-4bf1-b9fc-f5206a75fe3f
health: HEALTH_OK
services:
mon: 3 daemons, quorum pve01,pve02,pve03 (age 1.96961s)
mgr: pve02(active, since 36m), standbys: pve03, pve01
osd: 3 osds: 3 up, 3 in
data:
pools: 1 pools, 64 pgs
objects: 127.89k objects, 492 GiB
usage: 1.4 TiB used, 1.4 TiB / 2.8 TiB avail
pgs: 64 active+clean
io:
client: 1.0 MiB/s wr, 0 op/s rd, 25 op/s wr
msgrv2プロトコルが有効になったかどうかは、以下のコマンドで各モニターリストがv1とv2のアドレスを持っていることから確認できます。
# ceph mon dump
dumped monmap epoch 7
epoch 7
fsid 379c9ad8-dd15-4bf1-b9fc-f5206a75fe3f
last_changed 2020-08-12 00:34:49.488527
created 2017-11-24 23:57:30.396282
min_mon_release 14 (nautilus)
0: [v2:192.168.122.26:3300/0,v1:192.168.122.26:6789/0] mon.pve01
1: [v2:192.168.122.27:3300/0,v1:192.168.122.27:6789/0] mon.pve02
2: [v2:192.168.122.28:3300/0,v1:192.168.122.28:6789/0] mon.pve03
msgrv2プロトコルが有効になった後は /etc/pve/ceph.conf にモニターホストを追加しておくことが推奨されているので追加します。
# diff -u ceph.conf.bak2 /etc/pve/ceph.conf
--- ceph.conf.bak2 2020-08-12 00:41:53.273018283 +0900
+++ /etc/pve/ceph.conf 2020-08-12 00:47:16.000000000 +0900
@@ -5,6 +5,7 @@
cluster network = 192.168.122.0/24
fsid = 379c9ad8-dd15-4bf1-b9fc-f5206a75fe3f
mon allow pool delete = true
+ mon_host = 192.168.122.26 192.168.122.27 192.168.122.28
osd journal size = 5120
osd pool default min size = 2
osd pool default size = 3
PVE 5.xで生成されたコンフィグだと、元々以下のようにv1向けのアドレスとポートがセットで書かれていました。
上記で mon_host を追加しないとv1で接続した後、v2に再接続したりすると思われます。
mon addr 部分は消しても良さそうですが、今後PVEシステムがどう処理するか分からないので、一旦そのままにしています。
[mon.pve01]
host = pve01
mon addr = 192.168.122.26:6789
ceph config assimilate-conf と ceph config generate-minimal-config を使った方法がCephの公式ドキュメント側に書かれていました。
ただ、今後PVE側でケアされる可能性もあるので一旦使わないでスルーします。
https://docs.ceph.com/docs/nautilus/rados/configuration/msgr2/#updating-ceph-conf-and-mon-host
Legacy BlueStore stats reporting
特に出ていないので省略しました。
終わり
ほとんどPVEの公式ドキュメント通りでした。本当にお疲れ様でした。
期せずしてCephの公式ドキュメントも少し読むことが出来たので丁度よかったです。
既存のCeph OSDがLVMじゃないのはいずれ直そうかな？
それでは。