GameLift FleetIQ lifecycles and states - Amazon GameLift

GameLift FleetIQ lifecycles and states

Spot balancing process

GameLift FleetIQ periodically balances the instances in anAuto Scaling group that has Spot Instances. This process is not active with game server groups that use the ON_DEMAND_ONLY balancing strategy or do not have any active instances.

Spot balancing has two key goals:

  • To constantly refresh the group by only using Spot Instance types that are viable for game hosting.

  • To use multiple viable instance types (where possible) in order to reduce the impact of unexpected game server interruptions.

GameLift FleetIQ balances by evaluating the group's instance types and removing instances that are more likely to result in game server interruptions. To avoid terminating instances with active gameplay during balancing, best practice is to turn on game server protection for a game server group that's in production.

The following example illustrates how instances in an Auto Scaling group are affected by Spot balancing.


                    Lifecycle of an Auto Scaling group during GameLift FleetIQ balancing.
  • Step 1. Through a game server group, the linked Auto Scaling group is set up to launch instances of types m4.large, c4.large, and c5.large with game server protection enabled. The Auto Scaling group has launched a balanced collection consisting of two Spot Instances of each type. Four instances have at least one game server in UTILIZED status (shown with a dashed border), while two instances are not currently supporting gameplay.

  • Step 2. GameLift FleetIQ evaluates the current game hosting viability of all three instance types. The evaluation determines that the c4.large instance type has an unacceptable potential for game server interruption. GameLift FleetIQ immediately updates the Auto Scaling group configuration to temporarily remove c4.large from the list of instance types, preventing additional c4.large instances from being launched.

  • Step 3. GameLift FleetIQ identifies existing instances of type c4.large and takes actions to remove them from the group. As a first step, all game servers that are running on c4.large instances are flagged as draining. Game servers on draining instances can be claimed only as a last resort if no other game servers are available. In addition, an Auto Scaling group with draining instances is triggered to launch new instances to replace them.

  • Step 4. As new viable instances come online, the Auto Scaling group terminates draining instances. This replacement ensures that the group's desired capacity is maintained. The first instance to be terminated is the c4.large instance with no utilized game servers and game server protection turned off. It is replaced with a new c5.large instance.

  • Step 5. Draining instances with game server protection continue to run while their game servers are supporting gameplay. When gameplay ends, the remaining c4.large instance is terminated when a new m4.large instance has launched to take its place.

As a result of this process, the Auto Scaling group maintains its desired capacity while the group balances from using three instance types to two. GameLift FleetIQ continues to evaluate the original list of instance types for game hosting viability. When c4.large is again considered a viable instance type, the Auto Scaling group is updated to include all three instance types. The group naturally balances over time.

Life of a game server group

Game server groups go through the following lifecycle, including provisioning and status updates. A game server group is expected to be a long-lived resource.

Lifecycle of a game server group resource.
  • You create a game server group by calling the GameLift API CreateGameServerGroup() and passing in an EC2 launch template and configuration settings. In response to the call, a new game server group is created and placed in status NEW.

  • GameLift FleetIQ activates an asynchronous activation workflow, transitioning the game server group status to ACTIVATING. The workflow initiates the creation of underlying resources, including an Amazon EC2 Auto Scaling group and an EC2 instance with the provided AMI.

    • If provisioning fails for any reason, the game server group is placed into status ERROR. To get additional error information to help debug the failure cause, call DescribeGameServerGroup() on a game server group in an error state.

    • If provisioning succeeds, the game server group is transitioned to status ACTIVE. At this point, instances are launched with game servers that register with GameLift FleetIQ. The group's instance types are periodically evaluated for game hosting viability and balanced as needed. GameLift FleetIQ also tracks the status of active game servers in the group and responds to requests for game servers.

  • You remove a game server group by calling DeleteGameServerGroup() with the group identifier. This action puts the game server group into status DELETE_SCHEDULED. Only game server groups in ACTIVE or ERROR state can be scheduled for deletion.

  • GameLift FleetIQ activates an asynchronous deactivation workflow in response to the DELETE_SCHEDULED status, transitioning the game server group status to DELETING. You have the option of deleting just the game server group or delete both the game server group and the linked Auto Scaling group.

    • If deactivation fails for any reason, the game server group is placed into status ERROR. To get additional error information to help debug the failure cause, call DescribeGameServerGroup() on a game server group in an error state.

    • If deactivation succeeds, the game server group is transitioned to status DELETED.

Life of a game server

With GameLift FleetIQ, game servers go through the following lifecycle, including provisioning and status updates. A game server is expected to be a short-lived resource. As a best practice, game servers should be de-registered after the end of a game session rather than being re-used for another game session. This approach helps ensure that available game servers are always running on the lowest-cost resources that are viable for game hosting.

  • A game server resource is created when the game server process, running on an instance in a GameLift FleetIQ-linked Auto Scaling group, calls the GameLift API RegisterGameServer() to notify GameLift FleetIQ that it is ready to host players and gameplay. A game server has two statuses to track its current availability:

    • Utilization status tracks whether the game server is currently supporting gameplay. This status is initially set to AVAILABLE, indicating that it is ready to accept new gameplay. Once the game server is occupied with gameplay, this status is set to UTILIZED.

    • Claim status tracks whether the game server is claimed for imminent gameplay. A game server in CLAIMED status indicates that it has been temporarily reserved by a game client (or a game service such as a matchmaker). This status prevents GameLift FleetIQ from providing the same game server to multiple requesters. A game server with a blank claim status is available to be claimed.

  • The following diagram illustrates how a game server's utilization status and claim status change over its life span.

    
                            Lifecycle of a game server resource.
    • Step 1. A game server group has six registered game servers. Four have a utilization status AVAILABLE (A, B, C, and D), and two are currently UTILIZED (E and F).

    • Step 2. A game client or matchmaking system calls the GameLift API ClaimGameServer() to request a new game server. This request prompts GameLift FleetIQ to search for an available game server (D) and set its claim status to CLAIMED for 60 seconds. GameLift FleetIQ responds to its request with connection information for the game server (IP address and port), as well as other optional game-specific data. Since gameplay has not yet begun on the game server, its utilization status remains AVAILABLE, but it cannot be claimed with another request.

    • Step 3a. Using the connection information provided, game clients can connect to the game server and initiate gameplay. The game server (D) must be triggered within 60 seconds to change its utilization status to UTILIZED by calling the GameLift API UpdateGameServer().

    • Step 3b. If the game server's utilization status is not updated within 60 seconds, the claim timer expires and the claim status is reset to blank. The game server (D) is returned to the pool of available and unclaimed game servers.

  • A game server resource is removed after gameplay on the game server is complete and players have disconnected. Before shutting down, the game server process calls the GameLift API DeregisterGameServer() to notify GameLift FleetIQ of its departure from the game server group's pool of game servers.