企業環境への Tableau Server 導入ガイド

switchto

switchto は、ウィンドウ間の切り替えを容易にする Tim のスクリプトです。

1. 要塞ホストのホーム ディレクトリにある switchto というファイルに、次のコードをコピーします。

#!/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. スクリプトの IP アドレスを更新して EC2 インスタンスにマッピングし、ファイルを保存します。
3. スクリプト ファイルにパーミッションを適用します。

sudo chmod +x switchto

使用方法:

ホストを切り換えるには、次のコマンドを実行します。

./switchto <target>

たとえば、ノード 1 に切り換えるには、以下のコマンドを実行します。

./switchto node1

Tableau Server の独立したゲートウェイのトラブルシューティング

独立したゲートウェイ、Okta、Mellon、Tableau Server の SAML を構成する作業は、エラーが発生しやすいプロセスです。失敗の最も一般的な根本原因は文字列エラーです。たとえば、構成中に指定した Okta URL に末尾のスラッシュ (/) があることにより、SAML アサーション関連の不一致エラーが発生する可能性があります。これはほんの一例です。構成中に、誤った文字列を任意のアプリケーションで入力する機会がたくさんあります。

tableau-tsig サービスの再起動

トラブルシューティングを開始 (および終了) するには、独立したゲートウェイ コンピューターで tableau-tsig サービスを常に再起動します。このサービスの再起動は迅速であり、多くの場合、更新された構成がこれをトリガーにして Tableau Server からロードされます。

独立したゲートウェイ コンピューターで次のコマンドを実行します。

sudo su - tableau-tsig

systemctl --user restart tsig-httpd

exit

間違った文字列を見つける

文字列エラー (コピー/貼り付けの間違い、文字列の切り捨てなど) が発生した場合は、構成した各設定を時間をかけて一通り確認してください。

• Okta の事前認証の設定。設定した URL を注意深く確認してください。末尾のスラッシュを探します。HTTP か HTTPS かを確認します。
• ノード 1 での SAML 構成のシェル履歴。実行した tsm authentication saml configure コマンドを確認します。すべての URL が Okta で設定したものと一致することを確認します。ノード 1 のシェル履歴を確認する際に、tsm configuration set コマンドで指定した Mellon 構成ファイル パスが、独立したゲートウェイ上の、ファイルのコピー元のファイル パスに厳密にマッピングされていることを検証します。
• 独立したゲートウェイでの Mellon 構成。シェル履歴を確認して、Okta および Tableau SAML で設定したものと同じ URL 文字列でメタデータを作成していることを確認します。/etc/mellon/conf.d/global.conf で指定されているすべてのパスが正しく、MellonCookieDomain が Tableau サブドメインではなく、ルート ドメインに設定されていることを確認します。

関連するログの検索

すべての文字列が正しく設定されているようであれば、ログにエラーがないか調べます。

Tableau Server は、エラーとイベントを数十の異なるログ ファイルに記録します。独立したゲートウェイも、一連のローカル ファイルにログを記録します。これらのログは、次の順序で検査することをお勧めします。

独立したゲートウェイのログ ファイル

独立したゲートウェイのログ ファイルは、デフォルトでは /var/opt/tableau/tableau_tsig/logs にあります。

• access.log: このログは、Tableau Server ノードからの接続を示すエントリがあるので役立ちます。TSM を開始しようとしたときに、ゲートウェイ エラーが発生して開始できず、access.log ファイルにはエントリがない場合、コア接続に問題があります。最初のステップとして、AWS セキュリティ グループの設定を常に確認してください。もう 1 つの一般的な問題は、tsig.json のタイプミスです。tsig.json を更新する場合は、 tsm topology external-services gateway update -c tsig.json を実行する前に tsm stop を実行します。tsig.json が更新されたら、tsm start を実行します。
• error.log: このログには SAML および Mellon に関するエラーが含まれています。

Tableau Server の tabadminagent ログ ファイル

一連の tabadminagent (tabadmincontroller ではない) ファイルは、独立したゲートウェイ関連のエラーのトラブルシューティングに利用できる唯一のログ ファイルです。

独立したゲートウェイのエラーが tabdminagent に記録されている場所を見つける必要があります。これらのエラーはどのノードでも発生する可能性がありますが、発生するノードは 1 つのみです。「independent」の文字列が見つかるまで、Tableau Server クラスタの各ノードで次の手順を実行します。

1. EDG セットアップの Tableau Server ノード 1 ～ 4 で tabadminagent ログ ファイルの場所を見つけます。

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

2. 最新のログを開いて読み取ります。

   less tabadminagent_nodeN.log

   (N をノード番号に置き換えます)

3. 次の検索文字列を使用して、「Independent」と「independent」のすべてのインスタンスを検索します。

   /ndependent

   一致するものがない場合は、次のノードに移動して、手順 1 ～ 3 を繰り返します。

4. 一致した場合: 最後のエラー メッセージを取得するために Shift + G で一番下に移動します。

httpd スタブ ファイルの再読み込み

独立したゲートウェイは、Apache の httpd 構成を管理します。多くの場合、一時的な問題を解決する一般的な操作は、基になる Apache 構成をシードする httpd スタブ ファイルを再読み込みすることです。独立したゲートウェイの両方のインスタンスで以下のコマンドを実行します。

1. スタブ ファイルを httpd.conf にコピーします。

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

2. 独立したゲートウェイのサービスを再起動します。

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

ログ ファイルの削除または移動

独立したゲートウェイは、すべてのアクセス イベントをログに記録します。ディスク空き容量が一杯になることを防ぐには、ログ ファイル ストレージを管理する必要があります。ディスクが一杯になると、独立したゲートウェイはアクセス イベントを書き込めなくなり、サービスが失敗します。独立したゲートウェイの error.log に次のメッセージが記録されます。

(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

この障害が発生すると、Tableau ノード 1 で tsm status -v を実行した際に external ノードが DEGRADED ステータスになります。ステータス出力の external ノードは、独立したゲートウェイを指します。

この問題を解決するには、ディスクから access.log ファイルを削除するか、移動します。access.log ファイルは /var/opt/tableau/tableau_tsig/logs に保存されます。ディスクをクリアした後、tableau-tsig サービスを再起動します。

ブラウザ エラー

無効な要求: このシナリオの一般的なエラーは、Okta から送信される「無効な要求」というエラーです。多くの場合、この問題は、ブラウザーが前の Okta セッションからのデータをキャッシュしているときに発生します。たとえば、あなたが Okta 管理者として Okta アプリケーションを管理しており、別の Okta 対応アカウントを使用して Tableau にアクセスしようとすると、管理者データからのセッション データが「無効な要求」エラーの原因となる場合があります。ローカル ブラウザーのキャッシュをクリアしてもこのエラーが続く場合は、別のブラウザーに接続して Tableau シナリオを検証してみてください。

「無効な要求」エラーのもう 1 つの原因は、Okta、Mellon、および SAML の設定作業中に入力する多くの URL でタイプミスがあることです。これらすべてをエラーなしで入力したことを確認してください。

多くの場合、独立したゲートウェイ サーバー上の error.log ファイルでは、エラーの原因となっている URL を指定しています。

見つかりません - 要求された URL がこのサーバーで見つかりませんでした: このエラーは、多くの構成エラーの 1 つです。

Okta を使用して認証されたユーザーがこのエラーを受け取った場合は、SAML を構成したときに Okta 事前認証アプリケーションを Tableau Server にアップロードした可能性があります。Okta 事前認証アプリケーション メタデータではなく、Okta Tableau Server アプリケーション メタデータが Tableau Server で構成されていることを確認します

その他のトラブルシューティング ステップ

• Okta 事前認証アプリケーションの設定を確認します。HTTP プロトコルまたは HTTPS プロトコルがこのトピックで指定されているとおりに設定されていることを確認してください。
• 両方の独立したゲートウェイ サーバーで tsig-httpd を再起動します。
• 両方の独立したゲートウェイで sudo apachectl configtest が「構文 OK」を返すことを確認します。
• テスト ユーザーが Okta の両方のアプリケーションに割り当てられていることを確認します。
• ロード バランサーおよび関連するターゲット グループにスティッキネスが設定されていることを確認します。

独立したゲートウェイへの Tableau Server からの TLS 接続の検証

wget コマンドを使用して、独立したゲートウェイへの Tableau Server からの接続とアクセスを確認します。このコマンドのバリエーションを使用すると、証明書の問題が接続の問題を引き起こしているかどうかを理解するのに役立ちます。

たとえば、次の wget コマンドを実行して、Tableau Server からのハウスキーピング (HK) プロトコルを検証します。

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

tsig.json ファイルのホスト オプションに含めたのと同じホスト アドレスで URL を作成します。https プロトコルを指定し、URL に HK ポート21319 を追加します。

接続を確認し、証明書の検証を無視します。

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

TSIG のルート CA 証明書が有効であることを確認します。

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

Tableau が通信できる場合、コンテンツ関連のエラーが発生する可能性はありますが、接続関連のエラーは発生しません。Tableau がまったく接続できない場合は、ファイアウォールやセキュリティ グループのプロトコル構成を確認することから始めます。たとえば、独立したゲートウェイが存在するセキュリティ グループのインバウンド ルールでは、TCP 21319 を許可する必要があります。