【LVS】简介与说明
一、IPVS的三種負載均衡技術
- 通過NAT實現虛擬服務器(VS/NAT)
?
客戶通過Virtual IP Address(虛擬服務的IP地址)訪問網絡服務時,請求報文到達調度器,調度器根據連接調度算法從一組真實服務器中選出一臺服務器,將報文的目標地址 Virtual IP Address改寫成選定服務器的地址,報文的目標端口改寫成選定服務器的相應端口,最后將修改后的報文發送給選出的服務器。同時,調度器在連接Hash 表中記錄這個連接,當這個連接的下一個報文到達時,從連接Hash表中可以得到原選定服務器的地址和端口,進行同樣的改寫操作,并將報文傳給原選定的服務 器。當來自真實服務器的響應報文經過調度器時,調度器將報文的源地址和源端口改為Virtual IP Address和相應的端口,再把報文發給用戶。我們在連接上引入一個狀態機,不同的報文會使得連接處于不同的狀態,不同的狀態有不同的超時值。在TCP 連接中,根據標準的TCP有限狀態機進行狀態遷移,這里我們不一一敘述,請參見W. Richard Stevens的《TCP/IP Illustrated Volume I》;在UDP中,我們只設置一個UDP狀態。不同狀態的超時值是可以設置的,在缺省情況下,SYN狀態的超時為1分鐘,ESTABLISHED狀態的超 時為15分鐘,FIN狀態的超時為1分鐘;UDP狀態的超時為5分鐘。當連接終止或超時,調度器將這個連接從連接Hash表中刪除。
這樣,客戶所看到的只是在Virtual IP Address上提供的服務,而服務器集群的結構對用戶是透明的。對改寫后的報文,應用增量調整Checksum的算法調整TCP Checksum的值,避免了掃描整個報文來計算Checksum的開銷。
?
- 通過IP隧道實現虛擬服務器(VS/TUN)
?
VS/TUN 的工作流程如圖5所示:它的連接調度和管理與VS/NAT中的一樣,只是它的報文轉發方法不同。調度器根據各個服務器的負載情況,動態地選擇一臺服務器, 將請求報文封裝在另一個IP報文中,再將封裝后的IP報文轉發給選出的服務器;服務器收到報文后,先將報文解封獲得原來目標地址為VIP的報文,服務器發 現VIP地址被配置在本地的IP隧道設備上,所以就處理這個請求,然后根據路由表將響應報文直接返回給客戶。
在這里需要指出,根據缺省的TCP/IP協議棧處理,請求報文的目標地址為VIP,響應報文的源地址肯定也為VIP,所以響應報文不需要作任何修改,可以直接返回給客戶,客戶認為得到正常的服務,而不會知道究竟是哪一臺服務器處理的。
?
- 通過直接路由實現虛擬服務器(VS/DR)
?
VS/DR 的工作流程:它的連接調度和管理與VS/NAT和VS/TUN中的一樣,它的報文轉發方法又有不同,將報文直接路由給目標服務器。在VS/DR 中,調度器根據各個服務器的負載情況,動態地選擇一臺服務器,不修改也不封裝IP報文,而是將數據幀的MAC地址改為選出服務器的MAC地址,再將修改后 的數據幀在與服務器組的局域網上發送。因為數據幀的MAC地址是選出的服務器,所以服務器肯定可以收到這個數據幀,從中可以獲得該IP報文。當服務器發現 報文的目標地址VIP是在本地的網絡設備上,服務器處理這個報文,然后根據路由表將響應報文直接返回給客戶。
?
二、IPVS在內核中實現的八種連接調度算法
- 輪叫調度(Round-Robin Scheduling)
- 加權輪叫調度(Weighted Round-Robin Scheduling)
- 最小連接調度(Least-Connection Scheduling)
- 加權最小連接調度(Weighted Least-Connection Scheduling)
- 基于局部性的最少鏈接(Locality-Based Least Connections Scheduling)
- 帶復制的基于局部性最少鏈接(Locality-Based Least Connections with Replication Scheduling)
- 目標地址散列調度(Destination Hashing Scheduling)
- 源地址散列調度(Source Hashing Scheduling)
轉載于:https://www.cnblogs.com/xialiaoliao0911/p/8630386.html
總結
以上是生活随笔為你收集整理的【LVS】简介与说明的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: Android双列表联动和固定头部Scr
- 下一篇: 2 - Hexo + GitHub 搭建