| Table of Contents |
|---|
스플릿 브레인
개요
복제 클러스터의 관리자 또는 관리(HA) 소프트웨어에 의해 특정 시점에 소스 노드가 2 노드 이상 되는 상태를 스플릿 브레인(이하 SB) 이라고 합니다. SB는 복제 연결이 단절될 때 발생하며 양 노드가 서로의 역할과 상태를 알 수 없는 상태에서 동시에 소스노드가 되는 상황입니다. 이렇게 SB가 발생하면 복제 클러스터가 2개의 복제 SET으로 분할되어 잠재적으로 데이터가 유실될 수 있는 상태에 놓입니다. SB 발생을 인지하면 관리자는 다음의 절차에 따라 SB를 해결하고 복제를 정상화 시켜야 합니다.
감지
...
Split-Brain
Overview
The state in which the source node becomes more than two nodes at a specific time by the administrator or management (HA) software of the replication cluster is called a split brain (SB). SB occurs when the replication connection is disconnected, and both nodes become source nodes at the same time without knowing each other's role and status. When this SB occurs, the replication cluster is split into two replication SETs, putting it in a state of potentially data loss. Upon recognizing the occurrence of SB, the administrator must resolve the SB and normalize the replication according to the following procedure.
Detect
The FSR can internally identify whether both nodes are in SB state. The identification of SB is performed through RID exchange at the time when the replication connection is established. As a result, if it is recognized as SB, the replication connection is immediately disconnected and the connection is standby in a standalone state. The following is the output log when SB occurs.
| Code Block |
|---|
2019-12-19 14:50:03.629 WRN establishing error=split-brain compare=newer key=1 peer=node3 resource=r0 state=connected |
...
Resolve
SB 를 해결하는 방법은 SB가 발생한 두 노드 중 희생할 노드를 결정하는 것으로 시작합니다. 희생할 노드가 결정되면 희생노드 상에서 다음의 명령을 통해 희생노드의 데이터를 폐기하는 옵션으로 상대노드와 연결하여 최종 SB를 해결합니다The way to solve SB starts with deciding which of the two nodes the SB will sacrifice to. When the node to be sacrificed is determined, the data of the victim node is discarded through the following command on the victim node, and the final SB is resolved by connecting with the other node.
| Code Block |
|---|
fsradm connect --discard-my-data <res-id> <peer-node> |
When the SB is resolved by establishing a connection with --discard-my-data 로 연결을 수립하여 SB를 해결하면 희생노드는 상대노드를 기준으로 재 동기화하여 최신 복제 데이터 셋으로 복구 합니다.
...
, the victim node resynchronizes based on the other node and restores the latest duplicate data set.
| Info |
|---|
When multiple SBs occur, synchronization between victim nodes does not occur, so it can be resolved by establishing a connection with --discard-my-data 로 연결을 수립하여 해결할 수 있습니다from all victim nodes. |
장애 대응
FSR 은 다음의 오류 상황들을 장애로 규정하고 해당 장애가 발생할 경우 이에 대한 후속 대응을 수동으로 수행해야 합니다.
- 복제 대상 오류
- 파일 I/O 오류
복제 대상 오류
복제 대상이 위치한 볼륨이 운영 중 의도치 않게 마운트 해제 되거나 물리적 파손으로 인해 저장매체 자체에서 문제가 되는 등 복제 대상 자체에서 장애가 발생할 수 있습니다.. 이 경우 사용자는 복제 대상을 다시 복구하여 볼륨 장치가 다시 가동될 수 있도록 조치해야 합니다. 수동 복구가 완료되면 전체 동기화를 통해 복제를 재 시작 해야 합니다.
파일 I/O 오류
파일 I/O 는 파일경로 문제로 인한 오류, 계정에 따른 권한 문제 등 다양한 상황에서 오류가 발생될 수 있습니다. I/O 오류가 자주 발생되는 것은 아니지만 의도치 않은 환경의 변화가 있거나 예외 상황에 대해 유연하게 대응하도록 작성되지 못한 응용에 의해 오류가 발생되는 것은 서비스 운영 중에 발생할 수 있는 통상적인 상황 입니다. I/O 오류가 발생되면 해당 예외 상황에 대해 응용 프로그램들은 예외 처리를 수행하게 되어 있으며 이후 동작은 응용 프로그램에 따라 다르게 대응됩니다. 이렇게 소스 측 응용 프로그램에 의한 파일 I/O의 오류는 언제든지 발생될 수 있는 일반적인 파일 I/O 오류로 보며 장애로 간주하지 않습니다. 그러나 fsr 엔진에서 수행하는 파일 I/O 에서오류가 발생한다면 이는 장애가 됩니다. fsr 이 파일 I/O 를 할 수 없으면 미러링 연산이 근본적으로 불가하며 복제를 즉시 중단합니다.
fsr 엔진에서 발생한 I/O 오류의 오류 코드는 로그로 기록되며 해당 오류 코드를 통해 오류의 원인을 추정할 수 있습니다. 관리자는 이를 통해 장애를 수동으로 복구해야 하며 fsr의 I/O를 정상화해야 합니다. 정상화된 환경에서 최종적으로 리소스를 다시 기동시키고 전체동기화를 수행하여 복제를 재개합니다.
디스크 검사
디스크 볼륨의 물리적 오류는 미디어 자체의 손상에 기인하여 복구하기 어렵지만 파일시스템 수준의 논리적인 오류는 유틸리티(윈도우즈의 chkdsk 리눅스의 fsck)를 통해 검사하거나 복구할 수 있습니다.
...
Fault
Describes the subsequent response to the following failure situations
- Disk failure
- File I/O errors in the FSR engine
Disk failure
Failures can occur on the replication target disk itself, such as when the volume on which the replication target resides is unintentionally unmounted during operation or when the storage medium itself fails due to physical damage. In this case, the user should take steps to repair the replication target so that the volume device is up and running again. Once the manual repair is complete, replication should be restarted with a full synchronization.
Monitoring disk health
FSR periodically monitors the health of the disks to detect if something is wrong with them. This is based on S.M.A.R.T. (Self-Monitoring, Analysis, and Reporting Technology) technology, and the frequency of the monitoring can be specified as follows.
| Info |
|---|
"disk": { "health": { "period": 10 }}, |
Engine file I/O errors
File I/O can fail in a variety of situations, including errors due to file path issues and account permissions. Although I/O errors do not occur frequently, it is a common occurrence during service operation that they are caused by unintended changes in the environment or by applications that are not written to respond flexibly to exceptional situations. When an I/O error occurs, applications are expected to perform exception handling for that exception, and the subsequent behavior depends on the application. In this way, errors in file I/O by source-side applications are viewed as normal file I/O errors that can occur at any time and are not failures.
However, if an error occurs in file I/O performed by the fsr engine, it is a failure. If fsr is unable to do file I/O, mirroring is essentially impossible and replication stops immediately.
The error codes for I/O errors encountered by the fsr engine are logged, and the cause of the error can be estimated from the error code. From there, the administrator must manually repair the failure and normalize I/O on the fsr. In a normalized environment, resources are finally restarted and a full sync is performed to resume replication.
Check Disk
Physical errors on disk volumes are difficult to repair because they are caused by damage to the media itself, but logical errors at the filesystem level can be checked or repaired with a utility (chkdsk on Windows, fsck on Linux).
It is usually safe to use these utilities after the volume has been unmounted, and if logical faults are detected and subsequently repaired during this check, the volume must be spun up again as a replication resource and given a full synchronization to ensure consistency with the target.
File Lock
File Handle Closing Error
During the file locking process, there is a procedure to clean up the handles of files that are already open among the files to be replicated. This section explains what to do if the following error message occurs when performing this procedure.
| Info |
|---|
ERR handle closed error="attach: operation not permitted" exec=handle group= key=2 name=/opt/data/b/1234.txt node=b pid=76716 resource=r0 |
The above error only occurs on Linux and is caused by the ptrace utility not being authorized to perform that control, and to resolve it you will need to adjust your system's permission settings. If the value of /proc/sys/kernel/yama/ptrace_scope is set to 3, you will need to adjust it to a value between 0 and 2, and reboot after adjusting the setting. If you are unable to adjust the value of the ptrace_scope setting on your system, you will need to manually kill all processes that are opening files.