ceph

这个脚本写的是真心费劲！波哥不容易啊！ 老规矩吧： 1 git clone https://github.com/luckman666/deploy_ceph_cluster_luminous_docker.git 2 cd deploy_ceph_cluster_luminous_docker && chmod -R 755 . 3 # 编辑base.config里面的参数 4 ./deploy_ceph_master.sh 之前写的ceph(jewlel)由于相关源不稳定，导致脚本经常失败无法下载！ 所以写了一个ceph(luminous) docker部署ceph(luminous)相关的稳定镜像我已经打包到个人的公开仓库中 配置文件部分剪影 根据需要配置相应的参数脚本主要功能（可选）： 自动互信， 时钟同步， 更改主机名， 自动部署mon集群， 自动部署OSD集群， 自动部署MGR主备 自动部署RGW集群 自动添加portainer监控，管理集群容器 执行完后刷新所在服务器环境变量或者重新登录服务器。 执行ceph -s查看集群情况 查看服务器进程运行情况： MGR集群监控情况，根据集群显示结果查看MGR位置，并输入相应的IP及端口号 添加OSD命令（替换相应变量） $ceph_base_path 磁盘设备根目录 $odisk 磁盘设备名 $ceph_base_path

1、安装 ceph-mgr-dashboard yum install -y ceph-mgr-dashboard 2、禁用 SSL ceph config set mgr mgr/dashboard/ssl false 3、【可选】配置 host 和 port ceph config set mgr mgr/dashboard/server_addr $IP ceph config set mgr mgr/dashboard/server_port $PORT IP 不设置，默认绑定 :: ，禁用 ssl 之后，PORT 默认 8080 4、启用 Dashboard ceph mgr module enable dashboard 5、用户、密码、权限 # 创建用户 ceph dashboard ac-user-create <username> <password> administrator # 更多操作，查看帮助 ceph dashboard -h 6、查看 Dashboard 状态 ceph mgr services 使变更的配置生效 ceph mgr module disable dashboard ceph mgr module enable dashboard 配置访问前缀 ceph config set mgr mgr/dashboard/url_prefix

Ŀ¼ 首先需要说明的是，ceph的osd是不建议做成raid10或者raid5的，一般建议单盘跑。在我们的环境中，为了充分利用raid卡的缓存，即使是单盘，我们还是将其挂在raid卡下做成raid0。 这样不可避免的问题就是磁盘的损坏，需要在ceph当中做一些摘除动作，同时还需要重建raid。 在更换完磁盘重建raid之后，需要重新添加osd。新的osd加入到集群后，ceph还会自动进行数据恢复和回填的过程。我们还需要通过调整一些数据恢复和回填的参数来控制其恢复速度。 下面是详细的说明。 一般来讲，通过硬件监控，我们能感知到磁盘故障。但是故障的磁盘对应于系统中的哪一个盘符却没法知道。 我们可以通过检查dmesg日志来确认： [4814427.336053] print_req_error: 5 callbacks suppressed[] [4814427.336055] print_req_error: I/O error, dev sdi, sector 0 [4814427.337422] sd 0:2:5:0: [sdi] tag#0 FAILED Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK [4814427.337432] sd 0:2:5:0: [sdi] tag#0 CDB: Read(10) 28 00

本文讲述了ceph-fuse客户端问题排查基本流程：) 首先查看集群的整体情况 ceph -s 是否有osd挂掉，是否有pg非active ceph-fuse进程是否存在? ps -ef |grep ceph-fuse ceph-fuse进程不存在 需查看日志看什么原因，log文件默认为 /var/log/ceph/ceph-client.${user_id}.log ceph-fuse进程存在，但是访问卡 ceph-fuse客户端的unix socket文件为： /var/run/ceph/ceph-client.${user_id}.asok 其中${user_id} 一般为admin，可以通过查看ceph-fuse进程获取，或通过查看ceph.conf获得 1. 检查下该客户端与mds的连接session是否正常： ceph daemon /var/run/ceph/ceph-client.${user_id}.asok mds_sessions 如果mds session 的state不是open，通过netstat -anp 查看下客户端到mds的网络连接是否存在，状态是否正常，并根据情况决定是否往网络方向进行进一步检查 2. 访问卡住，说明客户端有正在进行中的请求，该请求可能是发往mds，也有可能是发往osd，通过如下命令查看： 查看客户端发往mds的请求： ceph

转载：https://www.cnblogs.com/happy-king/p/9193975.html#_label0 阅读目录 一、Ceph与Gluster之开源存储的对比 一、Ceph与Gluster的原理对比 　　Ceph和Gluster是Red Hat旗下的成熟的开源存储产品，Ceph与Gluster在原理上有着本质上的不同。 　　1、Ceph 　　Ceph基于一个名为RADOS的对象存储系统，使用一系列API将数据以块(block)、文件(file)和对象(object)的形式展现。Ceph存储系统的拓扑结构围绕着副本与信息分布，这使得该系统能够有效保障数据的完整性。 　　2、Gluster 　　Gluster描述为Scale-out NAS和对象存储系统。它使用一个Hash算法来计算数据在存储池中的存放位置，这点跟Ceph很类似。在Gluster中，所有的存储服务器使用Hash算法完成对特定数据实体的定位。于是数据可以很容易的复制，并且没有中心元数据分布式存储无单点故障且不易造成访问瓶颈，这种单点在早期Hadoop上出现，对性能和可靠性造成较大影响。 二、Ceph文件系统架构 　　RADOS(Reliable, Autonomic、Distributed Object Store)是Ceph系统的基础，这一层本身就是一个完整的对象存储系统，包括Cehp的基础服务

一、ceph概念 　　Ceph是一种为优秀的性能、可靠性和可扩展性而设计的统一的、分布式文件系统。ceph 的统一体现在可以提供 文件系统 、 块存储 和 对象存储 ，分布式体现在可以 动态扩展 。 特点： （1）高性能： 　　a. 摒弃了传统的集中式存储元数据寻址的方案，采用 CRUSH 算法，数据分布均衡，并行度高。 　　b.考虑了容灾域的隔离，能够实现各类负载的副本放置规则，例如跨机房、机架感知等。 　　c. 能够支持上千个存储节点的规模，支持TB到PB级的数据。 （2）高可用性： 　　a. 副本数可以灵活控制。 　　b. 支持故障域分隔，数据强一致性。 　　c. 多种故障场景自动进行修复自愈。 　　d. 没有单点故障，自动管理。 （3）高可扩展性： 　　a. 去中心化。 　　b. 扩展灵活。 　　c. 随着节点增加而线性增长。 （4）特性丰富： 　　a. 支持三种存储接口：块存储、文件存储、对象存储。 　　b. 支持自定义接口，支持多种语言驱动。 二、ceph组件 （1） Monitors：监视器 ，维护集群状态的多种映射，同时提供认证和日志记录服务，包括有关monitor 节点端到端的信息，其中包括 Ceph 集群ID，监控主机名和IP以及端口。并且存储当前版本信息以及最新更改信息，通过 "ceph mon dump"查看 monitor map。 （2） MDS

S3分段上传技术主要应用在大文件的数据上传上，通常在S3客户端会对上传的大文件做一次分片操作。在RGW内部还会对S3客户端发送过来的数据再进行一次分片处理，RGW默认分片大小是4MB。下面就Multipart不同部分进行详细解析。 1、初始化Multipart。 初始化Multipart使用的是HTTP POST操作，在RGW中使用RGWInitMultipart_ObjStore_S3类处理。由于RGWInitMultipart_ObjStore_S3类继承自RGWInitMultipart_ObjStore，而RGWInitMultipart_ObjStore类继承自RGWInitMultipart，而RGWInitMultipart类继承自RGWOp类。因此处理Mulipart初始化的操作主要集中在RGWInitMultipart::execute()函数中。下面对该函数的处理流程进行详细解析。 RGWInitMultipart::execute() |__RGWInitMultipart_ObjStore_S3::get_params() 从HTTP请求中得到RGWAccessControlPolicy_S3类实例 |__将RGWAccessControlPolicy_S3放入到属性列表中且属性key＝RGW_ATTR_ACL |__rgw_get_request

一、Get Object。 1、读取Object的主要处理流程。 RGWGetObj::execute() |__创建RGWGetObj_CB类实例，其中handle_data()函数为回调函数，该函数会调用RGWGetObj::get_data_cb()函数，而该函数最终会调用send_reponse_data() |__创建RGWRados::Object类实例 |__创建RGWRados::Object::Read类实例 |__get_params() 从HTTP请求字符串中读取range_str/if_mod/if_unmod/if_match/if_nomatch信息 |__init_common() 解析range_str/if_mod/if_unmod内容 |__RGWRados::Object::Read::prepare() |__RGWRados::get_state() |__RGWRados::get_obj_state() |__RGWRados::get_obj_state_impl() |__RGWObjectCtx::get_state() |__RGWRados::raw_obj_stat() |__检查attrset中是否包含RGW_ATTR_SHADOW_OBJ属性并将属性值写入到RGWObjState::shadow_obj中 |_

KeyValueStore 是 Ceph 支持的另一个存储引擎(第一个是FileStore)，它是在 Emporer 版本中Add LevelDB support to ceph cluster backend store Design Summit 上由本人提出并实现了原型系统，在 Firely 版本中实现了与 ObjectStore 的对接。目前已经合并到 Ceph 的 Master 上。 KeyValueStore 相对于 FileStore 是一个轻量级实现，目标是利用其不同 Backend 提供的能力来为 Ceph 的不同应用场景服务。如目前的默认 engine 是 LevelDB，期望来提供高性能的写性能。 主要数据结构 KeyValueStore 主要由三部分组成，一个是继承ObjectStore 的KeyValueStore 类，另一个是GenericObjectMap(类似于FileStore 的DBObjectMap)，最后一个是继承GenericObjectMap 的StripObjectMap。GenericObjectMap 是主要用来访问后端Engine 的实现，它的作用有点类似VFS，而Engine 就是各种不同的FileSystem，它抽象出一些基本的方法(read/write)和一些高级接口(rename/clone)等等

一：Ceph基础介绍 Ceph是一个可靠地、自动重均衡、自动恢复的分布式存储系统，根据场景划分可以将Ceph分为三大块，分别是对象存储、块设备存储和文件系统服务。 Ceph相比其它存储的优势点在于它不单单是存储，同时还充分利用了存储节点上的计算能力，在存储每一个数据时，都会通过计算得出该数据存储的位置，尽量将数据分布均衡，同时由于Ceph的良好设计，采用了CRUSH算法、HASH环等方法，使得它不存在传统的单点故障的问题，且随着规模的扩大性能并不会受到影响。 二：核心组件介绍 Ceph OSD（必装） 全称是Object Storage Device，主要功能包括存储数据，处理数据的复制、恢复、回补、平衡数据分布，并将一些相关数据提供给Ceph Monitor Ceph Monitor（必装） Ceph的监控器，主要功能是维护整个集群健康状态，提供一致性的决策，包含了Monitor map，即集群map，monitor本身不存储任何集群数据 Managers（必装） Ceph Manager守护进程（ceph-mgr）负责跟踪运行时指标和Ceph集群的当前状态，包括存储利用率，当前性能指标和系统负载。Ceph Manager守护进程还基于python的插件来管理和公开Ceph集群信息，包括基于Web的Ceph Manager Dashboard和 REST API