Table of Contents |
---|
...
리소스를 승격하기 위한 명령은 다음과 같습니다.
fsradm primary [리소스명]
Info |
---|
리소스의 역할을 primary 로 전환하는 것을 승격, 역할을 secondary 로 전환하는 것을 강등이라고 합니다. |
초기 동기화 시점의 로컬 파일은 양노드 정합성이 맞지 않은 Inconsistent 상태를 초기값으로 하기 때문에 기본적으로 승격이 거부됩니다. 초기 승격 시에는 강제(-f 옵션) 승격을 통해 사용자가 해당 리소스를 소스로 하겠다고 명시적으로 알려야 합니다.
...
Info |
---|
Invalidate 명령은 comparison_level 1(sync-by-hash-comp(속성, 해쉬 비교 동기화))을 기본 동작모드로 합니다. 동작 모드는 Invalidate 명령의 옵션으로 조정할 수 있습니다. |
대역 설정
Code Block |
---|
{
...
"network": {
"sync_ratio" : "7:3",
"sync_min" : 100M,
"sync_max" : 1G
}
} |
복제 네트워크의 복제, 동기화 대역폭을 사전에 조율하고 적절한 수치 또는 비율로 구성해야 합니다. 복제와 동기화의 비율은 보통 7:3(복제 7, 동기화 3)의 비율을 기본으로 복제 네트워크의 복제, 동기화 대역폭을 사전에 조율하고 적절한 수치 또는 비율로 구성해야 합니다. 복제와 동기화의 비율은 보통 7:3(복제 7, 동기화 3)의 비율을 기본으로 하여 네트워크 상황에 맞게 조정하면 됩니다. 되도록 복제에 많은 비중을 두는 게 로컬 I/O 성능에 좋습니다.
sync_min 과 sync_max 사이에서 동기화 대역을 설정할 수 있으며 sync_min 은 최소한 도의 보장 동기화 대역으로 지정됩니다. 단위는 byte/s 입니다.
복제 시작
...
Code Block |
---|
{
...
"network": {
"sync_ratio" : "7:3",
"sync_min" : 100M,
"sync_max" : 1G
}
} |
복제 시작
Secondary 노드가 승격되어 동기화가 시작됨과 함께 소스노드의 데이터에 실시간 변경분이 발생할 경우 변경분에 대한 반영을 자동으로 병행합니다. 복제는 로컬 데이터의 실시간 변경 분을 타깃으로 실시간 반영하는 동작으로 정의 되며 Primary 노드에서 Secondary 노드의 방향으로 진행됩니다.
...
Info | ||
---|---|---|
| ||
고아파일은 누락파일과 달리 타깃의 복제 경로에 연고없이 남겨진 파일로 정의합니다. 이것은 일반적인 복제 상황에선 발생하지 않지만 타깃의 파일이 보호되지 않는 상황에서 의도치 않은 파일 조작이 있을 경우에 발생합니다. 고아파일이 발생하면 FSR 의 고아파일 대응 정책에 따라 처리가 되고 기본적으로 타깃의 특정 경로에 백업하는 것으로 처리됩니다. 백업 필요없이 바로 삭제 처리하도록 옵션을 지정할 수도 있습니다. |
전환
전환(switch-over)은 복제 클러스터 내의 하나의 시스템에서 다른 시스템으로 자원에 대한 액세스를 수동 교환하는 동작입니다. 소스 노드를 강등시킨 후 타깃노드를 소스노드 역할로 승격하여 서비스를 위한 데이터를 활성화하는 과정입니다. 수동절체 라고도 하며 이와 반대로 장애에 자동 대응하는 개념으로 장애조치(fail-over)가 있습니다.
소스노드의 리소스를 강등합니다.
Code Block |
---|
c:\>fsradm secondary r0
done |
타깃노드의 리소스를 승격합니다.
Code Block |
---|
c:\>fsradm primary r0
done |
Info |
---|
고려사항 전환/절체 시 타깃노드의 리소스 파일상태는 UpToDate 최신 상태일 때 복제 정합성을 보장합니다. 만약 복제 연결이 단절되어 타깃이 최신 데이터를 가지지 못한 경우 이거나 타깃노드의 리소스가 동기화 중인 Inconsistent 상태일 경우에는 소스와 정합하지 않은 상태이므로 전환/절체를 제한해야 합니다. |
파일잠금
타깃에 복제된 파일들은 소스로부터 수신하는 미러링 데이터 이외의 다른 쓰기 I/O 로 부터 보호되어야 합니다. 그렇지 않으면 복제 사본을 유지하기 위한 데이터 일관성을 보장할 수 없습니다. 특히 HA를 운영하는 경우 절체의 과정 중 대기노드의 데이터 일관성 보장을 위해 파일 잠금 기능을 반드시 활성화 시켜서 운영해야 합니다.
파일잠금은 리소스의 nodes 섹션내의 auto_file_lock 옵션을 통해 리소스의 역할에 따라 자동으로 설정되게 하거나 fsradm lock 또는 unlock 명령을 통해 수동으로 활성화,비활성화 할 수 있습니다.
자동 잠금
auto_file_lock 옵션은 기본 활성화되어 있습니다. 리소스의 역할이 강등된다면 파일들은 기본적으로 잠겨진 상태가 됩니다. 잠겨진 파일들을 해제하려면 리소스의 역할을 승격하거나 unlock 명령을 통해 잠금을 해제해야 합니다.
강등 시 잠금은 자동이지만 해제는 자동이 아닙니다.
수동 잠금
auto_file_lock 옵션을 비활성화 하고 파일잠금을 수동으로 운영할 수도 있습니다. 파일잠금을 수동으로 운영하려면 다음과 같이 잠금명령과 강등명령을 개별적으로 수행하고 명령 순서를 지켜야 합니다.
파일잠금
타깃에 복제된 파일들은 소스로부터 수신하는 미러링 데이터 이외의 다른 쓰기 I/O 로 부터 보호되어야 합니다. 그렇지 않으면 복제 사본을 유지하기 위한 데이터 일관성을 보장할 수 없습니다. 특히 HA를 운영하는 경우 절체의 과정 중 대기노드의 데이터 일관성 보장을 위해 파일 잠금 기능을 반드시 활성화 시켜서 운영해야 합니다.
파일잠금은 리소스의 nodes 섹션내의 auto_file_lock 옵션을 통해 리소스의 역할에 따라 자동으로 설정되게 하거나 fsradm lock 또는 unlock 명령을 통해 수동으로 활성화,비활성화 할 수 있습니다.
자동 잠금
auto_file_lock 옵션은 기본 활성화되어 있습니다. 리소스의 역할이 강등된다면 파일들은 기본적으로 잠겨진 상태가 됩니다. 잠겨진 파일들을 해제하려면 리소스의 역할을 승격하거나 unlock 명령을 통해 잠금을 해제해야 합니다.
강등 시 잠금은 자동이지만 해제는 자동이 아닙니다.
수동 잠금
auto_file_lock 옵션을 비활성화 하고 파일잠금을 수동으로 운영할 수도 있습니다. 파일잠금을 수동으로 운영하려면 다음과 같이 잠금명령과 강등명령을 개별적으로 수행하고 명령 순서를 지켜야 합니다.
Code Block |
---|
c:\>fsradm lock r0
done
c:\>fsradm secondary r0
done |
-l 옵션을 명시할 경우 위의 두 명령을 하나의 강등명령으로 처리할 수도 있습니다. 명령의 순서는 위와 동일하게 락을 먼저 걸고 강등합니다.
Code Block |
---|
c:\>fsradm secondary -l r0
done |
이와 반대로 승격 과정에선 primary 명령 이후 잠금을 해제 합니다.
Code Block |
---|
c:\>fsradm lockprimary r0 done c:\>fsradm secondaryunlock r0 done |
-l 옵션을 명시할 경우 위의 두 명령을 하나의 강등명령으로 처리할 수도 있습니다. 명령의 순서는 위와 동일하게 락을 먼저 걸고 강등합니다.
Code Block |
---|
c:\>fsradm secondary -l r0
done |
이와 반대로 승격 과정에선 primary 명령 이후 잠금을 해제 합니다.
Code Block |
---|
c:\>fsradm primary r0
done
c:\>fsradm unlock r0
done |
-u 옵션을 사용하면 하나의 승격명령에서 처리할 수 있습니다.
...
u 옵션을 사용하면 하나의 승격명령에서 처리할 수 있습니다.
Code Block |
---|
c:\>fsradm primary -u r0 done |
...
Info |
---|
|
조회
상태 조회
FSR의 상태를 fsradm status 명령을 통해 조회할 수 있습니다.
Code Block |
---|
λ fsradm status all
r0 role:primary file:up_to_date pending:0 locked:false
node2 state:repl_source peer-state:repl_target role:secondary file:up_to_date
last-synced:2019-10-24T15:30:12+09:00
node3 state:connecting peer-state:unknown role:secondary file:unknown
last-synced:none
r1 role:secondary file:inconsistent pending:0 locked:false
node2 state:connecting peer-state:unknown role:secondary file:unknown
last-synced:none |
상세 출력 옵션을 사용하면 더 많은 상태 정보를 조회할 수 있습니다.
...
...
전환
전환(switchover)은 복제 클러스터 내의 하나의 시스템에서 다른 시스템으로 자원에 대한 액세스를 수동 교환하는 동작입니다. 소스 노드를 강등시킨 후 타깃노드를 소스노드 역할로 승격하여 서비스를 위한 데이터를 활성화하는 과정입니다. 수동절체 라고도 하며 이와 반대로 장애에 자동 대응하는 개념으로 장애조치(failover)가 있습니다.
소스노드의 리소스를 강등합니다.
Code Block |
---|
c:\>fsradm secondary r0
done |
타깃노드의 리소스를 승격합니다.
Code Block |
---|
c:\>fsradm primary r0
done |
Info |
---|
|
역할 유지
리소스 역할은 운영 상황에 따라 변경될 수 있지만, 때로는 역할을 지속해서 운영하는 방식이 필요할 수 있습니다. (FSR 1.2.4 이상)
persist-role 이 설정된 리소스는 재 시작 되는 시점에 명시적으로(fsradm 명령으로) 지정된 리소스 역할을 계속 유지합니다. 복제 서비스 또는 시스템이 리부팅되어 리소스가 재 시작되는 모든 상황에서 동작합니다.
Code Block |
---|
{
...
"options": {
"persist-role": true,
...
}
} |
단방향 복제
전환과 절체없이 항상 주 노드에서 대기노드로의 단방향 복제/백업만 하고 싶다면 대기 노드 측의 타깃 전용(target-only) 속성을 고려하십시오. (FSR 1.2.4 이상)
- 위에서 설명한 persist-role 속성을 리소스 options 섹션에 설정하여 주 노드와 대기노드의 역할(role)을 고정합니다.
- target-only 속성을 대기 노드 측에 설정하여 복제/동기화 방향을 주 노드에서 대기노드 한 쪽 방향으로만 강제합니다.
타깃 전용 노드는 명시적인 명령을 포함한 모든 복제/동기화 동작에서의 소스 역할이 금지되고 타깃 역할만 가질 수 있습니다. 그리고 소스 역할로 동작하는 수동 동기화나 승격 명령 등은 모두 차단됩니다(단, 복제 연결 해제 시 승격 허용됨).
Code Block |
---|
{
...
"options": {
"persist-role": true,
...
}
"nodes": [
{
"name": "active",
...
},
{
"name": "standby",
"target-only": true
...
}
} |
Info | ||
---|---|---|
| ||
복제 연결을 해제한 후
|
조회
상태 조회
FSR의 상태를 fsradm status 명령을 통해 조회할 수 있습니다.
Code Block |
---|
λ fsradm status all r0 role:primary file:up_to_date pending:0 locked:false node2 state:repl_source peer-state:repl_target role:secondary file:up_to_date last-synced:2019-10-24T15:30:12+09:00 node3 state:connecting peer-state:unknown role:secondary file:unknown repllast-started:2020-04-09T09:50:38+09:00 last-synced:2020-04-09T09:50:53+09:00 |
상태 조회를 지속하고 싶다면 --watch(-w) 와 --interval(-i) 옵션을 사용하여 상태를 모니터링할 수 있습니다.
Code Block |
---|
λ fsradm status all -w -i 1 r0 role:secondary file:inconsistent synced:none r1 role:secondary file:inconsistent pending:0 locked:false node2 state:establishedconnecting peer-state:establishedunknown role:secondary file:inconsistentunknown last-synced:none node3 state:connecting peer-state:unknown role:secondary file:unknown |
상세 출력 옵션을 사용하면 더 많은 상태 정보를 조회할 수 있습니다.
Code Block |
---|
λ fsradm status -v r0:node1 role:primary file:up_to_date pending:0 locked:false last-synced:none r1 role:secondary file:inconsistent locked:falsepromoted:2020-06-10T09:40:32+09:00 node2 state:connectingrepl_source peer-state:unknownrepl_target role:secondary file:unknownup_to_date lastrepl-synced:none update every 1.0s. current executions: 84 press 'q' or 'ctrl+c' to quit... |
파일 상태
복제 대상 파일의 복제 상태를 나타냅니다.
unknown 알 수 없는 상태. 연결되지 않은 상대 노드의 알 수 없는 파일 상태를 표현합니다.
fileless 복제 대상 미 적재 상태. attach 명령에 의해 attaching 상태로 전환합니다.
attaching 복제 대상 적재 중 상태. 적재 중 실패하면 failed, 적재 완료하면 consistent 또는 inconsistent 상태가 됩니다.
detaching 복제 대상 분리 중. 분리 완료하면 fileless 상태가 됩니다.
failed 복제 구성(적재) 실패 상태
inconsistent 데이터 순차성 보장 불가한 상태 또는 동기화 타겟의 파일 상태. 기본적으로 승격이 불가합니다.(강제 승격 가능)
consistent 데이터 순차성 보장하는 상태. 중간 상태이며 outdated 또는 up_to_date로 최종 전환됩니다.
outdated 과거 데이터 상태. 복제 타겟 상황에서 연결 단절이나 일시 중지 등에 의해 최신 데이터를 받지 못하게 될 경우의 상태. 기본적으로 승격이 불가합니다. (강제 승격 가능)
up_to_date 최신 데이터 상태. Primary이거나 복제 타겟일 경우의 상태입니다.
연결/복제 상태
양 노드가 연결 되기 까지의 상태는 연결 상태, 연결 수립 이후의 상태는 복제 상태로 정의됩니다. 다음의 상태들이 정의되어 있습니다.
standalone 중립 상태. 연결을 시도하지 않는 상태로 리소스의 초기 연결 상태에 해당합니다. connect 명령에 의해 connecting 상태로 전환됩니다.
disconnecting 연결이 단절되고 정리 중인 상태. standalone 또는 connecting 상태로 전환됩니다.
connecting 연결 시도 중 상태. 연결 시도 중 오류가 발생하면 standalone, 연결이 성공하면 connected 상태가 됩니다. 실제로는 소켓 계층에서 accept와 connect 가 동시에 시도되는 상태입니다.
connected 연결 성공하고 복제 네트워크에 대해 인증 중인 상태입니다. 인증이 성공하면 established, 인증이 실패하면 standalone 상태가 됩니다.
established 복제 인증 완료 상태. 연결 직후의 상태이며 Secondary 간 연결이 완료되었을 때의 기본 상태입니다. 동기화, 복제로 바로 이행하지는 않습니다. 이 상태에서 승격할 경우 sync_source 또는 repl_source가 되고 상대가 승격하면 sync_target 또는 repl_taret 이 됩니다.
sync_source 동기화 소스 상태. 동기화 일시 중지할 경우 sync_source_paused 상태, 동기화 완료시 repl_source 상태가 됩니다. 세컨더리간에 동기화가 완료될 경우엔 established 상태가 됩니다.
sync_source_paused 동기화 소스 일시 중지 상태. 동기화 재개할 경우 sync_source 상태가 됩니다.
sync_target 동기화 타겟 상태. 동기화 일시 중지할 경우 sync_target_paused, 동기화 완료 시 repl_target이 됩니다. secondary 간 동기화 완료는 established 상태가 됩니다.
sync_target_paused 동기화 타겟 일시 중지 상태. 동기화 재개할 경우 sync_target 상태가 됩니다.
repl_source 복제 소스 상태. 이 상태에서 강등할 경우 established 상태, 일시 중지할 경우 repl_source_paused, 동기화 시작 시 sync_source 상태로 전환합니다.
repl_source_paused 복제 소스 일시 중지 상태. 복제 재개 시 repl_source 상태가 됩니다.
repl_target 복제 타겟 상태. 이 상태에서 상대가 강등하면 established, 일시 중지할 경우 repl_target_paused, 동기화가 시작되면 sync_target 상태가 됩니다.
repl_target_paused 복제 타겟 일시 중지 상태. 복제가 재개되면 repl_target 상태가 됩니다.
성능 조회
성능 조회 명령을 통해 복제 처리량과 엔진 내부의 지연시간을 조회할 수 있습니다.
Code Block |
---|
λ fsradm perf r0 |
Code Block |
---|
λ fsradm latency r0 |
성능 모니터
fsradm perfmon 명령을 통해 성능을 실시간 모니터링할 수 있습니다.
Code Block |
---|
c:\>fsradm perfmon r0 |
...
started:2020-06-10T09:40:32+09:00 last-synced:2020-06-10T09:40:33+09:00
node3 state:connecting peer-state:unknown role:secondary file:unknown
repl-started:2020-04-09T09:50:38+09:00 last-synced:2020-04-09T09:50:53+09:00 |
상태 조회를 지속하고 싶다면 --watch(-w) 와 --interval(-i) 옵션을 사용하여 상태를 모니터링할 수 있습니다.
Code Block |
---|
λ fsradm status all -w -i 1
r0 role:secondary file:inconsistent locked:false
node2 state:established peer-state:established role:secondary file:inconsistent
last-synced:none
node3 state:connecting peer-state:unknown role:secondary file:unknown
last-synced:none
r1 role:secondary file:inconsistent locked:false
node2 state:connecting peer-state:unknown role:secondary file:unknown
last-synced:none
update every 1.0s. current executions: 84
press 'q' or 'ctrl+c' to quit... |
파일 상태
복제 대상 파일의 복제 상태를 나타냅니다.
unknown 알 수 없는 상태. 연결되지 않은 상대 노드의 알 수 없는 파일 상태를 표현합니다.
fileless 복제 대상 미 적재 상태. attach 명령에 의해 attaching 상태로 전환합니다.
attaching 복제 대상 적재 중 상태. 적재 중 실패하면 failed, 적재 완료하면 consistent 또는 inconsistent 상태가 됩니다.
detaching 복제 대상 분리 중. 분리 완료하면 fileless 상태가 됩니다.
failed 복제 구성(적재) 실패 상태
inconsistent 데이터 순차성 보장 불가한 상태 또는 동기화 타겟의 파일 상태. 기본적으로 승격이 불가합니다.(강제 승격 가능)
consistent 데이터 순차성 보장하는 상태. 중간 상태이며 outdated 또는 up_to_date로 최종 전환됩니다.
outdated 과거 데이터 상태. 복제 타겟 상황에서 연결 단절이나 일시 중지 등에 의해 최신 데이터를 받지 못하게 될 경우의 상태. 기본적으로 승격이 불가합니다. (강제 승격 가능)
up_to_date 최신 데이터 상태. Primary이거나 복제 타겟일 경우의 상태입니다.
연결/복제 상태
양 노드가 연결 되기 까지의 상태는 연결 상태, 연결 수립 이후의 상태는 복제 상태로 정의됩니다. 다음의 상태들이 정의되어 있습니다.
standalone 중립 상태. 연결을 시도하지 않는 상태로 리소스의 초기 연결 상태에 해당합니다. connect 명령에 의해 connecting 상태로 전환됩니다.
disconnecting 연결이 단절되고 정리 중인 상태. standalone 또는 connecting 상태로 전환됩니다.
connecting 연결 시도 중 상태. 연결 시도 중 오류가 발생하면 standalone, 연결이 성공하면 connected 상태가 됩니다. 실제로는 소켓 계층에서 accept와 connect 가 동시에 시도되는 상태입니다.
connected 연결 성공하고 복제 네트워크에 대해 인증 중인 상태입니다. 인증이 성공하면 established, 인증이 실패하면 standalone 상태가 됩니다.
established 복제 인증 완료 상태. 연결 직후의 상태이며 Secondary 간 연결이 완료되었을 때의 기본 상태입니다. 동기화, 복제로 바로 이행하지는 않습니다. 이 상태에서 승격할 경우 sync_source 또는 repl_source가 되고 상대가 승격하면 sync_target 또는 repl_taret 이 됩니다.
sync_source 동기화 소스 상태. 동기화 일시 중지할 경우 sync_source_paused 상태, 동기화 완료시 repl_source 상태가 됩니다. 세컨더리간에 동기화가 완료될 경우엔 established 상태가 됩니다.
sync_source_paused 동기화 소스 일시 중지 상태. 동기화 재개할 경우 sync_source 상태가 됩니다.
sync_target 동기화 타겟 상태. 동기화 일시 중지할 경우 sync_target_paused, 동기화 완료 시 repl_target이 됩니다. secondary 간 동기화 완료는 established 상태가 됩니다.
sync_target_paused 동기화 타겟 일시 중지 상태. 동기화 재개할 경우 sync_target 상태가 됩니다.
repl_source 복제 소스 상태. 이 상태에서 강등할 경우 established 상태, 일시 중지할 경우 repl_source_paused, 동기화 시작 시 sync_source 상태로 전환합니다.
repl_source_paused 복제 소스 일시 중지 상태. 복제 재개 시 repl_source 상태가 됩니다.
repl_target 복제 타겟 상태. 이 상태에서 상대가 강등하면 established, 일시 중지할 경우 repl_target_paused, 동기화가 시작되면 sync_target 상태가 됩니다.
repl_target_paused 복제 타겟 일시 중지 상태. 복제가 재개되면 repl_target 상태가 됩니다.
성능 조회
성능 조회 명령을 통해 복제 처리량과 엔진 내부의 지연시간을 조회할 수 있습니다.
Code Block |
---|
λ fsradm perf r0 |
Code Block |
---|
λ fsradm latency r0 |
성능 모니터
fsradm perfmon 명령을 통해 성능을 실시간 모니터링할 수 있습니다.
Code Block |
---|
c:\>fsradm perfmon r0 |
성능 모니터링은 콘솔화면에 결과를 출력하여 직접 확인하거나 모니터링 결과를 파일로 저장하는 등 다음과 같이 몇 가지 옵션을 사용할 수 있습니다.
...
Code Block |
---|
{ ... "disk": { "health": { "period": 5 } } } |
이벤트
FSR 은 이벤트 구독 명령을 통해 FSR 로 부터 정의된 이벤트를 통지 받을 수 있습니다. 이벤트 구독을 통해 파일이나 연결 등의 상태가 변경되는 과정을 실시간 추적할 수 있습니다.
Code Block |
---|
λ fsradm events r0
2020-06-12T12:42:39.295379 type=rpc state=connected
2020-06-12T12:42:41.685784 type=state node=node2 peer=node1 resource=r0 value=standalone
2020-06-12T12:42:41.685784 type=added node=node2 resource=r0
2020-06-12T12:42:41.685784 type=role node=node2 resource=r0 role=secondary
2020-06-12T12:42:41.685784 type=file_state node=node2 resource=r0 value=fileless
2020-06-12T12:42:41.728821 type=file_state node=node2 resource=r0 value=attaching
2020-06-12T12:42:41.744835 type=file_state node=node2 resource=r0 value=outdated
2020-06-12T12:42:41.774378 type=state node=node2 peer=node1 resource=r0 value=connecting |
이벤트 해석의 용이성을 위해 json 형식의 출력을 지원하며 동기화 상태(--sync), 성능 통계에 대한 모니터링(–perf)에 대한 옵션을 부가적으로 지원합니다.
Code Block |
---|
λ fsradm events --json r0
{"type":"rpc","timestamp":"2020-06-12T03:43:56.152358300Z","datas":{"state":"connected"}}
{"type":"state","timestamp":"2020-06-12T03:43:58.396422300Z","datas":{"node":"node2","peer":"node1","resource":"r0","value":"standalone"}}
{"type":"added","timestamp":"2020-06-12T03:43:58.396422300Z","datas":{"node":"node2","resource":"r0"}}
{"type":"role","timestamp":"2020-06-12T03:43:58.396422300Z","datas":{"node":"node2","resource":"r0","role":"secondary"}}
{"type":"file_state","timestamp":"2020-06-12T03:43:58.396422300Z","datas":{"node":"node2","resource":"r0","value":"fileless"}}
{"type":"file_state","timestamp":"2020-06-12T03:43:58.437426600Z","datas":{"node":"node2","resource":"r0","value":"attaching"}}
{"type":"file_state","timestamp":"2020-06-12T03:43:58.452638800Z","datas":{"node":"node2","resource":"r0","value":"outdated"}}
{"type":"state","timestamp":"2020-06-12T03:43:58.479433800Z","datas":{"node":"node2","peer":"node1","resource":"r0","value":"connecting"}} |
이벤트의 유형에 관한 상세한 내용은 부록의 명령어 부분을 참고하세요.
정합성 검사
다음의 명령을 통해 소스와 타깃간의 데이터 정합성 검사를 수행할 수 있습니다.
Code Block |
---|
λ fsradm verify <resource|all> <peer-node|all> |
정합성 검사 수행 중 중단을 하려면 verify-stop 을 사용합니다.
Code Block |
---|
λ fsradm verify-stop <resource|all> <peer-node|all> |
정합성 검사는 소스 또는 타깃에서 verify 검사를 요청하여 수행합니다. 타깃에서 정합성 검사를 요청하거나 중단할 경우에는 타깃 자신만 지정하면 되지만 소스에서 수행하려면 n node 에 대해 검사를 수행하고 있다면 중단할 타깃을 지정해야 합니다. 그렇지 않으면 n node 정합성 검사에 대해 모두 중단합니다.
정합성 검사는 복제 수행 여부에 따라 동작 모드에 차이가 있습니다. 소스와 타깃 양측이 Secondary 일 경우라면 일반 verify 검사모드로 동작합니다. 그러나 한 쪽이 Primary 인 복제가 있는 상태일 경우에는 소스와 타깃 간의 실시간 데이터 변경분에 대응하기 위한 advanced-verify 모드로 동작합니다. 이 모드에선 복제 변경 분에 대한 데이터 시퀀스를 대기하여 처리하는 방식입니다. 일반 verify 모드와 advanced-verify 모드는 엔진에서 자동으로 결정하므로 사용자는 신경쓰지 않아도 되지만 두 방식에 차이가 있다는 것은 알아두어야 합니다.
기본적으로 정합성 검사는 UpToDate 인 데이터간의 검사를 전제로 하기 때문에 양측이 최신의 데이터가 아닐 경우 또는 정합성 검사 도중 동기화가 진행되거나 복제 상태가 변경되는 등의 상태 변화가 있게 되면 정합성 검사는 취소됩니다.
검사를 하는 대상은 해쉬 비교를 통해 차이점이 있는 파일을 대상으로 하고 정합성 검사가 끝난 후 검사에 대한 결과는 result 명령을 통해 확인할 수 있습니다.
...
FSR(v1.3) 에서 디스크 상태를 모니터링하는 방법이 더 강화되었습니다. 가상화를 기반으로 한 가상 디스크(non pnp 장치)의 경우엔 다음의 방법으로 디스크 상태를 감시할 수 있는 방법을 추가로 제공합니다.
io_test 섹션에 활성화 여부와 주기를 지정하면 됩니다.
Code Block |
---|
{
"nodes": [
{
"name": "node1-hostname",
"url": "192.168.159.140:9830",
"files": [
{
"path": "C:/fsr/repl"
}
],
"io_test": {
"enable": true,
"period": "10s"
},
},
{
"name": "node2-hostname",
"url": "192.168.159.141:9830",
"files": [
{
"path": "C:/fsr/repl"
}
],
"io_test": {
"enable": false,
"period": "5s"
},
}
],
} |
Info |
---|
하이퍼바이저 상의 가상 디스크 들이 종종 표준 PNP 를 지원하지 않는 가상디스크로 제공되는 경우가 있습니다. 이런 디스크는 게스트 OS 입장에서 디스크 장치의 제거 등 장애상황을 인지할 수 있는 방법이 없습니다. 주기적인 디스크 I/O 를 통해 디스크 상태를 감시할 수 밖에 없습니다. |
이벤트
FSR 은 이벤트 구독 명령을 통해 FSR 로 부터 정의된 이벤트를 통지 받을 수 있습니다. 이벤트 구독을 통해 파일이나 연결 등의 상태가 변경되는 과정을 실시간 추적할 수 있습니다.
Code Block |
---|
λ fsradm events r0
2020-06-12T12:42:39.295379 type=rpc state=connected
2020-06-12T12:42:41.685784 type=state node=node2 peer=node1 resource=r0 value=standalone
2020-06-12T12:42:41.685784 type=added node=node2 resource=r0
2020-06-12T12:42:41.685784 type=role node=node2 resource=r0 role=secondary
2020-06-12T12:42:41.685784 type=file_state node=node2 resource=r0 value=fileless
2020-06-12T12:42:41.728821 type=file_state node=node2 resource=r0 value=attaching
2020-06-12T12:42:41.744835 type=file_state node=node2 resource=r0 value=outdated
2020-06-12T12:42:41.774378 type=state node=node2 peer=node1 resource=r0 value=connecting |
이벤트 해석의 용이성을 위해 json 형식의 출력을 지원하며 동기화 상태(--sync), 성능 통계에 대한 모니터링(–perf)에 대한 옵션을 부가적으로 지원합니다.
Code Block |
---|
λ fsradm events --json r0
{"type":"rpc","timestamp":"2020-06-12T03:43:56.152358300Z","datas":{"state":"connected"}}
{"type":"state","timestamp":"2020-06-12T03:43:58.396422300Z","datas":{"node":"node2","peer":"node1","resource":"r0","value":"standalone"}}
{"type":"added","timestamp":"2020-06-12T03:43:58.396422300Z","datas":{"node":"node2","resource":"r0"}}
{"type":"role","timestamp":"2020-06-12T03:43:58.396422300Z","datas":{"node":"node2","resource":"r0","role":"secondary"}}
{"type":"file_state","timestamp":"2020-06-12T03:43:58.396422300Z","datas":{"node":"node2","resource":"r0","value":"fileless"}}
{"type":"file_state","timestamp":"2020-06-12T03:43:58.437426600Z","datas":{"node":"node2","resource":"r0","value":"attaching"}}
{"type":"file_state","timestamp":"2020-06-12T03:43:58.452638800Z","datas":{"node":"node2","resource":"r0","value":"outdated"}}
{"type":"state","timestamp":"2020-06-12T03:43:58.479433800Z","datas":{"node":"node2","peer":"node1","resource":"r0","value":"connecting"}} |
이벤트의 유형에 관한 상세한 내용은 부록의 명령어 1.2.x 부분을 참고하세요.
정합성 검사
다음의 명령을 통해 소스와 타깃간의 데이터 정합성 검사를 수행할 수 있습니다.
Code Block |
---|
λ fsradm verify <resource|all> <peer-node|all> |
정합성 검사 수행 중 중단을 하려면 verify-stop 을 사용합니다.
Code Block |
---|
λ fsradm verify-stop <resource|all> <peer-node|all> |
정합성 검사는 소스 또는 타깃에서 verify 검사를 요청하여 수행합니다. 타깃에서 정합성 검사를 요청하거나 중단할 경우에는 타깃 자신만 지정하면 되지만 소스에서 수행하려면 n node 에 대해 검사를 수행하고 있다면 중단할 타깃을 지정해야 합니다. 그렇지 않으면 n node 정합성 검사에 대해 모두 중단합니다.
정합성 검사는 복제 수행 여부에 따라 동작 모드에 차이가 있습니다. 소스와 타깃 양측이 Secondary 일 경우라면 일반 verify 검사모드로 동작합니다. 그러나 한 쪽이 Primary 인 복제가 있는 상태일 경우에는 소스와 타깃 간의 실시간 데이터 변경분에 대응하기 위한 advanced-verify 모드로 동작합니다. 이 모드에선 복제 변경 분에 대한 데이터 시퀀스를 대기하여 처리하는 방식입니다. 일반 verify 모드와 advanced-verify 모드는 엔진에서 자동으로 결정하므로 사용자는 신경쓰지 않아도 되지만 두 방식에 차이가 있다는 것은 알아두어야 합니다.
기본적으로 정합성 검사는 UpToDate 인 데이터간의 검사를 전제로 하기 때문에 양측이 최신의 데이터가 아닐 경우 또는 정합성 검사 도중 동기화가 진행되거나 복제 상태가 변경되는 등의 상태 변화가 있게 되면 정합성 검사는 취소됩니다.
검사를 하는 대상은 해쉬 비교를 통해 차이점이 있는 파일을 대상으로 하고 정합성 검사가 끝난 후 검사에 대한 결과는 result 명령을 통해 확인할 수 있습니다.
Code Block |
---|
λ fsradm result r0 { "id": "r0", "result": { "summary": { "start_time": "2019-09-09T06:22:26.6958913Z", "end_time": "2019-09-09T06:22:27.4653424Z", "peer_node": "node2" }, "totals": { "diff_dir": "3", "diff_file": "1", "diff_bytes": "14", "orphaned_dir": "0", "orphaned_file": "0", "syncedorphaned_bytes": "0", "flagsmissing_dir": 4"0", "propertiesmissing_file": { "0", "modmissing_timebytes": { "0", "localsynced_bytes": "2019-09-06T13:26:54.0042751+09:00",0" }, "remotefiles": "2019-09-02T07:24:39.3341577Z"[ { } "type": "different", } }, { "type": "different", "name": "G:"name": "G:\\Temp\\test1\\conf\\drbd.d", "is_dir": true, "out_of_sync": "0", "synced": "0", "flags": 4, "properties": { "mod_time": { "local": "2019-09-06T13:26:59.06777481427926+09:00", "remote": "2019-0809-07T0202T07:1524:5839.4057437Z161996Z" } } }, { "type": "different", "name": "G:\\Temp\\test1\\contributors.txtconf\\drbd.d\\1", "outis_of_syncdir": "14"true, "synced"out_of_sync": "0", "synced": "0", "flags": 54, "properties": { "mod_time": { "local": "2019-09-09T1406T13:0026:0554.63792390042751+09:00", "remote": "20182019-1209-12T0402T07:4224:5039.6605579Z3341577Z" }, } "size": { }, "local": 9, { "remotetype": 15"different", } "name": "G:\\Temp\\test1\\conf", "is_dir": true, "out_of_sync": "0", "synced": "0", } "flags": 4, } "properties": { ], "file_count": 4 } } |
재구성
운영 중 설정을 변경하는 절차와 예기치 않은 장애가 발생한 후 이를 복구하기 위한 절차에 대해 설명합니다.
설정 변경
FSR 의 노드 간 구성 설정은 구성파일 수준에서 모두 동일해야 합니다. 만약 설정에서 차이가 있다면 동작 방식이 모호해 질 수 있기 때문에 이러한 구성의 차이를 두는 것을 제한하고 있습니다. 그래서 FSR 의 설정을 변경 하려면 먼저 소스와 타깃 노드 간의 연결을 해제하고 각각의 노드의 설정을 동일하게 변경하여 적용(adjust)한 후 연결을 재 성립하면 됩니다.
만약 연결 시점에 양 노드의 설정에 차이가 발견되면 오류와 함께 연결을 끊고 StandAlone 상태가 됩니다. 또한 연결이 이미 성립되어 있는 상태에서 양측의 설정이 차이가 있게 조정(adjust)하려고 하면 오류가 반환됩니다.
Info |
---|
설정을 조정(adjust)하는 과정은 FSR에서 내부적으로 구현한 프로토콜을 통해 노드 간 상태 변화를 수반합니다. adjust 를 수행한 노드는 adjusting 상태가 되며 이 시점에 상대편 노드는 need_to_adjust 상태가 되어 adjust 가 수행되도록 유도합니다. |
장애 후 조치
복제 운영 중 디스크에 물리적 손상이 발생하는 등 예기치 않은 문제가 발생할 경우 이에 대응하고 복제를 정상화 하기 위한 절차를 필요로 합니다. 기본적으로는 이러한 문제가 발생하게 되면 디스크를 교체하고 복제 구성을 다시 해야 합니다.
다음의 과정에 따라 복제를 재구성하고 재 동기화 하는 절차를 수행해야 합니다.
- 운영중인 리소스를 중지 합니다.
Code Block |
---|
c:\>fsradm down r0
done |
- 디스크 교체 등 복구작업을 수행합니다.
- 메타를 재 생성합니다. 만약 구성상 변경이 있을 경우 구성파일을 새롭게 작성하고 메타를 재 생성해야 합니다.
Code Block |
---|
c:\>fsradm meta create r0
done |
- 리소스를 기동합니다.
Code Block |
---|
c:\>fsradm up r0
done |
- 소스 노드와 연결이 수립되면 동기화를 시작합니다.
파일 삭제 백업
...
"mod_time": {
"local": "2019-09-06T13:26:59.0677748+09:00",
"remote": "2019-08-07T02:15:58.4057437Z"
}
}
},
{
"type": "different",
"name": "G:\\Temp\\test1\\contributors.txt",
"out_of_sync": "14",
"synced": "0",
"flags": 5,
"properties": {
"mod_time": {
"local": "2019-09-09T14:00:05.6379239+09:00",
"remote": "2018-12-12T04:42:50.6605579Z"
},
"size": {
"local": 9,
"remote": 15
}
}
}
],
"file_count": 4
}
} |
재구성
운영 중 설정을 변경하는 절차와 예기치 않은 장애가 발생한 후 이를 복구하기 위한 절차에 대해 설명합니다.
설정 변경
FSR 의 노드 간 구성 설정은 구성파일 수준에서 모두 동일해야 합니다. 만약 설정에서 차이가 있다면 동작 방식이 모호해 질 수 있기 때문에 이러한 구성의 차이를 두는 것을 제한하고 있습니다. 그래서 FSR 의 설정을 변경 하려면 먼저 소스와 타깃 노드 간의 연결을 해제하고 각각의 노드의 설정을 동일하게 변경하여 적용(adjust)한 후 연결을 재 성립하면 됩니다.
만약 연결 시점에 양 노드의 설정에 차이가 발견되면 오류와 함께 연결을 끊고 StandAlone 상태가 됩니다. 또한 연결이 이미 성립되어 있는 상태에서 양측의 설정이 차이가 있게 조정(adjust)하려고 하면 오류가 반환됩니다.
Info |
---|
설정을 조정(adjust)하는 과정은 FSR에서 내부적으로 구현한 프로토콜을 통해 노드 간 상태 변화를 수반합니다. adjust 를 수행한 노드는 adjusting 상태가 되며 이 시점에 상대편 노드는 need_to_adjust 상태가 되어 adjust 가 수행되도록 유도합니다. |
장애 후 조치
복제 운영 중 디스크에 물리적 손상이 발생하는 등 예기치 않은 문제가 발생할 경우 이에 대응하고 복제를 정상화 하기 위한 절차를 필요로 합니다. 기본적으로는 이러한 문제가 발생하게 되면 디스크를 교체하고 복제 구성을 다시 해야 합니다.
다음의 과정에 따라 복제를 재구성하고 재 동기화 하는 절차를 수행해야 합니다.
- 운영중인 리소스를 중지 합니다.
Code Block |
---|
c:\>fsradm down r0
done |
- 디스크 교체 등 복구작업을 수행합니다.
- 메타를 재 생성합니다. 만약 구성상 변경이 있을 경우 구성파일을 새롭게 작성하고 메타를 재 생성해야 합니다.
Code Block |
---|
c:\>fsradm meta create r0
done |
- 리소스를 기동합니다.
Code Block |
---|
c:\>fsradm up r0
done |
- 소스 노드와 연결이 수립되면 동기화를 시작합니다.
백업
파일 삭제 백업
FSR은 파일삭제에 대한 백업을 제공합니다. 파일삭제에 대한 백업은 의도치 않게 삭제 되는 파일들을 타깃의 특정경로에 임시로 저장해 두는 기능으로 archive 속성에 의해 지정될 수 있습니다. archive 속성은 기본 비활성화 되어 있으며 백업될 경로와 보관될 기간을 지정할 수 있습니다.
스냅샷
스냅샷은 특정 시점의 스토리지의 파일 시스템을 사진 찍듯이 캡처해서 데이터를 백업하는 기술 입니다. 복제 운영 중 사고로 최신 데이터가 훼손되거나 말웨어 감염과 같은 보안이슈에 노출되어 데이터 무결성이 훼손되면 복제의 기능만으로는 대응할 수 없습니다.
이런 경우를 대비해 복제와는 별개로 백업을 미리 해 두는게 일반적이며, 백업 유형에 따라 전체 백업 또는 전체 스냅샷, 증분 스냅샷을 통해 사용자의 데이터를 보호할 수 있습니다.
FSR은 스냅샷 기능을 복제 리소스를 기준으로 구현하고 있으며 따라서 스냅샷 제어도 리소스를 기준으로 합니다. 또한 스냅샷은 각 노드의 디스크 볼륨에 이미지로 저장 되고 노드 내에서 제어하고 처리됩니다. 이것은 클러스터 노드 들 간의 스냅샷들에 대한 상호 연동은 없다는 뜻 입니다. 노드 별로 스냅샷을 운영하다가 복구가 필요하면 노드에 저장된 이미지로 개별 복구하면 됩니다.
스냅샷을 생성하고 제어하는 명령과 관련한 자세한 사항은 스냅샷 - FSR 1.2 또는 스냅샷 - FSR 1.3 의 내용을 참고하세요.
스냅샷 볼륨
스냅샷을 운영하기에 앞서 가장 먼저 고려해야 할 것은 스냅샷을 저장해 둘 볼륨을 지정하는 것 입니다. 복제 볼륨 내에 스냅샷을 보관해 둘 수 도 있고 외부의 다른 디스크 볼륨에 저장할 수도 있습니다. 이것은 볼륨에서 이미 사용된 공간과 남은 여유 공간을 보고 정해야 하는데, 여유 공간이 많지 않다면 외부의 볼륨에 지정하여 스냅샷을 저장하는 것이 좋습니다.
스냅샷을 위한 볼륨 공간은 현재 사용된 데이터의 크기 만큼의 용량을 필요로 합니다.
예를 들어 1TB 볼륨에 100GB 를 사용하고 있다면 여기에 필요한 스냅샷 용량은 100GB 입니다. 만약 사용 용량이 100GB 를 넘어서 150GB 가 된다면 새로운 스냅샷을 기록하는데 최대 150GB 용량이 요구될 것 입니다.
다음은 스냅샷을 운영하기 위한 구체적인 구성 사례입니다.
- 복제 볼륨 1TB, 사용공간 300GB
- 1일 1회 스냅샷 기록, 1주(7일)의 스냅샷 스케줄 유지
위 예의 경우 1주 동안 7개 스냅샷 이미지 공간이 요구 되므로 스냅샷 저장을 위한 볼륨의 공간은 최소 300GB * 7 = 2.1TB 이며 최대 1TB * 7 = 7TB 가 됩니다.
스냅샷은 Copy On Write(COW) 기술을 기반으로 합니다. 데이터에 변경이 발생할 때 원본을 저장해 두는 것 입니다. 따라서 스냅샷을 생성한 지 얼마 지나지 않은 초기에는 변경점이 많지 않으므로 스냅샷이 차지하는 용량이 작습니다. 그렇지만 시간이 지날수록 데이터 변경 분은 점차 늘어나고 결국 데이터의 모든 영역이 변경 됬다고 가정하면 전체 원본 데이터를 저장해 둘 스냅샷 공간이 필요하게 됩니다. 결론적으로 스냅샷에 필요한 최대 용량은 데이터 전체 크기의 백업분에 해당하는 용량과 같다고 할 수 있습니다.
당장 스냅샷에 필요한 공간은 현재 사용되는 공간 만큼의 용량을 요구하겠지만 볼륨의 사용량은 시간이 갈수록 증가할 수 있으므로 이를 염두에 두어서 최대 용량으로 고려해야 한다는 것 입니다.
Info |
---|
다른 제품의 스냅샷 기능의 매뉴얼에는 전체 볼륨의 수십% 의 볼륨 여유 공간을 확보하는 것을 권장한다고 되어 있는 경우가 있습니다. 그러나 이것은 스냅샷을 위한 최대용량을 말하는게 아니라 단지 권장용량을 의미하기 때문에 스냅샷 용량 구성에 대해 오해를 불러 일으킬 수 있습니다. 이를 알지 못하고 충분한 여유 공간 없이 스냅샷을 운영하다 보면 어느 시점에 가서 더 이상 스냅샷을 생성하지 못하게 될 것 입니다. |
Info | ||
---|---|---|
| ||
FSR 스냅샷은 Windows 에서 Volume Shadow Copy Service 의 명세를 따릅니다.
리눅스 LVM 은 특별히 스냅샷 용량에 대해 제한하지 않습니다. 단지 스토리지 용량에 한정적 입니다. |
전/후 처리
FSR 스냅샷은 응용 일관성(Application Consistency)을 보장하는 스냅샷을 지향합니다. 응용 프로그램 일관성을 가진 스냅샷을 획득하기 위해선 다음과 같은 순서가 지켜져야 합니다.
- 스냅샷을 기록하기 전
- 응용 I/O 작업을 일시 중단하고 응용의 메모리 버퍼를 Flush 하여 디스크를 최신 데이터로 갱신합니다.
- 해당 볼륨에 대한 파일시스템 캐쉬를 Flush 합니다.
- 스냅샷을 기록합니다.
- 응용 I/O 작업을 재개합니다.
여기서 볼 수 있듯이 스냅샷을 기록하기 전에 최신 데이터를 볼륨에 반영하는 과정을 선행하고 스냅샷 기록 후 응용 I/O 를 재개할 수 있어야 합니다. 이것은 FSR 의 스냅샷 사전/사후 핸들러를 통해 응용을 제어하도록 기회가 부여되며 이 절차들이 제대로 수행 되었을 때 응용 일관성을 보장한 스냅샷을 취할 수 있습니다.
만약 위 절차대로 응용을 제어할 수 없다면 최소한 파일시스템 캐쉬를 Flush 해서 파일시스템 일관성(Filesystem Consistency)을 가진 스냅샷으로 기록해야 하며 이마저도 수행하지 않는다면 충돌 일관성(Crash Consistency) 수준의 스냅샷만을 확보하게 될 것 입니다.
Windows 의 VSS 서비스는 이러한 응용 일관성 스냅샷을 보장하기 위하여 VSS Writer 를 응용 프로그램에서 구현하도록 제안하고 있습니다. VSS는 응용의 VSS Writer 와 상호 연동하여 스냅샷 요청이 있을 경우 위 절차를 차례로 수행하여 응용 일관성 스냅샷을 구현합니다. 따라서 VSS Writer 를 구현한 응용 프로그램을 대상으로 한다면 사전/사후 핸들러를 작성할 필요가 없습니다. 다음은 VSS Writer 를 지원하는 대표적인 프로그램들 입니다.
현실적으로는 위 프로그램들을 제외하면 대부분의 응용 프로그램들에선 VSS Writer 를 구현하고 있지 않습니다.