信息以文件形式存储,文件用什么分类分层存放

文件、块和对象是三种以不同的方式来保存、整理和呈现数据的存储格式。这些格式各有各的功能和限制。文件存储会以文件和文件夹的层次结构来整理和呈现数据；块存储会将数据拆分到任意划分且大小相同的卷中; 对象存储会管理数据并将其链接至关联的元数据。

块存储

块存储会将数据拆分成块，并单独存储各个块。每个数据块都有一个唯一标识符，所以存储系统能将较小的数据存放在最方便的位置。这意味着有些数据可以存储在 Linux 环境中，有些则可以存储在 Windows 单元中。

块存储通常会被配置为将数据与用户环境分离，并会将数据分布到可以更好地为其提供服务的多个环境中。然后，当用户请求数据时，底层存储软件会重新组装来自这些环境的数据块，并将它们呈现给用户。它通常会部署在存储区域网络 (SAN) 环境中，而且必须绑定到正常运行的服务器。

由于块存储不依赖于单条数据路径（和文件存储一样），因此可以实现快速检索。每个块都独立存在，且可进行分区，因此可以通过不同的操作系统进行访问，这使得用户可以完全自由地配置数据。它是一种高效可靠的数据存储方式，且易于使用和管理。它适用于要执行大型事务的企业和部署了大型数据库的企业。这意味着，需要存储的数据越多，就越适合使用块存储。

块存储有一些缺点。块存储的成本高昂。它处理元数据的能力有限。

操作对象：磁盘

存储协议：SCSI、iSCSI、FC

接口命令：以SCSI为例，主要有Read/Write/Read Capacity

存储架构：DAS、SAN

文件存储

文件存储也称为文件级存储或基于文件的存储，数据会以单条信息的形式存储在文件夹中。当需要访问该数据时，计算机需要知道相应的查找路径。存储在文件中的数据会根据元数据来进行整理和检索，这些元数据会告诉计算机文件所在的确切位置。

请试想一下塞满文件柜的储藏室。每个文档都会按照某种类型的逻辑层次结构来排放 ——按文件柜、抽屉、文件夹，然后再是纸张。“分层存储”这个术语就是这么来的，而这就是文件存储。它是适用于直接和网络附加存储（NAS）系统的最古老且运用最为广泛的一种数据存储系统；当访问保存在个人计算机上的文件中的文档，就是在使用文件存储。文件存储具有丰富多样的功能，几乎可以存储任何内容。它非常适合用来存储一系列复杂文件，并且有助于用户快速导航。

问题是基于文件的存储系统必须通过添置更多系统来进行横向扩展，而不是通过增添更多容量来进行纵向扩展。

操作对象：文件和文件夹

存储协议：NFS、SAMBA（SMB）、POSIX

接口命令：以NFS为例，文件相关的接口命令包括：READ/WRITE/CREATE/REMOVE/RENAME/LOOKUP/ACCESS 等；文件夹相关的接口命令包括：MKDIR/RMDIR/READDIR 等

存储架构：NAS （LinuxNAS存储_Jacky_Feng的博客-CSDN博客）

对象存储

对象存储，也称为基于对象的存储，是一种扁平结构，其中的文件被拆分成多个部分并散布在多个硬件间。在对象存储中，数据会被分解为称为“对象”的离散单元，并保存在单个存储库中，而不是作为文件夹中的文件或服务器上的块来保存。

对象存储卷会作为模块化单元来工作：每个卷都是一个自包含式存储库，均含有数据、允许在分布式系统上找到对象的唯一标识符以及描述数据的元数据。元数据包括年龄、隐私/安全信息和访问突发事件等详细信息。为了检索数据，存储操作系统会使用元数据和标识符，这样可以更好地分配负载，并允许管理员应用策略来执行更强大的搜索。

对象存储需要一个简单的 HTTP 应用编程接口 (API)，以供大多数客户端（各种语言）使用。对象存储经济高效：您只需为已用的内容付费。它可以轻松扩展，因而是公共云存储的理想之选。它是一个非常适用于静态数据的存储系统，其灵活性和扁平性意味着它可以通过扩展来存储极大量的数据。对象具有足够的信息供应用快速查找数据，并且擅长存储非结构化数据。

它的缺点是无法修改对象 ，即必须一次性完整地写入对象。对象存储也不能很好地与传统数据库搭配使用，因为编写对象是一个缓慢的过程，编写应用以使用对象存储 API 并不像使用文件存储那么简单。

操作对象：对象（Object）

存储协议：S3、Swift

接口命令：主要有PUT/GET/DELETE等

存储架构：去中心化框架

对象存储概念

对象存储的数据组成

存储桶（Bucket）：存放对象的“容器”，且该“容器”无容量上限。对象以扁平化结构存放在存储桶中，无文件夹和目录的概念，用户可选择将对象存放到单个或多个存储桶中。存储桶的容量大小需要通过累加各个对象的大小得到。

每个存储桶可容纳任意数量的对象，但同一个主账号下存储桶数量最多仅能够创建200个。（？？？）

对于存储桶，应当以用途为粒度进行划分，确保每个存储桶的用途尽可能单一。例如，针对存放个人文件、发布静态网站、存储备份等用途都应该创建不同的存储桶。此外，不同项目的数据、不同的网站，或者完全私人的文件与工作性质、需要分享的文件，也应该划分不同的存储桶。

对象存储中也没有「文件夹」的概念。对象存储的管理平台为了模仿本地存储的使用习惯，并与本地存储系统互相兼容而模拟了目录结构，背后的原理也仅仅是根据 / 这个字符对 key 进行分隔。为了表示空目录，部分云平台也提供「文件夹」对象，实际上只是 key 以 / 结尾的空存储对象。

存储桶所在地域（Regin）

指对象存储的数据中心所在地域。对象存储允许用户在不同地域创建存储桶，可以选择在离业务最近的地域上创建存储桶，以满足低延迟、低成本以及合规性要求。

Bucket读写权限

Bucket读写权限包括：私有读写、公有读私有写和公有读写。

私有读写

只有该存储桶的创建者及有授权的账号才对该存储桶中的对象有读写权限，其他任何人对该存储桶中的对象都没有读写权限。存储桶访问权限默认为私有读写，推荐使用。

公有读私有写

任何人（包括匿名访问者）都对该存储桶中的对象有读权限，但只有存储桶创建者及有授权的账号才对该存储桶中的对象有写权限。

公有读写

任何人（包括匿名访问者）都对该存储桶中的对象有读权限和写权限，不推荐使用。

对象（Object）：对象存储的基本单元，可理解为任何格式类型的数据，例如、文档和音视频文件等。

每个对象都由对象键（Key）、对象值（Data）、和对象元数据（Metadata）组成。

对象键（Key）：对象键是对象在存储桶中的全局唯一标识（UID），可以理解为文件（名）路径。

key用于检索对象，文件对象的 key 与实际存储路径无关，服务器和用户不需要知道数据的物理地址，通过key就能找到对象。

对象值（Data）：即存储对象内容数据，可以理解为文件内容（Object Content）。

对象元数据（Metadata）：是一组键值对，可以通俗的理解为文件的属性，例如文件的修改时间、存储类型等。（传统的文件存储，元数据属于文件本身，和文件一起封装存储。而对象存储，元数据独立出来，并不在数据内部封装。）

对象访问地址

对象的访问地址由存储桶访问地址和对象键组成，其结构形式为<存储桶域名>/<对象键> 。

例如：上传对象exampleobjecttxt到广州（华南）的存储桶examplebucket-1250000000中，那么exampleobjecttxt的访问地址是：examplebucket-1250000000cosap-guangzhoumyqcloudcom/exampleobjecttxt。其中examplebucket-1250000000cosap-guangzhoumyqcloudcom为存储桶域名，exampleobjecttxt为对象键。

目录和文件夹

对象存储中本身是没有文件夹和目录的概念的，对象存储不会因为上传对象project/atxt而创建一个project文件夹。为了满足用户使用习惯，对象存储在控制台、COS browser 等图形化工具中模拟了「文件夹」或「目录」的展示方式，具体实现是通过创建一个键值为project/，内容为空的对象，展示方式上模拟了传统文件夹。

对象操作

用户通过控制台、工具、API、SDK等多种方式管理对象。

对象存储架构

对象存储设备（OSD）

OSD由存储介质、处理器、内存以及网络系统等组成，负责管理本地的对象，是对象存储系统的核心。和块设备相比，它们的差异在于提供的访问接口。OSD的主要功能是数据存储和安全访问。

数据存储：OSD管理对象数据，并将它们放置在标准的磁盘系统上，OSD不提供块接口访问方式，Client请求数据时用对象ID、偏移进行数据读写。

智能分布：OSD用其自身的CPU和内存优化数据分布，并支持数据的预取。由于OSD可以智能地支持对象的预取，从而可以优化磁盘的性能。

对象元数据管理：OSD管理存储的对象元数据与传统的inode元数据相似，通常包括对象的数据块和对象的长度。而在传统的NAS系统中，这些元数据是由文件服务器维护的，对象存储架构将系统中主要的元数据管理工作由OSD来完成，降低了Client的开销。

元数据服务器（MDS）

MDS控制Client与OSD对象的交互，为客户端提供元数据，主要是文件的逻辑视图（文件与目录的组织关系、每个文件所对应的OSD等）。主要功能如下：

对象存储访问：MDS构造和管理描述每个文件分布的逻辑视图，允许Client直接访问对象。MDS为Client提供访问该文件所含对象的能力，OSD在接收到每个请求时将先验证该能力，然后才可以访问。

文件和目录访问管理：MDS在存储系统上构建一个文件结构，包括限额控制、目录和文件的创建和删除、访问控制等。

Client Cache一致性：为了提高Client性能，在对象存储系统设计时通常支持Client方的Cache。由于引入Client方的Cache，带来了Cache一致性问题，MDS支持基于Client的文件Cache，当Cache的文件发生改变时，将通知Client刷新Cache，从而防止Cache不一致引发的问题。

客户端（Client）

对象存储系统提供给用户的也是标准的POSIX文件访问接口。接口具有和通用文件系统相同的访问方式，同时为了提高性能，也具有对数据的Cache功能和文件的条带功能。同时，文件系统必须维护不同客户端上Cache的一致性，保证文件系统的数据一致。

文件系统读访问流程：

① 客户端应用发出读请求;

② 文件系统向元数据服务器发送请求，获取要读取的数据所在的OSD;

③ 直接向每个OSD发送数据读取请求；

④ OSD得到请求以后，判断要读取的Object，并根据此Object要求的认证方式，对客户端进行认证，如果此客户端得到授权，则将Object的数据返回给客户端；

⑤ 文件系统收到OSD返回的数据以后，读操作完成。

对象存储的优缺点

（1）优点：

容量大，高扩展性

对象存储的容量是EB级以上,对象存储的所有业务、存储节点采用分布式集群方式工作，各功能节点、集群都可以独立扩容。从理论上来说，某个对象存储系统或单个桶（bucket），并没有总数据容量和对象数量的限制，即服务商就可以不停地往架构里增加资源，这个存储空间就是无限的，也是支持弹性伸缩的。

高安全性，可靠性

对象存储采用了分布式架构，对数据进行多设备冗余存储（至少三个以上节点），实现异地容灾和资源隔离。数据访问方面，所有的桶和对象都有访问控制策略，所有连接都支持SSL加密，访问用户进行身份权限鉴定。

高性能，支持海量用户的并发访问

（2）缺点：

不支持直接在存储上修改

对象存储系统保存的Object不支持修改（追加写Object需要调用特定的接口，生成的Object也和正常上传的Object类型上有差别）。用户哪怕是仅仅需要修改一个字节也需要重新上传整个Object。因此，它不适合存储需要频繁擦写的数据。

参考链接：

对象存储，为什么那么火？ - 知乎 (zhihucom)

对象存储 存储桶概述 - 开发者指南 - 文档中心 - 腾讯云 (tencentcom)

基本概念 (aliyuncom)

文件存储、块存储还是对象存储？ (redhatcom)

linux

驻马店市民请关注领取补贴！

巨魔-抽手机公告

广告



对比块存储、文件存储、对象存储

1242阅读·0评论·3点赞

2019年2月27日

ShapeFile的文件格式设计

90阅读·0评论·0点赞

2009年3月20日

应用ceph对象存储(ceph-13210)

72阅读·0评论·0点赞

2022年11月26日

三种存储类型比较-文件、块、对象存储

48W阅读·0评论·13点赞

2016年7月26日

常见存储格式文件简介

4534阅读·0评论·0点赞

2020年5月4日

s3cmd常用命令

781阅读·0评论·0点赞

2022年11月17日

驻马店发布，你有一台5G手机待领取



00:23

巨摩互动

广告

常见的存储格式

1083阅读·0评论·0点赞

2022年2月15日

文件、对象、块区别

1399阅读·0评论·0点赞

2020年7月13日

对象存储、文件存储、块存储的区别和联系

7330阅读·2评论·5点赞

2021年10月16日

数据分析中常见的存储方式

1537阅读·0评论·0点赞

2021年11月16日

三种存储类型：块存储、文件存储、对象存储

15W阅读·3评论·55点赞

2020年11月2日

如何设计二进制文件格式

1940阅读·0评论·1点赞

2020年3月6日

BMP文件存储格式

472阅读·0评论·2点赞

2021年8月2日

hive 的存储格式

1765阅读·0评论·1点赞

2022年6月18日

数据存储格式

446阅读·0评论·0点赞

2022年12月21日

总结：对象存储、块存储、文件存储的区别

6606阅读·0评论·3点赞

2022年4月9日

c语言中文件rw,什么是“块文件”？

386阅读·0评论·0点赞

2021年5月23日

存储块存储、文件存储和对象存储的区别？

350阅读·0评论·0点赞

2022年7月22日

块存储、文件存储与对象存储的区别与应用场景

1846阅读·1评论·0点赞

2022年6月5日

数据在内存中的存储方式

272阅读·0评论·0点赞

2022年8月21日

去首页

看看更多热门内容

．初次连接使用KVM 控制平台，KVM 控制平台不能正常工作

1、断开所有与KVM 连接的KVM 信号线与电源线

2、首先连接KVM 控制平台电源线，给KVM 控制平台供电，这时会听到蜂鸣器的开机提示音，KVM 会弹出用户名及密码输入窗口

3、输入正确的用户名及密码，敲两次“Enter”进入KVM系统弹出OSD 主菜单

4、检查KVM 控制平台是否能正常切换端口

5、用KVM 信号线连接1 台服务器(PC)至KVM 切换器的1 端口，检查KVM 控制平台是否能正常切换，服务器(PC)的键盘鼠标显示是否正常，如还是不能正常工作，可尝试重启服务器(PC)

6、在确保前面的步骤顺利操作完成后，逐步增加服务器(PC)直至达到要求

二．开机用户名及密码窗口没显示或者显示不正常，且不能登录进入KVM 系统

1、检查电源(AC 或DC)是否有输出。

2、开机时，是否有“哔“的一声开机提示，按键板的LED 灯是否亮起。

3、检查显示器的电源是否打开、显示器信号线是否已经连接到切换器的CONSOLE 端。

4、确认KVM 键盘是否能正常使用, 用户名或者密码没有输入正确，初始默认值为空，回车即可进入

5、如无法进入，在电源插座边外接USB 或者USB 或者PS/2 键盘是否可进入(初始默认值为空，按两次回车即可进入)

三 登录进入系统后，发现有KVM 端口不能切换或服务器(PC)显示画面质量比较差

1、调出OSD 主菜单，查看左上角的用户名，看管理员是否屏蔽了此用户的端口权限

2、检查信号线是否已经连接好。

3、复位显示器的显示设置。

4、(以上均不可)请联系经销商或者KVM 切换器厂家

四、切换至某一端口后，发现键盘鼠标不能正常操作

1、确认是否已经退出OSD 菜单。

2、调出OSD 主菜单，查看左上角的用户名，看管理员是否禁止了此用户的操作权限

3、重新插拔一次连接服务器(PC)端的USB 接口。

4、如果连接服务器(PC)端的是PS2 接口，可尝试重启服务器(PC)

五、无法调出OSD 主菜单

1、检查键盘是否正常。

2、在键盘上双击Scroll_Lock是否能调出OSD

3、在键盘上双击F12是否能调出OSD

4、在键盘上双击Caps Lock是否能调出OSD

六、级联时遇到OSD 乱码或者是显示不良等问题解

本教程用官网最近的cephadm来搭建ceph集群。

第一周作业：1ceph的组件和功能2ceph的数据读写流程3使用ceph-deploy安装一个最少三个节点的ceph集群 推荐3个或以上的磁盘作为专用osd 4测试ceph的rbd使用

1·Ceph组件和功能

组件

Ceph OSDs : ( Ceph OSD ）object storage daemon的功能是存储数据，处理数据的复制、恢复、回填、再均衡，并通过检查其他OSD 守护进程的心跳来向 Ceph Monitors 提供一些监控信息。当 Ceph 存储集群设定为有2个副本时，至少需要2个 OSD 守护进程，集群才能达到 active+clean 状态（ Ceph 默认有3个副本，但你可以调整副本数）。

Monitors : 维护着展示集群状态的各种图表，包括监视器图、 OSD 图、归置组（ PG ）图、和 CRUSH 图。 Ceph 保存着发生在Monitors 、 OSD 和 PG上的每一次状态变更的历史信息（称为 epoch ）。

MDSs : Ceph 元数据服务器为 Ceph 文件系统存储元数据（也就是说，Ceph 块设备和 Ceph 对象存储不使用MDS ）。元数据服务器使得 POSIX 文件系统的用户们，可以在不对 Ceph 存储集群造成负担的前提下，执行诸如 ls、find 等基本命令。

CephMgr ：在一个主机上的守护进程，负责运行指标，运行状态，性能负载，

其他术语：

RADOS：多个主机组成的存储集群，即可靠，自动化，分布式的对象存储系统。

File:  就是普通文件，ObjectRADOS看到的对象，Object与File的区别是， Object的最大尺寸由RADOS限定(通常为2MB或4MB) ，以便实现底层存储的组织管理。因此，当上层应用向RADOS存入尺寸很大的File时，需要将File切分成统一大小的一系列Objet (最后一个的大小可以不同)进行存储。

librados：RADOS集群的API，支持大部分主流语言。

Pool：存储池，大小取决于底层的存储空间。

PG：placeholder group，一个pool（存储池）内可以有多个PG，pool个pg都是抽象的逻辑概念，可以通过公示计算。PG的用途是对Object的存储进行组织和位置映射的。具体而言，一个PG负责组织若干个Object，但一个Obiect只能被映射到一个PG中，即PG和Object之间是“一对多”的映射关系。同时，一个PG会被映射到n个OSD上，而每个OSD上都会承载大量的PG，即PG和OSD之间是“多对多”的映射关系。在实践当中，n至少为2，如果用于生产环境，则至少为3。一个OSD上的PG可达到数百个。事实上， PG数量的设置关系到数据分布的均匀性问题。

OSD daemon：默认每2秒发送状态数据给monitor，（同时监控组内其他OSD的状态）（up 可以提供IO，down不能提供，in有数据，out没有数据）

PG和OSD之间的关系通过CRUSH算法得出的。常规这三个 OSD daemon 可以在一台机器上，也可以在不同机器上；那么根据 CRUSH 算法会尽可能的保证一个平衡，就是不在同一个机器上；毕竟Ceph中的数据是一个为平衡的状态，一切都是通过CRUSH 算法来实现的数据平衡，而 PG 本身是个有序列表，位于第一的位置是 master；这个列表的产生是由 monitor 来产生的；

寻址流程

File->Object映射 这次映射的目的是，将用户要操作的File映射为RADOS能够处理的Object，其十分简单，本质上就是按照Object的最大尺寸（默认4M）对File进行切分，相当于磁盘阵列中的条带化过程。这种切分的好处有两个:一是让大小不限的File变成具有一致的最大尺寸、可以被RADOS高效管理的Object;二是让对单一File实施的串行处理变为对多个Object实施的并行化处理。每一个切分后产生的Object将获得唯一的oid,即Object ID,其产生方式也是线性映射,极其简单。 Object →PG映射 在File被映射为1个或多个Object之后,就需要将每个Object独立地映射到1个PG中去。这个映射过程也很简单,如图所示,其计算公式如下:Hash(oid) & mask -> pgid由此可见,其计算由两步组成。首先,使用Ceph系统指定的一个静态哈希算法计算oid的哈希值,将oid映射为一个近似均匀分布的伪随机值。然后,将这个伪随机值和mask按位相与,得到最终的PG序号(pgid) 。根据RADOS的设计,给定PG的总数为m(m应该为2的整数幂),则mask的值为m-1。因此,哈希值计算和按位与操作的整体结果事实上是从所有m个PG中近似均匀地随机选择1个。基于这一机制,当有大量Object和大量PG时, RADOS能够保证Object和PG之间的近似均匀映射。又因为Object是由File切分而来的,大部分Object的尺寸相同,因此,这一映射最终保证了各个PG中存储的Object的总数据量近似均匀。这里反复强调了“大量” ,意思是只有当Object和PG的数量较多时,这种伪随机关系的近似均匀性才能成立, Ceph的数据存储均匀性才有保证。为保证“大量”的成立,一方面, Object的最大尺寸应该被合理配置,以使得同样数量的File能够被切分成更多的Object;另一方面, Ceph也推荐PG总数应该为OSD总数的数百倍,以保证有足够数量的PG可供映射。 PG→ OSD映射 第3次映射就是将作为Object的逻辑组织单元的PG映射到数据的实际存储单元OSD上。RADOS采用一个名为CRUSH的算法,将pgid代入其中,然后得到一组共n个OSD。这n个OSD共同负责存储和维护一个PG中的所有Objecto前面提到过, n的数值可以根据实际应用中对于可靠性的需求而配置,在生产环境下通常为3。具体到每个OSD,则由其上运行的OSD Daemon负责执行映射到本地的Object在本地文件系统中的存储、访问、元数据维护等操作。和“Object →PG"映射中采用的哈希算法不同, CRUSH算法的结果不是绝对不变的,而会受到其他因素的影响。其影响因素主要有两个。一是当前系统状态,也就是在前面有所提及的集群运行图。当系统中的OSD状态、数量发生变化时,集群运行图也可能发生变化,而这种变化将会影响到PG与OSD之间的映射关系。二是存储策略配置。这里的策略主要与安全相关。利用策略配置,系统管理员可以指定承载同一个PG的3个OSD分别位于数据中心的不同服务器或机架上,从而进一步改善存储的可靠性。因此,只有在系统状态和存储策略都不发生变化的时候, PG和OSD之间的映射关系才是固定不变的。在实际使用中,策略一经配置通常不会改变。而系统状态的改变或是因为设备损坏,或是因为存储集群规模扩大。好在Ceph本身提供了对这种变化的自动化支持,因而,即便PG与OSD之间的映射关系发生了变化,也并不会对应用产生影响。事实上, Ceph正是利用了CRUSH算法的动态特性,可以将一个PG根据需要动态迁移到不同的OSD组合上,从而自动化地实现高可靠性、数据分布再平衡等特性。之所以在此次映射中使用CRUSH算法,而不使用其他哈希算法,一方面原因是CRUSH算法具有上述可配置特性,可以根据管理员的配置参数决定OSD的物理位置映射策略;另一方面原因是CRUSH算法具有特殊的“稳定性" ,也即,当系统中加入新的OSD,导致系统规模增大时,大部分PG与OSD之间的映射关系不会发生改变,只有少部分PG的映射关系会发生变化并引发数据迁移。这种可配置性和稳定性都不是普通哈希算法所能提供的。因此, CRUSH算法的设计也是Ceph的核心内容之一。 至此为止, Ceph通过3次映射,完成了从File到Object Object到PG,PG再到OSD的整个映射过程。从整个过程可以看到,这里没有任何的全局性查表操作需求。至于唯一的全局性数据结构:集群运行图。它的维护和操作都是轻量级的,不会对系统的可扩展性、性能等因素造成影响 。

存储过程总结：

1计算文件到对象的映射

2通过哈希算法计算计算出文件对应的pool的PG

3通过CRUSH把对象映射到PG中的OSD

4PG种的OSD将对象写入到磁盘

5主OSD将数据同步到备份OSD，待备份OSD返回确认

6主OSD的到备份OSD写完操作以后给客户的返回写入成功

2 ceph的读写流程

当某个客户端需要向Ceph集群写入一个File时，首先需要在本地完成寻址流程，将File变为一个Object，然后找出存储该Object的一组共3个OSD，这3个OSD具有各自不同的序号，序号最靠前的那个OSD就是这一组中的Primary OSD，而后两个则依次Secondary OSD和Tertiary OSD。找出3个OSD后，客户端将直接和Primary OSD进行通信，发起写入操作(步骤1)。 Primary OSD收到请求后，分别向Secondary OSD和Tertiary OSD发起写人操作(步骤2和步骤3)。当Secondary OSD和Tertiary OSD各自完成写入操作后，将分别向Primary OSD发送确认信息(步骤4和步骤5)。当Primary OSD确认其他两个OSD的写入完成后，则自己也完成数据写入，并向客户端确认Object写入操作完成(步骤6)。之所以采用这样的写入流程，本质上是为了保证写入过程中的可靠性，尽可能避免出现数据丢失的情况。同时，由于客户端只需要向Primary OSD发送数据，因此在互联网使用场景下的外网带宽和整体访问延迟又得到了一定程度的优化。当然，这种可靠性机制必然导致较长的延迟，特别是，如果等到所有的OSD都将数据写入磁盘后再向客户端发送确认信号，则整体延迟可能难以忍受。因此， Ceph可以分两次向客户端进行确认。当各个OSD都将数据写入内存缓冲区后，就先向客户端发送一次确认，此时客户端即可以向下执行。待各个OSD都将数据写入磁盘后，会向客户端发送一个最终确认信号，此时客户端可以根据需要删除本地数据。分析上述流程可以看出，在正常情况下，客户端可以独立完成OSD寻址操作，而不必依赖于其他系统模块。因此，大量的客户端可以同时和大量的OSD进行并行操作。同时，如果一个File被切分成多个Object，这多个Object也可被并行发送至多个OSD上。从OSD的角度来看，由于同一个OSD在不同的PG中的角色不同，因此，其工作压力也可以被尽可能均匀地分担，从而避免单个OSD变成性能瓶颈。

问：为什么要设计三层映射而不是一层？

答：如果将object直接映射到一组OSD上，如果这种算法是固定的哈希算法，则意味着一个object被固定映射在一组OSD上，当其中一个OSD损坏时，object也无法部署到新的OSD上(因为映射函数不允许)。

如果设计一个动态算法(例如CRUSH算法)来完成这一映射，结果将是各个OSD所处理的本地元数据暴增，由此带来的计算复杂度和维护工作量也是难以承受的。

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

1准备工作

时间同步`

安装ntpdate（时间同步工具）

# apt install ntpate

0 ntpdate time1aliyuncom

echo'0 ntpdate time1aliyuncom'>> /var/spool/cron/crontabs/root

或者 可以通过

ansible all-mshell-a"echo  '0 ntpdate time1aliyuncom' >> /var/spool/cron/crontabs/root"

关闭 selinux 和防火墙

root@node1:~# sudo ufw status  ##查看状态

Status: inactive

root@node1:~# sudo ufw disable

Firewall stopped and disabled on system startup##禁用

root@node1:~#

配置域名解析或通过 DNS 解析

root@node1:~# cat /etc/hosts

127001 localhost

root@node1:~# hostnamectl set-hostname 对应的名称

## 以下是新增的 可以按照自己的习惯配置

192168106101  node1

192168106102  node2

192168106103  node3

安装python

root@node1:~# apt install python  ##python2

源修改成国内源  -- 具体步骤自行百度

https://mirrorsaliyuncom/ceph/#阿里云镜像仓库

http://mirrors163com/ceph/#网易镜像仓库

https://mirrorstunatsinghuaeducn/ceph/#清华大学镜像源

ceph用到的端口 (防火墙和安全中记得放开)

Ceph Monitor：启用 Ceph MON 服务或端口 6789 (TCP)。

Ceph OSD 或元数据服务器：启用 Ceph OSD/MDS 服务或端口 6800-7300 (TCP)。

iSCSI 网关：打开端口 3260 (TCP)。

对象网关：打开对象网关通讯所用的端口。此端口在 /etc/cephconf 内以 rgw frontends = 开头的行中设置。HTTP 的默认端口为 80，HTTPS (TCP) 的默认端口为 443。

NFS Ganesha：默认情况下，NFS Ganesha 使用端口 2049（NFS 服务、TCP）和 875 （rquota 支持、TCP）。

SSH：打开端口 22 (TCP)。

NTP：打开端口 123 (UDP)。

2搭建ceph集群

安装cephadm

root@node1:~#  wget https://githubcom/ceph/ceph/raw/pacific/src/cephadm/cephadm ## node1 管理节点上执行

root@node1:~#  chmod +x cephadm

root@node1:~# /cephadm add-repo --release pacific  ##设置要安装的版本

root@node1:~#  which cephadm   ##确认是否安装成功

初始化集群

root@node1:~# cephadm bootstrap --mon-ip 192168106101   ##ceph集群第一个节点的ip

初始化完了以后就可以访问dashboard了 地址 ： https://node1:8443/#/dashboard 访问用户密码上一步生成

添加其他节点和其他组件

root@node1:~# ssh-keygen

## 配置免密通信

root@node1:~#  ssh-copy-id -f -i /etc/ceph/cephpub root@node2

root@node1:~#  ssh-copy-id -f -i /etc/ceph/cephpub root@node3

## 添加node

root@node1:~#  ceph orch host add node2 192168106102

root@node1:~#  ceph orch host add node3 192168106103

## 添加osd

root@node1:~#  ceph orch daemon add osd node1:/dev/sdb

root@node1:~#  ceph orch daemon add osd node1:/dev/sdb

root@node1:~#  ceph orch daemon add osd node3:/dev/sdb

测试

root@node1:~#  ceph fs volume create testfs  ##添加测试fs

root@node1:~#  ceph orch apply mds testfs --placement="3" ##设置备份数

root@node1:~#   ceph orch daemon add mds testfs node1

root@node1:~#   ceph mds stat

## 在集群之外的或者任意机器上操作

root@node4:~#  apt install ceph-common -y

node1初始化集群的节点操作

root@node1:~#  scp /etc/ceph/cephclientadminkeyring user@node4:/etc/ceph

##  集群之外的clinet或者测试节点执行

root@node4:~#  mount -t ceph node1:/ /mnt/testfs -o name=admin,secret=AQAoJjBh7OPVNhAAQZyzLhDfgSj+KPmeU5RVlA==,fs=testfs  

root@node4:~#  mount -t ceph node2:/ /mnt/cephfs -o name=admin,secret=AQAoJjBh7OPVNhAAQZyzLhDfgSj+KPmeU5RVlA==,fs=testfs

root@node4:~#  df -h

Filesystem                  Size  Used Avail Use% Mounted on

udev14G014G0% /dev

tmpfs                       293M12M  292M1% /run

192168106101:/            18G 1000M   17G6% /mnt/testfs

192168106102:/            18G 1000M   17G6% /mnt/cephfs

root@node4:~#  cd /mnt/cephfs

root@node4:/mnt/cephfs#  dd if=/dev/zero of=test bs=1M count=100 ##生成文件

这时候文件是直接写在ceph集群上看了， 可以通过dashboard观察