分布式存储的架构以及存在的问题和解决办法1

前言

分布式存储存在的风险，其实就是因为“共享”、“大数据量”、“高性能”和X86服务器+廉价的磁盘为载体之间的矛盾所产生的，不是有些读者说的“数据架构”的问题。其实任何存储都存在这个问题，只是分布式存储更严重。

本文其实是从主机的网络、磁盘的吞吐角度分析存在的风险，所以和用那个厂家的存储无关。

还有人说你是危言耸听，如果按照你说的，这么多人用了分布式存储有这样的地雷岂不是要炸飞？软件定义的东西其实有很多BUG，重要的是能发现问题，事先做好弥补或方案。

还有人说，分布式存储用到现在也不超过2年，发生你说的问题还早。但是我们已经发现问题了，不能搁置不管。钓鱼岛问题搁置了，现在还不是造成麻烦了吗？

抛砖引玉

存储最重要的指标是什么？

很多人包括存储专家都会认为是存储的性能指标，比如IOPS和吞吐量。但是我认为存储最重要的是数据的安全性。

一个跑的飞快的存储，突然数据丢失了，后果会怎么样？数据的丢失，对于任何系统来说，都是灭顶之灾。

所以，不管什么样的存储，数据的安全可靠都是第一位的。

原来传统的存储使用了专用硬件，从可靠性上有比较高的保证，所以大家首先会关注性能指标。但是用X86为基础的SRVSAN的可靠性就不容乐观。

为什么说传统存储这个问题不是太突出呢?

除了专用设备外，还有应用场景和数据量不同等原因。在传统行业如电信、银行原来的系统建设是烟囱模式。不但网络是独立一套，存储也是。

往往是数据库服务和日志记录，用2台服务器和8个端口的小光交相连，小光交下只挂一个存储。数据量也没有这样大，存储的容量也在5T以下。这样存储的数据迁移是很容易和快速的，方法也很多。

由于是专用存储，所以完全可以采用“非在线”的手段，数据量也不大，可以在夜深人静的时候停机完成。

进入云计算时代，存储是共享的，数据是应用可靠，提供者不可控，数据量海量增加……传统的方法失灵了。(可见顾炯的云世界的“资源池内存储特点”的文章)

我们在2014年下半年，开始搭建以X86为载体的分布式块存储，经过严格的测试，在同年底投入商用，是业界首个商用的软件定义的分布式存储，当时各种媒体都争相报道。

到现在为止已经商用了近2年，存储运行稳定，表现优良。并从原来2P裸容量扩容到4.5P。

但是近段时间我却越来越担心，因为SRVSAN与生俱来的数据安全隐患，一直被人忽视了，而且主流厂家也没有意识到这个问题。如果这个隐患在若干年以后爆发，会发生重大性系统故障。

其实我在写这篇文章前2个月，我已经将这个担忧和想法告诉了现有分布式块存储的产品线总经理，得到他的重视，已经在弥补了。很多软件定义的东西，就怕想不到，突然发生了，想到了就会有相应的解决方案。

存储这个东西，大部分读者并不是太了解，从比较基础知识开始写，并引出问题和大家一起讨论解决的办法。盘算了一下大致分为七个部分，由于篇幅限制，在本篇将先介绍前三部分：

一、存储类型

二、文件系统

三、存储介质

四、Raid和副本

五、SRVSAN的架构

六、SRVSAN的安全隐患

七、解决的方法

一、存储类型

一般情况下，我们将存储分成了4种类型，基于本机的DAS和网络的NAS存储、SAN存储、对象存储。对象存储是SAN存储和NAS存储结合后的产物，汲取了SAN存储和NAS存储的优点。

图1

我们来了解一下应用是怎么样获取它想要的存在存储里的某个文件信息，并用大家熟悉的Windows来举例，如图1。

• 1、应用会发出一个指令“读取本目录下的readme.txt 文件的前1K数据”。

• 2、通过内存通信到目录层，将相对目录转换为实际目录，“读取C:\ test\readme.txt文件前1K数据”

• 3、通过文件系统，比如FAT32，通过查询文件分配表和目录项，获取文件存储的LBA地址位置、权限等信息。

文件系统先查询缓存中有没有数据，如果有直接返回数据；没有，文件系统通过内存通信传递到下一环节命令“读取起始位置LBA1000,长度1024的信息”。

• 4、卷（LUN）管理层将LBA地址翻译成为存储的物理地址，并封装协议，如SCSI协议，传递给下一环节。

• 5、磁盘控制器根据命令从磁盘中获取相应的信息。

如果磁盘扇区大小是4K,实际一次I/O读取的数据是4K，磁头