Running a Minecraft Server on Eleanor for Many Users

Using Eleanor to implement a multiplayer Minecraft server with a custom world.

Related items

WHAT IS MINECRAFT?

Minecraft is a creative first-person video game which permits players to build and navigate complex block-based 3D worlds. Elementary “circuit” functions allow interactive areas of the world to be programmed using basic building blocks. In a multiplayer server, all users inhabit the same persistent world. Due to the size of the world, and the fact that new areas are generated algorithmically, the server can require a reasonable amount of computing resources. This is less of an issue in this project, as the world is largely pre-built. The goal is to allow at least sixty users to access the service simultaneously. Generally speaking, getting 8 users running lag-free on a standard server is a bit of a challenge – usually due to disk performance.




Minecraft environment:

IMPLEMENTATION

The Minecraft server software is delivered as a single-threaded Java jar. As with many Java applications, memory garbage-keeping needs improvement. Therefore, consideration must be given to the balance between providing enough memory to keep things running smoothly, but not too much that the JVM (Java Virtual Machine) spends the whole time cleaning large sections of it up as players move around in the world. As the blocks comprising the world are streamed to the players, disk latency is also an important factor - if the latency is too high, players, animations, and objects in the world will seem to ’skip’ around. It was decided to host the server on a dedicated Ubuntu VM (Virtual Machine) on Eleanor, the University’s sandbox to experiment with virtual environments. An ’ideal’ template wasn’t available - few cores, lots of RAM, little fast disk - but an approximation was made by spinning up an instance with many cores, lots of RAM and a lot of standard disks, and then swapping out the disk for a smaller volume. Even with the storage worked around in this way, around 80% of the CPU resource was wasted. On future runs of the practical, Ansible was used to bring up the instance, allowing us to specify the desired instance size via the API, so resource waste was eliminated. A single Ansible playbook now deploys the running application from scratch with a single run.

CONFIGURATION

Minecraft is very simple to set up - the configuration lies entirely within the server properties text file. A basic instance was created, with the custom world in place, and then the configuration changed to allow for whitelisting, specific game modes, and operator rights for certain users. A simple start script was create to allow for rapid startup and shutdown of the server. This start script was run within a screen session, allowing an administrator to change settings on-the-fly in real time. This aided greatly in finalising the configuration.


RUNNING THE PRACTICAL

The practical was run over a weekend, with a few days before and after for light use. Once users began connecting in large numbers, it became apparent that the disk I/O was not up to the task. This was solved by moving the 2 gigabyte world into a RAM disk. This immediately solved all latency issues. Over the course of the practical the server software crashed several times and needed to be manually started. In any future practical, the start script should be run using flock, with a partner cronjob starting it if it’s not already running. This would effectively automate the only part of the practical which had issues.


CONCLUSION AND RECOMMENDATIONS

The practical was considered a great success, and the technical challenges were minor, given the number of concurrent users. It was suggested that running multiple instances of the world could be useful for times when specific game objects were being heavily used. Setting up the server as a cluster of four or five nodes on a single machine with ports allocated to connections randomly would be fairly straightforward to implement and would make better use of the abundance of cores in the VM. Before running further projects, it would be worthwhile working with Research Services to put together some more useful base configurations.

Explore Eleanor


This case study was written by John Dow, System Administrator at the School of Biological Sciences (SoB) over the research of Dr Thomas Little, Personal Chair in Evolutionary Biology, member of the Institute of Ecology and Evolution, as well as Dr Richard Fitzpatrick, curriculum developer at the SoB. Adaptations to the website were performed by Dr Andre Vieira, Research Facilitator for the College of Science and Engineering.


Related items

Why don't you explore featured projects demonstrating the use of similar resources and related training opportunities? Have a look at the carousels below.