前言之前看过一个朋友一篇文章，讲述的是Vsan为什么使用的是两副本，而ceph则大多数情况下需要三副本，当时个人观点是这个并不是关键点，但是在仔细考虑了问题的出发点以后，这个也可以说是其中的一个点 一个集群数据丢失可以从多方面去看 发生丢失数据的事件，这个来说，出现这个事件的概率是一致的，同等硬件情况下没有谁的系统能够说在两副本情况下把这个出现坏盘概率做的比其他系统更低 发生坏盘事件以后，数据丢失波及的范围，这个就是那个朋友提出的一个观点，对于Vsan来说因为文件的不拆分，也就是在丢了的情况下，只是局部数据的丢失，而ceph的数据因为拆分到整个集群，基本上说就是全军覆没了，这一点没有什么争议 一般来说，ceph都是配置的分布式文件系统，也就是数据以PG为组合，以对象为最小单元的形式分布到整个集群当中去，通过控制crush能够增加一定的可用概率，但是有没有办法实现真的丢盘的情况下，数据波及没有那么广，答案当然是有的，只是需要做一些更细微的控制，前端的使用的接口也需要做一定的改动，本篇将讲述这个如何去实现，以及前端可能需要的变动 方案实现首先来一张示意图，来介绍大致的实现方式，下面再给 ...

前言前一篇介绍了docker在命令行下面进行的ceph部署，本篇用docker的UI进行ceph的部署，目前来说市面上还没有一款能够比较简单就能直接在OS上面去部署Ceph的管理平台，这是因为OS的环境差异化太大，并且包的版本，以及各种软件的适配都可能造成失败，而docker比较固化环境，因此即使一个通用的UI也能很方便的部署出一个Cpeh集群 本篇就是对Docker UI部署集群做一个实践，对ceph了解，对docker了解，对dokcer的UI操作进行一定的了解的情况下，再做实践会比较好，总体上还是比较简单的 安装并运行portainer安装软件1234cd /optwget https://github.com/portainer/portainer/releases/download/1.12.1/portainer-1.12.1-linux-amd64.tar.gztar xvpfz portainer-1.12.1-linux-amd64.tar.gzcd portainer 运行软件1./portainer -H unix:///var/run/docker.sock ...

前言容器和ceph的结合已经在一些生产环境当中做了尝试，容器的好处就是对运行环境的一个封装，传统的方式是集成为ISO，这个需要一定的维护量，而容器的相关操作会简单很多，也就有了一些尝试，个人觉得如果玩的转容器可以考虑，当然得懂ceph，不然两套系统在一起，问题都不知道是哪个的，就比较麻烦了 本篇是基于之前我的填坑群里面的牛鹏举的一个问题，他的环境出现了创建osd的时候权限问题，我这边没遇到，现在实践了一遍，感觉应该是之前目录提前创建了的问题 实践步骤安装docker1yum install docker 下载ceph镜像这个镜像是sebastien维护的，他是redhat的ceph工程师，ceph-ansible的负责人,很多一线的资料都是来自他的分享，这个是一个集成好的镜像 1docker pull ceph/daemon 准备好一些目录 12mkdir -p /etc/cephmkdir -p /var/lib/ceph/ 注意只需要做这个两个目录，不要创建子目录，docker内部有相关的操作 创建一个mon123456sudo docker run -d --net=host ...

前言系统中有些地方会进行资源的限制，其中的一个就是open file的限制，操作系统默认限制的是1024,这个值可以通过各种方式修改，本篇主要讲的是如何在线修改，生产上是不可能随便重启进程的 实践查看系统默认的限制12[root@lab8106 ~]# ulimit -a|grep openopen files (-n) 1024 默认的打开文件是1024 12345[root@lab8106 ~]# ps -ef|grep ceph-osdceph 28176 1 0 18:08 ? 00:00:00 /usr/bin/ceph-osd -f --cluster ceph --id 0 --setuser ceph --setgroup cephroot 28619 26901 0 18:10 pts/3 00:00:00 grep --color=auto ceph-osd[root@lab8106 ~]# cat /proc/28176/limits |grep openMax open f ...

前言我们以前的管理平台在python平台下面做的，内部做的一些操作采用的是命令执行，然后解析的方式去做的，ceph自身有python的rados接口，可以直接调用原生接口，然后直接解析json的方式，这样更靠近底层 在看ceph-dash内部的实现的时候，发现里面的获取集群信息的代码可以留存备用 代码实例123456789101112131415161718192021222324#!/usr/bin/env python# -*- coding: UTF-8 -*-import jsonfrom rados import Radosfrom rados import Error as RadosErrorclass CephClusterCommand(dict): """ Issue a ceph command on the given cluster and provide the returned json """ def __init__(self, cluster, **kwargs): ...

前言所谓吃一堑长一智，每次面对问题才是最好的学习机会，在面对问题的时候，尽量是能够自己去解决，或者去尝试能够最接近答案，确实无法解决再去寻求他人帮助，这样成长的会更快一些，在学校读书做题的时候，老师也是经常告诉我们要忍住，不要去直接翻答案，在当今的互联网飞速的发展下，在google的帮助下，基本上90%的问题都能找到正确的答案，而我们其实真正需要锻炼的是实践能力和甄别的能力 去年一年给不少的生产环境解决过问题，在相互交流几次以后，解决问题的过程，基本也熟悉了，一般解决问题的大致流程都是： 告之我环境的当前状况，需要实现的情况 准备好远程的环境 告之对方可能出现的情况，是否可操作，然后解决问题 交流问题的出现原因以及解决的办法 目前来看，基本都解决了，对于我来说是一次处理故障经验的累积，对对方来说是环境的恢复，以及下次在出现相同故障的时候，自己能够处理好类似问题 本次恢复对于我来说也是刷新了的认识，进展只到了解决问题的地方，就结束了，那么我就记录下这次解决问题当中的收获 处理过程故障的发生应该是在一次掉电后触发的,整个集群在重新启动以后，出现了多块磁盘故障的问题，也有主机无法启动的情 ...

引言我们在进行 ceph 的 osd 的增加和减少的维护的时候，会碰到迁移数据，但是我们平时会怎么去回答关于迁移数据量的问题，一般来说，都是说很多，或者说根据环境来看，有没有精确的一个说法，到底要迁移多少数据?这个我以前也有思考过这个问题，当时想是对比前后的pg的分布，然后进行计算，正好在翻一些资料的时候，看到有alram写的一篇博客，alram是Inktank的程序员，也就是sage所在的公司，程序是一个python脚本，本篇会分析下这个对比的思路，以及运行效果 计算迁移量只需要一个修改后的crushmap就可以了，这个是离线计算的，所以不会对集群有什么影响 运行效果准备修改后的crushmap获取当前crushmap 1ceph osd getcrushmap -o crushmap 解码crushmap 1crushtool -d crushmap -o crushmap.txt 修改crushmap.txt这个根据自己需要，修改成自己想修改成的crushmap即可，可以是增加，也可以是删除 减少节点的计算假如删除一个osd.5 我们需要迁移多少数据将crushmap里面的osd ...

前言如果你有订阅一些科技新闻，应该会有看过内核在4.9当中加入了一个新的算法，来解决在有一定的丢包率的情况下的带宽稳定的问题，这个是谷歌为我们带来的干货，新的 TCP 拥塞控制算法 BBR (Bottleneck Bandwidth and RTT)，谷歌一向的做法是，先上生产，然后发论文，然后有可能开源，所以这个已经合并到了内核4.9分支当中，算法带来的改变在出的测试报告当中有很详细的数据展示，这个看多了可能反而不知道到底会有什么明显改变，特别是对于我们自己的场景 那么本篇就是来做一个实践的，开看看在通用的一些场景下，这个改变有多大，先说下结果，是真的非常大 实践还是我的两台机器lab8106和lab8107,lab8106做一个webserver，lab8107模拟客户端，用简单的wget来进行测试，环境为同一个交换机上的万兆网卡服务器 我们本次测试只测试一种丢包率的情况就是1%，有兴趣的情况下，可以自己去做些其他丢包率的测试，大多数写在丢包率20%以上的时候，效果可能没那么好，这个高丢包率不是我们探讨的情况，毕竟不是常用的场景###安装新内核内核可以自己选择4.9或者以上的进行安 ...

前言RBD 的 mirroring 功能将在Jewel中实现的，这个Jewel版本已经发布了很久了,这个功能已经在这个发布的版本中实现了，本来之前写过一篇文章，但是有几个朋友根据文档配置后，发现还是有问题，自己在进行再次配置的时候也发现有些地方没讲清楚，容易造成误解，这里对文档进行再一次的梳理 基本原理我们试图解决的或者至少需要克服的问题是，ceph在内部是强一致性的，这个对于跨区域的情况数据同步是无法接受的，一个请求需要异地返回再确认完成，这个在性能上肯定是无法接受的，这就是为什么基本上无法部署跨区域的ceph集群 因此我们需要有一种机制能够让我们在不同区域的集群之间复制块设备。这个能够帮助我们实现两个功能： 灾难恢复 全球块设备分布（跨地理位置） 内部的实现 从上图所示是进行的主备模式的备份，其实这个只是看怎么应用了，在里面是自动实现的主主的模式，双向同步的，只是在应用中需要注意不要去同时操作同一个image，这个功能是作为主备去使用的，以备真正有问题的时候去实现故障恢复，这个同步是异步的 一个新的进程一个新的守护程序：rbd-mirror 将会负责将一个镜像从一个集群同步到另 ...