proxmox在线半年总结及和zstack对比

Posted 2023-03-29 USTC-lup

Zstack，proxmox

鼎阳SDS6204长波形读取的潜力挖掘及上海光源测试

关于proxmox，给Zstack的公开建议

十一放假折腾服务器札记

应该是2022年6月份搭好proxmox三机集群，之后十一放假那几天把一部分在线系统迁移到集群中，之后在集群中一直稳定运行。

直到今年3月份第一次集群故障，3台服务器的两台ceph盘down：

不知道原因，没敢做什么操作，后来这些盘又都自己up回去了。

之后就是上周实验室整个突然掉电，好几台快阀控制器损坏，这个便携式服务器（翻博客发现这个竟然没专门发文秀一下）的系统raid1的一块三星870EVO竟然也在这次掉电中损坏了。

 

几台集群和便携式服务器都没有接UPS，掉电有零件随机损坏很正常。还好集群经受了掉电的考验，启动后发现ceph等文件系统都没问题。

合肥光源Zstack单机企业版的重负荷在线使用

逐束团3D10ms波形采集处理系统介绍和初步结果展示

之后又把便携式服务器上的逐束团3D系统的虚拟机转移到集群中：

逐束团3D系统需要一台服务器满负荷工作，所有其他轻负荷系统可在一台服务器上运行，另一台可用作热迁移和热备，并做新建虚拟机测试等任务，这样的池化管理在后续的集群服务器增加和轮换都极为方便，再不象原来多台单机系统各自管理，迁移和备份都要每台服务器不断地镜像传输。

这半年中，proxmox除了上次ceph故障自动恢复外，总体感觉系统还很稳定，使用的过程中，proxmox和zstack的比较，感觉还是zstack更好用以及更稳定，zstack是2020年上半年才知道，转眼使用快3年了，这几年一直使用的单机版，装过的所有服务器都一直正常，并且有一台服务器在搬运过程中，raid盘出现故障，即使这样的带病上岗，系统也一直稳定工作。

proxmox是需要命令行和web界面配合着操作才能完成想要做的事，比如镜像文件的导入和生成虚拟机，在zstack里，基本上web界面操作就可完成。

proxmox是现在系统运维和工程建设没有这部分基础架构预算的选择，不花钱订阅的话，使用过程中碰到问题只能求助周边或社区高手尝试解决，自己需要花费更多的功夫学习，zstack如果买许可证使用就省心多了，即使一直没有花钱，厚着脸皮求助他们的大神，也会不辞劳苦的帮忙应急解决问题。

为了系统的可靠运行，未来最终还是需要转移到自主基础架构上，还是给zstack些建议：

单机版不设限，5CPU以下多节点也不设限，这样无法3台双CPU服务器集群上线使用，但是可供运维工程师使用普通计算机组成集群熟悉系统，这样架构对一线运维人员就有更大的粘性；收费最好不要一次性投资后永久不收费，这样的一次性高额投入，向领导们申请预算，以及领导们向上面领导们申请这样比较大额的经费都是很麻烦的事，可以增加逐年订阅的收费模式，每年的金额并不大，在系统运行费里可以很方便的逐年支付。

有国产自主Zstack以及免费的开源proxmox可供选择，并且从事服务器运维没几年的生手就能很快地熟悉起来，完全可以替代vmware这类总想卡中国脖子的闭源基础架构。

详解ZStack 高性能网络方案以及性能对比测试

从写下第一行代码开始，云轴科技ZStack 始终秉持着 4S (Simple、Strong、Scalable、Smart) 的产品理念，这样的思想同样体现在 ZStack 虚拟网络方案上。

Linux Bridge 网络架构简单可靠，且能满足绝大部分应用场景，长久以来都是 ZStack 平台默认的方案。但随着云轴科技 ZStack 客户体量不断增长，默认的网络方案逐渐无法满足部分客户的需求。为了应对需求的变化，云轴科技 ZStack 先后推出了 SR-IOV 方案和高性能网络方案。

01、ZStack 网络方案

1.1 主流网络方案

目前主流的网络方案分为两大类：

●以 Linux Bridge 为基础，使用 Linux 内核协议栈，架构简单且稳定可靠，也是 ZStack 平台默认的网络方案；

●以 OVS 为基础，采用虚拟交换机的形式，支持 OpenFlow 协议，自由灵活，搭配 DPDK 可获得不俗的性能，ZStack 高性能网络方案就是以 OVS-DPDK 基础实现的。

两种方案各有千秋，选择合适的应用场景才能发挥最佳的作用。本文将介绍 ZStack 平台支持的 4 类网络方案，并通过测试对比其性能差异。

1.1.1 Linux Bridge 方案：功能性较好，但网络性能一般

以 Linux Bridge 为基础，集成多项网络服务，使用通用的 virtio 驱动，稳定可靠，具体如下图所示：

图1 Linux Bridge网络方案

该方案理论性能一般，满足通用场景，功能性较好，支持热迁移和多项网络服务。

1.1.2 SR-IOV 方案：网络性能较好，但功能性较差

SR-IOV 是 PCIe 协议的扩展，它允许设备，例如网卡，将对其资源的访问划分成多个 PCIe functions。ZStack 通过 pci-passthrough 将 VFs (virtual functions) 透传到虚拟机中，以达到最佳的网络性能，具体方案如图2所示：

图2 SR-IOV网络方案

该方案理论上拥有最佳的网络性能，但是功能性较差，例如：要求网卡支持 SR-IOV、无法热迁移、受限于 VFs 数量等。

1.2 ZStack高性能网络方案

云轴科技ZStack 推出的高性能网络方案以 OVS-DPDK 为基础，主要有以下两种实现方式：

1.2.1 dpdkvhostuser 方案：以消耗CPU资源实现高性能

采用标准的 OVS-DPDK 方案，以消耗 CPU 资源为代价换取优秀的网络性能；目前支持 Intel x710 系列以及 mellanox cx-5/cx6 网卡。方案如下图所示：

图3 dpdkvhostuser 方案

该方案理论性能优秀，且功能性较好，同样支持热迁移和部分网络服务。

1.2.2 software vDPA 方案：借助智能网卡中特定vDPA 模块实现高性能

在标准的 OVS-DPDK 方案的基础上，借助智能网卡中特定的 vDPA 模块，减少 CPU 资源消耗；目前仅支持 mellanox cx-5/cx6 网卡。

图4 software vDPA 方案

该方案理论性能优秀，功能性一般，支持热迁移，但是同样受限于 VFs 数量。

02、测试目标与方法

通过在相同的两台物理机上切换 ZStack 网络方案进行压力测试，验证不同网络方案下的性能表现。

2 .1 测试模型

图5 测试模型

2 .2 DUT 配置
服务器硬件配置

ZStack 平台配置

vm 配置

vpp 配置

2.3 TRex 配置

硬件配置同 DUT 硬件配置

测试软件版本及测试参数

2.4 测试方法

使用相同的服务器硬件和虚拟机配置，改变虚拟网络方案，通过 TRex 进行 UDP 小包测试，DUT 中使用 vpp 做路由转发避免 kernel 瓶颈；逐渐增加测试压力，直至开始出现丢包，记录测试数据及当前环境配置，并进行分析。

●CPU 资源消耗情况；

●零丢包 pps。

2.5 测试数据

可以看出高性能网络方案，即 dpdkvhostuser 和 vDPA 方案，以及 SR-IOV 方案相比默认的 Linux Bridge 方案性能提升显著；在不进行额外调优的情况下，SR-IOV 方案性能最佳。

2.6 结论

1.功能性及灵活性上 Linux Bridge >= dpdkvhostuser > software vDPA > SR-IOV；

2.网络性能上 SR-IOV > software vDPA > dpdkvhostuser > Linux Bridge；

3.高性能网络方案带来的性能提升以消耗 CPU 作为代价，而 vDPA 方案得益于智能网卡加速模块相比 dpdkvhostuser 方案可节约部分 CPU 资源；

4.SR-IOV 性能最佳，但是其局限性较大，例如，无法热迁移、要求虚拟机安装对应的网卡驱动等。

03、延伸思考

1.该测试使用的是 10Gb 光模块，因此光模块限制了性能的上限；测试环境（除 pmd-CPU 数外）均由 ZStack 平台默认配置，若增加 CPU 隔离，vNUMA 配置等优化手段，可以进一步提升；

2.虽然 Linux Bridge 和 SR-IOV 方案不需要使用单独的 pmd-CPU 资源，但并不意味着宿主机接收网络包时不用消耗 CPU 资源，事实上宿主机内核收包 CPU 将收到大量软中断；

3.ZStack 高性能网络方案，在设计上考虑到了以往的用户使用习惯，使用逻辑与以往相似，降低学习成本，快速上手；

4.dpdkvhostuser 和 software vDPA 方案各有优劣，dpdkvhouser 虽然消耗更多 CPU，但是使用条件更宽松；software vDPA 使用条件则更为苛刻，使用时可酌情选择。