82 lines
3 KiB
Markdown
82 lines
3 KiB
Markdown
# Dynamic Minecraft Servers
|
|
|
|
> **Status:** Proposed
|
|
> **Submitted:** Oct 26th, 2023
|
|
|
|
## The idea
|
|
|
|
Provision minecraft servers on-demand.
|
|
Servers are expensive especially when you don't have a sustained amount of active players.
|
|
Therefore it's probably a good idea to dynamically start and provision servers that can handle minecraft servers and kill them when demand ends.
|
|
|
|
## Flow
|
|
|
|
Terms:
|
|
|
|
- `Client`: End User
|
|
- `Server`: The provisioner
|
|
- `Instance`: Provisioned servers
|
|
|
|
### Connecting
|
|
|
|
The flow of connecting will look something like this.
|
|
|
|
1. Client connects to custom^[1]^ minecraft proxy.
|
|
2. Server checks if minecraft server exists and runs
|
|
1. Minecraft server is live: Server connects client to minecraft server.
|
|
2. Minecraft server is being created: Server waits until process finished and connects client to minecraft server.
|
|
3. Minecraft server doesn't exist
|
|
1. Server creates new cloud instance according to config.
|
|
2. Server waits 'till ICMP succeeds.
|
|
3. Server ssh'es into server and starts instance according to config.
|
|
4. Server waits 'till minecraft server starts.
|
|
5. Server connects client to minecraft server.
|
|
3. Server closes connection.
|
|
|
|
### Demand end
|
|
|
|
When demand ends the flow will look something like this.
|
|
|
|
0. Instance sends `DEMAND_END` to server
|
|
1. Server marks instance as `stopping` and won't connect clients to it.
|
|
2. The instance is stopped. (send `MC_STOPPED` to server)
|
|
3. Data is .tar.gz'd and sent to a storage medium. (sftp/cifs/...???)
|
|
4. Instance does post-flight checks.
|
|
1. Is all data backed up?
|
|
5. Instance sends `EXITING`
|
|
6. Server removes reference to instance.
|
|
7. Server destroys instance from hosting.
|
|
|
|
## Storage
|
|
|
|
All data whould be from the IDLE state of a server.
|
|
When demand ends all data should be sent to a storage medium; compressed.
|
|
When demand starts all data should be pulled from a storage medium and decompressed.
|
|
|
|
## Why is this significant?
|
|
|
|
Minecraft is a fun game, however it's trending in waves, therfore there are a lot of bursts of activity but not sustained.
|
|
|
|
Maintaining the Minecraft infrastructure can be done but it's tiresome and, maybe more importantly, dependant on humans.
|
|
People living in the US might connect when the admin is sleeping. Thus they can't play.
|
|
A simple proxy/manager can solve this.
|
|
|
|
## Cost
|
|
|
|
'Tis a dynamic scaling solution, thus undeterminable.
|
|
However, should this proposal be accepted the manager should have a option to refuse creation upon reached budget.
|
|
|
|
## Existing tooling
|
|
|
|
- [TimoCloud] might be a good example of what we're trying to do.
|
|
- [OnDemandMinecraft] does this idea with AWS but with a web-ui to start the server.
|
|
- [MineCloud] does this idea also with AWS but [MineCloud] uses a discord bot to start the server.
|
|
|
|
## Notes
|
|
|
|
- [1]: Yet to be written/determined which.
|
|
|
|
<!-- Links -->
|
|
[TimoCloud]: https://github.com/TimoCloud/TimoCloud
|
|
[OnDemandMinecraft]: https://github.com/trevor-laher/OnDemandMinecraft
|
|
[MineCloud]: https://github.com/VeriorPies/MineCloud
|