Astra Trident는 1월, 4월, 7월, 10월에 3개월마다 출시됩니다. Kubernetes 릴리스 한 달 후입니다.

Astra Trident는 일반적으로 Kubernetes의 알파 기능을 지원하지 않습니다. Trident는 Kubernetes 베타 릴리즈를 따르는 두 Trident 릴리스 내에서 베타 기능을 지원할 수 있습니다.

Astra Trident는 다른 NetApp 소프트웨어 제품에 종속되어 있지 않으며 독립 실행형 애플리케이션으로 작동합니다. 그러나 NetApp 백엔드 스토리지 디바이스가 있어야 합니다.

"tridentctl get" 명령을 사용하여 Astra Trident 구성에 대한 자세한 정보를 얻을 수 있습니다.

예. Trident 20.01에는 관리되는 백엔드 수, 프로비저닝된 볼륨 수, 사용된 바이트 수 등 Astra Trident의 작업에 대한 정보를 수집하는 데 사용할 수 있는 Prometheus 엔드포인트가 도입되었습니다. Cloud Insights를 사용하여 모니터링 및 분석할 수도 있습니다.

아니요 사용자 환경과 기능에 관한 한 변경 사항은 없습니다. 사용된 공급자 이름은 csi.trident.netapp.io` 입니다. 현재 및 향후 릴리즈에서 제공하는 모든 새로운 기능을 사용하려는 경우 이 Astra Trident 설치 방법을 사용하는 것이 좋습니다.

아스트라 트리덴트(Astra Trident)는 더 이상 '에트cd’를 필요로 하지 않습니다. CRD를 사용하여 상태를 유지합니다.

예, Astra Trident는 오프라인으로 설치할 수 있습니다. 을 참조하십시오 "여기".

예. Astra Trident 18.10 이상은 클러스터에 대한 "kudctl" 액세스 권한이 있는 모든 시스템에서 원격 설치 기능을 지원합니다. "kubbtl" 액세스를 확인한 후(예: 원격 시스템에서 kubeck get nodes 명령을 시작하여 확인) 설치 지침을 따릅니다.

Astra Trident는 하나의 인스턴스로 Kubernetes 배포(ReplicaSet)로 설치되었으므로 HA가 내장되어 있습니다. 구축 시 복제본 수를 늘이지 않아야 합니다. Astra Trident가 설치된 노드가 손실되거나 POD에 액세스할 수 없는 경우 Kubernetes가 자동으로 Pod를 클러스터의 정상 노드에 다시 배포합니다. Astra Trident는 컨트롤 플레인만 지원하므로 Astra Trident를 다시 구축할 경우 현재 마운트된 Pod는 영향을 받지 않습니다.

Astra Trident가 Kubernetes API Server에서 읽어 애플리케이션에서 새로운 PVC를 요청할 시기를 결정하므로 kubbe-system에 액세스해야 합니다.

Trident 설치 프로그램은 Kubernetes 클러스터의 PersistentVolume, PersistentVolumeClaim, StorageClass 및 Secret 리소스에 대한 특정 액세스 권한을 가진 Kubernetes ClusterRole을 생성합니다. 을 참조하십시오 "여기".

필요한 경우 설치에 Astra Trident가 사용하는 정확한 매니페스트 파일을 로컬에서 생성하고 수정할 수 있습니다. 을 참조하십시오 "여기".

권장되지 않지만 두 개의 Astra Trident 인스턴스에 동일한 백엔드 SVM을 사용할 수 있습니다. 설치 시 각 인스턴스의 고유한 볼륨 이름을 지정하거나 셋업/백엔드 .json 파일에 고유한 'toragePrefix' 매개변수를 지정하십시오. 이는 동일한 FlexVol가 두 인스턴스에 모두 사용되지 않도록 하기 위한 것입니다.

Astra Trident는 Kubernetes Pod로, Kubernetes를 실행 중인 모든 위치에 설치할 수 있습니다.

예. Astra Trident는 AWS, Google Cloud 및 Azure에서 지원됩니다.

예, Astra Trident는 Azure의 Azure NetApp Files 서비스와 GCP의 Cloud Volumes Service를 지원합니다.

Astra Trident는 오픈 소스이며 무료로 제공되지만, NetApp 백엔드가 지원되는 경우 NetApp은 이를 완벽하게 지원합니다.

지원 케이스를 제기하려면 다음 중 하나를 수행합니다.

tridentctl logs-a를 실행하여 지원 번들을 생성할 수 있습니다. 번들에 캡처된 로그 외에 kubelet 로그를 캡처하여 Kubernetes 측의 마운트 문제를 진단합니다. 쿠벨렛 로그를 얻는 지침은 Kubernetes 설치 방법에 따라 다릅니다.

에서 문제를 만듭니다 "GitTrident 허브" 제목에 * RFE * 를 기재하고 문제에 대한 설명을 기재하십시오.

에서 문제를 만듭니다 "Astra Trident GitHub를 참조하십시오". 문제와 관련된 모든 필수 정보와 로그를 포함해야 합니다.

질문, 문제 또는 요청이 있을 경우 NetApp을 통해 문의하십시오 "슬랙" 팀 또는 GitHub를 선택합니다.

'tridentctl update backend mybackend -f</path/to_new_backend.json> -n triment’로 백엔드 암호를 업데이트합니다. 이 예에서 'mybackend’를 백엔드 이름으로, '/path/to_new_backend.json’을 올바른 백엔드 .json 파일 경로로 바꿉니다.

Astra Trident가 Kubernetes 노드를 찾을 수 없는 두 가지 시나리오가 있을 수 있습니다. Kubernetes의 네트워킹 문제 또는 DNS 문제 때문일 수 있습니다. 각 Kubernetes 노드에서 실행되는 Trident 노드 데모는 Trident 컨트롤러와 통신하여 노드를 Trident에 등록할 수 있어야 합니다. Astra Trident를 설치한 후 네트워킹 변경이 발생하면 클러스터에 추가된 새 Kubernetes 노드에서만 이 문제가 발생합니다.

Trident POD를 제거할 경우 데이터가 손실되지 않습니다. Trident의 메타데이터는 CRD 객체에 저장됩니다. Trident에서 프로비저닝한 모든 PVS가 정상적으로 작동합니다.

NetApp은 하나의 주요 릴리즈에서 바로 다음 주요 릴리즈로 Astra Trident를 업그레이드할 수 있도록 지원합니다. 버전 18.xx에서 19.xx, 19.xx에서 20.xx로 업그레이드할 수 있습니다. 운영 구축 전에 연구소에서 업그레이드를 테스트해야 합니다.

다운그레이드를 원할 경우 다양한 요소를 평가해야 합니다. 을 참조하십시오 "다운그레이드 섹션을 참조하십시오".

백엔드 정의 파일에 둘 다 포함하는 것이 좋습니다. 그러나 관리 LIF는 필수 항목일 뿐입니다.

예. 20.04부터 Astra Trident는 ONTAP 백엔드에 대한 양방향 CHAP를 지원합니다. 이를 위해서는 백엔드 구성에서 'useCHAP=true’를 설정해야 합니다.

Astra Trident는 버전 20.04 이상에서 내보내기 정책을 동적으로 생성하고 관리할 수 있습니다. 따라서 스토리지 관리자는 백엔드 구성에서 하나 이상의 CIDR 블록을 제공할 수 있으며, 이러한 범위에 속하는 Trident 추가 노드 IP를 생성한 엑스포트 정책에 추가할 수 있습니다. 이러한 방식으로 Astra Trident는 주어진 CIDR 내에 IP가 있는 노드의 규칙 추가 및 삭제를 자동으로 관리합니다. 이 기능을 사용하려면 CSI Trident가 필요합니다.

Astra Trident 19.01 이후 버전에서는 DataLIF에 포트를 지정할 수 있습니다. backend.json 파일에 ""management LIF":<ip address>:<port>""로 설정한다. 예를 들어, 관리 LIF의 IP 주소가 192.0.2.1이고 포트가 1000이면 """관리 LIF":"192.0.2.1:1000""을 구성합니다.

예. Astra Trident 20.01은 ONTAP 백엔드에 대한 관리 LIF 및 데이터 LIF 매개 변수의 IPv6 주소 정의를 지원합니다. 주소가 IPv6 의미를 따르고 관리 LIF가 대괄호 안에 정의되어 있는지 확인해야 합니다(예: "[ec0d:6504:a9c1:a961:533d1:4bdf:ab32:e233]"). 또한 Astra Trident가 IPv6 기능을 위해 '--use-ipv6' 플래그를 사용하여 설치되어 있는지 확인해야 합니다.

예. 'tridentctl update backend' 명령을 사용하여 백엔드 관리 LIF를 업데이트할 수 있습니다.

아니요. 백엔드에서 데이터 LIF를 업데이트할 수 없습니다.

Astra Trident는 동일한 드라이버나 다른 드라이버를 사용하여 동시에 많은 백엔드를 지원할 수 있습니다.

Astra Trident는 백엔드 자격 증명을 Kubernetes Secrets로 저장합니다.

백엔드 속성을 사용하여 클래스에 맞는 풀을 자동으로 선택할 수 없는 경우 특정 풀 세트를 선택하는 데 'toragePools' 및 'additionalStoragePools' 매개 변수가 사용됩니다.

excludeStoragePools 매개 변수는 Astra Trident가 프로비저닝에 사용할 풀 세트를 필터링하고 일치하는 풀을 제거하는 데 사용됩니다.

동일한 유형의 백엔드가 여러 개 구성되어 있는 경우 Astra Trident는 'torageClass' 및 'PersistentVolumeClaim’에 있는 매개 변수를 기반으로 적절한 백엔드를 선택합니다. 예를 들어, 여러 ONTAP-NAS 드라이버 백엔드가 있는 경우 Astra Trident는 'torageClass' 및 'PersistentVolumeClaim’의 매개 변수를 조합하여 'torageClass' 및 'PersistVolumeentClaim’에 나열된 요구 사항을 전달할 수 있는 백엔드와 일치시킵니다. 요청과 일치하는 백엔드가 여러 개 있는 경우, Astra Trident는 임의의 백엔드 중 하나를 선택합니다.

예.

'ONTAP-NAS-이코노미' 드라이버는 동일한 FlexVol에서 최대 200개의 qtree(50~300 구성 가능), 클러스터 노드당 100,000 qtree, 클러스터당 2.4M qtree를 지원합니다. 이코노미 드라이버가 서비스하는 새 "PersistentVolumeClaim"을 입력하면 운전자는 새 Qtree를 처리할 수 있는 FlexVol가 이미 있는지 확인합니다. Qtree를 처리할 수 있는 FlexVol가 없으면 새 FlexVol가 생성됩니다.

백엔드 정의 파일에 매개 변수를 설정하여 Astra Trident가 프로비저닝한 볼륨에 대해 Unix 권한을 설정할 수 있습니다.

기본적으로 Astra Trident는 Kubernetes의 마운트 옵션을 아무 값으로도 설정하지 않습니다. Kubernetes 스토리지 클래스에서 마운트 옵션을 지정하려면 지정된 예제를 따르십시오 "여기".

적절한 호스트가 볼륨에 액세스할 수 있도록 하려면 백엔드 정의 파일에 구성된 "exportPolicy" 매개 변수를 사용합니다.

백엔드 정의 파일의 암호화 매개 변수를 사용하여 Trident에서 프로비저닝한 볼륨에 대한 암호화를 설정할 수 있습니다.

ONTAP용 QoS를 구현하려면 'torageClaes’를 사용합니다.

ONTAP 드라이버는 씬 또는 일반 프로비저닝을 지원합니다. ONTAP 드라이버는 기본적으로 씬 프로비저닝입니다. 일반 프로비저닝이 필요한 경우 백엔드 정의 파일 또는 'torageClass’를 구성해야 합니다. 둘 다 구성된 경우 'torageClass’가 우선합니다. ONTAP에 대해 다음을 구성합니다.

PVC 보호는 버전 1.10부터 Kubernetes에서 자동으로 활성화됩니다.

예. Astra Trident에서 만든 PVC를 확장할 수 있습니다. 볼륨 자동 증가 기능은 Trident에 적용되지 않는 ONTAP 기능입니다.

19.04부터는 볼륨 가져오기 기능을 사용하여 Kubernetes에 볼륨을 가져올 수 있습니다.

외부 볼륨이 DP 모드이거나 오프라인인 경우 볼륨 가져오기가 실패합니다. 다음과 같은 오류 메시지가 나타납니다.

Trident 19.10은 CSI Provisioner를 사용하여 iSCSI PVS를 확장할 수 있도록 지원합니다.

NetApp 스토리지의 용량이 있는 경우 Kubernetes 스토리지 리소스 할당량이 작동합니다. 용량 부족으로 인해 NetApp 스토리지가 Kubernetes 할당량 설정을 적용할 수 없을 경우 Astra Trident가 프로비저닝하려고 하지만 오류를 해결합니다.

예. Astra Trident는 스냅샷에서 필요 시 볼륨 스냅샷 및 영구 볼륨 생성을 지원합니다. 스냅샷에서 PVS를 생성하려면 'VolumeSnapshotDataSource' 기능 게이트가 활성화되어 있는지 확인합니다.

현재 ONTAP-NAS, ONTAP-NAS-Flexgroup, ONTAP-SAN, ONTAP-SAN-이코노미, 졸idfire-SAN의 온디맨드 스냅샷 지원을 이용할 수 있습니다. GCP-CV와 Azure-NetApp-files 백엔드 드라이버.

ONTAP-NAS, ONTAP-SAN, ONTAP-NAS-Flexgroup 드라이버에서 지원됩니다. FlexVol 레벨에서 ONTAP-SAN-이코노미 드라이버에 대한 스냅샷 정책을 지정할 수도 있습니다.

이는 'ONTAP-NAS-이코노미' 드라이버에서도 사용할 수 있지만 qtree 레벨의 세분화가 아니라 FlexVol 레벨의 세분화 수준에서 확인할 수 있습니다. Astra Trident에서 프로비저닝한 볼륨을 스냅샷하는 기능을 사용하려면 백엔드 매개 변수 옵션 '스냅샷 정책’을 ONTAP 백엔드에 정의된 대로 원하는 스냅샷 정책으로 설정하십시오. 스토리지 컨트롤러에서 생성한 스냅샷은 Astra Trident에서 알 수 없습니다.

예. 백엔드 정의 파일에 '스냅샷 예약' 속성을 설정하여 Astra Trident를 통해 스냅샷 복사본을 저장할 디스크 공간의 특정 비율을 예약할 수 있습니다. 백엔드 정의 파일에 '스냅샷 정책’과 '스냅샷 예약’을 구성한 경우 백엔드 파일에 명시된 '스냅샷 예약 공간' 비율에 따라 스냅샷 예약 비율이 설정됩니다. '스냅샷 예약' 백분율 값이 언급되지 않은 경우 ONTAP는 기본적으로 스냅샷 예약 비율을 5로 설정합니다. '스냅샷 정책' 옵션이 없음으로 설정되어 있으면 스냅샷 예약 비율은 0으로 설정됩니다.

예. 백엔드 정의 파일에서 '스냅샷 디렉토리' 매개 변수를 설정하여 Trident에서 프로비저닝한 볼륨의 스냅샷 디렉토리에 액세스할 수 있습니다.

현재 ONTAP CLI 또는 OnCommand System Manager를 사용하여 외부에서 SnapMirror를 설정해야 합니다.

ONTAP 스냅숏에 볼륨을 복원하려면 다음 단계를 수행하십시오.

NFS를 통해 데이터를 제공하는 SVM의 루트 볼륨에 로드 공유 미러를 생성할 수 있습니다. ONTAP는 Trident에서 생성한 볼륨의 로드 공유 미러를 자동으로 업데이트합니다. 이로 인해 볼륨 마운팅이 지연될 수 있습니다. Trident를 사용하여 여러 볼륨을 생성할 경우 볼륨 프로비저닝은 ONTAP에서 로드 공유 미러 업데이트에 따라 달라집니다.

Kubernetes에서는 네임스페이스의 스토리지 클래스를 허용하지 않습니다. 그러나 Kubernetes를 사용하여 네임스페이스당 사용되는 스토리지 리소스 할당량을 사용하여 네임스페이스당 특정 스토리지 클래스의 사용을 제한할 수 있습니다. 특정 스토리지에 대한 특정 네임스페이스 액세스를 거부하려면 해당 스토리지 클래스에 대한 리소스 할당량을 0으로 설정합니다.