Mon infrastructure maison a longtemps été hébergée sur mon poste avec un VMware Workstation. Puis je suis passé sur ESXi avec une machine dédiée. J’ai également eu un “Single Node Nutanix” et maintenant, mes besoins en “prod” ont augmenté. Je me tourne vers un vSAN à base d’Intel NUC comme beaucoup d’entre nous. Cette configuration sans être dans la HCL VMware fonctionne sans modification de l’iso d’installation de l’hyperviseur.
Voici une partie du script que j’utilise pour exporter mes informations d’hôtes à notre CMDB, l’intérêt principale de celui-ci est l’utilisation de “Get-View” et donc sa rapidité d’exécution.
$vCenter = Read-Host "Entrer ici le nom ou l'ip du vCenter"
Connect-VIServer $vCenter
#Creation du dossier pour l'export
md "C:\Scripts" -ErrorAction SilentlyContinue
#Inventaire Hosts
Get-View -ViewType HostSystem -Property Name, Config.Product, Summary.Hardware.Model, Summary.Hardware.MemorySize, Summary.Hardware.CpuModel, Summary.Hardware.NumCpuPkgs, Summary.Hardware.NumCpuCores, Summary, Hardware, Parent |
select Name,
@{N='Product';E={$_.Config.Product.FullName}},
@{N='Build';E={$_.Config.Product.Build}},
@{N='Model';E={$_.Summary.Hardware.Model}},
@{N='Memory';E={[Math]::Round(($_.Summary.Hardware.MemorySize)/ 1GB, 0)}},
@{N='CpuModel';E={$_.Summary.Hardware.CpuModel}},
@{N='CpuSocket';E={$_.Summary.Hardware.NumCPuPkgs}},
@{N='CpuCore';E={$_.Summary.Hardware.NumCpuCores}},
@{Name="Serial"; Expression={($_.Hardware.SystemInfo.OtherIdentifyingInfo | where {$_.IdentifierType.Key -eq "ServiceTag"}).IdentifierValue}},
@{N='Cluster';E={
$parent = Get-View -Id $_.Parent -Property Name,Parent
While ($parent -isnot [VMware.Vim.ClusterComputeResource] -and $parent.Parent){
$parent = Get-View -Id $parent.Parent -Property Name,Parent }
if($parent -is [VMware.Vim.ClusterComputeResource]){
$parent.Name}}},
@{N='DC';E={
$parent = Get-View -Id $_.Parent -Property Name,Parent
Do {$parent = Get-View -Id $parent.Parent -Property Name,Parent}
While ($parent.Moref.Type -ne "Datacenter" -and $parent.Parent)
echo $parent.name}} |
Export-csv -NoTypeInformation -encoding "unicode" -append "C:\Scripts\export-Hotes.csv"
Voici le résultat dans Excel :
Ça y est, j’ai enfin eu le temps de tester Runcast Analyser. Une découverte pour moi au dernier VMworld parmi les nombreux stands que j’ai visités là-bas.
Ce produit dédié à l’écosystème VMware, nous permet d’analyser l’infrastructure. Il remonte tous les points correspondant à des articles disponibles dans la base de connaissance VMware, un peu à la façon d’un HealthAnalyser.
Armé du guide d’utilisateur, je vais vous faire partager mon expérience de ce produit.
L’appliance est proposée en 3 dimensionnements :
Dès le déploiement de l’OVA, la machine dispose d’énormément de paramètres supplémentaires qui sont autant de recommandations VMware.
La VM est très simple à déployer, et dans le standard des appliances VMware. Elle propose l’administration au travers du port 5480. Compte utilisateur : rcadmin et mot de passe : admin pour cette interface.
J’en profite pour paramétrer le bon timezone et vérifier une potentielle mise à jour. La 1.6.3.0 est disponible depuis le 1er novembre, autant tester la dernière version. Cette dernière apporte principalement le rôle read-only et un meilleur support du web plug-in dans les différentes versions de vCenter.
Après le déploiement, on se connecte sur l’interface avec le compte utilisateur : rcuser et le mot de passe : Runecast!
Le port tcp 31415 indiqué dans la doc n’a plus l’air nécessaire et la redirection du 443 fonctionne directement : https://ip_appliance
La première étape, après le déploiement, consiste à ajouter un vCenter à analyser :
Après la configuration du vCenter, le guide de l’utilisateur conseille de configurer la collecte des logs, afin d’avoir le plus de données possibles pour l’analyse. Direction les paramètres en cliquant sur “Settings” puis l’onglet “Log Analysis”.
Runcast peut réaliser la configuration des hôtes et des VMs, directement pour nous, il suffit de cliquer sur la clé à molette.
Pareil pour les VMs.
Il est également possible de le faire manuellement en cliquant sur la bouée. Runecast vous indiquera les paramètres à modifier pour effectuer la configuration, et il peut aussi vous générer un script powershell.
Il faut maintenant lancer une analyse de l’infrastructure en cliquant sur “Analyse Now”.
Sur mon lab, l’analyse ne dure que quelques secondes.
Puis, le Dashboard fait un résumé de ce que l’analyse a détecté.
Il me remonte donc 5 problèmes critiques, 20 majeurs et 14 moyens. Ci-dessous, la liste des problèmes critiques, par exemple :
On peut développer chaque problème pour avoir le détail de la KB associée.
Au-delà des KB, concernant les problèmes courants de stabilité, le produit propose de vérifier la conformité avec les “best pratices” et aussi le “hardening guide”.
Chacune des listes est exportable vers le presse-papier, CSV ou PDF, en cliquant sur le bouton “Export”.
Export CSV:
Export PDF :
Comme certaines remontées font probablement parties de vos choix, vous pouvez cliquer sur “Ignore” afin de filtrer ce type d’alerte sur une partie de l’infrastructure surveillée :
Tout est maintenant en place pour faire le tour des alertes en fonction de leur priorité et de décider, ou non, de les traiter.
Pour terminer voici l’intégration du plug-in au WebClient VMware. Effectuez l’installation depuis la page Runecast : Settings > vCenter Connection puis :
Cliquez sur sur “Edit” et enfin “Install Plugin”.
Ensuite, depuis le webclient l’icône RuneCast apparait. Il faut parfois être patient, ça a été assez long sur mon lab.
Puis, on le configure dans “go to settings”.
On renseigne l’adresse IP ou le nom complet de l’appliance Runecast pour le token de l’API, il faut le générer depuis l’interface Runecast.
“Settings” puis “API Access tokens” puis “Generate API access token”.
On entre une description et on génère la clé.
Il reste à copier la clé dans la configuration du webclient puis, de dérouler le vCenter.
En conclusion, Runecast Analyser m’a vraiment séduit, le gain de temps pour ce niveau d’analyse est très important dès que l’environnement VMware devient un peu conséquent. Je ne peux que vous encourager à tester leur produit qui peut être téléchargé ici.
Pour information, je parle rarement des outils qui gravitent autour de nos environnements virtualisés, car il y en a vraiment beaucoup qui ne me semblent pas indispensables. Cependant, celui-ci m’a beaucoup plu et je tiens à préciser que cet article n’est pas sponsorisé.
Nous avons eu besoin d’un nouveau rôle pour nos ROBO afin de leur permettre d’éteindre les ESXi sur site.
J’ai créé un rôle personnalisé Shutdown host pour cette opération avec les privilèges suivants :
Global > Log event
Host > Configuration > Maintenance
Pourquoi faire un post la dessus me direz-vous ? tout simplement parce-qu’en fonçant tête baissé dans les permissions, j’étais plus tenté de configurer :
“Host > Configuration maintenance + power” mais ce n’est pas la bonne configuration.
Une des rares opérations pas vraiment transparente lorsque l’on administre des noeuds Nutanix avec ESXi comme hyperviseur concerne la mise en maintenance.
Comme vous le savez la CVM est liée au stockage local de l’hôte et ne sera pas déplacé par un vMotion pour la mise en maintenance, il faut donc l’eteindre.
Oui mais comment ? Pendant longtemps je pensais à tort qu’un “Shut Down Guest OS” était suffisant, qu’un hook avait été mis en place dans la CVM pour intercepter ce type d’ordre et proceder proprement à l’extinction. (Et en discutant autour de moi, je n’étais pas le seul à penser ça)
Sur les conseils d’un contact Nutan, j’ai ouvert un ticket au support pour en avoir le coeur net et il n’en ai rien, la seule méthode supportée consiste à se connecter à la CVM et executer la commande :
cvm_shutdown -P now
qui permet de réellement prévenir les autres noeuds du cluster que la CVM n’est plus disponible et ce point n’est pas présent via VMware.
Je vous met en lien les références Nutanix :
Shutting Down a Node in a Cluster (vSphere Web Client)
et aussi
Shutting down all nodes in a cluster for maintenance or relocation
