--- schema_version: "1" id: f0593e4894850e402c0ac9cef29232986954fa2174a743cf7322b80a24fd8dd7 title: 第 7 部分 - 驗證、工具和疑難排解 collection: tableau version: current locale: zh-tw portal_url: https://docs.salesforce.com/tableau/current/zh-tw/guides/enterprise-deployment/edg_part7.md canonical_url: https://help.tableau.com/current/guides/enterprise-deployment/zh-tw/edg_part7.htm source_site: help.tableau.com content_type: documentation content_hash: 628021c265b0b28958eff13279cbbbbd5b875ef27bdd317902d924f728037ac5 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/zh-tw/get_started_server.htm) 文件進行交叉引用，以確保準確無誤。 本主題包含安裝後驗證步驟和疑難排解指南。 ## 容錯移轉系統驗證 設定部署後，我們建議執行簡單的容錯移轉測試來驗證系統冗餘。 我們建議執行以下步驟來驗證容錯移轉功能： 1. 關閉 Independent Gateway (TSIG1) 的第一個執行個體。所有輸入流量都應由 Independent Gateway (TSIG2) 的第二個執行個體進行路由。 2. 重新啟動 TSIG1，然後關閉 TSIG2。所有輸入流量都應由 TSIG1 路由。 3. 重新啟動 TSIG2。 4. 關閉 Tableau Server 節點 1。所有 Vizportal/Application 服務流量都將容錯移轉到節點 2。 **注意**自 2022 年 9 月起，節點 1 的高可用性在特定 Tableau Server 2021.4 及更高版本上受到影響。如果節點 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=zh-tw "有關高可用性故障的 Tableau 知識庫文章。")。 5. 重新啟動節點 1 並關閉節點 2。所有 Vizportal/Application 服務流量都將容錯移轉到節點 1。 6. 重新啟動節點2。 在這種情況下，「關閉」或「重新啟動」是以關閉作業系統或虛擬機來完成，無需事先嘗試正常關閉應用程式。目標是模擬硬體或虛擬機故障。 每個容錯移轉測試的最小驗證步驟是向使用者進行身份驗證並執行基本的檢視動作。 在模擬失敗後嘗試登入時，您可能會收到「錯誤請求」瀏覽器錯誤。即使清除瀏覽器中的快取，也可能會看到此錯誤。當瀏覽器快取來自先前 IdP 工作階段的資料時，通常會發生此問題。如果清除本機瀏覽器快取後此錯誤仍然存在，請與其他瀏覽器連線來驗證 Tableau 方案。 ## 初始節點自動復原 Tableau Server 版本 2021.2.4 及更高版本在指令碼目錄 (`/app/tableau_server/packages/scripts.`) 中包含自動初始節點復原指令碼 `auto-node-recovery`。 若初始節點出現問題，並且節點 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 節點，需要使用啟動程序檔案部署新的 Tableau Server 主機，並按照第 4 部分中指定的原始節點 2 的設定方式對其進行設定。請參閱[設定節點 2](https://help.tableau.com/current/guides/enterprise-deployment/zh-tw/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 獨立閘道 在 Tableau Server 上設定獨立閘道、Okta、Mellon 和 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 設定的 Shell 歷程記錄。檢閱您執行的 `tsm authentication saml configure` 命令。驗證所有 URL 是否與您在 Okta 中設定的 URL 相符。在查看節點 1 的 shell 歷史記錄時，請確認 `tsm configuration set` 指定 Mellon 設定檔路徑的命令完全對應在Independent Gateway上複製檔案的檔案路徑。 - 獨立閘道中的 Mellon 設定。檢閱 shell 歷程記錄，驗證所建立的中繼資料是否使用您在 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 安全性群組設定。另一個常見問題是 `tsig.json` 中的拼字錯誤。如果更新 tsig.json，請執行 `tsm stop`，然後執行 `tsm topology external-services gateway update -c tsig.json`。更新 tsig.json 後，請執行 `tsm start`。 - `error.log`：除其他項目外，此記錄還包括 SAML 和 Mellon 錯誤。 #### Tableau Server tabadminagent 記錄檔 `tabadminagent`（非 `tabadmincontroller`）檔案集是解決 Independent Gateway 相關錯誤的唯一相關記錄檔。 必須找到在 `tabdminagent` 中記錄的 Independent Gateway 錯誤。這些錯誤可以在任何節點中，但只在一個節點上。在 Tableau Server 叢集中的每個節點中執行以下步驟，直到找到「independent」字串： 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 虛設常式檔案 Independent Gateway 管理 Apache 的 httpd 設定。通常會修復暫時性問題的一般操作是重新載入作為基礎 Apache 設定植入的 httpd 虛設常式檔案。在 Independent Gateway 的兩個執行個體上執行以下命令。 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 ### 刪除或移動記錄檔 Independent Gateway 記錄所有存取事件。將需要管理記錄檔儲存以避免填滿磁碟空間。如果磁碟已滿，Independent Gateway 將無法寫入存取事件並且服務將失敗。以下訊息將記錄到 Independent Gateway 上的 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` 節點是指 Independent Gateway。 要解決此問題，請刪除或移動磁碟上的 access.log 檔案。Access.log 的存放位置為 `/var/opt/tableau/tableau_tsig/logs`。清理磁碟後，重新啟動 tableau-tsig 服務。 ### 瀏覽器錯誤 **錯誤的要求**：這種情況下的一個常見錯誤是來自 Okta 的「錯誤的要求」錯誤。當瀏覽器快取來自先前 Okta 工作階段的資料時，通常會發生此問題。例如，如果您以 Okta 管理員身份管理 Okta 應用程式，然後嘗試使用不同的啟用 Okta 帳戶存取 Tableau，則來自管理員資料的工作階段資料可能會導致「錯誤的要求」錯誤。如果清除本機瀏覽器快取後此錯誤仍然存在，請嘗試與其他瀏覽器連線來驗證 Tableau 方案。 「錯誤請求」錯誤的另一個原因是在 Okta、Mellon 和 SAML 設定過程中輸入的眾多 URL 之一中發生拼寫錯誤。檢查您輸入的所有這些內容都沒有錯誤。 通常情況下，獨立閘道伺服器中的 `error.log` 檔案會指出造成此錯誤的 URL。 **找不到 - 在此伺服器上找不到請求的 URL** ：此錯誤代表許多設定錯誤的其中一種。 如果使用者使用 Okta 進行身份驗證，然後收到此錯誤，則很可能是在設定 SAML 時將 Okta 預身份驗證應用程式上傳到 Tableau Server。驗證出您在 Tableau Server 上設定了 Okta Tableau Server 應用程式中繼資料，而不是 Okta 預身份驗證應用程式中繼資料 其他疑難排解步驟: - 檢查 Okta 預身份驗證應用程式設定。確定 HTTP 與 HTTPS 協定按照此主題指定步驟設定。 - 在兩個獨立閘道伺服器上重新啟動 tsig-httpd。 - 請驗證 `sudo apachectl configtest` 是否在兩個獨立閘道上都傳回「語法正常」。 - 驗證測試使用者是否已指派給 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 檔案的 host 選項包含的相同主機地址建構 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。