À partir de la version 24.02, Astra Trident est sorti tous les quatre mois : février, juin et octobre.

Astra Trident ne prend généralement pas en charge les fonctionnalités alpha dans Kubernetes. Trident peut prendre en charge les fonctionnalités bêta dans les deux versions de Trident, qui suivent la version bêta de Kubernetes.

Astra Trident ne fonctionne pas sous forme de dépendance vis-à-vis d'autres logiciels NetApp, et il fonctionne comme une application autonome. Toutefois, vous devez disposer d'un système de stockage back-end NetApp.

Utilisez tridentctl get la commande pour obtenir plus d'informations sur votre configuration d'Astra Trident.

Oui. Les terminaux Prometheus peuvent être utilisés pour rassembler des informations sur les opérations d'Astra Trident, telles que le nombre de systèmes back-end gérés, le nombre de volumes provisionnés, d'octets consommés, etc. Vous pouvez également l'utiliser "Cloud Insights" pour la surveillance et l'analyse.

Non. Il n'y a pas de changement en ce qui concerne l'expérience utilisateur et les fonctionnalités. Le nom de provisionneur utilisé est csi.trident.netapp.io. Cette méthode d'installation d'Astra Trident est recommandée si vous souhaitez utiliser toutes les nouvelles fonctionnalités fournies par les versions actuelles et futures.

Oui, Astra Trident peut être installé hors ligne. Reportez-vous à la "Découvrez l'installation d'Astra Trident".

Oui. ASTRA Trident 18.10 et les versions ultérieures prennent en charge la fonctionnalité d'installation à distance à partir de n'importe quelle machine ayant kubectl accès au cluster. Une fois l' kubectl`accès vérifié (par exemple, lancez une `kubectl get nodes commande à partir de l'ordinateur distant pour vérifier), suivez les instructions d'installation.

ASTRA Trident est installé en tant que déploiement Kubernetes (ReplicaSet) avec une instance. Il est donc intégré à la haute disponibilité. Vous ne devez pas augmenter le nombre de répliques dans le déploiement. Si le nœud sur lequel Astra Trident est installé ou si le pod est inaccessible, Kubernetes redéploie automatiquement le pod sur un nœud en état de santé dans votre cluster. L'Astra Trident est uniquement du plan de contrôle. Les pods actuellement montés ne sont donc pas affectés en cas de redéploiement de l'Astra Trident.

L'Astra Trident effectue une lecture sur le serveur d'API Kubernetes afin de déterminer le moment où les applications demandent des nouveaux ESV. Il doit donc accéder à kube-System.

Le programme d'installation Trident crée un cluster Kubernetes ClusterRole, qui dispose d'un accès spécifique aux ressources PersistentVolume, PersistentVolumeClaim, StorageClass et Secret du cluster Kubernetes. Reportez-vous à la "Personnalisez l'installation tridentctl".

Vous pouvez générer et modifier localement les fichiers de manifeste exacts utilisés par Astra Trident pour l'installation, si nécessaire. Reportez-vous à la "Personnalisez l'installation tridentctl".

Bien qu'il ne soit pas conseillé, vous pouvez utiliser le même SVM back-end pour deux instances Astra Trident. Spécifiez un nom de volume unique pour chaque instance lors de l'installation et/ou spécifiez un paramètre unique StoragePrefix dans setup/backend.json le fichier. Ceci permet de s'assurer que le même FlexVol n'est pas utilisé pour les deux instances.

Astra Trident est un simple pod Kubernetes. Il peut être installé quel que soit l'emplacement de Kubernetes.

Oui, Astra Trident est pris en charge par AWS, Google Cloud et Azure.

Oui. Astra Trident prend en charge le service Azure NetApp Files dans Azure ainsi que le service Cloud Volumes Service dans GCP.

Bien qu'Astra Trident soit open source et fourni gratuitement, NetApp le prend entièrement en charge à condition que votre système back-end NetApp soit pris en charge.

Pour soulever un dossier de support, effectuez l'une des opérations suivantes :

Vous pouvez créer un bundle de support en exécutant tridentctl logs -a. Outre les journaux capturés dans le pack, capture le journal kubelet pour diagnostiquer les problèmes de montage côté Kubernetes. Les instructions d'obtention du journal kubelet varient en fonction de l'installation de Kubernetes.

Créez un problème "Astra Trident Github" et mentionnez RFE dans l'objet et la description du problème.

Créez un problème sur "Astra Trident Github". Veillez à inclure toutes les informations et tous les journaux nécessaires concernant le problème.

Pour toute question, problème ou demande, contactez-nous via Astra "Déroulez le canal" ou GitHub.

Mettez à jour le mot de passe du backend avec tridentctl update backend myBackend -f </path/to_new_backend.json> -n trident. Remplacez myBackend dans l'exemple par votre nom de back-end et `/path/to_new_backend.json par le chemin d'accès au fichier correct backend.json.

Il existe deux scénarios possibles pour savoir pourquoi Astra Trident ne peut pas trouver un nœud Kubernetes. Elle peut être due à un problème de mise en réseau dans Kubernetes ou DNS. Le demonset de nœuds Trident qui s'exécute sur chaque nœud Kubernetes doit pouvoir communiquer avec le contrôleur Trident pour enregistrer le nœud avec Trident. Si des modifications de mise en réseau ont eu lieu après l'installation d'Astra Trident, ce problème se produit uniquement avec les nouveaux nœuds Kubernetes qui sont ajoutés au cluster.

Les données ne seront pas perdues si le pod Trident est détruit. Les métadonnées Trident sont stockées dans des objets CRD. Tous les volumes persistants provisionnés par Trident fonctionneront normalement.

NetApp prend en charge la mise à niveau d'Astra Trident d'une version majeure à la prochaine version majeure. Vous pouvez effectuer la mise à niveau de la version 18.xx vers la version 19.xx, 19.xx vers la version 20.xx, etc. Il est conseillé de tester la mise à niveau dans un laboratoire avant le déploiement en production.

Si vous avez besoin d'un correctif pour les bogues observés après une mise à niveau, des problèmes de dépendance ou une mise à niveau non réussie ou incomplète, vous devez "Désinstallez Astra Trident"réinstaller la version précédente en suivant les instructions spécifiques à cette version. Il s'agit de la seule méthode recommandée pour revenir à une version antérieure.

Le LIF de gestion est obligatoire. Data LIF varie :

Oui. ASTRA Trident prend en charge le protocole CHAP bidirectionnel pour les systèmes ONTAP back-end. Ceci nécessite la useCHAP=true configuration de votre back-end.

Astra Trident peut créer et gérer de manière dynamique des règles d'exportation à partir de la version 20.04. Cela permet à l'administrateur de stockage de fournir un ou plusieurs blocs CIDR dans leur configuration backend et de laisser Trident ajouter des adresses IP de nœud comprise dans ces plages à une export policy créée. Ainsi, Astra Trident gère automatiquement l'ajout et la suppression de règles pour les nœuds dont les adresses IP sont comprises dans les rapports CIDR donnés.

Astra Trident prend en charge la définition des adresses IPv6 pour :

ASTRA Trident doit être installé à l'aide de l'indicateur --use-ipv6 (pour tridentctl l'installation), IPv6 (pour l'opérateur Trident) ou tridentTPv6 (pour l'installation Helm) pour qu'il fonctionne sur IPv6.

Oui, il est possible de mettre à jour le LIF back-end Management à l'aide de la tridentctl update backend commande.

Vous pouvez mettre à jour la LIF Data sur ontap-nas et ontap-nas-economy uniquement.

Astra Trident peut prendre en charge de nombreux systèmes back-end simultanément, avec le même pilote ou des pilotes différents.

Astra Trident stocke les identifiants back-end sous le titre de secrets de Kubernetes.

Si les attributs back-end ne peuvent pas être utilisés pour sélectionner automatiquement les pools appropriés pour une classe, les storagePools paramètres et additionalStoragePools sont utilisés pour sélectionner un ensemble spécifique de pools.

Le excludeStoragePools paramètre est utilisé pour filtrer l'ensemble de pools qu'Astra Trident utilisera pour le provisionnement et supprimera tous les pools correspondant.

S'il existe plusieurs systèmes back-end configurés du même type, Astra Trident sélectionne le back-end approprié en fonction des paramètres présents dans StorageClass et PersistentVolumeClaim. Par exemple, s'il existe plusieurs pilotes back-end ONTAP-nas, Astra Trident tente de faire correspondre les paramètres dans le StorageClass et PersistentVolumeClaim combinés avec un back-end qui peut répondre aux exigences répertoriées dans StorageClass le et `PersistentVolumeClaim`le . Si plusieurs systèmes back-end correspondent à la demande, l'Astra Trident est sélectionnée de manière aléatoire.

Oui.

Le ontap-nas-economy pilote crée jusqu'à 200 qtrees dans le même FlexVol (configurable entre 50 et 300), 100,000 qtrees par nœud de cluster et 2,4 millions par cluster. Lorsque vous entrez un nouveau PersistentVolumeClaim qui est entretenu par le conducteur économique, le conducteur recherche s'il existe déjà un FlexVol qui peut réparer le nouveau qtree. Si la FlexVol n'existe pas qui peut traiter le qtree, un nouveau FlexVol est créé.

Vous pouvez définir des autorisations Unix sur le volume provisionné par Astra Trident en définissant un paramètre dans le fichier de définition backend.

Par défaut, Astra Trident ne définit pas d'option de montage sur aucune valeur avec Kubernetes. Pour spécifier les options de montage dans la classe de stockage Kubernetes, suivez l'exemple donné "ici".

Pour permettre aux hôtes appropriés d'accéder à un volume, utilisez le exportPolicy paramètre configuré dans le fichier de définition back-end.

Vous pouvez définir le chiffrement sur le volume provisionné par Trident à l'aide du paramètre de chiffrement dans le fichier de définition back-end. Pour plus d'informations, reportez-vous à : "Fonctionnement d'Astra Trident avec NVE et NAE"

Les pilotes ONTAP prennent en charge le provisionnement fin ou non fin. Le provisionnement fin est par défaut pour les pilotes ONTAP. Si vous souhaitez effectuer un provisionnement lourd, vous devez configurer le fichier de définition du back-end ou le StorageClass. Si les deux sont configurés, StorageClass a priorité. Configurez les éléments suivants pour ONTAP :

La protection contre la demande de volume persistant est automatiquement activée sur Kubernetes à partir de la version 1.10.

Oui. Vous pouvez développer un volume de volume persistant créé par Astra Trident. Notez que la croissance automatique de volume est une fonctionnalité ONTAP qui n'est pas applicable à Trident.

L'importation du volume échoue si le volume externe est en mode DP ou est hors ligne. Vous recevez le message d'erreur suivant :

Le quota de ressources de stockage Kubernetes doit fonctionner tant que le stockage NetApp possède de la capacité. Lorsque le stockage NetApp ne peut pas respecter les paramètres de quota Kubernetes en raison d'un manque de capacité, Astra Trident tente d'effectuer le provisionnement, mais s'y efforce d'erreurs.

Oui. La création à la demande de copies Snapshot de volume et de volumes persistants à partir de copies Snapshot est prise en charge par Astra Trident. Pour créer des volumes persistants à partir de snapshots, assurez-vous que la VolumeSnapshotDataSource porte de fonctionnalité a été activée.

À partir d'aujourd'hui, la prise en charge de snapshots à la demande est disponible pour nos ontap-nas, ontap-nas-flexgroup ontap-san ontap-san-economy solidfire-san , , , , , gcp-cvs, et azure-netapp-files pilotes backend.

Cette option est disponible sur les ontap-nas pilotes , ontap-san et ontap-nas-flexgroup. Vous pouvez également spécifier un snapshotPolicy pour le ontap-san-economy pilote au niveau FlexVol.

Cela est également disponible sur les ontap-nas-economy pilotes, mais au niveau de la granularité FlexVol, et non au niveau qtree. Pour activer la possibilité d'effectuer des snapshots des volumes provisionnés par Astra Trident, définissez l'option du paramètre back-end snapshotPolicy sur la règle de snapshot souhaitée, comme définie sur le back-end ONTAP. Tout snapshot effectué par le contrôleur de stockage ne est pas connu d'Astra Trident.

Oui, vous pouvez réserver un pourcentage spécifique d'espace disque pour stocker les copies Snapshot via Astra Trident en définissant l' snapshotReserve`attribut dans le fichier de définition du back-end. Si vous avez configuré `snapshotPolicy et snapshotReserve dans le fichier de définition back-end, le pourcentage de réserve de snapshots est défini en fonction du snapshotReserve pourcentage mentionné dans le fichier back-end. Si le snapshotReserve pourcentage n'est pas mentionné, ONTAP utilise par défaut le pourcentage de réserve d'instantanés à 5. Si l' `snapshotPolicy`option est définie sur aucun, le pourcentage de réserve d'instantanés est défini sur 0.

Oui, vous pouvez accéder au répertoire de snapshot sur le volume provisionné par Trident en définissant le snapshotDir paramètre dans le fichier de définition back-end.

Actuellement, SnapMirror doit être défini en externe via l'interface de ligne de commande ONTAP ou OnCommand System Manager.

Pour restaurer un volume sur un snapshot ONTAP, effectuez les opérations suivantes :

Des miroirs de partage de charge peuvent être créés pour les volumes root des SVM qui fournissent des données sur NFS. ONTAP met automatiquement à jour les miroirs de partage de charge pour les volumes qui ont été créés par Trident. Cela peut entraîner des retards dans le montage des volumes. Lorsque plusieurs volumes sont créés via Trident, le provisionnement d'un volume dépend de la mise à jour par ONTAP du miroir de partage de charge.

Kubernetes n'autorise pas les classes de stockage dans les espaces de noms. Toutefois, vous pouvez utiliser Kubernetes pour limiter l'utilisation d'une classe de stockage spécifique par espace de noms à l'aide de quotas de ressources de stockage, qui sont par espace de noms. Pour refuser un accès d'espace de noms spécifique à un stockage spécifique, définissez le quota de ressources sur 0 pour cette classe de stockage.