SDN控制器之OVN實驗四：配置OVN負載均衡器
網路拓撲
基於我的上一篇文章，接下來我將介紹OVN的負載平衡特性。 但在開始之前，我們來看看上一個實驗中的配置。
實驗物理網路拓撲：
OVN 邏輯網路拓撲:
OVN 負載均衡器
OVN負載均衡器旨在為OVN邏輯網路空間內的工作負載提供非常基本的負載均衡服務。由於其簡單的功能集，它不是設計用於替換那些為高階用例提供更多花裡胡哨的功能的硬體負載均衡器。
其它負載均衡器大多使用基於雜湊的演算法來平衡VIP的請求到邏輯空間內的相關IP地址池。由於雜湊演算法是使用客戶端請求的頭來計算的，所以平衡應當是隨機性的，其中每個單獨的客戶端請求在連線的持續時間內始終選擇同一個負載均衡池的特定成員。
OVN中的負載平衡可以應用於邏輯交換機或邏輯路由器。選擇何種方式取決於您的具體要求。每種方法都有注意事項。
當應用於邏輯路由器時，需要牢記以下注意事項：
(1)負載平衡只能應用於“集中式”路由器（即閘道器路由器）。
(2)第1個注意事項已經決定了路由器上的負載平衡是非分散式服務。
應用於邏輯交換機時，需要牢記以下注意事項：
(1)負載平衡是“分散式”的，因為它被應用於潛在的多個OVS主機。
(2)僅在來自VIF(虛擬介面)的流量入口處評估邏輯交換機上的負載平衡。這意味著它必須應用在“客戶端”邏輯交換機上，而不是在“伺服器”邏輯交換機上。
(3)由於第2個注意事項，您可能需要根據您的設計規模對多個邏輯交換機應用負載平衡。
使用我們的的“偽虛擬機器”作為Web伺服器
為了演示負載均衡器，我們希望在我們的“dmz”中建立一對Web伺服器，Web伺服器提供一個可識別它們身份的檔案。 為了簡化實驗，我們將使用在我們的vm1/vm2名稱空間中分別執行的一個python web伺服器。
讓我們啟動web伺服器吧。
在ubuntu2上：
| 1 2 3 4 |
mkdir /tmp/www echo "i am vm1" > /tmp/www/index.html cd /tmp/www ip netns exec vm1 python -m SimpleHTTPServer 8000 |
在ubuntu3上：
| 1 2 3 4 |
mkdir /tmp/www echo "i am vm2" > /tmp/www/index.html cd /tmp/www ip netns exec vm2 python -m SimpleHTTPServer 8000 |
上面的命令將建立一個web伺服器，監聽TCP 8000。
我們還希望能夠測試與我們的網路伺服器的連通性。 為此，我們將從Ubuntu主機的全域性名稱空間使用curl。如果curl還沒有被安裝，那麼需要先安裝它。
| 1 |
apt-get -y install curl |
配置負載均衡器規則
首先，需要定義我們的負載均衡規則，即VIP和後端伺服器IP池。 這裡涉及的是在OVN北向資料庫中建立一個條目，並捕獲生成的UUID。 在的這次實驗中，我們將使用位於實驗室“資料”網路中的VIP 10.127.0.254。 我們將使用vm1/vm2的地址作為池IP。
在ubuntu1上：
| 1 2 |
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”上開啟負載均衡器功能。
在ubuntu1上：
| 1 |
ovn-nbctl set logical_router edge1 load_balancer=$uuid |
您可以通過檢查edge1的資料庫條目來驗證是否成功開啟負載均衡器功能。
| 1 |
ovn-nbctl get logical_router edge1 load_balancer |
現在，我們可以從任何Ubuntu主機的全域性名稱空間連線到VIP。
| 1 2 3 4 5 6 |
[email protected]:~# curl 10.127.0.254:8000 i am vm2 [email protected]:~# curl 10.127.0.254:8000 i am vm1 [email protected]:~# curl 10.127.0.254:8000 i am vm2 |
測試多次之後，可以確認負載平衡是相當隨機的。
讓我們看看禁用一個Web伺服器會發生什麼。 嘗試停止在vm1名稱空間中執行的python程序。 這是我得到的輸出結果：
| 1 2 3 4 |
[email protected]:~# curl 10.127.0.254:8000 curl: (7) Failed to connect to 10.127.0.254 port 8000: Connection refused [email protected]:~# curl 10.127.0.254:8000 i am vm2 |
如您所見，負載均衡器未執行任何型別的執行狀態檢查。 目前的計劃是，執行狀態檢查將由協調解決方案（如Kubernetes）執行，該功能將在未來某個時間點被加入。
在進行下一個測試之前，在vm1上重新啟動python Web伺服器。
負載均衡器在虛擬機器外部執行著，讓我們來看看從內部虛擬機器訪問VIP時會發生什麼。
在ubuntu2上呼叫vm3的curl：
| 1 2 3 4 |
[email protected]:~# ip netns exec vm3 curl 10.127.0.254:8000 i am vm1 [email protected]:~# ip netns exec vm3 curl 10.127.0.254:8000 i am vm2 |
很棒， 這似乎也正常工作了，但有個地方很有意思。 來看我們的OVN網路的邏輯圖，並考慮來自vm3的curl請求的流量。 另外，看看python web伺服器的部分日誌：
| 1 2 |
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的回覆。（如果不使用代理模式）負載均衡器就不工作了，這就是為什麼代理模式功能很重要。
為了進行第二輪測試，先刪除負載均衡器配置
| 1 2 |
ovn-nbctl clear logical_router edge1 load_balancer ovn-nbctl destroy load_balancer $uuid |
在邏輯交換機上配置負載均衡
接下來的實驗將負載均衡規則應用到邏輯交換機，會發生什麼呢？ 由於我們將負載均衡從邊緣移開，第一步需要建立一個帶有內部VIP的新的負載均衡器。 我們將使用172.16.255.62作為VIP。
在ubuntu1上：
| 1 2 |
uuid=`ovn-nbctl create load_balancer vips:172.16.255.62="172.16.255.130,172.16.255.131"` echo $uuid |
第一個測試:將負載均衡器應用於“內部”邏輯交換機。
在ubuntu1上：
| 1 2 3 |
# apply and verify ovn-nbctl set logical_switch inside load_balancer=$uuid ovn-nbctl get logical_switch inside load_balancer |
然後從vm3測試（位於“inside”）:
| 1 2 3 4 5 6 |
[email protected]:~# ip netns exec vm3 curl 172.16.255.62:8000 i am vm1 [email protected]:~# ip netns exec vm3 curl 172.16.255.62:8000 i am vm1 [email protected]:~# ip netns exec vm3 curl 172.16.255.62:8000 i am vm2 |
實驗貌似成功了。
再從“inside”刪除負載均衡器，並將其應用於“dmz”。在ubuntu1上：
| 1 2 3 |
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測試:
| 1 2 |
[email protected]:~# ip netns exec vm3 curl 172.16.255.62:8000 ^C |
不好，它掛起了。 那我們試試從vm1（它也駐留在“dmz”）測試:
| 1 2 |
[email protected]:~# ip netns exec vm1 curl 172.16.255.62:8000 ^C |
也不行。 這強烈說明了對客戶端的邏輯交換機而不是伺服器的邏輯交換機應用負載平衡的要求。一定要清理環境。
在ubuntu1上：
| 1 2 |
ovn-nbctl clear logical_switch dmz load_balancer ovn-nbctl destroy load_balancer $uuid |
結語
基本的負載平衡功能是非常有用的。 由於它直接構建到OVN中，意味著在你的SDN解決方案中又少部署一個軟體。 雖然OVN負載均衡器的功能不多，但是我認為它滿足了大部分使用者的需求。我也期望某些不足，如缺乏的健康檢查功能未來能夠在OVN中實現。。在下一篇文章中，我將介紹OVN的網路安全功能。
原文：https://blog.csdn.net/zhengmx100/article/details/72822606