摘要

  • Google Cloud 在 9 月 8 日宣布，Compute Engine 单项目预留与共享预留之间的转换正式可用，改变的是谁能使用已有容量，不是容量总量。
  • 共享本身不另收费，闲置资源仍然计费。把被其他项目实例明确指定使用的共享预留收回为单项目预留，还须处理这些实例的运行与恢复条件。

先改变使用者，再检验利用率

一支团队为未来任务留下的算力，可能正是另一支团队今天需要的资源。Google Cloud 此次更新给了管理者调整使用范围的办法。9 月 8 日的 Compute Engine 更新记录将预留共享类型转换标为正式可用：符合条件的单项目预留可以改为共享预留，也可以反向转换。

新意不在于首次提供共享预留，而在于两种类型之间可以切换。它也不是向其他机构转卖算力的市场。修改文档规定，共享范围最多涉及同一组织内的 100 个项目，且共享预留须从创建它的项目进行修改。使用者变了，预留的所有者项目并不会随之转移。

这里的“项目”是云内的资源和管理单位，并非一座数据中心。对集中管理算力的团队而言，机会在于让兼容的内部需求使用原本闲置的资源。共享既没有增加预留容量，也没有取消权限或配额要求。

谁用资源，谁承接相应账单

Google 的预留说明写得很清楚：只要预留存在，其资源无论使用与否都会产生费用；虚拟机使用这些资源时，不会对同一份预留资源重复收费。

共享本身不增加一项额外收费。默认由所有者项目承担账单，其他消费项目使用共享资源时，相应资源改由消费项目计费。可适用的承诺使用折扣等定价安排仍可能影响价格。因此，改变使用范围不是新折扣，也不能保证不同项目承担完全相同的单价。

可以设想，甲团队为稍后的任务保留容量，乙团队眼下有兼容任务。这只是解释机制的假设，并非 Google 披露的客户成效。共享可能让一部分闲置资源被利用；但两支团队随后同时需要容量时，资源池仍是有限的。设置本身无法替企业决定哪个任务更重要。

把共享收回，不能忽略已经接上来的任务

反向操作更值得细看。对于实例明确指定使用的共享预留，文档要求：转为单项目预留前，消费项目中正在使用该预留的实例须先停止、挂起或删除。这项要求不适用于所有者项目内的实例。

文档还有恢复条件。已停止或挂起、仍明确指定该共享预留的消费项目实例，在具备替代预留前不能重启或恢复；替代预留须处在原所有者项目和可用区，名称相同，属性匹配。这是在报道产品的依赖约束，不是在建议删除工作负载，也不是说已经发生了客户故障。它更不能被扩大为所有自动使用共享容量的实例都必须停机。

附带承诺的预留另有替换流程，自动生成的未来预留也有各自限制。此次正式可用不代表所有预留类型、容量安排或商业承诺都能任意改写。

灵活性确实增加了，但“可以调整使用权限”与“能够无代价地撤回别人已经依赖的容量”，是两件事。