目前，在私有云建設（很多可能并不是真正的私有云，也包括一些虛擬化平臺的建設）中，超融合出現的身影越來越多，本文

我們探討下超融合技術。

一 什么是超融合

        既然在說超融合架構，那就肯定有一般的融合架構，這其實也是目前行業內對于超融合定義爭論的焦點，也就是說哪些定義為

融合架構，哪些定義為超融合架構。

        個人來說比較傾向于以下定義：天然地(Natively)將兩個或多個組件組合到一個獨立的單元中，這句話的關鍵詞是天然地

（Natively）。這種定義有個好處就是留了很多自由解釋的空間，沒有把這個邊界框得太死。

        至于其他的解釋，個人覺得太具體化了，太具體的東西就容易引發爭議。其實和很多IT領域里面的技術名稱一樣，我們不一定

要追求一個所謂的標準定義，可能起名稱的人本來就沒考慮這么多。

二 超融合的出現

2.1    性能需求

        傳統架構的業務系統在運行一段時間后，經常會遇到業務系統變慢，特別是在業務高峰期表現非常明顯，比如月底月初的財務

系統。

        那在大多數的案例中，問題往往出現在存儲陣列上面，特別是虛擬化普及后，這種情況表現得更加明顯。這主要是在陣列使用

一段時間后，隨著磁盤等部件的老化，磁盤陣列的性能會存在一定的性能下降；同時，業務系統的運行也存在著使用范圍越來越廣，

用戶越來越多，特別是虛擬化平臺上虛擬機越開越多的情況。

        那傳統的解決方案，往往是更換性能更高的存儲設備，特別是SSD盤的價格下調在一定程度上解決了陣列磁盤的讀寫問題，但

是，這時網絡和陣列控制器往往成為了新的瓶頸。

        在網絡方面，以Intel S3700系列固態硬盤為例，其讀寫速度分別可達500MB/s和460MB/s,那不同的網絡帶寬能滿足對應的SSD

盤理論讀寫速度如下：

        就算是理論上支持40Gb的交換速度的IB交換機的出現，依然不能滿足大規模固態盤使用的速度要求。

        在存儲控制器方面：SSD對存儲架構的影響是巨大的，傳統機械硬盤的4K隨機性能只有300左右，而類似intel 3700這樣的

SSD則可以達到超過7.5萬IOPS。雙控制器架構在閃存架構中會成為瓶頸，比如EMC的Unity 650 可以支持一千塊硬盤或SSD，

但31塊SSD的時候就到達瓶頸。

2.2    技術的成熟

（1）分布式存儲架構

        分布式存儲在亞馬遜、谷歌等大型公有云得到了很好的應用，它基于X86服務器構建一個易擴展、高可靠的存儲資源池，這是

超融合的基礎。

（2）SSD盤的廣泛使用

        SSD的出現，解決了超融合架構中冷熱數據分層的問題，也使得數據的訪問速度相對比陣列訪問有了質的提高，下面是特定

I/O類型的不同延遲特性：

（3）CPU、網絡

        CPU長期以來基本遵循了摩爾定律的發展，更加強大廉價的CPU能在同時滿足計算和存儲需求。同時，萬兆網絡的普及解決了

不同服務器之間的數據橫向快速流動的要求。

2.3    超融合的技術路線

        超融合這個概念太熱，以至于除了我們所熟知Nutanix、VMware等廠商外，大部分的傳統硬件廠商都推出了自己超融合產品，

比如HP、DELL、華為、華三……，也有一些新晉玩家像深信服、SmartX等。

        但這些廠商所走的超融合路線也有很大不同。

        按照融合的程度，大致分為兩大類：

        以Nutanix、VMware為代表的廠商，強調盡量利用服務器本地資源來滿足虛擬機的計算、存儲需求，計算資源、存儲資源沒有

在硬件層做硬性的劃分，他強調的是計算資源池、存儲資源池的概念，在超融合的底層讓虛擬化優先使用本地的存儲資源。

        另外一個技術路線的廠商大多借鑒Oracle數據庫一體機的實現方式，將X86服務器劃分為計算節點和存儲節點，服務器之間采

用IB交換機相連，這和傳統的集中式存儲在邏輯架構上是一致的，區別只是用分布式存儲取代了磁盤陣列。

        在小型規模的應用上，以上兩種路線的區別不大，但在規模應用之后，第二種實現方式的網絡瓶頸就可能會顯現。本文介紹的

超融合技術，將以第一種為參照。

三 超融合的架構

        由于Nutanix在超融合領域的地位，其他超融合廠商在技術實現或多或少的借鑒了Natanix，該部分主要借鑒Nutanix超融合技術

方案讓大家了解下具體的超融合技術實現，以避免相關內容流于概念和表面。

        在Nutanix的架構中，大致可分為兩大塊，Prism和Acropolis。簡單的說就是一個是管理模塊（給管理人員用的），一個資源管

理模塊（如何去調度底層資源）。

3.1    Prism

        Prism是一個分布式的資源管理平臺，允許用戶跨集群環境管理和監控對象及服務。

        這部分內容不難理解，這里不做太多介紹，感興趣的朋友可以自己去查閱相關文檔。

3.2    Acropolis

        Acropolis 是一個分布式的多資源管理器，集協同管理和數據平臺功能于一身。它可以被細分為如下三個主要組件：

        ? 分布式存儲架構 (DSF)

        o 這是Nutanix 核心的賴以生存的組件，其基于分布式文件系統（HDFS）擴展而來。

        ? 應用移動性架構 (AMF)

        o 類似于 Hypervisor 把操作系統從硬件剝離而來，AMF 把工作負載（虛機、存儲和容器等）從 Hypervisor 抽象剝離開。這使

        能在不同的Hypervisor 之間切換和移動工作負載。

        ? 虛擬化管理器（AHV）

        o 一個基于 CentOS KVM hypervisor 的多用途虛擬化管理器組件。

        下圖以概要的方式展示了 Acropolis 不同層次的結構和關系：

3.2.1  融合平臺

        Nutanix 解決方案是一個融合了存儲和計算資源于一體的解決方案。它利用本地資源/組件來為虛擬化構建一個分布式的平臺，

亦稱作虛擬計算平臺。

        每個節點運行業界標準的 hypervisor（ESXi, KVM, Hyper-V）和 Nutanix 控制器虛機（CVM）。Nutanix CVM 中運行著

Nutanix 核心軟件，服務于所有虛機和虛機對應的 I/O 操作。得益于Intel VT-d（VM直接通路）技術，對于運行著VMware vSphere

的 Nutanix 單元，SCSI 控制（管理 SSD 和 HDD 設備）被直接傳遞到CVM。 下圖解釋了典型的節點邏輯架構：

3.2.2  集群組件

        Nutanix 平臺由下列宏觀組件構成：

        Cassandra

         ? 關鍵角色: 分布式元數據存儲

        ?描述：Cassandra 基于重度修改過的 Apache Cassandra，以分布式環的方式存放 和管理所有的集群元數據。Paxos 算法被

        用來保證嚴密的一致性。在集群中所有 節點上都運 行著這個服務。Cassandra 通過一個叫做 Medusa 的協議來訪問。

        Zookeeper

        ? 關鍵角色: 集群配置管理

        ? 描述：基于 Apache Zookeeper 實現，Zookeeper 存放了所有的集群配置信息，包 括主機、IP 地址和狀態等。集群中有三

        個節點會運行此服務，其中的一個被選舉 成 leader。Leader 接收所有請求并轉發到它的組員。一旦 leader 失去了反應，新

        的leader 會被自動選舉出來。Zookeeper 通過稱作 Zeus 的接口來訪問。

        Stargate

        ? 關鍵角色: 數據 I/O 管理

        ? 描述：Stargate負責所有的數據管理和 I/O 操作，是 hypervisor 主要的接口（通過 NFS、iSCSI 或 SMB）。為了供本地 I/O

        操作的能力，集群中所有節點都運行此服務。

        Curator

         ? 關鍵角色：以 Mapreduce 方式管理和清理集群

        ?描述：Curator 負責在整個集群間分配和調度任務，諸如磁盤容量平衡、預清理等 。

        Prism

         ? 關鍵角色：用戶界面和 API

        ?描述：Prism 是一個組件管理網關，它讓管理員能配置和監控 Nutanix 集群。它提供多種管理手段，如 Ncli、HTML5 UI 和

        REST API。Prism運行在集群中的每個節點，如同集群中其他組件一樣也采用 leader 選舉制。

        Genesis

        ? 關鍵角色：集群組件和服務管理

        ?描述：Genesis 是一個負責配置初始化和服務交互的進程，運行在每個節點上。 Genesis 不依賴于集群，即不管集群是否配

        置或運行與否，它都運行著。它唯一的前提是 Zookeeper 必須起來并運行著。

        Chronos

        ? 關鍵角色：任務調度

        ? 描述：Chronos 負責把由 Curator 掃?產生的任務在節點間調度執行并合理分配。 Chronos 運行在每個節點上，受控于主

        Chronos（負責任務委托且和主 Curator 運行在同一節點）。

        Cerebro

        ? 關鍵角色：數據復制和容災管理

        ? 描述：Cerebro 負責 DSF 中的數據復制和容災管理部分，包含快照的調度、遠程 站點的數據同步及站點的遷移和故障切換。

        Cerebro 運行在 Nutanix 集群的每個節 點上，并且每個節點都參與遠程站點/集群的數據同步。

        Pithos

        ? 關鍵角色：vDisk 配置管理

        ? 描述：Pithos 負責 vDisk（DSF 文件）的配置數據。Pithos 構建于 Cassandra 之 上，并運行在每個節點。

四 分布式關鍵技術和概念

4.1    節點架構

        在ESXi的部署中，控制器虛擬機（CVM）硬盤使用的 VMDirectPath I/O 方 式。這使得完整的PCI控制器（和附加設備）通過

直通方式連接 CVM并繞過虛擬化層。 這種設計讓其超融合技術和虛擬化軟件實現了解耦。

4.2    存儲池

        一個存儲池是一組物理存儲設備，大部分情況下，單個集群配置一個存儲池。

4.3    容器

        容器（container）從邏輯上劃分存儲池，并包含一組虛擬機或者文件（即虛擬磁盤）。很多人可能不理解為什么Nutanix要提

出容器的概念，其實它是為了數據存儲的靈活性，比如，在一個集群內，不同的虛擬化對應的應用數據可能重要性不同，需要的副

本數也不同，這時，就需要采用不同的容器，進行不同的設定。所以在實際使用了，我們經常將對存儲需求類似的虛擬機（含數據）

劃分到同一個容器內，這不僅要考慮當前狀態，還有今后可能的變動。

4.4    KVM架構

         KVM 中包含以下主要組成：

         KVM-kmod ： KVM 內核

         Libvirtd： API 接口，針對 KVM 和 QEMU 的監控、管理工具。 Acropolis 通過 libvirtd 與 KVM／QEMU 進行通訊。

         Qemu-kvm ： 一個“模擬器”（machine emulator），使得各個虛擬機能夠獨立運行。 Acropolis 通過它來實現硬件的虛擬化，

并使得 VM 以 HVM 的形式運行。

        以下是各個組成的邏輯示意圖：

        處理器兼容性

        類似于 Vmware 的 Enhanced vMotion Capability（EVC），它允許 VM 在不 同代次的處理器間進行遷移。Acropolis 將檢測

群集中代次最老的處理器，并把 所有的 QEMU 限定在此級別上。這樣就可以允許不同代次的處理器進行混 用，并確保主機之間可

以實現 VM 的在線遷移。

4.5    Nutanix的復制因子和冗余因子

        Nutanix的冗余因子在集群創建的時候就需要設置，并且后期不能改變，它確定了集群能同時壞掉多少臺物理服務器而不影響集

群的正常運行，而復制因子是針對容器的（一個集群一般包含多個容器），它表示了數據在容器的副本份數。應該來說，冗余因子從

物理上保證了復制因子的實現，所以，復制因子不能大于冗余因子，只能小于等于。

4.6    VM High Availability (HA)

        Acropolis 的 VM HA 可以確保當主機或 Block 掉電時，VM 的持續運行。當某個主機宕機時，VM 將在集群中某個健康節點中重

新啟動。其中，Acropolis Master 負責該 VM 的重啟操作。

        Acropolis Master 通過 Libvirt 監測節點的健康狀況：

五 超融合適用用戶

        超融合適合所有用戶嗎，這個回答見仁見智？不過個人認為，以下情況的客戶可以優先考慮超融合：

        1、如果在今后一段時間內，業務可能有較大增長；

        2、對系統對IO性能有較高要求；

        3、技術實力較強，想要對自身信息化架構充分掌控；

        但如果沒有自己的技術力量，又非常看重硬件平臺的穩定性，對任何硬件故障有一定程度“恐懼”的客戶建議可以再等等。

六 結論

        在未來幾年，可以確信“超融合”架構，以其強大的性能、部署靈活性、使用方便性等多方面優勢，將成為主流的IT架構之一。