如何为虚拟机分配CPU

       很多时候最基本的东西往往是最难的，所以今天这个话题并不容易；如果没有耐心，前面的部分有些烧脑，可以直接跳到到后面的“配置准则”。

        首先要做些概念的准备，作为类似汽车发烧友谈燃油车的时候，不去弄清楚气缸，火花塞这些，就无法说下去。

 NUMA
英文是non-uniform memory access，简单说就是在多个SOCKET（物理CPU）的系统中，访问自己的内存比访问别人的内存会快得多，如下面这个双CPU的系统，从CPU0去访问CPU1管理的内存中的信息（REMOTE ACCESS），需要更多的环节，比访问CPU0管理的内存(LOCAL ACCESS)时间要长很多；还有个问题CPU间的通信带宽也是有限的，除了内存访问，PCIe IO的数据也常常要通过CPU间的连接通信，因为PCIe设备总是隶属于某个CPU，比如某个万兆网卡，可能连接在CPU0上，而CPU1上的虚拟机需要这个网卡的的数据，也势必需要占用CPU之间的通信带宽；当数据的流量大于CPU间的带宽的时候，就会导致拥堵；延伸多说一句，很多厂商为了节约成本，往往在配置服务器时，就只为一个CPU配置PCIe的背板，导致全部的IO都在这个CPU上，这样做会导致IO的一些计算集中于一个CPU，而且IO的数据很多要通过CPU间的连接，对于esxi这种虚拟化这种不是很合适

NUMA节点
就是一个 SOCKET的物理核，缓存，内存，PCIe资源

vCPU
分配给虚拟机的CPU叫vCPU，其对应于SOCKET的线程（也叫逻辑核，数量是物理核的两倍，因为默认是启用超线程）

vNUMA
是esxi向虚拟机呈现的NUMA架构，告诉虚拟机OS现在你在使用的NUMA结构，vNUMA的结构和真实的物理资源可以是不一致的，当然这样会导致虚拟机的OS误解了资源，虚拟机性能受损

胖虚拟机（英文叫wide vm，这个词算我的发明，引用需要备注出处)
就是如果一个虚拟机无论是vCPU数量超过了一个NUMA节点的逻辑核，或者是内存超过一个NUMA节点的内存，简单说就是虚机的尺寸大于一个NUMA节点；当然与之相反，可以容纳在一个NUMA节点内的虚拟机被称为“廋虚拟机”

        VMware 在这方面，从vSphere 6.5开始做了一个简化，沿用至今，我相信大多数客户现在都应该使用6.5以上的版本；当采用的是默认配置，每个插槽内核数为1时，只要配置的不是一个胖虚拟机，esxi都会让虚拟机在一个NUMA节点中运行；如下图中，我们在配置虚拟机的vCPU资源时，看到的默认配置

        对于现代的服务器CPU，一般而言，esxi更关心“每个插槽内核数”和插槽数二者的乘积，就是总的vCPU，并不一定会按虚拟机的配置，呈现你希望的NUMA结构；比如2路服务器，每个CPU有20个线程，配置一个12vCPU的虚拟机，虚拟机配置为6个插槽，每个插槽内核数为2，esxi并不会按这个配置，配置出一个6个vNUMA节点的虚拟机，而是会按物理服务器的NUMA架构，配置为一个1个插槽，每个插槽内核数为12的虚拟机；其会按照总的vCPU个数和内存的配置，只要不超过一个NUMA节点，就会尽量让虚拟机运行在一个NUMA节点中，也不会启用vNUMA；当虚拟机是胖虚拟机，esxi选择尽量少的NUMA节点，并向OS映射物理资源，也就是vNUMA，由于现代的OS和大型应用，绝大多数都对NUMA架构进行了优化，可以很好的配合vNUMA架构，保证应用的性能不受影响。

        下面往更深处来讨论，虚拟机如果还是廋虚拟机，是否启用vNUMA,可以参考
https://frankdenneman.nl/2016/12/12/decoupling-cores-per-socket-virtual-numa-topology-vsphere-6-5/

    根据这篇文章，esxi会为每个虚拟机计算出一个：numa.autosize.vcpu.maxPerVirtualNode，参考这个数值后，才会决定出VPD的SIZE，从而决定是否为廋虚拟机启用vNUMA，以及这个vNUMA的插槽数及核数，现在我还不知道esxi是如何计算出这个数值。

        这时esxi才有可能按廋虚拟的插槽及核数配置，当然也可能启用了vNUMA，但不是按虚拟机的配置；所以如果你不按默认每个插槽内核数为1配置，你最好在配置完成的虚拟机上，确认下当前虚拟机的NUMA结构；如果在linux上可以用命令numactl -H 或者numastat，window的系统可以采用微软的工具coreinfo来检查虚拟机的NUMA架构。

        这种非默认的配置，可能会导致vNUMA的架构和底层的硬件不一致，比如我曾经在一个2路20核的服务器，配置24vCPU的虚拟机时，配置出了3个SOCKT的vNUMA:

        这样的虚拟机，从其OS看，它认为自己跑在3个SOCKET上，每个SOCKET上有8个核的系统，这个和底层的物理资源完全不匹配，所以性能会受到影响。

配置准则

1.配置虚拟机CPU时，无特殊情况，需要按默认的每个插槽内核数为1的默认配置来配置。

2.当配置虚拟机的CPU和内存的时候，如果可能，尽量不要配置胖虚拟机，这样虚拟机会在一个NUMA节点内获得资源，性能最优。

3.如果需要配置胖虚拟机，也要考虑NUMA节点的大小，尽量少的NUMA节点。

4.由于某种原因，比如软件许可，如果想不按默认的“每个插槽内核数为1”配置，也需要参考服务器CPU的插槽数来配置，尽量少配置插槽数，配置完成后，还需要在虚拟机OS中检查。

5.如果配置CPU热添加，要注意，如果虚拟机在启动的时候，不是胖虚拟机，虚拟机也不会启用vNUMA，当你进行热添加，虚拟机可能变成胖虚拟机，这时底层的物理资源已经需要来自2个以上的NUMA节点，但虚拟机并不会启用vNUMA，不会映射实际的NUMA物理资源，因为是否启用vNUMA，是在虚拟机启动的时候决定，这样会导致应用不知道底层的资源来自NUMA架构，应用认为资源还是来自一个NUMA节点，应用的性能会受损，所以在使用热添加的时候，由廋变胖要考虑到这点。

6.要留意很多OS及其不同的版本有CPU资源的限制，多配置的vCPU并不能被OS识别，造成浪费。

7.现在明白了为什么在一个集群中，尽量采用一致的服务器配置，因为虚拟机原来不是胖虚拟机，迁移到另外一个资源少的主机上，就变成了胖虚拟机；虚拟机启动后，其vNUMA的架构就不再改变了，如果迁移到另外一个物理机，底层的结构不同，比如从2路服务器，迁移到1路服务器，这就会导致其虚拟的vNUMA和物理机的NUMA结构不一致。

        总结下就是配置虚拟机CPU的时候，采用默认参数大多数情况都会是最优的配置，不要随意地修改“每个插槽内核数”和插槽数，在采用CPU或内存热添加的时候要明白所付出的性能代价。

        最后再从虚拟平台管理员的角度，说说如何对付"贪得无厌"的应用管理员。

        由于往往是屁股决定脑袋，应用管理员只对自己的应用负责，所以最大化地为自己的应用配置资源，最符合其利益，所以一般应用的需求都是超过其实际负荷，而且确实很多业务在上线前，大家也都没谱，多数都是往大了配，面对这样的情形，我建议虚拟平台管理员应该这样处理：

1. 在刚刚上线时，原则上接受应用管理员的要求，按应用要求配置虚拟机资源。

2. 通过vCenter监控或者其他监控软件，监控这些业务的消耗，一般2-3个月就可以看出资源配置是否合理，向应用提出资源变更的建议；VMware的Operation中就有这样的报表。

3. 由于这时你拿出了证据，就比较容易和应用管理员协商而达成一致，然后找适当的时间进行调整

        由于各种条件的变化，这种调整可能不是一个循环就可以完成，可能需要多个循环，经过2-3个这样的循环，就应该可以将资源调整合适；为虚拟配置正确的资源，是提升虚拟平台效率的关键！

         资源配置是虚拟化管理员最重要的工作，但我很少见到有人可以高效主动地对资源进行管理，希望本篇能对大家有所帮助。

如果您觉得有用，请点赞，分享和关注；合作联系电话：13503069419，加微信，请注明vExpert。

原文始发于微信公众号（vExpert）：如何为虚拟机分配CPU