리소스 풀

하나의 리소스 풀은 여러 XenServer® 호스트 설치로 구성되며, 가상 머신을 호스팅할 수 있는 단일 관리 엔터티로 묶입니다. 공유 스토리지를 함께 사용하면 리소스 풀을 통해 충분한 메모리가 있는 모든 XenServer 호스트에서 VM을 시작할 수 있습니다.

풀 코디네이터 (이전 명칭: “풀 마스터”)는 리소스 풀 내의 서버로, 관리 인터페이스(XenCenter® 및 xe CLI로 알려진 XenServer 명령줄 인터페이스에서 사용)를 노출합니다. 풀 코디네이터는 필요에 따라 개별 멤버에게 명령을 전달합니다.

이 문서에서는 리소스 풀과 관련된 개념, 요구 사항 및 모범 사례에 대해 설명합니다. 풀 생성 및 관리 방법에 대한 자세한 내용은 풀 관리를 참조하십시오.

리소스 풀의 장점

XenServer 호스트를 독립형 호스트(사실상 단일 풀)로 구성할 수도 있지만, XenServer는 공유 스토리지를 사용하는 리소스 풀로 그룹화된 호스트에 최적화되어 있습니다. 고가용성 및 라이브 마이그레이션과 같은 여러 기능은 다중 호스트 리소스 풀에서만 사용할 수 있습니다. XenServer 호스트를 리소스 풀로 구성할 때의 장점은 다음과 같습니다.

• VM 이동성: VM이 풀에서 실행 중이고 디스크가 풀 공유 스토리지에 있는 경우, 이러한 VM은 실행 중인 상태에서 XenServer 호스트 간에 동적으로 이동할 수 있습니다(라이브 마이그레이션). 또한 개별 XenServer 호스트에 하드웨어 오류가 발생하면 관리자는 동일한 리소스 풀 내의 다른 XenServer 호스트에서 실패한 VM을 다시 시작할 수 있습니다.
• 고가용성 이 기능은 워크로드의 VM을 보호하고 하드웨어 또는 호스트 오류 발생 시 최소한의 다운타임을 보장합니다. 리소스 풀에서 고가용성이 활성화되면 호스트에 오류가 발생할 경우 VM이 다른 호스트에서 자동으로 다시 시작될 수 있습니다. 풀 코디네이터에 오류가 발생하면 고가용성이 다른 풀 코디네이터를 선출합니다. 자세한 내용은 고가용성을 참조하십시오.
• 워크로드 밸런싱 워크로드 밸런싱은 리소스 풀과 그 위에서 실행되는 VM 워크로드를 평가하여 VM에 대한 최적의 배치 위치를 권장할 수 있습니다. 또한 워크로드 밸런싱이 배치 권장 사항을 자동으로 따르고 풀 내 호스트 간에 VM을 마이그레이션하도록 선택할 수도 있습니다. 자세한 내용은 워크로드 밸런싱을 참조하십시오.
• 안티-어피니티 VM 배치: 그룹 내 VM이 풀 내 호스트 전체에 고르게 분산되도록 합니다. 자세한 내용은 VM 배치를 참조하십시오.
• 관리 용이성: 각 XenServer 호스트를 개별적으로 관리하는 대신, 리소스 풀을 XenCenter에 추가하고 그 안에 있는 모든 호스트, SR 및 VM을 함께 관리합니다. 자세한 내용은 XenCenter를 참조하십시오.

리소스 풀 생성 요구 사항

XenServer 배포를 설계하고 풀 구성을 결정할 때 다음 요구 사항을 고려하십시오.

하드웨어 요구 사항

XenServer 리소스 풀의 모든 서버는 광범위하게 호환되는 CPU를 가지고 있어야 합니다. 즉:

• CPU 공급업체(Intel, AMD)는 모든 서버의 모든 CPU에서 동일해야 합니다.

• 모든 CPU에서 가상화가 활성화되어 있어야 합니다.

CPU 유사성에 따라 풀은 다음 유형 중 하나에 속합니다.

• 동종 풀: 동종 리소스 풀은 동일한 CPU를 가진 서버들의 집합입니다. 동종 리소스 풀에 참여하는 서버의 CPU는 풀에 이미 있는 서버의 CPU와 동일한 공급업체, 모델 및 기능을 가져야 합니다.

• 이종 풀: 이종 풀 생성은 Intel(FlexMigration) 및 AMD(Extended Migration) CPU의 기술을 사용하여 CPU 마스킹 또는 레벨링을 제공함으로써 가능합니다. 이러한 기능은 CPU가 실제와 다른 제조사, 모델 또는 기능 세트를 제공하는 것처럼 보이도록 구성할 수 있게 합니다. 이러한 기능은 서로 다른 CPU를 가진 호스트 풀을 생성하면서도 라이브 마이그레이션을 안전하게 지원할 수 있도록 합니다. 이러한 기능 마스킹 또는 레벨링의 결과로 CPU의 전체 성능을 얻지 못할 수도 있습니다.

호스트 참여 요구 사항

XenServer는 풀에 참여하는 호스트에 대해 다음 조건이 충족되는지 확인합니다.

• 풀에 이미 있는 호스트와 동일한 XenServer 버전 및 동일한 업데이트 수준으로 실행되어야 합니다.

• 참여하는 호스트는 기존 리소스 풀의 멤버가 아니어야 합니다.

• 참여하는 호스트에 공유 스토리지가 구성되어 있지 않아야 합니다.

• 참여하는 호스트에서 실행 중이거나 일시 중단된 VM이 호스팅되고 있지 않아야 합니다.

• 참여하는 호스트의 VM에서 VM 종료 또는 내보내기와 같은 활성 작업이 진행 중이 아니어야 합니다.

• 참여하는 호스트의 시계는 풀 코디네이터와 동일한 시간으로 동기화되어야 합니다(예: NTP 사용).

• 참여하는 호스트의 관리 인터페이스는 본딩되지 않아야 합니다. 호스트가 풀에 성공적으로 참여한 후 관리 인터페이스를 구성할 수 있습니다.

• 참여하는 호스트의 관리 IP 주소는 정적이어야 하며, 호스트 자체에 구성되거나 DHCP 서버의 적절한 구성을 통해 설정되어야 합니다.

• 참가 호스트의 관리 인터페이스는 리소스 풀의 관리 인터페이스와 동일한 태그 지정된 VLAN에 있습니다.

• 참가 호스트는 풀에 이미 있는 호스트와 동일한 개정 버전의 보충 팩으로 구성되어야 합니다.

• 참가 호스트는 풀에 이미 있는 호스트와 동일한 XenServer 라이선스를 가지고 있어야 합니다. 풀에 참가한 후에는 모든 풀 구성원의 라이선스를 변경할 수 있습니다. 가장 낮은 라이선스를 가진 호스트가 풀의 모든 구성원에게 제공되는 기능을 결정합니다.

  XenCenter를 사용하여 호스트를 풀에 추가하는 경우, XenCenter는 참가 호스트에 일치하는 라이선스가 적용되도록 합니다. 그러나 xe CLI를 사용하여 풀에 참가하는 경우, 풀에 참가하기 전에 호스트에 일치하는 라이선스를 할당하는 것이 좋습니다.

• 참가 호스트는 풀과 동일한 데이터 센터에 있거나, 근접성 정의를 충족하는 데이터 센터에 있어야 하며, 낮은 지연 시간(왕복 시간 5ms 미만)과 높은 대역폭(최소 10Gbps) 네트워크로 연결되어야 합니다.

스토리지 요구 사항

리소스 풀에서 사용하는 공유 스토리지에는 다음 요구 사항이 있습니다.

• 풀에 공유 NFS 또는 iSCSI 스토리지를 제공하는 서버는 고정 IP 주소 또는 고정 DHCP 임대를 가지고 있어야 합니다.

권장 풀 크기

명시된 구성 제한인 32는 풀에서 지원하는 최대 호스트 수입니다. 그러나 이는 권장 풀 크기가 아닙니다. 대부분의 워크로드에서 관리 또는 성능 관점에서 최적의 크기가 아닌 경우가 많기 때문입니다. 배포에 가장 적합한 크기를 결정할 때 다음 요소를 고려하십시오.

• 관리 고려 사항: 대부분의 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 호스트에 직접 연결할 때 다음 알고리즘을 사용할 수 있습니다.

암호:

• 에이에스128-씨티알
• 에이에스256-씨티알
• 에이에스128-지씨엠@오픈에스에스에이치.컴
• 에이에스256-지씨엠@오픈에스에스에이치.컴

메시지 인증 코드:

• 에이치맥-샤2-256
• 에이치맥-샤2-512
• 에이치맥-샤1

KexAlgorithms:

• 커브25519-샤256
• 이씨디에이치-샤2-니스트피256
• 이씨디에이치-샤2-니스트피384
• 이씨디에이치-샤2-니스트피521

HostKeyAlgorithms:

• 이씨디에스에이-샤2-니스트피256
• 이씨디에스에이-샤2-니스트피384
• 이씨디에스에이-샤2-니스트피521
• 에스에스에이치-이디25519
• 에스에스에이치-알에스에이

중요:

당사는 제품의 암호화 기능에 대한 고객 수정을 지원하지 않습니다. 그러나 XenServer 호스트에 대한 SSH 액세스를 비활성화하려면 호스트에 대한 SSH 액세스 비활성화 또는 풀에 대한 SSH 액세스 비활성화를 참조하십시오.

호스트가 리소스 풀에 참여하면 어떻게 됩니까?

새 호스트가 리소스 풀에 참여하면, 참여하는 호스트는 로컬 데이터베이스를 풀 전체 데이터베이스와 동기화하고, 풀에서 일부 설정을 상속합니다.

• VM, 로컬 및 원격 스토리지 구성이 풀 전체 데이터베이스에 추가됩니다. 이 구성은 호스트가 풀에 참여한 후 리소스를 명시적으로 공유하도록 설정하지 않는 한 풀의 참여 호스트에 적용됩니다.

• 참여하는 호스트는 풀에 있는 기존 공유 스토리지 리포지토리를 상속합니다. 새 호스트가 기존 공유 스토리지에 자동으로 액세스할 수 있도록 적절한 PBD 레코드가 생성됩니다.

• 네트워킹 정보는 참여하는 호스트에 부분적으로 상속됩니다. NIC, VLAN 및 본딩된 인터페이스의 구조적 세부 정보는 모두 상속되지만, 정책 정보는 상속되지 않습니다. 재구성해야 하는 이 정책 정보에는 다음이 포함됩니다.

  • 관리 NIC의 IP 주소는 원래 구성에서 보존됩니다.

  • 관리 인터페이스의 위치는 원래 구성과 동일하게 유지됩니다. 예를 들어, 다른 풀 호스트가 본딩된 인터페이스에 관리 인터페이스를 가지고 있다면, 참여하는 호스트는 참여 후 본드로 마이그레이션되어야 합니다.

  • 전용 스토리지 NIC는 XenCenter 또는 CLI에서 참여하는 호스트에 다시 할당되어야 하며, 트래픽을 적절하게 라우팅하기 위해 PBD를 다시 연결해야 합니다. 이는 IP 주소가 풀 참여 작업의 일부로 할당되지 않으며, 스토리지 NIC는 올바르게 구성되었을 때만 작동하기 때문입니다. CLI에서 스토리지 NIC를 전용으로 설정하는 방법에 대한 자세한 내용은 네트워킹 관리를 참조하십시오.