前面一节“ceph的pg诊断” 说明了ceph保证数据充足的可靠性。ceph讲究的随机，平均。但是我们有时候会发现同样大小的osd有的剩余空间很大，有的却以满了，例如下面的例子：
# 3个节点6个osd
[root@admin tmp]# ceph osd tree
ID WEIGHT TYPE NAME UP/DOWN REWEIGHT PRIMARY-AFFINITY
-1 0.05424 root default
-2 0.01808 host admin
0 0.00879 osd.0 up 1.00000 1.00000
3 0.00929 osd.3 up 1.00000 1.00000
-3 0.01808 host node1
1 0.00879 osd.1 up 1.00000 1.00000
4 0.00929 osd.4 up 1.00000 1.00000
-4 0.01808 host node2
2 0.00879 osd.2 up 1.00000 1.00000
5 0.00929 osd.5 up 1.00000 1.00000
#节点admin上的osd使用情况
[root@admin tmp]# df -h|grep osd
/dev/mapper/cephvg-osd 9.0G 8.5G 559M 94% /srv/ceph/osd
/dev/mapper/cephvg2-osd2 9.5G 6.0G 3.6G 63% /srv/ceph/osd2
#节点node1 上的osd使用情况
[root@node1 ~]# df -h|grep osd
/dev/mapper/cephvg-osd 9.0G 6.7G 2.4G 74% /srv/ceph/osd
/dev/mapper/cephvg2-osd2 9.5G 7.9G 1.7G 83% /srv/ceph/osd2
#节点node2上的osd使用情况
[root@node2 ~]# df -h|grep osd
/dev/mapper/cephvg-osd 9.0G 6.1G 3.0G 68% /srv/ceph/osd
/dev/mapper/cephvg2-osd2 9.5G 8.4G 1.2G 89% /srv/ceph/osd2上面我们可以看到三个节点6个OSD，每个osd都是10G的总容量且都是普通的磁盘，那为什么osd的使用率差别为什么这么大了？
下面我们就简单的解释一下：
我们在创建pool的时候都指定了pg的个数，且也限制了pool的磁盘容量配额
[root@admin tmp]# ceph osd pool ls detail|grep pool0
pool 3 'pool0' replicated size 3 min_size 2 crush_ruleset 0 object_hash rjenkins pg_num 32 pgp_num 32 last_change 127 flags hashpspool max_bytes 104857600 stripe_width 0
# pool0 设置pg32个，最大容量100M（max_bytes 104857600 换算出来的）[root@admin tmp]# ceph osd pool ls detail|grep pool1
pool 4 'pool1' replicated size 3 min_size 2 crush_ruleset 0 object_hash rjenkins pg_num 32 pgp_num 32 last_change 129 flags hashpspool max_bytes 5368709120 stripe_width 0
# pool1 也是32个pg，最大容量5G我们看到pool0和pool1的pg的个数相同，单总容量却相差甚远。那我们想想 总容量/pg个数=pg容量
pool0里面的pg容量和pool1里面的pg的容量相差很大，而每个pg分布到osd上，osd磁盘的大小却是相同的，这就是为什么导致osd使用率相差很大的原因。
[root@admin tmp]# ceph -s
cluster 55430962-45e4-40c3-bc14-afac24c69acb
health HEALTH_WARN
clock skew detected on mon.node1
2 near full osd(s)
Monitor clock skew detected
monmap e1: 3 mons at {admin=172.18.1.240:6789/0,node1=172.18.1.241:6789/0,node2=172.18.1.242:6789/0}
election epoch 30, quorum 0,1,2 admin,node1,node2
osdmap e134: 6 osds: 6 up, 6 in
flags nearfull,sortbitwise,require_jewel_osds
pgmap v2188: 192 pgs, 4 pools, 4474 MB data, 284 objects
44349 MB used, 12422 MB / 56772 MB avail
192 active+clean
# 已经警告2个osd 快满了。那么我们在详细去查一下，我们pool0里面存入的文件90m是一个大小只有90M的文件
[root@admin tmp]# rados -p pool0 ls
rbd_object_map.acd0238e1f29
90m
rbd_id.image0
rbd_directory
rbd_header.acd0238e1f29而pool1 里面存入了4个都是超大文件
[root@admin tmp]# rados -p pool1 ls|grep G
3G1
3G3
3G
3G2
我们分别看一下两个pool里面的文件的pg分布
[root@admin tmp]# rados -p pool0 ls|grep 90
90m
[root@admin tmp]# ceph osd map pool0 90m
osdmap e134 pool 'pool0' (3) object '90m' -> pg 3.149ba74f (3.f) -> up ([2,0,4], p2) acting ([2,0,4], p2)
#上面是pool0里面的小文件 分布在0，2，4osd上
[root@admin tmp]# rados -p pool1 ls |grep G
3G1
3G3
3G
3G2
[root@admin tmp]# ceph osd map pool0 90m
osdmap e134 pool 'pool0' (3) object '90m' -> pg 3.149ba74f (3.f) -> up ([2,0,4], p2) acting ([2,0,4], p2)
[root@admin tmp]# ceph osd map pool1 3G
osdmap e134 pool 'pool1' (4) object '3G' -> pg 4.e7764a6c (4.c) -> up ([4,0,5], p4) acting ([4,0,5], p4)
[root@admin tmp]# ceph osd map pool1 3G1
osdmap e134 pool 'pool1' (4) object '3G1' -> pg 4.f6d15484 (4.4) -> up ([1,5,0], p1) acting ([1,5,0], p1)
[root@admin tmp]# ceph osd map pool1 3G2
osdmap e134 pool 'pool1' (4) object '3G2' -> pg 4.860667f (4.1f) -> up ([3,2,1], p3) acting ([3,2,1], p3)
[root@admin tmp]# ceph osd map pool1 3G3
osdmap e134 pool 'pool1' (4) object '3G3' -> pg 4.5f18be84 (4.4) -> up ([1,5,0], p1) acting ([1,5,0], p1)
# 上面是pool1里面的大文件，大部分都分布在osd.0 和osd.5上
看明白了吧，就是因为pool1里面每个pg的容量非常大，且这些pg大多数分布在osd.0 和osd.5上，所以我们下面看到的两个接近满载的osd应该就是0和5，我们下面验证一下看看是不是这个样子
[root@admin ~]# ceph health detail
HEALTH_WARN clock skew detected on mon.node1; 2 near full osd(s); Monitor clock skew detected
osd.0 is near full at 93%
osd.5 is near full at 88%
mon.node1 addr 172.18.1.241:6789/0 clock skew 0.386219s > max 0.05s (latency 0.00494154s)所以我们在创建pool的时候要保证3个规则：
1 每个osd的pg个数在100个左右
2 pg的个数是2个N次方
3 每一个pool的总容量和pg的个数换算出来的pg的容量 都基本上一致
如果万一出现这样osd使用率不均衡的情况，接近办法有两个：
1 削峰填谷，转移大文件到其他pool
2 修改pool的pg个数（pg个数只能增大不能缩小，所以对大文件pool增大其pg个数）