Game Server Orchestrator Overview
As you may know, multiplayer online gaming has been rapidly growing over the past few years. Many studios are researching game hosting solutions (early during development) that can help their games to be as efficient as possible when it's released. A smooth release of a multiplayer game with an efficient game hosting solution can help with its success. i3D.net understands the importance of that. To help burgeoning game studios in that endeavor, i3D.net offers a new product: The Game Server Orchestrator.
In a nutshell, the Game Server Orchestrator is a fully customizable game hosting solution that offers scalability solutions (scaling up / down game servers based on demand), health checks, monitoring, and more.
Specifically, the Game Server Orchestrator operates by connecting to the database that contains the application instance entries and our designated message broker. It first retrieves the current state of the application instances from the database, checking if they are in the correct state. Based on this information, the Orchestrator sends messages through the message broker to communicate with the VM Manager, instructing it to create or destroy virtual machines as necessary. This coordination allows the Orchestrator to manage the provisioning and scaling of game server instances dynamically, ensuring optimal performance, and resource utilization in the game environment.
Why would I need an Orchestrator?
In the event of a highly successful game with a sudden surge in players, relying solely on basic game server capacity deployed on your own bare metal servers may prove insufficient. Ordering additional bare metal servers to increase capacity may take too long, resulting in new players being unable to join the game. To address this challenge, we have developed a dynamic game server deployment system that can seamlessly scale onto major cloud platforms like GCP, AWS, and Azure. This innovative solution bridges the gap between demand and compute resources, ensuring that your game server resources can dynamically adapt to player influxes in real-time, enabling a smooth and uninterrupted gaming experience for all players while safeguarding your reputation.
Base requirements you need to set up the Game Server Orchestrator
You will first need to integrate your game's backend. Then you will need to set up your hosting parameters, scaling mechanisms and deployment types by selecting your needs:
- Bare Metal instance types for your base layer (player base).
- Your deployment regions.
- Your cloud providers (for multi-cloud bursting when you need additional capacity).
- Your minimal and maximal amount of game instances per server, and the buffer of free game servers.
Ready to start setting this up? Go to our Quick Start Guide documentation.
Note
For your base requirements, we always recommend using Bare Metals as much as possible for the following reasons: - They provide better performances. - Their monthly cost is lower than the monthly cost of a Virtual Machine of similar size.
How does the Orchestrator work?
Once deployed, a simple game flow is as follows:
- Once your players start entering the game servers, the game client sends requests to your matchmaker.
- The matchmaker sends game and server details to the game client, which connects to the game server to start the round (and disconnects when the round is done).
Here is a visual of how the Game Server Orchestrator works:
The Orchestrator combines the major elements in order to deploy game servers when and where you need them. It must know which application (builds) it needs to deploy using:
It must also know where and how to deploy the builds with:
Together with the live game server status information such as Allocation / Live Status, the Orchestrator knows the occupied and free game servers. With that data, it can determine whether there are too few or too many free game servers. As a result of that information, the Scaler can send instructions to deploy or remove game servers as needed.
The scaling mechanism always operates on individual combinations of region + DC location (Data Center location) + ApplicationBuild. Deployment of game servers first occurs on Bare Metal servers and when they are full, the Orchestrator continues to deploy onto any configured cloud locations.
Host selection overview (Round robin strategy)
What is the Round robin strategy? This is which your BM or VM host will send a request to cloud provider A, then B, then C, and then back to A. Moreover, you can choose to use a cascading approach, which is you exhaust cloud provider A, then exhaust cloud provider B, and so on.
When the scaling mechanism needs to deploy a new ApplicationInstance, it will first look for a usable Bare Metal hosts (BM). If you have run out of BM hosts, the Orchestrator will continue with Cloud VMs, provided you have configured cloud locations in your DeploymentProfile.
A selected BM or VM host will be filled with instances before the mechanism will find the next free host. You can individually define the number of instances to be deployed onto a host for each BM or VM instance type.
Initializing an empty host
When a new, empty host (BM or VM) has been selected for game server deployment, the scaling mechanism will first deploy all the utilities (sidecars) and dependencies that you defined in your UtilityDeploymentTemplate and DepencencyDeploymentTemplate. After that, the new game servers are deployed.
How does the Orchestrator remove instances (downscaling)?
When player demand decreases and if there are too many application instances deployed, the scaling mechanism will start removing unused instances until the number of free / unallocated instances equals the bufferValue again.
If you have application instances deployed onto VMs, they are removed first. Only empty instances are removed. If no VMs are in use, or if there are no VMs with free / unallocated instances, the Scaler will continue downscaling instances on Bare Metal hosts.
To help reduce cloud hosting costs, the host with the least amount of application instances (or secondary, with the most free instances) will be selected for removing instances.
Note
Keep in mind though that if your game server hosts sessions take a long time to end, a VM cannot be destroyed until all its players have left the game server. If your game falls into that category you may want to invest in a mechanism that can transfer players to another game server, in an attempt to reduce cloud hosting costs.
Cleaning up a host when it's empty
After the last game server instance has been removed from a host, any side cars (utilities) and dependencies will also be removed. If the host is a VM, the VM will be destroyed. A Bare Metal host will become usable again for future deployments.