Recherche Logiciels de Virtualisations spécifiques

[wandazefish]

J'avais vu au début de mes recherches qu'il y avait deux types d'hyperviseurs. Mais moi quand j'ai fait des recheches je n'ai plus trop regarder ca, si on me dit qu'un hyperviseur de type 2 résoud mon problème de répartition des charges comment je peux dire que ce n'est pas le bon outil?

A la limite, tu peux prendre le système Windows le plus surdimensionné, installer dessus un "hyperviseur type II", et lui faire héberger plusieurs VM. Quelles conséquences?
- si l'hôte tombe en panne (panne du matériel ou du système!), toutes les VM hébergées sont en panne!
- on n'a pas de cluster, donc en cas de grosse panne matériel, on ne pourra pas relancer facilement les VM sur un hôte différent!
- et la "répartition des charges", on la fixe au départ en choisissant quelles VM l'hôte hébergera, de façon quasi définitive.

Le problème, c'est que le noyau du système hôte ne propose pas de file system partageable, indispensable pour monter un cluster. Tout au contraire, un "hyperviseur de type I" comme ESX propose d'emblée un file system (VMFS) conçu pour le clustering.

Sans parler des médiocres performances des entrées-sorties, dans le 1er cas sous-traitées au système hôte avec ce que ça implique de surconsommation CPU, alors que dans le 2ème elles bénéficient de drivers optimisés...
-----

[invite5420aad7]

A la limite, tu peux prendre le système Windows le plus surdimensionné, installer dessus un "hyperviseur type II", et lui faire héberger plusieurs VM. Quelles conséquences?
- si l'hôte tombe en panne (panne du matériel ou du système!), toutes les VM hébergées sont en panne!
- on n'a pas de cluster, donc en cas de grosse panne matériel, on ne pourra pas relancer facilement les VM sur un hôte différent!
- et la "répartition des charges", on la fixe au départ en choisissant quelles VM l'hôte hébergera, de façon quasi définitive.

Le problème, c'est que le noyau du système hôte ne propose pas de file system partageable, indispensable pour monter un cluster. Tout au contraire, un "hyperviseur de type I" comme ESX propose d'emblée un file system (VMFS) conçu pour le clustering.

Sans parler des médiocres performances des entrées-sorties, dans le 1er cas sous-traitées au système hôte avec ce que ça implique de surconsommation CPU, alors que dans le 2ème elles bénéficient de drivers optimisés...

Je comprend bien, mais je me suis heurté à un plus gros problème encore c'est que tous nos serveurs sont 32 bits, et les solutions de virtulisation que j'ai pu voir, ceux qui associe "virtualisation + clustering" sont 64 bits.
J'ai comme l'impression d'être revenu au point de départ : trouver une solution autre que logciel de "virtualisation + clustering"

[invite5420aad7]

En fait si il y en a qui connaissent un lggiciel qui associe "virtualisation + clustering" et qui est compatible 32 bits, il peut se manifester?

[wandazefish]

tous nos serveurs sont 32 bits

Il faut préciser ce qu'on entend par "serveur 32 bits":
- est-ce la machine qui est équipée de processeurs 32 bits? Dans ce cas elle est trop ancienne: on ne pourra ni l'intégrer à un cluster avec répartition de charge dynamique-et-tout-et-tout, - ni la faire évoluer . Mais on pourra virtualiser ce serveur, et l'héberger sur une machine 64 bits.
- est-ce l'OS du serveur qui est "32 bits", alors que les processeurs sont "64 bits" ? Dans ce cas, on pourra pareillement virtualiser ce serveur. On pourra aussi - théoriquement et avec les réserves précédentes: homogénéité du parc, remaniement des infrastructures réseau et de stockage, planification des changements - installer sur cette machine un hyperviseur 64 bits et l'intégrer à un cluster.

Donc AMHA cette recherche d'un hyperviseur 32 bits est sans objet.

D'ailleurs ESX/ESXi 3.5 doivent fonctionner sur des processeurs 32 bits http://fr.wikipedia.org/wiki/VMware mais d'un point de vue pratique je ne vois pas trop l'intérêt

[invite5420aad7]

Il faut préciser ce qu'on entend par "serveur 32 bits":
- est-ce la machine qui est équipée de processeurs 32 bits? Dans ce cas elle est trop ancienne: on ne pourra ni l'intégrer à un cluster avec répartition de charge dynamique-et-tout-et-tout, - ni la faire évoluer . Mais on pourra virtualiser ce serveur, et l'héberger sur une machine 64 bits.
- est-ce l'OS du serveur qui est "32 bits", alors que les processeurs sont "64 bits" ? Dans ce cas, on pourra pareillement virtualiser ce serveur. On pourra aussi - théoriquement et avec les réserves précédentes: homogénéité du parc, remaniement des infrastructures réseau et de stockage, planification des changements - installer sur cette machine un hyperviseur 64 bits et l'intégrer à un cluster.

Donc AMHA cette recherche d'un hyperviseur 32 bits est sans objet.

D'ailleurs ESX/ESXi 3.5 doivent fonctionner sur des processeurs 32 bits http://fr.wikipedia.org/wiki/VMware mais d'un point de vue pratique je ne vois pas trop l'intérêt

C'est de loin la première réponse qui me donne un peu d'espoir.
Les processeurs sont 32 bits et les OS aussi 32 bits.
Quel intérêt aura-t-on à virtualiser les serveurs si on ne peut pas apporter de solution de clustering?
On virtualise le serveur 32 bits et on l'installe sur uen machien 64 bits (don on achète un nouveau serveurs). Mon tuteur m'expliquait que si ils n'ont acheté que des serveurs 32 bits c'est que leurs applications sont compatibles 32 bits.
Est-ce qu'une application compatible 32 bits ne peut pas l'êtr aussi pour 64 bits?

[polo974]

...
Les processeurs sont 32 bits et les OS aussi 32 bits.

Pour le os, ok, mais les processeurs c'est à vérifier...

...
Est-ce qu'une application compatible 32 bits ne peut pas l'être aussi pour 64 bits?

si

[wandazefish]

Quel intérêt aura-t-on à virtualiser les serveurs si on ne peut pas apporter de solution de clustering?

Dans ce cas, on "consolide" - ==> moins de serveurs physiques - au risque que la panne d'un serveur physique devienne bien plus grave, puisque davantage d'applications seront impactées. Ca peut être tolérable pour des serveurs de développement/recette. Mais c'est complétement à contre-courant des objectifs d'un environnement de production. On peut redonder les composants des serveurs pour qu'ils résistent aux pannes (alimentation, cartes réseau et HBA, disques RAID...) mais les serveurs restent vulnérables aux pannes de carte mère, de mémoire, de rack... ou d'hyperviseur!

C'est de loin la première réponse qui me donne un peu d'espoir.

Alors, je n'ai pas été assez clair... et je dois apporter quelques précisions.
- ESXi (alias vSphere Hypervisor) peut être téléchargé gratuitement, et autorise la consolidation. Mais la mise en cluster est soumise à l'achat de licences.
- la licence est liée à un processeur physique (on trouve aussi "socket"). Le prix de la licence est le même pour un processeur dual-core d'il y a 5 ans, ou pour le dernier processeur 8-core .
- petit exemple rapide:
==> 10 serveurs bi-pro dual-core ==> 20 licences pour 40 processeurs logiques
==> 2 serveurs bi-pro 8-core ==> 4 licences pour 32 processeurs logiques.

...Si on ajoute les coûts de maintenance des serveurs et des logiciels, les coûts et les risques liés à une connectique complexe, la consommation électrique, la climatisation...,
...Si on considère qu'une "solution" du type "serveurs 32 bits + ESXi 3.5" est non-évolutive et obsolète avant même sa mise en service...
on voit l'urgence de ne pas se précipiter et de reconsidérer la problématique dans son ensemble.

Donc je suggère un retour aux fondamentaux de la gestion de projet:
- cadrage du projet: objectifs, limites, coûts, délais, risques...
- étude minutieuse de l'existant (le diable est dans le détail)
- élaboration de plusieurs scénarios chiffrés
Un avant-projet bâclé, c'est l'assurance d'un projet foireux...

[invite5420aad7]

Dans ce cas, on "consolide" - ==> moins de serveurs physiques - au risque que la panne d'un serveur physique devienne bien plus grave, puisque davantage d'applications seront impactées. Ca peut être tolérable pour des serveurs de développement/recette. Mais c'est complétement à contre-courant des objectifs d'un environnement de production. On peut redonder les composants des serveurs pour qu'ils résistent aux pannes (alimentation, cartes réseau et HBA, disques RAID...) mais les serveurs restent vulnérables aux pannes de carte mère, de mémoire, de rack... ou d'hyperviseur!



Alors, je n'ai pas été assez clair... et je dois apporter quelques précisions.
- ESXi (alias vSphere Hypervisor) peut être téléchargé gratuitement, et autorise la consolidation. Mais la mise en cluster est soumise à l'achat de licences.
- la licence est liée à un processeur physique (on trouve aussi "socket"). Le prix de la licence est le même pour un processeur dual-core d'il y a 5 ans, ou pour le dernier processeur 8-core .
- petit exemple rapide:
==> 10 serveurs bi-pro dual-core ==> 20 licences pour 40 processeurs logiques
==> 2 serveurs bi-pro 8-core ==> 4 licences pour 32 processeurs logiques.

...Si on ajoute les coûts de maintenance des serveurs et des logiciels, les coûts et les risques liés à une connectique complexe, la consommation électrique, la climatisation...,
...Si on considère qu'une "solution" du type "serveurs 32 bits + ESXi 3.5" est non-évolutive et obsolète avant même sa mise en service...
on voit l'urgence de ne pas se précipiter et de reconsidérer la problématique dans son ensemble.

Donc je suggère un retour aux fondamentaux de la gestion de projet:
- cadrage du projet: objectifs, limites, coûts, délais, risques...
- étude minutieuse de l'existant (le diable est dans le détail)
- élaboration de plusieurs scénarios chiffrés
Un avant-projet bâclé, c'est l'assurance d'un projet foireux...

Bon à lire ça effectivement mon niveau de gaieté redescend beaucoup.
C'est vraiment le contraire de ce que mon tuteur veut.
Enfin disont que lui ne veut pas faire une "restructuration complète de son parc informatique. les serveurs qu'il a je pense qu'il veut les conserver. Après on est pas obligé de tous les virtualiser.

- cadrage du projet: objectifs, limites, coûts, délais, risques... => objectif trouver un logiciel qui allie "virtualisation + clustering"
coûts => le coût du logiciel
délais => au moins deux mois, après j pense pouvoir déléguer ce que j'ai fait. Le principal est que j'amorce le projet et qu'au moins j'arrive jusqu'à la phase de tests
risques => je ne sais pas du tout

- étude minutieuse de l'existant (le diable est dans le détail)
un consultant en virtualisation (d'ailleur j'invite tous ceux qui sont intéressé par la virtualisation à consulter son blog qui est très bien fait : http://vpourchet.wordpress.com/), m'a redirigé vers un logiciel Microsoft Assesment Planning Toolkit qui me permettrait de faire un audit d'éligibilité du matériel, maintenant j'attend le feu vert de mon tuteur pour le télécharger, j'en ai jamais fait ce sera uen grande première

- élaboration de plusieurs scénarios chiffrés
alors là vraiment je ne vois pas, je n'arrive pas à voir quelle genre de scénario je pourrais avoir à mettre en place.

[invite5420aad7]

On ne voit pas bien ce qu'Unix vient faire là dedans... (j'ai aussi vu: Mac, BSD, Linux...)

En entreprise, il n'y a pas de place pour l'informatique capricieuse: on ne change pas de système sur un simple "yaka" !

L'un des intérêts de la virtualisation, ça peut justement être de NE PAS changer de système ! - Même si par ailleurs, à peu près toute l'infra-structure change...

Pour l'installation d'ESX, je t'invite à poursuivre, sur l'autre topic, avec l'étude de l'existant: contrôleurs de disques, cartes HBA, SAN, interfaces réseau... Les processeurs Xeon 3040 doivent supporter ESXi 4.1 (en 64 bits), mais c'est loin d'être le seul pré-requis...

Oui, effectivement.
Disons que je suis en attente pour avoir accès à toutes ces informations. Sinon oui finallement je pense aussi que le processuer peut supporter ESXi 4.1(en 64 bits), mais est-ce que l'OS lui ne posera pas problème? Windows Server 2003 Edition standard (32 bits).

[polo974]

Envoyé par wandazefish
On ne voit pas bien ce qu'Unix vient faire là dedans... (j'ai aussi vu: Mac, BSD, Linux...)

En entreprise, il n'y a pas de place pour l'informatique capricieuse: on ne change pas de système sur un simple "yaka" !
...

A part que vmware est basé sur un linux.

Et question informatique capricieuse, bricosoft remporte le trophée haut la main.

Les yaka, il faut les tester hors prod, avant de (ne pas) tout casser...

[invite1445654e]

A part que vmware est basé sur un linux.

Et question informatique capricieuse, bricosoft remporte le trophée haut la main.

Les yaka, il faut les tester hors prod, avant de (ne pas) tout casser...

informatique capricieuse = gnousoft ?
je me souviens à une époque on était obligée de forcer le redémarrage des serveurs NT chaque nuit pour qu'ils fonctionnent comme il faut ....

[invite5420aad7]

A part que vmware est basé sur un linux.

Et question informatique capricieuse, bricosoft remporte le trophée haut la main.

Les yaka, il faut les tester hors prod, avant de (ne pas) tout casser...

En fait il a raison parce qu'on ne change pas un OS comme ça du jour au lendemain (en tout cas pas dans uen entreprise). Je pense qu'ils vont vouloir garder windows, donc je voulais savoir si je pouvais installer un logiciel de virtualisaion VMware ESX 4.1 malgré un OS windows 32 bits, sachant maintenant que mes serveurs eux sont 32/64 bits.