-
[CentOS 7] 스토리지 서버의 다중화 (DRBD로 미러링 구성)Linux/CentOS 2018. 3. 6. 12:41
스토리지 서버의 장애 대책
스토리지 서버에서 대량의 파일이 저장된다. 따라서, 하드디스크 고장에 의해 데이터가 손실되면 복구가 매우 어렵다. 복구작업은 백업을 리커버리하는 것이 일반적인 방법이지만, 모든 파일을 리커버리하기에는 대단히 많은 시간이 소요된다. 또한 스토리지 서버의 장애는 영향을 미치는 범위가 광범위할 경우가 많으므로 RAID를 이용해서 하드디스크 고장에 의해 데이터가 손실되지 않도록 구성하는 것이 일반적이다.
한편, 고장 나는 것은 하드디스크만이 아니다. 단일 RAID 컨트롤러가 고장 난경우, 운이 좋다면 예비 RAID컨트롤러와 교환하는 것만으로 복구할 수도 잇겠지만, 고장 난 순간에 하드디스크에 예기치 않는 데이터를 덮어써서 데이터가 손실될 위험성이 있다.
디스크에 비하면 고장빈도는 극히 낮지만, 이와 같은 장애에도 데이터를 보호하고 위해서는 스토리지 서버를 두 대 준비해서 다중화하는 것을 생각해볼 수 있다.
스토리지 서버의 동기화 문제
스토리지 서버를 다중화하려면 두 대의 서버에 데이터를 계속해서 동기화할 필요가 있다. 그 방법으로 최초에 생각한 것이 "데이터를 업로드할 때에는 반드시 양쪽서버에 업로드 한다."라는 운용 방안이다. 그러나, 계속해서 데이터의 정합성을 취하는 것은 의외로 어려운 것이다. 업로드 프로그램의 상태가 좋지 않아서 파일이 한쪽 서버에만 전송될 수도 있고, 작업 실수로 인해 한쪽 서버의 데이터만 갱신해버릴 수도 있을 것이다.
파일 개수가 적어서 데이터 양이 적다면 간단한 스크립트를 이용해 기계적으로 정합성을 체크할 수 있을 것이다. 그러나, 파일 개수가 수백 만개, 수천 만개 이상있고 데이터 크기가 수백GB에 달하는 데이터를 체크하기는 곤란하다. 정합성 체크를 할 수 없는 상황에서 운용 방안에 계속 의존해 동기화를 수행하는 것은 신뢰성 면에서는 큰 불안요소를 남기게 된다.
DRBD
두 대의 서버에 대해 파일 단위로 디스크를 동기화하거나 정합성 체크하면 파일 개수가 많아질수록 디렉토리 검색이나 비교에 시간이 오래 걸린다. 또한, 그런 경우에는 하드디스크에 과도한 부하가 걸리므로 서버 전체의 성능이 크게 저하된다. DRBD(Distributed Replicated Block Devie)라는 소프트웨어를 이용하면 이 문제를 해결할 수 있다.
DRBD는 고가용성 High Availablity, HA 클러스터를 구성할 때 유용한 블록 디바이스를 제공한다. 가능하면 전용 네트워크를 사용해서 두 대의 컴퓨터의 블록 디바이스 간에 데이터를 미러링한다. 네트워크를 이용한 RAID 1이라 생각하면 알기 쉽다.
DRBD의 구성
DRBD는 그림과 같은 구조로 마스터 서버와 백업 서버가 있으며, 다음의 두 개로 구성되어 있다.
- 커널 모듈 (디바이스 드라이버)
- 유저랜드(userland) 툴 (제어 프로그램)
파일 단위로 데이터를 전송하는 것이 아니라 블록 디바이스에 대해 변경사항을 실시간으로 전송한다. 파일을 생성, 변경할 때 DRBD나 백업 서버의 존재를 의식할 필요는 없다.
DRBD의 미러링 Active, Backup 구성이다. Actvie측의 블록 디바이스에 대해서는 읽고 쓰기가 가능하나, Backup측의 블록 디바이스에는 접근할 수 없다. 다만, 버전 8.0.0이후에는 OCFS, GFS 등의 클러스터 파일시스템과의 조합에 의해 Active / Active 구성이 지원된다.
DRBD의 설정과 실행
123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051[root@mp3data02 etc]# cat /etc/drbd.conf# You can find an example in /usr/share/doc/drbd.../drbd.conf.exampleinclude "drbd.d/global_common.conf";include "drbd.d/*.res";[root@mp3data02 drbd.d]# cat r0.resresource r0 { # 리소스를 정의하는 블록, 여기서는 [r0]라는 이름의 리소를 정의하고 있다# DRBD devicedevice /dev/drbd0; # DRBD의 논리 블록 디바이스 지정한다. 여기 지정한 블록 디바이스에 대해 mkfs나 mount를 수행meta-disk internal; # 메타 데이터를 저장할 디바이스를 지정, internal을 지정한 경우 disk에 지정한 블록 디바이스 중 128MB를 메타 데이터용으로 확보on mp3data01.soribada.com { # 호스트마다 리소스를 정의하는 블록, unmae -n의 결과와 일치하는 여부로 자기 자신의 설정인지를 판단disk /dev/sdb1; # 미러링하고자 하는 물리 디바이스를 지정한다. 블록 디바이스이면 어떤 것이든 지정할 수 있지만, 루프백 디바이스를 지정하면 백업하게 되므로 주의 필요address 172.16.9.6:7766; # 데이터를 동기화하기 위해 수신 대기할 IP주소와 포트번호를 지정한다. 포트 번호는 리소스마다 고유}on mp3data02.soribada.com {disk /dev/sdb1;address 172.16.9.7:7777;}}[root@mp3data02 drbd.d]# cat global_common.confglobal {usage-count yes;}common {protocol C;handlers {pri-on-incon-degr "/usr/lib/drbd/notify-pri-on-incon-degr.sh; /usr/lib/drbd/notify-emergency-reboot.sh; echo b > /proc/sysrq-trigger ; reboot -f";pri-lost-after-sb "/usr/lib/drbd/notify-pri-lost-after-sb.sh; /usr/lib/drbd/notify-emergency-reboot.sh; echo b > /proc/sysrq-trigger ; reboot -f";local-io-error "/usr/lib/drbd/notify-io-error.sh; /usr/lib/drbd/notify-emergency-shutdown.sh; echo o > /proc/sysrq-trigger ; halt -f";}startup {}disk {on-io-error detach;}net {}syncer {rate 300M;}}cs # protocal A, B, C TYPE 설정항목
- 데이터 전송 프로토콜을 지정한다. 지정할 수 있는 값은 A, B, C 세 가지로, 각각 다음과 같은 특징이 있다.
Protocol A : 로컬 디스크에 쓰기가 끝나고 TCP 버퍼에 데이터를 송신한 시점에서 쓰기작업 완료로 한다 (성능 중시하는 비동기 전송).
Protocol B : 로컬 디스크에 쓰기가 끝나고 원격 호스트로 데이터가 도달한 시점에서 쓰기작업 완료로 한다. (A와 C의 중간)
Protocol C : 원격 호스트의 디스크에도 쓰기가 완료된 시점에서 쓰기작업 완료로 한다. (신뢰성을 중시하는 동기 전송)
마스터 서버에서 DRBD 실행하기
DRBD를 실행해보면, 우선은 마스터 서버상에서 다음과 같이 작업한다.
1234567891011121314151617181. DRBD를 실행한다.ws1:~# /etc/init.d/drbd startDRBD's startup script waits for the peer node(s) to appear.- In case this node was already a degraded cluster before thereboot the timeout is 0 seconds. [degr-wfc-timeout]- If the peer was available before the reboot the timeout willexpire after 0 seconds. [wfc-timeout](These values are for resource 'r0'; 0 sec -> wait forever)'To abort waiting enter 'yes' [ 17]: yes2. primary 상태로 한다.ws1:~# drbdadm -- --do-what-I-say primary all3. /dev/drbd0에 파일시스템을 만든다.ws1:~# drbdadm -- -O primary all4. /dev/drbd0을 /mnt/drbd0으로 마운트한다.ws1:~# mkfs /dev/drbd0cs DRBD를 실행하면 우선은 미러링 대상에 접속을 시도한다. 그러나, 최초 셋업할때는 대상이 없기 때문에 [To abort waiting enter 'yes']라는 메시지가 나오면 타임아웃 대기상태가 되므로 [yes]라고 입력하고 중단한다. 또한, 실행 직후의 DRBD는 [secondary 상태]로 되어 있다. 이는 primary 상태인 DRBD로부터 데이터가 들어올 때까지 대기하고 있는 상태로, 이 상태에서는 블록 디바이스에 대해 읽고 쓰기를 할 수 없다.
파일시스템을 만들고 마운트하기 위해서는 drbdadm 명령으로 [primary 상태]로 전환할 필요가 있다. primary 상태로 전환하려면 drbdadm의 primary 명령을 사용하지만, 지금과 같이 초기 구축시에 한해서는 0.7계열에서 -do-what-I-say옵션, 8.2계열에서는 -o 옵션을 붙여야 한다. primary 상태로 전환되면 /dev/drbd0를 /dev/sdb1과 동일하기 다룰 수 있게 된다.
백업 서버에서 DRBD 실행하기
마찬가지로 백업 서버에서 DRBD를 실행한다. 그러면 마스터 서버로부터 백업서버로 동기화가 진행된다. 동기화가 끝나면 셋업 완료된다. 마스터 서버의 /mnt/drbd0/에 파일을 만들어서 데이터를 쓰면 백업 서버에도 그대로 전송된다.
12345678910ws1:~# /etc/init.d/drbd startStarting DRBD resources: [ d0 s0 n0].ws1:~# /proc/drbdopversion:0.7.25 (api:79/proto:86-97)GIT-hash: 0ce4d235fc02b5c53c1c52c53433d11a694eab8c build by root@ws20: cs:SyncTarget st:Secondary/Secondary id:Inconsistentns:0 nr:528 dw:0 dr:0 al:14 bm:62 lo:9 pe:78 ua:64 ap:0[==================>.] sync'ed: 97.3% (31424/1048508)Kfinish: 0:00:01 speed: 21,240 (15,644) K/seccs DRBD의 장애극복
DRBD는 마스터 서버에 문제가 발생하더라도 백업 서버가 자동적으로 마스터 서버가 되지는 않는다. 따라서 keepalived를 이용해서 장애극복할 수 있도록 한다.
수동으로 전환하기
자동으로 장애극복하기 전에 우선은 수동으로 전환해보자. 장애극복을 위해서는 마스터 서버의 DRBD를 secondary 상태로 한다. 그러나 블록 디바이스가 마운트되어 있으면 실패하므로 NFS 서버를 정지해서 언마운트해둔다. 이 작업을 스크립트로 만든다. 이를 /usr/local/sbin/drbd-backup으로 양쪽 서버에 저장한다.
12345drbd-backup#!/bin/bash/etc/init.d/nfs-kernel-server stopumount /mnt/drbd0drbdadm secondary allcs 백업 서버를 마스터 서버로 할 경우는 DRBD를 primary 상태로 하고 블록 디바이스를 마운트해서 NFS서버를 실행한다. 이를 스크립트로 만든 것이 아래와 같다. /usr/local/sbin/drbd-master로 양쪽 서버에 저장한다.
123456drbd-master#!/bin/bashdrbdadm primary allmount /dev/drbd0 /mnt/drbd0/etc/init.d/nfs-kernel-server startcs 데이터가 동기화되어 있음을 확인하기 쉽게 하기 위해 마스터 서버의 /mnt/drbd0에 적당한 파일을 만들어준다. 다음으로 마스터 서버에서 drbd-backup명령을 실행해서 양쪽 서버를 secondary 상태로 한다. 그리고 나서 백업 서버에서 drbd-master 명령을 실행하면 primary 상태로 전이되면서 /dev/drbd0이 /mnt/drbd0/에 마운트 된다.
거기에는 좀 전에 마스터 서버에 임의로 생성해둔 파일이 있을 것이다. 마스터 서버에 장애가 발생했을 때, 이러한 일련의 작업이 자동적으로 실행되도록 하면 장애 극복을 할 수 있다. 계속해서 deepalive의 VRRP기능과 조합해서 NFS서버를 다중화하는 방법도 생각해보자.
'Linux > CentOS' 카테고리의 다른 글
[CentOS 7] Tomcat 서버 (1) 2018.04.20 [CentOS 7] VSFTP 서버 (0) 2018.04.04 [CentOS 7] NFS 서버 (0) 2017.12.02 [CentOS 7] Nagios 서버 (0) 2017.10.31 [CentOS 7] Apache 웹 서버 " 2 " (2) 2017.10.26