请注意，您正在查看 Looker 文档。如需查看 Looker Studio 文档，请访问 https://support.google.com/looker-studio。

此页面由 Cloud Translation API 翻译。

客户托管的架构解决方案：组件演示

本页介绍了 Looker 架构的特定组件的常见做法，并介绍了如何在部署中配置这些组件。

Looker 有许多依赖项，用于托管服务器、处理临时和预定的作业、跟踪迭代模型开发等。在本页中，此类依赖项称为“组件”。以下各部分对每个组件进行了详细介绍：

主机配置
JVM 配置
Looker 启动选项
内部（后端）数据库
Git 服务
网络

主机配置

操作系统和分发

Looker 在最常见的 Linux 版本（RedHat、SUSE 和 Debian/Ubuntu）上运行良好。这些发行版的派生版本通常可以正常运行，因为它们是专为在特定环境中运行而设计和优化的。例如，Google Cloud 或 AWS 发行版 Linux 与 Looker 兼容。Debian/Ubuntu 是 Looker 社区中使用频率最高的 Linux 版本，其中 Debian/Ubuntu 是 Looker 支持团队最熟悉的版本。最简单的方法是使用 Debian/Ubuntu 或从 Debian/Ubuntu 派生的特定云服务提供商的操作系统。

Looker 在 Java 虚拟机 (JVM) 中运行。选择发行版时，请考虑 OpenJDK 11 版本是否为最新版本。较低版本的 Linux 发行版可能能够运行 Looker，但 Looker 运行特定功能所需的 Java 版本和库必须是最新版本。如果 JVM 未包含所有建议的 Looker 库和版本，Looker 将无法正常运行。Looker 需要 Java HotSpot 1.8 Update 161+ 或 Java OpenJDK 11.0.12+。

CPU 和内存

4x16（4 个 CPU 和 16 GB RAM）节点足以满足小型团队使用的开发系统或 Looker 基本测试实例的需求。不过，对于生产环境，这通常还不够。根据我们的经验，16x64 节点（16 个 CPU 和 64 GB RAM）在价格与性能之间取得了较好的平衡。RAM 超过 64 GB 可能会影响性能，因为垃圾回收事件是单线程的，会暂停所有其他线程来执行。

磁盘存储

通常，100 GB 的磁盘空间对于生产系统来说已经足够。

集群注意事项

Looker 在 Java JVM 上运行，并且 Java 可能难以管理大于 64 GB 的内存。一般来说，如果需要更多容量，您应向集群中添加更多 16x64 节点，而不是将节点大小增加到超过 16x64。我们也可能更倾向于使用集群架构来提高可用性。

在集群中，Looker 节点需要共享文件系统的某些部分。共享的数据包括：

LookML 模型
开发者 LookML 模型
Git 服务器连接

由于文件系统是共享的，并且托管着多个 Git 代码库，因此处理并发访问和文件锁定至关重要。文件系统必须符合 POSIX 标准。网络文件系统 (NFS) 已知可行，并且可在 Linux 中轻松使用。您应该再创建一个 Linux 实例，并配置 NFS 以共享磁盘。默认 NFS 可能存在单点故障，因此请考虑进行故障切换设置或高可用性设置。

Looker 元数据也需要集中管理，因此其内部数据库必须迁移到 MySQL。这可以是 MySQL 服务，也可以是专用 MySQL 部署。本页的内部（后端）数据库部分会对此进行更详细的介绍。

JVM 配置

Looker JVM 设置在 Looker 启动脚本中定义。进行任何更新后，必须重启 Looker 才能更改清单。默认配置如下：

java \
  -XX:+UseG1GC -XX:MaxGCPauseMillis=2000 \
  -Xms$JAVAMEM -Xmx$JAVAMEM \
  -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCTimeStamps \
  -Xloggc:/tmp/gc.log ${JAVAARGS} \
  -jar looker.jar start ${LOOKERARGS}

资源

资源设置在 Looker 启动脚本中定义。

JAVAMEM="2300m"
METAMEM="800m"

JVM 的内存分配需要考虑运行 Looker 的操作系统开销。一般经验法则是，最多可为 JVM 分配总内存的 60%，但根据机器大小，还需注意一些事项。对于裸机总内存为 8 GB 的机器，我们建议为 Java 分配 4-5 GB 的内存，为 Meta 分配 800 MB 的内存。对于较大的机器，可以为操作系统分配较小比例的内存。例如，对于总内存为 60 GB 的机器，我们建议为 Java 分配 36 GB 内存，为 Meta 分配 1 GB 内存。请务必注意，Java 的内存分配通常应随计算机的总内存而扩展，但 Meta 应足以满足 1 GB 内存的需求。

此外，由于 Looker 会与 Chromium 等其他进程共享系统资源以进行渲染，因此应根据预期的渲染负载和机器大小选择分配给 Java 的内存量。如果预计渲染负载很低，则可以为 Java 分配更大的总内存份额。例如，在总内存为 60 GB 的机器上，可以将 46 GB 的内存安全地分配给 Java，这高于一般建议的 60%。适合每个部署的确切资源分配因情况而异，因此请将 60% 用作基准，并根据使用情况进行调整。

垃圾回收

Looker 倾向于使用适用于其 Java 版本的最现代垃圾回收器。默认情况下，垃圾回收超时时间为 2 秒，但您可以通过修改启动配置中的以下选项来更改此时间：

-XX:MaxGCPauseMillis=2000

在具有多个核心的大型机器上，垃圾回收超时时间可能会缩短。

日志

默认情况下，Looker 垃圾回收日志存储在 /tmp/gc.log 中。您可以通过修改启动配置中的以下选项来更改此设置：

-Xloggc:/tmp/gc.log

JMX

管理 Looker 可能需要监控，以帮助优化资源配置。我们建议使用 JMX 监控 JVM 内存用量。

Looker 启动选项

启动选项存储在名为 lookerstart.cfg 的文件中。此文件来自启动 Looker 的 Shell 脚本。

线程池

作为一个多线程应用，Looker 具有多个线程池。这些线程池涵盖核心 Web 服务器，以及调度、渲染和外部数据库连接等专用子服务。根据您的业务工作流，您可能需要修改这些池的默认配置。特别是对于客户托管的基础架构架构模式和做法页面中提到的集群拓扑，您需要注意一些特殊事项。

高调度吞吐量选项

对于所有非调度程序节点，请将 --scheduler-threads=0 添加到 lookerstart.cfg 中的 LOOKERARGS 环境变量。如果没有调度器线程，任何预定作业都不会在这些节点上运行。

对于所有专用调度程序节点，请将 --scheduler-threads=<n> 添加到 lookerstart.cfg 中的 LOOKERARGS 环境变量。Looker 默认启动 10 个调度程序线程，但可以增加到 <n>。使用 <n> 个调度程序线程时，每个节点都能够执行 <n> 个并发调度作业。通常建议将 <n> 保持在 CPU 数量的 2 倍以下。推荐的最大主机是具有 16 个 CPU 和 64 GB 内存的主机，因此调度程序线程的上限应小于 32。

高渲染吞吐量选项

对于所有非渲染节点，将 --concurrent-render-jobs=0 添加到 lookerstart.cfg 中的 LOOKERARGS 环境变量。如果没有渲染程序节点，则不会在这些节点上运行任何渲染作业。

对于所有专用渲染节点，请将 --concurrent-render-jobs=<n> 添加到 lookerstart.cfg 中的 LOOKERARGS 环境变量。Looker 默认从两个渲染线程开始，但可以增加到 <n>。使用 <n> 个渲染线程时，每个节点都能够执行 <n> 个并发渲染作业。

每个渲染作业都会使用大量内存。每个渲染作业的预算约为 2 GB。例如，如果为核心 Looker 进程 (Java) 分配了总内存的 60%，而剩余内存的 20% 留给操作系统，则剩余的 20% 将用于渲染作业。在 64 GB 的机器上，剩下 12 GB，足以支持 6 个并发渲染作业。如果某个节点专用于渲染，并且不包含在处理 Interactive 作业的负载均衡器池中，则可以减少核心 Looker 进程内存，以便处理更多渲染作业。在 64 GB 的机器上，您可以将大约 30%（20 GB）的内存分配给 Looker 核心进程。为常规操作系统预留 20% 的空间，剩余 50% (32 GB) 用于渲染，这足以满足 16 个并发渲染作业的需求。

内部（后端）数据库

Looker 服务器会维护有关其自身配置、数据库连接、用户、群组和角色、文件夹、用户定义的 Look 和信息中心的信息，以及内部数据库中的各种其他数据。

对于中等大小的独立 Looker 实例，此数据存储在 Looker 进程本身嵌入的内存 HyperSQL 数据库中。此数据库的数据存储在 <looker install directory>/.db/looker.script 文件中。虽然这种数据库方便且轻量，但在高负载情况下会出现性能问题。因此，我们建议从远程 MySQL 数据库入手。如果这种方法不可行，我们建议在 ~/looker/.db/looker.script 文件达到 600 MB 后迁移到远程 MySQL 数据库。集群必须使用 MySQL 数据库。

Looker 服务器会对 MySQL 数据库执行许多小型读写操作。每当用户运行 Look 或探索时，Looker 都会检查数据库，以验证用户是否仍处于登录状态、用户是否有权访问数据、用户是否有权运行 Look 或探索等。Looker 还会将数据写入 MySQL 数据库，例如运行的实际 SQL 以及请求的开始和结束时间。用户与 Looker 应用之间的一次互动可能会导致对 MySQL 数据库进行 15 到 20 次小型读写。

MySQL

MySQL 服务器应为 8.0.x 版本，并且必须配置为使用 utf8mb4 编码。必须使用 InnoDB 存储引擎。如需查看 MySQL 的设置说明，以及有关如何将数据从现有 HyperSQL 数据库迁移到 MySQL 的说明，请参阅将 Looker 后端数据库迁移到 MySQL 文档页面。

配置 Looker 以使用 MySQL 时，必须创建包含连接信息的 YAML 文件。将 YAML 文件命名为 looker-db.yml，并在 lookerstart.cfg 文件的 LOOKERARGS 部分中添加设置 -d looker-db.yml。

MariaDB

MySQL 采用双重许可，既可作为开源产品，也可作为商业产品。Oracle 一直在改进 MySQL，并将 MySQL 分支为 MariaDB。MySQL 的 MariaDB 等效版本已知可与 Looker 配合使用，但它们并不是为 Looker 工程团队而开发或进行测试；因此，我们无法为其功能提供支持，也无法保证其相关功能。

Cloud 版本

如果您在云基础架构中托管 Looker，则在同一云基础架构中托管 MySQL 数据库是合乎逻辑的做法。三大云供应商：Amazon AWS、Microsoft Azure 和 Google Cloud。云服务提供商负责管理 MySQL 数据库的大部分维护和配置，并提供管理备份和快速恢复等服务。以下产品已知可与 Looker 搭配使用。

系统活动查询

MySQL 数据库用于存储有关用户如何使用 Looker 的信息。任何有权查看系统活动模型的 Looker 用户都可以访问多个预构建的 Looker 信息中心，以分析此类数据。用户还可以访问 Looker 元数据的探索，以构建其他分析。MySQL 数据库主要用于执行小型、快速的“操作”查询。大型、缓慢的“分析”式模型系统活动模型生成的查询可能会与这些操作查询竞争，从而导致 Looker 运行缓慢。

在这些情况下，可以将 MySQL 数据库复制到另一个数据库。自助管理型系统和某些云端托管型系统都提供向其他数据库复制的基本配置。如何配置复制不在本文档的讨论范围之内。

为了将副本用于系统活动查询，您需要创建 looker-db.yml 文件的副本（例如名为 looker-usage-db.yml），将其修改为指向副本，并将设置 --internal-analytics-connection-file looker-usage-db.yml 添加到 lookerstart.cfg 文件的 LOOKERARGS 部分。

系统活动查询可以针对 MySQL 实例或 Google BigQuery 数据库运行。它们未针对其他数据库进行测试。

MySQL 性能配置

除了将 Looker 后端数据库迁移到 MySQL 所需的设置之外，高活跃集群可能还需要进行额外的调整和配置。您可以对 /etc/my.cnf 文件进行这些设置，也可以通过 Google Cloud 控制台（适用于云端管理的实例）进行设置。

my.cnf 配置文件分为多个部分。本部分讨论的以下设置更改在 [mysqld] 部分进行。

设置 InnoDB 缓冲池大小

InnoDB 缓冲区池大小是用于在内存中存储 InnoDB 数据文件状态的总 RAM。如果服务器专用于运行 MySQL，则 innodb_buffer_pool_size 应设置为系统总内存的 50%-70%。

如果数据库的总大小很小，则可以将 InnoDB 缓冲池的大小设置为数据库的大小，而不是 50% 或更大的内存。

在此示例中，服务器有 64 GB 的内存；因此，InnoDB 缓冲区应介于 32 GB 到 45 GB 之间。通常，分辨率越高越好。

[mysqld]
...
innodb_buffer_pool_size=45G

设置 InnoDB 缓冲池实例

当多个线程尝试搜索大型缓冲区池时，它们可能会争用。为防止这种情况，缓冲区会被划分为更小的单元，不同的线程可以访问这些单元，而不会发生冲突。默认情况下，缓冲池分为 8 个实例。这可能会导致出现 8 线程瓶颈。增加缓冲池实例的数量有助于降低出现瓶颈的几率。您应设置 innodb_buffer_pool_instances，确保每个缓冲区池至少获得 1 GB 的内存。

[mysqld]
...
innodb_buffer_pool_instances=32

优化 InnoDB 日志文件

提交事务时，数据库可以选择更新实际文件中的数据，也可以将事务的详细信息保存在日志中。如果数据库在数据文件更新前崩溃，日志文件可能会“重放”以应用所做的更改。写入日志文件属于一次小批量附加操作。高效做法是在提交时附加到日志，然后批量处理对数据文件的多项更改，并通过单个 IO 操作将它们写入到日志中。当日志文件已满时，数据库必须暂停处理新事务，并将所有更改的数据写回磁盘。

一般来说，InnoDB 日志文件应该足够大，能够包含 1 小时的事务。

通常有两个 InnoDB 日志文件。它们应占 InnoDB 缓冲池的 25% 左右。对于具有 32 GB 缓冲池的示例数据库，InnoDB 日志文件的总数据应为 8 GB，即每个文件 4 GB。

[mysqld]
...
innodb_log_file_size=8GB

配置 InnoDB IO 容量

MySQL 会限制写入磁盘的写入速度，以免服务器超负荷运转。默认值对于大多数服务器来说都比较保守。为获得最佳性能，请使用 sysbench 实用程序测量向数据磁盘的随机写入速度，然后使用该值配置 IO 容量，以便 MySQL 更快地写入数据。

在云托管的系统中，云供应商应该能够报告用于存储数据的磁盘的性能。对于自托管的 MySQL 服务器，以每秒 IO 操作数 (IOPS) 为单位测量随机写入数据磁盘的速度。Linux 实用程序 sysbench 是衡量此功能的一种方法。为 innodb_io_capacity_max 使用该值，为 innodb_io_capacity 使用该值的一半到四分之三。因此，在以下示例中，如果我们测量到 800 IOPS，则会看到相应值。

[mysqld]
...
innodb_io_capacity=500
innodb_io_capacity_max=800

配置 InnoDB 线程

MySQL 将为提供的每个客户端打开至少一个线程。如果有许多客户端同时连接，则可能会导致系统处理大量线程。这可能会导致系统花在换页上的时间比处理时间更多。

应进行基准化分析来确定理想的线程数。如需进行测试，请将系统 CPU（或 CPU 核心）数量的线程数设为 CPU 数量的 4 倍。对于 16 核系统，此值可能介于 16 到 64 之间。

[mysqld]
...
innodb_thread_concurrency=32

事务持久性

事务值为 1 会强制 MySQL 针对每个事务写入磁盘。如果服务器崩溃，事务不会丢失，但数据库性能会受到影响。将此值设置为 0 或 2 可以提高性能，但可能会丢失几秒钟的数据交易。

[mysqld]
...
innodb_flush_log_at_trx_commit=1

设置 flush 方法

操作系统通常会对写入磁盘的操作进行缓冲。由于 MySQL 和操作系统都进行缓冲，因此会降低性能。减少刷新方法的一层缓冲可以提高性能。

[mysqld]
...
innodb_flush_method=O_DIRECT

为每个表启用一个文件

默认情况下，MySQL 将为所有数据使用单个数据文件。innodb_file_per_table 设置将为每个表创建单独的文件，从而改进性能和数据管理。

[mysqld]
...
innodb_file_per_table=ON

停用元数据统计信息

此设置会禁止收集内部元数据表中的统计信息，从而提高读取性能。

[mysqld]
...
innodb_stats_on_metadata=OFF

停用查询缓存

查询缓存已废弃，因此将 query_cache_size 和 query_cache_type 设置为 0 可将其停用。

[mysqld]
...
query_cache_size=0
query_cache_type=0

扩大联接缓冲区

join_buffer 用于在内存中执行联接。提高此值可以改进某些操作。

[mysqld]
...
join_buffer_size=512KB

扩大临时表和堆大小上限

tmp_table_size 和 max_heap_table_size 会在临时内存表被强制写入磁盘之前，为其设置合理的默认值。

[mysqld
...
tmp_table_size=32MB
max_heap_table_size=32MB

调整表打开缓存

table_open_cache 设置决定了用于存放打开表的文件描述符的缓存大小。table_open_cache_instances 设置会将缓存拆分为多个较小的部分。table_open_cache 中可能会出现线程争用，因此将其拆分为更小的部分有助于提高并发性。

[mysqld]
...
table_open_cache=2048
table_open_cache_instances=16

Git 服务

Looker 旨在与 Git 服务搭配使用，以便对 LookML 文件进行版本管理。支持主要 Git 托管服务，包括 GitHub、GitLab 和 Bitbucket。Git 服务提供商提供额外的增值服务，例如查看代码更改的 GUI，以及对拉取请求和更改审批等工作流的支持。如有必要，Git 可以在普通 Linux 服务器上运行。

如果某个 Git 托管服务因安全规则而不适合您的部署，许多此类服务提供商都提供可在您自己的环境中运行的版本。特别是，GitLab 通常是自托管的，可以作为无许可费用的开源产品使用，也可以作为受支持的许可产品使用。GitHub Enterprise 可作为自托管服务提供，是一款受支持的商业产品。

以下部分列出了最常见服务提供商的细微差异。

GitHub/GitHub Enterprise

设置和测试 Git 连接文档页面使用 GitHub 作为示例。

GitLab/gitlab.com

如需了解 GitLab 的详细设置步骤，请参阅 Using GitLab for version control in Looker（在 Looker 中使用 GitLab 进行版本控制）这篇 Looker 社区帖子。如果您的代码库包含在子组中，则可以使用 HTTPS 或 SSH 格式将这些子组添加到代码库网址中：

https://gitlab.com/accountname/subgroup/reponame

git@gitlab.com:accountname/subgroup/reponame.git

此外，您还可以通过三种不同的方式在 GitLab 中存储 Looker 生成的 SSH 密钥：作为用户 SSH 密钥、作为仓库部署密钥或作为全局共享部署密钥。如需更详细的说明，请参阅 GitLab 文档。

Google Cloud Source

如需了解如何将 Git 与 Cloud Source Repositories 搭配使用，请参阅在 Looker 中使用 Cloud Source Repositories 进行版本控制社区帖子。

Bitbucket Cloud

请参阅在 Looker 中使用 Bitbucket 进行版本控制社区帖子，了解在 Bitbucket Cloud 中设置 Git 的步骤。自 2021 年 8 月起，Bitbucket Cloud 不支持部署 Webhook 中的 Secret。

Bitbucket Server

如需在 Bitbucket Server 中使用拉取请求，您可能需要完成以下步骤：

您打开拉取请求后，Looker 会自动在网址中使用默认端口号 (7999)。如果您使用的是自定义端口号，则需要手动替换网址中的端口号。
您需要点击项目的部署 webhook，将 Looker 中的生产分支与代码库的主分支同步。

Phabricator 扩散

如需了解如何使用 Phabricator 设置 Git，请参阅设置 Phabricator 和 Looker 进行版本控制社区帖子。

网络

传入连接

Looker Web 应用

默认情况下，Looker 会监听端口 9999 上的 HTTPS 请求。Looker 使用 CN 为 self-signed.looker.com 的自签名证书。您也可以将 Looker 服务器配置为执行以下操作：

使用 --ssl-provided-externally-by=<s> 启动标志接受来自 SSL 终止负载均衡器/代理的 HTTP 连接。该值应设置为代理的 IP 地址，或设置为可在本地解析为代理 IP 地址的主机名。Looker 仅接受来自此 IP 地址的 HTTP 连接。
使用客户提供的 SSL 证书，并设置 --ssl-keystore=<s> 启动标志。

Looker API

Looker API 侦听端口 19999。如果安装需要访问 API，则负载均衡器应具有必要的转发规则。SSL 注意事项与主 Web 应用一样。我们建议使用与 Web 应用不同的端口。

负载均衡器

负载均衡器通常用于在端口 443 接受使用客户证书的 HTTPS 请求，然后使用自签名证书或 HTTP 将请求转发到端口 9999 上的 Looker 服务器节点。如果负载平衡器使用的是 Looker 自签名证书，则必须将其配置为接受该证书。

空闲连接和超时

当用户在 Looker 中发起大型请求时，可能会导致在数据库上运行查询的费用很高。如果用户以任何方式放弃该请求（例如通过合上笔记本电脑的机盖、断开网络连接或在浏览器中关闭该标签页），Looker 会希望了解并终止该数据库查询。

为了处理这种情况，当客户端 Web 应用发出运行数据库查询的请求时，浏览器将使用长效 HTTP 请求向 Looker 服务器打开套接字连接。此连接将保持打开和空闲状态。如果客户端 Web 应用以任何方式终止或断开连接，此套接字将断开连接。服务器会看到该断开连接，并取消所有相关的数据库查询。

负载平衡器通常会注意到这些开放的空闲连接并会将其终止。为了有效运行 Looker，必须配置负载均衡器，以允许此连接在用户可以运行最长的查询时保持打开状态。建议超时时间至少为 60 分钟。

出站连接

Looker 服务器可以对所有资源（包括公共互联网）拥有不受限制的出站访问权限。这简化了许多任务，例如安装 Chromium，此操作需要访问 Linux 发行版的软件包仓库。

以下是 Looker 可能需要建立的出站连接。

内部数据库连接

默认情况下，MySQL 会监听端口 3306 上的连接。Looker 节点必须能够通过此端口发起与 MySQL 的连接。根据代码库的托管方式，您可能需要遍历防火墙。

外部服务

Looker 遥测服务器和许可服务器可通过 HTTPS 在公共互联网上使用。从 Looker 节点到 ping.looker.com:443 和 license.looker.com:443 的流量可能需要添加到许可名单中。

数据仓库连接

托管在云中的数据库可能需要使用公共互联网进行连接。例如，如果您使用的是 BigQuery，则可能需要将 accounts.google.com:443 和 www.googleapis.com:443 添加到许可名单中。如果数据库不在您自己的基础架构中，请咨询数据库主机以了解网络详情。

SMTP 服务

默认情况下，Looker 使用 SendGrid 发送出站邮件。这可能需要将 smtp.sendgrid.net:587 添加到许可名单。您还可以在配置中更改 SMTP 设置，以便使用其他邮件处理程序。

Action Hub、操作服务器和网络钩子

许多调度器目标（尤其是 Webhook 和 Looker 管理控制台中启用的调度器目标）都会涉及使用 HTTPS 请求发送数据。

对于 webhook，这些目的地由用户在运行时指定，并且可能与使用防火墙设置出站连接的目标相悖。
对于 Action Hub，这些请求会发送到 actions.looker.com。如需了解详情，请参阅我们的 Looker Action Hub 配置文档。
对于其他 Action 服务器，这些请求由管理员在 Looker 管理控制台中发送到 Action 服务器配置中指定的网域。

代理服务器

如果无法直接访问公共互联网，您可以将如下所示的一行代码添加到 lookerstart.cfg，将 Looker 配置为使用代理服务器处理 HTTP(S) 请求：

JAVAARGS="-Dhttp.proxyHost=myproxy.example.com
  -Dhttp.proxyPort=8080
  -Dhttp.nonProxyHosts=127.0.0.1|localhost
  -Dhttps.proxyHost=myproxy.example.com
  -Dhttps.proxyPort=8080"

请注意，节点间通信是通过 HTTPS 进行的，因此，如果您使用代理服务器且实例是集群的，通常需要将集群中所有节点的 IP 地址/主机名添加到 Dhttp.nonProxyHosts 参数中。

节点间通信

内部主机标识符

在集群内，每个节点必须能够与其他节点通信。为此，需要在启动配置中指定每个节点的主机名或 IP 地址。节点启动时，此值将写入 MySQL 代码库。然后，集群的其他成员可以参考这些值，与此节点进行通信。如需在启动配置中指定主机名或 IP 地址，请将 -H node1.looker.example.com 添加到 lookerstart.cfg 中的 LOOKERARGS 环境变量。

由于每个节点的主机名必须是唯一的，因此 lookerstart.cfg 文件在每个实例上必须是唯一的。除了对主机名或 IP 地址进行硬编码，您还可以使用命令 hostname -I 或 hostname --fqdn 在运行时查找这些内容。如需实现这一点，请将 -H $(hostname -I) 或 -H $(hostname --fqdn) 添加到 lookerstart.cfg 中的 LOOKERARGS 环境变量中。

内部端口

除了分别用于 Web 和 API 服务器的端口 9999 和 19999 外，集群节点还将通过使用端口 1551 和 61616 的消息代理服务相互通信。端口 9999 和 19999 必须对最终用户流量开放，但集群节点之间必须开放端口 1551 和 61616。

客户托管的基础架构架构模式