企业官网建设流程全解析

简介：Nutanix超融合平操作系统的中文使用手册，面向IT管理员、系统管理员及技术支持人员，旨在帮助读者快速掌握超融合平台的日常运维与功能操作。手册以计算、存储、网络与虚拟化融合架构为背景，系统讲解登录入口、主页仪表盘监控、AOS/NCC/AHV软件升级、固件升级、存储池与存储容器创建、网络管理等核心模块，并配有系统结构图和浏览器兼容性说明；各功能均按操作过程展开，既适合零基础读者按章节逐步学习，也可作为企业部署与故障排查时的速查手册。资源包含1个PDF文档，压缩包大小约7.42MB，目录从引言到功能说明层级分明，便于按需检索。目前已有1866人学习浏览，中文内容显著降低了Nutanix超融合平台的上手门槛，对数据中心运维人员具有较高的实用参考价值。

1. Nutanix超融合平台操作手册：中文环境里最缺的不是功能，是操作路径

Nutanix超融合平台的中文操作手册，表面上是一份界面指南，实际上是一套“计算+存储+虚拟化”三合一体系的使用逻辑。很多团队拿到一台预装好的Nutanix集群，打开Prism控制台第一眼是蒙的：没有vCenter那种层级分明的清单，取而代之的是集群健康分值、容量条、事件流和一堆英文缩写。这份内容的价值在于把“能用”变成“会用”——从虚机生命周期管理、存储容器规划、数据保护策略到故障排查，全部落地到具体操作步骤和参数选择。适合正在或准备把业务跑在Nutanix上的运维、实施和架构师，尤其是从VMware或深信服超融合平台迁移过来的团队，转换思路比记命令更重要。

2. 从Prism界面入手：虚拟机全生命周期操作与关键参数选择

2.1 创建虚拟机时不踩默认值：CPU、内存、存储和网络的四个设置点

Prism界面创建虚机的入口在“VM”页面点“Create VM”，大多数新手会直接填名称和镜像就下一步。但Nutanix的虚拟化底层是内置的AHV，默认参数不等于合理参数，至少四个地方需要手动确认。

第一个是CPU配置。AHV的vCPU分配有两种方式，默认是“1 vCPU = 1 core”，但物理CPU超线程开启后，你可以给虚机分配“2 vCPU = 1 core”的模式，也就是共享一个物理核的两个线程。对于CPU密集型应用，超线程没太大帮助；对普通Web服务器，开超线程能把密度提上去。Prism里对应选项叫“vCPU Allocation”，一般选“1:1”最省心，超卖场景再考虑“2:1”。这里我一般会先看物理主机的CPU型号，再决定超卖比，不会一上来就拉满。

第二个是内存。Nutanix的虚拟化层默认启用内存压缩，但只对同一页内的重复数据有效。创建虚机时“Memory”填的是分配给虚机的总量，额外的“Memory Reservation”默认是0，也就是允许超卖。如果虚机里跑的是Oracle或数据库类常驻内存应用，建议把Reservation设为100%，否则遇到内存压力时AHV会主动回收内存页，虚机性能波动会很玄学。

第三个是存储。选择虚拟磁盘时，“Storage Container”下拉框决定了数据落在哪个存储池，而“Flash Mode”才是真正影响性能的选项。默认的“Auto”会在集群检测到热数据时自动做分层，但手动指定“All Flash”能让关键业务盘的延迟稳定在0.5ms以内。额外说一句，AHV的磁盘是精简置备，创建时不管填多大容量，实际只占用了写入部分，别被虚机显示的大小吓到以为存储不够了。

第四个是网络。Prism里网络配置走的是“Subnet”概念，对应物理交换机上的VLAN。创建虚机前先确认好“Subnet”下拉里选的是哪个VLAN，很多踩坑现场就是虚机起不来绑了网卡，查了半天发现是Subnet选成了管理网络，业务VLAN根本没通。下面是创建命令走nCLI时的最小示例。

# 用nCLI在指定容器里创建虚拟磁盘 ncli disk create \ container-name="DefaultContainer" \ vm-name="web-prod-01" \ size=100G \ flash-mode=all_flash

这段命令说明：container-name指定存储落点，flash-mode=all_flash强制全闪性能；实际创建时还可以加thin-provisioned=true参数，默认就是精简，不需要额外指定。虚拟磁盘创建完后再用VM向导挂给虚机即可。如果走Prism界面，同样的设置对应“Flash Mode”下拉框和“Container”选择器，逻辑一致。

2.2 日常维护三件套：快照、克隆、迁移与批量关机

虚机跑起来之后，日常操作集中在快照、克隆和迁移。Nutanix的快照不是传统意义上的“复制当前状态”，而是基于CASP（分布式存储）做的写时复制，创建瞬间不占存储，只有数据变化了才增长。但注意，快照不是备份，它依赖原始虚机的虚拟磁盘存在，原始盘被删除，快照也就废了。我的习惯是：做变更前打一个快照，变更验证完保留48小时，确认就删掉。别让快照变长期备份，否则快照层越来越厚，读写性能会下降。

克隆操作适合做环境复制，比如把生产系统的虚机克隆一套到测试网段。Prism里“Clone VM”会比“Full Clone”快得多，原因是它共享底层数据块，只在写入时复制。克隆完以后一定要改主机名和IP，否则测试机和生产机在同一个DNS区域里会翻车。迁移包含两种：虚机跨主机迁移，和存储容器跨层迁移。前者在AHV里默认支持热迁移，界面操作是“Migrate VM”，后者需要先在“Storage”页面确认目标容器有足够容量，再在虚机磁盘设置里替换容器。

批量关机是重活，几十台虚机一台台点太慢，我们可以用nCLI脚本批量处理。

# 列出所有运行中的虚机，过滤出名字含"dev-"的并全部关机 ncli vm list | grep "dev-" | awk '{print $2}' | \ while read vm_id; do ncli vm off vm-id="$vm_id" done

逻辑说明：ncli vm list返回的是文本表格，第一列为虚机名，第二列为ID；用grep根据命名规则筛出目标环境，循环里逐台关机。如果你不想用管道处理文本，更稳妥的办法是在Prism里选中多台虚机，右键“Shut down”，记住那是ACPI关机，不是断电。虚机系统里如果启用了Nutanix Guest Tools，关机前会自动做文件系统刷新和内存回收，干净很多。对于Windows虚机，建议都装上Guest Tools，否则快照恢复时文件系统一致性没有保障。

3. 存储容器与数据保护：容量规划、存储策略和备份恢复的落地方法

3.1 存储容器的三层设计：把生产、测试和备份的数据落点分开

Nutanix的存储不是传统RAID组，而是以“Container”为单位做策略管理。容器本质上是一个逻辑逻辑空间，底层所有节点的磁盘组成分布式存储池，容器只是在这个池上划分出的策略边界。创建容器时，核心要设定三个参数：存储策略、数据保护属性和容量上限。

存储策略决定了性能取向。“Standard”走HDD容量层，适合归档；“Performance”会尽量把数据放在闪存层；“Compression”在闪存层做去重压缩，适合日志和虚拟桌面。注意“Compression”不是免费的，它对CPU有额外开销，当集群节点CPU持续超过80%时，压缩带来的性能损失可能比省下的容量更不划算。数据保护属性里，“Replication Factor”（RF）是Nutanix超融合的核心概念，RF2表示数据在集群里存两份，RF3存三份。RF2容错一个节点故障，RF3容错两个，但每份数据占用的容量也要翻倍。

容量上限是个容易忽略但必设的参数。“Container Usage Limit”不设置默认就是整个存储池大小，一旦业务疯狂写数据，会把集群所有可用容量耗尽，导致所有虚机IO阻塞。我的经验是：生产容器设集群总容量的60%，测试容器设20%，备份容器设20%，各留一点余量。下面是创建生产容器的最小命令。

# 创建生产容器，RF3策略，容量上限50% ncli container create \ name="prod-container" \ rf=3 \ limit-capacity=true \ max-capacity=50

这段命令逻辑：rf=3做双节点容错，适合数据库场景；limit-capacity=true配合max-capacity=50把容器限制到集群总容量的50%。如果是普通Web层，建议RF2，节省下来的空间放更多快照。创建后可以随时用ncli container edit调整，但从RF2升RF3会触发数据同步，集群压力会短时间变大，尽量在维护窗口操作。

3.2 数据保护策略：从本地方天到异地复制的时间表设计

数据保护是Nutanix超融合里的重头戏。Prism的“Data Protection”页面可以给每台虚机单独设置保护策略，也可以按容器统一配置。保护机制的底层是快照链，策略里定义三个参数：RPO（快照间隔）、Retention（保存周期）和Replication Target（副本目标）。

RPO可选值一般是1小时、4小时、1天，业务中断容忍度决定选哪个。数据库系统我一般选1小时快照，保留24小时；普通文件服务器4小时快照，保留7天。加了异地复制后，本地快照会异步同步到远端集群，RPO取决于WAN带宽和写入量，2Mbps链路上做跨机房复制，RPO基本能到15分钟左右，但这需要远端已经建好一个Nutanix集群并且做了Cluster Pair配对。

恢复操作是另一个高频动作。Prism里选择快照点后，“Restore”可以直接把虚机恢复到那个时间点；“Clone”则是在当前时间点旁生成一个新虚机。恢复时注意，如果原虚机还开着，系统会先关机再恢复，这期间有无法访问的空窗期。如果是误删文件的场景，更轻量的做法是“Mount VM Disk”，把快照里的虚拟磁盘挂载到一台临时虚机上，用操作系统命令取出文件。下面这段nCLI适合做定时保护的检查。

# 查看指定虚机的保护策略状态 ncli vm describe vm-name="web-prod-01" | grep -i "protection\|policy\|snapshot"

这条命令会把虚机描述信息里的策略字段全打出来，包含保护策略名、关联的快照域和最近一次快照时间。定时巡检时只要看“Last Snapshot”时间戳是否接近RPO，就能判断保护系统是否正常工作。如果快照时间远早于设定值，先查集群主机时间同步和存储节点剩余容量，快照失败最常见的原因不是策略错了，而是容量达到容器上限。

3.3 三种存储策略的选型参考

选型时别只看“性能”这个名词，观察一个写密集应用的CPU和存储延迟，如果存储延迟低但应用慢，问题往往在虚机CPU调度和内存压缩上。压缩策略要谨慎用于vCPU已经超卖的集群，因为压缩线程会和应用抢占CPU。

4. Nutanix实操避坑：五个最容易翻车的配置与排查记录

4.1 现象：创建虚机时选了Performance存储，集群可用容量反而下降更快

创建虚机时选择了Performance策略，跑了一周后看容量条，发现集群剩余容量比预期少了不止一倍。在Standard策略下数据写进HDD，写入前不需要额外空间；Performance策略会把数据先放闪存层，一旦闪存空间不足要换出到HDD时，系统会先保留两份数据再迁移，这个过程中闪存层可用空间会急剧下降，看起来就像容量被吃掉了。

找容量大头不用一台台虚机点开，直接看“Storage”页面的容器统计，或执行ncli container stats查看每个容器的逻辑用量和物理用量，两个数值差异大说明压缩或分层在正常工作，不必慌。解决方式不是禁用Performance，而是合理设计分层策略，把频繁读写的热数据放在Performance容器，把冷数据通过“Change Container”定期迁移到Standard容器，容量曲线就平滑了。

4.2 现象：新加节点后数据不均匀，部分节点IO异常高，集群健康分被扣

集群扩容后，新节点加进来了，但原有节点IO压力并没有缓解，反而某个老节点延迟飙升，Prism健康分掉了20分。扩容后数据再均衡是默认开启的，但Nutanix的再均衡策略偏保守，优先保证业务IO不被迁移流量干扰，所以新节点要过很久才会被分到数据，期间老节点要承担所有数据写入。

解决方式分两步。第一，先在“Cluster”页面查看“Data Rebalancing”状态，确认迁移任务确实在进行，如果显示No Active Task，说明没有再均衡动作触发。第二，手动加速，对I/O压力大的容器执行ncli container rebalance name=prod-container，命令执行后系统会主动迁移该容器内的数据块到新节点。注意尽量在业务低峰期跑这个命令，迁移流量会占到节点带宽的30%左右，跑太急会翻车。

4.3 现象：快照恢复后虚机文件系统损坏，数据库起不来

做快照保护后遇到一次恢复演练，把虚机恢复到前一天快照点，开机后Windows事件日志连续报磁盘错误，SQL Server无法正常启动。原因在于快照创建时虚机内还有脏数据在内存缓存里，Prism快照默认只保证崩溃一致性，不保证应用一致性。数据库这类应用要求所有写操作已落盘并记录到事务日志才算一致，而内存中未刷盘的数据在恢复后直接丢失，破坏事务链。

数据库虚机做快照前要在Guest OS里先做一次checkpoint或flush操作。Windows里用sqlcmd -Q "CHECKPOINT"，Linux里用sync，然后再在Prism里手动创建快照。如果用的是保护策略自动快照，Nutanix Guest Tools有协调机制，Windows虚机装了之后会在快照前调用VSS服务，不仅数据库，文件的恢复一致性也高出很多。所以不要在“精简步骤”里省掉Guest Tools，这条经验是血泪换来的。

4.4 现象：克隆后的虚机IP冲突，生产业务断连十分钟

克隆完一台Linux虚机到测试区，启动后没改网卡配置文件里HWADDR对应的IP地址，测试虚机与原生产虚机同时在线，ARP表被两边的MAC地址频繁刷新，整个二层广播域内出现间歇性丢包，生产业务受影响。这不算Nutanix的功能问题，但超融合环境里克隆操作太方便，这个坑更容易踩中。

克隆虚机之后，第一件事是进系统改网卡识别规则。CentOS和Ubuntu的配置位置不同，分别对应/etc/sysconfig/network-scripts/ifcfg-eth0和/etc/netplan/01-netcfg.yaml，要删除保留的旧MAC地址绑定，改成新MAC，并重新设置IP。Windows同理，在设备管理器里把克隆的网络适配器驱动删掉再扫描，让系统生成新的网络配置。如果这个步骤已经手滑，最快止血办法是拔掉测试机的网线或断掉对应VLAN，让它先下线，再把生产虚机的ARP缓存清一下。

4.5 现象：AOS版本升级后，Prism告警乱跳，部分虚机不可正常迁移

AOS升级完成，Prism界面弹出各种“Hosts with unhealthy disk”和“VM migration failed”告警，部分节点存储状态异常，虚机没法做热迁移。排查一圈，发现升级前没有检查主机CVM（Controller VM）和宿主机固件的兼容性。Nutanix每次大版本升级，不只是软件版本替换，底层存储控制器的驱动和固件也要匹配，如果宿主机固件版本过老，CVM和物理磁盘的通信路径会触发异常或超时。

处理方式：先在“Cluster”页面看“Firmware”部分，点击“Check for updates”确认宿主机固件是否为当前AOS版本建议的最低版本。如果不是，让系统先更新固件再执行后续升级。另外升级前先做一次健康检查，Prism页面“Health”选项里运行完整检测，确认项目中没有红色错误再点升级。如果升级已经失败或卡住，联系支持获取“One-click Upgrade”的回滚方案，不要自己乱动节点上的守护进程。

5. 进阶技巧：用容量预测脚本把“快没空间了”变成“提前三周预警”

到了集群规模变大、机器越来越多的时候，只看Prism的当前容量条已经不够，你需要的是预判未来两周到一个月会不会出问题。Nutanix本身带容量规划工具，但在实际项目里我更习惯自己写一个简短的Python巡检脚本，每天定时抓取容量和IO指标，输出一个简单的趋势判断。这样既能监控当前运行状态，又能给“什么时候需要加节点”提供一个量化依据。原理是把nCLI或REST API的输出解析成结构化数据，再按时间序列判断增长斜率。

import requests import json import datetime # 登录Prism API，获取容量数据和IO指标 prism_url = "https://prism-cluster-01:9440/api/nutanix/v3/cluster" session = requests.Session() session.verify = False session.auth = ("admin", "your_password") # 拉取集群容量状态 resp = session.get(prism_url + "/status", timeout=20) data = resp.json() capacity_bytes = data["storage_capacity_bytes"] usage_bytes = data["usage_bytes"] used_ratio = usage_bytes / capacity_bytes * 100 print(f"{datetime.date.today()} 容量使用率: {used_ratio:.2f}%")

逻辑说明：这段脚本通过Nutanix v3 API获取集群存储总容量和已使用量，输出使用率。verify=False是因为Prism默认证书是自签名的，项目内网和测试环境这样用可以，正式环境建议把证书换成CA签发的，verify指到证书路径，避免额外风险。如果要预测剩余可用天数，把最近30天的usage_bytes按天记录，用最小二乘法拟合斜率，再除以当前总容量就能得到一个估算值。

我习惯把这个脚本通过crontab在每天凌晨一点跑一次，结果追加到一个CSV文件，然后在Prism里做一个自定义Dashboard把数据可视化，看一周的曲线比看一天的数字有意义得多。这里有个很现实的教训：曾经有一个集群容量使用率从50%涨到80%只用了三周，Prism没有报警告，因为单日增长量都在安全阈值内，但积累起来就是大问题。后来我把容量预测也纳入巡检，提前两周加了节点，避免了一次“存储写满只读挂起”的翻车。现在每接手一个新集群，我第一件事就是搭好容量预测和巡检脚本，再做任何变更都有底。希望帮到你。

本文还有配套的精品资源，点击获取