Source: Dev.to

요약

TL;DR: Pacemaker의 기본 자동 복구(autofailback) 동작은 복구 중인 노드에서 조기 승격을 시도함으로써 활성 DRBD 프라이머리를 방해할 수 있으며, 이는 서비스 중단 및 데이터 위험을 초래할 수 있습니다. 이 문제는 다음과 같이 예방할 수 있습니다:

• DRBD 마스터/슬레이브 클론 리소스에 negative resource stickiness(예: -10000)를 설정합니다.
• manual failback(대기 모드 또는 위치 제약)을 구현합니다.
• 견고한 STONITH, 증가된 cluster-delay, 충분한 promoted-stop-timeout 값을 사용하여 graceful, delayed promotion을 설정합니다.

왜 이런 일이 발생하는가

Pacemaker/DRBD 클러스터는 고가용성을 제공하지만, 기본 동작은 해당 노드가 복구되자마자 리소스를 선호 노드로 “다시 이동”시키려 합니다. DRBD 환경에서는 이것이 치명적인 결과를 초래할 수 있습니다:

Example Pacemaker Log Snippet

Sep 20 10:35:01 node-a pacemakerd[12345]: info: Status: Requesting promote of drbd_res on node-a
Sep 20 10:35:01 node-a pacemakerd[12345]: crit: Result: promote_drbd_res_on_node-a: CIB_R_ERR_OP_FAILED
Sep 20 10:35:01 node-b pacemakerd[12345]: info: Status: Requesting demote of drbd_res on node-b
Sep 20 10:35:01 node-b pacemakerd[12345]: info: drbd_demote: stdout [drbd_demote: Attempting to demote resource 'r0']
Sep 20 10:35:02 node-b pacemakerd[12345]: warn: drbd_demote: stderr [drbd_demote: Cannot demote 'r0', it is still in use.]
Sep 20 10:35:02 node-b pacemakerd[12345]: crit: Result: demote_drbd_res_on_node-b: CIB_R_ERR_OP_FAILED

문제 발생 중 drbd-overview를 실행하면 예상치 못한 역할이나 연결이 표시됩니다.

예시 drbd-overview 충돌 시 출력

0:r0   Connected Primary/Primary UpToDate/UpToDate
       [WARNING: This indicates split‑brain in a two‑node cluster, which Pacemaker should prevent]
       [More likely, you'll see a quick flip or errors.]

핵심 문제

1. 리소스 로컬리티 선호 – Pacemaker는 리소스를 “선호하는” 노드에 유지하려고 합니다. 노드가 복구되면 Pacemaker는 해당 노드를 다시 적합한 후보로 간주합니다.
2. DRBD 기본(primary) 요구사항 – 두 노드 동기식(Protocol C) DRBD 설정에서는 한 번에 하나의 노드만 Primary가 될 수 있습니다.
3. 조기 승격 시도 – Pacemaker는 현재 primary를 안전하게 강등시키기 전에 복구 중인 노드에서 DRBD 리소스를 즉시 승격하려 할 수 있습니다.
4. 결과적인 충돌 – 이는 다음과 같은 상황을 초래할 수 있습니다:
   • 승격 실패 (RA가 다른 primary를 감지한 경우).
   • 두 노드가 잠시 서로를 primary라고 생각하는 경쟁 조건.
   • DRBD 내부 충돌 해결(자동 강등 또는 펜싱)으로 인해 I/O 중단 및 애플리케이션 실패가 발생할 수 있습니다.

솔루션

1. 부정적인 리소스 스틱니스

# Example: set a very high negative stickiness on the DRBD clone
pcs resource defaults resource-stickiness=-10000

• Pacemaker가 DRBD 리소스를 자동으로 복구(fail back)하지 않도록 보장합니다.
• 관리자가 수동으로 이동시키기 전까지 리소스는 현재 프라이머리 노드에 남아 있습니다.

2. 수동 페일백 전략

| **명시적 이동** | 프로모션 준비가 되면 `pcs resource move drbd_res <node>`를 사용합니다. |

### 3. 부드럽고 지연된 프로모션  

1. **견고한 STONITH** – 펜싱이 신뢰성 있게 동작하도록 보장합니다; 그렇지 않으면 Pacemaker가 안전한 다운그레이드를 건너뛸 수 있습니다.  
2. **`cluster-delay` 증가** – 클러스터가 상태 변화를 전파할 시간을 더 많이 확보합니다.  

   ```bash
   pcs property set cluster-delay=30s

3. 관대한 promoted-stop-timeout 설정 – 이전 프라이머리가 다운그레이드를 깔끔히 마칠 수 있게 합니다.

   pcs resource update drbd_res meta promoted-stop-timeout=120s

4. 옵션: migration-threshold – 빠른 왕복 이동을 방지합니다.

   pcs resource defaults migration-threshold=3

안전한 DRBD‑Pacemaker 클러스터 체크리스트

• 모든 노드에서 STONITH이 구성되고 테스트됨.
• DRBD 리소스에 Negative stickiness(또는 동등한 위치 제약) 적용.
• 워크로드에 맞게 Cluster‑delay 및 promoted‑stop‑timeout 값 조정.
• 모니터링(예: pcs status, drbd-overview, Pacemaker 로그) 설정하여 승격/강등 이벤트 알림.
• 운영자를 위한 수동 복구 절차 문서화.

TL;DR (재진술)

높은 음수 resource-stickiness를 설정하거나 위치 제약을 사용하여 자동 복구(failback)를 방지합니다.
주(primary)를 이동해야 할 경우, 수동으로 수행합니다(standby, pcs resource move, 또는 명시적 위치 규칙).
자동 복구를 원한다면 STONITH이 정상 작동하는지 확인하고, cluster-delay를 늘리며, promoted-stop-timeout을 증가시켜 기존 주가 새 주가 승격되기 전에 깔끔하게 다운그레이드될 수 있도록 합니다.

이 단계들을 따르면 “kill” 상황을 피하고 DRBD 리소스를 안정적으로 유지하며 서비스의 진정한 고가용성을 보장할 수 있습니다.

DRBD 노드가 복구될 때 “kill” 시나리오 방지

이전에 Primary였던 노드가 다른 노드가 이미 Primary 역할을 하고 있는 상태에서 온라인으로 복구되면, Pacemaker가 복구된 노드를 다시 승격시키려고 할 수 있습니다. 승격을 깔끔하게 수행하지 못하면 현재 활성 노드가 역할에서 강제로 빠져나가 서비스가 비정상적으로 종료됩니다(소위 kill 현상).

일반적인 원인

• 우아한 다운그레이드 부족 – Pacemaker가 현재 Primary를 다운그레이드할 충분한 시간이나 명확한 명령을 받지 못하고, 복구된 노드가 스스로를 주장합니다.
• 불충분하거나 느린 펜싱(STONITH) – 클러스터가 실패한 노드를 신뢰성 있게 격리하지 못합니다.

아래는 클러스터 가용성을 유지하면서 이 상황을 피할 수 있는 세 가지 검증된 방법입니다.

1️⃣ Primary “Sticky” 유지 (Negative Resource‑Stickiness)

아이디어 – 관리자가 수동으로 이동시키는 경우를 제외하고, 복구된 노드에 DRBD 리소스를 다시 이동시키지 않도록 Pacemaker에 지시합니다.

작동 방식

• DRBD 클론에 큰 음수 resource-stickiness 값을 설정하면 현재 Primary가 “sticky” 상태가 됩니다.
• 선택적으로 현재 Primary를 이미 보유하고 있는 노드를 선호하도록 위치 제약을 추가합니다.

예시 구성

# 1. DRBD Master/Slave 리소스 정의 (예시)
pcs resource create drbd_r0 ocf:linbit:drbd \
    drbd_resource=r0 \
    op monitor interval="60s" \
    op promote interval="30s" start-timeout="90s" stop-timeout="90s" \
    op demote interval="30s" start-timeout="90s" stop-timeout="90s" \
    --clone globally-unique=true ordered=true interleave=true

# 2. 큰 음수 stickiness 지정 → 자동 페일백 비활성화
pcs resource meta drbd_r0-clone resource-stickiness=-10000

# 3. drbd_r0가 Primary일 때만 동작하는 파일시스템 리소스
pcs resource create fs_data ocf:heartbeat:Filesystem \
    device="/dev/drbd/by-res/r0" directory="/mnt/data" fstype="ext4" \
    op monitor interval="30s"

# 4. drbd_r0-clone이 승격된 상태일 때만 fs_data가 실행되도록 보장
pcs constraint colocation add fs_data with drbd_r0-clone INFINITY target-role=Promoted

# 5. 순서 보장: 먼저 DRBD를 승격하고, 그 다음 파일시스템을 시작
pcs constraint order promote drbd_r0-clone then start fs_data

2️⃣ 복구된 노드를 Standby(유지보수 모드)로 전환

아이디어 – 복구된 노드에 리소스가 시작되는 것을 방지해, 승격하기 전에 해당 노드의 상태를 확인할 시간을 확보합니다.

단계

# 관리 워크스테이션(또는 클러스터 노드)에서 실행
pcs node standby <node>

• 노드는 standby 상태를 유지하며, Pacemaker는 해당 노드에 리소스를 스케줄링하지 않습니다.
• 확인이 끝나면 다음과 같이 복구합니다:

pcs node unstandby <node>

• 이후 필요에 따라 DRBD 리소스를 수동으로 이동시켜 페일백을 수행합니다.

3️⃣ Location Constraint를 사용해 복구 시 승격 차단

아이디어 – 복구된 노드에 Promoted 역할에 대해 매우 낮은 점수(또는 -INFINITY)를 부여해, Pacemaker가 해당 노드에서 DRBD 리소스를 자동으로 승격하지 못하도록 합니다.

예시

# node‑a가 선호되는 primary라고 가정합니다.
# node‑a가 복구될 때 drbd_r0를 승격하지 않도록 설정합니다.

# Promoted 역할에 대해 다른 노드(node‑b)를 선호하도록 지정
pcs constraint location drbd

_r0-clone prefers=node-b=100 target-role=Promoted

Explicitly avoid the recovering node for promotion

pcs constraint location drbd_r0-clone avoids=node-a=-INFINITY target-role=Promoted

* You can combine this with the negative stickiness from Solution 1 for extra safety.

| Pros | Cons |
|------|------|
| Provides fine‑grained control without putting the whole node in standby. | Still requires manual intervention to perform a fail‑back. |
| Prevents automatic promotion, thus avoiding split‑brain. | Slightly more complex to maintain the constraints. |
| Works together with stickiness for a “double‑lock”. | May need adjustments if the cluster topology changes. |

Korean Translation

_r0-clone prefers=node-b=100 target-role=Promoted

승격을 위해 복구 중인 노드 회피하기

pcs constraint location drbd_r0-clone avoids=node-a=-INFINITY target-role=Promoted

* 이 방법을 솔루션 1의 음수 스틱니스와 결합하면 추가적인 안전성을 확보할 수 있습니다.

| 장점 | 단점 |
|------|------|
| 전체 노드를 대기 상태로 전환하지 않고도 세밀한 제어를 제공합니다. | 여전히 장애 복구를 위해 수동 개입이 필요합니다. |
| 자동 승격을 방지하여 분할 브레인을 피합니다. | 제약 조건을 유지 관리하는 것이 다소 복잡합니다. |
| 스틱니스와 함께 작동하여 “이중 잠금”을 구현합니다. | 클러스터 토폴로지가 변경될 경우 조정이 필요할 수 있습니다. |

📋 요약

세 가지 접근 방식 모두 동일한 목표를 달성합니다: 복구 중인 노드가 명시적인 관리자의 승인 없이 DRBD 리소스를 자동으로 승격하지 않도록. 운영 워크플로우와 원하는 자동화 수준에 가장 잘 맞는 방식을 선택하십시오.

Source: …

솔루션 개요

이 솔루션은 여러 Pacemaker 전역 옵션과 리소스 메타‑속성을 활용하여 DRBD 기본 역할을 순차적이고 제어된 전환이 이루어지도록 합니다. 주요 요소는 다음과 같습니다.

• 견고한 펜싱(STONITH)
• 상태 전파를 위한 cluster-delay 증가
• 리소스 동작에 대한 세심한 타임아웃 설정

1. 견고한 펜싱(STONITH) 보장

왜?
Pacemaker가 실패한 노드를 신뢰성 있게 펜싱하지 못하면, 어떤 복구‑복귀 전략도 안전하지 않습니다.

# 전역적으로 STONITH 활성화
pcs property set stonith-enabled=true

# 쿼럼 정책 정의 (필요에 따라 stop 또는 freeze 선택)
pcs property set no-quorum-policy=stop   # 또는 'freeze'

# STONITH 장치 생성 (예: fence_ipmi 사용)
pcs stonith create fence_ipmi_node1 fence_ipmi \
    ipaddr=192.168.1.10 pcmk_host_list=node-a \
    login=admin passwd=password \
    op monitor interval=60s

pcs stonith create fence_ipmi_node2 fence_ipmi \
    ipaddr=192.168.1.11 pcmk_host_list=node-b \
    login=admin passwd=password \
    op monitor interval=60s

2. cluster-delay 증가

Pacemaker가 상태 변화를 전파할 시간을 더 확보하고, 조기 판단을 방지합니다.

pcs property set cluster-delay=60s

이 설정은 노드가 가입하거나 떠난 후 60 초 동안 중요한 리소스 배치 결정을 내리지 않도록 Pacemaker에 지시합니다.

3. DRBD 타임아웃 구성

pcs resource update drbd_r0-clone \
    op demote timeout="120s" promoted-stop-timeout="180s" \
    op stop timeout="120s" \
    meta stop-failure-is-fatal=false

4. 선택 사항: 선호 노드에 대한 리소스 스틱니스

선호 노드로 우아한 자동 복구‑복귀를 원한다면, 약간의 양의 스틱니스 또는 위치 규칙을 추가할 수 있지만, 위에서 설정한 보호 장치들이 적용되어 있는지 확인하십시오.