视界：ecFlow 5为成员国带来好处

meteorology/view, meteorology/workflow
目录

声明

本文正文内容翻译自 ECMWF Newsletter Number 166 - Winter 2021 由 Avi Bahra、Iain Russell 和 Sándor Kertész 撰写的文章《ecFlow 5 brings benefits to Member States》，版权归原作者所有。 翻译底稿来自 Google 翻译。

正文

管理大规模数据密集型计算过程的工作流是一个日益严峻的挑战。 这些工作流必须是可重复，高度可用，可监视和准确的，同时仍要灵活地支持更改。 在 ECMWF，ecFlow 应对了这一挑战，ecFlow 是内部开发的工作流软件包，可以满足中心及其成员国和合作国不断变化的要求。

ecFlow 面向通用用途设计，但已根据天气和气候科学的业务和研究需求进行了适配。 例如，ecFlow 在 ECMWF 有多种用途，包括研发实验运行，业务模式运行，数据后处理和归档以及软件构建。

ecFlow 使用户可以在受控环境中运行大量程序，这些程序相互之间以及在时间上都有依赖关系。 它提供对硬件和软件故障的良好容忍度，并允许受控重启。 服务端，客户端和图形用户界面 (GUI) 具有高度的可伸缩性，可以处理具有数十万个任务的工作流。 ecFlow 是开源的，使用 C++ 编写以实现最佳性能。 它在 UNIX 平台上运行，在 Linux 上具有多年的经验，最近用在 macOS 上。

ecFlow 的版本 5 在功能，性能，安全性和可维护性方面带来了许多现代化改进。

ecFlow 的架构

ecFlow 使用 C/S 架构 (图1)。 ecFlow 服务端管理多个套件 (suite)，每个套件都是任务的分层集合。 可以使用可确保其语法正确性的 Python API 定义复杂的套件 (图2）。 更简单的套件可以通过纯文本文件定义。 服务端将任务提交给将要运行的计算机，并在执行过程中接收更新。

可以使用任何脚本语言 (例如 shell 或 Python) 定义任务。 可以对这些脚本进行参数设置，这意味着同一个脚本可以用于多个有不同设置的任务。 例如，脚本变量 FORECAST_STEP 在一个任务运行时可以设置为 6，而在另一个任务运行时可以设置为 12。

脚本还可能包含嵌入式 ecFlow 命令，这些命令会将任务状态传达回服务器，例如，显示进度或触发另一个任务开始运行。 对于这些嵌入式命令的复杂调用，可以使任务动态修改服务端的套件，从而实现自适应工作流，而无需将修改后的套件手动加载到服务中。

ecFlow 并不与可能位于工作负载前端的任何特定队列系统绑定，但可以通过使用通用提交脚本将ecFlow 的任务提交到任何队列系统。

译者注：NWPC 使用脚本将 ecFlow 作业脚本提交到 Slurm 运行

ecFlow 客户端应用程序包括一个图形用户界面 ecFlowUI 和一个命令行程序 ecflow_client，两者都可用于查询和修改服务。

图1

各种客户端 (GUI，Bash，Python API) 可以使用 TCP/IP 或 SSL 协议与 ecFlow 服务进行双向通信。 服务可以直接运行任务，也可以将它们提交到队列系统。 无论哪种方式，任务仍然可以与服务通信。 服务在日志文件中跟踪事件，为过去事件的统计分析 (例如给定任务的平均持续时间) 提供基础。 定期将 checkpoint 文件写入磁盘，以提供服务内部状态的备份。 在将服务升级到 ecFlow 的较新版本时，也可以使用此机制来提供连续性。

import os
from ecflow import (
  Defs,
  Suite,
  Fmaily,
  Task,
  Edit,
  Trigger,
  Client
)

home = os.path.join(
  os.getenv("HOME"),
  "example"
)
defs = Defs(
    Suite(
        "test",
        Edit(ECF_HOME=home),
        Family(
            "f1",
            Edit(SLEEP=20),
            Task("t1"),
            Task(
                "t2",
                Trigger("t1 == complete")
            )
        )
    )
)

图2

一个简单的 Python 脚本示例，创建一个新的套件，其中包含两个任务，第二个任务将在第一个任务完成后立即运行。 然后使用默认设置将该套件加载到服务上。

图形用户界面

ecFlowUI 是 ecFlow 的图形用户界面 (图3)，使用 C++ Qt 库编写。 ecFlowUI 支持对工作流程的实时监控，允许启动、暂停和终止作业。 可以即时编辑套件的许多方面，包括作业脚本本身及其关联的变量。 可以使用高效的内置查看器查看实时和历史作业输出，该查看器可以处理任意大小的输出文件。 节点之间的依赖关系可以图形形式显示，内置的日志分析器可以帮助微调工作流。

ecFlowUI 可以一次监视多个 ecFlow 服务，并具有仅显示部分套件或任务的功能。 它还可以用于将一组任务从一个服务迁移到另一个服务。

图3

ecFlowUI 提供了一个用于查看套件并与套件进行交互的丰富环境，其中包括一个新的 Trigger Graph 视图，显示套件中各项之间的依赖关系。

ecFlow 版本 5

ecFlow 4 的一个限制因素是它的 C/S 通信对其链接的 boost 库版本更改非常敏感。 这意味着，如果使用不同版本的 boost 编译，那个单个客户端无法与所有正在运行的服务进行通信。 该技术还限制在通信协议中进行哪怕很小更改的能力，而这有时是开发新功能所必需的。

ecFlow 5 现在使用 JSON 格式进行通信，并且客户端和服务器可以自由使用不同版本的 boost。 此更改还允许添加新功能，而不会破坏与旧服务器或客户端的兼容性。

译者注：V5 版本使用 cereal 作为 JSON 序列化库

随着通信的进一步改进，ecFlowUI 现在可以使用更少的网络请求与服务器进行通信，这意味着更少的网络流量。 一项内部改进是 ecFlow 5 使用了 C++14 标准的特性，从而简化部分代码并提供性能优势。

ecFlow 5 具有 ECMWF用户以及成员国和合作国所要求的许多其他新功能，包括：

  • 改进的安全功能，例如集成 SSL 和基于密码的访问；ecFlowUI 现在可以在同一会话中查看基于SSL 和基于非 SSL 的服务。
  • ecFlowUI 现在具有交互式 trigger graph 视图，以显示节点和属性的相互依赖关系。
  • 服务现在支持自动存档和自动还原，从而允许套件的一部分在完成后动态写入磁盘，并在以后还原。这有助于处理超大型套件。
  • 改进的功能可以帮助用户诊断问题，例如，当工作负载故障或正在运行的作业与服务记录分离时。
  • 限制提交或活动任务数量的附加控制。
  • 各种较小的特性可帮助优化套件定义

ecFlow 的稳定性已通过 ECMWF 的日常运行验证。 此外，每晚都会进行大量测试，以确保其发行版中不会出现任何退步。 凭借其成熟性和经过验证的适用性，未来在 ecFlow 上的工作将着重于这种维护和稳定性的延续，而不是大型的新开发。

迁移到 ecFlow 5

ECMWF 的许多业务已经迁移到 ecFlow 版本 5。 ECMWF 的计算中心移至 Bologna 后，将仅提供版本 5。 幸运的是，从 ecFlow 4 迁移到 5 很简单，并且主要涉及停止当前运行的服务，然后使用 ecFlow 5 重新启动它。 迁移页面提供了更多详细信息。

https://confluence.ecmwf.int/display/ECFLOW/Migration+to+ecflow+5

重要的是要注意，由于通信协议的更改，版本 5 的服务只能使用版本 5 的 ecFlowUI。 还值得注意的是，尽管当前版本的 ecFlow 同时支持 Python 2 和 3，但是一旦在 Bologna 中运行，将仅支持 Python 3。 因此，建议确保尽快迁移任何套件，以避免出现最后的问题 (last-minute problems)。

获取

ecFlow 已安装在所有 ECMWF 的计算平台上，包括成员国和合作国服务器 ecgate。 如果您计划在 ECMWF 上运行业务 ecFlow 服务，请联系 User Services，后者将很高兴为您提供最佳设置方法的指导。 当前有一个默认版本和一个新版本的 ecFlow 5。 要使用其中之一，请使用以下命令：

module load ecflow/5
module load ecflow/5new

对于 ECMWF 的计算平台之外的用途，ecFlow 还可以作为二进制安装在 conda 平台上，可通过conda-forge 渠道使用以下命令获得：

conda install ecflow -c conda-forge

该源代码也可以在 GitHub (https://github.com/ecmwf/ecflow) 上找到，也可以从 ecFlow Confluence 页面上的压缩包 (https://confluence.ecmwf.int/display/ECFLOW/) 获得。

讨论

ecFlow 是 NWPC 当前使用的唯一工作流软件。 从 2018 年 CMA-PI 投入业务运行开始，NWPC 已使用 ecFlow 累计运行数值预报业务系统超过 2 年半时间。 尽管曾经遇到各种各样的问题，也曾有过因 ecFlow 卡住而导致定时业务系统没有按时启动，但类似的故障往往不是由 ecFlow 本身的问题导致，可能都与 HPC 的文件系统性能有关。 从总体应用情况看，ecFlow 完美地保障了 GRAPES 系列数值预报模式业务系统的稳定运行。

目前 NWPC 使用 ecFlow v4.11.1 版本，正计划考虑切换到 V5 版本。 但正如其它业务系统底层支撑软件几乎不会更新一样，ecFlow 的版本切换也仅仅是正在谋划当中。 虽然无需改动系统脚本就能实现切换，但总得有一个逐步测试的过程，而且基于当前版本开发的 ecFlow 工具也需要考虑与新版本的兼容性问题。 不过，笔者至少在今年第一季度对这个过程的兴趣不大，没有将其放到任务列表中。 也许这种没有太多挑战性的工作往往没有太大的吸引力，而我也不可避免地陷入到一个本不想进入的状态：

对于不能形成有效成果的通用型任务都没有多大兴趣

应该需要警惕逐渐出现的这种状态，与个人的理想状态相去甚远。

其实对于切换 ecFlow V5 版本，笔者有更多的想法。 当前 CMA-PI 上的 ecFlow 仅提供 Python 2 接口，如果有可能，尽量在新版本开始使用 Python 3 接口，将 Python 3 全面引入到业务系统运行环境中。 另外当前各个系统相互独立，没有构建模板，没有共享组件，缺乏代码复用。 虽然部门已有形成一套通用系统建设框架的想法，但这不是一件非常容易的事情。 只要思考下形成当前系统建设模式的背景，就会发现在该领域涉猎不深的缘由。 从 ecFlow 未来不会有新功能开发来看，这次切换可能是一段时期内对业务系统建设有所变革的唯一机会，就看到时候会如何选择了。 不过，正如我在一个月前的文章中所说的，新的一年要有新的开始，我还是不要再继续思考这个问题了。

参考

原文：

ecFlow 5 brings benefits to Member States

两篇使用 ecFlow 构建业务系统的参考文献：

  • 张志远, 孙立尹, 何锡玉, 等. 海洋环境数值预报业务综合运维平台设计与实现 [J]. 海洋预报, 2019, 36(3): 63-70.
  • 杜牧云, 赖安伟, 李俊, 等. 基于ECFLOW实现华中区域快速更新同化预报业务流程 [J]. 气象科技, 2019, 47(1): 179-185.

NWPC 基于 ecFlow 开发的工具项目请访问如下网址：

https://github.com/nwpc-oper

笔者翻译的 ecFlow 教程中文版（非最新版）：

https://perillaroc.github.io/ecflow-tutorial-cn/

2020 年翻译的一篇介绍 ecFlow V5.0 版本的文章：

《ecFlow学习笔记：V5.0版本前瞻》

关于 ecFlow 和工作流的更多文章请查看本博客的 ecFlow 标签和 meteorology/workflow 分类。