一種擬態存儲元數據隨機性問題解決方法

楊 珂，張 帆，郭 威，趙 博，穆 清

（1.戰略支援部隊信息工程大學，鄭州 450001；2.數學工程與先進計算國家重點實驗室，鄭州 450001）

0 概述

近年來，云計算和大數據技術的發展普及推動了互聯網服務模式的快速變革，以數據中心為代表的新一代信息基礎設施成為國內外社會建設發展的重點方向。數據存儲系統作為信息基礎設施中的重要組成部分，未來將承載更多的核心業務數據與用戶隱私數據，因此，其安全性也越來越受到關注和重視。然而，隨著“棱鏡門”［1］等各類網絡安全事件的頻發，產業界和學術界逐漸意識到傳統安全手段的缺陷，以防火墻［2］、IDS［3］、IPS［4］等為代表的被動防御方法已經難以滿足新一代信息技術背景下人們對網絡安全的需求［5］。

網絡空間擬態防御（Cyberspace Mimic Defense，CMD）［6］是一種新型的主動防御技術，其基于動態異構冗余（Dynamic Heterogeneous Redundancy，DHR）的擬態構造模型，賦予目標對象內生安全［7］功能屬性，使其能夠有效應對未知漏洞、后門等攻擊威脅，從而克服傳統防御手段的不足。擬態存儲是CMD技術在數據存儲系統上的具體實現，是解決新一代信息基礎設施中數據與存儲系統安全性問題的可行方案［8］。目前，研究人員已經在分布式存儲架構中成功導入擬態DHR 模型，并驗證了其提升數據與系統安全的有效性［8］。但與此同時，學者們也總結出擬態存儲系統中需要進一步關注并解決的諸多問題，包括大規模集群異構冗余化帶來的開銷和可實現性問題、執行體運行狀態不一致問題、擬態構造的調度和裁決策略問題等［9］。

本文針對擬態存儲中執行體運行狀態不一致問題展開研究，介紹擬態防御技術的相關研究以及擬態存儲基本架構，分析和驗證系統運行過程中由元數據隨機性所導致的問題，在此基礎上，設計實現相應的校正同步方法，并在實際系統中對元數據再同步方法的性能進行驗證。

1 相關工作

網絡空間擬態防御是實現信息系統內生安全的一種普適性方法，目前已經在工業控制處理器［10］、路由器［11］、DNS 服務器［12］、SDN［13-14］等領域得到一定的應用。擬態DHR 是網絡空間擬態防御方法中的核心模型，其結構如圖1 所示。

圖1 擬態DHR 模型Fig.1 Model of mimic DHR

DHR 模型［15］的構建基礎是一定數量的異構執行體，它們在功能上等價，但基于不同的硬件平臺、操作系統、運行環境等，因此，不同執行體所攜帶的漏洞后門也不完全相同，會對不同的攻擊產生獨立的響應輸出。通過對多個執行體輸出進行比較驗證，能夠有效判斷系統狀態，屏蔽異常而得到正確的結果，并且有針對性地對受攻擊執行體進行清洗、替換等操作。擬態DHR 模型具有構造安全的普適性，對已知和未知漏洞后門等均能實現有效防御，大幅增強了網絡應對外部入侵和內部滲透的能力［6，16］。文獻［6］指出，DHR 結構的防御成本隨著執行體數量N線性增加，但防御效果是非線性增加的，當N≥3 時，其安全性已經取得大幅提高。綜合考慮成本和安全性，在已實現的擬態防御系統中，一般采用3 個異構執行體，因此，本文在模型分析和實際測試時，將執行體數量設為3。

由于DHR 模型需要對防護目標構建異構冗余的多執行體，因此在分布式存儲架構中導入擬態防御方法要盡可能選取系統核心功能與數據的承載體，避免造成過大的成本和性能開銷。文獻［8］比較了分布式存儲系統中對不同對象進行擬態化設計的成本、可實現性以及有效性，最終確定將元數據功能節點（NameNode）作為擬態防護邊界，以盡可能取得最大的安全/成本收益比，其擬態存儲的基本架構如圖2 所示。

圖2 擬態存儲的基本架構Fig.2 The basic architecture of mimic storage

面向元數據服務的擬態存儲架構主要對元數據服務器進行擬態化改造，包含異構冗余化的執行體集合、配合分發裁決代理和調度控制器，從而實現防御功效。擬態存儲用擬態化的元數據服務結構取代一般分布式存儲系統中單一的元數據節點，對外的基本功能一致，但內部結構和處理流程對外是不可見的。在擬態化元數據服務結構內部，主要包括以下3 個模塊：

1）輸入輸出代理，主要負責分發客戶端請求、對執行體執行結果進行裁決和反饋。

2）異構元數據執行體集合，包括若干個異構的元數據執行體，各自獨立地執行客戶端請求并分別向輸入輸出代理反饋執行結果。

3）調度控制器，按照一定規則對執行體進行下線、清洗、上線等操作。

當元數據服務結構收到來自客戶端的請求消息時，輸入輸出代理將消息分發給所有在線的執行體，執行體分別執行操作并將結果發送到輸入輸出代理，輸入輸出代理按照一定規則對執行結果進行裁決，得到最終的輸出消息，同時將裁決結果發送給調度控制器，調度控制器根據裁決結果對執行體進行下線、清洗、上線等操作。為了保證多個執行體的功能等價，不僅需要在設計和開發階段保證執行體功能的一致性，還需要在存儲系統工作過程中保持執行體狀態的一致性，否則存儲系統將無法正常運行。

2 元數據隨機性問題

所有執行體是獨立運行且互不可見的，而每一個元數據執行體中都保存著用戶所有的元數據信息，如果這些執行體中保存的元數據信息出現了不一致的情況，將會導致執行體輸出不一致、裁決出現異常等問題，嚴重影響擬態存儲系統的正常工作。

在元數據節點NameNode 中存在隨機性的算法和邏輯，在工作正常的情況下也會出現若干NameNode 執行結果不一致的問題，如寫入文件指令會引發執行體隨機性邏輯，客戶端發送一個寫入文件的指令，執行體會隨機選擇一個數據節點，然后在該節點的同一機架和其余機架上分別再隨機選擇一個數據節點，即每個執行體會給出3 個具有一定隨機性的寫入地址，此時不同的執行體內部狀態就會大概率出現不一致的情況。不同步的元數據執行體示意圖如圖3 所示。

圖3 不同步的元數據執行體示意圖Fig.3 Schematic diagram of unsynchronized NameNode executors

圖3 所示流程為：

1）客戶端寫入一個文件M。

2）執行體返回3 組不同的寫入地址。

3）裁決器按照一定策略對執行體的返回結果進行裁決。

4）客戶端得到最終的寫入地址。

可以看出，雖然客戶端得到了預期的返回消息，但是此時3 個執行體所存儲的元數據不一致，即執行體的狀態不一致。本文在真實的擬態存儲環境中進行測試，結果如圖4 所示，可以看出，當執行存在隨機性的指令時，執行體狀態出現了不一致的情況，此時如果訪問寫入的文件，就會出現不可預知的錯誤。

圖4 執行體狀態不一致的測試結果Fig.4 Test results of inconsistent states of the executors

元數據的狀態同步是擬態裁決機制正常工作的基礎，然而元數據隨機性問題會使得系統產生誤判，導致整個擬態存儲系統無法正常運轉。因此，在擬態存儲中，解決NameNode 同步問題顯得尤為重要。

3 元數據再同步方法

3.1 解決思路

不同于傳統的關系型數據庫，在分布式存儲系統中存在CAP 原則，即在分布式系統的一致性（Consistency）、可用性（Availability）、分區容錯 性（Partition Tolerance）3 個屬性中，最多只能同時滿足2 個，三者不可兼顧。因此，在擬態存儲架構設計中必須有所取舍，根據分布式系統CAP 原則，要保證可用性和分區容錯性，只能犧牲一致性［17］。一致性一般分為如下3 類：

1）強一致性，即客戶端操作完成之后馬上就可以訪問更新過的值。

2）弱一致性，即客戶端操作完成后，不能保證馬上訪問到更新過的值，系統也不保證訪問時效。

3）最終一致性，其為弱一致性的特殊形式，保證在沒有后續操作的前提下系統最終返回上次更新的值［18］。

在工程實踐中，為了保證系統的可用性，通常將強一致性需求轉換成最終一致性需求［19-20］。基于這個思路，本文考慮用最終一致性的流程和相關機制來解決元數據的隨機性問題。

3.2 再同步方法

針對上述擬態存儲中元數據的隨機性問題，本文提出一種元數據再同步方法，其基本流程如圖5所示。

圖5 元數據再同步方法流程Fig.5 Procedure of metadata resynchronization method

本文元數據再同步方法在輸入輸出代理中增加NameNode 執行體狀態監視模塊并引入映射同步機制，系統工作流程如下：

1）客戶端發送請求消息。

2）輸入輸出代理將消息轉發給各個執行體。

3）執行體進行消息處理，并將響應結果發送給裁決器。

4）輸入輸出代理將裁決結果發出。

5）狀態監視模塊檢測到執行體狀態不一致，建立映射同步，記錄輸入指令和輸出結果的映射關系。

6）輸入輸出代理收到上報消息。

7）狀態監視模塊將上報信息反饋給各個執行體進行同步。

8）同步完成后執行體給狀態監視模塊發送確認信息。

9）狀態監視模塊清除映射同步信息，完成同步。

在同步過程中，整個流程最關鍵的步驟在于映射同步的建立。當狀態監視模塊檢測到執行體狀態不一致時，立即記錄客戶端的指令和裁決器的輸出結果，建立兩者的映射關系。在元數據再同步的過程中，如果客戶端再次訪問該條元數據而不經過執行體，通過映射同步可以直接給出訪問結果。如果缺少映射同步，客戶端訪問時執行體狀態尚未完成同步，依然無法得到正確的結果。映射同步僅存續在元數據同步期間，當同步完成之后，映射同步失去作用并隨即清除，從而減少資源占用。

4 實驗評估

本節將對元數據再同步方法進行實驗，以驗證該方法的有效性，并評估其對服務性能的影響，從而為后續研究提供依據。實驗內容主要分為2 個部分：

1）功能測試，即在真實的擬態存儲環境中添加再同步方法的相關功能代碼，測試其能否有效解決元數據隨機性問題。

2）性能測試，主要通過對比測試的方法觀察元數據同步過程中的開銷，以評估再同步方法對擬態存儲系統性能的影響。

4.1 實驗環境

本次實驗在擬態存儲工程樣機上進行。在硬件環境方面，基于異構化組件構建物理服務器，部署3 臺元數據執行體和4 臺數據節點，另外還包括1 臺分發裁決節點、1 臺內部管理節點以及相應的交換機、測試客戶端機。在軟件方面，在元數據執行體上分別部署CentOS、Solaris 和國產麒麟操作系統，存儲中間件使用典型的大數據分布式存儲Hadoop 2.7.3，抓包工具采用Tcpdump version 4.9.2，libpcap version 1.5.3，分析工具使用集成hadoop 協議的wireshark 版本，性能測試采用TestDFSIO 標準軟件工具。整個實驗環境拓撲如圖6所示。

圖6 測試環境拓撲Fig.6 Test environment topology

在功能測試中，通過外部存儲客戶端發起可觸發元數據執行體隨機性邏輯的上傳文件指令，然后在分發裁決節點進行抓包分析，并在內部管理平臺登錄查看各個執行體的工作日志，觀察系統是否能夠通過再同步方法解決隨機性邏輯導致的狀態不一致問題；在性能測試中，通過外部存儲客戶端分別對再同步功能開啟前后發起基本讀寫命令，以評估本文方法的實際運行開銷。

4.2 功能測試

通過文獻［21-22］可知，Hadoop 分布式存儲HDFS 的數據塊分配算法Block_allocate 具有隨機性，因此，本次實驗選取能夠觸發該算法的數據寫入操作（hdfs-put）進行測試，各個元數據執行體（簡記為NNx）返回的消息包結果如圖7 所示。

圖7 數據塊分配返回的消息包對比Fig.7 Comparison of message packets returned from data block allocation

圖7 顯示，NN1 分配的數據節點為DN1、DN3、DN4，而NN2 和NN3 分配的數據節點為DN2、DN3、DN4，元數據執行體Block_allocate 算法的隨機性被觸發。從圖8 可以看出，各個NN 對上傳文件的初次分配位置不同，其內容與圖7 中網絡消息包的返回一致，即元數據執行體運行狀態發生不一致的情況，此時繼續在分發表決節點抓包，觀察實際存儲的數據節點是否發起了再同步消息。

圖8 不同執行體上的塊分配日志記錄Fig.8 Block allocation logging on different executors

如圖9所示，DN1、DN3、DN4為實際存儲該文件的數據節點，它們在接收到上傳數據后向系統上報自己的接收事件（RECEIVED），分發表決器將此消息包再轉發至各個執行體進行再同步操作，此時觀察NN 上的運行日志。圖10 以初次分配DN2、DN3、DN4 的NN3為例，可以觀察到，NN3 在收到RECEIVED 消息包后，重新更新測試文件存儲位置的信息，將實際發起再同步數據包的DN1、DN3、DN4 添加為對應的存儲節點，即本文的再同步設計生效。為了更直觀地驗證再同步方法的有效性，通過存儲客戶端對寫入的測試文件進行讀取，可抓取到系統響應數據包如圖11 所示。

圖9 分發表決器收到的再同步消息包Fig.9 Resynchronization message packet received by the distribution and voting machine

圖10 NN3 執行體上的日志記錄Fig.10 Logging on NN3 executor

圖11 再同步后數據塊分配的返回消息包Fig.11 Returned message packet of data block allocation after resynchronization

從圖11 可以看出，在經過元數據的再同步后，當外部對測試上傳文件發起請求，各個元數據執行體的返回結果均為DN1、DN3、DN4 及其位置信息，可知其對應的元數據已經保持一致。繼續重復上述操作并檢查執行體狀態，再同步機制均能解決元數據隨機性問題，同步成功率可達100%。

4.3 性能測試

性能測試基于標準的TestDFSIO 工具對系統發起數據服務請求。由于本文的再同步方法并不涉及數據讀操作，其主要解決數據寫操作中出現的元數據隨機性問題，因此性能測試以寫操作作為主要請求內容。寫容量大小設定為10 GB，在擬態存儲配置單個塊64 MB 的條件下，對比再同步機制開啟前后的性能。如圖12、圖13 所示，客戶端能夠正常運行TestDFSIO 測試工具且生成規定大小的文件，不報錯。數據顯示，當擬態存儲未開啟再同步機制時，整個過程耗時337.955 s，寫入速率為30.488 MB/s；當擬態存儲開啟再同步機制后，總用時為349.180 s，寫入速率為29.490 MB/s。可以看出，對于一個數量較大的連續寫操作，再同步機制會造成一定程度的性能損失，但對于用戶而言是可接受的，并且在實際應用場景下，讀寫操作通常是穿插進行的，再同步機制的開銷能夠更好地分散在寫與寫的操作間隙，從而在一定程度上緩解性能損失，提高用戶體驗質量。

圖12 未開啟再同步機制的寫入測試結果Fig.12 Write test results without resynchronization mechanism

圖13 開啟再同步機制后的寫入測試結果Fig.13 Write test results with resynchronization mechanism

5 結束語

為了解決擬態存儲中的元數據隨機性問題，本文對擬態存儲工作流程進行分析，提出一種元數據再同步方法，以在不影響元數據對外服務的情況下實現NameNode 執行體狀態同步。在擬態存儲真實環境中的測試結果表明，本文方法能夠有效解決元數據隨機性問題，保證擬態存儲裁決機制的正常運行，提升擬態存儲系統的穩定性。后續將進一步優化NameNode 執行體同步過程，將帶有隨機性邏輯的功能部分遷移到分發表決代理或替換為偽隨機工作模式，從而減少再同步的流程步驟，縮短時間開銷，盡可能緩解同步過程造成的擬態存儲系統處理性能下降問題。