CN108628765B - 开源分布式存储软件Ceph中Cache实现方法和装置 - Google Patents

Abstract

本申请提供了开源分布式存储软件Ceph中Cache实现方法和装置。本申请中，通过依据Cache模式在所述Cache分区中创建Cache，能够在OSD实现Cache；进一步地，本申请中，基于Cache中读写流程的优异特性，则本申请通过在OSD实现Cache，能够提高读写效率；更进一步地，本申请中，无论Cache模式是否支持脏数据，都可在OSD实现Cache，而非人为实现，可以提高部署效率，也可简化维护。

Description

开源分布式存储软件Ceph中Cache实现方法和装置

技术领域

本申请涉及存储技术，特别涉及开源分布式存储软件(Ceph)中高速缓存存储器(Cache)实现方法和装置。

背景技术

Ceph，作为分布式文件***，其能够在维护可移植操作***接口(POSIX：PortableOperating System Interface of UNIX)兼容性的同时，也增加复制和容错功能。

Ceph，作为Linux的文件***备选之一，已经集成在主线Linux内核中，后续可用于解决海量存储的需求。

目前，Ceph应用的存储架构(简称Ceph存储架构)中，并不存在Cache。

发明内容

本申请提供了开源分布式存储软件(Ceph)中Cache实现方法和装置，以在Ceph存储架构中实现Cache。

本申请提供的技术方案包括：

一种开源分布式存储软件Ceph中高速缓存存储器Cache实现方法，该方法应用于存储数据节点OSD，在本OSD被激活时，该方法包括：

获取本OSD中已生成的Cache分区的Cache模式；

若依据所述Cache模式确定在所述Cache分区中创建Cache，则在所述Cache分区中创建Cache，并依据本OSD中已生成的数据Data分区所写入的数据信息的文件类型将所述数据信息写入所述Cache；

将所述Cache中写入的数据信息挂载至本OSD对应的OSD ID目录，依据所述OSD ID目录启动OSD进程。

一种开源分布式存储软件Ceph中高速缓存存储器Cache实现装置，该装置应用于存储数据节点OSD，包括：

获取单元，用于获取所述OSD中已生成的Cache分区的Cache模式；

确定单元，依据所述Cache模式确定是否在所述Cache分区中创建Cache；

Cache单元，用于在所述确定单元依据所述Cache模式确定在所述Cache分区中创建Cache时，在所述Cache分区中创建Cache，并依据本OSD中已生成的数据Data分区所写入的数据信息的文件类型将所述数据信息写入所述Cache；

处理单元，用于将所述Cache中写入的数据信息挂载至本OSD对应的OSD ID目录，依据所述OSD ID目录启动OSD进程。

由以上技术方案可以看出，本申请中，通过依据Cache模式在所述Cache分区中创建Cache，能够在OSD实现Cache；

进一步地，本申请中，基于Cache中读写流程的优异特性，则本申请通过在OSD实现Cache，能够提高读写效率；

更进一步地，本申请中，无论Cache模式是否支持脏数据，都可在OSD实现Cache，而非人为实现，可以提高部署效率，也可简化维护。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理。

图1为OSD的Prepare阶段流程图；

图2为OSD的业务逻辑结构图；

图3为OSD的Activate阶段流程图；

图4为本申请提供的Ceph中Cache实现的示范性实施例流程图；

图5为本申请提供的在Cache分区中创建Cache的示范性实施例流程图；

图6为本申请提供的OSD的业务逻辑结构图；

图7为本申请提供的OSD的Prepare阶段流程图；

图8为本申请提供的装置结构示意图。

具体实施方式

在描述本申请提供的方法之前，先对现有Ceph存储架构中OSD的业务逻辑进行描述：

Ceph存储架构中OSD的业务逻辑主要分两个阶段：部署(Prepare)阶段、启动(Activate)阶段。

在Prepare阶段，如图1所示，主要包括以下操作：

步骤101，获取日志(Journal)分区大小。

在应用中，会针对OSD配置一个文件(称为OSD配置文件)。OSD配置文件存储在指定目录下。作为一个实施例，这里的指定目录可为Ceph目录的子目录比如Ceph.cof目录下。

在一个例子中，OSD配置文件会记录Journal分区大小。这里OSD配置文件记录的Journal分区大小是依据业务需求配置的，比如可为10G、20G、30G等，本申请并不具体限定。

基于此，步骤101中，获取Journal分区大小可为：从OSD配置文件中读取Journal分区大小。

步骤102，依据获取的Journal分区大小在OSD生成Journal分区。

步骤103，为Journal分区设置对应的Journal通用唯一识别码(UUID：UniversallyUnique Identifier)，并生成Journal分区的链接。

在一个例子中，Journal UUID可按照预设的用于计算UUID的算法确定。不同OSD中Journal分区对应的Journal UUID不同。

在一个例子中，Journal分区的链接主要是便于快捷访问Journal分区。本申请应用于Linux***，Linux***中的链接有点类似于Windo ws的快捷方式。Linux***中的链接有两种：一种是硬链接；另一种是符号链接(又称软链接)。作为一个实施例，本步骤103生成的Journal分区的链接可为软链接。

步骤104，在OSD生成数据(Data)分区。

作为一个实施例，本步骤104可包括：将OSD中除Journal分区之外的区域作为Data分区。

图2具体示出了OSD中的Journal分区、Data分区。

步骤105，为Data分区设置对应的Data UUID，并生成Data分区的链接。

在一个例子中，Data UUID可按照预设的用于计算UUID的算法确定。不同OSD中Data分区对应的Data UUID不同。

在一个例子中，Data分区的链接主要是便于快捷访问Data分区。作为一个实施例，本步骤105生成的Data分区的链接与Journal分区的链接类似，也可为软链接。

步骤106，格式化Data分区，在Data分区写入OSD相关数据信息。

在一个例子中，OSD相关数据信息可包括：OSD中Journal分区对应的JournalUUID、OSD对应的OSD UUID、OSD所在的集群对应的集群UUID等。

当将数据信息写入Data分区后，可将数据信息的文件类型记录至OSD配置文件。

上简要描述了Prepare阶段的流程。

需要说明的是，在Prepare阶段，除了上述步骤101至步骤106之外，还会包括其他很多步骤，这里只是以步骤101至步骤106为例描述，并不表示涵盖整个Prepare阶段。

在Activate阶段，如图3所示，可包括以下步骤：

步骤301，获取Data分区所写入的数据信息的文件类型。

如上描述，当将数据信息写入Data分区后，可将数据信息的文件类型记录至OSD配置文件。基于此，本步骤301中，获取Data分区所写入的数据信息的文件类型可包括：从OSD配置文件中读取Data分区所写入的数据信息的文件类型。这里的文件类型可包括：日志型文件***(XFS)。

步骤302，依据获取的文件类型将Data分区所写入的数据信息挂载至已创建的Data分区临时目录。

步骤303，检查Data分区临时目录挂载的数据信息是否包括OSD通过认证的信息，若否，执行步骤304，若是，执行步骤305。

步骤304，申请本OSD对应的OSD标识(ID)和密钥(Key)，在所述Key通过认证设备认证时，则执行步骤305。

在一个例子中，这里，OSD是向Ceph存储架构中设有的监控器(Monitor)申请对应的OSD ID和Key，当Monitor接收到申请时，负责为OSD分配对应的Key和OSD ID。

作为一个实施例，当OSD申请本OSD对应的OSD ID和Key后，OSD就基于申请的OSDID和Key向认证设备发起认证，当OSD申请的Key通过认证设备的认证时，则可将OSD通过认证的信息记录至Data分区，之后执行步骤304。在一个例子中，这里的认证设备也可为上述的Monitor。

步骤305，取消Data分区临时目录与Data分区所写入的数据信息之间的挂载关系，将Data分区所写入的数据信息挂载至本OSD对应的OSD ID目录。

这里，之所以取消挂载关系，目的是为了防止无效的数据信息干扰目录的管理。

步骤306，依据OSD ID目录启动OSD进程。

至此，OSD进程才开始启动。

以上简要描述了Activate阶段的流程。

需要说明的是，在Activate阶段，除了上述步骤301至步骤306之外，还会包括其他很多步骤，这里只是以步骤301至步骤306为例描述，并不表示涵盖整个Activate阶段。

从图2所示流程描述的OSD的Prepare阶段和图3所示流程描述的OSD的Activate阶段可以看出，OSD并未部署Cache，这也意味着Ceph存储架构中未实现Cache。

而如果在Ceph存储架构中实现Cache，常常需要手动在OSD部署Cache比较复杂，而且不太容易维护。

为了在Ceph存储架构中自动部署实现Cache，本申请提供了如图4所示的流程：

参见图4，图4为本申请提供的Ceph中Cache实现的示范性实施例流程图。该方法应用于OSD，在OSD被激活时，如图4所示，该方法包括以下步骤：

步骤401，获取本OSD中已生成的Cache分区的Cache模式。

这里，本OSD中已生成的Cache分区下文描述，这里暂不描述。

步骤402，若依据所述Cache模式确定在Cache分区中创建Cache，则在所述Cache分区中创建Cache，并依据本OSD中已生成的数据Data分区所写入的数据信息的文件类型将所述数据信息写入Cache。

在一个例子中，步骤402中依据Cache模式确定在Cache分区中创建Cache可包括：判断所述Cache模式是否为用于指示支持脏数据的第一指定Cache模式，如果是，确定在所述Cache分区中创建Cache。

这里的第一指定Cache模式可支持加载、创建功能，作为一个实施例，第一指定Cache模式可为Cache机制中的回写(Write-back)模式。

基于Cache模式为第一指定Cache模式比如Write-back模式，则步骤402中，在Cache分区中创建Cache可包括：通过加载Cache分区创建Cache。

在另一个例子中，步骤402中依据Cache模式确定在Cache分区中创建Cache可包括：判断所述Cache模式是否为用于指示不支持脏数据的第二指定Cache模式；若是，确定在所述Cache分区中创建Cache。

这里的第二指定Cache模式不支持加载功能，作为一个实施例，第二指定Cache模式可为Cache机制中的直写(Write-through)模式、或者为数据绕过固态硬盘(SSD)直接写到普通硬盘(Write-around)模式等。

基于Cache模式为第二指定Cache模式比如Write-through模式或Write-around模式等，步骤402中，在Cache分区中创建Cache可包括图5所示流程：

如图5所示，该流程可包括：

步骤501，依据所述Data分区所写入的数据信息的文件类型将所述数据信息挂载至已创建的Data分区临时目录。

如上描述，当将数据信息写入Data分区后，可将数据信息的文件类型记录至OSD配置文件。基于此，本步骤501中，获取Data分区所写入的数据信息的文件类型可包括：从OSD配置文件中读取Data分区所写入的数据信息的文件类型。这里的文件类型可包括：日志型文件***(XFS)。

步骤502，检查所述Data分区临时目录挂载的数据信息是否包括本OSD通过认证的信息；若是，执行步骤503，若否，执行步骤504。

步骤503，在Cache分区中创建Cache。

步骤504，申请本OSD对应的OSD ID和Key，在所述Key通过认证设备认证时，在Cache分区中创建Cache。

这里，OSD是向Ceph存储架构中设有的监控器(Monitor)申请对应的OSD ID和Key，当Monitor接收到申请时，负责为OSD分配对应的Key和OSD ID。

作为一个实施例，当OSD申请本OSD对应的OSD ID和Key后，OSD就基于申请的OSDID和Key向认证设备发起认证，当OSD申请的Key通过认证设备的认证时，则可将OSD通过认证的信息记录至Data分区。在一个例子中，这里的认证设备也可为上述的Monitor。

至此，通过图5所示流程实现在Cache分区中创建Cache。基于图5所示流程，则步骤402中，依据本OSD中已生成的Data分区所写入的数据信息的文件类型将所述数据信息写入所述Cache包括：取消Data分区临时目录与Data分区所写入的数据信息之间的挂载关系，依据本OSD中已生成的数据Data分区所写入的数据信息的文件类型将所述数据信息写入所述Cache。

需要说明的是，在执行本步骤402时，OSD中也有可能并没有生成Cache分区，或者OSD中Cache分区的模式为默认值比如空或者指定值，此时可按照上述图3所示流程执行，这里不再赘述，

步骤403，将Cache中写入的数据信息挂载至本OSD对应的OSD ID目录，依据所述OSD ID目录启动OSD进程。

在一个例子中，在将Cache中写入的数据信息挂载至OSD ID目录之前，可取消Data分区临时目录与Cache中写入的数据信息之间的挂载关系，以使Cache中数据信息不再挂载至Data分区临时目录，防止无效的数据信息干扰目录的管理。

至此，完成图4所示流程。

通过图4所示流程能够在OSD实现Cache。基于Cache中读写流程的优异特性，则本申请通过在OSD实现Cache，能够提高读写效率；

进一步地，本申请中，无论Cache模式是否支持脏数据，都可在OSD实现Cache，而非人为实现，可以提高部署效率，也可简化维护。

在一个例子中，图4所示流程是基于以下OSD的Prepare阶段实现。这里，OSD的Prepare阶段相比图3所示Prepare阶段的改进主要包括：在OSD中增加了Cache分区的实现。相比于现有OSD的业务逻辑结构，本申请提供的OSD的业务逻辑结构中增加了Cache分区。图6示出了本申请提供的OSD的业务逻辑结构。

基于上面描述的改进，下面通过图7所示流程描述本申请提供的OSD的Prepare阶段：

如图7所示，主要包括以下操作：

步骤701，获取Journal分区大小、Cache分区大小。

在应用中，会针对OSD配置一个OSD配置文件。OSD配置文件存储在指定目录下。作为一个实施例，这里的指定目录可为Ceph目录的子目录比如Ceph.cof目录下。

在一个例子中，OSD配置文件会记录Journal分区大小、Cache分区大小。基于此，步骤701中，获取Journal分区大小、Cache分区大小可包括：从OSD配置文件中读取Journal分区大小、Cache分区大小。

步骤702，依据获取的Journal分区大小在OSD生成Journal分区，依据获取的Cache分区大小在OSD生成Cache分区。

步骤703，为Journal分区设置Journal UUID，并生成Journal分区的链接，为Cache分区设置Cache UUID和Cache模式，并生成Cache分区的链接。

在一个例子中，可将为Cache分区设置的Cache UUID、Cache模式记录在OSD配置文件中。

步骤704，在OSD生成Data分区。

作为一个实施例，本步骤704可包括：将OSD中除Journal分区、Cache分区之外的区域作为Data分区。至此，一个OSD至少包括Journal分区、Cache分区、Data分区，具体如图6所示。

步骤705，为Data分区设置对应的Data UUID，并生成Data分区的链接。

步骤706，格式化Data分区，在Data分区写入OSD相关数据信息。

在一个例子中，OSD相关数据信息可包括：OSD中Journal分区对应的JournalUUID、OSD对应的OSD UUID、OSD所在的集群对应的集群UUID、Cache UUID、Cache模式等。

当将数据信息写入Data分区后，可将数据信息的文件类型记录至OSD配置文件。

上简要描述了本申请提供的OSD的Prepare阶段的流程。

需要说明的是，在Prepare阶段，除了上述步骤701至步骤706之外，还会包括其他很多步骤，这里只是以步骤701至步骤706为例描述，并不表示涵盖整个Prepare阶段。

需要说明的是，本申请中，OSD中生成的Cache分区并非固定不变，其可根据业务需求发生更改。

当OSD中已生成的Cache分区发生更改时，可进一步执行以下步骤：

将Data分区写入的、且挂载在所述OSD ID目录的数据信息中的第一Cache UUID修改为更改后的Cache分区对应的第二Cache UUID；所述第一Cache UUID与更改前的Cache分区对应；返回图4所示流程。

以上对本申请提供的方法进行了描述。下面对本申请提供的装置进行描述：

参见图8，图8为本申请提供的装置示范性实施例结构图。该装置应用于OSD，包括：

获取单元，用于获取所述OSD中已生成的Cache分区的Cache模式；

确定单元，依据所述Cache模式确定是否在所述Cache分区中创建Cache；

Cache单元，用于在所述确定单元依据所述Cache模式确定在所述Cache分区中创建Cache时，在所述Cache分区中创建Cache，并依据本OSD中已生成的数据Data分区所写入的数据信息的文件类型将所述数据信息写入所述Cache；

处理单元，用于将所述Cache中写入的数据信息挂载至本OSD对应的OSD ID目录，依据所述OSD ID目录启动OSD进程。

在一个例子中，所述Cache单元依据Cache模式确定在所述Cache分区中创建Cache包括：判断所述Cache模式是否为用于指示支持脏数据的第一指定Cache模式；如果是，确定在所述Cache分区中创建Cache；

基于此，所述Cache单元在Cache分区中创建Cache包括：通过加载所述Cache分区创建Cache。

在另一个例子中，所述Cache单元依据所述Cache模式确定在所述Cache分区中创建Cache包括：判断所述Cache模式是否为用于指示不支持脏数据的第二指定Cache模式；若是，确定在所述Cache分区中创建Cache；

基于此，所述在Cache分区中创建Cache包括：依据所述Data分区所写入的数据信息的文件类型将所述数据信息挂载至已创建的Data分区临时目录；检查所述Data分区临时目录挂载的数据信息是否包括本OSD通过认证的信息；若是，在Cache分区中创建Cache；若否，申请本OSD对应的OSD标识ID和密钥Key，在所述Key通过认证设备认证时，在Cache分区中创建Cache。

作为一个实施例，所述处理单元进一步在所述OSD中已生成的Cache分区发生更改时，将所述Data分区写入的、且挂载在所述OSD ID目录的数据信息中的第一Cache UUID修改为更改后的Cache分区对应的第二Cache UUID；所述第一Cache UUID与更改前的Cache分区对应，并触发所述获取单元执行的操作。

至此，完成图8所示装置的结构描述。

以上所述仅为本申请的较佳实施例而已，并不用以限制本申请，凡在本申请的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本申请保护的范围之内。

Claims (10)

1.一种开源分布式存储软件Ceph中高速缓存存储器Cache实现方法，其特征在于，该方法应用于存储数据节点OSD，在本OSD被激活时，该方法包括：

获取本OSD中已生成的Cache分区的Cache模式；

若依据所述Cache模式确定在所述Cache分区中创建Cache，则在所述Cache分区中创建Cache，并依据本OSD中已生成的数据Data分区所写入的数据信息的文件类型将所述数据信息写入所述Cache；

将所述Cache中写入的数据信息挂载至本OSD对应的OSD ID目录，依据所述OSD ID目录启动OSD进程。

2.根据权利要求1所述的方法，其特征在于，所述依据Cache模式确定在所述Cache分区中创建Cache包括：

判断所述Cache模式是否为用于指示支持脏数据的第一指定Cache模式；

如果是，确定在所述Cache分区中创建Cache。

3.根据权利要求2所述的方法，其特征在于，所述在Cache分区中创建Cache包括：

通过加载所述Cache分区创建Cache。

4.根据权利要求1所述的方法，其特征在于，所述依据所述Cache模式确定在所述Cache分区中创建Cache包括：

判断所述Cache模式是否为用于指示不支持脏数据的第二指定Cache模式；

若是，确定在所述Cache分区中创建Cache。

5.根据权利要求4所述的方法，其特征在于，所述在Cache分区中创建Cache包括：

依据所述Data分区所写入的数据信息的文件类型将所述数据信息挂载至已创建的Data分区临时目录；

检查所述Data分区临时目录挂载的数据信息是否包括本OSD通过认证的信息；若是，在Cache分区中创建Cache；若否，申请本OSD对应的OSD标识ID和密钥Key，在所述Key通过认证设备认证时，在Cache分区中创建Cache。

6.根据权利要求1所述的方法，其特征在于，当本OSD中已生成的Cache分区发生更改时，该方法进一步包括：

将所述Data分区写入的、且挂载在所述OSD ID目录的数据信息中的第一Cache通用唯一识别码UUID修改为更改后的Cache分区对应的第二Cache UUID；所述第一Cache UUID与更改前的Cache分区对应；

返回激活所述OSD的操作。

7.一种开源分布式存储软件Ceph中高速缓存存储器Cache实现装置，其特征在于，该装置应用于存储数据节点OSD，包括：

获取单元，用于获取所述OSD中已生成的Cache分区的Cache模式；

确定单元，依据所述Cache模式确定是否在所述Cache分区中创建Cache；

Cache单元，用于在所述确定单元依据所述Cache模式确定在所述Cache分区中创建Cache时，在所述Cache分区中创建Cache，并依据本OSD中已生成的数据Data分区所写入的数据信息的文件类型将所述数据信息写入所述Cache；

处理单元，用于将所述Cache中写入的数据信息挂载至本OSD对应的OSD ID目录，依据所述OSD ID目录启动OSD进程。

8.根据权利要求7所述的装置，其特征在于，所述Cache单元依据Cache模式确定在所述Cache分区中创建Cache包括：判断所述Cache模式是否为用于指示支持脏数据的第一指定Cache模式；如果是，确定在所述Cache分区中创建Cache；

所述Cache单元在Cache分区中创建Cache包括：通过加载所述Cache分区创建Cache。

9.根据权利要求8所述的装置，其特征在于，所述Cache单元依据所述Cache模式确定在所述Cache分区中创建Cache包括：判断所述Cache模式是否为用于指示不支持脏数据的第二指定Cache模式；若是，确定在所述Cache分区中创建Cache；

所述在Cache分区中创建Cache包括：依据所述Data分区所写入的数据信息的文件类型将所述数据信息挂载至已创建的Data分区临时目录；检查所述Data分区临时目录挂载的数据信息是否包括本OSD通过认证的信息；若是，在Cache分区中创建Cache；若否，申请本OSD对应的OSD标识ID和密钥Key，在所述Key通过认证设备认证时，在Cache分区中创建Cache。

10.根据权利要求7所述的装置，其特征在于，所述处理单元进一步在所述OSD中已生成的Cache分区发生更改时，将所述Data分区写入的、且挂载在所述OSD ID目录的数据信息中的第一Cache通用唯一识别码UUID修改为更改后的Cache分区对应的第二Cache UUID；所述第一Cache UUID与更改前的Cache分区对应，并触发所述获取单元执行的操作。

Images