Software-Hochverfügbarkeit und BlueMind
Es ist möglich, ein High Availability-Softwaresystem einzurichten, das mit BlueMind integriert wird.
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
Note: Die beiden beteiligten Server müssen den Hardware-Dimensionierungsempfehlungen im folgenden Dokument entsprechen: Hardware-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.
Die Komponente cyrus-imap unterstützt keine Speicher vom Typ NFS für die Verwaltung von Metadaten. Unabhängig davon, für welche Art der replizierten Speicherung Sie sich entscheiden, benötigen Sie daher für das Verzeichnis /var/spool/cyrus/meta einen Block-Device-Speicher, der beispielsweise auf den Technologien Fibre Channel oder iSCSI basiert. Alle anderen Verzeichnisse wie /var/spool/cyrus/data und /var/lib/cyrus können hingegen auf über NFS eingebundenen Speicherorten gespeichert werden.
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/sieve/var/spool/bm-hollowed/var/spool/bm-mapi
Zu diesen muss die cyrus-Datenbank hinzugefügt werden, die sich im folgenden Verzeichnis befindet:
/var/lib/cyrus/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.
HINWEIS: /var/spool/cyrus/meta darf unter keinen Umständen auf einem NFS-Mount gespeichert werden; /var/spool/cyrus/data hingegen schon
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) darf die automatische Umschaltung nicht aktiviert werden, da sonst das Risiko von Split-Brain-Fehlern und Datenbeschädigungen besteht (siehe Kasten im entsprechenden Abschnitt), die vom BlueMind-Support nicht 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.
- Dann nur auf dem primären Server mit öffentlicher IP-Adresse die Post-Installation-Konfiguration gemäß dem Absatz durchführen: Post-Installation-Konfiguration
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.