Ozone Manager(OM) HA 구성에서 팔로워 OM 로그에 다음이 반복된다.
Failed APPEND_ENTRIES request om...555->om...551#66-t52, previous=(t:51, i:1137161), leaderCommit=1137172
java.lang.IllegalStateException: gap between start index 1074744 and first entry to append 1137162
팔로워의 Raft 로그는 인덱스 1074744 까지만 있는데 리더가 1137162 부터 보내고 있다. 약 6만 개 엔트리만큼 로그에 구멍이 생긴 상태이고, Raft 로그는 연속이어야 하므로 appendEntries 가 거부된다. 리소스(메모리 · CPU) 를 늘려도 이 gap 자체는 해소되지 않는다. 리소스 부족은 OM 이 자주 죽어 뒤처지게 만든 간접 원인일 수는 있어도, 지금 보이는 오류는 그 결과인 로그 불일치다.
팔로워가 한동안 다운되거나 네트워크가 끊겨 뒤처진 사이 리더가 해당 구간의 로그를 스냅샷 후 purge 했다. 정상이라면 InstallSnapshot 으로 따라잡아야 하는데 이 과정이 동작하지 않으면 gap 오류가 반복된다.
| 데몬 | 역할 |
|---|---|
| Ozone Manager(OM) | Volume → Bucket → Key 네임스페이스 메타데이터. 키 → 블록 매핑을 RocksDB 에 저장. 3노드가 Ratis(Raft) 로 복제 |
| Storage Container Manager(SCM) | 컨테이너(기본 5 GB 단위) 생성 · 할당 · 복제, 블록 할당, Datanode 등록 · 하트비트 · 상태 추적, 쓰기 파이프라인 구성. Ratis HA 가능 |
| Datanode | 컨테이너 형태로 데이터 저장. RATIS/THREE 는 3개 DN 이 Ratis 파이프라인으로 3중 복제. EC 도 지원 |
| Recon | OM · SCM · DN 정보를 집계하는 모니터링 UI. 데이터 경로에 관여하지 않는다 |
| S3 Gateway | S3 REST API 를 Ozone 프로토콜로 변환하는 stateless 게이트웨이 |
쓰기 흐름은 클라이언트 → OM 에 키 생성 요청 → OM 이 SCM 에 블록 할당 요청 → 클라이언트가 Datanode 파이프라인에 직접 데이터 기록 → OM 에 commit 이다. OM 은 논리적 네임스페이스, SCM 은 물리적 저장 위치를 담당한다.
ozone admin om roles -id=<om-service-id> # 리더 · 팔로워 상태
grep -i InstallSnapshot /var/log/hadoop-ozone/ozone-om-*.log # 스냅샷 전송 시도 · 실패 여부
gap 오류만 반복되고 InstallSnapshot 로그가 없으면 스냅샷 동기화가 아예 동작하지 않는 것이다. 나머지 두 OM 이 정상이고 리더가 선출돼 쿼럼(3 중 2) 이 유지되는지 먼저 확인한다. 쿼럼이 살아 있으면 서비스는 정상이므로 문제 노드 하나를 여유를 갖고 복구한다. 두 노드를 동시에 건드리지 않는다.
ozone-site.xml 의 ozone.om.ratis.storage.dir(미설정 시 ozone.metadata.dirs 하위 ratis 디렉터리) 를 확인하고, 삭제 대신 다른 위치로 이동해 백업한다.ozone admin om roles 로 FOLLOWER 로 정상 합류했는지 확인한다.ozone-site.xml 의 스냅샷 · purge 설정을 점검한다.
ozone.om.ratis.snapshot.auto.trigger.enabled = trueozone.om.ratis.snapshot.auto.trigger.threshold — 스냅샷 트리거 임계 트랜잭션 수ozone.om.ratis.log.purge.gap자동 스냅샷이 꺼져 있거나 임계값이 너무 크면 노드가 잠깐 뒤처졌을 때 따라잡지 못한다. OM 힙(OZONE_OM_OPTS 의 -Xmx) 과 디스크 I/O 도 함께 확보한다.