Elastic Cloud ECE 架構深鑽實務 定義容器化部署與高品質高可用性維運之生命週期

什麼是 Elastic Cloud Enterprise (ECE)？

Elastic Cloud Enterprise (ECE) 是 Elastic 官方推出的私有雲解決方案，允許企業在自己的基礎設施（實體機、虛擬機或私有雲）上運行與管理 Elastic Stack。其核心架構基於 Docker 容器化技術，旨在解決大規模部署中的資源隔離與管理難題。透過 ECE，管理員可以輕鬆實現多租戶管理、自動化擴展與高可用性 (HA) 配置。ECE 內建了強大的平台管理功能，包括透過 ZooKeeper 維護狀態一致性、使用 Proxies 導流以及 Allocators 管理資源分配。它讓企業能像使用 Elastic Cloud 官版服務一樣，在本地端享受極致的維生效率與安全性。

Elastic Cloud Enterprise Architecture

這篇文章將分享首次深入了解 Elastic Cloud Enterprise (ECE) 架構的心得，並詳細介紹如何透過 ECE 主控台介面 (Cloud UI) 進行高效的ECE 平台管理與系統架構設定。Elastic Cloud Enterprise 是 Elastic Stack 雲端企業用的版本，專為提供更完整且服務導向的系統架構而設計，並內建高可用性 (HA) 保證，有效減少因配置不當導致的系統不穩定問題。

在當今數位轉型的浪潮下，企業對數據處理與分析的需求日益增長，而 Elastic Stack 雲端部署的複雜性也隨之提高。深入進行 Elastic Cloud Enterprise 架構解析，便會發現其核心優勢在於其高度靈活且可擴展的容器化部署能力，結合內建的高可用性 HA 解決方案，確保了關鍵數據服務的持續穩定運行。這不僅大幅簡化了ECE 平台管理教學的難度，更讓企業能夠專注於數據價值創造，無需擔憂底層基礎設施的複雜性，從而加速創新步伐。

為什麼使用 Elastic Cloud Enterprise 而不自己管理?

• 減少部屬跟管理硬體架構的成本，像是管理網路、防火牆、硬碟狀況等等
• 用 docker 最大化硬體機台的使用率，隔離資源避免 Split Brains 這類問題
• 提供安全性、HA 的保證，減少因為一個服務沒處理好就整台機器掛掉的風險
• 能夠集中管理散布在各地的服務

ECE Features

• 服務都以 docker 容器的方式提供
• 透過多個 Availability Zones 做到 HA
• 透過 ZooKeeper 管理協調節點部屬的狀態
• 透過 API 或是網頁版 GUI 可以很方便的操作管理
• 支援離線安裝
• 系統還原或是快照功能

Roles and Runners

每台機器上會有一個 Runners 負責控管每一台機器，確保所有的容器都是正常健康運作的，Runner 會被給予多個角色，每個角色則會對應到不同的容器，有不同的權限及用途。

• Proxy Role，處理使用者請求，確保相關靜態資源的可存取狀態，協助不停機升級或擴充
• Allocator Role，負責把所有節點上的服務跑起來，負責產生新的容器並啟動節點
• Coordinator Role，負責 constructor，協調系統資源與排程
• Director Role，管理 ZooKeeper，只要被 assign 那台機器上面就會跑 Zookeeper 的服務，且服務不會因為角色移除而消失

ECE Platforms 系統架構

系統架構圖如下，可以看到每台機器上都會有一個 Runner，每個服務都會部屬在各自的 docker container 裡，幾個主要區塊如下

• Load balancers: 附載平衡負責導流
• Proxies: 監控每個 availability zones 是否健康，通常會在附載平衡後面接好幾個確保 Proxy 穩定
• Allocators: 管理節點上的站台服務，每個節點上服務的 CRUD
• Control Plane: 負責管理整個架構的核心
  • ZooKeeper，分散式系統中確保文件寫入一致性，用來存放 ECE 元件部屬狀態與所需的配置資訊維護像是 Proxy 的 Routing Table，會透過 STunnel 跟 ECE 元件們傳遞訊息溝通。
  • Director: 管理 ZooKeeper
  • Constructor: 排程與監控，當有相關狀態改變就要即時寫入 ZooKeeper，也負責分配節點到不同的 availability zones 確保服務可用性
  • Cloud UI and API: API 相關管理

系統架構圖

介紹了 Elastic Cloud Enterprise 的架構後，接下來會介紹透過 ECE 主控台介面 (Cloud UI) 做平台管理及設定，下一篇文章會介紹較進階的部屬樣板使用方式。Cloud UI 中的 Platforms 主要顯示與管理系統架構中各節點的健康狀況。一套完整的架構除了 Load Balancers 都能夠在 Platforms 中進行健康狀況的監控與配置，包含了以下相關選單

• Allocators
• Runners
• Proxies
• Elastic Stack
• Templates
• Repository
• Setting
• Security

Platforms Allocators

移動節點的功能，當我們發現某個 Cluster 中的健康狀況出問題或機器正在升級維護時，就能夠透過這個功能先把節點移動到其他的 Cluster 中來減少停機的時間。

移動或刪除 Allocators

Platforms Runners

Runners 是每台機器管理者，會管理多種角色，角色則會對應管理不同的容器服務，確保所有對應到該角色的容器服務都是健康的。

• Proxy Role，處理使用者請求，確保相關靜態資源的可存取狀態，協助不停機升級或擴充
• Allocator Role，負責把所有節點上的服務跑起來，負責產生新的容器並啟動節點
• Coordinator Role，負責 constructor，協調系統資源與排程
• Director Role，管理 ZooKeeper，只要被 assign 那台機器上面就會跑 Zookeeper 的服務，且服務不會因為角色移除而消失

管理每個 Runners 的角色

Platforms Proxy

查看目前 Proxy 設定的狀況，這個部分還沒有開到多個 Availablity Zone 所以還沒深入研究。

Proxy 狀態列表

Platforms ElasticStack

這一頁蠻單純的，每個 Deployment 中的 Elastic Stack 版本與內容列表。

Elastic Stack 版本與內容列表

Platforms Templates

提供部屬用的樣版，可以去設定每台機器是不是需要 highCPU 或是 SSD 等等的服務配置，像是儲存用的服務可能就不需要 SSD，記憶體與儲存空間的比例也可以設定到 1:48 ~ 1:96 等等相關配置。

樣板管理介面

Platforms Repository

要啟用快照功能一定要先配置 Repository，詳細介紹可以參考前一篇文章。

Repository 配置

Platforms Security And Setting

Platforms 相關設定與主控台安全管理，比較重要的是 Endpoints IP 或網域記得要設定正確，然後相關的 TLS 憑證可以在這裡匯入，主控台安全可以透過鎖 IP 的方式進行控管，只讓相關人員能夠進到這個管理介面。

Platforms 相關設定

IP 設定

Load Balancers

值得注意的是 Load Balancers 沒有包含在 ECE 裡面，因為 ECE 的架構中是包含這樣的設計，所以還是建議自行安裝像是 Nginx 這樣的工具，相關基礎配置也可以參考這篇介紹 nginx 的文章，裝上去之後就可以直接解決 C10K 的問題，每個 Availablity Zone 都至少配兩個 Load Balancers 來做到 HA，HA 的詳細概念與實作會在下一篇文章跟大家分享。

Activity

最後一個頁面其實是 Activity，可以看出是否有哪些節點已經閒置很久沒有使用，查看活動的狀態。

結點活動狀態

心得與結論

過去的經驗有直接架過包含附載平衡的實體主機、用過 Azure App service 服務和虛擬機、Aws 開虛擬機搭配部分服務，底下分享一些使用過的優缺點跟心得。

• 若買過 MS 版權軟體，實體機買斷長期較便宜，花同樣錢雲端開到同規格會比較貴
• 雲端服務大多提供快照、快速恢復的功能
• 實體機較容易遇到道路施工挖電纜影響，以前就至少遇過兩次服務需要中斷一點時間的狀況
• DDoS 等攻擊實體機需要透過配置防範，雲端大多有整合相關服務
• 實體機擴充較不容易，雲端服務可幾分鐘內完成可擴充彈性大，早期就遇過硬碟最大才 2T，每過一段時間，資料庫都要定期移轉資料到其他機台的狀況
• 如果套用了一些雲端微服務，可能會造成系統架構更複雜難懂，按照教學用了不太懂的服務後帳單突然變很貴，我之前同事就遇過但還好一周內發現，寄信給 AWS 後有退款成功

會適合用實體機自建的狀況:

• 本來公司就有購買主機、相關版權，像之前公司有買高級 NAS，拿來架 WordPress 官網前面掛個 Cloudfare 其實很夠用
• 公司有 MIS、維運團隊、架構師

會適合用雲端服務的狀況:

• 團隊較小，產品還沒穩定營利前
• 第一次申請完全可以先只用免費的額度，早期 Azure 還有新創方案超便宜

FAQ：Elastic Cloud Enterprise (ECE) 架構常見問題

Q1：ECE 與自行手動架設 Elasticsearch 集群最大的差別是什麼？

A：手動架設需要處理繁瑣的網路配置、節點擴展與手動備份。而 ECE (Elastic Cloud Enterprise) 提供了一層強大的管理抽象。它將所有服務（Elasticsearch, Kibana, APM 等）容器化，並提供視覺化的 Cloud UI 與 RESTful API。這意義著您只需按幾個按鈕，系統就會自動處理 Allocator 資源分配、Proxy 路由更新與 HA 高可用性配置，大幅降低了維運成本。

Q2：為什麼 ECE 架構中需要 ZooKeeper？

A：在分散式架構中，確保數據的一致性至關重要。ECE 使用 ZooKeeper 作為「單一真理來源」，存放所有組件的配置與狀態資訊。例如，當一個節點掛掉時，Constructor 會偵測到狀態變化並更新 ZooKeeper，隨後 Proxy 就會知道不再導流到該節點，從而保證系統的持續運作。

Q3：ECE 是否包含 Load Balancer？

A：ECE 本身不直接提供 Load Balancer。雖然 ECE 內建了 Proxies 來處理內部的導流與健康檢查，但建議在 ECE 前端自行架設硬體或軟體級的 Load Balancer（如 Nginx 或 F5），以處理外部流量的負載均衡與 C10K 等高併發問題，確保整個系統架構的穩健性。

• ← 上一篇
• 下一篇 →