SDN实战团分享(三十一):Nutanix超融合之架构设计

超融合平台

针对于超融合的概念有着不同的理解,因为组件不同(虚拟化、网络等)而理解不同。然而,核心的概念如下:天然地将两个或多个组件组合到一个独立的单元 中。在这里,“天然”是一个关键词。为了更加有效率,组件一定是天然地整合在一起, 而不是简单地捆绑在一起。对于 Nutanix,我们天然地将计算和存储融合到设备的单一节点中 。这就真正意味着天然地将两个或多个组件整合在一个独立的、 可容易扩展的单元中。

其优势在于:

1.独立单元的扩展

2.本地I/O处理

3.消除传统计算/存储的竖井式结构,融合它们在一起

目前Nutanix超融合产品有两种形态: 1、捆绑式的硬件 + 软件设备(Nutanix NX系列、Dell XC系列及联想HX系列),2、纯软件模式(Nutanix on UCS等)

一般来说,从硬件形态看,是在 2U 的占用空间中放置 2 个节点或 4 个节点。每个节点都运行一个符合行业标准的虚拟机监控程序(当前是 ESXi、KVM、Hyper-V, XenServer在目前版本是Tech-Preview)和 Nutanix 控制器 VM (CVM)。

Nutanix CVM 将运行 Nutanix 软件,并为虚拟机监控程序的所有 I/O 操作和该主机上运行的所有 VM 提供服务。凭借虚拟机监控程序的功能,利用 Intel VT-d 将管理 SSD 和 HDD 设备的 SCSI 控制器直接传递到 CVM。

下面是典型节点的逻辑表现形式的一个示例:

从软件定义的角度来看,一般来说,软件定义的智能化是在通用的、商品化的硬件之上通过运行软件来实现核心的逻辑,而这些逻辑之前用专有的硬件编程方式实现(例如 ASIC/FPGA 等)。对于 Nutanix 而言,是将传统的存储逻辑(例如 RAID,去重,压缩,纠删码等)采用软件方式去 实现,这些软件运行在标准的 x86 硬件上的 Nutanix 控制虚拟机(Controller Virtual Machine,即 CVM)内。那就真正意味着把关键处理逻辑从专有硬件中剥离放入到 运行在商用的硬件设备的软件之中。

一组 Nutanix 节点共同构成一个分布式平台,称为 Nutanix 分布式系统框架(DSF)。对于虚拟机监控程序,DSF 看起来就像任何集中式存储阵列一样,不过所有 I/O 都在本地进行处理,以提供最高性能。下面可找到有关这些节点如何形成分布式系统的更多详细信息。

以下是有关这些 Nutanix 节点如何形成 DSF系统的示例:

DSF可以看作是一个分布式自治系统,涉及从传统的单一集中模式处理业务转向跨集群内的所有节点分布式处理业务。传统角度考虑问题是假设硬件是可靠的,在某种程度上是对的。然而分布式系统的核心思想是硬件终究会出问题,在一个简单的、业务不间断的方式中处理故障是关键点。这些分布式系统的设计是为了调整和修复故障,达到自恢复和自治的目地。在组件发生故障时,系统 将透明地处理和修复故障,并持续按照预期运行。将会醒用户知晓故障的存在, 但不会作为一个紧急事件被提出来,任何一种修复(如:替代一个失效的节点)都可 以按照管理员事先设定好的计划表去自动化的处理。另外一种方式是重建而不需要替换,一个主数据节点被随机选举出来,当其故障后新的主数据节点会被选举出来, 利用 MapReduce 的概念来分配任务的处理。

因此DSF可实现:

☘ 分配的角色和任务到系统内的所有节点

☘ 利用MapReduce等机制执行分布式任务处理

☘ 当需要一个新的主数据节点时,采用选举机制

优势在于:

☘ 解决了单点故障(SPOF)

☘ 分布式业务负载,消除任何瓶颈

Nutanix超融合群集组件

Nutanix 平台由以下高级组件组成:

Medusa

☘ 关键角色:分布式元数据存储

☘ 描述:Medusa 基于经过重大修改的 Apache Cassandra,以一种环式分布方式存储和管理所有群集元数据。利用 Paxos 算法来保证严格一致性。该服务在群集中的每个节点上运行。

Zeus

☘ 关键角色:群集配置管理器

☘ 描述:Zeus 将存储所有群集配置(包括主机、IP、状态等)并且基于 Apache Zookeeper。该服务在群集中的三个节点上运行,其中一个被选举为领导节点。领导节点会接收所有请求并将其转发给对等节点。如果领导节点没有响应,则会自动选举一个新的领导节点。

Stargate

关键角色:数据 I/O 管理器

☘ 描述:Stargate 负责所有数据管理和 I/O 操作,并且是虚拟机监控程序的主要界面(经由 NFS、iSCSI 或 SMB)。该服务在群集中的每个节点上运行,以便为已本地化的 I/O 提供服务。

Curator

☘ 关键角色:映射化简群集的管理和清理

☘ 描述:管理者将负责整个群集中任务的管理和分配,包括磁盘平衡、主动清理和许多其他项目。管理者在每个节点上运行,而且受选定的主管理者的控制,主管理者会负责任务和作业的委派。

Prism

☘ 关键角色:UI 和 API

☘ 描述:Prism 是组件的管理网关,也是管理员配置和监控 Nutanix 群集所使用的管理网关。这包括 Ncli、HTML5 UI 和 REST API。Prism 在群集中的每个节点上运行,而且与群集中所有组件一样使用选定的领导者。

此外,Nutanix集群的节点间通讯(包括存储,服务)采用Google的Protocol Buffers以提升分布式系统的通讯效率和性能。

数据结构

Nutanix DSF的分布式存储系统由以下高级结构组成:

存储池

☘ 关键角色:物理设备组

☘ 描述:存储池是一组物理存储设备,包括群集的 PCIe SSD、SSD 和 HDD 设备。存储池可以跨越多个 Nutanix 节点,并且会随群集的扩展而扩展。大多数配置中只使用一个存储池。

容器

☘ 关键角色:VM/文件组

☘ 描述:容器是存储池的一个逻辑分段,包含一组 VM 或文件(虚拟磁盘)。有些配置选项(比如 RF)是在容器级别配置的,但是会应用于单独的 VM/文件级别。容器通常与数据存储存在 1 对 1 的映射(就 NFS/SMB 而言)。

vDisk

☘ 关键角色:虚拟磁盘

☘ 描述:虚拟磁盘是 DSF 上任何超过 512KB 的文件(包括 .vmdks 和 VM 硬盘)。虚拟磁盘由盘区构成,这些盘区在磁盘上作为盘区组进行分组并存储。

下图展示了这些节点如何在 DSF 和虚拟机监控程序之间进行映射:

Extent

☘ 关键角色:逻辑上连续的数据

☘ 描述:盘区是一段逻辑上连续的 1MB 的数据,由 n 个连续块组成(因来宾操作系统块的大小不同而不同)。以子盘区(又称切片)为基础来写入/读取/修改盘区,以保证粒度和效率。根据读取/缓存的数据量,将盘区的切片移动到缓存中时可能会对其进行剪裁。

盘区组

☘ 关键角色:物理上连续的存储数据

☘ 描述:盘区组是一段物理上连续的 4MB 的存储数据。该数据作为一个文件保存在 CVM 所拥有的存储设备上。盘区动态分布在盘区组之间,以便跨节点/磁盘提供数据分块,从而提高性能。

下图展示了这些结构在各种文件系统之间是如何关联的:

下面是有关这些单元如何逻辑相关的另一个图形表示:

I/O 路径概述

Nutanix DSF系统的 I/O 路径由以下高级组件组成:

OpLog

☘ 关键角色:永久性写入缓冲区

☘ 描述:Oplog 类似于文件系统日志,它的构建是为了处理突发性写入,它会将写入合并,然后将数据按顺序排入盘区存储。为了确定数据可用性而要确认写入之前,OpLog 会将写入同步复制到另一个 CVM 的 OpLog。所有 CVM 的 OpLog 都会参与复制,并且会根据负载进行动态选择。OpLog 存储在 CVM 的 SSD 层上,以便提供极快速的写入 I/O 性能,特别是对于随机 I/O 工作负载。对于连续工作负载,OpLog 将被绕过,写入直接进入盘区存储。如果当前数据处于 OpLog 中且尚未排出,所有读取请求将从 OpLog 直接完成,直到将它们排出,然后将由盘区存储/内容缓存为它们提供服务。对于启用指纹识别(又称重复数据删除)的容器,将会使用哈希方案对所有写入 I/O 进行指纹识别,以便根据内容缓存中的指纹来识别它们。

Extent Store

☘ 关键角色:永久性数据存储

☘ 描述:盘区存储是 DSF 的永久性大容量存储,跨 SSD 和 HDD,而且可以扩展,为其他设备/层提供便利。进入盘区存储的数据要么是 A) 从 OpLog 排出的,要么是 B) 本质上是连续的,直接绕过 OpLog。Nutanix ILM 将根据 I/O 模式动态确定层的放置并将数据在各层之间移动。

内容缓存

☘ 关键角色:动态读取缓存

☘ 描述:内容缓存(又称“弹性重复数据删除引擎”),是通过指纹识别的读取缓存,可以跨越 CVM 的内存和 SSD。当缓存中(或根据特定指纹)不存在数据的读取请求时,数据将被放入单一触控的内容缓存池中,内容缓存池完全处于内存中,在这里它会使用 LRU,直到将其从缓存中选定。任何后续读取请求会将数据“移动”(事实上并不移动任何数据,只是缓存元数据)到由内存和 SSD 组成的多点触控池的内存部分。这里将有两次 LRU 循环,其中一次是针对内存中的数据,逐出会根据它将数据移动到多点触控池的 SSD 部分,在多点触控池中将分配新的 LRU 计数器。多点触控池中任何数据读取请求都将导致数据达到多点触控池的顶峰,在这里会为其给定一个新的 LRU 计数器。指纹识别是在容器级别配置的,并可通过 UI 配置。默认情况下禁用指纹识别。

下图展示了内容缓存的高级概述:

数据保护

目前,Nutanix 平台使用复制因子 (RF) 来确保节点或磁盘发生故障时数据的冗余和可用性。如“架构设计”部分所述,OpLog 充当一个临时区域,将传入的写入吸收到低延迟的 SSD 层。将数据写入本地 OpLog 时,在被主机确认 (Ack) 为成功写入之前,数据将会同步复制到另外的一个或两个 Nutanix CVM 的 OpLog 中(取决于 RF)。这将确保数据存在于至少两个独立的位置,且具有容错能力。所有节点均参与 OpLog 复制以避免出现任何“热节点”并确保扩展时的线性性能。

然后,将数据异步排出到隐式维持 RF 的盘区存储中。之后在节点或磁盘出现故障的情况下,会将数据在群集中的所有节点之间重新复制以维持 RF。

下面我们将展示此过程的逻辑表现形式的一个示例:

数据位置

作为一个融合的(计算+存储)平台,I/O 和数据位置对与 Nutanix 有关的群集和 VM 性能至关重要。如前面 I/O 路径中所述,所有读取/写入 IO 均由本地控制器 VM (CVM) 提供服务,本地控制器 VM 位于邻近常规 VM 的每个虚拟机监控程序中。在 CVM 的控制下,VM 的数据将在本地由 CVM 提供服务并且位于本地磁盘中。当 VM 从一个虚拟机监控程序节点移动到另一个时(或发生 HA 事件时),最新迁移的 VM 的数据将由现在的本地 CVM 提供服务。在读取旧数据(存储在现在的远程节点/CVM 上)时,I/O 将由本地 CVM 转发到远程 CVM。所有写入 I/O 将立即在本地出现。DSF 会检测到 I/O 从另一节点出现,并在后台将数据迁移到本地,现在将允许在本地为所有读取 I/O 提供服务。为了不泛洪网络,只在读取时迁移数据。

下面我们将展示数据在虚拟机监控程序的节点之间移动时如何“跟随”VM 的一个示例:

原文发布于微信公众号 - SDNLAB(SDNLAB)

原文发表时间:2017-02-09

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏携程技术中心

干货 | Android工程模块化平台的设计

19430
来自专栏一名叫大蕉的程序员

分布式文件系统.get(V2)No.106

2018年9月28号,我估计会记得很久这一天,因为那天刚刚好是我来西厂的一周年,那天刚刚好是农历生日,刚刚好那天晚上我挖了一个大坑,跟遣怀师兄和小美姐姐一起填坑...

12520
来自专栏乐沙弥的世界

Percona XtraDB Cluster集群节点重启及故障转移

要重新启动集群节点,请关闭MySQL并重新启动它。该节点将离开集群(并且法定人数的总计数应该减少)。发布命令 systemctl restart mysql

11220
来自专栏后端技术探索

另一篇mysql防止库存超卖

今天王总又给我们上了一课,其实MySQL处理高并发,防止库存超卖的问题,在去年的时候,王总已经提过;但是很可惜,即使当时大家都听懂了,但是在现实开发中,还是没这...

17410
来自专栏LET

谈谈JavaScript代码优化

24460
来自专栏腾讯Bugly的专栏

《手Q Android线程死锁监控与自动化分析实践》

手Q每个版本上线以后研发同学都会收到各种问题反馈。在跟进手Q内部用户反馈的问题时,发现多例问题,其表象和原因如下:

1.1K80
来自专栏码神联盟

碎片化 | 第一阶段-06-第一个小程序-视频

如清晰度低,可转PC网页观看高清版本: 第一个java程序Hello word 暂时我们先使用记事本来编写代码,不建议直接使用开发工具eclipse,那都自动生...

38180
来自专栏腾讯Bugly的专栏

Android 插件技术实战总结

前言 安卓应用开发的大量难题,其实最后都需要插件技术去解决。 现今插件技术的使用非常普遍,比如微信、QQ、淘宝、天猫、空间、携程、大众点评、手机管家等等这些大家...

39260
来自专栏Python专栏

Python | 利用Python实现微博监控小姐姐动态

作者:奶权 来源:http://www.jianshu.com/p/9e7ba0a0a610

35720
来自专栏idealclover的填坑日常

从零开始折腾博客(0):静态?动态?

这两天心血来潮,忽然想折腾一个属于自己的博客,也就是这一系列的缘由。而最终也总算是折腾出来了,要不你就不会看到这篇文章了

16610

扫码关注云+社区

领取腾讯云代金券