一直以來都是用nginx的upstream模組做網站最前端的負載均衡，為了防止nginx本身當機導致網站不能訪問，通常都會做兩套nginx反向代理，然後用keepalive之類的軟體提供VIP。

常見的環境是nginx主節點和從節點各有一個公網IP，一個私有IP，VIP地址也使用公網IP來提供，正常情況下VIP只會在nginx主節點上工作，只有主節點當機或者網路不可達等情況下，VIP才會漂移到nginx從節點上。如果keepalive配置了非搶佔模式，則主節點恢復後，VIP也不會漂移會主節點，而是繼續在從節工作。這種配置要求機房網路不做mac地址繫結。

最近做的兩套培訓系統測試情況如下:

系統一：主從節點做雙網路卡繫結，都只有一個私有IP，VIP也為私有IP，通過防火牆的NAT轉發使用者的訪問請求。主節點當機後，VIP可以漂移至從節點，但使用者無法訪問網站，telnet防火牆公網IP的80埠提示無法連線。

系統二：主從節點各有兩張網路卡，分別配置一個公網IP和一個私有IP。VIP地址也使用公網IP來提供。

主節點當機後，VIP可以漂移至從節點，但使用者無法ping通VIP，自然網站也就打不開。

於是分別對這兩種情況進行排查：

系統二：屬於比較常見的配置方案。VIP漂移後無法ping通，第一反應詢問機房工作人員，是否相應的裝置做了mac地址繫結。得知無繫結策略後繼續排查。

發現配置net.ipv4.ip_nonlocal_bind = 1 引數並使其生效後重新測試正常。

系統一：情況有點特殊，按系統二的解決方法嘗試無果後，懷疑埠路由器對映上出現問題。於是繼續測試VIP漂移，發現VIP漂移到從節點後，防火牆上的arp表中vip對應的mac地址依舊是主節點網路卡的mac地址，原來防火牆才是罪魁禍首，坑爹的貨。機房使用的防火牆型號華為Quidway Eudemon1000E，據說預設配置下，這個arp地址表自動重新整理需要20分鐘！

好吧！於是用下面的命名手工重新整理後，萬事大吉，網站訪問也很順暢，比較鬱悶的是當主節點重新搶佔VIP後，依然需要手工重新整理下，否則防火牆還是把請求轉給從節點響應。

# arping -I 網路卡地址 -c 3 -s VIP地址 閘道器地址

後記：

要徹底解決系統一的問題，可以從兩方面去著手，首先是考慮去調整防火牆的arp表的自動重新整理時間；其次是考慮在從節點上部署一個無限迴圈的指令碼，時時去檢測是否搶佔到了VIP，若搶佔成功，則執行前面的重新整理命令，命令成功執行後退出指令碼，同時可以用nagios監控該指令碼，瞭解最新的主從切換情況。切記，迴圈執行一次接受後sleep 1秒，否則會當機的哦！

如果在主節點上也部署類似的指令碼，則會對網路帶來負擔，因而主節點恢復後的重新整理手工執行下就好了，如果忘記執行了，從節點依然可以工作，無傷大雅！