分布式存储（姚文辉）
1.大数据对分布式存储的需求
- 存储容量（>100PB）
- 高吞吐量（1PB sort < 2小时 350GB/每秒的吞吐量）
- 高可靠性（8个9）
- 服务高可靠性（99.95%时间可用）
- 运维简单
- 成本低，廉价pc服务器，数据压缩，混合存储。
2.大规模分布式存储系统的挑战
大规模分布式存储中小概率事件变为常态，如何高效的处理这些小概率事件是分布式系统工程中的巨大挑战。
- 磁盘机器损坏：磁盘损坏率大概为4%，机器宕机率为1%%，5000台机器的集群，磁盘机器损坏就会很常见。一旦出现宕机，IO流量需要自动导向到其他机器上的存储节点上。
- 网络故障：连接meta管理节点的网络发生异常，会导致“脑裂”现象，由于脑裂导致导致心跳异常，Meta服务自动切换的另外的机器，切换期间多个节点并行对外提供meta服务，会导致新写入的数据在老的meta管理节点不可见而作为垃圾数据删除，这种异常需要利用完善可靠的分布式协议来避免。
- 电源故障：数据副本跨机架，在架构设计上和物理部署上要求分布式存储系统需要有跨数据中心和地域的能力。
- 系统异常：时钟不一致等，NTP漂移等情况要求系统逻辑不能强依赖于时间精度和时钟同步，需要重新设置虚拟时钟来保证时序，达到数据一致性。
- 热点：通常会采用资源隔离和限制的方法来避免一个业务的计算过度消耗资源，同时分布式系统的客户端需要有主动绕过热点机器的功能来避免热点给整个系统带来的影响。
3.典型的分布式存储系统
HDFS：http://www.cnblogs.com/wxquare/p/4846438.html
ceph：http://docs.ceph.com/docs/v0.80.5/
4.分布式系统重要功能设计要点剖析
- 读写流程：链式写和主从写
第一步client进程在Master上打开文件写，在请求中传输文件名作为参数，在返回结果中会包含数据写入位置信息；第⼆步，client端以链式传输的方式将数据写入到多个CS中，顾名思义，数据会在一个传输链条上被传递。首先client将数据传输给CS1，CS1将数据传输给CS2，以此类推，直到最后一个CS收到数据，并返回给前一个链条节点CS，最终数据写入成功的返回传递给client端，表明数据已经写入成功，这样就完成了一次数据写入操作。从写入流程上来看，这写入过程中，每个数据经过的结点都只消耗了一份网络带宽，可以充分利用网络资源；对于有大量数据写入的应用，例如数据导入作业可以达到更高的流量。但从数据写入的返回消息上来看，返回链路相对较长，会给数据写入的latency有较大影响。
链式写入模式比较适合于数据流量大，但是不注重latency的业务；上图所示的主从模式，比较适合于数据写入频繁要求低延迟的业务。 在此图中省略了文件打开流程的描述，并且数据接收的对应的CS会分成两种，一种为Primary，作为写操作的协调者和接收者，另一种Replica只作为数据的接收者。client数据会首先发送给Primary，Primary将数据接收并转发给另外两台Replica，并等待所有的拷贝都已经合并入内存cache后，由Primary 返回client一个确认消息，此时数据并没有确认写入成功；等所有数据从内存中刷入到物理磁盘后，Replica将刷入磁盘成功的消息发送给Primary，并且Primary也写入成功后将最终数据写入成功的确认消息返回给client。 从上面的写入过程分析，Primary的网络流量是两份数据流量，在极限情况下也只能利用网络流量的一半，所以若果是数据导入的大流量业务不适合。单从数据写入成功的确认过程来看，写入3个副本的情况下只需要两跳即可到达Client，这样网络延迟相对减小，对应写入的latency降低。
2. IO QOS (服务质量)
问题：当多个用户访问存储系统时如何保证优先级和公平性
阿里盘古文件系统中采用的方案：
- 将IO请求按优先级分成多个类别，每个类有相应的权重表示该类请求占用IO带宽的比例
- IO请求根据分类放入相应的队列，队列内根据队列限制和任务做调度和丢弃
- 调度器根据相应权重从队列取出请求进行调度
3.数据正确性：checkSum
在集群中网络、内存、磁盘和软件都有可能导致数据错误，那么在分布式存储系统中如何保证海量数据中没有任何数据错误呢？ 数据应该给全程保护，否则任何一个环节出现问题导致数据错误未被检查到，都可能会导致数据出错。被保护的数据至少应该具有数据、数据长度和CRC校验值这样的三元组，而且在任何后续的处理中，都应该先对数据进行处理后，再校验这个3元组的一致性，来保证刚被处理过的数据是正确的。
4.数据可靠性（Replication）
当机器/磁盘出现异常，应通过其它副本快速恢复，充分利用多台机器的复制带宽，但是实际中，应考虑复制的优先级以及复制的流量控制。
5.节点的负载均衡（Rebalance）
当有新的机器/磁盘上线时，迁移数据保证负载均衡。充分利用多台机器的复制带宽，同上，实际中，也需要考虑控制因为负载均衡而导致复制优先级和流量控制。
6.垃圾回收（Garbage collection）
垃圾回收在分布式系统中就好像我们平时对屋子的整理过程，将无用的扔掉给有用物品留下足够的空间.
7.纠删码 (Erasure coding)
纠删码能降低系统的存储代价，但是增加了计算和恢复的代价。
8.元数据的高可用性和可扩展性
通常分布式存储中meta管理节点不多，但是数据读取过程都依赖meta节点，因此元数据管理需要做到高可用性非常重要。
通常的做法是可以将这些节点做成多个备份，保证在一个备份出现问题的时候，仍然可以提供服务。但是多个备份间需要维护数据一致性，防止服务切换造成的数据不一致或者丢失。
高可用性方案：
- 方案一：HDFS中元数据的高可用性方案是引入了分布式锁服务ZooKeeper，每个NameNode的FailoverController来维护分布式锁状态，在出现锁丢失的情况下，触发主备切换。主NameNode将操作日志写入到共享数据存储的设备上，这样的设备可以是有DRBD功能的磁盘或者NFS系统。 这个实现方案相对简单，因为交复杂的功能都放到了锁服务和共享存储系统中。这样的做法也是非常经济实惠的，复杂性均由分布式系统的单个模块来维护，其他服务进行依赖的做法降低了软件的实现难度和维护工作量。
- 方案二：阿里的盘古分布式文件系统Meta server之间采用了Paxos的特化Raft实现数据选举和同步，可以在任意多个master的备份。
- 方案三：在Ceph系统的元数据管理模块MDS从原理上来说使用了共享存储，每个MDS有一个Standby进程作为热备。但是其独特之处在于是利用了OSD同Ceph monitor组成的RADOS最为共享存储，这样的实现方法即保证了元数据管理的高可用，又提供了无限可扩展的能力，同时可以不依赖于其他系统做到了独立自包含。
可扩展性方案：
- 方案一：HDFS的可扩展性，Namespace切分的Fedeation。在HDFS Federation中NameNode的扩展性依赖于目录树的静态切分，每个目录子树被称为一个Volume，并将切分后的Volume分配到不同的NameNode上。DataNode则作为数据存储池，被所有的NameNode共享使用。为了让客户端可以找到某棵树中的节点，在client端需要加载ClientSideMountTable，这里记录了目录树同NameNode的对应关系，用户使用文件名访问元数据时，客户端首先用文件名从MountTable中获取NameNode的服务端口后，再发送元数据请求。 Federation的这种做法简单高效，静态划分的方法需要提前对各个NameNode未来元数据量有比较准确的估计，否则很容易造成各个NameNode间元数据的不平衡，给整个存储系统带来瓶颈。 盘古系统采用了同HDFS一样的解决方案，在实现过程中对应每个HDFS中的NameNode会部署一组盘古多master。盘古Federation除了用MountTable让用户透明访问系统外，还提供了新的访问方式。用户可以在文件名前指定Volume名称，这样可以绕过mount table的访问直接请求到某组盘古master上，这个功能可以有效防止集群中大量进程短时间启动时集中获取mount table带来的流量冲击。为了应对元数据不均衡的问题，盘古提供了在两个Volume间的元数据迁移工具。
- 方案二：Ceph系统的MDS的扩展性用动态分裂功能实现，分裂依据是目录或者文件的请求频率。当用户请求某个路径的时候，将路径中的每个目录以及最终末端的节点或者目录上的请求统计值增加，然后通过定期来计算每个MDS中目录的请求频率来决定是否已经超过了MDS的负载而需要动态分裂。分裂过程中源MDS会元信息发送给目标MDS，并分别记录迁移日志。这种动态分裂的方式可以有效解决局部访问热点带来的性能瓶颈，在元数据规模和处理能力方面都做了扩展，是比静态划分方法更好的设计和实现方式。
9.混合存储
混合存储原因是要根据不同存储介质合理使用，提高存储系统性能的同时又不会太大的增大成本。例如HDFS中可以将一个副本放在SSD中，其他副本放在此盘上，Heterogeneous Storages in HDFS，http://hortonworks.com/blog/heterogeneous-storages-hdfs/；阿里的盘古文件系统中，后台程序定期将SSD上记录的多次随机写合并成一次批量写，将数据写入到HDD的chunk replica文件中，这样能在一定程度上降低写的延迟；
RAMCloud内存存RAMCloud,https://ramcloud.atlassian.net/wiki/display/RAM/RAMCloud
RAMCloud内存存储方案同盘古的混合存储方案比较接近，最明显的不同点是将SSD换成了内存存储。 当数据写入是，所以数据均写入到内存，为了高效利用内存，采用了连续记录日志的方式将数据存放在内存中。同时将数据按照数据所属应用进行划分，分别建立索引，方便对数据进行随机访问。由于内存存储的易失性，所以需要将内存中的数据以异步方式保存到磁盘中。 这种实现策略非常适用于分布式的cache服务，可以充分利用内存的高带宽和低延迟，但是在分布式环境中需要同时配备高速网络，否则其威力得不到发挥。
从上面的例子可以看到，混合存储技术基本是利用高性能小容量高成本的介质来作为低性能大容量低成本的cache来满足业务需求。
|
磁盘 |
SSD |
内存 |
|
|
容量 |
1–4 TB |
400–800 GB |
24–128 GB |
|
延时 |
10 ms |
50–75 us |
100 ns |
|
吞吐 |
100–200 MB/s |
400 MB/s |
20 GB/s |
|
成本 |
0.06 $/GB |
1 $/GB |
10 $/GB |
