物理マシンにそのままOSをインストールすると再起動後のPOSTで待たされます。 仮想マシンであればPOSTはなく、再起動は迅速です。 これはメンテナンスをやりやすくします。 物理マシンが32GB程度を相場にするようになって数年になります。 サーバに積むべきメモリの相場はせいぜい4GB程度です。 レンタルサーバは1GB程度がコスパで選ばれると言います。 物理サーバをシングルで使うとメモリを持て余す時代になりました。 メモリ搭載量にもよりますが、 物理サーバにおよそ32GB程度以上積んでいるのであれば、 仮想化基盤を積極的に導入するのが良いと思います。
32GBメモリに乗る程度のgemma 4 12B Q8を試しました。 DDR4メモリとCPUで推論させて2.5tps前後の実績は、 コードエディタにバックエンドAPIとして与えるには遅すぎる感じです。 GPUがないと厳しい印象です。 GPUは高額なパーツなので、投資して回収できるかどうかが難しいところでもあります。 クラウドAPIは課金事故が起きますので簡単には採用できません。 どうするか悩ましいですね。
昨今のBIOS設定ではほとんどの場合で2GBをVRAMとして予約します。 これは実際のところどんな数字なのでしょうか。
バックアップ等は削除するときは根こそぎなのでdedupeしても実害は小さく、 むしろdedupeをすることが当たり前になりつつあります。 しかしプライマリストレージのdedupeはやめたほうがよいでしょう。 これには経験則からくる理由があります。
プライマリストレージは残容量を睨みながら運用することが普通です。 ファイルを収める容量が足りなくなれば不要なファイルを削除すればいいという判断をしがちです。 dedupeされたストレージでは、ファイルを削除すればいい、という判断は意図したように結実しません。 dedupeしてしまうと、ほとんどの場合でファイルに予期せぬ参照が残ります。 不要なファイルを削除しようと頑張っても、 参照は減りますが、書き込んで失われた容量が戻らないことに気がつくはずです。 dedupeされたストレージでは、 残容量が足りないと思った頃には致命的なまでに手遅れになっています。 dedupeされたストレージには、容量を見失わせるという副作用があることを忘れてはいけません。 一度ファイルを置いたら、以後削除できない(削除しても容量は取り戻せない)と考えるだけの計画と覚悟が必要です。
dedupeされたストレージを使う場合、 仮想化基盤用途のストレージであれば大抵の仮想ゲストの中身が同じであるという期待をしがちです。 実際には、そう上手くは行きません。 まず、ゲスト側メタデータが微妙にユニークなデータとして残ります。 年月が経てば各ゲストについてソフトウェア更新をしますから 少しづつバージョンの異なるゲストが散らばってゆくことになります。 これらが積み重なって意外に容量を食います。 ですから、dedupeされた仮想基盤だから容量削減が十分に効くものだとは思わないほうが良いです。
個人的に思うのは総書き込み容量をベースにして容量を決めるのが妥当ではないかと思います。 5年間使うストレージならば、重複率を念頭に置きつつも年間で書き込む容量の5倍を最初に確保しましょう。
現在のところ汎用DRAMチップの供給が絞られており、価格高騰が収まる様子はありません。 通常、このような状況になるとシェアを取るために低価格販売をするメーカが現れるものですが、 今回はそのような価格競争が働く様子はなく、 高値に張り付いた相場で取り引きされていると言われています。
メモリの値段が落ち着くかどうかはあと2年ほど様子見をする必要があります。 パソコンのビルドで32GBを積んでいればそれまで持ちこたえる可能性は高いです。 16GB搭載が完成品パソコンのメインストリームであることを考えると、 16GB搭載でも逃げ切れる可能性は高いでしょう。 8GBの選択は昔は可能でしたが、 今からそうするのはやめておいたほうが良いと思います。
Proxmox VEで単騎ストレージを構成する場合はLVM-Thinを選ぶことが勧められます。 LVM-Thinであれば生に近いパフォーマンスを引き出せます。 ストレージを二発積んでミラーを組みたい場合など、 ソフトウェアRAIDを構成したい場合は消去法でZFSを選ぶことになります。 ストレージが大きくなりすぎてLVM-Thinではメタデータが肥大化するのではないか、 と考えられる場合もZFSを選びます。 ストレージ総量が8TBを超えるようであればZFSのほうが有利だと考えています。
コンシューマグレードのメインボードでは、 SSDストレージを双発にすることが実用的ではありません。 CPUからNVMeに繋ぐレーンが少なく、AMD CPUであれば通常はPCIe 4レーンしか確保されていないからです。 このため通常はSSDストレージを単発で構成します。 SSDなら小容量でしょうし、だいたいにおいてLVM-Thinが有利です。
エンタープライズではストレージの双発は珍しくありません。 ほとんどの場合でハードウェアRAIDを組むでしょう。 ハードウェアRAIDであれば基本的にLVM-Thinを選ぶべき、とされています。 わざわざHBAモードを選ぶことは極めて稀ですから、 ZFSを使うことはないと考えて問題ありません。
Proxmox VEでは、異なるストレージプラグイン間においてコールドマイグレーションができません。 データコンバート処理がコールドマイグレーション機能においてサポートされていないのです。 ストレージプラグイン間のコンバート処理は専用のMove Diskメニューで独立して対応することになります。 ZFSノードとLVM-Thinノードの間で移送したい場合は、 中間形態のストレージとして共有NFSが必要です。
ライブマイグレーションを行う場合は、 ホストCPUがIntelかAMDかでブランド統一されている必要があります。 ライブマイグレーションを前提に調達するときはCPUをノード間で統一します。 新旧クラスタ間で移送するなどの特殊なパターンではライブマイグレーションが使えないことがあります。 ライブマイグレーションができないならコールドマイグレーションをするのですが、 そのとき機能制限に引っかかる場合があります。
Proxmox VEのGUIインストーラではLVM-Thinを明示的に選ぶオプションはありません。 ext4かXFSのいずれかを選べば、LVM-Thinを利用するものとして扱われます。
LVM-Thinはオーバーコミットを許します。 一時的なオーバーコミットに問題はありません。 オーバーコミットの常態化は原則として避ける必要があるでしょうね。 オーバーコミットが原因でストレージがショートすると、 ゲストシステムの停止に直結するからです。