面向航天应用的对象存储系统设计

宫永生，吕从民，曹素芝

(1.中国科学院空间应用工程与技术中心，北京100094；2.中国科学院大学，北京100049)

1 引言

随着太空探索逐步深入，空间应用的规模大幅扩展，相应地出现了载人空间站等大型飞行器及低轨互联网卫星星座等空间应用形态，且未来会向着月球基地、火星基地以及更深远的太空进一步拓展。空间应用的扩展对空间信息系统的发展提出了新的要求，空间信息系统的架构走向以组网为基础分布式形态，包括飞行器内部基于有线网络的分布式存储和处理以及多个飞行器间的空间无线网络分布式信息存储和处理。空间信息系统架构的演进意味着必须考虑如何在空间部署分布式存储系统，以满足未来空间应用的需求。

对象存储系统通过创新性的分布式架构设计，解决了资源共享、超高速存储、海量存储、高可靠、可扩展等数据存储系统面临的难题，在地面大规模数据存储系统中获得广泛应用。国际互联网工程任务组(Internet Engineering Task Force，IETF)于2010年正式发布了并行文件系统(parallel Network File System，pNFS)标准，在传统的网络文件系统NFS基础上添加对于分布式存储系统的支持，同时支持对象存储、块存储和文件存储设备3种类型。针对对象存储设备，pNFS定义了分布式对象存储的基本架构，但并未详细规定具体的分布式控制协议、存储协议以及系统数据备份策略等内容。由美国能源部资助开发的开源对象存储系统Lustre在超大规模和超高性能服务集群中获得广泛应用，在系统规模、性能和可靠性方面表现优异，但系统设计复杂度极高。面向极致性能、可靠性和可扩展性而设计的统一对象存储系统Ceph则在OpenStack社区获得了相当广泛的使用，其采用名为CRUSH(Controlled Replication Under Scalable Hashing)的算法计算数据对象的存储位置，替代传统元数据索引管理方式，提升了元数据服务器性能，以算代存是很巧妙的问题解决思路，但是需要客户端具有较强计算能力支持。

对象存储系统能够解决未来空间应用数据存储的大规模、高可靠、可扩展等关键需求，但是也面临一些设计挑战，突出体现在两方面:①空间设备的体积、重量、功耗(Size，Weight，and Power，SWaP)约束要远远比地面严苛，对象存储系统架构及协议设计上需充分优化，降低系统SwaP，特别是用户端的协议设计应尽可能简单。②空间应用数据具有特殊性，数据的产生、表征、传输等既有协议需要兼容，数据在轨存储模式与地面互联网应用相比也有很大的不同，空间数据存储系统设计需进行针对性考虑。

本文针对航天应用数据存储的需求，首先研究空间应用的数据特征及其对象化表征方式；然后在此基础上综合考虑空间设备体积、重量、功耗等特定的约束条件，设计轻量化空间应用对象存储系统架构及相关协议，并探讨系统中数据备份等关键策略设计；最后给出系统实现及验证情况，对后续研究提供借鉴。

2 基于CCSDS航天应用数据对象化定义

对象存储系统中的对象是数据的一种逻辑组织形式，对象特征通过对象属性来描述。航天应用数据对象的建立除了需要表征航天应用数据的特征之外，还需考虑数据对象后续存储及处理的使用模式，特别是在基于网络的对象存储系统中，对象数据的格式定义对于系统设计有很大影响。

航天应用数据一般按照CCSDS(Consultative Committee for Space Data Systems)定义的数据格式进行描述，本文在不更改CCSDS协议的前提下，对CCSDS的字段进行部分扩展，以反映空间应用数据的特征，同时考虑数据对象分布式存储需求。

CCSDS空间数据包协议(Space Packet Protocol，SPP)定义了空间应用的数据格式，满足星间、星地等空间链路上的空间用户数据传输需求，是传输链路层和用户应用之间的桥梁性协议。SPP协议定义的标准数据格式如图1所示，主要包括主导头、副导头和用户数据区3部分。

图1 空间数据包协议格式定义Fig.1 Definition of Space Packet Protocol

通过SPP数据格式可以看到，主导头主要用于定义数据的产生源头以及数据传输方式，而副导头则预留了较大的扩展空间，可以依据应用进行定制。

根据空间应用数据的自身特性以及对象存储系统的特点，在副导头增加数据存储属性字段来扩展数据的表征方式，并添加数据的后续存储需求，例如数据可靠性保证需求、数据的保密和压缩需求等内容。数据对象的副导头扩展定义如图2所示。

数据存储属性字段的第1个要素为任务号TaskID，由于空间应用数据的产生和处理与任务的安排密切相关，可方便后续对该任务数据的查询和检索操作。

图2 空间应用数据对象副导头扩展定义Fig.2 Packet secondary header definition for space app lication data

数据存储属性字段的第2个要素设计为子设备号SubDeviceID，对于某个特定的空间应用载荷(具有唯一APID)一般会包括若干个仪器设备，不同的仪器设备数据特征各不相同，后续需要的存储策略也有很大差异，因此加入子设备号属性，可对应用数据进一步细分。

数据存储属性字段的第3个要素设计为数据类型DataType，对于某个特定的空间应用载荷的特定仪器设备，依然可能产生不同的数据类型需要进行区分存储，数据类型字段可以对数据进一步细分。

数据存储属性字段的第4个要素设计为数据段标识SegNo，用于对同一类型数据的长度进行扩充。SPP协议中定义的序列号字段SeqNo仅能表示不超过1 GB的数据，对于更大的数据长度，序列号SeqNo会重复。增加数据段标识SegNo可扩展数据对象长度。

数据存储属性字段的第5个要素设计为QoS字段，QoS字段表征该数据对象希望对象存储系统执行的所有特殊需求，主要包括数据备份数目的需求、数据加密/压缩等需求。

综上，空间应用数据的CCSDS数据包可以采用＜APID，Task ID，SubDeviceID，DataType，SegNo，SeqNo＞六元组进行唯一表征，其中APID和Seq-No使用SPP包格式的主导头信息，而TaskID，SubDeviceID，DataType，SegNo则使用SPP包格式的副导头扩展信息。

3 对象存储系统架构设计

3.1 系统架构

对象存储系统由3部分构成，客户端(Client)、元数据服务器(Metadata Server，MDS)和对象存储设备(Object Storage Device，OSD)，三部分之间通过主要的3个协议进行通信:存储控制协议、存储管理协议和存储访问协议。系统架构如图3所示。

图3 对象存储系统架构Fig.3 Framework of object storage system

客户端与元数据服务器通过存储控制协议交换控制信息，例如任务请求及响应等；客户端与对象存储设备通过存储访问协议交换读写的数据；元数据服务器与对象存储设备通过存储管理协议进行对象存储设备状态管理等。

3.1.1 客户端

客户端是用户访问对象存储系统的入口，将用户直接的数据读写转换为对象存储系统内部的数据访问。客户端屏蔽对象存储系统内部访问细节，对用户提供直接的标准数据访问接口。

1)客户端与元数据服务器交换控制信息，获得当前存储系统的状态；

2)客户端与对象存储设备直接进行数据读写，完成数据传输。

3.1.2 元数据服务器

元数据服务器负责管理整个对象存储系统，包括所有用户的元数据信息以及对象存储系统自身的状态信息。元数据信息描述了数据对象是如何分布在对象存储设备上的布局信息(LAYOUT信息)，而系统自身状态信息则反映了对象存储设备本身的工作状态。

1)对象存储设备管理功能，包括节点健康状况监控及故障隔离；

2)系统元数据管理功能，负责所有用户数据的元数据信息管理，提供用户数据快速查询和检索功能。

3.1.3 对象存储设备

对象存储设备负责具体用户数据的实际存储功能。

1)智能化数据存储功能，支持按照数据对象ID进行数据访问；

2)支持按照时间码、对象属性等进行快速检索，提供符合要求的对象数据；

3)支持智能数据备份功能，对于需要进行数据冗余备份的对象数据，自动在多个对象存储设备节点进行数据备份。

3.2 系统功能设计

3.2.1 对象颗粒度设置

按照SPP格式定义，空间应用数据的基本颗粒度为单个CCSDS数据包，通过＜APID，TaskID，SubDeviceID，DataType，SegNo，SeqNo＞六元组进行表征，数据长度最长为64 kB。

对于对象存储系统来说，数据对象的颗粒度越小，意味着数据对象的管理类元数据信息越大。假设对象存储系统的总容量为128 TB，意味着数据对象的个数不少于2×10个。如果对于每个数据对象都建立索引信息，则元数据服务器代价很大。为此可将数据对象的管理粒度和实际对象存储粒度分离设计，将若干个数据对象分组进行统一管理。

例如，考虑到空间应用任务执行的特点和系统规模，元数据服务器的索引信息可以只管理到数据段号，对于具有相同五元组＜APID，Task ID，SubDeviceID，DataType，SegNo＞的数据对象都分布在同一个OSD上，这样元数据服务器的管理压力显著减低。另一方面具有相同五元组的数据对象总容量不会超过1 GB，方便了用户应用数据在多个OSD之间的调度问题，也简化了多备份策略下的数据迁移问题。

本系统将数据对象进行组合管理，每个数据对象组通过五元组＜APID，Task ID，SubDeviceID，DataType，SegNo＞进行表征，而数据对象的读写访问则依然使用六元组＜APID，Task ID，SubDeviceID，DataType，SegNo，SeqNo＞，简化系统管理的同时，满足用户细粒度访问数据的需求。

3.2.2 模块具体功能设计

1)元数据服务器模块。对象存储系统中OSD设备状态存在上线、下线等状态变化，元数据服务器需实时了解各个OSD设备的可用状态。为此设计心跳机制，OSD设备定时向元数据服务器报告自己的状态。通过该机制，元数据服务器可了解系统中所有OSD在线状态以及在线OSD的可用存储容量、执行任务情况等，并在系统中维持该信息(系统状态信息)。

元数据服务器另一个重要功能是维护系统中所有数据对象组的映射关系，即每个数据对象组存放在哪些OSD上(LAYOUT信息)。一般情况下，元数据服务器自身持久维护该信息，由此带来了多元数据服务器之间、元数据服务器和OSD之间的信息同步问题，需要设计复杂的一致性协议保障数据同步。

本文设计的元数据服务器对LAYOUT信息采用缓存模式，元数据服务器并不会长久保存LAYOUT信息，而是通过非易失OSD设备的信息进行恢复，所有数据以OSD信息为主，OSD同时保存了对象数据和对象元数据信息，可以保证数据和元数据之间的一致性。

同时，缓存更新策略也采用懒更新策略，即系统上电时不会主动询问OSD来实时更新该信息，只有当用户执行某个数据对象查询时，元数据服务器检查自己的LAYOUT信息，判断是否有相关数据对象组的记录，如果有则直接返回记录信息给用户；如果没有，则向系统中所有的OSD进行查询，并将查询结果反馈给用户的同时更新自身的LAYOUT信息。

通过缓存模式设计和懒更新策略，极大降低了元数据服务器的设计复杂度和工作负载，使得轻量化的元数据服务器实现成为可能。由此带来的缺点是用户查询元数据服务器缓存未命中的情况下，需要等待元数据服务器和OSD之间的信息更新，此时系统的读取性能会稍微下降。但是对于空间应用来说，90%以上的工况为数据写入，该设计对系统性能几乎无影响。

2)对象存储设备模块。对象存储设备设计为标准的对象数据访问设备，每个数据对象的ID使用六元组＜APID，TaskID，SubDeviceID，Data-Type，SegNo，SeqNo＞表示，支持对任意数据对象的单独访问。

3)客户端模块。用户在访问对象存储系统之前，需要获取对象存储系统的相关设备信息。

如果是数据对象写入操作，则首先向元数据服务器请求系统状态信息，可以获知系统中OSD设备的在线状态及工作参数，由客户端随机选择满足要求的OSD进行数据写入。

如果是数据对象读取操作，则首先向元数据服务器查询该数据对象的LAYOUT信息，并依据元数据服务器反馈的LAYOUT信息访问相应的OSD设备。

3.3 数据备份策略

数据备份策略从系统层面和数据层面2个维度考虑，分别关注系统元数据的备份以及用户数据的备份，以保障系统可靠运行和用户数据可靠存储。

3.3.1 系统元数据备份策略

对象存储系统的系统元数据包含了整个系统运行所需的所有关键信息，包括系统所有节点的健康状态数据、系统存储资源的分配状况、目前执行任务的用户信息等。

传统的对象存储系统中，系统元数据必须实时更新，否则会面临对象ID冲突等问题，导致数据对象写入的互相覆盖。因此对于多服务器组成的元数据服务器集群来说，多个服务器间的元数据必须满足强一致性同步要求，给设计带来了极大的挑战。为满足该要求，可以采用Paxos等一致性算法进行数据同步，由此带来了频繁的元数据服务器间数据更新操作，极大地影响系统的性能。

本系统设计的元数据服务器通过以下2个方法解决这一问题:

1)数据对象唯一性保证策略。数据对象ID的定义与数据产生的源头进行绑定，通过唯一六元组＜APID，Task ID，SubDeviceID，DataType，Seg-No，SeqNo＞进行表征。通过该种方式保证了系统中不存在同样的数据对象ID，因此即使在元数据服务器发生网络分区无法通信的情况下，依然各自能够执行正常的任务。在网络分区状态解决后，多个元数据服务器的信息并不会发生冲突的情况，直接进行融合合并即可。

2)OSD数据对象组预分配策略。每个OSD对于接收到的新的数据对象写入请求时，首先判断本OSD可供分配的剩余存储空间。由于每个数据对象组的大小定义为不超过1 GB，因此OSD可以轻易地根据当前正在执行的写入需求判断是否能够接受新的数据对象写入请求。这样，即使多个用户获得的系统元数据信息不够实时，也不会发生用户数据对象写入错误的问题。通过数据对象组预分配策略，避免了数据对象组冲突导致的回滚动作。

通过上述方法，解决了传统对象存储系统面临的元数据服务器分区隔离和数据同步的需求，无需实现任何专门的元数据备份策略，即可保证系统正常稳定运行。

3.3.2 用户数据备份策略

用户数据备份策略重点集中在面向航天应用的按需备份策略的实施。按需备份策略需要解决2个问题:首先是用户的备份需求通过什么样的方式通知对象存储系统，其次是对于存在多个备份的数据对象，谁来执行数据备份的操作以及维护系统中的有效备份数目。

由于数据对象具有自描述的特征，为了简化用户与对象存储系统之间的接口访问，可以将每个数据对象的备份需求直接嵌入到数据对象的包格式中，为此为每个数据对象定义QoS字段并将其放置在副导头位置，这样所有对象存储系统中的设备都能够获知该数据对象的QoS要求，而无需单独与用户进行协议交互。

QoS字段表征了该数据对象希望对象存储系统执行的所有特殊需求，主要包括数据备份数目的需求、数据加密/压缩等处理的需求。本文定义的QoS数据备份字段格式见图4，通过在数据对象格式中定义QoS字段，解决了数据备份需求的约定形式。

图4 QoS数据备份字段定义Fig.4 Definition of QoS data backup segment

本文采用由对象存储设备主导的用户数据备份方式。在该方式下，用户只需完成对第1个对象存储设备的数据写入即可，第1个对象存储设备会依据数据备份的具体需求，适时地将数据写入到其余的备份设备。

每个对象存储设备在接收到有备份需求的数据对象时，除了将该数据对象保存到本地，还会检查该对象的当前备份编号字段，如果当前备份编号小于备份次数需求，则该设备将当前备份编号加1并发送给系统中的下1个对象存储设备，如果当前备份编号大于等于备份次数需求，则只进行数据对象保存而不进行后续的备份工作。通过该机制能够以简单的方式实现系统中存储多个数据备份的需求。

在系统运行过程中，如某个备份节点发生了损坏，则会导致系统中有效数据备份数目减少。如果需要对象存储系统中始终存在满足需求的备份数目，则需要设计数据迁移策略，在监测到数据存储设备故障导致备份数目不足的情况下，启动数据迁移。空间数据备份策略的需求是为了解决数据存储设备故障的情况，避免关键数据的单点失效不可恢复，而不是追求系统在长时间运行中始终维持多个备份数据的存在。综合考虑空间应用数据的使用需求以及数据迁移带来的网络传输代价，本文不考虑数据迁移算法的设计，即数据备份策略只在初次数据写入的时候执行，保证系统中存在满足需求的备份数目，而后续设备故障导致的备份丢失不会触发数据迁移操作。

4 系统验证

4.1 验证系统组成

系统验证以空间站应用系统项目为背景，构建模拟地面验证环境，对本文提出对象存储系统进行功能和性能验证。

验证系统基于FC-AE-1553交换式网络进行构建，在交换网络之上实现了对象存储系统，主要包括元数据服务器、智能存储节点和客户端模拟设备，验证系统组成如图5所示。

在硬件设计上，元数据服务器和智能存储节点均采用自研的嵌入式3U VPX板卡(主芯片为Xilinx XC7Z045)，尽可能模拟将来在轨应用的实际使用环境，地检则使用多个机架式服务器进行模拟。

元数据服务器软件完成对智能存储节点的状态管理和客户端存储任务的管理，运行在FC-AE-1553网络的NC节点上。智能存储节点完成对用户数据的实际存储，运行在FC-AE-1553网络的NT节点上。客户端功能运行在地检上，完成载荷数据源模拟及地面数据下行通道模拟。三部分共同完成对象存储系统的资源调度，实现数据的写入和读取操作。

图5 技术验证系统组成框图Fig.5 Block diagram of technical verification system

验证系统的部分性能指标如下:

1)FC-AE-1553交换网络物理层速率为4.25 Gbps，去除物理层8 B/10 B编码开销，理论上限为3.4 Gbps；

2)单个NT模拟节点模拟不超过8个载荷，单个载荷的有效数据率设计为不超过600 Mbps，仿真实际的机柜内工作载荷；

3)单个NT智能存储节点的内部存储带宽为4.5～5.8 Gbps。

4.2 验证结果

为了验证对象存储系统在不同工况下的存储性能，分别设计多载荷任务同时访问测试和多节点存储系统测试，模拟在轨多用户同时访问和存储系统节点动态调整的使用工况。

1)多载荷任务同时访问性能测试。单个存储节点情况下，载荷任务分别设置为(1/2/4/8/16/32/64)，测试系统的存储总带宽。多载荷任务同时存储性能测试结果如图6所示，可以看到，随着载荷任务增多，系统总带宽逐步增加到3.17 Gbps，此后基本维持稳定。对象存储系统能够支持多任务并发执行，并在嵌入式环境下网络带宽利用率达到91%以上。

2)多存储节点系统性能测试。载荷任务固定为64的情况下，存储节点数目分别设置为(1/2/4/8)，测试系统的存储总带宽。多存储节点同时存储性能测试结果如图7所示。可以看到，在该小规模存储系统下，随着存储节点数目增多，对象存储系统的性能随着分布式节点近似线性增加，系统具有良好的横向扩展能力。

图6 多载荷任务工况系统存储带宽Fig.6 Storage bandw idth ofmulti-task system

图7 多存储节点工况系统存储带宽Fig.7 Storage bandw idth of multiple storage nodes system

5 结论

本文针对空间站空间应用场景，设计了小规模对象存储系统，研究了空间数据对象格式定义、对象存储系统架构和协议、系统数据备份策略等问题，提出了适应场景的设计方案，并进行了系统验证。验证结果表明:在航天专用的嵌入式环境下，通过对象存储系统解决资源共享、高速存储、高可靠、可扩展等数据存储系统面临的难题是一种可行的途径。