GFS2 클러스터형 풀
GFS2 클러스터링은 GFS2 SR을 사용하는 리소스 풀에 필요한 추가 기능을 제공합니다. GFS2에 대한 자세한 내용은 스토리지 구성을 참조하십시오.
GFS2 클러스터는 비클러스터형 풀의 호스트보다 더 긴밀하게 연결되고 조정되는 최대 16개의 XenServer® 호스트로 구성된 풀입니다. GFS2 클러스터의 호스트는 선택된 네트워크에서 서로 지속적으로 통신합니다. GFS2 클러스터의 모든 호스트는 GFS2 클러스터의 각 호스트 상태를 인식합니다. 이러한 호스트 조정은 GFS2 클러스터가 GFS2 SR의 내용에 대한 액세스를 제어할 수 있도록 합니다.
참고:
클러스터링 기능은 GFS2 SR을 포함하는 풀에만 유용합니다. 풀에 GFS2 SR이 포함되어 있지 않으면 풀에서 GFS2 클러스터링을 활성화하지 마십시오.
쿼럼
GFS2 클러스터의 각 호스트는 항상 GFS2 클러스터 내 대다수 호스트(자신 포함)와 통신해야 합니다. 이 상태를 호스트가 쿼럼을 가지고 있다고 합니다. 호스트가 쿼럼을 가지고 있지 않으면 해당 호스트는 자체 펜싱됩니다.
초기 쿼럼을 달성하기 위해 통신해야 하는 호스트 수는 GFS2 클러스터가 쿼럼을 유지하는 데 필요한 호스트 수와 다를 수 있습니다.
다음 표는 이 동작을 요약합니다. n 값은 GFS2 클러스터형 풀의 총 호스트 수입니다.
| 쿼럼 달성에 필요한 호스트 수 | 쿼럼 상태를 유지하는 데 필요한 호스트 수 | |
|---|---|---|
| 풀의 홀수 호스트 수 | (n+1)/2 | (n+1)/2 |
| 풀의 짝수 호스트 수 | (n/2)+1 | n/2 |
GFS2 클러스터형 풀의 경우, GFS2 클러스터의 is-quorate 매개변수를 쿼리하여 풀이 쿼럼을 가지고 있는지 확인할 수 있습니다.
xe cluster-list params=is-quorate uuid=<cluster_id>
GFS2 클러스터에 있는 활성 호스트 수를 확인하려면 다음 명령을 실행하십시오.
xe cluster-list params=live-hosts uuid=<cluster_id>
GFS2 클러스터가 쿼럼을 달성하는 데 필요한 활성 호스트 수를 확인하려면 다음 명령을 실행하십시오.
xe cluster-list params=quorum uuid=<cluster_id>
GFS2 클러스터가 생성될 때 활성 호스트 수는 이 값보다 크거나 같아야 합니다. 쿼럼을 유지하려면 GFS2 클러스터에 홀수 또는 짝수 개의 호스트가 포함되어 있는지 여부에 따라 필요한 호스트 수가 이 명령이 반환하는 값과 다를 수 있습니다.
홀수 개 풀
홀수 개 풀의 쿼럼 값을 달성하려면 GFS2 클러스터의 총 호스트 수보다 하나 더 많은 수의 절반, 즉 (n+1)/2가 필요합니다. 이는 풀이 쿼럼 상태를 유지하기 위해 연락 가능해야 하는 최소 호스트 수이기도 합니다.
예를 들어, 5개 호스트 GFS2 클러스터형 풀에서 GFS2 클러스터가 활성화되고 쿼럼 상태를 유지하려면 3개의 호스트가 연락 가능해야 합니다 [(5+1)/2 = 3].
가능한 경우 GFS2 클러스터형 풀에서 홀수 개의 호스트를 사용하는 것이 좋습니다. 이는 호스트가 쿼럼 세트를 가지고 있는지 항상 확인할 수 있도록 보장하기 때문입니다.
짝수 개 풀
짝수 개 GFS2 클러스터형 풀이 콜드 스타트에서 시작될 때, 호스트가 쿼럼을 갖기 전에 (n/2)+1개의 호스트가 사용 가능해야 합니다. 호스트가 쿼럼을 가지면 GFS2 클러스터가 활성화됩니다.
하지만 활성 짝수 개 풀은 연락 가능한 호스트 수가 최소 n/2인 경우 쿼럼 상태를 유지할 수 있습니다. 결과적으로 짝수 개의 호스트를 가진 실행 중인 GFS2 클러스터가 정확히 절반으로 분할될 수 있습니다. 실행 중인 GFS2 클러스터는 GFS2 클러스터의 어느 절반이 자체 펜싱을 수행하고 어느 절반이 쿼럼을 가질지 결정합니다. GFS2 클러스터 분할 전에 활성 상태로 확인된 가장 낮은 ID를 가진 노드를 포함하는 GFS2 클러스터의 절반은 활성 상태를 유지하고, 다른 절반은 자체 펜싱을 수행합니다.
예를 들어, 4개 호스트 GFS2 클러스터형 풀에서 GFS2 클러스터가 활성화되려면 3개의 호스트가 연락 가능해야 합니다 [4/2 + 1 = 3]. GFS2 클러스터가 활성화된 후 쿼럼 상태를 유지하려면 2개의 호스트만 연락 가능해야 하며 [4/2 = 2], 해당 호스트 세트에는 활성 상태로 알려진 가장 낮은 노드 ID를 가진 호스트가 포함되어야 합니다.
자체 펜싱
호스트가 쿼럼을 가지고 있지 않다고 감지하면 몇 초 내에 자체 펜싱됩니다. 호스트가 자체 펜싱되면 즉시 다시 시작됩니다. 호스트가 강제 종료되기 때문에 호스트에서 실행 중인 모든 VM은 즉시 중지됩니다. 고가용성을 사용하는 GFS2 클러스터형 풀에서 XenServer는 다른 풀 멤버의 재시작 구성에 따라 VM을 다시 시작합니다. 자체 펜싱된 호스트는 다시 시작하고 GFS2 클러스터에 다시 참여하려고 시도합니다.
GFS2 클러스터의 활성 호스트 수가 쿼럼 값보다 적어지면 나머지 모든 호스트는 쿼럼을 잃습니다.
이상적인 시나리오에서는 GFS2 클러스터형 풀이 항상 쿼럼에 필요한 것보다 더 많은 활성 호스트를 가지며 XenServer는 절대 펜싱되지 않습니다. 이 시나리오의 가능성을 높이려면 GFS2 클러스터형 풀을 설정할 때 다음 권장 사항을 고려하십시오.
-
하드웨어 이중화가 잘 되어 있는지 확인하십시오.
-
GFS2 클러스터 네트워크에 전용 본딩 네트워크를 사용하십시오. 본딩된 NIC가 동일한 L2 세그먼트에 있는지 확인하십시오. 자세한 내용은 네트워킹을 참조하십시오.
-
풀과 GFS2 SR 간에 스토리지 멀티패싱을 구성하십시오. 자세한 내용은 스토리지 멀티패싱을 참조하십시오.
GFS2 클러스터형 풀 생성
시작하기 전에 다음 전제 조건이 충족되는지 확인하십시오.
-
GFS2 클러스터형 풀의 모든 XenServer 호스트는 최소 2GiB의 제어 도메인 메모리를 가지고 있어야 합니다.
환경에 따라 호스트에 이보다 더 많은 제어 도메인 메모리가 필요할 수 있습니다. 호스트의 제어 도메인 메모리가 부족하면 풀에서 네트워크 불안정성을 겪을 수 있습니다. 네트워크 불안정성은 GFS2 SR이 있는 GFS2 클러스터형 풀에 문제를 일으킬 수 있습니다. 제어 도메인 메모리 양 변경 및 메모리 동작 모니터링에 대한 자세한 내용은 메모리 사용량을 참조하십시오.
-
GFS2 클러스터의 모든 호스트는 GFS2 클러스터 네트워크에 고정 IP 주소를 사용해야 합니다.
-
2개의 호스트로 구성된 풀은 전체 풀의 자체 펜싱에 민감하기 때문에 GFS2 클러스터링은 최소 3개 이상의 호스트를 포함하는 풀에서만 사용하는 것이 좋습니다.
-
GFS2 클러스터형 풀은 풀당 최대 16개의 호스트만 지원합니다.
- 풀의 호스트 간에 방화벽이 있는 경우, 호스트가 다음 포트를 사용하여 GFS2 클러스터 네트워크에서 통신할 수 있는지 확인하십시오.
- TCP: 8892, 8896, 21064
- UDP: 5404, 5405
자세한 내용은 XenServer에서 사용하는 통신 포트를 참조하십시오.
-
기존 풀에 GFS2 클러스터링을 추가하는 경우 고가용성이 비활성화되어 있는지 확인하십시오. 클러스터링이 활성화된 후 고가용성을 다시 활성화할 수 있습니다.
- 다른 트래픽에 사용되지 않는 GFS2 클러스터형 풀에 본딩된 네트워크를 사용하는 것이 좋습니다.
원하는 경우 XenCenter를 사용하여 풀에 GFS2 클러스터링을 설정할 수 있습니다. 자세한 내용은 XenCenter 제품 설명서를 참조하십시오.
xe CLI를 사용하여 GFS2 클러스터형 풀을 생성하려면 다음을 수행합니다.
-
GFS2 클러스터 네트워크로 사용할 본딩된 네트워크를 생성합니다.
참고:
GFS2 클러스터형 풀에는 전용 본딩된 네트워크를 사용하는 것이 좋습니다. 이 네트워크를 다른 트래픽에 사용하지 마십시오.
풀 코디네이터로 지정하려는 XenServer 호스트에서 다음 단계를 완료하십시오.
-
XenServer 호스트에서 콘솔을 엽니다.
-
다음 명령을 사용하여 본딩된 NIC와 함께 사용할 네트워크를 생성합니다.
xe network-create name-label=bond0 <!--NeedCopy-->새 네트워크의 UUID가 반환됩니다.
-
다음 명령을 사용하여 본드에서 사용할 PIF의 UUID를 찾습니다.
xe pif-list <!--NeedCopy--> -
활성-활성 모드, 활성-수동 모드 또는 LACP 본드 모드 중 하나로 본딩된 네트워크를 생성합니다. 사용하려는 본드 모드에 따라 다음 작업 중 하나를 완료하십시오.
-
활성-활성 모드(기본값)로 본드를 구성하려면
bond-create명령을 사용하여 본드를 생성합니다. 쉼표를 사용하여 매개변수를 구분하고 새로 생성된 네트워크 UUID와 본딩할 PIF의 UUID를 지정합니다.xe bond-create network-uuid=<network_uuid> / pif-uuids=<pif_uuid_1>,<pif_uuid_2>,<pif_uuid_3>,<pif_uuid_4> <!--NeedCopy-->두 개의 NIC를 본딩할 때는 두 개의 UUID를 입력하고, 네 개의 NIC를 본딩할 때는 네 개의 UUID를 입력합니다. 명령을 실행한 후 본드에 대한 UUID가 반환됩니다.
-
활성-수동 또는 LACP 본드 모드로 본드를 구성하려면 동일한 구문을 사용하고 선택적
mode매개변수를 추가한 다음lacp또는active-backup를 지정합니다.xe bond-create network-uuid=<network_uuid> pif-uuids=<pif_uuid_1>, / <pif_uuid_2>,<pif_uuid_3>,<pif_uuid_4> / mode=balance-slb | active-backup | lacp <!--NeedCopy-->
-
풀 코디네이터에 본딩된 네트워크를 생성한 후 다른 XenServer 호스트를 풀에 연결하면 네트워크 및 본드 정보가 연결하는 서버로 자동으로 복제됩니다.
자세한 내용은 네트워킹을 참조하십시오.
-
-
최소 3개의 XenServer 호스트로 구성된 리소스 풀을 생성합니다.
풀 멤버인 각 XenServer 호스트(마스터가 아닌)에서 다음 단계를 반복합니다.
- XenServer 호스트에서 콘솔을 엽니다.
-
다음 명령을 사용하여 XenServer 호스트를 풀 코디네이터의 풀에 연결합니다.
xe pool-join master-address=master_address master-username=administrators_username master-password=password <!--NeedCopy-->master-address매개변수의 값은 풀 코디네이터인 XenServer 호스트의 정규화된 도메인 이름으로 설정해야 합니다.password는 풀 코디네이터가 설치될 때 설정된 관리자 암호여야 합니다.
자세한 내용은 호스트 및 리소스 풀을 참조하십시오.
-
이 네트워크에 속하는 모든 PIF에 대해
disallow-unplug=true을 설정합니다.-
다음 명령을 사용하여 네트워크에 속하는 PIF의 UUID를 찾습니다.
xe pif-list <!--NeedCopy--> -
리소스 풀의 XenServer 호스트에서 다음 명령을 실행합니다.
xe pif-param-set disallow-unplug=true uuid=<pif_uuid> <!--NeedCopy-->
-
-
풀에서 GFS2 클러스터링을 활성화합니다. 리소스 풀의 XenServer 호스트에서 다음 명령을 실행합니다.
xe cluster-pool-create network-uuid=<network_uuid> <!--NeedCopy-->이전 단계에서 생성한 본딩된 네트워크의 UUID를 제공합니다.
GFS2 클러스터링 비활성화
GFS2 클러스터링을 비활성화할 수 있습니다. GFS2 클러스터링을 비활성화한 후에도 풀은 계속 존재하지만, 더 이상 GFS2 클러스터링되지 않으며 GFS2 SR을 사용할 수 없습니다.
GFS2 클러스터링을 비활성화하려면 다음 명령을 실행합니다.
xe cluster-pool-destroy cluster-uuid=<uuid>
GFS2 클러스터형 풀 관리
GFS2 클러스터형 풀을 관리할 때 다음 방법을 사용하면 풀이 쿼럼을 잃을 위험을 줄일 수 있습니다.
GFS2 클러스터형 풀에 호스트 추가 또는 제거
GFS2 클러스터형 풀에 호스트를 추가하거나 제거할 때 GFS2 클러스터의 모든 호스트가 온라인 상태인지 확인하십시오.
XenCenter를 사용하여 GFS2 클러스터형 풀에 호스트를 추가하거나 제거할 수 있습니다. 자세한 내용은 풀에 서버 추가 및 풀에서 서버 제거를 참조하십시오.
xe CLI를 사용하여 GFS2 클러스터형 풀에 호스트를 추가하거나 제거할 수도 있습니다. 자세한 내용은 xe CLI를 사용하여 풀에 호스트 추가 및 리소스 풀에서 XenServer 호스트 제거를 참조하십시오.
호스트가 정상적으로 종료되었는지 확인
호스트가 정상적으로 종료되면 다시 시작될 때까지 GFS2 클러스터에서 일시적으로 제거됩니다. 호스트가 종료되는 동안에는 GFS2 클러스터의 쿼럼에 포함되지 않습니다. 호스트가 없어도 다른 호스트가 쿼럼을 잃지 않습니다. 자세한 내용은 XenServer 호스트 종료를 참조하십시오.
그러나 호스트가 강제로 또는 예기치 않게 종료되면 오프라인 상태가 되기 전에 GFS2 클러스터에서 제거되지 않습니다. 이 호스트는 GFS2 클러스터의 쿼럼 값에 포함됩니다. 이 호스트의 종료는 다른 호스트가 쿼럼을 잃게 할 수 있습니다.
호스트를 강제로 종료해야 하는 경우, 먼저 GFS2 클러스터에 있는 활성 호스트 수를 확인하십시오. 이 작업은 corosync-quorumtool 명령으로 수행할 수 있습니다. 명령 출력에서 활성 호스트 수는 Total votes: 값이고 쿼럼을 유지하는 데 필요한 활성 호스트 수는 Quorum: 값입니다.
-
활성 호스트 수가 쿼럼을 유지하는 데 필요한 호스트 수와 동일한 경우, 호스트를 강제로 종료하지 마십시오. 그렇게 하면 전체 GFS2 클러스터가 펜싱됩니다.
대신, 다른 호스트를 복구하고 라이브 호스트 수를 늘린 후 호스트를 강제로 종료하십시오.
-
라이브 호스트 수가 정족수를 유지하는 데 필요한 호스트 수에 가까우면 호스트를 강제로 종료할 수 있습니다. 그러나 이렇게 하면 풀의 다른 호스트에 문제가 발생할 경우 GFS2 클러스터가 완전히 펜싱될 위험이 더 커집니다.
GFS2 클러스터의 복원력을 높이려면 종료된 호스트를 가능한 한 빨리 다시 시작하십시오.
유지 보수 모드 사용
호스트가 쿼럼을 잃을 수 있는 작업을 수행하기 전에 호스트를 유지 보수 모드로 전환하십시오. 호스트가 유지 보수 모드에 있으면 실행 중인 VM이 풀의 다른 호스트로 마이그레이션됩니다. 또한 해당 호스트가 풀 코디네이터였다면 해당 역할은 풀의 다른 호스트로 전달됩니다. 유지 보수 모드의 호스트가 자체 펜싱되는 작업을 수행하더라도 VM을 잃거나 풀에 대한 XenCenter® 연결이 끊어지지 않습니다.
유지 보수 모드의 호스트는 GFS2 클러스터의 쿼럼 값에 계속 포함됩니다.
GFS2 클러스터 풀의 일부인 호스트의 IP 주소는 해당 호스트가 유지 보수 모드일 때만 변경할 수 있습니다. 호스트의 IP 주소를 변경하면 호스트가 GFS2 클러스터를 떠나게 됩니다. IP 주소가 성공적으로 변경되면 호스트는 GFS2 클러스터에 다시 참여합니다. 호스트가 GFS2 클러스터에 다시 참여한 후 유지 보수 모드에서 해제할 수 있습니다.
자체 펜싱되었거나 오프라인인 호스트 복구
자체 펜싱된 호스트를 복구하는 것이 중요합니다. 이러한 GFS2 클러스터 멤버가 오프라인 상태인 동안에는 GFS2 클러스터의 쿼럼 수에 포함되며 연락 가능한 GFS2 클러스터 멤버 수가 줄어듭니다. 이 상황은 후속 호스트 장애로 인해 GFS2 클러스터가 쿼럼을 잃고 완전히 종료될 위험을 증가시킵니다.
GFS2 클러스터에 오프라인 호스트가 있으면 특정 작업을 수행할 수 없습니다. GFS2 클러스터 풀에서는 풀의 모든 멤버가 풀 멤버십의 모든 변경 사항에 동의해야 변경 사항이 성공할 수 있습니다. GFS2 클러스터 멤버와 연락할 수 없는 경우 XenServer는 GFS2 클러스터 멤버십을 변경하는 작업(예: 호스트 추가 또는 호스트 제거)을 방지합니다.
호스트를 복구 불가능으로 표시
하나 이상의 오프라인 호스트를 복구할 수 없는 경우 GFS2 클러스터 풀에 해당 호스트를 잊도록 지시할 수 있습니다. 이 호스트는 풀에서 영구적으로 제거됩니다. 호스트가 GFS2 클러스터 풀에서 제거되면 더 이상 쿼럼 값에 포함되지 않습니다.
호스트를 복구 불가능으로 표시하려면 다음 명령을 사용하십시오.
xe host-forget uuid=<host_uuid>
잊혀진 호스트 복구
GFS2 클러스터 풀에 호스트를 잊도록 지시한 후에는 해당 호스트를 풀에 다시 추가할 수 없습니다.
GFS2 클러스터형 풀에 다시 참여하려면 호스트에 XenServer를 다시 설치하여 풀에 새 호스트로 표시되도록 해야 합니다. 그런 다음 일반적인 방법으로 호스트를 GFS2 클러스터형 풀에 참여시킬 수 있습니다.
GFS2 클러스터형 풀 문제 해결
GFS2 클러스터형 풀에서 문제가 발생하는 경우, GFS2 클러스터형 풀 문제 해결을 참조하십시오.
제약 조건
- GFS2 클러스터형 풀은 풀당 최대 16개의 호스트만 지원합니다.
- GFS2 클러스터형 풀에서 HA를 활성화하려면 하트비트 SR이 GFS2 SR이어야 합니다.
- GFS2 클러스터 트래픽의 경우, 최소 두 개의 다른 네트워크 스위치를 사용하는 본딩된 네트워크를 사용하는 것이 좋습니다. 이 네트워크를 다른 용도로 사용하지 마십시오.
- XenCenter를 사용하여 GFS2 클러스터 네트워크의 IP 주소를 변경하려면 GFS2 클러스터링 및 모든 GFS2 SR을 일시적으로 비활성화해야 합니다.
- GFS2 클러스터가 활성 상태이고 실행 중인 VM이 있는 동안 GFS2 클러스터 네트워크의 본딩을 변경하지 마십시오. 이 작업은 GFS2 클러스터의 호스트가 하드 재시작(펜싱)되도록 할 수 있습니다.
- GFS2 클러스터 네트워크에서 IP 주소 충돌(여러 호스트가 동일한 IP 주소를 가짐)이 발생하고 GFS2 클러스터링이 활성화된 호스트가 하나 이상 포함된 경우, GFS2 클러스터가 올바르게 형성되지 않으며 호스트가 필요할 때 펜싱할 수 없습니다. 이 문제를 해결하려면 IP 주소 충돌을 해결하십시오.