Implementierung von BlueMind 4: Punkte, die besondere Aufmerksamkeit erfordern
Die BlueMind Version 4 integriert wichtige Architekturentwicklungen mit einerseits nativer Outlook-Unterstützung und andererseits Datenreplikation zur Aufbereitung von E-Mail-Daten für Outlook und andere Anwendungen (insbesondere neue Webmailer und Mobilgeräte).
Die Replikation
Die Replikation – jeweils eine pro Mail-Shard (also eine pro Mailbox-Rolle) – ermöglicht es Cyrus, eine Kopie der Nachrichten an den Dienst „bm-core“ weiterzuleiten. Der bm-core Dienst nutzt diese Replikation, um „Metadaten“ von Nachrichten abzurufen, die für bm-eas, bm-mapi und ElasticSearch benötigt werden. Diese „Metadaten“ werden in Datenbanken (wie bei Exchange) und in ElasticSearch gespeichert.
So kann auch bei Replikationsausfall ein ganzer Mailspool (Cyrus-Seite) übernommen werden, wobei die Mails in Webmailer und Thunderbird angezeigt werden. Unter diesen Bedingungen sind die Nachrichten (ganz oder teilweise) nicht verfügbar:
- im Outlook
- über EAS (Smartphones)
- in der Suchmaschine (Webmailer, Smartphones)
- zum Erstellen von Filtern in den Benutzereinstellungen oder der Verwaltungskonsole (Ordner werden nicht angezeigt)
Datenübernahme und Replikation
Generell sollte die Datenübernahme über E-Mail-Clients vermieden werden. Dies ist in Outlook unbedingt zu vermeiden, sei es durch das Laden einer PST-Datei oder durch das Verschieben von Nachrichten zwischen Profilen. Tatsächlich lassen sich die Überwachung des Fortschritts, die Fehlerbehebung und die Diagnose etwaiger Probleme über die Clients nicht zufriedenstellend durchführen.
BlueMind empfiehlt nachdrücklich eine Datenwiederherstellung im Rahmen eines serverseitig gesteuerten Prozesses. Diese Rücknahmen werden sicherer und effizienter sein, und die entsprechenden Instrumente werden eine bessere Nachverfolgung ermöglichen. Zu diesem Zweck entwickeln unsere Teams Migrationswerkzeuge.
Die empfohlenen Übernahmelösungen sind:
- das Migrationstool „bm-migrator“, das die Migration von Exchange-, Microsoft 365- (mit Einschränkungen), Zimbra- und Kerio-E-Mail-Systemen umfasst
- das Exchange Migration Tool (ein grafisches Tool, für das ein Zwischenserver unter Windows erforderlich ist)
- das serverseitige PST-Übernahmetool
- das iMAP-Synchronisierungstools mit imapsync (siehe nachstehende Empfehlungen)
- das Domino-Übertragungstool
Die Replikation extrahiert und speichert Informationen aus dem Mailspool in BlueMind-Objekten, die zuvor existieren müssen. Damit die Replikation reibungslos funktioniert, dürfen daher nur Daten in Cyrus eingegeben werden, die BlueMind bereits bekannt sind: Die Domänen und Postfächer müssen daher zuvor in der Verwaltungskonsole (oder über die API) angelegt werden, bevor die Postfächer befüllt werden.
Derzeit ist es in admin0 (BlueMind-Superadministrator) möglich, BlueMind-Daten ohne Berücksichtigung von BlueMind-Objekten und Mail-Speicherregeln zu übernehmen. In der Tat können mit admin0-Rechten E-Mail-Daten auf dem Cyrus-Server gespeichert werden, ohne dass irgendwelche Rechte oder Konsistenzprüfungen durchgeführt werden. Aus diesem Grund können die Daten für BlueMind als inkonsistent angesehen werden und somit kann die Replikation fehlschlagen. Wir raten daher davon ab, Daten per imapsync mit dem Benutzer admin0 zu importieren.
Um dies zu vermeiden, ist es wichtig, dass – falls eine Übernahme der BlueMind-Daten mittels imapsync geplant ist – imapsync mit den Anmeldedaten des Benutzers selbst durchgeführt wird. Wenn Sie die Vorgänge als E-Mail-Benutzer durchführen, können Sie sicher sein, dass das Konto existiert, dass die Partition die richtige ist usw.
So erstellen Sie einen API-Schlüssel für einen bestimmten Benutzer:
Beispiel für eine Datenübernahme, die dem Quellserver und den wiederherzustellenden Konten/Daten anzupassen ist:
https://forge.bluemind.net/stash/projects/BA/repos/bluemind-samples/browse/migration/4.0/kerio
Generell und insbesondere für Version 4 wird dringend empfohlen, die Datenübernahme auf einem Testserver zu testen, der anschließend neu installiert oder vernichtet wird. Die Datenübernahme muss, nachdem sie validiert wurde, auf einem leeren Server (oder einer leeren Domäne) durchgeführt werden, die keine Spur der in der Testphase durchgeführten Vorgänge aufweisen. Die LDAP / AD-Verbindung, die ImapSync-Datenübernahme oder die Exchange-Wiederherstellung können nach erfolgreichem Prototyping auf dem Produktionsserver nachgespielt werden.
Neugestaltung der BlueMind-Archivierung
Ab Version 4 wird die Nachrichtenarchivierung (HSM) von Cyrus nativ unterstützt (siehe die entsprechende Seite: Archivierung).
Wenn Ihre Installation bereits die Archivierung in Version 3.5 verwendete, müssen Sie diese 3.5-Archive wiederherstellen, um sie wieder in Cyrus zu integrieren (das sie dann selbstständig und transparent gemäß der festgelegten Richtlinien verwaltet).
Dies hat erhebliche Auswirkungen auf den Speicherplatz für E-Mails und bedeutet in der Regel langwierige Wiederherstellungsvorgänge, die konsistent mit den Aktualisierungsschritten in 4. organisiert werden müssen.
Ein detailliertes Update-Verfahren in 4 beschreibt die für die Übernahme der Archive notwendigen Vorgänge. Sie finden sie im Partnerbereich: Vorgehensweise für das Update von BlueMind 3.5 auf BlueMind 4. Bitte lesen Sie die verschiedenen Schritte dieses Verfahrens mit größter Aufmerksamkeit.
Dimensionierung
Mehrere Umstrukturierungen der Architektur und Änderungen in der Funktionsweise von BlueMind wirken sich auf die Größe des Speicherplatzes der BlueMind-Server aus. Es ist besonders wichtig, "full disks" zu vermeiden, die das Update auf Version 4 stören, blockieren oder fehlschlagen lassen. Die folgenden Speicherentwicklungen können sich auf Ihre BlueMind-Installation auswirken:
- /var/spool/bm-replication: Rechnen Sie mit einem erheblichen Anstieg des belegten Speicherplatzes. Es muss Speicherplatz in einer Größe von 25 % von /var/spool/cyrus/data verfügbar sein.
- /var/spool/bm-elasticsearch: 20 bis 25 % des E-Mail-Volumens der beiden Ordner /var/spool/cyrus/data und /var/spool/bm-hsm
- /var/lib/postgresql: Die Datenbank muss um 10 % des E-Mail-Volumens (/var/spool/cyrus/data und /var/spool/bm-hsm) wachsen können
- /var/log/bm/replication.log kann sehr stark an Größe zunehmen. Die entsprechende Partition muss mindestens 1 GB freien Festplattenspeicher haben.
Was die Speicherressourcen betrifft, so müssen dem ElasticSearch-Dienst zusätzliche 1,5 GB zugewiesen werden, damit er während der Aktualisierungsphase funktionieren kann.
Dieser zusätzliche Speicherplatzbedarf wird in der Anleitung zum Update auf Version 4 erläutert: Anleitung zum Update von BlueMind 3.5 auf BlueMind 4.
BlueMind ohne MAPI
Diese Arbeitsweise hat ihre Grenzen, die BlueMind nicht überschreiten kann. Aus diesem Grund hat BlueMind die native Verbindung mit Outlook entwickelt, eine Lösung, die eine bessere Berücksichtigung der Outlook-Funktionen ermöglicht.
Wenn Ihre Nutzer an den Outlook-Connector gewöhnt und mit ihm zufrieden sind, kann diese Arbeitsweise beibehalten werden. Andernfalls empfiehlt es sich, über MAPI schrittweise auf Outlook umzuschalten.
Outlook
Ohne den MAPI-Dienst funktioniert Outlook weiterhin mit dem Connector genauso wie in Version 3.5. Administratoren müssen das gleiche Verfahren zur Bereitstellung von Benutzern für den Outlook-Connector durchführen, damit die Benutzer diesen herunterladen und auf ihren Computern installieren können.
Das Ordner-Mapping wird von Outlook weder erkannt noch übersetzt. Standardordner wie Posteingang, Gesendete Nachrichten usw. erscheinen in englischer Sprache, da sie über das IMAP-Protokoll abgerufen werden, üblicherweise ohne Übersetzung. Aus technischer Sicht behindert dies die ordnungsgemäße Synchronisierung nicht, kann aber für die Nutzer lästig sein. Zu Ihrer Information: Mit MAPI wird das Mapping korrekt gehandhabt.
Cyrus
Ab Version 4.1 wird beim Start von BlueMind eine Überprüfung des Cyrus Baums durchgeführt und eine Warnung (durch eine Warnung in den Protokollen) erfolgt, wenn der Baum nicht konsistent ist.
BlueMind mit MAPI
Autodiscover
Ab Version 4.1 wird eine Autodiscover-Prüfung auf allen Domänen und Aliassen der Installation durchgeführt: wenn kein Autodiscover funktioniert, dann startet der MAPI-Dienst nicht, wenn mindestens ein Autodiscover gut ist, dann beginnt der Dienst, die erreichbaren Domänen zu bedienen. Wenn mindestens ein Autodiscover-Eintrag korrekt ist, wird der Dienst gestartet, um die zugänglichen Domänen bereitzustellen.
So versucht der MAPI-Server für jede Domäne und jeden Alias, eine Anfrage an domain.loc/autodiscover und autodiscover.domain.loc/autodiscover zu senden, und überprüft, ob er die Anfrage tatsächlich selbst erhält.
Außerdem wird auf dem DNS-Server überprüft, ob die Einträge _autodiscover._tcp.domain.loc und _autodiscover.<alles alias> vorhanden sind.
Um sicherzustellen, dass der Server korrekt konfiguriert und über diese URLs erreichbar ist, können Sie das Online-Diagnosetool von Microsoft verwenden: https://testconnectivity.microsoft.com/
Cyrus
Ab Version 4.1 wird beim Start von BlueMind eine Überprüfung des Cyrus Baums durchgeführt und eine Warnung (durch eine Warnung in den Protokollen) erfolgt, wenn der Baum nicht konsistent ist.
Outlook
Empfehlungen und gute Praktiken
Um in seiner aktuellen Version zu funktionieren, darf Outlook nicht mit "Objekten" verschmutzt werden, die nicht von BlueMind stammen. Deshalb ist es unerlässlich, ein leeres Outlook-Profil zu erstellen und kein Exchange / Office365-Konto auf demselben Profil einzurichten.
Darüber hinaus sind Registrierungsschlüssel anzuwenden, unter anderem um Konfigurationskonflikte mit im Netzwerk verfügbaren Informationen (DNS, ActiveDirectory) zu vermeiden. Diese Registrierungsschlüssel sind in der entsprechenden Dokumentation aufgeführt: Implementierung von MAPI für Outlook > Konfiguration der Arbeitsplätze mithilfe von Registrierungsschlüsseln
Erstellen eines leeren Outlook-Profils
Um Outlook ohne Connector korrekt zu verbinden, sollten Sie zunächst Implementierungsdokumentation auf der Serverseite lesen:
Implementierung von MAPI für Outlook
Wir weisen Sie insbesondere auf das Kapitel über die Anforderungen an die Serverkommunikation hin: Die automatische Erkennung muss korrekt funktionieren, damit Outlook mit BlueMind kommunizieren kann.
Befolgen Sie für jede Position die Dokumentation zum Erstellen eines Profils für Outlook
Auch hier sollten Sie darauf achten, vorab zu überprüfen, ob die URLs vom jeweiligen Rechner aus erreichbar sind.
Outlook-Einschränkungen im Zusammenhang mit dem Betrieb von BlueMind
Die bekannten Einschränkungen hinsichtlich der Funktionsweise von Outlook sind auf unserer Seite zur Kompatibilität von BlueMind mit Client-Software und Geräten aufgeführt.
Bei Problemen:
Version von BlueMind
In den anschließenden Versionen von BlueMind wurden seit der Version 4.0 zahlreiche Verbesserungen vorgenommen. Es ist unerlässlich, alle Versionen vor BlueMind 4.5 so schnell wie möglich zu aktualisieren, um von allen entwickelten Verbesserungen profitieren zu können.
Replikation auf ordnungsgemäße Funktion prüfen
Die Replikation ist nun weitgehend stabilisiert. Probleme mit der Replikation sind selten. Diese Überprüfungsanweisungen sind daher im Allgemeinen nicht mehr notwendig
In der bm-tick-Überwachungskonsole können Sie das Dashboard „Mailspool & Replication“ überwachen. Zwei Graphen sind besonders wichtig:
Anzahl der replizierten Nachrichten pro Stunde:
Anzahl der aktiven Replikationen:
Diese Zahl muss 1 pro Server mit der Mailbox-Rolle und damit der bm-cyrus-imapd Dienst sein, wenn diese Zahl sinkt, bedeutet dies, dass die Replikation nicht (mehr) erfolgt.
Ist diese Anzahl hingegen größer als die Anzahl der IMAP-Backends, so bedeutet dies in den meisten Fällen, dass die Rolle einem (oder mehreren) separaten Speicherserver zugewiesen wurde, der Dienst jedoch weiterhin auf dem Hauptserver ausgeführt wird. Nun muss die Deaktivierung erzwungen werden, indem Sie die folgenden Dateien auf dem bm-core erstellen und dann die Dienste stoppen:
touch /etc/bm/bm-cyrus-imapd.disabled
touch /etc/bm/bm-lmtpd.disabled
systemctl stop bm-cyrus-imapd ; systemctl stop bm-lmtpd
Um zu sehen, ob die Replikation funktioniert, können Sie zu jedem Zeitpunkt eine Operation an einer E-Mail durchführen (z.B. sie auf ungelesen setzen) und mit dem Befehl tail überprüfen, ob zur gleichen Zeit eine Zeile dieser Art in der Logdatei /var/log/bm/replication.log hinzugefügt wird:
{{APPLY MAILBOX (.... loginUtilisateur ) }}
Fortschritt des Replikationsprozesses
Die Tick Verbesserungen werden in künftigen Versionen einen besseren Überblick über den Replikationsfortschritt ermöglichen.
Unterdessen kann die Anzahl der Mails in den Mail- und Archiv-Spools mit der Anzahl der Einträge in der Tabelle verglichen werden, in der die Nachrichten gespeichert sind. Die Entsprechung ist nicht exakt, gibt aber einen guten Überblick über den Fortschritt.
Zum Beispiel, um die Anzahl der zu synchronisierenden E-Mails zu kennen:
# Anzahl der E-Mails aus dem Spool:
find /var/spool/cyrus/data/ -type f|wc -l
# Anzahl der E-Mails aus dem Archiv:
find /var/spool/bm-hsm/cyrus-archives -type f|wc -l
Die Summe der beiden muss dem Abfrageergebnis auf der bj-Datenbank nahe kommen:
select count(\*) from t_message_body;
Beachten Sie, dass der Standard-Replikationsstrom nur „lebendige“ Mailboxen überwacht. Das heißt, wenn das Replikationsdelta signifikant bleibt, obwohl die Replikation fast gestoppt ist, wurden alle aktiven Nutzer tatsächlich repliziert und haben Zugriff auf die damit verbundenen Funktionen (Webmailer-Suche, EAS, etc.). Wenn eine E-Mail an N Benutzer gesendet wird, wird sie einmal in t_message_body gezählt, aber N-mal im Spool vorhanden sein.
Um die Replikation auf passiven (unbenutzten) Boxen zu starten, müssen Sie alle Boxen mit dem folgenden Befehl in der Replikationswarteschlange positionieren, nachdem Sie einige Cyrus-Protokolle bereinigt haben:
#Cyrus-Bereinigung
service bm-cyrus-imapd stop
rm /var/lib/cyrus/sync/core/log\*
service bm-cyrus-imapd start
#Replikation starten
bm-cli maintenance repair --ops replication.parentUid $DOMAIN_UID$
wobei $DOMAIN_UID$ der Name der Domäne ist, zum Beispiel: bluemind.net
Bekannte Einschränkungen
Die bekannten Einschränkungen finden Sie in der BlueMind-Kompatibilitätsdokumentation.
Aktualisierung von BlueMind 4.0 auf 4.x
Ordner unter dem Posteingang
In BlueMind-Versionen 4.0.x sind die von Outlook unter dem Posteingang angelegten Ordner keine E-Mail-Ordner, sondern virtuelle Ordner.
BlueMind 4.1 bietet nun Unterstützung für Unterordner im Posteingang (Inbox).
Im Rahmen eines Updates von BlueMind 4.0.x auf 4.1 oder höher werden die virtuellen Ordner nicht migriert und gelöscht.
Um dies zu vermeiden, können Sie diese virtuellen Ordner vor dem Update aus dem Posteingang verschieben, um sie zu erhalten; anschließend können sie wieder in den Posteingang zurückverschoben werden und werden dort als E-Mail-Ordner neu erstellt.