4- Vérifier que l'éditeur supporte aussi les versions virtualisées
"Il faut être attentif au niveau du support des applications virtualisées. Par exemple, SAP fonctionne très bien en mode physique et en mode virtualisé, et SAP supporte la version virtualisée. A ma connaissance, ce n'est pas le cas avec Oracle. Donc, lorsqu'il y a un incident sur une version virtualisée d'Oracle, l'éditeur n'offrira pas de support", explique Chuyen Huynh Huu, responsable de l'offre optimisation des infrastructures chez Devoteam.
"La seule solution consiste alors à dévirtualiser, c'est à dire faire du V-to-P, pour montrer à l'éditeur que même sur une version physique, cela ne marche toujours pas, et que la virtualisation n'est donc pas en cause dans cet incident", précise Chuyen Huynh Huu.
5- Ne pas virtualiser des versions d'applications non-maintenues
Si la virtualisation permet de maintenir des applications dépassées au sein de son système d'information en les déployant sur des anciens systèmes, cette utilisation de la virtualisation est clairement déconseillée par les cabinets de conseil et les SSII.
| Virtualiser des applications dépassées : une
bombe à retardement |
"Les gens virtualisent les applications qui les gènent. On ne sait
pas trop ce qu'elles font, on ne veut pas les éteindre mais dans le même
temps on ne veut pas laisser un serveur qui va travailler 1 % de son
temps pour des applications anciennes. Du coup, l'entreprise fait appel à
la virtualisation. Mais dans ce cas, il manque une étape préalable
qui est l'urbanisation", déclare Chuyen Huynh Huu.
"Virtualiser de cette manière conduit à placer une bombe à retardement dans le système d'information. Un tel système fonctionne jusqu'au jour où l'entreprise est confrontée à un bug majeur et s'apercoit que la version virtualisée est non maintenue depuis des années. Il ne faut pas économiser à court terme pour perdre à long terme", ajoute Chuyen Huynh Huu - Devoteam.
6- Adapter ses montées de version aux environnements virtuels
Une montée de version sur un serveur virtuel implique une nouvelle organisation de l'exploitation. Toutes les ressources étant partagées sur un même serveur, il est difficile de trouver par exemple un créneau horaire dans lequel la machine serait moins sollicitée. De même, il n'est pas envisageable d'arrêter toutes les autres applications pour en mettre à jour une seule. Enfin, l'impact d'un dysfonctionnement peut désormais affecter plusieurs applications.
"Comme sur un serveur physique, les montées de version doivent être planifiées. Passer en mode virtuel n'est pas rédhibitoire mais cela ne peut pas se faire en mode panique. Il faut migrer la machine virtuelle sur un autre serveur physique, puis gérer la montée de version et migrer dans l'autre sens le serveur virtuel. Cela rajoute une tâche supplémentaire dans le processus", souligne le consultant de Devoteam.
