SafeKit: All-in-One-Software für SAN-lose Hochverfügbarkeit und Anwendungsclustering
Was ist SafeKit?
SafeKit ist eine All-in-One-Software für Hochverfügbarkeit , die eine 100-prozentige Anwendungsverfügbarkeit garantiert. Sie vereint hostbasierte Echtzeit-Replikation , automatisches Failover und Lastverteilung in einem einzigen Paket.
Durch die Synchronisierung von Daten zwischen Standard-Servern macht SafeKit teure gemeinsam genutzte Speicherlösungen (SAN) oder spezialisierte IT-Kenntnisse überflüssig. Es bietet eine einfache und kosteneffiziente Methode zum Schutz von Unternehmensdatenbanken (wie SQL Server), kritischen Sicherheitssystemen (wie der Videomanagementsoftware Milestone XProtect) und SCADA-Industriesteuerungen (wie Siemens-Anwendungen) – sowohl in Windows- als auch in Linux-Umgebungen.
🔍 SafeKit Hochverfügbarkeit Navigation Hub
Entdecken Sie SafeKit: Funktionen, technische Videos, Dokumentation und kostenlose Testversion
| Ressourcentyp | Beschreibung | Direkter Link |
|---|---|---|
| Hauptfunktionen | Warum SafeKit für einfache und kosteneffiziente Hochverfügbarkeit wählen? | Warum SafeKit für Hochverfügbarkeit? |
| Anwendungsfälle | Erfahren Sie, wie SafeKit die Hochverfügbarkeit kritischer Infrastrukturen gewährleistet | Alle Anwendungsfälle ansehen (OEM-Software, Edge-Server, SCADA und mehr) |
| Bereitstellungsmodell | All-in-One SANlose HA: Shared-Nothing Software-Clustering | SafeKit All-in-One SANlose HA ansehen |
| HA-Strategien | SafeKit: Infrastruktur (VM) vs. Hochverfügbarkeit auf Anwendungsebene | SafeKit HA & Redundanz: VM vs. Anwendungsebene |
| Technische Spezifikationen | Technische Einschränkungen für SafeKit-Clustering | Technische Einschränkungen von SafeKit ansehen |
| Proof of Concept | SafeKit: Konfiguration der Hochverfügbarkeit & Failover-Demos | SafeKit Failover-Tutorials ansehen |
| Architektur | Wie der SafeKit Mirror Cluster funktioniert (Echtzeit-Replikation & Failover) | SafeKit Mirror Cluster: Echtzeit-Replikation & Failover |
| Architektur | Wie der SafeKit Farm Cluster funktioniert (Netzwerk-Lastverteilung & Failover) | SafeKit Farm Cluster: Netzwerk-Lastverteilung & Failover |
| Wettbewerbsvorteile | Vergleich: SafeKit vs. traditionelle Hochverfügbarkeits-Cluster (HA) | Vergleich: SafeKit vs. traditionelle HA-Cluster |
| Technische Ressourcen | SafeKit Hochverfügbarkeit: Dokumentation, Downloads & Testversion | Kostenlose Testversion & Technische Dokumentation |
| Vorkonfigurierte Lösungen | SafeKit Applikationsmodul-Bibliothek: Gebrauchsfertige HA-Lösungen | SafeKit Applikationsmodule für Hochverfügbarkeit |
Warum SafeKit für einfache und kosteneffiziente Hochverfügbarkeit wählen?
Welche Funktionen bietet SafeKit?
SafeKit bietet die folgenden Funktionen für Windows und Linux in einem einzigen Softwareprodukt:
- Lastverteilung (Load Balancing)
- Synchrone Dateireplikation in Echtzeit
- Automatisches Anwendungs-Failover
- Automatisches Failback nach einem Serverausfall
Benötige ich spezielle Kenntnisse, um SafeKit einzurichten?
Nein. SafeKit ist einfach bereitzustellen – es sind keine fortgeschrittenen Fachkenntnisse erforderlich.
Erfordert SafeKit zusätzliche Hardware?
Nein. SafeKit läuft auf Ihren vorhandenen Servern, virtuellen Maschinen oder in der Cloud – es werden keine gemeinsam genutzten Festplatten oder SAN-Speicher benötigt.
Sind für SafeKit zusätzliche Softwarelizenzen erforderlich?
Nein. SafeKit funktioniert mit Standard-Editionen von Windows und Linux und benötigt keine Enterprise-Datenbanklizenzen.
Welche Probleme löst SafeKit?
SafeKit löst:
- Hardwarefehler (20 % der Probleme), einschließlich des kompletten Ausfalls eines Serverraums
- Softwarefehler (40 % der Probleme), einschließlich des Neustarts kritischer Prozesse
- Menschliche Fehler (40 % der Probleme) dank seiner einfachen Bedienung
Welche Anwendungen werden von SafeKit unterstützt?
Sie können Echtzeit-Replikation und Failover implementieren für:
- Alle Arten von Anwendungen, Dateiverzeichnissen und Diensten
- Datenbanken
- Vollständige virtuelle Maschinen (Hyper-V oder KVM)
- Docker, Podman und Cloud-Anwendungen
Wie senkt SafeKit die Kosten?
SafeKit macht die folgenden Anforderungen überflüssig:
- Netzwerk-Lastverteiler oder dedizierte Proxy-Server
- Gemeinsam genutzte Festplatten oder replizierte SAN-Speicher
- Enterprise-Editionen von Betriebssystemen und Datenbanken
- Spezialisierte Fachkenntnisse für die Cluster-Wartung
Wie wird die SafeKit-Hochverfügbarkeit preislich gestaltet und lizenziert?
SafeKit bietet ein transparentes, kosteneffizientes Lizenzmodell pro Knoten , das ausschließlich auf der Anzahl der Server basiert – unabhängig von CPU-Kernen oder Sockets. Im Gegensatz zu vielen Wettbewerbern im Bereich Hochverfügbarkeit, die wiederkehrende Abonnements vorschreiben, bietet SafeKit unbefristete Lizenzen (perpetual licenses) , um niedrigere Gesamtkosten (TCO) und langfristige Software-Assets zu gewährleisten.
- Keine versteckten Kosten: Alle vorkonfigurierten HA-Applikationsmodule werden kostenlos zur Verfügung gestellt.
- Risikofreie Evaluierung: Laden Sie eine kostenlose 30-Tage-Testversion herunter, um Failover und Replikation in Ihrer Umgebung zu testen.
- Individuelle Angebote: Bitte kontaktieren Sie uns für ein Angebot , das auf Ihre spezifischen Anforderungen an die Hochverfügbarkeit zugeschnitten ist.
SafeKit Anwendungsfälle
SafeKit für OEM
Die Bereitstellung von Hochverfügbarkeit für Ihre Anwendung steigert den Geschäftswert, indem sie einen kontinuierlichen Service garantiert, Ausfallrisiken senkt und das Kundenvertrauen stärkt. Gleichzeitig ermöglicht sie den unterbrechungsfreien Betrieb kritischer Prozesse auf Standardinfrastrukturen.
Ergänzen Sie Ihren Katalog um SafeKit als Hochverfügbarkeitsoption: eine reine Softwarelösung, die auf Ihre Anwendung zugeschnitten ist, ohne versteckte Kosten wie gemeinsam genutzten Speicher auskommt, vollständig hardwareunabhängig ist und in physischen, virtuellen oder Cloud-Umgebungen mit einfacher Plug-and-Play-Verwaltung eingesetzt werden kann.
SafeKit für Edge
Edge-Standorte verfügen oft weder über ein Rechenzentrum noch über HA-Expertise – und doch ist die Geschäftskontinuität entscheidend. SafeKit hält Edge-Anwendungen in Fabriken, auf Ölplattformen, Schiffen, in der Gebäudesicherheit, der Flugsicherung, in 5G-Netzwerken, im Gesundheitswesen, im Einzelhandel und mehr am Laufen…
SafeKit verwandelt zwei Standard-Edge-Server (beliebiger Marken) in einen Plug-and-Play-HA-Cluster – ohne gemeinsam genutzten Speicher/SAN. Ein leichtgewichtiger Software-Stack bietet Echtzeit-Replikation und automatisches Failover (optional auch mit Lastverteilung) und ist dabei einfach zu installieren und zu verwalten.
SafeKit für VMS
Videomanagement-Software (VMS) ist für die öffentliche Sicherheit von entscheidender Bedeutung. Sie zeichnet Live- und Archivvideos auf und zeigt diese an, damit Sicherheitskräfte sofort auf Vorfälle reagieren können. Jeder VMS-Ausfall stellt ein unmittelbares Risiko für Personen und Sachwerte dar.
SafeKit verhindert Videoverluste und Überwachungslücken, indem es den kontinuierlichen Zugriff auf Live- und aufgezeichnete Streams aufrechterhält – selbst bei Server- oder Softwarefehlern. Es lässt sich nahtlos in führende VMS-Plattformen wie Milestone, Genetec, Hanwha und andere integrieren, um die Überwachung genau dann betriebsbereit zu halten, wenn es darauf ankommt.
SafeKit für EACS
Elektronische Zutrittskontrollsysteme (EACS) sind für die physische Sicherheit unerlässlich. Sie steuern und überwachen den Zugang zu privaten und sensiblen Bereichen über Türen, Ausweise, Lesegeräte und Sensoren. Jeder Systemausfall kann Personen, Gebäude und Sachwerte sofort der Gefahr eines unbefugten Eindringens aussetzen.
SafeKit stellt sicher, dass Zutrittsentscheidungen, Alarme und Anmeldedaten jederzeit verfügbar bleiben, indem „Single Points of Failure“ eliminiert werden. Es bietet einen belastbaren Betrieb für EACS-Lösungen wie Hirsch Microsesame, Nedap AEOS und Siemens SiPass und gewährleistet den sicheren Zugang auch bei Vorfällen in der Infrastruktur.
SafeKit für SCADA
SCADA-Systeme (Supervisory Control and Data Acquisition) bilden das Herzstück industrieller Umgebungen. Sie ermöglichen es den Bedienern, kritische Prozesse über Sensoren, Ventile, Pumpen, Motoren und Mensch-Maschine-Schnittstellen (HMI) zu überwachen und zu steuern.
SafeKit minimiert Produktionsausfälle, indem es sicherstellt, dass SCADA-Steuerungssysteme – wie sie beispielsweise Probat-Kaffeeröster und ALSTEF-Gepäcksortieranlagen antreiben – trotz Hardware- oder Softwareproblemen betriebsbereit bleiben. Dies ermöglicht es dem Bedienpersonal, jederzeit die volle Sichtbarkeit und Kontrolle über die industriellen Prozesse zu behalten, wodurch kostspielige Stillstände und Sicherheitsrisiken vermieden werden.
SafeKit für BMS
Gebäudemanagementsysteme (BMS) sind das Herzstück moderner Gebäude und ermöglichen die automatisierte Steuerung von HLK-Anlagen, Stromverteilung, Beleuchtung, Brandschutz und Wassersystemen. Jeder Systemausfall kann sich direkt auf die Sicherheit der Nutzer, den Komfort und den Gebäudebetrieb auswirken.
SafeKit sichert die Gebäudeautomation ab, indem BMS-Dienste im Falle eines Fehlers transparent weiterlaufen. Es unterstützt Plattformen wie Siemens Desigo CC, Bosch BIS und verwandte Systeme, um einen sicheren, effizienten und unterbrechungsfreien Gebäudebetrieb aufrechtzuerhalten.
SafeKit für ATC
Flugsicherungssysteme (ATC) sind für die Sicherheit in der Luftfahrt von entscheidender Bedeutung. Sie ermöglichen die Echtzeitüberwachung und -steuerung von Flugzeugbewegungen am Boden und in der Luft durch Überwachungs-, Leit- und Kontrollanwendungen.
SafeKit stärkt die Resilienz von ATC-Systemen, indem es den Fluglotsen den ununterbrochenen Zugriff auf kritische Airside-Anwendungen garantiert. Es wird in Verbindung mit ATC- und Flughafenlösungen wie ADB SafeGate eingesetzt, um einen sicheren und kontinuierlichen Flugbetrieb unter allen Bedingungen zu gewährleisten.
SafeKit für OCC
Betriebsleitzentralen (OCC) bilden das Herzstück moderner Metronetze. Sie zentralisieren die Überwachung von Zugbewegungen, Stromversorgung, Signaltechnik, Fahrgastinformationen und das Incident Management. Bei automatisierten, fahrerlosen Metrolinien ist das OCC der zentrale Steuerungspunkt für den gesamten Betrieb.
SafeKit sichert die unterbrechungsfreie Überwachung der Metro, indem es gewährleistet, dass OCC-Anwendungen auch bei Ausfällen verfügbar bleiben. Es unterstützt Betriebsleitzentralen für automatisierte, fahrerlose Pariser Metrolinien und ermöglicht so einen kontinuierlichen Service sowie eine schnelle Reaktion auf Vorfälle, ohne auf Fahrer an Bord angewiesen zu sein.
Warum ein All-in-One-Produkt für SANlose Hochverfügbarkeit unverzichtbar ist
In der Welt des Business Continuity glauben viele Unternehmen fälschlicherweise, dass ein Backup oder ein Tool zur Datenreplikation dasselbe ist wie Hochverfügbarkeit (HA). In Wirklichkeit sind dies nur Teile eines viel größeren Puzzles. Um eine 100-prozentige Betriebszeit wirklich zu garantieren, benötigen Sie eine All-in-One-Lösung, die jede Ebene des Failover-Prozesses integriert.
Hier erfahren Sie, warum ein fragmentierter Ansatz scheitert und warum ein integriertes All-in-One-Produkt wie SafeKit – das hostbasierte Replikation auf Dateiebene nutzt – erforderlich ist.
Ist hostbasierte Replikation allein ausreichend für Hochverfügbarkeit?
Nein. Datenreplikation ist lediglich der Vorgang des Kopierens von Daten von Server A nach Server B. Obwohl sie kritisch ist, bietet die Replikation an sich keine Verfügbarkeit. Ohne die anderen Komponenten eines HA-Stacks ist die Replikation nur eine „passive Kopie“, die manuelle und zeitintensive Eingriffe erfordert, um nutzbar zu werden:
- Wenn Server A abstürzt, wird die Datenreplikations-Software Ihre Benutzer nicht automatisch auf Server B umleiten.
- Sie wird nicht erkennen, dass die Anwendung gestoppt wurde.
- Sie wird die Dienste nicht neu starten.
Die versteckten Risiken fragmentierter Lösungen: Warum isolierte HA die Ausfallrate erhöht
Viele Anbieter verlangen von Ihnen, mehrere verschiedene Produkte für hostbasierte Replikation , Failover und Lastverteilung „zusammenzustückeln“. Diese fragmentierte Architektur ist eine gefährliche Strategie für geschäftskritische Systeme:
- Anfällige Integration: Wenn Sie Produkt A für die Replikation und Produkt B für das Clustering verwenden, bauen Sie ein „Kartenhaus“. Jedes Betriebssystem-Update oder Sicherheitspatch birgt das Risiko, die fragile Kommunikationsverbindung zwischen diesen separaten Engines zu unterbrechen.
- Hohe kognitive Belastung & menschliches Versagen: Die Verwaltung mehrerer Schnittstellen erhöht das Fehlerrisiko. Bei einem Systemausfall unter hohem Druck führt das Springen zwischen verschiedenen GUIs oder die Verwendung unterschiedlicher CLI-Syntaxen zur Problemdiagnose zu Verwirrung und verlängerten Ausfallzeiten.
- Gegenseitige Schuldzuweisungen der Anbieter: Wenn ein Failover fehlschlägt, gibt der Replikationsanbieter möglicherweise dem Clustering-Tool die Schuld. Sie sitzen dazwischen fest, ohne einen klaren Weg zur Lösung. Eine All-in-One-Lösung bietet einen einzigen Verantwortlichen (Single Point of Accountability).
- Komplexe Wartung: Fragmentierte Systeme erfordern spezialisierte Kenntnisse für jede einzelne Komponente. Das macht die Lösung schwieriger zu warten und über die Zeit hinweg deutlich teurer.
Welche spezifischen Komponenten sind außer den Daten für ein echtes SANloses Failover erforderlich?
Um die Wiederherstellung zu automatisieren und Ausfallzeiten zu eliminieren, muss ein All-in-One-Produkt mehrere technische Prozesse gleichzeitig steuern:
- Hostbasierte Replikation: Synchrone Echtzeit-Replikation kritischer Anwendungsdaten zwischen Servern, ohne auf gemeinsamen Speicher (SAN) angewiesen zu sein. Dies garantiert keinen Datenverlust (RPO=0) und eliminiert teure Hardware-Abhängigkeiten.
- Virtuelle IP-Adresse (VIP): Diese bietet einen zentralen Einstiegspunkt für Benutzer. Im Falle eines Fehlers verschiebt die Software die VIP vom ausgefallenen Knoten auf den gesunden, sodass Benutzer ihre Konfiguration nicht ändern müssen.
- Hardware- und Software-Fehlerdetektoren: Das System muss sowohl den physischen Server als auch die spezifischen Softwareprozesse ständig per „Heartbeat“ überwachen, um ein Aufhängen oder einen Absturz sofort zu erkennen.
- Anpassbare Neustart-Skripte: Nicht jede Anwendung startet auf die gleiche Weise. Ein All-in-One-Tool ermöglicht benutzerdefinierte Skripte, um sicherzustellen, dass komplexe Dienste in der richtigen Reihenfolge starten.
- Automatisches Failover: Die Intelligenz, um den gesamten Wechsel von einem Server zum anderen ohne menschliches Eingreifen zu orchestrieren.
Warum muss der Failover-Mechanismus mit der hostbasierten Replikation synchronisiert sein?
Wenn Ihr Failover-Manager und Ihre Datenreplikation zwei verschiedene Produkte sind, sind diese möglicherweise nicht „synchron“.
Die Gefahr: Wenn ein Failover erfolgt, bevor die Replikation die neuesten Datenpakete vollständig übertragen hat, startet Server B die Anwendung mit veralteten oder beschädigten Daten.
Eine SANlose All-in-One-HA-Lösung stellt sicher, dass der Failover-Mechanismus über den Replikationsstatus informiert ist. Sie lässt den Start der Anwendung auf dem Backup-Knoten nur dann zu, wenn die Aktualität der Daten garantiert ist. Dies verhindert Datenverlust und Konflikte durch gleichzeitig aktive Knoten (Split-Brain).
Was passiert, wenn der ausgefallene Server repariert wurde (Failback)?
Das automatische Failback wird in technischen Leitfäden oft ignoriert und von herkömmlichen HA-Lösungen mangelhaft ausgeführt, bleibt jedoch die kritischste Anforderung für echte Resilienz. Ein echtes All-in-One-Produkt handhabt die „Rückkehr zum Normalbetrieb“ ebenso elegant wie den Ausfall. Wenn der ausgefallene Server wieder online geht, ist sein Datenstand veraltet. Die HA-Software muss:
- Daten resynchronisieren: Dies geschieht im Hintergrund vom aktiven Knoten zum wiederhergestellten Knoten.
- Betriebszeit aufrechterhalten: Diese Resynchronisation muss erfolgen, ohne die aktuell auf dem aktiven Knoten laufende Anwendung zu unterbrechen.
- Redundanz wiederherstellen: Sobald die Daten wieder gespiegelt sind, kehrt der Cluster automatisch in einen geschützten Zustand zurück und ist bereit für das nächste Ereignis.
Replikation auf Block- vs. Dateiebene: Warum Transparenz entscheidend ist
Die technische Methode, die für die hostbasierte Replikation verwendet wird, hat erheblichen Einfluss darauf, wie stark Sie Ihr bestehendes Anwendungs-Setup ändern müssen.
- Die Herausforderung der Replikation auf Blockebene: Die meisten SANlosen Lösungen replizieren auf Festplatten- oder Blockebene. Dies ist für die Anwendung nicht transparent. Sie müssen die Anwendung komplett umkonfigurieren, um ihre Daten auf ein spezielles, neu erstelltes „repliziertes Festplatten-Volume“ zu verschieben. Dies erfordert oft komplexe Migrationen und potenzielle Änderungen an der Anwendungslogik.
- Der SafeKit-Vorteil auf Dateiebene: SafeKit führt die hostbasierte Replikation auf Dateiebene durch, was für die Anwendung völlig transparent ist. Sie müssen keine Daten auf eine spezielle Festplatte verschieben; Sie konfigurieren SafeKit einfach so, dass die vorhandenen Anwendungsordner repliziert werden. Diese Ordner können sogar auf der Systemfestplatte verbleiben, sodass Sie eine Anwendung genau dort schützen können, wo sie bereits installiert ist.
Wahl Ihrer Hochverfügbarkeitsstrategie: VM HA vs. Application HA
SafeKit bietet zwei primäre Ansätze zur Sicherstellung der Geschäftskontinuität: Virtual Machine HA (VM HA) und Application HA. Obwohl beide Methoden automatische Failover-Funktionen bieten, unterscheiden sie sich deutlich in ihrem Umfang, ihren Datenreplikationsmechanismen, der Wiederherstellungsgeschwindigkeit und der Plattformkompatibilität. Dieser Vergleich erläutert diese Unterschiede, um die optimale Strategie für spezifische IT-Umgebungen zu identifizieren – abhängig davon, ob der Fokus auf breiter Virtualisierungsunterstützung oder feingranularer, schneller Anwendungswiederherstellung liegt.
Funktionsvergleich: SafeKit VM HA vs. SafeKit Application HA Clustering
| Vergleichsmerkmal | VM HA mit SafeKit Hyper-V- oder KVM-Modul | Application HA mit SafeKit Application-Modulen |
|---|---|---|
| Bereitstellungsdiagramm | ||
| Failover-Umfang | SafeKit innerhalb von zwei Hypervisoren: Replikation und Failover der gesamten VM. | SafeKit auf zwei virtuellen oder physischen Maschinen: Replikation und Failover auf Anwendungsebene. |
| Replizierte Daten | Repliziert mehr Daten (Anwendung + Betriebssystem). | Repliziert nur Anwendungsdaten, was zu geringeren Datenmengen führt. |
| Wiederherstellungsprozess & Geschwindigkeit (RTO) | Neustart der VM auf Hypervisor 2, wenn Hypervisor 1 ausfällt. Die Wiederherstellungszeit hängt vom Neustart des Betriebssystems ab. VM-Überwachung und Failover-Mechanismus. | Schnelle Wiederherstellung mit Neustart der Anwendung auf OS2, wenn Server 1 ausfällt. Typischerweise etwa 1 Minute oder weniger (niedriger RTO). Anwendungsüberwachung und softwarebasiertes Failover. |
| Installation | Die Anwendung wird einmal in einer einzelnen VM installiert. | Die Anwendung wird auf zwei Nodes installiert. |
| Konfiguration | Generische Lösung für jede Anwendung / jedes OS, das in der VM läuft. • Erfordert kein technisches Verständnis der in der VM installierten Anwendung. • Beste Lösung, wenn Sie nicht wissen, wie die Anwendung funktioniert. • Sie müssen lediglich den Speicherort der VM-Dateien definieren. | Erfordert technisches Verständnis der Anwendung selbst. • Welche Dienste neu gestartet werden müssen. • Welche Anwendungsverzeichnisse in Echtzeit repliziert werden müssen. • Konfiguration einer virtuellen IP-Adresse für das Failover. |
| Plattformkompatibilität | Funktioniert mit Windows/Hyper-V und Linux/KVM, ist jedoch nicht mit VMware kompatibel. | Plattformunabhängig; funktioniert mit physischen oder virtuellen Maschinen, Cloud-Infrastrukturen und allen Hypervisoren, einschließlich VMware. |
| Ideal für | Ideal für die Verwaltung komplexer Umgebungen mit mehreren Anwendungen über mehrere VMs hinweg mittels einer einzigen HA-Richtlinie. | Ideal zur direkten Integration von Hochverfügbarkeit in eine Softwarelösung, unabhängig von der zugrunde liegenden Hardware oder dem Hypervisor. |
Einschränkungen der SafeKit-Hochverfügbarkeit
Warum eine Replikation von einigen Terabyte?
Resynchronisationszeit nach einem Ausfall (Schritt 3)
- 1 Gb/s Netzwerk ≈ 3 Stunden für 1 Terabyte.
- 10 Gb/s Netzwerk ≈ 1 Stunde für 1 Terabyte oder weniger, abhängig von der Schreibgeschwindigkeit der Festplatten.
Alternative
- Für ein großes Datenvolumen verwenden Sie externen gemeinsamen Speicher.
- Teurer, komplexer.
Warum eine Replikation < 1.000.000 Dateien?
- Leistung der Resynchronisationszeit nach einem Ausfall (Schritt 3).
- Zeit zum Überprüfen jeder Datei zwischen beiden Knoten.
Alternative
- Legen Sie die vielen zu replizierenden Dateien in eine virtuelle Festplatte / virtuelle Maschine.
- Nur die Dateien, die die virtuelle Festplatte / virtuelle Maschine darstellen, werden in diesem Fall repliziert und resynchronisiert.
Warum ein Failover ≤ 32 replizierte VMs?
- Jede VM läuft in einem unabhängigen Spiegelmodul.
- Maximal 32 Spiegelmodule, die auf demselben Cluster laufen.
Alternative
- Verwenden Sie einen externen gemeinsamen Speicher und eine andere VM-Clustering-Lösung.
- Teurer, komplexer.
Warum ein LAN/VLAN-Netzwerk zwischen entfernten Standorten?
- Automatisches Failover der virtuellen IP-Adresse mit 2 Knoten im selben Subnetz.
- Gute Bandbreite für die Resynchronisation (Schritt 3) und gute Latenz für synchrone Replikation (typischerweise eine Round-Trip-Zeit von weniger als 2 ms).
Alternative
- Verwenden Sie einen Load Balancer für die virtuelle IP-Adresse, wenn sich die 2 Knoten in 2 Subnetzen befinden (unterstützt von SafeKit, insbesondere in der Cloud).
- Verwenden Sie Backup-Lösungen mit asynchroner Replikation für Netzwerke mit hoher Latenz.
SafeKit Technische Failover-Tutorials & Demos
SafeKit Video: Webinar (9:43)
&amp;amp;amp;amp;lt;br /&amp;amp;amp;amp;gt;
Kapitel
- Einführung (0:38)
- Demonstration von SafeKit (1:41)
- Beispiele für Redundanz und Hochverfügbarkeitslösungen (2:00)
- SafeKit-Vertrieb in vielen verschiedenen Ländern mit Milestone (0:49)
- Wahl zwischen zwei Lösungen: Virtuelle Maschine oder Applikations-Cluster (2:29)
- Besondere Vorteile (2:06)
SafeKit: Implementierung von HADR (6:42)
&amp;amp;amp;amp;lt;br /&amp;amp;amp;amp;gt;
Kapitel
- Einführung in SafeKit HADR über Stretched VLANs (1:06)
- Wie synchrone Spiegelung & doppelte Bestätigung funktionieren (1:41)
- Failover-Mechanismen: Gratuitous ARP (GARP) & virtuelle IP (2:10)
- Konzeption für langsame WANs: Hochverfügbarkeit vs. Backup-Strategien (2:45)
Erfahren Sie mehr über SafeKit HADR
SafeKit Video: Clustering auf Virtual Machine-Ebene (5:15)
&amp;amp;amp;amp;lt;br /&amp;amp;amp;amp;gt;
Kapitel
- 2 Hyper-V-Knoten und 2 virtuelle Maschinen (0:49)
- Konfiguration des Clusters und der zwei hyperv.safe-Module (1:59)
- Starten und Testen von VM-Replikation, Migration und Failover bei Absturz (2:26)
SafeKit Video: Clustering auf Anwendungsebene mit SQL (8:47)
&amp;amp;amp;amp;lt;br /&amp;amp;amp;amp;gt;
Kapitel
- 2 Knoten mit SQL Server (0:32)
- Konfiguration des Clusters und des mirror.safe-Moduls (3:58)
- Starten und Testen von SQL-Replikation, Migration und Failover bei Absturz (4:17)
SafeKit Video: OEM High Availability-Integration (4:22)
&amp;amp;amp;amp;lt;br /&amp;amp;amp;amp;gt;
Kapitel
- SafeKit für OEM-Integration (0:09)
- Beispiel für OEM-Einrichtung: Milestone XProtect (2:18)
- Erklärung von Failover-Szenarien (1:49)
- Fazit: Erweitern Sie Ihren Katalog um OEM-Hochverfügbarkeit (0:15)
SafeKit Video: Network Load Balancing Clustering (5:03)
&amp;amp;amp;amp;lt;br /&amp;amp;amp;amp;gt;
Kapitel
- 2 Knoten mit Apache (0:13)
- Konfiguration des Clusters und des farm.safe-Moduls (2:20)
- Starten und Testen von Netzwerklastverteilung und Failover bei Absturz (2:30)
SafeKit Video: Tutorial zur kostenlosen Zertifizierungsplattform (6:11)
&amp;amp;amp;amp;lt;br /&amp;amp;amp;amp;gt;
Kapitel
- Die Trainings- und Zertifizierungsplattform (1:41)
- Was ist ein SafeKit-Trainingsmodul? (1:57)
- Wie erhält man ein SafeKit-Zertifikat? (1:40)
- Teilen Sie Ihr Zertifikat auf LinkedIn (0:53)
Trainings- und Zertifizierungsplattform hier
SafeKit Video: Wettbewerbsvergleich und Cluster-Architekturen (13:21)
&amp;amp;amp;amp;lt;br /&amp;amp;amp;amp;gt;
Kapitel
- Einführung (4:10)
- Virtueller Maschinen-Cluster (1:20)
- Spiegel-Cluster (Mirror Cluster) (6:04)
- Farm-Cluster (Farm Cluster) (1:46)
SafeKit im Vergleich zu traditionellen HA-Clustern ansehen
SafeKit Video: Konsole auf dem Smartphone (0:54)
&amp;amp;amp;amp;lt;br /&amp;amp;amp;amp;gt;
SafeKit Video: E-Mail-Benachrichtigungen bei Failover (1:04)
&amp;amp;amp;amp;lt;br /&amp;amp;amp;amp;gt;
Wie funktioniert das SafeKit-Mirror-Cluster mit Windows/Linux?
Schritt 1. Echtzeit-Replikation
Server 1 (PRIM) führt die Anwendung Windows/Linux aus. Clients sind mit einer virtuellen IP-Adresse verbunden. SafeKit repliziert Dateiänderungen in Echtzeit über das Netzwerk.
Die Replikation erfolgt synchron, sodass im Gegensatz zur asynchronen Replikation bei einem Ausfall keine Daten verloren gehen.
Sie müssen lediglich die Namen der zu replizierenden Verzeichnisse in SafeKit konfigurieren. Es gibt keine Voraussetzungen für die Festplattenorganisation. Die Verzeichnisse können sich auch auf der Systemfestplatte befinden.
Schritt 2. Automatischer Failover
Wenn Server 1 ausfällt, übernimmt Server 2. SafeKit schaltet die virtuelle IP-Adresse um und startet die Anwendung Windows/Linux automatisch auf Server 2 neu.
Die Anwendung findet die von SafeKit replizierten Dateien auf Server 2 im aktuellen Zustand vor. Die Anwendung läuft auf Server 2 weiter, indem sie ihre Dateien lokal ändert, die nun nicht mehr auf Server 1 repliziert werden.
Die Failover-Zeit entspricht der Zeit für die Fehlererkennung (standardmäßig 30 Sekunden) zuzüglich der Startzeit der Anwendung.
Schritt 3. Automatischer Failback
Der Failback beinhaltet den Neustart von Server 1, nachdem das Problem behoben wurde, das den Ausfall verursacht hat.
SafeKit resynchronisiert die Dateien automatisch und aktualisiert nur die Dateien, die auf Server 2 geändert wurden, während Server 1 angehalten war.
Der Failback erfolgt ohne Beeinträchtigung der Anwendung Windows/Linux, die auf Server 2 wie gewohnt weiterlaufen kann.
Schritt 4. Rückkehr zum Normalbetrieb
Nach der Reintegration befinden sich die Dateien wieder im Mirror-Modus, genau wie in Schritt 1. Das System ist zurück im Hochverfügbarkeitsmodus, wobei die Anwendung Windows/Linux auf Server 2 läuft und SafeKit die Dateiaktualisierungen auf Server 1 repliziert.
Wenn der Administrator möchte, dass die Anwendung auf Server 1 läuft, kann dies zu einem geeigneten Zeitpunkt manuell über die Webkonsole oder automatisch per Konfiguration erfolgen.
Wie konfiguriert man ein SafeKit-Mirror-Cluster für Windows/Linux?
Die SafeKit-Webkonsole bietet eine intuitive Benutzeroberfläche zur Orchestrierung der Hochverfügbarkeit für Ihre kritischen Anwendungen. In nur wenigen Schritten können Sie ein SafeKit-Mirror-Cluster konfigurieren, um die Geschäftskontinuität zu gewährleisten:
- Anwendungs-Failover (Registerkarte „Macros“): Definieren Sie die spezifischen Anwendungsdienste, die im Falle eines Ausfalls automatisch neu gestartet werden sollen.
- Heartbeat-Netzwerk(e): Dedizierte Kommunikationspfade, die von den Cluster-Knoten genutzt werden, um gegenseitig kontinuierlich den Zustand und die Verfügbarkeit zu überwachen sowie Failover-Entscheidungen zu synchronisieren.
- Virtuelles IP-Management: Richten Sie die virtuelle IP-Adresse (VIP) für eine transparente Wiederverbindung der Clients nach einem Failover ein.
- Echtzeit-Replikation: Wählen Sie die kritischen Verzeichnisse für die hostbasierte, synchrone Replikation auf Byte-Ebene aus.
- Checkers (Prüfprogramme): Überwachen Sie den Zustand der Anwendung und lösen Sie eine automatische Wiederherstellung aus, wenn ein Prozessfehler erkannt wird.
Das SafeKit-Cluster enthält ein dediziertes Split-Brain-Prüfprogramm, um Probleme bei Netzwerkisolationen zu lösen, ohne dass eine dritte Witness-Maschine (Zeuge) oder ein zusätzliches Heartbeat-Netzwerk erforderlich ist. Erfahren Sie mehr über Heartbeat, Failover und Quorum in einem Cluster.
Wie überwacht man ein SafeKit-Mirror-Cluster für Windows/Linux?
Die SafeKit-Managementkonsole bietet eine einheitliche Ansicht Ihrer Hochverfügbarkeitsinfrastruktur. Sie ermöglicht es Administratoren, den Betriebszustand des Clusters zu überwachen und die Datensynchronisation in Echtzeit zu verfolgen.
Für ein Mirror-Cluster mit 2 Knoten zeigt die Konsole die Rollen der einzelnen Server übersichtlich an:
- PRIM (Primary): Der aktive Knoten, auf dem die Anwendung derzeit läuft und der die virtuelle IP verwaltet. Er führt Schreibvorgänge auf dem lokalen Speicher aus und übernimmt die Echtzeit-Replikation auf den sekundären Knoten.
- SECOND (Secondary): Der Standby-Knoten, der die synchronen Aktualisierungen auf Byte-Ebene empfängt. Er ist bereit, im Falle eines Ausfalls des primären Knotens sofort zu übernehmen.
- ALONE-Zustand: Warnt Sie visuell, wenn das Cluster auf einem einzelnen Knoten läuft (z. B. während Wartungsarbeiten oder nach einem Ausfall), was darauf hindeutet, dass die Redundanz vorübergehend verloren gegangen ist.
- Fortschritt der Resynchronisation: Wenn sich ein ausgefallener Knoten erholt, wechselt sein Status während der Datenreintegration im Hintergrund auf Orange, wodurch Ausfallzeiten während der Phase der „Rückkehr zum Normalbetrieb“ vermieden werden.
Über einfache Statussymbole hinaus bietet die Benutzeroberfläche eine Failover-Orchestrierung mit nur einem Klick. So können Sie die primäre Rolle für geplante Wartungsarbeiten manuell neu zuweisen und gleichzeitig die kontinuierliche Verfügbarkeit für die Benutzeraktivitäten gewährleisten.
Wie funktioniert das SafeKit-Cluster im Farm-Modus mit Windows/Linux?
Virtuelle IP-Adresse in einem Cluster im Farm-Modus
In der vorherigen Abbildung läuft die Anwendung Windows/Linux auf 3 Servern (3 ist ein Beispiel, es können auch 2 oder mehr sein). Benutzer sind mit einer virtuellen IP-Adresse verbunden.
Die virtuelle IP-Adresse ist lokal auf jedem Server im Cluster im Farm-Modus konfiguriert.
Der eingehende Datenverkehr an die virtuelle IP-Adresse wird von allen Servern empfangen und durch einen Netzwerkfilter im Kernel jedes Servers unter ihnen aufgeteilt.
SafeKit erkennt Hardware- und Softwarefehler, konfiguriert Netzwerkfilter im Falle eines Ausfalls neu und bietet konfigurierbare Anwendungsprüfer (Checkers) sowie Wiederherstellungsskripte.
Lastverteilung in einem Netzwerkfilter
Der Netzwerk-Lastverteilungsalgorithmus innerhalb des Netzwerkfilters basiert auf der Identität der Client-Pakete (Client-IP-Adresse, Client-TCP-Port). Abhängig von der Identität des eingehenden Client-Pakets akzeptiert nur ein Filter auf einem Server das Paket; die anderen Filter auf den anderen Servern lehnen es ab.
Sobald ein Paket vom Filter auf einem Server akzeptiert wurde, werden nur die CPU und der Arbeitsspeicher dieses Servers von der Windows/Linux-Anwendung verwendet, die auf die Anfrage des Clients antwortet. Die Ausgangsnachrichten werden direkt vom Anwendungsserver an den Client gesendet.
Wenn ein Server ausfällt, konfiguriert das Farm-Heartbeat-Protokoll die Filter im Netzwerk-Lastverteilungscluster neu, um den Datenverkehr auf den verbleibenden verfügbaren Servern neu auszubalancieren.
Zustandsbehaftete (stateful) oder zustandslose (stateless) Anwendungen
Bei einer zustandsbehafteten (stateful) Windows/Linux-Anwendung gibt es eine Sitzungsaffinität (Session Affinity). Derselbe Client muss über mehrere TCP-Sitzungen hinweg mit demselben Server verbunden sein, um seinen Kontext auf dem Server abzurufen. In diesem Fall ist die SafeKit-Lastverteilungsregel auf Basis der Client-IP-Adresse konfiguriert. Dadurch ist derselbe Client über mehrere TCP-Sitzungen hinweg immer mit demselben Server verbunden. Verschiedene Clients werden so auf verschiedene Server in der Farm verteilt.
Bei einer zustandslosen (stateless) Windows/Linux-Anwendung gibt es keine Sitzungsaffinität. Derselbe Client kann über mehrere TCP-Sitzungen hinweg mit verschiedenen Servern in der Farm verbunden sein. Es wird kein Kontext lokal auf einem Server von einer Sitzung zur nächsten gespeichert. In diesem Fall ist die SafeKit-Lastverteilungsregel auf Basis der Identität der TCP-Client-Sitzung konfiguriert. Diese Konfiguration eignet sich am besten für die Verteilung von Sitzungen auf die Server, erfordert jedoch einen TCP-Dienst ohne Sitzungsaffinität.
Wie konfiguriert man ein SafeKit-Cluster im Farm-Modus für Windows/Linux?
Das SafeKit-Cluster im Farm-Modus ist für hohe Verfügbarkeit und Skalierbarkeit von Diensten ausgelegt. Die Konfiguration konzentriert sich darauf, den eingehenden Datenverkehr gleichzeitig auf beide Knoten zu verteilen:
- Lastverteilte Dienste (Registerkarte „Macros“): Definieren Sie die spezifischen Anwendungsdienste (z. B. Apache, IIS, Nginx), die auf allen Knoten aktiv bleiben sollen.
- Heartbeat-Netzwerk(e): Kommunikationspfad(e), über die erkannt wird, ob ein Knoten die Farm verlassen hat, was eine sofortige Neuverteilung der Last auslöst.
- Virtuelle IP (Farm VIP): Im Gegensatz zu einem Spiegel-Cluster (Mirror-Cluster) wird die Farm-VIP mithilfe eines Kernel-Filteralgorithmus zwischen den Knoten geteilt, um den Netzwerkverkehr zu verteilen.
- Lastverteilungsregeln: Definieren Sie die Richtlinie für die Verkehrsverteilung basierend auf der Quell-IP-Adresse oder dem Quell-Port.
- Prüfer (Checkers): Überwachen Sie den Zustand der Anwendung und lösen Sie einen automatischen Neustart aus, wenn ein Prozessfehler erkannt wird.
Wie überwacht man ein SafeKit-Cluster im Farm-Modus für Windows/Linux?
Die Überwachung eines Clusters im Farm-Modus bietet Einblick in die Aktiv-Aktiv (Active-Active) -Natur der Infrastruktur, bei der alle Knoten zur Leistung der Anwendung beitragen (in diesem Beispiel werden 2 Knoten gezeigt):
- UP-Zustand (50 % auf 2 Knoten): In einer gesunden Farm befinden sich beide Knoten im „UP“-Zustand (50 %), was bedeutet, dass beide aktiv Client-Anfragen über die gemeinsame virtuelle IP-Adresse empfangen und verarbeiten.
- Automatische Neuausbalancierung: Wenn ein Knoten ausfällt, zeigt die Konsole visuell an, dass der verbleibende Knoten 100 % des Datenverkehrs übernimmt. Es gibt keine „Failover“-Verzögerung, da der überlebende Knoten bereits aktiv ist (abgesehen von einer Erkennungszeit von wenigen Sekunden).
- Knoten-Einfügung: Wenn ein reparierter Knoten neu gestartet wird, wechselt er vom Zustand „STOP“ in den Zustand „UP“ und beginnt automatisch, seinen Anteil an der Last zu übernehmen, ohne dass ein Administrator eingreifen muss.
- Keine Datensynchronisation: Beachten Sie, dass es in einem Cluster im Farm-Modus keinen „orangefarbenen“ Resynchronisationszustand gibt, da die Knoten in der Regel zustandslos (stateless) sind oder eine gemeinsame Backend-Datenbank nutzen (die separat in einem Spiegel-Cluster geschützt werden kann).
Neben einfachen Statussymbolen bietet die Benutzeroberfläche ein Knotenmanagement mit einem Klick. So können Sie einen Knoten für geplante Wartungsarbeiten manuell stoppen oder starten, während die gemeinsame virtuelle IP-Adresse den Datenverkehr automatisch neu verteilt, ohne die Aktivitäten der Benutzer zu unterbrechen.
Vergleich von SafeKit mit herkömmlichen Hochverfügbarkeits- (HA-) Clustern
Dieser Vergleich zeigt die grundlegenden Unterschiede zwischen SafeKit und traditionellen Hochverfügbarkeits-Clusterlösungen (HA) wie Failover-Cluster, Virtualisierungs-HA und SQL Always-On. SafeKit ist als einfache, rein softwarebasierte Lösung für generische Anwendungsredundanz konzipiert – im Gegensatz zur hohen Komplexität und den spezifischen Speicheranforderungen (Shared Storage, SAN) traditioneller HA-Mechanismen.
Vergleich von SafeKit mit traditionellen Hochverfügbarkeits-Clustern (HA)
| Lösungen | Komplexität | Anmerkungen |
|---|---|---|
| Failover-Cluster (Microsoft) | Hoch | Spezifischer Speicher (Shared Storage, SAN) |
| Virtualisierung (VMware HA) | Hoch | Spezifischer Speicher (Shared Storage, SAN, vSAN) |
| SQL Always-On (Microsoft) | Hoch | Nur SQL ist redundant, erfordert SQL Enterprise Edition |
| SafeKit | Niedrig | Am einfachsten, generisch und rein softwarebasiert. Nicht geeignet für die Replikation großer Datenmengen. |
Zusammenfassend erreicht SafeKit eine Hochverfügbarkeit mit geringer Komplexität durch einen einfachen, softwarebasierten Spiegelungsmechanismus, der teure, dedizierte Hardware wie ein SAN (Storage Area Network) überflüssig macht. Dies macht es zu einer leicht zugänglichen Lösung, um Anwendungsredundanz schnell zu implementieren – ohne komplexe Infrastrukturänderungen.
Architektonische Unterscheidungsmerkmale: SafeKit Software-Defined vs. Hardware HA Cluster
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 | • 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 | • 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 | • 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). • 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-Modulehyperv.safeoderkvm.safe). Hypervisoren arbeiten Aktiv/Aktiv mit mehreren virtuellen Maschinen. |
| Hochverfügbarkeit vs. Fehlertoleranz (Fault Tolerance) | • Kein dedizierter Server mit SafeKit. JederServer kann als Failover-Server des anderen dienen. • 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 | • 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 | • 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 | • 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 | • 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.
Schlüssel-Differenzierungsmerkmale des SafeKit Mirror Clusters
Die Wahl des richtigen Ansatzes zur Datenreplikation ist entscheidend für die Sicherstellung der Geschäftskontinuität. Dieser Vergleich hebt die wichtigsten Unterscheidungsmerkmale des SafeKit Mirror-Clusters mit Echtzeit-Dateireplikation gegenüber traditionellen Alternativen wie Datenbankreplikation, Festplattenreplikation, Shared-Disk-Lösungen und fehlertoleranten Systemen hervor.
SafeKit Mirror-Cluster: Vorteile gegenüber alternativen Replikations- und Clustering-Ansätzen
| Merkmal | SafeKit-Vorteil | Einschränkung der Alternativen |
|---|---|---|
| 3 Produkte in 1 | Spart unter Windows und Linux die Kosten für externen gemeinsamen/replizierten Speicher, Load-Balancing-Geräte und Enterprise-Editionen von Betriebssystemen und Datenbanken. Enthält alle Cluster-Funktionen: synchrone Echtzeit-Dateireplikation, Störungsüberwachung, automatischer Neustart, virtueller IP-Failover. | Traditionelle Ansätze erfordern separate Produkte für Speicherreplikation, Lastverteilung und Clustering — was Kosten und Komplexität erhöht. |
| Sehr einfache Konfiguration | Konfiguration über Anwendungsmodule. Neue Dienste und replizierte Verzeichnisse können einfach hinzugefügt werden. Alles wird über eine zentrale Webkonsole verwaltet. Kein Domänencontroller oder Active Directory erforderlich. | Microsoft Cluster und ähnliche Lösungen erfordern eine komplexe Active-Directory-Konfiguration und Domänencontroller. |
| Synchrone Replikation | Die Echtzeit-Replikation ist synchron ohne Datenverlust bei Ausfall (RPO = 0). | Asynchrone Replikation kann kürzlich durchgeführte Transaktionen verlieren, die zum Zeitpunkt des Ausfalls noch nicht repliziert wurden. |
| Vollautomatisches Failback | Nach einem Ausfall, wenn ein Server neu startet, ist das Replikations-Failback vollautomatisch. Der ausgefallene Server wird ohne Stopp der Anwendung auf dem verbleibenden Server wieder in den Cluster integriert. | Die meisten Replikationslösungen (insbesondere auf Datenbankebene) erfordern eine manuelle Resynchronisation. Die Anwendung kann während des Failbacks sogar gestoppt werden. |
| Replikation aller Datentypen | Die Replikation funktioniert für Datenbanken und für alle Dateien, die repliziert werden müssen. | Replikation auf Datenbankebene schützt nur die Datenbank, nicht Konfigurationsdateien, Protokolle oder andere Anwendungsdaten. |
| Dateireplikation vs. Festplattenreplikation | Die Replikation basiert auf Dateiverzeichnissen, die sich überall befinden können, sogar auf der Systemfestplatte. | Festplattenreplikation erfordert eine dedizierte Partition und eine spezielle Anwendungskonfiguration zur Datenspeicherung. |
| Dateireplikation vs. Shared Disk | Server können an zwei entfernten Standorten ohne gemeinsame Infrastruktur eingesetzt werden. | Shared-Disk-Lösungen erfordern physische Nähe und können keine entfernten Standorte abdecken. |
| Entfernte Standorte und virtuelle IP | Alle Cluster-Funktionen funktionieren für 2 Server an entfernten Standorten. Extended LAN ermöglicht VIP-Umleitung auf Schicht 2. Für unterschiedliche IP-Netzwerke wird die VIP über einen Load Balancer mit SafeKit Health Check verwaltet. | Viele Clustering-Lösungen unterstützen kein Failover an entfernten Standorten oder erfordern eine komplexe DNS-Umleitung mit unvorhersehbaren Wiederherstellungszeiten. |
| Quorum und Split Brain | Funktioniert mit nur 2 Servern. Ein einfacher Split-Brain-Checker zu einem Router bewältigt die Netzwerkisolation zwischen Standorten. | Die meisten Clustering-Lösungen erfordern einen 3. Server für das Quorum-Management. |
| Aktiv/Aktiv-Cluster | Der sekundäre Server ist nicht dediziert. Der Cluster kann mit 2 verschiedenen Mirror-Modulen aktiv/aktiv betrieben werden. | Fehlertolerante Systeme widmen den sekundären Server der Ausführung derselben Anwendung, synchronisiert auf Befehlsebene. |
| Einheitliche HA-Lösung | SafeKit implementiert sowohl Mirror-Cluster (Replikation + Failover) als auch Farm-Cluster (Lastverteilung + Failover). Eine N-Tier-Architektur kann mit einer einzigen Lösung auf Windows und Linux hochverfügbar gemacht werden. | Typische Architekturen mischen verschiedene Technologien für Lastverteilung, Replikation und Failover — was die betriebliche Komplexität erhöht. |
| RTO / RPO | Schneller Neustart der Anwendung bei Ausfall: etwa 1 Minute oder weniger. Kein Datenverlust (synchrone Replikation). | Vollständige VM-Replikation (VMware HA, Hyper-V Cluster) erfordert den Neustart des gesamten Betriebssystems auf einem neuen Hypervisor, was zu längeren Wiederherstellungszeiten führt. |
Zusammenfassend bietet der SafeKit Mirror-Cluster eine einheitliche, kosteneffiziente Hochverfügbarkeitslösung, die synchrone Dateireplikation, automatisches Failover und Failback, Lastverteilung und Unterstützung entfernter Standorte vereint — alles ohne dedizierte Hardware, gemeinsamen Speicher oder einen dritten Quorum-Server. Diese Einfachheit macht ihn besonders geeignet für Softwarehersteller und Organisationen, die zuverlässige HA auf Standard-Windows- und Linux-Servern benötigen.
Schlüssel-Differenzierungsmerkmale des SafeKit Farm Clusters
Das SafeKit Farm Cluster ist eine Hochverfügbarkeitslösung, die speziell für skalierbare Anwendungsumgebungen entwickelt wurde, in denen Lastverteilung und schnelles Failover unverzichtbar sind. Im Gegensatz zu herkömmlichen Methoden, die dedizierte Hardware-Load-Balancer oder komplexe Netzwerkkonfigurationen erfordern, bietet SafeKit eine integrierte, softwarebasierte Clusterlösung, die direkt auf den Anwendungsservern installiert wird. Die folgende Tabelle beschreibt die Kernfunktionen und einzigartigen Vorteile des SafeKit Farm Clusters und zeigt, wie es die Netzwerk-Lastverteilung vereinfacht und eine kontinuierliche Dienstverfügbarkeit auf Windows- und Linux-Plattformen sicherstellt.
Wichtigste Alleinstellungsmerkmale des SafeKit Farm Clusters mit Lastverteilung und Failover
| Vorteil | Detaillierter Nutzen und Mechanismus |
|---|---|
| Kein Load Balancer, keine dedizierten Proxy-Server oder spezielle Multicast-Ethernet-Adresse | • Die Lösung erfordert keine Load Balancer oder dedizierten Proxy-Server oberhalb der Farm für die Lastverteilung. SafeKit wird direkt auf den Anwendungsservern in der Farm installiert. Die Lastverteilung basiert auf einer standardmäßigen virtuellen IP-Adresse/Ethernet-MAC-Adresse und funktioniert mit physischen Servern oder virtuellen Maschinen unter Windows und Linux ohne spezielle Netzwerkkonfiguration • Dies ist bei Netzwerk-Load-Balancern nicht der Fall • Dies ist bei dedizierten Proxies unter Linux nicht der Fall • Dies ist bei einerspeziellen Multicast-Ethernet-Adresseunter Windows nicht der Fall |
| Alle Cluster-Funktionen | • Die Lösung umfasst alle Cluster-Funktionen: virtuelle IP-Adresse, Lastverteilung nach Client-IP-Adresse oder nach Sitzungen, Überwachung von Server-/Netzwerk-/Softwareausfällen, automatischer Neustart der Anwendung mit kurzer Wiederherstellungszeit und eineReplikationsoption mit einem Spiegelmodul • Dies ist bei anderen Lastverteilungslösungen nicht der Fall. Sie können Lastverteilung durchführen, enthalten aber keine vollständige Clusterlösung mit Neustartskripten und automatischem Anwendungsneustart bei Ausfällen. Sie bieten keine Replikationsoption • Die Clusterkonfiguration ist sehr einfach und erfolgt überAnwendungsmodule. Unter Windows muss kein Domänencontroller oder Active Directory konfiguriert werden. Die Lösung funktioniert unter Windows und Linux |
| Entfernte Standorte und virtuelle IP-Adresse | • Wenn Server über ein erweitertes LAN zwischen entfernten Standorten mit demselben IP-Netzwerk verbunden sind, funktioniert dievirtuelle IP-Adressevon SafeKit mit Lastverteilung auf Ebene 2 • Wenn Server mit verschiedenen IP-Netzwerken zwischen entfernten Standorten verbunden sind, kann die virtuelle IP-Adresse auf der Ebene eines Load Balancers mithilfe des SafeKit Health Checks konfiguriert werden. So können Sie Lastverteilung implementieren, aber auch alle Cluster-Funktionen von SafeKit nutzen, insbesondere die Überwachung und automatische Wiederherstellung der kritischen Anwendung auf den Anwendungsservern |
| Einheitliche Hochverfügbarkeitslösung | • SafeKit implementiert ein Farm-Cluster mit Lastverteilung und Failover. Aber es implementiert auch einSpiegel-Cluster mit Replikation und Failover. • Somit kann eine N-Tier-Architektur mit derselben Lösung unter Windows und Linux hochverfügbar und lastverteilt gemacht werden (gleiche Installation, Konfiguration, Administration mit der SafeKit-Konsole oder der Befehlszeilenschnittstelle). Dies ist einzigartig auf dem Markt • Dies ist bei einer Architektur, die verschiedene Technologien für Lastverteilung, Replikation und Failover kombiniert, nicht der Fall |
Zusammenfassend bietet das SafeKit Farm Cluster einen einheitlichen, softwarebasierten Ansatz für Lastverteilung und Hochverfügbarkeit, der Komplexität und Kosten drastisch reduziert. Durch die Integration von Lastverteilung und Failover direkt in die Anwendungsserverschicht mittels einer standardmäßigen virtuellen IP-Adresse entfällt die Notwendigkeit externer Netzwerkhardware (Load Balancer oder Proxies) und spezieller Multicast-Konfigurationen. Dieser integrierte Ansatz, kombiniert mit der Möglichkeit, ihn mit dem Spiegel-Cluster für vollständige N-Tier-HA zu kombinieren, macht SafeKit zu einer einzigartig einfachen und umfassenden Lösung für eine skalierbare und ausfallsichere Anwendungsbereitstellung in verschiedensten Umgebungen.
VM-Hochverfügbarkeit: SafeKits SAN-lose vs. Hyper-V/VMware HA
Bei der Implementierung von Hochverfügbarkeit ist eine zentrale Entscheidung, ob auf der Ebene der virtuellen Maschine (VM) oder auf der Anwendungsebene geschützt werden soll. VM-Ebene HA repliziert und failt komplette virtuelle Maschinen über und bietet eine generische Lösung für jede Anwendung. Anwendungsebene HA zielt nur auf die Anwendungsdaten und -dienste ab, was zu schnelleren Wiederherstellungszeiten und geringerem Ressourcenverbrauch führt. SafeKit bietet als einzige Lösung beide Ansätze — ohne in beiden Fällen gemeinsamen Speicher (SAN) zu benötigen — sodass Sie die beste Lösung für Ihre Infrastruktur und Wiederherstellungsanforderungen wählen können.
SafeKit VM HA vs. Anwendungs-HA vs. traditioneller Hyper-V Cluster & VMware HA
| Kriterium | VM HA mit SafeKit Hyper-V oder KVM Modul | Anwendungs-HA mit SafeKit Anwendungsmodulen | Microsoft Hyper-V Cluster & VMware HA |
|---|---|---|---|
| Architektur | SafeKit in 2 Hypervisoren installiert. Replikation und Failover der vollständigen VM. | SafeKit in 2 virtuellen oder physischen Maschinen installiert. Replikation und Failover auf Anwendungsebene. | Hypervisor-Cluster mit gemeinsamem Speicher. VM-Neustart auf einem anderen Host bei Hypervisor-Ausfall. |
| Speicher | Keine gemeinsame Festplatte — synchrone Echtzeit-Replikation ohne Datenverlust | Keine gemeinsame Festplatte — synchrone Replikation nur der Anwendungsdaten | Erfordert eine gemeinsame Festplatte und ein spezielles externes Festplattengehäuse |
| Replizierte Daten | Repliziert mehr Daten (Anwendung + Betriebssystem) | Repliziert nur Anwendungsdaten | Keine Replikation — gemeinsamer Speicher, auf den alle Hosts zugreifen |
| Wiederherstellungszeit | Neustart der VM auf Hypervisor 2, wenn Hypervisor 1 ausfällt. Wiederherstellungszeit = Zeit zum Neustart der VM. Failover bei VM-Absturz. | Schnelle Wiederherstellung mit Neustart der Anwendung auf Server 2. Etwa 1 Minute oder weniger (siehe RTO/RPO hier). Erweiterte Anwendungsprüfung und Software-Failover. | Vollständiger VM-Neustart auf einem neuen Hypervisor. Wiederherstellungszeit abhängig von Betriebssystem-Neustart + Anwendungsstart. |
| Disaster Recovery / Entfernte Standorte | Kein SAN erforderlich — Replikation in SafeKit über entfernte Standorte integriert | Kein SAN erforderlich — Replikation in SafeKit über entfernte Standorte integriert | Erfordert replizierte Festplattengehäuse über ein SAN oder vSAN |
| Konfiguration | Speicherort des VM-Dateiordners definieren, in dem die Anwendung installiert ist. Generische Lösung für jede Anwendung/jedes Betriebssystem. | Zu startende Dienste, zu replizierende Anwendungsordner und eine virtuelle IP-Adresse für Failover in einem Anwendungsmodul definieren. | Spezifische IT-Kenntnisse zur Konfiguration des Systems erforderlich |
| Unterstützte Plattformen | Funktioniert mit Hyper-V und KVM (nicht direkt VMware, außer durch Verschachtelung von Hyper-V oder KVM in VMware). | Funktioniert in jeder Infrastruktur: physische Server, VMware, Hyper-V, KVM virtuelle Maschinen, Cloud. | Auf VMware vSphere oder Microsoft Hyper-V Umgebungen beschränkt |
| IT-Kenntnisse | Keine speziellen IT-Kenntnisse erforderlich. Automatisches Failover. | Keine speziellen IT-Kenntnisse erforderlich. Automatisches Failover. | Spezifische IT-Kenntnisse zur Konfiguration des Systems erforderlich |
Zusammenfassend ist SafeKit die einzige Lösung, die sowohl VM-Ebene als auch Anwendungsebene Hochverfügbarkeit ohne gemeinsamen Speicher bietet. Für maximale Flexibilität und schnellste Wiederherstellungszeiten (etwa 1 Minute) ist Anwendungsebene HA der bevorzugte Ansatz — er funktioniert auf jeder Plattform (physisch, virtuell oder Cloud) und repliziert nur die relevanten Daten. Für Umgebungen, in denen der Schutz der gesamten VM einfacher ist, bietet SafeKits Hyper-V/KVM-Modul eine generische, SAN-lose Alternative zum traditionellen Microsoft Hyper-V Cluster oder VMware HA — und eliminiert die Kosten und Komplexität gemeinsamer Speicherinfrastruktur bei gleichzeitiger Garantie von null Datenverlust durch synchrone Echtzeit-Replikation.
Beachten Sie, dass SafeKit-Lösungen am einfachsten zu implementieren sind, aber auf die Replikation von einigen Terabyte und das Failover von 32 VMs beschränkt sind.
SafeKit HA Kostenlose Testversion & Technische Dokumentation
💡 Um Ihre High-Availability-Reise mit SafeKit zu beginnen, starten Sie mit den Schnellinstallationsanleitungen.
📦 SafeKit HA-Softwarepakete - Version 8.2
Diese Tabelle enthält die SafeKit-Installationsdateien für die aktuelle Version, organisiert nach Betriebssystem und Installationstyp.
| BS / Plattform | Installationstyp | Hauptvorteil / Dokumentation | Download-Link |
|---|---|---|---|
| Alle Plattformen | PDF-Dokument | Offizielles Software Release Bulletin (BS-Unterstützung & Fixes) | 📄 SafeKit 8.2 SRB anzeigen |
| Windows (Intel 64-Bit) | .exe Installer | Enthält Microsoft VC++ Redistributable | ⬇️ SafeKit 8.2 Windows EXE herunterladen |
| Windows (Intel 64-Bit) | .msi Installer | Enthält kein Microsoft VC++ Redistributable | ⬇️ SafeKit 8.2 Windows MSI herunterladen |
| Linux (Intel 64-Bit) | Selbstentpackende .BIN | Enthält Linux-Paket und Installationsskript | ⬇️ SafeKit 8.2 Linux BIN-Datei (Intel) herunterladen |
| Linux (ARM 64-Bit) | Selbstentpackende .BIN | Enthält Linux-Paket und Installationsskript | ⬇️ SafeKit 8.2 Linux BIN-Datei (ARM) herunterladen |
🔑 SafeKit’s HA Testschlüssel
Der folgende Link bietet Zugang zu einer voll funktionsfähigen Testversion, die zum Testen und Einrichten eines High Availability Clusters mit SafeKit entwickelt wurde.
➡️ Holen Sie sich Ihren kostenlosen 1-Monats-Testschlüssel, um SafeKit’s High Availability zu testen
📚 SafeKit-Konfigurationsanleitungen für Ihren HA-Cluster
Wichtige Dokumentation zur Einrichtung und Verwaltung Ihres SafeKit High-Availability-Clusters.
- SafeKit Quick Installation Guides
- SafeKit-Benutzerhandbuch in HTML (Version 8.2) / PDF herunterladen
- SafeKit-Versionshinweise in HTML (Version 8.2) / PDF herunterladen
- SafeKit 8.2 Software Release Bulletin (SRB)
- SafeKit Knowledge Base
📞/🤖 SafeKit Support
🎓 Kostenlose Schulung und Zertifizierung zu SafeKit
Erwerben Sie wertvolles Fachwissen in High Availability (HA) mit unserem kostenlosen Zertifizierungsprogramm.
ℹ️ Produktmarketing-Dokumentation
Entdecken Sie unsere Produktmarketing-Dokumentation für die SafeKit-High-Availability-(HA)-Software, einschließlich eines detaillierten Datenblatts, eines Produkt-Whitepapers und einer technischen Übersicht.
- Datenblatt zum SafeKit High Availability Cluster (PDF)
- Whitepaper – Technologie für High-Availability-Cluster (PDF)
- Whitepaper – Leitfaden zur Hochverfügbarkeit (PDF)
- Technische Referenz für RFI und RFP
SafeKit Anwendungsmodul-Bibliothek: sofort einsetzbare HA-Lösungen
Diese Tabelle zeigt die SafeKit High-Availability-(HA)-Lösungen, kategorisiert nach Anwendung und Betriebsumgebung (Datenbanken, Webserver, VMs, Container, Cloud). Ermitteln Sie das passende vorkonfigurierte .safe-Modul (z. B. mirror.safe, farm.safe u. a.), das für Echtzeit-Replikation, Lastverteilung und automatisches Failover geschäftskritischer Anwendungen unter Windows oder Linux erforderlich ist. Vereinfachen Sie die Einrichtung Ihres HA-Clusters mit direkten Links zu Schnellinstallationsleitfäden.
Ein SafeKit-.safe-Modul ist im Wesentlichen eine vorkonfigurierte High-Availability-(HA)-Vorlage, die definiert, wie eine bestimmte Anwendung mit der SafeKit-Software geclustert und geschützt wird. In der Praxis ist es eine ZIP-Datei, die eine Konfigurationsdatei (userconfig.xml) und Neustartskripte enthält.
⚠️ Hinweis: * Die Module mirror.safe und farm.safe sind standardmäßig im SafeKit-Installationspaket enthalten.
SafeKit High-Availability-(HA)-Lösungen: Schnellinstallationsleitfäden (mit herunterladbaren .safe-Modulen)
