Reicht ein VPS 200 für kleinen Mailserver?

  • Hallo Forum,


    ich bau zurzeit meine eigenen privaten Dienste um und erneuere dabei auch den Mailserver. Bisher lief für drei Jahre ein Postfix/Dovecot/Amavis/ClamAV/Spamassassin Konstrukt auf Debian Jessie für 7 Mailboxen mit durchschnittlichem Mailaufkommen: inklusive Spam sinds täglich etwa 100 Mails die ankommen, und etwa 10-20 ausgehende. Zurzeit nehmen die Mailboxen 5,4GB Speicher ein. Betriebssystem, Logs, apt Cache machen nochmal etwa 4 GB, also insgesamt knapp 10GB. Das ganze liegt zurzeit auf einem Root Server M Generation 6 (2 Kerne, 6 GB RAM, 240 GB SATA), auf dem sonst nur noch das tägliche Backup läuft. Das ist für 7 Mailboxen völlig sinnlos überdimensioniert.


    Das neue Setup ist Postfix/Dovecot/Rspamd auf Debian Stretch (das Setup von Thomas Leister - kennt man ja). Das einzig aufwändige am alten und neuen Aufbau ist im Prinzip das Spamhandling, und dabei sollte Rspamd noch weniger Ressourcen brauchen, als die Amavis/ClamAV/SpamAssassin Kombination. Daher hab ich überlegt, ob nicht einfach ein VPS 200 G8 mit den 20GB SSD, 2GB RAM und 1 vCore reicht?


    Die Mailboxen werden nicht so schnell größer werden. Nur zwei der Mailboxen sind groß und machen ca. 5 der 5,4GB aus, das sind aber über ein Jahrzehnt gewachsene Mailboxen. Die anderen User löschen regelmäßig die Mails inklusive Papierkorb. Also 20GB SSD reichen. Auch die 2GB RAM werden locker reichen. Unsicher bin ich nur beim vCore. Geteilter, nicht zugesicherter Core. Ich hab verschiedenes dazu im Forum gefunden, aber großteils nur Benchmarks, und wenig praktische Berichte mit den ganz kleinen VPS. Wie verhält sich so ein einzelner vCore? Hat jemand einen Mailserver in ähnlicher Größe auf einem VPS 200 laufen? Hat jemand Erfahrungen mit irgendeinem regelmäßig produktiv genutzten Dienst auf einem VPS 200 (Mailserver, Webserver, Teamspeak, Cloud, ...)? Gibts da manchmal Engpässe? Kanns passieren dass der Server ein halbes Jahr super läuft, und dann kommt jemand auf die gleiche Maschine und nimmt einem ständig Leistung? Beim Mailversand und Empfang ists ja generell eher egal wenns mal ein paar Sekunden länger dauert. Aber ich kann mir vorstellen, dass es unter Umständen bei mehreren Mails gleichzeitig mal knapp wird, und dann vielliecht Mails wegen irgendwelcher Timeouts nicht ankommen. Oder dass vielleicht Dovecot bei etwas mehr Last mal nicht hinterher kommt, und dann der Versandvorgang im Mailclient länger dauert (und da werden User ja schnell mal ungeduldig wenn der Ladebalken mal ein paar Sekunden länger läuft). Oder sind diese Bedenken unnötig und auch ein VPS 200 fadisiert sich bei diesem Mailaufkommen?

  • Ich betreibe mailcow auf einem VPS 500, im Leerlauf sind fast zwei GB RAM belegt, das meiste ist wohl ClamAV, SOGo ist auch recht ressourcenhungrig im Vergleich. Da würde ich mir evtl. Sorgen machen bzw. daher habe ich nicht den VPS 200 gewählt. Der Load bei mir ist bei 0.00 im Leerlauf, da reicht ein Kern locker. Ich bin mir sicher, dass die von anderen Kunden erzeugte Last sich nicht deutlich spürbar auswirken wird.


    EDIT: Ach warte, SOGo wolltest Du ja gar nicht. Na dann sollte auch der RAM kein Problem sein.

  • Meine ganz kleinen VPS mit einem Kern:


    VPS 500 G7

    - 1 vCore

    - 1 GiB RAM

    - 30 GiB SSD

    - Dienste: OpenLDAP mit MDB Backend, MongoDB, PowerDNS


    genesis-VPS500.png


    VPS 100 G7 SEa1

    - 1 vCore

    - 1 GiB

    - 20 GiB SAS

    - Dienste: OpenLDAP Replikation mit MDB Backend, MongoDB, PowerDNS


    nemesis-VPS100.png


    VPS 100 G7 SEa1 (Leistung siehe anderer VPS 100)

    - Dienste: CheckMK Monitoring mit Apache Webserver und Postfix


    zeta-VPS100.png


  • Da ist ja einiges an konkreten Usecases dabei, Danke! Der VPS 200 wird dann schon reichen.


    Mit SOGo hatte ich spekuliert, aber das Exchange Protokoll und die Weboberflächen brauch ich nicht. Einen Webmailclient hab ich auf einem anderen Server mit ein paar anderen Webspaces liegen, dadurch hab ich sowas wie separation of concerns weil Mailen und Webserven schön getrennt sind. Dann lässt es sich etwas besser damit jonglieren und auch die Ansible Playbooks werden schlanker.