Scaling

Note: The content on this page pertains to Managed Game Server Hosting (Clanforge). If you’re using Game Server Hosting (Multiplay), see the Game Server Hosting (Multiplay) documentation.

One of Game Server Hosting's key offerings is the advanced scaling system. The scaling system uses scaling settings, cost scores, quality of service data, and data trends to ensure each fleet always has the ideal amount of game servers to accommodate player demand. It allows a fleet to scale up and down in response to a fluctuating player count.

In a traditional fleet configuration, the capacity in the fleet comprises a base-line of bare metal machines that are always available, and integrations with cloud providers that allow the fleet to burst into the cloud when the number of concurrent players exceeds the bare metal machine capacity.

Scaling Game Servers

The line in the preceding graph indicates the number of allocated game servers. When the solid line lowers below the dashed line, there is no need for capacity above the base-line of bare metal machines. When the solid line rises above the dashed line, there is more demand for game servers than the base-line that bare metal can support, so the reactive scaler bursts into the cloud. Because the game servers running on the bare metal machines are static, the total number of game servers within a fleet doesn't lower below the number of game servers hosted on bare metal (the dashed line represents this in the graph). Therefore, the total number of servers is independent from the number of allocated servers.

Scaling Total Game Servers vs Allocated Game Servers

An optional (but highly recommended) feature of the reactive scalers exists to keep a buffer of available servers, which keeps a gap between the total number of servers and the number of allocated servers. This enables players to quickly join a game session.

Managed Game Server Hosting (Clanforge) controls how fleets scale at the fleet region level through its reactive scaler and descaler components. These two components use information about the fleet regions, such as the current capacity and scaling configuration, to determine when to scale up or down. You can't edit the scaling or descaling configuration values without the help of a Partner Manager or the Multiplayer support team.

Scaling up

Game Server Hosting (Clanforge)'s reactive scaler determines when and how fleet regions increase capacity. For each fleet region, the reactive scaler loads the capacity and the fleet region settings. Fleets and fleet regions contain the following configuration values:

  • The minimum available servers
  • The minimum servers
  • The minimum standby servers
  • The maximum servers
  • The allocation timeout
  • The shutdown TTL
  • The delete TTL
  • The disabled delete TTL

Setting these values for a fleet region overrides the equivalent settings at the fleet level.

The reactive scaler uses the scaling configuration values to calculate the target buffer, and then compares it to the current buffer.

If the current buffer is less than the target buffer, then the reactive scaler starts standby (warm) capacity. If the reactive scaler exhausts all warm capacity, then it adds a cloud machine by using one of the configured cloud providers attached to the account. The reactive scaler selects the most cost-effective cloud providers based on a value called the cost score, and then uses a round-robin algorithm to select a provider. Each cloud provider has a cost score which the reactive scaler uses to prioritize the most cost-efficient cloud provider.

Scaling down

Game Server Hosting (Clanforge) manages descaling decisions with a component called the descaler. For each fleet region, the descaler loads capacity and fleet region settings. The fleet region settings contain all the scaling configuration values for that specific region within the fleet. Fleets and fleet regions contain the following configuration values:

  • The minimum available servers
  • The minimum servers
  • The minimum standby servers
  • The maximum servers
  • The allocation timeout
  • The shutdown TTL
  • The delete TTL
  • The disabled delete TTL

The descaler uses the scaling configuration values to calculate the target buffer, and then compares it to the current buffer.

If the current buffer is greater than the target buffer, then the descaler searches for unused machines by comparing their timestamps against the shutdown TTL value. If a machine has been unused for longer than the shutdown TTL value, then the descaler stops the machine.

After stopping the game servers on an unused machine, the descaler compares the capacity against the configured minimum standby value. If the number of existing standby game servers satisfies the minimum standby servers value, then the descaler compares the amount of time that the machine has been shut down to the delete TTL. If the machine has been shut down for longer than the delete TTL, then the descaler deletes the machine through the cloud provider’s API

Scaling example

Consider the following scaling example. You have a single fleet of five bare metal machines with the option to scale by adding cloud machines from a cloud provider. The fleet has a server density of 12, so each machine can host 12 game servers.

For simplicity, the fleet only has a single fleet region in which all machines reside. The following table shows the configuration values of the fleet region.

Minimum available servers:24 game servers
Minimum servers:60 game servers
Maximum servers:No maximum specified
Shutdown TTL:15 minutes
Delete TTL:1 week

The minimum available servers value is 24 because that’s the minimum number of game servers that should always be available for new players to join. The minimum servers value is set to 60 because that’s how many game servers exist on the five bare metal machines in the fleet. It's worth noting that the minimum available servers value doesn't necessarily need to equal the number of game servers running on bare metal machines.

If all the game servers on the five bare metal machines are in use, then the reactive scaler introduces two cloud machines to ensure that there are 24 available game servers. If only four of the bare metal machines are in use, then that would leave only one machine available with 12 available game servers. To reach the required 24 available game servers, the reactive scaler would add one cloud machine with 12 game servers.

When players end game sessions and game servers become available again, the descaler monitors the time the game servers that have been unused and compare it against the shutdown TTL value. The descaler shuts down a machine when all the game servers on it have been unused for at least the amount of time specified by the shutdown TTL. When a machine is in the shutdown state, it's considered warm capacity. After a cloud machine has been in the shutdown state for longer than the delete TTL, the descaler deletes the cloud machine.