Nutanix 圣经（AOS5.16）
作者： Steven Poitras
翻译及审校： Nutanix 中国工程师团队2020.05
.

.
.
.
1

目

录

1 第一部分：历史回顾 .................................................................................... 9
1.1

1.1.1

大型机的时代 ................................................................................ 9

1.1.2

转向独立的服务器 ......................................................................... 91.1.3

集中式存储 .................................................................................... 9

1.1.4

虚拟化的出现 .............................................................................. 10

1.1.5

虚拟化的成熟 .............................................................................. 10

1.1.6

固态硬盘(SSD) ............................................................................ 11

1.1.7

云的到来 ...................................................................................... 11

1.2

延迟的重要性 ...................................................................................... 12

1.2.1

带宽的考量 .................................................................................. 13

1.2.2

内存延迟的影响 ........................................................................... 14

1.3

用户空间 vs 内核空间 ......................................................................... 15

1.3.1

轮询与中断 .................................................................................. 16

1.3.2

移动到用户空间/轮询 ................................................................... 171.4

2

数据中心的演变 .................................................................................... 9

Web-Scale .......................................................................................... 18

1.4.1

超融合 ......................................................................................... 19

1.4.2

软件定义的智能化 ....................................................................... 191.4.3

分布式自治系统 ........................................................................... 20

1.4.4

递增性和线性扩展 ....................................................................... 20

1.4.5

总结 ............................................................................................. 20

第二部分：基础 ......................................................................................... 22
2.1

策略和愿景 ......................................................................................... 22

2.1.1

超融合/云/虚拟化:“选择” .............................................................. 22

2.1.2

Acropolis (AOS + AHV/虚拟化平台):“运行时”.............................. 232

2.1.3

Prism“界面” ................................................................................. 24

2.1.4

Nutanix: 平台 ............................................................................... 25

2.2

2.2.1

第一步: 数据中心现代化(Core) .................................................... 27

2.2.2

第二步: 建设私有云(Essentials) .................................................. 27

2.2.3

第三部: 建设混合云(Enterprise) .................................................. 28

2.2.4

平台 ............................................................................................. 29

2.3

超融合平台 ......................................................................................... 292.4

分布式系统 ......................................................................................... 33

2.5

软件定义 ............................................................................................. 34

2.6

集群组件 ............................................................................................. 35

2.7

不间断升级 ......................................................................................... 37

2.7.1

步骤 1 - 升级前检查 ..................................................................... 38

2.7.2

步骤 2- 将升级软件上传到 2 节点 ................................................ 38

2.7.3

步骤 3 - 阶段升级软件 ................................................................. 38

2.8Foundation（镜像） ........................................................................... 39

2.8.1

架构 ............................................................................................. 39

2.8.2

输入项 ......................................................................................... 40

2.8.3

系统镜像和部署 ........................................................................... 41

2.9
3

产品和平台 ......................................................................................... 26磁盘驱动器解构 .................................................................................. 46

第三部分：Prism ....................................................................................... 49
3.1

设计方法 ............................................................................................. 49

3.2

架构 .................................................................................................... 49

3.2.1

Prism 的服务 ............................................................................... 51

3.2.2

认证和访问控制 ........................................................................... 52

3.3

管理导航 ............................................................................................. 53

3.3.1

Prism Central .............................................................................. 53

3.3.2

搜索 ............................................................................................. 56
3

3.3.3

Prism Element ............................................................................. 58

3.3.4

快捷键 ......................................................................................... 59

3.4

3.4.1

异常检测 ...................................................................................... 60

3.4.2

Nutanix 软件升级 ......................................................................... 63

3.4.3

Hypervisor 升级 ........................................................................... 66

3.4.4

集群扩展(增加节点) ..................................................................... 69

3.4.5

I/O 度量 ....................................................................................... 75

3.4.6

容量规划 ...................................................................................... 79

3.4.7

X-Play ......................................................................................... 81

3.54

特性和使用 ......................................................................................... 59

APIs 接口 ............................................................................................ 87

3.5.1

ACLI ............................................................................................ 88

3.5.2

NCLI ............................................................................................ 93

3.5.3

PowerShell CMDlets ................................................................... 96

第四部分： Acropolis ............................................................................... 102
4.1

架构 .................................................................................................. 102

4.1.1

Acropolis 服务 ........................................................................... 102

4.1.2

动态调度 .................................................................................... 104

4.1.3

放置位置 .................................................................................... 106

4.2

安全与加密 ....................................................................................... 106

4.2.1
4.3

数据加密和密钥管理 .................................................................. 117

分布式存储结构 ................................................................................ 125

4.3.1

数据结构 .................................................................................... 126

4.3.2

I/O 路径和缓存 .......................................................................... 128

4.3.3

可扩展的元数据 ......................................................................... 137

4.3.4

数据保护 .................................................................................... 140

4.3.5

可用域（机箱感知） .................................................................. 141

4.3.6

数据路径冗余 ............................................................................ 151

44.3.7

容量优化 .................................................................................... 156

4.3.8

存储分层和优先级 ..................................................................... 165

4.3.9

磁盘平衡 .................................................................................... 167

4.3.10

快照和克隆 ................................................................................ 169

4.3.11

网络及 I/O ................................................................................. 172

4.3.12数据本地化 Data Locality .......................................................... 173

4.3.13

影子克隆 Shadow Clones.......................................................... 174

4.3.14存储层和监控 ............................................................................ 175

4.4

服务 .................................................................................................. 177

4.4.1

Nutanix Guest Tools (NGT) ...................................................... 177

4.4.2

OS 定制化 ................................................................................. 184

4.4.3

Karbon（容器服务） ................................................................. 189

4.5

备份与容灾 ....................................................................................... 193

4.5.1

实施组件 .................................................................................... 194

4.5.2

保护对象 .................................................................................... 195

4.5.3

备份和恢复 ................................................................................ 199

4.5.4

应用一致性快照 ......................................................................... 202

4.5.5

复制和容灾（DR） .................................................................... 206

4.5.6

近同步复制技术（NearSync） .................................................. 209

4.5.7

城域高可用性 Metro Availability ................................................ 211

4.5.8

云链接 ....................................................................................... 214

4.6

Application Mobility Fabric* .............................................................. 217

4.7

管理 .................................................................................................. 217

4.7.1

重要页 ....................................................................................... 217

4.7.2

集群命令 .................................................................................... 219

4.7.3

指标和阈值 ................................................................................ 225

4.7.4

Gflags ........................................................................................ 225

4.7.5

故障排除和高级管理 .................................................................. 225
5

5

第五部分：AHV ....................................................................................... 242
5.1

5.1.1

节点架构 .................................................................................... 242

5.1.2

KVM 架构 .................................................................................. 242

5.1.3

最高配置和可扩展性 .................................................................. 243

5.1.4

网络 ........................................................................................... 244

5.2

如何工作 ........................................................................................... 248

5.2.1

存储 I/O 路径 ............................................................................. 248

5.2.2

IP 地址管理 ............................................................................... 257

5.2.3

VM 高可用性 (HA) ..................................................................... 258

5.3

6

架构 .................................................................................................. 242

管理 .................................................................................................. 261

5.3.1

重要页* ...................................................................................... 261

5.3.2

命令参考 .................................................................................... 261

5.3.3

计量与阈值 ................................................................................ 264

5.3.4

故障处理& 高级管理 .................................................................. 264

第六部分：vSphere ................................................................................. 265
6.1

架构 .................................................................................................. 265

6.1.1

节点架构 .................................................................................... 265

6.1.2

最高配置和可扩展性 .................................................................. 266

6.1.3

网络 ........................................................................................... 266

6.2

如何工作 ........................................................................................... 268

6.2.1

磁盘阵列卸载负载－VAAI ......................................................... 268

6.2.2

CVM Autopathing aka Ha.py..................................................... 268

6.3

管理 .................................................................................................. 269

6.3.1

重要页* ...................................................................................... 269

6.3.2

命令参考 .................................................................................... 269

6.3.3

指标和阈值 * .............................................................................. 271

6.3.4

故障排除和高级管理* ................................................................ 271
6

7

第七部分：Hyper-V ................................................................................. 271
7.1

架构 .................................................................................................. 271

7.1.1

节点架构 .................................................................................... 271

7.1.2

最高配置和可扩展性 .................................................................. 272

7.1.3

网络 ........................................................................................... 272

7.2

如何工作 ........................................................................................... 274

7.2.1
7.3

8

管理 .................................................................................................. 274

7.3.1

重要页* ...................................................................................... 274

7.3.2

命令参考 .................................................................................... 274

7.3.3

指标和阈值* ............................................................................... 276

7.3.4

故障排除和高级管理* ................................................................ 276

第八部分：Nutanix 集群 .......................................................................... 276
8.1

9磁盘阵列卸载负载－ODX .......................................................... 274

AWS 上的 Nutanix 群集 .................................................................... 276

8.1.1

已支持的配置 ............................................................................ 276

8.1.2

关键术语 / 结构 ......................................................................... 277

8.1.3

架构 ........................................................................................... 278

8.1.4

摆放策略 .................................................................................... 280

8.1.5

存储 ........................................................................................... 281

8.1.6

网络连接 .................................................................................... 282

8.1.7

主机网络连接 ............................................................................ 283

8.1.8

WAN / L3 网络 ........................................................................... 287

8.1.9

安全 ........................................................................................... 288

8.1.10

用法和配置 ................................................................................ 288

第九部分：存储服务 ................................................................................ 289
9.1

块服务 .............................................................................................. 289

9.2

文件服务 ........................................................................................... 296

9.3

对象存储服务 .................................................................................... 301
7

10

第十部分：网络服务 ............................................................................ 306

10.1

Flow（微分段） ................................................................................ 306

10.2

Epoch（网络监控/ DPI） ................................................................. 309

11

第十一部分：备份容灾服务 .................................................................. 309

11.1

Leap（策略驱动的灾难恢复/运行手册） .......................................... 309

11.2

Mine（备份解决方案） ..................................................................... 327

12

第十二部分：编排服务 ......................................................................... 327

12.1
13

Calm（编排/自动化） ....................................................................... 327
第十三部分：治理服务 ......................................................................... 328

13.1
14

Beam（成本治理/合规性） .............................................................. 328
第十四部分：场景 ................................................................................ 328

14.1

场景：安全分析平台 ......................................................................... 328

14.2

场景：多站点灾难恢复/复制 ............................................................. 328

15

第十五部分：集成 ................................................................................ 328

15.1

集成 .................................................................................................. 328

15.1.1
16

OpenStack ................................................................................ 328

后记 ...................................................................................................... 346

8

1

第一部分：历史回顾简要回顾一下基础设施的历史，了解我们今天所处的阶段。

1.1 数据中心的演变
数据中心在过去的几十年间已经发生翻天覆地的变化，下面我们将详细说明每一个阶段。

1.1.1 大型机的时代
大型机(MainFrame)在相当长的一段时间内作为数据中心核心业务系统的基础，使很多公司获得如下主要的特征：l系统本身就融合的 CPU、内存和存储l设计为内部冗余机制

但是大型机也带来了如下的问题：l

高昂的基础架构采购费用l

内在的复杂性l缺乏弹性，高度封闭的环境

1.1.2 转向独立的服务器
对于大部分的公司而言，其业务很难充分利用大型机的能力，在一定程度上导致了独立服务器的出现，其关键的特性包括：
l

CPU、内存和直连式存储 (DAS)l

比大型机更高灵活的系统环境

l可通过网络访问

但这些独立服务器模式仍然存在诸多问题：l

更多孤立环境l资源利用率低或不均l对于计算和存储而言，服务器成为单点故障（SPOF）

1.1.3 集中式存储

9

数据是业务获得持续盈利能力的重要一环。对于直连存储（DAS），企业既需要
更多的本地化存储空间，又需要数据的高可用，以保证服务器故障不会导致数据的不可用。
集中式存储替代了大型机和独立的服务器模式，提供可共享的、更大的存储资源
池，并具有数据的保护能力，集中式存储的主要特点包括：：l

池化的存储资源可以提高存储的利用率l

通过 RAID 的集中数据保护避免了服务器宕机引起的数据丢失l通过网络进行存储；

集中式存储依然存在如下的问题：l

成本高昂，但数据比硬件更有价值l更为复杂的系统（SAN 架构、WWPNs，RAID 组，卷，存储控制器等）

l

需要额外的管理工具和管理团队

1.1.4 虚拟化的出现与此同时，我们可以观察到，计算资源使用不充分，资源效率也低到让人无法容忍。
随后，虚拟化被引入，使多种工作负载和操作系统和 OS 以虚拟机(VM)的形式运行在
单一物理硬件之上。虚拟化增加了业务对于物理服务器的利用率，但也增加了竖井式环境和故障的影响范围。其核心特征有：l操作系统和物理硬件解耦合（VM）

l高效的计算使用率可以整合工作负载

早期的虚拟化存在一定的问题：l竖井式环境增多，管理复杂度增加l缺乏虚拟机的高可用，所以一旦计算节点失效影响范围变得更大l

池化资源的缺乏

l

需要单独的管理工具和管理团队。

1.1.5 虚拟化的成熟
成熟的虚拟化管理程序已成为高效且功能丰富的方案，随着 vMotion（热迁移）、
HA(高可用)和 DRS(分布式资源调度)等功能的出现，用户可以获得提供虚拟机高可用
性和动态迁移计算工作负载的能力。但仍有一个核心问题，就是对集中式存储的过度
依赖而导致的数据路径集中合并。这样随着虚拟机快速增长和存储阵列的负载提升会
导致严重的存储 IO 瓶颈。
关键的特性有：10l集群化计算资源池

l

在计算节点间具备动态迁移的能力（DRS/vMotion）

l

VM 具备高可用性，防止计算节点失效l集中化存储的要求

但存在以下问题：l

虚拟机的快速增长导致更高的存储需求l存储扩容需求导致更多竖井化环境和更高管理复杂度l由增加存储导致的更高单位存储容量成本l可能会导致阵列资源的争用l

存储配置更加复杂：üDatastore 内 VM 和 LUN 的配比ü

考虑存储控制器的数量满足 I/O 需求

1.1.6 固态硬盘(SSD)
SSD 可以无需借助更多的盘阵就可以实现很高的 I/O 性能，从而缓解 I/O 瓶颈。
然而，即使性能提高显著，控制器和网络还没有发展到能够处理如此大量 I/O 吞吐的能力。固态硬盘的关键特性有：l比传统 HDD 具备更好的性能l

基本上消除了寻址时间但固态硬盘也有问题：l瓶颈从磁盘上的存储 I/O 上升到了存储控制器和网络l竖井依然存在l阵列配置仍旧复杂

1.1.7 云的到来
云的概念是一个模糊的定义。简单地说就是一种可以消费和利用由他人提供的服
务的能力。随着云的引入，看待 IT、业务和最终用户的角度已经变化。
商业组织及 IT 消费者需要 IT 提供类似云的能力，如敏捷和快速实现价值。如果
无法满足，他们将直接采用公有云服务，而这可能会引发 IT 新问题：如数据安全。
云服务的核心理念:

11

自服务 / 按需消费
快速实现价值(TTV) /降低门槛•专注服务和 SLAo 围绕正常使用时间/高可靠/性能指标的合同保证•分级定价模式o 按实际使用量付费(一些服务免费)
•

o

云的分类
多数云的分类如下（从上层到下层）：•软件即服务(SaaS)任何软件/ 服务 通过简单的 url 地址接入和消费o 例如: Workday, Salesforce.com, Google 搜索等•
平台即服务(PaaS)o 开发和部署平台o 例如: Amazon Elastic Beanstalk / Relational Database Services(RDS), Google App Engine 等•
基础设施即服务(IaaS)o VMs/Containers/NFV 即服务
o 例如: Amazon EC2/ECS, Microsoft Azure, Google Compute Engine(GCE)等o

IT 焦点的转变
云向提出了非常有趣的 IT 两难选择。IT 可以拥抱它，或者寻求另一种选择。因为他们希望把数据放在内部，但同时拥有云的自服务和快捷的特性。这种转变促使 IT
更像一个对公司员工提供 IT 服务的服务提供商。

1.2 延迟的重要性下面给出特定 I/O 类型的不同延迟特性：项目延迟

L1 cache reference

0.5 nsBranch Mispredict

5 ns

L2 cache reference

7 ns

Mutex lock/unlock

25 ns

12

说明

14x L1 cache

Main memory reference

100 ns

20x L2 cache, 200x L1 cacheCompress 1KB with Zippy

3,000 ns

Sent 1KB over 1Gbps network

10,000 ns

0.01 ms

Read 4K randomly from SSD

150,000 ns

0.15 ms

Read 1MB sequentially from memory

250,000 ns

0.25 ms

Round trip within datacenter

500,000 ns

0.5 msRead 1MB sequentially from SSD

1,000,000 ns

1 ms, 4x memory

Disk seek

10,000,000 ns

10 ms, 20x datacenter round trip

Read 1MB sequentially from disk

20,000,000 ns

20 ms, 80x memory, 20x SSD

Send packet CA -> Netherlands ->CA

150,000,000
ns

150 ms(来源: Jeff Dean, https://gist.github.com/jboner/2841832)
上面的表格给出 CPU 访问它的缓存需要 0.5 纳秒到 7 纳秒不等（L1 vs L2），
对于内存，访问的时间为 100 纳秒，而一个固态硬盘的 4K 读则需要 150,000 纳秒，
即 0.15 毫秒。如果我们使用一个企业级固态硬盘（例如 Intel S3700 系列），这个设
备能力如下：lll

随机 I/O 性能：
ü

随机 4K 读可达 75000 IOPS

ü

随机 4K 写可达 36000 IOPS

序列化带宽：
ü

持续读可达 500 MB/sü持续写可达 460 MB/s延迟：ü读延迟 50 微秒

ü写延迟 65 微秒

1.2.1 带宽的考量13对于传统存储来说，有以下几种 I/O 媒介：l光纤通道 (Fiber Channel)
ül

4/8/16Gb 和 32Gb

以太网(包括 FCoE)ü

1/10Gb (40Gb Infiniband)等我们使用 Intel S3700 系列固态硬盘的 500 MB/s 读和 460 MB/s 写带宽作为计算
基础，参考如下公式：
numSSD = ROUNDUP((numConnections * connBW (in GB/s))/ ssdBW (R or W))
注释：固态硬盘数量四舍五入按照整块计算，也不考虑 CPU 处理所有 I/O 的损耗，假设 CPU 的处理能力也是无限的。

占满带宽所需的 SSD 数量

网络带宽
控制器连接

可用网络带宽

读 I/O

写 I/O

双 4Gb FC

8Gb == 1GB2

3

双 8Gb FC

16Gb == 2GB4

5

双 16Gb FC

32Gb == 4GB89

双 32Gb FC

64Gb == 8GB16

19

双 1Gb ETH

2Gb == 0.25GB

1

1

双 10Gb ETH

20Gb == 2.5GB

56

如上面的表格所示，如果想达到一块固态硬盘提供的 I/O 能力理论最大值，网络可能会成为瓶颈，不同的网络带宽对应到 1 块到 9 块固态硬盘的处理能力。

1.2.2 内存延迟的影响
典型内存的延迟在 100 纳秒左右(不同型号及品牌的内存延迟会不同)，我们可以依据下面公式计算：l

本地内存读取延迟= 100ns + [OS / hypervisor 开销]l网络内存读取延迟= 100ns + NW RTT latency + [2 x OS / hypervisor 开销]

14

如果我们假设一个典型的网络 RTT 为 0.5 毫秒(不同交换机延迟会不同)，即 500,000
纳秒,计算公式如下：l网络内存读取延迟= 100ns + 500,000ns + [2 x OS / hypervisor 负荷]

如果我们假设一个非常快速的网络，RTT 只有 10,000 纳秒：l网络内存读取延迟= 100ns + 10,000ns + [2 x OS / hypervisor 负荷]

这就意味着即使有一个理论上非常快速的网络，与本地内存访问相比，也会有超过
10,000%的开销，而对于一个比较慢的网络而言，这个延迟开销相比可能超过500,000%。
为了缓解延迟的开销，服务器端的缓存技术便应运而生了。

1.3 用户空间 vs 内核空间
在内核空间还是在用户空间处理内容的争论是一个经常被辩论的话题。在这里，
我将解释每一部分内容和他们各自的优点与缺点。
任何操作系统（OS）都有两个核心执行区域：•内核空间
o 操作系统中最有特权的部分o 处理调度，内存管理等
o 包含物理设备驱动程序并处理硬件交互•用户空间
o “其他的一切”
o 这是大多数应用程序和进程所在的地方
o 受保护的内存和执行这两个空间协同工作，以使操作系统运转，在继续讲述用户空间和内核空间之
前，我们来先定义一些关键组件：• 系统调用o 又名 内核调用（kernel call），通过中断（稍后会在后面描述）从内核
完成某个活动进程的请求• 上下文切换o 将执行从进程转移到内核，反之亦然例如，下面是一个简单的将输入写入磁盘的应用的用例，接下来会发生：
1. 应用程序想要将数据写入磁盘
2. 请求一个系统调用15

3. 上下文切换到内核
4. 内核复制数据5. 通过驱动程序执行写入磁盘
下面为交互过程示意图：

图.用户和内核空间交互示意其中一个比另一个好吗？实际上用户空间和内核空间各有优点和缺点：•用户空间o 非常灵活o 孤立的故障域（进程）o 可能效率低下§
上下文切换花费时间（〜1,000ns）•
内核空间
o 非常僵化o 较大故障域
o 可能更高效率§减少上下文切换1.3.1 轮询与中断
另一个核心部分是如何处理两者之间的交互。 有两种主要的交互类型：•轮询
o 不断“轮询”，例如 一直发出需求o 例子：鼠标，显示器刷新率等
16

o
o
•
o
o
o
o

需要持续的 CPU 处理，但延迟较低 （但是极大地减少延迟）
消除内核中断处理程序的开销§
删除上下文切换中断“对不起，我需要一个 foo 请求”
举例：举手请求资源
可能使“CPU 高效”，但要视场景而定。
通常会有更高的延迟

1.3.2 移动到用户空间/轮询
随着设备速度变得越来越快（例如 NVMe，Intel Optane，pMEM），内核和设备之间的交互已经成为瓶颈。 为了消除这些瓶颈，许多供应商通过轮询将内容从内
核移动到用户空间，以得到更好的结果。
英特尔存储性能开发套件（SPDK）和数据平面开发套件（DPDK）就是很好的
例子。 这些项目旨在最大限度地提高性能并尽可能减少延迟，并取得了巨大的成功。
这种转变包括两个关键的内容：（这种转变由两个核心改变组成）
1. 将设备驱动程序移动到用户空间（原先是内核空间）
2. 使用轮询方式（原先是中断方式）
与之前基于内核的设备驱动方式相比，这可以实现更高的性能，因为它消除了：•
代价高昂的系统调用和中断处理
•
数据副本
•
上下文切换
下面为用户空间中驱动程序与设备的交互示意图:17图.用户空间和轮询交互实际上，Nutanix 为其 AHV 产品（vhost-user-scsi）开发的一款软件实际上正在
被英特尔用于他们的 SPDK 项目。

1.4 Web-Scale
名词解释：Web Scale，一种全新的计算架构方式，面向基础架构和计算资源等，可以实现互联网规模的弹性扩展能力。
这部分将介绍一些 Web Scale 基础架构的核心概念，以及为什么我们要采用它。开
始介绍前，必须清楚的了解 Web Scale 不意味着你真的要扩展到像 Google、Facebook 或 Microsoft 等这种互联网规模。这种架构适用于任何扩展情况(从 3 节点
到上千节点)，并且会受益匪浅。
现有的挑战包括：l复杂，复杂，还是复杂l业务快速增长的需要l

对敏捷性的需求等

当讨论 Web Scale 架构时，有如下一些关键概念：
l

超融合

l

软件定义的智能化l分布式自治系统

l系统的递增性和线性扩展能力18

其他相关概念：l

基于 API 的自动化和丰富的分析能力l

作为核心租户的安全

l

自恢复能力

下面从技术视角来解释这些概念的意义。

1.4.1 超融合在业界，针对于超融合到底是什么有着很多不同的看法。这也是因为组件（虚拟化、网络等）范围的不同而产生的差异。但是，核心的概念是这样阐述：天然地（Natively）将两个或多个组件组合到一个独立的单元中。在这里，天然(Natively)是一个关键词。为了更加有效率，组件一定是天然地整合在一起，而不是简单地捆绑在
一起。对于 Nutanix，我们天然地将计算和存储融合到我们设备的单一节点中 。这就
真正意味着天然地将两个或多个组件融合在一个独立的、可容易扩展的单元中。
优势在于：
l独立单元的扩展

l

本地 I/O 处理l消除传统计算/存储的竖井式结构，将其融合在一起

1.4.2 软件定义的智能化软件定义的智能化是在通用的、商品化的硬件之上通过运行软件来实现核心的逻辑，而这些逻辑之前用专有的硬件编程方式实现(例如 ASIC/FPGA 等)。对于 Nutanix
而言，我们将传统的存储逻辑(例如 RAID，去重，压缩等)采用软件方式去实现，这些软件运行在标准的 x86 硬件上的 Nutanix 控制虚拟机 CVM(Controller Virtual
Machine)内。（注：Nutanix 支持 x86 和 IBM POWER 架构）那就真正意味着把关键处理逻辑从专有硬件中剥离，并在商用的硬件上进行软件操作。
好处在于：l

快速地版本迭代周期l消除了专有硬件的依赖l

利用通用商业硬件提高经济性l

使用期限内的投资保护

最后一点需要特别说明一下，投资保护是指旧的硬件可以运行最新的和最好的软
件。这意味着，在其贬值周期内的一部分硬件依然可以运行最新的软件，并且可以与新部署的设备具有相一致的特性。
19

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

将角色和职责分配给系统中的所有节点

l

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

当需要一个新的主数据节点时，采用选举机制优势：l消除单点故障 (SPOF)

l

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

1.4.4 递增性和线性扩展递增性和线性扩展是指现代化系统必须具有的两种能力，前者是指可以从一组小规模资源构建，后者是当指按需扩展的时候可以线性增加系统的性能。上面提到的所有结
构都是使得线性扩展成为可能的关键因素。例如，一个运行虚拟化负载的传统三层架构：服务器、存储和网络，所有这些组件都是独立扩展的。当扩展服务器数量时，却不能实现存储性能的横向扩展。但是像 Nutanix 的超融合平台，却可以同时随着节点
数的增加而同时扩展：l计算节点数量l

存储控制器的数量l计算和存储的性能及容量l

参与集群运行的节点数量

这就意味着：l

存储和计算节点的线性增加可以实现性能和容量的线性增长

优势在于：
l

从小规模开始扩展；l

在任何规模下获得一致性的性能增长

1.4.5 总结20

综上所述：l计算资源利用率的低效导致向虚拟化转移l高级特性，包括 vMotion、HA 和 DRS 等需要集中式存储l

VM 的快速增长不仅增加存储负载，而且增加存储资源争用，带来瓶颈l固态硬盘缓解了磁盘 I/O 问题，但依然不能解决网络和控制器带来的瓶颈

l跨网络的缓存或内存访问将面临巨大的开销，优势不再明显l阵列配置复杂性依然存在l

服务器端的缓存可降低阵列的负载和网络影响，但是必须引入新的组件l

本地化有利于降低传统网络传输数据（跨节点读）所面临的瓶颈和开销l

将焦点从复杂的基础架构转到管理的易用性和系统堆栈的简化l

Web Scale 的世界诞生了

21

2

第二部分：基础2.1 策略和愿景当我们在构思 Nutanix 这个公司时就认为，它应该专注于一个目标:

在任意位置让基础架构计算资源更为透明。
这种简单性将通过集中注意三个核心领域来实现:
1. 提高选择和可移植性(HCI/Cloud/Hypervisor)
2. 通过聚合、抽象和智能软件简化“栈”(Acropolis)
3. 通过关注用户体验(UX)和设计(Prism)，提供直观的用户界面(UI)

2.1.1 超融合/云/虚拟化:“选择”
尽管我们从支持单个虚拟化系统管理程序(ESXi)的单一硬件平台(NX)开始，但我们始终知道我们不仅仅是一个系统管理程序/平台/云公司。这是我们选择从头构建自
己的 UI 的原因之一，而不是在 vCenter 中作为插件运行，也不是在内核中作为 VM
运行(还有更多的原因)，等等。你可能会问为什么?选择。
没有一个虚拟化系统管理程序、平台或云可以满足所有客户的需求。通过支持同一平台下的多种解决方案，我们为客户提供了选择和影响力。通过赋予它们在它们之
间移动的能力，我们赋予了它们灵活性。所有交付与相同的经验，因为它都是Nutanix 平台的一部分。
我们现在支持超过 12 种不同的硬件平台(直接/OEM/第三方)、多个虚拟化管理程序(AHV、ESXi、Hyper-V 等)，并扩展与所有主要云供应商(AWS、Azure、GCP)的集成。这允许客户选择对他们最有利的方式，并将其用于供应商之间的协商。
注意:平台是一个关键字，在整个章节和一般情况下都会用到。我们不是在尝试打造一次性的产品，我们是在打造一个平台。

下面展示了 Nutanix 平台的高级架构:

22

图. Nutanix 平台-架构

2.1.2 Acropolis (AOS + AHV/虚拟化平台):“运行时”
我们通过一种称为分布式存储结构(DSF 当时被称为 Nutanix 分布式文件系统，即 NDFS)的特性简化了存储，将本地存储资源与智能软件结合起来，提供类似“集中式存储”的功能，从而开始构建我们的全新的系统。
多年来，我们添加了大量的特性和功能。为了简化问题，我将其分为两个核心领域:
1. 核心服务 -基础服务
2. 平台服务 - 以提供额外功能/服务的核心服务为基础的服务
核心提供基本的服务和组件，这些服务和组件有助于工作负载(vm /容器)和其他
更高级别的 Nutanix 服务的运行。一开始这只是 DSF 产品，但是我们继续扩展平台的功能来帮助简化和抽象堆栈。

23

下面是 AOS 核心平台的高层视图:

图. Nutanix 平台-Acropolis 核心

多年来，通过引入我们自己的虚拟化系统管理程序(AHV)、简化升级和提供安全性和加密等其他基本服务，这已经扩展到抽象虚拟化之类的东西(我们认为这应该是
透明的，并且是系统的一部分)。
有了这些功能，我们解决了许多基础设施级别的问题，但我们并没有止步于此。
人们仍然需要额外的服务，如文件共享、对象存储或容器。
而不是要求客户使用其他供应商和产品的一些服务，我们认为哪些我们应该合作，哪些我们应该建立自己的。在备份方面，我们与 Veeam 和 Hycu 等供应商合作。在文件和对象服务方面，我们将它们作为服务构建到平台中。
下面是 Nutanix 平台服务的高级视图:

图. Nutanix 平台– 服务

2.1.3 Prism“界面”
24

图. Nutanix 平台- Prism

简单地说，应用一些像苹果这样的公司所提倡的设计原则，它们注重简单、一致和直觉。从一开始，我们就在 Nutanix 产品的“前端”上投入了大量的时间和精力。
UI/UX 和设计团队并不是事后才想到的，而是一直在推动其发展。举个例子，我们是
第一批将管理界面用 HTML5 编写的企业软件公司(除了 SaaS 公司)之一。
这里的另一个核心项目是专注于为平台提供一个单一的接口，并在整个过程中保
持一致的体验。我们的目标是聚合 UI，就像融合基础设施一样。我们希望 Prism 成为一个单一接口，允许您管理和使用 Nutanix 平台，无论是管理数据中心中的虚拟化、云中的桌面即服务，还是提供开销可视性。
这对于我们继续通过功能/服务的创建和获取来扩展平台是很重要的。与其将新
功能捆绑在一起，我们宁愿花时间将它们原生地集成到平台中。这是一个较慢的过程，但从长远来看，它可以保持经验的一致性并降低风险。

2.1.4 Nutanix: 平台总而言之，我们的愿景很简单:“一个平台，任何应用，任何地点”。
注意:我从市场部的术语中借鉴了这句话，它非常适合并且简明扼要地说明了我们的目标。

25

图. Nutanix 平台- 架构从一开始，这就是我们的目标。这是我在 2014 年创建的一个关于 Nutanix 平台
架构的图片。正如你所看到的，没有太多的变化，我们只是继续扩大和朝着这个目标努力。

图. Nutanix 平台- Circa 2014

2.2 产品和平台
多年来，Nutanix 平台的能力和服务都有了很大的增长。多年来，它已经发展到
简化和抽象虚拟化、自动化升级和操作以及更多。本节将介绍当前的产品组合和伙伴关系。注:请参阅 Nutanix 网站的最新投资组合和产品。

26

多年来，随着产品系列的丰富，我们更专注于结果以及实现这些目标的过程，而不仅是谈论产品。 以下步骤涵盖了客户的“旅程”以及 Nutanix 可以帮助他们实现的结果。

2.2.1 第一步: 数据中心现代化(Core)
Core 包括基本的 Nutanix 产品，可促进从复杂的 3 层基础架构迁移到简单的HCI 平台。 AOS 提供所有核心服务（存储，升级，复制等），Prism 提供控制平面
和管理控制台，AHV 提供免费的虚拟化平台（注意：您也可以使用 ESXi，Hyper-V
和 XenServer）。
Core 功能包括：
•
•
•
•
•
•

核心平台(HCI)存储服务
虚拟化
集中管理与运营
升级复制 / DR

图. Products Ecosystem – Core2.2.2 第二步: 建设私有云(Essentials)

27

Essentials 专注于提供如私有云一样的消费 Core 基础架构的功能。 Flow 提供网络分段和安全性，Files 提供文件服务，Calm 提供自助服务，配额和编排功能。
基本功能包括：•高级分析和异常检测•

自动化与编排•自助服务门户（SSP）和配额

•

微分段

•

文件服务

图. Products Ecosystem - Private Cloud

2.2.3 第三部: 建设混合云(Enterprise)
Enterprise 专注于提供在云和云服务之间迁移工作负载的能力。 其中包括 Beam
等功能，这些功能侧重于跨云和本地部署的成本管理和合规性，以及 Frame（DaaS）和 Xi Leap（DRaaS）等其他云服务。
Enterprise 功能包括：•

策略驱动的灾难恢复/运行手册自动化

•

DRaaS

•

混合云成本治理和合规性•桌面即服务（DaaS）•

数据库即服务（DBaaS）•

Kubernetes / Docker 服务
28

•

对象存储

•

块服务

图. Products Ecosystem - Hybrid Cloud

2.2.4 平台
Nutanix 目前支持如下平台:
Nutanix 设备o NX (Supermicro)o HPE Powered DX• OEM 设备o Nutanix on Lenovo HXo Nutanix on IBM CS
o Nutanix on Dell XC• 第三方服务器支持o Nutanix on HPE ProLiant and Apolloo Nutanix on Cisco UCS
o Nutanix on Intel Data Center Blocks
o Nutanix Tactical and Ruggedized platforms on Klas•

2.3 超融合平台您可以观看以下讲解的视频: LINK
超融合系统有一些核心结构：29

•必须融合整合计算堆栈（例如，计算+存储）•必须在系统中的各个节点之间分布（分发）数据和服务•必须呈现和提供与集中存储相同的功能（例如，HA，实时迁移等）•

必须使数据尽可能靠近执行（计算）（Importance of Latency）•

不依赖于虚拟机管理程序•

不依赖于硬件下图显示了典型的三层堆栈与超融合的示例：

图. 3-Tier vs. HCI如您所见，超融合系统执行以下操作：•

虚拟化并将控制面移动到主机•

通过软件提供核心服务和逻辑•在系统中的所有节点之间分布（分片）数据•

将存储移动到计算本地

Nutanix 解决方案是一个融合了存储和计算资源于一体的解决方案。它利用本地组件
来为工作负载构建一个分布式的平台。

30

每个节点运行一个业界标准的 hypervisor（ESXi, AHV, Hyper-V 和 XenServer）和Nutanix 控制器虚拟机（CVM）。Nutanix CVM 中运行着 Nutanix 核心软件，服务于
主机上虚拟化层和虚拟机相关的所有 I/O 操作。
下图提供了一个例子，解释了典型的节点逻辑架构：

图 10-3. Converged Platform

Nutanix CVM 负责核心 Nutanix 平台逻辑，并处理以下服务：•存储 I / O 和转换（重复数据删除，压缩，EC）•

UI / API•升级•DR /复制•其他31注意：某些服务/功能将生成其他服务辅助 VM 或使用微服务平台（MSP）。 例如，
Nutanix Files 将部署其他 VM，而 Nutanix Objects 将为 MSP 部署 VM 并利用它们。
对于运行 VMware vSphere 的 Nutanix 节点，管理 SSD 和 HDD 设备的 SCSI 控制器
直接通过 VM-Direct 路径(Intel VT-d)传递给 CVM。在 Hyper-V 的情况下，存储设备通过 passed through 传递到 CVM。
虚拟化控制器在用户空间中将 Nutanix 控制器作为 VM 运行的关键原因实际上归结为两个核心领域：
1.流动性
2.弹性
3.维护/升级
4.性能，真的从一开始，我们就知道我们不仅仅是一家平台公司。从这个意义上讲，无论对于硬件，云还是虚拟机管理
程序供应商，选择对于我们来说一直都是一件大事。
通过在用户空间中作为 VM 运行，它将 Nutanix 软件与底层虚拟机管理程序和硬件平台分离。这使我们能
够快速添加对其他虚拟机管理程序的支持，同时在所有操作环境（本地和云）中保持核心代码库不变。此外，它为我们提供了不受限于特定于供应商的发布周期的灵活性。
由于在用户空间中作为 VM 运行的性质，我们可以优雅地处理诸如升级或 CVM“故障”之类的事务，因为它们不在虚拟机管理程序之内。例如，如果某个灾难性问题导致 CVM 崩溃，则整个节点仍将继续使用来自群集
中其他 CVM 的存储 I / O 和服务进行操作。在 AOS（Nutanix 核心软件）升级期间，我们可以重新启动CVM，而不会对该主机上运行的工作负载产生任何影响。
但是，进入内核不是快得多吗？简单的答案，不。
一个常见的讨论话题是围绕内核还是用户空间的争论。作为背景问题，我建议阅读“用户与内核空间”一节，其中涵盖了两者的实际含义和优点和缺点。
总而言之，操作系统（OS）有两个执行区域：内核（驱动程序可能位于操作系统的特权内核）和用户空间（应用程序/进程位于其中）。传统观点认为，就用户空间和内核（又称为上下文交换 context switches）之间的移动而言，在 CPU 和时间（〜1,000ns /上下文切换）方面开销高昂。
争论观点认为处于内核中总是更好/更快。事实并非如此。因为无论如何，在 guest VM 的 OS 中一定会
存在上下文交换 context switches。

32

2.4 分布式系统
分布式系统有三个核心构成:•必须没有单点故障(SPOF)•

在任何规模上都不能有任何瓶颈(必须是线性扩展的)•必须利用并发(MapReduce)

总之，一组 Nutanix 节点形成了一个分布式系统（Nutanix 集群），负责提供 Prism
和 Acropolis 功能。 所有服务和组件都分布在集群中的所有 CVM 中，以提供大规模
的高可用性和线性性能。
下图展示了这些 Nutanix 节点是如何形成一个 Nutanix 集群的:

图 .Nutanix 集群-分布式系统
这些技术也适用于元数据和数据。 通过确保元数据和数据分布在所有节点和所有磁
盘设备上，可以在正常的数据输入和重新保护期间保持最高的性能。
这使我们的 MapReduce 框架（Curator）能够充分利用集群的全部能力，并行执行操
作。 这些操作包括数据重新保护，压缩，纠删码，重复数据删除等。
下图显示了每个节点处理的工作负载如何随着集群的扩展而急剧下降的%：33

图 . 工作分配-集群扩展关键点:随着集群中节点数量的增加(集群扩展)，某些活动实际上变得更加高效，因为
每个节点只处理一部分工作。

2.5 软件定义软件定义系统有四个核心构成:•

必须提供平台移动性(硬件、Hypervisor)•

不能依赖任何特定硬件•

必须支持快速的开发速度(特性、bug 修复、安全补丁)•

必须利用摩尔定律

正如之前所提到的，Nutanix 平台是一个基于软件的而以软+硬件设备捆绑方式交付的解决方案。控制器虚拟机（CVM）中实现了 Nutanix 软件绝大多数功能与逻辑，从一开始就被设计成可扩展和可插入的体系架构。软件定义而非依赖于硬件卸载或构造的一个关键优势在于可扩展性。与任何产品生命周期一样，将始终引入改进和新特性。
由于不依赖于任何定制化的 ASIC/FPGA 或硬件功能，Nutanix 以软件更新的方式即可开发和部署新功能。这意味着可以通过软件升级来获得新功能（如：重复数据删除）。这也让那些老型号的设备可以支持新型号上推出的功能。比如说，你正在一款
老的机型上（例如：2400）运行着工作负载，而它没有提供数据去重的功能。你觉
得能从这项功能中大大受益，因此就在不中断业务的情况下进行在线升级。马上你就
有了这项数据去重的能力，如此简单而已。
就像增加新的软件功能，你也可以为 DSF 创建新的适配器或接口。当产品刚出厂时，它只从虚拟化层支持 I/O iSCSI，现在已经扩展到包括 NFS 和 SMB。将来我们34支持为不同工作负载和 hypervisor（HDFS 等）创建新的适配器。再次强调，所有这些都能通过软件升级就能实现。这跟传统架构的获得“最新最好功能”就一定要硬件更新或另外购买软件形成极大反差。Nutanix 把它变得不一样，由于所有功能都通过软
件部署，所以它能运行在任何硬件平台和任何 hypervisor，并通过软件升级实现新的部署。
下图是一个对于软件定义的控制框架的逻辑展现：图. 软件定义的控制器框架2.6 集群组件你可以通过观看下面视频来帮助理解： https://youtu.be/3v5RI_IbfV4
面向用户的 Nutanix 产品的部署和使用非常简单。 这主要是通过抽象和软件中的大量
自动化/集成来实现的。
以下是 Nutanix Cluster 主要组件的详细视图：35

图 . 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。

36

Curator•关键角色：以 Mapreduce 方式管理和清理集群•

描述：Curator 负责管理和分布整个集群中的任务，诸如磁盘容量平衡、主动清理等。Curator 运行在所有节点上，受控于主 Curator（其负责任务委托）。Curator 有两种扫描类型，每 6 小时一次全扫描和每 1 小时一次的部分扫描。

Prism
•

关键角色：用户界面和 API•

描述：Prism 是一个组件管理网关，它让管理员配置和监控 Nutanix 集群。它提供多种管理手段，如 Ncli、HTML5 UI 和 REST API。Prism 运行在集群中的每个节点，如同集群中其他组件一样也采用 leader 选举制。

Genesis•关键角色：集群组件和服务管理

•

描述：Genesis 是一个负责任何服务交互（启动/停止等）以及初始配置的进程，运行
在每个节点上。Genesis 是一个独立于群集运行的进程，不需要配置/运行群集。它唯
一的前提是 Zookeeper 必须正常启动和运行着。Cluster_init 和 cluster_status 这两个页面所显示的信息由 Genesis 进程提供。

Chronos•

关键角色：作业和任务调度•

描述：Chronos 负责从节点扫描和节点间调度/节流任务中获取作业和任务。Chronos运行在每个节点上，受控于主 Chronos（负责任务委托且和主 Curator 运行在同一节点）。

Cerebro•关键角色：数据复制和容灾管理•

描述：Cerebro 负责 DSF 中的数据复制和容灾管理部分，包含快照的调度、远程站点
的数据复制及站点的迁移和故障切换。Cerebro 运行在 Nutanix 集群的每个节点上，并且每个节点都参与远程站点/集群的数据复制。

Pithos•关键角色：vDisk 配置管理•

描述：Pithos 负责 vDisk（DSF 文件）的配置数据。Pithos 构建于 Cassandra 之上，并运行在每个节点。

2.7 不间断升级37

对于 AOS 升级，需要执行以下几个关键步骤：2.7.1 步骤 1 - 升级前检查
在升级前检查期间，将验证以下各项。注意：必须先成功完成此操作，然后才能继续升级。
• 检查 AOS，Hypervisor 版本之间的版本兼容性•检查集群健康状况（集群状态，可用空间和组件检查（例如，Medusa，Stargate，Zookeeper 等）•

检查所有 CVM 和 Hypervisors 之间的网络连接2.7.2 步骤 2- 将升级软件上传到 2 节点
完成升级前检查后，系统会将升级软件二进制文件上载到群集中的两个节点。这样做
是为了容错，并确保一个 CVM 正在重新启动，另一个 CVM 可供其他人从中提取软件。

2.7.3 步骤 3 - 阶段升级软件
将软件上载到两个 CVM 后，所有 CVM 将并行进行升级。
CVM 具有两个用于 AOS 版本的分区：•
活动分区（当前正在运行的版本）•
被动分区（进行升级的分区）
发生 AOS 升级时，我们将在非活动分区上执行升级。收到升级令牌后，它将升级后的分区标记为活动分区，并将 CVM 重新引导至升级后版本中。这类似于 bootbank /altbootbank。
注意：升级令牌在节点之间迭代传递。这样可确保一次仅重启一个 CVM。一旦 CVM
重新启动并稳定（检查服务状态和通信），令牌就可以传递到下一个 CVM，直到所
有 CVM 都已升级。

升级错误处理一个常见的问题是，如果升级不成功或在升级过程中部分出现问题，该怎么办？
如果发生某些升级问题，我们将暂停升级而不继续进行。注意：这种情况很少发生，因为升级前检查会在升级实际开始之前发现大多数问题。但是，如果升级前

38检查成功并且在实际升级过程中发生了某些问题，则不会对集群上运行的工作负载
和用户 I / O 产生影响。

Nutanix 软件旨在在支持的升级版本之间以混合模式无限期地工作。例如，如果群集正在运行 xyfoo 并正在升级到 xybar，则系统可以在两个版本的 CVM 上无限期运行。这实际上是在升级过程中发生的情况。
例如，如果您在 xyfoo 上有一个 4 节点群集，并开始升级到 xybar，则当第一个节
点升级时，它将运行 xybar，而其他节点则在 xyfoo 上。此过程将继续，并且 CVM
在收到升级令牌后将重新启动到 xybar 中。

2.8 Foundation（镜像）2.8.1 架构Foundation 是 Nutanix 提供的系统工具，用于引导，安装镜像和部署 Nutanix 集群。
镜像过程会安装所需版本的 AOS 软件和所选的 Hypervisor 软件。
默认情况下，Nutanix 节点出厂会预装 AHV 虚拟化平台，如果需要不同的 Hypervisor
平台，你必须用 Foundation 软件重新对所有节点采用所需的 Hypervisor 进行重新镜
像操作。注意：某些 OEM 方式会从工厂直接安装发运所需的 Hypervisor 软件。
下图展现的是 Foundation 的架构的高级视图：

图. Foundation-架构从 4.5 版本起，为了简化配置，CVM 里面就内嵌了 Foundation。Installer store 是用
来存放上传的镜像文件的目录，这些镜像可用于初始化部署时，也用于集群扩展时。

39

Foundation Applet 发现小程序(可以在此链接获取)负责发现节点，并且允许用户连接到某个选定的节点。一旦用户选定了连接某个节点，小程序将本地主机端口：9442
代理到 CVM 的本地连接的 IPv6 地址端口：8000。
下图展示了 Applet 架构的高级视图

图.Foundation-小程序架构
注意：发现小程序仅仅是发现和代理运行在所有节点上的 Foundation 服务的一种方式。所有镜像和配置工作都由 Foundation 服务来完成，而不是小程序本身。
高级技巧：

如果你位于和目标的 Nutanix 节点（比如跨广域网）不同的网络（L2），而 CVM
已经配置了 IPv4 地址，你可以直接连接到 CVM 的 Foundation 服务（而不是用发现小程序）。
直接将浏览器连接到：<CVM_IP>:8000/gui/index.html 来访问

2.8.2 输入项Foundation 工具配置时需要输入如下信息。典型的部署每个节点需要 3 个 IP 地址
（hypervisor, CVM，远程管理，如 IPMI，iDRAC 等）。除了每个节点的 IP 地址，
建议设置一个集群和数据服务的 IP 地址。
l

集群
o

名字

o

IP *

o

NTP *

o

DNS *

40

CVM

l
o

CVM 的 IP

o

掩码

o

网关

o

内存

HypervisorloHypervisor 主机 IP

o

掩码

o

网关

o

DNS*

o

主机名前缀

IPMI *

l
o

节点 IP

o

掩码

o

网关

注意：'*'号项是可选项，但是强烈建议进行配置

2.8.3 系统镜像和部署第一步就是通过发现小程序（discovery applet）连到 Foundation 的用户接口(如果是
相同的二层网络，则无需节点 IP 地址)图.Foundatioon-发现小程序（Discovery Applet）
如果无法发现所需的节点，请确认是否位于相同的二层网络中。
当连接到被选定的节点的 Foundation 实例，Foundation 主用户界面就会显示出来41

图. Foundation-发现页面
下面展示的是所有发现的节点和他们所在的机箱（Chassis）。选择所需的节点组成
集群，点击“Next”

图.Foundation-节点选择
下一个页面提示集群和网络输入:42

图.Foudation-集群信息

图.Foundation-网络信息
当信息输入完成，点击“Next”
下一步我们输入节点的详细信息和 IP 地址：43图. Foundation-节点安装
如果需要，可以手动的忽略主机名和 IP 地址图. Foudation-主机名和 IP
点击“Validate Network”验证网络配置并继续进行.这一步检查 IP 地址冲突确保连接正常44图. Foundation-网络验证当网络验证成功结束，我们现在就可以继续选择所需的镜像。
为了把 CVM 上的 Acropolis 升级到一个更新的版本，需要从门户上下载 Acropolis 并
上传打包文件。当我们有了 AOS 镜像，下一步就是选择 Hypervisor
对于 AHV 来讲，它内置在 Acropolis 的镜像中。对于其它的 Hypervisor 则需要上传对应的镜像文件。
注意：必须确保 AOS 和 Hypervisor 的版本在兼容列表里面（连接地址）。
当我们有了所需的镜像之后，点击“Create”:

图.Foundation-选择镜像
如果不需要重新安装镜像你可以点击'Skip'来跳过镜像安装过程。这样就不会重新部
署 Hypervisor 镜像或者 Nutanix 集群的镜像，仅仅对集群配置（如：IP 地址等）。
Foundation 将进行镜像安装（需要的情况下）和集群构建过程。

45

图.Foundation-集群构建过程
当集群构建成功完成你将看到完成的界面：

图. Foundation-集群构建完成

2.9 磁盘驱动器解构这一章节，我们将涉及到各种存储设备（SSD/HDD）如何在 Nutanix 平台被解构，
分区和使用。注：所有容量单位是二进制字节(GiB)而不是十进制字节(GB)，同时把驱动器格式化的文件系统和相关的消耗也一并考虑在内。

性能设备

46

性能设备是节点中性能最高的设备。 这些可以是 NVMe 或 NVMe 和 SSD 设备的混合。 它们存储了一些关键项目，有更详细的说明：l

Nutanix 主目录（CVM 核心）lCassandra （元数据 存储）lOpLog （持久写缓冲）l内容缓存 （SSD 缓存）l扩展存储 （持久存储）

下图示例了一个 Nutanix 节点的性能设备的存储分析：

图. SSD 驱动分解上图中，图形和份额不是按比例绘制的。当评估剩余 GiB 容量时，采用自顶而下的方法。例如，用于 OpLog 计算的剩余容量( GiB) 应该是 SSD 被格式化后的容量减去
Nutanix Home 和 Cassandra 占用的容量。
Nutanix Home 文件在前两个 SSD 镜像存储以保证高可靠，并预留 60GiB 空间给元数据。
5.0 版本中 Cassandra 是分片在不同节点的 SSD 中的（目前最多 4 个），每个 SSD
预留 15GiB 的容量（如果元数据使用增加，可以利用部分 Stargate 的 SSD）。在双SSD 系统，元数据会在 SSD 间镜像。每个 SSD 预留 15GiB（双 SSD 时 30GiB，4
个 SSD 时 60GiB）给元数据。
在 5.0 之前， Cassandra 默认在第一个 SSD，如果 SSD 故障 CVM 将重启，Cassandra 存储于第二个 SSD。此时，对于前两个磁盘，每个 SSD 的元数据预留是30GiB。
47

OpLog 分布在所有 SSD 设备里，每个节点最多 12 个 SSD (Gflag:
max_ssds_for_oplog)。如果 NVMe 设备可用，OpLog 将被放置在这些设备上，而不
是 SATA SSD。
可以使用以下公式计算每个磁盘的 OpLog 预留：MIN((Max cluster RF/2)*400 GiB)/
numDevForOplog)， ((Max cluster RF/2)*25%) x 剩余 GiB)。注意:从版本 4.0.1 开
始，OpLog 的大小调整是动态进行的，这将允许 extent store 存储部分动态增长。使用的值假定完全使用了 OpLog。
例如，如果 RF2 (FT1)集群中有 8 个 1TB 的 SSD 设备，结果将是:•MIN(((2/2)*400 GiB)/ 8), ((2/2)*25%) x ~900GiB) == MIN(50, 225) == 50 GiB ，每个设备预留 50 GiB 给 OpLog。

对于 RF3 (FT2)集群，这将是:•MIN(((3/2)*400 GiB)/ 8), ((3/2)*25%) x ~900GiB) == MIN(75, 337) == 75 GiB ，每个设备预留 75 GiB 给 OpLog。

如果 RF2 (FT1)集群有 4 个 NVMe 和 8 个 1TB 的 SSD 设备，结果会是:•MIN(((2/2)*400 GiB)/ 4), ((2/2)*25%) x ~900GiB) == MIN(100, 225) == 100
GiB ，每个设备预留 100 GiB 给 OpLog。

Extent Store 容量将是考虑所有其他预订之后的剩余容量。

HDD 设备
由于 HDD 设备主要作用于大容量存储，解构起来相对简单：lCurator 保留（Curator 存储）l扩展存储（持久存储）

48图. HDD 驱动解析3

第三部分：Prism

名词解释：Prism，控制面板，为数据中心运营提供一键式管理和操作界面。

3.1 设计方法
建设一个美观的、易于使用且直观的产品是 Nutanix 平台设计的核心思想，这一个章节将介绍我们的设计方法以及如何进行迭代。
（省略部分确认）3.2 架构
Prism 是一个分布式的资源管理平台，允许用户跨 Nutanix 集群环境管理和监控对象
及服务，无论它们是在本地还是云端。这些能力被分为两种类别：
l

接口能力
ü

l

HTML5 UI, REST API, CLI, PowerShell CMDlets 等

管理能力
ü

平台管理，虚拟机/容器的增删查改，策略定义与合规，服务设计与状态，分析和监控下图重点解释了作为 Nutanix 平台一部分的 Prism 概念特征：49

图. Prism 的概要架构Prism 主要由两个组件构成：lPrism Central (PC)ü

多集群管理器，负责管理多个 Acropolis 集群，以提供单一的、集中的管理界面。Prism Central 是一个可选的软件设备（虚拟机），可以部署在 Acropolis
集群内或集群外部ül

一对多的集群管理

Prism Element (PE)ü

本地集群管理者，负责本地集群的管理和运行，每个 Acropolis 集群都有自己
内置的 Prism Elementü

一对一的集群管理下图指出在 Prism Central 和 Prism Element 之间的逻辑关系：

50

图.Prism 架构提示：对于大规模或者分布式部署（例如多个集群或多个站点），建议使用 Prism Central 来简化管理操作，为所有
集群/站点提供单个管理界面。

3.2.1 Prism 的服务
Prism 服务运行在每一个 CVM 之上，其中一个 CVM 上的 Prism 服务会被选为 Prism Leader
组件，负责处理集群的 HTTP 请求。与其他的组件有 Master 类似，如果一个 Prism Leader
出问题，一个新的 Leader 会被选出。当不是 Prism Leader 的 CVM 得到 HTTP 的请求，它
将永远重定向请求到当前的 Prism Leader，并且返回 HTTP 应答码 301。下图是解释 Prism
服务是如何处理 HTTP 请求：

51

图.Prism 服务处理 HTTP 请求
Prism 端口：Prism 监听 80 和 9440 端口，如果 HTTP 流量来自于 80 端口，它将会被重定向到 9440 端口。
如果我们使用集群外部 IP（推荐），它将一直被当前的 Prism Leader 所有。即使 Prism
Leader 出问题，集群 IP 也会转移到新选举出的 Prism Leader 上。 一个 gratuitous ARP（gARP）将被用来清理旧的 ARP 缓存条目。在上面的场景中，任何时候集群 IP 都可以被用
来访问 Prism，而无需重定向需要，因为 Prism Leader 已经被选出。
专家提示：可以在任一个 CVM 里面使用命令将其设定为当前的 Prism Leader，请运行：“curllocalhost:2019/prism/leader”

3.2.2 认证和访问控制认证Prism 当前支持如下认证方式：
Prism Element (PE)
Local
Active Directory
LDAP• Prism Central (PC)o Localo Active Directoryo LDAP
SAML Authn (IDP)
•

o
o
o

SAML / 2FA

52

SAML Authn 允许 Prism 集成哪些遵从 SAML 标准的外部认证提供者(IDP) (例如. Okta, ADFS, 等).
同时也可以允许你采用多因素认证（MFA）或双因素认证（2FA）用于用户登陆 Prism 的安全保证。

访问控制
敬请期待！

3.3 管理导航Prism 提供相当直观和简单的使用方式，然而我们将介绍一些主要的页面和基本用法。
Prism Central(如果部署)可以使用指定的 IP 地址或相应的 DNS 条目，而 Prism
Element 可以通过 Prism Central 点击相应集群条目导航到，或者通过任意 Nutanix
CVM 或集群 IP（首选）来访问。一旦页面被加载将登陆到 Prism 欢迎界面，可以使用 Prism 账户或 AD 凭证登陆。

图.Prism 登陆页面
成功登录后，您将被导航到控制界面页面，该页面将提供 Prism Central 中托管集群的概述信息，或者是 PrismElement 中的本地集群。
在后面的章节中，我们会详细介绍 Pirsm Central 和 Prism Element 的更多细节。

3.3.1 Prism Central
下图显示出 Prism Central 的仪表盘。在这里我们可以监控和管理多个集群：53

图.Prism Central 仪表盘
在仪表盘上可以监控到所有的环境状态，如果有任何告警或选项，可以深入查看。
Prism Central 包括如下主要页面（注意：比较建议采用搜索的方式来定位到所需的
组件）：
l

主页面
o

整体环境的监控仪表盘，包括服务状态、容量计划、性能、任务等详细信息，为了获得更多信息，可以点击每一个条目

l

虚拟架构
o

l

虚拟化条目（例如：虚机，容器，镜像，目录，等等）
策略o

策略管理和创建（例如：安全策略（FLOW），数据保护策略（备份/复制），恢复策略（容灾），虚机工具策略（NGT）等）

l

硬件
o

l

物理设备管理（例如：集群，主机，磁盘，GPU）
活动ol

整个环境的告警、事件和任务
操作ol

操作面板、报告和动作（X-Play）
管理o环境组织管理（例如：用户，组，角色，可用域等）

54

l

服务
o

l

附加服务管理（例如 Calm、Karbon）
设置oPrism Central 的配置

访问这个菜单可以点击这个三层的图标：

图.Prism Central 菜单图标菜单会展开显示为下面的可用选项。

55

图.Prism Central 菜单列表3.3.2 搜索搜索目前是一个 Prism Central 图形界面的主要导航机制（菜单同样有效）。
可以在顶端左边靠近菜单图标的搜素栏中搜素导航到你想访问的组件。

图.Prism Central 搜索栏56搜索语法的示例
Prism Central 的搜索工具允许通过很多语法组合来丰富搜索能力，示例如下：

Rule

ExampleEntity type

vms

Entity type + metric perspective (io, cpu,
memory)vms ioEntity type + alerts

vm alerts

Entity type + alerts + alert filtersvm alerts severity=critical

Entity type + events

vm events

Entity type + events + event filtersvm events classification=anomaly

Entity type + filters (both metric and attribute)vm “power state”=on

Entity type + filters + metric perspective (io,cpu, memory)

vm “power state”=on io

Entity type + filters + alerts

vm “power state”=on alerts

Entity type + filters + alerts + (alert filters)

vm “power state”=on alerts severity=critical

Entity type + filters + events

vm “power state”=on events

Entity type + filters + events + event filters

vm “power state”=on events
classification=anomaly

Entity instance (name, ip address, disk serialetc)

vm1, 10.1.3.4, BHTXSPWRM

Entity instance + Metric perspective (io, cpu,
memory)vm1 ioEntity instance + alerts

vm1 alerts

Entity instance + alerts + alert filters

vm1 alerts severity=critical

Entity instance + events

vm1 events

57

Entity instance + events + event filters

vm1 events classification=anomaly

Entity instance + pages

vm1 nics, c1 capacity

Parent instance + entity typec1 vmsAlert title search

Disk bad alerts

Page name search

Analysis, tasks

以上的示例只是一部分语法，最好的熟悉方式就是去尝试下。

3.3.3 Prism Element
Prism Element 包括如下主要页面：
l

主页面
o

本地集群监控仪表盘，包括了告警、容量、性能、健康度、任务等详细信息，可以点击具体条目获得更多的信息

l

健康
o

l

环境、硬件及被管理对象的健康及状态信息，也包括 NCC 健康检查信息
虚拟机o实现全面的虚拟机管理、监控及创建、运行、更新和删除等功能o

虚拟机监控（非 Acroplis Hypervisor）

l

存储
o

l

容器管理、监控及创建、运行、更新和删除等功能
硬件ol

服务器、磁盘和网络管理、监控和健康检查，也涵盖了集群的扩展。
数据保护o

容灾、公有云对接和同城 Metro Availability 的配置，管理保护域的对象、快照、
复制和恢复

l

分析
o

l

具有事件关联性的集群及管理对象的详细性能分析告警o

本地集群和环境的告警58

主页面将提供详细的告警、服务状态、容量、性能及任务等信息，可以点击任意条目
获取更多的信息。下图展现了一个 Prism Element 管理下的本地集群仪表盘：图.Prism Element 仪表盘

3.3.4 快捷键
快速接入在 Prism 里面至关重要，为了简化用户的使用允许用户使用键盘的快捷键来访问不同的视图和内容：切换视图：lO – 概览视图l

D – 图标视图

l

T – 表格视图活动和事件lA – Alertsl

P – Tasks下拉导航和菜单l

M – 菜单选项l

S – 设置选项

lF – 搜索条目

lU – 用户条目l

H – 帮助3.4 特性和使用59

在下面内容中，我们将介绍一些典型的 Prism 应用程序以及一些常见的故障排除场
景。

3.4.1 异常检测
目前，在 IT 的日常操作中会有很多干扰因素。传统的系统上会产生大量的告警，事件和通知。经常会导致操作者a) 迷失在大量的干扰信息，而错过严重的告警b) 丢弃告警和事件信息通过 Nutanix 的异常检测能力，系统会监视各种基于时间序列的数据（例如：CPU 的使用，内存的使用，延迟等）并建立一个期望的值的范围。只有命中范围之
外才会触发告警和事件。你可以从任意的入口和事件页看到异常事件。
后面的图表展示的是许多 I/O 和磁盘使用的异常，比较常见于在系统中执行大量的批处理任务的情况。

图. Prism – 异常图表后图展示了一个样本度量的时间序列值的带宽图。

60

图. Prism – 异常吞吐这减少了不必要的警报，因为我们不希望系统经常在正常状态告警。例如，由于缓存等原因，数据库系统通常在>95%的内存利用率下运行。如果这个数字下降到
10%，那就是异常，可能出了什么问题(比如数据库服务宕机)。
另一个例子在周末运行的批处理的工作负载。例如，平常 I/O 带宽可能在工作周期间很低，但是在周末一些批处理进程(例如备份、报告等)运行时，I/O 可能会出现很大的峰值。我们的系统将检测到这种周期性，并在周末提高带宽标准。在这里你可以看到一个异常事件发生了，因为值超出了预期的范围:图.Prism – 异常事件61另一个有趣的异常的情况是季节性。例如，在假日期间，零售商的需求将高于一
年中的其他时间，或在月末关闭期间。
异常检测解释了这种季节性，并利用以下时间段来比较微观(每日)和宏观(季度)
趋势：
l

每日

l

每周

l

每月

您还可以设置自己的自定义警报或静态阈值：图. 异常自定义事件异常检测算法Nutanix 利用一种确定频段的方法称为“通用极端故意偏差测试”。简单理解类似于置信区间，该区间的
值介于算法确定的上下限之间。

该算法需要 3 种颗粒度（例如每天，每周，每月等）来计算季节性和预期范围。 例如，为了适应每个季节，将需要以下数据量：•每天：3 天•每周：3 周（21 天）•每月：3 个月（90 天）

62Twitter 拥有有关如何利用此资源的良好资源，这在逻辑上有更详细的介绍：LINK

3.4.2 Nutanix 软件升级执行 Nutanix 软件升级是一个非常简单且无需中断业务的过程。
在登录到 Prism 以后点击界面右上角的齿轮图标，或者快捷键 S 选择“升级软件”：

图.设置更新软启动“更新软件”对话框，然后显示出当前的软件版本，是否有新的版本更新，也可以手动上载 NOS 文件更新软件版本。如下图所示，可以从外部云环境下载更新版
本，也可以手动上传新版本软件：63

图：更新软件主界面从 CVM 更新软件

在一些特定场景下，你可能想手动下载软件并上载到 CVM 里。我一般在自己的环境中一般采用这种模式。
首先通过 SSH 的方式链接到任意 CVM 并找到 Prism Leader。
curl localhost:2019/prism/leader && echo
再通过 SSH 连接到 Prism leader 下载软件包和元数据的 JSON 文件。
运行下面的命令 "加载" 软件到 Prism:
ncli software upload file-path=<PATH_TO_SOFTWARE> meta-file-path=<PATH_TO_METADATA_JSON>software-type=<SOFTWARE_TYPE>
下面是一个完整的示例：
ncli software upload file-path=/home/nutanix/tmp/master-prism_central.tar meta-filepath=/home/nutanix/tmp/master-prism_central-metadata.json software-type=prism_central_deploy

如果点击上传，则将更新软件上传到 Nutanix CVM 中：图.更新软件上传在软件上传完成后点击”Upgrade”按钮，启动更新流程：图.升级软件——启动升级
再次确认是否要更新软件：64

图. 升级软件——更新确认
更新过程启动后进行更新检查，然后自动更新软件：

图. 升级软件-执行中
一旦更新过程完成，将看到更新状态，随后即刻可以访问新的功能：图. 软件升级——完成

65

提示：
当 Prism Leader 升级时，Prism 会话会出现暂时中断，但所有的虚拟机和服务运行不受影响。

3.4.3 Hypervisor 升级类似 Nutanix 软件升级，Hypervisor 的升级也能通过 Prism 采用完全自动化方式，其升级步骤与之前类似，运行弹出“Upgrade Software”对话框，然后选择”Hypervisor”。
Hypervisor 升级可以选择从云端自动下载软件，也可以手动上传新的软件版本。

图. 升级 Hypervisor — 主菜单它将加载升级软件到虚拟化层，一旦新版本软件被成功加载，点击“Upgrade”按钮开
始升级过程。
66

图. 升级 Hypervisor — 开始升级过程选择再次确认 Hypervisor 升级，点击“Upgrade”。

图. 升级 Hypervisor — 确认升级系统将自动进行升级前的检查，然后上传 Hypervisor 进行整个集群的升级工作。

图. 升级 Hypervisor — 预检查过程
一旦升级前检查完成，虚拟化层升级将以进度条形式开始进行：67

图. 升级 Hypervisor — 升级执行类似于 Nutanix 软件滚动升级的特性，集群的每个主机都会依次序在运行虚拟机不受影响的情况下完成升级工作。当主机 Hypervisor 升级的时候，上面虚拟机会被自动
在线迁移到其他节点上；在 Hypervisor 升级过程中，主机会被自动重启。这个过程会依次序进行，直到集群内所有节点都被升级完成。
提示：可以通过 Nutanix CVM 运行命令“host_upgrade --status”查看集群升级的状态，也可以通过查看 CVM 的日志“/data/logs/host_upgrade.out ”获取集群状态信息。

一旦升级完成，可以看见更新后的状态，立刻可以访问新的功能。

68

图. 升级 Hypervisor — 升级完成

3.4.4 集群扩展(增加节点)
Acropolis 集群动态扩展能力是核心的功能。要扩展 Acroplis 集群，可以将节点上架、摆放和插线，然后启动节点。一旦节点被启动后，其会以 mDNS 方式自动被当
前集群发现。
下图展现了一个 7 节点的集群，动态发现 1 个新节点的加入。

图. 动态发现节点69

多个节点可以被发现并被同时加入到集群中。一旦节点被发现，可以点击 Hardware
主页面右上角的“Expand Cluster”开始延伸这个集群。

图. Hardware 页面中的 Expand Cluster
也可以在任意页面通过点击页面顶端右上角的齿轮图标，并找到 Expand Cluster。

图. 齿轮图标下的 Expand Cluster
点开 Expand Cluster 菜单，可以选择要增到集群内的节点和指定相应的 IP 地
址。

70

图. Expand Cluster—主机选择
在主机被选中后，将会被提示上传 Hypervisor 镜像，用来安装新添加的节点。
对于 AHV 或者镜像已经存在于 Foundation 安装文件夹，则没有上传的必要。

71图. Expand Cluster—主机配置
在镜像上传完成后，可以点击 Expand Cluster 启动镜像安装和集群扩展任务。

72

图. Expand Cluster—执行执行任务将被提交，在任务栏将显示任务执行的情况。

图. Expand Cluster—执行
任务执行状态可以在扩展任务状态栏里查看。

73

图. Expand Cluster—执行
在镜像安装和添加节点的过程完成后，可以看到更新后的集群内节点数量和资源情况。

74图. Expand Cluster—执行

3.4.5 I/O 度量识别瓶颈是性能故障诊断过程中的一个关键部分。
为了辅助这一过程，Nutanix 已经在“虚拟机”页面引入了一个新的 I/O 指标部分。
延迟取决于多个变量。（队列深度，I/O 规模，系统条件，网络速度等）
本页面旨在提供对 I/O 规模、延迟、资源和模式的分析。
要使用这部分，请转到“虚拟机”页面，并从表中选择所需的虚拟机。在这里我们可以看到宏观的使用度量：

图. 虚拟机页面-细节

在这部分表格下面可以找到“I/O 度量”选项卡

75图：虚拟机页面——I/O度量项选择“I/O 度量”选项卡后，将显示详细视图。我们将详细分析这一页，以及如何在这
一节中使用它。
第一个视图是“平均 I/O 延迟”部分，它显示了过去三小时的平均读/写延迟。
默认情况下，最新报告的值将及时与下面对应的详细度量值一起显示出来。
也可以使用鼠标在表上移动来查看历史延迟值，并点击击图表的某一特定时间，在下方显示详细度量值图. I/O度量-延迟标图这在出现急剧的峰值负载时是很有帮助的。如果你看到一个尖峰并想进一步调查，点击尖峰并评估下面的细节

图. I/O度量-延迟标图

如果延迟都在接受范围内，就不需要进一步挖掘了。
下一部分显示为读/写 I/O 规模的直方图：

图. I/O度量-I/O规模直方图

76

在这里可以看到读 I/O 范围从 4K 到 32K 大小：

图. I/O度量-读I/O规模直方图

在这里可以看到写 I / O 范围从 16K 到 64K，以及一些到 512K 大小：

图. I/O度量-写I/O规模直方图专家提示

如果看到延迟出现一个尖峰，首先要检查的是 I/O 大小。较大的 I / O（64K 到 1MB）通常比小的 I / O 有更高
的延迟（4K 到 32K）。

下一节显示为读写 I/O 延迟的直方图图. I/O度量-延迟直方图通过看读延迟直方图中我们可以看到大多数读 I/O 在亚毫秒级别（小于 1ms），部分
是 2-5 毫秒。

图. I/O度量-读延迟直方图77

看看下面的“读I/O的源头”，可以看到大部分的I/O操作都是从SSD层提供的图. I/O度量-读的源头SSD

当数据被读取时，它将被实时获取到统一的高速缓存中（DRAM+SSD）（查看“I/O路径和缓存”章节以了解更多信息）。
在这里，我们可以看到数据已被放到缓存中，现在正在从DRAM提供服务

图. I/O度量-读的源头DRAM

现在可以看到，基本上我们所有的读I/O都是亚毫秒级 MS延迟（＜1ms）

图. I/O度量-读延迟直方图

在这里可以看到，大多数的写I / O是小于1-2毫秒的：78

图. I/O度量-写延迟直方图专家提示
如果看到读延迟出现了一个尖峰，并且I/O规模不大，请检查正在读取的I/O的位置
来自硬盘的任何初次读取会比DRAM缓存有更长的延迟/等待时间然而，一旦在缓存中，所有后续读取都将命中DRAM，在延迟方面可以看到改进。

最后这部分显示I/O类型与随机读写和顺序读写比例：

图. I/O度量-随机读写 vs. 持续读写

通常，I/O模式随着应用程序或工作负载而变化（如VDI主要是随机/IO，而Hadoop将
主要顺序I/O）。其他工作负载将是两者的混合。例如，数据库在插入或一些查询操
作时是随机I/O，而在数据抽取过程中是持续I/O。

3.4.6 容量规划查看详细的容量规划细节，可以通过在 Prism Central 的“cluster runway”中点击特定
的集群来查看容量规划的具体信息。

79

图. Prism Central - 容量规划这张视图提供了关于集群使用趋势的具体信息，并确定了最吃紧的资源情况（限制资源）。你也可以从中了解到占用资源最多的那些虚拟机，并得到可能的选项。譬如一
些释放资源的建议或扩展集群的节点类型推荐。

80

图. Prism Central – 容量规划 – 推荐建议

3.4.7 X-Play当我们考虑自己的日常活动时，显然是实现越多的自动化越好。 我们在日常生活中
经常使用常规程序，而科技使我们能够在其他领域也做到这一点。 Prism Pro X-Play
允许我们通过 Prism 自动化一组常见的运维活动。 但是，在深入研究产品之前，让我们先介绍一下我们要做的事情。
事件以下列方式驱动的自动化工作：事件→ 逻辑 → 行动在这种情况下，发生某种事件（或级联事件），会触发一系列动作或一组动作。
IFTTT 就是一个很好的例子，它接受一个事件，应用一些逻辑（提示“ if this thenthat”的缩写），然后执行一些操作。

81

例如，当我们离开家时，关掉灯。如果我们可以对事件进行编程（例如，不在家中/离开设备），触发系统自动关闭所有灯，那么我们的生活就会变得更加简单。我自己
在家里使用它，它使生活变得更加轻松，并使我能够专注于其他更重要的活动。
如果将此与我们的 IT 运营活动进行比较，我们将看到类似的模式。发生事件（例如，虚拟机需要更多磁盘空间），然后我们执行一系列操作（例如，创建工单，添加存储，关闭工单等）。这些重复性活动是自动化可以增加价值并使我们专注于更有益
的活动的完美示例。
使用 X-Play，我们可以采取一系列事件/警报，并允许系统拦截这些事件/警报并执行一系列动作。
首先，请转到 Prism Central 中“操作”下的“播放”部分：

图. X-Play – 导航页面82这将启动 X-Play 主页：

图. X-Play – 剧本在这里，你可以通过定义触发器来创建新的剧本:

图. X-Play – 触发器
下面显示了一个基于用户自定义告警的触发器示例：:83图. X-Play – 触发器 – 用户自定义告警当定义好触发器后，你现在可以指定一系列操作。下面显示了一些示例操作:

图. X-Play -操作之后，您输入操作的详细信息，这列举了一个 REST API 调用的列子：:

84

图. X-Play - REST Action 例子
REST API 操作和外部系统
X-Play 提供了许多默认操作，例如发送电子邮件，发送 slack 消息以及执行 REST API 调用等其他操作。
当我们考虑对接 CMDB 或其他工单/自动化工具之类的外部系统时，这一点至关重要。 通过使用 REST
API 操作，我们可以与那些接口进行交互以创建/解决工单，启动其他工作流程等。这是一个非常强大的选项，它可以使所有系统保持同步。

对于实体/事件的特定详细信息，你可以使用“参数”这个变量，该变量将为您提供有关事件，实体和其他内容的详细信息：85

图. X-Play - 操作的参数
完成后，你可以保存你的播放，它将按照定义开始执行。
下面显示了一个执行多个操作的 Play 示例：

图. X-Play – Playbook 示例
Play 标签框里会显示 Play 的执行时间和状态：86图.X-Play – 执行记住，自动化所有事情！

3.5 APIs 接口基于 HTML5 的用户界面是让 Prism 成为易于使用的管理工具的关键部分。同时，另一项核心功能是用于自动化的 API。所有 Prism 用户界面提供的功能都可以通过 REST API 编程接口供外部程序调用。这使得用户或是合作伙伴可以实现自动化部
署、第三方工具集成甚至是创建他们自己的用户界面。
在动态的、软件定义的环境中，Nutanix 提供了一组/系列接口，让程序调用变得非常简单。以下是主要的接口：•

REST API•

CLI - ACLI & NCLI•

Scripting interfaces

developer.nutanix.com
要了解有关 API 的更多信息并查看示例代码，请务必查 developer.nutanix.com

作为这其中的关键部分，REST API 可调用 Prism 的每一个功能和数据点，让工
作流/自动化工具可以轻易的驱动 Nutanix 做出反应。可与 Nutanix 集成的自动化工具
包括 Saltstack，Puppet，vRealize Operations，System Center Orchestrator 和
Ansible 等，都可以非常方便的创建构建在 Nutanix 上的客户工作流。这当然也意味
着任何第三方开发人员都能通过 REST 创建他们自己的用户界面或从 Nutanix 平台提取数据。

下图展示了 Nutanix REST API 浏览器的一小部分，以表明开发者是如何调用这些API 接口并得到其所希望的数据格式：

87

图. Prism REST API 浏览器
可以展开操作来显示 REST 调用的具体信息和例子：

图. Prism REST API 调用实例
API 验证方案
对于版本 4.5.x 客户端和 HTTP 调用的验证都通过使用 HTTPS 的基本验证方式来实现。

3.5.1 ACLI
Acropolis CLI (ACLI) 是用来管理 Nutanix 产品中 Acropolis 那部分功能的命令行接口。这些功能从 4.1.2 之后被开放。
说明：所有这些操作都可以通过 HTML5 图形用户界面和 REST API 完成。我这里用的命令只是作为我用来实现自动化脚本的一部分。
进入 ACLI Shell
描述: 进入 ACLI shell (可从任何 CVM 运行)。
Acli

88

或者
描述: 通过 Linux shell 执行 ACLI 命令
ACLI <Command>

ACLI 的响应以 json 格式输出描述: 以 json 格式输出 acli 命令的结果
Acli –o json

列出主机
描述: 列出集群中的 Acropolis 节点
host.list创建网络
描述：根据 VLAN 创建网络net.create <TYPE>.<ID>[.<VSWITCH>] ip_config=<A.B.C.D>/<NN>
Example: net.create vlan.133 ip_config=10.1.1.1/24

列出网络 v
描述：列出网络
net.list创建 DHCP 范围
描述：创建 DHCP 范围
net.add_dhcp_pool <NET NAME> start=<START IP A.B.C.D> end=<END IP W.X.Y.Z>

说明： 如果在创建网络时没有指定 Acropolis DHCP 服务器的地址，那么 .254 被保留并用作 Acropolis
DHCP 服务器地址。

89Example: net.add_dhcp_pool vlan.100 start=10.1.1.100 end=10.1.1.200

获得当前网络的详细信息
描述：获得一个网络中的虚拟机及其名字、UUID、MAC 地址及 IP 地址等信息
net.list_vms <NET NAME>
Example: net.list_vms vlan.133

为网络配置 DHCP 和 DNS 服务器
描述：设置 DHCP 和 DNS
net.update_dhcp_dns <NET NAME> servers=<COMMA SEPARATED DNS IPs> domains=<COMMASEPARATED DOMAINS>
Example: net.set_dhcp_dns vlan.100 servers=10.1.1.1,10.1.1.2 domains=splab.com

创建虚拟机
描述：创建虚拟机vm.create <COMMA SEPARATED VM NAMES> memory=<NUM MEM MB> num_vcpus=<NUM VCPU>
num_cores_per_vcpu=<NUM CORES> ha_priority=<PRIORITY INT>
Example: vm.create testVM memory=2G num_vcpus=2

批量创建虚拟机
描述：批量创建虚拟机vm.create <CLONE PREFIX>[<STARTING INT>..<END INT>] memory=<NUM MEM MB>
num_vcpus=<NUM VCPU> num_cores_per_vcpu=<NUM CORES> ha_priority=<PRIORITY INT>
Example: vm.create testVM[000..999] memory=2G num_vcpus=2

基于已有虚拟机克隆
描述：创建已有虚拟机的克隆
vm.clone <CLONE NAME(S)> clone_from_vm=<SOURCE VM NAME>

90

Example: vm.clone testClone clone_from_vm=MYBASEVM

基于已有虚拟机批量克隆
描述：批量创建已有虚拟机的克隆
vm.clone <CLONE PREFIX>[<STARTING INT>..<END INT>] clone_from_vm=<SOURCE VM NAME>
Example: vm.clone testClone[001..999] clone_from_vm=MYBASEVM

创建磁盘并添加到虚拟机# Description: Create disk for OS
vm.disk_create <VM NAME> create_size=<Size and qualifier, e.g. 500G> container=<CONTAINER
NAME>class="codetext"Example: vm.disk_create testVM create_size=500G container=default

给虚拟机添加网卡
描述：创建并添加网卡
vm.nic_create <VM NAME> network=<NETWORK NAME> model=<MODEL>
Example: vm.nic_create testVM network=vlan.100

设置虚拟机的启动磁盘
描述：设置启动设备通过磁盘 ID 设置从指定的磁盘启动
vm.update_boot_device <VM NAME> disk_addr=<DISK BUS>
Example: vm.update_boot_device testVM disk_addr=scsi.0

设置虚拟机的启动光驱设置从光驱启动
vm.update_boot_device <VM NAME> disk_addr=<CDROM BUS>

91

Example: vm.update_boot_device testVM disk_addr=ide.0

挂载 ISO 到光驱
描述：挂载 ISO 到虚拟机的光驱步骤:1. 上载 ISOs 到 container
2. 为客户端 IP 地址设置访问白名单
3. 上载 ISOs 以共享
基于 ISO 创建光驱设备
vm.disk_create <VM NAME> clone_nfs_file=<PATH TO ISO> cdrom=true
Example: vm.disk_create testVM clone_nfs_file=/default/ISOs/myfile.iso cdrom=true

如果光驱已经创建则直接挂载vm.disk_update <VM NAME> <CDROM BUS> clone_nfs_file<PATH TO ISO>
Example: vm.disk_update atestVM1 ide.0 clone_nfs_file=/default/ISOs/myfile.iso从光驱卸除 ISO
描述：从光驱移除 ISO
vm.disk_update <VM NAME> <CDROM BUS> empty=true开启虚拟机
描述：开启虚拟机vm.on <VM NAME(S)>
Example: vm.on testVM

开启所有虚拟机

92

Example: vm.on *开启一段编号范围的虚拟机
Example: vm.on testVM[01..99]

3.5.2 NCLI
说明：所有这些操作都可以通过 HTML5 图形用户界面和 REST API 完成。我这里用的命令只是作为我用来实现自动化脚本的一部分。.
添加子网到 NFS 白名单
描述：添加特定的子网到 NFS 白名单
ncli cluster add-to-nfs-whitelist ip-subnet-masks=10.2.0.0/255.255.0.0

显示 Nutanix 版本
描述：显示当前 Nutanix 软件的版本
ncli cluster version

显示 NCLI 的隐藏选项
描述：显示 ncli 的隐藏命令/选项
ncli helpsys listall hidden=true [detailed=false|true]

列出存储资源池
描述：显示已存在的存储资源池
ncli sp ls

列出存储容器描述：列出已有的容器
ncli ctr ls创建存储容器93

描述：创建一个新的容器
ncli ctr create name=<NAME> sp-name=<SP NAME>

列出虚拟机
描述：显示已存在的虚拟机
ncli vm ls

列出公共密钥
描述：列出已存在公共密钥ncli cluster list-public-keys

添加公共密钥
描述：为集群访问添加公共密钥通过 SCP 传输公共密钥到 CVM
添加公共密钥到集群
ncli cluster add-public-key name=myPK file-path=~/mykey.pub

移除公共密钥
描述：移除集群访问的公共密钥ncli cluster remove-public-keys name=myPK创建保护域
描述：创建一个保护域
ncli pd create name=<NAME>

创建远程站点描述：为数据复制创建远程站点

94

ncli remote-site create name=<NAME> address-list=<Remote Cluster IP>

为存储容器内的所有虚拟机创建保护域
描述：保护特定存储容器中的所有虚拟机ncli pd protect name=<PD NAME> ctr-id=<Container ID> cg-name=<NAME>

为特定虚拟机创建保护域
描述：保护特定虚拟机ncli pd protect name=<PD NAME> vm-names=<VM Name(s)> cg-name=<NAME>

为 DSF 文件（亦称作 vDisk）创建保护域
描述：保护特定的 DSF 文件
ncli pd protect name=<PD NAME> files=<File Name(s)> cg-name=<NAME>

创建保护域的快照
描述：为保护域创建一次性的快照ncli pd add-one-time-snapshot name=<PD NAME> retention-time=<seconds>

创建快照和同步到远程站点的复制计划
描述：创建一个持续的快照计划，同步数据到远程站点
ncli pd set-schedule name=<PD NAME> interval=<seconds> retention-policy=<POLICY> remotesites=<REMOTE SITE NAME>

列出复制状态
描述：监控数据复制状态ncli pd list-replication-status迁移保护域到远程站点95

描述：故障切换一个保护域到远程站点
ncli pd migrate name=<PD NAME> remote-site=<REMOTE SITE NAME>

激活保护域
描述：激活远程站点的保护域
ncli pd activate name=<PD NAME>

开启 DSF 的 Shadow Clones
描述：开启 DSF 的 Shadow Clone 功能
ncli cluster edit-params enable-shadow-clones=true

打开 vDisk 的去重
描述：为特定 vDisk 开启指纹识别并启用去重
ncli vdisk edit name=<VDISK NAME> fingerprint-on-write=<true/false> on-disk-dedup=<true/false>

检查集群可恢复性状态# Node status
ncli cluster get-domain-fault-tolerance-status type=node# Block status
ncli cluster get-domain-fault-tolerance-status type=rackable_unit

3.5.3 PowerShell CMDlets
下面将讲述 Nutanix 对 PowerShell CMDlets 命令行支持，包括如何使用和一些关于Windows PowerShell 的背景知识。
基础Windows PowerShell 是构建在.net 框架上的强大的 shell 和脚本语言。它是非常易用的编程语言，直观且交互性好。PowerShell 中有一些关键结构和组件：96CMDlets
CMDlets 是一组执行特定操作的命令或.NET 类。它们符合 Getter/Setter 方法论，通常使用<动词>-<名词>的操作结构。例如：Get-Process, Set-Partition 等。
管道（Piping）和流水线（Pipelining）

管道是 PowerShell 中的重要概念（类似于 Linux 中的用法），如果能正确使用，能使很多事变得简单。通过管道，你基本上可以把一个流水线操作的输出导向到作为下
一个流水线操作的输入。流水线可以根据需要变长。一个非常简单的例子就是获得当
前进程，找到匹配特定特征或过滤器的进程，然后对它们进行排序:
Get-Service | where {$_.Status -eq "Running"} | Sort-Object Name

管道也可以被用在 for-each 循环中，例如：# For each item in my array$myArray | %{# Do something}关键对象类型
下面是 PowerShell 中一些关键对象类型。你可以通过.getType()方法非常容易的得到
一个对象的类型，比如：$someVariable.getType()将会返回特定对象的类型。

变量$myVariable = "foo"说明：你可以为变量赋值为一系列命令或管道的输出:$myVar2 = (Get-Process | where {$_.Status -eq "Running”})

在这个例子中，将先运算括号中的命令，然后把其赋值给变量。

数组

97

$myArray = @("Value","Value")说明：你可以得到阵列、哈希表或自定义对象的数组。

哈希表$myHash = @{"Key" = "Value";"Key" = "Value"}

有用的命令
获得特定 CMDlet 命令的帮助信息（类似于 Linux 中的 man）
Get-Help <CMDlet Name>
Example: Get-Help Get-Process

列出一个命令或对象的属性和方法<Some expression or object> | Get-Member
Example: $someObject | Get-Member

核心 Nutanix CMDlets 和使用方法
下载 Nutanix CMDlets 安装器。Nutanix CMDlets 可以通过 Prism（4.0.1 以后版本）
用户界面直接下载，在右上角的下拉列表中可以找到。

98

图. Prism CMDlets 安装器链接

装载 Nutanix Snap-in
检查 snap-in 是否被装载，如没有请装载if ( (Get-PSSnapin -Name NutanixCmdletsPSSnapin -ErrorAction SilentlyContinue) -eq $null ){Add-PsSnapin NutanixCmdletsPSSnapin}

列出 Nutanix CMDlets
Get-Command | Where-Object{$_.PSSnapin.Name -eq "NutanixCmdletsPSSnapin"}连接到一个 Acropolis 集群
Connect-NutanixCluster -Server $server -UserName "myuser" -Password (Read-Host"Password: " -AsSecureString) -AcceptInvalidSSLCerts

获得满足搜索条件的虚拟机

99

设置变量
$searchString = "myVM"$vms = Get-NTNXVM | where {$_.vmName -match $searchString}

交互式
Get-NTNXVM | where {$_.vmName -match "myString"}

交互式的格式化输出
Get-NTNXVM | where {$_.vmName -match "myString"} | ft获得 Nutanix vDisks
变量方式$vdisks = Get-NTNXVDisk

交互式
Get-NTNXVDisk

交互式的格式化输出
Get-NTNXVDisk | ft获得 Nutanix 存储容器设置变量$containers = Get-NTNXContainer

交互式
Get-NTNXContainer

交互式的格式化输出
Get-NTNXContainer | ft100获得 Nutanix 保护域
设置变量$pds = Get-NTNXProtectionDomain

交互式
Get-NTNXProtectionDomain

交互式的格式化输出
Get-NTNXProtectionDomain | ft获得 Nutanix 一致性组
设置变量$cgs = Get-NTNXProtectionDomainConsistencyGroup

交互式
Get-NTNXProtectionDomainConsistencyGroup

交互式的格式化输出
Get-NTNXProtectionDomainConsistencyGroup | ft资源和脚本：•

Nutanix Github - https://github.com/nutanix/Automation•

Manually Fingerprint vDisks - http://bit.ly/1syOqch•

vDisk Report - http://bit.ly/1r34MIT•

Protection Domain Report - http://bit.ly/1r34MIT•

Ordered PD Restore - http://bit.ly/1pyolrb

注意：

上面的一些脚本没有被维护，仅供参考。
你可以在 Nutanix Github 上找到更多脚本

101https://github.com/nutanix

glance image-show <IMAGE_ID>

4

第四部分： Acropolis

4.1 架构
Acropolis 操作系统（AOS）提供了平台上运行工作负载和服务所用到的核心功能。包括但不限于存储服务、升级等。
该图中高亮显示的图像，展示了 Acropolis 在各个层面的概念性质：图. Acropolis 高级架构基于 Nutanix 的分布式特性，我们将其扩展到虚拟化和资源管理领域。Acropolis
是一个后端服务，支持工作负载和资源管理、配置和操作。它的目标是从运行的工作
负载中抽象出便利的资源(例如，系统管理程序、内部环境、云等等)，同时提供一个
单一的“平台”进行操作。
这使得工作负载能够在管理程序、云提供商和平台之间无缝移动。
支持的虚拟机管理程序

从 4.7 开始，支持 AHV 和 ESXi 虚拟机管理程序，但是未来可能会扩大对 Hypervisor 的支持。所有卷 API
和只读操作仍然受支持。

4.1.1 Acropolis 服务
102

集群内的每个 CVM 上都会运行一个 Acropolis 服务，其中一个会被选举为首选
Acropolis，负责任务调度，任务执行，IPAM（IP 地址管理）等，其余的均为从属
Acropolis，类似于其他具有首选节点的组件，当集群中首选 Acropolis 发生故障时，就会在余下的 Acropolis 服务中选举出一个新的首选 Acropolis。
Acropolis 服务的角色分类如下：主 Acropolis•

任务调度&执行

•统计信息收集/发布•网络控制器（针对 Hypervisor）•

VNC 代理（针对 Hypervisor）•

HA（针对 Hypervisor）

从属 Acropolis•

统计信息收集/发布

•VNC 代理（针对 Hypervisor）

下图展示了首选 Acropolis 与从属 Acropolis 之间关系的概念视图：103

图. Acropolis 服务
4.1.2 动态调度
有效地安排资源是确保资源有效利用的关键。Acropolis 动态调度增强了传统调度方
法需要依赖计算资源(CPU/MEM)来做出放置决策的调度方法。它充分利用了计算，存储和其他资源来驱动 VMs 和卷(ABS)放置决策。这确保了有效的资源消耗，从而获
得最佳的最终用户性能体验。
资源调度由两个关键过程组成:•
初始位置放置虚拟机在哪台服务器节点上开机•运行时优化基于实时运行指标的工作负载移动

Acropolis 调度在虚拟机初始位置放置时即开始生效。随着在 Asterix 版本的发布，
Acropolis 动态调度在此基础上扩展并提供实时的资源优化功能。
图中显示了调度架构的高级视图:104

图.Acropolis 动态调度
动态调度机制始终运行，从而优化放置位置， (目前每 15 分钟| Gflag:lazan_anomaly_detection_period_secs)。使用历史利用数值和平滑算法计算预估需求。这个预估的需求考虑到动态因素，这保证了突然的峰值不会扰乱结果。
独特的资源优化方法
审视现有的调度/优化平台(VMware DRS, Microsoft PRO)时，它们都只关注于在集群资源之间均匀地平衡工作负载，需要注意的是，如何消除激进的资源不平衡，主要取决于配置(例如手动->没有，保守->一些，激进->更多)。
例如，假设集群中有 3 个主机，每个主机分别使用 50%、5%和 5%。典型的解决
方案将尝试重新平衡工作负载，使每个主机利用率达到 20%。但是真的有必要吗?
我们真正需要的是消除资源竞争，而不是消除不平衡。除非有资源竞争，否则“平衡”工作负载不会带来任何好处。事实上，通过强迫不必要的移动，我们会导致额
外的工作(例如，内存传输、缓存重新定位等)，所有这些都需要消耗资源。
Acropolis 动态调度机制是这样的：它只会在预期发生资源竞争的情况下调用工作
负载移动，而不是因为不平衡。注:Acropolis DSF 以不同的方式工作，以确保在整
个集群中均匀分布数据以消除热点和加速重建。要了解更多 DSF，请查看“磁盘平衡”部分。
在虚拟机开机的时候。ADS 将平衡 VMs 在整个集群中的初始放置位置。

105

4.1.3 放置位置
放置位置取决于下面的几个因素：• 计算资源消耗我们监控每个节点的计算利用率。如果一个节点的 CPU 分配违背了它的阈值(目前是主机 CPU 的 85% | Gflag: lazan_host_cpu_usage_old_fraction)，我们将从这主机上迁移出 VMs 来重新平衡工作负载。这里要提到的一个关键问题是，只有在存在资源
争用时才会执行迁移。如果在节点之间(例如，3 节点 10%和 1 节点 50%)之间的利用率有偏差，我们将不会执行迁移，因为这样做没有任何好处，除非有资源争用。
•

存储性能作为一个超融合平台，我们管理计算和存储资源。调度程序将监视每个节点的Stargate 进程利用率。当某些 Stargate(s)违反分配阈值(当前 CPU 分配给 Stargate
为 85% | Gflag: lazan_stargate_cpu_usage_old_pct)时，我们将在主机间迁移资源，
以消除任何热点。VMs 和 ABS 的卷都可以迁移以消除任何热点的 Stargates 访问。
• (反)关联规则关联性或反关联性约束决定了在环境中的某项资源在调度时需要基于其他特定资源所在的位置。例如在某些情况下，您希望 VMs 在相同的节点上运行，以获得合规的许可。在这种情况下，VMs 将被绑定到同一个主机上。在其他情况下，您可能希望确
保 VMs 在不同的节点上运行，以实现可用性。在这种情况下，虚拟机将被反关联性约束。
调度器将尽最大努力基于先前工作负载情况确保优化。该系统会对无谓的移动进行惩罚，以确保不会有太多的迁移发生。这是非常重要的，因为我们希望确保移动不会对工作负载产生任何负面影响。
在迁移之后，系统将判断迁移的“有效性”，并了解实际的好处是什么。通过这种智能的学习模式可以自我优化，以确保任何迁移决策都有一个有效的依据。

4.2 安全与加密
自 Nutanix 平台创建开始，安全就是 Nutanix 平台的核心部分。 安全开发生命周期（Security Development Lifecycle (SecDL) ）贯穿 Nutanix 开发过程的每一步。安全开发生命周期系统是从开发阶段就考虑安全，而不是到最终用户使用后根据客户安
全需求再开始考虑去“加固”平台。
当我们考虑安全问题时，我们实际上是在努力实现三个核心目标(被恰当地称为
CIA 三位一体):106

1. 保密性o 通过防止未经授权的访问来保护和保护数据
2. 完整性o 通过防止未经授权的更改，确保资料的一致性和准确性
3. 可用性o 确保获授权用户可通过弹性和冗余访问数据这可以简化为一个简单的语句: 允许用户在不让坏人进入的情况下完成他们的工作。当我们设计安全性时，我们需要看看几个核心领域的利益，这些区域在下图中突出显示：

图. 安全层面
在下面的章节中，我们将详细分析先前图表中的每一个部分。

系统和配置
快速一览

107

•
•
•
•
•

修补并删除已知的漏洞
强制使用强密码并删除默认帐户
配置权限和用户权限关闭未使用的端口/协议
使用自动化来确保基线传统上，人们使用一种称为“加强”的方法来指代系统（OS+App）安全性。在这个过程中，您可以通过将某些内容配置为一个称为基线的特定标准来保护系统。
国防部的 IT 组织（DISA）有一个样本强化指南，他们称之为 STIG（更多细节见下文 SCMA 部分）。这包括目录权限、用户帐户管理、密码复杂性、防火墙和许
多其他配置设置。
一旦一个系统被配置成这个标准，它就被认为是“安全的”，然而这仅仅是这个过
程的开始。系统安全是在其整个生命周期中必须维护的东西。例如，为了确保满足标
准加固基线，应该配置使用自动化工具。这确保系统始终满足您的基线“期望状态”。
Nutanix 使用我们开发的一个称为 SCMA 的工具来确保其 CVM 和 AHV 虚拟机监控程序的安全，本节稍后将介绍这个工具。

数据
快速一览
•
•
•

对数据的安全访问控制
始终备份
数据加密和安全密钥

数据是任何业务的核心，可以说是公司最有价值的资产。 考虑安全性时，我们需要确保数据的可访问性，质量和避免泄露。
关于可访问性的概念，我们始终需要访问系统和数据来制定决策。 最近一种称为“勒索软件”的攻击方法通过加密数据，然后勒索用户以获取访问权限，从而对数据
访问构成威胁。 可以通过多种方法来避免这种情况，这也突出了备份的重要性。
数据质量也是至关重要的一项，因为很多决定或行动都取决于它。 例如，攻击者可以访问系统并下达恶意订单或将货物的收件地址改为他的地址。 在这里日志和校验对于确保数据不被篡改至关重要。

108

最后一点是我们如何保护或加固数据。 通常是通过加密来完成的，如果没有用
于解密数据的密钥，则加密过程将使数据变得无法使用。 在这种情况下，如果有人
要窃取加密的文件或磁盘设备，则他们将无法访问里面的数据。

网络

快速一览
•
•
•

划分授信/不受信的网络
外围和网段之间的防火墙
利用 IDPS 来检测异常网络是攻击者用来获取系统访问权限的典型通信媒介。 其中包括周边安全（例如外部防火墙）和内部入侵防护/检测。
像任何好的设计一样，网络也应该始终存在多个安全层级。 我们需要将高安全性网络从受信任的网络中划分出来，并从不受信任的网络（例如商业/ wifi 网络）中保护它们。 我们要始终认为办公室里的网络是永远不安全的。
通过拥有多级分层的网络，我们可以确保已经可以访问我们不受信网络的人在想进入安全网络时会遇到更大的困难。 在此过程中，好的 IDPS 系统可以检测访问异常或扫描工具，例如 nmap。

认证与授权
快速一览
•
•

尽可能使用 MFA / 2FA
使用细化权限身份验证就是根据可信赖的真实数据源例如 Active Directory 或任何其他 IDP（提供身份验证程序），对用户身份进行身份验证。 MFA（多因素身份验证）或2FA 这样的工具增加了对用户身份的额外保证。
一旦身份得到验证，下一步就是确定他们被授权做什么或可以访问什么；这就是授权部分。 用户 foo 被授权在 bar 上执行 x，y，在 bas 上执行 y，z。

合规与监控

109

快速一览
•
•

合规是一项持续的活动监控并查找异常

合规性通常是人们在查看某些认证（如 PCI、HIPA 等）时所指的东西。它进一
步扩展到确保符合已设置的强化指南或标准。 例如，STIG 是强化样本的基线，但是每个公司可能都有其他的政策/规则。 为了确保系统安全，我们必须确保我们的系统
符合这些策略并处于合规状态。
传统上，合规检查是可追溯的且大部需要手工完成的过程。这绝对是个错误的方法。 合规性是我们必须始终确保的事情，因为这是限制任何潜在威胁因素或关闭任
何可能威胁因素的唯一方法。
处理配置管理自动化（也称为期望状态配置-DSC）的工具至关重要。 它将确保我们的配置/设置始终配置在基线或所需的状态上。
监视和渗透测试对于验证和确保此合规性至关重要。 Nessus，Nmap 或metasploit 等工具可用于测试系统的安全性。 在测试过程中，监视和检测系统应检测到它们并发出警报。

用户
快速一览
•
•

教育，教育，教育养成良好的习惯（例如锁定计算机）

在任何系统中，用户一般来说都是最薄弱的环节。 为了确保用户不易遭受网络钓鱼攻击或社交操纵，培训和教育至关重要。 我们必须确保用户知道要查找的内容，如果他们不确定，可以升级到已知资源。
一种方法是模拟网络钓鱼攻击，这样用户就可以保持审视的态度。 我们还必须执行其他政策，例如计算机解锁状态下不要离开它或不要把密码写下来。

证书和认证
Nutanix 在堆栈的各个部分（内部和外部）都具有以下安全认证/资格：110

通用准则（Common Criteria）
o 1996 年六国七方签署了《信息技术安全评估通用准则》即 CC1.0。
1998 年美国、英国、加拿大、法国和德国共同签署了书面认可协议。后来这一标准称为 CC 标准，即 CC2.0。CC2.0 版于 1999 年成为国际标准 ISO/IEC
15408。目前已经有 17 个国家签署了互认协议，即一个 IT 产品在英国通过 CC
评估以后，那么在美国就不需要再进行评估了，反之亦然。
o *This is currently under re-certification as of March 2020•

安全技术实现指南（Security Technical Implementation Guides•(STIGs)）
DOD IA 和启用 IA 的设备/系统的配置标准。 自 1998 年以来，DISA 现场安全运营（FSO）通过提供《安全技术实施指南》，在提高 DoD（国防部）
安全系统的安全状况方面发挥了关键作用。 STIG 包含用于“锁定”可能容易受到
恶意计算机攻击的信息系统/软件的技术指南。
o美国联邦信息处理标准 FIPS 140-2
o FIPS Publication 140-2 是 NIST 所发布的针对密码模块的安全需求（Security requirements for cryptographic modules）。FIPS 140-2，这些标准和方针由 NIST 发布，并作为联邦信息处理标准（FIPS）在政府机构广泛采用。目前该标准的最新版本发表于 2002 年 12 月 3 日，其提供了密码模块评测、验证和最终认证的基础。
o FIPS 140-2 standard is an information technology security
accreditation program for cryptographic modules produced by private sector
vendors who seek to have their products certified for use in government
departments and regulated industries (such as financial and health-careinstitutions) that collect, store, transfer, share and disseminate sensitive but
unclassified (SBU) information.
• NIST 800-53• NIST 800-131a• ISO 27001• ISO 27017• ISO 27018•

自动安全配置管理 Security Configuration Management Automation (SCMA)

Nutanix 安全引擎现在可以让客户在特定时间点的安全基线检查，演进到在整个
部署的生命周期里持续进行安全基准线监控/自动修复，确保集群中所有 CVM 和AHV 主机满足安全基线要求。检查内容完全满足所有 STIGs 的安全检查项目，当发现不满足要求时，不需要客户介入就可以自动将配置设定为符合安全的设置。
111

执行 Ad-hoc SCMA
SCMA 将按照配置好的频率执行（默认是每小时），当然也可以根据要求立即执行。可以通过登录
CVM 后执行如下命令来运行 SCMA 工具：# Run on a single CVM
sudo salt-call state.highstate# Run on all CVMs
allssh "sudo salt-call state.highstate"

Nutanix 命令行接口（The Nutanix Command Line Interface (NCLI)）允许客户
设置不同的配置去满足严格的安全需求。
CVM 安全配置 CVM Security Settings
通过 NCLI 里下面的命令可以在集群范围内配置 SCMA 策略。下面列举所有的命
令和功能：
获得 CVM 安全配置：
ncli cluster get-cvm-security-config

此命令输出当前集群的配置，默认输出如下内容：
Enable Aide : false
Enable Core : false
Enable High Strength P... : false
Enable Banner : false
Enable SNMPv3 Only : false
Schedule : DAILY设置 CVM 登录条：112

此命令可以设置当登录任何一个 Nutanix CVM 时，是否开启或关闭 Departmentof Defense (DoD) knowledge of consent 登录条。
ncli cluster edit-cvm-security-params enable-banner=[yes|no] #Default:no

自定义登录条默认情况下， DoD knowledge of consent 登录条是启用的，通过下面的步骤可以自定义登录条 (登录任意一个 CVM 用 nutanix 账号运行):1. 备份当前的 Bannersudo cp -a /srv/salt/security/KVM/sshd/DODbanner /srv/salt/security/KVM/sshd/DODbannerbak

2. 通过 vi 命令修改当前 Bannersudo vi /srv/salt/security/KVM/sshd/DODbanner

3. 在所有其他 CVM 上重复以上修改 Banner 的步骤
4. 使用前面的命令启用 Banner设置 CVM 秘码长度

以下命令可以启用或关闭长密码策略(minlen=15,difok=8,remember=24).
ncli cluster edit-cvm-security-params enable-high-strength-password=[yes|no]#Default:no设置高级入侵检测环境（ Advanced Intrusion Detection Environment(AIDE)）
113

以下命令可以开启或关闭每周运行的 AIDE 服务
ncli cluster edit-cvm-security-params enable-aide=true=[yes|no] #Default:no设置 SNMPv3 only通过以下命令开启或关闭 SNMPv3 only traps.
ncli cluster edit-cvm-security-params enable-snmpv3-only=[true|false]#Default:false设置 SCMA schedule

以下命令设置 SCMA 运行频率：
ncli cluster edit-cvm-security-params schedule=[HOURLY|DAILY|WEEKLY|MONTHLY]#Default:HOURLY

虚拟化安全设置

The following commands have been added to NCLI to support cluster-wide
configuration of the SCMA policy. The list below gives all commands and functions:获得虚拟化的安全配置
ncli cluster get-hypervisor-security-config

此命令输出当前集群的配置，默认输出内容如下：
Enable Aide : false
Enable Core : false
Enable High Strength P... : false
Enable Banner : false
Schedule : DAILY设置虚拟化登录条114

此命令可以设置当登录任何一个 Nutanix 虚拟化时，是否开启或关闭
Department of Defense (DoD) knowledge of consent 登录条。
ncli cluster edit-hypervisor-security-params enable-banner=[yes|no]#Default:no设置虚拟化的密码强度

以下命令可以启用或关闭长密码策略(minlen=15,difok=8,remember=24).
ncli cluster edit-hypervisor-security-params enable-high-strength-password=[yes|no] #Default:no设置 Advanced Intrusion Detection Environment (AIDE)

以下命令可以开启或关闭每周运行的 AIDE 服务.
ncli cluster edit-hypervisor-security-params enable-aide=true=[yes|no]#Default:no设置 SCMA schedule

以下命令设置 SCMA 运行频率：
ncli cluster edit-hypervisor-security-params schedule=[HOURLY|DAILY|WEEKLY|MONTHLY]#Default:HOURLY

锁定集群
集群锁定功能是将 CVM 设置为只能通过密钥登录，而不能使用用户名和密码访问的一种方式。
在 Prism 界面右上角的齿轮菜单里可以找到集群锁定功能的配置项：115

图.集群锁定菜单这个界面会显示当前的配置，并允许你添加/删除用于访问的 SSH 密钥：

图.集群锁定界面
点击“New Public Key”按钮添加新的公钥，并输入密钥信息：116

图.集群锁定-添加密钥
SSH 密钥的制作

可以运行下面的命令来生成一个 SSH 密钥对：
ssh-keygen -t rsa -b 2048
这个命令会生成由两个文件组成的密钥对：••

id_rsa (私有密钥)
id_rsa.pub (公共密钥 – 这个密钥在向集群中添加密钥时使用。)

在你添加了密钥以后，你就有了有效的访问凭证，你可以禁用基于用户名密码的登录，通过勾选'Enable Remote Login with Password.'的选项，界面会弹出一个确认窗口，点击“OK”按钮之后，集群就被设置为锁定了。

4.2.1 数据加密和密钥管理
数据加密是一种允许对数据进行编码的方法，只有那些被授权的人才能使用数
据，使任何未经授权的人都无法解析。

117

例如，如果我有一条消息要发送给某人并确保只有他们可以读取它，我可以使用
密码（密钥）加密消息（明文）并向他们发送加密消息（密文）。 如果此消息被盗或被拦截，则攻击者只能看到密文，这些密文在没有密码来解密消息的情况下几乎无用。 一旦所需的一方收到了消息，他们就可以使用我们给他们的密钥解密消息。
有几种加密数据的主要方法：•对称加密（私钥加密）：o 相同的密钥用于加密和解密数据
o 示例：AES，PGP *，Blowfish，Twofish 等。
•非对称加密（公钥加密）：o 一个密钥用于加密（公钥），另一个密钥用于解密（私钥）o 示例：RSA，PGP *等
注意：PGP（或 GPG）使用对称和非对称密钥。
在讨论数据加密时，通常在两个主要环境中完成：•传输中：双方之间传输的数据（例如，通过网络发送数据）•静止：静态数据（例如存储在设备上的数据）
从 5.8 开始，Nutanix 解决了静态数据加密问题。
以下部分将介绍 Nutanix 如何管理数据加密及其关键管理选项。
数据加密

Nutanix 通过三种主要可选途径提供数据静态加密:•••原生基于软件的加密 (FIPS-140-2 Level-1) *released in 5.5
使用自加密磁盘 (SED) (FIPS-140-2 Level-2)
软件 + 硬件加密

加密配置可选在集群或容器级别，这取决于虚拟化层的类型：•

集群级别加密:o AHV, ESXi, Hyper-V•
容器 级别加密:o ESXi, Hyper-V
注意: 对基于 SED 加密的部署，物理设备自身加密，所以是集群级别的。
通过在设置菜单（齿轮）中使用“Data-at-Rest Encryption”功能查看集群加密状态。
可以看到当前状态并允许配置加密（如果当前没启用）。

118

下面例子中可以看到加密在集群层面已经启用：

图.数据加密-已启用（集群层面）下面例子中可以看到已经为列出的特定容器启用加密：119

图.数据加密-已启用（容器层面）通过点击“edit configuration”按钮可以启用/修改配置。弹出的菜单可以配置用于加密
的 KMS 或者查看现在正在使用的 KMS：

120

图.数据加密-配置
对于外部的 KMS，菜单可以引导使用 CSR 申请流程，配合 CA 完成签名。

原生基于软件的加密
Nutanix 软件加密提供原生的 AES-256 静态数据加密。这会和任何 KMIP 或者符合
TCG 规范的外部 KMS 服务器（Vormetric，SafeNet 等等）或者 Nutanix 原生 KMS（5.8 引入，后面会介绍更多）交互。对于加密/解密，系统会使用 Intel AES-NI 加速
功能减少潜在的性能影响。
当数据写入（OpLog 和 Extent Store）时，数据会在写入磁盘之前，在校验值的边界进行加密。
加密是数据写入磁盘之前应用到数据的最后一次转化：121

图. 数据加密-转化应用
加密和数据效率
由于数据加密是在应用所有去重压缩之后，可以确保保持这些方法对空间的节省。简单来说，对加密的数据
的去重压缩率会和非加密数据完全一样。

读数据时，会从磁盘上校验值边界读取加密数据，解密之后返回。在校验值边界执行
加密/解密可以确保没有读放大产生。借助于 Intel AES-NI 卸载，可以看到几乎没有任何对性能/响应时间的影响。
基于 SED 的加密

下图显示了概要的架构图：122图.数据加密-概要
SED 的数据加密方式是将存储设备划分为能设置为加密状态和非加密状态的“数据条带”。在 Nutanix 的系统里，boot 和 Nutanix 的 Home 分区是被加密处理过的。
所有的数据磁盘和数据条带是用 big key 到 level-2 标准进行高度加密处理的。
当集群启动的时候，它会想 KMS 服务器发出请求解锁磁盘的密钥。为了确保在集群里从来也不缓存任何密钥。在系统冷启动和 IPMI 重置的过程中，这个节点将需要向KMS 服务器发出获取解锁磁盘的请求。CVM 软启动的过程不会强制发生以上操作。

密钥管理(KMS)
Nutanix 提供原生的秘钥管理（本地秘钥管理器-LKM）存储功能（5.8 引入）作为对
第三方专用 KMS 解决方案的替代方案。用来消除对专用 KMS 的需要并简化环境，
当然外部 KMS 仍然支持。
前述章节提到过，秘钥管理是所有数据加密方案最重要的部分。多个秘钥用来在整个
堆栈中提供非常安全的秘钥管理方案。
在方案中使用了三种类型的秘钥：

123

·

数据加密秘钥 (DEK)o 用来加密数据的秘钥·

秘钥加密秘钥 (KEK)o 用来加密 DEK 的加密秘钥·

主加密秘钥 (MEK)o 用来加密 KEK 的加密秘钥o 只在使用本地秘钥管理器时使用下图展示了不同秘钥和 KMS 选项的关系：

图. 数据加密-秘钥管理

124

本地秘钥管理（LKM）服务分布在每个 Nutanix 节点，原生的运行在每个 CVM 中。
服务使用 FIPS140-2 加密模型（通过认证），秘钥管理器完成所有秘钥管理动作（例如重新生成秘钥，备份秘钥等）的同时，对于最终用户完全透明。
配置数据加密时，原生的 KMS 可以通过选择“Cluster’s local KMS”来使用：

图. 数据加密-配置
主秘钥使用 Shamir’s Secret Sharing 算法切片后存储在集群的所有节点上保证弹性
和安全。最小必须有 ROUNDUP(N/2)个节点重构秘钥，N=集群中所有节点的数量。
秘钥备份和秘钥轮换一旦启用加密，推荐备份数据加密秘钥（DEK）。如果备份，必须保证健壮的密码和位置安全。

系统提供轮换（重新生成秘钥）KEK 和 MEK 的功能。系统自动每年轮换主秘钥，该操作也可以按需完成。
在增加/移除节点事件中，也会发生主秘钥轮换。

4.3 分布式存储结构
125

分布式存储 DSF 像集中存储一样呈现给 Hypervisor，然而所有的 I/O 是在本地处理
以提供更高的性能。这些节点如何构成分布式系统的更详细内容会在下面章节里介绍。

4.3.1 数据结构
Acropolis 分布式存储结构的高层组件如下：存储池
角色：一组物理存储设备
描述：一个存储池是一组物理存储设备，包括集群内所有节点的 PCIe SSD、SSD 和
HDD。存储池可以跨多个 Nutanix 节点并且随着集群的扩展而扩展。在大部分情况下，建议单个集群配置一个存储池。
容器
角色：一组虚拟机或者文件的逻辑分组
描述：容器（container）从逻辑上划分存储池，并包含一组虚拟机或者文件（即虚拟磁盘）。一些配置项（例如 RF）是在容器层实现的，然后应用在单个虚拟机文件层
面。容器和 Datastore 是一一对应的（在 NFS、SMB 场景中）。
vDisk
角色：vDisk
描述：一个虚拟磁盘文件(vDisk)是 DSF 上任意一个大于 512KB 的文件（包括 VMDK
和虚拟机硬盘）。vDisk 逻辑上由组成‘Block map’的 vBlocks 组成，
最大 DSF vDisk 容量
DSF/stargate 方面并没有强制限制 vdisk 的大小。4.6 版本，vdisk 尺寸数值占用
64bit 二进制数。这意味着理论上最大 vDisk 容量可以达到 2^63-1 or 9E18 (9Exabytes)。任意小于这个数值的限制都来自客户端，比如 ESXi 规定的最大
vmdk 容量。

下图显示了各组件在 DSF 与 Hypervisor 之间的对应关系：

126

图. 文件系统分解纵览vBlock••

Key Role: 1MB chunk of vDisk address space
Description: A vBlock is a 1MB chunk of virtual address space composing avDisk. For example, a vDisk of 100MB will have 100 x 1MB vBlocks, vBlock 0
would be for 0-1MB, vBlock 1 would be from 1-2MB, and so forth. These vBlocks
map to extents which are stored as files on disk as extent groups.

Extend
角色：逻辑上连续的数据块
描述：一个 Extent 是逻辑上连续的 1MB 大小的数据块，它由 n 个连续的 block 组成（block 大小取决于不同操作系统）。Extent 的读写修改是基于更小的子块（也称为slice）以保证可粒度和有效性。当一个 extent 的 slice 被读入 cache 时，可以根据被读取/cache 的数据量大小被修剪。

Extend 组
角色：物理上连续的数据块
描述：一个 Extent Group 是物理上连续存储的 1MB 或者 4MB 大小的数据块。它以
文件的形式由 CVM 管理并保存在磁盘上。Extent 被动态分布在多个 Extent 组中，提供数据跨节点和磁盘的条带功能用来提高 IO 性能。注：在 NOS4.0 中，Extent 组可
以是 1MB 或者 4MB，这取决于消重功能。
下图说明这些不同结构分类和各个文件系统之间的对应关系:

127

图.文件系统分解细节
这是另外一个表明文件系统各部分关系的示意图：图.图形文件系统分解

4.3.2 I/O 路径和缓存你可以通过观看下面视频来帮助理解： https://youtu.be/SULqVPVXefY
典型的超融合存储 I / O 路径可分为以下重要的几层：
128

1. Guest OS (UVM) 到虚拟磁盘
o Nutanix 对此保持不变。 根据 hypervisor，guest OS 将使用设备驱动程序与虚拟磁盘设备进行对话。 取决于 hypervisor，它可以是 virtio-scsi（AHV），pvscsi（ESXi）等。虚拟磁盘也将根据管理程序而有所不同（例如，vmdk，vhd等）。
2. Hypervisor 到 Acropolis DSF (通过 CVM)
o Hypervisor 和 Nutanix 之间的通信是通过标准存储协议（例如 iSCSI，NFS，
SMBv3）在 CVM 和 hypervisor 的本地接口上进行的。 此时，所有通信都在该
主机本地执行（在某些情况下，I / O 将是远程的（例如，本地 CVM 关机等）。
3. Nutanix I/O 路径
o 对于 hypervisor 和 UVM 都是透明的，并且对于 Nutanix 平台是本地的。
下图显示了这些层 high-level 的关系：129

图. High-level I/O Path - Traditional

通信 和 I/O

130

在 CVM 中，Stargate 进程负责处理所有存储 I/O 请求以及与其他 CVM/物理设备的交互。存储设备控制器直接传递到 CVM，因此所有存储 I/O 都绕过 hypervisor。
下图显示了传统 I/O 的 high-level 路径：:

图. High-level I/O Path
在 5.18 中，引入 Nutanix BlockStore，以提供一个可扩展的文件系统层和块管理层，所有这些都在用户空间中处理。 这就从设备中删除了 Ext4，并消除了 Ext4 对内核驱动程序的调用。引入了新型的存储介质（例如 NVMe），设备利用户空间库直接处理设备 I / O（例如 SPDK），而无需进行任何系统调用（上下文切换）。 通过BlockStore + SPDK 的组合，所有 Stargate 设备交互都已移入到用户空间，从而消除了上下文交换或内核驱动程序的调用。

131

图. Stargate - Device I/O Path下图显示了使用 BlockStore + SPDK 更新的 I / O 路径的高级概览

图. High-level I/O Path - BlockStore
使用默认堆栈将调用内核级驱动程序来执行 CVM 跨网络通信进行数据复制。

132

但是，启用 RDMA 这些 NIC 绕过虚拟机管理程序中的任何内容传递到 CVM。
同样在 CVM 中，所有使用 RDMA 的网络流量仅使用内核级驱动程序作为控制路径，
然后所有实际数据 I / O 在用户空间中完成，而无需任何上下文切换。
下图显示了 RDMA 的 I / O 路径的高级概览：图. High-level I/O Path - RDMA
归纳一下，以下增强功能在如下方面做了优化：
1. PCI 直通绕过管理程序进行设备 I / O
2. SPDK + Blockstore 消除了内核存储驱动程序的交互，并将其移至用户空间
3. RDMA 绕过管理程序，所有数据传输均在 CVM 用户空间中完成Stargate I/O 逻辑
在 CVM 中，Stargate 进程负责处理来自用户 VM（UVM）和持久性（RF 等）
的所有 I / O。 当向 Stargate 发出写入请求时，有一个写入特征器，它将确定写是否
持久保存到 OpLog，Extent Store 或 AES 中。 同样对于读取，读取表征器负责处理
读取和管理缓存/预读。
Nutanix I / O 路径由以下高级组件组成：133

图. DSF I/O Path*从 AOS 5.10 开始，在满足必要条件时可以使用自治区存储（AES）来处理持续
的随机工作负载。
在全闪存节点配置中，扩展存储将仅由 SSD 设备组成，不会发生层 ILM，因为仅存在一个闪存层。 如果使用混合闪存（例如 NVMe，Intel Optane 等+ SATA
SSD），则性能最高的介质将是 Tier 0，而性能较低的介质将是 Tier1。对于混合（并非所有闪存）方案，闪存将是 第 0 层，硬盘为第 1 层。
OpLog
134

角色：持久性写缓存
描述：Oplog 类似于文件系统的日志（journal），用来处理突发的写操作，并聚合
这些写操作顺序地写到 Extent Store 中。为了保证数据高可用性的要求，在写操作完成（Ack）之前，数据写入 Oplog 的同时被同步复制到另一个 CVM 的 Oplog
中。所有 CVM 的 Oplog 都参与复制操作，并依据 CVM 负载情况自动选择。
Oplog 保存在 CVM 的 SSD 层以提供极高的 IO 写性能，特别是随机 IO 写操作。
对于顺序的 IO 写操作会直接写到 Extent Store 上而绕过 Oplog。如果数据当前在Oplog 中，所有的读请求会直接从 Oplog 中反馈，直到数据被合并推送到 Extent
Store 中后，只有当读的数据不在 Oplog 中,读请求才会从 Extent Store/Unified
Cache 中获得。如果在容器中的指纹（消重功能）被启用时，则所有写 IO 操作
时，数据块会被标记指纹，以便在数据进入 Unified Cache 时进行消重操作。
4.3.2.3.1

Per-vDisk OpLog Sizing

vDisk 的 Oplog 计算
Oplog 是共享资源，但分配是在 vDisk 基础上完成确保每个 vDisk 有均等机会。
这由每个 vDisk Oplog 限制（Oplog 中每个 vDisk 的最大数据量）实现。带有多
个 vDisk(s)的虚拟机可以使用每个 vDisk 限制乘以磁盘数量的 Oplog。
每个 vDisk Oplog 限制当前是 6GB（4.6 开始），以前版本最大 2GB。
由下面的 Gflag 控制：vdisk_distributed_oplog_max_dirty_MB。

Extent Store
角色：持久性数据存储
描述：Extent Store 是 DSF 中持久性大容量存储组件，它横跨 SSD 和 HDD，并且能扩展到其他节点的存储设备上。有两种数据流进入 Extent Store， 一种是从 Oplog 中被合并的数据顺序写入到 Extent Store，另外一中是绕过 Oplog 的顺序写操作直接写
入 Extent Store 中。Nutanix 的 ILM（information lifecycle management）基于 IO 类型（IO Pattern）动态决定数据保存的热分层位置，并且在不同热分层之间移动数据。
顺序写特征
当写到 vDisk 的并发写 IO 超过 1.5MB 时（4.6 开始），这个写 IO 就被认定为顺
序写。符合条件的 IO 会旁路 Oplog 直接到 Extent Store，因为大块对齐数据不会受益于 IO 合并。
由下面的 Gflag 控制：
vdisk_distributed_oplog_skip_min_outstanding_write_bytes。
所有其他 IO，包括较大的（例如，超过 64K）仍然由 Oplog 处理。

135Autonomous Extent Store (AES)•关键角色：持久数据存储•说明：自治扩展存储区（AES）是一种在 AOS 5.10 中引入的在扩展存储区中写入/
存储数据的新方法。 它利用了主要是本地+全局元数据的混合（在下面的“可伸缩元数
据”部分中有更多详细信息），从而由于元数据的局部性而实现了更加有效的持续性能。 对于持续的随机写入工作负载，这些负载将绕过 OpLog 并使用 AES 直接写入扩展存储区。 对于突发的随机工作负载，这些将采用典型的 OpLog I / O 路径，然后在可能的情况下使用 AES 排入扩展存储。 注意：从 5.11.1 开始，要启用 AES，该节点必须至少具有 8 个闪存设备，或者如果至少一个设备是 NVMe，则该节点必须具
有任意数量的闪存设备。
Unified Cache
角色：动态读缓存
描述:Unified Cache 是可消重的读缓存，它横跨 CVM 的内存和 SSD。当读取的数据不在缓存中（或基于一个特定的指纹），数据会放到 Unified Cache 的 Single-touch
池，该池完全保留在内存中，并且使用 LRU(最近最少使用算法)直到数据被弹出。如果后续有对该数据的读取操作，数据会被“移动”（其实没有实际的数据移动，移动的
只是数据的元数据（metadata）到 Multi-touch 池（Multi-toiuch 池跨内存和 SSD）中的内存段。这时开始，数据块具备 2 个 LRU，一个是其位于内存段的 LRU，如果
LRU 耗尽，则数据被移动到 Multi-touch 池的 SSD 段，并被赋予一个新的 LRU。如果数据再次被读取，则数据被移动到 Multi-touch 池的顶端，并重置其位于内存段的LRU。指纹标记可以在 Containter 层面通过管理 UI 进行配置。默认指纹标记被禁用。
下图是统一缓存中逻辑描述图：136

图. DSF 统一缓存缓存的粒度和逻辑：
数据是以 4K 粒度读进缓存的，所有缓存是实时完成的，没有延迟，也没有采用
批处理方式把数据读进缓存中。
每个 CVM 有它自己的本地缓存来管理本地 VM 的 vDisk，当一个 vDisk 被克隆
的时候（例如：新的克隆，快照等）每个新的 vDisk 都有自己对应的块，原有vDisk 标记为不改变。这可以确保每个 CVM 可以有自己的基于原 vDisk 的缓存
副本来确保缓存一致性。
当发生覆盖写的时候，会被重定向到 VM 自己的对应块中新的 extent。这确保了不会发生任何缓存崩溃。

Extent Cache
角色： 内存中的读缓存
描述：Extent Cache 是完全位于 CVM 内存中的读缓存。当指纹标记和消重被禁用时，它用来存储没有被标记指纹的 Extents。在 3.5 版本中 Extent Cache 和 content
Cache 是相互独立的，但在 4.5 版本这两个 Cache 被合并成统一的 Cache。

4.3.3 可扩展的元数据
你可以通过观看下面视频来帮助理解：https://youtu.be/MlQczJhQI3U
元数据（Metadata）是任何智能系统的核心，对于文件系统和存储阵列来说是至关重要的。在 DSF 中，有一些关键的结构来保证 DSF 扩展到超大规模数据量时依然可靠。
•

必须 100%时间里都是正确的（称为“强一致性”）

137

•
•
•

必须符合 ACID 策略
必须具有无限扩展性必须没有任何扩展性上的瓶颈（必须是线性扩展）

从 AOS 5.10 开始，元数据分为两个区域：全局元数据与本地元数据（之前所有元数
据都是全局的）。 这样做是对“元数据本地化”进行优化，并限制系统用于元数据查找
的网络流量。
这样更改的基础是因为并非所有数据都需要是全局的。 例如，每个 CVM 不需要知道
一个特定 extent 位于哪个物理磁盘上，他们只需要知道哪个节点保存该数据，而仅那个节点需要知道哪个磁盘具有该数据。
通过这样做，我们可以限制系统存储的元数据的数量（为仅本地数据消除元数据RF），并针对“元数据本地化”进行优化。
下图显示了全局元数据与本地元数据之间的区别：

图. Global vs. Local Metadata
本地元数据

•

说明：
o 每个 CVM 的本地元数据存储，其中仅包含本地节点所需的信息。 5.10 中引
入的自治区存储（AES）充分利用了这一点。

•

存储机制：
138

o AES DB（基于 Rocksdb）•

存储的数据类型：o 物理 extent / extent group 放置（例如，egroup 到磁盘的映射）等

全局元数据
l 说明：
o 元数据可全局供任何 CVM 使用，并在群集中的 CVM 之间分片。 5.10 之前的所有元数据。
l 存储机制：Medusa Store（基于 Cassandra）
l 存储的数据类型：o vDisk 块映射，extent 到节点的映射，时间序列状态，配置等。
以下部分介绍了如何管理全局元数据：
在上述架构章节中提到，DSF 使用一种“环状”的 Key-Value 结构的分布式数据库来保存重要的元数据和其它平台数据（例如 stats 等）。为了确保元数据的可用性和冗余度，也同样引入了复制因子（RF）。一旦一条元数据(Metadata)被写或者更新后，这条记录将同时写到“环”中的另一个节点，然后被复制到 n 个其他节点（n 决定与集群的大小）。集群中大多数（majority）节点同意之前确保所有信息一致，这就是强一
致性的 Paxos 算法。这确保了 Nutanix 平台数据的“强一致性”以及元数据作为平台的一部分进行存储。
下图显示了在一个 4 节点集群中，元数据的插入和更新操作：

139图.Cassandra 环形结构对于 DSF 的元数据数据库，集群扩展时的性能也是至关重要的。与传统的“双控”和主备模式不同，每个 Nutanix 节点只负责整个集群元数据中的一部分。这种方式消除了
传统的性能瓶颈问题，并且允许元数据被集群中所有节点共同维护。并且使用“一致性散列算法（Consistent Hashing）”来保证当节点数量变化时，需要被 remapping 的
元数据量最少。当节点数量从 4 增加到 8 个时，新节点将被插入到环中各个老节点之间，使用类似的 block 感知能力提供可靠性。
下图显示了环被扩展时的情况：

图.Cassandra 横向扩展

4.3.4 数据保护你可以通过观看下面视频来帮助理解： https://youtu.be/OWhdo81yTpk

140

Nutanix 平台使用复制因子（RF - Replication Factor/Resillience Factor）和校验
和（Checksum）来保证当节点或者磁盘失效时，数据的冗余度和可用性。按照上面
的解释，Oplog 作为暂存区来接受所有写操作，并保存到低延迟的 SSD 层上。当数
据写入本地 Oplog 时，数据被“同步”复制到另 1 个或者 2 个 Nutanix CVM 的 Oplog
之中（取决于 RF 设置），当这个操作完成之后，此次写操作才被确认（Ack）。这
样能确保数据至少存在于 2 个或者 3 个独立的节点上，保证数据的冗余度。注：当RF 为 3 时，至少需要 5 个节点，并且元数据（metadata）数据会保留 5 份（RF5）。
为每部分数据（1GB 的虚拟磁盘数据）选择 OpLog 对等体，并且所有节点都积极参与。 选择对等体的多个因素（例如响应时间，业务，容量利用等）。 这消除了零碎并确保每个 CVM / OpLog 可以同时使用。
用户数据的 RF 是通过 Prism 在容器层面进行配置。所有节点都参与 Oplog 的复
制操作，这样能消除“热点节点”，并保证线性的性能扩展。当数据被写入时，同时计算该数据块的校验和，并且作为数据块元数据中的一部分进行存储。随后数据块在保证满足 RF 的前提下，被“异步”推送到 Extent Store 中。当发生节点或者磁盘失效，
数据块会重新在所有节点间进行复制以满足复制因子的设置。任何时候，读取数据块并同时计算其校验和以确保数据块有效。当数据块检查结果不匹配校验和时，副本数
据将会覆盖该无效数据块。
即使未发生活跃 I / O，数据也始终被监视以确保完整性。 Stargate 的擦洗器操作将持续扫描扩展区组，并在磁盘未被大量使用时执行校验和验证。 这可以防止比特腐烂或坏扇区。
下图显示了这一过程的逻辑图：

图. DSF 数据保护4.3.5 可用域（机箱感知）你可以通过观看下面视频来帮助理解：https://youtu.be/LDaNY9AJDn8141

可用域（也称为节点/机箱/机架感知）是分布式系统的关键结构，以遵守组件和
数据放置的决定。DSF 现在是节点和机箱感知的，然而，随着集群规模的增长，需要提升到机架感知。Nutanix 说的 block 是指一个机箱，包含一个，两个或者四个服务器节点。注：如果需要实现机箱感知，最少需要 3 个机箱，否则缺省是节点感知。
Nutanix 目前支持以下级别的感知模式:l 磁盘(所有版本)l 节点(所有版本)
l 硬件设备(AOS 4.5 以上)
l 机柜(AOS 5.9 以上)
建议使用统一的较新的机箱来保证机箱感知是允许的。通常的场景和使用的感知级别能够在本章末找到。需要 3 个机箱是用于确保符合规定要求(quorum)。例如，
3450 是一个拥有 4 个节点的机箱。把角色和数据分散到不同机箱的原因是确保当一
个机箱故障或需要维护时，系统可以不中断地持续运行。注：在一个机箱里，冗余的电源和风扇是仅有的共享组件。
注意:机架感知要求管理员定义设备硬件设备所在的“机架”。
下图现实了如何在 Prism 里进行配置：

图. 机柜配置

机柜感知可以分为以下几个关键领域：l

数据（虚拟机数据）lMetadata（Cassandra）

142

l

配置数据（Zookeeper）

数据

DSF 的数据副本将会被写到集群中的其它机箱以保证当一个机箱故障或者计划
停机时，数据仍然可用。这适用于 RF2 和 RF3，以及在机箱故障的场景。一个简单的比较是节点感知，当一个节点故障时，副本将被复制到另外的节点以提供保护。机箱感知进一步增强了，当机箱故障时提供数据的可用性保证。
下图展示了在一个 3 机箱的部署中副本如何放置的例子：

图. 机箱感知的副本放置
当机箱故障时，机箱感知将被维持，副本将重新复制到其他机箱中：143

图. 机箱故障情况下的副本放置
机架/硬件设备感知与 Metro 集群

一个常见的问题是，您能否跨两个位置(房间、建筑物等)跨集群，并使用硬件设备/机柜感知来提供位置故障的弹性。
虽然在理论上这是可能的，但这并不是推荐的方法。让我们先思考一下我们想要实
现什么:
1.
低 RPO
2.
低 RTO (HA 事件而不是 DR 事件)
如果我们以第一种情况为例，即我们试图实现 RPO ~0，那么最好利用同步或准同步复制。这在获得相同的 RPOs 的同时，风险更低。
为了最小化 RTO，可以在同步复制的基础上利用 Metro 集群，并将任何故障作为
HA 事件处理，而不是执行 DR 恢复。
总体来说，利用同步复制/城域群集，是出于以下原因：144•通过同步复制/城域集群可以达到相同的最终结果，避免任何风险并保持故障域的隔离。
•在不受支持的“延伸”部署中，如果两个站点之间的网络连接断开，一侧将停止运行，这是因为必须维持仲裁（例如，主导方将保持运行）。在城域集群应用场景中，两边站点可以继续独立运行。
•在故障场景中，数据的可用性域放置是尽力而为的•两个站点之间额外的延迟/的网络带宽减少会影响“延伸”部署群集的性能
感知条件和容错

下面我们划分为一些通用的场景以及哪个级别的容错将被使用：动态感知类型FT 级别

是否打开纠删

最小单元

容忍同时失效

节点

1

否

3 节点

1 节点

节点

1

是

4 节点

1 节点

节点

2

否

5 节点

2 节点

节点

2

是

6 节点

2 节点

机箱

1

否

3 机箱

1 机箱

机箱

1

是

4 机箱

1 机箱

机箱

2

否

5 机箱

2 机箱

机箱

2

是

6 机箱

2 机箱

机柜

1

否

3 机柜

1 机柜

机柜

1

是

4 机柜

1 机柜

机柜

2

否

5 机柜

2 机柜

机柜

2

是

6 机柜

2 机柜

作为 Acropolis 基础软件版本 4.5 及以后，机箱感知是尽力而为的，不会强制启用。这样可以确保存储资源不平衡（例如，重存储节点）不会关闭该功能。当然，使用统一一致的机箱最小化存储不平衡仍然是最佳实践。
145

4.5 以前，下列必须满足下列条件：
如果 SSD 或者 HDD 层在不同机箱间的差别>最大方差：节点感知n

如果 SSD 或者 HDD 层在不同机箱间的差别<最大方差：机箱+节点感知

最大方差计算：100/(RF+1)，例如 RF2 是 33%，RF3 是 25%

元数据

正如在可扩展的元数据一章提到的，Nutanix 利用一个深度修改过的 Cassandra
平台来存储元数据和其它重要的信息。Cassandra 利用一个环形架构，复制到环里 n个对等（peer）来保证数据的一致性和可用性。
下图显示了一个 12 节点集群的 Cassandra 环的例子：

图. Cassandra 节点环
Cassandra 对等复制在整个环里用顺时钟的方式迭代到各节点。在机箱感知下，
对等（peer）会分布到机箱里，确保没有两个对等会在同一个机箱里。
下图显示了一个节点布局按照上述环形转换到机箱布局的例子：

146

图. Cassandra 节点块感知放置
在机箱感知特性下，即使发生机箱故障的情况下，仍然有至少两份数据副本（元数据 RF3，在大型集群可以利用 RF5）。
下图显示了所有节点复制拓扑形成环的例子147

图. 全 Cassandra 节点块感知放置
下图显示了 3 个 Zookeeper 节点分布在一个机箱感知的方式的例子：

148

配置数据

元数据感知条件
下面我们看一下一些常见的场景和那个级别的感知会被使用：l

FT1（数据 RF2/元数据 RF3）将会是机箱感知，如果：
n

>3 机箱

n

X 代表机箱最大节点数，剩余机箱的节点数最少有 2X 个

例 1：4 个机箱分别有 2，3，4，2 个节点，不会机箱感知，因为 2+3+2<2*4
最大节点的机箱有 4 个节点，其他三个机箱需要有 2x4 (8)个节点。如果剩下的只有 7 个节点的情况下
就不会触发机箱感知。
例 2：4 个机箱分别有 3，3，4，3 个节点，机箱感知，因为 3+3+3>2*4
最大节点的机箱有 4 个节点，其他三个机箱需要有 2x4 (8)个节点。如果剩下 9 个节点的情况下会触发
机箱感知。
l

FT2（数据 RF3/元数据 RF5）将会机箱感知
n

>5 机箱

n

X 代表机箱最大节点数，剩余机箱的节点数最少有 4X 个

例 1:6 个机箱分别有 2,3,4,2,3,3 个节点，不会机箱感知，因为 2+3+2+3+3<4*4
最大节点的机箱有 4 个节点，其他三个机箱需要有 4x4 (16)个节点。如果剩下的只有 13 个节点的情况
下就不会触发机箱感知。
例 2:6 个机箱分别有 2,4,4,4,4,4 个节点，机箱感知，因为 2+4+4+4+4>4*4
最大节点的机箱有 4 个节点，其他三个机箱需要有 4x4 (16)个节点。如果剩下 18 个节点的情况下会触发机箱感知。

配置数据149

Nutanix 利用 Zookeeper 来存储集群里必要的配置数据。这些角色也使用机箱感知的方式进行分布以确保机箱故障时仍然可用。
下图显示了一个启用机箱感知时 3 个 Zookeeper 节点分布情况的例子：

图 . Zookeeper 块感知放置在一个机箱失效的事件里，意味着其中一个 Zookeeper 节点没有了，ZooKeeper 的
角色将会被转移到集群里的另外一个节点上，如下图示：150

图. Zookeeper 块放置失败当这个机箱恢复正常上线后，Zookeeper 角色将会被转移回来，以维持机箱感知。
注：4.5 版本前，迁移需要手工方式，不能自动进行。

4.3.6 数据路径冗余你可以通过观看下面视频来帮助理解：https://youtu.be/SJIb_mTdMPg
可靠性和弹性是 DSF 或者任何主要存储平台设计的关键。
传统的架构是基于硬件应该是可靠的思路建设的，相反，Nutanix 使用一个不同
的方法，它认为硬件始终会出故障的。基于此，系统设计使用简洁和不中断的方式来处理这些故障。
注：但这并不意味着 Nutanix 的硬件质量不过关，只是概念的转变。Nutanix 硬件和品质部门一直致力于高质量和审核过程。
在之前的章节提到过，元数据和数据使用集群故障冗余级别的复制因子进行保护。5.0 支持 FT1 和 FT2 的故障冗余等级，分别对应元数据 RF3 和数据 RF2，或者
元数据 RF5 和数据 RF3。
要了解更多关于元数据如何切片的内容请参考之前的“可扩展元数据”章节。要了解更多关于如何保护数据的内容请参考之前的“数据保护”章节。
在通常状态中，集群数据摆放类似于下图：151

图. 数据链路冗余- Normal State

正如看到的，虚拟机 vDisk 数据在磁盘上有 2 份或者 3 份拷贝，分布在节点之间
和相关联的存储设备之间。
数据分布的重要性
依靠保证元数据和数据跨所有节点和所有磁盘设备分布，可以在通常的数据处
理和重新保护时保证最高性能。
当数据进入系统，主拷贝和副本拷贝会分布在本地和所有其他远程节点。这样
就消除了潜在热点（例如运行缓慢的节点和磁盘），并确保一致的写性能。
在数据磁盘或者节点故障时数据必须被重新保护，集群的全部能力都可以被用
来重建。在重建事件里，元数据扫描（找出故障设备上的数据和副本的位置）
平均分布在所有 CVM 上。一旦数据副本被所有健康 CVM 发现，磁盘设备（SSD＋HDD）和主机网络上联链路可以被用来并行重建数据。
例如，在一个有磁盘故障的 4 节点集群中，每个 CVM 会处理 25%的元数据扫
描和数据重建。在一个 10 节点集群中，每个 CVM 处理 10%的元数据扫描和
数据重建。在一个 50 节点集群中，每个 CVM 会处理 2%的元数据扫描和数据
重建。
关键点：使用 Nutanix，确保数据的一致性分布可以保证一致的写性能和极其优秀的重新保护时间。这也会应用到任何集群范围的活动（例如纠删码，压缩，重删等）。
对比其他解决方案，使用 HA 对或者单个磁盘保存所有数据的完整拷贝，如果镜像的节点／磁盘遭受压力（面对重 IO 或者资源受限）会面临前端性能问题。
而且，在数据必须被重新保护的故障事件中，这些方案会受限于单个控制器，
单个节点的磁盘资源和单个节点网络上联链路。当 TB 级数据必须被重新保
护，这会严重受限于本地节点的磁盘和网络带宽，增加系统停留在潜在的由于
其他故障发生导致数据丢失状态的时间。

潜在故障的级别

152

作为分布式系统，DSF 是基于处理组件、服务和 CVM 故障而构建的，可以分为如下
几个级别：
l

磁盘故障

l

CVM 故障l

节点故障什么时候重建开始？
当出现计划外故障时（在某些情况下，如果它们无法正常工作，我们
将主动将其置于脱机状态），我们立即开始重建过程。
与其他一些等待 60 分钟开始重建并且在此期间仅保留一份副本的供应商不同（风险很高，如果出现任何类型的故障，可能会导致数据丢失），我们不愿意牺牲这种风险 更高的存储利用率我们可以这样做是因为 a）我们的元数据的粒度 b）动态地选择用于
写入 RF 的对等体（当出现故障时，所有新数据（例如新写入/覆盖）保持
其配置的冗余）和 c）我们可以处理事物 在重建期间重新联机并在数据经
过验证后重新接收数据。 在这种情况下，数据可能会“过度复制”，其中Curator 扫描将启动并删除过度复制的副本。

磁盘故障

磁盘故障的特点是磁盘被拔掉、磁盘彻底坏了或者由于 I/O 出错被主动地删除。
当 Stargate 看见 I/O 错误或者经过一段时间磁盘没有响应，该磁盘将被标记下线 。
一旦发生上述情况，Hades 将运行 S.M.A.R.T.并检查设备状态。如果测试通过磁盘会被标为在线，如果失败会保持离线状态。如果 Stargate 多次标记一个磁盘下线（每小时 3 次）, 即使 S.M.A.R.T. 通过测试，Hades 仍会停止再次标记磁盘在线。
虚拟机影响：l

HA 事件：没有lI/O 失败：没有l

延迟：没有影响

当出现磁盘故障时，会立即触发一个 Curator 扫描（MapReduce 框架）。将会扫描元数据（Cassandra）以发现故障磁盘上的数据和哪些节点/磁盘拥有副本。
一旦发现数据需要重新复制，它会把复制任务分派到整个集群的节点。
当有坏盘或 SMART 日志监控到错误的时候，磁盘自查 Drive Self Test (DST)的进程
被启动。
下图显示了磁盘故障和重新保护的例子：

153

图. 数据链路冗余 – 磁盘故障一个重要的事情需要在这里强调的是鉴于 Nutanix 把数据和副本分散到所有节点
/CVMs/磁盘，所有节点/CVMs/磁盘将参与到重新复制中。
这样实质上减少了重新回到保护状态的时间，因为可以利用整个集群的能力。集群越大，越快回到保护状态。
节点故障虚拟机影响：l

HA 事件：发生l

I/O 失败：没有l

延迟：没有影响

如果一个节点失效了，虚拟机 HA 机制将启动，将会在另外的节点上重新启动虚拟机。一旦被重新启动，虚拟机将在本地 CVM 接管下继续提供服务。类似于磁盘失效，Curator 扫描将发现失效的数据节点和冗余的数据节点。与磁盘失效类似，节点失效也会在所有正常的集群节点内实现被保护数据的再平衡。
当节点故障持续相当长的时间，失效的 CVM 将被从元数据环中删除，当节点恢复和稳定一段时间后，CVM 将被重新加回环中。

154

图. 数据链路冗余– 节点故障如果延长一段时间后（在 4.6 版本是 30 分钟）节点仍然故障，故障的 CVM 将会
被从元数据环上移除。它恢复并稳定一段时间后会被重新加入环。
专家提示
数据可靠性状态会在 Prism 的主页面显示
您也可以通过 cli 查询数据冗余性状态：# Node status
ncli cluster get-domain-fault-tolerance-status type=node# Block status
ncli cluster get-domain-fault-tolerance-status type=rackable_unit这将是最新更新过的数据，但是您可以发起 Curator 半扫描重新刷新这个数据。

CVM 故障CVM 故障的特点是由于 CVM 的权利行为引起 CVM 临时不可用。系统设计本身可以很好的透明地处理这些故障。当 CVM 故障时，I/O 将被重定向到集群的其它 CVM。
具体机制因 Hypervisor 不同而各异。CVM 的滚动升级过程实际上是利用了这个能力，每次升级一个 CVM，迭代到整个集群。
虚拟机影响：l

HA 事件：没有lI/O 失败：没有155

l

延迟：由于 I/O 经过网络，潜在的高延迟

在出现 CVM 故障的时候，由原来故障 CVM 处理的 I/O 将会被转发到集群里的其它 CVM 上。ESXi 和 Hyper-V 是通过一个叫 CVM 自动路径的进程来处理的，利用
HA.py(比如”happy”)，修改路由，把发送到内部地址（192.168.5.2）的数据包转发到
集群里其它 CVM 的外部地址。这样使得数据存储保持原封不动，只是 I/O 由远程
CVM 来处理。
一旦本地 CVM 恢复正常并且稳定了，路由将被删除，本地 CVM 也将接管新的I/O。
对于 KVM，是利用 iSCSI 多路径技术，主路径是本地 CVM，另外两个路径是远
程。当主路径故障时，其中一个远程路径将被激活。
类似于 ESXi 和 Hyper-V 的自动路径技术，当本地 CVM 恢复正常后，本地 CVM 将
接管成主要路径。

4.3.7 容量优化
Nutanix 平台集成了多种存储优化技术并协同工作，使任何工作负载的可用容量
被有效利用，这些技术具备智能和自适应的工作特性，消除了需要手动配置和微调。
下面是一些集成的优化技术：
l

纠删码

l

压缩

l

消重

有关如何在以下各节中找到这些功能的更多详细信息。
该表描述了哪些优化适用于高级工作负载：
数据转换
纠删码

应用
所有

在线压缩

所有

离线压缩

无

说明
在不影响正常写入或读 IO 性
能的同时提供比传统的 RF 更
高的可用性，且降低开销。在磁盘/节点/块故障的情况下，
同时数据必须被解码的情况下有一些读的开销
不影响随机 IO，有助于提高存储层利用率。通过减少数据从磁盘复制和读取，有利于大的 IO 或顺序的 IO 性能
在线压缩将仅仅压缩大的或连续的写入，而随机或小的 IO/
应该采用离线压缩处理

156

Perf Tier 消重P2V/V2V,Hyper-V(ODX),Cross-container
clones

容量层消重P2V/V2V,Hyper-V(ODX),Cross-container
clones为没有克隆或通过采用
Acropolis 克隆的数据提供更大的缓存效率拥有上面的好处同时，减少在磁盘上的开销

纠删码

Nutanix 平台依赖于 RF 来保护数据和可用性，这个方法提供了最高程度的可用性，因为当数据失效时，不需要从其他存储位置或者重新计算来读取。然而，由于需
要完全复制，存储资源的成本比较高。
为了提供一个可用性和降低存储容量的平衡，DSF 提供了使用纠删码（EC）来对数据进行编码。
和 RAID（级别 4，5，6 等）的概念相似，校验位是计算出来的。EC 对不同节
点上的数据块条带进行编码和计算校验位。当主机或者磁盘故障时，校验位可以被利
用为计算任何缺失的数据块（解码）。在 DSF 里，数据块是一个 extend 组，每个数据块必须在不同的节点上，属于不同的 vDisk。
对于冷读取的数据，我们将更倾向将来自同一 vDisk 的数据块分布在各个节点
上，以形成数据条带（相同 vDisk 数据条）。这简化了 garbage collection（GC），
因为在删除 vDisk 的情况下可以删除整个条带。对于读取的热数据，我们更倾向将
vDisk 数据块保留在节点本地，并使用来自不同 vDisk 的数据（跨 vDisk 条）组成该
数据条。由于本地 vDisk 的数据块可以是本地的，其他 VM / vDisk 可以组成条带中的
其他数据块，因此可以最大限度地减少远程读取。如果读取的冷数据条变热，系统将尝试重新计算该数据条并本地化数据块。
条带中数据和奇偶校验块的数量可根据所需的容忍故障进行配置。该配置通常称为<数据块数> / <奇偶校验块数>。
例如，RF2 级别的可用性（N+1）在一个条带里能够包括 3 个或者 4 个数据块和
一个校验数据块（例如 3/1 或者 4/1）。RF3 级别的可用性（N+2）在一个条带里能
够包括 3 个或者 4 个数据块和两个校验数据块（例如 3/2 或者 4/2）。
EC +机箱感知从 5.8 开始，EC 可以以块感知方式放置数据和奇偶校验块（在 5.8 之前，这是在节点级别完成的）。
升级到 5.8 后，现有的 EC Containers 不会立即更改为阻止阻止的放置。如果集
群中有足够的块（条带大小（k + n）+ 1）可用，则这些以前的节点感知带将移动到块感知。新的 EC Containers 将构建块识别 EC 条。
预期的消耗可以用校验块数量/数据块数量来计算。例如，一个 4/1 的条带有 25%的消耗，或者是 1.25*（RF2 是 2*）。一个 4/2 条带有 50%的消耗或者是 1.5*（RF3 是
3*）。
下表是列出了常见条带大小和消耗的例子：

157

FT1 (RF2 equiv.)

FT2 (RF3 equiv.)

Cluster Size
(nodes)EC Strip Size(data/parity blocks)

EC Overhead(vs. 2X of RF2)

EC Strip Size(data/parity)

EC Overhead(vs. 3X of RF3)

4

2/1

1.5X

N/A

N/A

5

3/1

1.33X

N/A

N/A

6

4/1

1.25X

2/2

2X

7

4/1

1.25X

3/2

1.6X

8+

4/1

1.25X

4/2

1.5X

专家提示：
强烈建议集群里节点的数量要比条带大小组合（数据块数量+校验块数量）
至少加一，以便当节点故障时可以重建条带。这样避免了条带重建时（由Curator 自动进行）产生的计算过载。例如，一个 4/1 条带应该在集群里至少有 6 个节点。上面的表格是按照最佳实践得出来的。

编码是事后进行的，利用编码是在后处理过程中完成的，并利用策展人
MapReduce 框架进行任务分发。由于这是一个后处理框架，传统的写 I/O 路径不受
影响。
一个正常使用 RF 的环境看起来像这样的：158

图.典型 DSF RF 数据结构
在这个场景里，我们有混合 RF2 和 RF3 数据的集群，主数据块在本地，副本数据块
在集群的其它节点上。
当 Curator 运行完全扫描时，它会发现合适的 extend 组可以被编码的。合适的extend 组必须是“写冷的”，也就是它们写入超过一个小时以上。在合适的 extend 组被发现后，编码的任务将通过 Chronos 分发和控制。
下图展示了一个 4/1 和 3/2 条带的例子：

图.DSF 编码条带化- 保存前
一旦数据被成功地编码（条带和校验计算后），extend 组的副本将被删除。
下图展示了运行 EC 节省存储空间后的环境：159

图. DSF 编码条带化- 保存后
专家提示：纠删码和在线压缩可以完美地结合使用，大大节省存储空间。
在我们的环境里，总是利用压缩+EC 配置。
压缩你可以通过观看下面视频来帮助理解：https://youtu.be/ERDqOCzDcQY
Nutanix 容量优化引擎（COE）负责数据的转换来增加磁盘中数据的效率。目前
压缩是 COE 实现数据优化的一项关键特性。DSF 提供在线和离线两种压缩方式以满足客户的需求和不同数据类型。5.1 后, 离线压缩被默认开启。
当写数据到 Extent Store（SSD+HDD）时，在线压缩会压缩顺序数据流或者大 I/O（大于 64K）。包含从 Oplog 落下来的数据和不使用 Oplog 的顺序数据。
OpLog 压缩截至 5.0 版本，Oplog 现在压缩所有进入的大于 4K 的写，并表现出良好的压缩效果（Gflag: vdisk_distributed_oplog_enable_compression）。这样会更有效的利用 Oplog 空间并提升实际性能。
当数据从 Oplog 落入 Extent Store 会被解压缩、对齐并被按照 32K 对齐的尺寸重新压缩。
（截至 5.1 版本）
本特性缺省开启，不需要用户配置。

离线压缩开始按照正常方式写数据（以不压缩状态），然后借助 Curator 框架在集群范围压缩数据。当在线压缩开启但是 I/O 都是随机数据，数据会以未压缩的状态写入 Oplog，归
并，然后在内存中压缩后写入 Extent Store。

160

Nutanix 利用 LZ4 和 LZ4HC 通过 AOS 5.0 及更高版本进行数据压缩。在 AOS 5.0 之前的版
本中，谷歌使用 Snappy 压缩库，该库可提供良好的压缩率，最小的计算开销和极快的压缩/解压缩速率。 正常数据将使用 LZ4 压缩，这在压缩和性能之间提供了很好的融合。对于冷数据，将利用 LZ4HC 提供更高的压缩比。
以下两个类型被归类为冷数据：
正常数据：
l 三天没有读写访问（Gflag: curator_medium_compress_mutable_data_delay_secs）
不可更改数据（快照）
l 一天没有访问（Gflag: curator_medium_compress_immutable_data_delay_secs）

下面图示展现了一个在线压缩和 DSF 写 I/O 通道如何交互的例子：

图.在线压缩 I/O 路径
专家提示：建议总是使用在线压缩（压缩延迟=0），它只压缩大的/顺序写，不影响随机写的性能。
这也将增加 SSD 层的可用容量，增加有效性能并允许更多数据放置在 SSD 层。而且，对
于写入并在线压缩的大的或者顺序数据，用于 RF 的复制也会传输压缩过的数据，由于在网络上发送更少的数据而进一步增强性能。
在线压缩也完美地和纠删码配合使用。

161对于离线压缩，所有新的写 I/O 按照正常 DSF 的 I/O 通道没有压缩地写入。当压缩延迟（可配置）到达后，数据才有资格被压缩。压缩可以发生于 Extent Store 的任何地方。离线压缩使用 Curator 的 MapReduce 框架，所有节点将参与压缩任务。压缩任
务将被 Chronos 控制。
下图展示了一个离线压缩和 DSF 写 I/O 通道如何交互的例子：

图. 离线压缩 I/O 路径
对于读 I/O, 数据首先在内存解压缩之后 I/O 被读取。
你可以从 Prism 上，在存储>仪表盘页面上看到当前压缩率。
弹性消重引擎

你可以通过观看下面视频来帮助理解：https://youtu.be/C-rp13cDpNw
162

弹性消重引擎是 DSF 中一个基于软件的特性，它允许在容量层面（HDD）和性能层
面（SSD/内存）对数据进行消重操作。顺序的数据流在写入（ingest）时，按照
16KB 粒度进行 SHA-1 的散列（hash）运算标记指纹。指纹标记操作仅在数据块被
写入（ingest）的时候进行，并作为该数据块的元数据信息的一部分被持久保存。注
意：最初采用 4KB 粒度进行指纹标记，然而经过测试， 16KB 粒度的指纹标记操作
能在消重能力和减少元数据(metadata)开销之间取得最好的平衡。当已消重数据进入
unified cache 之后，将以 4KB 粒度进行消重。
传统消重操作需要在后台进行数据块扫描，数据被重新读取并开销大量系统资源，Nutanix 在写入时执行在线的指纹标记操作。消重时，外部存储上重复数据块可以被直接删除，而无需重新读取和计算指纹。
为了使元数据更加高效率，指纹标记参考计数被监控来跟踪可消重能力。参考计数低的指纹计数将被丢弃以减少元数据的过载。为最小化碎片，完全 extents 是用于在容
量层面的消重首选.
下图显示了弹性消重引擎如何扩展和处理本地虚拟机 I/O 请求的：专家提示：
对基本影像（Base images）使用性能层面的消重会利用内容缓存的优势。
（你可以手工对它们进行指纹标记，使用 vdisk_manipulator）。
当使用 Hyper-V 时（由于 ODX 实行完全数据拷贝），或者进行跨容器的克隆时（通常不建议，因为最好是一个容器），使用容量层面对 P2V/V2V 消重。
在大部分其它案例，压缩是节省容量最大的，应该建议使用。

图.弹性消重引擎 - 扩展性指纹标记操作是在数据写入大小为 64KB 或更大时发生，Intel 的加速器能使得 SHA1 的计算增加的额外 CPU 开销最小。如果数据不是持续写入（eg. 小 IO 操作），将不进行指纹标记操作，此时指纹标记操作将在后台发生。弹性消重操作不仅发生在磁
盘层面（HDD），并且也发生在高性能的存储层面（SSD/Memory）。当确定了哪些重复数据后，即基于相同指纹的多份数据，一个后台进程会使用 DSF 的 MapReduce
框架（curator）来移除重复数据。
163

由于标记指纹的数据已经被读取，会被保存在 DSF 的 Unified Cache 中（这是 multitier/pool cache）。任何后续对于同样指纹的数据请求将直接从 Cache 层面响应。要了解统一缓存和池架构，请参考 I/O 路径概览章节相关内容。

专家提示：指纹标识 vDisk Offsets
在 4.5 之前，只有 vDisk 的前 12GB 可以被指纹标识，这是用来维护一个较小的
元数据指纹标识并且由于 OS 通常是最普通的数据。4.5 之后，增加到 24GB，因为元数据更加高效。

下图显示了弹性消重操作如何优化 IO 操作：图 . 弹性消重引擎 I/O 路径164你可以从 Prism 上的存储>面板页查看当前的消重率。
专家提示：消重+压缩
在 4.5 版本，消重和压缩都可以在一个容器里启用，但是，除非数据是可以被消重的（条件在之前的章节里解析过），坚持使用压缩。

4.3.8 存储分层和优先级在磁盘平衡章节我们谈到了如何将集群内所有节点的磁盘容量作为存储池统一管理，并且通过 ILM 实现热数据本地化。简单而言，磁盘的分层是实现在集群内所有节点的SSD 和 HDD 上，并且由 ILM 负责触发数据迁移。本地节点的 SSD 层总是最高优先级的，负责所有本地虚拟机 I/O 的读写操作。并且还可以使用集群内所有其他节点的
SSD，因为 SSD 层总是能提供最好的读写性能，并且在混合阵列中尤为重要。
下图显示了热分层优先级顺序：图. DSF 层级优先顺序特定类型的存储资源（eg. SSD, HDD,等）在集群范围内被池化统一管理，形成集群
范围的存储分层。这意味着集群内任何节点都可以使用到整个存储分层，无论这一存
储资源在本地还是在其他节点上。
下图显示的时池化后的集群分层示意图：165

图. DSF 集群范围内的分层
一个经常被问到的问题就是：如果节点本地的 SSD 被用满之后，性能是否会下降？
之前我们提到使用磁盘平衡功能会保证集群范围内所有磁盘的利用率基本一致。那么
当本地 SSD 利用率非常高时，磁盘平衡功能会自动迁移 SSD 中最冷的数据到集群内另一个节点的 SSD 上。这将释放本地 SSD 的空间，数据会继续写到本地 SSD 上，
而不会因为通过网络写到另一个节点的 SSD 上而导致性能下降。一个关键点需要提及的是所有 CVM 和 SSD 都参与这种远程 IO 操作，可以消除潜在的瓶颈，并且通过执行远程 IO 操作可以自愈一些命中率的问题。

图. DSF 集群内的分层均衡另一种情况是当存储利用率到达一定的阈值（curator_tier_usage_ilm_threshold_percent，默认是 75），DSF ILM 将介入并作
为 Curator 框架的一个工作，并将数据从 SSD 上迁到 HDD 上。这会清空超过上述阈值的空间，或者通过参数（curator_tier_free_up_percent_by_ilm，默认是 15）清空
数据空间，这两个阈值取较大的那个。
迁移数据是使用最后访问时间来判断。例如当 SSD 利用率到 95%，那么将有 20%
的数据会被移动到 HDD（95% -> 75%），如果 SSD 利用率时 80%，则只有 15%的数据会被移动到 HDD。

166

图. DSF 层级 ILM
DSF 的 ILM 也会持续监控 I/O 类型数据分布和必要的数据迁移（向下/向上），使最热的数据本地化。

4.3.9 磁盘平衡
你可以通过观看下面视频来帮助理解：https://youtu.be/atbkgrmpVNo
DSF 被设计成为非常动态的平台，可以适用于不同工作负载的应用，并且允许混合
节点类型：例如将计算密集型（3050 系列）和存储密集型（60X0 系列）混合在一个
集群中。对于集群内部磁盘容量大小不同的，确保数据一致的分布非常重要。
DSF 有自带的称为磁盘平衡的技术，用来确保数据一致的分布在集群内部各节点上。磁盘平衡功能与各节点的本地磁盘利用率和内置的 DSF ILM（数据生命周期管理）一同工作。它的目标是一旦利用率超出设定阈值时，使得所有节点的磁盘利用率
大致相等。
注意：磁盘平衡作业由 Curator 处理，后者对 Primary I / O（UVM I / O）和background I / O 具有不同的优先级队列（例如，磁盘平衡）。 这样做是为了确保磁
盘平衡或任何其他后台活动不会影响前端延迟/性能。 在这种情况下，工作的任务将交给 Chronos，后者将限制/控制任务的执行。 此外，移动只会在同一层内完成以实
现磁盘平衡。 例如，如果我的数据在 HDD 层中出现不平衡的情况，则我将在同一层
(HDD)的节点之间移动。
下图显示了一个混合集群（3050 系列+6000 系列）的不平衡状态：167

图. 磁盘均衡 - 非平衡状态
磁盘平衡功能使用 DSF 的 Curator 框架作为调度进程，当磁盘阈值被触发时，在后
台自动运行（例如，当本地节点利用率超过 n%后自动运行）。当数据不平衡时，
Curator 会决定哪些数据移动到哪里，并自动生成 MapReduce 任务分发到各节点执行。例如，集群各节点同样都是相同型号（例如，3050 系列），每个节点的利用率
应该基本一致。
然而，当一些 VM 写了过多的数据，导致该 VM 数据快速增长，使得该节点磁盘利用率高于其他节点。此时磁盘平衡功能可以将该节点上最冷的数据移动到其他节点上，保证所有节点磁盘利用率达到基本平衡的状态。例如，集群各节点时不同型号（例如，3050+6020/50/70 系列），或者一些节点仅作为存储节点使用(不运行 VM)时，可能会触发磁盘平衡功能。
下图显示了一个混合集群在磁盘平衡后的“平衡”状态：

图. 磁盘均衡 - 平衡状态168

在一些情形下，客户可能希望将一个节点只作为存储使用，则这个节点上将没有虚拟机运行，它的主要功能作为大容量存储设备使用。在这种情况下，节点上所有内存都
可以给到 CVM 使用，来提供更大的读缓存。
下图显示了混合集群中包含仅存储节点，并使用“磁盘平衡”功能后数据从活动虚拟机节点移动到它上的情况：

图. 磁盘均衡 - 单纯的存储节点

4.3.10快照和克隆

你可以通过观看下面视频来帮助理解：https://youtu.be/uK5wWR44UYE
DSF 内置支持快照和克隆的卸载(offload)，能够利用 VAAI, ODX, ncli, REST, Prism
等进行快照和克隆。快照和克隆均利用最有效和高效的写时重定向（redirect-onwrite）算法。正如在上述数据结构章节解析的，一个虚拟机构成的文件（vmdk/vhdx）在 Nutanix 平台是 vDisks。
vDisk 是由 extend（逻辑上连续的数据块）构成，extend 存放在 extend 组里，extend 组是物理上连续的数据，在存储设备里以文件形式存放。当快照或者克隆发
生时，基础 vDisk 被标识为不可改变的，创建另外一个 vDisk 为可读写。这时候，两个 vDisk 都有相同的数据块映射，它是 vDisk 到相应 extend 的元数据映射。传统的
方法需要遍历快照链(增加读延迟)，而现在每个 vDisk 有它自己的数据块映射。这样
就消除了常见的很深的快照链的过载，允许你持续地进行快照而不影响性能。
下图显示了快照是如何进行工作的例子：

169

图. 快照块映射实例当一个 vDisk 的快照和克隆继续进行快照和克隆时，采用相同的方法：

图.多重快照块映射和新的写入

采用相同的方法进行虚拟机和 vDisk 的快照和克隆。当一个虚拟机或 vDisk 进行克隆
时，当前的块映射被锁定，克隆被创建出来。这些更新仅仅是元数据，没有 I/O 实际发生。相同的方法应用到克隆的克隆；之前克隆的虚拟机充当被克隆的“基础vDisk”，数据块映射被锁定，2 个克隆被创建：一个给正在被克隆的虚拟机，另外一个给新的克隆。
它们均继承了之前的数据块映射，任何新的写入和更新将会发生在它们单独的数据块
映射里。

170

图.多重克隆的块映射
如之前说过，每个 VM/vDisk 有它自己的单独的数据块映射。所以在上述例子里，所有从基础虚拟机来的克隆将会有它们自己的数据块映射，所有写和更新将会发生在那里。
如果发生覆写，数据将进入新的 extent / extent group。例如,假如在 extent e1 中偏移量 o1 处的现有数据被覆写，Stargate 将创建一个新的 extent e2 并跟踪新数据在
exten e2 的偏移量 o2 写入。 Vblock 映射将跟踪到字节级别。
下图显示了这些看起来是什么样的例子：

171

图 . 克隆块映射 - 新写入
任何后续 VM/vDisk 克隆或快照将会引起原始数据块映射被锁定，并将产生一个新的读写访问。

4.3.11

网络及 I/O关于视频解说，你可以查看以下链接：（https://youtu.be/Bz37Eu_TgxY)

Nutanix 平台的内部节点间无背板链接，而是依赖于标准的 10GbE 网络进行通讯。运行于 Nutanix 平台上的虚拟机的所有存储 I/O 都在专用私有网络里由虚拟化监
控程序（HyperVisor）处理。虚拟化层接收 I/O 请求，随后将其转发给本地 CVM 的
私网 IP。此 CVM 随后将通过外部 IP 及外部的 10GbE 网络把数据远程复制至其他
CVM 中。对于读请求，绝大部分都将由本地 CVM 提供服务，而无需通过外部的10GbE 网络。这就意味着，只有 DFS 的远程复制和 VM 的网络流量需要用到 10GbE
网络，除非本地 CVM 宕机或跨节点访问远程数据（如 vMotion 后）。当然，集群的其他一些情况也会临时使用到 10GbE 网络，例如：磁盘的负载均衡等。
以下是 VM 使用到的 I/O 路径的示意图，包含内部、外部 10GbE 网络：172

图. DSF 网络

4.3.12数据本地化 Data Locality关于视频解说，你可以查看以下链接：(https://youtu.be/ocLD5nBbUTU)

I/O 和数据的本地化（data locality），是 Nutanix 超融合平台强劲性能的关键所在。正如之前 I/O 路径（I/O Path）章节所述，所有的读、写 I／O 请求都藉由 VM 的所在节点的本地 CVM 所响应处理。VM 的数据都将由本地的 CVM 及其所管理的本地
磁盘提供服务。当 VM 由一个节点迁移至另一个节点时（或者发生 HA 切换），此VM 的数据又将由现在所在节点中的本地 CVM 提供服务。当读取旧的数据（存储在之前节点的 CVM 中）时，I／O 请求将通过本地 CVM 转发至远端 CVM。所有的写 I／O 都将在本地 CVM 中完成。DFS 检测到 I/O 请求落在其他节点时，将在后台自动
将数据移动到本地节点中，从而让所有的读 I/O 由本地提供服务。数据仅在被读取到才进行搬迁，进而避免过大的网络压力。
数据本地化有两种主要形式：•缓存本地化o 将远程数据拉入本地 Stargate 的统一缓存。这是在 4K 粒度下完成的。
o 对于没有本地副本的实例，请求将转发到包含副本的 Stargate，后者将返回数据，
本地 Stargate 将此数据存储在本地，然后返回 I / O。对该数据的所有后续请求将从
缓存中返回。
•Extent Group（egroup）本地化
o 迁移要存储在本地 Stargate 的扩展存储区中的 vDisk 扩展区组（egroup）。
o 如果副本 egroup 已经在本地，则无需移动。
o 在这种情况下，在满足某些 I / O 阈值后，实际副本 egroup 将重新定位。我们不会自动重新本地化/迁移 egroup，以确保我们有效利用网络。
o 对于启用 AES 的 egroup，在副本不在本地且满足模式的情况下，也会发生相同的
水平迁移。

173

以下展示了数据是如何随着 VM 而迁移的：图. 数据本地化

数据迁移条件：
Cache 本地化基于 vDisk 归属实时发生，当一个 vDisk/VM 从一个节点移动到另一个，vDisk 的归属被移交到本地 CVM，之后数据在本地 Unified Cache 里存储。中间过程 Cache 将被归属主机暂停（现在是远端主机）。 当它看见远端I/O 超过 300 秒，之前主机的 Stargate 将放弃 vDisk 标记，由本地 Stargate
接管。 缓存 vDisk 的数据需要得到所属权利，由此 Cache 一致性得到增强，Extend 本地化是一个取样操作，当满足以下条件时将搬迁 Extent Group：10
分钟内被触发 3 次随机读或者 10 次顺序读，其中 10 秒内的多次读取被视为 1
次触发.

4.3.13

影子克隆 Shadow Clones关于视频解说，你可以查看以下链接：(https://youtu.be/oqfFDMYQFJg)
Acropolis DSF 有一项功能称之为“Shadow Clones”，允许在大量并发读取时分布式
的缓存特定的 vDisk 或 VM 数据。最好的例子莫过于在 VDI 部署中，大量的链接克隆（Linked Clones）需要读取模版虚拟机（A central master or ‘Base VM’）。在Vmware View 中，这被称之为磁盘副本（replica disk），并被所有链接克隆所读
取。在 XenDesktop 中，这被称之为 MCS 主虚拟机（MCS Master VM）。这也可以
被用于其他的大量并发读取的环境中（例如：部署虚拟服务器等）。数据和 I/O 本地
化是将 VM 性能最大化，以及 DSF 的架构特性的关键之所在。

174关于 Shadow Clones，DSF 将监控 vDisk 的“本地化”访问趋势。如果有超过 2 个以上
CVM（包括本地的 CVM）同时访问，且全部都是读请求，该 vDisk 将被标记为只读。一旦 vDisk 被标记为只读，则该 vDisk 可被缓存至所有 CVM 的本地，实现本地
的数据读取（或可称之为基于 vDisk 的 Shadow Clones）。这样就可以让所有的 VM
在本地就可以读取模版虚拟的 vDisk 了。在 VDI 中，这就意味着所有的磁盘副本可以
被缓存到所有节点的本地，所有的读请求将由本地节点给予响应。注意：数据将在读取后执行搬迁，因此不会大量增加网络负载，并且可以大幅提升缓存的利用率。如果
模版虚拟机被更改，则 Shadow Clones 将停止，并丢弃。Shadow Clones 默认被开
启（如 NOS4.0.2），你可以通过以下 NCLI 命令行开启或关闭此功能：ncli cluster
edit-params enable-shadow-clones=<true/false>
下图展示的 Shadow Clones 是如何工作及允许分布式缓存的：图.影子克隆4.3.14存储层和监控Nutanix 平台监控着存储中的多个层面，从 VM 或 Guest OS 到物理磁盘。了解各个层面以及它们之间的关系对于后续的监控、运维、操作等是很重要的。
下图显示各个层面相关的监控事项及监控的颗粒度等：

图. 存储层级

175

虚拟机层
l

主要角色： 通过虚拟化层获取 VM 的状态参数

l

描述：通过虚拟化层直接获取 VM 或 Guest 的状态参数，标示出 VM 当前的性能，以及应用系统当前的 I/O 性能l

使用场景：故障定位或 VM 性能分析

虚拟管理器层
l

主要角色： 虚拟化层的状态参数

l

描述：通过虚拟化层获取当前的最为精准的状态参数。这些数据包含整个群集或其中任一节点的状态。这一层面上可以提供各个平台中的性能参数，可被用于更多的的分析场
景。当然，你也可以通过监控不同的颗粒度，获取更加精准的指标。这其中就包含
Nutanix CVM 的缓存命中率l

使用场景：提供更有价值的详细的性能指标

控制器层
l

主要角色： Nutanix 控制器的状态参数

l

描述：此状态参数由 Nutanix 控制器虚拟机（例如：通过 Stargate 2009 端口）直接提供，它将标示出前端采用了 NFS／SMB／iSCSI 中的哪种链接的方式，以及后端发生了哪些操作（例如：ILM、磁盘负载均衡等）。你可以查看单个控制器虚拟机或整个控制
器集群的相关参数。这些状态参数中部分数据将与虚拟化层的提供的数据相吻合，另
外，数据中还将包括后端的操作（例如：ILM、磁盘负载均衡等），当然这其中就包含
Nutanix CVM 的缓存命中率。在某些情况下，IOPS 的指标可能会有差异，因为 NFS／
SMB/iSCSI 客户端会将大的 IO 进行拆分。但它们表现出来的带宽应该是一致的l

使用场景：类似于 HyperVisor，却能够更好监控后端操作磁盘层l

主要角色： 磁盘设备的状态参数

l

描述：此状态参数由物理磁设备直接提供（通过 CVM），标示出了后端的操作。其中包括 I/O 在磁盘操作时命中 Oplog 或者 Extend Store。可以监控到单块磁盘、某个节点
的磁盘，或集群中的全部磁盘。一般情况下，对磁盘的操作包括 IO 的写入及未在缓存
中命中的读操作。任何在缓存中命中的读操作，都将不计入磁盘的监控数据中l

使用场景：可以查看有多少 IO 操作落到了缓存或磁盘中

176

保存期限
以上状态信息，在本地的 Prism 中仅保存 90 天。如使用 Prism Central 和Insights，则可以长期保存（如果容量充足的话）

4.4 服务
4.4.1 Nutanix Guest Tools (NGT)
Nutanix Guest Tools(NGT) 是一个安装在客户机操作系统上的软件代理（类似于vmtools），它使得虚拟机能够使用 Nutanix 平台的一些高级功能。
Nutanix Guest Tools 包括安装在虚拟机中的 NGT installer 和 Guest Tools 程序框
架。通过 Guest Tools 程序框架在代理程序和 Nutanix 平台之间进行协调。
Nutanix Guest Tools(NGT)通过 NGT Installer 安装程序进行安装配置，NGT Installer
安装程序包括如下组件：l 客户机代理服务；l 自助服务恢复 Self-service Restore(SSR)，也称为基于命令行的文件级
自服务恢复 File-level Restore(FLR)l 虚拟机移动性驱动（AHV 的 VirtIO 驱动）；l 针对 Windows 虚拟机的 VSS(volume shadow service 卷影服务)代理和硬件接口服务（ Hardware Provider）；
l 针对 Linux 虚拟机的应用一致性快照支持（通过脚本实现静默）；这个程序框架还包括一些高级组件：l 客户机工具组件服务（Guest Tools Service）
o 作为在 Acropolis、Nutanix 服务及客户机代理之间的网关。分布
在集群内的各个 CVM 上，该集群运行了在当前 Prism leader（
托管主机集群 vIP-虚拟 IP）上通过选举出来的 NGT Master 。
l 客户机代理（Guest Agent）
o 代理程序与相关服务作为 NGT 安装进程的一部分，部署在客户
机操作系统中。处理所有本地服务（例如 VSS、SSR 等）与前
述客户机工具组件服务的交互。
下图显示了组件的高级映射：177

图.Guest Tools 映射
客户机工具组件服务（Guest Tools Service）
客户机工具组件服务由两个主要角色组成：l NGT Master处理由 NGT Proxy 发来的请求并与 Acropolis 组件交互。每个集群动态选举得出
一个独立的 NGT Master，如当前 Master 失效，则将再选举出一个新的。该服
务的内部监听端口为 2073。

l NGT Proxy运行在每个 CVM 上，并转发请求给 NGT Master 以执行需要的活动。由当前作
为 Prism Leader（托管集群虚拟 IP）的 CVM 虚拟机与客户机代理程序进行通信。监听的外部端口为 2074。
当前 NGT Master您可以用下面命令行找到 NGT Master 角色所在的 CVM（在 CVM 运行）

下图显示了高级别的角色映射：

178

图. 客户机工具服务

客户机代理程序（Guest Agent）
客户机代理程序由以下高级别组件按之前已提到过的优先级组成：图. 客户机代理程序

通信与安全

179

客户机代理服务与客户机工具组件服务之间的通信通过 Nutanix 集群 IP 的 SSL
链接进行。当 Nutanix 集群组件和 UVM 的部署不在同一网络时，需要确认以下配置
是可行的：l确认 UVM 网络到集群 IP 的路由可达或者l 在 UVM 网络中创建一个防火墙规则（以及相关的 NAT 规则），允许与
集群 IP 在 2074 端口上进行通信。（优选方案）
客户机工具服务还要充当 CA 认证，负责在每一个已运行 Nutanix Guest Tool 的
UVM 上生成认证钥匙对。证书被嵌入 Nutanix Guest Tool 的 ISO 安装文件并作为安
装进程的一部分被安装在 UVM 上。
NGT 代理程序的安装NGT 代理程序的安装可通过 Prism 或通过命令行/脚本（ ncli/REST/PowerShell）。
通过 Prism 安装 NGT，在 Prism 界面导航到“VM”页面，选择一个虚拟机安装 NGT 代
理程序，然后点击“Enable NGT ”

图. 为虚拟机启动 NGT
在弹出的提示栏上点击“Yes”以继续 NGT 的安装；

180

图. 启动 NGT 安装的提示栏
安装 NGT 的虚拟机必须配置一个 CD-ROM 用以挂载 NGT 安装软件包，如下图所示：

图. 启动 NGT 安装 – 光驱设备在虚拟机操作系统中将能看到 包含 NGT 安装软件包的光驱设备:图. 启动 NGT 安装 – 虚拟机操作系统中的光驱设备鼠标双击上图光驱设备图标以开始安装进程。
181

静态安装
您可以通过运行下列命令（从 CD-ROM）执行一个静态安装:NutanixGuestTools.exe /quiet /l log.txt ACCEPTEULA=yes

在出现的提示栏中点击接受软件许可协议以完成 NGT 软件包的安装:图. 启动 NGT 安装 – 开始安装作为安装进程的一部分，Python、PyWin 和 Nutanix Mobility（提供跨虚拟化平台的互换能力）驱动将同时被安装。
安装结束后，需要重启虚拟机操作系统 。
成功完成安装和重启任务后，您将能看到以下条目出现在控制面板的“程序与功能”项目中。

182图.

启动 NGT 安装 – 已安装的程序

在服务项目中可以看到 NGT Agent 服务和 VSS Hardware Provider 服务已经运行：

图. 启动 NGT 安装 – 安装后启动的服务此时，NGT 已经完成部署并能够被使用了。
备注：
批量 NGT 部署
与其在每一个虚拟机上分别安装 NGT，更好的方式是在您的基础操作系统镜像
中嵌入并部署 NGT。
可通过以下步骤在操作系统基础镜像中嵌入并部署 NGT：
1.

在原版虚拟机上安装 NGT 并确认能够正常通信；

2.

基于该母版虚拟机克隆新的虚拟机；3.

在每个克隆虚拟机上挂载 NGT 的 ISO 文件 (因需要得到新的认证钥匙对)o

命令行示例：ncli ngt mount vm-id=<CLONE_ID> OR via Prism
183

o

4.

后续提供自动化的方式；
启动克隆虚拟机

当克隆生成的虚拟机启动时，它将检测到新的 NGT ISO 安装镜像并拷贝相关配
置文件和新的证书，完成后开始与 Guest Tools Service 进行通信。

4.4.2 OS 定制化
Nutanix 借助于 CloudInit 和 Sysprep 提供原生的 OS 定制化能力。CloudInit 是一个
控制 Linux Cloud Server 引导的软件包，它可以提前初始化和定制化 Linux
Instance。Sysprep 是 Windows 操作系统的 OS 定制化工具。
常见的使用如下：• 设置机器名• 安装软件包• 添加用户／密钥管理• 定制化脚本

支持的配置

解决方案适用于运行在 AHV 上的 Linux 客户机，支持以下版本（部分清单，完整的支持清单详见相关文档）：• Hypervisors：
o

•

AHV

操作系统：
o

Linux - 大部分当前常见版本oWindows -大部分当前常见版本

前提条件

184

使用 CloudInit 需要满足以下条件：• CloudInit 已经在 Linux 系统中安装完成。

Windows 默认已经安装了 Sysprep

软件包安装

CloudInit 如果不可用，可以通过以下命令进行安装：•

基于 RedHat 的 CentOS 和 RHEL：•

基于 Debian 的 Ubuntu：

Windows 基础安装已经包含了 Sysprep
镜像定制化为了进行 OS 定制化，在创建或克隆虚拟机时，在 Prism 或 REST API 中要选择Custom Script 复选框并在 Script 输入框中输入定制化的脚本。

185

图. 定制化脚本-输入选项
Nutanix 提供了几个指定定制化脚本路径的选项：•ADSF Patho 使用一个已经上传到 ADSF 上的文件
• Upload a fileo 上传一个准备使用的文件• Type or paste scripto CloudInit 脚本或者是 Unattend.xml 文本文件
包含脚本的 CD－ROM 在第一次启动时，Nutanix 会将用户数据脚本传递给
CloudInit 或者 Sysprep。

输入格式

平台支持大量用户数据输入格式，以下是可以识别的重要格式之一：• User-Data Script (CloudInit - Linux)
User-Data Script 是一个简单 shell 脚本，该脚本会在启动进程非常靠后阶段才会
被执行（例如：“rc.local - like”）
该脚本一般使用以”#!”开始的 bash script。
186

下面是 user-data 脚本举例：Include File (CloudInit - Linux)
Include File 包含了多组 URL（每个 URL 一行），每个 URL 都会被读取并且会
被执行到其他任何脚本。
该脚本都是以“＃include”开始，类似下面的 include 脚本案例：

Cloud Config Data (CloudInit - Linux)对 CloudInit 来说 Cloud-config 输入类型非常典型，该脚本以“#cloud-init”开始，类似下面的格式：187

确认 CloudInit 已执行

CloudInit 运行日志是保存在/var/log/下的 cloud-init.log 和 cloud-init-output.log• Unattend.xml (Sysprep - Windows)
Unattend.xml 文件是 Sysprep 在启动过程中定制化镜像时用到的内容。该脚本
以“<?xml version=”1.0” ?>”开始。
下面显示了 unattend.xml 文件的案例：

188

4.4.3 Karbon（容器服务）Nutanix 提供了使用 Kubernetes（当前）在 Nutanix 平台上利用持久容器的能力。之前也可以在 Nutanix 平台上运行 Docker，但是由于容器的天生原因无法使用永久数
据存储。
像 Docker 这样的容器技术是不同于硬件虚拟化。传统的虚拟化，每个虚拟机都有自己的操作系统（OS）但是他们共享底层的硬件。而容器他们共享的是底层的操作系
统内核，容器中运行的应用和他们之间的依赖关系都是运行在独立的进程中。
下面的表格对容器和虚拟机之间做了简单对比
虚拟机
容器
虚拟化类型
基于硬件的虚拟化基于操作系统内核的虚拟化
量级
重量级
轻量级
提供速度
慢（秒级或分钟级）实时（毫秒级）
性能
性能有限
超级性能
安全
完全独立（安全高）
进程级别独立（安全低）支持配置方法适用的配置方法如下：lHypervisor(s):

189

n
l
n

AHV
容器：
Docker 1.13

在 4.7 开始，该解决方案，目前存储集成只支持 Docker 的容器。但是其他容器 可以
在 Nutanix 平台上作为虚拟机运行。
容器服务架构
以下组件构成了 Acropolis Container ServiceslNutanix Docker Machine Driver：通过 Docker Machine 和
Acropolis Image Service 控制 Docker 的 container host 发布l
Nutanix Docker Volume Plugin：负责与 Acropolis Block Services
交互来创建、挂载，格式化和附加 volumes 到所需的容器时以下组件构成了 Docker（注意：不是所有都是必需的）
l
l
l
l
l
l
l
l
的请求
l

Docker Image：容器的基础镜像
Docker Registry: 为 Docker Images 管理空间
Docker Hub: 在线容器交易市场 (public Docker Registry)
Docker File：如何创建 Docker 镜像的 Text file 文本描述文件
Docker Container：运行 Docker 镜像的实例Docker Engine：创建、移动、运行 Docker 容器
Docker Swarm：管理 Docker 集群／调度的平台
Docker Daemon：处理来自 Docker 客户端的创建、运行和分配容器
Docker Store： 可信的企业级容器交易市场

架构
Nutanix 当前支持将 Docker Engine 运行为使用 Docker 而创建出来的虚拟机里。这
些机器可以是平台上运行的普通虚拟机。

图.Docker - 高级别架构
190

Nutanix 开发出 Docker Volume Plugin。利用它，可以通过 Acropolis Block Services
创建、格式化和附加一个 volume 给容器。这样就可以在容器关机或移动时数据保持不变。
通过 Nutanix Volume Plugin，Acropolis Block Services 在附加 volume 给主机或容器时，数据也能做到永久性。

图. Docker - 块服务
前提条件
要使用容器服务，需要满足以下条件：
•
•
•
•
•

Nutanix 集群必须是 AOS 4.7 或以后版本
Nutanix Docker Host Image 必须下载并且作为一个 Image 保存在 Acropolis 的 Image
Service 里
Nutanix Data Services IP 必须已经配置好
Docker Toolbox 必须在 client 机器上安装且配置Nutanix Docker Machine Driver 必须在客户端的 PATH 里

创建 Docker Host
当所有的前提条件满足后，在 Docker 机器上就可以提供 Nutanix Docker Hosts

191

下图显示了创建 Docker 主机的工作流：

图. Docker - 主机创建工作流
下一步，在 Docker Machine 上通过 SSH 登录到最新发布的 Docker 主机上：
安装 Nutanix Docker Volume Plugin：
docker plugin install ntnx/nutanix_volume_plugin PRISM_IP= DATASERVICES_IP=
PRISM_PASSWORD= PRISM_USERNAME= DEFAULT_CONTAINER= --alias
nutanix
完成后，查看 volume plugin 已经在运行：

创建 Docker 容器
当 Nutanix Docker Host 完成部署并且 volume plugin 也启动，就可以发布使用永久存储的容器了。
可以使用典型的 Docker volume 命令架构生成 volume 并制定 Nutanix volume
driver。
例如：192

可以使用标准的 Docker run 命令行并指定 Nutanix volume driver，示例如下：下图显示了创建容器的工作流：

图.Docker - 容器创建的工作流
现在你就拥有了配备永久存储的容器！

4.5 备份与容灾
Nutanix 提供原生备份和容灾（DR）功能，允许用户将运行在 DSF 上的 VM 和对象备份，还原和灾难恢复到本地或云环境（Xi）。从 AOS 5.11 开始，Nutanix 发布了一项名为 Leap 的功能，该功能抽象了许多这些概念。有关 Leap 的更多信息，请参
阅“”中的“ Prism”一章。
下面的章节包含以下内容：
l
实施组件
l
保护对象
l
备份和恢复
l
复制和容灾

193

注意：尽管 Nutanix 提供备份和容灾的原生功能选择，那些借助平台提供内置特性（VSS、快照等）的传统备份解决方案（例如 Commvault、Rubrik 等）仍然可以使用。

4.5.1 实施组件
Nutanix 备份和容灾涉及到以下关键组件：
保护域（PD／Protection Domain）• 主要角色：同时保护多个“虚拟机／文件”的逻辑组• 描述：一组虚拟机或文件基于某个相同的保护策略进行复制保护。一个 PD 可以
保护一整个容器（Container）或被选中的虚拟机或文件。

专家提示：可以针对不同的 RPO／RTO 需求，创建多个不同的 PD。例如可以针对“文件分发”创
建专门的 PD，用于 Golden images, ISO 文件的复制等.

一致性组（CG／Consistency Group）• 主要角色：PD 中多个相关联的虚拟机或文件构成的一个子集，以实现故障一致性。
• 描述：PD 中多个相关联的虚拟机或文件需要使用故障一致性发起快照。从而确
保在虚拟机或文件回滚时的数据一致性。一个 PD 中可包含多个 CG。
专家提示：
相互依赖的多个应用或服务类虚拟机（e.g. APP and DB）放置在一个 CG 中，可确保在发生回滚时的数据一致性。

快照计划（Snapshot Schedule）• 主要角色：快照和复制计划• 描述：为指定 PD 和 CG 中的虚拟机提供快照、复制的计划安排专家提示：快照计划应该符合预期 RPO 的要求

保留策略（Retention Policy）• 主要角色：本地或远程站点中保留的快照数量• 描述：保留策略定义了本地或远程站点中保留的快照数量。注意：在远程保留/复
制策略配置前，必须先配置远程站点。

194

远程站点（Remote Site）
专家提示：
保留策略即为虚拟机或文件的恢复点数量••

主要角色：远程 Nutanix 集群
描述：远程 Nutanix 集群是作为备份或容灾的目标来使用的。
专家提示：确保目标站点有充足容量（计算／存储）处理整个站点故障。
某些场景中在单个站点中不同机架之间实施复制／容灾也是有意义的。

以下的图片展示了一个站点内，PD、CG 和虚拟机/文件间的逻辑关系

图.容灾组件关系基于策略的灾难恢复和 RunBooks
基于策略的灾难恢复和 RunBooks 扩展了基于虚拟机的灾难恢复（PD，CG 等）中定
义的功能，并将其抽象为策略驱动的模型。通过关注感兴趣的项目（例如 RPO，保留等）并分配给类别而不是直接分配给 VM，可以简化配置。这也允许适用于所有
VM 的“默认策略”。
注意：这些策略是通过 Prism Central（PC）配置的。

4.5.2 保护对象使用如下过程保护对象（VMs、VGs、Files）：
在“Data Protection”页面，选择+Protection Domain->Async DR：图. 容灾（DR） – 异步保护域
指定 PD 名称并点击“Create”
195图. 容灾（DR） – 创建保护域选择要保护的对象196

图. 容灾（DR）– 异步保护域点击“Protect Selected Entities”

197图 . 容灾（DR）– 保护实体
保护对象将显示在“Protected Entities”中图 . 容灾（DR）– 被保护的实体
点击“Next”，然后点击“Next Schedule”来创建快照和复制计划。
输入需要的快照频率、保留策略和复制的远程站点。

198

图 . 容灾（DR）– 创建计划
点击“Create Schedule”完成计划创建。
多保护计划可以创建多个快照／复制计划。例如，一个每小时的本地备份计划，另一个每天复制到远程站点的计划。
需要重点指出的是，Nutanix 不仅可以简单的将一整个容器（Container）进行保护，还可以提供针对单个虚拟机或文件级的更加细致的保护。

4.5.3 备份和恢复
Nutanix 备份功能借助原生的 DSF 快照，由 Cerebro 调用并由 Stargate 执行。这种
快照是 0 复制确保有效利用存储、降低开销。更多关于 Nutanix 快照的内容在“快照和克隆”章节。
典型备份和恢复操作包括：• 快照：创建恢复点并复制（如果需要的话）•

恢复：从之前的快照中恢复虚拟机/文件（替换原有对象）•

克隆：类似于恢复，但不替换原有对象（使用需要的快照创建新对象）在“Data Protection”页，可以看到之前在“Protecting Entities”部分创建的保护域
（PD）。
199

图. 容灾（DR） – 查看保护域一旦选定目标 PD，可以看到不同选项：图.容灾（DR）– 保护域动作
如果点击“Take Snapshot”，可以为选择的 PD 临时创建快照并按需要复制到远程站点：图. 容灾（DR）– 创建快照“Migrate” PD 会将对象故障转移到远程站点：200

图. 容灾（DR）– 迁移在迁移（受控故障转移）的情况下，系统将创建一个新快照，进行复制，然后使用新创建的快照升级另一个站点。
专家提示
在 AOS 5.0 及更高版本中，您可以利用单节点复制达到数据保护。

在下面表格中查看 PD 快照信息：

图. 容灾（DR）– 保护域动作
从这里可以恢复或者克隆 PD 的快照：

201

图. 容灾（DR）– 恢复快照选择“Create new entities”类似于克隆 PD 快照创建指定前缀的新对象。另外，“Overwrite existing entities”会使用快照时间点上的对象替换现有对象。

存储型备份目标设备仅仅是用于备份／归档目的，可以在远程站点配置存储型 Nutanix 集群用作备份目标。这样数据可以复制到存储型集群或者从存储型集群进行复制。

4.5.4 应用一致性快照
Nutanix 提供原生的 VmQueisced Snapshot Service（VSS）功能静默操作系统和应
用操作，以确保完成应用一致性快照。
支持的配置
VmQueisced Snapshot Service（VSS）
VSS 是典型的用于 Windows 的名词，指 Volume Shadow Copy Service。但是因为该方案既用于 Windows，也用于 Linux，所以 Nutanix 将该名词修改为
VmQueisced Snapshot Service。

202该方案用于 Windows 和 Linux 客户虚拟机，包括以下版本（列表可能不全，参考文
档获得完整支持列表）：•••

Hypervisor：
o
ESX
o
AHV
Windows：o
2008R2，2012，2012R2
Linux：oCentos 6.5/7.0
oRHEL 6.5/7.0o
OEL 6.5/7.0
oUbuntu 14.04+
oSLES11SP3+

前提条件
使用 Nutanix VSS 快照的必要条件如下：•

Nutanix 平台o必须配置集群 Virtual IP（VIP）•
客户操作系统／用户虚拟机o必须安装 NGTo必须能够连接集群 VIP 的 2074 端口•容灾配置o客户虚拟机所在的 PD 必须启用“Use application consistentsnapshots”

架构
4.6 版本开始使用原生的作为 Nutanix 客户工具包的一部分的 Nutanix Hardware VSS
provider 来实现应用一致性。更多内容在“Nutanix Guest Tools”章节。
以下图片显示 VSS 架构的高层视图：203

图. Nutanix VSS – 高层视图
当保护虚拟机时，可以通过下面的普通数据保护流程并选择“Use applicationconsistent snapshots”执行应用一致性快照。

启用／禁用 Nutanix VSS
为用户虚拟机启用 NGT 时，Nutanix VSS 快照功能默认启用。但是需要使用以下命令关闭该功能：Windows VSS 架构
Nutanix VSS 方案集成在 Windows VSS 框架中。下图显示了该架构的高层视图：图 . Nutanix VSS – Windows 架构
一旦 NGT 安装，就可以看到 NGT 代理和 VSS Hardware Provider Service：图 . VSS 硬件供应商204

Linux VSS 架构
Linux 方案类似于 Windows 方案，但是借助于脚本而不是 Microsoft VSS 框架实现，因为 Microsoft VSS 框架在 Linux 发行版中不存在。
Linux VSS 架构高层视图如下所示：

图 . Nutanix VSS – Linux 架构
pre-freeze 和 post-thaw 脚本位于以下目录：••Pre-freeze：/sbin/pre-freeze
Post-thaw：/sbin/post-thaw

消除 ESXi 震荡（Stun）
ESXi 使用 VMware 客户端工具提供原生应用一致性快照。但是在这个过程中，会创建差异磁盘来处理新的写 IO，ESXi 为了重新映射虚拟磁盘到新的差异文件，会“震荡”虚拟机。VMware 快照删除时也会产生震荡。
在震荡过程中，虚拟机本身的操作系统不能执行任何操作，基本处于停滞状态（例如pings 会失败，没有 IO）。震荡时间依赖于 vmdk 的数量和 datastore 元数据操作的处理
速度（例如创建新的差异磁盘等）
使用 Nutanix VSS 完全规避了 VMware 快照／震荡过程，对性能或者虚拟机／操作系统可
用性几乎无影响。

205

4.5.5 复制和容灾（DR）
Nutanix 提供原生的容灾（DR）和复制功能，它们构建于“快照”&“克隆”等功能之上。
Cerebro 是在分布式存储（DSF）中负责管理容灾和复制的组件。Cerebro 运行于每
个节点之中，通过内部选举产生 Master（类似于 NFS Master），并由此节点管理复
制任务。如果当 Cerebro Master 所在的 CVM 发生故障，剩余的节点将选举出新的Master。通过<CVM IP>:2020，即可打开 Cerebro 的相关界面。容灾功能可以分解为以下关键要点：
l
l
l

复制拓扑
复制周期
全局去重

复制拓扑
一直以来，有几种主要的复制网络拓扑：点对点（Site to site），菊花链（hub andspoke），全网状／部分网状（full and／or partial mesh）。相对于传统的方案，它
们仅提供“点到点”或“菊花链”的方式，Nutanix 提供“全网状”或更加灵活的“多到多”的拓扑方式。

图 . 复制拓扑结构示例
这将让管理员能够灵活的配置复制功能，从而更好的满足公司需求。
复制周期
Nutanix 通过 Cerebro 实现数据的复制。Cerebro 服务分为 Cerebro Master 和
Cerebro Slave。Cerebro Master 由动态选举产生，除 Cerebro Master 节点之外的CVM 中，均运行 Cerebro 从属服务（Cerebro Slaves）。一旦“Cerebro Master”所对应的 CVM 宕机，新的 Master 将被自动选举产生。
Cerebro Master 负责委派任务给本地的 Cerebro 从属节点，以及协调远端的 Cerebro
Master，实现容灾数据复制。
在复制过程中，Cerebro Master 将负责确认哪些数据需要被复制，同时将任务委派给
Cerebro 从属节点，随后将告知 Stargate 哪些数据需要被复制，需要被复制到哪里。

206

在复制过程中，复制数据在多个层面被保护。源端 Extent 读使用校验码保证源数据的一致性（类似于 DFS 读），在目标端，新的 Extent(s)也会生成校验码（类似于DFS 写）。TCP 提供网络层面的一致性。
以下是相关架构的示意图：专家提示：
当使用代理方式配置远程站点时，一般都使用集群 IP。此 IP 将宿主在 Prism 主节
点（Prism Leader）上。即使任一 CVM 宕机，也可保证该 IP 可用。

图 . 复制架构我们也可以通过配置代理，使用桥接的方式承载整个集群的协调和复制的数据流。
专家提示：
当配置代理服务器来连接到远程站点时，请一直使用集群 IP 地址（由 Prism
Leader 角色提供并一直可用，甚至在 CVM 当机时仍然有效）
以下是使用代理的架构示意图：207

图 . 复制架构 - 代理（Proxy）
在某些情况下，我们也可以配置 SSH 隧道链接两个 CVM。
专家提示：
这只适用于非生产环境下，并请使用集群 IP 以确保高可用。
以下是使用 SSH 隧道的架构示意图：图 . 复制架构 - SSH 隧道

全局去重正如之前“Elastic Deduplication Engine”章节中所提到的，分布式存储（DSF）可以仅通过更新元数据（Metadata）指针实现重复数据删除。同样的实现方式也可被用208于容灾和复制中。通过网络发送数据之前，DFS 将检查远程站点中是否已经存在相关数据的记录(fingerprint)。如果有，则不发送数据，仅更新元数据。如果远程站点中
没有此数据记录，数据将被压缩并发送至目标站点中。此时，该数据将被用于两个站
点中的重复数据删除。
以下是 3 个站点的部署示例，每个站点包含多个 PD：图 . 复制消重注意：Fingerprinting 功能必须在源端和目标端的 Container／vstore 中都开启，实现复制间的重复数据删除。

4.5.6 近同步复制技术（NearSync）
基于前面提到的传统异步复制功能; Nutanix 在新版本中引入了近同步复制技术
（NearSync）的支持。
NearSync 提供了两全其美的功能：除了非常低的 RPO（与同步复制（metro）相近）之外，对主 I / O 延迟（与异步复制相同）的影响为零。这意味着允许用户具有
非常低的 RPO，而又不会产生对写入的同步复制的开销。
此功能使用称为轻量级快照（LWS）的新快照技术。与使用异步方式的传统基于虚拟磁盘的快照不同，它利用标记并且完全基于 OpLog 来完成（与在 Extent Store 中完
成的虚拟磁盘快照相比）。

209

Mesos 是一项新增的服务，用于管理快照层并抽象完整/增量快照的复杂性。
Cerebro 继续管理高层架构和策略（例如一致性组等），而 Mesos 负责与 Stargate
交互并控制 LWS 生命周期。
下图显示了 NearSync 组件之间的通信示例：

图. NearSync 组件交互
当用户配置快照频率<= 15 分钟时，将自动利用 NearSync 技术进行保护。在此之后，初始种子快照被执行然后被复制到远程站点。一旦这个过程在 60 分钟内完成（可以是第一个或第 n 个），除了开始 LWS 快照复制之外，另一个种子快照将被立即执行和复制。一旦第二个种子快照完成复制，所有已复制的 LWS 快照将变为有效，并且系统处于稳定的 NearSync 运行状态中。
下图显示了启用 NearSync 执行的示例时间表：图. NearSync 复制生命周期

在稳定的运行状态下，每隔一小时就会执行一次虚拟磁盘快照。除了 LWS 之外，远程站点不是将快照发送到远程站点，而是基于之前的虚拟磁盘快照和 LWS 来组成虚拟磁盘快照。
210

如果 NearSync 不同步（例如网络中断，广域网延迟等原因）导致 LWS 复制耗时大于 60 分钟，系统将自动切换回基于虚拟磁盘的快照。当其中一个快照复制在 60 分
钟内完成，系统将立即执行另一个快照，同时开始复制 LWS。在完整快照完成后，
LWS 快照将变为有效，系统处于稳定的 NearSync 状态中。此过程与初次启用NearSync 的情况类似。
当基于 LWS 的快照恢复（或克隆）时，系统将克隆最新的虚拟磁盘快照并逐渐应用
LWS，直到达到所需的 LWS。
下图显示了如何恢复基于 LWS 的快照的示例：图. 从 LWS 恢复 vDisk

4.5.7 城域高可用性 Metro Availability
Nutanix 具有“Stretch Clustering”的能力，允许它的计算和存储集群可以跨越多个物理站点。这种部署架构下，计算集群可以跨越两个站点并共享一个存储池。
这将 VM HA 集群从一个站点扩展到两个站点之间，提供近乎等于 0 的 RTO。
这种部署架构下，每个站点都有自己的 Nutanix 集群，但其中容器（Container）的
写操作被同步复制到远端的站点之中。
以下是此架构的详细示意图：211

图. 城域高可用性 - 正常状态
如果站点发生故障，则会发生 HA 事件，在该事件中可以在另一个站点上重新启动
VM。故障转移过程通常是手动过程。在 AOS 5.0 版本中，可以配置 Metro
Witness，它可以自动执行故障转移。见证人可以通过门户网站下载，并可以通过
Prism 进行配置。
以下是一个站点发生故障的示意图：212

图 . 城域高可用性 - 站点故障
如果站点间的网络链路故障，集群将分别独立运行。一旦网络链路修复，站点将进行增量同步，并重新恢复数据同步。
以下是网络链路故障的示意图：213

图 . 城域高可用性 - 连接故障

4.5.8 云链接云链接（Cloud Connect）功能可以很好的扩展分布式存储原生的容灾／复制功能（当前支持 Amazon Web Services, 或 AWS）。注意：该功能当前仅适用于备份／复制。
该过程非常类似于原生的容灾／复制功能去创建一个远程站点，实际上是一个“云端站点”被创建出来。当此云端站点被创建时，Nutanix 将自动在 EC2（当前为
m1.xlarge）或 Azure 虚拟机（当前为 D3）创建一个单节点的集群作为目标端。
运行在 AWS 上的云实例也是基于跟本地集群相同的 NOS 源代码构建。这就意味着
所有原生的复制功能（例如：全局重复数据删除、两地三中心等）可以直接使用。
在这个示例中，有多个 Nutanix 集群使用了云链接，它们可以共享区域里同一个实
例 ，或配置一个全新的实例。
云实例的存储是使用由 S3(AWS)或者 BlobStore(Azure)提供的逻辑磁盘，称为“云磁盘”。数据存储为通常的 Egroup，它在对象存储中作为文件存放。
以下是基于 AWS 的云端站点云链接的示意图：214

图. 云链接 - 地区
由于基于 AWS 创建的云端站点类似于 Nutanix 的普通远程站点，集群可将数据复
制到多个不同地域，从而获得更高的业务连续性（例如，地域性的大规模停电，仍可保证数据可用）：215

图 . 云链接 - 多地区
同样的复制／保留策略也可被用于云链接的数据复制之中。当数据或快照失效或过期时，云集群将执行必要的清理动作。
如果复制的频率不高（每天一次或每周一次），甚至可以配置为在复制开始前才启
动云实例，并在复制完成后，将其关机。
复制到云区域中的数据也可随时下传、恢复到现有的或新建的 Nutanix 集群中，当然该集群需要配置、链接到云端站点。

216

图 . 云链接 - 恢复

4.6 Application Mobility Fabric*
4.7 管理4.7.1 重要页
除了标准管理页面之外，高级页用来监视详细统计信息和指标，URL 访问方式
如下：http://<Nutanix CVM IP/DNS>:<Port/path (下文中提到的)> 示例:
http://MyCVM-A:2009，注：如果你在与 CVM 不同的子网访问页面，需要禁用 CVM
防火墙。

2009 Page

217

这是 Stargate 页用于监控后端存储，只能由高级用户使用。我将发表一篇帖
子，介绍 2009 年的页面和需要寻找的内容。

2009/latency Page
这是 Stargate 页用于监控后端延迟。

2009/vdisk_stats Page
这是 Stargate 页用于显示各种 vDisk 统计信息，包含 I/O、延迟、写命中(e.g.,
OpLog, eStore)、读命中(cache, SSD, HDD, etc.)等柱状图。

2009/h/traces Page
这是 Staegate 页用于监控操作的活跃跟踪

2009/h/vars Page
这是 Stargate 页用于监控各种计数器

2010 Page
这是 Curator 页用于监控 Curator 运行

2010/master/control Page
这是 Curator 控制页用于手工启动 Curator 工作

2011 Page
这是 Chronos 页监控通过 Curator 监控工作和任务计划2020 Page
这是 Cerebro 页用于监控保护域、复制状态和 DR

2020/h/traces Page
这是 Cerebro 页用于监控 PD 操作和复制的实施追踪

2030 Page

218

这是 Acropolis 主要页，显示主机环境详细信息、正在运行的任务和网络详细信息。

2030/sched Page这是一个 Acropolis 页面，通过显示虚拟机资源调度信息帮助决定虚拟机运行位置，这页显示虚拟机运行的主机的可用资源。

2030/tasks Page这是一个 Acropolis 页面用于显示 Acropolis 任务和状态，你可以点击任务 UUID
来获得任务的详细 JSON 信息。

2030/vms Page这是一个 Acropolis 页用于显示 Acropolis 虚拟机及虚拟机的详细信息，你可以点击虚拟机名称连接到虚拟机控制台。

4.7.2 集群命令

检查集群状态
说明：通过命令行检查集群状态
cluster status

检查本地 CVM 服务状态说明：通过命令行检查单个 CVM 的服务状态
genesis status

Nutanix 集群升级说明：通过命令行执行滚动(aka "live")集群升级

上传升级包到一台 CVM 的~/tmp/
解压缩升级包tar xzvf ~/tmp/nutanix*

219

运行升级
~/tmp/install/bin/cluster -i ~/tmp/install upgrade检查状态
upgrade_status节点升级说明：运行升级将指定节点升级到当前集群版本

任意 CVM 上运行以下命令
cluster -u <NODE_IP(s)> upgrade_node

Hypervisor 升级状态说明：任意 CVM 运行命令检查 Hypervisor 升级状态
host_upgrade --status详细日志(on every CVM)~/data/logs/host_upgrade.out

命令行重启集群及服务说明：通过命令行重启单一集群服务

停止服务
cluster stop <Service Name>启动服务
cluster start #NOTE: This will start all stopped services

通过命令行启动集群服务说明：命令行启动已经停止的集群服务

220

启动服务
cluster start #NOTE: This will start all stopped services

或者启动单一服务
Start single service: cluster start <Service Name>

命令行重启本地服务说明：命令行重启单一集群服务停止服务
genesis stop <Service Name>启动服务
cluster start

命令行启动本地服务说明：命令行启动已经停止的集群服务cluster start #NOTE: This will start all stopped services

通过命令行添加集群节点说明：通过命令行添加集群节点
ncli cluster discover-nodes | egrep "Uuid" | awk '{print $4}' | xargs -I UUID
ncli cluster add-node node-uuid=UUID

显示 vDisks 数量
说明：显示 vDisks 数量
vdisk_config_printer | grep vdisk_id | wc -l221

找到集群 ID说明：找到当前集群 ID
zeus_config_printer | grep cluster_id

打开端口
说明：通过 IPtables 启用端口sudo vi /etc/sysconfig/iptables-A INPUT -m state --state NEW -m tcp -p tcp --dport <PORT> -j ACCEPT
sudo service iptables restart检查 Shadow Clones
说明：通过以下命令格式显示 shadow clones：name#id@svm_id
vdisk_config_printer | grep '#'重置延迟页统计
说明：重置延迟页(<CVM IP>:2009/latency)计数器
allssh "wget $i:2009/latency/reset"查找 vDisks 数量
说明：查找 Distributed Storage Fabric （DFS）上的 vDisk 数量

vdisk_config_printer | grep vdisk_id | wc -l

命令行开始 Curator 扫描
Description: Starts a Curator full scan from the CLI 说明：命令行开始 Curator 全扫描
allssh "wget -O - "http://$i:2010/master/api/client/StartCuratorTasks?task_type=2";"

压缩环
222

说明：压缩元数据环
allssh "nodetool -h localhost compact"查找 NOS 版本
说明：查找 NOS 版本（注：也可使用 NCLI）
allssh "cat /etc/nutanix/release_version"查找 CVM 版本
说明：查找 CVM 镜像版本
allssh "cat /etc/nutanix/svm-version"

手工添加 vDisk 指纹说明：产生一个指定的 vdisk 指纹（为重复数据删除） 注：重复数据删除，必须在容器上启用
vdisk_manipulator –vdisk_id=<vDisk ID> --operation=add_fingerprints

手动添加所有 vDisk 指纹说明：:为所有磁盘生成指纹（用于重复数据删除） 注：重复数据删除，必须在容器上启用
for vdisk in `vdisk_config_printer | grep vdisk_id | awk {'print $2'}`; do vdisk_manipulator -vdisk_id=$vdisk -operation=add_fingerprints; done显示所有节点的 Factory_Config.json 文件
说明：显示集群中所有节点的 factory_config.json 文件内容
allssh "cat /etc/nutanix/factory_config.json"升级一个单一节点的 NOS 版本
说明：升级单一节点 NOS 版本匹配集群~/cluster/bin/cluster -u <NEW_NODE_IP> upgrade_node223

列出 DSF 文件（vDisk）
说明：为了存储 vDisks 列出 DSF 上的文件和相关信息
Nfs_ls获取帮助
Nfs_ls --help

安装 Nutanix Cluster Check(NCC)
说明：安装 Nutanix Cluster Check（NCC）健康检查脚本来测试潜在的问题和集群健康从 Nutanix Support Portal (portal.nutanix.com) 下载 NCC
SCP .tar.gz to the /home/nutanix directory
Untar NCC .tar.gz
tar xzmf <ncc .tar.gz file name> --recursive-unlink

运行安装脚本./ncc/bin/install.sh -f <ncc .tar.gz file name>创建链接source ~/ncc/ncc_completion.bash
echo "source ~/ncc/ncc_completion.bash" >> ~/.bashrc

运行 Nutanix Cluster Check (NCC)
说明：运行 Nutanix Cluster Check (NCC) 健康检查脚本来测试潜在的问题和集群健康，集群故障时这是排查的第一步

确保 NCC 已经安装（以上步骤）运行 NCC health checks
ncc health_checks run_all

使用进程监控命令行列出任务
224

progress_monitor_cli -fetchall

使用进程监控命令行移除任务progress_monitor_cli --entity_id=<ENTITY_ID> --operation=<OPERATION> -entity_type=<ENTITY_TYPE> --delete# NOTE: operation and entity_type should be all lowercase with k removed from the begining

4.7.3 指标和阈值
以下部分将涉及 Nutanix 后台具体的指标和阈值。更多更新即将推出！

4.7.4 Gflags

4.7.5 故障排除和高级管理查找 Acropolis 日志说明：查找 Acropolis 的集群日志allssh "cat ~/data/logs/Acropolis.log"

查找集群错误日志
说明：为集群查找错误日志
allssh "cat ~/data/logs/<COMPONENT NAME or *>.ERROR"

Stargate 示例
allssh "cat ~/data/logs/Stargate.ERROR"

查找集群致命日志说明：为集群查找致命日志
allssh "cat ~/data/logs/<COMPONENT NAME or *>.FATAL"

Stargate 示例
225

allssh "cat ~/data/logs/Stargate.FATAL"

使用 2009 页面(Stargate)

在大多数情况下，Prism 能够提供所有需要的信息和数据。然而，在某些情况下，如果需要一些更详细的数据，你可以利用 Stargate 的 2009 页。2009 页可以通过导航
到<CVM IP>：2009 查看。
访问后端页
如果你在不同的网段（L2 子网），你需要添加一个访问规则来访问任何后端页。

在页面的顶部是概述细节显示有关集群的各种详细信息：

图. 2009 页 - Stargate 概述
在本段有两个区域要留意，第一个是 I/O 队列，显示 admitted / outstanding 操作的数量。

该图显示了概述的队列部分：226图
14-2 2009 页 - Stargate 概述 – 队列
第二部分是内容缓存的细节,显示了高速缓存大小的信息和命中率
该图显示了概述的内容缓存部分图14-3 2009 页 - Stargate 概览 – 内容缓存专家提示
在理想的情况下，如果工作负荷使用了最好的读取性能命中率应高于 80％-90％+

注意：这些值是每个 Stargate / CVM
接下来的部分是“集群状态”，显示集群中不同的 Stargate 详细信息和它们的磁盘使用率。
下图显示了 Stargate 和磁盘利用率（可用/全部）：图. 2009 页 - 集群状态 - 磁盘使用情况

接下来的部分是“NFS Slave”部分，显示每个虚拟磁盘的各种详细信息和统计信息。
下图显示了虚拟磁盘和各种 I/O 的详细信息：227图
14-5 2009 页- NFS Slave - 虚拟磁盘统计专家提示
当看到任何潜在的性能问题请关注下几点：Avg. latency
Avg. op size
Avg. outstanding
欲了解更多具体细节请浏览 vdisk_stats 页面。

使用 2009 / vdisk_stats 页2009 vdisk_stats 页提供了每个虚拟磁盘进一步的数据点。此页面包括细节和随机条带图，延迟条带图，I/O 大小和工作组的细节。
可以通过在左栏点击“vDisk Id”导航到 vdisk_stats 页面。
下图显示了部分和超链接的虚拟磁盘 ID：

图. 2009 页 - 托管虚拟磁盘详细的虚拟磁盘统计。注：这些值是实时的，并且可以通过刷新页面更新。

228

第一个关键区域是“Ops and Randomness”部分，显示 I/O 模式是否在本质上随
机或顺序。
该图显示了“操作和随机性”部分：

图. 2009 页 - 虚拟磁盘统计 – 操作和随机性下一个区域显示前端读写的条带图和 I/O 延迟该图显示了“前端读取延迟”条带图：图
14-8 2009 页 - 虚拟磁盘统计 - 前端读取延迟该图显示了“前端写入延迟”条带图：图
14-9 2009 页 - 虚拟磁盘统计 - 前端写延迟

接下来的关键区域是 I/O 大小分布，显示读取的条带图和写入 I/O 的大小。
229

该图显示了“Read Size Distribution”条带图：图
14-10 2009 页 - 虚拟磁盘统计 - 读 I/O 大小

下图显示了“Write Size Distribution”条带图：图
14-11 2009 页 - 虚拟磁盘统计 - 写 I/O 大小

接下来的重点区域是“Working Set Size”部分，提供有关 Working Set Size 的最后 2
分钟和 1 小时的详细信息。细分为读写 I/O。

下图显示了“Working Set Sizes”表：图. 2009 页 - 虚拟磁盘统计 - Working Set Sizes

230

“Read Source”提供该层或位置的读 I/O 信息。

下图显示了“Read Source”的详细信息：

图. 2009 页 - 虚拟磁盘统计 - Read Source

专家提示如果您看到高的读取延迟，看一下虚拟磁盘的读源，并看一下 I/O 的服务源。在大多数情况下，高延迟可以通过读取来自 HDD（Estore HDD）引起的。

“Write Destination”部分将显示其中新写入的 I/O。

该图显示了“Write Destination”表：231

图. 2009 页 - 虚拟磁盘统计 - Write Destination

专家提示
随机或更小的 I/O（<64K）将被写入到 OPLOG。较大的或顺序的 I/O 将绕过OPLOG 和直接写到盘区存储（ESTORE）。

另一个有趣的数据是什么数据通过 ILM 被从 HDD 硬盘迁移到 SSD 固态硬盘。在'Extent Group Up-Migration “表显示，在过去 300、3600 和 86400 秒已经迁移的数
据。

下图显示了“Extent Group Up-Migration ”表：图.

2009 页 - 虚拟磁盘统计 - Extent Group Up-Migration

使用 2010 页（Curator）

232

2010 页是用于监控 Curator MapReduce 框架的详细页面。该页面提供了作业、
扫描和相关任务的详细信息。
您可以通过导航到 http://<CVM IP>:2010。注意：如果你不是 Curator Master 请点击“Curator Master:”后的 IP。
页面的顶部将显示 Curator Master 细节包括正常运行时间、版本等等。
下一节是“Curator Nodes”表，它显示有关集群中的节点、角色和健康状况的各种细节。这些节点将被用于分布式进程和选举任务。
该图显示了“Curator Nodes”表：图. 2010 页 - Curator Nodes

接下来的部分是“Curator jobs”表，该表显示已完成或当前正在运行的作业。
作业有两种主要类型，部分扫描是每隔 60 分钟，全面扫描是每 6 小时。注意：
基于利用率和其他活动的时间是可变的。
这些扫描将定期调度运行，也可以由某些集群事件触发。
这里有一些工作执行的原因：•

定期（正常状态下）•磁盘/节点/机箱失效

•ILM 失衡•磁盘/层失衡下图显示“Curator Jobs”表:233

图. 2010 页 - Curator Jobs

该表显示了一些由每个作业进行的高级别活动
Table 0. Curator 扫描任务
活动

全扫描

局部扫描

ILM

X

X

磁盘平衡

X

X

压缩

X

X

重复数据删除

X

擦除编码

X

垃圾清理

X

点击“Execution id”将带您到作业详细信息页面，该页面显示各种统计工作，以及所产生的任务。
在页面的顶部表将显示在工作中的各种信息的类型、原因、任务和持续时间。
接下来的部分是“后台任务统计”表，该表上的任务类型显示各种信息，产生量和优先级。
下图中显示作业详细信息表：234

图. 2010 页 - Curator Job – 详细信息该图显示了“后台任务统计”表：图. 2010 页- Curator Job – 任务

接下来的部分是“MapReduce 任务”表，该表显示了每个 Curator job 开始实际的
MapReduce 工作。局部扫描将有一个单一的 MapReduce 工作，全面扫描，将有四个 MapReduce 工作。
下图显示“MapReduce Jobs”表235

图. 2010 页- MapReduce 作业

点击“Job ID”将带您到 MapReduce 工作的详细信息页面，该页面会显示任务的状态，各种计数器以及关于 MapReduce 工作细节。
图中显示了一些工作的计数器的示例：

图. 2010 页- MapReduce 作业-计数器

236

主页上的下一个部分是“Queued Curator Jobs”和“Last Successful Curator
Scans”部分。这些表显示当定期扫描正常运行时，最后一次成功扫描的详细信息。
该图显示了“Curator 作业队列”和“Curator 最后一次成功扫描”部分：

图. 2010 页 - 队列和成功扫描高级命令行说明

Prism should provide all that is necessary in terms of normal troubleshooting andperformance monitoring. However, there may be cases where you want to get moredetailed information which is exposed on some of the backend pages mentioned
above, or the CLI.
Prism 提供所有用于普通排错和性能监控的必须信息。但是可能有些事件中，你需要
拿到更多在某些后端页面显示的详细信息或者命令行。
vdisk_config_printervdisk_config_printer 命令显示集群中所有 vdisk 的信息列表。
比较重要的包括：
•
•
•
•
•
•
•

Vdisk ID
Vdisk name
Parent vdisk ID (if clone or snapshot)
Vdisk size (Bytes)
Container id
To remove bool (to be cleaned up by curator scan)
Mutability state (mutable if active r/w vdisk, immutable if snapshot)

以下是示例输出：237

vdisk_usage_printer -vdisk_id=<VDISK ID>
vdisk_usage_printer 用来获取 vdisk, 相关 extents 和 egroups 的详细信息。
比较重要的包括：
•
•
•
•
•
•
•

Egroup ID
Egroup extent countUntransformed egroup size
Transformed egroup size
Transform ratio
Transformation type(s)Egroup replica locations (disk/cvm/rack)

以下是示例输出：238

注：用于去重的 egroup 大小和非去重的 egroups 大小分别为 （1 vs. 4MB）。“数据结构”章节提到过，对于去重的数据， 1MB 的 egroup 有利于消除去重数据导致的可能的碎片。
curator_cli display_data_reduction_reportcurator_cli display_data_reduction_report 用来获取转换产生的容器存储节省的空间的详细信息（例如 clone, snap, dedup, compression, erasure coding 等等）。
比较重要的包括：
•
•
•
•
•
•

Container ID
Technique (transform applied)
Pre reduction Size
Post reduction size
Saved space
Savings ratio

以下是示例输出：239

curator_cli get_vdisk_usage lookup_vdisk_ids=<COMMA SEPARATEDVDISK ID(s)>curator_cli display_data_reduction_用来获取每种转换产生的容器存储节省的空间的详细信息（例如 clone, snap, dedup, compression, erasure coding 等等）。
比较重要的包括：
Vdisk ID
Exclusive usage (Data referred to by only this vdisk)
Logical uninherited (Data written to vdisk, may be inherited by a childin the event of clone)•
Logical dedup (Amount of vdisk data that has been deduplicated)•
Logical snapshot (Data not shared across vdisk chains)•
Logical clone (Data shared across vdisk chains)•••

以下是示例输出：240

curator_cli get_egroup_access_info
curator_cli get_egroup_access_info 用来获取基于最后访问（读）/修改（覆盖写或者写）的每个桶的 egroups 的数量。该信息用来评估适合用于纠删码的候选的egroup 的数量。
比较重要的包括：••

Container ID
Access \ Modify (secs)

以下是示例输出：241

5 第五部分：AHV
5.1 架构
5.1.1 节点架构在 AHV 的部署中，控制器虚拟机（CVM）以虚拟机形式运行，并通过 PCI 直通方式访问磁盘。这样就可以让 CVM 绕过虚拟化层直接控制 PCI 设备。AHV 是基于
CentOS KVM 基础开发的，采用全硬件虚拟化路线实现。

图. AHV 节点

AHV 虚拟化以 CentOS KVM 为基础并扩展了诸多高级功能，如 HA，在线迁移等。同时，AHV 虚拟化系统也通过了微软服务器虚拟化验证程序的认证，可以运行微软的操作系统及应用程序。

5.1.2 KVM 架构
KVM 包括以下的主要组件：KVM-kmodKVM 内核模块•
Libvirtdo 一个 API, 管理 KVM 和 QEMU 的后台进程和管理工具。负责 Acropolis
与 KVM / QEMU 通过 libvirtd 进程进行通迅•
Qemu-kvm•o242

o 一个模拟器（machina emulator），使得每一个虚拟机能够独立运行。 AHV 通过它来实现硬件辅助虚拟化，并同样支持虚拟机以全虚拟化
HVM 的形式运行。下图显示了各个组件之间的关系：

图 . KVM 组件关系

Acropolis 与 KVM 之间通过 Libvirtd 进行通迅。
处理器兼容性类似于 VMware 的增强 vMotion 兼容性(EVC) 功能，允许虚拟机在不同代处理器
之间进行移动；AHV 将自动检测集群中最低的处理器，并限制所有的 QEMU 域运行
在这个级别中。通过此功能允许包含跨代处理器的 AHV 集群中，提供虚拟机在主机间在线迁移的能力。

5.1.3 最高配置和可扩展性
以下是配置的最大限制及范围
l
集群最大数量（Maximum cluster size）: N/A – 跟 Nutanix 集群一样l每个 VM 的最大虚拟 CPU（Maximum vCPUs per VM）: 每台主机的最大物
理核数l每个 VM 的最大内存（Maximum memory per VM）: 4TB 或者可用物理内存
中的最小值

l

每个虚拟磁盘的容量: 9EB* (Exabyte)l每个节点的最大 VM 数量（Maximum VMs per host）: N/A – 取决于内存的分配限制l每个集群的最大 VM 数量（Maximum VMs per cluster）: N/A –取决于内存的
分配限制

243

*AHV 不像 ESXi / Hyper-V 这样传统的存储堆栈; 在 AHV 中，所有的磁盘以裸SCSI 块设备方式直通到虚拟机中。这意味着最大的虚拟磁盘容量仅受限于 DSF 的虚拟磁盘容量(最大 9 EB)。

5.1.4 网络AHV 为所有虚机网络采用了 Open vSwitch (OVS)。虚机联网是通过 Prism / ACLI 配
置的，每个虚拟机网卡都连接到一个 Tap 接口。
下图展示了 OVS 架构的概念图：图. Open vSwitch 网络
在前面的架构图中，你可以看到一些类型的组件:Open vSwitch (OVS)244

OVS 是一个开源软件交换机，在 Linux 内核中实现，设计用于多服务器虚拟化环境。默认情况下，OVS 的行为类似于维护 MAC 地址表的第 2 层学习交换机。
Hypervisor 主机和虚机接到交换机上的虚拟端口。
OVS 支持许多流行的交换机特性，包括 VLAN 标记、链路聚合控制协议
(LACP)、端口镜像和服务质量(QoS)等。每个 AHV 服务器维护一个 OVS 实例，所有
OVS 实例组合在一起形成一个逻辑开关。称为网桥的结构会管理驻留在 AHV 主机上的交换机实例。

Bridge网桥充当虚拟交换机，管理物理和虚拟网络接口之间的网络通信通路。默认的
AHV 配置包括一个名为 br0 的 OVS 桥接器和一个名为 virbr0 的本地 Linux 桥接器。
virbr0 Linux 网桥在 CVM 和 AHV 主机之间进行管理和存储通信。所有其他存储、主机和 VM 网络流量都通过 br0 OVS 桥接器。AHV 主机、虚机和物理接口使用“Port”来连接到网桥。

Port
端口是在表示到虚拟交换机的连接性的桥上创建的逻辑结构。Nutanix 使用几种
端口类型，包括内部端口、Tap、VXLAN 和 Bond:l

内部端口 - 与默认网桥(br0)同名的内部端口为 AHV 主机提供访问。

l

Tap 端口 - 充当虚拟网卡到虚机的桥梁连接。

l

VXLAN 端口 - 用于 Acropolis 提供的 IP 地址管理功能。

l绑定端口 - 为 AHV 主机的物理接口提供网卡组。

Bond绑定端口聚合 AHV 主机上的物理接口。默认情况下，名为 br0-up 的绑定组是在
bridge br0 中创建的。在节点创建映像过程后，所有的接口都放在一个绑定组内，这
是 Foundation 创建映像的过程的要求。对默认绑定端口 br0-up 的更改通常将其重命
名为 bond0。Nutanix 建议使用名称 br0-up 来快速识别作为桥接 br0 上行链路的接口。

245

OVS 绑定允许多种负载平衡模式，包括活动 active-backup、balance-slb 和balance-tcp。LACP 也可以在绑定端口激活。在安装期间没有指定“bond_mode”设
置，默认为 active-backup，这是推荐的配置。

上行链路负载平衡

在前一节中简要提到，跨绑定组上行链路的流量平衡是可能的。
以下键合模式可供选择:active-backupo 在一个活动适配器上传输所有流量的默认配置。如果活动适配器变得不可用，
则绑定中的另一个适配器将变为活动的。限制吞吐量最大可达单个网口的带宽。(推荐)• balance-slb
在连接的适配器之间平衡每个虚机的网卡 (例如 VM A nic 1 - eth0 / nic 2 - eth1)。
将虚拟机网口的吞吐量限制为单个网口的带宽，但是具有 x 个网口的虚拟机可以
利用 x *适配器带宽(假设 x 对于绑定中的虚机网口和物理上行适配器的数量是相同的)。注意:对于多播流量有一些注意要求••

balance-tcp / LACP
在绑定的适配器之间平衡每个虚机网口的 TCP 会话。将每个网口的吞吐量限制为
最大连接带宽(物理上行适配器数量*速度)。需要链接聚合，并在需要 LACP 时使用。
你可以在 AHV Networking 手册中找到绑定模式的其他信息 (LINK).

VM 网卡类型

AHV 支持以下两种虚拟机网络接口类型：
Access(默认)•Trunk(4.6 版本以及上)默认情况下，虚拟机的网卡以 Access 模式创建(类似于您在端口组中所看到的虚•拟机网卡)，但是它也可以以 Trunk 接口方式连接到虚拟机操作系统。
Trunk 接口能通过以下命令行添加：246

vm.nic_create <VM_NAME> vlan_mode=kTrunked trunked_networks=<ALLOWED_VLANS>
network=<NATIVE_VLAN>

示例:
vm.nic_create fooVM vlan_mode=kTrunked trunked_networks=10,20,30 network=vlan.10

Service Chaining 服务链
作为网络路径的一部分，AHV 服务链功能允许截取所有流量，并转发给数据包
处理器（NFV，设备，虚拟设备等）用于后续处理。
服务链的常见用途：防火墙（如 Palo Alto 等）
负载均衡器（例如 F5，NetScaler 等）
IDS / IPS /网络监视器•••

在服务链中有两种类型的包处理器：

图. 服务链 – 包处理器
•
o
o
o
•
o
o

实时包处理器数据包通过 OVS 时实时拦截
可以修改和允许/拒绝数据包
常见用途：防火墙和负载均衡器
触发式包处理器
在数据包流动时检查，只能读取数据包流中的数据
常见用途：IDS / IPS /网络监视器

任何服务链接都是在应用流-微分割规则之后，并在包离开本地 OVS 之前完成
的。这发生在网络功能桥上(br.nf):247

图.服务链 – Flow
注意:可以在一条链中将多个 NFV /包处理器串在一起。

5.2 如何工作5.2.1 存储 I/O 路径
AHV 不像 ESXi / Hyper-V 这样传统的存储堆栈; 在 AHV 中，所有的磁盘以裸SCSI 块设备方式直通到虚拟机中。这样能够保持最佳和最轻量的 I/O 路径。

专家提示Acropolis 为最终用户抽象 kvm，virsh，qemu，libvirt 和 iSCSI，并处理所
有后端配置。 这允许用户通过 Prism / ACLI 将焦点集中在虚拟机上。 以下仅供参考，不建议使用 virsh，libvirt 等进行手动处理。
每一个 KVM 主机都有一个 iSCSI 重定向守护程序通过 NOP OUT 命令来检查
Stargate 的健康情况。
o 在 iscsi_redirector 日志中 (在 AHV 主机/var/log/的目录中), 可以看到每个Stargate 的健康状况:

注: 本地 Stargate 通过它的内部地址 192.168.5.254 显示
248

通过以下输出可以看出 iscsi_redirector 监听 127.0.0.1:3261 端口[root@NTNX-BEAST-1 ~]# netstat -tnlp | egrep tcp.*3261
Proto ... Local Address Foreign Address State

PID/Program name...
tcp ... 127.0.0.1:3261 0.0.0.0:*

LISTEN8044/python...

QEMU 配置 iSCSI Redirector 作为 iSCSI 目标门户。 在有登录请求时，iSCSIRedirector 将把 iSCSI 登录请求重定向到一个健康的 Stargate （默认本地优先）。

图 13-4 iSCSI 多路径-正常状态

请通过域 XML 文件查看配置：<devices>249

<emulator>/usr/libexec/qemu-kvm</emulator>...
<disk type='network' device='lun'><driver name='qemu' type='raw' cache='none' error_policy='report' io='native'/><source protocol='iscsi' name='iqn.2010-06.com.nutanix:vmdisk-16a5../0'><host name='127.0.0.1' port='3261'/></source><backingStore/><target dev='sda' bus='scsi'/><boot order='1'/><alias name='scsi0-0-0-0'/><address type='drive' controller='0' bus='0' target='0' unit='0'/></disk>...
</devices>

首选的控制器类型是 virtio-scsi（SCSI 设备的默认设置）。如果可以的话， IDE 设备
不推荐用于大多数场景。 为了将 virtio 与 Windows 一起使用，必须安装 virtio 驱动程
序，Nutanix 移动性驱动程序或 Nutanix VM tools,其中现代 Linux 发行版预装了
virtio。

...
<controller type='scsi' index='0' model='virtio-scsi'>

250

<driver max_sectors='2048'/><alias name='scsi0'/><address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/></controller>...

当一个活动的 Stargate 下线后(通过 NOP OUT 命令获取状态), iSCSI Redirector
将本地的 Stargate 标记为不健康状态。当 QEMU 试图发起一个 iSCSI 请求时，Redirector 将重定向此登录请求到一个健康的 Stargate 之上。

图.

iSCSI 多路径 – 本地 CVM 下线

251

一旦本地 CVM 重新上线（通过 NOP OUT 命令获得状态），远程的 Stargate 将结束所有的远程 iSCSI 会话。QEMU 将再次发送一个新的 iSCSI 登录请求并重定向到本地的 Stargate。

图. iSCSI 多路径 – 本地 CVM 上线传统 I / O 路径与每个系统管理程序和操作系统一样，用户和内核空间组件混合在一起，它们相互作
用以执行一个共同的活动。在阅读下面的文章之前，建议阅读“用户与内核空间”一节，以了解它们之间的相互作用。
当一个虚机执行 I/O 时，它将执行以下操作(为清晰起见，一些步骤已经被排除):
1.
2.
3.
4.
5.
6.

虚机的操作系统对虚拟设备执行 SCSI 命令
Virtio-scsi 接受这些请求并将它们放在客户的内存中
请求由 QEMU 主循环处理
Libiscsi 检查每个请求并转发
网络层将请求转发到本地 CVM(如果本地不可用，则从外部转发)Stargate 进程组处理请求下面显示了这个示例流程:252

图. AHV VirtIO 数据路径 – 经典
看看 Domain 的 XML，我们可以看到它是使用 qemu-kvm 模拟器:...
<devices><emulator>/usr/libexec/qemu-kvm</emulator>...

查看 AHV 主机，您可以看到 qemu-kvm 已经使用本地 Bridge 和 ip 建立了与正
常的 Stargate 的会话。对于外部通信，将使用外部主机和 Stargate IP 组。注意:每个磁盘设备将有一个会话(参见 PID 24845)[root@NTNX-BEAST-1 log]# netstat -np | egrep tcp.*qemu
Proto ... Local Address

Foreign Address

State

PID/Program nametcp ... 192.168.5.1:50410 192.168.5.254:3261 ESTABLISHED 25293/qemu-kvm
tcp ... 192.168.5.1:50434 192.168.5.254:3261 ESTABLISHED 23198/qemu-kvm
tcp ... 192.168.5.1:50464 192.168.5.254:3261 ESTABLISHED 24845/qemu-kvm

253

tcp ... 192.168.5.1:50465 192.168.5.254:3261 ESTABLISHED 24845/qemu-kvm...

现在在这个路径中有一些低效的地方，因为主循环是单线程的，而 libiscsi 会检
查每个 SCSI 命令。

Frodo I / O 路径（又名 AHV Turbo 模式）
随着存储技术的不断发展和效率的提高，我们可以进一步优化。鉴于我们完全控
制 AHV 和 Nutanix 堆栈，这是一个可以进一步提升的部分。
简而言之，Frodo 是 AHV 的一个高度优化的 I/O 路径，它允许更高的吞吐量、更低的延迟和更少的 CPU 开销。
专家提示
Frodo 功能会在 AOS 5.5.X 之后版本的虚拟机中被启用

当一个 VM 执行 I/O 时，它将执行以下操作(为清晰起见，一些步骤已经被排除):

1. VM 的操作系统对虚拟设备执行 SCSI 命令
2. Virtio-scsi 接受这些请求并将它们放在客户的内存中
3. 请求由 Frodo 处理
4. 自定义 libiscsi 附加 iscsi 头和转发
5. 网络层将请求转发到本地 CVM(如果本地不可用，则从外部转发)
6. Stargate 进程（组）处理请求

下图显示了这个示例流程:254

图. AHV VirtIO 数据路径– 经典
下面的路径看起来与传统的 I/O 很相似，除了一些关键的区别:•qemu 主循环被 Frodo (vhost-user-scsi)取代•frodo 向客户公开多个虚拟队列(VQs)(每个 vCPU 一个)•为多 vcpu 的虚拟机使用多个线程•libiscsi 被我们自己的更轻量级的版本所取代

对于客户端，它将注意到现在有多个用于磁盘设备的队列，而不是只看到性能改进。在某些情况下，与 Qemu 相比，执行 I/O 会减少 25%的 CPU 开销，并且性能会
提高 3 倍!与另一个 hypervisor 相比，我们已经看到执行 I/Os 的 CPU 开销下降了 3倍。
看看一个 AHV 主机，你会看到一个 frodo 进程为每个虚机 (qemu-kvm 进程)运行:

[root@drt-itppc03-1 ~]# ps aux | egrep frodo... /usr/libexec/qemu-kvm ... -chardev socket,id=frodo0,fd=3 \-device vhost-user-scsi-pci,chardev=frodo0,num_queues=16...

255

... /usr/libexec/frodo ... 127.0.0.1:3261 -t iqn.2010-06.com.nutanix:vmdisk...
...

看看域的 XML，我们可以看到它是用 frodo 模式:...
<devices><emulator>/usr/libexec/frodo</emulator>
...

专家提示
•
•

要利用 Frodo 的多线程/连接，必须在启用时让虚机 CPU>= 2 vCPU。
其特征如下:•o•o

1 vCPU 用户虚机:
1 Frodo 进程/ 会话每一个磁盘设备>= 2 vCPU 用户虚机:
2 Frodo 进程/ 会话每一个磁盘设备

在接下来的视频中，你可以看到 Frodo 进程已经建立了一个使用本地 Bridge 和
IP 的正常的 Stargate 会话。对于外部通信，将使用外部主机和 Stargate IP 地址。

[root@NTNX-BEAST-1 log]# netstat -np | egrep tcp.*frodo
Proto ... Local Address

Foreign Address

State

PID/Program nametcp ... 192.168.5.1:39568 192.168.5.254:3261 ESTABLISHED 42957/frodo
tcp ... 192.168.5.1:39538 192.168.5.254:3261 ESTABLISHED 42957/frodo
tcp ... 192.168.5.1:39580 192.168.5.254:3261 ESTABLISHED 42957/frodo

256tcp ... 192.168.5.1:39592 192.168.5.254:3261 ESTABLISHED 42957/frod

5.2.2 IP 地址管理
Acropolis IP 地址管理(IPAM) 解决方案提供了 DHCP 段以及分配 IP 地址到虚拟机的能力。IPAM 利用了 VXLAN 和 OpenFlow 规则去中断和响应 DHCP 请求。
这里我们通过一个示例来展示通过本地 Acropolis master 上 Nutanix IPAM 方案
的 DHCP 请求：

IPAM – 本地 Acropolis Master如果一个 Acropolis Master 是运行在远程的，同一个 VXLAN 隧道启用并处理网
图.

络请求。

257

图. IPAM – 远程 Acropolis Master

当然，传统的 DHCP / IPAM 方案也能够被用于“未管理”的网络场景之中。

5.2.3 VM 高可用性 (HA)AHV 虚拟机高可用性（HA）是一个用于在主机或机架在出现故障时确保虚拟机
高可用性的功能。当主机出现故障时，虚拟机将自动在集群中一个健康的节点上重新启动。Acropolis Master 负责重新启动虚拟机到健康的节点之上。
Acropolis Master 通过监控集群中所有主机上的 libvirt 来追踪主机的健康状态：图.

HA – 主机监控

258

当 Acropolis Master 出现分区、隔离或者失败时，一个新的 Acropolis Master 将
自动在集群中的健康节点中选举出来。如果一个集群出现分区的情况（举例来说，X节点不能与其他的 Y 节点通迅）时，仲裁侧的主机将保持在线，同时所有的虚拟机将
在这些主机上重新启动。

以下是两个主要的 HA 资源预留类型：•

缺省该模式不需要配置，安装基于 AHV 的集群时却生设置。当 AHV 主机不可用时，故障主机上的虚拟机会根据可用资源重启在剩下的主机，如果剩余主
机没有足够资源，不是所有受影响的虚拟机都会重启。
•
保证o 非缺省配置，当主机故障时，在集群 AHV 主机上预留空间确保所有受
故障影响的虚拟机都能重启在 AHV 集群的其它主机上。为了启用保证模式，选择启用 HA 选择框。会提示预留的内存数量和可以容忍的 AHV 主机故障数量。
o资源预留当使用保证模式，系统会预留主机资源。预留数量如下：
如果所有 container 时 RF2（FT1）相当于一个主机的资源•
如果任何 container 时 RF3（FT2）o 相当于两个主机的资源•o•

当主机内存容量不相等，系统使用最大主机内存决定每个主机预留多少资源。
预留分段会将资源预留在集群的所有主机上。这种场景下，每个主机为 HA 预留一个
百分比，确保整个集群在主机故障时有足够的故障切换的空间重启虚拟机。

下图显示了一个预留分段的示例场景：

259

图.

HA –预留分段

当一个主机失效时，其上运行的所有虚拟机将在集群中剩余的健康主机上重新启动。

图.

HA – 预留分段– 故障转移预留分段计算系统将自动计算总共的分段数量和每个主机上的预留值。下面我们将描述关于计算分段预留的一些细节。
Acropolis HA 使用固定分段去预留当主机失效时可以成功重新启动虚拟机的空间。这个分段容量与系统
中最大内存配置的虚拟机的内存一致。Acropolis HA 这个特色功能提供了组合多个小容量虚拟机到一个单一
的固定容量分段的能力。 在具有不同虚拟机容量的集群中，单一分段能够容纳多个虚拟机，因此可以减少固定容量的分段的碎片化。
最有效的虚拟机放置方式(最小数量的分段预留) 被定义成一个装箱问题，它是一个著名的计算机科学问题。最佳的解决方案是使用非确定性多项式（指数-科学术语），但是探索型的方案可能更适用于大部分通用场景。Nutanix 将继续提高虚拟机放置算法。我们期待在未来的版本中，通用场景仅有 0.25 的开销，当前碎
片的开销在 0.5 到 1 之间。每个配置的失效主机的总体开销在 1.5-2 之间。
当使用一个分段式的预留时，以下是一些关键的数据：

260

•
•
•

分段容量= 最大的虚拟机的内存(GB)最高负载的主机=最多运行虚拟机内存的主机(GB)碎片开销= 0.5 - 1

基于上述的输入，你能计算出预留分段的数量：
预留分段= (最高负载的主机/ 分段容量) x (1 + 碎片开销)

5.3 管理5.3.1 重要页*
5.3.2 命令参考在 OVS 上仅启动 10GbE 链路
说明: 在本机的 bond0 上将启用 10g 链路manage_ovs --interfaces 10g update_uplinks
说明: 在整个集群上仅启用 10g 链路
allssh "manage_ovs --interfaces 10g update_uplinks"

显示 OVS 上联链路说明: 在本机上显示 ovs 上联链路情况
manage_ovs show_uplinks
说明: 在整个集群上显示 ovs 上联链路情况
allssh "manage_ovs show_uplinks"

显示 OVS 接口261

说明: 显示本机的 ovs 接口
manage_ovs show_interfaces
说明: 显示整个集群的 ovs 接口
allssh "manage_ovs show_interfaces"

显示 OVS 交换机信息
说明: 显示交换机信息
ovs-vsctl show

列出 OVS 桥
说明:列出桥
ovs-vsctl list br显示 OVS 端口信息
说明: 显示 OVS 端口信息
ovs-vsctl list port br0
ovs-vsctl list port <bond>显示 OVS 接口信息
说明: 显示接口信息
ovs-vsctl list interface br0

在桥上显示端口/接口
说明: 显示上的端口
ovs-vsctl list-ports br0
说明: 显示桥上的 iface
ovs-vsctl list-ifaces br0262

创建 OVS 桥说明: 创建桥
ovs-vsctl add-br <bridge>

为桥添加端口说明: 为桥添加端口
ovs-vsctl add-port <bridge> <port>
说明: 为桥添加 bond 端口
ovs-vsctl add-bond <bridge> <port> <iface>显示 OVS bond 信息
说明: 显示 bond 信息
ovs-appctl bond/show <bond>

示例:
ovs-appctl bond/show bond0

设置 bond 模式并配置 LACP
说明: 在端口上启用 LACP
ovs-vsctl set port <bond> lacp=<active/passive>说明:启用所有主机上的 bond0
for i in `hostips`;do echo $i; ssh $i source /etc/profile > /dev/null 2>&1; ovs-vsctl set port bond0
lacp=active;done显示 bond 上的 LACP 信息
说明: 显示 LACP 细节

263

ovs-appctl lacp/show <bond>设置 bond 模式
说明: 设置端口的 bond 模式
ovs-vsctl set port <bond> bond_mode=<active-backup, balance-slb, balance-tcp>

显示 OpenFlow 信息
说明: 显示 OVS openflow 细节
ovs-ofctl show br0
说明: Show OpenFlow rules
ovs-ofctl dump-flows br0

得到 QEMU 进程 ID 和 top 信息
说明: 得到 QEMU 的进程 ID 信息
ps aux | grep qemu | awk '{print $2}'
说明: 得到指定进程 ID 的性能计量信息
top -p <PID>

得到所有 QEMU 进程的活动 Stargate
说明: 为所有 QEMU 进程得到活动的 Stargate 信息
netstat –np | egrep tcp.*qemu

5.3.3 计量与阈值
5.3.4 故障处理& 高级管理检查 iSCSI Redirector 日志说明: 检查所有主机的 iSCSI Redirector 日志

264

for i in `hostips`; do echo $i; ssh root@$i cat /var/log/iscsi_redirector;done

单个主机示例
Ssh root@<HOST IP>
Cat /var/log/iscsi_redirector

监控 CPU 闲置(闲置 CPU)说明: 监控 CPU 闲置情况执行 top 并查看 %st (如下)Cpu(s): 0.0%us, 0.0%sy, 0.0%ni, 96.4%id, 0.0%wa, 0.0%hi, 0.1%si, 0.0%st监控虚拟机网络资源状态说明: 监控虚拟机资源状态执行 virt-top
Virt-top查看网络页，可以按数字 2 进入网络页面。

6 第六部分：vSphere
6.1 架构
6.1.1 节点架构
在 ESXi 的部署中，控制器虚拟机（CVM）硬盘使用 VMDirectPath I/O 方式。这使得
完整的 PCI 控制器（和附加设备）通过直通方式连接 CVM 并绕过虚拟化层。

265

图. ESXi 的节点架构

6.1.2 最高配置和可扩展性
下面的最高配置和可扩展性的限制适用：•

最大集群大小：64•每个虚拟机的最大虚拟 CPU：128•每个虚拟机最大内存：4TB•

最大虚拟磁盘容量：62TB•

每台主机最大的虚拟机：1024•

每个集群最大的虚拟机：8000（如果启用 HA 2048 每个数据存储）

注：适用于 vSphere 6.0
专家提示
在 ESXi 主机执行基准测试时，必须将测试 ESXi 主机的电源策略设置为“高性能”。这会禁用 P-和 C-状态，保证测试结果没有人为限制。

6.1.3 网络266

每个 ESXi 主机有一个本地的 vSwitch 用来做 Nutanix CVM 和主机之间的内部通信。对于虚拟机和外部的通信则利用标准的 vSwitch（默认）和 dvSwitch 来实现。
本地 vSwitch (vSwitchNutanix)用来做 Nutanix CVM 和 ESXi 主机的本地通信。
主机上有 vmkernel 端口与 vSwitch (vmk1 - 192.168.5.1)相连， CVM 有一个接口绑定在内部 switch 的端口组上 (svm-iscsi-pg - 192.168.5.2)。这是一个私有的存储通信路径。
外部 vSwitch 可以是标准的 vSwitch 或者 dvSwitch，主要负责 ESXi 主机和CVM 的外部接口以及虚拟机在主机上所需要的端口组。外部 vmkernel 接口用来做主
机管理、vMotion 等。 外部 CVM 接口用来做和其他 Nutanix CVM 的通信。如果Trunk 上开启 VLAN，那么端口组就可以根据需要创建。
下图显示了 vSwitch 的结构:图.

ESXi vSwitch 网络概述上行和链路绑定策略267

推荐采用两个 ToR 交换机和上行链路 来保证交换机的 HA。系统默认的上行
接口是 active/passive 模式。具有 active/active 上行接口(e.g. vPC, MLAG, etc.)的
上行交换机可以用作其他的网络流量。

6.2 如何工作6.2.1 磁盘阵列卸载负载－VAAI
Nutanix 平台支持 VMware API 进行阵列集成（VAAI），它允许 hypervisor 卸载某些任务负载到阵列。这将使 Hypervisor 效率更高并且不需要“中间人”。Nutanix 目前支
持 NAS 的 VAAI 原语，包括“全文件克隆”，“快速文件克隆”和“预留空间”原语。这里
有一个很好的文章，解释的各种原语：http://cormachogan.com/2012/11/08/vaaicomparison-block-versus-nas/。
••••

克隆虚拟机有快照 - > VAAI 将不能使用
克隆虚拟机没有快照且处于关机状态 - > VAAI 将被使用
克隆虚拟机到不同的数据存储/容器 - > VAAI 将不能使用
克隆开机状态的虚拟机 - > VAAI 将不能使用

这些方案适用于 VMware View：•••

View 完整克隆（模板有快照） - > VAAI 将不能使用
View 完整克隆（模板没有快照） - > VAAI 将被使用
View 链接克隆（VCAI） - > VAAI 将被使用您可以验证 VAAI 的操作，通过使用“NFS 适配器”活动跟踪页面。

6.2.2 CVM Autopathing aka Ha.py
在本节中，我将介绍 CVM 的“失败”的处理方式。一个 CVM“ 失败”可能包括用户将
CVM 关机， CVM 升级，或任何可能会搞垮 CVM 的事件。DSF 有一个称为
autopathing 特征，其中当一个本地 CVM 变得不可用时，I/O 透明传递给集群中的其他 CVM 处理。Hypervisor 和 CVM 通信使用一个专用的 vSwitch 的私网地址
192.168.5.0（详见上图）。这意味着，对于所有存储的 I/O，这些都发生在 CVM 的内部 IP 地址（192.168.5.2）上。CVM 的外部 IP 地址用于远程复制和 CVM 通信。
下图显示了这样的一个例子：268

图. ESXi 主机网络

在一个本地的 CVM 故障的情况下，先前由本地 CVM 托管在本地 192.168.5.2 地址是
不可用的。DFS 将自动检测到该故障并通过万兆网络重定向这些 I/O 到集群中另一个
CVM 上。Hypervisor 和主机上运行的虚拟机将以透明的方式重新路由。这意味着，即使一个 CVM 关机，虚拟机仍然会继续能够执行 I/O。一旦本地 CVM 的还原并可用，流量随后将无缝地转交给本地 CVM 继续服务。

下图显示了如何寻找一个失败的 CVM 的图示：

图 . ESXi 主机网络 - 本地 CVM 下线

6.3 管理6.3.1 重要页*
6.3.2 命令参考
269

ESXi 的集群升级说明：使用 CLI 执行 ESXi 主机的自动升级＃上传离线升级包到 Nutanix NFS 容器＃登录到 Nutanix CVM＃进行升级cluster --md5sum=<bundle_checksum> --bundle=</path/to/offline_bundle> host_upgrade# 示例
cluster --md5sum=bff0b5558ad226ad395f6a4dc2b28597 --bundle=/tmp/VMware-ESXi-5.5.0-1331820depot.zip host_upgrade

重新启动 ESXi 主机服务
说明：以一个增量的方式重新启动每个 ESXi 主机服务for i in `hostips`;do ssh root@$i "services.sh restart";done

显示 ESXi 主机的网卡“up”状态说明：显示 ESXi 主机的在“UP”状态的网卡
for i in `hostips`;do echo $i && ssh root@$i esxcfg-nics -l | grep Up;done

显示 ESXi 主机的 10GbE 网卡和状态说明：显示 ESXi 主机的 10GbE 网卡和状态
for i in `hostips`;do echo $i && ssh root@$i esxcfg-nics -l | grep ixgbe;done

显示 ESXi 主机的活动适配器
说明：显示 ESXi 主机的工作，待机和未使用的适配器
for i in `hostips`;do echo $i && ssh root@$i "esxcli network vswitch standard policy failover get --vswitchname vSwitch0";done

显示 ESXi 主机路由表
说明：显示 ESXi 主机的路由表
for i in `hostips`;do ssh root@$i 'esxcfg-route -l';done检查 VAAI 在 Datastore 上是否启用说明：检查 VAAI 在 Datastore 上是否启用/支持
vmkfstools -Ph /vmfs/volumes/<Datastore Name>

270

设定 VIB 校验级别为 community supported
说明：设置 VIB 校验程度为 CommunitySupported 允许第三方安装 VIB
esxcli software acceptance set --level CommunitySupported

安装 VIB说明：不检查签名安装 VIB
esxcli software vib install --viburl=/<VIB directory>/<VIB name> --no-sig-check# 或者
esxcli software vib install --depoturl=/<VIB directory>/<VIB name> --no-sig-check检查 ESXi 的 ramdisk 的可用空间说明: 检查 ESXi ramdisk 可用空间
for i in `hostips`;do echo $i; ssh root@$i 'vdf -h';done

清除 pynfs 日志说明：清除每个 ESXi 主机上的 pynfs 记录
for i in `hostips`;do echo $i; ssh root@$i '> /pynfs/pynfs.log';done

6.3.3 指标和阈值 *6.3.4 故障排除和高级管理*

7 第七部分：Hyper-V
7.1 架构
当 Nutanix Hyper-V 集群创建时，会自动将 Hyper-V 主机加入指定的 Windows AD域。然后加入为虚拟机 HA 创建的 failover 集群。完成后，每个独立的 Hyper-V 主机
和 failover 集群都会有一个 AD 对象。

7.1.1 节点架构
在 Hyper-V 部署中，控制器虚拟机（CVM）作为一个虚拟机运行，并使用磁盘直通方式（passthrough）管理磁盘。

271

图. Hyper-V 的节点架构

7.1.2 最高配置和可扩展性
下面是最高配置和可扩展性的限制：•

最大集群大小：64•

每个 VM 最大的 vCPU：64•每个虚拟机最大内存：1TB•

最大虚拟磁盘容量：64TB•

每台主机最大的虚拟机：1024•

每个集群最大的虚拟机：8000

注：适用 Hyper-V 2012 R2 版本

7.1.3 网络每个 Hyper-V 主机有一个内部的虚拟交换机用来做 Nutanix CVM 和主机之间的
内部通信。对于虚拟机和外部的通信则利用外部的虚拟交换机（默认）或逻辑交换机
来实现。
272

内部交换机 (InternalSwitch)用来做 Nutanix CVM 和 Hyper-V 主机的本地通信。
主机上有 vmkernel 端口与 vSwitch (vmk1 - 192.168.5.1)相连， CVM 有一个接口绑定在内部 switch 的端口组上 (svm-iscsi-pg - 192.168.5.2)。 在这个内部交换机上，
主机有一个虚拟以太网接口 (vEth) (192.168.5.1)，CVM 在内部交换机上有一个虚拟以太网接口 vEth (192.168.5.2)。这是一个私有的存储通信路径。
外部 vSwitch 可以是标准的 vSwitch 或者逻辑交换机，主要负责 Hyper-V 主机和
CVM 的外部接口以及虚拟机在主机上所需要逻辑网络。外部 vEth 接口用来做主机管理、在线迁移等。 外部 CVM 接口用来做和其他 Nutanix CVM 的通信。如果 Trunk上开启 VLAN，那么就可以根据需要创建端口组。
下图显示了虚拟交换机的结构:

图. Hyper-V 虚拟交换机网络概览

上行和链路绑定策略273

推荐采用两个 ToR 交换机和上行链路来保证交换机的 HA。系统在交换机独立模式默认采用 LBFO 绑定 ，这无需其他特殊的配置。

7.2 如何工作7.2.1 磁盘阵列卸载负载－ODX
Nutanix 平台支持微软 Offloaded Data Transfer（ODX），允许 Hypervisor 卸载某些任务负载到阵列。这将使 Hypervisor 效率更高并且不需要“中间人”。Nutanix 目前为
SMB 支持 ODX，其中包括完整的复制和归零操作。然而，与 VAAI 中“快速的文件”
克隆操作（使用可写快照）相反，执行完全拷贝。鉴于此，更有效的方法是依靠本地
DSF 克隆，目前可以通过调用通过 nCLI、REST、或 Powershell CMDlets 命令。
目前 ODX 由以下操作调用：•在 DSF SMB 共享上的虚拟机或虚拟机文件副本•

SMB 共享文件副本

从 SCVMM 库（DSF SMB 共享）部署的模板 - 注：共享必须被添加到使用短名
称的 SCVMM 集群（例如，不是 FQDN）。一个简单的方法使这个条目添加到主机
文件的集群（例如：10.10.10.10 nutanix-130）。
ODX 不能通过以下操作来调用：•通过 SCVMM 克隆虚拟机•从 SCVMM 库（非 DSF SMB 共享）部署模板•

XenDesktop 的克隆部署

通过使用“NFS 适配器”的活动跟踪页面（是的 NFS，尽管正在通过 SMB 执行）可以验证 ODX 操作是否发生。当复制 vDISK 时该操作活动显示“NfsSlaveVaaiCopyDataOp”当一块磁盘置 0 时显示“NfsSlaveVaaiWriteZerosOp”。

7.3 管理7.3.1 重要页*
7.3.2 命令参考
在多台远程主机上执行命令274

说明：在一个或多个远程主机执行一个 PowerShell$targetServers = "Host1","Host2","Etc"
Invoke-Command -ComputerName $targetServers {<COMMAND or SCRIPT BLOCK>}

检查可用 VMQ Offloads
说明：显示特定主机 VMQ Offloads 的可用数量
gwmi –Namespace "root\virtualization\v2" –Class Msvm_VirtualEthernetSwitch | select elementname,
MaxVMQOffloads

禁用匹配特定前缀虚拟机的 VMQ
说明：禁用特定虚拟机的 VMQ$vmPrefix = "myVMs"
Get-VM | Where {$_.Name -match $vmPrefix} | Get-VMNetworkAdapter | Set-VMNetworkAdapter -VmqWeight0启用匹配特定前缀虚拟机的 VMQ说明：启用特定虚拟机的 VMQ$vmPrefix = "myVMs"
Get-VM | Where {$_.Name -match $vmPrefix} | Get-VMNetworkAdapter | Set-VMNetworkAdapter -VmqWeight1开机特定前缀的虚拟机说明：将特定前缀的虚拟机开机$vmPrefix = "myVMs"
Get-VM | Where {$_.Name -match $vmPrefix -and $_.StatusString -eq "Stopped"} | Start-VM

关机特定前缀的虚拟机说明：将特定前缀的虚拟机关机$vmPrefix = "myVMs"
Get-VM | Where {$_.Name -match $vmPrefix -and $_.StatusString -eq "Running"}} | Shutdown-VM RunAsynchronously

停止特定前缀的虚拟机275

说明：将特定前缀的虚拟机停止$vmPrefix = "myVMs"
Get-VM | Where {$_.Name -match $vmPrefix} | Stop-VM

获取 Hyper-V 主机的 RSS 设置
说明：获取 Hyper-V 主机 RSS(recieve side scaling 设置
Get-NetAdapterRss检查 Winsh 和 WinRM 连接
说明：通过执行一个简单的查询检查 Winsh 和 WinRM 连接/状态，应返回“the computer system object not
an error”
allssh "winsh "get-wmiobject win32_computersystem"

7.3.3 指标和阈值*

7.3.4 故障排除和高级管理*

8 第八部分：Nutanix 集群
8.1 AWS 上的 Nutanix 群集
AWS 上的 Nutanix 集群提供了使用裸金属资源的按需供应的集群。通过 Nutanix
平台的简单性，可以实现真正的随需应变能力。供应的集群看起来很像传统的 AHV
集群，只是运行在云提供商数据中心而已。

8.1.1 已支持的配置
解决方案适用于以下配置(列表可能不完整，请参考文档获得完全支持的列表:
核心使用场景：•按需/突发容量
•备份/ DR
276

•原生云•GEO 扩展/ 数据中心合并•应用程序迁移
•等等。
管理接口：
•

Nutanix 集群门户 – 资源供应•Prism Central (PC) – Nutanix 上层管理•AWS 控制台- AWS 管理

支持环境：
•

云:
AWS (EA)• EC2 基础实例类型:
o i3.metalo m5d.metalo z1d.metal
o

更新:
•

部分 AOS兼容特性:••

AOS 特性AWS 服务

8.1.2 关键术语 / 结构
在本节中使用的主要项目如下:•••Nutanix Clusters Portal
Nutanix 集群门户负责处理集群供应请求，并与 AWS 和所供应的主机进行交互。
它创建特定于集群的细节并处理动态云形成堆栈的创建。
Region
多个可用区域(地点)所在的地理地块或区域。一个区域可以有两个或多个 AZs。这
些区域可以包括 US-East-1 或 US-West-1。
Availability Zone (AZ)
AZ 由一个或多个离散的数据中心组成，通过低延迟链接相互连接。每个站点都有
自己的冗余电源、冷却系统、网络等。与传统的数据中心相比，这些被认为更有

277

•

•
•
•

弹性，因为 AZ 可以由多个独立的数据中心组成。这些可能包括 US-East-1a 或
US-West-1a 这样的站点。
VPC
租户的 AWS 云的逻辑隔离段。提供一种机制来保护和隔离环境。可以暴露给互联网或其他私有网络段(其他 vpc 或 vpn)。
S3
amazon 的对象服务，提供通过 S3 API 访问的持久对象存储。这用于存档/恢复
EBS面向对象 amazon 的卷/块服务，它提供可以附加到 ami 的持久卷。
Cloud Formation Template (CFT)
云形成模板简化了供应，同时允许您定义资源和依赖项的“堆栈”。然后可以将这个堆栈作为一个整体供应，而不是每个单独的资源供应。

8.1.3 架构从高层次上讲，Nutanix 集群门户是在 AWS 上提供 Nutanix 集群并与 AWS 进行
交互的主要接口。

设置过程可以概括为以下高级步骤：1.在 Nutanix 群集门户中创建群集
2.部署特定的输入（例如，区域，可用区，实例类型，VPC /子网等）
3. Nutanix Cluster Orchestrator 创建关联的资源
4. Nutanix AMI 中的主机代理通过 AWS 上的 Nutanix 群集签入
5.一旦所有主机都启动，集群就被创建了
以下内容展示了基于 AWS 交互的 Nutanix 群集的高层级概述：278

图. Nutanix Clusters on AWS - Overview
以下内容概述了群集协调器获取的输入和一些创建的资源：

图. Nutanix Clusters on AWS - Cluster Orchestrator Inputs
下面显示了 AWS 中节点的高级概述：279

图. Nutanix Clusters on AWS - Node Architecture鉴于主机是裸机，我们可以完全控制存储和网络资源，类似于典型的本地部署。
对于 CVM 和 AHV 主机引导，使用 EBS 卷。 注意：某些资源（例如 EBS 交互）通
过 AWS Nitro 卡运行，该卡在 AHV 主机中显示为 NVMe 控制器。

8.1.4 摆放策略默认情况下，AWS 上的 Nutanix 群集使用具有 7 个分区的分区放置策略。 主机
在与 Nutanix 中的机架相对应的这些分区中划分为条带。 这样可以确保您可以出现
1-2 个完整的“机架”故障，并且仍然保持可用性。

280

下面显示了分区放置策略和主机条带化的高层概览：

图. Nutanix Clusters on AWS - Partition Placement
在利用多种节点类型的情况下（例如 i3.metal 和 m5d.metal 等），每种节点类型
都有其自己的 7 个分区，节点在这些分区之间进行条带化。
下面显示了使用多种实例类型时分区放置策略和主机条带化的高层概览：

图. Nutanix Clusters on AWS - Partition Placement (Multi)

8.1.5 存储
AWS 上的 Nutanix 群集的存储可以分为两个核心区域：
1. 核心/活跃
2. 休眠

281

核心存储与您在任何 Nutanix 群集上所期望的完全相同，它将“本地”存储设备传递给 CVM，以供 Stargate 使用。
实例存储
鉴于“本地”存储由 AWS 实例存储支持，在断电/节点故障的情况下，该实例不能完全恢复。必须处理额外的注意事项。
例如，在本地 Nutanix 群集中，如果断电或节点发生故障，则存储将保留在本地设备上，并且当节点/电源恢复联机时，存储将恢复。 对于 AWS 实例存储，情况并非如此。
在大多数情况下，完全可用区应该不会掉电/宕掉，但是对于敏感的工作负载，建议：••

利用备份解决方案保留到 S3 或任何持久存储
将数据复制到其他 AZ /区域/云（本地或远程）中的另一个 Nutanix 群集

AWS 上 Nutanix 群集的一项独特功能是“休眠”群集的功能，使您可以在关闭EC2 计算实例的同时持久化数据。 这在您不需要计算资源并且不想继续为它们支付费用，但想要保留数据并能够在以后还原的情况下很有用。
集群休眠后，数据将从集群备份到 S3。 备份数据后，EC2 实例将终止。 恢复/还原后，将置备新的 EC2 实例，并将数据从 S3 加载到群集中。

8.1.6 网络连接网络连接可以分成几个重要部分：•

主机/群集网络连接• 客户/用户虚拟机网络连接• 广域网/L3 网络连接原生 vs. Overlay
我们决定不运行自己的覆盖网络，而是决定在 AWS 子网上本地运行，这允许平台上运行的 VM 与 AWS 服务进行本地通信，没有性能下降。

AWS 上的 Nutanix 群集已置备到 AWS VPC 中，以下内容显示了 AWS VPC 的
高层概览：

282

图. Nutanix Clusters on AWS - AWS VPC
新的 VPC vs. 默认的 VPCAWS 将创建默认的 VPC / Subnet / Etc。 每个区域都有 172.31.0.0/16 ip 方案。
建议使用适合您公司 IP 方案的关联子网，NAT / Internet 网关等创建新的 VPC。 如果您计划在 VPC 之间（VPC 对等）或到现有 WAN 扩展网络，则这一点很重要。 我将其视为 WAN 上的任何站点。

8.1.7 主机网络连接
在 AWS 裸机上运行的主机是传统的 AHV 主机，因此可以利用相同的基于 OVS的网络堆栈。
下面显示了 AWS AHV 主机的 OVS 堆栈的高层概览：283

图. Nutanix Clusters on AWS - OVS Architecture
除了添加了 L3 上行链路网桥之外，OVS 堆栈与任何 AHV 主机都基本相同。
对于 UVM（来宾虚拟机）网络，使用 VPC 子网。 可以在群集创建过程中或通过以下步骤创建 UVM 网络：
在 AWS VPC 仪表板中，单击“子网”，然后单击“创建子网”，然后输入网络详细
信息：

284

图. Nutanix Clusters on AWS - OVS Architecture
注意：CIDR 块应该是 VPC CIDR 范围的子集。
子网将从 VPC 继承路由表：

图.AWS 上的 Nutanix 群集-路由表在这种情况下，您可以看到对等 VPC 中的任何流量都将通过 VPC 对等链接，而任何
外部流量都将通过 Internet 网关。

285为了告诉 AOS 使用此网络，我们将标签添加到子网中。选择子网，然后单击“添加/编
辑标签”：

数

图.AWS 上的 Nutanix 群集-添加/编辑标签
添加密钥为“ ntnx：vlan”和该网络的 VLAN ID 的新标签：

数图.AWS 上的 Nutanix 群集-添加/编辑标签一旦子网在 AWS 端看起来不错，请使用以下命令“ subnet-manager-cli list-networks”
连接到 CVM 并发现新网络。这将查询 VPC 并列出子网。
286

数图.AWS 上的 Nutanix 群集-路由表
获取 AWS 子网 ID 后，使用以下命令“ allssh aws-subnet-manager add-network<SUBNET ID>”添加到 Acropolis。
数
图.AWS 上的 Nutanix 群集-添加网络
完成后，您将在 Prism 中看到该网络可用。

8.1.8 WAN / L3 网络
在大多数情况下，部署将不仅仅在 AWS 中，还需要与外部世界（其他 VPC，Internet 或 WAN）进行通信。
要连接 VPC（位于相同或不同区域），可以使用 VPC 对等连接，该对等连接允许您
在 VPC 之间建立隧道。注意：您需要确保遵循 WAN IP 方案的最佳做法，并且 VPC/子网之间没有 CIDR 范围重叠。
下图显示了 eu-west-1 和 eu-west-2 区域中的 VPC 之间的 VPC 对等连接：数

图.AWS 上的 Nutanix 群集-VPC 对等287

然后，每个 VPC 的路由表都将通过对等连接路由去往另一个 VPC 的流量（如果通信需要是双向的，则该流量表将在两端都存在）：数

图.AWS 上的 Nutanix 群集-路由表为了将网络扩展到本地/ WAN，可以利用 VPN 网关（tunnel）或 AWS Direct
Connect。

8.1.9 安全鉴于这些资源在我们完全控制的安全性之外的云中运行，因此数据加密和合规性是非常关键的考虑因素。
这些建议的特征如下：••••启用数据加密仅使用专用子网（不分配公共 IP）
锁定安全组和允许的端口/ IP CIDR 块
要获得更精细的安全性，请利用 Flow

8.1.10用法和配置

以下各节介绍如何在 AWS 上配置和利用 Nutanix 群集。
高层过程可以分为以下高层步骤：1. 创建 AWS 账户
2. 配置 AWS 网络资源（如有必要）3. 通过 Nutanix 群集门户配置群集
4. 预配完成后利用集群资源
288还有更多！

9 第九部分：存储服务
9.1 块服务
Acropolis Block Services (ABS) 的功能就是通过 iSCSI 提供后端的 DSF 存储给外部
的使用者（guest OS，物理主机，容器等）。
这将允许任何操作系统能够直接访问 DSF 利用存储的功能。在这种部署场景下，操
作系统绕过任何 Hypervisor 直接和 Nutanix 对话。
核心的 Acropolis Block Services 使用案例：• 共享磁盘
o Oracle RAC，Microsoft Failover Clustering 等• 首选的存储磁盘o 执行环境生命周期短但数据关键o 容器 s，OpenStack 等• 客户端发起的 iSCSI
o 当裸盘使用o Exchange on vSphere (支持 Microsoft)

认证的操作系统
根据 iSCSI 兼容性要求，以下操作系统通过了认证：• Microsoft Windows Server 2008 R2/2012 R2• Redhat Enterprise Linux 6.0+

块服务的概念以下组件构成了 Acropolis Block Services• Data Services IP：iSCSI 登录请求时使用的集群 IP 地址 （4.7 章节介
绍）• Volume Group：iSCSI 目标和磁盘组，在集中管理，快照和策略申请时使用• Disk(s)： 添加在 Volume Group 中的磁盘设备（就像 iSCSI 目标中的LUNs）
• Attachment：允许一个特定的发起者针对 Volume Group 的 IQN 准入• Secret(s)：NOTE: 在后端, 一个 VG 的 disk 就是一个在 DSF 上的 vDisk.
前提条件

289

在配置之前，需要先配置作为集中发现/登录门户的 Data Services IP，可以通过‘Cluster Details’ 页面(Gear Icon -> Cluster Details)来设置。

图.块服务-数据服务 IP
也可以通过 NCLI/API:创建目标在使用块服务之前，我们需要先创建一个 ‘Volume Group’作为 iSCSI 的目标
在‘Storage’页点击右手边的‘+ Volume Group’，

图. 块服务-添加卷组
在展开的菜单中需要指定 VG 的详细信息：290

图.块服务-添加 VG 细节
然后点击‘+ Add new disk’添加任何磁盘到目标中。在随后出现的菜单中允许我们选择目标容器和磁盘大小。

图.块服务-添加磁盘点击‘Add’。如果你需要添加多个磁盘，可以重复这个步骤。

291

当我们制定详细信息并添加完磁盘，我们可以将 Volume Group 附加到虚拟机或者
IQN 的发起者，这将允许虚拟机访问 iSCSI 目标（来自不明发起者的请求会被拒绝）

图. 块服务 – 发起者 IQN/VM
点击‘Save’，Volume Group 配置完成。
以上配置也可以通过 ACLI／API 来完成:
#创建 VG#添加磁盘到 VG#附加发起者 IQN 到 VG

路径 HA
前面提到，Data Services IP 让我们在不需要知道私有的 CVM IP 地址的情况下也能进行发现操作。

292

Data Services IP 被分配到当前的 iSCSI Master，一旦出现故障，一个新的 iSCSIMaster 会被选举出来且自动分配这个 Data Services IP。这种机制确保了 discovery
portal 始终可用。
配置了 Data Services IP 的 iSCSI 发起者会作为 iSCSI 目标入口。当有一个登录请求
时，平台会执行一个重定向到健康 Stargate 的 iSCSI 登录。

图.Block Services - 重定向登录
当出现活动的关联 Stagate 失效时，发起者会尝试让 iSCSI 登录到 Data Services
IP。这时，Data Services IP 将登录重定向到另一个健康的 Stargate。

图.Block Services - 故障接管
当出现问题的关联 Stargate 恢复正常且可用，当前活动的 Stargate 会静默 I/O 并结
束活动的 iSCSI 会话。当发起者重新尝试进行 iSCSI 登录时，Data Services IP 将登
录重定向到回复正常的关联 Stargate。

293图.块服务 - 自动恢复
健康监控和默认参数块服务中 Stargate 的有效性是通过 Zookeeper 来监控的，使用的是像 DSF 一样
的机制。
故障自恢复默认时间是 120 秒，这就意味着一旦关联 Stargate 恢复健康后超过
2 分钟，将静默并关闭会话，从而强制发起另外一个登录请求，使登录返回到恢
复正常的关联 Stargate。

通过这种机制，客户端多路径（MPIO）不再需要 path HA。现在我们不需要在连接
到发起者的同时去检查“Enable multi-path”选项（这个选项是启用 MPIO 的）图.块服务 -无需 MPIO
多路径
iSCSI 协议为每个目标在发起者和目标之间设置一个单独的 iSCSI 会话（TCP 链接）。这就是说，Stargate 和目标之间是一对一的关系。
如 4.7 章节所描述，默认有 32 个虚拟的目标在附加发起者和将每个磁盘添加到
volume group（VG）时自动创建完成。当创建多个 VG，并且每个 VG 只包含一个磁盘时，每个磁盘会提供一个 iSCSI 目标。
当我们通过 ACLI／API 查看 VG 详细信息时，你会看到为每个 attachment 创建出来的 32 个虚拟目标。

在这里，我们已经创建出来一个添加了 3 个磁盘设备的 VG，当在客户端发起搜索时，我们会看到每个磁盘设备都有一个自己的目标。（使用‘-tgt[int]’后缀）294图. 块服务 - 虚拟目标这样每个磁盘设备都有一个自己的 iSCSI 会话，并且这些会话能够在多个 Stargate
之间调度，增加可扩展性和提高了性能。

图.块服务 - 多路径
当为每个目标都建立了 iSCSI 会话(iSCSI 登录)，负载均衡就实现了。
活动路径使用以下命令查看驻留虚拟目标的活动 Stargate(s)：295如 4.7 章节说说，当分配目标要横跨集群节点时，如果需要，我们会用到 hash 算法。当我们要在健康节点中设置一个优先节点时到也会用到 hash 算法。
SCSI UNMAP (TRIM)
当我们需要从已删除的数据块中回收存储空间时，Acropolis Block Services 支
持符合 SCSI T10 规格的 SCSI UNMAP (TRIM) 命令行。

9.2 文件服务文件服务特性允许用户将 Nutanix 平台当作一个高可用的文件服务器。用户可以在一
个单一命名空间中存储主目录和文件。
支持的配置
文件服务支持如下配置（列表不完整，请参考手册获取完全的支持列表）：
虚拟化层
•
AHV
•
ESXi
文件协议：
•
CIFS2.1
兼容特性：•
Async-DR这个特性由以下一系列高级别的概念构成：
•
文件服务器
◦
高级别命名空间。每个文件服务器拥有自己的一组文件服务虚拟机。
•
共享◦
开放给用户的共享。一个文件服务器可以拥有多个共享（例如部门级共享等等）•
文件夹
存储文件的文件夹。文件夹在文件服务虚拟机间共享下图是这些高级别概念之间的映射关系：296

图. 文件服务关系映射
文件服务特性遵从与 Nutanix 平台相同的分布式方法论，确保可用性和扩展性。文件
服务器部署需要最少三个文件服务虚拟机下图是这些组件的细节：

图. 文件服务的细节支持的协议
4.6 版本中，SMB（最高到 2.1 版本）是唯一受支持的客户端与文件服务通讯的协议。
297

文件服务虚拟机作为代理虚拟机运行在平台上，并且是在配置过程中被透明地部署的。
下图是 Acropolis 平台上文件服务虚拟机的细节：

图. 文件服务虚拟机部署架构认证与授权
文件服务特性与微软活动目录（AD）和 DNS 完整集成。这样就可以利用 AD 中所有
安全的和已有的认证和授权功能。所有的共享权限、用户和组管理也可以在传统的负责 Windows 文件管理的 MMC 中完成。在安装过程中，会创建下列 AD/DNS 对象：•
文件服务器的 AD 计算机账户•
文件服务器和每个文件服务虚拟机的 AD Service Principal Name（SPN）•
指向所有文件服务虚拟机的文件服务器 DNS 条目•
每个文件服务虚拟机的 DNS 条目
用于文件服务器创建的 AD 特权
因为需要创建 AD 和 DNS 对象，所以必须使用域管理员或同等特权的用户账户来部
署文件服务特性。
高可用（HA）
每个文件服务虚拟机借助 Acropolis Volumes API 通过 in-guess iSCSI 来访问自己的数据存储。当文件服务虚拟机宕机时，任意文件服务虚拟机就可以连接任意 iSCSI 目
标。
下图是文件服务虚拟机存储的上层概览：298

图.文件服务虚拟机存储
文件服务虚拟机借助 DM-MPIO 提供路径高可用，DM-MPIO 缺省将活动路径设置在
本地 CVM：

图. 文件服务虚拟机 MPIO
当本地 CVM 不可用（例如活动路径中断）时，DM-MPIO 会激活一条到远端 CVM 的
故障转移路径，这条路径会继续接管处理 IO。

图 . 文件服务 MPIO 故障转移
当本地 CVM 恢复正常并且健康时，它会被标记为活动路径为本地 IO 提供服务。
正常工作环境中，每个文件服务虚拟机都会与自己的作为数据存储的 VG 通讯，并保
持到其它 VG 的备用连接。作为 DFS 受访进程的一部分，每个文件服务虚拟机都有一个供客户端与自身通讯的 IP。但是客户端不需要知道每个独立的文件服务虚拟机的IP，因为 DFS 受访进程会连接客户端到承载它们文件夹的正确 IP。

299

图. 文件服务虚拟机的工作模式
当文件服务虚拟机“故障”（例如人工维护、断电等）时，故障文件服务虚拟机的 VG
和 IP 都会被另一个文件服务虚拟机接管，确保客户端的可用性。
下图是故障文件服务虚拟机的 IP 和 VG 转移过程：300

图. 文件服务虚拟机故障场景
当故障文件服务虚拟机恢复正常并且稳定时，它会重新接管自己的 IP 和 VG 继续为客户端 IO 提供服务。

9.3 对象存储服务Nutanix Objects 功能通过一个符合 S3 的 API 提供了高度可扩展的持久对象服务（有关 S3 的更多信息：LINK）。由于 Nutanix Objects 已部署在 Nuatnix 平台之上，因此它可以利用 AOS 功能，如重复数据删除，压缩，复制等。Objects 是在
AOS 5.11 中引入的。

支持的配置
该解决方案适用于以下配置（列表可能不完整，请参阅文档以获取完全支持的列
表）：
核心用例：
301

•
•

备份
大数据/分析

管理界面：•

Prism Central（PC）

Hypervisor(s)：•N/A-运行在 Nutanix MSP 的。（取决于受 MSP 支持的 Hypervisors）

升级：
•

LCM

兼容功能：
•

TBI

Object 协议：•

S3（版本 4）

Nutanix 微服务平台（MSP）
Nutanix Object 利用 Nutanix 微服务平台（MSP），并且是这样做的首批核心服务之一。
Nutanix MSP 提供了一个通用框架和服务来部署 Object 组件的关联容器和平台服务，例如身份和访问管理（IAM）和负载平衡（LB）。

关键条款在本节中将使用以下关键术语，并在以下术语中进行定义：
Bucket向用户公开并包含 Object 的组织单位（与文件服务器上的文件共享）。一个部
署可以而且通常会有多个 Bucket（例如部门，分区等）。
• Objecto 通过 API (GET/PUT)接口的存储和项的实际单元(blob)• S3o 该术语用于描述引入的原始对象服务 Amazon Web Services（AWS）。现在在
语法上用于对象服务。S3 还用于定义在整个项目中都得到高度利用的 Object
API。
•

o

该图显示了概念结构的高级映射：

302

数字

图.Objetc-层次结构

Object 构造
此功能由一些高级构造组成：•

Load Balancer
负载平衡器是 Nutanix MSP 的一部分，并充当服务和数据请求的代理。这样可
以确保 Object 容器之间的服务和负载平衡具有高可用性。
Service Managero 服务管理器充当所有 UI 请求的端点，并管理 Object 存储实例。它还负责从实例收集统计信息。
Metadata Servero 元数据服务器负责包含 Nutanix Object 部署周围的所有元信息（例如buckets，Object 等）。利用 ChakrDB，这是 Nutanix 开发的基于 RocksDB 的键值存储。ChakrDB 使用 Nutanix ABS 进行存储。
Object Controller
o Object Controller 负责管理对象数据并与元数据服务器协调元数据更新。它通
过存储代理 API 与 Stargate 连接。
Region Manager
o Region Manager 负责管理 Acropolis DSF 上的所有对象存储信息（例如，区域）。
Regiono Region 提供 Object 与 Nutanix vDisk 上相应位置之间的高级映射。类似于虚拟磁盘 ID，偏移量和长度。
Atlas Serviceo Atlas Service 负责 Object 生命周期策略的实施和执行垃圾收集。
o

•

•

•

•

•

•

该图显示了 Object 服务体系结构的详细视图：

303

数字

图.Object-建筑
Objects 特定的组件以 Nutanix 绿色突出显示。对于 Objects，没有“覆盖”的概念，因此 CxxD 与 CRUD（创建/替换/更新/删除）不相关。对象“覆盖”的常用方法是创建新修订版或创建新对象并指向新对象。

Object 存储和 I / O
Object 存储在称为区域的逻辑结构中。区域是虚拟磁盘上固定的空间段。
该图显示了虚拟磁盘与区域之间的关系的示例：

304

数字

图.Objects-vDisk Region
较小的 Objects 可能适合单个区域（区域 ID，偏移量，长度）的块，而较大的Objects 可能会在各个区域上出现条纹。当大型 Objects 跨多个区域划分条带时，这些区域可以托管在多个 vDisk 上，从而可以同时利用多个 Stargate。
该图显示了 Object，chunk 和 region 之间的关系的示例：

数字

图.对象-对象块
Object 服务功能采用与 Nutanix 平台相同的分发方法，以确保可用性和可扩展
性。作为 Objects 部署的一部分，将至少部署 3 个 Objects VM。

305

10 第十部分：网络服务
10.1 Flow（微分段）
Flow 是一种分布式状态防火墙，可在 AHV 平台上运行的实体以及与其通信的外部事物之间进行精细的网络监视和实施。

支持的配置
该解决方案适用于以下配置（列表可能不完整，请参阅文档以获取完全支持的列
表）：
核心用例：
•

微分段

管理界面：
•

Prism Central（PC）

支持的环境：•本地：
o AHV（从 AOS 5.10 开始）
• 云：
o

升级：
•

AOS 的一部分

兼容功能：
•
•

Service Chaining
Calm
Epoch
通过 Prism Central 定义策略并分配类别来完成配置。这允许在中央位置进行配

置，并将其推送到许多 Nutanix 群集。每个 AHV 主机都使用 OpenFlow 实施规则。

实现结构
在 Nutanix Flow 中，有一些关键的结构：

类别

306

类别用于定义要对其应用策略和实施的实体组。它们通常适用，但不限于：环境，应用程序类型，应用程序层等。
••

类别：Key/Value“Tag”
示例：app app | tier | group | location | subnet 等等
例如，提供生产数据库服务的 VM 可能具有以下分配的类别：•••

AppTier：数据库
AppType：MySQL
Environment：生产
然后，策略可以利用这些类别来决定要应用哪些规则/动作（也可以在 Flow 上下

文之外利用）。

安全规则
安全规则是已定义的规则，并确定已定义类别之间允许的内容。

图.Flow - Microsegmentation - Rules
有几种类型的安全规则：•应用规则o 这是通用规则，可让您定义允许/拒绝的传输方式（TCP / UDP），端口和源/目的地。
o [允许|拒绝]传输：端口[至|发件人]o 示例：允许 TCP 8080 从 Category：Tier：Web 到 Category：Tier：App• 隔离规则o 拒绝两个类别之间的流量，允许类别内的流量o 示例：将租户 A 与租户 B 分开，克隆环境并允许在不影响正常网络通信的情况
下并行运行。
• 隔离规则o 拒绝指定 VM /类别的所有流量
o 例如：VM A，B，C 感染了病毒，请将其隔离以阻止病毒进一步感染网络下面显示了一个示例，该示例利用 Flow-微分段来控制示例应用程序中的流量：

307

数

图.Flow-微分段-示例应用执行执行决定匹配规则时将采取什么措施。使用 AHV Flow-微分段，有两种执行类型：•

应用通过允许定义的流并丢弃所有其他流来实施策略。
• 监控o 允许所有流，但是在策略可视化页面中突出显示任何可能违反该策略的数据包。
oFlow-微分段规则在数据包离开 UVM 后首先应用于该数据包。这发生在微分段桥
（br.microseg）中：

数字 t

图.流量-微分段-流量308

10.2 Epoch（网络监控/ DPI）
待续

11 第十一部分：备份容灾服务11.1 Leap（策略驱动的灾难恢复/运行手册）
Nutanix Leap 功能提供了通过 Prism Central（PC）配置的策略驱动的备份，灾难恢复和运行手册自动化服务。该功能建立在 AOS 上多年来在 PE 中配置的本机 DR
和复制功能之上，并对其进行了扩展。有关用于复制等的实际后端机制的更多信息，请参阅“Acropolis”中的“备份和灾难恢复（DR）”部分。Leap 在 AOS 5.10 中引入。

支持的配置
该解决方案适用于以下配置（列表可能不完整，请参阅文档以获取完全支持的列
表）：
核心用例：
•
•
•

基于策略的备份和复制DR 运行手册自动化DRaaS（通过 Xi）

管理界面：
•

Prism Central（PC）

支持的环境：•

本地：
AHV（自 AOS 5.10 开始）• 云：o Xi（自 AOS 5.10 起）
o

升级：
•

AOS 的一部分

兼容功能：•

AOS BC / DR 功能

关键内容
309

在本节中将使用以下关键术语，术语定义如下：•恢复点目标（RPO）
o 指发生故障时可接受的数据丢失。 例如，如果您希望 RPO 为 1 小时，则每 1 小
时创建一次快照。 如果进行还原，则您最多可以还原 1 个小时前的数据。 对于同步复制，通常 RPO 为 0。
•恢复时间目标（RTO）
o 恢复时间目标。 指从故障事件到恢复服务的时间段。 例如，如果发生故障，并
且您需要在 30 分钟内备份和运行应用，则 RTO 为 30 分钟。
•恢复点o 恢复点又称为快照。

实现构造
在 Nutanix Leap 中，有一些关键的结构：:保护政策关键角色：分配类别的备份/复制策略•说明：保护策略定义了 RPO（快照频率），恢复位置（远程群集/ Xi），快照保留（本地与远程群集）以及相关的类别。 使用保护策略，所有内容都将应用到类别级别（默认值可以应用于任何/全部）。 这与必须选择 VM 的保护域不同。
下图显示了 Nutanix 跳跃保护策略的结构：310

图. Leap -保护策略恢复计划•关键角色：灾难恢复手册•说明：恢复计划是一本运行手册，它定义了开机顺序（可以指定类别或 VM）和网络
映射（主要与恢复以及测试故障转移/故障回复）。 这是人们对 SRM 的最多的同义词定义。 注意：必须先配置保护策略，然后才能配置恢复计划。 这是必需的，因为
数据必须存在于恢复站点才能被恢复。
下图显示了 Nutanix Leap Recovery Plan 的结构：311

图. Leap – 恢复计划线性保留政策•关键角色：恢复点保留策略•描述：线性保留策略指定要保留的恢复点的数量。例如，如果 RPO 为 1 小时，而您
的保留时间设置为 10，则您将保留 10 小时（10 x 1 小时）的恢复点（快照）。

汇总保留政策•关键角色：恢复点保留策略•描述：汇总保留策略将根据 RPO 和保留持续时间“汇总”快照。例如，如果 RPO 为 1
小时，而您的保留时间设置为 5 天，则它将保持每小时 1 天和每天 4 天的恢复点。该
逻辑的特征如下：如果保留时间为 n 天，则保留 1 天的 RPO 和 n-1 天的每日恢复点。如果保留时间为 n 周，则保留 1 天的 RPO，每天保留 1 周，每周恢复点保留 n-1
周。如果保留时间为 n 个月，则保留 RPO 1 天，每天 1 周，每周 1 个月和每月 n-1
个月的恢复点。如果保留时间为 n 年，则保留 1 天的 RPO，每天保留 1 周，每周保
留 1 个月，每月恢复点保留 n-1 个月。

线性与汇总保留312对于保留期较短的小型 RPO 窗口，或者在始终需要恢复到特定 RPO 窗口的情况下，请使用线性策略。
将汇总策略用于保留期较长的任何内容。 它们更加灵活，可以自动处理快照的时效/精简，同时第一天仍提供精细的 RPO。
下面显示了 Leap 构造的高级概述：图. Leap – 概览
下面显示了 Leap 如何在内部和 Xi 之间复制：313

图. Leap – 拓扑

用法和配置以下各节介绍如何配置和使用 Leap。
总体过程可以分为以下步骤：1.连接到可用区（AZ）
2.配置保护策略
3.配置恢复计划
4.执行/测试故障转移和故障回复

连接可用区第一步是连接到 Xi AZ 或另一台 PC 的 AZ。 注意：从 5.11 开始，您至少需要部
署 2 台 PC（每个站点 1 台）。
在 PC 中，搜索“可用区域”或导航到“管理”->“可用区域”：

314

图. Leap – 连接可用区
单击“连接到可用区”，然后选择 AZ 类型（“ Xi”或“ Physical Location”，又名 PC实例）：图. Leap – 连接可用区
输入 PC 或 Xi 的密码，然后单击“连接”：

315

图. Leap – 连接可用区
现在将会显示已连接的可用区并可用。

配置保护策略在 PC 中，搜索“保护策略”或导航到“策略”->“保护策略”：

图. Leap – 保护策略316

点击“创建保护政策”：:

图. Leap – 创建保护策略输入名称，恢复位置，RPO 和保留策略的详细信息（如前所述）：317

图. Leap – 保护策略输入
注意：对于 Xi，您不需要选择“目标集群”
318

319

图. Leap – 保护策略输入 – Xi
接下来，我们将选择适用于该政策的类别：

图. Leap – 保护策略类别
单击“保存”，您将看到新创建的保护策略：图. Leap – 保护策略

配置恢复计划
在 PC 中，搜索“恢复计划”或导航到“策略”->“恢复计划”：320图. Leap – 恢复计划在首次启动时，将看到用于创建第一个恢复计划的屏幕：

图. Leap – 创建恢复计划
使用下拉菜单选择“恢复位置”：

321图. Leap – 选择恢复位置
注意：可以是任一 Xi 可用区或物理可用区（具有相应托管群集的 PC）。
输入恢复计划名称和描述，然后单击“下一步”：

322图. Leap – 恢复计划 – 命名
接下来点击“添加实体”并指定开机顺序：323

图 Leap – 恢复计划 – 启动顺序搜索要添加到每个阶段的 VM 或类别：324图 Leap – 恢复计划 – 启动顺序
一旦各阶段的开机顺序看起来不错，请单击“下一步”：

325图 Leap – 恢复计划 – 启动顺序

启动顺序
326

确定开机顺序时，您将需要分阶段进行以下操作：
阶段 0：核心服务（AD，DNS 等）
阶段 1：取决于阶段 0 服务的服务，是阶段 2 服务所必需的（例如数据库层）阶段 2：服务取决于阶段 1 服务，是阶段 3 服务所必需的（例如应用层）阶段 3：服务取决于阶段 2 服务，并且是阶段 4 服务所必需的（例如 Web 层）阶段 4-N：根据依赖性重复

•
•
•
•
•

现在，我们将在源环境和目标环境之间映射网络：图. Leap – 恢复计划 – 网路映射故障转移/故障回复网络
在大多数情况下，您将需要对测试网络使用不可路由或隔离的网络。 这将确保您没有重复 SID，arp 条目等
问题。

11.2 Mine（备份解决方案）待续

12 第十二部分：编排服务
12.1 Calm（编排/自动化）待续327

13 第十三部分：治理服务13.1 Beam（成本治理/合规性）待续

14 第十四部分：场景
14.1 场景：安全分析平台待续

14.2 场景：多站点灾难恢复/复制
待续

15 第十五部分：集成15.1 集成15.1.1OpenStack

OpenStack 是一个用于管理和构建云的开源平台。它主要被分为前端(仪表盘和 API)和基础架构服务(计算，存储资源等)。
OpenStack 和 Nutanix 解决方案有以下主要组件构成：•

OpenStack 控制器(OSC)o

一个现存的或新创建的虚拟机或主机，用来提供 OpenStack 用户界面、API
和服务。处理所有 OpenStack 的 API 调用。它可以跟 Acropolis OpenStack驱动共存在同一个 Acropolis OVM 中。

•

Acropolis OpenStack 驱动

328

o

负责处理来自 OpenStack 控制器的 OpenStack RPC，并将其转换为本地
Acropolis API 调用。它可以部署在 OpenStack 控制器，预装的 OVM 或是一个新的虚拟机上。

•

Acropolis OpenStack 服务虚拟机 (OVM)o

具有 Acropolis 驱动的虚拟机，负责处理来自 OpenStack 控制器的OpenStack RPC，并将其转换为本地 Acropolis API 调用。

OpenStack 控制器可以是一个已经存在的虚拟机/主机，或者作为 OpenStack 的一部
分部署在 Nutanix 解决方案上。Acropolis OVM 是一个助手 VM，它作为 Nutanix
OpenStack 解决方案的一部分部署。
客户端用他们期望的方式（Web UI / HTTP, SDK, CLI or API）来与 OpenStack 控制
器进行通信。而 OpenStack 控制器则与 Acropolis OVM 通信，后者利用 OpenStack驱动把指令转换成 Acropolis 自身的 REST API 调用。
下图描述这种通讯的概要过程：图. OpenStack + Acropolis OpenStack 驱动这样既可以使两者完美结合，也可以实现 OpenStack Portal 和 API 的优点，而无需复杂的 OpenStack 基础架构和相关管理。 所有后端基础架构服务（计算，存储，网络）均利用本地 Nutanix 服务。 无需部署 Nova Compute 主机等。该平台公开了这些服务的 API、控制器与这些服务进行通信，然后将它们转换为本地 Acropolis API
调用。 此外，考虑到简化的部署模型，完整的 OpenStack + Nutanix 解决方案可以在不到 30 分钟的时间内部署完成。
支持的 OpenStack 控制器
当前版本 (对应于 4.5.1) 需要一个 Kilo 或更新版本的 OpenStack 控制器。
329

下表列出了各组件角色映射的概要信息：
条目

角色

OpenStack
控制器

TenantDashboard

User interface
and APIX

Admin
Dashboard

Infra monitoringand opsX

Orchestration

Object CRUD
and lifecycle
management

X

QuotasResource
controls andlimitsX

Users, Groups
and Roles

Role based
access control(RBAC)X

SSO

Single-sign on

X

Platform
Integration

OpenStack to
Nutanix
integration

Infrastructure
Services

Targetinfrastructure(compute,
storage,
network)

Acropolis
OVM

Acropolis
集群

Prism

X

X

X

OpenStack 组件
OpenStack 由一系列提供基础架构功能服务的组件构成。其中一些功能由
OpenStack 控制器提供，有些则由 Acropolis OVM 提供。
下表列出了核心的 OpenStack 组件及其角色的映射：
组件角色OpenStack 控制

330

Acropolis OVMKeystone

Identity service

X

HorizonDashboard and UI

X

Nova

ComputeSwift

Object storage

CinderBlock storage

GlanceImage service

NeutronNetworking

Heat

Orchestration

X

OthersAll other components

X

X
X

X
X

X

X
X

下面提供了一个 OpenStack 组件及其通讯过程更为详细的视图：

图. OpenStack + Nutanix API 通讯
在下面的章节中，我们将讨论一些主要的 OpenStack 组件，以及它们如何集成到
Nutanix 平台中。
Nova

331

Nova 是 OpenStack 平台的计算资源引擎和调度器。在 Nutanix OpenStack 解决方案中，每个 Acropolis OVM 作为一个计算主机，每个 Acropolis 集群都将作为一个单一的 hypervisor 主机，用于调度 OpenStack 实例。Acropolis OVM 运行 Nova 计算资源服务。
你可以通过 OpenStack 门户从下面路径中查看 Nova 服务：'Admin'->'System'->'System Information'->'Compute Services'.
下图展示了 Nova 服务，主机及其状态：图. OpenStack Nova 服务
Nova 调度器基于选定的可用区，决定在哪个计算主机（如 Acroplis OVM）上存放实
例。这些请求将会被发送到选定的 Acropolis OVM 上，然后由 Acropolis OVM 转发请求到目标主机的 Acropolis 调度器。Acropolis 调度器将在集群中选出最优的节点存
放方式。集群中各节点不会直接暴露给 OpenStack。
你可以通过 OpenStack 门户，在路径'Admin'->'System'->'Hypervisors'中查看计算机
和 hypervisor 主机。
下图以计算机主机的形式列出了 Acropolis OVM：

图. OpenStack Compute 主机
下图以 hypervisor 主机的形式列出了 Acropolis 集群：332

图. OpenStack Hypervisor 主机
如你从上面的图示所见，所有集群的资源以单个 hypervisor 主机的方式展现。
Swift在对象存储中 Swift 被用于存储和检索文件。目前它仅用于快照和图像的备份/恢复。
CinderCinder 是 OpenStack 的卷组件，对外提供 iSCSI 对象。在 Nutanix 解决方案中Cinder 的实现借助于 Acropolis 卷管理 API。这些卷将以块设备的形式直接附加到实
例上去（相较于 in-guest）。
你可以通过 OpenStack 门户，在路径'Admin'->'System'->'System
Information'->'Block Storage Services'下查看 Cinder 服务。
下图显示了 Cinder 服务，主机和状态：图. OpenStack Cinder 服务Glance / Image Repo
Glance 是 OpenStack 中的镜像库，展现部署实例的可用镜像。镜像包括 ISO，磁盘
和快照。
Image Repo 是用来保存由 Glance 发布的可用镜像的存储库。这些镜像可以位于Nutanix 环境中或由外部来源。当镜像被保存在 Nutanix 平台上时，他们通过 OVM
以 Glance 的形式发布到 OpenStack 控制器。当 Image Repo 只存在于外部源时，Glance 将被 OpenStack 控制器接管，并且 Image Cache 将在 Acropolis Cluster 上使用。
Glance 在每个群集的基础上启用，，并且总是和 Image Repo 共存。在多个集群中同时启动 Glance 时，Image Repo 会横跨这些集群，并且通过 OpenStack 们创建的镜像将会被推送到所有运行 Glance 的集群。没有运行 Glance 的集群将利用 Image
Cache 在本地缓存镜像。
333

专家提示
对于大规模部署，每个站点至少保证有两个 Acropolis 集群在运行 Glance。这样
就能对 Image Repo 实现高可用，以便在一个集群不可用时，镜像始终可用，即便它不在 Image Cache 中。
当以外部源运行 Image Repo/Glance 时，Nova 会负责把数据从外部源转移到目标端
的 Acropolis 集群。在这种情况下，目标端的 Acropolis 集群会利用 Image Cache 来缓存镜像，以便后续访问时能从本地读取。
Neutron
Neutron 是 OpenStack 中的网络组件，负责网络配置。Acropolis OVM 允许用户通过
OpenStack 门户进行网络 CRUD 的操作，然后在 Acropolis 中进行必要的修改。
你可以通过 OpenStack 门户，从'Admin'->'System'->'System Information'->'Network
Agents'查看 Neutron 服务。
下图展示了 Neutron 服务，主机和状态：+ 目前只支持 Local 和 VLAN 网络类型
图. OpenStack Neutron 服务
Neutron 在实例启动时分配 IP 地址。Acropolis 也正是以这种方式得到相应虚拟机的IP 地址。当虚拟机发出 DHCP 请求时，Acropolis Master 将像对待 Acropolis
Hypervisor 一样在专用 VXLAN 上对此请求做出响应。
被支持的网络类型
当前只支持 Local 和 VLAN 网络类型
Keystone 和 Horizon 组件运行在与 Acropolis OVM 接口的 OpenStack Controller
中。OVM 中的 OpenStack 驱动将把 OpenStack API 调用转换成本地的 Acropolis
API 调用。
设计和部署334

对于大规模的云部署，一个好的交付拓扑是至关重要的。它将被分发并满足最终用户
的需求，同时提供灵活性和本地性。
下面是在 OpenStack 中用到的高层级的概念：•区域-Regiono一个地理意义上区域，其上可构建多个可用区（AZ）。区域可以设置成像
US-Northwest 或是 US-West 这样。

•

可用区-Availability Zone (AZ)o一个运行着云服务的特定站点或数据中心的位置。它可以包含像是 USNorthwest-1 or US-West-1 这样的站点。

•

主机聚合-Host Aggregateo•计算主机-Compute Hosto•一组计算主机，可以是一排、一整片或是如站点或 AZ 那样的范围。

一个运行着 nova 计算服务的 Acropolis OVM。

虚拟管理程序主机-Hypervisor Hosto一个 Acropolis 集群（以一个单一主机的形式可见）。

下图展示了以上各概念的高层级关系：

图. OpenStack - 部署结构335

下图展示了各概念应用的例子：图. OpenStack - Deployment Layout - 实例你可以通过 OpenStack 门户，从'Admin'->'System'->'Host Aggregates'查看和管理主机，主机聚合和可用区。
下图展示了主机聚合，可用区和主机：

图. OpenStack 主机聚合和可用区
服务设计和扩展

336

对于大规模部署来说，推荐以负载均衡的方式把多个 Acropolis OVM 连接到
OpenStack 控制器。这样既保证了可用性又均衡了工作负载。OVM 本身不包含任何处于延展性要求的状态信息。
下图展示了如何在一个单一站点扩展 OVM：

图. OpenStack - OVM 负载均衡
实现 OVM 的一种方法是使用 Keepalived 和 HAproxy。
对于跨越多个站点的环境，OpenStack 控制器将与跨站点的多个 Acropolis OVM 进行通信。
下图展示了一个跨站点部署的例子：337

图. OpenStack - 多站点
部署OVM 可以以独立的 RPM 包形式部署在 CentOS/Redhat 发行版本当中，或是作为一个虚拟机直接运行。Acropolis OVM 可以部署在任何 Nutanix 或非 Nutanix 的平台
上，只要其能连接到 OpenStack 控制器和 Nutanix 集群。
Acropolis OVM 的虚拟机可以通过以下方式部署到 Nutanix AHV 集群上。如果 OVM
已经部署，您可以跳过 VM 创建步骤。你可以用完整的 OVM 镜像或使用现有的
CentOS / Redhat VM 镜像。
首先我们将把 Acropolis OVM 的磁盘镜像导入到 Acropolis 集群。可以用 SCP 来传输镜像或是指定一个 URL 来导入。我们将用镜像服务的 API 来导入。注意：OVM 的虚拟机可以部署到任何地方，不一定是 Acropolis 集群。
运行以下命令，通过镜像 API 导入磁盘镜像：
image.create <IMAGE_NAME> source_url=<SOURCE_URL> container=<CONTAINER_NAME>

从任何 CVM 运行下列 ACLI 命令来创建 OVM 虚拟机：vm.create <VM_NAME> num_vcpus=2 memory=16G
vm.disk_create <VM_NAME> clone_from_image=<IMAGE_NAME>
vm.nic_create <VM_NAME> network=<NETWORK_NAME>
vm.on <VM_NAME>

虚拟机创建完毕并开启后，用给定的用户名和口令 SSH 到 OVM。

338

OVMCTL Help
在 OVM 上运行以下命令来获得帮助文本:
ovmctl --help

OVM 支持两种部署方式：
OVM-allinone•o

OVM 包含所有 Acropolis 驱动和 OpenStack 控制器
OVM-services•o

OVM 包含所有 Acropolis 驱动并且和外部/远端的 OpenStack 控制器通讯这两种部署模式都将在以下部分中进行讨论。你可以在任何模式下使用，也可以
在模式之间切换。
OVM-allinone
下列步骤涵盖了 OVM-allinone 的部署，从 SSH 到 OVM 开始：# Register OpenStack Driver service
ovmctl --add ovm --name <OVM_NAME> --ip <OVM_IP># Register OpenStack Controller
ovmctl --add controller --name <OVM_NAME> --ip <OVM_IP># Register Acropolis Cluster(s) (run for each cluster to add)ovmctl --add cluster --name <CLUSTER_NAME> --ip <CLUSTER_IP> --username <PRISM_USER> -password <PRISM_PASSWORD>

The following values are used as defaults:
Number of VCPUs per core = 4
Container name = default
Image cache = disabled, Image cache URL = None

我们可以用下面命令来确认配置：339

ovmctl --show

到此为止，所有的服务都应该起来并且正常运行。
OVM-services
下列步骤介绍了 OVM-services 的部署方式，从 SSH 到 OVM 开始：# Register OpenStack Driver service
ovmctl --add ovm --name <OVM_NAME> --ip <OVM_IP># Register OpenStack Controller
ovmctl --add controller --name <OS_CONTROLLER_NAME> --ip <OS_CONTROLLER_IP> --username<OS_CONTROLLER_USERNAME> --password <OS_CONTROLLER_PASSWORD>

The following values are used as defaults:
Authentication: auth_strategy = keystone, auth_region = RegionOne
auth_tenant = services, auth_password = admin
Database: db_{nova,cinder,glance,neutron} = mysql, db_{nova,cinder,glance,neutron}_password = admin
RPC: rpc_backend = rabbit, rpc_username = guest, rpc_password = guest# Register Acropolis Cluster(s) (run for each cluster to add)ovmctl --add cluster --name <CLUSTER_NAME> --ip <CLUSTER_IP> --username <PRISM_USER> -password <PRISM_PASSWORD>

The following values are used as defaults:
Number of VCPUs per core = 4
Container name = default
Image cache = disabled, Image cache URL = None

如果 OpenStack 控制器用的是非缺省的口令，我们需要更新以下信息：# Update controller passwords (if non-default are used)
ovmctl --update controller --name <OS_CONTROLLER_NAME> --auth_nova_password <> -auth_glance_password <> --auth_neutron_password <> --auth_cinder_password <> --db_nova_password <> -db_glance_password <> --db_neutron_password <> --db_cinder_password <>340

接下来我们用下面命令来确认配置：
ovmctl --show

既然 OVM 已经被设置完毕，我们就要配置 OpenStack 控制器使其能够获知 Glance
和 Neutron 的 endpoint 信息。
登录 OpenStack 控制器并进入 keystonerc_admin 源环境：
# enter keystonerc_admin source ./keystonerc_admin

首先我们要删除原来指向控制器的 Glance endpoint：# Find old Glance endpoint id (port 9292) keystone endpoint-list # Remove old keystone endpoint for
Glancekeystone endpoint-delete <GLANCE_ENDPOINT_ID>

下一步我们将创建新的指向 OVM 的 Glance endpoint：# Find Glance service id
keystone service-list | grep glance# Will look similar to the following:| 9e539e8dee264dd9a086677427434982 | glance | image |# Add Keystone endpoint for Glance
keystone endpoint-create \--service-id <GLANCE_SERVICE_ID> \--publicurl http://<OVM_IP>:9292 \--internalurl http://<OVM_IP>:9292 \--region <REGION_NAME> \--adminurl http://<OVM_IP>:9292

接下来删除原有指向控制器的 Neutron endpoint：# Find old Neutron endpoint id (port 9696) keystone endpoint-list # Remove old keystone endpoint for
Neutronkeystone endpoint-delete <NEUTRON_ENDPOINT_ID>341

下一步创建新的指向 OVM 的 Neutron endpoint：# Find Glance service id
keystone service-list | grep glance# Will look similar to the following:| f4c4266142c742a78b330f8bafe5e49e | neutron | network |# Add Keystone endpoint for Neutron
keystone endpoint-create \--service-id <NEUTRON_SERVICE_ID> \--publicurl http://<OVM_IP>:9696 \--internalurl http://<OVM_IP>:9696 \--region <REGION_NAME> \--adminurl http://<OVM_IP>:9696

Endpoint 创建完毕后，我们将用新的 Glance 主机的 Acropolis OVM 的 IP 来更新
Nova 和 Cinder 的配置。
依照下列内容编辑/etc/nova/nova.conf[glance]...
# Default glance hostname or IP address (string value)
host=<OVM_IP># Default glance port (integer value)
port=9292...
# A list of the glance api servers available to nova. Prefix# with https:// for ssl-based glance api servers.
# ([hostname|ip]:port) (list value)
api_servers=<OVM_IP>:9292
现在停掉 OpenStack 控制器上的 Nova 计算服务：342

systemctl disable openstack-nova-compute.service
systemctl stop openstack-nova-compute.service
service openstack-nova-compute stop

依照下列内容编辑/etc/cinder/cinder.conf# Default glance host name or IP (string value)
glance_host=<OVM_IP># Default glance port (integer value)
glance_port=9292# A list of the glance API servers available to cinder# ([hostname|ip]:port) (list value)
glance_api_servers=$glance_host:$glance_port

注释掉 lvm 作为 cinder 后台的选项，因为它根本不会被用到：# Comment out the following lines in cinder.conf#enabled_backends=lvm#[lvm]#iscsi_helper=lioadm#volume_group=cinder-volumes#iscsi_ip_address=#volume_driver=cinder.volume.drivers.lvm.LVMVolumeDriver#volumes_dir=/var/lib/cinder/volumes#iscsi_protocol=iscsi#volume_backend_name=lvm

现在停掉 OpenStack 控制器上的 cinder 服务：systemctl disable openstack-cinder-volume.service
systemctl stop openstack-cinder-volume.service
service openstack-cinder-volume stop也停掉 OpenStack 上的 Glance 镜像服务：343

systemctl disable openstack-glance-api.service
systemctl disable openstack-glance-registry.service
systemctl stop openstack-glance-api.service
systemctl stop openstack-glance-registry.service
service openstack-glance-api stop
service openstack-glance-registry stop

当所有配置文件都被更新后，我们将重启 Nova 和 Cinder 服务使更改生效。用下列
命令来重启服务，当然也可以用脚本来完成（可供下载）。
# Restart Nova services
service openstack-nova-api restart
service openstack-nova-consoleauth restart
service openstack-nova-scheduler restart
service openstack-nova-conductor restart
service openstack-nova-cert restart
service openstack-nova-novncproxy restart# OR you can also use the script which can be downloaded as part of the helper tools:~/openstack/commands/nova-restart# Restart Cinder
service openstack-cinder-api restart
service openstack-cinder-scheduler restart
service openstack-cinder-backup restart# OR you can also use the script which can be downloaded as part of the helper tools:~/openstack/commands/cinder-restart

PuppetPuppet 是一个生命周期配置管理（LCM）工具，支持 devops，安全性和合规性，程序控制以及基础架构和应用程序堆栈。
排错与高级管理344

关键日志目录组件关键日志目录

Keystone/var/log/keystone/keystone.log

Horizon/var/log/horizon/horizon.log

Nova/var/log/nova/nova-api.log/var/log/nova/nova-scheduler.log/var/log/nova/nove-compute.log*

Swift/var/log/swift/swift.log

Cinder/var/log/cinder/api.log/var/log/cinder/scheduler.log/var/log/cinder/volume.log

Glance/var/log/glance/api.log/var/log/glance/registry.log

Neutron/var/log/neutron/server.log/var/log/neutron/dhcp-agent.log*/var/log/neutron/l3-agent.log*/var/log/neutron/metadata-agent.log*/var/log/neutron/openvswitch-agent.log*

标星号的日志只存在于 Acropolis OVM 中。
专家提示
如果在 OpenStack Manager (Admin UI 或 CLI)中，服务被视为状态“down”，即使
服务在 OVM 中运行，也要检查 NTP。许多服务都要求在 OpenStack 控制器和Acropolis OVM 之间保持同步。

命令参考
装载 Keystone 源（先于其他命令执行）source keystonerc_admin

列出 Keystone 服务
keystone service-list345

列出 Keystone endpoints
keystone endpoint-list

创建 Keystone endpoint
keystone endpoint-create \--service-id=<SERVICE_ID> \--publicurl=http://<IP:PORT> \--internalurl=http://<IP:PORT> \--region=<REGION_NAME> \--adminurl=http://<IP:PORT>

列出 Nova 实例nova list

显示实例细节
nova show <INSTANCE_NAME>

列出 Nova hypervisor 主机
nova hypervisor-list

显示 Nova hypervisor 主机细节nova hypervisor-show <HOST_ID>

列出 Glance 镜像glance image-list

显示 Glance 镜像细节glance image-show <IMAGE_ID>

16 后记
346

感谢您阅读的 Nutanix 圣经！敬请期待更多的即将到来的更新并享受 Nutanix 平台！

347