복제 클러스터의 관리자 또는 관리(HA) 소프트웨어에 의해 특정 시점에 소스 노드가 2 노드 이상 되는 상태를 스플릿 브레인(이하 SB) 이라고 합니다. SB는 복제 연결이 단절될 때 발생하며 양 노드가 서로의 역할과 상태를 알 수 없는 상태에서 동시에 소스노드가 되는 상황입니다. 이렇게 SB가 발생하면 복제 클러스터가 2개의 복제 SET으로 분할되어 잠재적으로 데이터가 유실될 수 있는 상태에 놓입니다. SB 발생을 인지하면 관리자는 다음의 절차에 따라 SB를 해결하고 복제를 정상화 시켜야 합니다.

FSR 은 엔진 내부적으로 양 노드가 SB 상태인지를 식별할 수 있습니다. SB 에 대한 식별은 복제 연결이 수립되는 시점에 RID교환을 통해 수행하며 그 결과 SB 로 인식될 경우 복제 연결을 즉시 끊어서 연결 중립(standalone) 상태로 대기하게 됩니다. 다음은 SB 가 발생 되었을 때의 출력 로그 입니다.

SB 를 해결하는 방법은 SB가 발생한 두 노드 중 희생할 노드를 결정하는 것으로 시작합니다. 희생할 노드가 결정되면 희생노드 상에서 다음의 명령을 통해 희생노드의 데이터를 폐기하는 옵션으로 상대노드와 연결하여 최종 SB를 해결합니다.

--discard-my-data 로 연결을 수립하여 SB를 해결하면 희생노드는 상대노드를 기준으로 재 동기화하여 최신 복제 데이터 셋으로 복구 합니다.

다음의 장애 상황에 대한 후속 대응을 설명합니다.

• 디스크 장애

• FSR 엔진의 파일 I/O 오류

복제 대상이 위치한 볼륨이 운영 중 의도치 않게 마운트 해제 되거나 물리적 파손으로 인해 저장매체 자체에서 문제가 되는 등 복제 대상 디스크 자체에서 장애가 발생할 수 있습니다.. 이 경우 사용자는 복제 대상을 다시 복구하여 볼륨 장치가 다시 가동될 수 있도록 조치해야 합니다. 수동 복구가 완료되면 전체 동기화를 통해 복제를 재 시작 해야 합니다.

FSR은 디스크의 상태를 주기적으로 모니터링하여 디스크에 이상이 발생할 경우 이를 감지합니다. 이는 S.M.A.R.T.(Self-Monitoring, Analysis, and Reporting Technology) 기술을 기반으로 하며 모니터링의 주기는 다음과 같이 지정할 수 있습니다.

파일 I/O 는 파일경로 문제로 인한 오류, 계정에 따른 권한 문제 등  다양한 상황에서 오류가 발생될 수 있습니다. I/O 오류가 자주 발생되는 것은 아니지만 의도치 않은 환경의 변화가 있거나 예외 상황에 대해 유연하게 대응하도록 작성되지 못한 응용에 의해 오류가 발생되는 것은 서비스 운영 중에 발생할 수 있는 통상적인 상황 입니다. I/O 오류가 발생되면 해당 예외 상황에 대해 응용 프로그램들은 예외 처리를 수행하게 되어 있으며 이후 동작은 응용 프로그램에 따라 다르게 대응됩니다. 이렇게 소스 측 응용 프로그램에 의한 파일 I/O의 오류는 언제든지 발생될 수 있는 일반적인 파일 I/O 오류로 보며 이는 장애가 아닙니다.

그러나 fsr 엔진에서 수행하는 파일 I/O에서 오류가 발생한다면 이는 장애입니다. fsr 이 파일 I/O 를 할 수 없으면 미러링이 근본적으로 불가하므로 복제를 즉시 중단합니다.

fsr 엔진에서 발생한 I/O 오류의 오류 코드는 로그로 기록되며 해당 오류 코드를 통해 오류의 원인을 추정할 수 있습니다. 관리자는 이를 통해 장애를 수동으로 복구해야 하며 fsr의 I/O를 정상화해야 합니다. 정상화된 환경에서 최종적으로 리소스를 다시 기동시키고 전체동기화를 수행하여 복제를 재개합니다.

디스크 볼륨의 물리적 오류는 미디어 자체의 손상에 기인하여 복구하기 어렵지만 파일시스템 수준의 논리적인 오류는 유틸리티(윈도우즈의 chkdsk 리눅스의 fsck)를 통해 검사하거나 복구할 수 있습니다.

통상 이러한 유틸리티를 사용할 경우에는 볼륨을 언마운트한 후 사용하는게 안전하며, 그리고 이 검사 과정에서 논리적 결함감지와 그에 따른 복구가 있었다면 타깃과의 정합성 일치를 위해 해당 볼륨을 다시 복제 리소스로 기동한 후 반드시 전체 동기화를 시켜 주어야 합니다.

파일 잠금의 과정에서 복제 대상 파일들 중 이미 열려져 있던 파일의 핸들을 정리하는 절차가 있습니다. 이 절차를 수행하는 과정에서 다음과 같은 오류 메시지가 발생할 경우에 대한 설명 입니다.

위 오류는 리눅스에서만 발생하며 해당 제어를 수행하는 ptrace 유틸의 권한이 없기 때문에 발생하는 문제로 이를 해결하기 위해선 시스템의 권한 설정을 조정해야 합니다. /proc/sys/kernel/yama/ptrace_scope 의 값이 3 으로 설정된 경우 이 값을 0~2 사이의 값으로 조정해야 하고 설정을 조정한 후 리부팅을 해야 합니다. 만약 시스템의 ptrace_scope 설정 값을 조정할 수 없다면 파일을 열고 있는 프로세스들을 모두 종료하도록 수동으로 조치해야 합니다.

FSR은 우분투 환경에서 dkms를 사용하고 있습니다. dkms에 FSR 커널 모듈 소스를 등록해두면, 우분투에 새로운 커널이 설치될 때 자동으로 그 커널에 맞는 FSR 커널 모듈을 추가로 빌드해서 생성합니다. 기존 커널의 모듈은 그대로 유지되어 커널별로 하나씩 보관됩니다. 이후 FSR 서비스가 기동하면서 현재 커널용 모듈을 찾아서 올리게됩니다.

dkms가 FSR 커널 모듈을 빌드하기 위해서는 해당 커널의 헤더가 필요하며, 헤더가 없으면 dkms는 빌드를 건너뜁니다. 그래서 이후 FSR 서비스가 기동하더라도 아래와 같이 커널 모듈을 찾을 수 없다는 오류가 발생할 수 있습니다.

위 오류는 커널 헤더 미설치 외에도 다양한 원인으로 발생할 수 있는 문제입니다. 만약 수동으로 우분투의 새 커널 이미지를 설치한 경우 설치 로그에 아래와 같은 사항을 바로 확인할 수 있고 FSR 커널 모듈을 찾지 못하는 원인이 커널 헤더 미설치하는 점을 확인할 수 있습니다.

하지만 우분투 커널 자동 업데이트 시에는 이러한 정보가 드러나지 않기 때문에 파악이 어려울 수 있습니다. 이 때는 아래 로그 파일의 내용을 통해 문제의 원인을 파악할 수 있습니다.

• /var/log/apt/term.log

  • apt 명령어 실행으로 자동 실행된 dkms가 커널 모듈 빌드를 건너 뛴 상황인지 파악 가능

커널 헤더 미설치로 dkms가 FSR 커널 모듈 빌드를 건너 뛴 상황을 확인한 경우 커널 헤더 설치로 간단히 문제가 해결될 수 있습니다.

• apt-get install linux-headers-$(uname -r)

커널 헤더를 설치하면 자동으로 dkms 훅이 설치된 커널 헤더 버전에 맞는 FSR 커널 모듈을 빌드해서 생성합니다. 생성 후 FSR 서비스를 기동하면 문제 없이 서비스가 실행됩니다.

만약 dkms 훅이 정상 동작하지 않은 경우 아래 명령으로 직접 dkms가 FSR 커널 모듈을 빌드하도록 명령을 내릴 수 있습니다.

• dkms autoinstall: 현재 부팅된 커널 버전에 맞는 FSR 커널 모듈을 빌드 후 생성

• dkms autoinstall -k 5.15.199-kasan: 현재 부팅된 커널은 아니지만 이미 설치된 커널 버전에 맞는 FSR 커널 모듈 빌드 후 생성