李赣华，董黎，邰能建，夏克强，邰文星，高亚瑞玺

(1.国家宇航动力学实验室，陕西 西安 710043；2.西安卫星测控中心，陕西 西安 710043)

0 引言

近几年来，随着我国商用航天放开，在轨航天器数量迅猛增长，尤其是民商航天器数量飞速增长，面向未来发展需要，为了具备高可靠的航天器地面控制和管理能力，建设高可靠的航天数据处理中心是所有卫星用户关注和影响航天器应用的关键，面对卫星在轨管理、卫星运控、地面设备资源管理等多任务并行运行，地面系统不同代协同运行、异地多中心分布式部署、不同专用任务分离、软件系统与硬件平台解耦合、平台资源充分复用、系统高可靠运行能力等问题对中心系统架构提出了大量优化问题，设计合理的航天数据处理中心架构模型是有效解决这些问题的技术手段[1-2]。

1 国内外现状分析

1.1 国外现状

美国测控中心体系结构复杂，各中心因职责分工不同，体系架构也存在差异。为了适应未来太空联合作战的发展需要，各中心面临着转型和新老设备的更新换代问题。美国联合空间操作中心的思想理念较其他测控中心而言略有不同，也代表了美国测控中心体系建设的发展方向，JspOC 的体系架构是其中的代表[3-5]。

美国航天中心系统发展动向[6-8]：(1)加强资源的调度管理。NASA 和其领导下的航天跟踪与数据网(STDN)、深空测控网(DSN)两大主要测控系统共同负责对超过100颗的各种类型卫星和其他航天器进行管理。同时，克罗拉多州立大学、美国空军技术学院等多所大学和科研机构长期研究航天测控资源的调度管理。(2)推进大数据中心建设。针对目前美国任务系统，各任务数据系统存在多管道网络、低精度的用户数据入口限制、信息区隔、一般协议/标准/格式的缺乏、数据量无限增加导致的信息超负荷、数据确认和网络安全[2，9]、有限的传输带宽、成本高昂、设计无扩展性的缺陷。美国将进一步推进“大数据”建设，使数据可见、可信、可解、可被互操作、可以被获取。(3)对中心系统进行现代化改造。美国航天提出一种可扩展或“兼容式”航天中心框架结构，该框架以哥达德航天飞行中心的指挥控制框架——哥达德任务业务发展中心(Goddard Mission Services Evolution Center，GMSEC)为基础，作为共享的基础设施，如图1 所示，在其上可以根据专项任务研制添加任务专用组件，从而可以利用通用控制业务获得操作的灵活性，并提供互操作能力和态势感知能力。(4)进一步整合航天任务网络。美国已经在NASA 的天基网、近地网和军方卫星控制网之间利用CCSDS SLE 开展了一些互操作的实验。随着空国卫星控制网等其他卫星地面网的软硬件设备的更新换代和标准化与互操作措施的实施，以及NASA 正在进行的三网合一，美国航天测控资源的综合利用有望取得进一步进展。

图1 GMSEC 框架

欧洲航天中心系统发展动向：(1)发展全IP 化的通信网。ESA 通信网中，ESACOM、OPSNET 都随着技术的发展通过网络现代化转变成为IP 网，而IGS 自建设之初就采纳IP 协议，未来更将提供“全IP”业务，随着更多的航天器任务(包括机器人和载人)，整个航天通信系统将演进为一个由交换节点和和终端系统构成的网络，该网络支持容延迟网络(DTN)想定，数据、语音和视频业务都可以无缝地交织在一起，非常类似于现在地面上的互联网。(2)更换新的测控处理器。ESA 已经开发了几代多任务的测控处理器，未来的任务会提出一些新的要求包括：用于delta-DOR 的远单音；宽带测距和再生伪码测距；更易于进行重新配置的能力；获得非常低的Eb/N0 信号的能力；接收机的自主操作；高达600 Mb/s 的数据速率；先进的调制方案等。系统架构如图2 所示。

图2 ESA 中心体系架构示意图

1.2 国内现状

随着航天事业的快速发展，我国组建了多个航天任务管控中心，包括测控中心、飞行控制中心和各类卫星系统运控中心等，都属于航天数据处理中心，其职责分工各不相同，建设思路、体系架构[10-12]存在差异，整体使用和建设效益有待提升，存在的主要问题有以下几点。

1.2.1 资源复用能力低

(1)系统间资源无复用。当前，我国的航天任务系统功能相近，部分系统的子系统均有建设，但因系统体系架构存在差异，各中心独立运行，硬件资源不能相互支持，存在重复建设、硬件资源冗余的现象。

(2)单机资源利用率低。各任务中心内部系统的硬件资源综合利用率并不高。有的中心除了部分系统服务器CPU 资源消耗较高外，其余系统服务器资源使用率普遍较低，通常CPU 使用率低于20%。

(3)使用策略限制资源利用率。各系统为了提高可靠性普遍采用主备机的运行模式，备机在大多数情况下都是在做着与主机几乎完全相同的工作，对于备机的资源没有充分利用。

1.2.2 系统灵活性不足

航天数据处理中心软件系统与所运行的计算机的硬件配置关联过强，缺乏动态分配和灵活迁移的能力。这样就造成了相关的软件系统不仅在安装配置时过于复杂，首次进行系统安装时很难实现一键式的快速安装，需要大量的人工配置。一旦系统配置完毕，无论是添加新硬件设备还是硬件发生故障时的恢复，相关的软件系统都缺乏有效的应对能力。这间接造成了当前中心系统复杂的网络结构和硬件配置。

2 系统架构设计总体方案

2.1 多中心异地部署并行系统体系设计

未来保证航天器的安全稳定运行，防止水灾、地震以及人为误操作等带来的中心系统失能的问题，航天地面数据处理中心需要建设不同地点部署的多备份中心系统。本文面向多中心并行运行体系架构，通过分布式部署多处理系统，形成热备模式的多系统高可靠运行能力，具备为不同省市航天业务需求提供灵活航天业务服务的能力。

航天数据处理中心可以由任务规划、消息通信、卫星在轨服务、地面设备资源调度管理、开发验证等系统组成，系统架构和网络连接如图3 和图4 所示，其中消息通信系统是中心系统对外进行信息交换和提供服务的统一进出口，同时完成协议转换、数据预处理、时间同步和信息分发等功能；任务规划、卫星在轨服务、地面设备资源调度管理内部各自建立自己的信息收发子系统，负责与消息通信系统进行信息交换和自己系统内部子系统间的信息交换；开发验证系统主要包括开发测试、仿真等功能。

图3 航天数据处理中心内部系统网络连接示意图

图4 航天数据处理中心架构示意图

航天数据处理中心通过内部专网、外部专网、互联网等网络，与不同级别的用户以及内部专用系统进行信息交互。

2.2 国产云平台端应用设计

2.2.1 虚拟机云与容器云协同工作设计

云技术[13-14]主要分为两种：虚拟机云和容器云。两者各有优势：虚拟机云发展时间长，技术成熟，虚拟机之间的隔离性更好；容器云技术新颖，量级轻，效率高，易于迁移备份。在研究中发现由于不同功能的测控软件的性能需求不同，迁移需求不同，造成不同的软件适用的云技术可能不同。例如，容器更适合运行单一进程，容器不适合存储日志信息等。因此，需要在服务器集群上同时实现虚拟机云和容器云，这两种云需要协同工作。

2.2.2 云平台间的虚拟机和容器迁移设计

基于国产云平台的端应用设计如图5 所示，对于虚拟机云来说，虚拟机在不同的航天系统云平台上迁移，对不同航天任务系统云的Host OS 的一致性要求不高，当采用的Hypervisor 技术一致时，虚拟机本身就能保证其跨云迁移的适应性。对于容器来说，容器在运行时需要使用Linux 系统的内核，因此需要保证云平台上的Docker 容器做成镜像，通过数据转发节点的传输网络，跨越云平台完成传输、迁移后，能够正常使用目的云平台的Linux 内核并正常执行。要完成这一点，需要保证两个云平台的Linux 内核差异不要过大，保证上述迁移过程能正常进行。同时，为保证相互备份的两个系统云平台能够在必要的时候运行对方的虚拟机或容器，需要有一套镜像交互机制，使得所有系统中各自最新版本的镜像信息都能够在不同系统内保留副本，以便当本地遭遇灾害时，另一个系统的云平台能够迅速加载本方镜像并启动运行，并在共同的数据转发节点和设备条件下，完成所有航天器的航天业务实施。

图5 基于国产云平台的端应用设计

3 系统架构设计相关技术和方案研究

下面通过以下相关技术的研究，开展航天数据处理中心架构设计。

3.1 在线运行下的系统切换

3.1.1 云技术实现

传统虚拟机云架构包括基础设施即服务(Infrastruction as a Service，IaaS)、平台即服务(Platform as a Service，PaaS)、软件即服务(Software as a Service，SaaS)三层服务，如表1所示。

表1 IaaS、PaaS、SaaS 间的层级架构关系

随着云平台使用方式的发展，IaaS 以虚拟机为粒度，向用户提供资源的方式逐渐不能满足用户的需求。虚拟机的资源提供方式存在资源利用率低、调度分发缓慢、软件环境不统一等问题。PaaS 在IaaS 基础上发展而来，但PaaS 在应用架构选择、支持的软件环境服务方面有较大的限制，这带来了应用与平台无法解耦、应用运行时环境局限性强等问题。容器云解决了传统IaaS+PaaS方式存在的上述问题，提供了资源利用率高、镜像小、调度分发迅速、无需关注不同虚拟机之间开发环境差异的云计算资源利用、开发方式，提高了用户体验。容器云用Docker Engine 完成了资源的虚拟化，同时避免了在Host OS 的用户空间中再嵌套运行一个Guest OS 的设定，而是直接让容器使用Host OS 内核，这样避免了系统运行两层OS 带来的开销，提高了效率，但带来的副作用是，容器云中容器之间的隔离性要弱于虚拟机云中虚拟机之间的隔离性。需要在研究中评估容器云和各类航天应用软件的适配性，是否能够在性能和稳定性上得到良好的效果。

3.1.2 虚拟机云+容器云的协同部署

从3.1 节可以得出结论：在服务器集群上需要同时部署虚拟机云和容器云，并且这两种云需要协同工作。一些涉及大量IO 操作的工作可能并不适合在虚拟机上实现，因为性能较低，那么这些工作可能会在容器云中获得更好的效果；一些强调隔离性的软件最好部署在不同的虚拟机上，以充分利用虚拟机更强的隔离能力；一些日志记录软件会持续产生逐渐膨大的输出文件，不适合在容器中执行等。所以，两种云平台需要被同时使用。

3.1.3 航天应用软件的封装与迁移方案

首先，需对航天应用软件的隔离封装技术进行研发。云技术将服务器虚拟化为大量的虚拟机和容器，供航天应用软件执行。虚拟机和容器大规模的数量为应用隔离提供了可能性。以前各个任务的进程都运行在同一台服务器上，这就导致无法进行隔离。某个任务的进程出现问题，可能会影响其他任务进程的正常运行，甚至导致服务器状态异常进而需要重启，影响所有任务。另外，将某个任务的进程组迁移到其他机器上，需要人工参与，便利性和安全性不高。现在，虚拟机和容器数量多了，就可以以虚拟机或容器为单位，方便地将不同任务或不同功能的进程装进不同的虚拟机或容器中，完成进程之间的隔离。

对于虚拟机云，以虚拟机为箱体，封装任务软件，十分便捷，但需要权衡好每个虚拟机中封装软件的数量，防止虚拟机过多导致虚拟机本身的开销远大于航天应用软件的运行开销。对于容器云，直接用容器为箱体封装任务软件也易于实现，但是需要突破容器一般用来封装单个进程这种典型使用方法。探索如何在容器中封装多个进程，并研究一套进程控制机制，有效地控制容器内各个进程的执行是很有必要的。

其次，需对航天应用软件的迁移技术进行研发。对航天应用软件进行封装，可以限制软件故障的影响域，还利于软件运行时环境的备份、重启、迁移。在实际应用中，以镜像方式对虚拟机和容器进行固化备份后，还涉及镜像的存储和迁移问题。现有的云技术都可以较好地完成本地的迁移重启工作，但由于需要进行多中心相互支持、相互抗毁的能力，还需要一套良好的跨中心的镜像共享备份方式。当某个中心出现故障时，确保其他中心能够顺利运行故障中心共享出来的虚拟机和容器的镜像，从而顺利接管故障中心的任务。因此，要针对下列问题开展研究：如何设计航天应用软件的架构，避免镜像中软件产生的输出文件、日志等改变镜像本身，尽可能使镜像内容固件化，避免镜像内容频繁更动导致其需要频繁地在中心之间传输；如何让镜像文件尽可能地小，以便与存储和传输；通过何种方式，让镜像文件高效低耗地跨中心传输。

3.1.4 主用中心与备用中心的切换机制

为了各个中心可以相互支持、备份，达到抗毁目的，不同中心的云平台设计应当是互相兼容的。一个云平台上运行的虚拟机和容器镜像，放到另一个云平台上也可以正常执行。对于一个任务，与其相关的镜像应该在多个云平台中都可以执行，但是同时只能有一个主用中心具有发送上行的权限，其他中心都是备用中心。一个任务的主用中心可以在各个中心之间进行切换，切换有主动切换和被动切换两种。

主动切换由操作人员在端中进行操作，通过客户端或浏览器，选定新的主用中心，然后完成主用中心和备用中心的切换。需要注意的是，业务切换之前，需保证新的主用中心能够得到该任务的航天数据，同时也能够得到该业务的管控数据(包括虚拟机或容器镜像、配置信息、任务状态信息等)。

被动切换是由任务的主用中心出现故障或被损毁而引发的。对于每个任务，各个备用中心应该有一个优先级，一旦主用中心发生故障或损毁，就在优先级最高的那一个备用中心启动任务，作为新的主用中心，同时新的主用中心向数据分发节点注册该任务的航天数据。

3.2 高可用的数据管理

3.2.1 数据中心与分发节点的数据注册技术

数据分发节点连接了各个测站、各个航天数据处理中心，并在这些测站和中心之间完成数据的转发。航天数据的下传和上传需要通过数据分发节点。因此需要研究高效的航天数据转发机制，确保只给有需要的方向发送数据，防止数据的重复发送、无效发送。整个系统结构中，数据在测站和各个中心之间的转发关系应当和消息中间件转发消息的模式类似，而数据分发节点扮演的角色是消息中间件体质中的数据转发服务器。

3.2.2 系统高可用性技术

基于底层的虚拟化技术，研究其虚拟机热迁移，通过对内存迁移算法及内存压缩技术的研究实现迁移的高效性。在虚拟环境下设置主备虚拟机，在备节点上创建主虚拟机的完整拷贝，包括CPU 状态、内存、磁盘操作、QEMU 等都进行低延迟的定时同步。备节点虚拟机处于热备状态，定时检测主节点虚拟机心跳，在指定时间内收不到心跳即认为异常发生，备虚拟机切换到正常运行状态，实现虚拟机热备份。

通过动态在线给虚拟机增加或减少VCPU、虚拟内存、虚拟磁盘等虚拟资源数量，来实现虚拟机计算资源的动态分配，进一步提高系统的扩展性。通过实时数据同步，实现虚拟机内存快照技术，不中断用户的业务，实现虚拟机内存状态的备份，提高系统的高可用性。

3.3 安全防护的运维管理

3.3.1 设计Master/Agent 分布式监控管理架构

采用Master/Agent 分布式系统架构，其中Master 支持热备部署，主要用于系统信息的集中式管理及提供Web服务，Agent 分布式部署到各集群节点，负责信息的采集及系统的管理。每个Agent 均具备全部管理功能，脱离Master 可独立运行，进而实现系统的可用性、可靠性及可扩展性。

采用基于Agent 的系统监控技术，通过Agent 的组件化，开发不同的Agent 实现多种系统信息的自动化采集。通过设计根据用户容忍度和监控状态智能切换推送或拉取的推拉互补算法，实现对不同数据类型、不同采集频率，智能提供数据采集方式。

前期分析研究了RBAC 技术，拟攻克当前应用的RBAC访问控制模型关键技术，设计出适应卫星管控云的角色访问控制模型，实现基于Agent 的任务管理、权限管理等模块，进而实现对用户的管理。

3.3.2 用户分离的虚拟桌面

首先通过在云平台基础设施上构建基于主流虚拟化解决方案的基础云平台，在基础云平台之上进行功能扩展，构建虚拟资源管理系统，如图6 所示。虚拟资源管理系统可动态添加、删除组，并提供虚拟资源管理、配额限制、安全认证、策略、调度、缓存等子模块。多模块间采用松耦合设计，可选择开启或关闭子模块，提供各种能力组合。通过多重防御策略管理风险，以便在一层防御不够时管理风险，利用其他层次防御化解破坏，从而阻止完全破坏整个虚拟桌面系统。采用多种安全技术手段，在每一层执行不同粒度的安全性策略，确保单层的无安全死角，不遗漏任何破坏风险。

图6 一体化高安全虚拟桌面技术路线图

3.3.3 云平台数据安全交换及监管技术

在敏感数据智能发现方面，定制优化深层神经网络等机器学习算法对图像、视频等非结构化数据内容进行特征匹配，实现敏感内容的智能识别。在数据智能脱敏方面，通过对数据库以及各类文档、图像进行内容提取、规范化，并采用不可逆哈希创建数据指纹，形成面向特定行业的敏感信息内容索引，从而支撑高效准确的数据脱敏。最终，形成制定脱敏规程、发现敏感数据、定义脱敏规则、执行脱敏工作、验证脱敏成效的完整数据脱敏体系，如图7 所示。

图7 数据脱敏方法

数据安全监管技术基于数据挖掘及机器学习技术，通过收集对象存储系统、云数据库、共享交换平台的数据使用和交换记录、元数据信息、数据授权信息等数据安全事件，利用海量日志分析和机器学习方面，提供数据使用合规性审计、数据使用规律分析、数据使用异常监测和可视化展示功能，评估数据风险态势，帮助掌控全局数据安全状态，及时响应重要数据泄露、越权使用风险。

4 结论

本文以航天数据处理中心系统建设和应用为背景，通过统一的系统设计，提出了一个多中心、多任务、多功能的三层架构设计的航天数据中心系统，从高可靠的系统备份、数据管理、软件运行、平台运维等多个方面介绍了基于云平台的复杂系统架构。经过多个备份中心以及容灾中心系统并行运行，并对航天器和地面设备的管理应用，本文提出的系统能够保持不同航天器型号任务的热备运行能力，具备较强的统一运维和安全防护能力，能保持多年长期的高可靠稳定运行，可为其他航天数据处理中心以及商业航天任务中心的架构设计和构建提供技术支持。