中南管制综合信息系统架构优化研究

摘要：本文首先就中南管制综合信息系统的重要性进行了简单介绍，随后对该系统在运维过程中出现的故障进行分析，提炼出目前系统架构上的不足，并尝试从基础网络、应用服务等方面给出优化建议，希望能为有此需求的技术人员提供一种解决思路。

关键字：管制综合信息系统 架构优化

一、引言：

当前，在航空管制类业务信息化发展的大背景下，中南管制综合信息业务迅速发展，目前已包括航班信息处理系统、塔台运行管理系统、协同决策系统、流量管理系统等共十多套信息系统（简称“管综系统”）。该系统目前不仅在广州本地部署，还延申至中南12个分局站。随着管综系统运维保障工作日趋重要，如何确保系统的稳定性，如何针对在运维维护过程中发现的问题持续地进行优化改进，这对设备运维人员提出了更高的要求。

二、故障描述及分析

（一）故障现象描述

某地管综系统的系统架构如图1所示，管综系统核心服务器群由刀框硬件组成，相关的功能服务模块安装在被VMware虚拟化后的刀片服务器中，虚拟机文件存放在刀框内的专用存储阵列；席位终端通过接入交换机连接访问位于刀框中的相关业务虚拟机；为了确保系统信息安全，管综系统与外部连接通过防火墙实现。

在设备定期维护过程中，技术人员分别重启两台核心交换机后，防火墙发生主备切换，但与此同时发现刀框内的部分虚拟机其上应用程序自动关闭。检查虚拟机系统日志和系统信息，发现虚拟机在维护期间发生重启；检查虚拟化平台，告警事件显示平台触发HA切换，导致部分虚拟机迁移重启。防火墙切换属于正常情况，但虚拟机的迁移重启则完全不符合维护预期。

（二）故障分析及解决方法

技术人员利用实验环境对此次故障进行模拟，由于异常情况主要集中在核心交换机和刀框，故搭建刀片服务器、存储阵列及外部网络的连接如下图所示：

经过测试验证，刀框内存储阵列与刀片交换机相连接的两条链路属于主备工作模式，同时只有一路在工作，因此刀片内的虚拟机访问存储有如下两条路径。

路径1：刀片内的虚拟机访问存储阵列只通过刀框内本地刀片交换机即可，此时外部核心交换机不参与服务器与存储之间的连接，在后续的测试中技术人员验证了重启刀框外部核心交换机不会影响使用这一链路的虚拟机。

路径2：刀片内的虚拟机访问存储阵列需通过刀框内刀片交换机以及刀框外部的核心交换机才能实现。当核心交换机重启时，通过路径2访问存储的虚拟机由于无法访问存储阵列，触发HA机制强制进行虚拟机迁移，导致部分虚拟机异常重启。

从以上我们可以发现，当刀框外部核心交换机重启切换时，由于存储阵列不知道刀框外部的网络状态变化，即使其存在主备链路但也无法及时做出切换操作。随后技术人员通过调整设置，在刀片交换机上将与存储阵列相连和与核心交换机相连的接口纳入同一监控端口组，当外部链路（与核心交换机连接）异常时，使刀片服务器及存储阵列同步动作，确保虚拟机访问存储阵列不会中断。从此次故障处理中我们发现，管综系统基础硬件设备之间冗余机制较多，耦合度高，如涉及到硬件故障切换经常需要多种设备配合才能完成。

三、管综系统的优化分析

（一）管综系统现状

施工故障处理完成后，技术人员没有满足于解决该故障本身，而是进一步从基础网络、应用服务等方面针对管综系统进一步研究。

1.管综系统的基础网络

上图为管综系统典型网络架构，从结构上看设备拓扑为“烟囱”式，其中存储阵列、刀片交换机（用于存储网络）、刀片服务器、刀片交换机（用于业务网络）、核心交换机、核心防火墙、接入交换机（用户接入）均存在冗余设计，从上面的故障处理我们发现设备间的切换经常需要上下游设备同步切换配合才能确保业务连续运行，设备间的耦合度高，对设备的稳定性以及技术人员的业务配置、故障处理等综合能力都提出更高的要求。

2.管综系统的应用服务

上图为管综系统典型应用数据流，从中我们可以看出，管综系统包含有多个服务模块，各模块间功能表面上看相对独立，但是从数据流我们可以看出各模块间数据互相引用较多，模块间耦合度高，一旦某一个功能模块异常，势必会影响其他功能模块的正常运行。

（二）优化建议

将现有管综系统上云，利用上云后的技术可使应用服务与基础设施资源之间进行解耦，以及应用内部不同功能模块间尽可能地解耦。

应用服务方面：

针对应用服务方面，按照云原生的方法进行优化。云原生并不是简单地使用云平台运行现有的应用程序，它是一种能充分利用云计算优势对应用程序进行设计、实现、部署、交付和操作的应用架构方法。

云原生的代表技术包括容器、微服务和不可变基础设施等。这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。

容器提供的方式是标准化的，通过该技术可以将管综系统不同应用程序的不同组件组装在一起，又可以将它们彼此隔离。

微服务是一种软件架构方式，我们使用微服务架构可以将一个大型应用程序按照功能模块拆分成多个独立自治的微服务，每个微服务仅实现一种功能，具有明确的边界。为了让应用程序的各个微服务之间协同工作，通常需要互相调用REST等形式的标准接口进行通信和数据交换，这是一种松耦合的交互形式。

云原生加速了应用与基础设施资源之间的解耦，通过定义开放标准，向下封装资源，将复杂性下沉到基础设施层；向上支撑应用，让开发人员更关注应用服务本身。

数据流方面：

根据《民航中南空管局网络安全和信息化专项发展建设规划》中的规划，中南空管云数据中心架构体系如图5所示。其中在云数据中心内会建立管理数据的共享服务平台，借助云数据中心中的管理数据共享服务平台，提取各业务系统数据，统一数据标准，通过数据计算和加工为用户提供数据服务，构建统一的数据体系，实现数据服务的可重用性。

按照云原生方式优化后的管综系统，各业务模块将尽可能只与数据共享服务平台发生数据交互，各业务模块之间将进一步解耦。

基础网络方面：

基础网络由针对传统园区网的三层网络架构转向针对数据中心、虚拟化、分布式应用等技术特点的叶脊网络架构。

随着云计算的发展，横向（East-West）流量在数据中心中占据主导地位，涵盖几乎所有的云计算、虚拟化以及大数据应用场景。虚拟化技术的应用、软件架构的解耦以及分布式应用的兴起，均会大大增加东西向流量。横向网络在纵向设计的网络拓扑中传输数据会带有传输的瓶颈，因为数据经过了许多不必要的节点（如路由和交换机等设备）。主机互访需要通过层层的上行口，带来明显的性能衰减，而三层网络的原始设计更会加剧这种性能衰减，这也就是为什么当前主流的三层网络拓扑结构越来越不能满足数据中心网络需求的原因。

如上图所示为叶脊网络架构的简单模型，SPINE和LEAF之间为全网状连接（Full Mesh），具有如下优势：

带宽利用率高：每个LEAF到SPINE的多条上行链路以负载均衡方式工作，充分的利用了带宽；

网络延迟可预测：在以上模型中，各LEAF之间的连通路径的条数可确定，均只需经过一个SPINE，东西向网络延时可预测；

高可用性强大：传统网络采用STP协议，当一台设备故障时就会重新收敛，影响网络性能甚至发生故障，SPINE LEAF架构中一台设备故障时，不需重新收敛，流量继续在其他正常路径上通过，网络连通性不受影响，带宽也只减少一条路径的带宽，性能影响微乎其微；

叶脊网络架构，适用于需要大范围资源共享或者虚拟机迁移的网络。

四、结语

综上所述，通过对现有管综系统故障的研究分析，技术人员发现了当前设备运维过程中系统架构的痛点，应用与基础设施耦合度高、应用内不同模块间耦合度高。管综系统上云，利用云计算基础架构、数据共享平台设计、容器与微服务等技术可以加速应用与基础设施资源之间、应用不同功能模块之间的解耦，从而进一步提高中南管综系统业务的稳定性。