Ich denke über einen Speicher für E-Mails nach. Dieses Speichersystem läuft in meiner eigenen privaten Cloud (bereits repliziert), daher muss ich mich nicht um die Replikation kümmern.
Ich denke über 2 Optionen nach:
1- Ich werde einige „Festplatten“ (Volumen in der Cloud) erstellen und ein Btrfs-Dateisystem auf mehreren Festplatten erstellen. Wenn das Dateisystem voll ist, werde ich weitere „Festplatten“ erstellen und sie dem Btrfs-Dateisystem hinzufügen, indem ich:
btrfs device add /dev/vdX /mnt
btrfs filesystem balance /mnt
Dieser Einhängepunkt (/mnt) wird über NFS verfügbar gemacht und mein Dovecot-Server wird diesen Export einhängen und E-Mails darauf speichern.
2- Ich werde einige „Festplatten“ (Volumen in der Cloud) erstellen und ein verteiltes GlusterFS-Volumen über diese Festplatten erstellen. Wenn das Dateisystem voll ist, werde ich weitere „Festplatten“ erstellen und dem verteilten GlusterFS-Volumen neue „Festplatten“ hinzufügen und es neu ausbalancieren. Mein Dovecote wird dieses Volume mithilfe des GlusterFS-Clients mounten und E-Mails darauf speichern.
(Wiederhole: Ich muss nicht replizieren, da meine „Festplatte“, ein Volume in der privaten Cloud, im Untergrund repliziert wird)
Glauben Sie, welche Option ist besser:
- Leistung? (viele, viele kleine Lese-/Schreib-E/A)
- stabil?
- flexibel?
Antwort1
Sie müssen das I/O-Muster eines Mailservers berücksichtigen: Lesen/Schreibenvielekleine Dateien so schnell wie möglich. Beide Varianten von dir sind dafür bei einer großen Anzahl an Clients meiner Meinung nach wirklich ungeeignet.
Keines der beiden FS ist schnell genug, und ich vermute, dass insbesondere der Sperr-Overhead von GlusterFS erheblich sein wird. Dann fügen Sie mit NFS eine weitere Schicht hinzu, die ihren eigenen Overhead hat. Stattdessen würde ich versuchen, den Mail-Speicher mit möglichst geringem Overhead und mit einem schnellen Dateisystem zu verbinden. Normalerweise bedeutet dies, eine möglichst direkte Verbindung zum physischen Speicher herzustellen, aber da Sie Ihre Architektur hinter bescheuerten Bingo-Begriffen wie „private Cloud“ verstecken, wissen wir nicht, was möglich wäre.
Sie könnten beispielsweise versuchen, den Speicher über iSCSI auf den Mailserver zu exportieren und dann ein schnelles FS mit vielen kleinen Dateien zu verwenden und vielleicht, wenn es wirklich wichtig ist, LVM zu verwenden, um diesem FS in Form von zusätzlichen iSCSI-Volumes einfach Speicherplatz hinzufügen zu können (was wieder etwas Overhead bedeutet).
Was auch immer Sie versuchen: Sie müssen die verschiedenen Varianten vergleichen und prüfen, ob Sie die erforderliche Leistung daraus erzielen.
Antwort2
Wenn Sie eines der beiden oben genannten auswählen müssen, ist meiner Meinung nach NFS vorzuziehen.
GlusterFS verliert in Ihrem Setup alle Vorteile als verteiltes Dateisystem, da OpenStack-Volumes immer noch von einem zentralen Speicher aus gemountet werden. Es ist weder stabiler noch intelligenter, da es sich um verteilte Dateisperren kümmern sollte, während die NFS-Sperre auf einem einzelnen Server erfolgt.
Ich bin nicht sicher, ob es eine gute Idee ist, Ihren Speicher von mehreren Geräten zu kombinieren. Alternativ können Sie die hochrangige OpenStack-Volume-Service-Funktionalität überspringen und Ihren Speicher direkt verfügbar machen – formatiertes LVM(/ZFS/SAN)-Volume, das von NFS exportiert wird. Auf diese Weise eliminieren Sie unnötige iSCSI-Ebenen und können den E-Mail-Speicherplatz bei Bedarf erhöhen, solange der Hauptspeicher über genügend freien Speicherplatz verfügt.