導語：如何才能寫好一篇云計算基本架構，這就需要搜集整理更多的資料和文獻，歡迎閱讀由公務員之家整理的十篇范文，供你借鑒。

篇1

關鍵詞：云計算；虛擬化；VMware;VMware vSphere；架構

中圖分類號：TP303文獻標識碼：A文章編號：16727800（2012）008000602

作者簡介：連鴻鵬(1987-)，福建師范大學協和學院初級網絡工程師，研究方向為云計算。

0引言

虛擬化技術是伴隨著計算機的產生而發展的，虛擬化意味著對計算機資源的抽象。虛擬化技術實現了物理資源的邏輯抽象和統一表示，通過它可以提高資源利用率，并能夠根據用戶業務需求的變化，快速、靈活地進行資源部署，因此，虛擬化技術已經成為構建云計算環境的一項關鍵技術。

VMware 云基礎架構能夠讓現有的用戶從虛擬化中獲益，加速了現有數據中心云計算的轉移，與公共云基礎兼容，鋪平了向混合云模式前進的道路，成為云計算的新里程碑。

本文主要討論作為X86體系結構虛擬化技術的代表，VMware公司基于已有的虛擬化技術和優勢，提供了云基礎架構及管理、云應用平臺和終端用戶計算等多個層次上的解決方案，主要支持企業級組織機構利用服務器虛擬化技術，實現從目前的數據中心向云計算環境轉變方面的架構分析。

1VMware vSphere 簡介

VMware vSphere是在原來的VI3基礎上推出的系統，被成為業界首款云計算操作系統。vSphere將應用程序和操作系統從底層硬件分離出來，從而簡化了 IT 操作。現有的應用程序可以看到專有資源，而服務器則可以作為資源池進行管理。vSphere以原生架構的ESX/ESXi Server為基礎，讓多臺ESX Server能并發負擔更多個虛擬機。主要包括3部分：一是虛擬化管理器VMM部分的VMware ESX 4，VMware ESX Server主要是用于調配物理服務器中內存、CPU、存儲及網絡各種硬件資源，運行在物理服務器上的一個虛擬層并根據預定好的策略將這些資源分配到運行在其中的各虛擬機中，這些虛擬機以安全獨立的模式并行運行；二是用于整合和管理VMM的VMware vCenter，提高在虛擬基礎架構每個級別上的集中控制和可見性，通過主動管理發揮 vSphere 潛能，是一個具有廣泛合作伙伴體系支持的可伸縮、可擴展平臺；三是用于管理客戶端的軟件VMware Infrastructure Client。

2VMware vSphere 的基本架構

VMware vSphere 主要通過虛擬化技術將數據中心轉變為云計算基礎架構，通過虛擬化提供自助部署和調配的功能，將IT基礎架構作為服務來交付使用。vSphere是一個整體架構而非單個產品，基本架構如圖1。

圖1VMware vSphere 的基本架構

2.1vSphere的云端部分

vSphere所謂的云端是指平臺及架構部分（PaaS和IaaS）,可以分為內部和外部云端。內部云端由各種硬件資源組成，并有vSphere負責統合云端資源，在IaaS及PaaS中，資源為硬件及OS資源。外部云端vSphere可以將這些第三方提供的資源集成到企業的IT架構中。

2.2vSphere的底層：架構服務（Infrastructure Service）

有了硬件資源之后，就需要一個Hypervisor將資源集成，然后ESX和ESXi服務器將負責硬件資源虛擬化。Infrastructure Service主要可以分為運算部分的vCompute、存儲部分的vStorage以及網絡部分的vNetwork。

（1）vCompute部分。vCompute包括了ESX/ESXi以及DRS。ESX/ESXi主要實現服務器整合、提供高性能并擔保服務品質、流水式測試和部署及可伸縮的軟硬件架構。DRS確保按需調整資源配置，根據需要和優先級壓縮和增加應用系統的資源，動態的響應負載平衡。

（2）vStorage部分。vStorage包括VM所在硬盤的文件系統VMFS以及動態分配大小的Thin Provisioning，提供多種存儲虛擬連接選擇，通過vStorage VMotion減少或消除計劃內停機，通過精簡部署降低虛擬環境的存儲要求，通過vStorage API簡化管理并提高存儲操作的效率。VMFS是專門為虛擬機設計的高性能集群文件系統，該系統可以在VMware虛擬機的VMware虛擬數據中心環境中訪問共享存儲。

（3）vNetwork部分。VMware的網絡虛擬化技術主要通過VMware vSphere 中的vNetwork網絡元素實現。通過這些元素，部署在數據中心物理主機上的虛擬機可以像物理環境一樣進行網絡互連。vNetwork的組件主要包括虛擬網絡接口卡Vnic、vNetwork標準交換機vSwitch和vNetwork分布式交換機dvSwitch。vSphere提供了一個Distributed Network的架構，不但有完整的Bridged/NAT/Host only架構，更和Cisco合作推出一個專門安裝在vSphere上的分布式網絡。

2.3vSphere的Application Service

篇2

關鍵詞：云計算；數據中心；資源管理

中圖分類號：TP315

21世紀以來互聯網技術的發展十分迅速，隨著時間的增長，一些陳舊的網絡設施不斷的被淘汰，開始進行更新換代，換代的同時計算機技術的應用也不斷的被廣大的人們所熟知，互聯網技術中有一個重要的環節對網絡的發展起到承上啟下的作用，那就是數據的存儲，如今隨著計算機技術的不斷發展這種設備的成本也隨之降低，這也促使互聯網的用戶不斷的提高。人們慢慢的都進入了互聯網的時代，使得當今社會也變的越來越信息化，同時也有很多的數據要進行處理，使得傳統的一些數據的計算方法不再適合當今互聯網的發展速度，因此傳統的一些數據中心也滿足不了當今的需求。本文主要結合當今云計算的發展狀況，研究了云計算的基本理論和概念以后，深入分析了云計算的基本架構。

1 云計算數據中心的概述

1.1 云計算的概念。云計算的定義比較多，與之關聯的理論也比較多，但是總體來講主要有以下3個方面：第一分布式計算；第二信息海量計算；第三，并行數據計算。這些概念基本上都是美國標準語技術研究中心提出的，是國際上通用的概念。云計算并不是無償的服務，它是需要收取一定費用的，收取費用的計算主要是客戶使用網絡流量的費用。目前移動網絡也不斷的發展已經從2G發展到了4G網絡，互聯網時代開始更新換代。這也使得云計算技術運用越來越廣泛，用戶可以隨時隨地的通過訪問面來獲取自己想要的數據服務，或者計算的結果，并且獲取的過程是簡單而輕松的。與此同時工業的生產也不斷的運用云計算技術開展生產活動，隨著時間的推移，云計算在工業生產中的運用不斷的擴大和普及，也越來越成熟，涉及的工業領域也越來越多。

1.2 云計算的原理。云計算的原理和云計算涉及理論領域有著密切的關系。從這些領域我們可以看出云計算技術的主要目的是將需要處理的數據在網絡上的其他計算機上進行處理和計算。而對于企業的一些數據中心來講，云計算的運行原理和和網絡上的一些原理是相似的。唯一不同的就是企業的數據是根據需求來定的，隨著網絡的普及以及網絡速度的加快，移動客戶端數據也不斷的發展，云計算的服務也越來越廣泛，比如利用手機進行購物等都是云計算衍生的產品。這些技術與以往傳統的網絡相比變的越來越開放，不像以往使用單機進行數據處理，如今隨時隨地都可以操作，這樣也使得互聯網在一定的程度上越來越普及。

2 ITIL架構

目前應用最為廣泛的架構就是ITIL架構，這種架構主要分為6個不同的模塊這些模塊在一定的程度上有很大的聯系，它們并不是孤立的，在實際的工作中要相互作用的，這樣才能完成各自的任務，下面分開介紹這6個不同的模塊：

2.1 服務支持。該部分主要是對執行某項任務時，都由哪些人員參與，他們分別扮演何種角色，以及整個任務執行的具體細節進行描述，將聯系用戶以及細節的“服務臺”功能進行明確的定義。服務支持在整個云過程中所關注的重點是，IT組織是如何按照SLA標準向具體客戶提供IT服務的。

2.2 服務交付。該部分主要是用來對客戶開展某項業務所需要的服務，主要的服務內容就是對客戶的要求進行任務分工以及IT組織在提供這項服務時所需要具備的資源進行描述。在服務的過程中一些不同的人員要執行不同的工作內容，服務交付在整個云過程中所關注的重點是，IT組織如何與客戶簽訂具體的SLA等級協定，并在具體工作開展的過程中對SLA目標實施監控。

2.3 安全管理。安全就是保證用戶信息的安全，此模塊記錄很多用戶的數據，這些數據的主要內容是記錄一些具體的規劃和管理信息及IT服務所達到的安全流程水平，用以評估和控制所存在的風險，同時根據評估結果給予相應的解決。進行安全管理的目標就是要保證整個服務過程的保密性、完整性以及可用性。

2.4 IT基礎設施管理。IT基礎設施的管理十分重要，其關系到業務成本的問題，只有合理的對基礎設施進行管理才能保證最大的業務需求，創造更大的利潤，這個模塊最主要的任務就是保證IT架構的運行效率，以最小的運行成本保證最大的運行效率是其最主要的任務，可以有效的保證IT基礎設施的穩定建設。

2.5 應用管理。應用管理就是對客戶端上的應用進行管理，這個模塊的主要任務就是對各個應用的生命周期進行管理，并且對客戶進行管理的指導，以使他們能夠在最短的時間內從服務管理的角度對整個應用系統有著較為全面的了解。

2.6 服務管理規劃與實施。該部分主要是對服務的組織、實施以及改善服務管理流程，對整個過程中所出現的問題以及具體任務進行再規劃、設計，幫助客戶確立遠景目標，同時對服務改進方案進行全面的、持續的指導。

2.7 業務視角。所謂業務視角，是用來強調服務的開展應該從業務的角度觸犯，而不是只關注服務的交付者，讓IT服務人員明白其主要工作是為了實現具體的商業目標，是為了給用戶創造最大的價值，做出最大的貢獻。

3 ITIL的云計算數據中心管理理念

對于目前面向服務的數據中心架構來講，如果要是這些架構能夠穩定的、可靠的運行就必須有一些合理的管理模式，通過強大的管理模式把服務層的每個架構進行聯系起來，才能夠使得系統的運算結構有效的運行，也能使得網絡的基本結構得到很好的改善，目前面向服務的數據中心架構能夠最大的優化系統資源的配置。上一章詳細的講了ITIL的數據架構，這些架構在理論上是比較成熟的，也能夠經得住長期的實踐考驗，在具體的實際應用中還要根據客戶的需求進行設計，設計的標準很多，其中最主要的有；結果要能實施、對總體的需求能夠準確的表達，既然主要是面向客戶的架構，那么所有的設計都要根據客戶的需求來定，這樣才能滿足客戶需要的功能。

4 云計算資源的管理

4.1 云計算管理模型。主要分為兩個部分，一個是被動式部件一個是主動式的部件，這兩種系統的結構都具有層級的結構，其中主動式的部件就是系統的各種資源，就是對系統的數據進行反復的利用，作用的內容就是系統結構的內容，通俗的說就是執行傳統以及非傳統計算過程。而作業是整個層次結構的實體，調度的主要內容就是吧任務映像到資源，而不是將作業映像到資源。

4.2 云計算的資源調度。云計算中關鍵的系統就是云計算的資源調度系統，它直接影響著資源管理的有效性和可操作性，然而云計算的動態性能以及云計算的結構性能又直接影響著云計算資源的調度，直接影響云計算的系統復雜性。云計算資源的調度系統設計可分為3類，主要有集中式、分布式以及層次式等，在這3中調度的類型中，集中調度最為常見，它主要是通過一個中央的調度中心進行數據的交換，這種調度方式主要是通過一個程序進行的，其中所有能夠使用的信息都能夠在數據的中心體現。分布調度的原理主要是進行交互式的作業，主要把數據傳送到遠程的存儲器中，用戶可以通過網絡訪問這個服務器從而獲得相關的數據，這種操作并沒有中心的系統進行操作。

5 結束語

云計算技術越來越流行，都歸功于計算機技術的發展，人們對網絡的需求與日俱增，如今這種需求涉及到很多的方面和領域，不僅在企業中有所體現，在日常生活中都與人們息息相關，本文全面的接受了云計算的一些基本架構，分析了云計算的一些概念和原理，初步了解云計算技術有一定的作用，作者水平有限，沒能在云計算的硬件和軟件上深入分析，希望這以后的生活中繼續研究。

參考文獻：

[1]羅軍舟，金嘉暉，宋愛波.云計算：體系架構與關鍵技術[J].通信學報，2011（07）：3-21.

[2]張亞娟.云計算數據中心資源管理軟件設計[J].無線互聯科技，2014（04）：90+94.

[3]羅興宇.淺析云計算數據中心的資源管理[J].計算機光盤軟件與應用，2014（05）：40-41.

篇3

關鍵詞：融合媒體；云平臺；規劃；設計

1 融合媒體環境下云平臺的規劃問題研究

在建立相應的融合媒體云平臺之前，應率先明確如下問題，即：自建自有云平臺抑或租賃現成公用云平臺。在選取時，應將自身實際和未來產業發展形式緊密結合，我們應該明確的是，日后的媒體業務均將建立在云平臺基礎之上，但這只是一個結果，其實現需要經歷較長時間，其發展程度主要取決于以下二個方面：第一，播放終端的IT、IP及智能化改進，之前的通過數字信號傳輸的設備將被IT設備取代；第二，隨著IT產業的不斷完善，尤其是以光纖寬帶和計算能力為主的快速發展，導致電視視頻制播業務面臨高碼率、高存儲、高計算能力的需求。綜上，在很長時間里，融合媒體技術的發展將呈現多種云平臺并存的局面。即：

（1）媒體自建云平臺。該平臺主要指衛視自行建立的基于虛擬云計算技術上的云系統。該平臺主要用于解決目前制播系統向云體系過渡的問題。

（2）媒體專用云平臺。該平臺主要是在硬件上租賃公有平臺上的各種設備及相應服務，選用云計算技術進行管理。媒體專用云平臺主要針對于互聯網業務。

（3）公有云平臺。所謂的公有云平臺主要是阿里云、亞馬遜等公司提供的公共計算資源服務。使用者可以自由地在公有云平臺上上傳和下載需要的各類資源，對于一些高級資源，公有云平臺提供付費服務。在融合媒體云平臺系統中，公有云平臺主要是滿足社會服務功能[1]。

2 融合媒體環境下云平臺的設計實現問題研究

在涉及到融合媒體云平臺的設計實現方面，其中ONAIR云平臺是融合媒體平臺的代表作之一。作為媒體性質較強的云平臺，ONAIR將專業化音視頻處理技術同世界領先的云計算平臺以及遍布全國的CDN網絡二者深度融合，從而提高了云平臺對視頻端播放的控制作用，拓展了其內容制作、內容播控及網絡新媒體等功能。該平臺在設計時，嚴格遵循專業化導向，通過云平臺基礎服務提供商解決設施問題。

2.1 融合媒體環境下云平臺的基本架構形式

通過分析ONAIR云平臺可知，IaaS平臺能夠支撐各種最基本的云計算服務和功能，比如前文所述的阿里云、亞馬遜云等公共平臺。中間分布的PaaS層可以細化為6層，具體為：中間層（OM）和搜索引擎層（OCSE），這兩層的主要目的為配合不同云技術服務商的不同接口，實現對不同服務商的統一封裝；接口層（ESB）該層的目的是為實現其他復雜流程提供基礎，并實現與老舊系統的實時交互；基礎服務層（OBSP）基礎服務層主要為各種音視頻文件提供各類服務，比如：后期編輯、播放等功能；運營服務層（OBSS）為整個云平臺的正常運營提供服務，實現對服務的管理、收費及日志記錄等功能，確保平臺的盈利能力；位于拓撲圖最上一層的API層，將平臺所有的服務以API的方式封裝成接口給軟件開發人員及其他合作單位。對于融合媒體環境下的云平臺而言，其基本架構ONAIR的SaaS服務功能主要是為了滿足融合媒體環境下的各類服務，比如網絡電臺、微電臺、新聞云更新及自媒體云更新等。隨著互聯網技術的不斷發展，促使人類社會的認識發生了巨大的變革，日后的互聯網技術將朝著合作、開放的方向發展，因此，ONAIR的架構設計就充分體現了這一觀點[2]。

2.2 IaaS服務的功能介紹

為了提高融合媒體環境下的云平臺ONAIR的基礎服務能力，日前，ONAIR系統已經成功和阿里云服務實現對接。就對接的成果而言，所獲得的價值非常豐碩。從資源和硬件支持角度看，阿里云在國內已經初步建立了5個核心計算服務中心，計算服務器數量已經突破20萬臺次，這種計算規模完全可以支持目前的融合媒體環境下的云平臺計算服務水平，并且還可以支持其一定程度的擴張。其中，華通云數據擁有骨干網及遍布全國各地的CDN節點，借助這一顯著優勢，確保了ONAIR云平臺系統能夠將各類音視頻實時發送到全國的任何一個角落。

2.3 PaaS服務的功能介紹

（1）云平臺轉碼服務功能：云平臺的轉碼一般選用較為常用的集群轉碼方式，集群轉碼能很好地解決大內存的視頻轉碼效率。因為轉碼系統設置在云平臺上，其云計算方式可以無線放大，從而實現對視頻的高效轉碼。在具體的視頻轉碼操作中，高清視頻的轉碼能力可以達到10倍率左右。因此，對于操作用戶而言，僅需要給出輸入輸出的文件格式、碼率和需要達到的轉碼速度即可，其具體的轉碼操作均可由ONAIR云平臺系統自動完成[2]。（2）視頻快速編譯功能：選用BS架構形式，BS架構的界面部分采用低碼率視頻用于打點、瀏覽等交互操作。交互式操作完畢后，可將其上交到云平臺系統，進而實現視頻源代碼的快速編譯，從而確保視頻傳輸和共享的清晰度。（3）視頻采集服務：目前已有的SDI信號經制定編碼器切換為IP形式后，可以將其實時傳輸至云平臺端，并及時保存，當文件播放時，可將文件轉移到特定系統下或者直接下載至客戶端。（4）視頻播放功能：IP播放系統傳輸至云平臺后，可經過視頻服務器實現與CDN的交匯對接，將播放內容實時推送至客戶端口，其中包含PC端、手機移動端及互聯網電視等。其中視頻直播服務支持各種碼率和互聯網流協議。

2.4 SaaS服務功能

（1）網絡電視播放：網絡電視播放功能集成了視頻資源集中管理和服務（VMS）及相應的網站發送模式。通過云傳輸形式，在發送前確定好需要溝通和交換的資源，便可快速在云端開通虛擬機，實現虛擬機與原有系統的對接。以前傳統的電臺建立形式需要提前購置必要的電子設備，而現在使用云端傳送的形式，只要每月上繳固定的費用，便可實現資源實時獲取，在計費方式上，不同于以往的以時間為單位的繳納形式，云端傳送采用按量計費，計費方式更加人性化。（2）云端媒體資源整合：以往的媒體資源整合方式主要采用本地數據流磁帶庫從而實現對海量數據和文件的存儲和管理，由于該設備很容易出現故障，因此o后續的正常使用和維修保養造成了巨大的困難。基于存儲設備生產技術的不斷發展和完善，受到市場供求關系的影響，存儲設備的價格逐步下滑，通過云端處理的方式實現對海量數據和文件的存儲，同之前方法相比，顯示出極高的性價比和穩定性，數據傳送和訪問更加穩定可靠[1]。（3）云端新聞更新：采用云端實時更新的方式布置新聞媒體系統，提高了新聞的推送效率，可以快速將互聯網上上傳的新聞推送至指定新聞系統。新聞和相關文章被推送至云端上，新聞工作者可以直接取閱并修改，提高了以往新聞文稿的更新效率。（4）體育賽事的云端播放：之前的體育比賽前實況直播系統都集成在IBC中心，節目制作者必須在比賽實地才能實現對比賽的實況轉播。而云端賽事直播系統，是將IBC系統集成在云端，經過云平臺將視頻資料傳輸至相關媒體機構做進一步的編輯并第一時間，這樣一來，極大地提高了賽事的制作和播放效率，壓縮了工作時間，降低了相關成本，方便了節目部門的使用。比如在2014年的青奧會中，IBC系統建立了12條子系統，借助50M寬帶，實現了在短時間內將實況節目傳輸至云平臺供客戶端實時收看[2]。

3 結束語

綜上所示，云計算相關技術是保證融合媒體下云平臺建立的基礎，隨著互聯網及云計算技術的不斷完善，云計算及配套的云平臺系統必將成為新聞媒體中的生力軍，必將引領新一代的技術潮流。

參考文獻

篇4

關鍵詞：云計算；教育資源；共享平臺

中圖分類號：TP311.52 文獻標識碼：A 文章編號：1674-120X（2016）35-0113-02 收稿日期：2016-10-13

作者簡介：朱 林（1981―），男，講師，碩士，研究方向：軟件工程、電子商務。

一、研究背景

現階段，各大高校的教育資源共享方式比較單一，效率也較低下，教育資源共享的方式通常有FTP共享、教師下發資料、通過打印實現共享或通過 U 盤進行傳輸，隨著時代的發展，這些資源共享的方式存在的弊端越來越明顯。

二、基于云計算的教育資源共享平臺設計

使用云計算構建教育資源共享平臺可以解決以上弊端，該平臺主要實現對教育資源的高效共享和安全存儲。用戶包括管理員、教師和學生，用戶都可以上傳和下載教育資源，管理員主要可以添加教師和學生信息，并對上傳的資源進行審核通過；教師可以錄入試題，批閱試卷；學生則可以在線測試，并在教師批閱試卷后進行查看。主要從以下幾個方面考慮平臺的設計：

1.云平臺系統架構的設計

系統可以采用Apache VCL云平臺進行基本架構的設計，軟件架構使用目前軟件開發常見的N層結構模型：表示層、業務邏輯層、數據訪問層以及數據存儲層。其中，表示層與用戶息息相關，用于顯示平臺輸出的數據以及系統接收用戶輸入的信息，為用戶提供一個可以進行人機交互操作的平臺；業務邏輯層是整個系統中的核心部分，主要功能在于系統業務規則的制訂、業務流程的實現等與業務需求密切相關的系統功能，它應對的是系統的領域邏輯，其處于數據訪問層與表示層之間，以弱耦合的結構在數據交換中起著橋接作用，在整體架構中的關鍵性不可忽視；數據訪問層和數據存儲層的功能比較純粹，前者主要負責對數據庫的訪問，后者主要功能是進行文件的存取。

2.數據庫的設計

任何一個軟件系統都離不開數據庫的支持，云平臺也不例外。系統在當前的狀況下運行，對于數據的儲存，數據庫基本上可以滿足用戶的需求，但考慮到業務系統的不斷更新以及數據量的快速增加，平臺在未來一段時間里在性能和易擴展性上的要求也會與日俱增。為此，根據云教育資源共享平臺的現狀和未來的發展，需要采用合理的、適應發展的存儲架構，對數據存儲與處理、擴展性、訪問接口、調度策略等做相應的優化與改善，從而加強對各種數據資源的存儲維護等行為操作。

3.角色及流程設計

在基于云計算的教育資源共享平臺中，主要有三種用戶角色，分別是系統管理員用戶、教師用戶以及學生用戶。

（1）系統管理員是該系統的主要角色，在該系統中，系統管理員需要管理教師以及學生用戶，可以創建教師與學生用戶，還可以上傳下載教育資源，對教育資源進行審核或刪除，并添加課程信息，錄入題庫，添加題目。

（2）教師業務流程。

在該系統中，教師用戶由管理員用戶創建，需要從管理員處獲取登錄賬號及密碼，教師可以上傳和下載教育資源，可以添加課程信息，錄入題庫，添加題目，新增試卷，錄入試卷，并且在學生測試后，對學生的測試進行閱卷評分，注銷退出。

（3）學生業務流程。

在該系統中，學生是主要使用者，學生用戶也由系統管理員創建，因此也需要從管理員處獲取登錄賬號和密碼，登錄后，學生可以上傳和下載教育資源，并且在線測試課程，測試后提交試卷，由教師閱卷評分后公布成績，學生可以查看課程測試的成績。

三、云計算服務類型及開發框架選擇

1.云計算服務類型

隨著云計算技術越來越成熟，云計算的服務領域也越來越廣泛，在廣大領域中云計算的服務類型主要有以下三種：

（1）基礎設施即服務。

消費者從一些完善的基礎設施中獲得相應的服務，其主要面向硬件需求的客戶，用戶只需要提供需要計算的數據。

（2）平臺即服務。

將云平臺作為服務模式，本系統的云計算即是云平臺服務，需要用戶自己寫服務器，然后將所寫的服務器部署到云平臺上即可。用戶也可以自己寫云平臺，在這里為了方便，直接將服務器部署到開源的云平臺上。而本系統所選擇的云平臺為新浪云。

（3）軟件即服務。

軟件即服務，從字面意思理解，即通過軟件的形式提供服務，在這種云計算服務中，用戶并不需要購買軟件，只需要向擁有軟件的商家租用即可，通過租用的基于Web的軟件管理經營的活動。

2.主流云平臺

當前主流的云平臺主要有阿里云、新浪云等。其中可以使用新浪提供的云平臺開發本系統。在新浪云注冊賬號，然后進入新浪云服務，創建應用，在代碼管理中上傳自己的項目war包，下載新浪云的架包，然后將代碼的war包上傳到新浪云，并啟動新浪云上的MySQL服務，配置相應的JDBC連接。

3.開發框架

本系統可以選擇SSH框架進行開發，SSH框架由Spring，Struts，HibernateM成，其中Spring可以說是一個管理層，用來管理Struts和Hibernate之間的工作，Spring框架是一個輕量級的框架，主要有IOC和AOP兩大機制。Struts是一個基于MVC模型的整合框架，即Model層、View層、Control層。因此Struts是用來做應用層，負責調用service層。Hibernate是系統的持久層，也可以說是數據訪問層，它對JDBC調用數據庫作了輕量級的封裝，省去了大量的SQL語句。SSH框架是當前比較主流的Java Web框架。

四、系統構建關鍵點分析

（1）數據庫設計是系統構建的重要組成部分。教育資源共享平臺從總體上來說是屬于教學管理類系統平臺，在設計時，可以使用SQL Server數據庫系統進行數據的存儲管理。先要對系統的各個功能要有明確的定義，在此基礎上設計出功能表，創建數據庫。另外，必須明確表的有效屬性，在建表初期，難免會有無用的屬性，需經過反復的測試，只保留必要的屬性，減少數據庫的規模。

（2）對于需求的理解程度是系統的重點，需要分析平臺設計背后所反映出來的供求關系，對資源的廣度和效度進行深度挖掘，在基本要求和功能之上，創造盡可能多的創新點，并努力提高平臺的安全性和效率。

（3）在具體功能都能實現的基礎上優化頁面的設計。頁面如何布局是考慮的重要問題，既要體現美觀大方，又要減少代碼冗雜。不能一味地尋找網上的模板，必須對頁面布局有足夠的了解，才能省時省力，事半功倍。因此，用好HTML 5語言和JSP頁面開發技術尤為重要。

篇5

【關鍵詞】數據挖掘，Hadoop

1引言

1.1 數據挖掘技術概述

數據挖掘出現于 20 世紀 80 年代后期，90 年代有了突飛猛進的發展，并在進入 21 世紀后繼續繁榮。隨著科技的不斷進步，在物聯網、云計算、移動互聯網等發展的推動下，數據發生了“大爆炸”，其規模呈幾何級上升。如何將這些海量的、復雜的數據轉化成人類可理解的、有用的知識，從而指導我們的決策正成為目前面臨的重要的問題。

如今，隨著云計算的出現和發展，數據挖掘技術迎來了新的機遇和挑戰。現在的基于云計算的并行數據挖掘與服務的模式。數據挖掘的算法可以分布在多個節點上，并且這些算法之間是并行的。在進行數據挖掘的過程中，我們需要的資源會實現按需分配，具有很大的伸縮性。在分布式計算模型下，使用的是云計算模式。算法的實現采用 MapReduce 的方式，從而實現并行的要求。

1.2 Hadoop 框架

Hadoop是一個開源的分布式系統基礎架構，由 Apache 基金會開發。Apache Hadoop是一款支持數據密集型分布式應用并以Apache 2.0許可協議的開源軟件框架。它支持在商品硬件構建的大型集群上運行的應用程序。

Hadoop框架透明地為應用提供可靠性和數據移動。它實現了名為MapReduce的編程范式：應用程序被分割成許多小部分，而每個部分都能在集群中的任意節點上執行或重新執行。此外，Hadoop還提供了分布式文件系統，用以存儲所有計算節點的數據，這為整個集群帶來了非常高的帶寬。MapReduce和分布式文件系統的設計，使得整個框架能夠自動處理節點故障。它使應用程序與成千上萬的獨立計算的電腦和PB級的數據。現在普遍認為整個Apache Hadoop平臺包括Hadoop內核、MapReduce、Hadoop分布式文件系統（HDFS）以及一些相關項目，有Apache Hive和Apache HBase等等。

2 Hadoop數據存儲平臺

2.1基本設計思想

我們的基本思想是：充分利用 Hadoop的集群特征，將數據挖掘系統中需要巨大計算能力的各個模塊的計算和存儲要求擴展到Hadoop集群中的各個節點上，利用集群的并行計算和存儲能力來進行相關數據挖掘工作。系統采用MVC三層架構設計使結構更加清晰，系統易于擴展。在底層，使用 Hadoop來存儲、分析和處理巨大的數據量，而在高層通過接口直接透明的調用底層的計算和存儲能力。

在整個系統中，我們可以使用 HDFS 來存儲文件和數據。HDFS 具有很高的數據吞吐量，并且很好的實現了容錯機制。HDFS 提供了多種訪問接口，包括 API以及各種操作命令。使用 HDFS，我們可以為原始的大數據集提供存儲空間，對臨時文件進行存儲，為數據預處理、數據挖掘過程提供輸入數據，同時輸出數據我們也保存在 HDFS 中。系統整體架構如圖1所示。

2.2系統結構模型

結合以上的基本設計思想以及典型的數據挖掘系統模型，采用分層的思想，自頂向下每層都透明的調用下層接口，最頂層為交互層，用于用戶和系統之間的交互。最底層為分布式計算層，使用 HADOOP 來實現文件分布式存儲和并行計算功能。使用分層，各層之間變得獨立，易于系統的擴展。下面詳細介紹我們得到的基于 HADOOP 的數據存儲系統。如圖2所示。

1、交互層

提供系統和用戶之間的接口。通過提供具有良好表現形式的圖形界面，使得用戶可以登陸系統定制各種細粒度的業務，查看或者保存各種輸出結果。

交互層具有的模塊包括：

①用戶管理模塊：實現用戶身份的識別以及相應權限的設置，同時也包括對用戶登陸或者注銷等常用的管理。

②業務展示模塊：實現用戶提交的各種業務，并對業務結果進行查看，分析和保存等功能。用來將系統的返回結果交付給用戶。

2、業務應用層

提供了各種業務邏輯并實現了對各種業務流程的控制和調度。用戶提交的業務在這一層被處理，控制和調度。

業務應用層具有的模塊包括：

①用戶界面：用戶可以通過簡單應用的操作界面工具，進行海量數據處理存儲。

②業務響應模塊：相應上層的業務模塊，對完成業務所需的子業務進行調用、管理，并通過調用底層模塊完成業務。

3、數據處理層

為業務應用層提供數據挖掘階段業務流需要的各個模塊，并且具有較細的粒度。如數據預處理，模式評估，數據挖掘等組件。這一層是整個系統的核心，在這一層，主要的任務在于實現各種任務過程中算法的并行化，并將任務提交到 Hadoop 分布計算層進行運算。并將結果返回給業務應用層。

數據處理層具有的模塊包括：

①系統管理模塊：對系統實現分布式管理。主要包括：負載平衡管理、系統日志管理、對象事務管理、系統遠程部署管理等。

②數據加載模塊：將挖掘所需的數據進行注冊并放入系統的 HDFS 文件系統。

③數據存儲模塊：提供對海量數據的并行加載、處理和存儲功能。將數據從其他外設中導入平臺的HDFS；并行ETL 模塊用來對HDFS中的原始數據進行處理得到存儲數據；并行存儲模塊提供對處理后的數據進行存儲.

④并行查詢模塊：提供對海量數據的并行查詢、用戶自定義事務處理等功能。

⑤備份恢復模塊：提供對系統存儲數據的備份管理、備份存儲、備份恢復等功能，增強系統的安全

性和容錯性。

⑥模式評估模塊：Hadoop 框架自身提供了 HDFS，MapReduce 運行模式、運算環境以及自動管理。

4、分布式計算層

使用 HADOOP 框架來實現集群存儲、計算。Hadoop 提供了分布式文件系統和并行的運行模式，同時實現了對分布式系統的管理。我們需要在此之上實現任務提交的 Server。

3總結

本文分析了對現階段基于云計算平臺實現的數據挖掘研究以及開源的集群框架Hadoop的研究現狀作了分析。并在此基礎上設計了基于Hadoop的數據存儲系統的基本架構。采用以 Hadoop分布式平臺作為基礎，以 HDFS分布式文件系統和MapReduce 并行計算模型作為處理數據的方法。同時給出了系統的模型并簡要介紹了各個功能模塊。通過將數據挖掘技術與云計算時代下的集群框架 Hadoop結合起來，利用集群巨大的計算能力和存儲能力，從而實現對超大規模數據挖掘的性能提升。

參考文獻：

[1]維基百科 Apache Hadoop [EB/01] http：///wiki/Apache_Hadoop，2015

[2]Hadoop 技術 [EB/01] http：/// ，2010

[3]朱珠. 基于 Hadoop 的海量數據處理模型研究和應用[D].北京：北京郵電大學，2008.

[4]JeffreyDean， SanjayGhemawat. MapReduce： Symplified Data Processing on Large Clusters

[J].NewYork： ACM， 2008， 51（1）：107～113.

[5]韓家煒， 坎伯. 數據挖掘概念與技術[M]. 北京：機械工業出版社，2008.

[6]Dean J，Ghemawat S.MapReduce：Simplifier date processing on large munications of the ACM ，2008，51（1）：107-113

[7]B.Callaghan，B.Pawlowski，P. Staubach RFC 1813-NFS Version 3 Protocol Specification June 1995.

[8]Jeffrey Dean. Experiences with MapReduce， an abstraction for large-scale computation Proc.15th International Conference on Parallel Architectures and Compilation Techniques，2006：1.

[9]Yang Lai， Shi ZhongZhi. An Efficient Data Ming Framework on Hadoop using Java Persistence API. 2010 10th IEEE International Conference on Computer and Information Technology （CIT 2010）.

[10]Bhandarkar， M. MapReduce programming with apache Hadoop. Parallel & Distributed Processing （IPDPS）， 2010 IEEE International Symposium on， Atlanta， GA.

篇6

關鍵詞：軟件定義網絡；架構；OpenFlow

中圖分類號：TP311 文獻標識碼：A 文章編號：1009-3044（2013）13-3071-03

當前，網絡已經成為支撐現代社會發展以及技術進步的重要基礎設施，它深深地改變了人們的生產、生活和學習方式；然而，傳統網絡架構越來越不能滿足用戶的需求，網絡創新復雜困難。近年來，逐漸興起的軟件定義網絡（SDN） 正試圖打破這種僵局，它最終可能將取代現在不靈活且以硬件為中心的高速高性能多核處理網絡。一旦實現軟件定義網絡，網絡設備將配備軟件開發套件和開放API，從而實現全新的網絡應用程序。

1 軟件定義網絡（SDN）的概念

軟件定義網絡，又稱為可編程網絡，就是將網絡設備配置平面從嵌入式節點獨立出來到軟件平臺、由軟件驅動的中央控制節點自動化控制的網絡架構。軟件定義網絡以開放軟件模式替代傳統的基于嵌入系統的、不夠靈活的控制平面。軟件定義網絡是新的網絡控制平面實現方法，它適應了降低網絡復雜度、虛擬化和云計算的網絡需求。它的發展對專有控制平面技術產生的破壞性創新，將對網絡變革產生巨大影響。控制平面和轉發平面分離，轉發平面特性專注而簡單，減少了設備硬件，降低了成本。

2 軟件定義網絡架構分析

2.1 SDN架構的特點

SDN 架構分為三層，包括應用層、控制層和基礎設施層。SDN 控制層是基于軟件的控制器，負責維護全局網絡視圖，并且向上層應用提供用于實現網絡服務的可編程接口；應用層運行在控制層之上，通過控制層提供的全局網絡視圖，控制應用程序可以把整個網絡定義成為一個邏輯的交換機，同時，利用控制器提供的應用編程接口，網絡人員能夠靈活地編寫多種網絡應用，如路由、多播、安全、接入控制等；基礎設施層位于控制層之下，通過控制數據平面接口與控制層相連，主要提供網絡設備硬件。

同時，SDN在進行路徑選擇時更為靈活，從而為互聯網業務的部署及網絡優化創造了有利條件。傳統路由協議能在一定程度上實現網絡流量的負載均衡，因為這類路由協議在選擇網絡路徑時，總是會盡量選擇比較空閑的鏈路而避開擁堵的鏈路。這類協議的好處是能提高鏈路的利用率，其缺點是不易對互聯網業務進行優先級管理。而SDN可以通過為業務流指派鏈路來方便地實現不同業務的優先級管理。

2.2 OpenFlow架構分析

這種控制和轉發分離的架構對于L2交換設備而言，意味著MAC地址的學習由控制機來實現，V-LAN和基本的L3路由配置也由控制機下發給交換機。對于L3設備，各類IGP/EGP路由運行在控制機之上，控制機根據需要下發給相應的路由器。流表的下發可以是主動的，也可以是被動的，主動模式下，控制機將自己收集的流表信息主動下發給網絡設備，隨后網絡設備可以直接根據流表進行轉發；被動模式是指網絡設備收到一個報文沒有匹配的流查找表記錄時，將該報文轉發給控制機，由后者進行決策該如何轉發，并下發相應的流表。被動模式的好處是網絡設備無需維護全部的流表，只有當實際的流量產生時才向控制機獲取流表記錄并存儲，當老化定時器超時后可以刪除相應的流表，故可以大大節省空間。當一個控制機同時控制多個交換機/路由器設備時，它們看起來就像一個大的邏輯交換機，各個交換機/路由器硬件就如同這個邏輯網絡設備的遠程線卡。

3 軟件定義網絡應用分析

SDN 能夠應用于多種網絡環境，包括數據中心、企業網絡、云計算等。

首先，在云計算時代，在數據中心網絡環境中使用SDN，實現高彈性數據中心、優化物理資源利用率，讓用戶能整合各種計算、存儲和網絡資源，在數據中心內部，利用SDN 的優勢，可以有效地進行數據中心的路徑優化和負載均衡，提高數據中心資源利用率以及降低數據中心的能量消耗。另一方面，在多個數據中心之間利用SDN 網絡虛擬化技術以及邏輯上集中式的控制技術，可以輕松地實現應用到虛擬專用網（VPN）的映射以及虛擬機的遷移，快速建立和運營虛擬數據中心。

其次，軟件定義網絡能簡化大型企業網絡的管理。在企業網絡中利用SDN 技術，能夠極大地減輕網絡管理的復雜度，企業網絡管理人員只需要通過定義整網的管理策略就能夠直接對企業網絡進行控制，而不需要進行逐個設備的配置，提高了企業網絡的可靠性。

最后，軟件定義網絡能大大促進云計算的發展，因為軟件定義網絡技術大大簡化了虛擬環境的資源分配。基于控制器的負載均衡應用程序能夠利用控制器中關于各個網絡設備的大量容量信息，自動地在虛擬機之間遷移工作負載。基于控制器的應用程序與部署在虛擬機上的虛擬網絡服務設備很相似，但是與使用物理設備的常規模型相比，它們具有更高的可擴展性、靈活性、效率和可管理性。

4 結論

通過控制與轉發的分離，軟件定義網絡能夠降低網絡管控的復雜度，提高網絡的可靠性及安全性，提供多種粒度的網絡控制。未來網絡將越來越依賴于軟件，軟件定義網絡這種新穎的、動態的網絡架構將得到更廣泛的應用，進而促進網絡技術的不斷創新應用。

參考文獻：

篇7

關鍵詞：云計算；Google；水利信息系統

中圖分類號：TP3文獻標識碼：A文章編號：1007-9599 (2012) 06-0000-02

一、云計算

美國國家技術與標準局（NIST）是這樣定義云計算的：云計算是對基于網絡的、可配置的共享計算資源池能夠方便地、按需地訪問的一種模式。所謂的共享計算資源池包括網絡、服務器、存儲、應用和服務。這個共享計算資源池，就是我們所說的“云”[1]。

從云計算服務的封裝方法上講，云計算可以提供三種類型的服務：IaaS（Infrastructure as a Service，基礎設施即服務）、PaaS（Platform as a service，平臺即服務）和SaaS（Software as a Service，軟件即服務）。

圖1-1 云計算的服務類型

如圖1-1所示，IaaS將虛擬化的計算資源直接按需提供給客戶；PaaS在虛擬化的云計算平臺上建立支持多種業務的應用平臺，再將開發環境、運行環境提供給客戶；SaaS在虛擬化的云計算平臺上提供按需定制和快速部署的應用軟件服務。

二、Google云計算的關鍵技術

Google云計算技術的關鍵技術包括：分布式文件系統GFS、分布式編程模型MapReduce和分布式數據庫Bigtable等。其中，GFS提供了海量數據的高效存儲和訪問的能力，MapReduce提供了一種簡單、高效的海量數據的并行處理方法，Bigtable為海量數據的組織和管理提供了方便。

（一）GFS

Google文件系統（Google File System，GFS）是一個大型的分布式文件系統。它為Google云計算提供高效的海量數據存儲和訪問能力，GFS的系統結構如圖2-1[2]所示，GFS將整個系統的節點分為三種角色：Client（客戶端）、Master（主服務器）和Chunk Server（數據塊服務器）：

圖2-1 GFS的系統結構

如圖2-1所示，GFS系統為上層提供文件服務的過程是：Client首先訪問Master節點，獲得GFS分配的、將要為其服務的Chunk Server節點的信息，然后Client直接去訪問這些Chunk Server以完成數據的存取。

GFS的這種設計思想實現了數據流和控制流的分離。首先，Client與Master節點之間只有控制流，而沒有數據流，這就極大地降低了Master節點的負載；另外，Client與Chunk Server之間直接傳輸數據流，同時由于文件被分成多個Chunk進行分布式存儲，Client可以同時訪問多個Chunk Server，從而使整個文件系統的I/O高度并行，系統的整體性能得以提高。

（二）MapReduce

MapReduce[3]是Google提出的一種提供海量數據處理的并行編程模型，用于對大規模的數據集（大于1TB）進行并行處理。MapReduce的核心思想是將需要運算的問題拆解成“Map（映射）”和“Reduce（化簡）”這樣兩個簡單的步驟來進行處理，用戶只需要提供自己的編寫的Map函數和Reduce函數就可以在系統上進行大規模的分布式數據處理。如圖2-2所示，是MapReduce的運行模型，假設共有M個Map操作和R個Reduce操作。

（1）Map：一個Map操作就是對部分輸入的原始數據進行指定的操作。每個Map操作都針對不同的原始數據，因此Map與Map之間是互相獨立的，從而實現并行化的處理。

（2）Reduce：一個Reduce操作就是對每個Map所產生的一部分中間結果進行合并操作，每個Reduce所處理的Map中間結果是互不交叉的，所有Reduce產生的最終結果經過簡單的連接就形成了完整的結果集，因此Reduce的執行也是并行化的。

圖2-2 MapReduce的運行模型

具體地，在使用MapReduce開發并行處理程序時，用戶需要編寫以下兩個函數：

（1）Map：(in_key，in_value){(keyj，valuej)|j=1…k}；

（2）Reduce：(key，[value1，…，valuem])(key，final_value)。

Map函數和Reduce函數的輸入參數和輸出結果根據具體應用的不同而不同。Map的輸入參數是in_key和in_value，它表示了Map需要處理的原始數據。Map的輸出結果是一組對，這是經過該Map操作后產生的中間結果。在進行Reduce操作之前，系統已經將所有Map產生的中間結果進行了分類處理，使得相同key對應的一系列value能夠集合在一起提供給一個Reduce進行統一處理，則Reduce的輸入參數就是（key，[value1，…，valuem]）。Reduce的工作就是對這些對應相同key的value值進行歸并處理，最終形成（key，final_value）的結果。這樣，一個Reduce就處理了一個key，所有Reduce的結果合并在一起就是問題的最終運算結果。上述過程中，無論是各個Map還是各個Reduce，都是并行執行的。

（三）Bigtable

Bigtable[5]是Google開發的，以GFS、MapReduce、Chubby為基礎的分布式存儲系統。

如圖2-3所示，是Bigtable的基本架構。其中，Google WorkQueue是一個分布式的任務調度器，主要用來處理分布式系統的隊列分組和任務調度。

圖2-3 Bigtable基本架構

如圖2-3所示，邏輯上，Bigtable主要由三個部分組成：客戶端程序庫（Client Library）、一個主服務器（Master Server）和多個子表服務器（Tablet Server）。客戶端需要訪問Bigtable的服務時，首先要使用其庫函數執行Open()操作，通過Chubby打開一個鎖（即獲取文件目錄），鎖打開以后客戶端就即可和子表服務器進行通信。

三、基于Google云計算的水利信息系統

（一）水利信息系統的特點

水利信息系統的業務管理范圍較廣，主要包括水雨情信息、汛旱災情信息、水量水質信息、水環境信息等。系統規模較為龐大，各個模塊之間存在著較大的信息關聯性，同時要處理圖形數據和常規數據，還需要保證海量數據的準確性和及時性。云計算作為一種新的技術提供了更高的效率、巨大的可擴展性和更快、更容易的軟件開發。因此，水利信息系統需要云計算。

（二）基于Google云計算構建水利信息系統

基于Google云計算的水利信息系統總體框架包括物理資源層、虛擬化支持層、服務管理層、信息資源層、應用層、表現層六個層面，見圖3-1，主要為政府、企業、公眾提供服務。

圖3-1基于Google云計算的水利信息系統總體框架

Google云計算關鍵技術在構建水利信息系統時可以從以下幾個方面得以應用：

1.編程模型

MapReduce是Google開發的java、Python、C++編程模型，它是一種簡化的分布式編程模型和高效的任務調度模型，用于大規模數據集（大于1TB）的并行運算。嚴格的編程模型使云計算環境下的水利信息系統編程十分簡單。

2.海量數據分布存儲技術

水利信息系統數據量大，其存儲由大量服務器組成，同時為大量用戶服務，因此系統采用分布式存儲的方式存儲數據，用冗余存儲的方式保證數據的可靠性。在水利信息系統云計算系統中可采用GFS和Hadoop團隊開發的GFS的開源實現HDFS。所有數據方面的通信都直接和塊服務器聯系，這大大提高了系統的效率，防止主服務器負載過重。

3.海量數據管理技術

水利信息系統需要對分布的、海量的數據進行處理、分析，因此，數據管理技術必需能夠高效的管理大量的數據。因此在水利信息系統中的數據管理技術可以采用BT(BigTable)數據管理技術和Hadoop團隊開發的開源數據管理模塊HBase，提供靈活高效的服務。

4.虛擬化技術

在水利信息系統框架中的虛擬化支持層采用虛擬化技術實現軟件應用與底層硬件相隔離，它包括將單個資源劃分成多個虛擬資源的裂分模式，也包括將多個資源整合成一個虛擬資源的聚合模式。

5.云計算平臺管理技術

基于云計算的水利信息系統資源規模龐大，服務器數量眾多并分布在不同的地點，同時運行著數百種應用，Google云計算系統的平臺管理技術能夠使大量的服務器協同工作，方便的進行業務部署和開通，快速發現和恢復系統故障，通過自動化、智能化的手段實現大規模系統的可靠運營。

（三）基于Google云計算的水利信息系統的優勢和不足

基于Google云計算的水利信息系統與傳統水利信息系統相比有很多優點：

（1）成本低。由于應用程序在云中，故各終端電腦并不需要傳統的桌面軟件所要求的處理能力和硬盤空間。

（2）性能高和計算能力強。在云計算中，用戶計算機的啟和運行速度將會更快，因為他們只需將少量的程序和進程加載到內存中。云計算使用了數據副本容錯、計算節點同構可互換等措施來保障服務的可靠性，使云計算比本地計算機更可靠。

（3）存儲容量大和數據高效安全。所有數據存儲在云中，容量比現有的臺式機或筆記本電腦大很多。此外，云計算在一定程度上保持了數據的安全性。

（4）兼容性和群組織間的協作較強。云計算不針對特定的應用，在云的支撐下可以構造出各種應用，增強了多用戶間的協作能力。

（5）擴展性強及用戶使用方便。云的規模可以根據實際情況進行伸縮，滿足用戶和應用增長的需求。同時也消除了用戶對特定設備的依賴。

由于云計算計算本身還有很多需要改進的問題，例如需要持久的網絡連接。利用云計算，必須鏈接到因特網上才能利用自己的應用和文檔，失效的網絡連接就意味著用戶在此期間內不能工作及訪問云中的內容。一些因特網連接很少或本身不穩定的地區，也是可能影響云計算使用的決定性因素[6]。

參考文獻：

[1]劉鵬.云計算[M].北京:電子工業出版社,2010

[2]Sanjay Ghemawat,Howard Gobioff,Shun-Tak Leung.The Google File System[A].SOSP'03[C].Bolton Landing,NY,USA: ACM,2003:29-43

[3]Jeffrey Dean,Sanjay Ghemawant.MapReduce:Simplified Data Processing on Large Clusters[J].Communications of the ACM,2008,51(1):107-113

[4]Mike Burrows.The Chubby lock service for loosely-coupled distributed systems[A].OSDI’06[C].CA,USA:USENIX Association Berkeley,2006:335-350

[5]Chang F,Dean J,Ghemawant S,et al.Bigtable:a distributed storage system for structured data[J].ACM Trans ComputSyst,2008,26(2):1-26

篇8

關鍵詞:結構強度; 軟件平臺; 應力計算; 強度計算; CAESAM; StrenBox

中圖分類號:U215;TB115文獻標志碼:A

Method and application of StrenBox-automatical calculation

software platform of structural strength

MU Quanchen1, LI Xiaopeng2, YU Hualong1

(1. Samtech S.A Beijing Representative Office, Beijing 100022, China;

2. Xi’an Aircraft Design & Research Academy, Xi’an 710089, China)

Abstract: To improve the efficiency and enhance the cooperativity and inheritance of structural strength calculation work, the automatical calculation platform of structural strength which is named as StrenBox is built up. Its theory and method is illustrated and the calculation process is shown through an industrial application example on part of an aircraft fuselage. Based on the present status of strength calculation, the further work on automatical calculation platform of structural strength is forecasted.

Key words: structural strength; software platform; stress calculation; strength calculation; CAESAM; StrenBox

收稿日期:2009-05-21

作者簡介: 牟全臣(1968―),男,黑龍江哈爾濱人,博士,研究方向為有限元分析,(E-mail).cn

0引言

隨著飛機等結構強度計算工作的深入,其工作量、效率和協作等問題得到越來越廣泛的認識和關注,從客觀上促進結構強度自動化計算平臺的設想和構建. 在飛機和火箭的結構設計中,包括靜強度、動強度、疲勞和損傷容限等強度設計過程,大體可分為應力計算和強度計算兩部分工作. 前者根據結構的幾何、材料和載荷等數據構筑有限元模型,并應用通用CAE軟件計算結構的應力(內力)得到應力分析結果;后者用應力分析結果,根據結構實際工作狀態,引用行業強度標準、規范和判據進行強度計算,得到計算結果,并據此得到結構強度的結論,完成強度校核工作. 近年來,應力分析工具得到長足發展,應力計算工作的效率明顯提高,但由于需要結合各行業用戶不同的方法和要求,具有很強的特殊性,強度計算工作的效率仍很受限制. 有經驗表明,對機等復雜結構,強度計算在單一強度校核流程中所占的工作量比例在70%以上. 因此,構建結構強度自動化計算平臺的首要目的就是通過行業用戶特殊方法(包括行業標準、規范和判據等)的軟件化,縮減強度計算的工作量,提高計算效率.

為適應大規模結構設計的要求,規范強度校核流程和加強設計人員間的協作成為當務之急. 這為強度計算平臺的構建提供客觀需求. 依靠結構強度自動化計算平臺,有望從根本上解決長期困擾強度分析人員的任務管理、數據管理和版本控制等問題. 應該指出,該平臺的建設是項復雜的系統工程,除框架的構建和完善外,更主要的任務是總結和集成用戶數據和方法.對機結構而言,強度計算平臺需要處理大量的材料特性、截面特性、載荷理論或實驗數據,并且有針對性地研究靜強度、復合材料、疲勞和損傷容限等分析方法.

在國際知名的結構強度自動化計算平臺中,比較成熟和取得成功工業應用的是空客的ISAMI軟件系統,它是比利時SAMTECH有限公司的CAESAM平臺框架、空客的數據庫以及空客方法庫的有機集成平臺. 伴隨中國航空工業的快速發展,以大飛機等為標志的項目客觀上迫切需要建立自主的強度計算平臺以改善目前的強度分析流程、縮短設計周期、優化結構性能. 同樣借助于CAESAM平臺框架的StrenBox飛機結構強度自動化計算軟件系統是SAMTECH公司與國內重要飛機設計研究機構合作的成果. 它汲取ISAMI系統的開發經驗,結合國內的數據、方法和規范,形成完整的強度自動化校核體系. 該軟件目前在某些型號的飛機上已得到初步應用,其有效性也得到初步證實. 隨著開發和維護升級工作的深入展開,其全面推廣和廣泛應用指日可待.

1StrenBox平臺

目前飛機結構應力計算多采用MSC Nastran進行,其應力計算模型為bdf文件,包含結構的單元、特性、材料和載荷等信息,輸出為OP2文件,包含位移、內力和應力等信息;強度計算需要在StrenBox平臺環境中進行,其模型(有時也稱為廣義應力模型(General Finite Element Model,GFEM))以czm文件格式存儲,它除包含上述應力計算和結果的信息外,還要包含應力單元與結構單元(Structural Element, SE)的對應關系,工程特性(Engineering Object, EO)的截面和材料特性初值等信息.

應力計算模型和強度計算模型的關系見圖1. 兩者的區別可以概括為:(1)后者除包含應力計算模型的信息外還包含其結果信息;(2)1個SE可以對應1個或多個應力計算單元;(3)強度計算模型的EO包含如截面積、楊氏彈性模量和破壞強度等應力計算模型的EO,還應包含界面型材類型和參數,材料屈服參數及鉚釘連接特性等必需的強度計算信息;(4)強度計算模型可以對應應力計算模型的全部或部分.

圖 1應力計算模型和強度計算模型之間的關系

在完成應力計算模型和強度計算模型的建模后,可以構筑完整的強度設計流程,其過程見圖2.

圖 2基于StrenBox平臺的結構強度設計流程

在整個流程中,有兩個循環:(1)涉及細節結構參數修改的強度計算循環,也稱為“小循環”;(2)涉及全局結構參數修改的應力計算循環,也稱為“大循環”. 前者的前提假設是局部結構參數修改不影響整體內力分布,這已為工程實踐所證實. 兩種循環互相嵌套,可以實現結構強度的快速和多輪次計算,為基于強度的結構優化設計奠定基礎. 從圖2可知,StrenBox完成所有的強度計算循環工作,并通過應力模型自動修改功能,為“大循環”提供隨時更新的有限元模型. 實際的應力計算可以在其他通用的有限元分析軟件如MSC Nastran中進行.

作為軟件,StrenBox的上述各項功能通過各個模塊實現,子模塊及功能框圖見圖3.

圖 3StrenBox平臺的模塊及功能

在各個模塊中,CAESAM界面環境提供用戶操作的基本架構,SDK二次開發包提供在這個基本架構上實現用戶化集成開發的工具.

鑒于強度計算模型的復雜性,建模模塊提供手工和自動的強度計算模型生成功能,可以方便地由有限元模型和結果生成SE和EO等輸入文件和czm格式的強度計算模型;建模模塊還提供應力模型更新功能,這對實現圖2中以應力重新計算為標志的“大循環”至關重要.

實現強度計算的重要前提是引入和調用強度判據,這是強度判據插件模塊的功能. 目前StrenBox平臺已集成金屬材料機身和機(尾)翼結構的大部分靜強度判據,包括破壞準則、屈曲失效準則和后屈曲失效準則等. 各準則中分別包含眾多的針對長桁、腹板和框(翼肋)的特殊失效模式,如框彎曲破壞、長桁壓損、腹板張力場失效和加筋壁板柱失穩失效等,共計50余種.

在進行強度計算時,需調用材料、截面特性、鉚釘和曲線等庫參數,這要用到數據庫模塊的功能. 目前,StrenBox已附加國內外大部分常用金屬材料的力學性能數據,包括鋁合金、鋼和鈦合金等,以及多種標準型材數據,包括“L”型材、“T”型材、“帽”型材等. 數據庫模塊還附加常用鉚釘和螺栓等的力學特性,為連接結構分析提供數據. 在實際計算中會用到大量工程曲線,這些曲線構成曲線庫,方便強度判據插件模塊的隨時調用. 另外,考慮到用戶可能需要現有庫參數以外的數據,或用戶希望建立由常用參數構成自己的數據庫系統,程序提供用戶自定義數據庫功能.

最后,為便于模型的統一和強度分析工作的協同,StrenBox平臺還構建任務和數據管理系統,對強度計算工作在系統管理、任務管理、數據管理和版本控制等方面給出解決方案.

2StrenBox平臺的應用實例

以某機身艙段為例介紹StrenBox進行強度計算的過程和實例.

2.1強度模型建模

進行強度分析的首要任務是生成強度計算模型,其過程見圖4,大致為:選擇和導入應力計算模型(有限元模型);選擇生成強度計算單元的位置和類型;生成強度計算模型.

圖 4強度計算模型生成過程

為方便后面的批量分析計算,可以針對不同部件或不同分析類型,定義不同單元分組,如普通框、長桁、壁板和地板等,可以基于以上分組進行以后的強度計算. 機身艙段模型分組見圖5.圖 5機身艙段模型分組

2.2強度計算

用強度計算模型,可以進行強度計算,其過程見圖6.

圖 6強度計算過程及界面操作

圖 7加筋板單元

結構形式

強度計算的基本步驟可總結為:

(1)定義分析的單元或分組. 本例分析機身艙段的整個機身壁板,其SE為加筋板,見圖7. 本例的計算單元共計452個.

(2)定義或修改材料、截面或鉚釘等特性. 本例中,蒙皮材料采用2024-T3鋁合金,長桁采用7075-T761鋁合金,框截面采用“Z”型材,長桁截面采用“L”型材.

(3)定義分析類型,亦即強度判據. 本例對蒙皮加筋壁板結構進行柱失穩計算,因此采用“Column Buckling Failure for Stiffened Panel”的強度判據. 根據軟件的幫助文檔可以知道,該分析判據采用Johnson-Euler公式計算加筋板結構柱失穩失效的許用應力,對比實際工作應力,可以得到該失效模式實際結構的安全裕度. Johnson-Euler公式的形式為σc=σcrip-σ2crip4π2Estl′ρ2(4)定義載荷工況. 本例中考慮氣動載荷、慣性載荷和結構載荷在內的21種載荷工況.

(4)執行分析計算. 本例分析計算時間為83 s.

2.3計算結果后處理

強度計算結束后就可以對計算結果進行處理和顯示,得到用戶需要的關鍵數據和結果. 后處理結果分為云圖和表格兩類,見圖8. 云圖可以顯示工作應力,許用應力、安全裕度或其他計算參數的分布. 表格則可以顯示所有單元針對不同載荷工況的各種計算結果,也可以匯總特定單元不同載荷工況的計算結果.

圖 8結果后處理:表格和云圖

2.4報告生成

根據強度計算結果,可以匯總成強度計算報告. 在形成報告之前,需要用戶提供報告模板,以定義首頁、扉頁、目錄以及各個章節的格式和要求,StrenBox可以方便地提供在這些格式的框架內附加文字內容、圖片和表格的功能,見圖9.

圖 9報告模板和形式

2.5應力模型更新

在強度計算之后,用戶可對結構的安全性、可靠性和經濟性進行評估,根據評估結果決定設計參數更改和優化設計方案. 如前所述,如果更改參數數量積累到一定程度,需更改有限元模型并重新進行應力計算. StrenBox提供匯總模型參數更改內容,并最終自動更新應力計算模型(有限元模型)的功能,并對更改情況進行有效的監測和跟蹤,見圖10.圖 10應力模型更新和其版本控制

3進一步工作

應該指出,鑒于強度分析工作的復雜性,StrenBox強度自動化計算平臺目前完成的是基礎框架性工作和針對金屬桿板結構的靜強度計算,所以功能的拓展和完善將是一項長期的工作,需要持續不斷的努力. 目前可預測的進一步工作包括:將批處理功能用于強度計算過程,以加快強度計算循環效率;氣動網格與有限元網格的自動匹配;單位載荷方法計算結構的靜強度;通過子單元和子結構方法實現接頭或開口等局部細節模型與整個機身(或機翼)結構的整體模型的融合和互相驅動;任務和項目管理的進一步實用化;復合材料結構分析;疲勞和損傷容限分析等.

篇9

關鍵詞：CAPWAP協議；系統架構；平臺搭建；測試結果；網絡性能

中圖分類號： TP393.04

文獻標志碼：A

Abstract：

In view of maintenance difficulties and high cost in largescale development of Wireless Local Access Network （WLAN）， the Control and Provisioning of Wireless Access Points （CAPWAP） protocol that applied to communication between Access Controller （AC） and Wireless Terminator Point （WTP） was researched and implemented. In Linux environment， main features were realized， such as state machine management， and WTP centralized configuration. A platform of WLAN centralized management system based on local Medium Access Control （MAC） framework was built up. Wireshark capture tool， Chariot and Iperf were used to test the platform. The capture test results verify the feasibility of the framework， and the results of throughput and User Datagram Protocol （UDP） test also show that network performance is efficient and stable.

Key words： Control and Provisioning of Wireless Access Points （CAPWAP） protocol； system architecture； platform construction； testing result； network performance

0引言

隨著通信技術的發展和智能化技術的推進，人們對移動網絡的依賴性提高，大規模部署無線局域網（Wireless Local Access Network， WLAN）將成為必然趨勢。發展初期，傳統的WLAN中“胖”接入點（Access Point， AP）集成度高，對硬件要求也高，后期維護的弊端凸顯。隨之，集中管理式的WLAN架構成為了研究熱點。集中式WLAN架構中的無線終端（Wireless Terminator Point， WTP）通過接入控制器（Access Controller， AC）進行統一配置管理，把用戶流量進行橋接、轉發和加密，提高了WLAN的性能。文獻[1]詳細分析了CAPWAP（Control and Provisioning of Wireless Access Points）協議的基本原理和架構，搭建簡單的實驗平臺，對WLAN網絡中負載均衡等性能進行測試；文獻[2]中將CAPWAP協議應用于某一通信設備上，實現了輕型接入點協議（LightWeight Access Point Protocol， LWAPP）協議和CAPWAP協議兼容，構建報文分片攻擊模型；文獻[3]中搭建了數據隧道和控制隧道以實現一體化交換機管理和控制無線終端；文獻[4]中設計了CAPWAP客戶端的多線程信息采集和上報的方案，以實現無線接入點的管理。

本文基于CAPWAP協議的研究的基礎上，在Linux操作系統下實現了CAPWAP協議的本地轉發架構的WLAN集中管理系統并進行了測試，測試結果驗證了其正確性與可靠性。

1CAPWAP協議

Internet工程任務組（Internet Engineering Task Force， IETF）在2005年成立了CAPWAP工作組標準化WTP和AC間的隧道協議。2009年4月，了描述CAPWAP協議的RFC 5415（Request For Comments 5415）[5]文件以及只支持CAPWAP協議的Binding協議文件（RFC 5416）[6]。

1.1功能概述

CAPWAP協議的基本功能可以分為4大模塊：

1）狀態機管理模塊。解析狀態機事件，實現狀態遷移和驅動，以及狀態機管理。

2）報文管理模塊。實現AC與WTP和STA之間傳遞的報文的解析與轉發。

3）分片重組模塊。對超過最大傳輸單元（Maximum Transmission Unit， MTU）的長度的報文進行分片，對收到的分片進行重組。

4）隧道保活模塊。快速檢測對端是否運行正常，控制通道是否順暢，依靠Echo進行保活。

1.2系統架構

CAPWAP協議有兩種模式：分離MAC（Medium Access Control）和本地MAC[1]11-12，[7]。

1）分離MAC（Split MAC）。分離模式下所有二層的無線數據和管理幀都會被CAPWAP協議封裝變成802.3類型的數據，首先在WTP端在無線幀前面加上802.3幀，然后在隧道中傳輸過程時再加上CAPWAP頭。

2）本地MAC（Local MAC）。本地轉發模式允許數據幀可以用本地橋或者使用802.3的幀形式用隧道轉發。如果是本地橋轉發，STA傳過來的業務數據不經過AC處理直接轉發出去，AC只處理控制數據。

Local MAC與Split MAC主要的區別在于對無線幀的處理，根據802.11協議定義，802.11無線幀分為控制幀、管理幀和數據幀。控制幀在Local MAC和Split MAC架構下都是在WTP端進行處理；管理幀，Local MAC架構下在WTP或者AC端處理，Split MAC架構下將其中實時部分放在WTP端處理，非實時部分放在AC端進行處理；數據幀，Local MAC架構下在WTP轉變為802.3幀進行傳輸，Split MAC架構下，802.11數據幀透傳至AC端進行處理。

5結語

本文介紹了CAPWAP協議兩種系統架構的不同之處，提出了實現CAPWAP協議的基本架構，最后具體給出了實現平臺的搭建步驟，并測試實現平臺。Wireshark軟件的抓包結果不僅證實了系統實現的正確性，而且對CAPWAP協議中報文管理和狀態機的管理兩部分功能提供了依據；另一方面通過Chariot軟件和Iperf軟件測試了ACAP架構下無線網絡吞吐量等性能，結果顯示搭建的平臺性能高效穩定。

參考文獻：

[1]BERNASCHI M， CACACE F， IANNELLO G， et al. OpenCAPWAP： an open source CAPWAP implementation for the management and configuration of WiFi hotspots [J]. Computer Networks， 2009， 53（2）： 217-230.

[2]NIE Y. Research on CAPWAP protocol system implementation technology [D]. Wuhan： Huazhong University of Science and Technology， 2011.（聶勇.CAPWAP協議系統實現技術研究[D].武漢：華中科技大學，2011.）

[3]ZHANG G. CAPWAP protocol and its application in integrated switch [D]. Xian： Xidian University， 2009.（張弓長.CAPWAP協議及其在有線無線一體化交換機中的應用[D].西安：西安電子科技大學，2009.）

[4]GUO Z. Design and implementation of wireless access point extensions based on CAPWAP protocol [D]. Xian： Xidian University， 2011.（郭子明.基于CAPWAP協議的無線接入點擴展的設計與實現[D].西安：西安電子科技大學，2011.）

[5]CALHOUN P， MONTEMURRO M， STANLEY D. RFC 5415， Control And Provisioning of Wireless Access Points （CAPWAP） protocol specification [S]. Fremont， CA： IETF， 2009.

[6]CALHOUN P， MONTEMURRO M， STANLEY D. RFC 5416， CAPWAP protocol binding for IEEE 802.11 [S]. Fremont， CA： IETF， 2009.

[7]China Mobile Communications Corporation. China mobile WLAN ACAP interface interoperability test specifications： basic protocol volume （Version： 1.0.5） [M]. Beijing： China Mobile Communications Corporation， 2011.（中國移動通信集團公司.中國移動WLAN ACAP接口互通測試規范（基本協議分冊）（版本號：1.0.5）[M].北京：中國移動通信集團公司，2011.）

[8]RESCORLA E， MODADUGU N. RFC 4347， datagram transport layer security [S]. Fremont， CA： IETF， 2006.

[9]LIANG W， DONG P， ZHANG H. Research and implementation of centralized management and configuration based on CAPWAP [J]. Compute Technology and Development， 2011， 22（11）： 69-72.（梁文波，董平，張宏科.基于CAPWAP 的集中配置管理機制的研究與實現[J].計算機技術與發展，2012，22（11）：69-72.）

[10]HUANG J， DAI Q， JIANG W. Implementation of centralized WLAN based on CAPWAP [J]. Mobile Communications， 2011， 35（8）： 68-72.（黃軍記，戴青云，姜文超.基于CAPWAP的集中式WLAN實現[J].移動通信，2011，35（8）：68-72.）

[11]HUANG J. Improvement and implement the CAPWAP protocol on the fit AP system [D]. Guangzhou： Guangdong University of Technology， 2011.（黃軍記.瘦AP系統中CAPWAP協議的改進與實現[D].廣州：廣東工業大學， 2011.）

[12]BERNASCHI M， CACACE F， DAVOLI A， et al. A CAPWAPbased solution for frequency planning in large scale networks of WiFi hotspots [J]. Computer Communications， 2011， 34（11）： 1283-1293.

[13]XIANG W， WANG Z， GAO C. Communication protocol of centralized WLAN architecture [J]. Computer Engineering， 2008， 34（22）： 115-117.（向望，王志偉，高傳善.集中式WLAN體系結構通信協議[J].計算機工程，2008，34（22）：115-117.）

篇10

關鍵詞：云存儲；Hadoop；分布式存儲

中圖分類號：TP393 文獻標識碼：A 文章編號：1009-3044（20015）02-0003-03

Abstract：Google launched "Google101 program" in 2006. This is when truly specific concept of the "cloud" and related theories appear.Many companies have launched their own cloud platform. Facing the possibility of upcoming massive data of the library，cloud storage can linearly extend inactive data mass. This paper firstly outlines the basic architecture of the cloud platform， and introduces Hadoop distributed storage technology ， then a program for the cloud storage in small files is designed.Finally a summary and recommendations for future improvements are put forward.

Key words： cloud storage； Hadoop；distributed storage

目前隨著移動設備和無線網絡的迅速普及，在移動互聯網上創建虛擬3D世界變得非常流行，已成為一個新興數字媒體產業，并顯現出巨大的市場潛力和光明的產業化前景。同樣，為了推動這一產業的發展，那么集合大量的Web3D素材是極其有必要的。但是，由于Web3D素材的特性，不可避免的包含大量貼圖，從而其數據大小不同于文字和普通的圖片，級別普遍在十幾兆到數十兆之間。隨之而來的就是數據的存儲和管理問題，存儲方面，目前行業中的素材數量沒有具體統計，但粗略估算在千萬量級甚至以上。數據量龐大，以及數據傳輸效率的要求，云存儲系統是最合適的解決方案。

1 云平臺的基礎架構

云計算涉及在現有網絡上進行分布式計算，借此用戶的程序或應用可以同時在一臺或多臺連接到這個網絡的計算機上運行。一個或一組物理存在的計算機通過互聯網（Internet）、內網（Intranet）、局域網（local area network）或者廣域網（wide area network）連接到一起，作為一個整體以服務器的形式呈現給外界，這樣的形式就是云計算的具體表現。任何有權限訪問這個服務器的用戶可以使用它的計算能力來運行應用、存儲數據或者執行其他任務。

云計算服務的模式主要有三種：基礎設施即服務（Infrastructure-as-a-Service， IaaS），平臺即服務（Platform-as-a-Service，PaaS）和軟件即服務（Software-as-a-Service，SaaS）。其邏輯上的關系見圖1。

IaaS，基礎設施即服務是最基本的云服務模型，主要功能是將計算機偏底層的資源作為服務提供給用戶，其中主要是提供計算機服務，可以根據用戶的性能需求進行相應的配置調整，如CPU核數，內存大小，硬盤容量等等。用戶通過互聯網從這些集群設備中去申請服務。

PaaS是把計算平臺（Computing Platform）作為一種服務提供的商業模式。其中，計算平臺主要包括操作系統，程序語言執行環境，數據庫，Web服務器等平臺級產品。

SaaS模型的服務是將應用軟件作為服務提供給用戶。在這個模型中，運行應用軟件所需要的軟硬件資源皆由SaaS的提供商管理、維護。

云平臺是用來提供各種云計算服務的平臺。用戶可以在云平臺上購買、使用云計算服務，方便用戶組合使用云計算服務以達成用戶的目標。國外較為知名并具有代表性的有谷歌的云計算平臺（Google Cloud Platform），IBM的“智慧云”計算平臺（SmartCloud）和Amazon的彈性計算云（Elastic Compute Cloud）。國內也開始推出自己的云平臺，比較大的有百度云平臺和阿里云平臺，為客戶提供各類云服務。

2 分布式存儲系統Hadoop介紹

Hadoop作為分布式存儲系統的典范，是一個能夠對大量數據進行分布式處理的軟件框架，具有高容錯性和高擴展性等優點，允許用戶將Hadoop部署到價格低廉的服務器上，實現了將一項任務分發到由多臺機器組成的集群上，并有一系列的高容錯機制支撐。在具體實現時，開發人員直接搭建，實現整個云平臺的管理，而又不需要知道內部機制，這種智能化便捷化的分布式集群對開發人員技術的要求門檻較低。

Hadoop與GoogleGFS幾乎一致，因為Hadoop就是根據GFS創造的，包含HDFS、MapReduce、HBase。

2.1 HDFS

HDFS最上層是一個NameNode，下面有許多DataNode，關系像Master和slave一樣，所以有時候也稱NameNode為Master，DataNode為slave。NameNode對管理文件系統的元數據進行管理。DataNode中存儲實際的文件數據。客戶端和NameNode進行通信，獲取到文件的元數據后，然后直接和DataNode進行文件的I/O操作。

HDFS最常見的部署方法就是將NameNode部署在一臺專門的服務器上，在集群中的其他機器上運行一個或多個DataNode；同時也可以在NameNode所在的服務器上運行一個或多個DataNode。采用一個NameNode使整個系統的架構非常簡單。

NameNode中會記錄HDFS中元數據的變化，采用的是EditLog形式記錄。NameNode中使用FsImage來存儲文件系統的命名空間，命名空間包括文件與塊之間的映射，文件本身的屬性等。EditLog和FsImage都存儲在Namenode上。

HDFS中為了維持系統的穩定性，還設立了第二個NameNode節點，稱作Secondary NameNode節點，它會輔助NameNode處理FsImage和EditLog。NameNode啟動時會將EditLog和FsImge合并，而Secondary NameNode會周期性地從NameNode上去復制這些FsImage和EditLog到臨時目錄中，合并生成新的FsImage后再重新上傳到 NameNode，這樣當NameNode宕機后，Secondary NameNode還可以繼續工作，所保存的FsImage信息還存在。

2.2 HBase

HBase系統在架構層面由一個Master和多個RegionServer組成。如圖2所示。

其中，每個RegionServer對應集群中的一個節點，一個RegionServer負責管理多個Region。一張表上有很多數據，每個Region只是一張表上的部分數據，所以在HBase中的一張表可能會需要很多個Region來存儲其數據。HBase在對Region進行管理的過程中，會給針對每一個Region劃定一個范圍，也就是Row Key的一個區間，在這個特定的區間內的數據就交給特定的Region，這樣能夠保證負載相對均衡，能夠分攤到各個節點之上，這也是分布式的特點。此外，HBase也會自動地調節Region所在的位置。如果一個RegionServer變得比較活躍，使用的比較頻繁，HBase會把 Region轉移到不是很忙的節點，如此集群環境可以被合理使用。

Table在行的方向上劃分成多個Region，Region是按照空間來劃分的，最初建立Table時，Table內的Region數量只有一個，隨著系統的投入使用，Table內開始被不斷的插入數據，Region內會不斷的存入數據，當數據量達到某個特定的閥值，Region就會等分，變成兩個Region。Table是面向列的數據庫，行數會不斷的增加，HRegion數量也會不斷增多。在HBase中，分布式存儲的最小單元是HRegion，但是一個HRegion內又有一個或多個store構成。如圖3所示：

3 基于HBase的Web3D素材存儲設計

3.1 存儲系統的整體設計

由于素材本身數據的屬性，比如名稱、別名、文件類型等，這些信息存儲在MySQL中，同時為素材分配一個ID，在HBase存儲這個ID信息和一些簡單的關系稀疏的文件屬性。如圖4所示：

3.2 小型素材文件在HDFS上的存儲

系統素材文件[19]本身存儲在由HBase管理的HDFS中，而HDFS是專門為了大數據存儲而設計的，針對Web3D素材普遍是小文件的情況，就采用將素材文件進行合并，形成一個個大文件，然后將這些大文件存儲到HDFS中的做法實現小文件的存儲。

將素材文件合并后，我們不僅僅是存儲進系統，平臺本身還需要隨時查詢這些小文件，所以我們必須建立素材小文件與合并后的塊的對應關系。我們在文件名中標注合并后的大塊的ID以及塊內的偏移量加上文件塊內的長度來標記這個文件。

假設素材文件大小為2M，默認的一個塊的大小為64M。首先Master會在集群內找到一個空余剩余超過2M的塊。假設塊的ID為1234，且已經存儲了32M的數據，塊內的偏移量是通過頁來記錄的，一頁的大小為16k，那么目前32x1024/16=2048，那么素材存儲的位置就是從2049開始的，并且2M大小的數據占空間為128頁，那么該素材文件標記為（1234，2049，128）。

但是HDFS中的Master部分并沒有關于文件和塊的映射關系，我們需要在Master中設計這樣的查詢功能，新系統的架構圖如圖4所示：

當客戶端想要讀取某個素材文件時，首先從NameNode中的查詢模塊，從而獲得素材文件與塊之間的映射信息。

4 結束語

本文部署了Hadoop集群作為系統的分布式云存儲平臺，將用戶的資料等結構化數據存儲在MySQL中，并在MySQL中存儲部分關聯性強的素材元數據，并且指定ID。將素材本身存入Hadoop集群中，通過小文件打包的形式，改善了Hadoop集群中不適合存儲小文件的情況。但是關于系統文件打包機制，存儲后的刪除問題，僅僅從MySQL中刪除了素材文件的源信息，實際的文件還部分殘留在系統中，這一點應該對文件與塊的關系上繼續深化研究下去。

參考文獻：

[1] Bhardwaj Sushil， Leena Jain， Sandeep Jain. Cloud computing： A study of infrastructure as a service （IAAS）[J]. International Journal of engineering and information Technology， 2010（2.1）： 60-63.

[2] Vaquero， Luis M. A break in the clouds： towards a cloud definition[J]. ACM SIGCOMM Computer Communication Review， 2008，39（1）： 50-55.

[3] Cloud， Amazon Elastic Compute. Amazon web services[J]. Retrieved November， 2011（9）： 2011.

[4] 黃賢立. NoSQL非關系型數據庫的發展及應用初探[J]. 福建電腦， 2010（7）： 30.

[5] 黃曉云. 基于HDFS的云存儲服務系統研究[D]. 大連： 大連海事大學. 2010.

[6] 余思， 桂小林， 黃汝維. 一種提高云存儲中小文件存儲效率的方法[J]. 西安交通大學學報：自然科學版， 2011（6）： 59-63.

[7] MACKEY G， SEHRI S， WANG Jua. Improving metadata management for small files in HDFS[C]. 2010.

[8] 肖桐. 應用于海量數據處理分析的云計算平臺搭建研究[D]. 天津： 天津科技大學， 2013.