Guide de l'administrateur Kubernetes sur l'interface utilisateur Web NetBackup™
- Présentation de NetBackup pour Kubernetes
- Déploiement et configuration de l'opérateur NetBackup Kubernetes
- Conditions préalables au déploiement de l'opérateur NetBackup Kubernetes
- Déploiement du package de service sur l'opérateur NetBackup Kubernetes
- Spécifications de port pour le déploiement de l'opérateur Kubernetes
- Mise à niveau de l'opérateur NetBackup Kubernetes
- Suppression de l'opérateur NetBackup Kubernetes
- Configuration du système de déplacement des données NetBackup Kubernetes
- Configuration automatisée de la protection NetBackup pour Kubernetes
- Configuration des paramètres pour l'opération de snapshot NetBackup
- Dépannage des serveurs NetBackup avec des noms courts
- Prise en charge du mécanisme de planification des pods du système de déplacement des données
- Validation de la classe de stockage d'accélérateur
- Déploiement de certificats sur l'opérateur NetBackup Kubernetes
- Gestion des biens Kubernetes
- Gestion des groupes intelligents Kubernetes
- Protection des biens Kubernetes
- Protection d'un groupe intelligent
- Suppression de la protection d'un groupe intelligent
- Configuration d'une planification de sauvegarde
- Configuration des options de sauvegardes
- Configuration des sauvegardes
- Configuration d'AIR (Auto Image Replication) et de la duplication
- Configuration des unités de stockage
- Prise en charge du mode volume
- Configuration d'une sauvegarde cohérente au niveau application
- Gestion des groupes d'images
- Protection des clusters gérés par Rancher dans NetBackup
- Récupération des biens Kubernetes
- À propos de la sauvegarde incrémentielle et de la restauration
- Activation de la sauvegarde basée sur l'accélérateur
- À propos de la prise en charge de l'accélérateur NetBackup pour les charges de travail Kubernetes
- Contrôle de l'espace disque réservé aux journaux de suivi sur le serveur principal
- Impact du comportement de la classe de stockage sur l'accélérateur
- À propos des nouvelles analyses forcées par l'accélérateur
- Avertissements et raison probable des échecs des sauvegardes avec accélérateur
- Activation du mode FIPS dans Kubernetes
- Résolution des problèmes liés à Kubernetes
- Erreur lors de la mise à niveau du serveur principal : échec de NBCheck
- Erreur lors de la restauration d'une image ancienne : l'opération échoue
- Erreur de l'API de récupération de volume persistant
- Erreur lors de la restauration : l'état final du travail affiche un échec partiel
- Erreur lors de la restauration sur le même espace de noms
- Pods du datamover dépassant la limite de ressource Kubernetes
- Erreur lors de la restauration : le travail échoue sur le cluster hautement chargé
- Le rôle Kubernetes personnalisé créé pour des clusters spécifiques ne peut pas afficher les travaux
- Openshift crée des PVC vides non sélectionnés lors de la restauration des applications installées à partir d'OperatorHub
- L'opérateur NetBackup Kubernetes ne répond plus si la limite de PID est dépassée sur le nœud Kubernetes
- Échec lors de la modification du cluster dans NetBackup Kubernetes 10.1
- Échec de la restauration à partir d'un snapshot pour les demandes PVC volumineuses
- Échec partiel de la restauration des PVC de mode fichier de l'espace de noms sur un système de fichiers différent
- Échec de la restauration à partir de la copie de sauvegarde avec une erreur d'incohérence d'image
- Vérifications de connectivité entre les serveurs principal/de médias NetBackup et les serveurs Kubernetes
- Erreur lors de la sauvegarde avec accélérateur lorsque l'espace disponible pour le journal de suivi est insuffisant
- Erreur lors de la sauvegarde avec accélérateur en raison de l'échec de la création de la demande PVC pour le journal de suivi
- Erreur lors de la sauvegarde avec accélérateur en raison d'une classe de stockage d'accélérateur non valide
- Une erreur se produit lors du démarrage du pod de journal de suivi
- Échec de la configuration de l'instance de système de déplacement des données pour l'opération de création de demande PVC pour le journal de suivi
- Erreur lors de la lecture de la classe de stockage du journal de suivi à partir du fichier configmap
Pods du datamover dépassant la limite de ressource Kubernetes
NetBackup contrôle le nombre total de travaux de sauvegarde en cours sur la charge de travail Kubernetes à l'aide des deux propriétés de limite de ressource. Dans NetBackup 10.0, les pods du datamover dépassent les limites de ressource de et de définies par cluster Kubernetes.
Scénario n° 1
La limite de ressource pour les travaux de sauvegarde à partir d'un snapshot par cluster Kubernetes est définie sur 1.
Les ID de travail 3020 et 3021 correspondent aux travaux parents de la sauvegarde à partir d'un snapshot. La création du pod du datamover et son processus de nettoyage font partie du cycle de vie du travail de sauvegarde.
L'ID de travail 3022 correspond au travail enfant dans le cadre duquel les données sont transférées du cluster vers l'unité de stockage.
En fonction du paramètre de limite de ressource, l'ID de travail 3021 reste en file d'attente alors que l'ID de travail 3022 est en cours d'exécution. Une fois l'ID de travail de sauvegarde 3022 terminé, l'ID de travail parent 3021 démarre.
Notez que l'ID de travail 3020 est toujours en cours, car le nettoyage du pod du datamover et le cycle de vie de l'ID de travail parent 3020 sont toujours en cours.
Scénario 2
À ce stade, il se peut que deux pods du datamover s'exécutent simultanément dans l'espace de noms de déploiement de l'opérateur NetBackup Kubernetes. En effet, le nettoyage du pod du datamover créé durant le travail ID 3020 n'est pas encore terminé, alors que le pod de datamover associé au travail ID 3021 a commencé à être créé.
Dans un environnement très actif où plusieurs travaux de sauvegarde à partir d'un snapshot sont déclenchés, la définition d'une valeur de limite de ressource faible peut conduire à une situation dans laquelle les travaux de sauvegarde restent en file d'attente la plupart du temps.
En définissant une valeur de limite de ressource plus élevée, il peut arriver que les pods du datamover dépassent la limite de ressource spécifiée. Cela peut entraîner une pénurie de ressources dans le cluster Kubernetes.
Les opérations de nettoyage sont traitées de façon séquentielle, parallèlement à l'exécution du travail de déplacement de données tel que l'ID de travail 3022. À cela, il faut ajouter le temps nécessaire au nettoyage de la ressource du datamover, si cela représente mieux le temps nécessaire à la sauvegarde des données des PVC/de l'espace de noms, ce qui retarde davantage l'achèvement des travaux.
Si la durée combinée du transfert de données et du nettoyage des ressources correspond à la durée du travail de sauvegarde, le travail de sauvegarde du volume persistant ou des données de l'espace de noms peut retarder l'achèvement du travail.
Action recommandée : vérifiez les ressources et les performances du système, et définissez la valeur de la limite de ressource en conséquence. Vous obtiendrez ainsi de meilleures performances pour tous les travaux de sauvegarde.