Was bedeutet N+1 Redundanz? 2N, 2N+1 und Tier Stufen erklärt

Was ist Redundanz im Rechenzentrum, und was bedeutet N+1?

Redundanz im Rechenzentrum bedeutet, mehr Komponenten zu installieren, als die Last eigentlich braucht, damit eine Reserve bei einem Ausfall übernimmt. Bei N+1 steht N für die Anzahl der Einheiten, die die volle Last tragen; die zusätzliche Einheit überbrückt einen einzelnen Ausfall oder eine geplante Wartung ohne Unterbrechung.

Der Begriff stammt aus der Gebäudetechnik. Allerdings finden Sie dieselbe Logik auch bei den Netzteilen eines Servers, bei einer Netzwerkanbindung und im Serverpool hinter einer Webanwendung. Wir, Talha Aslan und Team, begegnen dem Begriff regelmäßig, wenn wir mit Kunden über Hosting für Websites und Onlineshops sprechen.

In diesem Leitfaden erklären wir das Konzept verständlich. Außerdem grenzen wir es von verwandten Begriffen wie 2N und den Tier Stufen des Uptime Institute ab. Zudem zeigen wir, worauf Sie als Websitebetreiber in einem Hostingvertrag achten sollten. Für technische Definitionen stützen wir uns auf Primärquellen wie das Uptime Institute und die Dokumentation des Linux Kernels.

Wofür steht N, und wie berechnen Sie den Wert?

N ist die Mindestzahl an Einheiten, die die volle Last tragen kann. Eine Einheit kann zum Beispiel ein USV Modul, ein Generator, ein Kühlgerät oder ein Netzwerkgerät sein. Die Rechnung beginnt also immer mit dem Verhältnis zwischen Last und Kapazität einer einzelnen Einheit.

Beispielrechnung: Ein Serverraum hat eine kritische IT Last von 300 kW, und jedes USV Modul trägt 100 kW. Dann ist N gleich 3. Ein N+1 Aufbau stellt 4 Module in den Raum. Somit kann ein beliebiges Modul ausfallen, während die übrigen drei die Last weiter tragen.

Allerdings betrachtet diese Rechnung nur die Kapazität. Wächst die Last, wächst auch N. Ein System, das heute N+1 erfüllt, rutscht deshalb unbemerkt auf N ab, sobald neue Racks dazukommen. Behandeln Sie Redundanz daher nicht als einmalige Entscheidung, sondern als Wert, den Sie zusammen mit der Kapazitätsplanung verfolgen.

Ein weiteres Detail: Bei N+1 ist das Plus immer genau eine Einheit. In einem System mit zehn Modulen macht eine Reserve zum Beispiel nur einen kleinen Anteil aus. Fallen zwei Module gleichzeitig aus, fehlt Kapazität. Manche Konzepte nutzen deshalb N+2 oder ähnliche Stufen; die Logik bleibt gleich, nur die Zahl der Reserven steigt.

Worin unterscheiden sich N+1, 2N und 2N+1?

Alle drei beantworten dieselbe Frage auf unterschiedlichem Niveau: Was passiert, wenn ein Bauteil oder ein Versorgungsweg ausfällt? Zunächst ergänzt N+1 genau eine Reserveeinheit. 2N baut dagegen das gesamte System doppelt auf. Es gibt also zwei unabhängige Stränge, und jeder trägt allein die volle Last. 2N+1 ergänzt diesen doppelten Aufbau schließlich um eine weitere Reserveeinheit.

Beispielrechnung: Bei einer USV mit N gleich 3 brauchen Sie 4 Module für N+1, 6 für 2N und 7 für 2N+1. Das heißt, 2N bedeutet mehr Hardware, mehr Fläche und mehr Wartungsaufwand als N+1.

Andererseits verdoppelt 2N auch den Verteilungsweg und löst damit ein Problem, das N+1 offen lässt: den Ausfall eines gemeinsamen Pfads. Hängen alle vier Module eines N+1 Systems an derselben Verteilung, kann diese Verteilung trotzdem die gesamte Last stoppen. Bei 2N bleiben Strang A und Strang B getrennt, und die Server beziehen Strom aus beiden.

Was ist ein Single Point of Failure, und wie beseitigt Redundanz ihn?

Ein Single Point of Failure (SPOF) ist eine Komponente ohne Reserve, deren Ausfall das gesamte System stoppt. Sie haben zum Beispiel vier USV Module. Hängen aber alle an einer einzigen Verteilung, ist diese Verteilung der Single Point of Failure. Deshalb garantiert die Zahl der N+1 Komponenten allein noch keine unterbrechungsfreie Verfügbarkeit.

Typische Single Points of Failure bei einer Website sind:

• Eine einzige Stromverteilung oder ein einziger Umschalter.
• Ein Gebäude mit nur einer Glasfasertrasse oder nur einem Netzbetreiber.
• Eine Datenbank auf nur einem Server mit nur einer Festplatte.
• Alle DNS Einträge bei nur einem Anbieter oder auf nur einem Nameserver. Unser Beitrag zu Anycast DNS behandelt diese Ebene.
• Ein Passwort, das nur eine Person kennt, oder ein Umschaltschritt, den nur eine Person beherrscht.

In der Praxis hilft eine einfache Methode. Legen Sie den Finger auf jedes Kästchen im Systemdiagramm und fragen Sie: Lädt die Website noch, wenn dieses Kästchen morgen früh ausfällt? Lautet die Antwort nein, haben Sie einen Single Point of Failure gefunden. Danach ergänzen Sie entweder eine Reserve oder akzeptieren das Risiko bewusst.

Welche Komponenten schützt Redundanz im Rechenzentrum?

Das Uptime Institute nennt als redundante kritische Strom und Kühlkomponenten eines Tier II Standorts USV Module, Kältemaschinen oder Pumpen sowie Generatoren. In der Praxis begegnet Ihnen N+1 Redundanz im Rechenzentrum vor allem in diesen Bereichen:

• Module der unterbrechungsfreien Stromversorgung (USV) und ihre Batterien.
• Generatoren und die Ausrüstung für die Kraftstoffversorgung.
• Kühlgeräte, Kältemaschinen, Pumpen und Lüfter.
• Stromverteiler, einschließlich der PDUs in jedem Rack.
• Router, Switches und Anbindungen verschiedener Netzbetreiber auf der Netzwerkseite.

Jede Ebene hat ihr eigenes N. Folglich kann ein Standort bei der USV nach N+1 und bei der Kühlung nach 2N aufgebaut sein. Steht auf der Seite eines Anbieters nur „N+1 Infrastruktur", fragen Sie nach, welche Ebene gemeint ist. Denn das schwächste Glied der Kette bestimmt die tatsächliche Ausfallsicherheit.

Die Netzwerkebene verdient zudem besondere Aufmerksamkeit. Selbst ein perfekt redundantes Gebäude verliert die Verbindung zum Internet, wenn nur ein Netzbetreiber es anbindet. Unser Leitfaden zu AS Nummern und BGP erklärt, wie Anbindungen über mehrere Netzbetreiber funktionieren.

Wie funktioniert Redundanz in der Stromversorgung: Netz, USV und Generator?

Die Stromkette verläuft meist in dieser Reihenfolge: Netzeinspeisung, Umschalter, USV, Verteilung und schließlich das Netzteil des Servers. Fällt das öffentliche Netz aus, übernehmen die USV Batterien sofort. Sie überbrücken die Zeit, bis der Generator anläuft. Danach trägt der Generator die Last auf Dauer.

In seinem Beitrag über verbreitete Irrtümer zu den Tiers schreibt das Uptime Institute, dass die Generatoranlage die einzige verlässliche Stromquelle eines Rechenzentrums ist, weil das öffentliche Netz ungeplanten Unterbrechungen unterliegt. Laut demselben Beitrag verlangt das Tier System allerdings nicht, dass die Generatoren ständig laufen. Stattdessen muss die Anlage die kritische Last ohne Laufzeitbegrenzung tragen können.

Auf der Stromseite zählt die Frage nach N+1 also an zwei Stellen: bei der Zahl der USV Module und bei der Zahl der Generatoren. Kann zum Beispiel jeder von zwei Generatoren die Last allein tragen, bleibt einer in Wartung, während der andere weiterarbeitet.

Gibt es dennoch nur einen Kraftstofftank, eine Kraftstoffpumpe oder einen Umschalter, stehen selbst redundante Generatoren hinter einem Single Point of Failure. Kurz gesagt: Sie bewerten Redundanz in der Stromversorgung anhand des gesamten Wegs vom Netz bis zum Server, nicht anhand der Zahl der Maschinen.

Warum ist N+1 auch bei der Kühlung wichtig?

Server wandeln den Großteil ihres Stroms in Wärme um. Fällt die Kühlung aus, steigt die Raumtemperatur schnell, und die Hardware schaltet sich zum Selbstschutz unter Umständen ab. Anders gesagt: Ein Kühlungsausfall kann zum echten Ausfall werden, obwohl der Strom weiter fließt. Deshalb planen Fachleute auch Kühlgeräte, Pumpen und Lüfter mit N+1 oder höher.

Konkret sollten Sie auf die Anordnung achten. In einem System, das auf dem Papier N+1 erfüllt, kühlt ein Reservegerät in einer entfernten Ecke den Bereich des defekten Geräts unter Umständen nicht ausreichend. Außerdem braucht auch die Stromversorgung der Kühlgeräte Redundanz. Sonst stoppt ein einzelner Fehler auf der Stromseite beide Systeme gleichzeitig.

Als Websitebetreiber können Sie diese Details nicht selbst prüfen. Sie können aber im Angebotsgespräch fragen: Wie viele Kühlgeräte gibt es, und wie viele davon sind Reserve? Eine vage Antwort ist ebenfalls eine Information. Transparente Anbieter beantworten diese Frage in der Regel ohne Zögern.

Wie hängen die Tier Stufen des Uptime Institute mit Redundanz im Rechenzentrum zusammen?

Das Tier Klassifizierungssystem des Uptime Institute beschreibt die Infrastruktur von Rechenzentren in vier Stufen, und jede Stufe umfasst die Anforderungen der darunterliegenden. Laut der offiziellen Erläuterung des Instituts sehen die Stufen so aus:

Wie die Tabelle zeigt, konzentriert sich Tier II auf redundante Komponenten, Tier III dagegen auf redundante Versorgungswege. Tier IV ergänzt dann die Fehlertoleranz. Somit adressiert jede Stufe einen Single Point of Failure, den die Stufe darunter offen lässt.

Behalten Sie außerdem einen Punkt im Blick. Das Tier System bewertet die physische Anlage. Der Code Ihrer Website, die Datenbankeinstellungen und Ihr Updateprozess liegen außerhalb dieser Bewertung. Daher kann eine Website mit nur einem Server selbst in einem Tier IV Gebäude ausfallen, wenn dieser Server oder seine Software streikt. Wer Anlage und Anwendung getrennt betrachtet, behält realistische Erwartungen.

Warum ist eine Tier Stufe nicht dasselbe wie die Zahl der Komponenten?

Eine verbreitete Annahme lautet: N+1 entspricht Tier III, und 2N entspricht Tier IV. Das Uptime Institute widerspricht. Laut dem Institut bestimmt oder garantiert eine höhere Zahl an Komponenten keine bestimmte Tier Stufe, denn die Bewertung umfasst auch Verteilungswege und weitere Systemelemente.

Dieselbe Quelle ergänzt, dass ein Standort je nach Anbindung an redundante Wege sogar mit reinen N+1 Komponenten Tier IV erreichen kann. Zudem betont das Uptime Institute, dass der Tier Standard keine bestimmte Technologie, kein Schema und keine Designkriterien vorschreibt. Er definiert Ergebnisse.

Ein Anbieter, der „2N Infrastruktur" verspricht, und ein Standort mit Tier Zertifizierung sind folglich zwei verschiedene Aussagen. Achten Sie außerdem auf die Wortwahl. Formulierungen wie „Tier III konform" oder „nach Tier III Standard gebaut" bedeuten nicht unbedingt eine unabhängige Zertifizierung.

Laut dem Institut ist selbst eine Designzertifizierung nur vorläufig, bis die gebaute Anlage ihre eigene Zertifizierung erhält. Wenn Sie Gewissheit wollen, fragen Sie den Anbieter nach der Art des Zertifikats und dem Namen des Standorts. So trennen Sie Marketingsprache von einer geprüften Aussage.

Wie viel Ausfallzeit pro Jahr bedeutet welcher Verfügbarkeitswert?

Einen Verfügbarkeitswert in Ausfallzeit umzurechnen, ist einfache Mathematik. Ein Jahr hat 365 Tage, also 8.760 Stunden. Bei 99,9 % Verfügbarkeit erlauben die restlichen 0,1 % somit 8,76 Stunden Ausfall pro Jahr. Die folgende Tabelle zeigt dieselbe Rechnung für einige gängige Werte.

Beispielrechnung: Wir haben mit einem Jahr von 365 Tagen und einem Monat von 30 Tagen gerechnet und die Ergebnisse gerundet.

Ein wichtiger Hinweis: Das Uptime Institute erklärt, dass es 2009 alle Angaben zur erwarteten jährlichen Ausfallzeit aus dem Tier Standard gestrichen hat. Laut dem Institut ordnet der aktuelle Standard den Tier Stufen keine Verfügbarkeitsprognosen zu. Prozentwerte, die Sie online neben Tier Stufen sehen, sind deshalb inoffizielle Schätzungen und keine offiziellen Definitionen.

Wie stark erhöht parallele Redundanz die Verfügbarkeit?

Beispielrechnung: Nehmen Sie zwei unabhängige Netzteile, die jeweils zu 99 % der Zeit funktionieren. Das System fällt nur aus, wenn beide gleichzeitig ausfallen. Die Wahrscheinlichkeit dafür beträgt 0,01 × 0,01, also 0,0001. Somit steigt die Verfügbarkeit theoretisch auf 99,99 %.

Allerdings beruht diese Rechnung auf einer entscheidenden Annahme: Unabhängigkeit. Hängen beide Netzteile in der Realität an derselben Verteilung, kommen die Ausfälle gemeinsam. Auch derselbe Firmwarefehler, dieselbe Produktionscharge oder derselbe Wartungsfehler kann beide Einheiten treffen. Fachleute sprechen dann von einem Ausfall mit gemeinsamer Ursache.

Bei Komponenten in Reihe kehrt sich das Bild um. Beispielrechnung: Hängt ein App Server mit 99,9 % Verfügbarkeit von einer Datenbank mit 99,9 % ab, ergibt sich die Gesamtverfügbarkeit aus dem Produkt beider Werte, also rund 99,8 %.

Jedes Glied ohne Reserve zieht die Gesamtverfügbarkeit folglich nach unten. Denken Sie Redundanz deshalb über die ganze Kette und nicht nur in einer Ebene. Parallele Strukturen erhöhen die Verfügbarkeit, serielle senken sie; gute Architektur bringt beides ins Gleichgewicht.

Redundanz auf Serverebene: doppelte Netzteile, RAID und zwei Netzwerkkarten

Auch in einem redundanten Rechenzentrum kann der Server selbst ein Single Point of Failure sein. Deshalb finden Sie bei Enterprise Servern häufig drei Schutzmaßnahmen:

• Doppelte Netzteile (PSU): Der Server hat zwei Netzteile, und jedes kann ihn allein versorgen. Für den echten Nutzen schließen Sie beide an verschiedene PDUs an, idealerweise an verschiedene Stromstränge.
• RAID: Es hält Daten verfügbar, wenn einzelne Festplatten ausfallen. RAID 1, 5, 6 und 10 bieten unterschiedlich starken Schutz, RAID 0 bietet dagegen keine Redundanz. Details finden Sie in unserem Leitfaden zu RAID Leveln.
• Zwei Netzwerkkarten mit Bonding: Zwei Netzwerkschnittstellen arbeiten als eine logische Schnittstelle. Fällt eine Verbindung aus, wechselt der Verkehr auf die andere.

Diese Maßnahmen schützen vor Ausfällen innerhalb des Servers. Trotzdem stoppt ein Defekt an Mainboard, Prozessor oder Betriebssystem die Maschine. Egal wie viele redundante Teile ein einzelner Server hat, für den Server selbst brauchen Sie also einen zweiten Server.

Berücksichtigen Sie das auch bei der Wahl zwischen einem Dedicated Server und einem VPS oder Cloud Server. Auf Cloud Plattformen bleibt die Hardwareebene für Sie unsichtbar. Dort bestimmen die Architektur des Anbieters und Ihr eigenes Anwendungsdesign, wie redundant Sie tatsächlich aufgestellt sind.

Wie prüfen Sie redundante Komponenten auf einem Linux Server?

Verwalten Sie Ihren eigenen VPS oder physischen Server, helfen Ihnen zwei Kernel Schnittstellen beim Auslesen des Zustands. Laut der Bonding Dokumentation des Linux Kernels besitzt jedes Bonding Gerät eine schreibgeschützte Datei im Verzeichnis /proc/net/bonding. Diese Datei zeigt die Konfiguration und den Zustand jeder untergeordneten Schnittstelle:

cat /proc/net/bonding/bond0

Laut derselben Dokumentation ist im Modus active-backup nur eine Schnittstelle aktiv; fällt sie aus, übernimmt eine andere. Bei Software RAID zeigt das in der md Dokumentation des Kernels beschriebene Attribut degraded, wie viele Geräte dem Array fehlen. Ein gesundes Array zeigt 0, bei einer ausgefallenen Festplatte steht dort 1:

cat /sys/block/md0/md/degraded

Die Gerätenamen können auf Ihrem System abweichen; bond0 und md0 sind nur Beispiele. Entscheidend ist, dass Sie diese Werte regelmäßig überwachen. Bleibt eine Festplatte in einem redundanten Array monatelang defekt, ist Ihr System unbemerkt auf N gefallen.

Hardwaredetails wie der Zustand doppelter Netzteile stammen dagegen aus herstellerspezifischen Verwaltungsschnittstellen. Dafür lesen Sie die Dokumentation Ihres Serverherstellers, und ein unbekanntes Werkzeug testen Sie nie zuerst auf einem Produktivserver.

Warum ist Redundanz kein Backup?

Redundanz hält den Betrieb am Laufen; ein Backup bringt Sie in der Zeit zurück. Löschen Sie auf einem Server mit RAID 1 versehentlich eine Tabelle, schreibt das System diese Löschung auf beide Festplatten gleichzeitig. Dasselbe gilt ebenso für Ransomware, ein fehlerhaftes Plugin Update oder eine misslungene Datenbankmigration. Ein redundantes System speichert also auch den Fehler redundant.

Ersetzen Sie deshalb das eine nie durch das andere. Ein guter Plan enthält beides:

• Redundanz: Sie hält den Dienst bei Hardwareausfällen am Laufen und bringt die Ausfallzeit nahe an null.
• Backup: Es stellt Daten auf einen früheren Stand zurück und schützt vor menschlichen Fehlern und Schadsoftware.
• Räumliche Trennung: Backups an einem anderen Ort schützen die Daten bei einem Ausfall des gesamten Standorts.

Die Backupseite beschreiben wir in unserem Beitrag zur Backup Strategie für Websites. Speziell für Datenbanken führt Sie unser Leitfaden zu mysqldump und pg_dump Schritt für Schritt durch den Ablauf.

Worauf sollten Websitebetreiber im SLA des Hosters achten?

Ein Service Level Agreement (SLA) legt die Verfügbarkeitszusage des Anbieters fest und regelt, was Sie erhalten, wenn er sie verfehlt. Aussagen zur Redundanz im Rechenzentrum stehen in Werbetexten; verbindlich ist dagegen das SLA. Achten Sie bei der Prüfung vor allem auf diese Punkte:

1. Verfügbarkeitswert und Messzeitraum: monatlich oder jährlich?
2. Definition des Ausfalls: nur ein kompletter Ausfall oder auch starke Verlangsamung?
3. Geplante Wartung: Nimmt der Anbieter Wartungsfenster aus der Berechnung heraus?
4. Entschädigung: meist in Form von Gutschriften; prüfen Sie die Obergrenze dieser Gutschriften.
5. Antragsverfahren: Innerhalb wie vieler Tage müssen Sie eine Gutschrift beantragen?
6. Geltungsbereich: Deckt das SLA das Netzwerk, den Server oder Ihre Anwendung ab?

Zusammen mit der Tabelle oben zeigt sich dann die eigentliche Bedeutung des SLA. Eine monatliche Zusage von 99,9 % heißt, dass rund 43 Minuten Ausfall im Monat noch vertragsgemäß sind. Trifft dieses Zeitfenster bei einem Onlineshop einen Aktionsabend, kann der Verlust die Gutschrift weit übersteigen. Kurz gesagt: Ein SLA ist keine Versicherung, sondern das Ziel, das sich der Anbieter selbst setzt.

Wie überprüfen Sie Aussagen eines Hosters zur Redundanz?

Auf Hostingseiten stehen oft Formulierungen wie „N+1 Stromversorgung", „redundantes Netzwerk" oder „Tier III Rechenzentrum". Für die Prüfung brauchen Sie kein Technikteam. Stattdessen genügen die richtigen Fragen:

• Welche Ebene ist redundant: USV, Generatoren, Kühlung, Netzwerk oder alles?
• Hat der Standort eine Tier Zertifizierung, und gilt sie für das Design oder für die gebaute Anlage?
• Wie viele Netzbetreiber binden den Standort an, und verlaufen die Glasfasertrassen auf getrennten Wegen?
• Hat mein Server doppelte Netzteile, und hängen sie an verschiedenen Stromsträngen?
• Verschiebt der Anbieter meine virtuelle Maschine automatisch auf einen anderen Host, wenn die Hardware ausfällt?

Zusammen mit den Kriterien aus unserem Leitfaden zur Wahl des Webhostings ergeben diese Fragen eine solide Checkliste. Wie sich Redundanz auf den Preis auswirkt, erklären wir zudem in unserem Beitrag zu den Faktoren der Serverkosten.

In einem weiteren Beitrag dieser Reihe vergleichen wir kurz Hoster mit eigenem Rechenzentrum und Hoster, die Fläche in fremden Anlagen mieten. Dieser Unterschied entscheidet auch darüber, wer Ihre Fragen zur Redundanz direkt beantworten kann.

Redundanz auf Anwendungsebene: Lastverteilung, DNS und Replikation

Redundanz im Rechenzentrum endet allerdings an den Mauern des Gebäudes. Echte Kontinuität für Ihre Website entsteht erst, wenn die Anwendung auf mehr als einem Server läuft. Ein Load Balancer verteilt eingehende Anfragen auf mehrere App Server und nimmt jeden Server aus dem Pool, der den Health Check nicht besteht. Folglich bemerken Ihre Besucher den Absturz eines einzelnen Servers nicht.

Bleibt kein gesunder Server im Pool, sehen Besucher dagegen meist eine Fehlerseite. Diesen Fall behandeln wir in unserem Beitrag zum 500 Internal Server Error und seinen Ursachen.

Bei Datenbanken übernimmt Replikation eine ähnliche Rolle: Sie kopieren die Daten des primären Servers auf ein oder mehrere Replikate. Allerdings ersetzt auch Replikation kein Backup, denn sie überträgt einen Löschbefehl ebenfalls auf die Replikate. Auf der DNS Seite schützen mehrere Nameserver vor dem Ausfall eines einzelnen DNS Endpunkts.

Zum Beispiel bringt diese Architektur im Vergleich zu einer Website mit nur einem Server deutlich mehr Komplexität. Sitzungsverwaltung, gemeinsamer Speicher für Uploads und der Deploymentprozess ändern sich. Für eine kleine Unternehmenswebsite ist sie daher oft unnötig. Bei Onlineshops mit viel Verkehr und bei SaaS Produkten ist sie dagegen eine ernsthafte Option.

Wann sollten Sie Redundanz Ihrem Hostinganbieter überlassen?

Redundanz auf Standortebene liegt vollständig beim Anbieter; auf USV, Generatoren und Kühlung haben Sie keinen Einfluss. Ihre Aufgabe ist es also, den richtigen Anbieter zu wählen und das SLA zu lesen. Auf Serverebene hängt die Verantwortung von der Art des Dienstes ab:

• Bei Shared Hosting sind RAID, Bonding und Netzteile nicht Ihr Bereich. Überlassen Sie das dem Anbieter.
• Bei einem Managed VPS oder Managed Server übernimmt der Anbieter Überwachung und Hardwaretausch. Sie verfolgen nur die Warnmeldungen.
• Bei einem unverwalteten physischen Server liegen RAID und Netzwerkkonfiguration bei Ihnen. Ohne Erfahrung probieren Sie das nicht zum ersten Mal im Produktivbetrieb aus.
• Eine Anwendungsarchitektur mit mehreren Servern verlangt Software und Betriebswissen. An diesem Punkt ist die Zusammenarbeit mit einem erfahrenen Entwicklungsteam der sicherere Weg.

Bedenken Sie zudem: Eine falsche Bonding Einstellung kann Sie vom Fernzugriff auf den Server aussperren. Nehmen Sie eine solche Änderung nie ohne Konsolenzugang oder ohne vorherige Absprache mit dem Support Ihres Anbieters vor. Wenn Sie die Infrastruktur Ihrer Website mit uns planen möchten, besprechen wir diese Entscheidungen im Rahmen unseres Webdesign Angebots.

Welches Maß an Redundanz im Rechenzentrum braucht Ihre Website?

Das richtige Maß hängt davon ab, was Sie ein Ausfall kostet. Der folgende Rahmen ist ein Startpunkt auf Basis unserer Praxiserfahrung, keine Garantie:

Schließlich brauchen Sie einen Weg, Ausfälle zu bemerken. Für eine schnelle Prüfung zeigt Ihnen unser Tool zur Prüfung, ob eine Seite down ist, ob Ihre Website antwortet. Dauerhaft hilft dagegen ein Überwachungsdienst, der jede Minute prüft. Denn Redundanz im Rechenzentrum nützt nur, wenn Sie das defekte Teil rechtzeitig bemerken.