http://linux-ha.osdn.jp/wp/archives/3868
변경 내역
- 2013.9.19 초판 제정
- 2016.3.24 Pacemaker-1.1에 대응
■ 소개
Linux-HA Japan을 보시는 여러분 안녕하세요. Linux-HA Japan 속 사람 동쪽라고합니다 m (_ _) m
"움직여 이해 Pacemaker - CRM 설정 편 ~ 그 3」라고하는 것으로, 전전번 , 전회 의 계속입니다.
이번의 예제 설정 파일 을 제어하는 다음 7 항목을 모두 해독 할 수 있습니다. 3 회에 걸친 CRM 설정 편은 이번이 마지막입니다.
- 1. STONITH은 무효입니다. ( 그 1 에서 읽어 내고 있음)
- 2. 1 회 자원 고장 F / O합니다. 자동 장애 복구는하지 않습니다. ( 그 1 에서 읽어 내고 있음)
- 3. resource1, resource2라는 자원을 grp라는 group (그룹)합니다. ( 2 에서 읽어 내고 있음)
- 4. resource3라는 자원을 clnResource라는 clone (복제) 자원으로 두 시스템에서 시작합니다. ( 2 에서 읽어 내고 있음)
- 5. resource1,2,3 자원은 반드시 resource3 (clnResource) → resource1 → resource2 순으로 시작합니다. (일부 2 에서 읽어 내고 있음)
- 6. grp는 둘 중 하나의 머신에서 시작합니다. 두 컴퓨터가 실행 가능한 상태의 경우 pm01을 우선합니다.
- 7. resource3 (clnResource)가 시작되지 않은 노드에서 resource1 및 resource2 (grp)가 시작되지 않습니다.
※ 전회, 전전번의 기사에서 자원 이름을 CRM 구성과는 다른 "dummy1」등이라고 기재되어 있었지만,"resource1 "오류였습니다. 죄송합니다.
이번 주목하는 것은 다음 부분입니다.
### Resource Location ###
location rsc_location-1 grp \
rule 200: #uname eq pm01 \
rule 100: #uname eq pm02
### Resource Colocation ###
colocation rsc_colocation-1 INFINITY: grp clnResource
### Resource Order ###
order rsc_order-1 0: clnResource grp symmetrical=false
이 곳에서는 location, colocation, order 세 가지 명령을 사용합니다.
이 3 개는 모두 자원에 대해 " 제약 "을 설정하는 명령입니다.
「제약」을 사용하면 자원이 시작할 때 다음 세 가지 조건을 설정할 수 있으며, 각 명령에 대응하고 있습니다.
- location → 위치 : 모든 노드에서 시작 하는가?
- colocation → 동거 : 어떤 자원과 함께 시작 하는가?
- order → 순서 : 어떤 자원의 전 / 후 시작할지?
조속히이 3 명령의 설명을 말하고 싶지만 그 전에 제약을 이해하는 데 중요한 개념이 있습니다.
그것은 " 점수 값 "입니다.
자세한 내용은 나중에 설명하지만 제약의 3 명령은 모두있는 규칙에 점수 값을 설정하는 것입니다.
그래서 우선 점수 값의 설명에서하고 싶습니다.
■ 점수 값의 큰 노드에서 자원 시작
점수 값은 자원을 모든 노드에서 시작하거나 우선 순위를 나타내는 값입니다.
노드를 시작하거나 리소스를 추가하거나 고장이 발생하거나와 클러스터의 상태에 변화가있을 경우 Pacemaker가 자동으로 (재) 계산합니다.
Pacemaker는 산출 한 점수 값을 비교하여 가장 큰 값의 노드에서 자원을 시작합니다.
산출 한 점수 값이 음수 경우 해당 노드에서 자원을 시작할 수 없습니다.
점수 값은 다음 범위 중 하나입니다.
-INFINITY <음수 <0 <양수 <INFINITY"-INFINITY (마이너스 무한대)」와 「INFINITY (무한) '는 특별한 값으로, 전자는"금지 ", 후자는"강제 "를 나타냅니다.
각각 다른 값의 연산 결과는 다음과 같이 정의되어 있습니다 .
- 다른 값 + INFINITY = INFINITY
- 다른 값 - INFINITY = -INFINITY
- INFINITY - INFINITY = -INFINITY
1,2 번째 연산 결과는 어딘지 모르게 압니다 만, 3 번째의 연산 결과는 조금 이상한 생각이 듭니다.
수학적으로 말하면 ∞-∞는 부정입니다. 이 클러스터 리소스를 시작할지 여부가 불확실한 와서는 불편합니다.
-INIFNITY는 일반적으로 고장이 발생한 노드에 부여됩니다. 만약 INIFINITY - INFINITY이 부정이라면 아래의 제약 명령 INFINITY를 부여한 노드에서 장애가 발생하면 자원이 시작할지 여부가 부정되어 버립니다.
이것을 피하고 고장난 노드에서 시작되지 판단하는 -INFINITY을 우선하고있는 것입니다.
점수 값은 기본적으로 Pacemaker가 클러스터의 상황에 따라 자동으로 산출되지만, 후술의 「제약」에 의해 특정에 경우의 점수 값을 사용자가 결정 (Pacemaker에 제공) 할 수 있습니다.
「제약」을 능숙하게 활용 점수 값을 조작하는 것으로, 자원의 시작을 사용자 마음대로 조종 할 수있는 것입니다.
■ location에서 시작 노드를 제약
location은 시작 노드를 제약하는 명령입니다.
그 노드의 상태를 평가하고 그것에 매치했을 경우의 점수 값을 정의하여 설정합니다.
location의 개요 대표적인 형식은 다음과 같습니다.
| 요약 | 논리 연산 식을 만족하는 경우의 점수 값을 지정하여 자원을 시작할 노드를 제한합니다.
논리 연산 식에서는 주로 "노드 이름"과 "속성 값"을 평가할 수 있습니다.
rule ~ 행을 여러 작성하여 1 리소스에 여러 평가 식 및 점수를 설정할 수 있습니다. |
|---|
| 서식 | location <제약의 ID> <리소스 ID> \
rule <점수 값> : <노드 상태 평가 식> and | or <노드 상태 평가 식> ...] [\]
[rule ...] |
|---|
| 설정 항목 | 제약의 ID | 이 제약을 고유하게 식별하는 ID를 부여합니다. 영숫자 클러스터에서 고유 한 임의의 문자열을 지정합니다. |
|---|
| 리소스 ID | 제약의 대상이되는 자원을 자원 ID로 지정합니다. rule ~ 행을 여러 작성하여 1 리소스에 여러 점수 값을 설정할 수 있습니다. |
| 점수 값 | 오른쪽의 논리 연산식이 참이면 점수 값을 지정합니다. |
| 노드 상태 평가 식 | 노드 상태의 평가 식은 주로 "노드 이름의 평가"와 "속성 값의 평가」 「속성 값의 유무」의 3 패턴을 자주 사용합니다 ※.
기법은 각각 다음과 같은 형태입니다.- #uname <연산자> <값>
- 노드 이름과 <값>을 <연산자>에서 비교 · 평가합니다.
"#uname」라고하는 기술은 해당 노드의 노드 이름에 전개되고 평가됩니다.
<값>은 임의의 숫자를 비교 대상으로 지정할 수 있습니다. - <속성 값 이름> <연산자> <값>
- <속성 값 이름>으로 지정한 속성 값과 <값>을 <연산자>에서 비교 · 평가합니다.
<값>은 임의의 숫자를 비교 대상으로 지정할 수 있습니다. - defined | not_defined <속성 값 이름>
- <속성 값 이름>으로 지정한 속성 값이 정의되어 있는지 여부를 평가합니다.
defined은 해당 속성 값이 정의되어있을 때 진정한, not_defined은 정의되어 있지 않을 때 진정한입니다.
※ 날짜도 평가할 수 있지만, 여기에서는 설명을 생략합니다. 알고 싶은 분은 CRM-CLI 공식 설명서 (일본어 버전) 참조하십시오. <연산자> 에는 다음을 사용할 수 있습니다. - lt : 왼쪽이 오른쪽보다 작은 경우에 true를 만든다
- gt : 왼쪽이 오른쪽보다 크면 참이된다
- lte : 왼쪽이 오른쪽보다 작거나 같으면 참이된다
- gte : 왼쪽이 오른쪽보다 크거나 같으면 true를 만든다
- eq : 왼쪽과 오른쪽이 동일한 경우에 true를 만든다
- ne : 왼쪽과 오른쪽이 같지 않으면 true를 만든다
또한, and와 or를 사용하여 여러 논리 연산 식의 결과를 통합 할 수 있습니다. |
평가 식에서 등장하는 속성 값 은 Pacemaker가 보유하고있는 값으로 노드마다 자원의 상태와 클러스터의 상태를 나타냅니다.
상황에 따라 값이 변화하면 그 노드의 상태를 알 수 있습니다.
일반적으로 자원 에이전트가 자원의 실시간 상태를 나타내는 데 사용합니다.
예를 들어 네트워크 소통을 확인하는 자원 (ocf : pacemaker : pingd)는 네트워크가 소통하는 경우 지정한 속성 값에 값을 추가하고 소통하지 않으면 값을 뺍니다. 속성 값은 모니터마다 실시간으로 변화하기 때문에이 속성 값을 살펴보면, 지금 현재 네트워크가 소통하고 있는지를 확인할 수 있도록되어 있습니다.
또한 crm_mon 명령에 -A 옵션을 쓰면 속성 값을 표시 할 수 있습니다.
다음 부분은 그룹 grp에 대해 노드 pm01의 시작은 점수 200 노드 pm02의 시작은 점수 100을 지정합니다.
즉, grp의 시작 노드로 pm01을 우선하도록 제한하고 있습니다.
location rsc_location-1 grp \
rule 200: #uname eq pm01 \
rule 100: #uname eq pm02
이제 다음이 読み解け했습니다.
- 6. grp는 둘 중 하나의 머신에서 시작합니다. 두 컴퓨터가 실행 가능한 상태의 경우 pm01을 우선합니다.
■ colocation에서 동거하는 자원을 제약
colocation는 지정된 (여러) 자원이 동일 노드에서 시작하는 것에 대해 점수 값을 설정합니다.
colocation의 개요 대표적인 형식은 다음과 같습니다.
| 요약 | 자원과 다른 자원이 동일한 노드에 존재하는 것에 대해 점수 값을 설정합니다. |
|---|
| 서식 | colocation <제약의 ID> <점수 값> : <리소스 ID> : <역할> <리소스 ID> : <역할>] [<리소스 ID> : <역할>]] ... |
|---|
| 설정 항목 | 제약의 ID | 이 제약을 고유하게 식별하는 ID를 부여합니다. 영숫자 클러스터에서 고유 한 임의의 문자열을 지정합니다. |
|---|
| 점수 값 | 오른쪽에 기술 한 자원을 동거하는 것에 대한 점수 값을 지정합니다.
일반적으로 INFINITY를 지정 동거를 강제 또는 -INFINITY을 지정 다른 노드에서 시작을 강제합니다. |
| 리소스 ID | 제약의 대상이되는 자원을 자원 ID로 지정합니다.
왼쪽의 자원 시작할 때 오른쪽 자원이 동일한 노드에 존재하는 것에 대해 점수 값을 설정합니다.
리소스 ID를 기술하는 순서에 의미가 약간 변경에 유의하십시오.
또한 ": <역할>"와 롤을 작성할 수 있습니다. 롤은 ms 명령으로 자원을 정의 할 때 필요한 개념입니다. Master와 Slave 등의 자원 상태를 말합니다. ms 명령은 이번 기사에서는 대상으로하고 있지 않기 때문에 자세한 설명은 생략합니다. |
다음 부분은 그룹 grp의 시작시 clnResource가 동일한 노드에서 시작하는 (하고있는) 것을 강제하고 있습니다.
colocation rsc_colocation-1 INFINITY: grp clnResource
이제 다음이 読み解け했습니다.
- 7. resource3 (clnResource)가 시작되지 않은 노드에서 resource1 및 resource2 (grp)가 시작되지 않습니다.
■ order 순서를 제약
order는 지정된 (여러) 자원의 액션을 실시하는 순서 에 대해 점수 값을 설정합니다.
order의 개요 대표적인 형식은 다음과 같습니다.
| 요약 | 지정된 (여러) 자원의 액션을 실시하는 순서에 대해 점수 값을 설정합니다.
액션은 시작, 승격 등이 포함됩니다. |
|---|
| 서식 | order <제약의 ID> <점수 값> : <리소스 ID> : <액션> <리소스 ID> : <액션>] ...
[symmetrical = true | false] |
|---|
| 설정 항목 | 제약의 ID | 이 제약을 고유하게 식별하는 ID를 부여합니다. 영숫자 클러스터에서 고유 한 임의의 문자열을 지정합니다. |
|---|
| 점수 값 | 이 제약에 대한 점수 값을 지정합니다.
0보다 큰 값을 지정하면 왼쪽의 자원이 상태 변화하면 오른쪽의 리소스에 영향 (중지하거나 시작 실행)합니다 ( Mandatory Ordering ).
0을 지정하면 왼쪽 자원의 액션 실행시 이외의 상태 변화가 오른쪽 자원에 영향을주지 않습니다. ( Advisory Ordering )
조금 어려운 표현되었습니다 만, 0과 INFINITY를 설정 한 경우 다음과 같은 이미지가된다고 이해하면 좋을 것입니다.- 0 : 가급적 왼쪽 → 오른쪽으로 <액션>하기
- INFINITY : 절대 왼쪽 → 오른쪽으로 <액션>해야한다
|
| 리소스 ID | 제약의 대상이되는 자원을 자원 ID로 지정합니다.
왼쪽의 자원 시작할 때 오른쪽 자원이 동일한 노드에 존재하는 것에 대해 점수 값을 설정합니다.
리소스 ID를 기술하는 순서에 의미가 약간 변경에 유의하십시오. |
| 액션 | 액션은 대상이되는 자원을 시작 (start), 정지 (stop) 상승 (promote) 강등 (demote) 중 어느 것을 실행시 제한 여부를 지정합니다.
지정하지 않으면 기본값은 start입니다.
※ 승격 (promote) 및 강등 (demote)은 ms 명령으로 자원을 정의 할 때 필요한 개념입니다. ms 명령은 이번 기사에서는 대상으로하고 있지 않기 때문에 자세한 설명은 생략합니다. |
| symmetrical | symmetrical이 제한 역순 제약을 자동으로 설정할지 여부를 true (=) 또는 false (= 안)에서 지정합니다.
예를 들어, "시작 A → B의 순서로 수행"이라는 제약에 대해 "정지는 B → A 순으로 진행할 것"이라고 반대의 제약을 자동으로 설정할 수 있습니다.
지정하지 않으면 기본값은 true입니다. |
다음 부분은 clnResource → grp의 순서로 시작하는 것을 보여줍니다.
점수 값은 0이므로 시작 후 clnResource의 상태 변화는 grp에 영향을주지 않습니다.
symmetrical을 false로하고 있기 때문에 정지 순서는 부정입니다.
### Resource Order ###
order rsc_order-1 0: clnResource grp symmetrical=false
이제 다음이 読み解け했습니다.
- 5. resource1,2,3 자원은 반드시 resource3 (clnResource) → resource1 → resource2 순으로 시작합니다.
염려되는 분도 있을지도 모릅니다 만, 전회 소개 한 group 명령도 동거과 순서를 지정하는 것이 었습니다.
예를 들어, "group grp1 resource1 resource2"는 "resource1과 2는 반드시 동거」, 「resource1 → resource2의 순서로 시작"을 정의합니다.
group은 colocation과 order를 조합하여 재현 할 수 있습니다.
다음 페이지에서 이번 찾은 것을 응용 한 실험을 해 봅시다.
■ 실험 1 colocation 점수 값을 -INFINITY에 보면
먼저 예의 CRM 설정 에서 Pacemaker를 시작합니다.
다음과 같이 시작해야합니다.
# crm_mon -rfA
～略～
Online: [ pm01 pm02 ]
Full list of resources:
Resource Group: grp
resource1 (ocf::heartbeat:Dummy): Started pm01
resource2 (ocf::heartbeat:Dummy): Started pm01
Clone Set: clnResource
Started: [ pm01 pm02 ]
Node Attributes:
* Node pm01:
+ pm02-eth1 : up
+ pm02-eth2 : up
* Node pm02:
+ pm01-eth1 : up
+ pm01-eth2 : up
Migration summary:
* Node pm01:
* Node pm02:
다음 클러스터를 가동시킨 채로 다음 명령 colocation 점수 값을 -INFINITY에 다시 씁니다.
두 노드에서 실행해도 괜찮습니다.
# crm configure edit
→vi等のエディタが起動し、現在のCRM設定が編集可能になる。
以下部分の「inf」を「-inf」に書き換える。
colocation rsc_colocation-1 inf: grp clnResource
↓書き換え
colocation rsc_colocation-1 -inf: grp clnResource
書き換えたらエディタを保存終了する。(viの場合、Esc→:wq)
변경은 즉시 Pacemaker에 반영되어 아마 다음과 같이됩니다.
# crm_mon -rfA
～略～
Online: [ pm01 pm02 ]
Full list of resources:
Resource Group: grp
resource1 (ocf::heartbeat:Dummy): Stopped ★
resource2 (ocf::heartbeat:Dummy): Stopped ★
Clone Set: clnResource
Started: [ pm01 pm02 ]
Node Attributes:
* Node pm01:
+ pm02-eth1 : up
+ pm02-eth2 : up
* Node pm02:
+ pm01-eth1 : up
+ pm01-eth2 : up
Migration summary:
* Node pm01:
* Node pm02:
★ 부분에서 resource1,2이 정지되었음을 알 수 있습니다.
이것은 grp (= resource1,2)와 clnResource (= resource3)의 colocation 점수 값을 -INFINITY에 다시 쓴 것으로,
제약 "grp과 clnResource 절대로 다른 노드에서 시작한다 '는 의미 되었기 때문에 입니다.
clnResource는 복제를위한 두 노드에서 시작하고 그대로는이 제약을 지킬 수 없기 때문에 grp을 중단 할 수밖에 없었습니다.
이 상태에서 clnResource을 중지하면 어떻게 될까요?
다음 명령을 실행하십시오. 두 노드에서 실행해도 괜찮습니다.
# crm resource stop resource3
아마 다음과 같이되었다고 생각합니다.
# crm_mon -rfA
～略～
Online: [ pm01 pm02 ]
Full list of resources:
Resource Group: grp
resource1 (ocf::heartbeat:Dummy): Started pm01 ★
resource2 (ocf::heartbeat:Dummy): Started pm01 ★
Clone Set: clnResource
Stopped: [ resource3:0 resource3:1 ] ☆
Node Attributes:
* Node pm01:
+ pm02-eth1 : up
+ pm02-eth2 : up
* Node pm02:
+ pm01-eth1 : up
+ pm01-eth2 : up
Migration summary:
* Node pm01:
* Node pm02:
☆ 부분에서 clnResource (resource3)가 정지하고 ★ 부분에서 정지했다 resource1,2가 시작되었는지 알 수 있습니다.
clnResource를 수동으로 중지함으로써 colocation 제약으로 억제되어 있던 resource1,2가 부팅 가능하게 된 것입니다.
■ 실험 2 order 점수 값을 INFINITY에 보면
order 점수 값에 0과 INFINITY를 설정하고 0과 INIFINITY의 의미의 차이를 확인합니다.
CRM 구성은 3 개의 Dummy 자원을 order에서 순서 제약을 건 그냥 단순한 것을 사용합니다.
### Cluster Option ###
property no-quorum-policy="ignore" \
stonith-enabled="false" \
crmd-transition-delay="2s"
### Resource Defaults ###
rsc_defaults resource-stickiness="INFINITY" \
migration-threshold="1"
### Primitive Configuration ###
primitive resource1 ocf:heartbeat:Dummy \
op start interval="0s" timeout="300s" on-fail="restart" \
op monitor interval="10s" timeout="60s" on-fail="restart" \
op stop interval="0s" timeout="300s" on-fail="block"
primitive resource2 ocf:heartbeat:Dummy \
op start interval="0s" timeout="300s" on-fail="restart" \
op monitor interval="10s" timeout="60s" on-fail="restart" \
op stop interval="0s" timeout="300s" on-fail="block"
primitive resource3 ocf:heartbeat:Dummy \
op start interval="0s" timeout="300s" on-fail="restart" \
op monitor interval="10s" timeout="60s" on-fail="restart" \
op stop interval="0s" timeout="300s" on-fail="block"
### Resource Order ###
order rsc_order-1 0: resource1 resource2 resource3
2016.3.24 수정 : 이전 기사에서는 order에 "symmetrical = false"를 부여하고있었습니다 만,이 경우 Pacemaker-1.1 계에서는 다음 실험에서는 0과 INFINITY 동작의 차이가 없어졌다 (본 0 의 경우와 같은) 때문에 "symmetrical = false"를 삭제했습니다.
또한 Dummy 자원 (/usr/lib/ocf/resource.d/heartbeat/Dummy)가 시작 타이밍 (문맥)을 알기 쉽게하기 위해 start시 1 초 sleep하도록 개조하고 있습니다.
또한 order 제약 밖에 쓸 수 없기 때문에 pm01와 pm02를 동시에 시작하면 각 자원이 흩어지게 거동이 어려워집니다. 따라서 우선 pm01을 시작, 설정을 읽어 모든 자원이 pm01에서 시작하고 pm02를 시작합니다.
# crm_mon -rfA
～略～
Online: [ pm01 pm02 ]
Full list of resources:
resource1 (ocf::heartbeat:Dummy): Started pm01
resource2 (ocf::heartbeat:Dummy): Started pm01
resource3 (ocf::heartbeat:Dummy): Started pm01
Node Attributes:
* Node pm01:
+ pm02-eth1 : up
* Node pm02:
+ pm01-eth1 : up
Migration summary:
* Node pm01:
* Node pm02:
다음 명령을 실행하여 resource1 장애를 유발합니다.
# rm -f /var/run/resource-agents/Dummy-resource1.state
Pacemaker가 고장을 감지하고 F / O를 수행합니다.
# crm_mon -rfA
～略～
Online: [ pm01 pm02 ]
Full list of resources:
resource1 (ocf::heartbeat:Dummy): Started pm02 ★F/Oし、pm02で起動
resource2 (ocf::heartbeat:Dummy): Started pm01
resource3 (ocf::heartbeat:Dummy): Started pm01
Node Attributes:
* Node pm01:
+ pm02-eth1 : up
* Node pm02:
+ pm01-eth1 : up
Migration summary:
* Node pm01:
resource1: migration-threshold=1 fail-count=1
* Node pm02:
Failed actions:
resource1_monitor_10000 (node=pm01, call=52, rc=7, status=complete): not running
고장 (파일 삭제)를 발생시킨 시간 이후의 로그를 grep하여 두 노드에서 자원이 어떤 행동을했는지를 확인하자.
Pacemaker-1.0 계와 1.1 계에서 로그 형식이 다르기 때문에 다음 각각의 경우를 나타냅니다.
Pacemaker-1.0 계의 경우
○ pm01 로그
# egrep "lrmd:.*info: rsc:[A-Za-z0-9]+ (start|stop)" /var/log/ha-log
Jan 8 12:57:58 pm01 lrmd: [1518]: info: rsc:resource1 stop[53] (pid 4772)
○ PM02 の ロ グ
# egrep "lrmd:.*info: rsc:[A-Za-z0-9]+ (start|stop)" /var/log/ha-log
Jan 8 12:57:58 pm02 lrmd: [1492]: info: rsc:resource1 start[21] (pid 7667)
Pacemaker-1.1 계의 경우
○ pm01 로그
# egrep "Operation .*_(start|stop)_" /var/log/ha-log
Mar 24 10:29:51 pm01 crmd[25011]: notice: process_lrm_event: Operation resource1_stop_0: ok (node=pm01, call=21, rc=0, cib-update=72, confirmed=true)
○ PM02 の ロ グ
# egrep "Operation .*_(start|stop)_" /var/log/ha-log
Mar 24 10:29:51 pm02 crmd[6357]: notice: process_lrm_event: Operation resource1_start_0: ok (node=pm02, call=14, rc=0, cib-update=14, confirmed=true)
고장난 resource1가 pm01에서 정지 후 pm02에서 시작하고 F / O가 성공했음을 로그에서도 확인할 수있었습니다.
다음은 order 점수 값을 INFINITY로 변경하고 이전처럼 resource1 장애를 유발합니다.
order rsc_order-1 0: resource1 resource2 resource3
↓ 書 き 換 え
order rsc_order-1 INFINITY: resource1 resource2 resource3
고장 후 crm_mon는 다음과 같이 될 것입니다.
# crm_mon -rfA
～略～
Online: [ pm01 pm02 ]
Full list of resources:
resource1 (ocf::heartbeat:Dummy): Started pm02 ★F/Oし、pm02で起動
resource2 (ocf::heartbeat:Dummy): Started pm01
resource3 (ocf::heartbeat:Dummy): Started pm01
Node Attributes:
* Node pm01:
+ pm02-eth1 : up
* Node pm02:
+ pm01-eth1 : up
Migration summary:
* Node pm01:
resource1: migration-threshold=1 fail-count=1
* Node pm02:
Failed actions:
resource1_monitor_10000 (node=pm01, call=60, rc=7, status=complete): not running
점수 값이 0 일 때처럼 pm02에서 resource1가 시작 (F / O)했습니다.
그러나 약간 거동이 조금 전과는 다른 것을 깨달았다 있을까요?
crm_mon을 잘 ~보고 있던 사람은 발견 할 수도 있지만, 실은 resource2,3도 resource1 고장에 끌려 다시 시작했습니다.
로그 (/ var / log / ha-log)에서 resource1 ~ 3의 거동을 확인하려고합니다.
Pacemaker-1.0 계의 경우
○ pm01 로그
# egrep "lrmd:.*info: rsc:[:A-Za-z0-9]+ (start|stop)" /var/log/ha-log
Jan 8 13:19:02 pm01 lrmd: [1518]: info: rsc:resource3 stop[61] (pid 5848) ★
Jan 8 13:19:02 pm01 lrmd: [1518]: info: rsc:resource2 stop[62] (pid 5849) ★
Jan 8 13:19:02 pm01 lrmd: [1518]: info: rsc:resource1 stop[63] (pid 5850)
Jan 8 13:19:04 pm01 lrmd: [1518]: info: rsc:resource2 start[64] (pid 5859) ★
Jan 8 13:19:05 pm01 lrmd: [1518]: info: rsc:resource3 start[66] (pid 5869) ★
○ PM02 の ロ グ
# egrep "lrmd:.*info: rsc:[:A-Za-z0-9]+ (start|stop)" /var/log/ha-log
Jan 8 13:19:03 pm02 lrmd: [8126]: info: rsc:resource1 start[5] (pid 8154)
Pacemaker-1.1 계의 경우
○ pm01 로그
# egrep "Operation .*_(start|stop)_" /var/log/ha-log
Mar 24 10:33:11 pm01 crmd[25288]: notice: process_lrm_event: Operation resource3_stop_0: ok ～略～ ★
Mar 24 10:33:13 pm01 crmd[25288]: notice: process_lrm_event: Operation resource2_stop_0: ok ～略～ ★
Mar 24 10:33:15 pm01 crmd[25288]: notice: process_lrm_event: Operation resource1_stop_0: ok ～略～
Mar 24 10:33:19 pm01 crmd[25288]: notice: process_lrm_event: Operation resource2_start_0: ok ～略～ ★
Mar 24 10:33:21 pm01 crmd[25288]: notice: process_lrm_event: Operation resource3_start_0: ok ～略～ ★
○ PM02 の ロ グ
# egrep "Operation .*_(start|stop)_" /var/log/ha-log
Mar 24 10:33:15 pm02 crmd[6453]: notice: process_lrm_event: Operation resource1_start_0: ok (node=pm02, call=14, rc=0, cib-update=11, confirmed=true)
★ 부분에서 이전과는 달리 resource2,3도 정지 → 시작을하고 있는지 알 수 있습니다.
각각 start 한 시간을 확인하면 resource1 → resource2 → resource3 순으로 시작한 것을 알 수 있습니다.
이것은 설정 한 order 제약이
" 절대 (= INFINITY) resource1 → resource2 → resource3의 순서로 시작 / 중지해야한다"
는 것이었다 때문에 고장에 의한 상태 변화에 따라 resource2 및 resource3를 중지 → 시작하는 거동이 때문입니다.
한편 점수 값이 0 인 경우의 order 제약
"가급적 (= 0) resource1 → resource2 → resource3의 순서로 시작 / 중지 '
라는 것이며, 고장으로 인한 상태 변화는 resource2 및 resource3에 영향을주지 않았습니다.
■ 실험 3 속성 값을 평가하는
location 제약에서 속성 값을 평가 해 봅니다.
CRM 설정은 하나의 Dummy 리소스를 location으로 배치 조건을 건 그냥 단순한 것을 사용합니다.
### Cluster Option ###
property no-quorum-policy="ignore" \
stonith-enabled="false" \
crmd-transition-delay="2s"
### Resource Defaults ###
rsc_defaults resource-stickiness="INFINITY" \
migration-threshold="1"
### Primitive Configuration ###
primitive resource1 ocf:heartbeat:Dummy \
op start interval="0s" timeout="300s" on-fail="restart" \
op monitor interval="10s" timeout="60s" on-fail="restart" \
op stop interval="0s" timeout="300s" on-fail="block"
### Resource Location ###
location rsc_location-1 resource1 \
rule -INFINITY: not_defined my_attribute or my_attribute lt 100
이를 Pacemaker에 반영합니다.
하지만, 다음과 같이 resource1는 중지 된 상태가 될 것입니다 (★ 부분).
# crm_mon -rfA
～略～
Online: [ pm01 pm02 ]
Full list of resources:
resource1 (ocf::heartbeat:Dummy): Stopped ★resource1は停止したまま
Node Attributes:
* Node pm01:
+ pm02-eth1 : up
+ pm02-eth2 : up
* Node pm02:
+ pm01-eth1 : up
+ pm01-eth2 : up
Migration summary:
* Node pm01:
* Node pm02:
이것은 CRM 설정의 다음 부분에서 "my_attribute"라는 속성 값이 존재하지 않는 경우 또는 100 이하인 경우에는 시작할 수 없다고 제약하고 있기 때문입니다.
위치 rsc_location-1 리소스 1 \
규칙 무한대 : not_defined my_attribute 또는 my_attribute LT (100)
resource1를 시작하려면 다음 crm_attribute 명령으로 속성 값을 수동으로 정의합니다.
두 노드에서 실행해도 괜찮습니다.
-N 옵션에서 속성 값을 생성하는 노드를 -n으로 속성 값 이름을 -v 값을 설정합니다.
-l은 reboot 또는 forever 중 하나에서, reboot는 그 속성 값이 Pacemaker 정지로 속성치가 삭제되는 것을 나타냅니다. forever은 Pacemaker 종료 된 후에도 속성 값을 담고 있습니다.
# crm_attribute -N pm01 -n my_attribute -v 100 -l reboot
속성 값이 설정되면 resource1가 시작합니다.
# crm_mon -rfA
～略～
Online: [ pm01 pm02 ]
Full list of resources:
resource1 (ocf::heartbeat:Dummy): Started pm01 ★resource1が起動
Node Attributes:
* Node pm01:
+ my_attribute : 100 ★属性値が100で設定された
+ pm02-eth1 : up
+ pm02-eth2 : up
* Node pm02:
+ pm01-eth1 : up
+ pm01-eth2 : up
Migration summary:
* Node pm01:
* Node pm02:
속성 값의 값을 10으로 변경하려고합니다.
# crm_attribute -N pm01 -n my_attribute -v 10 -l reboot
resource1가 중지 생각합니다.
# crm_mon -rfA
～略～
Online: [ pm01 pm02 ]
Full list of resources:
resource1 (ocf::heartbeat:Dummy): Stopped ★resource1が停止
Node Attributes:
* Node pm01:
+ my_attribute : 10 ★属性値が10に変更
+ pm02-eth1 : up
+ pm02-eth2 : up
* Node pm02:
+ pm01-eth1 : up
+ pm01-eth2 : up
Migration summary:
* Node pm01:
* Node pm02:
또한, 실제로 본 실험과 같이 속성 값을 수동으로 설정하거나 변경하는 경우는 거의없고, NW 감시 (ocf : pacemaker : pingd)과 디스크 모니터링 (ocf : pacemaker : diskd)가 내부적으로 사용 하고 있습니다.
■ お わ り に
3 회에 걸친 "움직여 이해 Pacemaker - CRM 설정 편 ~」은 이번으로 끝입니다.
끝까지 읽어 주신 분은 예제 설정 파일 은 물론, 데모 환경의 CRM 설정 파일 도 읽을 수있게되어 있다고 생각합니다.
