👻
おっさんのお小遣いで作るホームラボ〜10万円で作るHCI〜 ⑥(終) Proxmox VEでHCIの動作を確認する

2025/08/26に公開
インフラ系の常としてお盆の稼働もあり大分時間が空いてしまった。

今回はCephのプールを作成して、その上にVMを建てて問題なく動作することを確認したい。
ということで、今度こそようやく仮想マシンを動かせる状態に持って行くのだけど…

丁度Ver.9が正式リリース。
せっかくなので先にバージョンアップを実施してしまおう。そうしよう。

 番外：V8からV9へのバージョンアップとはいっても、まだ何もやってないのでやることは公式手順を実行するだけ。

Cephクラスタは停止しておき、選択肢は基本デフォルトのままで実行。

無事にアップデート完了して特に不具合もなさそう。



やったぜ。
作業後にリポジトリの不要リストを削除しておわり。

手順でコンソールから実施するように記載があったのを見逃してWEB画面でハングしてしまったのは内緒。

dpkg --configure -aして復旧させたのでノーカンでいいよね。

 Cephプールの作成さて、無事にバージョンアップも終わったので本来予定していた作業を実施していく。

ProxmoxでCephでストレージクラスタを作っただけではデータの保存先としては使えない

のでプールを作成する。
適当なノードを選択し、[Ceph]-[Pools]から[作成]を選択
適当に名前を設定して[作成]で完了。


こんな感じでサクッと設定完了。

簡単ですね。

ということで、最後にVMを建てて動作確認だ！

 参考：Ceph データ配置ポリシーの作成Proxmoxのデフォルト状態では、データ配置ポリシーはreplicated_ruleしか選べない。

具体的にCephとはなんぞやというところはこの辺を見てもらうとして、

プール作成時にイレイジャーコーディングを有効にしてRAID5的にも使えるようルールだけは作っておく。

このあたりの作業はGUIでは非対応なので、コマンドでポチポチと。

VM乗っけるプールにはイレイジャーコーディングは非推奨らしいから今回は使わない予定。しょうがないね。

 CRUSHルールの作り方まずはプロファイルの作成。プロファイルの作成こんな感じで作る。
ceph osd erasure-code-profile set ecprofile \
  k=2 \
  m=1 \
  plugin=jerasure \
  technique=reed_sol_van \
  crush-failure-domain=host


パラメータ
説明


k=2
データチャンク数（元データを2分割）

m=1
コーディングチャンク数（1つの冗長チャンク）

plugin=jerasure
標準的なECライブラリ

technique=reed_sol_van
高速で安定したアルゴリズム

crush-failure-domain=host
チャンクをホスト単位で分散し、1ホスト障害に耐える

この構成なら、3つのOSD（または3ホスト）に分散され、1つの障害に耐えられるRAID5相当の冗長性を実現できる。

本当はコーディングチャンクは2つ以上が望ましいということだけどホストが3つしかないからね。しかたないね。
続けてルールの作成
ceph osd crush rule create-erasure erasure-code-rule ecprofile
これでerasure-code-ruleという名前のCRUSHルールが作成したecprofileに基づいて作成される。
作成後の確認

ルール一覧表示：
ceph osd crush rule list
ルール詳細確認：
ceph osd crush rule dump <ルール名>
さて、実際に設定されているか確認する。
root@pve1:~# ceph osd crush rule list
replicated_rule
erasure-code-rule
root@pve1:~#
たぶんヨシ！
ちなみにルールに反映したプロファイルの構成はプール作成時に変更できないので注意。

もっと大規模なクラスタなら階層化しても面白いはず。

ちょっと今の構成ではできないけども。

 仮想マシンを建てるさて、この辺は特に何かあるわけではないのでサクッとやってしまう。

ホスト側が非力なので極力準仮想化デバイスを使って構築することにする。

細かい話はこのあたりの記事で詳しく解説されているので見てもらうとして…

ゲスト側のOSとしてはみんな大好きWindows11を選んでみる。

KVM向けWindows11用のVertIOドライバ（準仮想化ドライバ）はFedoraにあるこれを使う。探せば大体どうにかなるってとても素晴らしい。
ということでできあがり。



無事に起動してる。
注意点としては準仮想化ドライバの導入時にドライバのISOファイルをVM側で認識させる必要があるくらいかな。

WinSAT(古い)で見たところこんな感じ。
CPUScore:8.4
D3DScore:9.9
DiskScore:8.1
GraphicsScoer:2.2
MemoryScore:8.4
まあまあ動作確認には使えそうなレベル。

常用はちょっときついかな。
これで一応HCIとして使えるところまで完成。お疲れ様でした。

しかし結構かかったなあ。

 仮想マシンのホストを移動してみるせっかくクラスタ構成にしたので、ちゃんとできるよね、ということでVMの活性マイグレーションを実施してみる。

やり方としてはVMの管理ウインドウから「マイグレート」を選んでターゲットノードを選ぶだけ。
実行時はこんなログが流れて実行状態がわかる。
マイグレーションログ2025-08-XX XX:41:44 starting migration of VM 100 to node 'pve2' (192.168.255.102)
2025-08-XX XX:41:44 starting VM 100 on remote node 'pve2'
2025-08-XX XX:41:47 start remote tunnel
2025-08-XX XX:41:48 ssh tunnel ver 1
2025-08-XX XX:41:48 starting online/live migration on unix:/run/qemu-server/100.migrate
2025-08-XX XX:41:48 set migration capabilities
2025-08-XX XX:41:48 migration downtime limit: 100 ms
2025-08-XX XX:41:48 migration cachesize: 1.0 GiB
2025-08-XX XX:41:48 set migration parameters
2025-08-XX XX:41:48 start migrate command to unix:/run/qemu-server/100.migrate
2025-08-XX XX:41:49 migration active, transferred 58.1 MiB of 8.0 GiB VM-state, 122.8 MiB/s
2025-08-XX XX:41:50 migration active, transferred 162.1 MiB of 8.0 GiB VM-state, 145.9 MiB/s
2025-08-XX XX:41:51 migration active, transferred 269.0 MiB of 8.0 GiB VM-state, 947.3 MiB/s
2025-08-XX XX:41:52 migration active, transferred 381.9 MiB of 8.0 GiB VM-state, 114.8 MiB/s
2025-08-XX XX:41:53 migration active, transferred 494.3 MiB of 8.0 GiB VM-state, 112.7 MiB/s
2025-08-XX XX:41:54 migration active, transferred 607.0 MiB of 8.0 GiB VM-state, 247.8 MiB/s
2025-08-XX XX:41:55 migration active, transferred 719.5 MiB of 8.0 GiB VM-state, 274.6 MiB/s
2025-08-XX XX:41:56 migration active, transferred 832.4 MiB of 8.0 GiB VM-state, 116.0 MiB/s
2025-08-XX XX:41:57 migration active, transferred 945.1 MiB of 8.0 GiB VM-state, 114.9 MiB/s
2025-08-XX XX:41:58 migration active, transferred 1.0 GiB of 8.0 GiB VM-state, 113.7 MiB/s
2025-08-XX XX:41:59 migration active, transferred 1.1 GiB of 8.0 GiB VM-state, 133.1 MiB/s
2025-08-XX XX:42:00 migration active, transferred 1.3 GiB of 8.0 GiB VM-state, 96.4 MiB/s
2025-08-XX XX:42:01 migration active, transferred 1.4 GiB of 8.0 GiB VM-state, 113.5 MiB/s
2025-08-XX XX:42:02 migration active, transferred 1.5 GiB of 8.0 GiB VM-state, 112.7 MiB/s
2025-08-XX XX:42:03 migration active, transferred 1.6 GiB of 8.0 GiB VM-state, 113.7 MiB/s
2025-08-XX XX:42:04 migration active, transferred 1.7 GiB of 8.0 GiB VM-state, 111.7 MiB/s
2025-08-XX XX:42:05 migration active, transferred 1.8 GiB of 8.0 GiB VM-state, 115.8 MiB/s
2025-08-XX XX:42:06 migration active, transferred 1.9 GiB of 8.0 GiB VM-state, 112.7 MiB/s
2025-08-XX XX:42:07 migration active, transferred 2.0 GiB of 8.0 GiB VM-state, 117.0 MiB/s
2025-08-XX XX:42:08 migration active, transferred 2.1 GiB of 8.0 GiB VM-state, 113.3 MiB/s
2025-08-XX XX:42:09 migration active, transferred 2.2 GiB of 8.0 GiB VM-state, 112.7 MiB/s
2025-08-XX XX:42:10 migration active, transferred 2.4 GiB of 8.0 GiB VM-state, 111.7 MiB/s
2025-08-XX XX:42:11 migration active, transferred 2.5 GiB of 8.0 GiB VM-state, 112.7 MiB/s
2025-08-XX XX:42:12 migration active, transferred 2.6 GiB of 8.0 GiB VM-state, 113.7 MiB/s
2025-08-XX XX:42:13 migration active, transferred 2.7 GiB of 8.0 GiB VM-state, 114.8 MiB/s
2025-08-XX XX:42:14 migration active, transferred 2.8 GiB of 8.0 GiB VM-state, 113.7 MiB/s
2025-08-XX XX:42:15 migration active, transferred 2.9 GiB of 8.0 GiB VM-state, 112.5 MiB/s
2025-08-XX XX:42:16 migration active, transferred 3.0 GiB of 8.0 GiB VM-state, 112.2 MiB/s
2025-08-XX XX:42:17 migration active, transferred 3.1 GiB of 8.0 GiB VM-state, 113.9 MiB/s
2025-08-XX XX:42:18 migration active, transferred 3.2 GiB of 8.0 GiB VM-state, 112.2 MiB/s
2025-08-XX XX:42:19 migration active, transferred 3.3 GiB of 8.0 GiB VM-state, 153.0 MiB/s
2025-08-XX XX:42:20 migration active, transferred 3.5 GiB of 8.0 GiB VM-state, 126.3 MiB/s
2025-08-XX XX:42:21 migration active, transferred 3.6 GiB of 8.0 GiB VM-state, 135.8 MiB/s
2025-08-XX XX:42:22 migration active, transferred 3.7 GiB of 8.0 GiB VM-state, 100.1 MiB/s
2025-08-XX XX:42:23 migration active, transferred 3.8 GiB of 8.0 GiB VM-state, 295.9 MiB/s
2025-08-XX XX:42:23 xbzrle: send updates to 25087 pages in 29.2 MiB encoded memory, cache-miss 81.73%, overflow 4243
2025-08-XX XX:42:24 migration active, transferred 3.9 GiB of 8.0 GiB VM-state, 283.0 MiB/s
2025-08-XX XX:42:24 xbzrle: send updates to 68771 pages in 59.3 MiB encoded memory, cache-miss 35.73%, overflow 8407
2025-08-XX XX:42:25 average migration speed: 221.7 MiB/s - downtime 152 ms
2025-08-XX XX:42:25 migration completed, transferred 4.0 GiB VM-state
2025-08-XX XX:42:25 migration status: completed
2025-08-XX XX:42:25 stopping migration dbus-vmstate helpers
2025-08-XX XX:42:25 migrated 0 conntrack state entries
2025-08-XX XX:42:28 flushing conntrack state for guest on source node
2025-08-XX XX:42:33 migration finished successfully (duration 00:00:50)
TASK OK
マイグレーションの速度は、ざっくりこんな感じ
裏でCephの同期がゴリゴリ動いてる状態：21MiB/s　(約7分)
比較的ストレージへの負荷が低い状態：110MiB/s　（約90秒）

ネットワーク負荷が低い状態だとワイヤースピード出てるので満足。

ただ、通常の動作時のマイグレーションはなかなかきつい。7分はちょっと待ち時間としては長いね。

 まとめっぽいもの一応まとめでもやってみる。

 費用これは正直どうにでもなるところだと思うので、あんまりいうことはない。

ただN100のミニPC(新品)がメモリ16GBとSSDが500GBで2万切りってのは在庫処分の投げ売りだよね。

 静音性当初の想定通りほぼ無音なので、割と満足できてる。

スイッチとルーターがファンレスなのが大きい。

 HCI機器構成HCI基盤自体の検証を物理的に分けてするという意味では必要十分なので、目的は達成できてるんじゃなかろうか。(仮想化でネストすればホスト一台で挙動くらいは見えるし）

今回はHCIを組むことを前提とした(目的と手段が逆転してる)ので、正直上にのせる仮想マシンのことは…
ただ、単純に仮想化の環境を作りたいなら、性能のいいPC一台、10万円ほど出してシングルサーバーでホスト立てた方がパフォーマンスも出て満足すると思う。
あとやっぱりL3スイッチはあった方がいいね。ルーターでもどうにかなるけどローカルのネットワークを構成するだけなら圧倒的にL3スイッチの方が楽。

 パフォーマンス(CPU)N100自体で13年ほど前のシングルソケットサーバーレベルの性能はあるので、LXCコンテナやWindows11クライアントを数台、検証用途に動かす程度なら全然余裕ではある。メモリさえ積めば。メモリさえ積めば。

やはり16GBだとちょっと足りないので、32GB位はほしい。HCIなのでトータル48GBあるじゃんと言われればその通り。

 ストレージ今回は普通のSATA SSDで組んだけど、これでも検証なら必要十分な感じ。

今はSATA SSDもNVME SSDも大して値段の差が無いので予算に余裕があるならNVME SSDを買った方がパフォーマンスがよくて満足度は高そう。

容量はさすがに512GBだと絶妙に足りない。動かすVM分は問題ないけどアーカイブや資材の保存分まではまかなえない。外部に別途ストレージ用意するか、1TB以上の内蔵ストレージはあった方がいいな。

 ネットワークHCIの場合NWの速度がもろにVMのマイグレーションやストレージの同期性能に影響するので、そっちの性能はもう少しいいものがほしい。
今回の動作確認では遅い場合は20MiB/sしか出てないので、これだとやはり厳しい。

メモリ8GiBのVMの場合、10Gbpsならマイグレーション速度がワイヤースピードの20%だったとしても単純計算で200MiB/sの40秒程度、2.5Gbpsでも160秒程度でいける。3分ならギリギリ許容範囲かなあ。

10Gbps推奨な理由がよくわかる。

 その他の機器構成
 あってよかったものKVMスイッチ：サーバーの接続機器がサクッと切り替えられるのはとても便利でよかった。
小型の入力機器とモニタ：やっぱり場所とらないのは素晴らしい。

 あるとよかったものIP-KVM：実は後半は別件で購入したNano-KVMをKVMスイッチにつないで触ってみたけど、やっぱりリモートで触れるのはとてもいいね。
ということで簡単なまとめ終わり

 最後にふと思いつきでHCIを作ってみたけど、OSSでもここまで簡単にできるようになったんだなあという思い。

今回は金銭的にも縛りをある程度つけた上で作ってみたけど、予想よりはちゃんと動かせるものができてよかった。N100すごい。

それに専有面積と音と消費電力を気にしなければ、中古のサーバーをよりどりみどりで買える。

これなら20コア程度のサーバーでも10万/台位でどうにかできるはず。N100よりは相当快適。

家で常用はしたくないけど。
さて、今後はこのクラスタでちょこちょこ仮想の何かを動かしてお勉強していこうかなあ。
パラメータ	説明
k=2	データチャンク数（元データを2分割）
m=1	コーディングチャンク数（1つの冗長チャンク）
plugin=jerasure	標準的なECライブラリ
technique=reed_sol_van	高速で安定したアルゴリズム
crush-failure-domain=host	チャンクをホスト単位で分散し、1ホスト障害に耐える
番外：V8からV9へのバージョンアップ

Cephプールの作成

参考：Ceph データ配置ポリシーの作成

CRUSHルールの作り方

仮想マシンを建てる

仮想マシンのホストを移動してみる

まとめっぽいもの

費用

静音性

HCI機器構成

パフォーマンス(CPU)

ストレージ

ネットワーク

その他の機器構成

あってよかったもの

あるとよかったもの

最後に

Discussion
