리소스 풀
리소스 풀 은 가상 머신을 호스팅할 수 있는 단일 관리 엔터티에 바인딩된 여러 XenServer 호스트 설치로 구성됩니다. 공유 스토리지와 결합된 경우 리소스 풀을 사용하면 다음에서 VM을 시작할 수 있습니다. 어떤 메모리가 충분한 XenServer 호스트입니다.
풀 코디네이터 (이전에는 “풀 마스터”)는 리소스 풀의 서버로, 관리 인터페이스(XenCenter 및 XenServer 명령줄 인터페이스(xe CLI라고 함)에서 사용)를 노출합니다. 풀 코디네이터는 필요에 따라 개별 멤버에게 명령을 전달합니다.
이 문서에서는 리소스 풀과 관련된 개념, 요구 사항 및 모범 사례를 설명합니다. 풀을 생성하고 관리하는 방법에 대한 자세한 내용은 풀 관리를 참조하세요.
리소스 풀의 장점
XenServer 호스트를 독립형 호스트, 즉 실질적으로 하나의 풀로 구성할 수 있지만, XenServer는 공유 스토리지가 있는 리소스 풀로 그룹화된 호스트에 최적화되어 있습니다. 고가용성 및 라이브 마이그레이션과 같은 여러 기능은 여러 호스트의 리소스 풀에서만 사용할 수 있습니다. XenServer 호스트를 리소스 풀로 구성하는 이점은 다음과 같습니다.
- VM 이동성: VM이 풀에서 실행 중이고 풀 공유 스토리지에 디스크가 있는 경우 이러한 VM은 실행 중에도 XenServer 호스트 간에 동적으로 이동될 수 있습니다(라이브 마이그레이션). 또한 개별 XenServer 호스트에 하드웨어 장애가 발생하면 관리자는 동일한 리소스 풀에 있는 다른 XenServer 호스트에서 장애가 발생한 VM을 다시 시작할 수 있습니다.
- 고가용성 이 기능은 작업 부하에 있는 VM을 보호하고 하드웨어나 호스트 장애가 발생할 경우 가동 중지 시간을 최소화하도록 보장합니다. 리소스 풀에서 고가용성이 활성화되면 해당 호스트에 장애가 발생하면 VM이 다른 호스트에서 자동으로 다시 시작될 수 있습니다. 풀 코디네이터가 실패하면 고가용성은 다른 풀 코디네이터를 선출합니다. 자세한 내용은 고가용성을 참조하세요.
- 워크로드 밸런싱 워크로드 밸런싱은 리소스 풀과 해당 풀에서 실행되는 VM 워크로드를 평가하여 VM에 가장 적합한 배치를 추천합니다. Workload Balancing이 자동으로 배치 권장 사항을 따르고 풀에 있는 호스트 간에 VM을 마이그레이션하도록 선택할 수도 있습니다. 자세한 내용은 워크로드 밸런싱.
- 반친화성 VM 배치: 그룹 내 VM이 풀 내 호스트에 균등하게 분산되도록 합니다. 자세한 내용은 VM 배치.
- 관리 용이성: 각 XenServer 호스트를 개별적으로 관리하는 대신 XenCenter에 리소스 풀을 추가하고 그 안에 있는 모든 호스트, SR, VM을 함께 관리합니다. 자세한 내용은 XenCenter를 참조하세요.
자원 그룹을 만들기 위한 요구 사항
XenServer 배포를 설계하고 풀 구성을 결정할 때 다음 요구 사항을 고려하세요.
하드웨어 요구 사항
XenServer 리소스 풀의 모든 서버는 광범위하게 호환되는 CPU를 가져야 합니다. 즉,
-
CPU 공급업체(Intel, AMD)는 모든 서버의 모든 CPU에서 동일해야 합니다.
-
모든 CPU에는 가상화가 활성화되어 있어야 합니다.
CPU의 유사성에 따라 풀은 다음 유형 중 하나에 속합니다.
-
동종 풀: 동종 리소스 풀은 동일한 CPU를 갖춘 서버의 집계입니다. 유형이 같은 리소스 풀에 가입하는 서버의 CPU는 이미 풀에 있는 서버의 CPU와 동일한 공급업체, 모델 및 기능을 가져야 합니다.
-
이기종 풀: 이기종 풀 생성은 CPU 마스킹 또는 레벨링을 제공하는 Intel(FlexMigration) 및 AMD(Extended Migration) CPU의 기술을 사용하여 가능해집니다. 이러한 기능을 통해 CPU를 다음과 같이 구성할 수 있습니다. 나타나다 실제와 다른 제조사, 모델 또는 기능 세트를 제공하는 것입니다. 이러한 기능을 사용하면 CPU가 다른 호스트 풀을 생성할 수 있지만 실시간 마이그레이션을 안전하게 지원할 수 있습니다. 이 기능 마스킹이나 레벨링의 결과로 CPU의 전체 성능을 얻지 못할 수 있습니다.
호스트 가입 요구 사항
XenServer는 풀에 가입하는 호스트에 대해 다음 조건이 충족되는지 확인합니다.
-
풀에 이미 있는 호스트와 동일한 패치 수준에서 동일한 버전의 XenServer를 실행해야 합니다.
-
참여 호스트가 기존 리소스 풀의 구성원이 아닙니다.
-
참여 호스트에 공유 저장소가 구성되어 있지 않습니다.
-
참여 호스트는 실행 중이거나 일시 중단된 VM을 호스팅하지 않습니다.
-
참여 호스트의 VM에서 진행 중인 활성 작업(예: VM 종료 또는 내보내기)이 없습니다.
-
참여 호스트의 시계는 풀 코디네이터와 동일한 시간으로 동기화됩니다(예: NTP 사용).
-
참여 호스트의 관리 인터페이스가 결합되지 않았습니다. 호스트가 풀에 성공적으로 가입할 때 관리 인터페이스를 구성할 수 있습니다.
-
참여 호스트의 관리 IP 주소는 정적이며 호스트 자체에서 구성되거나 DHCP 서버에서 적절한 구성을 사용하여 구성됩니다.
-
참여 호스트의 관리 인터페이스는 리소스 풀과 동일한 태그가 지정된 VLAN에 있습니다.
-
참여 호스트는 풀에 이미 있는 호스트와 동일한 개정 버전의 동일한 보충 팩으로 구성되어야 합니다.
-
참여 호스트는 풀에 이미 있는 호스트와 동일한 XenServer 라이선스를 가져야 합니다. 풀에 가입한 후 풀 구성원의 라이선스를 변경할 수 있습니다. 가장 낮은 라이선스를 보유한 호스트가 풀에 있는 모든 멤버가 사용할 수 있는 기능을 결정합니다.
XenCenter를 사용하여 풀에 호스트를 추가하는 경우 XenCenter는 일치하는 라이선스가 참가하는 호스트에 적용되도록 합니다. 하지만 xe CLI를 사용하여 풀에 가입하는 경우, 풀에 가입하기 전에 호스트에 일치하는 라이선스를 할당하는 것이 좋습니다.
-
참여 호스트는 풀과 동일한 사이트에 있어야 하며 저지연 네트워크로 연결되어야 합니다.
보관 요구 사항
리소스 풀에서 사용하는 공유 스토리지에는 다음과 같은 요구 사항이 있습니다.
- 풀에 대한 공유 NFS 또는 iSCSI 스토리지를 제공하는 서버에는 정적 IP 주소 또는 정적 DHCP 임대가 있어야 합니다.
추천 풀 크기
나열된 구성 제한인 64개는 풀에서 지원하는 호스트의 최대 수입니다. 그러나 이는 권장되는 풀 크기가 아닙니다. 대부분의 작업 부하에서 관리나 성능의 관점에서 볼 때 최적의 크기가 아닌 경우가 많습니다. 배포에 가장 적합한 크기를 결정할 때 다음 요소를 고려하세요.
-
관리 고려 사항: 대부분의 XenServer 관리는 풀 수준에서 수행됩니다. 풀이 클수록 필요한 관리 작업이 줄어들고 더 많은 호스트를 함께 관리할 수 있습니다. 그러나 풀에 업데이트를 적용하는 등의 일부 관리 작업은 호스트가 많을수록 시간이 더 오래 걸릴 수 있습니다. 이는 풀에 있는 각 호스트에서 작업을 순차적으로 수행해야 하기 때문입니다. 이 경우 여러 개의 작은 풀에서 특정 작업을 완료하는 것보다 큰 풀에서 특정 작업을 완료하는 데 더 긴 유지 관리 기간이 필요할 수 있습니다.
-
리소스 공유: XenServer 풀은 일반적으로 호스트 간에 저장소 리포지토리와 같은 리소스를 공유합니다. 풀이 클수록 더 많은 호스트가 리소스를 공유할 수 있어 이점이 있습니다. 예를 들어 Citrix Virtual Apps and Desktops 환경에서는 여러 풀에 여러 사본을 만들지 않고도 여러 호스트가 골드 이미지를 공유할 수 있습니다. 그러나 공유 리소스에 대해 선택한 특정 장치에는 특정 성능 고려 사항이 있을 수 있으며, 이로 인해 더 작은 호스트 그룹을 사용하는 것이 더 나을 수 있습니다.
-
제어 평면 성능: XenServer 풀에서 모든 작업은 풀 코디네이터가 관리합니다. 풀에 호스트를 더 추가할수록 이 호스트의 툴스택 부하가 증가합니다. 각 호스트에서 백그라운드 활동이 더 많아지고 예상 동시 작업 수가 늘어납니다. 툴스택의 부하가 증가함에 따라 각 작업에 걸리는 시간도 늘어날 가능성이 높습니다. 결과적으로 하나의 큰 풀은 두 개의 작은 풀보다 눈에 띄게 느리게 작동할 수 있습니다.
-
오류 격리: XenServer나 풀에 중요한 다른 구성 요소(예: 스토리지 장치)에 문제가 발생하는 경우, 더 큰 풀에서는 해당 작업이 여러 개의 작은 풀로 분할되는 경우보다 작업 부하에 더 큰 영향을 미칠 수 있습니다.
-
GFS2 스토리지: 블록 스토리지에서 씬 프로비저닝에 GFS2 스토리지를 사용하는 경우 XenServer는 최대 16개의 호스트를 지원합니다. 이는 GFS2 구현의 제한과 스토리지를 관리하기 위해 호스트 간에 필요한 통신 증가로 인한 것입니다.
-
고가용성: 고가용성 기능을 사용하여 VM을 보호하는 경우 풀에 있는 모든 호스트는 지속적으로 서로를 모니터링하고 상태를 전달합니다. 풀 크기가 커질수록 이 모니터링의 일환으로 각 호스트가 보내고 받아야 하는 메시지의 양도 늘어납니다. 제어 도메인에 부하가 많으면 일부 모니터링 메시지가 손실될 확률이 높아집니다. 극단적인 상황에서는 메시지가 손실되어 호스트가 예기치 않게 안전을 위해 펜싱을 해야 할 수도 있습니다. 고가용성 기능을 사용할 때는 예상치 못한 펜싱 위험을 줄이기 위해 최대 16개의 호스트를 포함하는 작은 풀을 사용하는 것이 좋습니다.
대부분의 Citrix Virtual Apps and Desktops 사용 사례에서는 최대 32개까지 가능한 16개 호스트 풀 크기를 권장합니다.
수영장 크기를 계획할 때 이러한 요소를 고려하는 것 외에도 수영장의 동작을 관찰하고 모니터링하여 운영 환경에서 수영장 크기를 변경해야 하는지 확인하세요.
XenServer 호스트 및 리소스 풀과 통신
TLS
XenServer는 TLS 1.2 프로토콜을 사용하여 관리 API 트래픽을 암호화합니다. XenServer와 관리 API 클라이언트(또는 장치) 간의 모든 통신에는 TLS 1.2 프로토콜이 사용됩니다.
중요:
제품의 암호화 기능에 대한 고객 수정은 지원하지 않습니다.
XenServer는 다음과 같은 암호 그룹을 사용합니다.
- ECDHE-RSA-AES256-GCM-SHA384
- ECDHE-RSA-AES128-GCM-SHA256
SSH를 참조하십시오
SSH 클라이언트를 사용하여 XenServer 호스트에 직접 연결하는 경우 다음 알고리즘을 사용할 수 있습니다.
암호:
- AES128-CTR
- AES256-CTR
- aes128-gcm@openssh.com
- aes256-gcm@openssh.com
맥:
- HMAC-SHA2-256
- HMAC-SHA2-512
- HMAC-SHA1
켐스알고리즘:
- 곡선25519-SHA256
- ECDH-SHA2-NISP256
- ECDH-SHA2-NISP384
- ECDH-SHA2-NISP521
- 디피 헬맨 그룹14-SHA1
HostKeyAlgorithms:
- ECDSA-SHA2-NISP256
- ECDSA-SHA2-NISP384
- ECDSA-SHA2-NISP521
- SSH-ED25519
- SSH-RSA (영문)
중요:
제품의 암호화 기능에 대한 고객 수정은 지원하지 않습니다. 하지만 XenServer 호스트에 대한 SSH 액세스를 비활성화하려면 호스트에 대한 SSH 액세스 비활성화 또는 풀에 대한 SSH 액세스 비활성화를 참조하세요.
호스트가 리소스 풀에 가입하면 무슨 일이 일어나나요?
새 호스트가 리소스 풀에 가입하면 가입 호스트는 로컬 데이터베이스를 풀 전체 데이터베이스와 동기화하고 풀에서 일부 설정을 상속합니다.
-
VM, 로컬 및 원격 스토리지 구성이 풀 전체 데이터베이스에 추가됩니다. 이 구성은 호스트가 풀에 가입한 후 리소스를 명시적으로 공유하도록 만들지 않는 한 풀의 가입 호스트에 적용됩니다.
-
조인 호스트는 풀의 기존 공유 스토리지 저장소를 상속합니다. 새 호스트가 기존 공유 스토리지에 자동으로 액세스할 수 있도록 적절한 PBD 레코드가 생성됩니다.
-
네트워킹 정보는 조인 호스트에 부분적으로 상속됩니다. 구조 NIC, VLAN 및 결합된 인터페이스의 세부 정보는 모두 상속되지만 정책 정보는 그렇지 않습니다. 다시 구성해야 하는 이 정책 정보에는 다음이 포함됩니다.
-
원래 구성에서 유지되는 관리 NIC의 IP 주소입니다.
-
원래 구성과 동일하게 유지되는 관리 인터페이스의 위치입니다. 예를 들어, 다른 풀 호스트에 결합된 인터페이스에 관리 인터페이스가 있는 경우 가입 후 가입 호스트를 결합 상태로 마이그레이션해야 합니다.
-
XenCenter 또는 CLI에서 조인 호스트에 재할당해야 하는 전용 스토리지 NIC 및 그에 따라 트래픽을 라우팅하기 위해 다시 연결된 PBD입니다. 이는 IP 주소가 풀 조인 작업의 일부로 할당되지 않고 스토리지 NIC가 올바르게 구성된 경우에만 작동하기 때문입니다. CLI에서 스토리지 NIC 전용으로 사용하는 방법에 대한 자세한 내용은 을 참조하십시오 네트워킹 관리.
-