J'avais fais un grand texte, mais je viens de tout perdre (le système de gestion du forum, coupe la connexion malgré le fait que quelqu’un tape son texte, bon, certains sont un peu lent ... mais quand même!), je recommence donc en essayant d'en retrouver les grandes lignes.
Pour l'anecdote, mon tout premier système de virtualisation était basé sur le moteur de Windows 3.1 débarrassé de toutes choses windozienne pour ne garder que la partie commutation de tâches dos, j'aimais trop faire tourner des programmes dos en même temps, mon but était d'avoir une fluidité maximale entre les tâches, ce qui n'était pas facile, mais le "semblant" était quelquefois bluffant.
Cette "chose" (ou cette bidouille pour reprendre ce terme par quelqu'un) tenait sur une disquette 3 pouces et demi formaté en 1600Ko (au lieu de 1440ko) et "compressé à mort" (il restait quelques octets de libre sur la disquette!), la gestion de la mémoire haute était hyper optimisé, c'était à l'époque du dos 4 & 5, en dos 5, je devais tourner a environ 621ko de mémoire dispo dans la partie des fameux 640. Je mettais des jours pour gagner ne serait-ce que 1ko ! C'est vieux tout ça ! presque 25 ans !
Ensuite, j'ai utilisé OS/2 1.0 (qui a l'époque était écrit par Microsoft, juste avant le divorce avec IBM), la commutation était déjà efficace, à l'époque c'était génial, on était à l'époque des 386SX et on bavait tous devant les DX (chez moi, j'étais encore au 8086, du 16 bits!), le premier 486 a cette époque un million de francs ... nouveau!
Quelques années après, j'ai utilisé Vmware sous Windows puis sous Linux en RedHat (cela fonctionnait beaucoup mieux que Vmware en Windows, disons que le gros avantage c'était que ça plantait pas).
Aujourd'hui, j'utilise vbox sous debian, car je trouve cela très simple et performant.
XEN a été un de mes projet (j'ai toujours été fasciné par l'idée du concept), mais à l'époque, la mise en service était très compliqué, réservé qu'aux experts ou autres "barbus", tout ceci avec très peu de doc, bref, je ne me sentais pas dans ce monde.
De plus, le mode "virtualisation complète" avait et a parait-il peu d'intérêt sur un système de type Windows.
Se lancer dans une structure informatique demande du temps et tous changements de cap est aussi dur que de changer de direction avec un paquebot, surtout lorsque l'on a commencé a poser les premières briques et que la structure est déjà en production (parce que aussi on a pas le temps de se tourner les pouces).
Je suis une personne qui associe plusieurs éléments pour les mettre bout à bout, certains sortent le carnet de chèque et achète des solutions toutes faites, moi, je ne peux pas coté finances et surtout ça ne m'intéresse pas, j'aime savoir comment les choses fonctionnent et quand on est dans cette approche, on aime faire les choses par soit-même.
A un moment donné, il faut faire un choix, on essaie de faire "du mieux possible" et ensuite on se lance dans l'aventure.
Mon choix s'est porté sur vbox, non pas par rapport à une icône (tu me fais mal en disant ça, car je ne mange pas de ce pain là), mais par rapport au mode "headless". Mon utilisation de vbox se base sur deux scripts (./lance_mv.sh qui lance la mv en paramètre et ./save_mv.sh qui sauvegarde une mv avec une option de remise en route après la sauvegarde).
J'ai plusieurs serveurs de mv en debian et ceux-ci sont allégés au strict minimum: une net-install, ssh et vbox, ensuite un coup de balai avec rcconf pour virer les services inutiles et un swappiness à 0 pour avoir tout en mémoire. Cela donne un serveur de mv ultra-léger, monté en qq minutes et très véloce.
Quand aucune machine virtuelle est lancée, mes serveurs font moins de 30Mo de RAM avec 14 threads.
Pour les utilisateurs de mv, ce sont des postes clients en debian aussi (de vieux bousins de l'ancienne structure info de récup) qui possèdent en gros le même concept au niveau légèreté, mais au lieu de vbox, on y trouve juste le serveur X (x-window-system), il n'y a pas de gestionnaire de fenêtres. Au démarrage, un script accouplé à "dialog" (système de menu en mode texte style "install en mode texte de debian"), permet à l'utilisateur de faire des choix, il peut choisir la machine virtuelle qui l'intéresse. Ce script, va ensuite interroger les serveurs de machines virtuelles pour y trouver son bonheur. Car au départ il ne sait pas ou se trouve la mv, lorsqu'il a trouvé sa mv, il lance juste rdesktop sous X, celui-ci est lancé en full-screen ce qui fait que la mv prend place sur le poste client directement en mode graphique.
J'ai utilisé du VNC et je ne veux pas de cela, c'est trop peu réactif, je préfère nettement RDP même si il y a un léger bug coté pavé numérique (xfreerdp serait mieux mais il a un bug qui est gênant en exploitation ... enfin au moment ou j'écris ces lignes).
Toute cette structure est facile a mettre en œuvre et est robuste (toujours pas d'onduleurs, j'en ai trois mais les batteries sont hs ... et je sais plus où !), les serveurs sont autonomes et peuvent fonctionner séparément.
Même si ma structure est simple, elle n'a pas été facile a pondre, et je ne peux pas changer de cap facilement, car le projet est en cours, il est réellement productif depuis un an et je viens juste de finir de tout virtualiser, plus aucun windows n'est physique (environs 12 postes windows et 4 à 6 Linux).
Chaque mv est sauvegardées le soir et les sauvegardes finissent dans un nas4free (mirroir de 2 disques de 2To), ce n4f est pour l'instant clôné au "niveau fichiers" avec rsync sur une debian. Le nas4free a des snapshots auto et le rsync est exécuté avec l'option "backup" dans un boitier déporté (suis un peu parano). Il doit y avoir environ 2 millions de fichiers.
C'est une structure qui fonctionne bien, qui est ultra réactive coté mv windows XP (XP démarre en quelques secondes et l'affichage et instantané, difficile de savoir que l'on est en virtualisation d'ailleurs).
Je pense que tu comprendras qu'un changement de direction sur une structure de ce genre n'est pas facile, je dois aller jusqu'au bout et si je trouve mieux, alors, je changerai mais seulement lorsque le moment sera opportun.
Il me reste quelques petites choses a faire comme déplacer et détruire des mv depuis les postes clients (par le menu "dialog").
Ensuite un de mes projets et faire une gestion dynamique des capacités de virtualisation, c'est à dire qu'un serveur pourra "jauger" de sa charge et éventuellement demander le déplacement de la mv en fonctionnement sur un autre serveur. La structure pourrait passer d'un simple simple RaspberryPi au départ et finir avec plusieurs serveurs en service, et cela en toute transparence. Le repli de cette structure se ferait dans l'autre même sens. C'est pas évident, mais tout semble être ok pour le faire.
Donc pour en revenir avec XEN, c'est certainement bien, mais je ne peux pas l'essayer pour l'instant, ou alors, il faut que les possibilités soit compatible avec l'existant pour le fondre dans ma structure.
Pour l'iscsi, c'est un domaine nouveau pour moi, je trouve cela intéressant, mais il faut respecter certaines choses comme le ou les réseaux dédiés.
Je ne pense pas qu'il faille faire de l'iscsi pour "faire de l'iscsi" ou suivre une mode mais pour se sortir d'une structure matérielle dans certains cas, ce que je trouve de bien, c'est qu'on peut désormais travailler avec des "choses logiques ou virtuelles". Le manque de performances de ce coté est compensé par des améliorations matérielles, une structure virtuelle à l'heure actuelle marche aussi bien (même mieux) qu'une structure physique d'il y a quelques années, avec l'avantage d'être totalement malléable ... et indestructible).
Je sais qu'il existe des contraintes techniques cotés performances, mais les performances sont faites pour être améliorées et les pb pour être résolus, c'est d'ailleurs comme ça qu'avancent les choses, c'est pourquoi, je n'aime pas trop quand on met des "limitations"
sur un domaine en mouvement et en perpétuelle augmentation, des bémols oui, mais pas des stops, et puis dans ma philosophie c'est pas parce que quelqu'un n'y arrive pas, que d'autres n'y arriveront pas, j'ai quelques bons exemples de ce coté là mais dans le domaines des automatismes.
Pour Nas4free, j'ai trouvé mon bonheur avec celui-ci, en fait, c'est un peu un "garde-fou" pour moi, car il m'impose naturellement une config simple sans "trucs bizarres" (les fameuses "config exotiques" que certains montrent du doigt ... dans le brouillard).
Mon système idéal est pour moi FreeBSD, c'est pour moi l'informatique avec un grand I, mais il me manque certaines connaissances et je me rabats sur des solutions plus simples (le rêve serait pour moi VxWorks, mais ce sera peut-être dans une autre vie, j'ai été un grand passionné de robotique a une époque, ça explique sans doute la chose).
Il m'est déjà arrivé de me poser la question pour utiliser ZFS directement sous FreeBSD et pourquoi avec vbox dessus, mais vbox en Linux est bien aboutit et mieux suivi. Idem pour Nas4Free, c'est pour moi un système en mouvement qui vit bien "sa vie", tout ça marche déjà et est opérationnel.
En fait, pour tous les sytèmes que j'utilise, j'utilise une méthode de "ça marche ou ça dégage", c'est à dire que je veux des éléments qui ne montre aucune défaillance, c'est pour celà que mon dernier windows a été 95, et qu'il y a quelques années je suis passé de Fedora & Ubuntu à Debian (car j'avais des lenteurs inexpliqués, attention Ubuntu évolue est se corrige depuis ... pas de polémique!).
Pour Nas4free, je n'ai jamais eu de soucis, hormis ce pb de mémoire qui était réglé à 330To de RAM d'origine et qui faisait des reboot lorsque j’accédais a des fichiers plus gros que la RAM.
Cela fait plusieurs années que j'utilise Nas4free (qui avant était Freenas).
J'ai eu utilisé l'UFS mais je me suis aperçu qu'on pouvait perdre des données dans certaines circonstances, je plaçais l'UFS+SU sur un pied d'estale et je l'utilisais sur FreeBSD et Freenas à l'époque, mais j'ai perdu des données a deux reprises.
Pour ZFS, on peut lire des "il faut" ou des conseils, dans mon cas, je fais simple: je mets une structure en place, je lance des copies de fichiers et je coupe le courant ou je débranche des fils, si ça tient, alors j'utilise, et si un jour ça marche pas, j'y fais des "gros yeux méchants" et je place symboliquement le zinzin au bord du précipice et dès la moindre faute, je pousse !. Bref, cela fait des années que j'ai mon nas perso en raid0, il a subit pleins de coupures de courant (dont certaines par erreurs de ma part), il marche très bien et j'en suis très content. Après il y a le "pourquoi", si l'on regarde l'aspect technique et la conception de ZFS, alors, on peut comprendre aisément que l'on a à faire au un FS évolué conçu avec une technologie de base de donnée (venant d'Oracle rien d'étonnant). Je suis conscient que j'ai pu ne pas avoir de soucis personnellement, mais que d'autres puissent en avoir (tu dis que l'équipe de développement a du mal quelquefois et que le système n'est pas encore finalisé et est potentiellement dangereux en production), soit, mais moi, je préfère voir un défaut (vu et reproductible) plutôt qu'une hypothèse. Pour moi (et ça n'engage que moi), ZFS est plus solide que n'importe quel autre FS.
Il est possible que du coté de Nas4free la gestion ne soit pas encore au point, dans ce cas, c'est pas grave, car je n'utilise pas l'interface web de Nas4free, je fais juste un import et ensuite je fais tout en ligne de commande, cela supprime pour moi cette couche qui pourrait être gênante, pour le reste, il n'y a pas moult versions de ZFS, le risque est donc limité.
J'aime ZFS mais aussi BTRFS, je ne me suis pas penché sur la question, c'est un cousin proche de ZFS qui m'intéresse aussi, toutefois, je laisse "un peu d'eau couler sous les ponts" pour le mettre peut-être en service dans mes debian.
Voilà en grande partie mon raisonnement, un mix de recherche du meilleur avec une sensation de performance qui n'engage que moi (vivacité dans la virtualisation par exemple)
Tu as raison dans tes analyses, mais sache que tout le monde ne se contente pas d'essais hypothétiques avec juste un clic sur icône.
Ce qui est intéressant sur un forum, c'est de trouver une solution, mais aussi partager des avis, des expériences.
J'ai d'autres volets a explorer, il me manque de grosses pierres a ajouter (base de données, script-CGI, ... )
Ce texte est "un peu" lié quand même à l'iscsi et vbox, c'est pour ça que je le publie, désolé pour absys44 de m'étendre un peu (beaucoup) dans son fil de discussion.
