...
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.
디스크 교체
...
Disk replacement
Regenerate the meta data set and reconnect the resources as follows. If necessary, perform a full synchronization by explicitly executing the synchronization command.
| Code Block |
|---|
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> |
기타
...
Etc
For disk read errors and meta disk 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 을 통한 특별한 메커니즘으로 블록 디바이스의 정합성을 맞추게 됩니다. 이와 관련한 자세한 설명은 액티비티 로그를 참고하세요.
영구적 장애
영구적이거나 복구가 불가능한 장애가 발생한 경우, 다음 단계를 수행해야 합니다.
장애가 발생한 하드웨어를 유사한 성능 및 디스크 용량의 하드웨어로 교체합니다.
| Info |
|---|
타깃에서 기존 보다 작은 용량의 디스크로 교체할 경우 복제 연결이 거부되므로 주의해야 합니다. |
기본 시스템과 응용 프로그램을 설치합니다.
bsr을 설치하고, 동작하고 있는 노드의 /etc/bsr.d/ 아래에 있는 파일들과 /etc/bsr.conf를 복사합니다.
리소스 재구성 에 맞게 재 구성하고, 리소스를 기동하고 초기 동기화를 시작합니다.
만일 Primary 가 이미 동작하고 있다면 연결되면서 자동으로 동기화가 시작되므로 수동으로 동기화를 할 필요는 없습니다errors, automatic detach policy is applied to stop replication, and resources that have been stopped can be recovered only through reconfiguration.
Node failure
If the node goes down due to hardware failure or manual intervention, the other node detects the situation, switches the connection state to Connecting, and waits in disconnected mode until the other node reappears. Node failures are usually treated as temporary failures that are self-recovering, but must be manually recovered in the permanent failure.
Secondary failure
If the target side goes down, the source side can continue operating in disconnected mode, but modifications to the block will not be replicated to the other node. However, the information on the block being changed is stored internally and waits for synchronization with the changed block when the counterpart node is restored later.
Primary failure
During replication, the primary node may stop unexpectedly due to power failure. This state is called the Crashed Primary state. At this time, the other node detects that the primary node has disappeared and switches to disconneted mode. The crashed primary node is restarted through the booting process and started in an automatic secondary role by the service. It does not automatically promote the Primary role here. The Crashed Primary node establishes a connection with the Secondary node, and in the process, both nodes recognize each other that they are in the Crashed Primary state. After that, the consistency of both nodes is matched through the process of synchronization. in this case, when the failed node recovers, manual intervention is no longer required, but the cluster management application (HA) can determine the promotion of a particular node and continue its operational services.
If the source side goes down, HA must first decide whether to switch over. Depending on whether or not the switchover is made, it is determined by which node to synchronize when the source node is later restored and joined to the cluster.
When switching, the node that was the standby node acts as the new source node.
If you wait without switching, the node that was the original source node acts as the synchronization source node.
In case of primary node failure, special mechanism through AL will match the consistency of the block device. Please refer to the activity log of BSR Internals for details on this.
Permanent failure
In the event of a permanent or non-recoverable failure, you must perform the following steps.
Replace failed hardware with hardware of similar performance and disk capacity.
| Info |
|---|
Note that if the target is replaced with a disk with a smaller capacity than the existing one, the replication connection is rejected. |
Install basic systems and applications.
Install bsr and copy the files under /etc/bsr.d/ on the running node and /etc/bsr.conf.
It reconfigures according to the resource reconfiguration procedure, starts the resource, and starts the initial synchronization.
If Primary is already running, synchronization starts automatically when connected, so there is no need to synchronize manually.
스플릿 브레인
스플릿 브레인 동작 설정
bsr 에서는 스플릿 브레인을 감지하면 자동으로 운영자에게 알릴 수 있는 방법을 제공합니다.
...