《对于分布式存储的若干看法》由会员分享，可在线阅读，更多相关《对于分布式存储的若干看法（4页珍藏版）》请在金锄头文库上搜索。
1、对于分布式存储的若干看法Q: 现在领域内对于分布式存储的应用场景是否有比较明确的分类?比如冷热，快慢，大文件小文件之类的?分布式存储的应用场景相对于其存储接口，现在流行分为三种:1. 对象存储: 也就是通常意义的键值存储，其接口就是简单的 GET,PUT，DEL和其他扩展，如七牛、又拍，Swift，S3、2. 块存储: 这种接口通常以 QEMU Driver 或者 Kernel Module 的方式存在，这种接口需要实现 Linux 的 Block Device 的接口或者 QEMU 提供的 Block Driver接口，如 Sheepdog，AWS 的 EBS，青云的云硬盘和阿里云的盘古系统
2、，还有Ceph 的 RBD(RBD 是 Ceph 面向块存储的接口)3. 文件存储: 通常意义是支持 POSIX 接口，它跟传统的文件系统如 Ext4 是一个类型的，但区别在于分布式存储提供了并行化的能力，如 Ceph 的 CephFS(CephFS 是 Ceph 面向文件存储的接口)，但是有时候又会把 GFS，HDFS这种非 POSIX 接口的类文件存储接口归入此类。按照这三种接口和其应用场景，很容易了解这三种类型的 IO 特点，括号里代表了它在非分布式情况下的对应:1. 对象存储(键值数据库): 接口简单，一个对象我们可以看成一个文件，只能全写全读，通常以大文件为主，要求足够的 IO 带宽
3、。2. 块存储(硬盘): 它的 IO 特点与传统的硬盘是一致的，一个硬盘应该是能面向通用需求的，即能应付大文件读写，也能处理好小文件读写。但是硬盘的特点是容量大，热点明显。因此块存储主要可以应付热点问题。另外，块存储要求的延迟是最低的。3. 文件存储(文件系统): 支持文件存储的接口的系统设计跟传统本地文件系统如 Ext4 这种的特点和难点是一致的，它比块存储具有更丰富的接口，需要考虑目录、文件属性等支持，实现一个支持并行化的文件存储应该是最困难的。但像 HDFS、GFS 这种自己定义标准的系统，可以通过根据实现来定义接口，会容易一点。因此，这三种接口分别以非分布式情况下的键值数据库、硬盘和文
4、件系统的 IO特点来对应即可。至于冷热、快慢、大小文件而言更接近于业务。但是因为存储系统是通用化实现，通常来说，需要尽量满足各种需求，而接口定义已经一定意义上就砍去了一些需求，如对象存储会以冷存储更多，大文件为主。Q: 实现思路方面是否又有一些通用的分类法?实现上主要有两层区别：1. 系统的分布式设计: 主从、还是全分布式或者是兼而有之，目前现在存储系统因为一致性的要求，以主从为主。2. 底层的单机存储: 一种是依赖本地文件系统的接口，如GlusterFS，Swift，Sheepdog，Ceph。一种是依赖块接口的，目前只知道Nutanix 是使用这个的(http:/ Ceph 是支持(Cep
5、h 支持多种单机存储接口)。第一种依赖文件系统是因为分布式存储系统本身已经够复杂，实现者很难从上层一直到底层存储都去实现，而本地文件系统已经是一个通用化并且非常成熟的实现，因此分布式存储系统绝大部分(上述提到的都应该是)都会直接依赖本地文件系统。第二种接口目前只知道 Nutanix 是支持的(传统的存储厂商的存储产品一般会使用这种方式)，这种接口也就是比第一种去掉了文件系统层，实现一个简单的物理块管理即可。第三种它的主要原因是“存储定义”和对象存储的普及，希望硬盘来提供简单的键值接口即可，如希捷的 Kinetic API(https:/ 的 NVMKV(https:/ 是支持这种接口，而希捷和
6、华为最近推出了 IP 硬盘(http:/ /network_security_zone/2013/1024/2993465.shtml)，听说已经实现了 Swift上的原型。(从这里可以发现，分布式存储系统是在传统的单机接口上重新包装了一层，然后实现三种类似的接口)Q: 另外，对于不同的实现方案，分布式存储系统的性能是可以直接测试的，但理论可用性、数据可靠性的计算方式是不同的。UOS Cloud 现在是 Ceph 方案，你们是怎么做这个计算的?实际上这个计算是需要依赖于存储系统本身的，Ceph 的优势是提供了一个叫CRush 算法的实现，可以轻松根据需要来规划数据的副本数和高可用性。参考Cep
7、h 提供的模型定义(https:/ /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 时间我们忽略 No
8、n-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)【编辑推荐】1. 如何用云存储解决短视频社交产品锥心之痛 2. 博睿 Bonree 发布云平台网络测评排行榜 3. 初志携视频云存储一体机亮相 618 4. 为什么 OpenStack 会成为企业最重要的云平台？ 5. 提高云平台中 VM 高可用性的三个方法
