初期ノードの障害からの回復
Tableau を最初にインストールするコンピューターである「初期ノード」には、固有の特徴があります。初期ノード上で実行できるのは、ライセンス サービス (ライセンス マネージャー)、ライセンス認証サービス、TSM コントローラー (管理コントローラー) の 3 つのプロセスのみで、エラーが発生した場合を除き、これらのプロセスを他のノードに移動させることはできません。Tableau Server には、これらのプロセスを他のいずれかの既存ノードに移動するのを自動化するスクリプトが含まれています。これにより、TSM に戻るための完全なアクセス権を取得し、Tableau Server の実行を維持できるようになります。
他の 2 つのプロセスはまず初期ノードに含められますが、追加のノード、CFS (Client File Service)、調整サービスに追加・移動させることができます。インストールが CFS および調整サービスでどのように構成されていたかによって、これらを再デプロイする手順も必要になる場合があります。
最初のノードに障害が発生した場合
初期ノードに問題があり、他のノードに冗長プロセスがある場合、Tableau Server が引き続き実行できるという保証はありません。
- Tableau Server は、第一ノードに障害が発生してから最大 72 時間、ライセンス サービスの欠如によって他のプロセスが影響を受け始める前まで、実行を継続することができます。初期ノードでエラーが発生しても、ユーザーは引き続きサインインしてコンテンツを表示および使用することはできますが、管理コントローラーへのアクセス権がなくなるため、Tableau Server の再構成ができなくなります。
- ATR 用に構成された Tableau Server 2021.4.2 (またはそれ以前) のバージョンを実行している場合、第一ノードに問題が発生すると、すべてのサーバー機能が使用できなくなります。これは、初期ノードに問題がある場合でも、意図的に初期ノードを停止している (たとえば、システムレベル パッチを適用するために) 場合でも当てはまります。
冗長プロセスで構成されている場合でも、初期ノードに障害が発生すると、Tableau Server が機能し続けることができなくなる可能性があります。これは、インストールが高可用性用に構成されている場合でも当てはまります。つまり、できるだけ早く、2 つの固有のプロセスを別の実行中のノードに移動させる必要があります。相対的に時間が足りず復元できないという理由で初期のノードに失敗が起きる場合 (修正できるハードウェアのエラーなど)、まずは以下の手順を実行せずにノードのバックアップを試行する必要があります。
注: この記事の手順ではサーバーのダウンタイムが必要となり、業務に支障が出る可能性があります。したがって、最初のノードに非常に重大な障害が発生した場合にのみ実行する必要があります。最初のノードを再稼働できない場合は、次の手順を使用して主要な TSM プロセスをクラスタ内の別のノードに移動してください。
一般的な要件
Tableau Server バージョン 2020.1 では復元機能が強化されました。このトピックの手順は、Tableau Server 2021.1 用に作成されています。
障害が発生したノードを以前のバージョンの Tableau Server から復元しようとしている場合は、そのバージョン用の手順に従う必要があります。Tableau ヘルプのアーカイブ バージョンを表示するには、Tableau ヘルプ(新しいウィンドウでリンクが開く)を参照してください。
- マルチノード Tableau Server インストールをセットアップするプロセスの一環として、調整サービス アンサンブルを展開してあるはずです。下記のプロセスは、最初のノードで問題が発生する前に調整サービス アンサンブルが展開されていることを前提にしています。新しい調整サービス アンサンブルを展開する方法について詳細は、調整サービス アンサンブルの展開を参照してください。
- このプロセスでは、調整サービスを実行しているすべてのノードでクライアント ファイル サービス (CFS) のインスタンスを構成していることを前提にしています。CFS のインスタンスを追加しなかった場合は、最初のノードのみにインスタンスがあるため、CFS の少なくとも 1 つのインスタンスを別のノードに追加する必要があります。CFS を再読み込みする必要もあります。Tableau Server には最低 1 インスタンスの CFS が必要です。詳細については、クライアント ファイル サービスの構成およびTableau Server クライアント ファイル サービスを参照してください。
注: この操作には、TSM コマンド ラインを使用して実行する必要のある手順が含まれています。
TSM コントローラー、ライセンス サービス、アクティブ化サービスを別のノードに移動する
最初のノードで問題が発生した場合、TSM コントローラー、ライセンス発行サービス、アクティブ化サービスを別のノードで起動する必要があります。次のステップに従い、提供された move-tsm-controller スクリプトを使用して、TSM コントローラー、ライセンス発行サービス、アクティブ化サービスを別のノードで動作させます。
まだ動作しているノード上で、コントローラー復旧スクリプトを実行します。動作中ノード上のターミナルのプロンプトで、次のコマンドを入力します。
sudo /opt/tableau/tableau_server/packages/scripts.<version_code>/move-tsm-controller -n <nodeID>"nodeID" には TSM コントローラーを実行したいノードの ID が入ります。例:
sudo /opt/tableau/tableau_server/packages/scripts.10400.17.0802.1319/move-tsm-controller -n node2管理コントローラーがノード上で実行されていることを確認します。
tsm status -vTableau Server を停止します。
この手順の残りの部分には、
--ignore-node-statusオプションを使用する一部のコマンドが含まれています。--ignore-node-statusオプションを使用してコマンドを実行すると、指定されたノードの状況を考慮せずにコマンドが実行されます。--ignore-node-statusを使用するには、障害が発生したノードを指定します。tsm stop --ignore-node-status <nodeID>たとえば、node1 に障害が発生した場合は、次のコマンドを実行します。
tsm stop --ignore-node-status node1ノードにライセンス サービスを追加します。
tsm topology set-process -pr licenseservice -n <nodeID> -c 1元のノードから旧ライセンス サービスを削除します。"nodeID" は障害の発生した元の最初のノードです。
tsm topology set-process -pr licenseservice -n <nodeID> -c 0次のバージョンのいずれかを実行している場合
2023.3.0 以降
2023.1.3 以降
2022.3.7 以降
2022.1.15 以降
または、以前のバージョンを実行していて ATR を使用している場合は、有効化サービスを新しいノードに追加します。
tsm topology set-process -pr activationservice -n <nodeID> -c 1次のバージョンのいずれかを実行している場合
2023.3.0 以降
2023.1.3 以降
2022.3.7 以降
2022.1.15 以降
または、以前のバージョンを実行していて ATR を使用している場合は、元のノードから古い有効化サービスを削除します。「nodeID」は障害が発生した最初のノードです。
tsm topology set-process -pr activationservice -n <nodeID> -c 0重要: クラスターでは、CFS の唯一のインスタンスを実行しているノードに障害が発生すると、CFS によって管理されているファイルが失われるため、証明書とカスタム イメージをもう一度インポートし、関連する構成を変更して、CFS のこれらのファイルをもう一度設定する必要があります。 CFSによって管理されるファイルのリストについては、Tableau Server クライアント ファイル サービスを参照してください。
最初のノードでメッセージング サービス のみを実行していた場合は、このノードにメッセージング サービス を追加します。
tsm topology set-process -pr activemqserver -n node2 -c 1(オプション) 最初のノードで実行されていて、このノードでは実行されていなかったその他のプロセスも追加できます。たとえば、キャッシュ サーバーを追加するには次を入力します。
tsm topology set-process -pr cacheserver -n node2 -c 1変更を適用します。
tsm pending-changes apply --ignore-node-status <nodeID>保留中の変更にサーバーの再起動が必要な場合は、
pending-changes applyコマンドの実行時に、再起動が行われることを知らせるメッセージが表示されます。このメッセージはサーバーが停止していても表示されますが、その場合には再起動は行われません。--ignore-promptオプションを使用してメッセージが表示されないようにできますが、そのようにしても再起動に関する動作が変わることはありません。変更に再起動が必要ない場合は、メッセージなしで変更が適用されます。詳細については、tsm pending-changes applyを参照してください。TSM 管理コントローラーを
sudo su -l tableau -c "systemctl --user restart tabadmincontroller_0.service"注: tabadmincontroller の再起動には数分かかる場合があります。コントローラーを完全に再起動させる前に次の手順で保留中の変更を適用しようとする場合、TSM はコントローラーに接続できなくなります。
tsm status -vコマンドを使用して、コントローラーが実行されていることを確認できます。Tableau Server 管理コントローラーが「実行中」として表示されます。保留中の変更を適用します (変更は何もないように見えますが、このステップは必要です)。
tsm pending-changes apply --ignore-node-status <nodeID>Tableau Server ライセンスを新しいコントローラー ノード上で認証します。
tsm licenses activate -k <product-key>ライセンスが適切に認証されていることを確認します。
tsm licenses list最初のノードで調整サービスを実行していた場合は、そのノードに含まれていない新しい調整サービス アンサンブルを展開する必要があります。ノード クラスタが 3 つあり、最初のノードで調整サービスを実行していた場合、新しい単一インスタンスの調整サービス アンサンブルを別のノードに展開し、古いアンサンブルをクリーンアップする必要があります。次の例では、単一インスタンスの調整サービスが 2 番目のノードに展開されています。
tsm topology deploy-coordination-service -n node2 --ignore-node-status node1最初のノードでファイル ストア インスタンスを実行していた場合は、このインスタンスを削除する必要があります。
tsm topology filestore decommission -n <nodeID> --delete-filestoreここで
nodeIDは障害が発生した最初のノードです。上記で展開した新しい調整サービス アンサンブルが単一ノードのアンサンブルの場合は、
--ignore-warningsフラグを使用して保留中の変更を適用します。tsm pending-changes apply --ignore-node-status node1 --ignore-warnings最初のノードを削除します。
nodeIDは障害が発生した最初のノードです。tsm topology remove-nodes -n <nodeID>上記で展開した新しい調整サービス アンサンブルが単一ノードのアンサンブルの場合は、
--ignore-warningsフラグを使用して保留中の変更を適用します。tsm pending-changes apply --ignore-warningsTableau Server を起動します。
tsm startこの時点でサーバーが起動し、TSM を使用して構成を行うことができます。次のステップでは最初のノードを置換し、クラスタに元のノード数が含まれるようにします。この実行方法は、エラーが発生したノードを再利用するかどうかによって変わります。エラーが発生した理由を特定できない場合にはそのノードのみを再利用し、エラーが再発しないように対策を取ることをお勧めします。
元のノードの再利用を計画している場合は、まずはそこから Tableau を完全に削除する必要があります。これを行うには
tableau-server-obliterateスクリプトを実行します。この実行の詳細については、コンピュータから Tableau Server を削除するを参照してください。新しいコンピューター、または Tableau を完全に削除した後の元のコンピューターで、元のセットアップ プログラムと、現在管理コントローラーおよびライセンス発行サービスを実行中のノードから生成された bootstrap ファイルを使用して Tableau をインストールします。これにより、クラスターの一部として構成できる追加のノードが作成されます。ノード追加方法の詳細については、追加のノードのインストールと構成を参照してください。
ベスト プラクティスは、元のノードでエラーが発生したときに失ったプロセスを構成し、クラスタでの十分な冗長性を確保することです。新しい最初のノードから、新しく追加した追加ノードにプロセスを移動し、元の構成を複製することが必要な場合があります。たとえば、最初のノードがゲートウェイとファイル ストアのみを実行していた場合、同様の方法で新しい最初のノードの構成が必要となる場合があります。
必要な方法でノードを起動して実行したら、新しい調整サービス アンサンブルの再展開も必要です。詳細は、調整サービス アンサンブルの展開を参照してください。
最後に、まだ実施していない場合は、調整サービスを実行しているすべてのノードに CFS のインスタンスを追加します。詳細については、クライアント ファイル サービスの構成を参照してください。クライアント ファイル サービスの構成
クラスターでは、CFS の唯一のインスタンスを実行しているノードに障害が発生すると、CFS によって管理されているファイルが失われるため、証明書とカスタム イメージをもう一度インポートし、関連する構成を変更して、CFS のこれらのファイルをもう一度設定する必要があります。 CFS によって管理されるファイルのリストについては、Tableau Server クライアント ファイル サービスを参照してください。