--- schema_version: "1" id: b050b641f88ae49b35daee3024ce7b047074bd983e55f3329f4a27be2031a56f title: Deel 7 – Validatie, tools en problemen oplossen collection: tableau version: next locale: nl-nl portal_url: https://docs.salesforce.com/tableau/next/nl-nl/guides/enterprise-deployment/edg_part7.md canonical_url: https://help.tableau.com/v0.0/guides/enterprise-deployment/nl-nl/edg_part7.htm source_site: help.tableau.com content_type: documentation content_hash: 1241027cf37b0fee2db01123cb7494d368dbe16f80c05928e6cf73e614cd0d18 description: "Part 7: validate, troubleshoot, and recover the enterprise deployment, including failover." --- [Doorgaan naar hoofdinhoud](#main-content) # Deel 7 – Validatie, tools en problemen oplossen **Opmerking:** Tableau werkt de Gids voor bedrijfsbrede implementatie niet langer bij. Hoewel we de hier beschreven referentiearchitectuur nog steeds aanbevelen als een geldig implementatiemodel voor Tableau Server in AWS, kunnen specifieke configuratieprocedures sinds de laatste update zijn gewijzigd. Vergelijk deze stappen altijd met de meest recente documentatie in de [Help van Tableau Server](https://help.tableau.com/current/server/nl-nl/get_started_server.htm) om de nauwkeurigheid te waarborgen. In dit onderwerp worden onder andere validatiestappen voor na de installatie en richtlijnen voor probleemoplossing besproken. ## Validatie van failover-systemen Nadat u uw implementatie hebt geconfigureerd, raden wij u aan eenvoudige failover-tests uit te voeren om de systeemredundantie te valideren. Wij raden u aan de volgende stappen uit te voeren om de failover-functionaliteit te valideren: 1. Sluit de eerste instantie van de onafhankelijke gateway (TSIG1) af. Al het binnenkomende verkeer moet via de tweede instantie van de onafhankelijke gateway (TSIG2) worden gerouteerd. 2. Start TSIG1 opnieuw op en sluit vervolgens TSIG2 af. Al het binnenkomende verkeer moet via TSIG1 worden gerouteerd. 3. Start TSIG2 opnieuw. 4. Sluit Tableau Server-knooppunt 1 af. Al het Vizportal-/toepassingsserviceverkeer wordt overgezet naar knooppunt 2. **Opmerking** Vanaf september 2022 was de hoge beschikbaarheid van knooppunt 1 in gevaar op bepaalde versies van Tableau Server 2021.4 en hoger. Clientverbindingen mislukken als knooppunt 1 niet beschikbaar is. Dit probleem is opgelost in de volgende onderhoudsverklaringen: \- 2021.4.15 en hoger \- 2022.1.11 en hoger \- 2023.1.3 en hoger Om ervoor te zorgen dat uw Tableau Server-installatie met ATR-activeringen een respijtperiode van 72 uur heeft na de initiële uitval van een knooppunt, installeert u een van deze versies of voert u een upgrade uit naar een van deze versies. Raadpleeg [Tableau Server HA met ATR heeft geen respijtperiode na de initiële knooppuntstoring](https://kb.tableau.com/articles/issue/tableau-server-ha-using-atr-does-not-have-a-grace-period-after-the-initial-node-failure?lang=nl-nl "Tableau KB-artikel over hoge beschikbaarheidsfout.") (in het Engels) in de Tableau Knowledgebase voor nadere informatie. 5. Start knooppunt 1 opnieuw en sluit knooppunt 2 af. Al het Vizportal-/toepassingsserviceverkeer wordt overgezet naar knooppunt 1. 6. Start knooppunt 2 opnieuw op. In deze context betekent ‘afsluiten’ of ‘opnieuw opstarten’ dat u het besturingssysteem of de virtuele machine uitschakelt zonder dat er eerst een poging is gedaan om de toepassing op een correcte manier af te sluiten. Het doel is om een hardware- of virtuele machinestoring te simuleren. De minimale validatiestap voor elke failovertest is om te verifiëren met een gebruiker en basisweergavebewerkingen uit te voeren. U krijgt mogelijk een browserfoutmelding 'Bad Request' wanneer u probeert in te loggen na een gesimuleerde mislukking. Het kan zijn dat u deze foutmelding zelfs krijgt als u de cache van uw browser wist. Dit probleem treedt vaak op wanneer de browser data van een eerdere IdP-sessie cachet. Als deze fout zich zelfs nadat u de lokale browsercache hebt gewist blijft voordoen, valideert u het Tableau-scenario door verbinding te maken met een andere browser. ## Automatisch herstel van eerste knooppunt Tableau Server versie 2021.2.4 en hoger bevatten een geautomatiseerd script voor initiële knooppuntherstel, `auto-node-recovery`, in de scriptdirectory (`/app/tableau_server/packages/scripts.`). Als er een probleem is met het eerste knooppunt en er redundante processen op knooppunt 2 zijn, is er geen garantie dat Tableau Server blijft werken. Tableau Server kan tot 72 uur na een initiële knooppuntstoring blijven draaien, voordat het uitvallen van de licentieservice gevolgen heeft voor andere processen. Als dat het geval is, kunnen uw gebruikers zich mogelijk nog steeds aanmelden en hun inhoud bekijken en gebruiken nadat het eerste knooppunt uitvalt. U kunt Tableau Server echter niet opnieuw configureren, omdat u geen toegang meer hebt tot de beheercontroller. Zelfs als Tableau Server is geconfigureerd met redundante processen, is het mogelijk dat Tableau Server niet meer functioneert nadat het eerste knooppunt uitvalt. Om een initiële knooppuntfout (knooppunt 1) te herstellen: 1. Meld u aan bij Tableau Server-knooppunt 2. 2. Navigeer naar de scriptdirectory: cd /app/tableau\_server/packages/scripts. 3. Voer de volgende opdracht uit om het script te starten: sudo ./auto-node-recovery -p node1 -n node2 -k Waar `` een door komma's gescheiden lijst (zonder spaties) is met de licentiesleutels voor uw implementatie. Als u geen toegang hebt tot uw licentiesleutels, ga dan naar de [Tableau-klantenportaal](http://customer.tableausoftware.com/?_fsi=v45oWMAM) om ze op te halen. Bijvoorbeeld: sudo ./auto-node-recovery -p node1 -n node2 -k TSB4-8675-309F-TW50-9RUS,TSNM-559N-ULL6-22VE-SIEN Het auto-node-recovery script voert ongeveer 20 stappen uit om services op knooppunt 2 te herstellen. Elke stap wordt in de terminal weergegeven terwijl het script vordert. Een meer gedetailleerde status wordt vastgelegd in `/data/tableau_data/logs/app-controller-move.log`. In de meeste omgevingen duurt het 35 tot 45 minuten om het script te voltooien. ### Problemen met het herstel van het eerste knooppunt oplossen Als het herstellen van een knooppunt mislukt, kan het handig zijn om het script interactief uit te voeren om bepaalde stappen in het proces toe te staan of te blokkeren. Als het script bijvoorbeeld halverwege het proces mislukt, kunt u het logbestand raadplegen, wijzigingen in de configuratie aanbrengen en het script vervolgens opnieuw uitvoeren. Als u de interactieve modus gebruikt, kunt u alle stappen overslaan totdat u bij de stap komt die is mislukt. Om in de interactieve modus te werken, voegt u de `-i`\-knop toe aan het scriptargument. ### Het defecte knooppunt opnieuw opbouwen Nadat u het script hebt uitgevoerd, voert knooppunt 2 alle services uit die zich voorheen op de uitgevallen knooppunt 1-host bevonden. Om het vierde knooppunt toe te voegen, moet u een nieuwe Tableau Server-host implementeren met het bootstrapbestand en deze configureren zoals u dat voor het oorspronkelijke knooppunt 2 hebt gedaan, zoals uiteengezet in Deel 4. Zie [Knooppunt 2 configureren](https://help.tableau.com/v0.0/guides/enterprise-deployment/nl-nl/edg_part4.htm#Configur2). ## switchto Switchto is een script van Tim waarmee u eenvoudig tussen Windows kunt schakelen. 1. Kopieer de volgende code in een bestand met de naam `switchto` in de home directory op uw bastionhost. #!/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. Werk de IP-adressen in het script bij, zodat ze worden toegewezen aan uw EC2-instanties en sla het bestand vervolgens op. 4. Pas machtigingen toe op het scriptbestand: sudo chmod +x switchto Gebruik: Als u naar een host wilt overstappen, voert u de volgende opdracht uit: `./switchto ` Om bijvoorbeeld over te schakelen naar knooppunt 1, voert u de volgende opdracht uit: `./switchto node1` ## Problemen met de onafhankelijke gateway van Tableau Server oplossen Het configureren van de onafhankelijke gateway, Okta, Mellon en SAML op Tableau Server kan een foutgevoelig proces zijn. De meest voorkomende oorzaak van fouten is een tekenreeksfout. Een afsluitende slash (`/`) op de Okta-URL's die tijdens de configuratie zijn opgegeven, kan bijvoorbeeld een SAML-assertiegerelateerde mismatch-fout veroorzaken. Dit is slechts één voorbeeld. U kunt op veel punten tijdens de configuratie een onjuiste tekenreeks invoeren in een van de toepassingen. ### Start de tableau-tsig-service opnieuw Begin (en beëindig) het oplossen van problemen altijd door de tableau-tsig-service op de onafhankelijke gateway-computers opnieuw te starten. Deze service kan snel opnieuw gestart worden en vaak wordt dan het bijgewerkte config-bestand geladen vanaf de Tableau Server. Voer de volgende opdrachten uit op de onafhankelijke gateway-computer: sudo su - tableau-tsig systemctl --user restart tsig-httpd exit ### Onjuiste tekenreeksen identificeren Als u een tekenreeksfout hebt gemaakt (fout bij het kopiëren/plakken, afgebroken tekenreeks, enz.), neem dan de tijd om alle instellingen die u hebt geconfigureerd door te nemen: - Okta-pre-verificatieconfiguratie. Controleer zorgvuldig de URL's die u hebt ingesteld. Let op de schuine strepen aan het einde. Controleer HTTP versus HTTPS. - Shell-geschiedenis voor SAML-configuratie op knooppunt 1. Bekijk de `tsm authentication saml configure`\-opdracht die u hebt uitgevoerd. Controleer of alle URL's overeenkomen met de URL's die u in Okta hebt geconfigureerd. Terwijl u de shellgeschiedenis van knooppunt 1 bekijkt, controleert u of de `tsm configuration set`\-opdrachten die de paden van de Mellon-configuratiebestanden opgeven, exact zijn toegewezen aan de bestandspaden waarnaar u de bestanden op de onafhankelijke gateway hebt gekopieerd. - Mellon-configuratie op onafhankelijke gateway. Controleer de shellgeschiedenis om te verifiëren of u de metadata hebt gemaakt met dezelfde URL-tekenreeks die u hebt geconfigureerd in Okta en Tableau SAML. Controleer of alle paden die zijn opgegeven in`/etc/mellon/conf.d/global.conf` kloppen en dat de `MellonCookieDomain` is ingesteld op uw hoofddomein, niet op uw Tableau-subdomein. ### Relevante logboeken zoeken Als alle tekenreeksen correct lijken te zijn ingesteld, moet u de logboeken controleren op fouten. Tableau Server registreert fouten en gebeurtenissen in tientallen verschillende logbestanden. De onafhankelijke gateway registreert ook data in een aantal lokale bestanden. Wij adviseren u om deze logboeken in de volgende volgorde te controleren. #### Logbestanden van de onafhankelijke gateway De standaardlocatie van de logbestanden van de onafhankelijke gateway is `/var/opt/tableau/tableau_tsig/logs`. - `access.log`: dit logboek is nuttig omdat het vermeldingen bevat die verbindingen van de Tableau Server-knooppunten weergeven. Als u gatewayfouten krijgt (start niet) wanneer u TSM probeert te starten en er geen vermeldingen in de `access.log` bestand, dan is er een kernprobleem met de connectiviteit. Controleer altijd als eerste stap de configuratie van de AWS-beveiligingsgroep. Een ander veelvoorkomend probleem is een typefout in `tsig.json`. Als u tsig.json bijwerkt, voer dan `tsm stop` uit voordat u `tsm topology external-services gateway update -c tsig.json` uitvoert. Nadat tsig.json is bijgewerkt, voert u `tsm start` uit. - `error.log`: dit logboek bevat onder andere SAML- en Mellon-fouten. #### Tableau Server tabadminagent-logbestand De bestanden `tabadminagent` (niet `tabadmincontroller`) zijn de enige relevante logbestanden voor het oplossen van problemen met de onafhankelijke gateway. U moet achterhalen waar de fouten van de onafhankelijke gateway zijn vastgelegd in `tabdminagent`. Deze fouten kunnen op elk knooppunt voorkomen, maar ze komen slechts op één knooppunt tegelijk voor. Voer de volgende stappen uit op elk knooppunt in het Tableau Server-cluster totdat u de tekenreeks 'onafhankelijk' vindt: 1. Zoek de locatie van het tabadminagent-logbestand op Tableau Server-knooppunten 1-4 in de EDG-installatie: cd /data/tableau\_data/data/tabsvc/logs/tabadminagent 2. Open het laatste logboek om dit te lezen: less tabadminagent\_nodeN.log (vervang N door knooppuntnummer) 3. Zoek naar alle instanties van 'Independent' en 'independent' door de volgende zoekreeks te gebruiken: /ndependent Zijn er geen overeenkomsten? Ga dan naar het volgende knooppunt en herhaal stappen 1-3. 4. Wanneer u een overeenkomst krijgt: `Shift + G` om naar beneden te gaan en de laatste foutmeldingen te zien. ### httpd stub-bestand opnieuw laden De onafhankelijke gateway beheert de configuratie van httpd voor Apache. Een algemene bewerking die vaak tijdelijke problemen oplost, is het opnieuw laden van het httpd-stubbestand dat de onderliggende Apache-configuratie bevat. Voer de volgende opdrachten uit op beide instanties van de onafhankelijke gateway. 1. Kopieer het stub-bestand naar httpd.conf: cp /var/opt/tableau/tableau\_tsig/config/httpd.conf.stub /var/opt/tableau/tableau\_tsig/config/httpd.conf 2. Start de onafhankelijke gateway-service opnieuw: sudo su - tableau-tsig systemctl --user restart tsig-httpd exit ### Logbestanden verwijderen of verplaatsen De onafhankelijke gateway registreert alle toegangsgebeurtenissen. U moet de opslag van logbestanden beheren om te voorkomen dat de schijfruimte vol raakt. Als uw schijf vol raakt, kan de onafhankelijke gateway geen toegangsgebeurtenissen meer schrijven en mislukt de service. Het volgende bericht wordt dan vastgelegd in error.log op de onafhankelijke gateway: (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 Deze mislukking zal resulteren in de status `DEGRADED` voor het`external` knooppunt wanneer u `tsm status -v` uitvoert op Tableau knooppunt 1. Het `external` knooppunt in de statusuitvoer verwijst naar de onafhankelijke gateway. U kunt dit probleem oplossen door de access.log-bestanden van de schijf te verwijderen of te verplaatsen. Access.log-bestanden worden opgeslagen op `/var/opt/tableau/tableau_tsig/logs`. Nadat u de schijf hebt gewist, start u de tableau-tsig-service opnieuw. ### Browserfouten **Bad Request**: een veelvoorkomende fout in dit scenario is de foutmelding 'Bad Request' (ongeldige aanvraag) van Okta. Dit probleem doet zich vaak voor wanneer de browser data van een eerdere Okta-sessie in de cache opslaat. Indien u bijvoorbeeld de Okta-toepassingen beheert als Okta-beheerder en vervolgens probeert toegang te krijgen tot Tableau met een ander Okta-account, kunnen sessiedata van de beheerdersdata de fout 'Bad Request' veroorzaken. Als deze fout zich blijft voordoen, zelfs nadat u de lokale browsercache hebt gewist, valideer het Tableau-scenario dan door verbinding te maken met een andere browser. Een andere oorzaak van de fout 'Bad Request' is een typefout in een van de vele URL's die u invoert tijdens het configuratieproces voor Okta, Mellon en SAML. Controleer of u al deze gegevens zonder fouten hebt ingevoerd. Vaak staat in het `error.log`\-bestand op de onafhankelijke gateway-server welke URL de fout veroorzaakt. **Not Found - The requested URL was not found on this server**: (Niet gevonden - De gevraagde URL is niet gevonden op deze server) Deze fout duidt op een configuratiefout. Als de gebruiker is geverifieerd met Okta en vervolgens deze foutmelding krijgt, hebt u de Okta-toepassing voor voorafgaande verificatie waarschijnlijk naar Tableau Server geüpload toen u SAML configureerde. Controleer of de metadata van de Okta Tableau Server-toepassing zijn geconfigureerd op Tableau Server, en niet de metadata van de Okta-toepassing voor voorafgaande verificatie. Andere stappen voor probleemoplossing: - Controleer de instellingen van de Okta-toepassing voor voorafgaande verificatie. Zorg ervoor dat het HTTP- en het HTTPS-protocol zijn ingesteld zoals aangegeven in dit onderwerp. - Start tsig-httpd opnieuw op beide onafhankelijke gateway-servers. - Controleer of `sudo apachectl configtest` 'Syntax OK' retourneert op beide onafhankelijke gateways. - Controleer of de testgebruiker aan beide toepassingen in Okta is toegewezen. - Controleer of kleverigheid is ingesteld op de Load Balancer en de bijbehorende doelgroepen. ### De TLS-verbinding van Tableau Server naar de onafhankelijke gateway verifiëren Gebruik de `wget`\-opdracht om de connectiviteit en toegang van Tableau Server naar de onafhankelijke gateway te verifiëren. Variaties op deze opdracht kunnen u helpen te achterhalen of certificaatproblemen verbindingsproblemen veroorzaken. Voer bijvoorbeeld deze `wget`\-opdracht uit om het housekeeping (HK)-protocol van Tableau Server te verifiëren: `wget https://ip-10-0-1-38.us-west-1.compute.internal:21319` Maak de URL met hetzelfde hostadres dat u hebt opgegeven voor de hostoptie van het bestand tsig.json. Geef het `https`\-protocol op en voeg de URL toe met de HK-poort `21319`. Om de connectiviteit te controleren en certificaatverificatie te negeren: `wget https://ip-10-0-1-38.us-west-1.compute.internal:21319 --no-check-certificate` Om te verifiëren of het root-CA-certificaat voor TSIG geldig is: `wget https://ip-10-0-1-38.us-west-1.compute.internal:21319 --ca-certificate=tsigRootCA.pem` Als Tableau kan communiceren, kunt u nog steeds inhoudsgerelateerde fouten krijgen, maar u krijgt geen verbindingsgerelateerde fouten. Als Tableau helemaal geen verbinding kan maken, controleer dan eerst de protocolconfiguratie in de firewall/beveiligingsgroepen. De inkomende regels voor de beveiligingsgroep waarin de onafhankelijke gateway zich bevindt, moeten bijvoorbeeld TCP 21319 toestaan.