--- schema_version: "1" id: 3459d5a4968766c04a5a75b15d6eb2ce24ac85f30d21068aa7cd31ef29b2affc title: Parte 7 - Convalida, strumenti e risoluzione dei problemi collection: tableau version: current locale: it-it portal_url: https://docs.salesforce.com/tableau/current/it-it/guides/enterprise-deployment/edg_part7.md canonical_url: https://help.tableau.com/current/guides/enterprise-deployment/it-it/edg_part7.htm source_site: help.tableau.com content_type: documentation content_hash: deecab92d0ce0dd259033793f66fda7c242ecc07069d4d2d8378ac861af8c429 description: "Part 7: validate, troubleshoot, and recover the enterprise deployment, including failover." --- [Passa al contenuto principale](#main-content) # Parte 7 - Convalida, strumenti e risoluzione dei problemi **Nota**: Tableau non aggiorna più la Guida alla distribuzione per le organizzazioni di grandi dimensioni. Sebbene sia comunque consigliabile utilizzare l’architettura di riferimento descritta in questo articolo come modello di distribuzione valido per Tableau Server in AWS, le procedure di configurazione specifiche potrebbero essere state modificate dall’ultimo aggiornamento. Per una maggiore accuratezza, confronta sempre queste procedure con la versione più recente della [Guida di Tableau Server](https://help.tableau.com/current/server/it-it/get_started_server.htm). Questo argomento include le fasi di convalida post-installazione e la guida alla risoluzione dei problemi. ## Convalida del sistema di failover Dopo aver configurato la distribuzione, ti consigliamo di eseguire semplici test di failover per convalidare la ridondanza del sistema. Ti consigliamo di eseguire le seguenti fasi per convalidare la funzionalità di failover: 1. Arresta la prima istanza del Gateway indipendente (TSIG1). Tutto il traffico in entrata deve essere instradato attraverso la seconda istanza del Gateway indipendente (TSIG2). 2. Riavvia TSIG1 e quindi arresta TSIG2. Tutto il traffico in entrata dovrebbe instradarsi attraverso TSIG1. 3. Riavvia TSIG2. 4. Arresta Tableau Server Nodo 1. Tutto il traffico del servizio Vizportal/Applicazione passerà al Nodo 2. **Nota:** a partire da settembre 2022, la disponibilità elevata del Nodo 1 risultava compromessa in determinate versioni di Tableau Server 2021.4 e versioni successive. Le connessioni dei client non riusciranno se il Nodo 1 è inattivo. Questo problema è stato risolto nelle seguenti versioni di manutenzione: \- 2021.4.15 e successive \- 2022.1.11 e successive \- 2023.1.3 e successive Per garantire che l’installazione di Tableau Server che utilizza le attivazioni ATR abbia un periodo di tolleranza di 72 ore dopo l’errore iniziale del nodo, installa o esegui l’upgrade a una di queste versioni. Per maggiori dettagli, consulta [Tableau Server con disponibilità elevata che utilizza ATR non ha un periodo di tolleranza dopo l’errore iniziale del nodo](https://kb.tableau.com/articles/issue/tableau-server-ha-using-atr-does-not-have-a-grace-period-after-the-initial-node-failure?lang=it-it "Articolo della Knowledge Base di Tableau sull’errore della disponibilità elevata.") nella Knowledge Base di Tableau. 5. Riavvia il Nodo 1 e arresta il Nodo 2. Tutto il traffico del servizio Vizportal/Applicazione passerà al Nodo 1. 6. Riavvia il Nodo 2. In questo contesto, l'"arresto" o il "riavvio" viene eseguito spegnendo il sistema operativo o la macchina virtuale senza prima tentare una chiusura regolare dell’applicazione. L’obiettivo è simulare un guasto dell’hardware o della macchina virtuale. La fase minima di convalida per ogni test di failover consiste nell’autenticarsi con un utente ed eseguire operazioni di visualizzazione di base. Potresti ricevere un errore del browser "Richiesta errata" quando tenti di accedere dopo un guasto simulato. Potresti visualizzare questo errore anche se svuoti la cache nel browser. Spesso questo problema si verifica quando il browser memorizza nella cache i dati della sessione precedente di IdP. Se questo errore persiste anche dopo aver cancellato la cache del browser locale, convalida lo scenario di Tableau connettendoti con un browser diverso. ## Ripristino automatizzato del nodo iniziale Tableau Server versione 2021.2.4 e successive includono uno script di ripristino automatizzato del nodo iniziale, `auto-node-recovery`, nella directory degli script (`/app/tableau_server/packages/scripts.`). Se si verifica un problema con il nodo iniziale e sono presenti processi ridondanti nel Nodo 2, non è garantito che Tableau Server continui a funzionare. Tableau Server può continuare a funzionare fino a 72 ore dopo un errore del nodo iniziale, prima che la mancanza del servizio di gestione licenze influisca su altri processi. In tal caso, gli utenti potrebbero continuare a effettuare l’accesso e a visualizzare e a utilizzare il loro contenuto dopo il problema nel nodo iniziale, ma non potrai riconfigurare Tableau Server perché non disporrai più dell’accesso al controller di amministrazione. Anche se configurato con processi ridondanti, Tableau Server potrebbe non continuare a funzionare dopo un problema nel nodo iniziale. Per ripristinare il nodo iniziale (Nodo 1) in seguito a un errore: 1. Accedi al Nodo 2 di Tableau Server. 2. Passa alla directory degli script: cd /app/tableau\_server/packages/scripts. 3. Esegui questo comando per avviare lo script: sudo ./auto-node-recovery -p node1 -n node2 -k Dove `` è un elenco separato da virgole (senza spazi) delle chiavi di licenza per la tua distribuzione. Se non hai accesso alle chiavi di licenza, visita il [Portale clienti di Tableau](http://customer.tableausoftware.com/?_fsi=v45oWMAM) per recuperarle. Ad esempio: sudo ./auto-node-recovery -p node1 -n node2 -k TSB4-8675-309F-TW50-9RUS,TSNM-559N-ULL6-22VE-SIEN Lo script auto-node-recovery eseguirà circa 20 passaggi per ripristinare i servizi sul Nodo 2. Ogni passaggio viene visualizzato nel terminale durante l’avanzamento dello script. Lo stato più dettagliato è registrato in `/data/tableau_data/logs/app-controller-move.log`. Nella maggior parte degli ambienti, il completamento dello script richiede dai 35 ai 45 minuti. ### Risoluzione dei problemi di ripristino del nodo iniziale Se il ripristino del nodo non riesce, potrebbe essere utile eseguire lo script in modo interattivo per consentire o meno specifici passaggi nel corso del processo. Ad esempio, se lo script non riesce a un certo punto del processo, puoi esaminare il file di log, apportare modifiche alla configurazione e quindi eseguire nuovamente lo script. Tramite l’esecuzione in modalità interattiva, puoi saltare tutti i passaggi fino a raggiungere quello che non è riuscito. Per eseguire lo script in modalità interattiva, aggiungi lo switch `-i` all’argomento script. ### Ricostruzione del nodo con errori Dopo aver eseguito lo script, il Nodo 2 eseguirà tutti i servizi che erano precedentemente sull’host Nodo 1 in cui si è verificato il problema. Per aggiungere il Nodo 4, devi distribuire un nuovo host Tableau Server con il file di bootstrap e configurarlo come hai fatto per il Nodo 2 originale, come specificato nella parte 4. Consulta [Configurare Nodo 2](https://help.tableau.com/current/guides/enterprise-deployment/it-it/edg_part4.htm#Configur2). ## switchto Switchto è uno script di Tim che semplifica il passaggio da una finestra all’altra. 1. Copia il codice seguente in un file denominato `switchto` nella home directory dell’host bastion. #!/bin/bash #------------------------------------------------------------------- # switchto # # Helper function to simplify SSH into the various AWS hosts when # following the Tableau Server Enterprise Deployment Guide (EDG). # # Place this file on your bastion host and provide your AWS hosts' # internal ip addresses or machine names here. # Example: readonly NODE1="10.0.3.187" # readonly NODE1="" readonly NODE2="" readonly NODE3="" readonly NODE4="" readonly PGSQL="" readonly PROXY1="" readonly PROXY2="" usage() { echo "Usage: switchto.sh \[ node1 | node2 | node3 | node4 | pgsql | proxy1 | proxy2 \]" } ip="" case $1 in node1) ip="$NODE1" ;; node2) ip="$NODE2" ;; node3) ip="$NODE3" ;; node4) ip="$NODE4" ;; pgsql) ip="$PGSQL" ;; proxy1) ip="$PROXY1" ;; proxy2) ip="$PROXY2" ;; ?) usage exit 0 ;; \*) echo "Unkown option $1." usage exit 1 ;; esac if \[\[ -z $ip \]\]; then echo "You must first edit this file to provide the ip addresses of your AWS hosts." exit 1 fi ssh -A ec2-user@$ip 3. Aggiorna gli indirizzi IP nello script per mapparli alle tue istanze EC2, quindi salva il file. 4. Applica le autorizzazioni al file di script: sudo chmod +x switchto Uso: Per passare a un host, esegui questo comando: `./switchto ` Ad esempio, per passare a Nodo 1, esegui questo comando: `./switchto node1` ## Risolvere i problemi del Gateway indipendente di Tableau Server La configurazione di Gateway indipendente, Okta, Mellon e SAML su Tableau Server può essere un processo soggetto a errori. La causa principale più comune è un errore della stringa. Ad esempio, una barra finale (`/` ) sugli URL Okta specificati durante la configurazione può causare un errore di mancata corrispondenza relativo all’asserzione SAML. Questo è solo un esempio. Durante la configurazione esistono molte opportunità di inserire una stringa errata in una qualsiasi delle applicazioni. ### Riavviare il servizio tableau-tsig Comincia (e concludi) la risoluzione dei problemi riavviando sempre il servizio tableau-tsig sui computer del Gateway indipendente. Il riavvio di questo servizio è rapido e spesso fa scattare il caricamento della configurazione aggiornata da Tableau Server. Esegui questo comando sul computer del Gateway indipendente: sudo su - tableau-tsig systemctl --user restart tsig-httpd exit ### Trovare le stringhe errate Se hai commesso un errore nella stringa (errore di copia/incolla, stringa troncata ecc.), dedica del tempo a esaminare ciascuna delle impostazioni che hai configurato: - Configurazione della preautenticazione Okta. Esamina attentamente gli URL che hai impostato. Guarda le barre finali. Verifica HTTP e HTTPS. - Cronologia della shell per la configurazione SAML sul Nodo 1. Esamina il comando `tsm authentication saml configure` che hai eseguito. Verifica che tutti gli URL corrispondano a quelli che hai configurato in Okta. Durante la revisione della cronologia della shell dal Nodo 1, verifica che i comandi `tsm configuration set` che specificano i percorsi dei file di configurazione di Mellon vengano mappati esattamente ai percorsi del Gateway indipendente in cui hai copiato i file. - Configurazione di Mellon sul Gateway indipendente. Esamina la cronologia della shell per verificare di aver creato i metadati con la stessa stringa URL che hai configurato in Okta e Tableau SAML. Verifica che tutti i percorsi specificati in`/etc/mellon/conf.d/global.conf` siano corretti e che il `MellonCookieDomain` sia impostato sul tuo dominio principale, non sul tuo sottodominio Tableau. ### Cercare nei registri pertinenti Se tutte le stringhe sembrano essere impostate correttamente, controlla i registri per individuare eventuali errori. Tableau Server registra errori ed eventi in decine di file di registro diversi. Il Gateway indipendente registra anche in un insieme di file locali. Ti consigliamo di ispezionare questi registri nel seguente ordine. #### File di registro del Gateway indipendente Il percorso predefinito dei file di registro del Gateway indipendente è `/var/opt/tableau/tableau_tsig/logs`. - `access.log`: questo registro è utile in quanto contiene delle voci che mostrano le connessioni dai nodi di Tableau Server. Se ricevi degli errori del gateway (non si avvia) quando provi ad avviare TSM e non ci sono voci nel file `access.log`, allora esiste un problema di connettività principale. Verifica sempre la configurazione del gruppo di sicurezza AWS come prima fase. Un altro problema comune è un errore di battitura in `tsig.json`. Se esegui un aggiornamento di tsig.json, esegui `tsm stop` prima di eseguire `tsm topology external-services gateway update -c tsig.json`. Dopo che tsig.json è stato aggiornato, esegui `tsm start`. - `error.log`: tra le altre voci, questo registro include gli errori di SAML e Mellon. #### File di registro tabadminagent di Tableau Server La serie di file `tabadminagent` (non `tabadmincontroller`) contiene gli unici file di registro pertinenti per la risoluzione degli errori relativi al Gateway indipendente. Devi trovare il luogo in cui sono stati registrati gli errori del Gateway indipendente su `tabdminagent`. Questi errori possono trovarsi su qualsiasi nodo, ma su un unico nodo. Esegui le seguenti fasi su ciascun nodo nel cluster di Tableau Server fino a trovare la stringa "independent": 1. Individua la posizione del file di registro tabadminagent sui nodi 1-4 di Tableau Server nella configurazione della Guida alla distribuzione: cd /data/tableau\_data/data/tabsvc/logs/tabadminagent 2. Apri l’ultimo registro per leggere: less tabadminagent\_nodeN.log (sostituisci N con il numero del nodo) 3. Cerca tutte le istanze di "Independent" e "independent", utilizzando la seguente stringa di ricerca: /ndependent Se non ci sono corrispondenze, vai al nodo successivo e ripeti le fasi 1-3. 4. Quando ottieni una corrispondenza: premi `Shift + G` per spostarti in basso e ottenere gli ultimi messaggi di errore. ### Ricaricare il file stub httpd Il Gateway indipendente gestisce la configurazione di httpd per Apache. Un’operazione generica che risolverà spesso problemi temporanei consiste nel ricaricare il file stub httpd che esegue il seeding della configurazione Apache sottostante. Esegui i seguenti comandi su entrambe le istanze del Gateway indipendente. 1. Copia il file stub su httpd.conf: cp /var/opt/tableau/tableau\_tsig/config/httpd.conf.stub /var/opt/tableau/tableau\_tsig/config/httpd.conf 2. Riavvia il servizio Gateway indipendente: sudo su - tableau-tsig systemctl --user restart tsig-httpd exit ### Eliminare o spostare i file di registro Il Gateway indipendente registra tutti gli eventi di accesso. Dovrai gestire l’archiviazione dei file di registro per evitare di riempire lo spazio su disco. Se il tuo disco si riempie, il Gateway indipendente non sarà in grado di scrivere gli eventi di accesso e il servizio fallirà. Il seguente messaggio verrà registrato in error.log sul Gateway indipendente: (28)No space left on device: \[client 10.0.2.209:54332\] AH00646: Error writing to /var/opt/tableau/tableau\_tsig/logs/access.%Y\_%m\_%d\_%H\_%M\_%S.log Questo errore comporterà uno stato `DEGRADED` per il nodo `external` durante l’esecuzione di `tsm status -v` su Tableau Nodo 1. Il nodo `external` nell’uscita di stato si riferisce al Gateway indipendente. Per risolvere questo problema, elimina o sposta i file access.log dal disco. I file Access.log vengono archiviati in `/var/opt/tableau/tableau_tsig/logs`. Dopo aver cancellato il disco, riavvia il servizio tableau-tsig. ### Errori del browser **Richiesta non valida**: un errore comune per questo scenario è l’errore "Richiesta non valida" di Okta. Spesso questo problema si verifica quando il browser memorizza nella cache i dati della sessione precedente di Okta. Ad esempio, se gestisci le applicazioni Okta come amministratore di Okta e quindi tenti di accedere a Tableau con un diverso account abilitato per Okta, i dati della sessione dai dati dell’amministratore potrebbero causare l’errore "Richiesta non valida". Se questo errore persiste anche dopo aver cancellato la cache del browser locale, prova a convalidare lo scenario di Tableau connettendoti con un browser diverso. Un’altra causa dell’errore "Richiesta non valida" è un errore di battitura in uno dei tanti URL che inserisci durante i processi di configurazione di Okta, Mellon e SAML. Verifica di averli inseriti tutti senza errori. Spesso il file `error.log` sul server Gateway indipendente specificherà quale URL sta causando l’errore. **Non trovato - L’URL richiesto non è stato trovato su questo server**: questo errore indica uno di diversi possibili errori di configurazione. Se l’utente è autenticato con Okta e riceve questo errore, probabilmente hai caricato l’applicazione di pre-autenticazione Okta in Tableau Server quando hai configurato SAML. Verifica di avere configurato in Tableau Server i metadati dell’applicazione Tableau Server Okta, anziché i metadati dell’applicazione di pre-autenticazione Okta Altre fasi per la risoluzione dei problemi: - Esamina le impostazioni dell’applicazione di pre-autenticazione Okta. Verifica che i protocolli HTTP e HTTPS siano impostati come specificato in questo argomento. - Riavvia tsig-httpd su entrambi i server del Gateway indipendente. - Verifica che `sudo apachectl configtest` restituisca "Sintassi OK" in entrambi i Gateway indipendenti. - Verifica che l’utente di test sia assegnato a entrambe le applicazioni in Okta. - Verifica che la permanenza sia impostata sul servizio di bilanciamento del carico e sui gruppi di destinazione associati ### Verificare la connessione TLS da Tableau Server al Gateway indipendente Utilizza il comando `wget` per verificare la connettività e l’accesso da Tableau Server al Gateway indipendente. Le variazioni di questo comando possono aiutarti a capire se i problemi di certificato stanno causando problemi di connessione. Ad esempio, esegui questo comando `wget` per verificare il protocollo di pulizia (HK) da Tableau Server: `wget https://ip-10-0-1-38.us-west-1.compute.internal:21319` Crea l’URL con lo stesso indirizzo host che hai incluso per l’opzione host del file tsig.json. Specifica il protocollo `https` e aggiungi l’URL con la porta HK `21319`. Per verificare la connettività e ignorare la verifica del certificato: `wget https://ip-10-0-1-38.us-west-1.compute.internal:21319 --no-check-certificate` Per verificare che il certificato radice dell’autorità di certificazione per TSIG sia valido: `wget https://ip-10-0-1-38.us-west-1.compute.internal:21319 --ca-certificate=tsigRootCA.pem` Se Tableau è in grado di comunicare, potresti comunque ricevere errori relativi al contenuto, ma non riceverai errori relativi alla connessione. Se Tableau non riesce a connettersi, inizia verificando la configurazione del protocollo nei gruppi firewall/di sicurezza. Ad esempio, le regole in entrata per il gruppo di sicurezza in cui risiede il Gateway indipendente devono consentire TCP 21319.