Ceph分布式对象存储系统研究与优化
分布式存储系统对比之 Ceph VS MinIO
分布式存储系统对比之 Ceph VS MinIO分布式存储系统对比之Ceph VS MinIO对象存储概述对象存储通常会引用为基于对象的存储，它是能够处理大量非结构化数据的数据存储架构，在众多系统中都有应用。
对于部署在公有云的服务来说，公有云一般都提供对象存储服务，如阿里云的 OSS, 华为云的 OBS ，腾讯云的 COS 。
通过提供的 SDK 就可以访问。
如果不想用公有云的话，也有一些开源方案可以自己搭建。
一些开源的对象存储都会遵循 Amazon s3 协议。
Amazon s3 协议定义了操作对象存储的Resestfull 风格的 API 。
通过在 pom 中引用 aws-java-sdk-s3 可以实现对存储的操作。
开源方案对比存储的方案分成两种：① 一种是可以自定对象名称的；②另一种是系统自动生成对象名称。
不能自定义名称的有领英的 Ambry ， MogileFS 。
TFS 是淘宝开源的，但是目前已经很少有人维护它并且也不是很活跃。
Ceph 是一个比较强大的分布式存储，但是它整个系统非常复杂需要大量的人力进行维护。
GlusterFS 为本身是一个非常成熟的对象存储的方案， 2011 年被收购了，原班的人马又做了另外一个存储系统 MinIO 。
其中 Ceph 跟 MinIO 是支持 s3 协议的。
后面对这两种方案做了一个详细的介绍。
对象存储选型①MinIOMinIO 是一个基于 Apache License V2.0 开源协议的对象存储服务，它兼容亚马逊 S3 云存储服务，非常适合于存储大容量非结构化的数据，如图片，视频，日志文件等。
而一个对象文件可以任意大小，从几 KB 到最大的 5T 不等。
它是一个非常轻量级的服务，可以很简单的和其它的应用结合，类似于 NodeJS, Redis 或者 MySQL 。
MinIO 默认不计算 MD5 ，除非传输给客户端的时候，所以很快，支持 windows ，有 web 页进行管理。
ceph存储原理
ceph存储原理ceph是一种开源、分布式的对象存储和文件系统，它能够在大规模的集群中存储和管理海量数据。
在ceph中，数据被分割成对象，并将这些对象存储在不同的存储节点上以实现高可用性和容错性。
这篇文章将介绍ceph存储的原理，包括ceph的架构、数据的存储和调度方式以及ceph如何处理故障。
ceph架构ceph的架构包括三个主要组成部分：客户端、存储集群和元数据服务器。
客户端是使用ceph存储的应用程序，它们通常是通过ceph API或者对象存储接口来访问ceph集群。
存储集群由一个或多个monitors、object storage devices（OSD），以及可能的元数据服务器组成。
monitors是ceph集群的核心组件，它负责管理ceph的全局状态信息、监控OSD 状态，并为客户端提供服务发现和配置信息。
OSD是实际存储数据的存储节点，它负责存储和处理对象，并在节点故障时自动重新平衡数据。
元数据服务器用于管理ceph文件系统中的元数据信息，包括文件和目录的名称、属性和层次关系等。
ceph存储数据的方式ceph将数据分割成对象，并使用CRUSH算法将这些对象分布在集群中的OSD上。
CRUSH 算法是ceph中存储调度的核心算法，它通过一系列计算将对象映射到存储集群中的OSD。
CRUSH将对象映射到OSD的方式是通过建立CRUSH映射表以实现负载均衡和容错。
CRUSH映射表可以根据管理员的需求进行调整，以达到最佳的性能和可扩展性。
ceph的CRUSH算法有以下特点：1. CRUSH将对象映射到可扩展的存储后端，以实现分布式存储和高可用性。
2. CRUSH使用元数据信息来动态调整对象的存储位置，并根据OSD的状态和磁盘使用情况等信息来实现负载均衡。
3. CRUSH允许管理员对存储策略进行调整，以适应不同的应用场景。
ceph的故障处理ceph具有强大的故障处理机制，它能够自动处理节点故障和数据损坏等问题，以确保数据的完整性和可用性。
ceph对象存储原理
ceph对象存储原理Ceph对象存储原理Ceph是一种分布式的对象存储系统，它可以将数据存储在多个节点上，提供高可用性和可扩展性。
在了解Ceph对象存储原理之前，我们先来了解一下什么是对象存储。
对象存储是一种将数据以对象的形式存储的方式，每个对象都有一个唯一的标识符。
与传统的块存储和文件存储不同，对象存储不使用文件系统来组织数据，而是将数据与元数据一起存储为一个整体。
Ceph对象存储是基于RADOS（可靠自动分布式对象存储）架构实现的。
RADOS将存储集群划分为多个OSD（对象存储守护进程）节点，每个节点上存储着一部分数据。
当客户端请求访问数据时，Ceph会通过CRUSH算法来确定数据所在的节点，并将数据返回给客户端。
CRUSH算法是Ceph的核心算法之一，它负责将数据块映射到存储节点上。
CRUSH算法通过一系列的映射规则和散列函数来实现数据的分布式存储。
这样，即使在节点发生故障时，Ceph也能够保证数据的可用性。
在Ceph中，数据被分成多个对象，并存储在不同的OSD上。
每个对象都有一个唯一的标识符，称为对象ID。
当客户端请求访问数据时，它会向Ceph Monitor发送一个请求，Monitor会通过CRUSH算法确定数据所在的OSD，并将数据返回给客户端。
Ceph对象存储还提供了数据冗余和数据恢复的功能。
数据冗余是通过将数据复制到多个OSD节点来实现的，这样即使某个节点发生故障，数据仍然可用。
数据恢复则是通过复制丢失的数据块到其他节点上来实现的。
除了数据冗余和数据恢复，Ceph还提供了数据分片和数据压缩的功能。
数据分片可以将大的对象分成多个小的数据块进行存储，提高数据的并发性和吞吐量。
数据压缩则可以减少数据的存储空间，提高存储效率。
总结一下，Ceph对象存储的原理是基于RADOS架构实现的。
它通过CRUSH算法将数据分布在不同的存储节点上，提供高可用性和可扩展性。
同时，Ceph还提供了数据冗余、数据恢复、数据分片和数据压缩等功能，提高了数据的可靠性和存储效率。
ceph使用方法
ceph使用方法摘要：1.Ceph简介2.Ceph组件及其作用3.安装Ceph4.Ceph使用方法5.Ceph的日常维护与管理6.Ceph性能优化7.常见问题与解决方案正文：Ceph是一款开源的分布式存储系统，具有高性能、可靠性高、可扩展性强等特点。
它主要由以下几个组件构成：1.Ceph Monitor（CMS）：负责维护整个Ceph集群的元数据信息，包括监控各个节点的状态、集群映射关系等。
2.Ceph OSD：负责存储数据，包括数据存储和数据恢复。
OSD节点之间通过CRUSH算法实现数据分布和平衡。
3.Ceph Metadata Server：为Ceph客户端提供元数据服务，包括存储卷配置、快照、克隆等。
接下来，我们来了解一下如何安装和配置Ceph。
1.安装Ceph：首先，确保操作系统为CentOS 7及以上版本。
然后，按照官方文档的指引，依次安装Ceph Monitor、OSD和Metadata Server组件。
2.配置Ceph：安装完成后，需要对Ceph进行配置。
编辑Ceph配置文件（/etc/ceph/ceph.conf），设置相关参数，如：osd pool默认配置、monitor 选举算法等。
3.初始化Ceph：使用ceph-init命令初始化Ceph，之后启动Ceph相关服务。
4.创建存储池：使用ceph-volume命令创建存储池，为存储池分配OSD 节点。
5.创建卷：使用ceph-volume命令创建卷，并将卷挂载到客户端节点。
6.扩容存储池：当存储池空间不足时，可以通过添加OSD节点或调整pool参数进行扩容。
7.维护与管理：定期检查Ceph集群状态，使用ceph命令监控性能指标，如：osd tree、health monitor等。
8.性能优化：根据实际需求，调整Ceph配置文件中的相关参数，如：调整osd的osd_cache_size、osd_timeout等。
9.常见问题与解决方案：遇到问题时，可通过查询官方文档、社区论坛等途径寻求解决方案。
Ceph分布式存储中遇到的问题和解决办法
Ceph分布式存储中遇到的问题和解决办法最近有很多朋友拿着一篇关于“ceph运维那些坑”的文章来找我，起初我并没有在意，毕竟对于一个“新物种”来说，存在质疑是再正常不过的。
不过，陆续有更多的合作伙伴甚至圈内同行来问我如何看待这篇文章时，我觉得做为一名Ceph开发和运维的技术者，理应站出来为Ceph说点什么。
首先，原作者分析Ceph运维中遇到的问题是真实存在的，甚至在实际的运维过程中还出现过其他更复杂的问题。
因为最初的Ceph只是社区提供的一套开源版，因而想要实现产品化需要趟过很多次“坑”，就像最早的安卓系统一样。
我想任何产品在一开始都难以做到十全十美，因为技术本身就是在发现问题与解决问题的道路上不断前进发展的。
不过，在这里我想澄清的事实是：连初涉Ceph的运维人员都能发现的问题，研究Ceph多年的资深技术人员们肯定也早已发现。
接下来我就根据那篇文章中提到的坑，来说一说在实际产品化过程中我们是如何解决它们的。
一、扩容问题Ceph本身基于Crush算法，具备了多种数据复制策略，可以选择在磁盘、主机、机柜等等位置附着。
例如：如果采取3副本的数据保护策略，就可以通过复制策略来决定这3个副本是否同时分布在不同的磁盘、不同的主机、不同的隔离域、不同的机柜等位置来保证部分硬件故障后数据安全性和服务运行不中断。
Ceph底层是用资源池（POOL）来实现数据逻辑隔离，往往我们会出现因容量或性能不足需要对资源池进行扩容的问题，但是在容量扩容过程中，势必会带来进行数据重新平衡的要求。
Ceph中数据以PG为单位进行组织，因此当数据池中加入新的存储单元（OSD）时，通过调整OSDMAP会带来数据重平衡。
正如文章所提到的，如果涉及到多个OSD的扩容是可能导致可用PG中OSD小于min_size，从而发生PG不可用、IO阻塞的情况。
为了尽量避免这种情况的出现，只能将扩容粒度变小，比如每次只扩容一个OSD或者一个机器、一个机柜（主要取决于存储隔离策略），但是这样注定会带来极大的运维工作量，甚至连扩容速度可能都赶不上数据增长速度。
Ceph性能优化之配置参数调优
Ceph性能优化之配置参数调优该文同时发表在盛大游戏G云微信公众号，粘贴于此，方便各位查阅Ceph，相信很多IT朋友都听过。
因为搭上了Openstack的顺风车，Ceph火了，而且越来越火。
然而要用好Ceph却也不是件易事，在QQ群里就经常听到有初学者抱怨Ceph性能太烂，不好用。
事实果真如此吗！如果你采用Ceph的默认配置来运行你的Ceph集群，性能自然不能如人意。
俗话说，玉不琢,不成器；Ceph也有它的脾性，经过良好配置优化的Ceph性能还是不错的。
下文简单分享下，盛大游戏G云在Ceph优化上的一些实际经验，如有错误之处，欢迎指正。
下文的Ceph配置参数摘自CephHammer 0.94.1 版本Ceph配置参数优化首先来看看Ceph客户端与服务端的交互组件图：Ceph是一个统一的可扩展的分布式存储，提供Object,Block及file system三种访问接口；它们都通过底层的librados与后端的OSD 交互；OSD是Ceph的对象存储单元，实现数据的存储功能。
其内部包含众多模块，模块之间通过队列交换消息，相互协作共同完成io的处理；典型模块有：网络模块Messenger，数据处理模块Filestore,日志处理模块FileJournal等。
面对众多的模块，Ceph也提供了丰富的配置选项，初步统计Ceph有上千个配置参数，要配置好这么多参数，难度有多大可想而知。
G云内部主要使用Ceph Block Storage,即：Ceph rbd；下文的配置参数优化也就限于rbd客户端（librbd）和OSD端。
下面先来看看客户端的优化rbd客户端配置优化当Ceph作为虚拟机块存储使用时，Qemu是通过librbd，这个客户端库与Ceph集群交互的；与其相关的配置参数基本都以rbd_为前缀。
可以通过如下命令获取librbd的当前配置：//path/to/socket指向某个osd的admin socket文件#> ceph --admin-daemon {path/to/socket} config show | grep rbd下面对其中的某些配置参数进行详细说明：•rbd cache: 是否使能缓存，默认情况下开启。
ceph 原理
ceph 原理Ceph原理Ceph是一种开源的分布式存储系统，它被设计用于提供高性能、高可靠性和可扩展性的存储解决方案。
Ceph的原理基于RADOS（可靠自主分布式对象存储）技术，采用了分布式存储和对象存储的理念，旨在解决传统存储系统中的各种挑战和瓶颈。
一、分布式存储Ceph的核心思想是将数据分布到多个存储节点上，通过数据的分散存储和冗余备份来提高可靠性和性能。
每个节点都可以同时扮演存储节点和计算节点的角色，形成一个分布式存储集群。
数据被划分为多个对象，并通过唯一的对象ID进行标识和索引。
Ceph采用了动态数据分布机制，通过CRUSH算法（Controlled Replication Under Scalable Hashing）将对象映射到存储节点上。
CRUSH算法基于一致性哈希函数，能够将对象均匀分布到存储节点上，避免了传统存储系统中的数据热点问题。
同时，CRUSH算法还考虑了存储节点的负载情况和网络拓扑结构，能够根据实际情况进行动态的数据迁移和负载均衡，提高系统的性能和可扩展性。
二、对象存储Ceph将数据以对象的形式进行存储和管理，每个对象都有一个唯一的标识符和元数据。
对象的大小可以根据需求进行灵活设置，Ceph 能够支持从几KB到几TB不等的对象大小。
Ceph通过RADOS Gateway提供了对象存储接口，支持通过RESTful API和S3/Swift协议来访问和管理对象。
用户可以通过标准的HTTP 请求来上传、下载和删除对象，实现了与传统的文件系统和块存储的兼容性。
三、数据冗余和容错性Ceph在数据分布和存储过程中采用了冗余备份机制，确保数据的可靠性和容错性。
每个对象都会被复制到多个存储节点上，形成数据的冗余备份。
Ceph支持灵活的副本策略，用户可以根据需求设置副本的数量和位置。
Ceph通过心跳机制和故障检测算法来监测存储节点的状态，一旦发现节点故障或数据错误，系统会自动进行数据恢复和修复。
Ceph分布式存储学习指南
云计算与虚拟化技术丛书Ceph分布式存储学习指南Learning Ceph（芬）卡伦·辛格（Karan Singh） 著Ceph中国社区 译ISBN：978-7-111-56279-5本书纸版由机械工业出版社于2017年出版，电子版由华章分社（北京华章图文信息有限公司，北京奥维博世图书发行有限公司）全球范围内制作与发行。
版权所有，侵权必究客服热线：+ 86-10-68995265客服信箱：service@官方网址：新浪微博 @华章数媒微信公众号 华章电子书（微信号：hzebook）我们喜欢称呼Ceph为“未来的存储”，这是一个能够引起很多不同层的人共鸣的称呼。
对于系统架构师而言，Ceph的系统架构满足了所有人都希望构建的一类系统的需求。
它是模块化和可扩展的，并且有容错设计的。
对于用户来说，Ceph为传统和新兴的工作负载提供了一系列存储接口，可以在商用硬件上运行，并且支持仅以适度的资本投资来部署生产集群。
对于免费软件爱好者来说，Ceph持续推动着这些技术，这些技术的代码库是完全开源的，且允许所有人免费审查、修改并完善这些代码，在存储行业中这些代码仍然成本昂贵且具有专有的使用权限。
Ceph项目始于我在加州大学圣克鲁斯的一个研究计划，这个计划由几个能源部实验室（洛斯·阿拉莫斯、劳伦斯·利弗莫尔和桑迪亚）资助。
这个计划的目标是进一步加强拍字节（PB）级别的扩展、基于对象的存储系统。
在2005年加入该组织的时候，我最初的重点是为文件系统构建可扩展的元数据管理，即如何在多个服务器之间管理文件和目录层次结构，这样，系统就可以响应超级计算机中的100万个处理器，在同一时间将文件写入文件系统的同一目录下。
在接下来的3年里，我们主要研究了这个关键概念，然后构建了一个完整的体系结构并一直致力于这种系统的实现。
2006年当我们将最初描述Ceph的学术论文发表，并将相关代码开源且发布在网上后，我想我的主要工作就已经完成了。
ceph中bluestore的ssd盘划分流程
ceph中bluestore的ssd盘划分流程Ceph是一个开源的分布式存储系统，广泛应用于云计算和大规模数据存储环境中。
Bluestore是Ceph中一种新的存储后端，它针对固态硬盘（SSD）进行了优化，提供了更高的性能和更低的延迟。
在使用Ceph中的Bluestore时，对SSD盘进行合理的划分是非常重要的，本文将一步一步地介绍Ceph中Bluestore的SSD盘划分流程。
第一步：了解硬件需求和性能目标在划分Bluestore的SSD盘之前，首先需要了解硬件需求和性能目标。
这包括SSD盘的规格（容量、接口等）、性能指标（IOPS、带宽等）以及预期的Ceph集群负载类型（随机读写、顺序读写等）。
根据这些需求和目标，可以选择合适的SSD盘，并确定划分方案。
第二步：选择合适的划分策略Ceph中Bluestore的SSD盘划分策略有多种选择，包括单盘分区、单盘多分区、多盘分区等。
对于不同的应用场景和性能需求，选择合适的划分策略非常重要。
1. 单盘分区单盘分区是将整个SSD盘作为一个分区使用。
这种划分策略简单直接，适用于SSD盘容量较大且性能较好的情况。
但是需要注意的是，单盘分区可能会导致数据写入集中在SSD盘的某一区域，造成SSD盘部分空间利用率较低。
2. 单盘多分区单盘多分区是将SSD盘划分为多个分区，并分别用于不同的Ceph OSD （对象存储守护进程）。
这种划分策略可以实现负载均衡，避免数据写入集中在某一区域。
同时，单盘多分区可以更好地利用SSD盘的容量，提高空间利用率。
3. 多盘分区多盘分区是将多个SSD盘划分为多个分区，并分别用于不同的Ceph OSD。
这种划分策略可以进一步提高性能和负载均衡。
多盘分区可以将负载分散到多个SSD盘上，并充分利用各个SSD盘的性能优势。
根据实际需求和性能目标，选择合适的划分策略非常关键。
在选择划分策略时，需要综合考虑SSD盘的容量、性能指标、硬件成本和Ceph集群负载类型等因素。
Ceph概念理解
Ceph概念理解简介Ceph是⼀个可靠地、⾃动重均衡、⾃动恢复的分布式存储系统，根据场景划分可以将Ceph分为三⼤块，分别是对象存储、块设备存储和⽂件系统服务。
在虚拟化领域⾥，⽐较常⽤到的是Ceph的块设备存储，⽐如在OpenStack项⽬⾥，Ceph的块设备存储可以对接OpenStack的cinder后端存储、Glance的镜像存储和虚拟机的数据存储。
⽐较直观的是Ceph集群可以提供⼀个raw格式的块存储来作为虚拟机实例的硬盘。
与其他存储相⽐的优势:充分利⽤了存储节点上的计算能⼒在存储每⼀个数据时，都会通过计算得出该数据存储的位置，尽量将数据分布均衡。
不存在传统的单点故障的问题，且随着规模的扩⼤性能并不会受到影响。
采⽤了CRUSH算法、HASH环等⽅法。
核⼼组件Ceph OSD(Object Storage Device):主要功能是存储数据、复制数据、平衡数据、恢复数据等，与其它OSD间进⾏⼼跳检查等，并将⼀些变化情况上报给CephMonitor。
⼀般情况下⼀块硬盘对应⼀个OSD，由OSD来对硬盘存储进⾏管理，当然⼀个分区也可以成为⼀个OSD。
Ceph OSD的架构实现由物理磁盘驱动器、Linux⽂件系统和Ceph OSD服务组成。
对于Ceph OSD Deamon⽽⾔，Linux⽂件系统显性的⽀持了其拓展性，⼀般Linux⽂件系统有好⼏种，⽐如有BTRFS、XFS、Ext4等，BTRFS。
虽然它们有很多优点特性，但现在还没达到⽣产环境所需的稳定性，⼀般⽐较推荐使⽤XFS。
⼀般写数据到Ceph集群时，都是先将数据写⼊到Journal盘中，然后每隔⼀段时间⽐如5秒再将Journal盘中的数据刷新到⽂件系统中。
⼀般为了使读写时延更⼩，Journal盘都是采⽤SSD，⼀般分配10G以上，当然分配多点那是更好。
Ceph中引⼊Journal盘的概念是因为Journal允许Ceph OSD功能很快做⼩的写操作。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
如果未超出，则将文件数据写入到inline data， inline version+1 mark caps dirty, inline_version+1, dirty 异步将inline data写到mds 如果超出，执行如下步骤：
将 inline data迁移至OSD 执行原有写操作写OSD 迁移完成后，将Inode中的inline data清空，将inline_version置为 CEPH_INLINE_DISABLED
3
Ceph p 架构
RADOS
Ceph的核心组件 提供高可靠、高可扩展的分布式对象存储架构 高 靠 高 布 利用本地文件系统存储对象
Cli t Client
Cephfs RBD Radosgw Librados
4
Ceph p Clients
Cephfs
提供POSIX兼容的分布式文件系统接口，支持 提供POSIX兼容的分布式文件系统接 支持 kernel、fuse
实现fallocate, 支持将文件的指定区域清 空，释放对应的存储对象
优势
可在虚拟机删除文件时回收主机存储空间
23
fallocate用途
Ceph用作虚拟机镜像文件存储时，可以 释放host h t 上的存储空间，节省存储容量 上的存储空间 节省存储容量
24
算法
OSD object处理
当hole覆盖了整个object时,将该object从 当h l 覆盖 整个 bj 时 将该 bj osd上删除 如果hole只涉及object的一部分, 将该部分 写0
优势
节省了数据存储位置计算时间 节省了与OSD的通信
14
Inline data support pp
文件状态设计
Inline 状态：文件所有数据都存放在元数据区 域，OSD上不存数据 Disable状态：文件所有数据从元数据区域完全 迁移至OSD，元数据区域不再存放文件数据
状态变迁
记录并维护inine data版本, data版本 记录inline状态 状态只能从inline状态变迁到disable状态，不 可逆转
支持文件分片存储 OSD、Monitor、MDS均支持集群运行， 支持动态增删节点 无单点失效 支持动态增删节点，无单点失效 动态子树划分
8
capability p y
为了维护数据一致性, 由mds给client颁 发file fil cap, 决定client li t允许进行的操作 Fb: 允许client进行带缓存的写操作 Fc: 允许client进行带缓存的读操作 对于同一个文件，当有大于1个的writer 或1个writer和1个或多个reader时， 时 client将进行无缓存的同步读写，除非 打开LAZYIO
Ceph分布式对象存储系统 研究与优化
汪黎
liwang@
提纲
Ceph介绍 我们的工作
2
概述
Ceph是Sage Weil 在 UCSC开发的大规模的、 可扩展的、开源的分布式存储系统 扩 的 源的分布式存储系统 Ceph client included in Linux kernel since 2.6.34 Supported by Openstack since Folsom Maintained by Inktank inc.
Page cache
如果hole覆盖page cache中的整个page cache中的整个page, 将 该page写回，删除 如果hole只涉及 page的一部分, page的 部分 将该部分写 0
25
Some tricks
如果hole覆盖第一个object,由于其包含有backtrace等 元数据信息, 不将其删除, 而是将其truncate到0
28
Rbd copy py on read
方法
读取镜像时异步的复制对象副本到克隆镜像 下次读取时直接从克隆对象读取
29
Copy py on read
优势
提升BRD镜像中对象第二次读的性能 升BRD镜像中对象第 次读 性
关键技术
异步复制对象时的流程处理
评测
Without copy on read 12 11.5 11 10.5 10 9.5 9 1 2 读写次数 3 4
Data striping支持
把连续的数据分割成相同大小的数据块,把每 段数 据分别写入到不同对象上的方法 参数
Object Size Stripe Width St i C Stripe Count t
26
Cephfs p Quota Support pp
动机
为Cephphfs实现quota支持 quota针对目录设置, 可限制目录下存放的文件容量及数 量 Cephfs没有一个统一的UID/GID机制，传统的基于用户 和组的配额很难使用 Cephfs一般跟应用配合使用 应用自己记录用户信息, Cephfs一般跟应用配合使用, 应用自己记录用户信息 将 用户关联到对应的Cephfs目录
9
Ceph p for OpenStack p
rbd
为Glance、Cinder提供镜像存储 为Glance Cinder提供镜像存储 提供Qemu/KVM驱动支持 支持 支持openstack的虚拟机迁移 t k的虚拟机迁移
rgw
替代swift
CephFS
提供共享的文件系统存储 支持ope stack的虚拟机迁移 支持openstack的虚拟机迁移
Copy on read
With copy on read
度（MB/s） 速度
30
谢谢！
31
20
文件执行流程
Write
在Client 在Cli t inline_version< i li i < CEPH_INLINE_DISABLED时，表示是inline data状 态 判断Client是否有FB权限
如果有FB权限，判断写文件范围是否超出设置的 如果有FB权限 判断写文件范围是否超出设置的 inline阈值
如果没有权限，执行超出inline 阈值的相同流程
21
Inline data support pp
测试环境：
操作系统：Ubuntu 12.04 x86_64 ceph版本：0.56.6 Ceph部署：15个OSD， 1个MDS， 1个MON
测试方法：
顺序读取一定数量的1k小文件，统计总共花费的时间
OSD 存储文件数据和元数据 Monitor 监视整个集群状态 维护并通告集群拓扑 结构 MDS 缓存和同步元数据 管理名字空间 Client 提供POSIX接口
7
Cephfs p 特色
数据与元数据分离
数据由OSD服务 元数据由MDS服务 但都存储在OSD上，作为不同的对象，MDS作 为元数据 h 为元数据cache
RBD
提供高可靠的，分布式的块接口
Radosgw
提供S3 Swift兼容的对象接口 提供S3、Swift兼容的对象接口
Librados
提供rados库调用接口
5
Rados特色
高可靠性
多副本 自动隔离失效节点 数据自动恢复 自 恢复
高可扩展性
数据分布式存储 数据透明扩容
CRUSH副本分布算法
6
Cephfs p 组成
11
我们的工作
基于Ceph的优化
面向海量小文件访问的性能优化
Inline data support 面向虚拟化场景的存储优化 Fallocate support 面向Cephfs文件系统的优化 Cephfs quota support
面向rbd克隆镜像的优化 bd克
Copy on read
12
Inline data support pp
测试结果： 测试结果
Inline data
60 间（单位：秒） 时间 40 20 0 1000 2000 文件数量 3000 无inline data 有inline data
22
Fallocate support pp
动机
Ceph用于虚拟镜像文件存储时，不能 在虚拟机文件系统删除文件时回收空间
方法
16
Some tricks
inline data迁移异步进行 避免反复推送uptodate inline data inline data功能可以开关 避免multiple clients同时迁移inline data, 导致修改丢失 避免一个client迁移inine data成功,但在 未通知mds之前失效, 以后新的inline data不能覆盖osd上旧的inline data
Inline data support pp
数据结构设计
inode添加两个域
uint64_t inline_version bufferlist inline_data inline data
inline_version
标识inline data的版本 维护数据的一致性和正确性 从1开始单调递增，最大值为2 ^ 64 – 1，即 CEPH INLINE DISABLED，定义为inline data support CEPH_INLINE_DISABLED，定义为inline 的disabled状态
inline_data
存放小文件的实际文件内容
18
文件操作流程