--- title: "K3S Hochverfügbarkeit mit SafeKit: Installieren Sie das Modul k3s.safe für Failover" canonical: "https://safekit.eviden.com/de/quick-install/safekit-quick-installation-guide-with-kubernetes/" description: "Setzen Sie das k3s.safe-Modul für SafeKit ein, um die synchrone Echtzeitreplikation und das automatische Failover von Kubernetes unter Linux zu ermöglichen. Diese Anleitung führt Sie durch die Einrichtung eines SANless-Clusters mit 2 Knoten für kritische Linux Anwendungen ohne gemeinsam genutzten Speicher." category: "quick-install" lang: "de" topics: "Schnellinstallationsanleitung für Hochverfügbarkeit für Kubernetes, Einschränkungen SafeKit Hochverfügbarkeit, Übersicht über die SafeKit/Kubernetes-Lösung, Installation und Konfiguration der SafeKit/Kubernetes-Lösung unter Linux (k3s.safe), Welche verschiedenen Szenarien gibt es bei Netzwerktrennung in einem Cluster?, Demonstration der SafeKit mirror" translation: "translate_md 2026-11-08.15 | glossaire 2026-11-09.11 | Translation LLM | 40 expressions" --- # K3S Hochverfügbarkeit mit SafeKit: Installieren Sie das Modul k3s.safe für Failover {#k3s-high-availability-with-safekit-install-the-k3ssafe-module-for-failover} ## Schnellinstallationsanleitung für Hochverfügbarkeit für Kubernetes {#quick-guide} Diese Anleitung erklärt, wie Sie mit SafeKit einen **Mirror-Cluster** für Kubernetes einrichten, der ein automatisches Failover und eine synchrone Replikation ohne die Notwendigkeit eines gemeinsam genutzten Speichers gewährleistet. Für Hilfe können Sie [SafeKit AI 🤖](https://safekit.eviden.com/de/resources/safekit-support/) nutzen. ### 1. Überblick {#1-overview} * **Architektur:** Verwendet ein Zwei-Knoten-System (primär/sekundär). * **Datenschutz:** Implementiert synchrone Replikation in Echtzeit für **null Datenverlust** (RPO = 0). ### 2. Installation {#2-installation} * **Software:** Installieren Sie die SafeKit-Engine auf beiden Servern. * **Modul:** Laden Sie das vorkonfigurierte `k3s.safe` Anwendungsmodul herunter. ### 3. Konfiguration {#3-configuration} * **Webkonsole:** Konfigurieren Sie die spezifischen Ordner, die die Kubernetes Dateien enthalten. * **Überwachung:** Starten Sie die Überwachung und den Schutz der Kubernetes Anwendung. ## 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. ## Übersicht über die SafeKit/Kubernetes-Lösung {#overview-of-the-safekit--kubernetes-solution} Die Lösung wird hier beschrieben: **💡 [Kubernetes K3s Hochverfügbarkeit: Synchrone Replikation und Failover mit 2 Knoten]()** ## Installation und Konfiguration der SafeKit/Kubernetes-Lösung unter Linux (k3s.safe) {#installation-and-configuration-of-the-safekit--kubernetes-solution-on-linux-k3ssafe} ### 1. Pakete herunterladen {#1-download-packages} * Laden Sie die kostenlose Version von SafeKit 8.2 für Linux (safekitlinux_xx.bin) herunter * Laden Sie das k3s.safe Linux-Modul herunter * Laden Sie das Skript k3sconfig.sh herunter * Dokumentation (pptx) Hinweis: Das Skript k3sconfig.sh installiert K3S, MariaDB, NFS und SafeKit auf 2 Linux Ubuntu 24.04-Knoten. [SafeKit (Linux) herunterladen >]() k3s.safe (Linux) herunterladen > [k3sconfig.sh herunterladen >]() [Dokumentation (PDF) >]() ### 2. Zuerst auf beiden Knoten {#2-first-on-both-nodes} Auf 2 Linux Ubuntu 24.04-Knoten als Root: * Stellen Sie sicher, dass der Knoten über Internetzugang verfügt (dies kann auch über einen Proxy erfolgen) * Kopieren Sie k3sconfig.sh, k3s.safe und das Paket safekit_xx.bin in ein Verzeichnis und wechseln Sie mit cd in dieses Verzeichnis * Benennen Sie die .bin-Datei in „safekit.bin“ um * Stellen Sie sicher, k3sconfig.sh und safekit.bin ausführbar sind. * Bearbeiten Sie das Skript k3sconfig.sh und passen Sie die Umgebungsvariablen an Ihre Umgebung an (einschließlich einer virtuellen IP-Adresse) * Auf beiden Knoten ausführen: `./k3sconfig.sh prereq` Das Skript wird: * Installieren Sie die erforderlichen Debian-Pakete: alien, nfs-kernel-server, nfs-common, mariadb-server * Sichere MariaDB-Installation * Verzeichnisse für die Dateireplikation erstellen * Bereiten Sie den NFS-Server für die gemeinsame Nutzung replizierter Verzeichnisse vor * SafeKit installieren ### 3. Auf dem ersten Knoten {#3-on-the-first-node} Auf dem ersten Knoten ausführen: `./k3sconfig.sh first` Das Skript wird: * Erstellen Sie die K3S-Konfigurationsdatenbank und den K3S-Benutzer * Erstellen Sie die Replikationsspeichervolumendatei (Sparse-Datei) und formatieren Sie sie als xfs-Dateisystem * Erstellen Sie die Safekit-Clusterkonfiguration und wenden Sie sie an * Installieren und konfigurieren Sie das k3s.safe-Modul auf dem Cluster * Starten Sie das k3s-Modul als „prim“ auf dem ersten Knoten * k3s herunterladen, installieren und starten * Laden Sie das Helm-Chart „nfs-subdir-external-provisioner“ herunter und installieren Sie es * K3S-Token anzeigen (wird während der zweiten Installationsphase des Knotens verwendet) ### 4. Auf dem zweiten Knoten {#4-on-the-second-node} Auf dem zweiten Knoten ausführen: `./k3sconfig.sh second ` * ist die Zeichenfolge, die am Ende der Ausführung von „ k3sconfig.sh first“ auf dem ersten Knoten angezeigt wird Das Skript wird: * Stellen Sie sicher, dass das k3s-Modul als prim auf dem ersten Knoten gestartet wird * Installieren Sie k3s auf dem zweiten Knoten * Starten Sie das k3s-Modul ### 5. Überprüfen Sie, ob das k3s SafeKit Modul auf beiden Knoten läuft {#5-check-that-the-k3s-safekit-module-is-running-on-both-nodes} Überprüfen Sie dies mit diesem Befehl auf beiden Knoten: `/opt/safekit/safekit –H "*" state` Die Antwort sollte dem Bild ähneln. /opt/safekit/safekit –H "*" state ---------------- Server= http://10.0.0.20:9010 ---------------- admin action=exec --------------------- k3s-Status --------------------- Lokal (127.0.0.1): PRIM (Dienst: Verfügbar) (Farbe: Grün) Erfolg ---------------- Server= http://10.0.0.21:9010 ---------------- admin action=exec --------------------- k3s-Status --------------------- Lokal (127.0.0.1): SECOND (Dienst: Verfügbar) (Farbe: Grün) Erfolg ### 6. Starten Sie die SafeKit Webkonsole, um den Cluster zu verwalten {#6-start-the-safekit-web-console-to-administer-the-cluster} * Verbinden Sie einen Browser mit der SafeKit-Webkonsolen-URL `http://server0-IP:9010`. * Sie sollten eine Seite sehen, die dem Bild ähnelt. * Überprüfen Sie mit Linux-Befehlszeilen, ob K3S auf beiden Knoten gestartet wurde (gestartet in `start_prim` und `start_second`) und ob MariaDB auf dem primären Knoten gestartet wurde (gestartet in `start_prim`). ![Kubernetes Cluster in der SafeKit Webkonsole gestartet](https://safekit.eviden.com/wp-content/uploads/2024/03/14-monitoring-prim-second.png) ### 7. Testen {#7-testing} * Stoppen Sie den PRIM-Knoten, indem Sie im Kontextmenü nach unten scrollen und auf `Stop` klicken. * Überprüfen Sie, ob auf dem SECOND Knoten ein Failover stattfindet, der ALONE (grün) sein sollte. * Überprüfen Sie mit Befehlszeilen unter Linux das Failover von Diensten (gestoppt auf Knoten 1 im `stop_prim`-Skript und gestartet auf Knoten 2 im `start_prim`-Skript). MariaDB und K3S sollten auf node2 laufen. ![Warnung](https://safekit.eviden.com/wp-content/uploads/2022/07/warning-small.png) Wenn ALONE (grün) auf node2 nicht erreicht wird, analysieren Sie dies mit dem Modulprotokoll von Knoten 2. * Klicken Sie auf `node2`, um das Modulprotokoll anzuzeigen. * [Beispiel für ein SQL Server-Modulprotokoll,]() bei dem der Dienstname in `start_prim` ungültig ist. Der sqlserver.exe-Prozess wird überwacht, aber da er nicht gestartet wird, stoppt das Modul am Ende. ![Warnung](https://safekit.eviden.com/wp-content/uploads/2022/07/warning-small.png) Wenn alles in Ordnung ist, starten Sie einen Start auf node1, wodurch die replizierten Verzeichnisse von node2 erneut synchronisiert werden. Wenn etwas schiefgeht, stoppen Sie node2 und [erzwingen Sie den Start]() von node1 als primären Knoten, der mit seinen lokal intakten Daten zum Zeitpunkt des Stopps neu gestartet wird. ![Hinweis](https://safekit.eviden.com/wp-content/uploads/2022/07/note.png) 🛠️ [Weitere Informationen zu den Tests finden Sie im Benutzerhandbuch.]() ![Stoppen Sie das Modul auf dem PRIM-Server](https://safekit.eviden.com/wp-content/uploads/2024/03/16-monitoring-prim-second-stop.png) ### 8. Testen Sie den Cluster mit einer Kubernetes-Anwendung wie WordPress {#8-try-the-cluster-with-a-kubernetes-application-like-wordpress} Im Bild sehen Sie das Beispiel einer WordPress-Installation: ein Webportal mit einer Backend-Datenbank, die durch Pods implementiert wird. Sie können Ihre eigene Anwendung auf dieselbe Weise bereitstellen. WordPress ist automatisch hochverfügbar: * mit seinen Daten (PHP + Datenbank) in persistenten Volumes, die von SafeKit in Echtzeit repliziert werden * mit einer virtuellen IP-Adresse für den Zugriff auf die WordPress-Website für Benutzer * mit automatischem Failover und automatischer Failback Anmerkungen: * Das WordPress-Chart definiert einen Lastausgleichsdienst, der auf den Ports und lauscht. * WordPress ist über die URL `http://:.` * Die virtuelle IP-Adresse wird von SafeKit verwaltet und im Falle eines Failovers automatisch umgeschaltet. * Standardmäßig implementiert K3S Load Balancer mit Klipper. * Klipper lauscht auf : und leitet die TCP/IP-Pakete an die IP-Adresse und den Port des von ihm ausgewählten WordPress-Pods weiter. $ export KUBECONFIG= /etc/rancher/k3s/k3s.yaml $ helm repo add bitnami https://charts.bitnami.com/bitnami $ helm install my-release bitnami/wordpress --set global.storageClass=nfs-client --set service.ports.http=8099,service.ports.https=4439 Der vorherige Helm-Befehl sollte das WordPress-Image von `registry-1.docker.io` herunterladen. Möglicherweise treten bei `registry-1.docker.io`. Authentifizierungsprobleme auf. In diesem Fall sollten Sie Folgendes tun: * Erstellen Sie auf beiden Knoten `/etc/rancher/k3s/registries.yaml` mit folgendem Inhalt: configs: "registry-1.docker.io": auth: username: your_user_name password: your_password tls: insecure_skip_verify: true * Stoppen und starten Sie k3s, um dies zu berücksichtigen, mit `systemctl stop k3s` und `systemctl start k3s`. * Führen Sie `helm registry login -u your_user_name docker.io` aus und geben Sie dann Ihr Passwort ein ### 9. Unterstützung {#9-support} * Um Unterstützung zu erhalten, erstellen Sie 2 SafeKit `Snapshots` (2 .zip-Dateien), einen für jeden Knoten. ![Hinweis](https://safekit.eviden.com/wp-content/uploads/2022/07/note.png) 🛠️ [Fehlerbehebung im Benutzerhandbuch.]() ![Machen Sie Screenshots zur Unterstützung](https://safekit.eviden.com/wp-content/uploads/2024/03/30-snapshots-mirror.png) ### 10. Konfigurieren Sie bei Bedarf einen Split-Brain-Checker {#10-if-necessary-configure-a-splitbrain-checker} * Siehe unten [„Welche verschiedenen Szenarien gibt es bei Netzwerktrennung in einem Cluster?“,](#isolation) um zu erfahren, ob Sie einen Split-Brain-Checker konfigurieren müssen. * Klicken Sie in der Modulkonfiguration auf `Advanced Configuration` (siehe Abbildung), um `userconfig.xml` zu bearbeiten. * Deklarieren Sie den Split-Brain-Checker, indem Sie ihn im Abschnitt `` der `userconfig.xml` hinzufügen: ... ... * `Save and apply` die neue Konfiguration an, um die geänderte Datei userconfig.xml auf beiden Knoten erneut bereitzustellen (das Modul muss auf beiden Knoten gestoppt werden, um zu speichern und anzuwenden). **Parameter**: * `ident="witness"` identifiziert den Witness mit einem Ressourcennamen: `splitbrain.witness`. Sie können diesen Wert ändern, um den Witness zu identifizieren. * `exec="ping"` verweist auf den auszuführenden Ping-Code. Ändern Sie diesen Wert nicht. * `arg="witness IP"` ist ein Argument für den Ping. Ändern Sie diesen Wert mit der IP-Adresse des Zeugen (ein robustes Element, typischerweise ein Router). ![Geben Sie die Parameter ein](https://safekit.eviden.com/wp-content/uploads/2024/03/05-module-mirror-edit-config.png) ## Welche verschiedenen Szenarien gibt es bei Netzwerktrennung in einem Cluster? {#isolation} ### Ein einziges Netzwerk {#a-single-network} Bei einer Netzwerisisolation ist das Standardverhalten: * Wenn Heartbeats für jeden Knoten verloren gehen, geht jeder Knoten in ALONE und führt die Anwendung mit seiner virtuellen IP-Adresse aus (doppelte Ausführung der Anwendung, die ihre lokalen Daten ändert) * Wenn die Isolation behoben ist, wird ein ALONE Knoten gezwungen, anzuhalten und seine Daten vom anderen Knoten zu resynchronisieren * Am Ende ist der Cluster PRIM-SECOND (oder SECOND-PRIM, je nach Erkennung der doppelten virtuellen IP-Adresse durch Windows). ### Zwei Netzwerke mit einem dedizierten Replikationsnetzwerk {#two-networks-with-a-dedicated-replication-network} Bei einer Netzwerktrennung ist das Verhalten mit einem dedizierten Replikationsnetzwerk wie folgt: * ein dediziertes Replikationsnetzwerk wird in einem privaten Netzwerk implementiert, * Heartbeats im Produktionsnetzwerk gehen verloren (isoliertes Netzwerk), * Heartbeats im Replikationsnetzwerk funktionieren (nicht im isolierten Netzwerk), * Das Cluster verbleibt im PRIM/SECOND Zustand. ### Ein einziges Netzwerk und eine Split-Brain-Checker {#a-single-network-and-a-splitbrain-checker} Bei einer Netzwerktrennung ist das Verhalten mit einem Split-Brain-Checker wie folgt: * Ein Split-Brain-Checker wurde mit der IP-Adresse eines Witness (typischerweise ein Router) konfiguriert, * Der Split-Brain-Checker wird aktiv, wenn ein Server von PRIM auf ALONE oder von SECOND auf ALONE wechselt * Im Falle einer Netzwerktrennung testen beide Knoten die IP-Adresse, bevor sie in ALONE wechseln * Der Knoten, der auf die IP-Adresse zugreifen kann, geht in ALONE, der andere in WAIT * Wenn die Isolation behoben ist, synchronisiert der WAIT Knoten seine Daten neu und wird zu SECOND. Hinweis: Wenn der Witness ausgefallen oder getrennt ist, gehen beide Knoten in WAIT und die Anwendung wird nicht mehr ausgeführt. Deshalb müssen Sie einen robusten Witness wie einen Router wählen. ## Demonstration der SafeKit mirror {#demonstration-of-the-safekit-mirror-solution} ### SafeKit Video: Clustering auf Anwendungsebene (8:47) {#demo-mirror-ha-cluster} In diesem Video erfahren Sie, wie SafeKit einen **mirror HA-Cluster** ohne die Komplexität eines SAN implementiert. Während diese Demonstration Microsoft SQL Server verwendet, funktioniert die Lösung identisch für andere Datenbanken und Anwendungen. ### Kapitel {#chapters} 1. 🎬 [2 Knoten mit SQL Server](https://www.youtube.com/watch?v=mGwEguDnnH0&t=0s) (0:32) 2. 🎬 [Konfigurieren Sie den Cluster und das Modul mirror.safe](https://www.youtube.com/watch?v=mGwEguDnnH0&t=32s) (3:58) 3. 🎬 [SQL-Replikation, -Migration und Failover bei Absturz starten und testen](https://www.youtube.com/watch?v=mGwEguDnnH0&t=270s) (4:17) ### Schritt-für-Schritt-Implementierung {#step-by-step-implementation} * 🛠️ [Lies die Anleitung zum Einrichten eines Mirror-Clusters unter Windows](https://safekit.eviden.com/de/quick-install/safekit-quick-installation-guide-for-a-new-windows-application-with-real-time-replication-and-failover/) * 🛠️ [Lies den Leitfaden zum Einrichten eines Mirror-Clusters unter Linux](https://safekit.eviden.com/de/quick-install/safekit-quick-installation-guide-for-a-new-linux-application-with-real-time-replication-and-failover/)