Installation mit vielen E-Mail-Tickets Attachment Storage

[Stril]

Hallo,

ich betreibe seit 3 Monaten eine OTRS-Installation. In das System laufen pro Tag ca. 700 Mails.

Ein Problem machen mir dabei die Mailattachments.

Nachdem die Datenbank "unhandlich" groß wurde, habe ich die Attachments in das Filesystem ausgelagert. Jetzt habe ich inzwischen 11GB kleiner Dateien, die kaum handelbar sind, weil es einfach viel zu viele Dateien sind. Eine einzige Mail erzeugt dabei meistens ca. 7 Files:


file-1 file-2 plain.txt
file-1.content_alternative file-2.content_alternative

Daher meine Fragen:
- Wie geht ihr mit dieser Datenflut um? Behaltet ihr die Attachments in der Datenbank und "lebt" mit vielen, vielen GB großen mysql-Datenbanken?
- Gibt es eine Möglichkeit, die Attachments komprimiert vorzuhalten?
- Können alte Attachments irgendwie "archiviert" werden?
- Gibt es noch einen ganz anderen, besseren Weg?

Ich würde gerne noch mehr über das OTRS-System abwickeln können, aber dann habe ich ein Aufkommen von locker 6 Mio Tickets pro Jahr...

Vielen Dank für euere Hilfe

Phil

[root]

Hallo,

ich betreibe seit 3 Monaten eine OTRS-Installation. In das System laufen pro Tag ca. 700 Mails.

Ein Problem machen mir dabei die Mailattachments.

Nachdem die Datenbank "unhandlich" groß wurde, habe ich die Attachments in das Filesystem ausgelagert. Jetzt habe ich inzwischen 11GB kleiner Dateien, die kaum handelbar sind, weil es einfach viel zu viele Dateien sind. Eine einzige Mail erzeugt dabei meistens ca. 7 Files:


file-1 file-2 plain.txt
file-1.content_alternative file-2.content_alternative

Daher meine Fragen:
- Wie geht ihr mit dieser Datenflut um? Behaltet ihr die Attachments in der Datenbank und "lebt" mit vielen, vielen GB großen mysql-Datenbanken?
- Gibt es eine Möglichkeit, die Attachments komprimiert vorzuhalten?
- Können alte Attachments irgendwie "archiviert" werden?
- Gibt es noch einen ganz anderen, besseren Weg?

Ich würde gerne noch mehr über das OTRS-System abwickeln können, aber dann habe ich ein Aufkommen von locker 6 Mio Tickets pro Jahr...

zu 1.) Ich lasse die Daten einfach da wo sie sind. Und Attachments gehören auch nicht in die Datenbank, das bremst nur unnötig (ca. 200.000 Dateien unter /opt/otrs/var/article/YEAR).
zu 2.) Für einen Apache Webserver könnte man einiges zwar (vor-)komprimieren, allerdings dürfte dann das eine oder andere OTRS-Modul Probleme mit den Dateien haben.

Welches Problem hast Du denn genau mit der Menge an kleinen Dateien?

hth,
Roy

[Stril]

Hallo!

Welches Problem hast Du denn genau mit der Menge an kleinen Dateien?

Ich habe damit zwei Probleme:
- Die Datenmenge ist enorm, weil in keinster Weise komprimiert wird.
- Sollte ich irgendwann einmal auf ein anderes System migrieren müssen, dürfte es ziemlich schrecklich sein, die "Minidateien" zu kopieren. Das Gleiche gilt für das Backup.

Gruß
Phil

[root]

Ich habe damit zwei Probleme:
- Die Datenmenge ist enorm, weil in keinster Weise komprimiert wird.
- Sollte ich irgendwann einmal auf ein anderes System migrieren müssen, dürfte es ziemlich schrecklich sein, die "Minidateien" zu kopieren. Das Gleiche gilt für das Backup.

Das Problem mit der Datenmenge hätte ich jetzt nicht erwartet, da ja Plattenplatz relativ günstig ist. Eventuell hilft da das Feature Add-On von OTRS 'Delete Attachments',
was aber kostenpflichtig ist. Alternativ sollte man sich überlegen wie lange man die Tickets aufheben möchte. Ich lösche alle Vorgänge die aus dem drittletzten Kalenderjahr sind.
Das Backup halte ich für unproblematisch. Ich nutze dafür unter Linux eine LVM-Volume mit folgendem Ablauf mit dem ich dann ausreichend Zeit zum Sichern habe:

1. Cron Daemon stoppen.
2. Alternative VirtualHost Konfiguration für Webserver laden mit dem Hinweis 'Wartung'.
3. Dump der Datenbank.
4. Snapshot von /opt/otrs via lvm2.
5. Datenbank starten.
6. Webserver wieder 'normal' konfigurieren.
7. LVM-Snapshot mounten und die Daten sichern.
8. LVM-Snapshot unmounten und löschen.


Wegen einer Migration habe ich mir noch nie Sorgen gemacht. Ich habe für /opt/otrs ein eigenes Volume im SAN, bei einer Migration wird das einfach der neuen Maschine präsentiert.
Wenn man kein SAN zur Verfügung hat, tut's auch eine externe SCSI/SAS-Box zum Beispiel.

Gruß,
Roy