PostgreSQL的集群化和容器化部署

原创
2019/02/13 12:22
阅读数 6.2K

对于PostgreSQL用户来说,随着数据增多、业务负载上升,需要将其进行容器化和集群化改造,以便于管理和伸缩规模。PostgreSQL虽然可以支持集群,但仍然是传统数据库架构而非分布式数据库架构。扩展为集群主要有两种方式:一是单写多读,slave节点实时同步,实施比较简单;二是多写多读,需要在中间层添加分布式事务协调器实现写一致性,多读机制与第一种方法相同。大部分情况下,数据库都是写少读多,第一种方案就足够了。

作为开源数据库的新星,PostgreSQL已经发展了多种集群化部署方案,主要分为裸机部署、容器部署和Kubernetes集群部署三种主要方式;而且,已经研发了相应的扩展版本和部署工具,可以更快地进行集群的部署和管理。不过,由于扩展插件(如PostGIS)往往落后于主版本的开发,与特定版本有一定的依赖性,在缺省的集群安装中可能无法使用,需要自己手动安装甚至从源码进行编译。

Postgres-XL-水平扩展集群

Postgres-XL(https://www.postgres-xl.org/) 基于 PostgreSQL 数据库构建,是一个通用的 ACID 开源的、可方便进行水平扩展的 SQL 数据库解决方案。Postgres-XL内建了MPP (Massively Parallel Processing)能力,引入了分布式事务协调器,支持多写多读,可用于商业智能、大数据分析等场合。

Postgres-XL 可非常灵活的应付各种负载,特性包括:

  • OLTP 写频繁的业务。

  • 商业智能需要MPP并行性。

  • 操作数据存储。

  • Key-value 存储。

  • GIS 地理空间数据存储。

  • 适合不同业务工作环境。

  • 多租户服务提供商托管环境。

Postgres-XL在PostgreSQL上增加了GTC和GTM,架构上是比较复杂的,虽然可以容器化但还没有完整的Kubernetes集群部署方案,因此目前无法利用Kubernetes的节点伸缩、自动化管理等能力,需要手工进行配置。

Kubernetes部署-自动伸缩集群

目前在Kubernetes上部署PostgreSQL集群的方案有Stolon(由SorintLab开发)、Crunchy(由CrunchyData开发)、Patroni(由Zalando开发)。

以上几种方法采用一主多从的模式进行部署,主从节点之间通过数据复制保持同步,数据通过单一节点写入,从多个节点读出。节点由Kubernetes进行管理,可以实现负载均衡、在线扩容、容错漂移等高级特性,适合写入频率低、读取负载高的应用场景。

Stolon的Kubernetes部署架构如下图所示:

不过,由于缺省安装方案只提供了基本的容器镜像,而且扩展插件(如PostGIS)往往落后于主版本的开发,与特定版本有一定的依赖性,在缺省的集群安装中可能无法使用,需要自己手动安装甚至从源码进行编译,进行自定义容器镜像的创建,然后修改yaml配置文件进行部署,第一次部署起来有一些繁琐(以后可以通过现成的yaml文件重建,就比较简单了)。

采用Stolon部署PostgreSQL到Kubernetes,运行的容器实例情况如下:

PostGIS-空间数据存取

PostGIS是支持地理空间数据存储、查询和简单空间运算的数据库系统,基于PostgreSQL扩展开发,可以单独安装发行版,或者在PostgreSQL中安装扩展插件来实现该功能,目前开源的QGIS和SuperMap、ESRI等商业GIS软件都支持PostGIS作为数据存储后端服务器。在使用StolonCrunchyPatroni部署时,目前没有现成的镜像可用,需要自定义容器镜像。

为了方便使用,PostGIS提供了一些演示地图数据(如下),也可以使用GDALQGIS等免费工具和SuperMap、ArcGIS等大型商业GIS平台进行数据的导入、导出、转换、投影、制图、分析等操作。使用GeoPandas也可以在Python环境中进行空间数据操作,以及使用Notebook、JupyterHub/JupyterLab进行融合的空间大数据分析。

目前,Postgres-XL和PostgreSQL标准安装都可以直接安装PostGIS模块,导入数据即可使用。在使用StolonCrunchyPatroni部署时,目前没有现成的镜像可用,需要自定义容器镜像(估计,很快会有人做出来的)。

pgAdmin-图形管理界面

使用pgAdmin的图形化界面进行管理,参考:Kubernetes上PostgreSQL集群的管理

网络共享存储

PostgreSQL集群的各个节点使用各自的存储,即便是使用共享的存储设备。这种模式可以提高数据存储的可靠性,但需要将各节点的存储尽可能分布到不同的存储设备上,以减少存储设备失效带来的数据丢失的风险。

在部署时需要考虑到节点漂移后的存储可用性问题,可以采用制定节点的方式来固定访问的存储位置(如使用本机磁盘时),或者使用网络共享存储来提供可迁移的分布式存储访问,可以使用传统的光纤存储网络或者基于以太网协议的IPSAN(包括IPSCSI),也可以使用基于软件的网络存储服务(NFS)以及分布式存储(GlusterFS、Ceph/Rook)等。关于网络存储服务,参考:

集群数据库展望

随着容器技术和集群技术的发展,越来越多的服务器软件开始向云原生环境迁移,数据库也不例外。传统数据库服务器不仅向多节点集群方案发展,还向容器化和Kubernetes集群部署模式演进,就连Oracle都已经推出容器部署的方案,而新出现的NoSQL/NewSQL数据库(如MongDB/Redis等等)更是从一开始就把多节点集群、容器集群作为原生运行环境进行开发。

本文介绍了传统业务大量使用的PostgreSQL数据库的分布式和容器集群部署方案,而MySQL作为互联网企业大量采用的数据库服务器系统,也出现了OceanBase、Vitess等多种集群化部署方案(参考《分布式MySQL集群Vitess-简介》、 分布式MySQL集群Vitess-Kubernetes部署》),前几年新创的CrateDB声称是同时具有NoSQL的灵活性和SQL的易用性的分布式数据库系统。

随着云原生技术的成熟和被接受度增加,传统数据库将能够更好地支持云原生环境,带来可以动态伸缩的大规模SQL数据服务体验,而面向云原生的“原生数据库”系统也将获得更大的发展和更广泛的应用。

 

展开阅读全文
打赏
1
0 收藏
分享
加载中
更多评论
打赏
0 评论
0 收藏
1
分享
返回顶部
顶部