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

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.

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.

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.