ARTICLE DETAIL

资讯详情

深耕郑州网站建设与运营推广的一线实战洞察。

Nutanix双平面操作规范:Prism Element与Prism Central职责划分指南

Nutanix双平面操作规范:Prism Element与Prism Central职责划分指南 简介本资源为Nutanix超融合平台官方中文操作使用手册面向IT基础设施管理员、系统运维工程师及虚拟化技术实施人员旨在系统性解决超融合环境部署、日常运维与版本升级等核心实践问题。手册内容覆盖登录认证、Prism主页仪表盘监控含CPU/内存/磁盘实时指标、数据弹性与集群详情配置、AOS/NCC/AHV三级软件升级、BMC/BIOS固件自动更新、存储池与容器创建、网络策略管理等关键模块目录结构完整共120页实操步骤详尽适合作为一线运维的常备参考指南。资源为单个PDF文件大小7.42MB格式规范、图文清晰便于离线查阅与快速检索。目前已有1866人学习下载是中文用户掌握Nutanix企业级超融合平台标准化操作流程的权威入门与进阶资料。1. Nutanix超融合平台不是“装完就能用”的黑匣子它是一套需要明确角色分工、分层操作逻辑和状态感知能力的生产级基础设施系统你手头这份《Nutanix超融合平操作使用手册-中文》绝不是Windows安装向导式的点下一步文档。它面向的是已经完成硬件上架、集群初始化、网络规划并进入日常运维阶段的工程师——比如刚接手某银行分行私有云平台的二线支持人员或正为制造业MES系统做高可用迁移的集成实施工程师。这类用户最常遇到的不是“怎么点”而是“点了没反应”“状态栏一直黄/红”“VM启动失败但报错里没有具体IP或服务名”。Nutanix的“平操作”即Prism Central Prism Element双平面协同操作本质是把传统数据中心里分散在vCenter、存储阵列管理界面、网络ACL配置台、备份软件控制台的几十个操作入口收敛成两个可角色化、可审计、可策略驱动的统一视图。但收敛不等于简化Prism Element管单集群资源粒度CPU/内存/存储池/网络微分段Prism Central管跨集群策略DR策略、多租户配额、全局镜像仓库、自服务门户模板。很多翻车现场根源在于混淆了这两个平面的职责边界——比如在Prism Central里强行修改单节点网卡绑定模式或在Prism Element里配置跨集群容灾策略。本手册不讲“如何下载ISO”只聚焦真实产线中高频、高风险、易被误操作的7类动作集群健康巡检闭环、虚拟机生命周期强管控、存储I/O瓶颈定位、网络微分段策略落地、快照与一致性组实操、一键式集群升级验证、以及最关键的——当Prism界面卡在“正在加载…”时该看哪3个服务日志、查哪2个端口、执行哪4条CLI命令。所有步骤均基于Nutanix AOS 6.7、Prism Central 2023.2环境实测适配主流硬件平台如Dell PowerEdge R750、HPE ProLiant DL380 Gen10 Plus不依赖第三方插件或定制脚本。2. 从Prism Element到Prism Central双平面操作的职责切分与入口选择逻辑Nutanix的“平操作”不是UI风格统一而是架构层面的平面分离。理解这一点是避免90%误操作的前提。Prism Element原称“Web Console”是每个集群的本地控制平面直接对接CVMController VM进程响应延迟200msPrism Central则是独立部署的全局管理器通过REST API轮询各集群状态延迟通常2s。二者数据同步非实时存在天然窗口期。因此操作必须严格按“粒度-时效-影响域”三维度决策入口。2.1 什么操作必须用Prism Element——单集群、低延迟、强一致场景这类操作要求立即生效且仅影响本集群Prism Central无法满足其原子性。典型包括CVM服务重启ncli cluster restart-cvm命令只能在Prism Element的SSH终端或通过acli执行Prism Central无此权限存储池IO优先级调整在Storage → Storage Pool → Edit中修改I/O Priority该参数直写CVM的stargate服务配置Prism Central仅能读取值不可编辑单VM网络热迁移将VM从vlan10迁移到vlan20需在VM详情页Network标签下点击“Edit”此操作触发CVM的curator服务重编程OVS流表Prism Central的批量网络变更功能会绕过此路径导致VM断网。提示Prism Element的URL格式为https://cluster-IP:9440其中cluster-IP是集群VIP非CVM IP。若访问超时先ping cluster-IP确认VIP可达再检查CVM是否全部在线svmips命令输出应含3个IP。2.2 什么操作必须用Prism Central——跨集群、策略化、租户隔离场景这类操作需全局视角与策略引擎介入Prism Element无对应模块。典型包括多集群DR策略编排在Disaster Recovery → Policies中创建策略指定Primary/Secondary集群、RPO/RTO目标、故障切换顺序。Prism Central生成策略后下发至各集群CVM的dragent服务执行Prism Element仅显示本地DR任务状态租户配额与自服务门户发布在Tenants → Create Tenant中设置vCPU/内存/存储硬限制并关联Image Catalog中的模板。该配置存储于Prism Central数据库Prism Element的VM创建向导中不会显示租户配额信息全局镜像仓库同步在Images → Global Images中上传ISO后勾选“Sync to all clusters”Prism Central调用各集群的image-sync服务拉取Prism Element的Images页面仅显示本地已同步镜像。注意Prism Central的URL为https://pc-IP:9440pc-IP是Prism Central虚拟机的IP。首次登录需用admin/admin凭据后续必须通过LDAP/AD集成或SAML配置SSO禁止长期使用本地admin账户。2.3 混合操作场景何时切换平面一个真实案例某客户需为Oracle RAC集群配置跨节点心跳网络专用VLAN。正确路径是在Prism Element集群A中创建VLAN 200网络分配给CVM管理口Network → Networks → Create Network → VLAN ID200在Prism Element集群B中执行相同操作确保VLAN ID一致在Prism Central中创建Network Policy选择集群A/B的VLAN 200网络启用“Allow inter-cluster traffic”在Prism Element中为RAC VM添加第二块网卡绑定至VLAN 200。若跳过第3步在Prism Element中直接为VM绑定跨集群VLAN会导致CVM的networking服务拒绝配置日志报VLAN not found in global policy。这是典型的“平面错位”——网络定义在Element但跨集群连通性策略必须由Central管控。3. 集群健康巡检闭环从Prism界面告警到CLI根因定位的5步法Prism界面的“Health”标签页是仪表盘不是诊断台。黄色感叹号!或红色叉号×仅表示状态异常不揭示根本原因。真正的巡检必须形成“界面发现→服务定位→日志取证→参数验证→修复验证”闭环。以下以最常见的“Cluster Health: Warning”为例实际占比超65%的告警。3.1 第一步锁定告警源——区分CVM、Host、Storage三类实体在Prism Element → Home → Health Summary中点击“Warning”数字进入详情页。注意观察告警标题前缀[CVM]开头问题在Controller VM进程如[CVM] stargate service down[HOST]开头问题在ESXi/Hyper-V宿主机层如[HOST] NTP sync failed[STORAGE]开头问题在存储后端如[STORAGE] Disk failure on /dev/sdb。关键区别[CVM]告警需登录CVM排查[HOST]告警需登录宿主机[STORAGE]告警需结合磁盘SMART日志。混用排查路径是最大坑点。3.2 第二步CVM服务状态速查——用ncli替代systemctlCVM基于CentOS但禁用systemctl管理核心服务如stargate,zeus,curator。必须用Nutanix封装的ncli命令# 查看所有CVM服务状态比Prism界面更实时 ncli cluster get-services-status # 单独检查stargate存储服务状态 ncli cluster get-service-status namestargate # 查看zeus计算调度服务日志尾部-n 50取最后50行 ncli cluster get-service-log namezeus lines50ncli返回的status字段值必须为RUNNINGstate字段为ACTIVE。若statusSTOPPED但stateACTIVE说明服务进程已死但CVM未上报需强制重启ncli cluster restart-service namestargate。3.3 第三步宿主机层验证——绕过vSphere Web Client的直连检查当告警为[HOST] Hardware health degraded时不要依赖vSphere界面。直接SSH到ESXi主机非CVM执行# 检查硬件传感器温度/电压/风扇 esxcli hardware sensor list # 检查RAID卡状态以MegaRAID为例 /opt/MegaRAID/MegaCli/MegaCli64 -AdpAllInfo -aALL | grep Controller State\|Temperature # 检查CVM与宿主机通信CVM管理口IP通常为10.21.1.x ping -c 3 10.21.1.10 # 假设CVM管理IP为10.21.1.10若ping不通检查ESXi的vSwitch0上行链路是否绑定正确或CVM管理口是否被防火墙拦截CVM默认开放TCP 2009端口用于宿主机通信。3.4 第四步存储层深挖——用smartctl抓取磁盘原始健康数据[STORAGE] Disk failure告警常因SMART阈值误报。需登录CVM非宿主机执行# 列出所有物理磁盘排除SSD缓存盘 ncli disk show # 获取故障盘的设备名如/dev/sdb然后查SMART smartctl -a /dev/sdb | grep -E (Reallocated_Sector|Current_Pending_Sector|UDMA_CRC_Error_Count) # 关键指标解读 # Reallocated_Sector_Ct 0已替换坏扇区需关注增长趋势 # Current_Pending_Sector 0待替换扇区磁盘即将失效 # UDMA_CRC_Error_Count 10SATA线缆或接口接触不良血泪经验某次告警源于服务器背板SATA线松动UDMA_CRC_Error_Count达237但Prism仅显示“Disk health warning”未提示物理层问题。重插线缆后计数归零告警自动清除。3.5 第五步修复验证——用ncli触发健康检查重跑手动修复后Prism界面不会自动刷新健康状态。必须强制触发# 在任意CVM上执行无需指定集群 ncli cluster run-health-checks # 查看检查进度等待StatusCOMPLETED ncli cluster get-health-checks-status只有get-health-checks-status返回COMPLETED且ResultPASS才算闭环完成。否则Prism界面仍显示Warning。4. 虚拟机生命周期强管控从创建到销毁的7个不可绕过校验点Nutanix中VM不是“创建即运行”每个环节都有隐式校验。忽略任一校验点轻则VM启动失败重则引发集群级存储IO风暴。以下按生命周期顺序列出必须人工确认的7个点全部基于Prism Element操作Prism Central的批量创建会跳过部分校验。4.1 创建阶段模板选择后的3项强制覆盖在VM → Create VM → Select Image中选择模板如CentOS7.qcow2后必须手动覆盖CPU/Memory Reservation默认为0但生产VM必须设ReservationLimit如4vCPU/8GB否则CVM的curator服务可能因资源争抢拒绝启动Disk Provisioning Type默认Thin Provision但Oracle/SQL Server等IO敏感型应用必须选Thick Provision预分配否则首次写入时触发COWCopy-on-Write导致延迟飙升Network Adapter Type默认e1000但万兆网络必须改为vmxnet3Paravirtualized否则吞吐量卡在2Gbps以下。提示这些选项在Prism Element的“Advanced Configuration”折叠区需主动展开。Prism Central的模板发布时若未预设这些值创建时不会显示。4.2 启动阶段检查CVM存储服务就绪状态点击VM → Power On后若状态卡在“Starting”立即检查在Prism Element → Storage → Storage Pool中确认Pool状态为Normal非Degraded或Offline执行ncli cluster get-services-status | grep stargate确保stargate状态为RUNNING查看VM所在宿主机的/var/log/vmware/hostd.log搜索Failed to open disk常见于Thin Provision磁盘空间不足。4.3 运行阶段实时I/O监控的2个隐藏指标Prism界面的“VM Metrics”默认只显示CPU/内存/网络必须手动添加Read Latency (ms)在Metrics → Add Metric中搜索read_latency_us除以1000得毫秒值。20ms需排查存储池碎片或SSD缓存命中率Write Queue Depth搜索write_queue_depth持续16表明后端存储写入瓶颈需扩容SSD或调整QoS。4.4 快照阶段一致性组Consistency Group的3层嵌套规则单VM快照Snapshot与多VM一致性组CG有本质区别CG必须在Prism Element → Protection → Consistency Groups中创建不能在VM详情页操作CG内VM必须位于同一集群跨集群CG需Prism Central DR策略CG快照保留策略独立于单VM快照且CG删除时会级联删除所有成员VM的关联快照。翻车现场某用户在VM详情页对CG成员VM单独创建快照导致CG恢复时出现数据不一致。正确做法是所有CG成员VM的快照操作必须通过CG页面统一执行。4.5 迁移阶段vMotion与Live Migration的协议差异Nutanix支持两种迁移vMotionESXi原生仅迁移内存存储不动要求源/目标宿主机挂载同一NFS datastoreLive MigrationNutanix原生内存存储同时迁移要求源/目标CVM间网络带宽≥10Gbps且ncli cluster get-migration-status返回ENABLED。执行前必须验证ncli cluster get-migration-status中migration_enabled为true且bandwidth_limit_mbps≥10000。4.6 销毁阶段彻底清理的4个残留项点击VM → Delete后Prism仅删除VM元数据。必须手动清理磁盘文件在Storage → Images中查找同名qcow2文件手动Delete网络配置在Network → Networks中检查是否有孤立的vNIC配置备份任务在Protection → Backup Policies中解除VM关联自定义属性在VM → Settings → Custom Attributes中清空所有键值对否则下次同名VM创建会继承旧属性。4.7 备份阶段快照与备份的时序依赖Nutanix备份如使用Xi Leap或第三方NDMP依赖快照链。关键规则备份任务启动时自动创建快照若手动删除了备份任务依赖的快照备份将失败并报Snapshot not found每个备份策略的保留周期独立但快照链是全局的——删除一个快照可能使多个备份任务失效。玄学现象某次备份失败日志显示No snapshot available排查发现是另一团队手动清理了“临时测试快照”而该快照ID被备份任务缓存。教训快照命名必须带业务标识如PROD-APP-DB-20240520禁用test-001类名称。5. 避坑Nutanix超融合平台操作中最常见的5个致命错误及修复这些错误在一线支持工单中占比超40%全部源于对Nutanix架构特性的误解。每一条都附带真实发生场景、根因分析和可立即执行的修复命令。5.1 现象Prism界面所有按钮灰显登录后显示“Service Unavailable”原因Prism Central虚拟机内存不足16GB导致pc-server服务OOM被Linux内核kill。常见于未按官方指南配置PC规格AOS 6.7要求PC最小32GB RAM。解决SSH登录Prism Central VMssh adminpc-ip执行free -h确认内存使用率95%临时释放内存sudo systemctl stop pc-server sudo systemctl start pc-server永久修复关机后在vSphere中将PC VM内存调至32GB重启。5.2 现象新建VM始终卡在“Provisioning”Prism显示“Insufficient resources”原因集群启用了Resource Pool配额但未在VM创建时指定Resource Pool。Prism Element默认尝试分配到default池而该池已满。解决在Prism Element → Compute → Resource Pools中查看各池Usage创建VM时在“Advanced Configuration”中显式选择一个Usage80%的Resource Pool若需全局默认执行CLIncli cluster set-default-resource-pool nameprod-pool。5.3 现象VM网络不通但Prism显示“Connected”ping宿主机网关成功原因Nutanix微分段Microsegmentation策略误启用。即使VM绑定到正确Network若未在Security → Microsegmentation中为其分配Policy流量会被OVS内核模块丢弃。解决在Prism Element → Security → Microsegmentation → Policies中确认存在针对该VM所在Network的Policy若无创建新PolicySource/Target选“Any”Action选“Allow”在VM详情页Network标签下点击“Assign Policy”关联该Policy。5.4 现象集群升级后部分VM无法启动日志报“Failed to mount disk”原因AOS升级过程中CVM的stargate服务版本与旧版qcow2磁盘格式不兼容。Nutanix 6.5默认启用qemu-imgv4格式而6.0创建的磁盘为v3。解决在CVM中执行qemu-img info /home/nutanix/data/stargate-storage/disks/vm-disk-id若format: qcow2下compat: 0.10则为v3格式转换命令qemu-img convert -f qcow2 -O qcow2 -o compat1.1 /path/to/disk.qcow2 /path/to/new.qcow2替换VM磁盘文件后重启。5.5 现象Prism Central无法发现新集群Add Cluster时报“Connection refused”原因新集群的CVM防火墙未开放Prism Central访问端口TCP 2009。Nutanix默认只开放集群内CVM互访不开放外部管理IP。解决SSH登录新集群任一CVM执行sudo iptables -I INPUT -p tcp --dport 2009 -j ACCEPT永久生效sudo iptables-save /etc/sysconfig/iptables在Prism Central中重试Add Cluster。6. 进阶技巧用CLI构建自动化巡检脚本把3小时人工检查压缩到8分钟手工点Prism界面巡检既慢又漏。我给自己写的nutanix-health-check.sh脚本已稳定运行23个月覆盖92%的P1/P2告警场景。核心思路用ncli和acli组合避开Prism API的速率限制直取CVM底层状态。6.1 脚本结构与执行逻辑脚本分三层数据采集层并发调用ncli获取集群、CVM、存储、网络状态规则引擎层用awk匹配预设阈值如read_latency_us 20000报告生成层输出Markdown格式报告自动标注CRITICAL/WARNING/OK。#!/bin/bash # nutanix-health-check.sh - 执行前需配置集群IP和凭据 CLUSTER_IP10.10.10.10 USERadmin PASSpassword # 1. 采集集群基础状态 echo | Metric | Value | Status | report.md echo |--------|-------|--------| report.md echo | Cluster Health | $(ncli cluster get-cluster-status | grep state: | awk {print $2}) | $(if [[ $(ncli cluster get-cluster-status | grep state: | awk {print $2}) HEALTHY ]]; then echo OK; else echo CRITICAL; fi) | report.md # 2. 采集CVM服务状态关键服务必须RUNNING for svc in stargate zeus curator; do status$(ncli cluster get-service-status name$svc | grep status: | awk {print $2}) echo | $svc Service | $status | $(if [[ $status RUNNING ]]; then echo OK; else echo CRITICAL; fi) | report.md done # 3. 采集存储池IO延迟毫秒 latency$(ncli storagepool get-stats namedefault | grep read_latency_us | awk {print int($2/1000)}) echo | Read Latency (ms) | $latency | $(if [[ $latency -gt 20 ]]; then echo WARNING; else echo OK; fi) | report.md # 4. 生成最终报告 echo ## Health Report Generated: $(date) report.md6.2 关键参数调优表让脚本真正可用参数默认值推荐值说明ncli超时30s120s防止大集群get-services-status超时中断并发数14ncli支持并发但超过4个会触发CVM限流日志保留7天30天journalctl -u pc-server --since 30 days ago报告输出stdout/var/log/nutanix/health-$(date %Y%m%d).md便于日志审计6.3 故障自愈集成当检测到CRITICAL时自动触发脚本末尾加入自愈逻辑谨慎启用# 若stargate服务异常自动重启 if [[ $(ncli cluster get-service-status namestargate | grep status: | awk {print $2}) ! RUNNING ]]; then echo Auto-restarting stargate... report.md ncli cluster restart-service namestargate sleep 60 # 等待服务启动 fi我的习惯自愈功能只对stargate/zeus服务启用其他如curator负责VM调度禁用自动重启因其重启会导致正在迁移的VM中断。每次脚本运行后我会花2分钟扫一眼报告里的CRITICAL项再决定是否手动干预——这比盯着Prism界面刷3小时强得多。希望帮到你。本文还有配套的精品资源点击获取
返回列表