Was ist Server-Clustering? Architektur, Typen und reale Implementierung

Server-Clustering ist die Praxis, mehrere physische oder virtuelle Server – sogenannte Nodes – miteinander zu verbinden, sodass sie als ein einziges, einheitliches System arbeiten. Diese Architektur ermöglicht Lastverteilung, automatisches Failover und horizontale Skalierbarkeit, sodass Anwendungen auch dann verfügbar bleiben, wenn einzelne Hardware- oder Softwarekomponenten ausfallen. In einem ordnungsgemäß konfigurierten Cluster stellt kein einzelner Node einen Single Point of Failure dar – dies ist das grundlegende Prinzip, das geclusterte Infrastruktur von eigenständigen Server-Deployments unterscheidet.

Für jede Arbeitslast, bei der Ausfallzeiten direkt zu Umsatzverlusten, regulatorischen Risiken oder Datenbeschädigungsrisiken führen, ist Server-Clustering keine Option – es ist die grundlegende Architekturanforderung.

Wie Server-Clustering auf Architekturebene funktioniert

Im Kern basiert ein Cluster auf drei voneinander abhängigen Schichten: Compute-Nodes, gemeinsam genutztem oder repliziertem Storage und Cluster-Management-Software. Diese Schichten müssen gemeinsam entworfen und abgestimmt werden; eine Fehlkonfiguration in einer davon untergräbt die Garantien, die die anderen zu bieten versuchen.

Nodes

Jeder Node ist ein vollständiger Server – physisch oder virtuell – der in der Lage ist, die Zielarbeitslast unabhängig auszuführen. Nodes kommunizieren über einen dedizierten privaten Interconnect (üblicherweise eine separate NIC oder ein gebundenes Paar), der ausschließlich für Heartbeat-Signale und internen Cluster-Traffic verwendet wird. Dieses Netzwerk ist vom öffentlich zugänglichen Netzwerk getrennt, das Endbenutzeranfragen bedient.

Der Heartbeat ist der Puls des Clusters. Nodes tauschen Signale in konfigurierbaren Intervallen aus (typischerweise alle 1–2 Sekunden). Wenn ein Node eine definierte Anzahl aufeinanderfolgender Heartbeats verpasst, erklärt der Cluster-Manager ihn für tot und leitet ein Failover ein. Ein kritischer Grenzfall ist das Split-Brain-Szenario: Wenn das Heartbeat-Netzwerk selbst ausfällt, können beide Nodes glauben, der andere sei tot, und gleichzeitig versuchen, die Eigentümerschaft gemeinsamer Ressourcen zu übernehmen, was zu Datenbeschädigung führt. Die Verhinderung von Split-Brain erfordert einen Quorum-Mechanismus – eine Tiebreaker-Ressource wie einen dedizierten Quorum-Disk, einen Witness-Server oder einen cloudbasierten Arbitration-Service.

Gemeinsam genutzter und replizierter Storage

Die Storage-Architektur variiert je nach Cluster-Typ erheblich:

• Shared-Disk-Cluster verwenden ein SAN (Storage Area Network) oder NAS (Network-Attached Storage)-Gerät, das alle Nodes gleichzeitig einbinden. Der Cluster-Manager verwendet SCSI-Reservierungen oder Distributed Lock Manager (DLM), um gleichzeitige Schreibvorgänge zu verhindern, die Daten beschädigen würden.
• Shared-Nothing-Cluster replizieren Daten zwischen Nodes auf Block- oder Anwendungsebene (z. B. DRBD für Linux, SQL Server Always On Availability Groups). Jeder Node besitzt seinen lokalen Storage; die Replikation hält sie synchronisiert.
• Hybride Architekturen kombinieren beides und verwenden gemeinsam genutzten Storage für primäre Daten und Replikation für die Disaster Recovery an einem geografisch getrennten Standort.

Cluster-Management-Software

Der Cluster-Manager ist für die Ressourcenorchestrierung, Gesundheitsüberwachung und automatisches Failover verantwortlich. Weit verbreitete Lösungen umfassen:

• Pacemaker + Corosync – der De-facto-Standard unter Linux (RHEL, CentOS, Ubuntu)
• Windows Server Failover Clustering (WSFC) – nativ in Windows Server-Umgebungen
• Kubernetes – Container-natives Clustering mit Pod-Scheduling, Self-Healing und Rolling Updates
• VMware vSphere HA / vSAN – Clustering auf Hypervisor-Ebene für virtualisierte Workloads

Jede Lösung bietet unterschiedliche Primitiven zur Definition von Ressourcen, Constraints und Failover-Richtlinien. Eine Ressource in Pacemaker ist beispielsweise jeder Dienst, den der Cluster verwaltet – eine IP-Adresse, ein Filesystem-Mount, ein Datenbank-Daemon – und Constraints definieren die Reihenfolge und Kolokationsregeln für diese Ressourcen.

Kernvorteile von Server-Clustering

Hochverfügbarkeit und automatisches Failover

Der primäre Treiber für die meisten Cluster-Deployments ist Hochverfügbarkeit (HA). Wenn ein Node ausfällt, erkennt der Cluster-Manager den Ausfall durch verpasste Heartbeats und verlagert dann die betroffenen Ressourcen auf einen überlebenden Node – ein Prozess namens Failover. Moderne Cluster-Software kann dies für die meisten Workloads in unter 30 Sekunden abschließen, obwohl die Wiederherstellung auf Datenbankebene (Crash-Recovery, Log-Replay) zusätzliche Zeit hinzufügt, die von der Arbeitslast abhängt.

Recovery Time Objective (RTO) und Recovery Point Objective (RPO) sind die zwei Metriken, die die HA-Qualität definieren:

• RTO – wie lange der Dienst während des Failovers nicht verfügbar ist
• RPO – wie viele Daten verloren gehen können (gemessen in Zeit), wenn der primäre Node ausfällt, bevor die Replikation abgeschlossen ist

Synchrone Replikation erreicht RPO = 0, führt jedoch zu Schreiblatenz, da der primäre Node warten muss, bis das Replikat jeden Schreibvorgang bestätigt. Asynchrone Replikation reduziert die Latenz, akzeptiert jedoch einen RPO ungleich null. Die Wahl zwischen beiden ist eine geschäftliche Entscheidung, keine rein technische.

Load Balancing und horizontale Skalierbarkeit

Load-Balancing-Cluster verteilen eingehende Anfragen mithilfe von Algorithmen wie Round-Robin, Least-Connections, IP-Hash oder gewichteter Verteilung auf Nodes. Der Load Balancer selbst – ob Hardware (F5, Citrix ADC) oder Software (HAProxy, NGINX, LVS) – sitzt vor dem Cluster und muss redundant sein, um zu vermeiden, dass er zu einem Single Point of Failure wird.

Horizontale Skalierung in einem Cluster bedeutet das Hinzufügen von Nodes anstatt das Aufrüsten einzelner Server-Hardware (vertikale Skalierung). Dies ist wirtschaftlich bedeutsam: Commodity-Hardware-Nodes sind günstiger pro Recheneinheit als hochwertige monolithische Server, und der Cluster abstrahiert die zugrunde liegende Hardware von der Anwendung.

Fehlertoleranz und Redundanz

Fehlertoleranz geht über Node-Redundanz hinaus. Ein produktionsreifes Cluster-Design berücksichtigt:

• Doppelte Netzteile an jedem Node, die mit separaten PDUs und USV-Einheiten verbunden sind
• Redundante Netzwerkpfade (NIC-Bonding oder LACP-Trunking zu separaten Switches)
• Multipath I/O (MPIO) für Storage-Konnektivität, um einzelne HBA- oder Kabelausfälle zu eliminieren
• Geografische Verteilung über Availability Zones oder Rechenzentren hinweg zum Schutz vor standortweiten Ausfällen

Das Ignorieren einer dieser Schichten schafft versteckte Single Points of Failure, für die die Cluster-Software nicht kompensieren kann.

Vereinfachte Rolling-Wartung

Ein operativ unterschätzter Vorteil ist die wartungsfreie Betriebszeit. Ein Node kann ordnungsgemäß evakuiert werden – seine Ressourcen werden auf Peers migriert –, gepatcht, neu gestartet und ohne Serviceunterbrechung in den Cluster zurückgeführt werden. Dies wird als geplantes Failover oder Live-Migration in virtualisierten Umgebungen bezeichnet. Es verwandelt OS-Patching und Hardware-Austausch von geplanten Wartungsfenstern in routinemäßige, nicht störende Vorgänge.

Arten von Server-Clustern

Hochverfügbarkeits-Cluster

HA-Cluster sind das häufigste Enterprise-Deployment. Ein Zwei-Node-Aktiv-Passiv-HA-Cluster führt die Arbeitslast auf dem primären Node aus, während der sekundäre Node im Standby bleibt und kontinuierlich synchronisiert wird. Eine Aktiv-Aktiv-Variante führt die Arbeitslast auf allen Nodes gleichzeitig aus, was den Durchsatz erhöht, aber erfordert, dass die Anwendung gleichzeitigen Multi-Node-Zugriff unterstützt – nicht alle Datenbanken oder Legacy-Anwendungen tun dies.

Load-Balancing-Cluster

Diese Cluster sind von Natur aus Aktiv-Aktiv. Der Load Balancer verteilt Sitzungen auf einen Pool von Anwendungsservern. Sitzungspersistenz (Sticky Sessions) ist eine häufige Anforderung für zustandsbehaftete Anwendungen: Der Load Balancer muss die Anfragen eines bestimmten Clients während einer Sitzung an denselben Backend-Node weiterleiten. Dies schafft eine implizite Abhängigkeit, die das Entfernen von Nodes und Failover erschwert, weshalb zustandsloses Anwendungsdesign in modernen Architekturen stark bevorzugt wird.

Failover-Cluster

Failover-Cluster priorisieren Wiederherstellungsgeschwindigkeit und Datenintegrität gegenüber reiner Leistung. Sie sind die Standardarchitektur für SQL Server-, Oracle RAC- und SAP HANA-Deployments. Die zentrale technische Herausforderung besteht darin, sicherzustellen, dass das Failover-Ziel zum Zeitpunkt des Ausfalls eine konsistente, aktuelle Kopie aller Daten hat – weshalb synchrone Replikation und Quorum-Design in diesen Umgebungen unverzichtbar sind.

Storage-Cluster

Verteilte Storage-Systeme wie Ceph, GlusterFS und MinIO bilden ihre eigene Cluster-Schicht, unabhängig vom darüber liegenden Compute-Cluster. Ceph verwendet beispielsweise einen CRUSH-Algorithmus, um Daten ohne einen zentralen Metadaten-Engpass auf OSDs (Object Storage Daemons) zu verteilen. Storage-Cluster stellen das persistente Volume-Backend für Kubernetes-Workloads und die gemeinsam genutzte Storage-Schicht für HA-Compute-Cluster bereit.

Compute- und HPC-Cluster

High-Performance-Computing-Cluster verwenden Job-Scheduler (SLURM, PBS, LSF), um Nodes für Berechnungsaufgaben zuzuweisen. Nodes sind über InfiniBand oder Hochgeschwindigkeits-Ethernet verbunden, um die latenzarme, hochbandbreitige MPI (Message Passing Interface)-Kommunikation zu unterstützen, die parallele wissenschaftliche Workloads erfordern. Für GPU-beschleunigte Workloads – Deep-Learning-Training, Molekulardynamik, Computational Fluid Dynamics – ist die GPU-Hosting-Infrastruktur mit NVLink- oder NVSwitch-Interconnects die relevante Architektur.

Überlegungen zur realen Implementierung

Netzwerkdesign

Das Cluster-Netzwerk ist kein einzelnes Netzwerk. Ein ordnungsgemäß entworfener Cluster hat mindestens drei separate Netzwerksegmente:

1. Öffentliches Netzwerk – clientseitiger Traffic
2. Privater Cluster-Interconnect – Heartbeat und interne Cluster-Kommunikation
3. Storage-Netzwerk – iSCSI-, NFS- oder Fibre-Channel-Traffic zum gemeinsam genutzten Storage-Backend

Das Mischen dieser auf einer einzigen NIC oder einem VLAN führt zu Konflikten und schafft Szenarien, in denen Storage-I/O-Sättigung Heartbeat-Signale stört und falsche Failovers auslöst.

Fencing und STONITH

STONITH (Shoot The Other Node In The Head) ist der Mechanismus, durch den ein Cluster einen Node, von dem er glaubt, dass er ausgefallen ist, zwangsweise ausschaltet oder zurücksetzt. Ohne Fencing kann ein Node, der nicht mehr reagiert, aber nicht vollständig tot ist, weiterhin auf gemeinsam genutzten Storage schreiben, während der Cluster bereits ein Failover durchgeführt hat – ein garantierter Weg zur Datenbeschädigung. STONITH-Implementierungen umfassen IPMI/iDRAC-basierte Stromsteuerung, PDU-Switching und hypervisorbasiertes erzwungenes Ausschalten. Jeder HA-Cluster ohne eine funktionierende Fencing-Konfiguration ist nicht wirklich HA.

Clustering auf Anwendungsebene vs. Clustering auf Infrastrukturebene

Eine kritische Unterscheidung, die häufig übersehen wird: Infrastruktur-Clustering (Pacemaker, WSFC) bietet Failover auf Node-Ebene, aber die Anwendung muss auch so konzipiert sein, dass sie abrupte Neustarts toleriert. Datenbanken erfordern Crash-Recovery; Anwendungsserver müssen möglicherweise Verbindungen zu Backends neu herstellen; Caches können nach einem Failover kalt sein. Clustering auf Anwendungsebene – wie Datenbankreplikationsgruppen, Elasticsearch-Cluster oder Kafka-Broker-Cluster – behandelt Datenkonsistenz und Verfügbarkeit auf der Datenschicht, unabhängig von der darunter liegenden Infrastruktur. Produktionsumgebungen stapeln typischerweise beides: Infrastruktur-HA für die Compute-Schicht und Replikation auf Anwendungsebene für die Datenschicht.

Latenz zwischen Nodes

Bei synchroner Replikation wirkt sich die Inter-Node-Latenz direkt auf die Schreibleistung aus. Ein synchroner Commit erfordert einen Round-Trip zum Replikat, bevor der Schreibvorgang dem Client bestätigt wird. Bei 1 ms Inter-Node-Latenz beträgt der theoretische maximale synchrone Schreibdurchsatz 1.000 Operationen pro Sekunde pro Thread – unabhängig davon, wie schnell der lokale Disk ist. Deshalb sind geografisch verteilte synchrone Cluster über ~100 km zwischen Standorten hinaus unpraktisch, und deshalb wird asynchrone Replikation für regionsübergreifende Disaster Recovery verwendet.

Wann Server-Clustering die richtige Wahl ist

Server-Clustering ist angemessen, wenn die Kosten für Ausfallzeiten oder Datenverlust die Kosten der Clustering-Infrastruktur übersteigen. Spezifische Indikatoren:

• Die Anwendung hat ein SLA, das eine Verfügbarkeit von 99,9 % oder höher erfordert (weniger als 8,7 Stunden Ausfallzeit pro Jahr)
• Die Arbeitslast kann nicht für Patching, Hardware-Austausch oder Kapazitätsänderungen unterbrochen werden
• Traffic-Muster sind unvorhersehbar oder sprunghaft und erfordern elastische horizontale Skalierung
• Regulatorische Anforderungen schreiben Datenredundanz und Auditierbarkeit vor (PCI-DSS, HIPAA, SOC 2)
• Die Anwendung verarbeitet Finanztransaktionen, medizinische Aufzeichnungen oder Echtzeit-Kommunikation, bei denen Datenverlust rechtliche Konsequenzen hat

Für kleinere Workloads, die diese Kriterien nicht erfüllen, kann eine gut konfigurierte VPS-Hosting-Umgebung mit automatisierten Backups und Monitoring ausreichende Resilienz zu einem Bruchteil der Kosten bieten.

Herausforderungen und häufige Fehlermodi

Kosten und Infrastruktur-Overhead

Ein minimal lebensfähiger HA-Cluster erfordert mindestens zwei Nodes, gemeinsam genutzten oder replizierten Storage, redundantes Networking und Cluster-Management-Software-Lizenzierung (wo zutreffend). Für On-Premises-Deployments bedeutet dies typischerweise einen 3- bis 5-fachen Kostenmultiplikator gegenüber einem Single-Server-Deployment. Cloud-basiertes Clustering mit verwalteten Diensten (AWS RDS Multi-AZ, Azure SQL Managed Instance) verschiebt diese Kosten auf ein Betriebskostenmodell, führt jedoch zu Vendor-Lock-in.

Konfigurationskomplexität und operatives Fachwissen

Cluster-Fehlkonfiguration ist eine der häufigsten Ursachen für ungeplante Ausfälle in Enterprise-Umgebungen. Häufige Fehler umfassen:

• Fencing nicht konfiguriert oder nicht getestet – der Cluster kann sich nicht sicher von Node-Ausfällen erholen
• Quorum falsch konfiguriert – Split-Brain-Szenarien beschädigen gemeinsam genutzte Daten
• Ressourcenabhängigkeiten falsch definiert – Dienste starten nach dem Failover in der falschen Reihenfolge und verursachen Kaskadenausfälle
• Heartbeat-Netzwerk auf derselben Schnittstelle wie Produktions-Traffic – Storage- oder Traffic-Spitzen lösen falsche Failovers aus

Laufendes Cluster-Management erfordert Ingenieure, die sowohl die Cluster-Software als auch die Anwendungen, die sie schützt, verstehen. Dies ist ein eigenständiges Skill-Set gegenüber der allgemeinen Systemadministration.

Storage-Engpässe

Gemeinsam genutzter Storage ist ein häufiger Performance-Engpass in HA-Clustern. Alle Nodes konkurrieren um I/O-Bandbreite zum selben Storage-Backend. Schlecht konzipierte Storage-Cluster werden zum limitierenden Faktor für das gesamte System. Lösungen umfassen Storage-Tiering (NVMe für heiße Daten, Spinning Disk für kalte), Read-Caching auf Nodes und verteilte Storage-Architekturen, die den einzelnen Storage-Controller eliminieren.

Für Workloads, die maximale I/O-Leistung und vollständige Hardware-Kontrolle erfordern, bieten Dedizierte Server mit lokalem NVMe-Storage und Hardware-RAID eine solide Grundlage für den Aufbau storage-optimierter Cluster-Nodes.

Cluster-Architektur für Web-Hosting-Umgebungen

Web-facing-Cluster haben ein spezifisches Architekturmuster, das es wert ist, explizit detailliert zu werden:

[Client Requests]
        |
[Load Balancer Layer] (HAProxy / NGINX / cloud LB — active-active pair)
        |
[Application Server Layer] (Node 1, Node 2, Node N — stateless)
        |
[Database Layer] (Primary + Replica — HA cluster with automatic failover)
        |
[Shared Storage / Object Storage] (Ceph, NFS, S3-compatible)

Jede Schicht ist unabhängig skalierbar und redundant. Die Anwendungsserver sind zustandslos – der Sitzungsstatus wird in einem gemeinsam genutzten Redis– oder Memcached-Cluster gespeichert, nicht auf dem lokalen Node. Dieses Design bedeutet, dass jeder Anwendungs-Node entfernt oder hinzugefügt werden kann, ohne aktive Sitzungen zu beeinträchtigen.

Für Teams, die Web-Infrastruktur in großem Maßstab verwalten, bieten VPS mit cPanel-Umgebungen eine verwaltete Control Plane, die cluster-benachbarte Aufgaben wie DNS-Management, SSL-Bereitstellung und Multi-Domain-Konfiguration vereinfacht. Für Teams, die granulare Kontrolle über ihren Clustering-Stack bevorzugen, bieten VPS-Control-Panels eine Reihe von Optionen, die für verschiedene operative Modelle geeignet sind.

SSL-Terminierung in einer geclusterten Web-Umgebung verdient besondere Aufmerksamkeit: Der Load Balancer übernimmt typischerweise die TLS-Terminierung, entschlüsselt den Traffic, bevor er ihn über das interne Netzwerk auf Backend-Nodes verteilt. Dies erfordert, dass SSL-Zertifikate auf der Load-Balancer-Ebene bereitgestellt und erneuert werden, nicht auf einzelnen Anwendungs-Nodes – eine häufige Fehlkonfiguration, die nach einem Node-Failover zu Zertifikatsfehlern führt.

Technische Entscheidungsmatrix

Verwenden Sie diese Matrix, um die geeignete Cluster-Architektur für eine bestimmte Arbeitslast zu bestimmen:

Praktische Schlüssel-Checkliste

Überprüfen Sie vor dem Deployment eines Server-Clusters jedes der folgenden Punkte:

• Quorum ist konfiguriert mit einer ungeraden Anzahl von Stimmen oder einem dedizierten Tiebreaker – setzen Sie niemals einen Zwei-Node-Cluster ohne einen Quorum-Witness ein
• Fencing (STONITH) ist getestet, indem physisch ein Netzwerkkabel gezogen wird und bestätigt wird, dass der Cluster den Node korrekt isoliert und das Failover abschließt
• Heartbeat- und Produktionsnetzwerke befinden sich auf separaten physischen Schnittstellen – teilen Sie diese niemals
• Storage-Multipath (MPIO) ist konfiguriert mit mindestens zwei unabhängigen Pfaden zum gemeinsam genutzten Storage
• Replikationsverzögerung wird überwacht mit definierten Alarmschwellenwerten, bevor der RPO überschritten wird
• Failover wurde unter Last getestet – ein Cluster, der nie getestet wurde, ist kein Cluster, sondern eine Theorie
• Anwendungsverhalten nach dem Failover ist validiert – bestätigen Sie, dass die Anwendung sich mit dem neuen Primary verbindet, veraltete Verbindungen bereinigt und Traffic korrekt bedient
• Cluster-Ereignisse werden auf einem zentralen, externen Log-Server protokolliert – nicht auf lokalem Node-Storage, der während des Ausfalls, den Sie zu diagnostizieren versuchen, möglicherweise nicht verfügbar ist
• SSL-Zertifikate sind auf der Load-Balancer-Ebene bereitgestellt, nicht auf einzelnen Backend-Nodes
• Kapazitätsplanung berücksichtigt N-1-Node-Verfügbarkeit – der Cluster muss die volle Produktionslast mit einem ausgefallenen Node bewältigen

Häufig gestellte Fragen

Was ist die Mindestanzahl von Nodes, die für einen Server-Cluster erforderlich ist?

Technisch gesehen sind zwei Nodes für einen Aktiv-Passiv-HA-Cluster ausreichend. Ein Zwei-Node-Cluster erfordert jedoch einen Quorum-Witness (eine dritte Tiebreaker-Ressource), um Split-Brain zu verhindern. Für Aktiv-Aktiv-Load-Balancing-Cluster sind drei Nodes das praktische Minimum, um Redundanz aufrechtzuerhalten, wenn ein Node zur Wartung entfernt wird.

Was ist Split-Brain in einem Server-Cluster und warum ist es gefährlich?

Split-Brain tritt auf, wenn das interne Kommunikationsnetzwerk des Clusters ausfällt und die Nodes den Kontakt zueinander verlieren. Jeder Node schlussfolgert, dass der andere ausgefallen ist, und versucht gleichzeitig, die Eigentümerschaft gemeinsamer Ressourcen zu übernehmen. Wenn beide Nodes gleichzeitig ohne Koordination auf denselben gemeinsam genutzten Storage schreiben, ist Datenbeschädigung das Ergebnis. Quorum-Mechanismen und STONITH-Fencing sind die zwei Abwehrmaßnahmen gegen Split-Brain.

Wie unterscheidet sich Server-Clustering von Server-Virtualisierung?

Virtualisierung partitioniert einen einzelnen physischen Server in mehrere isolierte virtuelle Maschinen. Clustering verbindet mehrere Server, um als ein System zu agieren. Die beiden ergänzen sich: Virtualisierte Server (VMs) werden häufig als Cluster-Nodes verwendet, und Hypervisor-Plattformen wie VMware vSphere umfassen eigene HA-Clustering-Funktionen, die auf VM-Ebene statt auf OS- oder Anwendungsebene arbeiten.

Kann Server-Clustering alle Ausfallzeiten eliminieren?

Nein. Clustering reduziert ungeplante Ausfallzeiten drastisch durch Automatisierung des Failovers, eliminiert sie jedoch nicht. Das Failover selbst dauert Zeit (Sekunden bis Minuten, abhängig von der Arbeitslast und der Cluster-Konfiguration). Darüber hinaus können Bugs in der Cluster-Software, gleichzeitige Multi-Node-Ausfälle und Netzwerkpartitionierungsszenarien Ausfälle verursachen, die Clustering nicht verhindern kann. Das Ziel ist es, ein definiertes Verfügbarkeits-SLA zu erfüllen, nicht absolute null Ausfallzeiten zu erreichen.

Was ist der Unterschied zwischen einem HA-Cluster und einem Disaster-Recovery (DR)-Setup?

Ein HA-Cluster bietet automatisches, nahezu sofortiges Failover innerhalb desselben Standorts oder derselben Availability Zone, typischerweise mit RPO = 0 und RTO gemessen in Sekunden bis Minuten. Ein DR-Setup repliziert Daten an einen geografisch getrennten Standort und erfordert manuelle oder halbautomatische Intervention zur Aktivierung, mit RTO gemessen in Minuten bis Stunden und einem RPO ungleich null aufgrund asynchroner Replikation. Produktionsumgebungen, die sowohl lokale Resilienz als auch geografische Redundanz erfordern, setzen HA-Clustering innerhalb eines Standorts und DR-Replikation über Standorte hinweg ein.