VisorFS : la clef de voûte d’ESXi

A l’occasion du lancement du VMware Technical Journal, un document traitant de VisorFS a été publié discrètement. Signé Olivier Cremel (si si vous connaissez…), ce document “VisorFS: A Special-purpose File System for Efficient Handling of System Images” décrit l’historique ainsi que le fonctionnement de VisorFS, l’ingénieux “ramfs” stateless d’ESXi.

On y découvre notamment le secret du format vmtar qui permet de d’optimiser le contenu des tardisks pour que TPS soit le plus efficace possible sur la zone mémoire utilisé par l’hyperviseur.

When the system image is built, the system tar archives that become the tardisks are constructed as usual. These tardisks are processed by the vmtar tool, which reorders the content to page align the binaries and add the number of pages needing fix-ups to their metadata header.

On retient également le principe de base qui fait d’ESXi un hyperviseur aussi léger qu’efficace :

Complexity is pushed to offline tools so that simplicity can be kept in the running system.

Ceux qui l’auraient raté peuvent également consulter la session TA8245 du VMworld 2010 “ESXi Internals: Better Understanding for Better Management and Troubleshooting” pendant laquelle VisorFS est également abordé.

Tags: ,

[ACPI] cpu usage vs core utilization – MAJ

MAJ 13/07/2012 : VMware vient de nous confirmer que sur des processeurs avec l’Hyper-Threading activé, la valeur remonté est la somme des % d’utilisation de chaque core logique divisée par le nombre de core physique ce qui peut conduire (injustement selon nous) à des valeurs supérieures à 100%. Pour faire simple, avec l’HT d’activé ce compteur est complètement faussé et donc l’alarme inutile.

MAJ 19/04/2012 : Modification du script pour afficher nom du server et le status dans l’objet du mail

Le coup du PCPU Used vs PCPU Util c’est un classique de Krishna Raj (grand maître d’esxtop) aux VMworld pendant la session “esxtop for advanced users”. Il s’agit d’une situation où la consommation cpu “théorique” (basé sur la fréquence de base du cpu) est différente de la consommation ”réelle” (basée sur la fréquence courante du cpu). Les exemples de troubleshooting des sessions de Krishna sont lié à l’Hyperthreading et aux mécanismes qui permettent aux cpu de baisser leur fréquence pour économiser de l’énergie.

En fervents adeptes d’esxtop, nous avons tout de suite remarqué l’anomalie décrite par Krishna lors d’une séance de troubleshooting :

Le problème c’est que nous n’étions pas dans esxtop pour ça et, pire, aucune alarme ne nous était parvenue. Et pour cause, c’est le compteur “usage” qui est utilisé par vCenter et non pas “coreUtilization” :

Après investigation, il s’agissait d’une mauvaise configuration ACPI/C-State dans le BIOS et comme nous ne sommes pas infaillibles, nous nous avons pondu un petit oneliner PowerCLI pour créer une alarme qui se base sur le compteur coreUtilization :

(Get-View AlarmManager).CreateAlarm((Get-Folder -NoRecursion |Get-View).MoRef,(New-Object VMware.Vim.AlarmSpec -Property @{Name = "Host core usage";Description = "Custom alarm to monitor core Utilization";Enabled = $true;expression = (New-Object VMware.Vim.OrAlarmExpression -Property @{expression = @((New-Object VMware.Vim.MetricAlarmExpression -Property @{Metric = (New-Object VMware.Vim.PerfMetricId -Property @{CounterId = ((Get-View (Get-View ServiceINstance).Content.PerfManager).PerfCounter|?{$_.groupinfo.key -match "cpu"}|?{$_.nameinfo.key -match "coreUtilization"}|?{$_.RollupType -match "average"}).key;Instance = ""});Operator = "isAbove";Yellow = "7500";YellowInterval = "300";Red = "9000";RedInterval = "180";Type = "HostSystem"}))});Action=(New-Object VMware.Vim.GroupAlarmAction -Property @{Action= (New-Object VMware.Vim.AlarmTriggeringAction -Property @{Action = (New-Object VMware.Vim.SendEmailAction -Property @{ToList = "admin@vmware.local";Subject = "[vAlarm] {targetName} core usage is {newStatus}";CcList = "";Body = ""});TransitionSpecs = @((New-Object VMware.Vim.AlarmTriggeringActionTransitionSpec -Property @{StartState = "green";FinalState = "yellow";Repeats = $false});(New-Object VMware.Vim.AlarmTriggeringActionTransitionSpec -Property @{StartState = "yellow";FinalState = "red";Repeats = $true}))})});ActionFrequency = "1800"}))

Les seuils sont les mêmes que pour l’alarme “Host CPU Usage”, à savoir 75/90, mais nous avons réduit le temps pour l’alerte (red) à 3min au lieu de 5.

Tags: , , , ,

Cluster HA Astaro v8 en VM

Monter un cluster actif/passif de firewall Astaro en v8 c’est d’une simplicité déconcertante, vous choisissez l’id du node (1 ou 2), vous sélectionnez l’interface réseau (dédiée) pour le heartbeat et fixez le password. Laissez mijoter et admirez le résultat :

Malheureusement en VM c’est pas forcement la même chanson car il y a de fortes chances que vous soyez bloqué par le fait que le noeud actif du cluster utilise une addresse mac virtuelle mais que votre vswitch ne l’autorise pas, que le MTU de l’interface dédiée au heartbeat soit forcée à 2000 mais que le driver e1000 ne l’y autorise pas ou que le timeout de heartbeat de 3 sec par défaut soit un peu juste pour vos vswitch trop chargés. Heureusement la communauté d’Astaro a toujours été très active et les réponses à ces problèmes sont disponibles au détour de quelques topics (ici ou là par exemple).

Pour modifier les paramètres avancés du firewall, il faut se connecter en ssh (comme d’hab avec le compte “loginuser” puis un su pour atterrir en “root”) et taper la commande “cc” puis naviguer dans les différentes rubriques pour modifier les paramètres suivant :

cc > ha > advanced > virtual_mac$ =0

cc > ha > advanced > mtu$ =1500

cc > ha > times > dead_time =15

Il ne faudrait pas oublier de vous dire que pour les paramètres virtual_mac et mtu, il faut faire l’opération sur les 2 noeud avant de configurer le cluster (le noeud 2 n’est plus disponible après cela car il devient la copie conforme du node 1).

Sinon, on est désolé de vous annoncer qu’Astaro va bientôt changer de nom grâce à nos amis visionnaires de chez sophos (qui avait déjà saccagé le logo après le rachat), ca va s’appeler Sophos UTM (Unified Threat Management). Oui, c’est complètement pourri. Nous, on reste fan du logo de la v6 :

Tags: , , ,

Les scripts Powershell indispensables à votre veeam backup

MAJ 13/07/2012 : Mise à jour du script de récupération des fichiers de backup orphelins pour la v6, merci à Thierry pour le feedback.

Nous vous proposions il y a quelques temps un script qui stop les jobs en cours sur un serveur veeam backup, aujourd’hui nous allons plus loin dans la démarche avec 2 fichiers xml correspondant à 2 export de tache planifiée pour Windows 2008 R2 contenant les commandes. Le fichier StopActiveVBRJobs.xml va vous permettre de créer une tache planifiée qui arrêtera les jobs veeam en cours à 7h du matin, les jours de semaine, et le fichier RetryFailedVBRJobs.xml automatisera le retry des jobs arrêtés ”manuellement” à 21h, les mêmes jours.

Nous vous proposons également une tache planifiée qui automatise l’export des jobs veeam backup sur un partage CIFS (\\server\share\ à ajuster) et un autre qui permet d’exporter régulièrement (en xml) la liste des points de restauration possibles pour chaque vm de chaque job.

Voici maintenant un oneliner pour un usage très particulier, celui de trouver (replacez le get-item par remove-item pour supprimer) les fichiers veeam backup orphelins dans les répertoires cibles des jobs (cela peut arriver en cas de reboot violent du serveur veeam ou indisponibilité du repository pendant un backup).

v5 :

Compare-Object (Get-VBRJob|%{$_.Info.TargetDir|%{Get-ChildItem $_|%{$_.FullName}}}) (Get-VBRBackup|%{$_.GetStorages()|%{$_.FilePath}})|%{Get-Item $_.InputObject}

v6 :

Compare-Object (Get-VBRJob|%{$_.Info|%{Get-ChildItem "$($_.TargetDir)\$($_.Path)"|%{$_.FullName|?{$_ -match ".vrb|.vbk|.vib"}}}}) (Get-VBRBackup|%{$_.GetStorages()|%{$_.FilePath}})|%{Get-Item $_.InputObject}

On continue avec un autre oneliner qui permet d’afficher la liste des vm dont la date du dernier backup veeam (si vous avez activé la fonction qui rempli l’un des custom fields, “veeam” dans notre exemple) est supérieure à 21 jours, que vous pouvez utiliser dans un script pour vous envoyez un mail périodiquement par exemple.

Get-View -Viewtype virtualmachine|select name,@{n="backup";e={[Regex]::Match(($_.value|?{$_.key -eq ((get-view (Get-View ServiceINstance).content.CustomFieldsManager).field|?{$_.name -match "veeam"}).key}).value, "([0-9]{1,2}/){2,2}201[0-9]{1,1}[ ]*([0-9]{1,2}:?){3,3}").Value}},@{n="pool";e={(get-view $_.ResourcePool).name}}|?{$_.backup}|?{([datetime]::ParseExact(($_.backup), "dd/MM/yyyy HH:mm:ss", (New-Object System.Globalization.CultureInfo("fr-FR")))) -le (get-date).AddDays(-21)}

Et pour finir, un oneliner qui nous a prit un peu de temps (à cause du comportement bizarre du -ExpandProperty de la cmdlet Select-Object) qui vous permet de lister les vm présentent dans plusieurs jobs de backup.

Get-VBRBackup|select jobname,@{n="vm";e={$_.GetObjectOibsAll()|%{@($_.name,"")}}}|select jobname -ExpandProperty vm|select @{n="vmname";e={$_}}, @{n="jobname";e={$_.jobname}}|?{$_.vmname}|Group-Object -Property vmname|?{$_.Count -gt 1}|select name, @{n="jobs";e={$_.group|%{$_.JobName}}}

Tags: , ,

Resource Pool starter kit

Pour une petite infra ou lorsqu’on veut monter un vcenter vite fait tout en gardant une hiérarchisation des ressources, la solution de facilité est d’utiliser les paramètres Low, Normal et High des resource pool. Si vous n’avez pas 3 resource pool (Low, Normal et High) avec le même nombre de vm démarrées, vous risquez d’avoir de très mauvaises surprises…

Le mécanisme de shares, parfois mal connu malgré son apparition dans VI3 (oui oui, en 2006), est très bien expliqué sur le blog de Duncan ou par Frank dans l’excellent  VMware vSphere 5 Clustering Technical Deepdive.

Pour faire simple, si on veut toujours garder un bon ratio entres les pool, il faut recalculer les shares à chaque fois qu’une vm voit sa configuration cpu/mémoire changer ou qu’une vm est démarrée/arrêtée dans un des pool. L’idéal étant de le scripter, nous vous proposons un joli petit script PowerCLI (dérivé de celui posté par Andrew Mitchell sur le blog de Duncan) qui fera tout cela pour vous sur un model standardisé.

L’idée est d’avoir 4 resource pool toujours équilibrés (GOLD, SILVER, BRONZE et COPPER) qui représentent l’usage “classique” d’un cluster VMware, à savoir prod, pré-prod, qualif et dev. La seule chose que vous devez fournir au script est le nom du cluster et (en option) les pourcentages respectifs que vous jugez idéal pour votre environnement (45%, 30%, 15% et 10% par défaut).

Une fois les resource pool ajustés (si besoin), le script va créer pour le cluster un petit rapport html à la racine du site web du vcenter :

Vous l’aurez compris, ce script est fait pour tourner sur le vcenter à l’aide d’une tache planifiée (modèle pour Windows 2008 R2).

Set-ZResPoolShares

Nous vous rappelons que ce script se base sur le mécanisme de shares (QOS) et non sur celui de reservation/limit et qu’il est donc indispensable de monitorer les pools pour éviter toute contention qui dépasserait vos prévisions. Pour les petites infra, le vcenter reste l’outil idéal à nos yeux :

Tags: , , , ,