ipvsadm和keepalived的關(guān)系？

sjzwyb

在配置過程中對這兩個工具產(chǎn)生了疑問：keepalived的配置文件中也有負(fù)載均衡的配置，那還需要安裝ipvsadm不？若還安裝的話，能只用keepalived實現(xiàn)負(fù)載均衡嗎？還是只能實現(xiàn)高可用？請高手指點！

haide1014

keepalived只用于做心跳檢測，ipvsadm負(fù)責(zé)負(fù)載分發(fā)。

haide1014

       負(fù)載均衡在很多人眼里可能是集群架設(shè)的基礎(chǔ)，可能會有人覺得負(fù)載均衡后端的真實服務(wù)器越多處理速度越快，當(dāng)然這種想法是正確的，但是這是建立在不考慮LB服務(wù)器的負(fù)載模式和掛在負(fù)載均衡服務(wù)器后面的數(shù)據(jù)庫服務(wù)器處理速度的前提下的，下面我介紹一個我自己的經(jīng)歷吧：
       我們的一個業(yè)務(wù)之前一直是由一個tomcat再運行，基本上沒什么架構(gòu)可談，簡單的client—-tomcat—-oracle這樣的一個順序。直到有一天，我們的tomcat頻繁的當(dāng)機，用netstat命令查看鏈接數(shù)處于ESTABLISHED狀態(tài)的有1000~2000個！好吧！我這里吐槽一下，我來這里之前這里的16G內(nèi)存的Linux服務(wù)器居然用的是32位的OS��！
       我調(diào)過了tomcat和JVM的基本設(shè)置，但是受限于32位OS的內(nèi)存和句柄限制，對于業(yè)務(wù)也沒有什么明顯的緩解，于是開始著手搭建負(fù)載均衡（PS當(dāng)時沒有空閑的服務(wù)器進(jìn)行替換）。
       一上來由于沒有其它的服務(wù)器能夠立刻上線，又因為32位的操作系統(tǒng)浪費了大量的內(nèi)存，所以我就用了一個奇葩的單機多實例- -（請不要學(xué)我，這里對于單點故障完全沒有任何益處）我在服務(wù)器上同時運行了4個tomcat（因為在32位的OS上一個JVM最大只能占用2G的內(nèi)存，開啟多個JVM可以適當(dāng)?shù)奶嵘齼?nèi)存的利用率）和1個負(fù)載均衡的程序，這里我試驗過varnish、nginx和現(xiàn)在正在使用的haproxy（最后因為開發(fā)要求獲取一個數(shù)據(jù)所以又換回了nginx）。
       一開始雖然運行了4個tomcat但是OS的限制依舊很明顯，但是處理隊列的增加明顯的減少了運行隊列的等待情況，鏈接數(shù)也有原來的6000+變到了2000附近，處于ESTABLISHED狀態(tài)的鏈接更是減少到了400附近。

       就這樣又平穩(wěn)的運行了一個多月，終于新的服務(wù)器到位了，OS也換成了64位的了。于是我把之前的4個tomcat遷移到了新的服務(wù)器上，于是乎新的問題出現(xiàn)了。由于新服務(wù)器（應(yīng)該和64位的OS有關(guān)系）處理能力的提升，雖然處理速度變快了，但是后面的數(shù)據(jù)庫卻出現(xiàn)了明顯的壓力。
       通過觀察和測試，平均我每啟動一個tomcat，數(shù)據(jù)庫服務(wù)器的負(fù)載壓力立刻就會提升10（load average），用vmstat命令看R的增長也在10左右。于是原來的4個tomcat直接就把負(fù)載在10以內(nèi)的數(shù)據(jù)庫服務(wù)器壓到了40，這還是非高峰期！
       鑒于這種情況再DBA的協(xié)助調(diào)整下（這里不得不再說一下這個悲劇一樣的數(shù)據(jù)庫設(shè)計，各種大表連鎖查詢），一方面對于數(shù)據(jù)庫做了些優(yōu)化，但是效果不明顯，所以我把tomcat的數(shù)量削減到了2個，就這樣到現(xiàn)在運行了1周的時間里面訪問速度不但比之前的4個tomcat負(fù)載還要好，服務(wù)器也幾乎沒有出現(xiàn)過程序故障（這里再吐槽一下DELL R710的網(wǎng)卡驅(qū)動太和諧了）。
       到這里這個問題也就基本上解決了，負(fù)載均衡雖然可以增加處理隊列，增加對請求的處理速度，但是再搭建的同時也要考慮一下應(yīng)用對數(shù)據(jù)庫的負(fù)載壓力。只有找到一個良好的平衡點才能讓業(yè)務(wù)運行又快又平穩(wěn)！