System架構及環境

當有六台 Elasticsearch 節點，其中三台設定了 cluster.initial_master_nodes: elasticsearch01, elasticsearch02, elasticsearch03，而另外三台沒有設定，且其他參數皆為預設值，當這三台設定了 cluster.initial_master_nodes 的 master-eligible 节点之一掛掉，導致整個叢集無法使用，最主要原因是：

主要原因：cluster.initial_master_nodes 只用於集群啟動引導，且必須在所有 master-eligible 節點中一致設定

cluster.initial_master_nodes 是用來「啟動叢集（cluster bootstrap）」時，指定參與初始 master 選舉的 master-eligible 節點名單。這個設定只需要在所有 master-eligible 節點上保持一致且只在叢集初次啟動時使用。

若叢集已有運行且持續運作，cluster.initial_master_nodes 不應該保留在後續節點的配置中，且所有 master-eligible 節點都必須互相辨識且知道彼此，通常由 discovery.seed_hosts 負責節點發現。

如果只有三台 master-eligible 設定了 cluster.initial_master_nodes，另外三台沒有，代表這六台並非一致配置，而這種不一致會導致叢集形成混亂或錯誤行為。

如果該配置沒被移除，當其中一台原本設定了 cluster.initial_master_nodes 的 master-eligible 節點掛掉，其它節點可能因無法成功完成 quorum bootstrap，造成叢集無法選出 master，進而導致整個叢集無法正常工作。

更糟的是，過時或不正確地保留 cluster.initial_master_nodes 配置在非啟動階段的節點，會導致「多個獨立集群」或節點間無法有效溝通。

簡單說，導致叢集無法用的關鍵點
cluster.initial_master_nodes 只用於首次啟動 bootstrap，且必須在所有 master-eligible 節點中一致設定。

如果在已有叢集運行後仍在部分節點保留此設定，會導致節點間協調問題。

設定不一致時，節點可能無法達成 quorum 選舉 master，尤其當已設定的 master-eligible 節點之一掛掉時就導致無法完成選主。

其結果是整個叢集出現「無法選出 master」、「集群不可用」的狀況。

正確的做法建議
啟動新叢集時，在所有 master-eligible 節點的配置文件中以相同方式設定 cluster.initial_master_nodes。

叢集成功組建後，移除所有節點中的 cluster.initial_master_nodes 配置。

新加入的節點只需設定 discovery.seed_hosts 以發現 master 及其它節點。

確保所有 master-eligible 節點有正確且一致的發現設定，並且至少有過半(master quorum)節點可用。

後規劃將一台拆成四台規格小的機器，採 2-2-1-1

當前配置與需求分析

現有配置：

2 台 c7i.4xlarge，vCPU: 16/台，Memory: 32 GiB/台，總 vCPU: 32，總 Memory: 64 GiB。
6 個 Elasticsearch 節點（假設均勻分配，每台 c7i.4xlarge 運行 3 個節點），每節點約分配 10.67 GiB 記憶體（64 GiB ÷ 6）。
價格（新加坡地區）：0.8232 USD/小時/台 × 2 = 1.6464 USD/小時，月 1,202.13 USD，年 14,422.46 USD。

目標配置：

使用 r7i.large（vCPU: 2，Memory: 16 GiB/台），總記憶體需 ≥ 64 GiB，支持 6 個節點。
考慮成本、性能和資源分配，確定最佳台數。

假設：

每台 r7i.large 運行 1-2 個節點，確保 JVM 堆記憶體（例如 12 GiB/節點）與主機記憶體匹配。
不含儲存或其他費用，僅計算實例成本。

計算與比較
r7i.large 規格與分配

r7i.large：vCPU: 2，Memory: 16 GiB。
每台可支持 1-2 個節點：

1 節點：JVM 堆 12 GiB，留 4 GiB 系統。
2 節點：JVM 堆 6 GiB/節點，留 4 GiB 系統（較緊湊）。

候選方案

4 台 r7i.large（每台 1.5 節點平均）

總 Memory: 4 × 16 GiB = 64 GiB。
節點分配：每台 1-2 節點（例如 2-2-1-1 或 1-1-2-2）。
總 vCPU: 4 × 2 = 8。
價格：0.189 USD/小時/台 × 4 = 0.756 USD/小時。

月：0.756 × 730 = 551.88 USD。
年：0.756 × 8760 = 6,622.56 USD。

成本差異：月節省 1,202.13 - 551.88 = 650.25 USD（54%），年節省 7,799.90 USD（54%）。

5 台 r7i.large（每台 1.2 節點平均）

總 Memory: 5 × 16 GiB = 80 GiB。
節點分配：例如 1-1-1-1-2。
總 vCPU: 5 × 2 = 10。
價格：0.189 USD/小時/台 × 5 = 0.945 USD/小時。

月：0.945 × 730 = 689.85 USD。
年：0.945 × 8760 = 8,282.20 USD。

成本差異：月節省 1,202.13 - 689.85 = 512.28 USD（43%），年節省 6,140.26 USD（43%）。

6 台 r7i.large（每台 1 節點）

總 Memory: 6 × 16 GiB = 96 GiB。
節點分配：每台 1 節點。
總 vCPU: 6 × 2 = 12。
價格：0.189 USD/小時/台 × 6 = 1.134 USD/小時。

月：1.134 × 730 = 827.82 USD。
年：1.134 × 8760 = 9,935.84 USD。

成本差異：月節省 1,202.13 - 827.82 = 374.31 USD（31%），年節省 4,486.62 USD（31%）。

儲存成本（假設）

每台 100GB gp3（0.1 USD/GB-月）：

原配置：2 × 100GB = 20 USD/月。
4 台：400GB = 40 USD/月。
5 台：500GB = 50 USD/月。
6 台：600GB = 60 USD/月。

總成本：

原配置：1,202.13 + 20 = 1,222.13 USD/月。
4 台：551.88 + 40 = 591.88 USD/月。
5 台：689.85 + 50 = 739.85 USD/月。
6 台：827.82 + 60 = 887.82 USD/月。

節省（含儲存）：

4 台：630.25 USD/月（52%），年 7,563.00 USD。
5 台：482.28 USD/月（39%），年 5,787.36 USD。
6 台：334.31 USD/月（27%），年 4,011.72 USD。

最佳方案建議

推薦：4 台 r7i.large

理由：

總 Memory (64 GiB) 匹配原配置，支持 6 節點（例如 2-2-1-1 分配）。
每節點可分配 10-12 GiB 堆記憶體，符合 Elasticsearch 需求。
成本最低（月 591.88 USD，年 7,102.56 USD），節省 52%（含儲存）。
vCPU (8) 減少但足以支持輕負載，適合記憶體密集任務。

andy chiang 先前在 #note-2 中提到:

記憶體平時維持 88%左右，異常時段有上升最高至 97%，導致容器無法負載

凌晨三點為FLDS運作時間，另開 PRD FLDS 重構議題 #319

案例總結：PRD ES-02 容器崩潰與叢集失效事件分析
一、 事件背景
時間： 2025年8月13日 凌晨 03:00
現象： PRD ES-02 節點崩潰，導致整個叢集出現 503 錯誤（服務不可用）。
受影響範圍： 搜尋服務、監控數據寫入。
二、 事件經過與關鍵轉折

1. 第一次崩潰 (8/13 凌晨)
   現象： 主節點 ES-02 記憶體飆升至 97% 後容器崩潰。
   初步處理： 重啟服務，並將主節點暫時轉移至 ES-01。
   排查發現：
   指標異常： 凌晨 3 點正是 FLDS 任務運作時間，Refresh 指標從 60/s 飆升至 140/s。
   管理錯誤： ILM（索引生命週期管理）政策在處理 .ds-ilm-history 時失敗並不斷重試，產生額外負載。
2. 叢集無法選主 (Marlboro 的深度分析)
   問題： 當 ES-03 停機時，剩餘的 ES-01、ES-02 無法選出 Master。
   根因： 參數 cluster.initial_master_nodes 設定錯誤。
   該參數僅應用於「第一次啟動」叢集。
   若在正式運行中仍保留此設定，且節點配置不一致（3台有設、3台沒設），會導致 Quorum（法定人數）計算錯誤，造成叢集崩潰後無法自行恢復。
3. 第二次崩潰 (8/14 凌晨)
   現象： 凌晨 3 點記憶體再度飆升，服務徹底崩潰。
   發現新病灶： 日誌顯示版本不一致（7.17.21 vs 7.17.13）。
   處置： 由於選舉邏輯已毀損且排查無效，決定初始化 Volume 並重建叢集，優化 YAML 設定。
   三、 根因總結 (Root Cause Analysis)
   資源瓶頸 (Memory Exhaustion)：
   凌晨 3 點的 FLDS 大量寫入任務導致 Refresh 頻率過高，記憶體從 88% 壓榨到 97% 導致 OOM (Out of Memory)。
   配置錯誤 (Configuration Bug)：
   cluster.initial_master_nodes 長期錯誤保留，導致節點失效時，叢集無法達成共識進行選主。
   版本不一致 (Version Mismatch)：
   叢集內節點版本細微差異（.21 與 .13），導致選舉機制與索引讀取出現 IllegalStateException。
   管理任務負擔：
   無效的 ILM 政策導致系統不斷嘗試 Rollover，消耗額外的 I/O 與 CPU。
   四、 解決方案與後續行動
4. 立即修復
   重建叢集： 重新掛載 new-volume，確保所有節點版本統一（7.17.13）。
   優化設定： 移除正式環境中的 initial_master_nodes，改用正確的 discovery.seed_hosts。
   清理資料： 刪除未綁定政策的歷史索引，停止 ILM 的錯誤重試。
5. 架構優化建議 (Andy Chiang 提案)
   為了提高容錯能力並降低成本，建議將現有的「2 台大機器」拆分為「4 台小機器」：
   原配置： 2 * c7i.4xlarge (32 vCPU/64GB) -> 集中度太高，一台掛掉就損失 50% 戰力。
   新建議： 4 * r7i.large (8 vCPU/64GB)
   優點： 節點分散在 4 台實體機（2-2-1-1 分配），容錯率更高。
   節省： 預計每月節省約 $630 USD (52% 降幅)。
6. 程式面重構 (Martin Zhuo 提案)
   專案關聯： 開立 [#319 PRD FLDS 重構] 議題。
   目標： 優化凌晨 3 點的寫入邏輯，降低對 ES 造成的 Refresh 壓力和記憶體衝擊。