zd147896325的博客

前言尽管ceph可以提供出多个pool，很多情况下，客户的所有的业务数据位于一个pool内。这种情况下，主要使用的pool的PG分布是否均匀，就决定了各个OSD的使用是否均匀。CRUSH算法让PG均匀地分布在各个OSD上，但这仅仅是概率上的平均，实际使用中，经常发生不均匀的情况，甚至出现非常不均匀的情况。我们以pg_num = 1024的双副本pool为例，对于该pool，一共有2048个PG，这2048个PG分布在OSD上。如果Pool中有10个OSD，那么平均每个OSD应该分到204～205

目录场景描述情况介绍操作步骤Monitor成功创建场景描述:最近客户线上一个三节点集群，由于raid卡故障导致一个存储节点宕机，可能是raid卡突然故障导致ceph mon数据库文件丢失，ceph-mon无法启动，只能删掉重新创建情况介绍：可以看到集群只剩两个monitor再次发生网络动荡的时候，两个monitor容易发生脑裂，所以需要尽快解决操作步骤：先随机生成五位字符来当作monitor IDimport random mon_id = ""...

文章目录背景要求基础篇存储产品架构NAS相关块设备相关（ISCSI/FC）S3相关linux系统及其他磁盘及raid卡相关操作ceph相关故障排查进阶篇NASS3进阶篇NASS3背景本文旨在通过一系列的问题引导学习，这些问题都是从线上实践中选举出来的，为了达到循序渐进的效果，将问题分成了基础篇和进阶篇，目前文档还是初始阶段，后续还会陆续补充。希望SE可以通过这些问题的学习和实践，快速的了解和掌握我们产品。要求要求在解决这些问题的过程中，将自己的解决思路，探索过程留下文档，如果有自己的总结更好。基础

查看近期集群中node有没有发生重启以及存储节点负载情况onnode all uptime系统当前时间 17：59：03up 389 days, 19:23 从上次启动开始系统运行的时间2 users 注意这里实际是连接数量load average: 7.60, 6.72, 6.12 这是重头戏，分别描述了1分钟5分钟15分钟内系统平均负载根据经验值通常只需查看最后一个参数 [1...