系统架构

介绍Pigsty的系统架构

一套Pigsty部署在架构上分为两个部分：

  • 基础设施（Infra） ：部署于元节点上，监控，DNS，NTP，DCS，Yum源等基础服务。
  • 数据库集群（PgSQL）：部署于数据库节点上，以集群为单位对外提供数据库服务。

同时，用于部署的 节点（物理机，虚拟机，Pod）也分为两种：

  • 元节点（Meta）：部署基础设施，执行控制逻辑，每个Pigsty部署至少需要一个元节点。
  • 数据库节点（Node）：用于部署数据库集群/实例，节点与数据库实例一一对应。

沙箱样例

以Pigsty附带的四节点沙箱环境为例，组件在节点上的分布如下图所示：

图：Pigsty沙箱中包含的节点与组件

沙箱由一个元节点与四个数据库节点组成（元节点也被复用为一个数据库节点），部署有一套基础设施与两套数据库集群。 meta 为元节点，部署有基础设施组件，同时被复用为普通数据库节点，部署有单主数据库集群pg-meta。 node-1，node-2，node-3 为普通数据库节点，部署有数据库集群pg-test。

基础设施

每一套 Pigsty 部署（Deployment） 中，都需要有一些基础设施，才能使整个系统正常工作。

基础设施通常由专业的运维团队或云厂商负责，但Pigsty作为一个开箱即用的产品解决方案，将基本的基础设施集成至供给方案中。

  • 域名基础设施：Dnsmasq（部分请求转发至Consul DNS处理）
  • 时间基础设施：NTP
  • 监控基础设施：Prometheus
  • 报警基础设施：Altermanager
  • 可视化基础设施：Grafana
  • 本地源基础设施：Yum/Nginx
  • 分布式配置存储：etcd/consul
  • Pigsty基础设施：元数据库MetaDB，管理组件Ansible，定时任务，与其他高级特性组件。

基础设施部署于 元节点 上。一套环境中包含一个或多个元节点，用于基础设施部署。

除了 分布式配置存储（DCS） 之外，所有基础设施组件都采用副本式部署；如果有多个元节点，元节点上的DCS（etcd/consul）会共同作为DCS Server。

元节点

在每套环境中，Pigsty最少需要一个元节点，该节点将作为整个环境的控制中心。元节点负责各种管理工作：保存状态，管理配置，发起任务，收集指标，等等。整个环境的基础设施组件，Nginx，Grafana，Prometheus，Alertmanager，NTP，DNS Nameserver，DCS都将部署在元节点上。

同时，元节点也将用于部署元数据库 （Consul 或 Etcd），用户也可以使用已有的外部DCS集群。如果将DCS部署至元节点上，建议在生产环境使用3个元节点，以充分保证DCS服务的可用性。DCS外的基础设施组件都将以对等副本的方式部署在所有元节点上。元节点的数量要求最少1个，推荐3个，建议不超过5个。

元节点上运行的服务如下所示：

组件 端口 默认域名 说明
Grafana 3000 g.pigsty Pigsty监控系统图形界面
Prometheus 9090 p.pigsty 监控时序数据库
AlertManager 9093 a.pigsty 报警聚合管理组件
Consul 8500 c.pigsty 分布式配置管理，服务发现
Consul DNS 8600 - Consul提供的DNS服务
Nginx 80 pigsty 所有服务的入口代理
Yum Repo 80 yum.pigsty 本地Yum源
Haproxy Index 80 h.pigsty 所有Haproxy管理界面的访问代理
NTP 123 n.pigsty 环境统一使用的NTP时间服务器
Dnsmasq 53 - 环境统一使用的DNS域名解析服务器

部署于元节点上的基础设置架构如下图所示：

其主要交互关系如下：

  • Dnsmasq提供环境内的DNS解析服务（可选，可使用已有Nameserver）

    部分DNS解析将转交由Consul DNS进行

  • Nginx对外暴露所有Web服务，通过域名进行区分转发。

  • Yum Repo是Nginx的默认服务器，为环境中所有节点提供从离线安装软件的能力。

  • Grafana是Pigsty监控系统的载体，用于可视化Prometheus与CMDB中的数据。

  • Prometheus是监控用时序数据库。

    • Prometheus默认从Consul获取所有需要抓取的Exporter，并为其关联身份信息。
    • Prometheus从Exporter拉取监控指标数据，进行预计算加工后存入自己的TSDB中。
    • Prometheus计算报警规则，将报警事件发往Alertmanager处理。

  • Consul Server用于保存DCS的状态，达成共识，服务元数据查询。

  • NTP服务用于同步环境内所有节点的时间（可选用外部NTP服务）

  • Pigsty相关组件：

    • 用于执行剧本，发起控制的Ansible
    • 用于支持各种高级功能的MetaDB（也是一个标准的数据库集群）
    • 定时任务控制器（备份，清理，统计，巡检，高级特性暂未加入）

数据库集群

生产环境的数据库以集群为单位进行组织，集群是一个由主从复制所关联的一组数据库实例所构成的逻辑实体。每个数据库集群是一个自组织的业务服务单元，由至少一个数据库实例组成。

集群是基本的业务服务单元，下图展示了沙箱环境中的复制拓扑。其中pg-meta-1单独构成一个数据库集群pg-meta，而pg-test-1，pg-test-2，pg-test-3共同构成另一个逻辑集群pg-test。

pg-meta-1
(primary)

pg-test-1 -------------> pg-test-2
(primary)      |         (replica)
               |
               ^-------> pg-test-3
                         (replica)

下图从数据库集群的视角重新排列pg-test集群中相关组件的位置。

图：从数据库集群的逻辑视角审视架构（标准接入方案）

Pigsty是数据库供给方案，可以按需创建高可用数据库集群。只要集群中有任意实例存活，集群就可以对外提供完整的读写服务与只读服务。Pigsty可以自动进行故障切换，业务方只读流量不受影响；读写流量的影响视具体配置与负载，通常在几秒到几十秒的范围。

在Pigsty中，每个“数据库实例”在使用上是幂等的，采用类似NodePort的方式对外暴露 数据库服务。默认情况下，访问任意实例的5433端口即可访问主库，访问任意实例的5434端口即可访问从库。用户也可以灵活地同时使用不同的方式访问数据库，详情请参考：数据库接入。

数据库节点

数据库节点负责运行数据库实例， 在Pigsty中数据库实例固定采用独占式部署，一个节点上有且仅有一个数据库实例，因此节点与数据库实例可以互用唯一标识（IP地址与实例名）。

一个典型的数据库节点上运行的服务如下所示：

组件 端口 说明
Postgres 5432 Postgres数据库服务
Pgbouncer 6432 Pgbouncer连接池服务
Patroni 8008 Patroni高可用组件
Consul 8500 分布式配置管理，服务发现组件Consul的本地Agent
Haproxy Primary 5433 集群读写服务（主库连接池）代理
Haproxy Replica 5434 集群只读服务（从库连接池）代理
Haproxy Default 5436 集群主库直连服务（用于管理，DDL/DML变更）
Haproxy Offline 5438 集群离线读取服务（直连离线实例，用于ETL，交互式查询）
Haproxy <Service> 543x 集群提供的额外自定义服务将依次分配端口
Haproxy Admin 9101 Haproxy 监控指标与管理页面
PG Exporter 9630 Postgres监控指标导出器
PGBouncer Exporter 9631 Pgbouncer监控指标导出器
Node Exporter 9100 机器节点监控指标导出器
Consul DNS 8600 Consul提供的DNS服务
vip-manager x 将VIP绑定至集群主库上

主要交互关系如下：

  • vip-manager通过查询Consul获取集群主库信息，将集群专用L2 VIP绑定至主库节点（默认接入方案）。

  • Haproxy是数据库流量入口，用于对外暴露服务，使用不同端口（543x）区分不同的服务。

    • Haproxy的9101端口暴露Haproxy的内部监控指标，同时提供Admin界面控制流量。
    • Haproxy 5433端口默认指向集群主库连接池6432端口
    • Haproxy 5434端口默认指向集群从库连接池6432端口
    • Haproxy 5436端口默认直接指向集群主库5432端口
    • Haproxy 5438端口默认直接指向集群离线实例5432端口

  • Pgbouncer用于池化数据库连接，缓冲故障冲击，暴露额外指标。

    • 生产服务（高频非交互，5433/5434）必须通过Pgbouncer访问。

    • 直连服务（管理与ETL，5436/5438）必须绕开Pgbouncer直连。

  • Postgres提供实际数据库服务，通过流复制构成主从数据库集群。

  • Patroni用于监管Postgres服务，负责主从选举与切换，健康检查，配置管理。

    • Patroni使用Consul达成共识，作为集群领导者选举的依据。

  • Consul Agent用于下发配置，接受服务注册，服务发现，提供DNS查询。

    • 所有使用端口的进程服务都会注册至Consul中

  • PGB Exporter，PG Exporter， Node Exporter分别用于暴露数据库，连接池，节点的监控指标

节点与元节点交互

以单个 元节点 和 单个 数据库节点 构成的环境为例，架构如下图所示：

图：单个元节点与单个数据库节点（点击查看大图）

元节点与数据库节点之间的交互主要包括：

  • 数据库集群/节点的域名依赖元节点的Nameserver进行解析。

  • 数据库节点软件安装需要用到元节点上的Yum Repo。

  • 数据库集群/节点的监控指标会被元节点的Prometheus收集。

  • Pigsty会从元节点上发起对数据库节点的管理

    执行集群创建，扩缩容，用户、服务、HBA修改；日志收集、垃圾清理，备份，巡检等

  • 数据库节点的Consul会向元节点的DCS同步本地注册的服务，并代理状态读写操作。

  • 数据库节点会从元节点（或其他NTP服务器）同步时间

最后修改 2021-03-28: update arch access (d1fa2b3)