织梦做网站要多长时间,绿色建筑网站,网站做编辑器,快速建站实例演示完整版1. 方案背景
1.1. KubeVirt介绍
随着云计算和容器技术的飞速发展#xff0c;Kubernetes已成为业界公认的容器编排标准#xff0c;为用户提供了强大、灵活且可扩展的平台来部署和管理各类应用。然而#xff0c;在企业的实际应用中#xff0c;仍有许多传统应用或遗留系统难…1. 方案背景
1.1. KubeVirt介绍
随着云计算和容器技术的飞速发展Kubernetes已成为业界公认的容器编排标准为用户提供了强大、灵活且可扩展的平台来部署和管理各类应用。然而在企业的实际应用中仍有许多传统应用或遗留系统难以直接容器化通常采用传统的虚拟化技术来支撑。因此企业需要同时运行容器和虚拟机的混合云或私有云环境以便开发者和运维人员方便地管理和维护这两种类型的工作负载这促使了KubeVirt项目的诞生。
KubeVirt是一个开源项目由Red Hat、IBM、Google、Intel和SUSE等多家公司共同推动和贡献。该项目旨在通过Kubernetes来管理和运行虚拟机VMs使虚拟机能够像容器一样被部署和消费。KubeVirt扩展了Kubernetes的API增加了VirtualMachine和VirtualMachineInstance等自定义资源定义CRDs允许用户通过YAML文件或kubectl命令来管理虚拟机极大简化了虚拟机的创建、更新、删除和查询过程。
KubeVirt 的价值主要体现在统一的资源管理使得 Kubernetes 能够同时管理容器和虚拟机为用户提供统一的资源管理界面。这消除了容器和虚拟机之间的管理界限提高了资源管理的灵活性和效率为用户提供了更多的选择确保了应用的完整性和性能促进了传统应用的现代化和云原生转型。
1.2. 问题与挑战
KubeVirt在提供虚拟机实例的部署和管理能力时会面临着诸多网络和存储方面的问题与挑战。 如上图所示构建KubeVirt虚拟机环境需要先启动一个Pod在Pod中构建虚拟机的运行环境。
在无DPU/SmartNIC的场景下Pod通过Kubernetes CNI创建的veth pair连接网络 虚拟机为了对接CNI接入Pod中的网卡eth0-nic传统的虚拟机环境是需要创建网桥设备k6t-eth0网卡eth0-nic连接到网桥设备然后再创建TAP设备tap0TAP设备tap0的一端连接到网桥设备另外一端连接虚拟机这样虚拟机网络打通了与主机上OVS的网络连接。在上图中可以看到虚拟机的网络路径为ovs -- vethxxx -- eth0-nic -- k6t-eth0 -- tap0 -- eth0。
此外Pod的存储是通过Kubernetes CSI挂载到主机上云盘设备传统网络存储都是基于TCP的iscsi/rbd/nvmeof-tcp提供的远端存储在KubeVirt虚拟机环境中远端存储被CSI挂载到Pod中直接被虚拟机使用。
如上所述在KubeVirt虚拟机环境中网络和存储的配置面临着一系列问题与挑战
1、网络路径复杂且冗长
在无DPU/SmartNIC的场景下虚拟机网络路径包含了多个虚拟设备如veth pair、网桥、TAP设备等这使得网络路径复杂且冗长这种长路径不仅增加了数据包处理的复杂度提升了运维排障难度还可能导致更高的延迟和性能瓶颈。
2、资源消耗高
路径中过多的网络虚拟设备需要CPU和内存资源来处理数据包的转发和路由。这些资源消耗在高负载场景下尤为显著可能导致宿主机资源紧张整体资源利用率低。
3、网络性能低下
由于网络路径复杂和资源消耗高虚拟机的网络性能往往受到限制在高吞吐量或低延迟要求的应用场景中这种性能问题尤为明显。
4、基于TCP的远端存储存在性能瓶颈
使用iSCSI、RBDCeph RBD或NVMe-oFTCP模式等基于TCP的远端存储方案时数据需要经过网络协议栈的处理这增加了CPU的负担并可能导致较高的延迟这些存储协议没有硬件加速的支持因此在高I/O需求下性能表现不佳。
2. 方案介绍
2.1. 整体方案架构
为了应对KubeVirt虚拟机在网络与存储方面所遭遇的问题与挑战本方案创造性地集成了DPU数据处理单元硬件以下将详细阐述基于DPU卸载加速技术的KubeVirt虚拟机网络及存储解决方案的架构。 如上图所示基于DPU改造后后网络和存储都是从DPU卡接入的DPU硬件支持数据包的高速处理和RDMA远程直接内存访问技术提供对网络和存储的硬件加速能力。同时DPU集成了CPU核心能够将OVS控制面卸载到DPU中从而减少Host节点CPU的负载。为了把DPU接入K8S平台需要使用基于DPU的CNI和CSI用于对接DPU的网络和存储功能。
cni-controller该组件执行kubernetes内资源到ovn资源的翻译工作是SDN系统的控制平面也相当于ovn的cms云管理系统。其监听所有和网络相关资源的事件并根据资源变化情况更新ovn内的逻辑网络。cni-node为虚拟机提供虚拟网卡配置功能调用 ovs 进行配置。csi-controller用于创建volume和nvmeof target针对pvc调用第三方的controller创建卷创建快照和扩容等。csi-node为虚拟机所在容器提供云盘挂载功能最终通过spdk 进行配置spdk 通过 pcie 给虚拟机所在容器模拟磁盘。
2.2. 方案描述
2.2.1. 核心资源 KubeVirt的核心资源主要是虚拟机资源围绕虚拟机生命周期管理定义了其他的CRD资源包括
virtualmachinesvm: 该结果为集群内的VirtualMachineInstance提供管理功能例如开机、关机、重启虚拟机确保虚拟机实例的启动状态与虚拟机实例是1:1的关系类似与spec.replica为1的StatefulSet。Virtualmachineinstances(vmi)VMI类似于kubernetes Pod是管理虚拟机的最小资源。一个VirtualMachineInstance对象即表示一台正在运行的虚拟机实例包含一个虚拟机所需要的各种配置。
2.2.2. 网络 KubeVirt以multus(OVS)sriov的网络接入方式使用DPU虚拟机网络的接入定义需要分成2部分:
节点的基础网络如何接入pod中。pod中的网络如何接入虚拟机中。
2.2.2.1. 网络控制面 如上图所示将master节点dpu卡Host都作为node加入k8s集群这些node上运行着DPU CNI的相关组件下面分别进行介绍
ovn和ovs为转发面核心组件共同提供SDN软件定义网络能力其中ovn负责网络逻辑层面的管理和抽象而ovs则负责实际数据包的转发和处理。cni-controller该组件执行kubernetes内资源到ovn资源的翻译工作是SDN系统的控制平面也相当于ovn的cms云管理系统。其监听所有和网络相关资源的事件并根据资源变化情况更新ovn内的逻辑网络。cni-bin一个二进制程序作为kubelet和cni-node之间的交互工具将相应的CNI请求发给cni-node执行。cni-node该组件作为一个DaemonSet运行在每个节点上实现CNI接口并监听api-server配置本地网络其会根据工作模式做相应的网络配置工作模式有以下几种
1Default模式 cni-node的默认工作模式master和带SmartNic卡的Host节点中的cni-node均工作于此模式。在该模式下会对安置在其上的容器配置完整的虚拟网络配置如容器网络和ovs网络。
2DPU模式DPU节点中的cni-node工作于此模式。在该模式下会对安置在DPU内的容器配置完成的虚拟网络配置。而对安置在其Host的容器会配置ovs网络。
3Host模式带DPU卡的Host节点中的cni-node工作于此模式。在该模式下只会去配置容器网络而对应的底层网络如ovs网络则交由其对应DPU上工作在DPU模式的cni-node完成。
2.2.2.2. 网络数据面 基于DPU卸载与加速的高性能网络其核心技术的数据面原理如上图所示。基于ovn/ovs提供SDN的能力并基于DPU提供的SRIOV及流表卸载功能对网络进行了加速为云上业务提高了高性能网络。
2.2.3. 存储
Kubevirt并没有重新定义存储存储还是由Kubernetes定义的所以还是沿用CSI规范创建/挂载/删除磁盘卷如上图所示。主流平台的磁盘卷都是通过网络TCP/RDMA来挂载的一般都是基于TCP的RDMA需要硬件的支持。
2.2.3.1. 存储控制面 基于DPU的虚拟机磁盘卷架构如如上图所示将master节点dpu卡Host都作为node加入k8s集群这些node上运行着DPU CSI的相关组件k8s node分为不同的角色不同组件分别部署在不同的node之上。
Master上部署 csi的控制器csi-controller其中部署包含了组件external-provisioner、csi-plugin、csi-attacher、csi-resizer和csi-snapshotter等组件用于创建volume和nvmeof targetHost上部署csi-node-host配合csi-node-dpu通过va发现DPU挂载的nvme盘然后执行绑定或者格式化DPU上部署csi-node-dpuvolume-attacheropi-bridge和SPDK主要负责连接远端存储target及向宿主机模拟nvme硬盘;
opi-bridge是卡对opi-api存储的实现。volume-attacher是对DPU存储相关方法的封装csi-node-dpu 调用volume-attacher给host挂盘 为了对接不同的存储CSI提供了csi-framework, 通过csi-framework能快速的接入第三方的存储让第三方存储很方便的使用DPU的能力同时CSI提供基于opi框架的opi-framework通过opi-framework能快速让DPU适配到K8S集群。
2.2.3.2. 存储数据面 DPU通过网络连接远端存储target实现了存储协议的卸载同时能基于RDMA进行网络路径上的加速另一方面DPU模拟了nvme协议通过PCIe向宿主机提供了nvme块设备。
3. 方案测试结果
3.1. 测试步骤说明
主要是对KubeVirt虚拟机的网络和存储进行性能验证
网络性能主要测试卸载CNI方案和非卸载CNI方案下的虚拟机网卡性能包括带宽、PPS、时延。存储性能主要针对虚拟机的数据盘进行验证包括顺序写吞吐、顺序读吞吐、随机写IOPS、随机读IOPS、随机写时延、随机读时延。虚拟机的数据盘来源于DPU模拟的nvme磁盘后端存储协议有2种nvme over tcp和nvme over rdma。
使用卸载CNI方案的虚拟机网络拓扑如下图 使用非卸载CNI方案的虚拟机网络拓扑如下图 3.2. 性能测试结果
以下列举基于DPU 100G网络方案的网络性能指标并与非硬件卸载CNI方案做简单对比 分类 性能指标 非卸载CNI方案 卸载CNI方案 网络 网络带宽 27.4Gbps 137Gbps 网络PPS 3.4M 26M 网络时延 783us 18us
从上表可知基于卸载CNI方案的网络性能相比于非卸载CNI方案来说网络带宽提升了4倍网络PPS提升了6.6倍网络时延降低了97.7%
基于DPU100G存储方案性能指标nvme over rdma对比nvme over tcp 分类 性能指标 nvme over tcp nvme over rdma 存储 顺序写吞吐 1146MiB/s 2577MiB/s 顺序读吞吐 431MiB/s 5182MiB/s 随机写IOPS 104k 232k 随机读IOPS 63.1k 137k 随机写时延 164us 60us 随机读时延 429us 127us
从上表可知nvme over rdma方式的存储在吞吐、IOPS、时延方面全面优于nvme over tcp方式的存储。另外nvme over rdma场景下的存储性能远低于容器挂载硬盘时的性能(650kiops)原因是当前虚拟机的硬盘是通过virtio方式挂载的存在额外的虚拟化开销性能上受到限制。
4. 优势总结
在KubeVirt虚拟机环境中基于DPU硬件卸载的方案相较于传统的非卸载方案具有显著的优势这些优势主要体现在网络性能、资源利用率、时延降低以及存储性能加速等方面具体总结如下
1、降低网络复杂度和运维排障难度
通过DPU的网络卸载能力实现了网卡直通到虚拟机减少了虚拟网络设备veth pair、网桥、TAP设备等极大地缩短了网络路径降低了网络复杂性和运维排障难度并减少了数据在传输过程中的延迟和损耗。
2、显著提升网络性能
将虚拟机的流表卸载到DPU中利用硬件进行流表处理直接将网络数据对接到虚拟机这一过程比软件处理更为高效为虚拟机提供了接近物理网卡的极致性能。这种方式使得网络带宽提升了4倍PPS每秒包数提升了6.6倍网络时延降低了97.7%显著提升了网络吞吐量和处理速度。
3、降低资源消耗
将OVSOpen vSwitch控制面和数据面都部署在DPU中利用DPU的硬件资源进行网络数据包的转发和处理大大减轻了Host主机CPU和内存的负担。在40Gbps的TCP/IP流量场景下传统服务器容易因处理网络任务而耗尽CPU资源而基于DPU的硬件卸载方案能够显著降低CPU占用率使得服务器能够处理更多的计算任务或支持更高的网络负载。
4、加速存储性能
通过yusur-csi提供的基于DPU的RDMA支持相对于传统的TCP存储方案能够实现硬件级别的性能加速。这种加速效果最低能达到2倍最高能达到10倍显著提升了存储系统的吞吐量和响应速度。
综上所述基于DPU硬件卸载CNI方案通过缩短网络路径、降低资源消耗、减少网络时延以及加速存储性能等多方面优势为云计算和虚拟化环境提供了更高效、更可靠的网络和存储解决方案。
本方案来自于中科驭数软件研发团队团队核心由一群在云计算、数据中心架构、高性能计算领域深耕多年的业界资深架构师和技术专家组成不仅拥有丰富的实战经验还对行业趋势具备敏锐的洞察力该团队致力于探索、设计、开发、推广可落地的高性能云计算解决方案帮助最终客户加速数字化转型提升业务效能同时降低运营成本。
