Lobby Node migration
When you need to migrate the current Lobby server to a new machine (usually with higher hardware specs) there are a number of steps to follow, in order to complete the task successfully.
Migrating the Lobby means that at some point you will need to shut down the current server and activate another one that has already been launched and configured. Since this operation might affect some of the users currently connected to the Lobby the activity should be planned carefully, notifying the player base in advance.
Before we examine the steps to migrate a Lobby Node we need to clarify an important concept: an Overcast Cluster can only have one active Lobby at a time. While you can launch multiple Lobby Nodes in the cluster, only one will set itself as active and all the others will be in the inactive state.
The active Lobby is the one controlling all the Game Nodes in the cluster, while the inactive Lobbies are essentially ignored and don't participate in the cluster.
The way in which the active state is assigned is simple, using the first-come, first-served principle: when a Lobby boots up, it searches for other active Lobbies in the cluster and if none is found it auto-assigns the active state. If another active Lobby already exists, the new server will set itself as inactive. In other words, the first Lobby server launched will always become active by default, and all other Lobby servers launched subsequently will become inactive.
The most common use case for a Lobby migration is typically as follows: you are running a cluster where the Lobby Node is often reaching its capacity and therefore you would like to upgrade it to a higher tier machine.
The upgrade process requires creating a new server and eventually disposing of the former one. To do so you will need to follow these steps, in the provided order:
Launch a new Lobby Node in the same cluster, choosing a higher tier. You can do this in one of two ways:
- Using a previously stored snapshot of the current Lobby, so that all your configuration is preserved.
- Starting anew and configuring the server manually.
- Schedule the Lobby switch at a low traffic hour and notify your user base several days earlier at least.
A few hours before the scheduled maintenance activity we recommend these optional steps:
- Sending an Admin Message to all clients currently connected in the old Lobby (your game must support that type of messages).
- Deactivating the main Zone of the Lobby you're about to shut down.
- When it is time, shut down the active Lobby via the AdminTool's Stop Server button (see image below).
- Restart the new Lobby server (currently inactive) so that it can take over.
- If you have a third domain associated with the old Lobby Node, now it's time to unlink it and assign it to the new Lobby server.
Use the red "Stop server" button to shut down the old Lobby.
We recommend the optional steps described at point number 3 to avoid users being caught by surprise in case they didn't receive or read your previous notifications. Also deactivating the default Zone can help the migration by denying new connections to the Lobby while the remaining Users can still finish their session.
To be clear, deactivating the Zone doesn't kick out the users already joined but it prevents new users to login, which is important since the system is going to be shut down. These steps should gradually empty the Lobby so that the shut-down will affect few or no users at all.
Users attempting to log in an inactive Zone will receive a generic error on the client side such as:
Zone X is currently inactive
This can be customized from the client side to something more meaningful such as:
Zone X is currently inactive due to an imminent maintenance activity. Please try again later.
To learn more about error message customization please refer to the relative SFS2X documentation.
Minimum number of Game Nodes
Before restarting the inactive Lobby make sure to configure the minimum number of Game Nodes via the AdminTool's Cluster Configurator module. This is important because we started the new Lobby with this value set to zero. Now we want to set the minimum number of Game Nodes to its actual value.
If you forget about it you can still change it later, while the Lobby is already running.
Impact on games running on existing Game Nodes
The Game Nodes are essentially unaffected by a Lobby migration, meaning that they will continue with their activities without problems. Behind the scenes Game Nodes will detect the disappearance of the Lobby and will start searching until a new active one becomes available. At that point all Game Nodes will join the new Lobby and the cluster will continue its normal operations.
The only situation in which running games might be affected by a Lobby migration is if the Game Extensions rely on some interaction with the Lobby, for example when using Cluster Events.
As mentioned at step #6, you will also need to migrate your (typically third level) domain from the old Lobby to the new one. This is done via the Overcast interface.
Here you can click on the [Edit domain] icon in the Custom Domain column and change the associated domain name. To clear an association simply leave the text field empty. The domain change takes usually 5-6 minutes for the DNS servers to update.
In our Lobby migration example you will need to remove the domain from the old Lobby Node and assign it to the new one.
What about the old Lobby Node?
In our migration process we are supposed to shut down the old Lobby server, however this will only stop SmartFoxServer while the actual cloud server is still running. We usually recommend to terminate the server once the migration is complete. However, if you still need to check the server (maybe download log files, etc.) you can still reach it via the AdminTool as usual.
Once this is done you have successfully migrated your Lobby Node to a new server tier.