Skip to main content
Une version plus récente de ce produit est disponible.
La version française est une traduction automatique. La version anglaise prévaut sur la française en cas de divergence.

Notes de version

Contributeurs
PDF

Dans les notes de version, vous trouverez des informations sur les nouvelles fonctionnalités, les améliorations et les correctifs de bogues de la dernière version d'Astra Trident.

Avertissement Le tridentctl Binaire pour Linux fourni dans le fichier zip du programme d'installation est la version testée et prise en charge. Sachez que le macos binaire fourni dans le /extras une partie du fichier zip n'est pas testée ou prise en charge.

Nouveautés de la version 21.10.1

NetApp améliore et améliore continuellement ses produits et services. Voici quelques-unes des dernières fonctionnalités d'Astra Trident.

Pour les versions précédentes, voir "Versions cavalier de la documentation".

Changements depuis Astra Trident 21.10.0

Avertissement La version v21.10.0 présente un problème qui peut placer le contrôleur Trident dans un état CrashLoopBackOff lorsqu'un nœud est supprimé, puis réintégré au cluster Kubernetes. Ce problème a été résolu dans la version 1.210.1 (édition GitHub 669).

Correctifs

  • Condition de race potentielle fixe lors de l'importation d'un volume sur un back-end Cloud CVS GCP, entraînant l'échec de l'importation.

  • Résolution d'un problème de mise en service du contrôleur Trident dans un état CashLoopBackOff lorsqu'un nœud est retiré, puis réintégré au cluster Kubernetes (problème GitHub 669).

  • Problème résolu : les SVM n'ont plus été découverts si aucun nom de SVM n'a été spécifié (problème GitHub 612).

Changements depuis Astra Trident 21.07

Correctifs

  • Problème résolu : les clones de volumes XFS n'ont pas pu être montés sur le même nœud que le volume source (problème GitHub 514).

  • Résolution du problème pendant lequel Astra Trident a enregistré une erreur fatale lors de l'arrêt (problème GitHub 597).

  • Correctifs liés à Kubernetes :

    • Renvoyer l'espace utilisé d'un volume comme taille de restauration minimale lors de la création de snapshots avec ontap-nas et ontap-nas-flexgroup Pilotes (problème GitHub 645).

    • Résolution du problème où Failed to expand filesystem Une erreur a été consignée après le redimensionnement du volume (problème GitHub 560).

    • Résolution du problème de blocage d'un module Terminating État (problème GitHub 572).

    • A résolu le cas où un ontap-san-economy FlexVol peut contenir des LUN de snapshot (GitHub : édition 533).

    • Résolution du problème d'installation YAML personnalisé avec une image différente (problème GitHub 613).

    • Calcul de la taille de snapshot fixe (problème GitHub 611).

    • Problème résolu : tous les installateurs Trident d'Astra pouvaient identifier Kubernetes ordinaire comme OpenShift (problème GitHub 639).

    • A corrigé l'opérateur Trident pour arrêter la réconciliation si le serveur d'API Kubernetes est inaccessible (problème GitHub 599).

Améliorations

  • Prise en charge ajoutée de unixPermissions Option pour les volumes de performance GCP-CVS.

  • Ajout de la prise en charge des volumes CVS optimisés pour l'évolutivité dans GCP dans la plage de 600 Gio à 1 Tio.

  • Améliorations liées à Kubernetes :

    • Prise en charge ajoutée de Kubernetes 1.22.

    • Compatibilité de l'opérateur Trident et du tableau Helm avec Kubernetes 1.22 (problème GitHub 628).

    • Ajout d'une image opérateur à tridentctl Commande images (problème GitHub 570).

Améliorations expérimentales

  • Ajout de la prise en charge de la réplication de volume dans ontap-san conducteur.

  • Ajout de la prise en charge de REST * TECH Preview* pour ontap-nas-flexgroup, ontap-san, et ontap-nas-economy pilotes.

Problèmes connus

Les problèmes connus identifient les problèmes susceptibles de vous empêcher d'utiliser le produit avec succès.

  • L'ASTRA Trident applique maintenant une blanc fsType (fsType="") pour les volumes qui n'ont pas le fsType Spécifiés dans leur classe de stockage. Lorsque vous utilisez Kubernetes 1.17 ou version ultérieure, Trident prend en charge l'option vide fsType Pour les volumes NFS. Pour les volumes iSCSI, vous devez définir le fsType Sur votre classe de stockage lors de l'application d'un fsGroup Utilisation d'un contexte de sécurité.

  • Lors de l'utilisation d'un système back-end pour plusieurs instances Trident d'Astra, chaque fichier de configuration back-end doit avoir un fichier différent storagePrefix Valeur pour les systèmes ONTAP back-end ou différente TenantName Pour les systèmes SolidFire back-end. Astra Trident ne peut pas détecter les volumes que d'autres instances d'Astra Trident ont créés. Tentative de création d'un volume existant sur un système back-end ONTAP ou SolidFire réussie, Astra Trident traite la création de volume comme une opération identente. Si storagePrefix ou TenantName n'en diffère pas, il peut y avoir des collisions de noms pour les volumes créés sur le même back-end.

  • Lors de l'installation d'Astra Trident (à l'aide de tridentctl Ou l'opérateur Trident) et à l'aide de tridentctl Pour gérer Astra Trident, vous devez vous assurer que KUBECONFIG la variable d'environnement est définie. Cela est nécessaire pour indiquer le cluster Kubernetes tridentctl doit travailler contre. Lorsque vous utilisez plusieurs environnements Kubernetes, assurez-vous que KUBECONFIG le fichier est fourni avec précision.

  • Pour réclamer de l'espace en ligne pour des volumes persistants iSCSI, le système d'exploitation sous-jacent du nœud worker peut nécessiter le passage des options de montage vers le volume. Ceci est vrai pour les instances RHEL/RedHat CoreOS qui requièrent le discard "option de montage"; Assurez-vous que le mountOption de mise au rebut est inclus dans votre[StorageClass^] pour prendre en charge le blocage en ligne.

  • Si vous possédez plusieurs instances d'Astra Trident par cluster Kubernetes, Astra Trident ne peut pas communiquer avec d'autres instances et ne peut pas détecter les autres volumes qu'ils ont créés, ce qui entraîne un comportement inattendu et incorrect si plusieurs instances s'exécutent dans un cluster. Il ne devrait y avoir qu'une seule instance d'Astra Trident par cluster Kubernetes.

  • Avec Astra Trident StorageClass Les objets sont supprimés de Kubernetes alors que Astra Trident est hors ligne, Astra Trident ne supprime pas les classes de stockage correspondantes de la base de données lorsqu'elle est remise en ligne. Vous devez supprimer ces classes de stockage à l'aide de tridentctl Ou l'API REST.

  • Si un utilisateur supprime un volume persistant provisionné par Astra Trident avant de supprimer le volume persistant correspondant, Astra Trident ne supprime pas automatiquement le volume de sauvegarde. Vous devez supprimer le volume via tridentctl Ou l'API REST.

  • ONTAP ne peut pas provisionner simultanément plusieurs FlexGroup, sauf si l'ensemble d'agrégats est unique pour chaque demande de provisionnement.

  • Lorsque vous utilisez Astra Trident sur IPv6, vous devez préciser managementLIF et dataLIF dans la définition du back-end entre crochets. Par exemple : [fd20:8b1e:b258:2000:f816:3eff:feec:0].

  • Si vous utilisez le solidfire-san Pilote avec OpenShift 4.5, assurez-vous que les nœuds de travail sous-jacents utilisent MD5 comme algorithme d'authentification CHAP.

Trouvez plus d'informations