씬 프로비저닝된 공유 GFS2 블록 스토리지
씬 프로비저닝은 VDI의 전체 가상 크기를 미리 할당하는 대신, 데이터가 가상 디스크에 기록될 때 VDI에 디스크 스토리지 공간을 할당하여 사용 가능한 스토리지를 더 효율적으로 활용합니다. 씬 프로비저닝을 통해 공유 스토리지 어레이에 필요한 공간을 크게 줄일 수 있으며, 이에 따라 총 소유 비용(TCO)도 절감할 수 있습니다.
경고:
GFS2에는 진행하기 전에 신중하게 고려해야 할 여러 가지 제한 사항과 복잡성이 있습니다. 많은 경우 대체 스토리지 전략이 더 적절할 수 있습니다.
GFS2의 제한 사항은 다음과 같습니다.
- 모든 기능이 제공되지 않음 (DR 미지원, 스토리지 마이그레이션 미지원, 풀 크기 16개로 제한)
- 성능 제한으로 인해 대규모 I/O 집약적 워크로드에 부적합
- 클러스터 서비스 필요, 이는 안정성 문제를 야기할 수 있음
- 이해하기 더 복잡하여 잘못된 구성 및 오류 증가
이러한 제한 사항과 복잡성을 이해할 때, GFS2는 요구 사항을 충족할 대안이 없는 경우에만 사용하는 것이 좋습니다. GFS2가 적절할 수 있는 시나리오는 다음과 같습니다.
- 씬 프로비저닝이 필요하지만 SAN에서 제공되지 않는 경우. 씬 프로비저닝 요구 사항을 제공하는 SAN과 함께 LVM 스토리지를 사용하는 것이 좋습니다. 이것이 불가능한 경우 GFS2를 고려할 수 있습니다.
- 2TiB 초과 디스크 지원. GFS2는 최대 16TB 디스크를 지원합니다. 2TiB 초과 디스크가 필요한 경우 GFS2를 고려할 수 있습니다. 고객은 환경이 로드 및 성능 요구 사항을 충족할 수 있는지 확인하기 위해 테스트를 수행해야 합니다.
SAN이 씬 프로비저닝을 지원하는 경우, 2TiB보다 큰 VM 디스크가 필요하지 않다면 GFS2 대신 LVM과 함께 이를 사용하는 것이 좋습니다. 2TiB보다 큰 VM 디스크가 필요한 경우에는 LVM에서 여러 디스크를 사용하여 이를 달성하는 것을 고려하십시오.
공유 GFS2 유형은 iSCSI 또는 HBA LUN에 생성된 파일 시스템으로 디스크를 나타냅니다. GFS2 SR에 저장된 VDI는 QCOW2 이미지 형식으로 저장됩니다.
이 문서에서는 xe CLI를 사용하여 GFS2 환경을 설정하는 방법을 설명합니다. XenCenter를 사용하여 GFS2 환경을 설정하려면 (/ko-kr/xencenter/current-release/storage-pools-add-gfs2.html)을 참조하십시오.
1. GFS2 환경 계획
데이터 손실 위험 없이 공유 블록 스토리지에서 씬 프로비저닝의 이점을 제공하려면 풀이 우수한 수준의 안정성과 연결성을 제공해야 합니다. GFS2를 사용하는 리소스 풀의 호스트가 서로 안정적으로 통신하는 것이 중요합니다. 이를 보장하기 위해 XenServer®는 GFS2 SR과 함께 클러스터형 풀을 사용하도록 요구합니다. 또한 가능한 한 많은 복원력과 이중화를 제공하도록 환경을 설계하고 XenServer 기능을 구성하는 것이 좋습니다.
GFS2 SR과 함께 작동하도록 XenServer 풀을 설정하기 전에 이상적인 GFS2 환경에 대한 다음 요구 사항 및 권장 사항을 검토하십시오.
-
권장: 중복 네트워킹 인프라 구성.
-
권장: 전용 본딩 네트워크 생성
-
필수: 클러스터형 풀 설정
-
선택 사항: 제어 도메인 메모리 늘리기
-
권장: 스토리지 멀티패싱 구성
-
필수: GFS2 SR 생성
GFS2 SR이 있는 클러스터형 풀은 다른 유형의 풀 및 SR과 동작 방식에 약간의 차이가 있습니다. 자세한 내용은 제약 조건을 참조하십시오.
2. 중복 네트워킹 인프라 구성
본딩 네트워크는 두 개 이상의 NIC를 연결하여 네트워크 트래픽을 위한 단일 채널을 생성합니다. 클러스터형 풀 트래픽에 본딩 네트워크를 사용하는 것이 좋습니다. 그러나 본딩 네트워크를 설정하기 전에 네트워크 하드웨어 구성이 본딩 네트워크의 이중화를 촉진하는지 확인하십시오. 조직 및 환경에 실현 가능한 한 많은 권장 사항을 구현하는 것을 고려하십시오.
다음 모범 사례는 네트워크 스위치에 영향을 미칠 수 있는 소프트웨어, 하드웨어 또는 전원 장애에 대한 복원력을 추가합니다.
- 동일한 스위치의 포트뿐만 아니라 본딩 네트워크에서 사용할 수 있는 별도의 물리적 네트워크 스위치가 있는지 확인하십시오.
- 별도의 스위치가 서로 다른 독립적인 전원 분배 장치(PDU)에서 전원을 공급받는지 확인하십시오.
- 가능하다면, 데이터 센터에서 PDU를 전원 공급 장치의 다른 단계 또는 다른 유틸리티 회사에서 제공하는 공급 장치에 배치하십시오.
- 정전 시 네트워크 스위치와 서버가 계속 작동하거나 정상적으로 종료될 수 있도록 무정전 전원 공급 장치 사용을 고려하십시오.
3. 전용 본딩 네트워크 생성
클러스터형 풀의 호스트가 서로 안정적으로 통신할 수 있도록 보장하는 것이 중요합니다. 이 풀 트래픽에 대한 본딩 네트워크를 생성하면 클러스터형 풀의 복원력이 향상됩니다.
참고:
클러스터 네트워크는 비관리 VLAN에 있을 수 없습니다.
본딩 네트워크는 두 개 이상의 NIC 간에 본드를 생성하여 클러스터형 풀이 클러스터 하트비트 트래픽에 사용할 수 있는 단일의 고성능 채널을 만듭니다. 이 본딩 네트워크를 다른 트래픽에 사용하지 않는 것을 강력히 권장합니다. 관리 트래픽에 사용할 풀을 위한 별도의 네트워크를 생성하십시오.
경고:
이 권장 사항을 따르지 않기로 선택하면 클러스터 관리 네트워크 패킷 손실 위험이 더 높아집니다. 클러스터 관리 네트워크 패킷 손실은 클러스터형 풀이 쿼럼을 잃게 하고 풀의 일부 또는 모든 호스트가 자체 펜싱을 수행하게 할 수 있습니다.
클러스터가 이 권장되지 않는 구성에서 펜싱되거나 문제가 발생하는 경우, XenServer 지원팀은 조사 과정에서 권장 구성에서 동일한 문제를 재현하도록 요청할 수 있습니다.
GFS2 클러스터 네트워크로 사용할 본딩 네트워크를 생성하려면:
-
풀의 호스트 간에 방화벽이 있는 경우, 호스트가 다음 포트를 사용하여 클러스터 네트워크에서 통신할 수 있는지 확인하십시오.
- TCP: 8892, 8896, 21064
- UDP: 5404, 5405
자세한 내용은 XenServer에서 사용하는 통신 포트를 참조하십시오.
-
풀 코디네이터 역할을 할 XenServer 호스트에서 콘솔을 엽니다.
-
다음 명령을 사용하여 본딩된 NIC와 함께 사용할 네트워크를 생성합니다.
xe network-create name-label=bond0 <!--NeedCopy-->새 네트워크의 UUID가 반환됩니다.
-
다음 명령을 사용하여 본드에 사용할 PIF의 UUID를 찾습니다.
xe pif-list <!--NeedCopy--> -
활성-활성 모드, 활성-수동 모드 또는 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> <!--NeedCopy-->두 개의 NIC를 본딩할 때는 두 개의 UUID를 입력하고, 네 개의 NIC를 본딩할 때는 네 개의 UUID를 입력합니다. 명령을 실행하면 본드의 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 <!--NeedCopy-->
-
풀 코디네이터에 본딩된 네트워크를 생성한 후 다른 XenServer 호스트를 풀에 조인하면 네트워크 및 본드 정보가 조인하는 서버로 자동으로 복제됩니다.
자세한 내용은 네트워킹을 참조하십시오.
참고:
- XenCenter®를 사용하여 클러스터 네트워크의 IP 주소를 변경하려면 클러스터링 및 GFS2를 일시적으로 비활성화해야 합니다.
- 클러스터가 활성 상태이고 실행 중인 VM이 있는 동안에는 클러스터 네트워크의 본딩을 변경하지 마십시오. 이 작업으로 인해 클러스터의 호스트가 하드 재시작(펜싱)될 수 있습니다.
- 클러스터 네트워크에서 IP 주소 충돌(여러 호스트가 동일한 IP 주소를 가짐)이 발생하고 클러스터링이 활성화된 호스트가 하나 이상 포함된 경우, 클러스터가 올바르게 형성되지 않고 호스트가 필요할 때 펜싱할 수 없습니다. 이 문제를 해결하려면 IP 주소 충돌을 해결하십시오.
풀의 클러스터 시간 초과 값은 클러스터에 있는 호스트 수에 따라 달라집니다. 다음 명령을 실행하여 풀의 token-timeout 값을 초 단위로 찾으십시오.
xe cluster-param-get uuid=<cluster_uuid> param-name=token-timeout
네트워크 본드 페일오버 시간이 타임아웃 값보다 길어질 가능성이 있다면, 네트워크 인프라 및 구성이 클러스터형 풀을 지원하기에 충분히 안정적이지 않을 수 있습니다.
4. 클러스터형 풀 설정
공유 GFS2 스토리지를 사용하려면 XenServer 리소스 풀이 클러스터형 풀이어야 합니다. GFS2 SR을 생성하기 전에 풀에서 클러스터링을 활성화하십시오.
클러스터형 풀은 비클러스터형 풀의 호스트보다 더 긴밀하게 연결되고 조정되는 XenServer 호스트 풀입니다. 클러스터의 호스트는 선택된 네트워크에서 서로 지속적으로 통신합니다. 클러스터의 모든 호스트는 클러스터 내 모든 호스트의 상태를 인식합니다. 이러한 호스트 조정은 클러스터가 GFS2 SR 콘텐츠에 대한 액세스를 제어할 수 있도록 합니다. 클러스터형 풀이 항상 통신 상태를 유지하도록 하려면 클러스터의 각 호스트는 클러스터 내 호스트의 절반 이상(자신 포함)과 항상 통신해야 합니다. 이 상태를 호스트가 쿼럼을 가졌다고 합니다. 호스트가 쿼럼을 갖지 못하면 하드 재시작되고 클러스터에서 자체적으로 제거됩니다. 이 작업을 ‘펜싱’이라고 합니다.
자세한 내용은 클러스터형 풀을 참조하십시오.
클러스터형 풀 설정을 시작하기 전에 다음 전제 조건이 충족되었는지 확인하십시오.
-
3개에서 16개 사이의 호스트로 풀을 생성할 계획을 세우십시오.
가능한 경우 클러스터형 풀에 홀수 개의 호스트를 사용하십시오. 이렇게 하면 호스트가 쿼럼을 가지고 있는지 항상 확인할 수 있습니다. 두 개의 호스트로 구성된 풀은 전체 풀이 자체 펜싱될 가능성이 높으므로, 최소 세 개의 호스트를 포함하는 풀에서만 클러스터링을 사용하는 것이 좋습니다.
클러스터형 풀은 풀당 최대 16개의 호스트만 지원합니다.
- 클러스터형 풀의 모든 XenServer 호스트는 최소 2GiB의 제어 도메인 메모리를 가져야 합니다.
- 클러스터의 모든 호스트는 클러스터 네트워크에 대해 고정 IP 주소를 사용해야 합니다.
- 기존 풀을 클러스터링하는 경우 고가용성이 비활성화되어 있는지 확인하십시오. 클러스터링이 활성화된 후 고가용성을 다시 활성화할 수 있습니다.
xe CLI를 사용하여 클러스터형 풀을 생성하려면:
-
최소 3개의 XenServer 호스트로 리소스 풀을 생성합니다.
풀 코디네이터가 아닌 각 참여 XenServer 호스트에서 다음 단계를 반복합니다.
- XenServer 호스트에서 콘솔을 엽니다.
-
다음 명령을 사용하여 XenServer 호스트를 풀 코디네이터의 풀에 조인합니다.
xe pool-join master-address=<master_address> / master-username=<administrators_username> / master-password=<password> <!--NeedCopy-->master-address매개변수 값은 풀 코디네이터인 XenServer 호스트의 FQDN(정규화된 도메인 이름)으로 설정해야 합니다.password는 풀 코디네이터가 설치될 때 설정된 관리자 암호여야 합니다.
자세한 내용은 호스트 및 리소스 풀을 참조하십시오.
-
이 네트워크에 속하는 모든 PIF에 대해
disallow-unplug=true을(를) 설정합니다.-
다음 명령을 사용하여 네트워크에 속하는 PIF의 UUID를 찾습니다.
xe pif-list <!--NeedCopy--> -
리소스 풀의 XenServer 호스트에서 다음 명령을 실행합니다.
xe pif-param-set disallow-unplug=true uuid=<pif_uuid> <!--NeedCopy-->
-
-
풀에서 클러스터링을 활성화합니다. 리소스 풀의 XenServer 호스트에서 다음 명령을 실행합니다.
xe cluster-pool-create network-uuid=<network_uuid> <!--NeedCopy-->이전 단계에서 생성한 본딩된 네트워크의 UUID를 제공합니다.
5. 제어 도메인 메모리 늘리기
호스트에 제어 도메인 메모리가 부족하면 풀에서 네트워크 불안정성이 발생할 수 있습니다. 네트워크 불안정성은 GFS2 SR이 있는 클러스터형 풀에 문제를 일으킬 수 있습니다.
클러스터형 풀에 적절한 양의 제어 도메인 메모리가 있는지 확인하는 것이 중요합니다. 제어 도메인 메모리 양 변경 및 메모리 동작 모니터링에 대한 자세한 내용은 메모리 사용량을 참조하십시오.
6. 스토리지 다중 경로 구성
클러스터형 풀과 GFS2 SR 간에 스토리지 다중 경로가 설정되어 있는지 확인합니다.
다중 경로는 이중화를 위해 여러 경로를 통해 스토리지 트래픽을 스토리지 장치로 라우팅합니다. 모든 경로는 정상 작동 중에 활성 트래픽을 가질 수 있으며, 이는 처리량 증가로 이어집니다.
멀티패싱을 활성화하기 전에 다음 사항이 참인지 확인하십시오:
-
이더넷 또는 파이버 스위치가 스토리지 서버에서 여러 대상을 사용할 수 있도록 구성되어 있습니다.
예를 들어, 특정 포털에서
sendtargets을(를) 쿼리한 iSCSI 스토리지 백엔드는 다음 예시와 같이 여러 대상을 반환합니다.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 주소가 구성된 NIC가 4개 있어야 합니다.
-
iSCSI에 한해, 모든 iSCSI 대상 및 이니시에이터는 고유한 IQN을 가집니다.
-
iSCSI에 한해, iSCSI 대상 포트는 포털 모드에서 작동합니다.
-
HBA에 한해, 여러 HBA가 스위치 패브릭에 연결되어 있습니다.
-
가능하다면 여러 개의 이중화된 스위치를 사용하십시오.
xe CLI를 사용하여 멀티패싱을 활성화하려면
SR을 생성하기 전에 풀의 모든 호스트에 대해 멀티패싱을 활성화하는 것이 좋습니다. 멀티패싱을 활성화하기 전에 SR을 생성하는 경우, 멀티패싱을 활성화하려면 호스트를 유지 관리 모드로 전환해야 합니다.
-
XenServer 호스트에서 콘솔을 엽니다.
-
다음 명령을 사용하여 호스트의 모든 PBD를 분리하십시오:
xe pbd-unplug uuid=<pbd_uuid> <!--NeedCopy-->xe pbd-list명령을 사용하여 PBD의 UUID를 찾을 수 있습니다. -
다음 명령을 사용하여
multipathing매개변수 값을true로 설정합니다.xe host-param-set uuid=<host uuid> multipathing=true <!--NeedCopy--> -
여러 경로가 있지만 단일 경로 모드로 실행 중인 호스트에 기존 SR이 있는 경우:
-
영향을 받는 SR에 가상 디스크가 있는 실행 중인 게스트를 마이그레이션하거나 일시 중단합니다.
-
멀티패싱을 사용하여 다시 연결하려면 영향을 받는 SR의 PBD를 다시 연결합니다:
xe pbd-plug uuid=<pbd_uuid> <!--NeedCopy-->
-
-
풀의 모든 호스트에서 멀티패싱을 활성화하려면 이 단계를 반복합니다.
풀의 모든 호스트에서 멀티패싱을 활성화해야 합니다. 모든 케이블 연결과 iSCSI의 경우 서브넷 구성은 각 호스트의 해당 NIC와 일치해야 합니다.
자세한 내용은 스토리지 멀티패싱을 참조하십시오.
7. GFS2 저장소 리포지토리 생성
리소스 풀의 모든 XenServer 호스트에 표시되는 iSCSI 또는 HBA LUN에 공유 GFS2 SR을 생성합니다. GFS2와 함께 씬 프로비저닝된 LUN을 사용하는 것은 권장하지 않습니다. 그러나 이 구성을 선택하는 경우, XenServer가 LUN에 쓸 수 있도록 LUN에 항상 충분한 공간이 있는지 확인해야 합니다.
클러스터된 풀에 최대 62개의 GFS2 SR을 추가할 수 있습니다.
이전에 LVM으로 두꺼운 프로비저닝을 위해 블록 기반 스토리지 장치를 사용한 경우, XenServer에서 이를 감지합니다. XenCenter는 기존 LVM 파티션을 사용하거나 디스크를 포맷하고 GFS2 파티션을 설정할 수 있는 기회를 제공합니다.
iSCSI를 통한 공유 GFS2 SR 생성
xe CLI를 사용하여 iSCSI를 통한 GFS2 SR을 생성할 수 있습니다.
GFS2 SR용 장치 구성 매개변수:
| 매개변수 이름 | 상세 내용 | 필수 여부? |
|---|---|---|
provider |
블록 공급자 구현입니다. 이 경우, iscsi. |
예 |
target |
호스팅하는 iSCSI 파일러의 IP 주소 또는 호스트 이름 | 예 |
targetIQN |
SR을 호스팅하는 iSCSI 파일러의 IQN 대상 | 예 |
SCSIid |
장치 스카시 아이디 | 예 |
이러한 매개변수에 사용할 값은 xe sr-probe-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 <!--NeedCopy-->명령의 출력은 추가 매개변수를 제공하도록 요청하고 각 단계에서 가능한 값 목록을 제공합니다.
-
새 매개변수를 추가하면서 명령을 반복합니다.
-
명령 출력이
Found the following complete configurations that can be used to create SRs:으로 시작하면 지정한xe sr-create명령과device-config매개변수를 사용하여 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 생성
xe CLI를 사용하여 HBA SR을 통한 GFS2를 생성할 수 있습니다.
GFS2 SR에 대한 장치 구성 매개변수:
| 매개변수 이름 | 설명 내용 | 필수? |
|---|---|---|
provider |
블록 공급자 구현. 이 경우 hba. |
예 |
SCSIid |
장치 스카시 아이디 | 예 |
xe sr-probe-ext 명령을 사용하여 SCSIid 매개변수에 사용할 값을 찾을 수 있습니다.
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 <!--NeedCopy-->명령의 출력은 추가 매개변수를 제공하도록 요청하고 각 단계에서 가능한 값 목록을 제공합니다.
-
새 매개변수를 추가하면서 명령을 반복합니다.
-
명령 출력이
Found the following complete configurations that can be used to create SRs:으로 시작하면xe sr-create명령과 지정한device-config매개변수를 사용하여 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-->
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 작업에 대한 자세한 내용은 하드웨어 HBA 스토리지를 참조하십시오.
다음 단계는 무엇입니까?
이제 GFS2 환경이 설정되었으므로 쿼럼을 확보하여 클러스터된 풀의 안정성을 유지하는 것이 중요합니다. 자세한 내용은 클러스터된 풀 관리를 참조하십시오.
GFS2 환경에서 문제가 발생하면 클러스터형 풀 문제 해결을 참조하십시오.
다른 SR과 동일한 방식으로 GFS2 SR을 관리할 수 있습니다. 예를 들어, LUN의 크기를 늘리기 위해 스토리지 어레이에 용량을 추가할 수 있습니다. 자세한 내용은 라이브 LUN 확장을 참조하십시오.
제약 조건
공유 GFS2 스토리지는 현재 다음과 같은 제약 조건을 가집니다:
-
GFS2 SR을 사용하는 VM의 경우 Intellicache™는 지원되지 않습니다.
-
다른 씬 프로비저닝된 SR과 마찬가지로, GFS2 SR 사용량이 100%에 도달하면 VM에서 추가 쓰기 작업이 실패합니다. 이러한 실패한 쓰기 작업은 VM 내에서 오류, 데이터 손상 또는 둘 다를 유발할 수 있습니다.
-
SR 사용량이 80%에 도달하면 XenCenter에 경고가 표시됩니다. 이 경고에 대해 GFS2 SR을 모니터링하고 경고가 표시되면 적절한 조치를 취하십시오. GFS2 SR에서 높은 사용량은 성능 저하를 유발합니다. SR 사용량을 80% 미만으로 유지하는 것이 좋습니다.
-
VDI가 GFS2 SR에 있는 VM의 경우 스토리지 마이그레이션(라이브 또는 오프라인)을 통한 VM 마이그레이션은 지원되지 않습니다. 또한 다른 유형의 SR에서 GFS2 SR로 VDI를 마이그레이션할 수 없습니다.
-
소프트웨어 FCoE 전송은 GFS2 SR에서 지원되지 않습니다 (완전히 오프로드된 FCoE의 경우 HBA 사용).
-
Trim/unmap은 GFS2 SR에서 지원되지 않습니다.
-
CHAP는 GFS2 SR에서 지원되지 않습니다.
-
2TiB보다 큰 VDI는 VHD 또는 OVA/OVF로 내보낼 수 없습니다. 그러나 2TiB보다 큰 VDI를 가진 VM은 XVA 형식으로 내보낼 수 있습니다.
-
GFS2와 함께 씬 프로비저닝된 LUN을 사용하는 것은 권장하지 않습니다. 그러나 이 구성을 선택하는 경우, XenServer가 쓸 수 있도록 LUN에 항상 충분한 공간이 있는지 확인해야 합니다.
-
GFS2 SR과 함께 SAN 중복 제거를 사용하는 것은 권장하지 않습니다. 그러나 이 구성을 선택하는 경우, XenServer가 쓸 수 있는 공간이 항상 충분한지 확인하기 위해 SAN 사용량에 대한 적절한 외부 모니터링을 사용해야 합니다.
-
GFS2 파일 시스템은 100TiB보다 클 수 없습니다.
-
풀에 62개 이상의 GFS2 SR을 가질 수 없습니다.
-
클러스터형 풀은 풀당 최대 16개의 호스트만 지원합니다.
-
클러스터형 풀에서 HA를 활성화하려면 하트비트 SR이 GFS2 SR이어야 합니다.
-
클러스터 트래픽의 경우, 최소 두 개의 서로 다른 네트워크 스위치를 사용하는 본딩된 네트워크를 사용하는 것이 좋습니다. 이 네트워크를 다른 용도로 사용하지 마십시오.
-
XenCenter를 사용하여 클러스터 네트워크의 IP 주소를 변경하려면 클러스터링 및 GFS2를 일시적으로 비활성화해야 합니다.
-
클러스터가 활성 상태이고 실행 중인 VM이 있는 동안에는 클러스터 네트워크의 본딩을 변경하지 마십시오. 이 작업은 클러스터의 호스트가 강제로 다시 시작(펜싱)되도록 할 수 있습니다.
-
클러스터 네트워크에서 IP 주소 충돌(여러 호스트가 동일한 IP 주소를 가짐)이 발생하고 클러스터링이 활성화된 호스트가 하나 이상 포함된 경우, 클러스터가 올바르게 형성되지 않으며 호스트가 필요할 때 펜싱할 수 없습니다. 이 문제를 해결하려면 IP 주소 충돌을 해결하십시오.