企业官网建设流程全解析

从一次VNC登录故障看FusionSphere OpenStack网络平面流量路径

凌晨三点，运维工程师小李被紧急告警惊醒：某金融客户核心业务系统无法通过VNC登录虚拟机。这个看似简单的故障背后，隐藏着FusionSphere OpenStack复杂的网络平面交互体系。本文将带您深入故障现场，拆解流量在八个关键网络平面中的完整旅程。

1. 故障现象与初步定位

客户尝试通过ServiceCenter控制台使用VNC连接虚拟机时，持续收到"连接超时"错误。常规检查显示：

• 虚拟机状态为"运行中"
• 计算节点资源充足
• 网络设备无丢包告警
• VRM服务状态正常

关键排查步骤：

1. 在SC节点执行telnet <VRM_IP> 8080测试端口连通性
2. 检查noVNC代理服务日志发现错误：

   ERROR [nova.console.websocketproxy] Failed to connect to compute node: 172.28.1.23

3. 跟踪API请求路径：

   curl -X POST http://<External_API_VIP>/v2.1/servers/<uuid>/remote-consoles

注意：VNC登录涉及至少5个网络平面的协同工作，任何平面间的通信中断都会导致故障

2. 网络平面流量路径全解析

2.1 DMZ_Service平面：用户请求入口

作为整个流程的起点，DMZ_Service平面承载着用户初始请求。该平面的关键特性：

当用户在SC界面点击"远程登录"时：

1. 浏览器向https://sc.demo.com:443发起HTTPS请求
2. LVS负载均衡器将请求分发到Nginx集群
3. Nginx反向代理将请求转发到noVNC服务

常见故障点：

• SSL证书过期
• LVS健康检查失败
• ACL规则阻断443端口

2.2 Public_Service平面：内部服务枢纽

流量离开DMZ后进入公共服务平面，这里部署着关键中间件：

• Haproxy：负责API路由
• GaussDB：存储会话信息
• RabbitMQ：消息队列服务

该平面的特殊设计：

• 不与外网直接互通
• 采用VXLAN overlay网络
• 要求<5ms的网络延迟

故障排查时可关注：

# 检查RabbitMQ队列状态 rabbitmqctl list_queues | grep nova # 验证数据库连接 mysql -h <DB_VIP> -uconsole -p -e "SHOW STATUS"

2.3 External_API平面：南北向流量通道

作为内外网络的分界线，External_API平面承担重要转换功能：

1. 正向代理（内部访问外部）：

   graph LR A[Nova] --> B[API Gateway] B --> C[Internet]

2. 反向代理（外部访问内部）：

   graph RL D[User] --> E[nginx] E --> F[Nova-API]

配置要点：

• 必须配置Trunk允许管理VLAN通过
• 建议启用TCP keepalive
• 需要独立的安全组规则

2.4 Internal_Base平面：内部通信骨干

二层隔离的Internal_Base平面是OpenStack组件的"神经系统"：

• PXE安装：使用172.28.0.0/20网段
• 组件通信：Nova-Cinder交互等
• 安全特性：
  • 无默认网关
  • 禁止三层路由
  • 默认拒绝所有入站流量

故障案例：某次升级后，计算节点无法与控制节点通信，最终发现是交换机误配置了VLAN过滤。

3. 关键平面交互原理

3.1 External_OM平面的双重角色

作为资源接入平面，External_OM需要：

1. 对接异构虚拟化平台（KVM/VMware/FC）
2. 提供VNC代理通道
3. 承载RabbitMQ通信

流量路径示例：

noVNC代理 -> External_OM -> VRM -> 计算节点

提示：该平面需要与CNA管理网络三层互通，但应限制安全组规则

3.2 存储平面的特殊考量

当后端使用KVM时，Storage_data平面表现出独特特性：

• 对接IP SAN：需要成对平面（data0/data1）
• 对接FusionStorage：仅需单个平面
• 带宽要求：
  • 机械盘：≥10Gbps
  • 全闪存：≥25Gbps

典型配置错误包括：

• MTU不匹配（应统一为9000）
• 多路径软件未正确安装
• VLAN标签配置错误

4. 实战排错指南

4.1 网络连通性测试矩阵

建立平面间连通性检查表：

4.2 典型故障处理流程

针对VNC登录故障的标准处理流程：

1. 用户端验证：

   # 检查浏览器控制台错误 chrome://net-export/

2. 服务链追踪：

   from keystoneauth1 import session sess = session.Session(auth=...) sess.get('.../remote-consoles')

3. 组件级诊断：
   • 检查nova-consoleauth日志
   • 验证VNC token有效性
   • 测试计算节点libvirt连接

4.3 性能优化建议

根据实际运维经验，推荐以下优化措施：

• 网络平面分离：

  # nova.conf [vnc] server_proxyclient_address = 172.28.1.100 novncproxy_host = 192.168.100.10

• QoS策略：

  # 为VNC流量预留带宽 tc qdisc add dev eth0 root handle 1: htb tc class add dev eth0 parent 1: classid 1:10 htb rate 500Mbit

• 高可用配置：
  • 部署多活noVNC代理集群
  • 启用VRM双机热备
  • 配置存储多路径

5. 架构设计最佳实践

5.1 网卡规划方案

针对不同服务器配置的推荐方案：

4网卡配置：

• 网卡1+2：绑定为管理+业务平面（主备模式）
• 网卡3+4：绑定为存储平面（LACP模式）

2网卡配置：

• 网卡1：管理+业务+存储（VLAN隔离）
• 网卡2：BMC专用

5.2 安全隔离策略

各平面应实施差异化安全控制：

5.3 监控指标体系建设

建议监控以下关键指标：

• 平面间延迟：各跳点RTT值
• 带宽利用率：峰值流量监控
• 错误计数：

  # 获取网卡错误包计数 ethtool -S eth0 | grep errors

• 服务健康状态：

  # 检查nova服务状态 nova service-list | grep down

在实际运维中，我们发现VNC登录故障约60%源于网络平面间的路由或安全策略配置错误。通过建立标准化的流量路径检查清单，可将平均解决时间(MTTR)从2小时缩短至15分钟。