---
title: "Die besten und schlechtesten Anwendungsfälle für Hochverfügbarkeit: Ein Implementierungsleitfaden SafeKit"
canonical: "https://safekit.eviden.com/de/use-cases/best-worst-use-cases-high-availability/"
description: "Ermitteln Sie die besten und schlechtesten Anwendungsfälle für Hochverfügbarkeit. Erfahren Sie, wo SafeKit in softwaredefiniertem Clustering für Windows und Linux seine Stärken ausspielt, und finden Sie heraus, wann herkömmliche gemeinsam genutzte Speicherlösungen oder hardwarebasierte Hochverfügbarkeit für Ihr Unternehmen ungeeignet sein könnten."
category: "use-cases"
lang: "de"
topics: "Beste Anwendungsfälle, Einschränkungen SafeKit Hochverfügbarkeit"
---
# Beste und schlechteste Anwendungsfälle für Hochverfügbarkeit: Ein Implementierungsleitfaden SafeKit {#best-and-worst-high-availability-use-cases-a-safekit-implementation-guide}
## Beste Anwendungsfälle {#best-use-cases}
### OEM-Software {#oem-software}
Ein Softwarehersteller verwendet [ SafeKit als OEM-Software ]() für die Hochverfügbarkeit seiner Anwendung
### Distributed Enterprise {#distributed-enterprise}
Ein verteiltes Unternehmen implementiert [ SafeKit in vielen Niederlassungen ]() ohne spezifische IT-Kenntnisse
### Remote Sites {#remote-sites}
[ SafeKit wird an zwei entfernten Standorten ]() eingesetzt, ohne dass replizierte Festplatteneinschübe über ein SAN erforderlich sind.
## 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.