Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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

핫빗(Heartbeat)과 같은 클러스터 노드 간을 노드를 관리하는 관리 모듈에서 모든 연결이 끊어졌을 때 판단하는 일반적인 클러스터의 스플릿 브레인과 복제의 스플릿 브레인은 구별되어야 합니다.

...

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

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

스플릿 브레인 동작 설정

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

스플릿 브레인 발생 알림

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

...

Info

주의 할점

스플릿 브레인 핸들러의 리턴 결과는 bsr 커널 엔진과 동기적으로 연계되기 때문에 핸들러의 실행 결과가 리턴되지 않을 경우 커널 엔진에 영향을 줄 수 있습니다. 복잡하지 않은 단순한 스크립트로 구성할 것을 권장합니다.

핸들러 서비스는 기본적으로 리눅스에선 스플릿 브레인 핸들러가 기본적으로 활성화되어 있으나 Windows 에선 기본 비활성화되어 있습니다. 다음 명령을 사용하여 handler_use를 1로 설정하면 핸들러 서비스가 활성화 되며 Split-brain 알림을 받을 수 있게 됩니다. 

...

핸들러 서비스를 활성화할 수 있습니다.

Code Block
drbdcon /handler_use 1

...

이후에 split-brain이 발생하게 되면 bsr은 구성된 핸들러를 호출합니다.

수동 복구

절차

...

수동 복구

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

Info

Split-Brain detected, dropping connection! 

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

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

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

Code Block
bsradm disconnect <resource>

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

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

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

Code Block
bsradm connect <resource>

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

Info

스플릿 브레인의 폐기 노드(victim)의 데이터는 전체 디바이스 차원에서 동기화가 이루어지지 않습니다. 단지 victim의 수정사항을 롤백하고, 모든 수정사항에 대해 스플릿 브레인 survivor에서 victim노드로 전파됩니다. 즉 변경 분에 대해서만 동기화가 이루어 집니다.

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

다중 스플릿 브레인

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)가 권장되지만, 경우에 따라서는 그 과정을 자동화하는 것이 좋을 수도 있습니다.

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

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

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

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

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

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

자동 복구 정책

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

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

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

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

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

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

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

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

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

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

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

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

Note

  • 여기서 논의되지 않은 split brain 복구 키워드에 대한 자세한 내용은 drbd.conf(5)를 참조하세요.

  • after-sb-0pri 복구 옵션의 discard-zero-changes 는 일반적인 secondary/secondary 스플릿브레인의 상황에선 적용할 수 없는 옵션입니다. 기 옵션 구동의 조건은 sec/sec 스플릿브레인 상태에서 최소 한쪽 노드의 변경사항이 없어야 합니다(out-of-sync 가 zero). 그러나 Windows 환경에선 pri-> sec , sec-> pri 로의 role 변경이 발생할 시 노드의 oos(out-of-sync) 변경이 수반되므로 일반적인 role 변경 시나리오로는 sec/sec 스플릿브레인 상태의 discard-zero-changes 조건이 성립되기 어렵습니다. 해당 옵션을 검증하려면 다음과 같은 절차를 통해 한쪽 노드의 uuid 를 새롭게 생성하여 oos 변경이 없는 상태가 되도록 임의로 유도해야 합니다. 따라서 이 옵션은 WDRBD 동작의 검증과 관련하여 제한적으로 사용됩니다.

...

순서

...

Left

...

Right

...

비고

...

1

...

secondary / UpToDate

...

secondary / UpToDate

...

양노드 secondary 이며 UpToDate 상태 확인

...

2

...

drbdadm disconnect <resource>

...

3

...

drbdadm disconnect <resource>

...

4

...

drbdsetup new-current-uuid <minor>

...

Left 노드에 새로운 UUID 생성. <minor>는 minor 번호 예) 2

...

5

...

drbdadm primary <resource>

...

6

...

Right 노드에 I/O 발생

...

7

...

drbdadm secondary <resource>

...

8

...

drbdsetup get-gi <minor>

or drbdadm get-gi <resource>

...

drbdsetup get-gi <minor>

or drbdadm get-gi <resource>

...

.

...

9

...

drbdadm connect <resource>

...

10

...

drbdadm connect <resource>

...

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

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

...

Info

split-brain 핸들러 배치 파일 구성에서 사용하는 파일들은 절대

...

ex)

...

경로로 기술되어야 합니다.

구성 오류

기타

  • TCP Delayed ACK 설정 관련