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.
You can reserve and unreserve payloads with the following:
- The zeuz base API which uses HTTP: see the API Reference documentation on the
- 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:
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:
Min. machine spec
Note: Payload quota is how many cores one payload requires to run.
Free payload capacity
- Unreserved payloads: The number of active payloads 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. The scaler keeps the amount of available machine resource within your specified range (in this example, between 2-4 payloads). 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.
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.
A single machine (server hardware unit) (either 1 bare-metal machine or 1 cloud server)
- 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. 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. The scaler uses this spare capacity for the 2 unreserved payloads you specified. This leaves no free payload capacity on the machines.
Your scaling rules require a minimum of 2 free payload capacity. To accommodate this, the scaler allocates 1 new machine. In the hardware configuration rules, you specified that each machine has the capacity for 4 free payloads. This means that the new machine meets the minimum of 2 free payload capacity.
Image: 6 reserved payloads and 2 unreserved payloads on 3 machines.
- 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.
Image: 8 reserved payloads and 2 unreserved payloads on 3 machines.
- 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.
Image: 9 reserved payloads and 2 unreserved payloads on 3 machines. There is no longer enough payload capacity.
These machines only have 1 free payload capacity, and you have a scaling rule of a minimum 2 free payload capacity. Therefore, the scaler allocates a new machine, as shown in the following image:
Image: 9 reserved payloads and 2 unreserved payloads on 4 machines.
This gives you a free payload capacity of 5, consisting of the following:
- 1 free payload capacity on the third existing machine
- 4 free payload capacity on the new machine
This meets your scaling rule of a minimum 2 free payload capacity.
You also specified a maximum of 4 free payload capacity. The scaler cannot meet this rule at the same time as your rule for 2 minimum free payload capacity. When the scaler cannot meet both of these rules, it prioritizes the minimum free payload capacity.
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.
2021-feb-22 Example updated to correct error about unreserved payloads.
2020-dec-03 Page created with editorial review.
Updated 12 days ago