美军战术云计算应用研究

程赛先

(江苏自动化研究所, 江苏 连云港 222061)

美军战术云计算应用研究

程赛先

(江苏自动化研究所, 江苏 连云港 222061)

云计算在商业领域得到了广泛应用,军事领域中的应用研究近年来也正在拓展。但在战术环境中,云计算的应用还存在一些问题。本文列举了美军在研的四种类型的战术云及其适用场景，并详细研究了战术小云的体系结构，小云供应模式以及小云的发现协议等内容，最后分析了美军战术云计算的研究现状和应用前景。

战术云; 云计算; 美军

云计算即互联网计算。它的名称来源于网络在拓扑图中常被表示成一朵云的形状。从本质上讲,云计算是一种动态分配共享资源的高扩展性计算模型。通过随需提供软件和硬件,云计算实现了计算的服务化。

战术云计算是指利用云计算技术和方法支持存续时间较短信息的本地化访问和本地化处理需求。战术云可以简单地定义为战术环境中可用的云计算能力。

1 战术云的类型

战术云有四种不同类型,分别是集中式战术云、非集中式战术云、小云和微云,它们适用于不同的应用场景,见图1。

1)集中式战术云。集中式战术云是云计算的原始形态,提供企业级服务。通常部署于后方指挥部、主作战基地或海军基地内。既可被本地设备访问,也可被远程设备访问。移动设备通过无线接入点或4G蜂窝网络访问,前沿作战基地或航母打击群则通过远程通信链路访问。它可以处理巨量且不断增加的情报侦察监视数据。2003年以来,美国防部、各军种所属数据中心陆续开展了大规模的合并融合。由于云计算技术的兴起,在融合和建设过程中大量采用了云计算技术,构成了若干集中式战术云计算中心。集中式战术云可以跨多个地理位置、多个数据中心。目前集中式战术云的非密、机密和绝密等安全域要分别实现。

美国防机构过去排他性地使用了常规数据中心来提供企业服务。如果使用集中式战术云,可以大幅降低成本、增强系统部署灵活性、解决数据的爆炸性增长带来的计算需求问题。

2)非集中式战术云。非集中式战术云通常部署在前沿作战基地或舰艇上。基地或舰艇附近的系统和设备可以直接访问该云。非集中式战术云的计算和冷却设备安装在一个单独集装箱内,易于部署。除了规模较小外,在很多方面与集中式战术云相似。非集中式战术云通常都是自给式独立系统,无须依靠远程通信链路,作战人员在本地处理情报侦察监视数据,分析师在本地分析情报数据。

虽然非集中式战术云解决不了远程通信链路的不确定性问题,但它通过本地处理、本地信息访问和本地决策,降低了不良影响。

(图例中，LAV:轻型装甲车； FOB:前沿作战基地； MOB:主作战基地； HQ:总指挥部； NB:海军基地； CVBG:航母打击群； UAV:无人机)图1 战术云的四种类型和适用场景

3)小云:小云是“盒子里的数据中心”,通常部署在战车上。小云允许作战人员将随身携带设备的处理和存储能力卸载到小云上,从而扩展移动设备的能力,延长续航时间。通过车载自组织网(VANET)将小云互联,可使最终的处理和存储能力倍增。车载自组织网是由车辆构成的自组织网。自组织网的含义是,车辆随着它们进入和远离网络的有效范围而自动加入和离开该网络。

4)微云:微云是指运行在资源有限的移动设备上的云计算能力。微云为了共享、处理和存储数据,通过移动自组织网(MANET)通信。移动自组织网是一种无基础设施、通过无线互联的可自配置移动设备网络。VANET与MANET在多个方面具有相同的属性,但在机动性和受限设备两个重要方面有所不同。人员的机动性比车辆要小得多,MANET的拓扑结构不会遭受VANET那样的变动程度。MANET中,个人所能携带的移动设备拥有的计算能力要小得多,而车辆则可以装载更为强大的计算设施。

微云是作战人员随身携带的移动设备上的云资源组成的。通过MANET可增强计算和存储能力。临近的移动设备以协同的方式进行分布式计算,以解决单个移动设备难以独自解决的问题。不过由于网络传输期间消耗的能量通常比本地处理消耗的能量高数个数量级,在本地处理数据比在设备之间传输效率更高,因此微云只在某些情形下才可行。

微云提供了在战术边缘处理数据的能力,并基于数据处理的结果立即采取行动。但由于移动设备处理和存储能力有限,它们并不适合复杂的计算和大量的处理。微云有助于处理任务在参与节点间的分发。同小云节点加入VANET一样,微云节点通过加入MANET而成为其中一员,实际上延伸了该节点的有效作用距离,这就是网络的延伸和倍增作用。

在这四种战术云中,集中式战术云功能最全,性能最强。它拥有传统数据中心所有的企业计算能力,能够提供传统数据中心所有的企业级服务。集中式战术云一般部署在后方重要的固定军事设施和军事基地内,它提供的计算资源池,通常位于一个或多个数据中心。池中的资源都是经过抽象的,通过分配或回收计算资源的方式实现计算的动态化。集中式战术云是非常理想的战术云计算设施。如果能从任何位置、在任何时间访问集中式战术云,就不会有对其他类型的战术云的需求了。战术环境下，由于作战条件、通信技术或带宽等因素的限制,集中式战术云并不总是可以访问的。因此提供功能相似但规模较小、性能稍逊的其他形式的战术云就非常必要了。

非集中式战术云、小云和微云都是基于集中式战术云同样的技术,只是在实现规模上有所不同。非集中式战术云既包含计算功能,又包含冷却功能。

小云在规模上比集中式战术云小几个数量级,也比非集中式战术云小得多。小云由数个运行虚拟机、可被发现、无状态的服务器组成。其计算和存储资源,一般供附近的移动设备卸载资源密集的计算任务所用。

微云是对资源有限的移动设备提供的极其有限的云计算能力的称呼。微云的可用计算资源通常比小云低三个数量级。

2 战术小云

小云是一种在接入受限的环境中使用云计算的方法,由卡内基梅隆大学软件工程研究所(SEI)首倡。可以把小云视为移动用户附近资源丰富的可信计算机或盒子里的数据中心,其实质是将云计算就近部署在用户周围,以降低网络延迟和能源消耗。该方法综合运用了云计算技术和移动技术的优势,在缺少连通性的环境中,可以高效地提供任务能力。

小云的计算和存储资源,相当于移动设备的1000倍以上,移动设备只充当瘦客户端。小云是无状态的,在提供服务之前,需要移动设备提供必要的输入。小云在物理上就近部署至关重要,这样可确保应用程序反应时间足够快和可预知。就近部署意味着小云离移动设备通常只有一跳,移动设备通过Wifi或短程无线电访问。由于移动设备利用了附近的小云资源,这种体系结构有时候又被称为移动云计算。移动云计算通过无线接入点接入云端的存储和计算资源,主动感知、动态适应作战环境的变化,是一种灵活的增强移动设备性能的计算模型,它是网络觅食的一种变体。网络觅食这个术语来源于一篇 “普存计算:远景和挑战”的论文,是指通过将资源密集的任务从资源受限的移动设备上卸载,然后再装载到相连的数据中心上,以增强移动设备能力的做法。网络觅食利用外部环境中资源富有的计算资源增强资源受限设备的本身能力有两种主要形式。一种是计算卸载,为了延长续航时间增加计算能力,将计算密集型应用卸载。一种是数据中转,通过临时性的存储传输过程中的数据,改善移动设备和云端间的数据传输。大多数网络觅食方案依赖常规互联网接入云端,或者依赖将移动用户与服务器在部署时紧耦合的策略。通常需要固定部署,而且依靠多跳网络接入云端。而基于小云的网络觅食与传统网络觅食不同的是,小云是基于虚拟机、位于移动设备附近、单跳接入、前沿部署、可发现的计算密集型服务器;可在非链接模式下工作;只在需要供应应用时才与核心网通信,应用静态地分成客户端和服务器端两部分,移动设备上只运行应用的极瘦客户端。

小云不仅能够用来处理数据,还可以存储已有数据供检索用。小云尽管自身就可以提供某些能力,但是如果将多个小云互联成一个网络,则可以放大它的能力。联网小云的计算和存储能力随着参与节点数量的增长而增加,联网小云还提供了在各个参与节点之间分布式处理/存储数据的能力。

根据部署小云的平台不同,可以将小云分成陆地云、海上云和机载云。陆地云是部署在军用车辆(如LAV)上的小云组成的自组织网。每辆车上的小云可以通过车车网(V2V)或者通过车对基站(V2I)通信接入固定式通信单元彼此通信。在军事场景中,路边通信单元可以提供C2指令、上传车辆维护和健康状态甚至更新测绘数据。而在民用条件下,VANET利用蜂窝网络。美国联邦通信委员会(FCC)已经在5.850GHz至5.925GHz的频段中分配了75MHz的频谱专门用于情报传输系统(ITS)的短程通信。

海上小云(航母打击群云)是由部署在同一打击群内的舰艇上的云资源(可以是小云甚至是非集中式战术云)构成的自组织网。每艘舰艇上的云资源通过V2V网彼此通信。

机载云是由部署在飞机(如UAV)上的云资源构成的自组织网。每架UAV上的小云通过V2V网甚至通过V2I通信接入地面单元来彼此通信。为了收集地面传感器数据,UAV需与地面传感器通信。为了下载处理过的传感器数据,它们还与FOB通信。在这两种情况下,通信链路都是带宽受限的无线网络,链路质量不稳定且不可预知。机载云与陆地云在拓扑结构形成方面有所不同,机载云的拓扑结构更为多变。而陆地云的拓扑结构与可用道路的拓扑结构有趋同的倾向。当然对陆上军用车辆来说情况并不总是如此。此外机载环境使得云设备在大小、重量和能量方面受限更多。

尽管小云没有全部解决战术环境下的能力欠缺问题,如不可靠的通信链路对态势感知的不利影响,但它确实解决了包括ISR数据处理在内的本地信息处理问题。虽然本地信息处理对改善前沿作战的态势感知能力作用有限,但它却使作战人员更好的自主作战成为可能。

2.1 战术小云体系结构

为了更好地完成任务,作战人员正在不断地增加使用移动应用,通常执行计算密集型任务,如语言和图像识别、自然语言处理、态势感知增强等。这对移动设备的电池能力和计算资源造成了严重的负担。不幸的是,战场位于网络边缘,资源有限而且环境变化频繁,网络链接时断时续。在这种接入受限的动态战场环境中,战术小云是一种可行的较为理想的提供云计算能力的技术途径。基于虚拟机的小云可扩展性、机动性、灵活性和弹性好,可以显著增强战术系统的生存能力。

当前美国防部在小云方面的研究关注几个不同的方向。第一是资助卡内基梅隆大学软件工程研究所开展小云及其在战术环境中的应用研究;第二是美国陆军研究实验室(ARL)正在进行的移动自组织网络(MANET)的研究。

通过让移动设备接入小云,主动感知、动态适应作战环境的变化,是网络觅食的一种变体。目前市场上有多种网络觅食系统,但各系统在如何利用远程资源的策略方面有所不同,如往哪里卸载、何时卸载、卸载什么等。这些系统强调支持代码卸载和状态同步的算法,而较少关注软件体系结构和能源效率及性能之外的质量属性,如生存性、弹性、安全性、易部署性等战术质量属性。卡内基梅隆大学软件工程研究所在小云研究方面的重点是开发战术小云的体系结构,并实现战术系统所需要的质量属性,从而支持将战术小云作为移动战术系统的一部分进行作战部署。在这些质量属性中,生存性特别是移动战术系统的生存性是其研究重点。他们认为,移动战术系统的生存性需要快速部署和再部署能力、快速的运行时间,这样计算任务在小云远离之前就可执行完毕。同时移动战术系统还应支持小云和数据中心之间非连接状态下的运行。

卡内基梅隆大学软件工程研究所实现的增强移动战术系统生存性的基线战术小云有如下特点:

•将能力作为服务:每一个虚拟机(VM)提供一种自包含能力,并公开一个简单接口。小云发现协议使用以关键词表示的元数据来通知移动设备小云的可用能力。

•移动设备和小云之间的“请求-响应”交互:战术小云最适合无状态、请求-响应、客户/服务器交互类应用的运算卸载。这种类型的交互可以很容易地发现移动设备和小云之间的通信故障,而且如果需要重启或迁移运算时,对移动设备的影响最小。

•虚拟机作为服务容器:以活动用户的数量(在作战边缘环境下通常是限定的,因为小组规模已知)为基础,VM可以根据需要启动或停止,从而支持可扩展性和弹性。

•小云管理器:一个轻型、基于Web的与小云服务器的接口和服务虚拟机仓库可以很容易地实现能力的部署和重部署。

•标准的服务虚拟机包:服务虚拟机包可以很容易地从小云管理器、企业服务虚拟机仓库、U盘或通过USB与小云相连的移动设备来安装。

•小云优选:扩展了小云发现协议,可以使用来自客户端应用、服务虚拟机和小云本身的元数据。在有效距离内有一个以上小云的情况下,移动设备自动选择使用效能最大化的小云。基于小云负载、信号强度或其他参数来选择。

•小云的自动或手动移交:他们正在研究虚拟机的迁移能力,实现数据和运算在相邻小云间的手动或自动移交。手动移交可实现将能力从某一固定小云迁移至某一移动小云,然后再迁移回该固定小云。自动迁移可实现负载均衡。

其战术小云原型的体系结构如图2所示。

卡内基梅隆大学软件工程研究所下一步将重点研究战术小云间的互信。目前的小云依赖网络的安全性,即根据网络策略和许可允许移动设备与小云交互。这在很多领域是可以接受的,但是对战术环境来说还不够安全。

发现小云存在是移动设备接入小云的前提。目前小云的发现过程是：运行在小云上的发现服务建立小云服务,移动设备运用Multicast DNS协议查询小云服务是否存在。但Multicast DNS协议并不安全,因此要在小云的实现方案中嵌入安全措施,从一开始就在移动设备和小云之间建立互信关系。两个节点建立互信的通用方案是使用一种在线的第三方信任授权来验证请求方的证书或证书库,但战术环境并不能持续提供对第三方授权或证书库的访问。因此研究在无连接环境中建立互信实体的解决方案,用于两个或更多计算节点之间、任何形式的可信通信至关重要。

2.2 小云的发现

服务是指任何能被终端用户或过程使用的硬件或软件特征,战术小云的硬件和软件能力被包装成服务,因此小云的发现实质是小云所能提供的服务的发现。随着计算向以网络为中心的模式的转移,寻找和利用网络上的可用服务变得越来越重要。可被发现是小云区别于传统网络觅食的一个关键特点,也是小云被附近移动设备卸载计算和暂存数据的前提条件。快速的发现、优选和安全地连接附近小云的能力,是战术小云的重要能力。

图2 战术小云体系结构

目前常用的发现系统有Sun公司的JINI、标准化组织IETF的SLP、微软公司的UPnP和苹果公司的Bonjour等。这些服务发现协议正在成为中间件的核心部分,促进了基于服务的网络体系结构的发展。

发现是一种动态引用网络资源的机制。对服务发现来说,通常使用两种核心机制:多播发现和单播查询。多播报文用于客户侧反应性的动态发现,和服务器侧主动的服务公告。因为使用了链路本地消息传递机制,当前多播报文通常局限于单跳操作。单播消息传递用于连接已知的特定服务目录,目录中包含了网络上可用的其他服务的查询表。服务目录一般用在集中式或联邦式网络结构中,通常首先被发现。有的服务发现协议支持多播和单播的结合。Jxta、Bonjour、Zeroconf、Jini 和SLP都支持某种形式的多播。

UPnP、Jini、SLP、Bonjour等都是基于IP的第三层服务发现协议。为了使用这些协议,网络设备必须先有一个链路层连接来监听其他设备的多播报文。对有线网络来说,这是一个隐含过程,因为该设备插入局域网时链路层连接就自然建立了。但是在战术边缘,无线通信常常是唯一手段。与有线网络不同,在现有的移动自组织网中,每一个设备都必须经过设备发现、设备选择、第二层链接、第三层链接、第三层服务发现这五个步骤才能与其他设备连接。只有在第六步,用户才能选择其需要的服务。

现有的无线标准,还没有一种在建立链路层连接之前广播服务的机制。参考文献[6]提出了一种解决方案,使用户能够使用第二层服务发现机制。该方案的基本思路是扩展现有无线标准,在信标中增加专门用于服务发现的服务信息描述,实现第二层服务发现。通过对比实验,基于UWB的第二层服务发现可以缩短服务发现时间50倍。

第二层服务公告是将服务信息合并到设备公告中广而告之的一种技术,从而克服无线自组织网现有第三层服务发现的缺陷。它使正在寻找特定服务的某一设备,在建立链路层链接之前,就可以收集到正在广播其服务的其他设备足够多的信息。这些信息包括服务名称、可以提供的资源以及如何和在哪里可以访问到它们等等,这些信息是无线发现过程的固有部分。无线服务发现通常使用信标(Beacon)或探针(Probe)这两种方法中的任何一种来实现。信标是来自无线设备的周期性信号,用来公告设备的存在和与同伴建立传输计划。在UWB和802.11n等无线标准中,应用说明数据可以封装在叫做应用说明信息要素(ASIE)的字段中,并作为信标信息的一部分传输。这些ASIE可以用来传送设备上可用服务的摘要信息。无线服务发现的另外一种方法是使用探针请求。当设备加入无线网络时,它向其他设备发出多播探针请求,询问它们的共享服务。其他设备向请求设备单播回应以减少链路层拥堵,可以将服务播报作为探针请求回应的一部分。因为探针请求可以发生在任何时刻,附近的设备必须处于活动状态才能侦听到探针请求,这对续航时间有限的小型移动设备不利。

服务发现只是应用与资源交互的第一步,应用程序使用该资源更为重要。大多数发现系统只是简单地提供一个资源句柄,然后就退出了。即使双方就发现协议达成一致,也无法保证能实际合作,它们还必须就操作和数据格式以及语义达成一致。

在目前的小云原型中,小云发现是基于Avahi实现的,Avahi是一种zeroconf实现。Avahi同时使用了DNS-SD服务发现协议和多播DNS协议。使用多播地址可以使客户在不知道服务器地址的情况下请求服务,使移动设备及时发现、使用可用小云成为可能。原型小云的发现原理和过程见图3。

图3 原型小云发现过程

2.3 小云的供应

小云的供应,就是配置和部署服务虚拟机,使该服务虚拟机含有可在小云端运行的服务器端代码,供移动设备上的客户端使用的过程。

卡内基梅隆大学软件工程研究所实现了五种不同的小云供应机制,从小云自移动设备动态供应到基于任务能力需求的静态小云预供应,分别是虚拟机优化合成、应用虚拟化、缓存虚拟机、小云推送和随需虚拟机供应。这五种供应机制又分三种情形:运行时刻从移动设备供应,如虚拟机优化合成和应用虚拟化;部署时刻基于任务需要预供应,如缓存虚拟机和小云推送;运行时刻能力随需组配,如随需虚拟机供应。

2.3.1 虚拟机优化合成

在虚拟机合成模式下,小云是通过在运行时刻从移动设备向小云发送附加应用程序层而完成供应的。附加应用程序层提前创建好该应用的服务器端部分,该部分是基线虚拟机和在该基线虚拟机上安装完该应用后的差量部分。在运行时刻,可以执行该附加应用程序层创建过程的逆过程,来创建服务虚拟机。

虚拟机优化合成的目标是减少应用程序就绪时间----即发出小云供应请求到服务器通知准备运行之间的时间。细节如下:

•相当于客户/服务器应用的服务器端部分的附加应用程序层在离线时创建。创建过程如下:从一个基础虚拟机磁盘映像文件(使用QEMU qcow2作为虚拟机磁盘映像文件的格式)和一个基础内存文件启动一个虚拟机实例,在基础虚拟机映像上安装服务器端应用,并挂起该虚拟机。虚拟机挂起时,会创建作为应用程序层一部分的两份文件:一份文件对应挂起的虚拟机和基础虚拟机(qcow2文件)之间磁盘映像的变化部分,另一份文件对应挂起的内存映像和基础内存映像之间的二进制变化部分(使用xdelta3 和VCDIFF格式计算)。计算出来的磁盘和内存层运用LZMA2压缩算法使用XZ流压缩格式进行压缩,并装载到移动设备中。

•基础虚拟机仓库含有全部的基础虚拟机磁盘映像文件集和内存映像文件集,附加应用程序层从这些基础映像文件中创建。

•小云服务器在运行时使用xdelta3和lzma 库文件解压缩,并将收到的附加应用程序层应用于相应的基础虚拟机。

2.3.2 应用虚拟化

在应用虚拟化模式下,小云是通过在运行时刻从移动设备端向小云端发送虚拟化应用而供应的。同虚拟机优化合成一样,小云仍然来自移动设备在运行时的供应。应用虚拟化使用与操作系统虚拟化类似的方法,都是通过“欺骗”软件与虚拟的(而不是实际的)环境进行交互而实现的。运行时构件从应用程序中截获所有的系统调用,并将这些调用转发给虚拟化应用的内部资源。使用将应用及其全部依赖库文件整体打包的工具包预先创建虚拟化应用的服务器部分。在Linux操作系统下,CDE(代码、数据和环境的简称)被用来作为应用虚拟化器,而在Windows下,则使用Cameyo作为应用虚拟化器。CDE通过监控应用程序的执行来虚拟化应用,而Cameyo则是通过监控应用程序的安装过程来虚拟化应用。这两种工具都可生成移动设备上的虚拟化应用,这些虚拟化的应用在运行时刻传给小云,部署在与该虚拟应用的操作系统相匹配的虚拟机上。细节如下:

•支持在小云上运行的应用程序包就是虚拟化的应用,相当于小云应用的服务器端部分,它使用上文描述的过程创建。

•客户虚拟机库包含小云所能支持的每一种操作系统的虚拟机磁盘映像文件。

2.3.3 缓存虚拟机

在缓存虚拟机模式下,小云与服务虚拟机一起被预先供应。根据任务需要预先准备好小云,同时预先准备好各种能力的虚拟机存入虚拟机库。虚拟机库中的每一个虚拟机都被视为一种服务。该服务虚拟机的能力与移动设备上的客户端应用的能力相匹配。细节如下:

每一个服务虚拟机都有一个唯一的服务标识符,并作为一组文件存储在服务虚拟机库中。

•服务虚拟机元数据文件(.jsonsvm):JSON文件有以下字段:

serviceId: 虚拟机所提供服务的唯一标识符

servicePort: 虚拟机内的服务器监听端口

•磁盘映像文件(.qcow2):qcow2文件包含虚拟机磁盘映像和应用程序的服务器端部分。

•λ虚拟机状态映像文件(.lqs):虚拟机状态映像的文件格式是存储内存映像时libvirt.save()生成的。既包含挂起的虚拟机的描述,也包含运行服务器端应用时的虚拟机内存状态。

服务虚拟机仓库是作为一组文件夹创建的,每一个文件夹使用以下的命名约定:

.jsonsvm

.qcow2

.qcow2.lqs

服务虚拟机是在虚拟机内安装应用服务器然后挂起时创建的。JSON文件是由用来创建服务虚拟机的脚本自动创建的,并与磁盘和内存映像文件一起存储在同一个目录中。这三个文件用来启动服务虚拟机,确保服务虚拟机从其挂起点开始运行,从而减少应用的准备时间。

2.3.4 小云推送

在小云推送模式下,小云不仅与服务虚拟机一起被预先供应,而且与使用该服务虚拟机的移动端客户应用一起被预先供应,相应的客户端应用在运行时刻被推送至移动设备。小云推送供应机制的有关细节如下:

•每一个小云App都有唯一的标识符和存储在小云App库中的额外的元数据。小云服务器使用这些信息构建小云App列表,该列表根据请求发往小云客户端,与访问应用仓库类似。有必要指出的是,移动客户端需要的唯一元素是小云客户端。

•小云App和小云App元数据在运行时刻从小云获取,并存储在移动客户端。

2.3.5 随需虚拟机供应

在随需虚拟机供应模式下,小云是根据从移动设备发送的供应脚本,使用一种商业云供应工具在运行时刻“装配”服务虚拟机而实现供应的。

“装配”服务虚拟机时,小云基于一个供应脚本,该脚本有权访问装配服务虚拟机所需要的所有元素。云供应工具使用Puppet,供应脚本是用Puppet描述语言写成的一个清单。

基线虚拟机是一个挂起的虚拟机,用来作为构造服务虚拟机的模板。与虚拟机合成机制下的基础虚拟机不同,基线虚拟机可以修改、更新和持续保持,而不影响供应过程。每一个基线虚拟机都作为一组文件存储在基线虚拟机库中:

•磁盘映像文件(.qcow2):qcow2文件相当于基线虚拟机的磁盘映像。它包含一套基本的OS安装文件,加上服务虚拟机常用的构件和库文件。在使用Puppet的原型小云系统中,下列构件需要成为基线虚拟机的一部分:

1)SSH服务器,小云服务器用来发送文件和指令。

2)Puppet客户端用来执行虚拟机内的Puppet清单。

3)与小云服务器的网络连接,以便服务虚拟机(小云服务器作为HTTP文件服务器,通过HTTP)下载在小云本地存储的文件包和依存库文件。

•虚拟机状态映像文件(.lqs):虚拟机状态映像是保存内存映像时,以调用libvirt.save()时生成的格式存储。

•基线虚拟机元数据文件(.jsonbmd):JSON文件用以下字段描述基线虚拟机的基本特征:

osFamily (string): OS(即Linux、Windows)

os (string): OS名称或OS发行版名称:(即“Windows 7”、“Ubuntu”)

osVersion (string): OS版本(即“SP1”、“8.1”、“12.10”)

osISA: 指令集(即“x86-32”或“x86-64”)

基线虚拟机设置成一组文件夹,每一个文件夹都使用以下命名约定:

.jsonbmd

.qcow2

.qcow2.lqs

每一个小云App都有一个相应的服务供应脚本和用来在小云上设置相应服务虚拟机的元数据。

•基线虚拟机元数据文件(.jsonbmd):JSON文件描述基线虚拟机的基本特征,这些特征是创建服务虚拟机时必需的。格式与上面描述的基线虚拟机元数据文件一致,用来在供应过程中发现匹配的基线虚拟机。

•服务虚拟机元数据文件(.jsonsvm):JSON文件结构与“缓存虚拟机”一节中定义的文件结构一致,用来描述服务虚拟机。

•Puppet清单:脚本含有在服务虚拟机内部必须供应的内容的指令,如要安装的应用服务器、依存文件和库文件等。脚本遵循Puppet清单标准。

服务和依存文件库包含两组文件。在原型小云中,这些文件从小云主机使用HTTP下载等方式获取,但是只要有网络连接,它们也可以从外部URL中获取。

•服务虚拟机提供的构成实际服务的文件(在应用服务器中实现)

•依存文件:服务可能使用的、构成依存关系的文件/库文件。在原型小云中,在Ubuntu系统下是作为APT-GET库实现的,而在Windows下是作为MSI包实现的。

基于不同的小云供应机制的试验结果,在原型小云中,他们采取了将缓存虚拟机和小云推送相结合的小云供应机制,实现了移动设备上较低的能量消耗,降低了对移动设备的需求,简化了战术环境中小云的供应问题。

2.4 应用运行

收到服务虚拟机的IP地址和端口后,小云客户端将这些信息返回给小云客户端应用。小云客户端应用建立与服务虚拟机IP地址和端口的套接字,以客户端/服务器计算模式运行应用,直到应用关闭。

3 结束语

现代战争几乎完全依赖即时的信息和态势感知。信息优势可转变成作战优势,对战争胜负至关重要。但随着越来越接近战术边缘,信息的可用性和信息质量急剧降低。战术云计算提供了一种将云计算能力扩展至战术环境的手段,借助战术云计算可提供更多计算资源、改进协作和信息共享从而获得作战优势。

本文考察和评估了美军正在研究的四种战术云的体系结构,分别是集中式战术云、非集中式战术云、小云和微云等,并对卡内基梅隆大学软件工程研究正在研究的小云进行了较为详细的介绍。集中式战术云在节省成本、灵活性和处理ISR大数据方面提供了多种可能。它在军事应用方面的潜力,从云计算在商业领域的广泛和成功应用中可见端倪。集中式战术云提供的强大并行处理能力有助于开展对大数据的高级分析,从而向作战人员提供对完成任务至关重要的信息。非集中式战术云可以向远程部署的作战人员提供非常显著的好处:它可以在数周而不是数月甚至数年完成部署。一旦部署,它能确保行动情报比其他方式快得多地出现在作战人员手中,如远程访问集中式战术云。随着移动云计算技术的大量应用,使用小云的移动云计算有巨大的潜力。需要大量计算和数据访问而带宽有限的应用是这种技术的理想用户。通过将应用卸载到小云可极大降低移动设备的能量消耗。通过使用VANET技术,小云的计算和存储能力可倍增。微云在军用环境中是几种技术中相对容易实施的一种方案,但微云在战术边缘的部署意义有限。在移动设备电池技术突破之前,微云的应用前景尚不明朗。

因此,战术小云是最为可行的技术方案,值得进一步研究。特别是小云用来进行计算卸载和能力扩展的技术,应当进行详细和深入的研究。

[1] Alan Magar,Sphyrna Security Inc. Assessing the use of tactical clouds to enhance warfighter effectiveness[R].Defence Research and Development Canada Contract Report,April 2014.

[2] Grace Lewis. Tactical Cloudlets: Moving Cloud Computing to the Edge[D].Software Engineering Institute Carnegie Mellon University,December 10, 2014.

[3] Kyle Usbeck, Matthew Gillen, Joseph Loyall et al. Improving Situation Awareness with the Android Team Awareness Kit (ATAK), BBN Technologies, Cambridge[C].MA, USA, Proceedings of the SPIE Conference on Defense and Security, 20-24 April 2015.

[4] Johnu George, Chien-An Chen, Radu Stoleru et al. Hadoop MapReduce for Tactical Clouds, Department of Computer Science and Engineering[C].Texas A&M University, 2014 IEEE 3rd International Conference on Cloud Networking (CloudNet).

[5] W. Keith Edwards. Discovery Systems in Ubiquitous Computing[J].Georgia Institute of Technology,2006 IEEE CS and IEEE ComSoc.

[6] Shivani Sud, Roy Want, Trevor Pering et al. Enabling Rapid Wireless System Composition through Layer-2 Discovery[J].Intel Research,2008 IEEE Network.

[7] Christian Schwingenschlogl, Anton Heigl. Development of a Service Discovery Architecture for the Bluetooth Radio System[R].Technische Universitat Munchen (TUM), Institute of Communication Networks,September 1, 2000.

[8] Joseph P. Macker, Justin W. Dean, Ronald D. Lee, Robert B. Adamson. Distributed Service Discovery within Mobile Ad Hoc Networks[R].Naval Research Laboratory, September 20, 2011.

[9] 程赛先. 美军舰载战术云计算应用模式分析[C].中国指挥与控制学会火力与指挥控制专业委员会2015年学术年会论文集,2015.

[10] 程赛先. 云计算的军事应用:无人系统分布式战术控制的新方法[C].第四届中国指控大会年会论文集,2016.

Research on Tactical Cloud Computing Utilization in US Forces

CHENG Sai-xian

(Jiangsu Automation Research Institute, Lianyungang 222061, China)

Cloud computing has been widely utilized in commercial areas, and also expanded its usage in military areas in recent years. But some problems have been encountered in terms of its usage in tactical environment. The paper enumerates four different types of tactical cloud and their application scenarioes, and studies the architecture, clouldlet provision modes as well as its discovery protocals in detail. In the end, the paper analyses the current status and potentials of tactical cloud computing utilization in US forces.

tactical cloud; cloud computing； US forces

1673-3819(2017)06-0134-09

E94

A

10.3969/j.issn.1673-3819.2017.06.028

2017-09-11

2017-10-17

程赛先(1968-)，高级工程师，研究方向为综合电子信息系统情报。