Planet Ceph

Aggregated news from external sources

  • August 10, 2017
    如何测量Ceph OSD内存占用

    前言 这个工具我第一次看到是在填坑群里面看到,是由研发-北京-蓝星同学分享的,看到比较有趣,就写一篇相关的记录下用法 火焰图里面也可以定位内存方面的问题,那个是通过一段时间的统计,以一个汇总的方式来查看内存在哪个地方可能出了问题本篇是另外一个工具,这个工具的好处是有很清晰的图表操作,以及基于时间线的统计,下面来看下这个工具怎么使用的 本篇对具体的内存函数的调用占用不会做更具体的分析,这里是提供一个工具的使用方法供感兴趣的研发同学来使用 环境准备 目前大多数的ceph运行在centos7系列上面,笔者的环境也是在centos7上面,所以以这个举例,其他平台同样可以 需要用到的工具 valgrind massif-visualizer 安装valgrind yum install valgrind massif-visualizer是数据可视化的工具,由于并没有centos的发行版本,但是有fedora的版本,从网上看到资料说这个可以直接安装忽略掉需要的依赖即可,我自己跑了下,确实可行 下载massif-visualizer wget ftp://ftp.pbone.net/mirror/download.fedora.redhat.com/pub/fedora/linux/releases/23/Everything/x86_64/os/Packages/m/massif-visualizer-0.4.0-6.fc23.x86_64.rpm 安装massif-visualizer rpm -ivh massif-visualizer-0.4.0-6.fc23.x86_64.rpm –nodeps 不要漏了后面的nodeps 抓取ceph osd运行时内存数据 停掉需要监控的osd(例如我的是osd.4) [root@lab8106 ~]# systemctl stop ceph-osd@4 开始运行监控 [root@lab8106 ~]# valgrind –tool=massif /usr/bin/ceph-osd -f –cluster ceph –id 4 –setuser ceph –setgroup ceph==21522== Massif, a heap profiler==21522== Copyright (C) 2003-2015, and GNU …Read more

  • August 10, 2017
    Ceph recover的速度控制

    前言 磁盘损坏对于一个大集群来说,可以说是必然发生的事情,即使再小的概率,磁盘量上去,总会坏那么几块盘,这个时候就会触发内部的修复过程,修复就是让不满足副本要求的PG,恢复到满足的情况一般是踢掉坏盘和增加新盘会触发这个修复过程,或者对磁盘的权重做了修改,也会触发这个迁移的过程,本篇是用剔除OSD的方式来对这个修复的控制做一个探索 大部分场景下要求的是不能影响前端的业务,而加速迁移,忽略迁移影响不在本篇的讨论范围内,本篇将用数据来说明迁移的控制 本次测试在无读写情况下进程的 几个需要用到脚本和命令 磁盘本身的大概速度 [root@lab8106 ~]# ceph tell osd.0 bench{ “bytes_written”: 1073741824, “blocksize”: 4194304, “bytes_per_sec”: 102781897} 得到的结果为102MB/s 获取osd上pg迁移的对象的脚本 OSD的日志需要开启到10,这里采取动态开启的方式 ceph daemon osd.0 config set debug_osd 10 日志解析的脚本 cat /var/log/ceph/ceph-osd.0.log | awk ‘$7==”finish_recovery_op”&&$8==”pg[0.15(” {sub(/.*/,substr($2,1,8),$2); print $0}’|awk ‘{a[$1,” “,$2]++}END{for (j in a) print j,a[j]|”sort -k 1″}’ 获取osd.0上的pg0.15的迁移速度运行后的效果如下: 2017-08-08 17:14:33 12017-08-08 17:14:34 22017-08-08 17:14:35 22017-08-08 17:14:36 …Read more

  • August 9, 2017
    Ceph S3 基于NGINX的集群复制方案

    前言 ceph的s3数据的同步可以通过radosgw-agent进行同步,同region可以同步data和metadata,不同region只能同步metadata,这个地方可以参考下秦牧羊梳理的 ceph radosgw 多集群同步部署流程,本篇讲述的方案与radosgw-agent的复制方案不同在于,这个属于前端复制,后端相当于透明的两个相同集群,在入口层面就将数据进行了复制分流在某些场景下,需求可能比较简单: 需要数据能同时存储在两个集群当中 数据写一次,读多次 两个集群都能写 一方面两个集群可以增加数据的可靠性,另一方面可以提高读带宽,两个集群同时可以提供读的服务 radosgw-agent是从底层做的同步,正好看到秦牧羊有提到nginx新加入了ngx_http_mirror_module 这个模块,那么本篇就尝试用这个模块来做几个简单的配置来实现上面的需求,这里纯架构的尝试,真正上生产还需要做大量的验证和修改的测试的 结构设想 当数据传到nginx的server的时候,nginx本地进行负载均衡到两个本地端口上面,本地的两个端口对应到两个集群上面,一个主写集群1,一个主写集群2,这个是最简结构,集群的civetweb可以是很多机器,nginx这个也可以是多台的机器,在一台上面之所以做个均衡是可以让两个集群是对等关系,而不是一个只用nginx写,另一个只mirror写 环境准备 准备两个完全独立的集群,分别配置一个s3的网关,我的环境为: 192.168.19.101:8080192.168.19.102:8080 在每个机器上都创建一个管理员的账号,这个用于后面的通过restapi来进行管理的,其他的后面的操作都通过http来做能保证两个集群的数据是一致的 nginx的机器在192.168.19.104 在两个集群当中都创建相同的管理用户 radosgw-admin user create –uid=admin –display-name=admin –access_key=admin –secret=123456 这里为了测试方便使用了简单密码 此时admin还仅仅是普通的权限,需要通过—cap添加user的capabilities,例如: radosgw-admin caps add –uid=admin –caps=”users=read, write”radosgw-admin caps add –uid=admin –caps=”usage=read, write” 下面就用到了nginx的最新的模块了Nginx 1.13.4 发布,新增 ngx_http_mirror_module 模块 软件下载: wget https://nginx.org/packages/mainline/centos/7/x86_64/RPMS/nginx-1.13.4-1.el7.ngx.x86_64.rpm 下载rpm包然后安装安装: rpm -ivh nginx-1.13.4-1.el7.ngx.x86_64.rpm 修改nginx配置文件: upstream s3 { …Read more

  • August 7, 2017
    cephfs: ideal PG ratio between metadata and data pools

    Scenario: I’m deploying CephFS for the first time. I know I need a metadata pool as well as a data pool, but I don’t know how many PGs for one pool and the other? Can I use the same number, or should they be different? This question is a FAQ. The number of PGs should …Read more

  • August 7, 2017
    What is the optimum number of PGs for my pool?

    Each pool has a fixed number of Placement Groups (PGs) *and* a fixed number ofOSDs. The former is set when the pool is created and the latter is determinedby the CRUSH map. The number of PGs in a pool can be increased, but it cannot easily be decreased(there is always the option to create a …Read more

  • August 4, 2017
    openATTIC 3.4.2 has been released

    We are very happy to announce the release of openATTIC version 3.4.2. In this release, we’ve continued with the integration of Ceph Luminous features. It is now possible to configure the Ceph keyring via the ‘System | Settings’ menu. This release also implements the WebUI part of the previously introduced backend feature to create erasure …Read more

  • August 2, 2017
    More recommendations for Ceph and OpenStack

    A few months ago, we shared our Dos and Don’ts, as they relate to Ceph and OpenStack. Since that post has proved quite popular, here are a few additional considerations for your Ceph-backed OpenStack cluster. Do configure your images for VirtIO-SCSI By default, RBD-backed Nova instances use the virtio-blk driver to expose RBD images to …Read more

  • July 28, 2017
    How Many Mouvement When I Add a Replica ?

    Make a simple simulation ! Use your own crushmap : $ ceph osd getcrushmap -o crushmap got crush map from osdmap epoch 28673 Or create a sample clushmap : $ crushtool –outfn crushmap –build –num_osds 36 host straw 12 root straw 0 2017-07-28 15:01:16.240974 7f4dda123760 1 ID WEIGHT TYPE NAME -4 36.00000 root root -1 …Read more

  • July 27, 2017
    RBD快速删除的方法分析与改进

    前言 这个问题在很久以前就有一篇文章进行过讨论 remove-big-rbd,这个文章写的比较清楚了,并且对不同的方法做了分析,这里先把结论说下 rbd类型 rbd rm 方法 rados -p rm方法 未填充很多 慢 快 已填充很多 快 慢 在rbd进行删除的时候,即使内部没有对象数据,也一样需要一个个对象去发请求,即使对象不存在,这个可以开日志看到 实验过程 开启日志的方法 在/etc/ceph/ceph.conf中添加 [client]debug_ms=1log_file=/var/log/ceph/rados.log 然后执行操作后,去分析每秒钟的操作数目即可,类似下面的这个,也可以用日志系统进行分析,这里不赘述 cat /var/log/ceph/rados.log|grep delete|grep -v “>”|grep 13:29:46|wc -l 原始的快速删除方法 rados -p rbd ls | grep ‘^rbd_data.25ae86b8b4567’ | xargs -n 200 rados -p rbd rm 开启多进程删除的方法 这个比上面那种方法好的是: 可以显示当前删除的进度 可以指定删除的进程并发数 可以显示当时正在删除的对象 可以增加一个中断时间降低负载 首先获取一个需要快速删除的rbd的列表获取prifix [root@lab8106 put]# rbd …Read more

  • July 22, 2017
    从ceph对象中提取RBD中的指定文件

    前言 之前有个想法,是不是有办法找到rbd中的文件与对象的关系,想了很久但是一直觉得文件系统比较复杂,在fs 层的东西对ceph来说是透明的,并且对象大小是4M,而文件很小,可能在fs层进行了合并,应该很难找到对应关系,最近看到小胖有提出这个问题,那么就再次尝试了,现在就是把这个实现方法记录下来这个提取的作用个人觉得最大的好处就是一个rbd设备,在文件系统层被破坏以后,还能够从rbd提取出文件,我们知道很多情况下设备的文件系统一旦破坏,无法挂载,数据也就无法读取,而如果能从rbd中提取出文件,这就是保证了即使文件系统损坏的情况下,数据至少不丢失 本篇是基于xfs文件系统情况下的提取,其他文件系统有时间再看看,因为目前使用的比较多的就是xfs文件系统 本篇也回答了一个可能会经常被问起的问题,能告诉我虚拟机里面的文件在后台存储在哪里么,看完本篇就知道存储在哪里了 XFS文件系统介绍 [root@lab8106 ~]# mkfs.xfs -f /dev/rbd0p1 warning: device is not properly aligned /dev/rbd0p1meta-data=/dev/rbd0p1 isize=256 agcount=9, agsize=162816 blks = sectsz=512 attr=2, projid32bit=1 = crc=0 finobt=0data = bsize=4096 blocks=1310475, imaxpct=25 = sunit=1024 swidth=1024 blksnaming =version 2 bsize=4096 ascii-ci=0 ftype=0log =internal log bsize=4096 blocks=2560, version=2 = sectsz=512 sunit=8 blks, lazy-count=1realtime =none extsz=4096 blocks=0, …Read more

  • July 18, 2017
    利用火焰图分析ceph pg分布

    前言 性能优化大神Brendan Gregg发明了火焰图来定位性能问题,通过图表就可以发现问题出在哪里,通过svg矢量图来查看性能卡在哪个点,哪个操作占用的资源最多在查看了原始数据后,这个分析的原理是按层级来对调用进行一个计数,然后以层级去做比对,来看横向的占用的比例情况 基于这个原理,把osd tree的数据和pg数据可以做一个层级的组合,从而可以很方便的看出pg的分布情况,主机的分布情况,还可以进行搜索,在一个简单的图表内汇聚了大量的信息 实践 获取需要的数据,这个获取数据是我用一个脚本解析的osd tree 和pg dump,然后按照需要的格式进行输出 default;lab8106;osd.2;0.0 6default;lab8106;osd.3;0.0 6default;rack1;lab8107;osd.0;0.0 6 需要的格式是这个样的,最后一个为权重,使用的是对象数,因为对象数可能为0,所以默认在每个数值进行了加一的操作,前面就是osd的分布的位置 脚本/sbin/stackcollapse-crush内容如下: #! /bin/python# -*- coding: UTF-8 -*-import osimport commandsimport jsondef main(): global list_all_host list_all_host = commands.getoutput(‘ceph osd tree -f json-pretty 2>/dev/null’) getosd(‘osd.1’) getpgmap()def getosd(osd): mylist=[] crushid={} json_str = json.loads(list_all_host) for item in json_str[‘nodes’]: if item.has_key(‘children’): crushid[str(item[‘id’])]=str(item[‘name’]) for child in item[‘children’]: …Read more

  • July 12, 2017
    Cephfs 操作输出到日志查询系统

    前言 文件系统当中如果某些文件不见了,有什么办法判断是删除了还是自己不见了,这个就需要去日志里面定位了,通常情况下是去翻日志,而日志是会进行压缩的,并且查找起来非常的不方便,还有可能并没有开启这个时候就需要日志系统了,最近正好看到一篇最佳日志实践(v2.0),一篇非常好的文章,本篇日志属于文章里面所提到的统计日志,统计客户端做了什么操作 对于日志系统来说,很重要的一点,能够很方便的进行查询,这就需要对日志信息进行一些处理了,怎么处理就是设计问题,要求就是不多不少 结构 其中graylog配置部分在这篇使用日志系统graylog获取Ceph集群状态,根据这篇的操作,配置出12201的udp监听端口即可,剩余部分就是本篇中的配置 配置 集群的配置 需要对MDS的配置进行debug_ms=1,在/etc/ceph/ceph.conf当中添加下面配置 [mds.lab8106]debug_ms=1hostname=lab8106 这个地方集群的文件操作日志是记录在message里面的1级别的,所以把mds的debug_ms开到1日志长这个样子: 2017-07-13 11:26:23.703624 7fc3128c3700 1 — 192.168.8.106:6804/3280969928 <== client.14180 192.168.8.106:0/1092795882 2384 ==== client_request(client.14180:2346 mkdir #1/ppop 2017-07-13 11:26:23.702532 caller_uid=0, caller_gid=0{}) v2 ==== 170+0+0 (843685338 0 0) 0x5645ec243600 con 0x5645ec247000 下面会对这个日志进行提取 下载logstash https://artifacts.elastic.co/downloads/logstash/logstash-5.5.0.rpm [root@lab8106 ~]# rpm -ivh logstash-5.5.0.rpm 修改启动进程为root权限修改/etc/systemd/system/logstash.service文件当中的 User=rootGroup=root 因为logstash需要本地文件的读取权限,这里是为了方便直接给的root权限,方便使用,如果对权限要求比较严的环境,就给文件 创建一个配置文件 vim /etc/logstash/conf.d/logstash.conf 添加下面的配置文件,这个配置文件包含的内容比较多,会在后面详细的介绍下处理过程 input { file …Read more

Careers