此参考架构提供了一个概念框架，用于在 Google Distributed Cloud (GDC) 网闸隔离配置上部署和运行自行管理的 Oracle 数据库。借助此解决方案，您可以在标准集群上使用官方 Oracle Database Operator for Kubernetes 来维护关键数据库工作负载。
该架构侧重于实现自带许可 (BYOL) 模式，让您能够在隔离的环境中部署标准化、安全且高可用性的数据库。它涵盖了从预配和联网到生产级运营的整个生命周期，例如高可用性、备份、恢复和可观测性。
特性和功能
该解决方案提供了多个用于数据库管理的核心功能组件：
- 自动化生命周期管理：使用 Oracle Database Operator 自动预配、克隆、修补和配置单实例数据库 (SIDB)。
- 高可用性：集成式支持 Oracle Data Guard，可提供同步或异步复制和自动故障切换功能。支持在单个可用区内实现高可用性。
- 持久性存储集成：无缝利用 GDC 现有的标准 rwo 存储类来存储数据库文件，以确保数据持久性。
- 安全的映像管理：支持将 Oracle 容器映像从 Oracle Container Registry 镜像到本地 Harbor 注册表，包括集成的漏洞扫描。
- 统一的可观测性：内置机制，用于将数据库指标导出到 Prometheus 并使用辅助信息文件模式转发提醒日志。
- 灵活的网络：支持内部和外部 L4 负载平衡器，以安全地公开数据库端点。
架构原则
- 自行管理方法：提供用于部署和管理 Oracle 工作负载的架构框架。
- 云原生运维：使用运维人员模式管理有状态的工作负载，确保不同环境之间的一致性。
- 数据库感知型恢复能力：优先考虑数据库级复制 (Data Guard) 而不是基础架构级复制，以确保逻辑一致性和更快的恢复速度。
- 注重安全的设计：通过使用本地注册表、强制性映像扫描和针对所有数据库流量的明确网络政策，遵守气隙要求。
架构
此架构图展示了 GDC 标准集群、Oracle Database Operator、SIDB 资源和 Harbor 等支持性基础架构之间的关系。
概念和技术
本部分详细介绍了功能组件、它们的职责以及它们在系统内的通信方式。
基础架构和平台
- GDC 标准集群：Oracle Operator 和数据库 pod 所在的主要计算环境。
- Harbor 注册表：所有容器映像的安全本地可靠来源。它提供自动扫描功能，以确保映像不存在已知漏洞。
- 永久性存储：GDC standard-rwo 存储类使用 PersistentVolumeClaim 提供 Oracle 数据文件、重做日志和控制文件所需的底层块存储。
服务和逻辑
- Oracle Database Operator：负责监控
SingleInstanceDatabase和DataguardBroker等自定义资源的控制器。它会将这些内容协调为标准 Kubernetes 对象，包括数据库 Pod 的 StatefulSet 和网络服务。 - 单实例数据库 (SIDB)：使用 Oracle 多租户架构 (CDB/PDB) 的容器化部署。您可以在单个 SIDB 中创建多个可插拔数据库 (PDB)，从而部署多个不同的 SIDB 实例或整合工作负载。
- Data Guard Broker：协调主实例和备用实例之间的角色转换。它管理数据库角色标签（例如
database.oracle.com/role: primary），供 Kubernetes 服务在故障切换后正确路由流量。 - L4 负载平衡器：为数据库连接提供稳定的 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（只读备用）等高级功能需要特定的企业版许可。
- Oracle Database Free 版可用于开发和测试。
- 可用性和可靠性：
- 通过单可用区 Data Guard 配置（主实例和备用实例位于同一命名空间中）实现高可用性。
- 使用具有
primary角色标签选择器的服务可确保在故障切换期间实现无缝的客户端重定向，而无需进行客户端更改。 - 对于数据保护，该解决方案使用 RMAN 将数据备份到与 S3 兼容的存储桶。
- 运营管理：
- 虽然该运维人员可简化部署，但日常操作（例如调整和复杂恢复）仍需要数据库管理专业知识。
- 建议使用边车容器转发未发送到
stdout的详细跟踪记录和审核日志。
设计决策
此解决方案的主要架构选择侧重于在气隙环境的限制下平衡自动化。
Data Guard 与存储级复制
Data Guard 是一种高可用性机制，因为它能够感知数据库。此方法通过在将块写入备用数据库之前对其进行验证，可防止逻辑损坏，并确保在最大可用性模式下不会丢失任何数据。虽然这需要为企业版购买额外的许可，并且设置开销比卷快照更大，但它可为细化工作负载提供所需的一致性。
负载平衡器的服务管理
默认情况下，在 SingleInstanceDatabase 规范中设置 loadBalancer: true 参数会自动创建外部负载平衡器服务。对于内部负载均衡器，必须手动创建一个单独的服务资源，以包含必要的 networking.gke.io/load-balancer-type: "Internal" 注解。这种手动方法可对默认的由运算符代管式服务可能不会公开的注释和标签进行声明式控制。
日志 Sidecar 的可观测性策略
该解决方案建议使用边车容器进行日志转发。这样可将日志收集与主数据库进程分离，确保大量日志不会影响数据库性能。虽然这会增加每个数据库 pod 的资源占用空间，但可确保可靠地收集遥测数据，而不会影响数据库稳定性。
假设和限制
前提
- 环境具有预配置且可访问的 Harbor 实例，用于托管映像。
- 标准集群预安装了 cert-manager，用于处理运算符的 webhook 证书。
- 与 S3 兼容的对象存储区可用于 RMAN 备份目标。
限制
- 单可用区高可用性：支持在单个可用区内进行高可用性配置。
- 无 Oracle RAC：不支持 Real Application Clusters (RAC)；该解决方案侧重于单实例和 Data Guard。
- 仅限标准集群：此解决方案已针对 GDC 标准集群进行验证，但不支持共享用户集群。