防火墙对ceph的影响

2018-02-27 11:25:20来源:oschina作者:胡子叭槎人点击

分享

我们在部署ceph的时候大部分都是需要关闭防火墙的,假如不关闭防火墙,会发生什么了?


之前给公司远程部署一个ceph集群,3个节点上还部署的有openshift。在部署ceph的时候遇到了很多问题,最让人蛋疼的就是osd都挂上了,但是健康检查显示err,osd 0 in 0 on 。抓耳捞腮 后来才解决。问题是安装了openshift的节点上不能关闭防火墙。几个端口不能访问。


现在我们来实验一下如果不关闭防火墙的现象:


1 我创建了3个pool


rep1 1个副本


rep2 2个副本


rep3 3个副本


[root@admin ~]# ceph df
GLOBAL:
SIZEAVAILRAW USED %RAW USED
89044M 72066M16977M19.07
POOLS:
NAMEID USED %USED MAX AVAIL OBJECTS
rbd0500M2.17 22537M2
pool0 100 22537M1
rep1500 67612M1
rep2600 33806M1
rep3700 22537M0
[root@admin ~]# ceph osd pool get rep1 size
size: 1
[root@admin ~]# ceph osd pool get rep2 size
size: 2
[root@admin ~]# ceph osd pool get rep3 size
size: 3
# 副本数还可以这么查
[root@admin ~]# ceph osd pool ls detail|grep rep
pool 0 'rbd' replicated size 3 min_size 2 crush_ruleset 0 object_hash rjenkins pg_num 64 pgp_num 64 last_change 115 flags hashpspool stripe_width 0
pool 1 'pool0' replicated size 3 min_size 2 crush_ruleset 0 object_hash rjenkins pg_num 64 pgp_num 64 last_change 31 flags hashpspool stripe_width 0
pool 5 'rep1' replicated size 1 min_size 1 crush_ruleset 0 object_hash rjenkins pg_num 32 pgp_num 32 last_change 233 flags hashpspool stripe_width 0
pool 6 'rep2' replicated size 2 min_size 2 crush_ruleset 0 object_hash rjenkins pg_num 32 pgp_num 32 last_change 235 flags hashpspool stripe_width 0
pool 7 'rep3' replicated size 3 min_size 2 crush_ruleset 0 object_hash rjenkins pg_num 32 pgp_num 32 last_change 237 flags hashpspool stripe_width 0

分别在rep1 rep2 两个池中新建了几个object,我找出几个比较典型的object来实验


[root@admin ~]# ceph osd map rep1 file
osdmap e237 pool 'rep1' (5) object 'file' -> pg 5.2e6fb49a (5.1a) -> up ([6], p6) acting ([6], p6)
[root@admin ~]# ceph osd map rep2 file2
osdmap e237 pool 'rep2' (6) object 'file2' -> pg 6.be5b00c1 (6.1) -> up ([1,6], p1) acting ([1,6], p1)

上面可以看到rep1 中因为只有1个副本,所以pg5.1a只放在osd.6中 主pg只有一个,rep2 有两个副本,pg6.1放在osd.1 和osd.6中,主pg放在osd.1上。下面我们继续看看osd.1 和osd.6都在哪些节点上


[root@admin ~]# ceph osd tree
ID WEIGHTTYPE NAMEUP/DOWN REWEIGHT PRIMARY-AFFINITY
-1 0.08487 root default
-2 0.02829 host admin
6 0.02829osd.6up1.00000 1.00000
-3 0.02829 host node1
0 0.02829osd.0up1.00000 1.00000
-4 0.02829 host node2
1 0.02829osd.1up1.00000 1.00000

我们看到osd.6 在admin节点,osd.1 在node2节点


下面我们开始实验:


1 把admin 防火墙打开


[root@admin ~]# systemctl start firewalld
[root@admin ~]# systemctl status firewalld
● firewalld.service - firewalld - dynamic firewall daemon
Loaded: loaded (/usr/lib/systemd/system/firewalld.service; disabled; vendor preset: enabled)
Active: active (running) since Sun 2018-02-11 22:17:43 EST; 15s ago
Main PID: 15005 (firewalld)
CGroup: /system.slice/firewalld.service
└─15005 /usr/bin/python -Es /usr/sbin/firewalld --nofork --nopid
Feb 11 22:17:42 admin systemd[1]: Starting firewalld - dynamic firewall daemon...
Feb 11 22:17:43 admin systemd[1]: Started firewalld - dynamic firewall daemon.

2 在admin节点上向 pg5.1a里面写数据


[root@admin ~]# rados -p rep1 put file /etc/hosts
[root@admin ~]#

非常快数据正常写入


3 我们在其他节点向pg5.1a写数据


[root@node2 ~]# rados -p rep1 put file /etc/ceph/ceph.conf
^C
[root@node2 ~]#
#等待了10分钟都没写进去,卡死了

原因是什么了?因为我们把admin的防火墙开起来了,而osd.6就在admin上,我们向osd.6里面的pg5.1a写数据是没有问题,但是我们从其他节点上往osd.6里面的pg5.1a写数据被admin的防火墙拦截了,所以写不进去。


4 我们从admin节点向rep2 中的pg6.1写数据


[root@admin ~]# rados -p rep2 put file /etc/hosts
[root@admin ~]#
#正常写入

5 我们从其他节点向rep2中的pg6.1 写数据


[root@node2 ~]# rados -p rep2 put www /etc/hosts
[root@node2 ~]#
# 也能正常写入

这又是为什么了?不是说osd.6 被它的节点admin防火墙拦截了吗?为什么pg6.1 也有放在osd.6上的,为什么能正常写入?这是因为虽然rep1上的pg6.1 也有放在osd.6上,但是它的主pg是osd.1,osd.1节点是node2,它的防火墙没有开,所以是可以写的进去的。


下面我们就要解释一下主pg和副pg之间的联系,写数据值直接写入主pg中的,然后通过副pg主动从主pg中拷贝过去,所以我们就明白了为什么pg6.1 可以正常写入,因为写入的时候直接写入osd.1中的主pg6.1 ,然后副pg osd.6上的pg从主pg中拷贝,虽然osd.6上的防火墙打开了,到那时相互之间的联系是从防火墙内部向外链接,所以不受防火墙影响。那我可以猜测,如果主pg是osd.6,则无法正常写入。


其他osd联系你,你的防火墙打开拒绝了和其他osd通信,其他osd以为你死了上报给mon,状态写成down,但是你一个看,我靠,我没死还活着好好的,你又上报给mon状态写成up,然后其他osd又联系你,等等如此往复形成死循环。


所以当你放心osd 不停的down up,很可能就是防火墙问题。


如果设置的osd上报间隔时间比较长,那你会看到osd一致是up,但是你就是无法写入数据,生产上特别

最新文章

123

最新摄影

闪念基因

微信扫一扫

第七城市微信公众平台