Versions Compared

Old Version 84

changes.mady.by.user SungEun Kim

Saved on

compared with

New Version Current

changes.mady.by.user SungEun Kim

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Table of Contents
maxLevel7
minLevel1

리소스를 생성하고 삭제하기 까지의 전반적인 관리작업과 구성파일의 주요 설정에 대해 설명합니다.

...

리소스 생성은 앞 절에서 설명한 리소스 구성파일을 준비하는 작업입니다. 구성파일을 작성했다면 리소스를 생성한 것으로 간주합니다. bsr 에서는 이 과정을 사용자가 수작업으로 수행해야 하며 이를 위한 별도의 CLI 나 API 는 제공 되지 않습니다.

한 번 구성파일을 작성하여 리소스가 생성되면 구성파일이 삭제 되기 전 까지는 해당 리소스가 생성된 상태로 계속 유지되고, 구성파일을 삭제해야 만 노드 상의 리소스를 완전히 삭제할 수 있습니다.

메타 초기화

리소스가 생성되면 최초 기동을 위해 메타디스크를 초기화 해야 합니다. 메타 디스크의 초기화는 다음의 명령으로 수행합니다.

...

구성항목에 맞게 준비하고 메타를 초기화하면 리소스가 생성된 것으로 간주합니다.

메타 초기화

리소스를 생성하기 위해 다음의 명령으로 메타 초기화를 수행합니다.

Code Block
>bsradm create-md r0
initializing activity log
NOT initializing bitmap
Writing meta data...
New bsr meta data block successfully created.

메타초기화는 복제를 위해 필요한 부가 정보들을 메타디스크 상에서 초기화하는 작업으로 리소스를 최초 기동하기 전 한번 만 수행하면 됩니다. 만일 메타를 초기화 하지 않고 리소스를 기동할 경우 비정상적인 운영상황이 되므로 주의해야 합니다.메타초기화가 완료되면

한 번 구성파일을 작성하면 구성파일이 삭제 되기 전 까지는 해당 리소스의 구성 상태가 계속 유지되고, 구성파일을 삭제해야 만 노드 상의 리소스를 완전히 삭제할 수 있습니다.

메타초기화가 되면 리소스를 기동할 준비가 된 상태 입니다.

리소스 기동

...

Info

마운트 동작 관련

마운트 동작에 대한 Windows 와 Linux OS 간 차이가 있습니다. 리눅스에선 볼륨을 사용하기 위한 마운트 과정이 수동으로 요구되지만볼륨 마운트를 직접 수행해 주어야 하지만, 윈도우즈 환경에선 볼륨에 대한 마운트가 운영체제의 쉘 운영체제 수준에서 자동으로 수행되기 때문에 별도의 마운트 명령 작업이 필요치 않습니다. 따라서 리눅스에선 리눅스에서는 승격 후 볼륨을 사용하기 위한 마운트 동작이 추가로 필요합니다마운트를 추가로 수행해 주어야 합니다.

강등

Primary 역할에서 Secondary 역할로 전환하는 것을 강등이라고 합니다.

Code Block
bsradm secondary <resource>
리눅스의 경우 강등을 수행하기 전 볼륨에 대한 마운트
Info
Note

  • bsr 은 파일시스템의 무결성 검사(fsck)을 수행하여 만약 파일시스템이 깨져 있다면 초기동기화를 실패 처리합니다. 깨진 파일시스템을 수동으로 복구한 후 리소스 초기화를 다시 시도해야 합니다.

    • bsr의 Fastsync는 유효한 파일시스템의 정보를 기반으로 하기 때문에 초기동기화 전 파일시스템 무결성 검사를 필수적으로 수행해야 합니다.

  • 복제 볼륨이 TB 급 이상의 대용량일 경우 파일시스템 검사 시간이 오래 걸리면 초기동기화의 무결성 검사 단계에서 시간초과가 발생할 수 있습니다. 용량 큰 볼륨은 그만큼 무결성 검사 시간이 오래 걸리기 때문입니다. 이럴 경우 파일시스템 검사는 별도로 수행하고 bsradm --force primary 명령에서 파일시스템 검사를 건너띄는 --skip-check-fs 옵션의 사용을 고려하십시오.

강등

Primary 역할에서 Secondary 역할로 전환하는 것을 강등이라고 합니다.

Code Block
bsradm secondary <resource>
Info

리눅스의 경우 강등을 수행하기 전 볼륨에 대한 마운트 해제의 과정이 요구됩니다. 윈도우즈 환경에선 강등명령 내부적으로 마운트 해제를 선 수행하기 때문에 별도의 마운트 해제 과정이 필요치 않습니다.

...

Info

수동절체

수동 절체를 위한 절차는 다음과 같습니다.

  1. primary 노드에서 bsr 디바이스를 사용하는 모든 응용 프로그램이나 서비스를 중지하고, (리눅스에선 볼륨을 umount 한 후) 리소스를 secondary로 강등시킵니다.

    Code Block
    bsradm secondary <resource>

  2. primary로 승격시키고자 하는 노드에서 다음 명령을 실행합니다. (리눅스에선 볼륨을 mount 하여) 서비스를 재개합니다.

    Code Block
    bsradm primary <resource>

리소스 중지

bsradm down 명령을 통해 리소스를 중지할 수 있습니다. down 은 리소스 앞서 설명한 리소스 up 과정의 역순에 따라 중지가 수행하고 만약 리소스가 승격된 상태 였다면 강등을 먼저 수행합니다수행하고 중지합니다. 즉 리소스 강등, 복제 단절, 볼륨 분리(detach), 리소스 해제의 순으로 down 합니다.

...

Info

bsr 에선 운영 중인 리소스의 볼륨 분리는 장애로 직결되기 때문에 위험한 동작으로 간주하고 있으며 Primary 리소스의 볼륨 detach 를 코드 수준에서 제거하였습니다. 물론 Secondary 리소스의 볼륨 분리는 허용합니다.

...

해제

리소스를 위해 할당 했던 메모리 자원들을 해제합니다.

...

속성 설정

동적 설정

bsr 의 리소스 속성들은 기본적으로 운영 중 (런타임) 설정 변경을 지원합니다. 이것을 동적 설정 (변경)이라고 합니다. 그러나 이러한 속성들 중 일부 필수 속성들은 동적 설정을 지원하지 않으며 구성파일의 설정을 변경한 후 리소스를 재기동하여 적용하는 정적 방식으로 재구성해야 합니다. 즉 정적 설정의 경우 리소스 재기동이 필요합니다.

동적 설정

구성파일을 변경하고 구성파일을 변경해서 bsradm adjust 명령을 통해 실시간 변경합니다. 복제 프로토콜 변경 등 일부 특수 설정을 제외한 대부분의 속성은 이 방식으로 설정을 즉시 변경할 수 있습니다. 복제 프로토콜을 운영 중 변경하기 위해선 다음의 내용을 참고하세요.

Info

운영 중 복제 프로토콜 변경

운영 중 복제 프로토콜을 변경하기 위해서 프로토콜, 송신버퍼, 혼잡제어 설정을 다 같이 변경해야 합니다.

  • 먼저 bsrsetup del-peer <resource> <node-<peer_node_id> 명령으로 peer 연결을 삭제합니다.

  • 양 노드 리소스 파일의 sndbuf-size 의 크기, 프로토콜, 혼잡제어 설정을 조정합니다.

  • bsradm adjust <resource> 로 적용합니다.

정적 설정

복제 구성을 위한 필수적인 필수 설정(노드 ID, 볼륨 정보 등)의 변경이 필요할 경우 리소스 down 을 선행한 후 설정을 변경해야 합니다. 구성파일을 변경한 후 다시 up 하여 리소스가 재시작되는 시점에 변경된 설정이 반영됩니다.들에 대해선 동적 설정을 지원하지 않습니다. 구성파일의 설정을 변경한 후 리소스를 재 기동하여 적용해야 합니다.

리소스 재구성

전체 재구성

디스크 파손 등 장애 복구가 필요하거나 필요에 따라 구성을 완전히 변경해야

...

하는 경우 리소스 전체를

...

재구성해야 합니다.

...

  • 먼저 운영 중인 리소스를 down 한 후 구성을 변경하고 구성파일을 변경합니다.

  • 메타 재 초기화를 수행하여 하고 리소스를 재 기동해야 재기동 합니다.

Info

Windows 의 경우 전체 재구성 과정에서 볼륨에 걸려있는 락을 해제해야 할 경우가 필요가 있습니다. 이럴 때에 bsrcon 유틸리티의 /m bsrcon의 /release_vol 옵션을 사용하여 볼륨락을 해제할 수 있습니다.

  • 메타 디스크를 초기화하면 볼륨에 대한 초기 동기화의 절차를 다시 수행해야 합니다.

볼륨 크기 조정

구성된 리소스의 볼륨은 운영상황에 따라 크기를 확장하거나 축소해야 할 경우가 생깁니다. 이를 위해서는 복제 볼륨의 크기를 조정하는 다음과 같은 별도의 방법을 사용해야 합니다. 볼륨 크기 조정은 플랫폼에 따라 차이가 있으며 온라인 볼륨 확장에 대해서 지원하고 볼륨 축소는 전체 재구성의 작업 절차를 따라야 합니다.

윈도우즈

...

  • 초기 동기화(강제 승격)의 절차를 다시 수행합니다.

Note

구성 해제 시 주의할 점

운영 노드의 볼륨을 다시 소스로 하여 재구성하게 될 경우라면 소스였던 볼륨을 그대로 사용하면 되므로 별 다르게 주의할 점은 없습니다.

그러나 타깃 측 볼륨을 소스로 재구성해야 할 경우에는 구성을 해제하기 전에 반드시 다음의 과정을 통해 타깃이 최신 데이터가 확보될 수 있도록 해야 합니다.

  • 복제 연결을 수립합니다.

    • 복제 연결이 해제된 경우 타깃이 UpToDate 또는 Outdate 인 경우가 있는데, 이 때 소스 측의 OOS 를 반영하지 않으면 이를 최신 데이터로 간주하면 안됩니다.

  • 연결 후 OOS가 있을 경우 자동 동기화 하고 동기화를 완료합니다.

  • 소스 측 리소스를 중지(down) 하고, down 이 완료되면 이 때 타깃 노드는 최신데이터가 확보된 상태 입니다.

  • 구성 해제 작업을 시작합니다.

볼륨 크기 조정

구성된 리소스의 볼륨은 운영상황에 따라 크기를 확장하거나 축소해야 할 수 있습니다. 이를 위해서 복제 볼륨의 크기를 조정하는 다음과 같은 절차를 수행해야 합니다. 크기 조정은 플랫폼에 따라 차이가 있으며 볼륨 확장은 서비스 운영 중에 가능하지만 볼륨 축소는 리소스 오프라인 후 전체 재구성 과정을 거쳐야 합니다.

윈도우즈

다음의 순서로 볼륨 크기를 조정합니다.

  1. 복제 연결을 끊고(disconnect) 양 노드를 Primary 상태로 만듭니다(Secondary 상태에선 볼륨이 잠겨있기 때문에 크기조정을 할 수 없습니다).

  2. 양 노드를 Primary 로 승격하면 복제 클러스터는 스플릿브레인 상태가 됩니다.

  3. 양 측 볼륨의 크기를 확장합니다.

  4. 원래 Secondary 였던 노드를 강등합니다.

  5. Secondary 노드를 희생노드로 하여 스플릿 브레인을 해결합니다.

이렇게 하면 전체 복제 볼륨의 크기가 늘어나고 새롭게 늘어난 크기의 볼륨 영역만큼 소스 기준으로 동기화가 되어 온라인 중 볼륨 확장이 가능해 집니다. 진행됩니다.

Note

  • 물론 늘어난 타깃의 볼륨 크기는

...

  • 소스의 크기와 같게 조정되어야 합니다.

...

info

  • 볼륨의 크기가 커지는 만큼 메타디스크의 크기도 자동으로 늘어나는데(볼륨 확장시점에 bsr 내부적으로 처리합니다), 필요한 용량만큼 여유 분이 확보되어 있지 않다면 볼륨확장이

실패하게 됩니다

  • 실패합니다. 따라서 온라인 볼륨 확장을 위해선 초기 리소스 구축과정에서 이를 염두에 두고 메타디스크 크기를 여유있게 산정할 필요가 있습니다.

리눅스

리눅스에서 온라인 볼륨 확장을 수행하려면 다음과 같은 조건을 충족해야 합니다. bsr의 블럭장치가 LVM 과

...

함께 구성되어 있어야

...

하며 소스와 타깃 노드는 복제 연결상태를 Connected 상태로 유지해야 합니다.

운영 노드를 Primary 상태로 두고 양 노드의 볼륨의 크기를 LVM을 통해 늘린 후 한 노드에서 다음과 같은 명령을 내려서 다음의 과정을 통해 새롭게 늘어난 크기를 bsr 에 인식시킵니다. 아래는 LV 로 구성된 580MB 크기로 구성된 볼륨을 확장하는 예 입니다.

  1. LV 구성. 기존 사이즈는 580M로 구성되어 있는 상태

    Code Block

...

bsradm resize <resource>

볼륨의 늘어난 영역에 대한 새로운 동기화가 진행됩니다.

리소스 삭제

구성파일을 삭제 함으로써 리소스가 삭제됩니다. 보통 운영 중일 경우에는 다음의 절차를 통해 리소스를 삭제 합니다.

  • 운영 중인 리소스를 down 합니다.

    • Windows 의 경우 bsrcon /m 을 통해 볼륨에 걸려있는 락을 해제 합니다.

  • 리소스 구성파일을 삭제 합니다.

조회

버전

bsradm /V 명령을 통해 bsr의 버전 정보를 확인합니다.

Code Block
[root@bsr-01 nglee]# bsradm -V
BSRADM_BUILDTAG=GIT-hash:3dca67e82d331e95121288a57898fcda13357e94 build by nglee@NGLEE-1,2020-01-29 13:50:48
BSRADM_API_VERSION=2
BSR_KERNEL_VERSION_CODE=0x000000
BSR_KERNEL_VERSION=0.0.0
BSRADM_VERSION_CODE=0x010600
BSRADM_VERSION=1.6.0-PREALPHA3

상태정보

기본적인 상태 정보를 출력합니다.

Code Block
>bsradm status r0
r0 role:Secondary
  disk:UpToDate
  nina role:Secondary
    disk:UpToDate
  nino role:Secondary
    disk:UpToDate
  nono connection:Connecting

상세 정보를 출력합니다.

...

  1. [root@bsr01 /]# lvs /dev/local/r0
  LV   VG     Attr       LSize   Pool Origin Data%  Meta%  Move Log Cpy%Sync 
Convert

...

  1.

...

  1.

...

  1.

...

  1.

...

  1.

...

  1.

...

  1.

...

  1.

...

  1.

...

  1.

...

  1.

...

  1.

...

  1.

...

  1.

...

  1. r0   local  -wi-ao---- 580.00m

...

성능지시자

  • sent (network send).  네트워크 연결을 통해 상대 노드에 전송된 네트워크 데이터의 양입니다. (Kibyte)

  • received (network receive). 네트워크 연결을 통해 상대 노드에서 수신된 네트워크 데이터의 양입니다. (Kibyte)

  • written (disk write). 로컬 하드 디스크에 기록된 넷 데이터입니다. (Kibyte)

  • read (disk read). 로컬 하드 디스크로부터 읽은 넷 데이터입니다. (Kibyte)

  • al-writes (activity log). 메타 데이터의 activity log 영역에 대한 업데이트 횟수입니다.

  • bm-writes (bit map). 메타 데이터의 비트맵 영역에 대한 업데이트 횟수입니다.

  • upper-pending (application pending I/O ). 상위에서 bsr 로 전달된 I/O 들 중 완료되지 못하고 bsr에서 처리중인 I/O 개수 .

  • lower-pending (subsystem open count). bsr에서 수행한 로컬 I/O sub-system에 대한 (close 되지 않은) open 횟수.

  • pending. 상대 노드에게 요청하였지만 응답(ack)받지 못한 요청 횟수입니다.

  • unacked (unacknowledged). 상대 노드에서 요청을 받았지만 응답(ack)해 주지 않은 요청 횟수입니다.

  • write-ordering (write order). 현재 사용하는 디스크 쓰기 방식을 나타냅니다.

  • out-of-sync.  현재 동기화가 이루어지지 않은 스토리지의 양을 나타냅니다. (Kibytes)

  • resync-suspended.  재 동기화 중단 여부. 가능한 값 은 no,user, peer, dependency

  • blocked. 로컬 I/O 혼잡상태 표시

    • no: 혼잡없음

    • upper: 상위 디바이스에서 혼잡발생

    • lower: 디스크 혼잡

  • congested. 이 플래그는 복제 연결상의 TCP 송신 버퍼가 80 % 이상 채워 졌는지 여부를 알려줍니다.

    • yes: 네트웍 혼잡

    • no: 혼잡없음

네트워크 연결상태를 출력합니다.

Code Block
C:\>bsradm cstate r0
Connected

연결상태

  • StandAlone. 리소스가 아직 연결되지 않았거나, 사용자가 bsradm disconnect를 사용하여 연결을 끊었거나, 인증 실패 또는 스플릿 브레인과 같은 이유로 연결이 끊어져 네트워크 구성이 가능하지 않은 상태입니다.

  • Disconnecting. 연결이 끊어지는 동안의 일시적인 상태입니다. 다음 상태: StandAlone

  • Unconnected. 연결을 시도하기 전의 일시적인 상태입니다. 다음 상태: Connecting 또는 Connected.

  • Timeout. 상대 노드와의 통신 시간 초과에 따른 일시적인 상태입니다. 다음 상태: Unconnected

  • BrokenPipe. 상대 노드와의 연결이 끊어진 후 일시적으로 표시되는 상태입니다. 다음 상태: Unconnected

  • NetworkFailure. 상대 노드와의 연결이 끊어진 후 일시적으로 표시되는 상태입니다. 다음 상태: Unconnected

  • ProtocolError. 상대 노드와의 연결이 끊어진 후 일시적으로 표시되는 상태입니다. 다음 상태: Unconnected

  • TearDown. 상대 노드가 연결 종료 중임을 나타내는 일시적인 상태입니다. 다음 상태: Unconnected

  • Connecting. 상대 노드가 네트워크에서 확인 되기를 기다리고 있는 상태입니다.

  • Connected. TCP 연결이 설정되었으며, 상대 노드로부터 첫 번째 네트워크 패킷을 기다립니다.

복제상태

  • Off 상대노드와 연결이 끊어졌거나, 복제가 진행되지 않는 상태입니다.

  • Established. 정상적으로 연결된 상태입니다. 연결이 성립되었으며, 데이터 미러링이 활성화됩니다. 

  • StartingSyncS. 로컬 노드가 소스이고, 사용자에 의해 전체 동기화가 시작된 상태입니다. 다음 상태: SyncSource 또는 PausedSyncS

  • StartingSyncT. 로컬 노드가 타겟이고, 사용자에 의해 전체 동기화가 시작된 상태입니다. 다음 상태: WFSyncUUID

  • WFBitMapS. 부분 동기화가 시작됩니다. 다음 상태: SyncSource 또는 PausedSyncS

  • WFBitMapT. 부분 동기화가 시작됩니다. 다음 상태: WFSyncUUID

  • SyncSource. 로컬 노드가 소스이고, 동기화가 진행 중인 상태입니다.

  • SyncTarget. 로컬 노드가 타겟이고, 동기화가 진행 중인 상태입니다.

  • VerifyS. 로컬 노드가 소스이고, On-line 디바이스 검증이 실행 중입니다.

  • VerifyT. 로컬 노드가 타겟이고, On-line 디바이스 검증이 실행 중입니다.

  • PausedSyncS. 로컬 노드가 소스이고, 다른 동기화 작업 완료에 대한 의존성 또는 수동 명령 (bsradm pause-sync)에 의해 동기화가 일시 정지된 상태입니다.

  • PausedSyncT. 로컬 노드가 타겟이고, 다른 동기화 작업 완료에 대한 의존성 또는 수동 명령 (bsradm pause-sync)에 의해 동기화가 일시 정지된 상태입니다.

  • Ahead. 로컬노드가 네트워크 혼잡상태에 도달하여 복제데이터를 전송할 수 없는 상태입니다. (상대노드로 OOS Info 전송)

  • Behind. 상대노드가 네트워크 혼잡상태에 도달하여 복제데이터를 수신할 수 없는 상태입니다. (이후 SyncTarget 상태로 전환)

연결상태와 복제상태를 구분하여 표기합니다. 양 노드가 연결되기 전 까지는 연결상태가 StandAlone 에서 Connecting 사이에서 변화합니다. 연결이 성립된 이후는 연결상태가 Connected로 유지되고, 복제 상태는 Established 에서 부터 운영상황에 따라 여러가지 상태로 전환 됩니다.

복제 상태는 특정 시점에 하나의 상태만을 가질 수 있으며, 특히 노드가 소스 상태이면 피어노드는 타깃의 상태여야 합니다.

다음은 리소스의 역할을 출력하는 예 입니다.

Code Block
C:\Program Files\bsr>bsradm role r0
Primary/Secondary 

리소스는 다음 중 하나의 역할을 가집니다.

  • Primary. 읽기와 쓰기가 가능한 상태입니다. 클러스터 내에서 하나의 노드만 이 역할을 가질 수 있습니다.

  • Secondary. primary 노드로부터 디스크 변경 분을 업데이트 하며 읽기와 쓰기가 불가능한 상태입니다. 하나 또는 여러 노드에서 가질 수 있는 역할입니다.

  • Unknown. 리소스의 역할을 알 수 없는 상태입니다. disconnected 모드에서 상대 노드의 역할을 표시할 때 사용되며, 로컬 노드의 역할을 표시할 때는 사용되지 않습니다.

다음은 디스크의 상태 입니다.

Code Block
C:\Program Files\bsr>bsradm dstate r0
UpToDate/UpToDate

로컬 및 원격 디스크의 상태는 다음 중 하나의 값을 가집니다.

  • Diskless. 로컬 블록 디바이스가 bsr 드라이버에 할당되지 않은 상태입니다. 리소스가 백업 디바이스에 적재된 적이 없거나, bsradm detach <resource> 명령으로 수동 분리되었거나, lower-level I/O 오류 후에 자동으로 분리된 경우 이 상태가 됩니다.

  • Attaching. 메타 데이터를 읽는 동안의 일시적인 상태입니다.

  • Failed. 로컬 블록 디바이스의 I/O 실패 보고에 따른 일시적인 상태입니다. 다음 상태는 Diskless 입니다.

  • Negotiating. 이미 연결된 디바이스에서 Attach 가 실행되었을 때 일시적으로 이 상태가 됩니다.

  • Inconsistent. 데이터가 불일치한 상태입니다. 새로운 리소스를 구성했을 경우 양 노드의 디스크는 이 상태가 됩니다. 또는 동기화 중인 타겟 노드의 디스크 상태입니다.

  • Outdated. 리소스의 데이터가 일치하지만, 최신 데이터는 아닌 상태입니다.

  • DUnknown. 네트워크 연결을 사용할 수 없는 경우, 원격 디스크의 상태를 표시하기 위해 사용됩니다.

  • Consistent. 노드가 연결되는 과정에서 데이터는 일치한 상태로 간주된 일시적 상태입니다. 연결이 완료되면, UpToDate 인지 Outdated 인지 결정됩니다.

  • UpToDate. 데이터 정합성이 일치하고 최신의 상태입니다. 복제 중의 일반적인 상태입니다. 

Info

bsr은 Inconsistent 데이터와 Outdated 데이터를 구분합니다. Inconsistent 데이터란 어떤 식으로든 접근이 불가능하거나 사용할 수 없는 데이터를 말합니다. 대표적인 예로 동기화 진행 중인 타겟 쪽 데이터가 inconsistent 상태 입니다. 타겟 쪽 데이터는 동기화가 진행중일 때 일부는 최신이지만 일부는 지난 시점의 데이터 이므로 이를 하나의 시점인 데이터로 간주하는 것이 불가능합니다. 그런 경우에는 장치에 파일시스템이 있는 경우 그 파일시스템은 마운트(mount) 될 수 없거나 파일시스템 체크 조차도 수행되지 못하는 상태 일 수 있습니다.

Outdated 데이터는 특정시점의 데이터 정합성은 보장되지만 프라이머리(Primary) 노드와 최신의 데이터로 동기화되지 않은 데이터 입니다. 이런 경우는 임시적이든 영구적이든 복제 링크가 중단할 경우 발생합니다. 연결이 끊어진 Outdated 데이터를 사용하는데 별 문제는 없지만 이것은 결국 지난 시점의 데이터 입니다. 이런 데이터에서 서비스가 되는 것을 막기 위해 bsr은 Outdated 데이터를 가진 리소스에 대한 승격을 기본적으로 허용하지 않습니다. 그러나 필요하다면(긴급한 상황에서) Outdated 데이터를 강제로 승격할 수는 있습니다.

이벤트

다음과 같은 명령으로 실시간 이벤트 발생 상태를 확인할 수 있습니다. events2 명령은 '--statistics', '--timestamp' 옵션과 함께 사용할 수 있습니다.

Info

C:\Program Files\bsr\bin>bsrsetup events2 --now r0
exists resource name:r0 role:Secondary suspended:no
exists connection name:r0 peer-node-id:1 conn-name:remote-host connection:Connected role:Secondary
exists device name:r0 volume:0 minor:7 disk:UpToDate
exists device name:r0 volume:1 minor:8 disk:UpToDate
exists peer-device name:r0 peer-node-id:1 conn-name:remote-host volume:0
replication:Established peer-disk:UpToDate resync-suspended:no
exists peer-device name:r0 peer-node-id:1 conn-name:remote-host volume:1
replication:Established peer-disk:UpToDate resync-suspended:no
exists -

효율적인 동기화

bsr 에선 효율적인 동기화를 위해 FastSync, 체크섬 기반의 동기화, 운송동기화, 비트맵 제거 동기화 등 다양한 기능을 제공합니다.

FastSync

bsr은 디스크 전체 영역을 대상으로 수행하는 기존 전체 동기화 방식을 파일시스템이 사용하는 영역에 대해서만 동기화하는 빠른 동기화(FastSync)로 개선하였습니다. bsr 은 FastSync 를 위해 파일시스템의 사용영역 정보를 취합하여 해당 사용영역을 OOS 로 기록하고 동기화를 수행합니다.

FastSync 는 초기동기화를 위한 bsradm primary --force 명령 시점, invalidate/invalidate-remote, 온라인 정합성 검사 시점에 적용되어 동작합니다. FastSync가 동작하는데 있어서 사용자가 특별히 옵션을 설정할 필요는 없습니다.

체크섬 기반 동기화

체크섬 데이터 요약을 사용하면 bsr의 동기화 알고리즘의 효율성을 더욱 개선할 수 있습니다. 체크섬 기반 동기화는 동기화하기 전에 블록을 읽고 현재 디스크에 있는 내용의 해시(hash) 요약을 구한 다음, 상대 노드로부터 같은 섹터를 읽어 구한 해쉬 요약 내용과 비교합니다. 해시 내용이 일치하면 해당 블럭에 대한 동기화 쓰기(re-write)를 생략하고 일치하지 않을 경우 동기화 데이터를 전송합니다. 이 방식은 동기화 해야될 블럭을 단순히 덮어쓰는 기존 방식에 비해 성능에서 유리할 수 있으며 연결이 끊어져 있는(disconnect 상태) 동안 파일 시스템이 섹터에 같은 내용을 다시 썼다면 해당 섹터에 대해선 재동기화를 생략하게 되므로 전체적으로 동기화 시간을 단축시킬 수 있습니다.

운송 동기화

디스크를 직접 가져와서 구성하는 운송 동기화는 아래와 같은 상황에 적합합니다.

  • 초기 동기화 할 데이터의 량이 매우 큰 경우(수백 기가바이트 이상)

  • 거대한 데이터 사이즈에 비해 복제할 데이터의 변화율이 적을 것으로 예상되는 경우

  • 소스, 타깃 사이트간 가용 네트워크 대역폭이 제한적인 경우

위와 같은 상황에서 직접 디스크를 가져다가 동기화 하지 않고 일반적인 디바이스 동기화 방법으로 초기화를 진행한다면 동기화를 하는 동안 매우 오랜 시간이 걸릴 것입니다. 디스크 크기가 크고 물리적으로 직접 복사하여 초기화 시킬 수 있다면 운송동기화가 효율적일 수 있습니다.

일단 한가지 상황을 가정해보겠습니다. Primary인 상태로 연결이 끊어진 로컬 노드가 있습니다. 즉, 디바이스 구성은 완료되었고 동일한 bsr.conf 사본은 양 노드에 모두 존재합니다. 로컬 노드에서 초기 리소스 승격(initial resource promotion)을 위한 명령들은 실행했지만 리모트 노드는 아직 연결되어 있지 않습니다.

  • 로컬 노드에서 다음 명령을 실행합니다.

    Code Block
    bsradm new-current-uuid --clear-bitmap <resource>

  • 복제 대상이 될 데이터와 그 데이터의 metadata의 사본을 똑같이 생성합니다. 예를 들어, RAID-1 미러에서 hot-swappable drive를 사용할 수도 있을 겁니다. 물론 이 상황에서는 RAID set이 미러링을 지속하기 위해 새로운 drive로 교체해 주어야 할 것입니다. 그러나 여기서 제거했던 디스크 드라이브는 다른곳에서 바로 사용할 수 있는 말 그대로의 사본입니다. 만약 로컬 블록 디바이스가 스냅샷 사본 기능을 지원한다면 이 기능을 사용하면 됩니다.

  • 로컬 노드에서 아래 명령을 실행합니다. 두 번째 명령 실행에서는 --clear-bitmap 옵션이 없습니다.

    Code Block
    bsradm new-current-uuid <resource>

  • 원본 데이터와 동일한 사본을 물리적으로 직접 가져와서 원격 노드에 사용할 수 있도록 구성 합니다.

  • 물리적으로 디스크를 직접 연결할 수도 있고, 가져온 데이터를 비트단위로 통째로 기존에 가지고 있던 디스크에 복사하여 사용해도 됩니다. 이 과정은 복제한 데이터 뿐만 아니라 메타데이터에도 해 주어야 합니다. 이런 절차가 수용될 수 없다면 이 방법은 더 이상 진행 할 수 없습니다. 

  • 원격 노드에서 bsr 리소스를 기동시킵니다.

    Code Block
    bsradm up <resource>

두 노드가 연결되면 디바이스 전체 동기화(full device synchronization)를 시작하지는 않을 것입니다. 대신에 bsradm--clear-bitmap new-current-uuid 명령을 호출 한 뒤부터 변경된 블럭에 관한 동기화만 자동으로 개시됩니다.

만약 아무런 변화가 없더라도 새로운 Secondary 노드에서 롤백되는 Activity Log에서 다뤄지는 영역에 따라 간단한 동기화가 있을 수 있습니다. 

비트맵 제거 동기화

비트맵을 클리어(--clear-bitmap)하는 옵션을 사용하여 장시간에 걸친 초기 전체 동기화 없이 빠르게 복제 상태가 될 수 있도록 할 수 있습니다. 다음은 이러한 운영 사례를 소개합니다.

새로운 Current UUID를 생성하고 Bitmap UUID를 지워서 초기 동기화를 건너 뛰는 데 사용할 수 있습니다. 이 사용 예는 지금 막 생성된 메타 데이터에서만 작동합니다.

  1. 양 노드에서, 메타를 초기화 하고 장치를 구성합니다. bsradm -- --force create-md res

  2. 양 노드의 리소스를 기동하고 초기 핸드쉐이크 시점에 서로의 볼륨 크기를 인식합니다. bsradm up res

  3. 양 노드가 Secondary/Secondary, Inconsistent/Inconsistent 로 연결된 상태에서 새로운 UUID를 생성하고 비트맵을 클리어 합니다. bsradm new-current-uuid --clear-bitmap res

  4. 이제 양노드는 Secondary/Secondary, UpToDate/UpToDate 상태가 되고 한 쪽을 Primary 로 승격한 후 파일시스템을 생성합니다. bsradm primary res mkfs -t fs-type $(bsradm sh-dev res)

이러한 방식의 명백한 부작용 중 하나는 복제본에 오래된 가비지가 가득하다는 것입니다 (다른 방법을 사용하여 동일하게 만들지 않는 한), 온라인 검사 시 동기화되지 않은 블록 수를 찾을 것으로 예상됩니다. 볼륨에 이미 데이터가 있는 상황에서는 이 방식을 절대 사용해선 안됩니다. 언뜻보기에는 작동하는 것처럼 보일 수 있지만 일단 다른 노드로 전환하면 이미 있던 데이터는 복제되지 않았으므로 데이터가 깨집니다.

동기화 속도 조정

동기화가 백그라운드에서 동작하면 타깃의 데이터는 일시적으로 불일치(Inconsistent)한 상태가 됩니다. 이러한 Inconsistent 상태는 가능한 짧게 유지해야 정합성 보장 측면에서 좋기 때문에 동기화 속도가 충분하게 설정되어 있어야 유리합니다. 그러나 복제와 동기화는 같은 네트워크 대역을 공유하고 있으며 만약 동기화 대역이 높게 설정된다면 상대적으로 복제 대역은 적게 부여될 수 밖에 없습니다. 복제 대역이 낮아지면 로컬의 I/O latency에 영향을 주게 되고 결과적으로 운영 서버의 로컬 I/O 성능 저하를 가져오게 됩니다. 복제든 동기화든 어느 한쪽이 일방적으로 대역을 많이 점유하면 상대적으로 다른 쪽 동작에 영향을 주게 되므로 bsr 은 복제 대역을 최대한 보장하면서 동기화 대역을 복제 상황에 따라 적당히 조절하는 가변대역 동기화를 구현하고 있으며 이를 기본 정책으로 사용합니다. 이와 반대로 고정대역 동기화 정책은 복제에 관계없이 동기화 대역을 항상 보장하는 방식으로 서버 운영 중에 사용할 경우 로컬 I/O 성능의 저하를 가져올 수 있으므로 일반적으로는 권장되지 않고 특수한 상황에서만 사용해야 합니다.

Info

복제와 동기화

  • 복제는 로컬에서 발생하는 디스크의 변경 분 I/O 를 타깃에 실시간 반영하는 동작입니다. 변경 분 I/O가 로컬 디스크에 쓰여지는 문맥에서 복제가 수행 되므로 로컬 I/O 지연에 영향을 줍니다.

  • 동기화는 전체 디스크 볼륨 중 동기화 되지 않은 영역(out-of-sync)을 대상으로 소스 측 디스크의 데이터를 타깃의 데이터와 일치시키는 동작입니다. 0번 디스크 섹터를 시작점으로 하여 볼륨의 마지막 섹터 까지 순차적으로 처리됩니다.

이러한 차이를 명확하게 구분하기 위해 bsr은 복제와 동기화를 항상 구분하여 기술합니다.

Info

대기노드의 최대 디스크 쓰기 속도 보다 높은 값으로 동기화 속도를 설정하는 것은 의미가 없습니다. 대기노드는 진행 중인 디바이스 동기화의 타깃이 되기 때문에 대기 노드가 허용하는 I/O 서브시스템의 쓰기 속도보다 동기화 속도가 더 빠를 수는 없습니다. 같은 이유로, 복제 네트워크에서 사용할 수 있는 대역폭보다 더 높은 값으로 동기화 속도를 설정하는 것도 의미가 없습니다.

고정대역 동기화

...

  2. conf 구성. /dev/local/r0 가 /dev/bsr0의 backing device로 구성된 상태
     Code Block
    	volume 0 {
		device /dev/bsr0;
		disk /dev/local/r0;
		meta-disk /dev/loop3 /bsr_meta/r0_meta;
	}

  3. LV 볼륨 확장을 위해 PV 추가 생성
     Code Block
    [root@bsr01 /]# pvcreate /dev/sdf1
  Physical volume "/dev/sdf1" successfully created.
  4. VG 확장
     Code Block
    [root@bsr01 /]# vgs local
  VG    #PV #LV #SN Attr   VSize   VFree
  local   3   1   0 wz--n- 588.00m 8.00m
[root@bsr01 /]# vgextend local /dev/sdf1
  Volume group "local" successfully extended
[root@bsr01 /]# vgs local
  VG    #PV #LV #SN Attr   VSize VFree  
  local   4   1   0 wz--n- 1.52g 980.00m
  5. LV를 1.5GB 로 확장
     Code Block
    [root@bsr01 /]# lvextend -L 1.5G /dev/local/r0
  Size of logical volume local/r0 changed from 580.00 MiB (145 extents) to 1.50 GiB (384 extents).
  Logical volume local/r0 successfully resized.
[root@bsr01 /]# lvs /dev/local/r0
  LV   VG    Attr       LSize Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  r0   local -wi-ao---- 1.50g      
  6. 3~5번 단계를 모든 노드에서 동일하게 수행
  7. 확장된 size 를 resize 명령을 사용하여 bsr 에게 알림 (primary 노드에서 수행)
     Code Block
    [root@bsr01 /]# bsrsetup status --v --s r0
r0 node-id:0 role:Primary suspended:no
    write-ordering:drain req-pending:0
  volume:0 minor:0 disk:UpToDate
      size:593920 read:1129876 written:248320 al-writes:23 bm-writes:0 upper-pending:0 lower-pending:0 al-suspended:no al-pending-changes:0
      al-used:0 blocked:no
  bsr02 node-id:1 connection:Connected role:Secondary congested:no
    volume:0 replication:Established peer-disk:UpToDate resync-suspended:no
        received:0 sent:588328 out-of-sync:0 pending:0 unacked:0
  bsr03 node-id:2 connection:Connected role:Secondary congested:no
    volume:0 replication:Established peer-disk:UpToDate resync-suspended:no
        received:0 sent:588704 out-of-sync:0 pending:0 unacked:0
[root@bsr01 /]# bsradm resize r0
  8. resize 명령 실행 후 확장된 영역에 대해 부분 동기화가 진행되며, size 값이 593920에서 1572864으로 증가된 것을 확인할 수 있음
     Code Block
    [root@bsr01 /]# bsrsetup status --v --s r0
r0 node-id:0 role:Primary suspended:no
    write-ordering:drain req-pending:0
  volume:0 minor:0 disk:UpToDate
      size:1572864 read:1582588 written:248320 al-writes:31 bm-writes:0 upper-pending:0 lower-pending:2 al-suspended:no al-pending-changes:0
      al-used:0 blocked:no
  bsr02 node-id:1 connection:Connected role:Secondary congested:yes
    volume:0 replication:SyncSource peer-disk:Inconsistent done:47.46 resync-suspended:no
        received:0 sent:762944 out-of-sync:826368 pending:35 unacked:80
  bsr03 node-id:2 connection:Connected role:Secondary congested:yes
    volume:0 replication:SyncSource peer-disk:Inconsistent done:49.15 resync-suspended:no
        received:0 sent:786064 out-of-sync:799744 pending:27 unacked:68
  9. LV 확장과 resize 명령까지 성공하였다면 resize2fs 명령을 사용하여 filesystem을 확장시켜 주어야 한다. (primary 노드에서 실행)
     Code Block
    [root@bsr01 /]# df -h
Filesystem               Size  Used Avail Use% Mounted on
...
/dev/bsr0                555M  544M     0 100% /mnt0

[root@bsr01 /]# resize2fs /dev/bsr0
resize2fs 1.42.9 (28-Dec-2013)
Filesystem at /dev/bsr0 is mounted on /mnt0; on-line resizing required
old_desc_blocks = 1, new_desc_blocks = 1
The filesystem on /dev/bsr0 is now 393216 blocks long.

[root@bsr01 /]# df -h
...
/dev/bsr0                1.5G  545M  878M  39% /mnt0
볼륨의 늘어난 영역에 대한 새로운 동기화가 수행됩니다.
 Info
연결이 disconnect 된 상태에서 볼륨 크기를 조정하려면 다음의 과정을 따릅니다.
  1. secondary 노드에서 bsradm disconnect 로 연결 단절
  2. 양 노드에서 LV 확장
    1. LV 확장은 secondary 상태로 수행 가능하며 primary로 승격할 필요 없음.
  3. 확장된 size를 적용하기 위해 primary 노드에서 resize 명령 수행
     Code Block
    [root@bsr01 /]# bsrsetup status --v --s r1
r1 node-id:0 role:Primary suspended:no
    write-ordering:drain req-pending:0
  volume:0 minor:1 disk:UpToDate
      size:512000 read:1561828 written:25956 al-writes:37 bm-writes:0 upper-pending:0 lower-pending:0 al-suspended:no al-pending-changes:0 al-used:0
      blocked:no
  bsr-02 node-id:1 connection:Connecting role:Unknown congested:no
    volume:0 replication:Off peer-disk:DUnknown resync-suspended:no
        received:0 sent:1562367 out-of-sync:0 pending:0 unacked:0
[root@bsr01 /]# bsradm resize r1
  4. resize 명령 수행 후 size 값 증가 확인, 확장된 영역이 out-of-sync 로 설정됨
     Code Block
    [root@bsr01 /]# bsrsetup status --v --s r1
r1 node-id:0 role:Primary suspended:no
    write-ordering:drain req-pending:0
  volume:0 minor:1 disk:UpToDate
      size:1572864 read:1561828 written:25956 al-writes:45 bm-writes:0 upper-pending:0 lower-pending:0 al-suspended:no al-pending-changes:0 al-used:0
      blocked:no
  bsr-02 node-id:1 connection:Connecting role:Unknown congested:no
    volume:0 replication:Off peer-disk:DUnknown resync-suspended:no
        received:0 sent:1562367 out-of-sync:1060864 pending:0 unacked:0
  5. primary 노드에서 resize2fs 명령 실행
     Code Block
    [root@bsr01 /]# resize2fs /dev/bsr1
resize2fs 1.45.6 (20-Mar-2020)
Filesystem at /dev/bsr1 is mounted on /mnt_r1; on-line resizing required
old_desc_blocks = 8, new_desc_blocks = 12
The filesystem on /dev/bsr1 is now 1572864 (1k) blocks long.
  6. 파일 시스템 확장까지 완료한 이후 secondary에서 connect 명령을 사용하여 연결
% 재 연결시 주의 사항
  • primary 노드가 있어야 한다.  primary 노드가 없다면 확장된 영역이 동기화 되지 못하고 out-of-sync가 남아있게 된다.
  • 확장 이후 secondary의 볼륨 크기가 primary의 크기 보다 크거나 같아야 한다. primary의 볼륨 크기가 더 크면 복제 연결이 성립되지 않는다.
  • 타겟 노드의 LV 볼륨 사이즈를 secondary 상태에서 변경했다면 SB 해결 절차 없이 connect 명령 만으로 연결 할 수 있다. 타겟 노드를 --force primary 로 승격한 뒤 resize를 진행했다면, SB 해결 절차 수행이 필요하다.
리소스 삭제
리소스 삭제는 구성파일 삭제 후 메타를 완전히 폐기하는 것 까지를 수행해야 합니다. 다음의 절차를 따릅니다.
  • 운영 중인 리소스를 down 합니다.
  • 리소스 구성파일을 삭제 합니다.
  • Windows 의 경우 bsrcon /release_vol 을 통해 복제 볼륨에서 제외하고 볼륨락을 해제합니다.
  • wipe-md 명령으로 메타를 완전히 지웁니다. (bsr 1.7 이후로 wipe-md 는 /release_vol 명령 시점에 자동 수행합니다.)
조회
버전
bsradm /V 명령을 통해 bsr의 버전 정보를 확인합니다.
 Code Block
[root@bsr-01 nglee]# bsradm -V
BSRADM_BUILDTAG=GIT-hash:3dca67e82d331e95121288a57898fcda13357e94 build by nglee@NGLEE-1,2020-01-29 13:50:48
BSRADM_API_VERSION=2
BSR_KERNEL_VERSION_CODE=0x000000
BSR_KERNEL_VERSION=0.0.0
BSRADM_VERSION_CODE=0x010600
BSRADM_VERSION=1.6.0-PREALPHA3
상태정보
기본적인 상태 정보를 출력합니다.
 Code Block
>bsradm status r0
r0 role:Secondary
  disk:UpToDate
  nina role:Secondary
    disk:UpToDate
  nino role:Secondary
    disk:UpToDate
  nono connection:Connecting
상세 정보를 출력합니다.
 Code Block
C:\Users\Administrator>bsrsetup status r0 --verbose --statistic
r0 node-id:0 role:Primary suspended:no
    write-ordering:drain req-pending:0
  volume:0 minor:2 disk:UpToDate
      size:10467328 read:29847120 written:3029330 al-writes:260 bm-writes:0 upper-pending:0 lower-pending:0
      al-suspended:no al-pending-changes:0 al-used:0 accelbuf-used:0 blocked:no
  D3W2K22BSRAG-002 node-id:1 connection:Connecting role:Unknown congested:no
    volume:0 replication:Off peer-disk:DUnknown resync-suspended:no
        received:0 sent:11803912 out-of-sync:329892 pending:0 unacked:0
  D3W2K22BSRAG-003 node-id:2 connection:Connected role:Secondary congested:no
    volume:0 replication:Established peer-disk:UpToDate resync-suspended:no
        received:0 sent:16247308 out-of-sync:0 pending:0 unacked:0
성능지시자
  • sent (network send).  네트워크 연결을 통해 상대 노드에 전송된 네트워크 데이터의 양입니다. (Kibyte)
  • received (network receive). 네트워크 연결을 통해 상대 노드에서 수신된 네트워크 데이터의 양입니다. (Kibyte)
  • written (disk write). 로컬 하드 디스크에 기록된 넷 데이터입니다. (Kibyte)
  • read (disk read). 로컬 하드 디스크로부터 읽은 넷 데이터입니다. (Kibyte)
  • al-writes (activity log). 메타 데이터의 activity log 영역에 대한 업데이트 횟수입니다.
  • bm-writes (bit map). 메타 데이터의 비트맵 영역에 대한 업데이트 횟수입니다.
  • upper-pending (application pending I/O ). 상위에서 bsr 로 전달된 I/O 들 중 완료되지 못하고 bsr에서 처리중인 I/O 개수 .
  • lower-pending (subsystem open count). bsr에서 수행한 로컬 I/O sub-system에 대한 (close 되지 않은) open 횟수.
  • pending. 상대 노드에게 요청하였지만 응답(ack)받지 못한 요청 횟수입니다.
  • unacked (unacknowledged). 상대 노드에서 요청을 받았지만 응답(ack)해 주지 않은 요청 횟수입니다.
  • write-ordering (write order). 현재 사용하는 디스크 쓰기 방식을 나타냅니다.
  • out-of-sync.  현재 동기화가 이루어지지 않은 스토리지의 양을 나타냅니다. (Kibytes)
  • resync-suspended.  재 동기화 중단 여부. 가능한 값 은 no,user, peer, dependency
  • blocked. 로컬 I/O 혼잡상태 표시
    • no: 혼잡없음
    • upper: 상위 디바이스에서 혼잡발생
    • lower: 디스크 혼잡
  • congested. 이 플래그는 복제 연결상의 TCP 송신 버퍼가 80 % 이상 채워 졌는지 여부를 알려줍니다.
    • yes: 네트웍 혼잡
    • no: 혼잡없음
네트워크 연결상태를 출력합니다.
 Code Block
C:\>bsradm cstate r0
Connected
연결상태
  • StandAlone. 리소스가 아직 연결되지 않았거나, 사용자가 bsradm disconnect를 사용하여 연결을 끊었거나, 인증 실패 또는 스플릿 브레인과 같은 이유로 연결이 끊어져 네트워크 구성이 가능하지 않은 상태입니다.
  • Disconnecting. 연결이 끊어지는 동안의 일시적인 상태입니다. 다음 상태: StandAlone
  • Unconnected. 연결을 시도하기 전의 일시적인 상태입니다. 다음 상태: Connecting 또는 Connected.
  • Timeout. 상대 노드와의 통신 시간 초과에 따른 일시적인 상태입니다. 다음 상태: Unconnected
  • BrokenPipe. 상대 노드와의 연결이 끊어진 후 일시적으로 표시되는 상태입니다. 다음 상태: Unconnected
  • NetworkFailure. 상대 노드와의 연결이 끊어진 후 일시적으로 표시되는 상태입니다. 다음 상태: Unconnected
  • ProtocolError. 상대 노드와의 연결이 끊어진 후 일시적으로 표시되는 상태입니다. 다음 상태: Unconnected
  • TearDown. 상대 노드가 연결 종료 중임을 나타내는 일시적인 상태입니다. 다음 상태: Unconnected
  • Connecting. 상대 노드가 네트워크에서 확인 되기를 기다리고 있는 상태입니다.
  • Connected. TCP 연결이 설정되었으며, 상대 노드로부터 첫 번째 네트워크 패킷을 기다립니다.
복제상태
  • Off 상대노드와 연결이 끊어졌거나, 복제가 진행되지 않는 상태입니다.
  • Established. 정상적으로 연결된 상태입니다. 연결이 성립되었으며, 데이터 미러링이 활성화됩니다. 
  • StartingSyncS. 로컬 노드가 소스이고, 사용자에 의해 전체 동기화가 시작된 상태입니다. 다음 상태: SyncSource 또는 PausedSyncS
  • StartingSyncT. 로컬 노드가 타겟이고, 사용자에 의해 전체 동기화가 시작된 상태입니다. 다음 상태: WFSyncUUID
  • WFBitMapS. 부분 동기화가 시작됩니다. 다음 상태: SyncSource 또는 PausedSyncS
  • WFBitMapT. 부분 동기화가 시작됩니다. 다음 상태: WFSyncUUID
  • SyncSource. 로컬 노드가 소스이고, 동기화가 진행 중인 상태입니다.
  • SyncTarget. 로컬 노드가 타겟이고, 동기화가 진행 중인 상태입니다.
  • VerifyS. 로컬 노드가 소스이고, On-line 디바이스 검증이 실행 중입니다.
  • VerifyT. 로컬 노드가 타겟이고, On-line 디바이스 검증이 실행 중입니다.
  • PausedSyncS. 로컬 노드가 소스이고, 다른 동기화 작업 완료에 대한 의존성 또는 수동 명령 (bsradm pause-sync)에 의해 동기화가 일시 정지된 상태입니다.
  • PausedSyncT. 로컬 노드가 타겟이고, 다른 동기화 작업 완료에 대한 의존성 또는 수동 명령 (bsradm pause-sync)에 의해 동기화가 일시 정지된 상태입니다.
  • Ahead. 로컬노드가 네트워크 혼잡상태에 도달하여 복제데이터를 전송할 수 없는 상태입니다. (상대노드로 OOS Info 전송)
  • Behind. 상대노드가 네트워크 혼잡상태에 도달하여 복제데이터를 수신할 수 없는 상태입니다. (이후 SyncTarget 상태로 전환)
연결상태와 복제상태를 구분하여 표기합니다. 양 노드가 연결되기 전 까지는 연결상태가 StandAlone 에서 Connecting 사이에서 변화합니다. 연결이 성립된 이후는 연결상태가 Connected로 유지되고, 복제 상태는 Established 에서 부터 운영상황에 따라 여러가지 상태로 전환 됩니다.
복제 상태는 특정 시점에 하나의 상태만을 가질 수 있으며, 특히 노드가 소스 상태이면 피어노드는 타깃의 상태여야 합니다. 
다음은 리소스의 역할을 출력하는 예 입니다.
 Code Block
C:\Program Files\bsr>bsradm role r0
Primary/Secondary 
리소스는 다음 중 하나의 역할을 가집니다.
  • Primary. 읽기와 쓰기가 가능한 상태입니다. 클러스터 내에서 하나의 노드만 이 역할을 가질 수 있습니다. 
  • Secondary. primary 노드로부터 디스크 변경 분을 업데이트 하며 읽기와 쓰기가 불가능한 상태입니다. 하나 또는 여러 노드에서 가질 수 있는 역할입니다.
  • Unknown. 리소스의 역할을 알 수 없는 상태입니다. disconnected 모드에서 상대 노드의 역할을 표시할 때 사용되며, 로컬 노드의 역할을 표시할 때는 사용되지 않습니다.
다음은 디스크의 상태 입니다.
 Code Block
C:\Program Files\bsr>bsradm dstate r0
UpToDate/UpToDate
로컬 및 원격 디스크의 상태는 다음 중 하나의 값을 가집니다.
  • Diskless. 로컬 블록 디바이스가 bsr 드라이버에 할당되지 않은 상태입니다. 리소스가 백업 디바이스에 적재된 적이 없거나, bsradm detach <resource> 명령으로 수동 분리되었거나, lower-level I/O 오류 후에 자동으로 분리된 경우 이 상태가 됩니다.
  • Attaching. 메타 데이터를 읽는 동안의 일시적인 상태입니다.
  • Failed. 로컬 블록 디바이스의 I/O 실패 보고에 따른 일시적인 상태입니다. 다음 상태는 Diskless 입니다.
  • Negotiating. 이미 연결된 디바이스에서 Attach 가 실행되었을 때 일시적으로 이 상태가 됩니다.
  • Inconsistent. 데이터가 불일치한 상태입니다. 새로운 리소스를 구성했을 경우 양 노드의 디스크는 이 상태가 됩니다. 또는 동기화 중인 타겟 노드의 디스크 상태입니다.
  • Outdated. 리소스의 데이터가 일치하지만, 최신 데이터는 아닌 상태입니다.
  • DUnknown. 네트워크 연결을 사용할 수 없는 경우, 원격 디스크의 상태를 표시하기 위해 사용됩니다.
  • Consistent. 노드가 연결되는 과정에서 데이터는 일치한 상태로 간주된 일시적 상태입니다. 연결이 완료되면, UpToDate 인지 Outdated 인지 결정됩니다.
  • UpToDate. 데이터 정합성이 일치하고 최신의 상태입니다. 복제 중의 일반적인 상태입니다. 
 Info
bsr은 Inconsistent 데이터와 Outdated 데이터를 구분합니다. Inconsistent 데이터란 어떤 식으로든 접근이 불가능하거나 사용할 수 없는 데이터를 말합니다. 대표적인 예로 동기화 진행 중인 타겟 쪽 데이터가 inconsistent 상태 입니다. 타겟 쪽 데이터는 동기화가 진행중일 때 일부는 최신이지만 일부는 지난 시점의 데이터 이므로 이를 하나의 시점인 데이터로 간주하는 것이 불가능합니다. 그런 경우에는 장치에 파일시스템이 있는 경우 그 파일시스템은 마운트(mount) 될 수 없거나 파일시스템 체크 조차도 수행되지 못하는 상태 일 수 있습니다.
Outdated 데이터는 특정시점의 데이터 정합성은 보장되지만 프라이머리(Primary) 노드와 최신의 데이터로 동기화되지 않은 데이터 입니다. 이런 경우는 임시적이든 영구적이든 복제 링크가 중단할 경우 발생합니다. 연결이 끊어진 Outdated 데이터를 사용하는데 별 문제는 없지만 이것은 결국 지난 시점의 데이터 입니다. 이런 데이터에서 서비스가 되는 것을 막기 위해 bsr은 Outdated 데이터를 가진 리소스에 대한 승격을 기본적으로 허용하지 않습니다. 그러나 필요하다면(긴급한 상황에서) Outdated 데이터를 강제로 승격할 수는 있습니다.
이벤트
다음과 같은 명령으로 실시간 이벤트 발생 상태를 확인할 수 있습니다. events2 명령은 '--statistics', '--timestamp' 옵션과 함께 사용할 수 있습니다.
 Info
C:\Program Files\bsr\bin>bsrsetup events2 --now r0
exists resource name:r0 role:Secondary suspended:no
exists connection name:r0 peer-node-id:1 conn-name:remote-host connection:Connected role:Secondary
exists device name:r0 volume:0 minor:7 disk:UpToDate
exists device name:r0 volume:1 minor:8 disk:UpToDate
exists peer-device name:r0 peer-node-id:1 conn-name:remote-host volume:0
replication:Established peer-disk:UpToDate resync-suspended:no
exists peer-device name:r0 peer-node-id:1 conn-name:remote-host volume:1
replication:Established peer-disk:UpToDate resync-suspended:no
exists -
이벤트에 대한 자세한 사항은 /wiki/spaces/B/pages/3277422597 문서를 참고하세요.
효율적인 동기화
bsr 에선 효율적인 동기화를 위해 FastSync, 체크섬 기반의 동기화, 운송동기화, 비트맵 제거 동기화 등 다양한 기능을 제공합니다.
FastSync
bsr은 디스크 전체 영역을 대상으로 수행하는 기존 전체 동기화 방식을 파일시스템이 사용하는 영역에 대해서만 동기화하는 빠른 동기화(FastSync)를 기본 동작으로 변경하였습니다. 예를 들어 1TB 디스크에서 100MB 만 사용하고 있다면 100MB 디스크 영역에 대해서만 동기화 하므로 기존 전체 동기화(1TB)에 비해 10배 빠르게 초기동기화를 마칠 수 있습니다. FastSync 는 다음 시점에 기본 동작합니다.
  • 초기 전체 동기화(bsradm primary --force)
  • 수동 전체 동기화(invalidate/invalidate-remote)
  • 정합성 검사(bsradm verify)
 Note
주의할 점!
FastSync 는 초기 동기화를 수행하기 전에 파일시스템 정보를 우선 얻어야 하는데, 파일시스템이 훼손(깨짐)되어 있다면 사용 영역에 대한 정보를 부정확하게 처리할 수 있습니다. 이를 인식하지 못하고 FastSync 가 처리될 경우 소스와 타깃의 정합성이 불일치하게 되므로 매우 조심해야 합니다.
따라서 bsr 에선 이런 상황에 대비하기 위해 bsradm primary --force 를 통해 초기 동기화를 수행하기에 앞서 파일시스템 무결성 검사를 먼저 의뢰하고(chkdsk or fsck) 그 결과에 문제가 없을 때 FastSync 가 동작하도록 합니다. 
관리자는 bsr 초기동기화를 수행하기 전 파일시스템 무결성 검사를 수행하여 복제 디스크의 health 상태를 미리 파악해 둘 필요가 있습니다. 
 Info
FastSync 를 비활성화 하고 예전 FullSync 방식을 사용하려면 다음의 명령을 수행합니다.
bsrcon /set_fast_sync 0
현재 초기 동기화 방식이 FastSync 인지 FullSync 인지 확인하려면 다음의 명령을 수행합니다.
bsrcon /get_fast_sync
체크섬 기반 동기화
체크섬 데이터 요약을 사용하면 bsr의 동기화 알고리즘의 효율성을 더욱 개선할 수 있습니다. 체크섬 기반 동기화는 동기화하기 전에 블록을 읽고 현재 디스크에 있는 내용의 해시(hash) 요약을 구한 다음, 상대 노드로부터 같은 섹터를 읽어 구한 해쉬 요약 내용과 비교합니다. 해시 내용이 일치하면 해당 블럭에 대한 동기화 쓰기(re-write)를 생략하고 일치하지 않을 경우 동기화 데이터를 전송합니다. 이 방식은 동기화 해야될 블럭을 단순히 덮어쓰는 기존 방식에 비해 성능에서 유리할 수 있으며 연결이 끊어져 있는(disconnect 상태) 동안 파일 시스템이 섹터에 같은 내용을 다시 썼다면 해당 섹터에 대해선 재동기화를 생략하게 되므로 전체적으로 동기화 시간을 단축시킬 수 있습니다.
체크섬 기반 동기화는 기본적으로 비활성화 되어 있습니다. 이 기능을 사용하려면 양 노드의 리소스 구성에 다음 줄을 추가합니다.
resource <resource>
 net {
 csums-alg <algorithm>;
 }
 ...
}
<algorithm>은 시스템 커널 구성에서 커널 암호화 API가 지원하는 메시지 다이제스트 알고리즘입니다. 일반적으로 SHA1, MD5, CRC32C 중에서 선택할 수 있으며 Windows 는 CRC32 를 지원합니다.
운송 동기화
디스크를 직접 가져와서 구성하는 운송 동기화는 아래와 같은 상황에 적합합니다.
  • 초기 동기화 할 데이터의 량이 매우 큰 경우(수백 기가바이트 이상)
  • 거대한 데이터 사이즈에 비해 복제할 데이터의 변화율이 적을 것으로 예상되는 경우
  • 소스, 타깃 사이트간 가용 네트워크 대역폭이 제한적인 경우
위와 같은 상황에서 직접 디스크를 가져다가 동기화 하지 않고 일반적인 디바이스 동기화 방법으로 초기화를 진행한다면 동기화를 하는 동안 매우 오랜 시간이 걸릴 것입니다. 디스크 크기가 크고 물리적으로 직접 복사하여 초기화 시킬 수 있다면 운송동기화가 효율적일 수 있습니다.
일단 한가지 상황을 가정해보겠습니다. Primary인 상태로 연결이 끊어진 로컬 노드가 있습니다. 즉, 디바이스 구성은 완료되었고 동일한 bsr.conf 사본은 양 노드에 모두 존재합니다. 로컬 노드에서 초기 리소스 승격(initial resource promotion)을 위한 명령들은 실행했지만 리모트 노드는 아직 연결되어 있지 않습니다.
  • 로컬 노드에서 다음 명령을 실행합니다.
     Code Block
    bsradm new-current-uuid --clear-bitmap <resource>
  • 복제 대상이 될 데이터와 그 데이터의 metadata의 사본을 똑같이 생성합니다. 예를 들어, RAID-1 미러에서 hot-swappable drive를 사용할 수도 있을 겁니다. 물론 이 상황에서는 RAID set이 미러링을 지속하기 위해 새로운 drive로 교체해 주어야 할 것입니다. 그러나 여기서 제거했던 디스크 드라이브는 다른곳에서 바로 사용할 수 있는 말 그대로의 사본입니다. 만약 로컬 블록 디바이스가 스냅샷 사본 기능을 지원한다면 이 기능을 사용하면 됩니다.
  • 로컬 노드에서 아래 명령을 실행합니다. 두 번째 명령 실행에서는 --clear-bitmap 옵션이 없습니다.
     Code Block
    bsradm new-current-uuid <resource>
  • 원본 데이터와 동일한 사본을 물리적으로 직접 가져와서 원격 노드에 사용할 수 있도록 구성 합니다.
  • 물리적으로 디스크를 직접 연결할 수도 있고, 가져온 데이터를 비트단위로 통째로 기존에 가지고 있던 디스크에 복사하여 사용해도 됩니다. 이 과정은 복제한 데이터 뿐만 아니라 메타데이터에도 해 주어야 합니다. 이런 절차가 수용될 수 없다면 이 방법은 더 이상 진행 할 수 없습니다. 
  • 원격 노드에서 bsr 리소스를 기동시킵니다.
     Code Block
    bsradm up <resource>
두 노드가 연결되면 디바이스 전체 동기화(full device synchronization)를 시작하지는 않을 것입니다. 대신에 bsradm--clear-bitmap new-current-uuid 명령을 호출 한 뒤부터 변경된 블럭에 관한 동기화만 자동으로 개시됩니다.
만약 아무런 변화가 없더라도 새로운 Secondary 노드에서 롤백되는 Activity Log에서 다뤄지는 영역에 따라 간단한 동기화가 있을 수 있습니다. 
clear-bitmap 동기화
--clear-bitmap 옵션을 사용하여 장시간에 걸친 초기 전체 동기화 없이 빠르게 복제 상태가 될 수 있도록 할 수 있습니다. 다음은 이러한 운영 사례를 소개합니다.
새로운 Current UUID를 생성하고 Bitmap UUID를 지워서 초기 동기화를 건너 뛰는 데 사용할 수 있습니다. 이 사용 예는 지금 막 생성된 메타 데이터에서만 작동합니다.
  1. 양 노드에서, 메타를 초기화 하고 장치를 구성합니다. bsradm -- --force create-md res
  2. 양 노드의 리소스를 기동하고 초기 핸드쉐이크 시점에 서로의 볼륨 크기를 인식합니다. bsradm up res
  3. 양 노드가 Secondary/Secondary, Inconsistent/Inconsistent 로 연결된 상태에서 새로운 UUID를 생성하고 비트맵을 클리어 합니다. bsradm new-current-uuid --clear-bitmap res
  4. 이제 양노드는 Secondary/Secondary, UpToDate/UpToDate 상태가 되고 한 쪽을 Primary 로 승격한 후 파일시스템을 생성합니다. bsradm primary res mkfs -t fs-type $(bsradm sh-dev res)
이러한 방식을 사용했을 때 명백한 부작용 중 하나는 다른 방법을 써서 양측을 동일하게 만들지 않는 한 복제본에 이전 가비지 데이터가 가득차 있다는 것입니다. 여기서 온라인 검사를 하게되면 동기화되지 않은 블록들을 많이 찾게 될 것입니다. 볼륨에 이미 데이터가 있는 상황에서는 이 방식을 절대 사용해선 안됩니다. 언뜻보기에는 작동하는 것처럼 보일 수 있지만 다른 노드로 스위치오버 하면 이미 있던 데이터는 복제되지 않았으므로 데이터가 깨집니다.
동기화 속도 조정
동기화가 백그라운드에서 동작하면 타깃의 데이터는 일시적으로 불일치(Inconsistent)한 상태가 됩니다. 이러한 Inconsistent 상태는 가능한 짧게 유지해야 정합성 보장 측면에서 좋기 때문에 동기화 속도가 충분하게 설정되어 있어야 유리합니다. 그러나 복제와 동기화는 같은 네트워크 대역을 공유하고 있으며 만약 동기화 대역이 높게 설정된다면 상대적으로 복제 대역은 적게 부여될 수 밖에 없습니다. 복제 대역이 낮아지면 로컬의 I/O latency에 영향을 주게 되고 로컬 I/O 성능 저하를 가져오게 됩니다. 복제든 동기화든 어느 한쪽이 일방적으로 대역을 많이 점유하면 상대적으로 다른 쪽 동작에 영향을 주게 되므로 bsr은 복제 대역을 최대한 보장하면서 동기화 대역을 복제 상황에 따라 적당히 조절하는 가변대역 동기화를 구현하고 이를 기본 정책으로 합니다. 이와 반대로 고정대역 동기화 정책은 복제에 관계없이 동기화 대역을 항상 보장하는 방식인데, 서비스 운영 중에 사용하면 로컬 I/O 성능의 저하를 가져올 수 있으므로 일반적으로는 권장되지 않고 특수한 상황에서만 사용해야 합니다.
 Info
복제와 동기화
  • 복제는 로컬에서 발생하는 디스크의 변경 분 I/O 를 타깃에 실시간 반영하는 동작입니다. 변경 분 I/O가 로컬 디스크에 쓰여지는 문맥에서 복제가 수행 되므로 로컬 I/O 지연에 영향을 줍니다.
  • 동기화는 전체 디스크 볼륨 중 동기화 되지 않은 영역(out-of-sync)을 대상으로 소스 측 디스크의 데이터를 타깃의 데이터와 일치시키는 동작입니다. 0번 디스크 섹터를 시작점으로 하여 볼륨의 마지막 섹터 까지 순차적으로 처리됩니다.
이러한 차이를 기술적으로 명확하게 구분하기 위해 복제와 동기화를 항상 구분하여 기술합니다.
 Info
대기노드의 최대 디스크 쓰기 속도 보다 높은 값으로 동기화 속도를 설정하는 것은 의미가 없습니다. 대기노드는 진행 중인 디바이스 동기화의 타깃이 되기 때문에 대기 노드가 허용하는 I/O 서브시스템의 쓰기 속도보다 동기화 속도가 더 빠를 수는 없습니다. 같은 이유로, 복제 네트워크에서 사용할 수 있는 대역폭보다 더 높은 값으로 동기화 속도를 설정하는 것도 의미가 없습니다.
고정대역 동기화
백그라운드에서 수행되는 재동기화를 위해 사용되는 최대 대역폭은 리소스의 resync-rate 옵션에 따라 결정됩니다. 해당 옵션은 다음과 같이 /etc/bsr.conf 리소스 구성의 disk 섹션에 포함되어 있습니다.
 Code Block
resource <resource> {
  disk {
    resync-rate 40M;  
    c-min-rate 40M;  
    c-plan-ahead 0;  
    ...
  }
  ...
}
resync-rate, c-min-rate 설정은 초당 바이트 단위로 지정됩니다. 기본 단위는 Kibibyte이고 4096의 값은 4MiB로 해석됩니다.
 Info
Important 
  • c-plan-ahead 파라미터가 양수 값으로 설정되어 있을 경우 동적으로 동기화 속도를 조절합니다. 이 값은 기본적으로 20 으로 설정되어 있으며 고정대역 동기화를 위해서는 이 값을 0 으로 설정해야 합니다.
가변대역 동기화 
다중 리소스가 복제/동기화 네트워크를 공유하는 구성의 경우 고정대역 동기화로 구성할 경우 문제가 됩니다. 리소스 들이 같은 복제 네트워크를 공유하기 때문에 특정 복제 리소스 채널에 대해서 동기화율이 점유 당할 경우 다른 리소스들은 고정 동기화율이 보장되지 않게 됩니다. 이 경우, 가변대역 동기화를 통해 각각의 복제 채널의 동기화율을 동적으로 조정 하도록 구성하여 다른 리소스에 의해 동기화 대역이 점유당하더라도 이에 능동적으로 동기화 대역을 조절하여 대응할 수 있습니다. 가변대역 동기화는 초기 동기화 속도(resync-rate 만큼)를 결정한 후 자동 제어 알고리즘을 통해 지속적으로 동기화 속도를 조정합니다. 이 알고리즘은 복제가 전면에서 동작하면서도 동기화 대역을 c-min-rate 에서 c-max-rate 까지 가용하도록 합니다. 그러나 c-max-rate 를 너무 높게 설정하면 복제 대역이 부족해 지므로 해당 리소스에 부과된 가용 네트워크 대역의 절반 이하로 c-max-rate 를 설정하여 복제를 위한 대역을 확보해 두는 게 바람직 합니다.
가변대역 동기화를 위한 최적의 구성은 사용 가능한 네트워크 대역폭, 응용 프로그램 I/O 패턴 및 복제 링크 혼잡상황에 따라 달라질 수 있으며, 복제 가속기(DRX) 사용 여부에 따라 최적의 구성 설정이 달라질 수 있습니다. 
 Info
복제와 동기화를 동시에 처리할 경우
  • bsr 은 최소한 c-min-rate(기본 250KB) 만큼의 동기화 대역은 보장합니다.
  • bsr 은 복제 대역과 동기화 대역을 배분하면서 동시에 동기화 대역이 최대한 c-max-rate 에 도달하도록 시도합니다.
 Info
BSR과 DRBD 의 차이점
  • BSR은 동기화와 복제를 동시에 처리할 때 동기화 대역을 c-min-rate 에서 c-max-rate 값으로 유지하려고 합니다. 즉 가능한 한 동기화 대역을 충분히 확보하려고 시도합니다.
  • DRBD 는 동기화와 복제를 동시에 처리할 때 동기화 대역을 강제로 c-min-rate 의 값으로 떨어뜨립니다.
 Info
동기화 속도 추정
아래와 같은 수식으로 동기화 시간을 추정할 수 있습니다.
tresync = D/R
  • tresync 는 동기화 예상 시간입니다.
  • D는 별다른 영향(복제 링크가 끊어진 상황에서 데이터가 수정되는 등)을 거의 받지 않는다는 가정하에서 동기화될 데이터의 크기를 말합니다.
  • R은 조정 가능한 동기화율이며 이는 복제 네트워크 환경 및 I/O 서브시스템의 처리능력에 따라 한계 값이 달라집니다.
 Note
동기화 대역 설정 예
100Mbps 대역에서 5개 복제 리소스를 운영할 경우,
  • 100Mbps 는 약 10MB/s 이므로 5개 대역을 공평히 배분하면 리소스별 10/5 = 약 2MB/s
  • 복제/동기화 대역의 배분 비율은 특별한 요구가 없을 경우 각각 50%로 지정, 따라서 동기화 최대 대역(c-max-rate) 은 1MB
  • 최소한도로 보장할 동기화 대역을 c-min-rate 로 지정, 예를 들어 128KB
  • resync-rate 는 재동기화 시 시작 값.
resource {
resync-rate 128KB;
c-min-rate 128KB;
c-max-rate 1MB;
}
동기화 비율 설정
동기화 대역을 복제 대역에 대한 비율로 설정할 수도 있습니다.
 Code Block
resource <resource> {
  disk {
    c-min-rate 40M;  
    resync-ratio "3:1";
    ...
  }
  ...
}
위 예제는 복제 3 대 동기화 1의 비율(전체 4)로 동기화 대역을 설정합니다. 단, 동기화 비율과 c-min-rate를 비교하여 c-min-rate 값이 높으면 c-min-rate 값으로 적용됩니다. 이를 통해 최소한의 동기화 대역을 확보합니다.
혼잡 모드
 Info
비동기 방식 복제에서 만 사용합니다.
복제 대역이 변동대역인 환경(WAN)에서는 때때로 복제 링크가 정체 될 수 있습니다. 이로 인해 Primary 노드의 I/O가 대기하게 되면 로컬 I/O의 성능 저하가 발생합니다. 혼잡모드는 이러한 상황에 대응하기 위한 구성입니다. 
혼잡이 감지 되면 복제는 일시 중단되고 로컬의 I/O를 OOS 로 기록하면서 버퍼링 된 데이터를 서서히 타깃으로 전송합니다. 이 과정에서 Primary 는 Secondary 에 비해 앞선(Ahead) 데이터 상태이며 버퍼링 되었던 데이터를 다 전송하고 나면 자동으로 동기화 모드로 전환하여 복제 되지 못한 OOS 영역을 동기화 합니다. 
혼잡 모드는 다음의 3 가지 모드가 있습니다.
  • Blocking 모드
    • 아무 설정도 하지 않을 경우 기본적으로 Blocking 모드입니다. Blocking 모드에서는 TX 송신버퍼에 복제 데이터를 전송할 여유 공간이 생길 때 까지 대기(Blocking)합니다.
  • disconnect 모드
    • 복제 연결을 단절하여 로컬 I/O 부하를 일시적으로 해소하도록 disconnect 모드로 설정할 수 있습니다.
  • Ahead 모드
    • 복제 연결은 유지한 채 primary 노드의 I/O를 로컬 디스크에 우선 기록해 두었다가(해당 영역은 out-of-sync로 기록) 혼잡 해제 후 재동기화를 자동으로 수행하는 pull-ahead 모드로 설정할 수 있습니다. Ahead 상태가 된 Primary 노드는 Secondary 노드에 비해 앞서 있는(Ahead) 데이터 상태가 됩니다. 그리고 이 시점에 Secondary는 뒤 쳐진(Behind) 예전 데이터 이지만 쓸 수는 있는 가용 상태입니다. 혼잡이 해제되면, 세컨더리로의 복제는 자동 재개되고 Ahead 상태에서 복제되지 못했던 out-of-sync 블럭에 대해 백그라운드 동기화를 이어서 수행합니다. 혼잡모드는 일반적으로 데이터센터 또는 클라우드 인스턴스간의 광역 복제 환경과 같은 가변 대역폭을 가진 네크워크 링크 환경에서 유용합니다.
다음은 혼잡 정책을 설정하는 예 입니다.
리소스 구성파일에 on-congestion 옵션 항목으로 혼잡모드를 설정하고, congestion-fill 항목으로 혼잡 감지 임계치를 설정합니다.
 Code Block
resource <resource> {
  disknet {
    resyncsndbuf-ratesize 40M1G;  
    on-congestion c-min-rate 40M;  pull-ahead;
    congestion-fill 900M;
    c-plan-ahead 0;  
    ...
  }
  ...
}
resync-rate, c-min-rate 설정은 초당 바이트 단위로 지정됩니다. 기본 단위는 Kibibyte이고 4096의 값은 4MiB로 해석됩니다.
 Info
Important 
  • c-plan-ahead 파라미터가 양수 값으로 설정되어 있을 경우 동적으로 동기화 속도를 조절합니다. 이 값은 기본적으로 20 으로 설정되어 있으며 고정대역 동기화를 위해서는 이 값을 0 으로 설정해야 합니다.
  • c-min-rate는 복제와 동기화가 동시에 진행될 때 최소한의 동기화 속도를 설정하기 위한 파라미터입니다. 이 값은 기본적으로 250k 로 설정되어 있으며 만약 고정적인 동기화 속도를 보장하려면 resync-rate와 동일한 값 으로 설정해야 합니다. 
가변대역 동기화 
다중 리소스가 복제/동기화 네트워크를 공유하는 구성일 경우 고정대역 동기화는 최적의 방법이라 할 수 없습니다. 동일한 복제 네트워크를 공유하기 때문에 특정 복제 리소스 채널에 대해서 동기화율이 점유 당할 경우 다른 리소스들은 고정 동기화율이 보장되지 않게 됩니다. 이 경우, 가변대역 동기화를 통해 각각의 복제 채널의 동기화율을 동적으로 조정 하도록 구성하여 동기화율이 점유당하는 것을 완화시킬 수 있습니다. bsr은 이 모드에서 초기 동기화 속도를 결정한 후 자동 제어 루프 알고리즘을 통해 지속적으로 동기화 속도를 조정합니다. 이 알고리즘은 포그라운드 복제가 가능하도록 충분한 대역폭을 보장하며, 백그라운드 동기화가 포그라운드 I/O에 미치는 영향을 크게 완화시킵니다.
가변대역 동기화를 위한 최적의 구성은 사용 가능한 네트워크 대역폭, 응용 프로그램 I/O 패턴 및 복제 링크 혼잡상황에 따라 달라질 수 있으며, 복제 가속기(DRX) 사용 여부에 따라 최적의 구성 설정이 달라질 수 있습니다. 
 Info
동기화 속도 추정
아래와 같은 수식으로 동기화 시간을 추정할 수 있습니다.
tresync = D/R
  • tresync 는 동기화 예상 시간입니다.
  • D는 별다른 영향(복제 링크가 끊어진 상황에서 데이터가 수정되는 등)을 거의 받지 않는다는 가정하에서 동기화될 데이터의 크기를 말합니다.
  • R은 조정 가능한 동기화율이며 이는 복제 네트워크 환경 및 I/O 서브시스템의 처리능력에 따라 한계 값이 달라집니다.
혼잡 모드
 Info
비동기 방식 복제에서 만 사용합니다.
복제 대역폭이 가변적인 환경(WAN 복제 환경)에서는 때때로 복제 링크가 정체 될 수 있습니다. 이로 인해 Primary 노드의 I/O가 대기하게 되면 로컬 I/O의 성능저하가 발생하기 때문에 바람직하지 않습니다. 이러한 혼잡 상황을 감지할 경우 진행 중인 복제를 일시 중단하도록 구성할 수 있습니다. 대신 이렇게 복제가 중단되는 상황에서는 Primary 측의 데이터 세트가 Secondary의 데이터보다 앞선 상태(Ahead)가 되고 이 앞서간 데이터 블럭들은 OOS(Out-Of-Sync) 로 기록하여 혼잡이 해제되면 이미 기록한 OOS를 백그라운드 재동기화를 통해 해소합니다. 다음은 혼잡 정책을 설정하는 예 입니다.
...
congestion-extents 5500;
    congestion-highwater 20000;
    ...
  }
  ...
}
pull-ahead 옵션은 congestion-fill, congestion-extents 또는 congestion-highwater 와 함께 사용됩니다. 각 속성의 권장 값은 다음과 같습니다.
  • congestion-fill은 sndbuf-size 크기의 약 90% 로 설정합니다. 복제 가속기(DRX)를 연동하는 경우 DRX 버퍼의 90% 로 설정합니다.
    • 단, 버퍼의 크기가 10GB 이상 수준으로 크게 할당될 경우 90% 수준의 임계치가 혼잡을 감지하기에는 과도하게 큰 값일 수 있으므로 이는 튜닝을 통해 적정 수치로 조정할 필요가 있습니다.
  • congestion-extents의 권장 값은 al-extents 설정값의 90%입니다.
  • congestion-highwater 는 패킷 개수 기반으로 혼잡을 감지하는 기능입니다. 특히 용량 기반으로 복제 혼잡을 감지하기에 적합하지 않은 DR 환경에서 사용하기에 적당합니다. 기본값 20000 으로 설정되어 있으며 기본 활성화 됩니다. 0으로 설정시 비활성화 되며 최대값은 1000000 입니다.
 Info
송신버퍼(sndbuf)와 DRX 버퍼
bsr 에 설정하는 송신버퍼(sndbuf) 는 커널 메모리에서 직접 할당하기 때문에 크게 할당하기 어렵습니다. 시스템에 따라 차이는 있지만 보통 1GB 내에서 크기를 지정하는 것으로 제한할 필요가 있습니다. 그렇지 않을 경우 송신버퍼 할당으로 인해 시스템 커널 메모리가 부족해지면 시스템 동작과 성능에 영향을 줄 수 있습니다. 
따라서 대용량 버퍼를 구성해야 할 경우는 DRX 버퍼로 구성할 것을 권장합니다.
디스크 플러시
복제 중 타깃 노드가 전원장애로 인해 갑자기 다운된다면 디스크 캐쉬 영역이 배터리 백업 장치(BBWC)에 의해 백업되어 있지 않을 경우 데이터 유실이 발생할 수 있습니다. 복제에선 이를 미연에 방지하기 위해 데이터를 타깃의 디스크에 쓰는 과정에서 데이터를 미디어에 기록하고 난 후 flush 동작을 항상 수행하여 데이터 유실을 예방 합니다. 
반면에, BBWC 가 장착된 스토리지 장치에선 디스크 플러시 동작을 굳이 할 필요가 없으므로 다음과 같이 플러시를 비활성화 할 수 있도록 옵션으로 제공합니다.
 Code Block
resource <resource>
  disk {
    disk-flushes no;
    md-flushes no;
    ...
  }
  ...
}
배터리 백업 쓰기 캐시 (BBWC)가있는 장치에서 bsr을 실행할 때만 장치 플러시를 비활성화해야합니다. 대부분의 스토리지 컨트롤러는 배터리가 소진되면 쓰기 캐시를 자동으로 비활성화하고 배터리가 소진되면 쓰기(write through) 모드로 전환합니다.
정합성 검증
정합성 검증은 복제 수행 도중 복제 트래픽을 블럭 단위로 실시간 검증하거나 전체 디스크 볼륨 단위로 (사용된 영역에 대해서) 소스와 타깃의 데이터가 완전히 일치하는지 해쉬 요약 기반으로 비교하는 기능입니다.
트래픽 검사
블럭 계층에서 데이터를 전송하지만 데이터를 전송하는 다른 계층의 구성요소에서 예기치 않은 오류가 발생할 수 있습니다. 다음과 같은 상황들이 자주 발생하지는 않지만 대비해야 합니다.
  • 전송노드의 주 메모리에서 네트워크 인터페이스로 전달된 데이터에서 발생하는 비트플립 오류
    • 최근 랜카드에서 제공하는 TCP 체크섬 오프로드 기능이 활성화 될 경우 비트플립 오류가 하드웨어 수준에서 발생할 수 있습니다.
  • 수신노드의 네트워크 인터페이스에서 주 메모리로 전송된 데이터에서 발생하는 비트플립 오류
  • 네트워크 인터페이스 펌웨어 또는 드라이버 내에서의 버그 또는 경합상태로 인한 데이터 손상
  • 노드간 재조합 네트워크 구성 요소(라우터나 스위치)에 의해 주입 된 비트 플립 또는 임의적 손상(직접 연결, 백투백 연결을 사용하지 않는 경우).
bsr 은 암호화 메시지 요약 알고리즘을 사용하여 양 노드 간의 메시지 정합성을 검증합니다. 이 기능을 사용하게 되면 모든 데이터 블록의 메시지 요약본을 생성하고 그것을 상대 노드에게 전달한 후 상대편 노드에서 복제 패킷의 정합성을 확인합니다. 만약 요약된 블럭이 서로 일치하지 않으면 재전송을 요청합니다.
복제 트래픽의 정합성 검사는 기본적으로 비활성화되어 있습니다. 이를 활성화하려면 /etc/bsr.conf의 리소스 구성에 다음과 같은 내용을 추가합니다.
 Code Block
resource <resource> {
  net {
    sndbuf-size 20M;
    on-congestion pull-aheaddata-integrity-alg <algorithm>;
  }
 congestion-fill 2G;
    congestion-extents 2000;
    ...
  }
  ...
}
pull-ahead 옵션은 congestion-fill 및 congestion-extents와 함께 사용됩니다. congestion-fill의 권장 값은 다음과 같습니다.
  • 복제 가속기(DRX)를 연동하는 경우 DRX 버퍼 크기의 약 90% 로 설정합니다. 
  • DRX를 연동하지 않을 경우엔 sndbuf-size 의 90% 크기로 설정합니다
  • congestion-extents의 권장 값은 al-extents 설정값의 90%입니다.
디스크 플러시
복제 중 타깃 노드가 전원장애로 인해 갑자기 다운된다면 디스크 캐쉬 영역이 배터리 백업 장치(BBWC)에 의해 백업되어 있지 않을 경우 데이터 유실이 발생할 수 있습니다. 복제에선 이를 미연에 방지하기 위해 데이터를 타깃의 디스크에 쓰는 과정에서 데이터를 미디어에 기록하고 난 후 flush 동작을 항상 수행하여 데이터 유실을 예방 합니다. 
...
 ...
}
<algorithm>은 시스템의 커널 구성에서 커널 암호화 API가 지원하는 메시지 해싱 압축 알고리즘입니다. Windows 에서는 crc32c 만 지원합니다.
양 노드의 리소스 구성을 똑같이 변경한 후, 양 노드에서 bsradm adjust <resource>를 실행하여 변경사항을 적용시킵니다. 
온라인 정합성 검사
온라인 정합성 검사는 장치 운영 중에 노드 간의 블록별 데이터의 정합성을 확인하는 기능입니다. 정합성 검사는 중복 검사하지 않으며 파일시스템에 의해 사용하고 있는 영역에 대해서만 검사하는 것을 기본 동작으로 합니다. 지원하지 않는 파일시스템은 전체 검사 합니다.
동작방식은 다음과 같습니다. 한 쪽 노드에서(verification source) 특정 리소스 스토리지상의 모든 데이터 블럭을 순차적으로 암호화 요약(cryptographic digest)시키고, 요약된 내용을 상대 노드(verification target)로 전송하여 같은 블럭위치의 내용을 요약 비교 합니다. 만약 요약된 내용이 일치하지 않으면 해당 블럭은 out-of-sync로 표시되고 나중에 동기화대상이 됩니다. 여기서 블럭의 전체 내용을 전송하는 것이 아니라 최소한의 요약본만 전송하기 때문에 네트워크 대역을 효율적으로 사용하게 됩니다.
리소스의 정합성을 검증하는 작업은 운영 중에 검사하기 때문에 온라인 검사와 복제가 동시에 수행될 경우 약간의 복제성능 저하가 있을 수 있습니다. 하지만 서비스를 중단할 필요가 없고 검사 중이거나 검사 후 동기화 과정에서 서비스의 다운 타임이 발생하지 않는 장점이 있습니다. 
보통 온라인 정합성 검사는 OS에 예약된 작업으로 등록하여 운영 I/O 부하가 적은 시간 대에 주기적으로 수행하는 것이 일반적 입니다.
활성화
온라인 정합성 검사는 기본적으로 비활성화 되어 있으며 bsr.conf 내의 리소스 구성에 다음과 같은 내용을 추가하여 활성화 합니다.
 Code Block
resource <resource> {
 disk   net {
    disk-flushes no;
    md-flushes no;
    ...
  }
         verify-alg <algorithm>;
   }
   ...
}
배터리 백업 쓰기 캐시 (BBWC)가있는 장치에서 bsr을 실행할 때만 장치 플러시를 비활성화해야합니다. 대부분의 스토리지 컨트롤러는 배터리가 소진되면 쓰기 캐시를 자동으로 비활성화하고 배터리가 소진되면 쓰기(write through) 모드로 전환합니다.
정합성 검증
정합성 검증은 복제를 수행하는 과정에서 복제 트래픽을 블럭 단위로 실시간 수행하거나 전체 디스크 볼륨 단위로 (사용된 영역에 대해서) 소스와 타깃의 데이터가 완전히 일치하는지 해쉬 요약을 기반으로 블럭단위로 비교하는 기능입니다.
트래픽 검사
bsr 은 암호화 메시지 요약 알고리즘을 사용하여 양 노드 간의 메시지 정합성을 검증할 수 있습니다. 이 기능을 사용하게 되면 bsr 은 모든 데이터 블록의 메시지 요약본을 생성하고 그것을 상대 노드에게 전달한 후 상대편 노드에서 복제 패킷의 정합성을 확인합니다. 만약 요약된 블럭이 서로 일치하지 않으면 재전송을 요청합니다.
bsr 은 데이터 복제 시 이러한 정합성 검사를 통해 다음과 같은 에러 상황들에 대해 소스 데이터를 보호할 수 있으며, 만약 이와 같은 상황들에 대응하지 못하면 잠재적으로 복제 중 데이터 손상이 야기될 수 있습니다.
  • 주 메모리와 전송 노드의 네트워크 인터페이스 사이에서 전달된 데이터에서 발생하는 비트 오류 (비트 플립).
    • 최근 랜카드가 제공하는 TCP 체크섬 오프로드 기능이 활성화 될 경우 하드웨어적인 비트플립이 소프트웨어 적으로 감지되지 않을 수 있습니다
  • 네트워크 인터페이스에서 수신 노드의 주 메모리로 전송되는 데이터에서 발생하는 비트 오류(동일한 사항이 TCP 체크섬 오프 로딩에 적용됩니다).
  • 네트워크 인터페이스 펌웨어 또는 드라이버 내에서의 버그 또는 경합상태로 인해 손상된 상태.
  • 노드간에 재조합 네트워크 구성 요소에 의해 주입 된 비트 플립 또는 임의의 손상 (직접 연결, 백투백 연결을 사용하지 않는 경우).
복제 트래픽의 정합성 검사는 기본적으로 비활성화되어 있습니다. 이를 활성화하려면 /etc/bsr.conf의 리소스 구성에 다음과 같은 내용을 추가합니다.
 Code Block
resource <resource> {
  net {
    data-integrity-alg <algorithm>;
  }
  ...
}
<algorithm>은 시스템의 커널 구성에서 커널 암호화 API가 지원하는 메시지 해싱 압축 알고리즘입니다. Windows 에서는 crc32c 만 지원합니다.
양 노드의 리소스 구성을 똑같이 변경한 후, 양 노드에서 bsradm adjust <resource>를 실행하여 변경사항을 적용시킵니다. 
온라인 정합성 검사
온라인 정합성 검사는 장치 운영 중에 노드 간의 블록별 데이터의 정합성을 확인하는 기능입니다. 정합성 검사는 중복 검사하지 않으며 네트워크 대역폭을 효율적으로 사용하고 파일시스템에 의해 사용하고 있는 영역에 대해서 검사하는 것을 기본 동작으로 합니다.
온라인 정합성 검사는 한 쪽 노드에서(verification source) 특정 리소스 스토리지상의 모든 데이터 블럭을 순차적으로 암호화 요약(cryptographic digest)시키고, 요약된 내용을 상대 노드(verification target)로 전송하여 같은 블럭위치의 내용을 요약 비교 합니다. 만약 요약된 내용이 일치하지 않으면, 해당 블럭은 out-of-sync로 표시되고 나중에 동기화대상이 됩니다. 여기서 블럭의 전체 내용을 전송하는 것이 아니라 최소한의 요약본만 전송하기 때문에 네트워크 대역을 효과적으로 사용하게 됩니다.
리소스의 정합성을 검증하는 작업은 운영 중에 검사하기 때문에 온라인 검사와 복제가 동시에 수행될 경우 약간의 복제성능 저하가 있을 수 있습니다. 하지만 서비스를 중단할 필요가 없고 검사를 하거나 검사 후 동기화 과정 중에서 시스템의 다운 타임이 발생하지 않는 장점이 있습니다. 
보통 온라인 정합성 검사에 따른 작업은 OS에서 예약된 작업으로 등록하여 운영 I/O 부하가 적은 시간 대에 주기적으로 수행하는 것이 일반적인 사용법입니다. 
활성화
온라인 정합성 검사는 기본적으로 비활성화되어 있는데, bsr.conf 내의 리소스 구성에 다음과 같은 내용을 추가하면 활성화할 수 있습니다algorithm 은 메시지 해싱 알고리즘을 말하며 OS 커널에서 제공하는 다양한 알고리즘을 사용할 수 있습니다.(Windows 에선 crc32c 만 지원합니다.)
온라인 검증을 활성화 하기 위해 양 노드의 리소스 구성을 똑같이 변경한 후, 양 노드에서 bsradm adjust <resource>를 실행하여 변경사항을 적용시킵니다.
온라인 정합성 검사 실행
온라인 정합성 검사를 활성화한 후, 다음 명령을 사용하여 검사를 실행할 수 있습니다.
 Info
bsradm verify <resource>
온라인 검사가 실행되면, bsr 은 <resource>에서 동기화되지 않은 블록을 알아내 표시하고 이를 기록합니다. 이때 디바이스를 사용하는 모든 응용 프로그램은 아무런 제약 없이 동작할 수 있으며, 리소스의 역할 변경도 가능합니다.
verify 명령은 디스크 상태를 UpToDate로 변경한 후 검증을 수행합니다. 따라서 초기싱크가 완료된 이후 UpToDate 인 복제 소스 노드 측에서 수행하는 것이 바람직 합니다. 예를 들어, Inconsistent 상태의 디스크 노드 측에서 verify를 수행하면 디스크 상태가 UpToDate로 변경 되어 운영 상 문제가 될 수 있으므로 주의가 필요합니다.
검증이 실행되는 동안 out-of-sync 블록이 감지되면, 검증이 완료된 후에 다음 명령으로 동기화할 수 있습니다. 이 때 동기화가 되는 방향은 Primary 노드에서 Secondary 방향으로 이루어지며 Secondary/Secondary 상태에서는 동기화를 진행하지 않습니다. 따라서 Online 검증에 따른 OOS를 해소하기 위해선 소스 측 노드에 대한 Primary로의 승격이 요구됩니다. 
 Code Block
bsradm disconnect <resource>
bsradm connect <resource>
정합성 검사는 수행 도중 때에 따라 취소할 수 있습니다.
 Code Block
bsradm verify-stop <resource>
자동 검사
정기적으로 정합성 검사를 할 필요가 있다면, 다음과 같은 방법으로 bsradm verify <resource> 명령을 작업 스케줄러에 등록합니다.
우선 노드 중 하나에서 특정 위치에 다음과 같은 내용의 스크립트 파일을 만듭니다. 
 Info
bsradm verify <resource>
모든 리소스를 검증하려면 <resource> 대신 all 키워드를 사용하면 됩니다. 
다음은 schtasks(windows 스케줄 설정 명령어)를 사용해 예약된 작업을 생성하는 예 입니다. 다음과 같이 설정 하면 매주 일요일 자정 42분에 온라인 정합성 검사를 수행하게 됩니다.
 Code Block
 schtasks /create /tn "bsr_verify" /tr "%bsr_path%\verify.bat" /sc WEEKLY /D sun /st 00:42
역할 유지
리소스 역할은 운영 상황에 따라 변경될 수 있지만, 때로는 역할을 지속해서 운영하는 방식이 필요할 수 있습니다. (BSR 1.7.3 이상)
persist-role 이 설정된 리소스는 재 시작 되는 시점에 명시적으로(bsradm 명령으로) 지정된 리소스 역할을 계속 유지합니다. 복제 서비스 또는 시스템이 리부팅되어 리소스가 재 시작되는 모든 상황에서 동작합니다.
 Code Block
resource <resource> {
   net {
       verify-alg <algorithm>;
   }
   ...
}
algorithm 은 메시지 해싱 알고리즘을 말하며 Windows 에선 crc32c 만 지원합니다.
온라인 검증을 활성화 하기 위해 양 노드의 리소스 구성을 똑같이 변경한 후, 양 노드에서 bsradm adjust <resource>를 실행하여 변경사항을 적용시킵니다.
온라인 정합성 검사 실행
온라인 정합성 검사를 활성화한 후, 다음 명령을 사용하여 검사를 실행할 수 있습니다.
 Info
drbdadm verify <resource>
온라인 검사가 실행되면, bsr 은 <resource>에서 동기화되지 않은 블록을 알아내 표시하고 이를 기록합니다. 이때 디바이스를 사용하는 모든 응용 프로그램은 아무런 제약 없이 동작할 수 있으며, 리소스의 역할 변경도 가능합니다.
verify 명령은 디스크 상태를 UpToDate로 변경한 후 검증을 수행합니다. 따라서 초기싱크가 완료된 이후 UpToDate 인 복제 소스 노드 측에서 수행하는 것이 바람직 합니다. 예를 들어, Inconsistent 상태의 디스크 노드 측에서 verify를 수행하면 디스크 상태가 UpToDate로 변경 되어 운영 상 문제가 될 수 있으므로 주의가 필요합니다.
검증이 실행되는 동안 out-of-sync 블록이 감지되면, 검증이 완료된 후에 다음 명령으로 동기화할 수 있습니다. 이 때 동기화가 되는 방향은 Primary 노드에서 Secondary 방향으로 이루어지며 Secondary/Secondary 상태에서는 동기화를 진행하지 않습니다. 따라서 Online 검증에 따른 OOS를 해소하기 위해선 소스 측 노드에 대한 Primary로의 승격이 요구됩니다. 
 Code Block
drbdadm disconnect <resource>
drbdadm connect <resource>
자동 검사
정기적으로 정합성 검사를 할 필요가 있다면, 다음과 같은 방법으로 bsradm verify <resource> 명령을 작업 스케줄러에 등록합니다.
우선 노드 중 하나에서 특정 위치에 다음과 같은 내용의 스크립트 파일을 만듭니다. 
 Info
drbdadm verify <resource>
모든 리소스를 검증하려면 <resource> 대신 all 키워드를 사용하면 됩니다. 
다음은 schtasks(windows 스케줄 설정 명령어)를 사용해 예약된 작업을 생성하는 예 입니다. 다음과 같이 설정 하면 매주 일요일 자정 42분에 온라인 정합성 검사를 수행하게 됩니다.
...
  options {
    persist-role yes;
  }
  ...
}
단방향 복제
전환(switchover)이나 절체(failover)없이 항상 주 노드에서 대기노드로의 단방향 복제만 하고 싶다면 대기 노드 측의 타깃 전용(target-only) 속성을 고려하십시오. (BSR 1.7.3 이상)
  • 위에서 설명한 persist-role 속성을 리소스 options 섹션에 설정하여 주 노드와 대기노드의 역할(role)을 고정합니다.
  • target-only 속성을 대기 노드 측에 설정하여 복제/동기화 방향을 주 노드에서 대기노드 한 쪽 방향으로만 강제합니다. target-only 가 적용된 노드를 타깃 전용 노드라고 합니다.
타깃 전용 노드는 명시적인 명령을 포함한 모든 복제/동기화 동작에서의 소스 역할이 금지되고 타깃 역할만 가질 수 있습니다. 그리고 소스 역할로 동작하는 수동 동기화나 승격 명령 등은 모두 차단됩니다(단, 연결 해제 시 승격 허용됨).
 Code Block
resource <resource> {
  options {
    persist-role yes;
  }
  
  on active {
    ...
  }
  
  on standby-DR {
    ...
    options {
      target-only yes;
      ...
    }
  }
  ...
}
 Info
타깃 전용 노드의 데이터 확인
복제 연결을 해제한 후 승격을 통해 데이터를 확인할 수 있습니다. 데이터 확인을 위해 승격을 한 시점에는 SB가 발생한 상태이므로 복제를 다시 정상화하려면 다시 강등 후 SB 해결로 처리합니다.