ZFS、iSCSI、PXE を使用したディスクレス Linux ブートシステムの構築

多くの開発者にとって、安定したゲーム用またはメインの OS と柔軟な開発環境との間の緊張は常に課題です。さまざまなツールチェーンで Windows インストールが「汚染」されるのを防いだり、Windows Update が GRUB エントリを上書きするのを防止したりすることに関わらず、隔離された高性能な環境への欲求は共通しています。

USB ドライブはライブ Linux 環境で頻繁に使用されますが、紛失や消去が容易です。より堅牢でプロフェッショナルな解決策はディスクレスブートです。PXE（Preboot Execution Environment）、iSCSI、ZFS を活用することで、リモート NAS からフル Linux インストールを起動し、ネットワーク接続されたブロックデバイスをローカルハードドライブのように扱うことが可能です。

アーキテクチャ

この構成は、サーバーがブートインフラとストレージを提供し、クライアント（ゲーム PC やワークステーション）が計算リソースを提供するクライアント‑サーバーモデルに依存しています。

サーバースタック

  • Netboot.xyz: ネットワーク経由でさまざまな OS やインストーラを起動するためのメニュー駆動インターフェースを提供する多用途ツール。
  • TFTP (Trivial File Transfer Protocol): 初期ブートローダーのバイナリをクライアントに配信するために使用されます。
  • DNSMasq: DHCP サーバーとして機能し、クライアントのアーキテクチャ（BIOS 対 UEFI）に基づいて TFTP サーバーへ誘導します。
  • ZFS ZVol: ZFS プール内に作成されたブロックデバイスで、仮想ディスクの生ストレージを提供します。
  • iSCSI Target (targetcli): ZFS ZVol をネットワーク上のブロックデバイスとしてエクスポートし、クライアントがローカル SCSI ディスクとしてマウントできるようにします。

実装ガイド

1. ブートインフラの設定

最初のステップは、Debian 系サーバー（例: Proxmox）に netboot.xyz をインストールすることです。これには、Web サーバー（Apache）、TFTP、そして netboot アセットのデプロイを自動化する Ansible のインストールが含まれます。

カスタムブートターゲットをサポートするために、.ipxe スクリプトを作成する必要があります。このスクリプトは、クライアントに iSCSI サーバーの IP と特定の Target IQN を使用して sanboot（SCSI ネットワークブート）を試行させます。ブートが失敗した場合（初回インストール時に起こります）、スクリプトは Debian インストーラへフォールバックするように設定されています。

2. ネットワーク構成

DHCP サーバー（例: DNSMasq を実行しているルータ）は、異なるクライアントタイプを処理できるように設定する必要があります。典型的な構成は以下の通りです：

  • BIOS クライアント: netboot.xyz-undionly.kpxe に誘導されます。
  • UEFI クライアント: netboot.xyz-snp.efi に誘導されます。
  • iPXE クライアント: 初期ブートローダーが実行された後、以降のリクエストは Web サーバー上にホストされた menu.ipxe にリダイレクトされます。

3. ストレージと iSCSI の構成

ZFS を使用して、ディスクイメージとして機能する ZVol を作成できます：

zpool create tank /dev/disk/by-id/${DISK_ID}
zfs create -V 32G tank/debian-disk-12700k

この ZVol は targetcli を介してエクスポートされます。重要な手順は、バックストアの作成、iSCSI ターゲットの定義、そして相互認証（イニシエータとターゲットの両方のユーザー名/パスワード）を使用したアクセス制御リスト（ACL）の設定です。これにより、ネットワークディスクが不正なクライアントに露出しないようにします。

4. OS のインストール

iSCSI ターゲットに Debian をインストールするには、インストールプロセス中にいくつかの手動介入が必要です：

  1. イニシエータ設定: インストーラが iSCSI ターゲットを自動的に検出しない可能性があるため、TTY（Super+F2）に切り替えて /etc/iscsi/initiatorname.iscsi をサーバーで設定した IQN に合わせて編集する必要があります。
  2. iscsid の再起動: 新しいイニシエータ名を認識させるために iscsid デーモンを再起動する必要があります。
  3. ターゲットへのログイン: インストーラに戻り、ポータルアドレスと認証情報を提供してリモート ZVol をローカルディスクとしてマッピングできます。

インストールが完了し、GRUB が iSCSI ディスクにインストールされたら、システムを再起動できます。iPXE スクリプト内の sanboot コマンドは、起動可能な OS を検出して起動します。

技術的考慮事項とトレードオフ

パフォーマンスとレイテンシ

実装で指摘されたように、ネットワークブートはローカル NVMe ストレージに比べて本質的に遅くなります。RAM ディスクは OS の一部を緩和できますが、根本的なボトルネックはネットワーク速度です。

コミュニティの見解では、プロダクションレベルのディスクレス構成には 10Gbps Ethernet がほぼ必須とされています。さらに、iSCSI はネットワーク混雑に敏感です。パフォーマンスを最適化するために、以下が推奨されます：

  • iSCSI トラフィック用に専用 VLAN を使用する。
  • スイッチで Quality of Service（QoS）設定を実装し、ストレージトラフィックを優先する。
  • iSCSI の代替として、最新かつ高性能な NVMe over TCP を検討する。

安定性と保守性

この構成の主な利点の一つは OS の集中管理です。ブートローダー（GRUB）がリモートドライブにあるため、ローカルの Windows 更新が Linux のブートシーケンスを壊すことはありません。

しかし、一部のユーザーは rEFInd のような GRUB の代替案を提案しています。rEFInd は単一のテキスト設定ファイルを使用して EFI 管理を簡素化し、カーネル更新時の UEFI エントリの保守の複雑さを減らします。

他の方法との比較

iSCSI がブロックレベルのインターフェースを提供する一方で、他の開発者はディスクレスブートに NFS（Network File System） を好むことがあります。NFS は設定が簡単なことが多いですが、ファイルレベルで動作します。ゲスト OS がディスクのパーティショニングやファイルシステム（サーバーがネイティブにサポートしていないファイルシステムのインストールなど）を完全に制御する必要がある場合、iSCSI が一般的に好まれます。

"I've been running iSCSI volumes for OrangePI boards which had only SD card support for years. Performance was much better on Gigabit Ethernet vs the SD card."

"私は数年間、SD カードしかサポートしない OrangePI ボードで iSCSI ボリュームを使用してきました。Gigabit Ethernet の方が SD カードに比べてはるかにパフォーマンスが良かったです。"

サマリテーブル: ローカル vs. ディスクレスブート

機能 ローカル NVMe ディスクレス (iSCSI/PXE)
起動速度 超高速 ネットワーク依存
分離性 共有ディスク/パーティション 完全な物理的分離
保守性 手動パーティショニング 集中型イメージ管理
リスク ブートローダー上書き ネットワーク障害 = システム停止
柔軟性 固定ディスクサイズ 動的 ZVol リサイズ

Sources