location constraint를 사용하여 특정 노드에 점수를 주어서 리소스 시작시 해당 노드에 리소스를 올리는 기능은 많은 엔터프라이즈 환경에서 사용하는 구성이다.
다만 이 방법의 문제는 해당 노드에 문제가 발생 시, 리소스가 다른 노드로 이동하고 이후 문제가 발생한 노드가 정상화 되었을 때 자동으로 해당 노드로 리소스들이 다시 원복되는 점에 있다. 실제 서비스 운영에서는 일시적인 다운타임이 고객사에 아주 무서운 영향을 줄 수 있어, 이러한 리소스 이동은 최대한 줄여야 한다.
이를 위해 stickiness 기능이 있다. 이는 리소스 재배치를 피하기 위한 기능이다. stickiness 는 간단하게 이야기하면, 장애 발생시 리소스를 받는 노드에게 주는 "점수" 이다.
Fence_xvm 은 High Availability Cluster에서 리눅스 위에 kvm으로 가상머신 올리는 경우, 간단하게 구성할 수 있는 Fence 방법이다. 이 구성을 위해서는 kvm 호스트 머신에서 세팅, 그리고 클러스터 노드가 될 가상머신에서의 세팅 두가지 세팅이 필요하다. 이 구성은 RHEL8 기준이며, 다른 버전이나 상세 정보는 아래 Redhat KB 를 참고해야 한다. (로그인 필요)
pcmk_host_map 항목에서 형식이 nodename:port 라고 나오는데 port는 가상머신의 이름이다. 또한, 가상머신의 이름과 호스트명이 동일한 경우 pcmk_host_map은 입력하지 않아도 된다. fence_xvm 은 멀티캐스트라 충돌이 있을 수 있어 펜스 장치는 1개만으로 3개 노드를 커버하도록 한다.
pcs resource enable/disable 리소스명/그룹명 : 리소스 중단. 컨스트레인트 테스트할때 사용
pcs resource update 리소스 정보 변경
pcs resource op add/remove 리소스명 이름(monitor/start/stop등)
* 펜스 관련
pcs stonith list 에이전트명
펜스 리스트 보기
pcs stonith describe 에이전트명
해당 펜스 에이전트의 상세정보 확인
에이전트명 -h
해당 펜스 에이전트의 상세정보 확인
pcs stonith delete
펜스 삭제
* 컨스트레인트 관련
pcs constraint list --full
현재 컨스트레인트의 상세정보
pcs constraint delete 컨스트레인트명
컨스트레인트 제거
pcs constraint order a then b
a가 시작되어야 b 도 시작 가능하다. a가 스톱되어야 한다면 b가 먼저 스톱된다.
pcs constraint location A prefers/avoids 노드명
해당 리소스가 해당 노드를 더 선호하게 된다. 이것은 인피니티를 가지게 됨. / 또는 더 안선호하고 마이너스 인피니티를 가지게 함.
pcs constraint location A prefers node=500
해당 노드에 500점 준다
pcs constraint colocation add B with A
두 노드는 동일 노드에서 실행되어야만 한다. A가 메인이다. a가 시작되어야 b도 시작된다. a가 시작할 위치가 없으면 b도 실행할 수 없다. a가 먼저 실행될곳을 결정하고 그다음 b가 실행될지 여부를 결정한다.
pcs constraint colocation add B with A -INFINITY
둘이 절대 같이 안있게함.
# 현재 스코어 보기
crm_simulate -sL 의 옵션
-s : 스코어를 보여주기 (리소스, 리소스 그룹, stonith 장치)
-L : live cluster 에서 (현재 클러스터?인듯)
crm_simulate 명령은 리소스 type에 따라 특정 리소스에 대해 호출되는 할당 메서드(이전에는 color알려짐)를 사용하여 워크로드를 생성한다.
일반 리소스는 native_allocate만을 호출하는데 반면 클론된 리소스는 클론되는 레귤로 리소스에 대한 native_allocate 와 클론으로서 성격에 대한 clone_allocate 둘다 호출한다.
비슷하게, 그룹 리소스도 native_allocate와 group_allocate 두개를 호출한다.
location constraint 만을 사용해서 노드에 이동시키는 예시만 쓰므로, 리소스 할당 type은 여기서는 관련이 없다.
위 예시에서, location constraint 가 있는데 myweb 리소스 그룹은 노드1을 선호하도록 100점이 되어있다.
클러스터가 노드1에서 webip 리소스를 시작했다. 리소스가 실행되고 있을 때, 리소스 그룹이 자동으로 클러스터 내 모든 노드에 대하여 webserver 의 리소스가 -infinity 가 되도록 세팅했다. 따라서 그 리소스는 node1에서 실행되어야만 했다. (리소스그룹안에 모든 리소스들은 동일한 클러스터 노드에서 실행되어야만 하므로)
또한 crm_simulate 명령은 또한 특정 클러스터 구성과 이벤트 순서에 따라 리소스가 어떻게 재배치되는지를 예측하기 위한 문제해결 도구가 되기도 한다.
클러스터 내의 모든 이벤트는 모니터링될 수 있다. 이벤트는 노드 시작, 리소스 실패, 클러스터 구성 변경 등이 될 수 있다. 클러스터 모니터링은 중요한데 왜냐면 이것은 클러스터 상태에 대한 정보를 제공하기 때문이다. 즉, 시스템 관리자는 일부 이벤트에 대하여 알림을 받을 수 있도록 모니터링을 해야한다. 예를들어, 노드가 fail 되면 클러스터가 메시지를 보내게 할 수 있다. 이렇게 하면 클러스터의 모든 문제를 인지하고 적절히 대응할 수 있다.
alert agents 를 위한 스크립트 템플릿은 /usr/share/pacemaker/alerts 디렉토리에 있다. 시스템 관리자는 필요에 따라 이러한 템플릿을 그대로 쓰거나 수정해서 사용할 수 있다. 사용자는 또한 커스텀 alert agents를 만들 수 있다.
클러스터 alert 정의하기
pcs alert create 명령을 사용해서 클러스터 alert을 생성할 수 있다.
- path : alert agent script의 경로 (이 스크립트는 모든 노드에 동일한 위치에 있어야 한다)
- option : alert agent 스크립트에 환경 변수로 전달되는 에이전트별 구성 값이다.
- id : agent의 id 값. 만약 id 값을 정의하지 않았다면, pcs는 "alert-번호" 이런식으로 사용한다.
예를들어, 샘플 클러스터 alert인 myalert가 있고 이게 /usr/share/pacemaker/aperts/sample_alert.sh 파일을 실행한다면, 아래와 같이 명령어를 쓴다.
클러스터 alert 보기
pcs alert show / pcs alert config 두 명령어로 액티브된 클러스터 alert을 볼 수 있다. 두 명령어는 동일한 정보를 보여준다.
* 클러스터 alert 구성 변경하기
그리고 pcs alert update 명령으로 cluster alert의 옵션을 변경할 수 있다
클러스터 alert 제거하기
클러스터 alert의 제거가 필요할 때, pcs alert remove / pcs alert delete 명령을 사용한다. 둘다 동일한 동작을 수행한다.
예를들어, myalert 클러스터 alert을 제거하려면 아래처럼한다.
* 클러스터 alert 수신자 지정 구성하기
위에서 alert을 생성했으면, 해당 alert의 수신자를 지정한다. 지정하는 수신자는 alert agent의 유형에 따라 다르다. 예를 들어 email agent는 하나 이상의 이메일 주소로 alert을 보낼 수 있다. 파일에다가 이벤트를 기록하는 에이전트는, 하나 또는 하나이상의 파일을 수신자로 쓸 수 있다.
클러스터 alert의 수신자를 넣기 위해, pcs alert recipient add 명령을 사용한다.
예를 들어, 만약 위에 나온 sample_alert.sh 스크립트가 이메일을 보낸다고 했을 때, 구성은 이메일 주소를 수신자로 해야한다.
이미 만든 myalert 클러스터 alert에 대하여 이메일 수신자를 추가하려면, 아래처럼 수행한다.
동일한 클러스터 alert에 또 다른 이메일을 추가하려면, 동일한 에이전트에 대하여 다른 수신자를 만든다.
사용자는 또한 pcs alert recipient update 명령을 통해 클러스터 alert의 수신자를 수정할 수 있다. 수신자를 제거하려면, pcs alert recipient delete / pcs alert recipient remove 를 사용한다. 둘다 동일한 동작을 수행한다.
* mailto 알림 구성하기
시스템관리자는 일반적으로 알림은 어떤 유형의 클러스터 변경을 알려주기 때문에 유용하다고 생각한다. 예를들어, 리소스가 다른 노드로 마이그레이션될때의 알림은 노드의 장애가 있음을 알 수 있다. 리소스 그룹에 mailto 리소스를 추가하는 것은 이러한 알림을 받기에 간단한 방법이다. mailto 리소스는 리소스 그룹이 start/stop 할때 마다 수신자 주소로 등록된 이메일 주소로 이메일을 보낸다.
아래 예시에서, 사용자는 mailto 리소스를 importantgroup 리소스 그룹에 추가한다. 리소스는 admin@example.com 으로 이메일을 보내며, 제목 접두사에 중요 그룹 알림을 붙이고 그 뒤에 작업, 타임스탬프, 노드 이름을 붙인다.
mailto 리소스를 구성하였으면, 클러스터를 운영으로 넘기기 전에 mailto 리소스를 테스트해야 한다. 예를 들어 pcs resource move 명령을 사용하여 해당 리소스 그룹에서 리소스를 이동하여 리소스 그룹에서 MailTo 알림을 테스트할 수 있다.
* 클러스터 노드에서 mail-sending 구성
mail alert를 사용하는 mailto 리소스 에이전트 및 다른 리소스 에이전트는 dependency로서 모든 클러스터 노드에 mail transport agent (MTA, postfix이나 sendmail 등) 와 mail-sending 클라이언트가 설치하는것을 요구 한다. 이 예시는 구성이 간단하고 쉬운postfix를 사용하고, 또한 other user interface features 없이 커맨드라인으로의 메일 전송만 필요하기때문에 mailx를 사용한다. postfix 서비스는 enable 되어야 한다. 이러한 발신전용 요구사항에서는 추가적인 구성이 필요치 않다.
* 유저의 워크스테이션에서 메일 수신 구성
일반적으로, 사용자의 컴퓨터는 이미 메일 수신에 대한 구성이 되어있다. 만약, 여기 클래스 환경에서 구성되어 있지 않다면, workstation (실습시 사용하는) 에서 메일 컴포넌트가 설치되어야 한다. RHEL에서 SMTP 메일을 받도록 구성하려면, postfix MTA 를 설치하고 구성해야한다. 또한 사용하는 firewalld smtp 서비스 구성을 사용하여 SMTP 방화벽 포트를 오픈한다. postfix는 모든 네트워크 인터페이스에서 들어오는 메일을 수신하게 한다. 또한 postfix 서비스는 enable하여 자동으로 시작되게 한다.
실용적인 메일 읽는 프로그램을 구성하려면 mutt를 설치한다. Mutt를 처음 실행하면 메일 폴더를 만들라는 메시지가 표시된다. 이 폴더를 미리 폴더를 만들려면 루트가 아닌 mail user 로 mkdir을 사용하면 된다. 아래와 같이 명령을 실행한다. 여기까지 완료되면 클러스터에서 발신하는 메일을 받을 준비가 된다.
* References
mailx(1), mutt(1), pcs(8), and postfix(1) man pages
For more information, refer to the Triggering scripts for cluster events chapter in the Configuring and managing high availability clusters guide at
클러스터 트러블슈팅시, 가장 유용한 자원은 시스템 로그이다. 클러스터 로그는 크게 corosync, pacemaker 두가지 로그가 있다.
* Corosync Logging
Corosync daemon log는 /var/log/cluster/corosync.log 에 저장된다. 그리고 syslog에도 저장된다. 그러므로 사용자는 또한journalctl 명령이나 /var/log/messages 에서도 로그를 볼 수 있다. 시스템 관리자는 Corosync 구성파일(/etc/corosync/corosync.conf) 에 있는 logging {} 블록 을 수정하여 로깅을 컨트롤할 수 있다.
특정 파일에 corosync 로그를 기록하려면 to_logfile 이랑 logfile 경로를 logging {} 블록에 명시한다.
corosync는 또한 메시지를 stderr에 보낼 수 있다. 여기에서 systemd는 이러한 메시지를 수집하여 journald로 전달할 수 있다.
사용자는 corosync가 기록하는 메시지 로깅의 상세한 정도와 우선순위를 컨트롤할 수 있다. logging {} 블록에 syslog_priotiry, logfile_prority 세팅을 넣어서 이를 수행할 수 있다. 사용자는 두 파라미터에 다음 어떤 값도 사용할 수 있다. - emerg, alert, crit, err, wraning, notice, info, debug (높은 우선순위부터 낮은 우선순위로 정렬되어있음) 하나의 우선순위를 선택했을 때, corosync는 해당 우선순위보다 더 높은 우선순위의 메시지들을 로그파일에 포함한다. (즉 선택한 우선순위보다 낮은 우선순위 빼고 모두 로깅한다는것) 디폴트 로깅 우선순위는 info 이다. 또한 /etc/corosync/corosync.conf 파일에 있는 logging {} 블록안에 debug: 라인을 추가함으로써, 사용자는 모든 것에 대한 디버그 레벨 로깅을 강제할 수 있다.
한 노드에서 corosync 로깅 구성에 대한 변경을 진행한 후에는, 이러한 변경을 모든 노드에 배포하고 클러스터를 재시작해야한다. 변경사항을 배포하기 위해서, 구성파일 업데이트를 수행한 노드에서 pcs cluster sync 명령을 수행한다. 그러면, 각 노드에서 logging 변경사항을 활성화하기 위해 pcs cluster reload corosync 를 실행하게 된다. 그리고 전체 클러스터를 재시작하려면, pcs cluster stop --all 후pcs cluster start --all 을 하면 된다.
* corosync log file 리뷰하기
사용자는 corosync 가 생성한 여러 다른 메시지들을 보기 위해 로그 파일을 리뷰할 수 있다. 이 파일은 사용자가 제대로 클러스터를 셋업했는지를 verify하는데 도움을 준다. 가장 중요한 것으로, 이것은 또한 에러를 찾는데도 도움을 준다. 예를들어, corosync 로그 파일은 3노드 클러스터 구성에서 한 노드가 다운되면 아래와 같은 정보를 보여준다.
1. kronosnet 은 노드 1번이 다운되고, 또한 노드 1번은 활성화된 링크가 없는것을 리포트한다. [knet]
2. totem 프로토콜은 해당 노드로부터 정보를 받지 못했다. [totem]
3. CPG 서비스는 한 노드가 다운되었다고 메시지를 보낸다. [cpg]
4. 클러스터는 노드2,3의 쿼럼으로 유지되고 있다.
5. 클러스터는 활성화되어있는 노드2,3 에 서비스를 제공하도록 ready 상태이다.
* Pacemaker Logging
디폴트로, pacemaker 로그는 /var/log/pacemaker/pacemaker.log 에 저장된다. 그리고 "notice"와 그 이상의 레벨의 메시지만syslog에 저장된다. /etc/sysconfig/pacemaker 구성파일을 수정하여 로깅 옵션을 변경할 수 있다. Pacemaker 로깅할 대상 파일을 변경하려면 /etc/sysconfig/pacemaker 파일안에 PCMK_logfile 부분을 사용하여 pacemaker가 로깅에 사용할 파일을 변경할 수 있다.
디폴트로 pacemaker는 syslog에 로그를 로깅한다. 그러나 사용자는 PCMK_logfacility 옵션을 사용하여 특정 syslog 기능을 변경하거나, syslog 로깅하는것을 비활성화할 수 있다.
사용자는 구성파일 내에 PCMK_logpriority 세팅을 사용하여 pacemaker가 syslog에 기록하는 로그 우선순위를 컨트롤할 수 있다. 기본레벨은 info 이다. 시스템 관리자는 /etc/sysconfig/pacemaker에 있는 PCMK_debug=no 파라미터를 yes로 바꿈으로써 모든것에 대한 디버그 레벨 로깅으로 강제할 수 있다. PCMK_debug=yes 를 설정하면, 아래와 같이 debug 엔트리가 추가로 나오는것을 확인할 수 있다.
구성파일을 변경한 후에는, pacemaker.service를 재시작하여 변경사항을 적용한다. 클러스터 운영에 영향 없이 pacemaker를 재시작하려면, pacemaker.service를 재시작하기 전에 관리자는 한 노드를 standby모드로 변경하면 된다. 변경을 클러스터에 적용하려면전체 클러스터를 재시작해야 하며, 다음 명령어를 쓰면 된다. pcs cluster stop --all / pcs cluster start --all 을 수행하면 된다.
* 페이스메이커 로그 파일 리뷰하기
관리자는 클러스터에 의해 생성된 모든 메시지를 검토하기 위해 pacemaker 로그 파일을 리뷰할 수 있다. /var/log/pacemaker/pacemaker.log 파일은 수많은 클러스터 관련된 정보, 즉 product developers, redhat support team, advanced cluster administrators 에게 유용한 정보들이다. 반면에, pacemaker은 syslog에 중요한 메시지만 보낸다. 이것은journalctl -u pacemaker 또는 /var/log/messages 에 기록된다. 즉 pacemaker log 를 리뷰하기 위해 가장 좋은 절차는 grep을 사용하여 서로 다른 결과들을 필터해서 보는것이다. 아래 내용들은 전체 리스트를 의미하지는 않지만 관리자가 로그파일을 필터하는데 가장 중요한 기능들을 포함한다.
crm_update_peer_state_iter
클러스터 노드들의 상태에 대한 정보를 보여준다. 이 패턴을 grep으로 잡아 사용해서 노드가 언제 클러스터에서 연결을 잃었는지 검증할 수 있다.
crm_get_peer
각 노드의 노드 id를 보여준다. 이 패턴을 사용하여 이름에서 노드 id를 찾을 수 있다.
pcmk_cpg_membership
클러스터 멤버십에 댛나 정보를 보여준다. 이 패턴을 쓰면 노드의 서브시스템들이 클러스터에 조인하는것과 떠나는것을 모니터링할 수 있다.
pcmk_quorum_notification
쿼럼 상태를 보여준다. 이 패턴을 사용하여 언제 클러스터가 쿼럼을 업ㄷ었는지, 잃었는지, 유지하는지 볼 수 있다.
te_fence_node
펜스 요청에 대한 정보를 보여준다. 이 패턴을 사용하여 노드가 언제 펜스되었는지 알 수 있다.
tengine_stonith_notify
fencing operation의 상태에 대한 정보를 보여준다. 이 패턴을 사용하여 fencing agent가 성공적인지 확인할 수 있다.
determine_online_status_fencing
fence device의 상태를 보여준다. pcs stonith status 명령과 비슷한 정보를 제공한다.
#노트
journalctl을 사용하여, pacemaker와 corosync의 로그를 보려면 다음과 같이 한다.
다른노드에서 watch 로 펜싱 진행과 리소스가 리로케이션되는것을 확인한다. 그리고 현재 dc 노드가 누군지도 확인한다.
현재 nodeb가 dc노드로 보인다. 결과가 위와 다를 수 있음. (클러스터 정상 동작임) 현재 dc에서 nodea가 클러스터와의 통신을 언제 잃었는지 로그를 확인한다. 또한 클러스터가 해당 노드를 펜스한것도 확인한다. 현재 dc에서, /var/log/pacemaker/pacemaker.log 를 열고 거기서 crm_update_peer_state_iter 로 검색한다. 이 구문은 클러스터 멤버가 상태가 바뀌는 것을 보여준다. 해당 항목을 사용하여 을 사용하여 firstweb 리소스 그룹을 실행하던 노드와의 연결이 끊어진 시점을 확인한다.
현재 dc에서, /var/log/pacemaker/pacemaker.log 에서 te_fence_node 를 grep으로 검색해보자. 이 구문은 클러스터가 노드를 펜스하기 위해 수행한 시도들을 보여준다
현재 dc에서, 동일하게 tengine_stonith_notify 를 검색해보자. 이 구문은 irstweb 리소스 그룹을 가지고 실행중인 노드가 성공적으로 펜스되었는지를 확인할 수 있다.
클러스터가 기대한대로 작동하기 위해서, 노드들은 특정 사실에 대해 동의해야만 한다. 예를들어 어떤 서버들이 현재 클러스터 멤버인지, 어디서 서비스가 실행중인지, 어떤 머신이 어떤 리소스를 쓰는지 등. 이런 사실에 동의를 해야만 한다. High Availability Add-on은 다수결 투표 방식을 사용하여 이 방법을 구현한다. 현재 corosync 네트워크 통신에 성공적으로 참여하고 이미 클러스터에 조인되어 있는 다른 노드와 통신이 가능한 노드는 한 표를 던질 수 있다. 절반 이상의 투표가 던져지는 경우 클러스터는 정상적으로 작동한다.
과반수가 달성되기 위해 필요한 최소의 수를 쿼럼이라고 한다. 만약 쿼럼이 달성되면, 클러스터는 quorate 상태(정족수를 달성한 상태)라고 간주된다. 만약 절반이상의 노드들이 서로 커뮤니케이션 할 수 없는 경우, 클러스는 쿼럼을 잃게 된다.
클러스터가 시작될 때, 모든 클러스터 노드는 서로 통신을 하려고 시도하며, 쿼럼을 얻는데 초점을 맞춘다. 과반수가 형성되는 즉시, quorate 클러스터가 된다. quorate 클러스터에 성공적으로 조인되지 못한 다른 모든 노드들은 쿼럼을 가진 노드 중 하나에 의해 펜스당한다. 또한 quorate 클러스터에 조인되어 있는 노드가 더 이상 클러스터와 통신하지 못하게 되는경우, 해당 노드도 펜스당한다.
* 왜 쿼럼 계산이 필요한가?
클러스터에 있는 어떤 노드(들)이/가 특정 다른 노드들과 통신이 안되는 경우의 상황에서 쿼럼이 필요하다. 아래 그림은 5노드 클러스터를보여준다. 노드 1,2,3,4,5 가 있다. 그리고 ext4 파일시스템 공유스토리지를 서비스하고 있다. 해당 서비스는 노드1에서 실행중이다.
여기서, 노드4랑 노드5가 메인 프라이빗 네트워크에서 단절되고, 노드1,2,3과 통신이 안된다고 치자. 쿼럼이 없다면, 노드4,노드5. 두 노드는 노드1,2,3 세 노드가 모두 죽었다고 판단하고 리소스를 복구할 수 있도록 펜싱을 해야한다. 이런식으로, 쿼럼은 펜싱에 앞서 중요한관문의 역할을 한다.
클러스터에 펜싱 장치가 없으면 노드4,5는 즉시 리소스를 복구하여 동일한 ext4 파일시스템을 한번에 두 곳에 마운트하는데 이는 정상적인 상황이 아니다. 클러스터의 두 반쪽이 서로 독립적으로 작동하는 이러한 상황을 split-brain 이라고 한다. Split-brain 은 2노드 클러스터에서 특별히 문제가 되는데, 어느 한 노드가 죽으면 다른 노드는 클러스터 노드의 과반수로 구성이 되지 않기 때문이다.
이 예시에서, 모든 노드가 하나의 투표를 가진다면, 노드4와 노드5는 총 투표권 5개의 반을 넘지 못하는 2개이므로 위와 같은 상황은 발생할 수 없다. 이 상황에서 노드4,5는 다른 투표수가 하나 더 추가될때까지 작동을 멈추게 된다. 반면에 노드1,2,3은 총 투표의 절반이상인 3표를 가지므로 서비스를 계속 제공할 수 있게 된다.
* 쿼럼 계산하기
쿼럼은 corosync 컴포넌트인 votequorum에 의해 계산되고 관리된다. votequorum 컴포넌트는 클러스터가 quorate인지 계산하기 위해 2개의 값을 사용한다.
- expected votes : 모든 클러스터 노드가 정상작동하고 서로 잘 통신하고 있는 상태에서 기대되는 투표의 개수
- total votes : 현재 존재하는 투표 총 수. 만약 어떤 노드가 올라오지 않았거나, 클러스터와 통신이 안된다면
이 값은 expected votes 보다 작을 수 있다.
쿼럼을 달성하기 위해 필요한 투표의 개수는 expected votes 를 기준으로 한다. 아래 계산식은 쿼럼을 달성하기 위해 얼마나 투표가 필요한지 수를 보여준다. 이 계산에서, floor()는 항상 반내림한다.
3노드 클러스터의 경우 예시
아래 예시에서, 3노드 클러스터를 가정한다. 3노드 클러스터의 expected votes 는 3이다. 3노드 클러스터에서, 쿼럼을 달성하려면 최소2노드어야야 한다.
4노드 클러스터의 경우 예시
4노드 클러스터의 expected votes 는 4이다. 4노드 클러스터에서, 쿼럼을 달성하려면 최소 3노드여야 한다.
* 쿼럼 상태 확인하기
High Availability Add-on은 클러스터의 쿼럼 상태를 포괄적으로 보여주는 명령어를 제공한다. 이 명령은 pcs quorum status 이다. 이 명령은 쿼럼 관계된 정보들의 개요를 보여준다. total votes, expected votes 등등의 정보를 보여준다. 그리고 현재 쿼럼을 달성했는지 한눈에 보여준다.
1. 클러스터에 있는 노드의 수
2. pcs quorum status 명령을 친 노드의 node ID
3. 클러스터가 쿼럼을 달성했다면, yes 라고 나옴.
4. 만약 클러스터 내에 모든 구성된 클러스터 멤버가 활성화되어있다면, 현재 존재하는 투표의 수를 보여준다.
5. The Highest expected entry shows the largest value of expected votes that corosync could see at the last transition and is always expected to be the same as Expected votes.
6. 클러스터 내에서 현재 존재하는 투표 수
7. 클러스터가 쿼럼을 달성하기 위해 최소 필요한 수
8. 플래그 항목에는 클러스터에 현재 설정되어 있는 쿼럼 관련 속성이 표시된다. 클러스터가 정족수 상태인 경우 Quorate 속성이 표시된다. LastManStanding 또는 WaitForAll과 같은 추가 특수 기능이 설정되어 있으면 이 필드에 표시된다.
* 실습 : 쿼럼 작업 살펴보기
아래 명령으로 현재 상태를 본다.
아래와 같이 방화벽을 막아버려서, 노드c 가 클러스터와 통신을 못하게 하자.
이건 쉘 파일로 만들어놓은 막아놓는 룰이다.
이렇게 하면, 다른 노드들이 해당 노드c에 연결할 수 없기 때문에, 클러스터는 노드c를 펜스한다.
이제 상태를보자
기대되는 투표는 4개이나 실제 투표는 3개이다. 노드도 3개로 확인된다. 또한 아래 멤버쉽 정보에서도 해당 노드가 나오지 않는다.
기다리면 nodec가 살아나서 조인될것이며, 다시 정상화된다.
다른 테스트를 해보자. 노드b,c를 아예 꺼버린다.
참고 : 클러스터는 위 두 노드는 펜스하지 않는다. 왜냐면, gracefully 하게 셧다운 했기 때문이다. 클러스터는 unexpectedly unresponsive node만 펜스한다.
노드a에서 아까 watch pcs quorum을 하고 있었는데, 보면 아래처럼 나온다.
이 명령어는 더이상 작동하지 않는다. 왜냐면, 클러스터가 쿼럼을 잃었기 때문이다.
그러나, 사용자는 여전히 corosync-quorumtool 명령은 사용이 가능하다. 아래처럼 명령어를 쳐보자.
여기 보면 quorum이 activity blocked 라고 나와있다. 클러스터는 활동을 막은 상태이다. 왜냐면 4 노드 클러스터는 3개의 투표가 필요한데 지금 2개만 있기 때문이다. 리소스 손상을 방지하기 위해, 클러스터가 클러스터 리소스에 대한 시작/중지/리소스를 건드리는 작업등에서 quit 하게 된다.
노드b를 켜고 다시 상태를 보자. 다시 pcs quorum status 를 쳐서 상태를 보자. 기다리면 노드b가 조인되므로, 다시 쿼럼을 얻었다 근데 아직 여전히 하나는 노드가 없다.
* 쿼럼 계산 옵션들
위에서 설명한 기본적인 쿼럼 계산 옵션을 변경할 수 있다. votequorum 컴포넌트는 쿼럼 계산을 수정하는 방법을 가진 쿼럼 옵션을 줘서 클러스터를 만들 수 있게 허용한다. pcs cluster setup 명령을 줄 때, 아래 쿼럼 옵션을 줘서 클러스터 내에서 쿼럼의 행동을 변경할 수 있다. 이러한 쿼럼 옵션들은 새 클러스터 생성시 조합할 수 있고 또한 생성된 클러스터에서 변경할 수도 있다. 아래는 새 클러스터 생성시 예시이다.
* wait_for_all=1
쿼럼 계산을 시작하기 전에 모든 클러스터 구성원이 온라인 상태가 될 때까지 기다린다. 이 설정은 클러스터가 시작될 때 fence race을 효과적으로 방지한다. 이 설정을 사용하지 않으면 클러스터에 참여하지 않았거나 깨끗하게 종료되지 않은 모든 노드는 쿼럼이 달성되는 즉시 자동으로 펜싱됩니다.
* auto_tie_breaker=1
기본 50% + 1표가 아닌 클러스터 노드의 50%만 참여해도 쿼럼을 달성할 수 있다. 50% 대 50%의 split brain 상황의 경우, 가장 낮은(lowest) node ID가 참여하는 쪽이 쿼럼을 얻는다. 추가적으로, auto_tie_breaker 옵션과 last_man_standing 을 사용하면, 클러스터를 one node로 다운그레이드 시킬 수 있다.
* last_man_standing=1
default 로, 10초마다 expected votes가 다시 계산된다. 이를 통해 시스템 관리자는 클러스터에 활발하게 참여하는 노드가 두 개만 남을 때까지 클러스터 노드를 하나씩 클러스터에서 연결 해제할 수 있다. 클러스터 노드의 연결을 너무 빨리 끊으면 두 개 이상의 노드가 작동 중임에도 불구하고 쿼럼이 손실될 수 있다. 또한 last_man_standing=1은 여러 파티션들(클러스터의 하위집합(subsets))이 동시에 쿼럼을 요청하는것을 막기 위해 또한 wait_for_all도 같이 사용해야 한다.
* last_man_standing_window=10000
시스템 관리자는 이 값을 사용하여, 클러스터 내에서 한 노드가 참여하는것을 중단할 때 expected votes가 재계산될때까지의 시간(밀리세컨드) 을 변경하도록 할 수 있다. - 디폴트값은 10000 밀리세컨드 (10초) 이다.
* 존재하는 클러스터에서 쿼럼옵션 변경하기
클러스터 쿼럼 계산은 기존 클러스터에서도 영향을 받을 수 있다. 쿼럼 옵션 변경시 클러스터를 다시 시작하여 corosync가 새 구성을 적용하게 하기 위해 운영 중인 클러스터는 다운타임이 필요하다. pcs cluster stop --all로 클러스터를 중지하고, pcs quorum update명령으로 쿼럼 옵션을 수정할 수 있다. 다음 예제에서는 last_man_standing, wait_for_all 및 auto_tie_breaker 옵션을 사용하도록 설정한다.
새로운 옵션이 활성화되고 시작된 클러스터는 아래처럼 flags 부분이 변경된 것을 확인할 수 있다. 또한 pcs quorum config 명령으로도 확인 가능하다.
또한 클러스터의 쿼럼 관련 옵션이 있는 구성 파일은 /etc/corosync/ corosync.conf 이다. 모든 쿼럼 관련 옵션은 쿼럼 지시어에 설정된다. 이 구성파일은 모든 클러스터 내 노드끼리 동일해야 한다.
구성 변경 관련하여 Redhat은 pcs quorum update 를 권고한다. 이 명령은 이 corosync.conf 파일을 명령어를 친 서버에서 먼저 업데이트 하고, 클러스터가 멈춰있다 하더라도 자동으로 다른 모든 노드와 동기화를 시킨다. corosync.conf 파일을 수동으로 수정할 수도 있다 (레드햇은 권장하지 않음) 이 경우 pcs cluster sync 명령으로 모든 노드에다가 해당 파일을 복제해야만 한다. 그 후 클러스터를 시작한다.
* References
votequorum(5) , corosync-quorumtool(8) man page
For more information, refer to the Cluster quorum chapter in the Configuring and managing high availability clusters at
