对于分布式存储的若干看法

云计算 分布式
分布式存储的应用场景相对于其存储接口,现在流行分为三种: 对象存储、块存储、文件存储。本文将对三种类型的分布式存储的应用场景、实现思路和实现方案上作出解答。

[[138674]]

Q: 现在领域内对于分布式存储的应用场景是否有比较明确的分类?比如冷热,快慢,大文件小文件之类的?

分布式存储的应用场景相对于其存储接口,现在流行分为三种:

1. 对象存储: 也就是通常意义的键值存储,其接口就是简单的GET,PUT,DEL和其他扩展,如七牛、又拍,Swift,S3、

2. 块存储: 这种接口通常以QEMU Driver或者Kernel Module的方式存在,这种接口需要实现Linux的Block Device的接口或者QEMU提供的Block Driver接口,如Sheepdog,AWS的EBS,青云的云硬盘和阿里云的盘古系统,还有Ceph的RBD(RBD是Ceph面向块存储的接口)

3. 文件存储: 通常意义是支持POSIX接口,它跟传统的文件系统如Ext4是一个类型的,但区别在于分布式存储提供了并行化的能力,如Ceph的 CephFS(CephFS是Ceph面向文件存储的接口),但是有时候又会把GFS,HDFS这种非POSIX接口的类文件存储接口归入此类。

按照这三种接口和其应用场景,很容易了解这三种类型的IO特点,括号里代表了它在非分布式情况下的对应:

1. 对象存储(键值数据库): 接口简单,一个对象我们可以看成一个文件,只能全写全读,通常以大文件为主,要求足够的IO带宽。

2. 块存储(硬盘): 它的IO特点与传统的硬盘是一致的,一个硬盘应该是能面向通用需求的,即能应付大文件读写,也能处理好小文件读写。但是硬盘的特点是容量大,热点明显。因此块存储主要可以应付热点问题。另外,块存储要求的延迟是***的。

3. 文件存储(文件系统): 支持文件存储的接口的系统设计跟传统本地文件系统如Ext4这种的特点和难点是一致的,它比块存储具有更丰富的接口,需要考虑目录、文件属性等支持,实现一个支持并行化的文件存储应该是最困难的。但像HDFS、GFS这种自己定义标准的系统,可以通过根据实现来定义接口,会容易一点。

因此,这三种接口分别以非分布式情况下的键值数据库、硬盘和文件系统的IO特点来对应即可。至于冷热、快慢、大小文件而言更接近于业务。但是因为存储系统是通用化实现,通常来说,需要尽量满足各种需求,而接口定义已经一定意义上就砍去了一些需求,如对象存储会以冷存储更多,大文件为主。

Q: 实现思路方面是否又有一些通用的分类法?

实现上主要有两层区别:

1. 系统的分布式设计: 主从、还是全分布式或者是兼而有之,目前现在存储系统因为一致性的要求,以主从为主。

2. 底层的单机存储: 一种是依赖本地文件系统的接口,如GlusterFS,Swift,Sheepdog,Ceph。一种是依赖块接口的,目前只知道Nutanix是使用这个的(http://stevenpoitras.com/the-nutanix-bible)。***一种是依赖键值接口的,目前应该只有Ceph是支持(Ceph支持多种单机存储接口)。***种依赖文件系统是因为分布式存储系统本身已经够复杂,实现者很难从上层一直到底层存储都去实现,而本地文件系统已经是一个通用化并且非常成熟的实现,因此分布式存储系统绝大部分(上述提到的都应该是)都会直接依赖本地文件系统。第二种接口目前只知道Nutanix 是支持的(传统的存储厂商的存储产品一般会使用这种方式),这种接口也就是比***种去掉了文件系统层,实现一个简单的物理块管理即可。第三种它的主要原因是“存储定义”和对象存储的普及,希望硬盘来提供简单的键值接口即可,如希捷的Kinetic API(https://github.com/Seagate/Kinetic-Preview),FusionIO的 NVMKV(https://github.com/opennvm/nvmkv),这种接口另一方面是闪存厂商非常喜爱的,因为闪存的物理特性使得它支持键值接口比快接口容易得多,目前Ceph是支持这种接口,而希捷和华为最近推出了IP硬盘(http://net.zdnet.com.cn /network_security_zone/2013/1024/2993465.shtml),听说已经实现了Swift上的原型。

(从这里可以发现,分布式存储系统是在传统的单机接口上重新包装了一层,然后实现三种类似的接口)

Q: 另外,对于不同的实现方案,分布式存储系统的性能是可以直接测试的,但理论可用性、数据可靠性的计算方式是不同的。UOS Cloud现在是Ceph方案,你们是怎么做这个计算的?

实际上这个计算是需要依赖于存储系统本身的,Ceph的优势是提供了一个叫CRush算法的实现,可以轻松根据需要来规划数据的副本数和高可用性。参考Ceph提供的模型定义(https://github.com/ceph/ceph-tools/blob/master/models /reliability/README.html)来规划自己的。这是我的同事朱荣泽做的故障计算。这个计算只针对副本策略,并不适合使用EC(擦除码)的情况。

硬盘发生故障的概率是符合泊松分布的。

 fit = failures in time = 1/MTTF ~= 1/MTBF = AFR/(24*365)
事件概率 Pn(λ,t) = (λt)n e-λt / n!

我们对丢失数据是不能容忍的,所以只计算丢失数据的概率,不计算丢失每个object的概率。

 N代表OSD的个数
R代表副本数
S代表scatter width,关系着recovery时间
我们忽略Non-Recoverable Errors的概率

计算1年内任意R个OSD发生相关故障概率的方法是

 1年内OSD故障的概率。
在recovery时(R-1)个OSD发生故障的概率。
以上概率相乘。假设结果是Pr

因为任意R个OSD不一定属于Ceph的Copy Sets,则Ceph的丢失Copy Sets的概率是:

 M = Copy Sets Number
在N个OSD中,任意R个OSD的组合数是 C(R,N)
丢失Copy Sets的概率是 Pr * M / C(R, N)。

最终公式是:

P = func(N, R, S, AFR)

责任编辑:Ophira 来源: 麦子迈
相关推荐

2017-10-27 08:40:44

分布式存储剪枝系统

2024-08-12 16:20:27

2015-05-12 13:03:54

开源分布式存储HDFS

2018-02-22 08:42:04

分布式存储安全

2018-10-29 12:51:35

分布式存储元数据

2021-10-22 05:42:38

分布式存储三副本系统

2017-10-17 08:33:31

存储系统分布式

2017-01-10 16:18:26

分布式存储建设

2018-10-09 10:45:40

2017-04-14 09:48:25

分布式存储系统

2018-01-02 20:00:28

数据库MySQL分布式存储

2019-06-19 15:40:06

分布式锁RedisJava

2017-10-19 08:45:15

存储系统HBase

2018-11-20 09:19:58

存储系统雪崩效应

2017-10-12 09:36:54

分布式存储系统

2018-08-29 11:57:17

分布式存储优点

2017-08-17 09:18:29

分布式存储面试

2018-10-16 14:26:22

分布式块存储引擎

2017-12-18 10:47:04

分布式存储数据

2018-11-15 12:35:25

Ceph分布式存储
点赞
收藏

51CTO技术栈公众号