Hochverfügbarkeit · Standort Deutschland
High Availability Cluster
Hardware fällt aus, Netze haben Störungen, Software hat Fehler – die Frage ist nicht ob, sondern wann. Ein High Availability Cluster ist so gebaut, dass Ihre Anwendung davon nichts mitbekommt.
Einordnung
Was Hochverfügbarkeit in Zahlen bedeutet.
Verfügbarkeit wird in Neunen gemessen – und die Unterschiede sind größer, als sie klingen: 99 % bedeuten über drei ganze Tage Ausfall pro Jahr. 99,9 % sind noch knapp neun Stunden, erst 99,99 % drücken es unter eine Stunde. Welche Stufe Ihre Anwendung braucht, ist eine geschäftliche Frage: Was kostet Sie eine Stunde Stillstand?
Genau deshalb legen wir das Verfügbarkeitsziel gemeinsam fest, bevor die Architektur entsteht – und bauen dann exakt so viel Redundanz, wie dieses Ziel verlangt. Zugesagte Ziele stehen im Betriebsvertrag, nicht nur auf der Website.
Architekturprinzip
Kein Single Point of Failure.
Hochverfügbarkeit entsteht nicht durch bessere Hardware, sondern durch Architektur: Jede Komponente, deren Ausfall Ihre Anwendung stoppen würde, existiert mehrfach.
- Redundante Nodes in N+1-Auslegung: Der Ausfall eines Proxmox-Nodes ist ein Normalfall, kein Notfall.
- Automatischer Failover ohne manuellen Eingriff, typischerweise innerhalb von Sekunden.
- Redundante Loadbalancer mit Floating IP: Auch der Verteiler selbst ist kein Single Point of Failure.
- Replizierter Storage: Ceph oder ZFS-Replikation – ein Plattendefekt kostet keine Daten.
- Redundante Netzwerkpfade: Bonding, doppelte Uplinks, getrennte Netze für Storage und Management.
- Regelmäßige Failover-Tests mit Protokoll: Wir ziehen den Stecker, bevor es der Zufall tut.
Entscheidungslogik
Quorum, Fencing und das Split-Brain-Problem.
Der heikelste Moment eines Clusters ist nicht der Ausfall selbst, sondern die Entscheidung danach: Wer übernimmt? Damit die Automatik richtig entscheidet, braucht sie klare Regeln. Quorum stellt sicher, dass nur eine Mehrheit der Nodes handlungsfähig ist – deshalb bestehen unsere Cluster aus mindestens drei Nodes.
Fencing ergänzt das Quorum: Ein als fehlerhaft erkannter Node wird sauber vom Verbund getrennt, bevor er Schaden anrichten kann. So verhindern wir Split-Brain-Situationen, in denen zwei Cluster-Hälften gleichzeitig schreiben und Daten unwiederbringlich auseinanderlaufen.
Referenz
Der Failover, wie er tatsächlich abläuft.
Das komplette Ausfall-Szenario – vom Corosync-Heartbeat bis zur Alarmierung unserer Bereitschaft – haben wir auf der Startseite und unter Failover & Hochverfügbarkeit Schritt für Schritt beschrieben.
FAQ
Häufige Fragen zur Hochverfügbarkeit.
Merken meine Nutzer einen Failover?
Im Regelfall nicht. Der Loadbalancer nimmt den ausgefallenen Node binnen Sekunden aus der Verteilung; bestehende Verbindungen werden neu aufgebaut. Wie nahtlos das im Einzelfall ist, hängt von der Anwendung ab – das besprechen wir ehrlich im Konzept.
Reicht ein Zwei-Node-Cluster?
Für echte Hochverfügbarkeit nicht: Bei zwei Nodes gibt es im Fehlerfall keine Mehrheit, der Cluster kann nicht sicher entscheiden. Mit externem Quorum-Device ist es möglich – wir empfehlen für geschäftskritische Anwendungen aber drei Nodes.
Ersetzt Hochverfügbarkeit das Backup?
Nein. Replikation schützt vor Hardware-Ausfall, repliziert aber auch Fehler: Ein versehentliches Löschen liegt sofort auf allen Kopien. Getrennte, getestete Backups gehören deshalb immer dazu.
Welche Verfügbarkeit wird vertraglich zugesagt?
Das Verfügbarkeitsziel legen wir gemeinsam fest, passend zu Anwendung und Redundanzgrad – und schreiben es in den Betriebsvertrag. Pauschale Neunen ohne Architektur dahinter versprechen wir bewusst nicht.
Kontakt
Was kostet Sie eine Stunde Stillstand?
Lassen Sie uns über Ihr Verfügbarkeitsziel sprechen. Erste Einschätzung innerhalb eines Werktags, unverbindlich und kostenfrei.
Projekt anfragen