分布式存储系统设计的若干问题（二）

问题5：快照实现方案

一个现代的存储系统，快照已经成为了必选项。快照除了直接用于保存系统的中间状态（比如VM的中间状态），还是其他功能包括克隆，备份，容灾功能的基础。

快照就是的功能就是给存储拍一个照片，记住某个时刻的数据内容以备随时提取和回退。后面无论对数据再做读写操作，快照的内容总是保持不变。从这个原理上讲，如果在用户发出做快照命令时，迅速把某个volume的数据复制一份，这就是做了快照了，这个基本的做法就是SNIA定义的Split mirror。然而一个存储系统的实现往往不能采取这么简单粗暴的方法，一是性能受不了，这个方法要复制整个volume的数据，volume现在越来越大，甚至上百TB基本，这样的快照怕是和快字不沾边了。二是容量受不了，用复制的方法做快照没做一次就会多占用一份空间，在云计算时代讲究的是资源充分利用，用这个方法经济上不划算。

现代的存储系统实现快照基本都是In Place，不会把数据复制到存储系统以外的其他空间。方法上包括

• COW (Copy on Write): 这种方式是最容易理解的，即写入的时候判断如果是快照，就把快照数据复制一份到新的位置。而保持volume最新的数据位置不变。
• ROW (Redirect on Write)： 这种方式相对COW，写入的时候判读如果是快照，就把新数据写入到新分配的位置，而让快照数据留在旧的位置
• Append Only Log： 这种模式在平时写入时就避免了覆盖写，每次写入都会分配新的位置，即使非快照写。在这个基础上，当需要做快照时，只需要把快照时刻的数据尾的位置记录下来就可以。
• 其他的一些方法，比如CDP

问题6: 故障处理

在一致性环节选定了存储系统的CAP取舍(AP或者CP）后，就要考虑如何在各种故障时保证选定的目标。常见的故障包括：

• 磁盘故障，包括磁盘控制器错误，介质错误等。对于软件系统可能得到明确的错误通知（IO下发后磁盘或者驱动返回了错误码）也可能得不到任何通知。在得不到任何通知的情况下，这种错误统一的当作IO超时处理。
• 网络故障，包括网卡坏了，交换机坏了，网线断了等。对于软件系统同样要做好两手准备，得到了明确的故障通知或者得不到通知。
  网络是无状态部件，这点和磁盘故障不同。网络可以通过冗余降低故障的影响，故障后恢复的成本也比较低。然而因为网络的规模大（遍布整个数据中心），结构复杂（网卡，网线，多级交换机，众多的接插件），因而是故障率高发的模块。
• 掉电故障，掉电故障包括单个服务器节点掉电和整个存储集群掉电。发生掉电时正在执行中的IO的最终状态是不确定的，也就是会存在数据的不一致。单个节点掉电后要能保证系统的正常对外服务以及恢复供电后的数据恢复；整个集群掉电后不要求继续服务，但要提供手段在供电后恢复集群的数据一致。
• 软件故障，软件故障是未知的软件bug引起的IO超时，IO失败甚至是数据错误。软件bug包括存储系统本身的，也可能是来自第三方比如操作系统，依赖的第三方库。因为bug的种类五花八门而且未知（已知的bug在发布时必然会修好了），很难提前针对特定的故障给出特定的处理方法。这种情况下，存储系统要能提供基本的数据检查能力，检查软件故障是否造成了数据不一致并进行修复。

其他的一些故障，比如CPU坏了，内存坏了， 其行为都可以用上面的某种故障类型来涵盖。
一个存储系统的底线是保证不丢失数据，即使是发生了上面的各种故障（整个系统被物理消灭除外）。作为分布式系统还要保证在发生单点故障时持续提供服务。

问题7：recovery

这里说的recovery是指当系统出现副本间数据不一致时，重新恢复到一致的过程。而不是说类似“从备份系统恢复数据到主存储系统”，或者“从快照恢复数据”等。
当系统发生故障时，往往会导致副本间数据不一致。一个成熟的recovery机制需要考虑下面的因素：

• recovery期间不能中断用户IO，这一点往往是recovery的难点所在
• recovery要尽可能快，降低新故障发生的机率
• recovery对QoS的影响，简单说就是对现有用户IO的性能冲击
• recovery的可控性，是否可以控制recovery的执行时间，带宽占用

问题8： 扩容与数据均衡

分布式存储的一个显著优势是其scale out能力。因此扩容能力是分布式系统必须具备的。扩容之后随之要面临的问题就是数据均衡。
对于扩容需要考虑的问题是：

• 集群管理，新加入的节点如何和现有节点互相发现，自动加入还是手动触发。
• 如果集群还有进一步的资源分组，那么分组是由集群管理器决定，还是节点自身的配置决定
• 新节点加入后必须和集群中其他节点进行数据均衡后才能开始接受普通IO，还是可以不进行数据均衡就立刻可以分配承接普通IO。这一点对于大型的分布式存储至关重要，因为均衡或多或少总是会对系统的运行造成冲击，要尽量选择无需均衡就可以将新节点投入使用的方法。这样当用户业务繁忙而容量又达到高位时就不会因为扩容而导致业务受影响。

对于数据均衡需要考虑的问题很大程度上和recovery类似，

• 均衡期间不能中断用户IO
• 均衡对QoS的影响，简单说就是对现有用户IO的性能冲击
• 均衡的可控性，是否可以控制均衡的执行时间，带宽占用