一种分布式存储集群数据通信方法及系统与流程

本发明涉及分布式存储技术领域，更具体地说，涉及一种分布式存储集群数据通信方法及系统。

背景技术：

随着互联网业务量的增加、访问量和数据流量的快速增长，存储系统各个核心部分的处理强度也相对增大，使系统工作负载增大。用户需要访问存储系统的信息量呈爆炸式增长，存储系统规模的日益壮大给访问服务器的压力带来了巨大的挑战，尤其是对于金融、军事、大型企业等应用领域，存储系统一旦出现访问故障、崩溃等灾难性故障，企业将面临着难以承受的巨大损失，访问的可靠性已经成为衡量存储系统总体性能的重要因素。

目前在ceph标准版本中，每个osd设备都对应一个osd进程。osd之间的数据通信和心跳检测需要建立网络连接。在一定规模内，每个节点上的osd之间建立的tcp连接数，以及本节点osd与其他节点osd之间建立的tcp网络连接数与单节点盘位数的平方成正比，并且随着节点数的增加而线性增长。对于36盘位集群，当节点数达到10或更高时，单节点上的连接数会超过60000，已经超过系统所能承载的上限。

因此，如何降低节点间的连接数，解决由于连接数过多导致的集群规模受限的问题，是本领域技术人员需要解决的。

技术实现要素：

本发明的目的在于提供一种分布式存储集群数据通信方法及系统，以实现降低节点间的连接数，解决由于连接数过多导致的集群规模受限的问题。

为实现上述目的，本发明实施例提供了如下技术方案：

一种分布式存储集群的数据通信方法，包括：

源节点的源osd向目的节点的目标osd发送数据时，所述源osd将所述数据通过源节点的虚拟messenger发送至所述源节点的真实messenger，通过所述源节点的真实messenger将所述数据发送至所述目的节点的真实messenger；

所述目的节点的真实messenger接收所述数据，通过所述目的节点的虚拟messenger将所述数据下发至所述目的节点的目标osd。

其中，所述目的节点的真实messenger接收所述数据，包括：

所述目的节点的真实messenger，通过所述源节点和所述目的节点间唯一的tcp连接，接收所述源节点真实messenger发送的所述数据。

其中，所述通过所述目的节点的虚拟messenger将所述数据下发至所述目的节点的目标osd，包括：

所述目的节点的虚拟messenger接收所述目的节点的真实messenger发送的所述数据，通过所述数据中携带的目标osd的地址信息，调用与所述目标osd对应的处理函数处理所述数据。

其中，所述目的节点的虚拟messenger接收所述目的节点的真实

messenger发送的所述数据之后，还包括：

判断所述数据的目的端是否为osd；

若是，则执行通过所述数据中携带的目标osd的地址信息，调用与所述目标osd对应的处理函数处理所述数据的步骤。

其中，所述源节点的源osd向目的节点的目标osd发送数据之前，还包括：虚拟进程接收系统下发的osd管理指令，通过管理套接字向主进程发送管理osd的指令；所述管理osd的指令携带的osd地址信息与所述osd管理指令携带的地址信息相同。

其中，所述源节点的源osd向目的节点的目标osd发送数据之前，还包括：源节点的真实messenger与所述目的节点的真实messenger建立真实连接，并在连接成功后，源节点的虚拟messenger与目的节点的虚拟messenger建立虚拟连接；所述真实连接用于发送数据，所述虚拟连接用户发送osd基础信息。

一种分布式存储集群的数据通信系统，所述数据通信系统的每个节点包括：与本节点内所有osd通信连接的虚拟messenger，以及与虚拟messenger通信连接的真实messenger；

其中，每个节点的虚拟messenger，用于将本节点内osd发送的数据发送至本节点的真实messenger；并将本节点的真实messenger发送的数据下发至对应的osd；

每个节点的真实messenger，用于将本节点虚拟messenger上传的数据发送至目的节点的真实messenger；将源节点的真实messenger发送的数据下发至本节点的虚拟messenger。

其中，每个节点的虚拟messenger接收真实messenger发送的数据，通过数据中携带的目标osd的地址信息，调用与所述目标osd对应的处理函数处理所述数据。

其中，两个节点的真实messenger之间，通过节点间唯一的tcp连接进行数据的传输。

其中，两个节点的虚拟messenger之间，通过建立虚拟连接进行osd基础信息的传输。

通过以上方案可知，本发明实施例提供的一种分布式存储集群的数据通信方法，包括：源节点的源osd向目的节点的目标osd发送数据时，所述源osd将所述数据通过源节点的虚拟messenger发送至所述源节点的真实messenger，通过所述源节点的真实messenger将所述数据发送至所述目的节点的真实messenger；所述目的节点的真实messenger接收所述数据，通过所述目的节点的虚拟messenger将所述数据下发至所述目的节点的目标osd；

可见，在本方案中，每个节点中的所有osd发送数据或者接收数据时，均是通过节点间的真实messenger之间建立的真实连接进行数据的传输，并通过每个节点的虚拟messenger实现该节点内osd数据的上传及下发，节点间的osd的连接数与osd的数量没有关系，单节点的盘位数无关，只与集群的节点总数有关，从而降低了集群的连接数，解决由于连接数过多导致的集群规模受限的问题；本发明还公开了一种分布式存储集群的数据通信系统，同样能实现上述技术效果。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本发明实施例公开的一种分布式存储集群的数据通信方法流程示意图；

图2为现有技术中节点通讯示意图；

图3为本发明实施例公开的本实施例公开的节点通讯示意图；

图4为本发明实施例公开的数据下发流程示意图；

图5为本发明实施例公开的ceph标准版本下单节点的osd管理示意图；

图6为本发明实施例公开的单进程方案下单节点的osd管理示意图；

图7为本发明实施例公开的节点间建立连接流程示意图；

图8为本发明实施例公开的mark_down函数关闭连接流程示意图；

图9为本发明实施例公开的调用reset关闭连接流程示意图；

图10为本发明实施例公开的一种分布式存储集群的数据通信系统结构示意图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

本发明实施例公开了一种分布式存储集群数据通信方法及系统，以实现降低节点间的连接数，解决由于连接数过多导致的集群规模受限的问题。

参见图1，本发明实施例提供的一种分布式存储集群的数据通信方法，包括：

s101、源节点的源osd向目的节点的目标osd发送数据时，所述源osd将所述数据通过源节点的虚拟messenger发送至所述源节点的真实messenger，通过所述源节点的真实messenger将所述数据发送至所述目的节点的真实messenger；

具体的，在本方案中，每个目的节点的真实messenger，通过源节点和目的节点间唯一的tcp连接，接收源节点真实messenger发送的所述数据。也就是说，在本方案中，节点间进行数据传输是通过节点间建立的唯一tcp连接进行数据的传输。在进行数据的传输时，osd会先将数据发送至节点内的唯一的虚拟messenger，通过虚拟messenger将数据发送至节点内的唯一的真实messenger，且两个节点内的tcp连接是通过两个节点的真实messenger建立的，因此，osd要发送的数据会通过节点的真实messenger发送至目标节点的真实messenger，从而实现数据的发送。

可以理解的是，在数据传输之前，需要进行初始化处理，在现有方案中，节点内每个osd有与之唯一对应的messenger，因此在初始化时，osd需要将自己作为订阅者注册到与之唯一对应的messenger去，并且现有方案的通讯示意图如图2所示。本方案中的messenger为信差，实现数据的传输。

而在本方案中，由于每个节点内部只有一个虚拟messenger和真实messenger，因此在初始化处理时，需要每个osd将自己作为订阅者注册到虚拟messenger，并且虚拟messenger要将自己作为订阅者注册到真实messenger；注册后，虚拟messenger便知道本节点内osd的基础信息，该基础信息包括osd的ip地址等，从而实现了虚拟messenger接收各osd发送的数据，以及向对应的osd下发数据；同样的，真实messenger便可知道本节点内虚拟messenger的基础信息，例如虚拟messenger的ip地址等，从而实现了真实messenger接收虚拟messenger上传的数据以及向虚拟messenger下发数据，具体通信示意图如图3所示。

s102、所述目的节点的真实messenger接收所述数据，通过所述目的节点的虚拟messenger将所述数据下发至所述目的节点的目标osd。

其中，所述通过所述目的节点的虚拟messenger将所述数据下发至所述目的节点的目标osd，包括：

所述目的节点的虚拟messenger接收所述目的节点的真实messenger发送的所述数据，通过所述数据中携带的目标osd的地址信息，调用与所述目标osd对应的处理函数处理所述数据。

参见图4，为本实施例提供的数据下发流程示意图，具体来说，目的节点的虚拟messenger接收目的节点的真实messenger发送的所述数据之后，还包括：判断所述数据的目的端是否为osd；若是，则执行通过所述数据中携带的目标osd的地址信息，调用与所述目标osd对应的处理函数处理所述数据的步骤。

具体的，在单进程osd模式下，多个osd共享一个tcp连接，为了能够准确将数据发送到目的地，所有发往osd的数据需要在message中添加目的osdid成员变量，这个工作在虚拟连接的发送函数中完成。osd端收到数据之后，会调用osd注册的dispatcher函数进行数据处理，为了找到正确的dispatcher，需要在dispatcher中增加osdid成员变量，通过message中的osdid对比找到正确的osddispatcher处理。

需要说明的是，由于所有osd共享一个连接，因此osd的dispatcher函数要尽快返回，所以需要dispatcher将数据放入队列中就返回，然后由工作线程从队列中取出数据做进一步处理。

进一步的，vritual_messenger(虚拟messenger)类中实现一套messenger中的实现函数，除了通信模块vritual_messenger类基于dispatcher，osd等模块的处理函数都注册到vritual_messenger中，对于单进程模式来说，需要特殊处理的都在vritual_messenger中实现，不再去更改messenger中的函数实现之外，其他模块均使用vritual_messenger类来进行数据接收和发送。

可以看出，本方案中的节点间通过真实messenger间建立的唯一连接实现数据的传输，大幅度减少分布式文件系统中网络连接的数量，消除网络连接数过多引起的集群扩容的瓶颈问题。与此同时，因为网络模块采用的是多线程并发模型，每个网络连接都有一组线程提供服务，所以减少网络连接数量就意味着减少了线程个数，减少资源消耗，减轻cpu的压力。

基于上述任意实施例，在本实施例中，所述源节点的源osd向目的节点的目标osd发送数据之前，还包括：

虚拟进程接收系统下发的osd管理指令，通过管理套接字向主进程发送管理osd的指令；所述管理osd的指令携带的osd地址信息与所述osd管理指令携带的地址信息相同。

具体的，由于本方案中的进程为单进程，因此在本实施例中，提供一种单进程osd管理方法，需要说明的是，系统下发的osd管理指令包括对osd的启动、停止、重启及状态查询等，在本实施例中仅以启动、停止、重启及状态查询为例进行描述。

需要说明的是，为了使osd服务运行过程中，每个osd的cgroup中都有进程存在，在单进程方案中仍需要为每个osd启动一个单独的进程。不过该进程不会加入ceph集群，也不对外提供服务，它的主要作用是接收systemctl的指令，然后通过管理套接字将指令发送给真正的、唯一的osd后台服务进程。下面为简单起见，将每个osd的进程称为pseudo进程，将真正的、唯一的osd后台服务进程称为admin进程。admin进程是一个单独的服务进程，它本身也要接受systemctl的管理。每个osd服务要依赖该服务，即每osd服务运行期间，admin服务必须始终运行。参见图5，为本实施例提供的ceph标准版本下单节点的osd管理示意图；参见图6，为本实施例提供的单进程方案下单节点的osd管理示意图。

在这种pseudo-admin架构下，对单个osd的管理命令的实现如下：

1、启动osd：systemctl通过如下命令启动pseudo进程(示例)：

/usr/bin/ceph-osd–f–clusterceph–id32–setuserceph–setgroupceph

pseudo进程在启动后，通过管理套接字向admin进程发出启动osd的指令，该指令最关键的参数是osd的id。admin进程在接收到指令后，在进程内启动相应的osd。

本实施例中的存储服务器使用的是linux的系统，在linux系统下，采用systemd(systemd即为systemdaemon,是linux下的一种init软件)的技术对osd进程进行启动和停止。具体来说，比如要启动id为5的osd进程，那么会使用命令：systemctlstarticfs-osd@5。

我们使用systemd技术就要遵从systemd的要求，我们需要利用service文件，在service文件中我们会指定程序的路径和名字，/usr/bin/ceph-osd就是程序程序的路径和名字，程序为ceph-osd,它在/usr/bin/目录下。后面的-f–cluster什么的为程序的参数。执行了systemctlstarticfs-osd@5命令后，systemd就会按照我们service文件中所配置的程序路径和参数来启动我们的程序(进程)。也就是systemd会执行/usr/bin/ceph-osd–f–clusterceph–id5–setuserceph–setgroupceph来启动id为5的osd进程。我们称这个id为5的osd进程为osd.5。

2、停止osd：systemctl通过cgroup找到pseudo进程，并向该进程发出sigterm信号。pseudo进程在捕获sigterm后，通过管理套接字向admin进程发出停止osd的指令，然后退出。admin进程在接受到指令后，在进程内停止相应的osd。

3、重启osd：先停止pseudo进程，再启动pseudo进程。在此过程中admin进程会停止和再启动osd。

4、查询状态：pseudo进程在执行过程中，周期性地通过管理套接字向admin进程查询对应osd的状态。如果检测到该osd已经停止(异常退出)，pseudo进程也会退出。

admin进程将记录pseudo进程每次查询的时间，如果在指定的超时时间内没有接收到pseudo进程的查询命令，admin进程将主动停止相应的osd。

综上所述，本实施例中pseudo进程和admin进程的联系和区别具体包括如下所述：

1、pseudo进程的systemd配置文件是ceph-osd@.service；admin进程的systemd配置文件是ceph-osd-admin.service。

2、pseudo进程和admin进程的名称都是ceph-osd，但命令行参数不同。pseudo进程的命令行参数包含osd的id，admin进程的命令行参数不包含osd的id。

3、在一个节点上，pseudo进程通常有多个(和osd数一致)，admin进程只有一个。

4、pseudo进程不接入集群，也不实际提供服务；admin进程中的osd要接入集群并实际提供服务。

5、pseudo进程通过管理套接字来管理admin进程中对应id的osd。在一定的超时时间许可内，一个pseudo进程和admin进程中的一个osd相对应。

6、ceph-osd@.service依赖于ceph-osd-admin.service。在启动pseudo进程时，如果admin进程尚未启动，systemd会自动启动admin进程。

基于上述任意实施例，在本实施例中，所述源节点的源osd向目的节点的目标osd发送数据之前，还包括：

源节点的真实messenger与所述目的节点的真实messenger建立真实连接，并在连接成功后，源节点的虚拟messenger与目的节点的虚拟messenger建立虚拟连接；所述真实连接用于发送数据，所述虚拟连接用户发送osd基础信息。

具体的，本方案中的osd节点内多个osd共享一个真实连接，为了实现原来设计中的一对一的连接关系，在本方案中新建一个虚拟连接，每个osd对外采用虚拟连接与外界进行通信，虚拟连接的另一个作用是维持osd中的session机制。进而，osd与osd之间维持一个session，与connection同时创建，同时销毁，session与connection是一一对应关系，在单进程osd模式下，这个对应关系由虚拟连接与session来完成。

为了接口统一，目前所有的数据通信都要采用虚拟连接的方式，与另一个实体通信，首先要获取连接，获取连接有两种方式，从message中获取和调用get_connection来获取，这部分由virtual_messenger来保证，virtual_messenger实现自己的get_connection函数来返回虚拟连接，同时在接收到数据的预处理函数中给message设置虚拟连接，以供后面数据回应时获取连接，建立虚拟连接的方式尽量模拟实体连接的实现，流程如图7所示，图7为本实施例提供的节点间建立连接流程示意图；本方案中的osd基础信息为osd的ip地址信息等。

进一步的，在单进程的模式下，真实的tcp连接是节点与节点之间的，属于一个长链接，在上层业务处理时存在关闭旧连接建立新链接的动作，这个时候不能去关闭真实的tcp连接，我们采用关闭虚拟连接的方式与之适配，关闭连接主要有两种模式，应用层调用markdown函数关闭连接和真实tcp连接出问题调用reset函数。参见图8，为本实施例提供的mark_down函数关闭连接流程示意图，参见图9，为本实施例提供的调用reset关闭连接流程示意图。

具体的，对于连接的关闭这种情况，由虚拟连接与原来的业务逻辑对应，这样就不会影响到上层的业务逻辑，实现对业务逻辑的透明。对于mark_down函数调用过程中，涉及到调用上层虚拟链接reset函数的操作，都要先将虚拟链接放入到异步处理队列中来处理。

综上可见，单进程模式下由于一个节点内多个osd共享一个连接，为了保持原有的连接和osd一对一的形式，所有的数据通信都采用虚拟连接来实现，虚拟管理层用来实现对虚拟连接的获取、管理，将虚拟连接和真实连接关联起来，在虚拟连接层中实现messenger的dispatcher的所有处理函数，所有的数据处理都经过vritual_messenger来调用。从而通过节点间的一个进程管理一个节点上的所有osd设备，降低集群的连接数，解决由于连接数过多导致的集群规模受限的问题。

下面对本发明实施例提供的数据通信系统进行介绍，下文描述的数据通信系统与上文描述的数据通信方法可以相互参照。

参见图10，本发明实施例提供的一种分布式存储集群的数据通信系统，所述数据通信系统的每个节点包括：与本节点内所有osd通信连接的虚拟messenger100，以及与虚拟messenger通信连接的真实messenger200；

其中，每个节点的虚拟messenger100，用于将本节点内osd发送的数据发送至本节点的真实messenger；并将本节点的真实messenger发送的数据下发至对应的osd；

每个节点的真实messenger200，用于将本节点虚拟messenger上传的数据发送至目的节点的真实messenger；将源节点的真实messenger发送的数据下发至本节点的虚拟messenger。

基于上述实施例，每个节点的虚拟messenger接收真实messenger发送的数据，通过数据中携带的目标osd的地址信息，调用与所述目标osd对应的处理函数处理所述数据。

基于上述实施例，两个节点的真实messenger之间，通过节点间唯一的tcp连接进行数据的传输。

基于上述实施例，两个节点的虚拟messenger之间，通过建立虚拟连接进行osd基础信息的传输。

本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。

对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本发明。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本发明的精神或范围的情况下，在其它实施例中实现。因此，本发明将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。