DRBD Pacemaker: DRBD는 두 서버의 블록 장치를 복제하고 Pacemaker·Corosync는 어느 노드가 Primary, 파일시스템, 가상 IP와 서비스를 실행할지 결정합니다. 단순히 양쪽 노드에서 DRBD를 Primary로 올리거나 XFS를 동시에 마운트하면 데이터가 손상될 수 있으므로 Active/Passive와 강제 단일 쓰기 원칙을 지켜야 합니다.

기존 CentOS 7.9 예제는 지원 종료, 구형 Master/Slave 용어, 펜싱 생략 때문에 새 운영 환경에 그대로 적용하면 안 됩니다. 이 글은 Rocky Linux 9 계열과 DRBD 9, 현재 Pacemaker의 Promoted/Unpromoted 모델을 기준으로 설계 원리와 검증 순서를 설명합니다. 패키지 버전과 지원 조합은 배포판·LINBIT 계약 문서에서 다시 확인하십시오.

DRBD Pacemaker 2노드 HA: 단일 Primary, 블록 복제, quorum witness와 STONITH 펜싱 흐름
한 노드만 파일시스템을 마운트하고, 별도 복제 경로와 quorum·STONITH 경로가 split brain을 차단하는 Active/Passive 구조

DRBD Pacemaker 아키텍처와 장애 경계

계층 역할 실패 시 보호 장치
DRBD 9 블록 단위 동기 복제 Protocol C, 단일 Primary, 복제 상태 확인
Corosync 노드 멤버십·메시징·quorum 전용 또는 중복 네트워크, qdevice 검토
Pacemaker 리소스 배치·순서·복구 Promoted 역할, colocation·order 제약
STONITH 격리되지 않는 노드의 전원·접근 차단 독립 관리망, 실제 fence 시험
Filesystem DRBD 위 단일 writer XFS Promoted 노드에서만 마운트
VIP·서비스 클라이언트 진입점과 애플리케이션 Filesystem 뒤에 시작하고 역순으로 정지
Backup 삭제·손상·랜섬웨어 복구 DRBD와 분리된 버전형 백업·복원 시험
Pacemaker에서 STONITH 기능을 비활성화하는 운영 설정은 안전하지 않습니다. 통신이 끊긴 노드가 실제로 정지했는지 증명하지 못하면 두 노드가 같은 데이터의 소유권을 주장할 수 있습니다. 리소스를 올리기 전에 펜싱을 먼저 구성하고 시험하십시오.

DRBD Pacemaker 구축 전 요구사항

  • 두 노드의 OS, DRBD kernel module·utils, Pacemaker, Corosync, pcs, resource agent 호환성을 고정합니다.
  • 호스트명 정방향·역방향 해석과 NTP 동기화를 확인합니다.
  • 복제망, Corosync 통신망, 서비스망, BMC·펜싱 관리망의 장애 도메인을 가능한 한 분리합니다.
  • 양쪽 backing device 크기와 sector 정보를 확인하고 파티션에 파일시스템이나 LVM 서명이 없는지 검증합니다.
  • 전용 fence agent와 BMC 계정, qdevice 또는 제3의 판단 지점을 준비합니다.
  • RPO·RTO, 데이터 손상·split brain·사이트 장애 시 수동 복구 절차를 문서화합니다.

노드와 저장장치 사전 점검

hostnamectl --static
timedatectl status
chronyc tracking
getent hosts ha1.example.com ha2.example.com

lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS,MODEL,SERIAL
sudo blkid /dev/vdb1
sudo wipefs --no-act /dev/vdb1

예제는 /dev/vdb1을 사용하지만 실제 환경에서는 WWID, multipath, LVM 계층을 명확히 식별하십시오. 장치명이 재부팅 뒤 바뀌지 않는지 확인하고, 기존 서명이 보이면 중단합니다. wipefs의 –no-act는 조회만 하며 실제 삭제 명령은 이 글에서 자동화하지 않습니다.

패키지와 resource agent 확인

sudo dnf repolist
sudo dnf --showduplicates list   drbd-utils kmod-drbd pacemaker corosync pcs resource-agents fence-agents-all

rpm -q drbd-utils pacemaker corosync pcs resource-agents
modinfo drbd | head
drbdadm --version
pcs --version

pcs resource standards
pcs resource providers ocf
pcs resource agents ocf:linbit

DRBD 패키지 이름과 kmod 제공 방식은 저장소마다 다릅니다. RHEL 호환성, Secure Boot 서명, kernel 업데이트 정책과 지원 주체를 확인하고 검증된 저장소만 사용하십시오. ocf:linbit:drbd agent가 실제 설치되기 전에는 리소스를 만들지 않습니다.

DRBD Pacemaker 복제 리소스 구성

DRBD Protocol C는 원격 디스크에 쓰기가 확인된 뒤 완료를 반환하므로 동기 복제에 적합하지만, 애플리케이션 fsync와 스토리지 캐시 정책까지 자동으로 보장하지는 않습니다. 두 노드의 데이터 경로와 전원 장애 시 쓰기 보존 특성을 별도로 시험해야 합니다.

DRBD shared secret 생성

umask 077
openssl rand -base64 32

# 출력은 승인된 비밀 저장소에 보관하고
# 양쪽 노드의 DRBD 설정에 동일하게 배포합니다.

/etc/drbd.d/r0.res 예제

resource r0 {
  protocol C;
  device /dev/drbd0;
  disk /dev/vdb1;
  meta-disk internal;

  net {
    cram-hmac-alg sha256;
    shared-secret "REPLACE_WITH_GENERATED_SECRET";
  }

  on ha1.example.com {
    node-id 0;
    address ipv4 10.10.10.11:7789;
  }

  on ha2.example.com {
    node-id 1;
    address ipv4 10.10.10.12:7789;
  }
}

설정 파일은 root만 읽도록 0600으로 제한하고 구성 관리에서 secret을 평문 로그에 남기지 않습니다. REPLACE 문자열을 실제 비밀로 바꾸지 않은 상태에서 진행하면 안 됩니다. 방화벽은 복제 상대 주소에서 TCP 7789만 허용하고 SELinux와 firewalld를 끄지 마십시오.

메타데이터 생성과 장치 기동

sudo install -o root -g root -m 0600 /etc/drbd.d/r0.res /etc/drbd.d/r0.res
sudo drbdadm dump r0
sudo drbdadm create-md r0
sudo drbdadm up r0

sudo drbdadm status r0 --verbose
sudo cat /proc/drbd
create-md는 backing device에 DRBD 메타데이터를 씁니다. 장치 선택과 백업을 다시 확인한 뒤 양쪽 노드에서 실행하십시오. 기존 데이터가 있는 볼륨의 변환은 별도 마이그레이션 절차가 필요합니다.

초기 동기화와 파일시스템 생성

# 신규 빈 볼륨에서만, 권한 있는 변경 창에 ha1 한 곳에서 실행
sudo drbdadm primary --force r0
watch -n 2 sudo drbdadm status r0

# 두 peer가 UpToDate인 것을 확인한 뒤에만 새 XFS 생성
sudo mkfs.xfs -L ha_data /dev/drbd0
sudo mkdir -p /srv/ha-data
sudo mount /dev/drbd0 /srv/ha-data
sudo touch /srv/ha-data/cluster-marker
sudo umount /srv/ha-data
sudo drbdadm secondary r0

mkfs.xfs는 기존 내용을 파괴합니다. 재사용 볼륨이나 어느 한쪽에 보존할 데이터가 있으면 실행하지 마십시오. 초기 동기화 중 Source와 Target을 거꾸로 선택하면 올바른 데이터가 빈 블록으로 덮일 수 있으므로 신규 빈 장치임을 확인하고 상태가 UpToDate/UpToDate가 될 때까지 기다립니다.

DRBD Pacemaker 클러스터와 STONITH

pcs 인증과 Corosync 클러스터 생성

# 두 노드에서 hacluster 암호를 대화형으로 설정
sudo passwd hacluster

# 한 노드에서 실행하며 암호는 프롬프트에 입력
sudo pcs host auth ha1.example.com ha2.example.com -u hacluster
sudo pcs cluster setup ha-drbd ha1.example.com ha2.example.com --start
sudo pcs cluster enable --all

sudo pcs cluster status
sudo pcs quorum status
sudo corosync-cfgtool -s

2노드는 통신 단절 때 어느 쪽이 살아 있는지 서로 결정할 수 없습니다. Corosync qdevice를 제3의 투표로 두는 설계를 검토하되 qdevice도 STONITH를 대체하지 않습니다. LINBIT의 DRBD 내부 quorum·diskless tiebreaker를 사용할 경우 Pacemaker 펜싱과 DRBD resource-level fencing을 무작정 중첩하지 말고 지원 문서에 맞는 한 가지 일관된 설계를 선택하십시오.

Fence agent 탐색과 실제 시험

sudo pcs stonith list
sudo pcs stonith describe fence_ipmilan
sudo pcs stonith config
sudo pcs property config --all

# 실제 장비의 BMC·PDU·클라우드 fence agent와 매개변수로 생성한 뒤 확인
sudo pcs stonith config --full
sudo pcs stonith status

fence_ipmilan은 예시일 뿐입니다. 장비와 플랫폼에 맞는 fence agent, pcmk_host_map, 독립 관리 주소와 최소 권한 계정을 사용하십시오. 암호는 명령 이력에 넣지 말고 agent가 지원하는 안전한 secret 전달 방식을 사용합니다.

# 유지보수 창에 서비스 영향과 대상 노드를 이중 확인한 뒤에만 실행
sudo pcs stonith fence ha2.example.com

sudo pcs status --full
sudo journalctl -u pacemaker -u corosync --since '-10 min'
펜싱 시험은 대상 노드의 전원이 실제로 꺼지거나 스토리지 접근이 차단됐는지 사람이 확인해야 합니다. 명령 성공 메시지만 보고 안전하다고 판단하지 마십시오. 실패한 STONITH를 둔 채 데이터 리소스를 시작하면 안 됩니다.

DRBD Pacemaker promotable 리소스

DRBD agent와 Promoted 역할

sudo pcs resource create drbd_r0 ocf:linbit:drbd   drbd_resource=r0   op monitor interval=15s role=Promoted   op monitor interval=30s role=Unpromoted

sudo pcs resource promotable drbd_r0   promoted-max=1 promoted-node-max=1   clone-max=2 clone-node-max=1   notify=true

sudo pcs resource config drbd_r0
sudo pcs status --full

최근 Pacemaker는 Master/Slave 대신 Promoted/Unpromoted 용어를 사용합니다. promoted-max=1은 한 시점에 하나만 Primary가 되도록 제한합니다. 리소스 이름과 clone 이름은 pcs 버전이 생성한 결과를 확인해 다음 제약 명령에 정확히 사용하십시오.

Filesystem·VIP·서비스 그룹

sudo pcs resource create fs_data ocf:heartbeat:Filesystem   device=/dev/drbd0 directory=/srv/ha-data fstype=xfs   op monitor interval=20s timeout=40s

sudo pcs resource create vip_app ocf:heartbeat:IPaddr2   ip=192.0.2.50 cidr_netmask=24   op monitor interval=20s

sudo pcs resource create app_service systemd:myapp   op monitor interval=20s timeout=40s

sudo pcs resource group add app_group fs_data vip_app app_service

myapp 서비스는 cluster 밖에서 자동 시작되지 않도록 양쪽 노드의 systemd enable 정책을 정리합니다. IP 주소, interface, Filesystem agent 옵션과 서비스 timeout은 실제 환경에 맞춰야 합니다. XFS는 한 노드에서만 마운트하는 단일 writer 파일시스템이며 dual-primary 예제로 확장하지 않습니다.

순서와 colocation 제약

# 실제 생성된 promotable clone 이름을 pcs status/config에서 확인해 사용
sudo pcs constraint order   promote drbd_r0-clone then start app_group

sudo pcs constraint colocation add   app_group with promoted drbd_r0-clone INFINITY

sudo pcs constraint config --full
sudo pcs status --full

order는 DRBD가 Promoted된 뒤 그룹을 시작하게 하고, colocation은 그룹을 그 Promoted 노드에 배치합니다. 그룹 내부는 Filesystem→VIP→서비스 순으로 시작하고 역순으로 정지합니다. 제약 이름과 역할 문법은 설치된 pcs 버전의 help와 생성된 CIB를 확인하십시오.

DRBD Pacemaker 상태와 데이터 검증

정상 상태 점검

sudo pcs status --full
sudo crm_mon -1Arf
sudo pcs resource config
sudo pcs constraint config --full
sudo drbdadm status r0 --verbose

findmnt /srv/ha-data
ip -brief address | grep '192.0.2.50'
curl --fail --silent --show-error http://192.0.2.50/healthz
검사 정상 기준 이상 시 우선 확인
DRBD role 한 노드 Promoted/Primary, 한 노드 Unpromoted/Secondary 수동 promote 흔적, 제약, agent 로그
disk state 양쪽 UpToDate 복제망, backing device, resync 진행률
Filesystem Promoted 노드 한 곳에만 mount colocation·order와 systemd 자동 mount
STONITH 두 노드가 peer를 실제 격리 가능 BMC 전원·권한·관리망·agent timeout
quorum 예상 vote와 qdevice 상태 정상 Corosync link, wait_for_all, 제3 투표
서비스 VIP와 health endpoint 응답 Filesystem 준비, app 로그, 방화벽

DRBD Pacemaker 장애 전환 시험

케이블을 무작정 뽑기 전에 정상적인 standby 전환으로 리소스 제약과 애플리케이션을 검증합니다. 그 뒤 승인된 시험 계획에 따라 서비스 프로세스 실패, 노드 종료, Corosync link 단절, 복제망 단절, BMC 실패를 각각 분리해 시험합니다.

sudo pcs node standby ha1.example.com
watch -n 2 sudo pcs status --full

curl --fail --silent --show-error http://192.0.2.50/healthz
ssh ha2.example.com 'findmnt /srv/ha-data; sudo drbdadm status r0'

sudo pcs node unstandby ha1.example.com
sudo pcs status --full

Pacemaker가 리소스를 관리하기 시작한 뒤에는 수동 drbdadm primary, mount, systemctl start로 상태를 바꾸지 마십시오. 수동 조작은 CIB의 기대 상태와 실제 상태를 갈라놓습니다. 유지보수는 standby 또는 maintenance mode 절차를 사용하고 완료 후 모든 리소스의 관리 상태를 확인합니다.

DRBD Pacemaker split brain 대응

  1. 서비스와 자동 복구를 멈추고 두 노드가 동시에 데이터를 쓰지 못하게 물리적으로 격리합니다.
  2. DRBD role·disk state, Pacemaker·Corosync·fence 로그와 마지막 정상 백업 시점을 보존합니다.
  3. 애플리케이션 담당자와 어느 데이터가 정본인지 트랜잭션 기준으로 결정합니다.
  4. LINBIT 공식 split-brain 절차에서 선택한 피해 노드만 discard하도록 두 사람이 검토합니다.
  5. 재동기화 뒤 파일시스템 검사, 데이터 정합성, 서비스 기능과 백업을 확인합니다.
  6. 복제망·quorum·STONITH·제약의 근본 원인을 수정하고 동일 장애 시험을 반복합니다.
split brain 복구의 discard-my-data 명령은 한쪽 데이터 전체를 버릴 수 있어 이 글에 복사 실행 예제를 제공하지 않습니다. 정본 선택과 백업 없이는 진행하지 말고 사용 중인 DRBD 9 공식 문서와 지원 절차를 따르십시오.

증거 수집 명령

sudo drbdadm status r0 --verbose
sudo drbdsetup status --statistics
sudo pcs status --full
sudo crm_mon -1Arf
sudo corosync-cfgtool -s
sudo pcs quorum status

sudo journalctl -u drbd -u pacemaker -u corosync   --since '-30 min' --no-pager

DRBD Pacemaker 운영 체크리스트

  • CentOS 7 예제를 제거하고 지원되는 OS·DRBD·Pacemaker 조합을 고정했습니다.
  • backing device를 serial·WWID로 확인하고 파괴적 초기화 전 이중 검토했습니다.
  • 복제망, Corosync, 서비스망과 BMC 펜싱망의 장애 도메인을 분리했습니다.
  • STONITH를 실제로 시험했으며 stonith-enabled를 끄지 않았습니다.
  • DRBD는 promoted-max=1이고 XFS는 Promoted 노드 한 곳에서만 마운트됩니다.
  • Filesystem·VIP·서비스 그룹의 order와 colocation 제약을 검증했습니다.
  • standby·노드 종료·링크 단절·fence 실패의 예상 결과와 RTO를 기록했습니다.
  • DRBD와 별도의 버전형 백업을 만들고 격리 환경에서 복원했습니다.

DRBD Pacemaker 공식 문서와 관련 글

정리

DRBD Pacemaker: 2노드 HA의 핵심은 서비스를 빨리 다시 띄우는 것이 아니라 이전 소유자가 확실히 격리된 뒤 올바른 데이터를 한 곳에서만 쓰게 하는 것입니다. Protocol C와 Promoted 단일 역할, 실제 동작하는 STONITH, quorum 판단, Filesystem·VIP·서비스 제약을 함께 검증하십시오. 복제는 백업이 아니므로 장애 시험과 별도 복원 테스트까지 완료해야 운영 가능한 고가용성 구성이 됩니다.