...
Code Block |
---|
>bsradm create-md r0 initializing activity log NOT initializing bitmap Writing meta data... New drbdbsr meta data block successfully created. |
...
Info |
---|
복제 프로토콜 변경 운영 중 복제 프로토콜을 변경하기 위해서 프로토콜, 송신버퍼, 혼잡제어 설정을 같이 변경해야 합니다.
|
...
운영 노드를 Primary 상태로 두고 양 노드의 볼륨의 크기를 LVM을 통해 늘린 후 한 노드에서 다음과 같은 명령을 내려서 새롭게 늘어난 크기를 bsr 에 인식시킵니다.
Code Block |
---|
drbdadmbsradm resize <resource> |
볼륨의 늘어난 영역에 대한 새로운 동기화가 진행됩니다.
...
Info |
---|
성능지시자
|
...
Info |
---|
연결상태
|
Info |
---|
복제상태
|
...
Code Block |
---|
C:\Program Files\drbd>drbdadmbsr>bsradm role r0 Primary/Secondary |
...
Code Block |
---|
C:\Program Files\drbd>drbdadmbsr>bsradm dstate r0 UpToDate/UpToDate |
...
Diskless. 로컬 블록 디바이스가 BSR 드라이버에 할당되지 않은 상태입니다. 리소스가 백업 디바이스에 적재된 적이 없거나, drbdadm bsradm detach <resource> 명령으로 수동 분리되었거나, lower-level I/O 오류 후에 자동으로 분리된 경우 이 상태가 됩니다.
Attaching. 메타 데이터를 읽는 동안의 일시적인 상태입니다.
Failed. 로컬 블록 디바이스의 I/O 실패 보고에 따른 일시적인 상태입니다. 다음 상태는 Diskless 입니다.
Negotiating. 이미 연결된 디바이스에서 Attach 가 실행되었을 때 일시적으로 이 상태가 됩니다.
Inconsistent. 데이터가 불일치한 상태입니다. 새로운 리소스를 구성했을 경우 양 노드의 디스크는 이 상태가 됩니다. 또는 동기화 중인 타겟 노드의 디스크 상태입니다.
Outdated. 리소스의 데이터가 일치하지만, 최신 데이터는 아닌 상태입니다.
DUnknown. 네트워크 연결을 사용할 수 없는 경우, 원격 디스크의 상태를 표시하기 위해 사용됩니다.
Consistent. 노드가 연결되는 과정에서 데이터는 일치한 상태로 간주된 일시적 상태입니다. 연결이 완료되면, UpToDate 인지 Outdated 인지 결정됩니다.
UpToDate. 데이터 정합성이 일치하고 최신의 상태입니다. 복제 중의 일반적인 상태입니다.
...
다음과 같은 명령으로 실시간 이벤트 발생 상태를 확인할 수 있습니다. events2 명령은 '--statistics', '--timestamp' 옵션과 함께 사용할 수 있습니다.
Info |
---|
C:\Program Files\drbdbsr\bin>drbdsetup bin>bsrsetup events2 --now r0 |
...
백그라운드에서 수행되는 재동기화를 위해 사용되는 최대 대역폭은 리소스의 resync-rate 옵션에 따라 결정됩니다. 해당 옵션은 다음과 같이 /etc/drbdbsr.conf 리소스 구성의 disk 섹션에 포함되어 있습니다.
...
체크섬 데이터 요약을 사용하면 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에서 다뤄지는 영역에 따라 간단한 동기화가 있을 수 있습니다.
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 |
---|
비동기 방식 복제에서 만 사용합니다. |
...