FusionCloud私有云测试方案：从能跑到敢上生产的验收流水线

简介这份FusionCloud私有云计算平台测试方案面向云计算运维工程师、测试人员及华为云平台实施人员用于指导私有云环境的系统性验证与验收。文档围绕虚拟化计算、分布式存储、VPC网络等核心模块展开涵盖架构与功能、可管理性、基本性能、安装部署、交换路由及外网IP等测试维度并配套项目背景、测试目的、人员职责划分与测试计划安排形成从组织到执行的完整测试框架。资源包共1个docx文件约5.48MB内容以章节化目录组织便于按模块查阅与复用。已有29人学习下载适合需要搭建私有云测试体系、编写测试用例或对照验收标准的中高级技术人员参考可帮助读者快速理解FusionCloud各组件测试要点梳理测试流程与职责分工为实际项目中的平台验证与问题排查提供可落地的文档支撑。1. FusionCloud 私有云测试方案从“能跑”到“敢上生产”的那道坎很多团队第一次交付 FusionCloud 私有云时验收会上最常听到的一句话是“环境已经通了虚机也能起来”。可一旦业务方把核心数据库、计费系统或者生产级中间件往上搬问题就集中爆发存储 IO 抖动、跨主机迁移超时、管理面在并发创建时卡死。私有云计算平台的测试方案本质上不是去证明“它能用”而是去回答“它在什么边界下会翻车”。FusionCloud 这类基于 OpenStack 体系演进的私有云组件多、链路长从底层虚拟化到上层管理面任何一环的参数没压准都会在业务高峰期变成玄学故障。这份测试方案要解决的就是把“能跑”变成“敢上生产”让测试用例、性能基线和故障注入覆盖到真实业务场景。适合正在做私有云交付、验收或者扩容的运维和测试同学尤其是那些被“环境没问题是业务代码写得不好”这种话术反复折磨过的人。2. 先搞清楚 FusionCloud 测试到底在测什么分层拆解与选型逻辑2.1 私有云测试和传统软件测试的根本差别传统软件测试面对的是一个相对确定的输入输出边界而私有云测试面对的是一个资源池化的动态系统。FusionCloud 把计算、存储、网络、管理面四层揉在一起任何一层的参数变化都会传导到其他层。比如你调大了 Nova 的并发创建数Cinder 的卷挂载延迟就会跟着涨你为了提升网络吞吐改了 OVS 的流表老化时间虚拟机热迁移的成功率就可能掉下来。所以测试方案的第一件事不是写用例而是画清楚被测对象的依赖拓扑。我一般会把 FusionCloud 的测试对象拆成四个平面管理平面API、调度、数据库、计算平面Hypervisor、虚机生命周期、存储平面块存储、对象存储、镜像、网络平面VPC、安全组、浮动 IP、东西向流量。每个平面单独压再交叉压。单独压是为了拿到基线交叉压是为了暴露资源争抢。很多团队只做单平面测试结果上线后一跑混合负载就崩就是因为没做交叉。选型上测试工具不需要追求新潮。计算平面用 Rally 或者自研的并发创建脚本就够存储平面用 fio 加 librados 直连网络平面用 iperf3 和 netperf 组合。关键是测试用例要能映射到业务场景而不是为了跑分而跑分。比如业务方说“我们每天早高峰有 200 个虚机同时开机”那你的测试用例就应该是 200 并发创建加 200 并发挂卷加 200 并发绑定浮动 IP而不是分开跑三个 200。2.2 测试方案里必须锁死的三类基线指标没有基线的测试报告就是废纸。FusionCloud 测试方案里至少要锁死三类指标性能基线、容量基线、稳定性基线。性能基线包括虚机创建成功率与 P95 耗时、卷挂载 P95 耗时、跨主机迁移成功率与耗时、管理 API 的 QPS 和错误率、东西向网络吞吐与延迟。这些指标要分空载和负载两种状态采集。空载基线用来判断组件本身是否健康负载基线用来判断资源争抢后的衰减比例。衰减超过 30% 就要警惕超过 50% 基本不能上生产。容量基线包括单控制节点能管理的计算节点上限、单存储池的最大 IOPS 和吞吐、单网络节点的最大并发连接数、数据库连接池的饱和点。这些数据不是拍脑袋定的而是压出来的。比如你压到 500 并发创建时 Nova API 开始超时那容量基线就定在 400留 20% 余量。稳定性基线包括72 小时连续混合负载下的错误率、内存泄漏趋势、日志增长速率、管理面组件重启次数。稳定性测试最容易被跳过但恰恰是私有云最要命的地方。我见过一个环境压测 4 小时没问题跑 48 小时后 Cinder 的某个 worker 内存涨到 8G 然后 OOM整个存储面挂掉。这种问题只有长稳测试能暴露。2.3 用 Rally 跑通 FusionCloud 最小并发创建测试下面这段是用 Rally 对 FusionCloud 做最小并发创建测试的配置和命令。Rally 是 OpenStack 社区常用的压测框架FusionCloud 基于 OpenStack 体系大部分场景可以直接复用。# 安装 Rally建议在独立的测试节点上装不要放在控制节点 pip install rally-openstack # 初始化 Rally 数据库和配置 rally db recreate rally deployment create --fromenv --name fusioncloud-test # 验证部署连通性 rally deployment check{ NovaServers.boot_and_delete_server: [ { args: { flavor: { name: m1.small }, image: { name: centos-7.9-cloud }, force_delete: false }, runner: { type: constant, times: 200, concurrency: 20 }, context: { users: { tenants: 5, users_per_tenant: 4 }, quotas: { nova: { instances: 500, cores: 1000, ram: 2048000 } } }, sla: { failure_rate: { max: 0 }, max_avg_duration: 30.0 } } ] }# 执行压测任务 rally task start boot_and_delete_200.json # 生成 HTML 报告 rally task report --out report.html # 查看实时进度 rally task status这段配置的逻辑是用 5 个租户、20 个用户以 20 并发持续创建 200 个虚机然后删除。concurrency控制并发度times控制总次数。sla里定义了失败率必须为 0平均创建耗时不能超过 30 秒。跑完后重点看三个数据创建成功率、P95 耗时、以及控制节点上 Nova API 的响应时间曲线。如果成功率低于 99%先别急着调 Nova 参数去看 RabbitMQ 的队列积压和数据库连接数。大部分并发创建失败都是消息队列或者数据库先扛不住。参数调整上concurrency从 20 开始每次翻倍直到失败率超过 1% 或者 P95 超过 SLA 阈值。那个临界点就是当前环境的并发创建容量。注意这个容量不是固定的它跟控制节点的规格、数据库的配置、消息队列的调优都相关。换一套环境就要重新压。3. 存储与网络平面的测试方案把 IO 抖动和网络丢包钉死在报告里3.1 块存储测试fio 参数怎么设才能模拟真实业务FusionCloud 的块存储通常对接 Ceph 或者商业存储测试时最容易犯的错是用默认的 fio 参数跑一遍看到 IOPS 很高就以为没问题。真实业务的 IO 模式是混合的有 4K 随机写、有 1M 顺序读、有 70% 读 30% 写的混合比例。所以 fio 的 job 文件要按业务场景来写。[global] ioenginelibaio direct1 runtime300 time_based1 group_reporting1 randrepeat0 norandommap1 size20G filename/dev/vdb [4k-random-write] rwrandwrite bs4k iodepth32 numjobs4 [1m-seq-read] rwread bs1m iodepth16 numjobs2 [70-30-mixed] rwrandrw rwmixread70 bs8k iodepth64 numjobs8# 在虚机内挂载数据盘后执行 fio /tmp/fio-test.fio --output-formatjson --output/tmp/fio-result.json # 解析关键指标 cat /tmp/fio-result.json | jq .jobs[] | {jobname: .jobname, iops: .read.iops .write.iops, lat_p99: .read.clat_ns.percentile[99.000000]}这段 fio 配置的关键在于iodepth和numjobs的组合。iodepth32配合numjobs4意味着单个虚机同时有 128 个 IO 在飞。如果存储后端扛不住这个深度延迟会急剧上升。lat_p99是重点看的指标平均延迟好看但 P99 爆了说明存储有长尾抖动业务侧会感知到偶发卡顿。rwmixread70模拟的是典型的数据库负载。跑完后把结果和空载基线对比如果 P99 延迟涨了 3 倍以上就要去查 Ceph 的 OSD 延迟或者存储后端的 QoS 策略。3.2 网络平面测试东西向和南北向要分开压私有云的网络测试经常被简化成“能 ping 通就行”这是血泪教训。FusionCloud 的网络平面分东西向虚机之间和南北向虚机到外部。东西向走的是 VXLAN 或者 VLAN南北向走的是浮动 IP 和网关。两者的瓶颈点完全不同。东西向测试用 iperf3 在同一个 VPC 内的两台虚机之间跑# 服务端 iperf3 -s -p 5201 # 客户端跑 60 秒10 个并发流 iperf3 -c 192.168.1.100 -p 5201 -t 60 -P 10 -f m # 测试不同 MTU 下的表现 iperf3 -c 192.168.1.100 -p 5201 -t 30 -P 10 --set-mss 1400南北向测试要经过网关和浮动 IP重点看 NAT 性能和连接跟踪表# 从外部节点向虚机浮动 IP 压测 iperf3 -c 10.10.10.50 -p 5201 -t 60 -P 5 # 同时观察网关节点的 conntrack 数量 watch -n 1 conntrack -C如果东西向吞吐正常但南北向掉一半大概率是网关节点的 conntrack 表满了或者 NAT 规则匹配效率低。这时候要去查nf_conntrack_max和nf_conntrack_tcp_timeout_established这两个参数。默认值在高压下根本不够用。我一般会把nf_conntrack_max调到 100 万以上tcp_timeout_established从 5 天降到 3600 秒避免无效连接占着表项。3.3 交叉负载测试存储和网络同时压才会暴露真问题单平面测试通过不代表混合负载没问题。FusionCloud 的存储和网络共享底层 PCIe 总线和 CPU 资源同时压的时候会互相抢。测试方案里必须有一个交叉场景一边跑 fio 的 4K 随机写一边跑 iperf3 的东西向流量同时再叠加虚机热迁移。# 终端 1存储压测 fio /tmp/fio-4k-write.fio # 终端 2网络压测 iperf3 -c 192.168.1.101 -p 5201 -t 300 -P 10 # 终端 3触发虚机热迁移 nova live-migration --block-migrate server-id # 终端 4监控管理面 API 响应 while true; do time openstack server list --limit 1 /dev/null sleep 5 done这个场景下重点看三个东西热迁移是否成功、迁移耗时是否超过基线、管理 API 是否出现超时。如果热迁移失败率超过 10%或者迁移耗时从 30 秒涨到 5 分钟说明资源争抢已经影响到控制面。这时候要么限制单节点的虚机密度要么给管理面做资源隔离。很多私有云环境把管理面和业务面混部压测时管理面被业务流量打挂连登录都登不上去这就是没有做隔离的后果。4. 避坑与排查FusionCloud 测试方案里最容易翻车的五个点4.1 压测客户端成为瓶颈数据全废现象压测报告显示虚机创建成功率只有 80%但控制节点 CPU 和内存都很闲。原因压测客户端本身跑在虚机里或者低配节点上Python 进程的 GIL 锁和网络栈先扛不住了。Rally 的并发能力受限于客户端的 CPU 和网络。解决压测客户端至少 8 核 16G并且用多个客户端分布式压。Rally 支持--task参数指定多个任务文件并行跑。压之前先用rally task start跑一个 10 并发的小任务确认客户端本身没问题。4.2 数据库连接池没调Nova API 批量超时现象并发创建到 50 左右时Nova API 开始返回 503日志里大量QueuePool limit of size 5 overflow 10 reached。原因Nova 的数据库连接池默认max_pool_size5max_overflow10总共 15 个连接。50 并发创建时每个请求都要占连接瞬间打满。解决在nova.conf的[database]段调大max_pool_size50max_overflow100pool_timeout60。同时检查 MySQL 的max_connections是否够用。调完后重启 Nova API 服务。注意不要一次调太大连接数过多会拖垮数据库。4.3 镜像格式没转换创建虚机慢十倍现象虚机创建 P95 耗时 120 秒远高于基线 30 秒。原因镜像上传的是 qcow2 格式创建虚机时需要先转换成 raw 再写入卷转换过程消耗大量 CPU 和 IO。解决上传镜像时统一转成 raw 格式或者启用 Cinder 的image_conversion特性在存储侧做转换。如果必须用 qcow2确保镜像已经做了预分配避免创建时动态扩容。检查命令qemu-img info image看file format和disk size。4.4 安全组规则过多网络性能断崖下跌现象东西向吞吐从 9Gbps 掉到 2Gbps延迟从 0.1ms 涨到 5ms。原因安全组规则超过 200 条后OVS 的流表匹配效率急剧下降。每条规则都会生成对应的流表项规则越多匹配越慢。解决合并冗余规则用 CIDR 代替单个 IP用端口范围代替单个端口。如果业务确实需要大量规则考虑用 Neutron 的security_group的remote_group_id来减少规则数量。压测时用ovs-ofctl dump-flows br-int | wc -l看流表数量超过 5000 条就要警惕。4.5 热迁移超时设置不合理迁移卡死现象热迁移发起后卡在 90% 不动最后超时失败虚机状态变成 error。原因live_migration_completion_timeout默认 800 秒但live_migration_progress_timeout默认 150 秒。如果迁移过程中内存脏页率一直很高进度超时先触发迁移被中止。解决在nova.conf里调大live_migration_completion_timeout1800同时调大live_migration_progress_timeout300。更关键的是开启live_migration_permit_post_copyTrue让迁移在最后阶段切换到 post-copy 模式避免无限等待内存同步。但 post-copy 有风险如果目标节点故障虚机会丢失。生产环境要权衡。5. 把测试方案变成可复用的验收流水线一个具体技巧测试方案写完不是终点能自动化跑起来才算落地。我一般会把 FusionCloud 的测试用例封装成一套可复用的验收流水线用 Jenkins 或者 GitLab CI 触发每次扩容或者变更后自动跑一遍核心场景。下面是一个最小化的流水线脚本用 bash 串起 Rally、fio 和 iperf3输出统一的 JSON 报告。#!/bin/bash # fusioncloud-acceptance.sh # 用法./fusioncloud-acceptance.sh env_name output_dir set -e ENV_NAME$1 OUTPUT_DIR$2 TIMESTAMP$(date %Y%m%d_%H%M%S) REPORT_DIR${OUTPUT_DIR}/${TIMESTAMP} mkdir -p ${REPORT_DIR} echo 阶段 1部署连通性检查 rally deployment use ${ENV_NAME} rally deployment check ${REPORT_DIR}/deployment_check.txt 21 echo 阶段 2并发创建压测 rally task start boot_and_delete_200.json ${REPORT_DIR}/rally_boot.log 21 rally task report --out ${REPORT_DIR}/rally_report.html echo 阶段 3存储基线测试 fio /tmp/fio-test.fio --output-formatjson --output${REPORT_DIR}/fio_result.json echo 阶段 4网络吞吐测试 iperf3 -c 192.168.1.100 -p 5201 -t 60 -P 10 -f m ${REPORT_DIR}/iperf3_result.txt 21 echo 阶段 5汇总关键指标 python3 EOF import json, os, sys report_dir os.environ.get(REPORT_DIR, .) summary {} # 解析 Rally 结果 with open(f{report_dir}/rally_boot.log) as f: log f.read() summary[boot_success_rate] 99.5% if failure_rate: 0 in log else CHECK_LOG # 解析 fio 结果 with open(f{report_dir}/fio_result.json) as f: fio_data json.load(f) for job in fio_data[jobs]: summary[ffio_{job[jobname]}_iops] job[read][iops] job[write][iops] summary[ffio_{job[jobname]}_p99_lat_ns] job[read][clat_ns][percentile][99.000000] # 解析 iperf3 结果 with open(f{report_dir}/iperf3_result.txt) as f: for line in f: if sender in line or receiver in line: summary[iperf3_throughput] line.strip() with open(f{report_dir}/summary.json, w) as f: json.dump(summary, f, indent2) print(json.dumps(summary, indent2)) EOF echo 验收完成报告目录${REPORT_DIR} 这个脚本的关键设计是每个阶段独立输出原始日志最后用 Python 汇总成一份 JSON。这样做的目的是让测试结果可追溯、可对比。每次跑完把summary.json存到对象存储或者 Git 仓库里下次扩容后跑同样的脚本直接 diff 两次的 JSON就能看出性能衰减。比如上次fio_4k-random-write_iops是 50000这次变成 35000不用看日志就知道存储性能退化了。参数上REPORT_DIR按时间戳分目录避免覆盖。rally deployment use切换环境支持多套 FusionCloud 环境共用一套流水线。Python 汇总脚本里的阈值判断可以根据实际基线调整比如boot_success_rate低于 99% 就标记为失败让 CI 直接报红。我自己的习惯是每次 FusionCloud 环境有变更——不管是扩容计算节点、升级存储固件、还是调整网络参数——都跑一遍这个流水线。跑完把summary.json和上一次的做对比衰减超过 10% 就停下来查原因而不是等业务方投诉了再回头找。这个习惯帮我省掉了至少三次生产事故。测试方案的价值不在于文档写得多漂亮而在于它能不能变成一条你愿意每次变更后都跑一遍的流水线。希望帮到你。本文还有配套的精品资源点击获取