溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
本文小編為大家詳細介紹“LVS的環境怎么搭建”，內容詳細，步驟清晰，細節處理妥當，希望這篇“LVS的環境怎么搭建”文章能幫助大家解決疑惑，下面跟著小編的思路慢慢深入，一起來學習新知識吧。
LVS是Linux Virtual Server的簡寫，意即Linux虛擬服務器，是一個虛擬的服務器集群系統，目的在于使用集群技術和Linux操作系統實現一個高性能、高可用的服務器。它具有良好的可靠性，可拓展性和可操作性。從而以低廉的成本實現最優的性能。
1. DS：Director Server。指的是前端負載均衡器節點。 2. RS：Real Server。后端真實的工作服務器。 3. VIP：向外部直接面向用戶請求，作為用戶請求的目標的IP地址。 4. DIP：Director Server IP，主要用于和內部主機通訊的IP地址。 5. RIP：Real Server IP，后端服務器的IP地址。 6. CIP：Client IP，訪問客戶端的IP地址。
\1. 直接路由模式（DR）
原理：負載均衡器和RS都使用同一個IP對外服務?但只有DR對ARP請求進行響應，所有RS對本身這個IP的ARP請求保持靜默。也就是說，網關會把對這個服務IP的請求全部定向給DR，而DR收到數據包后根據調度算法，找出對應的RS，把目的MAC地址改為RS的MAC（因為IP一致）并將請求分發給這臺RS。這時RS收到這個數據包,處理完成之后，由于IP一致，可以直接將數據返給客戶，則等于直接從客戶端收到這個數據包無異，處理后直接返回給客戶端。由于負載均衡器要對二層包頭進行改換,所以負載均衡器和RS之間必須在一個廣播域，也可以簡單的理解為在同一臺交換機上。
優點：負載均衡器只是分發請求，應答包通過單獨的路由方法返回給客戶端。
缺點：要求負載均衡器的網卡必須與物理網卡在一個物理段上。
\2. NAT模式（NAT）
原理：就是把客戶端發來的數據包的IP頭的目的地址，在負載均衡器上換成其中一臺RS的IP地址，并發至此RS來處理，RS處理完成后把數據交給經過負載均衡器，負載均衡器再把數據包的原IP地址改為自己的IP，將目的地址改為客戶端IP地址即可。期間，無論是進來的流量,還是出去的流量，都必須經過負載均衡器。
優點：集群中的物理服務器可以使用任何支持TCP/IP操作系統。
缺點：擴展性差。當服務器節點（普通PC服務器）增長過多時，負載均衡器將成為整個系統的瓶頸，因為所有的請求包和應答包的流向都經過負載均衡器。當服務器節點過多時，大量的數據包都交匯在負載均衡器處，導致負載均衡器變慢以至于整個鏈路變慢。
\3. IP隧道模式（TUN）
原理：隧道模式就是，把客戶端發來的數據包，封裝一個新的IP頭標記(僅目的IP)發給RS，RS收到后，先把數據包的頭解開，還原數據包，處理后直接返回給客戶端，不需要再經過負載均衡器。注意，由于RS需要對負載均衡器發過來的數據包進行還原，所以說必須支持IPTUNNEL協議。因此，在RS的內核中，必須編譯支持IPTUNNEL這個選項。
優點：負載均衡器只負責將請求包分發給后端節點服務器，而RS將應答包直接發給用戶，減少了負載均衡器的大量數據流動，負載均衡器不再是系統的瓶頸，就能處理很巨大的請求量，這種方式，一臺負載均衡器能夠為很多RS進行分發。而且跑在公網上就能進行不同地域的分發。
缺點：隧道模式的RS節點需要合法IP，這種方式需要所有的服務器支持“IP Tunneling”(IP Encapsulation)協議，服務器可能只局限在部分Linux系統上。
\1. LVS負載均衡的調度算法一（靜態）
輪循調度（rr, Round Robin） 調度器通過“輪循”調度算法將外部請求按順序輪流分配到集群中的真實機器上，它均等的對待每一臺服務器，而不管服務器實際的連接數和系統負載。
加權輪循（wrr, Weighted Round Robin） 調度器通過“加權輪循”調度算法根據真實服務器的不同處理能力來調度訪問請求。這樣可以保證處理能力強的服務器能處理更多的訪問流量。調度器可以自動問詢真實服務器的負載情況，并動態的調整其權值。
目標地址散列（DH, Destination Hashing） “目標地址散列”調度算法根據請求的目標IP地址，作為散列鍵（Hash Key）從靜態分配的散列列表找出對應的服務器，若該服務器是可用的且未超載，將請求發送到該服務器，否則返回空。
源地址散列（SH, Source Hashing） “源地址散列”調度算法根據請求的源IP地址，作為散列鍵（Hash Key）從靜態分配的散列表找到對應的服務器，若該服務器是可用的且未超載，將請求發送到該服務器，否則返回空。
\2. LVS負載均衡的調度算法二（動態）
最少鏈接（LC, Least Connections） 調度器通過“最少鏈接”調度算法動態的將網絡請求調度到已建立的鏈接數最少的服務器上。如果集群系統的真實服務器具有相近的系統性能，采用“最少連接”調度算法可以較好的均衡負載。 OL(Over Load)=active * 256 + deactive
加權最少鏈接（WLC, Weighted Least Connections） 在集群系統中的服務器性能差異較大的情況下，調度器采用“加權最少連接”調度算法優化負載均衡性能，具有較高權值的服務器將承受較大比例的活動連接負載。調度器可以自動問詢真實服務器的負載情況，并動態的調整其權值。 OL(Over Load)=(active * 256 + deactive) / weighted
最短的期望延遲（SED, Shortest Expected Delay Scheduling）
最少隊列調度（NQ, Never Queue Scheduling） 無需排隊。如果有臺Real Server的連接數等于0就直接分配過去，不需要再進行SED運算。
基于局部性的最少鏈接（LBLC, Locality-Based Least Connections） “基于局部性的最少連接”調度算法是針對目標IP地址的負載均衡，目前主要用于Cache集群系統。該算法根據請求的目標IP地址找出該目標IP最近使用的服務器，若該服務器是可用的且沒有超載，將請求發送到該服務器；若服務器不存在，或者該服務器超載且有服務器處于一半的工作負載，則用“最少連接”的原則選出一個可用的服務器，將請求發送到該服務器。
帶復制的基于局部性最少鏈接（LBLCR, Locality-Based Least Connections with Repilcation） “帶復制的基于局部性最少連接”調度算法也是針對目標IP地址的負載均衡，目前主要用于Cache集群系統。它與LBLC算法的不同之處是它要維護從一個目標IP地址到一組服務器的映射，而LBLC算法維護從一個目標IP地址到一臺服務器的映射。該算法根據請求的目標IP地址找出該目標IP地址對應的服務器組，按“最少連接”原則從服務器組中選出一臺服務器，若服務器沒有超載，將請求發到該服務器；若服務器超載，則按“最少連接”原則從這個集群中選出一臺服務器，將該服務器加入到服務器組中，將請求發送到該服務器。同時，當該服務器組有一段時間沒有被修改，將最忙的服務器從服務器組中刪除，以降低復制的程度。
實驗環境：CentOS6.5，關閉iptables/selinux Client: 172.16.1.100 Director Server: eth0 - 192.168.1.100 eth2 - 172.16.1.101 (VIP) RealServer01: 192.168.1.101 RealServer02: 192.168.1.102
1、RS配置：
a. 兩臺RS的網卡配置中網關均配置為DS的eth0 IP: 192.168.1.100 b. 因為沒有做共享存儲，只在各自的主頁文件中加入不同信息以示區別： RealServer01 # echo "RealServer01" > /var/log/index.html RealServer02 # echo "RealServer02" > /var/log/index.html
2、DS配置：
a) 開啟ipv4轉發
# vi /etc/sysctl.confnet.ipv4.ip_forward = 1 b) 安裝啟動ipvsadm# yum install ipvsadm -y# service ipvsadm start
c) 增加規則
# ipvsadm -A -t 172.16.1.101:80 -s rr# ipvsadm -a -t 172.16.1.101:80 -r 192.168.1.101 -m -w 1# ipvsadm -a -t 172.16.1.101:80 -r 192.168.1.102 -m -w 2 d) 查看并保存 [root@director ~]# ipvsadm -L -nIP Virtual Server version 1.2.1 (size=4096) Prot LocalAddress:Port Scheduler Flags -> RemoteAddress:Port Forward Weight ActiveConn InActConn TCP 172.16.1.101:80 rr -> 192.168.1.101:80 Masq 1 0 0 -> 192.168.1.102:80 Masq 2 0 0 [root@director ~]# service ipvsadm saveipvsadm: Saving IPVS table to /etc/sysconfig/ipvsadm: [確定]
e) 在Client測試的結果 rr調度算法結果：
wrr調度算法結果：
# ipvsadm -E -t 172.16.1.101:80 -s wrr
ab命令基本參數：
-n 執行的請求數量 -c 并發請求個數 其它參數： -t 測試所進行的最大秒數 -p 包含了需要POST的數據的文件 -T POST數據所使用的Content-type頭信息 -k 啟用HTTP KeepAlive功能，即在一個HTTP會話中執行多個請求，默認時，不啟用KeepAlive功能
測試案例：
# yum -y install httpd-tools # ab -c 10 -n 10000
# 測試完成進度Benchmarking 172.16.1.101 (be patient) Completed 100 requests Completed 200 requests Completed 300 requests Completed 400 requests Completed 500 requests Completed 600 requests Completed 700 requests Completed 800 requests Completed 900 requests Completed 1000 requests Finished 1000 requests Server Software: Apache/2.2.15 Server Hostname: 172.16.1.101 Server Port: 80 Document Path: /index.html # 請求的資源Document Length: 14 bytes #返回的長度Concurrency Level: 10 # 并發個數Time taken for tests: 0.262 seconds # 總請求時間Complete requests: 1000 # 總請求數Failed requests: 0 # 失敗的請求數Write errors: 0 Total transferred: 280840 bytes HTML transferred: 14042 bytes Requests per second: 3816.98 [#/sec] (mean) # 平均每秒的請求數Time per request: 2.620 [ms] (mean) # 平均每個請求消耗的時間Time per request: 0.262 [ms] (mean, across all concurrent requests) Transfer rate: 1046.84 [Kbytes/sec] received # 傳輸速率Connection Times (ms) min mean[+/-sd] median max Connect: 0 1 0.4 1 3 Processing: 1 2 0.6 1 7 Waiting: 0 1 0.6 1 4 Total: 1 3 0.8 2 7 Percentage of the requests served within a certain time (ms) 50% 2 # 50%的requests都在2ms內完成 66% 3 75% 3 80% 3 90% 4 95% 4 98% 4 99% 5 100% 7 (longest request)
說明：由于缺乏實際requests，無法模擬其它動態調度算法的效果，暫時記錄到這里。
讀到這里，這篇“LVS的環境怎么搭建”文章已經介紹完畢，想要掌握這篇文章的知識點還需要大家自己動手實踐使用過才能領會，如果想了解更多相關內容的文章，歡迎關注億速云行業資訊頻道。
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
