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

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

0 概述

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

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

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

1 相關工作

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

圖1 擬態(tài)DHR 模型Fig.1 Model of mimic DHR

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

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

圖2 擬態(tài)存儲的基本架構Fig.2 The basic architecture of mimic storage

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

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

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

3）調(diào)度控制器，按照一定規(guī)則對執(zhí)行體進行下線、清洗、上線等操作。

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

2 元數(shù)據(jù)隨機性問題

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

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

圖3 不同步的元數(shù)據(jù)執(zhí)行體示意圖Fig.3 Schematic diagram of unsynchronized NameNode executors

圖3 所示流程為：

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

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

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

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

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

圖4 執(zhí)行體狀態(tài)不一致的測試結果Fig.4 Test results of inconsistent states of the executors

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

3 元數(shù)據(jù)再同步方法

3.1 解決思路

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

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

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

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

在工程實踐中，為了保證系統(tǒng)的可用性，通常將強一致性需求轉換成最終一致性需求［19-20］?；谶@個思路，本文考慮用最終一致性的流程和相關機制來解決元數(shù)據(jù)的隨機性問題。

3.2 再同步方法

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

圖5 元數(shù)據(jù)再同步方法流程Fig.5 Procedure of metadata resynchronization method

本文元數(shù)據(jù)再同步方法在輸入輸出代理中增加NameNode 執(zhí)行體狀態(tài)監(jiān)視模塊并引入映射同步機制，系統(tǒng)工作流程如下：

1）客戶端發(fā)送請求消息。

2）輸入輸出代理將消息轉發(fā)給各個執(zhí)行體。

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

4）輸入輸出代理將裁決結果發(fā)出。

5）狀態(tài)監(jiān)視模塊檢測到執(zhí)行體狀態(tài)不一致，建立映射同步，記錄輸入指令和輸出結果的映射關系。

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

7）狀態(tài)監(jiān)視模塊將上報信息反饋給各個執(zhí)行體進行同步。

8）同步完成后執(zhí)行體給狀態(tài)監(jiān)視模塊發(fā)送確認信息。

9）狀態(tài)監(jiān)視模塊清除映射同步信息，完成同步。

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

4 實驗評估

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

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

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

4.1 實驗環(huán)境

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

圖6 測試環(huán)境拓撲Fig.6 Test environment topology

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

4.2 功能測試

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

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

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

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

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

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

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

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

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

4.3 性能測試

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

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

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

5 結束語

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