Comment tailler une machine en fonction d'un besoin (serveur de mail ici) ?

Hello,

Plutôt que de faire un truc un peu au hasard et dimensionner à chaud (ce qui est rendu possible grâce à la virtualisation), j’aimerais savoir comment vous, vous faites pour tailler une machine au niveau des besoins en terme de CPU et de RAM.

Dans mon cas, je prépare un serveur de mail qui hébergera environ 20000 comptes, il y aura des gros, des petits et des non utilisateurs.
Mon serveur physique a largement de quoi donner à manger la VM qui va héberger ça, mais j’aimerais quand même bien tailler juste (tomber par trop loin) dès le départ… Il doit bien y avoir un moyen de calculer ça.
J’ai cherché de la doc à ce sujet, voir même des outils, mais je n’ai rien trouvé de probant.

A la louche, je tablerais sur 60000 mais reçus et autant émis. Cette estimation se base sur le serveur de mail que j’héberge déjà, à laquelle je rajoute de nouveaux utilisateurs.

Je pense qu’en RAM, 8G seront suffisants, par contre en CPU, vu que chaque mail émis/envoyé passe à rspamd et clamav, je pense qu’il faut prévoir large, mais comment définir “large” ?

Ce volume impressionnant c’est sur une durée en décades ou en décennies ? :joy:

Parfait, comme je suppose qu’à part la messagerie il n’y aura que des tâches administratives de routine, j’allouerais directement 80 %, voire 90 % des ressources à la VM. Quelle technologie de virtualisation utilisez-vous ?

Pourquoi un serveur, une grappe de serveurs ne serait-elle pas plus adaptée ? Et vous pouvez obtenir une architecture redondante.
Comment se feront les sauvegardes ?

Cordialement,
Regards,
Mit freundlichen Grüßen,
مع تحياتي الخالصة


F. Petitjean
Ingénieur civil du Génie Maritime.

« Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » (R. Devos)

Concernant le volume de mails, quand j’atteins des pics, avec 3500/4000 comptes, nous ne sommes pas loin de 15000/17000 mails émis, en envois comme en réception. Attention, j’englobe tout, y compris les mails de retours de postfix.
Donc je table sur une limite très haute pour être tranquille, je pense (et j’espère) ne pas arriver aux 3/4 de cette limite. C’est difficilement prédictible en fait, car les 16000 nouveaux comptes seront attribués à des particuliers et non des fonctionnels, je ne sais donc pas comment leur ils vont utiliser leur BAL. Mes filtres d’envois seront assez restrictifs pour éviter qu’ils envoient/reçoivent de la m***.

Mon serveur physique est un Intel Xeon-E 2136 - 6 c / 12 t - 3.3 GHz / 4.5 GHz avec 32 G de RAM.

Ce serveur hébergera donc la VM de messagerie et potentiellement d’autres serveurs (web, application), si la charge le permet. Dans un premier temps, je laisserai tout ce qui est Nginx et BDD tourner sur les 2 VPS existants, ils font bien leur boulot, inutile de charger l’hyperviseur avec ça.

Pour la sauvegarde des mails, c’est encore de négociation… c’est un sujet sensible, car le financement n’est pas illimité.
Pour le reste, des sauvegardes existent déjà, du full à de l’incrémentale.

Pour la redondance, il n’y en a pas. L’entité qui m’emploie n’est pas sur un système de profit, mais de dépense. Si il y a une panne, ce n’est pas la fin du monde (même si je dois éviter coûte que coûte que cela arrive), en revanche il ne doit pas y avoir de perte ou de fuite de donnée.

Pourquoi “un” serveur ? Parceque j’ai déjà eu du mal de leur faire comprendre qu’il fallait passer à des serveurs physiques plutôt que des VPS dans un premier temps :wink:

L’autre souci est la place. Il me fallait 4to, et ça, il n’y a qu’un serveur dédié OVH qui peut m’offrir ça, leur VPS sont limités à 500gb. Pour héberger 20000 comptes mails, ça fait juste… Donc si je voulais faire du clustering, il me faudrait un autre serveur et ça, je ne suis pas sûre qu’ils acceptent de payer !

Concernant la technologie, c’est du pure KVM administré à coup de virsh.

Je ne sais toujours pas sur quelle période de temps. 15 000 messages transférés c’est le nombre pour une minute, une heure, une journée, une semaine ? (vraie question)
Une des choses que j’ai appris en école d’ingénieur, il y a 45 ans, c’est l’importance des ordres de grandeur et des unités. D’où l’intérêt des coefficients adimensionnels.

Pour le dimensionnement de la VM, je n’ai en fait aucune idée et C’est vous qui voyez !

Cordialement,
Regards,
Mit freundlichen Grüßen,
مع تحياتي الخالصة


F. Petitjean
Ingénieur civil du Génie Maritime.

Le jugement est la faculté de penser le particulier comme contenu dans le général.
-± Emmanuel Kant -±

Certes,

Mais réfléchis un peu.

17 000 mails (envoi et réception) pour 4 000 comptes, ça fait une moyenne d’un peu plus de 4 mails.

A vue de nez, je dirais que c’est /jour.

Une chose que j’ai apprise dans ma carrière d’ingénieur, c’est que quand il te manque des informations, tu fais des hypothèses (que tu vérifies par la suite).

Amicalement.

Jean-Marie

Oui, excusez moi, c’est effectivement par jour.

Je n’ai pas la même expérience que vous et vous semblez tous les deux dire peu ou prou la même chose : pas de règle, on teste et on ajuste.

Si c’est bien ça, ça répond à ma question.

Du coup, je vais ouvrir le service progressivement et voir comment ça réagit, j’ajusterai en fonction.

Le problème, c’est qu’avec ce genre de service, tu as souvent un effet de seuil (je pense surtout à rspamd et clamav).

Dans un premier temps, la charge (cpu, mémoire, disque ?) croît à peu près linéairement en fonction du nombre de mails par unité de temps. Puis on arrive à ce “seuil” à partir duquel ça se met à croître beaucoup plus vite et il est très difficile de tailler ça a priori.

Si tu as un PC sous la main, tu peux te faire un démonstrateur sur lequel tu mets entre 100 et 1000 comptes, tu regardes ce que ça donne puis tu fais des règles de trois (en nombre de cœurs, fréquence d’horloge, taille mémoire, nombre de mails…).

Désolé de ne pouvoir t’aider plus.

Amicalement.

Jean-Marie

1 J'aime

Doucement, à mon taff nous avons des serveurs en relai qui font sans doute au de là par heure.
La question est légitime, j’ai déjà eu un serveur hébergeant une adresse compromise ayant initié de l’e-mail bombing et là ce sont des 2 à 3 million de mail / heure que l’on tentent d’envoyer.

cpu 4c 4t avec 8Go de ram sera largement assez pour s’occuper du volume journalier que tu précise.

Par contre pour tous ce qui est webmail et autres joyeusetées il faudra voir ça ailleurs ou augmenté les ressources.

1 J'aime

Une des techniques est de répartir. Si tu pars sur des VM, tu peux decoreler la partie messagerie de la partie anti-virus.

Du coup une VM de messagerie n’aura pas forcement besoin de beaucoup de mémoire ni de CPU mais de disque. ensuite tu peux faire deux petites VM, avec peu de disque un peu de mémoire et surtout du CPU, en loadbalancing comme ça tu reparties la charge. Comme ça tu évites les effets de seuils.

en fait en messagerie le nombre de compte n’a pas beaucoup d’importance au regard du volume de messages.

Enfin si tu supervise tes serveurs, tu peux faire en sorte de générer des alertes au regard des ressources utilisées et adapter ton serveur au fur et à mesure.

1 J'aime

Merci pour vos conseils et retours.

La solution de répartir sur plusieurs VM est très bonne, le « problème » est que pour le moment, mes différentes VMs ne se voient que par une interface publique, je suis actuellement en train de monter un réseau privé pour connecter tout ça plus proprement.
Quand le réseau privé sera monté, je ferai cette répartition.

Pour le moment, le trafic est beaucoup plus faible qu’imaginé, car je n’utilise actuellement que des nouveaux domaines (pour la surveillance et les comptes « privés » que seulement 5% de mes utilisateurs utilisent), j’ai donc un trafic très limité sur ce serveur en particulier.

Je vais rapatrier les gros domaines une fois seulement que j’aurai monté une infra réseau plus élaborée (travailler que sur du WAN n’est pas viable à terme, ne serait-ce que pour la sauvegarde), et donc, je passerai à ce moment sur une architecture où tout est éclaté :
vm1 : frontal nginx
vm2 : bdd
vm3 : mailing pure 1
vm4 : mailing pure 2
vm5 : antivirus
NAS/SAN : stockage des boites

Là, actuellement, tout est sur une seule grosse VM. Ça tient la route, mais c’est loin d’être optimal si on veut vraiment bien faire les choses (j’avance à mesure que le budget le permet aussi).

d’après mon expérience parmi les trucs importants:

  • limite sur le nombre de destinataire d’un courriel
  • limite sur le nombre d’envoi par minute d’un utilisateur
  • éventuellement avoir un système de gestion de listes de diffusion pour les utilisateurs qui veulent envoyer plus de courriel
  • s’assurer que quand tu envoies à plusieurs utilisateurs, le mail n’est scanné par l’antivirus qu’une fois.