熱門論文
最新論文
云平臺配置信息管理研究
發布時間：2023-08-04 14:11
目錄
摘要 I
ABSTRACT III
插圖索引 V
表格索引 VII
符號對照表 IX
縮略語對照表 XI
目錄 XIII
第一章 緒論 1
1.1 研究背景與意義 1
1.2研究現狀 2
1.3本文工作 4
1.4章節安排 4
第二章 相關知識 7
2.1云計算技術 7
2.1.1云計算概念 7
2.1.2 云計算服務模型 7
2.1.3 開源云平臺 8
2.2 ZooKeeper 分布式協同服務 9
2.2.1ZooKeeper 交互方式 9
2.2.2ZooKeeper 數據節點 9
2.2.3ZooKeeper 事件監聽 9
2.2.4ZooKeeper 服務器角色 10
2.3Docker 技術 11
2.3.1Docker 架構 11
2.3.2Docker 核心概念 11
2.4Nginx 技術 12
2.4.1 Nginx 簡介及優勢 12
2.4.2Nginx 服務方式 13
2.5 本章小結 14
第三章 云平臺配置信息管理系統的設計 15
3.1 云平臺總體架構 15
3.2 系統需求分析 16
3.2.1 總體需求 16
3.2.2 功能需求 17
3.3 系統總體架構 18
3.4ZKFramework 設計 19
3.4.1ZKFramework 必要性 19
3.4.2ZKFramework 框架設計 19
3.4.3 最佳響應時間的負載均衡策略 20
3.4.4 最小服務器負荷的負載均衡策略 22
3.5模塊設計 22
3.5.1 云主機管理模塊設計 23
3.5.2 云應用環境管理模塊設計 24
3.5.3 云應用自適應失效轉移模塊設計 25
3.5.4 配置信息管理模塊設計 27
3.5.5系統可靠性設計 28
3.6 本章小結 29
第四章 云平臺配置信息管理系統的實現 31
4.1ZKFramework 實現 31
4.1.1ZKFramework 使用流程 31
4.1.2 最佳響應時間的負載均衡策略實現 32
4.1.3 最小服務器負荷的負載均衡策略實現 34
4.2模塊實現 35
4.2.1 云主機管理模塊實現 35
4.2.2 云應用環境管理模塊實現 36
4.2.3 云應用自適應失效轉移模塊實現 38
4.2.4 配置信息管理模塊實現 40
4.2.5系統可靠性實現 42
4.3本章小結 43
第五章 實驗與測試 45
5.1ZooKeeper 集群部署 45
5.2 系統功能測試 46
5.2.1 配置信息管理測試 46
5.2.2 云應用高可靠性測試 48
5.3 系統性能測試 50
5.4 本章小結 51
第六章 結論與展望 53
6.1 研究結論 53
6.2 研究展望 53
參考文獻 55
致謝 59
作者簡介 61
第一章 緒論
1.1 研究背景與意義
云計算是一種新的計算范式，使用戶無需硬件投資即可使用 IT 設備。云平臺為 云計算提供了基礎設施服務，如多地理位置存儲、彈性計算、資源按需分配、網絡服 務等。相對于傳統基礎設施，云平臺提供了不同粒度的計費周期，如亞馬遜 EC2 按 照小時收費，微軟Azure按照分鐘收費等。用戶根據需求選擇服務器租用時間，節省 了運營支出，極大地降低了投資成本。其核心思想是將大量計算機組成一個共享資源 池，以互聯網為途徑，按需提供存儲、計算及網絡等服務，實現資源的快速供應與釋 放。云平臺因具有低成本、彈性等諸多好處已被廣泛使用，成為互聯網的重要組成部 分。
目前，由于不同地域的用戶對云平臺計算、網絡及存儲等服務需求不同，云平臺 服務商選擇不同的基礎設施進行搭建，導致云平臺存在廣泛的異構性。這種異構性帶 來了更高的性能和功率比，使平臺中的服務器得到了充分地利用。在滿足用戶特定需 求的同時，降低了云服務商的投資成本，也形成了分布式異構云平臺。此外，在云計 算領域，也存在一種共識，即異構服務器架構將主導未來的數據中心［1］。分布式異構 云平臺擁有廣闊的應用前景。
隨著分布式異構云平臺的普及，大量應用服務被部署到云平臺上，這些應用服務 稱為云應用。云應用通常由 Web 服務組成［2］，其規模會隨著應用需求發生變化，這種 動態變化機制會造成數據庫地址、Web服務器地址等配置信息發生變化。當云應用規 模擴展到一定程度時，其配置信息會變得極其分散，修改其中的任何一項都會變得非 常困難，且容易出現錯誤。
近年來，配置信息錯誤已經成為系統故障的主要原因之一，導致許多重要服務中 斷或服務器宕機。例如：Barroso和Clidaras等闡述了配置信息錯誤是谷歌服務失敗 的第二個主要原因［3］； Rabkin和Katz報告說，配置錯誤是Hadoop集群故障的主要原 因［4］；在數據密集型系統［5］、大規模互聯網和 Web 服務［6］、云平臺系統［7］、數據庫系 統［8］等系統中也常因為配置信息錯誤導致服務異常；許多大型互聯網和云服務商如谷 歌、微軟、亞馬遜和 LinkedIn 等，也經歷了配置信息錯誤導致的停機情況，影響了 數百萬客戶［9-12］。
因此，對云平臺配置信息進行統一管理，實現大規模集群下配置信息的高效管理， 降低配置信息操作的復雜度，減小配置信息發生錯誤的概率，使配置信息易于管理和 更改，縮減配置信息管理成本，最大限度地避免因配置信息發生錯誤導致的服務中斷， 提高云應用配置信息修改效率和準確性，非常值得研究。
1.2 研究現狀
隨著云平臺日益流行，越來越多的應用被部署到云平臺上［13］，并且應用的規模隨 著需求動態變化，給應用的配置信息管理帶來了困難和挑戰［14］。配置信息管理經過如 下三個階段。
（1） 人工管理 人工管理配置信息通過手動方式對配置信息進行操作，需操作人員登錄集群中的 每一臺服務器部署、修改配置信息。如今，許多生產系統，例如分布廣泛、規模龐大 的云平臺和數據中心系統，通常由數百甚至上千個計算節點組成［15］，人工管理每個節 點的配置信息耗時耗力且極容易出現錯誤，無法滿足系統對實時性和準確性的要求， 導致系統發生異常，無法提供正常服務［16］。
（2） 自動化部署 針對人工管理配置信息實時性差和準確性低的問題，出現了自動化部署工具。這 些工具利用機器處理速度快、效率高和一致強的優點，對配置信息進行自動化部署， 提高了配置信息部署的效率和一致性，極大地減少了操作人員的工作量。常見的自動 化部署工具有Puppet^, Chefti8］和CFEngine3［19］等，這些工具處理方式類似，主要分 為前端和后端兩個部分。其中，前端為配置信息管理者提供一種聲明式語言，后端將 這種聲明式語言直接轉化成配置信息，并進行相應操作。這些自動化部署工具可以有 效解決配置信息部署問題，但是缺乏配置信息變更實時通知功能，無法感知云主機運 行狀態，也沒有提供完整的云平臺配置信息管理解決方案。
（3） 分布式配置管理系統 隨著分布式技術的迅猛發展，涌現出很多分布式配置管理系統。主要產品如下：
• Qconf
Qconff20］是奇虎360公司的分布式配置管理系統，其設計目的是采用新的分布式 配置管理系統取代傳統的配置文件，將之前與系統緊密耦合的配置信息與代碼分離出 來，實現配置信息變更實時通知及簡化配置信息管理的功能， 并提供配置信息高效讀 取能力。Qconf采用分布式協同服務ZooKeeper事件監聽機制等實現，用戶可以通過 zkdash進行界面管理［21］。Qconf擁有諸多優點，如高效讀取配置信息，服務器宕機、 網絡中斷等情況對用戶透明，支持多種編程語言等。目前，Qconf支持的平臺比較少， 在CentOS系統上可以快速部署使用，但是在其他系統，如Ubuntu就會出現各種編 譯錯誤，平臺的移植性較差。
• Disconf
DisconH22］是百度公司的分布式配置管理平臺，為各種業務平臺提供統一的配置 管理服務。 Disconf 具有使用方式簡單、低入侵性、文檔齊全等特點，受到了銀聯、 滴滴出行、網易等互聯網公司的青睞。目前， Disconf 主要提供 Java 客戶端和 Web 管理端，其中 Java 客戶端采用注解或者 XML 配置方式使用， Web 管理端采用 SpringMVC 實現了前后端分離。 Disconf 與 QConf 類似，采用 ZooKeeper 事件監聽機 制等實現，不同的是，其真實的配置信息數據存在數據庫中。
• diamond
diamond^ ］是淘寶的分布式配置管理服務，對大多數淘寶內部系統的配置信息進 行統一管理。diamond具有簡單、可靠、易用等特點，為應用系統提供了配置信息管 理服務，應用系統不僅可以在啟動的時候獲取配置信息，還可以在應用系統運行過程 中感知配置信息的變化并獲取變化后的配置信息。
此外，類似上述配置信息管理產品還有 etcd、 xdiamond 等，這些產品實現了配 置信息統一管理，完成了配置信息訂閱和變更通知功能，但是，由于這些產品并沒有 針對云平臺做特殊處理，無法實時感知云主機狀態變更信息，也無法保證云應用的高 可靠性，在分布式異構云平臺應用時存在不足。
Qconf 和 Disconf 等產品都使用分布式協同服務 ZooKeeper 的臨時節點和事件監 聽機制［24-26］，實現配置信息變更實時通知功能。然而，ZooKeeper應用在分布式異構 云平臺時，其自帶的客戶端存在無法感知服務器性能差異及所屬地域，容易選擇負荷 較高或者離云主機較遠的服務器進行連接，從而導致配置信息讀取時間較長的問題。 ZooKeeper客戶端選擇服務器連接過程中，將服務器地址進行一次隨機打散，然后將 隨機打散的服務器地址形成一個循環隊列，之后客戶端按照循環隊列的順序依次獲取 服務器地址進行連接［27］。這種先隨機打散后輪詢使用的方式可以高效獲取服務器地址 進行連接，但在分布式異構云平臺使用時也存在一些問題，如沒有參考服務器性能參 數而無法選擇當前運行負荷最小的服務器，也無法選擇離客戶端最近或者響應時間最 佳的服務器。
因此，解決ZooKeeper在分布式異構云平臺下無法感知服務器性能差異及所屬地 域的問題，并利用ZooKeeper開發一種適用于云平臺的配置信息管理系統，統一管理 云應用的配置信息，解決現有配置信息管理系統無法實時感知云主機狀態變更信息， 不能保證云應用的高可靠性等問題，實現配置信息變更實時通知、云主機狀態信息實 時獲取、配置信息高效讀取、云應用快速響應配置信息變更等功能，提高云應用配置 信息修改的效率和準確性，保證云應用的高可靠性是非常必要的。
1.3 本文工作
針對手動修改配置信息無法滿足系統對實時性和準確性的要求，現有配置信息管 理系統因無法實時獲取云主機狀態變更信息，不能保證云應用的高可靠性而不適合云 平臺應用的問題，設計實現了一個云平臺配置信息管理系統。本文的主要工作如下：
(1)保證了云應用高可靠性，對配置信息進行統一管理 本文設計實現了云主機管理模塊、云應用環境管理模塊及云應用自適應失效轉移
模塊，保證了云應用的高可靠性；利用ZooKeeper臨時節點及事件監聽機制，設計實 現了配置信息管理模塊，對配置信息進行統一管理，完成了配置信息變更的實時通知、 云應用快速響應；將配置信息存儲于跨地域的ZooKeeper集群，實現了配置信息存儲 的容錯能力。
(2)優化了分布式異構云平臺中ZooKeeper客戶端與服務器的連接過程 針對分布式異構云平臺中 ZooKeeper 客戶端因無法選擇最佳服務器進行連接從
而導致配置信息讀取時間較長的問題，本文設計實現了 ZKFramework框架，提出了 最小服務器負荷和最佳響應時間的負載均衡策略，使客戶端能夠根據服務器性能差異 及所屬地域進行連接，從而減少配置信息讀取時間，優化應用程序性能，并達到充分 利用異構服務器性能的效果。
(3)分析了系統需求 本文分析了云平臺配置信息管理系統的總體需求，并根據總體需求詳細描述系統
的功能需求，為系統設計和實現打下基礎。
(4)設計實現了云平臺配置信息管理系統 根據系統對云應用高可靠性及配置信息管理功能的需求，設計了云平臺配置信息
管理系統的總體架構，詳細設計并實現了各個模塊，包括配置信息管理模塊、云主機 管理模塊、云應用環境管理模塊、云應用自適應失效轉移模塊，此外，實現了系統的 高可靠性，避免了系統單點故障的發生。
(5)完成了云平臺配置信息管理系統的測試 系統開發完成后，對系統功能和性能進行了測試。測試結果表明，系統達到了設
計目標，實現了云應用的高可靠性和配置信息的管理功能。
1.4 章節安排
本文分為六個章節進行介紹，各章節內容具體安排如下： 第一章為緒論。主要介紹論文研究的背景意義、研究現狀及論文的主要工作。 第二章為相關知識。對論文中所涉及的技術進行綜合性介紹。分別對云計算、分 布式協同服務 ZooKeeper、 Docker 容器和 Nginx 相關技術進行闡述。
第三章為云平臺配置信息管理系統的設計。完成云平臺配置信息管理系統的需求 分析和總體架構設計。對總體架構中 ZKFramework 框架及最小服務器負荷和最佳響 應時間的負載均衡策略進行詳細設計，并對系統中云主機管理、云應用環境管理等模 塊進行設計。
第四章為云平臺配置信息管理系統的實現。在第三章需求分析、總體架構及各個 模塊設計基礎上進行實現，介紹實現方案的詳細流程。
第五章為測試與實驗。系統完成后，對云平臺配置信息管理系統進行實際部署， 并完成系統功能測試和性能測試。
第六章為總結與展望。對云平臺配置信息管理系統中已經完成的內容進行總結， 分析系統實現過程中的問題，對未來工作進行展望。
第二章 相關知識
本文在研究云平臺配置信息管理系統中涉及到眾多技術知識，主要包含云計算、 分布式協同服務 ZooKeeper、 Docker 容器、 Nginx 相關技術等內容。本章節將對上述 技術知識進行簡要的介紹。
2.1 云計算技術
按需付費、彈性變化等諸多好處促使云計算越來越受歡迎，本節分別從云計算概 念、云計算服務模型和開源云平臺對云計算技術進行介紹。
2.1.1云計算概念
二十世紀九十年代至今，互聯網已經從最初并行計算階段，經歷了分布式計算和 網格計算概念后，逐漸走向了云計算領域。云計算通過網絡提供按需訪問共享資源和 在線計算的能力，其主要利用了虛擬機化技術，實現了一種按每次使用付費的商業模 式。對于服務提供商，這意味著無需投資昂貴的IT基礎設施，即可在全球各地開發、 部署和銷售云應用程序。
云計算將計算資源以服務的形式提供給用戶，形成了一個高度可擴展的分布式計 算系統。目前，并沒有統一的云計算定義，最為廣泛接受的是來自于美國國家標準與 技術研究院(National Institute of Standards and Technology，NIST)的定義［28］：
云計算是一種模型，該模型以網絡為訪問途徑，以便捷、按需訪問為目的，提供 一個共享資源池，用戶可以通過共享資源池按需獲取諸多資源，例如：服務器、網絡 和存儲等。同時， 該模型能夠在最小管理干涉和最小服務商參與的情況下完成資源迅 速供應和釋放。
2.1.2云計算服務模型
Youseff和Butrico等在深入研究云計算的基礎上，將云計算的服務模式分為了三 種［29］，具體如下。
(1)Iaas 基礎設施即服務
基礎設施即服務(Fastructure as a Service， Iaas)提供云計算最基礎的支撐，其 提供的服務主要包含虛擬機、網絡、存儲等。用戶在使用這些服務時，無需對支持這 些服務的基礎 IT 軟硬件付出原始投資成本，并可以依據需求動態調整服務參數，獲 取不同服務能力。Iaas主要優勢有使用靈活，可隨時擴展或回收資源等［30］。
目前，大型IT企業，如IBM、微軟、谷歌等都開始部署Iaas服務，比較著名的 Iaas服務主要有亞馬遜S3存儲服務、亞馬遜EC2計算服務以及OpenStack開源云計 算平臺等。
(2)Paas 平臺即服務
平臺即服務(Platform as a Service，Paas)在Iaas的基礎上，將應用程序的開發、 測試、部署等以服務形式提供給用戶。用戶使用 Paas 平臺后，不僅可以節省購買硬 件和軟件費用，還可以很方便地管理應用程序生命周期。
目前，Paas平臺受到了國內外互聯網公司的廣泛關注，其中已經能夠提供優秀服 務的Paas平臺主要包含谷歌App Engine平臺、微軟Azure平臺等［31］，兩個平臺關注 的內容不同，App Engine偏向于網絡應用服務，而Azure平臺則以組合操作系統及各 類開發服務為目的。
(3)Saas 軟件即服務
軟件即服務(Software as a Service， Saas)在Iaas的基礎，為用戶提供獲取軟件 的一種新形式，即無需將軟件安裝在自己的電腦或者服務器上，而是使用特定協議獲 取軟件功能［32］。Google提供的基于Web的電子郵件就是比較典型的軟件即服務。
2.1.3 開源云平臺
云平臺為用戶提供虛擬機、網絡、存儲等服務，由于其強大的擴展能力及低成本 等特點，已經被廣泛使用。目前，存在較多開源服務平臺［33］，具體如下：
( 1 ) OpenNebula
OpenNebula旨在幫助公司在現有IT基礎架構上構建簡單，經濟高效，可靠，開 放的企業云。其能夠提供靈活的工具，協調存儲，網絡和虛擬化技術，以實現服務的 動態布置。 OpenNebula 的靈活設計和模塊化允許與不同的存儲和網絡基礎設施(私 有、公共和混合)和虛擬機管理程序技術(如KVM，Xen和VMware)集成［34］。
( 2) Eucalyptus
Eucalyptus 由加利福尼亞大學開發創建。其根據據 GPL 許可證發布，可以用于創 建和管理私有和公共云。 Eucalyptus 復用了 EC2 的接口和功能，兼容亞馬遜 EC2 云 計算平臺和亞馬遜S3云存儲平臺［35］。
( 3 ) CloudStack
CloudStack 是一個擴展性非常高的開源云計算平臺，可用于構建公共云和私有云。 其支持大多數常見的操作系統，并且采用了分層的基礎結構，以便管理多種資源［36］。 CloudStack由Cloud.com以GNUv3許可證在2010年公布，2011年被Citrix收購，而 后在 2012 年更改許可證為 Apache 2.0。
( 4) OpenStack
OpenStack旨在創建一個可擴展、靈活的開源云計算平臺。通過OpenStack，用 戶可以構建一個包含計算、存儲和網絡等共享資源池，該共享資源池通過數據中心控 制并通過儀表板或API進行管理［37］。OpenStack云操作系統允許企業在數據中心構建 類似Amazon的云服務，其包括一系列相互關聯的項目，為云平臺基礎架構提供各種 服務。
2.2 ZooKeeper 分布式協同服務
ZooKeeper項目以封裝分布式一致性服務、提供高效可靠的原語集為目標，是一 種典型的分布式一致性解決方案。其提供了一系列簡單易用的接口，使開發人員能夠 實現命名服務、分布式鎖、集群管理等功能［38］。本節分別介紹 ZooKeeper 的交互方式、 數據節點、事件監聽及服務器角色。
2.2.1ZooKeeper 交互方式
ZooKeeper提供單機和偽集群兩種模式供用戶開發和測試使用，并支持集群部署 方式。在實際生產環境中，為了實現容錯功能，ZooKeeper常常以分布式集群方式部 署［39］。ZooKeeper集群交互方式如圖2.1所示，通常，ZooKeeper集群以端口 2181提 供客戶端連接訪問，客戶端連接集群時，采用一定的負載均衡策略選擇集群中某臺服 務器創建會話，該會話擁有一個超時時間，在這個時間內，客戶端可以通過連接訪問 ZooKeeper 集群數據，也可以接收來自集群的 Watch 事件通知。若在會話時間內，客 戶端因網絡故障等斷開連接，那么客戶端會選擇集群中其他服務器進行重新連接，會 話依舊有效。
2.2.2ZooKeeper 數據節點
數據節點是ZooKeeper數據模型中的數據單元，也被稱為Znode節點oZooKeeper 數據模型是一棵樹，也被稱為Znode樹，其結構如圖2.2所示。每一個數據單元就是 一個數據節點，這些數據節點可以保存數據內容，也擁有一系列屬性值，并可依照節 點存在方式進行永久節點和臨時節點劃分。其中，永久節點指該節點在創建后除非主 動刪除否則一直會存在，而臨時節點與客戶端的會話有關，只有在會話有效時，節點 才會存在，一旦會話失效，臨時節點也會從ZooKeeper集群中移除。此外，數據節點 還可以分為有序無序兩種，采用有序的數據節點可以防止數據節點命名沖突，其主要 是在數據節點創建的時候自動在節點名后面添加一個單調遞增的整型數字，該數字由 其父節點維護。
2.2.3ZooKeeper 事件監聽
事件監聽(Watcher)是ZooKeeper實現分布式協調服務的一個重要特性。該特性允
許客戶端接受 ZooKeeper 數據節點變化的通知。客戶端在感興趣的數據節點上注冊
Watcher，當數據節點發生變化后，ZooKeeper服務器就會將變化信息通知給客戶端, 客戶端得到通知即可獲取ZooKeeper服務器中最新的數據。
Znode 樹
圖 2.2 Znode 樹型結構
ZooKeeper中事件監聽在一次觸發后就會失效，也就是說如果需要持續監聽數據 節點變化，需要在單次觸發后再次進行事件的注冊監聽工作。此外，ZooKeeper注冊 監聽機制只進行事件通知，并不會向客戶端推送數據，采用這種方式可以保證客戶端 能夠獲取到最新的數據。
2.2.4ZooKeeper 服務器角色
ZooKeeper集群中，分別有Leader>Follower和Observer三種類型的服務器角色。 Leader 服務器是整個 ZooKeeper 集群中核心，為集群中事務請求的唯一處理者，對整 個事務請求進行排序編號，保證集群內部消息處理的順序性；Follower服務器在響應 客戶端的讀請求外，將事務請求轉發給 Leader 服務器，并參與集群中所有需要投票 的過程；Observer服務器工作原理和Follower服務器基本相同，該角色的服務器會處 理客戶端的讀請求，并將事務請求轉發給Leader服務器，但是Observer服務器不參 與任何形式的投票，這樣在不影響集群事務處理的能力下，可以提升集群的讀請求處 理能力。
2.3Docker 技術
Docker以提供高效、敏捷和輕量級容器方案為目的，主要對應用組件進行管理， 其中，管理內容包含組件封裝、分發、部署、運行等［40］。本節分別從架構和核心概念 對 Docker 技術進行介紹。
2.3.1Docker 架構
Docker采用Client-Server的模式，主要利用Linux容器技術實現基本功能，其最 大特點為“Build Once，Run Anywhere”,即用戶只需進行一次編譯過程，就可以在多個 平臺上運行［41］。 Docker 容器允許開發人員將應用及其依賴環境打包到一個可移植的 鏡像中，然后發布運行到其他平臺上。
Docker 架構圖如 2.3 所示，圖中展示了 Docker client>Docker daemon、GraphDB、 Driver和Graph等多個組件。其中，Docker client采用Docker命令或者API調用的方 式向Docker deamon發送操作容器的請求；Docker deamon根據請求類型啟動不同組 件進行處理； GraphDB 實現了圖數據庫的一部分操作，為獲取節點之間關系提供了 簡單易用的接口； Driver為驅動模塊，容器的具體運行環境由該模塊定制完成，分為 graphdriver、 networkdriver 和 execdriver 等； Graph 負責管理鏡像及鏡像間的關系，處 理鏡像相關的操作［42］。
2.3.2Docker 核心概念
Docker 主要有三個核心概念，分別為鏡像、容器和倉庫［43］。
（1 ） Docker 鏡像
Docker 鏡像近似于虛擬機鏡像，是一個只讀模板，利用 Docker 鏡像可以啟動 Docker 容器，運行特定任務。 Docker 鏡像創建和更新也非常簡單，用戶可以對已經 運行的 Docker 容器打標簽完成鏡像創建及更新，其更新原理是鏡像含有文件系統， 通過版本管理和增量方式進行修改。用戶可以從網上下載應用鏡像，并通過命令直接 運行，其所需環境已經被封裝到Docker鏡像中［44］。
（ 2） Docker 容器
Docker容器是由鏡像創建的應用實例，用來運行和隔離應用程序。用戶可以對容 器進行啟動、停止、刪除等操作。容器在啟動的時候會在只讀的鏡像層增加一個可寫 層，這樣用戶就可以進行寫操作，而Docker鏡像的內容不會發生改變［45］。
（ 3） Docker 倉庫
Docker倉庫是用來集中存放鏡像文件的場所，其類似于代碼倉庫。倉庫可以存放 多個鏡像文件，這些鏡像文件可以通過不同的標簽進行區分。Docker鏡像可以根據 用戶需求存儲在公有或者私有倉庫中，其中公有倉庫中存放了大量可以下載的鏡像， 這些鏡像可以被互聯網上任何用戶訪問使用。Docker鏡像搜索、上傳、下載功能通 過 Docker daemon 與 Docker Registry 交互完成［46］。
2.4Nginx 技術
Nginx由于高性能、開源、穩定等諸多特性，已經受到了廣泛使用，下面分別從 Nginx簡介及優勢、Nginx服務方式對Nginx技術進行介紹。
2.4.1 Nginx 簡介及優勢
Nginx 服務器研究始于俄國， 2002 年由 Igor Sysoev 開發，并在 2004 年發布第一 個正式版本。該版本功能尚不完善，主要作為Apache的輔助使用，目的是提高Apache 在HTML、CSS和JavaScript等靜態資源處理速度，實現Apache服務器多用戶多任 務快速處理的功能，從而降低延時。Nginx的優良性能吸引了大量的開發人員，如今， Nginx服務器在性能和功能上得到了非常大的發展，國內外如Github、網易、新浪等 大型互聯網公司都已廣泛部署使用。Nginx服務器不僅在并發能力、處理速度等性能 方面有著很好的優勢，在其他方面也有著非常優秀的特性：
（1）擴展性強， Nginx 很好地實現了松耦合，其不同模塊在功能、層次及類型 得到了充分的隔離，用戶可以很方便地選擇不同模塊進行修改升級。
（2） 占用資源少，Nginx對內存等進行了優化，消耗資源較少。
（3） 穩定性強， Nginx 通過分段分配的方式對系統資源配置進行了優化，避免 了惡意攻擊訪問造成系統內存耗盡的問題的發生，具有很高的穩定性。
（4） 代碼開源， Nginx 將代碼開源，既滿足了企業定制需求，也吸引了大量開 源愛好者，促使Nginx得到了快速的發展。
2.4.2Nginx 服務形式
Nginx 可以提供多種服務，其中，代理服務和反向代理服務最為常見。
代理服務也稱為正向代理服務。正向代理服務主要為局域網的服務器提供防火墻 的功能，并且允許局域網內服務器通過正向代理服務器訪問互聯網資源。部署正向代 理服務器后，局域網內的服務器在訪問互聯網的同時，也受到了很好的保護，不易受 到互聯網其他服務器的惡意攻擊。正向代理服務也可以起到緩存功能，假如局域網內 某臺服務器已經訪問過某個網址的內容，那么局域網中的其他服務器就可以直接從正 向代理服務器中獲取相關的數據，從而減少了網絡訪問延時，加速了局域網內服務器 的訪問速度。此外，部署正向代理服務器可以實現局域網服務器訪問互聯網時的授權 功能，通過在代理服務器配置局域網服務器訪問規則，過濾某些服務器的訪問數據包， 使局域網服務器訪問外網受限。
反向代理服務的實現效果與正向代理服務剛好相反，其目的是屏蔽局域網內的服 務器的具體信息，同時，實現互聯網其他服務器對局域網內資源的訪問。使用反向代 理服務可以實現隱藏原始服務器信息、負載均衡等的功能。
隱藏原始服務器信息可以有效減少服務器被惡意攻擊或者訪問的概率，互聯網用 戶訪問資源時只有Nginx反向代理服務交互，然后，Nginx反向代理服務器訪問原始 資源服務器，獲取數據后返回給用戶，若Nginx服務器已經訪問過原始資源服務器, 則可以直接將數據返回給用戶，從而減少原始資源服務器的訪問量，同時，加快用戶 的訪問速度。
負載均衡是反向代理的另一個優秀特性，當Nginx反向代理服務器所代理的原始 資源服務器擁有多臺時，可以選擇不同的負載均衡策略分配用戶的請求連接，實現原 始資源服務器的均衡利用。選擇合適的負載均衡策略可以有效避免單臺原始資源服務 器因為突發的訪問量出現宕機情況，并且可以根據服務器的性能差異配置處理比例， 實現異構服務器性能的充分利用。目前，Nginx負載均衡策略有內置和擴展兩種使用 方式，其內置的負載均衡策略主要有網絡地址哈希和加權輪詢兩種，擴展的負載均衡 策略可以根據用戶需求進行第三方安裝，常見的有最小連接數、fair等策略。
2.5 本章小結
本章對云平臺配置信息管理系統中涉及的云計算、ZooKeeper、Docker以及Nginx 相關技術進行詳細的介紹。首先從概念、服務模型及開源云平臺三個方面對云計算技 術進行了描述，然后詳細講述了分布式協同服務ZooKeeper交互方式、事件監聽機制、 數據節點和服務器角色，對Docker的架構及其核心概念進行了闡述和分析，最后分 別從 Nginx 簡介及優勢和 Nginx 服務方式對 Nginx 相關技術進行了介紹。
第三章 云平臺配置信息管理系統的設計
設計云平臺配置管理系統時，有必要對使用的云平臺總體架構進行簡單介紹。在 此基礎上，對系統需求進行分析，明確系統需求后，設計系統總體架構、 ZKFramework 框架及各個模塊，為后續實現工作奠定基礎。
3.1 云平臺總體架構
為了完成跨地域協同計算任務的研究，構建了一個多地協同服務的云平臺。該平 臺利用了 OpenStack云操作系統和虛擬化技術，提供了任務調度分配、虛擬資源和集 群監控等功能，將多地異構計算資源整合成一個較大的虛擬化資源池。平臺以運行計 算任務和提供云主機的形式對外提供服務，包含了 Windows， Ubuntu， RedHat 等多 種操作系統，用戶提交計算任務或申請云主機時可按需制定CPU,內存等資源。云
平臺總體架構如圖 3.1 所示。
由圖 3.1可知，該云平臺主要由兩個集群組成，每個集群部署地理位置不同，都 包含分控制中心、網絡節點和若干個計算節點，這些節點采用的服務器及集群中使用 的交換機會根據集群需求差異采用不同的設備，計算節點個數也會按照計算需求進行 設置。這樣，不同子集群提供的計算能力就會存在較大差異，形成了一個分布式異構 云平臺。
平臺采用雙層架構模型，分為總控制中心和分控制中心。其中，總控制中心對外 提供服務并且管理多個分控制中心，分控制中心負責所在集群的資源管理和任務運行。 主控制中心將資源申請管理等功能以 Web 服務形式發布到互聯網上，用戶通過互聯 網終端提交任務，任務經過網絡發送到總控制中心，總控制中心接受到任務后，啟動 調度器獲取平臺資源分布及使用狀況， 并根據調度策略給出資源分配結果， 分控制中 心接到任務和資源分配結果后，在相應計算節點上啟動云主機，由該云主機作為 Master節點，啟動整個并行計算任務。主控制中心除了提供資源管理功能外，還會進 行用戶認證，平臺資源監控匯總，任務結果匯總等任務。
3.2 系統需求分析
3.2.1 總體需求
云平臺配置信息管理總體目標為：保證云應用的高可靠性，在云應用正常運行的 基礎上，設計一個高效穩定的配置信息管理系統，使其適應分布式異構云平臺。其中， 配置信息需以分布式形式存儲，并且系統能夠根據服務器性能差異及其所屬地域，合 理分配用戶連接請求。
具體來說，主要包含以下幾點：
（1）云應用高可靠性
云平臺配置信息管理系統主要將云應用的配置信息與代碼分離出來，對配置信息 進行統一管理，只有在云應用正常運行的前提下，配置信息管理才有意義。
（ 2）統一管理配置信息
云平臺配置信息的統一管理，一方面可以實現對用戶透明的配置信息存儲、配置 信息變更實時通知、云應用快速響應的目標，另一方面可以統一配置信息操作功能， 方便用戶使用。
（3） 配置信息采用分布式形式存儲 云平臺采用多地協同服務的形式部署，隨著業務需求的擴張，整個云平臺集群規
模需不斷擴大，為了提高各個子集群配置信息的讀取效率并且實現配置信息系統無單 點故障、跨地區容錯功能，配置信息管理系統必須采用分布式形式存儲。
（4） 配置信息讀取適應分布式異構云平臺
分布式異構云平臺具有地理位置分散、子集群間服務器硬件性能存在差異等特征， 配置信息管理需要適應這些特征，能夠根據服務器性能差異分配用戶讀取請求，實現 服務器高效利用，同時，能夠感知服務器地理位置，選擇合適服務器進行連接，降低 網絡延時，減少配置信息讀取時間，提高應用程序性能。
（ 5）配置信息管理系統具有高可靠性 云平臺配置信息管理系統必須具有高可靠性，避免單點故障的發生。
3.2.2 功能需求 根據總體需求，對云平臺配置信息管理系統進行功能需求分析。為了保證云應用 的高可靠性，系統應具有云主機管理、云應用環境管理及云應用自適應失效轉移功能； 為了實現配置信息分布式存儲及存儲容錯能力，系統采用跨地域的ZooKeeper集群形 式存儲；為了使配置信息讀取適應分布式異構云平臺，本文提出 ZKFramework 框架 及最小服務器負荷和最佳響應時間的負載均衡策略；為了實現系統的高可靠性，系統 需要進行高可靠性設計。具體功能需求介紹如下：
（ 1）云主機管理 云主機管理主要實現云主機狀態變更信息的實時通知功能，其中，狀態信息主要 包括云主機上下線信息。利用該功能，云應用可以實時監測其所在主機的狀態，進行 必要的邏輯處理。
（2）云應用環境管理 云應用環境管理主要簡化傳統應用部署中安裝、配置環境、運行等一系列需要人 工參與的過程，依賴云應用環境管理，云平臺部署應用服務時可自動配置其運行環境， 為云應用自適應失效轉移奠定基礎。
（ 3 ）云應用自適應失效轉移 云應用自適應失效轉移是保證云應用高可靠性的核心功能，該功能收到云主機狀 態變更消息后，與云平臺進行交互，自動轉移應用服務，保證云應用的高可靠性。
（4） 配置信息管理 配置信息管理主要實現云平臺配置信息的統一管理，通過可視化管理界面方便用
戶管理配置信息，實現對用戶透明的配置信息存儲、配置信息變更實時通知及云應用 快速響應等功能。
（5） 系統可靠性 云平臺配置信息管理系統必須具有高可靠特征，滿足其在單臺服務器宕機的情況
下依舊能夠繼續運行，提供正常服務，實現配置信息管理系統的容錯能力。
（6） ZKFramework 框架及負載均衡策略
分布式異構云平臺中 ZooKeeper 客戶端因無法選擇最佳服務器進行連接從而導
致配置信息讀取時間長，為了使配置信息讀取適應分布式異構云平臺， ZKFramework 框架增強ZooKeeper客戶端，并提出最小服務器負荷和最佳響應時間的負載均衡策略, 使客戶端能夠根據服務器性能差異及所屬地域進行連接，從而減少配置信息讀取時間， 優化程序性能。
3.3 系統總體架構
云平臺配置信息管理系統主要利用云計算、ZooKeeper、Docker等技術實現系統 需求。在詳細分析了系統總體需求及功能需求的基礎上，設計了多個模塊，分別為云 主機管理模塊、云應用環境管理模塊、云應用自適應失效轉移模塊、配置信息管理模 塊、 ZKFramework 框架，并對系統可靠性進行設計。其中，云主機管理模塊、云應 用環境管理模塊及云應用自適應失效轉移模塊相互交互，保證了云應用的高可靠性； 配置信息管理模塊則實現了配置信息統一管理、配置信息變更實時通知及云應用快速 響應等；ZKFramework框架優化了 ZooKeeper客戶端與服務器連接過程，使其更適 合分布式異構云平臺；系統可靠性設計保證了整個云平臺配置信息管理系統無單點故 障。系統總體架構如圖 3.2 所示。
配置信息
管理面板
通過廣域網 訪問系統
系統可靠性
圖3.2展示了系統中各個模塊及相關集群。相關集群分別為：基于OpenStack云 操作系統搭建的分布式異構云平臺、跨地域ZooKeeper集群以及采用Registry鏡像搭 建的 Docker 私有倉庫。系統中各個模塊與集群交互，完成云平臺配置信息管理。具 體交互過程為：云平臺啟動云主機，利用云主機管理模塊在ZooKeeper集群注冊數據 節點，利用云應用環境管理模塊在 Docker 私有倉庫中查找下載云應用鏡像，啟動云 應用后，在ZooKeeper集群中注冊云應用數據節點，獲取ZooKeeper集群中與云應用 相關的數據更新云應用配置信息。云應用自適應失效轉移模塊收到云主機管理模塊通 知后，利用云應用環境管理模塊和云平臺管理功能，結合 ZooKeeper 相關數據，從 Docker 私有倉庫中下載應用鏡像，實現云應用自適應失效轉移。上述各個模塊與 ZooKeeper集群交互的過程中，都使用ZKFramework框架進行連接。
3.4ZKFramework 設計
3.4.1ZKFramework 必要性
目前，ZooKeeper客戶端選擇服務器進行連接時，采用隨機打散服務器地址形成 循環隊列后使用輪詢算法的方法。輪詢算法是一種最簡單的負載均衡策略，能夠將請 求或者數據均勻的分配到不同的處理單元上執行。例如在一個擁有三臺服務器的 ZooKeeper 服務器集群中，若第一臺服務器建立完一個連接，那么第二個連接就會分 配到第二個服務器上，以此類推，將客戶端連接請求均勻的分配到不同的服務器上。 這種負載均衡策略能夠快速選擇服務器進行連接，在相同性能的服務器集群中發揮很 好的效果，但在分布式異構云平臺中，卻因無法感知服務器性能差異及所屬地域，容 易選擇負載較高或者離云主機較遠的ZooKeeper服務器進行連接，造成云應用配置信 息讀取速度慢且服務器無法得到充分利用等問題。
針對上述問題，設計 ZKFramework 框架及最小服務器負荷和最佳響應時間的負 載均衡策略，使客戶端能夠根據服務器性能差異及所屬地域進行連接，減少配置信息 讀取時間，充分利用異構服務器性能。
3.4.2ZKFramework 框架設計
針對ZooKeeper客戶端在分布式異構集群中使用不足的問題，本文對其客戶端進 行增強，提出ZKFramework框架，該框架采用面向對象的編程思想，利用工廠方法、 創建者模式、策略模式等設計模式提高框架的可擴展性，優化ZooKeeper客戶端與集 群的連接過程。ZKFramework總體架構如圖3.3所示。
com.cloud.core.zkframework.factory
圖 3.3 ZKFramework 總體架構
圖3.3展示了 ZKFramework框架的各個模塊及其之間的關系。ZKFramework框 架在ZooKeeper客戶端的基礎上，新增負載均衡策略模塊，使其能夠適應分布式異構 云平臺，并且重新封裝客戶端接口，使操作更加便捷。ZKFramework模塊如表3.1所 示，其中， ZKFrameworkFactory 內部采用構建者模式，避免了構造函數需要大量可 選參數的問題，使用戶能夠根據需求選擇特定參數進行設置；Constant類集中管理系 統常量數據； LoadBalanceStrategy 采用策略模式設計最小服務器負荷和最佳響應時間 的負載均衡策略,并通過LoadBalanceStrategy接口方便用戶實現特定的負載均衡策略。
3.4.3最佳響應時間的負載均衡策略
分布式異構云平臺帶來了更高的性能和功率比，具有高可靠性和強容災能力。然 而，其地理位置分散特征會帶來訪問延時的問題，尤其在用戶訪問部署距其較遠的服 務時，網絡延時就會隨著傳播時間和等待時間大大增加。用戶在分布式異構云平臺中 申請的云主機所處地理位置不同，選擇不同地域的ZooKeeper服務器進行連接，響應 時間也會存在較大差異。選擇離云主機最近或者響應時間最佳的服務器進行連接，可
以有效降低網絡延時，減少配置信息讀取時間，優化程序性能。為了選擇合適的服務
器進行連接，本文設計最佳響應時間的負載均衡策略。
表 3.1 ZKFramework 模塊
模塊 作用
Client 提供對外接口
Factory 工廠類，創建ZKFramework
Utils 系統中使用的各種工具包
Core 實現ZKFramework操作
Api 各種連接ZooKeeper集群的操作接口
Constant 系統中設定的常量
LoadBalancestragetry 負載均衡功能相關內容
最佳響應時間的負載均衡策略主要思路是在用戶連接ZooKeeper服務器集群前， 首先向服務器集群發送一個請求數據包，集群服務器收到請求包后反饋響應，然后在 客戶端收集統計服務器響應時間，選擇響應時間最短的服務器地址進行連接。如果連 接失敗，則重新連接，直到連接成功。
最佳響應時間的負載均衡策略架構如圖 3.4所示，由圖可知，為了適應分布式異 構云平臺的多地理位置特性，在對應地域部署ZooKeeper子集群。集群中的每臺服務 器部署一個監控模塊Supervisor，該模塊負責處理客戶端查詢請求，統計服務器運行 狀態。客戶端通過 ZKFramework 連接 ZooKeeper 服務器集群時，首先通過網絡管理 模塊 HttpRequestUtils 向集群中所有服務器發送查詢請求， Supervisor 監控模塊收到請 求后，在服務器執行相應的命令，并將結果反饋到ZKFramework框架，ZKFramework 框架中使用HashMap記錄服務器信息及其響應時間，選擇響應時間最小的服務器進 行連接，如果連接失敗，則從 HashMap 中刪除該服務器信息，繼續進行服務器選擇 連接。
Supervisor監控模塊結構如圖3.5所示，該模塊采用Tornado Web服務器開發， 使用Http方式訪問，實現對ZooKeeper服務器的監控，通過該模塊可以獲取ZooKeeper 服務器端口的 TCP 連接數目、運行負荷和客戶端與服務器之間的網絡延時等信息。
if __name__ == ""__main__"":
tornado.options.parse_command_line()
app = tornado.web.Application(
handlers=[
(r"/", IndexHandler),
(r""/count"", CountHandler), (r"/loadn, LoadHandler), (r"/timen, TimeHandler),
])
http_server = tornado.httpserve i*.H TTPServer(app) http_server.listen(options.port) tornado.ioloop.IOLoop.instance().start()
圖 3.5 Supervisor 監控模塊結構
3.4.4最小服務器負荷的負載均衡策略
最小服務器負荷的負載策略旨在選擇 ZooKeeper 集群中運行負荷最小的服務器 進行連接，以達到充分利用異構服務器性能差異的效果，該策略主要適用于服務器性 能存在較大差異的分布式異構集群。最小服務器負荷的策略采用先統計后連接的方式 優化ZooKeeper客戶端與集群連接過程，其總體架構與圖3.4最佳響應時間策略架構 類似。主要思路是在用戶連接 ZooKeeper 服務器集群前，通過 ZKFramework 向集群 所有服務器發送負荷查詢請求，Supervisor監控模塊收到查詢請求后，利用Linux命 令獲取當前服務器運行負荷，反饋給ZKFramework框架，ZKFramework框架收到服 務器反饋信息后，通過 HashMap 收集統計服務器負荷信息，選擇當前運行負荷最小 的服務器進行連接，如果連接失敗，則重新選擇服務器進行連接，直到連接成功。
3.5 模塊設計
在詳細分析系統總體需求的基礎上，設計云主機管理模塊、云應用環境管理模塊 及云應用自適應失效轉移模塊保證云應用的高可靠性；設計配置信息管理模塊對配置 信息進行統一管理；對系統進行高可靠性設計，保證云平臺配置信息管理系統無單點 故障。
3.5.1 云主機管理模塊設計
為了實現云應用的高可靠性，首先需要對云應用所在的云主機進行管理，使云應 用能夠實時獲取云主機運行狀態，并根據云主機狀態進行相應的邏輯處理。隨著分布 式異構云平臺規模日益擴大，云主機數目也變得非常龐大，統計云主機在線離線情況， 監控其運行狀態有著非常高的意義。
傳統分布式集群管理主要采用基于Agent的管理方式。基于Agent的分布式集群 管理方案中，每個服務器上都會部署一個Agent，然后通過這個Agent向整個集群的 監控中心發送心跳包來判斷服務器在線離線情況。分布式云平臺規模較小時，采用基 于 Agent 的集群管理方案的確是較好的選擇，能夠快速有效地實現云主機的監控管理。 但是，當分布式云平臺規模變大或云應用需求發生變更時，采用傳統基于Agent的分 布式集群管理方式就會出現一些弊端，例如：當遇到大規模升級時，無法自動更新配 置信息而出現升級成本高和難以控制升級進度的問題；此外，采用統一 Agent管理方 式也無法滿足與業務耦合較高的監控需求。
本文云主機管理模塊采用ZooKeeper臨時節點和事件監聽機制，設計云主機上下 線實時通知功能及云主機運行狀態監控功能。云主機管理架構如圖 3.6 所示。
ZooKeepe r集群 云平臺子集群1
圖 3.6 云主機管理架構
由圖3.6可知，云主機主要通過ZKAgent代理服務與ZooKeeper集群進行交互, 完成云主機相關數據的注冊任務。ZooKeeper集群初始化時創建兩個永久節點 /cloud-config/all-servers 和/cloud-config/online-servers，分別存儲云平臺所有云主機信 息和當前在線的云主機信息。ZKAgent代理服務注冊云主機數據時利用云主機IP地 址進行命名，主要分為兩步，第一步在/cloud-config/all-servers節點下創建一個永久子 節點，然后在/cloud-config/online-servres節點下創建一個臨時子節點。ZKAgent代理 服務完成云主機數據注冊后，所有監聽/cloud-config/online-servers節點的客戶端都會 收到云主機上線的通知并進行相關的邏輯處理。與此類似，在云主機宕機后，所有監 聽/cloud-config/online-servers節點的客戶端也會收到云主機下線的通知并進行相關處 理。若云應用對云主機運行狀態有特定需求，則可以通過ZKAgent代理服務更改對 應數據節點的內容，以實時獲取云主機運行狀態信息。
此外，云主機離線統計在大規模云平臺性能測試、容量評估中具有重要作用，采 用上述云主機管理方案，統計離線云主機情況較為容易。
3.5.2 云應用環境管理模塊設計
云應用環境管理以減少人為參與，快速安裝部署云應用環境為目的，利用Docker 容器技術，設計應用環境管理。
傳統的應用服務部署需要經過安裝、配置環境、運行等階段，大規模部署云應用 時采用這種方式很難完成，其難點不僅表現在耗時耗力上，還會出現難以管理、運維 等問題。以Docker為代表的容器技術能夠封裝云應用的開發環境，無需人為參與安 裝、配置環境等階段，大量節約云應用環境部署時間，并且能夠保證云應用環境與用 戶開發測試環境的一致性，非常適合云應用環境管理。云應用環境管理架構如圖 3.7 所示。
圖 3.7 云應用環境管理架構
由圖 3.7 可知，在開發主機上用戶首先從中央倉庫或私有倉庫中下載基礎鏡像， 下載方式可采用命令行或Dockerfile配置文件；由基礎鏡像啟動容器進行開發；開發 完成后，通過 Docker 打標簽的方式將容器保存為一個新的鏡像；檢查私有倉庫是否 正常運行，若正常，則將鏡像推送到私有倉庫，否則，啟動私有倉庫后再進行鏡像推 送；鏡像推送到私有倉庫后，云主機查找下載鏡像，完成云應用部署，實現云應用環 境管理。
3.5.3云應用自適應失效轉移模塊設計
云應用自適應失效轉移模塊是保證云應用高可靠性的核心模塊，該模塊收到云主 機狀態變更消息后，與云平臺進行交互，自動轉移應用服務，實現云應用的高可靠性。
云應用自適應失效轉移模塊的設計主要分為配置、注冊監聽和還原處理三個階段， 其中，配置階段設定云應用在ZooKeeper集群中的相關數據節點，如注冊節點和監聽 節點，同時，設定云應用監聽節點內容變化后的處理類；注冊監聽階段解析配置階段 設定的注冊節點和監聽節點，并通過云應用相關代理服務在ZooKeeper集群的對應節 點下完成注冊和監聽工作；還原處理階段在收到監聽節點的內容變更通知后，通過配 置階段設定的處理類進行還原處理邏輯。
以 Nginx 反向代理 Web 服務的云應用為例，闡述云應用自適應失效轉移模塊的 設計。該云應用包含Web服務和Nginx反向代理服務，不同服務采用不同的Docker 鏡像進行環境管理，并在不同的云主機上部署運行，其相關代理服務處理邏輯也不相 同。云應用在ZooKeeper集群的數據存儲結構如圖3.8所示，在/cloud-config數據節 點下創建與云應用對應的子節點/cloud-config/web，通過該數據節點管理與云應用相 關的數據。例如：在Nginx反向代理服務的部署過程中，配置階段將注冊節點設置為 /cloud-config/web/nginx-servers，將監聽節點設置為/cloud-config/web/web-servers，將 監聽數據發生變化后的處理類為NginxHandler；注冊監聽階段，解析配置階段設置的 注冊節點和監聽節點，在注冊節點/cloud-config/web/nginx-servers下創建子節點完成 注冊工作，并監聽/cloud-config/web/web-servers數據節點；還原處理階段在部署Web 服務的云主機宕機后，利用ZooKeeper臨時節點和事件監聽機制，通知云應用代理服 務，該服務利用 NginxHandler 類處理還原過程。 NginxHandler 自適應失效轉移設計 如圖3.9所示，由圖可知，云應用代理服務收到Web云主機宕機的通知后，通過處理 類NginxHandler，自動修改Nginx配置文件，與云平臺主控制中心交互，申請啟動新 的云主機部署Web服務，Web服務所在云主機啟動后，重新修改Nginx配置文件， 完成自適應失效轉移。
ZooKeeper 集群
圖 3.8 云應用數據儲存結構
云平臺
總控中心
1.下載對應的鏡像
Docke r倉庫
Controller
2.啟動web服務
4.啟動Nginx服務
云平臺子集群1
云平臺子集群2
9.修改Nginx配置信息
&創建新的虛擬機部署web服務
7.修改Nginx配置信息
6. web虛擬機宕機
web1
| WebAgent
web3
| WebAgent]
web2
| WebAgent
nginx2
NginxAgent
ZooKeeper集群
nginx1
NginxAgent
webR
| WebAgent
圖 3.9 自適應失效轉移設計
3.5.4 配置信息管理模塊設計
配置信息管理主要實現云平臺配置信息的統一管理，通過可視化管理界面方便用 戶管理配置信息，實現對用戶透明的配置信息存儲、配置信息變更實時通知及云應用 快速響應等功能，并設計配置信息分組功能，在云應用存在大量配置信息時，使客戶 端能夠以分組的形式訂閱配置信息。
配置信息管理內容主要包含可視化管理界面、變更處理、分組訂閱和配置信息存 儲等，其中，可視化管理界面主要利用 SpringMVC 技術，設計用戶操作接口；變更 處理則利用 ZooKeeper 臨時節點及事件監聽機制，設計配置信息變更實時通知和云應 用快速響應的功能；分組訂閱將組內所有配置信息存放在ZooKeeper集群的一個數據 節點上，通過訂閱該節點實現分組訂閱功能；配置信息存儲則設計云應用配置信息在 ZooKeeper 集群的存儲結構。
配置信息管理架構如圖 3.10 所示，由圖可知，用戶通過可視化界面管理配置信 息；配置信息的創建、修改等操作通過ZKFramework更新到ZooKeeper集群中；變 更處理則通過云應用代理服務接收配置信息變更通知，設計云應用快速響應和配置信 息變更后的邏輯處理。
分組訂閱功能克服單個配置信息獨立訂閱方式在云應用配置信息訂閱數量較大 時存在操作復雜且比較繁瑣的問題。該功能將同組配置信息統一存儲在一個分組節點 下，使客戶端能夠按照分組的形式訂閱配置信息，有效降低訂閱配置信息時的工作量， 實現組內任何配置信息發生變化，云應用都會收到變更通知的效果。
配置信息存儲結構如圖3.11所示，由圖可知，系統首先創建/cloud-config/common 數據節點，用于保存系統中公用的配置信息，然后，根據云應用創建一個與之對應的 數據節點/cloud-config/appid，在該節點下創建/cloud-config/appid/config節點管理配置
信息，配置信息及其分組在/cloud-config/appid/config節點下創建對應的子節點。云應 用訂閱這些數據節點，實現配置信息變更的實時通知功能及應用程序的快速響應能力。
ZooKeeper 集群
圖 3.11 配置信息存儲結構
3.5.5 系統可靠性設計
系統可靠性設計解決云平臺配置信息管理系統單點故障問題，使系統在單臺服務 器宕機的情況下，依舊正常提供服務。
系統可靠性設計采用虛擬IP和Nginx反向代理技術，為用戶提供統一的網絡訪 問地址，通過虛擬 IP 映射兩臺 Nginx 反向代理服務器，當其中一臺發生宕機時，虛 擬 IP 自動映射到另外一臺服務器上，繼續提供服務。當系統可視化管理界面所在云 主機發生宕機或者增加部署可視化管理界面的云主機時，Nginx反向代理服務器通過 監聽ZooKeeper集群中部署Web服務的云主機對應的數據節點，獲取變更通知，自 動修改Nginx反向代理服務器的配置文件，實現系統的可靠性。
系統高可靠設計如圖3.12所示，通過虛擬IP對外提供服務，并映射兩臺Nginx 反向代理服務器。服務器代理的系統可視化管理界面運行在云主機上，且網絡地址等 信息存儲在ZooKeeper集群中。Nginx反向代理服務器從ZooKeeper集群中獲取云主 機網絡地址，然后根據地址信息修改配置文件，啟動服務。
虛擬IP
圖 3.12 系統高可靠設計
3.6 本章小結
本章介紹了所搭建的云平臺總體架構，分析了云平臺配置信息管理系統的需求， 明確了系統要實現的功能，在此基礎上，設計了系統總體架構及ZKFramework框架， 提出了最小服務器負荷和最佳響應時間的負載均衡算法，完成了各個模塊的詳細設計。
第四章 云平臺配置信息管理系統的實現
本章對云平臺配置信息管理系統的具體實現進行描述。首先對 ZKFramework 框 架及最小服務器負荷和最佳響應時間的負載均衡算法實現細節進行闡述，然后，詳細 介紹系統中各個模塊的實現細節。
4.1ZKFramework 實現
4.1.1ZKFramework 使用流程
ZKFramework 框架主要解決分布式異構云平臺使用 ZooKeeper 客戶端連接服務 器時，因無法感知服務器性能及所處地域，無法選擇最佳服務器進行連接，從而導致 配置信息讀取時間較長的問題。ZKFramework增強ZooKeeper客戶端，實現最小服 務器負荷及最佳時間的負載均衡算法，使客戶端能夠選擇更合適的ZooKeeper服務器 進行連接。 ZKFramework 使用流程圖如 4.1 所示。
圖 4.1 ZKFramework 使用流程圖
由圖 4.1 可知，使用 ZKFramework 框架連接 ZooKeeper 集群時，客戶端首先通過 ZKFramworkFactory中builder()方法創建Builder實例，Builder類通過創建者模式實 現，使用者可以根據需求選擇某些參數進行設置，主要參數如表 4.1 所示；參數設置 完成后，調用build()函數，生成ZKFrameworkImpl實例，該實例控制ZooKeeper集 群的連接和數據操作，ZKFrameworkImpl中start()方法負責與服務器集群創建連接, 生成 ZooKeeper 工具包中的 ZooKeeper 實例，數據操作最終由該實例進行處理，釋放 連接時，調用ZKFrameworkImpl中的close()方法完成，集群連接及數據操作結束。
表 4.1 ZKFramework 可選擇參數
參數名稱 描述
sessionTimeout 會話時間
connectString 連接地址
loadBalanceStrategy 負載均衡策略
采用何種負載均衡策略是ZKFramework框架連接ZooKeeper集群時需設置的參 數之一。負載均衡策略以優化客戶端和ZooKeeper服務器集群連接過程為目的，客戶 端與集群連接前，獲取集群中服務器的運行狀態信息，選擇最為合適的服務器進行連 接，減少網絡延時，降低云應用配置信息讀取時間，提高程序性能。負載均衡策略采 用策略模式實現，通過 ZKFramework 框架的 Builder 類進行設置，默認為最佳響應時 間的負載均衡策略。用戶也可以通過LoadBalanceStrategy負載均衡策略接口實現特定 的負載均衡策略，滿足用戶特定需求。
負載均衡策略設置和使用流程圖如 4.2 所示，主要在 ZKFrameworkImpl 中的 start 方法中發揮作用，該方法會調用負載均衡策略中 selectConnectString 方法選擇最佳服 務器連接地址，客戶端利用上述服務器地址連接ZooKeeper集群，如果連接失敗，則 重新進行選擇連接過程。
4.1.2最佳響應時間的負載均衡策略實現
最佳響應時間的負載均衡策略解決客戶端連接多地域 ZooKeeper 集群時存在不 足的問題，其不足主要表現在多臺ZooKeeper服務器部署地理位置相差較遠，客戶端 連接獲取數據時，其響應時間相差較大。最佳響應時間的負載均衡策略使客戶端感知 這種服務器距離，選擇離客戶端較近、響應時間較短的服務器進行連接，減少網絡延 時，優化程序性能。
最佳響應時間負載均衡策略在客戶端與服務器集群連接前，向要連接的服務集群 發送一個查詢數據包，服務器接收到查詢數據包后，向客戶端發送響應數據，客戶端
收集統計所有服務器的響應時間，在響應時間中選擇時間最短的服務器進行連接，實 現服務器距離感知功能。
圖 4.2 負載均衡策略設置和使用流程圖
最佳響應時間的負載均衡策略實現流程圖如4.3所示。圖中， ZKFrameworkFactory 創建 Builder 實例，利用該實例設置負載均衡策略為最佳響應時間負載均衡策略，該 策略首先獲取集群連接地址，地址為逗號分隔的多個網絡地址拼接而成的字符串，對 集群連接地址進行拆分，獲取所有服務器的連接地址，然后，構建HashMap數據結 構，利用該數據結構存儲服務器與響應時間鍵值對， 通過網絡管理模塊 HttpRequestUtils向每臺服務器發送時間查詢請求，服務器監控進程Supervisor接收到 查詢請求后，立即返回響應數據包，客戶端收到各個服務器的響應數據包后，統計總 共使用的時間并存儲，收集所有服務器響應時間，選擇用時最短對應的服務器地址返 回給ZKFrameworklmpl。如果連接失敗，則從HashMap中刪除該服務器信息，繼續 進行服務器選擇連接。
圖 4.3 最佳響應時間的負載均衡策略實現流程圖
4.1.3最小服務器負荷的負載均衡策略實現
最小服務器負荷的負載均衡策略，目的是選擇集群中運行負荷最小的服務器進行 連接，以充分利用異構服務器的性能差異。最小服務器負荷的負載均衡策略實現流程 圖如 4.4 所示，由圖可知， ZKFrameworkFactory 創建 Builder 實例，并利用該實例設 置負載均衡策略為最小服務器負荷的負載均衡策略，該策略與最佳響應時間負載均衡 策略類似，獲取集群連接地址并拆分，得到所有服務器的連接地址集合后，構建 HashMap 數據結構，存儲服務器編號及其負荷大小， 通過網絡管理模塊 HttpRequestUtils向所有服務器發送負荷查詢請求，服務器監控進程Supervisor接收到 負荷查詢請求后，利用linux命令uptime獲取當前服務器運行負荷大小并返回數據， 客戶端收到各個服務器的響應數據后，記錄負荷大小，收集所有服務器負荷大小后， 選擇當前負荷最小的服務器地址返回給ZKFrameworkImpl。如果連接失敗，則從 HashMap 中刪除該服務器信息，繼續進行服務器選擇連接。
圖 4.4 最小服務器負荷的負載均衡策略實現流程圖
4.2 模塊實現
4.2.1 云主機管理模塊實現
基于 ZooKeeper 的云主機管理模塊不僅可以實時獲取云主機上線、下線等情況， 還能夠使云應用實時獲取云主機運行狀態。：
云主機管理流程圖如4.5所示，由圖可知，云平臺根據用戶申請的內存、CPU、 硬盤等信息，使用調度器在云平臺計算節點上啟動云主機，云主機啟動后執行 ZKAgent.sh 腳本，該腳本封裝了 ZKAgent 代理服務的啟動、停止等操作，并與云平 臺總控制中心交互，獲取云應用鏡像。 ZKAgent.sh 腳本啟動云應用鏡像后，執行 ZKAgent 代理服務，由該代理服務完成 ZooKeeper 集群中數據節點的注冊任務。 ZKAgent 代理服務與 ZooKeeper 集群交互時， 會檢查 ZooKeeper 集群中 /cloud-config/all-servers 和/cloud-config/online-servers 數據節點是否被初始化，如果尚
未進行初始化，則先完成相關數據節點的創建過程，再進行云主機注冊任務。在云主 機注冊完成后，通過 ZKAgent 代理服務與 ZooKeeper 集群保持會話連接。若發生宕 機等故障，則云主機與ZooKeeper集群的會話失效，集群中/cloud-config/online-servers 數據節點就會刪除該云主機相關的信息， 然后， 通知所有監聽 /cloud-config/online-servers 數據節點的服務，這些服務收到云主機變更通知后，進行 相應的邏輯處理。
圖 4.5 云主機管理流程圖
4.2.2 云應用環境管理模塊實現
云應用環境管理模塊主要簡化傳統應用部署中安裝、配置環境、運行等一系列需 要人工參與的過程，依賴云應用環境管理模塊，云平臺可以自動配置應用服務的運行 環境，為云應用自適應失效轉移奠定基礎。
云應用環境管理模塊的實現分為搭建 Docker 私有倉庫、構建云應用鏡像和部署 云應用三個步驟。
（1） 搭建 Docker 私有倉庫
Linux服務器通過官方提供的registry鏡像進行倉庫搭建，其具體安裝步驟如下：
1） $sudo apt-get install docker.io
2） $sudo docker pull registry
3） $sudo mkdir -p /opt/data/registry
4） $sudo docker run -d -p 5000:5000 -v /opt/data/registry:/tmp/registry registry
首先，需要安裝docker軟件，然后下載registry鏡像，通過Docker命令運行registry 容器，即可完成 Docker 私有倉庫的搭建。默認情況下，私有倉庫會將用戶鏡像存放 于registry容器內的/tmp/registry目錄下，這樣，當registry容器被刪除后，存放在容 器內的鏡像也會丟失。因此，一般情況下會指定一個本地目錄掛載到容器內的 /tmp/registry目錄下，如本文中將/opt/data/registry掛載到/tmp/registry，從而實現鏡像 的永久存儲。
（2） 構建云應用鏡像
云應用鏡像構建流程圖如4.6所示。由圖可知，用戶開發上傳云應用時，從Docker 中央倉庫或者私有倉庫中下載基礎鏡像，通過Docker命令啟動容器并進行云應用開 發，開發完成后，通過 Docker 打標簽的方式將容器打包成一個新的鏡像，然后，上 傳鏡像到云平臺Docker私有倉庫中。至此，云應用鏡像構建完成。
圖 4.6 云應用鏡像構建流程圖
（3）部署云應用 部署云應用時只需要下載和運行兩個步驟，其中下載是指從中央倉庫或者本地倉 庫中獲取云應用服務的鏡像文件，運行指通過Docker啟動一個容器來運行云應用服 務。云應用部署流程圖如4.7所示。
圖 4.7 云應用運行流程圖
4.2.3云應用自適應失效轉移模塊實現
云應用自適應失效轉移模塊的實現分為配置、注冊監聽和還原處理三個階段， 以 Nginx反向代理Web服務的云應用為例，配置階段設置云應用相關參數；注冊監聽階 段發生在服務部署過程，解析配置階段設置的參數，并與ZooKeeper集群交互，完成 相關數據節點注冊監聽工作；還原處理階段在 Web 服務所在云主機宕機后，自動與 云平臺進行交互，申請新的云主機部署Web服務，并根據新的云主機IP地址自動更 新 Nginx 配置文件，實現自適應失效轉移。
該云應用部署時主要涉及Web服務部署和Nginx反向代理服務部署，兩者部署 過程類似，在此，以Nginx反向代理服務部署為例，闡述其實現過程。云平臺Nginx 反向代理服務部署流程圖如4.8所示，配置階段，設置Nginx反向代理服務的注冊節 點、監聽節點和處理類，將注冊節點設為/cloud-config/web/nginx-servers，監聽節點設 為/cloud-config/web/web-servers，處理類設為NginxHandler；注冊監聽階段，云主機 啟動后自動運行nginxStartUp.sh腳本，獲取Web服務所在云主機的數據，修改Nginx 配置文件，下載 Nginx 鏡像，啟動 NginxAgent 代理服務，由 NginxAgent 代理服務解 析配置階段設置的注冊節點和監聽節點參數，與ZooKeeper交互，完成相關數據注冊 任務，并監聽/cloud-config/web/web-servers數據節點，若數據節點內容發生變化，則 進行還原處理，否則，繼續監聽;還原處理階段由配置階段設定的處理類NginxHandler 進行相應操作。
NginxHandler還原處理實現流程圖如4.9所示。由圖4.9可知，NginxHandler還 原處理階段，收到Web服務所在的云主機變化通知，判斷其數目是否達到最小閾值， 該最小閾值在云應用初始化過程中設定，表示應用中部署 Web 服務的云主機最小數 目，若沒有達到最小閾值，則NginxAgent繼續保持監聽，若達到最小閾值則通過網 絡管理模塊HttpRequestUtils向主控制中心發送申請新的云主機部署Web服務的請求。 總控制中心收到請求后，開啟新的云主機，從Docker私有倉庫中下載Web鏡像，并 啟動服務，在/cloud-config/web/web-servers注冊子節點，此時，監聽該數據節點的 NginxAgent 代理服務收到變化通知，重新獲取 Web 服務所在的云主機信息，自動修 改配置文件，完成自適應失效轉移。
圖 4.8 云平臺 Nginx 反向代理服務部署流程圖
圖 4.9 NginxHandler 還原處理實現流程圖
4.2.4 配置信息管理模塊實現
配置信息管理模塊主要包含可視化管理界面、變更處理、分組訂閱和配置信息存 儲等。變更處理利用ZooKeeper臨時節點和事件監聽機制，實現方法與云主機管理模 塊、云應用自適應失效轉移模塊的監聽變更處理機制類似；分組訂閱將組內所有配置 信息存放在ZooKeeper集群的一個數據節點上，通過訂閱該節點即可完成；配置信息 存儲按其存儲結構將配置信息存儲在ZooKeeper集群即可實現。因此，本節主要介紹 配置信息管理中可視化管理界面的實現。
可視化管理界面實現流程圖如4.10所示，利用SpringMVC框架實現管理操作與 后臺處理分離，分為攔截器、控制器和服務層。攔截器分為非法攔截器和Cookie攔 截器，非法攔截器主要檢測用戶是否登錄，Cookie攔截器將用戶Cookie數據進行整 理提取；控制器分為應用控制器、登錄控制器、節點控制器及分組控制器，不同控制
器處理不同的用戶請求，應用控制器處理用戶在 ZooKeeper 集群創建應用的請求，登 錄控制器處理用戶登錄行為，節點控制器處理操作 ZooKeeper 數據節點的請求，分組 控制器處理配置信息中分組的相關操作；服務層利用 ZKFramework 連接 ZooKeeper 集群，并進行服務接口的封裝工作。
攔截器
Illegallnterceptor Cookieinterceptor
V
控制器
AppController LoginController
NodeController GroupController
A
v
ConfigService
V
ZKFramework
V
ZooKeeper 集群
圖 4.10 可視化管理界面實現流程圖
可視化管理處理時序圖如 4.11 所示。
ZKFrameowork
5. 操作數據
L 6.返回結果j
I I
圖 4.11 可視化管理處理時序圖
圖 4.11 中，用戶通過界面發送操作請求，非法攔截器判斷用戶是否合法，如果 非法，返回，否則，通過 Cookie 攔截器整理提取用戶數據，方便后續使用；根據請 求地址，選擇不同的控制器進行處理，控制器通過服務層 ConfigService 進行具體的 服務操作；服務層通過 ZKFramework 連接 ZooKeeper 集群，操作完成后，將操作結 果數據返回給用戶。
4.2.5 系統可靠性實現
系統可靠性實現主要利用虛擬IP和Nginx反向代理技術，解決云平臺配置信息 管理系統單點故障問題，使系統在單臺服務器宕機的情況下，依舊正常提供服務。
系統通過虛擬 IP 對外提供服務，采用該機制，可以有效隔離具體服務器，實現 了統一訪問的效果。系統高可靠性實現流程圖如4.12所示。
圖 4.12 系統高可靠性實現流程圖
由圖4.12可知，首先需完成虛擬IP與Nginx反向代理服務器的映射表的配置工 作，完成配置后，用戶通過虛擬IP訪問系統，并解決Nginx反向代理服務器出現單 點故障的問題。Nginx反向代理服務器開機后，執行nginxStartUp.sh腳本，該腳本負 責從 Docker 倉庫中獲取 Nginx 鏡像，然后通過 NginxAgent 代理服務從 ZooKeeper 集 群中獲取系統可視化管理界面所在云主機地址信息，根據該地址信息修改 Nginx 配置 文件，啟動容器，提供服務。Nginx服務啟動后，通過NginxAgent代理服務監聽 ZooKeeper 集群中系統界面所在云主機的數據節點，若數據節點內容發生變化，則修 改Nginx配置文件，并重新啟動Nginx服務，若數據節點內容未發生變化，則繼續保 持監聽。
4.3 本章小結
本章詳細介紹了 ZKFramework 框架的實現細節，并對最小服務器負荷和最佳響 應時間的負載均衡策略進行闡述，增強了 ZooKeeper 客戶端，使其適應分布式異構云 平臺使用，同時，描述了系統中各個模塊的實現流程。
第五章 實驗與測試
本章主要對云平臺配置信息系統進行測試，主要分為ZooKeeper集群部署、系統 功能測試和性能測試。
5.1ZooKeeper 集群部署
為了實現配置信息的分布式存儲、容錯能力及快速讀取的能力，系統采用多地域、 多服務器角色的ZooKeeper集群部署方案，使系統能夠在單臺服務器宕機或某個區域 ZooKeeper集群宕機的情況下依舊提供正常的服務。ZooKeeper集群部署方案如圖5.1 所示：
地域1
圖 5.1 ZooKeeper 集群部署方案
如圖5.1所示，在地域1部署三臺服務器，這些服務器都參與集群投票過程，在 地域2部署兩臺服務器，其角色被設置為Observero兩地集群通過IPv4 Over IPv6隧 道技術連接，其基本原理是以IPv6做為隧道底層封裝協議承載上層IPv4報文，隧道 的入口節點對收到的IPv4報文進行封裝，隧道的出口節點完成報文的解封裝工作。 采用上述集群部署方案主要優點如下：
（1）高效的讀寫性能
ZooKeeper 集群服務器分為參與投票和不參與投票兩種類型，每一次數據寫入需 要參與投票的服務器中投票通過數目超過一半才能完成。若上述集群部署方案中的所 有服務器都參與投票，則集群的寫性能會因兩地網絡延時而下降。因此，設置地域 2 服務器為Observer角色，使該地域服務器不參加投票過程，在不影響寫操作性能的 情況下，分擔讀請求的流量，提高本地讀請求速度。
（2） 無單點故障
ZooKeeper集群中服務器宕機數目只要小于集群服務器總數一半就能正常提供 服務，在上述部署結構中，兩地子集群都不存在單點故障。
（3） 跨地域的容錯功能
設置地域2服務器為Observer角色，一方面提高用戶對配置信息讀取性能，另 一方面實現跨地域的容錯功能，滿足地域2整個子集群發生故障后，云平臺配置信息 管理系統依舊能夠提供正常服務。
5.2 系統功能測試
云平臺配置信息管理系統主要包含配置信息管理功能和云應用高可靠性功能，本 文分別對其進行測試。
5.2.1 配置信息管理測試
配置信息管理的測試主要是測試云平臺配置信息管理系統是否能夠正常運行、是 否能夠新增配置信息分組、是否能夠對配置信息進行管理，主要測試方法是登錄系統、 新增配置信息分組、新增配置信息，查看可視化管理界面是否正常顯示。
測試流程為：用戶啟動瀏覽器，輸入 192.168.10.4:8080/login 地址，進入圖 5.2 所示的系統登錄界面，輸入用戶名及密碼，登錄系統，選擇菜單中的分組管理，點擊 新增分組，創建 webapp 分組，分組創建成功，如圖 5.3 所示，選擇菜單中的配置信 息，點擊新增配置，創建配置信息，選擇配置信息分組為webapp，輸入配置信息名 稱為name，值為cloudwebapp，配置信息創建成功，如圖5.4所示。在整個操作過程 中，可視化管理界面未見異常，功能處理邏輯正常運行，測試完成。
圖 5.2 系統登錄界面
圖 5.3 分組管理界面
圖 5.4 配置信息管理界面
5.2.2 云應用高可靠性測試
云應用高可靠性的測試主要以Nginx反向代理Web服務為例，闡述測試過程， 測試當Web云主機宕機時，系統是否能夠自動部署新的Web云主機，并根據云主機 IP地址自動修改Nginx配置文件，重啟Nginx服務，整個過程無需人為參與。
具體測試步驟如下：在云平臺主控制中心啟動 startController.sh 腳本，該腳本負 責處理申請虛擬機操作、獲取 Docker 鏡像名稱、獲取云主機網絡地址等，啟動后效 果如圖 5.5 所示；在云平臺部署三臺 Web 云主機和一臺 Nginx 云主機，其中，三臺 Web 云主機對應 IP 地址為：192.168.10.115、192.168.10.116 和 192.168.10.117, Nginx 云主機IP地址為192.168.10.100，部署效果如圖5.6所示，每臺云主機都包含云平臺 配置信息管理相關腳本，腳本如圖5.7所示，Web云主機開機自動運行webStartUp.sh 腳本，完成ZooKeeper集群中相關數據節點注冊，數據節點內容如圖5.8所示，Nginx 云主機開機自動運行 nginxStartUp.sh 腳本，獲取 Web 服務器數據，修改 Nginx 配置 文件，啟動Nginx服務，執行過程如圖5.9所示，在ZooKeeper集群完成相關數據節 點注冊，注冊結果如圖5.10所示；通過網絡地址為192.168.10.117的Web云主機關 機模擬云平臺運行過程中Web云主機宕機情況，Nginx云主機收到Web云主機關機 的消息后，與主控中心交互，申請啟動新的云主機部署Web服務，根據新的Web云 主機IP地址修改配置文件，修改過程如圖5.11所示，配置文件中代理的Web服務器 地址被自動修改為最新云主機的地址，配置文件變化如圖 5.12 所示，還原后的 Web 云主機情況如圖5.13所示，ZooKeeper集群Web數據節點內容更新為最新的Web云 主機地址，如圖5.14所示。測試過程無異常發生，完成Web云主機自動部署、Ngnix 配置文件自動修改等功能，測試完成。
ubuntu^control:-/cloud-config-controller$ Is
controller.py c reds startControll巳「?sh
ubuntu迫control:~/cloud-config?controller$ ./startcontroller.sh starting vm now
743e020e ?8732?401:e -b6b0c62f9c:03
[I 170323 11:54:44 web : 1946] 20G GET
[I 170323 11:54:44 web : 1946] 200 GET
[I 170323 11:55:14 web : 1946] 200 GET
[I 170323 11:55:47 web : 1946] 200 GET
[I 170323 11:55:48 web : 1946 ] 200 GET
/startwebvm?port=2181 (192.168.10.100) 5637.25ms /getnginxdockername (192.168.10.100) 0.56ms /getwebdockernmme (192.168.10.110) 0.67ms /getvmip?port=2181 (192.168.10.110) 0.68ms /getvmip?port=2181 (192.168.10.110) Q.41ms
圖 5.5 startController.sh 啟動效果
C O Q 192.168.10.51/horizon/project/instances/
☆ GB
圖 5.6 云主機部署結果
root@ubuntu：~/cloud-config# root(aubuntu：-/cloud-config# Is bin cloud-config-core.jar config roottaubuntu：-/cloud-config# cd bin/ root©ubuntu:-/cloud-config/bin# Is nginxStartUp.sh webStartUp.sh ZKAgent.sh roottaubuntu ：~/cloud-confiq/bin#
圖 5.7 配置信息管理腳本
[zk: localhost:2181(C0NNECTED) 20]
[zk: localhost:2181(C0NNECTED) 20] Is /cloud-config/web/web-servers
[192.168.10.115, 192.168.10.116, 192.168.10.117]
圖 5.8 Web 數據節點內容
cloud-config -• cloud-config -• tiated timeout
>INFO{ClientCnxn.java:876} --> Socket connection established to 192.168.1.13/192.168.1.13:2181, initiating session
>INFO{ClientCnxn.java:1299} Session establishment deplete on server 192.168.1.13/192.168.1.13:2181, sessionid = Oxl5afaad7f710607, nego =5000
>INF0{NginxAgent.java:99} -> watchedNode list updated:[192.168.10.115, 192.168.16.116, 192.168.19.117]
>INFO{NginxAgent.java:164} try to set Handler to rtginxagent.ChangeConfigFileHandler
>INFQ{NginxAgent.java：1G7} try to set Handler to nginxagent.ChangeConfigFileHandler
>INFO{NginxAgent.java:122} -■> set Handler to nginxagent.ChangeConfigFileHandler
>INFO{ChangeConfigFileHandler.java:31} change nginx configure file
>INFO{ChangeConfigFileHandler.java:61} current backend web server is [192.168.10.115, 192.168.10.116, 192.168.10.117]
>INFO{ChangeConfigFileHandler.java：62} --> begin fix the nginx configure file
>INFO{ChangeConfigFileHandler.java:46} fix nginx configure file over
>INFO{NginxAgent.java:179} register online server node 192.168.10.100 success
>INFQ{NginxAgent.java：183} all server node exists
>INFO{NginxAgent.java:196} --> register server node /cloud-config/web/nginx-servers/192.168.10.1B0 success
圖 5.9 nginxStartUp.sh 執行過程
[zk: localhost:2181(C0NNECTED)
[zk: localhost:2181(C0NNECTED)
[192.168.10.100]
[zk: localhost:2181(C0NNECTED)
25]
25] Is /cloud?config/web/nginx-servers
26]
圖 5.10 Nginx 數據節點內容
cloud-config INrO{ChangeConfigFileHandler.]ava:62} begin fix the nginx configure file
cloud-config INF0{ChangeConfigFileHandler.java:46} ■•> fix nginx configure file over
cloud-config INFOfNginxAgent.java：90} watchedNode list updated:[192.168.18.115, 192.168.IS.116, 192.168.IS.118]
cloud-config INFO{NginxAgent.java:104} try to set Handler to nginxagent.ChangeConfigFileHandler
cloud-config INFO{NginxAgent.java:107}八a try to set Handler to nginxagent.ChangeConfigFileHandler
cloud-config INFO{NginxAgent.java:122} set Handler to nginxagent.ChangeConfigFileHandler
cloud-config INFOfChangeConfigFileHandler.java:31} change nginx configure file
cloud-config INFO{ChangeConfigFileHandler.java:61} current backend web server is [192.168.16.115, 192.168.10.116, 192.168.19.118]
cloud-config --> INFO{ChangeConfigFileHandler.java:62} --> begin fix the nginx configure file
cloud-config --> INFO{ChangeConfigFileHandler.java:46} --> fix nginx configure file over
I
圖 5.11 Nginx 配置文件修改過程
upstream backend { server 192.168.10.115; server 192.168.10.116; server 192,168.10.117;
1
upstream backend {
server 192.168.10.115;
server 192.168.10.116;
server 192.168.10.118;
1
(b)修改后
圖 5.12 Nginx 配置文件變化
圖 5.13 還原后的 Web 云主機
[zk: localhost:2181(C0NNECTED) 29]
[zk: localhost:2181(CONNECTED) 29] Is /cloud config/web/web servers [192.168.10.118, 192.168.10.115, 192.168.10.116]
[zk: localhost:2181(C0NNECTED) 30]
圖 5.14 Web 數據節點最新內容
5.3 系統性能測試
云平臺配置信息管理系統性能測試主要對讀取配置信息的時間進行測試，采用 ZKFramework 框架，系統能夠選擇最近或者響應時間最佳的服務器進行連接，降低 網絡延時，減少讀取配置信息的時間。
本文對云平臺配置信息管理系統中配置信息讀取速度進行仿真測試，其測試方案 為：部署擁有五臺服務器的ZooKeeper集群，其中，三臺服務器參與投票過程，地址 分別為192.168.10.5、 192.168.10.6和192.168.10.7，兩臺服務器不參與投票過程，地 址分別為192.168.10.8和192.168.10.9,利用Linux流量控制工具TC模擬仿真網絡延 時，設定192.168.10.5、192.168.10.6和192.168.10.7三臺服務器具有相同的網絡延時， 模擬其跨地域的特征。分別在 5ms、 10ms、 15ms 和 20ms 的網絡延時下，測試自帶 客戶端與 ZKFramework 框架連接地址分配情況和兩者讀取配置信息的時間。每種延
時下，每隔1000ms啟動一個線程進行連接，連接100次，每次連接讀取100次配置 信息，統計配置信息讀取平均耗時。配置信息讀取時間結果如表 5.1 所示：
表 5.1 配置信息讀取時間
網絡 延時 連接 方式 服務器連接個數分配 平均 用時 提咼 百分比
(%)
192.16 &
10.5 192.168.
10.6 192.16 &
10.7 192.168.
10.8 192.16 &
10.9
0ms 自帶 客戶端 19 24 17 24 16 2.23 11.7
ZKFrame- work 17 26 13 26 18 1.97
5ms 自帶 客戶端 26 17 23 23 11 4.82 53.7
ZKFrame- work 0 3 2 55 40 2.23
10ms 自帶 客戶端 17 19 21 29 14 9.05 74.5
ZKFrame- work 0 0 1 57 42 2.31
15ms 自帶 客戶端 20 19 16 23 22 14.35 85.7
ZKFrame- work 0 0 0 55 45 2.05
20ms 自帶 客戶端 21 16 20 17 26 18.21 8&9
ZKFrame- work 0 0 0 56 44 2.03
如表5.1所示，網絡延時為0ms、5ms、10ms、15ms和20ms時，配置信息讀取 性能分別提高了 11.7%、 53.7%、 74.5%、 85.7%和 88.9%，有效降低了網絡延時對配 置信息讀取性能的影響。
5.4 本章小結
本章對支持系統運行的ZooKeeper集群進行了搭建，完成了系統功能測試和性能 測試，測試結果表明，系統功能和性能達到要求。
第六章 結論與展望
6.1 研究結論
本文深入研究了配置信息管理系統，分析了云平臺配置信息管理需求，針對現有 的配置信息管理系統因無法實時獲取云主機狀態變更信息，無法保證云應用的高可靠 性而不適合云平臺使用的問題，詳細設計并實現了一個云平臺配置信息管理系統，優 化了 ZooKeeper客戶端與集群連接過程，完成了系統測試，本文主要完成的工作如下：
（1） 解決了云應用高可靠性及配置信息管理等問題 對云平臺應用高可靠進行了深入研究，提出了云主機管理、云應用環境管理及云
應用自適應失效轉移模塊，實現了云應用的高可靠運行；采用了 ZooKeeper臨時節點 及事件監聽機制，完成了云應用配置信息管理中信息變更實時通知、云應用快速響應、 云主機變更實時通知等功能。
（2） 增強了 ZooKeeper 客戶端在分布式異構集群中的適應性
ZooKeeper無法感知分布式異構集群中服務器性能差異及所屬地域。針對這種不 足，本文提出了 ZKFramework 框架，優化了異構集群中 ZooKeeper 連接分配的過程， 提出了最小服務器負荷和最佳響應時間的負載均衡策略，增強了 ZooKeeper客戶端在 分布式異構集群的適應性。
（3） 設計實現了云平臺配置信息管理系統 對系統總體需求及功能需求進行了詳細的分析，在此基礎上，設計實現了配置信
息管理模塊、云主機管理模塊、云應用環境管理模塊、云應用自適應失效轉移模塊， 保證了云應用高可靠性，實現了配置信息管理功能，并對系統的可靠性進行了設計實 現。
6.2 研究展望
本文深入研究現有的配置信息管理系統，針對系統存在的不足，研究實現了一個 云平臺配置信息管理系統，系統實現后，進行下一步展望：
（1） 優化云主機的創建過程 本文在云應用自適應失效轉移模塊的實現過程中，發現云主機創建速度時快時慢，
對此，可以進一步優化云主機的創建過程。
（2） 研究云平臺網絡管理
系統中主要利用云主機的浮動IP進行通信，然而，云主機內部直接獲取本機浮
動 IP 存在困難，需與外部發生交互才能得到，后續可以進一步研究云平臺網絡管理。
（3）將 Docker 與云計算結合
系統利用Docker實現了云應用環境管理模塊，Docker由于其輕量、移植性強等 特性，受到了廣泛的應用，下一步可以在 Docker 與云計算結合方面進行更深入的研 究。
（4）擴展負載均衡算法 系統中提供了最佳響應時間和最小服務器負荷兩個獨立的負載均衡策略，擴展負 載均衡算法，使系統能夠先選出最佳響應時間范圍內的服務器群組，再按照最小服務 器負荷的負載均衡策略選擇最合理的服務器。
參考文獻
[1]Almorsy M, Grundy J, Muller I. An analysis of the cloud computing security problem[J]. arXiv preprint arXiv:1609.01107, 2016.
[2]Zuniga - Prieto M, Gonzalez - Huerta J, Insfran E, et al. Dynamic reconfiguration of cloud application architectures[J]. Software: Practice and Experience, 2016.
[3]Barroso L A, Clidaras J, Holzle U. The datacenter as a computer: An introduction to the design of warehouse-scale machines[J]. Synthesis lectures on computer architecture, 2013, 8(3): 1-154.
[4]Rabkin A, Katz R H. How hadoop clusters break[J]. IEEE software, 2013, 30(4): 88-94.
[5]Yuan D, Luo Y, Zhuang X, et al. Simple Testing Can Prevent Most Critical Failures: An Analysis of Production Failures in Distributed Data-Intensive Systems[C]. OSDI. 2014: 249-265.
[6]Oppenheimer D, Ganapathi A, Patterson D A. Why do Internet services fail, and what can be done about it?[C]. USENIX symposium on internet technologies and systems. 2003, 67.
[7]Gunawi H S, Hao M, Leesatapornwongsa T, et al. What bugs live in the cloud? a study of 3000+ issues in cloud systems[C]. Proceedings of the ACM Symposium on Cloud Computing. ACM, 2014: 1-14.
[8]Oliveira F, Nagaraja K, Bachwani R, et al. Understanding and Validating Database System Administration[C]. USENIX Annual Technical Conference, General Track. 2006: 213-228.
[9]Thomas K. Thanks, Amazon: The Cloud Crash Reveals Your Importance[J]. 2011.
[10]Brodkin J. Why Gmail went down: Google misconfigured load balancing servers[J]. 2012.
[11]Miller R. Microsoft: Misconfigured Network Device Caused Azure Outage[J]. 2012.
[12]Liang L Y. Linkedin. com inaccessible on Thursday because of server misconfiguration[J]. 2013.
[13]Mohammed B, Kiran M, Awan I U, et al. An Integrated Virtualized Strategy for Fault Tolerance in Cloud Computing Environment[C]. Ubiquitous Intelligence & Computing, Advanced and Trusted Computing, Scalable Computing and Communications, Cloud and Big Data Computing, Internet of People, and Smart World Congress (UIC/ATC/ScalCom/CBDCom/IoP/SmartWorld), 2016 Intl IEEE Conferences. IEEE, 2016: 542-549.
[14]Kan C. DoCloud: An elastic cloud platform for Web applications based on Docker[C]. Advanced Communication Technology (ICACT), 2016 18th International Conference on. IEEE, 2016: 478-483.
[15]Xu T, Zhou Y. Systems approaches to tackling configuration errors: A survey[J]. ACM Computing Surveys (CSUR), 2015, 47(4): 70.
[16]Bauer L, Garriss S, Reiter M K. Detecting and resolving policy misconfigurations in access-control systems[J]. ACM Transactions on Information and System Security (TISSEC), 2011, 14(1): 2.
[17]Shambaugh R, Weiss A, Guha A. Rehearsal: a configuration verification tool for puppet[C]. Proceedings of the 37th ACM SIGPLAN Conference on Programming Language Design and Implementation. ACM, 2016: 416-430.
[18]Preston S. Using Chef Provisioning to Provision Machines[M]. Using Chef with Microsoft Azure. Apress, 2016: 71-99.
[19]Wettinger J, Andrikopoulos V, Leymann F, et al. Middleware-oriented Deployment Automation for Cloud Applications[J]. IEEE Transactions on Cloud Computing, 2016.
[20]Qihoo360/QConf [EB/OL]. https://github.com/Qihoo360/QConf, 2016-1-10
[21]ireaderlab/zkdash [EB/OL]. https://github.com/ireaderlab/zkdash, 2016-1-10
[22]knightliao/disconf [EB/OL]. https://github.com/knightliao/disconf, 2016-1-13
[23]takeseem/diamond [EB/OL]. https://github.com/takeseem/diamond, 2016-1-15
[24]黃毅斐.基于ZooKeeper的分布式同步框架設計與實現[D].浙江：浙江大學,2012.
[25]Junqueira F, Reed B. ZooKeeper: distributed process coordination[M]. " O'Reilly Media, Inc.", 2013.
[26]譚玉靖.基于ZooKeeper的分布式處理框架的研究與實現[D].北京：北京郵電大學,2014.
[27]倪超.從Paxos到Zookeeper:分布式一致性原理與實踐[J]. 2015.
[28]Mell P, Grance T. The NIST definition of cloud computing[J]. 2011.
[29]Youseff L, Butrico M, Da Silva D. Toward a unified ontology of cloud computing[C]. Grid Computing Environments Workshop, 2008. GCE08. IEEE, 2008: 1-10.
[30]董健康，王洪波，李陽陽,程時端.IaaS環境下改進能源效率和網絡性能的虛擬機放置方法[J]. 通信學報,2014,(01):72-81.
[31]魏豪,周抒睿，張銳，楊挺，王千祥.基于應用特征的PaaS彈性資源管理機制J].計算機學 報,2016,(02):223-236.
[32]孫鵬.面向SaaS應用的多租戶海量存儲系統設計與實現[D].浙江：浙江大學,2010.
[33]Ismaeel S, Miri A, Chourishi D, et al. Open source cloud management platforms: A review[C]. Cyber Security and Cloud Computing (CSCloud), 2015 IEEE 2nd International Conference on. IEEE, 2015: 470-475.
[34]于飛.基于openNebula云平臺實現及性能評估[D].北京：北京郵電大學,2013.
[35]張帆，李磊，楊成胡，陳麗珍.基于Eucalyptus構建私有云計算平臺[J].電信科 學,2011,(11):57-61.
[36]王敏訥.基于cloudstack的虛擬機部署方案的研究與實現[D].北京：北京郵電大學,2015.
[37]Chandrasekaran K. Essentials of cloud computing[M]. CRC Press, 2014.
[38]Hunt P, Konar M, Junqueira F P, et al. ZooKeeper: Wait-free Coordination for Internet-scale Systems[C]. USENIX annual technical conference. 2010, 8: 9.
[39]Skeirik S, Bobba R B, Meseguer J. Formal analysis of fault-tolerant group key management using ZooKeeper[C]. Cluster, Cloud and Grid Computing (CCGrid), 2013 13th IEEE/ACM International Symposium on. IEEE, 2013: 636-641.
[40]Docker [EB/OL]. https://www.docker.com, 2016-2-20.
[41]仇臣.Docker容器的性能監控和日志服務的設計與實現[D].浙江：浙江大學,2016.
[42]馮明振.基于macvlan的Docker容器網絡系統的設計與實現[D].浙江：浙江大學,2016.
[43]Berlich R, Hug S, Hackerb S, et al. Seamless Integration of Docker-based Applications into Linux Servers[C]. International Symposium on Grids and Clouds. 2016, 13(18).
[44]馬越,黃剛.基于Docker的應用軟件虛擬化研究[J].軟件,2015,(03):10-14.
[45]劉熙，胡志勇.基于Docker容器的Web集群設計與實現[J].電子設計工 程,2016,(08):117-119.
[46]劉思堯，李強，李斌.基于Docker技術的容器隔離性研究[J].軟件,2015,(04):110-113.
下一篇：沒有了
相關標簽:
