Hochverfügbarkeit auf netcup: Zwei VPS mit Keepalived, Failover-IP und Cloud-vLAN absichern

Wer kritische Dienste auf einem einzelnen VPS betreibt, lebt gefährlich: Ein Kernel-Panic, ein fehlgeschlagenes Update oder ein Hardwarefehler reicht, und der Dienst ist stundenlang unerreichbar. Mit zwei netcup-Servern, dem kostenlosen Cloud-vLAN und einer Failover-IPv4 lässt sich das mit überschaubarem Aufwand ändern. Keepalived übernimmt den Herzschlag per VRRP über das private VLAN-Interface, und ein kleines Skript schwenkt bei einem Ausfall die öffentliche IP automatisch über die netcup REST API um. Das Ergebnis: typische Ausfallzeiten von unter 20 Sekunden, ohne proprietäre Cluster-Middleware und ohne monatliche Mehrkosten für die Netzwerkkomponenten.

Voraussetzungen

1. Zwei netcup VPS oder Root-Server im selben Rechenzentrum (z. B. Nürnberg) – standortübergreifende Failover-IPs werden nicht angeboten
2. Debian 12 oder Ubuntu 24.04 (root-Zugang per SSH auf beiden Knoten)
3. Eine bestellte Failover-IPv4 aus dem netcup CCP (Erweiterungen für KVM-Server)
4. Ein bestelltes Cloud vLAN Free 100 Mbit/s aus dem netcup CCP, beiden Servern zugewiesen
5. Einen aktiven netcup REST-API-Token (ab Oktober 2025 im SCP unter „API" verfügbar)
6. Grundkenntnisse in Linux-Netzwerkkonfiguration und SSH

Schritt 1: Failover-IP und Cloud-vLAN im CCP/SCP bestellen

Beide Erweiterungen müssen zwingend im selben Rechenzentrum wie deine VPS liegen – ein nachträgliches Umziehen ist nicht möglich. Wähle also erst den Standort deiner Server aus, bevor du bestellst.

1. Rufe https://www.customercontrolpanel.de auf und melde dich an.
2. Navigiere zu Meine Bestellungen → Erweiterungen für KVM-Server → Failover IPv4 und schließe die Bestellung ab.
3. Wechsle ins Server Control Panel (SCP) unter https://www.servercontrolpanel.de, öffne Server 1 und weise dort unter Netzwerk → Failover-IP die neue IP der primären Netzwerkkarte zu.
4. Zurück im CCP: Bestelle unter Erweiterungen → Cloud vLAN Free 100 Mbit/s das VLAN-Produkt. Weise es beiden Servern zu – das VLAN erscheint anschließend auf jedem Knoten als zweite Netzwerkkarte (meist eth1 oder ens7, je nach Image).

Verifizieren: Führe auf beiden Servern ip link show aus. Du solltest mindestens zwei Interfaces sehen: eth0 (öffentlich) und eth1 (VLAN, noch ohne IP-Adresse).

Schritt 2: eth1-Interface im Cloud-vLAN konfigurieren

Beide Server erhalten statische private Adressen im VLAN-Subnetz. Du kannst ein beliebiges RFC-1918-Subnetz verwenden; in diesem Beispiel nutzen wir 10.132.0.0/24.

Server 1 – /etc/network/interfaces.d/vlan.cfg

auto eth1
iface eth1 inet static
    address 10.132.0.10
    netmask 255.255.255.0

Server 2 – /etc/network/interfaces.d/vlan.cfg

auto eth1
iface eth1 inet static
    address 10.132.0.20
    netmask 255.255.255.0
sudo systemctl restart networking
ip addr show eth1   # Zuweisung prüfen

Verifizieren: ping -c3 10.132.0.20 von Server 1 aus muss drei erfolgreiche Antworten liefern. Kein Ping? Prüfe, ob das Cloud-vLAN im SCP wirklich beiden Servern zugewiesen ist.

Schritt 3: IPv4-Forwarding aktivieren

Damit die Failover-IP auf dem aktiven Knoten korrekt weitergeleitet wird, muss IP-Forwarding auf beiden Servern eingeschaltet sein.

echo "net.ipv4.ip_forward = 1" | sudo tee -a /etc/sysctl.conf
sudo sysctl -p

Verifizieren: sysctl net.ipv4.ip_forward gibt net.ipv4.ip_forward = 1 aus.

Schritt 4: keepalived installieren

sudo apt update && sudo apt install -y keepalived

Schritt 5: keepalived konfigurieren

Die VRRP-Instanz läuft ausschließlich über eth1 (das private VLAN). Würde sie auf eth0 laufen, würden VRRP-Multicast-Pakete ins öffentliche Internet gesendet – was andere netcup-Kunden stören kann und zur Sperrung des Servers führen kann.

Die virtuelle IP 10.132.0.100 ist eine rein interne Cluster-IP im VLAN und hat nichts mit der öffentlichen Failover-IP zu tun.

Server 1 – /etc/keepalived/keepalived.conf (MASTER)

vrrp_instance VI_1 {
    state MASTER
    interface eth1
    virtual_router_id 101
    priority 255
    advert_int 2
    authentication {
        auth_type PASS
        auth_pass GEHEIMES_PASSWORT
    }
    virtual_ipaddress {
        10.132.0.100
    }
    notify_master /etc/keepalived/scripts/to_master.sh
    notify_backup /etc/keepalived/scripts/to_backup.sh
    notify_fault  /etc/keepalived/scripts/to_backup.sh
}

Server 2 – /etc/keepalived/keepalived.conf (BACKUP)

vrrp_instance VI_1 {
    state BACKUP
    interface eth1
    virtual_router_id 101
    priority 254
    advert_int 2
    authentication {
        auth_type PASS
        auth_pass GEHEIMES_PASSWORT
    }
    virtual_ipaddress {
        10.132.0.100
    }
    notify_master /etc/keepalived/scripts/to_master.sh
    notify_backup /etc/keepalived/scripts/to_backup.sh
    notify_fault  /etc/keepalived/scripts/to_backup.sh
}

Wichtige Parameter im Überblick:

Nach drei ausgebliebenen Heartbeats (ca. 6 Sekunden bei advert_int 2) stuft der BACKUP-Knoten den MASTER als ausgefallen ein und übernimmt die Rolle.

Schritt 6: netcup REST-API-Token einrichten

Seit Oktober 2025 bietet netcup im SCP eine REST API an, die den alten SOAP-Webservice ablöst. Der SOAP-Dienst wird am 1. Mai 2026 abgeschaltet – wer noch ein SOAP-Skript betreibt, sollte jetzt migrieren.

Rufe im SCP oben rechts API → REST API Docs auf und folge dem Abschnitt „Authentifizierung". Nach der einmaligen Browser-Autorisierung erhältst du einen Refresh-Token, den du auf beiden Servern sicherst:

# Refresh-Token dauerhaft speichern (einmalig)
echo "DEIN_REFRESH_TOKEN" > ~/.netcup_refresh_token
chmod 600 ~/.netcup_refresh_token

# Bearer-Token testweise abrufen
REFRESH_TOKEN=$(cat ~/.netcup_refresh_token)
BEARER=$(curl -s -X POST "https://www.servercontrolpanel.de/api/v1/auth/token" \
  -H "Content-Type: application/json" \
  -d "{\"grant_type\":\"refresh_token\",\"refresh_token\":\"${REFRESH_TOKEN}\"}" \
  | python3 -c "import sys,json; print(json.load(sys.stdin)['access_token'])")
echo "Token OK: ${BEARER:0:20}..."

Ermittle anschließend deine REST-API-User-ID (nicht die CCP-Kundennummer!) sowie die ID der Failover-IP und die Server-IDs beider Knoten:

USER_ID="DEINE_USER_ID"

# Alle Failover-IPs auflisten
curl -s -X GET "https://www.servercontrolpanel.de/api/v1/users/${USER_ID}/failoverips/v4" \
  -H "Authorization: Bearer ${BEARER}" | python3 -m json.tool

# Server-IDs auflisten
curl -s -X GET "https://www.servercontrolpanel.de/api/v1/servers" \
  -H "Authorization: Bearer ${BEARER}" | python3 -m json.tool

Achtung: Die USER_ID für die REST API ist eine separate ID aus dem SCP-API-Bereich – sie unterscheidet sich von deiner CCP-Kundennummer. Eine falsche ID führt zu HTTP 403 oder 404.

Schritt 7: Failover-Skript anlegen

Das Skript to_master.sh wird von keepalived als root aufgerufen, sobald ein Knoten die MASTER-Rolle übernimmt. Es holt sich einen frischen Bearer-Token und leitet die Failover-IP per PATCH-Request auf diesen Server um. Die Retry-Logik berücksichtigt das Rate-Limit der API von 301 Sekunden zwischen schnellen Umschwenkungen.

sudo mkdir -p /etc/keepalived/scripts

/etc/keepalived/scripts/to_master.sh

#!/bin/bash
# netcup Failover – REST API (ab Oktober 2025)
# Variablen anpassen:
USER_ID="DEINE_USER_ID"
REFRESH_TOKEN_FILE="$HOME/.netcup_refresh_token"
FAILOVER_IP_ID="ID_DER_FAILOVER_IP"
TARGET_SERVER_ID="ID_DIESES_SERVERS"
API_BASE="https://www.servercontrolpanel.de/api/v1"
MAX_RETRIES=10
RETRY_INTERVAL=5

get_bearer() {
  curl -s -X POST "${API_BASE}/auth/token" \
    -H "Content-Type: application/json" \
    -d "{\"grant_type\":\"refresh_token\",\"refresh_token\":\"$(cat ${REFRESH_TOKEN_FILE})\"}" \
    | python3 -c "import sys,json; print(json.load(sys.stdin)['access_token'])"
}

BEARER=$(get_bearer)

for i in $(seq 1 ${MAX_RETRIES}); do
  HTTP_CODE=$(curl -s -o /dev/null -w "%{http_code}" \
    -X PATCH "${API_BASE}/users/${USER_ID}/failoverips/v4/${FAILOVER_IP_ID}" \
    -H "Authorization: Bearer ${BEARER}" \
    -H "Content-Type: application/json" \
    -d "{\"server_id\": \"${TARGET_SERVER_ID}\"}")
  if [ "$HTTP_CODE" == "200" ] || [ "$HTTP_CODE" == "204" ]; then
    echo "[$(date)] Failover erfolgreich (Versuch ${i})" >> /var/log/keepalived-failover.log
    # Failover-IP lokal als Interface-Alias einbinden
    ip addr add FAILOVER_IP/32 dev eth0 label eth0:1 2>/dev/null || true
    exit 0
  fi
  echo "[$(date)] Versuch ${i} fehlgeschlagen (HTTP ${HTTP_CODE}), warte ${RETRY_INTERVAL}s" \
    >> /var/log/keepalived-failover.log
  sleep ${RETRY_INTERVAL}
done
echo "[$(date)] Failover nach ${MAX_RETRIES} Versuchen fehlgeschlagen!" \
  >> /var/log/keepalived-failover.log
exit 1

Lege außerdem eine leere to_backup.sh an (keepalived erwartet sie) und setze die Berechtigungen:

sudo touch /etc/keepalived/scripts/to_backup.sh
sudo chmod +x /etc/keepalived/scripts/to_master.sh
sudo chmod +x /etc/keepalived/scripts/to_backup.sh
sudo chown root:root /etc/keepalived/scripts/*.sh

Ersetze in to_master.sh den Platzhalter FAILOVER_IP durch die tatsächliche öffentliche IP-Adresse. Das ip addr add am Ende ist entscheidend: Die API-Weiterleitung allein reicht nicht – der neue MASTER muss die IP auch lokal als Interface-Alias einbinden, sonst beantwortet er keine Pakete für diese Adresse.

Schritt 8: keepalived starten und testen

# Auf beiden Servern:
sudo systemctl enable --now keepalived
sudo systemctl status keepalived

Beobachte den VRRP-Verkehr auf dem VLAN-Interface, um sicherzustellen, dass keepalived die richtigen Pakete sendet:

sudo tcpdump proto 112 -i eth1 -n

Führe einen kontrollierten Failover-Test durch, indem du keepalived auf Server 1 anhältst:

# Auf Server 1:
sudo systemctl stop keepalived
# Server 2 sollte nach ca. 6 Sekunden MASTER werden und das Skript aufrufen

# Ergebnis auf Server 2 prüfen:
ip addr show eth0                      # Failover-IP sollte als eth0:1 erscheinen
cat /var/log/keepalived-failover.log   # Skript-Protokoll

Verifizieren: Nach dem Stoppen von keepalived auf Server 1 erscheint in /var/log/keepalived-failover.log auf Server 2 eine Zeile „Failover erfolgreich", und ip addr show eth0 zeigt die Failover-IP als eth0:1. Ein curl -I http://FAILOVER_IP von einem externen Rechner muss den Dienst von Server 2 erreichen.

API-Schnittstellenvergleich: SOAP vs. REST

Cloud-vLAN-Produktübersicht

Troubleshooting / Typische Fehler

Keepalived sendet VRRP auf eth0 statt eth1

Prüfe mit tcpdump proto 112 -i eth0: Erscheinen dort Pakete, läuft die VRRP-Instanz auf der falschen Schnittstelle. Korrigiere interface eth1 in keepalived.conf und starte den Dienst neu. VRRP auf der öffentlichen IP kann zur Sperrung durch netcup führen.

HTTP 403 oder 404 beim REST-API-Aufruf

Die USER_ID für die REST API ist nicht die CCP-Kundennummer. Schlage sie einmalig im SCP-API-Bereich nach. Ein 401-Fehler hingegen deutet auf einen abgelaufenen oder ungültigen Bearer-Token hin – prüfe, ob ~/.netcup_refresh_token korrekt gesetzt ist und die Datei für root lesbar ist (chmod 600).

Failover-Skript wird nicht ausgeführt

Das häufigste Problem: die Skriptdatei fehlt die Ausführberechtigung oder gehört nicht root. Prüfe mit ls -la /etc/keepalived/scripts/ – beide Dateien müssen root als Eigentümer haben und ausführbar sein. keepalived protokolliert Fehler in journalctl -u keepalived.

Rate-Limit der REST API (HTTP 429)

Bei einem schnellen Hin- und Herschalten (Flapping) blockiert die API weitere Umschwenkungen für 301 Sekunden. Das Retry-Skript fängt das ab, aber bei zu kurzen Heartbeat-Intervallen kann Flapping auftreten. Erhöhe advert_int auf 3 und erwäge, nopreempt in der BACKUP-Konfiguration zu setzen, damit Server 1 nach Wiederherstellung nicht sofort zurückübernimmt.

Failover-IP nach Umschwenkung nicht erreichbar

Die API-Weiterleitung allein genügt nicht: Der neue MASTER muss die Failover-IP auch lokal einbinden. Prüfe mit ip addr show eth0, ob der Alias eth0:1 gesetzt ist. Fehlt er, hat das Skript die Zeile ip addr add nicht erreicht – überprüfe das Log /var/log/keepalived-failover.log.

SOAP-Skript nach dem 1. Mai 2026

Wer das alte SOAP-Webservice-Passwort noch im Skript hat, verliert nach dem Abschalttermin den automatischen Failover vollständig. Migriere jetzt auf die REST API – das alte Webservice-Passwort (gesetzt unter SCP → Optionen → Webservice) funktioniert nicht mit der neuen API.

Häufige Fragen

Kann ich die Failover-IP zwischen Servern in verschiedenen Städten schwenken?

Nein. netcup bietet keine standortübergreifenden Failover-IPs. Beide VPS und die Failover-IP müssen im selben Rechenzentrum liegen – also entweder beide in Nürnberg oder beide in Mannheim. Falsch bestellte Produkte können nicht umgezogen werden.

Was passiert, wenn Server 1 zurückkommt (Revert)?

Im Standard-Modus ist keepalived „preemptive": Da Server 1 mit priority 255 höher als Server 2 mit 254 priorisiert ist, übernimmt er nach Wiederherstellung automatisch die MASTER-Rolle zurück. Das notify_master-Skript auf Server 1 leitet die IP dann per API zurück. Um unerwünschtes Flapping zu vermeiden, kannst du in der BACKUP-Konfiguration nopreempt eintragen.

Wie lange dauert der automatische Failover?

Bei advert_int 2 erkennt der BACKUP nach ca. 6 Sekunden (3 ausgebliebene Pakete) den Ausfall. Der anschließende REST-API-Aufruf dauert 1–3 Sekunden. Die gesamte Ausfallzeit liegt typischerweise bei 10–20 Sekunden.

Brauche ich das Cloud-vLAN zwingend?

Technisch könnte VRRP auch über eth0 laufen, aber dann wären VRRP-Multicast-Pakete öffentlich sichtbar. Das verstößt gegen netcup-Nutzungsbedingungen und kann zur Sperrung führen. Das private Cloud-vLAN ist die richtige und empfohlene Vorgehensweise – und kostenlos.

Kann ich das SOAP-Skript noch bis Mai 2026 nutzen?

Offiziell ja. In der Praxis empfiehlt sich jedoch eine baldige Migration, da ein „deprecated" markierter Dienst unangekündigt instabil werden kann. Das REST-API-Skript ist nicht wesentlich komplexer, bietet aber mehr Kontrolle über Fehlerbehandlung und Rate-Limits.

Fazit

Ein HA-Cluster aus zwei netcup-VPS ist kein Hexenwerk – die Kombination aus keepalived, Cloud-vLAN und REST API ergibt eine solide Lösung, die in rund 90 Minuten steht. Das private VLAN hält den VRRP-Heartbeat vom öffentlichen Internet fern, und das notify_master-Skript erledigt den Rest vollautomatisch. Die wichtigsten Stolperfallen sind das Verwechseln der API-User-ID mit der Kundennummer, fehlende Ausführungsrechte am Skript und das vergessene ip addr add für den Interface-Alias. Wer jetzt noch das alte SOAP-Skript betreibt, sollte die Migration zur REST API nicht aufschieben: Der Abschalttermin 1. Mai 2026 kommt schneller als gedacht.

Für weiterführende Absicherung des Clusters empfiehlt sich ein Blick auf die netcup SCP-Firewall mit UFW-Zusammenspiel sowie auf VPS absichern und härten mit UFW, SSH-Keys und Fail2Ban. Wer die netcup REST API darüber hinaus für weitere Automatisierungen nutzen möchte, findet in der Anleitung netcup SCP REST API einrichten und nutzen die passende Grundlage. Zum Thema privates VLAN gibt es außerdem die ergänzende Anleitung netcup Cloud VLAN einrichten: private Server-Kommunikation ohne öffentliche IP.

Weiterführende Anleitungen und Quellen

1. netcup SCP REST API einrichten und nutzen: Server automatisieren ohne SOAP
2. netcup Cloud VLAN einrichten: Private Server-Kommunikation ohne öffentliche IP
3. netcup Failover-IP: Bestellung, SCP-Zuweisung und Server-zu-Server-Wechsel
4. VPS absichern und härten: Anleitung mit UFW, SSH-Keys und Fail2Ban (Hetzner/Netcup)
5. netcup Helpcenter: Adding IP Addresses / Failover IP
6. netcup Community Tutorial: High Availability Cluster with Keepalived and Failover IPv4
7. netcup Helpcenter: REST API (ab Oktober 2025)
8. netcup Helpcenter: SCP Webservice (deprecated, bis Mai 2026)