디스크 장애

디스크 장애(오류)는 디스크 스토리지 계층의 물리적 연결 단자의 단선, 미디어 파손, 배드 섹터, SCSI 오류 등 얘기치 않은 장애로 인해 디스크 I/O 에 오류가 발생하는 상황을 말합니다. 이러한 장애 들은 일시적으로 발생했다가 정상화 되기도 하고 영구적 장애로 이어지기도 합니다. bsr 에선 이러한 장애를 일시적 장애와 영구적 장애로 구분하고 유형에 따라 오류를 다르게 처리합니다.

일시적 장애는 스토리지 계층에서의 어떤 이유로 인해 오류가 잠시 발생 했다가 다시 정상화되는 상황입니다. 이럴 경우에는 디스크 교체가 필요한 정도의 심각한 상황이 아니기 때문에 되도록이면 서비스 운영을 지속하면서 기 발생된 에러에 대해서만 별도로 해소하고 복제는 계속 운영되도록 하는게 효율적입니다. 즉 일시적 오류 상황에서는 I/O 에러가 발생한 블록 영역을 out-of-sync 로 기록하고 해당 블록으로 재시도된 I/O 가 성공하면 자연스럽게 OOS 가 해소되도록 합니다.

영구적인 디스크 오류는 디스크 교체 등 디스크 장애에 대한 별도 조치가 필요한 상황으로 전체 재구성의 절차를 통해 복구해야 합니다.

...

Disk Error

Disk failure (error) refers to a situation in which disk I / O fails due to an unexpected failure such as disconnection of the physical connection terminal of the disk storage layer, media corruption, bad sector, or SCSI error. These disorders occur temporarily and then become normal and sometimes lead to permanent disorders. bsr categorizes these disorders as temporary and permanent, and treats them differently depending on the type.

Temporary failure is a situation where, for some reason at the storage layer, an error occurs briefly and then normalizes again. In this case, since it is not a serious situation that requires a replacement, it is efficient to keep the service running as much as possible to resolve the errors that have occurred and to keep the replication running. That is, in a temporary error situation, the block area where the I/O error occurred is recorded as out-of-sync, and if the I/O retried with the block succeeds, the OOS is naturally resolved.

Permanent disk failures require recovery from disk failures, such as disk replacement, and must be repaired through a full rebuild configuration procedure.

I/O error handling policy is set through the on-io-error option in the resource <disk> section.

resource <resource> {
  disk {
    on-io-error <strategy>;
    ...
  }
  ...
}

해당 옵션을 <common> 섹션에 정의한다면 모든 리소스에 적용됩니다.

<strategy>는 다음과 같은 세 가지 옵션이 있습니다.

...

If the option is defined in the <common> section, it applies to all resources.

<strategy> has three options:

...

• passthrough The default value of on-io-error의 기본값으로 error is to report I/O 오류를 상위 계층에 보고합니다errors to the upper layer. I/O 오류는 Primary 노드일 경우 마운트 된 파일시스템으로 보내고, Secondary 노드에서는 Primary 노드로 쓰기 결과를 전달하거나 (복제 연결이 없을 경우)무시 됩니다. 이때 디스크 상태는 현 상태를 유지하며 해당 에러블럭에 대해 OOS로 기록합니다.

• detach lower-level I/O 에러가 발생하면, 노드는 백업 디바이스를 복제볼륨으로부터 분리(detach)시키고 diskless 상태로 전환합니다.

• call-local-io-error. 로컬 I/O 에러 핸들러로 정의된 명령을 호출합니다. 이 옵션은 local-io-error <cmd> 가 리소스의 <handlers> 섹션에 정의되어 있어야 사용 가능합니다. local-io-error 호출 명령 또는 스크립트를 사용하면  I/O 에러 처리를 전적으로 사용자의 결정에 맡깁니다.

에러처리 정책은 리소스가 운영중이더라도 adjust 명령을 통해 실시간 적용할 수 있습니다.

일시적 장애 처리

I/O 에러 정책을 패스스루(passthough)로 설정할 경우 I/O 에러의 결과는 파일시스템으로 전달되고 bsr 은 오류가 발생한 I/O 블럭을 OOS로 기록합니다. 이러한 OOS는 I/O 에러가 일시적이었다면 파일시스템에 의해 재 시도 되어 스스로 해소되거나, 그렇지 않다면 복제 재연결을 통해 재동기화를 유도하여 해당 OOS 영역을 해소합니다. 이 때 OOS를 해소하는 동기화의 방향이나 절체 여부 등의 운영은 관리자 또는 HA 운영 로직에 맡깁니다. 

영구적 오류 처리

일시적으로 I/O 오류가 발생하여 다소간의 OOS가 기록되는 상황을 제외한 모든 디스크 오류 상황을 영구적 오류 상태로 간주합니다.

영구적 오류는 다양한 상황에서 발생할 수 있습니다. 디스크에 실제 물리적인 손상(배드블럭)이 발생한 경우 또는 스토리지에 연결된 케이블이 단선되어 볼륨이 제거된 경우 SCSI 컨트롤러에 장애가 발생한 경우 등 실제로 스토리지 계층에 문제가 있는 상황을 포함해, 관리자의 실수 또는 bsr과 호환되지 않는 다른 프로그램의 영향으로 볼륨이 제거되는 복제 외적인 상황 등이 모두 포함됩니다. 이러한 영구적 오류가 발생하면 관리자는 복제를 재구성하거나 디스크를 교체해야 합니다. 영구적 디스크 오류를 조치하기 위해선 먼저 리소스를 down 한 이후 디스크를 복제 상태에서 분리(detach)해야 합니다. 물론 재구성을 해야 하는 복제 리소스에 대해선 메타디스크를 재초기화 해야 합니다.

디스크 오류 정책을 detach 정책으로 하여 리소스 분리를 자동으로 수행할 수도 있으나 자동분리(detach) 정책 보다는 passthrough 정책으로 설정하는 것을 권장합니다. passthrough 정책이 디스크의 일시적 오류에 능동적으로 대처할 수 있는 만큼 서비스 운영 측면에서 보다 더 합당합니다.

디스크 교체

다음과 같이 메타 데이터 세트를 재생성하고, 리소스를 다시 연결합니다. 필요하다면 명시적으로 동기화 명령을 수행하여 전체동기화를 진행합니다.

• errors are sent to the mounted file system in the case of the primary node, and error results to the primary node, but in the secondary node errors are ignored (if there is no replication connection). At this time, the disk status is maintained and the error block is recorded in OOS.

  • max-passthrough-count You can't have an infinite number of passthroughs. If more than a certain number of passthroughs are repeated, it should be considered a permanent disk failure, and you specify the threshold here.

• detach When a lower-level I/O error occurs, the node detaches the backup device from the replication volume and switches to diskless state.

• call-local-io-error. Call the command defined by the local I/O error handler. This option is only available if local-io-error <cmd> is defined in the <handlers> section of the resource. Using the local-io-error call command or script, I/O error handling is entirely at the user's discretion.

The error handling policy can be applied in real time through the adjust command even if the resource is in operation.

Temporary error handling

If the I/O error policy is set to passthough, the result of the I/O error is transferred to the file system, and the bsr records the I/O block in error as OOS. If the I/O error was temporary, the OOS is retried by the file system and resolved by itself. Otherwise, the OOS area is resolved by inducing resynchronization through replication reconnection. At this time, it is left to the administrator or the HA operation logic to manage operations such as the direction of synchronization to resolve the OOS.

It is possible to automatically perform resource detaching by using detach policy, but it is recommended to set the passthrough policy rather than the detach. The passthrough policy is more reasonable in terms of service operation as it can actively respond to temporary failures on disk.

Permanent error handling

All disk failure situations are considered as permanent errors except those in which some OOS is recorded due to temporary I/O errors.

Permanent errors can occur in a variety of situations. For example, if the physical damage (bad block) to the disk occurs, cable of storage is disconnected, the volume is removed, and the SCSI controller has failed. This includes non-replicating situations in which the volume is removed due to the mistake of administrator or other programs that are not compatible with bsr.

If this permanent error occurs, the administrator must reconfigure replication or replace the disk. To fix a permanent disk failure, you must first down the resource and then detach the disk from the replication state. Of course, you must reinitialize the metadisk for any replication resource that needs reconfiguration.

Disk replacement

Regenerate the meta data set and reconnect the resources as follows. If necessary, perform a full synchronization by explicitly executing the synchronization command.

C:\Program Files\bsr\bin>bsradm down <resource>
  
C:\Program Files\bsr\bin>bsradm create-md <resource>
v08 Magic number not found
Writing meta data...
initialising activity log
NOT initializing bitmap
New bsr meta data block sucessfully created.
 
 
C:\Program Files\bsr\bin>bsradm up <resource>
C:\Program Files\bsr\bin>bsradm invalidate <resource>

기타

...

Etc

For disk read errors and meta disk I/O 오류에 대해선 자동 분리(detach) 정책이 적용되어 복제가 중단되며, 복제 중단된 리소스는 재구성을 통해서만 복구 될 수 있습니다.

노드 장애

하드웨어에 장애가 발생되거나 또는 수동적인 개입으로 인하여 노드가 다운되면 상대편 노드는 상황을 감지하고 연결 상태를 Connecting 으로 전환하고 상대 노드가 다시 나타날 때까지 disconnected 모드 상태로 대기합니다.  장애 상황에 따라 다음의 두 가지 경우로 구분합니다.

• Secondary의 일시적 장애

  • 타깃 측이 다운됬을 경우 소스 측은 disconnected 모드로 운영을 지속할 수 있지만 블록에 대한 수정 사항은 상대 노드로 복제되지 않습니다. 다만 변경되고 있는 블록에 대한 정보는 내부적으로 저장하여 추후 상대 노드가 복구될 시 변경 된 블럭에 대해 동기화 할 수 있도록 대기 합니다.

• Primary 의 일시적 장애

  • 소스 측이 다운됬을 경우 HA 는 우선 절체 여부를 결정해야 합니다. 절체 여부에 따라 추후 소스 노드가 복구되어 클러스터에 합류 되었을 때 어느 노드를 기준으로 동기화 할 지가 판가름 됩니다.

    • 절체를 하면 대기노드 였던 노드가 새로운 소스 노드의 역할을 수행합니다.

    • 절체를 하지 않고 대기할 경우 원래 소스 노드였던 노드가 동기화 소스노드의 역할을 수행합니다.

Secondary 의 일시적 장애

Secondary 역할의 리소스를 가진 노드에서 RAM 문제와 같은 장비교체로 인한 일시적 장애가 발생할 경우, 장애 노드를 복구해서 온라인 할게 아니라면 추가적인 개입은 필요하지 않습니다. 단지 Secondary 노드를 재 시작하여 양 노드의 연결을 자동으로 재 시도하고 성립합니다. 이 후 Primary 노드에서 수정된 모든 변경사항이 Secondary 노드로 동기화하여 반영됩니다.

Primary 의 일시적 장애

복제 중 Primary 노드가 전원장애 등에 의해 예기치 않게 중단 될 수 있습니다. 이 상태를 Crashed Primary 상태라고 합니다. 이 때 상대편 노드는 Primary 노드가 사라진 것을 감지하고 disconneted 모드로 전환합니다. Crashed Primary 노드는 부팅 과정을 거쳐 재기동 되고 서비스에 의해 자동 Secondary 역할로 기동합니다. 여기서 Primary 역할로 자동 승격시키지는 않습니다. Crashed Primary 노드는 Secondary 노드와 연결을 수립하고 이 과정에서 양노드는 서로 Crashed Primary 상태가 되었음을 인지합니다. 이후, 동기화의 과정을 통해 양 노드의 정합성을 일치 시킵니다. 이전 섹션에서 설명한 것처럼, 이 경우에도 장애 노드가 복구되면 더 이상 수동 개입은 필요하지 않지만 클러스터 관리 응용 프로그램(HA)에 의해 특정 노드의 승격을 결정하고 운영서비스를 지속할 수 있습니다.

Primary 노드 장애의 경우 AL 을 통한 특별한 메커니즘으로 블록 디바이스의 정합성을 맞추게 됩니다. 이와 관련한 자세한 설명은 액티비티 로그를 참고하세요.

영구적 장애

영구적이거나 복구가 불가능한 장애가 발생한 경우, 다음 단계를 수행해야 합니다.

• 장애가 발생한 하드웨어를 유사한 성능 및 디스크 용량의 하드웨어로 교체합니다.

• 기본 시스템과 응용 프로그램을 설치합니다.

• bsr을 설치하고, 동작하고 있는 노드의 /etc/bsr.d/ 아래에 있는 파일들과 /etc/bsr.conf를 복사합니다.

• 리소스 재구성 에 맞게 재 구성하고, 리소스를 기동하고 초기 동기화를 시작합니다.

만일 Primary 가 이미 동작하고 있다면 연결되면서 자동으로 동기화가 시작되므로 수동으로 동기화를 할 필요는 없습니다.

스플릿 브레인

스플릿 브레인 동작 설정

bsr 에서는 스플릿 브레인을 감지하면 자동으로 운영자에게 알릴 수 있는 방법을 제공합니다.

스플릿 브레인 발생 알림

스플릿 브레인 발생 시 이를 감지하고자 한다면 스플릿 브레인 핸들러를 구성하여 감지할 수 있습니다. 다음은 이에 대한 리소스 구성 예 입니다.

resource <resource>
  handlers {
    split-brain <handler>;
    ...
  }
  ...
}

<handler>는 시스템 상에서 스크립트와 같은 실행 가능한 형태의 모듈로 구성합니다. 보통 배치파일이나 쉘 스크립트와 같은 실행 형태로 구성하는 것을 권장합니다.

리눅스에선 스플릿 브레인 핸들러가 기본적으로 활성화되어 있으나 Windows 에선 기본 비활성화되어 있습니다. 다음 명령을 사용하여 핸들러 서비스를 활성화할 수 있습니다.

drbdcon /handler_use 1

수동 복구

복제 연결 단절 후 양 노드가 Primary 역할이었다는 것을 감지했다면 상대 노드와 재 연결하는 시점에 스플릿 브레인(Split-brain)으로 판단하고 즉시 복제 연결을 끊습니다. 그리고 로그에 다음과 같은 메시지를 남깁니다.

하나의 노드에서 스플릿 브레인이 감지되면 리소스는 StandAlone 상태가 됩니다. 양 노드가 동시에 스플릿 브레인을 감지했다면 양 노드 모두 StandAlone 상태가 되지만, 한 노드에서 스플릿 브레인을 감지하기 전에 상대 노드가 연결을 먼저 끊게 되면 SB를 감지하지 못한 채 단지 Connecting 상태로 유지합니다.

스플릿 브레인을 복구하기 위해선 스플릿 브레인 자동 복구 구성이 되어 있지 않는 한, 변경사항을 폐기할 노드(victim)를 먼저 선택하고 다음과 같은 절차를 통해 수동으로 복구해야 합니다.

먼저 양 노드에서 다음의 명령을 통해 StandAlone 상태로 만듭니다.

bsradm disconnect <resource>

폐기할 노드(victim)에서 아래 명령을 수행합니다. 

bsradm secondary <resource>
bsradm connect --discard-my-data <resource>

운영 노드(survivor) 에서 연결합니다. 노드가 이미 Connecting 상태였다면 자동으로 연결되기 때문에 이 단계를 생략할 수 있습니다.

bsradm connect <resource>

정상적으로 연결되면 victim의 복제 상태는 즉시 SyncTarget으로 변경되고, 노드 간의 데이터 변경점들이 survivor 노드를 기준으로 동기화 됩니다.

재동기화가 완료되면 스플릿 브레인은 해결된 것으로 간주하며, 두 노드는 다시 완전히 일치된 이중화 복제 저장 시스템으로 복구됩니다. 

다중 스플릿 브레인

1:N 복제 환경에선 노드들 간의 스플릿 브레인이 다중으로 발생될 수 있습니다. 

예를 들어 A-B-C 의 1:2 복제 구성의 경우 각 노드의 연결을 단절하고 모든 노드의 리소스를 승격 후 볼륨에 I/O 를 수행합니다. 이 후 각 노드를 강등하여 재 연결하면 각각의 노드간에 스플릿 브레인이 발생됩니다. 이 때 스플릿 브레인은 A-B 노드간, B-C 노드간에 또는 A-C 노드 간의 스플릿 브레인 상황이며 클러스터 내 노드간의 SB가 다중으로 발생된 상황입니다. 이럴 경우 다중 SB의 해결은 노드들 간의 개별 연결 기준으로 다음의 절차에 따라 순차적으로 해결해야 합니다.

• Survival 노드와 Victim 노드를 결정하고 모든 노드에서 disconnect 하여 StandAlone 상태를 만듭니다.

• SB가 발생한 노드간에 SB를 해결합니다.

  • Survival 노드는 drbdsetup connect [resource] [victim node-id] 명령을 통해 Connecting 상태로 진입

  • Victim 노드는 drbdsetup connect [resource] [survival node-id] --discard-my-data 명령을 통해 SB 해결

• SB가 해결되고 나면 연결이 되지 않은 Victim 노드 간의 연결을 복원합니다. drbdsetup connect [resource] [victim node-id]

  • SB 를 해결하여 연결을 복원하는 도중 2차 SB가 발생될 경우도 있습니다. 이럴 경우 위와 동일한 절차로 SB를 해결합니다.

자동 복구

스플릿 브레인이 발생하면 관리자에게는 스플릿 브레인 수동 복구(Manual split brain recovery)가 권장되지만, 경우에 따라서는 그 과정을 자동화하는 것이 좋을 수도 있습니다.

bsr은 스플릿 브레인을 자동 복구할 수 있는 몇 가지 알고리즘을 제공합니다.

• Younger Primary 노드의 수정분 폐기: 네트워크 연결이 다시 복구 되고 스플릿 브레인이 감지되면, 최근 Primary 역할로 전환한 노드의 수정분을 폐기합니다.

• Older Primary 노드의 수정분 폐기: 네트워크 연결이 다시 복구 되고 스플릿 브레인이 감지되면, 처음 Primary 역할을 가졌던 노드의 수정분을 폐기합니다.

• 수정 내용이 적은 Primary 데이터 폐기 - 양쪽 노드에서 수정 내용이 더 적은 쪽 노드를 확인하여 그 노드의 내용을 폐기합니다.

• 데이터 변경 사항이 없는 호스트로 복구 - 스플릿 브레인 동안 데이터의 수정 이력이 없는 노드가 있다면 해당 노드로 복구시키고 스플릿 브레인 해결을 선언합니다. 하지만 이것은 아주 드문 경우입니다. 양쪽 노드에서 리소스 볼륨을 파일시스템에 마운트(심지어 읽기전용)만 하더라도 볼륨 내용은 수정사항이 발생하기 쉬우며, 그 후에는 이 방식으로 자동 복구될 가능성은 없다고 봐야 합니다.

자동 스플릿 브레인 복구를 사용할 지 여부는 대체로 응용프로그램에 따라 달라집니다. 예를 들어 bsr에서 데이터베이스를 호스팅하는 경우를 생각해보면 사용자 인터페이스와 연관된 데이터 베이스를 사용하는 웹 응용프로그램에서는 폐기 해야할 변경사항이 거의 없어서 자동 복구가 괜찮은 수단이 될 수 있지만 반대로 금융 데이터 처럼 그 어떠한 데이터라도 함부로 폐기가 힘든 성격을 가지고 있는 환경에서는 사람이 직접 수동 복구를 해야 할 것입니다. 자동 스플릿 브레인 복구를 활성화하기 전에 응용프로그램의 요구사항을 신중하게 고려해야 합니다.

자동 복구 정책

자동 split-brain 복구 정책을 구성하기 위해서는 bsr이 제공하는 몇 가지 구성 옵션을 이해해야 합니다. bsr은 SB 감지 시 Primary로 있었던 노드의 수에 따라 복구 정책을 구분하고, 이에 대한 자동 복구 정책은 리소스의 <net> 섹션에 다음과 같은 키워드를 사용하여 구성합니다.

after-sb-0pri. SB가 발생된 시점에, 어떤 노드도 Primary 역할에 있지 않은 상황으로 복구 방법은 다음과 같습니다. 

• disconnect : 자동으로 복구하지 않습니다. 구성된 SB 핸들러 스크립트가 있다면 이를 호출하고, disconnected 모드를 지속합니다.

• discard-younger-primary : 마지막으로 Primary 역할을 했다고 추정되는 노드에서 수정사항을 취소하고 되돌립니다. younger primary를 판단할 수 없다면 discard-zero-changes, discard-least-changes 순서로 동작하게 됩니다. 

• discard-least-changes : 최소의 변경 사항이 발생한 노드에서 수정사항을 취소하고 되돌립니다.

• discard-zero-changes : 변경 사항이 발생하지 않은 노드가 있다면, 다른 노드의 변경 사항을 적용합니다.

after-sb-1pri. SB가 발생된 시점에, 하나의 노드가 Primary 역할에 있는 상황으로 복구 방법은 다음과 같습니다. 

• disconnect : 자동으로 복구하지 않습니다. 구성된 SB 핸들러 스크립트가 있다면 이를 호출하고, disconnected 모드를 지속합니다.

• consensus : SB victim이 선택될 수 있다면 자동으로 해결합니다. 그렇지 않으면, disconnect처럼 동작합니다.

• call-pri-lost-after-sb : SB victim이 선택될 수 있다면, victim 노드에서 pri-lost-after-sb 핸들러를 호출합니다. 이 핸들러는 <handlers> 섹션에 구성되어야 하고, 클러스터에서 노드가 강제로 제거됩니다.

• discard-secondary : 현재 Secondary 역할에 있는 노드를 SB victim으로 만듭니다.

after-sb-2pri. SB가 발견된 시점에 양 노드에서 Primary 역할에 있는 상황으로, 복구 방법은 disconnect 를 통한 수동 복구만 사용할 수 있습니다.

구성 파일 작성 예시는 다음과 같습니다.

resource <resource> {
    handlers {
        split-brain "C:/Tools/script/split-brain.bat";
        ...
    }
    net {
        after-sb-0pri discard-zero-changes;
        after-sb-1pri discard-secondary;
        ...
    }
    ...
}

...

errors, automatic detach policy is applied to stop replication, and resources that have been stopped can be recovered only through reconfiguration.

Node failure

If the node goes down due to hardware failure or manual intervention, the other node detects the situation, switches the connection state to Connecting, and waits in disconnected mode until the other node reappears. Node failures are usually treated as temporary failures that are self-recovering, but must be manually recovered in the permanent failure.

Secondary failure

If the target side goes down, the source side can continue operating in disconnected mode, but modifications to the block will not be replicated to the other node. However, the information on the block being changed is stored internally and waits for synchronization with the changed block when the counterpart node is restored later.

Primary failure

During replication, the primary node may stop unexpectedly due to power failure. This state is called the Crashed Primary state. At this time, the other node detects that the primary node has disappeared and switches to disconneted mode. The crashed primary node is restarted through the booting process and started in an automatic secondary role by the service. It does not automatically promote the Primary role here. The Crashed Primary node establishes a connection with the Secondary node, and in the process, both nodes recognize each other that they are in the Crashed Primary state. After that, the consistency of both nodes is matched through the process of synchronization. in this case, when the failed node recovers, manual intervention is no longer required, but the cluster management application (HA) can determine the promotion of a particular node and continue its operational services.

If the source side goes down, HA must first decide whether to switch over. Depending on whether or not the switchover is made, it is determined by which node to synchronize when the source node is later restored and joined to the cluster.

• When switching, the node that was the standby node acts as the new source node.

• If you wait without switching, the node that was the original source node acts as the synchronization source node.

In case of primary node failure, special mechanism through AL will match the consistency of the block device. Please refer to the activity log of BSR Internals for details on this.

Permanent failure

In the event of a permanent or non-recoverable failure, you must perform the following steps.

• Replace failed hardware with hardware of similar performance and disk capacity.

• Install basic systems and applications.

• Install bsr and copy the files under /etc/bsr.d/ on the running node and /etc/bsr.conf.

• It reconfigures according to the resource reconfiguration procedure, starts the resource, and starts the initial synchronization.

If Primary is already running, synchronization starts automatically when connected, so there is no need to synchronize manually.

Split-brain

Split-brain behavior settings

bsr provides a way to automatically notify the operator when a split brain is detected.

Split-brain notification

If you want to detect when a split brain occurs, you can configure a split-brain handler to detect it. The following is an example of resource configuration.

resource <resource>
  handlers {
    split-brain <handler>;
    ...
  }
  ...
}

<handler> is composed of executable modules such as scripts on the system. It is usually recommended to configure it in an executable form such as a batch file or shell script.

On Linux, split brain handler is enabled by default, but on Windows it is disabled by default. You can activate the handler service using the following command:

drbdcon /handler_use 1

Manually recover

If it detects that both nodes were in the primary role after disconnection of the replication connection, it is determined as a split-brain when reconnecting with the other node, and the replication connection is immediately disconnected. And it leaves the following message in the log:

When a split brain is detected on one node, the resource is in the StandAlone state. If both nodes detect the split brain at the same time, both nodes will be in the StandAlone state, but if the other node first disconnects before detecting the split brain on one node, the SB will not be detected and will remain connecting.

In order to recover the split brain, unless the split brain automatic recovery configuration is configured, you must first select the node to discard the changes and manually recover it using the following procedure.

First, put the StandAlone state on both nodes with the following command.

bsradm disconnect <resource>

Execute the following command on the node(victim) to be discarded.

bsradm secondary <resource>
bsradm connect --discard-my-data <resource>

Connect from the Survivor node. If the node was already in the connecting state, you can skip this step because it will automatically connect.

bsradm connect <resource>

Upon successful connection, the replication status of the victim is immediately changed to SyncTarget, and data changes between nodes are synchronized based on the survivor node.

When resynchronization is complete, the split brain is considered resolved, and the two nodes are restored back to the fully matched redundant replication system.

Multiple split-brain

In a 1: N replication environment, multiple split brains can occur between nodes.

For example, in the 1:2 replication configuration of A-B-C, each node is disconnected, all resources are promoted, and I/O is performed on the volume. After this, if you demote each node and reconnect, a split brain occurs between each node. At this time, the split brain is a multiple split-brain situation between A-B nodes, between B-C nodes, or between A-C nodes, and multiple SBs occur between nodes in a cluster. In this case, the resolution of multiple SBs should be solved sequentially according to the following procedure based on the individual connection between nodes.

• Determine Survival node and Victim node and disconnect from all nodes to create StandAlone state.

• The SB is resolved between the nodes where the SB occurred.

  • Survival node enters the Connecting state through the command “drbdsetup connect [resource] [victim node-id]

  • Victim node resolves SB through the command drbdsetup connect [resource] [survival node-id] --discard-my-data

• After SB is resolved, restore the connection between the unconnected Victim nodes. drbdsetup connect [resource] [victim node-id]

  • In some cases, a secondary SB may occur again while resolving the SB to restore the connection. In this case, solve the SB by the same procedure as above.

Auto Recover

When a split brain occurs, manual split brain recovery is recommended for administrators, but in some cases it may be a good to automate the process.

bsr provides several algorithms to automatically repair split brain.

• Discarding revisions of the Younger Primary node: When a network connection is restored and a split brain is detected, the revisions of the node that has recently switched to the Primary role are discarded.

• Older Primary Node Revocation: When the network connection is restored again and the split brain is detected, the revision of the node that had the primary primary role is discarded.

• Discard Primary Data with Less Modifications-Both nodes see which node has the less modification and discard the contents of that node.

• Recover to host with no data changes-If a node has no history of data modification during split brain, recover to that node and declare split brain resolution. But this is a very rare case. Even if the resource volume is mounted (even read-only) on the file system on both nodes, the contents of the volume are apt to be modified, and there is no possibility of automatic recovery after this.

Whether to use automatic split brain recovery is largely application-specific. For example, if you're hosting a database on bsr, auto-recovery can be a decent means for web applications that use a database associated with the user interface, with few changes to discard, but vice versa. In an environment in which it is difficult to dispose of it, a manual repair will be required by a person. Before enabling automatic split brain recovery, you should carefully consider your application's requirements.

Automatic recovery policy

To configure the automatic split-brain recovery policy, you need to understand some of the configuration options that bsr provides. bsr classifies recovery policies according to the number of nodes that were primary when SB is detected, and the automatic recovery policy is configured using the following keyword in the <net> section of the resource.

after-sb-0pri. When SB occurs, no node is in the primary role, and the recovery method is as follows.

• disconnect : It does not recover automatically. If there is a configured SB handler script, it is called, and it remains in disconnected mode.

• discard-younger-primary : Undo and revert the modifications on the node that was assumed to have played the most recent primary role. If the younger primary cannot be determined, it will work in the order of discard-zero-changes, discard-least-changes.

• discard-least-changes : Amendments are canceled and reverted to the node with the smallest change.

• discard-zero-changes : If there are nodes that have not changed, the changes from other nodes are applied.

after-sb-1pri. When SB occurs, the recovery method is as follows when one node is in the primary role.

• disconnect : It does not recover automatically. If there is a configured SB handler script, it is called, and it remains in disconnected mode.

• consensus : If SB victim can be selected, it will be resolved automatically. Otherwise, it works like disconnect.

• call-pri-lost-after-sb : If the SB victim can be selected, the victim node calls the pri-lost-after-sb handler. This handler must be configured in the <handlers> section, and the node is forcibly removed from the cluster.

• discard-secondary : Make the node currently in the Secondary role a victim of SB.

after-sb-2pri. This is the situation where both nodes are in the Primary role at the time the SB is discovered. The recovery method can only use manual recovery through disconnect.

The following is an example of a configuration file with SB auto recovery.

resource <resource> {
    handlers {
        split-brain "C:/Tools/script/split-brain.bat";
        ...
    }
    net {
        after-sb-0pri discard-zero-changes;
        after-sb-1pri discard-secondary;
        ...
    }
    ...
}

Device reference errors

BSR internally maintains reference count for backing devices. The reference count is incremented when a device is opened by a particular process and decremented when it is closed to manage the lifecycle for the device and to force a particular process to no longer reference the device volume when it is time to clean up its resources.

Problems arise when the reference count is non-zero, either at the beginning of configuring the BSR resource or during the process of umounting the device. Because some process opened the device and never closed it, BSR detects this and treats it as an error.

• Resource configuration errors

If any process is referencing the BSR resource BACKING DEVICE, attaching the device will fail with the following error. 16 The error code corresponds to EBUSY.

• DOWN Errors

If the number of references to the device is not zero at the time of resource down, down will fail and the following log will be output.

To resolve this issue, you need to identify the process that is referencing the BSR volume and take steps to reduce the number of references to the volume, such as forcing the module to stop (fuser -ck).

For example, on Ubuntu 20.04 and later, multipath-tools (0.8.3) must have the following exception handling in multipath.conf to prevent references to the bsr device from occurring, otherwise multipath-tools will continue to reference the bsr volume, making it impossible to bring down.

blacklist {
        devnode "^(sd)[a-z]"
        devnode "^(bsr)[0-9]"
        }