OVN實戰---《The OVN Load Balancer》翻譯
Overview
基於前面幾篇文章的基礎之上，我們接下來將要探索OVN中的load balancingz這一特性。但是在開始之前，我們先來回顧一下上一個lab中創建好的拓撲結構。
The lab network
The OVN logical network
The OVN Load Balancer
The OVN load balancer用於為OVN邏輯網絡空間中的負載提供基本的負載均衡的功能。由於它的簡單特性，它並不是用來替代基於應用的，專有的load balancer，後者往往提供了更多高級特性。
The load balancer利用一種基於哈希的算法來將對於VIP的請求均衡到邏輯地址空間中一個相關的IP地址池中。因為哈希值是根據用戶請求的頭部計算的，因此均衡的結果會非常隨機。而每個用戶的請求都會在連接期間和負載池中的某個成員互相綁定。OVN中的Load balancing既可以應用到logical switch中，也可以應用到logical router中。我們需要根據具體的需求來確定在什麽地方應用該特性。下面是對各種方法的說明：
當將該特性應用到logical routers時，我們需要考慮以下事項：
- 負載均衡可能被應用到一個"centralized" router（或者說一個gateway router）
- 基於上一點，路由器中的負載均衡將不是一個分布式的服務
當將該特性應用到logical switch時，我們需要考慮以下事項：
- 負載均衡是“分布式”的，它可能會應用到多個OVS hosts中
- logical switch上的負載均衡只能被應用於來自VIF的流量。這意味著它只能用於"client" logical switch而不是"server" logical switch
- 基於上一點，你可能需要根據你設計所需的擴展性將負載均衡應用到多個logical switch中
Using Our Fake "VMs" as Web Servers
為了模擬load balancer，我們需要在"dmz"上創建一對web server，每一個server都提供可識別的服務。為了讓演示更為簡單，我們將在vm1/vm2的namespace中用一行python代碼來啟動一個web server。下面就來啟動我們的web servers。
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
上述命令用於創建web server，並且在TCP端口8000進行監聽，它會通過顯示不同的文件內容來標識不同的虛擬機。
同時我們還想要測試到達web server的連通性。對此，我們將在Ubuntu host的global namespace利用curl進行檢測。確保已經安裝了curl命令
apt-get -y install curl
Configuring the Load Balancer Rules
首先，我們需要定義load balancing rules，VIP以及後端的IP池。下文命令的內容就是在OVN northbound DB中創建一個記錄，並且獲取它的UUID。為了測試，我們將使用"data" network中的10.127.0.254作為VIP，並且將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
上述命令在northbound DB的load_balancer表中創建了一個記錄，並且將結果UUID存放在了變量"uuid"中。我們將在下面的命令中引用該變量。
The Gateway Router As a Load Balancer
首先，讓我們將load balancer profile應用到OVN gateway router "edge1"中
ubuntu1
ovn-nbctl set logical_router edge1 load_balancer=$uuid
我們可以通過如下命令來確認
ovn-nbctl get logical_router edge1 load_balancer
現在，從任意Ubuntu host的global namespace中，我們都能連接VIP了
[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 server會發生什麽。因此我們停止了vm1 namespace中的python程序，以下是我得到的結果：
[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
我們可以發現，the load balancer並不會做任何健康檢查。因為我們現在假設健康檢查將由Kubernetes這樣的編排方案來解決，但是我們可以相信，這個特性會在以後添加進來的。
在進行下一個測試前先重啟vm1中的python web server。
負載均衡在外部是可以正常工作的，接著我們來看看，從內部的虛擬機訪問VIP會有什麽樣的結果。在ubuntu2的vm3執行curl的結果如下：
[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 network的拓撲結構，再仔細想想在vm3上發出curl請求之後的網絡流。同時再觀察一下python web server的日誌。我的日誌如下所示：
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 -
我們來看一下日誌中的client IP address。第一個IP來自ubuntu1，而第二個IP則是edge1。但是為什麽請求來自edge1而不是直接來自vm3呢？這是因為實現OVN負載均衡特性的開發者考慮了所謂的"proxy mode"，對於這種模式，某些情況下，load balancer會隱藏client side IP。那麽為什麽要這麽做呢？想想如果web server看到了vm3的真實的IP會怎麽樣。那麽server的應答會直接路由到vm3，繞過edge1中的load balancer。從vm3的角度來看，它對VIP發出了一個請求，但是卻從其中一個web server收到了應答，用的是web server的真實的IP地址。這顯然不是我們想要的，這也就是proxy-mode存在的原因。
現在讓我們先刪除load balancer profile，進入下一輪的實驗。
Configure the Load Balancer On a Logical Switch
接下去讓我們來看看，將load balancing rule應用到各個logical switch中會有什麽情況。因為之前我們從edge移除了load balancing，因此我們要做的第一步就是用internal VIP創建一個新的load balancer profile。這次我們將使用172.16.255.62。
ubuntu1
uuid=`ovn-nbctl create load_balancer vips:172.16.255.62="172.16.255.130,172.16.255.131"` echo $uuid
首先，我們將它設置到"inside" 這個logical switch
ubuntu1
# apply and verify ovn-nbctl set logical_switch inside load_balancer=$uuid ovn-nbctl get logical_switch inside load_balancer
從vm3測試連通性（vm3位於"inside"中）
[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
看起來好像工作正常。接著將load balancer從"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發起測試
[email protected]:~# ip netns exec vm3 curl 172.16.255.62:8000 ^C
很不幸，卡住了。那我們再從vm1發起測試（vm1位於"dmz"中）
[email protected]:~# ip netns exec vm1 curl 172.16.255.62:8000 ^C
結果同樣不令人滿意。這也就說明負載均衡應該設置到用戶的logical switch而不是server的logical switch
最後，清理配置
ubuntu1
ovn-nbctl clear logical_switch dmz load_balancer ovn-nbctl destroy load_balancer $uuid
Final Words
基礎的負載均衡是一個非常好的特性。將它內置於OVN中意味著在部署你自己的SDN時可以減少一些依賴。盡管這個特性非常小，但是我認為它已經覆蓋了絕大多數客戶的需求。希望經過一段時間後，它的某些限制，例如缺少健康檢查，能夠被解決。
在下一篇文章中，我將進一步探索OVN中的網絡安全相關的內容
原文鏈接：http://blog.spinhirne.com/2016/09/the-ovn-load-balancer.html
OVN實戰---《The OVN Load Balancer》翻譯