如何配置OVN負載均衡器？
譯者簡介：鄭敏先，就職于諾云系統(tǒng)(上海)有限公司。工作地點為南京的諾云研發(fā)中心。擔任解決方案工程師。
概述
基于我的上一篇文章，接下來我將介紹OVN的負載平衡特性。 但在開始之前，我們來看看上一個實驗中的配置。
OVN 負載均衡器
OVN負載均衡器旨在為OVN邏輯網(wǎng)絡空間內(nèi)的工作負載提供非常基本的負載均衡服務。由于其簡單的功能集，它不是設計用于替換那些為高級用例提供更多花里胡哨的功能的硬件負載均衡器。
其它負載均衡器大多使用基于哈希的算法來平衡VIP的請求到邏輯空間內(nèi)的相關IP地址池。由于哈希算法是使用客戶端請求的頭來計算的，所以平衡應當是隨機性的，其中每個單獨的客戶端請求在連接的持續(xù)時間內(nèi)始終選擇同一個負載均衡池的特定成員。
實驗物理網(wǎng)絡拓撲：
OVN 邏輯網(wǎng)絡拓撲:
OVN中的負載平衡可以應用于邏輯交換機或邏輯路由器。選擇何種方式取決于您的具體要求。每種方法都有注意事項。
當應用于邏輯路由器時，需要牢記以下注意事項：
- 負載平衡只能應用于“集中式”路由器(即網(wǎng)關路由器)。
- 第1個注意事項已經(jīng)決定了路由器上的負載平衡是非分布式服務。
應用于邏輯交換機時，需要牢記以下注意事項：
- 負載平衡是“分布式”的，因為它被應用于潛在的多個OVS主機。
- 僅在來自VIF(虛擬接口)的流量入口處評估邏輯交換機上的負載平衡。這意味著它必須應用在“客戶端”邏輯交換機上，而不是在“服務器”邏輯交換機上。
- 由于第2個注意事項，您可能需要根據(jù)您的設計規(guī)模對多個邏輯交換機應用負載平衡。
使用我們的的“偽虛擬機”作為Web服務器
為了演示負載均衡器，我們希望在我們的“dmz”中創(chuàng)建一對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上：
- mkdir /tmp/www
- echo "i am vm2" > /tmp/www/index.html
- cd /tmp/www
- ip netns exec vm2 python -m SimpleHTTPServer 8000
上面的命令將創(chuàng)建一個web服務器，監(jiān)聽TCP 8000。
我們還希望能夠測試與我們的網(wǎng)絡服務器的連通性。 為此，我們將從Ubuntu主機的全局命名空間使用curl。如果curl還沒有被安裝，那么需要先安裝它。
- apt-get -y install curl
配置負載均衡器規(guī)則
首先，需要定義我們的負載均衡規(guī)則，即VIP和后端服務器IP池。 這里涉及的是在OVN北向數(shù)據(jù)庫中創(chuàng)建一個條目，并捕獲生成的UUID。 在的這次實驗中，我們將使用位于實驗室“數(shù)據(jù)”網(wǎng)絡中的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
上述命令在北向數(shù)據(jù)庫的load_balancer表中創(chuàng)建一個條目，并將生成的UUID存儲到變量“uuid”。 我們將在后面的命令中引用這個變量。
在網(wǎng)關路由器上配置負載均衡
在OVN網(wǎng)關路由器“edge1”上開啟負載均衡器功能。
在ubuntu1上：
- ovn-nbctl set logical_router edge1 load_balancer=$uuid
您可以通過檢查edge1的數(shù)據(jù)庫條目來驗證是否成功開啟負載均衡器功能。
- ovn-nbctl get logical_router edge1 load_balancer
現(xiàn)在，我們可以從任何Ubuntu主機的全局命名空間連接到VIP。
- root@ubuntu1:~# curl 10.127.0.254:8000
- i am vm2
- root@ubuntu1:~# curl 10.127.0.254:8000
- i am vm1
- root@ubuntu1:~# curl 10.127.0.254:8000
- i am vm2
測試多次之后，可以確認負載平衡是相當隨機的。
讓我們看看禁用一個Web服務器會發(fā)生什么。 嘗試停止在vm1命名空間中運行的python進程。 這是我得到的輸出結果：
- root@ubuntu1:~# curl 10.127.0.254:8000
- curl: (7) Failed to connect to 10.127.0.254 port 8000: Connection refused
- root@ubuntu1:~# curl 10.127.0.254:8000
- i am vm2
如您所見，負載均衡器未執(zhí)行任何類型的運行狀態(tài)檢查。 目前的計劃是，運行狀態(tài)檢查將由協(xié)調(diào)解決方案(如Kubernetes)執(zhí)行，該功能將在未來某個時間點被加入。
在進行下一個測試之前，在vm1上重新啟動python Web服務器。
負載均衡器在虛擬機外部運行著，讓我們來看看從內(nèi)部虛擬機訪問VIP時會發(fā)生什么。
在ubuntu2上調(diào)用vm3的curl：
- root@ubuntu2:~# ip netns exec vm3 curl 10.127.0.254:8000
- i am vm1
- root@ubuntu2:~# ip netns exec vm3 curl 10.127.0.254:8000
- i am vm2
很棒， 這似乎也正常工作了，但有個地方很有意思。 來看我們的OVN網(wǎng)絡的邏輯圖，并考慮來自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?答案是，實現(xiàn)負載平衡的OVN開發(fā)人員使用了一種稱為“代理模式”的方法，其中負載均衡器在某些情況下隱藏了客戶端IP。為什么這是必要的?想想如果Web服務器看到vm3的真實IP會發(fā)生什么。來自服務器的響應將直接路由回到vm3，繞過edge1上的負載均衡器。從vm3的角度來看，它看起來像是向VIP發(fā)出請求，但收到了來自其中一個Web服務器的真實IP的回復。(如果不使用代理模式)負載均衡器就不工作了，這就是為什么代理模式功能很重要。
為了進行第二輪測試，先刪除負載均衡器配置
- ovn-nbctl clear logical_router edge1 load_balancer
- ovn-nbctl destroy load_balancer $uuid
在邏輯交換機上配置負載均衡
接下來的實驗將負載均衡規(guī)則應用到邏輯交換機，會發(fā)生什么呢? 由于我們將負載均衡從邊緣移開，***步需要創(chuàng)建一個帶有內(nèi)部VIP的新的負載均衡器。 我們將使用172.16.255.62作為VIP。
在ubuntu1上：
- uuid=`ovn-nbctl create load_balancer vips:172.16.255.62="172.16.255.130,172.16.255.131"`
- echo $uuid
***個測試:將負載均衡器應用于“內(nèi)部”邏輯交換機。
在ubuntu1上：
- # 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
- i am vm1
- root@ubuntu2:~# ip netns exec vm3 curl 172.16.255.62:8000
- i am vm1
- root@ubuntu2:~# ip netns exec vm3 curl 172.16.255.62:8000
- i am vm2
實驗貌似成功了。
再從“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測試:
- root@ubuntu2:~# ip netns exec vm3 curl 172.16.255.62:8000
- ^C
不好，它掛起了。 那我們試試從vm1(它也駐留在“dmz”)測試:
- root@ubuntu2:~# ip netns exec vm1 curl 172.16.255.62:8000
- ^C
也不行。 這強烈說明了對客戶端的邏輯交換機而不是服務器的邏輯交換機應用負載平衡的要求。一定要清理環(huán)境。
在ubuntu1上：
- ovn-nbctl clear logical_switch dmz load_balancer
- ovn-nbctl destroy load_balancer $uuid
結語
基本的負載平衡功能是非常有用的。 由于它直接構建到OVN中，意味著在你的SDN解決方案中又少部署一個軟件。 雖然OVN負載均衡器的功能不多，但是我認為它滿足了大部分用戶的需求。我也期望某些不足，如缺乏的健康檢查功能未來能夠在OVN中實現(xiàn)。。在下一篇文章中，我將介紹OVN的網(wǎng)絡安全功能。
