Tweakons cette saloperie de vCenter

Après une migration, réalisée avec succès – on oubliera la petite heure passée en mode Fin du Monde quand l’AD du clent s’est mis à déconner suite à un truc qui n’a rien à voir avec cette migration mais que Murphy… –, de vCenter, il faut remettre en place les petits paramétrages non officiels qui vous facilitent la vie en améliorant les performances et en évitant des incidents.

1- Ajouter une dépendance sur le démarrage du service VMware VirtualCenter Server
Si comme moi vous utilisez, pour une petite infrastructure, SQL Server Express livré de base avec vCenter, vous pouvez constater que, de temps en temps, quand vous redémarrez votre serveur, le service VMware VirtualCenter Server se plante au démarrage car il démarre plus vite que le service SQL Server.
C’est très con.
Donc, le but du jeu, c’est de faire en sorte que le service VMware VirtualCenter Server ne démarre que quand la partie SQL Server est fonctionnelle. Donc créer une dépendance.
Bien évidement, chez Windows, créer une dépendance sur le démarrage d’un service ne se fait pas simplement. Naaaan. Ce serait trop sympa.
Il faut donc mettre les mains dans le camboui et dans la base de registres.
Il faut donc localiser le répertoire suivant : HKLMSYSTEMCurrentControlSetServices. Puis, il faut trouver l’entrée vpxd, qui est l’entrée pour le service VMware VirtualCenter Server. Dans vpxd, localisez la clé DependOnService qui est du type REG_MULTI_SZ. Si vous éditez cette clé, vous devez normalement voir qu’elle contient déja deux entrées : ProtectedStorage et lanmanworkstation. Il faut alors ajouter une troisième ligne représentant le service SQL Server. Dans mon système, l’entrée pour SQL Server s’appelle MSSQL$SQLEXP_VIM. Vous êtes censés trouver cette entrée aussi dans HKLMSYSTEMCurrentControlSetServices. Surtout ne pas rajouter une ligne vide, vous feriez planter le service. Une fois l’entrée concernant le service SQL Server ajoutée, vous pouvez fermer la base de registres et vérifier directement que le service VMware VirtualCenter Server a bien une nouvelle dépendance.

2- Augmenter la taille du journal des transactions de la base SQL
Il arrive de temps en temps qu’il y ait un problème avec le journal de transaction de la base SQL Server. – ici dans sa version Express. – Si ce journal est plein, votre service vCenter va planter. Vous pourrez alors voir dans les logs vCenter un message assez explicite. Les logs se trouvent – sur un serveur Windows 2008 R2 – dans C:UtilisateursAll UsersVMwareVMware VirtualCenterLogs. Ce sont les fichiers vpxd-XX.log. Un nouveau fichier est créé à chaque démarrage du service VMware VirtualCenter Server.
Pour pouvoir modifier les paramétrages du journal des transactions de votre base, il faut avoir récupérer les outils d’administration de base qui ne sont pas installés par défaut. Il s’agit, pour une base en SQL Server 2005 Express, de "Microsoft SQL Server Management Studio Express". Qui vient en version 32 ou 64 bits. Il existe aussi une version pour SQL Server 2008 Express.
Une fois ces outils récupérés et installés, connectez-vous à votre base SQL correspondant à votre vCenter.Dans la partie Base de données, faites un clic droit sur la base correspondant à votre vCenter – qui s’appelle chez moi VIM_VCDB – et choisissez Propriétés. Choisissez ensuite Fichiers. Vous avez alors deux entrées. Une de type Données qui est la base et une de type Journal qui est le fameux journal de transactions. Pour résoudre les éventuels problèmes, ou pour en éviter, il faut augmenter la taille maximum du journal de transaction. Cette option est réglable dans la colonne Croissance Automatique. Il faut cliquer sur le petit bouton gris avec "…". Là, vous pourrez configurer la façon dont le journal augmente automatiquement de taille – ne pas toucher à ce paramètre – et la taille maximum du journal. Aujourd’hui, franchement, n’hésiter pas à mettre 2048 Mo. Le journal pourra ainsi grandir jusqu’à 2 Go. Et normalement, il n’y aura pas de problème.

A noter que sur une ancienne mission, le vCenter reposait sur une base Oracle et plantait régulièrement à cause d’espace insuffisant sur le tablespace temp.

KB VMware

3- Reconstruction des indexes
Quatre tables posent problème pour vCenter. Ces quatre tables receuillent les informations de statistiques des serveurs ESX, des VMs et de l’ensemble de l’architecture. Ce qui fait que leurs indexes se fragmentent extrêmement rapidement. Ce qui entraîne des baisses des performances assez sensibles quand on consulte les sections liées aux graphes de performances et autres dans vCenter.
Pour solutionner le problèmes, il faut reconstruire les indexes en question de façon régulière. Dans un système de gestion de bases de données classique, cela se ferait sans problème. Par contre, quand vous avez SQL Server Express, c’est plus problèmatique. Comme c’est la version gratuit de SQL Server, certaines choses ne sont pas présentes et notament les plans de maintenance.
Donc, pour réindexer les quatres tables en questions, il faut faire un petit script SQL – avec Management Studio, c’est très facile à faire- qui sera lancer en ligne de commande.
Le script SQL ressemble à ceci :
USE [VIM_VCDB]
GO
ALTER INDEX [PK_VPX_HIST_STAT1] ON [dbo].[VPX_HIST_STAT1] REBUILD WITH
( PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, ALLOW_ROW_LOCKS  =
ON, ALLOW_PAGE_LOCKS  = ON, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY  =
OFF, ONLINE = OFF )
GO
ALTER INDEX [PK_VPX_HIST_STAT2] ON [dbo].[VPX_HIST_STAT2] REBUILD WITH
( PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, ALLOW_ROW_LOCKS  =
ON, ALLOW_PAGE_LOCKS  = ON, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY  =
OFF, ONLINE = OFF )
GO
ALTER INDEX [PK_VPX_HIST_STAT3] ON [dbo].[VPX_HIST_STAT3] REBUILD WITH
( PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, ALLOW_ROW_LOCKS  =
ON, ALLOW_PAGE_LOCKS  = ON, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY  =
OFF, ONLINE = OFF )
GO
ALTER INDEX [PK_VPX_HIST_STAT4] ON [dbo].[VPX_HIST_STAT4] REBUILD WITH
( PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, ALLOW_ROW_LOCKS  =
ON, ALLOW_PAGE_LOCKS  = ON, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY  =
OFF, ONLINE = OFF )
GO

Pour le lancer en ligne de commande, ça peut ressembler à ça :
sqlcmd -S .SQLEXP_VIM -i "D:Reconstruction_IndexReconstruction.sql" >> Log.log

Bon, c’est tout mais c’est déjà pas mal.

 

——

Après un deuxième plantage suite à une saturation du journal de transactions, il a fallu que je regarde un peu plus le pourquoi du remplissage excessif de ce fichier. Avant la migration en vCenter 4.1, je n’avais pas eu le problème.
Après quelques recherches, il apparaît que ma base n’était pas configurée correctement au niveau du Recovery Model. – Ce qui est dommage, c’est que c’est configuré automatiquement lors de l’installation de vCenter et de SQL Express. – Il faut donc, pour la base vCenter, mettre le Recovery Model à Simple.

KB VMware

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.