Introduction to Armada (Deprecated)
Armada is deprecated. It is replaced by AccelByte Multiplayer Servers (AMS), our next-generation dedicated server orchestration product. Ask your AccelByte account team about enabling AMS for your environments.
Overview
AccelByte Gaming Services (AGS) Armada is a dynamic game server manager that enables you to provide dedicated game servers as close as possible to your players. Armada allows you to have multiple fleets of servers, each with its own scaling behavior, that can be spread across different regions.
Armada allows you to take advantage of several features designed to ensure your players have the best gaming experience:
- Easy to integrate: Armada has been designed to stay out of the way of your regular server development. By using the AGS Game SDK, you will only need to call one API explicitly to make Armada work for you.
- Multi-region: Armada has been designed for greater global coverage and better game performance across more geographic regions. With Armada, you can maintain a separate server fleet size per region, allowing you to save costs by adjusting the fleet size according to your regional demand.
- Elastic demand-based scaling: Armada scales based on your players' demand per region at any specific time. This ensures your virtual machine cost in the region is minimized when it has less demand while ensuring that there are always resources available when the region is at peak capacity.
- Warmed dedicated servers: Armada enables you to preload and maintain up-and-running dedicated servers for each region, so that they can be claimed immediately by a game session without the need for its players to wait for a server to load.
- Integrated matchmaking and lobby: Armada connects directly with AGS Matchmaking and Lobby to provide geolocation support, so you can match players in the same region for an optimal player experience. If you are already using different matchmaking and lobby services, AccelByte will work with you to integrate Armada into them.
Key concepts
It is important to understand the key concepts used in the design of AGS Armada.
Dedicated server
A disposable game server that hosts one game session. The dedicated server is discarded and replaced with a new one by Armada once it has finished serving a game session. Not to be confused with a peer-to-peer (P2P) server.
Dedicated server manager
The dedicated server manager works out the regional server demands and makes requests to the server orchestrator.
Fleet
A collection of dedicated game servers, active or idle, to serve game sessions. Fleets are usually maintained separately in each regional cluster.
Quality of service
Each regional cluster will have its own quality of service servers that are used to verify the performance between your players' location and the regional cluster. This data is used to find out the best region for your players to play in.
In practice, once your game has integrated with the AGS Game SDK, the SDK will automatically ping each of the available regions to keep the connection data updated for you.
Regional cluster
A regional cluster is a server cluster located in a region that is responsible for running your dedicated servers.
Server orchestrator
The orchestrator spins dedicated servers on virtual machines that reside in a regional cluster based on your deployment configurations. It is also responsible to scale out and scale in virtual machines to make sure there is always hardware to fulfill a game's demands.
Nomad is used as Armada's primary orchestrator.
Virtual machine
The host to run your dedicated servers, usually sourced from a cloud provider. Virtual machines are managed by the server orchestrator and its information is abstracted from you. Contact your DPM if you want to know more about the underlying setup and possibly make changes to it.
Autoscaling strategy
Used with Armada, this is the strategy which the server orchestrator uses to acquire or return virtual machine instances to their provider. There are the three autoscaling strategies that Armada uses, each with their own pros and cons:
- Threshold: the scaling will be activated when the total resource usage exceeds the threshold value, then the orchestrator will scale out virtual machines by a fixed number. This is often used in a development environment where demands are usually static.
- Target Value: the scaling will be activated when the total resource usage exceeds the threshold value, then the orchestrator will scale out virtual machines dynamically based on the current number of virtual machines in use. This is often used in a production environment where demands usually follow a bell curve.
- Target Demand: the scaling will be activated whenever the demand changes, then the orchestrator will scale out virtual machines to match the demand. This is usually used in a product environment where large spikes of traffic are expected.
Dedicated server states
The dedicated server states keep track of the life cycle of a dedicated server. The states are:
- Creating
- Ready
- Busy
- Unresponsive
- Removing
The changes of states are shown in the following diagram:
Deployment
A deployment describes how you want your dedicated servers to spin up in a region. Each deployment contains:
- The dedicated server image version to be used
- The pod configuration to run the dedicated server image
- Various scaling options
Pod configuration
A pod configuration describes how much CPU and memory resources your dedicated server takes to run, and the effect of command line arguments that your dedicated server uses.
The orchestrator will make use of this information to determine whether there are enough hardware resources to host your dedicated servers, and, if necessary, to scale out one of your regional clusters.
Timeouts
Timeouts are time limits that are applied to your dedicated servers during some of the states in their life cycles. All these timeouts are configurable in the AGS Admin Portal.
Creation timeout
The creation timeout starts when Armada spins up your dedicated server and marks its state as Creating. It gives a configurable time limit for your dedicated server to initialize, so that if your dedicated server fails to initialize, Armada will remove the server and return its resources back to the regional cluster.
The creation timeout is applicable only when the dedicated server is in the Creating state. Once the dedicated server registers itself to the dedicated server manager, it will enter the Ready state.
Claim timeout
The claim timeout starts when an external service (such as Matchmaking) requests a dedicated server from Armada. Armada will reserve an available server.
Session timeout
The session timeout starts when a dedicated server starts serving a game session and enters the Busy state. This timeout gives a time limit for your dedicated server to serve a game session, so that Armada can remove stale servers that fail to exit normally after a game session has finished. If this timeout is exceeded, Armada sets the state of the server to Removing.
Unresponsive timeout
The unresponsive timeout refreshes when a server finishes its last health check with Armada. This timeout gives a time limit for your dedicated server to recover its connection to Armada in case of any network interruption. If this timeout is exceeded, Armada can remove the server and recover its resources, setting the servers' states to Unresponsive.