Ceph工作原理详解_ceph作用

2401_84264010

于 2024-05-16 08:27:21 发布

阅读量982

点赞数 29

分类专栏： 2024年程序员学习文章标签：网络安全 web安全面试

本文链接：https://blog.youkuaiyun.com/2401_84264010/article/details/138941648

版权

2024年程序员学习专栏收录该内容

110 篇文章

订阅专栏

如何自学黑客&网络安全

黑客零基础入门学习路线&规划

初级黑客
1、网络安全理论知识（2天）
①了解行业相关背景，前景，确定发展方向。
②学习网络安全相关法律法规。
③网络安全运营的概念。
④等保简介、等保规定、流程和规范。（非常重要）

2、渗透测试基础（一周）
①渗透测试的流程、分类、标准
②信息收集技术：主动/被动信息搜集、Nmap工具、Google Hacking
③漏洞扫描、漏洞利用、原理，利用方法、工具（MSF）、绕过IDS和反病毒侦察
④主机攻防演练：MS17-010、MS08-067、MS10-046、MS12-20等

3、操作系统基础（一周）
①Windows系统常见功能和命令
②Kali Linux系统常见功能和命令
③操作系统安全（系统入侵排查/系统加固基础）

4、计算机网络基础（一周）
①计算机网络基础、协议和架构
②网络通信原理、OSI模型、数据转发流程
③常见协议解析（HTTP、TCP/IP、ARP等）
④网络攻击技术与网络安全防御技术
⑤Web漏洞原理与防御：主动/被动攻击、DDOS攻击、CVE漏洞复现

5、数据库基础操作（2天）
①数据库基础
②SQL语言基础
③数据库安全加固

6、Web渗透（1周）
①HTML、CSS和JavaScript简介
②OWASP Top10
③Web漏洞扫描工具
④Web渗透工具：Nmap、BurpSuite、SQLMap、其他（菜刀、漏扫等）
恭喜你，如果学到这里，你基本可以从事一份网络安全相关的工作，比如渗透测试、Web 渗透、安全服务、安全分析等岗位；如果等保模块学的好，还可以从事等保工程师。薪资区间6k-15k

到此为止，大概1个月的时间。你已经成为了一名“脚本小子”。那么你还想往下探索吗？

如果你想要入坑黑客&网络安全，笔者给大家准备了一份：282G全网最全的网络安全资料包评论区留言即可领取！

7、脚本编程（初级/中级/高级）
在网络安全领域。是否具备编程能力是“脚本小子”和真正黑客的本质区别。在实际的渗透测试过程中，面对复杂多变的网络环境，当常用工具不能满足实际需求的时候，往往需要对现有工具进行扩展，或者编写符合我们要求的工具、自动化脚本，这个时候就需要具备一定的编程能力。在分秒必争的CTF竞赛中，想要高效地使用自制的脚本工具来实现各种目的，更是需要拥有编程能力.

如果你零基础入门，笔者建议选择脚本语言Python/PHP/Go/Java中的一种，对常用库进行编程学习；搭建开发环境和选择IDE,PHP环境推荐Wamp和XAMPP， IDE强烈推荐Sublime；·Python编程学习，学习内容包含：语法、正则、文件、网络、多线程等常用库，推荐《Python核心编程》，不要看完；·用Python编写漏洞的exp,然后写一个简单的网络爬虫；·PHP基本语法学习并书写一个简单的博客系统；熟悉MVC架构，并试着学习一个PHP框架或者Python框架 (可选)；·了解Bootstrap的布局或者CSS。

8、超级黑客
这部分内容对零基础的同学来说还比较遥远，就不展开细说了，附上学习路线。

网络安全工程师企业级学习路线

如图片过大被平台压缩导致看不清的话，评论区点赞和评论区留言获取吧。我都会回复的

视频配套资料&国内外网安书籍、文档&工具

需要体系化学习资料的朋友，可以加我V获取：vip204888 （备注网络安全）

当然除了有配套的视频，同时也为大家整理了各种文档和书籍资料&工具，并且已经帮大家分好类了。

一些笔者自己买的、其他平台白嫖不到的视频教程。

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化资料的朋友，可以点击这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

一、Ceph概述

这里简单的说一下相关的组件，只是简单介绍

组件	概念
Monitor	一个Ceph集群需要多个Monitor组成的小集群，它们通过Paxos同步数据，用来保存OSD的元数据
OSD	OSD负责相应客户端请求返回具体数据的进程，一个Ceph集群一般都有很多个OSD
MSD	MSD 全称Cepg Metadata Service，是CephFs服务依赖的元数据服务
Object	Ceph最底层的存储单位是Object对象，每个Object包含元数据和原始数据
PG	PG全称Placement Groups，是一个逻辑的概念，一个PG包含多个OSD。引入PG这一层其实是为了更好的分配数据和定位数据
RADOS	是Ceph集群的精华,为用户实现数据分配，Failover等集群操作
Libradio	Libradio是Rados提供库，因为RADOS是协议很难直接访问，因此上层的RBD、RGW和CephFs都是通过librados访问的目前提供PHP、Ruby、Java、Python等支持
CRUSH	CRUSH是Ceph使用的数据分布算法，类似一致性哈希，让数据分配到预期的地方。
RBD	RBD全称RADOS block device，是Ceph对外提供的块设备服务
Image	RBD image是简单的块设备，可以直接被mount到主机，成为一个device，用户可以直接写入二进制数据。image的数据被保存为若干个RADOS对象存储中的对象；image的数据空间是thin provision的，意味着Ceph不预分配空间，而是等到实际写入数据时按照object分配空间；每个data object被保存为多份。pool将RBD镜像的ID和name等基本信息保存在rbd_directory中，这样rbd ls命令就可以快速返回一个pool中所有的RBD镜像了更多Image信息
RGW	RGW全称RADOS gateway，是Ceph对外提供的对象存储服务，接口与S3和Swift兼容
CephFs	CephFs全称Ceph File System，是Ceph对外提供的文件系统服务
Pool	pool 是Ceph存储时的逻辑分区，它起到namespace的作用

Ceph介绍

1、ceph是一个Linux PB级分布式文件系统，Linux持续不断进军可扩展计算空间，特别是可扩展存储空间。Ceph加入到Linux中令人印象深刻的文件系统备选行列，它是一个分布式文件系统，能够在维护POSIX兼容性的同时加入了复制和容错功能。

2、ceph 可以提供对象存储RODOSGW、块存储RBD、文件系统存储Ceph FS 三种功能，以此满足不同场景的应用需求。

3、优点：可轻松扩展到PB容量，对多种工作负载的高性能(每秒输入/输出操作[IOPS]和带宽),高可靠性。Ceph开发了一些非常有趣的概念(例如，动态元数据分区，数据分布和复制)。ceph的设计还保护单一点的故障容错功能，它假设大规模(PB级别存储)存储故障是常见现象而不是例外情况。它的设计并没有假设某种特殊工作负载，但是包括适应变化的工作负载，提供最佳性能的能力。它利用POSIX的兼容性完成所有这些任务，允许它对当前依赖POSIX语义
在这里插入图片描述

自下向上，可以将Ceph系统分为四个层次

(1) 基础存储系统RADOS(Reliable，Autonomic,Distributed,Object Store,即可靠、自动化、分布式的对象存储) 顾名思义，这一层本身就是一个完整的对象对象存储系统，所有存储在Ceph系统中的用户数据事实上最终都是由这一层来存储的。而Ceph高可靠、高可扩展、高性能、高自动化等等特性本质上也是由这一层所提供的。因此，理解RADOS是理解Ceph的关键与基础

(2)基础库librados 这一层的功能是对RADOS进行抽象和封装，并向上层提供API，以便直接基于RADOS(而不是整个Ceph)进行应用开发。需要注意的是RADOS是一个对象存储系统。因此，librados实现的API也只是针对对象存储功能的

RADOS采用C++开发，所提供的原生librados API包括C和C++两种，物理上，librados和基于其上开发的应用位于同一台机器，因而也被成为本地API。应用调用本机上的librados API，再由后者通过socket与RADOS集群中的节点通信并完成各种操作。

(3)高层应用接口 这一层包括了三个部分：RADOS GWRADOS Gateway 、RBD Reliable Block Device和Ceph FS Ceph File System其作用是在librados库的基础上提供抽象层次更高的，更便于应用或客户端使用的上层接口

其中,RADOS GW是一个提供Amazon S3和Swift(内置大容量硬盘的分布式服务器)兼容的RESTful API的Gateway，以提供相应的对象存储应用开发使用。RADOS GW提供的API抽象层次更好，但功能则不如librados强大，应为开发者针对自己的需求选择使用

RBD则提供了一个标准的块设备接口，常用于在虚拟化的场景下为虚拟机创建Volume。目前，Red Hat 已经将RBD驱动集成在KVM/QEMU中，以提供虚拟机访问性能

Ceph FS是一个POSIX兼容的分布式文件系统,Ceph提供了POSIX接口，用户可以直接通过客户端挂载使用。它是内核态的程序，所以无需调用用户空间的librados库。通过内核中的net模块来和Rados进行交互

1.1 RADOS逻辑架构在这里插入图片描述

在使用RADOS系统时，大量的客户端程序通过OSD或者Monitor的交互获取cluster map，然后再本地进行计算，得出对象的存储位置后，便直接与对应的OSD通信，完成数据的各种操作。只要我们保证cluster map不频繁更新，则客户端显然可以不依赖任何元数据服务器，不进行任何查表操作，便完成数据访问流程。在RADOS的运行过程中，cluster map的更新完全取决于系统的状态变化，而导致这一变化的常见事件只有两种：OSD出现故障，或者RADOS规模扩大。而正常应用场景下，这俩种事件发生的频率显然远远低于客户端对数据进行访问的频率。

1.2 OSD逻辑结构

根据定义，OSD可以被抽象为两个组成部分，即系统部分和守护进程(OSD daemon)部分

OSD的系统部分本质上就是一台安装了操作系统和文件系统的计算机，其硬件部分至少包括一个单核的处理器、一定数量的内存、一块硬盘以及一张网卡。

由于这么小的规模的x86架构服务器并不实用,因而实际应用中通常将多个OSD集中部署在一台更大规模的服务器上。在选择系统配件时，应当能够保证每个OSD占用一定的计算能力、一定量的内存和一块硬盘。同时，应当保证该服务器具备足够的网络带宽

每个OSD拥有一个自己的OSD deamon。这个deamon负责完成OSD所有逻辑功能，包括与monitor和其他OSD(事实上是其他OSD的daemon)通信以维护更新系统状态，与其他OSD共同完成数据的存储和维护，与client通信完成各种数据对象操作等
在这里插入图片描述

RADOS集群主要两种节点：一种是为数众多的、负责完成数据存储和维护功能的OSD(Object Storage Device),另一种则是若干负责完成系统状态监测和维护的monitor。OSD和monitor之间相互传输节点状态信息，共同得出系统的总工作状态，并形成一个全局系统状态记录数据结构，即所谓的cluster nao。这个数据结构与RADOS提供的特定的算法相配合，便实现了Ceph无需查表，算算就好的核心机制以及若干优秀特性。

1.2 Ceph 基本组件

在这里插入图片描述

1.OSD 用于集群中所有数据与对象的存储。处理集群数据的复制、恢复、回填、再均衡。并向其他OSD守护进程发送心跳，然后向Mon提供一些监控信息。当Ceph存储集群设定数据有两个副本时(一共存2份),则至少需要两个OSD守护进程即两个OSD节点，集群才能达到active+clean状态

2.MSD 为Ceph文件提供元数据计算、缓存与同步。在Ceph中，元数据也是存储在osd节点中的，马上到！类似于元数据的代理缓存服务器。msd进程并不是必须的进程，只有使用Cephfs时，才需要配置msd

3.Monitior 监控整个集群的状态，维护集群的cluster MAP二进制表，保证集群数据的一致性。Cluster MAP描述了对象存储的物理位置，以及将一个设备聚合到服务位置的桶列表。

1.3 Ceph存储过程 (Ceph IO算法流程)

在这里插入图片描述

1.File----此处的File就是用户要存储或者访问的文件。对于一个基于Ceph开发的对象存储应用而言，这个File也就是对应于应用中的对象，也就是用户直接操作的对象

2.Objects----此处的Objects是RADOS所看到的对象。Object与上面提到的File的区别是，Object的最大Size由RADOS限定(通常为2MB或4MB),以便实现底层存储的组织管理。因此，当上层应用向RADOS存储size很大的file时，需要将file切分统一大小的一系列object(最后一个的大小可以不同)进行存储。

3.PG (Placement Group)----顾名思义，PG的用途是对object的存储进行组织和位置映射。一个PG负责若干个object(可以为数前个甚至更多)，但一个object只能被映射到一个PG中，即，PG和object之间是一对多映射关系。同时，一个PG会被映射到n个OSD上，而每个OSD上都会承载大量的PG，即，PG和OSD之间是多对多映射关系。如果用于生产环境，OSD至少为3.一个OSD上的PG则可达到数百个。事实上，PG数量的设置牵扯到数据分布的均衡性问题。

4.OSD ----即object storage device 需要说明的是OSD的数量事实上也关系到系统的数据分布均衡性，因此数量不能太少。

5.Failure domain ----这个概念在论文中并没有进行定义，此处不过多解释

基于上述定义，Ceph中的寻址至少要经历下面三次映射✌️

1️⃣ File->object 这次映射的目的是，将用户要操作的file，映射为RADOS能够处理的object。其映射十分简单，本质上就是按照object的最大size对file进行切分。这种切分的好处有2点。一是让大小不限的file变成最大size一致、可以被RADOS高效管理的object；二是让对单一file实施的串行处理变为多个object实施并行化处理

每一个切分后产生的object将获得唯一的oid，即object id。其产生方式也是线性映射，图中ino是待操作file的元数据，可以简单理解为该file的唯一id。ono则是由该file切分产生的某个object的序号。而oid就是将这个序号简单连缀在该file id之后得到的。

举例而言，如果一个id为filename的file被切分成了三个object，则其object序号依次为0、1和2，而最终得到oid就依次为filename0、filename1和filename2. 这里隐含的问题是，ino的唯一性必须得到保障，否则后续无法正常进行

2️⃣ Object->PG映射 在file映射为一个或多个object之后，就需要将每个object独立地映射到一个PG中去

计算公式如下

hash(oid) & mask -> pgid

由此可见，其计算由两步组成。首先是使用Ceph系统指定的静态哈希函数计算oid的哈希值，将oid映射成一个近似均衡分布的伪随机值。然后，将这个随机值和mask按位相与，得到最终的PG序号(pgid)。根据RADOS的设计，给定PG的总数为m(m应该是为2的整数)，则mask的值为-1。因此，哈希值计算和操作结果事实上是从所有m个PG中近似均匀的随机选择一个。基于这个机制，当有大量的object和大量PG时，RADOS能够保证object和PG之间的近似均匀映射。又因为object是由file切分而来，大部分object的soze相同，因而这一映射最终保证了，各个PG中存储的object的总数据量近似均匀

只有当object和PG的数量较多时，这种伪随机关系的近似均匀性才能成立，Ceph的数据存储均匀性才有保证。为保证大量成立，以方便，object的最大size应该被合理配置，以使得同样数量的file能够被切分更多的object；另一方面，Ceph推荐PG总数应该为OSD总数的数百倍，以保证有足够数量的PG可供映射。

3️⃣PG->OSD映射 第三次映射就是作为object的逻辑组织单元的PG映射到数据的实际存储单元OSD,RADOS采用一个名为CRUSH的算法，将pgid带入其中，然后得到一共n个OSD。这n个OSD即共同负责存储和维护一个PG中所有的object。前面已经描述，n的数值可以根据实际应用中对于可靠性的需求而配置，生产环境通常为3.具体到每个OSD。则由其上的OSD daemon负责执行映射到本地的object在本地文件系统中的存储、访问、元数据维护等操作

和object->PG映射中采用的哈希算法不同，这个CCRUSH算法的结果不是绝对不变的，而是受到其他因素的影响。其影响因素主要有二点：

一是当前系统状态，也就是上文逻辑结构中曾经提及的cluster map。当系统中的OSD状态、数量发生变化时，cluster map可能发生变化，而这种变化会影响到PG与OSD之间的映射

二是存储策略配置。这里的策略主要与安全相关，利用策略配置，系统管理员可以指定承载同一个PG的3个OSD分别位于数据中心的不同服务器乃至机架上，从而进一步改善存储的可靠性。

因此，只有在系统状态cluster map和存储策略都不发生变化的时候，PG和OSD之间的映射关系才是稳定不变的。在实际使用中，策略已经配置通常不会改变。而系统状态的改变或者是由于设备损坏，或者是因为存储集群规模扩大。好在Ceph本身提供了对这种变化的自动化支持。因而，即便PG与OSD之间的映射关系发生了变化，也并不会对应用造成困扰。事实上，Ceph正是需要有目的的利用这种动态映射关系。正是利用了CRUSH的动态特性，Ceph可以将一个PG根据需要动态迁移到不同的OSD组合上，从而自动化地实现高可靠性、数据分布性等。

至此为止，Ceph通过三次映射，完成了从file到object、PG和OSD整个映射过程。通过整个过程可以看到没有任何的全局性查表操作需求。至于唯一的全局性数据结构cluster map的维护和操作都是轻量级的，不会对系统的可扩展性、性能等因素造成不良的影响

一个可能出现困惑的问题：为什么需要同时设计出第二次和第三次映射？难道不重复吗

如果没有PG这一层映射，通过算法将object直接映射到一组OSD上。如果这种算法是某种固定映射的哈希算法，则意味着一个object将被固定在一组OSD上，当其中一个或多个OSD损坏时，object无法被自动迁移至其他OSD上(因为映射函数不允许)，当系统为了扩容新增了OSD时，object也无法被re-balance到新的OSD上(同样因为函数不允许）这些限制都违背了Ceph系统的高可靠性、高自动化的设计初衷

例如，在Ceph的现有机制中，一个OSD平时需要和与其共同承载一个PG的其他OSD交换信息，以确定各自是否工作正常，是否需要进行维护操作。由于一个OSD上约承载数百个PG，每个PG内通常有3个OSD，因此，一个OSD大约需要进行数百至数千次OSD信息交换

然后，如果没有PG的存在，则一个OSD需要和与其共同承载同一个object的其他OSD交换信息。由于每个OSD上承载的object很可能高达数百万个，因此同样长度的一段时间内，一个OSD大约需要进行的OSD间信息交换将暴涨至数百万乃至数千万次。而这种状态维护成本显然过高

总结：引入PG的好处有两种，一方面实现了object和OSD之间的动态映射，从而为Ceph的可靠性、自动化性等特征的实现留下了空间；另一方面也有效简化了数据的存储组织，大大降低了系统的维护管理开销。

1.4 Ceph集群

前面说过，monitor共同负责整个Ceph集群中所有OSD状态的发现与记录，并且共同形成cluster map的master版本，然后扩散至全体OSD以及client。OSD使用cluster map进行数据的维护，而client 使用cluster map进行数据的寻址。

在集群中，各个monitor的功能总体上是一样的，其相互间的关系可以简单理解为主从备份关系。monitor并不主动轮询各个OSD的当前状态。正相反，OSD需要向monitor上报信息状态。常见的上报情况有两种：一是新的OSD被加入集群，二是某个OSD发现自身或者其他OSD发生异常。在收到这些上报信息，monitor将更新cluster map的信息并加以扩散。

Cluster map包含如下内容 命令:ceph -s

（1) Eposh 即版本号。Cluster map的epoch是一个单调递增序列。Epoch越大，则cluster map版本越新。因此，持有不同版本cluster map的OSD或client可以简单的通过比较epoch决定应该遵从谁手中的版本。而monitor手中必定有epoch最大、版本最新的cluster map。当任意两方在通信时发现彼此epoch值不同时，将默认先将cluster map同步至高版本一方的状态。在进行后续状态
在这里插入图片描述

(2) health 集群内部健康状态，显示这台服务器在集群内部的状态
在这里插入图片描述

(3) monmap 各个OSD的网络地址

在这里插入图片描述

(4) osdmap 各个OSD的状态。OSD状态分为两个维度：up或者down (表示OSD是否正常工作)，in或者out (表示OSD是否在至少一个PG中)。因此，对于任意一个OSD，共有四种可能的状态

状态	说明
Up且in	说明该OSD正常运行，且已经承载至少一个PG的数据。这是一个OSD的标准工作状态；
Up且out	明该OSD正常运行，但并未承载任何PG，其中也没有数据。一个新的OSD刚刚被加入Ceph集群后，便会处于这一状态。而一个出现故障的OSD被修复后，重新加入Ceph集群时，也是处于这一状态；
Down且yin	说明该OSD发生异常，但仍然承载着至少一个PG，其中仍然存储着数据。这种状态下的OSD刚刚被发现存在异常，可能仍能恢复正常，也可能会彻底无法工作
Down且out	说明该OSD已经彻底发生故障，且已经不再承载任何PG

在这里插入图片描述

(5) pgmap 集群中pg、pools、磁盘大小等信息
在这里插入图片描述

1.5 Ceph特点

介绍了这么多ceph的信息，我们这里做一个总结

高性能 a.摒弃了传统的集中式存储元数据寻址的方案，采用CHUSH算法，数据分布均衡，并行度高。 b.考虑了容灾域的隔离，能够实现各类的副本放置规则，例如跨机房、机架感知等。 c.能够支持上千个存储节点的规模，支持TB到PB的数据
高可用性 a.副本数可以灵活控制。 b.支持故障域分隔，数据强一致性。 c.多种故障场景自动进行修复自愈。 d.没有单点故障，自动管理。
高可扩展性 a.去中心化。 b.扩展灵活 c.随着节点增加而线性增长
特性丰富 a.支持三种存储接口：块存储、文件存储、对象存储 b.支持自定义接口，支持多种语言驱动

1.6 Ceph架构

Ceph支持三种接口

Object:有原生的API，并且也兼容Swift和S3的api
Block:支持精简配置、快照和克隆
File:Posix接口、支持快照

1.7 Ceph核心组件及概念

组件	概念
Monitor	一个Ceph集群需要多个Monitor组成的小集群，它们通过Paxos同步数据，用来保存OSD的元数据
OSD	OSD负责相应客户端请求返回具体数据的进程，一个Ceph集群一般都有很多个OSD
MSD	msd全称Cepg Metadata Service，是CephFs服务依赖的元数据服务
Object	Ceph最底层的存储单位是Object对象，每个Object包含元数据和原始数据
PG	PG全称Placement Groups，是一个逻辑的概念，一个PG包含多个OSD。引入PG这一层其实是为了更好的分配数据和定位数据
RADOS	是Ceph集群的精华,为用户实现数据分配，Failover等集群操作
Libradio	Libradio是Rados提供库，因为RADOS是协议很难直接访问，因此上层的RBD、RGW和CephFs都是通过librados访问的目前提供PHP、Ruby、Java、Python等支持
CRUSH	CRUSH是Ceph使用的数据分布算法，类似一致性哈希，让数据分配到预期的地方。
RBD	RBD全称RADOS block device，是Ceph对外提供的块设备服务
RGW	RGW全称RADOS gateway，是Ceph对外提供的对象存储服务，接口与S3和Swift兼容
CephFs	CephFs全称Ceph File System，是Ceph对外提供的文件系统服务
Pool	pool 是Ceph存储时的逻辑分区，它起到namespace的作用

二、三种存储类型

2.1 块存储 rbd

在这里插入图片描述

典型设备：磁盘阵列，硬盘主要是将裸磁盘空间映射给主机使用的

优点

通过Raid与LVM等手段，对数据提供了保护
多块廉价的硬盘组合起来，提高容量
多块磁盘组合出来的逻辑盘，提高读写效率

缺点

采用SAN架构组网时，光纤交换机，造价成本高
主机之间无法共享数据

使用场景

docker容器、虚拟机磁盘存储分配
日志存储
文件存储
等等…

2.2 文件存储 fs

在这里插入图片描述

典型设备：FTP、NFS服务器为了克服块存储文件无法共享的问题，所以有了文件存储。在服务器上架设FTP与NFS服务，就是文件存储

优点

造价低，随便一台机器就可以了
方便文件共享

缺点

读写速度低
传输速度慢

使用场景

日志存储
有目录结构的文件存储

2.3 对象存储 rgw

在这里插入图片描述

典型设备：内置大容量硬盘的分布式服务器(swift、s3) 多台服务器内置大容量硬盘，安装上对象存储管理软件，对外提供读写访问功能。

优点

具备块存储的读写高速
具备文件存储的共享等特性

使用场景 (适合更新变动比较少的数据)

图片存储
视频存储

3.1 正常io流程图

在这里插入图片描述

1.client创建cluster handler 2.client读取配置文件 3.client连接上monitor，获取集群map信息 4.client读写io根据crshmap算法请求对应的主osd数据节点 5.主osd数据节点同时写入另外两个副本节点数据 6.等待主节点以及两个副本节点写完数据状态 7.主节点及副本节点写入状态都成功后，返回给client，io写入完成。