...
리소스를 생성하고 삭제하기 까지의 전반적인 관리작업과 구성파일의 주요 설정에 대해 설명합니다.
리소스 생성
리소스 생성은 앞 절에서 설명한 리소스 구성파일을 준비하는 작업입니다. 구성파일을 작성했다면 리소스를 생성한 것으로 간주합니다. bsr 에서는 이 과정을 사용자가 수작업으로 수행해야 하며 이를 위한 별도의 CLI 나 API 는 제공 되지 않습니다.
한 번 구성파일을 작성하여 리소스가 생성되면 구성파일이 삭제 되기 전 까지는 해당 리소스가 생성된 상태로 계속 유지되고, 구성파일을 삭제해야 만 노드 상의 리소스를 완전히 삭제할 수 있습니다.
메타 초기화
리소스가 생성되면 최초 기동을 위해 메타디스크를 초기화 해야 합니다. 메타 디스크의 초기화는 다음의 명령으로 수행합니다.
...
메타초기화가 완료되면 리소스를 기동할 준비가 된 상태 입니다.
리소스 기동
bsradm up 명령을 통해 리소스를 기동할 수 있습니다. up 은 내부적으로 다음의 과정을 순차적으로 수행하여 리소스를 기동합니다.
...
| Info |
|---|
bsr 의 상태는 bsradm status 명령으로 조회할 수 있습니다. 이와 관련한 자세한 내용은 조회의 내용을 참고하세요. |
리소스 할당
리소스를 위한 메모리를 할당하고 초기화 합니다.
볼륨 적재
리소스에 구성된 볼륨을 복제볼륨으로 적재(attach)하고 메타디스크의 정보를 조회하여 로드하고 구성파일에 설정된 옵션들을 적용합니다. 볼륨의 적재는 별도의 attach 명령으로도 개별 수행할 수 있습니다.
복제 연결
적재된 볼륨을 피어노드의 리소스 볼륨과 연결합니다. 연결이 수립되면 복제 상태는 Established 가 되고 복제를 시작하기 위한 대기상태가 됩니다. 만일 피어 노드가 연결을 아직 준비하고 있지 않았다면 로컬의 리소스는 연결 시도 중(Connecting) 상태를 유지합니다. 복제 연결은 개별 connect 명령으로도 수행할 수 있습니다.
리소스 up 의 과정이 위 절차에 따라 순차적으로 모두 수행되었을 때 리소스 기동에 대한 성공으로 간주 합니다. 리소스 기동의 과정 중 일부 절차가 실패할 경우 리소스 기동이 중단될 수 있습니다. 이럴 경우 리소스의 상태를 확인하고 bsr 로그와 에러 메시지 등을 통해 문제를 파악할 수 있습니다.
승격
리소스는 Primary 또는 Secondary 역할을 가질 수 있습니다. Primary 역할의 리소스는 볼륨 장치에 제한 없이 접근하여 데이터를 읽고 쓸 수 있지만 Secondary 역할의 리소스는 사용자 계층으로부터의 볼륨장치로의 접근이 완전히 차단되고 Primary 로 부터 수신한 데이터만 장치에 반영하는 역할을 수행합니다.
...
| Code Block |
|---|
bsrdadm primary <resource> |
초기 동기화
리소스가 초기 기동된 상태에서는 디스크의 상태가 양 노드 Inconsistent 상태이며 이 상태는 기본적으로 디스크를 승격할 수 없는 상태 입니다. 따라서 리소스에 대한 최초 승격은 강제옵션으로 승격하고 강제승격 이후 자동적으로 초기 동기화로 이어집니다. 강제 승격은 다음과 같이 수행합니다.
...
| Info |
|---|
마운트 동작 관련 마운트 동작에 대한 Windows 와 Linux OS 간 차이가 있습니다. 리눅스에선 볼륨을 사용하기 위한 마운트 과정이 수동으로 요구되지만, 윈도우즈 환경에선 볼륨에 대한 마운트가 운영체제의 쉘 수준에서 자동으로 수행되기 때문에 별도의 마운트 명령 작업이 필요치 않습니다. 따라서 리눅스에선 승격 후 볼륨을 사용하기 위한 마운트 동작이 추가로 필요합니다. |
강등
Primary 역할에서 Secondary 역할로 전환하는 것을 강등이라고 합니다.
...
| Info | ||||
|---|---|---|---|---|
수동절체 수동 절체를 위한 절차는 다음과 같습니다.
|
리소스 중지
bsradm down 명령을 통해 리소스를 중지할 수 있습니다. down 은 리소스 앞서 설명한 up 과정의 역순에 따라 중지가 수행하고 만약 리소스가 승격된 상태 였다면 강등을 먼저 수행합니다. 즉 리소스 강등, 복제 단절, 볼륨 분리(detach), 리소스 해제의 순으로 down 합니다.
...
| Code Block |
|---|
bsradm down <resource> |
리소스 강등
리소스가 승격된 상태였다면 먼저 강등을 수행합니다.
복제 단절
복제 연결을 단절하여 복제를 중단합니다. 연결 단절은 disconnect 개별 명령으로도 수행할 수 있습니다.
만약 동기화나 복제가 진행 중일 때 복제 단절을 시도할 경우 단절은 일정 시간 동안 유예될 수 있습니다. 이것은 복제를 단절하는 명령이 로컬과 피어노드에게 모두 전달되는 명령이기 때문에 이미 복제를 위해 버퍼링된 데이터 양이 많을 경우 순차적처리 구조에 따라 명령전달이 지연될 수 있기 때문입니다. 이러한 지연을 무시하고 싶을 경우에는 --force 옵션을 통해 로컬에서 강제로 연결을 단절할 수도 있습니다. 강제로 단절하게 되면 연결을 빠르게 끊을 수는 있으나 복제나 동기화를 위한 계류중인 데이터들이 모두 버려지게 되므로 해당 데이터들에 대한 OOS(Out-Of-Sync) 가 발생할 수 있다는 점은 고려해야 합니다.
볼륨 분리
복제 볼륨으로 적재했던 볼륨을 분리하고 메타디스크에 관련 정보를 기록합니다. 분리(detach)는 개별 명령으로 수행할 수 있으나 Primary 리소스의 볼륨에 대한 분리는 허용되지 않습니다.
| Info |
|---|
bsr 에선 운영 중인 리소스의 볼륨 분리는 장애로 직결되기 때문에 위험한 동작으로 간주했으며 Primary 리소스의 볼륨 detach 를 코드 수준에서 차단하였습니다. 물론 Secodnary 리소스의 볼륨 분리는 허용합니다. |
리소스 해제
리소스를 위해 할당 했던 자원들을 해제합니다.
리소스 재구성
bsr 의 리소스 속성들은 기본적으로 운영 중(런타임) 설정 변경을 지원합니다. 이것을 동적 설정 (변경)이라고 합니다. 그러나 이러한 속성들 중 일부 필수 속성들은 동적 설정을 지원하지 않으며 구성파일의 설정을 변경한 후 리소스를 재기동하여 적용하는 정적 방식으로 재구성해야 합니다. 즉 정적 설정의 경우 리소스 재기동이 필요합니다.
동적 설정
구성파일을 변경하고 bsradm adjust 명령을 통해 실시간 변경합니다. 복제 프로토콜 변경 등 일부 특수 설정을 제외한 대부분의 속성은 이 방식으로 변경할 수 있습니다.
| Info |
|---|
복제 프로토콜 변경 운영 중 복제 프로토콜을 변경하기 위해서 프로토콜, 송신버퍼, 혼잡제어 설정을 같이 변경해야 합니다.
|
정적 설정
복제 구성을 위한 필수적인 설정(노드 ID, 볼륨 정보 등)의 변경이 필요할 경우 리소스 down 을 선행한 후 설정을 변경해야 합니다. 구성파일을 변경한 후 다시 up 하여 리소스가 재시작되는 시점에 변경된 설정이 반영됩니다.
전체 재구성
구성을 완전히 변경해야 하거나 디스크 장애등을 위한 복구가 필요한 경우 리소스 전체를 재 구성해야 합니다. 이 경우에는 먼저 운영 중인 리소스를 down 한 후 구성을 변경하고 메타 재 초기화를 수행하여 리소스를 재 기동해야 합니다.
...
메타 디스크를 초기화하면 볼륨에 대한 초기 동기화의 절차를 다시 수행해야 합니다.
볼륨 크기 조정
구성된 리소스의 볼륨은 운영상황에 따라 크기를 확장하거나 축소해야 할 경우가 생깁니다. 이를 위해서는 복제 볼륨의 크기를 조정하는 다음과 같은 별도의 방법을 사용해야 합니다. 볼륨 크기 조정은 플랫폼에 따라 차이가 있으며 온라인 볼륨 확장에 대해서 지원하고 볼륨 축소는 전체 재구성의 작업 절차를 따라야 합니다.
윈도우즈
윈도우즈에서 복제 운영 중 양노드의 볼륨 크기를 조정하기 위해선 먼저 복제 연결을 끊고 양 노드를 Primary 상태로 만들어야 합니다. Secondary 상태에선 볼륨이 락으로 잠겨있기 때문에 볼륨의 크기조정이 불가합니다. 양노드를 Primary 로 승격한 상태이므로 복제 클러스터는 스플릿브레인 상태가 되고, 볼륨의 크기를 조정하는 작업을 수행하고 나면 원래 Secondary 였던 노드를 강등한 후 Secondary 노드를 희생노드로 하여 스플릿 브레인을 해결합니다.
...
| Info |
|---|
볼륨의 크기가 커지는 만큼 메타디스크의 크기도 자동으로 늘어나는데(볼륨 확장시점에 bsr 내부적으로 처리합니다), 필요한 용량만큼 여유 분이 확보되어 있지 않다면 볼륨확장이 실패하게 됩니다. 따라서 온라인 볼륨 확장을 위해선 초기 리소스 구축과정에서 이를 염두에 두고 메타디스크 크기를 산정할 필요가 있습니다. |
리눅스
리눅스에서 온라인 볼륨 확장을 수행하려면 다음과 같은 조건을 충족해야 합니다.
...
볼륨의 늘어난 영역에 대한 새로운 동기화가 진행됩니다.
리소스 삭제
구성파일을 삭제 함으로써 리소스가 삭제됩니다. 보통 운영 중일 경우에는 다음의 절차를 통해 리소스를 삭제 합니다.
운영 중인 리소스를 down 합니다.
bsrcon /m 을 통해 볼륨에 걸려있는 락을 해제 합니다.
리소스 구성파일을 삭제 합니다.
조회
버전
bsradm /V 명령을 통해 bsr의 버전 정보를 확인합니다.
| Code Block |
|---|
[root@bsr-01 nglee]# bsradm -V BSRADM_BUILDTAG=GIT-hash:3dca67e82d331e95121288a57898fcda13357e94 build by nglee@NGLEE-1,2020-01-29 13:50:48 BSRADM_API_VERSION=2 BSR_KERNEL_VERSION_CODE=0x000000 BSR_KERNEL_VERSION=0.0.0 BSRADM_VERSION_CODE=0x010600 BSRADM_VERSION=1.6.0-PREALPHA3 |
상태정보
기본적인 상태 정보를 출력합니다.
| Code Block |
|---|
>bsradm status r0 r0 role:Secondary disk:UpToDate nina role:Secondary disk:UpToDate nino role:Secondary disk:UpToDate nono connection:Connecting |
...
| Info |
|---|
bsr은 Inconsistent 데이터와 Outdated 데이터를 구분합니다. Inconsistent 데이터란 어떤 식으로든 접근이 불가능하거나 사용할 수 없는 데이터를 말합니다. 대표적인 예로 동기화 진행 중인 타겟 쪽 데이터가 inconsistent 상태 입니다. 타겟 쪽 데이터는 동기화가 진행중일 때 일부는 최신이지만 일부는 지난 시점의 데이터 이므로 이를 하나의 시점인 데이터로 간주하는 것이 불가능합니다. 그런 경우에는 장치에 파일시스템이 있는 경우 그 파일시스템은 마운트(mount) 될 수 없거나 파일시스템 체크 조차도 수행되지 못하는 상태 일 수 있습니다. Outdated 데이터는 특정시점의 데이터 정합성은 보장되지만 프라이머리(Primary) 노드와 최신의 데이터로 동기화되지 않은 데이터 입니다. 이런 경우는 임시적이든 영구적이든 복제 링크가 중단할 경우 발생합니다. 연결이 끊어진 Oudated 데이터를 사용하는데 별 문제는 없지만 이것은 결국 지난 시점의 데이터 입니다. 이런 데이터에서 서비스가 되는 것을 막기 위해 bsr은 Outdated 데이터를 가진 리소스에 대한 승격을 기본적으로 허용하지 않습니다. 그러나 필요하다면(긴급한 상황에서) Outdated 데이터를 강제로 승격할 수는 있습니다. |
이벤트
다음과 같은 명령으로 실시간 이벤트 발생 상태를 확인할 수 있습니다. events2 명령은 '--statistics', '--timestamp' 옵션과 함께 사용할 수 있습니다.
| Info |
|---|
C:\Program Files\bsr\bin>bsrsetup events2 --now r0 |
동기화 속도 조정
동기화가 백그라운드에서 동작하면 타깃의 데이터는 일시적으로 불일치(Inconsistent)한 상태가 됩니다. 이러한 Inconsistent 상태는 가능한 짧게 유지해야 정합성 보장 측면에서 좋기 때문에 동기화 속도가 충분하게 설정되어 있어야 유리합니다. 그러나 복제와 동기화는 같은 네트워크 대역을 공유하고 있으며 만약 동기화 대역이 높게 설정된다면 상대적으로 복제 대역은 적게 부여될 수 밖에 없습니다. 복제 대역이 낮아지면 로컬의 I/O latency에 영향을 주게 되고 결과적으로 운영 서버의 로컬 I/O 성능 저하를 가져오게 됩니다. 복제든 동기화든 어느 한쪽이 일방적으로 대역을 많이 점유하면 상대적으로 다른 쪽 동작에 영향을 주게 되므로 bsr 은 복제 대역을 최대한 보장하면서 동기화 대역을 복제 상황에 따라 적당히 조절하는 가변대역 동기화를 구현하고 있으며 이를 기본 정책으로 사용합니다. 이와 반대로 고정대역 동기화 정책은 복제에 관계없이 동기화 대역을 항상 보장하는 방식으로 서버 운영 중에 사용할 경우 로컬 I/O 성능의 저하를 가져올 수 있으므로 일반적으로는 권장되지 않고 특수한 상황에서만 사용해야 합니다.
...
| Info |
|---|
대기노드의 최대 디스크 쓰기 속도 보다 높은 값으로 동기화 속도를 설정하는 것은 의미가 없습니다. 대기노드는 진행 중인 디바이스 동기화의 타깃이 되기 때문에 대기 노드가 허용하는 I/O 서브시스템의 쓰기 속도보다 동기화 속도가 더 빠를 수는 없습니다. 같은 이유로, 복제 네트워크에서 사용할 수 있는 대역폭보다 더 높은 값으로 동기화 속도를 설정하는 것도 의미가 없습니다. |
고정대역 동기화
백그라운드에서 수행되는 재동기화를 위해 사용되는 최대 대역폭은 리소스의 resync-rate 옵션에 따라 결정됩니다. 해당 옵션은 다음과 같이 /etc/bsr.conf 리소스 구성의 disk 섹션에 포함되어 있습니다.
...
| Info |
|---|
Important
|
가변대역 동기화
다중 리소스가 복제/동기화 네트워크를 공유하는 구성일 경우 고정대역 동기화는 최적의 방법이라 할 수 없습니다. 동일한 복제 네트워크를 공유하기 때문에 특정 복제 리소스 채널에 대해서 동기화율이 점유 당할 경우 다른 리소스들은 고정 동기화율이 보장되지 않게 됩니다. 이 경우, 가변대역 동기화를 통해 각각의 복제 채널의 동기화율을 동적으로 조정 하도록 구성하여 동기화율이 점유당하는 것을 완화시킬 수 있습니다. bsr은 이 모드에서 초기 동기화 속도를 결정한 후 자동 제어 루프 알고리즘을 통해 지속적으로 동기화 속도를 조정합니다. 이 알고리즘은 포그라운드 복제가 가능하도록 충분한 대역폭을 보장하며, 백그라운드 동기화가 포그라운드 I/O에 미치는 영향을 크게 완화시킵니다.
...
| Info |
|---|
동기화 속도 추정 아래와 같은 수식으로 동기화 시간을 추정할 수 있습니다. tresync = D/R
|
효율적인 동기화
bsr 에선 효율적인 동기화를 위해 체크섬 기반의 동기화, 운송동기화, 비트맵 제거 동기화 등 다양한 기능을 제공합니다.
체크섬 기반 동기화
체크섬 데이터 요약을 사용하면 bsr의 동기화 알고리즘의 효율성을 더욱 개선할 수 있습니다. 체크섬 기반 동기화는 동기화하기 전에 블록을 읽고 현재 디스크에 있는 내용의 해시(hash) 요약을 구한 다음, 상대 노드로부터 같은 섹터를 읽어 구한 해쉬 요약 내용과 비교합니다. 해시 내용이 일치하면 해당 블럭에 대한 동기화 쓰기(re-write)를 생략하고 일치하지 않을 경우 동기화 데이터를 전송합니다. 이 방식은 동기화 해야될 블럭을 단순히 덮어쓰는 기존 방식에 비해 성능에서 유리할 수 있으며 연결이 끊어져 있는(disconnect 상태) 동안 파일 시스템이 섹터에 같은 내용을 다시 썼다면 해당 섹터에 대해선 재동기화를 생략하게 되므로 전체적으로 동기화 시간을 단축시킬 수 있습니다.
운송 동기화
디스크를 직접 가져와서 구성하는 운송 동기화는 아래와 같은 상황에 적합합니다.
...
| Info |
|---|
비트맵 제거 동기화 Generates a new current UUID and rotates all other UUID values. This has at least two use cases, namely to skip the initial sync, and to reduce network bandwidth when starting in a single node configuration and then later (re-)integrating a remote site.Available option: --clear-bitmap Clears the sync bitmap in addition to generating a new current UUID. This can be used to skip the initial sync, if you want to start from scratch. This use-case does only work on "Just Created" meta data. Necessary steps:
One obvious side-effect is that the replica is full of old garbage (unless you made them identical using other means), so any online-verify is expected to find any number of out-of-sync blocks.You must not use this on pre-existing data! Even though it may appear to work at first glance, once you switch to the other node, your data is toast, as it never got replicated. So do not leave out the mkfs (or equivalent).This can also be used to shorten the initial resync of a cluster where the second node is added after the first node is gone into production, by means of disk shipping. This use-case works on disconnected devices only, the device may be in primary or secondary role.The necessary steps on the current active server are:
Now add the disk to the new secondary node, and join it to the cluster. You will get a resync of that parts that were changed since the first call to bsrsetup in step 1. |
혼잡 모드
| Info |
|---|
비동기 방식 복제에서 만 사용합니다. |
복제 대역폭이 가변적인 환경(WAN 복제 환경)에서는 때때로 복제 링크가 정체 될 수 있습니다. 이로 인해 Primary 노드의 I/O가 대기하게 되면 로컬 I/O의 성능저하가 발생하기 때문에 바람직하지 않습니다. 이러한 혼잡 상황을 감지할 경우 진행 중인 복제를 일시 중단하도록 구성할 수 있습니다. 대신 이렇게 복제가 중단되는 상황에서는 Primary 측의 데이터 세트가 Secondary의 데이터보다 앞선 상태(Ahead)가 되고 이 앞서간 데이터 블럭들은 OOS(Out-Of-Sync) 로 기록하여 혼잡이 해제되면 이미 기록한 OOS를 백그라운드 재동기화를 통해 해소합니다. 다음은 혼잡 정책을 설정하는 예 입니다.
...
복제 가속기(DRX)를 연동하는 경우 DRX 버퍼 크기의 약 90% 로 설정합니다.
DRX를 연동하지 않을 경우엔 sndbuf-size 의 90% 크기로 설정합니다
congestion-extents의 권장 값은 al-extents 설정값의 90%입니다.
디스크 플러시
복제 중 타깃 노드가 전원장애로 인해 갑자기 다운된다면 디스크 캐쉬 영역이 배터리 백업 장치(BBWC)에 의해 백업되어 있지 않을 경우 데이터 유실이 발생할 수 있습니다. 복제에선 이를 미연에 방지하기 위해 데이터를 타깃의 디스크에 쓰는 과정에서 데이터를 미디어에 기록하고 난 후 flush 동작을 항상 수행하여 데이터 유실을 예방 합니다.
...
배터리 백업 쓰기 캐시 (BBWC)가있는 장치에서 bsr을 실행할 때만 장치 플러시를 비활성화해야합니다. 대부분의 스토리지 컨트롤러는 배터리가 소진되면 쓰기 캐시를 자동으로 비활성화하고 배터리가 소진되면 쓰기(write through) 모드로 전환합니다.
정합성 검증
정합성 검증은 복제를 수행하는 과정에서 복제 트래픽을 블럭 단위로 실시간 수행하거나 전체 디스크 볼륨 단위로 소스와 타깃의 데이터가 완전히 일치하는지 해쉬 요약을 기반으로 블럭단위로 비교하는 기능입니다.
트래픽 검사
bsr 은 암호화 메시지 요약 알고리즘을 사용하여 양 노드 간의 메시지 정합성을 검증할 수 있습니다. 이 기능을 사용하게 되면 bsr 은 모든 데이터 블록의 메시지 요약본을 생성하고 그것을 상대 노드에게 전달한 후 상대편 노드에서 복제 패킷의 정합성을 확인합니다. 만약 요약된 블럭이 서로 일치하지 않으면 재전송을 요청합니다.
...
양 노드의 리소스 구성을 똑같이 변경한 후, 양 노드에서 bsradm adjust <resource>를 실행하여 변경사항을 적용시킵니다.
온라인 정합성 검사
온라인 정합성 검사는 장치 운영 중에 노드 간의 블록별 데이터의 정합성을 확인하는 기능입니다. 정합성 검사는 네트워크 대역폭을 효율적으로 사용하고 중복된 검사를 하지 않습니다.
...
보통 온라인 정합성 검사에 따른 작업은 OS에서 예약된 작업으로 등록하여 운영 I/O 부하가 적은 시간 대에 주기적으로 수행하는 것이 일반적인 사용법입니다.
활성화
온라인 정합성 검사는 기본적으로 비활성화되어 있는데, bsr.conf 내의 리소스 구성에 다음과 같은 내용을 추가하면 활성화할 수 있습니다.
...
온라인 검증을 활성화 하기 위해 양 노드의 리소스 구성을 똑같이 변경한 후, 양 노드에서 bsradm adjust <resource>를 실행하여 변경사항을 적용시킵니다.
온라인 정합성 검사 실행
온라인 정합성 검사를 활성화한 후, 다음 명령을 사용하여 검사를 실행할 수 있습니다.
...
| Code Block |
|---|
drbdadm disconnect <resource> drbdadm connect <resource> |
자동 검사
정기적으로 정합성 검사를 할 필요가 있다면, 다음과 같은 방법으로 bsradm verify <resource> 명령을 작업 스케줄러에 등록합니다.
...