Discussion :

[Zwiter]

Bonjour,
Je me retrouve a la charge de gérer un calculateur haute performance que mon équipe utilise dans le cadre de sa recherche en génétique (bio-informatique : séquençage).
Il est composés de :
- 3 chassis (SUN BLADE 6000 MODULAR SYSTEM)
- chacun contenant 10 blades (SUN BLADE X6270 SERVER MODULE).
- Chaque blade contient 2 Xeon, et 64GO de RAM minimum.
- 1 jbod 80TO, en ZFS raidz2
- infiniband

En résumé, c'est un HPC avec 20 noeuds, chacun pouvant exécuter 10 taches.

Mais le jbod est trop sollicité lorsque le HPC tourne a plein régime, et je voudrais acheter des disques locaux aux nœuds (blades) pour copier les fichiers de travail, ou écrire les résultats intermédiaires.
Je pense acheter pour chaque noeuds/blades 4 disques Seagate constellation 2.5" de 500GO. Je les configurerais en RAID0 : c'est un espace temporaire qui doit offrir un maximum de performance. Les blades X6270 supporte des disques 2.5", SAS 3GB/s ou sata.

Est ce que ca vous semble aberrant ? Y a t il mieux a faire ?

Ma limite de prix est de 25 000$ taxes incluses (environ 15 000euros). Je suis en train de me renseigner sur la capacité des blades X6270 en taille et type de disque. Je suppose que ce type d'équipement support les formes de RAID les plus courantes.

Merci
Z.

[gangsoleil]

Bonjour,

Pourquoi 500 Go en espace de stockage temporaire ? Es-tu certain d'avoir besoin d'autant ?

Si tu peux te "contenter" de 256 Go, je te conseille tres tres fortement de te tourner vers des disques SSD, dont les debits sont tres tres superieurs aux disques a plateau(x).
Pourquoi 256 Go ? Parce que c'est une bonne limite financiere.

Bon, par contre, je te souhaite bon courage pour la configuration si ce n'est pas prevu des le depart

Edit : un petit lien pour te donner une idee du prix de bons SSD.

[Zwiter]

Bonjour gangsoleil,
merci de ta réponse.
Il n'y aurait pas 500, mais 4*500 soit 2T par nœud de calcul. J'ai choisi 500 car il correspond au mon budget, et offre une taille raisonnable sur le noeud.

Il se peut que cet espace ait a stocker temporairement 250GO de fichiers par taches (je suis actuellement sur un projet ou chaque fichier fait 200GO, et j'en ai 150 a traiter). Sachant qu'on peut lancer jusqu'à 10 programmes/scripts sur un nœud, il faudrait dans le meilleur des mondes être capable d'accueillir 2.5TO.
Toutefois, 4 ssd de 256 est une idée tres sexi.


Question relatif aux SSD :
Est ce que 1 SSD aurait de meilleurs perf IO que 4 hdd en raid0 ?
Samsung pro : est un bon ssd ?
Est ce que linux supporte sans probleme les ssd (l'OS date de 2009, caos linux) ?

Merci de tes commentaires.

[Clotho]

Si tu dois multiplier les grappes de raid 0 tu vas avoir un taux de panne annualisé très élevé...

Après tes besoins sont vraiment spécifiques et je ne sais pas ce qu'il peut exister à ce sujet, j'aurais plutot tendance à dire qu'un disque simple de 4To (ou 3To, pas en dessous, les débit chutent notablement) sera moins risqué qu'une grappe de 4X500, même si le débit sera moindre, la charge sera elle aussi fortement réduite, et les temps d'accès améliorés, quant au MTBF j'en parle pas.

Pour les SSD, l'IOPS est vraiment incomparable, je crois qu'il y a un facteur 700 en moyenne entre HDD et SSD en pratique. Il est tard et j'ai sommeil, mais de mémoire un bon HDD fait dans les 200 iops en moyenne, contre plus de 15.000 pour les plus gros SSD (et plus de 150.000 sur des cas extrêmement favorables qui n'ont pas de sens, mais qui sont ceux annoncés sur les boites...). C'est dû aux temps d'accès, inférieur au dixième de ms sur les SSD et supérieur à 7-8 ms sur un disque dur. Pour avoir un raid 0 sur un PC un peu vieux, je peux te dire que le temps d'accès moyen augmente avec le nombre de disques en RAID, sous windows (et certainement sur tous les autres OS) je suis à 12-13ms sur mon PC de remplacement.

Le samsung 840pro est actuellement le SSD le mieux noté avec les derniers intel, qui restent la référence dans le monde pro.

Normalement Linux ne pose pas de soucis avec les SSD quels qu'ils soient, ils sont totalement assimilables à des disques durs en "sortie" de Sata, c'est même un peu mieux que windows (trim, indexation, défragmentation silencieuse, etc...)

Je suppose que vous aviez réfléchi a vos besoins et vos capacités, mais habituellement on dit que le JBOD est le plus plastique/pratique, mais aussi le plus pourri au niveau des temps d'accès et de la puissance d'exécution, qu'est ce qui vous avait fait choisir ça au lieu d'un "gros" raid 5/6 ou autre ? Je n'en ai jamais vu fonctionner sur de si grosses capacités, je dis peut être une bêtise, dans ce cas je suis curieux d'avoir l'explication.

Pour notre boulot on a changé une de nos lames pour faire du stockage (sans commune mesure avec ton histoire) je sais qu'on nous a proposé une lame avec des disques à plateaux pour 60To et qu'on a 2To de disque à puces flash (je ne sais pas si c'est un ram disk ou des SSD) qui font office de cache, c'est pas parfait mais c'est vraiment un progrès par rapport à la précédente.

[Zwiter]

Merci Clotho pour tes insights.

Je vais essayer de te répondre au mieux d'après ce que je sais et ce que je susppose.

Le jbod a ete commandé debut 2011. Le prix d'un ssd de 256GO a cette époque était de 8000$. De plus, on travaillait avec des fichiers de maxi 3GO. On ne s'imaginait pas des fichiers de 250GO en 2013.

J'ai donc le jbod qui stock les données. dedans, j'ai 24 disques de 3T formant 1 pool raidz2 de 3 vdev. Ca fait donc 3 x 6 disques (donc 2 spares pour chaque vdev). La dessus, il y a 2 SSD de 230GO en cache. Avec cette configuration, j'atteinds un IO de 1.5k et une vitesse de lecture et ecriture simultanée respectivement de 70MO/s et 30MO/s (sachant qu'il y a une compression gzip-1). Sans IO, et un ecriture pure, le jbod produit dans les 600MO/s. Je suppose que en ce temps la, c'etait le meilleur rapport prix-capacite-performance.

Pour le raid0 sur les noeuds de calcul : c'est un espace temporaire, et qui peut etre faillible. Si un disque venait a lacher, on refait le raid0 et on relancera le calcul. Il n'y aura pas de perte de données, uniquement perte de temps.

J'hesite enormenent apres vos commentaires, mais je penche pour le SSD.
Pour le HDD : plus de place
Pour le SSD : plus de performances
DOnc a moi de savoir ce que je veux en 1er...

[gangsoleil]

Donc a moi de savoir ce que je veux en 1er...

Je pense que ce qui t'interesse, ce sont les performances du cluster, donc la vitesse.

Neanmoins, vu l'evolution de volumetrie que vous avez eu, il faut absolument prendre en compte ce qu'il en sera demain : si dans 6 mois vous avez des volumetries de 500 Go, ce n'est pas la meme chose que si ca reste "stable" a 250Go. Et si c'est dans 2 ans, la question ne se pose pas, car les technologies auront tellement evoluees qu'on pourra (probablement) rajouter des disques SSD de 1 ou 2 To pour pas (trop) cher.

[Zwiter]

Voici mes prédictions sur 2 ans :
250GO le fichier, c'est la nouvelle tendance. La technologie date de 2-3 ans, mais ce sont les objectifs qui ont évolué : jusqu'à maintenant, on séquençait uniquement la portion de l'ADN qui aurait une fonction. Par exemple faire une protéine, ou une région régulatrice. On appelle ceci l'exome, et il représente 1/10 de notre ADN. Maintenant, on s'intéresse a l'ADN entier (le génome). Ceci est rendu possible par des prix de séquençages très abordables. A ce ci s'ajoute la qualité du séquençage. Pour une meilleur qualité, on séquence plusieurs fois le même génome. Le fichier final s'en retrouve d'autant plus grand. Toutefois, 250GO devrait etre un maximum. Des fichiers plus gros n'auraient pas plus d'intérêt. Je pense donc que ce type de séquençage. et donc de fichier, devrait être la tendance pour les 2 prochaines années.

Notre problème, les IO
A cause de cette taille de données, notre bottle neck est la capacité a lire les fichiers. A quoi ca sert de pouvoir exécuter 200 programmes a la fois si une fois que 10 sont lancés, le disque est saturé de IO. Je cherche donc une solution pour diminuer ce problème.
Du coté de la perfomance, nous devrions etre ok : 36 Xeons a 2.27GHz, avec 64GO RAM minimum. Nous avons aussi accès a des supercalculateurs d'universités : 647 noeuds, 7700 Intel Westmere-EP X5650 hexa-coeurs, @ 2,667GHz.
Mais la-bas, on ne veut pas de moi car je sature tout avec les IO :p

L'argent (c'est important !)
Actuellement, nous avons 70 000$ restant pour mettre a jour notre calculateur haute performance. Je viens de me rendre compte (en posant la question a l'administration... <soupir>) que cette argent est disponible que jusqu'à la fin 2013. Donc j'ai, avec les délais administratifs, un mois pour tout dépenser. L'année prochaine, nous devrions refaire une demande de fond sur 3 ans. L'avenir sera donc débattu plus largement a ce moment.
Par contre, j'ai une grosse restriction sur ces 70k : je ne peux les dépenser que 25k a la fois. Sinon j'embarque dans une très longue procédure d'appel d'offre.
En résumé : je ne peux dépenser que 25k de disques. Puis 25k sur autre chose.

La solution que je propose : les disques locaux
Actuellement : les calculs s'effectuent sur le jbod (ZFS raidz2 montés en NFS sur les nœuds de calculs). Un gros programme ralenti donc le tout.
Avec les disques locaux, les données sources du programme seront copier sur le disque local du nœud, puis les calculs débuterons. La phase de copie sera donc limitant, mais avec un programme qui tourne 3 jours, c'est plutot négligeable.
En prix, ca donne environ ca, en faisant correspondre les prix entre les 2 solutions :
4 HDD (4x1T) * 20 noeuds * 270$ (1T 2.5 seagate constellation) = 21 600 $
2 SSD (2x512G) * 20 noeuds * 500$ (samsung pro 840 512GB) = 20 000 $

Conclusion
Je ne connais pas grand chose dans les systèmes de gestions de fichiers haute performance. C'est pourquoi j'écris mes réflexions ici, et je demande votre avis.
Je cherche a amélioré pour système pour ne pas être limiter par les IO.
Les SSD semble donc une bonne solution. des SSDs locaux aux nœuds permettent de ne pas pénaliser les autres programmes. De plus, les données copiées sur le ssd ne transitent plus via le réseau.
Toutefois peut etre que un jbod de SSD commun aux noeuds permettrait d'aitre plus trouver vers l'avenir. Le jbod aurait encore de la place de libre pour ajouter du stokage (hdd). De plus, un SSD brisé sera plus facile a changer (raidz2 + hotswap). Mais si un programme arrive encore a saturer, les autres programmes s'en retrouvent ralenti.

Les SSDs locaux semblent plus adaptés, mais je n'en ai pas la certitude. Je vais demander encore des avis. Je tiens énormément compte des vôtres. Il m'on fait deja réaliser que le HDD est une mauvaise option (IO).

Merci a vous.
Z.

[gangsoleil]

Bon, en resume :
en budget, les deux passent.
ton besoin, c'est l'IO. Et de ce cote la, tu ne trouveras pas mieux que le SSD.

Si tu as un peu de rab sur le budget, prends quelques disques en plus : plus tu as de disques, plus tu as de risque qu'il y en ait un qui plante. Si tu en as 5 de cote, tu seras content de pouvoir en changer "dans la minute" au lieu de "dans le courant de l'annee prochaine si les budgets sont votes".

[mode gourmand]
Est-ce que tu ne peux pas faire deux commandes, une pour des disques SSD locaux, montant max 25 000, et une pour un jbod de SSD communs aux noeuds ?
Si besoin, tu peux prendre des disques de marque differente pour "justifier" les deux commandes.

Precision pour ceux qui ne connaissent pas les trefonds de la gestion de budget de l'administration : dans certains cas, les budgets non utilises sont tout bonnement perdus ; c'est a dire que sur les 70 000 disponibles cette annee, si l'equipe n'en depense "que" 50 000, les 20 000 restants ne seront pas disponbiles l'annee prochaine -- et l'equipe ne sera pas non plus felicitee pour avoir depense moins. D'ou ma proposition.