クライアントポータル自体の防御を整える #

サーバー作成より先に、管理面の防御方針を決めます。特にチーム運用では、
MFA と許可 IP の扱いを先に整理しておくと、後から「誰がどこから管理面へ入れるか」で迷いません。

SSH 鍵を登録してからサーバーを作る #

AI-SRV と GPU ワーカーを作成した後に個別で鍵を差し込むより、クライアントポータルの SSH 鍵管理で
先に鍵を整備しておくほうが、テンプレート展開後すぐに管理へ入れます。

• 運用チーム用の公開鍵を整理する
• 緊急時の共有鍵と個人鍵を混在させない
• 記事公開時は鍵 fingerprint も載せない

Bestnet Cloud 上に AI-SRV をテンプレートから作成する #

AI-SRV には Ubuntu 24 系テンプレートを使い、GPUStack Server と NFS の両方を載せます。
このノードはモデル保管先も兼ねるため、OS ディスクとは別に十分な保存領域を確保する設計が向いています。

• 役割は GPUStack Server + NFS
• private network に接続する
• UI 公開が必要な場合のみ public 側を検討する
• モデル格納先の容量は worker よりも AI-SRV 側を厚くする

GPU-VPS 側に worker を必要台数ぶん作成する #

worker は推論用なので、GPU 種別・VRAM・将来のモデルサイズを基準に GPU-VPS のプランを選びます。
一方、モデル本体は NFS 側に寄せるので、worker のストレージは OS と実行に必要な最低限へ絞りやすくなります。

• Ubuntu 24 系で統一する
• GPU driver / CUDA が使える前提で作成する
• private network へ接続する
• 必要なければ public IP を持たせない構成も検討する

10G プライベートネットワークに全ノードを乗せる #

NFS と GPUStack の内部通信は、Bestnet Cloud と GPU-VPS を結ぶ 10G private link 上で流します。
これにより、モデル読み出しや worker join を public 側へ出さずに済みます。

• AI-SRV と全 worker を同一 private segment に収容する
• 固定 IP を割り当て、後続の NFS export と systemd 設定を安定化する
• worker に外向き通信が必要なら、NAT ルーター方式か一時 public egress を選ぶ

worker を private-only に寄せたい場合は、Bestnet Cloud の仮想ルーター / NAT パターンを使って
OS 更新や外部取得だけを外へ出す設計が扱いやすいです。

ファイアウォールの初期ルールを決める #

ルールは「AI-SRV に必要な inbound を最小限だけ許可し、worker は SSH 以外の inbound をほぼ持たせない」方針で十分です。
ポータルのファイアウォール画面で、まず既存ルールを確認し、その後に必要ポートだけ追加します。

NFS v4 前提なら 2049/tcp に寄せやすい一方、環境によっては rpcbind を使うことがあります。公開範囲は必ず private subnet に限定します。

最初のスナップショットを取得する #

OS の初期作成、鍵投入、private network 接続、ファイアウォールの整備が終わったら、
いったん AI-SRV と GPU worker のスナップショットを取得しておくと、その後のミドルウェア導入で失敗しても戻しやすくなります。

GPUStack Server をインストールする #

初期構築例では、AI-SRV に GPUStack Server を導入し、管理 UI へログインできる状態を作ります。
初期管理者パスワードは控えたら安全な vault へ移し、記事には掲載しません。

curl -sfL https://get.gpustack.ai | sh -s -
cat /var/lib/gpustack/initial_admin_password

# Web UI（例）
# http://10.10.0.10/

NFS 共有ディレクトリを作る #

モデルファイルの実体は /srv/gpustack_models に置きます。
これを private subnet のみへ export し、AI-SRV 自身でも /models として bind mount します。
こうしておくと、サーバーから見えるパスと worker から見えるパスが統一されます。

sudo mkdir -p /srv/gpustack_models

echo "/srv/gpustack_models 10.10.0.0/24(rw,sync,no_subtree_check,no_root_squash)" |   sudo tee -a /etc/exports

sudo exportfs -ra

# Server 自身も bind mount
sudo mkdir -p /models
sudo mount --bind /srv/gpustack_models /models
echo "/srv/gpustack_models /models none bind 0 0" | sudo tee -a /etc/fstab

worker 参加トークンを発行する #

GPUStack の GUI から worker join token を作成します。公開記事では <WORKER_JOIN_TOKEN> として表記し、
実値は掲載しません。併せて、GUI へログインできる管理元も private network 側に寄せる運用だとより安全です。

まずは /models を NFS マウントする #

各 worker は、AI-SRV が export している共有領域を同じパス /models でマウントします。
この時点で全 worker の cache path が揃うため、モデルの重複保存を防げます。

sudo mkdir -p /models
echo "10.10.0.10:/srv/gpustack_models /models nfs defaults 0 0" | sudo tee -a /etc/fstab
sudo mount -a

マウント後は mount | grep /models で、意図した共有先が見えているか確認します。

GPUStack Worker をインストールする #

AI-SRV 側で発行した token を使い、各 GPU-VPS を worker としてクラスタへ参加させます。

curl -sfL https://get.gpustack.ai | sh -s -   --server-url http://10.10.0.10   --token <WORKER_JOIN_TOKEN>

worker サービスで --cache-dir /models を固定する #

共有 cache 構成では、この指定がもっとも重要です。GPUStack Worker の systemd 定義に
--cache-dir /models を入れ、併せて data-dir も固定しておきます。

[Service]
ExecStart=/root/.local/bin/gpustack start   --server-url http://10.10.0.10   --token <WORKER_JOIN_TOKEN>   --cache-dir /models   --data-dir /var/lib/gpustack-data

sudo systemctl daemon-reload
sudo systemctl enable --now gpustack

# Using cache dir: /models が出れば OK
journalctl -u gpustack -f

GPUStack GUI で worker が Ready になることを確認する #

GUI の Workers 画面で、全 GPU-VPS が Ready になることを確認します。
ここで Not Ready のままなら、GPU driver / CUDA、NFS マウント、worker ログの順に切り分けると早いです。