Table of Contents
To start a server cluster consisting of multiple machines, you can start each process in any of the following ways:
-
the command line
-
the control_cluster.py script
-
WebConsole's ClusterControl module
CellApps, BaseApps, and LoginApps can have multiple instances running, while the other processes can have only one. The clients should connect to the IP address of a machine that is running a LoginApp.
The following sub-sections describe how to start server components.
WebConsole can be used to easily start, stop and control server components.
For an outline of WebConsole, see WebConsole. For operational behaviour, see the online WebConsole documentation in the Cluster Control module.
The script bigworld/tools/server/control_cluster.py is generally the easiest way to start a multi-machine BigWorld Server. For details, see Control Cluster.
The method used to stop the system depends on the method used to
start it. For example, calling the script
control_cluster.py with the option
stop stops a system started with that script. Stopping
LoginApp triggers other processes to terminate, unless this feature is
disabled in configuration file
<res>/server/bw.xml.
Use WebConsole[12] and control_cluster.py[13] for monitoring and recording real-time statistics. You can also get profiling data from the watchers (via WebConsole's ClusterControl module). Use WebConsole's LogViewer module to monitor the centralised log.
Just as you can use multiple CellApps and BaseApps in a large cluster, you can also run multiple LoginApps in a load sharing arrangement.
To do that, DNS has to set up so that it returns multiple DNS addresses for the login server's name. If you are using BIND, then you can simply put multiple A addresses in the zone configuration file. This means that when a client looks up the DNS address of the login server, it receives a login server randomly selected from the available pool.
For example, if you are using BIND as your DNS server (most Linux distributions come with BIND as their default DNS server), the zone file can have configuration similar to the ones in the table below:
| Name | TTL | CLASS | TYPE | ResourceRecord |
|---|---|---|---|---|
| login | 600 | IN | A | 10.0.0.1 |
| 600 | IN | A | 10.0.0.2 | |
| 600 | IN | A | 10.0.0.3 |
Example configuration on a BIND zone file
Because there are multiple A records with different IP addresses under one name, the IP address returned to a client when it looks up the address for the login server will be picked up from the IP address list, in a round robin manner.