Bonjour à tous,
 
Je dois monter un serveur postfix avec environ 1000 boites mails. Il y aura aussi dessus MySQL et un serveur Apache.
 
Je n'ai jamais monté de serveur postfix pour ce nombre de boites, j'aurais donc besoin de conseils pour le sizing (RAM, CPU surtout).
 
Merci d'avance.

Personne ?, même pas approximativement ?

je sais pas te répondre, par contre un autre paramètre qui peut être important est le nombre de mails traités par seconde, en as-tu une idée ?

Merci de ta réponse.
 
J'en ai aucune idée, c'est pour l'installation d'un nouveau service, je ne connait pas la conso des futurs utilisateurs malheureusement.

à vu de pif sans en savoir plus sur ton besoin
 
je dirait qu'une petite config avec au moins 2 cartes réseau en equilibrage de charge serait suffisante genre 2cores >=2.4Ghz  4Go de ram  
un disque spécialement pour /var et un /var assez grand genre 24Go un swap de 4Go sur le meme disque (essayer d'en prendre un petit en capacité mais rapide) ...ça doit suffir
 
 
si tu veux garantir le coup avec plus costaux avant meme d'en savoir plus
4cores >= 3ghz 16G de ram ecc
2 carte reseau en fail-over_____
2 carte reseau en fail-over_____\____le tout en equilibrage de charge
/var 24Go sur un raid 0 hardware (y coller aussi le swap)
 
là à mon humble avis tu est très largement dimenssionner pour absorber un agrandissement de la charge à l'avenir
 
 
 
Sachant que mysql bouffe peu, apache encore moins mais que ça génére des pics pendant les requettes et que ça écrit beaucoup enfin souvent et bien sur dans /var et les boites mails sont censées être aussi dans /var donc grosse activité pour ce point de montage d'où l'interet qu'il ai sont propre disque séparé réservé à lui seul (et au swap) en raid 0 hardware pour une très grande vitesse d'accès.
 
mais comme le dit Missardonik l'important est surtout de savoir combien de boites mails vont être active en simultané moyen et en pic  
combien de requettes sql simultanées moyennes et en pic ...  
 
n'ayant pas ces infos j'ai pris donc large.

Merci pour ta réponse, je vais me servir de tes infos pour commencer, je ferai évoluer par la suite si besoin.

 
Conseiller du raid0 pour un serveur destiné au stockage de données importantes (mails), c'est de la folie ...
 
Quant au dimensionnement: 24Go pour /var (pour stocker les mails), ça fait ~200Mo par boite.
 
Ne pas séparer la partition où les mails seront stockés de /var est à mon avis pas très judicieux.
 
Si /var est plein, plus de mail, plus de log, plus...
 
 

t'as pas tout compris, mais je vois pourquoi c'est tellement évident pour moi que je l'ai pas assez précisé.
 
alors :  
 
raid0 c'est parce que c'est var et que les BDD+ mails en traffic ça travaille enormément en ecriture/lecture en particulier pour le requettage genre rechercher un vieux mail ce genre de trucs d'autant plus important que comme tu le dis toi meme les mails ne seront  jamais archivés dans /var hors les mails actifs..  
 
la sizing de /var = RAM+SWAP+le reste  
RAM+swap pour pouvoir enregister un coredump en cas de besoin (donc dans mon exemple 16+4=12Go de fichier core....ainsi que les logs des requettes qui bouffent pas mal, et bien sur les spools ouverts...la BDD hors mis ses tablespaces qui seront stockés ailleurs que /var .....etc....donc  ce que j'appele le reste ça et ça seul prendrait probablement 2 à 4 gigas à lui seul... avec 2 à 4 go de reste ça passe bien mes 24Go de /var  
 
un fichier core qui échoue à s'écrire c'est le crash machine.... qd meme....
ou alors faut desactiver sa création mais en cas de crash impossible de corriger le problème parce qu'on l'a pas pour analyser.... c'est stupide...
 
raid 0 n'est donc absoluement pas de la folie mais une solution très réfléchie et appliqué des dizaines de fois en prod et pas chez des petits clients de 100employés ... crois en ma grande experiene un raid0 hardware sur du /var tu doubles ou quasi double les perfs de la machine à minima ... sans aucun problemes...
 
Quand au probleme du soit disant si /var est plein, plus de mail etc... c'est précisément pourquoi je size aussi large le /var  
 
par contre 200Mo de mails box c'est pas normal... un archivage de mail coté user doit être local au user, seuls ses mails entrant non traités peuvent etre dans /var pour des raisons évidentes de securité ...  
les mails sont ainsi tout simplement sauvegardés lors de la sauvegarde journalière des volumes utilisateurs. d'ailleurs les clients lourds, comme légers gèrent très bien ça ....thunderbird pour n'en citer qu'un....
 
mais la question portait sur une demande de puissance machine pas sur un exemple complet d'architecture.    c'est pour ça que je voulais pas me faire chi.... à faire une archi comme si c'était un modèle définitif...
 
Si j'avais parler de solution de stockage j'aurai pas utiliser un raid 0 mais un (raid 6+spare)+DRDB entre des machines en fail-over.... ce qui peut aussi s'appliquer si on veut pousser la logique jusqu'au bout et bien sur plannifier les sauvegardes aussi .... mais je rappelle que la question était une simple évaluation de puissance processeur et quantité de ram à la base.....  

 
Il n'est donc pas nécessaire ici de prendre l' énorme risque de faire du RAID0. Si un disque lache, tu perds tous les mails non sauvegardés arrivés entre la derniere sauvegarde et l'incident
 

 
Core dump qui remplit tout l'espace = saturation = plus de mails, ni de logs.
 

 
du raid0 pour stocker des données critiques...un vrai cauchemar
 

 
autant séparer le spool des logs (par exple) en utilisant LVM.
 

 
Quelles raisons de sécurité ?
 

 
Donc tu ne sauvegardes pas les mails sur le serveur, mais uniquement les profils de tes MUA ?
 

 
Il est vrai
 

 
Il est vrai aussi

tu prétends un risque en raid 0 si on perd un disque on perd tout, c'est vrai sauf que tu oublies un détail c'est que le risque est rigoureusement égale avec un disque unique ou pire encore un LVM parce que là n'importe quel disque de la grappe pete et tu perds tout et pas que /var ... mais tous le(s) VG(s) qui sont dessus il en va de meme d'ialleur avec un disque unique.
 
pourquoi les mails archivés ne doivent pas etre dans /var parce que /var est une partition très sensible et si elle vient à être pleine ou avoir une panne hardware genre disque , evidement ça crash c'est ça le probleme de securité des données...
 
rien n'enmpeche le cumul raid+lvm mais ça complexifie un peu l'architecture et surtout il faut bien réflechir avant un agrandissement par exemple. mais effectivement rien n'empeche pour la partie stockage de faire comme ça
 
 
 
 
la size du /var permet justement de ne pas saturer meme avec un core dump ...  c'est précisément l'inverse de ce que tu a compris.   manifestement.
 

Faire du raid0 me semble un conseil fort mauvais eu égard au risque de perte de données. L'utilisation de LVM (qui au passage peut se faire au é"dessus" du raid qu'il soit hard ou soft) n'entrant pas en ligne de compte dans la sécurité des données.
 
Aucun mail (même entrant) ne devrait se trouver dans /var.
 
Tes gros clients peuvent-ils se permettre de perdre les 4 derinières heures de mails reçus ?

mais c'est faut le risque de perte est rigoureusement identique en raid0 et sur un disque unique ... à vrai dire dans la réalité c'est meme pire avec un disque unique puisqu'on utilise en general des grands disques surpartitionnés... au lieu de petits disques dédiés. faut vraiment que tu progresses sur ce sujet la et qu'il t'arrives une grosse merde en prod un jour pour que tu comprennes      je crois que oui et donc te le souhaites fortement    mode super-vilain activé....      
 
non bien sur que non seuls les mails non traités peuvent être perdus, avec un système comme ça ... puisque tout mail lu meme sans réponse passe en zone archive. sur disque donc....ne racontes pas n'importe quoi non plus ...  
personne ne perdra jamais 4heures de mails meme une personne en vacances ... parce qu'ils seront dans les mails en attentes et donc sauvés pas en local dans la zone disque des utilisateurs mais ça change rien ce sera sauvé qd meme.
 
alors puisque tu vas encore tenté d'argumenter pour être bien sur d'avoir le dernier mot pour je ne sais quelle raison, j'anticipe de suite  
donc il faut  
sauver les mails archivé avec un certain rythme disons differentielle entre 12h et 14h....
sauver les mails archivé avec un certain rythme disons à froid la nuit
sauver la partie /var en differentiel asynchrone toutes les disons 30 minutes ou mieux encore l'avoir en DRDB synchrone
sauver la partie /var en full la nuit et le weekend...
 
c'est tout ça suffit largement....à éviter tous les cas de problèmes que tu as cité jusque là.

Je persiste à dire que le raid0 est un risque inutile. Plus tu augmente le nombre de disques en raid0, plus tu augmente les risques. Un RAID1, 6, voire 10 permet de ne *pas* perdre de données.
 
Exemple:
Tu reçois un mail (il est stocké dans /var/mail/$USER), 3 secondes après, ton disque lache. Tu as perdu ton mail
 
Avec une machine dont les disques sont en raid 1/6/10 (voire 5), tu n'aurais rien perdu.

j'ai compris tu confond raid et sauvegarde et stockage...
 
 
raid0=vitesse pas redondance c'est vrai ...
mais rien ne t'empeche de faire du cumulatif 0+1 ou 1+0 en l'occurence serait mieux... ou 5+0  etc...
 
mais pour des raisons de vitesse et cout de maintenance mieux vaut perdre un /var sur une machine qu'autre chose, en particulier si on a en plus un drdb...
ou des sauvegardes quotidiennes ou  une synchronisation ce qui dans les deux cas remplace un raid 1 ...si on fait les deux en plus....

Je ne confond rien du tout.
 
Perdre /var sur une machine stockant ses mails dans /var conduit potentiellement à:
- crash de la machine
- perte de données
 
Ce qui est loin d'être judicieux...
 
Tous les gens sérieux en entreprise font du RAID à des niveaux autres que 0 pour l'OS *et* les données qu'il est important de ne pas perdre...mais on s'éloigne du sujet initial.

depuis le depart on parle d'un mail stocké ailleurs d'une part puis de cas prévus empéchant la perte de donnée en cas de crash  justement que ce soit le plus transparent possible en cas de pépin  
et bien sur que si /var peut devoir et meme c'est très souvent le cas comme tmp ou encore le swap être sur du raid0 voir du 1+0 à la limite quand il n'y a pas redondance de la machine elle meme ...genre HA ou drdb ca plantera pas les utilisateurs, et ça perd pas de données... tu peux te demerder comme tu veux  au pire les sessions ouvertes vont être interrompues
je suis désolé de t'apprendre des trucs mais c'est le cas ! et dans le cas d'un serveur mail vu le nombre d'accès jour à /Var c'est très hautement pertinnant les i niveaux de raid 1 ou 5 ou 6 sont assez lents plus lents qu'un disque unque en tout cas, par dessu le marché ... et comme je l'ai dit plus haut dans un autre post rien n'interdit de faire du 0+1 ou du 0+5 et encore avec un planning de sauvegardes ou de synchro on peut largement s'en passer à condition d'avoir prévu un /var très large comme je le disais au début, avec bien sur tout les mails stockés ailleurs que /var ... on tourne en rond là...

Appelles une boîte privé IT spécialiste la dedans (Cad toute ) et demande leur un devis

En entreprise on a 6000 disques dans une baie dédiée et on a des lvolume pour les applications.  C'est un mix de tous les raids existant et ça autorise la perte d'une paquet de disques..

Mais bon si a 20 ans ta pas 300 000€ à foutre la dedans ta loupé ta vie

Tu dis nimp,  à disque égal tu as 2n * plus de chance de perdre tes data avec un raid 0 à n disque

 
J'en connais une petite pas mal, ça s'appelle google    
 
Sinon pour en revenir à la polémique, je suis d'accord avec Sndk.  

 
Il me semble même avoir compris en survolant les pages de man que lvm peut gérer nativement plusieurs types de raid, sans se baser sur mdraid.

 
 
dans un monde fictif mathematique oui
 
dans le monde réel non pourquoi ?
parce que depuis le depart je parle c'est précisé sans arrêt), de raid hardware, probablement du SAS donc actuellement avec un taux de panne ridicule comparer à une serveur "de base" en SATA par exemple....le ratio est très en faveur du SAS....et compencse à l'aise la resolution mathématique

L'avantage c'est que t'as plus besoin du check nagios pour vérifier l'état des raid

 
désolé mais tu dis n'importe quoi. Des disques durs il en pète en tous les jours, des sas y compris. Si tu n'en as jamais perdu un tu as eu de la chance et c'est tant mieux pour toi, mais tu ne peux pas te limiter à ça.

ok que si j'en ai perdu et meme en prod mais comme j'ai fait des architecture avec des paliatifs j'ai tjrs evité la perte de donnée, des exemples sont dans ce post d'ailleurs...
 
quand à ton soit disans n'importe quoi sur les taux de pertes SAS comparés à du SATA ou de l'IDE ou du SCSI c'est très clair que le scsi et le sas se petent moins et y'a vraiment pas photo... meme si il reste vrai que des pannes peuvent tjrs arriver ... la probabilité est faible  
ça plus les paliatifs indiqués où on a une tolérance aux pannes assez enorme ... le risque est très faible alors qu'un disque unique n'a aucune tolérence aux pannes par définition + une probabilité de panne un peu supérieur ... donc 2 raisons de risques supplémentaires.
 
et enfin si tu avais lu le post tu verrais en prime que j'ai tjrs dit qu'ajouter une couche genre 1+0 ou 5+0 de raid était un très bon complément sans se priver des perfs. contrairement à un raid5 nu par exemple.
 
mais ca ne change rien aux faits et"les faits ça peut pas se discuter" voir "la methode scientifique"  
 
Quand à la question initiale à part moi quelqu'un à réfléchi aux perfds CPU et RAM ?
 
 

bah en fait ce qui serait pas mal ce serait déjà de savoir si le serveur sera une VM ou pas et dans quel genre d'infra
ça coupera cours à toute les discussions sur le nombre de carte réseau et le RAID si c'est pris en charge dans la couche en dessous, non ?    
Faut savoir aussi si y'a de l'antivirus, de l'antispam, du webmail et avoir une fourchette sur le volume de mails entrants et sortant.
 
enfin là comme ça, j'ai envie de dire "42"    
 
 
 
sinon j'adore ce topic