Corosync 통신 구조와 Pacemaker 리소스 에이전트의 실제 동작 방식

작성자:

리눅스 HA(High Availability) 클러스터에서 가장 많이 사용되는 조합이 Corosync + Pacemaker다.
두 컴포넌트는 하나의 클러스터처럼 보이지만, 실제로는 역할이 명확히 분리된 구조를 가진다.
Corosync는 노드 간 통신과 멤버십을 담당하고, Pacemaker는 그 위에서 리소스를 어떻게 시작·중지·이동할지 결정한다.
이 글에서는 Corosync의 통신 구조와 Pacemaker 리소스 에이전트가 실제로 어떻게 동작하는지를 내부 흐름 기준으로 심층 분석한다.

1. Corosync와 Pacemaker의 역할 분리 개요

HA 클러스터에서 두 컴포넌트의 역할은 명확하다.

  • Corosync
    • 노드 간 통신
    • 클러스터 멤버십 관리
    • 쿼럼(quorum) 계산
    • 장애 감지(노드 up/down)
  • Pacemaker
    • 리소스 상태 판단
    • 리소스 시작·중지·모니터링
    • 장애 발생 시 복구·이동 정책 결정
    • 리소스 제약(constraint) 계산

즉, Corosync는 “누가 살아있는지”를 알려주고,
Pacemaker는 “무엇을 어떻게 할지”를 결정한다.

2. Corosync의 통신 계층 구조

Corosync는 단순한 메시지 브로드캐스터가 아니라, 여러 계층으로 구성된 통신 스택을 가진다.

TOTEM 프로토콜

Corosync의 핵심은 TOTEM(Total Order Multicast) 프로토콜이다.

TOTEM의 역할은 다음과 같다.

  • 모든 노드가 동일한 메시지 순서를 보장받도록 함
  • 멤버십 변경 이벤트를 일관되게 전파
  • split-brain 방지를 위한 기반 제공

즉, 클러스터 전체가 “같은 순서로 같은 사건을 인식”하도록 만드는 것이 목표다.

전송 방식

Corosync는 환경에 따라 여러 전송 방식을 사용할 수 있다.

  • UDP 멀티캐스트
  • UDP 유니캐스트
  • (최근 환경에서는) knet 기반 멀티링크 통신

현대 클러스터에서는 보통 knet + 유니캐스트 조합이 사용된다.
이는 멀티캐스트 의존성을 줄이고, 다중 네트워크 링크를 활용해 안정성을 높이기 위함이다.

3. 멤버십과 쿼럼 계산 과정

Corosync는 주기적으로 노드 간 heartbeat를 교환한다.
이 heartbeat가 일정 시간 이상 응답하지 않으면 해당 노드는 “멤버십에서 제거”된다.

멤버십 변경 시 발생하는 일은 다음과 같다.

  1. 노드 장애 또는 신규 노드 감지
  2. 새로운 멤버십 뷰(view) 생성
  3. 모든 노드에 동일한 멤버십 정보 전파
  4. 쿼럼 재계산

쿼럼이 깨지면 Pacemaker는 리소스 제어를 중단하거나, 설정에 따라 강제 정지한다.
이는 split-brain을 막기 위한 핵심 안전장치다.

4. Corosync와 Pacemaker의 인터페이스

Pacemaker는 Corosync 위에서 직접 네트워크 통신을 하지 않는다.
대신 **CIB(Cluster Information Base)**와 Corosync 이벤트를 통해 상태를 공유한다.

흐름은 다음과 같다.

  • Corosync
    • 멤버십 변경 이벤트 발생
    • 노드 상태 변화 전달
  • Pacemaker
    • 이벤트 수신
    • 클러스터 상태 재계산
    • 리소스 재배치 필요 여부 판단

이 구조 덕분에 Pacemaker는 “통신 구현”보다는 “정책 결정”에 집중할 수 있다.

5. Pacemaker 내부 구성 요소 개요

Pacemaker는 단일 프로세스처럼 보이지만 내부적으로 여러 컴포넌트로 나뉜다.

  • crmd
    • 클러스터 상태 머신
    • 리소스 상태 결정의 중심
  • pengine
    • 정책 엔진
    • 제약 조건, 점수(score) 계산
    • 최적의 리소스 배치 결정
  • lrmd
    • Local Resource Manager
    • 리소스 에이전트 실행 담당

이 중 리소스 에이전트와 직접 상호작용하는 것은 lrmd다.

6. 리소스 에이전트(Resource Agent)의 개념

리소스 에이전트(RA)는
“이 리소스를 어떻게 시작하고, 중지하고, 상태를 확인할지”를 정의한 스크립트다.

대표적인 에이전트 유형은 다음과 같다.

  • OCF(Open Cluster Framework)
  • LSB(init script 호환)
  • systemd 기반 에이전트

현대 클러스터에서는 대부분 OCF 에이전트가 사용된다.

7. OCF 리소스 에이전트의 실제 동작 방식

OCF 에이전트는 표준화된 인터페이스를 따른다.
Pacemaker는 특정 이벤트가 발생할 때 아래 동작을 호출한다.

  • start
  • stop
  • monitor
  • promote / demote (Master/Slave 구조)
  • meta-data

start 동작

  1. Pacemaker가 리소스를 특정 노드에 배치 결정
  2. lrmd가 해당 노드에서 RA start 호출
  3. 스크립트가 실제 서비스 기동
  4. 정상 종료 코드 반환

monitor 동작

monitor는 HA에서 가장 중요한 동작이다.

  • 주기적으로 실행
  • 서비스 상태 점검
  • 실패 시 Pacemaker에 장애 신호 전달

monitor 실패가 누적되면 Pacemaker는 리소스를 재시작 또는 다른 노드로 이동시킨다.

8. 장애 발생 시 전체 흐름

실제 장애 상황에서의 흐름은 다음과 같다.

  1. 노드 장애
    • Corosync heartbeat 타임아웃
  2. 멤버십 변경
    • Corosync가 새로운 멤버십 뷰 생성
  3. Pacemaker 상태 재계산
    • pengine이 리소스 재배치 계산
  4. 리소스 정리
    • 살아있는 노드에서 불필요한 리소스 stop
  5. 리소스 재기동
    • 새로운 노드에서 RA start 호출

이 모든 과정은 사람의 개입 없이 자동으로 수행된다.

9. 리소스 에이전트 설계에서 중요한 포인트

리소스 에이전트의 품질은 클러스터 안정성에 직결된다.

중요한 설계 원칙은 다음과 같다.

  • monitor는 반드시 빠르고 정확해야 함
  • start/stop은 멱등성(idempotency) 보장
  • 실패 시 명확한 종료 코드 반환
  • 외부 의존성(DB, 네트워크) 상태 고려

특히 monitor가 부정확하면
“정상 서비스인데 장애로 오인”하거나
“장애인데 정상으로 판단”하는 심각한 문제가 발생한다.

10. Corosync + Pacemaker 구조의 핵심 요약

이 조합의 핵심은 명확한 역할 분리에 있다.

  • Corosync
    • 통신, 멤버십, 쿼럼
    • 클러스터의 신경계
  • Pacemaker
    • 정책, 판단, 실행
    • 클러스터의 두뇌
  • Resource Agent
    • 실제 서비스 제어
    • 클러스터의 손과 발

11. 정리 및 결론

Corosync와 Pacemaker는 단순히 “함께 쓰는 도구”가 아니라,
통신 계층과 정책 계층을 분리한 정교한 HA 아키텍처다.

Corosync는

  • 노드 상태를 일관되게 공유하고
  • split-brain을 방지하며

Pacemaker는

  • 그 정보를 기반으로
  • 리소스를 언제, 어디서, 어떻게 실행할지를 결정한다.

그리고 그 결정의 최종 실행자는
리소스 에이전트다.

이 구조를 정확히 이해하면

  • 장애 발생 시 왜 그런 결정이 내려졌는지
  • 리소스가 왜 이동했는지
  • 왜 예상과 다른 동작을 했는지
    를 논리적으로 추적할 수 있다.

HA 클러스터 운영의 안정성은
설정보다 먼저 이 구조를 이해하는 것에서 시작된다.

댓글 남기기