Le carnet du grincheux

Je ne me suis converti aux serveurs X86 que très récemment et, je dois dire, par défaut, faute de combattants. En effet, ma conversion n'a pas été dictée par une hausse sensible de la qualité des serveurs de type PC, mais par la baisse assez nette de celle des architectures concurrentes. Pourquoi aujourd'hui payer le prix fort d'une architecture bien conçue alors que la qualité n'est plus au rendez-vous ?

Pourtant, j'étais l'un des derniers mohicans.

Depuis le milieu des années 1980, j'ai eu successivement des S.M.T. Goupil (G3/6809 avec disques durs ST506), des IBM PS/2, du matériel Digital Equipment Corporation sous la forme de PDP-11, VAX et Alpha et une foultitude de matériel Sun Microsystems, exclusivement d'architecture Sparc.

Fig. 1 : logo permettant de reconnaître un matériel informatique peut-être de qualité

Parmi le matériel Sun, j'ai eu l'occasion de voir passer chez moi une partie de la série sun4c (SparcStation 2, SparcStation IPC, SparcStation IPX avec Weitek PowerUP), les plus beaux représentants de la famille sun4m (SparcStation 5 et 20 avec SuperSparc II et HyperSparc), le serveur raté sun4d 600M, quelques sun4u (Ultra 1E, 2E, 5, 60, 80, 420R, Blade 2000) et des sun4v (T1000 et T2000). J'ai donc une vue à peu près représentative du matériel, de son évolution et de ses points faibles.

Les SparcStations étaient des machines très onéreuses. Mais je dois dire que toutes mes anciennes sun4c et sun4m fonctionnent toujours. Même une SparcStation 20 allant sur ses vingt ans et pourtant stressée puisqu'elle embarque 448Mo de mémoire, une VRAM de 8Mo, quatre processeurs ROSS HyperSparc à 200MHz, une carte SCSI additionnelle, quatre ports 100BaseTX supplémentaires et deux disques U320 SCSI de 300Go, tout cela avec son alimentation d'origine fournissant à peine plus de 100W mais avec quelques ventilateurs supplémentaires. Un processeur ROSS, ça chauffe un petit peu, alors des modules doubles, même en double largeur, ça chauffe beaucoup.

Les Ultra 1E et 2E sont d'assez bonne facture et ne posent pas de problèmes particuliers une fois oublié le mauvais vieillissement du ventilateur du processeur UltraSPARC 1 de l'U1E. En revanche, il y a eu une certaine dégradation lors du passage des machines Sbus/UPA aux machines PCI/UPA. Et un naufrage total lors du passage du PCI/UPA vers le PCI-X/PCI-E. Oracle n'a plus eu qu'à se baisser pour ramasser Sun Microsystems.

L'Ultra 5 est la première machine à problèmes. Le contrôleur de disque dur, un vulgaire contrôleur IDE, est vérolé jusqu'à la moelle. Les barrettes mémoire n'arrêtent pas de lâcher les unes après les autres. Heureusement, ce sont des barrettes ECC, donc le système prévient gentiment qu'elles sont en train de mourir avant qu'il ne soit trop tard. Enfin, il prévient souvent, presque toujours, mais cela n'empêche pas les mauvaises surprises. En dehors du caractère ECC, ces barrettes n'ont rien de plus qu'une vulgaire barrette mémoire d'un PC de bureau. Chose amusante, elles vieillissent bien plus mal que des barrettes no name de PC fabriquées en Chine sans aucun contrôle qualité. Faire de telles économies de bouts de chandelle au vu du prix d'achat d'une Ultra 5, c'est tout de même se moquer du monde voire prendre ses clients pour des imbéciles. À partir de ce moment, la part des machines Sun a commencé à s'écrouler. Le fait qu'il était possible d'utiliser Solaris sur des PC standard n'a pas aidé non plus.

Les U60, U80 et U420 étaient plus fiables que les U5. Enfin, si l'on peut dire. Sur les U60, un peu moins sur les U80, les alimentations n'arrêtent pas de claquer les unes après les autres. Heureusement, elles meurent sans injecter de haute tension sur l'électronique. Elles meurent parce qu'un condensateur travaille trop près de sa tension maximale, avec une ondulation trop forte et donc chauffe, vieillissant prématurément. Elles meurent aussi parce que les diodes Schottky d'entrée sont un peu faibles. Économiser trois francs six sous sur des machines qui valaient plusieurs dizaines de milliers de francs est mesquin. Les U80 provoquent elles-mêmes des erreurs de correction de la mémoire dès qu'elles contiennent 4Go de mémoire, ce que ne font pas les U420 utilisant pourtant la même carte-mère et les mêmes mémoires. Allez comprendre.

Et que dire des Blade 2000 ? Les Blade 2000 sont sensibles. Très sensibles. Les capteurs de température des processeurs renvoient par moment des valeurs aberrantes forçant la machine à s'arrêter brutalement car elle se met en protection. En mettant à jour l'openprom, on arrive à corriger le problème. Encore faut-il trouver la bonne version de l'openprom et avoir un contrat chez Sun pour pouvoir télécharger le patch. Mais cela ne règle pas le problème de la mémoire. Souvenez-vous. Nous étions le 1^er août 2010. Une éruption solaire d'intensité C3 est dirigée vers la Terre, conduisant les 3 et 4 août 2010 à des tempêtes magnétiques avec force aurores boréales. Le samedi 7 août, les champs magnétiques autour de la tache 1093 produisent une éruption. Les sondes de la NASA photographient l’explosion qui génère une grosse protubérance de classe M1 et précipite une éjection de masse coronale (CME) dans l’espace — qui apparemment évite de justesse le plan de la Terre, nous sommes chanceux. L’explosion provoquent aussi des bruits de glissades dans les hauts parleurs de certaines radios ondes courtes. Et les Blade 2000 tombent comme des mouches avec des erreurs de mémoire du type :

Cheetah error trap taken
afsr[0000004000000037] afar[0000000034ae79c0]
TL1(0) TPC[4f2808] TNPC[4f280c] O7[4f27ec]
TSTATE[4411001607] M_SYND(0), E_SYND(37)
Highest priority error (0000004000000000)
"HW corrected E-cache ECC error for writeback"
ERROR(1): AFAR E-syndrome [J0203, pin 135]
ERROR(1): D-cache idx[0] tag[0000000000000000]
utag[0000000000000000] stag[0000000000000000]
D-cache data0[0000000000000000] data1[0000000000000000]
data2[0000000000000000] data3[0000000000000000]
I-cache idx[0] tag[0000000000000000]
utag[0000000000000000] stag[0000000000000000]
u[0000000000000000] l[0000000000000000]
I-cache INSN0[0000000000000000] INSN1[0000000000000000] 
INSN2[0000000000000000] INSN3[0000000000000000]
I-cache INSN4[0000000000000000] INSN5[0000000000000000]
INSN6[0000000000000000] INSN7[0000000000000000]
E-cache idx[34ae79c0] tag[0000000000000045]
E-cache data0[0000000000000000] data1[0000000000000000]
data2[0000000000000000] data3[0000008000000000]

Plusieurs barrettes mémoire à changer pour que tout redevienne fonctionnel.

Il y a quelques mois, j'ai eu les mêmes problèmes sur des T1000. Barrettes mémoire parties en vacances pour des durées indéterminées. Pourtant, ces machines sont branchées sur un courant secouru parfaitement ondulé. Et cette nuit, rebelote :

SC Alert: MB/CMP0/CH3/R1/D0 deemed faulty and disabled
SC Alert: MB/CMP0/CH3/R1/D1 deemed faulty and disabled
ERROR: The following devices are disabled:
MB/CMP0/CH3/R1/D0 MB/CMP0/CH3/R1/D1

Ce n'est pas beau. J'ai réussi à faire redémarrer ce serveur à distance en désactivant deux barrettes mémoire sur les huit. Sur une machine coûtant la bagatelle de plus de 15000€ HT, c'est navrant.