오늘은 처음 Nutanix Files 를 구성할 때 가장 어렵고 헷갈렸던 백업 설정에 대해 알아보도록 하겠습니다.
처음 Nutanix Files를 세팅하다 보면 불안한 마음에 눈에 보이는 모든 가상머신(VM)을 로컬 Protection Domain(PD)에 때려 넣고 싶은 충동이 듭니다. 나도 주니어 시절 그랬으니까. 하지만 이 짓을 실행에 옮기는 순간 평화롭던 서버실에 사이렌이 울리고 너의 퇴근 시간은 무기한 연기된다는거. 공식 문서에는 그저 '하지 마라'고만 되어 있지만 현장에서 이 원칙을 무시했을 때 어떤 끔찍한 연쇄 작용이 일어나는지 하나씩 뜯어보자.
Prism Element에 로그인해서 VM 목록 인벤토리를 열어보면, 소중한 DB 서버, 웹 서버들 사이에 'NTNX-블라블라-CVM'이나 'NTNX-파일서버-FSVM' 같은 녀석들이 나란히 섞여 있는 게 보입니다. 관리자 입장에서는 겉모습이 똑같으니 전부 다 같은 가상머신처럼 보이기 마련이겠지만. 바로 여기서 가장 큰 착각이 시작됩니다. 일반 VM 백업하듯이 이 녀석들을 묶어서 스냅샷을 찍고 복제를 걸어버리면 내부 아키텍처의 동기화 메커니즘이 완전히 붕괴된다는 사실,, 후, 백업의 기본은 대상의 '성격'을 파악하는 것부터 시작한다는 점을 절대 잊지 마세요.
대참사의 시작: CVM을 백업 대상에 넣으면 생기는 일
클러스터의 심장인 CVM(Controller VM)을 로컬 PD에 포함시키는 건 자살 행위나 다름없습니다. CVM은 메타데이터를 관리하는 Medusa DB와 실제 I/O를 처리하는 Stargate 서비스가 미친 듯이 돌아가는 핵심 컨트롤러입니다. 이 녀석을 스냅샷 뜨고 나중에 복구한다고 덮어씌워 보세요. 기존 클러스터 노드들이 가지고 있는 최신 메타데이터와 복구된 CVM의 과거 메타데이터가 충돌하면서 스토리지 풀 전체가 멈춰버리게 됩니다. 듣기만 해도 무섭네요.
- 자체 보호 메커니즘 신뢰: Nutanix는 이미 RF2(Replication Factor 2)나 RF3 같은 자체 데이터 복제 기술로 CVM의 가용성을 보장하고 있다.
- 메타데이터의 무결성: 관리자가 임의로 CVM의 시간을 과거로 되돌리는 순간 클러스터의 데이터 블록 맵핑 정보가 꼬여버린다.
2026-04-16 11:45:02 INFO cluster: Stargate is down on node X.X.X.X
2026-04-16 11:45:03 ERROR cluster: Metadata ring mismatch detected. Split-brain condition.
2026-04-16 11:45:05 CRITICAL: I/O suspended across the cluster.
굳이 CVM을 보호하겠다고 나설 필요가 전혀 없습니다. 멋모르고 CVM 스냅샷을 복구했다가 저 에러 로그를 콘솔에서 보는 순간 등골에 식은땀이 흐르며, 복원된 과거의 메타데이터와 현재 살아있는 노드들의 메타데이터가 멱살을 잡고 싸우는 전형적인 Split-Brain 상태를 보게 될겁니다. 데이터 오염을 막기 위해 클러스터 스스로 모든 I/O를 차단해 버리는 최악의 방어 기제가 발동합니다. 벤더가 알아서 이중화, 삼중화로 튼튼하게 보호하고 있으니 제발 CVM은 투명 인간 취급하고 건드리지 마세요.
FSVM 백업의 역설: 껍데기는 가라, 알맹이(VG)만 챙겨라?
그렇다면 파일 서버 역할을 하는 FSVM(File Server VM)은 어떨까? FSVM 자체는 데이터를 전혀 들고 있지 않은 Stateless VM이다. 진짜 당신의 관리하는 소중한 사용자 데이터와 파일들은 볼륨 그룹(Volume Group, VG)에 고스란히 담겨 있다. 빈 껍데기인 FSVM만 로컬 PD로 열심히 백업해 봐야 장애 났을 때 아무짝에도 쓸모가 없다. 데이터와 껍데기의 시점이 어긋나면서 파일 서버 서비스가 아예 올라오지 않는 기염을 토하게 된다는 거.
현장 선배의 뼈때리는 실무 주의사항:
단순 로컬 백업이라면 FSVM 백업은 과감히 버려라. 하지만 원격지 재해복구(DR) 상황이라면 이야기가 완전히 달라진다. DR을 타야 한다면 반드시 FSVM과 VG를 '통째로' 하나의 PD로 묶어서 넘겨야 한다. 둘 중 하나라도 누락되거나 시점이 틀어지면 원격지에서 파일 서버 네트워크가 엉키고 AD(Active Directory) 조인이 풀려버리는 지옥을 맛보게 된다.
재해복구(DR) 전략: 돈(라이선스)과 복구 단위의 숨막히는 줄다리기
DR을 구성해야 하는 상황이 왔다면 당신에게는 두 가지 무기가 주어진다. 기본 라이선스로 가능한 PD 기반 DR과, 돈을 좀 써야 하는 Smart DR이다. 현장의 예산과 고객의 요구사항(RPO/RTO)에 맞춰 정확한 무기를 꺼내 들어야 한다.
 |
| Smart DR 페일오버 동작 구조 |
Protection Domain (PD) 기반 DR (Async Replication)
이 방식은 파일 서버 전체를 하나의 덩어리로 보고 Prism Element에서 묶어서
원격지로 던지는 무식하지만 확실한 방법이다. 비동기 복제 방식인 Async
Replication을 구성할 때는 RPO(목표 복구 시간)를 정확히 산정해야 한다. 단순히
상부의 지시대로 15분 단위로 촘촘하게 스냅샷 복제를 걸었다고 치자. 하루에
파일이 얼마나 변경되는지(Change Rate) 계산도 안 하고 네트워크
대역폭(Bandwidth) 제한도 안 걸어두면 곧바로 대형 사고가 터진다. 원격지로
넘어가지 못한 스냅샷 전송 큐가 꽉 막혀서 밀리기 시작하면 로컬 스토리지 풀의
여유 공간을 무섭게 갉아먹는다. 게다가 멈춘 큐를 뚫으려고 계속해서 재전송을
시도하느라 CVM CPU가 100%를 치며 널뛰는 현상을 새벽에 모니터링 알람으로 맞게
될 거다.
✔️
\\FileServer\Executive_Data (임원진 기밀 문서) →
RPO 1분 단위 촘촘한 복제✔️
\\FileServer\Public_Temp (단순 임시 공유 폴더) →
RPO 24시간 단위 여유로운 복제
Prism Central에서 정책을 내려주는 Smart DR은 파일 서버라는 '거대한 통'을 옮기는 게 아니라, 그 안의 개별 '공유 폴더(Share)' 단위로 핀셋 보호를 하는 녀석이다. 머릿속으로 위 박스의 상황을 상상해 보라. 굳이 무거운 전체 스냅샷을 뜰 필요 없이, 중요한 폴더와 안 중요한 폴더를 나누어 복제 주기를 다르게 가져갈 수 있다. 이렇게 설정하면 낭비되는 네트워크 트래픽을 기가 막히게 아낄 수 있는 거다.
Files Advanced 라이선스가 있어야 활성화되지만, 원클릭 Failover/Failback 기능을 제공한다. 야간에 장애가 터졌을 때 명령어 수십 줄을 치는 대신 버튼 한 번으로 특정 공유 폴더 서비스만 쏙 살려내고 엔지니어의 수면 시간을 보장해 주는 엄청난 효자 기능이라는 사실을 알아 두시길,
한눈에 보는 파일 서버 보호 전략 요약
| 구분 | 성격 (정체성) | 로컬 PD 백업 여부 | DR 시 권장 보호 방법 |
|---|---|---|---|
| CVM | 클러스터 메타데이터 컨트롤러 | 절대 금지 (장애 유발) | 불필요 (내부 메커니즘으로 자동 보호) |
| FSVM | Stateless 파일 서버 엔진 | 불필요 (빈 껍데기) | PD 기반 (FSVM+VG 통합) 또는 Smart DR |
초보 엔지니어 시절에는 무언가를 설정하지 않으면 불안해하는 강박이 있습니다. 뭘 더 하려고 하지 말고 시스템 아키텍처가 의도한 방향대로 놔두는 법을 배워 보세요. CVM과 FSVM의 본질을 이해했다면 오늘 당장 불필요하게 걸려 있는 로컬 스냅샷 정책부터 시원하게 날려버리세요. 스토리지 용량도 아끼고 클러스터의 안정성도 확보하는 가장 빠른 길입니다.
오늘 알려드린 내용을 바탕으로 효율적인 파일 서버 운영을 하기길 바랍니다.
0 댓글