DRBD는 두 서버의 블록 장치를 네트워크로 복제합니다. 기본 단일 Primary 모드에서는 Primary만 파일시스템을 마운트해 읽고 쓸 수 있고, Secondary는 변경된 블록을 복제받습니다.
아래는 node1(10.10.10.11)과 node2(10.10.10.12)의 비어 있는 /dev/sdb1을 DRBD 9로 묶는 예시입니다. 장치 안의 기존 데이터는 손상될 수 있으므로 대상 장치를 반드시 다시 확인하세요.
패키지와 사전 조건
배포판 저장소 또는 LINBIT 저장소에서 DRBD 9 커널 모듈과 관리 도구를 설치합니다. 패키지명은 배포판마다 다르므로 설치 후 실제 버전을 확인합니다.
modprobe drbd
drbdadm --version
lsblk -f두 노드의 hostname이 각각 node1, node2로 해석돼야 하며 TCP 7789 통신이 허용돼야 합니다. /dev/sdb1은 마운트하거나 파일시스템을 미리 만들지 않습니다.
리소스 설정
두 노드에 동일한 /etc/drbd.d/data.res를 만듭니다.
resource data {
net {
protocol C;
}
on node1 {
device /dev/drbd0;
disk /dev/sdb1;
address 10.10.10.11:7789;
meta-disk internal;
}
on node2 {
device /dev/drbd0;
disk /dev/sdb1;
address 10.10.10.12:7789;
meta-disk internal;
}
}Protocol C는 로컬과 원격 디스크 쓰기가 모두 끝난 뒤 완료를 반환합니다. 지연은 늘지만 동기 복제가 필요한 HA 구성에 적합합니다.
메타데이터 생성과 최초 동기화
두 노드에서 설정을 검사하고 리소스를 올립니다.
drbdadm dump data
drbdadm create-md data
drbdadm up data
drbdadm status data초기 데이터의 기준이 될 node1에서만 Primary로 강제 승격합니다. 새 디스크임을 확인하지 않고 이 명령을 실행하면 잘못된 노드가 동기화 원본이 될 수 있습니다.
drbdadm primary --force data
mkfs.ext4 /dev/drbd0
mkdir -p /srv/data
mount /dev/drbd0 /srv/data테스트 파일을 만든 뒤 drbdadm status data에서 연결 상태와 동기화 진행률을 확인합니다.
수동 장애 전환
정상 전환은 애플리케이션을 먼저 중지하고 기존 Primary를 내린 다음 진행합니다.
# 기존 Primary
systemctl stop [application]
umount /srv/data
drbdadm secondary data
# 기존 Secondary
drbdadm primary data
mount /dev/drbd0 /srv/data
systemctl start [application]두 노드를 동시에 Primary로 만들면 파일시스템이 손상될 수 있습니다. 강제 승격 전에 반대편 노드가 확실히 내려갔는지 확인하고, 운영 자동화에는 Pacemaker나 DRBD Reactor 같은 클러스터 관리자를 사용해야 합니다.
확인할 운영 항목
- 복제망 단절 후 재동기화가 완료되는가
- Primary 장애 시 애플리케이션과 마운트가 올바른 순서로 이동하는가
- split-brain 감지와 복구 절차가 문서화돼 있는가
- DRBD 복제와 별개로 외부 백업이 존재하는가
DRBD는 가용성을 높이는 복제 수단이지 백업을 대신하지 않습니다. 실수로 삭제한 블록도 즉시 복제된다는 점을 기억해야 합니다.