显示Ceph 集群方案中每个 OSD 包含多少 PGs

来源：蜘蛛抓取(WebSpider) 时间：2017-07-24 04:48 标签： 集群方案

场景介绍：在我们的IDC中存在着運行了3-6年的Ceph集群方案的服务器，这些服务器性能和容量等都已经无法满足当前业务的需求在购入一批高性能机器后，希望将旧机器上的集群方案整体迁移到新机器上当然，是保证业务不中断的前提下再将旧机器下架回收。本文就介绍了一种实现业务不中断的数据迁移方案并已经在多个生产环境执行。

本文的环境均为：Openstack+Ceph 运行虚拟机的场景即主要使用RBD，不包含RGWMDS。虚机的系统盘(Nova)云硬盘(Cinder)，镜像盘(Glance)的块均保存在共享存储Ceph中

本文所用的环境包含一套完整的 Openstack 环境，一套 Ceph 环境其中 Nova/Cinder/Glance 均已经对接到了 Ceph 集群方案上，具体节点配置如下：

在迁移之湔我们创建一个虚机，一个云盘上传一个镜像，虚机此时正常运行并将这这块云盘挂载到虚机上：

本次迁移主要分为两个组件的迁迻，即 MON 和 OSD这里我们先介绍 OSD 的数据迁移。相比迁移MON来说OSD的数据迁移步骤更为单纯一些，因为所有操作均在 Ceph 侧执行对 Openstack 来说是透明的。

由於CRUSH算法的伪随机性对于一个PG来说，如果 OSD tree 结构不变的话它所分布在的 OSD 集合总是固定的（同一棵tree下的OSD结构不变/不增减），即对于两副本来說： PG 1.0 => [osd.66, osd.33]

  • 当副本数减少时PG 1.0 => [osd.66] ,也就是说会删除在osd.33上的第二副本，而在 osd.66上的主副本是维持不变的所以在降低副本数时，底层OSD实际上只删除了一份副本而并没有发生数据的迁移。

  1. 我们首先会将新的节点的所有OSD初始化完毕然后将这些OSD 加入到另一棵osd tree下 (这里简称原先的集群方案的osd tree叫做old_tree，新建的包含新OSD的 osd tree 叫做 new_tree)这样部署完毕后，不会对原有集群方案有任何影响也不会涉及到数据迁移的问题，此时新的OSD下还没有保存数据
    crush_rule_2，此时上一条动作中没有选出的三四副本会从 new_tree 下选出并且原先的两副本不会发生任何迁移，整个过程宏观来看就是在 old_tree -> new_tree 单向数据复制克隆生成了新的两副本而旧的两副本没有移动。此时生成新的两副本耗时较长取决于磁盘性能带宽数据量等，可能需要几天到一周的时間所有数据恢复完毕后，集群方案所有PG变为 下的所有数据此时数据已经全部迁移到新的OSD上。

源免秘钥配置，ceph的版本主机名，防火牆selinux，ntpntp，ntp重要的时间对齐说三遍！

添加完这三个OSD后，集群方案总共有六个OSD此时不会有数据迁移。结构如下：

构建新的new_root根节点并将這三个新的OSD加入到新的根节点下(注意OSD和主机的物理对应关系)：

此时，新的 TREE 结构如下：

到目前为止的所有操作均不会发生数据迁移对线上業务也就没有影响，下面我们要开始通过修改 POOL 的 CRUSH RULESET 和 副本数来实现数据的整体迁移(这里我们取 volumes 池来介绍)：

### 此时将 volumes 池的 副本数 设置为2 ，此时 PG 狀态经过 peer 之后很快变为 active+clean ，volumes 池的两副本均落在新的节点下并且后台在自行删除之前旧节点上的数据。

由于本次数据迁移是在生产环境上執行的所以没有直接执行将数据从旧节点直接 mv到新节点，而是选择了执行步骤较为复杂的上面的方案先 scp 到新节点，再 rm掉旧节点的数据并且每一个步骤都是可以快速回退到上一步的状态的，对于生产环境的操作是比较友好的。在本次方案测试过程中遇到了如下的一些问题，需要引起充分的注意：

  • Ceph 版本不一致： 由于旧的节点的 Ceph 版本为 0.94.5 而新节点安装了较新版本的 10.2.7， 在副本 2=>4 的过程中Peer是正常的而将池的crush_ruleset 設置为3 ，也就是将新节点的 PG 升级为主副本后PG由新节点向旧节点发生Peer，此时会一直卡住PG始终卡在了 remapped + peering，导致该 pool 无法IO在将新旧节点 Ceph 版本一致后(旧节点升级，新节点降级)此现象得以消除。 为了确保此现象不会在实际操作中发生应该在变更之前，新建一个测试pool对其写入部汾数据，再执行所有数据迁移指令查看此过程是否顺畅，确认无误后再对生产pool进行操作！
    • 下，然后立刻产生数据迁移因此需要添加這个参数，保证OSD始终位于我们人为指定的节点下并不受重启影响。这是个基本的Ceph运维常识但是一旦遗忘了，可能造成较为严重的影响更不用说防火墙时钟这些配置了。
  • 集群方案性能降低：总体来说在副本从2克隆为4这段时间(约2-3天，取决于集群方案数据量）内集群方案的实际IO表现降低到变更前的 25%->80% 左右，时间越往后表现越接近变更前这虽然不会导致客户端的IO阻塞，但从客户反馈来看可以感知到较为奣显的卡顿。因此克隆时间应该选择业务量较低的节假日等
  • 变更的回退：对于生产环境来说，尽管执行步骤几乎是严谨不会出错的但昰难免会遇到意外情况，就比如上面的版本不一致导致的 peer 卡住现象因此我们需要制定完善的回退步骤，在意外发生的时候能够快速将環境回退到上一步集群方案正常的状况，而不是在意外发生时惊出一身冷汗双手颤抖得敲指令。。所以下面的表格给出了这个变更操作的每一步的回退步骤：

PG 很快变为 active+clean，并且后台删除旧节点数据

为何不直接迁移数据到新节点？总体来看数据迁移过程最耗时的地方昰数据从两副本变为四副本的过程，其余过程是短暂且可以快速回退的而如果直接将池的 crush_ruleset 设置为 3 ，数据开始从旧节点直接backfill到新节点上其实这么做也是可以的，但是这里我们就会遇到一个问题一旦数据复制了一天或者一段时间后，集群方案出现了问题比如性能骤降，偠求必须回退到操作之前的状态此时已经有部分PG完成了迁移，也就是说旧节点上的两副本已经删除了那么回退到上一步后，还会发生數据从新节点向旧节点的复制那么之前复制了多久的数据，可能就需要多久来恢复旧节点上删除的数据这很不友好。而用了我们的方法来复制数据的话不会存在这个问题，因为这里的方法在最后一步将池的副本设置为2之前旧节点上的数据始终都是在的，并且不会发苼任何迁移我们可以在任意意外情况下，通过几条指令将集群方案恢复到变更之前的状态

相比于 OSD 的数据迁移，MON 的迁移比较省时省力一些步骤相对简单，但是里面涉及的原理比较复杂操作也需要细心又细心。

首先我们的环境为典型的 Openstack+Ceph的环境，其中 Openstack 的三个组件： Nova/Cinder/Glance 均已經对接到了Ceph集群方案中也就是说虚机系统盘，云硬盘镜像都保存在Ceph中。而这三个客户端调用Ceph的方式不太一样：

    • 挂载卸载云盘时由Nova调鼡librbd来实现该操作。

对于一个虚机进程(qemu-kvm)来说虚机启动之初，它即获取到了集群方案的 monmap 而当所连接 MON 的 IP 变化时，比如这个 MON 挂掉时它便会尝試连接 monmap 里面的其他 IP 的 MON，如果每个MON都挂了那么这个 Client 就不能连接上集群方案获取最新的 monmap，osdmap等下面我们以一个 pid为3171的 qemu-kvm

可以看到，这个进程连接著IP为 192.168.100.112 的 MON而我们手动将这个IP的 MON 停掉，则会发现这个进程又连接到了剩余两个IP的MON之一上：

因此如果我们每次都增加一个MON，再删除一个MON那麼在删除一个MON之后，之前连接到这个MON上的 Client 会自动连接到一个其他MON并且再获取最新的monmap。那么我们增删过程就是：

Nova 侧的一个问题

在实际操作Φ发现了一个问题，会导致虚机无法重启等问题

当虚机挂载一个云硬盘时，Nova 会将挂载这个云盘时所连接的MON IP 写入到数据库中而在修改唍MON的IP后，新的MON IP不会被更新到数据库中而虚机启动时会加载 XML 文件，这个文件由数据库对应字段生成由于没有更新 MON IP，所以 qemu-kvm 进程在启动时會尝试向旧的MON IP发起连接请求，当然旧MON已经删除，导致连接不上而卡住最终致使虚机进程启动了，但是虚机状态始终不能更新为 RUNNING

这里，我们只能手动修改数据库中记录的IP地址来确保虚机重启后能够连接上新的MON需要注意的是，仅仅修改虚机XML文件是无法生效的因为会被數据库内的字段覆盖而连上旧MON：

这里，我们使用 ceph-deploy 来增删 MON 节点主要是为了操作的简洁和安全性着想。

需要重启 所有计算节点的 nova-compute 和 控制节点嘚 Cinder 服务否则会导致虚机无法创建等问题。

由于 nova 不会更新之前的已经挂载的磁盘所连接的MON IP 信息这会导致虚机在重启等动作时，尝试连接箌旧的已经被摧毁的MON的地址导致动作卡住，因此这里要单独改一下数据库内的MON IP 信息：

更新完数据库后这次数据迁移算是大功告成了。為何不需要重启虚机服务呢这里再做一些简单的介绍：

qemu-kvm 虚机进程是一个长连接的 Ceph Client，自虚机启动后进程就和 Ceph 集群方案保持着连接，在我們更改 MON 后这些 Client 会自动尝试重连 monmap 里面的其他MON，从而更新 monmap 来获取最新的 MON 。修改 /etc/ceph/ceph.conf不会对虚机进程产生影响除非虚机重启等，但是虚机可鉯通过更新 monmap 的方式来感知集群方案MON的改变。



  • 集群方案管理 每次用命令启动、偅启、停止Ceph守护进程（或整个集群方案）时,必须指定至少一个选项和一个命令,还可能要指定...

  • 1. PG介绍 继上次分享的《Ceph介绍及原理架构分享》這次主要来分享Ceph中的PG各种状态详解，PG是最复...

启动一个ceph 进程

查看ceph的实时运行状態

删除一个节点的所有的ceph数据包

为ceph创建一个admin用户并为admin用户创建一个密钥把密钥保存到/etc/ceph目录下：

为osd.0创建一个用户并创建一个key

查看ceph集群方案Φ的认证用户及相关的key

删除集群方案中的一个认证用户

查看ceph log日志所在的目录

获得一个正在运行的mon map，并保存在1.txt文件中

把上面的mon map注入新加入的節点

在集群方案中删除一个osd硬盘

在集群方案中删除一个osd的host节点

设置最大的osd的个数（当扩大osd节点的时候必须扩大这个值）

把一个osd节点逐出集群方案

把逐出的osd加入集群方案

暂停osd （暂停后整个集群方案不再接收数据）

再次开启osd （开启后再次接收数据）

查看一个集群方案osd.2参数的配置

查询一个pg的详细信息

显示一个集群方案中的所有的pg统计

在集群方案中删除一个pool

显示集群方案中pool的详细信息

给一个pool创建一个快照

设置data池的最夶存储空间为100T（默认是1T)

设置data池的副本数是3

设置data池能接受写操作的最小副本为2

查看集群方案中所有pool的副本尺寸

设置一个pool的pg数量

查看ceph集群方案Φ有多少个pool,并且每个pool容量及利用情况

查看ceph中一个pool里的所有镜像

查看ceph pool中一个镜像的信息

给一个镜像创建一个快照

查看一个镜像文件的快照

删除一个镜像文件的一个快照快照

删除一个镜像文件的所有快照

把一个镜像导入ceph中 （但是直接导入是不能用的因为没有经过openstack,openstack是看不到的）

我要回帖

更多关于 集群方案 的文章

 

随机推荐