lvs+keepalived

lvs

lvs:基於軟件的四層負載均衡，對外提供一個虛擬ip給客戶端，然後把客戶端請求使用，各種調度算法

分散到後端各個服務器，由於工作在四層所以非常高效，支持各種協議。不涉及應用層，所以沒太

多可配置的，做web的負載均衡時不能實現應用層的動靜分離，所以要基於應用層過濾，選haproxy

nginx,併發也是過萬，可滿足中大規模網站

lvs是怎麼實現負載均衡的？

看這幅圖

當客戶端請求lvs的公網地址時，在請求到達本機的INPUT（進入本機的報文）時，由lvs規則匹配到

於是lvs改掉請求報文的目標ip,改爲後端真正提供服務的ip，然後維持一個會話表，大概就是

某ip訪問了我的公網地址，我給他定向到後端的某服務器，然後在後端服務器迴應的時候，把報文

的源ip改爲自己的公網地址

會話表

由於請求響應都要經過lvs，所以可能會忙不過來。所以就有了第二種方法，當客戶端請求的時候經

過lvs調度，當是響應有後端服務器直接響應。但是有後端直接響應會有一個問題，就是後端服務器會

拿自己的ip作爲源ip響應客戶端，但是客戶端並沒有請求這個ip所以會丟掉報文。所以當後端服務器

在構建響應報文的時候，把源ip換成lvs的公網地址就好了。但是要構建就得自己有這個ip，而且因爲

lvs在使用這個ip，服務器肯定是不能使用的，所以就有了悄悄使用，不讓別人發現。

由於後端服務器要用lvs的公網地址接收客戶端報文，所以lvs不能再改目標地址了，所以就改目標mac

如果改了目標地址在構建響應報文就用了自己接收報文的那個地址了

還有第三種模型，ip隧道，就是lvs在收到客戶端請求報文時把請求ip首部再加一個服務器ip首部，

報文就會被轉發到服務器其他和上面上面一樣，還是服務器得有lvs的公網地址

三、調度算法

Director在接收到來自於Client的請求時，會基於"schedule"從RealServer中選擇一個響應給Client。ipvs支持以下調度算法：

1、輪詢（round robin, rr),加權輪詢(Weighted round robin, wrr)——新的連接請求被輪流分配至各RealServer；算法的優點是其簡潔性，它無需記錄當前所有連接的狀態，所以它是一種無狀態調度。輪叫調度算法假設所有服務器處理性能均相同，不管服務器的當前連接數和響應速度。該算法相對簡單，不適用於服務器組中處理性能不一的情況，而且當請求服務時間變化比較大時，輪叫調度算法容易導致服務器間的負載不平衡。

2、最少連接(least connected, lc)，加權最少連接(weighted least connection, wlc)——新的連接請求將被分配至當前連接數最少的RealServer；最小連接調度是一種動態調度算法，它通過服務器當前所活躍的連接數來估計服務器的負載情況。調度器需要記錄各個服務器已建立連接的數目，當一個請求被調度到某臺服務器，其連接數加1；當連接中止或超時，其連接數減一。

3、基於局部性的最少鏈接調度（Locality-Based Least Connections Scheduling，lblc）——針對請求報文的目標IP地址的負載均衡調度，目前主要用於Cache集羣系統，因爲在Cache集羣中客戶請求報文的目標IP地址是變化的。這裏假設任何後端服務器都可以處理任一請求，算法的設計目標是在服務器的負載基本平衡情況下，將相同目標IP地址的請求調度到同一臺服務器，來提高各臺服務器的訪問局部性和主存Cache命中率，從而整個集羣系統的處理能力。LBLC調度算法先根據請求的目標IP地址找出該目標IP地址最近使用的服務器，若該服務器是可用的且沒有超載，將請求發送到該服務器；若服務器不存在，或者該服務器超載且有服務器處於其一半的工作負載，則用“最少鏈接”的原則選出一個可用的服務器，將請求發送到該服務器。

4、帶複製的基於局部性最少鏈接調度（Locality-Based Least Connections with Replication Scheduling，lblcr）——也是針對目標IP地址的負載均衡，目前主要用於Cache集羣系統。它與LBLC算法的不同之處是它要維護從一個目標IP地址到一組服務器的映射，而 LBLC算法維護從一個目標IP地址到一臺服務器的映射。對於一個“熱門”站點的服務請求，一臺Cache 服務器可能會忙不過來處理這些請求。這時，LBLC調度算法會從所有的Cache服務器中按“最小連接”原則選出一臺Cache服務器，映射該“熱門”站點到這臺Cache服務器，很快這臺Cache服務器也會超載，就會重複上述過程選出新的Cache服務器。這樣，可能會導致該“熱門”站點的映像會出現在所有的Cache服務器上，降低了Cache服務器的使用效率。LBLCR調度算法將“熱門”站點映射到一組Cache服務器（服務器集合），當該“熱門”站點的請求負載增加時，會增加集合裏的Cache服務器，來處理不斷增長的負載；當該“熱門”站點的請求負載降低時，會減少集合裏的Cache服務器數目。這樣，該“熱門”站點的映像不太可能出現在所有的Cache服務器上，從而提供Cache集羣系統的使用效率。LBLCR算法先根據請求的目標IP地址找出該目標IP地址對應的服務器組；按“最小連接”原則從該服務器組中選出一臺服務器，若服務器沒有超載，將請求發送到該服務器；若服務器超載；則按“最小連接”原則從整個集羣中選出一臺服務器，將該服務器加入到服務器組中，將請求發送到該服務器。同時，當該服務器組有一段時間沒有被修改，將最忙的服務器從服務器組中刪除，以降低複製的程度。

5、目標地址散列調度（Destination Hashing，dh）算法也是針對目標IP地址的負載均衡，但它是一種靜態映射算法，通過一個散列（Hash）函數將一個目標IP地址映射到一臺服務器。目標地址散列調度算法先根據請求的目標IP地址，作爲散列鍵（Hash Key）從靜態分配的散列表找出對應的服務器，若該服務器是可用的且未超載，將請求發送到該服務器，否則返回空。

6、源地址散列調度（Source Hashing，sh）算法正好與目標地址散列調度算法相反，它根據請求的源IP地址，作爲散列鍵（Hash Key）從靜態分配的散列表找出對應的服務器，若該服務器是可用的且未超載，將請求發送到該服務器，否則返回空。它採用的散列函數與目標地址散列調度算法的相同。除了將請求的目標IP地址換成請求的源IP地址外，它的算法流程與目標地址散列調度算法的基本相似。在實際應用中，源地址散列調度和目標地址散列調度可以結合使用在防火牆集羣中，它們可以保證整個系統的唯一出入口。

lvs dr模型的實現

準備

# update 192.168.100.254

# vim /etc/hosts

192.168.100.25 node1.xy.com node1

192.168.100.26 node2.xy.com node2

192.168.100.8 lvsms.xy.com lvsms

192.168.100.6 lvsbk.xy.com lvsbk

在服務節點上安裝httpd

# yum -y install httpd

各提供一個主頁

# echo "<h1>node2.xy.com</h1>" >/var/www/html/index.html

# echo "<h1>node1.xy.com</h1>" >/var/www/html/index.html

在lvs上安裝ipvsadm用於配置lvs規則

# yum -y install ipvsadm

配置lvs調度器

1，配置vip

# ifconfig eth0:0 192.168.100.200/24 up

2，配置ipvs規則

# ipvsadm -A -t 192.168.100.200:80 -s wlc

# ipvsadm -a -t 192.168.100.200:80 -r 192.168.100.25 -g -w 1

# ipvsadm -a -t 192.168.100.200:80 -r 192.168.100.26 -g -w 1

配置後端服務器

node1

# ifconfig lo:0 192.168.100.200 netmask 255.255.255.255 broadcast 192.168.100.200

# echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore

# echo 1 > /proc/sys/net/ipv4/conf/lo/arp_ignore

# echo 2 > /proc/sys/net/ipv4/conf/lo/arp_announce

# echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce

# route add -host 192.168.100.200 dev lo:0

node2

# ifconfig lo:0 192.168.100.200 netmask 255.255.255.255 broadcast 192.168.100.200

# echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore

# echo 1 > /proc/sys/net/ipv4/conf/lo/arp_ignore

# echo 2 > /proc/sys/net/ipv4/conf/lo/arp_announce

# echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce

# route add -host 192.168.100.200 dev lo:0

測試

基於防火牆標記綁定實現多個端口服務

清空原先的規則

# ipvsadm -C

# iptables -t mangle -A PREROUTING -p tcp -m multiport --dports 80,443 -j MARK --set-mark 10

# ipvsadm -A -f 10 -s wlc

# ipvsadm -a -f 10 -r 192.168.100.25 -g -w 1

# ipvsadm -a -f 10 -r 192.168.100.26 -g -w 1

# ipvsadm -L -n

我們最後再來看報文是怎麼走的

1,客戶端發起請求

目標地址：2.2.2.2

源地址： 5.5.5.5

2，經過互聯網到達服務器的eth0目標地址和源地址沒有發生改變

服務器發現目標地址正是本機，於是收下了報文

3，當報文到達本機的INPUT鏈的時候被lvs規則匹配到，於是根據lvs

規則進行改報文首部，由於是定義的dr模型的規則，所以根據調度

算法，選一個後端服務器，假如正好選中了192.168.0.101,於是

修改報文的目標mac爲192.168.0.101的mac地址，然後把報文放到

交換機在這個時候源地址和目標地址是沒有發生改變的，因爲只是

修改了目標mac

我們來看看報文格式

4, 交換機發現目標mac是192.168.0.101的mac於是就把報文

發到了192.168.0.101

5, 192.168.0.101發現目標mac正是自己，於是收下了報文開始拆報文

先拆掉了mac看到了ip首部，發現目標地址正是本機，因爲lo:0的

地址正是2.2.2.2，於是又拆掉了ip首部，發現tcp首部是請求本機的

80端口，於是交給本機註冊使用了80端口的httpd進程，httpd進程

開始處理請求

6，當請求處理完後就要發給客戶端了，由於走lo:0報文出不去，但是

2.2.2.2這個客戶端請求地址就在2.2.2.2上，要夠建響應報文就必須

經過lo:0的2.2.2.2，所以就加了一條特殊的主機路由：

route add -host 2.2.2.2 dev lo:0

表示對2.2.2.2的請求都走lo:0，於是響應報文的源地址就變成了2.2.2.2

然後交給eth0的192.168.100.101，讓它交給默認網關，到達互聯網。

到這一步的時候目標地址是5.5.5.5源地址是2.2.2.2

如有錯誤謝謝指出，不勝感激

keepalived配置lvs高可用

# vim keepalived.conf

! Configuration File for keepalived
global_defs {
  notification_email {
    [email protected]
    [email protected]
    [email protected]
  }
  notification_email_from [email protected]
  smtp_server 192.168.200.1
  smtp_connect_timeout 30
  router_id LVS_DEVEL
}
vrrp_instance VI_1 {
   state MASTER        #在備節點上改爲BACKUP
   interface eth0
   virtual_router_id 51
   priority 100        #在備節點上改爲99
   advert_int 1
   authentication {
       auth_type PASS
       auth_pass 1111
   }
   virtual_ipaddress {
       192.168.100.200
   }
}
virtual_server 192.168.100.200 80 {
   delay_loop 6
   lb_algo wlc
   lb_kind DR
   persistence_timeout 50
   protocol TCP
   real_server 192.168.100.26 80 {
       weight 1
       TCP_CHECK {
           connect_timeout 3
           nb_get_retry 3
           connect_port 80
           delay_before_retry 3
       }
   }
   real_server 192.168.100.25 80 {
       weight 1
       TCP_CHECK {
           connect_timeout 3
           nb_get_retry 3
           connect_port 80
           delay_before_retry 3
       }
   }
}

keepalived會自己生成lvs規則，所以不用自己寫，而且可以檢查後realserver的健康

當realserver下線時自動從可用列表清除，保證了不會發生在調度的時候，有的可用有的不可用

yum安裝配置非常簡單，因爲所以的配置都做好了，只需要改改就能用，對於健康狀態

檢測可以使用基於應用層的http檢測，其實用tcp檢查80端口也行的

配置

real_server 172.16.100.12 80 {

weight 1

HTTP_GET {

url {

path /

status_code 200

}

connect_timeout 3

nb_get_retry 3

delay_before_retry 3

}

當需要配置監聽多個端口的時候把

virtual_server fwmark int (int爲打的防火牆標記)

lvs+haproxy

heartbeat drbd nfs高可用

lvs+keepalived

mysql基本用法

sphinx

mysql調優

Mac下配置sublime實現LaTeX

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結