分布式存储的元数据设计.pdf

分布式存储的元数据设计 李道兵 七⽜云存储 2015-04 北京 引⼦ • ⾯试新⼈时最经常被问到的⼀句话：七⽜的云存储真 的是⾃⼰写的么，是不是基于 Hadoop 的？ Outline • ⽆中⼼的存储设计: glusterfs • 有中⼼的存储设计：hadoop • 基于数据库的存储设计: gridfs, hbase • 绕过问题的存储设计: fastdfs glusterfs • 设计⺫标 • 兼容 POSIX ⽂件系统: 你的应⽤程序⽆需修改就可以 放到 glusterfs 上来运⾏ • ⽆中⼼节点: 性能瓶颈没有了，单点故障也没有了 • 扩展能⼒: ⼤容量存储都需要这个 • 我们在这⾥不讨论 POSIX 兼容的优劣，集中通过 glusterfs 来讨论⽆中⼼节点设计中普遍遇到的⼀些难点 glusterfs • glusterfs 是⼀系列⽆中⼼存储的设计的代表 • ⽆中⼼暗⽰着我们可以通过内容的 key 推算出来这个 key 的存储位置 • 在绝⼤部分实践中，在这种设计下如果出现单盘故障，处理模式如下 • 去掉坏盘，换上新盘 • 从⽼盘拷⻉数据到新盘 • 这个模式最⼤的问题是修复时间，4T盘在 100MB/s 的修复速度下需要 ⾄少 11 个⼩时，这么⻓的修复时间会导致数据的可靠性降低（在这 11个⼩时内另外两块盘的损坏概率） • 另外⼀种修复模式是在读的时候发现有坏块，然后触发修复，在这种模 式下修复只会更糟糕。 glusterfs • 如何回避掉这个问题呢？ • 引⼊中间层记录分区和物理设备的关系，这样磁盘 损坏不⽤等换盘就可以开始修复 • ⼀个磁盘分成多个区，每个区可以到不同的盘上去 修复，那么可以⼤幅度缩短修复时间，⽐如分到 50 个区（每个区 80GB), 那么修复时间就可以缩 ⼩到 13分钟左右。 glusterfs • 扩容 • 在⽆中⼼设计中，扩容往往伴随着数据的再平衡， 再平衡会带来如下的挑战 • ⺴络拥塞：可以使⽤独⽴的迁移⺴络来改善 • 迁移时间⻓且迁移期间数据读写逻辑变得更复杂 ：多加测试改善代码质量 glusterfs • 不⽀持异构存储 • ⽐如⼩⽂件经常伴随着很⾼的 iops 需求，针对⼩⽂件我们可 以引⼊SAS或者SSD盘来得到更⾼的 iops, 但对于⽆中⼼存储 来讲，这种⽅法很难实施。 • 类似的异构需求还包括某些客户数据只想存两份，⽽其他客 户数据则想多存⼏份的情况，这些在⽆中⼼存储中都是很难 解决的。 • ⼩⽂件的问题针对读取的部分可以通过缓存层来改善，但对 于⾼频率的写⼊没有太好的解决⽅案 • 这⼉也存在⼀个基于 hash 碰撞的攻击⽅案，不过影响不⼤。 glusterfs • 数据不⼀致的问题 • ⽐如我们要覆盖⼀个 key ，但在覆盖过程中出现意 外，导致只覆盖了三个副本中的两个或者⼀个。这 个时候就很容易读到错误的数据。 • 在写⼊⽂件时，先写临时⽂件，最后再重命名能改 善这个问题，但仍然不完美。 glusterfs • 问题总结 • 坏盘修复问题：元数据+分区可以改善这个问题 • 扩容动作⼤: 忍 • ⼩⽂件⾼IOPS: 劣势，集群⾜够⼤的话可以靠规模 来抗住 • 数据不⼀致的问题: 复杂度会变⾼