| Table of Contents |
|---|
목적
디스크에 쓰기 작업이 발생되면 bsr은 로컬 볼륨에 쓰기 작업을 진행하고 이와 동시에 네트워크를 통해 데이터 블럭을 전송합니다. 이 두 가지 작업은 복제를 수행하기 위해 동시에 발생합니다. 하지만 가끔 어느 한 순간에는 쓰기는 완료되었지만, 네트워크 전송은 아직 일어나지 못한 경우도 발생할 수 있습니다.
이 순간 만약 Active 노드에 장애가 발생하여 절체(fail-over)가 되면 노드들 간에 데이터 블럭은 동기가 맞지 않은 상태가 됩니다. 그것은 장애가 발생한 노드에서는 디스크에 기록했지만, 복제가 완료되지 않은 상태에서 절체가 되었기 때문입니다. 따라서 장애가 발생했던 액티브 노드가 복구되면 액티브 노드에 쓰여졌던 블럭들은 동기화할 데이터 셋(data set)으로부터 제거되어야 합니다. 그렇지 않으면 장애가 났던 노드는 정상 노드에서 한 번이라도 더 쓰기가 진행된 상태가 되어 스토리지 복제의 원칙인 "all or nothing"(모든 것이 일치하거나 아니면 포기하거나)을 위반하게 됩니다. 이 이슈는 bsr에만 국한 된 것이 아니라 거의 모든 스토리지 복제 솔루션에서 발생하는 이슈입니다. 어떤 스토리지 솔루션들은 액티브 측에서 장애가 발생하면 복구 후에도 새롭게 전체 동기화를 해야할 경우도 있습니다.
bsr에서는 메타 데이터 영역에 activity log(AL)를 저장하여, 최근에 기록된 해당 블록들을 추적할 수 있게 합니다. 이 영역을 hot extents라고 부릅니다. 액티브 였던 노드가 갑자기 셧다운 되어 리부팅되고 리소스 재기동 후 동기화를 하게 되면 전체 동기화를 하지 않고 AL에서 해당 hot extents만 동기화 하면 됩니다. 이렇게 하면 장애가 발생했던 액티브 노드에 대한 동기화 시간을 대폭적으로 줄일 수 있습니다.
Active extents
액티비티 로그는 active extent의 개수를 설정에서 정해 줄 수 있습니다. Primary 장애 후 재전송되는 데이터 크기는 모든 active extent 값에 4MiB를 곱한 크기 입니다. 이 파라미터는 다음과 같은 상반된 특성을 잘 절충한 값으로 설정되어야 합니다.
많은 Active extents - active extent를 많이 유지하는 것은 쓰기 처리량을 향상 시킵니다. 새로운 extent 가 활성화 될 때마다, 기존의 extent는 비활성화 상태로 재설정 되고 이런 전환과정을 메타 데이터 영역에 기록합니다. active extents의 수가 많은 경우 기존 active extents와 스와핑하는 과정이 적게 일어나므로 메타 데이터에 쓰는 작업이 감소되어 성능이 향상됩니다.
작은 Active extents - active extent를 작게 유지하는 것은 액티브 노드의 장애시 후속 복구를 위한 동기화 시간을 줄여줍니다.
운영 측면에서 성능향상에 주로 목적을 두어야 겠지만 동기화 시간이 늘어나는 점에 대해선 고려해야 합니다.
적당한 AL 크기
extents 수를 정하는 것은 동기화 속도에 원하는 동기화 시간을 기준으로 정해야 합니다. Active extents의 수는 다음과 같이 계산될 수 있습니다.
...
R - 지정된 동기화 속도. 단위는 MB/s
tsync - 타겟 동기화 시간. 단위는 초(sec)
E - Active extents의 개수
예를 들면, 클러스터가 200 MiByte/s의 처리 속도의 I/O 서브시스템에서 60 MiByte/s (R)의 동기화 속도, 4분 또는 240초(tsync=240)로 타겟 동기화 시간이 유지된다고 가정하면 아래처럼 계산할 수 있습니다.
...
...
Purpose
When a write operation to disk occurs, bsr writes to the local volume and simultaneously transfers a block of data over the network. These two actions occur simultaneously to perform replication. Sometimes, however, writing may be completed at one moment, but network transmission may not yet occur.
At this moment, if the Active node fails and becomes fail-over, the data blocks between the nodes will be out of sync. That is because the failed node wrote to disk, but it was switched over without replication being completed. Therefore, when the failed active node is restored, blocks written to the active node must be removed from the data set to be synchronized. Otherwise, the failed node will be at least once more writeable on the normal node, violating the principle of storage replication, "all or nothing" (all matches or give up). This issue is not limited to bsr, but is an issue with almost all storage replication solutions. Some storage solutions require a full full synchronization even after recovery if the active side fails.
bsr stores the activity log (AL) in the metadata area, allowing you to track the recently recorded blocks. These areas are called hot extents. If the active node suddenly shuts down and reboots and synchronizes after restarting the resource, it is only necessary to synchronize the corresponding hot extents in AL without performing full synchronization. This can drastically reduce the synchronization time for the active node that failed.
Active extents
The number of active extents can be set in the activity log. The data size that is retransmitted by resync after the primary failure is the size of all active extents multiplied by 4 MiB. This parameter should be set to a good compromise between the following conflicting characteristics:
Many active extents - Keeping a lot of active extents improves write throughput. Whenever a new extent is activated, the existing extent is reset to inactive state and this conversion is recorded in the metadata area. If the number of active extents is large, swapping with existing active extents takes less time, which reduces the write to metadata and improves performance.
Small active extents - Keeping the active extents small reduces the synchronization time for subsequent recovery in case of active node failure.
Performance should be primarily aimed at improving performance, but you should consider the increase in synchronization time.
Recommended AL size
Determining the number of extents should be based on the desired sync time for the sync speed. The number of active extents can be calculated as follows:
...
R - Specified sync speed. Unit is MB/s
tsync - Target sync time. Unit is second (sec)
E - Number of Active extents
For example, assuming that the cluster maintains a target synchronization time of 60 MiByte/s (R), 4 minutes, or 240 seconds (tsync = 240) in the I/O subsystem with a processing speed of 200 MiByte/s. You can calculate as below.
...
3600 is an exact value, but the bsr hash function that implements AL works best when the number of extents is set to a prime number.