Historique de la page
...
Sv translation | ||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||||
Getting the system readyNote: the two servers involved must follow the hardware sizing recommendations defined in the section: Hardware Sizing Storage spaceThe contents you want to share between the two servers can be shared either on a separate shared storage space such as a SAN (Storage Area Network), or through data replication between two separate storage spaces.
Data to be made available between both serversThe data located in the following directories must be made visible by both servers and its access must be managed by the HA handling system:
The cyrus database located in the following directory must also be added to this data:
NetworkTo work properly, BlueMind must be accessible through a single URL/IP. We therefore recommend that you use a system that is capable of handling floating (or virtual) IP addresses.
Monitoring scriptsPlease see our Supervision page. Setting Up High Availability
Data and services that need to be managed by HAHigh availability-based synchronization of BlueMind configuration filesBlueMind's configuration files that must be synchronized in real time by the HA handling system are located under /etc The following files must also be synchronized:
Managing the BlueMind updateThe key steps for updating a High Availability-based deployment of BlueMind are described below:
STONITHSTONITH, which stands for Shoot The Other Node In The Head, is a fencing or node isolation technique in cluster management. Its purpose is to shut down a server's failed cluster remotely – either through software or by directly cutting off its power supply. This is done at the hardware infrastructure level.
This technique can for instance be implemented using IPMI tools (Intelligent Platform Management Interface). IPMI is a server management interface specification whose implementations include freeIPMI, OpenIPMI, ipmitool, ... As far as hardware is concerned, implementation can be done on dedicated hardware or using iDRAC cards for DELL equipment. | ||||||||||||||||||||
Sv translation | ||||||||||||||||||||
|
Volet | ||||
---|---|---|---|---|
Auf dieser Seite:
|
Info |
---|
Die in diesem Dokument erwähnten Softwarelösungen von Drittanbietern werden als Beispiele genannt. Diese Liste erhebt keinen Anspruch auf Vollständigkeit. |
Vorbereitung des Systems
Hinweis: Die beiden betreffenden Server müssen den im folgenden Dokument definierten Hardware-Sizing-Empfehlungen entsprechen: Materialdimensionierung
Speicherplatz
Die Inhalte, die zwischen den beiden Servern ausgetauscht werden sollen, können entweder auf einem gemeinsamen Speicherplatz wie einem SAN (Storage Area Network) oder über eine Datenreplikation zwischen zwei getrennten Speicherplätzen ausgetauscht werden.
Astuce |
---|
Hochverfügbarkeit über einen Replikationsmechanismus kann zu großen Problemen beim Zugriff auf gemeinsam genutzte Festplattenressourcen führen, die im Falle eines Dienstausfalls auftreten können. Der häufigste Fall, in dem Bedenken bezüglich des Ressourcenzugriffs eine potenziell katastrophale Auswirkung haben, ist das Split-brain-Szenario. |
Remarque |
---|
Die Komponente cyrus-imap unterstützt keine NFS-Speicherung für die Verwaltung von Metadaten. Unabhängig von der gewählten Art des replizierten Speichers ist eine Speicherung vom Typ Block-device erforderlich, die z.B. auf Fibre Channel- oder iSCSI-Technologien für das Verzeichnis /var/spool/cyrus/meta basiert.Alle anderen Verzeichnisse wie /var/spool/cyrus/data und /var/lib/cyrus können auf per NFS gemounteten Speicherbereichen gespeichert werden. |
Daten, die zwischen den beiden Servern zur Verfügung gestellt werden sollen
In den folgenden Verzeichnissen befinden sich die Daten, die für beide Server sichtbar sein müssen und deren Zugriff durch das HA-Management-System 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
Astuce |
---|
Diese Daten müssen daher auf einem Speicherplatz liegen, der es dem passiven Server erlaubt, im Falle eines Failovers auf die Daten zuzugreifen, z.B. ein SAN-Speicher, ein GFS-Cluster oder andere... |
Avertissement |
---|
ERINNERUNG: |
Netzwerk
Damit BlueMind ordnungsgemäß funktioniert, muss es über eine einzige URL/IP erreichbar sein. Es wird daher empfohlen, ein System zu verwenden, das schwebende (oder virtuelle) IP-Adressen verwalten kann.
Remarque |
---|
Die Zugriffs-URL auf BlueMind-Frontends muss immer dieselbe sein. |
Supervisionsskripte
Siehe die entsprechende Seite Supervision
Konfigurieren der Hochverfügbarkeit
Zu verwaltende Daten und Dienste
Konfiguration der BlueMind-Synchronisierung
Die BlueMind-Konfigurationsdateien, die vom HA-Management-System in Echtzeit synchronisiert werden sollen, befinden sich im Verzeichnis /etc.
Außerdem müssen die folgenden Dateien synchronisiert werden:
- /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
Astuce |
---|
Um eine Echtzeitsynchronisation der Konfigurationsdateien zu erreichen, können Sie die folgenden Beispiele verwenden:
|
BlueMind Aktualisierung-Verwaltung
Die wichtigsten Schritte zur Aktualisierung einer BlueMind High Availability-Bereitstellung werden im Folgenden beschrieben:
Remarque |
---|
|
STONITH
STONITH, für Shoot The Other Node In The Head, ist eine Fencing-Technik, also eine Isolierung, im Cluster-Management. Das Prinzip besteht darin, den fehlerhaften Server eines Clusters aus der Ferne herunterfahren zu können, entweder per Software oder direkt durch Abschalten seiner Stromversorgung.
Diese Funktionsweise findet auf Ebene der physischen Infrastruktur statt.
Info |
---|
Diese Sicherheit verringert das Risiko der Datenbeschädigung im Falle eines komplexen Dienstausfalls erheblich, z.B. im Falle eines Split-Brain-Ausfalls, der dazu führt, dass sich die beiden Server als alleiniger Master betrachten und gleichzeitig versuchen, auf die gemeinsame Speicherressource zuzugreifen. Bei Hochverfügbarkeit auf Basis von Datenreplikation sind die Risiken der Datenkorruption erheblich. |
Diese Technik kann zum Beispiel mit IPMI-Tools (Intelligent Platform Management Interface) realisiert 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.