리소스 풀

리소스 풀은 여러 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에서 CPU 공급업체(Intel, AMD)가 동일해야 합니다.

• 모든 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를 사용하여 풀에 가입하는 경우, 풀에 가입하기 전에 호스트에 일치하는 라이선스를 할당하는 것이 좋습니다.

• 참가 호스트는 풀과 동일한 사이트에 있어야 하며, 짧은 대기 시간 네트워크로 연결되어야 합니다.

스토리지 요구 사항

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

• 풀에 공유 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는 다음 암호화 스위트를 사용합니다.

• 이씨디에이치이-알에스에이-에이이에스256-지씨엠-에스에이치에이384
• 이씨디에이치이-알에스에이-에이이에스128-지씨엠-에스에이치에이256

SSH

SSH 클라이언트를 사용하여 XenServer 호스트에 직접 연결할 때 다음 알고리즘을 사용할 수 있습니다.

암호:

• 에이이에스128-씨티알
• aes256-ctr
• aes128-gcm@openssh.com
• aes256-gcm@openssh.com

메시지 인증 코드:

• hmac-sha2-256
• hmac-sha2-512
• hmac-sha1

키 교환 알고리즘:

• 커브이오오일구-샤이오육
• 이씨디에이치-샤이-니스트피이오육
• ecdh-sha2-nistp384
• ecdh-sha2-nistp521

호스트 키 알고리즘:

• 이씨디에스에이-샤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를 전용으로 설정하는 방법에 대한 자세한 내용은 네트워킹 관리를 참조하십시오.