-
-
Notifications
You must be signed in to change notification settings - Fork 0
Elastic capacity in plain language
Elah may eventually let one Minecraft world use spare capacity from several machines instead of being trapped by one machine's limit.
This is a future goal. The current Elah release only inspects offline worlds and cannot run or scale a Minecraft server.
Imagine a community has several computers:
Machine A: quiet
Machine B: quiet
Machine C: busy
Machine D: quiet
A traditional server on Machine C cannot automatically use the other machines. A future Elah cluster could run additional compatible workers on A, B, or D and move suitable parts of the world after proving that ownership can move safely.
Elah would not move work just because one CPU number looks high. It would consider where players are, which world areas are busy, how long regions take to tick, how many entities and chunks are active, and whether moving a cell would create too much traffic between workers.
Future workers have three simple states:
- COLD: not running;
- WARM: ready but responsible for no part of the world;
- HOT: actively responsible for one or more cells.
When a spread-out world becomes busy, Elah could activate another compatible worker and safely move some cells to it. When demand falls, Elah could drain those cells, prove that the worker owns nothing, and return it to WARM or COLD.
A host could eventually define:
- GUARANTEED capacity reserved for a server;
- BURST capacity available from a shared pool up to a limit;
- PREEMPTIBLE capacity that is cheaper or temporary and can be reclaimed after a safe drain.
These are scheduling policies, not different safety levels. A cell always needs exactly one authoritative owner.
Many customers could use one physical fleet, but every Elah cluster must stay isolated. One customer's controller must not see or control another customer's workers, world, credentials, storage, network, or metrics.
Elastic capacity is most promising when work is naturally spread across a world:
- exploration and survival communities;
- factions, anarchy, and Earth worlds;
- many independent bases;
- large world borders;
- distributed chunk generation.
It is less powerful when almost everyone and everything is in one small place:
- one dense lobby;
- one giant mob farm;
- one small combat arena;
- another tightly connected hotspot.
Several weak machines cannot automatically replace one fast simulation thread. Distributed work also has communication costs. Elah must measure and explain those limits instead of promising infinite scaling.
Kubernetes or another infrastructure system could eventually run workers underneath Elah. It might satisfy a request for a compatible worker with a certain amount of memory and CPU.
Elah would still decide which Minecraft cell needs help, whether movement is useful, how ownership changes safely, and how affected players move. Kubernetes remains optional.
The short version is:
Generic infrastructure manages machines. Elah manages Minecraft.
Elah 0.0.3 | Repository | Releases | Security