網路儲存“相對論”：NVMe over Fabrics效能實戰
本週二（12月5日），在北京朝陽悠唐皇冠假日酒店召開的2017中國儲存峰會上，張廣彬和曾智強代表企事錄技術服務公司發表了題為《網路儲存“相對論》的演講，分享了最近測試高效能儲存和網路的一些實踐。以下為演講實錄。
連續好幾年在儲存峰會的技術論壇上開場，以前講的都比較概念趨勢性一些。今天主要講的不是概念，而是我們最近在一些新技術上的探索和實踐。這一場將會由我和我的同事曾智強共同來完成，我先講前面的這一部分。
我們企事錄服務公司，主要致力於新技術、新產品的市場教育，手段通常是分析和測試。分析方面我和曾智強在幾年前寫過技術分析報告《資料中心2013》，率先提出“硬體重構+軟體定義”的理念，並據此展開對前沿技術的解析，這幾年行業確實在向著這個方向前進，我們也在這個方向上去踐行理念，特別是指導我們的測試工作。這裡列出了企事錄與幾家業內知名企業合作的聯合實驗室，本次的NVMeoF測試就主要在和青雲合作的混合雲實驗室進行。
這個“相對論”當然只是取一下（愛因斯坦）相對論字面上的意思，網路和儲存一定程度上是相對的概念，是可以互相替代的。十多年前聽華中科技大學謝長生教授打過一個比喻——資訊的傳輸，可以在空間維度，和時間維度上進行：比如烽火臺，把敵人入侵的訊號通過烽火臺傳遞到很遠的地方，這是在空間維度上的傳輸；另外一種在時間維度上的傳輸，比如刻一個碑，幾百年甚至幾千年以後，這個碑沒有損壞，大家還是可以看到記錄下來的資訊。前者就是網路，後者就是儲存，我覺得這個很有啟發。
兩者結合起來，就是網路儲存？當然，我們也可以更抽象的想一想，譬如1968年上映的科幻電影《2001太空漫遊》，裡面有一個宇宙高智慧結晶的代表，就是黑石，有好事者演算過這個黑石可以儲存多少資料，而它還能夠自由移動，穿越時空，兼具網路和儲存的特性。
十多年前的網路儲存，跟現在不一樣，專有的儲存硬體架構，專有的儲存網路（Fibre Channel）。但從使用的角度，通過網路去訪問，其實跟訪問本地的硬碟，看起來沒什麼區別。現在我們講軟體定義儲存（SDS）和超融合（HCI），軟體定義儲存的主流是分散式的，在通用伺服器上，分佈到多個節點來執行，用伺服器叢集來提供服務。儲存和計算分離的場景，兩個叢集之間的網路顯然是可見的，使用和部署的時候可以明顯感受到。而超融合，把計算和儲存放到了一起，計算看起來訪問的是本地儲存資源，但實際上也可能是通過網路跨節點訪問，它的網路不是很明顯，但實際上各個節點之間，也是通過網路才成為一個整體。
超融合是這幾年企業級市場上很火的一個概念，我在去年的儲存峰會上也講過
超融合部署的另外一個優勢是，利用計算和儲存一體的特點，可以把計算節點經常訪問的資料，就近放在所在的節點本地，儘量避免跨網路訪問。這在網路狀況不太好的時候，有很好的效果。如圖所示，超融合市場的開創者Nutanix就提供這個功能。
公有云上也有類似的例子，譬如阿里雲的第一代塊儲存是2010年做的，當時阿里雲尚處於起步階段，用的網路還是千兆乙太網，就利用超融合的部署方式，來降低網路效能的不利影響。
我們後面也會提到，現在高速的儲存，譬如NVMe和3D XPoint這種低延遲儲存的出現，儲存效能大幅提升以後，網路效能如果跟不上來的話，可以用類似的資料本地化的方法，譬如微軟的S2D（Storage Spaces Direct），或者VMware vSAN，都有計劃加入資料本地化的功能。
剛才說到阿里雲，實際上超融合架構在大型雲端計算環境下的一個問題，就是計算和儲存資源緊耦合的方式不夠靈活。譬如阿里雲上線了一個叢集，可能計算資源很快賣空了，但儲存資源還剩很多，那這就是很不經濟的一種做法。所以阿里雲從第二代塊儲存技術開始，就採用了計算和儲存分離的方式，包括到現在的第三代也是採用分離部署的方式。
另一個例子是AWS的EBS。EBS主要為EC2計算例項服務，AWS有很多型別的EC2例項，C開頭的是計算優化的例項，前不久推出了最新一代的C5例項。AWS起步比較早，其虛擬化採用的是Xen，但是最新的一代C5轉向了KVM。上週的re:Invent 2017大會上，AWS為了介紹C5，把以前幾代例項的計算和儲存架構都大致回顧了一下。
這張是C3例項的架構圖，左邊是硬體架構，右邊是軟體架構，畫出了對應的對映關係。很多IaaS公有云的例項都有本地儲存的選項，本地儲存的問題在於，其就在例項（通常是VM）所在的物理主機上，如果雲主機重啟或遷移，本地儲存的資料就會丟失。所以本地儲存雖然快，但並不被視為持久化儲存。持久化的塊儲存，於AWS就是EBS（Elastic Block Storage，彈性塊儲存），黃色的虛線框裡就是EBS，是一個共享的儲存，通過網路訪問。從圖上的架構可以看到，儲存和網路一樣，通過網路來訪問。這就可以看到C3例項在儲存架構上的問題：儲存的流量和網路的流量，沒有有效的區隔，所以儲存的效能可能無法保證。
從2013年底到2015年初，過了一年多，AWS升級到了C4例項。黃色虛線框裡還是EBS，注意儲存的訪問路徑，已經和網路區隔開了，所以C4例項的EBS儲存，效能和QoS有保證。這也說明了網路和儲存的一些聯絡：有時候儲存的變化，實際上是網路的變化。
這是我畫的一個圖，橫軸是時間線，縱軸是SSD或HDD（硬碟）的大致數量。可以看到這是一個發展的曲線，左下角的是已經發生的事情。我們原來為什麼會有磁碟陣列？因為硬碟效能太差了，所以要把很多硬碟堆在一起，形成磁碟陣列提供更高的效能（有時是更大的容量）。隨著SSD的逐漸發展，剛開始用SSD給硬碟當快取，使用伺服器內建儲存，SSD加HDD組成快取或分層的方案，還可以是純SSD（全快閃記憶體），就可以滿足應用的需求。
由於SSD的加入提高了儲存的效能，伺服器本地的儲存就能滿足所承載應用的儲存效能需求，所以我們可以做成超融合的方案。這個黃色的圓圈的意思是，前幾年到未來幾年的這個時間區域內，伺服器內建儲存可以用超融合的方案，一個伺服器有10幾20幾個硬碟或SSD（SSD+HDD或者全閃）。
但是，隨著NVMe SSD逐漸普及，以及伺服器本身能支援的SSD數量進一步增加，可能又會往另外一個方向變化：一臺伺服器裝滿了SSD以後，本地的計算能力（執行的應用負載）已經不能完全發揮SSD的全部效能，所以又要把SSD放到單獨裝置裡面，把儲存獨立出來，供很多主機訪問，還有更高的靈活性。所以往右上角發展，比如說幾百片快閃記憶體放在一起，甚至將來有可能會上千個快閃記憶體放在一起。就像這張NVMe over Fabrics（NVMeoF）規劃的遠景，將來可以支援千個級別的SSD。NVMe over Fabrics現在已經走向了一些原型階段，或者是有一些產品出來了。
NVMe over Fabrics要解決的是，計算和儲存分離了以後，距離沒有產生美，帶來的卻是頻寬和延遲上的挑戰。怎麼解決這個挑戰，接下來的這一部分，有請我們企事錄負責測試的合夥人曾智強來講一講這方面的情況。
大家好，我是曾智強，我在企事錄主要負責（新）技術、產品及解決方案的評估和驗證。快閃記憶體的出現，確實加大了對儲存網路的挑戰。業內已經開始著手解決網路的問題，比如NVMe over Fabrics，我們也對NVMeoF做了一些探索和嘗試，取得一些成果，今天就給大家分享一下企事錄在NVMe over Fabrics方面獲得的一些實踐經驗。
說到NVMe over Fabrics，這是NVMe over Fabrics的一個總體架構示意圖。NVMe實際上一個暫存器級的邏輯介面，專為SSD等非易失性儲存開發，資料傳輸通常在PCIe之上。所以在NVMe over Fabrics 1.0規範裡面，把NVMe SSD比作是NVMe over PCIe，既然是over在PCIe上面，那是不是也可以over在其他的網路上？比如說企業資料中心最常用的Fibre Channel（FC），或者更常見的乙太網，乃至其他更高速的網路上？比如InfiniBand（IB）。InfiniBand和新一代乙太網有一個非常好的功能即RDMA（Remote Direct Memory Access，遠端直接記憶體訪問），可以有效降低軟體層導致的延遲。InfiniBand的頻寬一向很高（40Gbps以上），現在乙太網的頻寬也很高，比如新一代的25GbE，以及100GbE，而且也支援RDMA功能，比如RoCE（RDMA over Converged Ethernet）或iWARP（internet Wide Area RDMA Protocol）。這不僅能顯著降低延遲，也有助於提升頻寬。
中間紅色部分，就是支援RDMA的軟體堆疊，包括InfiniBand和乙太網，最右邊粉色部分，實際上就是Fibre Channel。NVMe over PCIe或者NVMe SSD上的訪問規則是由NVMe規範來定義的。
NVMeoF實際是基於NVMe 1.2規範，對協議層進行了擴充套件。這張圖就是NVMeoF的架構，可以看到，其實是在NVMe協議中的NVMe Transport進行了擴充套件，用以支援InfiniBand和乙太網，以及Fibre Channel等等。
從規範來看，NVMe over Fabrics實際上有兩種模式，第一個是Memory模式，所有的NVMe SSD就是使用這種模式；另外就是Message模式，通過對NVMe命令進行再次封裝，以此實現在其他網路上傳輸，如果在Fibre Channel上傳輸的話就使用message模式。此外，比較例外的就是RDMA上，支援RDMA功能實際上有InfiniBand和乙太網，而乙太網又有RoCE和iWARP兩種。NVMe over Fabrics都是支援的，並且memory模式和message都能用在RDMA上。
從邏輯架構上看的話，NVMe over PCIe和NVMe over RDMA上，在軟體開銷上的增加很小，可以近似的認為跨網路訪問和本地訪問的延遲幾乎是一樣的。所以如果用RDMA的話，雖然經過了網路，但其延遲可以非常接近於本地的水平。為了驗證NVMe over Fabrics，我們在企事錄和青雲聯合的混合雲實驗室裡設計了一個測試方案。
圖上就是測試部署的架構，圍繞資料庫應用構建的一個典型應用場景。之所以選擇資料庫應用，是因為資料庫對延遲的要求比較高，而Oracle資料庫也可以被認為是最關鍵的企業應用之一。最上面的是Oracle資料庫伺服器，配備的Intel雙路Xeon Platinum 8180處理器，是Intel新一代（SkyLake）處理器中最頂配的型號，配置了256GB記憶體。這臺伺服器上一共插了3張網絡卡，其中一張是Mellanox的CX5網絡卡，這是一張100Gb/s的網絡卡；另外兩張則是Mellanox的CX3網絡卡，是10Gb/s的。這三張網絡卡都支援RDMA功能，也就是RoCE。
Oracle資料庫伺服器通過兩臺交換機與最下面的儲存伺服器相連。右邊這臺就是100Gb/s交換機，是Mellanox提供的SN2100；左邊是Mellanox SX1024交換機，是10Gb/s交換機。最下面的是儲存伺服器，採用Intel雙路Xeon Gold 6154處理器，這是一款高主頻的處理器，適合驅動高效能的NVMe SSD，作為儲存伺服器，也配置了256GB記憶體。與Oracle資料庫伺服器一樣，也有一張100Gb/s和兩張10Gb/s的Mellanox網絡卡。在儲存方面，使用了4個U.2介面的Intel DC P4500SSD，每片SSD的容量是2TB。同時還使用了1片750GB的Intel DC P4800X，這就是傳說中的Optane，採用3D XPoint技術，一種全新介質的SSD。
這裡要特別感謝一下海天起點公司提供的技術支援。海天起點是一家專注於提供資料庫服務的公司，在Oracle資料庫的運維、優化和排錯方面有著非常豐富的經驗。之前講過，我們這個測試是以Oracle資料庫應用來構建的，之所以與海天起點合作，也是需要藉助他們的經驗來驗證Oracle資料庫在NVMeoF下的效能表現。同時，他們也非常關注NVMeoF，也希望跟我們一起探索，所以我們一拍即合，做了這個測試。
下面我們來看一下測試方面的情況。這張圖展示了在不同介面的大致頻寬，比如SATA、10GbE、25GbE、NVMe以及100GbE，我們看到，其頻寬基本是以倍數增長的。其中有一項是主流NVMe SSD的頻寬，採用PCIe x4通道，實際能達到的頻寬大約在3.2GB/s左右。而100GbE的頻寬大約在10GB/s左右，差不多是3片NVMe SSD相加的頻寬，所以在這個測試裡面，我們使用了4片NVMe SSD，以確保儲存總頻寬超過網路，如下表。
這個表是Intel DC P4500 SSD的效能引數，單片SSD大約能提供51.5萬IOPS，這是一個穩定狀態下的值。而我們拿到的是全新的SSD，所以在測試的時候，有一定的誤差，單片SSD的隨機讀效能大約是54萬IOPS，兩片P4500的效能大約在100萬左右，4片則在185萬左右。單片P4500的頻寬在3.2GB/s，隨著SSD數量的增加，其頻寬基本是線性增長的。
下面我們來看一下在實際測試中的情況。在10GbE iSCSI情況下，其隨機讀寫的效能大約是6萬IOPS和5萬IOPS。需要注意的是，我們這兒採用的測試是Oracle資料庫典型的8KB資料塊。然後開啟RDMA，也就是使用NVMeoF之後，10GbE的隨機讀寫效能幾乎能夠翻倍，超過了13.5萬IOPS。從圖上可以看到，隨機寫與隨機讀的效能差不多，與我們的常識相悖——基於NAND Flash的SSD，寫效能是要弱於讀效能的。這是因為10GbE的頻寬已經是瓶頸了，連1片P4500的效能極限都達不到，所以讀寫效能相差無幾。
最後則是100GbE NVMeoF下的效能，隨機讀寫效能為120萬和60萬IOPS，分別是10GbE iSCSI下的20倍和12倍。可見100GbE的優勢非常明顯，能夠有效地提升NVMe SSD的效能表現。
接下來是在頻寬方面的效能表現，我們使用的是64KB資料塊進行順序讀寫。在10GbE iSCSI情況下，其頻寬約為1.2GB/s，在NVMeoF下，其頻寬差不多，都在1.2GB/s左右，10GbE的頻寬已經成為瓶頸。而在100GbE的NVMeoF下，其順序讀頻寬提升了將近10倍，達到了11GB/s；寫頻寬也提升了5倍，接近6GB/s，差不多已經接近4片P4500 SSD的極限效能。
100GbE能夠有效的發揮NVMe SSD的IOPS和頻寬，那麼在延遲方面呢？下面我們進行了另外一個測試。先看一眼各種儲存介質的延遲表現：DRAM最小，在納秒（ns）級別；然後是SCM（儲存級記憶體），延遲增加了一個數量級；接著是SSD，延遲在微秒（μs）級別，相比DRAM又增加了三個數量級；最後是HDD，延遲在毫秒（ms）級別，相比SSD，延遲又增加了3個數量級。這些儲存介質的延遲差距都是指數級的。
在延遲方面的測試，我們使用了Intel DC P4800X SSD。這種採用3D XPoint技術、俗稱Optane的SSD，最引人注目的就是延遲極低，Intel官方公佈的延遲指標在10微秒左右，我們在NVMeoF測得其讀寫延遲分別為34微秒和35微秒，相比官方資料，有一定的增加，但還是在同一個數量級，NVMeoF的延遲表現確實非常優秀。
然後是P4500的延遲，這個是在本地測的，讀寫延遲分別為101微秒和31微秒。這也可以看出RDMA的延遲非常低，即使是跨網路了，其延遲仍與本地SSD的延遲相差不多。可能有人注意到了，不是說SSD的寫效能不如讀效能嗎？為什麼你這上面P4500的寫延遲比讀延遲還低不少，甚至也低於P4800X呢?
這裡需要說明，Intel DC P4500 SSD有獨立供快閃記憶體控制器使用的DRAM，作為寫快取，以加速SSD的寫操作，所以寫延遲比讀延遲還要低。為了保證DRAM裡面的資料在突發掉電情況下也能寫入到NAND快閃記憶體裡，所以P4500裡面還有兩顆電容，來防止資料丟失。而Optane的寫入特性很高，資料直接“落盤”的效能不遜於讀取時，自然也就不需要DRAM及電容保護。
這張圖則是在企事錄測試架構下P4500的延遲表現，可以看到，由於加了32佇列深度，在10GbE iSCSI模式下，延遲就比較高了，讀寫延遲分別為9毫秒和10毫秒。但在使用NVMeoF之後，即使是10GbE，其延遲也一下降到了3.7毫秒。仍然受限於10GbE的頻寬瓶頸，所以其讀寫延遲相差無幾。而在100GbE的NVMeoF情況下，延遲又降回到了微秒級別，比10GbE iSCSI模式低了一個數量級。
由於時間關係，企事錄實驗室的這個測試其實還沒有做完，因為我們最終的目標是要評估NVMeoF在Oracle資料庫應用場景下的效能表現，但我們的測試正在進行中，還沒有獲得進一步的結果，所以我們今天的分享就到此為止。但是，即使是這樣，我們也看到NVMeoF的潛力巨大，確實能夠較為充分的利用NVMe SSD的高效能，讓跨網路的儲存訪問獲得與訪問本地儲存相近的效能。我們相信隨著NVMeoF技術不斷髮展成熟，這肯定是未來的方向。我們將繼續測試NVMeoF，後續的測試結果將陸續公佈在我們的公眾號上面，下面就是我們的公眾號二維碼，對NVMeoF或者其他資料中心技術有興趣的同學可以掃這個二維碼關注我們的公眾號。謝謝！