Elastic Cloud ECE 維運除錯: 維運節點及高可用性的系統架構 | 前端三分鐘

文章目錄

1. 什麼是 Elastic Cloud Enterprise 高可用性 (HA)？
2. Elastic Cloud Enterprise 維運與除錯
1. 2.1. ECE 基本維運除錯
2. 2.2. High Availability
  1. 2.2.1. ECE 配置可用區域
  2. 2.2.2. 建立 Depeloyments
3. 結論與建議
4. FAQ：Elastic Cloud Enterprise 高可用性與維運常見問題

什麼是 Elastic Cloud Enterprise 高可用性 (HA)？

Elastic Cloud Enterprise 高可用性 (HA) 是指透過 ECE 的架構設計，確保 Elastic Stack 服務在面對硬體故障、網路中斷或機房災難時仍能持續運行的能力。其核心定義在於利用可用區域 (Availability Zones)：將系統組件（如 Elasticsearch 節點與 Proxies）分散部署在至少兩到三個相互獨立的實體環境中。ECE 內建了決勝局 (Tiebreakers) 機制，有效防止分散式系統中的「腦裂 (Split Brain)」現象，確保在故障發生時能自動選出新的 Master Node，實現無感切換與穩定的 HA 系統架構。

在現代企業級應用中，系統的穩定性與持續運行是核心要求。Elastic Cloud Enterprise 提供強大的高可用性 (HA) 配置選項，透過巧妙設計的HA 系統架構，確保服務即使面對部分故障也能保持不間斷。

關鍵在於利用地理分散的可用區域 (Availability Zones)，將系統組件部署在相互獨立的環境中，從而有效抵禦單點故障，大幅提升整體Elastic Stack 維運的韌性與可靠性，實現真正的業務連續性。

Elastic Cloud Enterprise 維運與除錯

這篇文章將深入示範如何透過 Elastic Cloud Enterprise (ECE) 配置高可用性 (High Availability) 的HA 系統架構，透過精密的架構設計來消除單點故障的影響，大幅提升網站的可靠性與穩定性。有效的ECE 維運除錯是 Elastic Stack 維運團隊的日常任務，本文將提供實用策略，超越傳統的重啟服務與主管推責，引導您進行更專業的系統維護。

不過一個稱職的維運通常可能還會給力的幫忙

幫忙上補釘或是緊急修復系統異常
日常的系統底層服務或軟體更新
協助啟用新的附加功能，譬如加密傳輸

ECE 基本維運除錯

ECE 目前體驗下來的心得是有好用方便的 UI，而且透過 Docker 容器化的配置也解決了一部分早期分散式系統會遇到的多租戶 (Multi-Tenancy)、腦裂 (split brain) 等等關於實體資源分配搶奪的問題，缺點大概就是目前還沒有 logstash? 不過這次 30 天體驗也沒怎麼使用到，其實大多狀況看起來也都可以處理得很好?

接下來會示範怎麼在不影響原來的服務的前提下，怎麼安全的去維護 ECE 中的元件服務。透過 Cloud UI 的介面，可以初步方便簡單觀察各個服務叢集目前的狀況，符號會有三種顏色，綠色正常、黃色警告、紅色不正常。

符號會有三種顏色，綠色正常、黃色警告、紅色不正常

正常在做維護或除錯的時候，理論上不應該影響原來系統的運行，會影響的話現在的 SA/SD 就應該去撞豆腐了? 接下來的示範中目前有三個可用區域，假設我們今天要進行第二個可用區域的相關維護。

第一個步驟進到 Allocators 選單找到第二個可用區域並啟動維護模式。

Allocators 選擇 zone 2 進行維護

啟動後會發現只有一個服務節點是只存在這個可用區域，這就是這次要移動的對象，有兩個 zone 以上的不需要移動，因為會有 Tiebreakers 幫忙自動做 HA，所以在真的停機之後會影響的就是這個節點的服務。

找出在這個可用區域且只有 1 zone 的服務

嘗試進行移動

移動的時候可能會發現一點小問題

會發現是沒有對應的可用區域可以移動，這邊就先簡單修改 Tag，把 highCPU 改成 false 就可以移動了

移動完成後假裝進行維護，把 Docker 停掉並重開機

會發現可用區域就不見了

等重開機完成後啟用 Docker 取消維護服務後，Tiebreakers 會自動讓節點服務恢復，收工 🎉🎉🎉

High Availability

ECE 的高可用性主要是透過可用區域 (availability zones) 來做到容錯與高可用性的，可用區域可以是任何雲端或是實體機台，每個區域皆由一或多個配備獨立電力、冷卻系統及網路的資料中心所組成，且不被其他區域的狀況影響，像是如果地震導致台北區停機，東京區系統應該還是要維持正常。

ECE 配置可用區域

安裝時透過 --availability-zone 這個指令來加入可用區域，安裝步驟如下:

安裝第一台，跟之前一樣安裝完之後會有帳號、密碼還有 token 相關訊息，記得存好，指定 --availability-zone myzone1。

bash <(curl -fsSL https://download.elastic.co/cloud/elastic-cloud-enterprise.sh) install --cloud-enterprise-version 2.1.1 --availability-zone myzone1

安裝第一台成功的訊息

安裝第一台成功

安裝第二台，會用到剛剛安裝成功得到的 token，剛剛存下來的訊息也有提醒我們要記得去設定角色，指定 --availability-zone myzone2，安裝完成後透過 GUI 設定相關的 role。

bash <(curl -fsSL https://download.elastic.co/cloud/elastic-cloud-enterprise.sh) install --cloud-enterprise-version 2.1.1 --availability-zone myzone2 --roles allocator --coordinator-host <IP> --roles-token <TOKEN>

安裝第二台成功

透過 Cloud UI Runners 去幫新的 Runner 配置角色

直接全部勾選

安裝第三台，如果想先指定相關的 role，可以透過指令在第一台先產生特定 token: curl -k -H 'Content-Type: application/json' -u admin:<PASSWORD> https://localhost:12443/api/v1/platform/configuration/security/enrollment-tokens -d '{ "persistent": false, "roles": ["allocator", "coordinator", "director", "proxy"] }'

用剛剛產生的 token 安裝第三台: bash <(curl -fsSL https://download.elastic.co/cloud/elastic-cloud-enterprise.sh) install --cloud-enterprise-version 2.1.1 --availability-zone myzone3 --roles "allocator,coordinator,director,proxy" --coordinator-host <IP> --roles-token <TOKEN>

產生成功

建立 Depeloyments

配置完可用區域後，就可以建立一個 Depeloyments，選擇 2 zones 測試。

建立一個 Depeloyments

建立成功後會發現另外一個 zone 多出一個 Tiebreakers、Master-eligible 的標籤，所以可以看出 Production 環境最少就是需要三個可用區域，選了 2 zones 的時候會自動把第三個設定成 tiebreaker，決勝局 (Tiebreakers) 的機制在 ECE 中是用來避免分散式架構中的 split brain，腦裂 (split brain) 是指在 HA 的系統架構中，兩個節點的溝通中斷時，本來對外是一個整體的節點分裂成兩個，並且開始搶奪共享的資源，導致系統產生錯誤或是效能下降。

一個整體的節點通常只會有一個 Master Node 主導，其他節點配合，所以需要透過配置 (n/2) + 1 以上的節點來確保法定票數 (quorum) 還有一個第三方仲裁者 (Tiebreakers)，當 Master Node 故障出現分裂問題時，就可以透過投票的機制選出新的 Master Node 去取代，Master node 主要是負責新增建立索引、確認節點歸屬的 cluster、決定部屬新節點的位置，Master-eligible 標籤則代表不只有投票功能，也有可能會變成新的 master node。

決勝局 (Tiebreakers)

結論與建議

安裝教學文件

官方的相關建議

每個可用區域中至少要有一個 Runner 有 director、coordinator roles
每個可用區域中，可以有多個 Runners，確認各區域加起來有足夠的 allocator role 即可
如果 clusters 夠多，可以讓 Master Nodes 不需要去處理檢索或是儲存建立索引的工作
一台實體機只能容納一個可用區域，避免一台時體機壞了就讓系統停機
狀況允許的話，特殊角色可以分別設置在獨立的 Runners，減少未來擴充時的問題
至少每個可用區域都要有一個甚至多個 Runners 要有 Proxy Role

FAQ：Elastic Cloud Enterprise 高可用性與維運常見問題

Q1：為什麼生產環境建議至少配置 3 個可用區域 (AZ)？

A：在 HA 系統架構 中，3 個可用區域能提供最佳的容錯能力。即使一個區域完全斷電，剩餘的兩個區域仍能達成法定票數 (Quorum)，選出新的 Master 節點並維持 Elastic Stack 維運 正常。若只配置 2 個 AZ，一旦其中之一故障，系統可能會因無法投票而陷入停擺。

Q2：什麼是「腦裂 (Split Brain)」？ECE 如何防範？

A：腦裂是指叢集中的節點因網路中斷而分裂成兩個獨立的小叢集，且兩者都認為自己是 Master。這會導致數據不一致與資源搶奪。Elastic Cloud Enterprise 透過在第三個可用區域部署 Tiebreakers (決勝局) 節點來防範此問題，確保在網路分裂時，只有獲得超過半數票數的節點群體能繼續運作。

Q3：如何安全地維護其中一個可用區域的 Allocator？

A：最佳 ECE 維運除錯 實務是先在 Cloud UI 中將該 Allocator 設為「維護模式 (Maintenance Mode)」。系統會停止分配新任務給該節點。對於只存在於該區域的單節點服務，應先手動移動 (Move) 到其他區域。確認無誤後再關閉 Docker 或進行硬體維護，完成後重啟並取消維護模式，服務會自動透過 HA 機制同步恢復。

更多相關文章