XenServer® 엔터프라이즈 참조 아키텍처

개요

이 참조 아키텍처는 엔터프라이즈 규모의 워크로드를 지원하기 위해 XenServer를 설계, 배포 및 운영하는 권장 접근 방식을 정의합니다. 이는 확장성, 복원력 및 운영 단순성에 중점을 두고 일반 서버 가상화뿐만 아니라 Citrix Virtual Apps and Desktops™ (CVAD) 환경을 호스팅하기 위한 검증된 기반을 제공합니다.

이 아키텍처는 XenServer 리소스 풀 개념을 확장 및 관리의 핵심 단위로 구축됩니다. 각 리소스 풀은 단일 데이터 센터(또는 밀접하게 연결된 데이터 센터 세트) 내에서 작동하도록 설계되었으며 예측 가능하고 고성능의 워크로드 실행을 지원합니다. 배포는 추가 리소스 풀을 추가하여 증가하는 용량 및 조직 요구 사항을 충족하도록 수평적으로 확장될 수 있습니다.

설계 원칙

다음 원칙들은 설계 접근 방식을 요약합니다:

• 확장 단위로서의 리소스 풀: 잘 정의된 리소스 풀 내에서 워크로드를 배포 및 관리하고, 추가 풀을 추가하여 수평적으로 확장합니다.
• 설계에 따른 워크로드 격리: 일관된 성능과 운영 동작을 보장하기 위해 리소스 풀을 특정 워크로드 유형에 맞게 조정합니다.
• N+1 용량 모델: 워크로드 가용성에 영향을 주지 않으면서 단일 호스트 장애를 허용할 수 있는 충분한 용량을 유지합니다.
• 관심사 분리: 성능, 복원력 및 보안을 보장하기 위해 관리, VM 및 스토리지 트래픽을 명확하게 분리합니다.
• 명시적 복원력 전략: 데이터 센터 내 복원력과 데이터 센터 간 재해 복구를 별개의 아키텍처 관심사로 다룹니다.
• 운영 단순성: 명확한 가치를 제공하는 경우에만 선택적 기능을 도입하여 불필요한 복잡성을 피합니다.

이러한 원칙들은 확장 가능하고 복원력이 있으며 운영하기 쉬운 XenServer 환경을 설계하기 위한 일관된 프레임워크를 제공하며, 동시에 진화하는 워크로드 및 조직 요구 사항에 적응할 수 있도록 합니다.

이 아키텍처는 원격 블록 스토리지 사용, Active Directory를 통한 통합 ID 관리, TLS를 통한 보안 관리를 가정합니다. 워크로드 요구 사항에 따라 워크로드 밸런싱(WLB), 고가용성(HA) 및 재해 복구(DR)와 같은 선택적 기능을 통합할 수 있지만, 각 기능은 명시적으로 계획되어야 하는 추가적인 운영 고려 사항을 도입합니다. 이 참조 아키텍처는 예측 가능한 성능과 강력한 운영 제어가 필요한 엔터프라이즈 환경을 위한 것입니다. 매우 큰 개별 VM 디스크(>2TB) 또는 GPU 집약적 워크로드와 같이 대체 설계 또는 조정이 필요할 수 있는 특수 시나리오에는 최적화되어 있지 않습니다.

전반적으로 이 문서는 설계 가이드이자 운영 프레임워크 역할을 하며, 조직이 일관되고 지원 가능한 방식으로 XenServer를 배포하는 동시에 시간이 지남에 따라 플랫폼을 확장하고 발전시킬 수 있는 유연성을 유지하도록 합니다.

가정 및 범위

이 아키텍처는 규모, 인프라 및 운영 방식에 대한 일련의 기본적인 가정을 기반으로 합니다.

• 사용되는 모든 하드웨어는 XenServer 하드웨어 호환성 목록(HCL)에 나열되어 있어야 합니다.

• 각 리소스 풀은 최대 1,000개의 가상 머신을 지원하도록 예상되며, 전체 배포는 단일 풀을 무기한 확장하는 대신 추가 풀을 추가하여 확장되며 최대 200개의 풀까지 가능합니다. 풀 내의 모든 호스트는 공유 스토리지에 대한 일관되고 안정적인 액세스를 보장하기 위해 긴밀하게 연결된 네트워크 경계 내에서 작동하는 것으로 가정합니다.
  • 호스트는 필요한 워크로드 및 성능 캐싱 요구 사항이 있는 제어 도메인을 지원하기에 충분한 RAM을 갖춰야 하며(리소스 풀 크기 조정 참조), 최대 6TB까지 가능합니다.
  • 호스트는 XenServer OS용 로컬 스토리지(최소 46GB, 이상적으로 70GB)를 갖추거나 SAN에서 부팅할 수 있어야 합니다.
  • 호스트는 UEFI 펌웨어를 사용해야 합니다. 레거시 BIOS는 XenServer 9에서 지원되지 않습니다.

• 스토리지는 원격 블록 기반 시스템을 통해 제공되는 것으로 가정하며, XenServer는 LVM 기반 스토리지 리포지토리를 사용합니다. 효율성과 복원력은 주로 기본 스토리지 플랫폼에 의해 제공되며, 여기에는 사용 시 활성 할당을 가능하게 하는 씬 프로비저닝 및 멀티패싱과 같은 기능이 포함됩니다. 지속적이고 안정적인 스토리지 연결은 중요한 요구 사항입니다.

• 네트워킹은 관리, 가상 머신 및 스토리지 트래픽 간의 엄격한 분리 모델을 따릅니다. 이를 위해 호스트는 최소 2개의 NIC와 2개의 파이버 채널 연결 또는 4개의 NIC를 갖춰야 합니다. 이러한 분리는 본딩된 네트워크 인터페이스와 결합되어 복원력과 처리량을 제공하며, 불필요한 종속성이나 성능 제약을 유발하는 구성을 피합니다.

• 보안 및 ID는 설계에 필수적인 요소로 간주됩니다. 관리 통신은 TLS를 사용하여 보호되며, 인증 및 역할 기반 액세스 제어를 위해 Active Directory와의 통합이 가정됩니다. 관리자 액세스는 표준 엔터프라이즈 보안 관행을 따르며, 로컬 계정 사용을 제한하고 관리 인터페이스 노출을 제어해야 합니다.

• 운영적으로, 리소스 풀은 N+1 용량 모델을 중심으로 설계되어 호스트 유지 관리 중 또는 단일 호스트 장애 발생 시 워크로드가 계속 실행될 수 있도록 합니다. 지원 가능성과 보안을 유지하기 위해 업데이트 및 업그레이드는 정기적으로 적용되어야 합니다. 재해 복구가 필요한 경우, 이는 원활하거나 완전히 자동화된 페일오버 기능보다는 조정된 운영 프로세스로 구현됩니다.

필요한 경우 선택적 기능을 통합할 수 있지만, 기본적으로 가정되지는 않습니다. 여기에는 다음이 포함됩니다.

• 워크로드 밸런싱(WLB)
• 워크로드용 고가용성(HA)
• 데이터 센터 간 재해 복구(DR)

이들 각각은 추가적인 운영 복잡성을 야기하므로, 명확한 워크로드 및 비즈니스 요구 사항에 따라 채택되어야 합니다.

범위 외

이 참조 아키텍처는 모든 시나리오를 위해 설계된 것이 아니며 보편적인 솔루션으로 취급되어서는 안 됩니다. 특히 다음 사항은 직접적으로 다루지 않습니다.

• 개별 가상 디스크가 2TB를 초과하는 워크로드
• GPU 가속 또는 GPU 종속 워크로드
• 지리적으로 분산된 데이터 센터 간에 원활하고 활성-활성 워크로드 이동성을 요구하는 아키텍처

이러한 경우에도 이 설계의 요소들이 여전히 적용될 수 있지만, 추가적인 아키텍처 고려 사항과 조정이 필요할 것입니다.

정의 사항

이 참조 아키텍처를 읽고 이해하는 데 도움이 되는 용어 및 정의입니다.

아키텍처 청사진

리소스 풀에 대한 기대치는 다음과 같습니다.

• 각 리소스 풀은 최대 1000개의 실행 중인 VM을 위해 설계되었습니다.
• 각 리소스 풀은 단일 데이터 센터 내에 또는 근접한 데이터 센터에 완전히 위치합니다.
• 각 리소스 풀은 모든 워크로드가 가용성 및 성능에 대해 유사한 특성을 갖는 하나의 특정 사용 사례를 제공합니다. 소규모 배포의 경우 혼합 사용 사례가 가능하지만, 리소스 풀의 로드 밸런싱 및 장애 모드를 고려할 때 주의해야 합니다.

단일 사용 사례의 예시는 다음과 같습니다.

• CVAD 배포를 위한 가상 데스크톱
• CVAD 배포용 애플리케이션 서버
• CVAD 인프라
• 일반 서버 가상화 워크로드

각 리소스 풀은 다음 속성을 가집니다.

• 모든 원격 블록 스토리지에 LVM 프로토콜 사용. GFS2 프로토콜 사용은 권장되지 않습니다.
• 풀 코디네이터 관리를 위한 고가용성
• 모든 관리 통신에 TLS 1.2 사용
• 선택 사항: 워크로드 VM을 위한 워크로드 밸런싱(WLB)
• 선택 사항: 워크로드 VM의 고가용성(HA)
• 선택 사항: 재해 복구(DR)
• 선택 사항: XenServer Conversion Manager가 설치되어 있는 상태여야 합니다.

참고:

데이터 센터 내 또는 데이터 센터 간에 여러 리소스 풀을 생성하여 필요한 곳에 워크로드를 제공함으로써 설계를 확장할 수 있습니다.

아래 섹션에 정의된 대로 각 리소스 풀을 구성합니다.

코어 리소스 풀 구성

새 리소스 풀을 구축할 때, 필요한 네트워크 및 스토리지 구성으로 독립 실행형 호스트를 구성한 다음, 다른 호스트를 이 풀에 추가하는 것이 가장 좋습니다. 추가 호스트는 리소스 풀에 추가될 때 구성을 얻게 됩니다.

역할 기반 액세스 제어 구성

모든 리소스 풀을 신뢰할 수 있는 Active Directory 도메인에 연결하여 AD 사용자 및 그룹을 쉽게 관리하고 감사하며, XenServer 리소스 풀에 대한 액세스 및 권한을 제어할 수 있도록 합니다.

참고:

AD 자격 증명을 통해 인증할 수 없는 비상 상황(예: AD 도메인 컨트롤러 장애)을 제외하고는 관리용으로 기본(루트) 계정을 사용하지 마십시오.

호스트용 인증서 프로비저닝

모든 리소스 풀의 모든 호스트는 관리 네트워크에서 사용할 프로비저닝된 TLS 인증서를 가지고 있어야 합니다. CVAD 워크로드의 경우 호스트는 DNS에서 FQDN으로 확인 가능해야 합니다.

모든 호스트에는 인증서가 프로비저닝되어야 합니다. 이는 공유 와일드카드 인증서이거나 호스트별 인증서일 수 있습니다.

참고:

XenServer API를 사용하는 일부 애플리케이션(예: 일부 이전 버전의 Citrix Apps and Desktops)은 각 호스트에 개별 인증서를 사용해야 하며 와일드카드 인증서 사용을 허용하지 않습니다. 자세한 내용은 관련 설명서를 참조하십시오.

• 서비스형 데스크톱
• CVAD 2507 버전 및 그 이후에 출시된 버전
• CVAD 2507 버전 이전에 출시된 버전

리소스 풀에 대한 모든 타사 연결은 TLS와 FQDN을 사용하여 리소스 풀의 호스트를 지정해야 합니다.

리소스 풀과의 통신 보안

• 포트 80 비활성화
• 관리 툴스택이 실패할 경우 SSH가 자동으로 활성화되도록 SSH를 자동 모드로 설정

보안 부팅 활성화

XenServer 9 호스트는 펌웨어에서 보안 부팅이 활성화되도록 구성할 수 있습니다. 이는 부팅 프로세스의 각 단계에서 서명 확인을 강제하여 호스트 운영 체제가 완전히 로드되기 전에 신뢰할 수 없거나 악성 코드가 실행될 위험을 줄입니다.

각 호스트의 펌웨어 설정에서 보안 부팅을 활성화하십시오. XenServer 9의 모든 Dom0 커널 모듈은 서명되어 있으므로 표준 호스트 작업에는 영향을 미치지 않습니다. 일부 호스트에서는 보안 부팅이 활성화되고 다른 호스트에서는 비활성화된 혼합 풀도 지원됩니다.

전체 구성 단계는 XenServer 9용 보안 부팅을 참조하십시오.

리소스 풀 네트워크 구성

다음 네트워크에는 분리가 필요합니다.

• 관리 네트워크
• VM 네트워크
• 스토리지 네트워크(네트워크 기반 스토리지를 사용하는 경우)

이러한 분리는 별도의 NIC를 사용하거나 동일한 NIC를 사용하여 VLAN을 통해 제공될 수 있습니다. 네트워크 기반 스토리지를 사용하는 경우 성능상의 이유로 별도의 NIC를 사용하는 것이 강력히 권장됩니다.

관리 및 VM 네트워크

관리 및 VM 네트워크는 복원력과 처리량을 제공하기 위해 본딩된 NIC에서 작동해야 합니다.

대역폭 가용성을 최대화하면서 연결 손실에 대한 최상의 응답을 보장하기 위해 가능한 경우 본드는 LACP 본드로 구성되어야 합니다. 이를 위해서는 스위치가 일치하는 구성으로 설정되어야 합니다. 스위치가 LACP를 지원하도록 구성할 수 없는 경우 VM 네트워크에는 활성-활성(active-active) 방식이 유용합니다. 관리 네트워크는 영향 없이 활성-수동(active-passive) 방식을 사용할 수 있습니다. 자세한 내용은 본딩 유형을 참조하십시오.

가능한 경우, 네트워크 전송에서 단일 실패 지점이 없도록 스위치를 NIC에 교차 연결해야 하며, 별도의 전원 또는 이중 전원 공급 장치를 사용해야 합니다. 자세한 내용은 네트워킹 모범 사례를 참조하십시오.

풀의 모든 호스트는 관리 네트워크에 고정 IP 주소를 가지고 있어야 합니다. XenServer는 DHCP에서 발급한 호스트 IP 주소가 변경되는 시나리오를 지원하지 않습니다. 고정 DHCP 주소를 사용하는 경우, DHCP 환경은 안정적으로 사용 가능해야 하며(예: 네트워크 인프라의 일부로), 해당 DHCP 서버에 의존하는 호스트에서 실행되는 VM에 의해 제공되어서는 안 됩니다. 인프라에는 정적 주소 지정이 권장됩니다.

모든 호스트 관리 네트워크는 동기화된 NTP 서버에 대한 연결을 허용하여 클록이 정렬된 상태를 유지하도록 해야 합니다. 이는 클록 드리프트가 발생하여 통신 경로를 끊는 것을 방지하기 위해 역할 기반 액세스 제어를 위한 컴퓨터 및 사용자 계정을 제공하는 Active Directory에 사용되는 것과 동일한 시간 소스여야 합니다. 또한 이는 모든 시스템 로그에 일관된 타임스탬프가 있음을 보장합니다.

환경 운영에 필요한 전체 연결 요구 사항은 여기에 나열되어 있습니다.

스토리지 네트워크

네트워크 기반 스토리지를 사용할 때의 모범 사례는 스토리지의 멀티패스 지원을 사용하는 것이며, 이는 독립적인 네트워크(즉, 다른 서브넷)를 필요로 합니다. 이는 일반적으로 본드 대신 단일 NIC를 사용하고 각 NIC에 적절한 서브넷을 구성하는 것을 의미합니다. 추가 권장 사항은 스토리지 공급업체에 문의하십시오.

리소스 풀 스토리지 구성

멀티패싱을 활성화해야 합니다. 이는 모든 호스트에 개별적으로 설정해야 하며, 모든 스토리지 리소스에 대해 최소 2개의 경로를 사용할 수 있어야 합니다. 이러한 경로는 네트워크/파이버 채널 인프라 전반에 걸쳐 다양해야 합니다.

LVM은 씬 프로비저닝되지 않은 스토리지이므로, XenServer는 생성된 VM 디스크에 필요한 전체 스토리지 양을 요구합니다. 이는 디스크의 작은 부분만 사용 중이더라도 모든 디스크와 템플릿이 사용 가능한 전체 용량을 차지한다는 것을 의미합니다.

스토리지를 효율적으로 사용하려면 자체 씬 프로비저닝 기능을 제공하는 SAN을 사용하는 것이 좋습니다. SAN 씬 프로비저닝은 VDI의 전체 가상 크기를 미리 할당하는 대신, 데이터가 가상 디스크에 기록될 때 VDI에 디스크 스토리지 공간을 할당하여 사용 가능한 스토리지를 더 잘 활용합니다. 사용되는 스토리지 양은 SAN 공급업체에서 제공하는 도구를 사용하여 관리자가 신중하게 모니터링해야 합니다.

SAN에서 씬 프로비저닝을 사용하는 경우 스토리지 사용률 모니터링이 중요합니다. SAN 용량이 소진되어 더 이상 쓰기가 불가능해지면 VM 오류 및/또는 데이터 손상이 발생할 수 있습니다.

Citrix® 환경을 위해 MCS를 사용하여 워크로드를 프로비저닝하는 경우, 골든 이미지를 모든 LUN에 복사해야 하므로 소수의 대용량 LUN을 사용하는 것이 좋습니다. 이 과정은 느릴 수 있으며 이미지 프로비저닝에 상당한 시간이 소요되어 업데이트된 이미지 배포가 지연될 수 있습니다.

복원력 전략

XenServer 리소스 풀은 스토리지 리소스와 함께 단일 데이터 센터(또는 근접한 데이터 센터들의 집합) 내에서 운영됩니다.

이러한 리소스 풀은 데이터 센터 내의 로컬 서버, 스토리지 및 네트워크 장애에 대해 복원력을 갖도록 구성할 수 있습니다. 또한, 데이터 센터가 실패하여 전체 리소스 풀이 손실되는 경우 재해 복구 기능을 제공하기 위해 리소스 풀을 조합하여 사용할 수 있습니다.

이 내용은 아래에서 별도로 다룹니다.

데이터 센터 내 복원력

데이터 센터 내 워크로드는 아래에 설명된 전체 DR 구성으로 보호할 수 있지만, 각 리소스 풀 내에는 리소스의 고가용성을 보장하기 위한 복원력 메커니즘이 있습니다. 이러한 메커니즘은 자동화되도록 설계되었으며, 더 흔하고 국지적인 문제로부터 보호하기 위해 더 자주 사용됩니다. 다음 기능들을 사용할 수 있습니다.

• 관리 고가용성 (예기치 않은 중단 시 자동 코디네이터 선출을 통해)
• 워크로드 컴퓨팅 고가용성 (예기치 않은 중단 시 자동 VM 재시작을 통해)
• 스토리지 복원력 (스토리지 멀티패싱을 통해)
• 네트워크 복원력 (네트워크 본딩 및 스위치 구성을 통해)

이를 달성하기 위해서는 워크로드를 운영하는 데 필요한 호스트 수 N에 대해 최소 N+1개의 호스트로 리소스 풀이 작동해야 합니다. 이는 호스트 하나를 사용할 수 없는 상태에서도 리소스 풀을 최대 용량으로 운영할 수 있는 기능을 제공합니다.

참고:

N+1 호스트 용량을 통해 워크로드 중단 없이 리소스 풀을 업데이트하고 업그레이드할 수 있어 보안 업데이트 및 기능 개선 사항을 쉽게 적용할 수 있습니다.

이러한 기능들은 데이터 센터 내 또는 근접한 데이터 센터 간에 완전히 운영되는 고도로 복원력 있는 배포를 제공할 것입니다. 지리적으로 분산된 데이터 센터 간의 복원력은 지원하지 않습니다. 이를 지원하는 유일한 방법은 아래에 설명된 DR 기능((#resilience-across-data-centers) 참조)을 통해서입니다.

선택적 기능

워크로드 밸런싱(WLB)

• 사용 시점: VM 워크로드의 런타임 동안 활용 패턴이 실질적으로 다르고 시간에 따라 변동하며, 성능 유지를 위해 자동 권장 사항 및/또는 재조정을 원하는 경우.
• 피해야 할 시점: 워크로드가 매우 균일하여(예: 유사한 비영구 VDI VM 다수) 초기 배치 및 일반적인 수명 주기 작업만으로도 적절한 균형이 제공되거나, 마이그레이션이 운영상 바람직하지 않은 경우.
• 운영 영향: 운영 및 모니터링할 추가 어플라이언스를 추가합니다. WLB 처리를 사용할 수 없는 일일 유지 관리 기간이 포함됩니다.

WLB는 워크로드 사용량이 시간이 지남에 따라 변경될 때 최적의 호스트 활용도와 성능을 유지하는 데 사용될 수 있습니다.

어플라이언스를 리소스 풀로 가져오고 관리 네트워크를 연결에 사용하십시오. Workload Balancing (WLB) 어플라이언스는 XenServer 다운로드 페이지에서 다운로드할 수 있습니다.

어플라이언스의 기본 크기(2GB RAM, 30GB 디스크 및 2개의 vCPU)를 사용해야 합니다.

워크로드 적합성

WLB는 VM의 실행 수명 동안 워크로드 수요가 동적으로 변경될 때만 필요합니다. WLB를 사용하는 경우, VM이 중지되었다가 다시 시작될 때마다 현재 워크로드에 최적으로 즉시 배치되므로, VM은 호스트 활용도가 변경될 때만 이동하면 됩니다. 사용 사례가 모두 유사한 작업을 수행하는 많은 유사한 VM을 제공하는 경우 WLB를 사용하는 것은 거의 가치가 없으며, 초기 VM 배치에 의존하여 워크로드 균형을 제공할 수 있습니다.

데이터베이스 유지 관리 기간 조정

WLB 어플라이언스는 매일 정기 유지 관리를 수행합니다. 기본적으로 이는 UTC 00:05에 이루어집니다. 이 과정에서 최대 30분 동안 WLB 처리 중단이 발생하므로, 리소스 풀의 활동이 적을 때 발생하도록 구성해야 합니다. 이는 정상적인 작동에는 영향을 미치지 않으며, 배치 최적화 결정에만 영향을 미칩니다. WLB는 유지 관리가 완료되는 즉시 작업을 완료합니다.

WLB 매개변수 구성

많은 구성 설정은 기본값으로 남겨둘 수 있습니다. 이렇게 하면 WLB 기능이 관리자에게 권장 사항을 제공하도록 설정되며, 관리자는 이러한 작업을 적용해야 합니다.

이 청사진의 기본 및 예상 구성은 리소스 풀이 최대 성능으로 작동할 수 있도록 ‘임계 임계값’과 가중치만 조정하면 됩니다. 이는 사용을 통해 최적화될 수 있지만, 몇 가지 제안된 초기 값은 다음과 같습니다.

• CPU 사용률: 이에 대한 기본값은 최대 가중치를 가진 90% 임계 임계값입니다. 이는 호스트 CPU가 지난 1.5분 동안 평균 90% 로드에 도달하면 WLB 서비스가 VM을 실행할 대체 위치를 평가하도록 보장합니다.

  • 더 낮은 CPU 사용률에서 VM 성능에 영향을 미치는 경우, 가능한 한 호스트 전체의 평균 CPU 사용량을 더 낮은 값으로 유지하기 위해 이 임계 임계값을 조정할 수 있습니다.
  • 권장 초기 임계 임계값: 90%
  • 권장 초기 메트릭 가중치 값: 가장 중요
• 여유 메모리: 호스트에 여유 메모리를 유지한다고 해서 특정 성능 이점이 있는 것은 아니므로, 메모리 확보를 위해 머신을 마이그레이션하는 것은 불필요한 오버헤드입니다.
  • 권장 초기 임계값: 0
  • 권장 초기 메트릭 가중치 값: 가장 중요하지 않음
• 네트워크 읽기 및 쓰기: 기본값은 25MB/s입니다. 이는 호스트가 읽기 또는 쓰기에 더 많은 대역폭을 사용하면 재배치 대상으로 고려된다는 의미입니다. 이 매개변수는 일부 VM이 과도한 네트워크 워크로드를 실행하고 다른 VM에 미치는 영향을 피하는 것이 중요하지 않는 한 관련이 없습니다.
  • 많은 애플리케이션의 경우 이는 관련 없는 요소이므로, 가중치는 가장 중요하지 않은 설정으로 지정해야 합니다.
  • 많은 최신 네트워크에서 이 값은 매우 낮으므로, 이 설정이 관련이 있다면 다른 호스트로 마이그레이션하기 전에 이 대역폭을 잘 활용할 수 있도록 설정하는 것이 좋습니다.
  • 권장 초기 임계값: 사용 가능한 대역폭의 90%
  • 권장 초기 메트릭 가중치 값: 중간 중요도
• 디스크 읽기 및 쓰기: 기본값은 25MB/s입니다. 이는 호스트가 읽기 또는 쓰기에 더 많은 대역폭을 사용하면 재배치 대상으로 고려된다는 의미입니다. 이 매개변수는 일부 VM이 과도한 디스크 워크로드를 실행하고 다른 VM에 미치는 영향을 피하는 것이 중요하지 않는 한 관련이 없습니다. 원격 스토리지를 사용하는 경우, 패브릭의 대역폭이 병목 현상이 아니라면 이 값은 의미가 없습니다. 원격 스토리지에 미치는 영향은 해당 스토리지를 사용하는 모든 VM 성능에 호스트와 관계없이 영향을 미치기 때문입니다.
  • 대부분의 최신 스토리지 및 패브릭에서 이 값은 낮으므로, 이 설정이 관련이 있다면 대역폭을 잘 활용할 수 있도록 더 높은 값으로 설정해야 합니다. 이 값은 정기적인 비업무 시간 VM 유지보수가 필요하지 않을 때 대규모 마이그레이션을 유발하지 않을 만큼 충분히 높게 설정해야 합니다.
  • 권장 초기 임계값: 사용 가능한 대역폭의 90%
  • 권장 초기 메트릭 가중치 값: 중간 중요도

리소스 풀을 위한 고가용성(HA)

전체 HA 문서는 여기에서 확인할 수 있습니다.

XenServer의 고가용성과 관련하여 고려해야 할 두 가지 요소가 있습니다.

• 관리 HA: 리소스 풀에서 코디네이터 호스트의 예기치 않은 중단이 발생할 경우 관리 작업을 자동으로 유지하는 기능
• VM HA: 리소스 풀에서 호스트의 예기치 않은 중단이 발생할 경우 워크로드 작업을 유지하는 기능

이 두 가지 측면 모두 특정 스토리지 및 네트워크 구성이 필요합니다. 이는 아래 섹션에서 다룹니다.

사용 가능한 스토리지 LUN 중 하나가 XenServer 하트비트 SR로 선택됩니다 (이 요구 사항에 대한 자세한 설명은 가용성을 위한 하트비트 참조). 사용 가능한 LUN이 두 개 이상인 경우 어떤 LUN이 선택되든 상관없습니다. HA 기능을 제공하기 위해 이 LUN에서 소량(<5GB)의 공간이 할당됩니다.

이 참조 아키텍처는 단일 호스트의 예기치 않은 손실 한도 내에서 워크로드 유지를 지원하도록 설계되었습니다. ‘허용할 장애 수’ 설정은 1로 설정해야 합니다.

참고:

HA를 사용할 때 다음 특성을 인지하는 것이 중요합니다.

• 리소스 풀에는 최소 3개의 호스트가 있어야 합니다.
• 펜싱은 실패했거나 안전하지 않다고 간주되는 호스트를 강제로 격리하여 가상 머신이 다른 곳에서 다시 시작되기 전에 공유 리소스(특히 공유 스토리지)에 액세스할 수 없도록 하는 메커니즘을 의미합니다. 리소스 풀이 클수록 호스트 펜싱의 영향이 커지고 통신 경로 요구 사항으로 인해 발생할 가능성이 높아집니다. 이와 관련하여 >16개 호스트를 가진 풀에 대해서는 신중한 고려가 필요합니다.
• 호스트/리소스 풀 유지 관리 작업 중에는 HA를 비활성화하여 이러한 유지 관리 활동이 수행되는 동안 예기치 않은 중단 위험을 줄여야 합니다.
• HA를 사용할 때는 HA 상태 파일 SR 및 네트워킹에 대한 스토리지 연결이 중단되지 않도록 주의해야 합니다. 이러한 연결이 중단되면 리소스 풀의 작업을 보호하기 위해 호스트가 예기치 않게 펜싱될 수 있습니다. 이는 인프라 유지 관리 시 연결이 끊어지지 않도록 신중하게 고려해야 함을 의미합니다.

관리 HA를 위한 대체 접근 방식

안정적이고 고가용성 관리 연결을 제공하기 위해 HA를 사용하는 경우, 위에 나열된 제한 사항을 피하기 위해 다음 접근 방식도 고려해야 합니다.

호스트 모니터링 구현

호스트가 응답하지 않을 때 감지하기 위해 XenServer 호스트를 타사 모니터링 솔루션과 통합합니다.

관리 연결 수동 복구

연락할 수 없는 호스트가 코디네이터이고 관리 작업을 사용할 수 없는 경우, 리소스 풀의 다른 모든 호스트는 비상 모드로 전환되어 원격 연결을 설정하여 그 중 하나를 새 풀 코디네이터로 선출할 수 있습니다. 이는 원격 언어 바인딩을 사용하여 수행할 수 있습니다. 아래 예시는 xe CLI 및 PowerShell에 대해 제공됩니다.

xe 명령줄 인터페이스:

xe -s <server_IP> -u <username> -pw <password> host-is-in-emergency-mode                     -> Confirm election possibility
xe -s <server_IP> -u <username> -pw <password> pool-emergency-transition-to-master           -> Designate current host as new master
xe -s <server_IP> -u <username> -pw <password> pool-recover-slaves                           -> Reconfigure member servers to new coordinator

<!--NeedCopy-->

파워셸:

Invoke-XenPool -XenAction EmergencyTransitionToMaster          -> Designate current host as new master
Invoke-XenPool -XenAction RecoverSlaves                        -> Reconfigure member servers to new coordinator

<!--NeedCopy-->

VM 고가용성

워크로드 밸런싱(WLB) VM

이 VM은 예기치 않은 중단 후 WLB 기능이 손실되지 않도록 다시 시작 우선순위가 ‘다시 시작’으로 설정되어야 합니다. 이 VM은 첫 번째 시작 그룹 0에 있어야 합니다.

다른 VM

XenServer의 정확한 사용법에 따라 추가 VM이 VM HA를 사용하도록 구성될 수 있습니다. 다음은 몇 가지 사용 사례에 대한 제안입니다.

결정 지침(VM HA): 예기치 않은 호스트 중단 후 자동 재시작이 서비스 연속성을 실질적으로 개선하고, 풀이 중단을 흡수하기 위해 N+1로 크기가 조정된 워크로드에 VM HA를 사용하십시오. 외부 브로커링/오케스트레이션이 이미 재시작 또는 스케일 아웃 동작을 제공하는 워크로드(예: 많은 비영구 CVAD 워크로드) 또는 재시작 순서 및 종속성을 제어하기 어려운 워크로드에는 VM HA를 피하십시오.

참고:

HA가 구성된 후 리소스 풀에 추가된 VM은 기본적으로 ‘다시 시작 안 함‘으로 설정됩니다. 필요한 경우 환경에 VM이 추가된 후 HA를 재구성해야 합니다.

• PVS 및 비영구 MCS VM: 이러한 VM에는 HA를 구성하지 마십시오. Do Not Restart으로 설정되어 있는지 확인하십시오. 다른 VM은 최종 사용자에게 즉각적인 서비스를 제공할 수 있어야 하며, Citrix Virtual Apps and Desktops는 최종 사용자가 필요로 할 때 또는 예상 수요를 지원하기 위한 자동 스케일 기능을 통해 이러한 VM의 재시작을 지원하는 전원 관리 기능을 제공합니다. AutoScale을 참조하십시오. 이는 통합 Citrix 환경에 대해 보다 최적화된 결과를 제공할 것입니다.

• MCS 영구 VM: 이들은 ‘다시 시작’으로 설정되어야 합니다. 설계되는 구성은 1개의 호스트가 서비스 중단(업데이트, 유지 관리 또는 중단으로 인해) 상태일 때 풀의 모든 VM을 작동하기에 충분한 RAM과 CPU가 사용 가능하도록 보장해야 하므로 이 구성이 가능할 것입니다.

• 일반 서버 가상화 워크로드(Citrix VDA를 실행하는 데 사용되지 않는 모든 워크로드): 이들은 ‘다시 시작’으로 설정되어야 합니다. 설계되는 구성은 1개의 호스트가 서비스 중단(업데이트, 유지 관리 또는 중단으로 인해) 상태일 때 풀의 모든 VM을 작동하기에 충분한 RAM과 CPU가 사용 가능하도록 보장해야 하므로 이 구성이 가능할 것입니다. VM은 필요에 따라 시작 그룹 및 지연을 사용하여 워크로드가 필요에 따라 다시 시작되도록 구성할 수 있습니다. 이는 Active Directory, DHCP 및 DNS 서비스 공급자와 같이 다른 서비스가 의존하는 워크로드의 우선순위를 지정하는 데 사용될 수 있습니다.

데이터 센터 간 복원력

선택 사항:

데이터 센터 간 재해 복구(DR). 이 참조 아키텍처는 필요한 경우 추가 설계 및 운영 고려 사항을 통해 DR을 지원할 수 있습니다.

DR에 대한 의사 결정 지침

• 사용 시점: 사이트 복원력에 대한 명확한 비즈니스 요구 사항, 복제 가능한 스토리지 플랫폼, 그리고 보조 사이트에서 VM 복구를 필요로 하는 합의된 복구 절차(RPO/RTO)가 있는 경우.
• 피해야 할 시점: 사이트 간에 빈번한 워크로드 이동성이 필요하거나, 페일오버/페일백 프로세스를 테스트하고 실행할 운영 역량이 없는 경우. CVAD의 경우, 조정된 CVAD DR 설계 없이 하이퍼바이저 연결 및 인증서가 원활하게 페일오버될 것이라고 가정하지 마십시오.
• 운영 영향: DR은 완전히 자동화되지 않습니다. 페일오버/페일백에는 계획된 런북, 스토리지 복제 제어에 대한 액세스, 정기적인 테스트가 필요합니다.

여기에 설명된 XenServer 재해 복구(DR) 구성은 인프라의 극심하고 계획되지 않은 중단을 지원하기 위해 드물게 사용될 것으로 예상되는 복원력 모드입니다. 이 작업은 자동화되지 않으며, 복구에는 신중한 계획과 운영이 필요합니다. DR 모델은 최적의 배치가 아닐 수 있는 임시 위치에서 워크로드를 운영할 수 있도록 하지만, 중단 기간 동안 중요한 비즈니스 운영을 지원할 것입니다.

XenServer DR 모델은 복잡한 솔루션이며, 사이트 장애로부터 보호를 제공하는 다른 방법들도 있습니다. 예를 들어, 비영구 VM을 사용하여 서비스를 제공하는 Citrix 워크로드의 경우, 임시 서비스를 제공하기 위해 추가 VM을 복구 사이트에 프로비저닝할 수 있습니다. 이러한 옵션은 구현하기 더 쉬울 수 있으므로 XenServer DR 기능을 사용하기 전에 고려해야 합니다.

CVAD에 적합한 DR 솔루션이 없는 한 Citrix VDI 워크로드에 DR을 사용하지 않는 것이 좋습니다. 네트워크 및 인증서 매핑으로 인해 신뢰할 수 없게 될 수 있으므로, 동일한 하이퍼바이저 연결이 XenServer DR 사이트로 페일오버될 수 있다고 가정하는 것은 안전하지 않습니다.

데이터 센터 장애 및 워크로드(또는 워크로드의 중요 부분) 손실 위험을 완화하기 위해 보조 데이터 센터 위치를 사용하여 재해 복구 기능을 제공할 수 있습니다. 추가 문서는 여기에서 확인할 수 있습니다.

DR 사이트의 하나 이상의 리소스 풀은 워크로드의 복구 위치가 되는 것 외에 다른 워크로드에도 사용될 수 있지만, 필요한 경우 추가 워크로드를 실행할 수 있도록 필요한 예비 용량을 유지해야 합니다.

장애 이벤트 발생 시 DR 사이트에서 전체 워크로드를 운영해야 하는 요구 사항은 없습니다. 기본 사이트에서 전체 운영이 복원될 때까지 부분 워크로드를 복구할 수 있지만, 워크로드는 1개의 리소스 풀에서 단일 복구 리소스 풀로 복구되어야 한다는 요구 사항이 있습니다. 워크로드는 여러 복구 풀로 분산될 수 없습니다.

중요:

기본 사이트의 LUN에서 DR 사이트로 데이터를 미러링하는 스토리지 복제 프로세스는 XenServer 도구 세트 외부에서 구성되어야 하며, 이 재구성은 페일오버를 담당하는 관리자가 사용할 수 있어야 합니다. 이는 이 프로세스와 관련된 작업의 일부로 미러링을 중단하고 재설정해야 하기 때문입니다(자세한 내용은 운영 섹션 참조).

이 배포를 구축할 때:

• VM 가상 디스크에 사용되는 모든 스토리지는 주 환경에서 백업 환경으로 복제되어야 합니다.
• 풀 메타데이터에 사용되는 모든 스토리지는 주 환경에서 백업 환경으로 복제되어야 합니다.
• DR 사이트의 하드웨어 인프라는 주 사이트와 일치할 필요는 없지만 동일한 프로세서 공급업체를 사용해야 합니다. 필요한 모든 장애 조치된 VM을 다시 생성하고 시작할 수 있도록 대기 리소스 풀에 충분한 메모리, CPU 및 네트워크 용량이 구성되어야 합니다.
• 복구 사이트의 XenServer 리소스 풀은 주 사이트와 동일하거나 더 새로운 릴리스 및 패치 수준이어야 합니다 (이를 달성하는 방법에 대한 자세한 내용은 배포 전반의 XenServer 버전 관리 참조).

운영 모델

배포 전반의 XenServer 버전 관리

XenServer 배포는 하나 이상의 리소스 풀과 하나 이상의 데이터 센터로 구성되어 확장 가능하고 견고하며 안전한 배포를 제공하여 대규모로 성능이 뛰어난 워크로드를 제공할 수 있습니다.

이러한 배포는 테스트 및 프로덕션 환경을 제공할 수 있으며, 이러한 환경을 통해 변경 사항을 롤아웃하는 워크플로를 구축할 수 있습니다.

선택 사항:

호스트 테스트 및 워크로드 테스트 단계는 선택 사항입니다. 참조 아키텍처는 이러한 단계의 유무에 관계없이 작동을 지원합니다.

호스트 테스트 및 워크로드 테스트 단계는 별도의 단계일 필요는 없으며, 결합될 수 있습니다. 이는 프로덕션으로의 변경 사항 적용 시간을 단축하여 유리할 수 있습니다. XenServer 업데이트 스트림은 견고하고 완전히 테스트되었으므로 지속적인 배포가 가능합니다. 보안, 견고성 및 성능을 유지하려면 업데이트가 프로덕션에 도달하는 시간을 최소화하는 것이 중요합니다.

각 단계에 대한 기대치는 다음과 같습니다.

• 초기 릴리스 테스트: 이 단계는 업데이트의 초기 가시성과 기능 유효성 검사를 위한 것입니다. 이 단계의 호스트는 일반적으로 일반 채널보다 2주 먼저 새 버전에 대한 액세스를 제공하는 초기 릴리스 채널을 사용하도록 구성됩니다. 이 단계의 호스트는 XenServer CDN(콘텐츠 배포 네트워크)에 액세스하기 위해 인터넷에 대한 아웃바운드 연결(직접 또는 프록시 서버를 통해)이 있어야 합니다.
• 호스트 테스트: 이 단계의 목적은 XenServer 소프트웨어 릴리스 업데이트 프로세스를 테스트하는 것입니다. 릴리스는 인터넷을 통해 XenServer CDN에서 또는 오프라인 채널 전달 메커니즘을 통해 사용할 수 있습니다.
• 워크로드 테스트/UAT: 이 단계에서는 XenServer 호스트를 프로덕션과 유사한 워크로드로 테스트하여 확장성 및 복원력을 검증할 수 있습니다. 릴리스는 인터넷을 통해 XenServer CDN에서 또는 오프라인 채널 전달 메커니즘을 통해 사용할 수 있습니다.
• 프로덕션 배포: 프로덕션 워크로드를 실행하는 호스트는 이전 테스트 단계를 거쳐 (직접 또는 오프라인 전달 메커니즘을 통해) 업데이트할 수 있습니다.

참고:

오프라인 업데이트를 사용하여 예상되는 XenServer 버전이 UAT 및 프로덕션 환경에 배포되도록 할 수 있습니다. 다른 리소스 풀에서 직접 업데이트를 동기화할 수 있지만, 소스 풀에 동기화되었지만 아직 적용되지 않은 업데이트가 있는 경우 대상 풀에 적용되어 대상 풀의 패치 버전이 더 높아질 수 있습니다.

지원 상태를 유지하려면 모든 리소스 풀을 정기적으로 업데이트해야 하며 6개월 이상 오래되지 않아야 합니다.

드라이버 다중 버전 관리 (DMV)를 사용한 드라이버 관리

XenServer 9는 Driver Multi-Versioning (DMV)을 도입하여 표준 스트리밍 호스트 업데이트 채널을 통해 승인된 드라이버 버전을 제공함으로써 대부분의 경우 별도의 드라이버 디스크가 필요 없게 합니다.

DMV를 통해 운영자는 업데이트 스트림에서 사용 가능한 여러 승인된 드라이버 버전 중에서 선택할 수 있습니다. XenServer는 각 호스트의 하드웨어와 호환되는 드라이버 변형만 제공합니다. 잘못된 드라이버가 적용된 경우, 호스트를 다시 설치하지 않고도 올바른 버전을 선택하고 설치할 수 있지만, 변경 사항을 적용하려면 재부팅이 필요합니다. XenServer 9는 서명된 드라이버 유효성 검사를 적용하여 승인되지 않은 타사 바이너리를 차단합니다.

자세한 내용은 드라이버 다중 버전 관리를 참조하십시오.

리소스 풀 모니터링

호스트 또는 VM의 리소스 풀에서 경고가 발생하면 XenCenter®의 경고 섹션에서 확인할 수 있습니다.

이러한 경고는 SNMP 통합 또는 이메일 SMTP 통합을 통해 외부 모니터링 도구에서도 사용할 수 있습니다.

고려해야 할 모니터링 유형은 2가지입니다.

• 활용도 모니터링: 예상치 못한 용량 문제가 신속하게 식별되고 조치될 수 있도록 보장합니다.
• 인프라가 올바르게 작동하고 예기치 않은 변경 사항이 발생하지 않도록 시스템 이벤트를 모니터링합니다.

통합 설계를 위해 아래에 자세히 설명되어 있습니다.

타사 모니터링 제품과의 통합은 여기에 설명된 SNMP 기능을 통해 이루어질 수 있으며, 해당 타사 도구에 통합된 경고를 제공할 수 있습니다.

참고:

풀에 새 호스트를 추가할 때, 새 호스트가 모든 SNMP 통합에 포함되도록 SNMP 설정을 재구성해야 합니다(자세한 내용은 제약 조건 참조).

사용량 모니터링

과도한 CPU 사용량과 같은 것을 감지하도록 구성할 수 있는 경고가 있습니다. 자세한 내용은 성능 경고를 참조하십시오.

다음은 이러한 이벤트에 대해 발생한 SNMP 트랩에서 제공되는 데이터의 예입니다.

2026-02-19 09:44:35 <UNKNOWN> [UDP: [10.71.64.14]:53876->[10.81.143.35]:162]:
iso.3.6.1.2.1.1.3.0 = Timeticks: (196826250) 22 days, 18:44:22.50       iso.3.6.1.6.3.1.1.4.1.0 = OID: iso.3.6.1.4.1.60953.1.10.1   iso.3.6.1.4.1.60953.1.10.1.1.0 = STRING: "add"  iso.3.6.1.4.1.60953.1.10.1.2.0 = STRING: "OpaqueRef:eea63153-f96c-25f5-17b9-08ce49e7ccf4"   iso.3.6.1.4.1.60953.1.10.1.3.0 = STRING: "83a9c805-a172-f1b2-55d4-081ec180893b" iso.3.6.1.4.1.60953.1.10.1.4.0 = STRING: "ALARM"    iso.3.6.1.4.1.60953.1.10.1.5.0 = INTEGER: 3     iso.3.6.1.4.1.60953.1.10.1.6.0 = STRING: "VM"       iso.3.6.1.4.1.60953.1.10.1.7.0 = STRING: "681e4064-16cb-4d0c-9c2c-887623bc623f" iso.3.6.1.4.1.60953.1.10.1.8.0 = STRING: "20260219T09:45:55Z"       iso.3.6.1.4.1.60953.1.10.1.9.0 = STRING: "The memory required by the control domain on \"Control domain on host: pm-demolab-3\" is about 5.7% of its allocated memory. Occasional performance degradation can be expected when memory swapping is forced to happen.
This alarm is set to be triggered when the memory required by the control domain is above 5.0% of its allocated memory."
<!--NeedCopy-->

시스템 이벤트 모니터링

시스템 경고는 여기에 설명되어 있습니다.

다음은 이러한 이벤트에 대해 발생한 SNMP 트랩에서 제공되는 데이터의 예입니다.

2026-02-19 09:43:39 <UNKNOWN> [UDP: [10.71.64.14]:46982->[10.81.143.35]:162]:
iso.3.6.1.2.1.1.3.0 = Timeticks: (196820650) 22 days, 18:43:26.50       iso.3.6.1.6.3.1.1.4.1.0 = OID: iso.3.6.1.4.1.60953.1.10.1   iso.3.6.1.4.1.60953.1.10.1.1.0 = STRING: "add"  iso.3.6.1.4.1.60953.1.10.1.2.0 = STRING: "OpaqueRef:ca95e2da-06b7-9aa5-fa4b-ddf007a50c59"   iso.3.6.1.4.1.60953.1.10.1.3.0 = STRING: "525e459c-51bc-c71c-9c52-dcd747e9a84f" iso.3.6.1.4.1.60953.1.10.1.4.0 = STRING: "ALL_RUNNING_VMS_IN_ANTI_AFFINITY_GRP_ON_SINGLE_HOST"      iso.3.6.1.4.1.60953.1.10.1.5.0 = INTEGER: 3iso.3.6.1.4.1.60953.1.10.1.6.0 = STRING: "Pool"  iso.3.6.1.4.1.60953.1.10.1.7.0 = STRING: "419d6735-5d11-56b1-8cdc-2853ce709a27"     iso.3.6.1.4.1.60953.1.10.1.8.0 = STRING: "20260219T09:44:59Z"   iso.3.6.1.4.1.60953.1.10.1.9.0 = STRING: "<body><message>Breach on VM anti-affinity rules</message><VM_group>3224f9d9-9492-06f7-3c92-da610cde33a8</VM_group><host>ce2a3c26-6bbc-4d23-8626-fba28d3dc651</host></body>"
<!--NeedCopy-->

원격 로깅

이것의 주된 목적은 지원 참여를 가능하게 하는 것입니다. 문제 해결 중 이 데이터의 가용성을 보장하기 위해 syslog 전달을 구성할 수 있습니다. 이를 통해 호스트에서 직접 로그를 검색할 수 없거나 호스트의 로그가 변조되었을 수 있다고 의심할 만한 이유가 있는 경우 로그를 검색할 수 있습니다.

이것이 구성된 경우, 풀의 모든 호스트에 구성되어야 합니다.

이 데이터는 상당한 공간을 차지할 수 있습니다. 이 기능 및 데이터의 사용 및 보존은 내부 보안 정책에 따라 재량에 맡겨집니다.

용량 계획 모델

리소스 풀 크기 조정

각 리소스 풀은 호스트 1대가 다운되더라도 전체 워크로드를 운영할 수 있도록 충분한 리소스를 포함해야 합니다. 이를 통해 다음이 가능합니다.

• 한 번에 1개의 호스트에서 필요에 따라 계획된 중단 발생
• 워크로드 중단 없이 리소스 풀 업데이트 수행
• 호스트 1대가 예기치 않게 실패할 경우 워크로드 중단을 최소화

이를 달성하기 위해 리소스 풀의 모든 호스트가 워크로드를 지원할 수 있는 동일한 기능(예: 동일한 구성, RAM, CPU)을 가지고 있어야 합니다. 이로 인해 중단 중 CPU 오버커밋 수준이 높아질 수 있지만, 이는 중단 조건이 해결될 때까지 단기적으로 예상됩니다.

리소스 풀에서 1개 이상의 호스트가 손실되면 모든 워크로드를 유지할 수 없게 되며, 호스트가 복구될 때까지 워크로드 중단이 발생할 수 있습니다.

참고:

하드웨어 업데이트/새로 고침과 같은 활동 중 일정 기간 동안 호스트의 용량이 동일하지 않은 경우, 가장 많은 메모리를 가진 호스트의 장애에 대비해야 합니다.

리소스 풀 용량 계산

이 참조 아키텍처에서는 각 리소스 풀이 특정 목적을 위한 것이라고 가정했습니다. 결과적으로 아래 계산은 리소스 풀의 모든 VM이 동일한 사양이라고 가정합니다.

NUMA 최적화

XenServer 9는 기본적으로 NUMA 배치 최적화를 활성화합니다. VM의 vCPU와 메모리가 호스트의 단일 NUMA 노드 내에 들어갈 때 워크로드는 더 낮은 메모리 액세스 지연 시간과 더 일관된 성능을 달성합니다. 이는 또한 호스트당 더 높은 VM 밀도를 가능하게 하여 추가 서버의 필요성을 줄일 수 있습니다.

최상의 결과를 얻으려면 VM의 메모리가 단일 물리적 NUMA 노드 내에 맞도록 VM 크기를 조정하십시오. VM이 단일 노드가 제공할 수 있는 것보다 더 많은 메모리를 필요로 하는 경우, XenServer는 VM을 여러 노드에 분산시키고 최적화 이점이 감소합니다. NUMA 노드 경계를 초과하는 VM 크기 조정은 일반적인 경우보다는 예외로 처리해야 합니다.

VM별 NUMA 메트릭을 사용하여 배치 모니터링 및 선호도 위반 감지를 할 수 있습니다. 자세한 내용은 XenServer 9의 NUMA 최적화를 참조하십시오.

리소스 풀 용량 계산

Dom0의 RAM은 32GB로 설정됩니다. 그러나 PVS 가속기가 사용되는 경우 가속을 지원하기 위해 vDisk당 최소 5GB씩 늘려야 하며, 이러한 계산에서 고려되어야 합니다.

입력

출력

참고:

호스트 장애, 유지 관리 또는 업데이트 작업 중 vm_host = vm_pool_max / (hosts_total - 1)

작동 예시

• vm_host_max = (1000 - 32 - 2) / 16 = 60 max VMs per Host
• vm_pool_max = 60 * (8 - 1) = 420 max VMs per pool
• srs_total = 420 * (3 + 0) / 1000 = 1.26 SRs (>1 so need 2 SRs spread over 2 LUNS)
• 정상 작동:
  • vm_host = 420 / 8 = 52.5 VMs per host (round down to 52)
  • host_cpu_overcommit = ((52 * 4) + 16 + 2) / 128 = 1.77 vCPU per pCPU
• 단일 호스트 중단 또는 업데이트/유지보수 작업 중:
  • vm_host = 420 / 7 = 60 VMs per host
  • host_cpu_overcommit = ((60 * 4) + 16 + 2) / 128 = 2.01 vCPU per pCPU

참고:

RAM 오버커밋을 제공하기 위해 동적 메모리 제어(DMC)를 사용하지 않습니다. XenServer는 정상 작동 중에는 이를 지원하지 않습니다. 이는 필요한 워크로드를 계속 실행할 다른 옵션이 없을 때 계획된 제어 유지보수의 짧은 기간 동안에만 사용될 것으로 예상됩니다.

오버커밋이 너무 높으면 풀의 VM 수를 허용 가능한 수준에 도달할 때까지 줄여야 합니다.