OSD全称Object Storage Device,也就是负责响应客户端请求返回具体数据的进程。一个Ceph集群一般都有很多个OSD。
要增加一个 OSD,要依次创建数据目录、把硬盘挂载到数据目录、把 OSD 加入集群、然后把它加入 CRUSH Map。
OSD进程的启动停止:https://blog.csdn.net/bandaoyu/article/details/119894927
client 无法链接mon的可能原因 1.连通性和防火墙规则。在MON主机上修改允许TCP 端口6789的访问。 2.磁盘空间。每个MON主机上必须有超过5%的空闲磁盘空间使MON和levelDB数据库正常工作。 3.MON没有工作或者离开选举,检查如上命令输出结果中的quorum_status和mon_status或者ceph -s 的输出来确定失败的MON进程,尝试重启或者部署一个新的来替代它。
资料(传送门)[http://bbs.ceph.org.cn/question/363]
问题背景 集群中剔除了一个osd,没有新加入,进行了一次pg的均衡,做完均衡后集群出现· Degraded data redundancy: 256 pgs undersized,为了保证集群的pg副本数为3,需要新添加一个osd来做pg的均衡 ceph 集群的状态 [root@node1 ~]# ceph -v ceph version 14.2.18 (befbc92f3c11eedd8626487211d200c0b44786d9) nautilus (stable) [root@node1 ~]#
节点的故障检测是分布式系统无法回避的问题,集群需要感知节点的存活,并作出适当的调整。通常我们采用心跳的方式来进行故障检测,并认为能正常与外界保持心跳的节点便能够正常提供服务。一个好的故障检测策略应该能够做到:
[root@node1 ~]# ceph auth list installed auth entries:
转载 https://cloud.tencent.com/developer/user/1021473/inventories
ceph是以对象的形式存储数据的,但是对象的存储并不会直接存储进OSD中,因为对象的size很小,在一个大规模的集群中可能有几百到几千万个对象。这么多对象光是遍历寻址,速度都是很缓慢的,也不可能在对象这一级追踪位置;并且如果将对象直接通过某种固定映射的哈希算法映射到osd上,当这个osd损坏时,对象无法自动迁移至其他osd上面。为了解决这些问题,ceph引入了归置组的概念,即PG。
Ceph通过伙伴OSD汇报失效节点和Monitor统计来自OSD的心跳两种方式判定OSD节点失效。
nearfull osd(s) or pool(s) nearfull 此时说明部分osd的存储已经超过阈值,mon会监控ceph集群中OSD空间使用情况。如果要消除WARN,可以修改这两个参数,提高阈值,但是通过实践发现并不能解决问题,可以通过观察osd的数据分布情况来分析原因。
在SUSE Linux Enterprise Server 11 SP3上轻松搭建Ceph集群。
SkeyePlayer RTSP Windows播放器新增OSD字幕叠加接口方法,这个接口和码率信息显示接口方法类似,都是调用FFRender库的接口实现的多OSD叠加,下面讲解下该方法的调用和注意事项;
最近用一组Fedora 19的虚拟机部署了一下ceph 0.81,由于ceph有了简化的部署工具ceph-deploy,看起来部署是个相当简单的过程,理论上应该就是下面几步:
在现有集群加入一个物理节点,接着再此节点创建ceph监视器、创建OSD。从宿主机系统执行ceph osd tree查看状态,创建起来的几个OSD状态都正常(up),从proxmox管理界面看也是这样。
ceph集群作为存储后端开始使用后扩osd时,每次添加完后等ceph集群恢复正常后再继续添加下一个,避免同时添加2个及以上的osd。
1. WBThrottle 监控类型 监控项 说明 perf dump WBThrottle bytes_dirtied 脏数据大小 bytes_wb 写入数据大小 ios_dirtied 脏数据操作 ios_wb 写操作 inodes_dirtied 等待写入的条目 inodes_wb 写记录 2. filestore 监控类型 监控项 说明 perf dump filestore journal_queue_max_ops 日志队列中的最大操作 journal_queue_ops 日志队列
###How to remove OSD from Ceph cluster It is not well described in the docs.
手动在目录/var/lib/ceph/bootstrap-osd/下新建删除文件正常,把ceph服务都重启了一遍还是这样。
如果一个OSD处于up状态,那么它可以是在集群内,也可以是在集群外,如果之前的状态为 up 且 in,现在变成 up out了,那么ceph会把PG迁移到其他的OSD上。如果某个OSD的变成out了,则crush就不会再分配PG给它,如果状态为down,那么它的状态就会为out,默认在OSD down掉300s后标记它为out状态
1. 查看数据分布是否均衡 #查看osd使用情况 $ ceph osd df tree ID CLASS WEIGHT REWEIGHT SIZE USE AVAIL %USE VAR PGS TYPE NAME -1 196.21051 - 190T 347G 190T 0.18 1.00 - root default -3 65.40106 - 61390G 115G 61274G 0.19 1.06 -
PG数量的预估 集群中单个池的PG数计算公式如下:PG 总数 = (OSD 数 * 100) / 最大副本数 / 池数 (结果必须舍入到最接近2的N次幂的值)
创建一个新集群后,PG 的状态一直处于 active , active + remapped 或 active + degraded 状态, 而无法达到 active + clean 状态 ,那很可能是你的配置有问题。
对每个人而言,真正的职责只有一个:找到自我。然后在心中坚守其一生,全心全意,永不停息。所有其它的路都是不完整的,是人的逃避方式,是对大众理想的懦弱回归,是随波逐流,是对内心的恐惧 ——赫尔曼·黑塞《德米安》
进行 OSD 排障前,先检查一下 monitors 和网络。如果 ceph health 或 ceph -s 返回的是健康状态,这意味着 monitors 形成了法定人数。如果 monitor 还没达到法定人数、或者 monitor 状态错误,要先解决 monitor 的问题。核实下你的网络,确保它在正常运行,因为网络对 OSD 的运行和性能有显著影响。
下一篇: Docker 部署Jira8.1.0→
设置osd分类前osd需要是未分类的,即:修改osd分类的做法是,先移除原有的分类,在添加新的分类:
最下面的蓝色长条可以看成一个个主机,里面的灰色圆柱形可以看成一个个OSD,紫色的cabinet可以也就是一个个机柜, 绿色的row可以看成一排机柜,顶端的root是我们的根节点,没有实际意义,你可以把它看成一个数据中心的意思,也可以看成一个机房的意思,不过只是起到了一个树状结构的根节点的作用。 CRUSH从root下的所有的row中选出一个row。 在刚刚的一个row下面的所有cabinet中,CRUSH选出三个cabinet。 在刚刚的三个cabinet下面的所有OSD中,CRUSH分别选出一个OSD。 这样做的根本意义在于,将数据平均分布在了这个集群里面的所有OSD上,同时,这样选择做到了三个OSD分布在三个不同的cabinet上。
如果是在admin节点修改的ceph.conf,想推送到所有其他节点,则需要执行下述命令
整个Bluestore现在由官方推出的ceph-volume工具进行管理,用以替代之前的ceph-disk。回顾之前ceph-disk是通过在xfs文件系统中打上相应的attributes,之后通过制定udev rules来实现启动。无论Ceph版本如何变化,基本的OSD自启动思路都是给块设备打标签->定制开机服务去触发执行。总结一下就是 Filestore的思路是: OSD打上xfs(attr) -> 由ceph-disk 触发执行 Bluestore的思路是: OSD打上LVM(tag) -> 由ceph-volume 触发执行 因此只要搞清楚LVM的tag机制,基本上就能很快搞定OSD自启动的相关排错问题。
Ceph是一款以对象存储技术(独立存储技术)为核心,并在此基础之上实现块存储、文件系统的一体化存储系统。
这些集群范围内的配置参数定义在Ceph的配置文件中,因此任何一个Ceph守护进程启动时都将会遵循已定义的设置。缺省的配置文件是ceph.conf,放在/etc/ceph目录下。这个配置文件有一个global部分和若干个服务类型部分。任何时候一个Ceph服务启动,都会应用[gloabl]部分,以及进程特定部分的配置。一个Ceph配置文件有多个部分,如下图所示。
前段时间匆匆地为老PVE(Proxmox Virtual Environment)集群的CEPH增加了SSD,之后匆匆地简单对比记下了写了那篇“使用SSD增强Ceph性能的比较测试”,之后才反应过来——操作步骤和过程没写。这里补上。
Ceph自动化部署工具现状 ceph-deploy 已经处于被淘汰边缘(官方现在主推ceph-ansible),deploy新手练手可以,配置管理太弱鸡,每次overwrite-conf都需要很大勇气。 ceph-ansible 看起来很美好,但是无法完美适配手头各种差异化的部署需求,看完源码,把里面核心的模块功能抽取出来,完全可以自己做,没必要拿官方的ansible。 ceph-deploy其实也是通过ssh去控制各个节点的ceph-disk命令工具执行,但是ceph-disk又被官方弃坑,最新版本推荐使
OSDMap 机制是 Ceph 架构中非常重要的部分,PG 在 OSD 上的分布和监控由 OSDMap 机制执行。OSDMap 机制和 CRUSH 算法一起构成了 Ceph 分布式架构的基石。
Ceph 配置文件可用于配置存储集群内的所有守护进程、或者某一类型的所有守护进程。要配置一系列守护进程,这些配置必须位于能收到配置的段落之下,比如:
之前看过一个朋友一篇文章,讲述的是Vsan为什么使用的是两副本,而ceph则大多数情况下需要三副本,当时个人观点是这个并不是关键点,但是在仔细考虑了问题的出发点以后,这个也可以说是其中的一个点 一个集群数据丢失可以从多方面去看
Rook 本身很复杂,包含很多 Controller,而 Rook 的复杂不仅体现在这里,并且 Ceph 也非常复杂,在部署和运维上有很多需要注意的地方。本文主要剖析 Rook 启动 osd 的流程,如果有部署过 Ceph 的经验,应该知道加入 osd 大概有两个步骤,1是先 prepare,也就是检查节点上的一些设备是否符合安装 osd,2是激活,也就是 activate。这个过程在 Rook 里也同样需要。
1、安装完虚拟机后,更改名字,设置/etc/hosts文件 2、ceph-deploy工具部署
RGW的index数据以omap形式存储在OSD所在节点的leveldb中,当单个bucket存储的Object数量高达百万数量级的时候,deep-scrub和bucket list一类的操作将极大的消耗磁盘资源,导致对应OSD出现异常,如果不对bucket的index进行shard切片操作(shard切片实现了将单个bucket index的LevelDB实例水平切分到多个OSD上),数据量大了以后很容易出事。
CRUSH 算法,全称 Controlled Replication Under Scalable Hashing (可扩展哈希下的受控复制),它是一个可控的、可扩展的、分布式的副本数据放置算法, 通过CRUSH 算法来计算数据存储位置来确定如何存储和检索数据。
在服务器资源不足,或者测试环境下,Ceph 通常只有一个节点,就算有多个服务器组成集群,往往存储服务器也往往只有一台,Ceph 的默认配置下,只能设置单数据备份,也就是说数据只存了一份,如果磁盘坏了,数据就丢了。虽然测试环境数据没那么重要,总保不齐就会有关键数据放在上面,所以还是要想办法在资源有限的条件下实现数据的高可用,另外这也是一个很好的进一步理解 Ceph 概念的好机会,接下来就让我们来看看是如何实现的吧。
一个Ceph集群需要多个Monitor组成的小集群,它们通过Paxos同步数据,用来保存OSD的元数据。
CSC模块主要把输入视频桢转化成硬件支持的图像,如HSV格式,NV12,NV21,RGB32,ARGB格式的任意一种格式。
如何缓解 index shard 过大造成的影响 下面这些都是属于应急操作,属于快速止血止痛,部分操作属高危,一定要谨慎使用。 1 调整OSD的几个op超时参数 下面的几个参数只是用例,具体根据各位线上情况进行调整,但是不宜过大。 osd_op_thread_timeout = 90 #default is 15 osd_op_thread_suicide_timeout = 300 #default is 150 filestore_op_thread_timeout = 180 #d
该命令要求必须在 osd.1 , mon.node1节点上才能执行 这三种方法显示结果都是一样的,不过第三种方法的显示格式和一二种不同而已。
删除当前 osd 的所有数据,并且重新加载 osd,此操作一定要保证有冗余可用的 osd,否则会造成整个 osd 数据损坏。
领取专属 10元无门槛券
手把手带您无忧上云