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…
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.
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 ;)
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.
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.
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…).
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 :)).
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).
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.
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) ?
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.
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…
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.
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 !
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. :)
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.
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 ;)
Si on en est a parler de la longueur du support…CentOS ou Scientific Linux sont vos amies.
C'est précisément pour cela d'ailleurs que je n'installe que ça au boulot…en dehors de toute considération hautement intellectuelle du type rpm sapu et autres debian rulez, bien évidemment.
J'allais oublier, ça marche™ bien, c'est stable et je ne prendrais pas deux barils d'ubuntu LTS contre un baril de CentOS. Certes les repo sont un peu moins peuplés, mais vraiment rien de bien méchant…
Bref. C'était mes 0.02€ !
http://www.opennms.org/ pour ma part. le seul souci est que les rpm sont pourris, qu'il ne faut surtout pas mettre à jour une fois installé car ça flingue la config :( Faudra d'ailleurs que je me motive pour réparer ça…
J'ai effectivement regardé (de loin) ces softs. pour apache, pas trop trop de soucis, par contre pour pg je ne vois pas trop comment faire du maître/maître et en ayant posé la question à un guru pg ou deux, il faudrait déployer ce genre de choses via londiste et autres bousins qui fonctionnent à grands renforts de triggers.
Ce qui est un peu « too much » pour moi, je n'ai ni le temps ni l'envie de me plonger dans ce genre de softs assez complexes et dont la maintenance ne me paraît pas simple à gérer en cas de souci.
Bref, merci pour tes lumières en tout cas !
Les raisons:
- pas de perte de place.
- déjà eu plusieurs raid 5/6 qui survivaient pas à un rebuild car un autre disque explosait en vol pendant le dit-rebuild (avec des gros disques en 5400rpm c'est − un peu − long comme opération).
- pas très bons en écriture les raid 5/6, déjà que mfs n'est pas un foudre de guerre dans ce cas :)
- remplacer un disque unique évite de faire gratter à mort le reste des disques de la machine impliquée (pas bon pour les perfs).
- c'est la réplication de mfs qui se charge de la sécu des données.
Je crois que c'est tout :)
Pour la HA d'apache, vu la charge (hum hum), j'aurais deux VM (kvm) sur deux machines différentes, rien de plus, il faudra que je me débrouille avec ça.
Quant à condor, il ne sert effectivement en rien à la HA, il est là pour faciliter l'utilisation de la puissance à disposition (exemple, on a X images à traiter, avant on bouclait X fois, et seul un cpu cravachait, maintenant, condor se charge de balancer les X tâches sur les cœurs dispo du parc).
[^] # Re: NUC pour le calcul, plus noeuds de stockage
Posté par laurent wandrebeck (site web personnel) . En réponse au message Remplacer un (petit) cluster pour consommer bcp moins tout en gardant de la puissance. É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 laurent wandrebeck (site web personnel) . En réponse au message Remplacer un (petit) cluster pour consommer bcp moins tout en gardant de la puissance. É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: Code à effacement, codes systématiques et puissance de calcul
Posté par laurent wandrebeck (site web personnel) . En réponse au message Remplacer un (petit) cluster pour consommer bcp moins tout en gardant de la puissance. É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: NUC pour le calcul, plus noeuds de stockage
Posté par laurent wandrebeck (site web personnel) . En réponse au message Remplacer un (petit) cluster pour consommer bcp moins tout en gardant de la puissance. É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 laurent wandrebeck (site web personnel) . En réponse au message Remplacer un (petit) cluster pour consommer bcp moins tout en gardant de la puissance. É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 laurent wandrebeck (site web personnel) . En réponse au message Remplacer un (petit) cluster pour consommer bcp moins tout en gardant de la puissance. É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: Type d'IO, Conso ?
Posté par laurent wandrebeck (site web personnel) . En réponse au message Remplacer un (petit) cluster pour consommer bcp moins tout en gardant de la puissance. É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 :)).
[^] # Re: Type d'IO, Conso ?
Posté par laurent wandrebeck (site web personnel) . En réponse au message Remplacer un (petit) cluster pour consommer bcp moins tout en gardant de la puissance. É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: NUC pour le calcul, plus noeuds de stockage
Posté par laurent wandrebeck (site web personnel) . En réponse au message Remplacer un (petit) cluster pour consommer bcp moins tout en gardant de la puissance. É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 laurent wandrebeck (site web personnel) . En réponse au message Remplacer un (petit) cluster pour consommer bcp moins tout en gardant de la puissance. É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: Type d'IO, Conso ?
Posté par laurent wandrebeck (site web personnel) . En réponse au message Remplacer un (petit) cluster pour consommer bcp moins tout en gardant de la puissance. É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 laurent wandrebeck (site web personnel) . En réponse au message Remplacer un (petit) cluster pour consommer bcp moins tout en gardant de la puissance. É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 laurent wandrebeck (site web personnel) . En réponse au message Remplacer un (petit) cluster pour consommer bcp moins tout en gardant de la puissance. É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: NUC pour le calcul, plus noeuds de stockage
Posté par laurent wandrebeck (site web personnel) . En réponse au message Remplacer un (petit) cluster pour consommer bcp moins tout en gardant de la puissance. É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: Ansible
Posté par laurent wandrebeck (site web personnel) . En réponse au message Remplacer un (petit) cluster pour consommer bcp moins tout en gardant de la puissance. É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. :)
[^] # Re: Type d'IO, Conso ?
Posté par laurent wandrebeck (site web personnel) . En réponse au message Remplacer un (petit) cluster pour consommer bcp moins tout en gardant de la puissance. É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.
# FS Posix et x86_64
Posté par laurent wandrebeck (site web personnel) . En réponse au message Remplacer un (petit) cluster pour consommer bcp moins tout en gardant de la puissance. É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 ;)
[^] # Re: Ça tombe bien, j'allais l'installer
Posté par laurent wandrebeck (site web personnel) . En réponse à la dépêche Piwigo 2.7 : un chez-soi pour vos photos. Évalué à 0.
OK Nikrou, bien vu, tu m’as grillé d’un pouième :D
[^] # Re: Ça tombe bien, j'allais l'installer
Posté par laurent wandrebeck (site web personnel) . En réponse à la dépêche Piwigo 2.7 : un chez-soi pour vos photos. Évalué à 4.
Pour Pg, il existe Phyxo, un fork de Piwigo. http://www.nikrou.net/post/2014/09/28/Phyxo-1.2.0-est-de-sortie-!
Mes 0.02€ :)
[^] # Re: Migration de Ubuntu vers Debian prévue ?
Posté par laurent wandrebeck (site web personnel) . En réponse à la dépêche Compte-rendu de l'intervention mercredi 17 avril. Évalué à 6.
Si on en est a parler de la longueur du support…CentOS ou Scientific Linux sont vos amies.
C'est précisément pour cela d'ailleurs que je n'installe que ça au boulot…en dehors de toute considération hautement intellectuelle du type rpm sapu et autres debian rulez, bien évidemment.
J'allais oublier, ça marche™ bien, c'est stable et je ne prendrais pas deux barils d'ubuntu LTS contre un baril de CentOS. Certes les repo sont un peu moins peuplés, mais vraiment rien de bien méchant…
Bref. C'était mes 0.02€ !
# opennms
Posté par laurent wandrebeck (site web personnel) . En réponse au sondage Quel outil de supervision ?. Évalué à 1.
http://www.opennms.org/ pour ma part. le seul souci est que les rpm sont pourris, qu'il ne faut surtout pas mettre à jour une fois installé car ça flingue la config :( Faudra d'ailleurs que je me motive pour réparer ça…
[^] # Re: CEA/Bull
Posté par laurent wandrebeck (site web personnel) . En réponse à la dépêche Sortie du Top 500 de juin 2012. Évalué à 3.
Le premier calculateur français plutôt, non ?
[^] # Re: Pacemaker
Posté par laurent wandrebeck (site web personnel) . En réponse au journal Quelles solutions adopter pour améliorer un parc existant ? La suite !. Évalué à 0.
J'ai effectivement regardé (de loin) ces softs. pour apache, pas trop trop de soucis, par contre pour pg je ne vois pas trop comment faire du maître/maître et en ayant posé la question à un guru pg ou deux, il faudrait déployer ce genre de choses via londiste et autres bousins qui fonctionnent à grands renforts de triggers.
Ce qui est un peu « too much » pour moi, je n'ai ni le temps ni l'envie de me plonger dans ce genre de softs assez complexes et dont la maintenance ne me paraît pas simple à gérer en cas de souci.
Bref, merci pour tes lumières en tout cas !
[^] # Re: JBOD au lieu de RAID 0/5/6
Posté par laurent wandrebeck (site web personnel) . En réponse au journal Quelles solutions adopter pour améliorer un parc existant ? La suite !. Évalué à 1.
Les raisons:
- pas de perte de place.
- déjà eu plusieurs raid 5/6 qui survivaient pas à un rebuild car un autre disque explosait en vol pendant le dit-rebuild (avec des gros disques en 5400rpm c'est − un peu − long comme opération).
- pas très bons en écriture les raid 5/6, déjà que mfs n'est pas un foudre de guerre dans ce cas :)
- remplacer un disque unique évite de faire gratter à mort le reste des disques de la machine impliquée (pas bon pour les perfs).
- c'est la réplication de mfs qui se charge de la sécu des données.
Je crois que c'est tout :)
[^] # Re: HA avec Apache
Posté par laurent wandrebeck (site web personnel) . En réponse au journal Quelles solutions adopter pour améliorer un parc existant ? La suite !. Évalué à 0.
Pour la HA d'apache, vu la charge (hum hum), j'aurais deux VM (kvm) sur deux machines différentes, rien de plus, il faudra que je me débrouille avec ça.
Quant à condor, il ne sert effectivement en rien à la HA, il est là pour faciliter l'utilisation de la puissance à disposition (exemple, on a X images à traiter, avant on bouclait X fois, et seul un cpu cravachait, maintenant, condor se charge de balancer les X tâches sur les cœurs dispo du parc).