Citrix Hypervisor

씬 프로비저닝된 공유 GFS2 블록 스토리지

January 31, 2025

제공::

중요:

Citrix Hypervisor 8.2 누적 업데이트 1은 2025년 6월 25일에 수명이 종료됩니다. 원활한 전환과 지속적인 지원을 위해 지금 XenServer 8로의 업그레이드를 계획하십시오. 자세한 내용은 업그레이드.

Citrix Virtual Apps and Desktops 라이센스 파일을 사용하여 Citrix Hypervisor 8.2 누적 업데이트 1 호스트에 라이센스를 부여하는 경우 이러한 라이센스 파일은 XenServer 8과 호환되지 않습니다. 업그레이드하기 전에 XenServer 8에서 사용할 XenServer Premium Edition 소켓 라이센스 파일을 얻어야 합니다. 이러한 소켓 라이센스 파일은 Citrix 워크로드를 실행하기 위한 Citrix for Private Cloud, Citrix Universal Hybrid Multi-Cloud, Citrix Universal MSP 및 Citrix Platform License 구독의 자격으로 사용할 수 있습니다. 아직 이러한 새로운 서브스크립션으로 전환하지 않은 Citrix 고객은 XenServer Premium Edition 소켓 라이센스 10,000개에 대한 무료 프로모션에 참여를 요청할 수 있습니다. 자세한 내용은 XenServer 서버.

업그레이드하기 전에 XenServer 8에 대한 호환 라이센스를 얻지 못한 경우 호스트를 업그레이드할 때 90일 평가판으로 되돌아갑니다. 평가판은 Premium Edition과 동일한 기능을 제공하지만 몇 가지 제한 사항이 있습니다. 자세한 내용은 XenServer 8 라이센스 개요.

씬 프로비저닝은 VDI의 전체 가상 크기를 미리 할당하는 대신 데이터가 가상 디스크에 기록될 때 디스크 스토리지 공간을 VDI에 할당하여 사용 가능한 스토리지를 더 잘 활용합니다. 씬 프로비저닝을 사용하면 공유 스토리지 어레이에 필요한 공간의 양을 크게 줄일 수 있으며, 그에 따라 총 소유 비용(TCO)도 절감할 수 있습니다.

공유 블록 스토리지에 대한 씬 프로비저닝은 다음과 같은 경우에 특히 유용합니다.

공간 효율성을 높이고자 합니다. 이미지가 띄엄띄엄 있고 두껍게 할당되지 않았습니다.
스토리지 배열에서 초당 I/O 작업 수를 줄이려고 합니다. GFS2 SR은 공유 블록 스토리지에서 스토리지 읽기 캐싱을 지원하는 첫 번째 SR 유형입니다.
여러 가상 머신에 대해 공통 기본 이미지를 사용합니다. 그러면 개별 VM의 이미지는 일반적으로 훨씬 더 적은 공간을 사용합니다.
스냅샷을 사용합니다. 각 스냅샷은 이미지이며 각 이미지는 이제 스파스입니다.
크기가 2TiB보다 큰 VDI를 만들려고 합니다. GFS2 SR은 최대 16TiB 크기의 VDI를 지원합니다.
스토리지는 NFS 또는 SMB3를 지원하지 않으며 블록 스토리지만 지원합니다. 스토리지가 NFS 또는 SMB3를 지원하는 경우 GFS2 대신 이러한 SR 유형을 사용하는 것이 좋습니다.
스토리지가 LUN의 씬 프로비저닝을 지원하지 않습니다. 스토리지가 씬 프로비저닝 LUN을 수행하는 경우 GFS2와 결합할 때 문제가 발생하고 공간이 부족할 수 있습니다. GFS2를 씬 프로비저닝된 LUN과 결합하는 것은 많은 추가 이점을 제공하지 않으며 권장되지 않습니다.

메모:

클러스터 네트워크가 비관리 VLAN에 있는 경우 클러스터된 풀에서 호스트를 추가하거나 제거할 수 없는 알려진 문제로 인해 VLAN과 함께 GFS2 SR을 사용하지 않는 것이 좋습니다.

공유 GFS2 유형은 iSCSI 또는 HBA LUN에서 생성된 파일 시스템으로 디스크를 나타냅니다. GFS2 SR에 저장된 VDI는 QCOW2 이미지 형식으로 저장됩니다.

이 문서에서는 xe CLI를 사용하여 GFS2 환경을 설정하는 방법에 대해 설명합니다. XenCenter를 사용하여 GFS2 환경을 설정하려면 을 참조하십시오. XenCenter 제품 설명서.

1. GFS2 환경 계획

데이터 손실 위험 없이 공유 블록 스토리지에서 씬 프로비저닝의 이점을 제공하려면 풀이 우수한 수준의 안정성과 연결성을 제공해야 합니다. GFS2를 사용하는 리소스 풀의 호스트가 서로 안정적으로 통신할 수 있는 것이 중요합니다. 이를 위해 Citrix Hypervisor를 사용하려면 GFS2 SR과 함께 클러스터된 풀을 사용해야 합니다. 또한 환경을 설계하고 Citrix Hypervisor 기능을 구성하여 가능한 한 많은 복원력과 중복성을 제공하는 것이 좋습니다.

GFS2 SR과 함께 작동하도록 Citrix Hypervisor 풀을 설정하기 전에 이상적인 GFS2 환경에 대한 다음 요구 사항 및 권장 사항을 검토하십시오.

권장: 중복 네트워킹 인프라 구성.
권장: 전용 결합 네트워크 만들기
필수: 클러스터된 풀 설정
선택적 제어 도메인 메모리 늘리기
권장: 스토리지 다중 경로 구성
필수: GFS2 SR을 생성합니다

GFS2 SR이 있는 클러스터된 풀은 다른 유형의 풀 및 SR과 동작에 몇 가지 차이점이 있습니다. 자세한 내용은 제약 조건.

2. 중복 네트워킹 인프라 구성

연결된 네트워크는 두 개 이상의 NIC를 함께 연결하여 네트워크 트래픽에 대한 단일 채널을 만듭니다. 클러스터된 풀 트래픽에 대해 연결된 네트워크를 사용하는 것이 좋습니다. 그러나 결합된 네트워크를 설정하기 전에 네트워크 하드웨어 구성이 연결된 네트워크에서 중복성을 촉진하는지 확인하십시오. 이러한 권장 사항을 조직 및 환경에 가능한 한 많이 구현하는 것이 좋습니다.

다음 모범 사례는 네트워크 스위치에 영향을 줄 수 있는 소프트웨어, 하드웨어 또는 전원 오류에 대한 복원력을 추가합니다.

동일한 스위치의 포트뿐만 아니라 연결된 네트워크에서 사용할 수 있는 별도의 물리적 네트워크 스위치가 있는지 확인합니다.
별도의 스위치가 서로 다른 독립적인 PDU(전원 분배 장치)에서 전력을 끌어오는지 확인합니다.
가능한 경우 데이터 센터에서 PDU를 전원 공급의 다른 단계 또는 다른 유틸리티 회사에서 제공하는 피드에 배치합니다.
무정전 전원 공급 장치를 사용하여 네트워크 스위치와 서버가 계속 작동하거나 정전 시 정상적으로 종료할 수 있도록 하는 것이 좋습니다.

3. 전용 본딩 네트워크 만들기

클러스터된 풀의 호스트가 서로 안정적으로 통신할 수 있도록 하는 것이 중요합니다. 이 풀 트래픽에 대해 연결된 네트워크를 만들면 클러스터된 풀의 복원력이 향상됩니다.

결합된 네트워크는 두 개 이상의 NIC 간에 결합을 만들어 클러스터된 풀이 클러스터 하트비트 트래픽에 사용할 수 있는 단일 고성능 채널을 만듭니다. 이 결합된 네트워크는 다른 트래픽에 사용되지 않는 것이 좋습니다. 관리 트래픽에 사용할 풀에 대한 별도의 네트워크를 만듭니다.

경고:

이 권장 사항을 따르지 않으면 클러스터 관리 네트워크 패킷이 손실될 위험이 높아집니다. 클러스터 관리 네트워크 패킷이 손실되면 클러스터된 풀의 쿼럼이 손실될 수 있으며 풀의 일부 또는 모든 호스트가 자체 차단됩니다.

클러스터가 펜싱을 하고 있거나 이 권장되지 않는 구성에서 문제에 직면한 경우 지원팀은 조사 과정에서 권장 구성에서 동일한 문제를 재현하도록 요청할 수 있습니다.

클러스터링 네트워크로 사용할 결합된 네트워크를 만들려면 다음을 수행합니다.

풀의 호스트 간에 방화벽이 있는 경우 호스트가 다음 포트를 사용하여 클러스터 네트워크에서 통신할 수 있는지 확인합니다.
- TCP: 8892, 8896, 21064
- UDP: 5404, 5405
자세한 내용은 Citrix Hypervisor에서 사용하는 통신 포트.
풀 마스터 역할을 할 Citrix Hypervisor 서버에서 콘솔을 엽니다.
다음 명령을 사용하여 연결된 NIC와 함께 사용할 네트워크를 만듭니다.
```
  xe network-create name-label=bond0

```
새 네트워크의 UUID가 반환됩니다.
다음 명령을 사용하여 본딩에 사용할 PIF의 UUID를 찾습니다.
```
  xe pif-list

```
액티브-액티브 모드, 액티브-패시브 모드 또는 LACP 본드 모드에서 결합된 네트워크를 생성합니다. 사용하려는 본드 모드에 따라 다음 작업 중 하나를 완료합니다.
- 활성-활성 모드(기본값)로 본드를 구성하려면 bond-create 명령을 사용하여 본드를 생성합니다. 매개변수를 구분하기 위해 쉼표를 사용하여 새로 생성된 네트워크 UUID와 본딩할 PIF의 UUID를 지정합니다.
```
   xe bond-create network-uuid=<network_uuid> /
       pif-uuids=<pif_uuid_1>,<pif_uuid_2>,<pif_uuid_3>,<pif_uuid_4>
 
```
  2개의 NIC를 본딩하는 경우에는 UUID를 2개 입력하고, 4개의 NIC를 본딩하는 경우에는 UUID를 4개 입력합니다. 명령을 실행한 후에는 본드의 UUID가 반환됩니다.
- 액티브-패시브 또는 LACP 본드 모드에서 본드를 구성하려면 동일한 구문을 사용하고 선택적 mode 매개변수를 추가하고 lacp 또는 active-backup를 지정합니다.
```
   xe bond-create network-uuid=<network_uuid> /
       pif-uuids=<pif_uuid_1>,<pif_uuid_2>,<pif_uuid_3>,<pif_uuid_4> /
       mode=balance-slb | active-backup | lacp
 
```

풀 마스터에서 결합된 네트워크를 만든 후 다른 Citrix Hypervisor 서버를 풀에 가입하면 네트워크 및 결합 정보가 가입 서버에 자동으로 복제됩니다.

자세한 내용은 네트워킹.

메모:

XenCenter를 사용하여 클러스터 네트워크의 IP 주소를 변경하려면 클러스터링 및 GFS2를 일시적으로 비활성화해야 합니다.

클러스터가 활성 상태이고 VM이 실행 중인 동안에는 클러스터링 네트워크의 본딩을 변경하지 마세요. 이 작업으로 인해 클러스터의 호스트가 하드 재시작(펜스)될 수 있습니다.

클러스터링 네트워크에서 클러스터링이 활성화된 호스트가 하나 이상 포함된 IP 주소 충돌(동일한 IP 주소를 가진 여러 호스트)이 있는 경우 클러스터가 올바르게 형성되지 않고 필요한 경우 호스트가 펜싱할 수 없습니다. 이 문제를 해결하려면 IP 주소 충돌을 해결하십시오.

액티브-패시브 본드 네트워크 장애 조치(failover) 시간을 테스트하려면 다음을 수행합니다.

액티브-패시브 모드를 사용하는 연결된 네트워크의 경우 액티브 링크에 장애가 발생하면 패시브 링크가 활성화되는 동안 네트워크 링크가 끊어지는 페일오버 기간이 있습니다. 액티브-패시브 본드 네트워크가 장애 조치(failover)하는 데 걸리는 시간이 클러스터 시간 제한보다 긴 경우 클러스터된 풀의 일부 또는 모든 호스트가 여전히 펜싱될 수 있습니다.

다음 방법 중 하나를 사용하여 네트워크를 강제로 장애 조치(failover)하여 연결된 네트워크 장애 조치(failover) 시간을 테스트할 수 있습니다.

네트워크 케이블을 물리적으로 뽑아서
하나의 네트워크 링크에서 스위치 포트를 비활성화하여

결과가 일관되도록 테스트를 여러 번 반복합니다.

풀의 클러스터 제한 시간 값은 클러스터에 있는 호스트 수에 따라 달라집니다. 다음 명령을 실행하여 토큰 시간 초과 풀의 값(초):Value in seconds in the Pool:

  xe cluster-param-get uuid=<cluster_uuid> param-name=token-timeout

장애 조치(failover) 시간이 시간 제한 값보다 클 가능성이 있는 경우 네트워크 인프라 및 구성이 클러스터된 풀을 지원할 만큼 충분히 안정적이지 않을 수 있습니다.

4. 클러스터된 풀 설정

공유 GFS2 스토리지를 사용하려면 Citrix Hypervisor 리소스 풀이 클러스터된 풀이어야 합니다. GFS2 SR을 생성하기 전에 풀에서 클러스터링을 활성화합니다.

클러스터된 풀은 클러스터되지 않은 풀의 호스트보다 더 긴밀하게 연결되고 조정된 Citrix Hypervisor 서버 풀입니다. 클러스터의 호스트는 선택한 네트워크에서 서로 지속적인 통신을 유지합니다. 클러스터의 모든 호스트는 클러스터에 있는 모든 호스트의 상태를 인식합니다. 이 호스트 조정을 통해 클러스터는 GFS2 SR의 내용에 대한 액세스를 제어할 수 있습니다. 클러스터된 풀이 항상 통신 상태를 유지하도록 하려면 클러스터의 각 호스트가 항상 클러스터에 있는 호스트의 절반 이상(자체 포함)과 통신해야 합니다. 이 상태를 쿼럼이 있는 호스트라고 합니다. 호스트에 쿼럼이 없는 경우 하드 다시 시작되고 클러스터에서 제거됩니다. 이 작업을 ‘펜싱’이라고 합니다.

자세한 내용은 클러스터형 풀을 참조하세요.

클러스터된 풀 설정을 시작하기 전에 다음 필수 구성 요소가 충족되는지 확인합니다.

3개에서 16개 사이의 호스트로 구성된 풀을 만들 계획입니다.

가능한 경우 클러스터된 풀에서 홀수의 호스트를 사용하면 호스트에 quorun이 있는지 항상 확인할 수 있습니다. 두 개의 호스트로 구성된 풀은 전체 풀의 자체 펜싱에 민감하므로 세 개 이상의 호스트가 포함된 풀에서만 클러스터링을 사용하는 것이 좋습니다.

클러스터된 풀은 풀당 최대 16개의 호스트만 지원합니다.
클러스터된 풀의 모든 Citrix Hypervisor 서버에는 최소 2GiB의 제어 도메인 메모리가 있어야 합니다.
클러스터의 모든 호스트는 클러스터 네트워크에 고정 IP 주소를 사용해야 합니다.
기존 풀을 클러스터링하는 경우 고가용성이 비활성화되어 있는지 확인합니다. 클러스터링을 사용하도록 설정한 후 고가용성을 다시 사용하도록 설정할 수 있습니다.

xe CLI를 사용하여 클러스터된 풀을 만들려면 다음을 수행합니다.

3개 이상의 Citrix Hypervisor 서버로 구성된 리소스 풀을 만듭니다.

풀 마스터가 아닌 Citrix Hypervisor 서버에 가입할 때마다 다음 단계를 반복합니다.
1. Citrix Hypervisor 서버에서 콘솔을 엽니다.
2. 다음 명령을 사용하여 Citrix Hypervisor 서버를 풀 마스터의 풀에 가입시킵니다.
```
  xe pool-join master-address=<master_address> /
      master-username=<administrators_username> /
      master-password=<password>

```
  의 값 마스터 주소 매개 변수는 풀 마스터인 Citrix Hypervisor 서버의 정규화된 도메인 이름으로 설정해야 합니다. 이 암호 풀 마스터를 설치할 때 설정된 관리자 암호여야 합니다.
자세한 내용은 호스트 및 리소스 풀.
이 네트워크에 속하는 모든 PIF에 대해 disallow-unplug=참.
1. 다음 명령을 사용하여 네트워크에 속하는 PIF의 UUID를 찾습니다.
```
  xe pif-list

```
2. 리소스 풀의 Citrix Hypervisor 서버에서 다음 명령을 실행합니다.
```
  xe pif-param-set disallow-unplug=true uuid=<pif_uuid>

```
풀에서 클러스터링을 사용하도록 설정합니다. 리소스 풀의 Citrix Hypervisor 서버에서 다음 명령을 실행합니다.
```
  xe cluster-pool-create network-uuid=<network_uuid>

```
이전 단계에서 만든 연결된 네트워크의 UUID를 제공합니다.

5. 제어 도메인 메모리 늘리기

호스트에 제어 도메인 메모리가 충분하지 않으면 풀에서 네트워크 불안정이 발생할 수 있습니다. 네트워크 불안정으로 인해 GFS2 SR이 있는 클러스터된 풀에 문제가 발생할 수 있습니다.

클러스터된 풀에 적절한 양의 제어 도메인 메모리가 있는지 확인하는 것이 중요합니다. 제어 도메인 메모리의 양을 변경하고 메모리 동작을 모니터링하는 방법에 대한 자세한 내용은 다음을 참조하십시오. 메모리 사용량.

6. 스토리지 다중 경로 구성

클러스터 풀과 GFS2 SR 사이에 스토리지 다중 경로가 설정되어 있는지 확인합니다.

다중 경로는 중복성을 위해 여러 경로를 통해 스토리지 트래픽을 스토리지 장치로 라우팅합니다. 모든 경로에는 정상 작동 중에 활성 트래픽이 있을 수 있으며, 이로 인해 처리량이 증가합니다.

다중 경로를 활성화하기 전에 다음 진술이 true인지 확인하십시오.

이더넷 또는 파이버 스위치는 스토리지 서버에서 여러 대상을 사용할 수 있도록 구성되어 있습니다.

예를 들어, iSCSI 스토리지 백엔드는 다음을 쿼리했습니다. SendTargets 지정된 포털에서 다음 예제와 같이 여러 대상을 반환합니다.
```
    iscsiadm -m discovery --type sendtargets --portal 192.168.0.161
    192.168.0.161:3260,1 iqn.strawberry:litchie
    192.168.0.204:3260,2 iqn.strawberry:litchie
```
그러나 단일 대상만 노출하는 어레이에 대해 iSCSI 다중 경로를 활성화하기 위해 추가 구성을 수행할 수 있습니다. 자세한 내용은 단일 대상만 노출하는 어레이를 위한 iSCSI 다중 경로.
iSCSI의 경우에만 제어 도메인(dom0)에는 다중 경로 스토리지에서 사용하는 각 서브넷의 IP 주소가 있습니다.

스토리지의 각 경로에 NIC가 있고 각 NIC에 IP 주소가 구성되어 있는지 확인합니다. 예를 들어 스토리지에 대한 4개의 경로를 원하는 경우 각각 IP 주소가 구성된 4개의 NIC가 있어야 합니다.
iSCSI의 경우에만 모든 iSCSI 대상 및 초기자에는 고유한 IQN이 있습니다.
iSCSI의 경우에만 iSCSI 대상 포트가 포털 모드에서 작동합니다.
HBA의 경우에만 여러 HBA가 스위치 패브릭에 연결됩니다.
가능하면 여러 개의 중복 스위치를 사용합니다.

xe CLI를 사용하여 다중 경로를 활성화하려면

풀의 모든 호스트에 대해 다중 경로를 사용하도록 설정하는 것이 좋습니다 전에 SR을 생성합니다. 다중 경로 지정을 활성화하기 전에 SR을 생성하는 경우 다중 경로를 활성화하려면 호스트를 유지 보수 모드로 전환해야 합니다.

Citrix Hypervisor 서버에서 콘솔을 엽니다.
다음 명령을 사용하여 호스트의 모든 PBD를 분리합니다.
```
  xe pbd-unplug uuid=<pbd_uuid>

```
다음 명령을 사용할 수 있습니다. xe pbd-목록 PBD의 UUID를 찾습니다.
의 값을 설정합니다. 다중 경로 지정 매개 변수를 참 다음 명령을 사용합니다.
```
  xe host-param-set uuid=<host uuid> multipathing=true

```
단일 경로 모드에서 실행 중인 호스트에 여러 경로가 있는 기존 SR이 있는 경우:
- 영향을 받는 SR에서 가상 디스크가 있는 실행 중인 게스트를 마이그레이션하거나 일시 중단합니다.
- 영향을 받는 SR의 PBD를 다시 연결하여 다중 경로를 사용하여 다시 연결합니다.
```
   xe pbd-plug uuid=<pbd_uuid>
 
```
이 단계를 반복하여 풀의 모든 호스트에서 다중 경로를 활성화합니다.

풀의 모든 호스트에서 다중 경로를 활성화해야 합니다. 모든 케이블 연결 및 iSCSI의 경우 서브넷 구성은 각 호스트의 해당 NIC와 일치해야 합니다.

자세한 내용은 스토리지 다중 경로 지정.

7. GFS2 SR 생성

리소스 풀의 모든 Citrix Hypervisor 서버에서 볼 수 있는 iSCSI 또는 HBA LUN에서 공유 GFS2 SR을 생성합니다. GFS2에서 씬 프로비저닝된 LUN을 사용하지 않는 것이 좋습니다. 그러나 이 구성을 선택하는 경우 LUN에 Citrix Hypervisor가 쓸 수 있는 충분한 공간이 항상 있는지 확인해야 합니다.

클러스터된 풀에 최대 62개의 GFS2 SR을 추가할 수 있습니다.

이전에 LVM을 사용한 씩 프로비저닝을 위해 블록 기반 스토리지 장치를 사용한 적이 있는 경우 Citrix Hypervisor에서 이를 감지합니다. XenCenter는 기존 LVM 파티션을 사용하거나 디스크를 포맷하고 GFS2 파티션을 설정할 수 있는 기회를 제공합니다.

iSCSI SR을 통해 공유 GFS2를 생성합니다

XenCenter를 사용하여 iSCSI SR을 통해 GFS2를 생성할 수 있습니다. 자세한 내용은 소프트웨어 iSCSI 스토리지 XenCenter 제품 설명서에 나와 있습니다.

또는 xe CLI를 사용하여 iSCSI SR을 통해 GFS2를 생성할 수 있습니다.

GFS2 SR에 대한 Device-config 매개변수:

매개 변수 이름	설명	필수?
`provider`	블록 공급자 구현입니다. 이 경우 `iSCSI (영문)`.	예
`target`	호스팅하는 iSCSI 파일러의 IP 주소 또는 호스트 이름	예
`targetIQN`	SR을 호스팅하는 iSCSI 파일러의 IQN 대상입니다	예
`SCSIid`	장치 SCSI ID	예

를 사용하여 이러한 매개 변수에 사용할 값을 찾을 수 있습니다. xe sr-프로브-ext 명령.

  xe sr-probe-ext type=<type> host-uuid=<host_uuid> device-config:=<config> sm-config:=<sm_config>
<!--NeedCopy-->

먼저 다음 명령을 실행합니다.
```
  xe sr-probe-ext type=gfs2 device-config:provider=iscsi

```
명령의 출력은 추가 매개 변수를 제공하라는 메시지를 표시하고 각 단계에서 가능한 값 목록을 제공합니다.
명령을 반복하여 매번 새 매개변수를 추가합니다.

명령 출력이 다음으로 시작하는 경우 SR을 생성하는 데 사용할 수 있는 다음과 같은 전체 구성을 찾았습니다.를 사용하여 SR을 찾을 수 있습니다. xe sr-생성 명령과 장치 구성 지정한 매개 변수입니다.

예제 출력 :

  Found the following complete configurations that can be used to create SRs:
  Configuration 0:
    SCSIid       : 36001405852f77532a064687aea8a5b3f
        targetIQN: iqn.2009-01.example.com:iscsi192a25d6
           target: 198.51.100.27
         provider: iscsi


  Configuration 0 extra information:
<!--NeedCopy-->

iSCSI 대상의 특정 LUN에서 공유 GFS2 SR을 생성하려면 클러스터 풀의 서버에서 다음 명령을 실행합니다.

  xe sr-create type=gfs2 name-label="Example GFS2 SR" --shared \
     device-config:provider=iscsi device-config:targetIQN=<target_iqns> \
     device-config:target=<portal_address> device-config:SCSIid=<scsci_id>
<!--NeedCopy-->

GFS2 파일 시스템이 마운트된 동안 iSCSI 대상에 연결할 수 없는 경우 클러스터 풀의 일부 호스트가 하드 재시작(펜스)될 수 있습니다.

iSCSI SR 작업에 대한 자세한 내용은 다음을 참조하십시오. 소프트웨어 iSCSI 지원.

HBA SR을 통해 공유 GFS2를 생성합니다

XenCenter를 사용하여 HBA SR을 통해 GFS2를 생성할 수 있습니다. 자세한 내용은 하드웨어 HBA 스토리지 XenCenter 제품 설명서에 나와 있습니다.

또는 xe CLI를 사용하여 HBA SR을 통해 GFS2를 생성할 수 있습니다.

GFS2 SR에 대한 Device-config 매개변수:

매개 변수 이름	설명	필수?
`provider`	블록 공급자 구현입니다. 이 경우 `HBA (영어)`.	예
`SCSIid`	장치 SCSI ID	예

를 사용하여 SCSIid 매개 변수에 사용할 값을 찾을 수 있습니다. xe sr-프로브-ext 명령.

  xe sr-probe-ext type=<type> host-uuid=<host_uuid> device-config:=<config> sm-config:=<sm_config>
<!--NeedCopy-->

먼저 다음 명령을 실행합니다.
```
  xe sr-probe-ext type=gfs2 device-config:provider=hba

```
명령의 출력은 추가 매개 변수를 제공하라는 메시지를 표시하고 각 단계에서 가능한 값 목록을 제공합니다.
명령을 반복하여 매번 새 매개변수를 추가합니다.

예제 출력 :

  Found the following complete configurations that can be used to create SRs:
  Configuration 0:
    SCSIid       : 36001405852f77532a064687aea8a5b3f
        targetIQN: iqn.2009-01.example.com:iscsi192a25d6
           target: 198.51.100.27
         provider: iscsi


  Configuration 0 extra information:
<!--NeedCopy-->

HBA 대상의 특정 LUN에서 공유 GFS2 SR을 생성하려면 클러스터 풀의 서버에서 다음 명령을 실행합니다.

  xe sr-create type=gfs2 name-label="Example GFS2 SR" --shared \
    device-config:provider=hba device-config:SCSIid=<device_scsi_id>
<!--NeedCopy-->

HBA SR 작업에 대한 자세한 내용은 다음을 참조하십시오. 하드웨어 호스트 버스 어댑터.

다음 단계

이제 GFS2 환경을 설정했으므로 쿼럼이 있는지 확인하여 클러스터 풀의 안정성을 유지하는 것이 중요합니다. 자세한 내용은 클러스터된 풀 관리.

GFS2 환경에서 문제가 발생하면 을 참조하십시오. 클러스터된 풀 문제 해결Troubleshoot clustered pools.

다른 SR과 동일한 방식으로 GFS2 SR을 관리할 수 있습니다. 예를 들어, 스토리지 배열에 용량을 추가하여 LUN의 크기를 늘릴 수 있습니다. 자세한 내용은 라이브 LUN 확장.

제약 조건

공유 GFS2 스토리지에는 현재 다음과 같은 제약 조건이 있습니다.

씬 프로비저닝된 SR과 마찬가지로 GFS2 SR 사용량이 100%로 증가하면 VM의 추가 쓰기가 실패합니다. 이러한 쓰기 실패로 인해 VM 내에서 오류가 발생하거나 데이터가 손상되거나 둘 다 발생할 수 있습니다.
XenCenter는 SR 사용량이 80%로 증가할 때 경고를 표시합니다. 이 경고에 대해 GFS2 SR을 모니터링하고 표시되면 적절한 조치를 취해야 합니다. GFS2 SR에서 사용량이 많으면 성능이 저하됩니다. SR 사용률을 80% 미만으로 유지하는 것이 좋습니다.
스토리지 마이그레이션(라이브 또는 오프라인)을 사용한 VM 마이그레이션은 VDI가 GFS2 SR에 있는 VM에 대해 지원되지 않습니다. 또한 다른 유형의 SR에서 GFS2 SR로 VDI를 마이그레이션할 수 없습니다.
소프트웨어 FCoE 전송은 GFS2 SR에서 지원되지 않습니다( 완전히 오프로드된 FCoE는 HBA를 사용합니다).
트리밍/매핑 해제는 GFS2 SR에서 지원되지 않습니다.
CHAP는 GFS2 SR에서 지원되지 않습니다.
MCS 전체 복제 VM은 GFS2 SR에서 지원되지 않습니다.
동일한 MCS 카탈로그에서 여러 GFS2 SR을 사용하는 것은 지원되지 않습니다.
이러한 SR의 GFS2 SR 및 디스크에는 성능 메트릭을 사용할 수 없습니다.
GFS2 SR에 저장된 VDI에 대해서는 변경된 블록 추적이 지원되지 않습니다.
2TiB보다 큰 VDI는 VHD 또는 OVA/OVF로 내보낼 수 없습니다. 그러나 VDI가 2TiB보다 큰 VM을 XVA 형식으로 내보낼 수 있습니다.
GFS2에서 씬 프로비저닝된 LUN을 사용하지 않는 것이 좋습니다. 그러나 이 구성을 선택하는 경우 LUN에 Citrix Hypervisor가 쓸 수 있는 충분한 공간이 항상 있는지 확인해야 합니다.
GFS2 SR과 함께 SAN 중복 제거를 사용하지 않는 것이 좋습니다. 그러나 이 구성을 선택하는 경우 SAN 사용률에 대한 적절한 외부 모니터링을 사용하여 Citrix Hypervisor가 쓸 수 있는 공간이 항상 있는지 확인해야 합니다.
GFS2 파일 시스템은 100TiB보다 클 수 없습니다.
풀에는 62개 이상의 GFS2 SR이 있을 수 없습니다.
클러스터된 풀은 풀당 최대 16개의 호스트만 지원합니다.
클러스터된 풀에서 HA를 활성화하려면 하트비트 SR이 GFS2 SR이어야 합니다.
클러스터 트래픽의 경우 두 개 이상의 서로 다른 네트워크 스위치를 사용하는 연결된 네트워크를 사용하는 것이 좋습니다. 이 네트워크를 다른 용도로 사용하지 마십시오.
XenCenter를 사용하여 클러스터 네트워크의 IP 주소를 변경하려면 클러스터링 및 GFS2를 일시적으로 비활성화해야 합니다.
클러스터가 활성 상태이고 VM이 실행 중인 동안에는 클러스터링 네트워크의 본딩을 변경하지 마세요. 이 작업으로 인해 클러스터의 호스트가 하드 재시작(펜스)될 수 있습니다.
클러스터링 네트워크에서 클러스터링이 활성화된 호스트가 하나 이상 포함된 IP 주소 충돌(동일한 IP 주소를 가진 여러 호스트)이 있는 경우 클러스터가 올바르게 형성되지 않고 필요한 경우 호스트가 펜싱할 수 없습니다. 이 문제를 해결하려면 IP 주소 충돌을 해결하십시오.

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

도움이 되었나요?

씬 프로비저닝된 공유 GFS2 블록 스토리지

January 31, 2025

제공::

January 31, 2025

제공::

도움이 되었나요?