Hochverfügbare Mail-Server mit CommuniGate Pro Cluster einrichten

Grundlage für die Hochverfügbarkeit bildet die Unterstützung für den Multiserver-Betrieb. CommuniGate Pro schaltet dabei Server zu einem Cluster aktiver Knoten zusammen. Das System unterscheidet zwischen statischen und dynamischen Clustern.

Ein statischer Cluster nutzt eine Partitionierung, bei der User-Konten auf verschiedene Server verteilt werden, ohne dass ein gemeinsamer Datenpool vorgehalten wird. Die beteiligten Maschinen kommen daher mit lokalem Storage aus. Bei CommuniGate Pro werden sämtliche Nutzdaten im File-System als Dateien und Verzeichnisse gespeichert, was eigene Datenbanken überflüssig macht.

Während dieser Cluster-Typ durch Verteilung der Last auf mehrere Server hauptsächlich bei der horizontalen Skalierung der Umgebung hilft, leisten dynamische Cluster wesentlich mehr. Auf Basis von Shared Storage (SAN oder NAS) werden hier sämtliche Daten und Benutzerkonten zentral gespeichert und befinden für alle Server (Knoten) im Cluster gleichermaßen im Zugriff. Durch diese Architektur können sowohl Ausfälle einzelner Server automatisch kompensiert als auch weitere Server bei Bedarf hinzugefügt werden.

Dynamische Cluster sind somit das Mittel der Wahl für die Schaffung einer ausfallsicheren Mailserver- und Kommunikations­infrastruktur mittels Failover. Durch den integrierten Lastenausgleich kann eine hochgradige Skalierbarkeit gewährleistet werden.

Single-Image-Architektur

Ob statisch oder dynamisch: Der Administrator richtet alle am Cluster beteiligten CommuniGate Pro Server auf Basis ein und derselben Binaries ein. Die Cluster-Mechanismen sind Bestandteil des Standardprogramms. Voraussetzung für den Aufbau eines Clusters ist eine entsprechende Lizenz.

Alle wichtigen von der CommuniGate-Software angebotenen Services von SMTP, POP, IMAP bis hin zu SIP und XMPP können dabei im Cluster betrieben werden. Das Multidomain- und Multimandanten-Konzept von CommuniGate Pro ist ebenfalls Cluster-fähig.

Multi-Server-Architektur

CommuniGate unterstützt – und empfiehlt - die Segmentierung der beteiligten Rechner im Cluster in sogenannte Frontend-Server und Backend-Server. Die Frontends wickeln die eingehenden Client-Verbindungen ab, sorgen für die SSL-Verschlüsselung und für das SMTP-Relaying. Zudem sind sie für die Realtime-Protokolle wie SIP zuständig.

In der zweiten Linie stehen die Backend-Server, welche die eigentlichen Nutzdaten sowie Benutzerkonten verwalten und für das Cluster-Management zuständig sind. Einer der Knoten fungiert dabei immer als Controller, der die Zugriffe im Cluster synchronisiert. CommuniGate Pro kommt dabei ohne Dateisperren aus, weil der Cluster gewährleistet, dass immer nur ein Backend-Server zu einer Zeit auf die Dateien eines Benutzerkontos zugreift.

Komponenten eines CG Pro Clusters

Für maximale Ausfallsicherheit sollten alle beteiligten Komponenten redundant ausgelegt werden:

• Load-Balancer regeln die Verbindungen der User zu den Frontend-Servern
• Mindestens zwei Frontend-Server verwalten die Verbindungen mit den Usern
• Mindestens zwei Backend-Server verwalten die Benutzer- und Nutzdaten
• Das Shared Storage speichert zentral alle Daten des gesamten Clusters und sollte daher performant sowie ausfallsicher ausgelegt sein

Kleine Cluster-Setups können auch ohne dedizierte Frontend- und Backend-Rollen auskommen. Bei solchen so genannten symmetrischen Konfigurationen übernimmt jeder Knoten beide Rollen.

Installation eines Clusters

Für die Einrichtung eines Clusters sind neben einer normalen Installation der Knoten sowie der Anbindung der Backend-Server an das zentrale Storage einige wenige Cluster-spezifische Konfigurationen vorzunehmen:

1. Jedem Knoten müssen alle anderen Knoten bekannt gemacht werden. Dies erfolgt in der Webadmin-GUI im Menüpunkt Konfiguration => Allgemein => Cluster über die Angabe ihrer IP-Adressen. Anschließend wird CommuniGate Pro auf dem Knoten gestoppt.
2. Der designierte Cluster-Manager muss als erster Knoten gestartet werden
3. In der Webadmin-GUI des Cluster-Managers muss eine Dynamic Cluster Domain konfiguriert werden (Menü User => Domains).
4. Erst anschließend wird der CommuniGate Pro-Dienst je Knoten entsprechend seiner Rolle mit dem richtigen Parameter gestartet, entweder –-clusterBackend oder –-clusterFrontend.
5. Nach dem Starten der Cluster-Knoten kann der Cluster-Status im Menü Monitoring => Cluster eingesehen werden.

Das Cluster-System teilt dem zweiten gestarteten Backend-Server automatisch die Rolle des Backup Controllers zu. Fällt der Master aus, wird automatisch der Backup-Knoten zum Controller.

Soll ein Knoten aus dem Cluster entfernt werden, zum Beispiel für Wartungszwecke, so genügt es, CommuniGate Pro auf dem betreffenden Rechner herunterzufahren. Sinnvollerweise wird der betreffende Server vorher aus den Load-Balancern abgemeldet.

Da die Backend-Server typischerweise nicht vom öffentlichen Netz aus zugänglich sind, kann von dort im Normalfall auch die Webadmin-GUI nicht aufgerufen werden. Administratoren können sich hier jedoch des Umwegs über einen der Frontendserver bedienen. Die aufzurufende URL muss dabei diesem Schema entsprechen: http://Frontendserver:8010/Cluster/<Backendserver>/

<Frontendserver> und <Backendserver> müssen in der URL durch die jeweilige IP-Adresse des Knotens ersetzt werden.

Skalierung für größte Umgebungen

Der Hersteller von CommuniGate Pro wirbt zum einen mit einer sehr hohen User-Dichte je Server von bis zu 450000 Benutzerkonten, zum anderen mit einer Ausbaufähigkeit seiner Cluster-Systeme bis zu etwa 5 Millionen Benutzern.

Umgebungen, die noch darüber hinausgehen, können dabei ebenfalls unterstützt werden, indem (statische) Cluster aus mehreren (dynamischen) Clustern gebildet werden. Dabei werden einzelne Backend-Server je durch ein dynamisches Cluster ersetzt.