Minecraft Netzwerk-Architektur: Einzelserver bis

Jedes Minecraft-Projekt beginnt gleich. Ein Server, ein paar Freunde, Vanilla Survival. Dann kommen Plugins, dann Minigames, dann ploetzlich hunderte Spieler, und man merkt: Ein einzelner Server reicht nicht mehr.

Dieser Artikel zeigt, wie man ein Minecraft-Projekt richtig skaliert. Vom einzelnen Paper-Server bis zum vollstaendigen Cluster mit Proxy, Load Balancing und Failover. Ohne Geschwafel, mit Konfigurationen und Diagrammen.

Stufe 1: Einzelserver

Die einfachste Architektur. Ein VPS oder Dedicated Server. Paper (oder Purpur) laeuft mit allen Plugins, allen Welten, allen Spielern in einem Prozess.

Spieler → [Paper Server :25565]
              ├── world/
              ├── world_nether/
              ├── world_the_end/
              └── plugins/

Das funktioniert bis zu einem bestimmten Punkt. Ungefaehr 80-120 Spieler online, je nach Hardware und Servertyp. Survival mit Farmen erreicht das Limit frueher als eine Lobby mit NPCs.

Typische Einzelserver-Konfiguration:

# Aikars JVM-Flags fuer optimale Garbage Collection
java -Xms8G -Xmx8G -XX:+UseG1GC -XX:+ParallelRefProcEnabled \
  -XX:MaxGCPauseMillis=200 -XX:+UnlockExperimentalVMOptions \
  -XX:+DisableExplicitGC -XX:+AlwaysPreTouch \
  -jar paper-1.21.4.jar nogui

Vorteile:

Einfache Einrichtung und Wartung
Eine Konfiguration, ein Prozess
Keine Datensynchronisationsprobleme
Alle Plugins funktionieren ohne zusaetzliche Konfiguration
Minimale Admin-Kenntnisse erforderlich

Nachteile:

Minecraft ist im Kern Single-Threaded. Mehr Kerne helfen nicht
Alle Spieler teilen sich eine Instanz. Lag bei Minigames = Lag im Survival
Keine Isolierung. Ein Plugin-Crash toetet alles
Kein Update eines Spielmodus ohne Neustart
Eine grosse Welt verbraucht den gesamten Arbeitsspeicher

Die zentrale Einschraenkung: Minecrafts Tick Loop. Alle 50 Millisekunden (20 TPS) verarbeitet der Server die gesamte Spiellogik: Mobs, Redstone, Chunks, Spieler. Wenn ein schwerer Prozess laenger als 50 ms dauert, stottert der gesamte Server. Vertikale Skalierung hat eine Obergrenze. Danach muss man horizontal skalieren.

Wenn ein einzelner Server nicht mehr reicht, kaufe keine staerkere Maschine. Aendere die Architektur.

Stufe 2: Wann braucht man einen Proxy?

Klare Anzeichen, dass es Zeit fuer Multi-Server wird:

TPS faellt unter 18 bei 60+ Spielern
Mehr als zwei Spielmodi (Survival, Minigames, Creative)
Updates fuer einen Modus sollen die anderen nicht beeinflussen
Last soll auf mehrere Maschinen verteilt werden
Gemeinsame Daten zwischen Servern noetig (Economy, Raenge, Freunde)

Ein Proxy loest das Kernproblem: Spieler verbinden sich mit einer Adresse, und der Proxy leitet sie zum richtigen Backend-Server weiter. Spieler wechseln zwischen Servern ohne Reconnect.

Ein weiterer Vorteil, der oft uebersehen wird: Mit einem Proxy kannst du Wartungsarbeiten an einem Server durchfuehren, waehrend Spieler auf anderen Servern weiterspielen. Du musst ein Plugin auf dem Survival-Server aktualisieren? Verschiebe die Spieler zur Lobby, aktualisiere, bringe sie zurueck. Niemand muss getrennt werden. Das ist entscheidend fuer Server mit 24/7-Betrieb.

Stufe 3: Basis-Netzwerk mit Velocity

Velocity ist der moderne Proxy fuer Minecraft. Falls du noch BungeeCord nutzt: wechsle. Velocity ist schneller, sicherer (Modern Forwarding mit HMAC-SHA256) und wird aktiv weiterentwickelt. Details in unserem Velocity vs BungeeCord Vergleich.

Grundaufbau:

Spieler → [Velocity Proxy :25565]
               ├── [Lobby :30001]       (Paper)
               ├── [Survival :30002]    (Paper)
               └── [Minigames :30003]   (Paper)

Velocity-Konfiguration

# velocity.toml
bind = "0.0.0.0:25565"
motd = "<green>MyServer Network"
show-max-players = 500
player-info-forwarding-mode = "modern"
online-mode = true

[servers]
lobby = "127.0.0.1:30001"
survival = "127.0.0.1:30002"
minigames = "127.0.0.1:30003"
try = ["lobby"]

[forced-hosts]
"survival.myserver.com" = ["survival"]
"games.myserver.com" = ["minigames"]

Backend-Server Konfiguration

Auf jedem Paper-Server in config/paper-global.yml:

proxies:
  velocity:
    enabled: true
    online-mode: false
    secret: "dein-secret-key-aus-forwarding.secret"

In server.properties jedes Backends:

server-port=30001  # eindeutig pro Server
online-mode=false  # Auth ueber Proxy

Wichtig: online-mode=false auf Backends, online-mode=true auf Velocity. Der Proxy verifiziert Lizenzen, Backends vertrauen dem Proxy durch Modern Forwarding.

Netzwerk-Topologie: Proxy, Lobby, Game Server

Gute Topologie bedeutet: Jeder neue Spieler landet zuerst in der Lobby.

Lastpuffer. Lobbys sind leichtgewichtig und belasten die CPU kaum
Serverauswahl. Spieler waehlen per GUI oder Befehlen ihren Zielserver
Fallback. Bei einem Game-Server-Crash werden Spieler zur Lobby zurueckgeschickt, statt getrennt zu werden
Wartung. Game-Server koennen neugestartet werden, ohne Spieler aus dem Netzwerk zu werfen

# Fallback-Konfiguration in velocity.toml
[servers]
lobby = "127.0.0.1:30001"
survival = "127.0.0.1:30002"
try = ["lobby"]

Gemeinsame Datenbanken: MySQL und Redis

Bei mehreren Servern muessen Daten synchronisiert werden. Zwei Hauptwerkzeuge: MySQL fuer dauerhafte Speicherung und Redis fuer Caching und Messaging.

MySQL: Gemeinsame Daten

Economy, Raenge, Statistiken, Freundeslisten. Eine Datenbank, auf die alle Server zugreifen.

# LuckPerms Konfigurationsbeispiel
storage-method: MySQL
data:
  address: 127.0.0.1:3306
  database: minecraft_network
  username: minecraft
  password: "starkes-passwort"
  pool-settings:
    maximum-pool-size: 10

Redis: Cache und Messaging

Redis ist schneller als MySQL fuer haeufige Operationen. Spieleranzahl, Datencache, Echtzeit-Synchronisation.

MySQL: Accounts, Guthaben, Inventare, Statistiken
Redis: Online-Status, Cache, Server-uebergreifende Nachrichten, Warteschlangen

Kommunikation zwischen Servern

Server muessen miteinander kommunizieren. Ein Spieler auf Survival schreibt einem Freund auf Minigames. Globaler Chat. Geldtransfers. Party-Einladungen.

Plugin Messaging Channel

Velocity unterstuetzt den BungeeCord Plugin Messaging Channel. Backends koennen Nachrichten ueber den Proxy senden.

Redis Pub/Sub

Fuer komplexere Logik eignet sich Redis Pub/Sub. Jeder Server abonniert Kanaele und kann Nachrichten senden/empfangen:

Survival veroeffentlicht → Redis-Kanal "global_chat" → Alle Server empfangen
Minigames veroeffentlicht → Redis-Kanal "party_invite" → Zielserver empfaengt

Das funktioniert auch, wenn Server auf verschiedenen Maschinen laufen.

Wichtig zu wissen: Plugin Messaging funktioniert nur, wenn mindestens ein Spieler auf beiden Servern (Sender und Empfaenger) online ist. Bei leeren Servern werden Nachrichten nicht zugestellt. Redis Pub/Sub hat diese Einschraenkung nicht und ist deshalb zuverlaessiger fuer serveruebergreifende Kommunikation.

Beispiel fuer Redis Pub/Sub in einem Plugin:

// Kanal abonnieren
jedis.subscribe(new JedisPubSub() {
    @Override
    public void onMessage(String channel, String message) {
        if (channel.equals("global_chat")) {
            Bukkit.broadcastMessage(message);
        }
    }
}, "global_chat", "party_invite");

// Nachricht veroeffentlichen
jedis.publish("global_chat", playerName + ": " + chatMessage);

Load-Balancing-Strategien

Bei mehreren Servern desselben Typs (z.B. drei Minigame-Server) muessen Spieler verteilt werden.

Round-Robin: Spieler gehen der Reihe nach. Erster zu Minigames-1, zweiter zu Minigames-2, dritter zu Minigames-3, dann wieder von vorne. Einfach, aber beruecksichtigt nicht die tatsaechliche Serverlast.

Least Connections: Intelligenterer Ansatz. Spieler gehen zum Server mit den wenigsten Spielern. Wird ueber ein Velocity-Plugin implementiert. Bessere Verteilung in der Praxis.

Queue-basiert: Fuer Modi wie BedWars oder SkyWars. Spieler treten einer Warteschlange bei, das System findet einen freien Server und schickt eine Gruppe dorthin. Am komplexesten, bietet aber das beste Spielerlebnis fuer kompetitive Modi.

Sicherheit auf jeder Ebene

Sicherheit in einer Multi-Server-Architektur ist komplexer als bei einem Einzelserver. Jede Schicht braucht eigenen Schutz.

Ebene 1: DDoS-Schutz

Erste Schicht: Traffic-Filterung BEVOR er dich erreicht. Ein spezialisierter DDoS-Filter vor dem gesamten Netzwerk. Mehr zur Auswahl in unserem Hosting und DDoS-Schutz Guide.

Ebene 2: Firewall

Backend-Server duerfen nicht aus dem Internet erreichbar sein. Nur der Proxy darf sich verbinden:

# Auf jedem Backend-Server
iptables -A INPUT -p tcp --dport 30001:30010 -s PROXY_IP -j ACCEPT
iptables -A INPUT -p tcp --dport 30001:30010 -j DROP

Ebene 3: Modern Forwarding

Velocity Modern Forwarding mit HMAC-SHA256. Kein Legacy-BungeeCord-Forwarding. Details in unserer Sicherheits-Checkliste.

Ebene 4: Datenbankzugriff

MySQL und Redis lauschen nur auf localhost oder dem internen Netzwerk:

# MySQL nur localhost
bind-address = 127.0.0.1

# Redis nur localhost
bind 127.0.0.1
requirepass "starkes-passwort"

Dienste trennen

Bei einem kleinen Netzwerk kann alles auf einer Maschine laufen. Beim Wachsen muss man trennen.

Eine Maschine (bis 100 Spieler)

[Maschine 1]
├── Velocity
├── Lobby
├── Survival
├── Minigames
├── MySQL
└── Redis

Zwei Maschinen (100-300 Spieler)

[Maschine 1: Proxy + Leicht]         [Maschine 2: Schwer + DB]
├── Velocity                          ├── Survival
├── Lobby                             ├── Minigames
├── Redis                             └── MySQL

Drei+ Maschinen (300+ Spieler)

[Maschine 1: Proxy]    [Maschine 2: Games]    [Maschine 3: DB]
├── Velocity            ├── Survival            ├── MySQL
├── Lobby               ├── Minigames-1         └── Redis
                        └── Minigames-2

Faustregel: Schwere Game-Server getrennt von der Datenbank. Eine belastete DB kann alle Disk-I/O aufbrauchen, und Game-Server fangen an zu laggen.

Docker fuer Server-Verwaltung

Docker vereinfacht die Verwaltung mehrerer Server. Jeder Server in seinem eigenen Container, isolierte Umgebung, einfache Skalierung.

# docker-compose.yml
version: '3.8'

services:
  velocity:
    image: itzg/bungeecord
    environment:
      TYPE: VELOCITY
    ports:
      - "25565:25565"
    volumes:
      - ./velocity:/server

  lobby:
    image: itzg/minecraft-server
    environment:
      TYPE: PAPER
      VERSION: "1.21.4"
      EULA: "TRUE"
      SERVER_PORT: 30001
    volumes:
      - ./lobby:/data

  survival:
    image: itzg/minecraft-server
    environment:
      TYPE: PAPER
      VERSION: "1.21.4"
      EULA: "TRUE"
      SERVER_PORT: 30002
    volumes:
      - ./survival:/data

  mysql:
    image: mysql:8.0
    environment:
      MYSQL_ROOT_PASSWORD: root-passwort
      MYSQL_DATABASE: minecraft

  redis:
    image: redis:7-alpine
    command: redis-server --requirepass redis-passwort

Docker bietet Isolierung, schnelles Deployment, Ressourcenlimits pro Container und einfaches Rollback ueber Images.

Horizontale Skalierung

Horizontale Skalierung bedeutet: mehr Server hinzufuegen statt bestehende aufzuruesten.

Das Prinzip ist einfach: Wenn Minigames-1 ausgelastet ist, kaufe nicht mehr RAM. Starte Minigames-2 auf einer anderen Maschine.

Voraussetzungen:

Stateless Backends. Spielerdaten in MySQL/Redis, nicht in lokalen Dateien
Einheitliche Konfiguration. Ansible oder aehnliches fuer konsistentes Deployment
Dynamische Registrierung. Ein Velocity-Plugin, das neue Backends automatisch hinzufuegt
Monitoring. Die Last jedes Backends muss bekannt sein

Hochverfuegbarkeit

Single Points of Failure sind der Feind. Wenn Velocity ausfaellt, ist das gesamte Netzwerk unerreichbar. Wenn MySQL stirbt, funktioniert nichts.

Redundante Proxies

Zwei Velocity-Instanzen hinter DNS Round-Robin oder einem TCP Load Balancer:

DNS: play.myserver.com
    → 10.0.0.1 (Velocity-1)
    → 10.0.0.2 (Velocity-2)

Oder mit HAProxy:

frontend minecraft
    bind *:25565
    default_backend velocity_servers

backend velocity_servers
    balance roundrobin
    server velocity1 10.0.0.1:25565 check
    server velocity2 10.0.0.2:25565 check

Datenbank-Replikation

MySQL Master-Slave-Replikation. Master verarbeitet Schreibzugriffe, Slave verarbeitet Lesezugriffe. Redis Sentinel fuer automatisches Failover bei Master-Ausfall.

Wo passt DDoS-Schutz in die Architektur?

DDoS-Schutz steht vor allem. Es ist die allererste Schicht, durch die jeder Spieler-Traffic laeuft.

Internet
    ↓
[DDoS Filter: MineGuard]   ← L3/L4/L7 Filterung
    ↓
[Velocity Proxy :25565]     ← Routing
    ↓
[Backend Server]            ← Spiellogik
    ↓
[MySQL / Redis]             ← Daten

Die echte Server-IP ist hinter dem DDoS-Filter verborgen. Spieler verbinden sich mit der Filter-Adresse. Der Filter laesst legitimen Traffic durch und blockiert Angriffe. Backend-Server sehen den Angriffs-Traffic nie.

Wichtig: Der DDoS-Filter muss VOR dem Proxy stehen, nicht danach. Wenn ein Angriff Velocity erreicht, wird selbst ein leistungsstarker Proxy unter volumetrischen Angriffen zusammenbrechen.

Praxisbeispiele fuer Architekturen

Kleines Netzwerk (50-100 Spieler)

Ein VPS mit 16 GB RAM und 4 Kernen.

[DDoS Filter]
    ↓
[VPS: 16GB RAM]
├── Velocity          (256 MB)
├── Lobby             (512 MB)
├── Survival          (6 GB)
├── Creative          (2 GB)
├── MySQL             (1 GB)
└── Redis             (256 MB)

Budget: 30-50 EUR/Monat. Fokus auf richtige JVM-Flags und Paper-Konfigurationsoptimierung (view-distance, simulation-distance, entity-activation-range). Velocity braucht bei dieser Groesse kaum Ressourcen. Gib den Game-Servern so viel RAM wie moeglich.

Mittleres Netzwerk (200-500 Spieler)

Zwei Dedicated Server. Schwere Game-Server getrennt vom Proxy und Datenbanken.

[DDoS Filter: MineGuard]
    ↓
[Server 1: 32GB, 8 Kerne]       [Server 2: 64GB, 8 Kerne]
├── Velocity                      ├── Survival        (12 GB)
├── Lobby           (1 GB)        ├── SkyBlock         (8 GB)
├── Redis                         ├── Minigames-1      (4 GB)
├── MySQL                         └── Minigames-2      (4 GB)

Budget: 100-200 EUR/Monat. Ab dieser Stufe wird Monitoring zwingend. Prometheus + Grafana einrichten, oder zumindest ein einfaches Skript, das TPS, CPU und RAM pro Server ueberwacht. Ohne Monitoring erfaehrst du von Problemen erst, wenn Spieler sich beschweren.

Backups auf dieser Ebene automatisieren. Jeder Server wird separat gesichert, Backups auf externem Speicher (S3, separate Festplatte). Datenverlust auf einem Server darf die anderen nicht betreffen.

Grosses Netzwerk (1000+ Spieler)

Ein Cluster aus 5+ Servern. Das ist ein vollstaendiges Production-Grade-Infrastrukturprojekt.

[DDoS Filter]
    ↓
[HAProxy / DNS Round-Robin]
    ↓
[Proxy-1] [Proxy-2]   ← zwei Velocity hinter Load Balancer
    ↓
[Lobby-1] [Lobby-2]   ← zwei Lobbys fuer Redundanz
    ↓
[Survival-1] [Survival-2] [Survival-3]  ← Survival-Cluster
[SkyBlock-1] [SkyBlock-2]               ← SkyBlock-Cluster
[BedWars-1..10]                          ← Minigame-Pool
    ↓
[MySQL Master] → [MySQL Slave-1] [MySQL Slave-2]
[Redis Master] → [Redis Slave] + [Sentinel]

Budget: 500+ EUR/Monat. Volle Redundanz, horizontale Skalierung, automatisches Failover. Auf dieser Ebene braucht man einen DevOps-Ingenieur oder zumindest einen Sysadmin mit Cluster-Erfahrung. Ansible fuer Deployment, CI/CD fuer automatische Updates. Jede Komponente muss austauschbar sein, ohne das gesamte Netzwerk herunterzufahren.

Checkliste vor dem Start

Bevor du auf Multi-Server-Architektur umstellst:

Stelle sicher, dass alle Plugins MySQL/Netzwerk-Speicher unterstuetzen
Richte Velocity mit Modern Forwarding ein
Sichere Backend-Ports per Firewall ab
Pruefe, dass Redis und MySQL nur auf internen Interfaces lauschen
Richte pro-Server-Backups ein
Setze Monitoring auf (TPS, CPU, RAM pro Backend)
Verbinde DDoS-Schutz vor dem Netzwerk
Teste Failback: Was passiert bei Backend-Ausfall?
Pruefe serveruebergreifende Synchronisation (Raenge, Guthaben, Inventar)
Dokumentiere deine Architektur

Starte einfach. Ein Velocity, eine Lobby, ein Game-Server. Wenn das stabil laeuft, fuege den naechsten Server hinzu. Versuche nicht, am ersten Tag einen 10-Maschinen-Cluster aufzubauen.

Netzwerk-Architektur ist kein Endzustand, sondern eine staendige Evolution. Das Projekt waechst, die Infrastruktur waechst mit. Wichtig ist, dass das Fundament von Anfang an stimmt.

Minecraft Netzwerk-Architektur: Vom Einzelserver zum Cluster