📚 课程目录第4章后端选择与配置

后端选择与配置：Local、HPC、AWS Batch、Google Cloud Life Sciences

后端选型这事儿，说大不大，说小不小。我见过有人花了两周配好了AWS Batch，结果跑了个10样本的测试就再也没用过。也见过有人直接用Local后端撑起整个团队的WDL开发，最后上线时才发现内存根本不够。

说白了，后端就是Cromwell调度任务的引擎。你选哪个，直接影响成本、速度、还有你半夜会不会被报警电话吵醒。今天咱们就挨个过一遍，我把自己踩过的坑和总结的经验都摊开来讲。

Local 后端：开发调试的好伙伴，生产环境的坑

Local后端不需要任何额外配置，Cromwell装完就能用。默认把任务提交到本地机器上，通过单独的JVM进程来跑。

我第一次用Cromwell就是在自己的笔记本上。跑一个基因比对WDL，数据量不大，一切正常。直到有一次，我同时启动了5个样本，笔记本风扇直接起飞，最后OutOfMemoryError. 嗯，当时我还在想是不是代码写错了。后来才发现，Local后端默认不限制并发，CPU和内存直接打满。

适用场景：单机开发调试、小样本测试（<100个任务）、流程语法验证。

配置示例。在cromwell.conf中指定backend为Local，并限制并发数：

backend {
  default = "Local"
  providers {
    Local {
      actor-factory = "cromwell.backend.impl.sfs.config.ConfigBackendLifecycleActorFactory"
      config {
        concurrent-job-limit = 2
        runtime-attributes = """
        String? docker
        Int cpu = 1
        Int memory_gb = 4
        """
      }
    }
  }
}

这里要注意的是concurrent-job-limit，一定要设置。我习惯设成cpu核心数 - 1，留一个核心给系统用。不然你连鼠标都拖不动。

避坑指南：我曾经在生产环境尝试用Local后端跑50个样本，结果跑了两天还没跑完，而且Cromwell进程挂掉后所有中间结果丢失，没有重试机制。Local不适合生产，千万别偷懒。

HPC 后端：SLURM/PBS 的配置与陷阱

大部分高校和传统生物信息中心都跑HPC。Cromwell支持通过SFS（Shared File System）后端与SLURM、PBS、LSF等调度系统对接。

配置核心点是让Cromwell知道怎么提交作业、怎么检查状态。我遇到过的最常见问题是作业脚本的#!/bin/bash路径不对，导致提交失败。

下面是一个SLURM后端的配置片段：

backend {
  default = "SLURM"
  providers {
    SLURM {
      actor-factory = "cromwell.backend.impl.sfs.config.ConfigBackendLifecycleActorFactory"
      config {
        submit-docker = """
        sbatch \
          --job-name=${job_name} \
          --cpus-per-task=${cpu} \
          --mem=${memory_gb}G \
          --output=${cwd}/execution/stdout \
          --error=${cwd}/execution/stderr \
          --wrap "/usr/bin/docker run --rm -v ${cwd}:${docker_cwd} ${docker} ${job_shell} ${command}"
        """
        submit = """
        sbatch \
          --job-name=${job_name} \
          --cpus-per-task=${cpu} \
          --mem=${memory_gb}G \
          --output=${cwd}/execution/stdout \
          --error=${cwd}/execution/stderr \
          --wrap "${job_shell} ${command}"
        """
        kill = "scancel ${job_id}"
        check-alive = "squeue -j ${job_id}"
        job-id-regex = "Submitted batch job (\\d+).*"
      }
    }
  }
}

注意submit-docker和submit分开配置。如果WDL里写了docker，Cromwell会自动走submit-docker；否则走submit。我曾经没配submit-docker，结果带docker的任务直接被忽略报错，排查了好几个小时。

经验之谈：HPC上一定要统一共享文件系统路径。如果Cromwell跑在登录节点，而计算节点挂载路径不同（比如/home vs /scratch），任务会瞬间失败。我个人习惯把所有路径用环境变量抽出来，在提交脚本里动态替换。

AWS Batch 后端：云原生弹性，但成本刺客

AWS Batch是Cromwell官方支持最好的云后端之一。它自动管理EC2实例的启停、自动伸缩。用好了是真香，用不好账单可能吓死人。

我刚开始用AWS Batch时，图省事直接用了默认的计算环境配置。结果跑了一个大矩阵运算，自动启动了r5.24xlarge实例，跑了8个小时，账单一看，$500多。后来我学乖了，在Compute Environment里限制了maxvCpus和实例类型。

在cromwell.conf中配置AWS Batch后端：

backend {
  default = "AWSBatch"
  providers {
    AWSBatch {
      actor-factory = "cromwell.backend.impl.aws.batch.AwsBatchBackendLifecycleActorFactory"
      config {
        // 必填
        root = "s3://my-bucket/cromwell-execution"
        aws-region = "us-east-1"
        // 计算环境ARN（提前在AWS Batch控制台创建）
        compute-environment-arn = "arn:aws:batch:us-east-1:123456789012:compute-environment/myCromwellEnv"
        // 任务队列ARN
        job-queue-arn = "arn:aws:batch:us-east-1:123456789012:job-queue/myCromwellQueue"
        // 可选：限制最大vCPU（预防成本爆炸）
        batch-attributes {
          maxvCpus = 256
        }
      }
    }
  }
}

避坑指南：我曾经不小心把compute-environment-arn拼错了，Cromwell报错“Cannot find compute environment”。日志里只显示了一个通用错误码，排查了半天才发现是ARN里少了个冒号。我的建议是：所有ARN先在AWS CLI里aws batch describe-compute-environments确认一遍再粘贴。

AWS Batch 的优势是弹性，想扩就扩。但要特别注意S3的读写性能。如果WDL里频繁write_lines()或者read_tsv()，小文件太多会导致S3请求数暴涨，增加延迟和成本。我一般会建议用户把中间结果打包成tar再上传。

Google Cloud Life Sciences 后端：Google 生态的集成之选

Google Cloud Life Sciences（原Google Pipelines API）后端，简称GCLS。它的核心是把每个Cromwell任务抽象成一个Pipeline，自动拉起GCE虚拟机运行，运行完自动销毁。

它的配置比AWS Batch简洁不少，因为很多基础设施（如虚拟机、磁盘）由Google管理。但代价是定制化能力弱一些。

配置示例：

backend {
  default = "PAPIv2"
  providers {
    PAPIv2 {
      actor-factory = "cromwell.backend.impl.google.pipelines.v2beta.PipelinesApiLifecycleActorFactory"
      config {
        root = "gs://my-bucket/cromwell-execution"
        project = "my-gcp-project"
        // 服务账号（可选，但建议单独创建）
        genomics {
          auth = "service-account"
          service-account-email = "cromwell-sa@my-gcp-project.iam.gserviceaccount.com"
        }
        // 可用区限制
        zone = "us-central1-a"
        // 虚拟机配置默认值
        default-runtime-attributes {
          cpu: 1
          memory: 4
          disks: "local-disk 10 HDD"
        }
      }
    }
  }
}

这里有个容易被忽略的点：disks的格式是" "，必须用空格分隔。我见过有人写成"local-disk,10,HDD"，管道直接失败，报错“Invalid disk specification”。

个人经验：GCLS的冷启动时间比AWS Batch稍长，第一次拉起虚拟机可能需要2-3分钟。但优势是它和Google Cloud Storage的集成特别好，大文件传输几乎零成本。如果团队已经在用GCP，我强烈推荐GCLS。

后端对比总表

特性	Local	HPC (SLURM/PBS)	AWS Batch	Google Cloud Life Sciences
部署难度	零配置	中等（需共享文件系统）	中等（需提前创建计算环境）	低（项目+服务账号即可）
弹性伸缩	无	手动（通过调度器队列）	自动（按需/Spot）	自动（仅Spot）
成本模型	固定（本地资源）	固定（集群资源）	按使用量（注意实例类型）	按使用量（虚拟机+磁盘）
重试能力	无	有限（依赖调度器）	内置（可配置）	内置（自动重启）
最大并发	受本地CPU/内存限制	受集群配额限制	受AWS vCPU配额限制	受GCE配额限制
适用规模	<100个任务	几百个任务	大规模（千级以上）	大规模（千级以上）

SVG：后端选型决策流程

下面这张图是我自己画的一个选型流程图。我每次给团队培训都拿它说事——先问规模，再问基础设施，最后看预算。

选型实战建议

看完对比表，你可能会纠结。我给几条实操建议：

开发阶段：用Local就够了。代码里加个runtime { cpu: 1; memory: "2 GB" }限制，别让笔记本冒烟。
团队已有HPC集群：优先用SLURM/PBS后端。但一定要测试共享文件系统路径是否一致。我建议在计算节点上手动跑一个pwd确认一下。
从零上云且预算敏感：选AWS Batch+Spot实例。但记得在WDL里设置maxRetries为2或3，Spot实例被回收时能自动重试。
团队使用Google生态：闭眼选GCLS。它的日志集成（Stackdriver）比AWS CloudWatch好用很多。
混合云场景：可以在cromwell.conf里配置多个backend，然后用backend标签在WDL里指定运行环境。比如开发流程用Local，生产用GCLS。

个人习惯：我一般会在每个Cromwell项目根目录放一个cromwell.conf模板，包含Local和云后端两套配置，通过环境变量CROMWELL_BACKEND切换。这样团队里做开发的同事不用改任何配置就能跑起来。

总结

后端选型没有银弹。Local胜在简单，HPC胜在集群稳定，AWS Batch和GCLS胜在弹性。关键是先搞清楚自己的任务规模和基础设施。

嗯，这一章的内容差不多就这样。记住一点：别在Local上跑超过10个样本，别在云上跑没有预算限制的作业。这两条我都是用真金白银换来的教训。