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