24.02 릴리즈부터 Astra Trident는 2월, 6월, 10월마다 릴리즈됩니다.

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

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

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

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

예, Astra Trident는 오프라인으로 설치할 수 있습니다. 을 "Astra Trident 설치에 대해 자세히 알아보십시오"참조하십시오.

예. Astra Trident 18.10 이상은 클러스터에 액세스할 수 있는 모든 장비에서 원격 설치 기능을 kubectl 지원합니다. 액세스가 확인된 후 kubectl(예: 원격 컴퓨터에서 명령을 시작하여 kubectl 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을 생성합니다. 을 "tridentctl 설치를 사용자 지정합니다"참조하십시오.

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

권장되지 않지만 두 개의 Astra Trident 인스턴스에 동일한 백엔드 SVM을 사용할 수 있습니다. 설치하는 동안 각 인스턴스에 대해 고유한 볼륨 이름을 지정하거나 파일에 고유한 StoragePrefix 매개 변수를 setup/backend.json 지정합니다. 이는 동일한 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 설치 방법에 따라 다릅니다.

문제를 "Astra Trident GitHub를 참조하십시오" 작성하고 문제에 대한 주제 및 설명에 * RFE * 를 언급합니다.

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

질문, 문제 또는 요청이 있는 경우 Astra 또는 GitHub를 통해 NetApp에 문의하십시오"불화 채널".

백엔드의 암호를 로 tridentctl update backend myBackend -f </path/to_new_backend.json> -n trident`업데이트합니다. `myBackend`이 예에서는 백엔드 이름을 `/path/to_new_backend.json` 올바른 파일 경로로 backend.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로 업그레이드할 수 있습니다. 운영 구축 전에 연구소에서 업그레이드를 테스트해야 합니다.

업그레이드, 종속성 문제 또는 실패하거나 불완전한 업그레이드 후에 발견된 버그에 대한 수정이 필요한 경우 "Astra Trident를 제거합니다"해당 버전에 대한 특정 지침을 사용하여 이전 버전을 다시 설치해야 합니다. 이 방법은 이전 버전으로 다운그레이드하는 유일한 권장 방법입니다.

관리 LIF는 필수입니다. 데이터 LIF는 다양합니다.

예. Astra Trident는 ONTAP 백엔드를 위한 양방향 CHAP를 지원합니다. 이를 위해서는 백엔드 구성에 설정이 useCHAP=true 필요합니다.

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

Astra Trident는 다음에 대한 IPv6 주소 정의를 지원합니다.

Astra Trident가 IPv6에서 작동하려면 플래그(설치용), IPv6 (Trident 운영자용) 또는 tridentTPv6 (Helm 설치용 tridentctl)를 사용하여 설치되어야 한다 --use-ipv6.

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

Data LIF는 와 ontap-nas-economy 에서만 업데이트할 수 ontap-nas 있습니다.

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

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

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

동일한 유형의 백엔드가 여러 개 구성된 경우 Astra Trident는 및 PersistentVolumeClaim 에 있는 매개 변수를 기반으로 적절한 백엔드를 선택합니다 StorageClass. 예를 들어, ONTAP-NAS 드라이버 백엔드가 여러 개 있는 경우 Astra Trident는 및 PersistentVolumeClaim 의 매개 변수를 일치시키고 백엔드를 일치시켜 StorageClass 및 PersistentVolumeClaim 에 나열된 요구사항을 제공할 수 있습니다. StorageClass 요청과 일치하는 백엔드가 여러 개 있는 경우, Astra Trident는 임의의 백엔드 중 하나를 선택합니다.

예.

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

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

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

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

백엔드 정의 파일의 암호화 매개 변수를 사용하여 Trident에서 프로비저닝한 볼륨에 대한 암호화를 설정할 수 있습니다. 자세한 내용은 다음을 참조하십시오. "Astra Trident가 NVE 및 NAE와 연동되는 방식"

를 사용하여 StorageClasses ONTAP용 QoS를 구현합니다.

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

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

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

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

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

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

현재, ontap-nas-flexgroup, ontap-san, , , , ontap-san-economy solidfire-san 및 gcp-cvs 에서 온디맨드 스냅샷 지원을 ontap-nas, 및 azure-netapp-files 백엔드 드라이버.

이 기능은 , ontap-san 및 ontap-nas-flexgroup 드라이버에서 사용할 ontap-nas 수 있습니다. FlexVol 수준에서 드라이버에 대해 ontap-san-economy 를 지정할 수도 snapshotPolicy 있습니다.

드라이버에서는 사용할 수도 있지만 FlexVol 레벨의 세분화된 레벨에서는 사용할 수 ontap-nas-economy 없습니다. Astra Trident을 통해 프로비저닝된 볼륨의 스냅샷을 생성하는 기능을 활성화하려면 백엔드 매개 변수 옵션을 ONTAP 백엔드에 정의된 대로 원하는 스냅샷 정책으로 설정하십시오 snapshotPolicy. 스토리지 컨트롤러에서 생성한 스냅샷은 Astra Trident에서 알 수 없습니다.

예. 백엔드 정의 파일에 속성을 설정하여 Astra Trident을 통해 스냅샷 복사본을 저장하기 위해 특정 비율의 디스크 공간을 예약할 수 있습니다 snapshotReserve. 백엔드 정의 파일에 및 을 snapshotReserve 구성한 경우 snapshotPolicy 스냅숏 예비 공간 백분율은 백엔드 파일에 언급된 백분율에 따라 snapshotReserve 설정됩니다. 백분율 숫자가 언급되지 않은 경우 snapshotReserve ONTAP는 기본적으로 스냅숏 예비 공간 비율을 5로 설정합니다. 이 snapshotPolicy 옵션을 none으로 설정하면 스냅숏 예비 공간 비율이 0으로 설정됩니다.

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

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

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

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

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