La gestion des patchs sur le matériel

Je discutais la semaine dernière avec David Dariouch de Pillar Data Systems de la gestion des patchs et plus particulièrement sur le matériel.

Le point de vue d’un constructeur est qu’il faudrait réaliser une campagne de tests annuelle sur l’ensemble du parc. L’idée est séduisante mais n’est pas toujours réaliste en fonction des organisations. En effet, nos infrastructures complexes nécessitent de valider les montées de version matérielles de bout en bout. Prenons l’exemple du stockage, il faudrait possédé en recette :

  • un serveur
  • des cartes HBA (ou dans mon cas des CNA FCoE)
  • un Fabric (là ca devient plus compliqué pour les PME)
  • une baie de stockage  (quasiment impossible pour une PME)

et du temps pour réaliser les tests de compatibilité et de non régression.

Un exemple concret, lors du remplacement d’un de nos 6500 de coeur de réseau, nous avons rencontré un effet de bord non escompté, à savoir les dvSwitch de nos ESX se sont mis à dropper tous les paquets entrant pour les VMs. Pour essayer de reproduire le problème afin de diagnostiquer, nous avons dans un premier temps souhaité une maquette hélas, il nous manquait des Nexus 5000 pour reproduire l’architecture, il a donc été décidé d’arrêter la production un samedi et de reproduire le problème sur notre environnement de production.

Tout cela pour dire qu’il n’est plus  toujours facile de valider les interventions sur nos architectures qui sont de plus en plus complexes et que les risques d’incompatibilité entre différents firmwares vont être de plus en plus présents – pour rappel, nous avons du flasher nos cartes CNA pour qu’elles fonctionnent correctement entre vSphere 4 U1 et les Nexus 5020.

Je garde néanmoins à l’esprit la suggestion de David qui est  de prévoir une campagne de « patchs » une fois par an.

Et chez vous, réalisez -vous des tests de bout en bout lors de l’application d’un patch matériel ?

Le site VMware indisponible …

En pleine migration du vCenter 4 en Update 1, les portails du support et des licences ont décidé d’être indisponibles …

bref une production qui tourne sur une version d’évaluation* j’adore …

Conseil du jour : en plus des sources, prévoir aussi  d’avoir sous le coude ses  numéros de licences …

* tien, tout comme mes serveurs ESX for Destop dédiés à View 4 :(

Changement de nom des niveaux de support VMware

Très discrètement VMware a changé le nom de ses offres de support :

  • Gold devient Basic (12×5)
  • Platinium devient  Production (24×7)

Ces changements « marketing » n’impactent ni les tarifs, ni les prestations associées.

Néanmoins VMware va proposer de nouvelles offres de support prochainement.

Le couac du jour lors d’une migration VI3 vers vSphere 4

Au moins avec cette migration on maitrise mieux le retour arrière que la mise à jour elle même

Entendu lors d’une migration en pleine production de plusieurs clusters VMware VI3 vers vSphere 4 après plusieurs plantages et « purple screens » !!!

A la décharge de l’éditeur à l’heure où j’écris ses quelques lignes rien de dit que c’est un problème logiciel. Les analyses qui vont suivre permettrons, j’espère, de mettre en évidence, la source du problème.