NetWorker Management Web UI : guide de tri et de dépannage (en anglais)
Résumé: NetWorker Management Web UI (NWUI) : guide de tri et de dépannage (en anglais)
Instructions
Fonctionnement de NWUI
NetWorker Web User Interface (NWUI) utilise les technologies suivantes : HTML5, Apache Tomcat, Spring Framework, Angular Framework et API REST. L’application NWUI peut être installée sur les systèmes d’exploitation Linux ou Windows. Elle peut être installée directement sur le serveur NetWorker ou sur un hôte autre que le serveur NetWorker.

Il y a quatre éléments importants. Ces composants peuvent se trouver sur le même hôte ou sur des hôtes distincts.
- Front-end Web : il s’agit de la couche de présentation écrite en HTML5 et en Angular Framework, qui présente les opérations NetWorker à l’utilisateur via un navigateur Web. Le navigateur Web est connecté aux processus back-end de l’interface utilisateur.
- Back-end de l’interface utilisateur : l’application back-end est écrite dans Spring Framework. Elle utilise Java et Apache Tomcat. La communication entre le front-end et le back-end et entre le back-end et le serveur NetWorker s’effectue à l’aide d’appels d’API REST internes. Le processus NWUI utilise l’instance Apache Tomcat existante sur le serveur NetWorker ou installe sa propre instance Apache Tomcat si elle est installée à distance à partir du serveur NetWorker.
- Serveur NetWorker : le framework REST du serveur NetWorker est chargé de recevoir les appels d’API REST du back-end de l’interface utilisateur et de les connecter aux composants principaux du serveur NetWorker. Le message bus RabbitMQ du serveur NetWorker est également utilisé pour l’interaction avec nsrjobd.
- AUTHC : le composant AUTHC de NetWorker est utilisé pour tous les besoins d’authentification. Le processus de demande contacte l’AUTHC pour vérifier les informations d’identification ; après vérification, AUTHC émet un jeton chiffré, basé sur le temps, signé et chiffré. Les composants NetWorker utilisent ce jeton pour authentifier l’utilisateur et autoriser ou non une opération demandée. Cela se fait généralement sur le serveur NetWorker, mais peut être installé sur un hôte séparé.
La plupart des communications utilisent l’API REST qui permet une interaction avec les ressources identifiées par les adresses URI (Uniform Resource Identifier). Elle utilise des verbes HTTP (HEAD, GET, PUT, POST, DELETE) pour interagir avec les URI en mode sans état.
Ces appels d’API REST sont internes aux opérations NetWorker et NWUI. Ne les confondez pas avec l’API REST NetWorker, qui permet des opérations personnalisées et est documentée dans le NetWorker REST API Developer Guide.
Dépannage
Définition du problème
- Détails du problème : Afin de générer une description complète du problème, posez-vous les questions suivantes :
- Quelle opération est en cours d’exécution et ne fonctionne pas ?
- Cette opération fonctionne-t-elle lorsqu’elle est lancée en dehors de NWUI (par exemple : à partir de NetWorker Management Console [NMC]) ?
- Le problème est-il constant ou intermittent ?
- S’il est intermittent, y a-t-il un déclencheur connu ?
- Cette opération fonctionnait-elle mieux auparavant et, le cas échéant, quelles modifications connues ont été apportées avant et après l’apparition du problème ?
- Quand le problème s’est-il produit pour la première fois (et qu’est-ce qui a changé depuis l’apparition du problème) ?
- Le problème se produit-il uniquement en cas de charge importante sur l’environnement de sauvegarde ?
- Quelle est l’étendue du problème (toutes les opérations de récupération ou certaines opérations de récupération, certains onglets ne fonctionnent pas tandis que d’autres ne sont pas affectés) ?
- Quelles actions ont déjà été tentées pour corriger le problème et quelles conclusions en ont été tirées ?
- Détails de l’environnement :
- Quelle est la version et la plateforme du système d’exploitation du serveur NetWorker ? NetWorker : méthodes d’identification de la version du logiciel NetWorker
- NetWorker Web User Interface (NWUI) est-elle installée sur le serveur NetWorker ou sur un hôte distinct ?
- S’il est installé sur un hôte distinct du NetWorker Server, quelle est la version du serveur NWUI ?
- Le serveur NWUI utilise-t-il le NetWorker Server local pour l’authentification (AUTHC) ou un serveur AUTHC distinct est-il utilisé : NetWorker : Identification du serveur d’authentification utilisé par NMC et NWUI
- Quel package Java est installé sur le serveur NWUI ; NetWorker Runtime Environment (NRE) ou Oracle Java Runtime Environment (JRE) ?
- Problèmes courants :
- Problèmes d’authentification : L’authentification utilise AUTHC de la même manière que NetWorker Management Console et la commande
nsrlogin.
Pour les problèmes d’authentification, commencez par tester l’authentification sur le serveur NetWorker pour déterminer si le problème concerne NWUI ou le serveur lui-même. Si vous utilisez AD ou LDAP pour l’authentification, commencez par effectuer un test avec les comptes NetWorker locaux pour vérifier si le problème affecte uniquement l’authentification externe.
Voici une commande classique utilisée pour tester que le processus d’authentification fonctionne comme prévu sur le serveur NetWorker :
- Problèmes d’authentification : L’authentification utilise AUTHC de la même manière que NetWorker Management Console et la commande
authc_mgmt -u [user name] -p [password] -e find-all-users.
nsrlogin -u ACCOUNT -p PASSWORD nsrlogout
nsrlogin -t TENANT -d DOMAIN -u USERNAME -p PASSWORD nsrlogout
Si un diagnostic d’authentification plus approfondi est nécessaire, consultez : NetWorker : activation du DÉBOGAGE AUTHC à des fins de dépannage (en anglais)
-
- Problèmes d’installation : Pour plus d’informations sur l’installation de NWUI et sur les journaux à consulter en cas de problème lors de l’installation, voir l’article suivant : NetWorker Management Web UI (NWUI) : procédure d’installation
- Problèmes back-end de l’interface utilisateur : Les principaux journaux back-end de l’interface utilisateur sont les suivants :
| Chemin Linux | Chemin Windows (par défaut) | Fonction |
/nsr/authc/logs/catalina.log |
C:\Program Files\EMC NetWorker\nsr\authc-server\tomcat\logs\catalina.log |
Journalisation du serveur Tomcat et journalisation du déploiement d’applications |
/nsr/authc/logs/nwui.log |
C:\Program Files\EMC NetWorker\nsr\authc-server\tomcat\logs\nwui.log |
Journalisation du serveur d’applications NWUI |
/nsr/logs/restapi/restapi.log |
C:\Program Files\EMC NetWorker\nsr\restapi\restapi.log |
NWUI communique avec le serveur NetWorker à l’aide de l’API REST NetWorker. Voir la section API REST de cet article pour savoir comment diagnostiquer les fonctions de l’API REST utilisées, ainsi que la réponse correspondante. |
/nsr/logs/daemon.raw |
C:\Program Files\EMC NetWorker\nsr\logs\daemon.raw |
Journalisation de NetWorker Server |
Si le serveur NWUI se trouve sur le NetWorker Server lui-même, il partage la même instance tomcat avec NetWorker.
Si vous fournissez un .raw au support, il est conseillé de le générer sur le système d’origine. Cela permet d’afficher les horodatages selon le fuseau horaire local du serveur : NetWorker : utilisation de nsr_render_log
Fichiers journaux :
Linux :
Les processus qui s’exécutent pour le back-end de l’interface utilisateur sont les suivants : code>/opt/nwui/bin/nwuictld et jsvc.exec. Pour vérifier s’ils sont en cours d’exécution, vous pouvez utiliser la commande ps suivante :
ps -ef | grep nwui

- Local vers NetWorker Server :
/opt/nwui/logs/nsr/authc/logs//nsr/logs/restapi/restapi.log/nsr/logs/daemon.raw/nsr/nwui/monitoring/app/logs/
- Distant (le serveur NWUI se trouve sur un hôte distinct du NetWorker Server) :
/opt/nwui/logs/nsr/nwui/logs
La commande suivante peut être utilisée pour créer une .zip de ces logs.
tar cvzfP /tmp/$(hostname)_$(date -I).tgz /opt/nwui/logs /nsr/nwui/logs /nsr/authc/logs /nsr/logs/daemon.raw /nsr/logs/restapi /nsr/nwui/monitoring/app/logs/ ; chmod 777 /tmp/$(hostname)_$(date -I).tgz ; ls -lth /tmp/$(hostname)_$(date -I).tgz
Windows
Le processus back-end NWUI Windows qui doit être en cours d’exécution est appelé nwuictld.exe :

Vous pouvez gérer cela à partir de services.msc:

Les journaux sont ici :
- Local vers NetWorker Server :
C:\Program Files\EMC NetWorker\nwui\logs\C:\Program Files\EMC NetWorker\nsr\authc-server\logsC:\Program Files\EMC NetWorker\nsr\restapi\restapi.logC:\Program Files\EMC NetWorker\nsr\logs\daemon.rawC:\Program Files\EMC NetWorker\nwui\monitoring\app\logs\
- Distant :
C:\Program Files\EMC NetWorker\nwui\logs%LOCALAPPDATA%\TempNetWorker_Management_Web_UI_Server_[TIMESTAMP].log%LOCALAPPDATA%\TempNetWorker_Management_Web_UI_Server_[TIMESTAMP]_0_MCUI.log
Serveur NetWorker
Exécutez la commande NSRGET sur le serveur NetWorker pour collecter les logs pertinents : NetWorker : Utilisation de l’outil
de collecte de données NSRGet NetWorkerLes journaux les plus pertinents dépendent de l’opération tentée à partir de NWUI. Pour plus d’informations sur les logs NetWorker, reportez-vous à : NetWorker : Fichiers journaux et emplacements
Débogage
Les niveaux de journalisation NWUI sont définis dans le fichier suivant :
- Windows (par défaut) :
C:\Program Files\EMC NetWorker\nsr\authc-server\tomcat\webapps\nwui\WEB-INF\classes\logback.xml - Linux :
/nsr/authc/webapps/nwui/WEB-INF/classes/logback.xml
- Augmentez le
maxFileSizefrom20MBto100MB - Modifiez le paramètre
root levelfromINFOtoDEBUG
- Redémarrez le service NWUI :
- Linux :
systemctl restart nwui - Windows (PowerShell) :
net stop nwui ; net start nwui
Navigateur Web Inspecter la console.
NWUI utilise des fonctions d’API et des réponses NetWorker, mais ces informations peuvent également être vérifiées directement dans le navigateur. Cette méthode est utile pour trouver des divergences entre les interfaces utilisateur et l’interface de ligne de commande NetWorker ou lorsque l’interface utilisateur ne renvoie pas les résultats attendus.
- Lors de l’accès à NWUI, cliquez avec le bouton droit de la souris dans la fenêtre du navigateur et sélectionnez Inspect.
- Dans la fenêtre « Inspect » du navigateur, cliquez sur l’onglet Network :
- Les opérations s’affichent sous Nom lors de l’exécution de fonctions dans NWUI. La colonne Status indique l’état d’exécution de l’API REST : Demande et réponse de l’API
- Cliquez sur l’opération que vous souhaitez examiner plus en détail. Par exemple, en cliquant sur la fonction de sauvegarde illustrée ci-dessus, les informations suivantes s’affichent dans l’onglet Headers :

L’URL de la demande, la méthode de la demande et le code d’état sont tous identifiables.
- Pour afficher la charge utile de la réponse, cliquez sur l’onglet Responses.
Cet exemple montre la réponse de l’API REST utilisée pour renseigner l’onglet Recover and Savesets après avoir parcouru les sauvegardes Azure et sélectionné un jeu de sauvegarde à restaurer.