vSphere 性能优化方法 & 故障排错方法及工具总结 | 周末送资料
本资料主要包括：
性能优化方法：vSphere 性能优化逻辑、针对 VM 的性能优化、针对 CPU 的性能优化、针对 RAM 的性能优化、针对 DISK 的性能优化、针对 Networking 的性能优化。
故障排查方法、工具：vSphere 故障排查思想、针对 Virtual Machine 的故障排查、针对 Storage 的故障排查、针对 vCenter 和 ESXi 的故障排查、常用的故障排查工具箱。
性能优化方法
一、vSphere 性能优化逻辑
1 、虚拟化逻辑分层示意图
2 、X86 结构下虚拟化的问题
• X86 的 os 通常直接运行在物理硬件层面，因此它的执行权限必须为 ring 0.
• X86 虚拟化架构则要求 os 运行在虚拟化层级上面
3 、CPU 软件虚拟化
• 二进制转换是最原始的 32bit x86 虚拟化的指令结构
• 利用二进制转换，就可以实现：
o 让 VMM 单独运行在 ring 0，保证相对独立与性能
o 让 Guest OS 运行在 ring 1.
o 让 Applications 运行在 ring 3.
4 、CPU 硬件虚拟化
• CPU 硬件虚拟化使得 VMM 运行虚拟机变得更加简单
• CPU 硬件虚拟化允许 VMM 不依赖二进制转换依然能够完全控制虚拟机
• 包括以下两种
o Intel VT-x
o AMD-v
5 、Intel VT-x 和 和 AMD-v
• 两者都是 CPU 的一种指令执行模式，它们的主要功能如下：
o 允许 VMM 运行在 ring 0 之下的 root mode
o 自动的通过 hypervisor 来获取权限和灵敏度级别
o 存放 Guest OS 在虚拟 CPU 控制架构中的状态
6、内存工作示意图
7 、虚拟环境性能分析
• 第一维度：
o 单台物理服务器上的单台虚拟机
• Hypervisor 位于物理设备与虚拟机之间
o 影响性能的重要因素
• VMM overhead
• 第二维度：
o 单台物理机上运行多台虚拟机
• Hypersior 位于物理设备与虚拟机之间
o 影响性能重要因素
• 调度开锁以及网路、存储、计算资源不足等问题
• 第三维度：
o VMware vSphere Distributed Resource Scheduler:
• 降低第二维度中可能存在的部分性能问题
o 影响性能的因素
• 高频次的 vMotion 动作
8 、vSphere 环境中影响性能的因素
• 硬件层面：
o CPU
o Memory
o Storage
o Network
• 软件层面：
o VMM
o Virtual Machine 设定
o Applications
9 、关于性能的最佳实践
10 、常见的性能问题
• 通常，性能问题都应该是在进行综合性能定义、管理的过程中出现的
• 综合所有产品的性能问题而言，性能问题通常体现在如下方面
o 应用程序无法满足 Service-Level Agreement
o 应用程序无法满足预先规划的性能浮动范围
o 用户反馈性能故障或吞吐不足
11 、性能问题排错方法论
• 排查性能问题和排查故障问题很多时候都是相似的，或者说：性能问题与故障问题的界限其实是很模糊的，因此都需要遵循类似的方法论，才能比较有效的进行排查
• 根据前辈们和厂家总结的经验，通常都建议参考如下 逻辑来定义故障
o 故障的体现形式是什么？
o 从哪里着手开始查找问题？
o 如何确定怎样检查问题？
o 是否确认找到问题就是真正意义上的问题所在？
o 想要针对性解决这个问题，需要做些什么
o 如果处理之后问题依然存在，接下来该怎么办？
12 、针对 ESXi Host 的 的 Checklist
13 、vSphere
二、针对 VM 的性能优化
1 、VM 性能相关概览
• 经过精细化配置、调校后的 VM 将会为 Applications 提供一个最好的运行环境
• 通常考虑 VM 的性能相关的参数包含下列几个选项
o Guest OS
o VMware Tools
o CPU
o Memory
oStorage
o Network
2 、首先选定合适的 OS 类型
• 在创建 VM 时，一定要正确选择 Guest OS 的类型
• Guest OS 类型会决定缺省的最优化硬件以及配套的设定
3 、保证好 Guest OS 的时间
• VM 里的时间计算逻辑会导致 Guest OS 的时间要想保持准确性是很重要的
• 规避这种可能性的方式
o 尽量选择需要较小时间中断的 Guest OS
• 大多数 Windows、Linux 2.4:100 Hz（每秒 100 个中断计数）
• 大多数 Linux 2.6: 1000 Hz
• 最新的 Linux：250 Hz
o NTP Server 是最好的方法
• 无论如何，别用 2 种以上的时间同少方式
4 、VMware Tools
• 被用于提升 VM 的性能和可管理性
• 保持 VMware Tools 为最新版本
• 确保 VMware Tools 是处于正常被 激活状态的，如果没有被激活，则请激活它
5 、Virtual Hardware 兼容性
• Virtual Hardware 兼容能力丐 ESXi Host 的版本有关系，高版本，低版本的 Virtual Hardware 的功能、性能兼容级别都不同
o 它会影响着 VM 的性能
o 正常状态下只能升级，不能降级
o Virtual Hardware 版本可以向下兼容
6 、Virtual Hardware v10
• 这个版本出现在 vSphere 5.5 当中，其上的虚拟机支持下列新功能
7 、针对 CPU
• 除非运行在 OS 里的 Applicantion 有这个需求，否则尽量避免使用 vSMP
o 激活了 SMP，则进程可能会被 跨 vCPUs 进行迁移，会导致额外的开销
• 如果有选择，最好是使用 OS 缺省的建议配置
8、关于 vNUMA 的使用
• vNUMA 允许 NUMA-aware 的 Guest OS 和 Application 通过硬件层的 NUMA 架构来提升资源利用效率
• vNUMA
o 要求 virtual hardware v8+(ESXi 5.0+)
o 当 vCPUs 数量超过 8 个时自动激活
o 可以在 vSphere Web Client 里激活或禁止
9 、针对 Memory 这部分的考量
• 大内存页面状态下：
o ESXi 可以支持 2MB 的内存页面给 Guest
o 大内存页面内存的使用会降低内存管理开销且能够变相提升 hypervisor 性能
• Transparent page sharing 组件是唯一的 overcommitted
o 如果 Guest OS 或 Applications 能够 handle 的话，建议使用大内存页面
• 为 VM 的交换文件单独找个地方存放
o 在 SSD 上配置 Host Cache 用作存放 swap-to-host cache
o 如果主机没用 swap-to-host cache 功能则建议存放在本地磁盘或远程 SSD 空间
o 尽量不要将交换文件存放在 Thin 模式下的 LUN 上面
10 、针对 Storage 这部分的考量
• 选择好合适 Guest OS 的硬件类型
o BusLogic 或 LSI Logic
o VMware Paravirtual SCSI(PVSCSI)适配器
• 针对 I/O 敏感类型业务选用
• PVSCSI 是一个和 BusLogic 和 LSI Logic 相似的部件，但是它是一个低 CPU 开销、高吞吐、低延迟和更好扩展能力的控制器类型
o Guest OS 队列深度适中
o 对齐 OS 的分
11 、针对 Network 部分的考量
• 如果有的选择，尽量使用 vmxnet3 这款虚拟网路卡：
o 如果不支持 vmxnet3，则可以退而求其次选择 Enhanced vmxnet
o 如果 Enhanced vmxnet 也不支持，可以选择 flexible 类型
• 尽量选择支持主机物理卡高性能功能组件的虚拟网路卡，例如 TCP checksum offlad，TSO 和 Jumbo Frames 等
• 确保物理网路卡运行在全双工模式和最高速状态
12 、开启 VM 的建议
• 在虚拟机开启和成功启动前，会消耗大量的资源
o CPU 和 Memory reservations 必须要得到满足
o 需要足够的磁盘空间用于存放下面 2 个 vswp 文件
• *.vswp
• vmx-*.vswp
o 如果为 vm 配置了 vSphere Flash Read Cache(vFRC),则还需要足够的 SSD 磁盘
13 、开启 VM 的 CPU 和内存预留
• 为了顺利开启 vm，ESXi Host 必须要有大量的 CPU、内存资源用于满足虚拟机的启动。当然，还需要包含启动这台虚拟机所需要的额外 Memory 开销
14 、针对 VM 的 的 Swap 文件存放建议
• 想要成功开启 VM 还需要有足够的存储空间存放 swap 文件
o *.vswp 交换文件的大小取决于虚拟机已配置的内存及预留值
o vmx-*.vswp 交换文件的大小取决于虚拟机的 Overhead Memory 和 Vmkernel 的 Reservation
15 、开启 VM 的 的 vSCSI 类型建议
• 要想成功启动 VM，Guest OS 必须要支持 SCSI Controller
• SCSI Controller 的选择可以在创建时和创建后去修改
• 创建虚拟机的向导中，会根据 Guest OS 类型不同而设定不同的默认建议选择
16 、VM 性能最佳实践
• 在创建 vm 时，选择合适的 Guest OS 类型
• 把不必要的设备，例如:USB, CD-ROM, 软驱等删除
• 仅仅在 Applications 支持 Multi-Threaded 时才配置 SMP
• 为 Guest OS 配置好时间同步
• 务必为 vm 安装 VMware Tools 并且保持为最新版本
• 建议使用最新的 Virtual Hardware 版本
• 针对大 I/O 类型的业务，需要考虑清楚，因为它会导致 Guest OS 的 I/O 性能受到影响
• 做好对 Guest OS 的分区对齐
• 尽可能使用 vmxnet3
三、针对 CPU 的性能优化
1 、World 概念概述
• 基本上，可以将 World 理解为 CPU 上调度的执行任务
o World 就好像是传统 OS 里的进程一样
• 所以，VM 就相当于一级 worlds 的集合
o 一个用于每个 vCPU
o 一个用于虚拟鼠标、键盘、屏幕（MKS）
o 一个用于 VMM
• CPU Scheduler 会选择将 World 调度到对应物理 CPU 或 core 上
2 、CPU Scheduler 组件
• CPU 资源的分配对于用户而言是动态和透明的
o 将 vCPUs 调度到物理 CPUs 上
o 每 2 ~ 40ms 会检查一次物理 CPU 的使用情况，然后按需去迁移 vCPUs
• 针对 CPU 的使用情况，强制采用 proportional-share 算法
o 每当 CPU 资源 overcommitted，则主机会在所有的 VMs 上执行物理 CPU time-slice
o 每个 vCPU 在调度时，会按照资源设定的优先级别去调用
3 、CPU Scheduler 组件：VM SMP 相关
• VMware ESXi 使用 co-scheduling 表来优化虚拟机 SMP 的效率
• Co-scheduling 的工作原理将同一时间的 CPU 调度请求分散到不同的物理 CPU 上
o 每一颗 vCPU 都会随时可能 Scheduled、Descheduled、Preempted、Blocked 等
• 在 SMP 虚拟机里发生 vCPUs 调度时，CPU Scheduler 可能会导致调度不均衡的问题
o 两颗以上的 vCPUs 的 SMP 虚拟机在调度到不同的 CPU 上时可能存在不同的执行速率，所以会不均衡
o 当除了某个 vCPU 外，整体的 vCPUs 的调度并没有完整执行，vCPU 的不均衡程度会加剧
o 当 vCPU 不均衡比例超过一定比例之后，也会被判定为不均衡
4 、CPU Scheduler 组件：Relaxed Co-Scheduler
• 该组件技术表示检测到不均衡之后同时调度大量虚拟机 vCPUs 的技术
o 减少虚拟机 Co-start 对物理 CPUs 数量的要求
o 增加 CPU 的利用率
• 针对 idle 的 vCPU 不存在 co-scheduling 的开销部分
5 、CPU Scheduler 组件：Processor topology
• CPU Scheduler 使用 Processor topology 信息来优化 vCPUs 在不同 Sockets 的位置存放选择
• CPU Scheduler 会尽可能在所有的 Sockets 上去分布负载，以便充分利用可用的 Cache
o 单 Socket 里的 Cores 通常会使用共享的 Last-Level Cache
o 使用共享的 Last-Level Cache，可以在内存敏感业务上提升 vCPU 的性能
• 当 SMP 虚拟机在 vCPUs 之间表现出明显的数据共享时，则依托缓存分布的方式将会是退而求其次的负载分布方式
o 可以通过在 vmx 文件里增加 sched.cpu.vsmpConsolidate= "TRUE"这行参数来覆盖掉缺省的调度逻辑
6 、CPU Scheduler 组件：NUMA-aware
• 在 Non-Uniform Memory Access(NUMA)主机上都会有直边到 1 个或多个本地内存控制器的 CPU 来提供本地内存：
o 同一台物理服务器上，通过本地内存访问 CPU 的进程效率会高于远程内存
o 当虚拟机的内存分布中大部分不在本地内存是，就意味着此时的 NUMA 性能是较差的
• NUMA scheduler 限制 vCPUs 到单一的 Socket 上，以便充分利用缓存
7 、Wide-VM NUMA Support
• Wide-VM 表示虚拟机拥有超过 NUMA 节点所有 Cores 的 vCPUs 数量
o 例如：1 台 4 vCPUs SMP 虚拟机可能分布在 2 Scokets, 2 Cores 的环境
o 只有当 Cores 的数量满足才不算 Wide-VM（HT 不算）
• 1 台 8 vCPUs 虚拟机可能 分布在 2 Scokets, 4 Cores 系统上，跃然激活了 HT，不过由于每个 NUMA 节点的 CPU 只有 4 Cores，所以，算作 Wide-VM
• Wide-VM NUMA 支持将 Wide-VM 分割到更小的 NUMA Client 环境里
o Wide-VM 为每个 Client 分配一个 Home Node
• 例如：1 台 4 vCPUs SMP 虚拟机运行在 2 Socket， 2 Cores 的系统时，会有 2 个 2 vCPU NUMA Clients;1 台 8 vCPUs SMP 虚拟机运行在 2 Sockets, 4 Cores 的系统时，会有 2 个 4 vCPU NUMA Clients.
o Wide-VM 由于包含多个 Clients，所以存在多个 Home Nodes，每个 Client 都有自己的 Home Node
8 、Wide-VM NUMA Support 的性能影响
• 以 1 台运行在 2 Sockets, 4 Cores 主机上的 8 vCPUs SMP 虚拟机为例（在这案例中，Wide-VM NUMA 支持与否都不影响性能） ：
o 假设是 Uniform Memory Access, 大约 50%的内存在 Local，因为如果不用 Wide-VM NUMA Support, 则会有 2 个 Home Nodes
• 以 1 台 4 Sockets, 2 Cores 系统为例，只有 25%左右的内存在 Local（这样一来，性能就会比直接访问好 1/2 左右） ：
o Wide-VM NUMA support 则相当于变相提升 50%的本地内存访问比例
9 、影响 CPU Performance 相关因素
• Idling virtual machines:
o 主要是 Gues 需要的 Time Interrupts 开销
• CPU affinity
o CPU affinity 则会限制 Scheduler 并且会导致负载不均衡
• SMP virtual machines
o 会产生 Co-Scheduling 的开销
• CPU 资源不足时的资源调度逻辑
o 如果存在 CPU 争用，则 Scheduler 会强行按照优先级顺序去依次满足高优先级>低优先级的虚拟机 CPU 请求
10 、CPU Read Time
• vCPUs 的工作模式是从 CPU Scheduler 根据 Proportinonal-share 算法去获取物理 CPU 的 Cycles
o 如果 vCPU 想要尝试去在没有可用 CPU Cycles 的物理 CPU 上执行指令时，请求会被列入等待队列
o 物理 CPU 没有 Cycles 通常都和物理 CPU 不够用或高优先级的 vCPUs 多吃多占有关
• vCPUs 等待物理 CPU 的可用 Cycles 时间集合就是 CPU Ready Times
o 从概念上来看，就该知道，这样一来必然会影响到 Guest OS 的 Performance
注：关于 RDY ，详情请查阅 :http://bbs.vmanager.cn/thread- - 6311- -1 1- - 1.html
11 、vSphere Client 查看 CPU 指标
12 、esxtop 下的 CPU 性能分析参数
• PCPU USED(%): 物理 CPU 的使用率
• 每一组的统计数据信息：
o %USED:使用率（包含%SYS）
o %SYS:VMKernel 系统的活动时间
o %RDY:Ready Time
o %WAIT:Wait 和 idling 时间
o %CSTP:提交到 co-schedule 的百分比
o %MLMTD:由于 CPU Limit 导致的无法调用运行参数
o NWLD:指定 Group 分配到的 Worlds 数量
• 输入"V"可以查看虚拟机的相关输出信息
• 输入"e"可以显示为虚拟机分配的所有可用 worlds
• 用于监控性能的重要指标
o High-usage 值
• 这个值通常都意味着高资源使用率
• 这个参数适用于几乎所有的对象
o Ready time
• 这是衡量 CPU 是否存在性能问题的重要指标
• CPU Ready Time 发生在虚拟机的 CPU 请求数量超过物理 CPUs 可用数量的情况下
• 计算方式：x * 100% / 20000 = 0.0001 y%
注：x x = 时间，单位 ms ， 20000 单位为 ms ，缺省系统刷新周期为 20s ， y = RDY 的百分比（超过 10% 时则会存在性能问题，超过 5% 时可能就会存在，但当时可能并不存在严重性的性能问题）
四、针对 RAM 的性能优化
1 、Mem.FreeMinPct
• Mem.MinFreePct 是 VMkernel 需要保持为 free 状态内存数量的控制参数
o VMkernel 通过弹性比例基于为 ESXi Host 配置的内存来决定 Mem.MinFreePct 这个参数值
2 、VMkernel 执行内存回收逻辑
3 、vSphere 5.x 内存回收阀值计算
• 假设 Mem.MinFree 值为 1619MB，则内存阀值计算比例如下 ：
4 、Guest OS 里面的内存相关参数
• 通常情况下 Guest Memory 和 Host Memory 的使用率是不同的，为什么呢？
o Guest physical memory
• Guest 里面可在评估活动内存状况时更加直观
• ESXi 活动内存评估技术需要时间去完成
o Host physical memory
• Host memory 使用情况并不会如实显示 Guest 的内存相关情况
• Host memory 使用情况会基于虚拟机在物理主机和 Guest 内存使用相关优先级而定
5 、Consumed Host Memory 和 Active Guest Memory
• Consumed host memory > active guest memory
o 如果没发生 Memory overcommitted，这种状态是 ok 的
o Consumed host memory 代表着 Guest 的最高内存使用量
• Consumed host memory <= active guest memory
o Active guest memory 不完全等于 Host Physical Memory
o 这种情况下，则性能可能存在问题
6 、利用 resxtop 监控内存状况
7 、vSphere Client 监控 Host Swapping
8 、在 resxtop 下的 Host Swapping -01
9 、在 resxtop 下的 Host Swapping-02
10 、vSphere Client 监控之 Balloon Driver
11 、resxtop 下的 Host Balloon
12 、Active Host-Level Swapping - 01
13 、Active Host-Level Swapping - 02
14 、解决内存不瞳的问题
• 解决 Host Swapping 的问题
o 为虚拟机安装 VMware Tools 借此激活 Balloon Driver 功能
o 减少为虚拟机设定的 Reservation 值
o 为 ESXi Host 添加物理内存
o 减少 ESXi Host 主机上 VMs 的数量
o 为虚拟机启用 Host Plug Memory 的功能，方便增加
15 、Balloon Driver vs Swapping
16 、什么时候出现 Swapping 发生在 Balloon 前？
• 同时开启大量虚拟机时就会出现这个情况
o 此时，虚拟机会消耗大量的内存
o 由于需要 VMware Tools 支持，所以 Balloon Driver 没有启动，因此就会导致 Swapping
• Host-Level Swapping 会导致启动缓慢，不过，完成启动之后，不一定会影响性能
• 虚拟机的内存被 Swap Out 到磁盘时，也不一定会影响性能，如果这部分内存不被访问的话
17 、Memory Best Practice
• Memory 最佳实践
o 为必要的 VMs 分配足够的内存，避免 Swapping
o 不要禁止掉 Balloon Driver
o 保证 TPS 功能开启
o 避免过大的 Memory Overcommitted
o 为必要的 VMs 启用 Memory Hot-Plug 功能
o 配置 Host Level Cache， 用 SSD 做 cache disk
o 不要为 ESXi Host 运行太多 VMs
五、针对 DISK 的性能优化
1 、针对 Datastore 的 的 Performance 相关监控
2 、磁盘相关参数
• 检查是否存在磁盘故障
o 确认是否有足够的带宽，看看是否能满足预期应用的开销需求
• 针对这样的问题，怎么办？
o 检查相关的关键参数，包含类似下面几个参数：
• 磁盘吞吐
• Device、kernel 的 Latency
• 磁盘命令的被迫终止数目
• 磁盘命令的 Active 数目
• 队列的 Active 命令数目
3 、vSphere Web Client 监控磁盘吞吐
• 关键参数：读、写速率和使用情况
4 、利用 resxtop 监控磁盘吞吐
• 下面几个参数被用于评估磁盘的吞吐情况：
o READs/s and WRITEs/s
o READs/s + WRITEs/s = IOPS
• 也可以选用 MB 的方式来计算
o MBREAD/s and MBWRTN/s
5 、磁盘吞吐状况范例
•注：输入字母 d 可以看 hba 卡相关的信息
o输入字母 u 可以查看 lun 的相关信息
o输入字母 v 可以查看虚拟机相关的信息
6 、vSphere Web Client 监控磁盘 Latency
7 、利用 resxtop 监控磁盘 Latency
• DAVG/cmd:LUN 的平均延迟，以 ms 为单位
• KAVG/cmd:vmkernel 的平均延迟，以 ms 为单位。通常超过 3ms 就会有性能问题
• GAVG/cmd:Guest 的平均延迟，以 ms 为单位，GAVG = DAVG + KAVG
• QAVG/cmd:队列的平均延迟，以 ms 为单位
8 、监控命令和队列命令
9 、磁盘 Latency 和队列范例
10 、监控是否存在严重存储过载
• vSphere Web Client 视图:Disk Command Aborts
• resxtop 命令参数：ABRTS/s
11 、针对 Datastore 配置 Alarm
•为 Datastore 配置 alarms 的方式如下：
o右击 datastore --> Alarms --> New Alarm Definition --> 输入想要在发生状态的监控条件
12 、分析 Datastore Alarms
•点击 Monitor --> Issuses --> Triggered Alarms
13 、设备驱动队列深度
• 设备驱动队列深度决定 LUN 在同一时间支持的活动命令数目
• 设置设备驱动队列值可以用于降低磁盘延迟：
o Qlogic 适配器默认队列深度为 64
o 其它的通常缺省队列深度为 32.
o 最大队列深度建议为 64.
• 将 Disk.SchedNumReqOutstanding 的值设定为与队列深度一样的最合适
14 、存储队列
• ESXi Host 主机端的队列：
o 设备驱动队列深度控制着 LUN 上面任意时间的活动命令数目
• 缺省深度 32.
o VMkernel 队列是设备驱动队列的溢出部分
• 存储陈列队列：
o 当针对存储阵列的活动命令数据过高时，就会产生这个部分的队列
• 在主机端或存储阵列端如果有大量的队列，就会增加命令延迟
15 、SCSI Reservation 用途讲解
• SCSI reservation 用来干什么:
o LUN 在一个较短周期内被单一主机占用的时间
o 当 VMFS Metadata 被更新时，被用于支持 VMFS 实例锁定文件系统
• Metadata 更新的通常会受到下列因素影响：
o 创建、删除 VMDK
o 增加 VMFS Size
o 增加 VMDK 文件 Size
o 更改磁盘的模式
• 最小化对虚拟机性能影响：
o 别在高峰时期去做前面那些事情
• 如果存储阵列支持 vSphere Storage APIS - Array Integration(VAAI)和硬件辅助锁定功能，则 SCSI reservation 是不必要的。
16 、存储多路径技术简介
• 可以帮助解决存储的存储性能故障
• 支持下面几种 Path Selection Policy:
o Most Recently Used(MRU)
o Fixed(Fixed)
o Round Robin(RR)
o Maybe Third-Party(PSP)
17 、VMware Virtual SAN 对于 DISK 性能相关
18 、vFRC 概述
• 关键组件：
o 内置于 Hypervisor、软件定义、SSD 配合 HDD 的分层存储
o 基于 Flash 设备提供针对 VMs 的高性能读取访问支持（Virtuall Flash Host Swap Cache）
o 将本地设备配置为 Flash Cache.
o 可以与下列组件结合：
• 要求 vSphere 5.5 Enterprise Plus
• VMware vCenter Server
• vSphere HA
• vSphere DRS
• VMware vSphere vMotion
19 、vFRC 与 与 DISK 性能优化
20 、vFRC Volume 限制
十二、针对 Networking 的性能优化
1 、网路相关的参数
• 衡量网路性能相关的参数有哪些？
• 通常，和网路相关的关键参数主要是和网路统计信息相关的部分，包括：
o Network usage
o Network packets received
o Network packets transmitted
o Received packets dropped
o Transmitteed packets dropped
2 、vSphere Web Client 监控网路相关信息
4 、利用 resxtop 监控网络统计信息
• 输入字母 n 可以查看网路相关的统计示意图
• 相关重要参数包括:
o MbTX/s: Data transmit rate
o MbRX/s: Data receive rate
o PKTTX/s: Packets transmitted
o PKTRX/s: Packets received
o %DRPTX: 传输的丢包率百分比
o %DRPRX:接收包的丢包率百分比
5 、vSphere Web Client 下查看网路性能
6 、利用 resxtop 查看网路性能
7 、Network I/O Virtualization Overhead
• Network I/O Virtualization overhead 可能来自于不同的层面，例如：
o Emulation 开销
o 包处理过程中
o 调度
o 虚拟中断组合
o 物理 CPU 带来的 Halt 和 Wake Up
o 虚拟 CPU 带来的 Halt 和 Wake Up
• Network I/O latency 也会由于网路虚拟化的开销导致增加
8 、vmxnet 虚拟网路卡
• vmxnet 是 VMware 的准虚拟化设备，有如下优势：
o 在虚拟机和 VMkernel 之间共享 Ring 的 Buffer
o 支持传输包聚合处理
o 支持中断聚合处理，以便减轻来自网路的中断开销
o 支持 Offloads TCP checksum 到硬件的计算
9 、影响网路性能的相关组件
• vSphere 通过结合物理网路卡的新特性，来实现针对网路性能的提升和保障，包括：
o TCP checksum offload-简单说就是利用网路卡进行 TCP 校验
• TCP checksum offload 是物理网路卡的功能之一，它的好处在于：
▪ 允许利用网路卡针对网路包执行 checksum 操作
▪ 降低来自物理 CPU 开销压力
▪ 能够根据包的大小来不同程度上提供更好的性能支持
o TCP segmentation offload-简称 TSO，简单说就是利用网路卡对 TCP 包切片
• TSO 可以通过减少大量来自 TCP 流量发送所需的 CPU 负载的情况下提升网络性能：
▪ 较大 TCP 包会被 Offload 到网路卡来进一步细分处理
▪ 网路卡会将其切割到 MTU 大小的帧
• 如果网络卡支持，则 TSO 会默认在 VMkernel 接口上激活
• 虚拟机级别的 TSO 需要手动激活
o Jumbo frames
• 在进行包传输前，IP 层会将包切片到 MTU 帧大小：
▪ 缺省的 MTU 是 1500 字节
▪ 接收端自行重组相关数据
• Jumbo Frames 的特征如下：
▪ 支持更大的以太网包，最大为 9000 字节
▪ 可以减少帧的传输数量
▪ 可以降低发送和接收端的 CPU 使用率
• 虚拟机端虚拟网路卡最好是配为 vmxnet3
• 网路的端到端都需要支持 Jumbo Frames
o 利用 DMA 直接访问内存
• 为了加快包处理效率，网路卡可以被允许直接 DMA（Direct Memory Access）到 Memory
• DMA 的好处
▪ 绕过 CPU，让 NIC 直接访问内存
▪ 避免内存空间需要通过 VMkernel 处理一次的情况
▪ 利用 Scatter-Gathe 的方式来实现将内存写入到不相邻的内存区块
▪ 允许灵活的使用可用内存，进而提供更好的性能
o 10 Gigabit Ethernet 与 40 Gigabit Ethernet
o NetQueue
• NetQueue 的性能提升主要体现在下面几个方面：
▪ 在 10GbE 和 40GbE 网路卡环境下大幅提升虚拟环境的网路性能
▪ 使用 Multiple Transmit、Multiple Receive Queues 的方式来实现将 I/O 在不同 CPU 上处理
▪ 不过仅限于支持 MSI-X（Extended Message Signaled Interrupts）系统类型
o VMware vSphere DirectPath I/O
o vSphere DirectPath I/O 允许虚拟机直接访问使用物理网路卡
o vSphere DirectPath I/O:
• 要求底层激活 IOMMU
• Intel CPU 要求支持 VT-d， AMD CPU 要求支持 AMD-Vi
• SpliRx Mode
o SplitRx 通过利用多物理 CPU 来处理单一网路队列中收到的网路包的方式，帮助提升网路性能
o 当同一台 ESXi Host 上多台 VMs 接收来自相同数据源的多播通讯时激活 SplitRx 模式
o 只有 vmxnet3 支持 SplitRx 模式
o SplitRx 模式会在 ESXi Host 检测到物理网路卡上单一网路队列符合下列条件时会被 激活：
• 网路卡的使用率负载过重
• 网路卡每秒超过 10000 个广播或多播包时
10 、Single Root I/O Virtualization
• Single Root I/O Virtualization(SR-IOV)允许单块物理 PCI Express（PCIe）卡同时被多台虚拟机使用
• SR-IOV 的工作场景如下：
o 针对网路延迟延迟活 CPU 敏感型业务的虚拟机
o 针对需要 Offload I/O 到物理网路卡处理和需要降低网路延迟的业务
• SR-IOV 配置要求：
• SR-IOV 兼容的功能，当 SR-IOV 功能启用后，以下功能将无法使用
o VMware vSphere vMotion
o VMware vSphere Storage vMotion
o VMware vSphere High Availability
o VMware vSphere Fault Tolerance
o VMware vSphere Distributed Resource Scheduler
o VMware vSphere Distributed Power Management
o Virtaul Machine 挂起与恢复
o Virtual Machine Snapshots
o 虚拟机设备热添加
o Cluster
11 、Network 性能最佳实践
• 尽可能使用 vmxnet3 这块虚拟网路卡
• 尽可能充分利用物理网络卡的高性能组件
• NIC Teaming 帮助 Load Balancing
• 合理的规划虚拟交换机构成，条件许可的情况下分开不同业务到不同的 vSwitch
• 条件许可的情况下，尽量启用 Traffic Flow、Network I/O Control 等功能
• 在网路负载较重的情况下，尽可能保证足够的物理 CPU 性能
故障排查方法、工具总结
(建议手机横向阅读)
一、vSphere 故障排查思想
1 、故障排查思维逻辑
故障排查涉及到整体的排错方法论，总体而言，故障排查需要遵循一个工作逻辑：
确认问题状况
o 确认问题所在
o 收集故障相关问题
确认导致故障的原因
o 确认什么原因导致的问题
o 诊断问题的根本原因是什么
解决问题
o 制定可能的解决方案
o 评估数据安全风险
o 执行最佳解决方案
2 、故障排查逻辑图示（流程及细节）
图示说明：
配置问题、软件 Bug、硬件故障是三种最为常见的故障
软件 bug 示例
o 在 ESXi 5.5 u1 或 u2 中存在这样一个常见的软件 Bug：网卡原因紫屏事件
硬件故障示例
o 若主机 HBA 卡电池出问题，可能会在写上面会有很差的表现
3 、vSphere 常规故障分层
4 、故障解决 E2E
故障状态 | 故障原因 |
1 个或多个 LUN 不可见 | LUN 不可见，存储可能没有恰当的 MAP 到主机 |
无法通过 vSphere Web Client 连接 vCenter | VirtualCenter Service 没有启动 |
Virtual Machine 无法启动 | 文件可能被锁定，文件可能丢失 |
5 、案例流程 - 故障状态（示例）
6 、案例流程 - 日志搜集（收集日志信息，用于进行故障分析）
7 、案例流程 - 可能性分析
利用结构化思维来进行故障分析，可以有效提高排错效率；
根据问题的提示，按照下图所示排错流程来进行排错
图示说明：
自上而下进行排错
自下而上进行排错
从中间环节排错
8 、案例流程 - 查找问题的根源
通过反复测试，来确认问题的根源所在，例如：VM 无响应的排错逻辑：
图示说明：
如果仅仅是单台虚拟机无响应，建议自上而下
若涉及很多虚拟机响应慢，建议从中间环节
存在告警，建议从下而上
9、案例流程 - 解决问题
完成问题根源定位之后，评估问题可能带来的影响
o 较大影响 - 立即解决
o 一般影响 - 条件许可的情况下解决
o 较小影响 - 有空解决
制定解决问题的方案
o 头疼医头 - 立刻就事论事解决问题
o 头疼医脚 - 避免同一个问题再次发生
o 长远考虑 - 整体考虑，从未来的思路触发去执行问题处理
10、vSphere 常规故障排查流程 - 追根溯源（图示）
图示说明：
此处以 vMotion 为例，其它故障与此类似
11、vSphere 排错组件归纳
二、针对 Virtual Machine 的故障排查
1、VM 故障排查思想
2 、VM 的文件架构
3 、Content ID
所谓 CID，位于 VM 的磁盘描述文件里面，负责磁盘相关整合状态跟踪
图示说明：
• 母盘的 parentCID 为"fffffff"
• 若虚拟机有快照，则第一级快照的 parentCID 为母盘的 CID，第二级快照的 parentCID 为第一级快照的 CID（若虚拟机存在多层快照，则依次类推）
• 如果快照层级出问题，可能会导致快照出问题，很有可能导致虚拟机无法启动
4 、故障 01 - 解决 Countent ID 不匹配的问题
• Step1：备份好磁盘描述文件
• Step2：下载这个文件，用文本编辑器打开，然后修改 CID
• Step3：修改之后，利用如下命令来验证 CID 的修改是否成功(若提示失败，则意味着 CID 的更改没有成功)
o vmkfstools -q Win01-A-000002.vmdk -v10
注意：虚拟机快照导致的虚拟机无法启动的故障，很多时候都是快照层级发生错乱所致。这类问题可以采用上述方法来解决。
5 、故障 02 - 解决 Snapshot 之 之 vss 导致故障（执行 Snapshot 时，提示 I/O 静默调用失败）
• VM 有大量的 I/O 负载导致在执行 Snapshot 时 I/O Quiescing 失败
• 通常通过下面 2 个技术来执行 I/O Quiescing
o Microsoft Volume Shadow Copy Service(VSS)
o VMware Tools SYNC driver
• 初始化检查
o 检查是否可以手动创建一个不调用 I/O Quiescing 的快照
6 、解决 I/O Quiescing 导致的 Snapshot 失败的故障问题
• 如果利用 VSS 执行 I/O Quiescing，则需要确认下列条件是否满足
o VSS 要求满足
o 相关服务是正常运行状态
o Microsoft Software Shadow Copy 服务正常
o VSS Writer 没报错
• 如果利用 SYNC Driver 执行 I/O Quiescing，则需要确认下列条件满足
o 禁止掉 SYNC Driver
o 在执行 Snapshot 之前，先将 I/O 密集型的业务停掉（比如数据库）
• 老版本的 Windows OS 没包含 SYNC Driver 在 Microsoft VSS 里面
7 、故障 03 - VM 开机失败
• 在 vmware.log 文件里面可以看到虚拟机开启失败
• 故障原因逻辑分析（从上到下）
• 分析是否 vm 文件丢失
o 执行如下命令来查看是否存在文件丢失
• ls /vmfs/volumes/Shared/Win01-B
• 解决方案
o 利用之前的备份来恢复
o 如果 descriptor 文件丢失，手动重建这个文件
• 分析是否虚拟机被锁定
o 确认是否存在文件被锁定
• 尝试开机虚拟机，如果失败，说明可能有锁定
• 执行如下命令查询是否有文件被锁定
▪ touch filename
• 可执行如下命令查看哪台 ESXi Host 锁定磁盘文件
▪ vmkfstools -D /vmfs/volumes/Shared/Win01-B/Win01-B-flat.vmdk
• 执行如下命令来找到锁定的进程信息
o lsof | grep <name_of_locked_file>
• 找到后杀掉它
• 如果依然无法确认那个进程导致虚拟机文件锁定，那就用最简单的逻辑
o 迁移虚拟机或重启 ESXi Host
8 、故障 04 - VMware Toolsf 无法安装( 最有可能是 GOS 类型选择错误)
• 检查 Guest OS 类型是否正常
• 分析 Guest OS 类型选错的问题
9 、故障 05 - Virtual Machine orphaned( 虚拟机被孤立)
检查 vCenter Server 是否在 VM 执行迁移的过程中重启过该虚拟机（在迁移到 60%的时候最容易出现），因为在虚拟机被重启时，会临时性的无法使用，状态就会显示为 orphaned
• 故障原因逻辑分析（自上而下）
• 分析 vMotion 或 DRS 导致故障
o 确认是否由于迁移导致故障
• 查看 Tasks 页标签
• 检查 orphaned 虚拟机被注册到的源或目标 ESXi Host
o 如果有找到虚拟机被注册到 ESXi Host
• 重启 ESXi Host 的管理服务
o 如果没有找到虚拟机被注册的信息，则执行
• 注册虚拟机到 ESXi Host 或 vCenter
• 利用 orphaned 虚拟机的 vmdk 创建全新的虚拟机
• 分析虚拟机没通过 vCenter 删除导致故障
o 执行如下命令去验证虚拟机的文件是否存在
• ls /vmfs/volumes/shared/Win01-B
o 如果配置文件被删除，则执行如下动作来恢复
• 重建虚拟机，借此重建*.vmx 文件
o 如果虚拟机的磁盘文件被删除，则执行
• 备份恢复计划
• 分析*.vmx 文件导致故障
o *.vmx 这个文件包含了虚拟机的所有配置信息，如果它被破坏可能会出现上述问题
o 解决思路
• 利用文件编辑器打开这个*.vmx 文件，去掉其中不当部分后重新尝试
• 从备份信息里恢复*.vmx 文件
• 直接从 Inventory 里移除掉虚拟机，然后重建 vm
• 分析 ESXi Host 根文件系统空间不足导致的故障
o 当 ESXi Host 的根文件系统空间不足时，系统可能会尝试删除掉虚拟机
o 可以执行如下命令来确认是否存在这个问题
• DCUI 下面执行:df -h
• 清除不必要的根文件系统里的内容
• 从 Inventory 移除掉 VM，再重新添加
10 、故障 06 - Virtual Machine Snapshot 故障（尝试创建或者处理快照时出错）
• 确认 vm 的磁盘是否支持 Snapshot，因为 RDM 的 Physical Mode、Independent Disk 等状态下是无法做快照的
• 由于 Snapshot 最多支持 32 级，因此，超过后会无法执行
• 故障原因逻辑分析（自上而下）
• 分析描述文件混乱问题导致故障
o 快照的 delta 文件在描述文件里错乱
• 000001-delta.vmdk 文件在 000001.vmdk 里没有正确描述
o Delta 磁盘根本就没了描述的配对文件
• copy 基础磁盘的描述文件，然后更名为配对 Delta 磁盘的描述文件
• 编辑里面，将相关的配对信息更改为 Delta 磁盘的信息
• 分析文件尺寸过大问题导致故障
o VMFS 5 Datastore 单个文件最大支持 62.93TB
o 快照最大值会受到限制
• VMFS 5 里，最大只能超过原始盘的 8GB 左右
• 这里的 8GB 的来源是开销的部分
• 分析 Datastore 空间不足问题导致故障
o 要处理所有的快照信息的前提条件就是 Datastore 的空间要足够
o 可以通过如下方式来确认是否有足够的空间
• 去 GUI 下查看快照所在的 Datastore 空间是否 ok
• 在 ESXi host 上运行命令：df -h
• 解决方案
o 增加 Datastore 的尺寸
o 移走虚拟机
三、针对 Storage 的故障排查
1 、Storage 故障排查逻辑
2 、vSphere Storage 架构示意图
• 当虚拟机无法使用时，排除其它故障，很大程度上会与 Storage 部分有关系。下图是 vSphere 环境下的 Storage 结构示意图：
3 、存储故障 01 - IP Storage 无法被 ESXi Hosts 访问
• 确认 ESXi Hosts 能看到虚拟机所在的 storage
o esxcli storage core path list
• 执行 rescan 动作看看能否重新查看到
o esxcli storage core adapter rescan -A <vmhba##>
• iSCSI Storage 结构示意图
o 如果 ESXi Host 出现连接 IP Storage 故障时需要去检查如下图所示的地址：
• 故障原因分析逻辑
o 如果 ESXi Hosts 过去访问 IP Storage 正常，在没做任何更改的情况下出现故障，则可以参考如下流程进行故障解决尝试：
• 检查存储硬件级别的问题
o iSCSI HBA 卡或 iSCSI Storage 阵列不被 ESXi Host 支持（比较少见）
去 vmware 的 HCL 里查看型号
o 确认 LUN 被正确的映射到适当的 ESXi Hosts 上
• 同一个存储组里的 LUN 是否被映射到所有的 ESXi Hosts 上
• LUN 的构建是否符合 ESXi Host 的使用标准
• 不同 ESXi 版本支持的 LUN 大小是不一样的
• 存储的微码版本
• LUN 是否被设定为 R/O（只读）
• 阵列上 For ESXi 的 Host ID 是否小于 255
o 存储设备故障
• 利用硬件工具诊断存储故障
• 检查是否 iSCSI 存储性能
o 检查是否设计了最佳 IP Storage 网路：
• 规避链路问题导致的过载
• 分开 iSCSI Traffic 和 NFS Traffic 以及其它相关的 vmk 接口
o 监控设备延迟情况
• 利用 esxtop 或 resxtop 命令后输入 d 查看
• 检查 VMkernel 配置是否异常
o VMkernel 接口是 IP Storage 的重要接口
• 在 ESXi Host 上 ping iSCSI Target 地址
▪ 例如：ping 172.20.13.14
▪ 如果 ping 不通则可能是 IP 问题
• 检查 iSCSI HBA 卡配置是否异常
o iSCSI 的 Initiator 是 iSCSI 连接的重要接口
• iSCSI Initiator 名称
• iSCSI Target 名称、端口和地址
• CHAP
o 确认 VMkernel 与网路卡的绑定是否正确，如下图所示：
注意：在 iSCSI 存储环境中，NIC 即使做了 Teaming，同一个 VMkernel 的话同一时间只允许一个 iSCSI HBA卡处于活动状态
• 检查 iSCSI 3260 端口是否可达
o iSCSI TCP 端口 3260 可用如下命令来检查：
• 在 ESXi Host 上执行 nc 命令来查看是否可到 iSCSI Storage 的 3260 端口
▪ nc -z <Ipaddr> 3260
o 解决方案
• 确认存储运行是否正常
• 确认 iSCSI 流量没被干扰
• 检查 VMFS Datastore Metadata 一致性（建议平时多做必要的备份）
o vSphere VMFS Datastore 的 Metadata 一致性需要检查：
• 使用 vSphere On-disk Metadata Analyzer（VOMA）这个工具检查 VMFS Metadata 一致性：
▪ voma -m vmfs
• -d /vmfs/devices/disks/naa.000…0000:1
• -s /tmp/analysis.txt
o 通常出现下列情况下需要执行这个一致性检查：
• 更换过磁盘
• VMkernel.log 里报 Metadata 错误
• 在 VMFS Volume 上的文件无法给其它 ESXi Host 访问
o 当出现一致性问题时，建议执行如下动作：
• 重建 VMFS Datastore 后恢复之前的备份
• 实在不行，就找 Vendor 的 RD 了
4 、存储故障 02 - 多路径故障
• 利用如下 命令来查找关于 LUN 的路径信息：
o esxcli storage core path list
• 利用如下命令列出 LUN 的多路径配置信息
o esxcli storage nmp device list
• 检查是否需要执行 Rescan 重现 LUN
o esxcli storage core adapter rescan -A <vmhba##>
• 故障原因分析逻辑
o 如果在/var/log/vmkernel.log 文件里看到关于 permanent data loss(PDL)或 all paths down（APD）之类的信息时，可以执行如下的故障排查流程
• PDL 的触发情况（vSphere 5.5 之后几乎不会发生）
• 计划外 PDL 修复
• APD 的触发情况
o 当存储在一定时间内无法被 ESXi Host 访问时 APD 可能发生：
• 这种情况一般都是短暂的，设备会很快重新可用（存储 IO 负载过大时 vSphere 可能会触发自动保护机制，暂时让存储离线）
o 可能导致 APD 的情况有如下：
• 存储设备从 ESXi Host 的移除动作并非计划内的
• VMkernel 无法检测到存储设备导致
• IP Storage 的前提下，网路连接中断导致所有 iSCSI 路径中断
• iSCSI HBA 卡本身固件版本故障
o 在 vSphere Web Client 里显示如下信息
• 设备变成了 Dead 或 Error 状态
• 所有存储路径变成 Dead 状态
• 设备上的所有 Datastore 不可用
• VMs 无法使用
• APD 的修复方式
o 当 host 到存储的连接出现 APD 时，想要在存储阵列或区域网路里面修复，则需要所有的 ESXiHost 重启
o 在 APD 情况下无法执行 vMotion
o 针对 APD 故障，ESXi Host 提供了一些缺省组件：
• 全局设定里，找到：Misc.APDHandlingEnable
▪ 缺省为 1，表示激活存储 APD 处理机制
• Timeout 设定，找到：Misc.APDTimeout
▪ 缺省为 140，这个数据表示 APD 故障的允许时间间隔，以秒为单位
• 检查 NIC Teaming 异常
o 对于 iSCSI Storage 来说，NIC Teaming 的配置是很重要的：
• 检查 Path Selection Policy 异常
o PSP 对于多路径来说，直接影响着活动链路状态和存储传输性能
四、针对 vCenter 和 和 ESXi 的故障排查
1 、vCenter SSO 架构回顾
2 、SSO 工作逻辑
3 、SSO 的 的 MultiSite
4 、SSO 故障
故障：SSO 无法自动发现信任域
• 通常是在先安装 SSO 后加域的情况下会出出现这种情况
• 安装之后尝试用命令来恢复--在 SSO 安装目录下，找到 utils 目录，执行命令：
o ssocli configure-riat -verbose -a discover-is -u admin -p <password>
5 、vCenter 环境组件回顾
• VMware VirtualCenter Server service 和 Webservice Management 服务会随着 vCenter Server 自动启动
• vCenter 服务器与 DB 之间必须通过 ODBC 进行连接
故障一：VMware VirtualCenter Server 服务无法启动
• 在服务器管理器里查看该服务是否真的没有启动
• 查看 Windows Event 里面的相关错误提示信息
1 ） 、可能的故障排查逻辑
• 检查可能存在的相关问题，由于 OS 是正常的。因此，这个状态下仅仅可能由于 OS 内部的问题，在做排查时，应当重点关注到 vCenter Server 自身的一些问题
2 ） 、解决 ODBC 数据源配置故障问题
• 利用注册表检查 vCenter Server 使用的是哪个数据源
• 对比 ODBC 数据源设定，看看是否匹配
3 ） 、解决端口可能被占用的问题
• 在 vCenter 所在系统，执行如下命令：
o netstat -bano | more
• 如果端口被占用，则去掉冲突的服务，或者为 vCenter 配置其它端口【不推荐】
4 ） 、解决 VCMSDS 服务异常问题
•VMware VCMSDS 服务没有正常运行
o 打开 windows 的服务管理器，去看看这个 VCMSDS 服务是否正常运行
o 尝试重启这个服务，如果失败，请检查 windows 日志提示
故障二：vCenter Server 服务启动缓慢
• vCenter Server 数据库异常可能导致 vCenter Server 服务无法启动
• 检查 vCenter Server 对应的数据库配置是否满足下列要求
o 磁盘空间是否满了
o 检查 SQL 的相关信息（是否空间不足了）
o 检查 Oracle 数据库增长情况
o 检查 Oracle 或 SQL 数据表的大小
o 验证 vCenter 到数据库的授信有效性
1 ） 、解决 vCenter Server 数据库增长问题
• vCenter Server 数据库的增长会影响到 vCenter server 的性能
• vCenter Server 会收集下列数据库中的相关信息
o Performance data
o Tasks Events Logs
o Error Logs
• 大多数情况下，数据库的增长都是由于 Performance 数据库增长过快导致
2 ） 、 vCenter Server 常规增长数据表
• vCenter Server 的数据库自然包涵系列数据表，例如：
o vpx_hist_stat1 到 vpx_hist_stat4(包含 Performance 数据信息)
o vpx_sample_time1 到 vpx_sample_time4(在 vpx_hist_stat 表的相关 performance 的时间帧数据)
o vpx_event 和 vpx_event_arg(存放来自于 vCenter Server 中 Tasks and Events 页标签的 Event 数据信息)
o vpx_task(存放在 vCenter Server 中来自于 Tasks and Events 页标签的 Tasks 相关信息)
3 ） 、如何通过 Rollup Jobs 控制增长
• vpx_hist_stat1 和 vpx_sample_time1 表里的 Performance 数据会按照下面的状态进行归档：
o 汇总过去每天的 rollup 任务
o 相关任务会通过将数据插入到 vpx_hist_stat2 与 vpx_sample_time2 表来完成
•下面是不同的时间间隔的变化状态节点：
4 ） 、验证数据表尺寸
• 可以根据相关性能数据来判断 vCenter 的性能状况，可以执行如下步骤来查看性能相关的东西
o 从 vpx_hist_stat1 表开始，看看它的 size 是怎样的
o 通常可以接受的数据量在 10 million 以内，如果超过，则可能存在性能问题
• 如果觉得 Performance 数据没有问题，则请检查一下看看过去 24 小时是否存在较大数据变化的情况
5 ） 、解决由于数据增长过快导致的问题
• 确认 Statistic Rollup Jobs 的存在
• 确认 Datastore Server 的 MSQL agent 服务是否正常启动
• 确认 Statistic Collection Levels 不是设置的过高：
o 尽量让 Statistics Level 在 2 以下，VMware 不建议超过 Level2
o 如果为了做 debugging，则建议增加 Static Level，但是记得做完之后做回调操作
6 ） 、重新初始化 vCenter Server 数据库
• 可以有下列方式来重置 vCenter Server 数据库
o 重建 vCenter Server
o 找 VMware 厂家处理
o 压缩数据库
• 可以通过下列方式重置 vCenter 数据库配置
o 在 vCenter 服务器上，执行如下命令
• vpxd.exe -b C:\Program Files\Vmware\Infrastructure\VirtualCenter
6 、ESXi 故障
故障一：ESXi Server 崩溃，出现紫屏的情况
• 主机 crash 会导致 PSOD 的出现
• 下列是几种典型的紫屏情况
o CPU exception
o Driver 或 module panic
o Machine check exception(MCE)
o Hardware fault
o 正版软件检测机制
PSOD 解决思路
• 记录下当前系统状态
o 将 PSOD 拍下来
o 记录下当时的相关故障场景
• 重启 ESXi Host
o 让 vm 能够正常启动
o 利用 vm-support 命令来收集主机上的故障包信息
• 联系 VMware 的技术支持力量
故障二：ESXi Host Hang 住
• ESXi host 可能由于下列问题 Hang 住
o 整个系统无响应
o 系统再重启后可能没能恢复正常
• 下面几种情况是 ESXi Host Hang 住的常见原因
o VMkernel 繁忙或者 deadlocked
o 硬件层面故障
1 ） 、验证 ESXi 是否 Hang 住
• 确认是否能做下列操作
o Ping VMkerenl
o 确认是否可以用 vSphere Client 去查询界面
o 监控 ESXi Host 与 VMs 之间是否有网路通讯
• 如果上述操作都能成功，则 ESXi Host 没有 hang 机
2 ） 、解决 ESXi Server Hang 掉的问题
• 重启 ESXi Server
• 通过下列确认为何会出现 hang 机情况
o 看日志
o 收集性能统计信息
• 如果是硬件故障，则在解决之后，尝试重装下 ESXi Host 或打个新补丁
五、常用的故障排查工具箱
1 、命令行工具介绍
• vSphere 支持的命令行工具很多，其中，可以用于排错的核心工具包括：
o DCUI 下的 ESXi Shell
o vSphere Management Asisstant(vMA)--基于网络
o vSphere Command Line Interface(vCLI)--基于网络
o ESXTOP（排错、监控、性能优化）
• ESXi Shell
o ESXi Shell 的访问途径有两种
• DCUI
• SSH
o SSH 访问 ESXi Shell 的方式
• 激活 ssh 访问服务
• 利用 Putty 之类的工具访问
• vMA
o vMA 是一个包含了下列内容的 Virtual Appliance
• vCLI 命令行
▪ 可以用这个命令行工具执行下面的命令管理 ESXi Host
• esxcli
• vim-cmd
• Vicfg-*
▪ 运行时，先执行命令连接到服务器
• vi-fastpass 授信组件
▪ 支持针对 vCenter Server 和 ESXi target 的授信
▪ 不用每次执行命令都需要输入权限信息
▪ 支持运行批处理脚本信息
o vMA 配置 Active Directory 授信
• 如果 ESXi Hosts 和 vCenter Server 加入了域，则可以通过 vMA 统一管理
▪ vMA 可以将 target 添加进来
▪ 相对而言，从安全角度而论 vi-fastpass 不如这个
• 为 vMA 配置 AD 前，建议做下列事情
▪ 确认 vMA 与 DNS 服务器在同一台 os
▪ 确认 vMA 可以访问 Domain
▪ 确认 IP 与 DNS 的解析无误
o 添加 vMA 到 AD
• 将 vMA 添加到 AD Doamin
▪ sudo domainjoin-cli join <domain-name> <domain-admin-user> -->> 输入 AD 管理密码 -->> 重启 vMA
• 检查 vMA 配置的 Domain 设定
▪ sudo domainjoin-cli query
• 为 AD 授信添加 target
▪ vifp addserver <FQDN of Server> --authpolicy adauth --username
ADDOMAIN\\<userID>
• 从 Doamin 删除掉 vMA
▪ sudo domainjoin-cli leave
• esxcli 命令介绍
o vSphere Storage 信息
• esxcli storage
▪ 可以获取存储多路径配置、LUN 信息和 Datastore 的相关设定
o esxcli network
• 可以查看网路相关的设定
o esxcli network vswitch standard
• 查看 vSS 的设定信息
o esxcli network vswith dvs
• 可以查看 vds 相关的信息，但不能用这条命令创建修改 vDS
o esxcli hardware
o vim-cmd -- 主要用于操作 ESXi Host、vCenter、虚拟机等信息
• 操作虚拟机
• 操作 ESXi Host
• 操作 vCenter
2 、vCenter Server 日志信息
• vCenter Server 包含了系列日志信息
• Windows 2003 的日志存放位置
o C:\Documents and Setting\All Users\Application Data\VMware VirtualCenter\Logs
• Windows 2008 的日志存放位置
o C:\ProgramData\VMware\VMware VirtualCenter\Logs
3 、ESXi Host 日志位置 -- /var/log
4 、vCenter Server 核心日志列表
5 、ESXi Host 日志清单
6 、vSphere Web Client 中的 Log Browser
7 、ESXi Host 的 DCUI 界面日志查看器
8 、vSphere Syslog Collector
9 、诊断数据收集之 vm-support
• 可以利用 vm-support 命令来收集诊断数据，发送给 VMware 技术支持部门进行故障排查
• 总体需要收集的信息如下
o Log files
o System status
o Configuration files
• vm-support 可以在 esxi host 上执行，然后收集相关的 Core 信息，收集到的信息格式为 xxxxxx-2016-08-21--.tgz
10 、vSphere Web Client 日志导出
由社区会员分享，点击阅读原文可下载原文档
觉得本文有用，请转发或点击“在看”，让更多同行看到
推荐资料：
VMware vSphere 服务器虚拟化部署安装图解 | 资料
下载 twt 社区客户端 APP
与更多同行在一起
高手随时解答你的疑难问题
轻松订阅各领域技术主题
浏览下载最新文章资料
长按识别二维码即可下载
或到应用商店搜索“twt”
*本公众号所发布内容仅代表作者观点，不代表社区立场