【PVE】Proxmox VE【KVM, LXC】NODE-2

**login:Penguin** · 2024/04/16(火) 12:23:19.23

>>9
Ceph組んだことないんだけど、Proxmox3台で、HAとCephを一緒に組めるものなのじゃないのか？

**login:Penguin** · 2024/04/16(火) 12:23:31.09

>>9
Ceph組んだことないんだけど、Proxmox3台で、HAとCephを一緒に組めるものなのじゃないのか？

**login:Penguin** · 2024/04/16(火) 12:24:10.57

ごめん、２どかいてしまった。

**login:Penguin** · 2024/04/16(火) 19:06:59.62

Cephに渡すドライブって /dev/sdb とかの丸ごとじゃないとダメなの？

N100の安miniPCで追加ドライブ用意するのが面倒
（Proxmox自体をUSBメモリにインストールすればいいのだけど、挿ってるのがちょっと気に入らないｗ）

**login:Penguin** · 2024/04/16(火) 20:46:42.01

raidzで組みたいんだが後からSSD増設できない仕様なのにSSD値上がりしまくってるせいで痛い
何かいい案ないものか

**login:Penguin** · 2024/04/16(火) 22:28:39.62

>10,11
参考になります
自分の環境だと3台( NIC 1Gbps )で Write 42MB/s 位でした（想定の範囲）
（一応 public と cluster のネットワークを分けてみたけど、内部の vm からだとあまり変わらず）
複数のノードから同時に書き込みして、その合計を書き込み速度って考えならもっと増えるかな（今度試してみよう・・・）

**login:Penguin** · 2024/04/16(火) 22:34:01.06

>>12
3台でCeph,HA,VMが共存できます

ただ、手元にPRIMERGY10台（使用中４台）あるから・・・

**login:Penguin** · 2024/04/16(火) 22:46:23.70

>>15
試したことが無いから憶測だけど
ある程度Linuxの知識あって、Cephのドキュメント読みながらOSD構築できるなら
LV(LVM)でも任意のパーテーションでもOSD用に割り当てできるはず

いま調べてる途中なんだけど、Cephのモニターかマネージャーノード（両方？）が
OSDじゃなくLinuxのインストール側のディスクに常に0.5MBye/sec位謎の書き込みしてる
（内容(原因)追ってるんだけど、inotifywaitでは？特定できてない）

それで、高耐久ではない一般的なUSBメモリだと直ぐに死ぬ！

**login:Penguin** · 2024/04/17(水) 02:43:13.08

Cephの謎の連続書き込みこれっぽい
/var/lib/ceph/mon/ceph-{host-name}/store.db
（ find / -mmin -1 の結果から、それっぽいの見つけた）
123456.log , 123456.sst（6桁？の数値.logと.sst）が原因っぽい
0.5MBye/sec≒15TByte/yearはちょっと多い・・・
Proxmoxの起動用に容量少ないSSD使ってるから不安しかない・・・

**login:Penguin** · 2024/04/17(水) 18:41:45.47

UNIXの頃から、安全を見てrootの予定空き容量は50%以上を確保しておけと。
（たいした容量は必要ない）

**login:Penguin** · 2024/04/18(木) 02:02:02.25

今日の悲しい報告

fstrimコマンドを100回は打った
Lvm(thin)もZFSもCephもThin Provisioningなのに、なぜ確保した範囲が解放されないって悩み過ぎた

Discardを有効にするために/etc/pve/qemu-server/<vmid>.conf 弄ったり
/etc/lvm/lvm.conf 弄ったり
zpool set autotrim=on pool 打ったり・・・

Vmで使う仮想DiskのDiscradのオプションに気づかずに・・・

**login:Penguin** · 2024/04/18(木) 07:02:23.16

>>20

OSDじゃなくLinuxのインストール側のディスクはHDDにしたほうが安全だね。。

**login:Penguin** · 2024/04/18(木) 16:35:24.54

PVEでのcephの運用勉強してたら
前提条件が変わってきて用意したパーツが無駄に(笑)

データ用SSD180GB(MLC)ｘ14個
起動用SSD32GB(SLC)ｘ14個　← これ、窓から投げ捨てて

起動用に100GB+α以上で高耐久のSSD調達しないと(涙)

**login:Penguin** · 2024/04/18(木) 21:42:57.67

>>24
どんな構成なのか気になる・・・

**login:Penguin** · 2024/04/19(金) 12:23:07.99

>>24
起動用はもう、HDDでいんじゃね？（笑

実際のところ、Proxmox起動用と、iso保存用は、HDDを使うのとSSD使うのどっちがいいんだろうね。

**login:Penguin** · 2024/04/19(金) 12:24:14.61

ISO置き場は読み込み速度がほしいのでSSDにしてるな

**login:Penguin** · 2024/04/19(金) 13:33:58.38

Optaneでいいよもう

**login:Penguin** · 2024/04/19(金) 17:35:56.25

/var/lib/ceph/mon 以下をtmpfsにしちゃうとか

**login:Penguin** · 2024/04/19(金) 18:14:15.03

逆にProxmoxサーバーのシステムディスクがHDDの場合、cephのパフォーマンスにどのぐらい影響するか知りたい。

**login:Penguin** · 2024/04/19(金) 23:40:58.82

>>25
[最初の計画]
32GB(SLC)をZFS・ミラーで冗長化して起動用(6台分)2個は予備
180GBｘ3をZFS・RAIDZで冗長化（4台分）
Proxmox ｘ3＋予備マシンｘ1、NASｘ1、実験用ｘ1

[途中の計画]
32GB(SLC)をZFS・ミラーで冗長化して起動用(6台分)2個は予備
180ｘ3をCephに使う(マシン3台＋1台）2個は予備
Proxmox ｘ3＋予備マシン＊1、NASｘ1、実験用ｘ1

[現在(中断する計画)]
32GB(SLC)をZFS・ミラーで冗長化して起動用(6台分)2個は予備（Cpehの書き込み量に対して不安）
NASに使ってるSSDとかHDDをCephに集結して、Proxmox ｘ５＋１(予備)でCephを構築してNASも兼ねる

**login:Penguin** · 2024/04/19(金) 23:55:22.06

>>26
HDD、1万回転のSASのなら使ってないのが・・・

＞Proxmox起動用
Ceph無し、容量それほど必要じゃないならSSD（ただし、信頼性の高いメーカー・モデルが良い）
HDDは電源切断直後に衝撃を与えると簡単に壊た

>>28
Optaneは昔数点確保してたけど、入手性が悪くて必要量確保するのが・・・

>>29
Cephの公式ドキュメントだとモニターノード用に100GB確保する事が推奨されてた
OSD少な目でも数十GBの容量は確保する必要が有りそうなので、tmpfsでの運用は難しいと思う
tmpfsを定期的に保存してたとして、障害発生時にモニターとOSDでの配置マップの整合性が合わないと最悪データ壊れたり、未知の不具合が起こるかも
モニターが保存してるデータベースは重要みたいで、モニターノードは頻繁にfsync発行してるらしい（ちょっと曖昧）

**login:Penguin** · 2024/04/21(日) 04:19:58.10

Cephのベンチマーク
Proxmoxの３台のノードでCephを構築
３ノードで同時に書き込み（シーケンシャル）をして書き込みレートを合計
NIC1Gbps(cluster・public同)　60~70MByte/sec
NIC1Gbps(cluster・public別)　85~95MBye/sec
NIC1Gbpsｘ2 ( balance-rr cluster・public同 ) 115~130MByte/sec
NIC1Gbpsｘ2 ( balance-rr cluster・public同 ecpool ( k=2,m=1 ) ) 230~290MByte/sec

**login:Penguin** · 2024/04/27(土) 09:31:54.96

Proxmox VE 8.2 released!
https://forum.proxmox.com/threads/proxmox-ve-8-2-released.145722/

**login:Penguin** · 2024/04/27(土) 10:09:04.96

ついに来たな

**login:Penguin** · 2024/04/27(土) 10:10:27.03

なんか変わったん？

**login:Penguin** · 2024/04/27(土) 14:16:11.46

へぇ。8.1.8以降だと、ESXiからのライブマイグレーションもGUIからできるようになっているのか。
ttps://qiita.com/oishi-d/items/0cc452a022fa1ea07a7b

戻し(PVE→ESXi)もできるようになると面白いと思う。

**login:Penguin** · 2024/04/27(土) 20:40:22.11

>>37
なんと

前に調べた時は、ESXi -> proxmox の移行が割と面倒なのと、そもそもハードウエアの準備が間に合わなかったので、当面ESXi を使い続ける決断をしたのだが、いよいよ現実的になってきたな

**login:Penguin** · 2024/04/27(土) 23:30:42.39

ZFS RAID1のバグは直ったかな
完全同容量でないと入れられないやつ

**login:Penguin** · 2024/05/01(水) 12:13:10.01

>>39
バグか仕様かは知らないが
直ってない

**login:Penguin** · 2024/05/07(火) 23:10:49.83

>>40
これ変わらないと将来片方壊れたとき復元できないんだよな

**login:Penguin** · 2024/05/08(水) 00:10:42.82

DebianやUbuntuのZFS RAID1なら問題ないの？

**login:Penguin** · 2024/05/08(水) 01:34:52.53

>>42
ProxmoxのインストールでZFSのMirrorだと同容量じゃないとインストール出来ないけど
コマンド前提で、インストール後のデータディスクなどにで、異なる容量でミラーを新規作成は-fオプションで可能
壊れたディスクを新しい容量の違う（より容量の多きい）に交換も可能

**login:Penguin** · 2024/05/08(水) 19:06:40.48

>>43
詳しく
pve片肺で入れたあとにもう1個繋いでzfsコマンドの-fでraid1作るってこと？-fなんかあったっけ
あとbootパーティションどうにかしないと起動しないよな。grub2再構築だけだといけなかった記憶

警備員[Lv.6][初] · 2024/05/09(木) 01:18:37.80

>>44
ちょっと気になったから実際に試してみた

◆Proxmoxの起動ディスクを異なる容量のZFS・Mirrorを構築する手順？
（BIOSのUEFI、CSM、SecureBoot等々の組み合わせで、ダメかもしれないが・・・）

インストール画面でZFSのRAID0を選択して容量の少ない方の単独のディスクにインストール
（ disk 0にインストール先　disk 1~ に --do not use-- を選択）

インストール後に、以下の手順でbootやら、ZFSミラーやらを構築

gdisk /dev/sdxでパーテーションを作成（Mirror先が /dev/sdb の場合）
・1 MB BIOS Boot Partition ( gdisk type EF02 )
・512 MB EFI System Partition ( ESP, gdisk type EF00 )
・ZFSミラー用のパーテーション( Type BF01 )

以下のコマンドで起動部分を構築
・proxmox-boot-tool format /dev/sdb2
・proxmox-boot-tool init /dev/sdb2

zpool statusで既存のプールのディスク名を確認「例）scsi-0QEMU_QEMU_HARDDISK_drive-scsi0-part3 」
以下のコマンドで単独のディスクからMirrorに変更
zpool attach rpool scsi-0QEMU_QEMU_HARDDISK_drive-scsi0-part3 /dev/sdb3
（容量に関する警告が出来る場合は -f で無視できる）

データのミラーリングが完了したら構築完了

参考用検索ワード　「proxmox Host_Bootloader」

**login:Penguin** · 2024/05/12(日) 13:35:30.68

kernel更新したらpt3_drv.koの組み込みでコケるようになった
素人判断で合っているのかどうか分からんけど、これで直った

diff pt3_pci.c-dist pt3_pci.c
929c929
< rc = dma_set_coherent_mask((struct device *)pdev, DMA_BIT_MASK(64));
---
> rc = dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(64));