Comparaison des versions

Ancienne version 43

changes.mady.by.user Sophie Lepissier

Sauvegardée le

comparé à

Nouvelle version 44

changes.mady.by.user Sophie Lepissier

Sauvegardée le

Légende

  • Ces lignes ont été ajoutées. Ce mot a été ajouté.
  • Ces lignes ont été supprimées. Ce mot a été supprimé.
  • La mise en forme a été modifiée.
Commentaire: Published by Scroll Versions from space DA and version BM-4
Sv translation
languagefr
Remarque

Cette page n'est plus actualisée. À partir de BlueMind 4.8, veuillez consulter la nouvelle documentation BlueMind

Présentation

II est possible de mettre en place un système de haute disponibilité logicielle (HA pour High Availability en anglais) s'intégrant avec BlueMind.

Le présent document donne les recommandations et informations sur le système BlueMind nécessaire pour pouvoir intégrer la solution de messagerie dans une infrastructure de haute disponibilité.


Volet
Sur cette page :
Sommaire
maxLevel2
Info

Les solutions logicielles tierces mentionnées dans le présent document sont données à titre d'exemple. Cette liste ne saurait être exhaustive.

Préparation du système

Note : les deux serveurs en jeu doivent respecter les recommandations de dimensionnement matériel définies dans le document suivant : Dimensionnement materiel

Espace de stockage

Le contenu à partager entre les deux serveurs peut l'être soit sur un espace de stockage partagé comme par exemple un SAN (Storage Area Network), soit via une réplication de données entre deux espaces de stockages séparés.

Astuce

La haute disponibilité via un mécanisme de réplication peut induire des problèmes majeurs d'accès aux ressources disques partagées qui surviennent le cas échéant dans des cas de pertes de services. Le cas le plus courant de soucis d'accès aux ressources ayant un impact potentiellement désastreux est le scénario de split-brain .

Remarque
Le composant cyrus-imap ne supporte pas les stockages de type NFS pour la gestion des méta-données. Quel que soit le choix retenu pour le type de stockage répliqué, il faut donc un stockage de type block-device se basant par exemple sur les technologies Fibre Channel ou iSCSI pour le répertoire /var/spool/cyrus/meta.
Tous les autres répertoires comme /var/spool/cyrus/data et /var/lib/cyrus peuvent quant à eux être stockés sur des espaces de stockages montés en NFS.

Données à rendre disponible entre les deux serveurs

Les données situées dans les répertoires suivants sont celles qui doivent être visibles par les deux serveurs et dont l'accès doit être géré par le système de gestion de la HA :

  • /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

À ces derniers doit être ajoutée la base de données cyrus située dans le répertoire suivant :

  • /var/lib/cyrus
  • /var/lib/postgresql
Astuce
Ces données doivent donc se trouver sur un espace de stockage permettant au serveur passif d'accéder aux données en cas de bascule, par exemple un stockage SAN, un cluster GFS, ou autre..
Avertissement

RAPPEL : /var/spool/cyrus/meta ne doit en aucun cas être stocké sur un montage NFS, en revanche /var/spool/cyrus/data peut l'être

Réseau

Afin de fonctionner correctement, BlueMind doit être accessible via une seule URL/IP, il est donc recommandé d'utiliser un système pouvant gérer des adresses IP flottantes (ou virtuelles).

Remarque
L'URL d'accès sur les frontend BlueMind doit obligatoirement être toujours la même.

Scripts de supervision

Voir la page dédiée Supervision

Configuration de la Haute disponibilité

Avertissement

Sans STONITH (voir ci-après), il ne faut pas activer la bascule automatique au risque d'avoir des défaillances split-brain et des corruptions de données  (voir encart dans le paragraphe dédié) qui ne seront pas prises en compte par le support BlueMind.

Données et services à gérer

Configuration de BlueMind à synchroniser

Les fichiers de configurations BlueMind à synchroniser en temps réel par le système de gestion de la HA sont situés dans le répertoire /etc.

Il faut également synchroniser les fichiers :

  • /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

Pour réaliser une synchronisation en temps réel des fichiers de configuration, il est possible de se baser sur les exemples suivant :

  • incron, basé sur inotify, permet de lancer des tâches en fonction de l'état d'un fichier par exemple. La documentation officielle est disponible sur le site de l'éditeur.
  • les fichiers peuvent être copier par rsync over ssh par exemple, comme présenté sur ce site.
  • d'autres outils existent comme l syncd et csync2

Gestion de la mise à jour de BlueMind

Les grandes étapes de la mise à jour d'un déploiement en Haute Disponibilité de BlueMind sont décrites ci-après :

Remarque
  • Avant de lancer la mise à jour de BlueMind, désactiver les services de gestion de la haute disponibilité.
  • Mettre à jour les paquets sur les deux serveurs.
  • Puis sur le serveur principal uniquement possédant l'adresse IP publique, réaliser la configuration post-installation comme indiqué au paragraphe : Configuration post-installation.

STONITH

STONITH, pour Shoot The Other Node In The Head, est une technique de fencing, ou isolement, dans la gestion de clusters. Le principe est de pouvoir éteindre le serveur défaillant d'un cluster à distance, soit logiciellement, soit directement en lui coupant son alimentation électrique.

Ce type de fonctionnement se situe au niveau de l'infrastructure matérielle.

Info
Cette sécurité permet de diminuer fortement les risques de corruption de données dans des cas de pertes de service complexes, par exemple comme dans le cas d'une défaillance de type split-brain qui va conduire les deux serveurs à se considérer unique maître et tenter d'accéder en même temps à la ressource de stockage partagée. Dans le cas d'une haute-disponibilité basée sur une réplication de données, les risques de corruption de données sont importants.

Cette technique peut par exemple être mise en place avec des outils IPMI (Intelligent Platform Management Interface). IPMI est une spécification d'interfaces de gestion de machines, mais il est possible d'en trouver des implémentations, comme par exemple freeIPMI, OpenIPMI, ipmitool, ...

L'implémentation côté matériel peut se faire par un matériel dédié ou simplement par l'utilisation par exemple des cartes iDRAC pour du matériel du constructeur DELL.

Sv translation
languageen
Remarque

This page is no longer being updated. From BlueMind 4.8, please refer to the new BlueMind documentation

You can set up a High Availability system that integrates with BlueMind.

This page provides recommendations and information about the BlueMind system required to be able to integrate the mail solution into a high availability infrastructure.

Volet
Sommaire
maxLevel2
Info

The third-party software solutions mentioned here are provided for illustration purposes only. This list is not comprehensive.

Getting the system ready

Note: the two servers involved must follow the hardware sizing recommendations defined in the section: Dimensionnement materiel

Storage space

The 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.

Astuce

Replication-based high availability can cause major issues with access to shared disk resources which may occur during loss of service. The most typical issue with resource access and with potentially disastrous consequences occurs in a split-brain situation.

Remarque

The cyrus-imap component does not support NFS-based storage. As a result, regardless of the type of replicated storage you choose, you need a block-device-based storage using technologies such as Fibre Channel or iSCSI for the data this component handles (/var/spool/cyrus and /var/lib/cyrus).

Data to be made available between both servers

The data located in the following directories must be made visible by both servers and its access must be managed by the HA handling system:

  • /var/spool/bm-docs
  • /var/spool/bm-elasticsearch
  • /var/spool/bm-hsm
  • /var/spool/cyrus
  • /var/spool/postfix
  • /var/spool/sieve
  • /var/spool/bluemind-pkgs

The cyrus database located in the following directory must also be added to this data:

  • /var/lib/cyrus
  • /var/lib/postgresql
Astuce
This data must therefore be located in a storage space -- SAN storage, GFS cluster, etc – that allows the passive server to access the data during switchovers.
Avertissement

REMINDER: /var/spool/cyrus MUST NOT be stored on an NFS mount.

Network

To 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.

Remarque
BlueMind's front-end access URL MUST always be the same.

Monitoring scripts

Please see our Supervision page.

Setting Up High Availability

Avertissement
If you are not using STONITH (see below), you must not enable automatic changeover otherwise you may end up with a split-brain and corrupted data (see box in the dedicated paragraph) which will not be covered by BlueMind support.

Data and services that need to be managed by HA

High availability-based synchronization of BlueMind configuration files

BlueMind'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:

  •  /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

Here are a few examples of how to synchronize configuration files in real time:

  • incron, based on inotify, allows you to launch jobs depending on a file's status for example. The official documentation is available on the vendor's website.
  • files can be copied by rsync over ssh for example, as shown on this website.
  • other tools include lsyncd and csync2

Managing the BlueMind update

The key steps for updating a High Availability-based deployment of BlueMind are described below:

Remarque
  • Before you start the BlueMind update, disable the high availability handling services.
  • Update the packages on both servers.
  • Next, on the main server with the public IP address only, carry out the post-installation configuration as described in: Configuration post-installation.

STONITH

STONITH, 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.

Info
This security system strongly lowers the risk of corrupted data in the event of complex services failures, e.g. a split-brain, which leads both servers to consider themselves the sole master and attempt to access the shared storage resource at the same time. With data replication-based high availability, the risk of data corruption is high.

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
languagede

Präsentation

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 für die Integration der Messaging-Lösung in eine Hochverfügbarkeitsinfrastruktur erforderlich sind.


Volet
Auf dieser Seite:
Sommaire
maxLevel2
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: /var/spool/cyrus/meta darf niemals auf einem NFS-Mount gespeichert werden, aber /var/spool/cyrus/data kann auf einem NFS-Mount gespeichert werden

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

Avertissement

Ohne STONITH (siehe unten) darf die automatische Ausfallsicherung nicht aktiviert werden, da sonst die Gefahr von Split-Brain-Ausfällen und Datenbeschädigungen besteht (siehe Textbox im entsprechenden Absatz), die vom BlueMind-Support nicht berücksichtigt werden.

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:

  • incron, basierend auf inotify, ermöglicht es, Aufgaben entsprechend dem Zustand z.B. einer Datei zu starten. Die offizielle Dokumentation ist auf der Website des Herausgebers verfügbar.
  • Dateien können z.B. per rsync over ssh kopiert werden, wie auf dieser Seite vorgestellt.
  • Es gibt andere Tools wie l syncd und csync2

BlueMind Aktualisierung-Verwaltung

Die wichtigsten Schritte zur Aktualisierung einer BlueMind High Availability-Bereitstellung werden im Folgenden beschrieben:

Remarque
  • Deaktivieren Sie die Hochverfügbarkeitsverwaltungsdienste, bevor Sie das BlueMind-Update starten.
  • Aktualisieren Sie die Pakete auf beiden Servern.
  • Führen Sie dann nur auf dem Hauptserver mit der öffentlichen IP-Adresse die Nachinstallationskonfiguration durch, wie beschrieben im Abschnitt: Configuration post-installation.

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.