bonjour à tous,
j'ai une question concernant le VCM:
Si le VCM tombe, est-ce que ca empêchera le DRS, HA & Vmotion de fonctionner?
en gros ma question est: est-ce que c'est le VCM qui gère ces modules ou s'il tombe les ESX sauront basculer automatiquement les VM;...?
 
merci de m'ôter ce doute  
 
 
 
edit: ortho

- Le VC n'empêche pas le cluster HA de fonctionner. Tu te sers de VC pour le créer (une config locale est écrite), ensuite ils se gèrent entre eux via heartbeat et actions préprogrammées.  
- le DRS, ne marche plus
- Vmotion sans VC  (hors HA) est difficile, tu en conviendras .
 
Maintenant ton VC n'est pas vraiment très critique dans l'infra, toutes les parties critiques restent fonctionnelles. Si ton VC tombe, réinstalle le simplement.  
La meilleur solution (avis perso) est un DB sur un serveur physique, backupé comme un DB de prod, et une VM sur un VM server ou ESXi à part de ton infra ESX.
Mettre VC sur le système est tout à fait supporté, mais j'ai perso du mal avec le fait d'avoir mon interface de management sur le même système que le système
à manager.
 
Deux remarques si tu te lances la dedans, (fait des recherches dessus)
1/ seul les 5 premiers nodes sont primaires=max 4 nodes failure
2/ depuis la version 3.5 Update 3, le comportement des nodes isolé à changé. Si network down et lock sur les vmdk, les VM restent activent sur le host (il est isolé mais pas down). Avant c'était un basculement d'office. Pour moi c'est mieux, sauf bien sur en cas de iScsi (elles basculent pas, faut changer le comportement initial)

merci pour ton éclaircissement.
je ne savais pas que le HA pouvait se passer du VCM.
d'accord avec toi,je en suis pas partisan du VCM en tant que VM...en tant que superviseur d'infra il se doit d'être physique. je le considère comme élément critique chez nous
 
merki

Disont que VC sert à créer le cluster (lui seul voit tous les hosts) mais qu'ensuite le HA peut marcher sans VC    
 
Le mettre en machine physique me semble le bon choix, mais comme Vmware supporte un VC dans une VM à 100%...on peut aussi dire qu'il n'y pas de raison de s'en priver.
Mon avis est basé sur le fait qu'une machine simple en plus quand on a déjà un systeme ESX HA, ca fait pas bcp de poid ds le budget.
 
Tant qu'on en parle, je vais ajouter une petite contradiction: en fait je ne met pas VC dans une VM sur les hosts qu'il gère mais...dans très peu de temps un upgrade va me faire prendre un autre scénario. Je garde la séparation des ESX gérés et du Vc sur machine physique séparé mais...j'installe sur ce serveur physique séparé ESXi
Le but? Cet ESXi ne fait pas partie du système, mais vu qu'il est gratuit ca va me permettre de mettre VC dans une VM et séparement l'update manager dans une autre. En cas de problème avec le serveur VC, il est facile d'en trouver un autre, peu importe le hardware: je remet ESXi dessus et ma VM VirtualCenter
 
Encore une fois ce sont des choix, mais si ca peut aider  

merci de ton retour.

Perso, je suis plutôt partisan du VC en VM. Le tout est d'assurer la sauvegarde de la base de données du VC (essentiel!) et de préparer un VC cloné pour parer à toute éventualité et retrouver une situation fonctionnelle le plus vite possible. Car il ne faut pas oublier que la gestion des resources et des permissions passe par le VC et que son indisponibilité peut poser rapidement des problèmes. Pour contre, je préconiserai de désactiver le DRS sur la VM VC.

Ce n'est que le comportement par défaut qui a changé... Quoiqu'il en soit, pour HA, la préconisation est de régler les VM hébergées sur du stockage IP (iSCSI et NAS) sur "power off".

l avantage a mon sens d avoir VC sur une VM et non sur un physique est le meme que pour toute VM ... si ca plante, tu recup le snapshot de ta VM avec VC dessus et hop, tout beau tout propre.... en theorie .
L'ideal meme c est d allouer une carte physique uniquement pour ton VC et la console d'admin, comme ca, tu te retrouve avec un petit reseau independant avec un seul poste dessus. Niveau securite c est pas mal je trouve

Pour avoir mis un peu le nez dans ESX, je reste assez sur les fesses par les possibilités offerte par ce systeme. Vraiment tres interessant

On peut utiliser du NAS pour stocker les VM ?? Je pensais que le SAN etait preconiser pour ca.

Pas forcément, tu as de bonnes perfs en NAS aussi.
 
Et sans rentrer dans les détails (j'suis pas admin VM) mais d'après les retours que j'ai, accéder à des fichiers vmdk via des liens NFS c'est plus facile à administrer/gérer.
 
J'en sais pas plus, je suis pas spécialiste VM.
 
Après même si c'est du NAS, tu peux très bien avoir des disques SAS ou FC derrière. La seule différence avec l'accès via un SAN, c'est le protocole utilisé (mode bloc ou mode fichier).
 
Et si tu utilise du iSCSI, même si c'est un accès en mode bloc, tu passe par le réseau GBE comme pour le NFS.

Yes. D'ailleurs, Netapp a sorti récemment une étude pour démontrer que pour un prix très inférieur au FC et au iSCSI, un NAS pouvait avoir des perfs pas si éloignées que ça des deux stockages cités précédemment. Certes, c'est du bench, il faut donc prendre ça avec un certain recul (c'est pas toujours vrai, tout dépend de l'utilisation effective des VMs) mais le NAS n'est pas non plus un stockage si lamentable que certains le pensent. En outre, oui, une VM peut être hebergée sur un NAS et peut être prise en compte par vMotion, donc par DRS, et par HA.  
Dernière remarque au sujet du NAS: VMware a récemment fait disparaitre sa recommandation d'éviter formellement le swap vmkernel sur du NAS. Certes, VMware continue de dire qu'il vaut mieux éviter le swap VMkernel (quelque soit le support FC, iSCSI, NAS), mais qu'il n'y a plus lieu de faire un distingo entre ces 3 types de stockages. De toute façon, il vaut mieux privilégier le swap GOS plutot que le swap VMkernet, ça a tjs été vrai.

Attention: le mode snapshot n'est pas qq chose à utiliser en régime de croisière (surtout dans les environnements de prod, ça serait une hérésie)! IL peut y avoir des conséquences en termes de performances et ça ne sert A RIEN pour le VC puisque toutes les données sont stockées dans la base du VC. Donc, la bonne pratique c'est : 1/ Clonage du VC server de manière à pouvoir repartir immediatement en cas de plantage GOS ou VC et 2/ sauvegarde régulière de la base du VC. Point.

 
Petite remarque, à priori les VM accédéeq en NFS sur du NAS ne sont pas compatibles avec SRM pour les basculements PRA (pas testé, info fournie par NetApp).

exact, vu que SRM est basé sur la réplication des LUNs.
de toute façon, pour SRM, toutes les baies FC et ISCSI ne sont pas nécessairement compatibles, vu que le constructeur doit fournir un SRA qui doit interfacer la baie avec SRM.

   
Y a un truc que je pige pas là ...
Les données des Vm ne sont en aucun cas situé dans la base du Vc ...  
Et ton architecture peut très bien tourner sans Vc (certes sans HA ni DRS ).
Perso mon Vc m'importe peu en tant que machine, elle tombe, je reinstalle .

Certes, sauf que les données du VC (le paramétrage de l'infrastructure) ne sont pas stockées dans la machine VC, mais dans la base de données du VC, qui généralement n'est pas installée sur la même machine que le VC. Donc, la machine VC est quasiment un "invariant" que l'on peut cloner et conserver "sous le coude" au cas où....
Oui, l'architecture peut fonctionner sans le VC, mais si tout le paramétrage des ressources disparait parceque la base du VC disparait, eh bien il faudra tout reparamétrer (limites, reservations, shares, ressources pools, clusters DRS et HA, alarmes etc.), travail dont on peut se passer.

Ok je croyais que tu parlais données VM alors que tu etais données Infrastructure.
Oki perso ma DB est situé sur mon VC, je fais un dump quotidien .. Mais a vrai dire je n'utilise que DRS dans un cadre de test, seul HA est la partie critique de mon VC .
++