Suite de l'affaire .... H+48... explosion en plein vol .....J'ai un appel d'utilisateur ce dimanche pour informer qu'il n'y a plus d'accès à certains serveurs. Je constate à distance qu'effectivement le temps de réponse est long et qu'un écran noir tient lieu de console dans vCenter sur certaines VMs qui pourtant fonctionnent ... ça sent pas bon. Je me déplace, je soupçonne un problème de SAN, IPSTOR, LAN/FCOE ... pourtant depuis certains hosts, je browse bien les Datastores hébergés sur IPSTOR. Après en avoir discuté avec Julien par tel, ce dernier me met le doigt sur l'embrouille : la base de données de vCenter est saturée !!!! J'ai commis le péché de ne pas passer tout de suite sous Oracle, parce que pas encore de SRM, et d'utiliser SQL lite fournit avec vCenter. Autoflagellation !
Moralité :
- Je n'avais pas encore upgradé ni tools, ni virtual hardware : ouf ! NE PAS UPGRADER DE SUITE NI TOOLS NI VIRTUAL HARDWARE sous peine d'impossibilité de retour arrière.
- Ayant gardé sous le coude des hosts en 3.5U4 et l'ancien vCenter 3.5U4, j'ai fait un failback.
- vCenter 4 remplit les 3 Go de la base en 2 jours .... il devient vraiment bavard.
Je vais donc retenter l'aventure avec Oracle cette fois.
Update 1 : Après vérification, il s'avère que la base SQL Lite Runtime ne saurait pas gérer au-delà de 3 Go de volumétrie. Il ne faut donc surtout pas l'installer et encore moins l'utiliser avec vCenter 4 :(
Update 2 : J'ai réinstallé vCenter 4 en m'appuyant sur Oracle 10g. J'ai positionné l'auto-extent des tablespace Oracle à 'no limit'. Nous allons voir le comportement.
1 commentaire:
Mouais,
Encore un newbie en virtualization de stockage qui a le sang chaud et sa 1ère réaction est de dire que c'est la faute d'IPStor...pff!
Allez Olivier reprends-toi, ni la pillar ni l'appliance n'ont bougé.
San José arrive ;-)
Enregistrer un commentaire