고가용성 클러스터링의 생명선, 하트비트 지연 임계값 설정 가이드
고가용성(HA) 클러스터 시스템에서 노드 간의 연결 상태를 확인하는 하트비트(Heartbeat) 신호는 시스템의 생명선과 같습니다. 이 신호의 지연 시간(Latency)에 대한 임계값(Threshold)을 올바르게 설정하지 않으면, 단순한 네트워크 지연이 치명적인 ‘스플릿 브레인(Split-Brain)’ 현상이나 불필요한 페일오버(Failover)를 유발할 수 있습니다. 본 가이드는 실무에서 즉시 적용 가능한 하트비트 지연 임계값 설정의 원칙과 구체적인 방법을 제시합니다.
증상 확인: 잘못된 임계값 설정의 징후
다음 증상이 관찰된다면 하트비트 지연 임계값 설정이 환경에 맞지 않을 가능성이 높습니다. 먼저 클러스터 로그(`/var/log/messages` 또는 `journalctl -u corosync`)에서 관련 메시지를 확인하십시오.
- 불필요한 페일오버: 실제 서비스 장애 없이도 노드가 계속해서 전환됩니다. 로그에 “node lost” 또는 “quorum lost” 메시지가 빈번하게 기록됨.
- 스플릿 브레인 현상: 두 노드가 모두 자신이 활성 노드라고 판단하여 동일한 자원(예: 공유 스토리지)에 동시에 쓰기 작업을 시도합니다, 데이터 손상의 가장 치명적인 원인.
- 자원 그룹의 플래핑(flipping): 서비스가 노드 a와 b 사이를 빠르게 오가며 안정적으로 정착하지 못합니다.
- 하트비트 링크 상태 불안정: 관리 도구(예: `crm_mon`, `pcs status`)에서 하트비트 링크가 지속적으로 up/down 상태를 반복합니다.
원인 분석: 지연 시간의 본질과 임계값의 역할
구형 시스템일수록 소프트웨어 충돌보다 하드웨어 노후화나 네트워크 인프라의 병목이 지연 시간 증가의 주된 원인입니다. 하트비트 지연은 주로 네트워크 경쟁, 스위치 버퍼링, 부하 증가 시의 CPU 처리 지연에서 발생합니다. 임계값 설정의 목표는 ‘정상적인 최대 지연’과 ‘비정상적인 연결 단절’을 정확히 구분하는 선을 찾는 것입니다. 이 선이 너무 짧으면(민감하게 설정하면) 네트워크 잡음에 과반응하고, 너무 길면(둔감하게 설정하면) 실제 장애를 감지하는 데 시간이 낭비되어 서비스 중단 시간(MTTR)이 길어집니다.
해결 방법 1: 기본 환경 측정 및 초기 임계값 산정
가장 먼저 실제 운영 환경에서의 기본 네트워크 지연 시간을 측정해야 합니다. 이 값은 이론적 추정이 아닌, 측정된 데이터를 기반으로 해야 합니다.
- 측정 도구 실행: 클러스터 노드 간에 `ping` 명령어를 이용해 ICMP 패킷 지연을 장시간(최소 5-10분) 관찰합니다. 부하가 높은 시간대에 측정하는 것이 좋습니다.
ping -c 1000 -i 0.2 [대상_노드_IP] | tail -5출력된 평균(`avg`)과 최대(`max`) RTT(Round-Trip Time) 값을 기록합니다. 나아가, `mtr` 도구를 사용해 구간별 지연을 확인할 수 있습니다.
- 초기 임계값 계산: 측정된 최대 RTT 값에 여유분을 추가하여 초기 임계값을 설정합니다. 일반적인 경험 법칙은 다음과 같습니다.
- 최소 임계값(민감도): 측정 평균 RTT * 2 ~ 3
- 권장 시작 임계값: 측정 최대 RTT * 2.5 ~ 3.5
예를 들어, 측정 최대 RTT가 2ms라면, 초기 임계값은 5ms ~ 7ms 정도로 시작합니다. 이 값은 하트비트 프로토콜(Corosync, Pacemaker)의 ‘`token`’ 또는 ‘`max_missed_count`’ 등의 파라미터 설정으로 변환됩니다.
주의사항: 이 측정은 반드시 전용 하트비트 링크(또는 VLAN)에서 수행해야 합니다. 서비스 트래픽과 혼합된 환경에서 측정하면 정확한 기준값을 얻을 수 없습니다. 또한, 스위치의 플로우 컨트롤이나 Jumbo Frame 설정이 지연에 영향을 미칠 수 있으므로 측정 시 네트워크 구성을 실제 운영 환경과 동일하게 유지하십시오.
해결 방법 2: Corosync/Pacemaker 환경에서의 구체적 설정 조정
Linux 기반 HA 클러스터의 사실상 표준인 Corosync와 Pacemaker 조합에서 하트비트 지연 관련 핵심 파라미터를 조정하는 방법입니다.
Corosync 구성 파일(`corosync.conf`) 수정
가장 직접적인 설정 파일입니다. 수정 전 반드시 원본 파일을 백업하십시오.
- 파일 백업:
cp /etc/corosync/corosync.conf /etc/corosync/corosync.conf.backup_$(date +%Y%m%d) - 토큰 타임아웃 조정: `totem` 섹션의 `token` 값은 하나의 노드가 토큰(네트워크 제어권)을 유지하는 시간(ms)입니다. 이 시간 내에 다른 노드가 토큰을 받지 못하면 문제로 판단합니다,
기본값은 1000ms(1초)입니다. 측정된 RTT가 매우 짧은 LAN 환경이라도 네트워크 불안정성을 고려해 3000ms ~ 5000ms 정도로 설정하는 것이 일반적입니다. 지연이 큰 WAN 환경에서는 더 늘려야 합니다.
totem {
...
token: 3000;
...
} - 토큰 재전송 간격 조정: `token_retransmits_before_loss_const` 값은 토큰 손실로 판단하기 전까지의 재전송 횟수입니다. `token` 시간과 조합되어 최종 타임아웃을 결정합니다. (최종 타임아웃 ≈ `token` * `token_retransmits_before_loss_const`)
기본값은 4입니다. `token`이 3000ms이고 이 값이 4라면, 약 12초 후에 노드 손실로 판단합니다. 네트워크가 불안정하면 이 값을 5~6으로 높여 민감도를 낮출 수 있습니다.
- 링크 모니터링 간격: `rrp_mode`가 “active”인 경우(링크 이중화) `link_priority`나 `link_timeout`을 확인하십시오. 특정 벤더 솔루션에서는 별도의 링크 모니터링 데몬 설정이 필요할 수 있습니다.
Pacemaker의 스토네스(Stonith) 및 리소스 타임아웃 연동 설정
Corosync가 노드 실패를 감지하면, Pacemaker는 리소스 페일오버를 실행합니다. 이때 스토네스 장치가 다른 노드를 차단합니다. 하트비트 지연 임계값은 이 전체 과정의 첫 걸림돌입니다.
- 스토네스 타임아웃: 스토네스 작업의 타임아웃은 하트비트 임계값으로 인한 노드 손실 판단 시간보다 충분히 길어야 합니다. 일반적으로 노드 손실 판단 시간의 1.5~2배를 설정합니다.
- 리소스 모니터링 간격: 개별 리소스(예: IPaddr2, Filesystem)의 `monitor` 작업 간격은 하트비트 감지보다 더 짧게 설정하여 애플리케이션 수준의 장애를 빠르게 감지할 수 있도록 구성할 수 있습니다. 이는 별개의 설정 레이어입니다.
해결 방법 3: 고급 모니터링 및 동적 임계값 적용 방안
정적인 임계값 설정으로도 충분할 수 있지만, 더욱 견고한 시스템을 위해 고려할 수 있는 접근법입니다.
- 다중 링크 및 투표 시스템 활용: 단일 하트비트 링크에 의존하는 것은 위험합니다. 최소 2개 이상의 물리적으로 분리된 네트워크 경로(예: 전용 랜 카드 2개, 다른 스위치 연결)를 통해 하트비트를 전송하도록 구성하십시오. Corosync의 `rrp_mode`를 “active”로 설정하고, `ringnumber` 별로 다른 네트워크 인터페이스를 지정합니다. 노드 손실 판단은 다수결(quorum) 원칙에 따르므로, 다중 링크는 일시적인 경로 장애를 흡수합니다.
- 지연 시간 모니터링 스크립트 구현: `ping` 또는 `corosync-blackbox` 툴의 출력을 주기적으로 모니터링하고, 일정 시간(window) 동안의 지연 추이(평균, 표준편차)를 계산하는 스크립트를 작성합니다. 지연이 서서히 증가하는 추세를 감지하면, 시스템 관리자에게 경고를 발송하여 네트워크 인프라의 잠재적 문제를 사전에 인지할 수 있습니다.
- 운영 체제 및 펌웨어 점검: 네트워크 인터페이스 카드(NIC)의 드라이버와 펌웨어가 최신인지 확인하십시오. 구형 드라이버에는 인터럽트 처리 지연(IRQ latency) 관련 버그가 존재할 수 있습니다, 또한, 서버 bios/uefi 설정에서 전원 관리 상태(c-state)를 너무 공격적으로 설정하면 cpu가 깊은 절전 모드로 들어가 패킷 처리 지연이 발생할 수 있습니다. 성능 중심 프로파일로 변경을 고려하십시오.
동일 문제 재발 방지를 위한 시스템 최적화 체크리스트
지금 당장 작동하는 해결책이 가장 훌륭한 기술적 자산입니다. 다음 체크리스트를 통해 설정의 안정성을 검증하고 재발을 방지하십시오.
- 네트워크 분리 확인: 하트비트 트래픽은 반드시 전용 물리적 링크 또는 전용 VLAN을 사용하며. 서비스 트래픽 및 관리 트래픽과 분리되어야 합니다.
- 스위치 설정 검증: 하트비트 포트에서 spanning tree protocol(stp)가 비활성화되어 있거나 portfast 모드로 설정되었는지 확인합니다. STP 재계산 시간은 하트비트 임계값을 쉽게 초과합니다.
- 시스템 시계 동기화: 모든 노드의 시계가 NTP를 통해 정확히 동기화되어 있어야 합니다. 시계 차이는 로그 분석과 특정 클러스터 운영에 악영향을 미칩니다.
- 쿼럼 정책 점검: 짝수 개의 노드로 구성된 클러스터에서는 쿼럼 장치(Quorum Device) 또는 기타 쿼럼 정책을 반드시 구성하여 스플릿 브레인을 방지해야 합니다.
- 정기 부하 테스트: 계획된 유지보수 시간에 네트워크 및 시스템에 고부하를 인위적으로 발생시켜, 극한 상황에서의 하트비트 지연과 클러스터 행동을 관찰하고 임계값을 조정합니다.
전문가 팁: 지연 시간 로깅 및 분석
Corosync의 로그 레벨을 높여(`debug: on` in `logging` section) 하트비트 메시지의 상세한 타임스탬프를 기록하게 할 수 있습니다. 이 로그를 분석하면 정상적인 `token` 회전 시간과 지연 발생 시의 패턴을 정량적으로 파악할 수 있습니다. 단, 디버그 로깅은 시스템 부하를 증가시키므로 장기간 운영 환경에서 사용하지 말고, 문제 진단을 위한 일시적 수단으로만 활용하십시오. 또한, `corosync-cfgtool -s` 명령어를 실행하면 현재 링크의 상태 및 통계 정보를 실시간으로 확인할 수 있어, 임계값 설정의 적절성을 검증하는 데 도움이 됩니다.