Gids voor bedrijfsbrede implementatie van Tableau Server

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

2. Werk de IP-adressen in het script bij, zodat ze worden toegewezen aan uw EC2-instanties en sla het bestand vervolgens op.
3. 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 <target>

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 hetexternal 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 (Ongeldige aanvraag): 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 cachet. Als u bijvoorbeeld de Okta-toepassingen beheert als Okta-beheerder en vervolgens probeert toegang te krijgen tot Tableau met een ander Okta-account, kunnen sessiegegevens van de beheerdersgegevens de fout 'Bad Request' veroorzaken. Als deze fout zich zelfs nadat u de lokale browsercache hebt gewist blijft voordoen, probeer dan het Tableau-scenario te valideren 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 de configuratieprocessen van 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 geeft aan dat er sprake is van een van de vele configuratiefouten.

Als de gebruiker is geverifieerd met Okta en vervolgens deze foutmelding krijgt, is het waarschijnlijk dat u de Okta-toepassing vóór verificatie hebt geüpload naar Tableau Server toen u SAML configureerde. Controleer of u de Okta Tableau Server-toepassingsmetadata hebt geconfigureerd op Tableau Server, en niet de Okta pre-auth-toepassingsmetadata

Andere stappen voor probleemoplossing:

• Controleer de pre-auth-toepassingsinstellingen voor Okta. Zorg ervoor dat de HTTP- en HTTPS-protocollen 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.