技术优化seo,seo推荐,广州网络推广公司有哪些,个人网站命名 备案简介#xff1a;阿里巴巴在“差异化 SLO 混合部署”上已经有了多年的实践经验#xff0c;目前已达到业界领先水平。所谓“差异化 SLO”#xff0c;就是将不同类型的工作负载混合运行在同一节点#xff0c;充分利用工作负载对资源 SLO 需求特征的不同#xff0c;提升资源整…简介阿里巴巴在“差异化 SLO 混合部署”上已经有了多年的实践经验目前已达到业界领先水平。所谓“差异化 SLO”就是将不同类型的工作负载混合运行在同一节点充分利用工作负载对资源 SLO 需求特征的不同提升资源整体使用效率。本文将重点介绍相关技术细节和使用方法让用户可以充分享受差异化 SLO 带来的技术红利。
作者佑祎
背景介绍
阿里巴巴在“差异化 SLO 混合部署”上已经有了多年的实践经验目前已达到业界领先水平。所谓“差异化 SLO”就是将不同类型的工作负载混合运行在同一节点充分利用工作负载对资源 SLO 需求特征的不同提升资源整体使用效率。本文将重点介绍相关技术细节和使用方法让用户可以充分享受差异化 SLO 带来的技术红利。
资源模型
作为通用的计算资源托管框架Kubernetes 托管了多种类型的业务负载包括在线服务、大数据、实时计算、AI 等等。从业务对资源质量需求来看这些业务可以分为“延时敏感型”Latency Sensitive简称 LS和“资源消耗型”Best Effort简称 BE两类。
对于 LS 类型为了确保资源的稳定性能够应对突发的业务流量能够应对机房容灾后带来的流量增长一个可靠的服务通常会申请较大的资源 request 和 limit这也是 Kubernetes 集群资源分配率很容易做到 80% 以上但利用率却低于 20% 的主要原因也是 Kubernetes 引入 BestEffort QoS 类型的原因。 为了充分利用这部分已分配但未使用的资源我们将上图中的红线定义为 usage蓝色线到红色先预留部分资源定义为 buffered绿色覆盖部分定义为 reclaimed如下图所示 这部分资源代表了可动态超卖的资源量也就是∑reclaimed(Guaranteed/Burstable)。将这部分空闲资源分配给 BE 类型的业务就可以充分利用工作负载对资源运行质量需求不同的特征提升集群整体资源利用率。
阿里云容器服务 Kubernetes 版Alibaba Cloud Container Service for Kubernetes以下简称 ACK差异化 SLO 扩展套件提供了将这部分超卖资源量化的能力动态计算当前的reclaimed资源量并以标准扩展资源的形式实时更新到 Kubernetes 的 Node 元信息中。
# Node
status:allocatable:# milli-corealibabacloud.com/reclaimed-cpu: 50000# bytesalibabacloud.com/reclaimed-memory: 50000capacity:alibabacloud.com/reclaimed-cpu: 50000alibabacloud.com/reclaimed-memory: 100000
低优的 BE 任务在使用 reclaimed 资源时只需在 Pod 增加“qos”和“reclaimed-resource”的表述即可其中 qos LS 对应高优先级qos BE 对应低优先级reclaimed-cpu/memory 为 BE Pod 的具体资源需求量。
# Pod
metadata:label:alibabacloud.com/qos: BE # {BE, LS}
spec:containers:- resources:limits:alibabacloud.com/reclaimed-cpu: 1000alibabacloud.com/reclaimed-memory: 2048 requests:alibabacloud.com/reclaimed-cpu: 1000alibabacloud.com/reclaimed-memory: 2048技术内幕
CPU 资源质量
CPU Burst Kubernetes 为容器资源管理提供了 Limit约束的语义描述对于 CPU 这类分时复用型的资源当容器指定了 CPU Limit操作系统会按照一定的时间周期约束资源使用。例如对于 CPU Limit 2 的容器操作系统内核会限制容器在每 100 ms 周期内最多使用 200 ms 的 CPU 时间片。
下图展示了一台 4 核节点、某 CPU Limit 2 的 Web 服务类容器在收到请求req后各线程Thread的 CPU 资源分配情况。可以看出即使容器在最近 1s 内整体的 CPU 利用率较低受 CPU Throttled 机制的影响Thread 2 仍需要等待下一个周期才能继续将 req 2 处理完成进而导致请求的响应时延RT变大这通常就是容器 RT 长尾现象严重的原因之一。 CPU Burst 机制可以有效解决延迟敏感性应用的 RT 长尾问题允许容器在空闲时积累一些 CPU 时间片用于满足突发时的资源需求提升容器性能表现目前阿里云容器服务 ACK 已经完成了对 CPU Burst 机制的全面支持。对于尚未支持 CPU Burst 策略的内核版本ACK 也会通过类似的原理监测容器 CPU Throttle 状态并动态调节容器的 CPU Limit实现与内核 CPU Burst 策略类似的效果。 CPU 拓扑感知调度
随着宿主机硬件性能的提升单节点的容器部署密度进一步提升进程间的 CPU 争用跨 NUMA 访存等问题也逐渐加剧严重影响了应用性能表现。在多核节点下进程在运行过程中经常会被迁移到其不同的核心考虑到有些应用的性能对 CPU 上下文切换比较敏感kubelet 提供了 static 策略允许 Guarantee 类型 Pod 独占 CPU 核心。但该策略尚有以下不足之处
static policy 只支持 QoS 为 Guarantee 的 Pod其他 QoS 类型的 Pod 无法使用。策略对节点内所有 Pod 全部生效而 CPU 绑核并不是”银弹“需要支持 Pod 粒度的精细化策略。中心调度并不感知节点实际的 CPU 分配情况无法在集群范围内选择到最优组合。
阿里云容器服务 ACK 基于 Scheduling framework 实现了拓扑感知调度以及灵活的绑核策略针对 CPU 敏感型的工作负载可以提供更好的性能。ACK 拓扑感知调度可以适配所有 QoS 类型并支持在 Pod 维度按需开启同时可以在全集群范围内选择节点和 CPU 拓扑的最优组合。
弹性资源限制reclaimed-resource
如资源模型中的描述节点 reclaimed-resource 的资源总量会跟随高优先级容器实际的资源用量动态变化在节点侧为了保障 LS 容器的运行质量BE 容器实际可用 CPU 数量同样受 LS 容器负载的影响。 如上图所示当 LS 容器资源用量上涨时受负载水位红线的限制BE 容器可用的 CPU 数量相应减少在系统层面会体现在容器 cgroup 分组的 CPU 绑定范围以及 CPU 时间片的分配限制。
内核Group Identity
Alibaba Cloud Linux 2 从内核版本 kernel-4.19.91-24.al7 开始支持 Group Identity 功能通过为容器设置不同的身份标识可以区分容器中进程任务的优先级。内核在调度不同优先级的任务时有以下特点
高优先级任务的唤醒延迟最小化。低优先级任务不对高优先级任务造成性能影响。主要体现在低优先级任务的唤醒不会对高优先级任务造成性能影响。低优先级任务不会通过 SMT 调度器共享硬件 unit超线程场景而对高优先级任务造成性能影响。Group Identity 功能可以对每一个容器设置身份标识以区分容器中的任务优先级。Group Identity 核心是双红黑树设计在 CFSCompletely Fair Scheduler调度队列的单红黑树基础上新增了一颗低优先级的红黑树用于存放低优先级任务。
系统内核在调度包含具有身份标识的任务时会根据不同的优先级做相应处理。具体说明如下表 LLC 及 MBA 隔离
在神龙裸金属节点环境容器可用的 CPU 缓存Last Level CacheLLC及 内存带宽Memory Bandwidth AllocationMBA可以被动态调整。通过对 BE 容器进程的细粒度资源限制可以进一步避免对 LS 容器产生性能干扰。
内存资源质量
全局最低水位线分级
在 Linux 内核中全局内存回收对系统性能影响很大。特别是时延敏感型业务LS和资源消耗型BE任务共同部署时资源消耗型任务时常会瞬间申请大量的内存使得系统的空闲内存触及全局最低水位线global wmark_min引发系统所有任务进入直接内存回收的慢速路径进而导致延敏感型业务的性能抖动。在此场景下无论是全局 kswapd 后台回收还是 memcg 后台回收都将无法处理该问题。 基于上述场景下的问题Alibaba Cloud Linux 2 新增了 memcg 全局最低水位线分级功能。在 global wmark_min 的基础上将 BE 的 global wmark_min 上移使其提前进入直接内存回收。将 LS 的 global wmark_min 下移使其尽量避免直接内存回收。这样当 BE 任务瞬间申请大量内存的时候会通过上移的global wmark_min 将其短时间抑制避免 LS 发生直接内存回收。等待全局 kswapd 回收一定量的内存后再解除 BE 任务的短时间抑制。
后台异步回收
在全局最低水位线分级后LS 容器的内存资源不会被全局内存回收影响但当容器内部紧张时会触发直接内存回收直接内存回收是发生在内存分配上下文的同步回收因此会影响当前容器中运行进程的性能。
为了解决这个问题Alibaba Cloud Linux 2 增加了容器粒度的后台异步回收功能。该功能的实现不同于全局 kswapd 内核线程的实现并没有创建对应的 memcg kswapd 内核线程而是采用了 workqueue 机制来实现并在 cgroup v1 和 cgroup v2 两个接口中均新增了控制接口memory.wmark_ratio。 当容器内存使用超过 memory.wmark_ratio 时内核将自动启用异步内存回收机制提前于直接内存回收改善服务的运行质量。
基于单机资源水位的驱逐
CPU 资源满足度
前文介绍了多种针对低优先级离线容器的 CPU 资源压制能力可以有效保障 LS 类型业务的资源使用。然而在 CPU 被持续压制的情况下BE 任务自身的性能也会受到影响将其驱逐重调度到其他空闲节点反而可以使任务更快完成。此外若 BE 任务在受压制时持有了内核全局锁这类资源CPU 持续无法满足可能会导致优先级反转影响 LS 应用的性能。
因此差异化 SLO 套件提供了基于 CPU 资源满足度的驱逐能力当 BE 类型容器的资源满足度持续低于一定水位时使用 reclaimed 资源的容器会按从低到高的优先级被依次驱逐。
内存阈值水位
对于混部场景的内存资源即便可以通过多种手段促使内核提前回收 page cache优先保障 LS 容器的资源需求。但在内存资源超卖情况下依然存在整机 RSS 内存用满导致 OOM 的风险。ACK 差异化 SLO 套件提供了基于内存阈值的驱逐能力当整机 Memory 使用率水位超过阈值时按优先级依次对容器进行 kill 驱逐避免触发整机 OOM影响高优容器的正常运行。
案例实践
使用 CPU Brust 提升应用性能
我们使用 Apache HTTP Server 作为延迟敏感型在线应用通过模拟请求流量评估 CPU Burst 能力对响应时间RT的提升效果。以下数据分别展示了 Alibaba Cloud Linux 2、CentOS 7 在 CPU Burst 策略开启前后的表现情况 对比以上数据可得知
在开启 CPU Burst 能力后应用的 RT 指标的 p99 分位值得到了明显的优化。对比 CPU Throttled 及利用率指标可以看到开启 CPU Burst 能力后CPU Throttled 情况得到了消除同时 Pod 整体利用率基本保持不变。
通过应用混部提升集群利用率
我们以“Web服务大数据”场景为例选择了 nginx 作为 Web 服务LS与 spark benchmark 应用BE混部在 ACK 集群的同一节点介绍 ACK 差异化 SLO 套件在实际场景下的混部效果。 对比非混部场景下的基线以及差异化 SLO 混部场景下的数据可以看出 ACK 差异化 SLO 套件可以在保障在线应用服务质量的同时性能干扰 5%提升集群利用率30%
对比“nginx 独立运行”与“差异化 SLO 混部”的 nginx 时延数据RT-p99 只有4.4%左右的性能下降。对比“spark 独立运行”与“差异化 SLO 混部”的 BE 任务运行时长即便在 BE 任务频繁受到压制的情况下总运行时间只上升了 11.6%。大数据集群提升资源利用率
相较于延时敏感型的在线服务大数据类型应用对资源质量的要求并不敏感“差异化 SLO 混部”可以进一步提升大数据集群的容器部署密度提高集群资源利用率缩短作业平均运行时间。我们以 Spark TPC-DS 评测集为例介绍 ACK 差异化 SLO 套件对集群资源利用率的提升效果。
以下数据展示了“差异化 SLO”功能在开启前后各项数据指标的对比情况
“差异化 SLO”功能开启后通过集群 reclaimed-resource 资源超卖模型集群内可以运行更多的 Spark 容器。集群 CPU 平均利用率由 49% 提升至 58%资源的充分利用使得评测集作业的总运行时间下降了 8%。总结
阿里云容器服务 ACK 支持差异化 SLO 的相关功能将在官网陆续发布各项功能可独立用于保障应用的服务质量也可在混部场景下共同使用。实践表明差异化 SLO 技术可以有效提升应用性能表现。特别是在混部场景下ACK 差异化 SLO 混部技术可以将集群资源利用率提升至相当可观的水平同时针对在线时延敏感型服务该技术可以将混部引入的性能干扰控制在 5% 以内。
原文链接
本文为阿里云原创内容未经允许不得转载。
