GFS2 클러스터형 풀 문제 해결

공유 블록 스토리지를 씬 프로비저닝하기 위해 GFS2를 사용하는 XenServer® 풀은 클러스터형입니다. 이러한 풀은 공유 파일 기반 스토리지를 사용하거나 공유 블록 스토리지를 사용하는 LVM을 사용하는 풀과는 다르게 작동합니다. 결과적으로 XenServer 클러스터형 풀 및 GFS2 환경에서 발생할 수 있는 몇 가지 특정 문제가 있습니다.

이 기능을 사용할 때 발생할 수 있는 사소한 문제를 해결하려면 다음 정보를 사용하십시오.

모든 호스트가 서로 ping할 수 있는데 클러스터를 만들 수 없습니다. 왜 그럴까요?

클러스터링 메커니즘은 특정 포트를 사용합니다. 호스트가 이러한 포트에서 통신할 수 없는 경우(다른 포트에서 통신할 수 있더라도) 풀에 대한 클러스터링을 활성화할 수 없습니다.

풀의 호스트가 다음 포트에서 통신할 수 있는지 확인하십시오.

• TCP: 8892, 8896, 21064
• UDP: 5404, 5405 (멀티캐스트 아님)

풀의 호스트 사이에 방화벽 또는 유사한 것이 있는 경우, 이러한 포트가 열려 있는지 확인하십시오.

이전에 풀에서 HA를 구성한 경우, 클러스터링을 활성화하기 전에 HA를 비활성화하십시오.

기존 클러스터형 풀에 새 호스트를 연결하려고 할 때 오류가 발생하는 이유는 무엇입니까?

풀에서 클러스터링이 활성화되면 모든 풀 멤버십 변경은 성공하기 전에 클러스터의 모든 멤버가 동의해야 합니다. 클러스터 멤버에 연결할 수 없는 경우, 클러스터 멤버십을 변경하는 작업(예: 호스트 추가 또는 호스트 제거)이 실패합니다.

새 호스트를 클러스터형 풀에 추가하려면 다음을 수행하십시오.

1. 모든 호스트가 온라인 상태이고 연결할 수 있는지 확인하십시오.

2. 풀의 호스트가 다음 포트에서 통신할 수 있는지 확인하십시오.

   • TCP: 8892, 8896, 21064
   • UDP: 5404, 5405 (멀티캐스트 아님)

3. 풀의 클러스터 네트워크에 연결되는 NIC에 연결 호스트의 IP 주소가 할당되어 있는지 확인하십시오.

4. 클러스터링이 풀에서 비관리 VLAN 네트워크를 사용하지 않는지 확인하십시오.

5. 새 호스트가 클러스터된 풀에 연결하려고 할 때 풀의 어떤 호스트도 오프라인 상태가 아닌지 확인하십시오.

6. 오프라인 호스트를 복구할 수 없는 경우, 클러스터에서 제거하려면 해당 호스트를 죽은 것으로 표시하십시오. 자세한 내용은 클러스터된 풀의 호스트가 오프라인 상태이며 복구할 수 없습니다. 클러스터에서 호스트를 제거하려면 어떻게 해야 합니까?를 참조하십시오.

클러스터된 풀의 일부 멤버가 클러스터에 자동으로 연결되지 않으면 어떻게 해야 합니까?

이 문제는 클러스터된 풀의 멤버가 동기화를 잃어버려서 발생할 수 있습니다.

클러스터된 풀의 멤버를 다시 동기화하려면 다음 명령을 사용하십시오.

xe cluster-pool-resync cluster-uuid=<cluster_uuid>

문제가 계속되면 GFS2 SR을 다시 연결해 볼 수 있습니다. 이 작업은 xe CLI 또는 XenCenter를 통해 수행할 수 있습니다.

xe CLI를 사용하여 GFS2 SR을 다시 연결하십시오.

1. 풀에서 GFS2 SR을 분리하십시오. 각 호스트에서 xe CLI 명령 xe pbd-unplug uuid=<uuid_of_pbd>을 실행하십시오.

2. 명령 xe cluster-pool-destroy cluster-uuid=<cluster_uuid>을 사용하여 클러스터된 풀을 비활성화하십시오.

   이전 명령이 실패하면 풀의 모든 호스트에서 xe cluster-host-force-destroy uuid=<cluster_host>을 실행하여 클러스터된 풀을 강제로 비활성화할 수 있습니다.

3. 명령 xe cluster-pool-create network-uuid=<network_uuid> [cluster-stack=cluster_stack] [token-timeout=token_timeout] [token-timeout-coefficient=token_timeout_coefficient]을 사용하여 클러스터된 풀을 다시 활성화하십시오.

4. 각 호스트에서 xe pbd-plug uuid=<uuid_of_pbd> 명령을 실행하여 GFS2 SR을 다시 연결합니다.

또는 XenCenter를 사용하여 GFS2 SR을 다시 연결하려면 다음을 수행합니다.

1. 풀의 스토리지 탭에서 GFS2 SR을 마우스 오른쪽 버튼으로 클릭하고 분리…를 선택합니다.
2. 도구 모음에서 풀 > 속성을 선택합니다.
3. 클러스터링 탭에서 클러스터링 사용을 선택 취소합니다.
4. 확인을 클릭하여 변경 사항을 적용합니다.
5. 도구 모음에서 풀 > 속성을 선택합니다.
6. 클러스터링 탭에서 클러스터링 사용을 선택하고 클러스터링에 사용할 네트워크를 선택합니다.
7. 확인을 클릭하여 변경 사항을 적용합니다.
8. 풀의 스토리지 탭에서 GFS2 SR을 마우스 오른쪽 버튼으로 클릭하고 복구를 선택합니다.

내 호스트가 자체 펜싱되었는지 어떻게 알 수 있습니까?

호스트가 자체 펜싱된 경우, 다시 시작할 때 클러스터에 다시 연결되었을 수 있습니다. 호스트가 자체 펜싱되어 복구되었는지 확인하려면 /var/opt/xapi-clusterd/boot-times 파일을 확인하여 호스트가 시작된 시간을 볼 수 있습니다. 파일에 예상치 못한 시작 시간이 있는 경우 호스트가 자체 펜싱된 것입니다.

내 호스트가 오프라인인 이유는 무엇입니까? 어떻게 복구할 수 있습니까?

호스트가 오프라인이 되는 데에는 여러 가지 가능한 이유가 있습니다. 이유에 따라 호스트를 복구할 수도 있고 복구하지 못할 수도 있습니다.

호스트가 오프라인이 되는 다음 이유들은 더 일반적이며 호스트를 복구하여 해결할 수 있습니다.

• 정상 종료
• 강제 종료
• 일시적인 전원 장애
• 재부팅

호스트가 오프라인 상태가 되는 다음 원인들은 덜 일반적입니다:

• 영구적인 호스트 하드웨어 장애
• 영구적인 호스트 전원 공급 장치 장애
• 네트워크 분할
• 네트워크 스위치 장애

이러한 문제는 하드웨어를 교체하거나 실패한 호스트를 비활성으로 표시하여 해결할 수 있습니다.

클러스터형 풀의 호스트가 오프라인 상태이며 복구할 수 없습니다. 클러스터에서 호스트를 제거하려면 어떻게 해야 합니까?

클러스터에 호스트를 잊도록 지시할 수 있습니다. 이 작업은 클러스터에서 호스트를 영구적으로 제거하고 쿼럼에 필요한 활성 호스트 수를 줄입니다.

복구할 수 없는 호스트를 제거하려면 다음 명령을 사용하십시오:

xe host-forget uuid=<host_uuid>

이 명령은 클러스터에서 호스트를 영구적으로 제거하고 쿼럼에 필요한 활성 호스트 수를 줄입니다.

참고:

호스트가 오프라인 상태가 아니라면 이 명령은 데이터 손실을 유발할 수 있습니다. 명령을 진행하기 전에 확인을 요청합니다.

호스트가 삭제된 후에는 클러스터에 다시 추가할 수 없습니다. 이 호스트를 클러스터에 다시 추가하려면 호스트에 XenServer를 새로 설치해야 합니다.

죽은 것으로 표시된 호스트를 복구했습니다. 클러스터에 다시 추가하려면 어떻게 해야 합니까?

죽은 것으로 표시된 XenServer 호스트는 클러스터에 다시 추가할 수 없습니다. 이 시스템을 클러스터에 다시 추가하려면 XenServer를 새로 설치해야 합니다. 이 새로 설치된 시스템은 클러스터에 새 호스트로 나타납니다.

클러스터가 계속 쿼럼을 잃고 호스트가 계속 펜싱되는 경우 어떻게 해야 합니까?

클러스터의 XenServer 호스트 중 하나 이상이 지속적으로 쿼럼을 잃어 펜스 루프에 빠지는 경우, nocluster dom0 명령줄 인수로 호스트를 부팅할 수 있습니다. 호스트의 물리적 또는 직렬 콘솔에 연결하여 dom0 명령줄에서 다음 명령을 실행합니다. /opt/xensource/libexec/xen-cmdline --set-dom0 nocluster. 다음에 호스트가 재부팅될 때 클러스터에 참여하려고 시도하지 않습니다.

호스트 문제를 진단하고 해결한 후, nocluster 인수를 제거하여 클러스터링을 활성화할 수 있습니다. 이렇게 하려면 다음 명령을 실행합니다. /opt/xensource/libexec/xen-cmdline --remove-dom0 nocluster. 변경 사항을 적용하려면 호스트를 재부팅하십시오.

직렬 콘솔을 통해 호스트에 액세스하고 Xen 명령줄을 편집하는 방법에 대한 자세한 내용은 고급 문제 해결을 참조하십시오.

클러스터된 풀에서 풀 코디네이터가 다시 시작되면 어떻게 됩니까?

대부분의 경우, 클러스터된 풀에서 풀 코디네이터가 종료되거나 다시 시작될 때의 동작은 다른 풀 멤버가 종료되거나 다시 시작될 때와 동일합니다.

호스트가 종료되거나 다시 시작되는 방식은 클러스터된 풀의 쿼럼에 영향을 미칠 수 있습니다. 쿼럼에 대한 자세한 내용은 쿼럼을 참조하십시오.

동작의 유일한 차이점은 풀에서 HA가 활성화되어 있는지 여부에 따라 달라집니다.

• HA가 활성화된 경우, 새 코디네이터가 선택되고 일반 서비스가 유지됩니다.
• HA가 활성화되지 않은 경우, 풀에 코디네이터가 없습니다. 나머지 호스트에서 실행 중인 VM은 계속 실행됩니다. 코디네이터가 다시 시작될 때까지 대부분의 관리 작업은 사용할 수 없습니다.

클러스터된 풀의 호스트가 강제로 종료된 후 풀이 사라진 이유는 무엇입니까?

호스트를 정상적으로(강제로가 아닌) 종료하면, 다시 켜질 때까지 쿼럼 계산에서 일시적으로 제외됩니다. 그러나 호스트를 강제로 종료하거나 전원이 끊기면 해당 호스트는 여전히 쿼럼 계산에 포함됩니다. 예를 들어, 3개의 호스트로 구성된 풀에서 2개를 강제로 종료하면 나머지 호스트는 쿼럼을 상실하여 펜싱됩니다.

클러스터형 풀의 호스트는 항상 깔끔하게 종료하도록 노력하십시오. 자세한 내용은 (/ko-kr/xenserver/9/hosts-pools/clustered-pools.html#manage-your-clustered-pool)을 참조하십시오.

클러스터형 풀 내의 모든 호스트가 동시에 다시 시작된 이유는 무엇입니까?

활성 클러스터의 모든 호스트는 풀에서 연결 가능한 호스트 수가 다음 값보다 적을 때 쿼럼을 상실한 것으로 간주됩니다.

• 짝수 개의 호스트가 있는 풀의 경우: n/2
• 홀수 개의 호스트가 있는 풀의 경우: (n+1)/2

문자 n은 클러스터형 풀의 총 호스트 수를 나타냅니다. 쿼럼에 대한 자세한 내용은 (/ko-kr/xenserver/9/hosts-pools/clustered-pools.html#quorum)을 참조하십시오.

이 상황에서는 모든 호스트가 자체 펜싱되어 모든 호스트가 다시 시작되는 것을 볼 수 있습니다.

풀이 쿼럼을 상실한 이유를 진단하려면 다음 정보가 유용할 수 있습니다.

• XenCenter에서 알림 섹션을 확인하여 문제 발생 시점에 자체 펜싱이 발생했는지 확인합니다.
• 클러스터 호스트에서 /var/opt/xapi-clusterd/boot-times을 확인하여 예기치 않은 시간에 재부팅이 발생했는지 확인합니다.
• Crit.log에서 자체 펜싱 메시지가 출력되었는지 확인합니다.

• 펜싱 정보에 대한 dlm_tool status 명령 출력을 검토합니다.

  예시 dlm_tool status 출력:

   dlm_tool status
  
   cluster nodeid 1 quorate 1 ring seq 8 8
   daemon now 4281 fence_pid 0
   node 1 M add 3063 rem 0 fail 0 fence 0 at 0 0
   node 2 M add 3066 rem 0 fail 0 fence 0 at 0 0
   <!--NeedCopy-->
  

디버깅을 위해 로그를 수집할 때는 클러스터의 모든 호스트에서 진단 정보를 수집하십시오. 단일 호스트가 자체 펜싱된 경우 클러스터의 다른 호스트에 유용한 정보가 있을 가능성이 더 높습니다.

클러스터형 풀의 호스트에 대한 전체 서버 상태 보고서를 수집합니다. 자세한 내용은 XenServer 서버 상태 보고서를 참조하십시오.

쿼럼이 있는데도 클러스터형 풀을 복구할 수 없는 이유는 무엇입니까?

호스트 수가 짝수인 클러스터형 풀이 있는 경우, 쿼럼을 _달성_하는 데 필요한 호스트 수는 쿼럼을 _유지_하는 데 필요한 호스트 수보다 하나 더 많습니다. 쿼럼에 대한 자세한 내용은 쿼럼을 참조하십시오.

짝수 개의 호스트로 구성된 풀에 있고 호스트의 절반을 복구한 경우, 클러스터를 복구하기 전에 호스트를 하나 더 복구해야 합니다.

다음 명령을 실행하여 클러스터에 쿼럼이 있는지 확인할 수 있습니다.

xe cluster-list params=is-quorate uuid=<cluster_id>

클러스터 설정을 변경할 때 Invalid token 오류가 표시되는 이유는 무엇입?

클러스터 구성을 업데이트할 때 유효하지 않은 토큰 ("[[\"InternalError\",\"Invalid token\"]]")에 대한 다음 오류 메시지가 나타날 수 있습니다.

다음 단계를 완료하여 이 문제를 해결할 수 있습니다.

1. (선택 사항) xapi-clusterd 및 시스템 로그를 포함하는 서버 상태 보고서를 수집하여 현재 클러스터 구성을 백업합니다.

2. XenCenter를 사용하여 클러스터형 풀에서 GFS2 SR을 분리합니다.

   풀 스토리지 탭에서 GFS2 SR을 마우스 오른쪽 버튼으로 클릭하고 분리…를 선택합니다.

3. 클러스터의 모든 호스트에서 이 명령을 실행하여 클러스터를 강제로 제거합니다.

   xe cluster-pool-force-destroy cluster-uuid=<uuid>
   

4. XenCenter를 사용하여 풀에서 클러스터링을 다시 활성화합니다.

   1. 도구 모음에서 풀 > 속성을 선택합니다.
   2. 클러스터링 탭에서 클러스터링 사용을 선택하고 클러스터링에 사용할 네트워크를 선택합니다.
   3. 확인을 클릭하여 변경 사항을 적용합니다.

5. XenCenter를 사용하여 GFS2 SR을 풀에 다시 연결합니다.

   풀의 스토리지 탭에서 GFS2 SR을 마우스 오른쪽 버튼으로 클릭하고 복구를 선택합니다.