Server如何SAN(中)：SSD和網絡 　　本文是“FusionCube超融合大講堂”的第三篇（中部），具體探討SSD和網絡對Server SAN的重要意義。繼續以足球和籃球作比，解析作為超融合架構核心的軟件定義存儲…… 　　上部回顧：Server SAN之規模與架構 　　本文將通過分析足球和籃球在團隊精神上的不同側重，從兩大（規模、架構）四小（SSD、網絡、副本、管理）共六個方面，來對比作為超融合架構根基的軟件定義存儲（具體到Server SAN），和融合架構常用的SAN存儲設備。 　　單挑打不死：閃存改寫游戲規則 　　歐洲杯小組賽剛結束，C羅“一生之敵”梅西率領的阿根廷連續第二年在美洲杯決賽中被公認牌面較弱的智利冰封。對梅西的質疑撲面而來：為什么前輩球王馬拉多納就可以帶阿根廷隊奪得世界杯冠軍，而梅西只收獲“三亞”呢？ 　　1986年的墨西哥高原，馬拉多納在進四強和決賽的路上包攬阿根廷隊全部進球，且各有一個突破數人圍堵射入的佳作，決賽在遭遇德國隊嚴密看管的情況下仍送出致命一傳。自那以后整整30年，重大足球賽事上再也見不到如此有統治力的個人表演，雖然梅西和C羅整個職業生涯的個人數據要亮眼得多。 　　不完全是巧合，從上世紀90年代后期開始，為了保護進攻隊員，FIFA和NBA都出臺了一系列有利于帶球突破的規則，結果卻大不相同。在NBA，每到季后賽的關鍵時刻，超級巨星的持球單打，一再成為扭轉戰局的關鍵。 　　然而，在世界杯和歐洲杯這樣的頂級足球賽事，個人帶球長途奔襲“一擊致命”的場面卻愈發少見。1990年世界杯決賽又在德國和阿根廷之間展開，馬拉多納已過巔峰，四年前負責防守他的馬特烏斯率隊成功復仇。 　　在本屆歐洲杯淘汰賽期間，馬特烏斯表示：現在的足球，跑動比他那時代每場多3000米，他那時代比貝肯鮑爾（70年代）每場多跑3000米。時代不同了，現代足球，組織更嚴密，飲食更規范。 　　連續三屆大賽，強隊的每場人均跑動距離都達到10公里以上，也就是說，現在的人均跑動距離，比20年前高近一半，是40年前的兩倍多。能奔善跑的隊員遍布全場，個人帶球過關斬將自然難上加難。沒有一個成熟的傳球組織體系是不行的。 　　本賽季的中超倒是還能看到類似的戲碼：首輪對決，連續作戰的衛冕冠軍恒大隊疲憊不堪，被力帆外援兩度長途帶球奔襲得分。 　　有趣的是，有媒體評論，中超的比賽風格，落后歐洲30年…… 　　球員跑動能力提升一倍，都會對比賽風格產生如此之大的影響。那么，存儲介質從硬盤換成閃存呢？ 　　左邊三種不同類型的SSD，對右邊三種不同轉速的硬盤。硬盤的隨機I/O性能已經過適當美化，依然慘不忍睹…… 　　上表列出的對比數據，可以再次說明幾個常識性問題： 　　在順序讀寫性能方面，硬盤與（基于閃存的）SSD相差并不是很大，特別是后者受寫入性能和接口帶寬限制，“只”快一倍到十幾倍，目前還很少超過20倍； 　　SSD（Solid State Drive，固態盤）的優勢主要體現在隨機訪問，IOPS（I/O per second，每秒I/O操作數）性能可達硬盤的上千倍，延遲也只有后者的百分之一左右。 　　由于硬盤的隨機訪問性能太差——吞吐量（throughput）不到自身順序傳輸帶寬的百分之一，傳統的中高端SAN存儲堆積大量的硬盤主要是為了獲得較高的IOPS。因此，級聯JBOD這種只增加硬盤數量而帶寬保持不變的典型Scale-up方式被廣泛采用。譬如，EMC最后一代采用單片式架構控制器的高端存儲產品Symmetrix DMX-4，一個4Gb/s FC-AL后端端口，最多可以連接60個硬盤——每個硬盤分到的帶寬不到70Mb/s，卻也算夠用了。 　　典型中端存儲系統的架構，（最上方）一對控制器拖著一組JBOD，可以是不同尺寸、轉速的硬盤 　　為了連接更多的硬盤，提供更大的存儲容量和更強的I/O能力，可以為存儲控制器增加后端端口數量。但是，一套控制器能增加的端口數是有限的，DMX-4最多可以提供64個后端端口，即32對（HA需求）磁盤通道，所以最多可連接1920個硬盤——如果通過產品認證請求（RPQ）批準，可以增加到2400個。 　　最新的VMAX3（VMAX 100K/200K/400K），雖然引擎（一對控制器組成）之間可以Scale-out，每個引擎仍能級聯6個磁盤擴展柜（DAE）。使用120個2.5英寸驅動器的DAE時，最多可達720個驅動器（硬盤或SSD），控制器的“負擔”依然很重。 　　同樣是隨機訪問，SSD的吞吐量超過100MB/s（1Gb/s）乃尋常事，繼續沿用一個控制器拖上百個（閃存或硬盤）驅動器的Scale-up模式，勢必造成性能上的巨大浪費。所以，圍繞閃存設計的產品，Scale-out是發展的主流，譬如EMC收購來的全閃存陣列產品XtremIO：每一對（HA）1U控制器和裝有25個SSD的2U盤柜組成一個名為X-Brick的基本單元，需要擴容時就增加X-Brick，性能隨之同步增長，最多可以擴展至8個X-Brick組成的集群（又是8個）。 　　XtremIO通過高帶寬、低延遲的40Gb/s QDR InfiniBand網絡橫向擴展 　　普通的服務器不用考慮雙控，也沒必要外接JBOD走Scale-up路線，內部直連的硬盤或SSD通常都能獨享接口帶寬： 　　SATA就是600MB/s，SAS現在能到1.2GB/s； 　　PCIe 3.0 x4（單向）4GB/s，x8可達8GB/s…… 　　于硬盤而言，SAS和SATA的帶寬在相當長一段時間內都不會成為瓶頸； 　　于SSD而言，PCIe 3.0 x4或x8的帶寬都有可能不夠。 　　重點是，在Scale-out模式下，存儲介質到其計算資源的通道更短且寬闊得多，就看如何使用，揚長避短了。 　　SSD不僅在性能上占據壓倒性優勢，容量上也早已超越硬盤，但大容量（如7200RPM）硬盤明顯更低的單位容量成本還是很有吸引力，而且順序讀寫的性能差距并不算大。所以，將SSD作為硬盤的Cache使用，起碼在現階段，仍是業界比較普遍采用的方案。 　　以FusionCube分布式存儲為例：在讀取數據時，SSD Cache解決硬盤最怕的熱點問題，即（根據系統算法）將一段時間內反復訪問的數據復制到SSD中，釋放硬盤的壓力，而太長時間沒有訪問的數據會被移出SSD。在寫入數據時，SSD起到緩存的作用，OSD收到VBS發送的寫I/O操作后，把數據寫入SSD就算完成本節點的寫操作。緩存在SSD中的寫I/O數據周期性的（或占據一定容量后）批量寫入到硬盤中，盡量減少對硬盤的隨機寫操作。 　　FusionCube分布式存儲的讀Cache（左）有兩層，第一層為內存，采用LRU（最近最久未使用）算法；第二層為SSD，采用熱點讀機制。寫緩存（右）則只使用非易失性的SSD 　　每個OSD管理自己的Cache/緩存，所以一份數據從寫入到緩存開始就會有二或三個副本，以防因單個硬件故障（SPOF）而導致數據丟失。此外，SSD用于讀Cache和寫緩存的容量配比是可以調整的。 　　與閃存正相反，硬盤不怕寫，怕隨機。所以，FusionCube分布式存儲支持大塊直通（pass-through），按缺省配置大于256KB的數據塊直接落盤而不經過SSD緩存，因為大數據塊寫入更接近順序訪問，硬盤并不比SSD慢太多，少了這么一個中間環節還有助于保護SSD。在順序讀寫比較多的場景（如OLAP），直接訪問硬盤比較有效。當然，這個直通的配置可以修改，取決于應用的類型和用戶的需求。 　　嚴格來說，作為不可缺少的基本功能，“分布式Cache”應該屬于“存儲引擎層” 　　FusionCube分布式存儲更直接的一點是，直接管理裸盤（raw disk）而不經過中間層（如單機文件系統），既可以直接提高每個I/O操作的性能，還可以區分不同程度的硬件故障，采取具備針對性的措施，減少對資源池整體性能的不利影響，譬如： 　　能夠識別出硬盤上的部分損壞（如壞扇區）。Read Repair（讀修復）機制在讀數據失敗時，系統會判斷錯誤類型，如果是磁盤扇區讀取錯誤，則自動從其他節點保存的副本讀取數據，然后重新寫入該副本數據到硬盤扇區錯誤的節點，從而保證數據副本總數不減少和副本間的數據一致性。雖然這個I/O操作會增加一點延遲，卻不至于將整個硬盤下線，做大量數據的重新分布（rebalance）——那會非常消耗存儲和網絡資源，影響業務的正常運行。 　　能夠識別出資源池中的“慢盤”。一個響應速度低于其他硬盤的硬盤會拖慢所有與其相關的I/O操作，這時要毫不猶豫的將其“踢出”資源池。 　　一句話：（硬盤）該保時保，該踢就踢，出發點都是保證系統整體性能不受影響。 　　Ceph也已經從Jewel版本開始，引入直接管理裸盤的BlueStore存儲引擎，以期替代原有的FileStore（看名字就知道）。初步的測試數據表明，基于硬盤的I/O性能可以提高一倍。當然，元數據管理等工作相應增加，需要社區和業界投入足夠的開發資源。 　　在全閃存配置下，SSD的高性能意味著需要分配更多的計算資源，來處理明顯增加的I/O請求。為了提高I/O性能，FusionCube分布式存儲允許在一個節點上部署多個VBS，或者為一個存儲設備部署多個OSD。在PCIe SSD作為主存時，可以在1個PCIe SSD上部署多個OSD進程，譬如2.4TB的PCIe SSD可以部署6個OSD進程，每個OSD進程負責管理400GB。 　　部分原因是，SSD如果不受接口帶寬限制（或受限制較少，如PCIe），有可能容量越大性能越高（與芯片數相關），而硬盤的機制卻不是這樣的。 　　在Ceph的實踐中，可以看到類似的做法，如為每個SSD分配2個OSD（Object Storage Daemon，對象存儲守護進程），以更充分的發揮SSD的性能優勢。 　　更多的OSD進程，意味著需要消耗更多的CPU和內存等計算資源。以FusionCube 9000的典型配置為例：6個PCIe SSD的全閃存節點，內存容量是12個SAS硬盤加1個SSD（Cache）的硬盤存儲節點的2.5倍（160GB：64GB），CPU內核數也差不多高一倍（E5-2660 v3：E5-2620 v3）。 　　不論是作為Cache/緩存還是全閃存，閃存的加入都是軟件定義存儲（包括Server SAN）能夠進入傳統企業應用的關鍵。受限于硬盤孱弱的隨機訪問能力，早期的軟件定義存儲實踐如GFS和HDFS，服務的都是Hadoop這類離線應用——畢竟，純比堆硬盤，還是傳統SAN存儲設備更有效。 　　帶球與傳球：網絡助攻Server SAN 　　過去兩年，倡導分享球的勇士隊打法賞心悅目，被認為是NBA的一股清流。對勇士隊的追捧隨著其在2015年6月奪冠，并在接下來的常規賽創下73勝記錄而達到頂峰。 　　但是，在隨后到來的西部決賽和總決賽，面對以巨星輪番單打為主的雷霆和騎士隊的沖擊，勇士隊再而衰，三而竭，終于敗下陣來。 　　其實，在去年的總決賽上，詹姆斯一個巨星就差點兒把勇士隊掀翻。如果有另一個人能分擔壓力，巨星連線或輪流沖擊，興許已經得手。 　　究其原因，在狹小的場地，高強度的壓迫下，過多的傳球容易被搶斷。總決賽最后幾場，勇士隊核心庫里關鍵時刻幾次致命的傳球失誤，令人記憶猶新。 　　然而，在過去的十年間，增加傳球、控制局面卻成為足球界的主流打法。西班牙隊依靠傳控打法在2008年登頂，并繼續統治了隨后兩屆大賽。奪得2014年世界杯的德國隊，也是當屆賽事上場均傳球次數最多的球隊。 　　凡事皆有例外，譬如2016年歐洲杯黑馬冰島隊，小組賽與最后的冠軍葡萄牙1比1戰平，卻只有后者一半的控球率（34%對66%）、三分之一強的傳球次數（223對616）、不到四分之一的成功傳球（132對536）。上賽季爆冷奪得英超冠軍的萊斯特城隊也是類似的路數。 　　歐洲杯小組賽最后一輪，沒有知名球星的冰島隊在最后一刻反擊，兩名隊員緊追帶球隊友，接應傳球絕殺奧地利……培養三名能奔善跑、傳球過關的隊員，可比發掘一位馬拉多納式的球王，要容易得多啊 　　冰島在越過“偽強隊”英格蘭之后被傳控更佳的法國隊無情摧殘，萊斯特的劇本也不可能在本賽季的英超重演。用傳控支配、消耗對手，仍然是頂級強隊的標志。 　　本節探討的現象與上節有緊密的聯系：球員們更能跑了，個人帶球過多很難打開局面；傳球當然比人跑得快，但長傳一則準確性欠佳，二則飛行時間過長，留給對手從容布防。于是，積極跑動的球員和頻繁的中短距離傳球結合，將整支球隊編織為一張伸縮自如的網絡。 　　SAN是專門為共享存儲系統（磁盤陣列）設計的網絡，用于把一臺或多臺主機（服務器）連接到存儲系統上使用。SAN的典型協議（如FC）與服務器之間的網絡（如以太網）不同，工作模式也很不一樣：一個存儲網絡里可能有多個存儲系統，但它們之間很少互相傳輸數據，或協商分擔工作負載。 　　可以說，SAN和Scale-up的模型里，沒有連續“傳球”的概念。雙控制器的切換，也像是一次性的球權轉移。 　　反過來，分布式、集群、Scale-out和Server SAN，每個名詞都透著濃濃的“傳球”協作味道。節點間的自動協調和數據傳輸是整個系統的生命線，必須要有高質量的網絡做保證。仍以FusionCube分布式存儲為例，接收I/O請求的節點，其VBS模塊計算出的硬盤位置如果不在本節點內，就必須通過節點間的網絡轉發到所屬節點，并等待返回，才能完成操作。如果網絡帶寬不夠或延遲過高，均會拖慢整個系統的性能。 　　與“純正的”FC SAN相比，Server SAN不需要引入（與服務器網絡）異構的網絡，節點之間的網絡和面向應用（服務器）的網絡可以基于同樣的網絡技術——以太網，或者InfiniBand（IB）。當然，這兩張網絡需要進行物理或邏輯上的隔離，以避免互相干擾。 　　為了保證Server SAN的性能，每服務器需要提供4Gbps帶寬用于FusionCube分布式存儲通信，推薦使用萬兆網絡。用于融合部署云資源池（如FusionCube 6000），且超過16個節點時，業務平面（面向應用）和存儲平面（節點之間）必須使用獨立的網卡。 　　FusionCube分布式存儲對接VMware、Xen和KVM的分離部署模式，可以看到網絡、SSD和硬盤的I/O路徑（存儲端的OS也可以是RHEL，或者Xen、KVM） 　　單個10GbE端口的帶寬約為1GB/s，對硬盤算挺高，而理論上1個PCIe SSD或2～4個SATA SSD即可填滿。 　　像Oracle RAC和SAP HANA等對性能要求很高的應用，節點之間的網絡可以換成InfiniBand，典型如FusionCube 9000。InfiniBand不僅具有四五倍于萬兆以太網的帶寬（40Gbps QDR或56Gbps FDR），還有低至納秒級的超短延遲，OLAP（高帶寬）、OLTP（高IOPS、低延遲）應用兩相宜。 　　InfiniBand的路線圖，遠非FC(SAN)可比。今年6月舉行的國際超算大會2016上，華為攜手Mellanox發布基于FusionServer E9000融合架構刀片服務器的InfiniBand EDR 100G交換解決方案 　　網絡、SSD和計算能力的相對廉價，是拉動軟件定義存儲的三駕馬車。不過，目前企業級SDS主要用的還是網絡的數據面，SDN要到規模非常大的時候才可能成為必需品。 　　（未完待續……）