談談VIP漂移那點破事

2021-09-05 06:51:31 字數 1139 閱讀 1024

一直以來都是用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埠提示無法連線。

主節點宕機後,vip可以漂移至從節點,但使用者無法ping通vip,自然**也就打不開。

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

發現配置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秒,否則會宕機的哦!

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

談談VIP漂移那點破事

一直以來都是用nginx的upstream模組做 最前端的負載均衡,為了防止nginx本身宕機導致 不能訪問,通常都會做兩套nginx反向 然後用keepalive之類的軟體提供vip。常見的環境是nginx主節點和從節點各有乙個公網ip,乙個私有ip,vip位址也使用公網ip來提供,正常情況下vi...

SPI匯流排那點破事

spi為序列外設介面的縮寫,spi為高速全雙工同步通訊匯流排,共使用4根線。spi以主從方式工作,通常可以乙個主裝置和乙個或多個從裝置。需要至少4根線。miso 主裝置資料輸入 mosi 主裝置資料輸出 sclk 時鐘 cs 片選 cs是從裝置是否被主裝置選中的引腳,當被選中時 通常以cs為低電平選...

關於虛函式那點破事

如果你是c 程式設計師,我想你可能遇到過這樣的情況 在debug時,對著乙個函式step into,明明呼叫的是a函式,可是結果卻跳進了b函式。為什麼,call stack裡顯示的也是明明白白,就是直接進了b函式。百思不得其解,於是你懷疑是不是系統出了問題,是不是編譯器出了問題,是不是偵錯程式出了問...