Archive pour la Catégorie: ‘vCenter

0 article trouvé dans cette archive
Fév/1370

Il y  a 2 semaines VMware a sorti vCenter Support Assistant 5.1 en GA. Un plug-in gratuit pour vCenter qui fournit un outil intégré à vSphere pour la création et la gestion d’incident. A la fois facile à utiliser, sécurisé, avec la génération et le téléchargement automatique des fichiers de logs lors de la création d’un incident SR (Support Request). Il intègre également la capacité de recherche dans la base de connaissances (KB) de VMware afin de permettre une résolution des problèmes communs plus rapidement.
Ainsi la collecte automatique de davantage d’informations dès l’ouverture d’un incident permet de minimiser les échanges initiaux avec le support VMware.
vCenter-Support-Assistant

Lire la suite…

Juil/1122

Avec la sortie de vSphere 5, le vCenter a sa version Virtual Appliance: « vCenter Server Appliance (vCSA) ». Bien entendu la version Windows continue d’exister assurer la continuité avec les précédentes versions et pour les installations physiques. Mais la avec cette version (tant demandé par la communauté), le composant central de l’infrastructure vSphere devient indépendant de Microsoft (et de sa licence) mais surtout les mises à jours en sont simplifiées: mise à jour comme toute autre Virtual Appliance avec UpdateManager. Cette Virtual Appliance est un serveur Linux qui contrairement à la précédente tentative (vCenter server 2.5 en Linux) n’a que peu de limitation en terme de fonctionnalité.

Lire la suite…

Juil/11180

Dans vSphere 5, l’interface d’administration Web a été complément revu. La précédente version était lente et très limité, je pense que personne ne l’utilisait (sauf peut-être pour les URL consoles). Cette nouvelle version qualifiée de « Next Generation Flex Client » et appelé « VMware vSphere Web Client » a été complètement ré écrit en Adobe Flex (comme les interfaces de View et vCloud Director). Pour le moment l’interface Web ne remplace pas 100% des fonctionnalités du client vSphere pour Windows mais elle remplit une grande partie des fonctionnalités. Elle permet donc de :

  • centraliser les interfaces d’administration de plusieurs vCenter
  • faire du SSO (inter vCenter)
  • intégration du client en tant que plugin (IE & Firefox)
  • personnaliser l’affichage: créer des vues personnalisées
  • l’accès rapide aux taches standard
  • faire des recherches avancées (et de les enregistrer) à travers plusieurs vCenter
  • extensibilité des fonctionnalités: possibilité d’ajouter des fonctions par un Framework de développement, grâce aux points d’extension riches natifs Linux (contrairement au plugin Html pour le client windows)
  • Gestion des VMs: Provisionning de VM /Edit Settings, Power Operations, Snapshots & migrate VMs / Gestion des Ressources VMs / Vue de tous les objets vSphere (Host, Clusters, DataStores , Folder …)
  • avoir une vue basique du Health Monitoring
  • se connecter à la console des VMs
  • gérer les vApps: Provisionning de vApps, Edit Settings, Power Operations
  • avoir un client indépendant des plateformes
  • prise en charge des flux de travail avec interruptions: possibilité de reprendre une action interrompue sans répéter le processus entier

Cette interface Web est un composant additionnel de vCenter pour Windows: « vSphere Web Client (Server)« , il peut donc être déporté sur un autre serveur si besoin.

Lire la suite…

Juin/1190

Généralement, en vue d’un PRA, l’infrastructure est déportée sur 2 salles. Et souvent, on part sur un premier stockage dans une salle, puis on le sécurise avec un autre dans la salle de secours. Mais la gestion en reste de façon globale aux 2 salles (infrastructure horizontale), ce qui est un bon début pour un PRA mais pas forcément automatisé.

Le produit VMware Site Recovery Manager est un produit gérant l’ordonnancement du PRA. Pour cela, il faut avoir un stockage (compatible SRM) répliqué entre 2 salles et surtout il faut que l’infrastructure virtuelle soit scinder en 2 salles pour qu’elles puissent fonctionner de façon autonome (permettant de faire repartir la Prod dans l’autre salle). Et c’est la qu’une évolution progressive d’une infrastructure virtuelle en vue d’un PRA, ne correspond pas à une architecture convenable pour SRM. C’est la justement qu’il va falloir verticaliser l’infrastructure pour la rendre compatible SRM.

Je ne vais pas m’étendre sur les pré-requis stockage ni d’installation de SRM. En partant d’un exemple concret, je vais plutôt expliquer le mode opératoire pour basculer une infrastructure virtuelle horizontale vers une infrastructure virtuelle verticale.

Donc partons de l’exemple ci-dessous, qui contient un premier vCenter dans une salle qui administre un ensemble de serveurs ESX pour les VMs Serveurs formant un Cluster entre 2 salles et un second vCenter dans l’autre salle qui administre un ensemble de serveurs ESX pour des VMs View formant un Cluster entre 2 salles:

Lire la suite…

Juin/1170

Pour des diverses raisons (dissociation géographique, mise en place de PRA…) il est possible que l’on souhaite séparer une infrastructure virtuelle en 2 instances vCenter. Cette opération était assez simple en vCenter 2.x (copie de la base et nettoyage des objets obsolètes). Avec la version vCenter 4.x c’est plus compliquée du fait des traces restantes dans la base ADAM. Il existe une procédure (Cf. KB1031846) qui permet de réaliser cette opération en nettoyant les relations avec l’ADAM, ce qui permettra de lier les 2 vCenters en Linked-Mode. 

Voici le mode opératoire pour séparer en 2 vCenter:

  1. Préparer le serveur pour le second serveur vCenter
  2. Créer une nouvelle base de donnée vierge sur le second vCenter 
  3. Créer la liaison ODBC (DSN) sur le second vCenter
  4. Copier les certificats SSL du premier vCenter sur le second (dans « C:Documents and SettingsAll UsersApplication DataVMwareVMware VirtualCenterSSL« )
  5. Installer vCenter sur le second serveur
  6. Arrêter les services du second vCenter (« VMware VirtualCenter Server » & « VMwareVCMSDS« ) 
  7. Exporter les permissions & les rôles du premier vCenter (exécuter en PowerCLI le script export-permissions-roles.ps1sur le premier vCenter)
  8. Déconnecter tous les ESXs (faire un « Remove » puis un « Disconnect« )
  9. Arrêter les services du premier vCenter (« VMware VirtualCenter Server » & « VMwareVCMSDS« ) 
  10. Sauvegarder la base de données du premier vCenter
  11. Restaurer sur la base de données du second vCenter (écraser la base vide)
  12. Supprimer les données de la table « VPX_BINARY_DATA » du second vCenter (avec la commande SQL « TRUNCATE Table dbo.VPX_BINARY_DATA« )
  13. Démarrer les services des 2 vCenters (« VMware VirtualCenter Server » & « VMwareVCMSDS« ) 
  14. Changer l’Unique ID et le vCenter Server Name du second vCenter (dans « vCenter Server Settings > Runtime Settings« )
  15. Redémarrer les services du second vCenter (« VMware VirtualCenter Server » & « VMwareVCMSDS« ) 
  16. Supprimer dans chaque vCenter les DataCenters/Clusters obsolètes
  17. Reconnecter les serveurs ESX dans chacun des vCenters
  18. Importer les permissions & les rôles sur le second vCenter (exécuter en PowerCLI le script import-permissions-roles.ps1sur le second vCenter) avec le fichier « vInventory.xml » généré lors de l’export
  19. Et optionnellement joindre le second vCenter au premier en Linked-Mode (avec l’assistant « vCenter Server Linked Mode Configuration« )

Lire la suite…

Juin/1170

La fonction Linked-Mode permet de lier plusieurs vCenter entre eux pour avoir une vue globale des vCenters.

Lors de la junction d’un vCenter en Linked-Mode, si vous avez l’erreur 28039: « Setup cannot join vCenter Server to linked mode group ». 

Lire la suite…

Mai/11310

La Haute Disponibilité (High Availability) ou HA chez VMware n’est pas une nouveauté. C’est toujours la possibilité de redémarrer une VM qui était sur un ESX sur un autre noeud d’un Cluster. Suite à un problème, un ESX du cluster est identifié comme hors service, ses machines virtuelles sont alors redémarrées sur un autre ESX du cluster tant que les ressources le permettent ou que la politique mise en place le tolère.

Comment est-il diagnostiqué qu’un ESX n’est plus en ordre de délivrer son service ?

Sur une simple absence de communication avec les autres ESX du cluster.

Les serveurs hôtes d’un cluster HA s’échangent un Heartbeat chaque seconde (valeur par défaut). Au delà de 15s sans échanges d’un ESX du cluster, il sera considéré comme hors service suite à une vérification complémentaire par Ping. Le « host network isolation » est propre à un ESX. C’est une capacité à ce placer en mode d’isolation. Sans récupération de heartbeat des autres ESX du cluster pendant 12s, un ESX testera ses adresses d’isolation (par défaut la passerelle – 9 autres possibles) avant de se déclarer isolé du réseau. Au dela de 15s, les autres ESX du cluster tenteront de redémarrer les VM de l’ESX en mode d’isolation. Des mécanismes permettent aujourd’hui d’éviter les situations de split brain en changement le paramètre « host isolation response », et le timeout de 15s sur les locks des fichiers vmdk. Lire la suite…

Mar/113
Par Dans ESX, ESXi, vCenter

Pour une administration en centrale sur une infra séparée géographiquement, il se pose souvent la question sur la bande-passante qu’il faut pour administrer des serveurs ESX à travers le WAN. Il y a bien une solution évidente: déporter le vCenter en Linked-Mode mais encore faut-il avoir plus de 3 ESXs sur ce site pour que ca soit intéressant au niveau des licences ou avoir plus de 10 sites déporté pour partir sur des packs Essentials ROBO. Sinon, on garde un seul vCenter en central et là, il faut avoir assez de bande passante.

Recommandations pour administrer des ESXs à travers le WAN:

  • Ne pas utiliser des liens inférieur 56 kbps. A partir de 128 kbps cela devient utilisable
  • Upgrader manuellement l’agent vCenter(vpxa) sur les serveurs ESX avant de les ajouter dans l’inventaire du vCenter
  • Augmenter la valeur du heartbeat TimeOut pour diminuer les pertes de connexion avec les ESXs (voir plus bas)
  • Réduire la résolution et le nombre de couleurs de toutes les VMs des sites déportés
  • Utiliser RDP pour se connecter aux VMs Windows (plutôt que la Console VM)
  • Utiliser ssh ou putty pour se connecter aux VMs Linux
  • Etre vigilant à la configuration des Firewalls entre le vCenter et les ESXs
  • Sur le site distant, utiliser VI Client en direct vers les ESXs ou du RDP vers le vCenter pour utiliser le VI Client

La bande passante et la latence peuvent provoquer quelques problèmes d’affichage pour la majorité des actions. Par contre pour les taches suivantes, cela peut provoquer des TimeOuts ou des figeages du VI Client:

  • Ajouter un serveur ESX à l’inventaire, si la bande passante est inférieure à 128 Kbps
  • Ouvrir la Console VM, si la bande passante est inférieure à 256 Kbps et la latence supérieur à 100 ms
  • Se positionner sur un ESX dans l’inventaire, si la bande passante est inférieure à 128 Kbps et la latence supérieur à 150 ms

Grosso modo, il faut compter:

  • 80 à 100 Kbps / ESX, pour l’administration entre un serveur ESX et le vCenter
  • 1 Mbps, pour la communication entre le VI Client et le vCenter

Lire la suite…

Jan/11190
Par Dans vCenter

Comme évoqué dans un article antérieur, pour corriger les erreurs Health.xml dans « vCenter Status », il faut corriger l’entrée du certificat vCenter dans l’ADAM.

Il est possible de le faire également avec un outil plus d’actualité que « ldp.exe » avec ADSI Edit sur Windows 2008.

Voici le mode opératoire avec ADSI Edit: Lire la suite…

Déc/10200
Par Dans KB, vCenter

Un problème qui revient souvent dans les installs et les upgrades, c’est que l’historique ne marche plus. On a par exemple plus de statistiques autre que le temps réel ou No Data dans le Performance Overview. Quand on travail avec une base de données autre que SQL express, le problème vient souvent des procédures stockées qui ne sont pas ou mal créées.
Pour commencer voici une liste de KB concernant ces problèmes:

  • KB1018256: les performances ne sont pas collectées dans vCenter qui a été modifié à une date future
  • KB1020903: vCenter n’affiche que les stats de performance temps réel
  • KB1009950: erreur d’upgrade des bases vCenter 2.5
  • KB1004382: mettre à jour les Rollup jobs suite à l’erreur : « Performance data not available for this entity »
  • KB5296658: « Performance data not available for this entity » dans le VI client

Principalement dans ces KB, ce qu’il faut faire c’est supprimer ces procédure stocké et ré-exécuter les jobs à partir des scripts présent dans le répertoire « C:Program FilesVMwareInfrastructureVirtualCenter Server » du vCenter.

Une fois tous les scripts SQL éxécuté, voici la liste des procédures stockées que l’on doit avoir sur une base vCenter 4.1:

Pour vérifier que les statistiques sont bien stockées dans la base, vous pouvez taper la requete SQL suivante (qui ne doit par retourner la valeur 0):

SELECT COUNT (*) FROM vpx_hist_stat1
SELECT COUNT (*) FROM vpx_sample_time1

Et en bonus, la KB1012812 pour les erreurs spécifiques à Performance Overview avec le module JDBC.