---
title: "Microsoft Azure Hochverfügbarkeit: SafeKit synchrone Replikation und Failover"
canonical: "https://safekit.eviden.com/de/solutions/azure-high-availability-cluster-synchronous-replication-failover/"
description: "Stellen Sie einen einfachen Microsoft Azure HA-Cluster mit SafeKit bereit. Unsere Shared-Nothing Architektur bietet synchrone Replikation, automatische Failover und RPO = 0 für Windows und Linux Anwendungen ohne die Kosten für gemeinsam genutzte Cloud-Datenträger."
category: "solutions"
lang: "de"
topics: "SafeKit Shared-Nothing HA in Azure: Eliminieren Sie gemeinsam genutzte Festplatten ohne Datenverlust, Inhaltsverzeichnis, Wie implementiert die SafeKit Software einfach einen Shared-Nothing Azure Hochverfügbarkeitscluster?, Wie funktioniert der SafeKit Mirror-Cluster mit Azure ?, Einschränkungen SafeKit Hochverfügbarkeit, Vergleich: SafeKit für Azure vs. native Cloud-HA/DR-Lösungen, Videoanleitung: Konfigurieren eines SafeKit HA-Mirror-Cluster"
translation: "translate_md 2026-11-08.3 | glossaire 2026-11-08.11 | Translation LLM | 34 expressions"
---
# Microsoft Azure Hochverfügbarkeit: SafeKit synchrone Replikation und Failover {#microsoft-azure-high-availability-safekit-synchronous-replication--failover}
## SafeKit Shared-Nothing HA in Azure: Eliminieren Sie gemeinsam genutzte Festplatten ohne Datenverlust {#cloud-ha-limitation}
Während große **Cloud-Anbieter** eine native Redundanz bieten, lassen sie oft eine erhebliche Lücke zwischen Datenreplikation und echter Hochverfügbarkeit. Derzeit müssen Cloud-Benutzer zwischen zwei suboptimalen Pfaden wählen: der nativen **asynchronen Replikation**, die ein manuelles Failover erfordert und Datenverlust riskiert, oder **der Cloud Shared Disk**, der die für eine nahtlose Geschäftskontinuität erforderlichen automatisierten Failover-Mechanismen fehlen.
### SafeKit: Die leichte All-in-One-Alternative zu komplexen Azure-Clustern {#safekit-cloud-mirror}
* **All-in-One 2-Knoten Azure Cluster:** SafeKit ist eine Komplettlösung, die **native Multi-AZ-Funktionen (Availability Zone)** mit virtueller IP, automatischem Failover, automatischer Failback und synchroner Echtzeit-Dateireplikation in einem einzigen, integrierten Softwarepaket bietet.
* **Kein Datenverlust (RPO = 0):** Im Gegensatz zur nativen Cloud-VM-Replikation für DR (Disaster Recovery) verwendet SafeKit **eine synchrone Replikation auf Dateiebene**, um die Datenintegrität für transaktionale Anwendungen zu gewährleisten und so sicherzustellen, dass bei einem Ausfall keine Daten verloren gehen.
* **Shared-Nothing-Architektur:** SafeKit macht Cloud-Shared-Disks überflüssig und löst die damit verbundenen Probleme der „Disk-Locking“. **Es verwendet lokale Festplatten für maximale Geschwindigkeit und minimale Kosten**. Während herkömmliche Cluster oft darauf warten, dass der Cloud-Anbieter eine Speicherblockierung von einem ausgefallenen Knoten freigibt, verwendet SafeKit unabhängige, synchronisierte Ordner innerhalb der lokalen Festplatten jedes Knotens, um ein sofortiges Failover zu gewährleisten.
* **Null-Anwendungs-Neukonfiguration:** SafeKit führt eine transparente Replikation auf Dateiebene durch, sodass Sie Anwendungen und Daten genau dort schützen können, wo sie installiert sind – auch auf der Systemfestplatte – ohne dass Daten auf dedizierte Cloud-Freigabenlaufwerke migriert werden müssen.
* **Kubernetes Alternative:** SafeKit bietet Hochverfügbarkeit für Legacy- und containerisierte Anwendungen (nicht für Kubernetes konzipiert) ohne den Betriebsaufwand und die Komplexität der Kubernetes-Orchestrierung.
* **Einheitliche Bereitstellung (On-Premise oder Cloud):** Abgesehen von der Konfiguration der [virtuellen IP innerhalb eines Cloud-Load Balancer](https://safekit.eviden.com/de/best-practises/how-a-virtual-ip-address-works/) bleibt der SafeKit Bereitstellungsprozess in lokalen und Cloud-Umgebungen identisch.
Durch die Konsolidierung **der Hochverfügbarkeit** in einer schlanken Softwareebene bietet SafeKit Redundanz und Geschäftskontinuität in Unternehmensqualität in der Cloud zu einem Bruchteil der Kosten herkömmlicher Clustering-Suiten.
**SafeKit HA Mirror-Cluster für Azure**
⚡ Kurzanleitung zur Installation Mirror-Cluster für Azure >
## Inhaltsverzeichnis {#toc}
* [Wie implementiert die SafeKit Software einfach einen Shared-Nothing Azure Hochverfügbarkeitscluster?](#safekit-mirror-ha-cluster)
* [Wie funktioniert der SafeKit-Mirror-Cluster mit Azure ?](#safekit-mirror-cluster)
* [Einschränkungen SafeKit Hochverfügbarkeit](#safekit-ha-limitations)
* [Vergleich: SafeKit für Azure vs. native Cloud-HA/DR-Lösungen](#safekit-mirror-ha-comparison)
* [Videoanleitung: Konfigurieren eines SafeKit Mirror-HA-Cluster](#videoguide-safekit-mirror-cluster)
* [🔍 SafeKit Hochverfügbarkeits-Navigations-Hub](#hub)
## Wie implementiert die SafeKit Software einfach einen Shared-Nothing Azure Hochverfügbarkeitscluster? {#safekit-mirror-ha-cluster}
### Was ist die SafeKit Mirror HA-Lösung für Azure ? {#what-is-the-safekit-mirror-ha-solution-for--get-app-}
SafeKit bietet Hochverfügbarkeit für Azure zwischen zwei virtuellen Maschinen in zwei Verfügbarkeitszonen (AZ).
Dieser Artikel erklärt, wie Sie schnell einen Azure Cluster ohne Cloud-Shared-Disks und ohne spezielle Kenntnisse implementieren können.
Das Prinzip der Lösung besteht darin, die Ordner zu definieren, in denen sich die Anwendungsdaten der Azure, ihre Dienste, eine virtuelle IP-Adresse und Prüfprogramme befinden.
SafeKit implementiert dann **die Echtzeit-Replikation** und **das automatische Failover**, um eine kontinuierliche Dienstverfügbarkeit zu gewährleisten.
### Warum sollten Sie sich für eine einheitliche All-in-One-HA-Lösung anstelle von fragmentierten Tools entscheiden? {#why-choose-a-unified-all-in-one-ha-solution-over-fragmented-tools}
Im Gegensatz zu "Add-on"-Lösungen, die separate Produkte für Replikation und Clustering kombinieren, integriert **SafeKit** **virtuelle IP, automatische Failover, automatischer Failback und synchrone Echtzeit-Dateireplikation** in eine einzige Engine.
Dies eliminiert das „Kartenhaus“-Risiko, bei dem Updates fragile Verbindungen zwischen unterschiedlichen Tools unterbrechen, bietet einen einzigen Verantwortlichkeitspunkt für den gesamten HA-Stack und reduziert menschliche Fehler, indem es eine einzige Schnittstelle für **Azure Anwendungs-HA** bereitstellt.
### Wie handhabt SafeKit die einheitliche Bereitstellung und die virtuelle Cloud-IP? {#how-does-safekit-handle-uniform-deployment-and-the-cloud-virtual-ip}
SafeKit ist eine Cloud-agnostische Lösung, was bedeutet, dass der Bereitstellungsprozess und die Architektur sowohl bei lokalen Servern als auch bei allen großen Cloud-Anbietern gleich bleiben. Der einzige architektonische Unterschied liegt darin, wie die **[virtuelle IP-Adresse](https://safekit.eviden.com/de/best-practises/how-a-virtual-ip-address-works/)** dem Netzwerk präsentiert wird:
* **Vor Ort:** SafeKit verwaltet die VIP direkt, indem es **GARP Pakete (Gratuitous ARP)** an lokale Switches sendet und die IP sofort zwischen den Knoten verschiebt.
* **In der Cloud:** Da Cloud-Netzwerke GARP nicht unterstützen, wird die virtuelle IP von einem **Cloud Load Balancer** gehostet. **SafeKit stellt die Health-Probe bereit**, um zu bestimmen, welcher Knoten der primäre ist. Dies ermöglicht es dem Load Balancer, den aktiven Knoten in Echtzeit zu erkennen und den Datenverkehr automatisch an diesen zu leiten, wodurch ein nahtloses Failover über Verfügbarkeitszonen hinweg gewährleistet wird.
### Welche besonderen Vorteile bietet SafeKit für die Hochverfügbarkeit Azure im Vergleich zu Mitbewerbern? {#what-are-the-distinctive-advantages-of-safekit-for--get-app--high-availability-compared-to-competitors}
SafeKit unterscheidet sich von herkömmlichen Azure Clustern durch seine **Shared-Nothing-Architektur** und die vereinfachte Bereitstellung. Während die meisten Unternehmenslösungen eine komplexe Verwaltung von Cloud-Shared-Disks erfordern, bietet SafeKit:
* **Synchrone Replikation mit Null Datenverlust:** SafeKit implementiert eine 100 % synchrone Replikation, die die vollständige Datenintegrität für transaktionale Anwendungen gewährleistet. Im Falle eines Ausfalls gibt es **keinen Datenverlust (RPO = 0)**. Darüber hinaus ist SafeKit in der Lage, nicht nur die Azure, sondern **auch alle anderen Datenordner** (Protokolle, Konfigurationsdateien usw.) zu replizieren, wodurch sichergestellt wird, dass die gesamte Umgebung gespiegelt wird.
* **Vereinfachte 2-Knoten-Cluster:** Im Gegensatz zu Standard-Clustern, die oft einen "Zeugen" (einen 3. Knoten, eine Festplatte, eine Dateifreigabe) benötigen, um ein Quorum aufrechtzuerhalten, bietet SafeKit volle Hochverfügbarkeit mit nur zwei redundanten Servern, wodurch Infrastrukturkosten und Komplexität reduziert werden.
[Erfahren Sie mehr über unseren Heartbeat- und Quorum-Mechanismus](https://safekit.eviden.com/de/best-practises/heartbeat-failover-quorum-windows-linux-cluster/).
* **Vereinheitlichtes Management:** Administratoren können Azure-Anwendungsfailover, Datenreplikation und Überwachung über eine einzige SafeKit Konsole verwalten. Dies macht Hochverfügbarkeit für Teams ohne spezielle "Cluster-Admin"-Expertise zugänglich.
* **Benutzerdefinierte Prüfungen:** SafeKit geht über die grundlegende Dienstüberwachung hinaus und **bietet Prüfungen** zur Überwachung des Zustands des Azure Anwendungsprozesses. Das System ist in hohem Maße erweiterbar, sodass benutzerdefinierte Prüfungen hinzugefügt werden können, die auf Ihre Umgebung zugeschnitten sind.
### Wie reduziert SafeKit die TCO (Total Cost of Ownership) für Azure im Vergleich zu Standard-Clustering? {#how-does-safekit-reduce-the-tco-total-cost-of-ownership-for--get-app--compared-to-standard-clustering}
Im Gegensatz zu herkömmlichen Hochverfügbarkeitslösungen ist SafeKit so konzipiert, dass es mit dem **absolut geringsten Infrastruktur-Overhead** betrieben werden kann, ohne die Zuverlässigkeit zu beeinträchtigen. Die wichtigsten Einsparungen im Vergleich zu herkömmlichen Failover-Clustern sind:
* **Keine Kosten für gemeinsam genutzte Cloud-Datenträger:** SafeKit verwendet eine „Shared-Nothing“-Architektur, die mit lokalen Datenträgern arbeitet.
* **Keine Enterprise Edition erforderlich:** Während native Datenbank-Replikationsmechanismen möglicherweise eine teure Enterprise-Lizenzierung erfordern, benötigt SafeKit **keine Enterprise-Edition**. Es funktioniert nahtlos mit der Standard-Edition und sogar der **kostenlosen Edition** und bietet High-End-Verfügbarkeit zu einem Bruchteil der Kosten.
* **Echte 2-Knoten-Effizienz:** Im Gegensatz zu Standard-Clustern, die oft einen "Zeugen" (einen 3. Knoten, eine Festplatte oder eine Dateifreigabe) benötigen, um ein Quorum aufrechtzuerhalten, bietet SafeKit volle Hochverfügbarkeit mit nur **zwei redundanten Servern**.
* **Keine erzwungenen Abonnements:** SafeKit bietet eine **unbefristete Lizenz**. Sie besitzen Ihre Software und vermeiden so die „Abonnementfalle“ und unvorhersehbare jährliche Preiserhöhungen, die bei modernen Cloud-basierten oder abonnementbasierten Modellen üblich sind.
* **Geringe Betriebskosten (OPEX):** Als Plug-and-Play-Lösung erfordert sie im Gegensatz zu komplexen Open-Source-Clustering-Tools keine spezielle Schulung oder teure externe Beratung für die Wartung.
* **CPU-unabhängige Preisgestaltung:** Die Lizenzierung ist unabhängig von der Anzahl der CPUs oder Kerne. Mit nur zwei Lizenzen für zwei Knoten können Sie Ihre Azure Anwendung vor Ausfällen schützen.
### Ist es möglich, einen Azure Mirror-Cluster ohne Clustering-Kenntnisse einzurichten? {#is-it-possible-to-set-up-a--get-app--mirror-cluster-without-clustering-skills}
Ja. Dieser Artikel erklärt, wie Sie [schnell einen Azure Mirror-Cluster implementieren können,](https://safekit.eviden.com/de/quick-install/safekit-quick-installation-guide-in-azure-with-real-time-replication-and-failover/) ohne dass Sie komplexe HA-Clustering-Kenntnisse benötigen. Durch die Verwendung der **automatisierten Failover-Skripte** von SafeKit zur Handhabung der Replikation und des Neustarts Ihrer **Azure Anwendung** erhalten Sie eine robuste Redundanzlösung, die wesentlich einfacher zu implementieren und zu warten ist als herkömmliche Clustering-Lösungen.
### Welche Anwendungen und Umgebungen kann SafeKit über Azure hinaus schützen? {#beyond--get-app--which-applications-and-environments-can-safekit-protect}
SafeKit ist eine vielseitige Hochverfügbarkeitslösung **für Windows und Linux**, die weit über Azure Mirror-Cluster hinausgeht. Sie ermöglicht **synchrone Echtzeit-Replikation** und automatisches Failover für eine breite Palette kritischer Workloads, darunter:
* **Virtuelle und physische Umgebungen:** Vollständige Hyper-V oder KVM Virtual-Machines.
* **Container-Orchestrierung:** Docker, Podman und K3s-Umgebungen (Kubernetes).
* **Daten & Services:** Individuelle Dateiverzeichnisse, Dienste und verschiedene Datenbanken.
* **Cloud-Infrastruktur:** Hohe Verfügbarkeit für Cloud-Anwendungen.
SafeKit bietet **Farm-Cluster** auch natives **Netzwerk-Lastausgleichs- und Failover** für zustandslose Anwendungen wie **Webserver**.
💡 [Die vollständige Liste der unterstützten HA-Lösungen finden Sie hier.](https://safekit.eviden.com/de/solutions/)
## Wie funktioniert der SafeKit Mirror-Cluster mit Azure ? {#safekit-mirror-cluster}
### Schritt 1. Replikation in Echtzeit {#step1}
Server 1 (PRIM) führt die Azure Anwendung aus. Clients sind mit einer [virtuellen IP-Adresse](https://safekit.eviden.com/de/best-practises/how-a-virtual-ip-address-works/) verbunden. SafeKit repliziert Änderungen, die an Dateien vorgenommen werden, in Echtzeit über das Netzwerk.
Die Replikation ist [synchron](https://safekit.eviden.com/de/best-practises/synchronous-replication-vs-asynchronous-replication/) und es kommt im Gegensatz zur asynchronen Replikation bei einem Fehler nicht zu Datenverlust.
Sie müssen lediglich die Namen der zu replizierenden Verzeichnisse in SafeKit konfigurieren. Es gibt keine Voraussetzungen für die Festplattenorganisation. Verzeichnisse können sich auf der Systemfestplatte befinden.
### Schritt 2. Automatische Failover-Funktion {#step2}
Wenn Server 1 ausfällt, übernimmt Server 2. SafeKit wechselt die virtuelle IP-Adresse und startet die Azure Anwendung automatisch auf Server 2.
Die Anwendung findet die von SafeKit replizierten Dateien auf Server 2 auf dem neuesten Stand. Die Anwendung läuft weiterhin auf Server 2, indem sie ihre Dateien, die nicht mehr auf Server 1 repliziert werden, lokal ändert.
Die Failover-Zeit entspricht der Fehlererkennungszeit (standardmäßig 30 Sekunden) zuzüglich der Anwendungsstartzeit.
### Schritt 3. automatischer Failback {#step3}
Failback beinhaltet das Neustarten von Server 1, nachdem das Problem behoben wurde, das zu seinem Ausfall geführt hat.
SafeKit synchronisiert die Dateien automatisch neu und aktualisiert dabei nur die Dateien, die auf Server 2 geändert wurden, während Server 1 angehalten war.
Das Failback erfolgt, ohne die Azure Anwendung zu stören, die weiterhin auf Server 2 ausgeführt werden kann.
### Schritt 4. Zurück zum Normalzustand {#step-4-back-to-normal}
Nach der Reintegration befinden sich die Dateien wieder im mirror, wie in Schritt 1. Das System ist wieder im Hochverfügbarkeitsmodus, wobei die Azure Anwendung auf Server 2 läuft und SafeKit die Dateiaktualisierungen auf Server 1 repliziert.
Wenn der Administrator möchte, dass die Anwendung auf Server 1 ausgeführt wird, kann dies manuell über die Webkonsole zu einem geeigneten Zeitpunkt oder automatisch über die Konfiguration erfolgen.
### Wie konfiguriert man einen SafeKit Mirror-Cluster für Azure ? {#safekit-mirror-cluster-configure}
Die **SafeKit Webkonsole** bietet eine intuitive Schnittstelle zur Orchestrierung der Hochverfügbarkeit für Ihre kritischen Anwendungen. In nur wenigen Schritten können Sie einen **SafeKit Mirror-Cluster** konfigurieren, um die Geschäftskontinuität zu gewährleisten:
* **Anwendungsfailover (Registerkarte „Makros“):** Definieren Sie die spezifischen Anwendungsdienste, die im Falle eines Ausfalls automatisch neu gestartet werden sollen.
* **Heartbeat-Netzwerk(e):** Dedizierte Kommunikationspfade, die von Clusterknoten verwendet werden, um den Zustand und die Verfügbarkeit der anderen Knoten kontinuierlich zu überwachen und Failover-Entscheidungen zu synchronisieren.
* **Virtuelles IP-Management:** Richten Sie die virtuelle IP (VIP) für eine transparente Client-Wiederverbindung nach einem Failover ein.
* **Echtzeit-Replikation:** Wählen Sie die kritischen Verzeichnisse für die hostbasierte, synchrone Replikation auf Byteebene aus.
* **Checkers:** Überwachen Sie den Zustand der Anwendung und lösen Sie eine automatische Wiederherstellung aus, wenn ein Prozessfehler erkannt wird.
Das SafeKit Cluster verfügt über eine spezielle Split-Brain-Prüfung, um Probleme mit der Netzwerktrennung zu lösen, ohne dass ein dritter Witness-Computer oder ein zusätzliches Heartbeat-Netzwerk erforderlich ist. Erfahren Sie mehr über [Heartbeat, Failover und Quorum in einem Cluster](https://safekit.eviden.com/de/best-practises/heartbeat-failover-quorum-windows-linux-cluster/).
### Wie kann man einen SafeKit Mirror-Cluster für Azure überwachen? {#safekit-mirror-cluster-monitoring}
Die **SafeKit Managementkonsole** bietet eine einheitliche Ansicht Ihrer Hochverfügbarkeitsinfrastruktur. Sie ermöglicht es Administratoren, den **Betriebsstatus** des Clusters zu überwachen und die Datensynchronisierung in Echtzeit zu verfolgen.
Bei einem Mirror-Cluster mit zwei Knoten zeigt die Konsole die Rollen der einzelnen Server deutlich an:
* **PRIM (Primär):** Der aktive Knoten, auf dem die Anwendung derzeit ausgeführt wird und der die virtuelle IP-Adresse verwaltet. Er führt Schreibvorgänge in den lokalen Speicher und die Echtzeitreplikation auf den sekundären Knoten durch.
* **SECOND (Sekundär):** Der Standby-Knoten empfängt synchrone Updates auf Byte-Ebene. Er ist bereit, sofort die Übernahme zu übernehmen, falls der primäre Knoten ausfällt.
* **ALONE Status:** Warnt Sie visuell, wenn der Cluster auf einem einzelnen Knoten läuft (z. B. während der Wartung oder nach einem Fehler), was darauf hinweist, dass die Redundanz vorübergehend verloren gegangen ist.
* **Resynchronisierungsfortschritt:** Wenn sich ein ausgefallener Knoten erholt, wird sein Status während der Hintergrunddatenneuintegration orange, um sicherzustellen, dass es während der „Rückkehr zum Normalzustand“-Phase keine Ausfallzeiten gibt.
Über einfache Status-Symbole hinaus bietet die Schnittstelle **eine Failover-Orchestrierung mit einem Klick**, mit der Sie die primäre Rolle für geplante Wartungsarbeiten manuell neu zuweisen und gleichzeitig die kontinuierliche Verfügbarkeit für Benutzeraktivitäten gewährleisten können.
## Einschränkungen SafeKit Hochverfügbarkeit {#safekit-ha-limitations}
Grenzwert / Anforderung | Grund und Auswirkung | Empfohlene Alternative
---|---|---
Replikationsgröße: Einige TB | Resynchronisierungszeit nach einem Fehler ([Schritt 3](https://safekit.eviden.com/de/architectures/file-replication-byte-level-with-failover-mirror-cluster/#safekit-mirror-cluster)):
• 1-Gbit/s-Netzwerk ≈ 3 Stunden/TB
• 10-Gbit/s-Netzwerk ≈ 1 Stunde/TB (abhängig von der Schreibgeschwindigkeit der Festplatte) | • Verwenden Sie [externen gemeinsam genutzten Speicher](https://safekit.eviden.com/de/best-practises/san-vs-nas-shared-storage-for-a-failover-cluster/) (teurer, komplexer).
Anzahl der Dateien: < 1.000.000 Dateien | • Leistung der Resynchronisierungszeit nach einem Fehler ([Schritt 3](https://safekit.eviden.com/de/architectures/file-replication-byte-level-with-failover-mirror-cluster/#safekit-mirror-cluster)).
• Zeit, die zum Vergleichen jeder Datei zwischen beiden Knoten benötigt wird. | • Legen Sie die vielen zu replizierenden Dateien auf eine virtuelle Festplatte/in eine virtuelle Maschine.
• In diesem Fall werden nur die Dateien repliziert und erneut synchronisiert, die die virtuelle Festplatte/virtuelle Maschine darstellen.
Failover-Kapazität: ≤ 32 VMs | • Jede VM läuft in einem unabhängigen mirror-Modul.
• Maximal 32 mirror-Module die auf demselben Cluster laufen. | • Verwenden Sie einen externen gemeinsam genutzten Speicher und eine andere VM-Clustering-Lösung (teurer, komplexer).
Netzwerkarchitektur: LAN/VLAN-Netzwerk zwischen entfernten Standorten | • Automatisches Failover der [virtuellen IP-Adresse](https://safekit.eviden.com/de/best-practises/how-a-virtual-ip-address-works/) mit 2 Knoten im selben Subnetz.
• Gute Bandbreite für die Resynchronisierung ([Schritt 3](https://safekit.eviden.com/de/architectures/file-replication-byte-level-with-failover-mirror-cluster/#safekit-mirror-cluster)).
• Geringe Latenz für [die synchrone Replikation](https://safekit.eviden.com/de/best-practises/synchronous-replication-vs-asynchronous-replication/): typischerweise < 5 ms RTT; höhere Werte sollten mit der Schreibgeschwindigkeit der Anwendung abgeglichen werden. | • Wenn sich die beiden Knoten in unterschiedlichen Subnetzen befinden (in der Cloud üblich), verwenden Sie [andere Umleitungsoptionen](https://safekit.eviden.com/de/best-practises/how-a-virtual-ip-address-works/#safekit-virtual-ip-implementation): einen Load Balancer, Cloud-Provider-CLIs, BGP oder DNS-Umleitung.
• Verwenden Sie Backup-Lösungen mit asynchroner Replikation für Netzwerke mit hoher Latenz.
## Vergleich: SafeKit für Azure vs. native Cloud-HA/DR-Lösungen {#safekit-mirror-ha-comparison}
Funktion | SafeKit für Azure | Native Cloud-Freigabediskette | Native Cloud-VM-Replikation für DR (Disaster Recovery)
---|---|---|---
Architektur | Shared-Nothing: Verwendet lokale Datenträger für maximale Geschwindigkeit und minimale Kosten. | Gemeinsamer Speicher: Abhängig von Cloud-verwalteten Datenträgern. | Blockebene: Repliziert ganze VM-Datenträger in eine passive Region.
Datenintegrität (RPO) | Null (RPO = 0): Synchrone Replikation auf Dateiebene. | Null: Synchrones Schreiben auf eine gemeinsam genutzte Festplatte. | Nicht Null: Asynchrone Replikation führt zu Datenverzögerung.
Failover-/Failback-Logik | Vollautomatisch: Integrierte Überwachung und Neustart. | Erfordert ein Failover-Tool von Drittanbietern, das gemeinsam genutzte Cloud-Datenträger unterstützt. | Manuell: Erfordert die Aktivierung eines Notfallwiederherstellungsplans.
Anwendungseinrichtung | Null-Rekonfiguration: Schützt Anwendungen dort, wo sie derzeit installiert sind. | Neukonfiguration: Anwendungsdaten müssen auf eine bestimmte freigegebene Festplatte migriert werden. | Keine: Erfasst das gesamte Betriebssystem und die Anwendungen im Ist-Zustand.
Replikationsumfang | Vollständig: Anwendungsdatenordner (DB + Konfiguration + Protokolle). | Teilweise: Nur auf dem freigegebenen Volume gespeicherte Daten. | Gesamt: Repliziert die gesamte virtuelle Maschine.
VM-Lokalisierung | Native Multi-AZ: Synchrone Replikation über Verfügbarkeitszonen hinweg innerhalb einer Region. | Anbieterabhängig: Erfordert einen gemeinsam genutzten Speicher, der über Verfügbarkeitszonen hinweg repliziert wird. | Regional: Hauptsächlich für die Replikation zwischen weit entfernten geografischen Regionen konzipiert.
Bereitstellungszeit | Niedrig: < 30 Minuten (On-Premise oder Cloud). | Hoch: Tage oder Wochen für die Clusterkonfiguration. | Medium: Erfordert die Einrichtung von DR-Tresoren und -Richtlinien.
### Ist Hochverfügbarkeit ein Ersatz für die native Cloud-VM-Replikation für die Notfallwiederherstellung (Disaster Recovery)? {#ha-vs-backup-ransomware}
**Nein**, Hochverfügbarkeit und Backups sind komplementär, nicht austauschbar. Während **SafeKit** **die Geschäftskontinuität** gewährleistet, indem es Anwendungen bei einem Hardwareabsturz weiterlaufen lässt, schützt es nicht vor logischen Fehlern, versehentlichen Löschungen oder Ransomware-Angriffen. Da die Echtzeitreplikation beispielsweise jede Änderung sofort spiegelt, wird ein Ransomware-Angriff auf den primären Knoten sofort auf den sekundären Knoten dupliziert. Um sich von solchen Cyberbedrohungen oder versehentlichen Löschungen zu erholen, benötigen Sie eine dedizierte **Backup-Lösung** mit einer robusten Aufbewahrungsrichtlinie. Dies ermöglicht es Ihnen, Ihre Umgebung auf einen fehlerfreien Zustand von vor dem Auftreten der Beschädigung „zurückzuspulen“.
### Schlussfolgerung {#conclusion}
Durch die Einführung einer **Shared-Nothing-Architektur** eliminiert SafeKit die Komplexität und die Kosten von Cloud-verwalteten Shared Disks. Im Gegensatz zu herkömmlichen Clustern bietet es eine **infrastrukturunabhängige** Lösung, die keine Neukonfiguration der Anwendung oder Datenmigration erfordert. Mit nativer **Multi-AZ-** Unterstützung und einer Bereitstellungszeit von unter 30 Minuten stellt SafeKit sicher, dass Ihre Azure Umgebung ausfallsicher bleibt, **ohne Datenverlust (RPO = 0)** und mit vollständig automatisierter Wiederherstellung.
## Videoanleitung: Konfigurieren eines SafeKit HA-Mirror-Cluster {#videoguide-safekit-mirror-cluster}
### SafeKit Video: Clustering auf Anwendungsebene (8:47) {#demo-mirror-ha-cluster}
In diesem Video erfahren Sie, wie SafeKit einen **Mirror-HA-Cluster** ohne die Komplexität eines Cloud-Shared-Disk-Clusters implementiert. Während diese Demonstration Microsoft SQL Server verwendet, funktioniert die Lösung identisch für andere Datenbanken und Anwendungen. Beachten Sie, dass die virtuelle IP in diesem Video für eine On-Premise-Lösung und nicht für einen Cloud Load Balancer mit SafeKit Health-Probes konfiguriert ist.
### Video-Highlights {#video-highlights}
1. 🎬 [2 Knoten mit SQL Server](https://www.youtube.com/watch?v=mGwEguDnnH0&t=0s) (0:32)
2. 🎬 [Konfigurieren Sie den Cluster und das Modul mirror.safe](https://www.youtube.com/watch?v=mGwEguDnnH0&t=32s) (3:58)
3. 🎬 [SQL-Replikation, -Migration und Failover bei Absturz starten und testen](https://www.youtube.com/watch?v=mGwEguDnnH0&t=270s) (4:17)