仮想基盤システムを設計しよう

はじめに

自宅のサーバ環境はRaspberry Piからはじまり、SynologyのNAS、ミニPCを利用したベアメタルLinuxサーバを使用していました。
NASのHDDが経年更新のタイミングとなったため、ここでNASを更新するとともにLinuxサーバを含めたハードウェアを統合することを決意たのです。

1台のベアメタルマシンで全てカバーしてもよいのですが、管理と分離が容易な仮想化基盤を採用し何となく逸般の誤家庭を目指します。

本稿では設計内容をそれぞれ紹介していきます。

要件

NASはファイルサーバとして使っていた事はもちろん、メインマシンであるWindowsのゲーミングPCのバックアップリポジトリやDBサーバとしても使っていました。
LinuxサーバはDockerのホスト、ゲーミングPCを使うまでもないブラウジングに利用していました。
この内容で必要な機能とアプリケーションをまとめます。

• Samba/NFSファイルサーバ
• DBサーバ
• Windowsに対する自動バックアップ
• Docker
• デスクトップ環境

ハードウェア要件は下記です。

• SSD, HDDを搭載可能
• 1GbE以上の有線LAN
• x86_64アーキテクチャ
• 映像出力とUSBホストが存在

ディスクはオールフラッシュ構成としてもよかったのですがコスパを取ってHDDとします。
正直ファイルサーバのアクセス速度はどうでもいいです。

バージョン

 執筆時点での各種バージョンは下記です。

• Proxmox VE 8.4
  • Debian 12.12
• Windows 11 Pro 24H2
• Ubuntu Server 24.04
• Rocky Linux 9.7
• Xubuntu 24.04
• Veeam Backup and Replication 12 Community Edition

ハードウェア選定

AOOSTARのコンパクトPCを密林で発見しました。（今は売り切れている。）

• SATA 3.5" HDDを2個、M.2 SSDを2個搭載可能
• CPUはAMD Ryzen 7 5825u（ノートPC用のCPU）
• メモリSODIMM DDR4 最大64GB
• NICはメタル2.5GbEが2個、WiFiが1個、Bluetoothが1個

商品説明に仮想基盤を搭載してもいいのよと書いてありますので乗ってみます。
縦型で収納サイズがコンパクトになるため採用を決断しました。

仮想基盤

Proxmox Virtual Environment（以降PVE）を使用します。
Proxmox Virtual Environment公式

ホストPCにプリインストールされているWindows 11 ProとHyper-Vを使用してもよかったのですが、面白くないという理由で却下しました。
権限による不整合の恐れがあるため、実行する仮想マシンはLXCではなく、基本的にVMとしてデプロイします。
コンテナが必要な場合はVM上のDockerを使用します。

クラスタリング/HA

仮想基盤の特徴であるクラスタリングは行いません。今のところいらないです。
HAによる自動フェイルオーバのためには、同じPCが最低2個とNAS or SANが最小構成のようです。
この辺りは他メーカの3Tier/HCIと似た構成になるでしょう。
Proxmox Cluster Manager

GUI

PVEの管理コンソールはWEBポータルなので使うためには別のPCが必要です。
PVEは通常のDebianと仮想化基盤のパッケージで、ホストのDebianにはデスクトップ環境をインストール可能です。
デスクトップ環境は軽量なXfce4とX11を採用します。
ただしホストからインターネットを使うのはなんか嫌なので、ローカルネット以外へのブラウジングは基本的にVM上で実行します。
ついでにホスト→インターネットへのアクセスをファイアウォールで阻止します。

仮想マシン・コンテナIDの管理

PVEはVMとLXCでそれぞれ独立したIDを割り当てることが可能です。
ただし、今回は見た目で混乱しないようにVMとLXCを合わせてユニークなIDを採番します。
VMとLXCともにホスト名を振って区別出来るようにします。

物理ディスク

マザーボードにはWindows 11 ProがインストールされたM.2 SSDが最初から搭載されています。
残り空きスロットはM.2が1個とSATAが2個です。

M.2スロット1

Windows SSDはそのままWindows用とします。
PVEのデバイスマウントを使い、VMから物理ディスクを起動先に指定します。これでVMであるにもかかわらず、仮想ディスクとは別のディスクからOSを起動できます。

M.2スロット2

新規で1TBのSSDを追加し、これを仮想基盤用とします。計算は後述します。
散歩中に偶然KIOXIA Exceria Plus G3の安売りを発見したので即決しました。マザーボードもPCIe 4.0ですので過不足はありません。
仮想マシンのバックアップはマシン単位として、ホストディスク単位のバックアップは考慮しないとします。
バックアップ内容は後述します。

SATAスロット

ファイルサーバ専用とします。
HDD WD Red Plus CMR 8TB×2を搭載しミラーリングとします。
フォーマットはRHEL系と同じくXFSを採用します。移行元のSynology NASはBTRFSでした。
噂程度ですがXFSは速度が高く復旧時間も短いらしいです。（未検証）
Red Hat Documentation 第3章 XFS ファイルシステム | ストレージ管理ガイド

XFSは単体でソフトRAIDを組めないため、ホストDebianでmdadmによるソフトRAIDを構成しアレイデバイスとします。下記はRHELのドキュメントですがインストール以外はDebianでも同じです。
Red Hat Documentation 6.3. ソフトウェア RAID の管理 | デプロイメントガイド

さらにPVEにデバイスマウントとしてファイルサーバVMにマウントします。
これで論理上はディスクアレイがファイルサーバVMに直結されている事になります。
強引に図にするとこんな感じです。

仮想ディスク

仮想マシン用の仮想ディスクはデフォルトのLVM（シックプロビジョニング扱い）とします。
仮想ディスクの合計容量 < 物理ディスク容量が設計時に確定しているためです。
シンプロビジョニング？なにそれおいしいの？

メモリ

最大容量である64GBを搭載します。既存のよくわからんメモリは撤去します。
搭載するメモリは無難にCrucial製PC4-25600にしました。
仮想マシンに割り当てるメモリ容量は別途定義とします。

CPU

これは換装出来ないのでそのまま使うしかありません。
PVE上で見ると16CPU扱いとなっていました。（8コア16スレッドなので論理16コア）

PVEもオーバーコミットが使えるのでvCPUの合計上限は元の3倍である48コアを目安とします。

I/F

PC本体にあるUSBとHDMIはKVMスイッチを接続しておきます。
これでホストのTTYを直接操作可能、VMもホストTTYから操作可能です。
UPSは繋ぎません。そんな物は無い。

仮想マシン

VMのOSは基本的にCLIのUbuntu Serverを採用します。ディストリビューションは何でもいいのですがPVEがDebianなので同じくAPT系で扱いやすいUbuntuとしました。
Ubuntu Server公式

LXCはDebianコンテナを採用します。これもPVEがDebianのためです。
Ubuntuとしなかったのは20MBほどファイルサイズが大きかったためです。

ただし、DBサーバのみRHEL、つまりRPM系Linuxが必要となるため（後述）、ここはRocky Linuxを採用します。
Rocky Linux公式
RHELクローンと言う事でAlma Linuxと迷いましたがぶっちゃけRocky Linuxと同じ物です。ルーレットでRocky Linuxに決まりました（？

GUIマシン

ホストXfce4、もしくは同一ネットワーク上の端末からGUIマシンVMをリモート操作します。
リモート操作はNoVNCではなくパフォーマンスの高いSPICEを使用します。NoVNCとSPICEともにPVEの管理コンソールからアクセス可能ですが、操作クライアント側にもSPICEをインストールする必要があります。
SPICE公式

閲覧用のVMはUbuntuにXfce4を標準搭載するXubuntuを採用します。
Xubuntu公式

Windows VMは定石通りWindowsリモートデスクトップからアクセスします。
Linux GUIからWindows VMにアクセスする際はRemminaを採用します。
RemminaはVNCやSSHクライアントも兼ねているので便利です。
Remmina公式

ネットワーク

ソフトファイアウォールでゾーン分割します。
ソフトファイアウォールも仮想基盤上に構築します。
構築するゾーンは下記とします。

• WAN
• DMZ
• LAN
• VPN（後述）

ホストマシンにある2個の物理NICはWANゾーンとLANゾーンに割り当てます。
DMZは今のところ使う予定はありませんがとりあえず作っておきます。

仮想ネットワーク

PVEの機能をそのまま使います。
VPN以外のゾーンに対応する仮想ネットワークをPVE上で作成します。
VPNゾーンはルータ内で完結するため仮想ネットワークへの接続は不要です。
仮想VLANも設定可能ですが、我が家にマネージドスイッチは無いので使えません。

物理NIC

ブリッジで仮想NICと物理NICを接続しますが、ここでLANゾーン用の仮想NICにIPアドレスを割り当てます。
これでホストDebianはLANゾーンのみの接続となります。
WANゾーンの物理NICにはIPアドレスはありませんので、ホストはWANゾーンと隔離されます。

WANゾーンはブロードバンドルータのLANに直結とします。（ややこしい
ブロードバンドルータにはWIFI APがあり、現在は携帯電話や会社PCなどがつながっています。ですが会社のPCをLANゾーンに入れるのはなんか嫌なのでWANゾーン扱いとします。
つまり、ブロードバンドルータの下位がWANゾーンです。
携帯電話はVPNからLANゾーンにアクセス可能とします。

LANゾーンの物理NICはゲーミングPCに直結します。
これでファイアウォールとゾーニングの恩恵を受けられます。
先述の通り仮想NICにIP割り当てを行わないと物理NICが使えなくなります。

ファイアウォール＆ルータ

ソフトウエアファイアウォールのpfSenseを採用します。
pfSenseはLinuxではなくFreeBSDベースであるためVMにしかデプロイ出来ません。
pfSense公式

いずれのゾーンも固定IPとします。
ファイアウォールに複雑なルールは特に求めていないため、pfSenseデフォルトの設定とします。
ゾーン間の通信動作設定の概略は下記です。

元	先	通信
WAN	LAN	全て拒否
WAN	DMZ	必要な物だけ許可
LAN	WAN	全て許可
LAN	DMZ	全て許可
DMZ	WAN	全て許可
DMZ	LAN	必要な物だけ許可
*	WAN	WireGuardだけ許可

VPNゾーンは下記とします。

元	先	通信
WAN	VPN	全て拒否
LAN	VPN	全て拒否
DMZ	VPN	全て拒否
VPN	WAN	全て許可
VPN	LAN	全て許可
VPN	DMZ	全て許可

仮想マシン内のファイアウォールは必要なルールだけONとします。
PVEの仮想ネットワークにあるファイアウォールはOFFとします。

DNS

外部公開するのDNSサーバは用意しません。いらないです。
DNSリゾルバとDNSフォワーダはpfSenseの機能として利用可能ですが、今回はDNSシンクホールのAdGuard Homeも採用します。
AdGuard Home GitHub

これでブラウズ中の広告除去をサーバで行えます。
こちらは特権が不要であり、簡略化のためLXCにデプロイとします。

VPN

WireGuardを採用します。
pfSenseのプラグインにWireGuardが存在しており、ルータ機能の一部に含める事が可能です。
VPNゾーンからは残りすべてのゾーンとの通信を許可とします。したがってLANゾーンとほぼ同じ条件となります。
また、WireGurdへの着信を許可するためにAny→WANの通信許可設定を入れます。
WireGuard | pfSense Documentation

DB

既存システムで利用していたMariaDBとPostgreSQLを採用します。
専用のVMにするべきですが、既存NASと同様の簡単構成でファイルサーバにデプロイします。
DBとファイルサーバが同時ダウンしても問題無いので割り切りました。

PCバックアップ

バックアップ対象は下記です。

• ファイルサーバ
• Dockerホスト
• VBRサーバ
• ゲーミングPC

pfSenseは設定完了後に手動で設定をバックアップとします。
AdGuard Homeは設定ファイルだけバックアップとします。
Linux GUIは破壊されても問題ないのでバックアップ不要です。

バックアップソリューション

Synology NASはもう使わないので、Synologyバックアップソリューションの代替が必要です。
今回はエンタプライズ環境で採用したことのあるVeeam Backup & Recovery 12（以降VBR）を採用します。
本来であればエンタプライズ用製品ですが、個人利用であればなんと無料のCommunity Editionを使えます。
Veeam公式

ただし、接続先10台までの上限やバックアップ先にクラウドを使えないなどの機能制限があります。まあ有償版の機能は使わないでしょう。
VBR12はWindows上で実行する必要があるため、既存のWindows上にVBRのシステムを構築します。
ちょうどWindowsは物理ディスクがPVEと別であり、本システムには適していると言えます。

バックアップリポジトリ

バックアップの保存先であるリポジトリはファイルサーバ、つまりホスト上のHDDとします。
コールドバックアップはAmazon S3としたいのですが、無償版では機能制限で使えません。
ここはRcloneを使い、HDDのファイルをS3に転送します。
Rclone Github

ゲーミングPC

Veeam Client for Windowsをインストールします。
バックアップ設定およびバックアップの実行はゲーミングPCから行います。

VBR VM本体

VBRを実行するWindows VMもディスクごとバックアップしてしまいます。
ゲーミングPCと同様にVeeam Client for Windowsでバックアップを行います。
また、VBR自体の設定も定期的に自動エクスポートするよう設定します。

各仮想マシン

VBRは仮想化基盤と直接連携して仮想マシンをバックアップ可能です。
もちろんPVEも対応していますが、VBRとPVEの連携には、専用の Linux VMをVBRからデプロイする事になり、VMが一つ増える事になります。
このVMが曲者で仮想ディスクのサイズやLinuxのログインパスワードなどをデプロイ時に指定する事が出来ません。
リソースを食うので上記Windowsマシンと同様にクライアントからのバックアップ実行とします。
Linuxマシン用のVBRクライアントはVeeam Client for Linuxです。各種ディストリビューション用が提供されており、CLIから操作可能です。

DBバックアップ

いずれのDBも論理バックアップ（SQLコマンドとしてバックアップ）、物理バックアップ（DBのファイルごとバックアップ）双方を遊び半分で採用します。
バックアップ先ディスクはファイルサーバの保存先であるHDDとします。
VBRでVMごとバックアップしますが、まあこまけえこたあいいんだよ

MariaDB

論理バックアップにはmysqldump、物理バックアップはmariabackupを使用します。
いずれもMariaDB本体に付属している物です。
mysqldump公式
mariabackup公式

PostgreSQL

論理バックアップにはpgdump、物理バックアップにはpg_rmanを使用します。
pgdumpはPostgreSQL本体に付属しています。
pgdump公式

ここで、pg_rmanはRPMパッケージもしくはソースコードでの提供です。
RPMパッケージを使用するために、DBサーバのOSにはRocky Linuxを採用としました。
pg_rman GitHub

Dockerボリューム

以前操作ミスでボリュームを吹っ飛ばした事があったのでボリュームのバックアップを行います。
ボリュームバックアップ用のvolume-backupというイメージがありました。
圧縮したボリュームはDokcerホストVMからファイルサーバVMのHDDに送ります。
volume-backup GitHub

仮想マシンの役割

まとめると下記となります。

• ルータ・ファイアウォール・VPN
• DNSシンクホール
• ファイルサーバ
  • DBサーバ
• Dockerホスト
• VBRサーバ
• Linux GUI

これらに仮想リソースを下記の通り割り当てます。
仮想環境なのでvDISKの縮小以外スケーリングは容易です。
PVE本体が使用するリソースを予約として計算に入れておきました。

役割	種類	OS	vCPU	vRAM [GB]	vDISK [GB]	備考
DNSシンクホール	LXC	Debian Container	1	0.5	2
ルータ	VM	FreeBSD (pfSense)	2	2	20
ファイルサーバ	VM	Rocky Linux	4	16	200
Dockerホスト	VM	Ubuntu Server	4	8	100
VBRサーバ	VM	Windows	4	16	-	vDISK不要
GUI	VM	Xubuntu	4	8	50
(PVE)	ホスト	Debian	(2)	(8)	(50)	予約分
合計	-	-	21	58.5	422

ものの見事にOSがバラバラですが、ちゃんと動きます。
これらの設計内容をもってシステムを組み上げますが、個々の実装手順については他の方が書かれているので改めて書く必要は無さそうです。
特徴箇所があればレポートは別途書こうと思います。