디스크 장애
디스크 장애(오류)는 디스크 스토리지 계층의 물리적 연결 단자의 단선, 미디어 파손, 배드 섹터, SCSI 오류 등 얘기치 않은 장애로 인해 디스크 I/O 에 오류가 발생하는 상황을 말합니다. 이러한 장애 들은 일시적으로 발생했다가 정상화 되기도 하고 영구적 장애로 이어지기도 합니다. bsr 에선 이러한 장애를 일시적 장애와 영구적 장애로 구분하고 유형에 따라 오류를 다르게 처리합니다.
일시적 장애는 스토리지 계층에서의 어떤 이유로 인해 오류가 잠시 발생 했다가 다시 정상화되는 상황입니다. 이럴 경우에는 디스크 교체가 필요한 정도의 심각한 상황이 아니기 때문에 되도록이면 서비스 운영을 지속하면서 기 발생된 에러에 대해서만 별도로 해소하고 복제는 계속 운영되도록 하는게 효율적입니다. 즉 일시적 오류 상황에서는 I/O 에러가 발생한 블록 영역을 out-of-sync 로 기록하고 해당 블록으로 발생한 재시도된 I/O 가 성공하면 자연스럽게 OOS 가 해소되도록 합니다.
영구적인 디스크 오류는 디스크 교체 등 디스크 장애에 대한 별도 조치가 필요한 상황으로 전체 재구성의 절차를 통해 복구해야 합니다.
I/O 에러 처리 정책은 리소스 <disk> 섹션의 on-io-error 옵션을 통해 설정 됩니다.
resource <resource> { disk { on-io-error <strategy>; ... } ... }
해당 옵션을 <common> 섹션에 정의한다면 모든 리소스에 적용됩니다.
<strategy>는 다음과 같은 세 가지 옵션이 있습니다.
passthrough on-io-error의 기본값으로 I/O 오류를 상위 계층에 보고합니다. 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 운영 로직에 맡깁니다.
bsr 은 I/O 오류가 일시적인지 또는 영구적인지 판단할 수 없으며 섹터 단위의 I/O 오류 추적 등의 구체적인 오류 통계를 취합하지는 않습니다. 다만 오류가 발생한 해당 장치에 대한 I/O 에러 발생 회수 정보만 유지합니다. 비록 구체적인 정보는 알 수 없지만 bsradm status의 I/O 에러 회수를 토대로 에러가 발생한 정도를 파악할 수 있습니다. 만약 일시적 에러가 발생했다면 status에 보여지는 io error 와 oos 는 다소간의 양만 기록되어 있을 것이며 시간이 지나도 그 양은 증가하지 않을 것 입니다.
영구적 오류 처리
일시적으로 I/O 오류가 발생하여 다소간의 OOS가 기록되는 상황을 제외한 모든 디스크 오류 상황을 영구적 오류 상태로 간주합니다.
영구적 오류는 다양한 상황에서 발생할 수 있습니다. 디스크에 실제 물리적인 손상(배드블럭)이 발생한 경우 또는 스토리지에 연결된 케이블이 단선되어 볼륨이 제거된 경우 SCSI 컨트롤러에 장애가 발생한 경우 등 실제로 스토리지 계층에 문제가 있는 상황을 포함해, 관리자의 실수 또는 bsr과 호환되지 않는 다른 프로그램의 영향으로 볼륨이 제거되는 복제 외적인 상황 등이 모두 포함됩니다. 이러한 영구적 오류가 발생하면 관리자는 복제를 재구성하거나 디스크를 교체해야 합니다. 영구적 디스크 오류를 조치하기 위해선 먼저 리소스를 down 한 이후 디스크를 복제 상태에서 분리(detach)해야 합니다. 물론 재구성을 해야 하는 복제 리소스에 대해선 메타디스크를 재초기화 해야 합니다.
디스크 오류 정책을 detach 정책으로 하여 리소스 분리를 자동으로 수행할 수도 있으나 자동분리(detach) 정책 보다는 passthrough 정책으로 설정하는 것을 권장합니다. passthrough 정책이 디스크의 일시적 오류에 능동적으로 대처할 수 있는 만큼 서비스 운영 측면에서 보다 더 합당합니다.
디스크 교체
다음과 같이 메타 데이터 세트를 재생성하고, 리소스를 다시 연결합니다. 필요하다면 명시적으로 동기화 명령을 수행하여 전체동기화를 진행합니다.
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>
기타
디스크 읽기 오류, 메타디스크 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/drbd.d/ 아래에 있는 파일들과 /etc/drbd.conf를 복사합니다.
리소스 재구성 에 맞게 재 구성하고, 리소스를 기동하고 초기 동기화를 시작합니다.
만일 Primary 가 이미 동작하고 있다면 연결되면서 자동으로 동기화가 시작되므로 수동으로 동기화를 할 필요는 없습니다.
스플릿 브레인
구성 오류
기타
TCP Delayed ACK 설정 관련