混合雲帳號整合、檔案權限管理與同步系統之研究 - 政大學術集成

全文

(1)國立政治大學資訊管理學系. 碩士學位論文指導教授：姜國輝博士、季延平博士. 立. 政治大. 學. ‧ 國. 混合雲帳號整合、檔案權限管理與同步系統之研究. ‧. A Research into Account Integration, Authorization. y. Nat. n. al. er. io. sit. and Content Synchronization of Hybrid Cloud. Ch. engchi. i n U. v. 研究生：丁柏元中華民國一○四年七月.

(2) 致謝研究所就學期間，首先要感謝姜國輝老師與季延平老師不遺餘力且耐心的指導，在研究和學習上都給予許多的幫助，使我在這兩年中受益匪淺。本論文能順利完成另外亦得感謝口試委員劉文卿老師及黃勝雄學長，對本論文提出許多寶貴的建議，使本論文能夠更加的完整充實。再來要感謝一起與我成長的碩士班同學、學長姐和學弟妹們，尤其是實驗室的夥伴們，大家總是互相幫忙、彼此扶持，克服種種難關，這段時間雖然過得艱. 政治大最後要感謝家人和女朋友，一路上你們在背後的默默支持，是我前進的動力，立. 辛但是很愉快，謝謝你們。. 讓我能夠順利完成學業。. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. Ch. engchi. i. i n U. v.

(3) 摘要隨著網際網路的蓬勃發展、雲端運算的興起，各種公有雲端服務林立，企業組織擁有更多不同的選擇與更經濟的解決方案，因此也願意投入更多花費在公有雲上。其中，最重要的一項服務為檔案同步與分享服務(File Synchronization and Sharing, FSS)，其可為企業組織帶來生產力，但在無法完全信任公有雲端服務的情況下，在檔案管理及服務上勢必會採用混合雲部署，私有雲端環境用來處理敏感度較高的資料而敏感度較低的檔案及文件才會採用公有雲端服務。本研究將探討在混合雲環境下會遇到的使用者多重帳號及身分，以及檔案一. 政治大. 致性的問題。我們提出一套整合不同雲端平台帳號的架構和方法，在檔案同步上，. 立. 設計出三次同步訊息交換和兩階段同步的機制，並且架構出一個入口網站(Portal). ‧ 國. 學. 服務，根據以上設計架構，實作出一個在混合雲環境，跨本地端、公有雲與私有雲的雲端帳號整合，檔案權限管理與同步之系統，最終可以解決在混合雲環境，. ‧. 不同雲端平台多重帳號的困擾，並可以維持不同裝置和雲端之間檔案資料和權限. y. Nat. sit. 一致性。本研究最後針對實作出的系統之三大功能模組進行測試，驗證本系統各. n. al. er. io. 元件模組的正確性和穩定性，測試結果都是通過的；也針對公、私有雲端，測試. i n U. v. 檔案同步時間，衡量各種大小檔案同步所需要花費的時間，驗證本系統的效能和實用性。. Ch. engchi. 關鍵字：混合雲、檔案同步服務、雲端儲存服務、檔案權限管理、異地備援. ii.

(4) Abstract As rapid growth of cloud computing and Internet, there are variety public cloud service providers on the market, and enterprises will have more choices and economical IT solutions, therefore, they are willing to spend more on public cloud. Although, the most significant of cloud-based productivity services is file synchronization and sharing, enterprises cannot fully trust public cloud, they will deploy file management system with hybrid cloud which they store less sensitive data on public cloud and highly sensitive data on private cloud.. 政治大 problems regarding too many 立 online accounts and synchronize data and permissions. This study aim to design a system on hybrid cloud deployment that can solve the. ‧ 國. 學. between different devices and cloud to maintain consistency. We propose a method to integrate accounts on different cloud and design a mechanize of file synchronization. ‧. which contains three steps messages flows and two stages synchronization to. sit. y. Nat. implement the system, otherwise, we also create a portal service.. n. al. er. io. Last but not least, we test three main modules of the system to verify correctness. i n U. v. and stability and the results are all pass. Also, we measure the synchronization time of. Ch. engchi. files with different size to verify effectiveness and practicality.. Keywords：Hybrid Cloud、File Synchronization Service、Cloud Storage Service、 File Permissions Management、Offsite Backup. iii.

(5) 目錄致謝................................................................................................................................. i 摘要................................................................................................................................ii Abstract ........................................................................................................................ iii 圖目錄..........................................................................................................................vii 表目錄........................................................................................................................... ix 第一章、緒論............................................................................................................ 1 1、. 研究背景........................................................................................................ 1. 2、. 研究動機........................................................................................................ 2. 3、. 研究目的........................................................................................................ 3. 4、. 研究流程........................................................................................................ 4. 立. 政治大. ‧ 國. 學. 第二章、文獻探討.................................................................................................... 5 1、. 雲端運算及其服務........................................................................................ 5. ‧. 1.1 雲端運算的服務模式.................................................................................... 5. Nat. sit. y. 1.2 雲端運算的部署方式.................................................................................... 6. n. al. er. io. 1.3 現有之雲端運算技術與服務........................................................................ 7. i n U. v. 2、. OpenID ......................................................................................................... 11. 3、. 雲端儲存技術及其發展.............................................................................. 12. Ch. engchi. 3.1 雲端儲存發展趨勢...................................................................................... 12 3.2 軟體定義儲存.............................................................................................. 14 3.3 OpenStack Swift .......................................................................................... 16 3.4 雲端資料管理介面...................................................................................... 20 4、. 檔案同步服務.............................................................................................. 23. 4.1 檔案同步服務模型...................................................................................... 23 4.2 檔案同步機制.............................................................................................. 24 4.3 企業檔案同步與分享服務.......................................................................... 25 第三章、系統設計與架構...................................................................................... 27 iv.

(6) 1、. 系統概述...................................................................................................... 27. 2、. 系統架構...................................................................................................... 28. 2.1 系統元件說明.............................................................................................. 28 3、. 混合雲帳號整合.......................................................................................... 31. 3.1 單一驗證介面.............................................................................................. 31 3.2 階段式帳號連結.......................................................................................... 32 3.3 雲端帳號對應.............................................................................................. 33 4、. 檔案與資料夾同步...................................................................................... 35. 4.1 檔案系統監控模組...................................................................................... 35. 政治大. 4.2 同步機制設計.............................................................................................. 36. 立. 4.3 雲端檔案與資料夾異動偵測...................................................................... 37. ‧ 國. 學. 4.4 檔案清單一致性.......................................................................................... 39 4.5 檔案與資料夾同步 API .............................................................................. 41. ‧. 5、. 檔案權限管理.............................................................................................. 42. sit. y. Nat. 5.1 權限與功能對應.......................................................................................... 42. io. er. 5.2 權限管理平台.............................................................................................. 42 第四章、系統實作與測試...................................................................................... 43. al. n. v i n Ch 系統部署環境.............................................................................................. 43 engchi U. 1、 2、. 系統實作...................................................................................................... 44. 2.1 混合雲帳號整合.......................................................................................... 44 2.2 檔案系統監控.............................................................................................. 46 2.3 同步訊息交換.............................................................................................. 47 2.4 檔案與資料夾同步...................................................................................... 48 2.5 檔案權限管理.............................................................................................. 53 3、. 系統操作範例.............................................................................................. 54. 3.1 使用者登入系統.......................................................................................... 54 3.2 同步檔案與資料夾...................................................................................... 55 v.

(7) 3.3 管理檔案權限.............................................................................................. 58 4、. 系統測試...................................................................................................... 59. 4.1 測試範圍...................................................................................................... 59 4.2 測試接受準則.............................................................................................. 59 4.3 測試環境...................................................................................................... 60 4.4 測試案例...................................................................................................... 62 4.5 測試結果與分析.......................................................................................... 65 第五章、研究結論與建議...................................................................................... 68 1、. 結論.............................................................................................................. 68. 2、. 研究貢獻...................................................................................................... 69. 3、. 未來研究建議.............................................................................................. 70. 立. 政治大. ‧. ‧ 國. 學. 參考文獻...................................................................................................................... 71. n. er. io. sit. y. Nat. al. Ch. engchi. vi. i n U. v.

(8) 圖目錄圖一：全球公有雲端服務花費(IDC, 2014).......................................................... 1 圖二：研究流程圖(本研究整理) ......................................................................... 4 圖三：雲端運算架構(引用自 NIST)..................................................................... 5 圖四：HDFS 架構圖(引用自 Hadoop 官方網站)............................................... 10 圖五：OpenID 運作流程(引用自 OpenID Foundation) ..................................... 11 圖六：基於雲端的儲存演進(引用自 Tenaja Group).......................................... 13 圖七：儲存節點(引用自 SwiftStack 官方網站) ................................................. 17. 政治大圖九：Cloud Storage Reference 立 Model(引用自 CDMI v1.1.1) .......................... 21. 圖八：儲存節點、硬碟和 Partition 三者關係(引用自 SwiftStack 官方網站) . 19. ‧ 國. 學. 圖十：兩種檔案同步服務的模型(Xianqiang, Bao, et al., 2011) ........................ 23 圖十一：SyncViews 詳細同步流程(Xianqiang, Bao, et al., 2011) ..................... 24. ‧. 圖十二：使用案例圖 ........................................................................................... 27. sit. y. Nat. 圖十三：系統部署圖 ........................................................................................... 28. al. er. io. 圖十四：單一驗證介面元件圖 ........................................................................... 31. v. n. 圖十五：帳號驗證順序圖 ................................................................................... 32. Ch. engchi. i n U. 圖十六：SQLite 帳號對應類別圖....................................................................... 33 圖十七：MongoDB 帳號對應 User Collection 的 JSON 結構 .......................... 34 圖十八：三次同步訊息溝通順序圖 ................................................................... 36 圖十九：兩階段同步順序圖 ............................................................................... 37 圖二十：客戶端應用程式更新本地端順序圖 ................................................... 38 圖二十一：客戶端應用程式檢查雲端儲存順序圖 ........................................... 39 圖二十二：MongoDB 檔案清單 Files Collection 的 JSON 結構 ...................... 40 圖二十三：系統部署環境圖 ............................................................................... 43 圖二十四：系統同步示意圖 ............................................................................... 49 vii.

(9) 圖二十五：入口網站登入畫面 ........................................................................... 54 圖二十六：本地端上客戶端應用程式登入畫面 ............................................... 54 圖二十七：入口網站檔案與資料夾同步首頁 ................................................... 55 圖二十八：本地端上客戶端應用程式功能選單 ............................................... 55 圖二十九：Windows 客戶端監控資料夾 ............................................................ 56 圖三十：Linux 客戶端監控資料夾 .................................................................... 56 圖三十一：入口網站檔案上傳畫面 ................................................................... 57 圖三十二：入口網站檔案同步畫面 ................................................................... 57. 政治大圖三十四：公開檔案列表畫面 ........................................................................... 58 立. 圖三十三：取得檔案存取網址畫面 ................................................................... 58. 圖三十五：本地端同步到伺服器端花費時間 ................................................... 65. ‧ 國. 學. 圖三十六：伺服器端同步新增、修改到雲端花費時間 ................................... 66. ‧. 圖三十七：伺服器端同步更名到雲端花費時間 ............................................... 67. n. al. er. io. sit. y. Nat. 圖三十八：伺服器端同步刪除到雲端花費時間 ............................................... 67. Ch. engchi. viii. i n U. v.

(10) 表目錄表一：軟體定義儲存和傳統儲存陣列差異(本研究整理) ............................... 14 表二：CDMI 物件 HTTP 操作(資料來源：CDMI v1.1.1) ............................... 21 表三：CDMI 容器 HTTP 操作(資料來源：CDMI v1.1.1) ............................... 22 表四：客戶端應用程式驗證判斷 ....................................................................... 31 表五：檔案系統監控事件 ................................................................................... 35 表六：檔案與資料夾同步 API 介面 ................................................................... 41 表七：檔案權限和操作功能對應表 ................................................................... 42. 政治大表九：雲端服務套件與說明立 ............................................................................... 51 表八：RabbitMQ 客戶端實作參數 ...................................................................... 47. ‧ 國. 學. 表十：伺服器端硬體規格表 ............................................................................... 60 表十一：本地端硬體規格表 ............................................................................... 60. ‧. 表十二：伺服器端軟體規格表 ........................................................................... 61. sit. y. Nat. 表十三：本地端作業系統規格表 ....................................................................... 61. al. er. io. 表十四：測試資料大小和類型 ........................................................................... 61. v. n. 表十五：混合雲帳號整合測試案例 ................................................................... 62. Ch. engchi. i n U. 表十六：檔案同步測試案例 ............................................................................... 63 表十七：檔案權限管理測試案例 ....................................................................... 64 表十八：測試案例結果 ....................................................................................... 65. ix.

(11) 第一章、. 緒論. 1、研究背景雲端運算的發展為企業的資訊處理帶來更多不同的選擇與更經濟的方案，而雲端運算可分為公有雲端服務與私有雲端服務兩大範疇。根據國際數據資訊 IDC (2014)的研究指出全球公有雲端服務的花費在 2014 年已達到 566 億美元，並預期會在 2018 年達到 1270 億美元，這表示其五年的年複合成長率為 22.8%，將是其餘 IT 市場成長率的 6 倍，而 SaaS 將在未來繼續佔據公有雲服務主要花. 政治大軟體層面的。在未來公有雲端服務會被企業更廣泛使用，然而在使用公有雲端服立. 費，其在 2014 年佔據 70%(圖一)，這很大程度是因為客戶在雲端服務需求多是. ‧. ‧ 國. 學. 務所可能會遭遇的問題與企業較為相關，尤其是在資訊安全和服務可靠性上。. n. er. io. sit. y. Nat. al. Ch. engchi. i n U. v. 圖一：全球公有雲端服務花費(IDC, 2014) 隨著公有雲端服務的發展，越來越多企業組織採用了不同的雲端解決方案，在眾多公有雲端服務類型中最重要的一類服務則是檔案同步與分享服務(IDC, 2014)，而企業要使用公有雲檔案同步與分享服務，不論是想做檔案資料異地備援或是想要更快速方便取得應用，隨時隨地透過手機可以進行存取，在不能完全信任此類 SaaS 的公有雲端服務的情況下，企業組織在其檔案管理及服務上勢必會有內部私有雲端環境，用來處理敏感度較高的資料，而敏感度較低的檔案及文 1.

(12) 件才會採用公有雲端服務，此種私有雲端環境和公有雲端環境並行的模式為混合雲環境。IDC FutureScape 報告預測在 2016 年以前將會有超過 65%的企業 IT 組織致力於發展混合雲的技術，而國際研調機構 Gartner (2013)報告則指出到了 2017 年底將會有高達 50%的企業採用混合雲的架構。. 2、研究動機從不同的研究報告中可以看到，企業組織在未來勢必會需要採用混合雲架構，然而使用於混合雲環境下使用檔案同步與分享服務可能為企業帶來生產力但也可能為企業的檔案管理帶來混亂與危機和帳號管理帶來困難。. 政治大於企業內部私有雲檔案資料和公有雲檔案資料不一致的情況，造成認知錯亂與失立檔案管理混亂主要來自兩方面:「資訊混亂」與「管理風險」。資訊混亂來自. ‧ 國. 學. 序，會產生資料一致性的問題。管理風險來自於企業內部私有雲檔案權限和公有雲檔案權限之間缺乏一致性的對應關係，使企業擔憂自己的數位資產在公有雲端. ‧. 上曝露在非預期的閱讀與編輯的風險。帳號管理困難則主要是因為當企業採用越. sit. y. Nat. 來越多雲端服務時，相對應的使用者帳號也會隨之增加，對用戶而言必須記來自. al. er. io. 於多個不同雲端平台上的帳號密碼，並且需要管理不同雲端平台上的檔案資料。. v. n. 本研究希冀能夠解決企業在使用檔案同步與分享服務於混合雲環境下運作. Ch. engchi. i n U. 時，可能發生的三種運作模式，備份雲端資料、更新雲端資料、同步資料權限所產生的資料一致性與權限一致性問題(翁雋傑, 2012)以及使用者在多個雲端平台擁有多個帳號，和其管理上的困難，並同時能提供動態的檔案自動化備援功能。為此，本研究實作出一個跨本地端、私有雲與公有雲的雲端帳號整合和檔案權限管理與同步系統。透過實作的系統，讓使用者能夠彈性的整合多個雲端平台帳號，並便利的透過單一介面來同步和管理不同雲端上的檔案資料和權限，系統可以確保每一份同步到公有雲端的檔案也能夠在企業內部私有雲環境上有相對應的檔案備份。. 2.

(13) 3、研究目的有別於私有雲和公有雲的部署模式，本研究所實作出的混合雲帳號整合、檔案權限管理與同步系統主要針對企業研究混合雲的部署方式及其應用，並且能夠解決企業在使用公有雲檔案同步與分享服務於混合雲部署方式下會發生的問題。本研究將針對以下三個主題進行詳細的分析與探討： (1) 帳號整合：為了解決企業內部帳號和雲端帳號過多的問題，系統能讓使用者手動且有選擇性的去連結多個公、私有雲端平台帳號，並將連結過的帳號進行整合，來完成公、私有雲帳號的對應。而根據此對應，當使用者使用任意. 政治大台上的資源，確保同一位使用者不同雲端之間的互通性。立. 已連結的雲端帳號來登入系統，都將可以存取其他在系統上已連結之雲端平. ‧ 國. 學. (2) 檔案一致性：分為資料一致性和權限一致性。在進行雲端資料備份與更新操作時，系統要能夠確保本地端、公有雲端檔案和私有雲端檔案資料的一致性。. ‧. 而在資料權限同步時，系統要能確保在公有雲端平台上檔案和私有雲內部檔. sit. y. Nat. 案對於企業內部身分和外部雲端之不同使用者身分的檔案存取權限的一致. al. er. io. 性，並且允許檔案擁有者進行檔案權限控管。. v. n. (3) 雲端自動化備援：系統在同步檔案到公、私有雲端時，同時也能夠動態的自. Ch. engchi. i n U. 動同步一份相同檔案到私有雲內部的環境上，作為一個備份。並且要能夠確保使用者對於檔案的每一種操作，例如，新增、刪除、修改、更名，也都能夠自動的同步到對應的備援檔案。. 3.

(14) 4、研究流程本研究詳細流程主要分成以下階段。. 立. 政治大. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. Ch. engchi. i n U. v. 圖二：研究流程圖(本研究整理). 4.

(15) 第二章、. 文獻探討. 1、雲端運算及其服務雲端運算是一種概念模式，依照使用者的需求透過網路去存取資源(如網路、伺服器、儲存、應用程式、服務)，可以用最少的管理而達到快速的配置與發佈 (NIST, 2011)，美國國家標準與技術研究院提出的定義中也進一步的說明對於雲端運算的五項重大特徵、三類服務模式、四種部署方式，如圖三，以下將針對雲端運算不同的部署方式和服務模式及其應用進行探討。. 政治大. 立. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. Ch. engchi. i n U. v. 圖三：雲端運算架構(引用自 NIST). 1.1. 雲端運算的服務模式. 以服務模式來進行分類，雲端運算包含三個層次之服務：軟體即服務 (Software as a Service, SaaS)、平台即服務(Platform as a Service, PaaS)，以及基礎設施即服務(Infrastructure as a Service, IaaS)，此三種層次之服務的運作敘述如下。. ( 1 ). 軟體即服務(SaaS) 服務供應商所提供的服務為建置在雲端基礎設施上的軟體或應用，而且該軟體或應用提供有使用者介面可以讓用戶從不同客戶端裝置去使用，例如：瀏覽器， 5.

(16) 甚至該服務可能也會提供程式 API 介面，允許開發者程式介接。由於服務是建置在提供商的雲端基礎設施之上，消費者不需要去管理或控制相關硬體環境，只需要處理限於自身的服務相關配置設定。. ( 2 ). 平台即服務(PaaS) 提供雲端運算平台，允許用戶根據提供商所提供的 SDK 或工具去開發及客製化自己的應用程式，並部署到該服務平台之上，用戶不需要去管理或控制底層雲端基礎設施。而服務提供商也提供應用程式於平台上使用之硬體相關資源使用率，並提供維運管理功能幫使用者進行監控及計費。. 政治大. ( 3 ). 基礎設施即服務(IaaS). 立. 服務提供商以虛擬化的技術提供用戶運算資源、儲存資源以及網路資源，並. ‧ 國. 學. 允許用戶可以部署和執行任意軟體，例如：作業系統、應用程式，而用戶可以動態分配所使用的運算資源。IaaS 服務的雲端基礎設施的底層架構和實體伺服器則. ‧. 由服務提供商來負責管理及維護。. y. Nat. io. sit. 雲端運算的部署方式. er. 1.2. 雲端運算依據其部署方式可以分為四種，分別是私有雲(Private Cloud)、社群. al. n. v i n 雲(Community Cloud)、公有雲(Public Cloud)，此四種部署 C h Cloud)及混合雲(Hybrid engchi U 方式介紹如下。. ( 1 ). 私有雲(Private Cloud) 建置雲端基礎設施專門為企業組織使用，可能是由該組織本身、第三方廠商或者兩者共同在企業組織內部(On premise)或是外部(Off premise)進行部署。企業組織建置私有雲環境而不採用公有雲的考量通常在於資料安全性和服務可靠性，而因為私有雲的網路環境是使用企業內部網路(Intranet)以此來和外部網路環境區隔，並且使用者多是具有企業組織內部身分的，安全性較能確保，另外私有雲的部署方式企業組織也較能掌控雲端基礎設施架構，並能改善其服務可靠性和彈 6.

(17) 性。. ( 2 ). 社群雲(Community Cloud) 為共同專注在特定議題，例如：任務、安全需求、政策和合規性考量，的數個特定組織所建置的雲端基礎設施，其可能是由社群內一個或多個組織來共同管理，或是由第三方廠商來進行管理。. ( 3 ). 公有雲(Public Cloud) 雲端基礎設施建置在服務提供商內部並為其所擁有，並且公開提供服務給一般大眾，此服務提供商有可能是商業、學術或政府單位。公有雲端服務一般大多. 政治大. 並非為免費的，是否收費是由各服務提供商自行決定，而計費方式主要是根據所. 立. 使用的服務類型和用量。企業組織可以依據自身需求和考量來使用不同服務供應. ‧ 國. 學. 商所提供的服務，例如：使用 SaaS 模式的檔案同步與分享服務。. ‧. ( 4 ). 混合雲(Hybrid Cloud). y. Nat. 其雲端基礎設施主要是由兩個或兩個以上的雲(私有雲、社群雲或公有雲)所. er. io. sit. 組成並各別獨立存在，但是藉由標準或是專有技術來把不同雲聯繫再一起，使雲之間的資料或是應用是具有可移植性的。企業組織使用混合雲雖然比完全使用公. al. n. v i n 有雲較為安全，而且建置成本比完全使用私有雲較為低，但是其公、私有雲之間 Ch engchi U 的安全控制，部署方式以及整體 IT 架構規劃上卻是更為複雜的。. 1.3. 現有之雲端運算技術與服務. 雲端運算是一種可彈性擴充之 IT 相關能力的運算方式，透過網際網路技術並以服務的形式提供給使用者(Gartner, 2012)，而近年來，隨著雲端運算的興起，雲端服務提供商林立，分別以不同的模式來提供雲端運算服務給使用者，其中目前現行之雲端運算技術和服務中比較常見的有 Google Cloud Platform、Amazon Web Services、Microsoft Azure、Rackspace、Dropbox、Hadoop 以下分別進行介紹。 7.

(18) ( 1 ). Google Cloud Platform Google 雲端平台(Google Cloud Platform)讓使用者可以使用和 Google 一樣的資訊科技來建置自己的服務，其提供一系列的工具與 API，讓開發人員只需要了解這些 API 的用法而不需要知道其內部的複雜邏輯和實際儲存與處理的工作。在 Google 提供的眾多服務之中，較知名服務為 Google App Engine，其是以 PaaS 模式來提供的雲端服務，允許使用者可以使用 Python、Java、PHP 和 Go 快速開發並部署自己的雲端 Web 應用。. ( 2 ). Amazon Web Services. 政治大析、應用程式和部署服務，其中最為知名的服務為 Amazon Elastic Compute Cloud, 立. Amazon Web Services, AWS 提供了一組廣泛的全球運算、儲存、資料庫、分. Amazon EC2，和 Amazon Simple Storage Services, Amazon S3。Amazon EC2 提供. ‧ 國. 學. 使用者不同規格的虛擬機，並且讓使用者可以根據自己的應用需求去動態的調整. ‧. 配置，而 Amazon S3 則提供高度可擴展性的網路儲存空間，允許使用者透過 REST. sit. y. Nat. API 來操作檔案資料。. io. er. ( 3 ). Microsoft Azure. Azure 是 Microsoft 的雲端平台，主要是以 IaaS 和 PaaS 模式來提供整合式服. al. n. v i n 務，其服務項目包含運算、儲存體、資料、網路連線及應用程式。而其服務類型 Ch engchi U 主要包含四項： . 建置基礎設施：在 Azure 上使用和企業組織內部相同的虛擬機器和管理工具。. . 開發現代化應用程式：開發及部署 Android、IOS、Windows 和 Web 的各類型應用程式，並且可依需求來彈性擴充。. . 管理及分析資料：提供 SQL 和 NoSQL 資料服務，並可以使用 HDInsight 建置 Hadoop 叢集來分析資料。. . 管理身分識別與存取：管理使用者帳戶、同步處理內部部署目錄，並提供多因素驗證服務。 8.

(19) ( 4 ). Rackspace Rackspace 是一家提供主機託管服務和雲端運算的供應商，Rackspace 的託管服務產品包括專用主機、雲端伺服器、雲端存儲、網站、電子郵件、Microsoft SharePoint、Microsoft Lync 等，在服務架構上提供專用託管、公有雲、私有雲及混合雲。Rackspace 說他們的服務為 Fanatical Support，強調每天 24 小時全年無休。Rackspace 在 2010 年和 NASA 合作創始了雲端開源平台 OpenStack，在 2012 年宣布自己的雲端平台是建置於 OpenStack 之上。. ( 5 ). Dropbox. 政治大服務給一般大眾，服務所支援的客戶端有 Windows、MAC 和 Linux 桌面版本以立 Dropbox 是一個提供檔案同步與分享的服務，其主要是以 SaaS 模式來提供. 及 Android、IOS、Windows 和 BlackBerry 行動裝置版本。Dropbox 支援恢復歷史. ‧ 國. 學. 紀錄，即使檔案被刪除，也可以從任何一個同步電腦中得以恢復，其版本紀錄使. sit. y. Nat. 要重新上傳完整檔案，以此來節省頻寬和時間。. ‧. 用了差分編碼技術，當用戶的檔案更動之後，只上傳有變更的檔案部分，而不需. io. er. ( 6 ). Hadoop. Hadoop 為 Apache 軟體基金會旗下的一個計劃，其主要是為了開發一套可靠. al. n. v i n 性、延展性並具有分散式運算能力的開源軟體，其子項目包含： Ch engchi U . Hadoop Common：支援其他 Hadoop 子項目的公用類別。. . Hadoop Distributed File System：支援高吞吐量存取應用資料的分散式檔案系統。. . Hadoop YARN：工作排程和叢集資源管理的框架。. . Hadoop MapReduce：以 YARN 為基礎來支援平行處理大型資料的系統。. Hadoop HDFS 是根據 Google 所發表的論文實作而成的，其旨在提供一個具有高度容錯並且能夠部署在廉價的普通硬體上的分散式檔案系統。其能提供高吞吐量的資料存取，非常適合大型資料的應用，圖四為 Hadoop HDFS 架構圖。. 9.

(20) 政治大圖四：HDFS 立架構圖(引用自 Hadoop 官方網站) ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. Ch. engchi. 10. i n U. v.

(21) 2、 OpenID OpenID 允許使用者以現有的帳號來登入多個不同網站，而不需要再額外註冊新的帳號密碼。使用者可以決定和 OpenID 關聯的資料，例如：名字、電子郵件，可以讓登入網站使用，換句話說，使用者可以控制有多少資訊是可以被登入網站存取的。使用 OpenID 可以確保使用者登入的密碼只會給身分提供者(Identity Provider)，而該提供者則確保使用者登入網站的身分，並且不會有其他網站知道登入密碼，所以不必擔心不道德或是不安全的網站威脅你的身分。 OpenID 目前被越來越多網站所使用，目前已經有超過十億允許 OpenID 的. 政治大 Yahoo、Microsoft、AOL、MySpace、Sears、Universal Music Group、France Telecom、立. 帳號和超過 50,000 網站採用 OpenID 登入。眾多大型組織，例如：Google、Facebook、. Novell、Sun、Telecom Italia 和更多，都發行者同意 OpenID。. ‧ 國. 學. OpenID 運作流程如圖五，分為以下五個步驟：. RP(Relying Party)端向 OP(OpenID Provider)端送出驗證請求。. . OP 端驗證使用者並取得授權。. . OP 端回應 ID Token，通常還會有 Access Token。. . RP 端對 UserInfo 端點送出帶有 Access Token 的請求。. . UserInfo 端點回傳該使用者的資料。. ‧. . n. er. io. sit. y. Nat. al. Ch. engchi. i n U. v. 圖五：OpenID 運作流程(引用自 OpenID Foundation). 11.

(22) 3、雲端儲存技術及其發展資料儲存的發展歷史從單一大型主機連接著硬碟，到和大型主機分離且擁有獨立、專有的控制器的儲存系統。隨著時間發展，資料和應用越來越大，根據國際數據公司 IDC (2013)的研究，全球的原始儲存器容量從 2012 年的 2,596 Exabytes (EB)到 2017 年時將升為 7,325 Exabytes (EB)，資料儲存增長速率比以往都還要快，IDC 估計到了 2020 年全球資料儲存量將達到 35,840 Exabytes (EB)。舊的儲存架構無法適應新的應用需求，資料儲存也有了新的發展，以下針對雲端儲存和相關技術進行探討。. 3.1. 雲端儲存發展趨勢. 立. 政治大. 雲端儲存或者是基於雲端的儲存，是從雲端運算概念上延伸和發展出來的一. ‧ 國. 學. 種網路儲存的模式(Wikipedia, 2015;韦小凤, 2013)，其實際資料儲存分布在多台通常是位在不同地點的伺服器上。有資料儲存需求的人或組織向雲端儲存提供商來. ‧. 租賃或購買儲存空間，而提供商需確保儲存資料的可用性和可存取性。. y. Nat. sit. Taneja Group 定義基於雲端的儲存(cloud-based storage)是儲存器在雲端上. n. al. er. io. (storage in the cloud)這個大領域之下的一個類別。儲存器在雲端上涵蓋了傳統的. i n U. v. 託管儲存(hosted storage)，其包含提供從遠端或是在託管的環境下經由 FTP、. Ch. engchi. WebDAV、NFS/CIFS 或是 Block Protocols 來存取。而基於雲端的儲存則是託管儲存技術的演進，其為儲存提供了更複雜的 API、命名空間(namespaces)、檔案或資料的虛擬化和管理工具，圖六顯示基於雲端的儲存演進。. 12.

(23) 立. 政治大. 圖六：基於雲端的儲存演進(引用自 Tenaja Group). ‧ 國. 學. 雲端儲存已經成為未來儲存發展的一種趨勢，但隨著雲端儲存技術的發展，. ‧. 各類搜尋、應用技術和雲端儲存相結合的應用，還須從安全性、可攜性以及資料. io. y. sit. 安全性. er. . Nat. 存取等角度進行改進。. 從雲端運算誕生，安全性一直是企業的首要考慮問題之一。同樣在雲端儲存. al. n. v i n 方面，安全仍是首要考慮的問題。許多用戶對雲端儲存的安球要求甚至高於他們 Ch engchi U. 自己的架構所能提供的安全水平。儘管如此，許多大型、可信賴的雲端儲存提供商建置了比多數企業資料中心更安全的資料中心，提供的雲端儲存具有更少的安全漏洞和更高的安全環節。 . 可攜性一些用戶在託管儲存的時候還要考慮資料的可攜性。一些大型服務提供商所. 提供的解決方案保證其資料可攜性媲美最好的傳統本地儲存。有的雲端儲存結合了強大的可攜功能，可以將整個資料組傳送到你所選擇的任何媒介，甚至是專門的儲存設備。 . 性能和可用性 13.

(24) 過去一些託管儲存和遠端儲存總是存在著延遲時間過長的問題。同樣的，網際網路本身的特性就嚴重威脅服務的可用性。隨著雲端儲存技術的不斷發展，各廠商將持續努力實現容量最佳化和廣域網路(WAN)最佳化，已盡量減少資料傳輸的延遲性。 . 資料存取現有對雲端儲存的疑慮還在於：如果執行大規模資料請求或是資料復原操作，. 那麼雲端儲存是否可以提供足夠的可存取性。在未來的技術條件之下，現有的廠商可以加大量資料傳輸到任類型的媒介，可將資料直接傳送給企業，且速度之快. 政治大雲端儲存不只是託管儲存更是一種服務，IBM (2009)提出資料儲存即服務立. 相當於複製、貼上操作。. (data-Storage as a Service)，並以 Amazon S3、Nirvanix SDN 為例。現今，各類儲. ‧ 國. 學. 存即服務(Storage as a Service, StaaS)提供商林立。而在使用上，使用者不論何時. ‧. 何地，只要透過 Web 介面的應用程式，即可以透過網際網路存取資料，而有的. y er. io. 3.2. sit. 進行協同工作。. Nat. 雲端儲存服務更允許你授權給其他使用者存取資料，讓個人的資料變成可以團隊. 軟體定義儲存a. n. iv l C n h eStorage, 軟體定義儲存(Software Defined i U n g c hSDS)是一種資料儲存方式，所有儲. 存相關的控制作業都放置在相對於實體儲存硬體的外部軟體中。這個軟體不是作為存放設備硬體的一部份，而是在一個伺服器上或者作為作業系統(OS)或 Hypervisor 的一部分(Wikipedia, 2015;吴迪, 2013)。軟體定義儲存和傳統儲存系統陣列差異，如表一。表一：軟體定義儲存和傳統儲存陣列差異(本研究整理) 軟體定義儲存標準化. 傳統儲存陣列. 儲存控制器功能可以運不同廠商的不同儲存設行在任何類型的伺服器備，有各自獨立的儲存控 14.

(25) 硬體上，且可以放置在任制器，且必須放置於特定何位置。靈活度. 硬體上。. 通常可以透過 REST API 透過命令列介面 (CLIs) 來進行操作。. 可擴充性. 或是 SMI-S API。. 節點可進行擴充，沒有實基於控制器設置，連接的際上數量的限制。. 多租戶. 硬碟數量有限。. 多租戶架構，每個租戶獨為了確保系統的服務品立的工作負載，甚至能自質，很可能每一臺儲存設. 政治大備只能讓特定應用程式來存取。. 動配置儲存。. 可跨越 NAS、SAN、Flash 有限的整合，例如：SAN. ‧ 國. 學. 整合性. 立. 陣列、物件式儲存等不同和 NAS 的整合設備。. sit. y. Nat. 源的統籌使用。. ‧. 的儲存設備，做到儲存資. io. er. 利用軟體定義儲存，將存儲服務從底層的專利硬體中抽象出來，可以提升運營效率，提供透明的資料移轉。由於降低了管理的複雜性，其可讓各種雲端應用. al. n. v i n Ch 更高效運行，並可進行低成本的擴展。IDC i U年所做的對全球範圍軟體定 e n g c於h 2013 義存儲市場的分類調查表明，軟體定義儲存具備以下一些特徵： . 軟體是其中的關鍵。它可在異構的、商品化硬體環境下運行，且可充分利用組織現有的存儲基礎架構。. . 軟體定義儲存可提供全面的存儲服務。. . 軟體定義儲存可對來自不同地點的物理存儲容量，包括內部磁片、快閃記憶體系統和外部存儲系統進行聯邦式管理，並很快可將這種管理擴大到各類雲以及雲物件平台。. . 軟體定義儲存可利用統一的單一 API 進行程式設計，然後通過各類入口網 15.

(26) 站進行管理。軟體定義儲存看起來能夠幫助企業從傳統的儲存基礎設施，轉向一個更加靈活、雲端化且是軟體定義的環境，並可以更有效率地進行管理，一旦正確部署了軟體定義儲存，便可預期獲得以下效益： . 自動選擇內部儲存資源和雲端儲存資源。. . 策略編排的儲存資源可最佳化性能，提高效率。. . 分析導向的軟體定義儲存和資源優化可滿足不可預測的業務需求。. . 使用開放的 API、工具，因此在跨混合雲環境中，可以很容易重複使用儲存。. 政治大 OpenStack 是一個開放原始碼的雲端運算管理平台專案，有幾個主要的元件立. 3.3. OpenStack Swift. 組合起來完成具體工作，而 Swift 則為其中的物件儲存(Object Storage)元件。有. ‧ 國. 學. 別於傳統檔案系統，OpenStack Swift 就像 Amazon S3 一樣，是一個儲存，例如：. ‧. 虛擬機映像檔、照片、email、備份和檔案與其他非結構化資料的分散式儲存系統，. y. Nat. 並提供良好的可擴充性(Scalable)、冗餘性(Redundancy)和牢靠性(Durable)。. er. io. sit. OpenStack Swift 可以安裝在一般的商用硬體上，這表示標準、低成本的伺服器組件可以用來建置儲存系統。藉由 Swift 提供邏輯上的資料管理而不是廠商專. al. n. v i n 有的硬體，可以輕易的彈性部署、擴充儲存系統，這就是軟體定義儲存本質上所 Ch engchi U 定義的。. OpenStack Swift 由八個處理程序(Processes)和服務(Services)組成其架構，分別為：Proxy Server、The Ring、Object Server、Container Server、Account Server、 Replicator、Updaters 和 Auditors，以下將以 Swift 功能面分別探討各元件。. ( 1 ). 伺服器處理程序 Swift 的伺服器處理程序(Server Processes)包含 Proxy、Account、Container 和 Object。當一個節點上單獨執行 Proxy Server，則稱該節點為代理節點(Proxy Node)，而當一個節點上至少執行了 Account、Container 和 Object Server 三者其中一項， 16.

(27) 則稱之為儲存節點(Storage Node)，如圖七所示，儲存節點上還會執行其他服務以維持資料的一致性。. 立. 政治大. ‧ 國. 學. 圖七：儲存節點(引用自 SwiftStack 官方網站). . Proxy Server. ‧. 代理伺服器(Proxy Server)為 Swift 架構中對內的溝通橋梁，且是對外部的客. y. Nat. sit. 戶端溝通的唯一管道，在上面的所有訊息傳遞都是透過標準的 HTTP 動詞，例如：. n. al. er. io. GET、PUT、POST 以及 DELETE。代理伺服器採用 shared-nothing 架構，表示其. i n U. v. 一個部署的代理節點(Proxy Node)都是獨立、自給的，且它可以根據負載需求來. Ch. engchi. 進行擴充，在一個 Swift 叢集之中應該至少要部署兩個代理節點，當其中一個出問題，另一個可以接手。 . Account Server 帳號伺服器(Account Server)提供每一個帳號(Account)的 Metadata 和帳號內. 的容器(Container)列表，其資料存在於 SQLite 資料庫中。 . Container Server 容器伺服器(Container Server)的主要工作為管理其 Metadata 和提供容器內所. 擁有的物件(Object)列表。容器伺服器不知道物件的存放位置，只知道物件所屬的容器，其資料存在於 SQLite 資料庫中。 17.

(28) . Object Server 物件伺服器(Object Server)提供了二進位大型物件(Blob)儲存服務，可以儲存、. 檢索和刪除位於節點硬碟上的物件。物件是使用其包含 Partition 的路徑和操作的時間戳記(Timestamp)在硬碟上存為二進位檔案，時間戳記可以讓物件伺服器儲存該物件的多個版本，並找到最新版本。除此之外，物件的 Metadata 是存放在檔案的延伸屬性(xattrs)，這樣的設計可以確保物件資料和 Metadata 儲存在一起。. ( 2 ). 一致性處理程序 OpenStack Swift 是很牢靠的，主要是因為一致性處理程序(Consistency. 政治大障所引起的錯誤。一致性處理程序主要包含兩個服務 Auditors 和 Replicators，這立. Processes)，其是用來處理故障，並且能夠找到和更正無論是資料損壞或是硬體故. Auditors. ‧. ‧ 國. . 學. 兩個服務會在儲存節點上執行以確保資料整合性和可用性。. 稽核器(Auditors)會在所有儲存節點上背景執行，帳號、容器和物件伺服器皆. sit. y. Nat. 會有相對應的稽核器服務，其會不斷掃瞄所在節點上整個硬碟內儲存資料的完整. Replicators. al. n. . er. io. 性，確保沒有資料損壞。當錯誤發生稽核器會把損壞的資料移動到隔離區。. Ch. engchi. i n U. v. 複寫器(Replicators)會在所有儲存節點(Storage Node)上背景執行，帳號、容器和物件伺服器皆會有相對應的複寫器服務，其會不斷檢查所在節點上的資料和叢集內其他節點上對應的資料，如果其他節點上的資料是比較舊的或是遺失，則複寫器會推送(Push)一份所在節點上的資料過去更新，而如果所在節點上的資料是比較舊或是遺失，則不會從其他節點拉(Pull)一份資料過來。複寫器也處理物件和容器的刪除，物件刪除藉由建立一個 0 位元組的且以.ts 為副檔名的墓碑檔案作為該檔案的最新版本，而複寫器會把該墓碑檔案推送到其他節點也作為此檔案的最新版本，如此該物件就代表被整個系統所刪除。容器刪除則藉由把該容器標記為已刪除，複寫器則會把這個版本推送到其他節點，如此 18.

(29) 該容器就代表被整個系統所刪除。 . Updaters 分為容器更新器(Container Updater)和物件更新器(Object Updater)，容器更新. 器主要工作是確保帳號的容器列表是最新的，除此之外，還會更新存放在帳號的 Metadata，包含物件數量、容器數量和總共使用了多少位元組。物件更新器則是作為一個備援機制，更新容器內的物件清單，該工作主要是由物件伺服器來執行，當失敗時才會由物件更新器來執行確認物件清單並進行更新存放在容器的 Metadata 的物件數量和總共使用的位元組資料。. 政治大 Swift 為了有效的跨叢集來存放資料，並可以快速存取，其資料存放模型如立. ( 3 ). 資料存取. ‧ 國. 學. 圖八，其中一個儲存節點內可能會有很多個硬碟(Disk)，而 Partition 則是目錄的概念，所以每一個硬碟內則會有多個 Partition。. ‧. n. er. io. sit. y. Nat. al. Ch. engchi. i n U. v. 圖八：儲存節點、硬碟和 Partition 三者關係(引用自 SwiftStack 官方網站) 帳號、容器和物件資料是分散存放在多個節點之上，當伺服器處理程序和一致性處理程序需要對資料進行操作時，會利用資料的儲存位置，例如：(/account, /account/container, /account/container/object)向對應的 Account Ring、Container Ring 和 Object Ring 來找到資料所在的位置。 . The Ring Ring 用於記錄儲存實體與物理位置之間的對應(Mapping)關係，並由一致性 19.

(30) 雜湊(Hash)演算法所產生。Ring 存在於叢集內的每一個節點上，Ring 中每一個 Partition 在叢集中都預設有 3 個副本(Replica)，且 Ring 會維護其位置。. 3.4. 雲端資料管理介面. 由於各家雲端儲存提供商的儲存系統標準不一，透過標準化的介面，即便各家系統內部有不同的運作功能和標準，也能透過統一的介面進行溝通。儲存網路產業協會(Storage Networking Industry Association, SNIA)是當前雲端儲存標準的主要推動者，其主要致力於推廣儲存系統統一標準與 API 介面的開發作業。SNIA 在 2010 年 4 月正式發布雲端資料管理介面(Cloud Data Management Interface,. 政治大如圖九所示，該模型顯示了多種可以支援傳統和新的應用程式的雲端資料儲立. CDMI) 1.0。. ‧ 國. 學. 存介面，這些介面都允許依照需求來提供從資源集區(Resource Pool)取出的儲存，而相關的容量則是從儲存服務(Storage Services)提供的儲存容量來取得。資料服. ‧. 務(Data Services)是根據其資料系統的 Metadata 來套用於各個物件上，而這些. sit. y. Nat. Metadata 都是在各個物件的基礎之上或是專為多組由物件組成的容器(Container). al. er. io. 明確說明其資料的需求。其中 CDMI 是定義了應用程式使用新增、抓取、更新、. v. n. 刪除(CRUD)雲端資料的功能介面，其功能還包含了管理用來存放資料的容器。. Ch. engchi. i n U. CDMI 介面也可以讓行政管理應用程式來管理容器、網域(Domain)、安全存取(Security Access)和監控(Monitoring)記帳(Billing)資訊，即使該儲存功能是透過傳統或是專有的協定。. 20.

(31) 立. 政治大. ‧. ‧ 國. 學 y. Nat. er. io. sit. 圖九：Cloud Storage Reference Model(引用自 CDMI v1.1.1) CDMI 是建置於 HTTP 的標準之上，所以允許使用 HTTP 的客戶端和 CDMI. al. n. v i n 伺服器進行溝通。這也使得 CDMI HTTP 為基礎的儲存 C h 的操作是可以和其他以 engchi U 協定，例如：WebDAV、Amazon S3 和 OpenStack Swift，是同時並行的。表二、表三為 CDMI 所規範的 HTTP 操作物件和容器的整理。表二：CDMI 物件 HTTP 操作(資料來源：CDMI v1.1.1) 操作說明. HTTP. URI. 建立資料物件. PUT. <root URI>/<ContainerName>/<DataObjectName>. 建立資料物件. POST. <root URI>/<ContainerName>/. 取得資料物件. GET. <root URI>/<ContainerName>/<DataObjectName>. 更新資料物件. PUT. <root URI>/<ContainerName>/<DataObjectName> 21.

(32) 刪除資料物件. DELETE <root URI>/<ContainerName>/<DataObjectName>. 表三：CDMI 容器 HTTP 操作(資料來源：CDMI v1.1.1) 操作說明. HTTP. URI. 建立容器物. PUT. <root URI>/<ContainerName>/<NewContainerName>/. 件刪除容器物. DELETE <root URI>/<ContainerName>/<TheContainerName>/. 件. 立. 政治大. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. Ch. engchi. 22. i n U. v.

(33) 4、檔案同步服務現代人在日常生活中有越來越多的各類型運算裝置，例如：工作上會使用筆記型電腦、家裡有台桌上型電腦、而身邊則隨時有手機甚至平板。眾多不同的裝置雖然讓我們在生活上管理個人資訊很方便，可是如果要在眾多裝置上去管理特定檔案則是很困難的(Dearman and Pierce, 2008)。. 4.1. 檔案同步服務模型. 由於要在眾多裝置上管理檔案是很困難的，所以對於檔案同步服務(File Synchronization Services, FSS)需求也隨之增加，此類型服務可以透過一個單一的. 政治大. 介面去管理所有裝置上的檔案，並能夠確保在各裝置上的資料版本是一致的。. 立. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. Ch. engchi. i n U. v. 圖十：兩種檔案同步服務的模型(Xianqiang, Bao, et al., 2011) 圖十是(Xianqiang, Bao, et al., 2011)歸納的檔案同步服務的兩種模型，檔案同步服務通常會要使用者在需要進行檔案管理的裝置上安裝客戶端軟體，安裝完成後會需要指定一個檔案同步目錄，而各裝置上的同步目錄都會對應到服務提供商雲端儲存上的同一個空間，當同步目錄內的檔案發生異動(CRUD)操作，客戶端 23.

(34) 軟體會把檔案自動同步到其他裝置上的同步目錄以確保檔案資料一致性。檔案同步服務通常也會提供網頁介面，允許登入的使用者對雲端儲存伺服器進行檔案上傳或下載檔案，而透過網頁進行上傳檔案的操作也會把檔案同步到其他裝置上的同步目錄。. 4.2. 檔案同步機制. SyncViews 為(Xianqiang, Bao, et al., 2011)針對檔案同步服務提出的作法，其在檔案同步運作上分為兩種更新操作(新增、更新、修改、刪除)，其分別為 Local Update、Remote Update 和兩種掃描操作，其分別為 Local Scan、Remote Scan。. 政治大 Update 代表伺服器上同步目錄裡面檔案的更新操作。Local Scan 代表已登入的客立. Local Update 代表使用者在客戶端的同步目錄對檔案進行更新操作；Remote. ‧ 國. 學. 戶端定期會去檢查是否有更新操作；Remote Scan 代表已登入的客戶端會定期去檢查伺服器上的歷史性更新操作，確認是否有 Remote Update。. ‧. n. er. io. sit. y. Nat. al. Ch. engchi. i n U. v. 圖十一：SyncViews 詳細同步流程(Xianqiang, Bao, et al., 2011) 24.

(35) 如圖十一，在 SyncViews 系統中使用者同步目錄內的所有檔案和資料夾的快照被定義為一個 View，而同一位使用者可能會有多個不同裝置，因此也會有著多個 View，例如𝑉𝑖𝑒𝑤ℎ𝑜𝑚𝑒 和𝑉𝑖𝑒𝑤𝑤𝑜𝑟𝑘，這些不同的 View 都會對應到伺服器端的同一個 View，以維持不同裝置間檔案一致性。而 SyncViews 在伺服器端則包含三個元件分別為 control-server、meta-server 和 storage server。其工作分配為 controlserver 主要負責處理從客戶端傳送過來的請求，和把更新操作傳給 meta-server 儲存在 ChangeRecords 資料表以及把檔案儲存在 storage-server，除此之外 metaserver 上還會有存有一份檔案相關資料，即是系統定義的 View，該資料表名為. 政治大企業檔案同步與分享服務立. Snapshot。. 4.3. ‧ 國. 學. 隨著雲端運算各種模式服務的發展，其中雲端檔案同步與分享服務，例如： Dropbox、Google Drive 等也越來越普及，此類型的服務亦被眾多企業組織所採. ‧. 用，並在未來會逐漸的增長(IDC, 2014)，因此國際研調機構 Gartner (2014)也把此. sit. y. Nat. 類服務定名為企業檔案同步與分享(Enterprise File Synchronization and Sharing,. al. er. io. EFSS)。EFSS 市場已漸漸成熟，各服務供應商基本除了檔案同步和分享之外，有. v. n. 可能在移動性、安全性、行政與管理、後端伺服器整合、檔案內容處理、協同合. Ch. engchi. i n U. 作、操作介面簡易性和易用性和雲端儲存這幾個面向提供不同程度的加值服務，以此來做出差異化。 Gartner (2014)歸納出各供應商所提供的 EFSS 服務可以分為三種架構，如下： . Cloud 企業組織的檔案是儲存在服務供應商的雲之上，其可以透過行動裝置進行存. 取和分享。會偏好這種架構的企業組織通常是想以能夠在 IT 控制之下的企業級替代方案取代員工的個人雲端服務，並且同時能夠保留使用者體驗和移動式協同合作。 . On-premises 25.

(36) 遠端存取、同步和分享元件是在企業內部部署，並整合了企業資料儲存庫，而且不再額外進行檔案副本。對於資料儲存有嚴格規範的企業組織會偏好選擇此種架構。 . Hybrid 使用者和裝置的驗證、安全以及搜尋機制是由服務供應商的雲所實作且提供，. 檔案和文件則保留在企業組織原有位置或是儲存在第三方的雲之上。企業組織不需要在其他供應商的雲之上額外建立資料副本，以此來簡化行動裝置用戶經由雲端存取組織資料，會偏好此種混合式架構。. 政治大. 而 EFSS 服務的類型則可以分為兩種，如下： . Destinations. 立. 企業組織購買該產品的主要目的就是為了此產品的檔案同步和分享功能。. ‧ 國. Extensions. 學. . ‧. 某種產品或應用，例如：協同合作、內容管理或儲存，在額外附加上檔案同. n. al. er. io. sit. y. Nat. 步和分享的功能。. Ch. engchi. 26. i n U. v.

(37) 第三章、. 系統設計與架構. 1、系統概述為解決在混合雲環境下，會遇到的帳號整合以及檔案資料一致性和權限的問題，本研究將實作出系統來整合使用者本地端以及公、私有雲端上的帳號、並進行檔案同步與權限管理。使用本系統，使用者可以方便管理自己在多個不同本地端，例如：家用桌上型電腦、公司筆記型電腦，以及私有雲，例如：OpenStack、 Hadoop，和公有雲端服務，例如：Google、Dropbox、Microsoft 和 Amazon 等的. 政治大料的一致性。使用者可以透過統一的入口來管理多個雲端平台上的檔案，並設定立. 檔案資料，並且能夠即時在不同雲端平台和裝置間進行檔案同步，以確保檔案資. 存取權限，進行檔案分享。. ‧ 國. 學. 圖十二為使用案例圖，描述使用者在本系統上將能進行的功能操作。. ‧. n. er. io. sit. y. Nat. al. Ch. engchi. i n U. 圖十二：使用案例圖 27. v.

(38) 2、系統架構本系統架構設計考量了，使用者本地端、私有雲端以及公有雲端提供商的混合雲環境，並可根據該架構來彈性擴充介接的私有雲和公有雲儲存服務，圖十三為本系統之 UML 部署圖，詳細各元件功能描述以下分述。. 政治大. 立. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. Ch. engchi. i n U. v. 圖十三：系統部署圖. 2.1. 系統元件說明. ( 1 ). Client 系統中的客戶端(Client)端為 Linux 和 Windows 桌面應用程式，需要由使用者自行安裝於本地端電腦上，程式啟動時會要求使用者以現有雲端帳號登入而不需要註冊。登入成功後，系統會把相關使用者資料寫進 SQLite 資料庫，並在本地端檔案系統新建一個系統專屬的監控資料夾，裡面會預設有目前已登入的雲端. 28.

(39) 服務資料夾。使用者可以再手動進行連結其他雲端服務，登入成功後同樣會在系統專屬監控資料夾內建立連結的雲端服務資料夾，並啟用同步。使用者在監控目錄內進行的檔案異動操作，例如：新增檔案、修改檔案、重新命名檔案以及刪除檔案和資料夾異動操作，例如：新增資料夾、重新命名資料夾、刪除資料夾，這些操作皆會被客戶端程式攔截並通知同步伺服器(Sync Server)，以及進行後續的檔案同步工作。. ( 2 ). Web Server 網站伺服器(Web Server)角色定位為系統的入口網站(Portal)，為系統提供了. 政治大式登入外，也提供讓客戶端應用程式使用網頁介面進行登入。入口網站彙整了登立. 單一驗證窗口和檔案同步以及管理，單一驗證窗口除了允許使用者以 OpenID 方. 入使用者所有已連結雲端服務，並提供使用者進行和客戶端程式一樣的檔案同步. ‧ 國. 學. 功能和額外的檔案下載功能。網站伺服器上也提供了檔案操作相關的 REST API，. ‧. 允許有權限的第三方程式或用戶來介接。. y. Nat. 在入口網站上，檔案管理服務讓使用者可以進行檔案分享功能，並且可以設. er. io. sit. 定檔案存取權限，例如：公開或是私人，透過由系統所提供的檔案存取網址，只要得到該網址並符合權限的用戶就可以進行檔案下載。. n. al. ( 3 ). Sync Server. Ch. engchi. i n U. v. 同步伺服器(Sync Server)主要負責把檔案同步到雲端儲存服務上。當使用者從客戶端進行的檔案和資料夾異動操作，同步伺服器會把相對應的變動透過雲端服務所提供的 API，對雲端服務進行檔案和資料夾異動。在同步伺服器上，同步程式會根據使用者所要同步的目的地端來進行區隔，例如：使用者在本地端的系統監控資料夾，對裡面的 Google Drive 資料夾進行新建檔案操作，同步程式則會把該檔案也新建到使用者的 Google Drive 雲端硬碟服務上；對裡面的 Dropbox 資料夾進行刪除檔案操作，同步程式也會把使用者在 Dropbox 服務上對應的檔案刪除。同步程式會把使用者每次異動的檔案版本最新資訊寫進資料庫，以維持使用 29.

(40) 者檔案清單的更新。由於同步程式的設計方式，同步請求的通知主要透過統一的通訊伺服器，和系統整體架構規劃上的考量，因此同步伺服器是可以進行彈性水平擴充的，把同步程式部署在多台同步伺服器上，來分擔使用者同步要求，彼此增進同步工作處理速度。. ( 4 ). Messaging Server 通訊伺服器(Messaging Server)為系統溝通的橋樑，在上面會架設 RabbitMQ 來負責客戶端、網頁伺服器和同步伺服器三者之間的訊息傳遞。訊息傳遞會以 AMQP 來進行，而訊息內容會以 JSON 資料格式來進行資料交換。. 政治大資料庫伺服器 (Database Server) 上架有 MongoDB ，其設計主要有兩種立. ( 5 ). Database Server. Collection 為 User 和 Files，User 存有系統上使用者資訊，Files 存有使用者擁有. ‧ 國. 學. 檔案清單和相關檔案權限資訊。. ‧. ( 6 ). OpenStack Swift. sit. y. Nat. OpenStack Swift 在系統架構上部署為代理節點(Proxy Node)和儲存節點. io. er. (Storage Node)，其主要作為系統上檔案同步的儲存伺服器，以及擔任檔案備援機制。使用者在客戶端或網站上進行的檔案和資料夾異動操作，都會透過代理節點. al. n. v i n 上的 Swift API 進行檔案同步，而同步程式進行同步工作時，可以從 Swift 上取 Ch engchi U 得相關檔案資料。. 30.

(41) 3、混合雲帳號整合在混合雲環境之下，使用者會有多重帳號和身分，例如：公有雲端服務帳號、私有雲帳號和本地端帳號等，本系統為進行在混合雲環境下的檔案同步，需要以使用者帳號的整合性為基礎，其詳細方法如下所述。. 3.1. 單一驗證介面. 使用本系統功能的先決條件為身分驗證通過，而系統的客戶端環境分為 Windows 和 Linux 作業系統，因此本研究透過系統中網頁伺服器所提供的 WebBased 的帳號驗證服務，以單一的驗證介面來支援跨平台的驗證需求，如圖十四. 政治大. 使用者客戶端和網站 Portal 端會共用同樣的驗證元件。. 立. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. Ch. engchi. i n U. v. 圖十四：單一驗證介面元件圖其中，Windows 和 Linux 的客戶端應用程式，會以應用程式內嵌 Web Browser 控制項的方式，讓客戶端應用程式也能共用和網站 Portal 同樣的 Web-Based 驗證介面，而不需要再個別開發專屬於應用程式的驗證模組。使用者可以透過 Web Browser 控制項進行和 Portal 服務一樣的登入方式，客戶端應用程式會以監聽 Web Browser 控制項網址的導向及其參數，來判斷使用者驗證成功與否，來決定後續的流程，網址判斷依據如表四。表四：客戶端應用程式驗證判斷. 31.

(42) URL. 說明. http://auth.example.com/service. 預設登入頁面，選擇要登入的雲端服務已經完成和雲端服務的 OpenID 驗. http://auth.example.com/application. 證，並重新導向回系統的驗證服務 http://auth.example.com/application?code= 網址參數 code 表示驗證成功 http://auth.example.com/application?error= 網址參數 error 表示驗證失敗. 3.2. 階段式帳號連結. 政治大. 本系統中雲端帳號的階段式連結，讓使用者不需要第一次就把所有雲端帳號. 立. 關聯建立起來，可以在未來自由選擇要連結(增加)或是移除和不同雲端帳號之間. ‧ 國. 學. 的關聯。系統設計上讓新使用者(第一次進行登入)和已登入的使用者，可以透過一樣的驗證流程來完成登入和連結雲端帳號，換句話說，新使用者視同雲端帳號. ‧. 連結數為零的用戶。使用者登入和連結雲端帳號的詳細帳號驗證順序如圖十五。. n. er. io. sit. y. Nat. al. Ch. engchi. i n U. 圖十五：帳號驗證順序圖 32. v.

(43) 系統的使用者，藉由帳號驗證服務所整合並彙整的多個不同雲端供應商 OpenID 來進行登入。本系統的帳號驗證服務只作為服務提供者，系統並不自行建立使用者帳號和密碼，而是透過 OpenID 來向各個雲端身分提供商，例如 Google、 Dropbox、Microsoft 和 Amazon 進行帳號驗證。當驗證成功後系統會把登入的雲端帳號和該使用者建立關聯並存在資料庫，確保使用者在不同裝置上登入本系統可以取得同樣的帳號連結關係。. 3.3. 雲端帳號對應. 由於使用者登入系統和連結雲端帳號都是透過同樣的帳號驗證服務，來和各. 政治大些雲端帳號，並把這些不同帳號資訊儲存並建立對應關係。立. 公有雲端服務、私有雲端服務進行驗證，因此系統可以得知登入的使用者擁有那. ‧ 國. 學. 帳號對應關係的資料儲存，分為客戶端和伺服器端，其中客戶端為配合應用程式是以 SQLite 來做為資料庫，儲存登入使用者目前已經擁有的帳號對應關係；. ‧. 伺服器端為了處理眾多使用者帳號對應資料，則使用 MongoDB 資料庫來儲存帳. y. sit. n. al. er. io. ( 1 ). 客戶端. Nat. 號對應關係，兩者的 Schema 設計如下所述。. Ch. engchi. i n U. v. 圖十六：SQLite 帳號對應類別圖 33.

(44) 如圖十六，Identity 和 Provider 為一對多關係，會以一筆 Identity 資料來對應到該使用者所有連結的雲端帳號，客戶端應用程式可以根據該資料表，判斷哪些雲端服務是有被連結的，並根據表中所存的使用者資料來做應用，其中 UID 是系統自動產生的唯一識別碼。. ( 2 ). 伺服器端. 立. 政治大. ‧. ‧ 國. 學 er. io. sit. y. Nat. al. v. n. 圖十七：MongoDB 帳號對應 User Collection 的 JSON 結構. Ch. engchi. i n U. 在伺服器端資料庫 MongoDB 的 User Collection 儲存的 JSON 資料格式如圖十七，其中 provider 陣列裡面會存有使用者各個雲端帳號相關的權杖(Token)資料，系統的同步服務可以使用雲端服務對應的權杖資料，並擁有權限來存取其儲存服務。. 34.

(45) 4、檔案與資料夾同步在混合雲環境之下，為了確保使用者在多個不同裝置上，檔案的一致性，其包含檔案資料的一致性和檔案清單的一致性，本研究針對使用者本地端、公有雲和私有雲三方的檔案，設計一個完整的檔案同步機制，詳細方法如下所述。. 4.1. 檔案系統監控模組. 使用者在本地端，例如：桌上型電腦、筆記型電腦，需要安裝客戶端應用程式，客戶端應用程式會包含檔案系統監控模組，該模組主要用於監控使用者於監控資料夾內進行的檔案和資料夾異動事件，整理如表五。. 政治大. 表五：檔案系統監控事件. 更名檔案. 刪除檔案. 資料夾監控事件刪除資料夾. 移動檔案. ‧. 新增資料夾. 修改檔案. 檔案監控事件. 學. 新建檔案. ‧ 國. 立. 移動資料夾. y. Nat. io. sit. 其中，移動檔案事件，系統會依判斷為新建檔案和刪除檔案兩種事件。而由. n. al. er. 於資料夾內可能是多層結構，有包含子資料夾和檔案，所以刪除資料夾事件，系. Ch. i n U. v. 統會依序判斷維刪除資料夾內檔案和刪除子資料夾，直到最後一層完畢；移動資. engchi. 料夾事件，系統會依序判斷為新增資料夾、新增資料夾內檔案和子資料夾，直到最後一層完畢，最後會再觸發刪除資料夾事件。檔案監控模組監聽到事件觸發後，會依據 producer-consumer pattern，檔案監控模組作為 producer，其會把每次產生的異動事件儲存進 Queue 資料結構，而同步模組作為 consumer，會不斷從該 Queue 資料結構把事件抓出來，再進行同步工作。其中，檔案和資料夾異動事件會轉為物件並以 𝑂𝑏𝑗𝑒𝑐𝑡𝑠𝑦𝑛𝑐𝑄𝑢𝑒𝑢𝑒 = {𝑂𝐼𝐷 , 𝑂𝐶ℎ𝑎𝑛𝑔𝑒𝑇𝑦𝑝𝑒 , 𝑂𝑃𝑎𝑡ℎ , 𝑂𝑂𝑙𝑑𝑃𝑎𝑡ℎ , 𝑂𝐿𝑎𝑠𝑡𝑀𝑜𝑑𝑖𝑓𝑖𝑒𝑑𝑇𝑖𝑚𝑒 , 𝑂𝑆𝑖𝑧𝑒 , 𝑂𝑇𝑦𝑝𝑒 }存進. 35. Queue。.

(46) 4.2. 同步機制設計. 同步機制的設計分為，客戶端和網站 Portal 對同步伺服器之間的同步訊息溝通以及檔案和資料夾的同步，如下所述。. ( 1 ). 同步訊息溝通同步模組從 Queue 把使用者異動事件取出來，接著判斷操作行為和類型是檔案或資料夾以及其相關資料後，不會馬上就開始進行檔案同步工作，而是會先和同步伺服器進行檔案同步要求，得到同步許可後，才會開始進行檔案或資料夾同步，完成後會再告知同步伺服器，同步訊息的溝通是透過通訊伺服器上的. 政治大. RabbitMQ 來進行處理，此三次訊息溝通的詳細順序圖如圖十八。. 立. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. Ch. engchi. i n U. v. 圖十八：三次同步訊息溝通順序圖此三次同步訊息：請求同步，其資料內容為. 𝑂𝑏𝑗𝑒𝑐𝑡𝑠𝑦𝑛𝑐𝑅𝑒𝑞𝑢𝑒𝑠𝑡 =. {𝑂𝑈𝐼𝐷 , 𝑂𝐼𝑡𝑒𝑚𝐼𝐷 , 𝑂𝑂𝑙𝑑𝐼𝑡𝑒𝑚𝐼𝐷 , 𝑂𝑃𝑎𝑡ℎ , 𝑂𝑂𝑙𝑑𝑃𝑎𝑡ℎ , 𝑂𝐶𝑙𝑖𝑒𝑛𝑡𝐾𝑒𝑦 , 𝑂𝐶ℎ𝑎𝑛𝑔𝑒𝑇𝑦𝑝𝑒 , 𝑂𝑇𝑜𝑘𝑒𝑛 , 𝑂𝐸𝑚𝑎𝑖𝑙 , 𝑂𝑇𝑦𝑝𝑒 , 𝑂𝐻𝑎𝑠ℎ }、回應同步請求，其. 內容為 𝑂𝑏𝑗𝑒𝑐𝑡𝑠𝑦𝑛𝑐𝑅𝑒𝑠𝑝𝑜𝑛𝑠𝑒 = {𝑂𝐼𝑡𝑒𝑚𝐼𝐷 , 𝐼𝐶ℎ𝑎𝑛𝑔𝑒𝑇𝑦𝑝𝑒 , 𝑂𝐼𝑡𝑒𝑚𝑅𝑜𝑙𝑒 , 𝑂𝑃𝑎𝑡ℎ , 𝑂𝑆𝑡𝑎𝑡𝑢𝑠 , 𝑂𝐴𝑢𝑡ℎ } 和同步完成，其內容為 𝑂𝑏𝑗𝑒𝑐𝑡𝑠𝑦𝑛𝑐𝐹𝑖𝑛𝑖𝑠ℎ𝑒𝑑 = {𝑂𝑈𝐼𝐷 , 𝑂𝐼𝑡𝑒𝑚𝐼𝐷 , 𝑂𝑂𝑙𝑑𝐼𝑡𝑒𝑚𝐼𝐷 , 𝑂𝑃𝑎𝑡ℎ , 𝑂𝑂𝑙𝑑𝑃𝑎𝑡ℎ , 𝑂𝐶ℎ𝑎𝑛𝑔𝑒𝑇𝑦𝑝𝑒 , 𝑂𝐸𝑚𝑎𝑖𝑙 , 𝑂𝑇𝑜𝑘𝑒𝑛 , 𝑂𝐿𝑎𝑠𝑡𝑀𝑜𝑑𝑖𝑓𝑖𝑒𝑑𝑇𝑖𝑚𝑒 , 𝑂𝑆𝑖𝑧𝑒 , 𝑂𝐻𝑎𝑠ℎ }. 36. ，.

(47) 皆會轉成 JSON 資料格式並以字串型態，來進行訊息傳遞和交換。. ( 2 ). 檔案與資料夾兩階段同步當第二次同步訊息溝通結束，同步伺服器允許客戶端開始進行同步，客戶端應用程式、網站 Portal 會把檔案或資料夾，以 OpenStack Swift 所提供的 REST API 同步到儲存伺服器，此為第一階段同步。同步完成後，客戶端應用程式、網站 Portal 會向同步伺服器送出第三次同步完成訊息，當同步伺服器收到同步完成訊息，此時就會再把該檔案或資料夾，以 REST API 從 OpenStack Swift 取得，再透過要同步的雲端儲存服務所提供的 API，把檔案和資料夾同步到對應的資料夾，. 政治大到公、私有雲端儲存服務，此兩階段的同步順序如圖十九。立. 此為第二階段同步。從客戶端和網站 Portal 到同步伺服器，而同步伺服器再同步. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. Ch. engchi. i n U. v. 圖十九：兩階段同步順序圖本系統檔案和資料夾同步，透過先同步到 OpenStack Swift 之上，在轉而同步到公有雲和其他私有雲上，這樣的做法可以確保使用者每一份同步到雲端的檔案和資料夾，在私有雲內部都將會有一份備份。. 4.3. 雲端檔案與資料夾異動偵測. 使用者進行檔案和資料夾異動操作，除了在本系統的客戶端和網站 Portal 上操作之外，也有可能是直接在已連結的雲端儲存服務，利用其所提供的介面，進 37.

(48) 行檔案異動操作。本系統為了達到雲端和本地端以及不同裝置之間的檔案一致性，會採用主動通知(Push)和被動掃描(Polling)混合的方式，以下將針對此兩種操作情境和機制詳細說明。. ( 1 ). 本系統上操作使用者在本系統客戶端和網站 Portal 上，進行檔案異動操作，當同步伺服器開始進行第二階段的同步時，如果該使用者還有其他裝置，也安裝了客戶端應用程式並且是啟動狀態，為了維持不同裝置上的檔案一致性，同步伺服器會採用主動通知(Push)該使用者其他客戶端應用程式，使其來進行檔案同步，詳細流程如圖二十。. 立. 政治大. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. Ch. engchi. i n U. v. 圖二十：客戶端應用程式更新本地端順序圖該通知同步訊息內容為，𝑂𝑏𝑗𝑒𝑐𝑡𝑠𝑦𝑛𝑐𝑁𝑜𝑡𝑖𝑓𝑖𝑐𝑎𝑡𝑖𝑜𝑛 = {𝑂𝑇𝑦𝑝𝑒 , 𝐼𝐶ℎ𝑎𝑛𝑔𝑒𝑇𝑦𝑝𝑒 , 𝑂𝑠𝑒𝑟𝑣𝑒𝑟𝑃𝑎𝑡ℎ , 𝑂𝑠𝑒𝑟𝑣𝑒𝑟𝑁𝑒𝑤𝑃𝑎𝑡ℎ }，也會轉成 JSON 資料格式並以字串型態，來進行訊息傳遞。. ( 2 ). 雲端儲存服務上操作使用者直接在已和本系統連結的雲端儲存服務，例如：Google、Dropbox、 38.