正在阅读：从GlusterFS看去中心存储的设计难点从GlusterFS看去中心存储的设计难点

本文主要通过GlusterFS来讨论无中心节点设计中普遍遇到的一些难点，区块链未来的发展在存储设计上可能遭受同样的问题，这点在私有链上可能更加突出，仅作为参考

GlusterFS是Scale-Out存储解决方案Gluster的核心，它是一个开源的分布式文件系统，具有强大的横向扩展能力，通过扩展能够支持数PB存储容量和处理数千客户端。GlusterFS借助TCP/IP或InfiniBandRDMA网络将物理分布的存储资源聚集在一起，使用单一全局命名空间来管理数据。GlusterFS基于可堆叠的用户空间设计，可为各种不同的数据负载提供优异的性能。

GlusterFA特点

GlusterFS作为一中高弹性的分布式存储，它在设计上具有以下几个特点。

1、扩展性和高性能

GlusterFS利用双重特性来提供几TB至数PB的高扩展存储解决方案。Scale-Out架构允许通过简单地增加资源来提高存储容量和性能，磁盘、计算和I/O资源都可以独立增加，支持10GbE和InfiniBand等高速网络互联。Gluster弹性哈希(Elastic Hash)解除了GlusterFS对元数据服务器的需求，消除了单点故障和性能瓶颈，真正实现了并行化数据访问。

2、高可用性

GlusterFS可以对文件进行自动复制，如镜像或多次复制，从而确保数据总是可以访问，甚至是在硬件故障的情况下也能正常访问。自我修复功能能够把数据恢复到正确的状态，而且修复是以增量的方式在后台执行，几乎不会产生性能负载。GlusterFS没有设计自己的私有数据文件格式，而是采用操作系统中主流标准的磁盘文件系统(如EXT3、ZFS)来存储文件，因此数据可以使用各种标准工具进行复制和访问。

3、全局统一命名空间

全局统一命名空间将磁盘和内存资源聚集成一个单一的虚拟存储池，对上层用户和应用屏蔽了底层的物理硬件。存储资源可以根据需要在虚拟存储池中进行弹性扩展，比如扩容或收缩。当存储虚拟机映像时，存储的虚拟映像文件没有数量限制，成千虚拟机均通过单一挂载点进行数据共享。虚拟机I/O可在命名空间内的所有服务器上自动进行负载均衡，消除了SAN环境中经常发生的访问热点和性能瓶颈问题。

4、弹性哈希算法

GlusterFS采用弹性哈希算法在存储池中定位数据，而不是采用集中式或分布式元数据服务器索引。在其他的Scale-Out存储系统中，元数据服务器通常会导致I/O性能瓶颈和单点故障问题。GlusterFS中，所有在Scale-Out存储配置中的存储系统都可以智能地定位任意数据分片，不需要查看索引或者向其他服务器查询。这种设计机制完全并行化了数据访问，实现了真正的线性性能扩展。

5、弹性卷管理

数据储存在逻辑卷中，逻辑卷可以从虚拟化的物理存储池进行独立逻辑划分而得到。存储服务器可以在线进行增加和移除，不会导致应用中断。逻辑卷可以在所有配置服务器中增长和缩减，可以在不同服务器迁移进行容量均衡，或者增加和移除系统，这些操作都可在线进行。文件系统配置更改也可以实时在线进行并应用，从而可以适应工作负载条件变化或在线性能调优。

6、基于标准协议

Gluster存储服务支持NFS, CIFS, HTTP, FTP以及Gluster原生协议，完全与POSIX标准兼容。现有应用程序不需要作任何修改或使用专用API，就可以对Gluster中的数据进行访问。这在公有云环境中部署Gluster时非常有用，Gluster对云服务提供商专用API进行抽象，然后提供标准POSIX接口。

去中心化存储面临的主要问题

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