目前，在私有云建设（很多可能并不是真正的私有云，也包括一些虚拟化平台的建设）中，超融合出现的身影越来越多，本文

我们探讨下超融合技术。

一 什么是超融合

既然在说超融合架构，那就肯定有一般的融合架构，这其实也是目前行业内对于超融合定义争论的焦点，也就是说哪些定义为

融合架构，哪些定义为超融合架构。

个人来说比较倾向于以下定义：天然地(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架构之一。

原文地址：https://www.cnblogs.com/zjh0301/p/9065800.html