服务端做网口聚合(bond4或bond1模式)后,down/up聚合网口,其他节客户端连接失败。

sky__hook

环境 : [Ubuntu14.04]
网卡聚合 :  [bonding+ifenslave], bond4和bond1
物理网卡 : P9P1/P9P2
聚合网卡 : bond0
以上环境作为服务端，服务端还有其他物理网卡，服务端程序监听所有IP，通过SO_BINDTODEVICE绑定到bond0网口，做到监听bond0。
如果只是down/up聚合的物理网卡不会出现问题，如果down/up聚合网卡，客户端连接失败(connection refused)，重启服务端程序后,恢复正常。如果服务端程序只是监听bond0网卡的一个IP，则不会出现连接失败。
分析是down掉聚合网口后监听失效，是否是服务端程序问题还是bond本身的bug，如果是服务端程序错误该怎么修改？如果是bond模式的bug，如何规避，服务端程序怎么感知到监听失效？
谢谢解答。

q1208c

回复 1# sky__hook

到底是哪里有影响？
没看明白。

sky__hook

回复 2# q1208c

服务端设备是多网卡的，服务端程序bind的是INADDR_ANY，最初客户端程序可以通过所有网段来访问服务端程序，为了安全性限制客户端只能在一个网段访问服务端程序，所以在服务端增加了setsockopt+SO_BINDTODEVICE方式来将服务端程序只绑定到一个网卡（没有改成bind一个IP是因为一个网口会有多个IP）。所以客户端只能通过服务端绑定的网卡的网段来访问服务端程序。

1、当服务端直接使用的都是物理网卡的情况都是正常的；
2、如果将物理网卡P9P1和P9P2做成虚拟聚合网卡bond0（采用bond4模式），此时如果将物理网卡P9P1或P9P2进行down、up操作，只要保证有一个物理网卡是up状态，也是正常的；
3、如果将bond0网卡down、up，客户端程序去访问服务端程序，就会出现connection refused，但是客户端去ping服务端是正常的，此时重启服务端程序后，又恢复正常。

q1208c

回复 3# sky__hook

你有试过只使用物理网卡时，down掉物理网卡的情况么？

一般来说，在管理上，很少会在同一块网卡上绑定多个IP或者多个网段的IP。
更一般的做法是使用 vlan。

我对程序设计不是太了解，不知道应用层的程序是怎么设置为监听物理层的网卡的。

sky__hook

回复 4# q1208c

只使用物理网卡都是正常的。
服务端节点有高可用keepalived的时候，工作节点会增加一个高可用VIP的，这个时候业务网卡（bond0）就会有两个IP。

另外，ifenslave有个限制就是，
当你ifdown bond0后，bond0、P9P1、P9P2都会down掉，
然后必须要先ifup P9P1或者ifup P9P2，bond0也会同时启动，如果先ifup bond0就会出现提示有60s等待时间等待P9P1或者P9P2启动，否则就会出现bond0异常。

另外测试发现，如果用命令ifconfig bond0 down的时候，不会同时down掉P9P1和P9P2，而且ifconfig bond0 up后也没有出现connetion refused的问题。

q1208c

回复 5# sky__hook

个人觉得, 你的环境被人为的搞得很复杂.

keepalived 本来应该 在上一层.

你把太多的功能加在了同一台服务器,很不利于管理.

sky__hook

q1208c 发表于 2017-11-21 15:39
回复 5# sky__hook

个人觉得, 你的环境被人为的搞得很复杂.

你说的keepalived在上一层什么意思呢？高可用的虚IP总是要落在一个工作节点吧，这里只是把聚合网卡当成工作节点的业务网卡了，不都是这么用么

q1208c

回复 7# sky__hook

我自己一般会单独搞一组机器来专门处理 转发。
这一层由于是单台，所以， 需要keepalived。

sky__hook

q1208c 发表于 2017-11-22 21:49
回复 7# sky__hook

我自己一般会单独搞一组机器来专门处理 转发。

多谢了，只能再看看ifenslave的聚合机制了。