天作之合:Greenplum移植到Kubernetes上

如果你好奇在Kubernetes上运行什么样的应用程序最好,根据我们的经验,水平扩展的分布式应用绝对是名列前茅的,而Greenplum就是最好的例子。

我们于2017年正式成立项目,致力于研究Greenplum如何最大化利用容器技术以及容器管理平台(例如Kubernetes)的优势。当时,Greenplum已经开始通过SQL查询和UDF(用户自定义函数)利用容器(例如PL/Container)。这些容器曾经在(现在仍旧)在函数的隔离上,和资源的精细管理方面非常有用。我们的下一个步骤就是将整个Greenplum移植到容器里面。这是否会是一种非常规的方式?是否是一个对遗留应用的“提升加搬动”有效的解决方案?这两种技术(Greenplum与容器)是否会像手与手套一样的天衣无缝地融合?

在探索的过程中,我们首先把Greenplum打包在了一个容器里面,并只运行此单个容器。当然这并不是一个完整的方案,但在正确的方向上迈出了第一步。这可以帮助我们测试和理解如何在这种环境下,进行程序的隔离、资源管理和数据存储。需要指出的是,容器并不是一个新技术,它没有增加新的层来隔离执程序和硬件资源,而仅仅是利用了Linux内核的基础设施,比如说,cgroups、命名空间(namespaces)和chroot,这些都是在过去40年里逐步加入内核的。


在运行的时候,容器中执行的代码和非容器中的代码一样,都是直接运行在硬件上。请不要与容器“镜像”的概念混淆,容器镜像的目的是为了可移植性,镜像并不属于运行环境,因此,你没有性能损失的用全部的硬件资源来执行容器中的代码。此外,如果你希望使用虚拟机带来的各种便利,也可以把容器部署到虚拟机里,你的代码在虚拟机的容器里将和直接运行在虚拟机中有一样的效果。

在把Greenplum放进单个容器之后,我们意识到这不是Greenplum到容器的最佳分配。因为Greenplum是一个MPP(大规模并行处理的Postgres数据库)系统,我们至少也需要把这整个集群分散到多个容器里面,让这些容器可以彼此识别,共同合作。于是,Kubernetes便出场了。

Kubernetes是一个开源的容器管理平台,它允许我们把Greenplum从单个容器里打散,真正地以一个水平扩展的分布式数据库的模式运行。Kubernetes把多个容器捆绑成为pods。一个pod可以有一个或一个以上的容器,它们彼此共享存储。在我们的例子里,这些存储是由PV(persistent volumes/持久卷)实现的。用户可以自行决定这些PV是本地的还是远程的。

再重申一次,这些组成pod的容器组,仅仅利用了Linux内核的运行构建而成。Kubernetes通过它的调度程序(scheduler)来指挥每个pods可以在哪个工作节点上执行。一个Kubernetes的集群也有主节点来运行其调度程序和其他的管理功能模块。我们通过提供(反)关联规则和节点选择器(一种简化的关联规则)来辅助Kubernetes进行调度决策。如果将来我们需要更复杂的逻辑,Kubernetes也支持自定义的调度程序。

我们可以为容器限定CPU和内存,在Kubernetes中,这被称为申请(requests)和限制(limits)。在工作节点上的可用资源是通过Linux内核的cgroups来实现管理的。

Kubernetes为Greenplum提供了一个非常理想的平台。它让我们通过精细的控制集群内计算的分布,得以清晰地分离计算和存储,并且为我们提供了管理资源的控制钮。 于是,Greenplum也自然成为了Kubernetes上面的巨型应用。因为它可以把用户的数据分布到整个集群,完成并行SQL和PL/language的查询。让我们迅速回顾一下Greenplum的架构。它由一个master一个 standby master大量的primary segments及其mirror segments组成。每一个segment都运行了自己的Postgres数据库,并且支持很多库与工具,来支持人工智能(AI)/机器学习,图像和文本分析等。

当收到一个查询时,master会建立一个查询计划,把查询执行分发到所有的primary segment上,使得Greenplum可以在很多的时间内返回结果。primary segment越多,数据并行性越好,你的分析就越快。

在Greenplum这种横向扩展的分布式架构下,当我们需要增加计算或者存储的时,只要简单地增加Segment数目。同样的,在Kubernetes上,一个应用程序也可以通过增加pods的数量来增强它的能力。很明显,Greenplum的基本单元和Kubernetes存在着一对一的关系:一个Greenplum的Segment映射到一个Kubernetes的pod。


正是因为Greenplum和Kubernetes本质上都是分布式系统,其在架构上才能得以完美契合。正基于此,我们才能摆脱Greenplum单一容器的设计,移植到一个高度可靠、基于Linux内核的容器协调系统里,运行原汁原味的Greenplum,为用户提供完美体验。而整体的解决方案又进一步提供了众多额外好处。

其中一个好处就是Operator模式,它可以自定义Kubernetes对一个应用程序的控制。这意味着,我们可以建立一个Greenplum的Operator,使Greenplum成为Kubernetes的一等公民。通过这个Operator来自动化各种运营操作,比如对整套相关工具和组件,而不仅仅是Greenplum,进行部署、故障转移、扩展、升级和打补丁等工作。

我们要注意的是,自动升级和打补丁,不等于零停机滚动升级。这其实是意味着,在指定的维护窗口内,用户可以单独触发Greenplum Operator进行升级,完成必要的步骤,并在升级过程中保存已有的状态和数据库里的数据。

另一个巨大的好处就是,我们可以在我们的CI(持续集成)流水线里管理应用程序的依赖库。这样的话,客户就可以省去很多麻烦,Greenplum和它丰富的生态系统就可以进行安全、设置、集成、网络、依赖这些方面的测试,然后封装到一个软件包里发布,建立一个新的Greenplum工作台,或者升级现有系统。当然用户还是可以自己控制组件的开启和设置。

但是有一个注意事项:总体性能需要底层硬件的支撑。像纯硬件部署一样,我们的硬件需要为pods提供足够的CPU、内存、磁盘IO和网络IO,Kubernetes不能奇迹般的飞升Greenplum的性能。在Kubernetes上面正确地部署,尤其是运行一个数据库,并不是一件简单的事情。在广大的Kubernetes社区里,这一块仍旧是一个挑战。我们经常可以见到在生产环境里部署不带状态的应用程序,而对数据库目前还是一个相对新的领域。

总而言之,我们的研究带领我们进入一个全新的领域,在这里,我们看到在Kubernetes上面运行象Greenplum这样的MPP数据库所带来的巨大机遇和好处。这不是一种生搬硬套,也不是对遗留应用的简单粗暴的迁移,而是这两种技术(Greenplum与容器)天衣无缝的融合。我们确信大规模并行Postgres数据库和Kubernetes的结合就是天作之合。

想要深入了解,请参考我们团队写在Pivotal Engineering Journal(Pivotal编程杂志)的文章:

使用运营商模式管理有状态应用; 编排注意事项 

存储超过容器或群集的有状态数据; 优化本地卷

提供有状态的Kubernetes容器,努力工作并保持活力

Kubernetes中的有状态应用程序

Greenbeum在Kubernetes运行

使用Minikube开发Kubernetes的Greenplum

作者简介

Oz Basarir,Pivotal技术产品经理

译者简介

李伦,中兴通讯上海研发中心虚拟化架构师

校对者简介

朱君鹏,华东师范大学博士研究生,个人兴趣主要集中在:新型硬件(GPU、RDMA、FPGA)等在数据库中的应用,架构设计与并行计算。

另外感谢Greenplum Kubernetes开发人员张辛对翻译重新进行了润色

原文链接

关注微信公众号

VMware 中国研发中心

Greenplum官方技术交流群

扫码添加小助手即可入群,添加时请备注 “GP网站”