NetWorker 19.9 : Les tâches de sauvegarde et de restauration vProxy ne démarrent pas, aucun vProxy n’est intercepté par le processus

Le workflow de sauvegarde des machines virtuelles indique que les machines virtuelles sont en attente d’exécution. Les détails de l’action de sauvegarde dans NetWorker Management Console affichent les éléments suivants :

Les sessions de restauration de machine virtuelle présentent le même symptôme. La session de restauration démarre, mais aucun vProxy n’est récupéré par la session. La tâche ne progresse pas et doit être annulée manuellement. Il n’y a aucun problème de disponibilité vProxy :

• Les vProxies sont affichés comme activés : Oui sous Devices-VMware> Proxies
• Il n’y a aucun message « vProxy n’est pas disponible » dans la fenêtre Alertes NMC.
• NetWorker Server peut résoudre correctement le nom de domaine complet (FQDN), le nom court et l’adresse IP vProxy.
• Le vProxy peut résoudre correctement le FQDN, le nom abrégé et l’adresse IP du NetWorker Server.
• Le port 9090 est ouvert entre le NetWorker Server et l’appliance vProxy. Chaque système peut communiquer avec l’autre via ce port.

Le serveur NetWorker est 19.9.0.0-19.9.0.3> ou 19.10.0.0.

Pour que la session de sauvegarde ou de restauration de la machine virtuelle puisse être établie, le NetWorker Server doit identifier une appliance vProxy disponible et s’y connecter.

Les optimisations de code ont été appliquées à NetWorker 19.9.0.4 et 19.10.0.1 via NETWORKER-85156.

Si le NetWorker Server est 19.9.0.3 ou version antérieure, effectuez une mise à niveau vers la version 19.9.0.4/19.10.0.1 ou une version ultérieure. Les appliances vProxy doivent également être mises à niveau vers la dernière version prise en charge par NetWorker. La mise à niveau de l’appliance vProxy garantit que les derniers correctifs de sécurité sont appliqués. Les nouvelles versions de vProxy regroupent également les bibliothèques ddboost mises à jour, la version VMware Virtual Disk Development Kit (VDDK) et les outils VMware.

Les téléchargements de packages NetWorker et vProxy sont disponibles via : https://www.dell.com/support/home/product-support/product/networker/overview

• NetWorker : procédure de mise à niveau de NetWorker et bonnes pratiques avant une mise à niveau
• NVP vProxy : Mise à niveau de l’appliance NVP vProxy à l’aide de nsrvproxy_mgmt
• NVP vProxy : Informations sur la version de NetWorker vProxy

Il existe plusieurs causes potentielles pour lesquelles un vProxy n’est pas sélectionné pour une opération de sauvegarde ou de restauration. Si le NetWorker Server est à la version 19.9.0.4, 19.10.0.1 ou ultérieure, procédez comme suit pour vous assurer qu’aucun autre problème n’empêche la sélection de vProxy :

État vProxy activé :

1. Dans NMC, accédez à Devices-VMware> Proxies, ou à partir de NetWorker Web User Interface (NWUI), accédez à Protection-VMware> Proxies.

2. Vérifiez que les vProxies sont activés. La colonne Enabled doit afficher Enabled : Oui :
   

    

   Remarque : Si le vProxy indique Activé : Non, modifiez le vProxy et sélectionnez Enabled : Oui

Résolution du nom :

Assurez-vous que l’environnement utilise le DNS (Domain Name System). Le serveur NetWorker, les vProxies, les systèmes Data Domain, les VMware vCenters et les hôtes VMware ESXi doivent tous utiliser des FQDN pouvant être résolus dans DNS. Les ressources configurées dans NetWorker doivent être ajoutées à l’aide de FQDN. Le FQDN, le nom court et les adresses IP doivent tous être résolus correctement. Tous les systèmes utilisant des entrées de fichier hosts doivent avoir des adresses IP, des noms de domaine complets et des alias corrects correctement remplis.

NVP vProxy : Dépannage de la connectivité réseau pour les opérations

de sauvegarde et de restaurationLa double pile (IPv4 et IPv6) n’est pas prise en charge par l’appliance vProxy, l’une ou l’autre doit être utilisée. Dans un environnement VMware compatible IPv6, les composants suivants ne doivent pas contenir d’entrées IPv4 inaccessibles dans le serveur DNS :

• • NetWorker server FQDN
  • FQDN de l’appliance vProxy
  • Data Domain FQDN
  • FQDN vCenter
  • ESXi FQDN

Les FQDN répertoriés ci-dessus doivent renvoyer uniquement les enregistrements AAAA du DNS et ne doivent pas contenir d’enregistrements IPv4 inaccessibles dans le DNS.

Voir: NVP vProxy : Sauvegardes de machines virtuelles en attente d’exécution dans un environnement utilisant des entrées de fichier hosts ou une configuration à double pile (IPv4 et IPv6)

1. À partir de l’appliance vProxy et du NetWorker Server, vérifiez que le FQDN, le nom abrégé et l’adresse IP peuvent être résolus pour chaque système correspondant :

   nslookup FQDN
   nslookup Short_Name
   nslookup IP_ADDRESS

   NetWorker : Pratiques d’excellence en matière de résolution de noms

2. Consultez le fichier /etc/hosts sur chaque système et assurez-vous, s’il existe des entrées de fichier d’hôte, qu’elles disposent de l’adresse IP correcte et des noms d’hôte correspondants.

   Remarque : Lorsque vous accédez à vProxy via SSH, vous devez vous connecter à l’aide du compte « admin ». L’accès root via SSH est désactivé par défaut.

Communication du port 9090 :

1. À partir du NetWorker Server, vérifiez que vous pouvez communiquer avec le port 9090 sur le vProxy :

   nsrports -t vProxy_Address -p 9090

2. À partir de l’appliance vProxy, confirmez que vous pouvez communiquer avec le port 9090 sur le NetWorker Server :

   curl -v NetWorker_Address:9090

   Remarque : Lorsque vous accédez à vProxy via SSH, vous devez vous connecter à l’aide du compte « admin ». L’accès root via SSH est désactivé par défaut.

Disponibilité vProxy :

1. Vérifiez la configuration du NetWorker Server daemon.raw pour toute disponibilité vProxy ou erreurs SSL.

   Linux : /nsr/logs/daemon.raw
   Windows. : C:\Program Files\EMC NetWorker\nsr\logs\daemon.raw

   NetWorker : utilisation de nsr_render_log

Erreurs de certificat et SSL

Si des erreurs SSL sont observées, le réenregistrement de l’appliance vProxy peut résoudre le problème : NVP vProxy : Comment désenregistrer/réenregistrer une appliance vProxy ?

Ajout à chaud de disponibilité.

Par défaut, une appliance vProxy dispose de 13 sessions Hot Add activées et de Network Block Device (NBD) désactivé.

Cela signifie que l’appliance vProxy doit résider sur un hôte ESXi qui a accès au datastore pour les machines virtuelles qu’elle sauvegarde. Si seul HotAdd est activé, vous pouvez activer temporairement NBD pour voir si la session de sauvegarde démarre. Si la sauvegarde démarre, cela suggère un problème d’accès Hot Add dans VMware. Ce problème peut être résolu en déployant des appliances vProxy sur des hôtes ESXi afin que chaque datastore VMware soit accessible par au moins une appliance vProxy. Il n’est pas recommandé d’utiliser NBD (lorsque cela est possible). De grandes quantités de sessions NBD peuvent entraîner une congestion sur le réseau de gestion ESXi. Pour plus d’informations sur l’évolutivité et les recommandations et limitations relatives à la connexion rapide/NBD, reportez-vous au Guide d’intégration de NetWorker VMware disponible ici : https://www.dell.com/support/home/product-support/product/networker/docs

HotAdd peut également être validé avec l’utilitaire ProxyHC : NVP-vProxy : Utilisation de l’outil de bilan de santé ProxyHC sur l’appliance vProxy.

Le vProxy manuel de l’action de sauvegarde est sélectionné :

L’action de sauvegarde contient un vProxy sélectionné manuellement :

Assurez-vous qu’il n’y a aucun problème (comme détaillé ci-dessus), accédez à ce vProxy ou avec sa disponibilité, testez un autre vProxy disponible ou définissez sur la sélection « Automatique ».