Astra Trident est commercialisé tous les trois mois : janvier, avril, juillet et octobre. Ceci fait un mois après une version de Kubernetes.

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 le tridentctl get Commande pour obtenir plus d'informations sur la 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 utiliser "Cloud Insights" pour la surveillance et l'analyse.

Non Il n'y a aucun changement en ce qui concerne l'expérience utilisateur et les fonctionnalités. Le nom de provisionnement 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. Voir "ici".

Oui. Avec Astra Trident 18.10 et les versions ultérieures, il prend en charge la fonctionnalité d'installation à distance à partir de n'importe quelle machine kubectl accès au cluster. Après kubectl vérification de l'accès (par exemple, lancement d'un kubectl get nodes commande de la machine à distance pour la vérification), suivre les instructions d'installation.

Astra Trident est installé en tant que Kubernetes Deployment (ReplicaSet) avec une instance, et ce de même qu'il a 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. Voir "ici".

Vous pouvez générer et modifier localement les fichiers de manifeste exacts utilisés par Astra Trident pour l'installation, si nécessaire. Voir "ici".

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 nom unique StoragePrefix paramètre dans le setup/backend.json 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éer un problème sur "Astra Trident Github" Et mentionner RFE dans le sujet et la description du problème.

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

Si vous avez des questions, des problèmes ou des demandes, contactez-nous par le biais de notre Astra "Déroulez le canal" Ou GitHub.

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

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 bugs observés après une mise à niveau, des problèmes de dépendance ou une mise à niveau infructueuse ou incomplète, vous devez "Désinstallez Astra Trident" et réinstallez 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 un paramètre useCHAP=true dans votre configuration 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 du drapeau --use-ipv6 (pour tridentctl 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 la LIF de management back-end à l'aide de tridentctl update backend commande.

Vous pouvez mettre à jour la LIF de données 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, l' storagePools et additionalStoragePools les paramètres sont utilisés pour sélectionner un ensemble spécifique de pools.

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

Si plusieurs systèmes back-end configurés du même type sont configurés, Astra Trident sélectionne le back-end approprié en fonction des paramètres présents dans StorageClass et PersistentVolumeClaim. Par exemple, si il existe plusieurs pilotes back-end ontap-nas, Astra Trident tente de correspondre aux paramètres dans le StorageClass et PersistentVolumeClaim combiné et correspondre à un système back-end capable de fournir les exigences répertoriées dans StorageClass et PersistentVolumeClaim. 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 Le pilote crée jusqu'à 200 qtrees dans le même FlexVol (configurables entre 50 et 300), 100,000 qtrees par nœud de cluster et 2,4 millions par cluster. Lorsque vous saisissez un nouveau PersistentVolumeClaim Le pilote cherche à voir si un FlexVol existe déjà pour le service du 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 backend.

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, se reporter à : "Fonctionnement d'Astra Trident avec NVE et NAE"

Utiliser StorageClasses Afin d'implémenter la QoS pour ONTAP.

Les pilotes ONTAP prennent en charge le provisionnement fin ou non fin. Le provisionnement fin est par défaut pour les pilotes ONTAP. Si un provisionnement lourd est souhaité, vous devez configurer le fichier de définition backend 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 l' VolumeSnapshotDataSource la porte de fonction a été activée.

Depuis, nous proposons aujourd'hui la prise en charge de snapshots à la demande 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 ontap-nas, ontap-san, et ontap-nas-flexgroup pilotes. Vous pouvez également spécifier un snapshotPolicy pour le ontap-san-economy Pilote au niveau FlexVol.

Cette fonction est également disponible sur le ontap-nas-economy Pilotes mais au niveau de la granularité FlexVol, pas au niveau de la granularité qtree. Pour permettre la création de copies Snapshot provisionnées par Astra Trident, définissez le paramètre back-end snapshotPolicy À la politique de snapshot souhaitée, telle que définie sur le back-end ONTAP. Tout snapshot effectué par le contrôleur de stockage ne est pas connu d'Astra Trident.

Oui. Il est possible de réserver un pourcentage spécifique d'espace disque pour le stockage des copies Snapshot via Astra Trident en configurant le snapshotReserve attribut dans le fichier de définition backend. Si vous avez configuré snapshotPolicy et snapshotReserve dans le fichier de définition backend, le pourcentage de réserve de snapshot est défini en fonction de la snapshotReserve pourcentage indiqué dans le fichier back-end. Si le snapshotReserve Le pourcentage de nombre n'est pas indiqué, ONTAP occupe par défaut le pourcentage de réserve Snapshot comme 5. Si le snapshotPolicy l'option est définie sur aucune, le pourcentage de réserve snapshot est défini sur 0.

Oui, vous pouvez accéder au répertoire de snapshots sur le volume provisionné par Trident en paramétrant le snapshotDir paramètre dans le fichier de définition backend.

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.