...

동기화 속도 조정

동기화가 백그라운드에서 동작하면 타깃의 데이터는 일시적으로 불일치(Inconsistent)한 상태가 됩니다. 이러한 Inconsistent 상태는 가능한 짧게 유지해야 정합성 보장 측면에서 좋기 때문에 동기화 속도가 충분하게 설정되어 있어야 유리합니다. 그러나 복제와 동기화는 같은 네트워크 대역을 공유하고 있으며 만약 동기화 대역이 높게 설정된다면 상대적으로 복제 대역은 적게 부여될 수 밖에 없습니다. 복제 대역이 낮아지면 로컬의 I/O latency에 영향을 주게 되고 결과적으로 운영 서버의 로컬 I/O 성능 저하를 가져오게 됩니다. 복제든 동기화든 어느 한쪽이 일방적으로 대역을 많이 점유하면 상대적으로 다른 쪽 동작에 영향을 주게 되므로 bsr 은 복제 대역을 최대한 보장하면서 동기화 대역을 복제 상황에 따라 적당히 조절하는 가변대역 동기화를 구현하고 있으며 이를 기본 정책으로 사용합니다. 이와 반대로 고정대역 동기화 정책은 복제에 관계없이 동기화 대역을 항상 보장하는 방식으로 서버 운영 중에 사용할 경우 로컬 I/O 성능의 저하를 가져올 수 있으므로 일반적으로는 권장되지 않고 특수한 상황에서만 사용해야 합니다.

고정대역 동기화

백그라운드에서 수행되는 재동기화를 위해 사용되는 최대 대역폭은 리소스의 resync-rate 옵션에 따라 결정됩니다. 해당 옵션은 다음과 같이 /etc/bsr.conf 리소스 구성의 disk 섹션에 포함되어 있습니다.

resource <resource> {
  disk {
    resync-rate 40M;  
    c-min-rate 40M;  
    c-plan-ahead 0;  
    ...
  }
  ...
}

resync-rate, c-min-rate 설정은 초당 바이트 단위로 지정됩니다. 기본 단위는 Kibibyte이고 4096의 값은 4MiB로 해석됩니다.

가변대역 동기화

다중 리소스가 복제/동기화 네트워크를 공유하는 구성일 경우 고정대역 동기화는 최적의 방법이라 할 수 없습니다. 동일한 복제 네트워크를 공유하기 때문에 특정 복제 리소스 채널에 대해서 동기화율이 점유 당할 경우 다른 리소스들은 고정 동기화율이 보장되지 않게 됩니다. 이 경우, 가변대역 동기화를 통해 각각의 복제 채널의 동기화율을 동적으로 조정 하도록 구성하여 동기화율이 점유당하는 것을 완화시킬 수 있습니다. bsr은 이 모드에서 초기 동기화 속도를 결정한 후 자동 제어 루프 알고리즘을 통해 지속적으로 동기화 속도를 조정합니다. 이 알고리즘은 포그라운드 복제가 가능하도록 충분한 대역폭을 보장하며, 백그라운드 동기화가 포그라운드 I/O에 미치는 영향을 크게 완화시킵니다.

가변대역 동기화를 위한 최적의 구성은 사용 가능한 네트워크 대역폭, 응용 프로그램 I/O 패턴 및 복제 링크 혼잡상황에 따라 달라질 수 있으며, 복제 가속기(DRX) 사용 여부에 따라 최적의 구성 설정이 달라질 수 있습니다.

효율적인 동기화

bsr 에선 효율적인 동기화를 위해 체크섬 기반의 동기화, 운송동기화, 비트맵 제거 동기화 등 다양한 기능을 제공합니다.

체크섬 기반 동기화

체크섬 데이터 요약을 사용하면 bsr의 동기화 알고리즘의 효율성을 더욱 개선할 수 있습니다. 체크섬 기반 동기화는 동기화하기 전에 블록을 읽고 현재 디스크에 있는 내용의 해시(hash) 요약을 구한 다음, 상대 노드로부터 같은 섹터를 읽어 구한 해쉬 요약 내용과 비교합니다. 해시 내용이 일치하면 해당 블럭에 대한 동기화 쓰기(re-write)를 생략하고 일치하지 않을 경우 동기화 데이터를 전송합니다. 이 방식은 동기화 해야될 블럭을 단순히 덮어쓰는 기존 방식에 비해 성능에서 유리할 수 있으며 연결이 끊어져 있는(disconnect 상태) 동안 파일 시스템이 섹터에 같은 내용을 다시 썼다면 해당 섹터에 대해선 재동기화를 생략하게 되므로 전체적으로 동기화 시간을 단축시킬 수 있습니다.

운송 동기화

디스크를 직접 가져와서 구성하는 운송 동기화는 아래와 같은 상황에 적합합니다.

• 초기 동기화 할 데이터의 량이 매우 큰 경우(수백 기가바이트 이상)

• 거대한 데이터 사이즈에 비해 복제할 데이터의 변화율이 적을 것으로 예상되는 경우

• 소스, 타깃 사이트간 가용 네트워크 대역폭이 제한적인 경우

위와 같은 상황에서 직접 디스크를 가져다가 동기화 하지 않고 일반적인 디바이스 동기화 방법으로 초기화를 진행한다면 동기화를 하는 동안 매우 오랜 시간이 걸릴 것입니다. 디스크 크기가 크고 물리적으로 직접 복사하여 초기화 시킬 수 있다면 이 방법을 권장합니다.

일단 한가지 상황을 가정해보겠습니다. Primary인 상태로 연결이 끊어진 로컬 노드가 있습니다. 즉, 디바이스 구성은 완료되었고 동일한 bsr.conf 사본은 양 노드에 모두 존재합니다. 로컬 노드에서 초기 리소스 승격(initial resource promotion)을 위한 명령들은 실행했지만 리모트 노드는 아직 연결되어 있지 않습니다.

• 로컬 노드에서 다음 명령을 실행합니다.

  Code Block
  bsradm new-current-uuid --clear-bitmap <resource>

• 복제 대상이 될 데이터와 그 데이터의 metadata의 사본을 똑같이 생성합니다. 예를 들어, RAID-1 미러에서 hot-swappable drive를 사용할 수도 있을 겁니다. 물론 이 상황에서는 RAID set이 미러링을 지속하기 위해 새로운 drive로 교체해 주어야 할 것입니다. 그러나 여기서 제거했던 디스크 드라이브는 다른곳에서 바로 사용할 수 있는 말 그대로의 사본입니다. 만약 로컬 블록 디바이스가 스냅샷 사본 기능을 지원한다면 이 기능을 사용하면 됩니다.

• 로컬 노드에서 아래 명령을 실행합니다.

  Code Block
  bsradm new-current-uuid <resource>

두 번째 명령 실행에서는 --clear-bitmap 옵션이 없습니다.

• 원본 데이터와 동일한 사본을 물리적으로 직접 가져와서 원격 노드에 사용할 수 있도록 구성 합니다.

• 물리적으로 디스크를 직접 연결할 수도 있고, 가져온 데이터를 비트단위로 통째로 기존에 가지고 있던 디스크에 복사하여 사용해도 됩니다. 이 과정은 복제한 데이터 뿐만 아니라 메타데이터에도 해 주어야 합니다. 이런 절차가 수용될 수 없다면 이 방법은 더 이상 진행 할 수 없습니다. 

• 원격 노드에서 bsr 리소스를 기동시킵니다.

  Code Block
  bsradm up <resource>

두 노드가 연결되면 디바이스 전체 동기화(full device synchronization)를 시작하지는 않을 것입니다. 대신에 bsradm--clear-bitmap new-current-uuid 명령을 호출 한 뒤부터 변경된 블럭에 관한 동기화만 자동으로 개시됩니다.

만약 아무런 변화가 없더라도 새로운 Secondary 노드에서 롤백되는 Activity Log에서 다뤄지는 영역에 따라 간단한 동기화가 있을 수 있습니다. 

비트맵 제거 동기화

비트맵을 클리어(--clear-bitmap)하는 옵션을 사용하여 장시간에 걸친 초기 전체 동기화 없이 빠르게 복제 상태가 될 수 있도록 할 수 있습니다. 다음은 이러한 운영 사례를 소개합니다.

새로운 Current UUID를 생성하고 Bitmap UUID를 지워서 초기 동기화를 건너 뛰는 데 사용할 수 있습니다. 이 사용 예는 지금 막 생성된 메타 데이터에서만 작동합니다.

1. 양 노드에서, 메타를 초기화 하고 장치를 구성합니다. bsradm -- --force create-md res

2. 양 노드의 리소스를 기동하고 초기 핸드쉐이크 시점에 서로의 볼륨 크기를 인식합니다. bsradm up res

3. 양 노드가 Secondary/Secondary, Inconsistent/Inconsistent 로 연결된 상태에서 새로운 UUID를 생성하고 비트맵을 클리어 합니다. bsradm new-current-uuid --clear-bitmap res

4. 이제 양노드는 Secondary/Secondary, UpToDate/UpToDate 상태가 되고 한 쪽을 Primary 로 승격한 후 파일시스템을 생성합니다. bsradm primary res mkfs -t fs-type $(bsradm sh-dev res)

...

효율적인 동기화

bsr 에선 효율적인 동기화를 위해 FastSync, 체크섬 기반의 동기화, 운송동기화, 비트맵 제거 동기화 등 다양한 기능을 제공합니다.

FastSync

bsr은 디스크 전체 영역을 대상으로 수행하는 기존 전체 동기화 방식을 파일시스템이 사용하는 영역에 대해서만 동기화하는 빠른 동기화(FastSync)로 개선하였습니다. bsr 은 FastSync 를 위해 파일시스템의 사용영역 정보를 취합하여 해당 사용영역을 OOS 로 기록하고 동기화를 수행합니다.

FastSync 는 초기동기화를 위한 bsradm primary --force 명령 시점, invalidate/invalidate-remote, 온라인 정합성 검사 시점에 적용되어 동작합니다. FastSync 가 동작하는데 있어서 사용자가 특별히 설정해야 할 옵션은 없습니다.

체크섬 기반 동기화

체크섬 데이터 요약을 사용하면 bsr의 동기화 알고리즘의 효율성을 더욱 개선할 수 있습니다. 체크섬 기반 동기화는 동기화하기 전에 블록을 읽고 현재 디스크에 있는 내용의 해시(hash) 요약을 구한 다음, 상대 노드로부터 같은 섹터를 읽어 구한 해쉬 요약 내용과 비교합니다. 해시 내용이 일치하면 해당 블럭에 대한 동기화 쓰기(re-write)를 생략하고 일치하지 않을 경우 동기화 데이터를 전송합니다. 이 방식은 동기화 해야될 블럭을 단순히 덮어쓰는 기존 방식에 비해 성능에서 유리할 수 있으며 연결이 끊어져 있는(disconnect 상태) 동안 파일 시스템이 섹터에 같은 내용을 다시 썼다면 해당 섹터에 대해선 재동기화를 생략하게 되므로 전체적으로 동기화 시간을 단축시킬 수 있습니다.

운송 동기화

디스크를 직접 가져와서 구성하는 운송 동기화는 아래와 같은 상황에 적합합니다.

• 초기 동기화 할 데이터의 량이 매우 큰 경우(수백 기가바이트 이상)

• 거대한 데이터 사이즈에 비해 복제할 데이터의 변화율이 적을 것으로 예상되는 경우

• 소스, 타깃 사이트간 가용 네트워크 대역폭이 제한적인 경우

위와 같은 상황에서 직접 디스크를 가져다가 동기화 하지 않고 일반적인 디바이스 동기화 방법으로 초기화를 진행한다면 동기화를 하는 동안 매우 오랜 시간이 걸릴 것입니다. 디스크 크기가 크고 물리적으로 직접 복사하여 초기화 시킬 수 있다면 운송동기화가 효율적일 수 있습니다.

일단 한가지 상황을 가정해보겠습니다. Primary인 상태로 연결이 끊어진 로컬 노드가 있습니다. 즉, 디바이스 구성은 완료되었고 동일한 bsr.conf 사본은 양 노드에 모두 존재합니다. 로컬 노드에서 초기 리소스 승격(initial resource promotion)을 위한 명령들은 실행했지만 리모트 노드는 아직 연결되어 있지 않습니다.

• 로컬 노드에서 다음 명령을 실행합니다.

  Code Block
  bsradm new-current-uuid --clear-bitmap <resource>

• 복제 대상이 될 데이터와 그 데이터의 metadata의 사본을 똑같이 생성합니다. 예를 들어, RAID-1 미러에서 hot-swappable drive를 사용할 수도 있을 겁니다. 물론 이 상황에서는 RAID set이 미러링을 지속하기 위해 새로운 drive로 교체해 주어야 할 것입니다. 그러나 여기서 제거했던 디스크 드라이브는 다른곳에서 바로 사용할 수 있는 말 그대로의 사본입니다. 만약 로컬 블록 디바이스가 스냅샷 사본 기능을 지원한다면 이 기능을 사용하면 됩니다.

• 로컬 노드에서 아래 명령을 실행합니다.

  Code Block
  bsradm new-current-uuid <resource>

두 번째 명령 실행에서는 --clear-bitmap 옵션이 없습니다.

• 원본 데이터와 동일한 사본을 물리적으로 직접 가져와서 원격 노드에 사용할 수 있도록 구성 합니다.

• 물리적으로 디스크를 직접 연결할 수도 있고, 가져온 데이터를 비트단위로 통째로 기존에 가지고 있던 디스크에 복사하여 사용해도 됩니다. 이 과정은 복제한 데이터 뿐만 아니라 메타데이터에도 해 주어야 합니다. 이런 절차가 수용될 수 없다면 이 방법은 더 이상 진행 할 수 없습니다. 

• 원격 노드에서 bsr 리소스를 기동시킵니다.

  Code Block
  bsradm up <resource>

두 노드가 연결되면 디바이스 전체 동기화(full device synchronization)를 시작하지는 않을 것입니다. 대신에 bsradm--clear-bitmap new-current-uuid 명령을 호출 한 뒤부터 변경된 블럭에 관한 동기화만 자동으로 개시됩니다.

만약 아무런 변화가 없더라도 새로운 Secondary 노드에서 롤백되는 Activity Log에서 다뤄지는 영역에 따라 간단한 동기화가 있을 수 있습니다. 

비트맵 제거 동기화

비트맵을 클리어(--clear-bitmap)하는 옵션을 사용하여 장시간에 걸친 초기 전체 동기화 없이 빠르게 복제 상태가 될 수 있도록 할 수 있습니다. 다음은 이러한 운영 사례를 소개합니다.

새로운 Current UUID를 생성하고 Bitmap UUID를 지워서 초기 동기화를 건너 뛰는 데 사용할 수 있습니다. 이 사용 예는 지금 막 생성된 메타 데이터에서만 작동합니다.

1. 양 노드에서, 메타를 초기화 하고 장치를 구성합니다. bsradm -- --force create-md res

2. 양 노드의 리소스를 기동하고 초기 핸드쉐이크 시점에 서로의 볼륨 크기를 인식합니다. bsradm up res

3. 양 노드가 Secondary/Secondary, Inconsistent/Inconsistent 로 연결된 상태에서 새로운 UUID를 생성하고 비트맵을 클리어 합니다. bsradm new-current-uuid --clear-bitmap res

4. 이제 양노드는 Secondary/Secondary, UpToDate/UpToDate 상태가 되고 한 쪽을 Primary 로 승격한 후 파일시스템을 생성합니다. bsradm primary res mkfs -t fs-type $(bsradm sh-dev res)

이러한 방식의 명백한 부작용 중 하나는 복제본에 오래된 가비지가 가득하다는 것입니다 (다른 방법을 사용하여 동일하게 만들지 않는 한), 온라인 검사 시 동기화되지 않은 블록 수를 찾을 것으로 예상됩니다. 볼륨에 이미 데이터가 있는 상황에서는 이 방식을 절대 사용해선 안됩니다. 언뜻보기에는 작동하는 것처럼 보일 수 있지만 일단 다른 노드로 전환하면 이미 있던 데이터는 복제되지 않았으므로 데이터가 깨집니다.

동기화 속도 조정

동기화가 백그라운드에서 동작하면 타깃의 데이터는 일시적으로 불일치(Inconsistent)한 상태가 됩니다. 이러한 Inconsistent 상태는 가능한 짧게 유지해야 정합성 보장 측면에서 좋기 때문에 동기화 속도가 충분하게 설정되어 있어야 유리합니다. 그러나 복제와 동기화는 같은 네트워크 대역을 공유하고 있으며 만약 동기화 대역이 높게 설정된다면 상대적으로 복제 대역은 적게 부여될 수 밖에 없습니다. 복제 대역이 낮아지면 로컬의 I/O latency에 영향을 주게 되고 결과적으로 운영 서버의 로컬 I/O 성능 저하를 가져오게 됩니다. 복제든 동기화든 어느 한쪽이 일방적으로 대역을 많이 점유하면 상대적으로 다른 쪽 동작에 영향을 주게 되므로 bsr 은 복제 대역을 최대한 보장하면서 동기화 대역을 복제 상황에 따라 적당히 조절하는 가변대역 동기화를 구현하고 있으며 이를 기본 정책으로 사용합니다. 이와 반대로 고정대역 동기화 정책은 복제에 관계없이 동기화 대역을 항상 보장하는 방식으로 서버 운영 중에 사용할 경우 로컬 I/O 성능의 저하를 가져올 수 있으므로 일반적으로는 권장되지 않고 특수한 상황에서만 사용해야 합니다.

고정대역 동기화

백그라운드에서 수행되는 재동기화를 위해 사용되는 최대 대역폭은 리소스의 resync-rate 옵션에 따라 결정됩니다. 해당 옵션은 다음과 같이 /etc/bsr.conf 리소스 구성의 disk 섹션에 포함되어 있습니다.

resource <resource> {
  disk {
    resync-rate 40M;  
    c-min-rate 40M;  
    c-plan-ahead 0;  
    ...
  }
  ...
}

resync-rate, c-min-rate 설정은 초당 바이트 단위로 지정됩니다. 기본 단위는 Kibibyte이고 4096의 값은 4MiB로 해석됩니다.

가변대역 동기화

다중 리소스가 복제/동기화 네트워크를 공유하는 구성일 경우 고정대역 동기화는 최적의 방법이라 할 수 없습니다. 동일한 복제 네트워크를 공유하기 때문에 특정 복제 리소스 채널에 대해서 동기화율이 점유 당할 경우 다른 리소스들은 고정 동기화율이 보장되지 않게 됩니다. 이 경우, 가변대역 동기화를 통해 각각의 복제 채널의 동기화율을 동적으로 조정 하도록 구성하여 동기화율이 점유당하는 것을 완화시킬 수 있습니다. bsr은 이 모드에서 초기 동기화 속도를 결정한 후 자동 제어 루프 알고리즘을 통해 지속적으로 동기화 속도를 조정합니다. 이 알고리즘은 포그라운드 복제가 가능하도록 충분한 대역폭을 보장하며, 백그라운드 동기화가 포그라운드 I/O에 미치는 영향을 크게 완화시킵니다.

가변대역 동기화를 위한 최적의 구성은 사용 가능한 네트워크 대역폭, 응용 프로그램 I/O 패턴 및 복제 링크 혼잡상황에 따라 달라질 수 있으며, 복제 가속기(DRX) 사용 여부에 따라 최적의 구성 설정이 달라질 수 있습니다.

혼잡 모드

...