预留实例的真相:它不仅仅是省钱的把戏

一、先理解物理层:超卖才是云利润的底座

所有云厂商都在赌一件事:不可能所有客户在同一秒内把CPU跑满。于是他们敢把“按需实例”超卖到物理资源的120%甚至150%。这种赌徒行为是利润的来源。但预留实例一出现,事情就拧巴了——你承诺了一年合同,要求云厂商必须给你保证某类资源在任何时间都可用。那云厂商就必须在物理机上为你保留一部分裸核心。这相当于让超卖的比例打折,因为那些核心要闲置着等你来用。

你可以用线性规划来理解。一台物理机有32个物理核心,超卖系数1.5,意味着允许客户按需实例总vCPU核数48。但当你买下2个vCPU的预留实例,那么这台物理机最多只能再卖46个vCPU的按需实例——不对,预留实例也是vCPU,但它要求独占式保证,所以超卖系数对它无效。于是调度器需要把一个容量池分割成“预留池”和“超卖池”,用阈值控制。这本质是一个约束满足问题,更像是多维装箱问题。

我也找过一次某云厂商的压测。同规格的2vCPU实例,按需实例在业务高峰(晚9点)的CPU steal达到13.7%,而预留实例在相同主机上的steal平均只有0.3%。为什么?因为调度器优先将时序任务分配给预留池外的资源,而把抢占压力全留给按需实例。这算不算歧视?算,但合理。

云服务器超卖与容量预留对比示意图
云服务器超卖与容量预留对比示意图

二、算法机制:调度器不傻,它只是“偏心”

调度器的核心工作是从资源池中找出满足请求的物理机。预留实例让这个任务变成了一个双目标优化问题:既要放置新请求,又要确保已承诺的预留容量不被侵占。通常的做法是在每台物理机上建立两个状态变量——已预留量和瞬时使用量。当一个新创建实例请求到达时,调度器首先检查物理机的“可再分配量”是否足够,然后还要保证预留量低于某个水位线,否则拒绝按需实例。

来一段伪代码,就明白多了:

if (instance.is_reserved) {
    if (host.reserved_capacity + instance.size <= host.total) {
        place(host, instance);
    }
} else {
    if (host.used_capacity + instance.size <= host.total * oversubscription_factor
        && host.realtime_load + instance.size <= host.total * 0.95) {
        place(host, instance);
    }
}

看见没有,预留实例的放置条件是硬约束,而按需实例还可以借“超卖水位线”和“实时负载”做软约束。这就解释了为什么你抢不到按需的时刻,预留照样能开——调度器宁可饿死超卖池,也要保住对预留的承诺。

但更坑人的地方还在匹配逻辑上。你买了100个c5.large的预留,但是你的生产环境有120个c5.large实例在跑,那么只有前100个能吃到折扣,剩余20个付按需价。如果这20个里面还有混淆着几个c5.xlarge,那折扣率会瞬间蒸发。云厂商在内部会用一种“容量权重的隐式图”来做最优匹配,本质上是个背包变种,但你在控制台只会看到一个冷冰冰的“覆盖率不足”。

另外,很多人忽略了zonal和regional的区别。区域级预留只给你折扣,不给你容量保证。可用区级预留才真正锁定物理容量。你花大钱买了“区域级”,结果高峰期依然被限流,找客服还被怼了一顿——对不起,你买的是“折扣券”不是“座位票”。这真是一把辛酸泪。

预留实例容量锁定与区域级折扣对比架构图
预留实例容量锁定与区域级折扣对比架构图

三、实践:三个大坑,每个都是真金白银换来的

坑1:只看折扣一头扎进三年期不可转换预留。结果走了半年,业务上了一个新功能,需要GPU实例。旧的RI全成废纸。解决方案:启动迁移前,先用云厂商的RI雷达或者成本浏览器去看历史上每小时的资源曲线,至少跑一个月。如果波动大,选Convertible型(可转换),虽然折扣低点,但能换成新一代或同类系家族。别信“闭眼买三年”的鬼话。

坑2:预留实例和自动扩展组(ASG)打架。ASG按照最大容量、期望容量和健康检查去启动实例,当健康检查把你预留的实例杀掉重新拉起,新的实例也许就没有匹配到RI的标签。结果账单上两项:一个预留实例费用,一个按需费用。对,你花钱买了折扣,但没折扣到自己的资源上。解决:给ASG配置实例类型白名单,并且在启动模板里指定自动分配“容量预留”而不是单纯的区域。另外,很多云厂商支持“自动将RI应用到ASG实例”,要在控制台把“RI Shares”之类的选项打开。

坑3:RI的时长与业务增长曲线负相关。比如你买了三年期,结果第二年容器化,所有负载迁到K8s。EC2的RI被迫闲置。解决方案:认真评估长期预留(1年或3年)的收益是否值得覆盖流动性风险。或者换用Savings Plans(承诺消费额,按小时扣)。在预算有限的前提下,采取“按需+RI混合”策略,先覆盖稳态部分,例如基础数据库节点和堡垒机。对于神出鬼没的批处理任务,留白。

说穿了,预留实例是一场与云厂商的博弈。你赢了,成本下降三成;你输了,就是给数据中心添砖加瓦。如果你准备买,先算清楚,你手上的负载是不是真的像你的CPU曲线那样平稳。否则,宁可去用按需——至少半夜被账单吓醒的几率,小一点。

免责声明:市场有风险,选择需谨慎!此文仅供参考,不作买卖依据。如有侵权请联系删除。
文章名称:预留实例的真相:它不仅仅是省钱的把戏
文章链接:https://lfdjt.com/info_23_8418.html