基于 Amazon MWAA 和 Amazon Batch，实现载荷仿真任务弹性调度和计算
内容提要
本文介绍了基于Amazon MWAA和Amazon Batch的载荷仿真任务弹性调度和计算方案。通过使用Amazon MWAA和Amazon Batch，可以实现风电机组载荷计算的可靠性和效率。文章提供了方案介绍和服务介绍，并详细介绍了环境搭建和任务调度的步骤。最后，通过验证结果证明了该方案的有效性。
延伸解读
许可证服务与自定义 AMI 的必要性
前处理任务需与 Bladed License Server 通信，依赖 aksusbd 服务监听 1947 端口。由于 Amazon Batch 使用 Host 网络模式，若在容器内启动该服务，端口会被首个任务占用，后续任务无法启动服务，且首个任务结束后端口释放会导致其他任务失败。因此，将 aksusbd 服务和 hasplm.ini 配置在主机上，并通过自定义 AMI 固化，是保证多任务并发稳定运行的关键。
实例选型与成本优化策略
前处理为计算密集型，选用 c6i.4xlarge；后处理为内存密集型，选用 r6i.large。两者均使用 Spot 实例以节约成本，并采用 SPOT_CAPACITY_OPTIMIZED 分配策略降低中断概率。同时可混合 On-demand 实例作为回退，结合 Airflow 的重试机制，在任务运行时间较短（前处理 1 小时内、后处理分钟级）的场景下，能有效平衡成本与可靠性。
存储与数据流转设计
方案使用 Amazon FSx for Lustre 作为共享存储，通过 Amazon Lambda 函数动态创建和删除文件系统，并修改后处理启动模板的 UserData 以自动挂载。Lustre 与 Amazon S3 之间通过 ImportPath 和 AutoImportPolicy 实现数据映射与同步，支持懒加载和预加载。验证中，从 S3 预热 92GB 数据耗时 20 分钟，后处理任务运行 10 分钟，体现了存储层对整体流程效率的影响。
性能对比与适用场景
真实场景测试中，前处理任务运行 1441 个工况，本方案使用 c6i.4xlarge Spot 实例并发 500 任务，耗时 1 小时 10 分钟；本地生产集群使用 500 物理核 Kubernetes 集群，耗时 1 小时 27 分钟。本方案利用超线程和弹性调度，在任务并发度高、可容忍重试的场景下，展现出效率优势，适合载荷仿真这类批处理型工作负载。
Q&A
如何使用Amazon MWAA和Amazon Batch进行载荷仿真任务调度？
可以通过创建Amazon MWAA和配置Amazon Batch来实现载荷仿真任务的调度，前处理任务使用Spot实例以节约成本，后处理任务选择内存密集型实例。
载荷计算的前处理和后处理阶段分别是什么？
前处理阶段使用Bladed软件计算中间结果，后处理阶段根据前处理的中间结果生成最终报告。
Amazon MWAA和Amazon Batch各自的功能是什么？
Amazon MWAA是Apache Airflow的托管服务，提供工作流程编排；Amazon Batch是完全托管的批处理计算服务，支持容器化工作负载的调度。
如何搭建Amazon MWAA环境？
搭建Amazon MWAA环境需要创建DAGs文件夹和Execution role，并确保Execution role具有调用Amazon Lambda、Amazon Batch和访问Amazon S3的权限。
使用Amazon Batch调度前处理任务时有哪些注意事项？
需要使用EC2 Spot实例以节约成本，选择计算密集型实例，并设置合适的重试策略和分配策略以降低中断概率。
验证方案有效性的方法是什么？
通过在真实场景中运行前处理和后处理任务，并检查计算结果和任务成功率来验证方案的有效性。
