Payload scaling

The zeuz scaler fits payloads into bare-metal machines or cloud servers, depending on the hardware configuration and scaling you specify for your allocation. The scaler allocates bare-metal machines, or spins cloud servers up or down, to accommodate the number of payloads you reserve.

(See documentation on Hardware configuration for further guidance on this.)

  • A reserved payload is a payload instance which runs a game server that is connected to players.
  • An unreserved payload is a payload instance which runs a game server that has no players connected to it. It is ready to quickly accept players when you need it to.
  • A payload slot is hosting machine capacity for one payload.

You can reserve and unreserve payloads with the following:

  • The zeuz base API which uses HTTP: see the API Reference documentation on the payload_reserve and payload_unreserve endpoints.
  • You can call this API from within your game server executable, with zeuz tool or in the zeuz control panel > Payloads page
  • The SDK in Golang: available as part of the zeuz SDK download omnibus package.

If you set up Hybrid Cloud, then the scaler automatically chooses between bare-metal machines and cloud servers to give you the best value for money. This provides the cost-efficiency of bare-metal machines and the flexibility of cloud servers.

Note: In a Hybrid Cloud configuration, a bare-metal machine may not be immediately available to the payloads of a newly enabled allocation. In this situation, zeuz runs these payloads on cloud servers. At the same time, zeuz continues trying to find an available bare-metal machine. Once a bare-metal machine is available, zeuz selects it for the allocation. The bare-metal machine remains tied to the allocation until you disable the allocation or configure it to be cloud-only. zeuz does this to reduce the reliance on cloud servers and maximize cost-efficiency.

For more information, see the documentation on allocation settings:

Example implementation

This is an example of how the scaler implements your hardware configuration and scaling rules specification.

In this example, you have specified the following rules in the Create allocation page of the zeuz control panel:

Hardware configuration

Min. machine specPayload quota
Core count4 VCORES1 VCORES

Note: Payload quota is how many cores one payload requires to run.

Scaling rules

Free payload capacity
2-4
Unreserved payloads
2-4

Note:

  • Unreserved payloads: The number of active payloads (used payload slots) you want started and pre-running but not connected to players. They provide spare game server capacity that is ready for when a new game server is needed for your game.
  • Free payload capacity: The amount of unused machine resource available at any time, measured in payloads (available payload slots). The scaler keeps the number of available payload slots within your specified range (between 2-4 in this example). This range allows you to maintain a specific minimum amount of server readiness and at the same time manage the cost, by specifying the maximum amount that is kept ready at any time.

Scaler implementation

The following images show how the scaler allocates server space (bare-metal machines or cloud servers) according to your specifications above and the number of payloads you reserve.

Legend

ItemDescription
1A single machine (server hardware unit) (either 1 bare-metal machine or 1 cloud server)
2Reserved payload
3Unreserved payload
4Available payload slot

Stage 1

  • You reserve 6 payloads.

Because you specified that a machine must have 4 cores and each payload requires 1 core (the payload quota), each machine has the capacity for 4 payloads (4 payload slots). To accommodate this, the zeuz scaler allocates machine space as follows:

  • If you are using only bare-metal machines, it allocates 2 bare-metal machines.
  • If you are using Hybrid Cloud, it allocates or spins up a combination of bare-metal machines and cloud servers. This might be 2 bare-metal machines, 2 cloud servers or 1 of each.
    • The scaler allocates bare-metal machines first, until it has used up all the capacity you specified for bare-metal machines in your support agreement with zeuz, and then it spins up cloud servers.

Note: In this example, we refer to one bare-metal machine or cloud server as a machine.

This leaves spare capacity on one machine for 2 payloads (2 available payload slots). The scaler uses this spare capacity for the 2 unreserved payloads you specified, leaving no available payload slots. To accommodate your scaling rule’s requirement for a minimum of 2 available payload slots, the scaler allocates 1 new machine. In the hardware configuration rules, you specified that each machine has the capacity for 4 payload slots. This means that the new machine meets the minimum capacity for 2 available payload slots.

Image: 3 machines with 6 reserved payloads, 2 unreserved payloads, and 4 available payload slots.

Stage 2

  • You reserve 2 more payloads in addition to the original 6 payloads, making 8 reserved payloads in total.

The scaler does the following:

  • Converts the 2 unreserved payloads into 2 reserved payloads.
  • Starts 2 new unreserved payloads, leaving 2 available payload slots.

Image: 3 machines with 8 reserved payloads, 2 unreserved payloads, and 2 available payload slots.

Stage 3

  • You reserve 1 more payload, making 9 in total.

The scaler does the following:

  • Converts 1 unreserved payload into a reserved payload.
  • Starts an additional unreserved payload, leaving 1 available payload slot.

Image: 3 machines with 9 reserved payloads, 2 unreserved payloads, and 1 available payload slot. There is no longer enough payload capacity to meet the requirements you defined in your scaling rules.

These machines only have 1 payload slot available, and because your scaling rules require a minimum of 2 available payload slots, the scaler allocates a new machine, as shown in the following image:

Image: 4 machines with 9 reserved payloads, 2 unreserved payloads, and 5 available payload slots.

This gives you 5 available payload slots, consisting of the following:

  • 1 available payload slot on the third existing machine.
  • 4 available payload slots on the new machine.

This meets your scaling rule of a minimum 2 available payload slots.

Your scaling rule also specified a maximum of 4 payload slots. However, the scaler cannot provide this plus the minimum of 2 available payload slots. When the scaler cannot meet both of these rules, it prioritizes the minimum number of available payload slots required.


2021-aug-24 Page updated with editorial review: clarified Example and zeuz terms.

2021-jun-10 Page updated with editorial review: added Hybrid Cloud note to introduction.

2021-may-19 Page updated with editorial review: clarification of zeuz terms.


Last edited on: October 14, 2021 (bc201402)