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

決策模擬論文怎么寫

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

決策模擬論文參考

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