comme tu le dis pascal, ca en reviens a faire un bon design d'application, se qui est nettement plus difficile a faire pour une societe que de decider qu'il faut $beaucoup$ pour une solution que l'on achete a l'exterieur (comme ca on peut relancer la faute sur kk d'autre quand l'application mal foutue plantera).
C'est exactement comme la securite, ou tu fais kkchose d'intelligent dans tes applications / OS ou tu achete ta securite avec des Firewall, des IDS., des IPS des anti virus spam worms truc machins et bidules, qui finalement ne resolvent pas grand chose, mais permettent de pouvoir relancer la faute sur le vendeur de matos. C'est beau l'informatique je trouve, enfin ce n'est pas unique a ce domaine. On Thu, Nov 18, 2004 at 07:50:16AM +0100, Pascal Bleser wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Thomas Silvestre wrote: > | Au boulot nous avons aussi ce genre de gr????sse machine, mais ?? part des > | disques et des ventilateurs et malgr?? un d??m??nagement de quelques km et > | une perte soudaine du courant dans toute la salle des serveur, nous > | n'avons jamais rencontr?? de probl??me hardware bloquant (a??e, je ne > | devrais pas dire ??a). Pour info nous utilisons du materiel ibm pSeries. > | Nous allons recevoir 2 nouveaux serveurs (p570) tr??s bient??t. > | Question maintenance et support, c'est vrai ??a co??te un pont. > | > | Petite question: avez-vous d??j?? eu de mauvaises exp??rience et avec quel > | mat??riel ou quel fabriquant? Des anecdotes c'est toujours sympa. > > Nous (ou nos clients) n'avons pas vraiment eu de mauvaises exp??riences > c??t?? stabilit?? ou m??me > performance, pour autant que je sache en tout cas. > > Moi c'est plut??t l'aspect du co??t que je voulais mettre en avant. > > Et en fait c'est assez simple ?? argumenter (en d??faveur des "grosses" > machines): > dans 99% des cas, tout le monde a un besoin en performances qui est assez > stable sur toute l'ann??e. > Il y a des peaks en journ??e, ou bien la nuit, mais grossomodo, c'est > mesur??, bien connu et puis on > sait acheter une machine (ou plusieurs) en fonction de cela. > Je vais prendre l'exemple d'un de nos clients, VISA. > Pour VISA comme dans la tr??s grande majorit?? des cas, il y a plusieurs > p??riodes de peaks tr??s forts > sur l'ann??e, comme p.ex. no??l, p??ques, la p??riode de vacances. > Pendant ces p??riodes-l??, tu as un besoin en performance qui est souvent 2 > ?? 3 fois sup??rieur ?? ton > maximum sur l'ann??e. > > Tout ceci pour expliquer que si tu prends pour strat??gie d'utiliser une > (ou deux) tr??s grosse(s) > machine(s) (disons une Sun Enterprise 15000), tu es forc??ment oblig?? > d'acheter une machine grosse > assez pour supporter la charge _maximale_ en production sur toute l'ann??e. > Or, elle va s'emm****r le reste du temps. > > Si, par contre, tu choisis une strat??gie avec beaucoup (ou du moins > plusieurs) machines plus > "petites" (comme d??j?? dit, pas n??cessairement des P3 avec 256MB RAM non > plus hein ;)) que tu > utilises en cluster, tu gagnes: > 1) en redondance: lorsque des composantes mat??rielles rendent l'??me, une > autre machine reprend la > charge (oui, je sais, ces "grosses" machines ont quand m??me pas mal de > composants en redondance > (alimentation, ...) mais bon, quand m??me - essaye de couper une E15K en > deux pour la mettre sur 2 > sites ;)) > 2) en co??ts: lorsque tu as ces p??riodes "chaudes" sur l'ann??e, tu > ajoutes des machines pour g??rer la > charge - mais ces machines peuvent ??tre utilis??es pour d'autres > applications le reste de l'ann??e > 3) en maintenance: oui et non: > ~ - tu y perds ?? moins d'avoir des bons syst??mes de gestion de cluster > (g??rer 30 machines est ?? > priori plus complexe qu'en g??rer une seule, m??me partitionn??e) > ~ - tu y gagnes parce que quand tu veux augmenter la performance, tu > ajoutes qqes machines (p.ex. > Intel ou AMD + Linux) - avec ton E15K, une fois la capacit?? maximale > atteinte, il faudra en acheter > une 2??me (et bonjour les frais) > > N??anmoins, j'ajouterais un b??mol ?? ce que Jef ?? dit: c'est beaucoup > plus complexe d'impl??menter une > application qui fonctionne bien en termes de "scalability" (+/- > "parall??lisation") et de "failover" > qu'une application qui fonctionne simplement avec beaucoup de CPUs. Donc > ??a d??pend parfois aussi du > cas de figure, du type et de la qualit?? de l'impl??mentation (software). > Un cluster de serveurs web (p.ex. Apache ou Tomcat), ??a se g??re tr??s > facilement en cluster de > beaucoup de petites machines. Par contre, quand il y a beaucoup d'acc??s DB > et beaucoup de donn??es ?? > ~ g??rer, c'est d??j?? nettement plus compliqu?? (synchronisation des > sessions, des caches, ??viter la > s??rialisation des acc??s DB, XA est une horreur, ...). > Enfin, ??a fait vivre les architectes syst??me comme moi ;D > > Il faut aussi voir que tu dois investir dans un bon backbone en fibre > optique (ou myrinet) pour > relier les noeuds (machines) du cluster. En outre, le consommation en > ??lectricit?? est beaucoup plus > importante pour 50 machines que pour 1 grosse - ??a n'est g??n??ralement > pas pris en compte, mais si tu > prends le cas de Google (10000 machines AMD/Intel+Linux) ou d??s que tu > comptes plusieurs centaines > de "petites" machines ... > > Il y a du pour et du contre, mais personellement, je suis ?? priori > beaucoup plus pour une > infrastructure de cluster de petites machines. Un avantage ??norme, c'est > aussi que tu as des > composants "standards", c??d du hardware sur base Intel, AMD (ou m??me > PowerPC) que tu peux acheter > chez plusieurs revendeurs (Intel, HP, Dell, Sun, et beaucoup d'autres). > Avec les tr??s grosses machines, tu n'as pas tellement le choix (IBM z- et > s-Series, IBM p-Series, > Sun Enterprise). > > enfin voil??, my 0.02EUR ;) > > - -- > ~ -o) Pascal Bleser http://guru.unixtech.be > ~ /\\ <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> > ~ _\_v The more things change, the more they stay insane. > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.2 (GNU/Linux) > > iD8DBQFBnEYor3NMWliFcXcRAvm1AJ9WzFdVugw1TxrfQbPeFhal+G3ELwCgvxg8 > giq9A9zRvw5fjbAxf/0DKns= > =amur > -----END PGP SIGNATURE----- > _______________________________________________________ > Linux Mailing List - http://www.unixtech.be > Subscribe/Unsubscribe: http://www.unixtech.be/mailman/listinfo/linux > Archives: http://www.mail-archive.com/linux@lists.unixtech.be > IRC: chat.unixtech.be:6667 - #unixtech -- -- -> Jean-Francois Dive --> [EMAIL PROTECTED] I think that God in creating Man somewhat overestimated his ability. -- Oscar Wilde _______________________________________________________ Linux Mailing List - http://www.unixtech.be Subscribe/Unsubscribe: http://www.unixtech.be/mailman/listinfo/linux Archives: http://www.mail-archive.com/linux@lists.unixtech.be IRC: chat.unixtech.be:6667 - #unixtech
