Openstack Neutron ： LBaaS v2

目錄

- LBaaS v2

- 負載均衡概念

    - 服務器池 Pool

    - 監聽器 Listener

        - L7 轉發策略 l7 policy

    - 負載均衡算法 Algorithms

    - 健康監測 Monitor

    - 會話保持 Session persistence

- 實現

    - HAproxy + keepalive

        - HAproxy

        - Keepalive

    - Octavia

- Load Balancing as a Service : Liberty and Beyond

 

LBaaS v2

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

• 服務器池 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、F5、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以外的值，如404、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

負載均衡本身的技術並不復雜，也發展得較為成熟，但如今負載均衡在各種雲上扮演着非常重要的角色，各個雲上與部署解決方案中都能看到它的身影。究其原因是其給租戶的應用帶來的彈性和可用性。雲的租戶可以在前端用戶完全無感知的情況下，按負載增刪后台服務器的數量，並實現服務的高可用，這非常符合雲“按需使用”“分布式高可用服務”的理念。所以當服務的彈性伸縮和高可用性成為雲計算的基本屬性時，負載均衡器就開始在雲上扮演不可替代的角色，可以說，不支持負載均衡的雲不能稱之為雲。而傳統的硬件負載均衡器無論是在可靠性、擴展性、可編程性、成本等方面都無法滿足雲供應商的需求。

 

 

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