存储设备以及主流分布式存储系统介绍

一、存储设备介绍

存储到今天为止，我们并不陌生，我们在使用的任何一台计算机其内部必须要有一块磁盘设备，这其实就是一种存储设备，对于单机为例，我们必须有一种存储设备来帮助我们进行数据的持久化存储；目前最常见的存储协议又分为如下：

• 接口协议：IDE、SATA、SCSI、SAN、USB
• DAS设备：直接接入主板；称为直接附加存储（计算机磁盘）
• NAS：网络附加存储
  • NFS：不在本机，运行于单独的服务器上，然后挂载到本机文件树上某一挂载点上，这样就可以直接使用外部的存储空间
  • CIFS：通用 Internet 文件系统 (CIFS) 协议，这是一种跨平台、独立于传输的协议，它为客户端系统提供一种机制，以使用服务器系统通过网络提供的文件和打印服务，由微软使用。说明：CIFS采用C/S模式，基本网络协议：TCP/IP和IPX/SPX；是用于互联网的SMB协议版本
  • 网络附加存储的特点：大多数都是文件系统接口，例如NFS，本身就是一个文件系统，然后通过网络NFS接口在用户空间输出完成之后，我们在客户端基于内核级的NFS模块实现与远程主机进行通信从而实现使用远端存储空间。但是网络原文链接：https://dqzboy.com附加存储我们无法再一次对其进行格式化、分区、创建存储块等操作。（属于文件系统级别）

• SAN：存储区域局域网络（也属于网络存储）
  • SAN提供的接口是块级别的接口，这个与NAS不同，所以SAN使用到的协议都是SCSI协议，SCSI协议与网络TCP/IP协议很像，但是SCSI协议只是用来传输数据存取操作的。由于SCSI本身底层使用的物理传输接口传输距离有限，所以下面两种就是对SCSI使用的物理层的传输信道通过另外的信道(类似隧道)进行传输：
    • FC SAN：借助于分布式光纤通道来传输SCSI协议
    • iSCSI：利用Internet来传输SCSI协议
  • 缺点也是显而易见，对网络带宽要求很高
  • 速度、性能和稳定性都比IDE要好

SCSI协议也是分层的，跟我们的网络TCP/IP很相像，只不过SCSI协议只是用来传输所谓的数据的存取操作。SCSI协议也有物理层、传输层(类似于我们的网络协议一样)，还有像应用层，它的应用的话可能就是高级指令、低级指令这些存取指令。它的物理层早期都是使用SCSI那个并行的线缆传输SCSI协议信号的方式来实现的。协议分层设计，也就意味着某一层是可以被替代的，所以就有人将底层物理层的协议替换成其他协议，例如通过光纤，Internet(以太网)来传输SCSI协议，从这个角度来讲，它们只不过是把SCSI协议底层的物理传输接口改换成了另外一种传输信道(承载机制换成另外一种)进行传输。

SCSI协议只能通过SCSI线来传输，距离是很有限的；如果使用光纤那就是几十公里的距离了，如果使用internet来传输，可以跨越互联网。

企业中使用存储按照其功能，使用场景，一直在持续发展和迭代，大体上可以分为四个阶段：

• DAS：Direct Attached Storage，即直连存储，第一代存储系统，通过SCSI总线扩展至一个外部的存储，磁带整列，作为服务器扩展的一部分；
• NAS：Network Attached Storage，即网络附加存储，通过网络协议如NFS远程获取后端文件服务器共享的存储空间，将文件存储单独分离出来；
• SAN：Storage Area Network，即存储区域网络，分为IP-SAN和FC-SAN，即通过TCP/IP协议和FC(Fiber Channel)光纤协议连接到存储服务器；
• Object Storage：即对象存储，随着大数据的发展，越来越多的图片，视频，音频静态文件存储需求，动仄PB以上的存储空间，需无限扩展。

存储的发展，根据不同的阶段诞生了不同的存储解决方案，每一种存储都有它当时的历史诞生的环境以及应用场景，解决的问题和优缺点。

• DAS 直连存储服务器使用 SCSI 或 FC 协议连接到存储阵列、通过 SCSI 总线和 FC 光纤协议类型进行数据传输；例如一块有空间大小的裸磁盘：/dev/sdb。DAS存储虽然组网简单、成本低廉但是可扩展性有限、无法多主机实现共享、目前已经很少使用了。
• NAS网络存储服务器使用TCP网络协议连接至文件共享存储、常见的有NFS、CIFS协议等；通过网络的方式映射存储中的一个目录到目标主机，如/data。NAS网络存储使用简单，通过IP协议实现互相访问，多台主机可以同时共享同一个存储。但是NAS网络存储的性能有限，可靠性不是很高。
• SAN存储区域网络服务器使用一个存储区域网络IP或FC连接到存储阵列、常见的SAN协议类型有IP-SAN和FC-SAN。SAN存储区域网络的性能非常好、可扩展性强；但是成本特别高、尤其是FC存储网络：因为需要用到HBA卡、FC交换机和支持FC接口的存储。
• Object Storage对象存储通过网络使用API访问一个无限扩展的分布式存储系统、兼容于S3风格、原生PUT/GET等协议类型。表现形式就是可以无限使用存储空间，通过PUT/GET无限上传和下载。可扩展性极强、使用简单，但是只使用于静态不可编辑文件，无法为服务器提供块级别存储。

综上、企业中不同场景使用的存储，使用表现形式无非是这三种：磁盘（块存储设备），挂载至目录像本地文件一样使用（文件共享存储），通过API向存储系统中上传PUT和下载GET文件（对象存储）。

机械硬盘：机械硬盘在接口上采用的还是老式的、速度较慢的SATA接口，且由于盘片为圆形，所以形状大小也就受到了限制

SSD硬盘：SSD硬盘也从之前的SATA协议到目前的PCIe和NVME协议，IO能力有了数十倍的提升，而传统的IDE设备也就100 IOPS(理论值，每秒100 IO)；使用SATA接口的固态硬盘IOPS在500左右，而采用最新的NVME接口的固态硬盘的IOPS在2000-4000不等

二、分布式存储介绍

分布式存储简单来讲就是通过计算机网络连接大量的物理节点，将不同的机器、不同的磁盘、不同逻辑分区的数据组织在一起，提供海量的数据存储(一般是PB级别，1PB=1024TB)。

分布式存储系统不但提高了系统的可靠性、可用性和存取效率，还易于扩展。同时，可以将这些分散的存储设备构建成一个虚拟的大存储池，供上层应用来使用。

分布式存储最早是由Google GFS的论文(大概是2005年发布的，论文翻译版)中提出，由Hadoop参考Google GFS论文实现了开源版本的GFSHDFS

• 元数据：NameNode(名称服务器)，存储路由信息；元数据是非常密集但又很小的IO请求，但是为了达到高性能高IO，通常会先在内存当中存储，然后通过机制实现高效的存储在磁盘(持久化)
• 数据：DataNode，存储我们的业务数据等

比如下图中，有很多节点，那么节点中只提供存储空间，我们把数据存上来就行；那么元数据可以找一个固定的节点进行存储。比如存一个2G数据时，客户端把这个2G存储数据的请求发给元数据节点，元数据节点按照我们所指定的大小规模进行切块，每一块当做一个独立的文件，然后进行路由和调度，从而完成分散存储的目的。比如这个文件以64M为一块(这里的块跟本机文件系统的块是两回事)，第一块交给第一个服务器存，第二块交给第二个服务器存，这样就可以充分利用多个节点的网络和磁盘IO的存储能力，从而达到分布式效果。

当用户读数据时，每一个文件的元数据在元数据服务器上，它记录有某一个文件被切了多少块，每一块在哪个服务器上，块和块之间是如何偏移的(就是哪个是第一块哪个是第二块)等信息，当用户读数据时，需要先去联系元数据服务器，然后由元数据返回给他相关的信息以后，他可以并行的从这些数据节点上加载到这些数据块，然后再按照元数据里面给出的逻辑，由客户端组合起来就可以得到完整的文件数据了。

如果Name Node宕机了，那么所有的数据也就无法组合起来了，因此需要对NameNode做高可用。文件系统的元数据是一类非常密集，但IO量非常小的数据，一个元数据也就几k、几十k，最多几百k的大小，但是上面是每个文件都有，所以我们每一次的访问文件数据都需要访问元数据，因此为了达到高性能、高效，它们一般都会在内存当中，因此非常消耗内存空间，但是一旦宕机了内存的数据就没了，所以就需要一种机制实现持久的存储在磁盘中。

但是我们的文件发生修改，那么元数据也需要跟着修改，所以没法判断每次都是哪个文件进行修改了，所以这种大量的往磁盘的这种修改操作都是随机的，而随机IO通常都非常慢，因此为了让这些修改操作可以快速高效的存储在磁盘上，通常都不是直接修改源文件的元数据的，而是把每次修改的具体请求记录下来，直接顺序的往后记(类似Redis中的AOF顺序写，AOF的缺点只能通过重放记录在文件中的指令才能把数据恢复回来)，这种方式后恢复数据很慢，所以就不存储在磁盘上了，而是把元数据都放在一个第三方的存储服务上。

       为什么需要使用到存储，文章来源(Source)：浅时光博客其实还是跟我们的业务系统有关，准确来说是我们的业务状态，如果没有存储中间件，服务端要对业务状态进行持久化，是会很复杂的，毕竟我们的服务端程序是面对的是庞大的用户群体，并且如果让开发人员对每一个API的请求状态进行考虑持久化，那么这个代价会很大。

那么存储简单的来讲就是负责维持计算系统状态的单元。从维持状态的角度，我们就需要要求存储的可靠性了。所以在现在的互联网的场景下也就从而衍生出了分布式的概念。主要就是为了我们的数据安全性。

三、Ceph

CEPH官网：https://docs.ceph.com/en/quincy/

Ceph是一个去中心化、对象式(Objects)存储系统，它把每一个待管理的数据流（例如一个文件）切分为一到多个固定大小（默认为4M可自定义）的对象数据，并以其为原子单元完成数据存取（类似于K8s里面的Pod，不可再切割的单元）。在经过了数年的发展之后，目前已得到众多云计算厂商的支持并被广泛应用。

对象数据的底层存储服务由多个主机组成的存储集群，该集群也被称之为RADOS存储集群，即可靠、自动化、分布式对象存储系统

libeRADOS是RADOS存储集群的API，它支持C、C++、Java、python、ruby和PHP等编程语言。因此我们要想向ceph里面存储数据，需要调libeRADOS的API来实现，它的API能把客户端提交的文件切割成固定的块，并分散的存储到我们的存储集群节点上去。

Ceph 独一无二地用统一的系统提供了对象、块、和文件存储功能，它可靠性高、管理简便、并且是自由软件。 Ceph 的强大足以改变公司的 IT 基础架构、和管理海量数据的能力。Ceph 可提供极大的伸缩性——供成千用户访问 PB 乃至 EB 级的数据。 Ceph 节点以普通硬件和智能守护进程作为支撑点， Ceph 存储集群组织起了大量节点，它们之间靠相互通讯来复制数据、并动态地重分布数据。

Ceph从设计上就是解决分布式存储所面临的元数据服务器很容易成为瓶颈的问题的。Ceph在存数据时，将一个对象存储在RADOS上的时候，它不会去查找文件存储到哪个位置，Ceph在存数据的时候，为了避免有一个元数据中心服务器成为整个系统的瓶颈所在，它也采用了计算方式来解决问题，当你在存文件的时候，它要对文件进行hash计算，然后映射到对应的存储节点上去，当你去查的时候也是通过同样的方式去查的。

CRUSH是Ceph内部通过计算的方式来完成对象(文件)路由的一个非常重要的计算算法。也就意味着Ceph没有中心节点，没有一个元数据服务器，因此任何一个对象进行存取的时候都是通过算法实时计算出来的（hash计算，对CPU消耗很小）

Ceph适合跨集群的中小文件和大型文件的存储， 拥有以下特点：

• 高性能
  • 采用CRUSH算法，数据分布均衡，并行度高（也就是可以将数据均衡的分布到各个节点上去，不会导致某个节点压力过大的情况），支持上千个存储节点， 支持TB及PB级数据。
• 高可用性
  • 支持故障域分隔，数据强一致性； 没有单点故障，自动管理。Ceph的部署必须得3个以上的奇数台节点才可以部署
• 高扩展性
  • 去中心化、灵活、随节点增加线性增长（当节点越多，数据的吞吐能力越高）。
• 场景丰富
  • 支持三种存储接口类型: 块存储、文件存储、对象存储。 同时支持自定义接口，C++为底层实现， 兼容多种语言。
    • 块存储： 将磁盘空间映射给主机使用， 适用场景 docker容器、虚拟机磁盘存储分配；日志存储， 文件存储
    • 文件存储： 解决块存储无法共享问题， 在服务器架设FTP和NFS服务器，适用目录结构的存储、日志存储等。
    • 对象存储： 大容量硬盘， 安装存储管理软件， 对外提供读写访问能力， 具备块存储的高速读写能力， 也具备文件存储共享的特性； 适用图片存储或视频存储（富媒体数据）

四、FastDFS

FastDFS是用C语言编写的一款开源的轻量级分布式文件系统。它对文件进行管理，功能包括：文件存储、文件同步、文件访问（文件上传、文件下载）等，解决了大容量存储和负载均衡的问题。特别适合以中小文件为载体的在线服务，如相册网站、视频网站等等。(文件大小官方建议是4K-500M)

FastDFS为互联网量身定制，充分考虑了冗余备份、负载均衡、线性扩容等机制，并注重高可用、高性能等指标，使用FastDFS很容易搭建一套高性能的文件服务器集群提供文件上传、下载等服务。

• 分组存储，灵活简洁、对等结构，不存在单点（分组存储：同组下存储的是相同的数据）
• 文件不分块存储，上传的文件和OS文件系统中的文件一一对应
• 文件ID由FastDFS生成，作为文件访问凭证，FastDFS不需要传统的name server
• 和流行的web server无缝衔接，FastDFS已提供apache和nginx扩展模块
• 中、小文件均可以很好支持，支持海量小文件存储
• 支持多块磁盘，支持单盘数据恢复
• 支持相同内容的文件只保存一份，节约磁盘空间
• 支持在线扩容 支持主从文件
• 存储服务器上可以保存文件属性（meta-data）V2.0网络通信采用libevent，支持大并发访问，整体性能更好
• 下载文件支持多线程方式，支持断点续传

FastDFS由客户端(Client)、 跟踪服务器(Tracker Server)和存储服务器(Storage Server)构成。

客户端，作为业务请求的发起方，通过专有接口，使用TCP/IP协议与跟踪器服务器或存储节点进行数据交互。FastDFS向使用者提供基本文件访问接口，比如upload、download、append、delete等，以客户端库的方式提供给用户使用。

Tracker Server是负载均衡和调度，通过Tracker Server在文件上传时可以根据一些策略来找到Storager Server来提供上传服务，Tracker Server可以有多台。这种跟踪器在访问上起到了负载均衡的作用，可以做到随时的增加或者下线，不会影响线上服务。

Tracker是FastDFS的协调者，负责管理所有的storage server和group，每个storage在启动后会连接Tracker，告知自己所属的group等信息，并保持周期性的心跳，Tracker根据storage的心跳信息，建立group==>[storage server list]的映射表。

Tracker 需要管理的元信息很少，会全部存储在内存中；另外Tracker 上的元信息都是由storage汇报的信息生成的，本身不需要持久化任何数据，这样使得Tracker非常容易扩展，直接增加Tracker机器即可扩展为Tracker cluster来服务，cluster里每个Tracker 之间是完全对等的，所有的Tracker 都接受stroage的心跳信息，生成元数据信息来提供读写服务。

文件存储，客户端上传的文件最终落在Storage Server。Storage Server没有文件系统，它是利用操作系统的文件系统来管理文件。存储服务器也是可以随时进行上线或者下线的，也不会影响到线上的服务。存储服务器（又称存储节点或数据服务器），文件和文件属性（meta data）都保存到存储服务器上。Storage server直接利用OS的文件系统调用管理文件。

Storage server（简称storage）以组（卷，group或volume）为单位组织，一个group内包含多台storage机器，数据互为备份，存储空间以group内容量最小的storage为准，所以建议group内的多个storage尽量配置相同，以免造成存储空间的浪费。

写文件时，客户端将文件写至group内一个storage server即认为写文件成功，storage server写完文件后，会由后台线程将文件同步至同group内其他的storage server。

每个storage写文件后，同时会写一份binlog，binlog里不包含文件数据，只包含文件名等元信息，这份binlog用于后台同步，storage会记录向group内其他storage同步的进度，以便重启后能接上次的进度继续同步。进度以时间戳的方式进行记录，所以最好能保证集群内所有server的时钟保持同步。

五、GlusterFS

   GlusterFS是Scale-Out存储解决方案Gluster的核心，它是一个开源的分布式文件系统，具有强大的横向扩展能力，通过扩展能够支持数PB存储容量和处理数千客户端。GlusterFS借助TCP/IP或InfiniBand RDMA网络将物理分布的存储资源聚集在一起，使用单一全局命名空间来管理数据。

官网：https://www.gluster.org/

• GlusterFS利用双重特性来提供高容量存储解决方案。

1. Scale-Out架构通过增加存储节点的方式来提高存储容量和性能（磁盘、计算机和I/O资源都可以独立增加），支持10GBE和InfiniBand等高速网络互联；
2. Gluster弹性哈希解决了GlusterFS对元数据服务器的依赖，GlusterFS采用弹性算法在存储池中定位数据，放弃了传统的通过元数据服务器定位数据，GlusterFS中可以智能的定位任意数据分片（将数据分片存储在不同节点上），不需要查看索引或者想元数据服务器查询。这种设计机制实现了存储的横向扩展，改善了单点故障及性能瓶颈，真正实现了并行化数据访问。

GlusterFS通过配置某些类型的存储卷，可以对文件进行自动复制（类似于RAID1），即使某个节点出现故障，也不影响数据的访问。当数据出现不一致时，自动修复功能能够把数据恢复到正确的状态，数据的修复是以增量的方式在后台执行，不会占用太多系统资源。GlusterFS可以支持所有的存储，以内它没有设计自己的私有数据文件格式，而是采用操作系统中标准的磁盘文件系统（如EXT3、XFS等）来存储文件，数据可以使用传统的访问磁盘的方式被访问；

全局统一命名空间将所有的存储资源聚集成一个单一的虚拟存储池，对用户和应用屏蔽了物理存储信息。存储资源（类似于LVM）可以根据生产环境中的需要进行弹性扩展或收缩。在多节点场景中，全局统一命名空间还可以基于不同节点做负载均衡，大大提高了存取效率；

GlusterFS通过将数据储存在逻辑卷中，逻辑卷从逻辑存储池进行独立逻辑划分。逻辑存储池可以在线进行增加和移除，不会导致业务中断。逻辑卷可以根据需求在线增长或增减，并可以在多个节点中负载均衡。文件系统配置更改也可以实时在线进行并应用，从而可以适应工作负载条件变化或在线性能调优

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

图中所示只是GlusterFS数据访问的一个概要图，大致过程：

1. 客户端或应用程序通过GlusterFS的挂在点访问数据；
2. Linux系统内核通过VFS API收到请求并处理；
3. VFS将数据递交给FUSE内核文件系统，并向系统注册了一个实际的文件系统FUSE，而FUSE文件系统则是将数据通过/dev/fuse设备文件递交给GlusterFS client端。可以将FUSE文件系统理解为一个代理；
4. GlusterFS client收到数据后。client根据配置文件对数据进行处理；
5. 经过GlusterFS client处理后，通过网络将数据传递至远端的GlusterFS Server，并且将数据写入服务器存储设备。

GlusterFS支持七种卷，这七种卷可以满足不同应用对高性能、高可用的需求。这七种卷分别是：

• 分布式卷：文件通过HASH算法分布到所有Brick Server上，这种卷是Glusterfs的基础；以文件为单位根据HASH算法散列到不同的Brick，其实只是扩大了磁盘空间，如果有一个磁盘损坏，数据也将丢失，属于文件级的RAID0，不具备容错能力
• 条带卷：类似于RAID0，文件被分为数据块并以轮询的方式分布到多个Brick Server上，文件存储以数据块为单位，支持大文件存储，文件越大，读取效率越高
• 复制卷：将文件同步到多个Brick上，使其具备多个文件副本，属于文件级RAID1，具有容错能力。因为数据分散到多个Brick中，所以读性能得到了很大提升，但写性能下降
• 分布式条带卷：Brick Server数量是条带数（数据块分布的Brick数量）的倍数，兼备分布式卷和条带卷的特点
• 分布式复制卷：Brick Server数量是镜像数（数据副本数量）的倍数，具有分布式卷和复制卷的特点
• 条带复制卷：类似于RAID10，同时具有条带卷和复制卷的特点
• 分布式条带复制卷：三种基本卷的复合卷，通常用于类Map Reduce应用

六、存储系统横纵对比

• 小图片
• 音频、小视频
• 其他类型小文件

• 适合存储大文件
• 小文件存储性能差

• 支持对象存储、块存储和文件存储
• 高性能、高可靠性和高扩展