...

The basic

bsr synchronizes and replicates the volumes of hosts in a cluster in real time over the network.

Based on Windows DRBD (wdrbd) forked from drbd (http://www.drbd.org), it is is an open source project built as a cross-platform common engine to support both Windows and Linux platforms. It inherits all the basic concepts and functions of Windows DRBD, and provides solutions to build a more stable and efficient replication environment by supplementing the problems and functions of DRBD9.

bsr is free to contribute and participate in development through the open source community (bsr) (For technical support or inquiries regarding bsr, please contact to github issues for bsr or Mantech's dev3@mantech.co.kr )

Basic

bsr replicates

Synchronization and Replication

To replicate, volume data on both hosts must first match. To achieve this, bsr performs a process of copying data from the source to the target using disk blocks as a unit, which is called synchronization.

Once synchronization is complete, both volumes will be in a completely identical state, and if data changes occur on the source side, only the changes will be reflected to the target side to maintain the consistency of both volumes.

Here, when data on the source side changes, the operation of reflecting the change in real time to the target side is called replication. Synchronization operates slowly in the background, while replication occurs quickly in the context of local I/O.

Replication works in the following way:

• The application writes data to the block device and replicates while replicating it in real time.

• Real-time replication does not affect other application services or system elements.

• Replicate synchronously or asynchronously

  • The In the synchronous method treats , replication as is considered complete when the replication data is has been written to the local disk and the target host's disk.

  • The asynchronous method treats replication as completed complete when replication data is written to the local disk and data is transferred to socket’s tx buffer.

Kernel Driver

The core engine of bsr was developed as a kernel driver.

The kernel driver is located at the disk volume layer, and controls write I/O from the file system in block units. And as it performs replication in the lower layer of the file system, it is suitable for high availability by providing a transparent replication environment independent of the file system and application. However, since it is located in the lower layer of the file system, it cannot control general operations related to files. For example, it is not possible to detect damage to the file system or control pure file data. It is only replicate in blocks written to disk.

...

• • transmitted to the target host.

Synchronization and replication operate separately within bsr, but can occur simultaneously at a single point in time. In other words, since replication can be processed simultaneously while synchronization is being performed (the operating node processes synchronization and simultaneously replicates write I/O that occurs during operation), the throughput between each node must be appropriately adjusted within the range of the maximum network bandwidth. . For information on setting the sync band, see https://mantech.jira.com/wiki/spaces/BUGE/pages/1419935915/Working#Adjusting-the-synchronization-speed.

Kernel drivers

The core engine of BSR is implemented as a kernel driver.

The kernel driver sits at the disk volume layer and provides block-by-block control over write I/O from the filesystem. Because it sits at the lower layer of the filesystem, it provides a transparent replication environment that is independent of the filesystem and the application, making it ideal for building high availability. However, being at the lower layer of the filesystem means that it has no control over common operations on files. For example, it can't detect corruption in the filesystem or control the file data - it just replicates it block by block as it is written to disk.

BSR provides Active-Passive clustering by default, not support Active-Active clustering.

위의 경우 직접 디스크를 가져다가 동기화 하지 않고 bsr의 일반적인 초기 동기화를 진행한다면 매우 오랜 시간이 걸릴 것입니다. 디스크 크기가 크고 물리적으로 직접 복사하여 초기화를 시킬 수 있다면 이 방법을 권장합니다.  운송 동기화 사용을 참고 하세요

관리 도구

bsr은 리소스를 구성하고 관리하기 위한 용도의 관리 도구를 제공합니다. 다음에서 설명하는 bsradm, bsrsetup, bsrmeta, bsrcon 으로 구성됩니다. 관리 명령어를 사용하기 위해 관리자 수준의 권한이 요구됩니다.

bsradm

• bsr의 세부 기능들에 대해 추상화한 상위 수준 명령어를 제공하는 유틸리티입니다. bsradm 을 통해 bsr 대부분의 동작을 제어할 수 있습니다.

• bsradm은 구성파일 etc\bsr.conf로부터 모든 구성 파라미터를 얻으며, bsrsetup 및 bsrmeta에 적절한 옵션을 주어 명령을 전달하는 역할을 합니다. 즉 실제 동작은 bsrsetup, bsrmeta 에서 수행됩니다.

• bsradm은 –d 옵션을 통해 dry-run모드로 실행시킬 수 있습니다. 이는 bsradm이 bsrsetup 및 bsrmeta 명령을 실제 호출하지 않고, 어떤 옵션 조합으로 실행되는지 미리 확인할 수 있는 방법을 제공합니다.

• bsradm 명령 옵션에 대한 자세한 사항은 Appendix B. 시스템 매뉴얼의 bsradm을 참고하십시요.

bsrsetup

• bsr 커널엔진에 필요한 값들을 설정할 수 있습니다. bsrsetup에 대한 모든 파라미터는 텍스트 인자로 전달해야 합니다.

• bsradm과 bsrsetup의 분리를 통해 유연한 명령 체계를 제공합니다.

  • bsradm에서 받아들인 파라미터는 보다 복잡한 파라미터로 치환하여 bsrsetup을 호출합니다.

  • bsradm은 리소스 구성파일의 문법적 오류 등을 확인하여 사용자 실수를 방지하지만, bsrsetup은 이러한 문법적 오류를 확인하지 않습니다.

• 대부분의 경우에선 bsrsetup을 직접 사용할 필요는 없으나 노드 간 개별제어 라든지 특수한 기능을 수행하기 위해 사용합니다.

• bsrsetup 명령 옵션에 대한 자세한 사항은 Appendix B. 시스템 매뉴얼의 bsrsetup 을 참고하십시요.

bsrmeta

• 복제 구성을 위한 메타 데이터 파일을 생성하거나, 메타에 대한 덤프, 복원 및 수정 기능을 제공합니다. bsrsetup처럼 대부분의 경우에 있어선 직접 bsrmeta를 사용할 필요가 없고 bsradm에서 제공하는 명령을 통해 메타 데이터를 제어합니다.

• bsrsetup 명령 옵션에 대한 자세한 사항은 Appendix B. 시스템 매뉴얼의 bsrmeta 를 참고하십시요. 

bsrcon

• bsr 관련 정보를 확인하거나 기타 필요한 설정을 조정할 수 있습니다.

• bsrcon 명령 옵션에 대한 자세한 사항은 Appendix B. 시스템 매뉴얼의 bsrcon 을 참고하십시요.

리소스

리소스는 복제 데이터 세트를 구성하기 위해 필요한 모든 것을 추상화한 대상입니다. 사용자는 리소스를 구성한 후 이를 제어함으로써 복제 환경을 운영합니다.

리소스를 구성하기 위해서 다음의 기본적인 내용들(리소스 이름, 볼륨, 네크워크 연결)을 지정해야 합니다.

리소스 이름

• 공백없이 US-ASCII 형태로 이름을 지정합니다.

볼륨

• 리소스는 공통의 복제 스트림을 공유하는 하나 이상의 볼륨으로 구성된 복제 그룹이며 리소스내의 모든 볼륨의 쓰기 정합성을 보장합니다.

• 볼륨은 하나의 장치로 기술하며 윈도우즈의 경우 드라이브 레터(drive letter)로 지정합니다.

• 하나의 복제 셋에는 데이터 복제를 위한 볼륨 한 개와 볼륨과 연계된 메타데이터를 저장하는 별도의 볼륨이 필요합니다. 메타 볼륨은 복제를 위한 내부 정보를 저장하고 관리하는 용도로 사용합니다.

  • 메타데이터는 저장하는 위치에 따라 외부 메타 형식(External Meta Type)과 내부 메타 형식(Internal Meta Type)으로 구분합니다. 예를 들어, 복제 대상 볼륨의 디스크내에 메타 데이터가 위치하면 내부 메타이고, 다른 장치 또는 다른 디스크에 위치하면 외부 메타가 됩니다.

  • bsr은 운영 중 복제 I/O 와 메타 데이터 쓰기가 동시에 수행될 수 있기 때문에 성능적인 측면에서 외부 메타 형식이 내부 메타에 비해 유리합니다. 그리고 메타 디스크의 I/O성능은 복제 성능에 직접적으로 영향을 주기 때문에, 되도록 이면 좋은 성능의 디스크로 구성하는게 좋습니다.

  • 주의할 점은, 메타를 위한 볼륨은 NTFS같은 파일시스템으로 포맷하지 않고 RAW 상태로 구성해야 한다는 것 입니다.

네트워크 연결(Connection)

• Connection은 두 호스트 사이의 복제 데이터 세트를 위한 통신 링크입니다.

• 각 리소스들은 다중 호스트들 간에 완전 메시(full-mesh) 연결 설정을 포함한 다중 호스트로 정의합니다.

• 연결 Name은 특별히 지정되지 않았을 경우 bsradm 수준에서 리소스 Name으로 자동 지정됩니다.

리소스 역할

리소스는 프라이머리(Primary) 또는 세컨더리(Secondary)의 역할을 가집니다.

• Primary는 리소스에 제한 없이 읽기, 쓰기 작업을 할 수 있습니다.

• Secondary는 상대 노드로부터 디스크의 변경된 모든 내용을 수신하여 기록하며 볼륨에 대한 액세스를 허용하지 않습니다. 따라서 응용 프로그램에서는 Secondary 볼륨에 대해선 읽거나 쓸 수 없습니다.

리소스의 역할은 bsr유틸리티 명령을 통해 변경할 수 있습니다. 리소스 역할을 Secondary에서 Primary로 변경할 때는 승격(Promotion)이라고 하고 반대는 강등(Demotion)입니다.

주요 기능

복제 클러스터

bsr은 복제를 위한 노드들의 집합을 복제 클러스터로 정의하며 기본적으로 복제 클러스터 멤버 중 하나의 노드에서만 프라이머리 리소스 역할을 할 수 있는 단일 프라이머리 모드를 지원합니다. 이중 또는 다중 프라이머리 모드는 지원하지 않습니다. 단일 프라이머리 모드 즉, Active-Passive 모델은 페일오버를 위한 고 가용 클러스터에서 데이터 저장매체를 다루는 표준적인 접근 방식입니다.

복제 방식

bsr은 3가지 복제 방식을 지원합니다.

Protocol A. 비동기 방식

비동기 방식은 Primary 노드에서 로컬 디스크에 쓰기를 마치고 동시에 TCP의 송신 버퍼에 쓰기가 완료되었을 때 복제 완료로 간주합니다. 따라서 이 방식은 절체(Fail-over)를 할 경우 로컬에는 썼지만 버퍼에 있던 데이터가 대기노드로 완전히 넘어가지 못할 수 있습니다. 절체 후 대기노드의 데이터는 일관성은 가지지만, 절체 시 발생한 쓰기의 일부 전송되지 못한 업데이트 내용은 손실될 수 있습니다. 이 방식은 로컬 I/O 응답성능이 좋으며 원거리 복제 환경에 적합한 방식입니다.

Protocol B. 세미 동기 방식

세미 동기방식은 Primary 노드에서 로컬 디스크 쓰기가 발생하면 복제 패킷을 상대 측 노드에서 수신 완료한 단계에서 복제 완료로 간주합니다.

일반적으로 강제 절체(Fail-over)시 데이터 손실이 발생되지는 않는 편이지만 양쪽 노드의 전원이 동시에 나가거나 Primary 스토리지에서 복구할 수 없는 손상이 발생한다면 Primary에서 가장 최근에 기록된 데이터는 손실될 수 있습니다.

Protocol C. 동기 방식

동기 방식은 로컬과 원격 양쪽 디스크에 모두 쓰기가 완료되어야 Primary 노드에서 복제 완료로 간주합니다. 따라서 어느 한쪽 노드에서 손실이 발생하더라도 데이터가 유실되지 않음을 보장합니다.

물론, 양쪽 노드(또는 노드의 스토리지 서브시스템) 모두가 동시에 되돌릴 수 없는 손상을 입는다면 데이터의 손실은 불가피합니다.

일반적으로 bsr은 Protocol C 방식을 많이 사용합니다.

복제 방식은 운영정책을 결정하는 요소인 데이터 정합성 여부와 로컬 I/O 지연(Latency) 성능, 처리량(Throughput) 등에 의해 결정되어야 합니다.

복제 모드를 구성하는 예제는 리소스 작성 부분을 참고하세요.

복제 전송 프로토콜

bsr의 복제 전송 네트워크는 TCP/IP 전송 프로토콜을 지원합니다. 

TCP(IPv4/v6)

bsr의 기본 전송 프로토콜이며 IPv4/v6를 지원하는 모든 시스템에서 사용할 수 있는 표준 프로토콜 입니다.

효율적인 동기화

bsr에서 복제(replication)와 (재)동기화(resynchronization)는 구분하는 개념입니다. 복제는 Primary 역할의 리소스의 모든 디스크 쓰기 동작을 Secondary 노드로 실시간 반영하는 동작이고, 동기화는 실기간 쓰기 I/O를 배제한 전체 블록 디바이스 관점에서 데이터를 일치시키는 처리과정 입니다. 복제와 동기화는 개별적으로 동작하지만 동시에 처리될 수도 있습니다.

Primary와 Secondary간의 복제 연결이 유지된다면 복제가 지속적으로 수행됩니다. 그러나 Primary 또는 Secondary 노드에서 장애가 나거나, 복제 네트워크가 단절되는 등의 이유로 복제 연결이 중단되었다면 Primary와 Secondary 간의 동기화가 필요한 상황에 놓입니다.

bsr은 동기화 할 때 원본 I/O가 디스크에 쓰여진 순서대로 블럭을 동기화하지 않습니다. 동기화는 메타데이터의 정보를 기반으로 0번 섹터 부터 마지막 섹터까지 동기화 되지 않은 영역에 대해서만 순차적으로 동기화하고 다음과 같이 효율적으로 처리합니다.

• 동기화는 디스크의 블럭 레이아웃에 따라 블럭 단위로 동기화하므로 디스크 탐색을 거의 수행하지 않습니다.

• 여러 번 연속적으로 쓰기 작업이 발생한 블럭은 한 번만 동기화하여 효율적입니다.

동기화하는 동안 대기(Standby)노드의 전체 데이터 셋 중 일부는 과거의 변경 전 내용이고 일부는 최신으로 업데이트됩니다. 이러한 데이터의 상태를 Inconsistent 상태라고 하고 모든 블럭이 최신 데이터로 동기화 완료된 상태를 UpToDate 상태라고 합니다. Inconsistent 상태의 노드는 일반적으로 볼륨이 사용가능하지 않은 상태이므로 이 상태는 가능한 짧게 유지하는 것이 바람직합니다.

물론 백그라운드에서 동기화가 진행되더라도 Active 노드의 응용 서비스는 중단되거나 하지 않고 계속 운영 가능 합니다.

고정 대역 동기화(Fixed-rate synchronization)

고정 대역 동기화에서는 초당 상대 노드로 동기화하는 데이터 속도를 상한선 내에서 조정할 수 있으며(이를 synchronization rate라고 합니다) 최소값(c-min-rate)과 최대값(c-max-rate)으로 지정할 수 있습니다.

가변 대역 동기화(Variable-rate synchronization)

가변 대역 동기화는 가용한 네트워크의 대역폭을 감지한 후 애플리케이션으로부터 수신된 I/O와  비교하여, 적절한 동기화 속도를 자동적으로 계산합니다. bsr은 가변대역 동기화를 기본 설정으로 합니다.

체크섬 기반 동기화(Checksum-based synchronization)

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

혼잡 모드

bsr은 비동기 복제 시 복제 네트워크의 혼잡도를 감지하여 능동적으로 대처할 수 있는 혼잡모드 기능을 제공합니다. 혼잡모드는 Blocking, Disconnect, Ahead 의 3 가지 동작모드를 제공합니다.

• 아무 설정도 하지 않을 경우 기본적으로 Blocking 모드입니다. Blocking 모드에서는 TX 송신버퍼에 복제 데이터를 전송할 여유 공간이 생길 때 까지 대기(Blocking)합니다.

• 복제 연결을 단절하여 로컬 I/O 부하를 일시적으로 해소하도록 disconnect 모드로 설정할 수 있습니다.

• 복제 연결은 유지한 채 primary 노드의 I/O를 로컬 디스크에 우선 기록하고 해당 영역은 out-of-sync로 기록하여 혼잡이 해제될 경우 재동기화를 자동으로 수행하는 Ahead 모드로 설정할 수 있습니다. Ahead 상태가 된 Primary 노드는 Secondary 노드에 비해 앞서 있는(Ahead) 데이터 상태가 됩니다. 그리고 이 시점에 Secondary는 뒤 쳐진(Behind) 데이터 상태가 되지만 대기노드의 데이터는 일관성은 있는 가용한 상태입니다. 혼잡 상태가 해제되면, 세컨더리로의 복제는 자동으로 재개되고 Ahead 상태에서 복제되지 못했던 out-of-sync 블럭에 대해 백그라운드 동기화를 자동으로 수행합니다. 혼잡모드는 일반적으로 데이터센터 또는 클라우드 인스턴스간의 공유연결을 통한 광역 복제 환경과 같은 가변 대역폭을 가진 네크워크 링크 환경에서 유용합니다.

온라인 데이타 무결성 검사

온라인 무결성 검사는 장치 운영 중에 노드 간의 블록별 데이터의 무결성을 확인하는 기능입니다. 무결성 검사는 네트워크 대역폭을 효율적으로 사용하고 중복된 검사를 하지 않습니다.

온라인 무결성 검사는 한 쪽 노드에서(verification source) 특정 리소스 스토리지상의 모든 데이터 블럭을 순차적으로 암호화 요약(cryptographic digest)시키고, 요약된 내용을 상대 노드(verification target)로 전송하여 같은 블럭위치의 내용을 요약 비교 합니다. 만약 요약된 내용이 일치하지 않으면, 해당 블럭은 out-of-sync로 표시되고 나중에 동기화대상이 됩니다. 여기서 블럭의 전체 내용을 전송하는 것이 아니라 최소한의 요약본만 전송하기 때문에 네트워크 대역을 효과적으로 사용하게 됩니다.

리소스의 무결성을 검증하는 작업은 온라인 중에 검사하기 때문에 온라인 검사와 복제가 동시에 수행될 경우 약간의 복제성능 저하가 있을 수 있습니다. 하지만 서비스를 중단할 필요가 없고 검사를 하거나 검사 이후 동기화 과정 중에 시스템의 다운 타임이 발생하지 않는 장점이 있습니다. 그리고 bsr은 FastSync 를 기본 로직으로 수행하기 때문에 파일시스템이 사용하고 있는 디스크 영역에 대해서만 온라인 검사를 수행하여 보다 더 효율적입니다.

온라인 무결성 검사에 따른 작업은 OS 수준에서 예약된 작업으로 등록하여 운영 I/O 부하가 적은 시간 대에 주기적으로 수행하는 것이 일반적인 사용법입니다. 온라인 무결성 검사를 구성하는 법에 대한 자세한 내용은 온라인 디바이스 검증의 사용(Using on-line device verification)을 참고하세요.

복제 트래픽 무결성 검사

bsr은 암호화 메시지 요약 알고리즘을 사용하여 양 노드 간의 복제 트래픽에 대한 무결성을 실시간 검증할 수 있습니다.

이 기능을 사용하게 되면 Primary는 모든 데이터 블록의 메시지 요약본을 생성하고 그것을 Secondary 노드에게 전달하여 복제 트래픽의 무결성을 확인할 수 있습니다. 만약 요약된 블럭이 일치하지 않으면 재전송을 요청합니다. bsr은 이러한 복제 트래픽 무결성 검사를 통해 다음과 같은 에러 상황들에 대해 소스 데이터를 보호합니다. 만약 이러한 상황들에 대해 미리 대응하지 않는다면 복제 중 잠재적인 데이터 손상이 유발될 수 있습니다.

• 주 메모리와 전송 노드의 네트워크 인터페이스 사이에서 전달된 데이터에서 발생하는 비트 오류 (비트 플립) (최근 랜카드가 제공하는 TCP 체크섬 오프로드 기능이 활성화 될 경우 이러한 하드웨어적인 비트플립이 소프트웨어 적으로 감지되지 않을 수 있습니다).

• 네트워크 인터페이스에서 수신 노드의 주 메모리로 전송되는 데이터에서 발생하는 비트 오류(동일한 고려 사항이 TCP 체크섬 오프 로딩에 적용됩니다).

• 네트워크 인터페이스 펌웨어와 드라이버 내의 버그 또는 경합상태로 인한 손상.

• 노드간의 재조합 네트워크 구성 요소에 의해 주입 된 비트 플립 또는 임의의 손상(직접 연결, 백투백 연결을 사용하지 않는 경우).

스플릿 브레인 통지와 복구

스플릿 브레인(Split brain)은 클러스터 노드들 사이에 모든 네트워크가 단절된 일시적인 장애 상황에서 클러스터 관리 소프트웨어나 관리자의 수동 개입으로 인해 두 개 이상의 노드가 Primary 역할을 가졌던 상황을 말합니다. 이것은 데이터에 대한 수정이 상대 측으로 복제되지 않고 각각의 노드에서 이루어졌다는 것을 암시하며 잠재적인 문제를 발생시킬 수 있는 상황입니다. 이 때문에 데이터가 병합되지 못하고 두 개의 데이터 셋이 만들어질 수도 있습니다.

핫빗(Heartbeat)과 같은 클러스터 노드 간을 관리하는 관리 모듈에서 모든 연결이 끊어졌을 때 판단하는 일반적인 HA 클러스터의 스플릿 브레인과 복제 스플릿 브레인은 구별되어야 합니다. 혼란을 피하기 위하여 앞으로 설명에서는 다음과 같은 규칙을 사용합니다.

• 스플릿 브레인이라 하면 위의 단락에서 언급한대로 복제 스플릿 브레인을 의미합니다.

• 클러스터 환경에서의 스플릿 브레인은 클러스터 파티션(cluster partition)이란 용어로 사용합니다. 클러스터 파티션은 특정 노드에서 모든 클러스터 연결이 끊어졌음을 의미합니다.

bsr에서 스플릿 브레인을 감지하면(이메일 또는 다른 방법을 통해) 자동적으로 운영자에게 알릴 수 있습니다.

디스크 에러 처리 정책

디스크 장비에서 장애가 발생할 경우 bsr은 디스크 장애 정책의 사전 설정을 통해 해당 I/O 에러를 상위 계층(대부분 파일시스템)으로 단순히 전달해서 처리하거나 복제 디스크를 detach 하여 복제를 중단하도록 합니다. 전자는 패스스루 정책, 후자는 분리 정책입니다.

패스스루(passthrough)

하위 디스크 계층에서 에러 발생 시 별도 처리없이 상위(파일시스템) 계층으로 에러 내용을 전달합니다. 에러에 따른 적절한 처리는 상위 계층에게 맡깁니다. 예를 들어, 파일 시스템이 에러 내용을 보고 디스크 쓰기 재시도를 하거나 read-only 방식으로 다시 마운트를 시도할 수 있습니다. 이렇게 오류를 상위 계층으로 전달하는 방식을 통해 파일시스템 스스로가 에러를 인지할 수 있도록 하여 스스로 에러에 대처할 수 있는 기회를 부여합니다.

복제 서비스 운영 경험에 따르면 디스크 장애는 생각보다 자주 발생합니다. 이러한 결과는 하위 디스크 계층에 의존적이며 디스크 계층 즉, 표준 SCSI 계층의 에러는 임의의 시점에 언제든지 발생할 수 있다는 점에 비추어 보면 디스크 계층의 안정성과는 별도로 다루어야 하고, 복제 측면에서도 유연하게 대처할 수 있어야 함을 의미합니다. 그동안 디스크 장애 정책으로 제공해 왔던 detach 정책은 서비스 운영관점에선 복제가 특정시점에 일방적으로 중단되는 정책이었습니다. 이러한 방식은 사후 복구도 어렵고 서비스 운영 지속 측면에서도 불리합니다. 우리는 이러한 문제를 해결하기 위해 passthrough 정책을 고안하였으며 bsr의 기본정책으로 설정하게 되었습니다. 패스스루 정책은 I/O 에러가 발생할 경우 해당 블럭에 대해서 OOS 를 기록하고 실패된 I/O 결과를 파일시스템으로 전달합니다. 이 때 파일시스템이 에러가 발생한 블럭에 대해 쓰기 재시도하여 성공하고 이를 통해 OOS를 해소한다면 이는 일시적인 디스크 계층의 에러를 파일시스템 스스로 극복하도록 유도하게 됩니다. 비록 파일시스템의 동작 특성에 따라 완전히 OOS가 해소되지 못한다고 하더라도 일부 남겨진 OOS 는 연결 재시도 등을 통해 재동기화 하여 해결할 수도 있습니다. 즉 패스스루 정책은 에러 블럭을 FS가 스스로 해결하거나 동기화를 통해 해소하도록 유도하고, 기본적으로 디스크 I/O에 문제가 있더라도 서비스 운영을 지속하도록 보장합니다.

분리(detach)

에러 정책을 detach 방식으로 구성하였다면 하위 계층에서 에러 발생 시 bsr이 자동으로 디스크를 분리(detach)하는 방식으로 처리합니다. 디스크가 detach 되면 diskless 상태가 되고 디스크로의 I/O 가 차단되며, 이에 따라 디스크 장애가 인지되고 장애 후속조치가 취해져야 합니다. bsr에서 diskless 상태는 디스크에 I/O 가 유입되지 못하도록 차단된 상태로 정의합니다. I/O 에러 처리 정책 설정 에서 설정 파일을 구성하는 방법에 대해 설명하고 있습니다.

Outdated 데이터 정책

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

Outdated 디스크 상태는 데이터의 일관성은 보장되지만 Primary 노드와 최신의 데이터로 동기화되지 않았거나 이를 암시하는 데이터 입니다. 이런 경우는 임시적이든 영구적이든 복제 링크가 중단할 경우 발생합니다. 연결이 끊어진 Oudated 데이터는 결국 지난 시점의 데이터 이기 때문에 이러한 상태의 데이터에서 서비스가 되는 것을 막기 위해 bsr은 Outdated 데이터를 가진 노드에 대해 승격(promoting a resource)하는 것을 기본적으로 허용하지 않습니다. 그러나 필요하다면(긴급한 상황에서) Outdated 데이터를 강제로 승격할 수는 있습니다. 이와 관련하여 bsr은 네트워크 단절이 발생하자마자 응용프로그램이 측에서 즉시 Secondary노드를 Outdated 상태가 되도록 만들 수 있는 인터페이스를 갖추고 있습니다. Outdated 상태가 된 리소스에서 해당 복제링크가 다시 연결된다면 Outdated 상태 플래그는 자동으로 지워지며 백그라운드로 동기화(background synchronization)가 완료되어 최종 최신 데이터(UpToDate)로 갱신됩니다.

Primary 가 Crash 되었거나 연결이 단절된 Secondary 노드는 디스크 상태가 Outdated 일 수 있습니다.

운송 동기화

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

• 초기 동기화 할 데이터의 량이 매우 많은 경우(수십 테라바이트 이상)

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

• 사이트간 가용 네트워크 대역폭이 제한적인 경우

Administration tools

BSR provides administrative tools for configuring and managing resources. It consists of bsradm, bsrsetup, bsrmeta, and bsrcon, which are described below. Administrator-level privileges are required to use the management commands.

bsradm

A utility that provides high-level commands that abstract from the detailed functionality of BSR. You can control most of the behaviour of BSR through bsradm.

bsradm gets all its configuration parameters from the configuration file etc\bsr.conf, and is responsible for passing commands to bsrsetup and bsrmeta with the appropriate options. This means that the actual behaviour is done by bsrsetup and bsrmeta.

bsradm can be run in dry-run mode with the -d option. This provides a way to see what combinations of options bsradm will run with, without actually invoking the bsrsetup and bsrmeta commands.

For more information about bsradm command options, see Appendix, bsradm in the Commands.

bsrsetup

Allows you to set the values required by the bsr kernel engine. All parameters to bsrsetup must be passed as text arguments.

The separation of bsradm and bsrsetup provides a flexible command scheme.

The parameters accepted by bsradm are replaced by more complex parameters to call bsrsetup.

bsradm prevents user mistakes by checking resource configuration files for grammatical errors, etc. bsrsetup does not check for these grammatical errors.

In most cases, you will not need to use bsrsetup directly, but use it when you need individual control between nodes or for special functions.

For more information about the bsrsetup command options, see Appendix, bsrsetup in the Commands.

bsrmeta

Provides the ability to create, dump, restore, and modify metadata for replication configurations. Like bsrsetup, most users do not need to use bsrmeta directly; they control metadata through commands provided by bsradm.

For more information about the bsrmeta command options, see Appendix, bsrmeta in the Commands.

bsrcon

View bsr-related information or adjust other necessary settings.

For more information about the bsrcon command options, see Appendix, bsrcon in the Commands.

Resource

A resource is an abstraction of everything you need to construct a replication dataset. You configure resources and control them to operate your replication environment.

To configure a resource, you must specify the following basic things: resource name, volume, and network connectivity.

Resource name

Specify a name in US-ASCII format without spaces.

Volume

• A resource is a replication group consisting of one or more volumes that share a common replication stream. bsr ensures the consistency of all volumes within a resource.

• A volume is described as a single device and is specified by a drive letter in Windows.

• A replica set requires one volume for data replication and a separate volume to store metadata associated with the volume. The meta volume is used to store and manage internal information for replication.

  • Metadata is divided into external and internal meta types based on where it is stored. For example, if the metadata is located on the disk of the volume being replicated, it is internal meta; if it is located on another device or another disk, it is external meta.

  • External meta types have an advantage over internal meta in terms of performance because replication I/O and meta data writing can be performed simultaneously during operation, and the I/O performance of the meta disk directly affects replication performance, so it is recommended to configure it with a high-performance disk as much as possible.

  • The volume for the meta should not be formatted with a filesystem like NTFS and should be configured as RAW.

Network Connections (Connection)

• A Connection is the communication link for a replica dataset between two hosts.

• Each resource is defined as a multi-host with a full-mesh connection setup between multiple hosts.

• The Connection Name is automatically assigned as the Resource Name at the bsradm level unless you specify otherwise.

Resource roles

A resource has a role of either Primary or Secondary.

• Primary can perform unlimited read and write operations on the resource.

• Secondary receives and records all changes to the disk from the other node and does not allow access to the volume. Therefore, applications cannot read or write to a Secondary volume.

The role of a resource can be changed through the bsr utility command. Changing the role of a resource from Secondary to Primary is called a promotion, and the opposite is called a demotion.

Main features

Replication clusters

BSR defines a set of nodes for replication as a replication cluster and supports single-primary mode by default, where only one node among the replication cluster members can act as a primary resource. It does not support multiple-primary mode. Single-primary mode, or the active-passive model, is the standard approach to handling data storage media in a highly available cluster for failover.

Replication methods

BSR supports three replication methods

Protocol A. Asynchronous

The asynchronous method considers replication complete when the primary node finishes writing to its local disk and simultaneously finishes writing to TCP's egress buffer. Therefore, in the event of a fail-over, data that has been written locally but is in the buffer may not fully pass to the standby node. After a failover, the data on the standby node is consistent, but some undelivered updates to writes that occurred during the failover may be lost. This method has good local I/O responsiveness and is suitable for long distant replication environments.

Protocol B. Semi-Synchronous

The semi-synchronous method considers replication to be complete when a local disk write occurs on the primary node and the replication packet is received by the other node.

While a forced fail-over typically does not result in data loss, the most recently written data on the Primary may be lost if both nodes lose power at the same time or if irreparable damage occurs on the Primary storage.

Protocol C. Synchronous

The synchronous method considers replication complete on the primary node when writes to both the local and remote disks are complete, thus ensuring that no data is lost in the event of a loss on either node.

Of course, if both nodes (or the nodes' storage subsystems) suffer irreversible damage at the same time, data loss is inevitable.

In general, BSR relies heavily on the Protocol C method.

The replication method should be determined by data consistency, local I/O latency performance, and throughput, which are factors that determine operational policy.

For an example of configuring replication mode, see Configuration examples.

Transport protocols

BSR's replication transport network supports the TCP/IP transport protocol.

TCP (IPv4/v6)

This is the default transport protocol for BSR and is a standard protocol that can be used on any system that supports IPv4/v6.

Efficient synchronization

As long as the replication connection between the primary and secondary is maintained, replication is performed continuously. However, if the replication connection is interrupted for any reason, such as a primary or secondary node failing, or the replication network being disconnected, synchronization between the primary and secondary is required.

When synchronizing, BSR does not synchronize blocks in the order in which the original I/O was written to the disk. It synchronizes only the unsynchronized areas sequentially, from sector 0 to the last sector, based on information in the metadata, and handles them efficiently as follows.

• Sync performs little disk traversal because it syncs on a block-by-block basis based on the block layout of the disk.

• Blocks with multiple consecutive write operations are synchronized only once, which is efficient.

During synchronization, the entire dataset on the Standby node is updated, some of it before past changes, and some of it up to date. The state of such data is called the Inconsistent state, and the state when all blocks have completed synchronization with the latest data is called the UpToDate state. A node in the Inconsistent state typically means that the volume is not available, so it is desirable to keep this state as short as possible.

Of course, application services on the Active node can continue to operate with little or no interruption while synchronization takes place in the background.

Partial synchronization

Once a full sync has been performed, it always operates as a partial sync. It is efficient by synchronizing only for out-of-sync areas (OOS).

Fast synchronization (FastSync)

bsr implements FastSync, which synchronizes only the parts of the volume that are in filesystem use. Without FastSync, you would have to synchronize over the entire volume, which can take a lot of synchronization time if the volume is large. FastSync is a powerful feature of bsr that can significantly reduce sync time.

Checksum-based synchronization

The efficiency of the synchronization algorithm can be further improved by using a summary of the checksum data. Checksum-based sync reads a block before syncing, obtains a hash summary of what is currently on the disk, and then compares it to the hash summary obtained by reading the same sector from the other node. If the hashes match, it skips the sync rewrite for that block. This can have a performance advantage over simply overwriting the block that needs to be synchronized, and if the file system rewrote the same content to a sector while disconnected (disconnect state), it will skip the re-sync for that sector, which can reduce the overall sync time.

Specify synchronization bandwidth

If you specify a synchronization band within the replication network band, the remaining bands are used as replication bands. If there is no synchronization behavior, all bands will be used as replication. You can specify the minimum value (c-min-rate) and maximum value (c-max-rate).

Fixed-rate synchronization

The data rate synchronized to the counterpart node is fixed to the resync-rate value.

Variable-rate synchronization

Variable-band synchronization handles synchronization between c-min-rate and c-max-rate by detecting available network bandwidth and arbitrating with replication throughput. In variable band synchronization, resync-rate only has the meaning of the initial synchronization band value.

bsr defaults to variable band synchronization.

Fixed-rate synchronization

In fixed-rate synchronization, the data rate of synchronization to the relative node per second can be adjusted within upper bounds (this is called the synchronization rate) and can be specified as a minimum (c-min-rate) and maximum (c-max-rate).

Variable-rate synchronization

Variable-rate sync detects the available network bandwidth and compares it to the I/O received from the application, and automatically calculates the appropriate sync rate. BSR uses variable-rate sync as the default setting.

Congestion mode

BSR provides a congestion mode feature that allows asynchronous replication to detect and proactively deal with congestion on the replication network. Congestion Mode provides three modes of operation: Blocking, Disconnect, and Ahead.

• If no settings are made, it defaults to Blocking mode. Blocking mode waits until there is free space in the TX transmit buffer to send replication data.

• You can set it to disconnect mode to temporarily relieve local I/O load by disconnecting the replication connection.

• It can be set to Ahead mode, which maintains the replication connection but writes the primary node's I/O to local disk first and writes those areas as out-of-sync, automatically resyncing when congestion is released. Once in the Ahead state, the primary node is in the Ahead data state relative to the secondary node, at which point the secondary is in the Behind data state, but the data on the standby node is consistent and available. When the congestion state is lifted, replication to the Secondary automatically resumes and background synchronization is automatically performed for any out-of-sync blocks that could not be replicated in the Ahead state. Congestion mode is typically useful in environments with variable bandwidth network links, such as wide area replication environments over shared connections between data centers or cloud instances.

Online data integrity checks

Online integrity verification is a feature that verifies the integrity of block-by-block data between nodes during device operation. Integrity checks make efficient use of network bandwidth and avoid redundant checks.

Online integrity verification sequentially cryptographically digests all data blocks on a specific resource storage on one node (verification source) and sends the digested contents to the other node (verification target) for summary comparison of the contents of the same block locations. If the summaries do not match, the block is marked as out-of-sync and will be subject to synchronization later. This is an efficient use of network bandwidth because we're not sending the entire contents of the block, just a minimal summary.

Because the work of verifying the integrity of the resource is done online, there may be a slight degradation in replication performance if online checks and replication are performed at the same time. However, it has the advantage of not requiring service interruption and no system downtime during the inspection or post-inspection synchronization process. And because bsr performs FastSync as its underlying logic, it is more efficient by performing online inspection only on the disk area that is being used by the filesystem.

A common usage for online integrity checks is to register them as scheduled tasks at the OS level and perform them periodically during times of low operational I/O load. For more information on how to configure online integrity checks, see Using on-line device verification.

Replication traffic integrity checks

BSR can perform real-time integrity verification of replication traffic between two nodes using a cryptographic message summarization algorithm.

When this feature is enabled, the primary generates a message summary of all data blocks and forwards it to the secondary node to verify the integrity of the replication traffic. If the summarized blocks do not match, it requests a retransmission. BSR uses these replication traffic integrity checks to protect source data against the following error situations. If these situations are not addressed proactively, they can lead to potential data corruption during replication.

• Bit errors (bit flips) that occur in the data passed between main memory and the network interface of the sending node (these hardware bit flips may go undetected by software if the TCP checksum offload feature offered by recent rancards is enabled).

• Bit errors occurring in the data being transferred from the network interface to the receiving node's main memory (the same considerations apply to TCP checksum offloading).

• Corruption caused by bugs or race conditions within the network interface firmware and drivers.

• Bit flips or random corruption injected by recombinant network components between nodes (unless direct, back-to-back connections are used).

Split-brain

A split-brain is a situation where two or more nodes have had a primary role due to manual intervention by the cluster management software or administrator in a temporary failure situation where all networks are disconnected between the cluster nodes. This is a potentially problematic situation because it implies that modifications to the data were made on each node rather than replicated to the other side. This can result in data not being merged and creating two data sets.

BSR provides the ability to automatically detect split brains and repair them. For more information about this, see the Split brain topic in Troubleshooting.

Disk status

The disk status in BSR is represented by one of the following states, depending on the situation.

• Diskless This is the state before the backing device is attached as a replica disk (Attach), or the disk is detached due to an I/O failure (Detach).

• UpToDate The disk data is up to date. If the target's disk is UpToDate, it means it is in a failover-able state.

• Outdated The data is consistent at a point in time, but may not be up to date. If the mirror connection is explicitly disconnected, the target's disk state defaults to Outdated.

• Inconsistent Refers to broken data where data consistency is not guaranteed. If the target's disk is Inconsistent, it is in an incorrigible state by default.

BSR distinguishes between inconsistent and outdated data. Inconsistent data is data that is inaccessible or unusable in some way. Typically, data on the target side of a synchronization is in an inconsistent state. The target data being synchronized is partly current and partly out of date, so it can't be considered data from a single point in time. Also, the filesystems that would have been loaded on the device may not be mountable at this time, or the filesystems may not even be automatically checked.

The Outdated disk state is data that is consistent but not synchronized with the primary node to the most recent data, or data that suggests it is. This happens when a replication link goes down, whether temporarily or permanently. Since disconnected Oudated data is, after all, data from a past point in time, to prevent data in this state from becoming a service, BSR disallows promoting a resource to a node with outdated data by default. However, it can force promotion of outdated data if necessary (in an emergency situation). In this regard, BSR provides an interface that allows applications to immediately cause a secondary node to become Outdated on their side as soon as a network disconnect occurs. Once the replication link is reconnected from the Outdated resource, the Outdated status flag is automatically cleared and a background synchronization is completed to update it to the latest and greatest data (UpToDate). A secondary node with a crashed primary or a disconnected secondary may have an Outdated disk status.

Handling disk I/O errors

When a disk device fails, BSR uses presets in the disk failure policy to either simply pass the I/O error to a higher tier (most likely the filesystem) to handle it, or to detach the replication disk to stop replication. The former is a pass-through policy, the latter a detach policy.

Pass-through

When an error occurs at the lower disk tier, it is passed to the upper (filesystem) tier without further processing. The corresponding handling of the error is left to the higher tier. For example, the filesystem might see the error and attempt to retry writing to the disk or remount in a read-only fashion. This way of passing errors to higher layers allows the filesystem to recognize errors on its own, giving it a chance to react on its own.

Detach

If you configure your error policy to DETACH, BSR will automatically detach the disk when an error occurs at a lower tier. When a disk is detached, it becomes diskless and I/O to the disk is blocked, which means that a disk failure is recognized and failure follow-up should be taken. BSR defines a diskless state as a state in which I/O to the disk is blocked. This is discussed in more detail in Disk failures in Troubleshooting.