Skip to main content

Allocations

IMS zeuz operates on declarative specifications of game servers known as Allocations. An Allocation is responsible for creating, running and deleting Payloads dynamically to scale with your game server demand.

How does an allocation work?​

When an Allocation is defined, the system will continuously monitor it to ensure the desired state of the Allocation is satisfied. How does it do that?

  1. Find all running Payloads in this Allocation
  2. If there are fewer (or more) payloads in Ready state than defined in the Buffer Size, the system ensures payloads are created (or deleted). During this action, the system also takes into account the specified Min payloads and Max payloads properties and the total number of payloads will never go below (or exceed) these thresholds. Only payloads which are not Reserved will be automatically scaled by the system.
  3. Collect information about each payload running to compute an Allocation Status.

Allocation statuses​

string (v0AllocationStatusState)
Default: "Unknown"
Enum: "Unknown" "New" "Updating" "Running" "Draining" "Stopped" "Deleted" "Error" "Disabled"

Name of the allocation state.

  • Unknown: The allocation is in an unknown state.
  • New: The allocation is newly created and has not yet been processed by the system.
  • Updating: The allocation is adjusting to match the desired state. The Allocation is generally in an Updating state when you edit it before it is fully reconciled.
  • Running: The allocation is running. There are payloads which have successfully started.
  • Draining: The allocations is draining. This state can be entered by disabling or deleting an Allocation. Before the Allocation is disabled or deleted, it will wait for all Reserved payloads to complete.
  • Stopped: The allocation stopped and has no more payloads running.
  • Deleted: The allocation has been deleted. It is still available in the system for some time, but there are no compute resources used by the allocation.
  • Error: The Allocation has reached an Error state - inspect the details of the error status. You can always edit the Allocation to correct the Error and the system will attempt to reach a Running state again.
  • Disabled: The allocation is disabled. There are no computing resources attached to the allocation.
"Unknown"

Defining an allocation​

An Allocation has a range of properties which configure, and customize, the Allocations behaviour.

General properties​

  • Name: How do you want to call the allocation? This is used only by humans to find the Allocation.
  • Region: The region in which the allocation should be created. To add a region speak to your Account Manager.
  • Annotations: (optional) Arbitrary set of key:value pairs attached to the allocation, this data does not get added to payloads.

Game server properties​

  • CPU: How much CPU do you expect each Payload to use?
    • Examples: 1.5 (one and a half CPU cores), 200m (200 millicores).
  • Memory: How much memory do you want each Payload to have?
    • This is not a hard limit for the payload. It's used to determine how many payloads can fit on a machine.

      Examples: 100Mi, 1Gi. Careful: 100m (lowercase m) means 0.1 byte. See resource units in kubernetes for more details.

  • Ports: Specify ports. Each port has a name, internal port number, protocol and policy.

Port policies​

See the different port policies and how to use them in Port policies.

Scaling properties​

  • Buffer size: How many Ready payloads should the system try to maintain?
    • Can either be a fixed number (10), or a percentage (10%).

      A percentage buffer size will try to ensure that x% of all running payloads are in a Ready state. This is useful for scaling the buffer size based on current demand.

  • Min payloads: What is the minimum number of payloads (reserved and unreserved) the system should run?
    • This can be increased to pre-scale the number of available payloads, e.g. before a launch or playtest.
  • Max payloads: What is the maximum number of payloads (reserved and unreserved) the system should run?
    • The system won't scale beyond this amount of payloads, even the buffer is depleted.

Game image properties​

  • Image: URL of your game Image - this contains your server build.
  • Command: (optional) Specify the command to run when your container starts.
  • Arguments: (optional) Specify additional arguments to the command above.