Citrix Hypervisor

호스트 및 리소스 풀

September 30, 2024

제공::

X X

이 섹션에서는 xe CLI (명령줄 인터페이스) 를 사용하는 일련의 예제를 통해 리소스 풀을 생성하는 방법에 대해 설명합니다. 간단한 NFS 기반 공유 스토리지 구성이 소개되고 몇 가지 간단한 VM 관리 예제가 설명되어 있습니다. 또한 물리적 노드 장애를 처리하기 위한 절차도 포함되어 있습니다.

Citrix Hypervisor 서버 및 리소스 풀 개요

리소스 풀은 여러 Citrix Hypervisor 서버 설치로 구성되며 가상 컴퓨터를 호스팅할 수 있는 단일 관리되는 엔터티에 함께 바인딩됩니다. 리소스 풀을 공유 스토리지와 결합하면 메모리가 충분한 모든 Citrix Hypervisor 서버에서 VM을 시작할 수 있습니다. 그런 다음 가동 중지 시간을 최소화하면서 실행하면서 Citrix Hypervisor 서버 간에 VM을 동적으로 이동할 수 있습니다 (실시간 마이그레이션). 개별 Citrix Hypervisor 서버에 하드웨어 오류가 발생하는 경우 관리자는 동일한 리소스 풀의 다른 Citrix Hypervisor 서버에서 장애가 발생한 VM을 다시 시작할 수 있습니다. 리소스 풀에서 고가용성을 사용하도록 설정하면 호스트에 장애가 발생하면 VM이 자동으로 다른 호스트로 이동합니다. 리소스 풀당 최대 64개의 호스트가 지원되지만 이 제한은 강제로 적용되지 않습니다.

풀에는 항상 마스터 라고 하는 물리적 노드가 하나 이상 있습니다. 마스터 노드만 관리 인터페이스 (XenCenter 및 xe CLI라고 하는 Citrix Hypervisor 명령줄 인터페이스에서 사용) 를 표시합니다. 마스터는 필요에 따라 개별 멤버에게 명령을 전달합니다.

참고:

풀 마스터가 실패하면 고가용성을 사용하도록 설정한 경우에만 마스터 재선택이 수행됩니다.

리소스 풀 생성 요구 사항

리소스 풀은 하나 이상의 Citrix Hypervisor 서버로 구성된 동종 (또는 제한이 있는 이기종) 집계이며 최대 64개까지 가능합니다. 같은 유형의 정의는 다음과 같습니다.

풀에 가입하는 서버의 CPU는 이미 풀에 있는 서버의 CPU와 동일합니다 (공급업체, 모델 및 기능 측면에서).
풀에 가입하는 서버는 이미 풀에 있는 서버와 동일한 패치 수준에서 동일한 버전의 Citrix Hypervisor 소프트웨어를 실행하고 있습니다.

이 소프트웨어는 서버를 풀에 조인할 때 추가 제약 조건을 적용합니다. 특히 Citrix Hypervisor 풀에 가입하는 서버에 대해 다음 조건이 충족되는지 확인합니다.

서버가 기존 리소스 풀의 구성원이 아닙니다.
서버에 공유 스토리지가 구성되어 있지 않습니다.
서버에서 실행 중이거나 일시 중단된 VM을 호스팅하지 않습니다.
서버의 VM에서 진행 중인 활성 작업 (예: VM 종료) 이 없습니다.
서버의 시계는 풀 마스터와 동일한 시간 (예: NTP 사용) 으로 동기화됩니다.
서버의 관리 인터페이스는 연결되지 않습니다. 서버가 성공적으로 풀에 가입할 때 관리 인터페이스를 구성할 수 있습니다.
관리 IP 주소는 서버 자체에서 구성되거나 DHCP 서버에서 적절한 구성을 사용하여 정적입니다.

리소스 풀의 Citrix Hypervisor 서버는 서로 다른 수의 물리적 네트워크 인터페이스를 포함할 수 있으며 다양한 크기의 로컬 스토리지 저장소를 가질 수 있습니다. 실제로 여러 서버가 완전히 똑같은 CPU를 가지기는 힘들기 때문에 사소한 차이는 허용됩니다. 동일한 풀의 일부로 다양한 CPU를 가진 호스트를 가질 수 있는 경우 --force 매개 변수를 전달하여 풀 조인 작업을 강제 실행할 수 있습니다.

풀의 모든 호스트는 동일한 사이트에 있어야 하며 지연 시간이 짧은 네트워크로 연결되어 있어야 합니다.

참고:

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

VM을 실행할 Citrix Hypervisor 서버를 선택하고 Citrix Hypervisor 서버 간에 동적으로 VM을 이동하려면 풀에 공유 스토리지 저장소가 포함되어야 합니다. 가능하면 공유 스토리지를 사용할 수 있는 후에 풀을 생성합니다. 공유 스토리지를 추가한 후에는 로컬 스토리지에 있는 디스크가 있는 기존 VM을 공유 스토리지로 이동하는 것이 좋습니다. xe vm-copy 명령을 사용하거나 XenCenter를 사용하여 VM을 이동할 수 있습니다.

리소스 풀 생성

리소스 풀은 XenCenter 또는 CLI를 사용하여 만들 수 있습니다. 새 호스트가 리소스 풀에 가입하면 조인 호스트는 로컬 데이터베이스를 풀 전체 데이터베이스와 동기화하고 풀에서 일부 설정을 상속합니다.

VM, 로컬 및 원격 스토리지 구성이 풀 전체 데이터베이스에 추가됩니다. 호스트가 풀에 가입한 후 리소스를 명시적으로 공유하지 않는 한 이 구성은 풀의 조인 호스트에 적용됩니다.
조인 호스트는 풀의 기존 공유 스토리지 저장소를 상속합니다. 새 호스트가 기존 공유 스토리지에 자동으로 액세스할 수 있도록 적절한 PBD 레코드가 생성됩니다.
네트워킹 정보는 조인 호스트에 부분적으로 상속됩니다. NIC, VLAN 및 연결된 인터페이스의 구조적 세부 사항은 모두 상속되지만 정책 정보는 상속되지 않습니다. 재구성해야 하는 이 정책 정보에는 다음이 포함됩니다.
- 원래 구성에서 보존되는 관리 NIC의 IP 주소입니다.
- 원래 구성과 동일하게 유지되는 관리 인터페이스의 위치입니다. 예를 들어 다른 풀 호스트에 연결된 인터페이스에 관리 인터페이스가 있는 경우 가입 후 조인된 호스트를 본드로 마이그레이션해야 합니다.
- 전용 스토리지 NIC - XenCenter 또는 CLI에서 조인 호스트에 재할당해야 하며, 이에 따라 트래픽을 라우팅하기 위해 PBD를 다시 연결해야 합니다. 이는 IP 주소가 풀 가입 작업의 일부로 할당되지 않고 스토리지 NIC가 올바르게 구성된 경우에만 작동하기 때문입니다. CLI에서 전용 스토리지 NIC를 사용하는 방법에 대한 자세한 내용은 네트워킹 관리를 참조하십시오.

참고:

호스트의 관리 인터페이스가 리소스 풀의 태그가 지정된 VLAN과 동일한 VLAN에 있는 경우에만 새 호스트를 리소스 풀에 조인할 수 있습니다.

xe CLI를 사용하여 풀에 호스트 추가

풀에 가입하려는 Citrix Hypervisor 호스트에서 콘솔을 엽니다.
다음 명령을 실행하여 Citrix Hypervisor 호스트를 풀에 연결합니다.
```
xe pool-join master-address=<address of pool master> master-username=<administrator username> master-password=<password>

```
master-address은(는) 풀 마스터의 정규화된 도메인 이름으로 설정해야 합니다. password는 풀 마스터가 설치될 때 설정된 관리자 암호여야 합니다.

참고:

호스트를 풀에 가입시키면 가입 호스트의 관리자 암호가 풀 마스터의 관리자 암호와 일치하도록 자동으로 변경됩니다.

Citrix Hypervisor 서버는 기본적으로 이름이 지정되지 않은 풀에 속합니다. 첫 번째 리소스 풀을 만들려면 기존의 이름 없는 풀의 이름을 바꿉니다. 탭 완성을 사용하여 pool_uuid을 찾습니다.

xe pool-param-set name-label="New Pool" uuid=pool_uuid
<!--NeedCopy-->

이기종 리소스 풀 생성

Citrix Hypervisor는 서로 다른 호스트 하드웨어를 이기종 리소스 풀이라고 하는 리소스 풀에 조인할 수 있도록 하여 시간이 지남에 따라 배포 확장을 간소화합니다. 이기종 리소스 풀은 CPU “마스킹” 또는 “레벨링”을 제공하는 Intel (FlexMigration) 및 AMD (확장 마이그레이션) CPU의 기술을 사용하여 가능합니다. CPU 마스킹 및 레벨링 기능을 사용하면 CPU가 실제와는 다른 제조사, 모델 또는 기능을 제공하는 것처럼 보이도록 구성할 수 있습니다. 이 기능을 사용하면 이기종 CPU를 사용하여 호스트 풀을 생성할 수 있지만 라이브 마이그레이션을 안전하게 지원할 수 있습니다.

참고:

이기종 풀에 참여하는 Citrix Hypervisor 서버의 CPU는 풀에 이미 있는 호스트의 CPU와 동일한 공급업체(즉, AMD, Intel)여야 합니다. 그러나 제품군, 모델 또는 스테핑 번호 수준에서 서버가 동일한 유형일 필요는 없습니다.

Citrix Hypervisor 이기종 풀의 지원을 단순화합니다. 이제는 동일한 공급업체 제품군의 CPU인 경우 기본 CPU 유형과 관계없이 기존 리소스 풀에 호스트를 추가할 수 있습니다. 풀 기능 집합은 다음을 수행할 때마다 동적으로 계산됩니다.

새 호스트가 풀에 합류합니다.
풀 멤버가 풀을 떠납니다.
재부팅 후 풀 멤버가 다시 연결됩니다.

풀 기능 집합의 변경 사항은 현재 풀에서 실행 중인 VM에 영향을 주지 않습니다. 실행 중인 VM은 시작되었을 때 적용된 기능 세트를 계속 사용합니다. 이 기능 집합은 부팅 시 고정되어 마이그레이션, 일시 중지 및 다시 시작 작업 전체에 걸쳐 유지됩니다. 성능이 낮은 호스트가 풀에 가입할 때 풀 수준이 떨어지면 새로 추가된 호스트를 제외하고 실행 중인 VM을 풀의 모든 호스트로 마이그레이션할 수 있습니다. 풀 내에서 또는 풀 간에 VM을 다른 호스트로 이동하거나 마이그레이션하는 경우 Citrix Hypervisor는 VM의 기능 집합을 대상 호스트의 기능 집합과 비교합니다. 기능 세트가 호환되는 것으로 확인되면 VM을 마이그레이션할 수 있습니다. 따라서 VM에 사용되는 CPU 기능에 관계없이 VM을 풀 내/외부로 자유롭게 이동할 수 있습니다. Workload Balancing을 사용하여 VM을 마이그레이션할 최적의 대상 호스트를 선택하는 경우 호환되지 않는 기능 세트가 있는 호스트는 대상 호스트로 권장되지 않습니다.

공유 저장소 추가

지원되는 공유 스토리지 유형의 전체 목록은 스토리지 저장소 형식을 참조하십시오. 이 섹션에서는 기존 NFS 서버에서 공유 스토리지(스토리지 저장소로 표시됨)를 생성하는 방법을 보여 줍니다.

CLI를 사용하여 리소스 풀에 NFS 공유 스토리지를 추가하려면

풀의 Citrix Hypervisor 서버에서 콘솔을 엽니다.
다음 명령을 실행하여 server:/path에 스토리지 저장소를 생성합니다.
```
xe sr-create content-type=user type=nfs name-label="Example SR" shared=true \
    device-config:server=server \
    device-config:serverpath=path

```
device-config:server는 NFS 서버의 호스트 이름이며 device-config:serverpath는 NFS 서버의 경로입니다. shared를 true로 설정하면 공유 스토리지는 풀의 모든 Citrix Hypervisor 서버에 자동으로 연결됩니다. 나중에 가입하는 모든 Citrix Hypervisor 서버도 스토리지에 연결됩니다. 스토리지 저장소의 UUID(범용 고유 식별자)가 화면에 인쇄되어 있습니다.
다음 명령을 실행하여 풀의 UUID를 찾습니다.
```
xe pool-list

```
다음 명령을 사용하여 공유 스토리지를 풀 전체 기본값으로 설정합니다.
```
xe pool-param-set uuid=pool_uuid default-SR=sr_uuid

```
공유 스토리지가 풀 전체의 기본값으로 설정되었으므로 이후의 모든 VM에는 기본적으로 공유 스토리지에 디스크가 생성됩니다. 다른 유형의 공유 스토리지를 만드는 방법에 대한 자세한 내용은 스토리지 저장소 형식을 참조하십시오.

리소스 풀에서 Citrix Hypervisor 서버 제거

참고:

풀에서 Citrix Hypervisor 서버를 제거하기 전에 해당 호스트에서 실행 중인 모든 VM을 종료해야 합니다. 그렇지 않으면 호스트를 제거할 수 없다는 경고가 표시될 수 있습니다.

풀에서 호스트를 제거(꺼내기)하면 시스템이 재부팅되고 다시 초기화되고 새로 설치와 비슷한 상태가 됩니다. 로컬 디스크에 중요한 데이터가 있는 경우 풀에서 Citrix Hypervisor 서버를 꺼내지 마십시오.

CLI를 사용하여 리소스 풀에서 호스트를 제거하려면

풀의 모든 호스트에서 콘솔을 엽니다.
다음 명령을 실행하여 호스트의 UUID를 찾습니다.
```
xe host-list

```
풀에서 필요한 호스트를 분리합니다.
```
xe pool-eject host-uuid=host_uuid

```
Citrix Hypervisor 서버가 꺼내지고 새로 설치된 상태로 유지됩니다.

경고:

로컬 디스크에 저장된 중요한 데이터가 있는 경우 리소스 풀에서 호스트를 꺼내지 마십시오 . 호스트를 풀에서 꺼내면 모든 데이터가 지워집니다. 이 데이터를 보존하려면 XenCenter 또는 xe vm-copy CLI 명령을 사용하여 VM을 풀의 공유 스토리지에 복사합니다.

로컬로 저장된 VM이 포함된 Citrix Hypervisor 서버를 풀에서 꺼내면 VM이 풀 데이터베이스에 표시됩니다. 로컬에 저장된 VM은 다른 Citrix Hypervisor 서버에서도 볼 수 있습니다. VM은 연결된 가상 디스크가 풀의 다른 Citrix Hypervisor 서버에 표시되는 공유 저장소를 가리키도록 변경되거나 제거될 때까지 시작되지 않습니다. 따라서 풀에 가입할 때 로컬 스토리지를 공유 스토리지로 이동하는 것이 좋습니다. 공유 스토리지로 이동하면 데이터 손실 없이 개별 Citrix Hypervisor 서버를 꺼내거나 물리적으로 실패할 수 있습니다.

참고:

태그가 지정된 VLAN 네트워크에서 관리 인터페이스가 있는 풀에서 호스트를 제거하면 시스템이 재부팅되고 동일한 네트워크에서 해당 관리 인터페이스를 사용할 수 있습니다.

유지 관리를 위해 Citrix Hypervisor 서버 풀 준비

리소스 풀의 일부인 호스트에서 유지 관리 작업을 수행하기 전에 해당 호스트를 비활성화해야 합니다. 호스트를 사용하지 않도록 설정하면 호스트에서 VM이 시작되지 않습니다. 그런 다음 해당 VM을 풀의 다른 Citrix Hypervisor 서버로 마이그레이션해야 합니다. XenCenter를 사용하여 Citrix Hypervisor 서버를 유지 관리 모드로 전환하여 이 작업을 수행할 수 있습니다. 자세한 내용은 XenCenter 설명서의 유지 관리 모드에서 실행을 참조하십시오.

백업 동기화는 24시간마다 수행됩니다. 마스터 호스트를 유지 보수 모드로 전환하면 오프라인 VM에 대한 최근 24시간 RRD 업데이트가 손실됩니다.

경고:

업데이트를 설치하고 구성을 확인하기 전에 모든 Citrix Hypervisor 서버를 재부팅하는 것이 좋습니다. 일부 구성 변경 사항은 Citrix Hypervisor 서버를 다시 부팅할 때만 적용되므로 재부팅 시 업데이트 실패의 원인이 될 수 있는 구성 문제가 발견될 수 있습니다.

CLI를 사용하여 유지 보수 작업을 위해 풀의 호스트를 준비하려면

다음 명령을 실행합니다.
```
xe host-disable uuid=Citrix Hypervisor_host_uuid
xe host-evacuate uuid=Citrix Hypervisor_host_uuid

```
이 명령은 Citrix Hypervisor 서버를 사용하지 않도록 설정한 다음 실행 중인 VM을 풀의 다른 Citrix Hypervisor 서버로 마이그레이션합니다.
원하는 유지 관리 작업을 수행합니다.
유지 관리 작업이 완료되면 Citrix Hypervisor 서버를 사용하도록 설정합니다.
```
xe host-enable

```
중지된 VM을 모두 다시 시작하고 일시 중단된 VM을 다시 시작합니다.

리소스 풀 데이터 내보내기

Export Resource Data(리소스 데이터 내보내기) 옵션을 사용하면 풀에 대한 리소스 데이터 보고서를 생성하고 .xls 파일이나 .csv 파일로 내보낼 수 있습니다. 이 보고서는 서버, 네트워크, 스토리지, 가상 컴퓨터, VDI, GPU 등과 같이 풀에 속해 있는 다양한 리소스에 대한 세부 정보를 제공합니다. 이 기능을 통해 관리자는 CPU, 스토리지, 네트워크와 같은 다양한 워크로드를 기반으로 리소스를 추적, 계획 및 할당할 수 있습니다.

참고:

리소스 풀 데이터 내보내기는 Citrix Hypervisor 프리미엄 에디션 고객 또는 Citrix Virtual Apps and Desktops 또는 Citrix DaaS 권한을 통해 Citrix Hypervisor에 액세스할 수 있는 사용자만 사용할 수 있습니다.

보고서에 포함된 리소스 및 다양한 유형의 리소스 데이터 목록은 다음과 같습니다.

서버:

이름
풀 마스터
UUID
주소
CPU 사용량
네트워크(평균/최대 KB)
사용된 메모리
스토리지
작동 시간
설명

네트워크:

이름
연결 상태
MAC
MTU
VLAN
유형
위치

VDI:

이름
유형
UUID
크기
스토리지
설명

스토리지:

이름
유형
UUID
크기
위치
설명

VM:

이름
Power State(전원 상태)
실행 대상
주소
MAC
NIC
운영 체제
스토리지
사용된 메모리
CPU 사용량
UUID
작동 시간
템플릿
설명

GPU:

이름
서버
PCI 버스 경로
UUID
전원 사용량
온도
사용된 메모리
컴퓨터 사용

참고:

GPU에 대한 정보는 Citrix Hypervisor 서버에 연결된 GPU가 있는 경우에만 사용할 수 있습니다.

리소스 데이터를 내보내려면

XenCenter 탐색 창에서 인프라를 선택한 다음 풀을 선택합니다.
풀 메뉴를 선택한 다음 리소스 데이터 내보내기를 선택합니다.
보고서를 저장할 위치를 찾은 다음 저장을 클릭합니다.

호스트 전원 켜기

원격으로 호스트 전원 켜기

Citrix Hypervisor 서버 전원 켜기 기능을 사용하여 XenCenter에서 또는 CLI를 사용하여 원격으로 서버를 켜고 끌 수 있습니다.

호스트 전원을 사용하려면 서버에 다음 전원 제어 솔루션 중 하나가 있어야 합니다.

Wake on LAN 지원 네트워크 카드.
Dell 원격 액세스 카드 (DRAC). DRAC와 함께 Citrix Hypervisor를 사용하려면 DRAC 지원을 받으려면 Dell 보조 팩을 설치해야 합니다. DRAC를 지원하려면 원격 액세스 컨트롤러를 사용하여 서버에 RACADM 명령줄 유틸리티를 설치하고 DRAC 및 해당 인터페이스를 활성화해야 합니다. RACADM은 대개 DRAC 관리 소프트웨어에 포함되어 있습니다. 자세한 내용은 Dell의 DRAC 설명서를 참조하십시오.
Citrix Hypervisor를 통해 전원을 켜고 끌 수 있는 관리 API 기반의 사용자 지정 스크립트입니다. 자세한 내용은 다음 섹션의 호스트 전원 켜기 기능에 대한 사용자 지정 스크립트 구성을 참조하십시오.

호스트 전원 켜기 기능을 사용하려면 다음 두 가지 작업을 수행해야 합니다.

풀의 호스트가 원격으로 전원 제어를 지원하는지 확인합니다. 예를 들어 Wake on LAN 기능이나 DRAC 카드가 있거나 사용자 지정 스크립트를 만든 경우).
CLI 또는 XenCenter를 사용하여 호스트 전원 켜기 기능을 사용하도록 설정합니다.

CLI를 사용하여 호스트 전원 켜기 관리

CLI 또는 XenCenter를 사용하여 호스트 전원 켜기 기능을 관리할 수 있습니다. 이 섹션에서는 CLI를 사용한 관리 방법에 대해 설명합니다.

호스트 전원 켜기는 호스트 수준 (즉, 각 Citrix Hypervisor에서) 에서 사용하도록 설정됩니다.

호스트 전원 켜기를 사용하도록 설정한 후 CLI 또는 XenCenter를 사용하여 호스트를 켤 수 있습니다.

CLI를 사용하여 호스트 전원을 켜려면

명령을 실행합니다.

xe host-set-power-on-mode host=<host uuid> \
    power-on-mode=("" , "wake-on-lan", "DRAC","custom") \
    power-on-config=key:value
<!--NeedCopy-->

DRAC의 경우 비밀 기능을 사용한다면 power_on_ip인 키를 사용하여 암호를 지정합니다. 자세한 내용은 비밀을 참조하십시오.

CLI를 사용하여 원격으로 호스트를 켜려면

명령을 실행합니다.

xe host-power-on host=<host uuid>
<!--NeedCopy-->

호스트 전원 켜기 기능에 대한 사용자 지정 스크립트 구성

서버의 원격 전원 솔루션이 기본적으로 지원되지 않는 프로토콜 (예: Wake-On-Ring 또는 Intel Active 관리 기술) 을 사용하는 경우 사용자 지정 Linux Python 스크립트를 만들어 Citrix Hypervisor 컴퓨터를 원격으로 켤 수 있습니다. 그러나 DRAC 및 Wake on LAN 원격 전원 솔루션에 대한 사용자 지정 스크립트를 만들 수도 있습니다.

이 섹션에서는 Citrix Hypervisor API 호출 host.power_on과 연결된 키/값 쌍을 사용하여 호스트 전원 켜기에 대한 사용자 지정 스크립트를 구성하는 방법에 대해 설명합니다.

사용자 지정 스크립트를 만들 때 Citrix Hypervisor 서버에서 원격으로 전원을 제어하려는 경우 명령줄에서 스크립트를 실행합니다. 또는 XenCenter에서 이 기능을 지정하고 XenCenter UI 기능을 사용하여 상호 작용할 수 있습니다.

Citrix Hypervisor API는 개발자 설명서 웹 사이트에서 사용할 수 있는 Citrix Hypervisor 관리 API 문서에 설명되어 있습니다.

경고:

/etc/xapi.d/plugins/ 디렉토리에서 기본적으로 제공되는 스크립트는 변경하지 마십시오. 이 디렉터리에 새 스크립트를 포함할 수 있지만 설치 후 해당 디렉토리에 포함된 스크립트를 변경해서는 안 됩니다.

키/값 쌍

호스트 전원 켜기를 사용하려면 host.power_on_mode 및 host.power_on_config 키를 구성합니다. 값에 대한 자세한 내용은 다음 섹션을 참조하십시오.

이러한 필드를 동시에 설정할 수 있는 API 호출도 있습니다.

void host.set_host_power_on_mode(string mode, Dictionary<string,string> config)
<!--NeedCopy-->

host.power_on_mode

정의: 원격 전원 솔루션 유형 (예: Dell DRAC) 을 지정하는 키/값 쌍을 포함합니다.
가능한 값:
- 전원 제어가 비활성화됨을 나타내는 빈 문자열입니다.
- “DRAC”: Dell DRAC를 지정할 수 있습니다. DRAC를 사용하려면 Dell 보조 팩을 이미 설치해야 합니다.
- “wake-on-lan”: Wake on LAN을 지정할 수 있습니다.
- 다른 이름(사용자 정의 전원 켜기 스크립트를 지정하는 데 사용됨) 이 옵션은 전원 관리를 위한 사용자 지정 스크립트를 지정하는 데 사용됩니다.
유형: 문자열

host.power_on_config

정의: 모드 구성을 위한 키/값 쌍을 포함합니다. DRAC에 대한 추가 정보를 제공합니다.
가능한 값:
- DRAC를 원격 전원 솔루션 유형으로 구성한 경우 다음 키 중 하나도 지정해야 합니다.
  - “power_on_ip”: 전원 제어 카드와 통신하도록 구성한 지정한 IP 주소입니다. 또는 DRAC가 구성된 네트워크 인터페이스의 도메인 이름을 입력할 수 있습니다.
  - “power_on_user”: 관리 프로세서와 연결된 DRAC 사용자 이름으로, 출하 시 기본 설정에서 변경했을 수 있습니다.
  - “power_on_password_secret”: 비밀 번호 기능을 사용하여 암호를 보호하도록 지정합니다.
- 암호 기능을 사용하여 암호를 저장하려면 “power_on_password_secret” 키를 지정하십시오. 자세한 내용은 비밀을 참조하십시오.
유형: 맵 (문자열, 문자열)

샘플 스크립트

샘플 스크립트는 Citrix Hypervisor API를 가져와서 사용자 지정 스크립트로 정의한 다음 원격으로 제어하려는 호스트와 관련된 매개 변수를 전달합니다. 모든 사용자 정의 스크립트에서 session 매개 변수를 정의해야 합니다.

스크립트가 실패하면 결과가 나타납니다.

import XenAPI
def custom(session,remote_host,
power_on_config):
result="Power On Not Successful"
for key in power_on_config.keys():
result=result+''
key=''+key+''
value=''+power_on_config[key]
return result
<!--NeedCopy-->

참고:

스크립트를 만든 후 확장자가.py 인 /etc/xapi.d/플러그인에 저장합니다.

Citrix Hypervisor 서버 및 리소스 풀과 통신

TLS

Citrix Hypervisor TLS 1.2 프로토콜을 사용하여 관리 API 트래픽을 암호화합니다. Citrix Hypervisor와 관리 API 클라이언트 (또는 어플라이언스) 간의 통신에는 TLS 1.2 프로토콜이 사용됩니다.

중요:

당사는 제품의 암호화 기능에 대한 고객 수정을 지원하지 않습니다.

Citrix Hypervisor는 다음과 같은 암호 제품군을 사용합니다.

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

또한 일부 버전의 Citrix Virtual Apps and Desktops와 이전 버전의 호환성을 위해 다음 암호화 제품군도 지원됩니다.

TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA256

참고:

이러한 추가 암호 제품군은 CBC 모드를 사용합니다. 일부 조직에서는 GCM 모드를 선호하지만 Windows Server 2012 R2는 GCM 모드를 사용하는 RSA 암호 제품군을 지원하지 않습니다. Citrix Hypervisor 서버 또는 풀에 연결하는 Windows Server 2012 R2에서 실행되는 클라이언트는 이러한 CBC 모드 암호 제품군을 사용해야 할 수 있습니다.

SSH

SSH 클라이언트를 사용하여 Citrix Hypervisor 서버에 직접 연결하는 경우 다음 알고리즘을 사용할 수 있습니다.

암호:

aes128-ctr
aes256-ctr
aes128-gcm@openssh.com
aes256-gcm@openssh.com
aes128-cbc
aes256-cbc

MAC:

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

KexAlgorithms:

curve25519-sha256
ecdh-sha2-nistp256
ecdh-sha2-nistp384
ecdh-sha2-nistp521
diffie-hellman-group14-sha1

HostKeyAlgorithms:

ecdsa-sha2-nistp256
ecdsa-sha2-nistp384
ecdsa-sha2-nistp521
ssh-ed25519
ssh-rsa

Citrix Hypervisor 서버에 대한 SSH 액세스를 사용하지 않도록 설정하려면 xsconsole에서 이 작업을 수행할 수 있습니다.

XenCenter에서 서버 콘솔을 열고 root로 로그인합니다.
xsconsole을 입력합니다.
xsconsole에서 원격 서비스 구성 > 원격 셸 활성화/비활성화로 이동합니다.

콘솔에 원격 셸이 활성화되어 있는지 여부가 표시됩니다.
원격 셸의 사용 여부를 변경하려면 Enter 키를 누릅니다.

중요:

당사는 제품의 암호화 기능에 대한 고객 수정을 지원하지 않습니다.

서버에 TLS 인증서 설치

Citrix Hypervisor 서버에는 기본 TLS 인증서가 설치되어 있습니다. 그러나 HTTPS를 사용하여 Citrix Hypervisor와 Citrix Virtual Apps and Desktops 간의 통신을 보호하려면 신뢰할 수 있는 인증 기관에서 제공하는 인증서를 설치하십시오.

이 섹션에서는 xe CLI를 사용하여 인증서를 설치하는 방법에 대해 설명합니다. XenCenter를 사용하여 인증서를 사용하는 방법에 대한 자세한 내용은 XenCenter 설명서를 참조하십시오.

TLS 인증서와 해당 키가 다음 요구 사항을 충족하는지 확인합니다.

인증서와 키 쌍은 RSA 키입니다.
키가 인증서와 일치합니다.
키는 인증서에 별도의 파일로 제공됩니다.
인증서는 중간 인증서에 별도의 파일로 제공됩니다.
키 파일은 .pem 또는 .key 중 하나여야 합니다.
모든 인증서 파일은 .pem, .cer 또는 .crt 중 하나여야 합니다.
키의 길이는 2048비트보다 크거나 같고 길이가 4096비트보다 작거나 같습니다.
키는 암호화되지 않은 PKCS #8 키이며 암호 키가 없습니다.
키와 인증서는 base-64로 인코딩된 ‘PEM’ 형식입니다.
인증서가 유효하며 만료되지 않았습니다.
서명 알고리즘은 SHA-2(SHA256)입니다.

선택한 인증서와 키가 이러한 요구 사항을 충족하지 않을 경우 xe CLI에서 경고를 표시합니다.

TLS 인증서는 어디서 받을 수 있나요?

Citrix Hypervisor 서버에 설치하려는 신뢰할 수 있는 인증서가 이미 있을 수 있습니다.
또는 서버에 인증서를 만든 후 선호하는 인증 기관에 보내 서명을 받을 수도 있습니다. 이 방법은 개인 키가 Citrix Hypervisor 서버에 남아 있고 시스템 간에 복사할 수 없으므로 더 안전합니다.

TLS 인증서를 만드는 단계는 다음과 같습니다.

1. 인증서 서명 요청 생성

먼저 개인 키와 인증서 서명 요청을 생성합니다. Citrix Hypervisor 서버에서 다음 단계를 완료합니다.

프라이빗 키 파일을 생성하려면 다음 명령을 실행합니다.
```
openssl genrsa -des3 -out privatekey.pem 2048

```

키에서 암호를 제거합니다.

openssl rsa -in privatekey.pem -out privatekey.nop.pem
<!--NeedCopy-->

개인 키를 사용하여 인증서 서명 요청을 만듭니다.

openssl req -new -key privatekey.nop.pem -out csr
<!--NeedCopy-->

프롬프트에 따라 인증서 서명 요청을 생성하는 데 필요한 정보를 제공합니다.
- 국가 이름. 해당 국가의 TLS 인증서 국가 코드를 입력합니다. 예를 들어 캐나다의 경우 CA, 자메이카의 경우 JM이 있습니다. 웹에서 TLS 인증서 국가 코드 목록을 찾을 수 있습니다.
- 주 또는 지방 이름 (전체 이름). 풀이 있는 주 또는 시/도를 입력합니다. 예: 매사추세츠 또는 앨버타.
- 지역성 이름. 풀이 있는 구/군/시의 이름입니다.
- Organization Name(조직 이름): 회사 또는 조직의 이름입니다.
- Organizational Unit Name(조직 구성 단위 이름): 부서 이름을 입력합니다. 이 필드는 선택 사항입니다.
- 일반 이름. Citrix Hypervisor 서버의 FQDN을 입력합니다. Citrix는 만료되지 않는 FQDN 또는 IP 주소를 지정할 것을 권장합니다.
- 전자 메일 주소. 이 전자 메일 주소는 인증서를 생성할 때 인증서에 포함됩니다.
인증서 서명 요청은 현재 디렉터리에 저장되며 이름이 csr로 지정됩니다.
다음 명령을 실행하여 콘솔 창에 인증서 서명 요청을 표시합니다.
```
cat csr

```

전체 인증서 서명 요청을 복사하고 이 정보를 사용하여 인증 기관에 인증서를 요청합니다.

인증서 서명 요청의 예:

-----BEGIN CERTIFICATE REQUEST-----
MIIDBDCCAewCAQAwgYsxCzAJBgNVBAYTAlVLMRcwFQYDVQQIDA5DYW1icmlkZ2Vz
aGlyZTESMBAGA1UEBwwJQ2FtYnJpZGdlMRIwEAYDVQQKDAlYZW5TZXJ2ZXIxFTAT
...
SdYCkFdo+85z8hBULFzSH6jgSP0UGQU0PcfIy7KPKyI4jnFQqeCDvLdWyhtAx9gq
Fu40qMSm1dNCFfnACRwYQkQgqCt/RHeUtl8srxyZC+odbunnV+ZyQdmLwLuQySUk
ZL8naumG3yU=
-----END CERTIFICATE REQUEST-----
<!--NeedCopy-->

2. 인증 기관에 인증서 서명 요청 전송

인증서 서명 요청을 생성했으므로 이제 조직의 선호 인증 기관에 요청을 제출할 수 있습니다.

인증 기관은 디지털 인증서를 제공하는 신뢰할 수 있는 제3자입니다. 일부 인증 기관에서는 인터넷에서 액세스할 수 있는 시스템에서 인증서를 호스팅하도록 요구합니다. 이 요구 사항이 있는 인증 기관은 사용하지 않는 것이 좋습니다.

인증 기관은 서명 요청에 응답하고 다음 파일을 제공합니다.

서명된 인증서
해당하는 경우, 중간 인증서

이제 이러한 모든 파일을 Citrix Hypervisor 서버에 설치할 수 있습니다.

3. Citrix Hypervisor 서버에 서명된 인증서 설치

인증 기관이 인증서 서명 요청을 다시 실행한 후 다음 단계를 완료하여 Citrix Hypervisor 서버에 인증서를 설치합니다.

서명 인증서를 가져오고, 인증 기관에 서명 인증서가 있는 경우 인증 기관으로부터 중간 인증서를 가져옵니다.
키와 인증서를 Citrix Hypervisor 서버에 복사합니다.

서버에서 다음 명령을 실행합니다.

xe host-server-certificate-install certificate=<path_to_certificate_file> private-key=<path_to_private_key> certificate-chain=<path_to_chain_file>

certificate-chain 매개 변수는 선택 사항입니다.

보안을 강화하기 위해 인증서를 설치한 후 개인 키 파일을 삭제할 수 있습니다.

관리자 암호 관리

Citrix Hypervisor 서버를 처음 설치할 때 관리자 또는 루트 암호를 설정합니다. 이 암호를 사용하여 XenCenter를 서버에 연결하거나 사용자 이름(root)을 사용하여 시스템 구성 콘솔인 xsconsole에 로그인합니다.

서버를 풀에 조인하면 서버의 관리자 암호가 풀 마스터의 관리자 암호와 일치하도록 자동으로 변경됩니다.

참고:

Citrix Hypervisor 관리자 암호에는 인쇄 가능한 ASCII 문자만 포함되어야 합니다.

암호 변경

XenCenter, xe CLI 또는 xsconsole을 사용하여 관리자 암호를 변경할 수 있습니다.

XenCenter

XenCenter를 사용하여 풀 또는 독립 실행형 서버의 관리자 암호를 변경하려면 다음 단계를 완료하십시오.

리소스 창에서 풀이나 풀의 서버를 선택합니다.
풀 메뉴 또는 서버 메뉴에서 서버 암호 변경을 선택합니다.

독립 실행형 서버의 루트 암호를 변경하려면 리소스 창에서 서버를 선택하고 서버 메뉴에서 암호, 변경을 차례로 클릭합니다.

세션 간에 서버 로그인 자격 증명을 저장하도록 XenCenter가 구성된 경우 새 암호가 기억됩니다. 자세한 내용은 서버 연결 상태 저장을 참조하십시오.

관리자 암호를 변경한 후 풀 암호를 교체합니다. 자세한 내용은 풀 암호 교체를 참조하십시오.

xe CLI

xe CLI를 사용하여 관리자 암호를 변경하려면 풀의 서버에서 다음 명령을 실행합니다.

  xe user-password-change new=<new_password>
<!--NeedCopy-->

참고:

명령 기록에 일반 텍스트 암호가 저장되지 않도록 명령 앞에 공백을 추가해야 합니다.

관리자 암호를 변경한 후 풀 암호를 교체합니다. 자세한 내용은 풀 암호 교체를 참조하십시오.

xsconsole

xsconsole을 사용하여 풀 또는 독립 실행형 서버의 관리자 암호를 변경하려면 다음 단계를 완료하십시오.

풀 마스터에서 콘솔로 이동합니다.
root로 로그인합니다.
xsconsole을 입력합니다. Enter 키를 누릅니다. xsconsole이 표시됩니다.
xsconsole에서 화살표 키를 사용하여 인증 옵션으로 이동합니다. Enter 키를 누릅니다.
암호 변경으로 이동합니다. Enter 키를 누릅니다.
관리자 암호로 인증합니다.
암호 변경 대화 상자에서 다음을 수행합니다.
1. 현재 암호를 입력합니다.
2. 새 암호를 입력합니다.
3. 새 암호를 다시 입력하여 확인합니다.
암호 변경 성공 화면이 표시됩니다. Enter를 눌러 닫습니다.

서버가 풀 마스터인 경우 이 업데이트된 비밀번호는 이제 풀의 다른 서버로 전파됩니다.

관리자 암호를 변경한 후 풀 암호를 교체합니다. 자세한 내용은 풀 암호 교체를 참조하십시오.

분실한 루트 암호 재설정하기

Citrix Hypervisor 서버의 관리자 (루트) 암호를 분실한 경우 서버에 직접 액세스하여 암호를 재설정할 수 있습니다.

Citrix Hypervisor 서버를 재부팅합니다.
GRUB 메뉴가 표시되면 e를 눌러 부트 메뉴 항목을 편집합니다.
로 init=/sysroot/bin/sh시작하는 줄에 추가합니다 module2.
Ctrl-X를 눌러 루트 셸로 부팅합니다.

명령 셸에서 다음 명령을 실행합니다.

chroot /sysroot
passwd

(type the new password twice)

sync
/sbin/reboot -f
<!--NeedCopy-->

서버가 풀 마스터인 경우 이 업데이트된 비밀번호는 이제 풀의 다른 서버로 전파됩니다.

관리자 암호를 변경한 후 풀 암호를 교체합니다.

풀 시크릿 회전

풀 비밀은 풀에 있는 서버 간에 공유되는 비밀로, 서버가 풀에 대한 멤버쉽을 증명할 수 있도록 합니다.

풀 관리자 역할 사용자가 이 암호를 확인할 수 있으므로 이러한 사용자 중 한 명이 조직을 떠나거나 풀 관리자 역할을 상실하는 경우 풀 암호를 교체하는 것이 좋습니다.

XenCenter 또는 xe CLI를 사용하여 풀 암호를 회전할 수 있습니다.

XenCenter

XenCenter를 사용하여 풀의 풀 암호를 교체하려면 다음 단계를 완료하십시오.

리소스 창에서 풀이나 풀의 서버를 선택합니다.
풀 메뉴에서 풀 암호 교체를 선택합니다.

풀 암호를 교체할 때 루트 암호를 변경하라는 메시지도 표시됩니다. 환경이 손상되었다고 생각하여 풀 암호를 교체한 경우 루트 암호도 변경해야 합니다. 자세한 내용은 암호 변경을 참조하십시오.

xe CLI

xe CLI를 사용하여 풀 암호를 교체하려면 풀의 서버에서 다음 명령을 실행합니다.

xe pool-secret-rotate
<!--NeedCopy-->

환경이 손상되었다고 생각하여 풀 암호를 교체한 경우 루트 암호도 변경해야 합니다. 자세한 내용은 암호 변경을 참조하십시오.

Citrix Hypervisor 풀에서 IGMP 스누핑 사용

Citrix Hypervisor는 모든 게스트 VM에 멀티캐스트 트래픽을 전송하여 호스트 장치에서 요청하지 않은 패킷을 처리하도록 요구함으로써 불필요한 부하를 발생시킵니다. IGMP 스누핑을 사용하도록 설정하면 로컬 네트워크의 호스트가 명시적으로 연결되지 않은 멀티캐스트 그룹에 대한 트래픽을 수신할 수 없으며 멀티캐스트 성능이 향상됩니다. IGMP 스누핑은 IPTV와 같이 대역폭을 많이 사용하는 IP 멀티캐스트 응용 프로그램에 특히 유용합니다.

참고:

IGMP 스누핑은 네트워크 백엔드가 Open vSwitch를 사용하는 경우에만 사용할 수 있습니다.

풀에서 이 기능을 사용하도록 설정하는 경우 물리적 스위치 중 하나에서 IGMP 쿼리기를 활성화해야 할 수도 있습니다. 그렇지 않으면 하위 네트워크의 멀티캐스트가 브로드캐스트로 폴백되어 Citrix Hypervisor 성능이 저하될 수 있습니다.

IGMP v3을 실행하는 풀에서 이 기능을 사용하도록 설정하면 VM 마이그레이션 또는 네트워크 결합 장애 조치로 인해 IGMP 버전이 v2로 전환됩니다.

GRE 네트워크에서 이 기능을 사용하려면 사용자가 GRE 네트워크에서 IGMP 쿼리기를 설정해야 합니다. 또는 물리적 네트워크에서 GRE 네트워크로 IGMP 쿼리 메시지를 전달할 수 있습니다. 그렇지 않으면 GRE 네트워크의 멀티캐스트 트래픽이 차단될 수 있습니다.

XenCenter 또는 xe CLI를 사용하여 풀에서 IGMP 스누핑을 활성화할 수 있습니다.

XenCenter

풀 속성으로 이동합니다.
네트워크 옵션을 선택합니다. 여기서 IGMP 스누핑을 활성화 또는 비활성화할 수 있습니다.

xe CLI

풀 UUID 가져오기:

xe pool-list
풀에 대한 IGMP 스누핑 활성화/비활성화:

xe pool-param-set [uuid=pool-uuid] [igmp-snooping-enabled=true|false]

IGMP 스누핑을 활성화한 후 xe CLI를 사용하여 IGMP 스누핑 테이블을 볼 수 있습니다.

IGMP 스누핑 테이블 보기

다음 명령을 사용하여 IGMP 스누핑 테이블을 확인합니다.

ovs-appctl mdb/show [bridge name]

참고:

xe network-list를 사용하여 브리지 이름을 가져올 수 있습니다. 이러한 브리지 이름은 xenbr0, xenbr1, xenapi, 또는 xapi0일 수 있습니다.

그러면 네 개의 열이 있는 테이블이 출력됩니다.

포트: 스위치의 포트(OVS)입니다.
VLAN: 트래픽의 VLAN ID입니다.
GROUP: 포트가 요청한 멀티캐스트 그룹입니다.
기간: 이 레코드의 기간(초)입니다.

GROUP이 멀티캐스트 그룹 주소인 경우 연결된 스위치 포트에서 IGMP Report 메시지가 수신되었음을 의미합니다. 이는 멀티캐스트 그룹의 수신자(구성원)가 이 포트에서 수신 대기하고 있음을 의미합니다.

두 개의 레코드가 포함된 다음 예를 들어 보겠습니다.

포트	VLAN	그룹	기간
14	0	227.0.0.1	15
1	0	쿼리기	24

첫 번째 레코드는 멀티캐스트 그룹 227.0.0.1에 대해 포트 14에서 수신 대기하는 수신기가 있음을 보여줍니다. Open vSwitch는 227.0.0.1 멀티캐스트 그룹으로 향하는 트래픽을 모든 포트로 브로드캐스트하지 않고 이 그룹의 수신 포트(이 예에서는 포트 14)에만 전달합니다. 포트 14와 그룹 227.0.0.1을 연결하는 레코드가 15초 전에 생성되었습니다. 기본적으로 타임아웃 간격은 300초입니다. 즉, 레코드를 추가한 후 300초 동안 스위치가 포트 14에서 더 이상 IGMP Report 메시지를 수신하지 않으면 레코드가 만료되고 테이블에서 제거됩니다.

두 번째 레코드에서 GROUP은 쿼리기입니다. 즉, 연결된 포트에서 IGMP Query 메시지가 수신되었습니다. 쿼리기는 멀티캐스트 그룹에서 수신 중인 네트워크 노드를 확인하기 위해 모든 스위치 포트에 브로드캐스트되는 IGMP Query 메시지를 정기적으로 전송합니다. IGMP Query 메시지를 수신하면 수신자는 IGMP Report 메시지로 응답합니다. 그러면 수신자의 멀티캐스트 레코드가 새로 고쳐지고 만료되지 않습니다.

VLAN 열은 VLAN에 수신기/쿼리기가 있음을 나타냅니다. ‘0’은 네이티브 VLAN을 의미합니다. 태그가 지정된 일부 VLAN에서 멀티캐스트를 실행하려면 VLAN에 레코드가 있는지 확인하십시오.

참고:

VLAN 시나리오의 경우 VLAN 열 값이 네트워크의 VLAN ID와 동일한 쿼리 레코드가 있어야 합니다. 그렇지 않으면 VLAN 네트워크에서 멀티캐스트가 작동하지 않습니다.

이 콘텐츠의 공식 버전은 영어로 작성되었습니다. 일부 Cloud Software Group 설명서 콘텐츠는 사용자의 편의를 위해 기계 번역되었습니다. Cloud Software Group는 기계 번역 콘텐츠를 제어할 수 없으며, 오류, 부정확성 또는 부적절한 언어가 포함될 수 있습니다. 영어 원본에서 다른 언어로 번역된 모든 콘텐츠의 정확성, 신뢰성, 적합성 또는 적절성에 대한 모든 종류의 명시적 또는 묵시적 보증이나 Cloud Software Group 제품 또는 서비스가 기계 번역된 콘텐츠를 준수한다는 보증은 하지 않으며, 해당하는 최종 사용자 사용권 계약, 이용 약관 또는 제품 또는 서비스가 준수해야 하는 Cloud Software Group와의 모든 계약에 제공된 모든 보증은 기계 번역된 범위까지 적용되지 않습니다. Cloud Software Group는 기계 번역된 콘텐츠의 사용으로 인해 발생할 수 있는 손상이나 문제에 대해 책임을 지지 않습니다.

도움이 되었나요?

호스트 및 리소스 풀

September 30, 2024

제공::

X X

September 30, 2024

제공::

X X

도움이 되었나요?