Salut tout le monde!
Alors voilà, je m'interroge un peu sur la puissance nécessaire pour un serveur devant fournir les services suivants:
- sendmail (900 comptes utilisateurs, limités à 5Mo), couplé à clamav et spamassassin
- samba en controleur de domaine principal (350 profils itinérants)
- DHCP
- Proxy pour 900 postes
- et bastion, basé sur netfilter.
Moi, j'envisage comme solution une boite du style:
- bi Proc (Athlon XP Bartone), 2,2GHz
- 1Go en mémoire, 2*120GO en miroir
- 2 cartes 1000Tx montées en bonding
- 1 carte 100Tx pour l'accés internet
- une fedora ou une debian stable
Je sais que normalement il serait préférable d'utiliser une bécane pour chacun des services, une pour le parefeu, une autre pour samba, et une autre pour sendmail, mais pour des questions de budget, ça passera pas. Au départ, on devait mettre un P4 2.6G avec la même config mais j'ai peur que ça fasse vraiment juste.
Dites moi ce que vous en pensez ...
Pour info, l'accés internet se fait sur SDSL 1024
# Re: info sur la Puissance du serveur nécessaire
Posté par Matthieu BENOIST . Évalué à 3.
Je ferrai 3 machines à ta place, ça t'évitera des problèmes par la suite AMHA
[^] # Re: info sur la Puissance du serveur nécessaire
Posté par Nap . Évalué à 2.
de plus ça n'est pas très sûr d'héberger des services sur une machine faisant office de firewall... si jamais un maichan pirate exploite une faille d'un des services et prends le contrôle de la machine, alors ton réseau n'est plus protégé du tout.
Sinon pour la puissance nécessaire à samba, le mieux est de poser la question sur la mailing list (très active)
[^] # Re: info sur la Puissance du serveur nécessaire
Posté par Matthieu BENOIST . Évalué à 2.
J'ai pas autant de poste à gérer dans mon entreprise (moins d'une centaine) et les machines utilisée sont des vieillerie. (la plus puissante, pour le mail est un PII400, 256 Mo de ram, et 2 disque de 80 Go en raid logiciel. la pire est un P133 avec 16 Mo de ram et un noyau 2.2, mais elle va bientot gigler.
Donc ta config ma l'air acceptable :) à par contre, sur la PII400 je gère les mails via kolab + spamassassin + antivirus.
spamassassin est plutot lent.
Il te faudrait au moins des alims redondantes, AMHA
[^] # Re: info sur la Puissance du serveur nécessaire
Posté par Là Yop . Évalué à 3.
[^] # Re: info sur la Puissance du serveur nécessaire
Posté par Nap . Évalué à 4.
[^] # Re: info sur la Puissance du serveur nécessaire
Posté par Matthieu BENOIST . Évalué à 2.
~~~>[] je sort (autre fin de posts souvent utilisée ^_^ )
# Re: info sur la Puissance du serveur nécessaire
Posté par Prosper . Évalué à 5.
Sinon personnelement je te conseillerais de prendre une debian stable avec quelques sources suplementaires bien choisie ( en particulier pour sa, clamav et samba ) plutot que une fedora bien trop jeune a mon gout et surtout bien plus galere a administrer qu une debian ( c est une redhat quoi ... ) , d autre part je comprends pas trop le choix de sendmail , postfix conviendrait bcq mieux ( plus performant , plus facile a configurer , plus secure ).
[^] # Re: info sur la Puissance du serveur nécessaire
Posté par Matthieu BENOIST . Évalué à 1.
[^] # Re: info sur la Puissance du serveur nécessaire
Posté par aurel (site web personnel, Mastodon) . Évalué à 2.
troll detected...
l'administration d'une fedora n'est pas plus casse tete que celle d'une debian. essaye et tu verras par toi meme.
[^] # Re: info sur la Puissance du serveur nécessaire
Posté par Moby-Dik . Évalué à -2.
[^] # Re: info sur la Puissance du serveur nécessaire
Posté par aurel (site web personnel, Mastodon) . Évalué à 1.
C'est pas crédible de donner son avis sans argumenter.
[^] # Re: info sur la Puissance du serveur nécessaire
Posté par guhh . Évalué à 0.
-> sécurité : prend Postfix ;
-> facilité d'admin/mise en place : prend Exim.
# Puissance du serveur(s)
Posté par Quzqo . Évalué à 4.
- netfilter
- DHCP/DNS (à voir)
Tu auras ainsi une meilleure sécurité en plaçant le second serveur en DMZ. A mon sens, netfilter est beaucoup plus souple à configurer que chacune des applications citées (Proxy, mail, samba, ...). Et cela représente un point centralisé à administrer pour ce qui est des droits d'accès Intranet/Internet au niveau IP. Je n'imagine pas cette tâche très consommatrice en CPU; seule la mémoire peut définir la taille de tes tables de routage (voir docs du kernel/netfilter/iptable).
Concernant les autres services, j'ai peur que tes 120 Go soient un peu justes pour hébergé 350 profils itinérants + système + données partagées... surtout s'il s'agit de profils Windows qui a la facheuse habitude de proposer par, défaut, la sauvegarde dans l'espace du profil si je me souviens bien. Pour peu que les utilisateurs soient négligeants...
En revanche, le bi-proc + 1Go de mémoire (voir un peu plus?) représente un gain appréciable en environnement multitâche. Je pense que ce choix reste le meilleur au vu des services que tu souhaites proposer, notamment mail+clamav/spamassassin et samba (accès R/W sur de l'IDE) qui sont consommateurs en CPU/mémoire.
La bande passante ne me semble pas de trop pour partager les fichiers ET mettre à jour les profils itinérants de manière transparente (surtout le soir lorsque tout le monde se délogue vers 18h00 ;o). A ce propos, je te conseille de faire le tour des benchmarks des cartes car le full-duplex peut devenir *très* consommateur en CPU sur certains modèles (en tous cas, j'ai pu le vérifier en 10/100 Mb/s entre du 3Com, Netgear et RealTek).
Pour affiner ton choix, tu peux aussi jeter un oeil sur des logiciels comme mrtg qui propose des exemples d'utilisation avec de véritables statistiques (voir liens depuis le site, je n'ai rien sous la main dsl) avec #users #mem #load ... ou faire le tour des recommandations d'hébergeurs (?) au besoin leur demander des devis.
PS: du SATA, voir du SCSI ne serait-il pas envisageable/intéressant ?
[^] # Re: Puissance du serveur(s)
Posté par Mickael_83 . Évalué à 1.
Pour les softs de stats, j'utiliserai plutôt cacti, moins "barbare" pour l'utilisateur final et assez complet, en plus l'admin sur place débute sous linux, il n'est donc pas très à l'aise encore.
Plus tard, il est possible qu'on délègue effectivement samba et les mails sur 2 bécanes dédiés, mais pour l'instant, y'en aura qu'une seule (question budget et subvention).
Et Netfilter (iptables) est effectivement un produit très efficace, bien configuré, la machine est quasi imprenable, à moins d'y passer vraiment beaucoup de temps (comme d'hab, la perfection n'est pas de ce monde :-) )
[^] # Re: Puissance du serveur(s)
Posté par ckyl . Évalué à 1.
Si en plus la machine qui fait firewall est la même que celle qui heberge les services...
Enfin c'est juste ce que j'en dis :-)
[^] # Re: Puissance du serveur(s)
Posté par Mickael_83 . Évalué à 1.
Non, y'aura pas apache, et samba, il apparaitra certaine pas sur l'interface externe (pas fou non plus)
# Re: info sur la Puissance du serveur nécessaire
Posté par Yves Agostini (site web personnel) . Évalué à 1.
appreciez l'uptime
os[Linux 2.4.18- Debian 3.0]
up[ 497+60 jours, 5 heures, 18 minutes]
cpu[AMD Athlon(tm) XP 2000+, 1.67 GHz (3322.67 bogomips)]
charge[ 0.07]
mem[ 867.3/878.83 MB (98.7% libre)]
ethernet[ 3Com Corporation 3c905C-TX [Fast Etherlink] (#2) (rev 120).]
raid[Distributed Processing Technology SmartRAID V Controller (rev 2).]
disk[ 37.52/168.18 GB (22.3%) ()]
27000 comptes samba crees
3000 utilisateurs 50M en profils itinerants
150 machines
home de 164G (4*80 G en raid ide) utilise a 23%
firewall
squidGuard
dhcp
mon avis :
les cartes 1000Tx ne servent a rien 100M c'est tout a fait suffisant, ca doit meme inutilement charger les procs
mais de la ram, de la ram, de la ram, surtout pour spamassassine clamav
les seuls problemes viennent de la gestion des profits itinerants avec des bases de registres qui s'abiment et la gestion des quotas sur XP
[^] # Re: info sur la Puissance du serveur nécessaire
Posté par Nÿco (site web personnel) . Évalué à 2.
[^] # Re: info sur la Puissance du serveur nécessaire
Posté par Prosper . Évalué à 1.
enfin bon comme dirait l autre , y a d autre moyen pour montrer que t as une grosse bite.
[^] # Re: info sur la Puissance du serveur nécessaire
Posté par Yves Agostini (site web personnel) . Évalué à 1.
Concernant le kernel non à jour, si aucun des 3000 utilisateurs n'a de shell, que les serveurs sont à jours et qu'ancun code externe n'est utilisable, par exemple php avec empoisonnement des logs, un noyau troué ne pose pas de problème...
Concernant, l'uptime de "497+60 jours" c'est bien sur moi qui ai rajouté le 497. C'est bien de savoir que le compteur est remis a zéro après 497, c'est une remarque très intéressante !
Concernant le load et la ram, en lisant correctement on verra que sur cette machine il n'y a pas de mail et que si l'on veut en mettre avec de l'antivirus il faut de la ram, de la ram, de la ram. Tiens, je me repète ...
En terminant à propos de plus grosse : c'est une machine à 2000 Euros, c'est donc loin d'être une grosse ;)
Ceux qui savent lire et réfléchir, en tireront certaines conclusions qui n'apparaissent pas évidentes à d'autres :
- iptable et samba sont très performant et demandent très peu de ressources
- les problèmes viennent des clients windows
- les raids ide sont suffisament performant
et donc il faut préférrer de la ram à du proc et des cartes réseaux Giga
[^] # Re: info sur la Puissance du serveur nécessaire
Posté par -=[ silmaril ]=- (site web personnel) . Évalué à 1.
[^] # Re: info sur la Puissance du serveur nécessaire
Posté par Prosper . Évalué à 1.
ahahah !
Concernant le kernel non à jour, si aucun des 3000 utilisateurs n'a de shell, que les serveurs sont à jours et qu'ancun code externe n'est utilisable, par exemple php avec empoisonnement des logs, un noyau troué ne pose pas de problème...
une grosse partie des attaques se fait par un gain remote shell , le fait de ne pas avoir un shell n empeche en AUCUN CAS de peter une machine . un shell ca peut s obstenir de plusieurs facons ( l exemple de savanah ou security.debian.org est assez frappant ) enfin bon chacun sa conception de la securité.
Concernant, l'uptime de "497+60 jours" c'est bien sur moi qui ai rajouté le 497. C'est bien de savoir que le compteur est remis a zéro après 497, c'est une remarque très intéressante !
mm je vois pourquoi tu me parles de ca mais bon , je preciserais que c est corrigé dans le 2.6 , l "uptime ticker etant codé en 64bits , la limite est du fait du codage en 32bits de l uptime ( mesuré en ms cf /proc/uptime ) dans les kernels 2.4.x , ca peut meme passer a 49.7 jours si on s amuse a changer la valeur Hz a1000 ce qui etait conseillé pour avoir un kernel avec une faible latence .
[^] # Re: info sur la Puissance du serveur nécessaire
Posté par Yves Agostini (site web personnel) . Évalué à 1.
Cependant tu peux essayer la commande "/bin/rm -rf ~/*" en user space sur ton noyau patché ... tu apprécieras le résultat. Pour mémoire avant d'accéder au noyau il y a quelques étapes supplémentaires. On parlera une autre fois de sécurité.
Sinon la remarque "intéressante" était ironique, l'objectif était de démontrer que ce type de serveurs est une solution viable puisqu'en fonctionnement depuis un an et demi. On peut rajouter que je n'ai jamais enendu parler de serveur Microsoft unique avec 27000 comptes créés et 3000 utilisés.
Et la conclusion est que pour le problème posé cela ne dépend pas vraiment des performances du serveur mais de l'utilisation des profils itinérents de XP.
Pour info XP charge une première fois le profil, sans doute dans un répertoire temporaire (?) puis le copie. Résultat si l'on met des quotas sur le client, il faut autoriser une taille double !!!! De plus, l'alarme soft des quota existe mais n'affiche rien de source Microsoft !!! et confirmé !
Ensuite, l'utilisation de netbios n'est pas très robuste, au moindre problème le client Microsoft refuse d'effacer la copie locale.
Le résultat de ces 2 technologies Microsoft produit régulièrement des bases de registres abimées. Au moins 2 par semaine sur mes 3000 clients.
[^] # Re: info sur la Puissance du serveur nécessaire
Posté par Prosper . Évalué à 1.
Cependant tu peux essayer la commande "/bin/rm -rf ~/*" en user space sur ton noyau patché ... tu apprécieras le résultat. Pour mémoire avant d'accéder au noyau il y a quelques étapes supplémentaires. On parlera une autre fois de sécurité.
ca va les chevilles ? ca gonfle pas trop , t as pas un peu l impression de peter plus haut que ton c*l ?
[^] # Re: info sur la Puissance du serveur nécessaire
Posté par corn . Évalué à 1.
je prefere encore avoir un uptime de merde et pas avoir un kernel troué ...
Sauf que chez Debian, quand il y a un trou dans le noyau, ils appliquent le patch sur la version du noyau de la distrib stable (2.4.18 pour Woody) plutôt que de changer la version du noyau.
Cela signifie donc que son noyau n'est a priori pas troué s'il a mis à jour sa Debian.
[^] # Re: info sur la Puissance du serveur nécessaire
Posté par Prosper . Évalué à 1.
* http://www.debian.org/security/2003/dsa-403(...)
* http://www.debian.org/security/2003/dsa-311(...)
....
[^] # Re: info sur la Puissance du serveur nécessaire
Posté par corn . Évalué à 1.
Ooops j'avais pas pensé à ça :-p
Son noyau est donc troué :-)
[^] # Re: info sur la Puissance du serveur nécessaire
Posté par hommelix . Évalué à 1.
Moi aussi j'ai ca a deux heures du mat le we.
Mais quand une mailing list de 3000 utilisateurs passe le load monte un peu plus. C'est pas trop representatif ;)
[^] # uptime
Posté par Quzqo . Évalué à 1.
Amusant ce 497+60... je croyais que le noyau revenait à 0 à 496 j. d'uptime, mais peut-être est-ce 498... ou plus... ou moins
Quoiqu'il en soit, je crois que c'est avant 500 j.
[^] # Re: uptime
Posté par Prosper . Évalué à 1.
# Considérations diverses.
Posté par Rafael (site web personnel) . Évalué à 1.
Si les services sont crutiaux, c'est de la folie.
Si la machine tombe pour quelque raison que ce soit, tout tombe, plus de business possible, et c'est le siège éjectable (comprendre la porte pour faute grave).
Je ne m'étendrait pas sur le si ça tient la charge.
Sendmail = vieille idée. Il existe des trucs au moins aussi bien, mais pas troués, et plus légers. (exim, postfix)
Pour un serveur de prod, Debian stable s'impose. Pas pour troller, mais par sélection naturelle. (l'expérience est une longue suite d'erreurs faites un jour ou l'autre) (Copyright GNU FDL moi 1989)
Isoler le fw d'un coté.
Isoler le hd intensif d'un autre coté (stockage proxy, stockage samba, stockage mail)
Isoler le CPU intensif de l'autre (spamassasin clamav)
Avec des disques dernier cris il est difficile de saturer du 100MBit/s, et il faut carrément mettre le prix.
Plus on noyaute les services, plus il possible d'offrir des redondances en cas de panne, ou tout au moins un matos opérationel à plus de zéro %.
Quand on a 350 profils itinérants, on se prend du matos qui marche en quantité suffisante, sinon les 350 gusses sont au chomage technique.
Mettre dans le même panier les profils itinérants (crutiaux) et le proxy de pages de cul (non crutiaux) me semble une erreur.
Enfin, même la config netfilter la plus pointue du monde ne met pas à l'abris d'un trou de sécu. L'upgradabilité d'une machine de prod est fondamentale pour cela. (bis repetita Debian stable)
Si les décideurs pressés de 350 itinérants et 900 users connectés ne lâchent suffisament de blé, il faut leur expliquer que si ça plante, ils trainqueront. Il faut noyauter tout ça. C'est pas une passerelle pour la maison, c'est pour bosser là.
Pour finir, SMP rulez. PIV bof. BiPro AMD rox.
[^] # Re: Considérations diverses.
Posté par Mickael_83 . Évalué à 1.
Comme je l'ai dit et je le répète, c'est une question de budget. Si le client avait un budget de 5000 Euros, no souci, or là en l'occurence c'est pas le cas du tout.
La séparation des serveurs se fera sans doute au coup par coup mais pour l'instant, je n'ai pas d'autres choix.
" Si les décideurs pressés de 350 itinérants et 900 users connectés ne lâchent suffisament de blé, il faut leur expliquer que si ça plante, ils trainqueront. Il faut noyauter tout ça. C'est pas une passerelle pour la maison, c'est pour bosser là."
T'inquiète, c'est expliqué, écrit noir sur blanc en caractères de 16 gras et italique. C'est pas pour me couvrir mais bel et bien pour leur expliquer que si effectivement ça plante, ben ils étaient quand même averti avant. Surtout quand on sait qu'ils vont forcément prcéder à l'achat de 350 M$, ça fout les boules. C'est pour ça que je l'ai marqué en gros caractère ! ;-)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.