简介这份FusionCloud私有云计算平台测试方案面向云计算运维工程师、测试人员及华为云平台实施人员用于指导私有云环境的系统性验证与验收。文档围绕虚拟化计算、分布式存储与VPC三大核心模块展开涵盖架构与功能、可管理性、基本性能、安装部署、交换、路由和子网、外网IP等测试维度并配套项目背景、测试目的、人员职责划分、测试计划与时间地点安排形成从组织到执行的完整测试框架。资源包内含1个docx文档压缩包约5.48MB目录层级清晰便于按模块快速定位测试项。已有29人学习参考适合需要搭建私有云测试体系、编写测试用例或对照验收标准查漏补缺的技术人员可帮助读者理解华为FusionCloud平台各组件测试要点提升方案设计与落地效率。1. FusionCloud 私有云测试方案从资源池到业务验收的完整闭环很多团队在私有云服务器搭建完成后第一反应是“能 ping 通、能开虚拟机就算交付了”结果上线三个月后业务侧反馈存储 IO 抖动、跨节点迁移超时、租户配额被击穿。FusionCloud 私有云计算平台的测试方案本质上不是一份“功能勾选表”而是一套从物理资源池、虚拟化层、云服务层到业务验收逐层收敛的验证体系。它要回答三个问题资源池的真实容量边界在哪、多租户隔离是否可靠、故障注入后业务能否自动恢复。这套方案适合正在做私有云交付的运维工程师、云平台测试人员和架构师尤其是那些已经踩过“验收即翻车”坑的团队。下面按资源池、虚拟化、云服务、性能、避坑、进阶验证六段推进每一步都给出可复现的命令和参数。2. 资源池层测试物理机、存储与网络的基线怎么打2.1 物理节点准入检查别让一台坏盘机器混进集群FusionCloud 的资源池由大量物理节点组成测试第一步不是上云平台而是逐台做硬件基线。常见做法是用ipmitool读传感器、用smartctl查盘、用ethtool看网卡协商速率。我一般会写一个批量脚本把每台机器的 CPU 型号、内存容量、磁盘 SMART 状态、网卡速率、BIOS 版本全部落表任何一项不达标直接踢出集群。#!/bin/bash # 物理节点准入检查脚本逐台执行 NODE$1 echo $NODE 硬件基线 # 1. 带外传感器温度、电压、风扇 ipmitool -I lanplus -H $NODE-bmc -U admin -P password sdr type temperature # 2. 磁盘健康重点关注 Reallocated_Sector_Ct 和 Media_Wearout for disk in /dev/sd[a-z]; do smartctl -H -A $disk | grep -E SMART overall|Reallocated_Sector|Media_Wearout done # 3. 网卡协商速率必须是 25000Mb/s 或 10000Mb/s for nic in $(ls /sys/class/net | grep -E eth|enp|ens); do echo $nic: $(ethtool $nic | grep Speed) done # 4. NUMA 拓扑后续虚拟机绑核要用 numactl --hardware逻辑说明ipmitool的sdr type temperature只读温度类传感器避免输出过长smartctl的-H给健康总评-A给属性表重点看重分配扇区计数是否大于 0。网卡速率低于 10G 的节点不要放进分布式存储池否则会成为木桶短板。NUMA 拓扑输出要保存后面做 CPU 绑定时直接引用。参数说明-I lanplus是 IPMI 2.0 协议-H后跟 BMC 地址-U/-P是带外账号。如果 BMC 不通先查交换机 ACL 和 VLAN 配置不要跳过这台机器直接上云。2.2 分布式存储池测试用 fio 摸清 IOPS 和时延底牌FusionCloud 底层通常挂 Ceph 或自研分布式存储。测试存储池不能只看“容量对不对”要分场景压4K 随机写看 IOPS1M 顺序写看带宽4K 随机读写混合看时延。我一般用fio在三个节点同时发起模拟真实多副本写入。# 在三个存储客户端同时执行模拟三副本写入 fio --namerandwrite --ioenginelibaio --direct1 \ --bs4k --size10G --numjobs8 --rwrandwrite \ --group_reporting --runtime120 --time_based \ --filename/mnt/ceph/testfile --output-formatjson \ --output/tmp/fio_randwrite.json # 顺序写带宽测试 fio --nameseqwrite --ioenginelibaio --direct1 \ --bs1M --size20G --numjobs4 --rwwrite \ --group_reporting --runtime120 --time_based \ --filename/mnt/ceph/testfile_seq逻辑说明--direct1绕过页缓存测的是真实落盘性能--numjobs8模拟 8 个并发客户端--runtime120 --time_based让任务跑满两分钟而不是写完固定大小就停。JSON 输出方便后续用脚本提取iops和clat百分位。参数说明4K 随机写 IOPS 低于 5000 的存储池跑数据库类业务会非常痛苦1M 顺序写带宽低于 500MB/s 的池子不适合放镜像仓库。时延看clat的 99 分位超过 20ms 就要查网络或磁盘队列深度。2.3 管理网络与业务网络分离验证FusionCloud 部署规范要求管理、存储、业务三张网物理隔离或 VLAN 隔离。测试方法是在管理网用iperf3打流同时业务网跑虚拟机迁移观察管理网时延是否抖动。如果管理网和业务网混跑一次大规模迁移就可能让 API 超时控制台“假死”。# 管理网打流持续 60 秒 iperf3 -c 192.168.10.2 -t 60 -P 4 --logfile /tmp/mgmt_iperf.log # 同时在另一台机器触发虚拟机热迁移 nova live-migration --block-migrate vm-id target-host逻辑说明-P 4开四个并行流更接近真实管理流量。迁移过程中观察iperf3的retr重传次数如果重传超过 100 次说明管理网被业务流量挤占。参数说明管理网建议独立万兆存储网建议 25G 起步业务网按租户带宽需求规划。三网合一在测试环境可以凑合生产环境一定翻车。3. 虚拟化层测试虚拟机生命周期与热迁移的边界3.1 虚拟机全生命周期操作从创建到快照回滚虚拟化层测试要覆盖创建、启动、关机、重启、挂起、恢复、快照、回滚、删除九个动作。每个动作都要验证元数据一致性比如删除虚拟机后端口是否释放、卷是否解绑、安全组规则是否清理。我一般用openstack命令行批量跑配合watch观察资源状态。# 创建一台测试虚拟机 openstack server create --flavor m1.medium --image cirros \ --nic net-id$NET_ID --security-group default test-vm-01 # 等待 ACTIVE 后创建快照 openstack server image create --name test-vm-01-snapshot test-vm-01 # 回滚用快照重建一台新虚拟机 openstack server create --flavor m1.medium --image test-vm-01-snapshot \ --nic net-id$NET_ID test-vm-01-restore # 删除原虚拟机检查端口和卷是否释放 openstack server delete test-vm-01 openstack port list --server test-vm-01 # 应返回空逻辑说明快照回滚不是“恢复原机”而是用快照镜像新建一台。测试时要确认新机的 MAC 地址、IP 地址是否冲突。删除后port list必须为空否则说明 Neutron 有残留后续创建同 IP 虚拟机会失败。参数说明--flavor指定规格--image指定镜像--nic指定网络。如果创建卡在BUILD状态超过 5 分钟查nova-compute日志和 RabbitMQ 队列积压。3.2 热迁移测试带块迁移和不带块迁移的差别热迁移是私有云的高频操作也是测试重点。不带块迁移要求虚拟机磁盘在共享存储上迁移只传内存状态带块迁移会把磁盘一起搬耗时长但支持本地盘。测试时要分别验证迁移时长、业务中断时间、迁移后网络连通性。# 不带块迁移共享存储场景 time nova live-migration vm-id target-host # 带块迁移本地盘场景 time nova live-migration --block-migrate vm-id target-host # 迁移过程中持续 ping 虚拟机 ping -i 0.2 vm-ip | tee /tmp/migration_ping.log逻辑说明time记录迁移总耗时ping -i 0.2每 200ms 发一个包统计丢包数和最大中断时长。不带块迁移的中断通常小于 200ms带块迁移可能达到数秒。参数说明迁移并发数默认是 1大规模集群可以调nova.conf的max_concurrent_live_migrations但不要超过存储带宽的承受能力。迁移超时参数live_migration_timeout默认 300 秒跨机房迁移要适当调大。3.3 多租户隔离验证安全组、配额与 VLAN 隔离多租户是私有云的核心价值测试要验证租户 A 的虚拟机无法访问租户 B 的虚拟机租户 A 的配额用尽后无法继续创建资源不同租户的 VLAN 不能互通。# 租户 A 创建虚拟机和网络 openstack --os-project-name tenant-a server create ... openstack --os-project-name tenant-a network create tenant-a-net # 租户 B 尝试 ping 租户 A 的虚拟机应该不通 openstack --os-project-name tenant-b server create ... # 在租户 B 的虚拟机内执行 ping tenant-a-vm-ip # 预期 100% packet loss # 配额测试把租户 A 的实例配额设为 1再创建第二台 openstack quota set --instances 1 tenant-a openstack --os-project-name tenant-a server create ... # 预期报 QuotaExceeded逻辑说明租户隔离依赖 Neutron 的 VLAN/VXLAN 隔离和安全组默认拒绝规则。如果租户 B 能 ping 通租户 A说明底层网络隔离失效这是严重安全漏洞。参数说明配额包括实例数、CPU 核数、内存、卷、浮动 IP 等。测试时要逐项打满确认报错信息清晰。安全组默认规则是入方向全拒绝出方向全允许测试时要验证默认规则是否生效。4. 云服务层测试API、镜像与编排的可靠性4.1 API 网关压测并发创建虚拟机的极限在哪FusionCloud 对外提供 REST API测试时要模拟多用户并发调用。我一般用locust或wrk压nova创建接口观察 API 响应时间和错误率。# locustfile.py并发创建虚拟机 from locust import HttpUser, task, between class CloudUser(HttpUser): wait_time between(1, 3) token None def on_start(self): # 获取 token resp self.client.post(/v3/auth/tokens, json{ auth: {identity: {methods: [password], password: {user: {name: admin, password: password, domain: {name: Default}}}}}} ) self.token resp.headers[X-Subject-Token] task def create_server(self): self.client.post(/v2.1/servers, headers{ X-Auth-Token: self.token}, json{server: {name: load-test-vm, flavorRef: m1.small, imageRef: cirros-id, networks: [{uuid: net-id}]}} )逻辑说明on_start只执行一次获取 tokentask每次请求都创建虚拟机。压测时要监控nova-api的 CPU 和数据库连接数找到拐点。参数说明并发用户数从 10 开始每 5 分钟加 10直到错误率超过 1%。记录此时的 TPS 和 P95 响应时间。如果数据库连接池打满调nova.conf的max_pool_size。4.2 镜像服务测试上传、下载与格式转换Glance 镜像服务测试要覆盖 qcow2、raw、vmdk 三种格式的上传下载以及镜像元数据是否正确。大镜像上传要测分片和断点续传。# 上传 qcow2 镜像 openstack image create --disk-format qcow2 --container-format bare \ --file cirros.qcow2 --public cirros-test # 下载并校验 MD5 openstack image save --file /tmp/cirros-download.qcow2 cirros-test md5sum cirros.qcow2 /tmp/cirros-download.qcow2 # 应一致 # 格式转换qcow2 转 raw qemu-img convert -f qcow2 -O raw cirros.qcow2 cirros.raw逻辑说明MD5 校验确保镜像传输无损。格式转换用于性能敏感场景raw 格式没有元数据开销但体积更大。参数说明--disk-format必须和实际文件格式一致否则创建虚拟机会失败。--container-format bare表示无容器封装。大镜像上传超时调glance-api.conf的client_socket_timeout。4.3 编排服务测试Heat 模板的创建与回滚Heat 编排测试要验证模板语法、资源依赖、创建失败后的回滚。我一般写一个包含网络、子网、虚拟机、浮动 IP 的模板故意在中间步骤制造错误观察是否回滚干净。# test-stack.yaml heat_template_version: 2018-08-31 resources: test_net: type: OS::Neutron::Net properties: name: test-net test_subnet: type: OS::Neutron::Subnet properties: network: { get_resource: test_net } cidr: 10.0.0.0/24 test_vm: type: OS::Nova::Server properties: flavor: m1.small image: cirros networks: - subnet: { get_resource: test_subnet }逻辑说明get_resource建立依赖关系Heat 会按拓扑排序创建。如果test_vm创建失败Heat 默认回滚删除test_subnet和test_net。参数说明heat_template_version要匹配平台支持的版本。回滚策略由disable_rollback控制默认 false 即开启回滚。测试时要确认回滚后网络和子网确实被删除。5. 避坑与排查私有云测试中最容易翻车的五件事5.1 现象虚拟机创建成功但无法获取 IP原因Neutron 的 DHCP 代理没有正常运行或者 DHCP 命名空间没有创建。常见于新扩容的计算节点。解决登录网络节点执行neutron-dhcp-agent状态检查用ip netns查看 DHCP 命名空间是否存在。如果缺失重启neutron-dhcp-agent并检查dhcp_agent.ini的interface_driver配置。5.2 现象热迁移卡在 90% 后超时失败原因迁移过程中内存脏页率过高或者目标节点 CPU 不兼容。常见于虚拟机内存大于 16G 且业务写入频繁的场景。解决迁移前用virsh dommemstat看脏页速率如果超过 100MB/s先暂停业务或改用块迁移。CPU 不兼容查nova.conf的cpu_mode统一设为host-passthrough。5.3 现象Ceph 存储池 IOPS 远低于预期原因副本数设为 3 但只有 2 个故障域或者网络 MTU 不一致导致分片重传。解决ceph osd tree确认故障域分布ceph osd pool get pool size确认副本数。网络 MTU 用ping -M do -s 8972测试全链路必须一致。5.4 现象API 并发创建虚拟机时报 503原因nova-api的 worker 数不够或者数据库连接池打满。解决调nova.conf的osapi_compute_workers为 CPU 核数的一半max_pool_size调到 50 以上。同时检查 RabbitMQ 是否有消息积压。5.5 现象租户配额已满但资源实际未使用原因删除虚拟机时卷或浮动 IP 未释放导致配额计数虚高。解决openstack quota show tenant对比实际资源列表用openstack server list --all-projects和openstack volume list --all-projects找出残留资源手动清理后重置配额。6. 进阶验证用混沌工程给 FusionCloud 做故障注入前面五章把功能、性能、隔离都测完了但真实生产环境的故障往往来自“意料之外”。我一般会在验收前做一轮混沌工程主动注入故障看平台的自愈能力。这一步不是必选项但做过之后上线心里踏实很多。6.1 用 ChaosBlade 注入节点宕机和网络延迟ChaosBlade 是国内常用的混沌工程工具支持物理机、容器、网络多种场景。在 FusionCloud 测试中我主要用三个实验随机杀nova-compute进程、给存储网注入 100ms 延迟、模拟管理网丢包 10%。# 安装 chaosblade wget https://chaosblade.oss-cn-hangzhou.aliyuncs.com/agent/github/1.7.0/chaosblade-1.7.0-linux-amd64.tar.gz tar -zxvf chaosblade-1.7.0-linux-amd64.tar.gz cd chaosblade-1.7.0/ # 实验一杀 nova-compute 进程 ./blade create process kill --process nova-compute --local # 实验二存储网注入 100ms 延迟 ./blade create network delay --interface eth1 --time 100 --local # 实验三管理网丢包 10% ./blade create network loss --interface eth0 --percent 10 --local # 销毁实验 ./blade destroy experiment-id逻辑说明process kill模拟计算节点服务崩溃观察虚拟机是否自动迁移到其他节点。network delay模拟存储网抖动观察虚拟机 IO 是否挂起。network loss模拟管理网丢包观察 API 是否重试成功。参数说明--interface指定网卡--time单位毫秒--percent是丢包百分比。实验前一定要在测试环境做生产环境慎用。每个实验都要有明确的观察指标和回滚方案。6.2 验证自愈虚拟机 HA 和存储副本重建注入故障后重点看三个指标虚拟机是否在 60 秒内自动重启或迁移、存储副本是否在 5 分钟内重建到 3 副本、API 错误率是否在 1 分钟内恢复。# 观察虚拟机 HA 状态 watch -n 5 openstack server list --all-projects -c ID -c Name -c Status -c Host # 观察 Ceph 副本重建 watch -n 10 ceph -s | grep -E health|recovery|degraded # 观察 API 错误率 tail -f /var/log/nova/nova-api.log | grep -E ERROR|503逻辑说明watch每 5 秒刷新一次观察状态变化。Ceph 的degraded数量应该先升后降最终回到 0。API 日志中的 ERROR 应该在故障注入停止后 1 分钟内消失。参数说明HA 的触发时间由nova.conf的ha_interval控制默认 30 秒。存储副本重建速度受osd_recovery_max_active影响测试时可以适当调大加快重建生产环境要平衡重建速度和业务性能。6.3 一个具体技巧用 Prometheus 记录故障前后的黄金指标混沌工程不能靠肉眼观察我一般会提前部署 Prometheus 和 Grafana记录四个黄金指标延迟、流量、错误、饱和度。故障注入前后各截一张图对比曲线变化。指标采集方式正常范围故障阈值API P95 延迟nova-api 日志 500ms 2s虚拟机创建成功率自定义 exporter 99% 95%存储 IOPSCeph exporter基线 ±20%低于基线 50%管理网丢包率node_exporter 0.1% 1%逻辑说明这张表是我做验收时的“后悔药”每次故障注入后对照阈值判断平台是否合格。如果某个指标在故障停止后 5 分钟还没恢复说明自愈机制有缺陷必须在上线前修掉。参数说明Prometheus 采集间隔建议 15 秒Grafana 看板要提前配好。自定义 exporter 可以用 Python 写暴露/metrics接口即可。做完这一轮混沌工程我对 FusionCloud 的脾气基本摸清了。我的习惯是每次交付前至少做三次故障注入每次换不同的节点和不同的故障类型直到平台在故障下的表现稳定可预期。希望帮到你。本文还有配套的精品资源点击获取 FusionCloud私有云测试全攻略：从资源池到混沌工程
简介这份FusionCloud私有云计算平台测试方案面向云计算运维工程师、测试人员及华为云平台实施人员用于指导私有云环境的系统性验证与验收。文档围绕虚拟化计算、分布式存储与VPC三大核心模块展开涵盖架构与功能、可管理性、基本性能、安装部署、交换、路由和子网、外网IP等测试维度并配套项目背景、测试目的、人员职责划分、测试计划与时间地点安排形成从组织到执行的完整测试框架。资源包内含1个docx文档压缩包约5.48MB目录层级清晰便于按模块快速定位测试项。已有29人学习参考适合需要搭建私有云测试体系、编写测试用例或对照验收标准查漏补缺的技术人员可帮助读者理解华为FusionCloud平台各组件测试要点提升方案设计与落地效率。1. FusionCloud 私有云测试方案从资源池到业务验收的完整闭环很多团队在私有云服务器搭建完成后第一反应是“能 ping 通、能开虚拟机就算交付了”结果上线三个月后业务侧反馈存储 IO 抖动、跨节点迁移超时、租户配额被击穿。FusionCloud 私有云计算平台的测试方案本质上不是一份“功能勾选表”而是一套从物理资源池、虚拟化层、云服务层到业务验收逐层收敛的验证体系。它要回答三个问题资源池的真实容量边界在哪、多租户隔离是否可靠、故障注入后业务能否自动恢复。这套方案适合正在做私有云交付的运维工程师、云平台测试人员和架构师尤其是那些已经踩过“验收即翻车”坑的团队。下面按资源池、虚拟化、云服务、性能、避坑、进阶验证六段推进每一步都给出可复现的命令和参数。2. 资源池层测试物理机、存储与网络的基线怎么打2.1 物理节点准入检查别让一台坏盘机器混进集群FusionCloud 的资源池由大量物理节点组成测试第一步不是上云平台而是逐台做硬件基线。常见做法是用ipmitool读传感器、用smartctl查盘、用ethtool看网卡协商速率。我一般会写一个批量脚本把每台机器的 CPU 型号、内存容量、磁盘 SMART 状态、网卡速率、BIOS 版本全部落表任何一项不达标直接踢出集群。#!/bin/bash # 物理节点准入检查脚本逐台执行 NODE$1 echo $NODE 硬件基线 # 1. 带外传感器温度、电压、风扇 ipmitool -I lanplus -H $NODE-bmc -U admin -P password sdr type temperature # 2. 磁盘健康重点关注 Reallocated_Sector_Ct 和 Media_Wearout for disk in /dev/sd[a-z]; do smartctl -H -A $disk | grep -E SMART overall|Reallocated_Sector|Media_Wearout done # 3. 网卡协商速率必须是 25000Mb/s 或 10000Mb/s for nic in $(ls /sys/class/net | grep -E eth|enp|ens); do echo $nic: $(ethtool $nic | grep Speed) done # 4. NUMA 拓扑后续虚拟机绑核要用 numactl --hardware逻辑说明ipmitool的sdr type temperature只读温度类传感器避免输出过长smartctl的-H给健康总评-A给属性表重点看重分配扇区计数是否大于 0。网卡速率低于 10G 的节点不要放进分布式存储池否则会成为木桶短板。NUMA 拓扑输出要保存后面做 CPU 绑定时直接引用。参数说明-I lanplus是 IPMI 2.0 协议-H后跟 BMC 地址-U/-P是带外账号。如果 BMC 不通先查交换机 ACL 和 VLAN 配置不要跳过这台机器直接上云。2.2 分布式存储池测试用 fio 摸清 IOPS 和时延底牌FusionCloud 底层通常挂 Ceph 或自研分布式存储。测试存储池不能只看“容量对不对”要分场景压4K 随机写看 IOPS1M 顺序写看带宽4K 随机读写混合看时延。我一般用fio在三个节点同时发起模拟真实多副本写入。# 在三个存储客户端同时执行模拟三副本写入 fio --namerandwrite --ioenginelibaio --direct1 \ --bs4k --size10G --numjobs8 --rwrandwrite \ --group_reporting --runtime120 --time_based \ --filename/mnt/ceph/testfile --output-formatjson \ --output/tmp/fio_randwrite.json # 顺序写带宽测试 fio --nameseqwrite --ioenginelibaio --direct1 \ --bs1M --size20G --numjobs4 --rwwrite \ --group_reporting --runtime120 --time_based \ --filename/mnt/ceph/testfile_seq逻辑说明--direct1绕过页缓存测的是真实落盘性能--numjobs8模拟 8 个并发客户端--runtime120 --time_based让任务跑满两分钟而不是写完固定大小就停。JSON 输出方便后续用脚本提取iops和clat百分位。参数说明4K 随机写 IOPS 低于 5000 的存储池跑数据库类业务会非常痛苦1M 顺序写带宽低于 500MB/s 的池子不适合放镜像仓库。时延看clat的 99 分位超过 20ms 就要查网络或磁盘队列深度。2.3 管理网络与业务网络分离验证FusionCloud 部署规范要求管理、存储、业务三张网物理隔离或 VLAN 隔离。测试方法是在管理网用iperf3打流同时业务网跑虚拟机迁移观察管理网时延是否抖动。如果管理网和业务网混跑一次大规模迁移就可能让 API 超时控制台“假死”。# 管理网打流持续 60 秒 iperf3 -c 192.168.10.2 -t 60 -P 4 --logfile /tmp/mgmt_iperf.log # 同时在另一台机器触发虚拟机热迁移 nova live-migration --block-migrate vm-id target-host逻辑说明-P 4开四个并行流更接近真实管理流量。迁移过程中观察iperf3的retr重传次数如果重传超过 100 次说明管理网被业务流量挤占。参数说明管理网建议独立万兆存储网建议 25G 起步业务网按租户带宽需求规划。三网合一在测试环境可以凑合生产环境一定翻车。3. 虚拟化层测试虚拟机生命周期与热迁移的边界3.1 虚拟机全生命周期操作从创建到快照回滚虚拟化层测试要覆盖创建、启动、关机、重启、挂起、恢复、快照、回滚、删除九个动作。每个动作都要验证元数据一致性比如删除虚拟机后端口是否释放、卷是否解绑、安全组规则是否清理。我一般用openstack命令行批量跑配合watch观察资源状态。# 创建一台测试虚拟机 openstack server create --flavor m1.medium --image cirros \ --nic net-id$NET_ID --security-group default test-vm-01 # 等待 ACTIVE 后创建快照 openstack server image create --name test-vm-01-snapshot test-vm-01 # 回滚用快照重建一台新虚拟机 openstack server create --flavor m1.medium --image test-vm-01-snapshot \ --nic net-id$NET_ID test-vm-01-restore # 删除原虚拟机检查端口和卷是否释放 openstack server delete test-vm-01 openstack port list --server test-vm-01 # 应返回空逻辑说明快照回滚不是“恢复原机”而是用快照镜像新建一台。测试时要确认新机的 MAC 地址、IP 地址是否冲突。删除后port list必须为空否则说明 Neutron 有残留后续创建同 IP 虚拟机会失败。参数说明--flavor指定规格--image指定镜像--nic指定网络。如果创建卡在BUILD状态超过 5 分钟查nova-compute日志和 RabbitMQ 队列积压。3.2 热迁移测试带块迁移和不带块迁移的差别热迁移是私有云的高频操作也是测试重点。不带块迁移要求虚拟机磁盘在共享存储上迁移只传内存状态带块迁移会把磁盘一起搬耗时长但支持本地盘。测试时要分别验证迁移时长、业务中断时间、迁移后网络连通性。# 不带块迁移共享存储场景 time nova live-migration vm-id target-host # 带块迁移本地盘场景 time nova live-migration --block-migrate vm-id target-host # 迁移过程中持续 ping 虚拟机 ping -i 0.2 vm-ip | tee /tmp/migration_ping.log逻辑说明time记录迁移总耗时ping -i 0.2每 200ms 发一个包统计丢包数和最大中断时长。不带块迁移的中断通常小于 200ms带块迁移可能达到数秒。参数说明迁移并发数默认是 1大规模集群可以调nova.conf的max_concurrent_live_migrations但不要超过存储带宽的承受能力。迁移超时参数live_migration_timeout默认 300 秒跨机房迁移要适当调大。3.3 多租户隔离验证安全组、配额与 VLAN 隔离多租户是私有云的核心价值测试要验证租户 A 的虚拟机无法访问租户 B 的虚拟机租户 A 的配额用尽后无法继续创建资源不同租户的 VLAN 不能互通。# 租户 A 创建虚拟机和网络 openstack --os-project-name tenant-a server create ... openstack --os-project-name tenant-a network create tenant-a-net # 租户 B 尝试 ping 租户 A 的虚拟机应该不通 openstack --os-project-name tenant-b server create ... # 在租户 B 的虚拟机内执行 ping tenant-a-vm-ip # 预期 100% packet loss # 配额测试把租户 A 的实例配额设为 1再创建第二台 openstack quota set --instances 1 tenant-a openstack --os-project-name tenant-a server create ... # 预期报 QuotaExceeded逻辑说明租户隔离依赖 Neutron 的 VLAN/VXLAN 隔离和安全组默认拒绝规则。如果租户 B 能 ping 通租户 A说明底层网络隔离失效这是严重安全漏洞。参数说明配额包括实例数、CPU 核数、内存、卷、浮动 IP 等。测试时要逐项打满确认报错信息清晰。安全组默认规则是入方向全拒绝出方向全允许测试时要验证默认规则是否生效。4. 云服务层测试API、镜像与编排的可靠性4.1 API 网关压测并发创建虚拟机的极限在哪FusionCloud 对外提供 REST API测试时要模拟多用户并发调用。我一般用locust或wrk压nova创建接口观察 API 响应时间和错误率。# locustfile.py并发创建虚拟机 from locust import HttpUser, task, between class CloudUser(HttpUser): wait_time between(1, 3) token None def on_start(self): # 获取 token resp self.client.post(/v3/auth/tokens, json{ auth: {identity: {methods: [password], password: {user: {name: admin, password: password, domain: {name: Default}}}}}} ) self.token resp.headers[X-Subject-Token] task def create_server(self): self.client.post(/v2.1/servers, headers{ X-Auth-Token: self.token}, json{server: {name: load-test-vm, flavorRef: m1.small, imageRef: cirros-id, networks: [{uuid: net-id}]}} )逻辑说明on_start只执行一次获取 tokentask每次请求都创建虚拟机。压测时要监控nova-api的 CPU 和数据库连接数找到拐点。参数说明并发用户数从 10 开始每 5 分钟加 10直到错误率超过 1%。记录此时的 TPS 和 P95 响应时间。如果数据库连接池打满调nova.conf的max_pool_size。4.2 镜像服务测试上传、下载与格式转换Glance 镜像服务测试要覆盖 qcow2、raw、vmdk 三种格式的上传下载以及镜像元数据是否正确。大镜像上传要测分片和断点续传。# 上传 qcow2 镜像 openstack image create --disk-format qcow2 --container-format bare \ --file cirros.qcow2 --public cirros-test # 下载并校验 MD5 openstack image save --file /tmp/cirros-download.qcow2 cirros-test md5sum cirros.qcow2 /tmp/cirros-download.qcow2 # 应一致 # 格式转换qcow2 转 raw qemu-img convert -f qcow2 -O raw cirros.qcow2 cirros.raw逻辑说明MD5 校验确保镜像传输无损。格式转换用于性能敏感场景raw 格式没有元数据开销但体积更大。参数说明--disk-format必须和实际文件格式一致否则创建虚拟机会失败。--container-format bare表示无容器封装。大镜像上传超时调glance-api.conf的client_socket_timeout。4.3 编排服务测试Heat 模板的创建与回滚Heat 编排测试要验证模板语法、资源依赖、创建失败后的回滚。我一般写一个包含网络、子网、虚拟机、浮动 IP 的模板故意在中间步骤制造错误观察是否回滚干净。# test-stack.yaml heat_template_version: 2018-08-31 resources: test_net: type: OS::Neutron::Net properties: name: test-net test_subnet: type: OS::Neutron::Subnet properties: network: { get_resource: test_net } cidr: 10.0.0.0/24 test_vm: type: OS::Nova::Server properties: flavor: m1.small image: cirros networks: - subnet: { get_resource: test_subnet }逻辑说明get_resource建立依赖关系Heat 会按拓扑排序创建。如果test_vm创建失败Heat 默认回滚删除test_subnet和test_net。参数说明heat_template_version要匹配平台支持的版本。回滚策略由disable_rollback控制默认 false 即开启回滚。测试时要确认回滚后网络和子网确实被删除。5. 避坑与排查私有云测试中最容易翻车的五件事5.1 现象虚拟机创建成功但无法获取 IP原因Neutron 的 DHCP 代理没有正常运行或者 DHCP 命名空间没有创建。常见于新扩容的计算节点。解决登录网络节点执行neutron-dhcp-agent状态检查用ip netns查看 DHCP 命名空间是否存在。如果缺失重启neutron-dhcp-agent并检查dhcp_agent.ini的interface_driver配置。5.2 现象热迁移卡在 90% 后超时失败原因迁移过程中内存脏页率过高或者目标节点 CPU 不兼容。常见于虚拟机内存大于 16G 且业务写入频繁的场景。解决迁移前用virsh dommemstat看脏页速率如果超过 100MB/s先暂停业务或改用块迁移。CPU 不兼容查nova.conf的cpu_mode统一设为host-passthrough。5.3 现象Ceph 存储池 IOPS 远低于预期原因副本数设为 3 但只有 2 个故障域或者网络 MTU 不一致导致分片重传。解决ceph osd tree确认故障域分布ceph osd pool get pool size确认副本数。网络 MTU 用ping -M do -s 8972测试全链路必须一致。5.4 现象API 并发创建虚拟机时报 503原因nova-api的 worker 数不够或者数据库连接池打满。解决调nova.conf的osapi_compute_workers为 CPU 核数的一半max_pool_size调到 50 以上。同时检查 RabbitMQ 是否有消息积压。5.5 现象租户配额已满但资源实际未使用原因删除虚拟机时卷或浮动 IP 未释放导致配额计数虚高。解决openstack quota show tenant对比实际资源列表用openstack server list --all-projects和openstack volume list --all-projects找出残留资源手动清理后重置配额。6. 进阶验证用混沌工程给 FusionCloud 做故障注入前面五章把功能、性能、隔离都测完了但真实生产环境的故障往往来自“意料之外”。我一般会在验收前做一轮混沌工程主动注入故障看平台的自愈能力。这一步不是必选项但做过之后上线心里踏实很多。6.1 用 ChaosBlade 注入节点宕机和网络延迟ChaosBlade 是国内常用的混沌工程工具支持物理机、容器、网络多种场景。在 FusionCloud 测试中我主要用三个实验随机杀nova-compute进程、给存储网注入 100ms 延迟、模拟管理网丢包 10%。# 安装 chaosblade wget https://chaosblade.oss-cn-hangzhou.aliyuncs.com/agent/github/1.7.0/chaosblade-1.7.0-linux-amd64.tar.gz tar -zxvf chaosblade-1.7.0-linux-amd64.tar.gz cd chaosblade-1.7.0/ # 实验一杀 nova-compute 进程 ./blade create process kill --process nova-compute --local # 实验二存储网注入 100ms 延迟 ./blade create network delay --interface eth1 --time 100 --local # 实验三管理网丢包 10% ./blade create network loss --interface eth0 --percent 10 --local # 销毁实验 ./blade destroy experiment-id逻辑说明process kill模拟计算节点服务崩溃观察虚拟机是否自动迁移到其他节点。network delay模拟存储网抖动观察虚拟机 IO 是否挂起。network loss模拟管理网丢包观察 API 是否重试成功。参数说明--interface指定网卡--time单位毫秒--percent是丢包百分比。实验前一定要在测试环境做生产环境慎用。每个实验都要有明确的观察指标和回滚方案。6.2 验证自愈虚拟机 HA 和存储副本重建注入故障后重点看三个指标虚拟机是否在 60 秒内自动重启或迁移、存储副本是否在 5 分钟内重建到 3 副本、API 错误率是否在 1 分钟内恢复。# 观察虚拟机 HA 状态 watch -n 5 openstack server list --all-projects -c ID -c Name -c Status -c Host # 观察 Ceph 副本重建 watch -n 10 ceph -s | grep -E health|recovery|degraded # 观察 API 错误率 tail -f /var/log/nova/nova-api.log | grep -E ERROR|503逻辑说明watch每 5 秒刷新一次观察状态变化。Ceph 的degraded数量应该先升后降最终回到 0。API 日志中的 ERROR 应该在故障注入停止后 1 分钟内消失。参数说明HA 的触发时间由nova.conf的ha_interval控制默认 30 秒。存储副本重建速度受osd_recovery_max_active影响测试时可以适当调大加快重建生产环境要平衡重建速度和业务性能。6.3 一个具体技巧用 Prometheus 记录故障前后的黄金指标混沌工程不能靠肉眼观察我一般会提前部署 Prometheus 和 Grafana记录四个黄金指标延迟、流量、错误、饱和度。故障注入前后各截一张图对比曲线变化。指标采集方式正常范围故障阈值API P95 延迟nova-api 日志 500ms 2s虚拟机创建成功率自定义 exporter 99% 95%存储 IOPSCeph exporter基线 ±20%低于基线 50%管理网丢包率node_exporter 0.1% 1%逻辑说明这张表是我做验收时的“后悔药”每次故障注入后对照阈值判断平台是否合格。如果某个指标在故障停止后 5 分钟还没恢复说明自愈机制有缺陷必须在上线前修掉。参数说明Prometheus 采集间隔建议 15 秒Grafana 看板要提前配好。自定义 exporter 可以用 Python 写暴露/metrics接口即可。做完这一轮混沌工程我对 FusionCloud 的脾气基本摸清了。我的习惯是每次交付前至少做三次故障注入每次换不同的节点和不同的故障类型直到平台在故障下的表现稳定可预期。希望帮到你。本文还有配套的精品资源点击获取