譯者簡介：鄭敏先，就職于諾雲系統(上海)有限公司。工作地點為南京的諾雲研發中心。擔任解決方案工程師。
概述
基于我的上一篇文章，接下來我将介紹ovn的負載平衡特性。 但在開始之前，我們來看看上一個實驗中的配置。
ovn 負載均衡器
ovn負載均衡器旨在為ovn邏輯網絡空間内的工作負載提供非常基本的負載均衡服務。由于其簡單的功能集，它不是設計用于替換那些為進階用例提供更多花裡胡哨的功能的硬體負載均衡器。
其它負載均衡器大多使用基于哈希的算法來平衡vip的請求到邏輯空間内的相關ip位址池。由于雜湊演算法是使用用戶端請求的頭來計算的，是以平衡應當是随機性的，其中每個單獨的用戶端請求在連接配接的持續時間内始終選擇同一個負載均衡池的特定成員。
實驗實體網絡拓撲：
ovn 邏輯網絡拓撲:
ovn中的負載平衡可以應用于邏輯交換機或邏輯路由器。選擇何種方式取決于您的具體要求。每種方法都有注意事項。
當應用于邏輯路由器時，需要牢記以下注意事項：
負載平衡隻能應用于“集中式”路由器(即網關路由器)。
第1個注意事項已經決定了路由器上的負載平衡是非分布式服務。
應用于邏輯交換機時，需要牢記以下注意事項：
負載平衡是“分布式”的，因為它被應用于潛在的多個ovs主機。
僅在來自vif(虛拟接口)的流量入口處評估邏輯交換機上的負載平衡。這意味着它必須應用在“用戶端”邏輯交換機上，而不是在“伺服器”邏輯交換機上。
由于第2個注意事項，您可能需要根據您的設計規模對多個邏輯交換機應用負載平衡。
使用我們的的“僞虛拟機”作為web伺服器
為了示範負載均衡器，我們希望在我們的“dmz”中建立一對web伺服器，web伺服器提供一個可識别它們身份的檔案。 為了簡化實驗，我們将使用在我們的vm1/vm2命名空間中分别運作的一個python web伺服器。
讓我們啟動web伺服器吧。
在ubuntu2上：
mkdir /tmp/www
echo "i am vm1" > /tmp/www/index.html
cd /tmp/www
ip netns exec vm1 python -m simplehttpserver 8000
在ubuntu3上：
echo "i am vm2" > /tmp/www/index.html
ip netns exec vm2 python -m simplehttpserver 8000
上面的指令将建立一個web伺服器，監聽tcp 8000。
我們還希望能夠測試與我們的網絡伺服器的連通性。 為此，我們将從ubuntu主機的全局命名空間使用curl。如果curl還沒有被安裝，那麼需要先安裝它。
apt-get -y install curl
配置負載均衡器規則
首先，需要定義我們的負載均衡規則，即vip和後端伺服器ip池。 這裡涉及的是在ovn北向資料庫中建立一個條目，并捕獲生成的uuid。 在的這次實驗中，我們将使用位于實驗室“資料”網絡中的vip 10.127.0.254。 我們将使用vm1/vm2的位址作為池ip。
在ubuntu1上：
uuid=`ovn-nbctl create load_balancer vips:10.127.0.254="172.16.255.130,172.16.255.131"`
echo $uuid
上述指令在北向資料庫的load_balancer表中建立一個條目，并将生成的uuid存儲到變量“uuid”。 我們将在後面的指令中引用這個變量。
在網關路由器上配置負載均衡
在ovn網關路由器“edge1”上開啟負載均衡器功能。
ovn-nbctl set logical_router edge1 load_balancer=$uuid
您可以通過檢查edge1的資料庫條目來驗證是否成功開啟負載均衡器功能。
ovn-nbctl get logical_router edge1 load_balancer
現在，我們可以從任何ubuntu主機的全局命名空間連接配接到vip。
root@ubuntu1:~# curl 10.127.0.254:8000
i am vm2
i am vm1
測試多次之後，可以确認負載平衡是相當随機的。
讓我們看看禁用一個web伺服器會發生什麼。 嘗試停止在vm1命名空間中運作的python程序。 這是我得到的輸出結果：
curl: (7) failed to connect to 10.127.0.254 port 8000: connection refused
如您所見，負載均衡器未執行任何類型的運作狀态檢查。 目前的計劃是，運作狀态檢查将由協調解決方案(如kubernetes)執行，該功能将在未來某個時間點被加入。
在進行下一個測試之前，在vm1上重新啟動python web伺服器。
負載均衡器在虛拟機外部運作着，讓我們來看看從内部虛拟機通路vip時會發生什麼。
在ubuntu2上調用vm3的curl：
root@ubuntu2:~# ip netns exec vm3 curl 10.127.0.254:8000
很棒， 這似乎也正常工作了，但有個地方很有意思。 來看我們的ovn網絡的邏輯圖，并考慮來自vm3的curl請求的流量。 另外，看看python web伺服器的部分日志：
10.127.0.130 - - [29/sep/2016 09:53:44] "get / http/1.1" 200 -
10.127.0.129 - - [29/sep/2016 09:57:42] "get / http/1.1" 200 -
注意日志中的用戶端ip位址。第一個ip是上一輪測試的ubuntu1。第二個ip是edge1(來自vm3的請求)。為什麼請求來自edge1而不是直接來自vm3?答案是，實作負載平衡的ovn開發人員使用了一種稱為“代理模式”的方法，其中負載均衡器在某些情況下隐藏了用戶端ip。為什麼這是必要的?想想如果web伺服器看到vm3的真實ip會發生什麼。來自伺服器的響應将直接路由回到vm3，繞過edge1上的負載均衡器。從vm3的角度來看，它看起來像是向vip送出請求，但收到了來自其中一個web伺服器的真實ip的回複。(如果不使用代理模式)負載均衡器就不工作了，這就是為什麼代理模式功能很重要。
為了進行第二輪測試，先删除負載均衡器配置
ovn-nbctl clear logical_router edge1 load_balancer
ovn-nbctl destroy load_balancer $uuid
在邏輯交換機上配置負載均衡
接下來的實驗将負載均衡規則應用到邏輯交換機，會發生什麼呢? 由于我們将負載均衡從邊緣移開，第一步需要建立一個帶有内部vip的新的負載均衡器。 我們将使用172.16.255.62作為vip。
uuid=`ovn-nbctl create load_balancer vips:172.16.255.62="172.16.255.130,172.16.255.131"`
第一個測試:将負載均衡器應用于“内部”邏輯交換機。
# apply and verify
ovn-nbctl set logical_switch inside load_balancer=$uuid
ovn-nbctl get logical_switch inside load_balancer
然後從vm3測試(位于“inside”):
root@ubuntu2:~# ip netns exec vm3 curl 172.16.255.62:8000
實驗貌似成功了。
再從“inside”删除負載均衡器，并将其應用于“dmz”。在ubuntu1上：
ovn-nbctl clear logical_switch inside load_balancer
ovn-nbctl set logical_switch dmz load_balancer=$uuid
ovn-nbctl get logical_switch dmz load_balancer
然後再次從 vm3測試:
^c
不好，它挂起了。 那我們試試從vm1(它也駐留在“dmz”)測試:
root@ubuntu2:~# ip netns exec vm1 curl 172.16.255.62:8000
也不行。 這強烈說明了對用戶端的邏輯交換機而不是伺服器的邏輯交換機應用負載平衡的要求。一定要清理環境。
ovn-nbctl clear logical_switch dmz load_balancer
結語
基本的負載平衡功能是非常有用的。 由于它直接建構到ovn中，意味着在你的sdn解決方案中又少部署一個軟體。 雖然ovn負載均衡器的功能不多，但是我認為它滿足了大部分使用者的需求。我也期望某些不足，如缺乏的健康檢查功能未來能夠在ovn中實作。。在下一篇文章中，我将介紹ovn的網絡安全功能。
作者：佚名
來源：51cto