ONTAP 노드가 강제로 꺼졌다 켜지면, 부팅 콘솔에 RDB 복구 관련 메시지가 지나갑니다. 처음 보면 심장이 내려앉습니다 — “클러스터 설정 데이터베이스가 깨졌나?” 실제로 제 랩에서 노드 하나가 리소스 부족으로 죽었다 살아났고, 그 복구 과정에서 “깨진 것”과 “복구 중인 것”을 어떻게 구분하는지를 실측으로 정리했습니다.
부팅 때 보이는 RDB 복구 메시지는 비정상 종료 후의 정상 절차입니다. 깨졌는지 아닌지는 메시지가 아니라
cluster ring show한 줄이 판정합니다 — 이 글은 그 출력을 읽는 법입니다.
1. 상황 — 노드가 죽었다 살아났다
제 2노드 랩 클러스터에서 cluster1-02 가 호스트 메모리 부족으로 응답 불능이 됐습니다 (그 사고 자체는 가상 랩 메모리 실측 글에 있습니다 — 증상은 게스트에, 원인은 호스트에 있었습니다). 재부팅으로 살아났는데, 문제는 그다음입니다. 비정상 종료를 겪은 노드의 클러스터 설정 DB는 믿어도 되는가?
이때 확인 순서는 두 단계입니다 — 먼저 노드가 클러스터에 복귀했는지, 그다음 RDB가 동기화됐는지.
cluster1::> cluster show
Node Health Eligibility
--------------------- ------- ------------
cluster1-01 true true
cluster1-02 true true <-- 죽었던 노드가 true로 복귀
2 entries were displayed.Health: true 는 “노드가 살아서 클러스터와 통신한다”까지만 말해줍니다. 설정 DB가 온전한지는 별도 확인이 필요합니다.
2. RDB가 뭐길래 — 클러스터의 설정 원장
RDB(Replicated Database)는 클러스터 설정을 담는 복제 데이터베이스입니다. 볼륨 위치, 네트워크 구성 같은 관리 정보가 여기 살고, 모든 노드가 사본을 복제해 갖습니다. 하나의 DB가 아니라 역할별로 나뉜 여러 개의 “링(ring)”으로 굴러갑니다. [문서확인]
| 링 | 담는 것 |
|---|---|
mgmt | 관리 게이트웨이 — 클러스터 관리 설정 |
vldb | 볼륨 위치 DB — 어떤 볼륨이 어느 애그리게이트에 있나 |
vifmgr | LIF(논리 인터페이스) 구성과 페일오버 |
bcomd | SAN(블록) 관련 구성 |
crs | 구성 복제 서비스 |
각 링에는 master 노드 1개가 있고 나머지는 secondary로 복제를 받습니다. 노드가 갑자기 죽으면 그 노드의 사본만 뒤처지는 것이고, 재부팅하면 살아 있는 master에게서 밀린 트랜잭션을 받아 따라잡은 뒤 정족수(quorum)에 합류합니다 — 부팅 때 본 “복구” 메시지가 바로 이 절차입니다.
3. ⭐ 판정 — cluster ring show 읽는 법
advanced 권한의 cluster ring show 가 링 상태를 그대로 보여줍니다. 복구 직후 제 클러스터의 실제 출력입니다.
cluster1::> set -privilege advanced
cluster1::*> cluster ring show
Node UnitName Epoch DB Epoch DB Trnxs Master Online
--------- -------- -------- -------- -------- --------- ---------
cluster1-01 mgmt 3 3 9630 cluster1-01 master
cluster1-01 vldb 3 3 406 cluster1-01 master
cluster1-01 vifmgr 3 3 91 cluster1-01 master
cluster1-01 bcomd 3 3 616 cluster1-01 master
cluster1-01 crs 3 3 9 cluster1-01 master
cluster1-02 mgmt 3 3 9630 cluster1-01 secondary
cluster1-02 vldb 3 3 406 cluster1-01 secondary
cluster1-02 vifmgr 3 3 91 cluster1-01 secondary
cluster1-02 bcomd 3 3 616 cluster1-01 secondary
cluster1-02 crs 3 3 9 cluster1-01 secondary
10 entries were displayed.볼 곳은 세 군데입니다.
| 확인 항목 | 정상 기준 | 위 출력에서 |
|---|---|---|
| Epoch = DB Epoch | 같은 링에서 두 값이 같아야 한다 | 전 링 3 = 3 ✅ |
| DB Trnxs가 노드 간 동일 | 같은 링이면 모든 노드가 같은 트랜잭션 번호 | mgmt 9630=9630 등 전부 일치 ✅ |
| Online 열 | master 1개 + 나머지 secondary, 전부 온라인 | n1 master / n2 secondary ✅ |
이 세 가지가 맞으면 RDB는 깨지지 않았습니다. 죽었던 노드의 사본이 master를 완전히 따라잡아 동기화됐다는 뜻입니다. 부팅 때의 복구 메시지는 이 상태로 오기 위한 과정이었을 뿐입니다.
4. 마무리 확인 — DB 밖의 것들
RDB가 정상이어도 서비스까지 확인해야 복구 완료입니다. 제 경우 세 가지를 봤습니다.
# 1) 죽은 노드에 있던 LIF들이 복귀했나
cluster1::> network interface show -fields curr-node,is-home,status-oper
→ 페일오버 갔던 데이터 LIF가 자기 홈 노드로 자동 복귀 (is-home true)
# 2) 이벤트 로그에 새 rdb 에러가 없나
cluster1::> event log show -event *rdb*
cluster1-02 8/27/2026 15:57:29 ERROR rdb.node.starvation: CPU starvation detected in the RDB.
→ 사고 시점의 기록 1건뿐, 재부팅 이후 신규 에러 없음
# 3) 클라이언트 실접근 (NFS 마운트에서 파일 읽기) → 정상2번의 rdb.node.starvation 이 사고 원인을 정확히 말해줍니다 — RDB 프로세스가 CPU를 못 받아 굶었다(starvation)는 것. 호스트 리소스 부족이 게스트 안에서는 이렇게 기록됩니다.
5. 그럼 언제가 진짜 문제인가
| 증상 | 의미 |
|---|---|
| 재부팅 후에도 특정 링이 offline 지속 | 해당 링이 정족수에 못 들어오고 있다 |
| Epoch ≠ DB Epoch 가 시간이 지나도 그대로 | 복제 합류가 안 끝나고 있다 |
| DB Trnxs가 노드 간 계속 다름 | 동기화가 진행되지 않는다 |
Eligibility: false | 노드가 정족수 참여 자격 자체를 잃은 상태 |
이런 상태가 지속되면 그때가 진짜 장애입니다 — 그리고 여기서부터는 임의로 조치하지 말고 지원(운영 장비라면 NetApp 지원)을 통해 진행하는 것이 맞습니다. RDB를 수동으로 건드리는 명령들은 diag 권한 영역이고, 잘못 쓰면 복구 가능한 상태를 복구 불가능하게 만듭니다. 판정까지가 관리자 몫, 수술은 지원 몫입니다.
정리
| 하나만 기억한다면 |
|---|
강제 종료 후의 RDB 복구 메시지는 정상 절차다. 판정은 cluster ring show 로 — Epoch=DB Epoch, 노드 간 DB Trnxs 일치, master/secondary 전원 온라인이면 깨진 게 아니다. 이 세 가지가 계속 어긋나 있을 때만 장애이고, 그때는 지원과 함께 간다. |
이 랩의 클러스터 구성은 2노드 클러스터 구축 글에, 노드 다운이 SnapMirror 전송에 미친 영향은 SnapMirror 글에 있습니다.
참고 문서 — ONTAP CLI — cluster ring show · ONTAP CLI — cluster show
모든 출력은 ONTAP Simulator 9.17.1 가상 랩에서 직접 실행한 결과입니다. 실제 장비의 장애 상황에서는 반드시 지원 절차를 따르시기 바랍니다.
