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. Trident 20.01 introduit les terminaux Prometheus qui peuvent être utilisés pour collecter des informations sur le fonctionnement d'Astra Trident, notamment le nombre de systèmes back-end gérés, le nombre de volumes provisionnés, les 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.

Astra Trident n'a plus besoin d'un etcd. Il utilise des CRD pour maintenir l'état.

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 de Trident crée un cluster Kubernetes ClusterRole qui dispose d'un accès spécifique au volume persistant, à la demande de volume persistant, à la classe de stockage et aux ressources secrètes 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 AWS et 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 "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, n'hésitez pas à nous contacter en suivant notre "Mou" Équipe ou GitHub.

Mettez à jour le mot de passe du backend 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 de 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.

Un certain nombre de facteurs doivent être évalués si vous voulez rétrograder. Voir "la section sur la rétrogradation".

NetApp recommande d'avoir les deux dans le fichier de définition du back-end. Toutefois, le LIF de gestion est le seul qui est obligatoire.

Oui. À partir de la version 20.04, Astra Trident prend en charge le protocole CHAP bidirectionnel pour les systèmes back-end ONTAP. 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. Cette fonctionnalité requiert CSI Trident.

Astra Trident 19.01 et les versions ultérieures prennent en charge la spécification d'un port dans le DataLIF. Configurez-le dans le backend.json fichier en tant que “managementLIF”: <ip address>:<port>”. Par exemple, si l'adresse IP de votre LIF de gestion est 192.0.2.1, et si le port est 1000, configurez "managementLIF": "192.0.2.1:1000".

Oui. Astra Trident 20.01 prend en charge la définition des adresses IPv6 pour la gestion des LIF et les paramètres de dataLIF pour les systèmes back-end ONTAP. Vous devez vous assurer que l'adresse suit la sémantique IPv6 et que la LIF de gestion est définie entre parenthèses (par exemple, [ec0d:6504:a9c1:ae67:53d1:4bdf:ab32:e233]). Vous devez également vous assurer que Astra Trident est installé à l'aide du `--use-ipv6 Indicateur 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.

Non, il n'est pas possible de mettre à jour la LIF de données sur le backend.

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.

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.

À partir de la version 19.04, vous pouvez utiliser la fonctionnalité d'importation de volumes pour intégrer des volumes dans Kubernetes.

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

Trident 19.10 prend en charge l'extension de volumes persistants iSCSI à l'aide du mécanisme de provisionnement CSI.

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, aws-cvs, 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.