ceph

( Part 1/3 – Installation - Part 3/3 – librados client ) It is quite common that after the initial installation, the Ceph cluster reports health warnings. Before using the cluster for storage (e.g., allow clients to access it), a HEALTH_OK state should be reached: cluster-admin@ceph-mon0:~/ceph-cluster$ ceph health HEALTH_OK This part of the tutorial provides some troubleshooting hints that I collected during the setup of my deployments. Other helpful resources are the Ceph IRC channel and mailing lists. Useful diagnostic commands A collection of diagnostic commands to check the status of the

OSD::main() |__ObjectStore::create() |__调用FileStore构造函数创建FileStore类对象 |__MonClient::build_initial_monmap() 从配置文件中读取monitor map信息 |__OSD::mkfs() |__FileStore::mkfs() |__在/var/lib/ceph/osd/ceph-${id}/目录下生成fsid文件 |__在/var/lib/ceph/osd/ceph-${id}/目录下创建version_stamp文件 |__在/var/lib/ceph/osd/ceph-${id}/目录下创建superblock文件 |__在/var/lib/ceph/osd/ceph-${id}/目录下创建current文件夹 |__在/var/lib/ceph/osd/ceph-${id}/current/目录下创建commit_op_seq文件且初始化该文件的内容为1 |__在/var/lib/ceph/osd/ceph-${id}/current/omap/目录下创建osd_uuid文件（current/omap目录是OSD omap的工作目录） |__FileStore::mkjournal() |__FileStore::new_journal() |__FileJournal(

概述 本文介绍 Ubuntu 环境下使用 saltstack 。 环境 测试环境为 Ubuntu server 14.04 。 禁用 : 所有 Ubuntu 系统都禁用 selinux , iptables 。 5 个运行 Ubuntu server 14.04 x86_64 的虚拟机： 192 . 168 . 1 . 119 ceph - node1 192 . 168 . 1 . 111 ceph - node2 192 . 168 . 1 . 112 ceph - node3 192 . 168 . 1 . 113 ceph - node4 192 . 168 . 1 . 114 ceph - node5 我们分配 saltstack 中的角色： 所有节点 都担任 Minion 角色，ceph-node1 同时担任 Master 角色。 主机名 请按上面的机器分配，设置好每个机器的主机名。编辑各机器上的 /etc/hostname 文件即可。并修改 /etc/hosts里的 127.0.1.1 指向该名。本测试配置完成后是这样的： ouser@ceph-node1:~$ sudo salt '*' cmd.run 'grep 127.0.1.1 /etc/hosts' ceph-node2: 127.0.1.1 ceph-node2 ceph-node4: 127.0.1.1

tcmu+librbd环境搭建 1.环境 升级内核要求>=4.4.8 备注：解决 target__core__user.h 头文件缺失问题 cp target__core__user.h /usr/include/linux/ 2.安装依赖 2.1 ceph相关 yum install ceph-devel -y 2.1 其他依赖 yum install cmake3 make gcc libnl3-devel glib2-devel kmod-devel zlib-devel -y 2.TCMU-runner编译安装 2.1 获取源码 git clone [https://github.com/kitwestneat/tcmu-runner.git](https://github.com/kitwestneat/tcmu-runner.git) 2.2 编译安装 cmake -DCMAKE_INSTALL_PREFIX=/usr -Dwith-glfs=false -Dwith-qcow=false -D SUPPORT_SYSTEMD=true . make make install 2.3 启动tcmu-runner systemctl start tcmu-runner 3.targetcli安装 3.1下载地址 https://github.com/open-iscsi

一：概念介绍 Ceph对象网关是建立在librados之上的对象存储接口，可为应用程序提供通往Ceph存储集群的RESTful网关， Ceph对象存储支持两个接口 1.S3兼容：为对象存储功能提供与Amazon S3 RESTful API的大部分子集兼容的接口 2.Swift兼容：为对象存储功能提供与OpenStack Swift Ceph对象存储使用Ceph对象网关守护进程（radosgw），该守护进程是用于与Ceph存储群集进行交互的HTTP服务器，由于它提供与OpenStack Swift和Amazon S3兼容的接口，因此Ceph对象网关具有自己的用户管理。，Ceph对象网关可以将数据存储在一个同时拥有Ceph的文件系统客户端或Ceph块设备客户端的数据的一个Ceph存储群集中。 S3和Swift API共享一个公共的名称空间，因此您可以使用一个API写入数据，而使用另一个API读出数据。 二：安装 从Firefly（v0.80）开始，Ceph对象网关运行在Civetweb（嵌入到ceph-radosgw守护程序中）中，而不是Apache和FastCGI上，使用Civetweb可以简化Ceph对象网关的安装和配置，另外，从v0.80后开始，Ceph对象网关不支持SSL。您可以使用SSL设置反向代理服务器，以将HTTPS请求作为HTTP请求发送到CivetWeb。

Pg 和 pgp 的含义： PG 是指定存储池存储对象的目录有多少个， PGP 是存储池 PG 的 OSD 分布组合个数 PG 的增加会引起 PG 内的数据进行分裂，分裂到相同的 OSD 上新生成的 PG 当中 PGP 的增加会引起部分 PG 的分布进行变化，但是不会引起 PG 内对象的变动 存储池 pg 的计算： Pg 数量 = （ osd 数量 *200 ） / 副本数 例子 1 ：创建存储池时，有 10 个硬盘，副本数为 2 。 PgNumBase = (10 * 200) / 2 = 1000 ，找到的 N 为 9 ，即 29 < 1000 < 210 ，因为 1000 > ( 29 * 1.25 ) ，所以最后得到 PgNum = 1024 。 例子 2 ：创建存储池时，有 9 个硬盘，副本数为 3 。 PgNumBase = (9 * 200) / 3 = 600 ，找到的 N 为 9 ，即 29 < 600 < 210 ，因为 600 <= ( 29 * 1.25 ) ，所以最后得到的 PgNum = 512 。 Pg 的角色 正常情况下同一个 pg 所有的实例保存的内容完全相同，原则上不需要对它们的身份加以区分，但是出于数据一致性考虑，仍然需要从中选出一个起主导作用的实例，称为 Primary ，由其作为集中点对所有任务进行统筹管理。 Primary

osd对象存储设备： ceph中数据存储过程首先数据会被分割成多个object，(每个object一个object id，大小可设置，默认是4MB），object是Ceph存储的最小存储单元。由于object的数量很多，为了有效减少了Object到OSD的索引表、降低元数据的复杂度，使得写入和读取更加灵活，引入了pg(Placement Group )：PG用来管理object，每个object通过Hash，映射到某个pg中，一个pg可以包含多个object。 Pg再通过CRUSH计算，映射到osd中。如果是三副本的，则每个pg都会映射到三个osd，保证了数据的冗余。写入数据的过程如下图所示： 完成存储用户数据的工作绝大多数都是由osd daemon进程来实现的。集群中一般有多个osd，client将直接与osd进行I/O操作的交互，而不再需要ceph monitor干预。在ceph集群中每个osd高度自治，数据复制，数据恢复，数据迁移等都由osd自主进行而无需中心控制器干预；osd之间相互监督，确保故障能够被及时捕获和上报至monitor；通过osd与客户端、以及osd之间相互学习和点对点传播osdmap，ceph能够快速进行故障切换和恢复，并最大程度保证对外提供不中断的存储服务。 网络通讯 在设计上，ceph将整个RADOS集群网络分为两个独立的平面

ceph架构简介 在测试OpenStack的后端存储时，看到了ceph作为后端存储时的各种优势 ，于是查询资料，总结了这篇ceph架构的博客，介绍了ceph的架构和ceph的核心组件。ceph整体十分庞大，本文只是介绍了整体架构和概念，想要详细查看ceph请看博文： Ceph介绍及原理架构分享 1.1 Ceph简介 ​ Ceph是一个统一的分布式存储系统，设计初衷是提供较好的性能、可靠性和可扩展性。 1.2 Ceph架构 支持三种接口： Object：有原生的API，而且也兼容Swift和S3的API。 Block： 支持精简配置、快照、克隆。 File：Posix接口，支持快照。 1.2.1 架构介绍 1、ceph架构最底层是RADOS对象存储系统（Ceph最底层的存储单元是Object对象），外部想要访问该系统需要librados库。 2、ceph对外提供四种存储：应用直接访问RADOS、对象存储接口、块存储接口、文件系统接口；分别对应：代码直接访问、radosgw（rgw）、librbd（rbd）、元数据服务器（MDS） 1.3 Ceph核心组件及概念介绍 Monitor 一个Ceph集群需要多个Monitor组成的小集群，它们通过Paxos同步数据，用来保存OSD的元数据。 OSD OSD全称Object Storage Device

目录 Ceph 调整crush map 1、前言 2、示例 1、创建新的replicated 2、修改当前pool的rule Ceph 调整crush map 1、前言 本文章适用于ceph n版 2、示例 1、创建新的replicated ####命令模板###### ceph osd crush rule create-replicated <rule-name> <root> <failure-domain> <class> ###################示例##### ceph osd crush rule create-replicated ssd-rule default host ssd 2、修改当前pool的rule #####命令模板####### ceph osd pool set <pool-name> crush_rule <rule-name> ####示例######## ceph osd pool set ssd-pool crush_rule ssd-rule 来源： https://www.cnblogs.com/yanling-coder/p/11986810.html

Cluster map 存储了整个集群的数据的分布以及成员包括 mon map ,osd map, pg map,crush map 。 cluster map 不仅存储在 monitor 节点，它被复制到集群中的每一个存储节点，以及和集群交互的 client 。当因为一些原因，比如设备崩溃、数据迁移等， cluster map 的内容需要改变时， cluster map 的版本号被增加， map 的版本号可以使通信的双方确认自己的 map 是否是最新的，版本旧的一方会先将 map 更新成对方的 map ，然后才会进行后续操作。 一、 Cluster map 的实际内容包括： 1. Epoch ，即版本号。 cluster map 的 epoch 是一个单调递增序列。 epoch 越大，则 cluster map 版本越新。因此，持有不同版本 cluster map 的 OSD 或 client 可以简单地通过比较 epoch 决定应该遵从谁手中的版本。而 monitor 手中必定有 epoch 最大、版本最新的 cluster map 。当任意两方在通信时发现彼此 epoch 值不同时，将默认先将 cluster map 同步至高版本一方的状态，再进行后续操作。 2. 各个 OSD 的网络地址。 3. 各个 OSD 的状态。 OSD 状态的描述分为两个维度： up 或者 down