--- schema_version: "1" id: 867d2b4acf66aa252c3a79972f2040ce235cd9b5e19f1945a22890e84cf0c2c0 title: パート 7 - 検証、ツール、トラブルシューティング collection: tableau version: current locale: ja-jp portal_url: https://docs.salesforce.com/tableau/current/ja-jp/guides/enterprise-deployment/edg_part7.md canonical_url: https://help.tableau.com/current/guides/enterprise-deployment/ja-jp/edg_part7.htm source_site: help.tableau.com content_type: documentation content_hash: bcf671f90bafb4fa942241acaeb46d1107038e8dbf515d27554580fdfafd2358 description: "Part 7: validate, troubleshoot, and recover the enterprise deployment, including failover." --- [メイン コンテンツに進む](#main-content) # パート 7 - 検証、ツール、トラブルシューティング **注**: Tableau は、企業環境への導入ガイドの更新を終了しました。AWS での Tableau Server の有効な導入モデルとして、ここで説明されているリファレンス アーキテクチャは引き続き推奨されていますが、具体的な構成手順が前回の更新時から変更されている可能性があります。必ず最新の [Tableau Server ヘルプ](https://help.tableau.com/current/server/ja-jp/get_started_server.htm) ドキュメントと照らし合わせて、正確な手順を確認してください。 このトピックには、インストール後の検証手順とトラブルシューティング ガイダンスが含まれています。 ## フェールオーバー システムの検証 展開を構成した後、シンプルなフェールオーバー テストを実行して、システムの冗長性を検証することをお勧めします。 フェールオーバー機能を検証するには、次の手順を実行するとよいでしょう。 1. 独立したゲートウェイの最初のインスタンス (TSIG1) をシャットダウンします。すべてのインバウンド トラフィックは、独立したゲートウェイの 2 つ目のインスタンス (TSIG2) を介してルーティングされます。 2. TSIG1 を再起動してから、TSIG2 をシャットダウンします。すべてのインバウンド トラフィックは TSIG1 を介してルーティングされます。 3. TSIG2 を再起動します。 4. Tableau Server ノード 1 をシャットダウンします。すべての Vizportal/アプリケーション サービス トラフィックがノード 2 にフェールオーバーします。 **注:** 2022 年 9 月現在、Tableau Server 2021.4 以降の特定のバージョンで、ノード 1 の高可用性が低下しています。ノード 1 がダウンしている場合、クライアント接続が失敗します。この問題は、以下のメンテナンス リリースで修正済みです。 \- 2021.4.15 以降 \- 2022.1.11 以降 \- 2023.1.3 以降 ATR アクティブ化を使用する Tableau Server インストールで、初期ノードの障害発生後に 72 時間の猶予期間を確保するには、これらのバージョンのいずれかをインストールまたはアップグレードしてください。詳細については、Tableau ナレッジ ベースの「[ATR を使用する Tableau Server HA で初期ノードの障害後の猶予期間が存在しない](https://kb.tableau.com/articles/issue/tableau-server-ha-using-atr-does-not-have-a-grace-period-after-the-initial-node-failure?lang=ja-jp "高可用性の障害に関する Tableau KB の記事")」を参照してください。 5. ノード 1 を再起動し、ノード 2 をシャットダウンします。すべての Vizportal/アプリケーション サービス トラフィックがノード 1 にフェールオーバーします。 6. ノード 2 を再起動します。 このコンテキストでは、事前にアプリケーションの正常なシャットダウンを試みることなく、オペレーティング システムまたは仮想マシンをオフにすることにより、「シャットダウン」または「再起動」を行います。その目的は、ハードウェアや仮想マシンの障害をシミュレーションすることです。 各フェールオーバー テストの最小限の検証手順では、ユーザーで認証し、基本的なビュー操作を実行します。 障害をシミュレーションした後、サインインを試みたときに、「無効な要求」ブラウザ エラーが返される場合があります。ブラウザーのキャッシュをクリアしても、このエラーが表示されることがあります。多くの場合、この問題は、ブラウザーが前の IdP セッションからのデータをキャッシュしているときに発生します。ローカル ブラウザーのキャッシュをクリアした後でもこのエラーが続く場合は、別のブラウザーに接続して Tableau シナリオを検証してください。 ## 初期ノードの自動リカバリ Tableau Server バージョン 2021.2.4 以降には、初期ノードを自動的に回復できるスクリプト `auto-node-recovery` が、スクリプトのディレクトリ (`/app/tableau_server/packages/scripts.`) に含まれています。 初期ノードに問題があり、ノード 2 に冗長プロセスがある場合、Tableau Server が引き続き実行できるという保証はありません。Tableau Server は、初期ノードに障害が発生した後、ライセンス発行サービスの欠如が他のプロセスに影響を与え始めるまで、最大 72 時間実行し続ける可能性があります。初期ノードでエラーが発生しても、ユーザーは引き続きサインインしてコンテンツを表示および使用することはできますが、管理コントローラーへのアクセス権がなくなるため、Tableau Server の再構成ができなくなります。 冗長プロセスで構成されている場合でも、初期ノードに障害が発生すると、Tableau Server が機能し続けることができなくなる可能性があります。 初期ノード (ノード 1) のリカバリ手順は次のとおりです。 1. Tableau Server ノード 2 にサインインします。 2. スクリプトのディレクトリに変更します。 cd /app/tableau\_server/packages/scripts. 3. 次のコマンドを実行してスクリプトを起動します。 sudo ./auto-node-recovery -p node1 -n node2 -k `` は、ご利用の展開のライセンス キーをコンマで区切ったリスト (スペースなし) です。ライセンス キーがわからない場合は、[Tableau カスタマー ポータル](http://customer.tableausoftware.com/?_fsi=v45oWMAM)にアクセスして検索してください。例: sudo ./auto-node-recovery -p node1 -n node2 -k TSB4-8675-309F-TW50-9RUS,TSNM-559N-ULL6-22VE-SIEN auto-node-recovery スクリプトは、約 20 のステップを実行して、サービスをノード 2 に回復します。スクリプトが進むにつれて、各ステップがターミナルに表示されます。より詳細なステータスは `/data/tableau_data/logs/app-controller-move.log` に記録されます。ほとんどの環境では、スクリプトが完了するまでに 35 ～ 45 分かかります。 ### 初期ノード リカバリのトラブルシューティング ノードの回復に失敗した場合は、スクリプトをインタラクティブに実行して、プロセス内の個別のステップを許可または禁止すると便利な場合があります。たとえば、スクリプトがプロセスの途中で失敗した場合は、ログ ファイルを確認し、設定を変更してからスクリプトを再実行できます。インタラクティブ モードで実行することにより、失敗したステップに到達するまですべてのステップをスキップできます。 インタラクティブ モードで実行するには、スクリプトの引数に `-i` スイッチを追加します。 ### 障害が発生したノードを再構築します。 スクリプトを実行すると、ノード 2 では、以前は障害が発生したノード 1 ホスト上にあったすべてのサービスが実行されます。4 ノードを追加するには、bootstrap ファイルを使用して新しい Tableau Server ホストを展開し、パート 4 で指定した元のノード 2 と同じように構成する必要があります。「[ノード 2 の構成](https://help.tableau.com/current/guides/enterprise-deployment/ja-jp/edg_part4.htm#Configur2)」を参照してください。 ## 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 3. スクリプトの IP アドレスを更新して EC2 インスタンスにマッピングし、ファイルを保存します。 4. スクリプト ファイルにパーミッションを適用します。 sudo chmod +x switchto 使用方法: ホストを切り換えるには、次のコマンドを実行します。 `./switchto ` たとえば、ノード 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 を許可する必要があります。