CN116401225A - 一种面向卫星云的分布式文件系统 - Google Patents

一种面向卫星云的分布式文件系统 Download PDF

Info

Publication number
CN116401225A
CN116401225A CN202310312635.4A CN202310312635A CN116401225A CN 116401225 A CN116401225 A CN 116401225A CN 202310312635 A CN202310312635 A CN 202310312635A CN 116401225 A CN116401225 A CN 116401225A
Authority
CN
China
Prior art keywords
data
metadata
nodes
satellite
node
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202310312635.4A
Other languages
English (en)
Inventor
沃天宇
范坤
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Beihang University
Original Assignee
Beihang University
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Beihang University filed Critical Beihang University
Priority to CN202310312635.4A priority Critical patent/CN116401225A/zh
Publication of CN116401225A publication Critical patent/CN116401225A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10—File systems; File servers
    • G06F16/18—File system types
    • G06F16/182—Distributed file systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10—File systems; File servers
    • G06F16/11—File system administration, e.g. details of archiving or snapshots
    • G06F16/122—File system administration, e.g. details of archiving or snapshots using management policies
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5083—Techniques for rebalancing the load in a distributed system
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04B—TRANSMISSION
    • H04B7/00—Radio transmission systems, i.e. using radiation field
    • H04B7/14—Relay systems
    • H04B7/15—Active relay systems
    • H04B7/185—Space-based or airborne stations; Stations for satellite systems
    • H04B7/1851—Systems using a satellite or space-based relay
    • H04B7/18513—Transmission in a satellite or space-based system
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/104—Peer-to-peer [P2P] networks
    • H04L67/1042—Peer-to-peer [P2P] networks using topology management mechanisms
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/104—Peer-to-peer [P2P] networks
    • H04L67/1044—Group management mechanisms 
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1097—Protocols in which an application is distributed across nodes in the network for distributed storage of data in networks, e.g. transport arrangements for network file system [NFS], storage area networks [SAN] or network attached storage [NAS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/133—Protocols for remote procedure calls [RPC]
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D30/00—Reducing energy consumption in communication networks
    • Y02D30/70—Reducing energy consumption in communication networks in wireless communication networks

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Databases & Information Systems (AREA)
  • Data Mining & Analysis (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Computing Systems (AREA)
  • Mathematical Physics (AREA)
  • Astronomy & Astrophysics (AREA)
  • Aviation & Aerospace Engineering (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

本发明通过分布式系统领域的方法，实现了一种面向卫星云的分布式文件系统。系统由5个组件组成：元数据管理模块、StorageEngine、Policy、客户端和卫星拓扑服务模块；其中元数据管理模块进行元数据存储，Storage Engine是数据存储模，Policy是策略模块，用户使用客户端与卫星云文件系统进行交互，卫星拓扑服务模块针对卫星云场景专门设计为卫星云文件系统提供卫星云的网络拓扑信息，各模块之间使用RPC通过专门的文件系统接口实现通信。本发明提供的方法针对卫星通信场景，保证元数据的高效读取和可靠性；利用卫星云的网络拓扑特征，最大程度地减少副本放置的通信代价和能量损耗；最大化降低访问时延。

Description

一种面向卫星云的分布式文件系统
技术领域
本发明涉及分布式存储技术领域，尤其涉及一种面向卫星云的分布式文件系统。
背景技术
经过数十年的快速发展，起源于上世纪60年代的现代遥感技术及应用已经进入了新的阶段。遥感技术在农作物监测与产量估计、土地资源监控与调查、灾情监测与评估、海洋环境监测等多个领域具有重要的应用价值，与国民经济发展、生态环境保护以及国家安全具有十分紧密的关系。此外，在与人们日常生活息息相关的天气预报、地图导航以及空气质量监测等场景中，遥感技术都发挥了重要作用。近些年来，随着遥感技术的不断发展，其已经具备了新的特征：高空间分辨率、高时间分辨率以及高光谱分辨率等，并且应用领域也更加广泛，深入到军事、民用的方方面面。
当前的遥感卫星任务链获取信息的链条较长，主要包含地面任务规划、遥感数据星上存储、星地数据传输以及地面接收处理数据等环节。另外，遥感卫星只能在过境时将数据传输到地面站，受通信时长和通信带宽的影响，遥感数据落地时延单位为天级，这严重影响了遥感卫星的使用时效。
近几年，5G移动通信技术进入到大规模商用阶段，许多科研机构和公司已经着手探索研究下一代移动通信技术6G。星地一体融合组网是6G中的一项关键技术，即飞行在不同轨道高度的卫星、飞行在不同空域的飞行器以及地面网络组成全新的移动通信网络。星地一体融合网络可以通过天基、空基实现对偏远地区、海上和空中的按需覆盖，同时还可以通过地面网络实现城市内的常态化网络覆盖，具有很强的实用性，同时具备灵活组网、韧性抗毁等优势。
最近，卫星互联网方案在太空也得到了验证，该方案在太空中批量部署卫星，形成一个协同计算网络，未来有望利用该网络服务于城市建设、环境监测、防灾减灾以及应急通讯等多个领域中。另一方面，还可以按照需求对卫星边缘任务进行更新，例如：通过在轨AI模型的推理，来比较山体在暴雨前后图片的变化，以期提前探查发现山体坍塌或者发生其他地质灾害的风险，提前向相关部门发出预警，帮助人们做好应急准备。因此建设一个云计算资源管理与服务系统对卫星互联网有重大意义，可以利用协同卫星的网络、存储和计算能力，使数据得到快速处理和落地，突破数据传输时延长的瓶颈。
建设卫星云的一个关键点就是整合存储资源，由于遥感影像都是大文件，且数据类型多样，非常适合利用分布式文件系统来存储。并且经过多年的发展，分布式文件系统已经很成熟，可以提供文件资源统一视图，具有海量存储，可扩展性好，冗余副本，高可用等特点。但是卫星云上的节点载核计算能力有限，并且网络拓扑也不同于传统的数据中心拓扑，是一种典型的Torus网络。Torus这种网络结构允许节点和多个邻居通信，节点之间通信有多条路由路径，这会使网络有更好的网络联通性，较强的容错能力和鲁棒性。并且由于卫星轨道的运动特征，卫星之间的距离也会变化，这对于设计分布式文件系统提出了挑战。
综上所述，本发明必须考虑卫星节点载核资源受限的特点，充分利用卫星云的网络拓扑和运动特征，设计面向卫星云的分布式文件系统，提高系统的性能和可用性。
低轨卫星指近地轨道卫星，近地轨道又称LEO(Low Earth Orbit)的高度一般在2000公里以下，由于低轨卫星距离地面较近，因此速度也较快，目前绝大多数遥感卫星、通信卫星和空间站都采用近地轨道。
一般来说星地通信采用无线电信号，而卫星星座之间通过卫星间链路(Intersatellite Link，ISL)相互连接，ISL连接着不同轨道的卫星和相同轨道的卫星。同一轨道内的卫星之间的距离在整个连接中是固定的，但不同轨道间卫星的距离是随着卫星的移动而变化的。尽管卫星移动会导致网络拓扑结构发生变化，但已建立的连接必须在网络中保持，其中每颗卫星在其轨道平面内连接到其后继卫星和前驱卫星，以及距每个相邻平面最近的卫星。并且由于太空环境下真空中光的传播速度比光纤快47％，因此与地面网络相比，卫星网络可以显着降低网络延迟。
虽然卫星尽管具有高移动性，但网络的实际拓扑不会改变，显而易见，一个星座可以建模为N×M的2D Torus网络，其中N是轨道的数量，M是轨道内卫星的数量。
随着卫星通信网络的进步，人们也在思考更多的可能性，比如LEO边缘计算。在边缘计算中，计算和存储资源嵌入网络中并靠近消费者，以提供低访问延迟、增加吞吐量、增加隐私和降低成本等。对于LEO卫星网络，网络边缘是卫星星座本身，因为卫星直接与用户设备(地面站)通信。因此很多人提出使用LEO Edge，通过向LEO卫星添加计算和存储资源，以构建CDN或物联网预处理等边缘应用程序。
而目前在卫星上支持大型存储的系统很少，CubeSat是一个先驱，CubeSat是一种用于太空研究的小型卫星，这种卫星价格较低，可以在更短的时间内完成更多的工作。但是CubeSat的存储、计算和通信能力有限，单个CubeSat本身无法完成很多工作，因此需要建立CubeSat集群。
CubeSat分布式文件系统(CDFS)就是为CubeSat集群设计的分布式存储系统，以支持后续的分布式处理。而现有的分布式文件系统，如Google文件系统、Hadoop分布式文件系统和Lustre都是为使用可靠的有线通信介质连接的分布式系统而设计的。这些文件系统并不适合在CubeSat集群上存储数据，因为传统的分布式文件系统假设通信媒介是可靠的，并且它们是专为使用机架以平面或分层方式组织节点的系统而设计的，其通信成本不是很高。而对于太空中的CubeSat集群，传统的分布式文件系统设计会带来巨大的通信开销、消耗大量电力。CDFS通过一系列的方案克服了上述问题，包括负载均衡、传输时复制和基于树的路由和聚合来控制消息减少等措施。
Cloud Constellation计划建立一个名为Space-Belt的基于低地球轨道(LEO)卫星的云基础设施，该基础设施计划为互联网服务提供商、电信业务等大型企业和政府机构提供安全的数据存储。为了解决普遍存在的全球数据不安全危机，该系统将利用LEO轨道卫星和安全地面网络的组合，允许客户在太空中安全地存储大量敏感和关键任务数据。这种系统的优点很容易被识别，因为它可以通过以下方式保护高价值数据：1.与互联网和地面租用线路完全绝缘；2.将其从网络攻击和秘密活动中解放出来；3.保护它免受地球上的自然灾害和重大事件的影响；4.解决所有管辖问题；5.规避违反隐私法规的风险。
现有方案基于天基云设计了数据存储基础的分层结构，其中数据存储层中，数据集存储在分布式服务器集群中，这些服务器部署在LEO卫星上，在每颗LEO卫星中，至少应将一台服务器嵌入到机载单元中。然后每台服务器托管一个或多个虚拟机(VM)，其中可以执行一些流行的数据存储技术，如HBase、Hive和HDFS，以提供数据管理功能。目前完全基于卫星的大规模存储系统比较少，不过有很多借助卫星，与地面数据中心想结合的存储系统。
针对地面数据中心设计的分布式文件系统主要有两大核心技术，分别是元数据管理和多副本技术。目前分布式文件系统的元数据服务主要有三种模型：集中式元数据管理、分布式元数据管理和无元数据服务的设计。
集中式元数据管理将元数据和数据存储服务二者分离，在这其中元数据服务器专门负责响应客户端的查询请求并存储元数据。这种架构十分简单清晰，GFS、HDFS和Lustre均采用这种架构，但是单一主数据服务存在单点故障问题，为此GFS通过操作日志文件来提供单一主数据服务节点的容错机制，在元数据节点出现故障后，可以依据日志文件快速启动另一台元数据节点，实现系统恢复。Lustre引入了active/standby架构模式，active元数据节点作为活跃节点满足数据节点的读写请求，standby元数据节点作为备份节点与活跃节点保持状态的同步。HDFS HA模式设计了冗余的hot-standby NameNode，负责周期性地对主NameNode内存中的元数据信息进行合并操作，发生故障后，通过Zookeeper选举新的主NameNode。数据规模较小或特定的应用环境下，单一的主数据服务在减少元数据访问的通信代价以及维护元数据的一致性开销等方面显示出了优势，但随着云计算和大数据应用对存储系统的规模、性能以及可用性方面带来的压力不断增大，单一主数据服务架构显然不能满足大数据处理的诸多要求。
分布式元数据管理模型采用集群模式，将元数据划分到集群中的不同节点上，各节点协同工作，共同提供元数据服务。与集中式元数据管理模型相比，该模型让集群中的所有节点共同分担元数据的访问压力，很好的解决了单点性能瓶颈和单点故障的问题。
分布式元数据管理模型又可分为完全对等模型和完全分布式模型。在完全对等模型中，每一个元数据节点都可以对外提供服务，节点之间通过Gossip、Paxos等一致性协议维护数据的一致性，各节点之间周期性地进行数据和状态同步。在完全分布式模型中，
集群中的节点只能提供部分元数据服务，使用时需要整合各节点的服务，共同提供元数据服务，比如Ceph和GPFS。通过其独有的CRUSH算法和动态子树划分策略，CephFS将系统的任务和元数据分散至不同的节点，各节点共同相应元数据访问请求。通过将访问压力分散到多个节点，提高了系统的吞吐率，同时也不存在单点故障问题。但是分布式元数据管理模型在设计和实现上是更复杂的，开发人员必须充分考虑分布式元数据管理导致的不一致问题和性能损耗。
无元数据服务器模型理论上是可行的，只要设计一种不依靠定位查询的元数据的寻址方式即可。在理想状态下，采用无元数据节点模型有诸多好处，不会存在与元数据相关的单点故障、性能瓶颈和分布式数据一致性等问题。因此采用无元数据节点模型可以在系统并发性和拓展性实现线性的增长，同时也提高了系统的可靠性。GlusterFS使用了此模型，它通过一种弹性哈希算法，彻底移除了元数据节点和服务，使得系统的可扩展性很好。GlusterFS通过哈希算法寻址，简化了元数据访问的通信链路，极大提升了访问元数据的效率。但是无元数据服务模型也面临着很多问题，比如某节点失效后，哈希桶需要重分布，数据迁移的成本很大，并且这种模型由于缺少中心节点，在进行目录遍历等操作时效率低下。
集中式的元数据管理方式存在单点故障和性能瓶颈，全分布式模型实现复杂，难以维护一致性，无元数据服务器模型缺少总控节点，难以控制，并且这三种模型都没有考虑网络拓扑特征。
关于多副本技术，云计算以大量廉价的商用机器为基础，所以常常会发生硬件故障，多副本技术是云计算领域中可以提高数据可靠性的一种常用技术手段。多副本技术利用增加数据的冗余副本实现，一方面可以保证数据的可靠性，另一方面提高对数据的访问效率。副本技术的一个关键点就是副本放置算法，它为各文件或数据块分配相应的存储节点集合，直接决定系统对磁盘空间、I/O、能耗等资源的利用能力，直接影响集群性能发挥和作业执行时间。这导致优化副本放置算法是优化存储系统最重要的部分。
HDFS采用一种机架感知的副本放置策略，NameNode可以获取全部DataNode的网络拓扑图，同一个机架上节点间的网络状况比不同机架的更加理想。HDFS将副本保存在同一机架和不同机架中，存储在同一机架中可以减少网络传输开销，保存不同机架中可以提高数据安全性。这种策略通过减少机架之间的数据传输，使得文件的读写效率得到提高，又因为存放在不同机架上的副本，导致数据的可靠性和安全性也得到了提高。但是由于这种策略缺少对节点负载情况、节点网络距离和节点硬件性能等因素的综合考虑，因此很容易出现负载失衡的情况。
Wentao Zhao通过考虑所有节点磁盘的空间差异来解决默认放置策略的不足，这在一定程度上使得异构HDFS节点上的数据放置策略更优。Xiaolong Ye提出一种新的副本放置策略，该策略在选择放置副本的节点时综合考虑了每个节点的实时状态和磁盘利用率，达到平衡节点工作负载的目的。
Luo提出的副本放置策略SRPM基于SVM算法，SRPM策略先对集群中的每个节点的CPU性能、磁盘转速、服务器负载等硬件信息以及节点网络距离进行特征提取，然后根据提取的特征值对节点进行分类，最后在较优的节点中选择放置副本的合适节点。Zhao Wentao提出的副本放置策略对节点存储空间敏感，该策略计算集群中节点的存储空间，然后从中选取存储空间较多的节点用于存放副本。林伟伟提出的数据副本放置策略综合考虑结点的数据负载信息和网络拓扑的距离来决策，利用线性加权法将多目标优化问题化简为单目标优化问题。选取决策值更优的数据存储节点用来存放数据副本。Jing Xu提出基于负载和用户历史信息的副本放置策略，该策略不仅利用到用户历史副本访问特征来针对性的放置副本，而且也考虑到节点的负载情况,在一定程度上提高了系统性能。Li Chunlin针对边缘云，综合考虑文件不可用、节点负载和网络传输成本等多种因素，提出了多目标优化模型来制定最优的副本放置策略，同时为了解决突发请求导致的文件访问热点问题提出了hotspots副本迁移模型，包括了获取数据节点的负载、热文件选择策略和动态副本迁移。
以上都是针对传统数据中心网络关于副本放置的研究，不同的网络拓扑采取的副本放置算法有很大区别，与有线网络相比，无线Mesh网络相邻网状节点之间的无线信道争用，以及来自相邻无线链路的干扰，导致在由许多无线跳数组成的长路径上的吞吐量显著降低。Zakwan提出了一种新的启发式算法MP-DNA，将请求节点和副本服务器之间的跳数视为我们的成本函数中要最小化的一个因素，同时考虑了内容的流行度。Zakwan在2014年又提出了改进的针对WMN副本放置的算法，针对内容在节点不均匀分布的场景进行了优化。Yaling Tao提出了一种由互联网边缘网络中的大量缓存节点构建的缓存网络方案，用于存储最终用户所需的传感器数据副本。
对于数据中心网络的副本放置，机架感知策略减少了机架之间的数据传输，提高了文件的读写效率，但是没有考虑节点负载情况、节点硬件性能、节点网络距离等因素。而网络距离感知的副本放置考虑节点之间的网络距离，但只针对数据中心网络，没有考虑负载情况。负载均衡副本放置策略综合考虑CPU、存储空间和网络I/O等因素，充分利用集群资源，但缺乏动态性，没有充分利用卫星云的Torus网络拓扑特征，而目前无线Mesh网络的副本放置方案大多针对计算、存储资源部匮乏的传感器节点，也不适用于卫星云场景。
针对数据中心网络的分布式文件系统已经非常成熟，但是卫星云的Torus网络拓扑不同于地面云，并且具有时变特性。本发明针对卫星云场景，考虑可用性和节点负载，充分利用卫星云的网络拓扑特征，设计并实现面向卫星云的分布式文件系统，提供卫星云的底层存储，保证数据的高可用，降低数据传输代价，提高数据的访问效率。
发明内容
为此，本发明首先提出一种面向卫星云的分布式文件系统，系统由5个组件组成：元数据管理模块、Storage Engine、Policy、客户端和卫星拓扑服务模块；
其中元数据管理模块以TiKV架构为基础的元数据存储模型进行元数据存储，同时采用元数据高可用设计将元数据切分成不同的数据块，并设计元数据编码方法和元数据缓存机制，保证元数据集群的负载均衡和数据的高效访问，同时设计主数据服务以建立无状态元数据节点；
Metadata Engine为元数据引擎，由元数据服务器组成，由于元数据服务器只缓存从底层KV取的元数据，并不进行持久化操作，发生宕机时重新缓存即可，因此是无状态的；
Storage Engine是数据存储模块，由全部卫星组成，每一个卫星都是块服务器，采用元数据节点的选取策略、针对低延迟访问场景的副本放置策略优化和拓扑感知的副本放置策略保存和读写块数据；
Policy是策略模块，针对卫星云场景进行，为所述元数据管理模块提供元数据的存储模型选择，为所述Storage Engine提供元数据节点的选取策略和拓扑感知的副本放置策略，针对低延迟访问场景的副本放置策略优化；
用户使用客户端与卫星云文件系统进行交互，系统之间通过专门的文件系统接口实现客户端与卫星云文件系统的交互；
卫星拓扑服务模块针对卫星云场景专门设计为卫星云文件系统提供卫星云的网络拓扑结构、星间链路距离、星地通信区间信息，为机制和策略提供输入参数；
各模块之间使用RPC进行通信。
所述元数据存储模型将元数据信息建模为键值对，用分布式KV存储系统TiKV存储，采用目录项表和索引节点表两个表来存储目录树信息，所述目录项表用于存储目录树中的内容，以多叉树结构转化成KV形式存储，多叉树的键值在首部存储父目录的索引节点Id；所述索引节点表用于存储中的索引节点信息，键值为索引节点Id，采用引用计数方法实现硬链接。
所述元数据高可用设计使用multi-raft-group的副本机制，将数据按照键值的范围划分成大致相等的切片，每一个切片会有多个副本，其中一个副本是Leader，提供读写服务，存储节点通过调度节点对这些切片以及副本进行调度，以保证数据和读写负载都均匀地分散在各个存储节点上。
所述无状态元数据节点建立方法为：主数据服务存储统一接入TiKV，块服务器通过主数据服务操作元数据，主数据服务并不实际存储数据，只缓存TiKV中的数据，同时主数据服务在内存中维护各个节点的负载情况，块服务器在启动时上报自己的网络地址，每个块服务器定期上报自身的负载信息，主数据服务在内存中维护了每个块服务器的信息。
所述元数据节点的选取策略采用基于2D-Torus网络的资源放置算法，首先将网络拓扑看成一个无权图，也就是使DM＝DN，用跳数来作为距离指标，这种被称为d-Hops放置，d为跳数，使用基本的2D-Torus资源放置算法，使得每一个节点到元数据节点的跳数都不会超过d，根据卫星云建模的N×M的2D-Torus网络拓扑，如果N和M都是k的倍数，并且k＝2d2+2d+1，一个k×k的2D-Torus网络的完美放置位置是：
[i，2d2i](mod k)，i＝0，1，…，(k-1)
由于N和M未必是k的整数倍，而是N＝pk+r和M＝qk+s，并且0<s,r<k，因而构造(p+1)×(q+1)个k×k的2D-Torus子块，然后分别使用完美放置算法，最后删除k-r行和k-s列，当DM≠DN时，网络拓扑不是一个无权图，转化基本的2D-Torus资源放置算法，将N×M延伸成N×N，其中N>M，然后再压缩成N×M。
所述拓扑感知的副本放置策略通过局部筛选，针对带宽、能量和负载均衡优化，加以使用最小生成树算法，来选取最优的副本放置方案：
考虑带宽性能，则一个节点接受到数据后，会以该节点为圆心，固定的跳数或距离为半径，圈出一个区域，之后所做的任何选取策略，只能在区域内考虑；
考虑能量性能，副本的复制路径对方法进行优化，采用链式复制的方式，将路径，选取最少中继点、将最多的副本放置位置作为存储中继的路径模式，作为优化策略；
考虑负载均衡性能，则在副本放置时，获取区域内所有节点的负载分数。负载分数用LBF表示，输入：节点存储容量Nstorage，节点计算能力Ncpu，节点通信带宽Nbandwidth，节点剩余电力Npower，总存储容量Total_Storage，总处理能力Total_Cpu，总通信带宽Total_Bandwidth，总电力Total_Power，存储权重Wstorage，计算权重Wcpu，通信带宽Wbandwidth，电力权重Wpower参数，通过如下步骤进行计算：
LBFstorage＝Nstorage÷Total_Storage
LBFcpu＝Ncpu÷Ttotal_Cpu
LBFbandwidth＝Nbandwidth÷Total_Bandwidth
LBFpower＝Nbadwidth÷Total_Power
LBF＝Wstorage×LBFstorage+Wcpu×LBFcpu+Wbandwidth×LBFbandwidth+Wpower×LBFpower
输出的LBF即负载分数；在筛选副本放置位置时，首先排除负载分数低于指定阈值的节点，然后按照各个节点的负载分数为概率进行选择，也就是说负载分数越高的节点越容易被选择；
之后综合三种方法，设计一种组合过滤优化策略，最大化减少通信代价，节约能源和带宽，并仍然保证数据的高可靠存储，假设总节点数目为N，要求的副本数目为P，具体的算法描述如下：
首先收到写请求的节点A，访问Master获取拓扑位置信息，根据指定的跳数或距离划分一个以其为中心的局部区域，过滤掉区域外的所有节点，区域内的节点数目为M，则本轮过滤掉了N-M个候选者；
之后在这些节点中，过滤掉低于负载分数阈值的节点，此时剩余M1个节点；
之后以各节点的负载分数为概率选取M1个可重复的节点，在这种情况下，负载分数高的节点很大概率被重复选取，而负载分数低的节点则小概率被选取，然后对选取出的M1个节点进行去重，剩余M2个节点；最后
在剩余的M2个节点需要选取P个节点，使节点A将数据复制到这P个节点的通信代价最小，即将剩余的M2个节点构造一个无向图，权重为跳数或距离，从A节点开始使用Prim算法构造最小生成树，当树的结点数为P+1时停止，这时使用Prim算法新增的P个节点即为最优副本放置和复制的位置。
所述针对低延迟访问场景的副本放置策略优化针对系统对同一区域进行跟踪处理、关于热点区域的数据频繁被生成，热点副本频繁被访问的场景，采取拓扑感知的组合策略，将局部选择的区域扩大到全局，在区域选择步骤不过滤节点，同时将负载过滤和负载分数概率选择作为约束，而不作为直接过滤条件，并再次使用Torus网络最优放置策略，来减少访问副本的通信代价。
所述块服务器的具体包括块存储、数据块校验、读写流程三部分；
所述块存储结构将数据块结构序列化成json格式存放在块服务器目录下；
所述数据库校验功能设计为：每一个数据块中设计若干Block，每一个Block都保存有固定4MB大小的数据，Block中保存了数据的校验和，在读取Block时需要验证存储的校验和和计算的校验和是否一致，如果不一致说明数据发生了丢失或损坏，需要用其他副本的Block数据来修正；
所述读写流程通过读流程和写流程两个独立过程实现，
所述读流程输入为chunk_id，输出为error_code，表示读流程是否成功；算法首先根据chunk_id构造出对应的ChunkReader，然后根据chunk_id可以找到数据块对应的数据块元数据文件，load进内存后就还原出了数据块的内存映像。接着对数据块包含的所有block进行遍历，每一次遍历都需要read该Block的数据，计算校验和，如果校验和验证不通过，直接返回错误，否则调用ChunkReader的add方法，调用add方法后，ChunkReader会将数据暂存在buffer中，等所有block遍历完成后，再调用ChunkReader的commit方法，ChunkReader会写一条CommitLog，表示数据块读取成功，如果在遍历block时系统宕机，认为读取数据块失败；
所述写流程输入为chunk_id和块数据data，算法首先根据chunk_id构造ChunkWriter，然后根据chunk_id将数据块的元数据信息load进内存，分配新的block_id并创建Block，写入Block数据，偏移量和校验和，然后将Block写如磁盘。接着更改数据块元数据信息，更改偏移量，插入新的block_id，将数据块信息写入磁盘后，调用ChunkWriter的commit方法进行提交，此时写入块数据成功。
所述客户端采用多线程传输数据块和Block、多接口访问的方式实现；
所述多线程传输方式在客户端调用MDS拿到文件的元数据信息后，将大文件先切分成64MB的数据块，然后submit整个数据块到线程池中，然后将数据块切分成若干Block，重新submit另外一个任务到线程池中，线程池会调用Chunkserver提供的write接口插入到对应的数据块中；
所述多接口访问方式可兼容Posix，支持Fuse挂载，并为了支持Fuse挂载建立C_Connector，将C++的接口暴露成C的接口，并定义一系列fuse_operations，将对应的接口映射到系统编写的函数。
所述卫星拓扑服务模块提供关于卫星网络拓扑相关信息，包括卫星的位置坐标，卫星与地面站的通信区间，数据来源于STK Engine批量导出的数据，本发明所述系统通过Python调用STK Engine生成源数据，为了避免频繁地启动调用STK Engine，卫星拓扑服务会保存一段时间内的数据并对外提供服务，若请求内容的时间片不在已保存的数据中，则请求STK Engine获取数据，数据的流动过程具体为：客户端通过Brpc调用卫星拓扑服务模块，如果卫星拓扑服务模块的数据库中有请求数据，直接处理返回，如果没有则需要通过Python STKAPI调用STK Engine，落库后再处理返回。
本发明所要实现的技术效果在于：
1.高可用分布式元数据管理机制。分布式文件系统的元数据管理是最基础并且重要的部分，存储了包括文件层级关系，分块存放位置等。由于卫星云的Torus网络拓扑特征，网络通信需要多跳，采用单点的元数据服务器会导致通信瓶颈，也会存在单点故障的问题。本发明研究一种针对卫星云Torus网络的高可用分布式元数据管理机制，切分元数据到不同的元数据服务器上，保证元数据的高效读取和可靠性。
2.拓扑感知的副本放置策略。副本保障了系统的可靠性，副本如何放置决定了系统是否可靠，同时也影响着系统读取效率，是分布式文件系统副本问题中很关键的一环。卫星云载核不同于强大的地面云，它的载荷存储和计算能力有限，所以必须更加充分利用已有的资源，除此之外，星间链路通信带宽也是宝贵的资源。一般情况下，数据会经过上传，等待处理，调度处理、等待落地、落地的流程，其中大部分数据写入后不会更改，并且数据不会被频繁的访问，这也就意味着全局的副本随机放置会带来严重的星间链路带宽浪费，因此本发明研究一种拓扑感知的副本放置和复制策略，利用卫星云的网络拓扑特征，最大程度地减少副本放置的通信代价和能量损耗。
3.针对低延迟访问场景的副本放置策略优化。考虑一种场特殊场景，某区域在一段时间内频繁被遥感卫星拍摄，本发明称之为热点地区，在这种场景下，关于热点地区的副本也会被频繁的访问和更新。这时副本初始放置时的通信代价不再是主要考虑因素，关键点转为数据访问和更新时通信代价。因此，本发明研究一种针对低延迟访问场景的副本放置优化策略，最大化降低访问时延。
附图说明
图1系统架构图
图2元数据目录树结构
图3分布式KV系统架构图
图4局部副本筛选策略
图5带宽和能量优化策略
图6全局副本筛选策略
图7客户端多线程上传流程
图8客户端多接口访问
图9拓扑服务交互流程
图10文件系统接口ls流程图
图11文件系统接口write流程图
具体实施方式
以下是本发明的优选实施例并结合附图，对本发明的技术方案作进一步的描述，但本发明并不限于此实施例。
本发明提出了一种面向卫星云的分布式文件系统。
系统架构：
针对现有技术存在的缺点，本发明提出一种面向卫星云的分布式文件系统，卫星云文件系统Sa tFS主要由5个组件组成：Metadata Engine、Storage Engine、Policy、Client和Topo Service。如图1所示，Metadata Engine是卫星云文件系统SatFS的元数据管理模块，搭建于TiKV之上，提供高可用、高可靠的元数据存储，同时将元数据切分成不同的Partition，保证元数据集群的负载均衡和数据的高效访问，其中Metadata Engine中的Master节点并不持久化数据，因此是无状态的。Storage Engine是数据存储模块，由全部卫星组成，每一个卫星都是Chunk Server，保存chunk数据，提供读写chunk功能。Policy是卫星云文件系统SatFS的策略模块，主要是针对卫星云场景做各种优化，包括元数据的存储模型选择，元数据节点的选取策略，拓扑感知的副本放置策略，针对低延迟访问场景的副本放置策略优化等。用户使用Client与卫星云文件系统SatFS进行交互，目前支持CLI和Fuse挂载。Topo Service是针对卫星云场景专门设计的，旨在为卫星云文件系统SatFS提供卫星云的网络拓扑结构、星间链路距离、星地通信区间等信息，为各种机制和策略提供输入参数。各模块之间使用RPC进行通信，相互协调，共同组成卫星云文件系统SatFS。
元数据管理模块：
元数据管理模块以TiKV架构为基础的元数据存储模型进行元数据存储，同时采用元数据高可用设计将元数据切分成不同的数据块，并设计元数据编码方法和元数据缓存机制，保证元数据集群的负载均衡和数据的高效访问，同时设计主数据服务以建立无状态元数据节点。
元数据存储模型；
传统的分布式文件系统比如HDFS，使用原生的NameNode作为元数据服务器时，面临很多问题：(1)元数据信息包括文件系统的树状目录结构、文件与数据块的映射关系和物理块与存储位置的映射关系全内存存储，单机承载能力有限。(2)访问元数据使用全局一把读写锁，读写吞吐性能较差；(3)随着集群数据规模增加，重启恢复时间达到小时级别，期间不能进行任何操作。
为了解决以上问题，本发明提出一种KV存储模型，将元数据信息建模为键值对，用分布式KV存储系统TiKV来存储，TiKV搭建于嵌入式数据库RocksDB之上，提供高性能的读写访问，同时也避免了内存失效。如图2是我们假想的一个有3个目录，1个符号链接和4个文件的目录树：
表1目录树信息表
Figure BDA0004149062890000101
目录树的各节点信息如表1所示，本发明采用了两个表来存储目录树信息，分别是Dentry Table和Inode Table。Dentry Table用于存储图2中Directory Tree中的内容，不同类型的Dentry保存的内容不同：
1.FILE：保存的是文件的base name和文件指向的Inode Id，根据Inode Id能够在Inode Table中唯一定位到一个Inode，因为本发明系统支持硬链接，因此，文件的引用数目、权限、owner、mtime、ctime、atime等信息均保存到Inode Table中。
2.SYMLINK：保存的是符号链接自身的base name和符号链接指向的Inode Id，根据Inode Id能够在Inode Table中唯一定位到一个Inode，Inode中保存符号链接本身的权限、owner、mtime、atime、ctime以及指向的target的名字等信息。
3.DIRECTORY：保存的是目录的base name，目录的Inode Id，以及目录的权限、owner、mtime、atime、ctime等信息。
Dentry Table本质上是一棵多叉树，而本发明系统元数据采用KV格式存储，因此需要将多叉树结构转化成KV形式，键值Key必须包含父目录的信息便于索引，首先排除父目录的目录名，因为记录整个父目录前缀会导致Key的范围较大，不利于存储。因此本发明系统在Key的首部存储父目录的Inode Id，这样通过TiKV的prefix scan特性，能够方便的列出一个目录的所有孩子节点，减少索引文件的时间复杂度。关于Key的编码，如表3所示，前面8字节固定长度是大端序存储的父目录Inode Id，后面紧跟着当前Dentry的base name。对于图2中的目录树，Dentry Table的内容如表4所示。
表3DentryTable存储格式
Figure BDA0004149062890000111
表4示例Dentry Table
Figure BDA0004149062890000112
Inode Table用于存储图2中的Inode infos，key为Inode Id，value为引用计数、文件/符号链接的权限、owner、atime、ctime和mtime等。最核心的部分是引用计数，它是用于实现硬链接的核心，对于图2中的目录树，Inode Table的内容如表5所示。
表5示例InodeTable
Figure BDA0004149062890000113
总而言之，将系统的所有元数据都表述成KV格式，这对于切分元数据和水平扩容实现了良好的基础。
元数据高可用设计：
传统的NameNode设计是有单点故障的，而且随着文件数目变多，元数据服务器的负载会越来越大，因此本发明提出用分布式KV系统来存储元数据，比如TIKV。一个分布式KV系统的架构一般如图3所示，与传统的整节点备份方式不同，分布式KV系统一般使用multi-raft-group的副本机制。将数据按照key的范围划分成大致相等的切片(下文统称为Partition)，每一个切片会有多个副本(通常是3个)，其中一个副本是Leader，提供读写服务。存储节点通过调度节点对这些Partition以及副本进行调度，以保证数据和读写负载都均匀地分散在各个存储节点上，这样的设计有很多好处：
1.高可用：分布式KV系统使用Raft协议来维持数据一致性，任何写请求都只能在Leader上写入，并且需要写入多数副本后(默认配置为3副本，即所有请求必须至少写入两个副本成功)才会返回客户端写入成功。调度节点也使用Paxos/Raft等一致性协议来避免单点故障。
2.负载均衡：分布式KV系统的调度节点通过心跳包收集各存储节点的信息，根据调度的策略来维护整个集群的Leader分布均匀，维持每个节点的存储容量均匀，维持访问热点分布均匀，控制Balance的速度，避免影响在线服务，管理节点状态等。
3.水平扩展：分布式KV系统一般都支持水平拓展，即可以新增节点而不影响线上服务。
本发明设计的元数据存储模型建立在分布式KV存储系统的基础之上，每一个MDS都与分布式KV节点建立连接，将数据存储在底层的分布式KV中，保证了高可用，提供了负载均衡和水平扩展的能力。
元数据节点选取策略：
不同于地面数据中心的扁平网络结构，卫星云的网络拓扑是一种2D-Torus网络。在地面环境中，元数据集群放置的位置不是关键因素，因为数据中心的网络不是瓶颈，但是在卫星云的场景下，元数据集群选取的策略至关重要，影响着整个系统的延迟和吞吐能力。因此本发明基于2D-Torus网络的资源放置算法，提出一种选取算法，满足不同的QoS需求。
首先考虑最简单的场景，我们将网络拓扑看成一个无权图，也就是使DM＝DN，用跳数来作为距离指标，这种被称为d-Hops放置，d为跳数，这样就可以使用基本的2D-Torus资源放置算法，使得每一个节点到元数据节点的跳数都不会超过d。根据卫星云建模的N×M的2D-Torus网络拓扑，如果N和M都是k的倍数，并且k＝2d2+2d+1，那么关于一个k×k的2D-Torus网络的完美放置位置是：
[i,2d2i](mod k),i＝0,1,…,(k-1)
但是并不是恰好N和M都是k的整数倍，更一般的情况是N＝pk+r和M＝qk+s，并且0<s,r<k，Bae和Bose提出了构造(p+1)×(q+1)个k×k的2D-Torus子块，然后分别使用完美放置算法，最后删除k-r行和k-s列，这样得出的结果并不是完美的，也就是说又可能存在一个节点到元数据节点的距离稍微大于d跳，但是并不影响实际效果。一个比较棘手的问题是DM≠DN，网络拓扑也不是一个无权图，因此需要转化一下基本的2D-Torus资源放置算法，将N×M延伸成N×N(假设N>M)，然后再压缩成N×M，从而得到最优的放置方案。
元数据编码：
前文提到了元数据主要存放在4个表中，即Dentry Table、Inode Table、FchunkTable和Dnode Table，实现上只需要针对不同的Table设置不同的key的前缀就行，表6是数据表的编码格式，inode_id和chunk_id通过allocate()分配，因为底层KV存储保存了当前已分配的最大值，所以递增即可，其中整型会转换成大端序的字符串，同时为了避免频繁获取inode_id和chunk_id，元数据节点会批量地获取inode_id和chunk_id。
表6元数据编码表
Figure BDA0004149062890000131
无状态元数据节点：
MDS存储统一接入TiKV，Chunkserver通过MDS操作元数据，但是MDS并不实际存储数据，只缓存TiKV中的数据。同时MDS在内存中维护了各个节点的负载情况，包括CPU占用率、内存使用率、磁盘剩余空间等，这些信息同样也不需要持久化，Chunkserver在启动时会上报自己的网络地址，每个Chunkserver也会定期上报自身的负载信息。MDS在内存中维护了每个Chunkserver的信息，即结构体ChunkserverInfo，如表7所示，包括Chunkserver的IP地址、开关状态、CPU占用率、总内存大小、内存使用率，总磁盘空间和剩余磁盘空间等信息，后续也需要用这些信息来做决策。所以本质上MDS是无状态的，因此不需要额外的冗余机制来保证MDS的失效，可以做到随启随停，提供很大的灵活度。元数据管理是存储计算分离的，TiKV是整个元数据的统一存储，提供无限扩容存储底座，而MDS可看作计算节点，进行元数据的计算操作。当整个系统的元数据访问压力变大时，可以扩容MDS节点，也可以扩容TiKV节点。当访问压力变小时，可以关掉一些MDS节点。当元数据的存储容量不够时，可以扩容TiKV节点。同时也可以根据业务场景，适当地调整MDS节点缓存的容量和过期策略。
表7 ChunkserverInfo结构体描述
Figure BDA0004149062890000132
元数据缓存机制：
MDS访问TiKV需要网络传输，而卫星云的网络资源是比较有限的，带宽非常宝贵，因此本发明系统在MDS上提供了缓存机制，缓存从TiKV取得的元数据，但是缓存就必然带来一致性的问题，本发明选择牺牲一部分的一致性，换取宝贵的带宽资源。
本发明采取LRU和过期时间的缓存机制，LRU(Least Recently Used)即最近最少使用，是一种常用的置换算法，选择最近最久未使用的数据予以淘汰。同时本发明通过设置数据的过期时间来保证MDS不会访问到太旧的数据，从而影响系统的一致性。MDS在缓存的内容中操作失效后，也会淘汰缓存数据，重新拉取TiKV中的数据。
副本放置策略：
包括针对低延迟访问场景的副本放置策略优化和拓扑感知的副本放置策略两部分方案构成。
拓扑感知的副本放置策略：
传统的分布式文件系统如GFS和HDFS，是专为具有扁平结构的计算机集群和具有分层结构的数据中心而设计，其中节点组织成机架和数据中心。并且具有充足的电量供应和可靠的网络，并且为这种架构设计和优化的数据分发和数据复制等操作，比如随机的副本放置，将会导致大量的通信开销和能量损耗。对此，本发明提出一种拓扑感知的副本放置策略，通过局部筛选，针对带宽、能量和负载均衡优化，加以使用最小生成树算法，来选取最优的副本放置方案。
为了减少通信开销，在一个节点接受到数据后，会以该节点为圆心，固定的跳数或距离为半径，圈出一个区域。之后所做的任何选取策略，只能在区域内考虑。如图4所示，中心的红点为客户端，写入的数据只能在红色虚线的框内放置，这对于卫星云场景是合理并有效的，因为数据被分布式存放后，会被批处理计算任务读取，在进行计算时，只需要将算子分布到各分片上即可，相比于文件数据，算子传输所占用的带宽是微小的，并且也很少有随机读取的情况，因此局部的副本放置可以有效减少数据传输的代价。
在选取副本时，如果考虑副本的复制路径，就可以做一些更细致的优化。以图5为例，假设A收到了文件数据，现在要复制两份副本。现在有两种方案，第一种是将副本放置在B和C，第二种是放置在D和E。如果分别计算A到B和C的距离与A到D和E的距离，那么都是1+2＝3个链路通信代价。但实际上第一种方案，A可以先把副本复制到C，然后C再把副本复制到B，这样只损耗了2个链路通信代价，因此第一种方案是更好的，本发明把它称作“链式复制”。因此，本发明在选择副本放置位置时，不能只考虑距离源点与各放置点的距离，还要考虑是否可使用这种优化策略。
负载均衡的目标就是将数据分发到集群中时要平衡各节点存储容量、处理能力、通信带宽和电源电力。在副本放置时，会获取区域内所有节点的负载分数。负载分数用LBF表示，计算方式如表8所示。
表8负载分数计算算法伪代码
Figure BDA0004149062890000151
在筛选副本放置位置时，首先排除负载分数低于指定阈值的节点，然后按照各个节点的负载分数为概率进行选择，也就是说负载分数越高的节点越容易被选择，基于这种副本选择方式，系统是趋向于负载均衡的。
利用上述三种优化策略，本发明提出一种组合过滤优化策略，最大化减少通信代价，节约能源和带宽，并仍然保证数据的高可靠存储。假设总节点数目为N，要求的副本数目为P，具体的算法描述如下：
1.收到写请求的节点A，访问Master获取拓扑位置信息，根据指定的跳数或距离划分一个以其为中心的局部区域，过滤掉区域外的所有节点，区域内的节点数目为M，则本轮过滤掉了N-M个候选者。
2.在这些节点中，过滤掉低于负载分数阈值的节点，此时剩余M1个节点；
3.以各节点的负载分数为概率选取M1个可重复的节点，在这种情况下，负载分数高的节点很大概率被重复选取，而负载分数低的节点则小概率被选取，然后对选取出的M1个节点进行去重，剩余M2个节点。
4.在剩余的M2个节点需要选取P个节点，使节点A将数据复制到这P个节点的通信代价最小。自然地，我们可以想到将剩余的M2个节点构造一个无向图，权重为跳数或距离，从A节点开始使用Prim算法构造最小生成树，当树的结点数为P+1时停止，这时使用Prim算法新增的P个节点即为最优副本放置和复制的位置。
针对低延迟访问场景的副本放置策略优化：
当某段时间出现热点地区时，系统可能会对同一区域进行跟踪处理，关于热点区域的数据频繁被生成，热点副本频繁被访问，在这种情况下，局部的副本放置策略会带来全局通信代价的增长，本发明针对此场景提出了全局副本选取策略，来减少地面基站访问热点数据的延迟。
同样也是采取拓扑感知的组合策略，即先根据区域进行选择，然后根据负载分数进行选择，最后使用Prim最小生成树算法生成副本放置方案。本发明针对低延迟访问场景将局部选择的区域扩大到全局，即在区域选择步骤不过滤节点。同时我们将负载过滤和负载分数概率选择作为约束，而不作为直接过滤条件。类似地，因为要保证全局的访问延迟，所以我们再次使用上文所述的Torus网络最优放置策略，来减少访问副本的通信代价。同时，由于轨道是周期性变化的，所以最优放置方案理论上有N×M种，并且是等价的。
如图6所示，根据Torus网络最优放置策略求得的结果是黑点所在的位置，同时将黑点平移得到的位置也是一种最优放置方案，取决于参考系的选择。但是这几种放置方案也是有区别的，如果选择A方案，在节点S复制副本时的通信代价明显是比较大的，排除此方案。然后比较B和C方案，可以看到B和C方案所构成的虚拟三角形都可以将S围住，但是B方案的链路通信代价为8，而C方案的链路通信代价为9，所以B方案是更好的，本发明在选取副本位置时，也依据这样的原则来选取。
块服务器模块
块服务器又称Chunkserver，主要执行读写Chunk任务，而卫星云面对的场景一般是遥感图像这样的大文件，因此本发明所述系统在实现时默认设置最大64MB的Chunk。同时为了避免空间的浪费，本发明系统将Chunk作为一种逻辑数据，每一个Chunk有若干Block，每一个Block都保存有固定4MB大小的数据。
块存储组织结构：
Chunk作为一种逻辑存储结构，不实际存储数据，如表9所示，chunk_id是chunk的唯一标识，bytes_size表示chunk实际的字节数，blocks按序存放了所有block的block_id。Block是真实的物理存储单元，如表10所示，包含了block_id，当前写block的偏移量，数据data和数据的校验和check_sum。
表9Chunk结构体描述
Figure BDA0004149062890000161
表10Block结构体描述
Figure BDA0004149062890000171
Chunk结构会被序列化成json格式存放在Chunkserver目录，Chunk相当于元数据，Block是固定大小的，同样会被持久化存储在指定Chunk的目录下。通过这种方式，有效地减少了空间浪费，同时也能提升读文件的性能。
数据块校验：
存储系统的校验机制是将用户产生的数据进行固化或者网络传输时，对原数据计算校验码并一同传输或固化，在再次使用这部分数据的时候，重新计算校验码并与保存的校验和进行对比以验证数据一致性。当网络传输受到网络环境的影响很可能产生数据错误，只有对每次网络通信进行校验才能保障数据在网络上不会丢失或出错，虽然计算校验和需要花费一定的时间，但是这是必要的，保障数据的准确性是存储系统设计的第一要素。
Block中保存了数据的校验和，可以有效避免因网络传输和系统故障导致的数据丢失和错乱，在读取Block时需要验证存储的校验和和计算的校验和是否一致，如果不一致说明数据发生了丢失或损坏，需要用其他副本的Block数据来修正。本发明所述系统使用google开源的CRC32计算校验和，生成的校验和为32位，存储在Block的checksum中。
块读写流程：
块的读写是块服务器的核心实现，块读写的性能直接影响整个分布式文件系统的读写性能，同时读写块也要容忍网络故障、断电等场景，保证块数据的一致性。块的读写主要依赖两个类完成，分别是ChunkReader和ChunkWriter，需要同时修改Chunk元数据和Block数据。
表11为读Chunk算法的伪代码，输入为chunk_id，输出为error_code，表示读流程是否成功。算法首先根据chunk_id构造出对应的ChunkReader，然后根据chunk_id可以找到Chunk对应的Chunk元数据文件，load进内存后就还原出了Chunk的内存映像。接着对Chunk包含的所有block进行遍历，每一次遍历都需要read该Block的数据，计算校验和，如果校验和验证不通过，直接返回错误，否则调用ChunkReader的add方法。调用add方法后，ChunkReader会将数据暂存在buffer中，等所有block遍历完成后，再调用ChunkReader的commit方法，ChunkReader会写一条CommitLog，表示Chunk读取成功。这样做的目的是为了保证读取Chunk时的原子性，如果在遍历block时系统宕机，因为还没有调用commit方法，所以可以认为读取Chunk失败。add和commit的设计参考了git语义，提供类似事务原子性的语义。
表11读Chunk算法伪代码
Figure BDA0004149062890000172
/>
Figure BDA0004149062890000181
块的写流程如表12所示，输入为chunk_id和块数据data。算法首先根据chunk_id构造ChunkWriter，然后根据chunk_id将Chunk的元数据信息load进内存，分配新的block_id并创建Block，写入Block数据，偏移量和校验和，然后将Block写如磁盘。接着更改Chunk元数据信息，更改偏移量，插入新的block_id，将Chunk信息写入磁盘后，调用ChunkWriter的commit方法进行提交，此时写入块数据成功。
表12写Chunk算法伪代码
Figure BDA0004149062890000182
客户端模块：
多线程传输：
在传输大文件的时候，如果按Chunk和Block顺序传输，读写性能势必会大幅度缩减，造成读写文件的延迟与文件大小成正比，这是不合理的。因此客户端必须使用多线程传输Chunk和Block。在客户端调用MDS拿到文件的元数据信息后，就可以将文件切分成Chunk，每个Chunk可以切分成若干Block，因为数据没有重叠，所有的传输都可以并行操作，Chunkserver需要对并行传输过来的Chunk和Block进行排队，有逻辑关系的数据按序写入。
本发明所述系统使用了线程池来并行传输，其中上传处理的流程如图7所示，大文件先切分成64MB的Chunk，然后submit整个Chunk到线程池中，然后将Chunk切分成若干Block，重新submit另外一个任务到线程池中，线程池会调用Chunkserver提供的write接口插入到对应的Chunk中。
多接口访问：
为了便于用户使用，本发明系统实现了多种接口接入，比如CLI，Fuse和Http接口，见图8。CLI接口是自定义接口，不兼容Posix和HDFS，但是可定制化，更加灵活方便，CLI主要通过嵌入Client的SDK来实现，其中Client与MDS和Chunkserver通过RPC通信。
同时为了兼容Posix，本发明也支持Fuse挂载，用户只需要将本发明系统挂载在某个目录下，就可以像操作内核文件系统一样操作SatFS，但是因为Fuse只支持C语言，所以系统需要建立一个C_Connector，将C++的接口暴露成C的接口。Fuse的实现方式比较固定，需要定义一系列fuse_operations，将对应的接口映射到系统编写的函数，当执行mount时，在文件系统上执行的操作就会经过VFS转换到系统编写的函数，因此又叫用户态文件系统。
另外本系统也支持Restful风格Http接口访问，Http接口通过Brpc来实现，用户不再不需要客户端，但是上传和下载文件仍需要前端来配合。
卫星拓扑服务模块：
卫星拓扑服务节点主要提供关于卫星网络拓扑相关信息，包括卫星的位置坐标，卫星与地面站的通信区间等。卫星拓扑服务本质上是一个数据服务，数据来源于STKEngine批量导出的数据，本发明所述系统通过Python调用STK Engine生成源数据，为了避免频繁地启动调用STK Engine，卫星拓扑服务会保存一段时间内的数据并对外提供服务。若请求内容的时间片不在已保存的数据中，则请求STK Engine获取数据。数据的流动大致如图9所示，Client通过Brpc调用TopoService，如果TopoService的数据库中有请求数据，直接处理返回，如果没有则需要通过Python STKAPI调用STK Engine，落库后再处理返回。
文件系统接口实现流程：
本发明所述系统目前支持的接口如表13所示，接下来分析一下ls和write两个代表性的流程，涉及到多个服务，其中ls不涉及与Chunkserver的交互。
表13文件系统接口实现列表
Figure BDA0004149062890000201
Ls流程如图10所示，MDS首先根据ls的path获取Inode Id，获取到对应path的Inode Id后，调用KV的Get方法，获取path信息。如果path是文件，那么构造文件的stat信息返回给Client即可，如果path是目录，则需要构造prefix，调用KV的PrefixScan进行前缀查询，查询出目录下所有的文件或目录，构造stat信息并返回。
Write流程如图11所示，Client发起Write请求至MDS，MDS获取该文件的Inode Id，然后计算该文件Chunk信息，包括Chunk Id和副本放置位置，将Chunk信息写入KV中并返回给Client，Client根据Chunk信息切分task，将文件分片多线程传送至对应的Chunkserver中，直到整个文件传输成功。

Claims (10)

1.一种面向卫星云的分布式文件系统，其特征在于：系统由5个组件组成：元数据管理模块、Storage Engine、Policy、客户端和卫星拓扑服务模块；
其中元数据管理模块以TiKV架构为基础的元数据存储模型进行元数据存储，同时采用元数据高可用设计将元数据切分成不同的数据块，并设计元数据编码方法和元数据缓存机制，保证元数据集群的负载均衡和数据的高效访问，同时设计元数据服务以建立无状态元数据节点；
Metadata Engine为元数据引擎，由元数据服务器组成，所述元数据服务器无状态；
Storage Engine是数据存储模块，由全部卫星组成，每一个卫星都是块服务器，采用元数据节点的选取策略、针对低延迟访问场景的副本放置策略优化和拓扑感知的副本放置策略保存和读写块数据；
Policy是策略模块，针对卫星云场景进行，为所述元数据管理模块提供元数据的存储模型选择，为所述Storage Engine提供元数据节点的选取策略和拓扑感知的副本放置策略，针对低延迟访问场景的副本放置策略优化；
用户使用客户端与卫星云文件系统进行交互；
卫星拓扑服务模块针对卫星云场景专门设计为卫星云文件系统提供卫星云的网络拓扑结构、星间链路距离、星地通信区间信息，为机制和策略提供输入参数；卫星云文件系统需要根据网络拓扑结构进行最优的副本放置策略选择，同时系统
各模块之间使用RPC进行通信，系统之间通过专门的文件系统接口实现客户端与卫星云文件系统的交互。
2.如权利要求1所述的一种面向卫星云的分布式文件系统，其特征在于：所述元数据存储模型将元数据信息建模为键值对，用分布式KV存储系统TiKV存储，采用目录项表和索引节点表两个表来存储目录树信息，所述目录项表用于存储目录树中的内容，以多叉树结构转化成KV形式存储，多叉树的键值在首部存储父目录的索引节点Id；所述索引节点表用于存储中的索引节点信息，键值为索引节点Id，采用引用计数方法实现硬链接。
3.如权利要求2所述的一种面向卫星云的分布式文件系统，其特征在于：所述元数据高可用设计使用multi-raft-group的副本机制，将数据按照键值的范围划分成大致相等的切片，每一个切片会有多个副本，其中一个副本是Leader，提供读写服务，存储节点通过调度节点对这些切片以及副本进行调度，以保证数据和读写负载都均匀地分散在各个存储节点上。
4.如权利要求3所述的一种面向卫星云的分布式文件系统，其特征在于：所述无状态元数据节点建立方法为：主数据服务存储统一接入TiKV，块服务器通过主数据服务操作元数据，主数据服务并不实际存储数据，只缓存TiKV中的数据，同时主数据服务在内存中维护各个节点的负载情况，块服务器在启动时上报自己的网络地址，每个块服务器定期上报自身的负载信息，主数据服务在内存中维护了每个块服务器的信息。
5.如权利要求4所述的一种面向卫星云的分布式文件系统，其特征在于：所述元数据节点的选取策略采用基于2D-Torus网络的资源放置算法，首先将网络拓扑看成一个无权图，也就是使DM＝DN，用跳数来作为距离指标，这种被称为d-Hops放置，d为跳数，使用基本的2D-Torus资源放置算法，使得每一个节点到元数据节点的跳数都不会超过d，根据卫星云建模的N×M的2D-Torus网络拓扑，如果N和M都是k的倍数，并且k＝2d2+2d+1，一个k×k的2D-Torus网络的完美放置位置是：
[i，2d2i](mod k)，i＝0，1，...，(k-1)
由于N和M未必是k的整数倍，而是N＝pk+r和M＝qk+s，并且0＜s，r＜k，因而构造(p+1)×(q+1)个k×k的2D-Torus子块，然后分别使用完美放置算法，最后删除k-r行和k-s列，当DM≠DN时，网络拓扑不是一个无权图，转化基本的2D-Torus资源放置算法，将N×M延伸成N×N，其中N＞M，然后再压缩成N×M。
6.如权利要求5所述的一种面向卫星云的分布式文件系统，其特征在于：所述拓扑感知的副本放置策略通过局部筛选，针对带宽、能量和负载均衡优化，加以使用最小生成树算法，来选取最优的副本放置方案：
考虑带宽性能，则一个节点接受到数据后，会以该节点为圆心，固定的跳数或距离为半径，圈出一个区域，之后所做的任何选取策略，只能在区域内考虑；
考虑能量性能，副本的复制路径对方法进行优化，采用链式复制的方式，将路径，选取最少中继点、将最多的副本放置位置作为存储中继的路径模式，作为优化策略；
考虑负载均衡性能，则在副本放置时，获取区域内所有节点的负载分数。负载分数用LBF表示，输入：节点存储容量Nstorage，节点计算能力Ncpu，节点通信带宽Nbandwidth，节点剩余电力Npower，总存储容量Total_Storage，总处理能力Total_Cpu，总通信带宽Total_Bandwidth，总电力Total_Power，存储权重Wstorage，计算权重Wcpu，通信带宽Wbandwidth，电力权重Wpower参数，通过如下步骤进行计算：
LBFstorage＝Nstorage÷Total_Storage
LBFcpu＝Ncpu÷Total_Cpu
LBFbandwidth＝Nbandwidth÷Total_Bandwidth
LBFpower＝Nbandwidth÷Total_Power
LBF＝Wstorage×LBFstorage+Wcpu×LBFcpu+Wbandwidth×LBFbandwidth+Wpower×LBFpower
输出的LBF即负载分数；在筛选副本放置位置时，首先排除负载分数低于指定阈值的节点，然后按照各个节点的负载分数为概率进行选择，也就是说负载分数越高的节点越容易被选择；
之后综合三种方法，设计一种组合过滤优化策略，最大化减少通信代价，节约能源和带宽，并仍然保证数据的高可靠存储，假设总节点数目为N，要求的副本数目为P，具体的算法描述如下：
首先收到写请求的节点A，访问Master获取拓扑位置信息，根据指定的跳数或距离划分一个以其为中心的局部区域，过滤掉区域外的所有节点，区域内的节点数目为M，则本轮过滤掉了N-M个候选者；
之后在这些节点中，过滤掉低于负载分数阈值的节点，此时剩余M1个节点；
之后以各节点的负载分数为概率选取M1个可重复的节点，在这种情况下，负载分数高的节点很大概率被重复选取，而负载分数低的节点则小概率被选取，然后对选取出的M1个节点进行去重，剩余M2个节点；最后在剩余的M2个节点需要选取P个节点，使节点A将数据复制到这P个节点的通信代价最小，即将剩余的M2个节点构造一个无向图，权重为跳数或距离，从A节点开始使用Prim算法构造最小生成树，当树的结点数为P+1时停止，这时使用Prim算法新增的P个节点即为最优副本放置和复制的位置。
7.如权利要求6所述的一种面向卫星云的分布式文件系统，其特征在于：所述针对低延迟访问场景的副本放置策略优化针对系统对同一区域进行跟踪处理、关于热点区域的数据频繁被生成，热点副本频繁被访问的场景，采取拓扑感知的组合策略，即先根据区域进行选择，然后根据负载分数进行选择，最后使用Prim最小生成树算法生成副本放置方案；区别是将局部选择的区域扩大到全局，即在区域选择步骤不过滤节点，同时将负载过滤和负载分数概率选择作为约束，而不作为直接过滤条件，并再次使用所述Torus网络最优放置策略，来减少访问副本的通信代价。
8.如权利要求7所述的一种面向卫星云的分布式文件系统，其特征在于：所述块服务器的具体包括块存储、数据块校验、读写流程三部分；
所述块存储结构将数据块结构序列化成json格式存放在块服务器目录下；
所述数据库校验功能设计为：每一个数据块中设计若干Block，每一个Block都保存有固定4MB大小的数据，Block中保存了数据的校验和，在读取Block时需要验证存储的校验和和计算的校验和是否一致，如果不一致说明数据发生了丢失或损坏，需要用其他副本的Block数据来修正；
所述读写流程通过读流程和写流程两个独立过程实现，
所述读流程输入为chunk_id，输出为error_code，表示读流程是否成功；算法首先根据chunk_id构造出对应的ChunkReader，然后根据chunk_id可以找到数据块对应的数据块元数据文件，load进内存后就还原出了数据块的内存映像。接着对数据块包含的所有block进行遍历，每一次遍历都需要read该Block的数据，计算校验和，如果校验和验证不通过，直接返回错误，否则调用ChunkReader的add方法，调用add方法后，ChunkReader会将数据暂存在buffer中，等所有block遍历完成后，再调用ChunkReader的commit方法，ChunkReader会写一条CommitLog，表示数据块读取成功，如果在遍历block时系统宕机，认为读取数据块失败；
所述写流程输入为chunk_id和块数据data，算法首先根据chunk_id构造ChunkWriter，然后根据chunk_id将数据块的元数据信息load进内存，分配新的block_id并创建Block，写入Block数据，偏移量和校验和，然后将Block写如磁盘。接着更改数据块元数据信息，更改偏移量，插入新的block_id，将数据块信息写入磁盘后，调用ChunkWriter的commit方法进行提交，此时写入块数据成功。
9.如权利要求8所述的一种面向卫星云的分布式文件系统，其特征在于：所述客户端采用多线程传输数据块和Block、多接口访问的方式实现；
所述多线程传输方式在客户端调用MDS拿到文件的元数据信息后，将大文件先切分成64MB的数据块，然后submit整个数据块到线程池中，然后将数据块切分成若干Block，重新submit另外一个任务到线程池中，线程池会调用Chunkserver提供的write接口插入到对应的数据块中；
所述多接口访问方式可兼容Posix，支持Fuse挂载，并为了支持Fuse挂载建立C_Connector，将C++的接口暴露成C的接口，并定义一系列fuse_operations，将对应的接口映射到系统编写的函数。
10.如权利要求9所述的一种面向卫星云的分布式文件系统，其特征在于：所述卫星拓扑服务模块提供关于卫星网络拓扑相关信息，包括卫星的位置坐标，卫星与地面站的通信区间，数据来源于STK Engine批量导出的数据，本发明所述系统通过Python调用STKEngine生成源数据，为了避免频繁地启动调用STK Engine，卫星拓扑服务会保存一段时间内的数据并对外提供服务，若请求内容的时间片不在已保存的数据中，则请求STK Engine获取数据，数据的流动过程具体为：客户端通过Brpc调用卫星拓扑服务模块，如果卫星拓扑服务模块的数据库中有请求数据，直接处理返回，如果没有则需要通过Python STK API调用STK Engine，落库后再处理返回。
CN202310312635.4A 2023-03-28 2023-03-28 一种面向卫星云的分布式文件系统 Pending CN116401225A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202310312635.4A CN116401225A (zh) 2023-03-28 2023-03-28 一种面向卫星云的分布式文件系统

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202310312635.4A CN116401225A (zh) 2023-03-28 2023-03-28 一种面向卫星云的分布式文件系统

Publications (1)

Publication Number Publication Date
CN116401225A true CN116401225A (zh) 2023-07-07

Family

ID=87017151

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202310312635.4A Pending CN116401225A (zh) 2023-03-28 2023-03-28 一种面向卫星云的分布式文件系统

Country Status (1)

Country Link
CN (1) CN116401225A (zh)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116610756A (zh) * 2023-07-17 2023-08-18 山东浪潮数据库技术有限公司 一种分布式数据库自适应副本选择方法及装置
CN117149097A (zh) * 2023-10-31 2023-12-01 苏州元脑智能科技有限公司 一种分布式存储系统数据访问控制方法及装置
CN117207199A (zh) * 2023-11-08 2023-12-12 北京星河动力装备科技有限公司 太空机械臂控制方法、装置、系统、电子设备和存储介质
CN117407374A (zh) * 2023-12-12 2024-01-16 创云融达信息技术(天津)股份有限公司 一种基于分布式文件系统的分布式锁实现方法和系统
CN118018563A (zh) * 2024-04-10 2024-05-10 厦门福慧康电子科技有限公司 一种具有分布式存储结构的系统

Cited By (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116610756A (zh) * 2023-07-17 2023-08-18 山东浪潮数据库技术有限公司 一种分布式数据库自适应副本选择方法及装置
CN116610756B (zh) * 2023-07-17 2024-03-08 山东浪潮数据库技术有限公司 一种分布式数据库自适应副本选择方法及装置
CN117149097A (zh) * 2023-10-31 2023-12-01 苏州元脑智能科技有限公司 一种分布式存储系统数据访问控制方法及装置
CN117149097B (zh) * 2023-10-31 2024-02-06 苏州元脑智能科技有限公司 一种分布式存储系统数据访问控制方法及装置
CN117207199A (zh) * 2023-11-08 2023-12-12 北京星河动力装备科技有限公司 太空机械臂控制方法、装置、系统、电子设备和存储介质
CN117207199B (zh) * 2023-11-08 2024-03-22 北京星河动力装备科技有限公司 太空机械臂控制方法、装置、系统、电子设备和存储介质
CN117407374A (zh) * 2023-12-12 2024-01-16 创云融达信息技术(天津)股份有限公司 一种基于分布式文件系统的分布式锁实现方法和系统
CN117407374B (zh) * 2023-12-12 2024-02-27 创云融达信息技术(天津)股份有限公司 一种基于分布式文件系统的分布式锁实现方法和系统
CN118018563A (zh) * 2024-04-10 2024-05-10 厦门福慧康电子科技有限公司 一种具有分布式存储结构的系统

Similar Documents

Publication Publication Date Title
CN116401225A (zh) 一种面向卫星云的分布式文件系统
Jiang et al. QoE-aware efficient content distribution scheme for satellite-terrestrial networks
US10929428B1 (en) Adaptive database replication for database copies
CN107734026B (zh) 一种网络附加存储集群的设计方法、装置及设备
CN107544862B (zh) 一种基于纠删码的存储数据重构方法和装置、存储节点
CN103268318B (zh) 一种强一致性的分布式键值数据库系统及其读写方法
US7657578B1 (en) System and method for volume replication in a storage environment employing distributed block virtualization
CN106446126B (zh) 一种海量空间信息数据存储管理方法及存储管理系统
US10558565B2 (en) Garbage collection implementing erasure coding
CN106156359A (zh) 一种云计算平台下的数据同步更新方法
CN104754001A (zh) 云存储系统和数据存储方法
CN102752404B (zh) 一种新型的灾难备份恢复方法与系统
US11734248B2 (en) Metadata routing in a distributed system
US20140081919A1 (en) Distributed backup system for determining access destination based on multiple performance indexes
CN105138615A (zh) 一种构建大数据分布式日志的方法和系统
CN103098015A (zh) 存储系统
CN103763155A (zh) 分布式云存储系统多服务心跳监测方法
WO2019034999A2 (en) SPEEDABLE SPATIAL-TEMPORAL DENSITY DATA FUSION
CN103180842A (zh) 云计算系统和用于该云计算系统的数据同步方法
CN104539681A (zh) 分布式gis加速系统和gis服务的处理方法
US10909143B1 (en) Shared pages for database copies
CN105426427A (zh) 基于raid 0 存储的mpp 数据库集群副本实现方法
Ye et al. Secure, dependable, and high performance cloud storage
CN101808127A (zh) 数据备份方法、系统和服务器
US20230367749A1 (en) Data migration method and apparatus, device, medium, and computer product

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination