vSphere 性能优化方法总结

vSphere 性能优化逻辑

针对 VM 的性能优化

针对 CPU 的性能优化

针对 RAM 的性能优化

针对 DISK 的性能优化

针对 Networking 的性能优化

一、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 之间表现出明显的数据共享时，则依托缓存分布的方式将会是退而求其次的负载分布方式

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

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

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 字节

▪ 接收端自行重组相关数据

•JumboFrames 的特征如下：

▪ 支持更大的以太网包，最大为 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 性能