从PXE安装到VNC登录：图解FusionSphere OpenStack网络流量到底怎么走的？
从PXE到VNC：FusionSphere OpenStack网络流量全链路解析
当一台裸金属服务器从PXE启动安装操作系统，到最终用户通过VNC远程登录虚拟机，这中间究竟经历了怎样的网络旅程？作为企业级云计算平台的核心组件，FusionSphere OpenStack通过精细划分的网络平面实现各功能模块的安全隔离与高效协作。本文将用流量追踪视角拆解关键业务场景下的数据流动路径，揭示每个操作背后隐藏的网络设计哲学。
1. 网络平面架构设计原理
在深入流量路径之前，需要理解FusionSphere OpenStack采用多平面网络架构的根本原因。与社区版OpenStack相比，华为的定制化方案通过8个核心平面实现功能解耦：
| 平面类型 | 典型网段 | 核心功能 | 安全等级 |
|---|---|---|---|
| Internal_base | 172.28.0.0/20 | 组件间通信、PXE安装 | 最高 |
| External_API | 用户自定义 | 外部API调用、管理入口 | 中 |
| External_OM | 用户自定义 | 资源接入、VNC代理 | 高 |
| Storage_data | 根据存储配置 | KVM场景下的存储连接 | 高 |
| BMC_Base | 独立规划 | 硬件管理(IPMI) | 最高 |
| 业务平面 | 租户VLAN池 | 虚拟机间通信 | 可变 |
| 管理平面 | 独立规划 | VRM与CNA通信 | 最高 |
| OM_Service | 用户自定义 | 跨Region运维管理 | 高 |
这种设计的三大优势体现在：
- 故障隔离：单个平面故障不会波及其他功能（如存储流量激增不影响管理通信）
- 安全分级：按数据敏感程度实施差异化的访问控制（如Internal_base禁止三层转发）
- 性能优化：专网专用避免流量竞争（如存储平面独立保障IOPS）
关键设计原则：物理网卡可复用，但每个逻辑平面必须配置独立VLAN标签。例如4网口服务器可采用两两绑定方式承载所有平面。
2. PXE安装阶段的网络流量
当管理员通过FusionSphere Director（FCD）部署新计算节点时，触发以下典型流量路径：
初始化连接（External_API平面）
- 管理员通过HTTPS访问FCD界面（DMZ_Service → Public_Service → External_API）
- 反向代理（Nginx）将请求转发至内部FCD服务
PXE启动流程（Internal_base平面）
# 在DHCP服务器上的配置示例 subnet 172.28.0.0 netmask 255.255.240.0 { option routers 172.28.0.1; # 实际部署中通常不配置网关 filename "pxelinux.0"; next-server 172.28.1.100; # TFTP服务器地址 }- 服务器网卡设置为untag模式接收PXE引导文件
- 流量特征：
- 纯二层通信（无VLAN tagging）
- 使用TFTP协议传输安装镜像
- 默认禁止跨网段通信（即使同属Internal_base）
组件安装阶段（External_OM平面）
- 安装程序通过该平面获取VRM、FusionStorage等组件包
- 典型交互：
- 从FusionCompute拉取虚拟化驱动
- 向FusionManager注册新节点
异常处理：若PXE阶段失败，需检查交换机端口是否配置为access模式（vlan id=pvid），并确认DHCP响应未被防火墙拦截。
3. 虚拟机创建流量链
用户通过ServiceCenter（SC）创建弹性云服务器时，网络流量呈现清晰的层级跃迁：
DMZ_Service → Public_Service → External_API → Internal_base → External_OM → 资源池关键阶段解析：
前端交互（DMZ_Service/Public_Service）
- 负载均衡器（LVS）将请求分发到SC集群节点
- 公共服务组件（如GaussDB）通过Public_Service平面验证配额
OpenStack核心处理（External_API/Internal_base）
- Nova-api接收创建请求后触发的操作序列：
# 简化版虚拟机创建流程 def create_instance(): nova_api.validate_request() # External_API neutron.allocate_network() # Internal_base cinder_api.attach_volume() # Internal_base nova_scheduler.select_host() # Internal_base nova_compute.start_instance() # External_OM
- Nova-api接收创建请求后触发的操作序列：
资源层对接（External_OM）
- 通过FC/SAN驱动在存储平面创建虚拟磁盘
- VRM执行实际的虚拟机启动操作
流量安全设计：
- 每个跃迁点都需经过双向证书认证
- 敏感操作（如磁盘挂载）强制使用TLS 1.2加密
- External_OM平面默认禁止直接外连，需通过跳板机访问
4. VNC登录的流量迷宫
用户发起VNC连接请求时，流量将穿越多个安全边界：
请求发起阶段
- 用户浏览器 → SC控制台（DMZ_Service）
- 控制台通过Public_Service平面获取会话令牌
代理中转阶段
graph LR A[External_API] --> B[noVNC Proxy] B --> C[External_OM] C --> D[VRM] D --> E[计算节点]（注：实际输出时应删除此mermaid图表，此处仅为说明流程）
鉴权与连接建立
- Consoleauth服务验证令牌有效性（Internal_base）
- 计算节点打开VNC端口（External_OM）
- 流量加密采用AES-256-GCM算法
排障要点：
- 若卡在连接初始化阶段，需检查External_API到External_OM的路由
- 突然断开通常源于会话超时（默认300秒无操作断开）
- 画面卡顿可能因OM平面带宽拥塞导致
5. 平面融合的实践权衡
虽然标准部署要求平面隔离，但实际场景中常面临资源约束。以下是三种典型融合方案的风险评估：
方案A：管理平面与External_OM合并
- 优点：减少网卡需求
- 风险：CNA被入侵可能导致控制节点沦陷
- 实施要点：
- 配置独立VLAN
- 启用严格的ACL策略
方案B：Storage_data与业务平面合并
- 适用场景：测试环境或小规模部署
- 性能影响：可能造成存储IOPS波动
- 配置示例：
# 在计算节点上绑定存储与业务流量 nmcli con add type team con-name team0-storage ifname team0 \ config '{"runner": {"name": "activebackup"}}' nmcli con add type vlan con-name vlan-storage dev team0 id 100
方案C：External_API与DMZ_Service共用物理链路
- 安全措施：
- 部署WAF防护Web攻击
- 启用DDoS清洗
- 流量限速策略
在最近某金融云项目中，我们采用方案A+方案C的组合，通过25Gbps网卡承载6个逻辑平面，关键控制措施包括：
- 每平面独立QoS策略（如OM平面保障最小带宽30%）
- 基于DPDK的流量监控
- 微隔离策略（每组件仅开放必要端口）