GDC 氣隙環境中的 PostgreSQL 資料庫參考架構

這項參考架構提供概念架構，說明如何在 Google Distributed Cloud (GDC) 氣隙環境中，部署及運作客戶管理的 PostgreSQL 資料庫。這項解決方案可讓機構在虛擬機器上部署高可用性 (HA) 多區域叢集，維持重要資料庫工作負載。

這項架構著重於彈性的 3 節點設定，即使單一可用區或基礎架構發生故障，也能確保資料庫可用性。從自動佈建和網路到高可用性、備份、還原和可觀測性等生產環境作業，這項服務涵蓋整個生命週期。

特點與功能

這個解決方案提供多個資料庫管理核心功能元件：

  • 自動高可用性：使用 Patroni 和 etcd 提供自動領導者選舉和容錯移轉，確保資料庫在無須手動介入的情況下保持運作。
  • 多可用區韌性：將資料庫節點分散至三個不同的可用區，防範區域性硬體或基礎架構服務中斷。
  • 標準化自動化：使用以 Ansible 為基礎的劇本和 Autobase 佈建整個堆疊，確保部署作業可重複執行且一致。
  • 連線集區：整合 PgBouncer 服務，管理大量連線並穩定資料庫節點的資源耗用量。
  • 全域負載平衡：使用平台管理的全域 L4 負載平衡器，提供可跨所有區域存取的單一穩定虛擬 IP (VIP)。
  • 實體隔離就緒：專門的工作流程，可封裝所有必要的作業系統依附元件和二進位檔，以便在未連線的環境中部署。
  • 資料保護：搭配使用 pg_dump 和 pg_basebackup 等標準工具，以及 GDC 儲存空間快照，維持完善的備份和復原策略。

架構

這個架構包含三個 VM 環境，分布在三個可用區，執行共置服務堆疊。

執行服務共置堆疊的三個 VM 架構。

架構原則

  • 以多數為準的共識：使用以法定人數為準的模型，其中多數節點 (3 個中的 2 個) 必須同意叢集狀態，以避免「腦裂」情境並確保資料完整性。
  • 關注點分離：每個 VM 都會執行共置但不同的服務堆疊 (資料庫、高可用性管理員、共識和集區)，以提供獨立且具彈性的節點。
  • 資料庫感知容錯移轉：透過 Patroni 的 REST API 優先處理資料庫健康狀態指標，以協調平台負載平衡器重新導向流量。
  • 基礎架構即程式碼：所有設定工作都依賴自動化應對手冊，可降低部署和擴充期間發生人為錯誤的風險。

概念與技術

本節詳細說明功能元件、各自的責任，以及元件在系統內的通訊方式。

基礎架構和平台

  • 虛擬機器 (VM)：分散在各個可用區的專屬運算執行個體，用於代管資料庫堆疊。
  • 全域 L4 負載平衡器：平台代管服務，提供穩定的虛擬 IP (VIP)，可將流量導向目前的叢集領導者。
  • 永久儲存空間：必須使用高效能 SSD 支援的儲存空間，才能滿足共識層預先寫入記錄的嚴格延遲需求。

服務和邏輯

  • PostgreSQL 17：負責資料持續性和查詢執行的核心關聯式資料庫引擎。
  • Patroni：高可用性管理員，可監控本機 PostgreSQL 程序，並使用 etcd 協調領導者選舉。
  • etcd：分散式設定儲存空間，提供共識層，並保存叢集的權威狀態。
  • PgBouncer：輕量型連線集區器，位於 PostgreSQL 前方，可有效處理傳入的應用程式連線。

資料流程和介面

  • PgBouncer (連接埠 6432)：應用程式資料庫流量的主要進入點。
  • Patroni API (通訊埠 8008)：負載平衡器使用的 HTTPS REST 介面，可執行健康狀態檢查，並透過 /primary 端點識別目前的領導者。
  • etcd (通訊埠 2379)：共識叢集的通訊管道，用於維護狀態及執行選舉。

注意事項

  • 擴充性和效能：
    • 資料庫節點的大小應根據工作負載調整，最少要有 2 個 vCPU 和 8 GiB RAM。實際工作環境工作負載通常從 8 個 vCPU 和 32 GiB 開始。
    • 效能取決於低延遲儲存空間；必須使用 SSD，才能確保 etcd 能在 10 毫秒內處理資料同步。
    • 同步複製：同步複製的額外負荷直接取決於可用區間的網路延遲。為確保零資料遺失設定達到最佳效能，必須具備低區域間延遲。
  • 資源管理與授權：
    • 這個解決方案採用免費的開放原始碼資料庫元件。
    • Autobase 是參考自動化工具，可簡化 HA 堆疊的安裝和設定作業。不過，架構並非專屬於 Autobase，且可使用自訂管道管理基礎開放原始碼元件。
    • 如果貴機構需要自動化套件的正式支援，可以選擇第三方付費支援。
    • 使用 PgBouncer 進行連線集區化，可有效避免因使用者連線數過高而導致 CPU 和記憶體耗盡。
  • 可用性和穩定性：
    • 透過 3 節點仲裁機制實現高可用性。任何單一節點或區域發生故障，都不會中斷服務。
    • 叢集穩定性：如要維持可靠的法定人數，節點之間的網路延遲時間必須很短。平均封包往返時間 (RTT) 最好低於 10 毫秒，以免發生選舉逾時和叢集不穩定的情況。
  • 營運管理：
    • 次要版本修補程式和主要升級等例行工作，仍由客戶的營運團隊負責。
    • 系統會自動將 VM 的 stdout 輸出內容擷取到 GDC 實體隔離監控平台。我們將在日後發布指南，說明如何整合個別元件的更詳細監控功能。
    • 您應使用資料庫原生工具和平台快照，實施完善的備份策略。我們會另外發布這些程序的詳細指南。

設計決策

這項解決方案的架構選擇，為多區域部署提供彈性路徑。

透過 Kubernetes 執行的虛擬機器

我們選用以 VM 為基礎的方法，提供多可用區高可用性。 GDC 不支援跨越多個實體區域的 Kubernetes 叢集。因此，如要建構健全的跨可用區架構，就必須將專屬 VM 部署到不同可用區。這項設定可在單一基礎架構區域完全故障時繼續運作。

平台原生全域負載平衡

此架構會利用 GDC 全域 L4 負載平衡器，而非 VM 上的軟體型 Proxy。這種做法有以下幾個優點：

  • 全球涵蓋範圍：提供可在所有可用區存取的穩定虛擬 IP。
  • 平台管理：VIP 由平台的控制層獨立管理。
  • 簡化容錯移轉：容錯移轉作業是透過標準健康狀態檢查探測作業管理，而非複雜的本機軟體設定。
  • 高可用性：移除對本機 Proxy 的依賴，確保資料庫流量的進入點保持彈性。

假設和限制

假設

  • 環境具有本機登錄檔或機制，可匯入封裝的 OS 依附元件和二進位檔。
  • 所有目標 VM 都能透過金鑰型 SSH 存取，進行 Ansible 型自動化作業。
  • 專案有足夠的配額，可佈建多區域 VM 和負載平衡器。

限制

  • 手動維護：作業系統修補和 PostgreSQL 版本升級作業必須手動執行，解決方案不會自動執行。
  • 儲存空間敏感度：共識層 (etcd) 對磁碟延遲非常敏感。持續出現大量儲存空間爭用情況，可能會影響共識層的穩定性。
  • 網路穩定性：高可用性管理工具仰賴可用區之間穩定且低延遲的網路連線。延遲或網路抖動可能會影響叢集協調和角色轉換的時間。

其他教材