面向航天應用的對象存儲系統設計

宮永生，呂從民，曹素芝

(1.中國科學院空間應用工程與技術中心，北京100094；2.中國科學院大學，北京100049)

1 引言

隨著太空探索逐步深入，空間應用的規模大幅擴展，相應地出現了載人空間站等大型飛行器及低軌互聯網衛星星座等空間應用形態，且未來會向著月球基地、火星基地以及更深遠的太空進一步拓展?？臻g應用的擴展對空間信息系統的發展提出了新的要求，空間信息系統的架構走向以組網為基礎分布式形態，包括飛行器內部基于有線網絡的分布式存儲和處理以及多個飛行器間的空間無線網絡分布式信息存儲和處理?？臻g信息系統架構的演進意味著必須考慮如何在空間部署分布式存儲系統，以滿足未來空間應用的需求。

對象存儲系統通過創新性的分布式架構設計，解決了資源共享、超高速存儲、海量存儲、高可靠、可擴展等數據存儲系統面臨的難題，在地面大規模數據存儲系統中獲得廣泛應用。國際互聯網工程任務組(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 客戶端

客戶端是用戶訪問對象存儲系統的入口，將用戶直接的數據讀寫轉換為對象存儲系統內部的數據訪問?？蛻舳似帘螌ο蟠鎯ο到y內部訪問細節，對用戶提供直接的標準數據訪問接口。

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個對象存儲設備，如果當前備份編號大于等于備份次數需求，則只進行數據對象保存而不進行后續的備份工作。通過該機制能夠以簡單的方式實現系統中存儲多個數據備份的需求。

在系統運行過程中，如某個備份節點發生了損壞，則會導致系統中有效數據備份數目減少。如果需要對象存儲系統中始終存在滿足需求的備份數目，則需要設計數據遷移策略，在監測到數據存儲設備故障導致備份數目不足的情況下，啟動數據遷移?？臻g數據備份策略的需求是為了解決數據存儲設備故障的情況，避免關鍵數據的單點失效不可恢復，而不是追求系統在長時間運行中始終維持多個備份數據的存在。綜合考慮空間應用數據的使用需求以及數據遷移帶來的網絡傳輸代價，本文不考慮數據遷移算法的設計，即數據備份策略只在初次數據寫入的時候執行，保證系統中存在滿足需求的備份數目，而后續設備故障導致的備份丟失不會觸發數據遷移操作。

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 結論

本文針對空間站空間應用場景，設計了小規模對象存儲系統，研究了空間數據對象格式定義、對象存儲系統架構和協議、系統數據備份策略等問題，提出了適應場景的設計方案，并進行了系統驗證。驗證結果表明:在航天專用的嵌入式環境下，通過對象存儲系統解決資源共享、高速存儲、高可靠、可擴展等數據存儲系統面臨的難題是一種可行的途徑。