关于维护 Ceph & OpenStack 集群过程中的一些总结

字数 8373阅读 1027评论 0赞 4

内容摘要：

Ceph集群维护需保持OSD状态UP&IN，PG状态正常，可使用ceph-deploy工具添加或删除节点，新建存储池需指明PG数量。维护方法包括crushmap、Monitor和OSD故障排查，建议设置最小副本数和修改PG数量优化性能，修改cinder-volume配置文件和恢复OSD分区表解决存储问题。

当前摘要为AI生成

OSD的状态可能在ceph集群内（in）或集群外（out），也可能处于运行中（up）或者不运行中（down）。
 OSD处于UP状态时，可能处于集群内（in）或集群外（out）。当他是UP状态且在集群中（in），则可以向这个OSD读写数据。如果处于UP状态的OSD最近out了（以前是in），ceph会把其上的PG迁移到其他处于UP&in状态的OSD上，CRUSH也就不再分配PG给他了。
 如果一个OSD处于down状态，其也应处于集群外（out）。如果一个OSD 处于 out&in状态，则说明整个ceph集群处于非健康状态。
 当ceph集群启动并运行时，所有的OSD应处于 up&in 状态。
 如果ceph集群中处于UP状态的OSD数量小于处于in状态的OSD 数量，则需要查看是哪些ceph-osd守护进程没有运行。如果有OSD处于down 状态 ，则应把他启动起来（systemctl start ceph-osd@OSD实例）。
 CRUSH会根据ceph设定的存储持副本数将PG分配到不同的OSD上。
 Acting set ：一组涉及到某个PG 的OSD。
 Up set :实际处理读写请求的OSD集合。（CEPH依靠UP SET 处理客户端请求，大多数情况下 up set 和 acting set 是相同的。）如果up set 和 acting set 不相同，则说明某个OSD正在恢复或集群中的OSD数量发生了变化导致CEPH正在迁移数据或者集群中的OSD故障有其他OSD正在接管故障OSD的工作。
 获取PG列表：ceph pg dump
 查看指定PG的acting set 或up set涵盖的OSD：ceph pg map PG编号
 查看PG的状态：ceph pg stat
 查看pool或PG编号信息：ceph osd lspools，它会输出 “ pool-编号.pg-编号 ”
 查询某个PG：ceph pg pool-编号.pg-编号 query
 找出卡住的PG组：ceph pg dump_stuck 状态类型
 向CEPH中写数据前必须取保PG处于active & clean 状态。
 CEPH确认当前PG的状态：PG的主OSD与其从OSD建立连接并确认当前PG状态。
 OSD会向CEPH-MON报告自己的状态。
 CEPH集群健康检查结果为 HEALTH_WARN，原因有二：一是OSD未运行或运行异常；二是PG状态异常。导致PG状态异常的原因有：新建了pool，此时PG未协商一致；PG正在恢复；OSD发生了增减；PG的副本间的数据不一致；PG副本正在被洗刷；ceph中没有足够的容量进行回填操作；修改了crushmap导致PG正在迁移。
 存储对象数据：rados put 对象名 数据文件路径 —pool=存储池
 查看ceph对象存储中的文件：rados -p 存储池 ls
 定位对象数据的位置：ceph osd map 存储池 对象名
 删除对象存储数据：rados rm 对象名 —pool=存储池
 列出ceph集群中的全部用户：ceph auth list
 CEPH管理员创建或删除普通用户是会把keys发给客户端。
 CEPH中使用 “ TYPE.ID ” 的个是表示用户，比如 “ client.admin ” 表示用户为client类型且其ID是admin。
 获取某个用户的信息：ceph auth get 用户类型.用户ID
 CEPH 新增用户：
 ceph auth add
 ceph auth get-or-create
 ceph auth get-or-create-key
 查看某个用户的当前授权信息：ceph auth get 用户类型.用户ID
 变更某个用户的授权信息：ceph auth caps用户类型.用户ID
 删除某个用户：ceph auth del 用户类型.用户ID
 打印某个用户的授权密钥：ceph auth print-key 用户类型.用户ID
 倒入用户及其密钥：ceph auth import -i 密钥文件路径
 CEPH客户端本地保存的keyring文件路径：/etc/ceph/集群名.keyring或/etc/ceph/keyring。也可以在ceph.conf中指定keyring路径。
 创建客户端的keyring使用 ceph-authtool —create-keyring 。当需要创建一个包含多个用户的keyring文件时，建议使用 “ 集群名.keyring ” 作为文件名保存与目录 “ /etc/ceph/ ” 下。创建仅包含一个用户的keyring文件时，建议使用 “ 集群名.用户类型.用户名.keyring ” 作为文件名保存与目录 “ /etc/ceph/ ” 下。
 获取某个用户的keyring文件：ceph auth get 用户类型.用户名 -o 用户的keyring文件
 向已存在的keyring文件中导入某个用户：ceph-authtool 目标keyring文件 —import-keyring 被导入的keyring文件
 Ceph的Monitor建议部署成不少于3个的奇数个。后续如需增加，建议每次增加2个Monitor。
 通过ceph-deploy工具增加Monitor节点：
 1 登陆 ceph-deploy所在的admin节点，并进入ceph-deploy的工作目录；
 2 执行 ceph-deploy mon create MONITOR主机
 手工添加Monitor节点：
 1 登录到待操作主机，新建MONITOR的工作目录 /var/lib/ceph/mon/ceph-节点主机名
 2 新建一个临时目录用于存储该节点的keyring文件和集群的mon-map文件，假定这个临时目录为 /temp/
 3 获取 mon.admin 的 keyring 文件：ceph auth get mon.admin -o /temp/集群名.mon.admin.keyring
 4 获取ceph集群的mon-map文件：ceph mon getmap -o /temp/集群名.monap
 5 格式化MONITOR的工作路径：ceph-mon -i MON-ID —mkfs —monmap /temp/集群名.monmap —keyring /temp/集群名.mon.admin.keyring
 6 启动该节点上的Monitor进程（它会自动加入Ceph集群）：ceph-mon -i MON-ID —public-addr IP:PORT
 通过ceph-deploy工具删除Monitor节点：
 1 登陆 ceph-deploy所在的admin节点，并进入ceph-deploy的工作目录；
 2 执行 ceph-deplou mon destroy MONITOR主机
 手工删除Monitor节点：
 1 登录到控制节点主机，停止全部的ceph-mon
 2 确认还存活的Monitor并登陆到存活的Monitor节点
 3 提取Ceph集群的mon-map：ceph-mon -I ‘MON-ID’—extract-monmap /temp/monmap
 4 删除mon-map中有故障或处于非存活状态的Monitor：monmaptool /temp/monmap —rm 待删除的MONITOR
 5 向存活的Monitor 注入 修改后的mon-map：ceph-mon - i 存活的MONITOR —inject-monmap /temp/monmap
 6 启动存活的Monitor
 7 确认当前集群中的Monitor达到了预定数量（ceph -s）
 8 酌情备份或删除剔除掉的Monitor节点数据目录 /var/lib/ceph/mon
 通过ceph-deploy工具 添加OSD ：
 1 登陆 ceph-deploy所在的admin节点，并进入ceph-deploy的工作目录；
 2 列举出目标节点上的磁盘；
 3 格式化目标磁盘（也就是删除了目标磁盘上的分区表）
 4 准备目标磁盘（实质是创建磁盘分区）
 5 激活准备好的磁盘并把它启动为OSD
 手工增加OSD：
 1 创建OSD，并记录OSD编号
 2 登录到新增主机创建数据目录
 3 把用于做OSD的磁盘挂载到新建的数据目录
 4 初始化OSD的数据目录
 5 向Ceph集群添加OSD的keyring密钥
 6 把新的OSD添加到 crushmap 中
 7 启动新增的这个OSD
 手工删除OSD：
 1 停止待删除的OSD进程
 2 将待删除的OSD标记为out状态，并等待ceph集群恢复到HEALTH_OK状态；
 3 从crushmap中删除对应的osd记录
 4 删除该OSD 的keyring信息
 5 删除这个OSD
 6 卸载掉OSD的数据目录挂载点
 7 登录主管理节点，修改ceph.conf，删除其中的osd对应条目
 8 将修改后的ceph.conf同步到ceph集群中的其他主机上
 Ceph默认使用 存储池RBD存放数据，默认存放1个数据对象及其1个副本。默认给一个OSD分配100个PG。
 新部署好的ceph集群中默认只有一个名为RBD的存储池。
 新建存储池需要指明存储池的PG数量和PGP数量，以及存储池类型。
 为了保证I/O正常，建议给存储池设置最小副本数。
 删除存储池时，最好也删除其对应的规则集及其涉及的用户。
 Crushmap确定了数据应如何存储及检索。它会尽量把数据随机地、平均地分不到集群的OSD中。Crushmap规则规定了如何放置数据对象副本。默认情况下，每个存储池都有一条规则，一般不需要修改默认规则。
 手动管理crushmap需要在配置文件中设置“osd crush update on start = false”。
 编辑crushmap需要：
 1 获取当前集群的crushmap并保存为本地文件；
 2 使用crushtool反编译保存的crushmap；
 3 修改设备、桶、规则的信息；
 4 重编译crushmap；
 5 把新编译好的crushmap注入到Ceph集群。
 Ceph中的权重与设备容量：1.00表示1TB的设备容量；0.5表示500GB设备容量。
 使用osd primary-affinity 设置的主OSD亲和性。
 增加集群里OSD所对应的crushmap条目：ceph osd crush set ...
 把集群里的某个OSD剔除出crushmap：ceph osd crush remove ...
 调整某个OSD的crush权重：ceph osd crush reweight ...
 在crushmap中建立两个树，一个用于让存储池映射到大容量的SATA硬盘构成的OSD上、一个用于让存储池映射到高速读写的SSD硬盘构成的OSD上。然后设置ssd-primary规则让存储池内的各归置组使用SSD型的OSD创建虚拟机的启动卷。
 Monitor之间通过mon-map发现彼此。
 修改一个Monitor的IP必须先增加一个新的Monitor以确保Ceph集群中的mon形成法定人数。而后删除旧的mon并更新ceph.conf中的mon信息。
 修改Ceph集群的配置信息：
 1 修改 /etc/ceph/ceph.conf 文件，并重启ceph各进程；
 2 使用daemon或者tell的形式在运行的集群中修改（当时生效，重启ceph集群后失效，常用于调试或者调优或者排障）
 ***********************************************************
 Monitor不能正常服务，则Ceph集群 不可用。
 Monitor故障时的排查顺序：
 Mon进程在运行吗？（检查本地磁盘空间足不足）
 Mon Server可链接吗？（防火墙是否拦截）
 执行“ceph -s”是否有响应？（Monitor没有形成法定人数时会输出大量fault信息，此时可用Unix套接字和mon进程交互获取信息；如果收到status信息，则说明已经形成了法定人数、且集群在运行着）
 Unix套接字用于直接和守护进程交互。Monitor的socket在其节点的目录/run/下，默认位于 /var/run/ceph/ceph-mon.ID.asok 。
 Probing状态意味着当前主机的Monitor还在根据monmap搜索其他Monitor。在多个Monitor环境中，未达到mon预定的法定人数前都会处于该状态。卡在probing状态的原因有三：主机的链接问题、节点间时钟不同步和monmap中的某个MonitorIP地址与试试IP地址不相符合。
 Electing状态意味着当前主机的Monitor处于选举状态。如果卡在electing状态，原因一般是Monitor节点间时钟不同步。
 Synchronizing状态意味着正在与其他Monitor进行同步。Monitor的数据库越小，同步越快。
 如果Monitor的状态在Synchronizing和Electing之间反复，则说明集群状态更新速度超过了同步速度。
 Leader或peon状态，通常和集群内各节点的时钟不同步有关。Ceph中允许的最大时钟偏移量是0.05秒。
 修复受损的Monitor的monmap：
 1 从剩余的Monitor中抓取monmap；
 2 停止以受损的Monitor；
 3 把抓取到的的monmap注入到目标Monitor；
 4 启动目标Monitor
 修复受损的Monitor的数据库store.db：
 方法一：用幸存的Monitor的store.db覆盖已损坏的store.db
 方法二：使用OSD上存储的信息恢复Monitor的数据库
 1 从所有的OSD主机上搜集monmap信息；
 2 使用ceph-monstore-tool重建store.db；
 3 用重建的store.db替换已损坏的store.db；
 4 重新导入相应的keyring、重新设置PG信息、重新打入MDS-map。
 本地磁盘空间不足时Monitor服务会down掉。
 停止CRUSH自动均衡：给集群设置 noout 标签。
 OSD启动失败：
 1 配置文件是否合规；
 2 配置的数据和日志路径是否正确；
 3 OSD的最大线程数是否超出了系统内核限制；
 4 OSD是不是写满了（Ceph不允许向满的OSD中写入数据）
 某个OSD挂了：
 1 通过 ceph health detail 查看是哪个osd进程
 2 登录到目标osd进程主机查看日志，一般是硬盘损坏的情况居多。
 3 OSD是不是写满了（Ceph不允许向满的OSD中写入数据）
 OSD响应慢：
 1 网络问题导致OSD演示或震荡
 2 磁盘没有独占用于OSD，有其他共享进程在进行顺序读写
 3 磁盘存在坏的扇区
 4 monitor进程和osd进程共享了磁盘
 5 文件系统不恰当（推荐使用xfs）
 6 内存不足（推荐为每个OSD进程规划1GB内存）
 OSD震荡：public网（ceph管理网）运行正常、但Cluster网（ceph集群网）出现了网络连接失败或者明显延时。
 ***********************************************************
 正常的PG状态应该是：active+clean。PG状态一直无法达到此状态，应该检查pool、pg、crush的配置。
 允许把不同的数据副本分不到同一个host的OSD上：把cepf.conf中的 osd crush chooseleaf type 值改为 0。
 OSD处于up&in状态、但PG未处于active+clean状态：给存储池的默认size设置了较大的值，需要恰当修改。Crushmap错误到最后PG不能映射到正确的OSD也是一个原因。
 PG卡在stale状态可以通过重启OSD进程修复；
 PG卡在inactive状态一般是osd进程互联失败了，重启对应的osd进程即可；
 PG卡在unclean状态通常是未找到对象副本造成I/O阻塞，应及早恢复down的节点。
 只有几个OSD在接受数据：PG数量比较少，未能均衡分布到整个集群的OSD上。
 不能向Ceph集群写入数据：OSD启动的数量是否满足存储池PG要求的最小数量。
 PG处于inconsistent状态：PG的数据清洗发生了错误，建议检查硬盘是否有损坏。剔除掉坏的硬盘、移除掉不一致的对象后，对集群进行 pg repair 修复。
 每个OSD中有太多PG：OSD较少、但存储池较多，常见于测试环境。Ceph默认的是每个OSD上最多300个PG。可以通过调整monitor节点上的ceph.conf中的警告值规避。
 每个OSD中有太少PG：OSD较多、但存储池较少。一般不需要理会，等到建立了存储池后该警告就会消失。
 Ceph集群的上电启动步骤：
 1 确认ceph的客户端作业已经停止；
 2 先给MonitorServer上电；
 3 确认节点间的时钟同步；
 4 确认ceph服务已正常运行；
 5确认OSD全部UP且集群的OSD仍处于noout状态；
 6 解除集群的OSD noout状态；
 7 执行 ceph -w 和 ceph -s 确认集群状态为 HEALTH_OK状态
 从ceph集群中移除某个OSD节点：
 1 登录Monitor节点查询集群状态；
 2 把故障节点上的OSD全部设定为out；
 3 从crushmap中移除目标osd；
 4 删除 osd的keyring认证；
 5 删除目标osd
 ***********************************************************
 增加PG相当于在OSD上新建了PG目录，会引起对象数据分裂。
 增加PGP会引起PG的分布变化。
 PG制定了存储池中对象数据的目录有多少个；PGP决定了PG的分布组合个数。
 备份恢复Monitor：
 1 备份mon的store.db数据库
 2 备份mon节点的 /etc/ceph/ 目录
 3 把备份好的文件传送到新的目标操作主机并修改ceph.conf中的mon_initial_members角色为新的目标操作主机
 4 在新的目标操作主机使用monmaptool新建一个monmap
 5 在新的目标操作主机注入新建的monmap
 6 启动新的目标操作主机上的mon进程
 7 将新的目标操作主机上的ceph.conf推送到其他节点并重启ceph集群
 
 
 OpenStack的cinder和glance都配置了Ceph存储。
 在OpenStack上取法删除卷，发现有个cinder-volume状态为down；查看cinder-volume日志发现同一个时间点里有的删除成功、有的删除失败，怀疑是RBD存储卷卡死了。打开ceph.conf中的RBD Client日志，发现是进程打开的文件过多会引起的。这个环境进行过OSD扩容，RDB Client删除卷是需要和全部的OSD建立连接，超出了cinder-volume进程允许打开的最大文件数。修改cinder-volume进程的配置文件中的limit nofile 值即可。
 
 
 恢复OSD的分区表：
 1 给集群设置 noout 标签
 2 停止目标OSD进程
 3 查看其它正常OSD 的分区信息，并记录data和journal分区的起始位置
 4 使用parted工具完成分区表的创建
 5 检查新建的分区表
 6 把目标OSD挂载回数据目录
 7 重建目标OSD 的journal日志
 8 启动OSD
 PG卡在active+remapped 状态，是因为对OSD做了reweight，导致PG无法映射到对应的OSD上。

Ceph

著作权归作者所有

如果觉得我的文章对您有用，请点赞。您的支持将鼓励我继续创作！

添加新评论0 条评论

Ctrl+Enter 发表

匿名评论

关于维护 Ceph & OpenStack 集群过程中的一些总结

添加新评论0 条评论

文章目录展开目录

作者其他文章

相关文章

相关问题

相关资料