组件清单

以 vip-manager、Haproxy、Pgbouncer、Postgres、Patroni、cadvisor、fluentd构建高可用PostgreSQL部署方案:

1. Patroni

使用Patroni管理一个3节点的PostgreSQL集群,实现自动failover和leader选举。

2. PgBouncer

部署一个PgBouncer实例,作为数据库连接池,提高连接利用率和吞吐量。

3. vip-manager

运行vip-manager管理一个虚拟IP,映射到Patroni集群的当前leader节点上。

4. Haproxy

配置Haproxy对PgBouncer进行反向代理,获得虚拟IP,实现到leader的请求转发。

5. cadvisor

在每台节点上运行cadvisor,收集机器和运行容器的监控指标。

6. fluentd

收集各节点的日志,统一发送到Elasticsearch。

7. docker-compose

编排所有服务,定义网络、卷等,并管理容器。

通过组合使用以上组件,可以实现一个自动故障转移、负载均衡、可监控的高可用Postgres部署方案。

基于以上方案，实现跨洲际的系统保障

通过这种设计,可以提供一个跨区域的冗余系统,避免单点故障,实现故障恢复和流量负载均衡。可以根据实际需要调整设计。

  1. 在不同洲际区域分别部署完整的HA集群和代理组件。例如在亚洲和美洲各部署一套。

  2. 两个区域之间使用异步Streaming Replication实现异地双活。

  3. 在每个区域内部同时具备故障自动转移功能。

  4. 在应用层实现读写分离,亚洲的应用优先读写亚洲集群,美洲的应用优先读写美洲集群。两地之间双向兼容数据。

  5. 在两个区域的代理前再加入全局负载均衡(GLB),对用户透明。它会自动根据应用就近原则路由流量。

  6. GLB层也可实现站点失效时的故障转移,例如如果美洲区域不可用,会将流量切换至亚洲。

  7. 利用监控系统获取两个区域的拓扑、延迟、服务可用情况等信息,实现基于情报的流量调度。

全局负载均衡(GLB)

引入GLB后,需要确保其自身的高可用性,谨慎设计流量迁移策略,并建立高质量的监控体系,以降低引入的新风险。

在跨区域部署的PostgreSQL高可用方案中使用全局负载均衡(GLB)存在一些技术风险需要注意:

  1. 网络质量风险

不同地区之间的网络质量和延迟可能波动较大,会影响GLB策略的执行效果。

  1. 单点故障风险

如果GLB自身存在单点故障,可能导致整个应用的不可用，需要GLB本身也具有冗余机制。

  1. 复杂度风险

添加GLB会增加系统复杂度,需要精心设计GLB的高可用、监控、调度等机制。

  1. 一致性风险

如果双写策略配置不当,可能导致两地数据不一致。

  1. 故障转移风险

区域故障时,大规模流量切换可能对备用区域造成冲击压力。

  1. 监控质量风险

GLB依赖监控数据质量,如果监控数据误报会导致错误的流量调度。

  1. 策略错误风险

GLB策略如果设计或实现有缺陷,也会引起问题。

灾备

同城双活

同城双活是在同城或相近区域内建立两个机房。同城双机房距离比较近，通信线路质量较好，比较容易实现数据的同步复制 ，保证高度的数据完整性和数据零丢失。
同城两个机房各承担一部分流量，一般入口流量完全随机，内部RPC调用尽量通过就近路由闭环在同机房，
相当于两个机房镜像部署了两个独立集群，数据仍然是单点写到主机房数据库，然后实时同步到另外一个机房。

两地三中心架构
所谓两地三中心是指 同城双中心 + 异地灾备中心。异地灾备中心是指在异地的城市建立一个备份的灾备中心，
用于双中心的数据备份，数据和服务平时都是冷的，
当双中心所在城市或者地区出现异常而都无法对外提供服务的时候，异地灾备中心可以用备份数据进行业务的恢复。