Archive Container - Best practice

E-Mails im REDDOXX MailDepot werden in sogenannten Archiv-Containern gespeichert. Die Archiv-Container
sind dafür ausgelegt, eine sehr große Anzahl von einzelnen E-Mails zu speichern und zu indizieren. In einem
einzelnen Archiv-Container können daher problemlos mehrere Millionen E-Mails bzw. mehrere Terabytes
Daten gespeichert werden, wenn entsprechende Voraussetzungen erfüllt sind.

Ein Archiv-Container besteht aus zwei Komponenten, den Daten (Volume-Files) und dem Volltext-Index für die
E-Mails. Die Daten dieser beiden Komponenten werden getrennt voneinander, aber innerhalb eines
gemeinsamen Basis-Verzeichnisses gespeichert.

Damit die Archiv-Container konsistent und problemlos betrieben werden können, ist die richtige Auswahl der
verwendeten Storages wichtig. Für die Auswahl der Storages ist es entscheidend, ob der Archiv-Container noch
beschrieben wird, oder ob er nur lesend in die Appliance eingebunden wird.

Für Archiv-Container, welche noch beschrieben werden (Insbesondere den „Default“ Container) muss ein
ständig verfügbarer Storage bereitgestellt werden. Netzwerk-Freigaben sollten hier unbedingt vermieden
werden.

Archive-Container, welche nur noch gelesen werden, können hingegen auch problemlos von Netzwerk-Freigaben eigebunden werden.

Eine detailliertere Betrachtung der einzelnen Storage-Typen wird später in diesem Dokument beschrieben.

Wie bereits erwähnt, besteht ein Archiv-Container aus 2 Komponenten, welche unterhalb eines gemeinsamen
Basis-Verzeichnis gespeichert werden.

Ein geschlossener Archiv-Container kann daher sehr einfach zwischen Storages kopiert bzw. verschoben
werden. Dazu muss nur das Basis-Verzeichnis incl. Aller unter Verzeichnisse kopiert bzw. verschoben werden.

Ein Archiv-Container, welcher noch in der Appliance oder in anderen Utilities geöffnet ist,
kann nicht konsistent kopiert oder verschoben werden. Es dürfen nur geschlossene Archiv-Container kopiert
oder verschoben werden.

Die Verzeichnisstruktur eines Archiv-Containers ist wie folgt aufgebaut:

Grafik

Info
Die max. Größe der einzelnen Volume-Dateien kann beim Erstellen eines neuen Archiv-Containers festgelegt
werden. Das ist historisch bedingt und ist veraltet.

Der Default beträgt 4096 MB und es gibt keine Notwendigkeit mehr diesen Wert anzupassen.

Prinzipiell können Archiv-Container von beliebigen Datenträgen incl. Netzwerkfreigaben geöffnet und
durchsucht werden.

Archiv-Container, welche noch beschrieben werden, sollten unbedingt auf einem Block-Device abgelegt
werden.

Sowohl der Volltext-Index als auch die Daten-Volumes sind ähnlich wie Datenbanken und haben ständig
Dateien geöffnet, um diese zu beschreiben. Wenn es beim Schreiben von Daten in einen Archiv-Container zu
einer Netzwerkunterbrechung kommt, oder das NAS (z.B. durch einen Neustart) längere Zeit nicht erreichbar
ist, kann es sehr leicht zu inkonsisten Daten kommen, welche ggf. nicht automatisch korrigiert werden können.

Netzwerk-Storages wie NFS- oder CIFS/SMB Freigaben sind daher nicht geeignet, um Archiv-Container, die
noch verändert werden, sicher zu speichern.

Archiv-Container, die nur noch lesend verwendet werden, können hingegen problemlos auch auf Netzwerk-Freigaben gespeichert werden.

Die REDDOXX Appliance unterstützt die Anbindung von verschiedenen Storage-Typen.
Deshalb versuchen wir hier einen Überblick über die Storage-Typen und den empfohlenen Einsatzzweck zu
geben.

Als Local Storage wird ein direkt mit der REDDOXX Appliance verbundener Datenträger bezeichnet. Da die
REDDOXX Appliance inzwischen fast ausschließlich als Virtuelle-Appliance betrieben wird, entspricht der Local
Storage somit einer Virtuellen-Disk der eingesetzten Virtualisierungsumgebung.

Local Storage ist der optimale Storage für das Speichern von Archiv-Container, welche beschrieben werden
sollen. Also insbesondere für den „Default“ Archiv-Container, oder andere Archiv-Container welche z.B. durch
Archiv-Tasks beschrieben werden.

-> NTFS-Formatierte Local Storages

NTFS Formatierte Disks können zwar in die Appliance eingebunden werden, allerdings ist die Performance, in
Verbindung mit Archiv-Containern, deutlich schlechter (bis zu 10-mal langsamer)!

Zudem wird eine deutlich höhere CPU-Auslastung generiert, wenn Archiv-Containern von einer NTFS-formatierten Disk eingebunden werden.

-> Appliance Failover Konfiguration

Local Storage darf nicht verwendet werden, wenn zwei REDDOXX-Appliances als Failover System konfiguriert
sind. Eine Failover Konfiguration mit virtuellen Appliances ist aber weder üblich noch empfohlen.

iSCSI ist, genau wie der Local Storage, ein Block-basierter Storage und ist daher ebenfalls gut für ArchivContainer geeignet, welche beschrieben werden sollen.

Die REDDOXX Appliance unterstützt eine Standardanbindung an iSCSI-Targets.
In Umgebungen wo ISCSI in erweitertem Umfang (z.B. mit Multipath Anbindung) eingesetzt wird, kann das
i.d.R. durch die Virtualisierungslösung umgesetzt werden.

Ist die Virtualisierungslösung bereits an iSCSI angebunden, dann ist es i.d.R. besser Local Disks durch den
Virtualisierer für die Appliance bereitzustellen.

-> NTFS-Formatierte iSCSI Storages

NFS-Freigaben sind gut geeignet, um Archiv-Container einzubinden, von denen ausschließlich gelesen wird.

Beim Schreiben in Archiv-Container, welche auf einer NFS-Freigabe liegen, kann es durch NetzwerkUnterbrechungen kann es zu einem Defekt des Archiv-Containers kommen. Deshalb sollte vermieden werden
Daten in Archiv-Container zu schreiben, wenn diese von einer NFS-Freigabe in die REDDOXX Appliance
eingebunden sind.

Für CIFS/SMB Freigaben gilt das gleiche wie für NFS-Freigaben. Allerdings zeigt die Praxis, dass die Perfomance
der Archiv-Container je nach eingesetztem Storage-Gerät mit CIFS/SMB teilweise deutlich schlechter ist als mit
NFS-Freigaben.
Wir empfehlen daher, CIFS/SMB Freigaben ausschließlich für das Backup der Appliance zu verwenden.

Wie bereits beschrieben, wurden die Archiv-Container für sehr große Datenmengen entwickelt. Das
theoretische Limit eines einzelnen Archiv-Container ist ca. 400 TB bzw. 4 Milliarden E-Mails.

Allerdings ist es in der Praxis aus verschiedenen Gründen nicht sinnvoll so große Archiv-Container entstehen zu
lassen. Zu viele kleine Archiv-Container haben hingegen andere Nachteile und sind genau so wenig sinnvoll.

Generell ist es für die Performance beim Durchsuchen des gesamten Archives besser, wenn es weniger und
dafür größere Archiv-Container gibt. Wenn eine Suche im Archiv durchgeführt wird, dann muss diese Suche in
jedem Volltext-Index der einzelnen Archiv-Container durchgeführt werden, und anschließend müssen die
einzelnen Ergebnisse aggregiert werden. D.h. je mehr Archiv-Container es gibt, desto größer wird der
Performanceverlust durch das Aggregieren der einzelnen Suchergebnisse.

Die Frage lässt sich nicht pauschal beantworten. Rein technisch gesehen kann man sagen, je größer, desto
besser. Allerdings gibt es in der Praxis einige Punkte, die beachtet werden sollten. Die zwei Wichtigsten werden
nachfolgend beschrieben.

Wenn es z.B. nur einen sehr großen Archiv-Container geben würde, dann wäre bei einer Migration (z.B.
Verschieben auf einen anderen Storage) das komplette E-Mail-Archiv für die Dauer der Migration nicht
verfügbar!

Deshalb sollte die max. Größe eines Archiv-Containers so gewählt werden das der Container innerhalb der
eingesetzten Storage Technologien in einer akzeptablen Zeit „bewegt“ werden kann. Durch die Verwendung
mehrerer Archiv-Container können diese z.B. sukzessive migriert werden, ohne dass das E-Mail-Archiv komplett
ausfällt.

Sollte der Volltext-Index eines Archiv-Container defekt sein, kann der Volltext-Index aus den Daten wieder
hergestellt werden. Dieser Prozess benötigt aber Zeit, und während dieser Re-indizierung ist der Archiv-Container natürlich nicht für die Benutzer verfügbar.

In vielen Installationen hat sich die Verwendung von Jahres-Container bewährt.

D.h. es wird ein Archiv-Container pro Jahr erstellt. Wenn ein neuer Container erstellt wurde, kann der vorherige
dann z.B. bei Bedarf auf ein Netzwerk-Storage migriert werden.

Wenn in der Umgebung aber nur wenige E-Mails (z.B. weniger als 1 Million pro Jahr) archiviert werden,
dann ist es ggf. sinnvoll nur alle 2 oder 3 Jahre einen neuen Archiv-Container zu erstellen. Um viele sehr kleine
Archiv-Container zu vermeiden.

Wenn in der Umgebung sehr viele E-Mails (z.B. mehr als 10 Millionen pro Jahr) archiviert werden, dann kann es
sinnvoll sein auch 2 Archiv-Container oder mehr pro Jahr zu erzeugen.