一种实现有状态服务存储数据共享的系统及方法

1.本发明属于计算机系统技术领域，具体涉及一种实现有状态服务存储数据共享的系统及方法。


背景技术：

2.docker是一个开源的应用容器引擎，让开发者可以打包他们的应用以及依赖包到一个可移植的容器中,然后发布到任何流行的linux机器或windows机器上,也可以实现虚拟化,容器是完全使用沙箱机制,相互之间不会有任何接口。
3.kubernetes是一种可自动实施linux容器操作的开源平台。它可以帮助用户省去应用容器化过程的许多手动部署和扩展操作。也就是说，可以将运行 linux容器的多组主机聚集在一起，由kubernetes帮助轻松高效地管理这些集群。而且，这些集群可跨公共云、私有云或混合云部署主机。因此，对于要求快速扩展的云原生应用而言(例如借助apache kafka进行的实时数据流处理)，kubernetes是理想的托管平台。
4.kubernetes对于有状态的容器应用或者对数据需要持久化的应用，不仅需要将容器内的目录挂载到宿主机的目录或者emptydir临时存储卷，而且需要更加可靠的存储来保护应用产生的重要数据，以便容器应用在重建之后，仍然可以使用之前的数据。不过，存储资源和计算资源(gpu/内存)的管理方式完全不同。为了能够屏蔽底层存储实现的细节，让用户方便使用，同时能让管理员方便管理，kubernetes从v1.0版本就引入了persistentvolume和 persistentvolumeclaim两个资源对象来实现对存储的管理子系统。
5.persistentvolume(pv)是对底层网络共享存储的对象，将共享存储定义为一种”资源“，比如节点(node)也是一种容器应用可以”消费“的资源。 pv由管理员进行创建和配置，它与共享存储的具体实现直接相关，例如 glusterfs、iscsi、rbd或gce/aws公有云提供的共享存储，通过插件式的机制完成与共享存储的对接，以供应用访问和使用；persistentvolumeclaim(pvc) 则是用户对于存储资源的一个”申请“。就像pod”消费“node的资源一样，pvc会”消费“pv资源。pvc可以申请特定的存储空间和访问模式。现在的容器平台kubernetes大概支持几种卷存储：1.分布式存储，比如：ceph， glusterfs，nfs以及各个云厂商的共享存储。2.本地存储，比如：hostpath，local。以上对接的存储在实际使用上都存在不同的限制条件，比如云厂商的共享存储则依赖于云厂商的基础设施，这样是供应商绑定；ceph，glusterfs开源的共享存储则依赖于团队或项目能够提供ceph，glusterfs等存储服务。不仅是技术上要求比较高，同时资源和维护成本也比较高；nfs则是单机版，高可用的开源方案也都不成熟；本地存储hostpath则存在安全问题，也是单机模式，容器漂移也存在问题；local卷也是单机模式，容器漂移问题。
6.由于实际使用中对于容器的共享存储有不同的需求，对于一些比较简单的使用场景，对于存储系统的要求不是很高，如果采用分布式存储，并对接到 kubernetes，这样无论是技术，资源还是维护成本都比较高。但是如果用单机的存储，如果挂载存储的服务器宕机又会导致存储不能用。所以针对这些场景，在容器环境中需要解决这些技术问题。


技术实现要素：

7.有鉴于此，本发明的第一目的在于提出一种实现有状态服务存储数据共享的系统。第二目的在于提出一种实现有状态服务存储数据共享的方法。
8.基于上述第一目的，一种实现有状态服务存储数据共享的系统，包括：容器平台、存储服务模块、业务容器、存储容器和共享卷，所述的业务容器，所述的存储容器和所述的共享卷部署在所述的容器平台中，所述的存储容器用以实现与所述的存储服务模块的数据交互功能，所述的业务容器和所述的存储容器能够读写同一个共享卷，实现数据共享。
9.所述的业务容器和所述的存储容器采用边车模式部署在一个pod内，两者挂载同一个共享卷。
10.所述的容器平台为kubernetes容器平台。
11.所述的存储服务模块采用nas或/和s3存储模式。
12.基于上述第二目的，一种实现有状态服务存储数据共享的方法，包括以下步骤：
13.步骤1，在一个pod的启动过程中，首先启动的是存储容器，然后是业务容器；
14.步骤2，存储容器在第一次启动，需要连接远端的存储服务模块，进行资源初始化；
15.步骤3，存储容器启动成功后，业务容器启动，按照服务数据持久化需求，把数据写入到共享卷；
16.步骤4，存储容器实时监测共享卷中的数据，并同步到远端的存储服务模块，同时根据创建存储版本；
17.步骤5，如果业务容器宕机，同时pod没有漂移到其他的负载节点，存储容器在启动时，如果远端的存储服务模块的存储版本和共享卷中的存储版本一致。则直接启动业务容器，如果不一致，则根据远端的存储服务模块的最新存储版本先进行数据恢复，即从远端的的存储服务模块中还原数据到共享卷中，然后启动业务容器；
18.步骤6，如果pod漂移到其他负载节点，存储容器在启动时，会检测远端的存储服务模块是否有对应的存储资源，如果远端的存储服务模块已经存在存储资源数据，则对远端的存储服务模块的存储版本和共享卷中的存储版本进行匹配，如果远端的存储服务模块的版本较新，则开始从远端的存储服务模块中恢复数据到共享卷，然后业务容器启动后就可以读到宕机前最新的版本数据；当业务容器有写入数据到共享卷中，存储容器会实时同步到远端的存储服务模块中。
19.与现有技术相比，本发明方法以下优点和有益效果：1、不需要重量级的分布式存储或对接到kubernetes中，也可以实现有状态服务在kuberentes平台上稳定运行，即使宕机或pod漂移到另外节点也能进行数据还原，支持服务运行；2、所采用的存储服务都是现在比较常用的资源来实现本方案，通用性和适用性比较好。在很多基础设施还没有完全支持容器化的企业能够比较快的实施和落地；3、通过边车模式的存储服务解决了有状态业务服务容器化的难点，对于业务服务零侵入性，技术落地和推广的成本比较低；4、结合了kuberentes 的本地共享卷和存储服务，解决了本地共享卷的单机模式，提高了共享卷的可用性。同时实现了自动的灾害和数据还原。
附图说明
20.图1为本发明实施例的系统的结构示意图；
21.图2为本发明实施例的方法的流程示意图。
具体实施方式
22.下面结合附图对本发明作进一步的说明，但不以任何方式对本发明加以限制，基于本发明教导所作的任何变换或替换，均属于本发明的保护范围。
23.实施例1：
24.如图1所示，一种实现有状态服务存储数据共享的系统，包括：容器平台、存储服务模块、业务容器、存储容器和共享卷，所述的业务容器、所述的存储容器和所述的共享卷部署在所述的容器平台中，所述的存储容器用以实现与所述的存储服务模块的数据交互功能，所述的业务容器和所述的存储容器能够读写同一个共享卷，实现数据共享。
25.业务容器对于共享卷使用就像是服务使用虚拟机本地磁盘一样。对于业务容器，可以理解为就是在使用本地硬盘。
26.所述的业务容器和所述的存储容器采用边车模式部署在一个pod内，两者挂载同一个共享卷。pod是kubernetes中的最小调度单元，一个pod封装一个容器(也可以封装多个容器)，pod里的容器共享存储、网络等。也就是说，可以把整个pod看作虚拟机，然后每个容器相当于运行在虚拟机的进程。同一个 pod里的所有容器都被统一安排和调度。
27.所述的容器平台为kubernetes容器平台。
28.所述的存储服务模块采用nas或/和s3存储模式。
29.实施例2：
30.如图2所示，一种实现有状态服务存储数据共享的方法，包括以下步骤：
31.步骤1，在一个pod的启动过程中，首先启动的是存储容器，然后是业务容器；
32.步骤2，存储容器在第一次启动，需要连接远端的存储服务模块，进行资源初始化；
33.步骤3，存储容器启动成功后，业务容器启动，按照服务数据持久化需求，把数据写入到共享卷；
34.步骤4，存储容器实时监测共享卷中的数据，并同步到远端的存储服务模块，同时根据创建存储版本；
35.步骤5，如果业务容器宕机，同时pod没有漂移到其他的负载节点，存储容器在启动时，如果远端的存储服务模块的存储版本和共享卷中的存储版本一致。则直接启动业务容器，如果不一致，则根据远端的存储服务模块的最新存储版本先进行数据恢复，即从远端的的存储服务模块中还原数据到共享卷中，然后启动业务容器；
36.步骤6，如果pod漂移到其他负载节点，存储容器在启动时，会检测远端的存储服务模块是否有对应的存储资源，如果远端的存储服务模块已经存在存储资源数据，则对远端的存储服务模块的存储版本和共享卷中的存储版本进行匹配，如果远端的存储服务模块的版本较新，则开始从远端的存储服务模块中恢复数据到共享卷，然后业务容器启动后就可以读到宕机前最新的版本数据；当业务容器有写入数据到共享卷中，存储容器会实时同步到远端的存储服务模块中。
37.本发明实施例有以下技术效果：
38.1、不需要重量级的分布式存储或对接到kubernetes中，也可以实现有状态服务在kuberentes平台上稳定运行，即使宕机或pod漂移到另外节点也能进行数据还原，支持服务
运行。
39.2、所采用的存储服务都是现在比较常用的资源来实现本方案，通用性和适用性比较好。在很多基础设施还没有完全支持容器化的企业能够比较快的实施和落地。
40.3、通过边车模式的存储服务解决了有状态业务服务容器化的难点，对于业务服务零侵入性，技术落地和推广的成本比较低。
41.4、结合了kuberentes的本地共享卷和存储服务，解决了本地共享卷的单机模式，提高了共享卷的可用性。同时实现了自动的灾害和数据还原。
42.5、本方案属于轻量级方案，不适合大规模数据存储。
43.上述实施例为本发明方法的一种实施方式，但本发明的实施方式并不受所述实施例的限制，其他的任何背离本发明的精神实质与原理下所做的改变、修饰、代替、组合、简化，均应为等效的置换方式，都包含在本发明的保护范围之内。