回到最初的Ceph运维工程师的问题,本系列讲述的是传统运维向新一代云运维转型之软件定义存储部分的转型,运维是企业业务系统从规划、设计、实施、交付到运维的最后一个步骤,也是重要的步骤。运维小哥最初的梦想搭建一个Ceph存储集群,对接云服务,底层存储实现高可用的数据访问架构。其中运维小哥经历了硬件选型、部署、调优、测试、高可用架构设计等的一系列转型的关卡学习,终于就要到最后的应用上线了。但是往往在生产环境中除了无单点、高可用的架构设计之外还需要平时做一些预案演练,比如:服务器断电、拔磁盘等问题,避免出现灾难故障影响业务正常运行。
通过以上措施的实施,可以提高Ceph集群的安全性,保护数据免受未经授权的访问和攻击。
这个问题是作者一个集群中(ceph 0.94.5)出现了一个磁盘损坏以后造成了一些对象的丢失,然后在做了一定的处理以后,集群状态已经正常了,但是还是新的请求会出现block的状态,这个情况下如何处理才能让集群正常,作者贴出了pg dump,ceph -s,ceph osd dump相关信息,当出现异常的时候,需要人协助的时候,应该提供这些信息方便其他人定位问题,最后这个问题作者自己给出了自己的解决办法,出现的时候影响是当时的流量只有正常情况下的10%了,影响还是很大的
以上命令可以帮助管理员监控Ceph集群的健康状态、数据的存储和使用情况,以及集群中各个组件的运行情况。
Ceph 配置文件可用于配置存储集群内的所有守护进程、或者某一类型的所有守护进程。要配置一系列守护进程,这些配置必须位于能收到配置的段落之下,比如:
前一篇介绍了docker在命令行下面进行的ceph部署,本篇用docker的UI进行ceph的部署,目前来说市面上还没有一款能够比较简单就能直接在OS上面去部署Ceph的管理平台,这是因为OS的环境差异化太大,并且包的版本,以及各种软件的适配都可能造成失败,而docker比较固化环境,因此即使一个通用的UI也能很方便的部署出一个Cpeh集群
ceph里面的数据是以对象的形式存储在OSD当中的,有的时候因为磁盘的损坏或者其它的一些特殊情况,会引起集群当中的某一个对象的异常,那么我们需要对这个对象进行处理
Ceph通过自动修复机制来处理节点故障和数据损坏。当一个节点(例如OSD)出现故障时,Ceph会检测到该故障并采取相应的措施进行修复。具体的自动修复机制包括以下几个步骤:
作为一个成熟、可靠的分布式存储框架,Ceph集群中的各个组件都具备很强的自运维能力,这样的能力都是依托于 Ceph 优秀的故障检测机制。这篇文章主要分析一下集群状态的变迁。
Ceph 提供了对象存储,可作为存储引擎在 JuiceFS 中使用。这一组合非常适合云计算、大数据分析和机器学习等数据密集型应用场景。
最下面的蓝色长条可以看成一个个主机,里面的灰色圆柱形可以看成一个个OSD,紫色的cabinet可以也就是一个个机柜, 绿色的row可以看成一排机柜,顶端的root是我们的根节点,没有实际意义,你可以把它看成一个数据中心的意思,也可以看成一个机房的意思,不过只是起到了一个树状结构的根节点的作用。 CRUSH从root下的所有的row中选出一个row。 在刚刚的一个row下面的所有cabinet中,CRUSH选出三个cabinet。 在刚刚的三个cabinet下面的所有OSD中,CRUSH分别选出一个OSD。 这样做的根本意义在于,将数据平均分布在了这个集群里面的所有OSD上,同时,这样选择做到了三个OSD分布在三个不同的cabinet上。
1、停止osd systemctl stop ceph-osd@22.service 2、刷入日志 ceph-osd -i 22 –flush-journal 3、启动osd systemctl start ceph-osd@22.service 可以确认集群恢复OK
Ceph通过伙伴OSD汇报失效节点和Monitor统计来自OSD的心跳两种方式判定OSD节点失效。
与集中式存储相反,分布式存储通常采用存储单元集群的形式,并具有在集群节点之间进行数据同步和协调的机制。分布式存储最初是由Google提出的,其目的是通过廉价服务器解决大规模,高并发情况下的Web访问问题。
Ceph是一款以对象存储技术(独立存储技术)为核心,并在此基础之上实现块存储、文件系统的一体化存储系统。
本文为长篇连续剧,将分多个篇幅发表,主要介绍了从动手部署环境到后期运营故障处理过程中常见的问题,内容由浅入深,是居家旅行运维Ceph的必备良药。
存储根据其类型,可分为块存储,对象存储和文件存储。在主流的分布式存储技术中,HDFS/GPFS/GFS属于文件存储,Swift属于对象存储,而Ceph可支持块存储、对象存储和文件存储,故称为统一存储。
nearfull osd(s) or pool(s) nearfull 此时说明部分osd的存储已经超过阈值,mon会监控ceph集群中OSD空间使用情况。如果要消除WARN,可以修改这两个参数,提高阈值,但是通过实践发现并不能解决问题,可以通过观察osd的数据分布情况来分析原因。
ceph 客户端从ceph monitor获取cluster map,然后执行在pool中的pg执行IO操作。cursh ruleset和pg的数量是决定数据对象放在哪里的核心因素。获取到最新的cluster map,ceph客户端是不知道数据对象在哪里。
client 无法链接mon的可能原因 1.连通性和防火墙规则。在MON主机上修改允许TCP 端口6789的访问。 2.磁盘空间。每个MON主机上必须有超过5%的空闲磁盘空间使MON和levelDB数据库正常工作。 3.MON没有工作或者离开选举,检查如上命令输出结果中的quorum_status和mon_status或者ceph -s 的输出来确定失败的MON进程,尝试重启或者部署一个新的来替代它。
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上),数据量大了以后很容易出事。
一、概述 Ceph是一个分布式存储系统,诞生于2004年,最早致力于开发下一代高性能分布式文件系统的项目。随着云计算的发展,ceph乘上了OpenStack的春风,进而成为了开源社区受关注较高的项目之一。 Ceph有以下优势: 1. CRUSH算法 Crush算法是ceph的两大创新之一,简单来说,ceph摒弃了传统的集中式存储元数据寻址的方案,转而使用CRUSH算法完成数据的寻址操作。CRUSH在一致性哈希基础上很好的考虑了容灾域的隔离,能够实现各类负载的副本放置规则,例如跨机房、机架感知等。Crush算
Ceph 是一个可扩展的分布式存储系统,性能卓越,安全可靠。 Ceph 12.2.0 正式版已发布。这是Luminous v12.2.x长期稳定版本的第一个版本。在Kraken(v11.2.z)和 Jewel(v10.2.z)后我们做了很多重大修改,而且升级过程并不简单哦。请仔细阅读版本说明。
Ceph Monitors之间默认使用6789端口通信,OSD之间默认用6800:7300范围内的端口通信。Ceph OSD能利用多个网络连接进行与客户端、monitors、其他OSD间的复制和心跳的通信。若需要开启防火墙则必须同时放通相应规则,具体操作见:http://docs.ceph.org.cn/rados/configuration/network-config-ref/
每一个Ceph新手,都或多或少被文中提到的四大天(坑)王吊打过,或钢筋铁骨成为大神,或删库跑路沦为亡魂。因此有必要给大家早早普及一下这四大天王的手段,帮各位早脱苦海。本文建立在你已经基本了解Ceph的构架和基本原理,如果不熟悉的同学可以看下面内容
在上期,我们提到,Ceph集群使用多副本的情况下,整体读性能可达所有物理磁盘读性能的总和,但由于写入的机制为只写入主副本,然后向另外两个副本同步,因此,以三副本为例,写性能只能达到所有磁盘写性能总和的三分之一。以SATA大盘单盘,100 IOPS写性能计,6节点72大盘的总写IOPS性能只能到2400 IOPS。这是难以满足高性能数据库需求的。
作为一个面向大规模的分布式存储系统,故障处理是作为一个常态异常处理。Ceph 为了细化和保证故障发生和故障恢复的集群高可用性和一致性,在设计上将故障分为两类:
Alex,专注于云计算领域数年,目前主要从事容器云平台的建设,推进各类基础设施服务的云原生化。
如果是在admin节点修改的ceph.conf,想推送到所有其他节点,则需要执行下述命令
节点的故障检测是分布式系统无法回避的问题,集群需要感知节点的存活,并作出适当的调整。通常我们采用心跳的方式来进行故障检测,并认为能正常与外界保持心跳的节点便能够正常提供服务。一个好的故障检测策略应该能够做到:
Ceph是一个PB,EB级别的分布式存储系统,可以提供文件存储,对象存储、和块存储,它可靠性高,易扩展,管理简便,其中对象存储和块存储可以和其他云平台集成。一个Ceph集群中有Monitor节点、MDS节点(用于文件存储)、OSD守护进程。
「生产环境下部署 Kubernetes 集群」由 「运维之美」技术交流群中的群友「往事随风」编写完成,并授权公众号原创首发。
CRUSH 算法,全称 Controlled Replication Under Scalable Hashing (可扩展哈希下的受控复制),它是一个可控的、可扩展的、分布式的副本数据放置算法, 通过CRUSH 算法来计算数据存储位置来确定如何存储和检索数据。
作者:徐凯 这篇文章主要介绍了如何用三台虚拟机搭建一套Ceph分布式系统,步骤简洁但不失准确性。环境清理一小节可以解决绝大多数部署不成功的问题,最后一节介绍了常用的Ceph操作,希望能给刚搭建环境的
消息: Client name failing to respond to cache pressure
本文作者 / Wenda 关注存储以及周边生态,独立的存储系统生存太艰难,融入生态才体现价值。 1、背 景 我们Ceph作为后端存储时,这里只针对块存储空间的使用进行讨论。 对于块存储空间,Linux用户的使用方法有多种,如:rbd map方式、rbd-nbd map方式、 rbd-fuse方式, 但是对于Windows用户,如何使用呢?--- 答案:通过ISCSI访问。 2、说 明 针对块存储场景,iSCSI gateway的作用: 1) 采用ceph作为后端存储时,通过iSCSI协议为Wi
Scrub主要是为了检查磁盘数据的静默错误,在英文中被称为:Silent Data Corruption,大家都知道硬盘最核心的使命是正确的读取和写入数据,在读、写失败的情况下及时抛出异常,但是在某些场景下,写入成功,读取的时候才发现数据已经损坏,这就是静默错误,一般静默错误产生原因有这几种:
容器和ceph的结合已经在一些生产环境当中做了尝试,容器的好处就是对运行环境的一个封装,传统的方式是集成为ISO,这个需要一定的维护量,而容器的相关操作会简单很多,也就有了一些尝试,个人觉得如果玩的转容器可以考虑,当然得懂ceph,不然两套系统在一起,问题都不知道是哪个的,就比较麻烦了
Ceph项目最早起源于Sage就读博士期间的工作(最早的成果于2004年发表),并随后贡献给开源社区。在经过了数年的发展之后,目前已得到众多云计算厂商的支持并被广泛应用。RedHat及OpenStack都可与Ceph整合以支持虚拟机镜像的后端存储。
虚拟机创建三台服务器, CENTOS 版本为 7.6 , IP 网段 192.168.116.2/24 。三台主机名称为:
ceph版本12.2.8,一个PG卡在remapped状态,但是集群状态是OK的,为了修复这个remapped状态,才有了下面的操作。
要将Ceph集群与云平台(如OpenStack)集成,以提供存储服务,可以按照以下步骤进行操作:
Ceph是当前非常流行的开源分布式存储系统,具有高扩展性、高性能、高可靠性等优点,同时提供块存储服务(rbd)、对象存储服务(rgw)以及文件系统存储服务(cephfs),Ceph在存储的时候充分利用存储节点的计算能力,在存储每一个数据时都会通过计算得出该数据的位置,尽量的分布均衡。目前也是OpenStack的主流后端存储,随着OpenStack在云计算领域的广泛使用,ceph也变得更加炙手可热。国内目前使用ceph搭建分布式存储系统较为成功的企业有华为,xsky,杉岩数据,中兴,华三,浪潮,中移动等。
要学习使用Ceph,首先需要有一个Ceph集群,本文通过ceph-deploy一个自动化部署Ceph的工具部署一个Ceph集群,掌握Ceph集群部署的方法。
能否利用TStack的计算、网络和存储能力,将Oracle运行在X86服务器,IP网络,云存储的“云化”架构上,去掉IOE架构中的I和E呢?
对每个人而言,真正的职责只有一个:找到自我。然后在心中坚守其一生,全心全意,永不停息。所有其它的路都是不完整的,是人的逃避方式,是对大众理想的懦弱回归,是随波逐流,是对内心的恐惧 ——赫尔曼·黑塞《德米安》
在极端情况下,如数据中心断电,造成 Ceph 存储集群全局宕机,可以按照本节所示流程进行 Ceph 集群上电恢复操作。
领取专属 10元无门槛券
手把手带您无忧上云