无中心的存储设计：GlusterFS

http://blog.qiniu.com/archives/2546

无中心的存储设计：GlusterFS

目前，GlusterFS在互联网行业中用的较少，在大型计算机中用的较多。它在设计上具有以下几个特点。

兼容POSIX文件系统：单机上的应用程序无需修改就可以放到GlusterFS上运行。

没有中心节点：不存在单点故障和性能瓶颈。

扩展能力：因为没有中心节点，所以GlusterFS的扩展能力无限，扩展多少台服务器都没有问题。

我们不讨论POSIX兼容的优劣,集中通过GlusterFS来讨论无中心节点设计中普遍遇到的一些难点。

1. 坏盘修复。无中心暗示着可通过key推算这个key的存储位置。但是，磁盘坏了（单盘故障）怎么办呢？直接的处理方式是去掉坏盘，换上新盘，将这些数据拷贝过来。这样的处理方式在小型系统上非常适用。但是一个4T的Sata盘，即使在千兆网下写入速度也只能达到100MB/s，修复时间会是11小时。考虑到一般的存储满指的是全部存储量的80%，那么修复时间将达到8到9个小时，所以不适合用于大型系统。大型系统磁盘多，每天会坏很多块磁盘。如果磁盘是同一批购买的，由于对称设计，读写的特性很相似，那么在坏盘修复的八九个小时里，其他磁盘同时坏的概率非常高。这时，整个系统的可靠性会比较低，只能达到6个9或7个9。如果想达到更高的可靠性，只能通过疯狂增加副本数这种会让成本大量提高的方法来解决。

GlusterFS本身不用这种修复设计，它的修复方式是在读磁盘时发现有坏块就触发修复，但这种设计的修复时间会更长。该如何回避掉这个问题呢？最简单的方法是将磁盘分成多个区，确保每个区尽量小。例如，将4T盘分成50个区，每个区只有80GB，并且记录各个区的一些元信息。在我们从key推算存储位置时，先计算出这个
key 所在区的编号，再通过刚才的元信息获得这个区对应的机器、磁盘和目录。这样带来的好处是，在磁盘坏了的时候，不用等换盘就可以开始修复，并且不一定要修复到同一块磁盘上，可以修复到有空间的多块磁盘上，从而得到一种并发的修复能力。如果将4T盘分成50个区（每个区80G），那么修复时间就可以从8到9个小时缩减到13分钟左右。

2. 扩容。如前所述，在无中心节点的设计中，从key可以推算它存储的位置，并且我们要求key是均匀Hash的。这时，如果集群规模从一百台扩容到二百台，会出现什么问题呢？Hash是均匀的，意味着新加的一百台机器的存储负载要和以前的一致，有一半的数据要进行迁移。但集群很大时，数据迁移过程中所花的时间通常会很长，这时会出现网络拥塞。同时数据迁移过程中的读写逻辑会变得非常复杂。解决方法是多加一些测试，改善代码质量，不要出Bug。还有一种方法是，保持容量固定，尽量不要扩容，但这与互联网的风格（从很小的模型做起，慢慢将它扩大化）不相符。

3. 不支持异构存储。提供云存储服务的公司必然会面临一个问题，有很多客户存储的文件非常小，而另外很多客户存储的文件非常大。小文件通常伴随着很高的IOPS需求，比较简单的做法是将Sata盘（100IOPS）换成SAS盘（300
IOPS）或者SSD盘（10000 IOPS以上）来得到更高的IOPS。但是对于无中心存储，由于key是Hash的，所以根本不知道小文件会存在哪里，这时能提高IOPS的唯一办法是加强所有机器的能力。例如，每台机器中将10块Sata盘、2块SAS盘和1块SSD盘作为一个整体加入缓存系统，提升系统的IOPS，但整体的成本和复杂性都会增加很多。另外一种方式是拼命扩大集群规模，这样整体的IOPS能力自然会比较高。

类似的异构需求还包括某些客户数据只想存两份，而其他客户数据则想多存几份，这在无中心存储中都很难解决。

4. 数据不一致的问题。比如要覆盖一个key，基于Hash意味着要删除一个文件，再重新上传一个文件，新上传的文件和之前的一个文件会在同一块磁盘的同一个目录下使用同样的文件名。如果覆盖时出现意外，只覆盖了三个副本中的两个或者一个，那么就很容易读到错误的数据，让用户感觉到覆盖没有发生，但原始数据已经丢失了。这是最难容忍的一个问题。解决方案是在写入文件时，先写一个临时文件，最后再重命名修改。但由于是在分布式架构中，且跨机器操作，会导致逻辑的复杂性增加很多。

简单总结一下，以GlusterFS为代表的无中心设计带来的一些问题如下图所示。