Create fleets to deploy dedicated servers

Introduction

A fleet scales virtual machines, and manages dedicated servers (DS) hosted within those virtual machines, based on regional scaling configurations.

AGS Shared Cloud

In Shared Cloud, you can only create up to three fleets and assign them to the North America East (us-east-2) region only.

This article walks you through how to create and customize a fleet in AccelByte Multiplayer Servers (AMS) to suit your needs.

Prerequisites

Before you begin this guide, you must have:

• Access to your game's namespace and account in the AccelByte Gaming Services (AGS) Admin Portal.
• Integrated a dedicated server with the AGS Server SDK.
• Uploaded a dedicated server build to AMS.

Enable regions

While not required in order to run Dedicated Servers in a fleet, if you are using AGS matchmaking you must enable QoS for any regions you would like your players to be able to use dedicated servers in.

To enable QoS for the available regions:

1. Go to your game namespace in the AGS Admin Portal.

2. On the sidebar, under ADD-ONS, select AccelByte Multiplayer Servers > QoS Regions.

3. In the QoS Regions list, switch on the toggle button of the regions you want to be available for your players.

   AGS Shared Cloud

   Shared Cloud users are limited to just the North America East (us-east-2) region.

Fleet types

AMS supports two types of fleets:

• Production: is the default fleet type when creating a new fleet. Production fleets are meant for live games and are designed to quickly and efficiently allocate dedicated servers to players by always keeping a buffer of dedicated servers ready to be consumed. Production fleets also use immutable attributes like the dedicated server image and command line arguments to help prevent accidental changes that could break your dedicated server deployments and negatively impact players of your live game.

• Development: provides more flexibility and cost efficiency by letting you run multiple dedicated server versions and command line permutations in the same fleet. This helps reduce costs during development by minimizing the number of virtual machine instances needed to test multiple dedicated server versions, game modes, maps, and more. Development fleets accomplish this by decoupling the dedicated server image and command line arguments from the fleet, allowing you to late-bind the dedicated server image and command line arguments in the dedicated server claim flow. Development fleets don't know which configurations to run until they are requested so they cannot maintain a full buffer of ready dedicated servers. However, development fleets maintain enough VM capacity to supply the buffer needed to start a dedicated server as soon as a particular dedicated server configuration is requested.

  note

  Development fleets work in conjunction with Development Server Build Configurations, referred to as "Build Configurations" for brevity in the AccelByte official documentation and in the Admin Portal. Build Configurations consist of a dedicated server image and command line arguments, which are appended to the command line arguments specified in the associated development fleet. To learn how to create a Build Configuration and associate it with a development fleet, see Use build configurations with development fleets.

Create a fleet

AMS can start up your dedicated game servers whenever there is demand. However, before AMS can do so efficiently, it needs to have all the necessary data on how best to run your dedicated game servers, as well as where and when to run them. The fleet creation process will ensure that you have given all information required for AMS to manage your fleet.

To create a fleet, follow these steps:

1. Go to your game namespace in the AGS Admin Portal.

2. On the sidebar, open the AccelByte Multiplayer Servers menu and select Fleet Manager or Fleets. The Fleets page appears.

3. Click the + Create Fleet button. The Create Fleet form appears.

4. In the Fleet & Image section, type in a name for your fleet, which must be unique within the namespace. Then, depending on the type of fleet, do one of the following:

   • For a production fleet, choose one dedicated server image that has been uploaded to the account. The fleet will start dedicated servers based on this image. You can search for an image by using its image ID or image name.
   • For a development fleet, click the slider next to Development Fleet.

5. Click Next to go to the Deployment Profile section.

6. In the Deployment Profile section, adjust your timeout values as necessary.

   Timeout

   • Creation Timeout: The creation timeout starts when the local watchdog launches your dedicated server, and marks its state as "Creating." This timeout gives a configurable time limit for your dedicated server to initialize, so that if your dedicated server fails to do so, AMS will remove the server, and replace it with a new one.

     • The creation timeout is applicable only when the dedicated server is in the "Creating" state. Once the dedicated server notifies the watchdog that it is ready to host a game session, it will enter the "Ready" state.

   • Session Timeout: The session timeout starts when the dedicated server is claimed by a game session and enters the "In Session" state. It gives a time limit for your dedicated server to serve a game session, so that watchdog can remove stale servers that fail to exit themselves normally, once a game session has finished.

   • Drain Timeout: The drain timeout starts when the dedicated server that is not serving an active game session receives the drain signal from the local watchdog. The drain signal tells the dedicated server that the VM it is running on is slated to be removed, and gives a configurable period of time for it to finish any essential work (which may include finishing an active game session) and then exit before the watchdog forcibly kills it.

   • Unresponsive Timeout: The unresponsive timeout refreshes when a server finishes its last health check with AMS. It gives a time limit for your dedicated server to recover after an event which disrupts its heartbeats to the watchdog. If the timeout is exceeded, AMS will remove the server and replace it with a new one.

   Port Configuration

   Add the ports that you want the dedicated servers listen to. The actual port values for the ports you create will be generated at runtime. A default port is also automatically created for the fleet, which cannot be edited or deleted.

   Command Line

   In the command line box, add your dedicated server command line arguments and ensure that you specify any additional parameters required for your dedicated server to run in the desired configuration. To learn how to construct your command, see Construct your dedicated server command line.

7. Click Next to go to the DS Host section.

8. In the DS Host section, select which instance type you want your dedicated servers to run in and the number of dedicated servers you want to run in the instance.

9. In the Region section, configure the scaling strategy of each region where you want your fleet to host dedicated servers in. Click on a region's respective Edit button (pencil icon) under Action. On the pop-up that appears, fill in the required information:

   Max servers

   Set the maximum number of servers that the region can maintain. This value is useful as a limiter to make sure the cost of game servers will not go over budget. This count includes servers in all states: "Creating," "Ready," or "Claimed." For a production fleet, set a number that accommodates the maximum number of players you expect to have during peak times. That is: max = <peak CCU> / <players per server>.

   note

   To accommodate fluctuations in claim rates and DS restart times, increase the value by 5% or 10%. This adjustment accounts for the fact that when a claimed DS finishes its session, there is a short period until the next DS is in the "Ready" state. During this time, it contributes to the maximum count but cannot be claimed until it is ready.

   Min servers

   Set the minimum number of active servers that the deployment needs to maintain, regardless of its state. In many cases, you can set this to 0 and use buffer to automatically scale the fleet based on demand. Yet, setting a minimum is useful if you don't want to rely on automatic scaling and just want to ensure a fixed minimum number of servers.

   Buffer Value

   The buffer value tells the fleet the exact number of servers required to maintain the "Ready" state, ensuring they can be claimed by game sessions immediately. This is crucial, because the time to start a new DS varies between 1-10 minutes, which would be too long for a player to wait on a server. The duration depends on the DS creation time, including the time for AMS to start a new VM and download the DS image. It's recommended to assume a worst case duration of 10 minutes. Insufficient buffer size relative to expected demand growth will delay game sessions from claiming servers. To estimate an appropriate production fleet value, use this formula: buffer = <change in demand per unit time> x <max time to start a DS>, where:

   • <change in demand per unit time> = (<demand at t2> - <demand at t1>)/(t2-t1)
     • <demand at t1> and <demand at t2> are the expected numbers of claimed servers at the start and end of the period.
     • t1 and t2, respectively, are the beginning and end times of the period over which we calculate the increase of demand.
   • <max time to start a DS> is the estimated maximum time it takes to start a new DS. For example, over a time span of 12 hours, we expect the demand to increase linearly from 1.000 to 2.500 DSs. Then, every 10 minutes we require an additional 10 x (2500 - 1000) / (12 x 60) = 21 DSs. So you would set the buffer to 21. However, realistically, demand doesn't increase linearly, and in fact we see that jitter plays a large role in determining buffer size. Jitter is the short term fluctuation of the number of claimed DSs. So even if the 12-hour trend is 21 DSs per 10 minutes, there might be a one-minute instance where 30 DSs get claimed at once. Therefore, we should set the buffer size to 30.

   note

   For games already released, we provide metrics to analyze and recommend a buffer size based on your game's historical data (not available in AGS Shared Cloud). To find it, go to https://<your-grafana-dedicated-stack>.grafana.net/dashboards (more info at AIS dashboard) and open AMS Buffer Sizing. Then, select your namespace and fleet. The dashboard shows the "Required" buffer size for each region. It is the size of the buffer that would have been required based on the DS trend and jitter. As such, we recommend that as the buffer size.

   

   tip

   Create your own copy of the AMS Fleet Size calculator and use your parameters to calculate the min, max, and buffer value for your fleet per region.

   note

   • The fleet will always try to maximize the use of the AMS virtual machine instances. Therefore, your minimum and maximum number of servers will be rounded up to the closest multiple of the number of servers configured to run in each virtual machine. This ensures there are no wasted resources in the AMS instances that are being billed to your account. Consider the example where the number of servers to be run in a virtual machine is 5, minimum servers is 3, and maximum servers is 28. The fleet will adjust the scaling behavior to minimum servers to 5 and maximum servers to 30. Additionally, if the buffer value results in an additional virtual machine to be requested by the fleet, all five dedicated servers within the newly set up virtual machine will become buffers.
   • For development fleets, in most cases, a buffer setting of between 1 and whatever number you have set as the number of DS per VM is appropriate. With a setting of 1, it won't start a new VM until the existing VMs are all full. With a setting equal to the DS/VM setting, it will start a new VM as soon as any claimed DS exists on all of the existing VMs. In general, a new VM will start if the existing VMs don't have room to fit the number of DS set in the buffer setting.

10. Click Save to save your configuration and repeat this step for each region you want to enable for the fleet.

11. Click Next to go to the Logs & Artifacts Sampling section.

12. In the Logs & Artifacts Sampling section, configure sampling rules for collecting dedicated server logs and artifacts. To learn about sampling rules, see the Sampling rules section.

13. Click Next to go to the Summary section.

14. Review your fleet configuration, then click the Create button. The Create Fleet pop-up appears.

15. (Optional) On the pop-up, you have the option to activate the fleet immediately after it's created. You can skip this step and activate or deactivate the fleet at a later time.

16. Click Create to create the fleet. Your fleet is immediately added to the Fleets list.

Construct your dedicated server command line

Aside from a few required flags, you are free to construct your own dedicated server command line.

Development fleets work a little differently than production fleets. The dedicated server command line for a development fleet is a combination of the fleet's command line appended with the associated Build Configuration's command line. If the required flags are not specified in either the development fleet command line or the Build Configuration command line, no dedicated servers will successfully launch for the fleet.

The required flags are as follows:

Unreal

Config Injection

-ABDsId ${dsid} -ABPort ${default_port} -ABWatchdogUrl ${watchdog_url}

Default Command

-dsid=${dsid} -port=${default_port} -watchdog_url=${watchdog_url}

-ABDsId, -dsid: Dedicated server ID

The dsid should be passed into the dedicated server by the flag -ABDsId ${dsid} or -dsid ${dsid}. The usage of the flag is covered by the SDK.

-ABPort, -port: Ports

Ports can be passed to the dedicated server with any format of flags that you desire. The substitution variable for your ports will follow the format: ${<<your_port_name_in_lowercase>>_port}.

-ABWatchdogUrl, -watchdog_url: the URL to the local watchdog

The watchdog is the monitoring agent of the dedicated servers in the hosting machine. The SDK will connect to the watchdog automatically using the URL.

note

• Using -AB as a prefix will add the ability to inject the AGS Unity SDK config. Therefore, you can get the value and use that as needed by calling this.
• The code snippet will be added soon.

Unity

Config Injection

-ABDsId ${dsid} -ABPort ${default_port} -ABWatchdogUrl ${watchdog_url}

Default Command

-dsid ${dsid} -port ${default_port} -watchdogUrl ${watchdog_url}

-ABDsId, -dsid: Dedicated server ID

The dsid should be passed into the dedicated server by the flag -ABDsId ${dsid} or -dsid ${dsid}. The usage of the flag is covered by the SDK.

-ABPort, -port: Ports

Ports can be passed to the dedicated server with any format of flags that you desire. The substitution variable for your ports will follow the format: ${<<your_port_name_in_lowercase>>_port}.

-ABWatchdogUrl, -watchdogUrl: the URL to the local watchdog

The watchdog is the monitoring agent of the dedicated servers in the hosting machine. The SDK will connect to the watchdog automatically using the URL.

note

Using -AB as a prefix will add the ability to inject the AGS Unity SDK config. Therefore, you can get the value and use that as needed by calling this.

var dsid = AccelByteSDK.GetServerRegistry().Config.DsId;
var port = AccelByteSDK.GetServerRegistry().Config.Port;
var watchdogUrl = AccelByteSDK.GetServerRegistry().Config.WatchdogUrl;

Additional variables for substitution

Additionally, AMS supports variable substitution for the following variables in your dedicated server command:

Variable name	Description
${creation_timeout}	Expands to the value of the creation timeout, as defined in the fleet.
${session_timeout}	Expands to the value of the session timeout, as defined in the fleet.
${drain_timeout}	Expands to the value of the drain timeout, as defined in the fleet.
${unresponsive_timeout}	Expands to the value of the unresponsive timeout, as defined in the fleet.
${artifact_path}	Expands to the value of the absolute path of an artifact directory that will get recursively collected.

Sampling rules

Sampling rules tell AMS when to collect logs, custom artifacts, and core dumps for your dedicated servers managed by this fleet. Sampling rules are defined by artifact type and dedicated server exit status.

There are three configurable rules:

• Percentage of logs and custom artifacts to collect for dedicated servers that exit with a status of 0 (success)
• Percentage of logs and custom artifacts to collect for dedicated servers that exit with a status > 0 (failure)
• Percentage of core dumps to collect for dedicated servers that exit with a status > 0 (failure)

note

The Enable Log Sampling section of the UI applies to both Logs and Custom Artifacts. The Enable Artifacts Sampling section of the UI only applies to Core Dumps so only the abnormal exit sampling rate is applicable. We are aware this is confusing and will fix the UI in an upcoming release.

The value of each rule defines the percentage of dedicated servers for which artifacts will be collected. For example, a sampling value of 100 tells AMS to collect artifacts for all dedicated servers belonging to the fleet, whereas 50 means that AMS will collect artifacts from roughly half of the dedicated servers.

Setting the sampling percentage to zero tells AMS to report all matching artifacts, but not actually collect and store them for you to retrieve.

Sampling rules can also be deactivated, effectively disabling the sampling rule, which means AMS will not even report artifacts matching the rule.

To view and manage the collected artifacts from your dedicated servers using the Admin Portal, see the View and manage dedicated server logs and artifacts article.

What's next

If you created a development fleet, you need to learn how to use a build configuration with your development fleet. If you created a production fleet to deploy your dedicated servers, you are ready to configure a Play Session to claim dedicated servers from your new fleet.

You can also explore different dedicated server claim scenarios.