Veritas NetBackup™ CloudPoint Guide d'installation et de mise à niveau

Échec de la connexion de l'agent CloudPoint au serveur CloudPoint si l'hôte d'agent est redémarré brusquement

Ce problème peut se produire si l'hôte sur lequel l'agent CloudPoint est installé est arrêté brusquement. Même après le redémarrage de l'hôte, l'agent ne parvient pas à établir une connexion avec le serveur CloudPoint et passe dans un état hors ligne.

Le fichier journal de l'agent contient l'erreur suivante :

Flexsnap-agent-onhost[4972] mainthread flexsnap.connectors.rabbitmq: error - channel 1 closed unexpectedly: (405) resource_locked - cannot obtain exclusive access to locked queue ' flexsnap-agent.a1f2ac945cd844e393c9876f347bd817' in vhost '/'

Ce problème se produit car la connexion RabbitMQ entre l'agent et le serveur CloudPoint ne se ferme pas, même en cas d'arrêt brusque de l'hôte d'agent. Le serveur CloudPoint ne peut pas détecter l'indisponibilité de l'agent tant que l'hôte d'agent n'a pas été interrogé. La connexion RabbitMQ reste ouverte jusqu'au prochain cycle d'interrogation. Si l'hôte d'agent redémarre avant le déclenchement de la prochaine interrogation, l'agent essaye d'établir une nouvelle connexion avec le serveur CloudPoint. Cependant, étant donné que la connexion RabbitMQ précédente existe déjà, la nouvelle tentative de connexion échoue avec une erreur de ressource verrouillée.

En raison de cet échec de connexion, l'agent est mis hors ligne et entraîne l'échec de toutes les opérations de restauration et de snapshot effectuées sur l'hôte.

Solution de contournement :

Redémarrez le service Veritas CloudPoint Agent sur l'hôte d'agent.

L'enregistrement de l'agent CloudPoint sur des hôtes Windows peut expirer ou échouer

Pour protéger des applications sous Windows, vous devez installer et enregistrer l'agent CloudPoint sur l'hôte Windows. L'enregistrement de l'agent peut parfois dépasser le délai habituel et expirer ou échouer.

Solution de contournement :

Pour résoudre ce problème, procédez comme suit :

Pour en savoir plus, reportez-vous aux sections suivantes :

Se reporter à Enregistrement de l'agent basé sur Windows.

Se reporter à Redémarrage de CloudPoint.

Reprise après incident lors de la perte du package de reprise après incident ou de la phrase de passe

Ce problème peut se produire en cas de perte du package DR ou de la phrase de passe.

Dans le cas d'une sauvegarde de catalogue, 2 packages de sauvegarde sont créés :

Le package DR contient les certificats UUID NetBackup et la base de données de catalogue comprend l'UUID. Lorsque vous procédez à une reprise après incident à l'aide du package DR, puis à la récupération de catalogue, le certificat UUID et l'UUID sont restaurés. Cela permet à NetBackup de communiquer avec CloudPoint, car l'UUID reste inchangé.

Cependant, l'opération de reprise après incident ne peut pas être réalisée en cas de perte du package DR ou de la phrase de passe. Vous ne pouvez récupérer le catalogue sans le package DR qu'après la réinstallation de NetBackup. Dans ce cas, un nouvel UUID est créé pour NetBackup et CloudPoint ne le reconnaît pas. Le mappage un-à-un de NetBackup et CloudPoint est perdu.

Solution de contournement :

Pour résoudre ce problème, vous devez mettre à jour le nouvel UUID NBU et le numéro de version une fois le serveur principal NetBackup créé.

Après avoir obtenu le l'UUID NBU et le numéro de version, exécutez la commande suivante sur l'hôte CloudPoint pour mettre à jour le mappage :

/cloudpoint/scripts/cp_update_nbuuid.sh -i <NBU UUID> -v <Version Number>

Le travail de snapshot aboutit, mais le travail de sauvegarde échoue avec l'erreur "Le certificat du serveur CloudPoint n'est pas valide ou n'existe pas. (9866)" lorsque le paramètre ECA_CRL_CHECK est désactivé sur le serveur principal.

Si le paramètre ECA_CRL_CHECK est configuré sur le serveur principal et désactivé, la même valeur doit être définie dans le fichier bp.conf de l'installation CloudPoint.

Prenons l'exemple d'une sauvegarde à partir d'un snapshot où le certificat externe utilisé pour la configuration de NetBackup est révoqué. Dans ce cas, si ECA_CRL_CHECK est défini sur DISABLE sur le serveur principal, définissez la même valeur dans le fichier bp.conf de l'installation CloudPoint. Si vous ne suivez pas cette procédure, l'opération de snapshot aboutira, mais l'opération de sauvegarde échouera avec l'erreur de certificat.

Se reporter à Configuration de la sécurité pour Azure et Azure Stack .

CloudPoint ne parvient pas à établir de connexion à l'aide de l'instance de cloud Windows sans agent

Erreur 1 : <Instance_name>: network connection timed out.

Cas 1 : message du journal du serveur CloudPoint :

WARNING - Cannot connect to the remote host. SMB Connection timeout
 <IP address> <user>

…

flexsnap.OperationFailed: Could not connect to the remote server 
<IP address>

Solution de contournement

Pour résoudre ce problème, procédez comme suit :

Cas 2 : message du journal du serveur CloudPoint :

WARNING - Cannot connect to the remote host. WMI Connection 
timeout <IP address> <user>

…

flexsnap.OperationFailed: Could not connect to the remote 
server <IP address>

Solution de contournement :

Pour résoudre ce problème, procédez comme suit :

Cas 3 : message du journal du serveur CloudPoint :

Exception while opening SMB connection, [Errno Connection error 
(<IP address>:445)] [Errno 113] No route to host.

Solution de contournement : vérifiez que l'instance de cloud est en cours d'exécution ou que son état n'est pas incohérent.

Cas 4 : message du journal du serveur CloudPoint :

Error when closing dcom connection: 'Thread-xxxx'"

Où xxxx correspond au nombre de threads.

Solution de contournement :

Pour résoudre ce problème, procédez comme suit :

Erreur 2 : <Instance_name>: Could not connect to the virtual machine.

Message du journal du serveur CloudPoint :

Error: Cannot connect to the remote host. <IP address> Access denied. 

Solution de contournement :

Pour résoudre ce problème, procédez comme suit :

Les opérations de cloud CloudPoint échouent sur un système RHEL si un pare-feu est désactivé

Les opérations CloudPoint échouent pour tous les plug-ins cloud pris en charge sur un système RHEL si un pare-feu est désactivé sur ce système lorsque les services CloudPoint sont en cours d'exécution. Ce problème de configuration réseau empêche CloudPoint d'accéder aux terminaux clients d'API REST du fournisseur cloud.

Solution de contournement

Le travail de sauvegarde à partir d'un snapshot et le travail d'indexation échouent avec les erreurs

Jun 10, 2021 2:17:48 PM - Error mqclient (pid=1054) SSL
Connection failed with string, broker:<hostname>
Jun 10, 2021 2:17:48 PM - Error mqclient (pid=1054) Failed SSL
handshake, broker:<hostname>
Jun 10, 2021 2:19:16 PM - Error nbcs (pid=29079) Invalid
operation for asset: <asset_id>
Jun 10, 2021 2:19:16 PM - Error nbcs (pid=29079) Acknowledgement
not received for datamover <datamover_id>

et/ou

Jun 10, 2021 3:06:13 PM - Critical bpbrm (pid=32373) from client
<asset_id>: FTL - Cannot retrieve the exported snapshot details
for the disk with UUID:<disk_asset_id>
Jun 10, 2021 3:06:13 PM - Info bptm (pid=32582) waited for full
buffer 1 times, delayed 220 times
Jun 10, 2021 3:06:13 PM - Critical bpbrm (pid=32373) from client
<asset_id>: FTL - cleanup() failed, status 6

Ce problème peut se produire lorsque l'accès entrant à CloudPoint sur les ports 5671 et 443 est bloqué au niveau du pare-feu du système d'exploitation (firewalld). La communication entre le conteneur du système de déplacement de données (utilisé pour les travaux de sauvegarde à partir d'un snapshot et les travaux d'indexation) et CloudPoint est donc bloquée. Le conteneur du système de déplacement de données ne peut donc pas démarrer la sauvegarde ou l'indexation.

Solution de contournement

Configurez les règles du pare-feu du système d'exploitation de façon à autoriser la connexion entrante sur les ports 5671 et 443.

La connexion sans agent échoue pour une machine virtuelle avec un message d'erreur.

La connexion sans agent échoue pour une machine virtuelle avec le message d'erreur suivant lorsque l'authentification par clé SSH d'une machine virtuelle est remplacée par une authentification par mot de passe via le portail :

User does not have the required privileges to establish an agentless connection

Ce problème se produit lorsque les autorisations ne sont pas correctement définies pour l'utilisateur dans le fichier sudoers, comme indiqué dans le message d'erreur ci-dessus.

Solution de contournement :

Résolvez le problème de fichier sudoers pour l'utilisateur en fournissant les autorisations requises pour exécuter les opérations sudo sans mot de passe.

La fonction CloudPoint échoue lorsque CloudPoint est déployé dans un sous-réseau privé (sans Internet)

Ce problème se produit lorsque CloudPoint est déployé dans un réseau privé dans lequel le pare-feu est activé ou l'adresse IP publique est désactivée. L'équipe en charge de la sécurité des informations du client n'accorde pas à la machine virtuelle un accès complet à Internet.

Solution de contournement

Activez les ports à partir de la ligne de commande du pare-feu à l'aide des commandes suivantes :

firewall-cmd --add-port=22/tcp

firewall-cmd --add-port=5671/tcp

firewall-cmd --add-port=443/tcp

La restauration d'un bien à partir d'une copie de sauvegarde échoue

Dans certains cas, une réinitialisation intermittente de la connexion se produit dans le conteneur Docker. La charge utile TCP envoyée par le serveur est alors supérieure à ce qu'indique la fenêtre du client. Le conteneur Docker supprime parfois le paquet SYN+ACK du nouveau protocole de connexion TCP. Pour autoriser ces paquets, utilisez l'option nf_conntrack_tcp_be_liberal.

Si nf_conntrack_tcp_be_liberal = 1, les paquets suivants sont autorisés :

Si nf_conntrack_tcp_be_liberal = 0, ils sont également considérés comme non valides et rejetés.

Solution de contournement

Pour résoudre le problème de la restauration à partir de la copie de sauvegarde, définissez l'option nf_conntrack_tcp_be_liberal = 1 sur le nœud sur lequel s'exécute le conteneur du datamover.

Utilisez la commande suivante pour définir la valeur de nf_conntrack_tcp_be_liberal :

sysctl -w net.netfilter.nf_conntrack_tcp_be_liberal=1

Certains pods de l'extension Kubernetes sont passés à l'état Terminé.

Solution de contournement

Désactivez l'extension Kubernetes.

Supprimez le pod d'écoute à l'aide de la commande suivante :

#kubectl delete pod flexnsap-listener-xxxxx -n <namespace>

Activez l'extension Kubernetes.

L'utilisateur ne peut pas personnaliser un plan de protection cloud

Solution de contournement

Créez un plan de protection avec la configuration souhaitée et attribuez-le au bien.

Le conteneur Podman ne démarre pas ou les conteneurs ne sont pas opérationnels après un redémarrage

Sur la plate-forme RHEL 8.x, le message d'erreur suivant s'affiche après le redémarrage d'un conteneur ou d'un ordinateur :

# podman restart flexsnap-coordinator 47ca97002e53de808cb8d0526ae033d4b317d5386ce085a8bce4cd434264afdf: "2022-02-05T04:53:42.265084989+00:00 Feb 05 04:53:42 flexsnap-coordinator flexsnap-coordinator[7] agent_container_health_check flexsnap.container_manager: INFO - Response: b'{""cause"":""that name is already in use"",""message"":""error creating container storage: the container name \\""flexsnap-agent.15bd0aea11164f7ba29e944115001d69\\"" is already in use by \\""30f031d586b1ab524511601aad521014380752fb127a9440de86a81b327b6777\\"". You have to remove that container to be able to reuse that name.: that name is already in use"",""response"":500}\n'"

Solution de contournement

Sous l'emplacement /var/lib/cni/networks/flexsnap-network/ sur le système de fichiers, recherchez un fichier contenant une entrée d'adresse IP mappée avec le conteneur qui n'a pas pu démarrer.

[ec2-user@ip-172-31-44-163 ~]$ ls -latr /var/lib/cni/networks/flexsnap-network/ total 16 -rwxr-x---. 1 root root 0 Jan 22 12:30 lock drwxr-xr-x. 4 root root 44 Jan 22 12:30 .. -rw-r--r--. 1 root root 70 Feb 4 14:47 10.89.0.150 -rw-r--r--. 1 root root 70 Feb 4 14:47 10.89.0.151 -rw-r--r--. 1 root root 70 Feb 4 14:47 10.89.0.152 -rw-r--r--. 1 root root 11 Feb 7 11:09 last_reserved_ip.0 drwxr-xr-x. 2 root root 101 Feb 7 11:13 . [ec2-user@ip-172-31-44-163 ~]$

Dans le répertoire ci-dessus, supprimez le fichier d'adresse IP dupliqué et effectuez les opérations suivantes :

Arrêtez le conteneur : #podman stop <container_name>

Démarrez le conteneur : #podman start <container_name>

Après le démarrage des services de démarrage/d'arrêt, les conteneurs CloudPoint, RabbitMQ et MongoDB sont toujours à l'état de démarrage

Les conteneurs flexsnap-mongodb et flexsnap-rabbitmq ne sont pas passés à l'état de fonctionnement. L'état du conteneur flexsnap-mongodb est le suivant :

[ec2-user@ip-172-31-23-60 log]$ sudo podman container inspect --format='{{json .Config.Healthcheck}}' flexsnap-mongodb {"Test":["CMD-SHELL","echo 'db.runCommand({ping: 1}).ok' | mongo --ssl --sslCAFile /cloudpoint/keys/cacert.pem --sslPEMKeyFile /cloudpoint/keys/mongodb.pem flexsnap-mongodb:27017/zenbrain --quiet"],"Interval":60,"Timeout":30000000000,"Retries":3} [ec2-user@ip-172-31-23-60 log]$ sudo podman container inspect --format='{{json .State.Healthcheck}}' flexsnap-mongodb {"Status":"starting","FailingStreak":0,"Log":null} [ec2-user@ip-172-31-23-60 log]$

Solution de contournement

Exécutez la commande #podman suivante depuis l'interface de ligne de commande :

[ec2-user@ip-172-31-23-60 log]$ sudo podman healthcheck run flexsnap-mongodb

[ec2-user@ip-172-31-23-60 log]$ sudo podman ps -a

CONTAINER ID  IMAGE                          COMMAND  CREATED      STATUS                  PORTS                      NAMES

fe8cf001032b  localhost/veritas/

  flexsnap-fluentd:10.0.0.0.9817         2 days ago    Up 45 hours ago      0.0.0.0:24224->24224/tcp  flexsnap-fluentd

2c00500c1ac6  localhost/veritas/

  flexsnap-mongodb:10.0.0.0.9817         2 days ago    Up 45 hours ago (healthy)                      flexsnap-mongodb

7ab3e248024a  localhost/veritas/

  flexsnap-rabbitmq:10.0.0.0.9817        2 days ago    Up 45 hours ago (starting)                     flexsnap-rabbitmq

[ec2-user@ip-172-31-23-60 log]$ sudo podman healthcheck run flexsnap-rabbitmq

[ec2-user@ip-172-31-23-60 log]$ sudo podman ps -a

CONTAINER ID  IMAGE                           COMMAND  CREATED       STATUS                   PORTS                   NAMES

fe8cf001032b  localhost/veritas/

  flexsnap-fluentd:10.0.0.0.9817        2 days ago    Up 45 hours ago          0.0.0.0:24224->24224/tcp  flexsnap-fluentd

2c00500c1ac6  localhost/veritas/

  flexsnap-mongodb:10.0.0.0.9817        2 days ago    Up 45 hours ago (healthy)                          flexsnap-mongodb

7ab3e248024a  localhost/veritas/

  flexsnap-rabbitmq:10.0.0.0.9817       2 days ago    Up 45 hours ago (healthy)                          flexsnap-rabbitmq

 

[ec2-user@ip-172-31-23-60 log]$ sudo podman container inspect --format='{{json .State.Healthcheck}}' flexsnap-mongodb

{"Status":"healthy","FailingStreak":0,"Log":

[{"Start":"2022-02-14T07:32:13.051150432Z","End":"2022-02-14T07:32:13.444636429Z","ExitCode":0,"Output":""}]}

[ec2-user@ip-172-31-23-60 log]$ sudo podman container inspect --format='{{json .State.Healthcheck}}' flexsnap-rabbitmq

{"Status":"healthy","FailingStreak":0,"Log":

[{"Start":"2022-02-14T07:32:46.537804403Z","End":"2022-02-14T07:32:47.293695744Z","ExitCode":0,"Output":""}]}

[ec2-user@ip-172-31-23-60 log]$

La génération du certificat échoue lors de l'enregistrement de CloudPoint auprès de NetBackup

À partir de la version 9.1.2 de CloudPoint, la génération de certificats NetBackup est synchronisée avec l'enregistrement dans l'API de registre de CloudPoint. Cela signifie que l'échec de la génération d'un certificat entraînera l'échec de l'enregistrement de CloudPoint auprès de NetBackup (ajout ou modification de l'entrée de serveur CloudPoint à partir de l'interface utilisateur Web). Ces certificats sont utilisés pour le datamover qui est lancé pour des opérations telles que la sauvegarde à partir d'un snapshot, la restauration à partir d'une sauvegarde, l'indexation (basée sur VxMS), etc. Si la génération du certificat échoue, ces travaux ne peuvent pas être exécutés. CloudPoint sur des machines virtuelles cloud ne peut donc pas se connecter à NetBackup sur des machines virtuelles de laboratoire, ce qui signifie que l'enregistrement échouera et que CloudPoint ne pourra pas être ajouté à NetBackup.

Solution de contournement

Pour ajouter CloudPoint dans ce type de situation, vous devez ignorer la génération du certificat sur CloudPoint en ajoutant l'entrée suivante dans le fichier /cloudpoint/flexsnap.conf :

[client_registration] skip_certificate_generation = yes

Le délai d'expiration par défaut de 6 heures ne permet pas la restauration d'une base de données de plus de 300 Go

Solution de contournement

La valeur du paramètre de délai d'expiration configurable peut être définie de façon à permettre la restauration d'une base de données plus volumineuse. La valeur du délai peut être spécifiée dans le fichier /etc/flexsnap.conf du conteneur flexsnap-coordinator. Il n'est pas nécessaire de redémarrer le conteneur de coordination. La valeur du délai d'expiration sera récupérée lors du prochain travail de restauration de la base de données.

L'utilisateur doit spécifier le délai d'expiration en secondes comme suit :

docker exec -it flexsnap-coordinator bash root@flexsnap-coordinator:/# cat /etc/flexsnap.conf [global] target = flexsnap-rabbitmq grt_timeout = 39600

Les informations du plug-in sont dupliquées si des tentatives précédentes d'enregistrement de CloudPoint ont échoué

Ce problème se produit uniquement lorsque CloudPoint a été déployé à l'aide du mécanisme de déploiement du marketplace. Lorsque les informations de plug-in sont ajoutées avant l'enregistrement, des informations de plug-in sont créées en double dans le fichier CloudPoint_plugin.conf.

Solution de contournement

Supprimez manuellement les informations de plug-in en double dans le fichier CloudPoint_plugin.conf.

Dans l'exemple suivant, l'entrée en double pour la configuration du plug-in GCP est visible (en gras) dans le fichier CloudPoint_plugin.conf :