| 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. |
...
초기 동기화(강제 승격)의 절차를 다시 수행합니다.
구성된 리소스의 볼륨은 운영상황에 따라 크기를 확장하거나 축소해야 할 수 있습니다. 이를 위해서 복제
| Note |
|---|
구성 해제 시 주의할 점 운영하던 운영 노드의 볼륨을 다시 소스로 하여 재구성하게 될 경우라면 소스 였던 소스였던 볼륨을 그대로 사용하면 되므로 별 다르게 주의할 점은 없습니다. 그러나 타깃 볼륨 측을 측 볼륨을 소스로 재구성해야 할 경우에는 구성을 해제하기 전에 반드시 다음의 절차를 과정을 통해 반드시 타깃이 최신 데이터가 확보될 수 있도록 해야 합니다.
예를 들어, 타깃의 disk 상태가 UpToDate 라 하더라도 복제 연결이 해제된 상태일 경우에는 최신 데이터가 아닐 수 있다는 점을 간과 해선 안됩니다. (소스 측에 OOS 가 있으면 타깃은 예전 데이터 입니다.) 구성을 해제하기 전 위의 과정을 통해 최신 데이터를 가진 볼륨을 반드시 확보해야 합니다. |
볼륨 크기 조정
볼륨 크기 조정
구성된 리소스의 볼륨은 운영상황에 따라 크기를 확장하거나 축소해야 할 수 있습니다. 이를 위해서 복제 볼륨의 크기를 조정하는 다음과 같은 절차를 수행해야 합니다. 크기 조정은 플랫폼에 따라 차이가 있으며 볼륨 확장은 서비스 운영 중에 가능하지만 볼륨 축소는 운영중에는 안되고 서비스 리소스 오프라인 후 전체 재구성을 통해서 해야 재구성 과정을 거쳐야 합니다.
윈도우즈
윈도우즈에서 복제 운영 중 양노드의 다음의 순서로 볼륨 크기를 조정하기 위해선 먼저 조정합니다.
복제 연결을 끊고(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의 버전 정보를 확인합니다.
...
혼잡이 감지 되면 복제는 일시 중단되고 로컬의 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 해결로 처리합니다. |