postheadericon VMWare vSphere 4, un quebradero. XenServer 5, 10 minutos.

Domingo, 07 de Junio de 2009 19:50 | postauthoriconEscrito por xavisan | Imprimir

Muchos de nosotros hemos sufrido más de una vez en cuanto hemos tenido que actualizar cualquier plataforma o migrarla a una versión superior, prácticamente ningún sistema se "libra" de ciertos problemas, pero ¿que pasa cuando todo depende de una plataforma de virtualización?.

El tema puede llegar a complicarse enormemente cuando se trata de VMware, veamos alguna de las razones simples.

VMware ha publicado una serie de artículos KB para intentar esbozar y solucionar esos problemas denominados"las mejores prácticas para la instalación de vSphere", si instalamos desde cero, estupendo como cualquier otro sistema, pero no podemos dedir lo mismo cuando tenemos que pensar en actualizar a vSphere, sobre todo cuando tratamos temas delicados como la mejora importante de las máquinas virtuales ESX 3.0 a ESX 4.0 y las sustanciales diferencias en el hardware.

Así que entendemos que cualquier sistema debería de ser sencillo, todos sabemos que existierón algunos cambios con los procesos de actualización de XenServer 5.0 y el Update 3, pero estos fuerón resueltos con mucha agilidad y gran rapidez, para ser explicitos con el tema de la HA, sin duda Citrix ha aprendido de esto, yha simplificado enormemente sus procesos de actualización. De hecho así lo ha demostrado al pasar de 4.11 a 5.0 y 5.5 en breve (artículo publicado en CTXDOM.COM, puedes consultarlo en la Knowledgebase de esta comunidad), pero desgraciadamente no podemos decir lo mismo en VMware, un proceso de actualización que puede ser realmente catastrófico y con unas pérdidas importantes, si su sistema depende de este Software y no ha pensado en los problemas adicionales, curiosamente la facilidad de VMWare de uso que tanta publicidad han generado en su migración puede ser peligrosa en algunos puntos, y tendríamos que tenermos muy en cuenta.

Así que veamos cómo se ha centrado en la facilidad de uso ...
En unos de los puntos de la migración de ESX Server indican claramente el siguiente mensaje,

  4. Si un SAN está conectado a la ESX Server, separar la fibra antes de continuar con la actualización.

Concretamente se puede imaginar un responsable de sistemas el tener que pedir a sus técnicos que a pie de máquina a máquina, en su centro de datos que tiren las conexiones de fibra abajo, y volver después a levantarlas despues de la actualización? Curioso, ¿Que pensaría?. Si además unimos las características o elementos implementados de ORACLE sobre VMware a los que ORACLE no da soporte, podemos llegar a tener ennuestro CPD un problema de gran importancia.
 
En XenServer la automatización de estos procesos son vitales así como la facilidad de uso para cualquier elemento de estas características, sin olvidar que ORACLE da soporte sobre plataforma Xen, actualmente Xen es el Hyper-Visor que más está evolucionando y creciendo, tal como en plataformas de virtualización con un standard totalmente aceptado por fabricantes como Microsoft, ORACLE y otros.....