负载伸缩

zeuz 扩容管理器根据您在 配载 中指定的硬件配置和 伸缩规则负载 装入裸机或云服务器中,扩容管理器 调配裸机、启动或关停云服务器,以确保分配负载的数量满足您的需求。

如需更多指导,请参阅 硬件配置

  • 已分配负载是运行游戏服务器并连接到玩家的负载实例。
  • 待分配负载是运行游戏服务器但尚未连接到玩家的负载实例。准备就绪等待玩家快速连接。
  • 负载槽是负载的机器托管容量,一个负载槽可容纳一个负载。

您可以通过以下方式对负载进行分配操作:

  • 基于 HTTP 协议的 zeuz 基础 API:请参阅 API 参考文档中的 payload_reserve 和 payload_unreserve 端点。
  • 您可以通过 zeuz 工具或使用 zeuz 控制面板 > Payloads 页面上,调用游戏服务器可执行文件中的 API。
  • Golang SDK:该 SDK 为 zeuz SDK omnibus 软件包 的一部分。

如果您设置了 混合云,那么扩容管理器将自动分配裸机和云服务器,为您提供最优性价比。这兼具了裸机的低成本和云服务器的灵活性。

注意:在混合云配置中,裸机可能无法立即用于新启用配载的负载。在这种情况下,zeuz 会先在云服务器上运行负载,与此同时继续尝试找寻可用的裸机。一旦找到可用裸机,zeuz 会优先为配载选用裸机,被选用的裸机将持续与配载绑定,直至您禁用该配载或将其配置为仅使用云服务器。zeuz 通过这种方式减少对云服务器的依赖,最大限度地提高成本效益。

更多信息,请参阅配载设置的相关文档:

实现示例

该部分借以下示例阐明扩容管理器如何实现您的硬件配置和伸缩规则。

本例中,您已在 zeuz 控制面板的 创建配载 页面中指定了下列规则:

Hardware configuration (硬件配置)

Min. machine spec (最低机器规格)Payload quota (负载配额)
Core count (核数)4 个虚拟核1 个虚拟核

注意负载配额 是一个负载运行所要求的核数。

Scaling rules (伸缩规则)

Free payload capacity (可用负载空位)
2-4
Unreserved payloads (待分配负载)
2-4

注意

  • 待分配负载:已启动且预运行但尚未连接玩家的活跃负载数量 (已用 负载槽)。它们提供备用的 游戏服务器 容量,当您的游戏需要新的游戏服务器时,待分配负载随时可用。
  • 可用负载空位:随时保持未使用和可用状态的 机器 资源,以负载 (可用负载槽) 为单位。扩容管理器将可用负载槽的数量维持在您指定的范围内 (本例中,可用负载槽的数量保持在 2-4 之间)。指定范围中,最小值确保您始终有一部分服务器准备就绪,与此同时最大值方便您管控成本。

扩容管理器的实现

下方图表显示了扩容管理器如何根据您的上述规格和已分配负载的数量,来分配服务器空间 (裸机或云服务器)。

图例

对象描述
11 台机器 (1 组服务器硬件) (1 个裸机或 1 个云服务器)
2已分配负载
3待分配负载
4可用负载空位

阶段 1

  • 您分配了 6 个负载。

由于您指定每个机器必须有 4 个核 (最低机器规格),且每个负载需要 1 个核 (负载配额),因此每个机器都有 4 个负载的容量 (4 个负载槽)。为符合您的设置,zeuz 扩容管理器对服务器空间的分配如下:

  • 如果您仅使用裸机,那么会分配 2 个裸机。
  • 如果您使用混合云,那么会分配或启用裸机与云服务器的组合方案如下: 2 个裸机、2 个云服务器、或裸机和云服务器各 1 个。
    • 扩容管理器会优先分配裸机,直到您在与 zeuz 签订的支持协议中为裸机指定的全部容量被用完时,再启用云服务器。

注意:本例中,我们将 1 个裸机或 1 个云服务器成为 1 台机器。

其中 1 台机器上会有 2 个负载的备用容量 (2 个可用负载槽),扩容管理器将此备用容量用于您指定的 2 个待分配负载,这样一来就没有可用负载槽了。 您在伸缩规则中指定了至少 2 个可用负载槽。为符合您的设置,扩容管理器分配 1 台新机器。在硬件配置规则中,您指定了每台机器有 4 个负载槽的容量,这意味着新机器能满足至少 2 个可用负载槽的需求。

图像:6 个已分配负载、2 个待分配负载和 4 个可用负载槽位于 3 台机器上

阶段 2

  • 您在初始 6 个已分配负载的基础上再分配 2 个负载,总计 8 个已分配负载。

扩容管理器进行如下操作:

  • 将 2 个待分配负载转化为已分配负载。
  • 启动 2 个新的待分配负载,剩余 2 个可用负载槽。

图像:8 个已分配负载、2 个待分配负载和 2 个可用负载槽位于 3 台机器上

阶段 3

  • 再分配 1 个负载,总计 9 个已分配负载。

扩容管理器进行如下操作:

  • 将 1 个待分配负载转化为已分配负载。
  • 再启动 1 个待分配负载,剩余 1 个可用负载槽。

图像:9 个已分配负载、2 个待分配负载和 1 个可用负载槽位于 3 台机器上 (此时已没有足够的负载容量满足伸缩规则中指定的需求)

现有机器仅剩余 1 个可用负载槽,而您的伸缩规则中指定了至少 2 个可用负载槽。因此,扩容管理器分配 1 台新机器以满足可用负载槽的需求,如下图所示:

图像:9 个已分配负载、2 个待分配负载和 5 个可用负载槽位于 4 台机器上

这样一来就包含了下列 5 个可用负载槽:

  • 现有的 3 台机器上有 1 个可用负载槽
  • 新机器上有 4 个可用负载槽

由此满足了您指定的至少 2 个可用负载槽的伸缩规则。

此外,您还指定了至多 4 个可用负载槽,但在此例中,扩容管理器无法同时满足您指定的可用负载槽的上限和下限。当扩容管理器不能同时满足上下限时,会优先满足可用负载槽的下限。


2021年8月24日 该文档已更新并通过审校:根据 zeuz 术语阐明示例

2021年6月10日 该文档已更新并通过审校:在介绍中添加混合云注释

2021年5月19日 该文档已更新并通过审校:阐明 zeuz 术语


最近更新时间: October 21, 2021 (0439de66)