OpenStack Neutron 之 Load Balance

OpenStack Neutron 之 Load Balance

負載均衡（Load Balance）是 OpenStack Neutron 支持的功能之一。負載均衡可以將網絡請求分發到多個實際處理請求的虛機上，這樣能有效處理高流量的網絡請求，負載均衡在現實中有不少使用場景。本文將基於 Neutron 所提供的負載均衡，介紹其基本概念、實現過程，並驗證其功能。

Neutron Load Balance 簡介

負載均衡(Load Balance)其實早在 OpenStack 的 Grizzly 版本就集成到 Neutron 中。它做爲 OpenStack Neutron 項目的高級服務之一，可以均衡的將所收到的網絡流量分配給指定的實例們，而且可以確保工做負載以可預見的方式分配到這些實例中，從而達到更高效的使用系統資源的目的。這裏的實例，指的是 OpenStack 管理的虛機。 在 Neutron 項目內部，習慣將負載均衡稱爲 LBaaS(Load Balance as a Service)。自集成到 Neutron 以來，LBaaS 經歷過幾回大的變化。截止至本文，OpenStack 社區正在進行 Kilo 版本的開發，這個版本中，對 LBaaS 的變化主要有：

• 代碼從 Neutron 中抽離，直接由獨立的項目管理
• LBaaS V2 的實現

LbaaS V2 是一次較大的改變，它修改了目前的數據結構，爲更復雜的用戶場景提供了可能，具體的變化能夠參考 OpenStack 社區的文檔。因爲目前社區提供的版本仍然是 LBaaS V1，而且實現 V2 以後將繼續對 V1 兼容，所以，本文以後的內容，如無特殊說明都是基於 V1。

Load Balance 基本概念

要了解 Neutron 的負載均衡，首先須要對其內部的數據類型和基本概念有必定的瞭解。

圖 1. LBaaS V1 邏輯架構

圖 1 顯示了 LBaaS 的邏輯結構，接下來依次介紹其含義。

VIP

VIP(Virturl IP address)就是負載均衡對外提供服務的地址。VIP 有本身的 IP 地址，並且通常都能經過公網進行訪問。在 Neutron 中，VIP 對應着二層虛擬設備 br-int 上的一個 port。當負載均衡 Pool 裏面至少有一個 member 時，VIP 纔有存在的意義，由於這時至少有一個實際的 OpenStack 實例在處理網絡請求。VIP 負責將網絡流量分發到各個 member，Neutron LBaaS 中支持如下三種網絡流量的分發方式。

• Round robin：平均的將網絡流量分發到多個 member。
• Source IP：從某一個特定 IP 發來的網絡請求，老是發到特定的 member。
• Least connections：將收到的網絡請求，發給當前負載均衡池中鏈接數最少的 member。若是全部的 member 鏈接數同樣，則遵循 Round robin 的方式。

Neutron 中，VIP 還支持設置最大鏈接數(connection-limit)，這樣在網絡流量大時，能夠保護負載均衡池。最大鏈接數能夠設置成-1，這時不限制鏈接數。

Pool

Pool 是 LBaaS V1 中的 root resource。全部的其餘資源都是基於 pool 來建立的。Neutron LBaaS 默認以 HAProxy 爲 Driver 實現。在默認狀況下，一個 pool 對應着一個獨立的 HAProxy 進程，一個獨立的 namespace。目前一個 pool 只能有一個 VIP，在 LBaaS V2 裏面，能夠容許一個 pool 對應多個 VIP。

Member

Member 對應的是 pool 裏面處理網絡請求的 OpenStack 實例。在 OpenStack Neutron 中，member 是一個邏輯關係，表示着實例與 pool 的對應關係。這也就是說，一個 OpenStack 實例，能夠對應不一樣的 pool，在 Neutron 的 LBaaS 裏面建立多個 member。在建立 member 時所選擇的實例，必須與 pool 處於同一個 subnet，不然將不能工做。

Health monitor（健康監控）

Health monitor 只有在關聯 pool 時纔有意義。它用來監測 pool 裏面 member 的狀態。它會以輪詢的方式，去查詢各個 member，若是 member 未做出響應，它會更新 member 的狀態至 INACTIVE，這樣在 VIP 分發網絡請求時，就不會考慮這個 member 了。若是 member 恢復了響應，它會更新 member 的狀態至 ACTIVE。這時，member 會從新出如今 VIP 的分發列表中。

與其餘的概念不一樣，Health monitor 在 Neutron 的負載均衡中不是必須的。也就是說，沒有 Health monitor，也能組成一個負載均衡池。可是，若是沒有 Health monitor，pool 會一直認爲全部的 member 都是 ACTIVE 狀態，這樣全部的 member 會一直出如今 VIP 的分發列表中，哪怕 member 對應的實例不能響應網絡請求。這在實際應用中會形成負載均衡的響應異常。

Neutron Load Balance 的實現

Neutron LBaaS 是基於 Neutron 實現的，pythone-neutronclient 中包含了 LBaaS 相關的命令，LBaaS 的數據也是存儲在 Neutron 的數據庫中。LBaaS 的程序架構也遵循着 Neutron 對 service plugin 的要求。具體如圖 2 所示。

圖 2. LBaaS 代碼結構

從圖中能夠看出，代碼主要由三部分組成：

• Extension：負責處理 REST API 請求，並將 REST API 請求轉發到 Plugin。
• Plugin：處理核心邏輯，管理 DB 的讀寫。
• Agent：處理並響應由 Plugin 發來的請求，管理 Driver。前面說過，OpenStack Neutron 默認採用 HAProxy 做爲 driver。

回頁首

功能驗證

通過前面的說明，您對 Neutron 的負載均衡應該有了必定的瞭解。這一部分主要介紹如何配置、使用 Neutron 的負載均衡。

配置

IBM Cloud Manager with OpenStack 默認會配置好 Neutron 的負載均衡。這裏再說明一下相關的配置項，這裏的配置都是基於 Neutron LBaaS 的默認 driver - HAProxy 來講明的。 首先須要修改 Neutron 的配置，這樣 Neutron 在啓動的時候就會加載 LBaaS plugin。

清單 1. 修改 Neutron 配置以加載 LBaaS Plugin

# vi /etc/nova/neutron.conf
service_plugins=neutron.services.loadbalancer.plugin
.LoadBalancerPlugin
service_provider=LOADBALANCER:Haproxy:neutron.services
.loadbalancer.drivers.HAProxy.plugin_driver
.HaproxyOnHostPluginDriver:default

出於排版的須要，清單 1 中的鍵值對被分紅了幾行，在實際的配置文件中，每一組鍵值對必須存在於同一行中。清單 1 中的 service_plugins 必須是在原有的 service_plugins 上追加，即 neutron.conf 裏面只能有一個 service_plugins 鍵，這個鍵能夠對應多個值，以逗號分隔。清單 2 中的 service_provider 能夠單獨存在，即 neutron.conf 裏面能夠有多個 service_provider 存在。接下來須要修改 neutron-lbaas-agent 的配置，使得 neutron-lbaas-agent 能正常啓動。

清單 2. 修改 neutron-lbaas-agent 配置

# vi /etc/neutron/lbaas_agent.ini 
device_driver=neutron.services.loadbalancer.drivers
.HAProxy.namespace_driver.HaproxyNSDriver
interface_driver=neutron.agent.linux.interface
.OVSInterfaceDriver

與清單 1 相似，在實際的配置文件中，每一組鍵值對必須存在於同一行中。清單 2 中的 device_driver 對應的是實際作負載均衡的設備的 driver。清單 2 中的 interface_driver 是指 Neutron 選用的虛擬網卡管理驅動。IBM Cloud Manager with OpenStack 默認採用 OpenVSwitch，所以這裏配置成 OVSInterfaceDriver。 最後重啓相應的服務便可。

清單 3. 重啓服務以使配置生效

# service neutron-server restart
# service neutron-lbaas-agent restart

OpenStack Horizon 帶有一個 Neutron LBaaS 的管理界面，這個界面默認是不打開的。須要修改 Horizon 的配置並重啓 HTTP server 來打開，具體操做如清單 4 所示。

清單 4. 修改 Horizon 配置並重啓服務

# vi /etc/openstack-dashboard/local_settings
OPENSTACK_NEUTRON_NETWORK = {
‘enable_lb’: True,
}
# service httpd restart

建立資源

這一部分介紹如何從零開始，在 Neutron 裏面創建一個可用的負載均衡池。如前面介紹的，pool 是 Neutron LBaaS 中的 root resource，所以，首先應該建立一個 pool，再建立 pool 裏面的 member 和 VIP，最後建立 Health monitor。本文以命令行形式建立資源。若是按照清單 4 中在 OpenStack Horizon 中打開了 LBaaS 的管理界面，也能夠經過 OpenStack Horizon 建立負載均衡資源，過程相似，這裏就再也不贅述。

清單 5. 建立 LBaaS 資源

# neutron lb-pool-create --lb-method ROUND_ROBIN \
--name mypool --protocol HTTP --subnet-id SUBNET_UUID \
--provider PROVIDER_NAME
# neutron lb-member-create --address 10.0.0.3 \
--protocol-port 80 mypool
# neutron lb-member-create --address 10.0.0.4 \
--protocol-port 80 mypool
# neutron lb-vip-create --name myvip --protocol-port 80 \
--protocol HTTP –-subnet-id SUBNET_UUID –-address 10.0.0.10
# neutron lb-Healthmonitor-create --delay 3 --type HTTP \
--max-retries 3 --timeout 3
# neutron lb-Healthmonitor-associate  HEALTHMONITOR_UUID mypool

清單 5 中，首先建立了一個 pool，指定的網絡流量分發方式是 Round robin，提供服務的協議是 HTTP，這在前面都有說明。--subnet-id 是但願添加的 member 所在的 subnet 的 id，這在前面也有說明。建立 member 時，指定的--address 是實例對應的 IP 地址。在建立 VIP 時，指定的--address 是一個空閒的 IP，這個參數能夠不指定，這裏爲了後面的結果驗證寫上一個固定的地址。在建立 member 和 VIP 時，都必須指定 pool，它們只能屬於一個 pool。而建立 Health monitor 的時候，不用指定 pool，經過一條額外的指令關聯 pool。一個 Health monitor 能夠關聯多個 pool。建立 Health monitor 時，參數的意義分別是：--delay 輪詢的間隔；--type 輪詢時查詢的方式，支持 HTTP、HTTPS、TCP 和 PING；--max-retries 輪詢失敗的最大嘗試次數；--timeout 每次輪詢的超時時間。

驗證結果

在驗證結果以前，須要在加入到負載均衡池中的 OpenStack 實例上面運行 HTTP server，爲了區分，本文中實例裏的 HTTP server 返回本身的 IP 地址做爲響應內容。運行 HTTP server 的方法因系統和環境而不一樣，可是比較簡單，網上也有說明，這裏再也不贅述。 按照以前建立的資源，負載均衡池如今對外提供的服務地址是 http://10.0.0.10。在這裏，寫一個測試腳本 test_lb_vip.sh，見清單 6，用來訪問 VIP 的服務地址 10 次。

清單 6：測試負載均衡的腳本

#!/bin/bash
for k in $( seq 1 10 )
do
curl http://10.0.0.10
done

運行測試腳本，最後輸出的結果見清單 7。

清單 7. 測試結果

10.0.0.3
10.0.0.4
10.0.0.3
10.0.0.4
10.0.0.3
10.0.0.4
10.0.0.3
10.0.0.4
10.0.0.3
10.0.0.4

從清單 7 的測試結果看，訪問 VIP http://10.0.0.10 的 10 次網絡流量，被平均的分配到了負載均衡池的兩個 member 中，這符合預期。 在實際的使用場景中，通常是但願提供服務的 VIP 地址是公網地址，而實際處理網絡流量的 member 是私網地址。基於以前建立的資源，只需按照清單 8 給 VIP 關聯上一個 floatingIP 便可實現。

清單 8. 爲 VIP 添加公網 IP

# neutron floatingip-create PUBLIC_NETWORK
# neutron floatingip-associate FLOATINGIP_ID VIP_PORT

這樣在 Neutron 的路由層(三層)，創建了一個由 floating IP 對應的公網 IP 和 VIP 對應的私網 IP 組成的對應關係。全部從公網來的網絡流量，通過 Neutron 的路由層，都轉到了 VIP 對應的私網 IP，從而達到了 VIP 以公網地址的形式提供服務的目的。將清單 6 中的測試腳本改爲對應的 floatingIP 地址，從新運行，將獲得與清單 7 同樣的結果。

總結

負載均衡在實際中，有很普遍的應用場景。OpenStack Neutron 默認以 HAProxy 爲負載均衡的 driver，同時也支持 A10 network、netscaler、radware 等做爲 driver。IBM Cloud Manager with OpenStack 從 4.2 版本開始支持負載均衡，並以 HAProxy 做爲 driver。結合 IBM 高性能的 Power 機器和 OpenStack 便捷的 IaaS(Infrastructure as a Service)管理功能，能夠爲用戶提供更多的應用場景。

來源： http://www.ibm.com/developerworks/cn/cloud/library/1506_xiaohh_openstacklb/

來自爲知筆記(Wiz)