ISR Information Products AG
Hauptsitz
Lange Straße 61 
38100 Braunschweig
Phone: +49 (0) 531 1208-0 
Fax:       +49 (0) 531 1208-199
info@isr.de
ISR Information Products AG
Geschäftsstelle Münster
Am Mittelhafen 14
48155 Münster
Phone: +49 (0) 251 9 24 34-0
Fax:       +49 (0) 531 1208-199
info@isr.de
ISR Information Products AG
Geschäftstelle Hamburg
Neue Burg 2
20457 Hamburg
Phone: +49 (0) 531 1208-400 
Fax:       +49 (0) 531 1208-199
info@isr.de
ISR Information Products AG
Geschäftsstelle Köln
Kaiser-Wilhelm-Ring 26
50672 Köln
Phone: +49 (0) 531 1208-200 
Fax:       +49 (0) 531 1208-199
info@isr.de
ISR Information Products AG
Geschäftsstelle München
St.-Martin-Str. 64
81541 München
Phone: +49 (0) 531 1208-300 
Fax:       +49 (0) 531 1208-199
info@isr.de

E-Mail Archivierung mit IBM Content Collector for Email - Überlegung zur Planung

Warum E-Mail Archivierung?

E-Mails sind aus unserer heutigen Kommunikation nicht mehr wegzudenken. Während die Verbreitung im privaten Bereich eher abnimmt und zunehmend durch Messenger ersetzt wird, nimmt sie im geschäftlichen Umfeld durch den Trend zur Digitalisierung noch weiter zu.

Der Gesetzgeber hat dies schon vor geraumer Zeit erkannt und entsprechende Vorgaben gemacht, um die rechtssichere Dokumentation von Geschäftskorrespondenz zu gewährleisten. Aber auch für die IT Infrastruktur in Form von Mail Servern stellt die zunehmende Anzahl und vor allem die Größe, die E-Mails heute im Schnitt haben, eine Herausforderung dar.

Aus diesem Grund werden immer häufiger Systeme zur rechtssicheren Archivierung von E-Mails und zum Mailbox Management eingesetzt. Auch IBM ist in diesem Markt mit seinem Produkt „IBM Content Collector for Email“ vertreten. Es bietet neben der reinen Compliance Archivierung von E-Mails auch die Möglichkeit des Mailbox Managements durch flexible Archivierungsregeln. Es können sowohl auf der Eingangsseite Microsoft Exchange und IBM Lotus Notes als auch auf der Archivseite IBM Content Manager und IBM FileNet P8 Content Manager bedient werden.

Während der Systemaufbau für kleine und mittelgroße Umgebungen kaum eine Hürde darstellt, müssen bei großen bis sehr großen Umgebungen verschiedene Vorüberlegungen gemacht werden, um einen störungsfreien Betrieb sicherzustellen. Dies gilt umso mehr, wenn mit dem Aufbau einer Lösung auch noch die Migration einer Altanwendung einhergeht. Denn bereits kleine Fehlentscheidungen in der Architektur können später zu massiven Performanceproblemen führen. Für eine Lösung auf Basis von Microsoft Exchange, IBM Content Collector for Email und IBM FileNet P8 Content Manager sollen nachfolgend die wichtigsten Themenfelder und Entscheidungen betrachtet werden.

Betrachtet wird eine etwas größere Exchange Server Umgebung mit 6.000 Usern verteilt auf 20 Exchange Server weltweit. Täglich werden rund 100.000 E-Mails über die Journalarchivierung sowie 100.000 E-Mails über das Mailbox Management verarbeitet, was bei 250 Arbeitstagen zu rund 50 Millionen archivierten E-Mails pro Jahr führt.

Für diese Anforderung müssen die verschiedenen Teile der Archivierungsumgebung betrachtet werden:

• IBM FileNet P8 Content Platform Engine (CPE)

• IBM Content Search Services (CSS)

• IBM Content Collector for Email (ICC)

• Wahl der optimalen SAN Speicherklassen für die einzelnen Teilprozesse

IBM Filenet P8 Content Platform Enigne (CPE)

Aufgrund des in ICC genutzten Datenmodells wird jede E-Mail nur einmal gespeichert („distinct email instance“, DEI). Jede Version der E-Mail, die durch die Journal- oder Mailboxarchivierung archiviert werden soll, stellt dann nur noch eine Verknüpfung zu dieser E-Mail dar („email instance“, EI). Als Richtwert hat es sich bewährt, in einem IBM FileNet P8 Object Store nicht mehr als 150-200 Millionen DEI Objekte zu speichern. Die Menge ist da-bei unter anderem auch abhängig von der Häufigkeit und Größe der Anhänge. Diese haben nämlich maßgeblich Einfluss auf die Größe des Volltext Indexes. Dieser darf für die optimale Performance nämlich nicht zu groß wer-den.

Mit Hilfe der Indexpartitionierung in P8 wird der Index dann anhand des E-Mail Datums in mehrere Teile gesplittet. Dabei hat sich die Teilung in 3- oder 4-monatige Abschnitte als guter Startwert bewährt und sollte mit dem Standardzeitraum der Suche von ICC korrelieren, damit bei einer Suche jeweils nur 1 oder 2 Teilbestände durch-sucht werden müssen. Vorsicht aber bei zu vielen Teilbeständen – auch hier leidet die Performance.

Darüber hinaus muss in einem Object Store bei der Anlage der Storage Area unbedingt die Deduplikation aktiviert werden, damit Attachments nicht mehrfach gespeichert werden. Auf die Kompression sollte unbedingt verzichtet werden, da hier die Performance beim Speichern stark einbricht.

IBM Content Search Services (CSS)

In großen bis sehr großen Installationen sollten mindestens zwei CSS Server vorhanden sein. Dabei wird ein Server nur für die Indexierung genutzt und ein Server nur für die Suchen. Wichtig dabei ist, dass auf beiden Servern die Default Parameter für die CSS Server angepasst werden. Ganz oben auf der Liste stehen dabei die Anpassung der Heap Size sowie die verschiedenen Parameter für die maximalen parallelen Teilprozesse, um die gegebene Hardware bestmöglich auszulasten.

Wenn man aufgrund hoher Last beim Indexieren skalieren muss, ist es nur bis zu einem bestimmten Punkt sinnvoll, einem Server mehr RAM und CPU Cores zu geben. Bei mehr als 8 Cores ist es besser, einen weiteren Server aufzubauen.

IBM Content Collector für E-Mails

Wenn die oben genannten 150-200 Millionen Objekte in einem IBM FileNet P8 Object Store erreicht sind, sollte ein zweiter Object Store erstellt und neue E-Mails dann in diesem gespeichert werden. Am einfachsten geht dies, wenn man hierfür das Partitionierungsfeature von ICC nutzt. Hier kann ebenfalls anhand des E-Mail Datums definiert werden, in welchen P8 Object Store eine E-Mail gespeichert wird. Diese Konfiguration sollte immer mit den Grenzen der Indexpartitionierung in den P8 Object Stores übereinstimmen. Auf diese Weise können bereits vorausschauend neue Speicherbereiche eingerichtet werden, der Roll-over erfolgt dann automatisch.

SAN Speicher

Die einzelnen Teilprozesse haben unterschiedliche Anforderungen an die Performance des SAN Speichers. Der Speicherbereich im P8 für die Dokumente ist hierbei eher unkritisch, da durchaus auch langsamere Laufwerke verwendet werden können. Anders sieht das bei dem Speicherbereich für den Volltext Index aus, hier sollten schnelle SAS Platten oder SSDs zum Einsatz kommen. Ideal ist auch ein 2-tier Storage aus SAS Platten und SSDs, bei denen häufig genutzte Daten in schnellen Datenbereichen liegen.

Anders als in der Dokumentation von IBM beschrieben hat der Einsatz von schnellem Speicher für die temporären Arbeitsverzeichnisse von ICC und CSS keine nennenswerte Auswirkung auf die Performance.

Fazit

In einer IBM Content Collector for Email Installation gibt es noch weit mehr Möglichkeiten, Einfluss auf die Gesamtperformance des Systems zu nehmen. Die hier genannten sind nur ein kleiner Ausschnitt und müssen im konkreten Fall alle im Zusammenhang betrachtet und optimiert werden. Dabei ist es wichtig zu wissen, welche Parameter bereits zu Beginn korrekt dimensioniert werden müssen und welche auch im Lauf der Zeit noch angepasst werden können.

Malte
Ahrens
Service Manager System Integration
Phone: