Handbuch zu Tableau Server Enterprise-Bereitstellung

Switchto

Switchto ist ein Shell-Skript von Tim, das den Wechsel zwischen Fenstern erleichtert.

1. Kopieren Sie den folgenden Code in eine Datei namens switchto im Basisverzeichnis auf Ihrem Bastion-Host.

#!/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. Ändern Sie die IP-Adressen im Skript so, dass sie mit Ihren EC2-Instanzen übereinstimmen, und speichern Sie dann die Datei.
3. Wenden Sie Berechtigungen auf die Skriptdatei an:

sudo chmod +x switchto

Verwendung:

Um zu einem Host umzuschalten, führen Sie den folgenden Befehl aus:

./switchto <target>

Wenn Sie zum Beispiel zum Knoten 1 umschalten möchten, führen Sie den folgenden Befehl aus:

./switchto node1

Fehlerbehebung beim Tableau Server Independent Gateway

Das Konfigurieren von Independent Gateway, Okta, Mellon und SAML in Tableau Server kann ein fehleranfälliger Prozess sein. Die häufigste Fehlerursache sind Zeichenfolgenfehler. So kann zum Beispiel ein nachgestellter Schrägstrich (/) in den Okta-URLs, die während der Konfiguration angegeben wurden, einen Nichtübereinstimmungsfehler in Bezug auf SAML-Assertion verursachen. Dies ist nur ein Beispiel. Es gibt viele Möglichkeiten während der Konfiguration, bei einer der Anwendungen eine falsche Zeichenfolge einzugeben.

Neustarten des tableau-tsig-Dienstes

Beginnen (und beenden) Sie die Fehlerbehebung immer mit einem Neustart des tableau-tsig-Dienstes auf den Independent Gateway-Computern. Das Neustarten dieses Dienstes geht schnell und bewirkt meist, dass die aktualisierte Konfiguration von Tableau Server geladen wird.

Führen Sie die folgenden Befehle auf dem Independent Gateway-Computer aus:

sudo su - tableau-tsig

systemctl --user restart tsig-httpd

exit

Auffinden falscher Zeichenfolgen

Wenn Sie einen Zeichenfolgenfehler gemacht haben (Fehler beim Kopieren/Einfügen, Zeichenfolge abgeschnitten usw.), nehmen Sie sich die Zeit, alle von Ihnen konfigurierten Einstellungen durchzugehen:

• Die Konfiguration der Okta-Vorauthentifizierung. Überprüfen Sie sorgfältig die von Ihnen festgelegten URLs. Suchen Sie nach abschließenden Schrägstrichen. Prüfen Sie auf HTTP anstelle von HTTPS.
• Shell-Verlauf für die SAML-Konfiguration auf Knoten 1. Überprüfen Sie den Befehl tsm authentication saml configure, den Sie ausgeführt haben. Stellen Sie sicher, dass alle URLs mit denen übereinstimmen, die Sie in Okta konfiguriert haben. Vergewissern Sie sich beim Überprüfen des Shell-Verlaufs von Knoten 1, dass die tsm configuration set-Befehle, die die Mellon-Konfigurationsdateipfade angeben, exakt mit den Dateipfaden übereinstimmen, in die Sie die Dateien in Independent Gateway kopiert haben.
• Die Mellon-Konfiguration in Independent Gateway. Überprüfen Sie den Shell-Verlauf, um sicherzustellen, dass Sie die Metadaten mit der gleichen URL-Zeichenfolge erstellt haben, die Sie in Okta und Tableau-SAML konfiguriert haben. Stellen Sie sicher, dass alle Pfade, die in /etc/mellon/conf.d/global.conf angegeben sind, korrekt sind und dass die MellonCookieDomain auf Ihre Stammdomäne festgelegt ist, nicht auf Ihre Tableau-Unterdomäne.

Durchsuchen relevanter Protokolle

Wenn alle Zeichenfolgen korrekt zu sein scheinen, sollten Sie die Protokolle auf Fehler überprüfen.

Tableau Server protokolliert Fehler und Ereignisse in Dutzenden verschiedener Protokolldateien. Auch Independent Gateway protokolliert in einer Reihe lokaler Dateien. Wir empfehlen, diese Protokolle in der folgenden Reihenfolge zu überprüfen.

Independent Gateway-Protokolldateien

Der standardmäßige Speicherort der Protokolldateien des Independent Gateway lautet /var/opt/tableau/tableau_tsig/logs.

• access.log: Dieses Protokoll ist insofern nützlich, als es Einträge enthält, die Verbindungen von den Tableau Server-Knoten anzeigen. Wenn Sie bei dem Versuch, TSM zu starten, Gateway-Fehler erhalten ("...startet nicht"), und es keine Einträge in der Datei access.log gibt, liegt ein grundlegendes Konnektivitätsproblem vor. Überprüfen Sie als ersten Schritt immer die Konfiguration der AWS-Sicherheitsgruppe. Ein weiteres häufiges Problem ist ein Schreibfehler in tsig.json. Wenn Sie in tsig.json eine Änderung vornehmen, führen Sie tsm stop aus, bevor Sie tsm topology external-services gateway update -c tsig.json ausführen. Nachdem tsig.json aktualisiert wurde, führen Sie tsm start aus.
• error.log: Neben anderen Einträgen werden in diesem Protokoll auch SAML- und Mellon-Fehler verzeichnet.

Protokolldatei von Tableau Server-tabadminagent

Die tabadminagent-Dateien (nicht tabadmincontroller) sind die einzigen relevanten Protokolldateien für die Behebung von Fehlern im Zusammenhang mit Independent Gateway.

Sie müssen herausfinden, wo Independent Gateway-Fehler in tabdminagent protokolliert wurden. Diese Fehler können auf jedem beliebigen Knoten, aber nur auf einem einzigen Knoten auftreten. Führen Sie die folgenden Schritte auf jedem Knoten im Tableau Server-Cluster durch, bis Sie die Zeichenfolge "independent" finden:

1. Suchen Sie den Speicherort der tabadminagent-Protokolldatei auf den Tableau Server-Knoten 1–4 im EDG-Setup:

   cd /data/tableau_data/data/tabsvc/logs/tabadminagent

2. Öffnen Sie das neueste Protokoll, in dem Folgendes steht:

   less tabadminagent_nodeN.log

   (Ersetzen Sie "N" durch die Knotennummer.)

3. Suchen Sie nach allen Stellen, an denen "Independent" oder "independent" steht, indem Sie die folgende Suchzeichenfolge verwenden:

   /ndependent

   Wenn es keine Treffer gibt, gehen Sie zum nächsten Knoten und wiederholen Sie die Schritte 1–3.

4. Wenn Sie einen Treffer erhalten: Drücken Sie die Tastenkombination Shift + G, um nach unten zu den letzten Fehlermeldungen zu gelangen.

Neuladen der httpd-Stub-Datei

Independent Gateway verwaltet die Konfiguration von httpd für Apache. Eine allgemeine Methode, mit der sich vorübergehende Probleme oftmals beheben lassen, ist die httpd-Stub-Datei neu zu laden, aus der die zugrunde liegende Apache-Konfiguration stammt. Führen Sie auf beiden Instanzen von Independent Gateway die folgenden Befehle aus.

1. Kopieren Sie die Stub-Datei herüber zu httpd.conf:

   cp /var/opt/tableau/tableau_tsig/config/httpd.conf.stub /var/opt/tableau/tableau_tsig/config/httpd.conf

2. Starten Sie den Independent Gateway-Dienst neu:

   sudo su - tableau-tsig
   systemctl --user restart tsig-httpd
   exit

Löschen oder Verschieben von Protokolldateien

Independent Gateway protokolliert sämtliche Zugriffsereignisse. Um zu verhindern, dass dabei der gesamte Festplattenplatz belegt wird, müssen Sie die Protokolldateispeicherung verwalten. Wenn Ihre Festplatte voll wird, kann Independent Gateway keine Zugriffsereignisse mehr protokollieren und stellt den Betrieb mit einem Fehler ein. Die folgende Meldung wird in "error.log" in Independent Gateway protokolliert:

(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

Dieser Fehler führt zum Status DEGRADED für den external Knoten, wenn Sie tsm status -v auf Tableau-Knoten 1 ausführen. Der Knoten external in der Statusmeldung bezieht sich auf Independent Gateway.

Um dieses Problem zu beheben, müssen Sie die "access.log"-Dateien auf der Festplatte löschen. Die "access.log"-Dateien werden unter /var/opt/tableau/tableau_tsig/logs gespeichert. Nachdem Sie Platz auf der Festplatte geschaffen haben, starten Sie den tableau-tsig-Dienst neu.

Browserfehler

Bad Request: Ein häufiger Fehler in diesem Szenario ist ein Fehler vom Typ "Bad Request" (Ungültige Anforderung) von Okta. Dieses Problem tritt häufig auf, wenn der Browser Daten aus einer früheren Okta-Sitzung zwischenspeichert. Wenn Sie beispielsweise die Okta-Anwendungen als Okta-Administrator verwalten und dann versuchen, mit einem anderen Okta-fähigen Konto auf Tableau zuzugreifen, können Sitzungsdaten aus den Administratordaten den Fehler "Bad Request" verursachen. Wenn dieser Fehler auch dann noch auftritt, wenn Sie den lokalen Browser-Cache löschen, versuchen Sie, das Tableau-Szenario zu validieren, indem Sie eine Verbindung mit einem anderen Browser herstellen.

Eine weitere Ursache für Fehler vom Typ "Bad Request" (ungültige Anforderung) sind Schreibfehler in einer der vielen URLs, die Sie während der Okta-, Mellon- und SAML-Konfigurationsprozesse eingeben. Überprüfen Sie, ob Sie diese alle fehlerfrei eingegeben haben.

Oftmals gibt die Datei error.log auf dem Independent Gateway-Server an, welche URL den Fehler verursacht.

Not Found – The requested URL was not found on this server: Diese Fehlermeldung weist auf einen von vielen Konfigurationsfehlern hin.

Wenn der Benutzer mit Okta authentifiziert ist und dann diese Fehlermeldung erhält, haben Sie wahrscheinlich die Vor-Authentifizierungsanwendung von Okta bei der Konfiguration von SAML auf Tableau Server hochgeladen. Stellen Sie sicher, dass Sie die Metadaten der Tableau Server-Anwendung von Okta auf Tableau Server konfiguriert haben und nicht die Metadaten der Vor-Authentifizierungsanwendung von Okta.

Weitere Fehlerbehebungsschritte

• Überprüfen Sie die Einstellungen der Vor-Authentifizierungsanwendung von Okta. Stellen Sie sicher, dass die Protokolle HTTP und HTTPS wie in diesem Thema beschrieben festgelegt sind.
• Starten Sie tsig-httpd auf beiden Independent Gateway-Servern neu.
• Überprüfen Sie, ob sudo apachectl configtest auf beiden Independent Gateways die Meldung "Syntax OK" zurückgibt.
• Stellen Sie sicher, dass der Testbenutzer in Okta beiden Anwendungen zugewiesen ist.
• Stellen Sie sicher, dass "Stickiness" für das Lastenausgleichsmodul und die zugehörigen Zielgruppen aktiviert ist.

Überprüfen der TLS-Verbindung von Tableau Server zu Independent Gateway

Verwenden Sie den wget-Befehl, um die Konnektivität und den Zugriff von Tableau Server zu Independent Gateway zu überprüfen. Variationen dieses Befehls können Ihnen helfen zu verstehen, ob Verbindungsprobleme aus Problemen mit Zertifikaten resultieren.

Führen Sie zum Beispiel diesen wget-Befehl aus, um das Housekeeping-Protokoll (HK) von Tableau Server zu überprüfen:

wget https://ip-10-0-1-38.us-west-1.compute.internal:21319

Erstellen Sie die URL mit derselben Hostadresse, die Sie für die Hostoption der Datei "tsig.json" angegeben haben. Geben Sie das https-Protokoll an und fügen Sie die URL mit dem HK-Port 21319 an.

So überprüfen Sie die Konnektivität und ignorieren die Zertifikatsüberprüfung:

wget https://ip-10-0-1-38.us-west-1.compute.internal:21319 --no-check-certificate

So überprüfen Sie, ob das Stammzertifizierungsstellenzertifikat für TSIG gültig ist:

wget https://ip-10-0-1-38.us-west-1.compute.internal:21319 --ca-certificate=tsigRootCA.pem

Wenn Tableau in der Lage ist, zu kommunizieren, werden Ihnen möglicherweise noch inhaltsbezogene Fehler gemeldet, aber keine verbindungsbezogenen Fehler. Wenn Tableau überhaupt keine Verbindung herstellen kann, überprüfen Sie zunächst die Protokollkonfiguration in den Firewall-/Sicherheitsgruppen. So müssen zum Beispiel die Regeln für eingehenden Datenverkehr für die Sicherheitsgruppe, in der sich Independent Gateway befindet, TCP 21319 zulassen.