基于ceph的动态链式存储集群实现方法
技术领域
本发明属于数据存储技术领域,设计与实现在海量数据的复杂应用场景下,对数据进行链式分级存储。
背景技术
Ceph做为优秀的分布式文件系统,具有很高的可靠性,在保证性能的同时可轻松扩展到数PB容量,完全满足在大数据及云计算的海量存储的需求,现在也成为了开源社区众人皆知的明星项目,特别是随着云计算的发展,Ceph乘上了OpenStack的春风,受到各大厂商的待见,Intel、DreamHost、SanDisk、CISCO、Yahoo等公司都或多或少的参与其中。
在目前,随着数据量的日益剧增,大量数据占据存储空间的同时,部分新的或者常用数据作为热点数据需要经常被访问,业界比较普遍的做法是将这些高频访问的数据放入高性能的存储集群中作为缓冲,其余的数据放入采用廉价设备的普通集群中即所谓的“冷热隔离”,典型的例如:ceph cache tier,在提高访问速度的同时降低企业采用高性能设备所带来的巨额成本。
申请号为CN201410756537.0,公开了一种基于分级存储的分布式文件系统实现方法,包括以以下步骤:1)对系统中的数据采用全局统一命名空间,建立无元数据服务的分布式文件系统;2)将整个分布式文件系统根据业务需要划分为不同的逻辑分区;3)对不同的逻辑分区选用不同的存储介质和存储方式;4)逻辑分区间的数据实现自动迁移,并对迁移后的数据进行数据重定位。与现有技术相比,本发明具有数据访问完全并行化、性能好、硬件成本低等优点。但是大量增加的数据势必带来大量的热点数据,想要保证这些热点数据的快速访问,最直接的方法就是增加缓冲集群的容量,然而这样势必又造成成本的不断增加;我们都清楚,在绝大多数的应用场景中,热点数据随着时间的推移热度是不断递减的,比如:新闻、气象、银行的账单流水,这些数据的热度递减产生的效应,我们称之为数据的价值递减效应,这种递减在采用热点集群也就是冷热隔离的方式并不能体现,采用人工干预的方式耗时耗力且不能动态调整。
业界已经逐渐的意识到了这方面的问题并提出各种分级存储的方案,大体的思路将适用于不同性能、不同存储能力、不同IO能力的存储设备组合分成多级(一般为三级:高性能、常规、低速高容量),但是我们知道存储的发展日新月异,新技术层出不穷,性能不断飙升,业务对性能的需求也是水涨船高;比如,在短短几年时间SSD的4K随机IOPS从几十万已经飙升到了200万之高(群联Phison Element AIC SSD),容量更是从几百G扩大到了8T之多(Intel最近宣布了一种代号“Ruler”的全新形态SSD,号称可以在1U空间内提供1PB(1000TB)的惊人容量),相信这个数字还会在不断地新技术出现的未来不停的刷新,那么带来一个非常直观也现实的问题,当初声称处于分级存储最高级的高性能集群在当下已经远不能胜任其高性能的美誉,对新兴的业务(比如:超算领域)反而成为拖累。
可能随着业务需求的不断调整需要实现集群性能差异均衡化,或者需要扩大整个集群链达到更高容量的存储,这时候不得不考虑在分级集群中加入一个普通的集群,这个想法在当前的分级存储中是相当困难的,可能需要中断所有的运行业务,效果也不可预期,而且这样造成的风险无法估量。
发明内容
针对上述技术问题,本发明提出一种可不断迭代升级的高性能分级存储集群并且支持灵活的动态伸缩的技术,实现分布式存储系统在适应数据价值递减效应下的分级存储。
为达到上述目的,本发明采用的技术方案为:基于ceph的动态链式存储集群实现方法,将不同性能及容量的多个集群链式相连形成分级存储集群,包括头部集群、普通集群,并且可以根据需求动态的在集群链中添加或删除集群,通过集群间的清洗策略保证数据在集群链中合理分布,当满足清洗策略时对集群中数据进行清洗;头部集群实现策略分发,数据映射和高速缓冲。策略分发:集群间清洗策略的配置和分发,监督策略执行情况及动态调整,数据映射:所有业务数据IO都从头部集群经过并由头部集群映射到其他集群,高速缓冲:头部集群对数据进行高速缓冲。
所有业务数据IO都从头部集群经过并有头部集群映射到其他集群,头部集群的高速缓冲是为了应对冷数据(价值低底层级别的数据)在某些特殊需求情况下需要进行访问(比如数据分析领域需要对历史数据进行汇总分析),但是由于数据已经存储在分级存储的下游,集群性能底下,那么加入高速缓冲,可以有效的加快数据的访问速度,同时这种数据访问的需求不会由于清洗机制造成不必要的升迁导致数据在多级集群中反复的往返游走(数据分析结束后低价值数据被再次访问的可能性很小,但是如果由于短期内的高频访问导致这些低价值数据被不断提升到高层集群是对资源的浪费且造成业务的扰动)。
链式集群,单个集群每次的变动只会影响其首尾两个集群,对其他集群几乎无影响,当集群链上的集群越来越多的时候,这样的扰动将会微乎其微。尤其是在对头部、尾部操作时,其影响集群只有头部或尾部集群,这种方式大大的加强了系统的稳定性,保证服务质量;使用Level_{num}的方式标识各个集群,集群本身只需要其上游集群、下游集群和对应的清洗策略。
当加入新的头部集群时,包括如下步骤:
步骤11,新头部集群同步原头部集群的MON Map、OSD Map信息;
步骤12,原头部集群将不在自己集群的数据请求转交给新头部集群处理,逐渐让新头部集群数据升温,各集群链集群的热点数据在新头部集群的命中率将提升,而原头部集群的热点数据将冷却;
步骤13,清洗机制将对原头部集群达到条件的数据移交至新头部集群;
步骤14,新头部集群彻底接管原头部集群的功能;
步骤15,原头部集群退化为二级存储集群,新头部集群加入完成。
为满足业务需求的不断调整,或者需要扩大整个集群链达到更高容量的存储,在分级存储集群中加入中间级集群(普通集群)时,包括如下步骤:
步骤21,头部集群暂时阻止新加入集群Level_?前后集群Level_N-2、Level_N-1的数据清洗;
步骤22,为新加入的集群Level_?配置上游集群及下游集群的清洗策略;
步骤23,配置Level_N-2、Level_N-1集群配置,指定“Level_?”为Level_N-2的下游集群、为Level_N-1的上游集群;
步骤24,重新分发新的清洗策略至Level_N-2及Level_N-1;
步骤25,解除对Level_N-2及Level_N-1数据清洗的阻止,数据清洗重新启动。
分级存储集群中删除中间级集群(普通集群)时,包括如下步骤:
步骤31,头部集群为待删除集群(Level_N-1)配置新的清洗策略该清洗策略停止待删除集群上游的降级及下游的提升机制,加快数据的向上游提升机向下游降级的速度;
步骤32,当待删除集群(Level_N-1)内的数据全部被提升/降级完成后,待删除集群(Level_N-1)通知头部集群自己已经置空;
步骤33,头部集群将待删除的集群(Level_N-1)从集群链中移除,并通知待删除集群(Level_N-1)退役成功;
步骤34,待删除集群(Level_N-1)停止所有业务服务,进入休眠状态;
步骤35,头部集群配置Level_N-2、Level_N集群,指定为Level_N-2的下游集群及Level_N的上游集群;
步骤36,头部集群重新分发新的清洗策略至Level_N-2及Level_N;
步骤37,Level_N-2与Level_N数据清洗重新启动。
头部集群不可以直接删除,如需要删除需要加入新的头部集群,再执行普通集群删除的方法。
本发明公开一种链式存储集群的清洗机制。
1).清洗策略相关概念:
a).阈值
阈值是清洗的依据,根据阈值判断数据是否达到清洗条件,可以根据使用量占比当使用量超过一定的比重后,对长时间低频使用的数据采用末尾淘汰的方式将数据清洗到低级的存储集群当中;
b).清洗率
清洗率是清洗粒度的体现,当达到目标的清洗率后即使有达到目标的清洗阈值,也不在进行清洗,这样可以给运维带来更多操作配置的途径;
c).时机
为了不影响正常业务的进行,可以对数据清洗时的开始时间和持续时间限制,只在规定时间段内做数据清洗。
2).清洗算法
提升算法:
数据是否提升:清洗率*ln(数据大小/上游剩余空间*留置比)+访问频率*(1/近期迁移次数)>1
降级算法:
数据是否降级:清洗率*ln(数据大小/下游剩余空间*留置比)-访问频率*(1/近期迁移次数)<1
其中,上/下游剩余空间:与该集群相邻的上/下游集群剩余的空间;留置比:集群空间预留容量/集群空间容量。
3).清洗机制(流程)
数据清洗只会在集群链相连的两个集群间进行,不相连的集群不会发生直接的数据交换。包括以下步骤:
步骤41,通过头部集群配置清洗策略,策略应用到集群链中的所有集群或直接应用到某个集群对上(集群对:每两个相邻集群组成一个集群对);配置清洗策略可以采用批量导入及命令行形式。
步骤42,头部集群将清洗策略分发给相连的两个集群,接收的集群把接收到的策略部署到集群中,并生效;
步骤43,当不满足我们的数据清洗策略时,等待新的清洗事件触发;当满足清洗策略,后端开始数据清洗,降级的数据向相连的下游集群传递副本,提升的数据向相连的上游集群传递副本;
步骤44,副本传递完成后头部集群接受数据映射重定向;更具体的为:副本接收方向头部集群发送数据映射重定向的请求,头部集群接受重定向请求后,动态调整pg完成重定向,并返回重定向标签(oid);副本接收方接收到标签后会给接收的副本打入标签,并通知副本发送方副本已经接收并重定向完成。
步骤45,发送方处理清洗的最后工作,删除原副本。在这里可以是直接删除副本,也可以是将副本标记为“可删除”状态,等待后台的删除线程执行异步的延时删除。
步骤43中数据清洗中传递副本具体包括:
步骤431,发送方发送副本发送请求,请求包括副本个数、大小;
步骤432,接收方接收副本发送请求,通过后做好副本接收准备;
步骤433,接收方接收副本。
由于集群链中相连集群清洗可能牵涉到大量的数据迁移,那么为了保障服务的可靠,清洗环节引入QoS以保证集群在清洗过程中同样可以正常对外服务。
QoS模式通过对数据清洗的读、写带宽进行限制防止带宽扰动;QoS模式可以配置为均衡、清洗优先、业务优先模式,针对各模式采用不同的线程个数配比(业务线程数、清洗线程数、空间回收线程数)保障集群的可用性;两种方式调整不同的线程个数配比:1.通过配置文件指定线程个数2.通过Master节点分发配置动态调整。
对于清洗的数据我们可以采用不同的删除方式来保障存储节点的性能,我们可以用异步延时的方式删除数据,当然这也会带来一定的数据冗余。(同步、异步)删除:清洗机制里面数据从一个集群流入到另一个集群,原集群保存的数据就需要删除处理了,这种删除会占用系统资源的,尤其是当清洗的数据量较大时,使用同步删除方式集群可能会耗费大量磁盘吞吐在数据删除上,如果此时正是业务高峰期势必会影响正常业务的进行,那么此时可以使用异步删除,在业务不繁忙时删除这些清洗完的数据。
本发明具有以下有益效果:本发明的基于ceph的动态链式存储集群实现方法,可不断迭代升级的高性能分级存储集群并且支持灵活的动态伸缩的技术,实现分布式存储系统在适应数据价值递减效应下的分级存储,方便根据实际业务需求灵活调整存储集群链的大小、长度、性能,从而降低成本,达到规划合理、成本可预期、兼顾性能。
链式集群,单个集群每次的变动只会影响其首尾两个集群,对其他集群几乎无影响,当集群链上的集群越来越多的时候,这样的扰动将会微乎其微。尤其是在对头部、尾部操作时,其影响集群只有头部或尾部集群,这种方式大大的加强了系统的稳定性,保证服务质量。并且数据清洗环节引入QoS保证了集群在清洗过程中同样可以正常对外服务。
附图说明
图1为本发明实施例的动态链式存储集群集群链架构。
图2为本发明实施例的动态链式存储集群头部集群职能图。
图3为本发明实施例的动态链式存储集群集群链示意图。
图4为本发明实施例的动态链式存储集群新头部集群加入的协同与移交。
图5为本发明实施例的动态链式存储集群新头部集群加入的头部集群退化。
图6为本发明实施例的动态链式存储集群普通集群加入示意图。
图7为本发明实施例的动态链式存储集群普通集群删除示意图。
图8为本发明实施例的动态链式存储集群数据清洗策略。
图9为本发明实施例的动态链式存储集群数据清洗流程。
图10为本发明实施例的动态链式存储集群数据副本迁移。
图11为本发明实施例的动态链式存储集群QoS的作用环节。
图12为本发明实施例的动态链式存储集群QoS的保障。
具体实施方式
为了便于本领域技术人员的理解,下面结合实施例与附图对本发明作进一步的说明。
1.集群架构(如图1所示)
a.Master(Level_0)集群是集群链的头部集群实现高速缓存(可配置)、数据映射、策略分发、用户配置;
b.集群链中的集群链式相连,实现真正的数据分级存储;
c.下图1展示了一个可能的集群链,集群链是可以根据具体业务需求动态配置的。
如果集群链只存在Master(Level_0)的链表头部集群,则该架构就是普通的集群,如果包含两级(Level_0、Level_1)则该架构是一个典型的ceph cache tier集群,这种可伸缩性,将会对我们面对未来未知的业务需求带来灵活的调整空间,从而不需要让我们从一开始就去考虑冷热隔离、分级存储,刚开始有个集群链头部集群足矣。
2.Master cluster职能(如图2所示)
a.策略分发:
主要是针对分级的存储集群间清洗策略的配置与分发,监督策略执行情况及动态调整。
b.数据映射:
由于数据清洗会造成数据在两个相邻集群的移动,这时需要Master动态的对ceph的pg进行分裂与归并,使清洗后的数据可以正常被读取;
c.高速缓冲:
为了满足应用场景的多元化,可以将Master集群作为缓冲层,提高对整个集群链数据的访问速度,尤其是在应对阶段性、突发性特点的低级链集群的访问时,缓冲作用更为明显。所有业务数据IO都从Master集群经过并由Master集群映射到其他集群,Master集群的高速缓冲是为了应对冷数据(价值低底层级别的数据)在某些特殊需求情况下需要进行访问(比如数据分析领域需要对历史数据进行汇总分析),但是由于数据已经存储在分级存储的下游,集群性能低下,那么加入高速缓冲,可以有效的加快数据的访问速度,同时这种数据访问的需求不会由于清洗机制造成不必要的升迁导致数据在多级集群中反复的往返游走(数据分析结束后低价值数据被再次访问的可能性很小,但是如果由于短期内的高频访问导致这些低价值数据被不断提升到高层集群是对资源的浪费且造成业务的扰动)。
3.集群链(如图3所示)
分级存储集群采用链式连接,保证存储的可按需动态调整,链式集群有以下几点优势:
1).链式的集群可以灵活的在集群链中添加或删除任意集群,不论是头尾或者中部;
2).数据的清洗只会在集群链相连集群进行,不会对其他集群造成扰动;
3).可以对每个相连集群单独配置清洗策略,配置更加灵活;
4).可以针对相连集群单独配置QoS保证服务质量。
作为一种可能的集群链,头部集群采用NVMe-SSD/NVRAM集群,第一级采用SSD集群,第二级采用混合集群,第三极采用大容量廉价的HDD集群。
4.新Master集群加入(高性能集群的动态升级)
本实施例采用的链式集群,单个集群每次的变动只会影响其首尾两个集群,对其他集群几乎无影响,当集群链上的集群越来越多的时候,这样的扰动将会微乎其微。尤其是在对头尾操作时,其影响集群只有首/尾部集群,这种方式大大的加强了系统的稳定性,保证服务质量;为了表述方便我们会使用Level_{num}的方式标识各个集群,但真实的集群本身并不知道自己处于哪个Level,而只需要知道自己的上游集群、下游集群和对应的清洗策略就可以了。
新Master集群加入包括如图4所示的协同与移交,和如图5所示的头部集群退化:
1).New Master集群同步Master的MON Map、OSD Map信息;
2).Master将不在自己集群的数据请求转交给New Master处理,逐渐让NewMaster数据升温,各集群链集群的热点数据在New Master集群的命中率将提升,而Master集群的热点数据将冷却;
3).清洗机制将对Master集群达到条件的数据移交至New Master集群;
4).New Master集群彻底接管Master集群的功能如图5所示;
5).Master集群退化为二级存储集群,新Master集群加入完成。
5.普通集群加入
可能随着业务需求的不断调整需要实现集群性能差异均衡化,或者需要扩大整个集群链达到更高容量的存储,这时候不得不考虑在分级集群中加入一个普通的集群,这个想法在当前的分级存储中是相当困难的,可能需要中断所有的运行业务,效果也不可预期,而且这样造成的风险无法估量。但是采用链式的集群系统可以很好的解决这个难题。如图6所示,普通集群加入包括以下步骤:
1).Master暂时阻止新加入集群前后集群的数据清洗;
2).为新加入的集群配置上游及下游清洗策略;
3).配置Level_N-2、Level_N-1集群配置,指定为Level_N-2的下游集群及Level_N-1的上游集群;
4).重新分发新的清洗策略至Level_N-2及Level_N-1;
5).解除阻止,数据清洗重新启动。
6.普通集群删除(非Master集群),如图7所示,包括以下步骤:
1).Master为待删除集群(Level_N-1)配置新的清洗策略该清洗策略停止待删除集群上游的降级及下游的提升机制,并把自己标记为“退役中”状态,从而加快数据的向上游提升机向下游降级的速度;
2).当待删除集群(Level_N-1)内的数据全部被提升/降级完成后,待删除集群(Level_N-1)会通知Master集群自己已经置空;
3).Master集群将待删除的集群(Level_N-1)从集群链中移除,并通知待删除集群(Level_N-1)退役成功;
4).待删除集群(Level_N-1)停止所有业务服务,进入休眠状态;
5).Master集群配置Level_N-2、Level_N集群配置,指定为Level_N-2的下游集群及Level_N的上游集群;
6).重新分发新的清洗策略至Level_N-2及Level_N;
7).Level_N-2与Level_N数据清洗重新启动。
本实施例中,Master集群不可以直接删除,如需要删除需要先加入新的Master集群,再执行普通集群删除的方法。
7.链式集群的清洗策略
为了能使数据能够达到分级存储,我们势必要采用某种机制在合适的时机将低价值的数据顺着集群链向下游移动,腾出相对较高性能的集群空间,同时高价值(访问)的数据会沿着集群链不断地向上游迁移,这样的机制我们称之为清洗机制,对这种机制所做的一系列配置统称为清洗策略。
1).如图8所示,清洗策略相关概念包括:
a).阈值
阈值是清洗的依据,根据阈值判断数据是否达到清洗条件,比如我们可以根据使用量占比当使用量超过一定的比重后,对长时间低频使用的数据采用末尾淘汰的方式将数据清洗到低级的存储集群当中;
b).清洗率
清洗率是清洗粒度的体现,当达到目标的清洗率后即使有达到目标的清洗阈值,也不在进行清洗,这样可以给运维带来更多操作配置的途径;
c).时机
为了不影响正常业务的进行,我们可以数据清洗时有开始时间和持续时间限制的,只在规定时间段内做数据清洗。
2).清洗算法
提升算法:
数据是否提升:清洗率*ln(数据大小/上游剩余空间*留置比)+访问频率*(1/近期迁移次数)>1;
降级算法:
数据是否降级:清洗率*ln(数据大小/下游剩余空间*留置比)-访问频率*(1/近期迁移次数)<1。
其中,上/下游剩余空间:与该集群相邻的上/下游集群剩余的空间;留置比:集群空间预留容量/集群空间容量。
9.数据清洗机制(流程)
如图9所示,本实施例对链式集群设计的数据清洗策略的清洗机制,数据清洗只会在集群链相连的两个集群间进行,不相连的集群不会发生直接的数据交换。
a).通过Master集群配置清洗策略,可采用批量导入及命令行形式,策略可以应用到所有的集群中,也可以根据需求配置在某个集群对上;
b).Master集群将清洗策略分发给相连的两个集群上(链端),接收的集群会把接收到的策略部署到集群中,并生效;
c).当不满足我们的数据清洗策略时,我们会等待新的清洗事件触发;
d).如果满足清洗策略,后端开始数据清洗,降级的会向相连的低级集群传递副本,提升的数据则向相连的高级别集群传递副本,这些复制一般是事务性的;数据副本迁移如图10所示。
e).发送方发送副本发送请求,请求包括副本个数、大小;
f).接收方接收副本发送请求,通过后做好副本接收准备;
g).接收方接收副本;
h).副本传递完成后副本接收方将会向Master集群发送数据映射重定向的请求,当Master集群接受重定向请求后,会动态调整pg完成重定向,并返回重定向标签(oid);
i).副本接收方接收到标签后会给接收的副本打入标签,并通知副本发送方副本已经接收并重定向完成;
j).发送方处理清洗的最后工作,在这里清洗可以是直接删除副本,也可以是将副本标记为“可删除”状态,等待后台的删除线程执行异步的延时删除。
10.QoS保障
如图11所示,QoS作用环节为数据清洗过程,由于集群链中相连集群清洗可能牵涉到大量的数据迁移,那么为了保障服务的可靠,在清洗环节引入QoS以保证集群在清洗过程中同样可以正常对外服务。如图12,QoS的保障包括:
a.带宽限制,可以保证集群在正常工作是,不会因为数据清洗而带来大的网络带宽扰动;
b.QoS模式可以配置为均衡、清洗优先、业务优先模式,针对各模式采用不同的线程个数配比(业务线程数、清洗线程数、空间回收线程数)保障集群的可用性(两种方式:1.通过配置文件指定线程个数;2.通过Master节点分发配置动态调整);
对于清洗的数据我们可以采用不同的删除方式来保障存储节点的性能,我们可以用异步延时的方式删除数据,当然这也会带来一定的数据冗余。(同步、异步)删除:清洗机制里面数据从一个集群流入到另一个集群,原集群保存的数据就需要删除处理了,这种删除会占用系统资源的,尤其是当清洗的数据量较大时,使用同步删除方式集群可能会耗费大量磁盘吞吐在数据删除上,如果此时正是业务高峰期势必会影响正常业务的进行,那么此时可以使用异步删除,在业务不繁忙时删除这些清洗完的数据。
以上的实施例仅为说明本发明的技术思想,不能以此限定本发明的保护范围,凡是按照本发明提出的技术思想,在技术方案基础上所做的任何改动,均落入本发明保护范围之内。