文章目录
- 1.对于一套分布式存储的方案，怎样评估它是好还是不好？
- 2.如何对分布式存储的不同实现进行分类？
- 3.分布式存储中的“数据可靠性”是如何计算的？
1.对于一套分布式存储的方案，怎样评估它是好还是不好？
（1）评价一个存储方案好和不好，只有一个客观的标准，那就是是否能满足用户的需求。
从青云的角度来说，有以下几点是用户需要的：
（1）运行或在线系统需要高性能。
这个不用多说，用户的业务数据几乎都会存储在数据库里面，没有一个用户会觉得数据库性能不重要
（2）离线或备份数据需要高容量，低价格。
这部分数据通常量很大，但是对性能要求不高，对不经常用的东西也不希望负担高额成本。
（3）所有的数据都必须是可靠的，绝对不能丢。
这是用户对于存储的容忍底线，所有负责任的企业都会将可靠性放在最重要的位置上，
在这个基础上能达到多高的性能就看技术实力了。（2）权衡的因素有很多——可靠性要求、可用性要求、时延要求、一致性要求、使用模式相关要求（包括请求大小、QPS/IOPS、吞吐）等。
（1）对于块存储，要求的访问时延是 10ms 级的，因为给虚拟机用的，传统硬盘也是 10ms 级的时延，请求尺寸都很小，但 qps（iops）可能会很高，那么在这种情况下：
>异地多中心是不现实的，存储要和主机尽量接近，相应地可靠性必然会有所打折
>强一致副本不会过多，强一致要求对时延有影响
（2）对于对象存储，要求的访问时延是 100ms - 1s 级的，
请求一般是中到大尺寸，低 qps 的，在这种情况下:
可以用更多的分散副本数来换取更高的可靠性，但过多副本增加维持一致性的难度，需要折衷
（3）另外 SSD 随着成本降低，在块存储里逐渐成为主流了，以便提供更好的 IOPS，
AWS 这个月开始，创建的 EBS 卷缺省就是 SSD 的了。
>对于评价一个实现，首先是看适合不适合这个用途，然后看这个方案有没有显著的缺点，
是否有严重的影响，然后成本之类的也是一个因素，做软件的人总觉的用便宜硬件实现
高大上的服务才值得吹牛，呵呵。
>底层存储服务（有别于数据库）的一致性是一种很难被用户观测到的，但是如果一个实现
根本没达到应有的一致性，比如块服务，只写了一个副本就返回给应用说写成功了，
这样是不太道德的，反正我个人坚持应该（EBS 块存储）应该写两个副本再返回，
在这个约束之内来优化。
总结就是：先看是否满足约束，然后看架构是否恰当，最后看细节流程的优化。2.如何对分布式存储的不同实现进行分类？
（1）布式存储的应用场景相对于其存储接口，现在流行分为三种:
- 对象存储: 也就是通常意义的键值存储，其接口就是简单的 GET、PUT、DEL 和其他扩展，如七牛、又拍、Swift、S3
- 块存储: 这种接口通常以 QEMU Driver 或者 Kernel Module 的方式存在，这种接口需要实现 Linux 的 Block Device 的接口或者 QEMU 提供的 Block Driver 接口，如 Sheepdog，AWS 的 EBS，青云的云硬盘和阿里云的盘古系统，还有 Ceph 的 RBD（RBD 是 Ceph 面向块存储的接口）
- 文件存储: 通常意义是支持 POSIX 接口，它跟传统的文件系统如 Ext4 是一个类型的， 但区别在于分布式存储提供了并行化的能力，如 Ceph 的 CephFS(CephFS 是 Ceph 面向文件存储的接口)，但是有时候又会把 GFS，HDFS 这种非 POSIX 接口的类文件存储接口归入此类。
（2）按照这三种接口和其应用场景，很容易了解这三种类型的 IO 特点，括号里代表了它在非分布式情况下的对应：
- 对象存储（键值数据库）：接口简单，一个对象我们可以看成一个文件，只能全写全读，通常以冷存储、大文件为主，要求足够的 IO 带宽。
- 块存储（硬盘）：它的 IO 特点与传统的硬盘是一致的，一个硬盘应该是能面向通用需求的，即能应付大文件读写，也能处理好小文件读写。但是硬盘的特点是容量大，热点明显。
因此块存储主要可以应付热点问题。
另外，块存储要求的延迟是最低的。 - 文件存储（文件系统）：支持文件存储的接口的系统设计跟传统本地文件系统如 Ext4 这种的特点和难点是一致的，它比块存储具有更丰富的接口，需要考虑目录、文件属性等支持，实现一个支持并行化的文件存储应该是最困难的。
但像 HDFS、GFS 这种自己定义标准的系统，可以通过根据实现来定义接口，会容易一点。
（3）在实现上述三类的存储方式的方面，主要有两层区别
- 系统的分布式设计：主从、还是全分布式或者是兼而有之，目前现在存储系统因为一致性的要求，以主从为主。
- 底层的单机存储：主要有3种类
（1）一种是依赖本地文件系统的接口，如 GlusterFS，Swift，Sheepdog，Ceph。
第一种依赖文件系统是因为分布式存储系统本身已经够复杂，实现者很难从上层一直到底层存储都去实现，而本地文件
系统已经是一个通用化并且非常成熟的实现，因此分布式存储系统绝大部分（上述提到的都应该是）都会直接依赖本地文件系统
（2）一种是依赖块接口的，目前只知道 Nutanix 是使用这个的。
第二种接口目前只知道 Nutanix 是支持的（传统的存储厂商的存储产品一般会使用这种方式），这种接口也就是比第一种
去掉了文件系统层，实现一个简单的物理块管理即可。
（3）最后一种是依赖键值接口的，目前应该只有 Ceph 是支持（Ceph 支持多种单机存储接口）。
第三种它的主要原因是“存储定义”和对象存储的普及，希望硬盘来提供简单的键值接口即可，如希捷的Kinetic API ，
Fusionio NVMKV ，这种接口另一方面是闪存厂商非常喜爱的，因为闪存的物理特性使得它支持键值接口比快接口容易得多，
目前 Ceph 是支持这种接口，而希捷和华为最近推出了 IP 硬盘，听说已经实现了 Swift 上的原型。
总结：
从这里可以发现，分布式存储系统是在传统的单机接口上重新包装了一层，然后实现三种类似的接口。（4）分布式存储的策略
- 策略方面，三副本、多 AZ 六副本和网络 RAID 都是一类的，它们都是指数据的分布策略来提供数据可用性。
（1）对于三副本、多 AZ 六副本的策略而言，数据的多个副本分布在所有服务器的几个中，也就是只要超过副本数的服务器挂掉，
存储系统就面临部分数据不可用的情况。
（2）网络 RAID 是为了避免这种情况，比如在 1000 台服务器的情况，将其分成 10 台一组的 100 组，这样同样是一份
数据（Data1）的三个副本都只属于某一个组，它不可用只当 1 组内（10 台）中超过 3 个台机器不可用时才会发生，这样概率会小非常多。
（3）EC 是一个类副本策略，它可以理解为增强版的复制，更少的副本可以达到更好的数据可用。（5）硬件对分布式存储的影响
- SSD，SAS，SATA 和内存的组合是为了提供数据访问的性能。
- 千兆、万兆甚至 Inifiniband (IB)是组合是为了提供网络传输的性能。
（6）其他补充
- 很多实现的细节其实是做的差不多的，eg：很多对象存储都会把小对象放到一些预分配的大块存储区域里，然后定期做 compaction，来提高存储效率、避免文件系统碎片等。
- 对于块服务，有些实现是比较简单直接的，直接把存储分成块，用户有申请，就调度到某几台机器上，分配一些块，组成卷给用户用，而有些实现是比较高层的，会先构建一个底层的分部式存储系统，然后再从中分配块给用户用。
- 对象存储和文件存储的区别
（1）首先对象存储和文件存储的区别是不大的，存储的都是一样的东西，只是抛弃了统一的命名空间和目录树的结构，
使得扩展起来桎梏少一些。
（2）独立的互联网存储服务一般都是做对象存储的，因为块存储是给计算机用的，对象存储是给浏览器等 HTTP 客户端用的。
独立服务所提供的存储系统，访问都来自互联网，自然是做对象存储；与之相对应，大部分类 AWS 的主机服务商都会提供一个
块存储服务搭配主机服务。
（3）同一个服务商同时提供两个服务是有好处的，除了提供的服务比较全这个优点以外，对象存储还可以支撑块存储的快照、
主机的系统镜像存储等应用，可以相互结合的。3.分布式存储中的“数据可靠性”是如何计算的？
- 实际上这个计算是需要依赖于存储系统本身的。
我们使用 Ceph，Ceph 的优势是提供了一个叫 CRush 算法的实现，可以轻松根据需要来规划数据的副本数和高可用性。 - 沿用文章中的可靠性定义，数据可靠性的计算涉及到以下几个量：
集群规模 - 总硬盘数目（L）
容错度（M）
修复速度（t）
单盘可靠性（p：在 t 时间内损坏的概率）- 我们这个概率的计算和 RAID 是类似的。
我们可以将 RAID 的概念延伸一下，其实 RAID 的本质就是 replication，通过多个副本来解决一个或者多个节点出问题造成的影响。
所以不管是本机的副本，还是跨网络或者跨地域的副本，本质上都是在用 replication 做冗余 - AWS 的两个主要资源层存储服务是 EBS 和 S3。
（1） EBS 承诺的是年平均故障率（AFR），一年中发生块设备故障而导致卷无法使用的概率，这个要求实际上不高的。
（2）后者是对象存储服务，强调数据可靠性，承诺 11 个 9 的 Durability，据说实际能达到更高；
参考：
虚拟座谈会：有关分布式存储的三个基本问题
