‘壹’ 分布式存储有哪几种类型
分布式存储，分为文件存储，块存储和对象存储，是存储设备提供的不同类型的服务，适配不同的使用场景。
分布式是存储设备的部署方式，是部署在一台机器上，还是一个多台设备组成的集群中。软件定义这个概念比较宽泛，是指通过软件功能来实现曾经通过专用硬件完成的工作，也就是说，对于存储硬件已经没有要求了，用通用硬件+存储软件来实现将一台服务器，变成存储设备。其实无论是不是软件定义存储，其内部都运行着存储系统软件，把这个词单拿出来，就是更加强调其对于硬件的无要求。
‘贰’ 分布式块存储系统是什么东西
分布是块存储系统一般是块设备存储用于为虚拟机提供volume，作用和AWS的EBS一样。在Openstack以前的版本中，是由nova-volume提供快设备存储服务，但是从F版本以后，就创建了一个新的项目cinder，用于取代nova-volume。openstack cinder就是一种分布式块存储系统。
‘叁’ 深挖Kubernetes存储为何如此难及其解决方案
以Kubernetes为代表的容器编排工具在应用开发部署领域起正发挥着颠覆性的变革作用。随着微服务架构的发展，从开发人员的角度来看，应用逻辑架构与基础设施架构之间开始解耦，这意味着开发者能够将精力更多集中在软件构建以及价值交付身上。
当管理Docker镜像的时候，Kubernetes也让实际应用变的十分便捷灵活。在利用Kubernetes进行容器架构的应用部署时，管理员们将在无需修改底层代码的前提下将其部署在任何位置——包括公有云、混合云乃至私有云。
虽然Kubernetes在扩展性、便携性与管理性等方面的表现都相当给力，但截至目前，它仍然不支持存储状态。与之对应的是，如今的大多数应用都是有状态的——换言之，要求在一定程度上配合外部存储资源。
Kubernetes架构本身非常灵活的，能够根据开发者的需求、规范以及实际负载情况，对容器进行随意创建与撤销。此外，Pod和容器还具有自我修复与复制能力。因此从本质上讲，它们的生命周期普遍非常短暂。
但是，现有持久存储解决方法无法支持动态的应用场景，而持久化存储也无法满足动态创建与撤销的需求。
当我们需要将有状态应用部署到其它基础架构平台，或者另一家内部或混合云供应商的环境中时，可移植性低下无疑将成为我们面临的巨大挑战。更具体地讲，持久化存储解决方案往往会锁定于特定云服务供应商，而无法灵活完成转移。
另外，云原生应用中的存储机制也相当复杂、难于理解。Kubernetes中的不少存储术语极易混淆，其中包含着复杂的含义与微妙的变化。再有，在原生Kubernetes、开源框架以及托管与付费服务之间还存在着诸多选项，这极大增加了开发人员在做出决定之前的考量与试验成本。
以下是CNCF列出的云原生存储可选方案：
我们首先从最简单的场景出发，即在Kubernetes当中部署一套数据库。具体流程包括：选择一套符合需求的数据库，让它在本地磁盘上运行，然后将其作为新的工作负载部署到集群当中。但是，由于数据库中存在的一些固有属性，这种方式往往无法带来符合预期的效果。
容器本身是基于无状态原则进行构建的，凭借这一天然属性，我们才能如此轻松地启动或撤销容器环境。由于不存在需要保存及迁移的数据，集群也就不需要同磁盘读写这类密集型操作绑定在一起了。
但对于数据库，其状态必须随时保存。如果以容器方式部署在集群当中的数据库不需要进行迁移，或者不需要频繁开关，那么其基本属性就相当于一种物理存储设备。在理想情况下，使用数据的容器应该与该数据库处于同一Pod当中。
当然，这并不是说将数据库部署在容器中的作法不可取。在某些应用场景下，这样的设计完全能够满足需求。举例来说，在测试环境或者处理非生产级数据时，由于总体数据量很小，将数据库纳入集群完全没有问题。但在实际生产中，开发人员往往需要仰仗于外部存储机制。
Kubernetes到底是如何与存储资源彼此通信的？其利用的是控制层接口。这些接口负责将Kubernetes与外部存储相对接。接入Kubernetes的外部存储解决方案被称为“卷插件（Volume Plugins）”。正是有了卷插件的存在，存储资源才得以抽象化并实现可移植性。
以前，卷插件一般由核心Kubernetes代码库进行构建、链接、编译以及装载。这样就极大的限制了开发人员的发挥空间，同时也带来了额外的维护开销。因此，项目维护人员们决定在Kubernete的代码库上增加一些新的存储功能。
随着CSI以及Flexvolume的引入，卷插件如今可以在集群中直接部署，而完全无需更改代码库。
原生Kubernetes与存储
持久卷是由管理员负责配置的存储单元，它们独立于任何单一Pod之外，因此不受Pod生命周期的影响。
存储资源有两种使用方式：静态存储与动态存储。
实际上，静态定义的持久卷并不能适应Kubernetes的可移植特性，因为存储资源具有对环境的依赖性——例如AWS EBS或者GCE Persistent Disk。另外，手动绑定还需要根据不同供应商的存储方案修改YAML文件。
在资源分配方面，静态配置实际上也违背了Kubernetes的设计原则。后者的CPU与内存并非事先被分配好绑定在Pod或者容器上，而是以被动态形式进行分配。
通过简单的说明，相信大家已经了解了原生Kubernetes对外部存储资源的使用方式。当然，这里仅仅做出概括，实际使用场景中还有更多其它因素需要考量。
CSI——容器存储接口
下面来看容器存储接口（简称CSI）。CSI是由CNCF存储工作组创建的统一标准，旨在定义一个标准的容器存储接口，从而使存储驱动程序能够在任意容器架构下正常起效。
CSI规范目前已经在Kubernetes中得到普及，大量驱动插件被预先部署在Kubernetes集群内供开发人员使用。如此一来，我们就可以利用Kubernetes上的CSI卷来访问与CSI兼容的开放存储卷。
CSI的引入，意味着存储资源能够作为Kubernetes集群上的另一种工作负载实现容器化以及部署。
相关开源项目
目前，围绕云原生技术涌现出大量工具与项目。但作为生产场景中的一大突出问题，我们往往很难在云原生架构中选择最合适的开源项目。换言之，解决方案选项太多，反而令存储需求变得更难解决。
我们再看一次CNCF列出的云原生存储的可选方案：
下面我会分享一下当下流行的存储方案Ceph与Rook，还有Rancher开源的容器化分布式存储Longhorn。
Ceph
Ceph是一种动态托管、横向扩展的分布式存储集群。Ceph面向存储资源提供一种逻辑抽象机制，其设计理念包括无单点故障、自管理以及软件定义等特性。Ceph可以面向同一套存储集群分别提供块存储、对象存储以及文件存储的对应接口。
Ceph架构相当复杂的，其中使用到大量的底层技术，例如RADOS、librados、RADOSGW、RDB、CRUSH算法，外加monitor、OSD以及MDS等功能性组件。这里我们先不谈它的底层架构，关键在于Ceph属于一种分布式存储集群，这使得扩展更便利、能够在不牺牲性能的前提下消除单点故障，且提供涵盖对象存储、块存储以及文件存储的统一存储体系。
Ceph架构图
Rook
另一个有趣且颇具人气的项目是Rook，这是一项旨在将Kubernetes与Ceph融合起来的技术方案。从本质上讲，它将计算节点和存储节点放进了同一个集群当中。
Rook是一种云原生编排器，并对Kubernetes做出扩展。Rook允许用户将Ceph放置在容器内，同时提供卷管理逻辑以立足Kubernetes之上实现Ceph的可靠运行。Rook还使本应由集群管理员操作的多种任务完成了自动化实现，其中包括部署、引导、配置、扩展以及负载均衡等等。
Rook自身不具备持久状态，也不需要单独管理。这，才是真正与Kubernetes设计原则相符的存储资源管理方案。
Rook凭借着将Ceph与Kubernetes协同起来的强大能力而颇受欢迎，在GitHub上获得近4000颗星，1600多万次的下载，并吸引到100多名贡献者，现已进入CNCF孵化阶段。
Longhorn
Longhorn项目是Rancher Labs推出的开源的基于云和容器部署的分布式块存储新方式。Longhorn遵循微服务的原则，利用容器将小型独立组件构建为分布式块存储，并使用容器编排来协调这些组件，形成弹性分布式系统。
如今，基于云和容器的部署规模日益扩大，分布式块存储系统也正变得越来越复杂，单个存储控制器上的volume数量在不断增加。2000年代初，存储控制器上的volume数量只有几十个，但现代云环境却需要数万到数百万的分布式块存储卷。存储控制器变成了高度复杂的分布式系统。
Longhorn充分利用了近年来关于 如何编排大量的容器和虚拟机的核心技术 。例如，Longhorn并没有构建一个可以扩展到100,000个volume的高度复杂的控制器，而是出于让存储控制器简单轻便的考虑，创建了100,000个单独的控制器。然后，我们可以利用像Kubernetes这样的最先进的编排系统来调度这些独立的控制器，共享一组磁盘中的资源，协同工作，形成一个弹性的分布式块存储系统。
Longhorn基于微服务的设计还有很多其他优势。因为每个volume都有自己的控制器，在升级每个volume的控制器和replica容器时，是不会导致IO操作明显的中断的。Longhorn可以创建一个长期运行的工作来编排所有live volume的升级，同时确保不会中断系统正在进行的操作。为确保升级不会导致意外的问题，Longhorn可以选择升级一小部分volume，并在升级过程中出现问题时回滚到旧版本。这些做法在现代微服务应用中已得到广泛应用，但在存储系统中并不常见。希望Longhorn可以 助力于微服务在存储领域的更多应用。
结 语
对于实际应用层面出现的任何问题，最重要的自然是判断需求、设计系统或者选择适当的工具。同样的道理也适用于云原生环境。虽然具体问题非常复杂，但也必然会出现大量工具方案尝试解决。随着云原生世界的持续发展，我们可以肯定，新的解决方案将不断涌现。未来，一切都会更加美好！
‘肆’ 分布式存储选型
云计算场景中, 通常使用对象存储系统来做保存文件, 例如用户上传的图片, 视频, 文档等, 或是虚拟镜像, iso镜像的内部数据. 公有云厂商通常还会基于对象存储提供SDN服务, 用来加速用户数据的访问. 而块存储则作为一种补充, 提供独立于虚拟机的(虚拟机删除数据不丢失), 方便扩展的存储设备.
对象存储由于是通过网络API提供服务的, 所以可以跨集群访问.
集群内文件共享的方案非常多, windows上的共享磁盘, linux 上的samba, nfs 等项目都提供这样的功能. 集群文件系统通常会和NAS进行对比, 以体现其在成本方面的优势. 但是, 由于传统的基于共享磁盘的集群文件系统在可扩展性方面比较弱, 有催生的分布式的集群文件系统, moosefs 就是典型的分布式集群文件系统.
集群文件系统也可以用来存储虚拟机镜像, 已达到存储节点和计算节点的分离.
直观上看, 对象存储系统与业务系统是平行关系, 而集群文件系统则通常是业务系统的一个组成部分.
分布式存储目前主要分两大类: 块存储(文件系统, 裸设备), 对象存储. 像 NFS 这样只提供, 只提供简单磁盘共享, 缺乏扩展能力的项目, 只能叫集群存储, 而不能算分布式存储.
考虑到未来分布式存储的可能有多种应用场景, 所以我们更关注各个方案的功能是否完备. 以下是本次选型的标准.
|-|Ceph |Taobao TFS |Openstack Swift |MooseFS |
|----|----|----|----|----|----|
|MetaData冗余[1] |YES[选举] |YES[主从] |NO[3] |YES[主从]
|数据冗余[2] |YES |YES |YES |YES
由于块存储是直接挂载到操作系统上使用的, 除了使用软件本身的配额管理工具, 还可以使用操作系统的配个管理工具来实现基于用户的容量配额管理.
根据前述选项标准, 这里推荐部署Ceph系统.
‘伍’ NeonIO 云原生存储简介与应用
NeonIO 是一款支持容器化部署的企业级分布式块存储系统，能够给 Kubernetes 平台上提供动态创建（dynamic provisioning）持久存储卷（persistent volume）的能力，支持 clone、snapshot、resstore、resize 等功能。
NeonIO 架构如图上所示。
(1) 组件容器化：服务组件、CSI、Portal 容器化。
(2) 支持 CSI：提供标准的 IO 接入能力，可静态、动态创建 PV。
(3) UI 界面，运维方便：
(4) 与云原生高度融合：
(5) 一键式部署：helm install neonio ./neonio -- namespace kube-system。
(6) 部署简单灵活：和 Rook-Ceph 对比：
(1) 全闪的分布式存储架构
(2) 极短的 IO 路径：抛弃文件系统，自研元数据管理系统，使 IO 路径极短
(3) 使用 HostNetwork 网络模式
好处：
(1) 服务组件可靠性与可用性
(2) 数据的可靠性与可用性
(1) Pod 跨节点重建高效：2000PV 的挂载/卸载 16s。
(2) 批量创建 PV 能力：2000PV 的创建 5min。
测试平台：NeonIO 超融合一体机集群（3 个节点，192.168.101.174 - 192.168.101.176）。
注意：所有测试均使用 NVMe SSD，卷大小 = 1TiB。性能工具： https://github.com/leeliu/dbench
图中黄色表示的是 NeonIO，第一张图纵坐标是 IOPS，第二张图纵坐标是毫秒，从结果来看，无论是单副本还是 3 副本，NeonIO 在 IOPS、时延都有明显的优势。
存储大师班 | ZFS存储池块管理与事务模型
对象存储手把手教四 | Bucket 生命周期管理
‘陆’ 分布式存储是什么东西
关于分布式存储实际上并没有一个明确的定义，甚至名称上也没有一个统一的说法，大多数情况下称作 Distributed Data Store 或者 Distributed Storage System。
其中维基网络中给 Distributed data store 的定义是：分布式存储是一种计算机网络，它通常以数据复制的方式将信息存储在多个节点中。
在网络中给出的定义是：分布式存储系统，是将数据分散存储在多台独立的设备上。分布式网络存储系统采用可扩展的系统结构，利用多台存储服务器分担存储负荷，利用位置服务器定位存储信息，它不但提高了系统的可靠性、可用性和存取效率，还易于扩展。
尽管各方对分布式存储的定义并不完全相同，但有一点是统一的，就是分布式存储将数据分散放置在多个节点中，节点通过网络互连提供存储服务。这一点与传统集中式存储将数据集中放置的方式有着明显的区分。
‘柒’ 分布式存储是什么
分布式存储系统，是将数据分散存储在多台独立的设备上。传统的网络存储系统采用集中的存储服务器存放所有数据，存储服务器成为系统性能的瓶颈，也是可靠性和安全性的焦点，不能满足大规模存储应用的需要。分布式网络存储系统采用可扩展的系统结构，利用多台存储服务器分担存储负荷，利用位置服务器定位存储信息，它不但提高了系统的可靠性、可用性和存取效率，还易于扩展。
分布式和集中式存储
集中存储的优缺点是，物理介质集中布放;视频流上传到中心对机房环境要求高，要求机房空间大，承重、空调等都是需要考虑的问题。
分布存储，集中管理的优缺点是，物理介质分布到不同的地理位置;视频流就近上传，对骨干网带宽没有什么要求;可采用多套低端的小容量的存储设备分布部署，设备价格和维护成本较低;小容量设备分布部署，对机房环境要求低。
链乔教育在线旗下学硕创新区块链技术工作站是中国教育部学校规划建设发展中心开展的“智慧学习工场2020-学硕创新工作站 ”唯一获准的“区块链技术专业”试点工作站。专业站立足为学生提供多样化成长路径，推进专业学位研究生产学研结合培养模式改革，构建应用型、复合型人才培养体系。
‘捌’ 对象存储、块存储、文件存储分别是什么有什么区别
你可以把块理解成整个硬盘，文件理解成硬盘中的文件，对象理解成很多台服务器中的很多块硬盘。
‘玖’ 对象存储、文件存储和块存储有什么区别
区别如下：
1、速度不同
块存储：低延迟（10ms），热点突出；
文件存储：不同技术各有不同；
对象存储：100ms-1s，冷数据；
2、可分步性不同
块存储：异地不现实；
文件存储：可分布式，但有瓶颈；
对象存储：分步并发能力高；
3、文件大小不同
块存储：大小都可以，热点突出；
文件存储：适合大文件；
对象存储：适合各种大小；
4、接口不同
块存储：Driver，kernel mole ；
文件存储：POSIX；
对象存储：Restful API ；
5、典型技术不同
块存储：SAN；
文件存储：HDFS，GFS；
对象存储：Swift，Amazon S3；
6、适合场景不同
块存储：银行；
文件存储：数据中心；
对象存储：网络媒体文件存储；
(9)分布式块存储的存储卷扩展阅读：
文件存储的优缺点：
优点
（1）、造价低：随便一台机器就可以，另外普通的以太网就可以，根本不需要专用的SAN网络，所以造价低。
（2）、方便文件共享。
缺点
（1）、读写速率低，传输速率慢：以太网，上传下载速度较慢，另外所有读写都要1台服务器里面的硬盘来承受，相比起磁盘阵列动不动就十几上百块硬盘同时读写，速率慢了许多。
‘拾’ 分布式存储的三种类型
有关分布式存储的三个基本问题
文件系统vs对象存储——选型和趋势
块存储、文件存储、对象存储这三者的本质差别是什么
分布式存储的应用场景相对于其存储接口，现在流行分为三种:
对象存储: 也就是通常意义的键值存储，其接口就是简单的GET、PUT、DEL和其他扩展，如七牛、又拍、Swift、S3
块存储: 这种接口通常以QEMU Driver或者Kernel Mole的方式存在，这种接口需要实现Linux的Block Device的接口或者QEMU提供的Block Driver接口，如Sheepdog，AWS的EBS，青云的云硬盘和阿里云的盘古系统，还有Ceph的RBD（RBD是Ceph面向块存储的接口）
文件存储: 通常意义是支持POSIX接口，它跟传统的文件系统如Ext4是一个类型的，但区别在于分布式存储提供了并行化的能力，如Ceph的CephFS(CephFS是Ceph面向文件存储的接口)，但是有时候又会把GFS，HDFS这种非POSIX接口的类文件存储接口归入此类。