可軟體定義程式的儲存邏輯——Efficientandagilestoragemanagementinsoftwaredefinedenvironments

可軟體定義程式的儲存邏輯——Efficientandagilestoragemanagementinsoftwaredefinedenvironments

note：寫這個也許算是翻譯，又或算是對這個論文[1]的理解，又或者只是我的看法。

這篇論文和IOFlow相比較，更加地注重軟體定義程式儲存的架構（我覺得是利用已有的架構來建立新的架構，然後使用已有的協議），而不是像IOFlow那樣注重通訊的協議。並且，這個架構還是軟體定義程式環境的架構，而不僅僅是儲存的架構，不過全文注重說了儲存（更有挑戰性）。特別地，關於可軟體定義程式的儲存邏輯，從這裡可以管中窺豹。

SDE軟體定義程式環境資料中心的環境包括Compute、Network和Storage資源。

資料中心對（flex）靈活性和rapid的需求越來越大，而資料中心應用程式效能和計算、網路和儲存這些資源息息相關。一個整體的對資料中心的smart的組織和安排方案（global view）肯定能打破計算，網路和儲存的限制，明顯的增加QoS和使用者體驗。

Objective of SDS

SDS的目標和軟體定義程式網路的目標是一樣的，SDN的目標可以分為兩個維度，從橫向上來說，是全域的最佳化能力；從縱向上來說，是控制平面和資料平面的軟體整合。

從高層應用程式的角度來看(和低層的LUN和RAID比較)，應用程式的部署要求storage provision和一定的效能(從整個系統的角度看)，系統將所需的邏輯卷分配給應用程式。然而，應用程式的生命週期是動態變化的，需要的資源不停地在動態變化著(儲存需求，效能需求，資料保護要求，拷貝政策，復原點目標和復原點時間的改變)等，所以上面提到的這些變化如果可以顯示的去配置，那麼對於應用程式來說，就太有效了。

總之，SDS的總目標就是使得需求和下層的infrastucture解耦。

這篇文章最主要的貢獻是一個叫做IBM OPen Platform的SDS解決方案，基於OpenStack（使用了它的擴充介面）。
已有的儲存方案企業級的解決方案

儲存企業界提出了一個叫做SMI-S（儲存管理首創說明）的草案來作為管理不同存放裝置的統一介面。但是這個和SDS是有區別的，也不能達到在前面提出的SDS的目標。為了減小它和SDS的區別，達到更好的使用者級需求和體驗，IBM的儲存管理方案VSC做了很多事情，其他的企業級儲存還包括RMC，NetAPP等等。

開源社區的解決方案

Openstack是一個來源的雲管理系統，這個開源項目現在由許許多多的vendor在參與，已經取得了很大的成就。Openstack中提供了SDS的平台，他的儲存部分主要是包括了swift(給應用程式和虛擬機器提供了Object Storage Service)和Cinder(給虛擬機器提供了Block Storage)。

Swift

Swift管理和提供Object Storage Service，提供相應的API給client。swift的一個很重要的能力就是在可用的磁碟和nodes中間自動的複製資料，自動的來提供可擴充性，有效性和資料保護的能力(這些都是隱藏的功能，swift有一套嘛)。然後swift的目標是更小的儲存開銷，因為叢集中的機器都是有大型存放區的商品機。現在的新的應用程式中很流行使用Object Storage Service，尤其是web程式(因為swift的 REST API 在http上面很盛行)。比起檔案儲存體和Block Storage來說，Object Storage Service更加有擴充性，也更加靈活。

cinder

它是一個塊管理組件，提供了Block Storage管理的功能，比如給伺服器建立，增加塊裝置，或者刪除某個伺服器的塊裝置。(這些伺服器不再使用簡單的linux伺服器的儲存，而是使用統一的儲存支援，(向上甚至支援ceph和netapp))。現在cinder可以管理很多的儲存系統，比如GBFS(IBM的分布式並行檔案系統，屬於底層的一個檔案系統)和lvm(卷管理器)。cinder包括一個scheduler(plugged，所以可以採用第三方的)來為伺服器選擇最佳的塊裝置(根據需求，可能包括volume type(也是儲存資源的一種抽象吧))。更多學習cinder，點擊這裡。

openstack的這些儲存機制是在一定程度上支援軟體定義程式的概念的，但是對那些具體的支援還不夠，如果說是SDS應該還算不上。

架構架構

這篇文章提出了一個叫做IBM Open Platform的平台（如所示），主要包括了對工作負載的抽象，對資源的抽象，以及負載到資源的映射，以及相關的最佳化。要讓這個架構發揮作用，對workload和對資源的抽象都很重要。對workload的抽象就是把各種各樣不同的workload通過一種抽象方式（比如說JSON或者XML）表述，然後抓取出其中的與應用相關的需求，比如說基礎架構和操作流。

而資源的抽象就是提供一個統一的介面來提供、管理和監控下層的計算、儲存和網路資源。所以複雜的裝置對於使用者來說就是透明的了，而那個核心的SDE統一控制平面就翻譯workload的抽象表示，也翻譯來自下層資源的抽象表示，然後組織sdc、sdn和sds的組件（為了靈活而有效管理）。

工作負載的抽象

比如說，一個簡單的三層的web程式一般包括一個web伺服器，包括一個資料庫，還要一個應用伺服器。這種軟體模式可以被一個描述性的語言格式來描述，比如JSON。然後中間的unifiedcontrol plane的engine解析這種語言，之後為這個workload組織安排底層的資源。

從儲存的角度來說，這個架構可以創造靈活的儲存語義。比如說，應用程式可以指定儲存卷的大小，儲存服務類型和相關的其他的政策等。因此，這個架構使得程式開發人員和系統管理者顯式的指定他們對底層儲存的需求。這種使用者級的儲存需求也可以在使用者程式的生命週期中發生改變，帶來了更大的靈活性。

資源的抽象

那麼資源的抽象是怎麼做的呢？

IBM的開放平台支援的底層平台不僅僅是企業級的儲存子系統，也包括商業存放裝置，比如GBFS。資源抽象就是將儲存資源(不管是SAN，還是NAS或者是DAS)抽象為一個資源集區，然後再根據workload的需求去管理和分配。

比如說這個架構可以在GBFS中利用底層的存放裝置建立一個檔案，然後把這個檔案作為一個塊裝置分配給虛擬機器去使用，也可以使用GBFS的快照和檔案遷移的功能去管理虛擬塊裝置。關於底層的特殊的裝置，有的裝置可能是企業級的，會提供一些進階的功能，比如韌體級的壓縮和去重能力。這個時候，就可以使用這些功能。但是如果底層的存放裝置沒有這些功能，就需要調用軟體的方法來達到這個目的。

總之這個架構提供了一個儲存資源的抽象，能夠達到很好的儲存資源使用率，並且提高操作效能，減少了儲存系統的複雜度。

資源的映射

從上面的描述我們看到，這個架構中 unified control plane的功能就是利用上面的請求，組織安排下面的資源。對於儲存請求，那就是解析儲存請求的要求並傳給sds模組來達到資源地圖的目的。從下面的例子可以很好的瞭解有關儲存資源的映射過程。

performance-aware儲存配置

形象一點來說，對於每個儲存資源建立請求，都需要一個“服務類型”的標籤，代表著特殊的對（storage provisioning）的需求，比如說RAID的層級或者是錯誤恢複特性（resiliency profile）。每個服務類型代表一組儲存的配置。比如說對於“白金”層級的服務類型，那可能就是要求低延遲，這樣的workload建立的儲存卷更有可能放在ssd中，而不是普通的磁碟。另外，如果可用的ssd有很多，組成一個資源集區，這個架構還會分析ssd資源集區中裝置的利用率情況，然後將新建立的儲存卷放在其中一個SSD（會產生最小的效能影響的）。

儲存fabric管理

當儲存單元建立好了之後，也就是建立好了workload伺服器和儲存卷之間的聯絡。然後對於下面的儲存網路技術，比如fc，iscsi，infiniband和fcoe都提供了統一的介面。然後這個架構提供一個最好的zone管理和fabric 分析來確定伺服器和儲存卷之間的最好的storage fabric。（比如說，通過分析存放裝置的利用率，然後在多個連接埠之間進行Server Load Balancer）（也可以使用爬山演算法來找到最好的路徑）

儲存恢複

還原能力是資料保護的一個重要的特性。在這平台上，有兩種形式的resiliency。一種是fabric resiliency，應用程式可以選擇一條IO路徑，保證路徑上的每一個節點都是好的（不會failue，就像fcoe儲存節點上面的需求那樣）；對於存放裝置級的資料保護措施，這個架構可以讓應用程式選擇一種複製策略，比如point-in-time快照，同步的鏡像或者非同步鏡像。儲存恢複還可以利用sde的整體功能，包括計算，來實現更加整體的資料還原功能。

連續模式最佳化ILM

這裡有一個很重要的概念，叫做儲存資訊生命週期管理（ILM）。這是因為資料的價值在它的生命週期中是動態變化的，比如郵件資料在剛開始的時候價值是最高的，後來隨著時間這個郵件越來越沒有價值了。所以ILM的目標就是在正確的時間把正確的資料放在正確的storage tier上面。這也就是Storage tiering技術（根據曆史io行為，來決定io tier）。而我們的這個架構使得可以應用程式根據獨特的需求來控制儲存的tier。比如說給一個服務類型指定是（higher tier和lower tier的類型，然後自動的在某些io閾值的時候執行某些tier policy。

note：就比如說應用程式編程的時候就可以指定在將來某個時候把資料存放在哪塊盤上面~~~

SDE的整合

資料中心對（flex）靈活性和rapid的需求越來越大，而資料中心應用程式效能和計算、網路和儲存這些資源息息相關。一個整體的對資料中心的smart的組織和安排方案（global view）肯定能打破計算，網路和儲存的限制，明顯的增加QoS和使用者體驗。

這個sde架構中的儲存部分和其他的組件比如sdc和sdn都合作良好，並且整個架構有著豐富的api，還可以在這個架構上做各種各樣的最佳化。比如說VM的安放問題。

storage-aware VM placementVM的放置關係到cpu，記憶體和vdisk。對於一個io密集型的vm來說，它的vdisk放在SAN中的某個位置是相當重要的（延遲和頻寬），對於一個計算密集型的VM來說，cpu和記憶體的分配就更加重要。所以vm的放置往往也需要考慮到cpu，儲存和vdisk的問題。這個架構的邏輯能提供一個靈活的vm儲存放置方案。LAB

IBM的研究人員建立了一個小型的實驗環境，這個架構得到了很好的應用，效果也很好。

參考文獻

[1]Alba, A., et al. "Efficient and agile storage management insoftware defined environments." IBM Journal of Research and Development 58.2 (2014): 1-12.