Versions Compared

Key

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

...

Code Block
resource <resource> {
  disk {
    on-io-error <strategy>;
    max-passthrough-count 100;
    ...
  }
  ...
}

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

...

  • passthrough on-io-error의 기본값으로 하위계층의 I/O 오류를 상위 계층에 보고합니다. I/O 오류는 Primary 노드일 경우 마운트 된 파일시스템으로 보내고, Secondary 노드에서는 Primary 노드로 쓰기 결과를 전달하거나 (복제 연결이 없을 경우)무시 됩니다. 이때 디스크 상태는 현 상태를 유지하며 해당 에러블럭에 대해 OOS로 기록합니다. I/O 오류는 상위에 의해 재시도 되어 정상 처리되거나 다시 오류가 발생될 수 있습니다. 재시도가 되어도 오류가 지속되면 다음의 detach 정책에 의해 처리됩니다.

    • max-passthrough-count 패스스루를 무한정 할 수는 없습니다. 일정 수 이상 패스스루가 반복될 경우 영구적 디스크 장애로 간주해야 하고 여기의 임계점을 지정합니다.

  • detach 하위계층의 I/O 에러가 발생하면, 노드는 장치를 복제볼륨으로부터 분리(detach)시키고 diskless 상태로 전환합니다.

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

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

Info

디스크 I/O 오류는 생각보다 자주 발생합니다. 이것은 bsr 복제가 하위 디스크 계층에 의존적이며 SCSI 계층의 에러가 임의의 시점에 언제든지 발생할 수 있다는 점에서 복제 측면에서도 이러한 디스크 I/O 오류에 passthrough 정책의 특징

bsr 은 하위의 SCSI 스토리지 계층에서 발생하는 오류들에 유연하게 대처할 수 있어야 함을 의미합니다합니다.

그동안 디스크 장애 정책으로 제공해 왔던 detach 정책은 서비스 운영관점에선 복제가 특정시점에 특정 시점에 일방적으로 중단되는 정책이었습니다. 이러한 방식은 사후 복구도 어렵고 서비스 운영 지속 측면에서도 불리합니다. 우리는 이러한 문제에 대응하여 passthrough 정책을 고안하였으며 bsr의 기본 정책으로 설정하게 되었습니다.

패스스루 정책은 I/O 에러가 발생할 경우 해당 블럭에 대해서 OOS 를 기록하고 실패된 I/O 결과를 파일시스템으로 전달합니다. 이 때 파일시스템이 에러가 발생한 블럭에 대해 다시 쓰기하여 이를 통해 OOS를 해소한다면 이는 일시적인 디스크 계층의 에러를 파일시스템 스스로 극복하도록 유도하게 됩니다. 비록 파일시스템의 동작 특성에 따라 완전히 OOS가 해소되지 못한다고 하더라도 일부 남겨진 OOS 는 연결 재시도 등을 통해 재동기화 하여 해결할 수도 있습니다.

패스스루 정책은 에러 블럭을 FS가 스스로 해결하거나 동기화를 통해 해소하도록 유도하고, 기본적으로 디스크 I/O에 문제가 있더라도 서비스 운영을 지속하도록 보장합니다.

...

Info

bsr 은 I/O 오류가 일시적인지 또는 영구적인지 판단할 수 없으며 섹터 단위의 I/O 오류 추적 등의 구체적인 오류 통계를 취합하지는 유지하지 않습니다. 다만 오류가 발생한 해당 장치에 대한 I/O 에러 발생 회수 정보만 유지합니다간직합니다. 비록 구체적인 정보는 알 수 없지만 bsradm status의 I/O 에러 회수를 토대로 에러가 발생한 정도를 파악할 수 있습니다. 만약 일시적 에러가 발생했다면 status에 보여지는 io error 와 oos 는 다소간의 양만 기록되어 있을 것이며 시간이 지나도 그 양은 증가하지 않을 것 입니다.

...

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

스플릿 브레인

스플릿 브레인 동작 설정

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

...

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

...

.

Code Block
bsrcon /handler_use 1

스플릿 브레인 상태 확인

스플릿 브레인이 발생했을 때의 상태 출력 결과 입니다.

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:StandAlone error:split-brain 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

수동 복구

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

...

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

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

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

SB 핸들러의 배치 파일 구성에서 사용하는 파일들은 절대 경로로 기술되어야 합니다.

Note

SB 해결(복구) 동기화 중 재 연결이 발생할 경우 다시 SB 발생 상황으로 돌아갑니다. SB 해결이 완료되지 않아서 아직은 양측 노드가 SB 상태이기 때문입니다.

...

bsr 1.7 이후 부터는 이 부분을 변경하여 한 번 SB 해결이 시도되면 재 연결이 되더라도 이후 SB 해결이 완료될 때 까지 SB 해결을 자동으로 수행하도록 합니다.

장치 참조 오류

bsr 은 내부적으로 백킹 디바이스에 대한 참조 회수를 유지 합니다. 참조 회수는 특정 프로세스가 장치를 열었을 때 증가하고 닫으면 감소되는데 이를 통해 장치에 대한 생명주기를 관리하고 리소스를 정리하는 시점에 특정 프로세스가 장치 볼륨을 더 이상 참조하지 않도록 강제합니다.

...

  1. 커널모듈 삭제

    1. bsrvflt.sys 삭제

      1. HKLM, System\CurrentControlSet\Control\Class\{71A27CDD-812A-11D0-BEC7-08002BE2092F}UpperFilters 키의 값 내용 중 bsrvflt 문자열 제거 후 레지스트리 저장

      2. HKLM, System\CurrentControlSet\Services\bsrvflt 키 삭제

    2. bsrfsflt.sys 삭제

      1. HKLM, System\CurrentControlSet\Services\bsrfsflt 키 삭제

  2. 응용 서비스 삭제

    1. sc stop drbdservicebsr

    2. sc delete drbdservicebsr

  3. 환경변수 삭제

    1. DRBDBSR_PATH, CYGWIN 시스템 환경변수 삭제

  4. Program Files\drbd bsr 경로에 설치된 파일들 삭제

  5. 리부팅