本文提出的基于P2P的云存储模型是个双环的结构,如图1所示:

图1

	Figure Option ViewDownloadNew Window
	图1 基于P2P的云存储模型

将提供云存储服务的数据中心的服务器分成两部分,性能高、处理能力强的服务器组成内环的服务管理网络提供元数据等信息的存储和管理,采用DHT网络对内环的服务管理节点进行组织;普通的性能一般的服务器组成外环的数据存储网络来完成对用户数据的实际存储。外环的每一个数据块服务器(Chunk Server)将被指定一个内环的服务管理节点对其进行管理,一个服务管理节点将管理本区域内的所有数据块服务器,形成存储簇(Storage Cluster),完成对用户数据的实际存储。模型涉及4种角色:客户端、网关、服务节点和数据块服务器,主要功能如下:

(1)客户端(Client App):这里的Client App是指使用云存储服务的主体,根据自己的需求向云存储系统发出数据存储或是检索的请求。

(2)网关(G):所有来自Client App的请求首先到达网关,网关和服务管理节点一起由DHT网络进行管理,网关使用DHT算法计算出应该处理文件元数据所在的服务管理节点,然后根据其路由表转发请求。由于网关本身是无状态的,只是用来管理会话和转发请求,因此不会成为系统的瓶颈,即使出现宕机的情况,也不会丢失任何数据,可以迅速得到恢复。

(3)服务管理节点(M):服务管理节点需要管理本区域内的所有数据块服务器,监测它们的运行情况,处理Client App发出的请求信息,并需要对相邻服务节点的元数据进行备份。

(4)数据块服务器(S):数据块服务器完成实际的数据存储,接受本区域服务管理节点的管理。

在本模型的设计中,服务管理节点之间采用Chord算法组成一个逻辑的环状覆盖网络(Overlay Network),通过这种分布式的存储方式,每个节点只需要负责小范围的路由,并管理一部分的数据块服务器,从而完成对网络的寻址和存储。服务管理节点采用分层结构(见图1),包括文件定位层、路由层和元数据存储层;各层需要实现的主要接口如表1所示:

表1

表1

表1 服务管理节点各层需要实现的主要接口 层名称 接口名称 实现的功能 文件定位层 Map(v) 映射一个值v到某一个服务管理节点 路由层 lookup(v) join() leave() 根据给定值v,路由请求到负责处理的节点 新的服务管理节点加入 某个服务管理节点离开 元数据存储层 getNodeList() /getNodeList(v) 返回负责存储或检索的数据块服务器列表

表1 服务管理节点各层需要实现的主要接口

文件定位层和路由层实际上构成一个DHT网络,应用Chord算法对用户的请求进行分发和路由,通过DHT网络,请求能够被均匀地分发到各个节点,使系统具有良好的负载均衡。节点间采用DHT网络连接,当有新的节点加入时,节点需要执行Chord算法的加入协议,将一些其他节点加入到它的路由表中,并且需要将它的加入通知其他节点。某个节点的离开也类似此过程。总之,服务管理节点网络的构建类似于一个P2P网络的构建。元数据存储层存储与本节点有关的文件元数据信息,比如文件大小、文件ID、文件块对应的数据块服务器信息、版本号等。通过对元数据存储模块进行查询,存储系统能够快速、准确、完整地定位需求的文件。这样就实现了索引同存储相分离,同时避免了中心节点的瓶颈现象,提高了系统的性能。

将云存储系统分成多个存储簇,每个存储簇由一个服务管理节点和多个数据块服务器组成,完成对数据的实际存储和管理。服务管理节点对集群内部的数据块服务器进行管理,监控块服务器的运行,为要存储的数据提供存储的位置、文件块和数据块服务器的映射信息等元数据信息。存储簇对文件的存储采用分块的方式,数据块服务器与Client App交互,完成对数据块的存储和数据的更新。

数据块服务器需要向服务管理节点发送心跳包来报告自己的状态信息,如果数据块服务器出现故障,服务管理节点需要及时获悉这一情况,并采取相应的措施来恢复失效节点的数据,从而维持整个系统的稳定,避免数据的丢失。此外,服务管理节点需要对所管理的数据块服务器的使用和运行情况信息进行统计,包括CPU性能、内存、带宽和硬盘剩余等。服务管理节点通过这些信息可以获得各数据块服务器的运行情况,当向Client App返回用于数据存储和检索的数据块服务器列表时,能够根据各数据块服务器的运行情况对其进行评定,使得Client App能够选择运行情况相对良好的数据块服务器来处理相关的请求,从而提高系统的整体性能。

GFS和HDFS都通过数据分块和复制来提供更高的可靠性和更好的性能,能够满足对大文件的存储需求。为了提高数据在系统中的安全性,本文提出的云存储模型采用信息扩散法(Information Dispersal Algorithms, IDA)来对数据进行分块。

信息扩散法^{[ 11]}是指将一个长为L=|F|的文件F分成n片,每片的长度为|F_i|=L/m,1≤i≤n,使得从n个分块中任意取出m块就可以重构文件F,且分块文件的长度总和为(m/n)×L。算法的具体步骤^{[ 12]}如下:

(1)设文件F由字符串组成,F=b₁,b₂,…,b_N,其中字符b_i∈[0,…,B]且b∈Z(B=2^l-1,l为一个字节拥有的位数);取最小的大于B的素数p作为该文件中字符运算的模,该字符串中所有元素上限为Z^p。

(2)选择一个合适的整数m,令n=m+k,其中m/n<1+ε,ε>0。

(3)选择n个向量a_i=(a_i1,a_i2,…,a_in)∈ ,1≤i≤n,使n个向量中任意不同的m个向量非线性相关。随机从(a₁,a₂,…,a_n)中抽取m个向量,这m个向量是非线性的可能性非常大。

(4)利用选择的向量组对F进行拆分,把文件F分成长度为m的序列,则:

F=(b₁,b₂,…,b_m),(b_m+1,b_m+2,…,b_2m),…

令s₁=(b₁,b₂,…,b_m),s₂=(b_m+1,b_m+2,…,b_2m),…,

则F_i=c_i1,c_i2,…,c_iN/m,其中i=1,2,…,n且c_ik=a_i·s_k= a_i1·b_(k-1)m+1+…+a_im·b_km

|F_i|=|F|/m

(5)利用选择的向量组对矩阵F进行重组。

如果文件F的m个分块F₁,F₂,…,F_m已经给出,那么可以依照以下步骤重建文件F。

让A=(a_ij),1≤i,j≤m是一个m×m矩阵,其中第i行为a_i,可以看出:

A·[b₁,…,b_m]^T=[c₁₁,…,c_m1]^T,则[b₁,…,b_m]^T= A^-1·[c₁₁,…,c_m1]^T,其中,b_j=a_i1c_ik+…+a_imc_mk,1≤j≤N

通过此算法对数据文件进行分块,数据不会被非法识别,极大地增强了云存储中数据的安全性和保密性,数据的分块存储也提高了系统的可用性和云存储系统的容错、容灾的能力。服务管理节点按照此算法对数据文件进行分块,对每个分块数据用一个128位的句柄进行表示,并且为每个数据块设置一个版本号,用于数据块副本间的一致性管理,文件元数据副本之间形成一个链表。服务管理节点上的数据块存储结构,如图2所示:

图2

	Figure Option ViewDownloadNew Window
	图2 文件元数据存储结构

在本文提出的云存储模型中,由于提供数据存储的服务器可以是普通的PC,节点失效应该被视为一种常态,为了保证数据的可靠性和可用性,需要对数据进行多点备份,多点备份能够提高云存储系统的性能和可靠性,因此副本管理是云存储的一个非常重要的问题。在本模型的设计中,涉及到两类数据的副本存储:用户存储的数据本身,以分块的形式存储在Chunk Server中;在服务管理节点上存储的文件元数据信息。当Chunk Server 或是服务管理节点失效时,要确保不会影响系统的正常运行,并且需要有一种策略来恢复失效节点上的数据,从而保证相关数据的副本总是保持在一定的水平。

对于用户存储的数据,数据副本的存储位置由服务管理节点来分配与管理,当存储数据副本的某个数据块服务器失效时,服务节点管理能够及时地知道这一情况并重新选择一个数据块服务器来恢复失效节点的数据,确保系统中的数据副本总能保持在一定的水平。

每个服务管理节点维护一个副本列表和一个后继节点列表,对于服务管理节点存储的文件元数据信息,通过查询后继节点列表(Successor-list),在紧邻的两个后继节点上分别存放一份元数据副本。例如,如果副本数量是3,当文件元数据发生改变后,就要将相关的元数据保存到此节点的前两个后继节点,如图3所示:

图3

	Figure Option ViewDownloadNew Window
	图3 服务管理节点元数据副本管理

图3中,节点M₁的数据副本保存在它的后继节点M₂和M₃。当M₁发现副本列表中某个节点失效时,便从后继列表中选择下一个后继节点加入列表,并将相关的元数据副本复制到这个后继节点上,以维护系统中副本数量不变,同时原来由失效节点管理的数据块服务器由失效节点的后继节点管理,避免了数据块服务器的丢失,不会对系统的性能产生较大的影响。通过应用这样的策略,保证即使某个服务管理节点失效,它所存储的元数据信息也能在相应的后继节点上找到,不会影响系统的运行。例如当M₃失效时,M₁会及时地发现这一状况,选择后继节点M₄作为新的副本节点,将自己的数据副本保存在M₄。同时,M₄需要选择M₆作为失效节点M₃的副本节点。这样,M₁和M₃的副本数量都不会降低。原来由失效节点M₃处理的请求由M₄来处理,M₄也将管理M₃管理的数据块服务器。而这一切对Client App来说是透明的,不会对用户产生任何不利的影响,从而维护了系统的稳定。

由于云存储系统为多个用户提供服务,多个用户可能会同时访问同一数据的多个副本,当用户对数据进行更新的时候,就面临着如何保证数据副本一致性的问题,因此云存储系统需要提供一种策略来保证系统中数据副本的一致性。在本文提出的云存储模型中,采用如下的策略来确保副本的一致性。

(1)Client App 向系统发出要对某一数据文件进行更新的请求。

(2)请求到达相应的服务管理节点后,服务节点检查相关的文件元数据副本链表的状态,元数据副本链表的状态有锁定和未锁定两种状态。如果未锁定,说明没有其他的更新请求正在被处理。就将相关的文件元数据锁定,阻塞其他更新请求。

①服务管理节点向存储其副本的相关后继节点发出锁定的命令,将副本锁定。

②服务管理节点向Client App返回相应的文件元数据信息,Client App利用这些元数据来完成数据的更新。

③系统对副本采取异步更新的模式,即Client App先对文件的某一副本进行更新,其余副本的更新由已完成更新的副本来完成,如图4所示:

图4

	Figure Option ViewDownloadNew Window
	图4 数据副本更新过程

一个文件块及其副本分别存储在N₁、N₂、N₃ 三个节点上,当Client App对N₁进行更新完成后,由N₁对N₂进行更新,同样的方式,由N₂对N₃进行更新。当某个数据块服务器完成更新后,需要向服务管理节点发出更新完成的消息,并增加相应副本的版本号。

④当文件的所有数据副本完成更新后,它们的版本号是同样的并且是最新的,此时将文件解锁,其他更新请求就可以得到处理,文件也可以被Client App读取,从而保证了副本的一致性。如果某一个数据块服务器出现故障,未能完成数据的更新,则副本链表的版本号会出现不一致的情况,服务管理节点会周期性地检查这一情况,并将相关的副本更新到最新状态。

(3)如果在步骤(2)中,相关的文件元数据已被锁定,服务管理节点就将这个更新请求放入一个请求队列中,等待当前更新请求的完成。

此模型的数据存储过程如下:

(1)客户端向网关发出存储数据的请求,网关根据用户要存储文件的文件名等信息用Hash算法计算相应的Key值,并根据路由表转发此请求到相应的服务处理节点。

(2)相应的服务管理节点接收到请求后,为此请求分配适当的数据块服务器,并将数据块服务器的地址列表返回到客户端。

(3)客户端接收到从服务处理节点返回的数据块服务器地址列表后,分别与各数据块服务器建立连接,传输数据。

(4)当数据块服务器与客户端完成数据传输后,需要向相应的服务管理节点报告,并在其他节点完成数据备份,对于数据的备份情况,也要存储在服务管理节点。在服务节点知道数据完成存储(包括备份数据)时,服务管理节点从其后继节点列表中选择紧邻的两个服务节点,将此次存储的相关元数据信息存储到这两个节点,从而完成元数据信息的备份。