Astra Trident 통합
Astra Trident를 통합하려면 다음과 같은 설계 및 아키텍처 요소를 통합해야 합니다. 드라이버 선택 및 배포, 스토리지 클래스 설계, 가상 스토리지 풀 설계, PVC(Persistent Volume Claim)는 Astra Trident를 사용한 스토리지 프로비저닝, 볼륨 운영, OpenShift 서비스 구축에 영향을 줍니다.
운전자 선택 및 전개
ONTAP용 백엔드 드라이버를 선택합니다
ONTAP 시스템에는 4개의 서로 다른 백엔드 드라이버를 사용할 수 있습니다. 이러한 드라이버는 사용 중인 프로토콜과 스토리지 시스템에서 볼륨을 프로비저닝하는 방법에 따라 다릅니다. 따라서 어떤 드라이버를 배포할지 신중하게 고려해야 합니다.
상위 레벨에서는 애플리케이션에 공유 스토리지가 필요한 구성 요소(동일한 PVC에 액세스하는 여러 Pod)가 있는 경우 NAS 기반 드라이버가 기본 선택이고 블록 기반 iSCSI 드라이버는 비공유 스토리지의 요구를 충족합니다. 애플리케이션의 요구사항 및 스토리지 및 인프라 팀의 편안함 수준을 기준으로 프로토콜을 선택합니다. 일반적으로 대부분의 애플리케이션에서 두 서버 간에 차이가 거의 없기 때문에 공유 스토리지(둘 이상의 POD에 동시 액세스가 필요한 경우)가 필요한지 여부에 따라 결정하는 경우가 많습니다.
ONTAP 백 엔드에 대한 5개의 드라이버가 아래에 나열되어 있습니다.
-
ONTAP-NAS: 프로비저닝되는 각 PV는 ONTAP FlexVolume입니다.
-
ONTAP-NAS-이코노미: 각 PV 프로비저닝은 qtree이며 FlexVolume당 qtree(기본값 200)를 구성할 수 있습니다.
-
ONTAP-NAS-flexgroup: 각 PV는 전체 ONTAP FlexGroup로 프로비저닝되고 SVM에 할당된 모든 애그리게이트가 사용됩니다.
-
ONTAP-SAN: 각 PV는 자체 FlexVolume 내의 LUN입니다.
-
ONTAP-SAN-이코노미: 각 PV는 LUN으로 프로비저닝되며 FlexVolume당 구성 가능한 LUN 수(기본값 100)가 있습니다.
세 개의 NAS 드라이버 중 하나를 선택할 경우 해당 기능에 약간의 영향을 줍니다. 이 기능은 응용 프로그램에서 사용할 수 있습니다.
아래 표에서 모든 기능이 Astra Trident를 통해 표시되는 것은 아닙니다. 용량 할당 후 기능을 적용하려면 스토리지 관리자가 일부 기능을 적용해야 합니다. 위 첨자 각주는 기능 및 드라이버별 기능을 구별합니다.
ONTAP NAS 드라이버 | 스냅샷 수 | 복제 | 동적 엑스포트 정책 | 다중 연결 | QoS를 참조하십시오 | 크기 조정 | 복제 |
---|---|---|---|---|---|---|---|
'ONTAP-NAS' |
예 |
예 |
Yesfootnote: 5[] |
예 |
Yesfootnote: 1[] |
예 |
Yesfootnote: 1[] |
ONTAP-NAS-이코노미 |
Yesfootnote: 3[] |
Yesfootnote: 3[] |
Yesfootnote: 5[] |
예 |
Yesfootnote: 3[] |
예 |
Yesfootnote: 3[] |
'ONTAP-NAS-Flexgroup' |
Yesfootnote: 1[] |
아니요 |
Yesfootnote: 5[] |
예 |
Yesfootnote: 1[] |
예 |
Yesfootnote: 1[] |
Astra Trident는 ONTAP용 SAN 드라이버 2개를 제공하며 해당 기능은 아래에 나와 있습니다.
ONTAP SAN 드라이버 | 스냅샷 수 | 복제 | 다중 연결 | 양방향 CHAP | QoS를 참조하십시오 | 크기 조정 | 복제 |
---|---|---|---|---|---|---|---|
'ONTAP-SAN' |
예 |
예 |
Yesfootnote: 4[] |
예 |
Yesfootnote: 1[] |
예 |
Yesfootnote: 1[] |
ONTAP-SAN-이코노미 |
예 |
예 |
Yesfootnote: 4[] |
예 |
Yesfootnote: 3[] |
Yesfootnote: 1[] |
Yesfootnote: 3[] |
위 표의 각주: Yes[1]: Astra Trident에서 관리하지 않음 Yes[2]: Astra Trident에서 관리하지만 PV 세분화되지는 않음 Yes[3]: Astra Trident에서 관리하지 않음, PV 세분화됨 Yes[4]: 원시 블록 볼륨에서 지원됨 Yes[5]: CSI Trident에서 지원
PV 세분화되지 않은 기능은 전체 FlexVolume에 적용되고 모든 PVS(즉, 공유 FlexVol의 qtree 또는 LUN)는 공통 스케줄을 공유합니다.
위 표에서 볼 수 있듯이, ONTAP-NAS와 ONTAP-NAS-이코노미 간의 기능 대부분은 동일합니다. 그러나 ONTAP-NAS-이코노미 드라이버는 PV 단위의 일정 제어 기능을 제한하므로 특히 재해 복구 및 백업 계획에 영향을 줄 수 있습니다. ONTAP 스토리지에서 PVC 클론 기능을 활용하고자 하는 개발팀은 ONTAP-NAS, ONTAP-SAN 또는 ONTAP-SAN 절약 드라이버를 사용할 때만 가능합니다.
|
졸idfire-san의 드라이버도 PVC를 클로닝할 수 있습니다. |
Cloud Volumes ONTAP용 백엔드 드라이버를 선택합니다
Cloud Volumes ONTAP은 NAS 및 SAN 프로토콜(NFS, SMB/CIFS 및 iSCSI)을 지원하는 파일 공유 및 블록 레벨 스토리지 등 다양한 활용 사례에 맞게 엔터프라이즈급 스토리지 기능과 함께 데이터 제어를 제공합니다. Cloud Volume ONTAP와 호환되는 드라이버는 ONTAP-NAS, ONTAP-NAS-이코노미, ONTAP-SAN, ONTAP-SAN 경제입니다. Cloud Volume ONTAP for AWS, Cloud Volume ONTAP for Azure, Cloud Volume ONTAP for GCP에 적용할 수 있습니다.
ONTAP용 Amazon FSx의 백엔드 드라이버를 선택합니다
ONTAP용 Amazon FSx를 사용하면 고객이 익숙한 NetApp 기능, 성능 및 관리 기능을 활용하는 동시에, AWS에 데이터를 저장하는 간편성, 민첩성, 보안, 확장성을 활용할 수 있습니다. ONTAP용 FSX는 ONTAP의 다양한 파일 시스템 기능과 관리 API를 지원합니다. Cloud Volume ONTAP와 호환되는 드라이버는 ONTAP-NAS, ONTAP-NAS-이코노미, ONTAP-NAS-Flexgroup, ONTAP-SAN, ONTAP-SAN입니다.
NetApp HCI/SolidFire의 백엔드 드라이버를 선택합니다
NetApp HCI/SolidFire 플랫폼과 함께 사용되는 'olidfire-SAN' 드라이버는 관리자가 QoS 제한을 기반으로 Trident에 대한 Element 백엔드를 구성하는 데 도움이 됩니다. Trident에서 프로비저닝한 볼륨에 대한 특정 QoS 제한을 설정하기 위해 백엔드를 설계하려면 백엔드 파일에 'type' 매개 변수를 사용하십시오. 또한 관리자는 'limitVolumeSize' 매개 변수를 사용하여 스토리지에 생성할 수 있는 볼륨 크기를 제한할 수 있습니다. 현재 볼륨 크기 조정 및 볼륨 복제와 같은 Element 스토리지 기능은 'olidfire-SAN' 드라이버를 통해 지원되지 않습니다. 이러한 작업은 Element 소프트웨어 웹 UI를 통해 수동으로 수행해야 합니다.
SolidFire 드라이버 | 스냅샷 수 | 복제 | 다중 연결 | CHAP | QoS를 참조하십시오 | 크기 조정 | 복제 |
---|---|---|---|---|---|---|---|
'솔더불-산' |
예 |
예 |
Yes[2] |
예 |
예 |
예 |
Yesfootnote: 1[] |
각주: Yesfootnote: 1 [ ]: Astra Trident Yesfootnote: 2 [ ]: 원시 블록 볼륨에서 지원됩니다
Azure NetApp Files용 백엔드 드라이버를 선택합니다
Astra Trident는 'Azure-NetApp-files' 드라이버를 사용하여 를 관리합니다 "Azure NetApp Files" 서비스.
이 드라이버 및 구성 방법에 대한 자세한 내용은 에서 찾을 수 있습니다 "Azure NetApp Files를 위한 Astra Trident 백엔드 구성입니다".
Azure NetApp Files 드라이버 | 스냅샷 수 | 복제 | 다중 연결 | QoS를 참조하십시오 | 비즈니스 | 복제 |
---|---|---|---|---|---|---|
'Azure-NetApp-파일' |
예 |
예 |
예 |
예 |
예 |
Yesfootnote: 1[] |
각주: Yesfootnote: 1 [ ]: Astra Trident에서 관리하지 않습니다
Cloud Volumes Service with AWS의 백엔드 드라이버를 선택합니다
Astra Trident는 AWS-CVS 드라이버를 사용하여 AWS 백엔드의 Cloud Volumes Service와 연결합니다. Trident에서 AWS 백엔드를 구성하려면 백엔드 파일에 apiRegion, apiURL, apiKey, s ecretKey를 지정해야 합니다. 이러한 값은 CVS 웹 포털의 계정 설정/API 액세스에서 확인할 수 있습니다. 지원되는 서비스 수준은 CVS에 맞춰 조정되며 '표준', '프리미엄', '익스트림'도 포함됩니다. 현재 100G는 프로비저닝할 최소 볼륨 크기입니다. CVS의 향후 릴리스에서는 이 제한이 적용되지 않을 수 있습니다.
AWS 드라이버에 대한 CV | 스냅샷 수 | 복제 | 다중 연결 | QoS를 참조하십시오 | 비즈니스 | 복제 |
---|---|---|---|---|---|---|
'AWS-CV' |
예 |
예 |
예 |
예 |
예 |
Yesfootnote: 1[] |
각주: Yesfootnote: 1 [ ]: Astra Trident에서 관리하지 않습니다
AWS-CV 드라이버는 가상 스토리지 풀을 사용합니다. 가상 스토리지 풀은 백엔드를 추상화하여 Trident가 볼륨 배치를 결정할 수 있도록 합니다. 관리자는 backend.json 파일에 있는 가상 스토리지 풀을 정의합니다. 스토리지 클래스는 레이블을 사용하여 가상 스토리지 풀을 식별합니다.
Cloud Volumes Service with GCP의 백엔드 드라이버를 선택합니다
Astra Trident는 GCP-cvs 드라이버를 사용하여 GCP 백엔드의 Cloud Volumes Service와 연결합니다. Trident에서 GCP 백엔드를 구성하려면 백엔드 파일에 projectNumber, apiRegion 및 apiKey를 지정해야 합니다. GCP 웹 포털에서 프로젝트 번호를 확인할 수 있으며, GCP에서 Cloud Volumes에 대한 API 액세스를 설정하는 동안 생성한 서비스 계정 프라이빗 키 파일에서 API 키를 가져와야 합니다. Astra Trident는 두 가지 중 하나로 CVS 볼륨을 생성할 수 있습니다 "서비스 유형":
-
* CVS *: 기본 CVS 서비스 유형으로, 제한된/중간 수준의 성능으로 높은 조널 가용성을 제공합니다.
-
* CVS - 성능 *: 성능이 중요한 운영 워크로드에 가장 적합한 성능 최적화 서비스 유형입니다. 세 가지 서비스 수준('Standard', 'Premium', 'Extreme')을 선택할 수 있습니다. 현재 100GiB는 프로비저닝할 최소 CVS 성능 볼륨 크기이고 CVS 볼륨은 300GiB 이상이어야 합니다. CVS의 향후 릴리스에서는 이 제한이 적용되지 않을 수 있습니다.
|
기본 CVS 서비스 유형 ['storageClass=software']를 사용하여 백엔드를 배포할 때 사용자 * 는 해당 프로젝트 번호 및 프로젝트 ID에 대해 GCP의 1TiB 미만의 볼륨 기능에 대한 액세스 * 를 얻어야 합니다. Trident에서 1TiB 미만의 볼륨을 프로비저닝하는 데 이 작업이 필요합니다. 그렇지 않은 경우, 600GiB 미만의 PVC에 대해 체적 생성 * 이 실패합니다. 사용 "이 양식입니다" 1TiB 미만의 볼륨에 대한 액세스 권한 얻기 |
GCP 드라이버에 대한 CVS | 스냅샷 수 | 복제 | 다중 연결 | QoS를 참조하십시오 | 비즈니스 | 복제 |
---|---|---|---|---|---|---|
GCP-CV |
예 |
예 |
예 |
예 |
예 |
Yesfootnote: 1[] |
각주: Yesfootnote: 1 [ ]: Astra Trident에서 관리하지 않습니다
GCP-CV 드라이버는 가상 스토리지 풀을 사용합니다. 가상 스토리지 풀은 백엔드를 추상화하여 Astra Trident가 볼륨 배치를 결정할 수 있도록 합니다. 관리자는 backend.json 파일에 있는 가상 스토리지 풀을 정의합니다. 스토리지 클래스는 레이블을 사용하여 가상 스토리지 풀을 식별합니다.
스토리지 클래스 설계
Kubernetes Storage Class 객체를 생성하려면 개별 스토리지 클래스를 구성 및 적용해야 합니다. 이 섹션에서는 애플리케이션에 대한 스토리지 클래스를 설계하는 방법에 대해 설명합니다.
특정 백엔드 사용률을 위한 스토리지 클래스 설계
특정 스토리지 클래스 객체 내에서 필터링을 사용하여 해당 스토리지 클래스에 사용할 스토리지 풀 또는 풀 세트를 결정할 수 있습니다. Storage Class에서 'toragePools', 'additionalStoragePools', 'excludeStoragePools' 등의 세 가지 필터를 설정할 수 있습니다.
'toragePools' 매개 변수는 지정된 속성과 일치하는 풀 세트로 스토리지를 제한하는 데 도움이 됩니다. 추가 StoragePools 매개변수는 Astra Trident가 프로비저닝에 사용할 풀 세트를 속성 및 'toragePools' 매개 변수로 선택한 풀 세트와 함께 확장하는 데 사용됩니다. 매개 변수만 사용하거나 둘 모두를 함께 사용하여 적절한 스토리지 풀 세트가 선택되었는지 확인할 수 있습니다.
excludeStoragePools 매개 변수는 속성과 일치하는 나열된 풀 세트를 명시적으로 제외하는 데 사용됩니다.
QoS 정책을 에뮬레이트하기 위한 스토리지 클래스 설계
서비스 품질 정책을 에뮬레이트하기 위해 스토리지 클래스를 설계하려면 '미디어' 속성을 HDD 또는 'SSD'로 사용하여 스토리지 클래스를 생성합니다. 스토리지 클래스에 언급된 미디어 특성에 따라, Trident는 미디어 속성과 일치하도록 HDD 또는 SSD 애그리게이트를 제공하는 적절한 백엔드를 선택한 다음 볼륨 프로비저닝을 특정 애그리게이트로 전달합니다. 따라서 프리미엄 QoS 정책으로 분류될 수 있는 '미디어' 속성이 'SD'로 설정된 스토리지 클래스 Premium을 생성할 수 있습니다. 표준 QoS 정책으로 분류될 수 있는 미디어 속성을 'HDD'로 설정하는 또 다른 스토리지 클래스 표준을 생성할 수 있습니다. 또한 스토리지 클래스에서 ""IOPS"" 속성을 사용하여 QoS 정책으로 정의할 수 있는 Element 어플라이언스로 프로비저닝을 리디렉션할 수도 있습니다.
특정 기능을 기반으로 백엔드를 활용하는 스토리지 클래스 설계
스토리지 클래스는 씬 및 일반 프로비저닝, 스냅샷, 클론 및 암호화와 같은 기능이 설정된 특정 백엔드에서 볼륨 프로비저닝을 수행하도록 설계되었습니다. 사용할 스토리지를 지정하려면 필요한 기능이 설정된 적절한 백엔드를 지정하는 스토리지 클래스를 생성합니다.
가상 스토리지 풀을 위한 스토리지급 설계
모든 Astra Trident 백엔드에 가상 스토리지 풀을 사용할 수 있습니다. Astra Trident가 제공하는 드라이버를 사용하여 백엔드에 대한 가상 스토리지 풀을 정의할 수 있습니다.
가상 스토리지 풀을 사용하면 관리자가 저장소 클래스를 통해 참조할 수 있는 백엔드에 대한 추상화 수준을 생성할 수 있으므로 백엔드에 볼륨을 보다 유연하고 효율적으로 배치할 수 있습니다. 동일한 서비스 클래스로 다른 백엔드를 정의할 수 있습니다. 또한 동일한 백엔드에서 여러 스토리지 풀을 생성할 수 있지만 특성이 다릅니다. 특정 레이블이 있는 선택기로 스토리지 클래스를 구성한 경우 Astra Trident는 볼륨을 배치할 모든 선택기 레이블과 일치하는 백엔드를 선택합니다. 스토리지 클래스 선택기 레이블이 여러 스토리지 풀과 일치하면 Astra Trident가 볼륨 용량을 할당할 스토리지 풀 중 하나를 선택합니다.
가상 스토리지 풀 설계
백엔드를 생성하는 동안 일반적으로 매개 변수 집합을 지정할 수 있습니다. 관리자가 동일한 스토리지 자격 증명을 사용하여 다른 매개 변수 집합을 가진 다른 백엔드를 생성할 수 없었습니다. 가상 스토리지 풀의 도입으로 이 문제가 완화되었습니다. 가상 스토리지 풀은 백엔드 및 Kubernetes 스토리지 클래스 간에 도입된 레벨 추상화입니다. 따라서 관리자는 Kubernetes 스토리지 클래스를 통해 백엔드에 독립적인 방식으로 Selector로 참조할 수 있는 레이블과 함께 매개 변수를 정의할 수 있습니다. Astra Trident를 사용하여 지원되는 모든 NetApp 백엔드에 대해 가상 스토리지 풀을 정의할 수 있습니다. 해당 목록에는 SolidFire/NetApp HCI, ONTAP, Cloud Volumes Service on AWS, GCP 및 Azure NetApp Files가 포함됩니다.
|
가상 스토리지 풀을 정의할 때는 백엔드 정의에서 기존 가상 풀의 순서를 재정렬하지 않는 것이 좋습니다. 또한 기존 가상 풀의 속성을 편집/수정하고 대신 새 가상 풀을 정의하는 것이 좋습니다. |
다양한 서비스 수준/QoS를 에뮬레이트할 수 있도록 가상 스토리지 풀을 설계합니다
서비스 클래스를 에뮬레이트하기 위해 가상 스토리지 풀을 설계할 수 있습니다. Cloud Volume Service for AWS를 위한 가상 풀 구축을 사용하여 다양한 서비스 클래스를 설정하는 방법을 살펴봅시다. 다양한 성능 수준을 나타내는 여러 레이블을 사용하여 AWS-CVS 백엔드를 구성합니다. '레벨 11'을 적절한 성과 수준으로 설정하고 각 레이블 아래에 다른 필수 요소를 추가합니다. 이제 다른 가상 스토리지 풀에 매핑할 다른 Kubernetes 스토리지 클래스를 생성합니다. parameters.selector` 필드를 사용하여 각 StorageClass는 볼륨을 호스팅하는 데 사용할 수 있는 가상 풀을 호출합니다.
특정 측면을 할당할 수 있도록 가상 풀을 설계합니다
특정 측면의 여러 가상 스토리지 풀을 단일 스토리지 백엔드에서 설계할 수 있습니다. 이를 위해 백엔드에 여러 레이블을 구성하고 각 레이블 아래에 필요한 측면을 설정합니다. 이제 다른 가상 스토리지 풀에 매핑될 ' parameters.selector` ' 필드를 사용하여 다른 Kubernetes 스토리지 클래스를 만들 수 있습니다. 백엔드에서 프로비저닝되는 볼륨에는 선택한 가상 스토리지 풀에 정의된 측면이 있습니다.
스토리지 프로비저닝에 영향을 미치는 PVC 특성
요청된 스토리지 클래스 이외의 일부 매개 변수는 PVC를 생성할 때 Astra Trident의 프로비저닝 결정 프로세스에 영향을 줄 수 있습니다.
액세스 모드
PVC를 통한 저장 요청 시 필수 필드 중 하나가 액세스 모드입니다. 원하는 모드는 스토리지 요청을 호스팅하기 위해 선택한 백엔드에 영향을 줄 수 있습니다.
Astra Trident는 다음 매트릭스에 따라 지정된 액세스 방법과 사용된 스토리지 프로토콜을 일치시키려고 시도합니다. 이는 기본 스토리지 플랫폼과 무관합니다.
ReadWriteOnce 를 참조하십시오 | ReadOnlyMany 를 참조하십시오 | ReadWriteMany 를 참조하십시오 | |
---|---|---|---|
iSCSI |
예 |
예 |
예(원시 블록) |
NFS 를 참조하십시오 |
예 |
예 |
예 |
NFS 백엔드가 구성되지 않은 상태로 Trident 배포에 제출된 ReadWriteMany PVC에 대한 요청은 볼륨이 프로비저닝되지 않습니다. 이러한 이유로 요청자는 자신의 응용 프로그램에 적합한 액세스 모드를 사용해야 합니다.
볼륨 작업입니다
영구 볼륨 수정
영구 볼륨은 Kubernetes에서 두 가지 예외, 영구적 객체입니다. 생성된 후에는 부가세 반환 청구액 정책 및 크기를 수정할 수 있습니다. 그러나 이렇게 해서 Kubernetes 외부에서 볼륨의 일부 측면이 수정되지 않도록 할 수는 없습니다. 특정 애플리케이션에 맞게 볼륨을 사용자 지정하거나, 실수로 용량이 소비되지 않도록 하거나, 어떠한 이유로든 볼륨을 다른 스토리지 컨트롤러로 이동하는 것이 좋을 수 있습니다.
|
현재 Kubernetes 트리 프로비저닝 시 NFS 또는 iSCSI PVS의 볼륨 크기 조정 작업은 지원되지 않습니다. Astra Trident는 NFS 및 iSCSI 볼륨 확장을 지원합니다. |
PV의 접속 세부 정보는 생성 후 수정할 수 없습니다.
주문형 볼륨 스냅샷을 생성합니다
Astra Trident는 CSI 프레임워크를 사용하여 필요 시 볼륨 스냅샷 생성 및 스냅샷에서 PVC 생성을 지원합니다. 스냅샷은 편리한 데이터 시점 복사본을 유지 관리하는 방법을 제공하며 Kubernetes의 소스 PV와 독립적인 라이프사이클을 갖고 있습니다. 이러한 스냅샷을 사용하여 PVC를 복제할 수 있습니다.
스냅샷으로부터 볼륨을 생성합니다
Astra Trident는 볼륨 스냅샷으로부터 PersistentVolumes 생성을 지원합니다. 이를 위해 PersistentVolumeClaim을 생성하고 볼륨을 생성해야 하는 필수 스냅샷으로 "소스"를 언급하기만 하면 됩니다. Astra Trident는 스냅샷에 데이터가 있는 볼륨을 생성하여 이 PVC를 처리합니다. 이 기능을 사용하면 지역 간에 데이터를 복제하거나 테스트 환경을 생성하거나 손상되거나 손상된 운영 볼륨을 전체적으로 교체하거나 특정 파일 및 디렉토리를 검색하여 연결된 다른 볼륨으로 전송할 수 있습니다.
클러스터에서 볼륨 이동
스토리지 관리자는 ONTAP 클러스터의 Aggregate와 컨트롤러 간에 볼륨을 스토리지 소비자로 중단 없이 이동할 수 있습니다. 대상 애그리게이트는 Astra Trident가 사용하는 SVM이 액세스할 수 있는 경우, 이 작업은 Astra Trident 또는 Kubernetes 클러스터에 영향을 주지 않습니다. 여기서 중요한 점은 애그리게이트를 SVM에 새로 추가한 경우, Astra Trident에 다시 추가하여 백엔드를 새로 고쳐야 한다는 것입니다. 그러면 Astra Trident가 SVM의 인벤토리를 다시 만들어 새 애그리게이트를 인식할 수 있습니다.
그러나 Astra Trident는 백엔드에서 볼륨을 이동하는 기능을 자동으로 지원하지 않습니다. 여기에는 동일한 클러스터, 클러스터 간 또는 다른 스토리지 플랫폼(스토리지 시스템이 Astra Trident에 연결된 SVM인 경우에도 해당 스토리지 플랫폼)에 있는 SVM이 포함됩니다.
볼륨이 다른 위치에 복사되면 볼륨 가져오기 기능을 사용하여 현재 볼륨을 Astra Trident로 가져올 수 있습니다.
볼륨 확장
Astra Trident는 NFS 및 iSCSI PVS 크기를 조정할 수 있도록 지원합니다. 따라서 사용자는 Kubernetes 계층을 통해 직접 볼륨의 크기를 조정할 수 있습니다. ONTAP, SolidFire/NetApp HCI 및 Cloud Volumes Service 백엔드를 포함한 모든 주요 NetApp 스토리지 플랫폼에서 볼륨 확장이 가능합니다. 나중에 확장을 허용하려면 볼륨과 연관된 StorageClass에서 allowVolumeExpansion을 true로 설정합니다. 영구 볼륨의 크기를 조정해야 할 때마다 영구 볼륨 클레임의 'pec.resources.requests.storage' 주석을 필요한 볼륨 크기로 편집합니다. Trident는 스토리지 클러스터의 볼륨 크기를 자동으로 조정합니다.
기존 볼륨을 Kubernetes로 임포트
볼륨 가져오기를 사용하면 기존 스토리지 볼륨을 Kubernetes 환경으로 가져올 수 있습니다. 이는 현재 ONTAP-NAS, ONTAP-NAS-flexgroup, solidfire-san, Azure-NetApp-files, AWS-CV가 지원하고 있습니다. 그리고 “GCP-CV”의 드라이버도 있습니다. 이 기능은 기존 애플리케이션을 Kubernetes로 포팅하거나 재해 복구 시나리오에서 유용합니다.
ONTAP 및 'solidfire-san' 드라이버를 사용하는 경우, 'tridentctl import volume <backend-name><volume-name> -f/path/PVC.YAML' 명령을 사용하여 Astra Trident에서 관리할 기존 볼륨을 Kubernetes로 가져옵니다. 볼륨 가져오기 명령에 사용되는 PVC YAML 또는 JSON 파일은 Astra Trident를 프로비저닝자로 식별하는 스토리지 클래스를 가리킵니다. NetApp HCI/SolidFire 백엔드를 사용할 경우 볼륨 이름이 고유한지 확인합니다. 볼륨 이름이 중복되면 볼륨을 고유한 이름으로 복제하여 볼륨 가져오기 기능에서 볼륨 이름을 구분할 수 있도록 합니다.
'AWS-CV', 'Azure-NetApp-files' 또는 'GCP-CV' 드라이버를 사용하는 경우, 'tridentctl import volume <backend-name><volume path> -f/path/PVC.YAML' 명령을 사용하여 Astra Trident에서 관리할 Kubernetes로 볼륨을 가져오십시오. 이렇게 하면 고유한 볼륨 참조가 보장됩니다.
위 명령을 실행하면 Astra Trident가 백엔드에서 볼륨을 찾고 해당 크기를 읽습니다. 구성된 PVC의 볼륨 크기를 자동으로 추가(필요한 경우 덮어쓰기)합니다. 그런 다음 Astra Trident가 새로운 PV를 생성하고 Kubernetes가 PVC를 PV에 결합합니다.
특정 가져온 PVC가 필요한 컨테이너를 배포한 경우 PVC/PV 쌍이 볼륨 가져오기 프로세스를 통해 바인딩될 때까지 보류 상태로 유지됩니다. PVC/PV 쌍이 바인딩되면 다른 문제가 없는 한 컨테이너가 나타나야 합니다.
OpenShift 서비스를 배포합니다
OpenShift 부가 가치 클러스터 서비스는 클러스터 관리자와 호스팅 중인 애플리케이션에 중요한 기능을 제공합니다. 이러한 서비스가 사용되는 스토리지는 노드 로컬 리소스를 사용하여 프로비저닝할 수 있지만, 이로 인해 서비스의 용량, 성능, 복구 가능성 및 지속 가능성이 제한되기도 합니다. 엔터프라이즈 스토리지 어레이를 활용하여 이러한 서비스에 필요한 용량을 제공하면 서비스를 대폭 향상시킬 수 있습니다. 그러나 모든 애플리케이션과 마찬가지로 OpenShift와 스토리지 관리자는 긴밀하게 협력하여 각 애플리케이션에 가장 적합한 옵션을 결정해야 합니다. Red Hat 문서는 요구 사항을 결정하고 사이징 및 성능 요구 사항을 충족할 수 있도록 적극 활용해야 합니다.
레지스트리 서비스
레지스트리의 스토리지 배포 및 관리는 에 설명되어 있습니다 "NetApp.IO를 참조하십시오" 에 있습니다 "블로그".
로깅 서비스
다른 OpenShift 서비스와 마찬가지로 로깅 서비스는 Ansible을 사용하여 인벤토리 파일에서 제공하는 구성 매개 변수로 배포됩니다 호스트가 플레이북에 제공됩니다. OpenShift를 설치한 후 초기 OpenShift 설치 중에 로깅을 배포하고 로깅을 배포하는 두 가지 설치 방법이 제공됩니다.
|
Red Hat OpenShift 버전 3.9를 기준으로 공식 문서는 데이터 손상 관련 우려 때문에 로깅 서비스에 NFS를 사용할 것을 권장합니다. 이는 제품에 대한 Red Hat 테스트를 기반으로 합니다. ONTAP의 NFS 서버에는 이러한 문제가 없으며 로깅 구축을 쉽게 되돌릴 수 있습니다. 궁극적으로, 로깅 서비스를 위한 프로토콜을 선택할 수 있습니다. 두 가지 모두 NetApp 플랫폼을 사용할 때 효과가 있으며 원할 경우 NFS를 피할 이유가 없습니다. |
로깅 서비스에서 NFS를 사용하도록 선택한 경우 설치 관리자의 실패를 방지하려면 Ansible 변수 "openshift_enable_unsupported_configurations"를 "true"로 설정해야 합니다.
시작하십시오
로깅 서비스는 필요에 따라 두 애플리케이션 및 OpenShift 클러스터 자체의 핵심 운영에 구축할 수 있습니다. 작업 로깅을 배포하려는 경우 변수 "openshift_logging_use_ops"를 "true"로 지정하면 서비스의 인스턴스 두 개가 만들어집니다. 작업에 대한 로깅 인스턴스를 제어하는 변수에는 "ops"가 포함되어 있지만 응용 프로그램의 인스턴스는 그렇지 않습니다.
기본 서비스에서 올바른 스토리지를 활용할 수 있도록 구축 방법에 따라 Ansible 변수를 구성하는 것이 중요합니다. 각 배포 방법에 대한 옵션을 살펴보겠습니다.
|
아래 표에는 로깅 서비스와 관련된 스토리지 구성과 관련된 변수만 포함되어 있습니다. 에서 다른 옵션을 찾을 수 있습니다 "RedHat OpenShift 로깅 설명서" 배포 내용에 따라 검토, 구성 및 사용해야 합니다. |
아래 표의 변수는 제공된 세부 정보를 사용하여 로깅 서비스에 대한 PV 및 PVC를 생성하는 Ansible 플레이북을 만듭니다. 이 방법은 OpenShift 설치 후 구성 요소 설치 플레이북을 사용하는 것보다 훨씬 덜 유연하지만, 기존 볼륨을 사용할 수 있는 경우 옵션으로 제공됩니다.
변수 | 세부 정보 |
---|---|
"openshift_logging_storage_kind" |
설치 프로그램이 로깅 서비스에 대한 NFS PV를 생성하도록 'NFS'로 설정합니다. |
"openshift_logging_storage_host"를 선택합니다 |
NFS 호스트의 호스트 이름 또는 IP 주소입니다. 이 경우 가상 머신의 데이터 LIF로 설정해야 합니다. |
'openshift_logging_storage_nfs_directory |
NFS 내보내기의 마운트 경로입니다. 예를 들어 볼륨이 '/openshift_logging'으로 가정되는 경우 이 변수에 해당 경로를 사용합니다. |
'openshift_logging_storage_volume_name' |
생성할 PV의 이름(예: PV_ose_logs)입니다. |
"openshift_logging_storage_volume_size" |
NFS 내보내기의 크기(예: 100Gi)입니다. |
OpenShift 클러스터가 이미 실행 중이고 Trident가 배포 및 구성된 경우 설치 관리자는 동적 프로비저닝을 사용하여 볼륨을 생성할 수 있습니다. 다음 변수를 구성해야 합니다.
변수 | 세부 정보 |
---|---|
"openshift_logging_es_pvc_dynamic" |
동적으로 프로비저닝된 볼륨을 사용하려면 true로 설정합니다. |
'openshift_logging_es_pvc_storage_class_name' |
PVC에 사용될 스토리지 클래스의 이름입니다. |
"openshift_logging_es_pvc_size"를 선택합니다 |
PVC에서 요청된 체적의 크기입니다. |
"openshift_logging_es_pvc_prefix" |
로깅 서비스에서 사용하는 PVC의 접두사입니다. |
"openshift_logging_es_ops_pvc_dynamic" |
작업 로깅 인스턴스에 동적으로 프로비저닝된 볼륨을 사용하려면 "true"로 설정합니다. |
'openshift_logging_es_ops_pvc_storage_class_name' |
작업 로깅 인스턴스에 대한 스토리지 클래스의 이름입니다. |
"openshift_logging_es_ops_pvc_size"를 선택합니다 |
작업 인스턴스에 대한 볼륨 요청의 크기입니다. |
"openshift_logging_es_ops_pvc_prefix" |
ops instance PVCs(ops 인스턴스 PVC)의 접두사입니다. |
로깅 스택을 배포합니다
초기 OpenShift 설치 프로세스의 일부로 로깅을 배포하는 경우 표준 배포 프로세스만 따르면 됩니다. Ansible이 완료되는 즉시 서비스를 이용할 수 있도록 필요한 서비스와 OpenShift 개체를 구성 및 배포합니다.
하지만 초기 설치 후에 구축할 경우 구성 요소 플레이북을 Ansible에서 사용해야 합니다. 이 프로세스는 다른 버전의 OpenShift에서 약간 변경될 수 있으므로 반드시 읽고 따라야 합니다 "RedHat OpenShift Container Platform 3.11 설명서" 를 참조하십시오.
메트릭 서비스
메트릭 서비스는 관리자에게 OpenShift 클러스터의 상태, 리소스 활용도 및 가용성에 대한 중요한 정보를 제공합니다. 또한 POD 자동 크기 조정 기능도 필요하며, 많은 조직에서 비용 청구 및/또는 애플리케이션 표시를 위해 메트릭 서비스의 데이터를 사용합니다.
로깅 서비스 및 OpenShift와 마찬가지로 Ansible을 사용하여 메트릭 서비스를 배포합니다. 또한 로깅 서비스와 마찬가지로 메트릭 서비스는 클러스터의 초기 설정 중에 또는 구성 요소 설치 방법을 사용하여 작동 후에 배포될 수 있습니다. 다음 표에는 메트릭 서비스에 대한 영구 스토리지를 구성할 때 중요한 변수가 나와 있습니다.
|
아래 표에는 메트릭 서비스와 관련된 스토리지 구성과 관련된 변수만 포함되어 있습니다. 문서에 나와 있는 다른 많은 옵션은 배포 내용에 따라 검토, 구성 및 사용해야 합니다. |
변수 | 세부 정보 |
---|---|
"openshift_metrics_storage_kind" |
설치 프로그램이 로깅 서비스에 대한 NFS PV를 생성하도록 'NFS'로 설정합니다. |
'openshift_metrics_storage_host |
NFS 호스트의 호스트 이름 또는 IP 주소입니다. SVM을 위한 데이터 LIF로 설정해야 합니다. |
'openshift_metrics_storage_nfs_directory |
NFS 내보내기의 마운트 경로입니다. 예를 들어, 볼륨이 '/openshift_metrics'로 가정되는 경우 이 변수에 해당 경로를 사용합니다. |
'openshift_metrics_storage_volume_name' |
생성할 PV의 이름(예: PV_ose_metrics). |
'openshift_metrics_storage_volume_size |
NFS 내보내기의 크기(예: 100Gi)입니다. |
OpenShift 클러스터가 이미 실행 중이고 Trident가 배포 및 구성된 경우 설치 관리자는 동적 프로비저닝을 사용하여 볼륨을 생성할 수 있습니다. 다음 변수를 구성해야 합니다.
변수 | 세부 정보 |
---|---|
'openshift_metrics_cassandra_pvc_prefix' |
지표 PVC에 사용할 접두사입니다. |
'openshift_metrics_cassandra_pvc_size |
요청할 볼륨의 크기입니다. |
'openshift_metrics_cassandra_storage_type' |
메트릭에 사용할 스토리지 유형으로, 적절한 스토리지 클래스로 PVC를 생성하려면 Ansible에서 이를 동적 으로 설정해야 합니다. |
'openshift_metrics_cassanda_pvc_storage_class_name' |
사용할 스토리지 클래스의 이름입니다. |
메트릭 서비스를 구축합니다
호스트/인벤토리 파일에 정의된 적절한 Ansible 변수를 사용하여 서비스를 구축하십시오. OpenShift 설치 시 배포하는 경우 PV가 자동으로 생성되고 사용됩니다. OpenShift를 설치한 후 구성 요소 플레이북을 사용하여 배포하는 경우, Ansible이 필요한 PVC를 만들고 Astra Trident가 PVC를 위한 스토리지를 프로비저닝하면 서비스를 배포합니다.
위의 변수와 배포 프로세스는 각 OpenShift 버전에 따라 변경될 수 있습니다. 검토 후 준수해야 합니다 "RedHat의 OpenShift 배포 가이드" 사용자 환경에 맞게 구성되도록 사용자의 버전에 대해.