当前位置：首页 > news >正文

从PXE安装到VNC登录：图解FusionSphere OpenStack网络流量到底怎么走的？

news 2026/6/7 2:55:55

从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

资源层对接（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共用物理链路