RHEL High Availability Cluster Add-on 은 클러스터 노드 멤버쉽을 컨트롤하기 위한 여러가지 방법을 제공한다. systemd 는 클러스터에 조인되고 클러스터의 한 부분이 되기 위해 클러스터 노드에서 꼭 실행되어야 하는 클러스터 서비스인 corosync 와 pacemaker를관리한다. pcsd가 실행되는 인증받은 노드에서, 클러스터 서비스는 pcs로 컨트롤된다. pcs 명령으로 클러스터를 관리할 수 있다.
* 클러스터 시작/중지하기
pcs cluster start / pcs cluster stop 명령은 클러스터를 각각 시작/중지한다. 이 명령은 명령이 실행되는 해당 노드에서 적용되며, 다른노드는 파라미터로 따로 정보를 주거나, --all로 전체노드를 대상으로 한다. pcs cluster start --all / stop --all 이것은 해당 명령을 치는 노드와 동일한 클러스터에 있는 모든 노드를 시작/중지한다.
단일 클러스터 서비스 시작하기
전체 클러스터 서비스 중지하기
* 클러스터 서비스 enable / disable 하기
pcs cluster enable / disable명령은 systemd로 관리되는 corosync와 pacemaker 두 클러스터 서비스를, 노드가 부팅되었을 때 자동으로 실행할지 말지를 결정한다. enable 하면, 리부팅시 자동으로 클러스터 서비스가 올라가서 클러스터에 조인된다. 두 명령어 모두 해당명령어를 친 노드만 적용되며, 다른 노드를 하려면 파라미터를 줘야하며, 모든 노드도 마찬가지로 파라미터를 줘야한다.
해당 노드에서 enable 수행
특정 노드 enable 수행
모든 노드 enable 수행
* 클러스터 노드를 추가하고 빼기
RHEL High Availability Cluster Add-on 은 클러스터 노드를 즉시 넣을수도, 뺼수도 있다. 이것은 클러스터 내에서 서비스 다운타임 없이 클러스터를 확장하거나, 노드를 교체할 수 있다는 것이다.
클러스터에 새로운 노드 넣기
새로운 노드가 조인되도록 해당 새로운 노드에 다음과 같은 설정이 필요하다. 방화벽 설정 / 펜스 설정 / pcsd 시작 및 enable / hacluster 패스워드 설정 (현재 존재하는 노드와 일치해야 함) 이 4가지 설정 후 아래 절차를 통해 클러스터에 해당 노드를 조인한다.
1. 노드 인증
pcs host auth node.fqdn 명령 사용, 원래 있던 클러스터 노드 사이의 인증.
2. 클러스터에 노드 추가
아래 명령은 현재 클러스터 안에 있는 노드에서 해야하며 정상상태여야 한다.
3. 클러스터 시작 및 enable
노드가 성공적으로 추가되고 인증되면, 시스템 관리자는 새 노드에서 클러스터 서비스를 시작하고 enable한다. 서비스가 이 새로운 노드에 올라가기 전에, 펜싱도 꼭 구성하고 정상작동하도록 해야한다. pcs cluster start node4.example.com / pcs cluster enable node4.example.com 이 명령어가 사용되지 않는 한 새로운 노드는 클러스터의 활성화된 멤버가 되지 않는다.
클러스터에서 노드 제거하기
pcs cluster node remove node.fqdn 명령을 사용하여 노드를 영구적으로 제거할 수 있다. 이 기능은 실제로 클러스터에 노드가 필요하지 않거나, 클러스터 노드를 새 하드웨어로 변경하는 경우 사용한다.
1. 노드 제거
아래 명령은 클러스터 내에 있는 정상 상태의 노드에서 사용해야 하며, 제거될 노드에서 사용하면 안된다.
2. 해당 노드의 펜스 제거
노드가 제거되었기 때문에, 해당 노드의 전용 펜스 장치를 제거하거나 해당 노드가 포함된 공유 펜스 장치를 재구성해야 한다. 아래 예시는해당 노드의 전용 펜스를 제거하는 예시이다.
* 클러스터 노드가 리소스를 실행 하는것을 금지하기
관리자가 일반 클러스터 운영을 중단하지 않고 클러스터 노드의 리소스 실행을 일시적으로 중단해야 하는 경우가 있다. 첫번째로 노드별작업이 필요할 때가 있다. 예를 들어 실행된 노드에 중요한 보안 업데이트를 적용해야 할 때 이러한 상황이 발생할 수 있다. 노드별로standby 모드 전환한 후 업데이트를 적용할 수 있으므로 다운타임을 줄일 수 있다. 두번째로는 리소스 마이그레이션 테스트가 있다. 노드가 standby 모드로 전환되면 리소스가 할당되지 않는다. 현재 노드에서 실행 중인 리소스는 다른 노드로 마이그레이션을 진행하게 된다.
pcs node standby/unstandby 명령은 해당 명령이 실행되는 노드를 standby모드로 만든다. 다른 노드도 인수로 주거나, --all옵션으로전체를 할 수 있다.
standby 모드는 해당 노드에 resource constraint 가 세팅되는것이고, pcs cluster unstandby는 해당 resource constraint 를 삭제하는 것이다. resource constraint를 제거한다고 하여, 해당 노드가 원래 standby전에 리소스가 있었다면 그게 반드시 다시 마이그레이션되는것은 아니다. (원래 리소스가 원복되는것이 아니라 변경 없이 그대로 있게 된다)
* 클러스터 상태 보기
클러스터 상태, corosync 상태, 구성된 리소스 그룹, 리소스, 클러스터 노드 상태는 pcs status 로 본다. 아래 명령어들로 특정 일부만 볼수도 있다. 또한 pcs status --full 모든 전체값을 확인할 수 있다.
pcs status cluster : 클러스터 상태만 확인
pcs status resources : 리소스 그룹과 각각의 리소스들만 확인
pcs status nodes : 구성된 클러스터 노드만 확인
pcs status corosync : corosync 상태만 확인
pcs status pcsd : 모든 구성된 클러스터 노드의 pcsd 상태만 확인
1. node3.example.com 은 현재 스탠바이 모드이다.
2. node1.example.com / node2.example.com 은 현재 완전히 작동중이다.
3. node4.example.com 은 현재 오프라인이다. 클러스터 서비스 두개가 멈춰있거나, 클러스터의 Quorum 문제가 있을 수 있다.
* References
pcs(8), corosync(8), and pacemaker(8) man pages
For more information, refer to the Managing cluster nodes chapter in the Configuring and managing high availability clusters at
클러스터 관리자로서 필요에 따라 리소스와 리소스 그룹을 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
어떠한 서비스는 하나 이상의 리소스로 이루어진다. 리소스는 IP주소, 파일시스템, httpd같은 서비스 등 여러가지가 있다. 사용자에게 서비스를 제공하는데 필요한 가장 작은 구성요소들을 의미한다. 클러스터에서는 이러한 리소스를 직접 실행하거나 중지시키고, 상태를 모니터링한다. 클러스터가 전담하여 이러한 역할을 수행한다.
* 리소스를 실행하는 방식
리소스 실행 방식은 총 3가지가 있다. (LSB, OCF, systemd) 클러스터 관리자는 클러스터 소프트웨어가 어떤 시스템 서비스를 지원하는지 이해하는 것이 중요하다. 서비스 구성 시 최대한의 구성 용이성을 가진 ocf 스크립트를 통해 클러스터가직접 서비스를 지원하는 것이 이상적이다. ocf로 다이렉트 서비스가 안되는 경우, systemd나 lsb 를 쓸 수 있다.
LSB (Linux Standard Base)
/etc/init.d/ 에 들어가는 init 스크립트와 호환되는 LSB 이다. 간단하게 말하면 스크립트로 서비스를 만드는 것이다.
OCF (Open CLuster Framework)
클러스터 리소스에 대한 추가 제어를 제공하기 위해 추가 입력 매개변수를 처리할 수 있는 확장된 LSB init 스크립트인 오픈 클러스터 프레임워크 호환 스크립트이다. /user/lib/ocf/resource.d/provider 에 파일들이 있다. 클러스터에서 여러가지 리소스들을 쉽게 사용하도록 구성한 것이다. 일반적으로 이 형식의 리소스를 가장 많이 사용한다.
systemd
레드햇8에서 서비스를 관리하고 정의하기 위한 표준인 systemd 유닛 파일이다. 이것으로도 리소스를 만들 수 있다.
* 자주 사용하는 리소스 종류
filesystem
파일시스템을 마운트할 때 사용한다. 로컬 파일시스템이 될 수 있고, iscsi나 fc 또는 nfs, smb 등이 가능하다.
ipaddr2
ipaddr2는 유동아이피를 할당한다. 참고로 ipaddr 도 있었는데, 이전에 쓰던아이피 할당 방법이다. 레드햇8에서는, ipaddr은 심볼릭 링크로 ipaddr2에 연결되어 있다.
apache
apache httpd 서비스를 시작하는 리소스이다. 따로 설정하지 않으면, /etc/httpd의 구성을 사용한다.
mysql
이 리소스는 mysql 데이터베이스를 컨트롤한다. stand-alone 운영 / a clone set with external replication / full primary/secondary setup 3가지 방식으로 데이터베이스를 구성할 수 있다.
* 리소스 에이전트
Redhat High Availability 애드온은 클러스터 리소스를 위한 광범위한 지원을 제공한다. 클러스터 리소스들은 agents라고 부르는 스크립트에 의해 관리된다. agents 들은 클러스터 리소스에 대하여 start/stop/monitor 3가지를 하는데 필요하다.
사용가능한 에이전트 리스트 보기 (pcs resource list)
리소스 에이전트 상세정보 보기 (pcs resource describe 에이전트명 --full)
모든 resource agent들은 튜닝할 수 있는 파라미터들을 제공한다. 이 명령은 해당 클러스터 리소스의 설명과 튜닝할 수 있는 파라미터의 정보를 보여준다.
* 리소스 그룹
일반적으로 실제 클라이언트가 사용하는 서비스는 하나의 리소스로 이루어지지 않는다. 이러한 서비스 단위로 묶어놓은 리소스들을 리소스 그룹이라고 한다. 예를 들어 일반적인 웹 서비스는 IP 주소 리소스, Apache 리소스, 웹 서버의 DocumentRoot 폴더에 대한 공유 파일 시스템 리소스로 구성됩니다.
모든 웹 서비스 리소스가 동일한 클러스터 노드에서 실행되어야 제대로 작동하는 서비스를 제공할 수 있습니다. 이러한 리소스를 함께 묶는 편리한 방법은 동일한 리소스 그룹에 추가하는 것입니다. 동일한 리소스 그룹에 있는 모든 서비스는 리소스 그룹에 추가되는 순서대로 시작되고 역순으로 중지됩니다. 클러스터 노드에 장애가 발생하면 클러스터는 전체 리소스 그룹을 다른 노드로 마이그레이션하고 새 노드에서 리소스를 시작합니다.
예를들어 웹 서비스를 하려고 하는데, 3노드 클러스터에서 ip는 노드1에, 파일시스템은 노드2에, httpd 서비스는 노드3에 있다면 서비스가 성립되지 않는다. 리소스 그룹은 이러한 용도에 따른 리소스들을 한데 모아 한번에 한 노드에서 start/stop 하게 한다. 또한 그룹 안에서는 그룹 안의리소스 순서대로 start/stop 하게 한다.
또한 어떤 경우에는, 리소스 그룹안에 들어간 리소스들끼리 디펜던시가 있는 경우가 있다. 예를 들어 특정 IP 주소에서 수신 대기하도록 구성된 웹 서버는 노드에서 IP 주소를 구성할 때까지 시작할 수 없다. 즉 VIP리소스가 먼저 시작되어야 웹서버 리소스가 시작하게 된다. 일반적으로 리소스는 그룹에 추가되는 순서대로 시작되고, 중지될때는 역순으로 중지된다. 이러한 순서를 컨트롤하기 위해 리소스 생성/추가시 --before resourceid / --after resourceid 를 사용하여 특정 리소스의 전에 또는 후에 리소스를 등록할 수 있다. (리소스 생성 및 추가는 아래 참고)
리소스는 생성된 순서대로 배치되며, 그룹을 명시하면 그룹에 순서대로 들어간다. 이 순서는 리소스 시작/종료에 아주 중요한 부분으로, 운영에 큰 영향을 준다. 따라서 순서를 잘 확인해야 한다. 또한 리소스 그룹에 속하지 않는 리소스를 생성하려면 그룹 옵션은 생략하면 된다.
또한 리소스를 생성할 때는 해당 리소스에 대한 액세스 권한이나, 기본적으로 필요한 것들이 있어야 한다. 예를들어, apache 리소스를 올리려면 httpd 패키지가 설치되어 있어야 하고 방화벽이 해제되어야 한다.
예시 : filesystem 리소스 생성하기
myfs라는 이름을 가진 리소스이며, 디스크 장치는 /dev/sdb1, 마운트 포인트는 /var/www/html 이고 파일시스템 형식은 xfs 이다.
리소스 수정하기
pcs resource update
이미 생성된 클러스터 리소스의 값을 수정하거나 옵션을 변경할 수 있다. 아래 예시를 참고한다.
예시 : 이미 생성된 myfs 리소스의 장치를 /dev/sda1로 변경
리소스 삭제하기
pcs resource delete
더이상 필요하지 않은 경우 리소스 및 리소스 그룹 구성을 제거할 수 있다. 리소스명 또는 리소스그룹명을 명시하여 삭제할 수 있다.
예시 : 리소스 myfs 삭제
* 리소스 동작
리소스는 시작할때, 중지할때, 모니터링할때 3가지의 동작이 있으며, 이 동작들에 대한 주기(interval)과 타임아웃(timeout)이 있다. 주기는 모니터링에만 사용하며, 해당 주기마다 모니터링을 실행한다. 또한 타임아웃은 3가지 동작 모두 적용되며, 해당 타임아웃 시간까지 시작/중지/모니터링이 성공하지 않는경우 문제라고 간주하고 재시작, fence 등을 수행하게 된다.
이러한 주기와 타임아웃값들은 튜닝이 가능하며, 리소스 생성시 명시하여 설정할 수 있다. 형식은 아래 예시와 같다. webserver 라는 리소스를 monitor interval 20 초, timeout을 30초로 주어 생성할 때, 아래처럼 한다.
리소스 동작 값을 넣을 때는 op 로 시작하며, op monitor/start/stop interval= timeout= 이런식으로 명시한다. 다른 예시로, op monitor interval=20s timeout=30s start timeout=60s stop timeout=120s 이런식으로 사용할 수 있다.
시작 타임아웃을120초로 하고,모니터 인터벌을 30초로 하고, 모니터가 fail되면 fence 한다.
만약 리소스가 start 하는데 fail 된 경우, 그때는 리소스의 failcount가 INFINITY 로 세팅되어 해당 노드에서 리소스가 영원히 실행되지 않도록 막는다. 존재하는 failcount값은 pcs resource failcount show 로 확인이 가능하다. fail의 원인을 트러블슈팅하기위해, [pcs resource debug-start 리소스명] 을 사용하면 리소스 시작 시도의 오류 메시지를 표시하여 해당 부분을살펴보고 문제를 복구할 수 있다. 리소스가 복구되면, [pcs resource cleanup 리소스명] 을 사용하여 해당 리소스의Failcount를 리셋시켜야 해당 노드에서 해당 리소스가 다시 시작할 수 있다.
* 리소스 동작값의 추가 / 제거
리소스 동작값 추가
리소스의 operation은 pcs resource op add 명령으로 추가할 수 있다. 예를들어, 현재 있는 webserver 리소스에다가 모니터링 인터벌 10초, 모니터링 타임아웃 15 초, 그리고 모니터링이 fail되면 펜스시키는 옵션을 주는 경우, 아래처럼 한다.
리소스 동작값의 제거
pcs resource op remove 명령으로 제거할 수 있다. 아래처럼 webserver 리소스에서 op 값을 제거한다.
* 리소스 그룹 생성 예시 : 웹 서비스
클러스터된 웹 서비스는 3가지의 리소스를 요구한다.
1. Virtual IP : 퍼블릭 네트워크를 통해 아파치 웹서버에 의해 서비스되는 컨텐츠에 접속할 수 있도록 함. 각 노드들은 정해진 ip를 가지지만, 이 ip를 서비스 운영에 사용하면 노드가 죽었을 때 접속하지 못하는 문제가 발생한다. 이를 막기위해 노드 간 이동하는 대표 Virtual IP가 필요하다.
2. 파일시스템 : 아파치 웹서버에 의해 저장된 데이터들. (이론적으로는 모든 노드에 모든 웹 콘텐츠를 보유하는 것도 가능하지만 콘텐츠를 동기화하는 메커니즘이 필요합니다.)
3. apache 리소스 : httpd 서비스를 제공
1. Virtual IP
첫번째로 VIP가 필요하다. 아래와 같이 VIP를 생성한다. 당연히 해당 IP는 각 노드들의 네트워크 장치가 접근 가능한 대역으로 설정해야 한다.
2. 공유 스토리지
# 중요
클러스터 노드에서 SELinux를 활성화한 경우, 클러스터 관리자는 마운트된 파일 시스템의 콘텐츠를 관련 데몬에서 사용할 수 있는지 확인해야 합니다. 또한 block device 의 경우 적절한 SELinux 컨텍스트를 설정해야 하며, NFS의 경우 관련 SELinux booleans, (예: httpd_use_nfs=1)을 설정해야 합니다.
3.웹 서비스
홈페이지 파일을 서비스하는 apache (httpd) 리소스를 생성해야 한다. 이를 위해 httpd 패키지 설치가 필요하며 방화벽 해제도 필요하다. 또한 /var/www/html에 index.html 파일도 필요하다.
위와 같이 생성 후, curl 172.25.99.80 명령을 수행하면 index.html 파일을 읽어올 수 있다.
* 리소스 그룹에 리소스 추가/제거
리소스를 리소스 그룹에 추가하기
현재 존재하는 리소스는 리소스 그룹에 추가될 수 있다. 클러스터 관리자는 pcs resource group add groupname resourcename 명령으로 추가할 수 있다. 만약 해당 리소스가 이미 다른 그룹의 멤버라면, 위 명령어를 쳤을 때 현재 그룹에서 빠지고 명령어에 명시된 그룹에 추가되게 된다. 명시한 그룹이 없는 그룹이라면, 자동으로 그룹을 만들게 된다.
예시 : myresource 라는 리소스를 mygroup 에다 추가하려면 아래처럼 한다.
리소스를 리소스 그룹에서 제거하기
pcs resource group remove groupname resourcename 명령으로 리소스를 리소스 그룹에서 제거할 수 있다. 해당 리소스는 여전히 클러스터에 존재하지만, 해당 리소스 그룹에서는 빠지게 된다. 만약 리소스 그룹에 하나만 남은 리소스를 제거하면, 해당 리소스 그룹도 없어지게 된다.
예시 : myresource 라는 리소스를 mygroup 리소스그룹에서 제거하려면 아래처럼 한다.
* 기타 리소스 확인 명령어
pcs resource status : 구성된 리소스와 리소스 그룹에 대한개요, 리소스 상태를 볼 수 있다.
pcs resource config : 구성된 리소스의 상세 속성과 operation, 정보 확인
* References
pcs(8) man page
For more information, refer to the Configuring cluster resources chapter in the Configuring and managing high availability clusters guide at
클러스터 안의 노드가 문제가 있는 경우, 어떻게 동작할지 모르며 클러스터의 파일시스템 자원에 접근이 가능하다면 데이터 무결성을 손상시킬 수 있다. 이것을 막기 위해 문제가 있는 경우 해당 노드가 클러스터 리소스에 접근하는 것을 제한하는 외부 방법이 필요하다. 이것이 Fencing 이다.
Fencing의 방법은 여러가지가 있는데, 그중 서버를 꺼버리는 행위는 가장 간단하다. 죽은 노드는 확실하게 아무것도 할 수 없기 때문이다. 또 다른방법으로, 문제있는 노드를 네트워크/스토리지에서 분리하는 "작업의 조합"으로써 Fencing을 할 수도 있다. 네트워크에서 분리하는 이유는 새로운 리소스가 해당 노드로 가지 않게 하려는 것이며, 스토리지에서 분리하는 것은 문제있는 노드가 공유디스크에 쓰기를 하지 못하게 하기 위한 것이다.
Fencing은 클러스터에서 서비스와 리소스를 Recovery하는 매우 중요한 신호이며, 일반적인 절차이다. (서버가 꺼졌다고 난리를 피울 필요가 없다) Red Hat High Availability Add-on은, 응답없는 노드가 클러스터에 의해 Fencing 당하기 전까지는 해당 노드에서 리소스를 시작하지도 않고 서비스를 리커버리 하지도 않는다.
클러스터에서 Fencing이 올바르게 구성되면, 클러스터 내의 모든 노드가 다른 모든 노드를 Fencing 할 수 있어야 한다. 또한, 레드햇의 지원을 받으려면 클러스터의 모든 클러스터 노드가 Fencing을 받을 수 있도록 구성해야 한다.
* Fencing과 관련된 클러스터 시나리오
Fencing이 없는 상태에서 발생할 시나리오
3노드 클러스터 (노드1,노드2,노드3)이 Fencing없이 구성되어 있다. 노드1은 공유디스크에서 ext4 파일시스템 리소스를 마운트하였고, 웹서버 리소스가 해당 파일시스템에서 index.html등의 파일을 불러와 웹서비스를 수행한다. 갑자기 노드1 클러스터 네트워크 상에서 응답을 멈추는 문제가 발생하였다.
1. 노드2는 빠르게 파일시스템 체크를 수행한 후, 해당 공유 스토리지를 마운트한다.
2. 노드2는 웹 서비스를 시작한다.
3. 노드1이 갑자기 정상화되었고 마운트되어있는 파일시스템에서 쓰기를 시작한다. 현재 이 파일시스템은 노드2도 마운트 되어있다.
4. 파일시스템 손상이 발생한다. (ext4는 두군데 이상에서 마운트하고 쓰기가 발생하면 데이터 손상이 일어난다)
Fencing이 있는 상태에서 발생할 시나리오
3노드 클러스터 (노드1,노드2,노드3)이 Fencing없이 구성되어 있다. 노드1은 공유디스크에서 ext4 파일시스템 리소스를 마운트하였고, 웹서버 리소스가 해당 파일시스템에서 index.html등의 파일을 불러와 웹서비스를 수행한다. 갑자기 노드1 클러스터 네트워크 상에서 응답을 멈추는 문제가 발생하였다.
1. 클러스터는 노드1을 스토리지로부터 제거한다. (Fencing)
2. 노드2는 빠르게 파일시스템 체크를 수행한 후, 해당 공유 스토리지를 마운트한다.
3. 노드2는 웹 서비스를 시작한다.
4. 노드1이 정상화 되었으나 파일시스템은 마운트 할 수 없다. 또는, 노드1이 리부팅되었고 깨끗하게 되어 다시 클러스터에 들어가서 대기하게 된다.
* Fencing 방법
Fencing은 두가지 주요 방법이 있다. Power Fencing, Storage Fencing. 두 방법은 Power switch나 virtual fencing daemon 같은 fence device가 필요하다. 그리고 클러스터와 Fencing device간의 통신을 활성화 하기위한 Fencing agent 소프트웨어가 필요하다. 실제로 특정 노드에 Fencing을 해야 하는 경우, 클러스터는 Fence agent에게 이 임무를 위임한다. Fence agent는 Fence device에 통신하여 작업을 수행하도록 한다.
Power Fencing
서버의 전원을 차단하는 방법이다. 이 방법은 STONITH라고도 불리며, Shoot The Other Node In The Head의 줄임말이다. 파워 펜싱에는 두가지 종류가 있다. 또한 파워 펜싱은 서버를 끄거나 켜는 등 여러가지 방법으로 서버를 컨트롤 할 수 있다. 서버가 껐다 켜지면 클린한 상태가 되며, 클러스터 서비스가 enable 되어있다면 리부팅후 다시 자동으로 클러스터에 조인하게 된다.
1. 서버 외부에서 제어되는 네트워크 멀티탭 같이 전원차단 기능이 있는 하드웨어
2. 서버 내부에 전원을 차단하는 IPMI (예: iLO, DRAC, IPMI) 또는 가상 머신 Fencing Device 등
아래는 1번의 예시이다. 1번의 경우 일반적으로 서버는 파워 서플라이가 2개이상이므로, 모든 파워서플라이가 꺼지도록 설정해야 한다. 잘못 설정하는 경우, 실제로는 펜싱이 되지 않았는데 겉으로는 펜싱이 된 것처럼 보여 큰 문제가 발생할 수도 있다.
Storage Fencing
서버를 스토리지에서 연결을 해제하는 펜싱 방법이다. 이것은 SCSI reservation을 쓰거나 FC 스위치의 포트를 닫는 등의 방법으로 구현한다. 파워 펜싱 없이 스토리지 펜싱만 쓰는 경우, 해당 서버가 클러스터에 다시 조인되는지는 관리자가 확인해야만 한다. 사실 일반적으로 파워 펜싱을 사용하며 스토리지 펜싱을 사용하는 것은 드물다. 아래는 멀티패스를 사용하는 FC 스토리지를 사용하여 스토리지 펜싱을 수행하는 예시이다.
* Fence agent의 종류 (자주 사용하는것만)
- Hareware Management Fencing : 서버 관리 툴 (iLO, iDRAC, IPMI 등) 을 통해 사용하는 Fencing
- Virtual Mahine Fencing / Libvirt Fencing : 가상머신(VMWare, KVM 등의 하이퍼바이저) 를 통해 사용하는 Fencing
- Cloud instance fencing : 클라우드 종류에 따라, 예를들어 알리바바, AWS, AZURE등에서 사용할 수 있는 Fencing agent 들이 있다.
* Fence 여러개 조합하기
Fence는 하나만 사용하는것이 아닌 여러개 사용이 가능하다. 위에서 소개한 파워 펜싱, 스토리지 펜싱을 함께 쓸 수도 있다. 여러개의 펜싱 조합은 서로 백업으로써 작동할 수 있다. 펜싱도 실패할 수 있기 때문이다. 예를들어 첫번째로 파워 펜스를 수행하고, 실패한다면 스토리지 펜스를 수행하게 할 수도 있다.
* Fence Agent 에 대해 알아보기
Red Hat High Availability Add-on은 여러가지 펜스 장치를 지원하는 Fence agent들을 제공한다. 실제 사용하는 Fence Device를 지원하는 Fence agent를 설치하여 Fence를 구성하면 된다. fence-agents-all 패키지를 설치하면 레드햇에서 제공하는 대부분의 Fence Agents를 설치할 수 있다. 그러나, 모든 fecing agent를 싹다 모은것은 아니다. 또한 그중 몇가지는 수동으로 설치해야 한다. 더 많은 정보는 다음을 참고한다. https://access.redhat.com/articles/2912891
Fence Device와 Fence agents 각각 종류에 따라 모두 요구되는 파라미터가 다르다. 공통되는 파라미터도 있지만 각각 파라미터가 다르므로 미리 확인이 필요하다. 각각의 Fence agent들은 명령어들처럼 쓸 수도 있다. 추가적으로, 모든 fencing agents은 /usr/sbin/fence_* 에서 확인할 수 있다.
명령어1 : 설치된 fence agent 정보 확인하기 - pcs stonith list
[root@node ~]# pcs stonith list
fence_amt_ws - Fence agent for AMT (WS)
fence_apc - Fence agent for APC over telnet/ssh
fence_apc_snmp - Fence agent for APC, Tripplite PDU over SNMP
fence_bladecenter - Fence agent for IBM BladeCenter
...output omitted...
명령어2 : Fence Agent의 상세 정보 확인하기
pcs stonith describe [Fence agent 이름] (--full 옵션을 추가하여 아주 상세히 볼 수 있다)
위와 같이 해당 에이전트는 어디에 사용하는지도 설명이 나오며, ip는 필수적으로 필요하고, port는 옵션으로 필요하다는 것을 알 수 있다.
명령어3 : Fence Agent의 상세 정보 확인하기 - man 사용, fence 에이전트 자체 사용
- man [Fence agent 이름]
- [Fence agent 이름] -h
명령어4 : Fence Agent를 명령어로써 사용하기
fence_ipmilan은 아래와 같은 명령으로 Fence를 수행할수도 있다.
Fence Device 만들기
클러스터에서, pcs stonith create 명령으로 Fence Device를 생성할 수 있다. 기본 형식은 다음과 같다.
- name : STONITH fence device의 이름. pcs status 등 상태 확인 명령에서 나오는 이름이다.
- fencing_agent : fence device에 의해 사용될 fencing agent의 이름.
- fencing_parameter : fencing agent에 사용할 요구되는 파라미터들.
* Fence 관련 여러 명령어들
설정된 Fence device의 현재 상태 보기
pcs stonith status 명령 : 클러스터에서 구성된 fence device, 사용되는 fencing agent, fence device 상태를 보여준다. fence device의 상태는 started와 stopped 두가지가 있다.
- started : 해당 device는 작동중인 상태
- stopped : 해당 fence device는 작동하지 않는 상태
설정된 Fence device의 정보 보기
pcs stonith config 명령 : 모든 STONITH 리소스의 configuration option들을 보여준다. 특정 STONITH 리소스 이름을 줘서 해당 리소스의 configuration option만 볼수도 있다.
설정된 Fence device 속성값 변경하기
pcs stonith update fence_device_이름 : fencing device의 옵션을 변경할 수 있다. 이 명령은 새로운 fencing device 옵션을 추가하거나, 원래 있는 값을 변경할 수 있다. 예를들어, fencing device 인 fence_node2가 node2 대신 node1를 펜스해버렸다. 이경우, 아래 명령으로 바로잡을 수 있다.
설정된 Fence device 삭제하기
어떤 시점에서는 클러스터에서 fencing device를 제거해야 할 수 있다. 이는 해당 클러스터 노드를 삭제하거나, 노드를 펜스하기 위해 다른 펜스 매커니즘을 사용하기 위해 사용할 수 있다. pcs stonith delete Fence_device_name 명령으로 수행한다.
* fence 구성 테스트하기
- 구성된 fencing 설정이 잘 작동하는지 두가지 방법으로 확인할 수 있다.
1. pcs stonith fence 노드명
- 이것은 요청한 노드를 펜스시킨다.
- 사용자는 fence 시키고 싶은 노드에서 하는게 아니라, 다른 노드에서 이 명령을 사용해야 한다 (should)
- 만약 이 명령이 성공하면, 해당 노드는 펜스된다.
2. 한 노드를 네트워크 케이블을 뽑거나 방화벽에서 포트를 닫거나, 전체 네트워크 스택을 비활성화여 노드에서 네트워크를 비활성화한다.
- 그러면 클러스터의 다른 노드는 해당 노드가 장애라는것을 확인하고 펜스를 해야 한다. (should)
- 이는 실패한 노드를 감지하는 클러스터의 기능도 테스트합니다.
* Fence agent 의 파라미터
Fence agent 의 파라미터는 크게 일반 파라미터와 전용 파라미터 두가지 범주가 있다. 일반 파라미터는 대부분의 Fence agent가 모두 동일하게 사용하며, 전용 파라미터는 Fence agent 마다 각각 다른 파라미터이다. 파라미터부터는 이해가 잘 안될텐데, 자주 사용하는 Fence agent의 파라미터의 예시를 보면서 이해하면 도움이 된다.
<일반 파라미터>
아래는 자주 사용하는 일반 파라미터이다.
pmk_host_list
- 이 매개변수는 fencing device에 의해 제어되는 node 들의 리스트를 스페이스로 구분한 리스트를 제공한다.
Knowledgebase: "What format should I use to specify node mappings to stonith devices in pcmk_host_list and pcmk_host_map in a RHEL 6, 7, or 8 High Availability cluster?"
모든 서버마다 BMC가 있거나 가상으로 구현할 수 있다. 각 BMC는 IP, ID, PW를 가지고 있다. 이 정보로 fence 를 생성한다. 또한 각 서버의 관리 툴에서 ipmi over lan 옵션을 활성해야 할 수도 있으므로 참고할 것.
BMC를 사용하지 않는 경우, 여러가지 하드웨어 디바이스들이 있다. 이 장치들은 장치마다 구성 방법이 있으므로 따로 참고해야 하며, 이 예시에서는 BMC를 사용한 fence_ipmilan 에이전트를 예시로 든다.
• Uninterruptible power supplies (UPS)
• Power distribution units (PDU)
• Blade power control devices
• Lights-out devices
Fence 구성 명령
이 예시에서는 fence_ipmilan 이라는 에이전트를 예시로 들며, 각각 노드마다 fence 장치를 생성해야 한다. 따라서 총 3개를 만든다. pcs stonith create명령을 사용한다.이 커맨드는 클러스터 노드를fence할 수 있는fence agent에 의해 요구되는 파라미터의 세트와value값을 요구한다. fence agent인fence_ipmilan의 파라미터는pcmk_host_list, username, password, ip가 요구된다. pcmk_host_list파라미터는 클러스터에 알려진 해당 호스트를 나열한다. ip매개변수는 펜싱 장치의IP주소 또는 호스트 이름을 요구한다.
구성된 Fence 상태 확인
pcs stonith status명령은 클러스터에 연결된fence장치의 상태를 보여준다. 모든fence_ipmilan펜스 장치는started로 보여야만 한다.
만약 하나 이상의fence장치가stopped되어있는 경우,대부분fence agent와fencing server간 커뮤니케이션의 문제이다. "pcs stonith config펜스장치"명령으로fence device의 세팅을 확인한다.또한pcs stonith update명령으로 펜스장치를 업데이트할 수 있다.
실제로 fence를 수행하여 잘 작동하는지 확인
아래 두가지 방법으로 Fence 를 수행해볼 수 있다. 이미 Fence가 구성되었다면 첫번째 방법으로, 구성되지 않았다면 두번째 방법으로 할 수 있다. 아래 두번째 캡쳐는 위 정보와 맞지 않은데, 이런 형식으로 하면 된다는 것을 얘기하는 것이다.
Fence가 성공되었다면 해당 서버는 종료되며, 다시 부팅된다. 부팅되고 다시 클러스터에 조인하게 된다. (enable 설정 했을 시)
동일한 한가지 작업을 여러대의 컴퓨터가 세트가 되어 일하는 것. 러스터에 목적은, 운영하는 서비스가 Single Point Failure 의 영향을 가능한 받지 않게 하려는 것이다. 클러스터 내에 있는 컴퓨터들은 각각 node 라고 하며, 이들은 서로를 모니터링한다. node 또는 서비스에 문제가 있을 시, 정상적인 node에 서비스를 이동시켜 가능한 한 서비스 운영의 downtime을 최소화 시킨다.
이러한 전략은 하나의 서버가 가능한 한 uptime을 오랫동안 유지하도록 하는 것과는 다른 전략이다. 사실 uptime은 실제 엔드유저에게는 크게 중요하지 않으나, 서비스의 가용성은 엔드유저에게 중요하다.
* High Availbility 클러스터 방식
시스템 관리자는 서비스 요구사항과 하드웨어 사용 가능량 (비용)에 따라 최적화된 클러스터 구성을 결정해야 한다. 클러스터 구성을 계획할 때 가장 중요한 질문은 다음과 같다. "해당 서비스를 클러스터에 넣으면 가용성이 증가하는가?" 클러스터 구성은 2가지 방식을 가진다.
1. Active-Active Cluster
- 여러 노드에 하나의 동일한 서비스가 올라간다. 이 경우 한 노드가 죽는다 하더라도 다른 노드가 살아있다.
- 서비스는 다른 살아있는 노드에서 수행하므로 문제가 없고, Fail된 노드가 회복되면 다시 클러스터는 워크로드를 전체 노드에 분배한다.
- 이러한 타임의 클러스터의 주요 목표는 로드밸런싱으 수행하고, 높은 부하를 컨트롤하기 위해 많은 인스턴스를 확장하는 것이다.
- 다만 로드밸런싱을 위해 따로 로드밸런서가 필요하다.
- Active-Active 클러스터는 2개 이상의 클러스터 노드에서 사용할 수 있다.
2. Active-Passive Cluster
- 하나의 서비스가 하나의 노드에만 올라간다. 만약 하나의 노드가 Fail되면, 그때 클러스터는 다른 정상 노드에 해당 서비스를 올린다.
- 이 방식은 문제있는 노드가 클러스터 리소스에 접근해서 데이터 무결성을 깨뜨릴 수 있어, Fencing이라는 정책이 필요하다.
- 참고로 이 과정은 Activce-Passive 클러스터 구성에 포커스를 맞추고 있다.
* 클러스터의 구성요소 및 용어
리소스 / 리소스 그룹
work의 기본 단위를 리소스라고 표현한다. 여기서 work 기본 단위란, 실행하는 어플리케이션, 파일시스템, IP주소 등 모든 것이 리소스가 된다. 리소스 그룹은 관계 있는 리소스들은 하나로 묶는 것이다. 예를들어 웹 서비스를 제공하려면 접속할IP, 웹서비스, 웹페이지가 저장될 파일시스템 등이 필요하다. 이런 관계 있는것들은 하나의 노드에서 실행되어야하므로 리스소 그룹으로 묶어 하나의 노드에서 해당 그룹이 실행되도록 한다.
Failover
클러스터에 올라간 리소스에 문제가 있는경우, 해당 리소스를 다른 노드로 마이그레이션한다. 이러한 방식으로 클러스터가 운영된다.
Fencing
클러스터 내에서 가장 안전하게 지켜야 하는것은 데이터이다. 여러 노드에서 한 파일시스템에 접근을 시도하면 데이터 무결성 문제로 파일시스템이 깨지게 된다. 이것을 막기 위해 Fencing 이라는 방식이 있으며, 크게 서버의 전원을 끄거나 스토리지 연결을 끊는 방식이 있다. 서버 전원을 끄는 방식을 일반적으로 많이 사용한다. 노드에 문제가 생기면, 문제는 너무나 많은 종류가 있고 다 추측할 수 없다. 따라서 리소스에 문제가 있다고 판단되면 단순하게 Fencing을 수행해서 리소스를 다른 노드로 마이그레이션한다.
Quorum
클러스터의 무결성을 유지하기 위해 필요한 투표 시스템이다. 클러스터 노드에 문제가 생기면, 의사결정을 할 노드가 누가 될지를 결정하는데, Quorum으로 결정을 한다. 모든 노드는 투표수를 1개씩 가지며, 전체 노드 수에 기반하여 과반수 이상의 투표 수를 가진 노드의 그룹이 Quorum을 얻게 된다. Quorum을 얻지 못한 노드 (과반수가 아닌 노드)는 모두 Fencing된다. 만약 클러스터가 Quorum을 얻지 못한 상태라면, 어떠한 리소스도 시작되지 않으며, 실행된 리소스들은 중지된다. 예를들어 5노드 클러스터에서 3노드가 응답이 없고 2노드만 투표하면 그 클러스터는 Quorum을 잃게 되는 것이다.
* 클러스터 네트워크/하드웨어 아키텍쳐
클러스터 구성을 위해서는 아래와 같이 복잡한 구성이 필요하다. 아래는 5노드 클러스터의 일반적인 구성이다. 파란색은 IP 네트워크이며, 녹색은 SAN 네트워크(iSCSI, FCoE도 가능)이다. 하늘색은 상황에 따라 다른데, 아래 예시에서는 IP 네트워크이다.
- 왼쪽 Public Network 는 일반 사용자들이 접근하는 네트워크로, 외부에서 접근하는 공개적인 네트워크이다.
- 오른쪽 Private Network 는 엄격하게 비공개되어야 하며, 절대 외부에서 접근하지 않도록 해야 한다.
- Private Network 의 Ethernet Switch는 노드간 통신하는 경로로, Heartbeat 가 포함된다.
- Power Control은 전원을 끄는 Fencing에 필요한 것으로, 서버 전원을 끄기 위해 IPMI를 사용하여 서버 전원을 종료한다.
일반적인 서버 벤더는 전용 IPMI 관리툴이 있다. (Dell/iDRAC , HP/iLO 등)
* 클러스터 소프트웨어 구성요소
클러스터 소프트웨어는 Red Hat Enterprise Linux Add-ON : High Availability 에서 제공된다. 클러스터는 아래와 같이 여러 소프트웨어 데몬/컴포넌트들이 연계되어 작동한다.
Corosync
클러스터 노드간 통신을 핸들링하기 위해 페이스메이커에 의해 사용되는 프레임워크이다. corosync는 Pacemaker의 멤버십 및 쿼럼 데이터 소스이기도 하다.
Pacemaker
모든 클러스터에 관련된 활동에 대한 책임을 가지는 컴포넌트이다. 클러스터 멤버쉽을 모니터링하고, 서비스와 리소스를 관리하고, 클러스터 멤버를 fencing 한다. pacemaker RPM 패키지는 아래 3가지 중요 기능이 포함된다.
Cluster Information Base (CIB)
CIB는 클러스터와 클러스터 리소스들의 구성과 상태 정보를 XML 포맷형태로 포함한다. 클러스터 안에 있는 하나의 클러스터 노드는 DC(Designated Coordinator)로 행동하도록 페이스메이커에 의해 선택되며, 또한 모든 다른 노드에 싱크되는 클러스터/리소스 상태와 클러스터 구성을 저장한다. 스케줄러 (pacemaker-schedulerd)는 CIB의 컨텐츠를 사용하여 클러스터의 이상적인 상태와 어떻게 그 상태에 도달할지에 대해 계산한다.
Cluster Resource Management Daemon (CRMd)
클러스터 리소스 관리 데몬은 모든 클러스터 노드에서 실행되는 LRMd(Local Resource Management Daemon)에다가 리소스의 시작/종료/상태 체크 action을 조정/전송 한다. LRMd는 CRMd에게 받은 Action을 resource agents에게 전달한다.
Shoot the Other Node in the Head (STONITH)
stonith는 fence 요청을 처리를 담당하는 시설이며, 또한 해당 요청 액션을 CIB 안에 구성된 fence 장치에게 보낸다.
Pcs
pcs RPM 패키지는 두개의 클러스터 구성 툴을 포함한다. pcs 명령어는 커맨드 라인 인터페이스를 제공한다. 이것으로 pacemaker / corosync 클러스터의 모든 부분을create/configure/control 할 수 있다. pcsd 서비스는 클러스터 구성 동기화를 제공하며, 또한 pacemaker/corosync 클러스터를 create/configure 하도록 하는 웹프론트엔드를 제공한다.
* 클러스터 요구사항 및 조건
클러스터의 요구사항 및 조건은 매우 중요하며, 가능하면 클러스터 설정, 네트워크 아키텍쳐, 펜스 구성 같은 관련 데이터를 레드햇 support로 전송해서 검토받을 수 있다. 주요 고려사항은 다음과 같다.
1. 노드 개수
2. 클러스터의 네트워크 범위 (같은 네트워크 대역이 아닌 거리적으로 먼 거리 등)
3. Fence 장치
4. 노드의 가상화/클라우드 환경
5. 네트워크 구조
6. selinux
* 장애 조치 계획
모든 하드웨어는 결국엔 장애가 발생한다.. 하드웨어 수명 주기는 주 단위에서 연 단위까지의 범위를 가진다. 게다가 거의 모든 소프트웨어는 버그가 있다. 어떤것은 눈에 띄지 않지만, 다른것들은 전체 데이터베이스를 손상시킬 수도 있다.
시스템 관리의 주요 TASK 중 하나는 이런 문제가 발생할 것을 알고, 그에 따라 계획하는 것이다. 클러스터는 많은 Single Point of Failure (SPOF) 를 가진다. 이를 하드웨어단에서, OS 단에서, 인프라단에서, 소프트웨어단에서 이중화를 통해 막을 수 있다.
아래는 완전한 목록은 아니지만 일반적인 문제들이다.
• Power supply - > 파워 이중화
• Local storage -> 레이드 구성
• Network interfaces -> 네트워크 포트 본딩
• Network switches -> 스위치 이중화
• Fencing software -> Fence 이중화
• User data -> 정기적인 외부 백업
* References
pcs(8) man page For more information, refer to Chapter 2.
For more information, refer to the High Availability Add-On Overview chapter in the Configuring and managing high availability clusters guide at
Knowledgebase: "How can Red Hat assist me in assessing the design of my RHEL High Availability or Resilient Storage cluster?" https://access.redhat.com/articles/2359891
RHEL HA ADD-ON은 요구되는 소프트웨어 패키지 모음과 방화벽 설정, 그리고 노드 인증이 필요하다. 추가적으로, RHEL8과 RHEL7 클러스터 노드는 호환되지 않는다. 페이스메이커 클러스터에 있는 모든 노드들은 동일한 메이저 버전의레드햇 리눅스를 써야만 한다. (마이너 버전 얘기는 없음) 커뮤니케이션을 위해 RHEL8은 corosync 3.x를 쓰며, RHEL7은 corosync 2.x를 쓴다.
노드에 필요한 소프트웨어 설치
클러스터 구성 소프트웨어는 pcs 패키지이다. pcs 패키지는 corosync와 pacemaker 패키지를 필요로한다. yum으로 pcs 설치시 corosync와 pacemaker는 dependency로 자동으로 설치된다. fencing agents는 각각 클러스터 노드에 설치되어야 한다.
fence-agents-all 패키지는 모든 사용가능한 fancing agent 패키지를 당겨온다. 관리자는 fence-agents-all을 할지 아니면 fence-agents-XXX 패키지만 설치할지 선택해야 한다. 여기서 XXX는 fence 에이전트 종류에 따른 이름이다. pcs와 fence-agents-all(또는 다른 fence agent) 패키지는 모든 클러스터 노드에 설치되어야 한다.
클래스룸 환경은 서버를 IPMI OVER LAN을 통해 전원끄기/켜기/재시작 할 수 있는 BMC를 포함한다. 클러스터에서 BMC를 사용하기 위해서는 fence-agents-ipmilan 패키지를 모든 클러스터 노드에 설치해야 한다.
클러스터 통신을 위한 방화벽 설정
모든 클러스터 노드의 방화벽에서 클러스터 통신을 위해 방화벽을 해제해야 한다. rhel8의 기본 방화벽은 firewalld이며, 방화벽 데몬은 클러스터 통신을 허용하기 위해 High-Availability 이라는 표준 서비스와 함께 제공됩니다. high-availability 방화벽 서비스를 각 노드에서 허용하기위해서는 아래와 같이 한다.
Pacemaker와 Corosync를 각 노드에서 활성화하기
pcsd 서비스는 클러스터 구성 동기화와 클러스터 구성을 위한 웹 프론트엔드를 제공한다. 이 서비스는 모든 클러스터 노드에 있어야 한다. systemctl을 사용하여 pcsd를 활성화한다. 모든 클러스터 노드에서 한다.
클러스터 커뮤니케이션을 위한 유저 설정
pcsd는 클러스터 커뮤니케이션과 구성을 위해 hacluster라는 유저를 사용한다. 레드햇은 클러스터 내의 모든 노드의 hacluster 유저가 동일한 비번을 쓰기를 권고한다. 아래처럼 비번을 redhat으로 구성할 수 있다.
클러스터 노드 인증
pcsd 서비스 내에서 클러스터 노드를 인증해야 한다. 이 인증을 위해 hacluster 계정과 패스워드를 사용한다. pcs host auth 명령어로 클러스터 내의 모든 노드를 인증하기 위해서, 노드 중 하나의 노드에서만 아래 명령어를 실행하면 된다. 자동화를 목적으로 -u 유저명 , -p 패스워드 옵션을 사용할수도 있다.
High Availability Cluster는 구축 전 기본적인 네트워크 구성이 필요하다. 아래 예시가 가장 기본 네트워크이며, 해당 교육과정 수업시 실습을 위해 기본적으로 구성되는 Lab 시스템이다. 해당 네트워크 구성을 이해해야 기본적인 수업이 가능하다.
* 기본 네트워크 구조
workstation
핸즈온 메인으로 사용하는 컴퓨터. 실제 시험장에서 내가 직접 사용하는 물리적 PC라고 생각하면 된다. GUI이며, 항상 여기에서 먼저 로그인을 한다. 여기서 모든 다른 VM에 SSH로 연결할 수 있다. standard 유저 계정을 가지며, student / student 계정이다. student는 필요한 경우 root가 될 수 있다. 어떠한 작업도 root로 다이렉트로 로그인하는것을 요구하지 않는다. 하지만 만약 필요하다면 비번은 redhat 이다.
nodea / nodeb / nodec / noded
실제 클러스터 구성과 실습을 수행하는 서버들이다. workstation과 동일한 권한을 가진 계정인 student / student 를 가진다. 모든 VM은 lab.example.com DNS 도메인을 가진다. (172.25.250.0/24) 그리고 그 다음에는 3개의 다른 네트워크가 있다.
private.example.com (192.168.0.0/24) : private 클러스터 커뮤니케이션으로만 사용한다.
private.example.com 은 클러스터 인프라에 있어 아주 중요하다. 왜냐면 이 네트워크가 fail되면 전체 클러스터가 fail 되기 때문이다. 이 때문에, 레드햇은 production에서는 클러스터 회복력을 높이기 위해 네트워크 이중화를 사용하도록 권고한다.네트워크 이중화는 이후 코스에서 설명한다.
bastion
bastion 시스템은 항상 실행중이어야만 한다. bastion 시스템은 사용자의 lab machine과 classroom 네트워크에 연결하는데 있어 router처럼 작동한다. 만약 bastion이 죽으면, 다른 lab machine들은 제대로 작동하지 않거나 부팅중 hang이 발생할 수 있다.
기타 서버들
몇몇 서버들은 support service를 하는 시스템이 classroom에 있다. content.example.com / materials.example.com 이 둘은 핸즈온 활동에서 사용되는 소프트웨어와 material이 있다. (이부분은 실제 공부에서는 중요하지 않다) 또한 iSCSI와 NFS를 제공하는 스토리지 서버인 storage.lab.example.com 도 제공된다. 이 스토리지는 매우 중요하지만 실습을 위해 구축하는 방법은 따로 이 수업에서 제공되지 않는다.
* 서버 역할 및 IP 표
- 아래는 classroom 환경에서 사용되는 여러 머신들을 ip와 역할들을 포함하여 표로 만든 것이다.
* Fencing 환경
fencing은 클러스터에서 중요한 부분이다. 자세한 설명은 이후 코스에서 하겠지만, 간단히 정의하면 문제있는 클러스터 노드가 클러스터 자원에 엑세스하는것을 제한하기 위한 것이다. 우선 중요한 것은 네트워크 측면에서의 Fencing 설명이며, 이 부분만 설명한다. 이 코스에서는 두가지 다른 fencing 방법이 사용된다. Fence은 최소 하나 이상 구축해야 하며 아래 예시 둘 중 하나만 사용해도 되고, 둘다 사용해도 된다. 그 외 여러가지 다른 종류가 많고 다른것을 사용해도 상관없다.
fencing 방법1 - BMC
이 방법은 실제로 프로덕션 레벨에서 사용할 때 가장 많이 사용하는 방법이며, 물리적 서버의 관리 포트를 사용하는 방법이다. 물리적 서버의 종류는 대표적으로 Dell, Lenovo, HP 등이 있고, 각 회사마다 다른 이름의 관리 툴을 사용한다. (iDRAC, xClarity, IMM, iLO 등) 이 툴들은 서로 다르지만 모든 기반은 BMC에 기반을 두고 있다.
가상머신은 Power 관리에 관련된 BMC(Baseboartd Management Controller) 가 없다. 래서 BMC 동작은 power 라는 machine 의해 시뮬레이트된다. 시뮬레이션된 BMC 메커니즘은 클러스터 노드에서 원격으로 모니터링 및 관리 작업을 수행한다. (BMC에서 펜싱을위한 파워 모니터링을 말하는것으로 보임) BMC 장치의 IP주소는 (192.168.0.101/102/103/104) 이며 각각 nodea/b/c/d 를 위해 사용된다. 이것은 power 에 의해 호스트된다.
BMC IP주소와 노드 이름은 classroom 환경이 생성될 때 할당된다. openstackbmc 서비스는 power 에서 power-managed cluster node 하나당 하나의 프로세스로 실행된다. (즉 4개의 프로세스가있음) 이 서비스는 해당 노드를 대신하여 IPMI (Intelligent Platform Management Interface)의 요청에 응답한다. 모든 BMC 장치에 대하여, 로그인 정보는 admin / password 이다.
Fencing 방법2 - Simulated chassis
이 과정에서 사용되는 두 번째 fencing 방법은 관리 섀시(예: ibmbblade, hpblade 또는 블레이드 센터)를 시뮬레이션 한다. 이 방법은 fencing 요청을 위해 chassis IP 한개만 필요하다.
이 fencing 방법은 각 클러스터 노드에 플러그 번호를 할당하는데 fence_rh436 커스텀 스크립트와 pcmk_host_map 파라미터를 사용한다. 노드를 펜스하라는 요청이 chassis IP (192.168.0.100)에 보내질 때, 플러그 번호가 포함된다. fence_rh436 스크립트는 이 요청을 Fencing through simulated BMC 방법 에게 IPMI call 로 변환시켜 보낸다.
이 classroom에서 power 머신은 fence 할 노드인 가상머신을 전원 종료하는 요청을 simulate chassis에서 수행하도록 한다.
* 클러스터 구성 환경 초기화 할 때 유의사항
classroom 환경을 재시작하는것은 모든 classroom node들 또는 특정 노드를 초기 상태로 돌리는 것이다. 리셋을 통해 가상머실을 초기화하고 lab을 다시 시작할 수 있다. 이슈가 생기거나 해결이 어려운 문제가 있을 때 빠르게 해결할 수 있는 방법이다. 이 classroom은 전체 또는 일부 환경을 초기화 할 때 제약조건이 있다.
대부분의 레드햇 트레이닝 코스에서 개별 시스템은 필요한 경우 하나하나 리셋이 가능하다. 그러나, 이 과정에서는 클러스터 노드를 하나만 리셋하면, 그 결과로서 해당 노드가 필요한 정보들을 잃게되고, 클러스터의 일부로서 통신하는것이 실패하게 된다. 그러므로 올바른 절차는 클러스터에서 해당 노드를 제거하고, 그 후에 재시작해야한다. 클러스터에서 노드를 제거하는것은 2가지 스탭으로 진행된다.
2. 노드가 클러스터에서 제거된 것을 반영하기 위해 fence 구성을 조정한다. (dedicated fence 장치를 삭제하거나 shared fence 장치를 수정한다.
노드를 재시작한 후에는 해당 노드는 다시 클러스터에 포함해야 한다. 즉, 모든 요구되는 패키지를 설치하고, 해당 노드를 클러스터 안에 권한을 넣고, 방화벽 포트를 열고, pcsd 서비스를 시작하고, 해당 노드가 클러스터의 일부가 되도록 구성도 해야한다.
* 클러스터의 노드들
일부 클래스룸의 VM들은 작업동안 수정되지 않으며, 시스템 문제가 발생하지 않는 한 전혀 리셋할 필요도 없다. 예를 들어, workstation 머신은 불안정해지거나 통신이 끊긴 경우에만 재설정해야 하며 자체적으로 재설정될 수 있다. 아래 표에는 재설정할 수 없는 머신과 필요한 경우 재설정할 수 있는 머신이 나열되어 있다. 만약 재설정을 해야하는 상황이 있다면, 온라인 환경에서, 선택한 머신을 클릭하고 ACTION -> RESET을 하면 된다.
참고할 사항으로, 만약 power 머신을 리셋한다면, fencing resouces들은 fail되거나 stop된다. 타임아웃이 되기 때문이다. 이 경우, 클러스터에서 이 리소스들을 다시 사용하는것을 enable 하도록 resources의 fail count를 꼭 reset 해줘야 한다. 이를 위해 아래 명령을 치면 된다. pcs resource cleanup my_resource
또한 original course build를 재생성하여 클래스룸 환경을 리셋할수도 있다. 이것은 문제가 완전히 꼬였을 때 사용한다. 문제를 해결하는것보다 코스를 재생성하는것은 빠르며, 일반적으로 몇분이 걸리며 깔끔하다. 온라인 환경에서 delete를 클릭하고, 기다렸다가 create 버튼을 누르면 된다.
