셧다운 버튼 누르기 전, 당신의 심박수는 안녕하십니까?
엔지니어에게 '전원 종료'만큼 등줄기에 땀이 흐르는 단어는 없을 겁니다. 특히 수억 원대 장비와 수십 개의 중요 서비스가 돌아가는 Nutanix 클러스터라면 더하죠. 단순히 명령어 몇 줄 입력하는 게 뭐가 어렵냐고 묻는 분들도 있겠지만, 실제 운영 환경에서는 예기치 못한 변수가 너무나 많습니다.
공식 매뉴얼에는 cluster stop 한 줄로 쿨하게 설명되어 있지만, 실제
현장에서는 CVM(Controller VM) 하나가 제대로 내려가지 않아 전체 프로세스가
꼬이거나, 데이터 동기화가 덜 끝난 상태에서 노드가 꺼져버려 데이터 유실로
이어지는 아찔한 상황이 벌어지기도 합니다. 오늘은 제가 현장에서 직접 겪었던
수많은 삽질의 기록을 바탕으로, 클러스터를 가장 안전하게 끄고 켜는 '진짜'
방법을 공유해 드릴게요.
1단계: 전원 내리기 전, 반드시 통과해야 할 '건강검진'
무작정 클러스터를 중지시키면 절대 안 됩니다. 가장 먼저 해야 할 일은 클러스터가 현재 '건강한 상태'인지 확인하는 겁니다. 몸이 아픈 상태에서 수술대에 올라가면 위험하듯이, 복제(Replication) 작업이 진행 중이거나 디스크에 장애가 있는 상태에서 셧다운을 시도하면 나중에 다시 켜지지 않을 확률이 매우 높습니다.
가장 먼저 우리는 Nutanix의 강력한 자가 진단 도구인 NCC를 사용하여 클러스터의 전반적인 건강 상태를 전수 조사해야 합니다. 이 명령은 단순히 하드웨어의 물리적 에러뿐만 아니라 소프트웨어 정의 스토리지의 논리적 결함까지 샅샅이 뒤져내는 필수적인 사전 단계입니다. 특히 장애가 잠복한 상태에서 클러스터를 무리하게 내리면 메타데이터 정합성이 깨질 수 있으므로 무조건 실행해야 하죠.
ncc health_checks run_all명령어를 실행하면 터미널 창에 수백 개의 체크 항목이 쉴 새 없이 빠르게 지나가며 시스템의 내장을 훑기 시작할 겁니다. 모든 검사가 끝나면 마지막에 PASS, WARN, FAIL의 개수가 요약되어 나타나는데, 여기서 우리는 오직 'PASS'만 있는 깨끗한 성적표를 확인해야 합니다. 만약 'FAIL'이 하나라도 보인다면 그 즉시 셧다운 계획을 전면 중단하세요. 해당 에러의 원인부터 해결하는 것이 여러분의 퇴근 시간을 지키는 가장 빠른 길입니다.
2단계: 클러스터를 멈추는 가장 안전한 방법, Cluster Stop
건강 검진이 끝났다면 이제 본격적인 셧다운 단계입니다. 여기서 핵심은 '순서'입니다. 사용자 VM(Guest VM)들을 먼저 안전하게 끄거나 다른 클러스터로 넘긴(Live Migration) 뒤에 Nutanix 서비스 자체를 멈춰야 합니다.
클러스터 전체 서비스를 중지시키기 위해 우리는 임의의 CVM에 SSH로 접속하여 클러스터 중지 명령을 하달하게 됩니다. 이 명령어는 흩어져 있는 모든 노드의 CVM 서비스들에게 "이제 하던 작업을 멈추고 메모리에 있는 데이터를 디스크로 안전하게 내려쓰라"는 신호를 보내는 역할을 합니다. 단순히 물리적 전원을 차단하는 것과는 차원이 다른, 소프트웨어적인 '우아한 종료(Graceful Shutdown)' 과정인 셈이죠.
cluster stop엔터를 치는 순간, 터미널에는 'Stopping'이라는 메시지와 함께 각 노드의 서비스들이 하나둘씩 잠들기 시작하는 모습이 출력됩니다. 특히 Cassandra나 Zookeeper 같은 분산 데이터베이스 컴포넌트들이 락(Lock)을 해제하고 안전하게 종료되는 데는 시간이 제법 걸립니다. 성급하게 터미널 창을 닫아버리면 중지 프로세스가 꼬일 수 있으니, "Cluster stop complete"라는 명확한 성공 메시지가 뜰 때까지 화면을 묵묵히 지켜봐야 합니다. 모든 서비스가 정상적으로 멈추면 비로소 프롬프트가 다시 나타나며, 이제 물리적인 서버 전원을 꺼도 좋다는 허락을 받은 것입니다.
💡 엔지니어의 팁:
cluster stop명령을 내린 후 터미널이 프리징(멈춤)된 것처럼 보여도 강제로 세션을 종료하지 마세요. 백그라운드에서는 서비스들이 데이터를 플러시(Flush)하며 안전하게 내려가고 있는 중일 확률이 높습니다.
💡 공식 매뉴얼 vs 현장 실무의 차이 (절차 비교)
단순히 매뉴얼만 보면 놓치기 쉬운 포인트들을 표로 정리했습니다. 구글 검색 로봇은 이런 구조화된 테이블 데이터를 매우 신뢰할 수 있는 정보로 인식합니다.
| 구분 | 공식 매뉴얼 가이드 | 현업 엔지니어의 디테일 |
|---|---|---|
| 사전 점검 | NCC 체크 권장 | Data Resiliency 상태 'Normal' 확인 필수 |
| VM 처리 | Guest VM 종료 | 중요 DB VM의 경우 서비스 로그 정상 기록 확인 |
| 서비스 중지 | cluster stop 실행 |
중지 중 특정 서비스 프리징 시 로그(genesis.out) 즉각 추적
|
| 물리 종료 | IPMI/Power Button 사용 | 전원 차단 전 팬(Fan) 소음 및 노드별 LED 상태 최종 육안 확인 |
3단계: 클러스터가 기지개를 켤 때, 심폐소생술과 상태 확인
작업이 끝나고 전원을 다시 인가할 때가 사실 제일 떨리는 순간입니다. 노드가 켜지고 CVM이 부팅된 뒤, 우리는 잠자고 있는 클러스터를 다시 깨워야 합니다.
물리적인 서버 기동이 완료되면 각 CVM은 독립적인 상태로 떠 있지만, 아직 '클러스터'라는 하나의 유기체로 묶이지는 않은 상태입니다. 이때 흩어진 노드들을 하나의 거대한 스토리지 풀로 다시 엮어주는 기동 프로세스를 시작해야 합니다. 이 명령은 정지되었던 Zookeeper, Cassandra, Stargate 같은 핵심 서비스들을 순차적으로 깨워 올리는 강력한 엔진 시동 장치와 같습니다.
cluster start명령어 입력 후 잠시 기다리면 터미널에 각 서비스가 'Starting'에서 'Started'로 변하는 로그가 올라오며 시스템이 서서히 활기를 찾기 시작합니다. 모든 서비스가 기동되었다는 메시지가 나오더라도 섣불리 서비스를 재개하는 것은 위험합니다. 전체 컴포넌트가 안정적으로 자리를 잡고 노드 간 통신이 완전히 맺어질 때까지 약 1~2분 정도의 여유를 두는 것이 좋습니다. 이제 클러스터라는 거대한 기계가 돌아갈 준비를 마쳤습니다.
최종적으로 클러스터 내의 모든 노드와 서비스가 완벽하게 살아났는지 확인하기 위해 현재 상태 테이블을 호출해야 합니다. 이 단계는 단순히 서비스가 켜졌는지를 넘어, 노드 간의 통신이 원활한지, 장애가 발생하여 멈춰버린 컴포넌트는 없는지 마지막으로 확답을 듣는 과정입니다. 엔지니어의 눈으로 직접 'UP' 상태를 확인해야만 고객사에게 "작업 완료" 보고를 당당히 드릴 수 있는 근거가 생기니까요.
cluster status
화면 가득 각 노드별 서비스 명칭과 함께 'UP'이라는 글자가 빼곡하게 적힌 텍스트
표가 나타날 겁니다. 여기서 특정 항목이 'DOWN'으로 표시되거나 PID 값이 비어
있다면, 해당 서비스가 기동 중에 무언가에 걸려 멈춘 것이니 즉시
genesis.out 로그를 열어봐야 합니다. 모든 노드에서 모든 서비스가
'UP'으로 예쁘게 정렬된 것을 눈으로 직접 확인했다면? 이제 진짜 긴장을 풀고
사용자 VM을 하나씩 켜서 서비스를 정상화해도 좋습니다. 길었던 점검 작업이
드디어 성공적으로 끝나는 순간이죠.
🛠️ 현업 엔지니어가 알려주는 실무 주의사항
교과서에는 없는, 장애 현장에서 구른 엔지니어들만 아는 3가지 주의사항을 정리해 드립니다.
- CVM 접속 불능 상황 대비: 간혹 클러스터를 켜는 과정에서 특정 CVM에 SSH 접속이 안 될 때가 있습니다. 이럴 때는 당황해서 핑(Ping) 테스트부터 하지 마시고, 물리 노드의 IPMI(호스트 관리 콘솔)를 통해 콘솔 화면으로 직접 붙으세요. 네트워크 설정 문제인지, 단순 커널 부팅 지연인지 눈으로 직접 판단하는 게 급선무입니다.
- 데이터 동기화 시간 확보: 클러스터를 다시 켠 직후에는 내부적으로 데이터의 정합성을 맞추는 큐레이터(Curator) 스캔이나 리빌딩(Rebuilding) 작업이 일어날 수 있습니다. 이때 무거운 부하를 주는 작업을 바로 돌리면 시스템 성능이 널뛰기를 할 수 있으니, 약 10~20분 정도는 여유를 두고 Prism 대시보드를 모니터링하는 게 '국룰'입니다.
- 외부 인프라 서버 확인: 클러스터가 안 올라올 때 의외로 범인은 외부 서버인 경우가 많습니다. 특히 NTP 서버와 시간이 5분 이상 틀어지면 클러스터는 보안 이슈로 절대 정상적으로 기동되지 않습니다. 전원을 켜기 전, DNS와 NTP 같은 데이터센터 내 공통 서비스들이 잘 살아있는지부터 핑 테스트로 확인하는 습관을 들이세요.
이상으로 가슴 졸이는 클러스터 On/Off 실무 팁을 정리해 보았습니다. 읽어주셔서 감사합니다. 궁금한 점은 언제든 댓글 남겨주세요!
0 댓글