---
schema_version: "1"
id: 284b2f879d7131698f65fb351bdbbdb64b1d95a7ffecf3a8af946490a0d08e3d
title: 第 7 部分 - 验证、工具和故障排除
collection: tableau
version: current
locale: zh-cn
portal_url: https://docs.salesforce.com/tableau/current/zh-cn/guides/enterprise-deployment/edg_part7.md
canonical_url: https://help.tableau.com/current/guides/enterprise-deployment/zh-cn/edg_part7.htm
source_site: help.tableau.com
content_type: documentation
content_hash: be68c0d2a725037f3a193ac8b7949bddd644261faadeb9075d2ad1d926e9a240
description: "Part 7: validate, troubleshoot, and recover the enterprise deployment, including failover."
---
[跳转到主要内容](#main-content)

# 第 7 部分 - 验证、工具和故障排除

**注意**：Tableau 不再更新《Enterprise 部署指南》。尽管我们仍然推荐将此处描述的参考架构作为 AWS 中 Tableau Server 的有效部署模型，但自上次更新以来，特定的配置过程可能已更改。请始终将这些步骤与最新的 [Tableau Server 帮助](https://help.tableau.com/current/server/zh-cn/get_started_server.htm)文档进行交叉引用，以确保准确性。

本主题包括安装后验证步骤和故障排除指南。

## 故障转移系统验证

配置部署后，我们建议运行简单的故障转移测试来验证系统冗余。

我们建议运行以下步骤来验证故障转移功能：

1. 关闭独立网关的第一个实例 (TSIG1)。所有入站流量都应通过独立网关的第二个实例 (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=zh-cn "有关高可用性故障的 Tableau 知识库文章。")。
5. 重新启动节点 1 并关闭节点 2。所有 Vizportal/应用服务流量将故障转移到节点 1。
6. 重新启动节点 2。

在此上下文中，“关闭”或“重新启动”是通过关闭操作系统或虚拟机来完成的，而无需事先尝试应用程序的正常关闭。目标是模拟硬件或虚拟机故障。

每个故障转移测试的最小验证步骤是验证用户身份并执行基本的视图操作。

当您在模拟失败后尝试登录时，可能会收到“错误请求”浏览器错误。即使您清除了浏览器中的缓存，也可能会看到此错误。当浏览器缓存来自先前 IdP 会话的数据时，通常会发生此问题。如果即使在您清除本地浏览器缓存后此错误仍然存在，请通过连接其他浏览器来验证 Tableau 方案。

## 初始节点自动恢复

Tableau Server 版本 2021.2.4 及更高版本在脚本目录 (`/app/tableau_server/packages/scripts.<version>`) 中包括自动初始节点恢复脚本 `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.<version>
3. 运行以下命令以启动脚本：
    
    sudo ./auto-node-recovery -p node1 -n node2 -k <license keys>
    
    其中 `<license keys>` 是用于您的部署的许可证密钥的逗号分隔（无空格）列表。如果您无权访问许可证密钥，请访问 [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

自动节点恢复脚本将执行大约 20 个步骤以将服务恢复到节点 2。随着脚本的进行，每个步骤都显示在终端中。更详细的状态会记录到 `/data/tableau_data/logs/app-controller-move.log`。在大多数环境中，脚本需要 35 到 45 分钟才能完成。

### 对初始节点恢复进行故障排除

如果节点恢复失败，您可能会发现以交互方式运行脚本以允许或禁止过程中的离散步骤很有用。举例来说，如果脚本在整个过程中失败，您可以查看日志文件，更改配置，然后再次运行脚本。通过以交互模式运行，您可以随后跳过所有步骤，直到到达失败的步骤。

若要以交互模式运行，请向 script 参数中添加 `-i` 开关。

### 重建故障节点

运行脚本后，节点 2 将运行以前在出现故障的节点 1 主机上的所有服务。若要在 4 节点中添加，您需要使用引导程序文件部署新的 Tableau Server 主机，并按照第 4 部分中指定的原始节点 2 的方式对其进行配置。请参见[配置节点 2](https://help.tableau.com/current/guides/enterprise-deployment/zh-cn/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 <target>`

例如，若要切换到节点 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 历史记录时，请验证指定 Mellon 配置文件路径的 `tsm configuration set` 命令是否准确映射到您在独立网关上复制文件的文件路径。
- 独立网关上的 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 topology external-services gateway update -c tsig.json` 之前运行 `tsm stop`。tsig.json 更新后，运行 `tsm start`。
- `error.log`：除其他条目外，此日志还包括 SAML 和 Mellon 错误。

#### Tableau Server tabadminagent 日志文件

`tabadminagent`（而不是 `tabadmincontroller`）文件集是解决独立网关相关错误的唯一相关日志文件。

您必须找到已将独立网关错误记录到 `tabdminagent`的位置。这些错误可以在任何节点上，但它们只在一个节点上。在 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 存根文件

独立网关管理 Apache 的 httpd 配置。通常可以修复暂时问题的一个通用操作是重新加载 httpd 存根文件，该文件是底层 Apache 配置的种子。在独立网关的两个实例上运行以下命令。

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 文件。访问日志文件的存储位置为 `/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` 在两个独立网关上是否都返回“Syntax 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 文件的 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。