序論：寫作是一種深度的自我表達。它要求我們深入探索自己的思想和情感，挖掘那些隱藏在內心深處的真相，好投稿為您帶來了七篇備份技術論文范文，愿它們成為您寫作過程中的靈感催化劑，助力您的創作。

篇(1)

關鍵詞：熱備，集群，容錯，數據同步，心跳機制，高可用性

 

0.概述

容錯熱備份系統就是指由至少一臺主機，一臺備機組成的一個集群，當在主機上運行的應用程序或者控制系統由于外界各種未知的干擾，而出現了停止，數據損壞或者丟失的情況下，集群會自動將主機上運行的應用程序或者控制系統切換到備機上繼續運行，并且保證網絡ip地址也隨之進行切換，保證數據同步，使數據不丟失，不損壞。論文參考網。

本文主要研究了容錯熱備份系統的切換可靠性，方案的可用性以及監控過程中的心跳機制和切換當中的數據同步。分別驗證了“N對1”和“N加1”的熱備份方案。

1.容錯熱備份系統的原理介紹

Veritas ClusterServer(VCS)，是一種高可用性集群軟件，主要用在雙機熱備，容錯系統中，保護數據，保持不間斷服務。本文即采用Symantec公司的VCS軟件達到對應用程序中進程的監控和切換。VCS使用的心跳協議是低延遲傳輸協議(LLT, Low LatencyTransport)，LLT協議比IP協議更快并且可靠， LLT協議上方為組成員和廣播協議(GAB, Group MembershipService Broadcast)，由其發送廣播。GAB為多點對多點的傳輸協議，有信息傳輸的安全保障功能， GAB驅動LLT，為整個集群提供了可靠的數據傳輸。高可用進程(High availability Daemon, HAD)是VCS的主要進程，在GAB上層注冊，用以監控管理集群中物理機器的狀態。在以上這些協議以及進程之上，VCS中，是最上層提供管理資源的邏輯的多縣城進程。針對每個資源類型，都有相應的，監視對應類型的資源。原理構架如圖一所示：

圖一 VCS原理構架

2.容錯熱備份系統的方案對比

本文采取的容錯熱備份方案有以下兩種：N對1熱備份方案和N加1熱備份方案。論文參考網。論文參考網。

2.1 N對1熱備份方案

N對1的熱備份方案主要采用的是非對稱的故障切換模式，提供了一個專用的備份服務器，整個集群中的N臺主機對應一個備機，當任何一臺主機發生故障時，集群會將該主機的應用程序切換到這一臺備機上，由于提供了專用備機，沒有在同一臺計算機上運行多個應用程序而互不兼容的風險。

2.2 N加1熱備份方案

N加1熱備份方案主要采用的是對稱故障切換模式，該方案下，不需要專門的冗余服務器，集群中的一臺額外服務器只是用作備份容量，集群中的某臺主服務器出現故障時，可以通過之前的配置，切換到集群中任意一臺機器上，任何服務器可以為其它服務器提供冗余。

3.容錯熱備份系統的實現及驗證結論

本文的實驗環境采用3臺Linux操作系統的計算機作為容錯熱備份系統的物理節點，掛接磁盤，分別用來驗證N對1和N加1方案的可行性。

本文論證了三種情況：1.殺死主機上正在運行的應用程序的進程（即可認為是應用程序出現問題的情況）；2.主機與公網斷網的情況；3.主機意外宕機的情況。以上三種情況下，該容錯熱備份系統均能成功檢測并且平滑切換，保證了數據同步，數據信息無損失。

通過對容錯熱備份系統的深入研究，以及多種不同熱備份方案的比較，得出以下結論：本文采用的容錯熱備份系統，適用性廣泛，對于各種不同的領域，均可達到網絡信息與服務高可靠性的持續運行，并且保證數據的同步。

【參考資料】

[1]張艷,李舟軍,何德全.災難備份和恢復技術的現狀與發展[J].計算機工程與科學,2005,(02).

[2]劉迎風,祁明.容災技術及其應用[J].計算機應用研究,2002,(06).

[3]劉衛平.網絡存儲中的數據容錯與容災技術研究[D].西北工業大學, 2006.

[4]于雪松,王孝良,張雪源.具有雙機熱備功能智能電網數據采集系統[J].東北電力技術2010,(01).

[5]王麗華.計算機容錯系統的體系結構與安全性研究[D].西南交通大學,2002.

[6]李海山.面向恢復的容錯計算機技術研究[D].哈爾濱工程大學,2007.

[7]何曉琴,胡勇,常有渠.一種低成本的數據庫熱備份方法[J].重慶電力高等專科學校學報,2008,(04).

[8]陳筠,桑楠,熊光澤. 一種容錯實時計算機體系結構的研究與實現[J].電子科技大學學報,2007,(05).

[9]毛睿.“雙機容錯”在我院信息系統中的應用[J].電腦知識與技術,2008,(35).

篇(2)

論文摘要：急救指揮中心所有的軟件和用戶數據都存儲在服務器硬盤這個核心的數據倉庫中，如何保證服務器數據的安全，并且保證服務器最大程度上的不間斷運作對每個指揮中心來說都是一個關鍵問題。針對急救通訊指揮系統的安全保障問題，從數據物理安全、網絡安全、應用系統安全、告警控制系統等方面論述了應采取的安全防范措施。對保障網絡指揮中心數據安全具有重要意義。

1數據的物理安全方法

1.1RAID技術

對每臺服務器的兩塊硬盤做RAID技術處理，把多塊獨立的硬盤(物理硬盤)按不同的方式組合起來形成一個硬盤組(邏輯硬盤)，從而提供比單個硬盤更高的存儲性能和提供數據備份技術。數據備份的功能是在用戶數據一旦發生損壞后，利用備份信息可以使損壞數據得以恢復，從而保障了用戶數據的安全性，而且數據備份是自動的。在用戶看起來，組成的磁盤組就像是一個硬盤，用戶可以對它進行分區，格式化等等。總體來說，RAID技術的兩大特點是速度和安全。

1.2雙機熱備系統

從狹義上講，雙機熱備特指基于active/standby模式的服務器熱備。服務器數據包括數據庫數據同時往兩臺或多臺服務器寫，或者使用一個共享的存儲設備。在同一時間內只有一臺服務器運行。當其中運行著的一臺服務器出現故障無法啟動時，另一臺備份服務器會通過軟件診測(一般是通過心跳診斷)將standby機器激活，保證應用在短時間內完全恢復正常使用。雙機熱備的工作機制實際上是為整個網絡系統的中心服務器提供了一種故障自動恢復能力。

2、網絡安全保障體系

中心網絡由局域網、外部網兩大部分組成。因此，我們為了建立起強大、穩定、安全的網絡，可從兩大安全層次著手設計與管理：局域網安全和外部網安全，這兩大層次結合起來才能構成完善的網絡安全保障體系。

2.1應用系統安全

應用系統的安全主要是保護敏感數據數據不被未授權的用戶訪問。并制訂出安全策略。包括身份認證服務;權限控制服務;信息保密服務;數據完整;完善的操作日志。這些服務互相關聯、互相支持，共同為本系統提供整體安全保障體系。

2.2數據安全

數據的安全主要體現在兩個方面，首先，是數據不會被非授權用戶訪問或更該，其次，數據在遭到破壞時的恢復。

3應用安全系統

資料永久保存，磁帶回復時間無嚴格限制。數據存儲：磁盤陣列+磁帶庫;Tier1=4TB HDD存放線上經常使用的數據;備份帶庫：3TB定時定期備份所有數據。

3.1采用磁帶庫

磁帶庫具有如下優點：更高的價值;簡化IT;集成的解決方案;靈活的數據存儲和轉移;多種接口選擇;AES256位嵌入式硬件加密和壓縮功能;用戶可自行維護和更換的組件;廣泛的兼容性測試;久經考驗的可靠性。

3.2數據備份軟件

3.2.1基于LAN備份方案

LAN是一種結構簡單，易于實現的備份方案，廣泛的存在于各中小企業中LAN方案在企業發展壯大過程中所發揮的作用一直被客戶所認同。由于急救系統用戶數據量的巨大，基于LAN備份的弊端較突出：此方案對LAN的依賴非常強;因為內部LAN為企業內部辦公用網絡，而LAN方案依賴現有網絡進行備份恢復數據流的傳輸，所以必然會影響現有辦公網絡環境;基于LAN備份難于擴展，因為需要而添加存儲設備將導致繁忙的辦公網絡更加繁忙;管理困難是LAN備份的又一難題，因為設備分散于網絡各個環節，使管理員進行數據備份恢復及平時維護工作有一定難度。

3.2.2基于IPSAN的備份方案

基于IPSAN的備份方案，通過結合CBS備份管理軟件，將使備份恢復工作簡單而有效。

備份網絡與辦公網絡有效隔離開，備份數據不通過辦公網絡傳輸，而是直接通過IPSAN交換機與存儲設備進行連接。

系統具備良好的擴展性能，在現有基礎上，客戶能夠添加各種存儲設備(需支持ISCSI)。

根據客戶需要，可以實現D2D2T功能。將數據首先備份于速度較快的磁盤陣列上，加快備份的速度。再將數據從磁盤陣列備份到磁帶庫。

通過CBS備份管理軟件能夠集中管理其中各種設備，制定備份策略，安排備份時間，實現無人值守作業，減輕管理員的工作量。下圖為CBS備份框架。

備份服務器作為整個CBS備份架構的中心，實現管理功能。

4告警控制系統

通訊指揮系統出現故障時自動告警提示，確保系統安全運行。2M口通訊故障告警、網絡通訊故障告警、終端網絡斷開告警、電話到達告警、定時放音、擴音、報時控制，也可自動循環播放、電源出現故障可自動向受理臺告警。

警告系統整體性能：輸入：8-32通道，8通道遞增;電源輸入：AC 180V-250V 50Hz;控制通道輸入及輸出：AC<240V/3ADC<30V/3A;告警控制盒與計算機的通訊連接告警控制盒端用：232口;計算機端用：COMl口或COM2口;使用電纜：232串口電纜;各告警通道開啟時間超過10分鐘將自動關閉;各開/關控制通道接通時間超過10分鐘將自動斷開。

5總結

隨著數據管理與控制信息化綜合系統的不斷完善，對服務器數據的安全要求也越來越高，論文就如何保障急救指揮中心證服務器數據的安全，論文從數據物理安全、網絡安全、應用系統安全、告警控制系統等方面論述了應采取的安全防范措施。對保障網絡指揮中心數據安全具有指導性的作用。

參考文獻：

[1]何全勝，姚國祥.網絡安全需求分析及安全策略研究.計算機工程，2000，(06).

篇(3)

關鍵詞： IPTV; 負載平衡; 影音串流; 影音備份; 隨選視訊

中圖分類號： TN964?34 文獻標識碼： A 文章編號： 1004?373X（2014）24?0022?06

IPTV system with load balance among replica servers

GUO Shu?yao， LI Meng?huang

（Department of Information Technology and management， Shih Chien University， Taipei 104， Taiwan， China）

Abstract： Since the video media has wide band width， the improvement of QoS （quality of service） of IPTV system depends on effective management of video servers. A video replication and access request distribution algorithm to implement a load balanced IPTV system with replica servers is proposed in this paper. The proposed algorithm is based on the more replicas for hot program and load distribution among replica servers. By comparing with two other algorithms， the proposed algorithm features better load balance effects. System practices demonstrate that the access requests can be evenly distributed among replica servers such that a better streaming service can be provided. The proposed algorithm has been implemented on an IPTV system platform. The relative technical issues for the implementation are discussed.

Keyword： IPTV; load balance; video streaming; video replica; video on demand

0 引 言

在VOD（Video on Demand）的系統規劃上或是Video Replication and Placement的研究上，或是CDN（Content Delivery Network）系統建置的成本問題探討上，storage capacity的需求是很明確的，就是各Video program的檔案總和（也就是各Video program的program duration總和）。然而network bandwidth的需求的估算就比較困難[1?3]。論文以“worst?case demand”作為network bandwidth配置的參考參數，從而決定系統建置所需的storage capacity、網絡光纖及交換設備的容量。Worst?case demand即是peak usage demand，在peak usage period的時候，使用者的數目達到最高峰，這些使用者所使用的network bandwidth總和即是worst?case demand，系統網絡的配置必須依據此最高峰的network bandwidth需求來設定，以確保其服務質量。而在文獻[1?3]的論文中，則以replication的方式來分散單一Origin server的負荷，在此架構中，Replica servers用來儲存許多熱門的影音內容，各影音內容依其viewing request probability來決定影音replication的份數，從而分散這些熱門影音內容被點選時的網絡流量帶寬，以得到最佳成本的系統建置。 雖然上述論文有數學模式來描述worst?case demand的估量方法，然而還是無法精確地估量系統的worst?case demand，尤其Replica servers對worst?case demand估量的影響，文獻[1?3]的分析模式有其適用性的問題與困難。除了文獻[1?3]的研究外，文獻[4?8]等研究的replication策略， 都是依各影音的熱門程度，給予不同備份數的影音檔，藉此來分散掉該影音在Origin Server的負荷。比如若A影片的熱門程度是B影片的3倍的話，若B影片在replica servers有2個replicas的話，那么A影片就會有6個replicas安置在replica servers。而上述影音的熱門程度的決定，在文獻[4?8]等的研究會以影片的access rate或access probability或popularity來界定該影音的熱門程度。

本文以圖1的架構探討具有replica servers的IPTV系統架構的video replication及access request distribution。如何將Origin Server里的影音replicated至replica server，此即video replication的問題;當一個access request要求服務時，如何將此access request distribute各replica servers，此即access request distribution的問題。此IPTV系統是架構在Smart?iTV的系統平臺，提供以遙控器為輸入設備的IPTV服務[9]，亦能提供匯流IPTV、PC及mobile device的數字匯流影音服務[10]。

圖1 具有replica servers的VOD系統架構

1 Video replication algorithm和Access

request distribution algorithm

為了方便探討，本文假設此IPTV系統的每個影音檔案都具有同樣的大小以及播放的帶寬。因此對于Replica Server j的空間容量Cj系以可以儲存多少個影片來表示;而Replica Server j的帶寬容量Bj 則以可以同時播放多少個影片來表示。本文以αj來代表Replica Server j的replication風險值，此值是探討Video replication algorithm的重要參考值。

表1 理論模式中所提及的符號

以下列的Test Case來比較不同算法的優劣，此Test Case為：v1，v2，v3，v4，v5，v6，v8，v10，v12。假設有9部影音分別為v1每1 s被點播1次;v2每2 s被點播1次;v3每3 s被點播1次;v4每4 s被點播1次;v5每5 s被點播1次;v6每6 s被點播1次;v8每8 s被點播1次;v10每10 s被點播1次;v12每12 s被點播1次，共9部影音。此時有一部Origin Server以及三部replica servers為Replica Server I，Replica Server Ⅱ，Replica Server Ⅲ來建構此9部影音的播放服務;每當有一影音被點播，則該影音第一次被播放時是Origin Server來提供，此時該影音將被備份至3部replica servers中的某一臺，之后該影音要再度被點播時則由存放該影音的replica server來提供;此處亦假設每部replica server的Bj為3，Cj為4。以下分別以算法一、算法二、算法三來探討不同算法的優劣。

算法1：Video replication algorithm：選擇最不常使用的replica server作為video replication的replica server。Access request distribution algorithm： 端視access request的影音座落在哪個replica server，即由該replica server執行該影音的播放。

根據上述algorithms，Test case在各時間的video replication及access request distribution如圖2所示。第1 s時v1由Origin Server播放，此時三部replica servers總共播放次數皆為0，則依順序從Origin Server中將v1影音復制至Replica Server I，此時Replica Server I的存放影音個數為1。第2 s時v1由Replica Server I執行v1的播放，此時v2由Origin Server被播放，同時v2將從Origin Server被復制，此時Replica Server Ⅱ，Replica Server Ⅲ尚無提供影音的播放，則依順序從Origin Server中將v2影音復制至Replica Server Ⅱ ，此時Replica Server Ⅱ的存放影音個數為1。于第8 s時，Replica Server Ⅲ的存放影音個數為4，已達到replica server最大儲存空間Cj上限4。而在第10 s時，由于Replica Server Ⅲ影音總共播放次數最少，因而從Origin Server將v10復制至Replica Server Ⅲ，但Replica Server Ⅲ儲存影音空間Cj已達上限4，因此將發生v10無法被復制及播放問題。

圖2 算法1的仿真結果

算法2：Video replication algorithm：選擇較低的αj的Replica Server j執行video replication;Access request distribution algorithm：端視access request的影音座落在哪個replica server，即由該replica server執行該影音的播放。

根據上述algorithms，Test case在各時間的video replication及access request distribution如圖3所示。第1 s時v1由Origin Server播放，此時v1將被復制，同時三部replica server之αj值皆為[03]，則依順序從Origin Server中將v1備份至Replica Server I，此時Replica Server I的存放影音個數為1。第2 s時v1由Replica Server I執行v1的播放，同時v2從 Origin Server中被播放，此時Replica Server Ⅱ，Replica Server Ⅲ之αj值皆為[03]，則依順序從Origin Server中將v2備份至Replica Server Ⅱ，此時Replica Server Ⅱ的存放影音個數為1。第3 s時v1由Replica Server I執行v1的播放，同時v3從Origin Server中被播放，此時Replica Server Ⅲ之αj值為[03]，則從Origin Server中將v3備份至Replica Server Ⅲ，此時Replica Server Ⅲ的存放影音個數為1。依此程序持續將v1，v2，v3，v4，v5，v6，v8，v10，v12備份在Replica Server I、Replica Server Ⅱ、Replica Server Ⅲ上，雖然與演算一比較后每個影音都能均勻分布在各個replica server上，但未考慮各個影音熱門程度問題，因此各個replica server處理影音播放工作量不平衡，可得知Replica Server I播放影音總共次數比Replica Server Ⅱ及Replica Server Ⅲ多，但未達到負載平衡成效。

圖3 算法2的仿真結果

算法3：Video replication algorithm：選擇較低的αj的Replica Server j執行video replication;并將熱門的影音備份到更多的replica servers。Access request distribution algorithm：當有多個replica servers具有access request所需的影音時，選擇負荷最小的replica server，執行該影音的播放。

根據上述algorithms，Test case在各時間的video replication及access request distribution如圖4所示。

事先設定每5 s會去查詢單位時間內影音被播放的狀況以得知5 s內被點播次數最多的影音，設定為熱門影音，即備份至其他的replica servers，以平均分擔各個replica server的負載。本算法在將影音備份到各個replica servers的過程，具皆與算法二一致，亦即以αj值作重要的參考參數。當在第5 s時v1被播放，系統每5 s查詢各影音被播放之狀況，發現v1于5 s內被播放次數達到4次。相較于目前所被播放的影音v2，v3，v4都來得熱門許多，因此啟動v1備份。由于Replica Server Ⅱ、Replica Server Ⅲ之αj值皆為[13]，則依順序將v1備份至Replica Server Ⅱ。至于access request distribution的運作，以圖4的第120 s為例，在此時間，Test Case的9個影音都需播放，由于v3，v4，v5，v6，v8，v10，v12均只有一份影音在特定的replica server，所以這些影音只能在此些replica server上播放。亦即Replica Server I播放v4，v6，v10;Replica Server Ⅱ播放v5，v8，v12;Replica Server Ⅲ播放v1，v3，v5;如是Replica Server I為滿載負荷，Replica Server Ⅱ、Ⅲ相對負荷較小。由于v2在Replica Server Ⅱ、Ⅲ均有備份，v1則在Replica Server I、Ⅱ、Ⅲ均有備份，所以擇定v2在Replica Server Ⅱ播放，v1在Replica Server Ⅲ播放，如此可以得到3部replica servers的負載平衡。

圖4 算法3的仿真結果

圖4與圖3相較，皆能符合系統影音服務需求，圖4經由將熱門影音備份在更多的replica servers，而有較佳的負載平衡，其負載比例為1∶1∶0.9，而圖3的負載比例為1∶0.5∶0.3。因此，本文即以算法3作為實踐此一具有負載平衡的IPTV串流系統。

2 系統架構

2.1 前臺系統架構

由于本文是修改Smart?iTV系統平臺，以成為一個具負載平衡的影音串流系統，所以本論文勢必須對Smart ?iTV系統做詳盡的剖析，才能在此系統內嵌此負載平衡的模塊。攸關本論文的Smart?iTV系統為其前臺系統，此前臺系統概分為影音選單頁面、影音介紹頁面、以及影音播放頁面，如圖5所示。

影音選單頁面的選項可能為影音內容的選項或是另一個影音選單頁面，若是該選項屬于影音內容的選項，當該選項被點選時，系統即呈現該影音內容的影音介紹頁面，該頁面會有一觸發影音播放的關鍵點，當使用者啟動觸發影音播放關鍵點時，該影音內容即內嵌在影音播放頁面做串流播放，并且將該影音的播放次數記錄在Smart?iTV的數據庫里。

圖5 Smart?iTV影音選單頁面到影音播放頁面的流程關系

2.2 具平衡負載的串流系統架構分析

為達串流負載平衡的串流系統，本論文提出Original video replication、Hot video replication 及Access request distribution這三個模塊的實作，如圖6所示。當使用者點播某部影音時，Original video replication module將查詢使用者所點選的影音過去曾被播放過，若不曾被播放過，則由Origin Server提供影音播放服務，并依照算法3，將所被點播的影音備份至αj值較低的Replica Server j;若曾被播放過，則Access requests distribution process將至Smart?iTV數據庫查詢哪些replica servers有該影音的備份，并依算法3選擇負載較低的replica server，來執行此影音播放的服務。Hot video replication process是一個back?ground process，每單位時間內去查詢Smart?iTV數據庫中被點播次數最多的影音，判定為熱門影音，并選擇αj值較低的replica server，將此熱門的影音備份到該replica server。圖6的Replica Server I、Ⅱ兩個replica servers，在Smart?iTV的Original video replication module及Hot video replication process會各自與replica server的Peer video replication共同完成video replication的任務。

圖6 具平衡負載的串流系統架構圖

3 系統實作

由于本系統是架構Smart?iTV上，所以會引用部分Smart?iTV數據表及相關字段，并增加部分的數據表及數據表字段，為使這些信息能夠被清楚檢視，茲整理如表2所示。

表2 影音播放相關數據表

參照圖7，當使用者進入影音選單頁中所呈現的影音選項來自步驟0.1的CategoryTemplate數據表中Cate_Name值，而使用者點選某一影音選項時則可能導向步驟0.2或步驟0.3，步驟0.2根據使用者所點選之Cate_Name值找出其對應的Cate_ShowMode值，當Cate_ShowMode為‘3’時則又是另一組影音選單頁，當Cate_ShowMode值為‘1’時直接進入步驟0.3同時將Cate_UID值傳至影音介紹頁，依照Cate_UID值根據步驟0.4找到相符合的ML_PID值所對應的ML_UID域值及ML_Content及影音文件名。當使用者于影音介紹頁中啟動觸發影音播放的關鍵點時，及執行步驟0.5將ML_Content值傳至影音播放頁，影音播放頁串流服務是透過mms的協議來達成的，此即mms：//IP address of a replica server/Media Service的發行端點/被點播的影音檔名，被點播的影音檔名即步驟0.5的ML_Content值。同時執行步驟0.6將View_ContentID值記錄至View_Content_Log數據表，以記錄像音的播放次數。基于上述所討論的Smart?iTV的架構，本論文在影音播放頁內嵌了Original video replication module及Access request distribution process的模塊、在Smart?iTV的系統安置了Hot video replication process的background job、以及記錄各replica servers規格的Replica_Server_Profile數據表、記錄各replica servers存放影音文件的Replication_Log數據表、記錄各影音在各replica servers播放次數的View_Count，如圖7所示。圖7的0.1～0.6步驟，為上述Smart?iTV既有影音播放的流程;步驟1.1～1.4是Original video replication module的步驟流程;步驟2.1～2.5是Access request distribution process的步驟流程;步驟3.1～3.7是Hot video replication process的步驟流程。當有一影音被點播，Original video replication module將查詢View_Content_Log及MediaListTemplate檢視該影音過去是否有被播放過，如步驟1.1;若不曾被播放過，此時依照圖6情境由Original Server提供影音播放，隨即啟動video replication將影音備份至最小αj（從Replica_Server_Profile得到）的Replica Server j，并更新Replica_Server_Profile的Replica Server j存放的影音數及記錄備份影音數據至Replication_Log，如步驟1.2、1.3、1.4;若不曾被播放過即啟動Access request distribution process，選擇Origin Server播放，同時標記該影音已表示該影音被播放過，若曾被播放過至Replication_Log查詢該影音備存放在哪一Replica Server j，挑選該Replica Server j播放，并記錄其播放該影音次數，如步驟2.1、2.2;若于Replication_Log中查詢到有兩個Replica Server j皆擁有該影音檔案，則依步驟2.3查詢View_Count_Stat_On_Replica數據表根據播放影音量最少的Replica Server j來播放，并記錄Replica Server j播放次數，如步驟2.4、2.5。

圖7 具負載平衡之IPTV系統實作架構

步驟3.1、3.2單位時間內Hot video replication process將去查詢View_Count_Log數據表被播放次數最高的影音，設定為熱門影音，如步驟3.3;即啟動video replication將影音備份至最小αj（同步驟1.2）的Replica Server j，如步驟3.4;并更新Replica_Server_Profile的Replica Server j存放的影音數及記錄Replication_Log備份影音數據，如步驟3.5、3.6;每當Hot video replication process完成video replication動作時，即更新View_Count_Log重置影音播放次數，如步驟3.7。

圖8 具負載平衡之IPTV影音串流系統實作

圖8為圖7的細部流程及對應的數據表的關系圖。使用者要點播影音vi，可從View_Content_Log及MediaListTemplate中計算ML_UID次數，即可判斷vi是否曾經被點播過，若不曾點播過vi，則Origin Server播放vi，并將vi備份至最小αj（從Replica_Server_Profile計算CurrVideoNum/Bandhwidth得αj）的Replica Server j并更新Replica_Server_Profile的CurrVideoNum值及記錄Replication_Log的Video_Name值為vi，同時于記錄MediaListTemplate的ML_PlayBack值，表示已被Origin Server播放過。若vi曾被點播過（從MediaListTemplate的ML_PlayBack知道），則從Replication_Log數據表可知，是否有兩部以上replica servers存放vi。若為false，即從Replication_Log挑選存放vi的Replica Server j播放，并于View_Count_Stat_On_Replica中記錄Replica Server j播放vi次數;若為true，即從View_Count_Stat_On_Replica數據表中，搜尋存放vi的replica servers播放影音量最少的Replica Server j來播放vi，同時于View_Count_Stat_

On_Replica中記錄Replica Server j播放vi次數。而Hot video replication process則是每單位時間內計算View_Count_Log中影音放次數最高的影音，并設定為熱門影音，并查詢最小αj的Replica Server j，將此熱門影音備份至更多的replica servers，同時更新Replica_Server_Profile的CurrVideoNum值及記錄Replication_Log的Video_Name值為vi。

4 結 論

本文提出在Smart?iTV平臺上建構一個具負載平衡的IPTV影音串流系統的video replication及access request distribution algorithms，并以Original video replication，Access request distribution及Hot video replication等3個模塊來實作此algorithms。除了比較與驗證相關算法之外，本文已分析系統實作的方式及可行性。經實例驗證，此系統確能達到replica servers負載平衡的效果，以能承載更多的系統服務要求。

參考文獻

[1] THOUIN Frederic， COATES Mark. Equipment allocation in video?on?demand network deployments [J]. ACM Transactions on Multimedia Computing， Communication， and Applications， 2008， 5（1）： 1?22.

[2] THOUIN Frederic， COATES Mark. Video?on?demand server selection and placement [C]// Proceedings of the 20th International Tele?traffic Conference on Managing Traffic Performance in Converged Networks. [S.l.]： [s.n.]， 2007： 18?29.

[3] ZHOU Xiao?bo， XU Cheng?zhong. Efficient algorithm of video replication and placement on a cluster of streaming servers [J]. Journal of Network and Computer Applications， 2007， 30（2）： 515?540.

[4] TAN Bo， MASSOULIE Laurent. Optimal content placement for peer?to?peer video?on?demand systems [C]// Proceedings of IEEE INFOCOM. [S.l.： IEEE， 2011： 694?702.

[5] NEVES Tiago Araujo， DRUMMOND Lucia Maria de A， OCHI Luiz Satoru， et al. Solving replica placement and request distribution in content distribution networks [J]. Electronic Notes in Discrete Mathematics， 2010， 36： 89?96.

[6] CHELLOUCHE Soraya Ait， AUBRY Will， NEGRU Daniel， et al. Home boxes support for an efficient video on demand distribution [C]// Proceedings of 2011 IEEE International Conference on Multimedia and Expo（ICME）. [S.l.]： IEEE， 2011： 1?6.

[7] MU?OZ?GEA Juan Pedro， TRAVERSO Stefano， LEONARDI Emilio， et al. Modeling and evaluation of multisource streaming strategies in P2P VoD systems [J]. IEEE Transaction on Consumer Electronics， 2012， 58（4）： 1202?1210.

[8] WU Wei?jie， LUI J C S. Exploring the optimal replication strategy in P2P?VoD systems： Characterization and evaluation [C]// Proceedings of 30th International Conference on Computer Communications. [S.l.]： IEEE， 2011： 1206?1214.

篇(4)

關鍵詞：內部控制，管理制度

 

我國的會計電算化工作從20世紀70年代開始，經過20多年的不斷發展、完善，目前已經廣泛的應用到各個行業。會計電算化替代傳統的手工記賬，大大提高了工作效率，推動了會計的現代化發展。論文參考，管理制度。會計電算化是會計工作的發展方向，是促進會計基礎工作規范化和提高經濟效益的重要手段和有效措施。在全球經濟貿易一體化的今天，會計電算化地位日趨重要，但它在給我們帶來巨大效益的同時，也存在巨大的風險，建立約束機制，完善電算化內部管理制度是十分必要的，我認為主要應從以下幾個方面加強管理：

一、 建立健全會計電算化崗位、職責范圍，建立相應制度，實行內部牽制

會計電算化后的工作崗位可以分為基本工作崗位和電算化會計崗位。電算化會計崗位包括直接管理、操作、維護計算機及會計軟件的工作崗位，一般可以劃分為：電算主管、軟件操作、審核記賬、電算維護、電算審查、數據分析等崗位。

會計電算化給會計工作增添了新的摘要保持相對穩定。各個工作崗位應建立自己的職責范圍，切實做到事事有人管，人人有專責。

與傳統的會計工作一樣，內部會計控制的關鍵是不相容職務的相互分離，各單位要根據本單位的實際情況和工作需要建立內部牽制制度。論文參考，管理制度。在電算化會計系統中，不相容職務主要包括系統開發、發展與系統操作；數據維護管理與電算審核；數據錄入與審核記賬；系統操作與系統檔案管理等，應建立一套符合職責劃分原則的內部控制制度。其次，單位應對計算機的使用建立一套具體使用制度，盡量做到專機專用；實行用戶權限分級授權管理，增加軟件的限制功能。論文參考，管理制度。

二、 加強計算機硬件、軟件管理

計算機的設備安全和正常運行是會計電算化的前提條件。論文參考，管理制度。對計算機硬件設備的管理包括：（一）、對計算機所處的環境、溫度進行控制；保持設備整潔、定期進行保養、維護等以防止意外事故發生；（二）、建立完善的安全制度，防止設備被盜，防止無關人員進入計算機進行操作等。（三）、對計算機上機管理應有明確的制度規定：包括輪流值班制度、上機記錄制度、上機時間安排等。

互聯網實現了會計資源的信息共享，但同時也處于極大的風險之中。為了提高網絡會計信息的安全應采取嚴密的防范措施。論文參考，管理制度。對計算機軟件的管理包括：（一）、加強會計數據和會計軟件的安全保密，防止非法刪除和修改，定期進行備份。（二）、提高網絡的安全防范能力，可采用防火墻技術、網絡防毒、信息加密、存儲認證、授權進入等措施。此外，會計軟件還應有完備的操作日志文件。

三、 建立健全電算化檔案的管理制度

會計電算化檔案包括存儲在計算機硬盤中的會計數據及其他磁性介質或光盤存儲的會計數據和計算機打印出來的書面等形式的會計數據；會計數據是指記賬憑證、會計帳薄、會計報表等數據。

電算化會計檔案管理是重要的會計基礎工作，應嚴格按照有關規定執行，由專人負責。論文參考，管理制度。（一）、計算機會計系統有關的資料應及時存檔，建立完善的檔案管理制度。檔案管理制度應包括合格的檔案管理人員、完善的資料使用和歸還手續，還應有對所有檔案進行定期備份的措施，制定應急措施和恢復手段，會計軟件一旦受到破壞能夠恢復。（二）、采用光盤等介質存儲會計帳薄、報表，其保存期限同打印輸出的書面形式的會計帳薄、報表。記賬憑證、總分類賬、現金日記賬、銀行日記賬仍需要打印輸出。對磁性介質存放的數據要保持雙備份。（三）、手工錄入并由計算機打印出的記賬憑證上應有錄入人員、稽核人員、會計主管人員的簽名或蓋章，收付款記賬憑證還應由出納人員簽名或蓋章。

四、 加強學習，提高業務素質

目前我國還有相當一部分會計人員素質較低，計算機知識掌握不夠，對計算機的基本操作、維護根本不懂，對使用系統的會計人員應加強培訓，減少系統運行后出錯的可能性。對有關人員的培訓不僅僅是對系統的使用的培訓，還包括系統運行后的內部控制制度，憑證流轉程序等的培訓。掌握會計軟件的各種功能，充分發揮其作用，也是實現電算化安全運行和保障的需要。

篇(5)

 

主要欄目

環境科學理論基礎研究

環境科學應用基礎研究

環境科學應用技術研究

生態環境研究

環境工程研究

環境管理研究

環境經濟研究

環境法律研究

 

投稿要求

1、來稿要求論點明確、數據可靠、邏輯嚴密、文字精煉，每篇論文必須包括題目、作者姓名、作者單位、單位所在地及郵政編碼、摘要和關鍵詞、正文、參考文獻和第一作者及通訊作者（一般為導師）簡介（包括姓名、性別、職稱、出生年月、所獲學位、目前主要從事的工作和研究方向），在文稿的首頁地腳處注明論文屬何項目、何基金（編號）資助，沒有的不注明。

2、論文摘要盡量寫成報道性文摘，包括目的、方法、結果、結論4方面內容（100字左右），應具有獨立性與自含性，關鍵詞選擇貼近文義的規范性單詞或組合詞（3～5個）。

3、文稿篇幅（含圖表）一般不超過5000字，一個版面2500字內。文中量和單位的使用請參照中華人民共和國法定計量單位最新標準。外文字符必須分清大、小寫，正、斜體，黑、白體，上下角標應區別明顯。

4、文中的圖、表應有自明性。圖片不超過2幅，圖像要清晰，層次要分明。

5、參考文獻的著錄格式采用順序編碼制，請按文中出現的先后順序編號。所引文獻必須是作者直接閱讀參考過的、最主要的、公開出版文獻。未公開發表的、且很有必要引用的，請采用腳注方式標明，參考文獻不少于3條。

6、來稿勿一稿多投。收到稿件之后，5個工作日內審稿，電子郵件回復作者。重點稿件將送同行專家審閱。如果10日內沒有收到擬用稿通知（特別需要者可寄送紙質錄用通知），則請與本部聯系確認。

7、來稿文責自負。所有作者應對稿件內容和署名無異議，稿件內容不得抄襲或重復發表。對來稿有權作技術性和文字性修改，雜志一個版面2500字，二個版面5000字左右。作者需要安排版面數，出刊日期，是否加急等情況，請在郵件投稿時作特別說明。

8、請作者自留備份稿，本部不退稿。

9、論文一經發表，贈送當期樣刊1-2冊，需快遞的聯系本部。

篇(6)

[論文摘要]為了保障數據資料的安全，必須進行數據備份。而一旦發生災難，造成大量數據丟失，容災系統將能保證業務盡快恢復，甚至可以保證業務不間斷執行。數據備份也正是容災系統得以運行的前提。

數據資料已經成為企事業單位的無形資產和重要財富，其安全也倍受關注。當遭受地震、洪水、臺風、恐怖襲擊等重大災害，以及發生大范圍停電、網絡中斷、硬件故障等事故時就會由于數據丟失破壞而造成重大損失。考慮到大范圍內災難或故障發生的可能性，為了保障數據安全，利用現有存儲設備資源為大量的主流平臺用戶制定完備的備份和容災方案，構建簡單、經濟、可靠的備份及容災系統，增強系統的抗災能力，最大限度地減少損失有著十分重要意義。

一、數據備份策略

從備份策略來講，現在的備份可分為三種：完全備份、增量備份、差異備份、累加備份策略。下面來討論以下這幾種備份方式：

完全備份就是拷貝給定計算機或文件系統上的所有文件，而不管它是否被改變。

增量備份就是只備份在上一次備份后增加、改動的部分數據。增量備份可分為多級，每一次增量都源自上一次備份后的改動部分。

差異備份就是只備份在上一次完全備份后有變化的部分數據。如果只存在兩次備份，則增量備份和差異備份內容一樣。

累加備份采用數據庫的管理方式，記錄累積每個時間點的變化，并把變化后的值備份到相應的數組中，這種備份方式可恢復到指點的時間點。

一般在使用過程中，這三種策略常結合使用，常用的方法有：完全備份、完全備份加增量備份、完全備份加差異備份、完全備份加累加備份。

完全備份會產生大量數據移動，選擇每天完全備份的客戶經常直接把磁帶介質連接到每臺計算機上（避免通過網絡傳輸數據）。這樣，由于人的干預（放置磁帶或填充自動裝載設備），磁帶驅動器很少成為自動系統的一部分。其結果是較差的經濟效益和較高的人力花費。

完全備份加增量備份源自完全備份，不過減少了數據移動，其思想是較少使用完全備份。比如說在周六晚上進行完全備份（此時對網絡和系統的使用最小）。在其它6天（周日到周五）則進行增量備份。增量備份會問這樣的問題：自昨天以來，哪些文件發生了變化？這些發生變化的文件將存儲在當天的增量備份磁帶上。

完全備份加差異備份的思想也是較少使用完全備份。比如說在周六晚上進行完全備份，在其它6天（周日到周五）則進行差異備份。做差異備份時，將會把自上星期六以來發生了變化的文件存儲在當天的增量備份磁帶上。

二、容災系統的等級及實現技術

容災是一個范疇比較廣泛的概念，廣義上，我們可以把所有與業務連續性相關的內容都納入容災。容災是一個系統工程，它包括支持用戶業務的方方面面。而容災對于IT而言，就是提供一個能防止用戶業務系統遭受各種災難影響破壞的計算機系統。容災還表現為一種未雨綢繆的主動性，而不是在災難發生后的“亡羊補牢”。從狹義的角度，我們平常所談論的容災是指，除了生產站點以外，用戶另外建立的冗余站點，當災難發生生產站點受到破壞時，冗余站點可以接管用戶正常的業務，達到業務不間斷的目的。為了達到更高可用性，許多用戶甚至建立多個冗余站點。

容災系統是通過在異地建立和維護一個備份存儲系統，利用地理上的分離來保證系統和數據對災難性事件的抵御能力。

根據容災系統對災難的抵抗程度，可分為數據容災和應用容災。數據容災是指建立一個異地的數據系統，該系統是對本地系統關鍵應用數據實時復制。當出現災難時，可由異地系統迅速接替本地系統而保證業務的連續性。應用容災比數據容災層次更高，即在異地建立一套完整的、與本地數據系統相當的備份應用系統（可以同本地應用系統互為備份，也可與本地應用系統共同工作）。在災難出現后，遠程應用系統迅速接管或承擔本地應用系統的業務運行。

設計一個容災系統，需要考慮多方面的因素，如備份/恢復數據量大小、應用數據中心和備援數據中心之間的距離和數據傳輸方式、災難發生時所要求的恢復速度、備援中心的管理及投入資金等。根據這些因素和不同的應用場合，通常可將容災系統分為四個等級。

第0級：沒有備援中心這一級容災系統，實際上沒有災難恢復能力，它只在本地進行數據備份，并且被備份的數據只在本地保存，沒有送往異地。

第1級：本地磁帶備份，異地保存在本地將關鍵數據備份，然后送到異地保存。災難發生后，按預定數據恢復程序恢復系統和數據。這種方案成本低、易于配置。但當數據量增大時，存在存儲介質難管理的問題，并且當災難發生時存在大量數據難以及時恢復的問題。為了解決此問題，災難發生時，先恢復關鍵數據，后恢復非關鍵數據。

第2級：熱備份站點備份在異地建立一個熱備份點，通過網絡進行數據備份。也就是通過網絡以同步或異步方式，把主站點的數據備份到備份站點，備份站點一般只備份數據，不承擔業務。當出現災難時，備份站點接替主站點的業務，從而維護業務運行的連續性。

轉貼于

第3級：活動備援中心在相隔較遠的地方分別建立兩個數據中心，它們都處于工作狀態，并進行相互數據備份。當某個數據中心發生災難時，另一個數據中心接替其工作任務。這種級別的備份根據實際要求和投入資金的多少，又可分為兩種：①兩個數據中心之間只限于關鍵數據的相互備份；②兩個數據中心之間互為鏡像，即零數據丟失等。零數據丟失是目前要求最高的一種容災系統方式，它要求不管什么災難發生，系統都能保證數據的安全。所以，它需要配置復雜的管理軟件和專用的硬件設備，需要投資相對而言是最大的，但恢復速度也是最快的。

在建立容災系統時會涉及到多種技術，如：SAN或NAS技術、遠程鏡像技術、基于IP的SAN的互連技術、快照技術等。

衡量容災系統的兩個技術指標：RPO（Recovery Point Objective）：即數據恢復點目標，主要指的是業務系統所能容忍的數據丟失量。

RTO（Recovery Time Objective）：即恢復時間目標，主要指的是所能容忍的業務停止服務的最長時間，也就是從災難發生到業務系統恢復服務功能所需要的最短時間周期。

RPO針對的是數據丟失，而RTO針對的是服務丟失，二者沒有必然的關聯性。RTO和RPO的確定必須在進行風險分析和業務影響分析后根據不同的業務需求確定。對于不同企業的同一種業務，RTO和RPO的需求也會有所不同。

三、數據容災與數據備份的聯系

從定義上看，備份是指用戶為應用系統產生的重要數據（或者原有的重要數據信息）制作一份或者多份拷貝，以增強數據的安全性。因此，備份與容災所關注的對象有所不同，備份關系數據的安全，容災關心業務應用的安全，我們可以把備份稱作是“數據保護”，而容災稱作“業務應用保護”。備份最多表現為通過備份軟件使用磁帶機或者磁帶庫將數據進行拷貝，也有用戶使用磁盤、光盤作為存儲介質；容災則表現為通過高可用方案將兩個站點連接起來。

備份與容災是存儲領域兩個極其重要的部分，二者有著緊密的聯系。首先，在備份與容災中都有數據保護工作，備份大多采用磁帶方式，性能低，成本低；容災采用磁盤方式進行數據保護，數據隨時在線，性能高，成本高。其次，備份是存儲領域的一個基礎，在一個完整的容災方案中必然包括備份的部分；同時備份還是容災方案的有效補充，因為容災方案中的數據始終在線，因此存儲有完全被破壞的可能，而備份提供了額外的一條防線，即使在線數據丟失也可以從備份數據中恢復。

要保護數據，企業需要數據備份和容災系統。但是很多企業在搭建了備份系統之后就認為高枕無憂了，其實還需要搭建容災系統。數據容災與數據備份的聯系主要體現在以下幾個方面：

（一）數據備份是數據容災的基礎

數據備份是數據高可用的最后一道防線，其目的是為了系統數據崩潰時能夠快速的恢復數據。雖然它也算一種容災方案，但這種容災能力非常有限，因為傳統的備份主要是采用數據內置或外置的磁帶機進行冷備份，備份磁帶同時也在機房中統一管理，一旦整個機房出現了災難，如火災、盜竊和地震等災難時，這些備份磁帶也隨之銷毀，所存儲的磁帶備份也起不到任何容災功能。

（二）容災不是簡單備份

真正的數據容災就是要避免傳統冷備份所具有先天不足，它能在災難發生時，全面、及時地恢復整個系統。容災按其容災能力的高低可分為多個層次，例如國際標準SHARE 78 定義的容災系統有七個層次：從最簡單的僅在本地進行磁帶備份，到將備份的磁帶存儲在異地，再到建立應用系統實時切換的異地備份系統，恢復時間也可以從幾天到小時級到分鐘級、秒級或0數據丟失等。

無論是采用哪種容災方案，數據備份還是最基礎的，沒有備份的數據，任何容災方案都沒有現實意義。但光有備份是不夠的，容災也必不可少。容災對于IT而言，就是提供一個能防止各種災難的計算機信息系統。從技術上看，衡量容災系統有兩個主要指標：RPO（Recovery Point Object）和RTO（Recovery Time Object），其中RPO代表了當災難發生時允許丟失的數據量；而RTO則代表了系統恢復的時間。

（三）容災不僅是技術

容災是一個工程，而不僅僅是技術。目前很多客戶還停留在對容災技術的關注上，而對容災的流程、規范及其具體措施還不太清楚。也從不對容災方案的可行性進行評估，認為只要建立了容災方案即可高枕無憂，其實這具有很大風險的。特別是在一些中小企業中，認為自己的企業為了數據備份和容災，整年花費了大量的人力和財力，而結果幾年下來根本就沒有發生任何大的災難，于是放松了警惕。可一旦發生了災難時，后悔晚矣！這一點國外的跨國公司就做得非常好，盡管幾年下來的確未出現大的災難，備份了那么磁帶，幾乎沒有派上任何用場，但仍一如既往、非常認真地做好每一步，并且基本上每月都有對現行容災方案的可行性進行評估，進行實地演練。

參考文獻

篇(7)

關鍵詞：計算機；云時代；網絡；簡史

中圖分類號：TP3-05 文獻標識碼：A DoI: 10.3969/j.issn.1003-6970.2012.05.028

A Discussion on "Cloud Computing"

Jao Duo-qin

(Lanzhou Resources and Environment Voc-Tech College, Lanzou 730020, China)

【Abstract】Today is the era of new things are emerging. Did not know what the network, with great difficulty, it is also known as cloud. I start from the development of computers, covering the development of networks and cloud technology, and strive to Deep elaborate computer into the cloud era process.

【Key words】Computer; The cloud era; Network; A Brief History

0 引 言

1946年，第一臺計算機發明，將人們從繁瑣的數據計算中解脫出來，1969年，互聯網問世，使得計算機的功能進一步強大。而到了如今一個屬于網絡的新名詞“云”已經走進了我們的生活，什么云計算、云存儲、云備份之類。那么云究竟是什么，它是怎么發展起來的呢？

1 計算機發展簡史

網絡是建立在多臺計算機互聯的基礎之上的，那么在談及網絡之前，讓我們先來簡單了解一下計算機的發展簡史。世界上第一臺計算機ENIAC始于1946年，其雛形是電動計算器。計算機的發明最初用于軍事，主要是用來計算彈道。這是最初的計算機，它需要占三間房的面積。到了1956年，隨著晶體管的問世，第二代計算機誕生了，計算速度也大大提高，占地面積也縮小了。3年后，集成電路得以使用，隨即出現了第三代計算機。隨后大規模、超大規模集成電路廣泛應用，計算機也逐步向前發展，速度越來越快，體積越來越小，直到今天我們看到各種形式的計算機，比如臺式機、平板、筆記本電腦等。在計算機的發展歷史上有一個人是不能忽視的，他就是馮·諾依曼，是他設計了計算機并提出了計算機的計算架構：輸入、處理、輸出，直到今天再復雜的計算機也是秉承這一工作流程，馮·諾依曼也因此被稱為計算機之父。計算機主要由硬件和軟件兩大部分構成。硬件即計算機當中實際存在的部件，軟件是眾多程序的集合，是讓計算機能夠發揮實際效用的指令與代碼的表現形式，正是因為有了軟件的配合，計算機的強大功能才得以充分的發揮。計算機上可以運行眾多的軟件，它具有運算速度快、計算精確度高、有邏輯判斷能力、有自動控制能力的特點。計算機在規模上主要經歷了大型、小型機、微型機這樣三個發展階段。

2 聯網發展簡史

在計算機發明后的23年，也就是1969年，原來每臺計算機只能單獨處理數據而不能協作處理數據的不足已經不能滿足人們的需要了，特別是為了軍事用途而發明計算機的美國軍方。于是美國軍方就將加利福尼亞大學及其洛杉磯分校、斯坦福大學研究學院、猶他州大學的四臺主要計算機連接起來，這次連接是在當年的12月進行的。到了1970年的6月，麻省理工學院、哈佛大學、加州對達莫尼卡系統發展公司相繼加入。又到了1972年的1月，斯坦福大學、麻省理工學院的林肯實驗室、卡內基梅隆大學以及CaseWesternResverve加入，緊接著國家航空和宇宙航行局、Mitre、Burroughs、蘭德公司和伊利諾利州大學也加入了進來。再到了1983年時，美國國防部將這些由計算機連接起來組成的網絡分為軍網和民網，爾后逐漸擴大成為今天的互聯網，并且吸引了越來越多的公司加入。

互聯網包括因特網、萬維網。互聯網、因特網、萬維網三者的關系是萬維網是因特網的分支，因特網是互聯網的分支，凡是能彼此通信的設備組成的網絡就是互聯網。

有了互聯網，我們可以聊天、玩游戲、查閱東西等。 還可以用來進行廣告宣傳、購物，總之互聯網給我們的生活帶來了很大的方便，互聯網亦可以幫助我們的工作和學習。

3 從網到云的蛻變

互聯網的功能是強大的，其涵義也不斷在擴大。網絡本身是虛擬的，但是網絡上發生的一切卻是事實的。隨著互聯網越來越完善，越來越龐大，人們再不能滿足互聯網只實現一些簡單的應用，他們要讓互聯網爆發，從而完成更多先前所不能完成的事情。而隨著網絡不斷的強大，它也被賦予了一個生動的名字：云，天空中飄浮著不止一塊云，而網絡當然也不止一個，所有的網絡連接起來，就如同云一樣，云也因此成為了網絡的代名詞，是對網絡的美稱，是種比喻。

3.1 網絡云的應用

網絡云的主要應用領域就是云計算，云計算是網格計算、分布式計算、并行計算、效用計算等技術與網絡技術的融合。它是基于互聯網的相關服務的增加、使用和交付模式，通常涉及通過互聯網來提供動態易擴展且經常是虛擬化的資源[1-3]。云計算有廣義與狹義之分。廣義的云計算是指服務的交付和使用模式，指通過網絡以按需、易擴展的方式獲得所需服務；狹義的云計算[1-10]是指通過網絡獲得所需資源，它是以IT為基礎的，有按需、易擴展的特點。云計算通過使計算分布在大量的分布式計算機上，而非本地計算機或遠程服務器中[4，10]，其可以提供基礎設施即服務、平臺即服務、軟件即服務。

3.2 云計算的應用領域

云計算的應用領域主要有云存儲、云備份、云安全。

首先來看一下云存儲。云存儲是云計算的分支，其通過集群應用、網絡技術或分布式文件系統等形式，將網絡中不同類型的存儲設備集合起來協同工作，以對外提供數據存儲和業務訪問功能。云存儲的實質是一個以數據存儲[4-5，7-9，11-13]和管理為核心的云計算系統，只要云計算系統運算及處理的是大量的數據存儲和管理時，云計算系統中就少不了要配置大量的存儲設備，這時云存儲也可被稱作云存儲系統。一個完整的云存儲[11-12]系統由存儲層、基礎管理層、應用接口層、訪問層這樣四部分構成，用戶通過訪問層實現對云存儲相應功能的使用。云存儲要得以實現，要依賴于寬帶網絡的發展，WEB2.0技術，應用存儲的發展，集群技術、網絡技術和分布式文件系統[9]，CDN內容分發、P2P技術、數據壓縮技術，存儲虛擬化技術、存儲網絡化管理技術等等這些配套領域的發展。網絡硬盤，就是云存儲的一個小范圍應用。

其次來看一下云備份。云備份是云計算的分支，是指通過集群應用、網格技術或分布式文件系統等功能，將網絡中大量各種不同類型的存儲設備通過應用軟件集合起來協同工作，共同對外提供數據存儲備份和業務訪問的功能服務。要想實現云備份[4-5，7-9，11-13]，先要整合硬件，即對服務器進行統一管理，然后要有一個堅實的底層支持。云備份側重于備份的過程，也是數據防災的一個重要組成部分，被廣泛應用于企業及有需要的個人用戶之中。

最后來看一下云安全。對于計算機及網絡來講，說到安全大家所能想到的就是密碼、病毒、木馬、惡意軟件等等這些東西，不錯，這些都是電腦安全領域的范疇[14]。但是這里將要談到的云安全不僅包括對這些常規安全的處理，更包括更廣泛、更深層的電腦及網絡安全領域。先來看一下云安全究竟是什么。云安全亦是云計算技術的一項重要運用，其同云存儲、云備份一樣，是云計算的分支[15]，它已經在反病毒軟件中取得了廣泛的應用，并且卓有成效，反病毒軟件在與病毒的技術競爭中因為云安全的介入而贏得了先機。云安全通過網狀客戶端對運行于網絡之上的軟件進行行為監測，發現有病毒、木馬、惡意程序后，傳送到服務端進行分析和處理，爾后把解決方案回傳到每一個客戶端[7]。云安全就是借全網之力來抵御病毒、木馬、惡意軟件，是一個大網絡版的殺毒軟件。云安全融合了并行處理、網格計算、未知病毒行為判斷等興技術和概念。云安全讓用戶感受最深的[7]就是在線殺毒、未知病毒分析及對將病毒庫由本地放到服務器，這樣大大降低了本地機器的負擔，提高了運行效率。云安全目前已被各大安全公司廣泛使用，從而使得殺毒軟件的功能進一步強大，反病毒的能力越來越強。

4 結 語

從計算機到網絡再到云，幾十年彈指一揮間。誰也不會想到當初只是美國軍方用于計算彈道的計算機以及后來同樣為了軍事用途而建立起來的互聯網會在幾十年后的今天如同當看電的發現及燈泡的發明一樣對世界、對人們起著舉足輕重的作用。歷史見證了計算機及互聯網的發展，人們也賦予了互聯網以云的生動稱呼。科學無止境，計算機進入了云時代，但這并不是終點，計算機技術、網絡技術，云技術還將不斷向前發展。

參考文獻

[1] 于巧稚.CEO需要了解的云計算[J].中國建設信息，2012，（06）.

[2] 董日波.基于云計算的高校信息化建設[J].電腦編程技巧與維護，2012，（8）.

[3] 邦慧.云計算在新一代信息技術產業中不是浮云[J].衛星電視與寬帶多媒體，2012，（9）.

[4] 初穎.基于云計算架構的移動ADC業務應用研究[D].東北財經大學碩士論文，2010.12.01.

[5] 朱勇.淺談云計算與圖書館數據中心[J].科技情報開發與經濟，2010，（24）.

[6] 任宇寧.云計算時代的存儲技術——云存儲[J].科技傳播，2012，（3）.

[7] 葛曉濱.全球信息化背景下的電子商務發展動態研究[J].計算機與信息技術，2012，（01）.

[8] 張志成.中小學數字化校園應用集成平臺研究及其應用[D].重慶大學碩士論文，2011.05.01.

[9] 張迪，霍妍.云計算技術在醫院信息化中的應用[J].信息技術，2011，（05）.

[10] 曹沁宇. 淺談云計算技術在客服系統中的應用[C].2011全國無線及移動通信學術大會論文集，2011.

[11] 茍彥.存儲區域網絡在聯機事務處理下的性能優化及應用[D].重慶大學碩士論文，2011.05.01.

[12] saas_saas模式_金蝶友商網[DB/0L].youshang

[13] 樂靜雯.計算機簡史[J].科學技術周刊，2009.10.