Verfügbarkeit berechnen: Rechner für Prozentwert und Ausfallzeit
Die erlaubte Ausfallzeit folgt aus einer einzigen Rechnung: Ausfallzeit = Zeitraum × (100 % − Verfügbarkeit). Geben Sie unten einen Prozentwert ein, erhalten Sie die Ausfallzeit pro Jahr, Monat, Woche und Tag. Die Umkehrung ermittelt aus einer tolerierbaren Ausfallzeit den Prozentwert, den Sie dafür brauchen.
Verfügbarkeit ist nach der Definition des Bundesamts für Sicherheit in der Informationstechnik (BSI) die Wahrscheinlichkeit, dass ein System zu einem beliebigen Zeitpunkt alle zugesicherten Eigenschaften erfüllt. Angegeben wird sie meist in Prozent.
Ausfallzeit-Tabelle: von 99 % bis 99,999 % Verfügbarkeit
Bei 99,99 % Verfügbarkeit beträgt die Ausfallzeit höchstens 52,6 Minuten pro Jahr, bei 99,9 % sind es 8,76 Stunden. Jede weitere Neun teilt die erlaubte Ausfallzeit durch zehn. Die Tabelle zeigt die üblichen Stufen für Jahr, Monat, Woche und Tag.
| Verfügbarkeit | pro Jahr | pro Monat (30 Tage) | pro Woche | pro Tag |
|---|---|---|---|---|
| 99 % | 87,6 h (3,65 Tage) | 7,20 h | 1,68 h | 14,4 min |
| 99,5 % | 43,8 h | 3,60 h | 50,4 min | 7,20 min |
| 99,9 % | 8,76 h | 43,2 min | 10,1 min | 1,44 min |
| 99,95 % | 4,38 h | 21,6 min | 5,04 min | 43,2 s |
| 99,99 % | 52,6 min | 4,32 min | 1,01 min | 8,64 s |
| 99,999 % | 5,26 min | 25,9 s | 6,05 s | 864 ms |
Konvention: Jahr = 365 Tage, Monat = 30 Tage, Betrieb rund um die Uhr. Das BSI rechnet in seinen Beispielen mit 365,25 Tagen; 99,9 % ergeben dann 8,77 statt 8,76 Stunden. Werte auf drei signifikante Stellen gerundet. Stand: Oktober 2026.
Verfügbarkeitsklassen nach BSI
Das BSI teilt Verfügbarkeit in seinem Hochverfügbarkeitskompendium in sechs Verfügbarkeitsklassen (VK) ein, unterschieden nach der Anzahl der Neunen. Die Ausfallzeiten gelten für einen Betrieb von 7 × 24 Stunden.
| Klasse | Bezeichnung | mindestens | Ausfall pro Monat | pro Jahr |
|---|---|---|---|---|
| VK 0 | Ohne zugesicherte Verfügbarkeit | keine Prozentangabe | ||
| VK 1 | Normale Verfügbarkeit | 99,0 % | < 8 h | < 88 h |
| VK 2 | Erhöhte Verfügbarkeit | 99,9 % | < 44 min | < 9 h |
| VK 3 | Hochverfügbarkeit | 99,99 % | < 5 min | < 53 min |
| VK 4 | Höchstverfügbar | 99,999 % | < 26 s | < 6 min |
| VK 5 | Verfügbarkeit unter extremen Bedingungen, auch bei höherer Gewalt (Disaster-Tolerant) | keine Prozentangabe; die Ausfallzeit ist laut BSI kaum vorherbestimmbar | ||
Quelle: BSI, HV-Kompendium V 1.6, Band G, Kapitel 2, Tabelle 3 (Stand 2013). Das Kompendium ist zurückgezogen, Band G bleibt zu Informationszwecken veröffentlicht.
Hochverfügbarkeit: Definition und Schwelle
Von Hochverfügbarkeit spricht man nach der Einteilung des BSI üblicherweise ab Verfügbarkeitsklasse 3, also ab 99,99 % oder weniger als 53 Minuten Ausfall pro Jahr. Solche Systeme stehen nahezu unterbrechungsfrei zur Verfügung. Normale Maßnahmen reichen dafür laut BSI nicht aus: Nötig sind Automatismen, die den Zustand überwachen und den Betrieb selbsttätig wiederherstellen, zusammen mit betriebsbereiten Redundanzen.
Die Klassen beschreiben Anforderungen an einen Geschäftsprozess oder ein System; ein Gütesiegel für eine Plattform sind sie nicht. Welche Klasse ein Prozess braucht, richtet sich nach den Folgen eines Ausfalls: den Kosten seines Stillstands und etwaigen rechtlichen oder sicherheitsbezogenen Anforderungen. Weitere Fachbegriffe erklärt das Glossar im Bereich Wissen.
Nicht verwechseln: Verfügbarkeitsklassen nach DIN EN 50600
Auch die Rechenzentrumsnorm DIN EN 50600 kennt vier Verfügbarkeitsklassen. Sie bewerten nach Angaben von CEN-CENELEC die Auslegung von Stromversorgung, Klimatisierung und Verkabelung eines Rechenzentrums, nicht die Verfügbarkeit des Dienstes, der darin läuft. Eine Klasse nach DIN EN 50600 entspricht deshalb nicht der BSI-Klasse gleicher Nummer und sagt allein nichts über die Verfügbarkeit Ihrer Anwendung.
Was Prozente verschweigen: Messpunkt, Zeitraum, Wartung, Teilausfall
Ein Verfügbarkeitswert in Prozent sagt erst dann etwas aus, wenn feststeht, wie er gemessen wird. Zwei Angaben mit demselben Prozentwert können sehr unterschiedliche Zusagen sein: Entscheidend sind Messpunkt, Messzeitraum, der Umgang mit geplanter Wartung und die Frage, ob Teilausfälle mitzählen. Die folgenden fünf Prüffragen klären das für jede Verfügbarkeitsangabe, unabhängig vom Anbieter.
| Frage | Warum sie den Wert verändert |
|---|---|
| Wo wird gemessen? | Ein Server kann laufen, während die Anwendung nicht antwortet. Messungen am Server, am Netzrand oder aus Nutzersicht ergeben unterschiedliche Werte. |
| Über welchen Zeitraum? | 99,9 % pro Jahr lassen einen Ausfall von 8,76 Stunden am Stück zu; pro Monat gemessen sind es höchstens 43,2 Minuten je Monat. |
| Zählt geplante Wartung? | Sind Wartungsfenster ausgenommen, kann die tatsächliche Erreichbarkeit deutlich darunter liegen. |
| Was gilt als Ausfall? | Teilausfälle wie ein defekter Checkout oder stark erhöhte Antwortzeiten zählen nur, wenn die Definition sie erfasst. |
| Wie oft und wie lange? | Derselbe Wert kann einen langen oder viele kurze Ausfälle bedeuten, für Geschäftsprozesse ein großer Unterschied. |
Hinzu kommen zwei Hinweise des BSI. Die in Verträgen übliche Beobachtungsdauer von einem Jahr sichert kaum statistische Signifikanz; ein ausfallfreies Jahr belegt also noch keine hohe Verfügbarkeit. Und je nachdem, ob geplante Wartung, Logistik und Verwaltung als Ausfallzeit zählen, gibt es mehrere Verfügbarkeitsbegriffe. Bleibt offen, welcher gemeint ist, entstehen häufig falsche Erwartungen.
Wir prüfen im Betrieb deshalb mit Health-Checks aus Nutzersicht, ob Ihre Anwendung antwortet, und nicht nur, ob ihre Prozesse laufen. Weitere Prüffragen zu Vertrag und Service Levels sammelt die Checkliste für die Auswahl eines Hosting-Anbieters.
Ausfallkosten berechnen: was eine Stunde Stillstand kostet
Welche Verfügbarkeit Sie brauchen, ist vor allem eine wirtschaftliche Frage: Was kostet Sie eine Stunde Stillstand? Ausfallkosten berechnen Sie, indem Sie die Ausfalldauer mit Ihrem Umsatzausfall und Ihren Personalkosten je Stunde multiplizieren und Folgekosten wie Vertragsstrafen addieren. Die Zahlen kommen aus Ihrem Unternehmen; allgemeingültige Beispielwerte gibt es nicht.
Ausfallkosten = Ausfalldauer in Stunden × (Umsatzausfall je Stunde + Personalkosten je Stunde) + Folgekosten
| Variable | Was hineingehört |
|---|---|
| Ausfalldauer | Erwartete Ausfallzeit im betrachteten Zeitraum, etwa pro Jahr aus der Tabelle oben. |
| Umsatzausfall je Stunde | Umsatz oder Deckungsbeitrag, der tatsächlich verloren geht; manche Kunden bestellen später erneut. |
| Personalkosten je Stunde | Arbeitszeit von Mitarbeitenden, die nicht arbeiten können oder nacharbeiten müssen. |
| Folgekosten | Vertragsstrafen, Datenwiederherstellung und Kundenkommunikation im selben Zeitraum. |
Den Wert einer höheren Verfügbarkeit zeigt der Abstand zweier Ziele. Zwischen 99,9 % und 99,99 % liegen 7,88 Stunden Ausfallzeit pro Jahr. Multipliziert mit Ihren Kosten je Ausfallstunde ergibt sich, was die zusätzliche Neun im Jahr wert ist; dem stehen die Mehrkosten für Redundanz gegenüber.
Eine Stunde Stillstand in der Nacht kostet oft weniger als zur Hauptgeschäftszeit. Rechnen Sie außerdem bis zum vollständigen Wiederanlauf, einschließlich Datenabgleich und Nacharbeit.
Woher Verfügbarkeit kommt: Reihe, Redundanz, Wiederanlauf
Die Verfügbarkeit eines IT-Systems entsteht durch Architektur, vor allem durch Redundanz. Jede Komponente, ohne die Ihre Anwendung nicht läuft, senkt die Gesamtverfügbarkeit; jede Komponente, die eine ausgefallene ersetzen kann, hebt sie. Daraus folgen zwei Rechenregeln, die das BSI für voneinander unabhängige Ausfälle beschreibt: eine für die Reihe, eine für die Redundanz.
In Reihe: die Kette ist schwächer als ihr schwächstes Glied
Müssen mehrere Komponenten gleichzeitig funktionieren, multiplizieren sich ihre Verfügbarkeiten: A = A1 × A2 × … × An. Zwei Komponenten mit je 99,9 % ergeben zusammen 99,8 %, also 17,5 Stunden Ausfall pro Jahr. Das BSI rechnet vor, dass eine Komponente mit 99,99 % in Reihe mit einer Komponente mit 99 % nur rund 98,99 % erreicht. Die Kette ist damit schwächer als ihr schwächstes Glied.
Redundant: Ein Gesamtausfall braucht mehrere Fehler zugleich
Genügt eine von mehreren Komponenten, fällt das Ganze nur aus, wenn alle gleichzeitig ausfallen. Dann multiplizieren sich die Ausfallwahrscheinlichkeiten: 1 − A = (1 − A1) × (1 − A2). Zwei Nodes mit je 99 % ergeben rechnerisch 99,99 %.
Schema als Text
- In Reihe: Komponente A und Komponente B müssen beide laufen, jede mit 99,9 %. Gesamt: 0,999 × 0,999 ergibt rund 0,998, also 99,8 % oder 17,5 Stunden Ausfall pro Jahr.
- Redundant: Node 1 und Node 2 haben je 99 %, einer von beiden genügt. Gesamt: 1 − 0,01 × 0,01 ergibt 0,9999, also 99,99 % oder 52,6 Minuten Ausfall pro Jahr.
- Beide Rechnungen setzen voraus, dass die Ausfälle voneinander unabhängig sind; die Redundanzrechnung unterstellt zusätzlich, dass die Umschaltung keine Zeit kostet.
Beide Regeln setzen unabhängige Ausfälle voraus, die Redundanzregel zusätzlich eine Umschaltung ohne Zeitverlust. In der Praxis kann ein gemeinsamer Stromkreis, ein fehlerhaftes Update oder eine Fehlbedienung redundante Komponenten gleichzeitig treffen; Redundanz muss deshalb jede Ebene erfassen, vom Netz bis zum Storage.
Was das für einen Proxmox-Cluster bedeutet
Das BSI nennt zwei Hebel für mehr Verfügbarkeit: die mittlere Zeit bis zum Ausfall verlängern (MTTF, Mean Time to Failure) und die mittlere Ausfalldauer verkürzen (MTTR, Mean Time to Repair). Die Verfügbarkeit ist das Verhältnis beider: A = MTTF ÷ (MTTF + MTTR).
Der HA Manager eines Proxmox-Clusters setzt am zweiten Hebel an, der Ausfalldauer. Fällt ein Node aus, startet der Proxmox HA Manager die betroffenen virtuellen Maschinen automatisch auf einem anderen Node neu. Dienste, die hinter dem Loadbalancer auf mehreren Nodes laufen, bleiben dabei erreichbar.
Der Loadbalancer nimmt einen ausgefallenen Node binnen Sekunden aus der Verteilung. Die virtuellen Maschinen des Nodes starten nach dem Fencing auf einem anderen Node neu; wie lange das dauert, hängt vom Fencing und von der Startzeit des Gastsystems ab.
Läuft Ihre Anwendung in einer einzigen virtuellen Maschine, zählt ein Ausfall des Nodes, auf dem sie gerade läuft, also als Ausfallzeit, bis Fencing und Neustart abgeschlossen sind. Wie Quorum, Fencing und HA Manager zusammenspielen, beschreibt die Seite High Availability Cluster; warum ein Cluster dafür mindestens drei Nodes oder ein externes Quorum-Device braucht, der Ratgeber Split-Brain, Quorum und Fencing.
Ein HA-Cluster ersetzt kein Backup.
Replikation überträgt auch versehentliche Löschungen, fehlerhafte Updates und verschlüsselte Daten auf alle Kopien. Wie schnell und mit welchem Datenstand Sie danach wieder arbeiten sollen, legen RTO und RPO fest, also Recovery Time Objective und Recovery Point Objective.
Unsere Zusage: Das Verfügbarkeitsziel steht im Betriebsvertrag
Pauschale Neunen versprechen wir nicht; das Ziel steht im Betriebsvertrag. Bei managed-cluster.net legen wir das Verfügbarkeitsziel für jeden Managed Cluster gemeinsam mit Ihnen fest, passend zu Ihrer Anwendung und zum Redundanzgrad der Architektur. Eine belastbare Grundlage dafür sind Ihre Ausfallkosten, also das, was Sie eine Stunde Stillstand kostet.
Neben dem Verfügbarkeitsziel regelt der Vertrag Reaktionszeiten nach Prioritätsstufen, Servicezeiten und Eskalationswege sowie die Wiederanlaufziele RTO und RPO. Eine Übersicht, was im Betriebsvertrag steht, finden Sie bei Betrieb & Monitoring. Kritische Alarme erreichen die Rufbereitschaft sofort und werden umgehend bearbeitet, rund um die Uhr.
- Nachweis: Zu jedem Managed Cluster gehört ein monatlicher Betriebsbericht mit Verfügbarkeit, Vorfällen und Auslastung. Das Business-Paket enthält zusätzlich SLA-Reports und erweitertes Monitoring mit Eskalation.
- Vorfälle: Zu jedem Vorfall erhalten Sie einen Nachbericht mit Ursache und abgeleiteten Maßnahmen.
- Tests: Vor der Inbetriebnahme testen wir den Failover vollständig, danach regelmäßig mit Protokoll, im mit Ihnen abgestimmten Rhythmus (Failover-Tests und Notfallpläne).
- Wartung: Updates spielen wir Node für Node im laufenden Betrieb ein. Ausnahmen wie das Major-Upgrade einer Datenbank kündigen wir an und legen sie in ein Zeitfenster, das Sie wählen.
So setzen wir das um
Hochverfügbarkeit im Managed Proxmox Cluster
Im Standard drei Nodes mit Quorum und Fencing gegen Split-Brain, 24/7-Monitoring mit Rufbereitschaft und in den Paketen Essentials und Business Ceph-Storage mit drei Repliken je Datenblock auf verschiedenen Nodes.
Redundanz je Ebene im High Availability Cluster