Etant débutant non informaticien, et après recherches sur Google et autres sans réponse claire, je viens vous soumettre ici une question d’ordre très général que je me pose (mais je la pose pour optimiser le fonctionnement de ma VM Jeedom).
Voici :
Pour gagner en performance sur Jeedom (mais pas que), j’envisage de monter un cluster proxmox.
Savez vous si les threads d’un cluster sont mutualisables pour une VM Jeedom. Expl : j’ai 2 nodes de 2 coeurs/4 threads chacun => est-ce que je peux affecter 3 coeurs/6 threads à une VM Jeedom alors que mon plus petit node n’a que 2 coeurs ?
Même question pour la mutualisation de la RAM de mes nodes, pour en affecter plus par addition à la VM Jeedom ?
question subsidiaire plus spécifique à Jeedom : je sais que Jeedom consomme peu de ressources mais admettons que je veuille un Jeedom qui réagisse à la vitesse de la lumière, est ce que le fait de lui attribuer plus de coeurs/threads va vraiment faire une différence?
Olive, merci pour ta réponse. Malheureusement, elle n’est pas complètement claire pour moi. J’ai bien vu qu’on affectait des coeurs à une VM mais ma question est : pour une VM installée dans un cluster sur un node Proxmox, peut-on lui affecter « en renfort » les ressources d’un autre node, lui faire profiter de coeurs additionnels ou de RAM additionnelle.
Ou bien le fait d’être installée dans un cluster n’apporte à la VM que le bénéfice de la haute disponibilité, mais pas de mutualisation de la puissance de calcul des différents matériels du cluster?
Ta réponse semble dire que j’affecte un coeur ou que j’alloue de la mémoire un peu comme je veux, mais je voudrais être vraiment sûr. Car dans l’affirmative, c’est plus intéressant d’acheter des petites machines à mettre en cluster plutot qu’une seule « grosse » (et chère) avec plus de ressources.
non, je ne pense pas, une VM tourne sur une instance (un noeud) du cluster, pas sur plusieurs (et ca serait beaucoup trop lent, imagine les accès ram ou pire CPU à travers le réseau)
Oui, affecter plus de coeur apporte une différence notable.
Après, de manière général, en virtualisation il faut faire attention à ce type de config: cela ne sert à rien d’oversize toutes tes vms au max du noeud « parce que tu as les coeurs »
C’est même contre-productif parce que si 4 machines ont le droits aux quatres coeurs de la machine physique (par exemple), cela va en fait les ralentir car chacune d’elles va devoir « attendre » la dispo des coeurs pour faire ses taches (alors que l’une aurait eu assez avec 1) car ils sont utlisés par les autres vms;
en bref, il y a concurrence inutile entre les vms pour avoir les ressources.
Alors que si tu as 4 machines utilisant chacune 1 coeur sur une machine physique ayant 4 coeurs, il n’y pas de concurence.
C’est une vision simplifiée évidement, le problème est plus complexe (et je ne suis pas expert non plus) mais l’idée est là.
Bonjour @Mips, merci pour ta réponse. C’est déjà plus clair pour moi.
Je me posais la question car les scientifiques par exemple mutualisent à travers le monde via internet des machines pour concevoir des supercalculateurs, mais j’admets bien volontiers que ça doit être très différents comme architecture, genre client/serveur, traitement asynchrone etc… donc pas comparable. Mais je me demandais si le même genre de mécanisme existe au sein d’un cluster. Mais soit, tu as l’air de penser que non.
Conséquence : si je dois investir dans une machine pour monter un hyperviseur Proxmox, et que la haute disponibilité des services n’est pas le coeur de ma préoccupation, mais plutot la performance, il vaut mieux acheter une machine avec beaucoup de coeurs et de RAM (plutôt que plusieurs petites à budget équivalent) si je veux avoir une VM Jeedom dessus, avec beaucoup de coeurs qui lui seraient réservés. Exact ?
En fait, dans mon raisonnement, par exemple avec une machine 6 coeurs, j’en aurais mis 4 pour Jeedom et 1 pour une autre petite VM et 1 pour une autre par exemple…
l’idée était bien de « dédier » les coeurs à telle ou telle VM. Toutes mes VMs « ne se valent pas » et même si elles sont trois, je préfère que Jeedom soit la mieux lotie, les autres sont plus accessoires.
Non, pas des « supercalculateurs », plutôt des calculs très simple à faire mais énormément et on s’en fou du délai généralement, genre ceux pour « écouter les signaux reçu de l’espace » de toute façon l’événement est passé déjà;
donc oui, c’est mieux de ne pas prévoir une trop petite config;
après le choix final du nombre de coeur par vm dépend fort de ta config (un coeur n’est pas un autre), de la charge que jeedom a (gérer 4 prises connectées ne va pas demander une super puissance ) etc mais c’est facilement adaptable.
my 2 cents, je trouve qu’on est plus vite limité par la ram que par le cpu, perso je regrette de ne pas avoir pris plus de ram…
sinon pour te donner un exemple, j’ai +220 équipement, +2200 commandes, +100 scénarios et jeedom tourne très bien dans une vm avec 2 coeurs sur proxmox sur un nuc i5 7gen
A coté de jeedom, j’en ai d’autres en fait pour dev et test les plugins, et 2 autres machines juste un coeur et moins de ram voir très peu de ram
) etc mais c’est facilement adaptable.