GFS2 클러스터형 풀

GFS2 클러스터링은 GFS2 SR을 사용하는 리소스 풀에 필요한 추가 기능을 제공합니다. GFS2에 대한 자세한 내용은 스토리지 구성을 참조하십시오.

GFS2 클러스터는 비클러스터형 풀의 호스트보다 더 긴밀하게 연결되고 조정되는 최대 16개의 XenServer® 호스트 풀입니다. GFS2 클러스터의 호스트는 선택된 네트워크에서 서로 지속적으로 통신합니다. GFS2 클러스터의 모든 호스트는 GFS2 클러스터 내 모든 호스트의 상태를 인식합니다. 이러한 호스트 조정은 GFS2 클러스터가 GFS2 SR 콘텐츠에 대한 액세스를 제어할 수 있도록 합니다.

참고:

GFS2 클러스터링 기능은 GFS2 SR을 포함하는 풀에만 유용합니다. 풀에 GFS2 SR이 포함되어 있지 않으면 풀에서 GFS2 클러스터링을 활성화하지 마십시오.

쿼럼

GFS2 클러스터의 각 호스트는 항상 GFS2 클러스터 내 대다수 호스트(자신 포함)와 통신해야 합니다. 이 상태를 호스트가 쿼럼을 가지고 있다고 합니다. 호스트가 쿼럼을 가지고 있지 않으면 해당 호스트는 자체 펜싱됩니다.

초기 쿼럼을 달성하기 위해 통신해야 하는 호스트 수는 GFS2 클러스터가 쿼럼을 유지하기 위해 필요한 호스트 수와 다를 수 있습니다.

다음 표는 이 동작을 요약합니다. n 값은 GFS2 클러스터형 풀의 총 호스트 수입니다.

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 클러스터의 총 호스트 수에 1을 더한 값의 절반, 즉 (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 주소를 사용해야 합니다.

• 두 개의 호스트로 구성된 풀은 전체 풀의 자체 펜싱에 민감하므로 GFS2 클러스터링은 최소 3개 이상의 호스트를 포함하는 풀에서만 사용하는 것이 좋습니다.

• GFS2 클러스터형 풀은 풀당 최대 16개 호스트만 지원합니다.

• 풀의 호스트 간에 방화벽이 있는 경우 호스트가 다음 포트를 사용하여 GFS2 클러스터 네트워크에서 통신할 수 있는지 확인하십시오.
  • TCP: 8892, 8896, 21064
  • UDP: 5404, 5405

  자세한 내용은 XenServer에서 사용하는 통신 포트를 참조하십시오.

• 기존 풀에 GFS2 클러스터링을 추가하는 경우 고가용성이 비활성화되어 있는지 확인하십시오. GFS2 클러스터링이 활성화된 후 고가용성을 다시 활성화할 수 있습니다.

• 다른 트래픽에 사용되지 않는 GFS2 클러스터형 풀에 본딩된 네트워크를 사용하는 것이 좋습니다.

원하는 경우 XenCenter를 사용하여 풀에 GFS2 클러스터링을 설정할 수 있습니다. 자세한 내용은 XenCenter 제품 설명서를 참조하십시오.

xe CLI를 사용하여 GFS2 클러스터형 풀을 생성하려면 다음을 수행하십시오.

1. GFS2 클러스터 네트워크로 사용할 본딩된 네트워크를 생성합니다.

   참고:

   GFS2 클러스터형 풀에는 전용 본딩된 네트워크를 사용하는 것이 좋습니다. 이 네트워크를 다른 트래픽에 사용하지 마십시오.

   풀 코디네이터로 지정하려는 XenServer 호스트에서 다음 단계를 완료하십시오.

   1. XenServer 호스트에서 콘솔을 엽니다.

   2. 다음 명령을 사용하여 본딩된 NIC와 함께 사용할 네트워크를 생성합니다.

      xe network-create name-label=bond0
      <!--NeedCopy-->
      

      새 네트워크의 UUID가 반환됩니다.

   3. 다음 명령을 사용하여 본드에서 사용할 PIF의 UUID를 찾습니다.

      xe pif-list
      <!--NeedCopy-->
      

   4. 활성-활성 모드, 활성-수동 모드 또는 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 호스트를 풀에 조인하면 네트워크 및 본드 정보가 조인하는 서버로 자동으로 복제됩니다.

   자세한 내용은 네트워킹을 참조하십시오.

2. 최소 3개의 XenServer 호스트로 구성된 리소스 풀을 생성합니다.

   풀 멤버인 각 XenServer 호스트(마스터가 아닌)에서 다음 단계를 반복합니다.

   1. XenServer 호스트에서 콘솔을 엽니다.

   2. 다음 명령을 사용하여 XenServer 호스트를 풀 코디네이터의 풀에 조인합니다.

      xe pool-join master-address=master_address master-username=administrators_username master-password=password
      <!--NeedCopy-->
      

      master-address 매개변수 값은 풀 코디네이터인 XenServer 호스트의 정규화된 도메인 이름으로 설정해야 합니다. password는 풀 코디네이터가 설치될 때 설정된 관리자 암호여야 합니다.

   자세한 내용은 호스트 및 리소스 풀을 참조하십시오.

3. 이 네트워크에 속하는 모든 PIF에 대해 disallow-unplug=true을 설정합니다.

   1. 다음 명령을 사용하여 네트워크에 속하는 PIF의 UUID를 찾습니다.

      xe pif-list
      <!--NeedCopy-->
      

   2. 리소스 풀의 XenServer 호스트에서 다음 명령을 실행합니다.

      xe pif-param-set disallow-unplug=true uuid=<pif_uuid>
      <!--NeedCopy-->
      

4. 풀에서 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 클러스터 네트워크에서 GFS2 클러스터링이 활성화된 호스트가 하나 이상 포함된 IP 주소 충돌(여러 호스트가 동일한 IP 주소를 가짐)이 발생하면 GFS2 클러스터가 올바르게 형성되지 않고 필요할 때 호스트가 펜싱할 수 없습니다. 이 문제를 해결하려면 IP 주소 충돌을 해결하십시오.