| Table of Contents | ||||
|---|---|---|---|---|
|
...
리소스 생성은 앞 절에서 설명한 리소스 구성파일을 구성항목에 맞게 준비하고 메타를 초기화하면 리소스가 생성된 것으로 간주합니다.
메타 초기화
구성파일을 작성하고 메타디스크를 초기화 하면 리소스가 생성된 것으로 간주합니다. 메타 디스크의 초기화는 리소스를 생성하기 위해 다음의 명령으로 메타 초기화를 수행합니다.
| Code Block |
|---|
>bsradm create-md r0 initializing activity log NOT initializing bitmap Writing meta data... New bsr meta data block successfully created. |
...
리소스를 위해 할당 했던 메모리 자원들을 해제합니다.
...
속성 설정
동적 설정
bsr 의 리소스 속성들은 기본적으로 운영 중 (런타임) 설정 변경을 지원하며 이것을 동적 설정 이라고 합니다. 하지만 속성들 중 일부 필수 속성들은 동적 설정을 지원하지 않으며 구성파일의 설정을 변경한 후 리소스를 재기동하여 적용하는 정적 방식으로 재구성해야 합니다.
동적 설정
구성파일을 변경하고 지원합니다. 구성파일을 변경해서 bsradm adjust 명령을 통해 실시간 변경합니다. 복제 프로토콜 변경 등 일부 특수 설정을 제외한 대부분의 속성은 이 방식으로 설정을 즉시 변경할 수 있습니다. 복제 프로토콜을 운영 중 변경하기 위해선 다음의 내용을 참고하세요.
| Info |
|---|
운영 중 복제 프로토콜 변경 프로토콜, 송신버퍼, 혼잡제어 설정을 다 같이 변경해야 합니다.
|
정적 설정
복제 구성을 위한 필수적인 필수 설정(노드 ID, 볼륨 정보 등)의 변경이 필요할 경우 리소스 down 을 선행한 후 구성파일을 변경합니다. 다시 up 하여 리소스가 재시작되는 시점에 변경된 설정이 반영됩니다.들에 대해선 동적 설정을 지원하지 않습니다. 구성파일의 설정을 변경한 후 리소스를 재 기동하여 적용해야 합니다.
리소스 재구성
전체 재구성
디스크 파손 등 장애 복구가 필요하거나 필요에 따라 구성을 완전히 변경해야
...
하는 경우 리소스 전체를
...
재구성해야 합니다.
...
먼저 운영 중인 리소스를 down 한 후 구성을 변경하고 구성파일을 변경합니다.
메타 재 초기화를 수행하여 하고 리소스를 재 기동해야 재기동 합니다.
| Info |
|---|
Windows 의 경우 전체 재구성 과정에서 볼륨에 걸려있는 락을 해제해야 할 경우가 필요가 있습니다. 이럴 때에 bsrcon 유틸리티의 bsrcon의 /release_vol 옵션을 사용하여 볼륨락을 해제할 수 있습니다. |
메타 디스크를 초기화하면 볼륨에 대한 초기 동기화의 절차를 다시 수행해야 합니다.
볼륨 크기 조정
...
초기 동기화(강제 승격)의 절차를 다시 수행합니다.
| Note |
|---|
구성 해제 시 주의할 점 운영 노드의 볼륨을 다시 소스로 하여 재구성하게 될 경우라면 소스였던 볼륨을 그대로 사용하면 되므로 별 다르게 주의할 점은 없습니다. 그러나 타깃 측 볼륨을 소스로 재구성해야 할 경우에는 구성을 해제하기 전에 반드시 다음의 과정을 통해 타깃이 최신 데이터가 확보될 수 있도록 해야 합니다.
|
볼륨 크기 조정
구성된 리소스의 볼륨은 운영상황에 따라 크기를 확장하거나 축소해야 할 수 있습니다. 이를 위해서 복제 볼륨의 크기를 조정하는 다음과 같은 절차를 수행해야 합니다. 크기 조정은 플랫폼에 따라 차이가 있으며 볼륨 확장은 서비스 운영 중에 가능하지만 볼륨 축소는 운영중에는 안되고 서비스 오프라인 리소스 오프라인 후 전체 재구성을 통해서 해야 재구성 과정을 거쳐야 합니다.
윈도우즈
윈도우즈에서 복제 운영 중 양노드의 다음의 순서로 볼륨 크기를 조정하기 위해선 먼저 조정합니다.
복제 연결을 끊고(disconnect) 양 노드를 Primary 상태로
...
만듭니다(Secondary 상태에선 볼륨이
...
잠겨있기 때문에
...
크기조정을 할 수 없습니다).
양 노드를 Primary 로 승격하면 복제 클러스터는 스플릿브레인 상태가
...
됩니다.
양 측 볼륨의 크기를 확장합니다.
원래 Secondary 였던 노드를
...
강등합니다.
Secondary 노드를 희생노드로 하여 스플릿 브레인을 해결합니다.
이렇게 하면 전체 복제 볼륨의 크기가 늘어나고 새롭게 늘어난 크기의 볼륨 영역만큼 소스 기준으로 동기화가 되어 온라인 중 볼륨 확장이 가능해 집니다. 진행됩니다.
| Note |
|---|
|
...
|
...
|
리눅스
리눅스에서 온라인 볼륨 확장을 수행하려면 bsr의 블럭장치가 LVM 과 같은 볼륨 관리자와 함께 구성되어 있어야 하며 소스와 타깃 노드는 복제 연결상태를 Connected 상태로 유지해야 합니다.
...
운영 중인 리소스를 down 합니다.
리소스 구성파일을 삭제 합니다.
Windows 의 경우 bsrcon /release_vol 을 통해 복제 볼륨에서 제외하고 볼륨락을 해제합니다.
wipe-md 명령으로 메타를 완전히 지웁니다. (bsr 1.7 이후로 wipe-md 는 /release_vol 명령 시점에 자동 수행됩니다. 이는 사용자 오류 방지를 위한 조치 입니다.)수행합니다.)
조회
버전
bsradm /V 명령을 통해 bsr의 버전 정보를 확인합니다.
...
상세 정보를 출력합니다.
| Code Block |
|---|
C:\Users\>bsrsetupAdministrator>bsrsetup status r0 --verbose --statistic r0 node-id:0 role:SecondaryPrimary suspended:no write-ordering:drain req-pending:0 volume:0 minor:2 disk:InconsistentUpToDate size:409600010467328 read:029847120 written:03029330 al-writes:0260 bm-writes:0 upper-pending:0 lower-pending:0 lower-pending:0 al-suspended:no al-pending-changes:0 al-used:0 accelbuf-used:0 blocked:no WIN2012R2_2D3W2K22BSRAG-002 node-id:1 connection:ConnectedConnecting error: role:SecondaryUnknown congested:no volume:0 replication:EstablishedOff peer-disk:Inconsistent DUnknown resync-suspended:no received:0 sent:011803912 out-of-sync:0329892 pending:0 unacked:0 |
성능지시자
...
D3W2K22BSRAG-003 node-id:2 connection:Connected role:Secondary congested:no
volume:0 replication:Established peer-disk:UpToDate resync-suspended:no
received:0 sent:16247308 out-of-sync:0 pending:0 unacked:0 |
성능지시자
sent (network send). 네트워크 연결을 통해 상대 노드에 전송된 네트워크 데이터의 양입니다. (Kibyte)
received (network receive). 네트워크 연결을 통해 상대 노드에서 수신된 네트워크 데이터의 양입니다. (Kibyte)
written (disk write). 로컬 하드 디스크에 기록된 넷 데이터입니다. (Kibyte)
read (disk read). 로컬 하드 디스크로부터 읽은 넷 데이터입니다. (Kibyte)
al-writes (activity log). 메타 데이터의 activity log 영역에 대한 업데이트 횟수입니다.
bm-writes (bit map). 메타 데이터의 비트맵 영역에 대한 업데이트 횟수입니다.
upper-pending (application pending I/O ). 상위에서 bsr 로 전달된 I/O 들 중 완료되지 못하고 bsr에서 처리중인 I/O 개수 .
lower-pending (subsystem open count). bsr에서 수행한 로컬 I/O sub-system에 대한 (close 되지 않은) open 횟수.
pending. 상대 노드에게 요청하였지만 응답(ack)받지 못한 요청 횟수입니다.
unacked (unacknowledged). 상대 노드에서 요청을 받았지만 응답(ack)해 주지 않은 요청 횟수입니다.
write-ordering (write order). 현재 사용하는 디스크 쓰기 방식을 나타냅니다.
out-of-sync. 현재 동기화가 이루어지지 않은 스토리지의 양을 나타냅니다. (Kibytes)
resync-suspended. 재 동기화 중단 여부. 가능한 값 은 no,user, peer, dependency
blocked. 로컬 I/O 혼잡상태 표시
no: 혼잡없음
upper: 상위 디바이스에서 혼잡발생
lower: 디스크 혼잡
congested. 이 플래그는 복제 연결상의 TCP 송신 버퍼가 80 % 이상 채워 졌는지 여부를 알려줍니다.
yes: 네트웍 혼잡
no: 혼잡없음
...
bsr은 디스크 전체 영역을 대상으로 수행하는 기존 전체 동기화 방식을 파일시스템이 사용하는 영역에 대해서만 동기화하는 빠른 동기화(FastSync)로 를 기본 동작으로 변경하였습니다. 예를 들어 1TB 디스크에서 100MB 만 사용하고 있다면 100MB 디스크 영역에 대해서만 동기화 하므로 기존 전체 동기화(1TB)에 비해 10배 빠르게 초기동기화를 마칠 수 있습니다. FastSync 는 다음과 같은 다음 시점에 기본 동작합니다.
초기 전체 동기화(bsradm primary --force)
수동 전체 동기화(invalidate/invalidate-remote)
정합성 검사(bsradm verify)
| Note |
|---|
주의할 점! FastSync 는 초기 동기화를 수행하기 전 시점에 디스크 공간에서 파일시스템이 사용하는 전에 파일시스템 정보를 우선 얻어야 하는데, 파일시스템이 훼손(깨짐)되어 있다면 사용영역에 사용 영역에 대한 정보를 부정확하게 처리할 수 있습니다. 이를 인식하지 못하고 FastSync 가 처리될 경우 소스와 타깃의 정합성이 불일치하는 결과를 낳게 불일치하게 되므로 매우 조심해야 합니다. 따라서 bsr 에선 이런 상황에 대비하기 위해 bsradm primary --force 를 통해 초기 동기화를 수행하기에 앞서 파일시스템 무결성 검사를 먼저 의뢰하고(chkdsk or fsck) 그 결과에 문제가 없을 때 FastSync 가 동작하도록 합니다. 관리자는 bsr 초기동기화를 수행하기 전 파일시스템 무결성 검사를 수행하여 복제 디스크의 health 상태를 미리 파악해 둘 필요가 있습니다. |
| Info |
|---|
FastSync 를 비활성화 하고 예전 FullSync 방식으로 변경 하려면방식을 사용하려면 다음의 명령을 수행합니다.
현재 초기 동기화 방식을 알고 싶을 때방식이 FastSync 인지 FullSync 인지 확인하려면 다음의 명령을 수행합니다.
|
체크섬 기반 동기화
체크섬 데이터 요약을 사용하면 bsr의 동기화 알고리즘의 효율성을 더욱 개선할 수 있습니다. 체크섬 기반 동기화는 동기화하기 전에 블록을 읽고 현재 디스크에 있는 내용의 해시(hash) 요약을 구한 다음, 상대 노드로부터 같은 섹터를 읽어 구한 해쉬 요약 내용과 비교합니다. 해시 내용이 일치하면 해당 블럭에 대한 동기화 쓰기(re-write)를 생략하고 일치하지 않을 경우 동기화 데이터를 전송합니다. 이 방식은 동기화 해야될 블럭을 단순히 덮어쓰는 기존 방식에 비해 성능에서 유리할 수 있으며 연결이 끊어져 있는(disconnect 상태) 동안 파일 시스템이 섹터에 같은 내용을 다시 썼다면 해당 섹터에 대해선 재동기화를 생략하게 되므로 전체적으로 동기화 시간을 단축시킬 수 있습니다.
체크섬 기반 동기화는 기본적으로 비활성화 되어 있습니다. 이 기능을 사용하려면 양 노드의 리소스 구성에 다음 줄을 추가합니다.
resource <resource>
net {
csums-alg <algorithm>;
}
...
}
<algorithm>은 시스템 커널 구성에서 커널 암호화 API가 지원하는 메시지 다이제스트 알고리즘입니다. 일반적으로 SHA1, MD5, CRC32C 중에서 선택할 수 있으며 Windows 는 CRC32 를 지원합니다.
운송 동기화
디스크를 직접 가져와서 구성하는 운송 동기화는 아래와 같은 상황에 적합합니다.
...
| Info |
|---|
동기화 속도 추정 아래와 같은 수식으로 동기화 시간을 추정할 수 있습니다. tresync = D/R
|
| Note |
|---|
동기화 |
...
대역 설정 |
...
동기화 대역을 복제 대역에 대한 비율로 설정할 수도 있습니다.
| Code Block |
|---|
| resource <resource> {
disk {
c-min-rate 40M;
예 100Mbps 대역에서 5개 복제 리소스를 운영할 경우,
resource { resync-rate 128KB; c-min-rate 128KB; c-max-rate 1MB; } |
동기화 비율 설정
동기화 대역을 복제 대역에 대한 비율로 설정할 수도 있습니다.
| Code Block |
|---|
resource <resource> {
disk {
c-min-rate 40M;
resync-ratio "3:1";
...
}
...
} |
...
혼잡이 감지 되면 복제는 일시 중단되고 로컬의 I/O를 OOS 로 기록하면서 버퍼링 된 데이터를 서서히 타깃으로 전송합니다. 이 과정에서 Primary 는 Secondary 에 비해 앞선(Ahead) 데이터 상태이며 버퍼링 되었던 데이터를 다 전송하고 나면 자동으로 동기화 모드로 전환하여 복제 되지 못한 OOS 영역을 동기화 합니다.
혼잡 모드는 설정에 따라 다음과 같이 동작합니다.다음의 3 가지 모드가 있습니다.
Blocking 모드
아무 설정도 하지 않을 경우 기본적으로 Blocking 모드입니다. Blocking 모드에서는 TX 송신버퍼에 복제 데이터를 전송할 여유 공간이 생길 때 까지 대기(Blocking)합니다.
disconnect 모드
복제 연결을 단절하여 로컬 I/O 부하를 일시적으로 해소하도록 disconnect 모드로 설정할 수 있습니다.
Ahead 모드
복제 연결은 유지한 채 primary 노드의 I/O를 로컬 디스크에 우선 기록해 두었다가(해당 영역은 out-of-sync로 기록) 혼잡 해제 후 재동기화를 자동으로 수행하는 pull-ahead 모드로 설정할 수 있습니다. Ahead 상태가 된 Primary 노드는 Secondary 노드에 비해 앞서 있는(Ahead) 데이터 상태가 됩니다. 그리고 이 시점에 Secondary는 뒤 쳐진(Behind) 예전 데이터
이지만 쓸 수는 있는 가용 상태입니다. 혼잡이 해제되면, 세컨더리로의 복제는
자동 재개되고 Ahead 상태에서 복제되지 못했던 out-of-sync 블럭에 대해 백그라운드 동기화를
이어서 수행합니다. 혼잡모드는 일반적으로 데이터센터 또는 클라우드 인스턴스간의 광역 복제 환경과 같은 가변 대역폭을 가진 네크워크 링크 환경에서 유용합니다.
다음은 혼잡 정책을 설정하는 예 입니다.
리소스 구성파일에 on-congestion 옵션 항목으로 혼잡모드를 설정하고, congestion-fill 항목으로 혼잡 감지 임계치를 설정합니다.
...
congestion-fill은 sndbuf-size 크기의 약 90% 로 설정합니다. 복제 가속기(DRX)를 연동하는 경우 DRX 버퍼의 90% 로 설정합니다.
단, 버퍼의 크기가 10GB 이상 수준으로 크게 할당될 경우 90% 수준의 임계치가 혼잡을 감지하기에는 과도하게 큰 값일 수 있으므로 이는 튜닝을 통해 적정 수치로 조정할 필요가 있습니다.
congestion-extents의 권장 값은 al-extents 설정값의 90%입니다.
congestion-highwater 는 패킷 개수 기반으로 혼잡을 감지하는 기능입니다. 특히 용량 기반으로 복제 혼잡을 감지하기에 적합하지 않은 DR 환경에서 사용하기에 적당합니다. 기본값 20000 으로 설정되어 있으며 기본 활성화 됩니다. 0으로 설정시 비활성화 되며 최대값은 1000000 입니다.
| Info |
|---|
송신버퍼(sndbuf)와 DRX 버퍼 bsr 에 설정하는 송신버퍼(sndbuf) 는 커널 메모리에서 직접 할당하기 때문에 크게 할당하기 어렵습니다. 시스템에 따라 차이는 있지만 보통 1GB 내에서 크기를 지정하는 것으로 제한할 필요가 있습니다. 그렇지 않을 경우 송신버퍼 할당으로 인해 시스템 커널 메모리가 부족해지면 시스템 동작과 성능에 영향을 줄 수 있습니다. 따라서 대용량 버퍼를 구성해야 할 경우는 DRX 버퍼로 구성할 것을 권장합니다. |
디스크 플러시
복제 중 타깃 노드가 전원장애로 인해 갑자기 다운된다면 디스크 캐쉬 영역이 배터리 백업 장치(BBWC)에 의해 백업되어 있지 않을 경우 데이터 유실이 발생할 수 있습니다. 복제에선 이를 미연에 방지하기 위해 데이터를 타깃의 디스크에 쓰는 과정에서 데이터를 미디어에 기록하고 난 후 flush 동작을 항상 수행하여 데이터 유실을 예방 합니다.
...
|
역할 유지
리소스 역할은 운영 상황에 따라 변경될 수 있지만, 때로는 역할을 지속해서 운영하는 방식이 필요할 수 있습니다. (BSR 1.7.3 이상)
persist-role 이 설정된 리소스는 재 시작 되는 시점에 명시적으로(bsradm 명령으로) 지정된 리소스 역할을 계속 유지합니다. 복제 서비스 또는 시스템이 리부팅되어 리소스가 재 시작되는 모든 상황에서 동작합니다.
| Code Block |
|---|
resource <resource> {
options {
persist-role yes;
}
...
} |
단방향 복제
전환(swtichover)이나 절체(failover)없이 항상 주 노드에서 대기노드로의 단방향 복제만 하고 싶다면 대기 노드 측의 타깃 전용(target-only) 속성을 고려하십시오. (BSR 1.7.3 이상)
위에서 설명한 persist-role 속성을 리소스 options 섹션에 설정하여 주 노드와 대기노드의 역할(role)을 고정합니다.
target-only 속성을 대기 노드 측에 설정하여 복제/동기화 방향을 주 노드에서 대기노드 한 쪽 방향으로만 강제합니다.
타깃 전용 노드는 명시적인 명령을 포함한 모든 복제/동기화 동작에서의 소스 역할이 금지되고 타깃 역할만 가질 수 있습니다. 그리고 소스 역할로 동작하는 수동 동기화나 승격 명령 등은 모두 차단됩니다(단, 연결 해제 시 승격 허용됨).
| Code Block |
|---|
resource <resource> {
options {
persist-role yes;
}
on active {
...
}
on standby-DR {
...
options {
target-only yes;
...
}
}
...
} |
| Info |
|---|
타깃 전용 노드의 데이터 확인 복제 연결을 해제한 후 승격을 통해 데이터를 확인할 수 있습니다. 데이터 확인을 위해 승격을 한 시점에는 SB가 발생한 상태이므로 복제를 다시 정상화하려면 다시 강등 후 SB 해결로 처리합니다. |