本文是一篇決策模擬論文，本文提出了一種結合軟件模擬和實際測試模擬的分布式集群模擬方法，它設計的目的在于輔助分布式任務執(zhí)行集群的開發(fā)，特別是為了使普通開發(fā)者能在資源受限的情況下模擬分布式集群在大規(guī)模的場景表現(xiàn)。
第1章緒論
1.1研究背景及意義
近年來，云計算作為一種新興趨勢受到服務提供商和用戶的大量關注。伯克利的報告指出，云計算將大幅改變現(xiàn)有的IT產業(yè)[1]。在云計算中，算力資源、存儲資源、應用程序等計算資源可以通過網絡按照現(xiàn)用現(xiàn)付的模式提供給用戶[2]。在該模式下數(shù)據(jù)中心可以將計算資源整合起來，通過按需使用的方式提供給眾多用戶，從而高效地利用計算資源。
云計算的發(fā)展當中出現(xiàn)了多種云服務形式。最先出現(xiàn)的服務形式是基礎設施即服務(IaaS)，在此模式下云服務商可以幫助用戶維護服務器，數(shù)據(jù)庫，網絡環(huán)境等IT基礎設施。為了使服務變得更加方便以及提高計算資源的利用效率，云計算領域又先后提出了平臺即服務(PaaS)以及軟件即服務(SaaS)的概念，在PaaS模式下用戶不再需要關心底層基礎設施,也無需自行配置運行環(huán)境。云服務商提供一個應用運行平臺，用戶可以基于該運行平臺運行自身應用。而在SaaS下用戶更是無需自行編寫應用，云服務商直接提供軟件服務。在Paas和SaaS模式當中，云計算中心的資源調度的單位變成了應用。在實際當中，這些應用常常依托于容器化技術，容器化應用可以方便地在不同物理節(jié)點間遷移，相比于虛擬機的形式，容器化應用可以在一臺主機上高密度部署，使得資源利用率更高。由于容器化應用的啟動停止比虛擬機形式更加靈活，容器化應用在水平擴容方面更加有優(yōu)勢。在應用請求的高峰期，容器化應用可以生成更多副本，而在請求相對空閑期減少應用的副本數(shù)。容器化應用的提交，結束等動作更加頻繁，系統(tǒng)的調度請求更加密集。相比于IaaS模式，這些模式對調度系統(tǒng)的要求有所不同。伴隨著Serverless的趨勢[3]，F(xiàn)aaS作為一種更靈活的方式,在云服務中得到廣泛應用[2]。在該模式下資源管理單位從完整的單體應用變成了更細粒度的函數(shù)。
.........................
1.2國內外研究現(xiàn)狀
在調度集群的設計領域，目前有多種架構類型的調度集群架構。比較典型的有集中式調度、共享狀態(tài)式調度和去中心化調度。集中式調度采用單一的中央調度器來管理整個集群的資源和任務調度。所有的節(jié)點和應用都需要與中央調度器交互,匯報自身狀態(tài)并接收調度決策。其優(yōu)點在于其架構相對簡單,便于管理和推理全局狀態(tài)以及更容易實現(xiàn)復雜的調度策略和規(guī)則。其缺點在于其中央調度器可能會成為單點故障。當集群規(guī)模擴大時,中央調度器可能會成為性能瓶頸。集中式調度集群的代表有Apache Hadoop YARN[5]，Apache Mesos[6],以及Spark[7]原生的調度系統(tǒng)。共享狀態(tài)調度架構引入了多個相互協(xié)作的調度器實例,通過共享集群狀態(tài)來進行分布式調度決策。每個調度器實例都可以獨立運行,并且訪問集群的全局狀態(tài)。其優(yōu)點在于其提高了可伸縮性和容錯性,無單點故障，在不同調度器實例可以應用不同的調度策略。其缺點需要一個外部高可用的狀態(tài)存儲系統(tǒng)(如Zookeeper[8])來存儲集群狀態(tài)，并且狀態(tài)共享和一致性協(xié)議可能會增加集群設計的復雜性。共享狀態(tài)集群的代表有Google Omega,獨立部署etcd且有多個apiserver的Kubernetes集群。去中心化調度采用完全分布式的架構,沒有中央調度器或集群狀態(tài)存儲。每個節(jié)點都是獨立的調度器,只根據(jù)本地信息做出調度決策。
.......................
第2章相關工作與研究
2.1常見調度系統(tǒng)架構
目前常見的調度系統(tǒng)架構有集中式調度架構，共享狀態(tài)式調度架構，去中心化式調度架構。下面將介紹這些架構的典型代表。此外，由于調度系統(tǒng)的復雜性，一些調度可能是混合架構的設計，融合了多種類型架構的優(yōu)勢，這些調度集群的存在說明在調度系統(tǒng)領域架構的差異性是相當豐富的,正是由于這些架構的差異性所在，導致了目前很少有適合的研究工具公平對比這些架構調度系統(tǒng)的性能差異。
2.1.1集中式調度架構
集中式調度是最常見的調度架構，它具有簡單性，一致性，資源集中管理的優(yōu)勢。但是該架構的調度集群容易因為單節(jié)點故障導致系統(tǒng)失效，并且容易由于集群規(guī)模擴展而出現(xiàn)單節(jié)點性能瓶頸[20]。中心化的調度架構被廣泛應用在大型的集群管理系統(tǒng)當中，包括Hadoop Yarn[5],Quincy[21]，F(xiàn)irmament[22]和Gemini[23]。

決策模擬論文怎么寫

Apache Hadoop YARN是Apache Hadoop生態(tài)系統(tǒng)的一個關鍵組件，用于集群資源的管理和任務調度。YARN的目標是提供一個通用的、可擴展的資源管理平臺，使得Hadoop能夠運行更廣泛的應用程序，而不僅僅局限于MapReduce。在YARN當中其管理集群資源的核心是ResourceManager，其部署在YARN集群的主節(jié)點當中，與此對應的是部署在工作節(jié)點的NodeManager。當外部的客戶端向YARN申請資源時，ResourceManager會根據(jù)其所有工作節(jié)點的信息，向合適的NodeManager發(fā)送資源分配請求。部署在工作節(jié)點上的NodeManager會需要定時地向ResourceManager返回自身節(jié)點的狀態(tài)信息。
............................
2.2調度集群的軟件模擬
軟件模擬方案相比實際模擬方案需要的計算資源更低，測試的運行更為方便，但缺點是軟件模擬在構造上與實際生產環(huán)境的差異較大，調度集群的研究在軟件模擬中取得的效果缺少可信度。
2.2.1離散事件驅動模擬
離散事件模型可以逐個事件地動態(tài)模擬現(xiàn)實世界,并生成詳細的表現(xiàn)報告，它廣泛地用于各種模擬當中[30]。GridSim[13],CloudSim[12]以及其派生的集群模擬器以SimJava[31]為底層模擬框架，SimJava以離散事件模型為核心。圖2.4描述了離散事件驅動的模型。
離散事件驅動的核心概念是事件循環(huán)機制。事件循環(huán)的名稱的由來在于其算法本身是一個循環(huán)執(zhí)行事件結構。如圖2.4所示，事件循環(huán)開始前會進行初始化模擬系統(tǒng)的時間，集群狀態(tài)和事件列表。在事件循環(huán)機制下，集群狀態(tài)是包含集群中調度節(jié)點，工作節(jié)點的狀態(tài)，這些狀態(tài)又包含了任務隊列的狀態(tài)，工作節(jié)點運行任務的狀態(tài)。事件列表又被稱為未來事件列表(FEL)，未來事件列表代表著在集群未來會發(fā)生的事件，值得注意的是未來事件集在模擬過程中是可以被不斷修改的。這些事件在列表中以時間順序排隊。在開始時,該任務隊列會加入一些初始的事件。該列表中頭部事件就是下一個集群要發(fā)生的事件。事件循環(huán)會重復執(zhí)行最新的事件,當執(zhí)行一個事件后，集群的狀態(tài)會得到修改，同時事件集本身也有可能得到更改，該更改包括事件增加，事件內容修改，事件刪除。從事件集本身可以修改看出，某個時刻下，模擬器的未來事件集并不代表該集群的未來執(zhí)行完全按照事件集進行。事件集和集群狀態(tài)共同組成模擬器的狀態(tài)，模擬器的狀態(tài)只會由于事件的修改而修改，下一個執(zhí)行的事件是確定的，即事件列表最前的事件。事件的執(zhí)行會修改集群的狀態(tài)，并會影響后續(xù)事件的狀態(tài)。
.....................................
第3章 雙模擬方式并行的分布式調度集群模擬方法 ........................ 18
3.1 模擬方法概述 ...................... 18
3.2 基于Actor模型的分布式任務調度系統(tǒng)描述方法 ..................... 19
第4章 大規(guī)模分布式調度集群模擬系統(tǒng)設計 ....................... 35
4.1 設計目標及解決辦法 ..................... 35
4.2 模擬框架整體架構設計........................ 36
第5章 模擬系統(tǒng)的功能測試以及可靠性驗證 ....................... 55
5.1 實驗環(huán)境配置 ................................ 55
5.1.1 軟件模擬模式的實驗平臺 ......................... 55
5.1.2 實際部署模擬模式的實驗平臺 ........................ 55
5.1.3 調度集群算法與參數(shù)配置 .......................... 56
第5章模擬系統(tǒng)的功能測試以及可靠性驗證
5.1實驗環(huán)境配置
本模擬支持兩種模式的集群模擬測試，因此本文為本模擬器的功能測試以及可靠性驗證準備了兩套測試環(huán)境。它們分別是軟件模擬模式測試使用的單機環(huán)境，以及實際部署化模擬模式下的Kubenetes集群實驗環(huán)境。
5.1.1軟件模擬模式的實驗平臺
在模擬器的軟件模擬模式中，本文使用機器配置如下所示：•CPU:AMD R5 3600 [email protected]•內存：16GB•硬盤:1TB SSD在模擬器的軟件模式中使用的軟件環(huán)境如下•操作系統(tǒng)：Ubuntu:22.04•軟件版本：Go:1.21 Python:3.10 Make:4.3

決策模擬論文參考

..............................
第6章總結和展望
6.1本文工作總結
本文提出了一種結合軟件模擬和實際測試模擬的分布式集群模擬方法，它設計的目的在于輔助分布式任務執(zhí)行集群的開發(fā)，特別是為了使普通開發(fā)者能在資源受限的情況下模擬分布式集群在大規(guī)模的場景表現(xiàn)。使用該模擬器可以用于分析不同集群架構設計的預期性能，并附帶豐富的集群調試功能以及結果分析功能。本文模擬器實現(xiàn)以上功能的核心設計是本模擬采用了的基于Actor模型的集群描述方法，該描述方法使得集群的定義脫離了底層的實現(xiàn)，使得Actor模型可以被軟件模擬也可以被實際部署測試模擬。該做法的優(yōu)勢是使得開發(fā)者快速的進行模型算法的修改，并可快速的將軟件模擬中的模型轉換為實際部署的集群。而兩種模式同時的模擬使得通過實際測試數(shù)據(jù)校準軟件模擬成為可能。實際部署測試用于收集實際生產環(huán)境的具體環(huán)境參數(shù)用于校準模擬器。在軟件測試中本模擬器采用離散時間驅動架構，集群狀態(tài)隨時間點迭代的模擬方法。經過測試該架構的優(yōu)勢在于可以利用延長模擬時間的方式，復用一臺計算機的資源來模擬大型的集群的運行。其中模擬器的設計可以用于模擬集群各種網絡條件的場景，以及可以模擬節(jié)點服務擁堵的情況。本模擬器的實際部署模式可以將模擬器模型實例化真正可運行的集群。該模式基于Kubenetes集群，經過測試本模擬器可以無縫完成集群模型的實例化，并且，實際測試得到的數(shù)據(jù)可以用于校準軟件模擬器使得軟件模擬器在小規(guī)模情景下的實驗結果逼近實際部署的實驗結果，從而佐證軟件模擬的結果的可靠性。
參考文獻(略)