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伺服器。