* 클러스터 리소스 관리하기
클러스터 관리자로서 필요에 따라 리소스와 리소스 그룹을 start/stop, 이동 등을 수행한다. 또한 클러스터의 특정 리소스/리소스 그룹을 특정 노드에 대하여 임시로 마이그레이션을 제한하거나, 현재 실행중인 노드가 아닌 다른 노드로 이동시키거나, 리소스가 특정 노드로 다시 마이그레이션 하는 것들을 컨트롤할 수 있다. 이러한 컨트롤은 특정 클러스터 노드 유지보수시 필요하며, 클러스터 운영에 수동으로 개입하여 서비스 이동을 가능한 줄임으로서 서비스 다운타임을 최소화 할 수 있다.
* 클러스터 리소스 활성화/비활성화 하기
클러스터 리소스/리소스그룹을 실행되지 않도록 또는 실행되도록 컨트롤한다.
리소스 disable / enable 개념
리소스 disable : 해당 리소스를 멈추고 다시 시작하지 않도록 한다.
리소스 enable : 클러스터가 해당 리소스를 시작할 수 있게 한다.
리소스 disable/enable 예시
원래 아래와 같이 리소스가 수행중이다.
아래 명령으로 firstweb 리소스를 disable 수행한다.
상태를 보면 stopped 된 것을 알 수 있다.
constraint에서는 따로 설정된 제한은 없다.
다시 아래 명령으로 firstweb 리소스를 enable 수행한다.
정상적으로 리소스가 시작된다. (시작되는 위치는 클러스터마다 다를 수 있다. 이것은 by design 이다.)
* 클러스터 리소스 이동하기
리소스 move 의 개념
리소스/리소스 그룹은 현재 실행중인 노드에서 다른 노드로 이동할 수 있다. 이동할 노드를 명시하면 해당 노드로 이동할 수 있다. 노드를 명시하지 않으면 가장 적절한 노드로 자동으로 이동한다. 일반적으로 클러스터의 특정 노드 유지보수를 위해 사용할 수 있다. 아래와 같이 실행하면 해당 myresource는 node2.example.com 노드로 이동하게 된다.
이 명령은 아직 배우지 않았지만 리소스를 "이동"시키는게 아니라 constraint 라는 것을 적용하여 이동 "되게" 만드는 것이다. 이동할 노드를 명시하지 않는 경우, 현재 리소스가 있는 노드에 임시 disable 규칙을 적용하여 해당 리소스가 다른 노드로 이동"되게" 만든다. 또한, The move command with a target creates for the original node a Enable rule.
리소스 move 예시
원래 firstweb은 nodea에 있었다. 아래와 같이 명령을 수행해서 이동시킨다.
상태를 보면 nodeb 로 이동한 것을 알 수 있다. (다른 노드로 갈 수도 있다)
constraint를 상세히 보면, firstweb 리소스는 nodea에 대하여 disable 이 된 것을 확인할 수 있다. (nodea에서 disable되었으니 자연히 다른 노드로 이동한다)
* 클러스터 리소스 마이그레이션 제한하기
특정 클러스터 노드에 리소스가 마이그레이션 되지 않도록 막기 위해 "pcs resource ban 리소스명" 명령을 사용할 수 있다. 이 명령은 해당 리소스가 실행되고 있는 노드에서 실행되지 못하게 만든다. 또한 리소스명 뒤에 특정 노드를 입력하면, 해당 리소스가 특정 노드로 마이그레이션 되는것을 막는다. 아래처럼 수행할 수 있다.
이 명령도 move 와 마찬가지로 임시 constraint 규칙을 만드는 것이다. 해당 명령을 수행 후 pcs constraint list 명령으로 새로 생성된constraint 규칙을 확인할 수 있다. 아래 예시에서 myresourcegroup은 node2.example.com에 대하여 ban 된 상태를 알 수 있다.
* 임시 리소스 제한 제거하기
move, ban 명령으로 인해 생성된 임시 constraint는 클러스터 동작에 영향을 주므로 제거가 필요할 수 있다. 기본적으로 다음과 같은 명령을 사용한다. "pcs resource clear 리소스명" 또한 특정 클러스터 노드에 지정된 리소스에 대한 임시 constraint를 제거하기 위해 노드명 파라미터를 추가할 수 있다. 또한 이 명령어는 pcs constraint 로 설정한 location constraint 에는 영향을 주지 않는다. (임시constraint 만 클리어한다)
예를 들어 node2에 있는 myresource 리소스에 대한 금지 제한을 해제하려면 다음을 실행하면 된다.
예시 - 임시 constraint 클리어 수행하기
위의 "리소스 move 예시" 에서 move 를 수행하여 생성된 constraint 를 삭제해보자.
다시 constraint 리스트를 보면 삭제된 것이 확인된다.
다시 리소스 상태를 보면, 이동했던 nodeb에서 변함없이 잘 실행되고 있는것을 확인할 수 있다.
* constraint 란?
High Availability Add-on에는 3가지 종류의 constraint가 있다. order / location / co-location 이 3가지이며, order는 리소스가 시작/중지되는 순서를 정의하며, location은 리소스가 배치될/배치되지 않을 위치를 정의한다. 그리고 co-location은 두가지의 리소스의 관계를 가지고 리소스 배치를 정의한다. 예를 들어, 특정 두 리소스가 항상 서로 같은 노드에 배치되어야 한다면 co-location constraint를 정의해야 한다. 또 다른 예시로, 어떤 리소스가 가능한한 특정 노드에서만 실행되도록 하고 싶을 수 있다. 이러한 경우 location constraint를 사용할 수 있다.
리소스 그룹은 명시적으로 리소스에 constraint를 지정하지 않고 자연스럽게 constraint를 세팅하는 가장 쉬운 방법이다. 리소스 그룹 안에 모든 리소스들은 내부적으로 서로 co-location constraint를 가진다. 즉 리소스들은 같은 노드에 있어야만 한다. 또한 리소스 그룹 안에 있는 멤버 리소스들은 서로 order constraint 를 가진다. 리소스그룹 내부에서 리소스가 생성된 순서대로 시작/중지하기 때문이다. 또한 리소스 그룹에 포함된 리소스 각각에 constraint를 설정하면 안되고, 리소스 그룹 전체에 constraint를 적용해야 한다.
3가지 각각의 constraint는 고유의 기능과 특성을 가지며, 서로 모두 완전히 다르다. 따라서 각각 개념을 잘 이해해야 한다.
* order constraint
order constraint 는 리소스가 실행되는 순서를 지정한다. 예를들어, 데이터베이스에 액세스하는 리소스는 데이터베이스 리소스가 먼저 올라와야만 사용이 가능하다.
pcs constraint order 설정하기
위와 같이 구성하면, 아래와 같은 효과가 발생한다.
- 만약 리소스 둘다 stop 된 경우, A가 시작되어야만 B도 시작 가능하다.
- 만약 리소스 둘다 실행중인 상태에서, A가 pcs에 의해 disable되는 경우, 클러스터는 A가 stop되기 전에 B를 stop시킨다.
- 만약 리소스 둘다 실행중이고, A가 restart되면, 클러스터는 또한 B도 리스타트한다.
- 만약 리소스 A가 실행되지 않고 있고, 클러스터가 A를 start 할 수 없는경우, B는 stop 된다. 예를 들어 첫 번째 리소스가 잘못 구성되었거나 손상된 경우 이러한 문제가 발생할 수 있다.
* colocation constraint
colocation constraint 는 두개의 리소스가 동일 노드에서 실행되어야만한다(실행되면 절대 안된다) 를 명시한다.
두 리소스/그룹이 동일한 노드에서 꼭 실행되도록 하기
아래 예시는 두개의 리소스/리소스그룹 (A,B)가 서로 함께 실행되게 한다.
Pacemaker는 A먼저 어디 노드에 있어야 할지 체크하고, 그 후에만 B가, 확인된 그곳(A가 있을 곳) 에 위치할 수 있는지 여부를 결정한다. A와 B의 시작은 병렬로 이루어지며, A,B 둘다 실행할 수 있는 위치가 없는 경우 A가 우선권을 가지며 B는 중지된 상태로 유지된다. 만약A가 실행할 위치가 없으면, B도 실행할 곳이 없다.
두 리소스/그룹이 절대 동일한 노드에서 실행되지 않도록 하기
아래 예시는 두개의 리소스/리소스그룹 (A,B)가 서로 함께 실행되지 않도록 한다.
colocation 예시
아래와 같이 nfs와 firstweb 두 리소스 그룹이 있다.
두 그룹을 아래와 같이 코로케이션 하면, nfs가 먼저 실행되고 그 뒤에 firstweb이 실행된다.
constraint 상태를 보면 다음과 같다. 이제 두 그룹은 항상 동일 노드에서 실행된다.
아래와 같이 nfs가 있는 nodea 로 firstweb이 넘어간 것을 확인할 수 있다.
* location constraint
클러스터는 다른 설정이나 constraint가 적용된 것이 없다면 클러스터 전체에 걸쳐 리소스를 고르게 분산시키려고 한다. location constraint는 리소스/리소스그룹이 실행할 노드 위치를 컨트롤할 수 있다. 리소스에 적용된 location constraint는 해당 리소스가 특정 노드/노드들을 선호/비선호하게 만든다.
location constraint의 score
location constraint는 여러 노드중 어떤 노드에 배치될지 결정하기 위해 score 라는 개념을 가진다. 이 score에 따라서 노드를 선호할지, 피할지를 결정한다. 스코어와 효과는 다음과 같다.
INFINITY : 이 리소스는 여기서 실행되어야만 한다 (must)
양수 또는 0 (ex : 10) : 이 리소스는 여기서 실행되어야 한다. (should)
음수 (ex : -5) : 리소스는 여기서 실행되지 않아야 한다. 클러스터는 이 노드를 피한다. (should)
-INFINITY : 이 리소스는 절대 여기서 실행되면 안된다. (must)
리소스는 숫자끼리 경합할 때 가장 높은 score인 노드에 올라간다. 만약 여러 노드가 동일한 score를 가진다면 (예를들어, 둘다INFINITY 인 경우), 그때는 클러스터가 그 중 하나의 노드를 선택해 실행한다. 일반적으로 클러스터는 리소스가 없는 노드를 선호한다. 여러 노드가 서로 다른 점수를 가지는 경우, 그때 클러스터 리소스/리소스그룹은 가장 높은 점수를 가진 노드에서 실행된다. 또한 충분히 높은 점수를 가진 노드를 찾을 수 없는경우, 리소스는 stopped 상태로 남는다.
만약 여러개의 constraint나 스코어가 적용되는 경우, 그것들을 모두 합산해서 총점을 적용한다. 만약 INFINITY에 -INFINITY 를 더하면 결과는 -INFINITY가 된다. (즉 리소스가 항상 노드를 피해야 한다는 constraint가 있다면, 이 constraint가 이긴다)
또한, score를 통해 리소스가 올라갈 노드가 선택이 되었다 하더라도, 또한 colocation constraint도 고려된다. 예를들어, 만약 리소스 A가 리소스 B와 함께 있어야 하고, B는 노드1에서만 실행될 수 있는 경우, 리소스A가 노드2를 선호하는것은 영향이 없다. 리소스A는 B를 따라 노드1에서 실행되게 된다.
현재 score 확인 명령 - crm_simulate -sL
location constraint 선호 설정하기
이 명령은 리소스 또는 리소스 그룹인 A가 해당 node에 실행될 수 있도록 INFINITY 스코어를 가지게 한다. 다른 location constraint가 없다면, 이 설정은 A가 항상 해당 node에서 실행되도록 강제한다. 그게 안되면 클러스터의 다른 노드에서 실행하도록 한다.
A에 대하여 node에 500점 score 주기
location constraint 비선호 설정하기
이렇게 하면 -INFINITY 값을 주게 되며, A에 대하여 해당 node를 가능한 피하게 한다. 즉 가능한 다른 노드에서 A가 실행된다. 만약 다른 노드들중 어떠한것도 사용가능한 노드가 없다면, 리소스는 시작하지 못한다.
단순히 perfer, avoid 설정이나, 스코어를 주는 설정 모두 이러한 변경사항은 즉시 적용되며, 필요한 경우 리소스 이동이 이루어지므로 다운타임에 조심해야 한다.
stickiness 설정
클러스터는 기본적으로 리소스를 이동할 때 비용이 들지 않는다고 가정한다. 따라서 만약 더 높은 스코어의 노드가 사용가능해지면, 클러스터는 리소스를 해당 노드로 재배치한다. 그런데 리소스 이동은 리소스를 내렸다 올리게 되므로 일시적으로 다운타임이 발생하며, 실제 엔터프라이즈 운영에서는 잠깐의 다운타임이라도 아주 큰 영향을 줄 수 있다. 또한 리소스 종류에 따라 재배치에 시간이 많이 걸릴수도 있는데, 이러면 더 영향이 크다. stickiness 설정은 필요하지 않은 리소스 재배치를 피할때 사용한다.
default resource stickiness는 리소스가 현재 실행중인 노드에게 점수를 설정하여 리소스 재배치를 피하게 만든다. (문맥상 최초 실행할때는 하지 않고, 그 다음 실행중인 노드에 점수를 설정한다는 것이다)
예를들어, resource stickiness가 1000으로 세팅되어 있고, 리소스가 선호하는 노드의 location constraint 스코어는 500이라고 하자.
리소스가 시작되면, 리소스는 선호하는 노드에서 실행된다. 만약 선호하는 노드에 장애가 생기는 경우, 그때 리소스는 다른 노드로 이동할 것이다. 그리고 리소스가 이동한 그 노드는 새로운 스코어 1000을 얻는다.
선호하는 노드가 다시 정상화 되었을 때, 선호하는 노드의 스코어는 500이므로 해당 리소스는 선호하는 노드로 돌아가지 않는다.
이제 클러스터 관리자는 편한 시간 (계획된 다운타임 기간 등)에 선호하는 노드로 리소스를 수동 재배치 하면 된다.
default resource stickiness 1000 으로 설정하기
default resource stickiness 설정값을 없애기
리소스 그룹을 위한 리소스 stickiness 는 이 그룹에 실행되고 있는 리소스가 몇개인지 개수에 기반해서 계산된다. 만약 리소스 그룹이 5개의 활성화된 리소스를 가지고 있고 리소스 stickiness가 1000이라면, 그 리소스 그룹의 유효 점수는 5000점을 가진다.
stickiness 설정 보기 (현재 리소스 디폴트 값들 보기)
stickiness 예시
현재 firstweb은 nodeb에서 실행중이다. 따로 score는 없는 상태이다. 이 상태에서 firstweb의 location constraint를 nodea 에서 선호하도록 200 점을 준다.
위 명령 후 firstweb은 nodeb에서 nodea로 이동한다. default resource stickiness 는 0이고 이 값보다 nodea 의 200점이 더 높기 때문이다.
default resource stickiness를 500으로 변경한다.
firstweb에 대하여 nodeb에다 499점을 준다.
리소스 그룹은 바뀌지 않는다.
stickiness 는 원래 prefer 값 (nodea의 200점)에 더하는 게 아니라 stickiness 값 자체가 되는 것으로 보인다. 즉 nodea는 200점, nodeb는 499점인데 stickiness 때문에 nodea가 500이 되고 nodeb는 499로 이기지 못해 리소스 이동이 발생하지 않는 것이다.
* Constraint 관리 명령
constraint 상태 확인하기
pcs constraint list --full
constraint 제거하기
pcs constraint delete id (id는 위에서 나온 결과의 id 부분이다)
* References
pcs(8) and crm_simulate(8) man pages
For more information, refer to the Managing cluster resources, Displaying resource constraints, and Performing cluster maintenance chapters in the Configuring and managing high availability clusters guide at
For more information, refer to the Determining which nodes a resource can run
on, Determining the order in which cluster resources are run, Colocating cluster resources, and Displaying resource constraints chapters in the Configuring and managing high availability clusters guide at
'High Availability > RH436 & EX436' 카테고리의 다른 글
| [RH436/EX436] 6. iSCSI 연결 (1) | 2024.02.06 |
|---|---|
| [RH436/EX436] 5. 클러스터 관리 (0) | 2024.02.06 |
| [RH436/EX436] 3. 리소스 - 리소스 개념 (0) | 2024.02.03 |
| [RH436/EX436] 2. Fencing (1) | 2024.02.03 |
| [RH436/EX436] 1. 클러스터 개념 및 기본클러스터 구성 (0) | 2024.02.03 |