bogdan a écrit 16 commentaires

oula j'ai l'impression que tu mélanges un peu tout.
oula j'ai l'impression que tu me prends un peu pour un con toi !!!

Si je veux mutualiser mon stockage, j'utilise plutôt un SAN. Et dans ce cas la mes volumes/LUN sont dans le filesystem que je veux.
FAUX. Tu n'a jamais managé un SAN/NAS et ca se voit. Sur aucun des appareils vendus dans le commerce tu n'as la liberté du FS (ni chez netapp, ni chez emc, ni chez HP, etc.), les FS sont imposés, sinon si tu bidouilles ton filer, au revoir le support et à la première panne tu est au chomage.
Sinon je cherche à pouvoir construire des filers avec des technos libres et c'est impossible encore (manque des fonctions esentielles).

Concernant ZFS tu corrobores mon point de vue comme quoi c'est un produit non fini et non interopérable.

Dans tous les cas je trouve ca incroyable comme les gens de ce site croyent tout savoir sur tout. Bel esprit vraiment, continuez comme ca !

J'en viens au simple fait que ZFS est loin d'être mur et interopérable et c'est dommage.

Tous les admin du monde ont besoin d'avoir le moins possible de machines de stockage (dans ton cas d'avoir des Samba et des serveurs W$ n'est pas optimal comme chez nous autres d'ailleurs) et le fait de grouper les 2 types de données UNIX/W$ sur un cluster de serveurs peut d'avérer tiptop (sauvegarde, accès, maintenance, gestion des droits, snapshots, etc....)

Dans ton cas, de faire du Samba over ext3 ou over ZFS c'est pareil, reste que si ta DSI pouvait mutualiser tes données sur des clusters de stockage centralisés ils le feraient sans sourciller :)

Je ne pense pas que ZFS soit pour l'instant d'une grande utilité en entreprise (tu veux vraiment convertir des partoches en ZFS ? as tu testé toutes les applis qui y accèdent tout ca ? ), mais prions/participons pour que lui et BTRFS le deviennent, interopérables et finis :)

Tu es vraiment d'une mauvaise foi incroyable et tu me fais dire ce que je n'ai pas dit.

Déja tu devrais arrêter de polémiquer vainement sur ma capacité à ouvrir les yeux sur le marché, je ne répondrais pas à tes frustrations d'admin LinuxFR aux chevilles sur-dimensionnées et qui a tout vu.

Mon point est le suivant : quelles que soient les données d'entreprise, au vu du pourcentage de machines W$, celles-ci seront fatalement amenées à consulter et modifier ces données. Ainsi, l'usage des ACL devient indispensable afin de reproduire l'architecture des droits des différents intervenants sur une arborescence globale (je pense aux droits des chefs de mission, projet, service, département, division, etc. qui sont transversaux) et Samba n'est pas pour moi (comme d'ailleurs pour pas mal de DSI dans notre cas) une solution viable.

Donc les ACL dans une entreprise c'est essentiel (oui il existe de bidouilles et autres pour contourner), l'idéal étant qu'un même volume de données puisse être tagué à la fois ACL et UNIX; chose qui n'existe pas pour l'instant.

Oui il n'y a pas d'ACL sur les serveurs UNIX, grande nouvelle.
Par contre je suis sur que les postes bureautique de la banque ont *aussi* accès à des partages autres que des Samba qui fonctionnent avec des ACL, meme si cela dépasse ta conaisssance.

Ahhh la mauvaise foi ca a du bon desfois !!!
Je ne bosse pas sur des projets bureautique, etc... Tu ne bosse pas donc tu ne vois pas, tu ne connais pas ?
Cite moi une seule entreprise du CAC40 (ou du moins connue) qui peut se passer de la gestion d'ACL sur ses serveurs de stockage. Il n'y en a pas !!!
Des projets uniquement UNIX qui n'ont pas besoin d'ACL on en a tous fait, de la à dire que les ACL ne sont pas indispensables dans un monde profesionnel, c'est une enorme connerie.

Je ne suis pas un grand utilisateur de BSD donc oui peut-être que ZFS est très utilisé, comme je le disais plus haut : à la masion pour faire des bidouilles.

Je cite "(tout le monde n'utilise pas les ACL non plus)" : eh ben si. N'importe ou dans le monde le parc des machines reste à 95% du Windows donc les ACL sur les serveurs de stockage c'est un *besoin primordial*.

Et non Oracle ne paye personne pour le portage de BTRFS sur BSD/Solaris mais je mets ma main à couper que BTRFS sera 1.0 avant qu'on ait une version utilisable de ZFS en Linux ou BSD. N'est ce pas ce qui nous intéresse : avoir un bon FS sous Linux pour pouvoir profiter de cet OS ??

Je dis juste que si SUN ne met pas son équipe de dév pour porter ZFS, la communauté ne fera pas mieux que ce que nous avons actuellement, càd quelquechose d'approximatif et qui manque de fonctions pour être *vraiment* utilisable.

Et non il ne manque pas des fonctions d'appoint comme tu le sous-entends mais bel et bien de vrais must-have : je suis désolé mais le support des ACL est *indispensable* dans un monde profesionnel (à la maison je veux bien croire que non, sinon tous ceux qui racontent le contraire sont des incompétents ou alors n'ont jamais vu les 97% du marché qui en ont besoin).

Pour en revenir à ce que tu défends dur comme fer, oui ZFS est peut-être le FS "moderne" le plus avancé multi-plateforme libres, je ne le discute pas. Par contre je discute le fait que ZFS soit *utilisable* autre part que à la maison pour faire des bidouilles; pour le moment il est impossible d'utiliser ZFS (Linux/*BSD) dans une entreprise (un truc serieux hein, pas ma boite que j'ai monté hier :) ).

Et si tu veux un exemple de FS qui a super bien marché autre part que dans son OS d'origine regarde XFS : développé par SGI dans les années 90, on peut faire un / en XFS sous Linux, BSD, etc .... en plus toutes les fonctions du FS marchent et c'est le FS le plus performant à l'heure actuelle (discutable mais en général sur les opérations simples : création de masse, renommage en masse, destruction d'inodes, accès, etc. c'est lui qui défonce ext3, reiser et les autres; pour cela voir un article datant de qqes mois chez /. ou sinon testez chez vous :) ).

Populaire sous FreeBSD ? Impossible, arrete de raconter n'importe quoi, il manque la partie la plus dure à coder (ACL et boot de / en ZFS) :

Missing functionality :

- We don't have iSCSI target daemon in the tree, so sharing ZVOLs via
iSCSI is also not supported at this point. This should be fixed in
the future, we may also add support for sharing ZVOLs over ggate.
- There is no support for ACLs and extended attributes.
- There is no support for booting off of ZFS file system.

Extrait du post du porteur de ZFS sous BSD... Et donc je comprends mal qu'un portage non fini puisse être "populaire".

Et comme tu le dis bien, il existe des *portages* sous pas mal de systèmes mais aucun n'est opérationnel et surtout pas le Linux dont il manque les 20% de code les plus délicats et il faut appliquer des patchs exotiques pour faire tourner une moitié de ZFS.

C'est bien beau de la part de SUN d'encourager le portage (Allez-y les gars faits vous plaisir à porter, nous on regarde, on a d'autres trucs à faire) sans y mettre ne serait-ce qu'une personne qui conaisse le code.

En conclusion avant d'attaquer mes remarques, prends le temps de lire l'état d'avancement de ZFS sur BSD, Linux, OSX et autres et tu comprendras que ce n'est pas gagné pour l'avoir 100% opérationnel et natif avant des années.

Je ne veux vraiment pas jouer le rabat-joie mais :

1) Le principe du snapshot existe depuis belle lurette chez Netapp, EMC et autres (pour les grands constructeurs de stockage) et est plutot bien intégré à Windows (clic droit et "Anciennes versions" sous WinXP) et UNIX (cd .snapshot, un peu plus roots mais ca le fait aussi).
2) Conaissant SUN j'ai du mal à croire que le ZFS sera un jour populaire sous Linux/*BSD puisque ce n'est pas son but et que le portage n'est pas vraiment facile (et oui il faut des ressources pour le faire, chose que SUN ne mettra jamais en oeuvre).

Sinon je vous invite à regarder du coté BTRFS qui lui est écrit pour Linux et possède nombre de qualités (snap, mirroring, stripping, compression, multiple RAID, etc.) dont la première est d'être GPL et fait pour Linux.

Biensur que ce n'est pas une question d'égo; je ne lis pas tous les commentaires, je cible en regardant la note... Et franchement je pense que la plupart des lecteurs DLFP font pareil, non ?

Torque est un bon produit, comme tu le dis c'est une souche OpenPBS; de plus on trouve pas mal d'infos sur les ML Torqueusers (et pas seulement des infos clustering mais aussi pour des soucis MPI ou autre).
Comme tu le dis aussi il faut Maui pour faire la gestion de ressources ce qui prouve à mon goût que le projet n'est plus vraiment actif au niveau dév.
Oui, il doit "bien tourner", après tout dépend de ta politique de scheduling : dans la plupart des cas que j'ai rencontré l'idéal était de classer ses jobs par type de code, walltime, memory used et priorité puis d'organiser soit en suspendant des jobs longs (donc forcément peu prioritaires), ou/et en priorisant les utilisateurs qui ont moins consommé de ressources que d'autres (fairshare); après on peut affiner en créant des queues prime et non prime (queues qui tournent le jour ou la nuit), etc ... Ce genre de politique de scheduling n'était pas implémentée (ou du moins pas en changeant 1 seule ligne de conf) dans OpenPBS donc je ne pense pas qu'on puisse le faire facilement avec Torque.
Si vous devez faire une étude comparative pour votre cluster, vous pouvez considérer Torque et/ou OpenPBS dans votre liste de soft, mais les fonctions de ces derniers se retrouvent dans SGE ou PBS Pro avec pas mal d'autres truc sexy (j'ai fait l'exercice plusieures fois avec différentes contraintes à chaque fois et le couple SGE / PBS Pro a toujours été gagnant et pour pas chèr).

Ben SGE est un bon soft libre, multi-plateformes, qui marche bien avec la plupart des noeuds qu'on peut acheter actuellement (dell PE, altix, bluegene, les bull, ...) et qui a toutes les fonctionnalités utiles dans un job scheduler. Comme je le disais le plus difficile avec SGE c'est d'intégrer des codes de calcul proprio (Abaqus, Fluent, Nastran, Radioss, etc ...) d'une marnière propre (le but étant que le scheduler puisse arrêter un job, libérer la license puis reprendre ce job; le tout sans intervention humaine sur les fichiers d'entrée). Là, il faut commencer à perdre des jours pour faire des scripts shell ...
Ensuite si on a un minimun de moyens (de l'ordre de 25euro par core/proc) je recommande PBS Pro qui est très complet; pas la peine d'aller chercher LSF (ok c'est très complet aussi, ca marche sur toutes les plate-formes mais ca coute énormément plus cher).
Après sur des plus gros systèmes de tout de facon votre vendeur de hard essayera de vous vendre son soft (je pense notamment à IBM ou SGI) mais je trouve que PBS comme d'ailleurs SGE marchent très bien sur des grappes d'Altix ou de Bleugene si on les configure correctement (en faisant des virtual nodes par lames, ...)

Evidemment le rédacteur de la news poste un commentaire sans aucun intéret en ayant foutu 3 mot clés dans Google et il est mieux noté que les gens qui apportent vraiment qqchose, meci linuxfr...

Ca c'est une belle usine à gaz dont le coeur est écrit en Java (1 proc "monopolisé" par le thread central du soft car meme si en ram la JVM ne fait pas beaucoup en CPU ca pèse, encore difficilement installable sur des archis exotiques : RISC, PPC, même ia64) et avec un système de BDD trop compliqué (pourquoi aller chercher un Oracle ou MySQL pour un cluster alors qu'un fichier texte ou un SQLite suffisent amplement!!).
De plus, après avoir lu la doc du produit, il me semble manquer de fonctionnalités essentielles pour un Job Scheduler : personnalisation des start/stop job, mise en place de ressources pour la gestion des licences, intégration des codes de calcul.
Bref, un produit qui n'apporte rien et qui manque de fonctions.

Il n'y a qu'une solution à ton problème : SGE (Sun Grid Engine), c'est du OpenSource by Sun. Pour l'avoir testé sur une 40aine de noeuds (i386 et x86_64) je peux dire qu'il est plutôt complet au niveau "concepts généraux" et les dev sont prompts à te répondre sur les ML. Par contre là où j'ai vite atteint les limites c'est pour l'intégration de codes de calcul proprio : rien n'est prévu de base, il faut tout scripter.
La déclaration de ressources dynamiques (c'était pour des licences logicielles qui n'étaient pas entièrement gerées par SGE) m'a aussi posé problème : impossible sur la version que j'avais d'appeler un script pour lire le nombre de licences restantes....
Sinon le meilleur rapport qualité/prix d'aujourd'hui c'est PBS Pro (qui se base sur OpenPBS, que je ne conseille pas car vieux et non maintenu :) ); très complet, avec interface HTTP permettant de soumettre les jobs, intégration de beaucoup de codes, intégration des lib MPI, fairshare, etc.

Il s'agit également de la toute première distribution Linux à proposer le support expérimental des menus DVD...


On ne va pas deconner non plus à dire qu'on a inventé le monde...

Plus serieusement ne voyez pas là une critique de cette très bonne distro spécialisée mais cette dernière phrase me choque vraiment !!! Cela m'étonnerait fortement qu'au niveau intégration de nouvelles versions de code vous fassiez mieux qu'une certaine G---oo pour ne pas la nommer.
En tout cas bon travail !