728x90
반응형
1️⃣ 하트비트(Heartbeat)란?
- 인덱서 클러스터에는 Cluster Master(현재는 CM → CMM, Cluster Manager) 와 여러 인덱서(peer)가 있습니다.
- CM은 일정 주기(Heartbeat Interval)마다 인덱서들에게 “너 살아 있니? 상태가 뭐니? 버킷 몇 개 있어?” 하고 묻습니다.
- 인덱서는 응답에 자신이 가진 버킷 manifest(메타데이터) 를 포함시켜 전달합니다.
2️⃣ 왜 버킷 개수가 많아지면 영향이 있나?
- 각 버킷마다 manifest 정보를 확인/전송해야 하니까, 버킷 개수가 많으면 Heartbeat 응답이 커지고 늦어집니다.
- 대규모 환경(수만~수십만 버킷)에서는 CM이 모든 인덱서 peer 상태를 받는 데 시간이 걸려요.
- 그래서 버킷 5만 개당 1초씩 heartbeat 주기를 늘려라 라는 게 Splunk 권장 튜닝 가이드입니다.
즉,
- 버킷이 많음 = 응답이 무거움
- 응답이 무거움 = 주기 너무 짧으면 peer가 제때 보고를 못함 → CM이 “이 노드 죽었네?” 하고 잘못 판단
- 그 결과 → 클러스터 상태 전환(rebalance, fix-up) 시 혼란이 생겨 검색 불가능 구간이 발생할 수 있음
3️⃣ "상태 전환 중 검색 가능성에 영향" 이라는 말의 뜻
- 클러스터는 Peer 노드 하나가 죽으면 다른 Peer의 복제본을 Primary로 승격시킵니다.
- 이걸 상태 전환(State Transition) 이라고 부릅니다.
- 근데 Heartbeat가 너무 짧으면, 아직 살아 있는 노드를 “죽었다”고 오판 → 잘못된 승격/재배치 발생 → 해당 버킷의 데이터 검색 불가 상태가 일시적으로 생김.
즉, Heartbeat를 너무 촘촘히 두면 “민감하게 오판”하는 리스크가 있고,
반대로 너무 길게 두면 “실제 장애 감지가 늦어짐”.
4️⃣ 그래서 Splunk 권장은?
- 기본 heartbeat는 보통 30초 수준.
- 버킷이 많으면 응답이 오래 걸리므로, 버킷 5만 개마다 1초씩 늘려라 → CM이 오판하지 않게.
- 예: 버킷 20만 개라면 최소 34초 정도로 잡는 게 안정적.
✅ 쉽게 비유하자면
- CM(관리자)이 인덱서(peer)한테 “현황 보고해!” 하고 매 30초마다 전화한다고 합시다.
- Peer가 “저 버킷 20만 개 정리 중이라 보고서 작성에 10초 걸려요” 라고 하면…
- 전화 간격이 30초면 보고가 밀려서 관리자가 “얘 연락 두절, 죽었네!” 하고 판단 → 잘못된 장애 처리 발생.
- 그래서 전화 주기를 40초로 늘려주는 게 맞습니다.
👉 정리:
“Heartbeat 주기를 너무 짧게 두면, 버킷이 많을 때 인덱서가 응답을 제때 못 해서 CM이 오판
→ 상태 전환 중 검색이 끊길 수 있다.
→ 버킷이 5만 개 늘어날 때마다 1초씩 주기를 늘려라.”
1️⃣ 인덱서 클러스터의 두 가지 하트비트 성격
(A) 저수준 Heartbeat (1초 주기)
- Peer 인덱서 ↔ CM 간 TCP 연결에서 1초마다 신호를 보냅니다.
- 만약 60초 동안 응답 없음 → CM은 해당 peer를 “down” 상태로 판단.
- 이건 말 그대로 “네트워크/프로세스 살아 있나?” 확인하는 수준.
- 설정은 heartbeatTimeout (server.conf) 관련 값으로 조정 가능. (기본 60초)
(B) 상태 리포트 Heartbeat (Manifest 포함)
- Peer가 자신이 가진 버킷 메타데이터(manifest) 와 상태를 CM에게 보고하는 주기.
- 이게 클러스터 매니저의 status heartbeat interval입니다.
- 여기서 버킷이 많으면 manifest 처리 시간이 늘어나니까, “버킷 5만 개당 1초씩 보고 주기를 늘려라” 라는 권장이 나오는 거예요.
- 설정은 heartbeatPeriod (server.conf → [clustering] 섹션) 값으로 조정. (기본 30초 수준)
2️⃣ 왜 두 개가 헷갈리냐?
- 문서에서 말하는 “1초 heartbeat / 60초 timeout”은 네트워크 keepalive 같은 저수준 레벨.
- 튜닝 가이드에서 말하는 “버킷 많으면 주기를 늘려라”는 건 상태 리포트 주기.
- 결국 서로 다른 계층의 heartbeat인데 둘 다 “하트비트”라고 부르니까 혼동되는 거예요.
3️⃣ 정리
- timeout: peer를 죽었다고 판단하기까지 기다리는 시간 (기본 60초)
- heartbeat 주기(Period): peer가 CM에 상태/manifest 보고를 보내는 주기 (기본 30초, 버킷 많으면 늘려야 함)
👉 따라서 문서에서 본 1초 heartbeat는 그대로 두고,
튜닝 시 건드리는 건 heartbeatPeriod (상태 보고 주기) 입니다.
✅ 비유
- 1초 heartbeat + 60초 timeout: “숨 쉬고 있나?” 확인 (응답 없으면 1분 뒤 사망 판정)
- heartbeatPeriod (30초 → 조정): “업무 보고서 제출” 주기 (버킷 많으면 작성 오래 걸리니 제출 간격 늘리라는 권장)
더보기
🌳상태 리포트 주기(heartbeatPeriod) 와 피어 타임아웃(heartbeatTimeout) 설정 방법 (server.conf)
1) 현재 값 확인 (권장)
$SPLUNK_HOME/bin/splunk btool server list clustering --debug- 실제로 적용 중인 값을 정확히 보여줍니다(기본값/로컬 덮어쓰기 포함).
- 운영 전에 꼭 이걸로 점검하세요.
2) 설정 파일 위치
- 클러스터 매니저(Cluster Manager, CM)와 피어(인덱서) 모두 server.conf 의 [clustering] 섹션에서 관리됩니다.
- 일반적으로 CM와 피어에 동일한 정책을 일관되게 배포합니다.
3) 핵심 파라미터 요약
- heartbeatPeriod
- 의미: 상태/버킷 메타(매니페스트) 리포트 주기 (상태 보고서 제출 간격)
- 효과: 너무 짧으면 대규모 버킷 환경에서 보고 처리 지연 → CM 오판 가능 ↑
- 튜닝 가이드: 버킷 5만 개마다 +1초 늘리기
- heartbeatTimeout
- 의미: 피어를 “다운”으로 판단하기 전까지 기다리는 최대 시간
- 효과: 너무 짧으면 네트워크/부하 일시 이슈에도 다운으로 오판, 너무 길면 장애 전파가 느려짐
기억하기:
- heartbeatPeriod = “업무 보고서 제출 간격”
- heartbeatTimeout = “응답 없으면 사망 판정까지 기다리는 시간”
4) 설정 예시
(A) 기준값 예시
# server.conf (CM와 Peer 공통 권장)
[clustering]
mode = manager / peer
# 상태 리포트 주기(초) — 기본은 대략 30초권
heartbeatPeriod = 30
# 피어 Down 판정 타임아웃(초) — 문서상 기본 60초권
heartbeatTimeout = 60(B) 대규모 환경 튜닝 예시
- 가정: 버킷 총 200,000개 수준
- 권장: 5만 개마다 +1초 → +4초
- ⇒ heartbeatPeriod = 30 + 4 = 34
[clustering]
mode = manager / peer
heartbeatPeriod = 34
heartbeatTimeout = 60 # 상황에 따라 75~90 등으로 완만히 상향 가능
(C) 초대규모/멀티사이트에서 여유를 더 주는 예시
- 버킷/사이트 간 동기화 지연이 보이면 period를 더 늘리거나 timeout을 소폭 상향
[clustering]
mode = manager / peer
heartbeatPeriod = 40
heartbeatTimeout = 90팁: heartbeatTimeout 은 최소 heartbeatPeriod보다 충분히 커야 합니다.
(예: period 40초면 timeout을 40초보다 아래로 두면 안 됨)
5) 변경 적용 절차(안전하게)
1. CM와 Peer 모두에 설정 반영(DS 사용 시 앱으로 배포 권장)
2. 클러스터 롤링 재시작
# CM에서
splunk show cluster-status
# 각 피어에서 순차적으로
splunk restart
# 상태가 안정되면 다음 피어…
3. 재시작 후 상태 확인
splunk show cluster-status
splunk btool server list clustering --debug6) 현장 팁
- 증상 기반 조정
- CM에서 간헐적 피어 down/up 플랩이 보이거나, 상태 전환(rebalance/fix-up) 중 일시 검색 누락이 관찰되면
→ heartbeatPeriod를 먼저 (+1~+5초 범위) 보수적으로 상향
→ 여전히 오판/지연이 있으면 heartbeatTimeout을 소폭 상향
- CM에서 간헐적 피어 down/up 플랩이 보이거나, 상태 전환(rebalance/fix-up) 중 일시 검색 누락이 관찰되면
- 지표 모니터링
- CM의 splunkd.log 에서 peer health, fix-up, replication 메시지 추적
- MC(Monitoring Console)에서 Cluster > Indexing 대시보드로 재복제/수리 큐 지연 관찰
- 버킷 수 추산
- 인덱스별 버킷 개수/상태를 주기적으로 점검(roll/hot-warm 정책도 함께 최적화)
- “5만 개당 +1초”는 총 버킷 수(사이트/피어 전체 관점) 로 보정
📌 service_interval 이란?
- 인덱서 클러스터(Cluster Manager ↔ Peer)에서 클러스터 매니저가 주기적으로 실행하는 서비스 루프 주기를 말합니다.
- CM이 정기적으로 하는 일:
- 피어 상태 확인
- 버킷 메타데이터(manifest) 수집
- replication/fix-up 필요 여부 판단
- 검색 가능 상태(primary/secondary role) 재조정
👉 즉, service_interval은 클러스터 매니저가 내부적으로 상태 점검과 관리 로직을 실행하는 간격입니다.
(Heartbeat는 피어 ↔ CM 신호 주기고, Service interval은 CM이 그 신호를 모아서 “업무 처리”하는 주기라고 보시면 돼요.)
✅ 운영 가이드
- 보통은 service_interval은 건드리지 않습니다.
(기본 30초가 대부분 환경에서 충분히 안정적) - 대규모 환경에서 CM이 지나치게 자주 상태 관리 루프를 돌면서 CPU 부하가 크다면 → 소폭 늘리는 식으로 조정할 수 있습니다.
- 하지만 튜닝 1순위는 heartbeatPeriod이고, service_interval은 극히 특수한 경우에만 만집니다.
👉 요약
- heartbeatPeriod: 피어가 CM에 상태 보고하는 주기
- service_interval: CM이 받은 상태 보고를 토대로 클러스터 관리 작업을 실행하는 주기
📌 service_interval = 0 의 의미
- server.conf 의 [clustering] 섹션에서 설정 가능
- 기본값은 0 = “CM이 서비스 루프를 최대한 빠르게 계속 돌린다” 는 뜻입니다.
- 즉, 별도 지연(슬립 타임) 없이 상태 관리, 버킷 복제/수리(fix-up), manifest 확인 같은 클러스터 관리 작업을 연속적으로 수행합니다.
- 값이 양수(초 단위) 로 지정되면, 그만큼 간격을 두고 서비스 루프를 실행합니다.
- 예: service_interval = 5 → CM이 관리 루프 돌리고 5초 쉰 뒤 다시 실행
📊 왜 기본값이 0일까?
- 대부분 환경에서는 CM이 즉시/지속적으로 클러스터 상태를 관리하는 게 안정적입니다.
- 그래서 기본은 0(=실시간 loop)이고,
특수 대규모 환경(버킷 수 수십만 이상, CM CPU 과부하가 눈에 띌 때)에서만 간격을 주도록 설정합니다.
⚖️ 다른 값들과 비교
| heartbeatPeriod | 30초 | Peer → CM 상태/manifest 보고 주기 |
| heartbeatTimeout | 60초 | Peer 응답 없을 때 CM이 “Down” 판정까지 기다리는 시간 |
| service_interval | 0 | CM이 클러스터 관리 루프를 도는 간격 (0=연속 실행) |
👉 즉,
service_interval = 0 은 실시간 루프, heartbeatPeriod = 30 은 보고 주기, heartbeatTimeout = 60 은 다운 판정 기준
✅ 운영 가이드
- 기본은 0 유지 → CM이 빠르게 상태를 처리해 줌.
- 만약 CM CPU 부하가 지나치게 크거나, 대규모 환경에서 “관리 루프 간격을 강제로 띄워야” 하는 경우만 5, 10 같은 값을 부여.
- Splunk도 공식적으로 웬만하면 건드리지 말고 0 유지 권장.
- 파란 점(30s 간격) → Peer가 CM에 상태/manifest 보고 (heartbeatPeriod)
- 빨간 점선(60s) → Timeout 기준. 만약 이 시점까지 응답이 없으면 Peer를 “Down” 으로 판단 (heartbeatTimeout)
- 초록 점(매 5s) → CM이 내부 루프를 돌며 버킷 복제/수리, 상태 관리 (service_interval)
- 기본값 0 → 사실상 “쉬지 않고 계속” 루프 실행 (여기선 보기 편하게 5초 단위로 표시)
👉 정리:
- heartbeatPeriod: Peer가 언제 보고서를 내느냐
- service_interval: CM이 언제 그 보고서를 바탕으로 관리 업무를 보느냐
- heartbeatTimeout: CM이 “응답이 없으면 죽었다”라고 판정하는 한계치
728x90
반응형