일본 IDC 내 물리 서버(Bare Metal) 인프라에서 Corosync와 Pacemaker를 활용하여 고가용성(HA) 클러스터를 구축하고, Split-Brain 방지 및 자동 장애 복구를 구현하는 실무 가이드를 제공합니다.
물리 서버(Bare Metal) 환경에서 서비스 연속성을 유지하는 것은 인프라 운영자의 핵심 과제 중 하나입니다. 퍼블릭 클라우드의 자동 복구 기능과 달리 물리 서버 인프라에서는 하드웨어 장애나 OS 수준의 중단 현상에 직접 대응할 수 있는 고가용성(HA, High Availability) 메커니즘을 직접 설계하고 구현해야 합니다. 특히 일본 IDC 인프라를 활용하여 핵심 업무 시스템이나 데이터베이스 서비스를 운영할 때, 단일 물리 노드의 장애가 전체 서비스 중단으로 이어지지 않도록 클러스터링 솔루션을 도입하는 것이 매우 중요합니다.
Corosync는 클러스터 내 노드 간 상태를 동기화하고 멤버십 및 메시징을 담당하는 하위 레이어 솔루션이며, Pacemaker는 이 상태 정보를 기반으로 실제 서비스 리소스(예: VIP, 데이터베이스, 웹 서버 등)의 구동, 중지, 이동을 제어하는 리소스 관리자입니다. 이 두 요소를 조합하면 물리 서버의 하드웨어 및 네트워크 이상 발생 시 예비 노드로 리소스를 인계하는 자동 장애 조치(Failover) 체계를 구축할 수 있습니다.
Corosync와 Pacemaker 기반 HA 클러스터의 핵심 개념과 도입 필요성
고가용성 클러스터의 목적은 단일 장애점(SPOF, Single Point of Failure)을 제거하여 서비스 가동률을 최대로 유지하는 것입니다. 물리 서버 호스팅 환경에서는 메인보드, 메모리, NIC 등 하드웨어 부품 장애나 네트워크 스위치 연결 장애가 언제든 발생할 수 있습니다.
Corosync와 Pacemaker 조합은 오픈소스 기반으로 검증된 HA 솔루션으로, 서비스 상태 파악, 노드 간 헬스체크, 리소스 재배치를 자동 수행합니다. 이를 통해 장애 발생 시 운영자의 개입 없이도 수 초에서 수 분 이내에 예비 노드로 서비스 가상 IP(VIP) 및 애플리케이션을 전환할 수 있습니다.
Corosync 노드 간 통신 설정 및 쿼럼(Quorum) 구성 가이드
Corosync 구성에서 가장 중요한 요소는 노드 간 심장박동(Heartbeat) 신호를 주고받는 네트워크 통신의 신뢰성과 쿼럼(Quorum) 판단 기준을 정립하는 것입니다. 멀티 노드 환경에서 네트워크 분할로 인해 양쪽 노드가 서로의 생존을 확인하지 못하는 현상이 발생하면, 양측 모두 자신을 주 노드로 판단하여 동일한 리소스를 이중으로 구동하는 Split-Brain 장애가 발생할 수 있습니다.
이를 방지하기 위해 Corosync 설정 파일(corosync.conf)에서는 통신 바인딩 인터페이스와 쿼럼 정책을 명확하게 정의해야 합니다. 두 노드 간의 Direct 케이블 연결이나 이중화된 내부 VLAN망을 확보하여 심장박동 패킷의 손실을 방지하는 것이 권장됩니다.
corosync.conf 주요 설정 요소
- totem 섹션: 노드 간 패킷 전달 주기, 타임아웃 시간, 암호화 방식(crypto_cipher, crypto_hash)을 설정합니다.
- nodelist 섹션: 클러스터에 참여하는 각 노드의 Node ID, Hostname, Ring0/Ring1 IP 주소를 명시합니다.
- quorum 섹션: 과반수 동의 기준을 설정하며, 2노드 구성 시에는 ‘two_node: 1’ 옵션을 신중하게 검토하여 구동 방향을 결정합니다.
Pacemaker 리소스 관리자 설정과 VIP/서비스 리소스 바인딩
Corosync가 노드 간의 헬스체크 및 쿼럼을 유지하면, Pacemaker는 수집된 상태 정보를 바탕으로 클러스터 리소스를 제어합니다. 주요 리소스에는 가상 IP(VIP), 시스템 서비스(Systemd), 공유 스토리지 마운트 등이 포함되며, 이들 간의 실행 순서와 의존성을 정확히 바인딩해야 정상적인 서비스 연속성이 보장됩니다.
리소스 설정 시에는 Resource Agent(RA) 표준(OCF, LSB, systemd)을 준수해야 하며, 모니터링 주기(Interval)와 타임아웃(Timeout) 값을 물리 서버의 부하 수준에 맞춰 적절히 조정해야 합니다.
핵심 리소스 및 바인딩 규칙
VIP 리소스(IPaddr2)와 애플리케이션 리소스(예: PostgreSQL 또는 Nginx)는 항상 동일한 노드에서 동작하도록 그룹화(Group)하거나 콜로케이션(Colocation) 제약 조건을 부여해야 합니다. 또한, VIP가 정상 할당된 이후 애플리케이션이 구동되도록 순서(Order) 제약 조건을 명시합니다.
클러스터 장애 시나리오별 초동 진단 및 Split-Brain 방지 절차
HA 클러스터 운영 중 발생할 수 있는 주요 장애 유형은 물리 서버 다운, 네트워크 회선 절단, 리소스 응답 지연 등입니다. 이에 대비하여 Fence 디바이스(STONITH)를 구성하는 것이 클러스터의 데이터 정합성을 지키는 핵심 절차입니다.
STONITH(Shoot The Other Node In The Head)는 비정상 상태로 판단된 노드의 전원을 원격으로 차단하거나 IPMI/iLO/Out-of-Band 인터페이스를 통해 강제 리셋하여 Split-Brain 상태에서 공유 데이터가 손상되는 것을 차단합니다. 물리 인프라 환경에 따라 하드웨어 IPMI 기반 펜싱 디바이스를 적용해야 합니다.
| 장애 시나리오 | 감지 메커니즘 | 클러스터 동작 및 복구 절차 |
|---|---|---|
| 주 노드 전원 차단 | Corosync Heartbeat 타임아웃 초과 | 보조 노드가 쿼럼을 확보하고 STONITH 실행 후 VIP 및 서비스 이관 |
| 내부망 네트워크 단선 | Ring0/Ring1 이중화 회선 전환 실패 시 쿼럼 상실 | STONITH를 통한 상대 노드 전원 차단 시도 후 단일 노드 격리 조치 |
| 애플리케이션 프로세스 다운 | Pacemaker Monitor 에이전트 실패 감지 | 1차 로컬 재시작 시도 후 지속 실패 시 타 노드로 리소스 장애 이관 |
안정적인 일본 IDC 클러스터 운영을 위한 실무 검토 항목과 체크리스트
일본 IDC 내 물리 서버 인프라에서 고가용성 클러스터를 성공적으로 운영하기 위해서는 인프라 레벨의 네트워크 이중화와 물리적 랙 배치를 사전 검토해야 합니다. HARU IDC와 같은 전문 데이터센터 환경을 활용할 경우, 물리 서버 간 내부 인터페이스 이중화 구성이나 Out-of-Band 원격 관리망(IPMI)을 안정적으로 제공받을 수 있어 클러스터 펜싱 환경 구축이 용이합니다.
다만 물리 인프라 이중화가 완료되었더라도 시스템 운영 관점에서의 지속적인 장애 조치 테스트와 로그 분석이 수반되어야 합니다. 서비스 오픈 전에 반드시 강제 펜싱 테스트 및 회선 차단 테스트를 거쳐 자동 장애 복구가 정상 작동하는지 검증해야 합니다.
일본 IDC HA 클러스터 도입 실무 체크리스트
- 네트워크 이중화: Heartbeat 통신용 내부 네트워크 인터페이스가 서로 다른 L2 스위치 또는 VLAN으로 분리되어 있는가?
- Out-of-Band IPMI 접근성: STONITH 펜싱 처리를 위한 원격 IPMI/iSM 관리 IP가 전용 관리망에 안전하게 격리되어 있는가?
- 리소스 제약 조건 검증: VIP와 서비스 간의 Order 및 Colocation 제약 조건이 올바르게 설정되었는가?
- 장애 복구 테스트: 주 노드 강제 리셋 시 보조 노드로 서비스가 지정된 시간 내 정상 전환되는가?
- 운영 모니터링: crm_mon 또는 pcs status 상태 모니터링 알림이 외부 NMS/Syslog 서버와 연동되어 있는가?
결론적으로 Corosync와 Pacemaker를 결합한 고가용성 클러스터 설계는 물리 서버 인프라에서 불가피하게 발생할 수 있는 하드웨어 및 시스템 장애에 대비하는 강력한 방안입니다. 시스템 환경과 인프라 조건에 맞춰 쿼럼과 펜싱 정책을 철저히 검증함으로써 높은 수준의 비즈니스 연속성을 확보할 수 있습니다.
기업용 VPN 구성이 필요하신가요?
고정 IP, 관리자 접근 제한, 원격 업무 환경에 맞는 VPN 구성을 안내해드립니다.