--- title: "Hochverfügbarkeitsarchitekturen und Best Practices für Software-Cluster" canonical: "https://safekit.eviden.com/de/best-practises/high-availability-architectures-and-best-practices/" description: "Entdecken Sie Hochverfügbarkeitsarchitekturen (HA) und Best Practices für Anwendungscluster. Erfahren Sie, wie SafeKit Mirror- und Farm-Cluster ohne gemeinsam genutzte Datenträger implementiert und so Datenverlust verhindert und automatischer Failover für kritische Anwendungen ermöglicht wird." category: "best-practises" lang: "de" topics: "Welche Hochverfügbarkeitsarchitekturen und Best Practices gibt es?, Vergleichstabellen zu Hochverfügbarkeitsarchitekturen und Best Practices" --- # Hochverfügbarkeitsarchitekturen und Best Practices für Software-Cluster {#high-availability-architectures--software-clustering-best-practices} ## Welche Hochverfügbarkeitsarchitekturen und Best Practices gibt es? {#what-are-the-high-availability-architectures-and-the-best-practices} ### Überblick {#overview} Dieser Artikel stellt verschiedene Hochverfügbarkeitsarchitekturen und Best Practices vor und vergleicht ihre jeweiligen Vor- und Nachteile. ![Hochverfügbarkeitsarchitekturen und Best Practices](https://safekit.eviden.com/wp-content/uploads/2023/03/high-availability-architectures-and-best-practices.png "w:400") Die folgenden Vergleichstabellen erläutern die SafeKit-Hochverfügbarkeitsarchitektur und ihre Best Practices. SafeKit ist eine Software für Hochverfügbarkeit. ### Welche Hochverfügbarkeitsarchitekturen gibt es? {#what-are-the-high-availability-architectures} Es gibt zwei Arten von [Hochverfügbarkeitsarchitekturen](): für Backend-Anwendungen wie Datenbanken und für Frontend-Anwendungen wie Webdienste. Backend-Architekturen basieren auf zwei Servern, die Daten gemeinsam nutzen oder replizieren und bei Hardware- oder Softwarefehlern automatisch einen Anwendungs-Failover ausführen. Frontend-Architekturen basieren auf einer Serverfarm mit mindestens zwei Servern. Hardware- oder Software-Load-Balancing verteilt TCP-Sitzungen auf die verfügbaren Server. Außerdem muss zwischen Hochverfügbarkeit auf Anwendungs- und auf virtueller Maschinenebene gewählt werden. ### Welche Best Practices gibt es? {#what-are-the-best-practices} Dieser Artikel vergleicht Best Practices für Hochverfügbarkeitsarchitekturen in folgenden Bereichen: * [Software- und Hardware-Clustering](), * [Shared-Nothing- und Shared-Disk-Architektur](), * [Hochverfügbarkeit auf Anwendungs- und VM-Ebene](), * [Hochverfügbarkeit und Fehlertoleranz](), * [synchrone und asynchrone Replikation](), * [Datei- und Festplattenreplikation](), * [Datenreplikationstechniken](), * [RPO und RTO anhand von Beispielen](), * [Split-Brain und Quorum](), * [virtuelle IP-Adressen](). ## Vergleichstabellen zu Hochverfügbarkeitsarchitekturen und Best Practices {#comparative-tables-on-high-availability-architectures-and-best-practices} Die Wahl der richtigen Hochverfügbarkeitslösung (High Availability / HA) ist entscheidend für die Sicherstellung der Betriebskontinuität und die Minimierung von Ausfallzeiten. Dieser Vergleich bietet eine direkte, technische Gegenüberstellung zweier grundlegender Architekturansätze: Das softwaredefinierte Shared-Nothing-Clustering von SafeKit im Vergleich zu traditionellen HA-Methoden, die in der Regel auf Hardware, gemeinsamen Datenträgern (wie einem SAN) und komplexen Konfigurationen basieren. Diese Unterschiede betreffen die Einfachheit der Bereitstellung, Datenreplikationsmethoden, Wiederherstellungszeiten (RTO/RPO) und die betriebliche Komplexität. Die folgende Tabelle beschreibt die wesentlichen Unterschiede zu den wichtigsten Hochverfügbarkeitsthemen. **Hochverfügbarkeitsvergleich: SafeKit Software-Clustering vs. Traditionelle HA / Hardware-Clustering** Thema | SafeKit (Software-Clustering / Primärer Ansatz) | Traditionelle HA / Hardware-Clustering ---|---|--- [Software-Clustering vs. Hardware-Clustering](https://safekit.eviden.com/best-practises/clustering-software-vs-hardware-clustering/) | • Ein einfacher Software-Cluster, bei dem das SafeKit-Paket lediglich auf zwei Servern installiert wird | • Komplexes Hardware-Clustering mit externem Speicher oder Netzwerk-Load-Balancern [Shared-Nothing vs. Shared-Disk-Cluster](https://safekit.eviden.com/best-practises/shared-nothing-architecture-vs-shared-disk-architecture/) | • SafeKit ist ein Shared-Nothing-Cluster: Einfach bereitzustellen, selbst an entfernten Standorten | • Ein Shared-Disk-Cluster ist komplex in der Bereitstellung [Anwendungs-Hochverfügbarkeit vs. Hochverfügbarkeit ganzer virtueller Maschinen](https://safekit.eviden.com/de/best-practises/vm-ha-vs-application-ha/) | • Anwendungs-HA unterstützt Hardware- und Softwareausfälle durch Anwendungsprüfer (Checker).
• Schnelle Wiederherstellungszeit, da nur die Anwendung neu gestartet wird ([RTO etwa 1 Minute oder weniger](https://safekit.eviden.com/best-practises/what-is-rpo-and-rto-with-examples/)).
• Anwendungs-HA erfordert die Definition von Neustart-Skripten pro Anwendung sowie zu replizierenden Ordnern (SafeKit-Anwendungsmodule). | • Vollständige VM-HA unterstützt Hardwareausfälle und einige Softwareausfälle wie z. B. eine eingefrorene VM.
• VM-Neustart im Fehlerfall und Wiederherstellungszeit abhängig vom Neustart des Betriebssystems.
• Keine Neustart-Skripte bei vollständiger VM-HA erforderlich (SafeKit-Module 🛠️ [hyperv.safe](https://safekit.eviden.com/quick-install/safekit-quick-installation-guide-with-hyper-v/) oder 🛠️ [kvm.safe](https://safekit.eviden.com/quick-install/safekit-quick-installation-guide-with-kvm/)). Hypervisoren arbeiten Aktiv/Aktiv mit mehreren virtuellen Maschinen. [Hochverfügbarkeit vs. Fehlertoleranz (Fault Tolerance)](https://safekit.eviden.com/best-practises/high-availability-cluster-vs-fault-tolerant-system/) | • Kein dedizierter Server mit SafeKit. Jeder [Server kann als Failover-Server des anderen dienen](https://safekit.eviden.com/architectures/active-active-cluster-real-time-replication/).
• Softwareausfall mit Neustart in einer anderen Betriebssystemumgebung.
• Reibungslose Aktualisierung von Anwendung und Betriebssystem Server für Server möglich (Version N und N+1 können koexistieren). | • Sekundärer Server dediziert für die Ausführung derselben Anwendung, synchronisiert auf Befehlsebene.
• Softwareausnahme tritt auf beiden Servern gleichzeitig auf.
• Reibungslose Aktualisierung nicht möglich.
• Spezielle fehlertolerante Hardware oder Hypervisoren erforderlich. [Synchrone Replikation vs. Asynchrone Replikation](https://safekit.eviden.com/best-practises/synchronous-replication-vs-asynchronous-replication/) | • SafeKit implementiert eine synchrone Replikation in Echtzeit ohne Datenverlust im Fehlerfall.
• Zwingende Voraussetzung für Hochverfügbarkeit. | • Bei asynchroner Replikation kommt es im Fehlerfall zu Datenverlust.
• Nicht für Hochverfügbarkeit geeignet, sondern für Backup-Lösungen. [Dateireplikation auf Byte-Ebene vs. Festplattenreplikation auf Block-Ebene](https://safekit.eviden.com/best-practises/byte-level-file-replication-vs-block-level-disk-replication/) | • SafeKit implementiert eine Echtzeit-Dateireplikation auf Byte-Ebene und wird einfach mit den zu replizierenden Anwendungsverzeichnissen konfiguriert, selbst auf der Systemfestplatte. | • Die Festplattenreplikation auf Block-Ebene ist komplex zu konfigurieren und erfordert die Ablage der Anwendungsdaten auf einer speziellen Festplatte. [Heartbeat, Failover und Quorum zur Vermeidung von 2 Master-Knoten](https://safekit.eviden.com/best-practises/heartbeat-failover-quorum-windows-linux-cluster/) | • Um 2 Master-Knoten (Split-Brain) zu vermeiden, bietet SafeKit einen einfachen Split-Brain-Checker, der auf einem Router konfiguriert wird. | • Um 2 Master-Knoten zu vermeiden, erfordern andere Cluster eine komplexe Konfiguration mit einer dritten Maschine, einer speziellen Quorum-Festplatte oder einer speziellen Verbindungsleitung. [Virtuelle IP-Adresse: Primär/Sekundär, Netzwerk-Lastverteilung, Failover](https://safekit.eviden.com/best-practises/how-a-virtual-ip-address-works/) | • Keine dedizierten Proxy-Server und keine spezielle Netzwerkkonfiguration in einem SafeKit-Cluster für virtuelle IP-Adressen erforderlich. | • Spezielle Netzwerkkonfiguration in anderen Clustern für virtuelle IP-Adressen erforderlich (Hinweis: SafeKit bietet einen an Load Balancer angepassten Health Check). **Zusammenfassend** hat die Architekturentscheidung zwischen Software-Clustering (wie SafeKit) und Hardware-Clustering (traditionelle Shared-Disk-/SAN-Lösungen) erhebliche Auswirkungen auf die Bereitstellungskomplexität, die Betriebskosten und die Effektivität der Wiederherstellung im Fehlerfall. Die wichtigste Erkenntnis aus diesem Vergleich ist die Entwicklung hin zu Shared-Nothing-Architekturen und Hochverfügbarkeit auf Anwendungsebene, bei denen eine schnelle Wiederherstellung von Anwendungen (niedrige RTO) und flexible Bereitstellungsoptionen (auch über verteilte Standorte hinweg) im Vordergrund stehen. Dies führt häufig zu einer schlankeren und widerstandsfähigeren Lösung als hochkomplexe, hardwareabhängige Clusterkonfigurationen. Um maximale Geschäftskontinuität bei gleichzeitig vereinfachter Verwaltung zu erreichen, ist die Bewertung eines softwarebasierten Ansatzes von entscheidender Bedeutung.