Redundanz und Ausfallverhalten

Überblick

Redundanz entsteht in EasyUC auf zwei Ebenen. Die Kubernetes-Control-Plane mit etcd übersteht bei drei Nodes den Ausfall eines Nodes. Longhorn hält Kopien der Volumes auf mehreren Nodes.

Die Anwendung und die Datendienste laufen dagegen in jeweils einer Instanz. Fällt ein Node aus, startet Kubernetes die betroffenen Dienste auf einem anderen Node neu. Das ist eine Wiederherstellung durch Neustart, kein unterbrechungsfreies Failover.

Control Plane und etcd-Quorum

etcd speichert den Zustand des Kubernetes-Clusters. Jeder EasyUC-Node ist ein Server-Node und damit Mitglied im etcd-Cluster. Die Control Plane bleibt funktionsfähig, solange die Mehrheit dieser Mitglieder verfügbar ist.

Bei drei Nodes sind das zwei. Fällt ein Node aus, arbeiten die beiden anderen weiter. Mit zwei Nodes gewinnen Sie keine Ausfallsicherheit, weil nach einem Ausfall die Mehrheit fehlt. Die Übersicht dazu steht unter Warum drei Nodes.

Longhorn-Replikate

Longhorn hält Kopien der Volumes auf mehreren Nodes. Fällt ein Node aus, liegt auf einem anderen Node ein Replikat, das Longhorn dort anhängen kann. Solange ein Node fehlt, zeigt Longhorn betroffene Volumes als degraded an.

Auf einem einzelnen Node sind die Volumes nicht redundant. Den Zustand aller Volumes sehen Sie im Manager.

Was beim Ausfall eines Nodes passiert

Kubernetes und Longhorn stellen die Dienste ohne Eingriff wieder her. Das braucht Zeit, und bis dahin sind die betroffenen Dienste nicht erreichbar.

1. 1

   Ein Node fällt aus

   Die Dienste auf diesem Node sind nicht mehr erreichbar.

2. 2

   Kubernetes erkennt den Ausfall

   Der Node wird als nicht verfügbar markiert. Das dauert typischerweise einige Minuten.

3. 3

   Neustart auf einem anderen Node

   Kubernetes startet die betroffenen Komponenten auf einem verbleibenden Node.

4. 4

   Volume wird angehängt

   Longhorn hängt dort das Replikat des Volumes an.

5. 5

   Dienst wieder erreichbar

   Die Komponenten laufen wieder. Zeigen Benutzer, CUCM oder das NAT für Microsoft auf die Adresse des ausgefallenen Nodes, stellen Sie diese um, siehe Adressen planen.

Jeder Dienst in einer Instanz

Jeder Dienst läuft heute in einer Instanz. Das gilt für die EasyUC-Komponenten ebenso wie für MariaDB, Elasticsearch, RabbitMQ, den Manager, acd-media und teams-sbc. Fällt ein Node aus, startet Kubernetes die betroffenen Dienste auf einem anderen Node neu. Das dauert einige Minuten; laufende Gespräche auf diesem Node werden beendet.

Folgendes gibt es heute nicht:

• Replikation der Datenbank, etwa mit Galera
• mehrere Instanzen je Dienst
• automatisches Failover ohne Unterbrechung
• Rolling Updates. Bei einem Update starten alle Dienste gemeinsam neu, siehe Updates.
• Alarmierung per E-Mail, SNMP oder Prometheus

Adressen planen: keine gemeinsame virtuelle IP

EasyUC stellt keine gemeinsame virtuelle IP-Adresse bereit. Benutzer, CUCM und das NAT für Microsoft zeigen auf die Adresse eines Nodes. Damit Sie nach einem Ausfall umstellen können, planen Sie Folgendes:

• DNS-Namen statt fester IP-Adressen für Benutzer, Agenten und CUCM.
• Für Teams das 1:1-NAT so, dass Sie es auf den Node umstellen können, auf dem teams-sbc nach einem Ausfall läuft.
• Das Webzertifikat mit allen Namen, unter denen EasyUC erreichbar sein soll, siehe Zertifikate.
• In Richtung CUCM verbinden sich jtapi und acd-media mit dem CUCM-Host aus den AXL-Einstellungen.

Installationen mit einem Node

Bei einem einzelnen Node gibt es keine Redundanz im Cluster. Der Schutz kommt aus der Virtualisierung: Hochverfügbarkeit des Hypervisors, VM-Snapshots und Backups. Was Datenbank-Backup und Vollsicherung abdecken, steht unter Backup und Wiederherstellung.

Überwachung

Diese Informationen stehen zur Verfügung:

• Status und Auslastung der Nodes im Manager
• Zustand der Longhorn-Volumes im Manager
• Status der Komponenten, live im Manager
• Verlauf der Backups im Manager
• Gateway-Status des Teams-SBC, alle 20 Sekunden an die Administrationsoberfläche gemeldet