Watch & Learn

* pcs alert 유틸리티를 사용하여 클러스터 모니터링하기

클러스터 내의 모든 이벤트는 모니터링될 수 있다. 이벤트는 노드 시작, 리소스 실패, 클러스터 구성 변경 등이 될 수 있다. 클러스터 모니터링은 중요한데 왜냐면 이것은 클러스터 상태에 대한 정보를 제공하기 때문이다. 즉, 시스템 관리자는 일부 이벤트에 대하여 알림을 받을 수 있도록 모니터링을 해야한다. 예를들어, 노드가 fail 되면 클러스터가 메시지를 보내게 할 수 있다. 이렇게 하면 클러스터의 모든 문제를 인지하고 적절히 대응할 수 있다.

세세한 모니터링을 위해, High Availability Add-on은 pcs alert 라는 유틸리티를 제공한다. 이 유틸리티는 클러스터가 alert을 보내는 것을 호출하는 외부 프로그램, alert agents 라는 프로그램을 사용한다. alert agents 를 호출하면, 클러스터는 정보를 alert agents에 제공하기 위해 환경 변수를 사용한다. alert agents를 사용하기 위한 환경 변수에 대해 더 보려면 다음을 참고한다. (The Environment Variables Passed to Alert Agents table https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html-single/configuring_and_managing_high_availability_clusters/index#tb-alert-environmentvariables-HAAR)

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

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html-single/configuring_and_managing_high_availability_clusters/index#assembly_configuring-pacemaker-alert-agents_configuring-and-managing-high-availability-clusters

Knowledgebase: "Can we configure pacemaker cluster to send Email notification when a resource goes in stopped state ?" https://access.redhat.com/solutions/4210311

* 실습 : 메일 알림 구성하기 (mailto, alert)

(1) 메일 수신자 설정

우선 메일 받는 워크스테이션쪽에 아래 앤서블을 실행하여 설치 및 구성한다.

1. 이 플레이는 localhost 에서 실행한다.

2. 이 전체 플레이북은 로컬로 실행한다.

3. 첫번째 작업은 postfix랑 mutt를 설치한다.

4. 두번째 작업은 /home/student/Mail 디렉토리를 생성한다.

5. 세번째 작업은, inet_interfaces=all 파라미터를 설정한다.

6. 네번째 작업은, 방화벽을 준비한다.

7. 마지막 작업은, postfix 서비스를 enable하고 시작한다.

(2) mailto 구성

이제 각 노드에 구성하는 플레이북을 만들자.

1. 플레이 타겟은 nodes 이다. 모든 노드들이다. 3클러스터 노드.  이 모든 작업은 3노드에 실행된다.

2. 첫번째 작업은 postfix랑 mailx를 설치한다.

3. 마지막 작업은  postfix서비스를 enable한다.

이제 mailto 리소스를 구성해본다.

리소스명은 webmail 이고, firstweb 그룹에 들어간다. 이게 트리거되면, 제목은 CLUSTER-NOTIFICATION 이 들어가고, student@workstation.lab.example.com 으로 메일을 보낸다. 

내 workstation 머신에서, mutt를 student 유저로 실행해서 생성된 메시지를 본다. 제목이 CLUSTER-NOTIFICATION 인지 확인한다.  클러스터가 해당 리소스 그룹을 relocate, stop, start 할때 메일이 오는지 확인한다.

(3) alert 구성

alert agent를 설치하고,  이 에이전트를 사용하여 클러스터 이벤트를 이메일 메시지로 를 이메일 메시지로 보내도록 alert 를 구성할 수 있다. 구성값은 다음과 같다.

이것도 플레이북으로 만든다.  (예시에서는 이미 파일이 존재함)

이제 alert agent를 구성한다. 위 테이블에 있는 세팅값을 사용한다.

이메일 수신자를 지정한다.

생성된 alert을 본다.

firstweb 리소스 그룹을 수동으로 이동해서 알림이 오는지 보자. 또한 nodec에서 네트워크 통신에 문제를 일으켜 펜스되면 또 메시지가 어떻게 오는지 보자.

nodea 에서, pcs status 로 상태를 보자. nodec 가 다시 클러스터 조인되는것도 보자. 기다리면 노드c는 재시작되어 조인된다.

이제 workstation에서 메시지들을 보자.  타임스탬프로 시작하고 cluster1: resource operation  텍스트가 포함된 제목이 있는 이메일 메시지를 살펴본다. 이러한 이메일은 클러스터 및 클러스터 리소스에 대한 변경 사항을 알려준다.

* 클러스터 로깅 구성하기

클러스터 트러블슈팅시, 가장 유용한 자원은 시스템 로그이다. 클러스터 로그는 크게 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의 로그를 보려면 다음과 같이 한다.

* References

corosync.conf(5) man page 

/etc/corosync/corosync.conf.example configuration file 

/etc/sysconfig/pacemaker configuration file

Knowledgebase: "How do I configure logging for corosync in Red Hat Enterprise Linux (RHEL) 8 High Availability clusters?" https://access.redhat.com/solutions/5017511

* 로그 분석하기 예시

현재 아래와 같이 정상적으로 사용중이다.

현재 리소스는 nodea에 있으며, 내가 할때는 nodeb등에 있을 수 있음. 정상임.

네트워크 커뮤니케이션에 문제를 일으켜 노드a를 펜스시키자. 아래 스크립트를 사용한다.

다른노드에서 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 

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html-single/configuring_and_managing_high_availability_clusters/index#assembly_configuring-cluster-quorum-configuring-and-managing-high-availability-clusters

For more information, refer to the Cluster quorum chapter in the Configuring and managing high availability clusters guide at 

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html-single/configuring_and_managing_high_availability_clusters/index#assembly_configuring-cluster-quorum-configuring-and-managing-high-availability-clusters

* 실습 : 클러스터에 새로운 쿼럼 옵션 넣기 , last man standing 옵션 확인

아래처럼 현재 아무 옵션도 없음.

클러스터 전체를 내린다.

옵션을 추가한다.

다시 클러스터 시작

구성 확인

이제 nodec 를 끄고 클러스터가 degrade 되는걸 확인한다.

이거 켜놓고 노드c 를 끈다.

다시 pcs quorum status 명령 실행되고 있는 곳으로 간다.

nodec 가 죽고 10초 후에, 클러스터는 expected votes를 4에서 3으로 바꾼다.

따라서 클러스터는 쿼럼값도 2로 다시 계산한다.

노드가 정상적으로 클러스터를 떠나면, 클러스터는 위와 같은 식으로 동작하게 되는 것이다.

또한 사용자는  클러스터가 쿼럼을 다시 계산하는데 있어 대기 시간을 제어하기 위해 last_man_standing_window 옵션을 사용할 수 있다. 기본값은10초 (10000밀리초) 이다.

노드d도 끈다.

이제 pcs quorum status 를 보면, 노드d stop 작업을 한 후 10초 후에 클러스터는 expected vote를 3에서 2로 줄인것을 알 수 있다.

만약 last_man_standing 옵션을 활성화하지 않았따면, 클러스터는 두번째 노드가 죽었을 떄 쿼럼을 달성하지 못했을 것이다.

기본적으로 4노드 클러스터는 쿼럼을 얻기 위해 3개의 노드가 작동해야 된다는 것을 기억해야 한다.

일반적으로, 클러스터가 쿼럼 상태를 유지하려면 최소 2개의 노드가 작동해야 하므로, quorum 값은 1로 줄어들지 않는다.

디폴트로 클러스터는 하나의 노드로 작동하는것을 허용하지 않기 때문에, quorum 값은 1이 될수가 없다.

남은 노드가 하나만 있는 상태에서 계속 작동하는 2노드 클러스터를 만들 수 있는 구성은 따로 있다.

* 단일 장애 지점(SPoF) 이란? 

Single Point of failure (SPoF) 는 복잡한 설치의 특정 부분이 장애가 나면, 전체 환경이 박살나는 그 부분들을 말한다. 메탈 체인이 하나라도 망가진다면 전체 체인이망가진다.일반적인 HA 클러스터는, 여러 SPoF 가 있을 수 있다. 아래는 일부의 예시이다.

하드웨어 SPoF

소프트웨어 SPoF

* Network Redundancy 를 통해 클러스터 가용성 높이기

corosync는 corosync의 네트워크 통신 레이어에서 kronosnet (또는 knet) 에 의존한다. knet은 클러스터 커뮤니케이션에 있어서 추상화 레이어에서 이중화와 보안을 제공한다. knet, corosync를 함께 사용하여 최대 8개의 분리된 네트워크에서 노드간 통신을 설립할 수 있다. 하나의 네트워크가 죽으면, 커뮤니케이션은 다른 남아있는네트워크에서 지속된다. knet은 각 서로 다른 서브넷을 가진 네트워크 링크를 요구한다. 만약 동일한 서브넷에서 여러개의 네트워크 인터페이스를 사용하려면 그대신 티밍을 사용해야 한다.

Red Hat은 크로스오버 이더넷 케이블을 사용하여 두 시스템을 다이렉트로 연결하는 것을 지원하지 않는다. 또한 Red Hat은 일반적인 클러스터 사용시 여러개의 네트워크 연결을 지원하지만, DLM을 사용할 때 하나의 네트워크 연결만 지원합니다. 이 제한은  lvmlockd, LVM 공유 볼륨 그룹 및 GFS2 모두 DLM에 의존하기 때문에 이것들 모두 적용됩니다.  

클러스터를 관리하기 위해 사용하는 pcs명령과 이것과 연관된 pcsd 데몬은  knet을 사용하지 않는다. 이 노드는 클러스터를 만들 때 지정한 노드 이름과 연결된 네트워크를 통해 pcs host auth 및 pcs cluster setup 명령으로 통신한다. 해당 네트워크가 장애나면, pcs 명령은 더이상 작동하지 않는다. 클러스터가 여전히 잘 작동하고 있고, 그것이 여러개의 knet 링크 때문이라 하더라도, pcs. 명령은 더이상 작동하지 않는다.  pcs 명령이 사용되는 네트워크를 보호하려면, teaming을 사용해야 한다.

여러개의 링크와 함께 클러스터 구성하기

pcs cluster setup명령으로 새로은 클러스터를 만들때, 각 서버의 사용할 링크 서브넷의 ip주소를 제공하면 여러개의 링크를 구성할 수 있다. 아래 예시는, 네개노드 클러스터이고, 3개의 통신링크를 만든다. 192.168.0.0/24 , 10.4.0.0/16 , 172.16.0.0/16 서브넷이다. addr 옵션을 각 노드 이름 뒤에 사용하여 각 서브넷들을 제공한다.

존재하는 클러스터에 링크 추가하기

pcs cluster link add 명령으로 존재하는 클러스터에 링크를 추가할 수 있다. 사용자는 꼭 각 노드의 새로운 서브넷의 ip주소를 제공해야 한다.  아래예시는 192.168.100.0/24 대역의 링크 하나를 4개 노드 클러스터에 더하는 것이다.

링크 구성 정보 확인

클러스터는 링크 구성 정보를 /etc/corosync/corosync.conf파일에 저장한다. 아래 예시는 각 클러스터 노드가 링크들을 보여주는 섹션이 있는걸알려준다.  클러스터는 유니크 링 넘버로 각 링크들을 식별한다. 위 예시에서는 0~3까지이다. 0,1,2,3

클러스터에서 링크 삭제하기

링크를 제거하기 위해서는 pcs cluster link remove 링번호. 명령을 사용한다. 아래 예시는 링 넘버 3  (192.168.100.0/24)를 삭제한다.

로그상에서 링크 다운 확인하기

트러블슈팅을 위해, /var/log/cluster/corosync.log파일에서 링넘버등을 확인할 수 있다. 아래 예시는 로그에서 해당 링크가 다운된것을 보여준다. 위corosync.conf 파일대로라면, 해당 링은 링크1인 호스트2가 문제가 있다는것을 확인할 수 있다.

* 실습 : 클러스터 통신에 대한 네트워크 이중화 구성

노드는 a,b,c 3노드이다. 클러스터 구성 전 작업은 모두 되어있다. (방화벽, pcsd 등)

노드a 에서, 아래 확인

클러스터 만들때 리던던트 통신 채널을 함께 만든다.

클러스터 시작 및 enable  

 
클러스터가 이런식으로 구성되어 있다. (펜스 부분은 skip) 

이제 192.168.2.0/24 대역을 쓰는 네트워크를 확인하자. 

해당 네트워크를 끊는다. 

다시 상태를 본다. 멀쩡하다 

corosync 로그를 본다. 링크1이 죽어서 호스트 2,3이 다운된걸 확인할 수 있다.

(호스트1은 현재 이 노드a 이다. 로그는 항상 주관 적이므로) 

corosync 파일을 본다. 

* Fencing Level 만들기

여러 레벨의 펜싱 구성

단일 노드에 여러 개의 펜스 장치를 사용할 수 있는 경우 계층화된 토폴로지로 구성할 수 있다. 예를 들어, IPMI over LAN 및 APC by Schneider Electric(이전의American Power Conversion Corporation) 네트워크 전원 스위치 장치를 사용할 수 있는 환경에서 클러스터는 먼저 fence_ipmilan 펜싱 에이전트를 시도할 수 있다. 이후 실패하면 클러스터는 APC 전원 스위치에 액세스하여 노드의 전원을 끄는 fence_apc 펜싱 에이전트를 사용할 수 있다.

이러한 유형의 이중화 펜싱은 펜싱 레벨로 stonith 리소스를 구성하여 구현할 수 있다. 클러스터는 1부터 시작하는 순차 번호로 각 펜싱 레벨을 식별한다. 클러스터가 노드를 펜싱할 때, 먼저 레벨에 추가한 순서대로 레벨 1에 있는 모든 펜싱 장치를 사용하려고 시도한다. 모두 성공하면 클러스터는 노드가 펜싱된 것으로 간주하고 거기서 멈춘다. 그러나 펜싱 장치 중 하나라도 실패하면 클러스터는 해당 레벨의 처리를 중지하고 레벨 2의 펜싱 장치로 계속 진행하는 식으로 계속 진행한다.

Fencing Level 만들기

펜싱 레벨을 추가하기 전에, 모든 stonith 리소스를 구성해두어야 한다. 다 되었다면, pcs stonith level add  레벨 노드명 장치명 을 사용한다. 아래 예시는 2개의펜스레벨을 노드1에 대하여 지정한다.

Fencing Level 관리하기

pcs stonith level 명령으로 레벨 볼 수 있다.

Fencing Level 제거하기

클러스터 노드에 대한 레벨을 제거하기 위해서는 pcs stonith level remove 레벨 노드 명령을 사용한다.

클러스터 노드의 모든 레벨을 제거하기 위해서는,  pcs stonith level clear 노드명 을 사용한다.

노드 이름을 제공하지 않으면, 모든 노드의 모든 펜스 레벨이 제거된다.

장비를 더 추가하기

pcs stonith level 명령은 현재 존재하는 펜스 레벨에 노드를 추가하는것은 제공하지 않는다. 노드를 더하기 위해서는, 전체 레벨을 삭제하고 다시 만들어야 한다.

* Redundant  파워 서플라이 펜싱 구성하기

신중한 구성이 필요한 일반적인 설정은 중복 전원 공급 장치가 있는 노드에 전원 펜싱을 적용하는 것이다. 펜싱 프로세스 중에 클러스터는 노드를 효과적으로 펜싱하기 위해 두 전원 공급 장치에서 전원을 제거해야 한다.

중복 전원 공급 장치로 노드를 올바르게 펜싱하려면 전원 공급 장치당 하나씩 스토니스 리소스를 생성한 다음 동일한 펜스 레벨에 추가한다. 한 레벨에 여러 장치를 추가하려면 pcs stonith level add 명령에 쉼표로 구분된 STONITH 리소스 목록을 입력한다. 다음 예는 node1 머신을 펜싱하기 위해 두 개의 STONITH 리소스를 생성한다. . 해당 머신에는 두 개의 APC 전원 스위치에 연결된 두 개의 전원 공급 장치가 있다. STONITH 리소스는 fence_apc 에이전트를 사용하여 이 두 전원 스위치를 주소 지정한다. 마지막으로, 마지막 명령은 두 리소스로 펜스 레벨 1을 생성한다.

동일한 레벨에서 stonith 리소스를 추가하면 클러스터는 먼저 모든 서버에 대해 "off" 동작을 수행한 다음 모든 서버에대해 "on" 동작을 실행한다. 이 동작은 특정 시점에 모든 노드의 전원이 꺼지도록 보장하여 노드를 효과적으로 펜싱한다. Red Hat Enterprise Linux 7.1 및 이전 버전에서는 클러스터가 이러한 방식으로 작동하지 않으며 더 복잡한 구성이 필요하다. 상세 추가 정보는 다음 링크를 참고할 것. Knowledgebase: "How can I configure fencing for redundant power supplies in a RHEL 6 or 7 High Availability cluster with pacemaker?" [https://access.redhat.com/solutions/1173123] for more information.

 * 실습 : 여러 펜스 디바이스 레벨 만들기

현재 펜스구성 확인

 
이미 클러스터에는 fence_ipmilan 으로 펜스를 구성해둠.
클래스룸에는 두번째 펜스장치를 할 디바이스를 제공함. fence_rh436을 쓸것임. 

pcmk_host_map 파라미터에는 노드와 , 그에 연관된 플러그 넘버를 적는다. 타임아웃은 180초이며 power_timeout 파라미터를 사용한다.
 
추가된 상태를 보자. 

이렇게 하면 클러스터가 노드a를 펜스해야 할떄, 첫번째로 fence_nodea를 쓰고, 이게 페일되면 그다음 fence_classroom을 쓴다.
 

다른 노드에서 반복하자. 

결과를 보자. 

2번펜싱레벨을 쓰는지 보자.
IP 설정을 broke.example.com으로 변경하여 의도적으로 fence_nodec 펜스 장치의 구성에 문제를 일으킨다.
완료되면 nodec 머신에 펜싱을 시도한 다음 클러스터가 머신을 성공적으로 펜싱했는지 확인합니다. 

상태먼저 보자 

펜싱을 날려보자 

클러스터가 성공이라고 한다. 첫번째 레벨은 안됐지만 두번째 레벨을 진행해서 성공한것이다.
 
 
 
   

* References 

corosync.conf(5) man page 

Knowledgebase: "Support Policies for RHEL High Availability Clusters - Cluster Interconnect Network Interfaces"

https://access.redhat.com/articles/3068841

For more information, refer to Creating a high availability cluster with multiple links section in the Configuring and managing high availability clusters guide at 

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html-single/configuring_and_managing_high_availability_clusters/index#proc_configure-multiple-ip-cluster-creating-high-availability-cluster

For more information, refer to the Configuring fencing levels section in the Configuring and managing high availability clusters guide at

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html-single/configuring_and_managing_high_availability_clusters/index#proc_configuring-fencing-levels-configuring-fencing

 * GFS2 파일시스템의 개요

GFS2 파일시스템은 여러 노드에서 동시에 읽기쓰기를 할 수 있는 클러스터 파일시스템이다. 일반 파일시스템과 비슷한 기능을 지원한다. 예를들어 POSIX ACLs, extended attributes, quotas, symbolic links, SElinux 지원 등 모두 지원한다. 동시 접근을 관리하기 위해, GFS2 는 rhel 클러스터 인프라를 사용해 노드를모니터링하고, 펜싱하고, DLM (distributed lock manager) 을 사용해 파일 및 디렉토릭의 잠금을 제어한다.

각 클러스터 노드는 gfs2파일시스템을 모니터링하는데에 각각 분리된 journal을 사용한다. 한 노드가 죽으면, 클러스터는 해당 노드를 펜스한다. 그리고 다른 노드중하나에서 해당 journal을  replay 한다. 사용자는 이러한 저널을 파일시스템 생성할때 할당한다. 그러나 또한 사용자는 존재하는 파일시스템에 추가적인 저널을 추가할수 있다. 

레드햇은 gfs2파일시스템에 대하여 싱글의 경우, 그리고 16개 이상의 노드를 가진 클러스터의 경우에는 지원하지 않는다. 또한 레드햇은 lvm shared lv에 최상단에파일시스템을 만드는 경우에만 gfs2 를 기술지원한다. 한 노드에 마운트하는 파일시스템을 gfs2로 만들지 말아야 한다. 단독 사용에는 xfs가 더 성능도 좋고 설치와관리도 편하다.

순수한 64비트 환경에서, gfs2 파일시스템은 이론적으로 8EiB까지 확장할 수 있다. 그러나, 최대 gfs2 파일시스템 사이즈는 레드햇은 100TiB까지 지원한다. 또한 대부분 설치 환경에서, 큰 사이즈의 gfs2 1개보다 작은 사이즈의 gfs2 여러개가 더 좋다. 큰 사이즈의 gfs2에서, fsck.gfs2 를 수행하면 엄청난 시간을 소요하며 메모리도 많이 먹는다. 또한 이 파일시스템을 리스토어할 때도 많은 시간을 소요한다.

레드햇은 gfs2 파일시스템을 Resilient Storage Add-on 의 일부로 제공한다. grfs2는 클러스터 인프라스트럭쳐가 필요하기 때문이다. 따라서 Resilient Storage Add-on 외에 High Availability Add-on 도 필요하다.

* gfs2 구성 전 사전 확인사항

요구사항 

High Availability Add-on : resilient storage (gfs2) 는 fence 장치와 함께 작동하기 위해 클러스터 인프라에 의존한다.

lvm 공유 볼륨 그룹과 공유 논리 볼륨 :  레드햇은 LVM 공유 볼륨 그룹의 논리 볼륨 위에 파일 시스템을 배포할 때 GFS2를 지원합니다. 모든 클러스터 노드에서 논리 볼륨을 activate 해야 한다.

시간 프로토콜 : gfs2는 클러스터 노드의 시스템 시간과 동기화가 필요하다. chrony 를 사용할 수 있다.

gfs2-utils RPM 설치 : 아래와 같이 패키지를 설치해야 구성이 가능하다.

gfs2 구성 시 필요한 정보

클러스터 노드 수

gfs2 파일시스템이 동시에 마운트되는 클러스터 노드의 수는 생성해야 하는 journal 개수를 식별해준다. 만약 클러스터에 노드를 추가한다면, 그전에 이미 추가 journal이 준비되어 있어야 한다.

클러스터 이름

gfs2파일시스템을 만들때는 클러스터 이름을 명시해야 한다.이 클러스터의 멤버들만이 해당 파일시스템을 마운트할 수 있다.

파일시스템 명

각 gfs2 파일시스템은 클러스터 내에서 유니크하게 식별되는 이름을 가진다. 이 이름은 gfs2 파일시스템 생성시 16글자로 제한되는 이름을 만들 수 있다.

lvm 공유 논리 볼륨 이름

gfs2 파일시스템을 포맷하고 마운트하는데 LV를 사용한다.

추가 필요한 설정

글로벌 클러스터 파라미터인 no_quorum_policy를 freeze로 설정해야 한다. 이 파라미터는 쿼럼을 잃었을 때 클러스터가 어떻게 동작할지를 컨트롤한다. 디폴트값인stop는 클러스터가 쿼럼을 잃으면 모든 리소스를 클러스터가 stop 시킨다. 그러나, 정상작동하기 위해 gfs2는 클러스터가 be quorate 인 것을 요구한다. (쿼럼이 있는 상태)

따라서 쿼럼을 잃게 되는 경우, 모든 리소스가 stop 되게 되니  GFS2 파일 시스템 리소스를 중지하려고 한다. 그런데 gfs2는 쿼럼이 있어야만 정상작동하므로 이gfs2에 대한 모든 중지 시도가 실패하여 결국 클러스터가 완전히 실패하게 된다. 이를 방지하기 위해 no-qurum-policy를 freeze로 둠으로써, 클러스터는 쿼럼이 회복될 때까지 리소스를 중지시키지 않고 아무 작업도 수행하지 않게 한다.

* gfs 파일시스템 생성하기

모든 전제 조건이 갖추어지면 어느 노드에서나 mkfs.gfs2 명령을 사용하여 GFS2 파일 시스템을 생성할 수 있다. 다음 표에는 mkfs.gfs2에 대한 가장 일반적인 옵션이 나열되어 있다.

-t <lock_table_name>

- Locking Table의 이름을 정의한다.

- 이 형식은 "클러스터네임:파일시스템네임" 을 따른다.

- 클러스터네임 : 해당 클러스터네임에 포함된 노드만 파일시스템을 마운트할 수 있다.

- 파일시스템네임 : 파일시스템을 식별하는 유니크한 이름이다. 이 이름길이는 16자 까지로 제한되어있다.

-j <저널수>

- 처음 생성시 저널의 개수를 의미한다.

- 사용자는 이후 추가 저널을 넣을 수 있다.

- 각 노드가 접근하는 파일시스템은 동시에 하나의 저널이 필요하다.

- 만약 이 옵션을 생략하면, 디폴트로 한개의 저널이 생성된다.

J <저널 크기>

- 각 저널의 크기를 MiB로 표현한다. 최소 사이즈는 8MiB 이고, 최대 사이즈는  1GiB 이다.

- 디폴트로, mkfs.gfs2명령은 파일시스템 사이즈에 기반하여 값을 계산한다.

- 최상의 성능을 위하여, 레드햇은 128MiB 이상을 권고한다.

아래 예시는  gfs2파일시스템을 어떻게 만들지 보여준다. 이름은 examplegfs2이다. 또한 examplecluster 에 포함되어있다.  저널사이즈는 128MiB이고, 공유 로지컬볼륨은 /dev/lvmsharedvg/lv1 이다.

* 주의사항

테스트 목적으로, mount 명령으로 , 일반적인 파일시스템들과 동일하게 일시적으로 gfs2를 마운트해볼 수 있다. 하지만 프로덕션 레벨에서는, gfs2 파일시스템을 마운트하기위해서는 꼭 클러스터 리소스로서만 마운트해야한다. 만약 수동으로 gfs2를 마운트하면 (mount 명령어로) 그때는 항상 서버를 끄거나 리스타트하기전에 수동으로 umount 를 해줘야 한다. 그렇지 않으면, 시스템은 종료중에 hang 이 발생한다. 동일한 이유로, 절대로 /etc/fstab에 gfs2 파일시스템을 넣지 말아야 한다.

* 클러스터 리소스를 사용하여 GFS2 파일 시스템 마운트하기

GFS2 파일 시스템에 클러스터 파일 시스템 리소스를 사용하면 다른 클러스터 리소스처럼 해당 리소스를 관리하고 제어할 수 있다.  또한 파일 시스템이 정확하고 깔끔하게 마운트 및 마운트 해제되도록 보장한다.

GFS2는 LVM 공유 논리 볼륨에 의존하고, 이는 다시 lvmlockd 및 DLM에 의존하므로 이러한 서비스를 관리하기 위한 리소스를 이미 생성했는지 확인해야 한다. 이전에 클러스터 LVM 구성에서 작업한 dlm, lvmlockd 리소스 설정, 공유 LV 리소스 설정, 리소스 실행 순서를 정의하는 Constraint 설정까지 완료한 후에 gfs2 파일시스템을 생성해야 한다. 다음 명령은 /data 마운트 지점에 /dev/lvmsharedvg/lv1 GFS2 파일 시스템을 마운트하는 파일 시스템 리소스를 생성한다.

이 명령은 리소스를 LVMshared_group 리소스 그룹에 추가한다. (이 LVMshared_group 리소스에는 이미 LVM-activate 리소스가 있고 클론이 되어있음) LVMshared_group 리소스 그룹을 복제했기 때문에 클러스터는 모든 클러스터 노드에서 파일 시스템을 마운트하고 관리하게 된다.

* gfs2 관리 : 파일시스템에 저널 추가하기

파일시스템이 가진 저널보다 더 많은 노드에 gfs2 파일시스템을 마운트할 수 없다. 파일시스템이 얼마나 많은 저널을 가지고 있는지 찾기 위해, gfs2_edit -p journals 명령을 사용한다. 아래 예시대로는 2개의 저널을 가지고 있는것을 알수 있다.

저널을 추가하려면, gfs2_jadd 명령을 사용한다. 

-j 옵션을 써서원하는 저널의 개수를 명시한다.

-J 온션은 새로운 저널의 크기를 MiB로 명시한다. (디폴트는 128 이다. 128MiB)

사용자는 파일시스템의 장치명이나, 마운트 포인트를 줄 수 있다. 아래 예시는 256 MiB의 저널을 만드는것이다. 이 명령은 한 노드에서만 하면 된다.

* gfs2 관리 :  파일 시스템 확장하기

GFS2는 LVM 공유 논리 볼륨에 추가한 여분의 공간을 활용하여 파일 시스템을 확장 할 수 있다. 레드햇은 확장작업 할 때 꼭 파일시스템 데이터를 백업하기를 권고한다. 또한, gfs2는 축소를 할 수 없다.

gfs2_grow 명령을 써서 gfs2 파일시스템을 확장할 수 있다.  파일시스템 장치명이나 마운트포인트를 명시한다. 명령은 이 파일시스템이 마운트되어있는곳 아무데서나 할 수 있다. 아래 예시는 10GiB 로지컬 볼륨을 추가하고, gfs2_grow 로 테스트하고, 실제로 작업한다.

-T 옵션은 테스트 모드를 활성화한다. 이 모드에서는 일반 모든 작업을 진행하나, 실제로 변경을 디스크에 commmit하지만 않는다.

* gfs2 관리 : 파일시스템 복구하기

일반 상황에서, gfs2 파일시스템은 수동 복구가 필요하지 않다. 노드가 죽었을 때, 파일시스템의 무결성을 유지하기 위해서, 클러스터는 노드를 펜스하고, 다른 노드는 그 저널을 리플레이한다. 몇몇 상황에서 , 예를들어 스토리지 장치가 죽었을 경우, 시스템에서 gfs2 파일시스템을 dirty상태 또는 손상된 상태로 둘 수 있다.

이 경우 fsck 명령을 사용하여 파일 시스템을 복구할 수 있다. fsck 명령은 GFS2 파일 시스템을 인식하고 fsck.gfs2 명령을 호출하여 실제 검사를 수행한다. fsck.gfs2 명령을 직접 실행할 수도 있다.

주의할 것

fsck.gfs2 실행하기 전에, 파일시스템을 모든 클러스터 노드에서 umount 해야 한다. 파일시스템이 리소스로서 클러스터에서 관리되고 있다면, 해당 리소스를 disable하여 모든 노드에서 umount 하게 하도록 하자.

아래 예시는 clusterfs를 disable 한다. --wait 옵션은 명령이 작업이 완료될때까지 기다렸다가 결과를 반환하도록 지시한다. 이 예제에서는 명령이 최대 180초 동안 대기한 다음 해당 타이머가 만료(작업이 제대로 안끝나면) 오류를 반환한다.

이후 fsck.gfs2가 완료되면, 다시 해당 리소스를 enable 한다.

* 슈퍼블록을 변경하기

gfs2 파일시스템을 다른 클러스터로 옮기거나,  클러스터 이름을 바꾸는경우, 꼭 해당 gfs2 슈퍼블록안에있는 locking table name을 업데이트 해줘야 한다. 또한, gfs2 슈퍼블록에 변경을 가하기 전에, 파일시스템을 모든 클러스터 노드에서 umount 해야한다. 

tunegfs2 -l 명령으로 gfs2슈퍼블록을 본다.

tunegfs2 -o locktable=<newname> 명령으로 locking table name을 변경한다.

아래 예시는 이름을 newcluster 로 변경한다.

* 노드 추가하기

노드3개 있는 시스템에서 노드 1개를 추가하여 총 노드 4개가 되도록 한다.

현재 있는 파일시스템 마운트 한거 확인

저널 확인

위 결과는 GFS2 파일 시스템에 저널이 3개만 있다는 것을 보여준다. 따라서 네 번째 노드에 해당 파일 시스템을 마운트하려는 경우 추가 저널을 추가해야 한다.

저널 추가

* 파일시스템 증설하기

현재 용량 확인

2기가 늘리는 작업

 늘리기 위해 따로 마운트를 해제하지 않는다. 즉 온라인중에 가능. 다만 I/O가 적을때 하는것이 권장된다.

확인

* References

mkfs.gfs2(8) and mount(8) fsck.gfs2(8), gfs2_edit(8), gfs2_grow(8), gfs2_jadd(8), and tunegfs2(8) man pages 

Knowledgebase: "What are the recommended best practices for mkfs.gfs2?" 

https://access.redhat.com/solutions/2883291

For more information, refer to the GFS2 file systems chapter in the Configuring GFS2 file systems guide at 

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html-single/configuring_gfs2_file_systems/index#assembly_creating-mounting-gfs2-configuring-gfs2-file-systems

For more information, refer to the GFS2 file systems in a cluster chapter in the Configuring and managing high availability clusters guide at 

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html-single/configuring_and_managing_high_availability_clusters/index#assembly_configuring-gfs2-in-a-cluster-configuring-and-managing-high-availability-clusters

Knowledgebase: "What are some examples of GFS & GFS2 workloads that should be avoided?"

https://access.redhat.com/solutions/41223

Knowledgebase: "How can Red Hat assist me in assessing the design of my RHEL High Availability or Resilient Storage cluster?" 

레드햇은 고객이 계획한 클러스터 구성이 지원 가능한지를 리뷰하기 위해 Red Hat for an Architectural review와 컨택하는것을 추천한다.

https://access.redhat.com/articles/2359891

For more information, refer to the Planning a GFS2 file system deployment chapter in the Configuring GFS2 file systems guide at

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html-single/configuring_gfs2_file_systems/index#assembly_planning-gfs2-deployment-configuring-gfs2-file-systems

Knowledgebase: "Do I need to make changes to my GFS/GFS2 file systems when renaming the cluster in RHEL?" https://access.redhat.com/solutions/18430

For more information, refer to the GFS2 file systems and GFS2 file system repair chapters in the Configuring GFS2 file systems guide at 

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html-single/configuring_gfs2_file_systems/index

* LVM configuration 파일 소개

/etc/lvm/lvm.conf 파일은 LVM의 동작을 구성한다. 이 파일은 locking 동작을 제어하는 설정, LVM 서명을 검사해야 하는 장치 및 기타 여러 동작을 제어하는 설정을 가지고 있다. 대부분 상황에서는 이 파일을 수정할 필요가 없다. 클러스터에서는 공유 스토리지로써 LVM을 사용하는 두가지 방법이 있는데, HA-LVM (High Availability LVM) 과 LVM 공유 볼륨 그룹  두가지이다. 각각 방식을 설정할 때lvm.conf의 수정이 필요하다.

* 클러스터 스토리지 방식 1 : High Availability LVM 방식 

한번에 한 노드가 VG를 액세스하고, 그 VG안에 있는 LV에 액세스한다.  HA-LVM은 xfs나 ext4같은 전통적인 파일시스템을 쓰는어플리케이션이 active/passive 형태로 클러스터를 사용할 때 좋은 선택이다. 데이터 커럽션을 막기 위해서, 단 하나의 노드만 vg에 액세스 가능하고 파일시스템 마운트가 가능하다.

HA-LVM 구성 전에, 모든 클러스터 노드에서 LVM을 먼저 설정해야 한다. 이 설정은 여러 노드에서 VG가 활성화되는것을 막기 위해 HA-LVM은 VG 메타데이터 안에 SYSTEM ID를 저장한다. 이 구성을 통해서, 해당 SYSTEM ID와 매치되는 그 볼륨 그룹과 그 볼륨그룹의LV만 활성화 될 수 있다. LVM 은 여러 타입의 SYSTEM ID를 지원하는데, uname 타입은 SYSTEM ID로써 호스트명을 사용한다. 이 방법은 구성하기 쉽다.  uname 타입 구성을 지원하기 위해, 모든 클러스터 노드에서 /etc/lvm/lvm.conf를 수정하고, 거기서system_id_source 파라미터를 uname으로 변경하면 된다.

 이 초기 설정이 끝나면, 평소대로 PV를 만들고 VG를 생성하고 LV를 만들면 된다.

HA LVM 생성 및 리소스 올리기

1. lvm conf 변경

nodea / nodeb / nodec 장비를 HA LVM 쓰도록 준비한다. 각 세 노드에서 /etc/lvm/lvm.conf 에서 아래 부분을 수정한다. (수정 전 백업파일을 꼭 만들도록 하자.)

그리고 각 세 노드에서 lvm systemid 명령으로 확인한다.

2. nodea에서, 평소대로 lvm 생성

PV 생성

VG 생성 

VG를 만들때는, system id도 확인된다. 앞의 결과에서, LVM이 VG의 SYSTEM ID로 호스트명을 사용하는것을 알 수 있다. 이 구성에서는 nodea만 이 VG와 통신할 수 있는것이다. lvm systemid 명령, vgdisplay 명령에서도 해당 VG의 System ID를 확인할 수 있다.

LV 생성

참고로 이 LV에 이전에 FILESYSTEM 시그니쳐가 남아있는경우, 아래처럼 뜨는데 Y 하면 된다.

파일시스템 생성

3. nodea에서 halvm이라는 이름으로  LVM-activate 리소스 에이전트를 만든다.

이 에이전트는 HA-LVM 볼륨그룹을 관리하고,  또한 VG와 VG의 LV 활성화/비활성화를 담당한다. 이리소스는 생성할 때  halvmfs 리소스 그룹에 포함되게 한다. 이 리소스가 시작되면, 해당 리소스를 실행하는 노드에서 clustervg VG가 활성화된다.

4. nodea에 서 파일시스템 리소스를 만든다.

이름은 xfsfs이며, halvmfs 리소스 그룹에 포함된다. 이 파일시스템은 /dev/clustervg/clusterlv LV를 사용하며, 마운트 포인트는 /mnt이다.

LVM-activate 리소스가 먼저 생성되고, 그다음 Filesystem 리소스가 생성되어 순서대로 리소스가 올라가도록 해야한다.

5. 확인

 * 클러스터 스토리지 방식 2 :  LVM 공유 볼륨 그룹

 VG와 LV가 모든 클러스터 노드에 모든 시간에 접근이 가능하다. 한번에 하나의 클러스터 노드에서만 VG에 액세스할 수 있는 HA-LVM과 달리, LVM 공유 VG와 LV는 모든 클러스터 노드에서 동시에 사용할 수 있다. 이를 위해 GFS2 파일시스템을 사용한다. GFS2 파일시스템과 함께 LV 공유 VG는 어플리케이션에서 모든 클러스터 노드에서 해당 데이터에 대한 동시 읽기/쓰기를 제공한다. 이 방식은 여러 노드가 동시에 공유 데이터에 접근하는 방식을 사용하므로, lvm.conf에서 LVM 공유 볼륨 그룹 방식을 구성해야 한다. 다만 실제로 수정하지는 않고 리소스로서 구성한다. 이 구성은 꽤 복잡한 작업이며, 다음 섹션에서 설명한다.

유의해야 할 것은, 클러스터되지 않은 파일시스템, ext4나 xfs를 LVM 공유 볼륨 그룹에서 사용해서는 안된다. 이렇게 구성하고 동시에I/O가 발생하면 해당 파일시스템은 커럽션과 부정합이 나타난다. 이는 데이터 손실을 야기시키므로 절대 해서는 안된다. ext4나 xfs를 사용하지 말고, 클러스터 파일시스템 GFS2와 같은걸 써라. GFS2는 여러 노드에서 동시에 마운트하고 액세스할 수 있다.

LVM 공유 볼륨 그룹을 사용할때, LVM 명령어는 모든 클러스터 내에서 메타데이터 변경을 관리하기 위해 로컬 LVM Locking 데몬(lvmlockd) 과 상호작용한다. 이러한 lvmlockd 프로세스는 각 클러스터 노드에서 실행되고 있어야만 한다. lvmlockd는 High Availability Add-on과 별개로 제공되는 Resilient storage Add-on의 부분 중 하나이며, lvm-2lockd rpm패키지에서 제공된다.

또한 서로 다른 노드에서 실행되고 있는 lvmlockd 프로세스들이 서로 자기들의 작업을 싱크로 하기위해, lvmlockd는 Distributed Lock Manager (DLM)에 의존한다. DLM은 dlm 커널 모듈과 커널 모듈을 pilot하는 dlm_controld 프로세스 두가지로 구성된다. 차례대로, dlm_controld 프로세스는 node membership을 위해 클러스터 infrastructure에 의존한다. dlm RPM 패키지가 DLM을 제공한다.

아래 그래픽은 모든 LVM 공유 볼륨 그룹 사이에 컴포넌트들이 상호작용하는것을 보여준다. DLM과 lvmlockd 인프라스트럭쳐가 구축된 후, 사용자는 전통적인 pvcreate, vgcreate, lvcreate 명령어로 LVM 공유 볼륨그룹을 관리할 수 있다.

LVM 공유 볼륨 그룹 구성을 위한 사전준비 : dlm, lvm2-lockd 구성

1. dlm, lvm2-lockd 설치

dlm은 클러스터 인프라에 의존하므로, 우선 인프라부터 설치해야 한다. 또한 이 인프라는 FENCE DEVICE까지 포함이 된다. 즉 dlm은 클러스터 구성과 펜스등에 연관이 있다는 것이다. dlm과 lvm2-lockd RPM을 각 노드에 설치한다.

2. dlm, lvm2-lockd 프로세스 구성

이제 이 두 dlm_controld와 lvmlockd 프로세스를 모든 노드에서 실행되어야 한다. 그런데 이것은 단순히 데몬으로 띄우는 것이 아니라 클러스터에서 띄워줘야 한다. 따라서 클러스터 리소스로서 이 두가지 프로세스를 실행해야 한다. 레드햇 클러스터에서는 위 두 프로세스를 컨트롤하기 위해  ocf:pacemaker:controld와 ocf:heartbeat:lvmlockd 리소스 에이전트 두가지를 제공한다. 

두 리소스는 하나의 리소스 그룹에서, 정확한 순서대로 생성해야 한다. lvmlockd가 시작하기 전에 DLM이 먼저 시작해야 하기 때문이다. 아래 예시에서는 on-fail 파라미터 fence로 설정했는데, 이것은 어떤 노드에서 이 프로세스중 하나라도 fail이 되면 그 프로세스를 재시작하려고 시도하지 않고 해당 노드를 Fence 한다. 그만큼 이 리소스들은 매우 중요하다.

또한 이 프로세스들이 모든 클러스터 노드에서 무조건 실행되고 있어야 하기 때문에,  이 리소스 그룹을 clone 한다.  interleave 파라미터를 true로 설정하는것은, 로컬 노드에서 dlm_controlled 프로세스가 시작되자마자 lvmlockd 프로세스가 시작될 수 있도록 하는 파라미터이다. 이 파라미터가 없으면 lvmlockd 리소스는 모든 노드에서 모든 dlm_controld 프로세스가 시작될 때까지 대기하게 된다.

3. 상태 확인

pcs status --full 명령을 사용하여, 클러스터와 클러스터 정보에 대한 모든 정보를 보게 한다. 아래 정보는 lock_group 리소스 그룹이 3개의 노드에 실행되고 있음을 보여준다.

4. 참고사항

HA-LVM과 달리,  /etc/lvm/lvm.conf에 있는 system_id_source 파라미터를 건드리지 않는다. LVM 공유 VG의 경우, 기본값인 none 을 그대로 두면 된다. 

LVM 공유 볼륨 그룹과 LV 생성, 그리고 리소스 생성

LVM 공유 VG 인프라스트럭쳐가 설치되었으면, 사용자는 이제 표준 lvm 명령어를 통해 vg와 lv를 생성할 수 있다. (몇가지 옵션을 넣어야 한다) 이 명령어는 한 노드에서만 실행하면 되고, 그 명령어는 lvmlockd가 복제하여 모든 노드에 구성을 실행한다. 참고로 LVM 공유 VG를 변경을 할 때는  lvmlockd가 모든 노드에서 살아있고 정상적이어야 한다.

1. PV 및 VG 생성하기

/dev/sdb에 대하여, 아래 명령을 수행한다. 또한 vgcreate 수행시 --shared 옵션을 넣는다. 이것은 일반적인 로컬 vg가 아닌 LVM 공유VG임을 의미한다.

이후 모든 노드에서, VG가 시작된다. 이 명령을 실행하지 않은 다른 모든 노드에서 VG가 lock을 사용하도록 해야한다.  아래와 같이 수행한다.

2. LV 생성하기

lvcreate에 --activate sy 옵션을 넣어야 한다. 이 옵션은 여러 노드가 LV를 동시에 활성화하고 사용할 수 있게 하는 옵션이다. 이 명령어는 한 노드에서만 하면 된다.

3. 파일시스템 생성

이와 같은 공유 논리 볼륨은 GFS2와 같은 클러스터 파일 시스템에 자주 사용된다.  GFS2 파일 시스템으로 공유 논리 볼륨을 포맷하고 사용하는 방법은 내용이 많아 다음 섹션에서 전달한다.

4.  LVM 공유 VG 리소스 올리기

공유 LV를 클러스터에서 사용하기 위해, 첫번째로 해당 노드에서 activate를 해야한다. RHEL HA 클러스터는 모든 클러스터 노드에서activation을 하기 위해 LVM-activate 라는 리소스 에이전트를 제공한다. 아래 예시는 lvmsharedvg/lv1 LV를 활성화하고LVMshared_group 리소스 그룹에 넣도록 sharedlv1 리소스를 생성한다. 또한 이 예시는 이러한 activation이 모든 클러스터 노드에 수행되도록 resource group를 clone 한다.

현재 해당 리소스 그룹 (LVMshared_group) 은 하나의 리소스만 가지고 있는 상태다. 사용자는 일반적으로 LV를 공유 파일시스템인GFS2로 포맷하고, 이 리소스 그룹의 두번째 리소스로서 파일시스템 마운트를 설정한다. 이것도 마찬가지로 모든 노드에 걸쳐 수행해야 한다. 위 3번 절차처럼 GFS2를 생성하고 마운트하는것은 이후 코스에서 다룬다.

마지막 리소스 그룹 (LVMshared_group) 을 생성한 후에는, 클러스터는 2개의 클론된 리소스 그룹을 가진다. 하나는 DLM과 lvmlockd 프로세스 가 있는 리소스 그룹, 그리고 다른 하나는 공유 LV활성화와 파일시스템 리소스 그룹. 총 2개이다.

공유 LV를 활성화하는것은 DLM과 lvmlockd 프로세스에 의존되므로,  dlm, lvmlcokd 프로세스가 먼저 실행되고, 그 이후에 공유 lv 활성화하는 리소스 그룹이 실행되게 해야 한다. 그렇게 하기 위해 아래와 같이 order와 colocation 컨스트레인트를 두 그룹 사이에 설정해야 한다.

* References

lvmlockd(8) and dlm_controld(8) lvmsystemid(7)  man pages

Knowledgebase: "Support Policies for RHEL Resilient Storage - dlm General Policies" https://access.redhat.com/articles/3068921

For more information, refer to the Configuring a GFS2 file system in a cluster chapter in the Configuring and managing high availability clusters guide at

Configuring and managing high availability clusters Red Hat Enterprise Linux 8 | Red Hat Customer Portal

For more information, refer to the LVM logical volumes in a Red Hat high availability cluster section in the Configuring and managing high availability clusters guide at

Configuring and managing high availability clusters Red Hat Enterprise Linux 8 | Red Hat Customer Portal