【重识云原生】第三章云存储第一节——分布式云存储总述

  《重识云原生系列》专题索引：

1. 第一章——不谋全局不足以谋一域
2. 第二章计算第1节——计算虚拟化技术总述
3. 第二章计算第2节——主流虚拟化技术之VMare ESXi
4. 第二章计算第3节——主流虚拟化技术之Xen
5. 第二章计算第4节——主流虚拟化技术之KVM
6. 第二章计算第5节——商用云主机方案
7. 第二章计算第6节——裸金属方案
8. 第三章云存储第1节——分布式云存储总述
9. 第三章云存储第2节——SPDK方案综述
10. 第三章云存储第3节——Ceph统一存储方案
11. 第三章云存储第4节——OpenStack Swift 对象存储方案
12. 第三章云存储第5节——商用分布式云存储方案
13. 第四章云网络第一节——云网络技术发展简述
14. 第四章云网络4.2节——相关基础知识准备
15. 第四章云网络4.3节——重要网络协议
16. 第四章云网络4.3.1节——路由技术简述
17. 第四章云网络4.3.2节——VLAN技术
18. 第四章云网络4.3.3节——RIP协议
19. 第四章云网络4.3.4节——OSPF协议
20. 第四章云网络4.3.5节——EIGRP协议
21. 第四章云网络4.3.6节——IS-IS协议
22. 第四章云网络4.3.7节——BGP协议
23. 第四章云网络4.3.7.2节——BGP协议概述
24. 第四章云网络4.3.7.3节——BGP协议实现原理
25. 第四章云网络4.3.7.4节——高级特性
26. 第四章云网络4.3.7.5节——实操
27. 第四章云网络4.3.7.6节——MP-BGP协议
28. 第四章云网络4.3.8节——策略路由
29. 第四章云网络4.3.9节——Graceful Restart(平滑重启)技术
30. 第四章云网络4.3.10节——VXLAN技术
31. 第四章云网络4.3.10.2节——VXLAN Overlay网络方案设计
32. 第四章云网络4.3.10.3节——VXLAN隧道机制
33. 第四章云网络4.3.10.4节——VXLAN报文转发过程
34. 第四章云网络4.3.10.5节——VXlan组网架构
35. 第四章云网络4.3.10.6节——VXLAN应用部署方案
36. 第四章云网络4.4节——Spine-Leaf网络架构
37. 第四章云网络4.5节——大二层网络
38. 第四章云网络4.6节——Underlay 和 Overlay概念
39. 第四章云网络4.7.1节——网络虚拟化与卸载加速技术的演进简述
40. 第四章云网络4.7.2节——virtio网络半虚拟化简介
41. 第四章云网络4.7.3节——Vhost-net方案
42. 第四章云网络4.7.4节vhost-user方案——virtio的DPDK卸载方案
43. 第四章云网络4.7.5节vDPA方案——virtio的半硬件虚拟化实现
44. 第四章云网络4.7.6节——virtio-blk存储虚拟化方案
45. 第四章云网络4.7.8节——SR-IOV方案
46. 第四章云网络4.7.9节——NFV
47. 第四章云网络4.8.1节——SDN总述
48. 第四章云网络4.8.2.1节——OpenFlow概述
49. 第四章云网络4.8.2.2节——OpenFlow协议详解
50. 第四章云网络4.8.2.3节——OpenFlow运行机制
51. 第四章云网络4.8.3.1节——Open vSwitch简介
52. 第四章云网络4.8.3.2节——Open vSwitch工作原理详解
53. 第四章云网络4.8.4节——OpenStack与SDN的集成
54. 第四章云网络4.8.5节——OpenDayLight
55. 第四章云网络4.8.6节——Dragonflow

56.  第四章云网络4.9.1节——网络卸载加速技术综述

57. 第四章云网络4.9.2节——传统网络卸载技术

58. 第四章云网络4.9.3.1节——DPDK技术综述

59. 第四章云网络4.9.3.2节——DPDK原理详解

60. 第四章云网络4.9.4.1节——智能网卡SmartNIC方案综述

61. 第四章云网络4.9.4.2节——智能网卡实现

62. 第六章容器6.1.1节——容器综述

63. 第六章容器6.1.2节——容器安装部署

        分布式云存储知识地图： 

1 分布式存储发展简述

1.1 存储发展简史

        在了解什么是分布式存储之前，我们先来简单了解一下存储几十年来的大概历程。

• 直连存储（DAS）：存储和服务器直连，拓展性、灵活性差。
• 中心化存储（SAN、NAS）：设备类型丰富，通过IP/FC网络互连，具有一定的拓展性，但是受到控制器能力限制，拓展能力有限。同时，设备到了生命周期要进行更换，数据迁移需要耗费大量的时间和精力。
• 分布式存储：基于标准硬件和分布式架构，将数据分散存储到多个存储服务器上，并将这些分散的存储资源构成一个虚拟的存储设备，可实现千节点/EB级扩展，同时可以对块、对象、文件等多种类型存储统一管理。

        直连存储与中心化存储也可以统称为集中式存储。

1.1.1 集中式存储简述

        集中式存储系统中，整个存储资源是集中在一个系统中的，但集中式存储并不是一个单独的设备，是集中在一套系统当中的多个设备，比如下图中的 EMC 存储就需要几个机柜来存放。

        在这个存储系统中包含很多组件，除了核心的机头(控制器)、磁盘阵列( JBOD )和交换机等设备外，还有管理设备等辅助设备。

        结构中包含一个机头，这个是存储系统中最为核心的部件。通常在机头中有包含两个控制器，互为备用， 避免硬件故障导致整个存储系统的不可用。机头中通常包含前端端口和后端端口，前端端口用户为服务器提供存储服务，而后端端口用于扩充存储系统的容量。通过后端端口机头可以连接更多的存储设备，从而形成一个非常大的存储资源池。

        在整个结构中，机头中是整个存储系统的核心部件，整个存储系统的高级功能都在其中实现。控制器中的软件实现对磁盘的管理，将磁盘抽象化为存储资源池，然后划分为 LUN 提供给服务器使用。这里的 LUN 其实就是在服务器上看到的磁盘 。当然，一些集中式存储本身也是文件服务器，可以提供共享文件服务。无论如何，从上面我们可以看出集中式存储 最大的特点是有一个统一的入口，所有数据都要经过这个入口 ，这个入口就是存储系统的机头。这也就是集中式存储区别于分布式存储最显著的特点。如下图所示：

1.1.2 分布式存储简述

        分布式存储最早是由谷歌提出的，其目的是通过廉价的服务器来提供使用与大规模，高并发场景下的 Web 访问问题。它 采用可扩展的系统结构，利用多台存储服务器分担存储负荷，利用位置服务器定位存储信息，它不但提高了系统的可靠性、可用性和存取效率，还易于扩展。

1 、分布式存储的兴起

        分布式存储的兴起与互联网的发展密不可分，互联网公司由于其数据量大而资本积累少，而通常都使用大规模分布式存储系统。

        与传统的高端服务器、高端存储器和高端处理器不同的是，互联网公司的分布式存储系统由数量众多的、低成本和高性价比的普通 PC 服务器通过网络连接而成。其主要原因有以下三点：

1. 互联网的业务发展很快，而且注意成本消耗，这就使得存储系统不能依靠传统的纵向扩展的方式，即先买小型机，不够时再买中型机，甚至大型机。互联网后端的分布式系统要求支持横向扩展，即通过增加普通 PC 服务器来提高系统的整体处理能力。
2. 普通 PC 服务器性价比高，故障率也高，需要在软件层面实现自动容错，保证数据的一致性。
3. 另外，随着服务器的不断加入，需要能够在软件层面实现自动负载均衡，使得系统的处理能力得到线性扩展。

2 、分布式存储的重要性

        从单机单用户到单机多用户，再到现在的网络时代，应用系统发生了很多的变化。而分布式系统依然是目前很热门的讨论话题，那么，分布式系统给我们带来了什么，或者说是为什么要有分布式系统呢?

1. 升级单机处理能力的性价比越来越低，企业发现通过更换硬件做垂直扩展的方式来提升性能会越来越不划算;
2. 单机处理能力存在瓶颈，某个固定时间点，单颗处理器有自己的性能瓶颈，也就说即使愿意花更多的钱去买计算能力也买不到了;
3. 出于稳定性和可用性的考虑，如果采用单击系统，那么在这台机器正常的时候一切 OK ，一旦出问题，那么系统就完全不能用了。当然，可以考虑做容灾备份等方案，而这些方案就会让系统演变为分布式系统了;
4. 云存储和大数据发展的必然要求，云存储和大数据是构建在分布式存储之上的应用。移动终端的计算能力和存储空间有限，而且有在多个设备之间共享资源的强烈的需求，这就使得网盘、相册等云存储应用很快流行起来。然而，万变不离其宗，云存储的核心还是后端的大规模分布式存储系统。大数据则更近一步，不仅需要存储海量数据，还需要通过合适的计算框架或者工具对这些数据进行分析，抽取其中有价值的部分。如果没有分布式存储，便谈不上对大数据进行分析。仔细分析还会发现，分布式存储技术是互联网后端架构的神器，掌握了这项技能，以后理解其他技术的本质会变得非常容易。

1.2 分布式存储整体架构总述

        分布式存储包含的种类繁多，除了传统意义上的分布式文件系统、分布式块存储和分布式对象存储外，还包括分布式数据库和分布式缓存等，但其中架构无外乎于三种：

A、 中间控制节点架构

        以 HDFS ( Hadoop Distribution File System )为代表的架构是典型的代表。在这种架构中，一部分节点 NameNode 是存放管理数据(元数据)，另一部分节点 DataNode 存放业务数据，这种类型的服务器负责管理具体数据。这种架构就像公司的层次组织架构， namenode 就如同老板，只管理下属的经理( datanode )，而下属的经理，而经理们来管理节点下本地盘上的数据。

        在上图中， 如果客户端需要从某个文件读取数据，首先从 NameNode 获取该文件的位置(具体在哪个 DataNode )，然后从该 NameNode 获取具体的数据。在该架构中 NameNode 通常是主备部署( Secondary NameNode )，而 DataNode 则是由大量节点构成一个集群。由于元数据的访问频度和访问量相对数据都要小很多，因此 NameNode 通常不会成为性能瓶颈，而 DataNode 集群中的数据可以有副本，既可以保证高可用性，可以分散客户端的请求。因此，通过这种分布式存储架构可以通过横向扩展 datanode 的数量来增加承载能力，也即实现了动态横向扩展的能力。

B、 完全无中心架构 – 计算模式

        以 Ceph 为代表的架构是其典型的代表。在该架构中与 HDFS 不同的地方在于该架构中没有中心节点。客户端是通过一个设备映射关系 计算出来 其写入数据的位置，这样客户端可以直接与存储节点通信，从而避免中心节点的性能瓶颈。

        如上图所示， 在 Ceph 存储系统架构中核心组件有 MON 服务、 OSD 服务和 MDS 服务等。

(1) MON 服务用于维护存储系统的硬件逻辑关系，主要是服务器和硬盘等在线信息。MON 服务通过集群的方式保证其服务的可用性。

(2) OSD 服务用于实现对磁盘的管理，实现真正的数据读写，通常一个磁盘对应一个 OSD 服务。

(3) MDS 只为 CephFS 文件存储系统跟踪文件的层次机构和存储元数据。Ceph 块设备和 RADOS 并不需要元数据，因此也不需要 Ceph MDS 守护进程。

(4) RADOS ：RADOS 就是包含上述三种服务的 ceph 存储集群。在 Ceph 中所有的数据都以对象形式存在的，并且无论哪种数据类型 RADOS 对象存储都将负责保存这些对象。RADOS 层可以确保数据始终保持一致性。要做到这一点必须执行数据复制、故障检测和恢复，以及数据迁移和所在集群节点实现在平衡。

(5) RBD (块设备)：原名 RADOS 块设备，提供可靠的分布式和高性能块存储磁盘给客户端。

(6) CephFS ：Ceph 文件系统提供了一个使用 Ceph 存储集群存储用户数据的与 POSIX 兼容的文件系统。

(7) Librados ：libRADOS 库为 PHP 、 RUBY 、 Java 、 Python 、 C++ 等语言提供 了方便的访问 RADOS 接口的方式。

(8) RADOS GW ：RGW 提供对象存储服务，它允许应用程序和 Ceph 对象存储建立连接， RGW 提供了与 Amazon S3 和 openstack Swift 兼容的 RUSTFUL API。

        客户端访问存储的大致流程是，客户端在启动后会首先通过 RADOS GW 进入，从 MON 服务拉取存储资源布局信息，然后根据该布局信息和写入数据的名称等信息计算出期望数据的位置(包含具体的物理服务器信息和磁盘信息)，然后和该位置信息对应的 CephFS 对应的位置直接通信，读取或者写入数据

C、 完全无中心架构 – 一致性哈希

        以 swift 为代表的架构是其典型的代表。与 Ceph 的通过计算方式获得数据位置的方式不同，另外一种方式是通过一致性哈希的方式获得数据位置。一致性哈希的方式就是将设备做成一个哈希环，然后根据数据名称计算出的哈希值映射到哈希环的某个位置，从而实现数据的定位。

        Swift 中存在两种映射关系，对于一个文件，通过哈希算法( MD5 )找到对应的虚节点(一对一的映射关系)，虚节点再通过映射关系( ring 文件中二维数组)找到对应的设备(多对多的映射关系)，这样就完成了一个文件存储在设备上的映射。

1.3 云上分布式存储简述

        分布式存储架构由三个部分组成：客户端、元数据服务器和数据服务器。客户端负责发送读写请求，缓存文件元数据和文件数据。元数据服务器负责管理元数据和处理客户端的请求，是整个系统的核心组件。数据服务器负责存放文件数据，保证数据的可用性和完整性。该架构的好处是性能和容量能够同时拓展，系统规模具有很强的伸缩性。

        分布式存储分为文件存储、对象存储和块存储，但它们三种存储方式的基本架构都是大同小异的。即客户端或应用端、元数据（MDS）服务器和数据节点服务器。客户端和元数据服务器之间交互是“信令交互”，而客户端到数据节点是“媒体交互”。元数据服务器或通过数据节点服务器获取各节点服务器的基本配置情况和状态信息。

1.3.1 块存储

        典型设备：磁盘阵列，硬盘

        块存储主要是将裸磁盘空间整个映射给主机使用的，就是说例如磁盘阵列里面有5块硬盘（为方便说明，假设每个硬盘1G），然后可以通过划逻辑盘、做Raid、或者LVM（逻辑卷）等种种方式逻辑划分出N个逻辑的硬盘。（假设划分完的逻辑盘也是5个，每个也是1G，但是这5个1G的逻辑盘已经于原来的5个物理硬盘意义完全不同了。例如第一个逻辑硬盘A里面，可能第一个200M是来自物理硬盘1，第二个200M是来自物理硬盘2，所以逻辑硬盘A是由多个物理硬盘逻辑虚构出来的硬盘。）

        接着块存储会采用映射的方式将这几个逻辑盘映射给主机，主机上面的操作系统会识别到有5块硬盘，但是操作系统是区分不出到底是逻辑还是物理的，它一概就认为只是5块裸的物理硬盘而已，跟直接拿一块物理硬盘挂载到操作系统没有区别的，至少操作系统感知上没有区别。

        此种方式下，操作系统还需要对挂载的裸硬盘进行分区、格式化后，才能使用，与平常主机内置硬盘的方式完全无异。

优点：

1. 这种方式的好处当然是因为通过了Raid与LVM等手段，对数据提供了保护。
2. 另外也可以将多块廉价的硬盘组合起来，成为一个大容量的逻辑盘对外提供服务，提高了容量。
3. 写入数据的时候，由于是多块磁盘组合出来的逻辑盘，所以几块磁盘可以并行写入的，提升了读写效率。
4. 很多时候块存储采用SAN架构组网，传输速率以及封装协议的原因，使得传输速度与读写速率得到提升。

缺点：

1. 采用SAN架构组网时，需要额外为主机购买光纤通道卡，还要买光纤交换机，造价成本高。
2. 主机之间的数据无法共享，在服务器不做集群的情况下，块存储裸盘映射给主机，再格式化使用后，对于主机来说相当于本地盘，那么主机A的本地盘根本不能给主机B去使用，无法共享数据。
3. 不利于不同操作系统主机间的数据共享：另外一个原因是因为操作系统使用不同的文件系统，格式化完之后，不同文件系统间的数据是共享不了的。例如一台装了WIN7/XP，文件系统是FAT32/NTFS，而Linux是EXT4，EXT4是无法识别NTFS的文件系统的。就像一只NTFS格式的U盘，插进Linux的笔记本，根本无法识别出来。所以不利于文件共享。

1.3.2 文件存储

典型设备：FTP、NFS服务器

        为了克服上述文件无法共享的问题，所以有了文件存储。

        文件存储也有软硬一体化的设备，但是其实普通拿一台服务器/笔记本，只要装上合适的操作系统与软件，就可以架设FTP与NFS服务了，架上该类服务之后的服务器，就是文件存储的一种了。

        主机A可以直接对文件存储进行文件的上传下载，与块存储不同，主机A是不需要再对文件存储进行格式化的，因为文件管理功能已经由文件存储自己搞定了。

优点：

1. 造价交低：随便一台机器就可以了，另外普通以太网就可以，根本不需要专用的SAN网络，所以造价低。
2. 方便文件共享：例如主机A（WIN7，NTFS文件系统），主机B（Linux，EXT4文件系统），想互拷一部电影，本来不行。加了个主机C（NFS服务器），然后可以先A拷到C，再C拷到B就OK了。

缺点：

1. 读写速率低，传输速率慢：以太网，上传下载速度较慢，另外所有读写都要1台服务器里面的硬盘来承担，相比起磁盘阵列动不动就几十上百块硬盘同时读写，速率慢了许多。

1.3.3 对象存储

典型设备：内置大容量硬盘的分布式服务器

        对象存储最常用的方案，就是多台服务器内置大容量硬盘，再装上对象存储软件，然后再额外搞几台服务作为管理节点，安装上对象存储管理软件。管理节点可以管理其他服务器对外提供读写访问功能。

        之所以出现了对象存储这种东西，是为了克服块存储与文件存储各自的缺点，发扬它俩各自的优点。简单来说块存储读写快，不利于共享，文件存储读写慢，利于共享。能否弄一个读写快，利 于共享的出来呢。于是就有了对象存储。

        首先，一个文件包含了了属性（术语叫metadata，元数据，例如该文件的大小、修改时间、存储路径等）以及内容（以下简称数据）。

        以往像FAT32这种文件系统，是直接将一份文件的数据与metadata一起存储的，存储过程先将文件按照文件系统的最小块大小来打散（如4M的文件，假设文件系统要求一个块4K，那么就将文件打散成为1000个小块），再写进硬盘里面，过程中没有区分数据/metadata的。而每个块最后会告知你下一个要读取的块的地址，然后一直这样顺序地按图索骥，最后完成整份文件的所有块的读取。

        这种情况下读写速率很慢，因为就算你有100个机械手臂在读写，但是由于你只有读取到第一个块，才能知道下一个块在哪里，其实相当于只能有1个机械手臂在实际工作。

        而对象存储则将元数据独立了出来，控制节点叫元数据服务器（服务器+对象存储管理软件），里面主要负责存储对象的属性（主要是对象的数据被打散存放到了那几台分布式服务器中的信息），而其他负责存储数据的分布式服务器叫做OSD，主要负责存储文件的数据部分。当用户访问对象，会先访问元数据服务器，元数据服务器只负责反馈对象存储在哪些OSD，假设反馈文件A存储在B、C、D三台OSD，那么用户就会再次直接访问3台OSD服务器去读取数据。

        这时候由于是3台OSD同时对外传输数据，所以传输的速度就加快了。当OSD服务器数量越多，这种读写速度的提升就越大，通过此种方式，实现了读写快的目的。

        另一方面，对象存储软件是有专门的文件系统的，所以OSD对外又相当于文件服务器，那么就不存在文件共享方面的困难了，也解决了文件共享方面的问题。

        所以对象存储的出现，很好地结合了块存储与文件存储的优点。

1.3.4 块存储、对象和文件存储架构区别

1.3.4.1 块存储

        块存储是一种裸设备，它是将存储设备以“块”的方式直接提供给客户，由客户自己的操作系统里的文件系统进行管理。

        华为的FusionStorage是一个典型的“块”存储。FusionStorage分成了MDC、OSD和Client三部分。和其他分布式存储重大的差别是:MDC是记录、更新OSD服务器、磁盘等的状态，并把这些状态数据实时同步给Vbs，由Vbs计算出来数据所落的位置。MDC可以单独部署，也可以集中部署，也可以分布部署。

        一般分布式存储的MDC采用的是数据库或内存储数据库来记录数据块和物理位置关系。客户端向MDC发出询问位置的请求，MDC查询数据库后返回请求数据的存储位置。

        这种方法存储访问的速度较慢，而且MDC作为交通的“枢纽”，绝对是整个存储的核心，当MDC发生故障，会导致整个存储都不能使用。但是采取这个方式，也有好处，比如可以根据不同需求设置不同的副本策略等。

1.3.4.2 对象存储

        对象存储是在同样容量下提供的存储性能比文件存储更好，又能像文件存储一样有很好的共享性。实际使用中，性能不是对象存储最关注的问题，需要高性能可以用块存储，容量才是对象存储最关注的问题。

        所以对象存储的持久化层的硬盘数量更多，单盘的容量也更大。对象存储的数据的安全性保障也各式各样，可以是单机raid或网络raid，也可以副本。

        Ceph和google基于GFS的存储就是典型的对象存储。

1.3.4.3 区别

        分布式块存储里是没有文件系统的，是通过客户端直接将最简单明了的命令传递给存储的“块”来执行。

        对象存储和文件存储虽然结构类似，但并不将存储底层的“块”直接提供出来，而是通过隐藏着一个文件系统，包装成为“文件”或“对象”提供出来。

        这些存储“不挑”操作系统或终端，最终执行命令的是存储里面的文件系统操控存储执行的，所以共享性很好。

        文件存储通过“目录+文件名+偏移量”来检索，文件间有目录层次的；

        而对象存储采用“唯一对象ID+偏移量”来检索，对象扁平存储的，是没有层次的。而且块、对象、文件存储是可以相互转换的。

2 主流开源分布式存储方案概述

        在主流的分布式存储技术中，HDFS/GPFS/GFS属于文件存储，Swift属于对象存储，而Ceph可支持块存储、对象存储和文件存储，故称为统一存储。

2.1 Ceph

        Ceph最早起源于Sage就读博士期间的工作、成果于2004年发表，并随后贡献给开源社区。经过多年的发展之后，已得到众多云计算和存储厂商的支持，成为应用最广泛的开源分布式存储平台。

        Ceph根据场景可分为对象存储、块设备存储和文件存储。Ceph相比其它分布式存储技术，其优势点在于：它不单是存储，同时还充分利用了存储节点上的计算能力，在存储每一个数据时，都会通过计算得出该数据存储的位置，尽量将数据分布均衡。同时，由于采用了CRUSH、HASH等算法，使得它不存在传统的单点故障，且随着规模的扩大，性能并不会受到影响。

2.1.1 Ceph的主要架构

• 基础存储系统RADOS

        Ceph的最底层是RADOS（分布式对象存储系统），它具有可靠、智能、分布式等特性，实现高可靠、高可拓展、高性能、高自动化等功能，并最终存储用户数据。RADOS系统主要由Ceph OSD、Ceph Monitors两部分组成，Ceph OSD 的功能是存储数据，处理数据的复制、恢复、回填、再均衡，并通过检查其他OSD 守护进程的心跳来向 Ceph Monitors 提供一些监控信息。Ceph Monitor维护着展示集群状态的各种图表，包括监视器图、 OSD 图、归置组（ PG ）图、和 CRUSH 图。 

• 基础库LIBRADOS

        LIBRADOS层的功能是对RADOS进行抽象和封装，并向上层提供API，以便直接基于RADOS进行应用开发。RADOS是一个对象存储系统，因此，LIBRADOS实现的API是针对对象存储功能的。物理上，LIBRADOS和基于其上开发的应用位于同一台机器，因而也被称为本地API。应用调用本机上的LIBRADOS API，再由后者通过socket与RADOS集群中的节点通信并完成各种操作。

• 上层应用接口

        Ceph上层应用接口涵盖了RADOSGW（RADOS Gateway）、RBD（Reliable Block Device）和Ceph FS（Ceph File System），其中，RADOSGW和RBD是在LIBRADOS库的基础上提供抽象层次更高、更便于应用或客户端使用的上层接口。

• 应用层

        应用层就是不同场景下对于Ceph各个应用接口的各种应用方式，例如基于LIBRADOS直接开发的对象存储应用，基于RADOSGW开发的对象存储应用，基于RBD实现的云主机硬盘等。

2.1.2 Ceph的功能模块

• Client客户端：负责存储协议的接入，节点负载均衡。
• MON监控服务：负责监控整个集群，维护集群的健康状态，维护展示集群状态的各种图表，如OSD Map、Monitor Map、PG Map和CRUSH Map。
• MDS元数据服务：负责保存文件系统的元数据，管理目录结构。
• OSD存储服务：主要功能是存储数据、复制数据、平衡数据、恢复数据，以及与其它OSD间进行心跳检查等。一般情况下一块硬盘对应一个OSD。

2.1.3 Ceph的优点

1.CRUSH算法

        CRUSH算法是ceph的两大创新之一，简单来说，ceph摒弃了传统的集中式存储元数据寻址的方案，转而使用CRUSH算法完成数据的寻址操作。采用CRUSH算法，数据分布均衡，并行度高，不需要维护固定的元数据结构。

2.高可用

        Ceph中的数据副本数量可以由管理员自行定义，并可以通过CRUSH算法指定副本的物理存储位置以分隔故障域，支持数据强一致性，适合读多写少场景；ceph可以忍受多种故障场景并自动尝试并行修复。

3.高扩展性

        Ceph本身并没有主控节点，扩展起来比较容易，并且理论上，它的性能会随着磁盘数量的增加而线性增长。

4.特性丰富

        Ceph支持对象存储、块存储和文件存储服务，故称为统一存储。

2.1.4 Ceph的缺点

1. 去中心化的分布式解决方案，需要提前做好规划设计，对技术团队的要求能力比较高。
2. Ceph扩容时，由于其数据分布均衡的特性，会导致整个存储系统性能的下降。

 2.2 GFS

        GFS是google的分布式文件存储系统，是专为存储海量搜索数据而设计的，2003年提出，是闭源的分布式文件系统。适用于大量的顺序读取和顺序追加，如大文件的读写。注重大文件的持续稳定带宽，而不是单次读写的延迟。

2.2.1 GFS的主要架构

        GFS 架构比较简单，一个 GFS 集群一般由一个 master 、多个 chunkserver 和多个 clients 组成。

        在 GFS 中，所有文件被切分成若干个 chunk，每个 chunk 拥有唯一不变的标识（在 chunk 创建时，由 master 负责分配），所有 chunk 都实际存储在 chunkserver 的磁盘上。

        为了容灾，每个 chunk 都会被复制到多个 chunkserve.

2.2.2 GFS的功能模块

• GFS client客户端：为应用提供API，与POSIX API类似。同时缓存从GFS master读取的元数据chunk信息；
• GFS master元数据服务器：管理所有文件系统的元数据，包括命令空间（目录层级）、访问控制信息、文件到chunk的映射关系，chunk的位置等。同时 master 还管理系统范围内的各种活动，包括chunk 创建、复制、数据迁移、垃圾回收等；
• GFS chunksever存储节点：用于所有 chunk的存储。一个文件被分割为多个大小固定的chunk（默认64M），每个chunk有全局唯一的chunk ID。

2.2.3 GFS的写入流程

1. Client 向 master 询问要修改的 chunk在哪个 chunkserver上，以及 该chunk 其他副本的位置信息。
2. Master 将Primary、secondary的相关信息返回给 client。
3. Client 将数据推送给 primary 和 secondary；
4. 当所有副本都确认收到数据后，client 发送写请求给 primary，primary 给不同 client 的操作分配序号，保证操作顺序执行。
5. Primary 把写请求发送到 secondary，secondary 按照 primary 分配的序号顺序执行所有操作
6. 当 Secondary 执行完后回复 primary 执行结果。
7. Primary 回复 client 执行结果。

        由上述可见，GFS在进行写数据时，有如下特点：

• GFS在数据读写时，数据流与控制流是分开的，并通过租约机制，在跨多个副本的数据写入中, 保障顺序一致性;
• Master将chunk租约发放给其中一个副本，这个副本称为主副本，由主副本确定chunk的写入顺序，次副本则遵守这个顺序，这样就保障了全局顺序一致性
• Master返回客户端主副本和次副本的位置信息，客户端缓存这些信息以备将来使用，只有当主副本所在chunkserver不可用或返回租约过期了，客户端才需要再次联系Master；
• GFS采用链式推送，以最大化利用每个机器的网络带宽，避免网络瓶颈和高延迟连接，最小化推送延迟；
• GFS使用TCP流式传输数据，以最小化延迟。

2.2.4 GFS特点

• 适合大文件场景的应用，特别是针对GB级别的大文件，适用于数据访问延时不敏感的搜索类业务
• 中心化架构，只有1个master处于active状态
• 缓存和预取，通过在client端缓存元数据，尽量减少与master的交互，通过文件的预读取来提升并发性能
• 高可靠性，master需要持久化的数据会通过操作日志与checkpoint的方式存放多份，故障后master会自动切换重启。

2.3 HDFS

        HDFS（Hadoop Distributed File System），是一个适合运行在通用硬件(commodity hardware)上的分布式文件系统，是Hadoop的核心子项目，是基于流数据模式访问和处理超大文件的需求而开发的。该系统仿效了谷歌文件系统(GFS)，是GFS的一个简化和开源版本。

2.3.1 HDFS的主要架构

• HDFS Client（客户端）：从NameNode获取文件的位置信息，再从DataNode读取或者写入数据。此外，client在数据存储时，负责文件的分割；
• NameNode（元数据节点）：管理名称空间、数据块（Block）映射信息、配置副本策略、处理客户端读写请求；
• DataNode（存储节点）：负责执行实际的读写操作，存储实际的数据块,同一个数据块会被存储在多个DataNode上
• Secondary NameNode：定期合并元数据，推送给NameNode，在紧急情况下，可辅助NameNode的HA恢复。

2.3.2 HDFS的特点（Vs GFS）

• 分块更大，每个数据块默认128MB；
• 不支持并发，同一时刻只允许一个写入者或追加者；
• 过程一致性,写入数据的传输顺序与最终写入顺序一致；
• Master HA，2.X版本支持两个NameNode，（分别处于Active和Standby状态），故障切换时间一般几十秒到数分钟；

2.3.3 HDFS适合的应用场景

• 适用于大文件、大数据处理，处理数据达到 GB、TB、甚至PB级别的数据。
• 适合流式文件访问，一次写入，多次读取。
• 文件一旦写入不能修改，只能追加。

2.3.4 HDFS不适合的场景

• 低延时数据访问；
• 小文件存储；
• 并发写入、文件随机修改；

2.4 OpenStack Swift

        Swift 最初是由Rackspace公司开发的分布式对象存储服务， 2010 年贡献给 OpenStack 开源社区。作为其最初的核心子项目之一，为其 Nova 子项目提供虚机镜像存储服务。

2.4.1 Swift的主要架构

        Swift 采用完全对称、面向资源的分布式系统架构设计，所有组件都可扩展，避免因单点失效而影响整个系统的可用性。

 Swift 组件包括：

• 代理服务（Proxy Server）：对外提供对象服务 API，转发请求至相应的账户、容器或对象服务
• 认证服务（Authentication Server）：验证用户的身份信息，并获得一个访问令牌（Token）
• 缓存服务（Cache Server）：缓存令牌，账户和容器信息，但不会缓存对象本身的数据
• 账户服务（Account Server）：提供账户元数据和统计信息，并维护所含容器列表的服务
• 容器服务（Container Server）：提供容器元数据和统计信息，并维护所含对象列表的服务
• 对象服务（Object Server）：提供对象元数据和内容服务，每个对象会以文件存储在文件系统中
• 复制服务（Replicator）：检测本地副本和远程副本是否一致，采用推式（Push）更新远程副本
• 更新服务（Updater）：对象内容的更新
• 审计服务（Auditor）：检查对象、容器和账户的完整性，如果发现错误，文件将被隔离
• 账户清理服务（Account Reaper）：移除被标记为删除的账户，删除其所包含的所有容器和对象

2.4.2 Swift的数据模型

        Swift的数据模型采用层次结构，共设三层：Account/Container/Object（即账户/容器/对象)，每层节点数均没有限制，可以任意扩展。数据模型如下：

2.4.3 一致性散列函数

        Swift是基于一致性散列技术，通过计算将对象均匀分布到虚拟空间的虚拟节点上，在增加或删除节点时可大大减少需移动的数据量；

        为便于高效的移位操作，虚拟空间大小通常采用 2 n；通过独特的数据结构 Ring（环），再将虚拟节点映射到实际的物理存储设备上，完成寻址过程。如下图所示：

        散列空间4 个字节（32为），虚拟节点数最大为232，如将散列结果右移 m 位，可产生 2(32-m)个虚拟节点，（如上图中所示，当m=29 时，可产生 8 个虚拟节点）。

2.4.4 环的数据结构

        Swift为账户、容器和对象分别定义了的环。

        环是为了将虚拟节点（分区）映射到一组物理存储设备上，并提供一定的冗余度而设计的，环的数据信息包括存储设备列表和设备信息、分区到设备的映射关系、计算分区号的位移（即上图中的m）。

        账户、容器和对象的寻址过程。（以对象的寻址过程为例）：

1. 以对象的层次结构 account/container/object 作为键，采用 MD5 散列算法得到一个散列值；
2. 对该散列值的前 4 个字节进行右移操作（右移m位），得到分区索引号；
3. 在分区到设备映射表里，按照分区索引号，查找该对象所在分区对应的所有物理设备编号。如下图：

2.4.5 Swift的一致性设计

Swift 采用 Quorum 仲裁协议

• 定义：N：数据的副本总数；W：写操作被确认接受的副本数量；R：读操作的副本数量
• 强一致性：R+W>N， 就能保证对副本的读写操作会产生交集，从而保证可以读取到最新版本；
• 弱一致性：R+W<=N，读写操作的副本集合可能不产生交集，此时就可能会读到脏数据；

        Swift 默认配置是N=3，W=2，R=2，即每个对象会存在 3 个副本，至少需要更新 2 个副本才算写成功；如果读到的2个数据存在不一致，则通过检测和复制协议来完成数据同步。

        如R=1，就可能会读到脏数据，此时，通过牺牲一定的一致性，可提高读取速度，（而一致性可以通过后台的方式完成同步，从而保证数据的最终一致性）

        Quorum 协议示例如下所示：

2.4.6 Swift特点

• 原生的对象存储，不支持实时的文件读写、编辑功能
• 完全对称架构，无主节点，无单点故障，易于大规模扩展，性能容量线性增长
• 数据实现最终一致性，不需要所有副本写入即可返回，读取数据时需要进行数据副本的校验
• 是OpenStack的子项目之一，适合云环境的部署
• Swift的对象存储与Ceph提供的对象存储区别：客户端在访问对象存储系统服务时，Swift要求客户端必须访问Swift网关才能获得数据。而Ceph可以在每个存储节点上的OSD（对象存储设备）获取数据信息； 在数据一致性方面，Swift的数据是最终一致，而Ceph是始终跨集群强一致性）

2.5 Lustre分布式存储

        Lustre是基于Linux平台的开源集群（并行）文件系统，最早在1999年由皮特•布拉姆创建的集群文件系统公司（Cluster File Systems Inc.）开始研发，后由HP、Intel、Cluster File System和美国能源部联合开发，2003年正式开源，主要用于HPC超算领域。

2.5.1 Lustre的主要架构

Lustre组件包括：

• 管理服务器(MGS)：存放集群中所有Lustre文件系统的配置信息，Lustre客户通过联系MGS获取信息，可以与MDS共享存储空间
• 元数据服务器(MDS): 管理存储在MDT中的元数据，使存储在一个或多个MDT中的元数据可供Lustre客户端使用，每个MDS可管理一个或多个MDT。
• 元数据目标(MDT): MDS用于存储元数据(例如文件名，目录，权限和文件布局)，一个MDT可用于多个MDS，但一次只能有一个MDS访问
• 对象存储服务器(OSS)：为一个或多个本地OST提供文件I / O服务和网络请求处理, 通常，OSS服务于两个到八个OST
• 对象存储目标(OST)：用户文件数据存储在一个或多个对象中，每个对象位于单独OST中
• Lustre客户端：运行Lustre客户端软件的计算节点，可挂载Lustre文件系统。客户端软件包括一个管理客户端(MGC)，一个元数据客户端(MDC)和多个对象存储客户端(OSC)。每个OSC对应于文件系统中的一个OST。
• 逻辑对象卷(LOV)通过聚合OSC以提供对所有OST的透明访问，逻辑元数据卷(LMV)通过聚合MDC提供一种对所有MDT透明的访问。

2.5.2 Lustre特点

• 支持数万个客户端系统，支持PB级存储容量，单个文件最大支持320TB容量
• 支持RDMA网络，大文件读写分片优化，多个OSS能获得更高的聚合带宽
• 缺少副本机制，存在单点故障。如果一个客户端或节点发生故障，存储在该节点上的数据在重新启动前将不可访问
• 适用高性能计算HPC领域，适用于大文件连续读写。

2.6 主流分布式存储技术的比较

        几种主流分布式存储技术的特点比较如下：

         此外，根据分布式存储系统的设计理念，其软件和硬件解耦，分布式存储的许多功能，包括可靠性和性能增强都由软件提供，因此大家往往会认为底层硬件已不再重要。但事实往往并非如此，我们在进行分布式存储系统集成时，除考虑选用合适的分布式存储技术以外，还需考虑底层硬件的兼容性。一般而言，分布式存储系统的产品有三种形态：软硬件一体机、硬件OEM和软件+标准硬件，大家在选择时，需根据产品的成熟度、风险规避、运维要求等，结合自身的技术力量等，选择合适的产品形态。

3 参考链接

主流分布式存储技术的对比分析与应用 - fanyqing - twt企业IT交流平台

一文看懂分布式存储架构，这篇分析值得收藏-51CTO.COM

分布式存储主流框架 - 知乎

架构设计：系统存储（1）——块存储方案（1）_说好不能打脸的博客-CSDN博客_存储方案

Longhorn 云原生分布式块存储解决方案设计架构和概念

Longhorn 云原生分布式块存储解决方案设计架构和概念 - 为少 - 博客园

Ceph的整体架构介绍，这篇文章带入Ceph的大门

Ceph介绍及原理架构分享 - 简书

分布式存储架构_百度百科

Ceph介绍（一）：基本原理_Yannick_J的博客-CSDN博客_ceph

Openstack Swift 原理、架构与API介绍_HeyManLeader的博客-CSDN博客_swift架构

OpenStack Swift学习笔记_i_chips的博客-CSDN博客_openstack swift

OpenStack对象存储：Swift架构详解_西门仙忍的博客-CSDN博客_对象存储swift架构

《云原生进阶之容器》专题索引：

1. 第一章Docker核心技术1.1节——Docker综述
2. 第一章Docker核心技术1.2节——Linux容器LXC
3. 第一章Docker核心技术1.3节——命名空间Namespace
4. 第一章Docker核心技术1.4节——chroot技术
5. 第一章Docker核心技术1.5.1节——cgroup综述
6. 第一章Docker核心技术1.5.2节——cgroups原理剖析
7. 第一章Docker核心技术1.5.3节——cgroups数据结构剖析
8. 第一章Docker核心技术1.5.4节——cgroups使用
9. 第一章Docker核心技术1.6节——UnionFS
10. 第一章Docker核心技术1.7节——Docker镜像技术剖析
11. 第一章Docker核心技术1.8节——DockerFile解析
12. 第一章Docker核心技术1.9节——docker-compose容器编排
13. 第一章Docker核心技术1.10节——Docker网络模型设计
14. 第二章——Kubernetes概述
15. 第二章Controller Manager原理剖析--2.1节Controller Manager综述
16. 第二章Controller Manager原理2.2节--client-go剖析
17. 第二章Controller Manager原理2.3节--Reflector分析
18. 第二章Controller Manager原理2.4节--Informer机制剖析
19. 第二章Controller Manager原理2.5节--DeltaFIFO剖析
20. 第二章Controller Manager原理2.6节--Informer controller
21. 第二章Controller Manager原理2.7节--Indexer剖析
22. 第二章Controller Manager原理2.8节--Resync机制
23. 第三章List-Watch机制3.1节-- List-Watch机制剖析
24. 第四章Operator原理4.1节--定制资源（Custom Resource）
25. 第四章Operator原理4.2节--CRD
26. 第四章Operator原理4.3节--Operator模式
27. 第四章Operator原理4.4节--Operator深入实践
28. 第五章容器运行时5.1节--容器运行时总述
29. 第五章容器运行时5.2节--容器运行时接口规范CRI
30. 第五章容器运行时5.3.1--runC简介与使用
31. 第五章容器运行时5.3.2--runC原理解读
32. 第五章容器运行时5.4--容器运行时之Firecracker
33. 第五章容器运行时5.5--容器运行时之Kata Container
34. 第五章容器运行时5.6--容器运行时之gVisor
35. 第六章容器网络6.1--Docker网络模型
36. 第六章容器网络6.2--K8S网络模型
37. 第六章容器网络6.3--CNI及各CNI网络解决方案简述
38. 第六章容器网络6.4.1--Flannel组网方案综述
39. 第六章容器网络6.4.2--Flannel的安装与部署
40. 第六章容器网络6.4.3--Flannel网络模式
41. 第六章容器网络6.5.1--Calico网络方案综述
42. 第六章容器网络6.5.2--Calico网络架构详述
43. 第六章容器网络6.5.3--Calico安装与部署
44. 第六章容器网络6.6.1--Cilium网络方案概述
45. 第六章容器网络6.6.2--Cilium部署
46. 第六章容器网络6.7.1--阿里云Terway网络模式综述