Problèmes connus
Suggérer des modifications
PDF
Les problèmes connus identifient les problèmes susceptibles de vous empêcher d'utiliser cette version du produit avec succès.
Les problèmes connus suivants ont une incidence sur la version actuelle :
Les sauvegardes d'applications et les snapshots échouent si la classe volumesnapshotclass est ajoutée après la gestion d'un cluster
Les sauvegardes et les snapshots échouent avec un UI 500 error dans ce scénario. Pour contourner ce problème, actualisez la liste des applications.
La gestion d'un cluster avec Astra Control Center échoue lorsque le fichier kubeconfig contient plusieurs contextes
Vous ne pouvez pas utiliser un kubeconfig avec plus d'un cluster et un contexte. Voir la "article de la base de connaissances" pour en savoir plus.
Un pod de surveillance peut se bloquer dans les environnements Istio
Si vous couplez Astra Control Center avec Cloud Insights dans un environnement Istio, le telegraf-rs le pod peut se bloquer. Pour résoudre ce problème, procédez comme suit :
-
Trouvez le pod qui s'est écrasé :
kubectl -n netapp-monitoring get pod | grep Error
Vous devez voir les résultats similaires à ce qui suit :
NAME READY STATUS RESTARTS AGE telegraf-rs-fhhrh 1/2 Error 2 (26s ago) 32s
-
Redémarrez le module en panne, en le remplaçant
<pod_name_from_output>avec le nom du pod affecté :kubectl -n netapp-monitoring delete pod <pod_name_from_output>
Vous devez voir les résultats similaires à ce qui suit :
pod "telegraf-rs-fhhrh" deleted
-
Vérifiez que le pod a redémarré et qu'il n'est pas dans un état d'erreur :
kubectl -n netapp-monitoring get pod
Vous devez voir les résultats similaires à ce qui suit :
NAME READY STATUS RESTARTS AGE telegraf-rs-rrnsb 2/2 Running 0 11s
Les opérations de gestion des données d'application échouent avec l'erreur de service interne (500) lorsque Astra Trident est hors ligne
Si Astra Trident sur un cluster d'application est mis hors ligne (et reconnecté) et 500 erreurs de service internes sont rencontrées lors de la tentative de gestion des données d'application, redémarrez tous les nœuds Kubernetes du cluster d'application pour restaurer la fonctionnalité.
Les opérations de restauration sur place pour les classes de stockage ontap-nas échouent
Si vous effectuez une restauration sur place d'une application (restaurez-la dans son espace de noms d'origine) et que la classe de stockage de l'application utilise le ontap-nas-economy pilote, l'opération de restauration peut échouer si le répertoire de snapshot n'est pas masqué. Avant de remettre le produit en place, suivez les instructions de la section "Sauvegardez et restaurez les opérations ontap-nas" pour masquer le répertoire d'instantanés.
La restauration à partir d'une sauvegarde lors de l'utilisation du chiffrement à la volée Kerberos peut échouer
Lorsque vous restaurez une application à partir d'une sauvegarde vers un back-end de stockage utilisant le chiffrement à la volée Kerberos, l'opération de restauration peut échouer. Ce problème n'affecte pas la restauration à partir d'un snapshot ni la réplication des données d'application à l'aide de NetApp SnapMirror.
|
Lors de l'utilisation du chiffrement à la volée Kerberos avec les volumes NFSv4, vérifiez que les volumes NFSv4 utilisent les paramètres corrects. Reportez-vous à la section Configuration du domaine NetApp NFSv4 (page 13) du "Guide des améliorations et des bonnes pratiques de NetApp NFSv4". |
Les données de sauvegarde restent dans le compartiment après leur suppression pour les compartiments dont la règle de conservation a expiré
Si vous supprimez la sauvegarde immuable d'une application après l'expiration de la politique de conservation du compartiment, la sauvegarde est supprimée d'Astra Control, mais pas du compartiment. Ce problème sera corrigé dans une prochaine version.