ceph

前言 BlueStore可以理解为一个支持ACID的本地日志型文件系统。所有的读写都是以 Transaction 进行，又因为支持覆盖写，所以写流程设计的相对复杂一些，涉及到一系列的状态转换。我们着重分析一下状态机、延迟指标以及如何保证IO的顺序性和并发性。 目录 状态机 延迟分析 IO保序 线程队列 IO状态 最后YY 状态机 queue_transactions queue_transactions 是ObjectStore层的统一入口，KVStore、MemStore、FileStore、BlueStore都相应的实现了这个接口。 state_t state 变量记录了当前时刻事物处于哪个状态。在创建TransactionContext的时候会将 state 初始化为 STATE_PREPARE ，然后在 _txc_add_transaction 中会根据操作码类型(opcode)进行不同的处理。同时会获取PG对应的OpSequencer(每个PG有一个OpSequencer)用来保证PG上的IO串行执行，对于deferred-write会将其数据写入RocksDB(WAL)。 以下阶段就进入BlueStore状态机了，我们以写流程为导向分析状态机的每个状态。 STATE_PREPARE 从state_prepare开始已经进入事物的状态机了。这个阶段会调用 _txc_add

1. PG介绍 这次主要来分享Ceph中的PG各种状态详解，PG是最复杂和难于理解的概念之一，PG的复杂如下： 在架构层次上，PG位于RADOS层的中间。 a. 往上负责接收和处理来自客户端的请求。 b. 往下负责将这些数据请求翻译为能够被本地对象存储所能理解的事务。 是组成存储池的基本单位，存储池中的很多特性，都是直接依托于PG实现的。 面向容灾域的备份策略使得一般而言的PG需要执行跨节点的分布式写，因此数据在不同节点之间的同步、恢复时的数据修复也都是依赖PG完成。 2. PG状态表 正常的PG状态是 100%的active + clean， 这表示所有的PG是可访问的，所有副本都对全部PG都可用。 如果Ceph也报告PG的其他的警告或者错误状态。PG状态表： 3.1 Degraded 3.1.1 说明 降级：由上文可以得知，每个PG有三个副本，分别保存在不同的OSD中，在非故障情况下，这个PG是active+clean 状态，那么，如果PG 的 副本osd.4 挂掉了，这个 PG 是降级状态。 3.1.2 故障模拟 a. 停止osd.1 $ systemctl stop ceph-osd@1 b. 查看PG状态 $ bin/ceph pg stat 20 pgs: 20 active+undersized+degraded; 14512 kB data, 302 GB used

什么是MinIO ？ 根据官方定义： MinIO 是在 Apache License v2.0 下发布的对象存储服务器。 它与 Amazon S3 云存储服务兼容。 它最适合存储非结构化数据，如照片，视频，日志文件，备份和容器/ VM 映像。 对象的大小可以从几 KB 到最大 5TB。 MinIO 服务器足够轻，可以与应用程序堆栈捆绑在一起，类似于 NodeJS，Redis 和 MySQL。 一种高性能的分布式对象存储服务器，用于大型数据基础设施。它是机器学习和其他大数 据工作负载下 Hadoop HDFS 的理想 s3 兼容替代品。 为什么需要MinIO？ Minio 有良好的存储机制 Minio 有很好纠删码的算法与擦除编码算法 拥有RS code 编码数据恢复原理 公司做强做大时，数据的拥有重要性，对数据治理与大数据分析做准备。 搭建自己的一套文件系统服务,对文件数据进行安全保护。 拥有自己的平台，不限于其他方限制。 MinIO 和其他OSS存储解决方案各有什么优缺点？ 这里主要针对Ceph、Minio、FastDFS 热门的存储解决方案进行比较。 Ceph 优点 成熟 红帽继子，ceph创始人已经加入红帽 国内有所谓的ceph中国社区，私人机构，不活跃，文档有滞后，而且没有更新的迹象。 从git上提交者来看，中国有几家公司的程序员在提交代码，星辰天合，easystack,

Ceph的结构 在 【Ceph浅析笔记】Ceph是什么.md 里面我们介绍了Ceph的基本思想。下面我们先来介绍一下Ceph的基本结构。 基础存储系统RADOS 最底层是数据真正存放的地方，物理上由大量的节点所构成，然后在上面加了一个 中间层 ，可以实现Ceph的可靠性、自动化、可扩展等特性，所有我们将之称为RADOS(Reliable,Autonomic,Distributed Object Store) librados 然后我们希望能对客户透明，也就是用户不需要关心底层如何实现的，只需要直接在Ceph上进行开发。所以又加了一堆库函数 librados 。 这些库函数与应用一般来说在同一台节点上，所以也被称为 本地API Restful API 由于Ceph是基于C++开发的，那么librados提供的结构也是C或者C++的。 而且我们也希望Ceph能于Amazon S3和Swift这些分布式系统所兼容，所以可以再在上面加一个中间层，比如RADOS GW, RDD,Ceph FS。 比如说RADOS GW，本质就是一个网关，也就是可以提供协议的转换，这样对外就可以兼容S3和Swift的了。 RBD，全称是Reliable Block Device，也就是一个 块设备 接口，这样上层的操作系统看到的其实就是裸硬盘。 有了块存储接口，当然也有文件系统接口，Ceph

Ceph是什么 什么是Ceph？首先我们应该明确，Ceph是一种 分布式存储系统 ，所谓 分布式 ，指的是Ceph可以部署在多台服务器上，通过多台服务器并行处理来对外提供高性能的读写块。 同时Ceph除了能提供块存储，还可以提供文件存储、对象存储。 Ceph的优势 实际上Ceph不是一个才出现的开源项目，而是走过了 7年的路程，那么Ceph有什么样的优势呢？ Ceph的优势在于它的 设计思想 ：无需查表，算算就好。也就是说它可以充分利用服务器的 计算能力 ，消除了对单一中心节点的依赖，可以实现 真正的无中心结构 这样Ceph的可靠性和可扩展性都很强，而且客户端访问延迟也比较少。 Ceph在OpenStack开源社区中备受重视。 OpenStack是现在最为流行的开源云操作系统，目前Ceph已经成为OpenStack中呼声最高的开源存储方案之一。 Ceph的产生和发展 一般来说开源项目的来源主要有两个，一个是从学校里面的一些课题，一个是企业里面的大牛对产品进行开源。Ceph就是典型的学院派，它起源于Sage Weil博士期间的课题，使用C++开发。 2011年Sage创建了Inktank公司以主导Ceph的开发和社区维护。 Ceph的设计思想 Ceph的应用场景 要理解Ceph的设计思想，我们首先应该研究这个东西的 应用场景 ，因为它的应用场景关系到它为什么这么设计。

一、Ceph简单介绍 1） OSDs: Ceph的OSD守护进程（OSD）存储数据，处理数据复制，恢复，回填，重新调整，并通过检查其它Ceph OSD守护程序作为一个心跳 向Ceph的监视器报告一些检测信息。Ceph的存储集群需要至少2个OSD守护进程来保持一个 active + clean状态.（Ceph默认制作2个备份，但可以调整它） 2） Monitors:Ceph的监控保持集群状态映射，包括OSD(守护进程)映射,分组(PG)映射，和CRUSH映射。 Ceph 保持一个在Ceph监视器, Ceph OSD 守护进程和 PG的每个状态改变的历史（称之为“epoch”）。 3） MDS: MDS是Ceph的元数据服务器，代表存储元数据的Ceph文件系统（即Ceph的块设备和Ceph的对象存储不使用MDS）。Ceph的元数据服务器使用POSIX文件系统，用户可以执行基本命令如 ls, find,等，并且不需要在Ceph的存储集群上造成巨大的负载。 Ceph把客户端的数据以对象的形式存储到了存储池里。利用CRUSH算法，Ceph可以计算出安置组所包含的对象，并能进一步计算出Ceph OSD集合所存储的安置组。CRUSH算法能够使Ceph存储集群拥有动态改变大小、再平衡和数据恢复的能力。 二、Ceph存储特点 Object：有原生的API，而且也兼容Swift和S3的API

目录 文章目录 目录 令牌桶算法 漏桶算法 前端 QoS：通过 QEMU 的块设备 IO 限速机制进行限速 后端 QoS：通过 librbd 的镜像 IO 限速机制进行限速 总结 参考文章 令牌桶算法 令牌桶算法是一个非常老牌的 I/O 控制算法，在网络、存储 I/O 上都有着广泛的应用。即：一个固定容量的桶装着一定数量的令牌，桶的容量即令牌数量上限。桶里的令牌每隔固定间隔补充一个，直到桶被装满。一个 IO 请求将消耗一个令牌，如果桶里有令牌，则该 IO 请求消耗令牌后放行，反之则无法放行。对于限制 IO 请求 bps，只需让一个 IO 请求消耗 M 个令牌即可，N 即为此 IO 请求的字节数。 令牌桶算法可以达到以下效果： 令牌桶算法可以通过控制令牌补充速率来控制处理 IO 请求的速率； 令牌桶算法允许一定程度的突发，只要桶里的令牌没有耗尽，IO 请求即可立即消耗令牌并放行，这段时间内 IO 请求处理速率将大于令牌补充速率，令牌补充速率实际为平均处理速率； 令牌桶算法无法控制突发速率上限和突发时长，突发时长由实际 IO 请求速率决定，若实际 IO 请求大于令牌补充速率且速率恒定，则： 突发时长 = 令牌桶容量 / (实际 IO 请求速率 - 令牌补充速率) 。 在令牌桶算法的描述中，有一个条件是无强制约束的，那就是在桶里的令牌耗尽时，无法放行的 IO 请求该怎么处理

修改主机名和 /etc/hosts 关闭防火墙和 SELINUX 安装和配置 NTP ceph-deploy 节点安装 安装 ceph-deploy sudo yum install ceph -deploy -y 配置 SSH（生成公秘钥实现免密访问） 添加 OSD ceph-deploy disk zap ceph2: /dev/vdb ceph3: /dev/vdb ceph-deploy osd prepare ceph2: /dev/vdb ceph3: /dev/vdb ★ 注意：[prepare 命令只准备 OSD 。在大多数操作系统中，硬盘分区创建后，不用 activate 命令也会自动执行 activate 阶段（通过 Ceph 的 udev 规则）。] 摘自： http: //docs.ceph.org.cn/rados/deployment/ceph-deploy-osd/ 所以下面的 activate 会报错，实际上 OSD 已经激活，这个时候推荐的做法是在 OSD 节点手动去看服务有没有启动。参：[OSD 启动确认(和 monitor 启动确认类似)] ceph-deploy osd activate ceph2: /dev/vdb ceph3: /dev/vdb 推送配置文件 ceph-deploy admin ceph1 ceph2 ceph3

个人理解Docker的每一个虚机其实是宿主操作系统中的一个进程。主要是一种虚拟化技术。OpenStack主要解决的是基础架构云的云服务问题。OpenStack是在虚拟化技术之上的一层，主要解决系统部署管理的自动化。OpenStack可以兼容多种虚拟化技术包括：PowerVM, KVM, VMware, Docker等。 openstack是Iaas，是管理IT资源的，利用openstack和计算，存储，网络资源池化，然后以很灵活的方式分配最终用户。 docker是一种软件包的集成技术。有点类似现实中的集装箱。 openstack本身可以使用docker技术去封装，去实施。 openstack管理的虚机中可以使用docker去部署各种开发环境。 Docker与OpenStack 类别 Docker OpenStack 应用平台 PaaS IaaS 部署难度 简单 复杂 执行性能 和物理性能几乎一致 vm会占用资源 镜像体积 MB GB 管理效率 简单 复杂 隔离性能 较高 彻底隔离 可管理性 单进程，较弱 完整的管理系统 网络连接 较弱 Neutron灵活组件网络 启动速度 极快 稍慢 openstack在硬件资源的管理方面已经比较成熟了： 单机的虚拟化技术优化 计算：kvm用的最多，已经非常成熟了；目前的一些重点在虚机热迁移的优化上。 存储/网络：SR-IOV或者vhost-net

1. 数据分布算法挑战 数据分布和负载均衡： a. 数据分布均衡，使数据能均匀的分布到各个节点上。 b. 负载均衡，使数据访问读写操作的负载在各个节点和磁盘的负载均衡。 灵活应对集群伸缩 a. 系统可以方便的增加或者删除节点设备，并且对节点失效进行处理。 b. 增加或者删除节点设备后，能自动实现数据的均衡，并且尽可能少的迁移数据。 支持大规模集群 a. 要求数据分布算法维护的元数据相对较小，并且计算量不能太大。随着集群规模的增 加，数据分布算法开销相对比较小。 2. Ceph CRUSH算法说明 CRUSH算法的全称为：Controlled Scalable Decentralized Placement of Replicated Data，可控的、可扩展的、分布式的副本数据放置算法。 pg到OSD的映射的过程算法叫做CRUSH 算法。(一个Object需要保存三个副本，也就是需要保存在三个osd上)。 CRUSH算法是一个伪随机的过程，他可以从所有的OSD中，随机性选择一个OSD集合，但是同一个PG每次随机选择的结果是不变的，也就是映射的OSD集合是固定的。 3. Ceph CRUSH算法原理 CRUSH算法因子： 层次化的Cluster Map 反映了存储系统层级的物理拓扑结构。定义了OSD集群具有层级关系的 静态拓扑结构。OSD层级使得