我认为需要理清这些关键技术,最好的方式是理解这些关键技术因何而生的,是为了解决什么问题。换句话说,如果要你自己手动实现一个分布式存储系统会如何设计。这里我们暂且不关心是什么块存储、对象存储还是文件存储。我们从设计一个分布式存储系统开始,逐步介绍涉及的关键技术。

首先想一个问题,为什么需要分布式存储,其中最主要的原因之一就是解决数据在单机硬盘存不下的问题。如果不用分布式存储你会怎么办?使用工具把文件分割成一个个小文件,存到其他机器即可,并做好记录,下次读的时候再查看记录按顺序或者指定读取第几个小文件把内容合并,这其实就实现了手工式的分布式存储:)。另一个原因就是解决数据单机处理不了的问题,比如就统计下文件中单词出现次数,数据太大,内存有限,算不了,怎么办?把数据分成一个个小文件,拷到其他机器,每个机器只处理每一个小文件,最终合并结果即可,这其实就是手工式的mapreduce,同样需要分布式存储。

分布式存储系统,通俗地讲就是要把文件存储到多个机器中。那么需要解决的第一个问题便是这些文件如何知道该保存到哪台服务器中。这里有两个思路,其中一个是设计一个控制服务器,由这个控制服务器负责统一调度,客户端请求存储一个文件时,首先与控制服务器交互,控制服务器返回需要保存到服务器的地址,读取文件时也需要与控制服务器交互,获取存储位置信息,其中HDFS、GFS等分布式存储使用此种技术,namenode就类似于控制服务器角色。另外一个思路是,不需要控制服务器,客户端自己计算需要存储到哪里,最简单的方式是直接取hash,比如有8台存储服务器,只需要把文件内容或者文件名取hash模8即可计算出应该存储到哪台存储服务器。但有个问题是,当服务器数量增减时,hash就失效了,几乎需要重排迁移所有数据,根本没有办法实现水平扩展,这在分布式系统中是无法忍受的。为了避免出现这种情况,引入了一致性hash算法,又称为环哈希,关于该算法可参考深入云存储系统Swift核心组件:Ring实现原理剖析 - 牛皮糖NewPtone - 博客园,其中OpenStack Swift、华为FusionStorage就是使用的该方法。除了环hash,当然还有其他的类hash算法,比如CRUSH算法,关于CRUSH算法介绍可参考大话Ceph--CRUSH那点事儿,其中开源分布式存储系统Ceph就是使用的该方法。需要注意的是虽然基于hash的文件分布映射方法不需要控制节点计算需要存储的位置,但仍然需要控制服务器保存一些集群元数据,比如集群的成员信息、映射规则、监控等等,如Ceph的mon服务。如果只有一个控制服务,则存在单点故障,挂掉了就会导致服务不可用。为了避免单点故障,具备高可用特点,必然需要同时启动多个控制服务,有多个控制服务就必须区分谁是leader,谁是slave,因此需要分布式一致性来协调选主,可以基于现有的分布式协调系统实现,如Zookeeper、Etcd服务等,也可以直接基于Paxos、Raft算法实现,Paxos相对复杂,Google的分布式锁服务Chubby就是基于Paxos实现的,Raft相对比较简单容易理解,可参看Raft-Understandable Distributed Consensus动态展示了该算法的执行流程,更多关于Raft的信息可参看官方文档主页Raft Consensus Algorithm。

文件直接映射到物理主机或者物理硬盘,粒度太粗略,容易导致数据分布不均匀。如果踢掉一台服务器或者一块硬盘,需要把这台服务器的数据迁移到重映射的另一台主机,迁移数据的IO都集中在这两台主机之间,其它主机帮不上忙。于是引入了虚拟主机概念,OpenStack Swift中叫做partition以及Ceph中PG等都是类似的概念。原理就是在物理主机上面加一层逻辑主机,比如有8台物理主机,可以创建128个虚拟主机,然后把这8台物理主机映射到这128台逻辑主机上,这样相当于每一台主机都虚拟成16台虚拟主机,当然实际上不一定是按照平均分,可以根据磁盘容量映射,磁盘空间大可以映射较多的虚拟主机。当然虚拟主机数量通常都会设置成2的幂,这样很多计算都可以使用位运算进行优化,比如取模运算等。这样文件块会先根据虚拟主机计算存储位置,然后再从表中查找虚拟主机映射的物理主机,文件块分布更均匀,当踢掉一台主机时会重映射到多台主机中,数据迁移效率提升。

解决了文件如何分布的问题,自然会遇到的问题是如果文件很大怎么办,可能在一台服务器根本存不下,即使存下了,也会导致各个服务器的磁盘利用率不均衡,甚至可能出现大量存储碎片。于是我们自然想到的是把文件分块,然后基于块存储,比如按照64MB大小分块,如果存储一个2GB的文件,则需要把文件分割成32个块,然后逐块存储,存储位置仍然使用前面提到的hash算法。分块是存储密度更大、更紧凑,几乎所有的分布式存储系统都会使用分块技术。

接下来,将考虑存储系统的数据可靠性(数据不丢)以及可用性(数据可访问)问题,如果其中一个服务器坏了怎么办?显然可能出现一个文件的某些块不能访问了,文件读取失败。为了解决这个问题,最容易想到的方法是使用冗余技术,即每一个块,我都存储多份,并分布到不同的服务器中,这样即使其中一个服务器宕机了,也能从其他服务器中读取块,这个和RAID 1技术原理是一样的。存储多少份呢,这个需要权衡成本以及数据可靠性要求,通常来说存储三份就够了。有人会说,存储三份,相当于使用了三倍的存储空间,这样存储资源是不是有点太浪费了,而又不想牺牲数据可靠性。我们学习算法时经常使用时间换空间的思想,计算换存储,这个仍然可以从RAID实现中获取灵感,以RAID 5为例,通过奇偶校验恢复数据,存储利用率为(n-1)/n,相比RAID 1的1/2提高了存储利用率,并且具有RAID 1一样的可靠性,但需要耗费CPU计算奇偶位。奇偶校验只能缺一位,自然可以想到进一步泛化,于是引入纠删码技术,原理其实就是类似解线性方程,关于纠删码技术介绍可以参考Erasure Code - EC纠删码原理。几乎所有的分布式存储系统都使用了冗余副本技术,大多数都会支持纠删码,比如Ceph、Swift。

无论使用纯副本技术还是结合纠删码,必然还是需要把一个块复制多份存储,写入多份,这里假设副本数为3份。这些副本如何写入呢?当拿到三个副本的位置后,客户端可以同时写入三个副本,这种方式称为直接复制(direct replication),这样的问题是客户端会同时占用3倍的业务网络带宽,吞吐量也只有1/3,glusterfs采用的是这种复制策略。另一种方式是客户端只选择其中一个主节点写入数据,当写完第一个节点的数据后,由第一个节点复制到第二个节点,再由第二个节点复制到第三个节点,以此类推直到写完所有的副本,这种方式称为链式复制(chain replication),Ceph、HDFS都是采用的该种策略,这样由于客户端其实只是写了一份数据,不占用额外的业务网络,而存储节点之间的复制可以是一个专门的存储网,不影响业务网络。关于chain replication可以参考论文Chain Replication for Supporting High Throughput and Availability。

写入多份数据,如何保证这些副本数据都是一样的,如何保证三个数据同步呢,万一哪台服务器挂了写不进去怎么办。于是引入了一致性策略。最简单的方法,就是等所有的副本都完成时才返回结果,这样保证写入的三个副本肯定没有问题,这就是强一致性,其中Ceph就是使用的强一致性模型,强一致性能够保证多副本完全一致,并且不会读取脏数据,但是性能不好,万一有一台服务器巨慢则会拖垮整个集群,典型的木桶效应,因此强一致性天生难以支持跨区域部署,因为跨区域的远端时延太长了,导致存储系统性能低。为了避免这种情况,我们可以适当放宽条件,即只要保证一半以上的服务器写入成功即返回,这样即使其中有少数服务器拖后腿也没有关系,不用等,让他自个慢慢同步,最终一致即可。这就是典型的最终一致性模型,OpenStack Swift即采用该种策略,这种模型能够提高读写性能,但可能读取脏数据,比如刚好读到还没有来得及同步的服务器的数据块。事实上高性能和强一致性是两者不可兼得的,这就是著名的CAP理论,这里的C代表一致性,A代表可用性(在一定时间内,用户的请求都会得到正确的应答),P代表分区容错。正常情况下,存储系统的所有节点都是互通的,处在一个网络连通区域中,如果有些节点之间不连通了(节点挂了或者网络故障),这就相当于把一个网络连通区域割裂了几个区域,彼此不能通信了,因此叫做分区。分布式存储系统要系统出现分区时数据不丢(可靠性),数据可访问(可用性),避免脑裂,因此P是100%需要满足的,否则稍微一个网络抖动,数据就损坏了。剩下的就是C和P之间的权衡,这个就看你要设计成什么存储系统了,如果一致性不那么重要,比如对象存储,上传了一个新文件,即使马上读不到数据也无所谓,但是可能需要支持大规模的对象写入,因此更关注A,设计为AP存储系统。而对于一些实时性要求高的系统,必须保证写入后数据一定能够读到正确的数据(而不是脏数据),就必须牺牲吞吐量,因此设计为CP存储系统。

为了节省存储空间,可能会用到压缩技术,压缩大家都很熟悉了,这里不多介绍。

如果是一个海量分布式存储系统,尤其是提供公有云服务,比如网盘服务,肯定会有用户上传一模一样的文件,为了节省成本,自然想到避免存储重复的文件,这就是重删技术(Data deduplication),可参考int32bit:百度云的「极速秒传」使用的是什么技术?,简单理解就是客户端上传文件时,先在本地计算下hash指纹,然后上传到服务器比对,如果指纹一样,说明文件已经存在,此时不需要上传文件内容,直接链接下即可,不仅节省了存储空间(比压缩更省),还节省了上传时间,实现秒传。我了解的Fusion Storage是实现了重删技术,OpenStack Swift、Ceph貌似都没有。

另一个问题是,如果集群彻底瘫了,数据就彻底没了,这可不能忍。为了解决这个问题,你自然会想到使用复制手段,即备份技术,把文件复制存储到其它廉价存储服务器中,比如S3。当用户执行save操作时,复制这个文件并重命名为xxx-020(时间戳),这样非常容易就能恢复到备份的任意版本,由于每次都要拷贝整个文件,因此称为全量备份(full backup)。每次都复制显然耗时耗空间,自然想到只复制上一次备份后改变的内容,这样就可以节省存储空间,即增量(incremental backup)备份。注意,备份一定要拷贝到其它存储系统,如果仅仅是拷贝到当前存储系统,不叫备份,只能叫副本,集群瘫了,数据仍然不能恢复。副本主要用于防故障,即一块硬盘坏了数据不丢且还能读,备份还用于防人祸,比如误删操作,能回滚到前面的一个备份点上。

以上备份技术需要用户自己手动执行,如果没有实时备份,集群突然挂了,数据还是会丢。因此需要采取容灾策略,其中一个容灾策略就是异地同步技术,或者叫做复制技术(geo-replication/mirror),这个类似于mysql的主从同步,即在异地建立一个一模一样的集群,这个集群正常情况下不向用户提供存储服务,仅仅同步本地的集群数据,当本地的集群挂了,能够自动切换到异地集群,服务依然可用。注意这个和副本之间完全同步不一样,复制技术通常采用异步策略,基于操作日志replay,mysql使用binlog,ceph使用journal日志。ceph的rbd mirror就是采用的此种技术,关于rbd mirro介绍参考Ceph Jewel Preview: Ceph RBD mirroring。

当然即使有如上的副本技术、备份技术、容灾技术,集群瘫了也可能短时间内不可用。这就引入两个指标,一个是RPO,故障后数据可恢复到故障前哪个时间点,当然越小约好,0表示能立即恢复,无穷大表示数据废了恢复不了了,3表示能恢复到故障前3秒,这其实和备份策略有关,比如每天0点备份,那备份点就是当天0点数据。另一个指标为RTO,即故障后多长时间可以恢复,0表示服务连续毫无影响,无穷大表示服务再也恢复不了了,60表示一个分钟能恢复。

分布式存储系统不仅需要大量的磁盘IO,还需要网络IO,然而网络带宽必然是有限的,有限的资源就必然需要合理的分配。如果某个用户持续不断的读写,抢占大量的IO带宽,则必然导致其它用户性能下降,甚至出现饿死状况。因此需要公平控制用户的IO资源使用情况,于是引入了QoS。QoS的目标是要实现系统IOPS的调度分配,对单一客户端的IOPS、IO带宽进行限制,不能让某个客户端独占了整个系统的IOPS。QoS限制客户端能够使用的最大值称为limit,即上限。注意,QoS不是仅仅有limit就够了,为了避免某些客户端迟迟得不到IO调度而被饿死,QoS还包含一个下限控制,称为reservation。上限limit容易理解,这个下限就容易弄混,因为有人会想,如果我的这个客户端就是没有IO需求,那它的IOPS就是0,这个下限有什么意义。其实这个下限是一个承诺,当客户端有大于reservation的IOPS请求时,系统能够保证给予不小于reservation的IOPS,如果客户端本身就不需要大于的reservation的值,那自然不需要分配其IOPS。因此,这个reservation翻译为预留更合适,系统调度IOPS时,会优先满足reservation的值,多余的再根据实际情况分配。当然在同时满足了请求的上限和下限下,不同的请求IOPS仍然不同,优先级也有可能不一样,因此还需要一个控制指标,称为分配比例。系统会根据权重去分配,能者多得,这样才能真正发挥资源的最大价值。关于QoS的实现,有两种思路,一种是直接使用Linux系统的cgroup实现,QEMU对虚拟机的磁盘QoS控制就是使用的该原理,这种方式不依赖于存储系统本身的实现。另一种就是QoS由存储系统自己,对某个节点实现QoS可参考VMware在OSDI发表的一篇论文mClock: handling throughput variability for hypervisor IO scheduling,而dmClock即分布式的mClock,实现分布式系统的QoS控制,目前是作为Ceph的一个子项目,ceph/dmclock,关于dmClock的介绍可参考虚拟化I/O QoS mClock算法介绍。

块存储:即提供裸的块设备服务,裸设备什么都没有,需要用户自己创建分区、创建文件系统、挂载到操作系统才能用,挂一个块存储设备到操作系统,相当于插一个新U盘。只实现了read、write、ioctl等接口。SAN、LVM、Ceph RBD、OpenStack Cinder等都属于块存储服务。

文件存储:可以简单理解为分布式文件系统,通常实现了POSIX接口,不需要安装文件系统,直接像NFS一样挂载到操作系统就能用。典型的文件存储如NAS、HDFS、CephFS、GlusterFS、OpenStack Manila等。

对象存储:提供Web存储服务,通过HTTP协议访问,只需要Web浏览器即可使用,不需要挂载到本地操作系统,实现的接口如GET、POST、DELETE等,典型的对象存储如百度网盘、S3、OpenStack Swift、Ceph RGW等。百度云网盘手机端

有些存储系统只提供以上某种接口,有些存储系统则能够同时支持以上三种存储服务接口,比如Ceph。

块存储最典型的使用场景是作为虚拟机的磁盘。虚拟机通常需要申请几十GB到几TB的虚拟硬盘,但虚拟机实际上并不是一下就真的会用那么多的存储,如果申请多少就分配多少,显然会造成磁盘空间利用率不高,不能实现超售。因此引入了精简配置(thin provision),这个其实不难理解,就是类似于Linux的稀疏文件(sparse file),关于Linux稀疏文件介绍可参考int32bit: sparse文件处理与传输,简单理解就是当申请一个20GB的虚拟磁盘时并不会立即真正从硬盘中分配空间,而是用多少分配多少,因此可以创建总大小远大于实际物理磁盘空间大小的磁盘,实现磁盘超售。但需要注意控制超售率,避免虚拟磁盘写满时,物理磁盘空间不足导致数据损坏。

分布式存储和本地存储一样,自然需要有版本控制,用户可以随时回滚到任意一个时间点的存储状态,或者基于某个时间点的版本修改,类似于git的checkout以及branch操作。当然你可以使用备份技术实现,只是太耗时耗空间。为了实现这个功能,引入快照技术(snapshot),快照的功能形如其名,就是把当前的存储状态拍个照保存下来,以后可以随时回滚到某个快照时刻的状态。可以在快照的基础上,创建一个一样的磁盘卷,称为克隆(clone),注意和复制(copy)的不同,创建的新卷并没有拷贝源数据,也没有分配任何存储空间,只是画了一个指针指向原来的快照卷,秒级完成。OpenStack使用Ceph存储后端能够秒级创建虚拟机就是这个原因。当用户读取数据时,如果自己的卷没有找到,则需要在它parent中去找,如何写入则取决于采用何种快照方式。快照的实现有两种方式,一种是COW(Copy On Write,写时拷贝),快照是只读的,不允许修改,当用户有新的数据写入克隆的磁盘时,会首先从快照中拷贝一份数据写到另一个分配的空间,然后把修改的数据覆盖新分配的空间,相当于两次写操作。当磁盘创建快照,克隆,再创建快照,再克隆,形成一条很长的克隆链,当读取数据时,需要从当前卷开始查找,找不到查找其parent卷,直到查找到base镜像,写入数据也类似,当当前卷的块没有时,需要从其parent中依次查找,然后拷贝到自己的卷中,再写入新的数据。显然,当链越来越长时,卷的读写性能越来越差,因此需要控制链的长度。另一种快照技术是ROW(Redirect On Write),这个和COW不同,当有新数据写入时,直接写入一个新分配的区,然后修改卷的指针指向新的区地址,只有一次写操作,关于COW与ROW介绍可以参考ROW/COW 快照技术原理解析。

虚拟机可能同时挂了多个虚拟硬盘,需要对这个虚拟机打快照,此时需要保证所有的卷的快照时一致的,而不能出现各个卷快照点不一致。于是引入了一致性快照技术(Consistency Snapshot Group),参考存储专栏:深度解读高端存储的快照技术_存储在线。

以上,花了两个晚上粗略总结了分布式存储系统的一些关键技术,参考了很多博客文章,在原文中都有标明。百度网盘搜百度盘需要强调的是真正实现分布式存储系统的技术远不止这些,这里仅仅作为抛砖引玉。其它的技术,诸如副本不一致时如何同步,新增或者减少节点时数据如何迁移,引入缓存提高性能等等,待有时间再补充。

一切以客户的需求为出发点。传统存储以文件系统为典型代表,但是随着数据爆炸性增长,传统文件系统已经无法满足对存储系统的容量、性能等需求,因此,云存储应运而生。

云存储最大的特点是数据被集中存储在数据中心,公有云存储将客户数据存放在公有云服务商数据中心,而私有云存储则是将公有云存储能力私有化部署在客户自身的数据中心。

既然提到了数据中心,可想而知云存储最大的特点应该是海量:解决数以PB至EB的数据存储需求。所有云存储技术面对的通用问题有如下几个:

好的扩展性取决于好的架构设计。主流云存储系统一般分为中心化和去中心化设计。中心化设计以GFS为典型代表,HDFS等也继承这种设计思想。顾名思义,中心化就是存在中心服务器会维护存储系统的关键元信息。维护这些元数据的关键作用是文件定位:即给定一个文件描述符,如何快速找到文件所在的存储位置(在哪个服务器的哪个磁盘上)。

当然,元信息的种类也有所不同,这种不同也体现了扩展性的差异,如GFS就在中心服务器中维护了文件属性等元数据,可想而知,随着文件数量的增长,必然达到一个瓶颈,于是更多的优化方案就出来了,例如元数据分割(静态分割、动态分割等)。

去中心化设计则力图避免该问题:数据的定位不再需要去中心服务器查询,而是通过特定的计算就可以找到文件的位置。可想而知,抛弃了元数据服务的束缚,整个系统就可以自由自在的翱翔了。当然,这也是有代价的,接下来就说。

去中心化固然好,但是由于存在节点变更时需要解决数据迁移问题,因此是一个头疼的问题,如何尽量减少数据迁移,又是一个大的课题,这里不展开细述。

因此,中心化的设计依然有其存在的价值,其简单的设计在分布式存储系统这个复杂的工程领域特别难得。

有几天没来更新,请谅解,因为这几天在帝都吸雾霾,做贡献。今天就来聊聊可靠性吧,这应该是做存储的最关心的问题了,每天都在担心有没有给客户丢数据,做梦都能吓醒。

这很好理解,最简单粗暴的方法是将数据存在多个地方,这样,即使一个地方数据丢失了,还有其他的备份可用。这是最常见的做法,看似简单,实际非常复杂,需要考虑以下问题:

上面的这些问题既涉及工程经验问题,百度云邮箱在哪里又包含了复杂的分布式理论知识(如多备份数据一致性),够吃好几壶了

多副本好是好,就是代价太大了,需要多花费好几倍的成本来存储数据,资本家不会答应的。于是大家想起了通过计算的方式来为数据计算校验信息,在数据损坏时通过校验信息来恢复原始数据(参考RAID),同样很复杂,需要考虑的问题有:

从狭义上来说,云存储是指通过虚拟化、分布式技术、集群应用、网格技术、负载均衡等技术,将网络中大量的存储设备通过软件集合起来高效协同工作,共同对外提供低成本、高扩展性的数据存储服务。

从广义上来讲,云存储可以理解为按需提供的虚拟存储资源,如同云计算的Paas、Iaas服务一样,可称为数据存储即服务(Data Storage As a Service,DaaS),即基于指定的服务水平请求,通过网络提供适当的虚拟存储和相关数据服务。

云存储不是指某一个具体的设备,而是指一个由许许多多个存储设备和服务器所构成的集合体。使用者使用云存储,并不是使用某一个存储设备,而是使用整个云存储系统带来的一种数据访问服务。云存储的核心是应用软件与存储设备相结合,通过应用软件来实现存储设备向存储服务的转变。云存储就是将储存资源放到网络上供人存取的一种新兴方案。使用者可以在任何时间、任何地方,透过任何可连网的装置方便地存取数据。

Ø低成本:云存储系统应具备高性价比的特点,低成本体现在两方面, 更低的建设成本和更低的运维成本;

Ø无接入限制:相比传统存储,云存储强调对用户存储的灵活支持, 服务域内存储资源可以随处接入,随时访问;

Ø易管理:少量管理员可以处理上千节点和PB级存储,更高效的支 撑大量上层应用对存储资源的快速部署需求。

传统的存储架构就是如下图所示的,存储、网络和主机都在同一个数据中心,客户通过局域网可以直接访问背后的存储。

而云存储是指通过虚拟化、分布式技术、集群应用、网格技术、负载均衡等技术,将分散在不同地方的大量的存储设备通过软件集合起来,客户通过公用访问接口、接入网和客户端程序等获取存储资源,客户并不知道所访问的存储资源处在什么地方。

Ø存储层:存储设备数量庞大且分布在不同地域,彼此通过广域网、互联网或光纤通道网络连接在一起。在存储设备之上是一个统一存储设备管理系统, 实现存储设备的逻辑虚拟化管理、多链路冗余管理,以及硬件设备的状态监控和故障维护。

Ø基础管理层:通过集群、分布式文件系统和网格计算等技术,实现云存储设备之间的协同工作,使多个的存储设备可以对外提供同一种服务, 并提供更大更强更好的数据访问性能。数据加密技术保证云存储中的数据不会被未授权的用户访问, 数据备份和容灾技术可以保证云存储中的数据不会丢失, 保证云存储自身的安全和稳定。

Ø应用接口层:不同的云存储运营商根据业务类型,开发不同的服务接口,提供不同的服务。例如视频监控、视频点播应用平台、网络硬盘,远程数据备份应用等。

Ø访问层:授权用户可以通过标准的公用应用接口来登录云存储系统,享受云存储服务。

通过存储虚拟化方法,把不同厂商、不同型号、不同通信技术、不同类型的存储设备互联起来,将系统中各种异构的存储设备映射为一个统一的存储资源池。存储虚拟化技术能够对存储资源进行统一分配管理,又可以屏蔽存储实体间的物理位置以及异构特性,实现了资源对用户的透明性,降低了构建、管理和维护资源的成本,从而提升云存储系统的资源利用率。

存储虚拟化技术虽然不同设备与厂商之间略有区别,但从总体来说,可概括为基于主机虚拟化、基于存储设备虚拟化和基于存储网络虚拟化三种技术。

分布式存储是通过网络使用服务商提供的各个存储设备上的存储空间,并将这些分散的存储资源构成一个虚拟的存储设备,数据分散的存储在各个存储设备上。目前比较流行的分布式存储技术为:分布式块存储、分布式文件系统存储、分布式对象存储和分布式表存储。

为应对数据存储的急剧膨胀,企业需要不断购置大量的存储设备来满足不断增长的存储需求。权威机构研究发现,企业购买了大量的存储设备,但是利用率往往不足50%,存储投资回报率水平较低。通过云存储技术不仅解决了存储中的高安全性、可靠性、可扩展、易管理等存储的基本要求,同时也利用云存储中的数据缩减技术,满足海量信息爆炸式增长趋势,一定程度上节约企业存储成本,提高效率。

比较流行的数据缩减技术包括:自动精简配置、自动存储分层、重复数据删除、数据压缩

在以数据为中心的时代,数据的重要性无可置否,如何保护数据是一个永恒的话题,即便是现在的云存储发展时代,数据备份技术也非常重要。数据备份技术是将数据本身或者其中的部分在某一时间的状态以特定的格式保存下来,以备原数据出现错误、被误删除、恶意加密等各种原因不可用时,可快速准确的将数据进行恢复的技术。数据备份是容灾的基础,是为防止突发事故而采取的一种数据保护措施,根本目的是数据资源重新利用和保护,核心的工作是数据恢复。

内容分发网络是一种新型网络构建模式,主要是针对现有的Internet进行改造。基本思想是尽量避开互联网上由于网络带宽小、网点分布不均、用户访问量大等影响数据传输速度和稳定性的弊端,使数据传输的更快、更稳定。通过在网络各处放置节点服务器,在现有互联网的基础之上构成一层智能虚拟网络,实时地根据网络流量、各节点的连接和负载情况、响应时间、到用户的距离等信息将用户的请求重新导向离用户最近的服务节点上。

存储加密是指当数据从前端服务器输出,或在写进存储设备之前通过系统为数据加密,以保证存放在存储设备上的数据只有授权用户才能读取。目前云存储中常用的存储加密技术有以下几种:全盘加密,全部存储数据都是以密文形式书写的;虚拟磁盘加密,存放数据之前建立加密的磁盘空间,并通过加密磁盘空间对数据进行加密;卷加密,所有用户和系统文件都被加密;文件/目录加密,对单个的文件或者目录进行加密。

以目前数据增长的速度来看,云存储越来越流行不足为奇。增长速度最快的数据是归档数据,鉴于很多因素它是云存储的理想之选,这些因素包括成本、访问频率、保护和可用性。但是并非所有云存储都是相同的。一家提供商可能主要关注于成本,而另一家提供商关注于可用性或性能。没有一个架构具有单一侧重点,但是一个架构实现给定特征的程度定义了其市场和适当的使用模型。

不从效用角度谈论架构是很难的。通过各种特征度量一个架构,包括成本、性能、远程访问,等等。因此,我首先定义一组可度量云存储模型的标准,然后探究云存储架构内的一些有趣的实现。

首先,我们讨论一个通用的云存储架构,设置上下文以供后面探究独特的架构特性。

云存储架构主要关乎以一个高度可扩展和多租户的方式按需交付存储。通用(参见 图 1)的云存储架构包含一个导出 API 以访问存储的前端。在传统的存储系统中,这个 API 是 SCSI 协议;但是在云环境中,这些协议在演化。在那里您可以找到 Web 服务前端、基于文件的前端,甚至更多传统前端(比如 Internet SCSI 或 iSCSI)。在前端后面是一个中间件层,我将它称作存储逻辑。该层通过传统的数据放置算法(考虑地理布局)实现各种功能,比如复制和数据简缩。最后,后端实现对数据的物理存储。这可能是一个实现特定功能的内部协议或物理磁盘的一个传统后端。

从图 1 中,您可以看到当前云存储架构的一些特征。注意,没有特征在特定层中是独有的,而是充当本文探讨的特定主题的指导。这些特征的定义见 表 1。

云存储的一个重点是成本。如果客户可以购买并在本地管理存储,而不是在云中租赁它,那么云存储市场就会消失。但是成本可划分为两个高级类别:物理存储生态系统本身的成本和管理它的成本。管理成本是隐式的,但却是总体成本的一个长期组成部分。为此,云存储必须能在很大程度上进行自我管理。引入新存储(其中系统通过自动自我配置来容纳它)的能力和在出现错误时查找和自我修复的能力很重要。在未来,诸如自主计算这样的概念将在云存储架构中起到关键的作用。

Web 服务 APIs 的一个问题是,它们需要与应用程序集成,以利用云存储。因此,对云存储也使用常见的访问方法来提供即时集成。例如,NFS/Common Internet File System (CIFS) 或 FTP 等基于文件的协议,iSCSI 等基于块的协议。Nirvanix、Zetta 和 Cleversafe 等云存储提供商提供这些访问方法。

尽管上面提到的协议是最常用的,但也有适合云存储的其他协议。最有趣的其中一个是基于 Web 的分布式创作与版本控制(WebDAV)。WebDAV 也基于 HTTP,且将 Web 作为一种可读写的资源加以启用。WebDAV 的提供商包括 Zetta 和 Cleversafe 等。

您还可以寻找支持多协议访问的解决方案。例如,IBM® Smart Business Storage Cloud 从同一存储虚拟化架构同时启用基于文件(NFS 和 CIFS)的协议和基于 SAN 的协议。

性能表现为很多方面,但是在用户与远程云存储提供商之间移动数据的能力是云存储最大的挑战。问题就是 TCP,它同时也是互联网的主力。TCP 基于数据包确认从对等端点控制数据流。数据包丢失或延迟到达情况下将启用阻塞控制,进一步限制性能以避免更多全局网络问题。TCP 适用于通过全局 Internet 启用小量数据,但不适用于会增加往返时间(RTT)的大型数据移动。

通过 Aspera Software,Amazon 解决了这个问题,方法就是从程式中删除 TCP。且开发了一个称为Fast and Secure Protocol(FASP™) 的新协议,以在大型 RTT 和严重数据包丢失情况下加速批量数据移动。关键是 UDP 的使用,它是 TCP 的缔约方传输协议。UDP 允许主机管理阻塞,将这个方面推进到 FASP 的应用层协议中(参见 图 3)。

通过标准(非加速)NICs、FASP 有效使用应用程序可用带宽,并移除传统的批量数据传输模式的基本瓶颈。参考资料部分提供在传统 WAN、洲际传输和有损卫星链接中 FASP 性能相关的一些有趣统计信息。

云存储架构的一个关键特征称为多租户。这只是表示存储由多个用户(或多个 “承租者”)使用。多租户应用于云存储堆栈的多个层,从应用层(其中存储名称空间在用户之间是隔离的)到存储层(其中可以为特定用户或用户类隔离物理存储)。多租户甚至适用于连接用户与存储的网络基础架构,向特定用户保证服务质量和优化带宽。

您可以从多个方面看待可扩展性,但正是云存储的随需视图使其最具吸引力。扩展存储需求(向上和向下)可改善用户成本,提高云存储提供商的复杂性。

不仅要为存储本身提供可扩展性(功能扩展),而且必须为存储带宽提供可扩展性(负载扩展)。云存储的另一个关键特性是数据的地理分布(地理可扩展性),支持经由一组云存储数据中心(通过迁移)使数据最接近于用户。对于只读数据,也可以进行复制和分布(使用内容传递网络完成)。这如图 4所示。

在内部,一个云存储架构必须能够扩展。服务器和存储必须能够在不影响用户的情况下重新调整大小。正如在 可管理性 部分所讨论的,自主计算是云存储架构所必需的。

如果一个云存储供应商有用户的数据,它必须能够应求将该数据提供给用户。鉴于网络中断、用户错误和其他情况,这很难以一种可靠而确定的方式予以提供。

有一些有趣而新颖的方案可用于解决可用性,比如信息传播。一家提供私有云存储的公司 Cleversafe(稍后介绍)使用 Information Dispersal Algorithm (IDA) 来在发生物理故障和网络中断的情况下实现更高的可用性。IDA 是由 Michael Rabin 最初为电信系统而创建的一种算法,它支持使用 Reed-Solomon 代码对数据进行切片处理,以便在数据丢失的情况下实现数据重建。此外,IDA 允许您配置数据切片的数量,这样一来,可以为一个可接纳故障将数据对象分割成 4 个切片,对 8 个可接纳故障分割成 20 个切片。与 RAID 类似,IDA 支持通过原始数据的子集重建数据,含有一定数量的代码错误开销(依赖于可接纳故障的数量)。这如图 5所示。

有了为数据切片的能力以及 cauchy Reed-Solomon 纠错码,就可以将切片分发到地理上分散的站点进行存储。对于大量切片(p)和大量可接纳故障(m),最终开销是p/(p-m)。因此在图 5中,p= 4 且m= 1 的存储系统的开销是is 33%。

IDA 的缺点在于,它是处理密集型的,无硬件加速。复制是另一个有用的技术,且由各个云存储提供商实现。尽管复制技术引入了大量开销(100%),但可以简单而高效地提供它。

一名客户控制和管理其数据存储方式及其相关成本的能力很重要。许多云存储提供商实施控制,使用户对其成本有更大的控制权。

Amazon 实现 Reduced Redundancy Storage (RRS),为用户提供最小化总存储成本的一种方式。数据是在 Amazon S3 基础架构内复制的,但使用 RRS,数据复制次数较少,且存在丢失数据的可能性。这适用于可重新创建的或在其他地方有副本的数据。Nirvanix 还提供基于策略的复制来对如何以及在何处存储数据提供更细粒度的控制。

存储效率是云存储基础架构的一个重要特征,特别是将重点放在总成本上。下一部分专门介绍成本,但是该特征更多地是关于对可用资源的高效使用,而非成本。

要使一个存储系统更高效,必须存储更多数据。一个常见的解决方案就是数据简缩,即通过减少源数据来降低物理空间需求。实现这一点的两种方法包括压缩— 通过使用不同的表示编码数据来缩减数据 — 和重复数据删除— 移除可能存在的相同的数据副本。虽然两种方法都有用,但压缩方法涉及到处理(重新编码数据进出基础架构),而重复数据删除方法涉及到计算数据签名以搜索副本。

云存储最显著的特征之一是通过使用降低成本的能力。这包括购置存储的成本、驱动存储的成本、修复存储的成本(当驱动器出现故障时)以及管理存储的成本。在从这个角度(包括 SLAs 和增加存储效率)看待云存储时,云存储在某些使用模型中会很有用。

云存储解决方案内的一个有趣的使用高峰由一个名为 Backblaze 的公司提供(参见 参考资料 了解详情)。Backblaze 着手于为云存储产品构建廉价存储。一个 Backblaze POD(存储架)在一个 4U 机箱中具有 67TB 的数据包,价格不到 8,000 美元。这个数据包含有一个 4U 机箱、一个主板、4GB 的 DRAM、4 个 SATA 控制器、45 个 1.5TB SATA 硬盘和两个电源。在主板上,Backblaze 运行 Linux®(以 JFS 作为文件系统)且以 GbE NICs 作为前端,使用 HTTPS 和 Apache Tomcat。Backblaze 的软件包括重复数据删除、加密功能和用于数据保护的 RAID6。Backblaze 对其 POD 的描述(详细介绍如何构建您自己的 POD)向您展示公司可以将存储成本降低多大幅度,使云存储成为一个可行且经济高效的选择。

到目前为止,我主要谈讨了云存储提供商,但是还有云存储模型可支持用户控制其数据。云存储演化为三个类别,其中一个支持合并两个类别,以提供一个经济高效而安全的选择。

本文大部分讨论了公共云存储提供商,它们将云存储基础架构作为可出租商品予以提供(从长期或短期存储和基础架构内使用的网络带宽角度来讲)。私有云使用公共云存储的概念,但是以可安全嵌入到用户防火墙内的形式。最后,混合云存储支持合并这两个模型,通过策略定义哪些数据必须私下维护,哪些可在公共云内得到安全维护(参见 图 6)。

云存储模型如图 6 所示。典型的公共云存储供应商包括 Amazon 和 Nirvanix(将存储作为服务提供)。典型的私有云存储提供商包括 IBM、Parascale 和 Cleversafe(为内部云构建软件和/或硬件)。最后,混合云提供商包括 Nirvanix 和 Egnyte 等。

云存储是云存储模型中的一个有趣进化,它重新定义我们在企业内构建、访问和管理存储的方式。尽管云存储目前主要是一种消费技术,它在迅速向企业质量方向演化。混合云存储模型将使企业能够在一个本地数据中心内维护其机密数据,同时委托更少的机密数据到云中,以实现成本节约和地域保护。

云存储的范围很广有很多不同的类型,这里以比较泛用的S3做栗子吧(仅限公有技术,防老东家抄水表。。。)

涉及概念较多不做一一展开仅提供维基链接,对某项特别感兴趣可以自行谷歌百度。

首先是分布服务过不去的CAP。其实这是个伪命题,因为如果不给P的话系统崩了会被客户怼死。。。所以只有AP还是CP的选择。网络存储对一致性要求不高一般选AP。

要高 Availability 就要用Consistent hashing来发散文件块。很多人同时写要用Vector clock来确定事件的先后顺序做冲突解决。

然后是消息系统。新加入的机器,或者机器倒了,怎么样能让其他机器都知道呢?一半会有两种通信协议。一种是快速但不一致的Gossip protocol用作常规消息传播,一种是高一致但比较缓慢的Consensus协议来传播重要系统信息(很多用Paxos)

再有就是冗余存储,保证机房倒了硬盘崩了的时候不会丢数据。这个最简单的自然是存上N遍,但是考虑到复制成本一般不会这么做(因为要保证破三路硬盘也不会丢的话就要把一个文件存四遍,硬盘开销太大)。这时候要用到Erasure code,比如Reed-Solomon。