這項參考架構提供概念架構,說明如何在 Google Distributed Cloud (GDC) 實體隔離方案上部署及運作自行管理的 Oracle 資料庫。這項解決方案可讓您在標準叢集上使用官方的 Oracle Database Operator for Kubernetes,維護重要的資料庫工作負載。
這項架構著重於啟用自備授權 (BYOL) 模式,讓您在隔離環境中部署標準化、安全且高可用性的資料庫。涵蓋完整生命週期,從佈建和網路到高可用性、備份、還原和可觀測性等生產環境級作業,無一不包。
特點與功能
這個解決方案提供多個資料庫管理核心功能元件:
- 自動化生命週期管理:使用 Oracle Database Operator 自動佈建、複製、修補及設定單一執行個體資料庫 (SIDB)。
- 高可用性:整合 Oracle Data Guard 支援功能,提供同步或非同步複製和自動容錯移轉功能。單一可用區支援高可用性。
- 整合永久儲存空間:針對資料庫檔案,順暢運用 GDC 現有的標準 RWO 儲存空間類別,確保資料耐久性。
- 安全映像檔管理:支援將 Oracle Container Registry 中的 Oracle 容器映像檔鏡像到本機 Harbor 登錄檔,包括整合式安全漏洞掃描。
- 統一觀測能力:內建機制,可將資料庫指標匯出至 Prometheus,並使用補充資訊模式轉送警告記錄。
- 彈性網路:支援內部和外部 L4 負載平衡器,可安全地公開資料庫端點。
架構原則
- 自行管理方法:提供部署及管理 Oracle 工作負載的架構。
- 雲端原生作業:使用運算子模式管理有狀態的工作負載,確保不同環境之間的一致性。
- 資料庫感知韌性:優先處理資料庫層級的複製作業 (Data Guard),而非基礎架構層級的複製作業,確保邏輯一致性並加快復原速度。
- 以安全為重的設計:使用本機登錄檔、強制執行映像檔掃描,以及針對所有資料庫流量採用明確的網路政策,符合氣隙要求。
架構
架構圖顯示 GDC 標準叢集、Oracle Database 運算子、SIDB 資源,以及 Harbor 等支援基礎架構之間的關係。

概念與技術
本節詳細說明功能元件、各自的責任,以及這些元件在系統內的通訊方式。
基礎架構和平台
- GDC 標準叢集:主要運算環境,Oracle 運算子和資料庫 Pod 所在位置。
- Harbor 登錄檔:所有容器映像檔的安全本機可靠來源。這項功能提供自動掃描服務,確保映像檔沒有已知的安全漏洞。
- 永久儲存空間:GDC standard-rwo 儲存空間類別提供 Oracle 資料檔案、重做日誌和控制檔案所需的基礎區塊儲存空間,並使用 PersistentVolumeClaim。
服務和邏輯
- Oracle Database 運算子:負責監控
SingleInstanceDatabase和DataguardBroker等自訂資源的控制器。並將這些物件協調為標準 Kubernetes 物件,包括資料庫 Pod 的 StatefulSet 和網路服務。 - 單一執行個體資料庫 (SIDB):使用 Oracle 多租戶架構 (CDB/PDB) 的容器化部署。您可以部署多個不同的 SIDB 執行個體,或在單一 SIDB 中建立多個可插式資料庫 (PDB),藉此整合工作負載。
- Data Guard Broker:協調主要和待命執行個體之間的角色轉換。例如,在容錯移轉後,Kubernetes 服務會使用資料庫角色標籤 (例如
database.oracle.com/role: primary) 正確轉送流量。 - 第 4 層負載平衡器:提供穩定的 IP 位址,用於資料庫連線。
資料流程和介面
- SQL*Net (連接埠 1521):應用程式連線的主要通訊協定。
- 可觀測性匯出工具:公開 Prometheus 的
/metrics端點。 - 快訊記錄:標準資料庫快訊記錄會傳送至
stdout,由 GDC 記錄代理程式收集。 - RMAN 通道:
CronJob資源會使用這些通道,將備份資料串流至與 S3 相容的物件儲存空間。
注意事項
- 擴充性和效能:
- 工作節點的大小至少須為 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 憑證。
- 與 S3 相容的物件儲存庫可用於 RMAN 備份目標。
限制
- 單一可用區 HA:單一可用區內支援高可用性設定。
- 不支援 Oracle RAC:解決方案不支援 Real Application Clusters (RAC),而是著重於單一執行個體和 Data Guard。
- 僅適用於標準叢集:這項解決方案適用於 GDC 標準叢集,不支援共用使用者叢集。