Neutron：LBaaS v2

LBaaS v2

 

Neutron 包含負載均衡服務，即LBaaS。負載均衡器能夠將用戶的訪問流量經過算法均攤到多臺主機實例上，實現以 Scale-out的方式擴容應用的性能。Neutron LBaaS 包含如下核心的概念：

• 服務器池 Pool：服務器池內包含了多個服務器成員，同一個池內的服務器至少包含一種統一的對外服務。
• 服務器成員 Member：服務器成員，包含服務器的IP和端口。
• 監聽器 Listener：監聽器將持續監聽指定的端口上的鏈接請求。一個負載均衡器中容許存在多個監聽器，同時經過共享服務器池，多個監聽器也能夠關聯到同一個服務器池。
• 健康監控 Health monitor：檢查服務器池中成員的狀態，以及服務器的加入、離開。

 

負載均衡概念

創建在現有的網絡之上，提供了一種廉價、有效、透明的方法來擴大網絡設備和服務器的帶寬、增長吞吐量、增強網絡數據處理能力，以及提升網絡的靈活性和可用性。經過負載均衡器，能夠實現N臺廉價的Linux服務器並行處理，從面達到小型機或大型機的計算能力。單臺負載均衡器位於網站的最前端，它起着分流客戶請求的做用，至關於整個網站或系統的入口。因爲IPv4中IP地址日益緊張以及出於安全方面的才慮，不少網絡使用保留IP地址（如10.0.0.0/255.0.0.0、172.16.0.0/255.128.0.0、和192.168.0.0/255.255.0.0).這些不在Internet上使用，而是專門爲內部網絡預留的。當內部網絡中的主機要訪問Internet或被Internet訪問時，就須要進行網絡地址轉換（Network Address Translation，NAT），NAT方法就是交不一樣IP地址的並行網絡服務變成一個在同一IP地址上的虛擬服務。

 服務器池 Pool

服務器池即後端一組提供服務的實例，每一個成員都是一個IP地址+4層的端口。例如，常見的提供web服務的實例，在服務器池中表示爲：192.168.1.1：80。提供的服務不一樣則端口號也不相同。池內的服務器都統一對外提供某一種服務。例如：

服務器 1：192.168.1.1：80

服務器 2：192.168.1.3：80

服務器 3：192.168.1.4：80

 

負載均衡器經過 VIP 統一對前端提供服務，用戶向虛擬IP發起鏈接請求，監聽器監聽到對應端口的請求後，經過負載均衡算法將請求轉發到後端服務池中的一個成員上。而後成員對用戶請求的資源進行響應，這樣整個過程對於用戶來講是透明的。包括後端服務器的增長、減小以應對用戶規模的增縮，都不會對已經創建的鏈接產生影響。

 

監聽器 Listener

監聽器即一個不斷在端口上檢查鏈接請求的進程，一旦發現客戶端的鏈接請求，則會按照你設定的規則將鏈接請求轉發給後端的服務器池。一個監聽器關聯一個端口，如：HTTP(80)、HTTPS（443），當使用HTTPS，則須要上傳用於https 加密和解密的證書到監聽器中。

L7 轉發策略  l7 policy

 

 l7策略轉發流程

LBaaS v2 支持L7的轉發策略，每一個監聽器上均可以配置多條轉發策略（L7 Policy）。策略由由規則（rule）和操做組成，相似 if…then…的條件語句，當有流量匹配了 rule 的條件時，就按照策略中的操做轉發。不然就繼續向下匹配。規則能夠匹配HTTP請求中的特殊字段或URL，這給業務帶來了極大的靈活性。

rule 支持的匹配項包括：

• Hostname，L7 rule 支持匹配HTTP/1.1 請求中的host字段
• path，HTTP URI 中路徑的部分
• file_type，請求的文件類型
• header，HTTP 頭中其餘字段
• cookie，cookie的值

須要注意的是，同一個policy下的rule是「與」的關係，即策略下的全部rule都匹配的狀況下，纔會按照策略的操做轉發。其中任何一條不匹配都會跳過該策略向下匹配。

匹配的算法包括：

• regex，正則表達式，非的意思
• starts_with，字符串開頭
• ends_with，字符串結尾
• contains，字符串中包含的值
• equal_to，等於

L7 policy 的操做支持：

• block，請求將直接被拒絕；
• redirect_to_url，重定向用戶的url；
• redirect_to_pool，重定向到後端特定的主機池內。

 

 

例如：能夠在監聽器上添加兩條rule，一條匹配HTTP請求中 file_type 包含：jgp、png、gif、zip、txt 的請求轉發給 image pool。另外一條一條匹配URI中 path 以「*/login」開頭的請求轉發給APP pool。

這樣就簡單的實現了網站上靜態內容（圖片）與動態內容（用戶登陸）的分流處理，這能在不改變應用架構的狀況下，減輕web服務的負載。對於雲原生應用來講，這樣的功能很是重要。

 

L7策略配置示例以下：

• neutron --policy policy1 lbaas-create-l7policy --name "policy1" --description "My Description" --listener "listener1" --action redirect_to_pool --pool "pool1" --position 1 （建立L7策略，命名爲「policy1」描述爲「lb策略」，並關聯 「listener 1」，策略的動做是將匹配的流量轉發到「pool1」)
• neutron lbaas-create-l7rule rule1 --rule-type path --compare-type starts_with --value "/api" --policy policy  (在「policy 1」下添加一條規則，匹配全部URL中以 「/api」開頭的請求)

可見到 LBaaS v2可根據業務需求制定出很是靈活的7層轉發策略。

 

負載均衡算法 Algorithms

自己Neutron支持的負載均衡算法包括：輪詢、最少鏈接、源IP。

• 輪詢 Round robin，是最廣泛的算法，每當有一個新的請求來臨，負載均衡器都會按順序選擇服務器池中的一臺設備來響應。有點相似音樂播放軟件的列表循環。這種模式下服務器池中的每個服務器都能均勻地分配到相同的訪問請求數，而不會管服務器繁忙程度、服務器配置的高低。比較適用於服務器池內的服務器配置相同、用戶訪問習慣相同的業務。加權輪詢是改進的負載均衡算法，當後端服務器池中設備配置高低不一時，可根據服務器處理能力的高低分配服務器的權值，權值高的服務器會被分配更多的用戶請求。
• 最少鏈接算法 Least connections，負載均衡器收到新的請求時，都會從當前服務器池中挑選一個當前併發鏈接數最少的服務器來負責。最少鏈接算法考慮的服務器的實時負載狀況，儘可能保證了任務分配的平均，防止單個服務器超出負載，可是當後端服務器池中存在高處理能力的服務器時，這個處理能力高的設備始終沒法得到更多的工做負載，存在性能的浪費。最少鏈接算法有優化後的加權最小鏈接算法
• IP hash，負載均衡器在收到主機的鏈接請求後，會根據數據包的源IP地址字段的hash值，同時按照輪詢的方式爲客戶端分配主機，當負載均衡器再次收到同一IP的請求時，則會按照以前的記錄爲客戶端分配上次創建鏈接的主機。這樣保證了當同一個IP的用戶，屢次獨立的訪問都能由同一臺服務器來處理，適用於服務器須要臨時記錄或保存客戶信息的應用中。

 

健康監測 Monitor

健康檢測的機制是指是負載均衡器經過按期的心跳信號檢測服務器池中的服務器運行狀態，從而排除掉後端故障的主機，保證服務總體正常。

Neutron支持的健康檢測方式包括 ICMP、TCP、HTTP幾種。

• ICMP是最簡單的，經過ping 和echo的方式，看根據服務器是否響應。只要服務器操做系統TCP/IP協議棧運行正常，網卡不出問題，服務器到負載均衡之間的網絡正常，ICMP的方式都起到良好的做用，但以上狀況都不能表明服務器上面運行的應用是正常的。
• TCP是4層的檢測方式，相比ICMP、TCP會請求主機的特定端口，看特定的端口可否正常響應。
• HTTP的方式則更進一籌，會經過get特定的頁面，根據HTTP的返回代碼來判斷應用是否正常。

健康監測的指標越精確，越能反映服務的實際響應狀況，若是是web服務，最好是使用HTTP的方式，這樣檢測結果更可信。

 

會話保持 Session persistence

會話保持功能經常使用於有狀態的服務中，好比服務器經過session來維護用戶鏈接的狀態，由於session保存在服務器本地，若是不斷地經過網絡來在服務器池中同步session的話，會消耗服務器的帶寬和處理能力，因此這時會選擇使用負載均衡器的會話保持功能。它能保證同一個用戶的請求會被髮送到同一臺服務器。

 

Lbaas v2支持的會話保持的類型爲：

• 源IP：源IP即IP hash 算法，根據IP地址來識別客戶。負載均衡器在收到請求後會計算數據包頭源IP地址的hash值，並按照輪詢的方式給該客戶端分配一個服務器，同時將二者的對應關係記錄到表中，當再次收到同一源IP發來的請求時，則查找到以前的服務器進行轉發。可是當客戶端經過NAT、或代理的方式上網時，源IP的方式就可能致使多個客戶端被分配到同一個主機。順便一提，去年在公司用12306在高峯期搶車票時，剛打開網站就被提示「您的操做頻率過快」，即頗有可能12306後端也是判斷同一個IP提交的訪問請求過多，從而誤把新接入用戶看成了已訪問過的用戶。
• HTTP_cookie：該模式下會根據瀏覽器中緩存的cookie來識別用戶，cookie裏面通常都緩存了計算機信息和瀏覽器的信息以及用戶認證的信息。Lbaas v2中負載均衡器會在服務器第一次返回給客戶端的迴應中插入「SRV」的cookie值，標識了回覆的服務器。當再次收到客戶端發起的HTTP請求時，lbaas v2會找出 cookie中的"SRV"字段，並剝離掉後轉發給以前回復的服務器。HTTP_cookie 的問題在於，有可能一些用戶會禁用掉瀏覽器上的cookies，這種狀況下基於cookies的會話保持就將失效了。
• App_cookie：該模式下須要在負載均衡器中預先定義各個後端中設置的cookie，並將對應關係存儲到表中，當收到客戶端的請求時，檢查請求中是否有預先定義的cookie，若是有，則轉發到對應的服務器。

 

雖然當今互聯網應用中經過token來實現用戶的識別和鑑權已經比較常見了，但負載均衡的會話保持可以很好彌補經過 seesion 識別用戶的應用的不足。可是基於cookie的會話保持沒法支持服務器直接返回的部署模式，即服務器返回給用戶的流量不通過負載均衡器，而是直接上行轉發出去。因此在某些大流量的應用中，負載均衡器可能成爲性能的瓶頸。

 

非對稱流量中，服務器直接返回到客戶端，上行流量不通過負載均衡器，LBaaS v2 暫時還不支持這種部署模式。

 

實現

Neutron中 LBaaS v2實現方式，

一：使用HAproxy做爲負載均衡器，在網絡節點上運行LBaaS agent，agent會完成節點上的Haproxy 的建立和配置工做。這也是目前較爲成熟的使用方式。

二：使用Octavia 做爲負載均衡器，Octavia是在LBaaS v2中加入到openstack中的，官方對它的定位不是要代替HAproxy在neutron中的地位，而是做爲一個可選開源的LB服務提供者，相似LVS+F5等。Octavia的架構是全新設計的，並且在一開始就立志成爲運營級的負載均衡解決方案。只是目前Octavia仍是遠談不上成熟，官方推薦只在Devstack中使用。

三： 使用lvs做爲負載均衡器

 

HAproxy + keepalive

比較經常使用的開源負載均衡器有LVS、Nginx、HAproxy，

LVS只能作到四層的負載均衡，即只能依據IP+端口的方式進行轉發，不支持L7的轉發策略，

Nginx不只能作Web服務器，同時也能做爲負載均衡器使用；

HAproxy 和Nginx都能基於L7策略進行轉發。

LVS也常常和HAproxy、Nginx混用，在大流量的集羣中，先由LVS將流量分攤到不一樣的Nginx/HAproxy集羣，再由Nginx/HAproxy作L7轉發。除此以外Neutron也支持Ctrix、F五、Radware等公司的插件，從而經過專用的負載均衡硬件來實現。

 

LBaaS v2的經典實現方式就是在網絡節點上部署HAproxy+Keepalive 實現負載均衡服務。 其中HAproxy提供L7的負載均衡，Keepalive用於實現高可用方案。

HAproxy

HAproxy可以爲服務器池提供7層的負載均衡功能，即能根據HTTP請求頭中的內容來執行負載均衡算法。並且做爲開源軟件，被普遍使用。

HAProxy的特色是：   

1. HAProxy也是支持虛擬主機的。 
2. HAProxy的優勢可以補充Nginx的一些缺點，好比支持Session的保持，Cookie的引導；同時支持經過獲取指定的url來檢測後端服務器的狀態。 
3. HAProxy跟LVS相似，自己就只是一款負載均衡軟件；單純從效率上來說HAProxy會比Nginx有更出色的負載均衡速度，在併發處理上也是優於Nginx的。 
4. HAProxy支持TCP協議的負載均衡轉發，能夠對MySQL讀進行負載均衡，對後端的MySQL節點進行檢測和負載均衡，你們能夠用LVS+Keepalived對MySQL主從作負載均衡。 
5. HAProxy負載均衡策略很是多，HAProxy的負載均衡算法如今具體有以下8種： 

① roundrobin，表示簡單的輪詢，這個很少說，這個是負載均衡基本都具有的； 
② static-rr，表示根據權重，建議關注； 
③ leastconn，表示最少鏈接者先處理，建議關注； 
④ source，表示根據請求源IP，這個跟Nginx的IP_hash機制相似，咱們用其做爲解決session問題的一種方法，建議關注； 
⑤ ri，表示根據請求的URI； 
⑥ rl_param，表示根據請求的URl參數’balance url_param’ requires an URL parameter name； 
⑦ hdr(name)，表示根據HTTP請求頭來鎖定每一次HTTP請求； 
⑧ rdp-cookie(name)，表示根據據cookie(name)來鎖定並哈希每一次TCP請求。

1.啓用lbaas v2首先須要修改neutron的配置文件，加入插件：

/etc/neutron/neutron.conf

service_plugins = [existing service plugins],neutron_lbaas.services.loadbalancer.plugin.LoadBalancerPluginv2

 

2.在lbaas的配置文件中添加lbaas v2：

/etc/neutron/neutron_lbaas.conf

service_provider = LOADBALANCERV2:Haproxy:neutron_lbaas.drivers.haproxy.plugin_driver.HaproxyOnHostPluginDriver:default

 

3.選擇2層設備的驅動：

/etc/neutron/lbaas_agent.ini

[DEFAULT]
interface_driver = openvswitch

根據實際，選擇 ovs 或者 linux bridge，須要與節點上的2層設備類型匹配。

 

4.開啓數據庫遷移

neutron-db-manage --subproject neutron-lbaas upgrade head

 

5.啓動 lbaas v2 agent。

neutron-lbaasv2-agent \
--config-file /etc/neutron/neutron.conf \
--config-file /etc/neutron/lbaas_agent.ini

來自 <https://docs.openstack.org/ocata/networking-guide/config-lbaas.html#configuring-lbaas-v2-with-octavia>

 

隨後便可以建立負載均衡器：

1.建立負載平衡器，指定負載平衡的名稱和關聯的子網名。需指定與虛擬機所在的子網。

neutron lbaas-loadbalancer-create --name my-lb  private-subnet


2.爲新負載平衡器建立偵聽器。

neutron lbaas-listener-create \    //添加監聽器
--loadbalancer my-lb \   //關聯以前建立的負載均衡器
--protocol HTTP  \     //選擇監聽器協議，TCP\HTTP\HTTPS
--protocol-port  80 \     //選擇監聽器對外監聽的端口（即向用戶開放的端口）
--name webservice-listener \    //設置監聽器名稱



3.建立 LBaaS 服務器池。

neutron lbaas-pool-create \
--lb-algorithm  ROUND_ROBIN \  //選擇負載均衡算法,支持上文中提到的輪詢、最少鏈接、IP hash等
--listener LISTENER_1_NAME \     //關聯監聽器
--protocol HTTP \     //服務器池使用的協議
--name LB_POOL_1      //服務器名稱
 

4.將服務器實例添加到建立的 LBaaS 池中。

neutron lbaas-member-create  \
--subnet <subnet-id> --address <server 1 IP> \    //將後端服務器添加到地址池中
--protocol-port 80 <pool name>       //後端服務器上服務所使用的端口,能夠與前端的端口不一致

neutron lbaas-member-create  \   
--subnet <subnet-id> --address <server 2 IP> \
--protocol-port 80 <pool name>


5.設置Health monitor指標。

neutron lbaas-healthmonitor-create \
--delay DELAY_IN_SECONDS     //設置心跳檢測發送到服務器成員的週期，單位爲秒。需避免過於頻繁的心跳檢測，以及檢測不及時的狀況出現，達到平衡。對可用性要求高能夠設置爲3～5秒，

--type [HTTP | TCP]       //選擇心跳檢測的協議，若是TCP則只檢測服務器上端口是否開啓,HTTP則支持檢測web服務的狀態。當選擇HTTP時，能夠指定http的方法，默認是 get 一個特定的頁面。同時還能指定服務器正常響應對應的HTTP狀態碼，如返回200時，表明web服務正常，200之外的值，如40四、408等則表明異常。可經過 expected_codes  設置。url_path 則用來指定health monitor 請求的頁面。

--max-retries NUMBER \      //設置在改變服務器可用狀態以前，等待服務器的應答的次數。假設爲n，若是是n次未響應，則切換爲inactive，以後若是n次正常響應，則切換爲active。推薦爲 3
--timeout TIMEOUT_IN_SECONDS     //設置超時的時長，當超過該時長服務器都沒有迴應，則認爲服務器這次心跳監測爲故障。

--pool LBAAS_POOL       //將健康監測配置關聯到服務器池。


一個服務器從出現故障，到負載均衡器發現並標記爲不可用，再也不爲其分配流量，這其中須要的時間爲：Time = delay *(max-retries -1) + timeout   (*忽略從服務器發生故障到下一次健康監測中間的延時)，在這個時間段內，負載均衡器都會爲服務器分配流量。


6.分配浮動IP，爲負載均衡器分配浮動IP與爲雲主機分配浮動IP是同樣的，都是在fip的命名空間中爲指定一個公網地址到內網地址的映射。這樣外部的用戶就能夠經過公網地址直接訪問到服務器池內的主機。若是做爲內部使用的負載均衡器，則不須要分配浮動ip。

neutron floatingip-associate FLOATINGIP_ID LOAD_BALANCER_PORT_ID

 

 

最後不要忘記設置防火牆和安全組，容許外部流量訪問負載均衡器的VIP和開啓的listener端口。

 

Keepalive

HAproxy的 Active/Standby 部署模式就是經過keepalive 來實現的。keepalive的核心是vrrp，openstack的HA中大量使用了vrrp協議來提供高可用，包括以前L3中提到的路由器的高可用。負載均衡器的vip將會配置在vrrp的 vip上，對外提供服務。同時vrrp會經過心跳檢測負載均衡主備設備運行的狀態，並實現vip的切換。

Octavia中還有一個假主備模式，即負載均衡在實際中爲單節點部署，不過Octavia Controller內的Health manager會頻繁檢測負載均衡節點的運行狀態，一旦發現負載均衡器故障，則從備用的負載均衡器中選一個代替故障的設備，並套用原來的配置。

 

Octavia

Octavia項目是在 Liberty 版本中隨着LBaaS v2一同發佈，其amphorea模塊是實現負載均衡功能的模塊，支持部署在虛擬機、容器、裸機上，爲雲上的租戶提供負載均衡服務。

上圖是Octavia的架構，neutron原生集成了Octavia的驅動，能夠直接經過Neutron的接口來完成Octavia的管理。同時Octavia也支持獨立工做，其擁有獨立的數據庫，租戶的配置信息不只會保存在Neutron的數據庫中，也會保存在Octavia的獨立數據庫中。（同時按照網上的部署經驗，octavia和neutron的數據庫同步是一個較大的問題）

 

Octavia 0.8版本中的amphorae 鏡像是一臺運行了HAproxy的ubuntu虛擬機，已經支持RH Linux、Centos、Fedora。將來還將支持以容器和裸金屬的方式部署。

除此以外是Octavia的核心Controller，它包含4個組件：

• API Controller：運行Octavia 的API，並接受外部的調用申請，而後經過消息總線傳送給worker。
• Controller Worker：負責執行API的各類操做，包括對nova、neutron接口的調用，以實現amphorae虛擬機的生命週期管理、建立端口、建立外部網絡等資源，除此以外還有SSL證書、工做流等等功能管理。都由worker來一一實現。
• Health manager：用於監控amphorae的運行狀態，並執行amphorae的故障切換。
• Housekeeping manager：用於刪除無用的數據庫記錄，管理備用池和安全證書等。

 

用戶在openstack環境中建立負載均衡服務時，建立amphorea虛擬機、端口、安全組等操做，這些都是由Octavia Controller自動完成，用戶不可見，用戶能見到的只有部署完成以後的Octavia的配置項和對應的網絡端口。

service_provider = LOADBALANCERV2:Octavia:neutron_lbaas.drivers.octavia.driver.OctaviaDriver:default

 

 

 

Octavia的建立和配置命令與建立HAproxy的命令是徹底同樣的，配置好插件後 Octavia API Controller 將執行neutron指令，並完成amphorae的建立和配置等工做。

可見到Octavia項目目標是搭建一個完善的本地負載均衡管理平臺，目前它是以虛擬機的方式提供服務，未來計劃可以對雲主機、容器、甚至裸機部署負載均衡服務，並支持Active、Active部署方式。

 

更多內容能夠參考如下文章

https://docs.openstack.org/octavia/latest/reference/introduction.html

http://lingxiankong.github.io/blog/2016/03/30/octavia/

http://502245466.blog.51cto.com/7559397/1303506

 

Load Balancing as a Service : Liberty and Beyond

負載均衡自己的技術並不複雜，也發展得較爲成熟，但現在負載均衡在各類雲上扮演着很是重要的角色，各個雲上與部署解決方案中都能看到它的身影。究其緣由是其給租戶的應用帶來的彈性和可用性。雲的租戶能夠在前端用戶徹底無感知的狀況下，按負載增刪後臺服務器的數量，並實現服務的高可用，這很是符合雲「按需使用」「分佈式高可用服務」的理念。因此當服務的彈性伸縮和高可用性成爲雲計算的基本屬性時，負載均衡器就開始在雲上扮演不可替代的角色，能夠說，不支持負載均衡的雲不能稱之爲雲。而傳統的硬件負載均衡器不管是在可靠性、擴展性、可編程性、成本等方面都沒法知足雲供應商的需求。

 

 

以LVS（Linux Virtual Server）做爲負載均衡器：    

LVS：使用Linux內核集羣實現一個高性能、高可用的負載均衡服務器，它具備很好的可伸縮性（Scalability)、可靠性（Reliability)和可管理性（Manageability)。

LVS的優勢是：

1. 抗負載能力強、是工做在網絡4層之上僅做分發之用，沒有流量的產生，這個特色也決定了它在負載均衡軟件裏的性能最強的，對內存和cpu資源消耗比較低。 
2. 配置性比較低，這是一個缺點也是一個優勢，由於沒有可太多配置的東西，因此並不須要太多接觸，大大減小了人爲出錯的概率。 
3. 工做穩定，由於其自己抗負載能力很強，自身有完整的雙機熱備方案，如LVS+Keepalived，不過咱們在項目實施中用得最多的仍是LVS/DR+Keepalived。 
4. 無流量，LVS只分發請求，而流量並不從它自己出去，這點保證了均衡器IO的性能不會受到大流量的影響。 
5. 應用範圍比較廣，由於LVS工做在4層，因此它幾乎能夠對全部應用作負載均衡，包括http、數據庫、在線聊天室等等。

LVS的缺點是：   

1. 軟件自己不支持正則表達式處理，不能作動靜分離；而如今許多網站在這方面都有較強的需求，這個是Nginx/HAProxy+Keepalived的優點所在。 
2. 若是是網站應用比較龐大的話，LVS/DR+Keepalived實施起來就比較複雜了，特別後面有 Windows Server的機器的話，若是實施及配置還有維護過程就比較複雜了，相對而言，Nginx/HAProxy+Keepalived就簡單多了。

 

LVS的常見名詞解釋

CIP<-->VIP--DIP<-->RIP
Direct Routing：直接路由
負載均衡層(Loader Balancer)，它就是咱們所說的的Director
RS real server ：真實提供服務的計算機
VIP：Virtual IP（VIP）address：Director用來向客戶端提供服務的IP地址
RIP：Real IP （RIP） address：集羣節點（後臺真正提供服務的服務器）所使用的IP地址
DIP：Director's IP (DIP) address：Director用來和D/RIP 進行聯繫的地址
CIP：Client computer's IP (CIP) address：公網IP，客戶端使用的IP

 

 

Session持久機制
1.Session綁定：始終將統一請求者的鏈接定向至統一RS（第一次請求時仍有調度選擇）：沒有容錯能力，有損均衡效果
2.session複製：在RS之間同步session，所以，每一個RS持集羣中全部的session；對於大規模集羣環境不適用
3.session服務器：利用單獨部署的服務器來統一管理session

LVS的集羣服務：
四層交換，四層路由
根據請求目標套接字（包括端口的協議類型tcp，udp）來實現轉發

 LVS類型：

     NAT-->(DNAT)

     DR

     TUN

     FULLNAT（ipvsadm沒有該模式）

 

 VS/NAT的體系結構比較簡單：在一組服務器前有一個調度器，它們是經過Switch/HUB相鏈接的，這些服務器提供相同的網絡服務、相同的服務內容，即無論請求被髮送到哪一臺服務器，執行結果都是同樣的。服務的內容能夠複製到每一臺服務器的本地硬盤上，可能經過網絡文件系統共享，也能夠經過一個分佈式文件系統來提供。

 LVS NAT的特性：

一、RS應該使用私有地址；

二、RS的網關的必須指向DIP；

三、RIP和DIP必須在同一網段內；

四、請求和響應的報文都得通過Director；在高負載場景中，Director極可能成爲系統性能瓶頸；

五、支持端口映射；

六、RS可使用任意支持集羣服務的OS；

  

LVS DR類型的特性：

一、RS可使用私有地址；但也可使用公網地址，此時能夠直接經過互聯網連入RS以實現配置、監控等；

二、RS的網關必定不能指向DIP；

三、RS跟Dirctory要在同一物理網絡內（不能由路由器分隔）；

四、請求報文通過Directory，但響應報文必定不通過Director

五、不支持端口映射；

六、RS可使用大多數的操做系統；

 

LVS TUN類型：IP隧道

一、RIP、DIP、VIP都得是公網地址；

二、RS的網關不會指向也不可能指向DIP；

三、請求報文通過Directory，但響應報文必定不通過Director；

四、不支持端口映射；

五、RS的OS必須得支持隧道功能；

 

VS/DR或VS/TUN應用的一種模型中（全部機器都在同一個物理網絡），全部機器（包括Director和RealServer）都使用了一個額外的IP地址，即VIP。當一個客戶端向VIP發出一個鏈接請求時，此請求必需要鏈接至Director的VIP，而不能是RealServer的。由於，LVS的主要目標就是要Director負責調度這些鏈接請求至RealServer的。

所以，在Client發出至VIP的鏈接請求後，只能由Director將其MAC地址響應給客戶端（也多是直接與Director鏈接的路由設備），而Director則會相應的更新其ipvsadm table以追蹤此鏈接，然後將其轉發至後端的RealServer之一。

若是Client在請求創建至VIP的鏈接時由某RealServer響應了其請求，則Client會在其MAC table中創建起一個VIP至RealServer的對就關係，並以致進行後面的通訊。此時，在Client看來只有一個RealServer而沒法意識到其它服務器的存在。

爲了解決此問題，能夠經過在路由器上設置其轉發規則來實現。固然，若是沒有權限訪問路由器並作出相應的設置，則只能經過傳統的本地方式來解決此問題了。這些方法包括：

一、禁止RealServer響應對VIP的ARP請求；

二、在RealServer上隱藏VIP，以使得它們沒法獲知網絡上的ARP請求；

三、基於「透明代理（Transparent Proxy）」或者「fwmark （firewall mark）」；

四、禁止ARP請求發往RealServers；

 

LVS Scheduling Method LVS的調度方法：

1.Fixed Scheduling Method  靜態調服方法

(1).RR     輪詢

(2).WRR    加權輪詢

(3).DH     目標地址hash

(4).SH     源地址hash

2.Dynamic Scheduling Method 動態調服方法

(1).LC     最少鏈接

(2).WLC    加權最少鏈接

(3).SED    最少指望延遲

(4).NQ     從不排隊調度方法

(5).LBLC   基於本地的最少鏈接

(6).LBLCR  帶複製的基於本地的最少鏈接

 

ipvsadm組件定義規則的格式：

1.定義集羣服務格式：

(1).添加集羣服務：

ipvsadm -A|E -t|u|f service-address [-s scheduler]

              [-p [timeout]] [-M netmask]

-A：                  表示添加一個新的集羣服務

-E：                  編輯一個集羣服務

-t：                  表示tcp協議

-u：                  表示udp協議

-f：                  表示firewall-Mark,防火牆標記

service-address：     集羣服務的IP地址，即VIP

-s                    指定調度算法

-p                    持久鏈接時長，如#ipvsadm -Lcn ，查看持久鏈接狀態

-M                    定義掩碼

 

ipvsadm -D -t|u|f service-address      刪除一個集羣服務

ipvsadm -C                             清空全部的規則

ipvsadm -R                             從新載入規則

ipvsadm -S [-n]                        保存規則

 

2.向集羣服務添加RealServer規則：

(1).添加RealServer規則

ipvsadm -a|e -t|u|f service-address -r server-address

              [-g|i|m] [-w weight]

-a                 添加一個新的realserver規則

-e                 編輯realserver規則

-t                 tcp協議

-u                 udp協議

-f                 firewall-Mark，防火牆標記

service-address    realserver的IP地址

-g                 表示定義爲LVS-DR模型

-i                 表示定義爲LVS-TUN模型

-m                 表示定義爲LVS-NAT模型

-w                 定義權重，後面跟具體的權值

ipvsadm -d -t|u|f service-address -r server-address          --刪除一個realserver

ipvsadm -L|l [options]                                       --查看定義的規則

如：#ipvsadm -L -n  

ipvsadm -Z [-t|u|f service-address]                          --清空計數器

 

LVS-NAT 模型實例 

打開路由間轉發功能

[root@mgm-net0 ~]# sysctl -a | grep net.ipv4.ip_forward
sysctl: reading key "net.ipv6.conf.all.stable_secret"
net.ipv4.ip_forward = 1

若爲0，設置爲1：

echo 1 > /proc/sys/net/ipv4/ip_forward

sysctl  -p      //當即生效

 

查看ipvs支持功能

[root@mgm-net0 ~]# grep -E -i "ipvs|IP_VS" /boot/config-3.10.0-862.11.6.el7.x86_64
CONFIG_NETFILTER_XT_MATCH_IPVS=m
CONFIG_IP_VS=m
CONFIG_IP_VS_IPV6=y
# CONFIG_IP_VS_DEBUG is not set
CONFIG_IP_VS_TAB_BITS=12
# IPVS transport protocol load balancing support
CONFIG_IP_VS_PROTO_TCP=y
CONFIG_IP_VS_PROTO_UDP=y
CONFIG_IP_VS_PROTO_AH_ESP=y
CONFIG_IP_VS_PROTO_ESP=y
CONFIG_IP_VS_PROTO_AH=y
CONFIG_IP_VS_PROTO_SCTP=y
# IPVS scheduler
CONFIG_IP_VS_RR=m
CONFIG_IP_VS_WRR=m
CONFIG_IP_VS_LC=m
CONFIG_IP_VS_WLC=m
CONFIG_IP_VS_LBLC=m
CONFIG_IP_VS_LBLCR=m
CONFIG_IP_VS_DH=m
CONFIG_IP_VS_SH=m
CONFIG_IP_VS_SED=m
CONFIG_IP_VS_NQ=m
# IPVS SH scheduler
CONFIG_IP_VS_SH_TAB_BITS=8
# IPVS application helper
CONFIG_IP_VS_FTP=m
CONFIG_IP_VS_NFCT=y
CONFIG_IP_VS_PE_SIP=m

查看速率信息

[root@lvs-server ~]# ipvsadm -Ln --rate
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port                 CPS    InPPS   OutPPS    InBPS   OutBPS
  -> RemoteAddress:Port
TCP  10.0.0.50:80                             1        5           5           449       550
  -> 192.168.1.51:80                       0         3           2           228       275
  -> 192.168.1.52:8080                   0         3           2           221       275
CPS：每秒的鏈接數
InPPS：每秒流入包個數
OutPPS：每秒流出包個數
InBPS：每秒進入流量（字節）
OutBPS：每秒流出流量（字節）

 

在配置完規則以後須要保存和重載，規則保存在/etc/sysconfig/ipvsadm文件中

#保存ipvsadm規則至/etc/sysconfig/ipvsadm文件中
[root@lvs-server ~]# ipvsadm -S >/etc/sysconfig/ipvsadm
[root@lvs-server ~]# cat /etc/sysconfig/ipvsadm

lbaas-lvs實現：namespace lvs-xxx下

底層代碼實現：

class LvsDriver(agent_device_driver.AgentDeviceDriver):

[root@node0 ~]# ipvsadm -C

[root@node0 ~]# ipvsadm -ln --stats

IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Conns InPkts OutPkts InBytes OutBytes
-> RemoteAddress:Port
[root@node0 ~]# ipvsadm -A -u 10.33.46.64:9999 -s sh -p 120
[root@node0 ~]# ipvsadm -ln --stats
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Conns InPkts OutPkts InBytes OutBytes
-> RemoteAddress:Port
UDP 10.33.46.64:9999 0 0 0 0 0
[root@node0 ~]# ipvsadm -a -u 10.33.46.64:9999 -r 10.33.46.68:9999 -m -w 1
[root@node0 ~]# ipvsadm -ln --stats
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Conns InPkts OutPkts InBytes OutBytes
-> RemoteAddress:Port
UDP 10.33.46.64:9999 0 0 0 0 0
-> 10.33.46.68:9999 0 0 0 0 0
[root@node0 ~]# arping -c 1 10.33.46.68
ARPING 10.33.46.68 from 10.33.46.64 tap85d707e7-35
Unicast reply from 10.33.46.68 [FA:16:3E:0D:A6:AB] 1.310ms
Sent 1 probes (1 broadcast(s))
Received 1 response(s)
[root@node0 ~]# netcat -uvz -w 1 10.33.46.68 9999
[root@node0 ~]# netcat -uvz -w 1 10.33.46.64 9999
Warning: Host 10.33.46.64 isn't authoritative! (direct lookup mismatch)
10.33.46.64 -> mgm-net0 BUT mgm-net0 -> 172.30.65.2
[root@node0 ~]# netcat -uvz -w 1 10.33.46.68 9990
[root@node0 ~]# ipvsadm -ln --stats
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Conns InPkts OutPkts InBytes OutBytes
-> RemoteAddress:Port
UDP 10.33.46.64:9999 2 2 0 64 0
-> 10.33.46.68:9999 2 2 0 64 0
[root@node0 ~]# ipvsadm -ln --stats
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Conns InPkts OutPkts InBytes OutBytes
-> RemoteAddress:Port
UDP 10.33.46.64:9999 2 3 0 111 0
-> 10.33.46.68:9999 2 3 0 111 0
[root@node0 ~]# ipvsadm -ln --stats
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Conns InPkts OutPkts InBytes OutBytes
-> RemoteAddress:Port
UDP 10.33.46.64:9999 2 4 0 142 0
-> 10.33.46.68:9999 2 4 0 142 0

測試：

負載均衡器的成員虛機上，server監聽端口

[root@host-10-33-46-68 ~]# nc -ul  10.33.46.68 9999

[root@node0 ~]# ipvsadm -Z       ====清空統計數據
[root@node0 ~]# ipvsadm -ln --stats     ==查看統計
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Conns InPkts OutPkts InBytes OutBytes
-> RemoteAddress:Port
UDP 10.33.46.64:9999 0 0 0 0 0
-> 10.33.46.68:9999 0 0 0 0 0

client發包

[root@node2 ~]# echo "hello word"|nc -nuv 10.33.46.64 9999

Ncat: Version 7.50 ( https://nmap.org/ncat )
Ncat: Connected to 10.33.46.64:9999.
Ncat: 11 bytes sent, 0 bytes received in 0.02 seconds.

server端收到數據

[root@host-10-33-46-68 ~]# nc -ul 10.33.46.68 9999
hello word

[root@node0 ~]# ipvsadm -ln --stats

IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Conns InPkts OutPkts InBytes OutBytes
-> RemoteAddress:Port
UDP 10.33.46.64:9999 1 1 0 39 0
-> 10.33.46.68:9999 1 1 0 39 0

 

 

部署LVS-DR集羣
3.1 問題
使用LVS實現DR模式的集羣調度服務器，爲用戶提供Web服務：

路由器對外公網IP地址爲202.114.106.20

路由器內網IP地址爲192.168.0.254

路由是須要設置SNAT及DNAT功能

LVS調度器真實IP地址爲192.168.0.10

LVS調度器VIP地址設置爲192.168.0.253

真實Web服務器地址分別爲192.168.0.一、192.168.0.2

使用加權輪詢調度算法，真實服務器權重與其IP地址末尾數一致

3.2 方案
使用4臺虛擬機，1臺做爲Linux路由器、1臺做爲Director調度器、2臺做爲Real Server、物理機做爲客戶端，拓撲結構如圖-2所示。

Nginx和LVS對比的總結：   

1. Nginx工做在網絡的7層，因此它能夠針對http應用自己來作分流策略，好比針對域名、目錄結構等，相比之下LVS並不具有這樣的功能，因此Nginx單憑這點可利用的場合就遠多於LVS了；但Nginx有用的這些功能使其可調整度要高於LVS，因此常常要去觸碰觸碰，觸碰多了，人爲出問題的概率也就會大。    

2. Nginx對網絡穩定性的依賴較小，理論上只要ping得通，網頁訪問正常，Nginx就能連得通，這是Nginx的一大優點！Nginx同時還能區份內外網，若是是同時擁有內外網的節點，就至關於單機擁有了備份線路；LVS就比較依賴於網絡環境，目前來看服務器在同一網段內而且LVS使用direct方式分流，效果較能獲得保證。另外注意，LVS須要向託管商至少申請多一個ip來作Visual IP，貌似是不能用自己的IP來作VIP的。要作好LVS管理員，確實得跟進學習不少有關網絡通訊方面的知識，就再也不是一個HTTP那麼簡單了。

3. Nginx安裝和配置比較簡單，測試起來也很方便，由於它基本能把錯誤用日誌打印出來。LVS的安裝和配置、測試就要花比較長的時間了；LVS對網絡依賴比較大，不少時候不能配置成功都是由於網絡問題而不是配置問題，出了問題要解決也相應的會麻煩得多。 

4. Nginx也一樣能承受很高負載且穩定，但負載度和穩定度差LVS還有幾個等級：Nginx處理全部流量因此受限於機器IO和配置；自己的bug也仍是難以免的。 

5. Nginx能夠檢測到服務器內部的故障，好比根據服務器處理網頁返回的狀態碼、超時等等，而且會把返回錯誤的請求從新提交到另外一個節點。目前LVS中 ldirectd也能支持針對服務器內部的狀況來監控，但LVS的原理使其不能重發請求。好比用戶正在上傳一個文件，而處理該上傳的節點恰好在上傳過程當中出現故障，Nginx會把上傳切到另外一臺服務器從新處理，而LVS就直接斷掉了，若是是上傳一個很大的文件或者很重要的文件的話，用戶可能會所以而惱火。 

6. Nginx對請求的異步處理能夠幫助節點服務器減輕負載，假如使用 apache直接對外服務，那麼出現不少的窄帶連接時apache服務器將會佔用大 量內存而不能釋放，使用多一個Nginx作apache代理的話，這些窄帶連接會被Nginx擋住，apache上就不會堆積過多的請求，這樣就減小了至關多的資源佔用。這點使用squid也有相同的做用，即便squid自己配置爲不緩存，對apache仍是有很大幫助的。 

7. Nginx能支持http、https和email（email的功能比較少用），LVS所支持的應用在這點上會比Nginx更多。在使用上，通常最前端所採起的策略應是LVS，也就是DNS的指向應爲LVS均衡器，LVS的優勢令它很是適合作這個任務。重要的ip地址，最好交由LVS託管，好比數據庫的 ip、webservice服務器的ip等等，這些ip地址隨着時間推移，使用面會愈來愈大，若是更換ip則故障會接踵而至。因此將這些重要ip交給 LVS託管是最爲穩妥的，這樣作的惟一缺點是須要的VIP數量會比較多。Nginx可做爲LVS節點機器使用，一是能夠利用Nginx的功能，二是能夠利用Nginx的性能。固然這一層面也能夠直接使用squid，squid的功能方面就比Nginx弱很多了，性能上也有所遜色於Nginx。Nginx也可做爲中層代理使用，這一層面Nginx基本上無對手，惟一能夠撼動Nginx的就只有lighttpd了，不過lighttpd目前尚未能作到 Nginx徹底的功能，配置也不那麼清晰易讀。另外，中層代理的IP也是重要的，因此中層代理也擁有一個VIP和LVS是最完美的方案了。具體的應用還得具體分析，若是是比較小的網站（日PV小於1000萬），用Nginx就徹底能夠了，若是機器也很多，能夠用DNS輪詢，LVS所耗費的機器仍是比較多的；大型網站或者重要的服務，機器不發愁的時候，要多多考慮利用LVS。

如今對網絡負載均衡的使用是隨着網站規模的提高根據不一樣的階段來使用不一樣的技術：

第一階段：利用Nginx或HAProxy進行單點的負載均衡，這一階段服務器規模剛脫離開單服務器、單數據庫的模式，須要必定的負載均衡，可是仍然規模較小沒有專業的維護團隊來進行維護，也沒有須要進行大規模的網站部署。這樣利用Nginx或HAproxy就是第一選擇，此時這些東西上手快， 配置容易，在七層之上利用HTTP協議就能夠。這時是第一選擇。

第二階段：隨着網絡服務進一步擴大，這時單點的Nginx已經不能知足，這時使用LVS或者商用Array就是首要選擇，Nginx此時就做爲LVS或者Array的節點來使用，具體LVS或Array的是選擇是根據公司規模和預算來選擇，Array的應用交付功能很是強大，本人在某項目中使用過，性價比也遠高於F5，商用首選，可是通常來講這階段相關人才跟不上業務的提高，因此購買商業負載均衡已經成爲了必經之路。

第三階段：這時網絡服務已經成爲主流產品，此時隨着公司知名度也進一步擴展，相關人才的能力以及數量也隨之提高，這時不管從開發適合自身產品的定製，以及下降成原本講開源的LVS，已經成爲首選，這時LVS會成爲主流。    

最終造成比較理想的基本架構爲：Array/LVS — Nginx/Haproxy — Squid/Varnish — AppServer。