文 / 中国民生银行信息科技部 袁春光 张立 焦媛
银行业数据中心的服务大体上分为在线服务和离线作业，在线服务主要是交易类服务，其流量存在周期性，但是对服务质量（SLA）却有极高的要求，主要负载出现在白天工作时间段，夜间的交易负载较低，计算资源的使用呈现日高夜低的特征。离线作业一般是大数据分析、批量任务或者模型训练，属于资源密集型服务，主要负载出现在夜间，可以容忍一定的时延甚至中断，计算资源的使用呈现日低夜高的特征。这两类服务的负载高峰存在明显的时间段错位，在时间维度上可以实现有效的资源互补。随着近年在线业务的渗透率提升和大数据类系统建设不断加强，两类负载所需的计算资源都在迅猛增长，如何将两类负载的资源打通、共享，以大量节约硬件投入，成为数据中心迫切需要解决的困难。
随着云原生技术不断演进，应用云原生改造的持续推进，云原生基础设施已经成为银行业数据中心重要的计算平台。以云原生技术为统一算力平台，通过在线和离线混合部署（简称在离线混部），让在线服务和离线作业共享计算节点成为可能，这样可以极大地提升整体资源使用率，降低企业的 IT 成本。
在离线混部的价值
在离线混部可以大幅度提升计算资源使用效率。根据 Garner 统计，全球数据中心平均计算资源使用率不到 15%，造成资源使用率低下的原因包括为峰值处理预留资源，为灾备预留冗余资源，以及巨大的负载时间段分布差异（如日间和夜间存在巨大负载差异）。对于银行业数据中心，由于要考虑到极致的稳定性，资源配比往往是按照业务的峰值需求匹配，导致整体计算资源使用率偏低，一般在 10%15% 之间。通过混合部署，在确保在线服务稳定性的前提下，可以将整体计算资源使用率提升到 30%（如图1所示），后期如果继续优化负载感知和资源隔离能力，甚至可以将整体资源使用率提升到 40% 以上。相当于同样的计算资源，可以承载的业务服务能力增加到原来的 23 倍，对应可以节省 50% 甚至更多的 IT 成本。所以在离线混部的价值巨大。
图1 混部示意图
在离线混部依赖的基础设施能力
1.云原生作为统一计算基础设施
混合部署要求在线离线服务部署到同样的计算节点，目前只有基于容器的云原生技术可以实现这一点。在容器计算节点上，在线和离线服务都以 K8s Pod 的方式运行。在线服务的云原生改造已经有比较成熟的实现方式，而离线作业以大数据作业为主，改造起来困难比较大，原因是调度方式需要由 YARN 切换到 K8s，同时确保对客户端透明，让大数据作业可以非常方便地在 YARN 集群和 K8s 集群之间切换。
2.适配大数据作业的高级调度能力
K8s 标准的调度器是按照调度在线作业的目标设计的，并不适合大数据作业。大数据作业要在 K8s 集群上运行，需要调度器具备组调度能力（Gang Scheduling）和负载感知调度能力。具体来说就是一个作业相关的 Pod 要看作一个 Pod 组（Pod Group），只有可用资源满足 Pod 组需求前提下，才会启动调度，并且只有 Pod 组里的 Pod 都创建成功，才认为是调度成功。负载感知调度可以避免热点节点上被继续调度 Pod，同时节点资源使用率过高时要主动驱逐部分离线大数据 Pod，避免影响节点上的在线业务。
3.计算节点内核具备负载优先级管理能力
通过调度器增强可以让离线 Pod 的分布尽可能分散，但是无法按照优先级提供资源隔离和控制，因此也无法避免在线服务不受干扰。这种情况下，需要计算节点的操作系统内核具备对不同优先级 Pod 的资源控制和隔离能力，包括调度时优先调度在线 Pod 的线程，SMT 抗干扰能力，带宽分级控制，以及能够把计算节点上离线作业 Pod 的总体资源使用量控制在一个能力范围之内，这样才能彻底避免对在线服务 Pod 产生干扰，在混合部署以后依然能够对高优先级应用提供非常高水平的 SLA。这一能力需要操作系统内核进行针对性地增强才能实现。
民生银行在离线混部实践
回到落地多云给企业带来的实践层面挑战，除了部署 / 运维复杂度、打通 / 互操作性和成本控制复杂度，最后一点就是数据管理 / 合规难度。随着国际格局愈发复杂，多云 / 分布式云也出现了一些亟待解决的下一阶段发展问题。
民生银行的容器云平台一开始的设计就是支持在线应用的混合部署，不同在线应用的容器 Pod 可以共享计算节点。为了支持在线应用混合部署，容器云平台采用 Underlay 网络模型，允许不同应用 Pod 以不同的IP地址出访，由于 Pod 的 IP 不固定，还需要配套网络访问策略联动，在应用 Pod 的 IP 发生变化时动态更新 Pod 的网络访问策略。在此基础上，为了进一步提升资源使用效率，民生银行开始探索在离线混部的实现。
首先需要对大数据作业做云原生改造。银行使用比较广泛的大数据集群是 YARN 集群，并有专用的客户端用于提交作业到 YARN 集群。云原生改造的难点是要把大数据作业的调度管理系统从 YARN 改造为 K8s（如图 2 所示），并且对客户端完全透明。客户端还是以 YARN 的方式提交作业，但是作业会被提交到一个转换层，由转换层将其翻译为 K8s 语言，以 K8s Pod 的方式调度管理 YARN container，K8s 的计算节点做为 NodeManager 承载这些 YARN Container Pod。此外，为了实现容灾和灵活的资源调度，也需要有一个 YARN 作业的路由管理层，允许平台管理员灵活地将队列在不同 K8s 集群之间切换。
图2 YARN 云原生改造示意图
在实现大数据作业云原生改造的基础上，还需要配套专门的大数据作业 K8s 调度器，更好地满足大数据作业调度的需求。除了基础的组调度，还需要负载感知调度和弹性配额调度。负载感知调度有两个层面，一是在调度大数据作业 Pod 前要先观察所有计算节点的历史负载，选择负载最低的节点进行调度，同时辅助以 Pod 间反亲和性，让同一个作业的 Pod 尽量均匀分散在不同的计算节点；二是在某个节点负载过高，超过警戒阈值时，主动将部分低优先级的大数据作业 Pod 驱离到其他负载较低的节点，确保不对在线服务产品干扰。弹性配额调度是指根据时间段为大数据作业分配不同的资源配额，比如夜间可以分配较多的配额，日间分配较少的配额。在配额减少时，如果正在运行的作业占用了超过配额的资源，就必须减少部分低优先级作业的资源，甚至停止这些作业，以释放资源保证在线服务有充足的资源可用。
为了更好地实现在线离线服务的资源隔离和优先级控制，还需要在计算节点的 Kernel 层面做增强。K8s Pod 的资源控制和隔离是通过 Linux Kernel 提供的 Cgroup 机制实现，仅支持 Best Effort、Burstable 和 Guaranteed 三种方式。Best Effort 方式不能对 Pod 资源做限制，无法采用；Guaranteed 方式类似 CPU 绑核，用于离线服务并不合适，用于在线服务也会造成较多资源浪费；Burstable 是目前在线服务采用的方式，虽然有资源控制，但是不区分优先级，并不适合给低优先级的离线服务使用。因此需要对 Kernel 做增强，包括为低优线程提供专门的低优先级 CPU 调度队列、SMT（CPU 超线程）抗干扰、抢占式调度、网络带宽分级控制等。同时在 Cgroup 层面要适配这些增强的能力。在此基础上，还需要优化 K8s Cgroup 的实现，允许为低优先级的离线 Pod 设置单独的 Cgroup 层级，把离线 Pod 使用的资源总量控制在一个允许的范围内，避免突增的离线负载与在线服务竞争资源。在增强的 Kernel 和 Cgroup 基础上，还需要一个 K8s Cgroup 适配器，根据 K8s Pod 的优先级配置标签，将其放置到对应优先级的 Cgroup 里，并且能够动态切换优先级，满足应用动态变化的需求。
在离线混部的效果和展望
在离线混合部署已经在民生银行生产环境投产，初期采用潮汐运行方式，白天仅运行在线服务，夜间才允许运行离线大数据服务。混部计算节点的 CPU 平均使用率可以从 10% 提升到 30% 左右。同时，我们也在根据实际运行情况不断优化调度和控制策略，目标是通过弹性资源配额控制，包括调度器的队列弹性伸缩、Cgroup 配额弹性伸缩等，在确保在线服务不受干扰的前提下，尽可能提升离线作业的资源使用率，同时增加离线作业的资源使用时间段，逐步允许白天也可以运行部分离线作业。
混合部署是云原生深度应用的必然选择，是云原生转型进入深水区的重要标志。民生银行将持续在此方面进行探索，为高效、集约的数字化转型提供能力支撑。