自行管理的 Oracle 資料庫參考架構

這份參考架構提供概念架構,說明如何在 Google Distributed Cloud (GDC) 實體隔離方案上部署及操作自行管理的 Oracle 資料庫。這項解決方案可讓您在標準叢集上,使用官方的 Kubernetes 專用 Oracle Database Operator,維護重要的資料庫工作負載。

這個架構著重於啟用自備授權 (BYOL) 模式,讓您在隔離環境中部署標準化、安全且高可用性的資料庫。涵蓋從佈建和網路到正式環境級作業 (例如高可用性、備份、還原和觀測能力) 的完整生命週期。

特點與功能

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

  • 自動化生命週期管理:使用 Oracle Database Operator,自動佈建、複製、修補及設定單一執行個體資料庫 (SIDB)。
  • 高可用性:整合支援 Oracle Data Guard,提供同步或非同步複製和自動容錯移轉功能。單一可用區內支援高可用性。
  • 整合永久儲存空間:順暢使用 GDC 現有的 standard-rwo 儲存空間級別來儲存資料庫檔案,確保資料耐用性。
  • 安全映像檔管理:支援將 Oracle 容器映像檔從 Oracle Container Registry 鏡像至本機 Harbor 登錄檔,包括整合式安全漏洞掃描。
  • 統合觀測能力:內建機制,可將資料庫指標匯出至 Prometheus,並使用 Sidecar 模式轉送警告記錄。
  • 彈性網路:支援內部和外部 L4 負載平衡器,可安全公開資料庫端點。

架構原則

  • 自行管理方法:提供部署及管理 Oracle 工作負載的架構。
  • 雲端原生作業:使用運算子模式管理有狀態工作負載,確保不同環境的一致性。
  • 資料庫感知韌性:優先採用資料庫層級複製 (Data Guard),而非基礎架構層級複製,確保邏輯一致性並加快復原速度。
  • 以安全性為主的設計:使用本機註冊資料庫、強制執行映像檔掃描,以及所有資料庫流量的明確網路政策,遵守實體隔離要求。

架構

這個架構說明 GDC 標準叢集、Oracle Database Operator、SIDB 資源,以及 Harbor 等支援基礎架構之間的關係。

自行管理的 Oracle 資料庫架構圖。

概念和技術

本節將詳細說明功能元件、其職責,以及元件在系統中的通訊方式。

基礎架構和平台

  • GDC 標準叢集:Oracle Operator 和資料庫 Pod 所在的主要運算環境。
  • Harbor Registry:所有容器映像檔的安全本機可靠資料來源。這項服務提供自動掃描功能,確保映像檔沒有已知的安全漏洞。
  • 永久儲存空間:GDC standard-rwo 儲存空間類別會使用 PersistentVolumeClaim,提供 Oracle 資料檔案、重做日誌檔和控制檔案所需的基礎區塊儲存空間。

服務和邏輯

  • Oracle Database Operator:負責監控 SingleInstanceDatabase 和 DataguardBroker 等自訂資源的控制器。並將這些物件協調為標準 Kubernetes 物件,包括用於資料庫 Pod 的 StatefulSet,以及用於網路的 Service。
  • 單一執行個體資料庫 (SIDB):使用 Oracle 多租戶架構 (CDB/PDB) 的容器化部署。您可以部署多個不同的 SIDB 執行個體,或在單一 SIDB 中建立多個可插式資料庫 (PDB),藉此整合工作負載。
  • Data Guard Broker:協調主要和待命執行個體之間的角色轉換。它會管理資料庫角色標籤 (例如 database.oracle.com/role: primary),Kubernetes 服務會使用這些標籤,在容錯移轉後正確轉送流量。
  • L4 負載平衡器:提供穩定的 IP 位址,用於連線至資料庫。

資料流程和介面

  • SQL*Net (通訊埠 1521):應用程式連線能力的主要通訊協定。
  • 觀測能力匯出工具:公開 Prometheus 的 /metrics 端點。
  • 快訊記錄:標準資料庫快訊記錄會傳送至 stdout,由 GDC 記錄代理程式收集。
  • RMAN 管道:CronJob 資源會使用這些管道,將備份串流至與 S3 相容的物件儲存庫。

注意事項

  • 擴充性和效能:
    • 正式環境工作負載的 worker 節點至少須有 8 個 vCPU 和 32 GiB RAM。
    • 建議您使用 nodeSelector 或汙點和容忍,將特定節點專用於資料庫工作負載。
    • 效能表現與基礎儲存空間息息相關,建議使用 IOPS 較高的 standard-rwo。
  • 資源管理和授權:
    • 這項解決方案採用自備授權 (BYOL) 模式。
    • 透明資料加密 (TDE)、進階壓縮和 Active Data Guard (唯讀待命) 等進階功能,需要特定的 Enterprise Edition 授權。
    • Oracle Database Free 版本可用於開發和測試。
  • 可用性和穩定性:
    • 如要達到高可用性,請採用單一可用區 Data Guard 設定,將主要和待命執行個體放在同一個命名空間。
    • 使用具有 primary 角色標籤選取器的 Service,可確保在容錯移轉期間順暢重新導向用戶端,而無須變更用戶端。
    • 為保護資料,這項解決方案會使用 RMAN,將資料備份至與 S3 相容的 bucket。
  • 營運管理:
    • 雖然運算子可簡化部署作業,但調整和複雜還原等日常作業仍需要資料庫管理專業知識。
    • 建議使用邊車容器,轉送未傳送至 stdout 的詳細追蹤記錄和稽核記錄。

設計決策

這項解決方案的主要架構選擇著重於平衡自動化與實體隔離環境的限制。

Data Guard 與儲存空間層級複製

Data Guard 具備資料庫感知功能,因此是高可用性機制。這種做法可防範邏輯損毀,並在區塊寫入待命執行個體前進行驗證,確保在最高可用性模式下不會遺失任何資料。雖然這需要額外的 Enterprise Edition 授權,且設定負擔比磁碟區快照多,但能為精煉工作負載提供必要的一致性。

負載平衡器的服務管理

根據預設,在 SingleInstanceDatabase 規格中設定 loadBalancer: true 參數會自動建立外部負載平衡器服務。如果是內部負載平衡器,則必須手動建立獨立的服務資源,並加入必要的 networking.gke.io/load-balancer-type: "internal" 註解。這種手動方法可讓您以宣告方式控管註解和標籤,而預設的運算子代管服務可能不會公開這些註解和標籤。

記錄檔 Sidecar 的觀測能力策略

解決方案建議使用邊車容器轉送記錄。這樣一來,記錄收集作業就會與主要資料庫程序分離,確保大量記錄不會影響資料庫效能。雖然這會增加每個資料庫 Pod 的資源用量,但可確保可靠的遙測資料收集,而不會影響資料庫穩定性。

假設和限制

假設

  • 環境已預先設定可存取的 Harbor 執行個體,用於託管映像檔。
  • 標準叢集已預先安裝 cert-manager,可處理運算子的 Webhook 憑證。
  • RMAN 備份目標可使用與 S3 相容的物件儲存庫。

限制

  • 單一可用區高可用性:支援單一可用區內的高可用性設定。
  • 不支援 Oracle RAC:不支援 Real Application Clusters (RAC),解決方案著重於 Single Instance 和 Data Guard。
  • 僅限標準叢集:解決方案已通過 GDC 標準叢集驗證,不支援共用使用者叢集。

後續步驟