note：網上有很多關於軟件定義存儲的負面消息。有人說，在存儲發展的歷史中，存儲早就不僅僅是硬件了，軟件在存儲中有一個核心的地位；還有人覺得應該做軟件隱藏的存儲，因爲軟件這個事讓存儲的管理變得很難，這些軟件包括：重複數據刪除，自動精簡配置等；也有些人說，我們並不需要更多的軟件，我們需要看到的是更少的軟件；也有人說，存儲本來就是軟件定義的，所有的存儲都需要軟件；尤其是當存儲成爲分享資源時（大數據和數據中心的存儲），往往會被複雜而神祕的軟件包圍。很多人說，每次更新系統時，就會增加越來越多的存儲軟件，從快照到複製再到自動精簡配置等。
而當我懷着不太樂觀的情緒，看了IOFlow論文[1]的摘要的時候，特別驚喜。對於上面所有的對於軟件定義存儲的疑惑都通通打消了。
Overview
在現在的數據中心中，應用程序到存儲設備的I/O路徑都特別長，其中包括很多的層次或者說是stages，具體是怎樣的可以點擊這裏，而且這些層次之間的接口還是不透明的(就像隧道)，這使得要enforce一個end-to-end的policy (比如對於不同的tenant，需要不同的存儲帶寬，比如熱數據和冷數據，比如存儲服務的不同等級的客戶)很難（相對於軟件定義網絡的控制邏輯而言，因爲網絡包的頭部很好處理）。相對於SDN的OpenFlow，這裏設計了IOFlow，在hypervisor階段和storage
server階段進行實施。
break：對疑問的解釋是，IOFlow不是單純的增加軟件，而是用軟件去管理不透明的軟件和硬件，從而實現管理和監控，看到的軟件當然也就更少了(只有控制器的程序，還可以方便的監控)。而且更新系統的時候，這些存儲軟件根本就不需要更新啦，邏輯都在控制器上。
但是既然是軟件定義存儲，肯定有數據平面，控制器，然後有控制器的應用程序。那麼問題來了，他們各自的作用是什麼？然後是怎麼交互的？下面將給出詳細的闡述。
Stage
在軟件定義存儲裏，這數據平面跟軟件定義網絡的數據平面又不一樣，在存儲領域，這數據平面是一層層的，很深；而在軟件定義網絡裏面，數據平面是plate的，很廣(轉發路由的算法多)。
IOFlow把數據平面稱爲stage，根據queues和排隊規則來implement traffic流量的區別。(和SDN的 flow table不一樣，flow table需要根據流規則來轉發）。排隊規則將不同頭部（原地址（比如VM ID）和目的地址（比如shared storage的ID））的I/O請求映射到不同的隊列上面，然後根據要求配置隊列的屬性。這樣，這些隊列便可以通過service 特性來控制隊列處理過程的速度，然後使用route特性來引導I/O請求到下一個stage。
首先，控制器的discovery組件使用getqueueinfo來獲得這個stage是哪種io頭部stage(比如說是網絡頭部呢，還是smb頭部呢)，然後控制器可以使用createqueuerule來創建排隊規則，把到來的IO packets分配給這個stage的queues。然後就可以配置隊列的路由和速度屬性了。
note：在這些層次化的模塊之間進行轉發和管理有點太不可思議，層次化的模塊本來就環環相扣，誰也少不了誰，怎麼轉發本來就都已經是確定了的。所以這裏Control功能只是更精確的控制轉發速度以及爲了安全特性而設置的route功能。
note：IOFlow是微軟做的，不開源。IOFlow的虛擬存儲是基於virtual disk的，但是我想用的fcoe的虛擬化的層次不是基於virtual disk 的，而是vm-based的，所以基於這種情況的存儲stage是不一樣的。
雖然stage的原理大概能夠說清楚了，但是如果要是問怎麼控制流速？服務特性除了流速還有什麼，分別採用什麼機制來進行控制？怎麼控制路由？你能不能舉個例子？在stage部分還有沒有什麼特殊處理？下面一一解答。
要怎麼控制流速呢？在stage階段是採用一種叫做token bucket的機制。令牌環的工作原理是，信息幀在傳輸時，如果有足夠的令牌就能夠傳輸，否則不能(在這裏，token多代表更高的帶寬，少則代表更低的速率)。隊列的速度也是按照令牌的速率。然而存儲的請求和網絡packets不同，所以令牌環的設計也不同。對於網絡packets，一個byte就代表一個令牌環，對於存儲而言，因爲不同的請求，read，write和create等的處理方式都不一樣，所以令牌環的設計要基於tenant的requests，令牌環要根據請求的不同來設計。然而他們之間也不是線性關係，因爲在存儲的backend，每種請求的處理時間又和請求大小，數據局部性以及設備類型相關，所以爲了測量io請求的開銷，控制器還是做了很多其他的事情的。當把這個測量出來之後，控制器再調用API配置stage的queue的令牌數。這種配置每隔一段時間更新一次。
除了用令牌環控制流速，還需要使用priority特性來配置每個隊列，對於特殊的隊列給特殊的優先級。然後還通過queue size 這個參數來配置隊列的長度，這樣可以使得請求擁塞，給後端造成壓力。
那麼stage又是怎麼控制路由的呢？就像note中顧慮的那樣，由於stage是那種層層依賴的關係，queue當然會有一個默認的下一跳。但是也可以控制去讓它走不同的路線。比如說讓從不被信任的vm出來的io流進入malware scanning stage。
舉個例子，比如對於一個tenant租戶，他所有的虛擬機跨越10個hypervisor，這幾個虛擬機共同訪問某個存儲服務器，這個時候控制器可以通過在每個hypervisor處節流來達到更大的並行性，而不是在存儲服務器端節流（這樣可能會引起競爭）。
需要特殊考慮的情況？比如說在SMBc stage將大io請求(可能不好確定io性能，影響token的準確性)分解爲小io請求。
Controller概述
軟件定義存儲的控制器要控制的內容是和存儲相關的，存儲在乎的是帶寬保證，而是否能夠到達目的地這個並不難，因爲存儲網絡看起來比較簡單，不像是網絡的路由是那麼複雜的拓撲結構，往往將導致非常複雜的路由算法。
在軟件定義的存儲領域，Controller有兩個主要的作用,一是和上面的Control 應用程序交互,另外一方面是和數據平面交互,控制數據平面。在這裏控制器的作用主要是表現在發現數據中心的stages，然後和他們進行交互，並且維護一張全局的stage graph拓撲結構。然後他將這個拓撲和每個stage的信息告知上層的控制應用程序。這些Control應用程序，是和sdn領域裏面的控制邏輯比如hub或者l2 switching在一個層面上。
Control application
在這篇論文裏面，主要提到了兩種類型的應用程序。一個是性能控制的應用程序，另外一個是Malware Scanning middlebox。Malware Scanning middlebox是基於這樣的一個前提，認爲有些Flow是trusted，而另外有些是untrusted。所以對於untrusted的flow，就讓他們進入這個malware scanning middlebox進行檢測，如果檢測發現他們是可以被信任的，再讓他們路由到其他的stages(否則可能被丟棄)。Controller使用API configureQueueRouting（使得進入malware scanning middlebox）來處理untrusted虛擬機發出的流。對於一般的情形，關心的更多的是性能，也就要用到性能控制的應用程序了。
性能控制主要是包括minBandwidth或者exactBandwidth。性能控制的應用程序應該可以看到他需要的一張子圖。控制器要做的就是給子圖中的任何一個個隊列配置某個合適的帶寬。
比如說對於上面的左邊的圖，這種複雜的情形，首先要保證這個帶寬是可以保證的，然後可能要用到右邊的算法來保證帶寬（文章中有具體的說明），配置隊列的屬性。
比起在軟件定義網絡裏面的那些個情形，比如hub,那個邏輯基本是算比較簡單的了，第二層的學習也還算是比較複雜，若是FCOE的轉發邏輯（曾經分析過）那是相當的複雜，這麼比較一番，SDS的控制程序邏輯算是很容易。Control application似乎沒有那麼寬廣的使用空間（比如hub, l2 switching，或者fcoe路由），它只是數據中心的一個tenant的控制程序。
note： 通過上面的Control application，估計對控制器的理解也更加深入了，但是軟件定義網絡的控制器有很多種實現版本，比如NOX，POX，以及FLOODLIGHT。但是這裏微軟的IOFlow不開源，估計也就只有微軟版的控制器啦。然後這個控制器提供一套API和控制應用程序交互。
p.s.犯懶了，關於功能評價和可擴展性和性能的評價不寫了，總的一句話就是功能很好，效果很顯著，但是可擴展性問題值得擔憂。感興趣的還是自己分析原論文吧~~
參考文獻
[1]Eno Thereska, Hitesh Ballani, Greg O'Shea, Thomas Karagiannis, Ant Rowstron, Tom Talpey, Richard Black, and Timothy Zhu，IOFlow: A SoftwareDefined Storage Architecture，SOSP'13，November 2013