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