클라이언트 포털 자체의 방어를 정비한다 #

서버 생성보다 먼저 관리면의 방어 방침을 결정합니다. 특히 팀 운용에서는
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 로그 순으로 확인하면 빠릅니다.