Salut,
je dois, pour des raisons de consommation, remplacer le (petit) cluster du boulot. Pour information, nous faisons du traitement scientifique d’images satellites. Nous avons besoin de puissance de calcul et d’I/O (aussi rapide que possible).
Actuellement, on a 6 nœuds + un maître. 46 cœurs, 2 à 3.5go par cœur, 72 disques (12 à 24 disques par machine), pour un espace total de 140to (70 réellement utilisables avec la solution actuelle).
Logiciellement parlant, on a:
HTCondor pour la répartition des tâches.
MooseFS pour le FS réparti (dont la version 1 n’est plus maintenue, la 2 n’est plus libre).
Ganglia surveille le tout.
Rien™ ne se charge de la configuration des machines sinon mes petits doigts.
Le tout sur une plate-forme CentOS 6 x86_64.
Je dois, si possible avoir mieux, tout en consommant (bcp) moins, le tout sans éclater le petit budget d’environ 20k€ HT.
J’ai trouvé 3 solutions matérielles qui semblent correspondre (je mets les liens vers là où on achète nos bécanes habituellement, si vous connaissez mieux, ça m’intéresse, nous ne sommes liés en rien à la boite en question).
- Une grosse babasse gavée de CPU et de disques. 1800W, 4U. 18k€. 48 cœurs opteron 6xxx, 256 go (max) de ram (5.3go/cœur), 24 disques 6to. Le gros inconvénient, si la machine lâche, on a plus aucun moyen de production, ni d’accès aux données.
- Un Power Cloud R3PCA12-24, 1620W, 3U, 20k€. 96 cœurs opteron 3380 en 12 servers, 32 go (max) soit 4go/cœur, 2 disques par serveur soit 24 total (6to toujours). Beaucoup de CPU même si ce ne sont pas les plus rapides du monde, un déséquilibre cpu/disques qui me fait craindre un côté I/O surchargé et donc lent. Par contre, si une machine tombe, on ne perd que deux disques ce qui risque d’être peu problématique côté système de fichier réparti pour la disponibilité des données. Machines « maxées » (impossible d’ajouter plus de cpu ou de ram).
- Un FatTwin 12 disquse. 1620W, 4U, 23k€. 48 cœurs physiques/96 HT (intel xeon E5 2620v2) en 4 serveurs, 64 go (5.3 go/cœur), 256 max, 12 disques par serveur, 48 disques total. J’aime l’équilibre un disque/un cœur. J’aime beaucoup moins la chute d’une machine qui fait forcément que le FS réparti tombe avec (je ne connais pas de solution qui supporte à coût décent qu’un quart du volume disparaisse). La machine (à grands renforts de brouzoufs, intel n’y va vraiment pas avec le dos de la cuillère) peut évoluer en nombre de cpu (96 cœurs physiques max total) et en ram.
Côté logiciel:
1. On garderait HTCondor qui fait bien son travail.
2. MooseFS est remplacé par une solution utilisant l’Erasure Code. Contrairement à MooseFS dont le coût est de 2 (réplicas) pour assurer un minimum de sécurité des données, cette technique permet un coût de 1.5 (je simplifie, pas la même de tergiverser). Je pense utiliser RozoFS, mais rien n’est gravé dans le marbre.
3. Ganglia pourrait bien rester, HTCondor s’y intégrant bien (en théorie, j’ai pas eu le temps de faire la conf).
4. J’hésite à mettre en place une solution type Ansible/Salt/Chef/Puppet bien que je les trouve assez overkill pour si peu de machines. J’aimerais trouver plus simple/plus rapide à déployer. et tant qu’à faire y intégrer les desktops utilisateurs (CentOS) ainsi que notre malheureux serveur web/bdd. soit 7 machines utilisateur (dont un windows), les serveurs au nombre de x + la gateway + le serveur web/bdd + le failover.
Je passerais, dans la foulée, les machines utilisateurs/serveurs à CentOS 7.
Voilà pour le topo. Merci pour vos lumières, je reste terriblement indécis. Le FatTwin me fait de l’œil, mais niveau HA c’est pas génial. Le microcloud me fait de l’œil, mais niveau I/O, c’est pas génial. Quelqu’un connaitrait-il une solution entre les deux ?
Pour le côté résistance, j’aime bien AMD…et quand je vois les prix Intel…bref.
Merci d’avance pour vos conseils et propositions. (inutile d’essayer de me « vendre » du debian ou ubuntu ou suse ou que sais-je. l’OS utilisé n’est pas en cause, merci :))
# FS Posix et x86_64
Posté par laurent wandrebeck (site web personnel) . Évalué à 5.
Et j’oubliais, nous devons rester en x86_64 et avoir un accès POSIX aux données. L’utilisation de solutions de stockage proprio est hors de propos, ne serait-ce que par le coût et…le fait que ce soit proprio ;)
# Type d'IO, Conso ?
Posté par KiKouN . Évalué à 10.
Tu dit que la principal raison de ce changement est la conso. Mais tu ne donne aucune valeurs. A quoi bon mettre 20k€ si au final on ne sait pas combien on va gagner en conso ?
Combien consomme la chose ? chacun des noeuds ? chacun de ces composants ? Marié SSD et HDD base conso peuvent faire gagner pas mal sur des HDD entreprise. Couper de la ram non utilisée aussi. ( pour moi, 1Go de ram ~ 1W , moins maintenant)
Quelles types d'IO as-tu besoin ? Est-ce plus du débit ou un grand nombre de petites écritures ? Est-ce que le cluster calcule 24h/24h ? Car cela me semble bizarre ce besoin de N coeur/M hdd par machine.
Sur un plan comme cela, ma première idée serait de partir sur 2 ou 3 noeuds stockage/hyperviseur et des noeuds de calculs à côté plus ou moins à la demande permettant de recycler aussi l'existant si besoin.
[^] # Re: Type d'IO, Conso ?
Posté par laurent wandrebeck (site web personnel) . Évalué à 2.
Pour la conso, en faisant très à la louche intergalactique, le cluster actuel c’est 7×900W.
La machine unique c’est 1620W. Ce qui est dans les clous (nous devons drastiquement baisser notre conso du fait du datacenter mutualisé). Je te passe les détails. Nous n’aurons pas de mesure précise de conso, le DC n’en étant pas équipé, les calculs de coût étant basés sur les alims. Je sais, je sais…mais c’est comme ça. Nous visons ici 2000W totaux.
Pour le stockage, chaque machine (en fat twin ou microcloud) se voit accompagnée d’un mini ssd 8go pour l’OS, les disques 6to étant sans doute des WD green ou red, ne serait-ce que pour le prix. les 7200rpm chiffrant au double.
Pour le type d’I/O, typiquement, tout ou partie d’une image est chargée (+ les éventuelles données exogènes), les calculs sont effectués, le résultat est écrit. Tendance à la lecture de « grosses » données (une image commence environ à 40mo, jusqu’au 500 ou plus, fonction de l’instrument, et ça tend clairement à grossir. On limite la conso de ram fonction des clients, entre 1.5go et 4 générallement, avec quelques rares monstres très orientés CPU), idem pour l’écriture, donc.
Mais les utilisateurs regardent les données aussi, parfois de manière partielle, et tapent dans les données de manière plus ou moins automatisée pour sortir des stats, graphs…donc on a aussi une partie d’accès aléatoires. Le cluster n’est pas chargé h24. Quant au besoin N cœurs/M hdd, je me base simplement sur le comportement du fs déployé. avec 72 disques pour 46 cœurs, on arrive à faire ramer le fs. Maintenant la techno utilisée va changer, donc…
hélas je n’aurais pas la possibilité de faire des tests de charge avant de m’être arrêté une fois pour toute sur le matos et l’avoir acheté. Pas de retour arrière possible.
La multiplication de machines est impossible (et trop consommatrice). Nous devons aussi prendre la place la plus infime possible (rentrer dans une ½ baie est idéal). Or nous avons déjà:
1 U switch stacké 1 50W
2 U switch stacké 2 50W
3 U gateway/fw 300W
4 U nas 50W
5 U serveur home 1 50W
6 U serveur home 2 50W
7 U serveur web/bdd 300W
Les serveurs actuels prennent 6×2U + 3U, soit 15U. 22U, plus le 1U du bandeau, 23. Avec microcloud ou fattwin, on rentre dans 12/13U, ce qui est presque trop peu ;)
J’espère avoir répondu correctement à tes questions. Merci pour ton intervention, en tout cas.
[^] # Re: Type d'IO, Conso ?
Posté par barmic . Évalué à 4.
Je me demande si ton archi est vraiment pertinente.
J'ai l'impression qu'un FS distribué fait trop de choses pour toi. Si j'ai bien compris les nœuds ne travaillent pas ensemble. Tu pourrais pas avoir avoir une machine cheff d'orchestre qui envoie les tâche à chaque nœud ceux-ci vont aller chercher leur donner sur une machine dédiée au stockage faire le boulot en local puis renvoyer le résultat au stockage central puis indiquer au répartiteur qu'ils ont fini ?
L'avantage c'est que les traitement deviennent totalement locaux et que tu n'a pas la complexité d'un FS distribué.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Type d'IO, Conso ?
Posté par laurent wandrebeck (site web personnel) . Évalué à 2.
Typiquement, on a n images à traiter, faisant n ou n×x résultats. ou encore (moins courant), lecture de n images et en sortie une seule. Chaque code est générallement écrit pour traiter une image (sans compter qu’on hérite parfois/souvent de codes existants et qu’il est inenvisageable de les réecrire).
Actuellement, les nœuds récupèrent l’image à traiter (le chef d’orchestre c’est HTCondor), la colle en local, la traite, renvoient sur le fs réparti. Il arrive aussi qu’on traite directement sur le fs réparti.
Le déploiement du FS réparti n’est pas un gros problème. Jette un œil à moosefs si tu as le temps, c’est d’une simplicité effarante. L’avantage étant aussi la disponibilité des données. On supporte le vautrage de deux bécanes simultanément sans être bloqué, ce qui n’est pas le cas avec une baie (ou deux).
Mais moi aussi, je me demande ce qui est le plus pertinent :) . L’archi actuelle a grossi machine par machine, mfs était un bonheur sans nom à ce niveau. là, j’ai l’occasion d’avoir un truc tout propre alors j’essaie d’en profiter.
[^] # Re: Type d'IO, Conso ?
Posté par ptit_poulet . Évalué à 1.
Bonjour,
Je suis d'avis comme Barret Michel.
Je partirai plutôt sur un nas avec plusieurs interfaces réseaux : 2 ou 3 lien gigabits.
Pour la partie calcul et économie d'énergie, HTCondor peut gérer la mise en hibernation des PC non exploités et les réveiller automatiquement si nécessaire. Il faudra surement creuser cette partie histoire d'établir une stratégie énergie pour gagner un peu.
Par contre pour la partie calcul, avez-vous déjà pensé à vous orienter vers les gpu ? Il faudrait voir (si cela est compatible avec votre projet) à faire les calculs de rendement/consommation/prix d'achat.
[^] # Re: Type d'IO, Conso ?
Posté par laurent wandrebeck (site web personnel) . Évalué à 1.
Le côté hibernation empêche effectivement l’usage d’un fs réparti. D’un autre côté, on peut laisser tourner les bécanes, vu que le calcul de conso réel n’existe pas. Une machine éteinte ne nous fera rien gagner. Je sais c’est pas écolo etc. mais en divisant la conso finale par un bon 3 je pense que c’est déjà pas mal ;) Mais si, effectivement, on part sur du nas, autant éteindre les nœuds ne foutant rien.
Pour le GPU, comme je disais plus haut, nous avons beaucoup de codes existants, et parfois hérités, il est impossible pour nous de les réecrire en cuda ou opencl. de une, car cela serait très long à faire (passer du mono-thread au massivement parrallèle demande beaucoup de travail), qu’on est pas payé pour, et qu’on a pas non plus les moyens humains. De deux, parce que les clients ont besoin de codes fonctionnant au sein de leurs architectures existantes (et le spatial n’est pas vraiment un milieu se précipitant sur les nouvelles technos ;)).
Nous avons porté un code de type monte carlo (mono thread et en fortran siouplé) en gpu car nous étions financés. Cela a donné de bons résultats, et avons une machine s’occupant de ces calculs. Mais ça reste limité pour les raisons suscitées. On espère que ça va progresser, mais on y est pas encore…
[^] # Re: Type d'IO, Conso ?
Posté par ptit_poulet . Évalué à 1.
Peut-être faudrait-il penser à utiliser les postes de travail déjà existants. Par exemple quand tout le monde part manger et si vous avez 50 postes de travail, c'est 50 machines "qui ne servent à rien". Ou aussi possibilité d'allouer un certain pourcentage des ressources des postes de travail si ceci ne sont pas utilisés pour faire tourner de grosses applis, par exemple s'ils ne servent qu'à faire tourner un client mail et une suite office, pas besoin de tout le processeur et de la ram.
[^] # Re: Type d'IO, Conso ?
Posté par laurent wandrebeck (site web personnel) . Évalué à 1.
C’est le cas, nos 6 machines utilisateurs peuvent être mises à contribution (oui oui on est des liliputiens à gros besoins). La bande passante vers le bureau est plus limitée, et quand 50 process moulinent, le fs fait ce qu’il peut (mfs n’est pas non plus un foudre de guerre).
[^] # Re: Type d'IO, Conso ?
Posté par NeoX . Évalué à 4.
donc tu as un monstre de calcul et de stockage
mais chaque utilisateur dispose d'une quantité CPU/RAM limitée (1 à 4Go par utilisateur)
c'est dommage ?
avec une machine moins puissante, mais en allouant plus de CPU/RAM aux utilisateurs, les traitements seraient plus courts,
et tu pourrais toujours avoir autant d'utilisateur, cadencé.
perso je preferes avoir 10 utilisateurs qui utilise chacun la machine 1 minute.
plutot que d'avoir les 10 utilisateurs en meme temps, qui vont charger la machine pendant 10 minutes
d'abord parce que ca fluidifient les I/O en limitant les acces concurrents (un seul utilisateur, une seule serie d'objet).
et au final ils auront tous l'impression d'avoir un truc rapide (1min de traitement plutot que 10 minutes)
[^] # Re: Type d'IO, Conso ?
Posté par laurent wandrebeck (site web personnel) . Évalué à 1.
Quand un client (à qui on va livrer le code industrialisé pour qu’il se charge de la prod par exemple) a un cluster et nous dit que le code doit pas manger plus de x go en ram, et bien on s’arrange pour utiliser le max autorisé. Ce n’est pas plus compliqué que cela. Il est beaucoup plus facile de faire du monothread et de parralléliser sur les images que découper les images pour tout regrouper ensuite (encore pire quand il y’a une dépendance entre les pixels).
Les calculs ont tendance a être lourds, aussi, la partie I/O, même si elle est lourde, représente rarement (jamais ?) plus de la moitié du temps de processing. Si on n’utilise pas au max les CPU, on perd donc du temps.
Dans les cas où un code a besoin de beaucoup de ram (disons 28go), htcondor le pose sur une bécane pouvant l’encaisser, le cpu patauge tout ce qu’il peut et les autres cpu restent inutilisés (si le code est monothread) parce qu’ils n’ont plus/très peu de ram dispo et que les autres jobs veulent davantage que ce qui est disponible, auquel cas ils vaquent sur d’autres machines ou attendent que ça se libère.
Mais j’ai la désagréable impression de répondre à côté de la plaque ou d’avoir raté le point de ton commentaire.
[^] # Re: Type d'IO, Conso ?
Posté par NeoX . Évalué à 2. Dernière modification le 26 octobre 2014 à 14:58.
pas complement, puisqu'il y a des precisions utiles.
si ton CPU passe 50% de son temps à "attendre" les données des disques durs, alors tu "perd" du temps ;)
donc il est probable que quand un des noeuds veut acceder à des données qui sont sur les autres noeuds, il va utiliser du temps CPU et des I/O de cet autre noeud, qui n'est peut-etre pas dispo puisqu'en cours de calcul => donc de l'attente.
ton probleme actuel c'est que tes noeuds de cluster de calcul sont aussi des clusters de stockage.
si tu dissocies les 2, tes acces aux données ne sont plus conditionnés par la dispo des CPU de calcul,
de plus tu peux pousser la separation en ayant un systeme permettant de stocker :
- les données courantes sur un systeme avec des SSD (tu diminues fortement l'engorgement sur les I/O)
- les données d'archives sur un systeme "dormant" à base de disque dur,
bref le GRID de calcul, c'est une bonne idée, mais à mon avis il ne faut pas faire le GRID de stockage avec les memes machines.
[^] # Re: Type d'IO, Conso ?
Posté par laurent wandrebeck (site web personnel) . Évalué à 1.
C’est évident que des systèmes dédiés I/O et processing seraient plus efficaces. Mais je peine fortement à entrevoir un moyen d’avoir ça vu les contraintes budgétaires/conso/place :(
Un système données chaudes et froides serait fantastique, je confirme. Le souci, supposons 40k images à traiter. 40k fichiers résultats. à disons 256mo l’image d’entrée, et autant en sortie, ça fait pas loin de 10to en lecture, autant en écriture. Réparti sur 10 machines, ça fait 1to+1to de données chaudes. ça va évincer à tour de bras, on va lire en froid, mettre en chaud, traiter, écrire en chaud, rapido virer en froid et recommencer. Les disques n’auront pas beaucoup plus de repos.
Avec un beau budget, il serait possible d’avoir une solution élégante, là, hélas…je ne peux faire autre chose que de trouver le meilleur compromis possible (avec vos conseils avisés à tous :)).
# Ansible
Posté par Cascador (site web personnel) . Évalué à 5.
Hello,
Je n'ai pas essayé Salt/Puppet/Chef car la courbe d'apprentissage est rude à ce que j'ai lu et cela nécessite un client. Par contre Ansible a un sens (à mon avis) dès 3 machines. Il ne faut pas se bloquer en se demandant si il y a un intérêt puisque l'installation est ridicule.
J'ai fait des articles (mais moi j'ai du Debian), j'espère qu'ils te serviront à voir la facilité et à te lancer.
Tu commences là et tu continues ici. Il y a 6 articles.
Tcho !
[^] # Re: Ansible
Posté par thamieu . Évalué à 3.
Ansible a un sens dès 1 machine. Combien de fois voit-on les gens faire les trucs à la rache pensant être débarassés, pour après découvrir qu'il devront refaire les mêmes choses sur une nouvelle machine ?
Je plussoie pour Ansible par rapport à Puppet (je ne connais pas les autres). Ansible en lui-même est très simple à prendre en main, le plus dur c'est de trouver une organisation qui reflète tes besoins : l'internet fourni des myriades d'exemples de gestion de configuration, mais si tu veux faire du déploiement d'applications d'un coup c'est plus rare.
[^] # Re: Ansible
Posté par barmic . Évalué à 4.
Personnellement je trouve fabric plus simple à prendre en main qu'ansible (mais c'est probablement parce que je suis plus développeur qu'administrateur). En fait avec ansible mais lors de mes quelques essais j'avais un long temps d'attente sans savoir ce qui se passait (pour faire des choses assez triviale), donc je suis assez vite retourné sur fabric.
Par contre je pense (pas certain) que ça a du sens surtout en environnement homogène. Le DSL n'étant pas vraiment une abstraction des OS sous-jacent.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Ansible
Posté par laurent wandrebeck (site web personnel) . Évalué à 1.
J’ai regardé (rapidement) les articles Ansible…il est vrai que ça a l’air simple et rapide à déployer.
Je regarde Fabric, dont je n’avais jamais entendu parler. Merci à vous trois. :)
# NUC pour le calcul, plus noeuds de stockage
Posté par NeoX . Évalué à 3.
comme dit plus haut, revoit ton archi,
là tu as 7 noeuds identiques gavé de CPU/RAM/HDD
tu pourrais faire une vrai architecture N-tiers
avec des noeuds de calculs (des NUC pour etre petits, peu consommateurs)
deux noeuds de stockages type NAS pour pouvoir acceder aux données depuis les noeuds du cluster ou depuis les postes utilisateurs.
typiquement avec un NAS residentiel actuel, j'ai 110Mo/s de debit vers mon stockage.
l'an dernier au boulot on a eu une baie EMC cluster (2cartes meres, 2 alims, 12 emplacements disques, 24To NL-SAS) à 8K€
il te resterait alors 12K€ pour tes noeuds de calculs, ca fait un paquet de NUC
[^] # Re: NUC pour le calcul, plus noeuds de stockage
Posté par laurent wandrebeck (site web personnel) . Évalué à 1.
Idée intéressante. ranger des nuc dans une baie n’est pas idéal, mais c’est presque anecdotique.
Donc, un nuc = 65 watts, 2 cœurs i5. 4 à 8 go/cœur, 1 seul NIC (dommage vu qu’on a des switchs stackés). Une seule alim, on ne peut pas profiter de la double arrivée électrique du DC. Coupure de test tout les 6 mois une ligne après l’autre = faut éteindre tout le biniou. Encore qu’il existe des multiprises qu’on peut brancher sur plusieurs arrivées, je crois.
48 cœurs, 24 nucs, soit 1560W, sans les baies. coût, 330+40 de ssd+90 pour 8go de ram = 460 TTC, soit 9000€ HT à la louche. Un syno 12 disques et son extension (~3.5k€), on bouffe dans les 400W. Le tout pour 2kW, et 12.5k€.
J’avoue que je n’avais pas du tout pensé à ce type de configuration, et elle a ses bons côtés. Par contre, j’ai plus que la conso du micro-cloud (potentiellement sans alim redondante), et pas de LB/HA côté réseau, ce qui peut logiquement brider les perfs.
Après avoir mouliné en dormant (sisi), un microcloud avec chaque serveur en raid 0 (pour augmenter la patate en I/O, et de toutes façons, les serveurs sont hotswap, pas les disques…), 96 cœurs.
Plus de cœurs (le double), conso un petit 20% inférieur, alim redondante, LB/HA réseau. Mais prix plus élevé (40%).
Je suis embêté pour la dispo des données, aussi. raid 5, hors de question. raid 6, en mettant le disque 6to à 5.4 formaté, on a 2×54to utiles (deux volumes raid 6, et le bon vieux retour du « damned, mon run s’est planté en cours de route parce que j’ai rempli le volume x alors qu’il reste de la place sur y ».
Avec une soluce type RozoFS, je n’ai que 87to utiles, mais avec bien davantage de sécu pour les données (équivalent de 3 réplicas), ce qui fait qu’on ne craint pas qu’une bécane se gaufre, et qu’on ne voit qu’un volume.
Je ne jette pas ton idée aux orties, loin de là. Je suis par contre indécis. Pour une fois, le budget est dispo, et la dispo apportée par le microcloud est intéressante (et carrément bienvenue). Le cluster peut être occupé pendant 2 ou 3 semaines d’affilée, et on aime beaucoup ne pas être interrompus pour le moindre souci hard ;)
Du coup, maintenant, j’hésite entre micro-cloud et nuc+nas :) merci pour tes lumières !
[^] # Re: NUC pour le calcul, plus noeuds de stockage
Posté par NeoX . Évalué à 3. Dernière modification le 26 octobre 2014 à 13:30.
coupure electrique ou reseau, suffit de repartir tes equipements.
8 NUC => 4 par lignes electriques
parmi ces 4, 2 sur un switch, 2 sur l'autre
j'imagine que tes switch eux sont redondés.
en cas de coupure electrique sur une ligne, tu fonctionnes en mode degradé, mais tu fonctionnes quand meme.
en plus avec du boot PXE, on peut imaginer que les NUC soit sans stockage, boot sur le reseau au demarrage.
Sinon je ne comprends pas, tu veux 87To dans ton "cluster" mais tes images font 40Mo à 500Mo voire plus.
donc tu peux clairement "sortir" les 87To du cluster de calcul, et les mettre dans un cluster de stockage.
ca ne reduit pas forcement le prix, mais si un noeud de calcul tombe, ca n'impacte pas la performance ni la capacité de stockage.
[^] # Re: NUC pour le calcul, plus noeuds de stockage
Posté par laurent wandrebeck (site web personnel) . Évalué à 1.
Effectivement, le mode dégradé est une possibilité, le PXE aussi, bien sûr. Je me tâte toujours ;)
Exact pour les images. On stocke les données de plusieurs sats, parfois sur plusieurs années, parfois aussi à l’échelle du globe. À force, ça chiffre. Pour simplifier, on a les résultats qui font une taille équivalente aux données d’entrées. Et on garde plusieurs séries de résultats, pour faire des comparaisons en fonction des divers paramètres, des versions d’algo…alors forcément au bout d’un moment on dégage les résultats qui ne sont plus pertinents, mais il faut de la place pour les stocker en attendant.
Les scientifiques (en tout cas ceux là) mangent du To au p’tit déj ;)
Tu parles de cluster de stockage…je n’ai rien contre l’idée, mais cluster de stockage + cluster de calcul = ça utilise des U et ça consomme, soit le contraire de ce que je cherche (et qui m’est imposé), non ? Ou j’ai raté une marche ?
24 nucs à 1500W, comment je fais rentrer 87To utiles dans moins de 500W (et si possible 120W si on veut comparer à conso égale, bien que l’autre solution soit pourvue de davantage de cœurs) ?
Merci pour tes lumières :)
[^] # Re: NUC pour le calcul, plus noeuds de stockage
Posté par NeoX . Évalué à 2.
il faut se poser les bonnes questions et peut-etre commencer par faire de vrai mesure de consommation,
car pour le stockage, on trouve par exemple :
4U pour 144To et 250W de consommation
en prenant :
https://www.synology.com/en-global/products/RS2414+
(125W)
+ le chassis d'extension
https://www.synology.com/en-global/products/RX1214#spec
(121W)
donc en gardant ton cluster de calcul, et en transferant les data sur un vrai systeme de stockage
tu dois deja pouvoir economiser quelques W
[^] # Re: NUC pour le calcul, plus noeuds de stockage
Posté par NeoX . Évalué à 2.
dans le meme ordre d'idée (je viens de relire ta config actuelle)
6 noeuds, 12 à 24 disques => 72 à 144 disques pour gerer ton stockage de 140To soit environ 2T par disque.
alors qu'on fait maintenant des NAS/SAN dans lesquels tu peux mettre des disques de 3 à 6To
tu divises alors le nombre de disque necessaire pour la meme quantité de stockage => donc tu divises le nombre de machine pour gerer ce meme stockage => tu reduis la conso.
[^] # Re: NUC pour le calcul, plus noeuds de stockage
Posté par laurent wandrebeck (site web personnel) . Évalué à 1.
5 nœuds à 12 disques, 1 à 24 pour être précis.
Moins de bécanes, moins de cœurs. Déjà qu’ils trouvent que ça va pas assez vite… et toujours le problème coût/dispo des données avec le nas.
(c’te vieille impression de serpent qui se mord la queue…).
[^] # Re: NUC pour le calcul, plus noeuds de stockage
Posté par laurent wandrebeck (site web personnel) . Évalué à 1.
Pour les vraies mesures de conso, y’a pas. c’est le chiffre écrit sur l’alim (sans commentaire). Je pourrais peut-être jouer de la conso pic indiquée dans la doc officielle, à voir.
Ce qui m’inquiète c’est la dispo des données. La cm/le cpu/la ram crame, on est dans la mouise.
Faudrait donc utiliser du sha comme ils appellent ça (c’est en prod depuis peu chez nous avec du rs814 pour servir les home utilisateurs), et donc avoir deux rs et deux rx. 7k€, plus les disques, un petit 10k. paf, 17k€ et 500W (en conso pic, si c’est alim 1600 /o\ )
Raid 6 sur un tel volume…je le sens moyen. Un disque claque (et ça finira invariablement par arriver), ça va patauger pendant des jours et faudra croiser tout ce qu’on peut pour que rien d’autre ne lache dans la foulée. JBOD et autres raid on oublie, amha.
On ajoute les NUC, on monte à un soupcon plus de 2kW, sans compter que le budget s’envole (+8k sans stockage local), on arrive à 25k.
N’avoir qu’un rs et un rx diminuerait fortement le budget, mais donne un SPOF qui risque de m’empêcher de dormir. la bécane claque, plus d’accès aux données pendant plusieurs jours le temps de recevoir le remplaçant = chomage technique. Le volume claque, c’est certainement la mort de la boite.
J’aime bien l’idée, les perfs seraient sans doute bonnes, mais soit c’est cher, soit c’est attendre que la cata arrive…et on a pas les moyens de changer de matos dès qu’il n’est plus sous garantie (qui plus est avec de tels volumes, ça ne se fait pas en 5 minutes).
Je sais que je vais devoir faire des compromis vu les contraintes, mais la dispo est importante sinon vitale, quitte a sacrifier (un peu) les perfs.
[^] # Re: NUC pour le calcul, plus noeuds de stockage
Posté par NeoX . Évalué à 2.
24h si t'es en france est que le produit est en stock
garantie J+1 sur certains produits
[^] # Re: NUC pour le calcul, plus noeuds de stockage
Posté par laurent wandrebeck (site web personnel) . Évalué à 1.
Soit, même en j+1, j’ai 5 personnes qui vont me regarder avec des gros yeux, sortir les battes…sans oublier les « mais je suis à la bourre je dois livrer demain matin, mon run était presque fini. J’ai absolument besoin des données, faut encore que je sorte les graphs ! » ;)
J’ai enfin réussi à obtenir un cœur de réseau (ça va faire rire les admins de gros parc mais je fais ce que je peux ) HA (pas cher, deux d-link dgs-1510-52), un serveur de home HA (pas cher non plus, 2 syno rs-814), le cluster et le volume sont eux aussi importants. sigh.
[^] # Re: NUC pour le calcul, plus noeuds de stockage
Posté par KiKouN . Évalué à 3.
Si un jour ( temps de livraison ), c'est critique pour la boite, alors il en faut au moins un en spare.
[^] # Re: NUC pour le calcul, plus noeuds de stockage
Posté par jolitorax . Évalué à 2.
Si tu as du Dell la commande ipmitool te permet de connaître la consommation électrique (ici un Dell PowerEdge R710).
D'autres marques proposent sans doute ce genre d'information via les ipmitool
[^] # Re: NUC pour le calcul, plus noeuds de stockage
Posté par jolitorax . Évalué à 1.
Gandalf m'a tuer… Trop tard pour finir d'éditer !
Donc, sur un gros Dell PowerEdge R620 qui fait du calcul, j'ai une valeur max de 300 W pour la dernière semaine. En ce moment il est mollement utilisé et tourne entre 145 et 165 W
[^] # Re: NUC pour le calcul, plus noeuds de stockage
Posté par laurent wandrebeck (site web personnel) . Évalué à 1.
J’ai du supermicro, mais je vais regarder si c’est possible. merci pour l’info :)
[^] # Re: NUC pour le calcul, plus noeuds de stockage
Posté par Frank-N-Furter . Évalué à 2.
J’ai eu un client qui avait du matos de chez Supermicro, et tu pouvais obtenir des informations sur la consommation électrique. Par contre c’était de l’Intel.
Depending on the time of day, the French go either way.
[^] # Re: NUC pour le calcul, plus noeuds de stockage
Posté par X345 . Évalué à 6.
Sérieusement des NUCs pour faire du calcul…
Déjà, je sais pas ce que c'est que cette manie de mesurer la puissance de calcul en nombre de cœurs et de considérer que tout est équivalent. C'est sûrement valable quand on fait de l'hébergement web avec un CPU utilisé à 10% tout le temps, mais dès que le code est un peu calculatoire, il va y avoir des différences énormes entre un cœur de Core i5-4250U, un cœur de Xeon E5-2690v3 et un cœur d'Opteron 3380.
Typiquement un Opteron 3380 8 Cœurs (2.6-3.6 Ghz) est moins puissant qu'un tout petit Intel Xeon E3-1225v3 4 Cœurs (3.1Ghz - 3.5Ghz). Et quelle idée de venir comparer un core de Core i5-4250U 2C (1.3-2.6Ghz) a tout ça.
T'as l'air d'avoir de gros besoins en stockage (140 To, erf), et assez peut en CPU, mais quand même.
Aussi du matériel grand public (des NUCs) n'est pas prévu pour tourner 24h/24h dans un datacenter, tu vas avoir un taux de panne super élevé.
[^] # Re: NUC pour le calcul, plus noeuds de stockage
Posté par NeoX . Évalué à 3.
en meme temps il n'a qu'un budget de 20K€ pour faire du "big data"
[^] # Re: NUC pour le calcul, plus noeuds de stockage
Posté par X345 . Évalué à 2.
La solution la plus simple et économique est peut-être quelque chose comme 3 serveurs à 7000€. Deux serveurs pour le calcul et les données "chaudes" en cours de traitement, avec beaucoup de RAM et de CPU et ~20To de stockage local chacun. On ajoute un troisième serveur avec peu de RAM et de CPU (Un quad core, et 32G) supportant des disques 3.5" pour le stockage froid (données pas en cours de traitement). Ou trois serveurs identiques.
Mais effectivement, ça fait un budget très serré.
[^] # Re: NUC pour le calcul, plus noeuds de stockage
Posté par X345 . Évalué à 1.
Par exemple,
Actualis Power Store R3HTP4XFB-16 (7100€ HT)
2 Xeon E5-2650v2 (16 cœurs)
6x 16GB RAM (96GB RAM)
12 Western Digital SE 4TB (48TB)
T'en achètes 3 comme ça, ça te fait 21300€ HT (sans les cartes réseau) :
48 Cœurs Xeon Ivy Bridge 2.6Ghz
288 GB RAM (6Go/cœur)
144To Stockage
Si tu montes à 8000€ par nœud, tu peux avoir :
Actualis Power Store R3HTP4XFB-16 (8300€ HT)
2 Xeon E5-2670v2 (20 cœurs)
8x 16GB RAM (128GB RAM)
12 Western Digital SE 4TB (48TB)
Ce qui fait au total (25000€ HT)
60 Cœurs Xeon Ivy Bridge 2.5Ghz
384 GB RAM (6.4 Go/cœur)
144To Stockage
C'est surement les configurations le plus raisonnables.
[^] # Re: NUC pour le calcul, plus noeuds de stockage
Posté par laurent wandrebeck (site web personnel) . Évalué à 1.
Alim 800W, ×3 = 2400. Dommage. On doit viser le 2000 peu ou prou avec ce qui est déjà en place (~800W). je pourrais gagner 300W là-dessus environ, mais je m’attaque au plus gros (et donc plus urgent) d’abord.
Avec un microcloud, je serais à ~2400. Avec ta propale, 3200. Trop gros passera pas comme dirait l’autre.
[^] # Re: NUC pour le calcul, plus noeuds de stockage
Posté par X345 . Évalué à 2.
Après avoir comparer les CPUs par cœur, on va comparer les puissances en utilisant la puissance maximale des alimentations…
Déjà si on compare les TDP des composants, c'est un peu plus réaliste.
Ce qui va consommer dans ton infra, c'est la tripotée de disques et les processeurs. En mettant que tu mets les mêmes disques dans le microcloud et les 3 serveurs classiques, le principal élément discriminant seront les processeurs :
12 Opterons 3380 : 12 * 65W = 780W
6 Xeons E5-2670v2 : 6 * 95W = 570W (-25%)
Les cartes mères Bi-Xeon vont certes consommer plus que les petites cartes mères Opteron, mais 3 cartes mères, ça va forcément moins consommer que 12 (!).
Trois blocs d'alims de 800W, ça consommera plus que 1 bloc de 1600W, mais bon dans une infra un peu critique, je préfère avoir 6 alims que 2, vu que ça a quand même tendance a pas mal lacher…
Honnêtement pour faire efficace énergétiquement, multiplier les machines et les cœurs, c'est rarement la bonne solution.
[^] # Re: NUC pour le calcul, plus noeuds de stockage
Posté par laurent wandrebeck (site web personnel) . Évalué à 1.
Comme je le disais, hélas, comme il n’y a pas de mesure précise de conso, la référence est pour notre « hébergeur » le nombre de watts indiqués sur l’alim. Je pourrais peut-être et ce n’est pas gagné réussir à leur faire prendre en compte la conso pic indiquée dans la doc, mais dans le doute…
Après pour les alims, ça claque je confirme, mais j’ai dû avoir du bol, celles qui m’ont lâché en 10 ans se comptent sur les doigts d’une main.
Une conso réelle tendrait à me faire pencher vers 3 bécanes. Une conso « alim » pour le microcloud. Je sais, ça manque de logique, mais on ne peut pas non plus se tourner vers du hosting. du coup…
[^] # Re: NUC pour le calcul, plus noeuds de stockage
Posté par X345 . Évalué à 1.
Pardon, je ne n'avais plus ça en mémoire, mea culpa. Dans ce cas, tu fais effectivement bien de te tourner vers les solutions avec alim mutualisée, ce sera souvent ça qui affichera les plus bas chiffres.
Oui, tu as raison, ça tient quand même. Après je comparais les alims aux CPUs/barettes de RAM, t'as du voir plus d'alim lacher que de CPU ou barrettes de RAM :)
Pour les disques, t'es déjà au courant que tu vas les changer de temps à autre :)
[^] # Re: NUC pour le calcul, plus noeuds de stockage
Posté par NeoX . Évalué à 2.
si tu as un hebergeur qui limite, il doit etre en mesure de te dire combien tu consommes.
demandes lui les chiffres.
ensuite quand tu fais ta coupure du semestre, regarde le graffe machines eteintes, puis allumes tes machines une par une et regarde de combien ca remonte à chaque allumage.
[^] # Re: NUC pour le calcul, plus noeuds de stockage
Posté par laurent wandrebeck (site web personnel) . Évalué à 1.
J’avais raté celui-çi, mea culpa.
Non, l’hébergeur n’a pas cette capacité. Ce n’est pas son cœur de métier, ce sont des « salles numériques » et pas un datacenter, d’où justement ce « mode de calcul » (erm) à la noix. Du coup, avec leur obligation d’égalité de traitement des diverses boîtes, si on leur amène de la conso réelle à coup de watt-mètre ou de doc, on fort probablement va se faire jeter (puisqu’il n’y a pas de raison que nous soyons traités différemment bla bla).
[^] # Re: NUC pour le calcul, plus noeuds de stockage
Posté par NeoX . Évalué à 2.
faut relire le contrat,
il te vend, dans tes charges, une arrivée électrique fournissant 2KW
si tu consommes 1KW (au wattmetre)
tu dois pouvoir mettre encore 1KW
toute autre methode de calcul est de la "charlatanerie" et tu paies pour un service qui n'est pas rendu puisque tu paies pour 2KW mais tu n'as pas le droit de consommé plus de 1KW reels,
un avocat pourra faire gagner ta boite sur le sujet.
[^] # Re: NUC pour le calcul, plus noeuds de stockage
Posté par laurent wandrebeck (site web personnel) . Évalué à 1.
J’ai jeté un œil rapide. C’est 2kW en « puissance max théorique » tel que c’est écrit.
Quant à avoir potentiellement recours à un avocat, je pense que le gérant va mettre son véto, on a jamais eu recours à un avocat en presque 15 ans d’existence, et in fine hormis pourrir les relations, ça arrangera pas grand-chose, amha.
[^] # Re: NUC pour le calcul, plus noeuds de stockage
Posté par laurent wandrebeck (site web personnel) . Évalué à 1.
Je sais bien que les cpu ne sont pas équivalents. le microcloud existe aussi en xeon e3. La multiplication des cœurs (dans le cas des opteron) pourrait être un avantage pour la gestion des données. Je serais aux anges de pouvoir bencher tout ça avant de pouvoir prendre une décision mais je ne peux point.
Avec nos 46 cœurs (opteron ancienne gén) actuels, on a ~40 process concurrents (on indique toujours à HTCondor de ne pas lancer de process sur un cœur dont la charge est supérieure à 0.7 ou 0.8), soit un cœur peu ou prou monopolisé par nœud pour la gestion de l’I/O. Alors vaut-il 48 cœurs xeon en 12 bécanes ou 96 cœurs opteron certes moins rapides ?
En supposant toujours un ½ voire 1 cœur de pris (fantaisie, vu qu’intestable), ça voudrait dire 36 à 42 jobs concurrents pour l’un, 84 à 90 pour le second. les disques suivront-ils ? le fait que le processing soit plus long sur opteron pourrait compenser…Franchement je ne sais que penser.
[^] # Re: NUC pour le calcul, plus noeuds de stockage
Posté par X345 . Évalué à 0.
Je pense qu'au niveau puissance brute de calcul, ça revient à peu près au même.
Si on jette un œil au benchmarks synthétiques (qui sont très imparfaits hein…, mais c'est mieux que rien du tout):
Xeon E5-2620v2 6C 2.1Ghz : 8664 pts Passmark (1444 pts par cœur)
Opteron 3380 8C 2.6Ghz : 6565 pts Passmark (802 pts par cœur)
Sur des benchmark plus pratiques, l'Opteron 3380 n'obtient pas de très bon résultats malgré ses 8 cœurs : http://www.servethehome.com/Server-detail/amd-opteron-3380-review-benchmarks-review/
Le voir faire à peine mieux qu'un Xeon X3440, un quad-core de 2009…
Mais typiquement AMD n'est pas très bon en performance/cœur ni même performance/watt. Sur certaines configurations, il sont meilleurs si on regarde le rapport performance/prix mais c'est à vérifier.
Je me répète mais si tu veux limiter la consommation électrique, limiter le nombre de cœur c'est bien.
# Code à effacement, codes systématiques et puissance de calcul
Posté par X345 . Évalué à 1.
Une remarque également sur les codes à effacement, qui tu sembles vouloir utiliser pour réduire la quantité d'espace de ton cluster dédiée à la tolérance aux pannes.
Certains codes (Reed-solomon notamment) sont dit systématiques, ce qui signifie qu'un fichier encodé en Reed-solomon peut être lu directement, sans décodage. Un décodage est seulement nécessaire lorsqu'il faut réparer (ie, récupérer) le fichier suite à la panne d'un disque.
D'autres codes (notamment la transformée mojette utilisée par RozoFS) sont non-systématiques, ce qui signifie qu'un fichier encodé en RozoFS doit être décodé avant de pouvoir être utilisé. Un décodage est également nécessaire pour réparer le fichier suite à la panne d'un disque. Le décodage consomme du temps CPU (de la puissance de calcul), ce qui peut être un problème (ou non, en fonction de ta worload).
Des quelques démo que j'ai vu, RozoFS a de bonnes performances voir très bonnes, c'est à dire que le décodage consomme peu de puissance CPU, mais peut-être qu'un code systématique serait mieux dans ton cas. Je sais pas exactement ou ça en est, mais les codes à effacement dont Reed-solomon (qui est systématique) sont en cours d'implémentation dans Ceph ( http://ceph.com/docs/giant/dev/erasure-coded-pool/ http://ceph.com/releases/v0-80-firefly-released/ ).
Je te conseille de :
1. Vérifier que RozoFS ne mange pas trop de CPU, et fournit une bande passante suffisante. Si c'est le cas, aucun problème, tu devrais pouvoir l'utiliser. Il me semble que c'est un produit assez mature.
2. Sinon, regarde du coté de Ceph avec un Erasure Coded Backend (Reed-Solomon). La bande passante et la consommation CPU seront excellentes, par contre c'est peut-être un peu plus bêta/un peu moins mature.
[^] # Re: Code à effacement, codes systématiques et puissance de calcul
Posté par laurent wandrebeck (site web personnel) . Évalué à 2.
Je ne connaissais pas cette distinction (non-)systématique, merci pour l’éclairage.
Pour le côté mature, il est (très) important. Tout comme je veux éviter que le matos puisse nous péter au nez autant que possible, il en est de même pour le soft. Perdre physiquement ou logiciellement le volume serait une cata.
Je suis persuadé qu’à terme Ceph sera du bonheur en barre vu le monde qu’il y’a derrière. Mais j’ai peur qu’il ne soit pas d’une stabilité suffisante pour le moment (7 releases de la 0.80 en 5 mois avec du important et du critical fixes…). Peut-être (sans doute ?) ai-je tort. Je m’étais renseigné il y’a une paire d’années sur la bête, et sa mise en place était assez complexe. Sais-tu si cela s’est amélioré ? Je n’ai hélas guère de temps à consacrer au déploiement.
RozoFS semble beaucoup plus simple à ce niveau, mais plus léger niveau features. Nous, tant que les données sont en sécurité, que ça plante pas et que ça fait correctement son taff, tant pis si on n’a pas obtenu 10% de perfs en plus parce que çi ou ça. On fera avec. Je doute de pouvoir faire trop la fine bouche ;)
[^] # Re: Code à effacement, codes systématiques et puissance de calcul
Posté par X345 . Évalué à 1.
En fait, la question à se poser c'est est-ce que c'est une perte de 10% ou de 50% (bien pour ça qu'il faut bencher).
Regarde la charge CPU qu'il te faut pour lire à 100MB/s sur un disque, tu seras vite fixé.
[^] # Re: Code à effacement, codes systématiques et puissance de calcul
Posté par laurent wandrebeck (site web personnel) . Évalué à 1.
Va falloir que je bidouille un truc avec ma bécane du taff alors (cpu bulldozer), j’ai pas de 3380, les autres opteron sont en prod et pas de cette gén là. C’est ce que j’ai de plus proche. J’dois pouvoir trouver (et brancher) deux ou trois disques dessus pour tester. Pas mieux. Je vous tiendrais au courant, mais ce ne sera pas pour demain, j’ai du monde sur ma todo list et de la deadline qui pointe son nez.
# Et la grille de calcul européenne ?
Posté par seraf1 . Évalué à 1.
Une question toute simple, pourquoi ne pas utiliser la grille de calcul européenne qui est faite pour ça (voir avec France-Grille) ?
[^] # Re: Et la grille de calcul européenne ?
Posté par laurent wandrebeck (site web personnel) . Évalué à 1.
Nous sommes 100% privés. Même si en liens avec des labos et autres instituts, nous ne faisons pas partie des partenaires du GIS.
En plus, même si nous disposons qu’une connex pas trop dégueu (100mbps symétriques), je pense pas qu’on arrive à envoyer les données à traiter assez vite pour gagner du temps de traitement…
Mais l’idée est bonne :)
# datacenter ?
Posté par KiKouN . Évalué à 2.
Les contraintes semblent venir du datacenter. Pourquoi ne pas aller voir ailleurs ? Il y a t'il des besoins particuliers a être en datacenter ?
7x900W c'est pratique pour se chauffer en hiver où chauffer le garage d'à côté. L'autohébergement peut être une solution. Et tu payerai l'électricité réellement consommée.
[^] # Re: datacenter ?
Posté par laurent wandrebeck (site web personnel) . Évalué à 1.
Aller voir ailleurs c’est 1500€/mois la ½ baie. Impossible pour notre petite structure de supporter un tel coût. À 2000W de conso, l’hébergement est dans les charges. Au-delà, tu casques.
Le fait que les bécanes soient dans une salle climatisée, avec double arrivée électrique, le tout sur une connex 100mbps et à proximité de notre bureau est un plus quand tu dois, au hasard, changer un disque, ou aller voir sur place pourquoi ton serveur supermicro sans kvm ni rien ne répond plus. Sans compter qu’on a besoin de dispo. Ça fait toujours ch… quand t’as 3 semaines H24 de calculs en cours, et que le jus tombe. Déjà rien que le temps des checks disques, sans parler des merdouilles, plus reprendre la prod, tu pleures.
[^] # Re: datacenter ?
Posté par NeoX . Évalué à 2.
je penses que ce qu'il proposait c'etait eventuellement la location de serveur en datacenter.
il y a maintenant des hebergeurs qui font des reseaux privés en interne à leur datacenter, ils gerents les machiens, la clim, la redondance, etc
tu ne fais plus que payer un loyer pour les machines.
ton budget de 20K€ c'est en investissement amorti sur 5 ans ou en frais de fonctionnement par années ?
[^] # Re: datacenter ?
Posté par KiKouN . Évalué à 2.
Non, je voulais savoir s'il était pertinent d'héberger en datacenter. Mais là, avec 3 semaines pour un calcul, c'est une raison suffisante pour moi.
[^] # Re: datacenter ?
Posté par laurent wandrebeck (site web personnel) . Évalué à 1.
Louer du serveur, c’est 400HT/mois les 72 to bruts, donc il en faut 2. 800€. Et je n’ai « que » 12 cœurs. + 2 binious à 16 cœurs, hop, on est à pas loin de 1200€/mois.
En cloud, c’est 5k€ à la louche.
un petit HPC dédié, beaucoup trop cher aussi.
Un machin type EC2, on va perdre un temps fou pour y faire monter les données, et je ne suis pas sûr que nos clients acceptent que leurs données ne soient pas traitées en interne. Bref, je n’ai pas regardé plus loin.
On amorti sur 3 ans il me semble. Ce qui fait ~0.5k/mois avec un minicloud à 20k. « Notre » datacenter a beau avoir des limitations, on a ces 2kW compris dans les charges. Ne pas les utiliser est jeter de l’argent par la fenêtre.
[^] # Re: datacenter ?
Posté par NeoX . Évalué à 2.
parce que là encore tu confonds stockage et calcul.
800euros de stockage par mois => 9600/ans (mais la location de la baie est incluse dans le prix, alors que dans ton projet c'est inclus dans les charges des locaux mais inutilisable car limité)
ensuite tu prends des noeuds de calcul purs
1200euros le maitre + 2 slaves puis 400euros le noeud supplementaire
sachant que 1 noeud c'est deja 16Cores/32Thread et 64Go de ram
donc deja avec le cluster de base, tu as 32 coeurs, 128Go de ram (en considerant que le calcul ne se fait pas sur le maitre)
à l'année le cluster de calcul coute 14.400euros, plus 9600euros pour le stockage sur reseau 10Gbps, ondulé, climatisé, etc
soit un cluster à 24.400euros location du datacenter incluse
si tu as été voir le meme fournisseur que moi tu peux aussi leur demander un devis pour construire la machine mais l'installer chez toi
et les charges, ca evolue, tu dois pouvoir obtenir plus de courant pour tes besoins.
à l'inverse si tu ne consommes plus car ton cluster est ailleurs, ca ne doit plus apparaitre dans les charges => c'est du budget en plus pour le cluster.
[^] # Re: datacenter ?
Posté par laurent wandrebeck (site web personnel) . Évalué à 1.
t’es à 24k/an. ici…c’est 20k sur 3 ans mini ! (+ les pièces de rechange, ok)
Quant à cette histoire de récupérer les charges pour les 2kW, faudrait que je regarde le bail, mais je crois que c’est compris, la conso est mutualisée non seulement au datacenter mais aussi au niveau du bâtiment, donc je pense que c’est même pas la peine d’essayer.
Je peux obtenir plus de courant (je l’ai déjà), ce n’est pas (vraiment) le souci, mais la grille tarifaire est prohibitive.
L’hébergement n’est pas le cœur de métier de la boite gérant le bâtiment dans lequel on bosse. C’est un service « offert ». Ils ont obligation de fournir 2kW pour chaque boîte, et à l’heure actuelle, les clims ne peuvent plus évacuer plus de chaleur, donc ils poussent tout le monde à réduire sa conso (nombre consomme plus que 2kW) pour arriver dans les clous afin de pouvoir accueillir avec le même niveau de service les nouveaux arrivants. Bref…
# NAS + 2 serveurs 1U interconnectés en 10 GbE
Posté par koopa . Évalué à 1.
Je te propose une configuration conforme aux spécifications (6U, < 2kWatt, < 20 kEUR) dans laquelle tu sépares le stockage et le calcul:
- 1 NAS avec carte 10GbE
- 2 serveurs 2-sockets 1U avec carte 10 GbE
Tu connectes les serveurs en point à point 10GbE sur le NAS, comme ça tu n'as pas besoin de switches, ni de FS réparti car tout est centralisé sur le NAS.
L'architecture est extensible:
- stockage: via des baies d'extensions SAS pour ton NAS
- calcul: tu peux acheter un switch 10GbE pour brancher davantage de serveur de calculs
Pour le budget, il faut environ 10kEUR pour le NAS (100TB) et 5kEUR par serveur de calcul.
Pour le NAS je te recommande QNAP, mais ça marchera aussi avec un autre NAS professionnel sous Linux.
Réferences:
http://www.bechtle.fr/shop/BD_FR-fr/Switch+Smart+NETGEAR+XS712T+10-Gigabit_800753
http://www.ldlc.com/fiche/PB00170943.html
[^] # Re: NAS + 2 serveurs 1U interconnectés en 10 GbE
Posté par laurent wandrebeck (site web personnel) . Évalué à 1.
Voilà qui est tentant !
Un système disque qui arrache pas mal (même si les 6to intellipower ne sont pas les plus rapides…), raid 6 j’imagine ? 75to utiles une fois formaté à la louche (c’est tout de même très loin de 100). un peu light, mais à priori supportable. Par contre, j’ai peur de la proba d’explosion en vol du volume en cours de rebuild, situation qui se présentera forcément. Perso, le raid, j’ai arrêté (sauf le 1 pour l’os) quand j’ai paumé un (gros, à l’époque) volume raid 6. Puis quand ça rebuild ça patauge sévère pendant des jours, sans parler de blocs défectueux pouvant facilement causer le souk…Quelqu’un a de l’expérience avec de tels volumes en raid ? Je ne suis pas confiant, pour ma part.
Perdre partiellement des données est certes pénible, mais bien moins que de paumer le volume complet qu’on a pas les moyens de sauvegarder (dans cette configuration là, ni dans les précédentes que nous avons connu, en tout cas).
9k€ pour le nas en 10g avec des disques pas cher.
J’arrive à 12k pour 48 cœurs, du 10g pour deux serveurs, 1400W alim.
Le nas étant à 650W, on est à 2050, plus les 800 (bientôt 500) existants, sigh. (je rappelle que le « coût » conso est compté via ce qui est écrit sur les alims, et pas la conso réelle).
Dommage, c’était prometteur (bien que potentiellement (relativement) un peu léger niveau HA).
Merci pour la proposition en tout cas !
[^] # Re: NAS + 2 serveurs 1U interconnectés en 10 GbE
Posté par KiKouN . Évalué à 2.
On ne fait que rarement des raids aussi gros. En général, c'est des petits raid 5 ou 6 de 4 à 8 disques que l'on regroupe après ( JBOD sur 3 grappes, raid 1 sur 2 autres, etc… selon usage ). Si un grappe pête complètement, c'est moins lourd à restaurer. Si un disque pête, il n'y a que la grappe qui est plus lente.
Sinon, en général, une bécane est vendu avec une alim permettant un grand nombre de configuration. Autant de puissance dispo n'est pas forcément nécessaire. Mettre simplement une alim moins grosse et plus adapté à la configuration est aussi un axe de recherche.
[^] # Re: NAS + 2 serveurs 1U interconnectés en 10 GbE
Posté par jolitorax . Évalué à 1.
Les serveurs de calcul modernes consomment vraiment peu même en mode gros calculs. Je surveille sur les nœuds que nous avons et ils dépassent rarement les 300 W. Ils sont équipés de deux alimentations redondantes de 750W, mais on aurait très bien pu choisir des 495 W également disponibles pour ces modèles, vu qu'ils sont très peu équipés en périphériques.
En fait sur les étiquettes tu vas avoir marqué 2x750 ou 2x495W tandis qu'en réalité tu ne consommera que 300W. Se baser sur les étiquettes te mange un facteur 3 de puissance à la louche. L'un des gains qu'il est possible de négocier avec ton hébergeur, est de fournir la puissance réelle maxi consommée de tes équipements, beaucoup de constructeurs les fournissent via des benchmarks.
Avec de la spec technique sous le coude, il doit être possible de convaincre ton hébergeur. Certes, ce n'est plus vraiment de la technique, mais plutôt de la politique.
[^] # Re: NAS + 2 serveurs 1U interconnectés en 10 GbE
Posté par NeoX . Évalué à 2.
hmmm dans ton cluster actuel il me semble que tu disais avoir 140To, donc seulement 70 exploitables….
J'imagine que c'est parce qu'en fait tu as 2x70To ?
donc avec la solution proposée ici, tu as 75To, soit 5To de plus qu'actuellement.
et ca, uniquement pour le stockage,
les serveurs de calcul peuvent avoir, en local, quelques To dispo le temps du calcul.
[^] # Re: NAS + 2 serveurs 1U interconnectés en 10 GbE
Posté par laurent wandrebeck (site web personnel) . Évalué à 1.
C’est exact, 70 à l’heure actuelle (on était montés à 115 utiles un moment, mais la grosse babasse à 36 disques nous a claqué dans les pattes et pas les moyens de la remplacer, ni possible sachant qu’il fallait gagner du watt, donc régime forcé).
Le truc, c’est que c’est l’archi qu’on va garder pendant plusieurs années, donc j’essaie d’avoir un volume utile sympa.
Après discussion avec les collègues, on semble plutôt s’orienter vers un microcloud opteron, chaque bécane avec 2 disques 6to en raid 0, le tout avec un fs distribué type erasure coding. Pour les données froides, on va claquer un syno ds1413 dans le bureau, et faire des volumes spécifiques à des satellites qui servent peu. Comme ça, en cas de besoin, on charge le syno avec les disques qui vont bien, copie (ou non d’ailleurs, à voir sur pied) des données vers le volume « prod », et on lance le processing.
J’me demande si c’est bien utile d’avoir un disk on module 8go pour l’os des machines, ou s’il faut que je planche pour les booter diskless (les disques 6to étant réservés au stockage).
Voilà l’idée en gros. Mais rien n’est fixé dans le marbre.
[^] # Re: NAS + 2 serveurs 1U interconnectés en 10 GbE
Posté par NeoX . Évalué à 2.
je ne comprend toujours pas pourquoi s'obstiner à vouloir 6To de stockage LOCAL
surtout avec ton exprience malheureuse du noeud qui tombe avec 36To de données dedans.
Alors que les données peuvent etre sur un NAS/SAN dédié, mettre les disques dedans.
Doublé le NAS si tu veux de la securité,
et les noeuds deviennent pur calcul
si un noeud lache, les données sont toujours sur le NAS, tu relances le calcul sur le noeud d'à coté.
[^] # Re: NAS + 2 serveurs 1U interconnectés en 10 GbE
Posté par laurent wandrebeck (site web personnel) . Évalué à 1.
Le stockage local comme tu dis faisait partie du FS réparti, que la machine claque n’a pas causé de pertes de données. Le dit fs a certes retréci, il a fallu faire du nettoyage pour que les réplicas puissent se refaire et assurer à nouveau la sécurité des données, mais le point important est que rien n’a disparu, et que le volume était dispo et accessible.
Pour le NAS, en avoir un seul avec une extension (un syno rs et un rx, ou les qnap équivalents) me donne 24 disques de 6to…avec quelque chose comme deux raid 6. soit 20 disques efficaces, donc ~108to utiles. Ce qui est très bien niveau taille, le tout pour 10k€ (avec alim redondantes, 8.3k sinon). et 800W. Une défaillance de cm, de cpu, de disque un peu trop violente, voire d’alim (le plus courant étant les disques, suivi des alims puis des cm de mon expérience), et hop, on est aux fraises et complètement bloqués. Ajouter un second rs+rx ? L’addition monte entre 16.6 et 20k, et 1600W totaux. Et j’ai pas de cpu.
Si j’avais un bon 30k€ et la possibilité d’utiliser 4kW, je chopais deux rs+rx, les disques, deux serveurs pour un total de 48 cœurs, et roule. Mais je n’ai que 20k€ et 2kW. À choisir entre la vitesse et la dispo, je vote dispo. Qui est meilleure je pense avec la solution minicloud. Si un nœud (et même deux) lache, on est toujours up and running.
Alors c’est sûr, on sera pas aussi rapide que la soluce nas+serveur dédié calcul. Mais je ne peux pas avoir l’efficacité max et la dispo max vu nos contraintes. La dispo est définitivement plus importante.
Désolé de dire niet à tout bout de champs, j’adorerais que vous me présentiez une archi qui rentre dans les clous et qui soit plus sexy :)
[^] # Re: NAS + 2 serveurs 1U interconnectés en 10 GbE
Posté par NeoX . Évalué à 2.
tu fais quand meme des tres grosses estimations tant financieres qu'en termes de puissance.
tu as fais un tableau comparatif des diverses solutions ?
Perso en regardant les données constructeurs, je trouve qu'un ensemble RS+RX ne consomme que 246W (disons 300W en prenant une marge)
si tu doubles l'installation => 600W (800W si tu reprends une marge)
on est bien loin des 1600W de ton estimation à la louche.
cf mon projet precedemment cité :
4U pour 144To et 250W de consommation
en prenant :
https://www.synology.com/en-global/products/RS2414+
(125W)*
+ le chassis d'extension
https://www.synology.com/en-global/products/RX1214#spec
(121W)*
precision du constructeur :
donc il mesure bien la consommation de l'appareil en charge.
et je ne penses pas qu'un disque de 6To consomme 2x plus qu'un disque de 3To.
pour les prix, chez un fournisseur francais, on est effectivement dans les prix que tu cites,
puisqu'en prix "public" donc sans negociation on a :
Chassis RS2414RP+ : 1690euros HT
Chassis RX1214RP : 1450euros HT
24 disques 6To : 225x24 = 5400euros HT
=> 8540euros HT pour 250W (disons 300W en prenant de la marge)
si on redonde toute l'installation dans la crainte d'une panne ca fait en effet un budget de 17080euros HT pour 600W
il ne reste plus que 3K pour les noeuds de calcul.
mais là encore, regardes d'autres fournisseurs, demandent des devis,
car entre le prix catalogue et le prix que tu aura reellement, y a parfois un monde.
Ex l'lan dernier en fin d'année on avait touché la baie EMC VNXe (double alim, double carte mere) à 8K€ pour 12disques 2To NL-SAS
netapp faisait aussi sa baie 12 slots à 9Ke
alors que ce sont des produits à plus de 16Ke en prix catalogue.
Bref fait un vrai boulot de DSI :
1) cahier des charges stockage + calcul (en dissociant les deux tu peux surement trouver ton bonheur)
2) faire faire des devis par plusieurs prestas
3) etudier/comparer, faire jouer la concurence.
[^] # Re: NAS + 2 serveurs 1U interconnectés en 10 GbE
Posté par laurent wandrebeck (site web personnel) . Évalué à 1.
Je répète: ce n’est pas la consommation réelle qui est mesurée, c’est le chiffre indiqué sur l’alim qui est pris en compte. Je sais, mais c’est comme ça. je vais tenter de négo la conso pic, sans la moindre assurance que ça passe.
Merci d’avoir cité emc et netapp, je note. en voyant les prix, j’avais directement laissé tomber, je ne pensais pas qu’on pouvait obtenir de telles ristournes (même si tes exemples restent hors budget).
Pour le cahier des charges, c’est facile: le plus de dispo possible le plus de place possible le plus rapide possible par ordre décroissant d’importance, le tout en 2kW et 20k€. Avant, quand le jus n’était pas un souci, on ajoutait quand on pouvait une bécane qui faisait de la puissance de calcul et du stockage en plus dans le cluster. C’était complètement transparent pour eux. HTCondor gérait simplement plus de cœurs, mfs grossissait tout seul comme un grand.
Maintenant, la problématique est bien différente. je dois trouver la prod de ces prochaines années. Et elle sera figée jusqu’à ce qu’on change pour des plus gros disques voire carrément pour la remplacer par un nouveau boitier, avec des cpus plus mieux et plus de ram, le tout pour une conso et un encombrement similaires (même si sur ce dernier point on a un soupçon de marge).
Pour le vrai boulot de DSI, j’essaie. sisi. mais tu ne connais pas la joie des petites structures ou me trompe-je ? :)
[^] # Re: NAS + 2 serveurs 1U interconnectés en 10 GbE
Posté par NeoX . Évalué à 2.
j'ai travaillé dans des petites structures, donc je connais, et c'est pour cela que je te donnes des pistes, consistant principalement à penser cluster de calcul d'un coté, cluster de stockage de l'autre.
et il reste clair que si tu bases tes comparatifs sur les W de l'alim et pas sur les W consommés, tu va jamais t'en sortir.
le moindre PC Corei7 gamer est vendu avec une alim à 1000W
regarde peut-etre à ne changer que le stockage, en enlevant les disques des noeuds de calculs, tu gardes les 48 coeurs avec la RAM,
le stockage part dans un boitier qui consomme moins
regarde aussi pour te faire reprendre le cluster actuel,
si ca se trouve tu vas en avoir pour 5 ou 10K€ de reprise, + 20K€ de budget => 25 à 30K€ pour la nouvelle installation.
[^] # Re: NAS + 2 serveurs 1U interconnectés en 10 GbE
Posté par laurent wandrebeck (site web personnel) . Évalué à 1.
Le compte en W « alim » est une contrainte extérieure, sinon tu penses bien que je me serais basé sur la conso réelle. Il faut que je fasse avec.
Séparer les disques en gardant les bécanes ne change rien du coup, sinon augmenter artificiellement la pseudo-conso.
Pour la reprise, tu connais des boites la pratiquant ? Je vais poser la question à actualis, sait-on jamais.
Merci !
[^] # Re: NAS + 2 serveurs 1U interconnectés en 10 GbE
Posté par ptit_poulet . Évalué à 1.
Et pourquoi ne pas héberger vous même vos serveurs ? Comme ça vous gérez votre consommation électrique comme bon vous semble.
[^] # Re: NAS + 2 serveurs 1U interconnectés en 10 GbE
Posté par NeoX . Évalué à 2.
c'est la cas,
dans le loyer que paie sa boite pour les locaux, il y a un "baie technique" prevue dans les charges.
du coup ils veulent utiliser cette baie plutot que d'en monter une autre à coté.
[^] # Re: NAS + 2 serveurs 1U interconnectés en 10 GbE
Posté par ptit_poulet . Évalué à 1.
Ah ok je n'avais pas compris ça…
Donc y a les avantages d'être auto hébergé avec les inconvénients d'être hébergé chez quelqu'un… pas facile tout ça :D
[^] # Re: NAS + 2 serveurs 1U interconnectés en 10 GbE
Posté par laurent wandrebeck (site web personnel) . Évalué à 1.
Personne n’a le lieu qui va bien pour stocker les machines, ni la connex, d’ailleurs.
[^] # Re: NAS + 2 serveurs 1U interconnectés en 10 GbE
Posté par jolitorax . Évalué à 1.
Je pensais aussi à cette option. Le NAS qui consomme dans la salle dédiée et les serveurs de calcul dans les locaux.
Certains serveurs modernes sont compatible avec la classe A4 ASHRAE, ce qui veut dire des températures d'arrivée d'air entre 5 et 45°. Ce qui permet de ne pas forcement les mettre dans un datacentre, et ce d'autant plus pour des serveurs de calcul qui peuvent être éteint sans conséquences tant qu'ils ne travaillent pas. Le job scheduler (HTCondor) lui peut être sur une machine virtuelle sur le NAS (ou ailleurs).
[^] # Re: NAS + 2 serveurs 1U interconnectés en 10 GbE
Posté par laurent wandrebeck (site web personnel) . Évalué à 1.
On est léger niveau connexion réseau vers notre cœur pour monter des bécanes de processing dans la pièce. on a deux groupes de 4 bureaux, chaque groupe descendant en 1gbps vers le cœur de réseau (Et c’est non évolutif pour les mois/années qui viennent). Niveau perf ça promet. Et si en plus les utilisateurs rament…(le serveur nfs de /home est branché direct sur les switchs stackés)
En plus, il fait déjà très chaud (bâtiment hqe, pas de clim au niveau des bureaux. je suis en tshirt (et j’ai chaud), il fait 10° dehors) de base avec les machines utilisateurs, les écrans, la tour avec des cartes GPU. En rajouter, on arrête la science pour le sauna ou hammam :D
[^] # Re: NAS + 2 serveurs 1U interconnectés en 10 GbE
Posté par ptit_poulet . Évalué à 1.
Et pourquoi ne pas partir sur un nas homemade ? Le prix sera largement plus bas, avec des perfs surement plus élevées. L'intégration/encombrement ne sera pas aussi bien qu'avec un nas constructeur mais après faut se poser les bonnes questions. On veut un truc tout joli mais surement cher, ou un truc qui fait ce qu'on lui demande, pas forcément beau mais moins cher. On pourrait faire un peu comme avec la pub sur les légumes moches… :D
[^] # Re: NAS + 2 serveurs 1U interconnectés en 10 GbE
Posté par NeoX . Évalué à 2.
Pour avoir reflechit au stockage pour mon ancienne boite (l'an dernier quoi)
pour 24To de stockage, pour avoir de la redondance, etc
ce n'est pas forcement moins cher de faire soi meme (alim redondante, CPU/RAM redondante, gestion des 24To en NL-SAS)
[^] # Re: NAS + 2 serveurs 1U interconnectés en 10 GbE
Posté par legranblon (site web personnel) . Évalué à 1.
Et si le réseau est un point bloquant tu passe du 10Gbit ethernet à de l'infiniband (DDR, qdr ou fdr). Tu gagne en débit mais surtout en latence. Le petit plus, c'est qu'apparament certaines cartes peuvent accepter un firmware iscsi. :-)
[^] # Re: NAS + 2 serveurs 1U interconnectés en 10 GbE
Posté par laurent wandrebeck (site web personnel) . Évalué à 1.
hmmmmmm. du 10g partout, ce serait bien. mais c’est encore un peu cher pour notre toute petite bourse. je vais devoir faire avec du 2×1gbps (voire du 4×1) par machine et des jumbo encore un moment, je crois ;)
En supposant le cas microcloud, 12 machines, chacune avec 2 voire 4 ports gbps, ça me fait au pire du 24 ports utilisé par switch, comme ce sont des 48, je suis peinard, et j’ai quand même de la BP (et de la dispo) à pas cher avec un bonding. de quoi ne pas trop dégueulasser les perfs, je pense.
Sauf si j’arrive à caser dans nos contraintes 2 nas et 2 serveurs suffisamment pếchus auquel cas je pourrais espérer de pouvoir connecter ce petit monde en 10g sans switch, mais sinon, 1350 de switch+1600 de cartes (400€ pièce, 1 par nas, une par serveur), on est à 3k. ça risque d’être difficile à caser. Quant à l’infiniband, c’est encore moins abordable, alors je n’y pense même pas ;)
Bref, bonne nuit (et merci).
[^] # Re: NAS + 2 serveurs 1U interconnectés en 10 GbE
Posté par legranblon (site web personnel) . Évalué à 1.
Concernant l'inabordabilite de l'infiniband: tu trouves des hba infiniband ddr aux environs de 180€/pièce (160 dollards chez jpcparts) et tu peux les brancher en direct bien entendu.
# Rester sur le même type d'infrastructure
Posté par ptit_poulet . Évalué à 1.
Finalement vu les contraintes, le budget et la fonction finale. Il n'est peut-être pas judicieux de faire d'un côté un NAS et de l'autre 2-3-4 nœuds de calculs.
Je m'explique, un NAS serait vraiment top mais le problème imaginons que la CM du NAS meurt, vous ne pouvez plus bosser. Si un nœud de calcul meurt pour X ou Y raison, vous allez d'un coup perdre une grosse partie de votre puissance de calcul.
Il faudrait peut-être rester sur votre architecture actuelle mais en améliorant la partie logiciel. Utilisation d'un fs distribué du style HADOOP ou autre…
Vous avez 20k de budget et 2kW d'alimentation.
Pourquoi ne pas tenter de faire 10 PC de 2k consommant chacun 200W.
Niveau fiabilité vous serez plus tranquille, si un nœud décède pas de panique les 9 autres sont toujours là.
Par contre pour la consommation, il faudra effectivement revoir avec votre bailleur pour lui expliquer que la consommation écrite sur l'alimentation ça ne veut strictement rien dire… car le mieux aurait était de tenter de faire 20 nœuds à 1k chacun mais bon les alimentations seront plutôt de 200W chacune donc loin des 2kW en tout…
[^] # Re: Rester sur le même type d'infrastructure
Posté par laurent wandrebeck (site web personnel) . Évalué à 1.
On utilise déjà un FS distribué (moosefs actuellement, qui fonctionne très bien (niveau stabilité), à base de réplicas (ce qui est coûteux en place), qui a le défaut de ne pas être le plus rapide du monde, et qui vient de devenir proprio).
Un hadoop/hdfs (ou quantcast fs ou je ne sais quel autre backend il existe) serait certainement très bon pour les perfs. Bouger les process plutôt que les données, c’est idéal. Aux dernières nouvelles (qui remontent un peu, j’avoue), l’accès posix aux données n’était pas dispo/stable (ou libre, je ne sais plus). Et on ne peut définitivement pas modifier les codes existants (beaucoup trop lourd), ni imposer aux clients la plate-forme (c’est plutôt l’inverse…d’où le fait qu’on soit rhel compatible et posix niveau accès fichiers).
C’est pour ça que je suis arrivé à la même conclusion que toi. c’est pas le plus efficace, mais c’est le meilleur compromis (je pense).
J’ai eu un devis micro-cloud, pour 12 machines en 3U, 1620W d’alim, 96 cœurs opteron 3380, 4go/cœur, 24 disques 6to, 2×1gbps par machine, j’en suis à 16.5k€ HT.
points forts: que 1620W, pas mal de cœurs même si ce ne sont pas des bombes, 86To utiles avec un reed-solomon ou une mojette. un prix que je trouve plutôt bas (si je peux mettre le moins possible, c’est mieux).
point faible: que deux alims redondantes, que 2×1gbps. 4×1 eût été idéal (2 pour le fs, 2 pour htcondor encore que ça me semble largement overkill), mais les cartes 4×1gbps n’existent pas en microLP, et le 10g fait trop monter le budget.
Je n’avais pas pensé à la multiplication des 1U à pas cher, merci pour la piste !
En prenant des (10) pizza box 1U, low-cost au possible, une alim par box, 10×4 cœurs xeon E3-1220v3, 4go/cœur, 10×2 disques 6to, 4×1gbps par machine, j’en suis à 15k€ HT.
points forts: 4×1gbps, le prix. 10 alims (mais sans redondance).
points faibles: 2kW (avec les 800 existants que je vais réduire à 500 incompressibles à terme, difficile de négo. 1620+500 c’est plus facile pour « rentrer » dans la case 2kW max). « Que » 72To utiles.
Si je passe à 1600W, soit 8 bécanes, je n’ai plus que 32 cœurs et 58to utiles. Par contre je suis persuadé qu’ils vont en faire une jaunisse (mais on peut pas bosser dans ces conditions, c’est le retour à la préhistoire, t’as plus qu’à m’offrir un boulier, autant devenir fleuriste (no offense) etc etc), même si ça ne coûte que 12k€.
(je sais, je sais, on compare pas des cœurs d’opteron et de xeon, mais bref).
Pour la conso vis à vis du bailleur…je vais tenter ma chance sans grand espoir.
[^] # Re: Rester sur le même type d'infrastructure
Posté par NeoX . Évalué à 2.
dis leur alors de se plaindre à leur direction
qui se plaindra à la tienne,
à qui tu expliqueras l'etat du marché, et les devis que tu as fais, et pourquoi tu en arrives à ces machines
et la prochaine fois ils prevoieront un budget en fonction des devis, plutot que sorti d'un chapeau :P
[^] # Re: Rester sur le même type d'infrastructure
Posté par laurent wandrebeck (site web personnel) . Évalué à 1.
Euh. On est 10 en tout. 7 au « siège ». Et la direction…ben c’est nous, vu que la boîte nous appartient. Le budget ne sort donc pas d’un chapeau mais de la tréso :)
C’est pas avec toi que je parlais précédemment de petite structure ? ;)
[^] # Re: Rester sur le même type d'infrastructure
Posté par NeoX . Évalué à 2.
si si, mais tu peux etre dans une "petite structure" sans etre au conseil d'administration ni etre parmi les decideurs.
donc on te file parfois un budget qui n'a rien de realiste et tu dois te debrouiller avec.
[^] # Re: Rester sur le même type d'infrastructure
Posté par laurent wandrebeck (site web personnel) . Évalué à 1.
Pas réaliste…je ne sais pas. Pas idéal, c’est sûr. On obtient quand même quelque chose qui n’est pas si ridicule.
Y’a 10 ans, notre premier serveur (tour bien sûr) était un bi-athlon MP, avec 2go et 3×200go en raid 5 hard. Y’a quand même eu du progrès ;)
Mais effectivement, j’ai parfois l’impression que débrouille est mon second prénom ;)
[^] # Re: Rester sur le même type d'infrastructure
Posté par BAud (site web personnel) . Évalué à 2.
essaie tout de même si tu ne peux pas obtenir des fonds de panier en fin d'année (si tu peux te permettre d'attendre fin novembre pour demander des devis) : avec une dizaine à quinzaine de machines, tu pourrais obtenir de meilleurs réductions que ce à quoi tu t'attends, parfois Noël et les clôtures de fin d'année ont du bon quand tu arrives avec du volume.
[^] # Re: Rester sur le même type d'infrastructure
Posté par ptit_poulet . Évalué à 1.
Voir même prendre des modèles de proc en fin de vie. Une fois la nouvelle gamme sur le marché, les prix des anciens dégringolent.
Pour les proc, je sais je vais me faire taper sur les doigts par tout le monde. Mais regarde aussi côté "grand public" les rapports perf/prix sont peut-être plus abordables, sachant que tu auras le choix de partir sur de la CM moins cher et donc au final peut-être baisser encore les tarifs ce qui permettrait de prendre 2 machines de plus. Ça permettrait au final d'avoir quasiment la même puissance de calcul mais d'être encore plus serein côté redondance.
[^] # Re: Rester sur le même type d'infrastructure
Posté par laurent wandrebeck (site web personnel) . Évalué à 1.
J’ai eu un devis pour le microcloud, en opteron avec des disques de 6to: 17.6k€HT. Je peux gagner là-dessus 1.2k€ en achetant les disques en lignes, soit 16.4k€.
CPU à 218€HT l’unité, difficile de trouver moins cher. Basculer sur du CPU grand public, c’est compliqué, y’a pas de cm petit format, donc obligé de se tourner vers des bécanes 1U, et donc on est limité à 8 bécanes (pour la conso, principalement, mais aussi la place).
[^] # Re: Rester sur le même type d'infrastructure
Posté par laurent wandrebeck (site web personnel) . Évalué à 1.
Hélas, je ne peux pas multiplier les machines à loisir. à 200W l’alim pour les plus légères que j’ai trouvé, je ne peux en avoir que 8 pour ne pas trop exploser la limite de conso qui nous est imposée. À 200W, deux disques par machine, point de salut. Donc moins de disques et moins de cœurs que ce qu’offre le microcloud pour la même conso :(
Pour les fonds de panier, je peux attendre un peu.
Quels vendeurs me conseillerais-tu de contacter ?
[^] # Re: Rester sur le même type d'infrastructure
Posté par ptit_poulet . Évalué à 1.
Je vais rajouter un truc concernant les disques durs. Fait les calculs avec des disques de 3To au lieu de 6To. Pour le même prix tu devrais obtenir une capacité totale plus élevée tout en étalant un peu la charge sur plus de support. En cas de soucis sur un hdd tu perdras qu'un disque de 3To au lieu de 6To d'un seul coup, ce qui permettrait une remise en marche plus rapide lors de changement du hdd.
[^] # Re: Rester sur le même type d'infrastructure
Posté par laurent wandrebeck (site web personnel) . Évalué à 1.
Limitation de place en rack et de consommation, donc multiplier les disques n’est pas possible. Ce serait évidemment bon pour les perfs et limiterait l’I/O quand un disque crâme, j’en suis bien conscient, mais…
Au final, j’aurais dû écrire mon post ainsi:
Vous avez 1.6kW en puissance théorique max, 15U, un budget de 20k, 2×45 ports gbps via un 2 switchs stackés en 10g à dispo, et besoin d’autant d’espace (70To utiles mini), de puissance de calcul, de dispo que possible.
Que proposez-vous ?
La vache, c’est ’achement plus court dit comme ça !
Mais merci d’avoir réfléchi à mon problème :)
[^] # Re: Rester sur le même type d'infrastructure
Posté par ptit_poulet . Évalué à 1. Dernière modification le 27 juillet 2024 à 11:48.
C'est bon j'ai LA solution http://4.bp.blogspot.com/-1E1CISTF4Rk/USIuZ34zRWI/AAAAAAAADEk/JLC9-bVa3Dw/s1600/Screen+Shot+2013-02-18+at+7.05.05+PM.png
Qui dit mieux ?
[^] # Re: Rester sur le même type d'infrastructure
Posté par laurent wandrebeck (site web personnel) . Évalué à 1.
Presque !
Mais ça doit pêcher du côté x86_64, et du côté réseau aussi, pi de la ram. ;)
[^] # Re: Rester sur le même type d'infrastructure
Posté par NeoX . Évalué à 2.
ben deja on a pas la meme definition de puissance dispo.
moi j'ai un contrat qui me dit ca, je lui met du NAS comme indiqué precedemment à 400W les 144To sur 2x2U
il ne reste plus que les noeuds de calculs pour les 1200W restant.
là encore je ne regarde pas l'alim, mais la consommation du produit.
[^] # Re: Rester sur le même type d'infrastructure
Posté par laurent wandrebeck (site web personnel) . Évalué à 1.
C’est sympa de ta part d’intervenir, mais ce serait bien de me lire aussi ;) Les comptes ne se font pas en conso max du produit mais en puissance max théorique de l’alim (même si c’est ce que je vais essayer de négocier). Ta soluce, c’est donc du 800W selon ce mode, et ~250W sinon.
Pour me citer à propos de cette histoire de nas: http://linuxfr.org/nodes/103747/comments/1569980
Merci :)
[^] # Re: Rester sur le même type d'infrastructure
Posté par NeoX . Évalué à 3.
c'est bien pour cela que je precisais qu'on avait deja discuté du sujet.
mais ton exemple de contrat dit "puissance theorique max"
il ne parle pas de puissance des alims.
le jour ou tu trouves une alim avec 100% de conversion pour 100% de charge, tu m'appelles.
les alims 80%GOLD te certifie une perte minimale quand l'alim est chargée à 80% de sa puissance.
ainsi une alim de 800W sera "optimale" à 640W de charge.
et il est peu probablement que le constructeur mettent une alim de 800W si les composants dans le PC/Serveur chargent cette meme alim à 640W.
bref, s'il n'est pas precisé dans le contrat que c'est la puissance indicative de l'alim qui est l'element determinant, tu peux considerer que l'alim consomme au mieux 80% de ce qui est indiqué dessus (en toute theorie).
mais je suis d'accord que ca ne te donne pas de solution à ton probleme.
peut-etre faudrait-il voir avec vos fournisseurs habituelles, et faire jouer la concurrence,
on arrive en fin d'année, les commerciaux vont se battre pour te vendre "leur" solution de HPC,
et toi tu fais descendre les prix (comme deja dit, j'ai eu presque 50% sur les prix catalogue de grands noms du SAN/NAS)
et meme si ca rentre pas dans les 20K€, (+-10%) tu as un justificatif pour ta direction pour tenter d'augmenter un peu le budget.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.