本文是一篇计算机专业论文，本文提出了一种结合软件模拟和实际测试模拟的分布式集群模拟方法，它设计的目的在于辅助分布式任务执行集群的开发，特别是为了使普通开发者能在资源受限的情况下模拟分布式集群在大规模的场景表现。使用该模拟器可以用于分析不同集群架构设计的预期性能，并附带丰富的集群调试功能以及结果分析功能。
第1章绪论
1.1研究背景及意义
近年来，云计算作为一种新兴趋势受到服务提供商和用户的大量关注。伯克利的报告指出，云计算将大幅改变现有的IT产业[1]。在云计算中，算力资源、存储资源、应用程序等计算资源可以通过网络按照现用现付的模式提供给用户[2]。在该模式下数据中心可以将计算资源整合起来，通过按需使用的方式提供给众多用户，从而高效地利用计算资源。
云计算的发展当中出现了多种云服务形式。最先出现的服务形式是基础设施即服务(IaaS)，在此模式下云服务商可以帮助用户维护服务器，数据库，网络环境等IT基础设施。为了使服务变得更加方便以及提高计算资源的利用效率，云计算领域又先后提出了平台即服务(PaaS)以及软件即服务(SaaS)的概念，在PaaS模式下用户不再需要关心底层基础设施,也无需自行配置运行环境。云服务商提供一个应用运行平台，用户可以基于该运行平台运行自身应用。而在SaaS下用户更是无需自行编写应用，云服务商直接提供软件服务。在Paas和SaaS模式当中，云计算中心的资源调度的单位变成了应用。在实际当中，这些应用常常依托于容器化技术，容器化应用可以方便地在不同物理节点间迁移，相比于虚拟机的形式，容器化应用可以在一台主机上高密度部署，使得资源利用率更高。由于容器化应用的启动停止比虚拟机形式更加灵活，容器化应用在水平扩容方面更加有优势。在应用请求的高峰期，容器化应用可以生成更多副本，而在请求相对空闲期减少应用的副本数。容器化应用的提交，结束等动作更加频繁，系统的调度请求更加密集。相比于IaaS模式，这些模式对调度系统的要求有所不同。伴随着Serverless的趋势[3]，FaaS作为一种更灵活的方式,在云服务中得到广泛应用[2]。在该模式下资源管理单位从完整的单体应用变成了更细粒度的函数。相比于完整应用，函数任务的运行时间更为短暂，当函数提交后，资源管理会为该函数寻找计算资源，当函数执行完成后即释放资源。函数应用具有高度并行化特征，用户可以同时提交大量任务函数，这些函数可以并行执行，互不干扰。在FaaS模式下调度系统的任务提交更为频繁，集群的状态变化更快，这又为计算中心的调度系统带来了新的挑战[4]。
1.2国内外研究现状
在调度集群的设计领域，目前有多种架构类型的调度集群架构。比较典型的有集中式调度、共享状态式调度和去中心化调度。集中式调度采用单一的中央调度器来管理整个集群的资源和任务调度。所有的节点和应用都需要与中央调度器交互,汇报自身状态并接收调度决策。其优点在于其架构相对简单,便于管理和推理全局状态以及更容易实现复杂的调度策略和规则。其缺点在于其中央调度器可能会成为单点故障。当集群规模扩大时,中央调度器可能会成为性能瓶颈。集中式调度集群的代表有Apache Hadoop YARN[5]，Apache Mesos[6],以及Spark[7]原生的调度系统。共享状态调度架构引入了多个相互协作的调度器实例,通过共享集群状态来进行分布式调度决策。每个调度器实例都可以独立运行,并且访问集群的全局状态。其优点在于其提高了可伸缩性和容错性,无单点故障，在不同调度器实例可以应用不同的调度策略。其缺点需要一个外部高可用的状态存储系统(如Zookeeper[8])来存储集群状态，并且状态共享和一致性协议可能会增加集群设计的复杂性。共享状态集群的代表有Google Omega,独立部署etcd且有多个apiserver的Kubernetes集群。去中心化调度采用完全分布式的架构,没有中央调度器或集群状态存储。每个节点都是独立的调度器,只根据本地信息做出调度决策。其优点在于其高度分布式,良好的伸缩性和较强容错性。其缺点在于其难以实现复杂的全局调度策略和规则。调度决策只基于局部视图,可能无法获得全局最优。其代表有Sparrow[9]，Tarcil[10]，以及Quasar[11]。这三种架构模式各有利弊,在不同的应用场景中会有不同的选择。随着集群规模和应用复杂度的增加,共享状态式和去中心化调度架构通常具有更好的伸缩性和高可用性。但对于需要复杂调度策略的场合,集中式架构可能更加合适。
第2章相关工作与研究
2.1常见调度系统架构
目前常见的调度系统架构有集中式调度架构，共享状态式调度架构，去中心化式调度架构。下面将介绍这些架构的典型代表。此外，由于调度系统的复杂性，一些调度可能是混合架构的设计，融合了多种类型架构的优势，这些调度集群的存在说明在调度系统领域架构的差异性是相当丰富的,正是由于这些架构的差异性所在，导致了目前很少有适合的研究工具公平对比这些架构调度系统的性能差异。
2.1.1集中式调度架构
集中式调度是最常见的调度架构，它具有简单性，一致性，资源集中管理的优势。但是该架构的调度集群容易因为单节点故障导致系统失效，并且容易由于集群规模扩展而出现单节点性能瓶颈[20]。中心化的调度架构被广泛应用在大型的集群管理系统当中，包括Hadoop Yarn[5],Quincy[21]，Firmament[22]和Gemini[23]。
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章模拟系统的功能测试以及可靠性验证
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
5.1.2实际部署模拟模式的实验平台
在部署模拟实验中，使用了云服务形式的Kubenetes集群。其具体环境参数如下：•集群环境：阿里云ACK服务•节点数量：10 ECS节点每个ECS节点的配置：•操作系统：Ubuntu:22.04•Kubenetes版本：1.30.1•容器镜像仓库：阿里云ACR•CPU:4 vCPU(通过虚拟化技术从物理CPU中分配出来的核心)•Memory:8GB
第6章总结和展望
6.1本文工作总结
本文提出了一种结合软件模拟和实际测试模拟的分布式集群模拟方法，它设计的目的在于辅助分布式任务执行集群的开发，特别是为了使普通开发者能在资源受限的情况下模拟分布式
