어느 날 갑자기 들려온 "용량 부족" 알람, 무엇이 문제였을까?
평온하던 오후, 고객사 인프라 담당자에게서 목소리에 물기가 섞인 전화 한 통이 걸려왔습니다. Nutanix Prism 대시보드에 'Storage Capacity critical' 알람이 빨갛게 들어왔는데, 정작 가상 머신(VM) 내부에서는 공간이 넉넉하다는 겁니다. HPE ProLiant DL380 서버 기반으로 탄탄하게 구축된 환경이라 하드웨어 물리 장애는 아닐 텐데, 원인을 알 수 없으니 현장은 그야말로 아수라장이었습니다.
처음에는 저도 가벼운 마음으로 주변 시니어 엔지니어들에게 물어봤어요. 다들 "스냅샷 지워봐라", "휴지통 비웠냐" 같은 뻔한 이야기만 하더군요. 하지만 시키는 대로 다 해보고 수동으로 스냅샷을 싹 정리해도 용량은 줄어들 기미가 보이지 않았습니다. 시간은 계속 흐르고 고객의 재촉은 심해지는데 해결책은 안 보이고... 정말 엔지니어로서 자존심도 상하고 등에 식은땀이 흐르는 당혹스러운 순간이었습니다. 동료들의 조언이 무색하게 대시보드의 빨간불은 꺼질 줄 몰랐죠.
우리가 놓치고 있었던 Nutanix 스토리지의 진실
Nutanix AHV 환경, 특히 HPE 서버 위에서 구동될 때는 우리가 일반적인 윈도우나 리눅스 서버를 보듯 용량을 판단하면 안 됩니다. 이번에 문제가 된 KB21177은 단순한 수치 오류가 아니라, 메타데이터와 시스템 예약 영역의 불일치에서 오는 괴리를 다루고 있었습니다.
우선 우리가 흔히 범하는 실수와 실제 데이터가 쌓이는 원인을 비교해 보겠습니다.
| 구분 | 흔히 하는 착각 (As-Is) | 실제 작동 원리 (To-Be) |
|---|---|---|
| 용량 확인 주체 | Guest OS (Windows/Linux)의 df -h |
Nutanix 컨테이너 및 스토리지 풀 레벨 |
| 삭제 데이터 처리 | 파일 삭제 즉시 가용 용량 확보 | 가비지 컬렉션(GC) 및 큐레이터 작업 대기 |
| HPE 하드웨어 영향 | 디스크 장애 시 바로 용량 감소 | 리빌딩 과정에서의 임시 복제본 생성으로 용량 일시 급증 |
| 스냅샷 관리 | 눈에 보이는 스냅샷 리스트가 전부임 | 보존 정책(Retention Policy)에 따른 숨겨진 메타데이터 존재 |
| 예약 공간(Reservation) | 할당된 만큼만 용량을 차지함 | 설정된 Reservation 값이 실제 사용량보다 우선함 |
위 표를 보면 알 수 있듯이, 우리는 Guest OS 레벨에서의 용량만 보고 "이상하다"라고 외치고 있었던 겁니다. 실제로는 Nutanix의 CVM(Controller VM)이 관리하는 분산 파일 시스템(ADSF) 내부에서 정리가 안 된 데이터들과 시스템 예약분이 발목을 잡고 있었던 것이죠.
 |
| Nutanix CVM 및 ADSF 분산 스토리지 논리 구조도 |
해결을 위한 첫걸음: CVM 내부의 실제 데이터 파악하기
단순히 프리즘 대시보드 수치만 믿지 말고, 직접 CVM에 접속해서 어떤 녀석이 용량을 잡아먹고 있는지 범인을 찾아야 합니다. 가장 먼저 확인해야 할 것은 현재 클러스터의 논리적/물리적 사용량의 차이입니다.
아래 명령어를 통해 클러스터 전체의 스토리지 상태를 한눈에 파악할 수 있습니다.
ncli cluster get-storage-stats
이 명령어는 현재 Nutanix 클러스터가 인식하고 있는 전체 물리적 공간과 실제 사용자가 점유한 논리적 공간, 그리고 가용 가능한 여유 공간을 리스트 형태로 출력합니다. 실행 결과에서 'Storage Usage' 항목이 'Free Capacity'보다 현저히 낮음에도 불구하고 크리티컬 알람이 떠 있다면, 이는 메타데이터나 리빌딩 과정에서 발생한 찌꺼기 데이터가 원인일 확률이 매우 높습니다. 특히 HPE 서버의 로컬 디스크들이 인식하는 원천 데이터(Raw Data)의 총량을 여기서 한눈에 검증할 수 있습니다.
그다음으로는 특정 컨테이너가 과도하게 예약된 공간(Reservation)을 잡고 있지는 않은지 확인해야 합니다.
ncli container ls
이 명령어는 현재 생성된 모든 스토리지 컨테이너의 설정 정보를 상세히 불러오는 역할을 수행합니다. 여기서 'Explicit Reservation' 항목을 유심히 봐야 하는데, 만약 특정 컨테이너에 실제 데이터 사용량보다 훨씬 큰 값이 할당되어 있다면 이를 수정하는 것만으로도 대시보드상의 용량 부족 알람을 즉시 해결할 수 있습니다. 예를 들어 실제 데이터는 1TB인데 예약이 5TB로 잡혀 있다면, 대시보드는 이미 5TB를 쓴 것으로 간주해버리기 때문입니다.
해결되지 않는 용량, 'Stale Data'를 강제로 정리하자
만약 설정값에 문제가 없는데도 용량이 부족하다면, Nutanix의 청소부인 'Curator'와 'Stale Data'를 의심해봐야 합니다. 원래는 자동으로 지워져야 할 데이터들이 특정 이유로 시스템 구석에 남아있는 경우죠. 이를 확인하기 위해 vDisk 정보를 조회해 봅니다.
vdisk_config_printer | grep -i "vdisk_id" | wc -l
이 과정은 현재 시스템에 등록된 모든 가상 디스크의 개수를 정확히 세는 작업입니다. 만약 운영 중인 VM 개수보다 가상 디스크 수가 터무니없이 많다면, 이는 과거에 삭제했던 VM의 찌꺼기(Orphaned vDisks)가 여전히 스토리지를 점유하고 있다는 강력한 증거가 됩니다. 보통은 삭제 명령을 내리면 메타데이터도 함께 날아가야 하지만, 가끔씩 링크가 끊어진 채로 용량만 차지하는 유령 데이터들이 발생하곤 합니다.
실행 후 숫자가 수천 개 단위로 나온다면, 이는 시스템이 스스로 청소하지 못한 상태이므로 Nutanix 서포트 팀의 가이드에 따라 가비지 컬렉션을 수동으로 트리거 하거나 스케줄을 조정해야 합니다. 억지로 데이터를 지우려 하기보다 이런 '유령 디스크'들이 어디에 연결되어 있는지 파악하는 것이 급선무입니다.
💡 현업 엔지니어가 알려주는 실무 주의사항
HPE Nutanix 환경을 운영하다 보면 가장 당황스러운 게 'Physical Disk'의 정비 타이밍입니다. 현장에서 겪어보지 않으면 절대 모르는 포인트 3가지를 짚어드릴게요.
- 디스크 교체 전후 용량 변화: HPE 서버의 디스크 하나가 장애가 나서 교체할 때, 리빌딩(Rebuilding) 과정에서 일시적으로 용량 사용률이 10~15% 정도 급증할 수 있습니다. Nutanix는 가용성을 위해 복제본을 다시 만드는데, 이때 이미 용량이 80% 이상 차 있는 상태라면 클러스터 전체가 Read-only 모드로 전환되는 대참사가 발생할 수 있으니 주의하세요.
- Prism vs CVM의 시간차: 프리즘 대시보드는 실시간 반영이 아닙니다. CVM에서 명령어로 데이터를 삭제했거나 예약을 해제했더라도 대시보드 수치에 반영되기까지는 짧게는 수 분, 길게는 수십 분까지 걸립니다. "지웠는데 왜 안 줄어들지?"라며 당황해서 이것저것 다른 설정을 건드리다가 오히려 설정을 꼬이게 만드는 실수를 절대 하지 마세요.
-
Log 파일의 배신: 가끔 데이터 스토리지 문제가 아니라 CVM
자체의 루트 파티션 로그 파일(
/home/nutanix/data/logs)이 비대해져서 용량 부족 알람을 일으키기도 합니다. 스토리지 풀 용량이 넉넉한데도 특정 노드에서만 계속 알람이 온다면, 전체 클러스터 용량이 아니라 해당 노드의 로그 디렉터리를 반드시 체크해 보십시오.
주변 동료들도 몰랐던 이 비밀은 결국 꼼꼼한 명령어 확인과 Nutanix 고유의 분산 구조(ADSF)를 이해하는 데서 풀렸습니다. 삽질은 고통스럽지만, 그 과정에서 얻은 이 데이터들은 여러분의 강력한 자산이 될 거예요. 저도 그날의 식은땀 덕분에 이제는 용량 알람 앞에서도 차분하게 CVM부터 접속하는 여유가 생겼답니다.
항상 모든 엔지니어분들에게 도움이 되는 글이 되었으면 합니다. 좋은 하루 보내세요. ^^
0 댓글