客戶代管架構解決方案：元件操作說明

本頁將探討 Looker 架構中特定元件的常見做法，並說明如何在部署中設定這些元件。

Looker 有許多依附元件，用於代管伺服器、處理即時和排程工作負載、追蹤迭代模型開發等。本頁將這些相依項目稱為「元件」，以下各節將詳細說明每個元件：

主機設定

OS 和發行版

Looker 可順利在最常見的 Linux 版本上執行，包括 RedHat、SUSE 和 Debian/Ubuntu。這些發行版本的衍生版本，如果是為了在特定環境中執行而設計及最佳化，一般來說都沒問題。舉例來說， Google Cloud 或 AWS 發行的 Linux 版本都與 Looker 相容。Debian/Ubuntu 是 Looker 社群中使用率最高的 Linux 版本，也是 Looker 支援團隊最熟悉的版本。最簡單的方法是使用 Debian/Ubuntu，或是特定雲端服務供應商提供的衍生自 Debian/Ubuntu 的作業系統。

Looker 會在 Java 虛擬機器 (JVM) 中執行。選擇發行版時，請考量 OpenJDK 11 的版本是否為最新版本。較舊的 Linux 發行版本可能可以執行 Looker，但 Looker 用於特定功能所需的 Java 版本和程式庫必須為最新版本。如果 JVM 不包含所有建議的 Looker 程式庫和版本，Looker 就無法正常運作。Looker 需要 Java HotSpot 1.8 更新 161 以上版本或 Java OpenJDK 11.0.12 以上版本。

CPU 與記憶體

4x16 (4 個 CPU 和 16 GB RAM) 節點就足以建構開發系統，或小型團隊用於測試 Looker 的基礎執行個體。不過，這通常不足以用於正式工作環境。根據我們的經驗，16x64 節點 (16 個 CPU 和 64 GB RAM) 在價格和效能之間取得了良好平衡。超過 64 GB 的 RAM 可能會影響效能，因為垃圾收集事件是單執行緒的，並會暫停執行所有其他執行緒。

磁碟儲存空間

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，建議將 4 到 5 GB 的記憶體分配給 Java，並將 800 MB 的記憶體分配給 Meta。對於較大的機器，可為作業系統分配較少的記憶體比例。舉例來說，如果機器的總記憶體為 60 GB，建議您將 36 GB 分配給 Java，並將 1 GB 分配給 Meta。請務必注意，Java 的記憶體配置通常應與機器的總記憶體量成比例，但 1 GB 的 Meta 應已足夠。

此外，由於 Looker 會與其他處理程序 (例如用於轉譯的 Chromium) 共用系統資源，因此應根據預期的轉譯負載和機器大小，選取要分配給 Java 的記憶體量。如果算繪負載預期偏低，則可為 Java 分配較大的總記憶體比例。舉例來說，在總記憶體為 60 GB 的機器上，Java 可安全地分配到 46 GB，這比一般建議的 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 有許多執行緒集區。這些執行緒集區範圍涵蓋核心網頁伺服器，以及排程、轉譯和外部資料庫連線等專屬子服務。視您的業務工作流程而定，您可能需要修改這些集區的預設設定。特別是，請特別考量「客戶代管基礎架構架構模式和做法」頁面中提到的叢集拓樸。

高排程處理量選項

針對所有非調度器節點，請將 --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 個並行轉譯工作。如果節點專門用於轉譯，且未納入負責處理互動工作負載的負載平衡器集區，則可減少核心 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 或 Explore 時，Looker 就會檢查資料庫，確認使用者是否仍登入、是否具備存取資料的權限、是否具備執行 Look 或 Explore 的權限，等等。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。我們知道 MariaDB 與 MySQL 的對應版本可與 Looker 搭配運作，但這些版本並非由 Looker 工程團隊開發或測試，因此我們不支援或保證這些版本的功能。

雲端版本

如果您在雲端基礎架構中代管 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 記錄檔

交易完成後，資料庫可以選擇更新實際檔案中的資料，也可以將交易詳細資料儲存在記錄中。如果資料庫在更新資料檔案前發生當機情形，您可以「重播」記錄檔來套用變更。寫入記錄檔案是小型附加作業。在提交時附加至記錄檔，然後將多項資料檔案變更合併為批次，並在單一 I/O 作業中寫入，這麼做效率較高。當記錄檔已滿時，資料庫必須暫停處理新的交易，並將所有變更的資料寫回磁碟。

一般來說，InnoDB 記錄檔的大小應足以容納 1 小時的交易。

InnoDB 記錄檔通常有兩個。這些值應約為 InnoDB 緩衝區集區的 25%。以 32 GB 緩衝區的範例資料庫為例，InnoDB 記錄檔總大小應為 8 GB，也就是每個檔案 4 GB。

[mysqld]
...
innodb_log_file_size=8GB

設定 InnoDB IO 容量

MySQL 會限制寫入磁碟的速度，以免伺服器不堪負荷。預設值對大多數伺服器來說都偏保守。為獲得最佳效能，請使用 sysbench 公用程式來評估資料磁碟的隨機寫入速度，然後使用該值設定 I/O 容量，讓 MySQL 更快速地寫入資料。

在雲端代管系統中，雲端供應商應能回報用於資料儲存的磁碟效能。針對自行代管的 MySQL 伺服器，請以每秒 I/O 作業次數 (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

設定刷新方法

作業系統通常會為寫入磁碟的作業進行緩衝。由於 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 的詳細設定步驟，請參閱 Looker 社群的「在 Looker 中使用 GitLab 進行版本控制」一文。如果您的存放區包含子群組，您可以使用 HTTPS 或 SSH 格式將這些子群組新增至存放區網址：

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


[email protected]:accountname/subgroup/reponame.git

此外，您可以透過三種方式在 GitLab 中儲存 Looker 產生的安全殼層金鑰：使用者安全殼層金鑰、存放區部署金鑰或全域共用部署金鑰。如需更深入的說明，請參閱 GitLab 說明文件。

Google Cloud 來源

如要瞭解如何設定 Git 與 Cloud Source Repositories，請參閱「在 Looker 中使用 Cloud Source Repositories 進行版本管控」社群文章。

Bitbucket Cloud

如要瞭解如何設定 Bitbucket 與 Bitbucket Cloud，請參閱「在 Looker 中使用 Bitbucket 進行版本管控」社群文章。自 2021 年 8 月起，Bitbucket Cloud 不支援部署 webhook 的機密資料。

Bitbucket Server

如要使用 Bitbucket Server 的提取要求，您可能需要完成下列步驟：

  1. 開啟提取要求時，Looker 會自動使用網址中的預設通訊埠號碼 (7999)。如果您使用自訂的連接埠號碼，就必須手動在網址中替換連接埠號碼。
  2. 您必須觸發專案的部署 webhook，才能將 Looker 中的實際工作環境分支與存放區的主要分支同步。

Phabricator 擴散

如要瞭解如何透過 Phabricator 設定 Git，請參閱「設定 Phabricator 和 Looker 以進行版本控制」社群貼文。

網路

連入連線

Looker 網頁應用程式

根據預設，Looker 會監聽通訊埠 9999 上的 HTTPS 要求。Looker 使用自行簽署的憑證，其 CN 為 self-signed.looker.com。您也可以將 Looker 伺服器設定為執行下列操作：

  1. 使用 --ssl-provided-externally-by=<s> 啟動標記，接受來自 SSL 終止負載平衡器/Proxy 的 HTTP 連線。這個值應設為 Proxy 的 IP 位址，或是可在本機解析為 Proxy IP 位址的主機名稱。Looker 只會接受來自這個 IP 位址的 HTTP 連線。
  2. 使用客戶提供的 SSL 憑證，並搭配 --ssl-keystore=<s> 啟動標記。

Looker API

Looker API 會監聽 19999 通訊埠。如果安裝程序需要存取 API，則負載平衡器應具備必要的轉送規則。與主要網頁應用程式相同，SSL 也需要考量以下事項。建議您使用與網頁應用程式不同的連接埠。

負載平衡器

負載平衡器通常會使用客戶的憑證，在通訊埠 443 接受 HTTPS 要求，然後使用自行簽署的憑證或 HTTP，將要求轉送至通訊埠 9999 的 Looker 伺服器節點。如果負載均衡器使用 Looker 自行簽署的憑證，則必須設定為接受該憑證。

閒置連線和逾時

使用者在 Looker 中啟動大型要求時，可能會導致查詢在資料庫中執行時產生高額費用。如果使用者以任何方式放棄該要求 (例如關閉筆電、與網路中斷連線，或關閉瀏覽器中的該分頁)，Looker 就會想知道並終止該資料庫查詢。

為處理這種情況，當用戶端網頁應用程式提出執行資料庫查詢的要求時，瀏覽器會使用長效 HTTP 要求，向 Looker 伺服器開啟通訊端連線。這個連線會保持開啟和閒置狀態。如果用戶端網頁應用程式以任何方式終止或中斷連線，這個 Socket 就會中斷連線。伺服器會發現該連線已中斷，並取消任何相關的資料庫查詢。

負載平衡器通常會注意到這些閒置的連線，並將其終止。為了有效執行 Looker，您必須設定負載平衡器，讓此連線保持開放狀態，直到使用者執行最長的查詢為止。建議設定的逾時時間至少為 60 分鐘。

傳出連線

Looker 伺服器可對所有資源 (包括公開網際網路) 享有無限制的傳出存取權。這可簡化許多工作，例如安裝 Chromium，因為這項作業需要存取 Linux 發行版的套件存放區。

以下是 Looker 可能需要建立的傳出連線。

內部資料庫連線

根據預設，MySQL 會監聽通訊埠 3306 的連線。Looker 節點必須能夠透過這個通訊埠啟動 MySQL 連線。視存放區的代管方式而定，您可能需要穿越防火牆。

外部服務

您可以在公開網際網路上使用 HTTPS 存取 Looker 遙測和授權伺服器。您可能需要將 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、Action Server 和 Webhook

許多排程器目的地 (尤其是 webhook，以及在 Looker 管理面板中啟用的 webhook) 都會使用 HTTPS 要求傳送資料。

  • 對於 webhook，這些目的地是由使用者在執行階段指定，可能與防火牆封鎖傳出連線的目標相違。
  • 對於動作中樞，這些要求會傳送至 actions.looker.com。詳情請參閱 Looker Action Hub 設定說明文件。
  • 對於其他動作伺服器，這些要求會傳送至管理員在 Looker 管理面板中，在動作伺服器設定中指定的網域。

Proxy 伺服器

如果無法直接存取公開網際網路，您可以將以下行程式碼新增至 lookerstart.cfg，將 Looker 設為使用 Proxy 伺服器處理 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 進行，因此如果您使用 Proxy 伺服器，且執行個體已叢集，通常會將叢集中所有節點的 IP 位址/主機名稱新增至 Dhttp.nonProxyHosts 引數。

節點間通訊

內部主機 ID

在叢集內，每個節點都必須能夠與其他節點通訊。為此，您可以在啟動設定中指定每個節點的主機名稱或 IP 位址。節點啟動時，這個值會寫入 MySQL 存放區。叢集中的其他成員就能參照這些值，與這個節點進行通訊。如要在啟動設定中指定主機名稱或 IP 位址，請在 lookerstart.cfg 的 LOOKERARGS 環境變數中加入 -H node1.looker.example.com。

由於每個節點的電腦名稱不得重複，因此 lookerstart.cfg 檔案在每個執行個體上都必須不重複。除了將主機名稱或 IP 位址硬式編碼外，您也可以使用 hostname -I 或 hostname --fqdn 指令，在執行階段找出這些項目。如要實作這項操作，請在 lookerstart.cfg 的 LOOKERARGS 環境變數中新增 -H $(hostname -I) 或 -H $(hostname --fqdn)。

內部通訊埠

除了分別用於 Web 和 API 伺服器的 9999 和 19999 連接埠外，叢集節點也會透過訊息中介服務進行通訊，該服務使用 1551 和 61616 連接埠。通訊埠 9999 和 19999 必須開放給使用者流量，但 1551 和 61616 必須在叢集節點之間開放。