对每个人而言,真正的职责只有一个:找到自我。然后在心中坚守其一生,全心全意,永不停息。所有其它的路都是不完整的,是人的逃避方式,是对大众理想的懦弱回归,是随波逐流,是对内心的恐惧 ——赫尔曼·黑塞《德米安》
[root@node1 ~]# ceph --admin-daemon /var/run/ceph/ceph-osd.21.asok config show | less
一个RGW环境的更新,ceph 12.2.12升级到14.2.4流程,跳过中间的13版本。 注意:升级很危险,操作需谨慎。升级没有后悔药,本人不承担任何因升级及相关操作导致的任何数据丢失风险。
[root@node1 ~]# ceph daemon mon.node1 config show | more {
前段时间看到豪迈的公众号上提到了这个离线转换工具,最近看到群里有人问,找了下没什么相关文档,就自己写了一个,供参考
添加osd 案例1 由于Luminous里默认使用Bluestore,可以直接操作裸盘,data和block-db会使用lv。综合成本及性能,我们把block.db使用ssd的分区,osd仍然使用sas,block.wal不指定. 这里vdb作为osd盘,vdc作为block-db盘
整个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自启动的相关排错问题。
前段时间匆匆地为老PVE(Proxmox Virtual Environment)集群的CEPH增加了SSD,之后匆匆地简单对比记下了写了那篇“使用SSD增强Ceph性能的比较测试”,之后才反应过来——操作步骤和过程没写。这里补上。
ceph 客户端从ceph monitor获取cluster map,然后执行在pool中的pg执行IO操作。cursh ruleset和pg的数量是决定数据对象放在哪里的核心因素。获取到最新的cluster map,ceph客户端是不知道数据对象在哪里。
本文作者 / spikehe(何诚) 爱好acg,小甲师兄的首席大弟子~ 在大佬中夹缝求生的实习boy 最近跟着小甲师兄优化Ceph块存储缓存,涉及IO映射和磁盘空间分配,想到Ceph Bluestore就是绕过标准文件系统,直接对裸盘空间进行管理的,因此学习了一下以做参考,同时结合源码对Bluestore整体做一个了解。 Ceph存储引擎简介 Ceph整体的存储层框架可以从图1中看到, IO请求在RBD等客户端发出,在Message层统一解析后会被OSD层分发到各个PG,每个PG都拥有一个队列,线
Ceph 是一个可扩展的分布式存储系统,性能卓越,安全可靠。 Ceph 12.2.0 正式版已发布。这是Luminous v12.2.x长期稳定版本的第一个版本。在Kraken(v11.2.z)和 Jewel(v10.2.z)后我们做了很多重大修改,而且升级过程并不简单哦。请仔细阅读版本说明。
了解Ceph的人都知道,RADOS是整个Ceph的基础,也是整个Ceph的核心,但越是核心,越难掌握,想想看,单单RADOS的代码就有将近20W行之多,不经历好几年的摸爬滚打,怕是难以掌握其中的来龙去脉。
手动在目录/var/lib/ceph/bootstrap-osd/下新建删除文件正常,把ceph服务都重启了一遍还是这样。
集群误操作,停掉了所有OSD服务,同时关闭了自启动,尝试”systemctl start ceph-osd@10“发现日志出现下面的报错
转而使用BlueStore。BlueStore是Ceph最新的存储引擎,运行在用户态并且完全控制IO,取得了极大性能提升。
线上发现L版本一个OSD down,不确定是否磁盘故障,之前的filestore排查起来比较熟,换成Bluestore以后,有些细节上的操作不一样,因为用到的是SSD,所以有了这篇排查文档。
一、相关依赖包安装 1. 安装依赖包 yum install libtool gcc gcc-c++ libuuid-devel keyutils-libs-devel libblkid-devel redhat-lsb libedit-* yum install libatomic_ops-devel snappy-devel leveldb-devel libudev-devel cryptopp-* fuse-devellibaio-devel xfsprogs-de
Ceph基本功能 Ceph提供对象存储/块存储/文件存储的功能。一个Ceph就请你中至少包括Ceph Monitor、Ceph Manager、Ceph OSD,如果不熟了CephFS也需要一个MetaData Server组件。Ceph是以在Pool中存储数据对象的形式存储数据,首先ceph把应用端的文件先切若干个分ceph配置的标准对象大小的数据对象,然后针对这些数据对象进行哈希计算找到每个对象应该存储的PG,然后通过CRUSH算法和PG信息获取一组健康的OSD(一组OSD的数量和多副本或者纠删码相关)
1、BlueStore:事务型的本地日志文件系统 2、磁盘块大小:普通磁盘 512字节;SSD磁盘:4KB 3、COW:写时复制 RMW: 4、读写锁
Ceph项目是加州大学圣克鲁兹分校的 Weil于2006年开发的。当时他发现元数据的查询和维护严重影响了 Lustre等分布式文件系统的性能和扩展性,因此设计了一种利用算法来确定数据与存储节点对应关系的方法 CRUSH。2015年5月发布的 Linux内核2.6.34已开始支持Ceph。Weil也成立了IntTank公司,专注于Ceph的开发。2014年5月,该公司被 RedHat收购。Ceph同时支持3种存储访问接口,因此被广泛应用于开源私有云计算平台中,为云计算平台提供虚拟机存储和对象访问能力。
本文主要介绍ceph16版本集群节点系统磁盘故障后的集群恢复,虽然系统盘很多都是做了raid1,但从实际做的项目看,总是有很多未知意外发生,节点挂掉后,上面的mon和osd,mgr都会down掉,如果所在节点的mgr服务是激活状态,则其他节点所在的备用节点将会升级为激活状态。
如果是在admin节点修改的ceph.conf,想推送到所有其他节点,则需要执行下述命令
[TOC] 0x00 前言简述 CEPH 简介 Q: 什么是CEPH? 答: Ceph是一个统一的分布式存储系统,设计初衷是提供较好的性能、可靠性和可扩展性。 Ceph 项目最早起源于Sage就读博士
软件定义存储(SDS)是一个软件层,在物理存储设备和数据请求之间提供个抽象层,实现存储虚拟化功能,将底层存储设备和服务器汇集到虚拟存储空间中。这些虚拟空间通过各种冗余方式,提供恢复能力和容错能力。软件定义存储解决方案可以按照业务或基础设施的发展速度进行扩展,使用通用硬件,基于分布式环境构建存储。
今天来聊一聊Ceph新版本功能,Ceph会在今年秋季发布一个长期支持稳定版本Luminous(12.x.x),现在已经出RC版了,Luminous版本新增了很多功能,比如新增一个内置的Dashboard、底层的存储引擎的变更、消息方式的改变等等。
继上次分享的《Ceph介绍及原理架构分享》,这次主要来分享Ceph中的PG各种状态详解,PG是最复杂和难于理解的概念之一,PG的复杂如下:
ceph升级到bluestore后,df命令不能直接显示osd id与磁盘/dev/sdN的对应关系了,如:
L版本开始极大的降低了对运维操作复杂度,新增了很多命令去确保数据安全,很多新手在删除OSD的时候很容易忽视了集群PGs的状态最终导致数据丢失,因此官方加入以下几个命令
Ceph 是一个分布式的开源存储系统,由贝尔实验室的德雷克·昆伯斯(Sage A. Weil)在2004年创立。在它的发展历程中,Ceph 经历了多个关键的里程碑和版本演变。
ceph luminous版本新增加了很多有意思的功能,这个也是一个长期支持版本,所以这些新功能的特性还是很值得期待的,从底层的存储改造,消息方式的改变,以及一些之前未实现的功能的完成,都让ceph变得更强,这里面有很多核心模块来自中国的开发者,在这里准备用一系列的文章对这些新功能进行一个简单的介绍,也是自己的一个学习的过程
Ceph使用RADOS提供对象存储,通过librados封装库提供多种存储方式的文件和对象转换。外层通过RGW(Object,有原生的API,而且也兼容Swift和S3的API,适合单客户端使用)、RBD(Block,支持精简配置、快照、克隆,适合多客户端有目录结构)、CephFS(File,Posix接口,支持快照,社会和更新变动少的数据,没有目录结构不能直接打开)将数据写入存储。
Ceph是专为在商品硬件上运行而设计的,这使得构建和维护超大规模的数据集群在经济上是可行的。当规划出你的集群硬件时,你需要平衡一些考虑因素,包括故障域和潜在的性能问题。硬件规划应该包括将Ceph守护进程和其他使用Ceph的进程分布在许多主机上。一般来说,我们 建议在为该类型的守护进程配置的主机上运行特定的Ceph守护进程。我们建议使用其他主机来处理使用您的数据集群的进程(例如OpenStack、CloudStack)
现在是不是很无聊?因为的注意到了咱们公众号每天关注的人数数据逐渐回升。大过年的不把你们逼到一定份上应该不会主动学习的吧!
RADOS: Reliable, Autonomic Distributed Object Store
Ceph是一种高度可扩展的分布式存储解决方案,提供对象、文件和块存储。在每个存储节点上,将找到Ceph存储对象的文件系统和Ceph OSD(对象存储守护程序)进程。在Ceph集群上,还存在Ceph MON(监控)守护程序,它们确保Ceph集群保持高可用性。
之前用的是 ceph-deploy 部署 ceph 集群,在官网的最新介绍中有如下描述:
ceph osd df - 可以查看每个osd的用量,每个osd的pg数,权重 ceph osd find <int> - 可以查找到osd的位置,在osd比较多时用到 ceph osd perf - 可以查看所有osd提交及应用提交的延时,对监控osd的健康状态极有帮助 ceph osd scrub <int> - 指定osd进行清洗,注意到,清洗是为了检查osd缺陷和文件系统错误,正确的清洗策略很重要 ceph quorum_status - 报告集群当前法定人数情况,若集群因mon跪了导致故障可由此排查 ceph report - 报告集群当前的全部状态,输出信息非常详细,排查没有头绪时可以试试这个 radosgw-admin bucket limit check - 查看bucket的配置信息,例如索引分片值 ceph daemon osd.1 config show - 显示指定的osd的所有配置情况 ceph tell 'osd.*' injectargs '--osd_max_backfills 64' - 立即为osd设置参数,不需要重启进程即生效 ceph daemon /var/run/ceph/ceph-client.rgw.hostname -s.asok config show - 查看指定的asok的配置 ceph-bluestore-tool bluefs-export --path /var/lib/ceph/osd/ceph-1 --out-dir /home/xx - 导出指定osd的整个rocksdb ceph-kvstore-tool rocksdb /home/xx/db/ list - 查看rocksdb里面的记录 ceph tell osd.* heap release - 通知所有osd释放那些可以释放的内存 ceph daemon osd.x dump_historic_ops - 调查指定osd的op处理情况,诊断延时的瓶颈 ceph daemon osd.x dump_ops_in_flight - 调查指定osd的性能问题
2019年4月18日至20日,第九届中国开源黑客松活动在深圳鹏城实验室举办,这是一场持续3日,集结多位社区专家的技术分享大会。
Ceph自动化部署工具现状 ceph-deploy 已经处于被淘汰边缘(官方现在主推ceph-ansible),deploy新手练手可以,配置管理太弱鸡,每次overwrite-conf都需要很大勇气。 ceph-ansible 看起来很美好,但是无法完美适配手头各种差异化的部署需求,看完源码,把里面核心的模块功能抽取出来,完全可以自己做,没必要拿官方的ansible。 ceph-deploy其实也是通过ssh去控制各个节点的ceph-disk命令工具执行,但是ceph-disk又被官方弃坑,最新版本推荐使
问题背景 集群中剔除了一个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 ~]#
在k8s上编排ceph是容器生态存储方案的一个趋势,能非常简单快速的构建出存储集群,特别适合供有状态服务使用,计算存储分离将使应用的管理变简单,业务层与云操作系统层也能更好的解耦。
安全是整个存储必不可少的一环,但是很少有人能够比较全面的总结一下Ceph的安全体系,于是老司机在这里“鬼话连篇”。
Ceph是当前非常流行的开源分布式存储系统,具有高扩展性、高性能、高可靠性等优点,同时提供块存储服务(rbd)、对象存储服务(rgw)以及文件系统存储服务(cephfs),Ceph在存储的时候充分利用存储节点的计算能力,在存储每一个数据时都会通过计算得出该数据的位置,尽量的分布均衡。目前也是OpenStack的主流后端存储,随着OpenStack在云计算领域的广泛使用,ceph也变得更加炙手可热。国内目前使用ceph搭建分布式存储系统较为成功的企业有华为,xsky,杉岩数据,中兴,华三,浪潮,中移动等。
我们经常会说:容器和 Pod 是短暂的。其含义是它们的生命周期可能很短,会被频繁地销毁和创建。容器销毁时,保存在容器内部文件系统中的数据都会被清除。为了持久化保存容器的数据,可以使用存储插件在容器里挂载一个基于网络或者其他机制的远程数据卷,使得在容器里创建的文件,实际上是保存在远程存储服务器上,或者以分布式的方式保存在多个节点上,而与当前宿主机没有绑定关系。这样,无论在哪个节点上启动新的容器,都可以请求挂载指定的持久化存储卷。
Ceph亚太峰会RGW部分议题分享 本次Ceph亚太峰会干货最实在的的要数Redhat的《Common Support Issues and How to Troubleshoot Them》这里把RGW部分摘出来,和大家分享一下,本次议题主要是涉及到RGW中Object数量过多导致的OSD异常如何处理。 故障现象描述 Flapping OSD's when RGW buckets have millions of objects ● Possible causes ○ The first issue h
RGW的index数据以omap形式存储在OSD所在节点的leveldb中,当单个bucket存储的Object数量高达百万数量级的时候,deep-scrub和bucket list一类的操作将极大的消耗磁盘资源,导致对应OSD出现异常,如果不对bucket的index进行shard切片操作(shard切片实现了将单个bucket index的LevelDB实例水平切分到多个OSD上),数据量大了以后很容易出事。
Cephadm使用容器和systemd安装和管理Ceph集群,并与CLI和仪表板GUI紧密集成。
Rook 是基于 Kubernetes 之上构建的存储服务框架。它支持 Ceph、NFS 等多种底层存储的创建和管理。帮助系统管理员自动化维护存储的整个生命周期。存储的整个生命周期包括部署、启动、配置、申请、扩展、升级、迁移、灾难恢复、监控和资源管理等,看着就让笔者觉得事情不少,Rook 的目标就是降低运维的难度,让 Kubernetes 和 Rook 来帮你托管解决这些任务。
云知声是一家专注于语音及语言处理的技术公司。Atlas 超级计算平台是云知声的计算底层基础架构,为云知声在 AI 各个领域(如语音、自然语言处理、视觉等)的模型迭代提供训练加速等基础计算能力。Atlas 平台深度学习算力超过 57 PFLOPS(5.7 亿亿次/秒,是的你没有看错,是亿亿次]
领取专属 10元无门槛券
手把手带您无忧上云