Bonjour,
je vous passe les détails, mais les devs ont fait un site avec un modèle MVC et un framework que je ne citerais pas... Mais c'est pas assez rapide, donc comme vous le savez ça retombe sur les sysadmins. Ne vous inquiétez pas je ne me suis pas laisser faire ;) et ce depuis le départ, quand un simple "hello world" sortait en 400ms contre 10ms brut avec un include_de_2k_lignes_mais_sans_objets...
Une des solutions pour accélérer le bouzin, c'est de changer le hardware. Pas la peine de parler des autres solutions, je les connais déjà, je souhaite juste étudier et chiffrer celle-ci.
Aujourd'hui on a des serveurs 8 coeurs cadencés a 2,33GHz (L5410), et je voudrais savoir ce que donnerais un Nehalem cadencé à 2.26GHz par rapport aux Xeon, pour exécuter des pages PHP5. Aujourd'hui elles sortent en ~500ms avec les Xeon, avec APC, du cache, et tout le toutim.
Est-ce que vous avez déjà expérimenter ces processeurs pour ce type d'application ? Ya de grande chance pour que j'en achète un pour voir, mais je souhaite d'abord écouter vos avis.
Salut Greg,
Le 19 juil. 2010 à 18:06, Greg a écrit :
Bonjour,
je vous passe les détails, mais les devs ont fait un site avec un modèle MVC et un framework que je ne citerais pas... Mais c'est pas assez rapide, donc comme vous le savez ça retombe sur les sysadmins. Ne vous inquiétez pas je ne me suis pas laisser faire ;) et ce depuis le départ, quand un simple "hello world" sortait en 400ms contre 10ms brut avec un include_de_2k_lignes_mais_sans_objets...
Une des solutions pour accélérer le bouzin, c'est de changer le hardware. Pas la peine de parler des autres solutions, je les connais déjà, je souhaite juste étudier et chiffrer celle-ci.
Aujourd'hui on a des serveurs 8 coeurs cadencés a 2,33GHz (L5410), et je voudrais savoir ce que donnerais un Nehalem cadencé à 2.26GHz par rapport aux Xeon, pour exécuter des pages PHP5. Aujourd'hui elles sortent en ~500ms avec les Xeon, avec APC, du cache, et tout le toutim.
Est-ce que vous avez déjà expérimenter ces processeurs pour ce type d'application ? Ya de grande chance pour que j'en achète un pour voir, mais je souhaite d'abord écouter vos avis.
Ca ira plus vite c'est sûr... Mais bon... Reste que quand même y a des merdes dans le code :p
Greg, tu devrais donner des 486 a tes dev... histoire qu'ils apprennent a coder...
<OT> J'ai 2 nehalems E5530 en rab... </OT>
Disons que pour de l'usage filer (opensolaris zfs + infiniband) sur de la carte mère supermicro ça dépote pas mal....
A noter que avec du nehalem, il faut mieux prendre de la grosse barrette mémoire que plein de petites barrettes mémoire sinon ton joli bus DDR3 dégringole a 800MHz au lieu de 1333MHz :) qui pour des appli avec des jolies frameworks qui mange partout... a l'air important....
Je saute d'ailleurs sur l'occasion vis a vis des nehalem, hyper threads ou pas (moi de mon coté j'ai plutôt penché vers le "pas" :).
Xavier
Le 19/07/10 18:22, Xavier Beaudouin a écrit :
Salut Greg,
Le 19 juil. 2010 à 18:06, Greg a écrit :
Bonjour,
je vous passe les détails, mais les devs ont fait un site avec un modèle MVC et un framework que je ne citerais pas... Mais c'est pas assez rapide, donc comme vous le savez ça retombe sur les sysadmins. Ne vous inquiétez pas je ne me suis pas laisser faire ;) et ce depuis le départ, quand un simple "hello world" sortait en 400ms contre 10ms brut avec un include_de_2k_lignes_mais_sans_objets...
Une des solutions pour accélérer le bouzin, c'est de changer le hardware. Pas la peine de parler des autres solutions, je les connais déjà, je souhaite juste étudier et chiffrer celle-ci.
Commence par dégager apache et mettre nginx en frontal (en fcgi), déplacer les static sur un serveur à part, et pour les bouts de cgi pour la monetique, reverse proxy_pass de nginx vers un thttpd ou autre httpd basique. Tu gagnes déjà le moteur asynchrone et une meilleur utilisation des cores dispos (moins de deadlock sur l'allocateur de PHP, qui est LE problème avec symfony)
Aujourd'hui on a des serveurs 8 coeurs cadencés a 2,33GHz (L5410), et je voudrais savoir ce que donnerais un Nehalem cadencé à 2.26GHz par rapport aux Xeon, pour exécuter des pages PHP5. Aujourd'hui elles sortent en ~500ms avec les Xeon, avec APC, du cache, et tout le toutim.
Est-ce que vous avez déjà expérimenter ces processeurs pour ce type d'application ? Ya de grande chance pour que j'en achète un pour voir, mais je souhaite d'abord écouter vos avis.
Nehalem 4/6 cores / 3 canaux ou Opteron 8/12 cores / 4 canaux, à la limite je pencherai plutôt pour des Opteron dans ce cas précis, car ce n'est pas la fréquence des CPU qui bloque, c'est la vitesse d'instanciation des objets. Et avec nginx, tu gagnes sur l'utilisation de plus de cores plus lents.
En plus, c'est moins cher. Mais ça on peut en causer en PV.
Ca ira plus vite c'est sûr... Mais bon... Reste que quand même y a des merdes dans le code :p
Greg, tu devrais donner des 486 a tes dev... histoire qu'ils apprennent a coder...
Y peuvent pas, ils "bossent" sous eclipse. Mais bon, c'est un grand classique, "sur ma station ça marche" dit le couillon qui tourne tout seul sur un quadcore.
<OT> J'ai 2 nehalems E5530 en rab... </OT>
Disons que pour de l'usage filer (opensolaris zfs + infiniband) sur de la carte mère supermicro ça dépote pas mal....
Je suis pas sur que ce soit deux applications assez proches ;) Mais oui, les archis nehalem sont très bonnes en web.
A noter que avec du nehalem, il faut mieux prendre de la grosse barrette mémoire que plein de petites barrettes mémoire sinon ton joli bus DDR3 dégringole a 800MHz au lieu de 1333MHz :) qui pour des appli avec des jolies frameworks qui mange partout... a l'air important....
Je saute d'ailleurs sur l'occasion vis a vis des nehalem, hyper threads ou pas (moi de mon coté j'ai plutôt penché vers le "pas" :).
Moi j'en met pas. Encore une fois parce que le problème, en PHP/symfony, c'est _toujours_ la vitesse d'instanciation de la myriade d'objets intermédiaires nécessaires à l'ORM. Et ça, l'hyperthreading n'y changera pas, à part augmenter la contention sur les routines d'allocation.
Xavier _______________________________________________ FRsaG mailing list FRsaG@frsag.org http://www.frsag.org/mailman/listinfo/frsag
Commence par dégager apache et mettre nginx en frontal (en fcgi),
J'ai déjà une archi qui sert le statique, avec squid en reverse, mais un passage sur nginx ou varnish est dans les cartons. On utilise des features sur squid qui n'existe peut-être pas sur ces 2 là, ça fait partit de l'étude.
des cores dispos (moins de deadlock sur l'allocateur de PHP, qui est LE
problème avec symfony)
Intéressant, cette identification de bottleneck.
Le 19/07/10 20:54, Greg a écrit :
des cores dispos (moins de deadlock sur l'allocateur de PHP, qui est LE problème avec symfony)Intéressant, cette identification de bottleneck.
Merci xdebug.
En fait, quand on trace un site basé sur un framework un peu lourd, on constate souvent que le plus gros de la charge vient de l'initialisation de toute l'environnement du framework.
Sur des bases monolithiques comme symfony, c'est plusieurs milliers d'objets à créer pour servir une page simple.
L'allocateur de PHP n'est pas un modèle de perf ( environ O(n.log(n)) ), mais surtout il réaloue dynamiquement (merci le loose typing).
Quand on part sur un code assez sommaire en symfony, la vitese de chargement du framework est assez stable. Dès lors qu'une requette en base survient, c'est à tout l'ORM de se mettre en route. Pour peu que le debug soit actif, c'est plusieurs centaines d'objets à créer, avec un wait() à chaque allocation, le temps qu'elle soit acquitée.
Résultat, sur du code de prod (typiquement e-commerce avec scénario de parcours rapide), c'est 90% du temps passé sur PHP à gérer la mémoire.
Symfony n'est pas le seul dans ce cas, tous les frameworks monolithiques en souffrent, peu importe le langage. Mais c'est un peu moins prononcé sur des outils plus modernes (RoR ou Django).
Le 19/07/2010 18:06, Greg a écrit :
Bonjour,
je vous passe les détails, mais les devs ont fait un site avec un modèle MVC et un framework que je ne citerais pas... Mais c'est pas assez rapide, donc comme vous le savez ça retombe sur les sysadmins. Ne vous inquiétez pas je ne me suis pas laisser faire ;) et ce depuis le départ, quand un simple "hello world" sortait en 400ms contre 10ms brut avec un include_de_2k_lignes_mais_sans_objets...
Une des solutions pour accélérer le bouzin, c'est de changer le hardware. Pas la peine de parler des autres solutions, je les connais déjà, je souhaite juste étudier et chiffrer celle-ci.
Aujourd'hui on a des serveurs 8 coeurs cadencés a 2,33GHz (L5410), et je voudrais savoir ce que donnerais un Nehalem cadencé à 2.26GHz par rapport aux Xeon, pour exécuter des pages PHP5. Aujourd'hui elles sortent en ~500ms avec les Xeon, avec APC, du cache, et tout le toutim.
Est-ce que vous avez déjà expérimenter ces processeurs pour ce type d'application ? Ya de grande chance pour que j'en achète un pour voir, mais je souhaite d'abord écouter vos avis.
Salut,
Le L5410 n'a pas les mêmes fonctionnalités que les E ou les X 54. Déjà, il est un poil moins balaise.
Pour bosser pas mal avec des X55 (pareil, le E est un peu moins puissant, le L encore moins) pour des serveurs Web, ça dépote grave. On a un gain assez important en terme de page/seconde par rapport aux anciennes machines (désole je n'ai pas de chiffre exactement mais j'ai eu l'occasion de faire pas mal de bench).
Tu auras donc de meilleure performance, l'archi Nehalem (core i7) m'a beaucoup impressionné avec un gain de performance important par rapport au 54 (et aux anciens CPU 53, 33, etc ...).
Il y a encore mieux, les X56. J'ai pu avoir des X5650, HT activé => 24 coeurs. C'est parfait pour les serveurs webs, ca permet d'avoir un nombre impressionnant de page/secondes.
Mais la puissance CPU et le nombre de coeur ne fera que limiter les dégats, si le code est pourri, il restera pourri sur un autre CPU et la scalabilité va couter très cher (un X55 c'est pas donné, idem pour les X56) ...
Je vois que tu as bien fait les choses avec APC. 500ms par page, c'est déjà pas mal ... avec un framework par dessus en plus. Tout dépend avec combien de stress tu fais sortir une page en 500ms. Si c'est avec 200 connexions/secondes ou bien seulement 10 ... Voir comment l'application se comporte en encaissant la charge.
Sinon, fastcgi vs modphp => modphp est gagant sur tout les tests que j'ai fait. Donc pour voir, ça sert pas à grand chose niveau "perf".
Reverse proxy, mais ça demande aussi du taf coté dev. Taf, dev. Ok, on a compris. Mais sur une super optimisation, avec ça, roule ma poule, si c'est bien fait.
a+
ps: Symfony ou Zend ? :p ps2: enfin une ML pour les sysadmin, depuis le temps que j'en rêvais ^^
-- Guillaume
Il y a encore mieux, les X56. J'ai pu avoir des X5650, HT activé => 24 coeurs. C'est parfait pour les serveurs webs, ca permet d'avoir un nombre impressionnant de page/secondes.
Tu m'intéresse ! Je vais me renseigner auprès de Dell. Et tant qu'à faire avec du SSD.
Je vois que tu as bien fait les choses avec APC. 500ms par page, c'est déjà pas mal ... avec un framework par dessus en plus. Tout dépend avec combien de stress tu fais sortir une page en 500ms. Si c'est avec 200 connexions/secondes ou bien seulement 10 ... Voir comment l'application se comporte en encaissant la charge.
100 requêtes/s (données apache), avec un load de 4.
ps: Symfony ou Zend ? :p
lequel est le pire ? ;) Je ne suis pas sûr qu'il y ait une grosse différence entre les 2, au niveau performance.
Merci pour votre retour !
ps: Symfony ou Zend ? :p
lequel est le pire ? ;) Je ne suis pas sûr qu'il y ait une grosse différence entre les 2, au niveau performance.
Même si ce n'est pas une liste de dev, je peux donner mon retour sur ce point : très clairement, le pire est symfony, à tous les égards : lenteur, lourdeur et sécurité.
Il est plus lent que Zend sur des applications identiques (lenteur ; je n'ai pas vérifié, puisque ca voudrait dire recoder l'appli juste pour tester, mais j'ai lu plusieurs articles le disant) et surtout, de par son design monolithique, un simple hello world signifie charger la terre entière (ou presque) en mémoire avant de pouvoir atteindre le code actif (lourdeur).
Niveau sécurité, l'utilisation de très nombreuses fonctions qu'un admin a envie de désactiver sont utilisées, à commencer par ini_set, set_time_limit et autre memory_limit à 32M. Je parle pas du +ExecCGI par défaut dans le .htaccess à la racine du docroot, alors qu'il n'y a jamais eu un seul CGI dans le docroot de symfony...
Dans la même lignée, j'ai pu voir une discussion sur la mailing list de dev de symfony à propos d'un rapport de "faille"qui a purement et simplement été ignoré par le développeur principal de Symfony d'une majestueuse variation du "It's not a bug, it's a feature" : Le répertoire d'upload des fichiers est par défaut dans le docroot... donc si un dev négligeant ne fait pas assez de check, on peut directement appeler notre script de hack par une simple requête HTTP... J'attends, personnellement qu'un framework ait des valeurs par défaut sécurisées, et des warnings dans sa documentation en cas de changement de ces valeurs.
Sachant que c'est un rapport de faille qui aurait du être fait en privé, et au vu de la manière dont il a été "traité", j'ai peur pour les autres rapports qui sont restés confidentiels.
Alors même s'il y a des défauts aussi dans Zend, mon choix est fait : Zend, définitivement Zend.
Florian MAURY
Il est plus lent que Zend sur des applications identiques (lenteur ; je n'ai pas vérifié, puisque ca voudrait dire recoder l'appli juste pour tester, mais j'ai lu plusieurs articles le disant) et surtout, de par son design monolithique, un simple hello world signifie charger la terre entière (ou presque) en mémoire avant de pouvoir atteindre le code actif (lourdeur).
pas mieux pour Zend. Oui, c'est Zend qu'on a choisit.
Niveau sécurité, l'utilisation de très nombreuses fonctions qu'un admin a envie de désactiver sont utilisées, à commencer par ini_set, set_time_limit et autre memory_limit à 32M. Je parle pas du +ExecCGI par défaut dans le .htaccess à la racine du docroot, alors qu'il n'y a jamais eu un seul CGI dans le docroot de symfony...
On peut désactiver les .htaccess sur Apache, c'est d'ailleurs un gain en IO ;)
Alors même s'il y a des défauts aussi dans Zend, mon choix est fait : Zend, définitivement Zend.
Mon choix serait plutôt de faire notre propre framework MVC, mais c'est trop tard :-/
Le point positif c'est que si je remplace mes 96 coeurs en 12 serveurs de 8, par 4 serveurs en Nehalem 32 coeurs, je vais bien gagner en capa électrique :)
On peut désactiver les .htaccess sur Apache, c'est d'ailleurs un gain en IO ;)
Le gain est pas tuant non plus. La dernière fois que j'ai groupé les instructions du .htaccess dans le fichier de conf d'apache et desactivé les .htaccess, j'ai gagné 3%. Pas transcendant comparé aux perles de certains devs, et souvent impossible sans avoir les devs qui débarquent toutes les 5 minutes parce qu'ils ont réécrit une rewriterule :/
Alors même s'il y a des défauts aussi dans Zend, mon choix est fait : Zend, définitivement Zend.
Mon choix serait plutôt de faire notre propre framework MVC, mais c'est trop tard :-/
Je me suis toujours demandé pourquoi personne n'avait codé un framework php en module PHP. Le fait que ce soit en C devrait booster sacrément le bouzin...
Florian MAURY
surement que pour la portabilité c'est pas évident. ça oblige à avoir un dédier pour s'en servir.
Le 19/07/2010 21:42, Florian MAURY a écrit :
On peut désactiver les .htaccess sur Apache, c'est d'ailleurs un gain en IO ;)
Le gain est pas tuant non plus. La dernière fois que j'ai groupé les instructions du .htaccess dans le fichier de conf d'apache et desactivé les .htaccess, j'ai gagné 3%. Pas transcendant comparé aux perles de certains devs, et souvent impossible sans avoir les devs qui débarquent toutes les 5 minutes parce qu'ils ont réécrit une rewriterule :/
Alors même s'il y a des défauts aussi dans Zend, mon choix est fait : Zend, définitivement Zend.
Mon choix serait plutôt de faire notre propre framework MVC, mais c'est trop tard :-/
Je me suis toujours demandé pourquoi personne n'avait codé un framework php en module PHP. Le fait que ce soit en C devrait booster sacrément le bouzin...
Florian MAURY _______________________________________________ FRsaG mailing list FRsaG@frsag.org http://www.frsag.org/mailman/listinfo/frsag
Un truc qu'il faut apprendre aux développeurs : une base de données n'est pas un endroit pour stocker des sessions PHP car soit disant les développeurs ne savent pas que l'on sait unifier des sessions depuis plusieurs serveurs.
Un autre truc, qui peut aider mais je ne dis pas que ça changera tout ... les sessions dans Memcache pour diminuer les accès disques et un tmpdir de MySQL sur un tmpfs ça peut aussi aider au niveau rapidité ;)
Entre Symfony et Zend ... peu de différences, à vrai dire j'ai pas fait de benchmarks, encore une fois tout dépend du développeur ... require_once vs require,cache / pas cache, etc ... soit il sait ce qu'il fait soit il met n'importe quoi dans son code et on a beau faire du mieux que l'on peut ... une ligne de code suffit pour tout ralentir
Un truc aussi qui peut aider mais pas testé en production : l'executeur PHP de Facebook ( HipHop ) -> http://pro.01net.com/editorial/512183/facebook-accelere-son-php-avec-hiphop/
On Mon, 19 Jul 2010 21:00:53 +0200, Greg greg-frsag@duchatelet.net wrote:
Il y a encore mieux, les X56. J'ai pu avoir des X5650, HT activé => 24 coeurs. C'est parfait pour les serveurs webs, ca permet d'avoir un
nombre
impressionnant de page/secondes.
Tu m'intéresse ! Je vais me renseigner auprès de Dell. Et tant qu'à
faire
avec du SSD.
Je vois que tu as bien fait les choses avec APC. 500ms par page, c'est déjà pas mal ... avec un framework par dessus en plus. Tout dépend avec combien de stress tu fais sortir une page en 500ms. Si c'est avec 200 connexions/secondes ou bien seulement 10 ... Voir comment l'application se comporte en encaissant la charge.
100 requêtes/s (données apache), avec un load de 4.
ps: Symfony ou Zend ? :p
lequel est le pire ? ;) Je ne suis pas sûr qu'il y ait une grosse différence entre les 2, au niveau performance.
Merci pour votre retour !
Le Mon, Jul 19, 2010 at 09:21:30PM +0200, Lilian RIGARD - Devclic a écrit:
Un truc qu'il faut apprendre aux développeurs : une base de données n'est pas un endroit pour stocker des sessions PHP car soit disant les développeurs ne savent pas que l'on sait unifier des sessions depuis plusieurs serveurs.
Et on fait ça comment alors ?
Perso je vois plusieurs solutions, mais bon...
- nfs (ça scale pas)
- drbd/ocfs2 (scale un peu mieux avec drbd en pri/pri, mais perfs dégradées avec du iscsi (pas de cache), et ocfs2 a une petite tendance suicidaire au moindre problème réseau)
- drbd/glustre ou autre, pas testé.
- ... ?
(et sinon après bah c'est du bon gros nas/san proprio...)
Arnaud.
Le 19 juillet 2010 21:36, Arnaud Launay asl@launay.org a écrit :
Le Mon, Jul 19, 2010 at 09:21:30PM +0200, Lilian RIGARD - Devclic a écrit:
Un truc qu'il faut apprendre aux développeurs : une base de données n'est pas un endroit pour stocker des sessions PHP car soit disant les développeurs ne savent pas que l'on sait unifier des sessions depuis plusieurs serveurs.
Et on fait ça comment alors ?
Avec un système clef/valeur, il y en a plusieurs et j'en ai testé quelques uns :
http://www.duchatelet.net/blog/?post/2008/06/19/Session-PHP%3A-Le-choix
Sharedance est une tuerie, et est en prod depuis des mois sur un serveur de plus de 3 ans, et ça tient super bien (sur un tmpfs) ;)
Sharedance est une tuerie, et est en prod depuis des mois sur un serveur de plus de 3 ans, et ça tient super bien (sur un tmpfs) ;)
+1. J'ai adopté la même solution, il y a des années ; j'allais répondre la même chose.
En revanche, en 2008, j'avais des problèmes de stabilité avec Sharedanced qui plantait tout seul ; j'avais mis un daemontools pour le respawner au cas où. Depuis j'ai quitté l'entreprise et je ne sais pas si cette solution a été conservée.
Si tes sessions sont de tailles relativement hétérogènes, memcached peut également faire l'affaire ; c'est bien scalable.
Florian MAURY
Le Mon, Jul 19, 2010 at 09:46:54PM +0200, Florian MAURY a écrit:
Sharedance est une tuerie, et est en prod depuis des mois sur un serveur de plus de 3 ans, et ça tient super bien (sur un tmpfs) ;)
+1. J'ai adopté la même solution, il y a des années ; j'allais répondre la même chose.
Hmmmm. Ayant (comme tous ou presque ici...) des problématiques de prod, la question classique: ça marche sans rien modifier ?
Un peu comme le cache php "apc": ce truc est une tuerie, et le gros bénef, c'est qu'il suffit de l'installer sans rien toucher ailleurs, il marche tout seul, de la même façon (pour les sessions php) qu'un ocfs/nfs/etc.
Biscotte toucher au code, c'est juste pas possible...
Arnaud.
Le Mon, Jul 19, 2010 at 10:00:06PM +0200, Arnaud Launay [asl@launay.org] a écrit:
Le Mon, Jul 19, 2010 at 09:46:54PM +0200, Florian MAURY a écrit:
Sharedance est une tuerie, et est en prod depuis des mois sur un serveur de plus de 3 ans, et ça tient super bien (sur un tmpfs) ;)
+1. J'ai adopté la même solution, il y a des années ; j'allais répondre la même chose.
Hmmmm. Ayant (comme tous ou presque ici...) des problématiques de prod, la question classique: ça marche sans rien modifier ?
Un peu comme le cache php "apc": ce truc est une tuerie, et le gros bénef, c'est qu'il suffit de l'installer sans rien toucher ailleurs, il marche tout seul, de la même façon (pour les sessions php) qu'un ocfs/nfs/etc.
Biscotte toucher au code, c'est juste pas possible...
Quelques applis essayent d'être plus malignes que l'admin sys et font du caca quand on change le session.save_handler pour autre chose que ce qu'elles attendent.
Mais dans la plupart des cas, ça fonctionne sans soucis.
C'est pour du site "dédié" ou du mutualisé, que tu poses la question ?
Le Tue, Jul 20, 2010 at 10:44:24AM +0200, Dominique Rousseau a écrit:
Biscotte toucher au code, c'est juste pas possible...
Quelques applis essayent d'être plus malignes que l'admin sys et font du caca quand on change le session.save_handler pour autre chose que ce qu'elles attendent.
Hmmm. De toute façon, dès qu'on touche à php...
Mais dans la plupart des cas, ça fonctionne sans soucis. C'est pour du site "dédié" ou du mutualisé, que tu poses la question ?
Les deux, capitaine. D'abord le tester sur un petit mutu en serveur simple, et ensuite passer sur un dédié contenant ~200 sites répartis sur 3 serveurs, si ça marche en mode "on touche pas le code".
Arnaud.
Le Tue, Jul 20, 2010 at 10:51:16AM +0200, Arnaud Launay [asl@launay.org] a écrit:
Le Tue, Jul 20, 2010 at 10:44:24AM +0200, Dominique Rousseau a écrit:
Biscotte toucher au code, c'est juste pas possible...
Quelques applis essayent d'être plus malignes que l'admin sys et font du caca quand on change le session.save_handler pour autre chose que ce qu'elles attendent.
Hmmm. De toute façon, dès qu'on touche à php...
:-)
Mais dans la plupart des cas, ça fonctionne sans soucis. C'est pour du site "dédié" ou du mutualisé, que tu poses la question ?
Les deux, capitaine. D'abord le tester sur un petit mutu en serveur simple, et ensuite passer sur un dédié contenant ~200 sites répartis sur 3 serveurs, si ça marche en mode "on touche pas le code".
Dans ce cas, oui, faut tester. Si tu peux modifier la configuration PHP site par site, tu peux faire du cherry picking pour tester le bon fonctionnement.
Heu NFS : c'est pas mort ?
- drbd/ocfs2 : on a ça pour le FS principal mais pas pour les sessions / OCFS2 est un peu suicidaire mais en fait il est très chiant à configurer ... et rien n'est clairement expliqué : à noter que c'est utilisé dans les cluster RAC
- drbd / gluster : on a eu de gros problèmes de lock avec gluster ... à oublier ... ça reste bien pour du backup globalisé
- Memcache : notre solution retenue, 1 Actif / Passif avec une réplication Master / Slave ( Repcached )
- Sharedance est pas mal non plus mais on a pas testé, Skyblog l'utilise
On attend Redis ... qui est le remplaçant de Memcache car il faut bien dire que Memcache en version cluster c'est une hérésie ... la réplication ne fonctionne pas en mode actif / actif ...
On Mon, 19 Jul 2010 21:36:28 +0200, Arnaud Launay asl@launay.org wrote:
Le Mon, Jul 19, 2010 at 09:21:30PM +0200, Lilian RIGARD - Devclic a
écrit:
Un truc qu'il faut apprendre aux développeurs : une base de données n'est pas un endroit pour stocker des sessions PHP car soit disant les développeurs ne savent pas que l'on sait unifier des sessions depuis plusieurs serveurs.
Et on fait ça comment alors ?
Perso je vois plusieurs solutions, mais bon...
nfs (ça scale pas)
drbd/ocfs2 (scale un peu mieux avec drbd en pri/pri, mais perfs dégradées avec du iscsi (pas de cache), et ocfs2 a une petite tendance suicidaire au moindre problème réseau)
drbd/glustre ou autre, pas testé.
... ?
(et sinon après bah c'est du bon gros nas/san proprio...)
Arnaud. _______________________________________________ FRsaG mailing list FRsaG@frsag.org http://www.frsag.org/mailman/listinfo/frsag
Salut,
Le 19/07/2010 19:20, DjinnS a écrit :
Tu auras donc de meilleure performance, l'archi Nehalem (core i7) m'a beaucoup impressionné avec un gain de performance important par rapport au 54 (et aux anciens CPU 53, 33, etc ...).
Il y a encore mieux, les X56. J'ai pu avoir des X5650, HT activé => 24 coeurs. C'est parfait pour les serveurs webs, ca permet d'avoir un nombre impressionnant de page/secondes.
Et les X75 ça vaut quoi ?
Comparatif Intel : http://ark.intel.com/Compare.aspx?ids=47916,46497,
Je tente une config Dell : - soit R610 avec 2xX5680 @3,33GHz, 12Mo de cache par chip, 12 cores en tout - soit R810 avec 4xX7542 @2,66GHz, 18Mo de cache par chip, 24 cores en tout
A première vue je dirais que je peux gérer plus de transactions/s avec le R810, mais est-ce que le X7542 est beaucoup moins rapide que le X5680 ?
Le 21/07/2010 10:58, Greg a écrit :
Salut,
Le 19/07/2010 19:20, DjinnS a écrit :
Tu auras donc de meilleure performance, l'archi Nehalem (core i7) m'a beaucoup impressionné avec un gain de performance important par rapport au 54 (et aux anciens CPU 53, 33, etc ...).
Il y a encore mieux, les X56. J'ai pu avoir des X5650, HT activé => 24 coeurs. C'est parfait pour les serveurs webs, ca permet d'avoir un nombre impressionnant de page/secondes.
Et les X75 ça vaut quoi ?
Comparatif Intel : http://ark.intel.com/Compare.aspx?ids=47916,46497,
Je tente une config Dell :
- soit R610 avec 2xX5680 @3,33GHz, 12Mo de cache par chip, 12 cores en
tout
- soit R810 avec 4xX7542 @2,66GHz, 18Mo de cache par chip, 24 cores en
tout
A première vue je dirais que je peux gérer plus de transactions/s avec le R810, mais est-ce que le X7542 est beaucoup moins rapide que le X5680 ?
Salut,
Han ! J'ai pas encore eu l'occasion de toucher ces bêtes, donc je peux rien dire ... Par contre, sur le papier, les fonctionnalités ne sont pas les mêmes. Les X7542 ont l'air beaucoup plus cher et tu peux avoir 24 coeurs avec le 5680 pour "moins cher". Les R610 avec 2xX56 coûtent quand même un bras déjà ...
Je pense que ton gain sera déjà relativement important avec le passage en R610.
-- DjinnS
Le 21/07/2010 11:26, DjinnS a écrit :
Han ! J'ai pas encore eu l'occasion de toucher ces bêtes, donc je peux rien dire ... Par contre, sur le papier, les fonctionnalités ne sont pas les mêmes. Les X7542 ont l'air beaucoup plus cher et tu peux avoir 24 coeurs avec le 5680 pour "moins cher". Les R610 avec 2xX56 coûtent quand même un bras déjà ...
Les R610 n'ont que 2 sockets, donc 12 cores max, d'où ma question. Je ne pige pas pourquoi les X7542 sont plus cher alors qu'ils ont une finesse de gravure plus important (45nm contre 32nm pour les X56), moins de GT/s (5.86 contre 6.4), et une fréquence moins élevé (2.66 contre 3.33) ...
Le 21/07/2010 11:43, Greg a écrit :
Le 21/07/2010 11:26, DjinnS a écrit :
Han ! J'ai pas encore eu l'occasion de toucher ces bêtes, donc je peux rien dire ... Par contre, sur le papier, les fonctionnalités ne sont pas les mêmes. Les X7542 ont l'air beaucoup plus cher et tu peux avoir 24 coeurs avec le 5680 pour "moins cher". Les R610 avec 2xX56 coûtent quand même un bras déjà ...
Les R610 n'ont que 2 sockets, donc 12 cores max, d'où ma question. Je ne pige pas pourquoi les X7542 sont plus cher alors qu'ils ont une finesse de gravure plus important (45nm contre 32nm pour les X56), moins de GT/s (5.86 contre 6.4), et une fréquence moins élevé (2.66 contre 3.33) ...
C'est 24cores sur les X56 car ils supportent l'Hyper Threading (mais pas les X75). Donc tu peux monter à 2*12 cores => 24 (parfait pour un serveur Web).
Il y a beaucoup plus mémoire cache sur les X75, ce qui je pense, influence le prix du CPU. Je ne sais pas par contre s'il y a un réel gain au niveau de perf, il faudrait pouvoir faire les mêmes bench sur chaque type de machine pour savoir (même si certains se paluche sur les tests de charge avec des histoires de cache l2 blablablabla). Le gain des X56 étant relativement important au niveau de la puissance, et vu le prix des X75 (et du R800 en gros), je resterais pour le moment sur un R610, bonne machine, évolutive (96Go de RAM max si je dis pas de conneries, etc ...).
-- DjinnS
Greg wrote:
Le 19/07/2010 19:20, DjinnS a écrit :
Tu auras donc de meilleure performance, l'archi Nehalem (core i7) m'a beaucoup impressionné avec un gain de performance important par rapport au 54 (et aux anciens CPU 53, 33, etc ...).
Il y a encore mieux, les X56. J'ai pu avoir des X5650, HT activé => 24 coeurs. C'est parfait pour les serveurs webs, ca permet d'avoir un nombre impressionnant de page/secondes.
Et les X75 ça vaut quoi ?
Je tente une config Dell :
- soit R610 avec 2xX5680 @3,33GHz, 12Mo de cache par chip, 12 cores en tout
- soit R810 avec 4xX7542 @2,66GHz, 18Mo de cache par chip, 24 cores en tout
A première vue je dirais que je peux gérer plus de transactions/s avec le R810, mais est-ce que le X7542 est beaucoup moins rapide que le X5680 ?
Aucune idée pour les X75, mais je me pose la même question pour les nouveaux Opterons: vu qu'on commence à trouver des cartes-mères avec chipsets corrects et puces réseau Intel, ça peut à nouveau s'envisager dans des serveurs
On peut avoir jusqu'à 48 coeurs par machine avec ça par exemple: http://www.supermicro.com/Aplus/system/1U/1042/AS-1042G-TF.cfm http://www.supermicro.com/Aplus/motherboard/Opteron6100/SR56x0/H8QGi_-F.cfm
Est-ce que c'est mieux que du Nehalem classique ? Pour le calcul scientifique je ne me fais pas de souci, mais je n'ai pas trop d'idée pour une utilisation en tant que serveur web / base de données, etc...
Le 21/07/2010 11:34, Francois Tigeot a écrit :
Aucune idée pour les X75, mais je me pose la même question pour les nouveaux Opterons: vu qu'on commence à trouver des cartes-mères avec chipsets corrects et puces réseau Intel, ça peut à nouveau s'envisager dans des serveurs
On peut avoir jusqu'à 48 coeurs par machine avec ça par exemple: http://www.supermicro.com/Aplus/system/1U/1042/AS-1042G-TF.cfm http://www.supermicro.com/Aplus/motherboard/Opteron6100/SR56x0/H8QGi_-F.cfm
Est-ce que c'est mieux que du Nehalem classique ? Pour le calcul scientifique je ne me fais pas de souci, mais je n'ai pas trop d'idée pour une utilisation en tant que serveur web / base de données, etc...
SuperMicro ... non, ça peut pas être sérieux ?
-- DjinnS
Le mercredi 21 juillet 2010 11:55:26, DjinnS a écrit :
SuperMicro ... non, ça peut pas être sérieux ?
Bonjour, il faudrait revoir un peu les mauvais apprioris, qui existent principalement à cause d'intégrateurs peu scrupuleux qui montent les machines dans des caves, et où l'on peut retrouver un peu de tout dans un serveur soi disant "supermicro".
Les serveurs montés par supermicro en angleterre (et utilisant uniquement des composants certifiés), sont extrêmement robustes et performants. On les utilise dans les infrastructures les plus sensibles, et les plus lourdes avec une grande satisfaction.
J'ai plusieurs serveurs en production à base d'opteron à 6, 8 et 12 coeurs, et c'est vraiment *très* performants (testé principalement sur applications web, base mysql, et quelques applications métier en Java et autre).
amicalement,
Salut,
Aucune idée pour les X75, mais je me pose la même question pour les nouveaux Opterons: vu qu'on commence à trouver des cartes-mères avec chipsets corrects et puces réseau Intel, ça peut à nouveau s'envisager dans des serveurs
On peut avoir jusqu'à 48 coeurs par machine avec ça par exemple: http://www.supermicro.com/Aplus/system/1U/1042/AS-1042G-TF.cfm http://www.supermicro.com/Aplus/motherboard/Opteron6100/SR56x0/H8QGi_-F.cfm
Est-ce que c'est mieux que du Nehalem classique ? Pour le calcul scientifique je ne me fais pas de souci, mais je n'ai pas trop d'idée pour une utilisation en tant que serveur web / base de données, etc...
J'ai de bécanes comme ça avec du 6128 (rien a voir avec les amstrad !) soit 32 coeurs a 2Ghz...
Pas encore le cash pour du 12 coeurs, mais clairement avec 4 6128 + 64Go de RAM, tous les CPU a fond sur distributed net (une méthode pour voir si la machine est 100% stable après le memtest...) je mange 540W avec un cos phi 0,97 environ...
Ca fait peu de watt / core... Et aussi pour la virtu ou des licenses au processeurs physique (eg le monde des fenêtres colorées) c'est pas mal :)
Y a quelques issues avec la DDR3 mais en général ça roxe.
Pour avoir tenté d'avoir le même type de config chez Tyan, ça c'est terminé : je commande chez supermicro... (il n'y a qu'un proto carte mère 4 socket G34 et rien encore de dispo).
Supermicro avec 100% élements supermicro tourne impec... Sans soucis, par contre les gens qui mettent dans un boitier supermicro des trucs genre au hasard asus, tyan, gigabyte... bah faut pas s'étonner que ça marche mal... ou pas :)
J'ai des machines qui tournent depuis 5 ans... malgré des coups de chaud a 50°C dans la salle... et sur mon job-1 600-700 machines moins d'une merde par an... En général si ca passe le burn... elles tournent sans pb...
Xavier
Xavier Beaudouin wrote:
Aucune idée pour les X75, mais je me pose la même question pour les nouveaux Opterons: vu qu'on commence à trouver des cartes-mères avec chipsets corrects et puces réseau Intel, ça peut à nouveau s'envisager dans des serveurs
J'ai de bécanes comme ça avec du 6128 (rien a voir avec les amstrad
Joli :-) Ca incite à en acheter juste par nostalgie.
!) soit 32 coeurs a 2Ghz...
[...]
Y a quelques issues avec la DDR3 mais en général ça roxe.
Pour avoir tenté d'avoir le même type de config chez Tyan, ça c'est terminé : je commande chez supermicro... (il n'y a qu'un proto carte mère 4 socket G34 et rien encore de dispo).
Ca fait quelques années où ils sont à la masse chez Tyan. Les rachats ça n'a pas du aider...
Supermicro avec 100% élements supermicro tourne impec... Sans soucis
Ben oui, ils ont le taux de panne le plus faible que j'ai vu parmis les différentes marques qui me sont passées entre les mains. Je n'ai pas compris la réponse du troll qui a répondu avant toi.
par contre les gens qui mettent dans un boitier supermicro des trucs genre au hasard asus, tyan, gigabyte... bah faut pas s'étonner que ça marche mal... ou pas :)
Ca me fait penser à une boîte de péteurs de prix qui existait à Saint-Quentin en Yvelines il y a quelques années. Le nom m'échappe.
Distrimax ... mais le service était bof bof ... on en avait pour son argent : jamais rien en stock et le SAV : inexistant, je me rappelle de cette mauvaise période passée avec eux.
Le 21/07/2010 19:02, Yellis Services a écrit :
Francois Tigeot a écrit :
Bonjour,
Ca me fait penser à une boîte de péteurs de prix qui existait à Saint-Quentin en Yvelines il y a quelques années. Le nom m'échappe.
Distrimax ?
Emmanuel
FRsaG mailing list FRsaG@frsag.org http://www.frsag.org/mailman/listinfo/frsag
Yellis Services wrote:
Francois Tigeot a écrit :
Ca me fait penser à une boîte de péteurs de prix qui existait à Saint-Quentin en Yvelines il y a quelques années. Le nom m'échappe.
Distrimax ?
Non, c'était d'autres. J'ai fini par retrouver leur nom dans mes archives: Actualis.
Je n'ai jamais bossé avec eux, mais j'ai entendu plein d'histoires qui faisaient peur sur leur compte.
Toujours présents : http://www.actualis.biz/pro/Accueil.htm
http://www.actualis.biz/pro/Accueil.htmMais je n'ai aucun feedback d'eux.
2010/7/21 Francois Tigeot ftigeot@zefyris.com
Yellis Services wrote:
Francois Tigeot a écrit :
Ca me fait penser à une boîte de péteurs de prix qui existait à Saint-Quentin en Yvelines il y a quelques années. Le nom m'échappe.
Distrimax ?
Non, c'était d'autres. J'ai fini par retrouver leur nom dans mes archives: Actualis.
Je n'ai jamais bossé avec eux, mais j'ai entendu plein d'histoires qui faisaient peur sur leur compte.
-- Francois Tigeot, Zefyris
FRsaG mailing list FRsaG@frsag.org http://www.frsag.org/mailman/listinfo/frsag
Le Wed, Jul 21, 2010 at 09:02:45PM +0200, Philippe a écrit:
Toujours présents : http://www.actualis.biz/pro/Accueil.htm http://www.actualis.biz/pro/Accueil.htmMais je n'ai aucun feedback d'eux.
Pour les SM, on bosse avec Ahead: http://www.ahead-it.eu/fr/
Rien à redire. Serveurs impecs, livraison rapide, site web plutôt bien foutu, questions répondues rapidement... Bien.
Arnaud.
Philippe a écrit :
http://www.actualis.biz/pro/Accueil.htmMais je n'ai aucun feedback d'eux.
En 2006, j'ai commandé un boitier SC812S livré après 6 mois et 50 appels téléphonique et avec les paniers des disques dur manquant ...
Sinon, c'est plus chère que ASINFO
Emmanuel.
J'ai un ami qui a commandé chez kabia, apparemment ils sont très efficaces et sympa.
2010/7/21 Yellis Services www@yellis.net
Philippe a écrit :
http://www.actualis.biz/pro/Accueil.htmMais je n'ai aucun feedback
d'eux.
En 2006, j'ai commandé un boitier SC812S livré après 6 mois et 50 appels téléphonique et avec les paniers des disques dur manquant ...
Sinon, c'est plus chère que ASINFO
Emmanuel.
FRsaG mailing list FRsaG@frsag.org http://www.frsag.org/mailman/listinfo/frsag
Yellis Services wrote:
Francois Tigeot a écrit :
Ca me fait penser à une boîte de péteurs de prix qui existait à Saint-Quentin en Yvelines il y a quelques années. Le nom m'échappe.
Distrimax ?
Non, c'était d'autres. J'ai fini par retrouver leur nom dans mes archives: Actualis.
Les choses ont bien changées depuis ce temps. Actualis est maintenant une filiale de supermicro, et leurs serveurs sont directement montés par SuperMicro en angleterre. Ils ne font plus de serveurs low-cost ou autre matériel poubelle, mais fournissent maintenant des comptes comme le ministère de la défense, ou les centres de recherches.
Pour ceux que ça intéresse, je peux vous mettre en relation préférentielle avec eux. Seul défaut : les délais de livraison sur le matériel non standard (de 15 jours à 3 semaines). Pour le reste, *désormais* c'est impeccable (mais ça n'a pas toujours été le cas...)
amicalement,
christophe.casalegno@digital-network.net wrote:
Les choses ont bien changées depuis ce temps. Actualis est maintenant une filiale de supermicro,
Ca m'étonnerait beaucoup. D'où vient cette info ?
et leurs serveurs sont directement montés par SuperMicro en angleterre. Ils ne font plus de serveurs low-cost ou autre
[...]
Pour le reste, *désormais* c'est impeccable (mais ça n'a pas toujours été le cas...)
Il reste le fait qu'ils sont en redressement judiciaire...
Le jeudi 22 juillet 2010 07:37:02, Francois Tigeot a écrit :
christophe.casalegno@digital-network.net wrote:
Les choses ont bien changées depuis ce temps. Actualis est maintenant une filiale de supermicro,
Ca m'étonnerait beaucoup. D'où vient cette info ?
De moi ;) et je suis une source sure ;)
Il reste le fait qu'ils sont en redressement judiciaire...
Le temps de transformer la société, puisqu'elle n'est plus qu'une structure commerciale et de conseil en amont de Supermicro.
amicalement,
Christophe Casalegno wrote:
Le jeudi 22 juillet 2010 07:37:02, Francois Tigeot a écrit :
christophe.casalegno@digital-network.net wrote:
Les choses ont bien changées depuis ce temps. Actualis est maintenant une filiale de supermicro,
Ca m'étonnerait beaucoup. D'où vient cette info ?
De moi ;) et je suis une source sure ;)
Ca continue à m'étonner, vu que tout Supermicro a toujours privilégié la vente en indirect.
Le 22/07/2010 13:14, Francois Tigeot a écrit :
Christophe Casalegno wrote:
Le jeudi 22 juillet 2010 07:37:02, Francois Tigeot a écrit :
christophe.casalegno@digital-network.net wrote:
Les choses ont bien changées depuis ce temps. Actualis est maintenant une filiale de supermicro,
Ca m'étonnerait beaucoup. D'où vient cette info ?
De moi ;) et je suis une source sure ;)
Ca continue à m'étonner, vu que tout Supermicro a toujours privilégié la vente en indirect.
Mais c'est bien le cas. Les deux dernières commande actualis me sont parvenues en direct des chaines de montages supermicro. Précédement, c'est actualis qui gérait l'assemblage. Ils ne font plus que conseil/transmission de la commande chez SM.
Simon Morvan wrote:
Le 22/07/2010 13:14, Francois Tigeot a écrit :
Christophe Casalegno wrote:
Le jeudi 22 juillet 2010 07:37:02, Francois Tigeot a écrit :
christophe.casalegno@digital-network.net wrote:
Les choses ont bien changées depuis ce temps. Actualis est maintenant une filiale de supermicro,
Ca m'étonnerait beaucoup. D'où vient cette info ?
De moi ;) et je suis une source sure ;)
Ca continue à m'étonner, vu que tout Supermicro a toujours privilégié la vente en indirect.
Mais c'est bien le cas. Les deux dernières commande actualis me sont parvenues en direct des chaines de montages supermicro. Précédement, c'est actualis qui gérait l'assemblage. Ils ne font plus que conseil/transmission de la commande chez SM.
C'est surtout la partie filiale qui me laisse sceptique; la sous-traitance, ça n'a rien de vraiment exceptionnel.
Bonjour,
Le 21/07/2010 20:46, Francois Tigeot a écrit :
Yellis Services wrote:
Francois Tigeot a écrit :
Ca me fait penser à une boîte de péteurs de prix qui existait à Saint-Quentin en Yvelines il y a quelques années. Le nom m'échappe.
Non, c'était d'autres. J'ai fini par retrouver leur nom dans mes archives: Actualis.
Actualis n'assemble plus de serveur, ils n'ont plus qu'un rôle commercial et de support. Les machines sont assemblées par Supermicro directement en usine.
Sur le Supermicro j'ai bossé avec Actualis il y a longtemps, c'était n'importe quoi, ensuite Dataswift (avant le rachat) mais ça a été la cata et pour finir j'ai travaillé un bout de temps avec ASinfo mais j'ai laissé tombé suite aux problèmes matériels et surtout d'assemblage (vis qui se balade, câble USB sous la CM).
Supermicro fait du matériel de très bonne qualité et performant mais tout ce qui est soft (firmware, BIOS, IPMI) est vraiment à chier. Ils ont trop de modèles de cartes mères, chacune a un BIOS spécifique ce qu'il fait qu'un modèle n'est supporté que 6 à 12 mois. Pour l'IPMI c'est pareil, il existe des dizaines de firmware différents et incompatibles entre eux ce qu'il fait qu'ils n'arrivent pas à les gérer :
http://www.supermicro.com/support/bios/firmware.aspx
Sur une carte récente X8DRi-F (Dual Nehalem), l'IPMI est presque inutilisable. Le SSH donne accès à un shell bash dans le contrôleur (ARM), quand il y a des erreurs matérielles ça donnes des "Unknown error on NULL component"
Maintenant je n'achète que du HP, le matériel est moyen (chipset broadcom) mais le support est génial. Là un mec est venu changer la carte mère d'un serveur (DL320 G5p) qui avait plus de 2 ans et sans aucune garantie supplémentaire 24h après mon appel au support. Les BIOS sont supportés pendant 2 à 3 ans avec des MAJ régulières et corrections de bugs, le firmware IPMI est supporté des années. Ils ont 3 version de l'IPMI : Lo100-i (de la merde), ILO2 et depuis peu ILO3. C'est tout, le même firmware ILO2 tourne sur des dizaines de modèles de serveurs et sur plusieurs générations (G5 et G6).
Je reste moyennement content de HP, heureusement que le support est bon et que j'ai des bons prix sinon je serai allé voir du coté de Dell ou même IBM. J'ai déjà perdu 6 serveurs DL320 G6 d'un coup à cause d'un "bug" dans le firmware de l'alimentation, une carte mère DL320 G5p (chipset broadcom grillé) et là j'ai un DL360 G7 tout neuf qui me sort des erreurs MCE sur la RAM.
Frédéric.
Hello,
On 22/07, Frédéric VANNIÈRE wrote:
Sur le Supermicro j'ai bossé avec Actualis il y a longtemps, c'était n'importe quoi, ensuite Dataswift (avant le rachat) mais ça a été la cata et pour finir j'ai travaillé un bout de temps avec ASinfo mais j'ai laissé tombé suite aux problèmes matériels et surtout d'assemblage (vis qui se balade, câble USB sous la CM).
Supermicro fait du matériel de très bonne qualité et performant mais tout ce qui est soft (firmware, BIOS, IPMI) est vraiment à chier. (...) Maintenant je n'achète que du HP, le matériel est moyen (chipset broadcom) mais le support est génial.
Même expérience ici avec les Supermicro chez ASinfo. On a vite laissé tomber pour retourner à DELL (spécialiste du chipset foireux également). Les accès consoles via les cartes Drac sont pénibles (clavier fucked up) mais ça marche de base (et sans licence)
Le jeudi 22 juillet 2010 09:52:27, Frédéric VANNIÈRE a écrit :
Sur une carte récente X8DRi-F (Dual Nehalem), l'IPMI est presque inutilisable. Le SSH donne accès à un shell bash dans le contrôleur (ARM), quand il y a des erreurs matérielles ça donnes des "Unknown error on NULL component"
Je ne peux pas juger pour les architectures Intel, car on ne travaille qu'avec AMD sauf pour une modèle d'entrée de gamme à base de xeon x3430.
Sur l'ensemble des gammes utilisées et de leurs évolutions, l'ipmi 2.0 fonctionne parfaitement : interface web en java, fonctionne sous différent navigateur : reboot, reset, kvm, état du hardware de la machine et virtual media over network fonctionne parfaitement.
Ce retour est à considérer depuis début 2009, où l'on a remplacé les cartes Tyan par des supermicro. Au passage pas pour des raisons techniques (fonctionnement impeccable également), mais de difficulté d'approvisionnement.
amicalement,
-
Arnaud Launay -
Christophe Casalegno -
christophe.casalegno＠digital-network.net
-
Cyril Bellot -
DjinnS -
Djstey -
Dominique Rousseau -
Florian MAURY -
Florian MAURY -
Francois Tigeot -
Frédéric VANNIÈRE -
Greg -
Jérôme Nicolle -
Lilian RIGARD - Devclic -
Philippe -
Simon Morvan -
Xavier Beaudouin -
Yellis Services