Software-Hochverfügbarkeit und BlueMind
Es ist möglich, ein HA-System (High Availability) zu implementieren, das mit BlueMind integriert werden kann.
Dieses Dokument enthält die Empfehlungen und Informationen über das BlueMind-System, die erforderlich sind, um die Messaging-Lösung in eine hochverfügbare Infrastruktur zu integrieren.
Die in diesem Dokument erwähnten Softwarelösungen von Drittanbietern dienen nur als Beispiel. Diese Liste ist nicht erschöpfend.
Vorbereitung des Systems
Hinweis: Beide Server müssen den Empfehlungen für die Hardwaredimensionierung entsprechen, die in dem folgenden Dokument definiert sind: Materielle Dimensionierung
Speicherplatz
Der Inhalt, der zwischen den beiden Servern geteilt werden soll, kann entweder auf einem gemeinsamen Speicherplatz, z. B. einem SAN (Storage Area Network), oder durch Datenreplikation zwischen zwei separaten Speicherbereichen geteilt werden.
Hochverfügbarkeit über einen Replikationsmechanismus kann zu erheblichen Problemen beim Zugriff auf gemeinsam genutzte Festplattenressourcen führen, die in Fällen von Serviceausfällen auftreten können. Das häufigste Problem beim Zugriff auf Ressourcen mit potenziell katastrophalen Auswirkungen ist das Szenario des split-brain.
Daten, die zwischen den beiden Servern verfügbar gemacht werden sollen
Die Daten in den folgenden Verzeichnissen sind diejenigen, die für beide Server sichtbar sein müssen und deren Zugriff durch das HA-Managementsystem verwaltet werden muss:
/var/spool/bm-docs/var/spool/bm-elasticsearch/var/spool/bm-hsm/var/spool/cyrus/var/spool/postfix/var/spool/bm-hollowed/var/spool/bm-mapi
Dazu muss die Datenbank in dem folgenden Verzeichnis hinzugefügt werden:
/var/lib/postgresql
Diese Daten müssen sich daher in einem Speicher befinden, der es dem passiven Server ermöglicht, im Falle eines Failovers auf die Daten zuzugreifen, z. B. ein SAN-Speicher, ein GFS-Cluster oder ähnliches.
Netzwerk
Um richtig zu funktionieren, muss BlueMind über eine einzige URL/IP zugänglich sein, daher wird empfohlen, ein System zu verwenden, das floating (oder virtuelle) IP-Adressen verwalten kann.
Die URL für den Zugriff auf das BlueMind Frontend muss immer dieselbe sein.
Supervisionsskripte
Siehe dedizierte Seite Überwachung
Konfiguration der Hochverfügbarkeit
Ohne STONITH (siehe unten) sollte die automatische Failover-Funktion nicht aktiviert werden, um das Risiko von split-brain-Fehlern und Datenbeschädigungen zu vermeiden (siehe Kasten im entsprechenden Absatz), die nicht vom BlueMind-Support berücksichtigt werden.
Zu verwaltende Daten und Dienste
Konfiguration des zu synchronisierenden BlueMind
Die BlueMind-Konfigurationsdateien, die vom HA-Verwaltungssystem in Echtzeit synchronisiert werden sollen, befinden sich im Verzeichnis /etc.
Sie müssen auch die Dateien synchronisieren:
- /usr/share/bm-elasticsearch/config/elasticsearch.yml
- /etc/aliases
- /etc/aliases.db
- /etc/sysctl.conf
- /etc/ssl/certs/bm_cert.pem
- /var/lib/bm-ca/ca-cert.pem
Um eine Echtzeitsynchronisation der Konfigurationsdateien zu erreichen, können Sie die folgenden Beispiele verwenden:
- incron, das auf inotify basiert, ermöglicht es, Aufgaben zu starten, die beispielsweise vom Status einer Datei abhängig sind. Die offizielle Dokumentation finden Sie auf der Website des Herausgebers
- Dateien können z. B. mit rsync über ssh kopiert werden, wie auf dieser Website dargestellt
- Weitere Tools wie l syncd und csync2 stehen zur Verfügung
Verwaltung des BlueMind-Updates
Die Hauptschritte des Upgrades einer BlueMind Hochverfügbarkeitsanwendung werden im Folgenden beschrieben:
- Bevor Sie das Update von BlueMind starten, deaktivieren Sie die Dienste zur Verwaltung der hohen Verfügbarkeit.
- Aktualisieren Sie die Pakete auf beiden Servern.
- Führen Sie dann nur auf dem Hauptserver mit der öffentlichen IP-Adresse die Konfiguration nach der Installation durch, wie auf der Seite beschrieben. Konfiguration nach der Installation
STONITH
STONITH, für Shoot The Other Node In The Head, ist eine Technik des fencing oder der Isolierung in der Cluster-Verwaltung Das Prinzip besteht darin, dass ein ausgefallener Server in einem Cluster aus der Ferne abgeschaltet werden kann, entweder per Software oder direkt durch Unterbrechung der Stromzufuhr.
Diese Art von Betrieb ist auf der Ebene der Hardware-Infrastruktur angesiedelt.
Dies ermöglicht es, das Risiko von Datenbeschädigungen bei komplexen Serviceverlustfällen stark zu reduzieren, beispielsweise bei einem Fehler vom Typ split-brain, der dazu führen würde, dass beide Server sich als einzigen Master betrachten und gleichzeitig versuchen, auf den gemeinsamen Speicherplatz zuzugreifen Im Falle einer hohen Verfügbarkeit, die auf Datenreplikation basiert, ist das Risiko der Datenkorruption hoch.
Diese Technik kann beispielsweise mit IPMI-Tools (Intelligent Platform Management Interface) implementiert werden IPMI ist eine Spezifikation von Maschinenverwaltungsschnittstellen, aber es gibt auch Implementierungen wie freeIPMI, OpenIPMI, ipmitool, ...
Die Implementierung auf der Hardwareseite kann durch dedizierte Hardware oder einfach durch den Einsatz von z.B. iDRAC-Karten für Hardware des Herstellers DELL erfolgen.