站長資訊網1.1 LVS簡介
LVS（Linux Virtual Server），也就是Linux虛擬服務器, 是一個自由軟件項目。使用LVS技術要達到的目標是：通過LVS提供的負載均衡技術和Linux操作系統實現一個高性能、高可用的服務器群集，它具有良好可靠性、可擴展性和可操作性。從而以低廉的成本實現最優的服務性能。
LVS主要用來做四層負載均衡。
1.2 Keepalived簡介
Keepalived是分布式部署系統解決系統高可用的軟件，結合LVS（Linux Virtual Server）使用，其功能類似于heartbeat，解決單機宕機的問題。
Keepalived是以VRRP協議為實現基礎的，VRRP全稱Virtual Router Redundancy Protocol，即虛擬路由冗余協議。通過VRRP協議結合LVS，對組群服務器監控情況，若master出現宕機情況，則將VIP漂移到backup機上。實現了分布式系統高可用?？梢岳斫鉃椋簁eepalived是LVS的管理軟件，根據監控情況，將宕機服務器從ipvsadm移除掉。
Keepalived的誕生最初是為LVS ipvs（director）提供高可用性的，后來發展一個多功能、通用的輕量級高可用組件，可以為ipvs、nginx、haproxy等諸多服務提供高可用功能，主要應用在負載均衡調度器上，同時也可以檢查后端各realserver的健康狀態。
1.3 負載均衡
四層負載均衡工作在OSI模型的傳輸層，由于在傳輸層，只有TCP/UDP協議，這兩種協議中除了包含源IP、目標IP以外，還包含源端口號及目的端口號。四層負載均衡服務器在接受到客戶端請求后，以后通過修改數據包的地址信息（IP+端口號）將流量轉發到應用服務器。
七層負載均衡工作在OSI模型的應用層，應用層協議較多，常用http、radius、dns等。七層負載就可以基于這些協議來負載。這些應用層協議中會包含很多有意義的內容。比如同一個Web服務器的負載均衡，除了根據IP加端口進行負載外，還可根據七層的URL、瀏覽器類別、語言來決定是否要進行負載均衡。
四層通過虛擬 IP + 端口接收請求，然后再分配到真實的服務器，七層通過虛擬的 URL 或主機名接收請求，然后再分配到真實的服務器。所謂的四到七層負載均衡，就是在對后臺的服務器進行負載均衡時，依據四層的信息或七層的信息來決定怎么樣轉發流量。
2. 搭建過程及測試
2.1 主機配置
|
主機名
|
ip
|
操作系統
|
軟件
|
端口
|
|
lvs01
|
10.1.28.253
|
CentOS 7.0
|
lvs keepalived
|
8080
|
|
lvs02
|
10.1.28.70
|
CentOS 7.0
|
lvs keepalived
|
8080
|
|
Nginxsever01
|
10.1.28.30
|
CentOS 7.0
|
nginx
|
8080
|
|
Nginxsever01
|
10.1.28.40 | CentOS 7.0 | nginx | 8080 |
2.3 搭建準備
2.3.1 關閉所有機器防火墻
[root@lvs01 ~]#systemctl stop firewalld.service
2.3.2 關閉防selinux
關閉所有服務器selinux，修改/etc/selinux/config，將SELINUX由enforcing設置為disabled，重啟服務器。
2.4 ipvs安裝
LVS無需安裝，安裝的是管理工具，第一種叫ipvsadm，第二種叫keepalive。ipvsadm是通過命令行管理，而keepalive讀取配置文件管理。
分別在lvs01和lvs02執行如下操作：
[root@lvs01 ~]# yum -y install ipvsadm
2.4.1 把模塊加載進系統
[root@lvs01 ~]#ipvsadm
2.5 keepalived安裝
分別在lvs01和lvs02執行如下操作：
[root@lvs01 ~]# yum -y install keepalived
2.6 keepalived配置
! Configuration File for keepalived
global_defs {
router_id MASTER ## keepalived 服務器標識符，可以隨意設定（ 貌似也是全局唯一 ）
}
vrrp_instance VI_1 { ## 定義一個名為 VI_1 的 VRRP 實例
state MASTER ## Keepalived 服務器角色，MASTER 為主、BACKUP 為備
interface eth0 ## 指定 HA 監測網絡接口
virtual_router_id 51 ## 虛擬路由標識，同一個 VRRP 實例使用唯一的標識，主備必須一樣
priority 100 ## 節點優先級，同一 VRRP 實例中 MASTER 的優先級必須大于 BACKUP
advert_int 1 ## MASTER / BACKUP 之間同步檢查間隔時間，單位 秒
authentication { ## 節點之間通信驗證類型、密碼 ，同一 VRRP 實例中，MASTER / BACKUP 必須使用相同的密碼才可以通信
auth_type PASS
auth_pass 123456
}
virtual_ipaddress { ## 虛擬 IP 地址，又稱漂移 IP ?？梢酝ㄟ^ ip add 在 MASTER 上查看是否綁定
10.1.28.123
}
}
virtual_server 10.1.28.123 8080 { ## 定義虛擬服務器
delay_loop 6 ## 定義健康檢查時間間隔，單位 秒
lb_algo rr ## 負載均衡調度算法，支持 rr 、wrr 、lc 、wlc 、lblc 、sh 、dh 等
lb_kind DR ## LVS 負載均衡機制，支持 NAT 、TUN 、DR
persistence_timeout 120 ## 會話保持時間，單位 秒。提供動態頁面 session 保持功能，同一 IP 該值時間內被持續分配到同一臺節點服務器上
protocol TCP ## 轉發協議類型，支持 TCP 、UDP
real_server 10.1.28.30 8080 { ## 定義節點服務器
weight 1 ## 節點權重值，數字越大權重越高，分配到的連接越多。主要用于后端節點服務器性能不統一
notify_down /etc/keepalived/real_down.sh ## 該節點服務器處于 DOWN 狀態后執行的腳本
TCP_CHECK { ## 健康檢測方式，支持 HTTP_GET 、SSL_GET 、TCP_CHECK 、SMTP_CHECK 、MISC_CHECK
connect_port 8080 ## 檢測端口，不指定時默認為 real_server 指定的端口
connect_timeout 3 ## 無響應超時時間，單位 秒
nb_get_retry 3 ## 重試次數
delay_before_retry 3 ## 重試間隔，單位 秒
}
}
real_server 10.1.28.40 8080 { ## 第二臺節點服務器
weight 1
notify_down /etc/keepalived/real_down.sh
TCP_CHECK {
connect_port 8080
connect_timeout 3
nb_get_retry 3
delay_before_retry 3
}
}
}
lvs02配置
! Configuration File for keepalived
global_defs {
router_id lvs02
}
vrrp_instance VI_1 {
state BACKUP
interface ens160
virtual_router_id 51
priority 90
advert_int 1
authentication {
auth_type PASS
auth_pass 1111
}
virtual_ipaddress {
10.1.28.123
}
}
virtual_server 10.1.28.123 8080 {
delay_loop 6
lb_algo rr
lb_kind DR
# persistence_timeout 50
protocol TCP
real_server 10.1.28.30 8080 {
weight 1
TCP_CHECK{
connetct_timeout 10
retry 3
delay_before_retry 3
connetct_port 8080
}
}
real_server 10.1.28.40 8080 {
weight 2
TCP_CHECK{
connetct_timeout 10
retry 3
delay_before_retry 3
connetct_port 8080
}
}
}
2.7 參數說明
IPVS三種IP負載均衡技術：
VS/NAT： 即（Virtual Server via Network Address Translation）
也就是網絡地址翻譯技術實現虛擬服務器，當用戶請求到達調度器時，調度器將請求報文的目標地址（即虛擬IP地址）改寫成選定的Real Server地址，同時報文的目標端口也改成選定的Real Server的相應端口，最后將報文請求發送到選定的Real Server。在服務器端得到數據后，Real Server返回數據給用戶時，需要再次經過負載調度器將報文的源地址和源端口改成虛擬IP地址和相應端口，然后把數據發送給用戶，完成整個負載調度過程?？梢钥闯?，在NAT方式下，用戶請求和響應報文都必須經過Director Server地址重寫，當用戶請求越來越多時，調度器的處理能力將稱為瓶頸。
VS/TUN：即（Virtual Server via IP Tunneling）
也就是IP隧道技術實現虛擬服務器。它的連接調度和管理與VS/NAT方式一樣，只是它的報文轉發方法不同，VS/TUN方式中，調度器采用IP隧道技術將用戶請求轉發到某個Real Server，而這個Real Server將直接響應用戶的請求，不再經過前端調度器，此外，對Real Server的地域位置沒有要求，可以和Director Server位于同一個網段，也可以是獨立的一個網絡。因此，在TUN方式中，調度器將只處理用戶的報文請求，集群系統的吞吐量大大提高。
VS/DR： 即（Virtual Server via Direct Routing）
也就是用直接路由技術實現虛擬服務器。它的連接調度和管理與VS/NAT和VS/TUN中的一樣，但它的報文轉發方法又有不同，VS/DR通過改寫請求報文的MAC地址，將請求發送到Real Server，而Real Server將響應直接返回給客戶，免去了VS/TUN中的IP隧道開銷。這種方式是三種負載調度機制中性能最高最好的，但是必須要求Director Server與Real Server都有一塊網卡連在同一物理網段上，且真實服務器網絡設備或設備別名不作 ARP 響應。
IPVS調度器實現了如下八種負載調度算法：
輪叫（Round Robin）
調度器通過”輪叫”調度算法將外部請求按順序輪流分配到集群中的真實服務器上，它均等地對待每一臺服務器，而不管服務器上實際的連接數和系統負載。
加權輪叫（Weighted Round Robin）
調度器通過”加權輪叫”調度算法根據真實服務器的不同處理能力來調度訪問請求。這樣可以保證處理能力強的服務器處理更多的訪問流量。調度器可以自動問詢真實服務器的負載情況，并動態地調整其權值。
最少鏈接（Least Connections）
調度器通過”最少連接”調度算法動態地將網絡請求調度到已建立的鏈接數最少的服務器上。如果集群系統的真實服務器具有相近的系統性能，采用”最小連接”調度算法可以較好地均衡負載。
加權最少鏈接（Weighted Least Connections）
在集群系統中的服務器性能差異較大的情況下，調度器采用”加權最少鏈接”調度算法優化負載均衡性能，具有較高權值的服務器將承受較大比例的活動連接負載。調度器可以自動問詢真實服務器的負載情況，并動態地調整其權值。
基于局部性的最少鏈接（Locality-Based Least Connections）
“基于局部性的最少鏈接” 調度算法是針對目標IP地址的負載均衡，目前主要用于Cache集群系統。該算法根據請求的目標IP地址找出該目標IP地址最近使用的服務器，若該服務器 是可用的且沒有超載，將請求發送到該服務器；若服務器不存在，或者該服務器超載且有服務器處于一半的工作負載，則用”最少鏈接”的原則選出一個可用的服務 器，將請求發送到該服務器。
帶復制的基于局部性最少鏈接（Locality-Based Least Connections with Replication）
“帶復制的基于局部性最少鏈接”調度算法也是針對目標IP地址的負載均衡，目前主要用于Cache集群系統。它與LBLC算法的不同之處是它要維護從一個 目標IP地址到一組服務器的映射，而LBLC算法維護從一個目標IP地址到一臺服務器的映射。該算法根據請求的目標IP地址找出該目標IP地址對應的服務 器組，按”最小連接”原則從服務器組中選出一臺服務器，若服務器沒有超載，將請求發送到該服務器，若服務器超載；則按”最小連接”原則從這個集群中選出一 臺服務器，將該服務器加入到服務器組中，將請求發送到該服務器。同時，當該服務器組有一段時間沒有被修改，將最忙的服務器從服務器組中刪除，以降低復制的 程度。
目標地址散列（Destination Hashing）
“目標地址散列”調度算法根據請求的目標IP地址，作為散列鍵（Hash Key）從靜態分配的散列表找出對應的服務器，若該服務器是可用的且未超載，將請求發送到該服務器，否則返回空。
源地址散列（Source Hashing）
“源地址散列”調度算法根據請求的源IP地址，作為散列鍵（Hash Key）從靜態分配的散列表找出對應的服務器，若該服務器是可用的且未超載，將請求發送到該服務器，否則返回空。
本例中采用DR負載均衡和wrr負載調度算法
3. 負載均衡及高可用測試
3.1 啟動Keepalived
lvs01和lvs02分別執行：
[root@lvs01 ~]# service keepalived start
執行ip a，lvs01上有vip10.1.28.123，lvs02沒有
3.2 頁面訪問
通過不同瀏覽器訪問http://10.1.28.30:8080
3.3 Master上檢查連接情況
lvs01上執行ipvsadm -ln:
3.4 ipvsadm參數說明
ipvsadm:
-L|-l（–list）：顯示內核虛擬服務器表
-n（–numeric）：輸出IP 地址和端口的數字形式
輸出參數說明：
Forward 轉發方式，當前是路由轉發
Weight 權重
ActiveConn 當前活躍的連接數
InActConn 當前不活躍的連接數
3.5 修改keepalived參數
通過ipvsadm命令發現訪問請求都被分配到92（nginx02）這臺服務器，沒有實現負載均衡。這個和keepalived參數配置persistence_timeout有關，這個參數的意義是保持客戶端的請求在這個時間段內全部發到同一個真實服務器。
分別注釋lvs01和lvs02的persistence_timeout：
[root@lvs01 keepalived]# cp /etc/keepalived/keepalived.conf /etc/keepalived/keepalived.conf.bak
[root@lvs01 keepalived]# view /etc/keepalived/keepalived.conf #persistence_timeout 50
重啟兩臺lvs服務器keepalived服務：
[root@lvs01 keepalived]# service keepalived restart
再次測試：
發現連接均勻的分配到后臺兩臺nginx服務器。
3.5.5 lvs高可用測試
恢復keepalived配置并重啟服務。
lvs01宕機前訪問頁面：
停止lvs01的keepalived服務，模擬lvs01宕機：
systemctl stop keepalived
查看lvs02情況：
發現vip已飄至lvs02。
http://10.1.28.123:8080，訪問正常：
恢復lvs01的keepalived服務：
發現vip飄回至lvs01，vip頁面訪問正常
總結：
當 MASTER 服務器無法提供服務時，VIP 會在 MASTER 上自動移除，BACKUP 服務器會提升為 MASTER 狀態，綁定 VIP 、接管服務。
當 MASTER 修復加入網絡后，會自動搶回 VIP ，成為 MASTER 身份。
