本頁將探討 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) 在價格和效能之間取得了理想平衡。如果 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，建議將 4 到 5 GB 分配給 Java，800 MB 分配給 Meta。如果是較大的機器，可分配給作業系統的記憶體比例會較低。舉例來說，如果機器的總記憶體為 60 GB，建議將 36 GB 分配給 Java，1 GB 分配給 Meta。請務必注意，Java 的記憶體配置通常應隨著機器的總記憶體量調整，但 Meta 應足以達到 1 GB。
此外，由於 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 是多執行緒應用程式，因此有多個執行緒集區。這些執行緒集區的範圍從核心網頁伺服器到排程、算繪和外部資料庫連線等專門子服務都有。視業務工作流程而定，您可能需要修改這些集區的預設設定。特別是「客戶代管基礎架構架構模式與做法」頁面中提及的叢集拓撲，有特別的注意事項。
高排程處理量選項
對於所有非排程器節點，請在 lookerstart.cfg 中將 --scheduler-threads=0 新增至 LOOKERARGS 環境變數。如果沒有排程器執行緒，這些節點就不會執行任何排定的工作。
針對所有專屬排程器節點，在 lookerstart.cfg 中將 --scheduler-threads=<n> 新增至 LOOKERARGS 環境變數。Looker 預設有 10 個排程器執行緒，但可以增加至 <n> 個。有了 <n> 個排程器執行緒，每個節點就能同時執行 <n> 個排程工作。一般來說，建議將 <n> 保持在 CPU 數量的 2 倍以下。建議使用的最大主機是具有 16 個 CPU 和 64 GB 記憶體的主機，因此排程器執行緒的上限應小於 32。
高算繪處理量選項
對於所有非算繪節點，請在 lookerstart.cfg 中將 --concurrent-render-jobs=0 新增至 LOOKERARGS 環境變數。如果沒有算繪器節點，這些節點就不會執行任何算繪作業。
針對所有專屬算繪節點，請在 lookerstart.cfg 中將 --concurrent-render-jobs=<n> 新增至 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% 供一般 OS 使用，剩下 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 工程團隊開發或測試，因此不支援或保證功能。
雲端版本
如果您在雲端基礎架構中代管 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 資料檔案狀態的記憶體總量。如果伺服器專門用於執行 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
設定清除方法
作業系統通常會緩衝處理寫入磁碟的作業。由於 MySQL 和 OS 都會緩衝處理，因此效能會受到影響。減少一層緩衝區的排清方法可以提升效能。
[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 git@gitlab.com:accountname/subgroup/reponame.git
此外，您還能透過三種不同方式，在 GitLab 中儲存 Looker 產生的 SSH 金鑰：使用者 SSH 金鑰、存放區部署金鑰或全域共用部署金鑰。如需更深入的說明，請參閱 GitLab 說明文件。
Google Cloud 來源
如需如何透過 Cloud Source Repositories 設定 Git，請參閱 這篇 Looker 社群文章。
Bitbucket Cloud
如需透過 Bitbucket Cloud 設定 Git 的步驟，請參閱「在 Looker 中使用 Bitbucket 進行版本控管」社群貼文。自 2021 年 8 月起，Bitbucket Cloud 不支援部署 Webhook 的密鑰。
Bitbucket Server
如要搭配 Bitbucket Server 使用提取要求，可能需要完成下列步驟：
- 開啟提取要求時，Looker 會自動在網址中使用預設的通訊埠號碼 (7999)。如果您使用自訂連接埠號碼，則必須手動取代網址中的連接埠號碼。
- 您必須點選專案的部署 Webhook，才能將 Looker 中的正式版分支與存放區的主要分支同步。
Phabricator 擴散
如需透過 Phabricator 設定 Git 的步驟，請參閱這篇社群貼文。
網路
傳入連線
Looker 網頁應用程式
根據預設，Looker 會監聽通訊埠 9999 的 HTTPS 要求。Looker 使用的自行簽署憑證，其 CN 為 self-signed.looker.com。您也可以設定 Looker 伺服器執行下列操作：
- 使用
--ssl-provided-externally-by=<s>啟動旗標，接受來自 SSL 終止負載平衡器/Proxy 的 HTTP 連線。值應設為 Proxy 的 IP 位址，或可在本機解析為 Proxy IP 位址的主機名稱。Looker 只會接受來自這個 IP 位址的 HTTP 連線。 - 使用客戶提供的 SSL 憑證，並搭配
--ssl-keystore=<s>啟動標記。
Looker API
Looker API 會監聽通訊埠 19999。如果安裝作業需要存取 API，負載平衡器就應具備必要的轉送規則。適用的 SSL 考量事項與主要網頁應用程式相同。建議使用與網頁應用程式不同的連接埠。
負載平衡器
負載平衡器通常會使用客戶的憑證，在通訊埠 443 接受 HTTPS 要求，然後使用自行簽署的憑證或 HTTP，將要求轉送至通訊埠 9999 的 Looker 伺服器節點。如果負載平衡器使用 Looker 自行簽署的憑證，則必須設定為接受該憑證。
閒置連線和逾時
使用者在 Looker 中發出大型要求時，可能會導致查詢在資料庫中執行時耗費大量資源。如果使用者以任何方式放棄該要求 (例如關上筆電螢幕、中斷網路連線，或關閉瀏覽器中的該分頁)，Looker 會想知道並終止該資料庫查詢。
為處理這種情況，當用戶端 Web 應用程式要求執行資料庫查詢時，瀏覽器會使用長期有效的 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 設定，改用其他郵件處理常式。
動作中樞、動作伺服器和 Webhook
許多排程目的地 (尤其是 Webhook 和Looker 管理面板中啟用的目的地) 都會透過 HTTPS 要求傳送資料。
- 如果是 Webhook，這些目的地是由使用者在執行階段指定，可能與防火牆輸出連線的目標相違背。
- 如果是動作中心，這些要求會傳送至
actions.looker.com。詳情請參閱 Looker Action Hub 設定說明文件。 - 如果是其他動作伺服器，管理員會在 Looker Admin 面板中，將這些要求傳送至動作伺服器設定中指定的網域。
Proxy 伺服器
如果無法直接連上公開網際網路，您可以設定 Looker 使用 Proxy 伺服器發出 HTTP(S) 要求，方法是在 lookerstart.cfg 中加入類似下列的程式碼行：
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 中將 -H node1.looker.example.com 新增至 LOOKERARGS 環境變數。LOOKERARGS
由於每個節點的主機名稱不得重複，因此每個執行個體上的 lookerstart.cfg 檔案不得重複。除了將主機名稱或 IP 位址硬式編碼，您也可以使用 hostname -I 或 hostname --fqdn 指令在執行階段找出這些項目。如要實作這項功能，請在 lookerstart.cfg 中將 -H $(hostname -I) 或 -H $(hostname --fqdn) 新增至 LOOKERARGS 環境變數。
內部通訊埠
除了用於網頁和 API 伺服器的 9999 和 19999 埠之外，叢集節點也會透過訊息代理服務彼此通訊，該服務會使用 1551 和 61616 埠。通訊埠 9999 和 19999 必須對使用者流量開放，但通訊埠 1551 和 61616 必須在叢集節點之間開放。