NetWorker Management Web UI (NWUI): guida alla valutazione e alla risoluzione dei problemi

Riepilogo: NetWorker Management Web UI (NWUI): guida alla valutazione e alla risoluzione dei problemi

Questo articolo si applica a Questo articolo non si applica a Questo articolo non è legato a un prodotto specifico. Non tutte le versioni del prodotto sono identificate in questo articolo.

Istruzioni

Come funziona NWUI

NetWorker Web User Interface (NWUI) utilizza le seguenti tecnologie: HTML5, Apache Tomcat, Spring Framework, Angular Framework e API (Application Programming Interface) REST (Representational State Transfer). L'applicazione NWUI può essere installata su sistemi operativi Linux o Windows. Può essere installata direttamente sul server NetWorker oppure su un host che non sia il server NetWorker.


                  Componenti di NWUI 


Sono presenti quattro componenti importanti:
Questi componenti possono trovarsi sullo stesso host o su host separati.
  • Front-end web:  questo è il livello di presentazione scritto in HTML5 e Angular Framework che presenta le operazioni NetWorker all'utente tramite un web browser. Il web browser è connesso ai processi di back-end dell'interfaccia utente.
  • Back-end dell'interfaccia utente:  l'applicazione di back-end è scritta in Spring Framework.  Utilizza Java e Apache Tomcat. La comunicazione tra front-end e back-end e tra back-end e server NetWorker avviene utilizzando chiamate API REST interne. Il processo NWUI utilizza l'istanza Apache Tomcat esistente sul server NetWorker oppure installa la propria istanza Apache Tomcat in caso di installazione remota dal server NetWorker.
  • Server NetWorker: il framework REST del server NetWorker è responsabile della ricezione delle chiamate API REST dal back-end dell'interfaccia utente e della connessione ai componenti principali del server NetWorker. Il bus dei messaggi RabbitMQ del server NetWorker viene utilizzato anche per l'interazione con nsrjobd.
  • AUTHC: il componente AUTHC di NetWorker viene utilizzato per tutte le esigenze di autenticazione. Il processo di richiesta contatta AuthC per verificare le credenziali; dopo la verifica, AuthC genera un token orario, firmato e crittografato. I componenti di NetWorker utilizzano questo token per verificare l'utente e autorizzare o meno un'operazione richiesta. In genere si tratta del server NetWorker, ma può essere installato su un host separato. 
La maggior parte delle comunicazioni utilizza l'API REST che consente l'interazione con le risorse identificate dagli indirizzi URI (Uniform Resource Identifier). Utilizza i verbi HTTP (HEAD, GET, PUT, POST, DELETE) per interagire con gli URI (Uniform Resource Identifier) in modo stateless. Queste chiamate API REST sono interne alle operazioni di NetWorker e NWUI.

a { text-decoration: none; color: #464feb; } tr th, tr td { border: 1px solid #e6e6e6; } tr th { background-color: #f5f5f5; } Da non confondere con l'API REST NetWorker, che consente operazioni personalizzate ed è documentata nella guida per gli sviluppatori dell'API REST NetWorker.

Risoluzione dei problemi

Definizione del problema

DETTAGLI DEL PROBLEMA
Al fine di generare una descrizione completa del problema, considerare le seguenti domande:
  • Quale operazione si sta tentando di eseguire e non funziona?
  • Questa operazione riesce quando viene avviata all'esterno di NWUI (ad esempio da NetWorker Management Console (NMC))?
  • Il problema è costante o intermittente?
  • Se è intermittente, esiste un fattore determinante?
  • In precedenza funzionava meglio e, in tal caso, sono state applicate modifiche note prima o dopo la comparsa del problema?
  • Quando è emerso il problema per la prima volta (e cosa è cambiato dall'insorgere del problema)?
  • Il problema si verifica solo in momenti di carico elevato dell'ambiente di backup?
  • Qual è l'ambito del problema (tutte le operazioni di ripristino o solo alcune, alcune schede non funzionano mentre altre non sono interessate)?
  • Quali azioni sono già state intraprese per risolvere il problema e quali conclusioni ne sono state tratte?

DETTAGLI DELL'AMBIENTE
  • Qual è la versione del server NetWorker e quale sistema operativo utilizza?
  • NWUI è installato sul server NetWorker o su un host separato?
    • Qual è la versione di NWUI, se installata su un host separato dal server NetWorker?
  • Quale pacchetto Java è installato sul server NWUI; è installato NetWorker Runtime Environment (NRE) oppure Oracle Java Runtime Environment (JRE)?
Authentication
L'autenticazione utilizza AUTHC come NetWorker Management Console e il comando nsrlogin . Per problemi di autenticazione, testare innanzitutto l'autenticazione sul server NetWorker per determinare se il problema riguarda NWUI o il server stesso. Se si utilizza AD o LDAP per l'autenticazione, eseguire innanzitutto un test con account NetWorker locali per verificare se il problema riguarda solo l'autenticazione esterna.

Un comando tipico utilizzato per testare se il processo di autenticazione funziona correttamente sul server NetWorker è il seguente:  
authc_mgmt -u [user name] -p [password] -e find-all-users.

Oppure:

Account NetWorker locale:

nsrlogin -u ACCOUNT -p PASSWORD
nsrlogout
Account esterno (AD/LDAP):
nsrlogin -t TENANT -d DOMAIN -u USERNAME -p PASSWORD
nsrlogout
 
La Guida alla configurazione della sicurezza di NetWorker contiene i dettagli completi sul funzionamento dell'autenticazione NetWorker, su come testarla e su come reimpostare una password, se necessario.

Se è necessaria una diagnosi di autenticazione ulteriore, vedere:  NetWorker: Come abilitare AUTHC DEBUG per la risoluzione dei problemi

Problemi di installazione
Per informazioni dettagliate su come installare NWUI e su quali registri consultare in caso di problemi di installazione, consultare il seguente articolo:
NetWorker Management Web UI (NWUI): Modalità di installazione                   

 

Problemi di back-end dell'interfaccia utente

I registri di back-end dell'interfaccia utente importanti sono:
Percorso Linux Percorso Windows (predefinito) Funzione
/nsr/authc/logs/catalina.log C:\Program Files\EMC NetWorker\nsr\authc-server\tomcat\logs\catalina.log Registrazione del server Tomcat dell'implementazione delle applicazioni.
/nsr/authc/logs/nwui.log C:\Program Files\EMC NetWorker\nsr\authc-server\tomcat\logs\nwui.log Registrazione del server delle applicazioni NWUI.
/nsr/logs/restapi/restapi.log C:\Program Files\EMC NetWorker\nsr\restapi\restapi.log Registrazione dell'API REST di NetWorker. NWUI comunica con il server NetWorker tramite l'API REST NetWorker. Per ulteriori informazioni su come diagnosticare quali funzioni dell'API REST vengono utilizzate e le relative risposte, vedere la sezione API REST in questo articolo.
/nsr/logs/daemon.raw C:\Program Files\EMC NetWorker\nsr\logs\daemon.raw Registrazione del server NetWorker.

Se il server NWUI si trova sul server NetWorker stesso, condivide la stessa istanza di Tomcat con NetWorker.
Se si fornisce un file di registro .raw al supporto, si consiglia di eseguire il rendering del file di registro sul sistema da cui ha origine. Questo garantisce che i timestamp vengano visualizzati nell'ora locale del server: NetWorker: Come utilizzare nsr_render_log

File di registro

Linux:

I processi eseguiti per il back-end dell'interfaccia utente sono:  /opt/nwui/bin/nwuictld jsvc.exec È possibile controllare se sono in esecuzione con il comando ps :
ps -ef | grep nwui
                  Output di ps che mostra il back-end di NWUI 
I registri sono qui:

Da server locale a server NetWorker:
  • /opt/nwui/logs
  • /nsr/authc/logs/
  • /nsr/logs/restapi/restapi.log
  • /nsr/logs/daemon.raw
  • /nsr/nwui/monitoring/app/logs/
Remoto (il server NWUI si trova su un host separato dal server NetWorker):
  • /opt/nwui/logs
  • /nsr/nwui/logs   
Il comando seguente può essere utilizzato per creare un file ZIP di questi registri
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
NOTA: a seconda che NWUI sia in un ambiente locale o remoto rispetto al server NetWorker, il comando precedente potrebbe indicare che alcune directory sono mancanti. In tal caso, è normale che il ciclo di apprendimento venga eseguito. Il nome host e la data non devono essere modificati, il comando precedente crea automaticamente il bundle con il nome host del server e la data corrente (AAAA-MM-GG).
Windows

Il processo di back-end di NWUI per Windows che deve essere eseguito è denominato nwuictld.exe:


                  tasklist che mostra il servizio NWUI 

È possibile gestirlo da services.msc:

                  console di servizio che mostra NWUI 
 

I registri sono qui:

Da server locale a server NetWorker
  • C:\Program Files\EMC NetWorker\nwui\logs\
  • C:\Program Files\EMC NetWorker\nsr\authc-server\logs
  • C:\Program Files\EMC NetWorker\nsr\restapi\restapi.log
  • C:\Program Files\EMC NetWorker\nsr\logs\daemon.raw
  • C:\Program Files\EMC NetWorker\nwui\monitoring\app\logs\
Remoto: 
  • 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
NOTA: i percorsi mostrati rappresentano il percorso di installazione predefinito di NetWorker. Se NetWorker è stato installato su un'altra unità o utilizza un percorso diverso, regolarlo di conseguenza.
 
Server NetWorker

Eseguire lo strumento nsrget sul server NetWorker per raccogliere i registri pertinenti:
NetWorker: come utilizzare lo strumento di data collection di NetWorker NSRGet

I registri più rilevanti dipendono dall'operazione che si sta tentando di eseguire da NWUI. Per ulteriori informazioni sui registri di NetWorker, vedere:
NetWorker: file e posizioni dei registri

Debug

Per eseguire il debug della comunicazione dell'API REST, modificare il livello di debug nel file logback.xml sul server NetWorker:

Windows (predefinito): C:\Program Files\EMC NetWorker\nsr\authc-server\tomcat\webapps\nwrestapi\WEB-INF\classes
Linux: /nsr/authc/webapps/nwrestapi/WEB-INF/classes


                  file logback 

Rimuovere i commenti dalle righe relative alla registrazione delle chiamate API. Questo fa sì che il livello di registrazione sia impostato su "trace" per le richieste e le risposte dell'API REST.

                  Impostazioni di debug 

Vedere: NetWorker: Come abilitare il debug dell'API REST

 

API REST

NWUI utilizza l'API REST per interfacciarsi con NetWorker. I registri di NWUI e dell'API REST mostrano le funzioni API e le risposte NetWorker, ma queste informazioni possono essere controllate direttamente nel browser. Questo metodo è utile per individuare discrepanze tra l'interfaccia utente e la CLI NetWorker o quando l'interfaccia utente non restituisce i risultati previsti. 

 

  1. Per accedere a NWUI, cliccare con il pulsante destro del mouse nella finestra del browser e selezionare Inspect.

Inspect

  1. Nella finestra "Inspect" del browser cliccare sulla scheda Network:

inspect nel browser, network

  1. Quando si eseguono funzioni in NWUI, le operazioni vengono visualizzate in Name. La colonna Status include lo stato di completamento dell'API REST: Richiesta e risposta dell'API 
  2. Cliccare sull'operazione che si desidera esaminare ulteriormente. Ad esempio, cliccando sulla funzione backups mostrata sopra, nella scheda Headers vengono visualizzati i seguenti dettagli:

Da qui l'URL di richiesta, il metodo di richiesta e il codice di stato sono tutti identificabili.

  1. Per visualizzare il payload della risposta, cliccare sulla scheda Responses.

 

Questo esempio mostra la risposta dell'API REST utilizzata per compilare la scheda Recover and Savesets dopo aver visualizzato i backup di Azure e selezionato un saveset per il ripristino.

Informazioni aggiuntive

Prodotti interessati

NetWorker

Prodotti

NetWorker, NetWorker Series
Proprietà dell'articolo
Numero articolo: 000010592
Tipo di articolo: How To
Ultima modifica: 19 dic 2025
Versione:  5
Trova risposta alle tue domande dagli altri utenti Dell
Support Services
Verifica che il dispositivo sia coperto dai Servizi di supporto.