GDC 网闸隔离配置上的 PostgreSQL 数据库参考架构

此参考架构提供了一个概念框架，用于在 Google Distributed Cloud (GDC) 气隙环境中部署和运行客户管理的 PostgreSQL 数据库。此解决方案使组织能够利用部署在虚拟机上的高可用性 (HA) 多地区集群来维护关键数据库工作负载。

该架构侧重于弹性 3 节点配置，即使在单个可用区或基础设施发生故障时，也能确保数据库可用性。它涵盖了从自动化配置和联网到生产级运营（例如高可用性、备份、恢复和可观测性）的完整生命周期。

特性和功能

该解决方案提供了多个用于数据库管理的核心功能组件：

  • 自动化的高可用性：使用 Patroni 和 etcd 提供自动主节点选举和故障切换，确保数据库在无需人工干预的情况下保持运行。
  • 多可用区弹性：将数据库节点分布在三个不同的可用区，以防范局部硬件或基础设施服务中断。
  • 标准化自动化：使用基于 Ansible 的 playbook 和 Autobase 预配整个堆栈，以确保部署可重复且一致。
  • 连接池：集成 PgBouncer 服务，用于管理大量连接并稳定数据库节点上的资源消耗。
  • 全球负载均衡：使用平台管理的全球 L4 负载平衡器，提供可在所有可用区中访问的单个稳定虚拟 IP (VIP)。
  • 网闸隔离就绪状态：用于打包所有必需的操作系统依赖项和二进制文件以在断开连接的环境中进行部署的专用工作流。
  • 数据保护：利用 pg_dump 和 pg_basebackup 等标准工具以及 GDC 存储快照，制定可靠的备份和恢复策略。

架构

该架构由分布在三个可用区中的三个虚拟机环境组成，这些虚拟机运行一个共置的服务堆栈。

运行同位服务堆栈的三虚拟机架构。

架构原则

  • 基于多数的共识：使用基于法定人数的模型，其中大多数节点（3 个中的 2 个）必须就集群状态达成一致，从而防止“脑裂”情况并确保数据完整性。
  • 关注点分离：每个虚拟机都运行一个同位但不同的服务堆栈（数据库、HA 管理器、共识和池程序），以提供一个自包含且富有弹性的节点。
  • 支持数据库的故障切换：通过 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 毫秒，以防止选举超时和集群不稳定。
  • 运营管理：
    • 次要版本修补和主要升级等日常任务仍由客户的运维团队负责。
    • 虚拟机的 stdout 输出会自动注入到 GDC 网闸隔离配置监控平台中。我们日后会发布指南，介绍如何针对各个组件集成更详细的监控功能。
    • 应使用数据库原生工具和平台快照来实现可靠的备份策略。我们将另行发布有关这些程序的详细指南。

设计决策

此解决方案的架构选择为多可用区部署提供了一条弹性路径。

Kubernetes 上的虚拟机

我们选择了基于虚拟机的方案，以提供多可用区高可用性。 GDC 不支持跨多个物理可用区的 Kubernetes 集群。因此，将专用虚拟机部署到不同的可用区对于实现稳健的跨可用区架构至关重要。此配置可在单个基础架构可用区完全发生故障时继续运行。

平台原生全球负载均衡

该架构利用 GDC 全球 L4 负载平衡器，而不是虚拟机上的基于软件的代理。这种方法具有以下优势：

  • 全球可达性：提供可在所有可用区中访问的稳定虚拟 IP。
  • 平台管理：VIP 由平台的控制平面单独管理。
  • 简化了故障切换：故障切换通过标准健康检查探测进行管理，而不是通过复杂的本地软件配置进行管理。
  • 高可用性：消除对本地代理的依赖可确保数据库流量的入口点保持弹性。

假设和限制

前提

  • 环境具有本地注册表或用于导入打包的操作系统依赖项和二进制文件的机制。
  • 基于密钥的 SSH 访问权限可用于所有目标虚拟机，以实现基于 Ansible 的自动化。
  • 项目具有足够的配额，可用于预配多可用区虚拟机和负载平衡器。

限制

  • 手动维护：操作系统修补和 PostgreSQL 版本升级是手动任务，不会由解决方案自动执行。
  • 存储敏感度：共识层 (etcd) 对磁盘延迟高度敏感。持续的高存储争用可能会影响共识层的稳定性。
  • 网络稳定性：高可用性管理器依赖于可用区之间稳定、低延迟的网络连接。延迟或网络抖动可能会影响集群协调和角色转换的时序。

其他资料