PostgreSQL 高可用怎麼做？EDB PEM 監控平台的 HA 設計解析
在企業級資料庫架構中，高可用性（High Availability, HA）通常被優先實作在資料庫本身。
以 PostgreSQL / EDB Postgres Advanced Server（EPAS）而言，這常意味著實作 primary–standby 複寫、自動故障切換、備援監控、WAL 備份系統 等。
然而，多數企業在建置 HA 時，常忽略了另一個關鍵問題：資料庫監控與管理系統是否也需要高可用性？
EDB 所提供的 Postgres Enterprise Manager（PEM） 是許多企業監控 PostgreSQL / EPAS 的核心平台；一旦 PEM 當機，雖不影響資料庫運作，但企業將失去監控、警示、效能分析與自動化管理能力。
因此，讓 PEM 本身具備 HA 能力，是完整高可用方案中不可或缺的延伸。
為什麼需要 PEM HA？
PEM 在 EDB 架構中扮演以下角色：
- 集中式監控：收集所有 Postgres / EPAS、Barman、pgBouncer … 等資訊
- 告警（Alerting）：發出 Email、SNMP、Webhook 告警
- 效能診斷（Performance Diagnostics）
一旦 PEM Server 無法提供服務：
- 通知與告警中斷
- 監控與歷史趨勢資料中斷
- 自動化工作無法執行
- 監控代理 PEM Agent 無法上傳資料
- 管理者難以判斷高可用切換後的叢集狀況
對大型環境（>20+ DB instances）是一個不可忽視的風險。因此，在企業級資料庫環境中，為了實現完整的高可用管理鏈，PEM HA 是一個不可忽略的部署元件。
PEM HA 同地 / 異地架構概念
PEM 同地高可用架構的基本核心架構：
- 透過 streaming replication 將PEM Server 後端資料同步於 primary / standby
- PEM Server 使用虛擬 IP（VIP）提供單一服務入口點
- PEM Agents 全部指向 VIP，而不是指向單一 PEM Server
- PEM Server 故障切換後，PEM Agents 會自動重新連線
針對以上核心原則，PEM 同地 HA 架構會如下圖呈現：
説到這，其實你會發現 PEM HA 與資料庫的 HA 有著一模一樣的核心架構。
透過 EDB 提供的 Failover Manager，使PEM server 也可以綁定 Virtual IP 並且達成自動故障切換，進而減少因 PEM 故障而產生的 downtime 時間。
同樣的，PEM HA 與資料庫 HA 有著相似的特性 ：資料庫的高可用架構中，唯有 Primary 可提供讀寫功能在PEM 高可用架構中，所有的連線（包含Web UI）都只會指向 Primary。
那麼，PEM 可以達成異地高可用架構嗎？
值得補充的是，自 PEM 10.1 版本開始，PEM Server 在高可用架構上有了更彈性的部署方式。
以同地高可用架構為例，若要讓 PEM Server 本身具備高可用能力，通常會搭配 Failover Manager（EFM） 與 Virtual IP（VIP），形成 Primary / Standby 的雙機架構。然而，VIP 受限於 Layer 2 網段，無法跨區域使用，因此若想將 PEM Primary 與 Standby 部署在不同機房或地理區域，就會受到架構限制。
自 PEM 10.1 開始，PEM Server 支援 PostgreSQL 的 multi-host connection string，使 PEM Agent 以及 PEM 本身都能同時連接多個主機，進一步提升異地高可用的可行性。
這代表：
- PEM Primary 與 PEM Standby 可以分別部署在不同地區、不同網段
- 不再依賴 Virtual IP
- Agent 在 Primary 不可用時，可自動切換連線到新的 primary
- 整體架構更彈性，也能真正做到跨區域的高可用
實際架構看起來會像這樣：
PEM HA 同地 / 異地 實際測試
那麼，如何建立 PEM 監控的高可用架構呢？我們先來簡單介紹其組成元件。
- 兩台 PEM Servers
- 主節點：PEM Primary (範例 ip → 172.16.1.76)
- 備援節點：PEM Standby (範例 ip → 172.16.1.77)
- 資料同步
- 建議使用 EDB 整合的 Streaming Replication
- synchronous / asynchronous 取決於可用性 vs 性能
- Virtual IP
- 透過 EDB Failover Manager 將 virtual ip (172.16.1.155) 綁定至各主機上
- PEM Agent
- 透過資料庫主機上 PEM Agent 的設定來決定Failover 發生時資料庫該連向哪一個 PEM Server
PEM HA 同地 高可用架構（EFM + VIP）
將 PEM primary 設定好後，透過 streaming replication 將 PEM standby 也同步到 PEM primary 的資料，並且將兩個節點都加入到 Failover Manager 的叢集內，會呈現以下狀態：
可以看到我們已經將 virtual ip 透過 Failover manager 綁定到兩台 PEM Server，現在再到資料庫主機端的 PEM Agent 設定檔去修改要連線的 ip 。
上圖就是在資料庫端所安裝的 PEM Agent 的設定檔。
PEM Agent 欲連線的 PEM Server 的 ip 以及 port，還有其運作過程所產生的 log 的位址等設定都會存取在該設定檔裡面。
只需要將第一項設定 pem_host 修改成我們前面設定的 virtual ip,，將 PEM agent 服務重啟後，監控資料就能順利指向 PEM Server 所綁定的 virtual ip。
當 failover 狀況發生時，由於我們指向的目標 ip 是 virtual IP，無需手動更改資料庫連線的資訊，virtual ip 就會自行綁定至當前可提供服務的 PEM server。
以下嘗試將 PEM primary 的資料庫服務停止（systemctl stop postgresql-17）：可以看到 EFM 狀態顯示 PEM Primary 斷線，並且 EFM 自動將 standby promote 成 primary。
透過 virtual ip 去訪問 PEM web 介面，可以發現服務是依舊正常顯示：
這樣一來就成功驗證了 PEM 同地 HA 架構的可行性！
PEM HA 異地 高可用架構（EFM + Multi-host connection）
如前文所述，VIP 天生受到 Layer 2 網段限制，而無法跨區域部署。我們可以透過 PEM 10.1 版本之後支援的 multi-host connection， 來達成部署異地PEM的高可用架構。
基本上，唯一與同地高可用架構不同之處，就是 PEM Agent 端的設定檔案。
在修改設定檔案之前，我們先看當前 EFM 叢集狀態：
因為沒有額外綁定 Virtual IP 在資料庫的主機上，可以看到這次狀態的頁面在 VIP 的欄位是空白的。
接著就到 PEM Agent 設定檔，新增兩台 PEM Server ip 。
過去 PEM Agent 設定中，pem_host 欄位只允許一組 PEM server ip。但自 PEM 10.1 版本開始，該設定檔便支援了填入一組以上的 ip 。
現在只要將兩台 PEM server 的 ip 依照 primary >> standby 的順序填入後，PEM Agent 就會自行依照順序去尋找當前可供讀寫（當前 primary）的 PEM host， 進行後續的連線。
接下來，實際將當前的 PEM Standby promote 成新的 primary，並且觀察是否可以透過 PEM standby 進行連線。
透過 efm promote <叢集名稱> –switchover 將原先的 standby promote 成 primary：
由於 PEM HA 有著與資料庫 HA 相同的特性（連線一律指向 Primary），可以看到我們用 PEM 舊 primary ip 是無法訪問 Web UI 介面的：
相反的，這時就可以透過 PEM standby（新的 primary） ip 去做訪問：
這樣一來，我們也驗證了如何透過 multi-host connection 去達成 PEM 的高可用架構！
結語
在 PostgreSQL / EDB 高可用架構中，PEM 的角色比多數人想像中來得更加關鍵。若資料庫本身已經做到 PG / EPAS HA，但監控平台仍是單點，就等於整個 HA 架構仍有進步的空間。
透過引入 PEM HA：
- 整個 PostgreSQL 監控、管理、告警與自動化流程都能具備高可用性
- 真正達到企業級的完整資料庫 HA 生態
如果您的企業正在規劃或已經部署 PostgreSQL 高可用架構，建議下一步就是將 PEM 納入 HA 設計，讓整個系統達到更完整的韌性與可靠性。
文章參考資料：
[3] https://www.enterprisedb.com/docs/pem/latest/considerations/ha_pem/#multi-host-connection-strings
想了解更多資訊，歡迎聯絡我們，或是 加入歐立威 Line 好友！
