専用サーバーを展開するためのフリートを作成します
Introduction
A fleet scales virtual machines, and manages dedicated servers that are hosted within those virtual machines, based on regional scaling configurations.
In Starter, 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 availabel regions:
Go to your game namespace in the AGS Admin Portal.
On the sidebar, open the AccelByte Multiplayer Servers menu and select QoS Regions.
In the QoS Regions list, switch on the toggle button of the regions you want to be available for your players.
AGS StarterStarter 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 consume. 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.
注記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:
Go to your game namespace in the AGS Admin Portal.
On the sidebar, open the AccelByte Multiplayer Servers menu and select Fleet Manager or Fleets. The Fleets page appears.
Click the + Create Fleet button. The Create Fleet form appears.
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.
Click Next to go to the Deployment Profile section.
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 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.
- 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.
Click Next to go to the DS Host section.
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.
ヒントSearch for an instance type using its name. If you want additional information on the instance type, click the info button on the entry.
Click Next to go to the Region section.
In the Region section, configure the scaling strategy of each region where you want your fleet to host dedicated servers in. Click on a regions' respective Edit button (pencil icon) under Action. On the pop-up that appears, fill in the required information:
Min Servers: the minimum number of servers that the deployment needs to maintain, regardless of whether the servers are in the Ready (warmed buffer) or In Session (serving a game session) state. this value is useful to handle the baseline concurrent users, by ensuring that there are enough servers ready to go.
Max Servers: 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.
Buffer Value: the buffer value tells the fleet the exact number of servers to maintain as warmed buffers.
注記- Warm buffers are dedicated servers that are idling in the Ready state, ready to be claimed by a game session to start serving the session immediately.
- 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 configure 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 an virtual machine is five, minimum servers is three, and maximum servers is 28. The fleet will adjust the scaling behavior to minimum servers to five 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.
Click Save to save your configuration and repeat this step for each region you want to enable for the fleet.
Click Next to go to the Logs & Artifacts Sampling section.
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.
Click Next to go to the Summary section.
Review your fleet configuration, then click the Create button. The Create Fleet pop-up appears.
(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.
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
- Unity
- Config Injection
- Default Command
-ABDsId ${dsid} -ABPort ${default_port} -ABWatchdogUrl ${watchdog_url}
-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}.
-log: Log file path
The log file path can be passed to the dedicated server with any format of flags that you desire, followed by using the phrase ${log_file} for parameter substitution. Note that you will use the path to emit your logs, so that AMS can carry your logs to the log stash for later retrieval.
-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.
- Using
-ABas 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.
- Config Injection
- Default Command
-ABDsId ${dsid} -ABPort ${default_port} -ABWatchdogUrl ${watchdog_url}
-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.
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)
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.