가상 랩 PC 메모리 32GB — VM 몇 대까지 버티는지 직접 재봤다

가상 랩 PC 메모리는 몇 GB면 충분할까요. 저는 32GB로 시작했고, 이 글을 쓰는 날 그 한계를 정확히 알게 됐습니다 — VM 안의 노드가 실제로 죽어서요. CPU도 디스크도 아니었습니다. 벽은 메모리 하나였습니다.

이 글은 사양표 나열이 아니라 같은 PC에서 같은 날 측정한 숫자입니다. VM을 몇 대까지 돌릴 수 있는지, 한계를 넘으면 어떤 식으로 무너지는지, 그리고 그때 에러가 왜 엉뚱한 곳을 가리키는지를 담았습니다.

가상 랩 PC 메모리 32GB의 실제 예산 — 호스트가 약 6GB를 쓰고 안전 여유 4GB를 남기면 VM 예산은 약 22GB이며, VM 할당 20GB에 여유가 3.5GB로 떨어진 순간 노드 하나가 죽었다는 실측 결과
32GB라고 32GB를 쓸 수 있는 게 아니다. 호스트 몫과 안전 여유를 빼면 VM 예산은 22GB 안팎이고, 그 선을 넘은 날 노드가 죽었다.

측정 환경

항목
CPUAMD Ryzen 5 5600 (6코어 12스레드)
메모리32GB (OS 인식 31.9GB)
OS / 하이퍼바이저Windows 11 Pro + VMware Workstation Pro
VM 구성ONTAP Simulator 노드 각 6GB · Ubuntu Server 2GB · Windows Server 2025 4GB

랩 구성 과정은 OVA 임포트 글2노드 클러스터 글에 있습니다. 이 글은 그 랩을 돌리는 PC 쪽 이야기입니다.

1. 구동 조합별 실측 — 여유 메모리가 말해주는 것

VM 조합을 바꿔가며 호스트의 여유 메모리를 쟀습니다. 전부 같은 날, 같은 PC입니다.

구동 조합VM 할당 합계실측 여유판정
ONTAP 2노드 + Ubuntu14GB8.7GB안정
ONTAP 2노드 + Ubuntu + Windows Server18GB4.0GB실질 상한선
ONTAP 3노드 + Ubuntu20GB3.5GB노드 사망

할당 합계가 18GB → 20GB로 2GB 늘었을 뿐인데 이런사고가 발생햇습니다.

한 가지 흥미로운 실측도 있었습니다. 같은 18GB 할당인데 Windows Server를 재부팅한 직후에는 여유가 7.2GB로 나왔습니다. VM은 할당량을 예약만 해두고 게스트가 실제로 만진 만큼만 물리 메모리를 차지하기 때문입니다. 그래서 “지금 여유가 있으니 한 대 더” 는 함정입니다 — 게스트들이 메모리를 채워가면서 여유는 뒤늦게 사라집니다.

2. ⭐ 한계를 넘으면 — 호스트가 아니라 게스트가 죽는다

여유 3.5GB 상태에서 벌어진 일입니다. 호스트 Windows는 멀쩡했습니다. 파란 화면도, 경고 팝업도 없었습니다. 대신 ONTAP 클러스터 노드 하나가 조용히 응답을 멈췄습니다.

cluster1::> cluster show

Node                  Health  Eligibility
--------------------- ------- ------------
cluster1-01           true    true
cluster1-02           false   true          <-- 죽었다

cluster1::> network port show -node cluster1-02 -port e0d

Error: show failed: Timeout: Operation "vifmgr_netports_iterator::get_imp()"
       took longer than 25 seconds to complete [from mgwd on node "cluster1-01"
       (VSID: -1) to vifmgr at 169.254.245.203]

이 출력만 보면 ONTAP 장애로 보입니다. 노드 상태를 뒤지고, 네트워크를 의심하고, 로그를 파게 됩니다. 그런데 진짜 원인은 호스트 PC의 메모리 부족이었습니다. 하이퍼바이저가 부족한 메모리를 디스크로 스와핑하기 시작하면, 게스트 안에서 시간에 민감한 프로세스들이 타임아웃으로 먼저 쓰러집니다. 증상이 나타나는 곳(게스트)과 원인이 있는 곳(호스트)이 다른 위치에 있습니다.

이 상태는 켜져 있던 다른 작업에도 번졌습니다 — 그 노드가 원본인 SnapMirror 전송이 진행량 그대로 멈췄고, NFS 클라이언트 접근도 걸렸습니다. 랩 전체가 이상해 보이는데 만진 건 아무것도 없는 상황 — 이때 호스트 메모리를 의심해야 합니다.

3. 왜 CPU와 디스크는 문제가 없었나

6코어 12스레드에 VM들의 vCPU 합계는 10개였습니다. 오버커밋이지만 한 번도 걸림돌이 되지 않았습니다 — 랩 VM들은 대부분의 시간을 놀고 있기 때문입니다. 디스크도 씬 프로비저닝이라 실사용량만 차지했습니다.

메모리만 다릅니다. CPU는 나눠 쓸 수 있지만 메모리는 자리를 차지합니다. 게스트가 잡은 페이지는 게스트가 놓기 전까지 그 자리에 있어야 하고, 부족해지면 하이퍼바이저는 스와핑밖에 할 게 없습니다. 가상 랩용 PC를 고를 때 CPU 코어 수보다 메모리 용량이 먼저인 이유입니다.

4. 가상 랩 PC 메모리 계산법

이번 실측으로 얻은 계산식은 단순합니다.

VM 예산  =  물리 메모리  −  호스트 몫(~6GB)  −  안전 여유(4GB)

32GB 기준:  32 − 6 − 4  =  VM 합계 22GB 안팎이 실전 한계
물리 메모리VM 예산이 랩 기준으로 가능한 것
16GB~6GBONTAP 싱글 노드 하나가 빠듯하다
32GB~22GBONTAP 2노드 + 클라이언트 2대 (18GB) — 딱 맞음
64GB~54GB클러스터 2개(DR 구성) + 클라이언트까지 여유

호스트 몫 6GB는 Windows 11 + VMware 기준 실측치입니다. 안전 여유 4GB는 이번에 4.0GB에서는 버티고 3.5GB에서는 죽은 경험에서 나온 값입니다 — 그 사이 어딘가가 절벽이었고, 저는 여유가 4GB 아래로 내려가면 VM을 늘리지 않기로 했습니다.

5. 32GB가 모자라면 — 증설 말고 다른 답도 있다

이날 세 번째 ONTAP 노드가 필요했던 이유는 클러스터 간 복제 실습 때문이었습니다. 선택지는 둘이었습니다.

선택지비용판단
64GB로 증설메모리 2개 교체 비용상시로 VM 5대 이상 돌릴 게 아니면 과함
시간 분할 — 안 쓰는 VM을 내리고 켠다0원이걸 택했다. Windows Server를 내려 6GB를 비우고 세 번째 노드를 올림

게다가 지금은 증설 타이밍도 나쁩니다. AI 데이터센터가 D램 생산 능력을 빨아들이면서 램 가격이 급등해 높은 가격대에 굳어 있는 시기라서요 — 왜 이런 상황이 됐는지는 램 가격 글에 따로 정리했습니다

다만 시간 분할에는 규율이 필요합니다. 이번 사고도 “내린 만큼 비었겠지” 하고 여유를 다시 확인하지 않고 올렸다가 났습니다. VM을 켜기 전에 여유 메모리를 확인하는 것 — 한 줄이면 됩니다.

PS> "{0:N1}GB" -f ((Get-CimInstance Win32_OperatingSystem).FreePhysicalMemory/1MB)
4.0GB    # 4GB 아래면 VM을 더 올리지 않는다

정리 — 가상 랩 PC 메모리 체크리스트

상황기준
PC를 고를 때CPU 코어보다 메모리 먼저. 이 랩 기준 32GB가 실전 최소
VM을 올리기 전여유 메모리 확인 — 4GB 아래면 올리지 않는다
“지금 여유 있는데?” 싶을 때게스트가 아직 안 만진 것뿐이다. 할당 합계 기준으로 판단
VM들이 갑자기 이상할 때게스트 로그보다 호스트 여유 메모리부터 본다
가끔만 필요한 VM증설보다 시간 분할 — 내리고 켜는 것으로 충분하다

이 랩에서 실제로 도는 것들이 궁금하시면 — ONTAP Simulator 설치부터 시작하는 스토리지 시리즈가 있습니다. 그리고 이날 죽었던 노드 때문에 멈췄던 복제 이야기는 SnapMirror 글에 있습니다.

댓글 남기기