Openstack Neutron ： LBaaS v2

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

之因此稱之爲 lbaas v2，是由於Neutron的負載均衡的模型有過一次如上圖的進化，在v2的版本中，neutron 對負載均衡的架構有了一次很是大的調整，v2版本變得更符合行業標準，且驅動和功能擴展變得更爲簡單，除此以外新版本還容許一個負載均衡器下添加多組 Listener 監聽服務，以及加入了TLS。Lbaas v2沒法和lbaas v1同時運行，開啓lbaas v2須要中止lbaas v1。

改進後的LBaaS v2通過了更爲全面的測試，而且加入了更多的HTTP層代理的特性。並開始支持Active-Standby部署模式，後續版本中將進一部支持Active-Active。新版能夠說是負載均衡架構和功能的一次飛躍。

負載均衡概念

服務器池 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中使用。

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請求頭中的內容來執行負載均衡算法。並且做爲開源軟件，被普遍使用。

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部署方式。

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

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

Load Balancing as a Service : Liberty and Beyond

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

Otavia的加入也能夠說是openstack社區很清楚地看到了這一趨勢，並立志將負載均衡單獨拿出neutron做爲一個重要項目來對待。從Octavia支持的部署模式就能看出這一項目的野心。或許它將來將成爲一個跨虛擬機、容器、裸機的統一負載均衡服務。

相關標籤/搜索

每日一句

每一个你不满意的现在，都有一个你没有努力的曾经。