LVS負載均衡之session解決方案

2021-09-20 17:42:16 字數 2525 閱讀 6202

lvs負載均衡之session解決方案

1. 持久連線是什麼?

1.1 在lvs中,持久連線是為了用來保證當來自同乙個使用者的請求時能夠定位到同一臺伺服器。

2. 為什麼會用到持久連線?

2.1 cookie/session機制的簡單說明:

在web服務通訊中,http本身是無狀態協議,不能標識使用者**,此時出現了乙個問題,當使用者在乙個**瀏覽了a網頁並跳轉到b網頁,此時伺服器就認為b網頁是乙個新的使用者請求,你之前的登陸的資訊就都丟失了,頭疼。為了記錄使用者的會話資訊,我們的開發者就在客戶端/伺服器端軟體提供了cookie/session機制,當你訪問**時,伺服器端建立乙個session會話區,並建立乙個cookie與這個session繫結,將資訊傳送給你的瀏覽器。這樣,只要你的cookie存在,伺服器端的session存在,那麼當你開啟新頁面的時候,伺服器依然會認識你!

2.2 cookie/session由負載均衡導致的問題:

上面說伺服器需要靠session/cookie來標記使用者的會話,這沒什麼問題。不過,當你在做了負載均衡的時候,就出現了問題。

我們依然假設乙個場景:某電商**為了實現更多使用者的訪問,提供了a、b兩台伺服器,並在前面做了lvs負載均衡。於是某使用者開啟了某購物**,選中了一件衣服,並加入了購物車(此時背後的操作是:lvs負載均衡器接受了使用者請求,並將其分發到了選中的伺服器,並將使用者新增了一件衣服記錄到這個會話的session中)。這時當使用者開啟了第二個網頁,又選中了一件帽子並加入購物車(此時背後的操作是:lvs負載均衡器接受了使用者請求,進行計算,將其傳送到選中的伺服器上,該伺服器將使用者新增了一件帽子記錄到session中)。

到現在可能各位已經發現問題了,由於lvs是乙個四層負載均衡器,僅能根據ip:port對資料報文進行分發,不能確保將同一使用者根據session發往同乙個伺服器,也就是使用者第一次被分配到了a伺服器,而第二次可能分配到了b伺服器,但是b伺服器並沒有a伺服器使用者的session記錄,直接導致這個例子裡的使用者發現自己的購物車沒有了之前的衣服,而僅有帽子。這是不可接受的。為了避免上面的問題,生產環境中一般有三種方案:

2.2.1 將來自於同乙個使用者的請求發往同乙個伺服器

2.2.2 將session資訊在伺服器集群內共享,每個伺服器都儲存整個集群的session資訊

2.2.3 建立乙個session儲存池,所有session資訊都儲存到儲存池中

顯然,第一種方案是最簡單,也是最節約資源的,而持久連線和sh演算法就是實現第一種方案的兩種方式。由於sh的應用並不是太多,我們僅僅介紹一下其和持久連線的區別,其他的就不講述了,有興趣的朋友可以自行查詢資料。

3. lvs的sh演算法和持久連線:

sh演算法全稱為source hash(源位址hash),它和持久連線的作用都是"將來自同乙個ip的請求都**到同乙個server",從而保證了session會話定位的問題。兩者的不同是:

(1)sh演算法:使用sh演算法,sh演算法在核心中會自動維護乙個雜湊表,此雜湊表中用每乙個請求的源ip位址經過雜湊計算得出的值作為鍵,把請求所到達的rs的位址作為值。在後面的請求中,每乙個請求會先經過此雜湊表,如果請求在此雜湊表中有鍵值,那麼直接定向至特定rs,如沒有,則會新生成乙個鍵值,以便後續請求的定向。但是此種方法在時間的記錄上比較模糊(依據tcp的連線時長計算),而且其是演算法本身,所以無法與演算法分離,並不是特別理想的方法。

(2)持久連線:此種方法實現了無論使用哪一種排程方法,持久連線功能都能保證在指定時間範圍之內,來自於同乙個ip的請求將始終被定向至同乙個rs,還可以把多種服務繫結後統一進行排程。

詳細一點說:當使用者請求到達director時。無論使用什麼排程方法,都可以實現對同乙個服務的請求在指定時間範圍內始終定向為同乙個rs。在director內有乙個lvs持久連線模板,模板中記錄了每乙個請求的**、排程至的rs、維護時長等等,所以,在新的請求進入時,首先在此模板中檢查是否有記錄(有內建的時間限制,比如限制是300秒,當在到達300秒時依然有使用者訪問,那麼持久連線模板就會將時間增加兩分鐘,再計數,依次類推,每次只延長2分鐘),如果該記錄未超時,則使用該記錄所指向的rs,如果是超時記錄或者是新請求,則會根據排程演算法先排程至特定rs,再將排程的記錄新增至此表中。這並不與sh演算法衝突,lvs持久連線會在新請求達到時,檢查後端rs的負載狀況,這就是比較精細的排程和會話保持方法。

4. lvs的三種持久連線方式:

(1)pcc:每客戶端持久;將來自於同乙個客戶端的所有請求統統定向至此前選定的rs;也就是只要ip相同,分配的伺服器始終相同。

(2)ppc:每埠持久;將來自於同乙個客戶端對同乙個服務(埠)的請求,始終定向至此前選定的rs。例如:來自同乙個ip的使用者第一次訪問集群的80埠分配到a伺服器,25號埠分配到b伺服器。當之後這個使用者繼續訪問80埠仍然分配到a伺服器,25號埠仍然分配到b伺服器。

(3)pfmc:持久防火牆標記連線;將來自於同一客戶端對指定服務(埠)的請求,始終定向至此選定的rs;不過它可以將兩個毫不相干的埠定義為乙個集群服務,例如:合併http的80埠和https的443埠定義為同乙個集群服務,當使用者第一次訪問80埠分配到a伺服器,第二次訪問443埠時仍然分配到a伺服器。

5.定義lvs持久連線:

lvs的持久連線功能需要定義在集群服務上面,使用-p timeout選項。

負載均衡之lvs

集群 cluster 將一組計算機軟 硬體連線起來,高度緊密的協作完成計算工作,其中的單個計算機通常稱為節點。負載均衡集群 load balancing 通過負載均衡器,將負載盡可能平均分攤處理。lvs linux virtul server linux虛擬服務,分為三層結構 排程器 上面的虛擬ip...

負載均衡之LVS

lvs是四層負載均衡器,linux2.4核心以後天然支援 核心的一部分 其網路架構如下所示 備註 lvs對外暴露的公網ip叫做 vip nat模式 nat network address translation 網路位址轉換,即將乙個ip位址轉換為另乙個ip位址的技術,如下圖所示 lvs接收到請求,...

負載均衡之LVS詳解

負載均衡 四層負載均衡 lvs 之前也寫過相關的文章,但是寫的太爛了。自己都不也敢直視。現在有空決定重新全面學習了下lvs.總結出本部落格。好了,其他的不多說了,我們開始吧。一 負載均衡 負載均衡包括如下 1 硬體負載均衡 f5,big ip citrix,netscaler a102 軟體負載均衡...