...
Info |
---|
Disk failures occur more often than expected, based on experience in operating replication services. These results depend on the sub-disk layer. This means that errors in the disk layer, that is, the standard SCSI layer, can occur at any time and at any time, which means that they must be handled separately from the stability of the disk layer and be flexible in terms of replication. The detach policy, which has been provided as a disk failure policy, was a policy where replication was unilaterally stopped at a specific point in time in terms of service operation. This method is also difficult to post-recovery and disadvantageous in terms of continuing service operation. We devised a passthrough policy to solve this problem and set it as the default policy for bsr. The pass-through policy records the OOS for the block when an I/O error occurs and delivers the failed I/O result to the file system. At this time, if the file system succeeds by retrying to write to the block where the error occurred and resolves the OOS through this, it will lead to the temporary overcoming of the disk layer error. Although OOS cannot be completely resolved depending on the operating characteristics of the file system, some remaining OOS can be resolved by resynchronizing through connection retries. In other words, the pass-through policy induces the Filesystem to resolve the error block by itself or through synchronization, and basically ensures that the service continues to operate even if there is a problem with the disk I/O. |
Temporary error handling
If the I/O 에러 정책을 패스스루(passthough)로 설정할 경우 I/O 에러의 결과는 파일시스템으로 전달되고 bsr 은 오류가 발생한 I/O 블럭을 OOS로 기록합니다. 이러한 OOS는 I/O 에러가 일시적이었다면 파일시스템에 의해 재 시도 되어 스스로 해소되거나, 그렇지 않다면 복제 재연결을 통해 재동기화를 유도하여 해당 OOS 영역을 해소합니다. 이 때 OOS를 해소하는 동기화의 방향이나 절체 여부 등의 운영은 관리자 또는 HA 운영 로직에 맡깁니다.
Info |
---|
bsr 은 I/O 오류가 일시적인지 또는 영구적인지 판단할 수 없으며 섹터 단위의 I/O 오류 추적 등의 구체적인 오류 통계를 취합하지는 않습니다. 다만 오류가 발생한 해당 장치에 대한 I/O 에러 발생 회수 정보만 유지합니다. 비록 구체적인 정보는 알 수 없지만 bsradm status의 I/O 에러 회수를 토대로 에러가 발생한 정도를 파악할 수 있습니다. 만약 일시적 에러가 발생했다면 status에 보여지는 io error 와 oos 는 다소간의 양만 기록되어 있을 것이며 시간이 지나도 그 양은 증가하지 않을 것 입니다. |
Permanent error handling
일시적으로 I/O 오류가 발생하여 다소간의 OOS가 기록되는 상황을 제외한 모든 디스크 오류 상황을 영구적 오류 상태로 간주합니다.
영구적 오류는 다양한 상황에서 발생할 수 있습니다. 디스크에 실제 물리적인 손상(배드블럭)이 발생한 경우 또는 스토리지에 연결된 케이블이 단선되어 볼륨이 제거된 경우 SCSI 컨트롤러에 장애가 발생한 경우 등 실제로 스토리지 계층에 문제가 있는 상황을 포함해, 관리자의 실수 또는 bsr과 호환되지 않는 다른 프로그램의 영향으로 볼륨이 제거되는 복제 외적인 상황 등이 모두 포함됩니다. 이러한 영구적 오류가 발생하면 관리자는 복제를 재구성하거나 디스크를 교체해야 합니다. 영구적 디스크 오류를 조치하기 위해선 먼저 리소스를 down 한 이후 디스크를 복제 상태에서 분리(detach)해야 합니다. 물론 재구성을 해야 하는 복제 리소스에 대해선 메타디스크를 재초기화 해야 합니다.
디스크 오류 정책을 detach 정책으로 하여 리소스 분리를 자동으로 수행할 수도 있으나 자동분리(detach) 정책 보다는 passthrough 정책으로 설정하는 것을 권장합니다. passthrough 정책이 디스크의 일시적 오류에 능동적으로 대처할 수 있는 만큼 서비스 운영 측면에서 보다 더 합당합니다error policy is set to passthough, the result of the I/O error is transferred to the file system, and the bsr records the I/O block in error as OOS. If the I/O error was temporary, the OOS is retried by the file system and resolved by itself. Otherwise, the OOS area is resolved by inducing resynchronization through replication reconnection. At this time, it is left to the administrator or the HA operation logic to manage operations such as the direction of synchronization to resolve the OOS.
Info |
---|
bsr cannot determine if an I/O error is temporary or permanent, and it does not collect specific error statistics such as sector-by-sector I/O error tracking. Instead, only the number of I/O error occurrence information for the device in which the error occurred is maintained. Although the specific information is not shown, the degree of error can be determined based on the number of I/O errors in bsradm status. If a temporary error occurs, the io error and oos shown in status will only be recorded in a small amount and will not increase over time. |
Permanent error handling
All disk failure situations are considered as permanent errors except those in which some OOS is recorded due to temporary I/O errors.
Permanent errors can occur in a variety of situations. For example, if the physical damage (bad block) to the disk occurs, cable of storage is disconnected, the volume is removed, and the SCSI controller has failed. This includes non-replicating situations in which the volume is removed due to the mistake of administrator or other programs that are not compatible with bsr.
If this permanent error occurs, the administrator must reconfigure replication or replace the disk. To fix a permanent disk failure, you must first down the resource and then detach the disk from the replication state. Of course, you must reinitialize the metadisk for any replication resource that needs reconfiguration.
It is possible to automatically perform resource detaching by using detach policy, but it is recommended to set the passthrough policy rather than the detach. The passthrough policy is more reasonable in terms of service operation as it can actively respond to temporary failures on disk.
디스크 교체
다음과 같이 메타 데이터 세트를 재생성하고, 리소스를 다시 연결합니다. 필요하다면 명시적으로 동기화 명령을 수행하여 전체동기화를 진행합니다.
...