EdgeSimPy 代码解读

主要组件

管理

ComponentManager

• 组件的基类，管理抽象实体，提供模型元数据导出

Simulator

• 初始化：加载元数据、构建模型
• 启动模拟，循环执行step并监控，满足退出条件停止，将数据保存到本地
• step：
  • 执行资源管理算法、Agent活动调度算法

抽象实体（Agent）

BaseStation

• 连接Servers、Switchs，有坐标、无线延迟，用户可连接

EdgeServer

• 承载Container、从Registry所在Server拉取Layers（按最短路径，同时创建Flow）
• 可添加Image（根据Layers判断可否）
• 可承载服务、根据服务的Image拉取没有的Layers
• 可设置电量模型
• step：
  • 当有Layer等待下载且未达同时下载上限时，创建网络流，从最近的Registry下载所需Layers

NetworkSwitch

• 可设置电量模型

NetworkLink

• 连接Switch，含延迟、带宽，承载Flow，路由App

NetworkFlow

• 从源Server到目标Server经Path传输Data，记录途中Link的带宽和传输状态
• 在每个step：
  • 根据带宽传输数据，如果传输的是Layer，更新目标Server的下载状态

Topology

• 管理图，提供延迟、路径等计算
• 申请/释放通信路径（User到App的多组Switch链）：向所有途径的Link中添加/删除Application
• step：
  • 运行网络流调度算法

ContainerImage

• 通过digest唯一标识，由Layers组成

ContainerLayer

• 通过digest唯一标识

ContainerRegistry

• 容器注册机，在Server上运行，需要占用cpu、mem和disk
• 可部署在Server上，向目标Server的下载队列中添加缺少的Layers，增加磁盘占用
• 可从Server中卸载，当没有Flow从Registry拉取Layers时执行卸载，如果设置purge_images，则卸载前删除所有未使用（没有服务运行，没有服务向所在Server迁移）的Images和相关Layers
• step：
  • 检查Server是否有所需Image，有则启用Registry

Service

• 基于Image，由Server承载，从属于App
• 可部署（Provision）在Server，Provision过程视为Migration，向目标Server的下载队列中添加缺少的Layers，增加cpu、mem需求，记录迁移状态。迁移中的Service不可用
• step：
  • 如果有服务正在迁移，按迁移状态（waiting、pulling_layers、finished、migrating_service_state）执行迁移流程，如果是状态服务，建立Flow传输状态
  • 迁移完成后通知所有访问App的用户

Application

• 由Services组成，可由Users访问

User

• 通过基站访问App，有延迟、有坐标，可设置移动模型、访问模型
• 延迟计算，调用Topology返回User到App的总延迟
• 可设置App的通信路径（一组Switch链的id），先释放原有路径，再通过Dijkstra算法计算连通组成App的所有Service所在的Server的延迟最短路径并通过Topology申请，最后计算并保存延迟和路径
• 可设置起始位置与停留步数，并与该位置处基站相连
• step：
  • 对于该User的所有App，根据access_patterns，判断是否在请求中并更新请求列表
  • 根据coordinates_trace和mobility_model进行移动，更新坐标和连接的基站，同时更新通信路径和延迟

内置模型与算法

flow scheduling

• equal_share：对于所有Flow，考虑其中含未占用某Link带宽或没有数据传输的Flow的所有Link，将带宽平均分配给每个Flow
• max_min_fairness：同上，对每个Link上的所有Flow，迭代：如果Flow的带宽富裕（allocated > demand）将其分配带宽定为demand，将所有省下来的带宽平均分给不富裕的Flow，如此往复直到没有剩余带宽或所有Flow的分配带宽满足需要

mobility models

• pathway：User从起始基站通过最短路径到达随机的目标基站，重复n_paths次，按seconds_to_move在每处停留（默认60秒），记录每second的位置mobility_path，用其更新User的坐标追踪
• random_mobility：User从起始基站随机选择相邻基站移动，重复n_moves次，其余同上

power models

• Network：Conterato：Switch的所有port和chassis耗电总和
• Servers：Linear：静态耗电 + 系数 * 动态项；Square：静态 + 系数 * 动态^2；Cubic：静态 + 系数 * 动态^3；

user access patterns

• Circular：从start开始按durations和intervals循环更新User对App每step的请求，每次迭代一次
• Random：随机选择duration和interval更新，其余同上

activation schedulers

• Base：从当前step未启动的Agent中按加入顺序激活（执行Agent的step函数）所有，step、time加一
• Default：按Server、Service、Topology、Flow、User、Registry、Switch、Link、Station、Layer、Image、App的顺序激活所有Agent，step、time加一
• Random：从当前step未启动的Agent中随机选择一个激活，直到全部激活，step、time加一

dataset generator

• edge servers：含多种内置规格的Server类型
• map：可按六边形或四边形格点建系，返回坐标集
• network switches：按Conterato电量模型构建简单交换机
• network topologies：
  • barabasi albert：按BA模型生成网络
  • partially connected hexagonal mesh：创建一个部分连接的无线网格网络
• placement：含一系列分配Registries和Services的算法
  • best fit：Servers按 ​\sqrt[3]{\Delta cpu*\Delta mem*\Delta disk} 升序，​\Delta表示剩余
  • worst fit：Servers按 ​\sqrt[3]{\Delta cpu*\Delta mem*\Delta disk} 降序
  • random fit：随机

第三方库

Mesa

• Agent Based Modeling in Python

NetworkX

• Python package for the creation, manipulation, and study of the structure, dynamics, and functions of complex networks

新增

新增组件

Request

• step
  • 监视Job完成情况
  • 计算从用户发出到接收的delay

Job

• 记录request对应的任务，根据server分配启动tasks
• step
  • 监视Task完成情况
  • 记录完成时间

Task

• 支持DAG（任务含时序依赖关系），根据自身资源占用向所在server更新，根据status和step判断是否完成
• step：
  • 当依赖任务均完成后，计算依赖任务所在server到自身server的最长延迟，更新起始step
  • 当server能容纳时启动，当step_demand降为0时完成，当server故障时标记为terminated

RequestDistributor

• 假设运行在master_nodes上，在每个step，收集所有用户请求
• 通过A3C算法，根据当前服务器状态（CPU、Memory利用率）决定请求分配

新增模型

fault patterns

• Random：给定最大次数、最长持续时间，随机Shutdown或Recovery