vSphere 7 新功能全接触

vSphere 7 已于3月11日正式发布了，这个是我们期待已久的一个vSphere的版本，vSphere 7 会带来哪些新的更新呢？因为之前都已经听说，vSphere 7 是一个重构的基础架构的软件版本。搜寻到相关材料，我们来看看vSphere7 到全部更新，先给张全景图，没图没真相（内容个人翻译，非官方翻译，不保证翻译准确）

看来vSphere 7 是的更新主要从四个方面进行的，包括宣传已久的vSphere with Kubernetes（project Pacific），生命周期管理，内生安全和应用加速。

那么我们一个一个来看！

vSphere with Kubernetes （之前项目名为Pacific）

vSphere with Kubernetes是和vSphere 7 一同发布的，在看Pacific之前不得不提VMware的Tanzu，Tanzu是一个的从构建, 到运行, 到管理的完整的组件。

因为在之前的市场活动中已经有太多的关于Tanzu的剧透，这里就按下Tanzu Mission Control，Bitnami和Pivtal部分不表，先说vSphere with Kubernets。

企业应用是个不断演化的过程，从大小机，一个厂商包揽，到软硬件解藕，到三层架构，到容器类应用，到云原生应用。整个过程中多种应用形态（VM，容器，K8S）混合将持续很长时间，特别是现在虚拟化已经非常成熟的情况下，如何在此基础上构建云原生类应用，IT admin可以通过专注于管理应用程序而不是管理VM来实现大规模控制。开发人员和操作员通过熟悉的工具（用于操作员的vSphere工具和用于开发人员的Kubernetes服务）协作以提高速度。这就是vSphere with Kubernetes解决的问题

这样两种应用类型运行在一个平台上，解决了：

• K8s平台手工去构建的繁琐，没办法保证可维护性和可扩展性，vSphere 7 上只需打开启动按钮
• 各种应用形态运行在各自孤立的资源池里，资源平台无法共享
• 不同的技能，工具和运维团队，或者IT管理员需要运维管理多套基础架构资源

vSphere 7 中不仅解决Kubernetes的问题，还用Kubernetes重构的vSphere的平台

1. 虚拟机资源也支持声明式交付，简化开发人员的流程成本，Yaml的方式同时交付虚拟机和容器类应用
2. 以应用(Namespace)为单位的方式对资源的管控，包括服务质量，安全性，可用性，访问控制，在应用程序级别和容器上继承vSphere功能（HA, vMotion, DRS），保证业务的连续性，并且在vCenter中的Kubernetes群集，容器和现有VM的统一可见性
3. IT管理员可以快速把开源社区的服务变成自己公司开发人员的service来交付，开发人员用yaml声明式去申请服务（HANAN，Oracle DB等）, 使得vSphere真正成为一个兼顾所有应用模式的平台，通过vSphere中的Kubernetes构造在开发人员和操作人员之间保持一致的视图

另外可能有同学关心性能的问题，根据VMware官方实验室给出的数据，运行在VMware原生Pod（也就是vSphere Pod）比运行在Linux下性能要高8%，比跑在VM里的Pod性能要好30%，版本出来后大伙可以验证一下。

VMware vSphere7 with Kubernetes可能也是目前是目前唯一可以统一的、声明式的交付应用（容器）和基础设施（虚机、存储等）的企业软件平台。

Management

vCenter配置文件

在新版本vSphere 7的vCenter支持配置文件的导入导出，包括管理信息，网络信息，认证信息，可以采用DCLI， PowerCLI或者Ansible，Puppet，Chef等利用vSphere提供的4个API：list, Export, Validate, Import 对配置文件（Json格式）进行操作，这样简化了我们备份vCenter的数据量和效率。可以对导出的配置文件进行修改，也可以在导入新的vCenter之前可以在新vCenter进行验证

内容库

在vSphere 7 中对content Library的功能也进行了更新，首先你可以采用check out模版排他性操作对VM进行更新，但同时也不会影响到现有的模板部署。也可以使用check in将VM转换成模版，并创建新模版版本，也可以利用versioning进行回溯。

vCenter Server Multi-homing& Scalability

vCenter Server7 支持multi-homing (多网卡) 配置. 并且NIC 1保留给 vCenter HA (VCHA). 最多支持4个NIC 。

vCenter的扩展能力也有很大增强

详细见下表，不赘述

vCenter Server CLI Tools

CMSSO-UTIL: 简化对vCenter SSO的配置，包含两个子命令unregister 和 domain-repoint

VCSA-DEPLOY：支持对vCenter进行Install, Upgrade和Migrate

vSphere Lifecycle Manager

Cluster Image管理

vSphereLifecycle Manager采用了新的EXSI生命周期管理模式：Cluster Image

一个Cluster Image可以由vSphere的发行版本+硬件厂商的附加组件，包括固件，驱动等（目前看情况支持的厂商为Dell和HPE），对某个集群升级的时候可以先行进行兼容性验证，减少因为兼容性问题导致的风险。但估计要求是一个集群的host必须是一个model

Hardware Management

使用LifecycleManager可以轻松检查和升级主机的固件。可以与受支持的供应商管理工具（如Dell Openmanage和HPE Oneview）进行交互。自动检查HCL，以确保客户正在为其驱动程序和固件运行推荐的固件版本。

同时提供完整的RESTAPI接口可用。

vCenter SSO

vSphere 7摒弃了外置的PSC，vsphere6.7和以前的版本如果为外部多PSC时需要借助外部的Load balancer，Embedded之后不再需要load balancer，部署变得简单。老版本在升级到vSphere 7时也会将原本外部的PSC变成内置，也不建议部署基于windows vCenter

vCenter Update Planner

vCenter UpdatePlanner可以进行pre-update check以避免升级过程中导致的问题

vCenter ServerUpdate Planner可以帮助规划和升级客户环境。可以在vSphere Client中直接获得接收到想要升级的通知。可以根据数据中心中运行的当前版本或vCenter Server监视VMware产品的互操作性，从而简化了升级工作流程。可用的预检查有助于版本兼容性，然后再开始升级。

Resource Management

Improved DistributedResource Scheduler (DRS)

2006年发布了分布式资源调度（DRS）的第一版。数据中心和工作负载发生了重大变化。vSphere DRS过去一直专注于群集状态，检查是否需要重新平衡，因为可能会发生一台ESXi主机消耗过多而另一台ESXi主机消耗较少资源的情况。如果DRS逻辑确定可以改善群集平衡，它将根据已配置的设置建议并执行vMotion。这样，DRS便通过使用群集范围的标准偏差模型来实现群集平衡。

新应用程序具有不同的特性，需要更改DRS以支持不断变化的应用程序格局。随着vSphere 7的发布，引入了新的DRS逻辑以及新的UI。与先前版本的vSphere一样，新的和改进的DRS逻辑更加以工作负载为中心，而不是以群集为中心。DRS被完全重写，以具有更细粒度的资源调度级别，主要侧重于工作负载。让我们更详细地介绍新的DRS算法，并了解如何解释新UI中的指标。

新的DRS逻辑采用了非常不同的方法。它计算主机上的VM DRS分数，改进的DRS逻辑通过使用VM DRS分数来量化虚拟机的满意度。并将VM移动到提供最高VM DRS分数的主机。与旧版DRS的最大区别在于，它不再平衡主机负载。这意味着DRS不太关心ESXi主机利用率基准。现在，我们通过关注我们最关心的指标（虚拟机的幸福感）来改善集群上的工作负载平衡。VM Score值大的容易被迁移

VM DRS Score因素：

• CPU就绪时间百分比
• 良好的CPU缓存行为
• 内存交换
• 主机上突发资源可消耗空间
• VM的迁移（vMotion）成本

需要注意的重要一点是，改进的DRS现在每1分钟运行一次，从而提供了一种更细粒度的方法来计算工作负载平衡。这样可以总体上提高工作负载的性能。

另外在Improved DRS里面有一个Scalable Shares，在Cluster和Pool级别启用，优先保证“high”level的虚拟机资源，这个就不多讲，容易理解。除vSphere with Kubernetes之外默认是不开启该功能

vMotion优化

其实就是为了解决Monster VM的vMotion问题，或者说单位时间内存变化量比较大的虚拟机的vMotion问题，像SAP HANA 或者 Oracle

首先来看一下vMotion的流程

1. 在目标主机创建VM
2. 内存预复制阶段，将VM使用的所有内存页面复制到目标位置
3. 源虚拟机已挂起
4. 内存的最后几位和设备状态（即VM正在使用哪些内存页面）被传输到目标
5. 恢复目标虚拟机，指向vMotion复制的内存页。
6. 源虚拟机被清理，删除

这里的关键要点是，切换时间（也称为“眩晕时间”）保持在1秒以内。我们完全有能力针对“普通”或“较小”的虚拟机执行此操作，但是随着工作负载的增长，这成为一个挑战。其实就是内存大量变化时持续迭代内存拷贝的效率问题，拷贝效率越高，变化量就会越小，最终达到拷贝完成

第一，我们希望在原主机上的虚拟机在未迁移成功之前，功能不受影响

为了在vMotion期间跟踪所有变化的页面，我们在为VM配置的所有vCPU上安装了所谓的“Page Tracer”。所以所有vCPU都以随机顺序停止（微秒级别），以便能够安装页面跟踪程序。

然后每当vCPU写内存页面时（由于“Page Table Entry”（PTE）设置为只读），它也会引入一些小停顿以确保我们复制内存页面到目标ESXi主机。在所有PTE都设置为只读之后，将指示vCPU刷新转换后备缓冲区（TLB），以确保该层中没有“缓存”内存页。

由于VM的大小大约小于8个vCPU，因此vMotion期间的性能从来都不是什么大问题。但是随着更大的VM的使用，性能影响变得非常明显。我们需要重新架构安装页面跟踪程序的方式以及如何处理页面触发。

在vSphere 7中，我们声明一个vCPU可以完成所有页面的安装和页面触发（内存页面变化），而不是在为VM配置的所有vCPU上执行此操作。使用此方法的效率要高得多，工作负载可以继续使用vCPU，而不会受到干扰。一个vCPU将负责将全局内存中的所有页面表条目（PTE）设置为只读，并处理页面跟踪程序安装程序和页面触发。最后，所有vCPU仍需要刷新转换后备缓冲区（TLB），但是现在可以在不同的时间进行以减少对性能的影响。

第二，改进传输bitmap的方式，不发送整个位图，而是仅发送需要发送的页面。这是因为VM的最大部分已将其内存复制到目标主机。因此，我们压缩位图，仅提取相关的内存页号并进行传输。

对于大型VM，该示例是针对将来已准备好vMotion的24TB内存的VM大小调整，这意味着我们将传输位图所需的秒数缩短为几毫秒。这样一来，总切换时间也减少到了亚秒级，但这仍然很大程度上取决于工作负载的特性。

Assignable Hardware

新的DynamicDirectPath I/O和NVIDIA vGPU均使用可分配硬件框架。动态DirectPath I/O是配置直通以将PCIe设备直接暴露给VM的新方法。PCIe的硬件地址不再直接映射到虚拟机的配置（vmx）文件，而是向VM提供了PCIe设备能力。例如，VM需要型号为V100的GPU。可分配的硬件将不会与DRS进行交互，以查找具有此类设备可用的ESXi主机。它将声明该设备并将VM注册到该主机。当VM启用vGPU时，DRS能够查找具有相同GPU配置文件的ESXi主机。

由于PCIe设备的这种抽象，vSphere 7能够使用DRS对启用了DynamicDirectPath I / O的VM进行初始放置。这也意味着支持vSphere HA，从而提高了工作负载可用性，因为如果ESXi主机出现故障，则vSphere HA和DRS将尝试在群集中尚存的ESXi主机上查找类似的设备。这取决于群集中的设备可用性。

要使用可分配的硬件，VM必须在VM硬件版本17上运行。添加PCIe设备后，将为用户提供（动态）DirectPath I/O设备或NVIDIA vGPU配置文件的选项。具有可分配硬件的DRS将使用所选的PCIe设备或vGPU配置文件在群集中进行初始放置。

Application Acceleration

我们在解藕了计算资源，存储资源，网络资源后，新的应用场景，例如大数据，AI，ML需要新的算力技术，比如GPU。在vSphere 7之前或者说在目前市场上的AI/ML算力解决方案中都是将GPU的算力和CPU算力同时绑定在一台主机上，应用进行vMotion首先需要考虑目标节点是否同时满足GPU算力和CPU算力，也就是在目标主机上必须有x86 CPU和 GPU卡，并且有足够的资源满足需求，另外大家也知道Nvidia的GPU的切分力度也是比较固定的，没办法做到灵活切分

在目前采用在vSphere 7之前平台对于GPU用于AI/ML的处理方式如下图

导致GPU资源池变得孤立，所以，

1. 某些团队GPU资源负载超负荷运行
2. 某些团队富裕的GPU资源无法共享
3. 生成环境GPU资源长时间处于闲置状态

vSphere 7集成了VMware前期收购的Bitfusion，解决方案是将GPU/FPGA等AI/ML资源池化置于计算资源后端，计算资源需要AI相关算力时，通过网络灵活可力度调度后端AI算力资源

基于vSphere针对机器学习和AI工作负载优化

整合和共享硬件加速器

轻松确定未充分利用的孤立且昂贵的资源。不论位置如何，都可以远程（全部或部分）共享硬件加速器。GPU资源的切分也变得灵活

现在和将来扩展

在整个基础架构中利用GPU，并使用同一基础架构集成不断发展的技术，例如FPGA和定制ASIC。

Security

Simplified CertificateManagement

关注合规性的客户对证书比较关注。在vSphere 6.7和更早版本中，我们需要管理大量证书，包括组件与组件之间，甚至进程与进程之间，这对于在vCenter Server中的VMware证书颁发机构之外管理证书的客户来说是一个问题。在vCenter Server和ESXi级别重新发行和替换所有组件可能会变得很复杂。

vSphere 7使用通用证书，而不是每个进程都有自己的证书。这样降低了复杂性，可以轻松地在安全性和合规性方面做正确的事。

Identity Federation

vCenter Server能够与Active Directory和LDAP目录进行交互已有很长时间了。作为vSphere Single Sign-On（SSO）的一部分，它也有自己的目录。我们可以提高安全性的最大方法之一是通过良好的密码策略，而最简单的方法之一就是实施多因素身份验证。但是问题在于实现MFA的方法太多了，我们几乎不可能用所有这些方法扩展vCenter Server。

所以解决方案是使用开放式身份验证和授权标准（例如OAUTH2和OIDC）的联盟。让vCenterServer与企业标识提供者进行对话，并使vSphere Admins和vCenter Server脱离此过程。这简化了vSphere Admin的工作，并缩小了审核范围。它还为许多不同的多因素身份验证方法打开了大门，因为IT管理员已经知道如何插入Active Directory联合身份验证服务或ADFS之类的东西。

vSphere 7将开箱支持ADFS。兼容多种IDP规则，例如 Active Directory，Ping，Okta，vIDM等不同方式。这样使得vCenter和IDP连接变得相对容易。当然所有旧式身份验证选项仍然存在。

vSphere Trust Authority

国内对KMS这种加密的需求并不多，可能也只有很少部分企业才用到，但我们还是做一个介绍。具有受信任的平台模块并启用了安全启动的主机可以记录有关启动过程和配置的指标，并将其报告给vCenter Server，以验证这些指标是否符合预期和期望。这是一个称为证明的过程。

如上图左部分，vSphere 6.7中采用的加密方式有些缺陷，主要是授信是在vCenter VM上完成并且加密密钥保持在vCenter VM上，也办法保证vCenter所以在host是否处于授信状态，另外因为dependency loop的问题vCenter没办法加密vCenter

在vSphere 7中创建单独的硬件根信任的ESXi集群，这些主机将承担认证任务，并将成为验证其他群集以确保这些系统满足信任要求的主机，受信任的主机也接管与关键管理器的通信。这简化了与KMS的连接和风险审计。其他非加密认证启动的主机将无法运行加密的VM， 这样vCenter Server也可以进行加密和保护

但是需要知道的是服务器需要Trusted Platform Module芯片的支持

vSGX/Secure Enclaves

英特尔软件防护扩展（SGX）允许应用程序与硬件一起使用，以创建GustOS或hypervisor无法查看的安全飞地。用来将敏感的逻辑和存储移入该区域。
（仅限英特尔，AMD具有SEV）

至此，vSphere 7 的全部内容有来大致的了解，正式版本会在3月底或者4月初Release，想进一步了解vSphere 7，快去下载Beta版本试用吧！