一直以來都是用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函式。百思不得其解，於是你懷疑是不是系統出了問題，是不是編譯器出了問題，是不是偵錯程式出了問...