ceph

作者：张瑞旗 / 腾科IT培训集团 Gluster Storage和Ceph都是在开源技术的基础上开发出来开源应用，都属于SDS，即Software Defined Storage。时至今日，两个应用都收归红帽公司麾下。当你正在寻找一款存储解决方案时，你会选择哪一种产品呢？恐怕你特别想知道，Gluster Storage跟Ceph相比，到底哪个好呢？ 首先，我们要知道，这两个存储肯定不一样。到底哪里不一样？有人总结了这么一句： Ceph: scalable object storage with block and file capabilities Gluster: scalable file storage with object capabilities Ceph: 兼有块存储、文件存储功能的高扩展对象存储 Gluster: 兼有对象存储功能的高扩展文件存储 也就是说，Ceph主要是对象存储能力强，比较适用于存放小文件、需要频繁快速访问的文件。对象存储就意味着，存储到介质上的二进制数据是打散的、无序的。块存储则是连续存放在一起的。 Gluster以文件、文件夹的形式向客户端服务，管理操作更简单，更适用于长期存储、深度存储的文件或者大文件，如视频文件。例如AWS的Glacier超便宜的存储服务，将需要长期存档的数据存放在磁带盘上。查询的时候，先预约，3-5个工作日内即可查询

Ceph wen件系统的名称是 CephFS ，它是一个 POSIX 兼容的分布式文件系统，并使用Ceph RADOS 存储数据 。要实现 Ceph wen件系统，需要一个正常运行的 Ceph 存储集群，并且至少包含一个 Ceph 元数据服务器( Ceph Metadata Server, MDS) 。 客户端可以通过两种方式使用 Ceph wen件系统:使用本地内核驱动程序挂载 CephFS ，或者使用 Ceph FUSE。 （1）准备一个健康的ceph 集群 [root@node140 mds]# ceph -s cluster: id: 58a12719-a5ed-4f95-b312-6efd6e34e558 health: HEALTH_OK services: mon: 2 daemons, quorum node140,node142 (age 22h) mgr: admin(active, since 6d), standbys: node140 osd: 16 osds: 16 up (since 17h), 16 in (since 3d) data: pools: 5 pools, 768 pgs objects: 2.61k objects, 9.8 GiB usage: 47 GiB used, 8.7 TiB / 8.7 TiB avail pgs:

Creating Peering Activating Active Backfilling Backfill-toofull Backfill-wait Incomplete Inconsistent Peered Recovering Recovering-wait Remapped Scrubbing Unactive Unclean Stale Undersized down Creating 含义：PG正在创建 引起原因：创建pool的时候，根据指定的pg数量进行创建pg时出现的状态，正常状态 后果：无 解决方案：无需解决，正常状态之一 Peering 含义：PG之间进行互联，就其中的对象和元数据状态达成一致 引起原因：当pg被creating之后，会进行互联，存储归置组副本的 OSD 之间就其中的对象和元数据状态达成一致。 后果：无 解决方案：无需解决，正常状态之一 Activating 含义：pg在完成peering过程后，会对之前的结果进行固化，等待所有pg同步，尝试进入active状态 引起原因：pg进入active前的准备状态 后果：如果长期卡在该状态，会影响该PG无法读写，进而影响整个pool可用性 解决方案：停掉PG所在所有OSD 用ceph-object-tool进行pg数据备份 用ceph-object-tool在主PG上删除空的pg（不要手动删除）

对于cache的东西啊，我曾经在公司的项目中，有写过cache的经历，所以我以为我很了解，在我看ceph手册对于cache tier描述的时候，感觉没啥新鲜的东西，但是当我对应到ceph源码级别的时候，发现自己YY的ceph cache tier不太正确。了解不难，深入不易啊。闲话少说进入正题。（排版有点乱） 一、什么是cache tier 在ceph的手册里 http://docs.ceph.com/docs/master/rados/operations/cache-tiering/ 中对 cache tiering 进行了描述。 分布式的集群一般都是采用廉价的pc搭建，这些pc通常使用的是传统的机械硬盘，所以在磁盘的访问速度上有一定的限制，没有理想的iops数据。当去优化一个系统的IO性能时，最先想到的就是添加cache，热数据在cache被访问到，缩短数据的访问延时。Cache 一般会有 memory 或者ssd来做，考虑到价格和安全性，一般都是采用ssd作为cache。尤其实在随机io上，如果随机io全部放在ssd上，等数据冷却，将数据合并后，再刷入机械硬盘中，提升系统的io性能。(本来是想给大家看一下ssd和机械盘的性能测试结果的，但是测试数据是公司的不能放出来，自己测试的数据找不到了。。。。)。 对于ceph而言，怎么利用ssd作为普通磁盘的cache的，从手册中可知

源码编译安装 ganesha 简介 系统环境：CentOS 7.5 ceph：luminous nfs-gnesha：v2.6 stable 安装步骤 安装依赖 首先需要安装编译会用到的公共库 1 yum install gcc git cmake autoconf libtool bison flex doxygen openssl-devel gcc-c++ krb5-libs krb5-devel libuuid-devel nfs-utils -y 如果是使用 Ubuntu 系统，主要有以下几个包不同 gcc-c++ -> g++ libuuid-devel -> uuid-dev nfs-utils -> nfs-kernel-server 如果要生成 FSAL_RGW 模块，需要安装 librgw2-devel 1 yum install librgw2-devel -y 如果要生成 FSAL_CEPH 模块，需要安装 libcephfs1-devel 1 yum install libcephfs-devel -y 源码下载 克隆源码到本地 1 git clone -b V2.6-stable https://github.com/nfs-ganesha/nfs-ganesha.git --recursive 编译 cmake nfs-ganesha 源码

http://www.zphj1987.com/2016/09/19/%E6%9B%BF%E6%8D%A2OSD%E6%93%8D%E4%BD%9C%E7%9A%84%E4%BC%98%E5%8C%96%E4%B8%8E%E5%88%86%E6%9E%90/ 前言 之前有写过一篇 删除OSD的正确方式 ，里面只是简单的讲了下删除的方式怎样能减少迁移量，本篇属于一个扩展，讲述了 Ceph 运维当中经常出现的坏盘提换盘的步骤的优化 基础环境两台主机每台主机8个 OSD，一共 16 个 OSD，副本设置为2，PG 数设置为800，计算下来平均每个 OSD 上的 P G数目为100个，本篇将通过数据来分析不同的处理方法的差别 开始测试前先把环境设置为 noout ，然后通过停止 OSD 来模拟 OSD 出现了异常，之后进行不同处理方法 测试三种方法 首先 out 一个 OSD，然后剔除 OSD，然后增加 OSD 停止指定 OSD 进程 out 指定 OSD crush remove 指定 OSD 增加一个新的 OSD 一般生产环境会设置为 noout ，当然不设置也可以，那就交给程序去控制节点的 out，默认是在进程停止后的五分钟，总之这个地方如果有 out 触发，不管是人为触发，还是自动触发数据流是一定的，我们这里为了便于测试，使用的是人为触发，上面提到的预制环境就是设置的 noout

通过cgroup将ceph-osd进程与某一个 CPU core 绑定脚本： mkdir -p /sys/fs/cgroup/cpuset/ceph # cup number : 0,1,2,3 = 0-3 echo 0,4 > /sys/fs/cgroup/cpuset/ceph/cpuset.cpus # NUMA node echo 0 > /sys/fs/cgroup/cpuset/ceph/cpuset.mems osd-pid-list=$(ps aux | grep osd | grep -v grep | awk '{print $2}') for osd-pid in $(osd-pid-list) do echo $(osd-pid) > /sys/fs/cgroup/cpuset/ceph/cgroup.procs done 来源： https://www.cnblogs.com/wangjq19920210/p/11428042.html

什么是StatefulSet StatefulSet 是Kubernetes中的一种控制器，他解决的什么问题呢？我们知道Deployment是对应用做了一个简化设置，Deployment认为一个应用的所有的pod都是一样的，他们之间没有顺序，也无所谓在那台宿主机上。需要扩容的时候就可以通过pod模板加入一个，需要缩容的时候就可以任意杀掉一个。但是实际的场景中，并不是所有的应用都能做到没有顺序等这种状态，尤其是分布式应用，他们各个实例之间往往会有对应的关系，例如：主从、主备。还有数据存储类应用,它的多个实例，往往会在本地磁盘存一份数据，而这些实例一旦被杀掉，即使从建起来，实例与数据之间关系也会丢失，而这些实例有不对等的关系，实例与外部存储有依赖的关系的应用，被称作“有状态应用”。StatefulSet与Deployment相比，相同于他们管理相同容器规范的Pod，不同的时候，StatefulSet为pod创建一个持久的标识符，他可以在任何编排的时候得到相同的标识符。 StatefulSet的应用特点: 稳定且有唯一的网络标识符 当节点挂掉，既pod重新调度后其PodName和HostName不变，基于Headless Service来实现 稳定且持久的存储 当节点挂掉，既pod重新调度能访问到相同的持久化存储，基于PVC实现 有序、平滑的扩展、部署 即Pod是有顺序的

Ceph 存储集群可以从RBD的快照中创建写时复制 (COW 副本），这就是 Ceph 的快照分层。 Ceph 的这个分层特性允许客户端创建 Ceph RBD 的多个即时副本， 这个特性对云平台和虚拟化平台非常有 ，例如 OpenStack 、CloudStack 和Qemu/ KVM 这些平台通常'以快照的形式保护含有 OS/VM 镜像的Ceph RBD 镜像 ，然后通过不断复制这个快照来创建新的虚拟机 /实例 ，快照是只读的，但是 COW 副本则是完全可写的; Ceph 的这个特性为云平台带来巨大的灵活性，并且对于云平台非常有用，下图显示了 RADOS 块设备、 RBD 快照和COW 快照副本之间的关系。 每一个复制的镜像(子镜像)都包含它的父快照的引用，用于读取镜像数据。 因此，父快照在用于复 制之前应该处于被保护状态。当有数据写入COW 复制的镜像时，它会为自己存储新的数据引用。 COW 复制的镜像与 RBD是一 样的。 它们都非常灵活，类似于 RBD ，也就是说，它们可写， 可调整容量，可以创建新的快照，将来还可以复制。 RBD 镜像的类型定义了它所支持的特性，在Ceph 中，有两种 类型的RBD 镜像:format-l和 form t-2， format-l和 format-2 类型的 RBD 镜像 都支持快 照特性。然而，分层特性( 也就是 COW 特性)只有

Ceph 完全支持快照，它是一个基于时间点的、只读的 RBD 镜像副本。 可以通过创建快 照并恢复其原始数据，保存 Ceph RBD 镜像的状态。 快照操作: （0）客户端已经map了remote_rbd1 的rbd [root@zabbix71 alertscripts]# rbd showmapped id pool namespace image snap device 0 rbd remote_rbd1 - /dev/rbd0 （1）rbd已经mount在mnt目录 [root@zabbix71 alertscripts]# df -h Filesystem Size Used Avail Use% Mounted on /dev/rbd0 150G 9.8G 141G 7% /mnt （2）在/mnt下创建2个测试文件 [root@zabbix71 mnt]# ls ceph-file test test1 （3）服务器端做快照 语法： rbd snap create<pool-name>/<image-name> @<snap-name [root@node140 ~]# rbd snap create rbd/remote_rbd1@snap1 [root@node140 ~]# rbd snap ls rbd/remote_rbd1 SNAPID NAME SIZE