SafeKit: All-in-One-Software für SAN-lose Hochverfügbarkeit und Anwendungsclustering

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

Nein. SafeKit ist einfach bereitzustellen – es sind keine fortgeschrittenen Fachkenntnisse erforderlich.

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.

Nein. SafeKit funktioniert mit Standard-Editionen von Windows und Linux und benötigt keine Enterprise-Datenbanklizenzen.

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

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

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

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.

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.

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.

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).

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:

1. Daten resynchronisieren: Dies geschieht im Hintergrund vom aktiven Knoten zum wiederhergestellten Knoten.
2. Betriebszeit aufrechterhalten: Diese Resynchronisation muss erfolgen, ohne die aktuell auf dem aktiven Knoten laufende Anwendung zu unterbrechen.
3. 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.

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.

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.

• 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.

• 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.

• 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.

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 einen SafeKit Mirror-Cluster konfigurieren, um die Geschäftskontinuität zu gewährleisten:

• Anwendungs-Failover (Registerkarte Makros): Definieren Sie die spezifischen Anwendungsdienste, die im Falle eines Fehlers automatisch neu gestartet werden sollen.
• Heartbeat-Netzwerk(e): Dedizierte Kommunikationspfade, die von den Clusterknoten genutzt werden, um gegenseitig den Zustand und die Verfügbarkeit kontinuierlich zu überwaken und Failover-Entscheidungen zu synchronisieren.
• Virtuelles IP-Management: Richten Sie die virtuelle IP (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.

Der SafeKit-Cluster enthält einen speziellen Split-Brain-Checker, um Netzwerkisolationsprobleme zu lösen, ohne dass ein dritter Zeugenserver (Witness) oder ein zusätzliches Heartbeat-Netzwerk erforderlich ist. Erfahren Sie mehr über Stromausfall und Netzwerkisolation in einem Cluster.

Die SafeKit-Managementkonsole bietet eine zentrale Ansicht Ihrer Hochverfügbarkeits-Infrastruktur. Sie ermöglicht es Administratoren, den Betriebszustand 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 übersichtlich an:

• PRIM (Primary): Der aktive Knoten, auf dem die Anwendung derzeit ausgeführt wird und der die virtuelle IP verwaltet. Er schreibt auf den lokalen Speicher und führt die Echtzeit-Replikation auf den sekundären Knoten durch.
• SECOND (Secondary): Der Standby-Knoten, der synchrone Updates auf Byte-Ebene empfängt. Er ist bereit, bei einem Ausfall des Primärknotens sofort zu übernehmen.
• Zustand ALONE: Warnt Sie visuell, wenn der Cluster auf nur einem 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 Resynchronisierung: Wenn ein ausgefallener Knoten wiederhergestellt wird, wechselt sein Status während der Datenreintegration im Hintergrund auf Orange. Dies gewährleistet einen unterbrechungsfreien Betrieb während der Phase der „Rückkehr zum Normalzustand“.

Über einfache Statussymbole hinaus bietet die Benutzeroberfläche eine Failover-Orchestrierung per Mausklick. So können Sie für geplante Wartungsarbeiten die Rollen (Primär/Sekundär) manuell tauschen, ohne die Benutzeraktivitäten zu unterbrechen.

Der SafeKit Farm-Cluster ist für hohe Verfügbarkeit und Skalierbarkeit von Diensten konzipiert. 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): Kommunikationspfade, die verwendet werden, um festzustellen, ob ein Knoten die Farm verlassen hat, was eine sofortige Neuverteilung der Last auslöst.
• Virtuelle IP (Farm VIP): Im Gegensatz zu einem Mirror-Cluster wird die Farm VIP von den Knoten gemeinsam genutzt, wobei ein Kernel-Filteralgorithmus zur Verteilung des Netzwerkverkehrs eingesetzt wird.
• Lastverteilungsregeln: Definieren Sie die Richtlinien für die Verkehrsverteilung basierend auf der Quell-IP-Adresse oder dem Port.
• Checkers (Prüfmodule): Überwachen den Zustand der Anwendung und lösen einen automatischen Neustart aus, wenn ein Prozessfehler erkannt wird.

Das Monitoring eines Farm-Clusters bietet Einblick in die 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 Zustand „UP“ (50 %), was bedeutet, dass beide aktiv Client-Anfragen über die gemeinsame virtuelle IP empfangen und verarbeiten.
• Automatische Lastumverteilung: 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-Integration: Wenn ein reparierter Knoten neu gestartet wird, wechselt er von „STOP“ zu „UP“ und beginnt automatisch, seinen Anteil an der Last zu empfangen, ohne dass ein Eingreifen des Administrators erforderlich ist.
• Keine Datensynchronisation: Beachten Sie, dass es in einem Farm-Cluster keinen „orangenen“ Resynchronisationszustand gibt, da die Knoten in der Regel zustandslos sind oder eine Backend-Datenbank gemeinsam nutzen (die separat in einem Mirror-Cluster geschützt werden kann).

Über einfache Statussymbole hinaus bietet die Schnittstelle ein Knotenmanagement mit einem Klick. Dies ermöglicht es Ihnen, einen Knoten für geplante Wartungsarbeiten manuell zu stoppen oder zu starten, während die gemeinsame virtuelle IP den Datenverkehr automatisch neu verteilt, ohne die Benutzeraktivität zu unterbrechen.