Evaluar Conozca los pros y contras de las tecnologías, productos y proyectos que está considerando.

¿Las mejoras de Hyper-V 3.0 harán que las empresas se olviden de VMware?

Hyper-V 3.0 incluye varias nuevas funcionalidades y mejoras que favorecen la virtualización de Exchange, pero ¿suficientes para abandonar VMware?

Hace poco discutíamos con un colega sobre el próximo lanzamiento de Hyper-V 3.0, que debutará en Windows Server 8. Me preguntó si yo creía que las nuevas funcionalidades de de Hyper-V 3.0 bastarían para influir en los administradores que están actualmente virtualizando Exchange a través de VMware vSphere. No tengo una bola de cristal, pero sí algunas ideas sobre cómo los administradores responderán ante Hyper-V 3.0.

En primer lugar, sin duda muchos administradores seguirán virtualizando Exchange mediante VMware vSphere. Hay un número de razones para que así sea:

  • Hyper-V tiene la fama de ser un producto inmaduro que no es apropiado para entornos empresariales. Ese estigma seguramente acompañará a Hyper-V durante algún tiempo, incluso después del lanzamiento de su versión 3.0.
  • Las organizaciones que utilizan VMware pueden haber invertido un capital considerable en sus infraestructuras de virtualización existentes y pueden mostrarse reacias a abandonarlas.
  • Algunos negocios de TI permanecerán con VMware solamente debido a la lealtad con el proveedor.
  • Algunas organizaciones dudarán de cambiarse a Hyper-V debido a la dificultad de mover una aplicación con una tarea crítica, como es el caso de Exchange Server, hacia una plataforma de virtualización diferente.

Como puede ver, existen varias razones para que los administradores de Exchange se queden con VMware. No obstante resulta difícil pasar por alto varias de las nuevas funcionalidades de Hyper-V, especialmente si tenemos en cuenta cómo pueden beneficiar a los negocios de Exchange.

Exchange e Hyper-V 3.0: Mejoras en la escalabilidad

Muchas de las mejoras de virtualización incluidas en Hyper-V 3.0 se centran en la escalabilidad. Anteriormente, las máquinas virtuales (VM) que se ejecutaban en Hyper-V estaban limitadas a cuatro CPU virtuales y 32 GB de RAM. Solamente estas limitaciones provocaron que numerosas empresas se lo pensaran dos veces en el momento de alojar Exchange en Hyper-V.

Ahora en Hyper-V 3.0 las VM pueden ser provistas con hasta 32 CPU virtuales y hasta 512 GB de RAM. Además, Hyper-V 3.0 será compatible con discos duros virtuales de hasta 16 TB. Estas mejoras de escalabilidad deberían poder albergar fácilmente hasta los mayores servidores de buzones de Exchange 2010.

Exchange e Hyper-V 3.0: Mejoras en la Migración en vivo

Otro aspecto de la tecnología Hyper-V 3.0 que seguramente causará impresión entre los administradores de Exchange es que Microsoft ha rediseñado tanto la Migración en vivo como la Migración de Almacenamiento en Vivo. La Migración en vivo se introdujo por primera vez con Windows Server 2008 R2 como una alternativa a Vmotion de VMware. Esta opción permite a los administradores mover una máquina virtual de un servidor host agrupado a otro sin tiempo de inactividad.

El problema era que en la primera iteración de la Migración en vivo solo podía mover una máquina virtual a la vez. Si un servidor contenía un gran número de máquinas virtuales, el proceso de moverlas a otro host podía ser dolorosamente lento. Por el contrario, con Hyper-V 3.0 será capaz de mover simultáneamente varias máquinas virtuales entre servidores host sin tiempo de inactividad.

Exchange e Hyper-V 3.0: Reglas de afinidad y mejoras en la conmutación por error

Los administradores de Exchange también deberían beneficiarse de las reglas de afinidad y anti-afinidad en Hyper-V 3.0. En Exchange Server, a menudo hay máquinas virtuales que nunca deberían residir en un servidor host de virtualización común. Por ejemplo, si va a distribuir las cargas de trabajo a través de múltiples servidores de acceso de cliente (CAS), no tiene sentido desde los puntos de vista de rendimiento y de tolerancia de fallos albergar varios servidores en un único host de virtualización.

Eche un vistazo a nuestra guía completa de virtualización de Exchange Server.

El problema aquí es que en situaciones de conmutación por error, las máquinas virtuales que fueron aisladas una de la otra, pueden terminar funcionando en un servidor común. Puede configurar las reglas de afinidad y anti-afinidad de Hyper-V 3.0 para que un grupo de máquinas virtuales pueda conmutar por error de forma colectiva (donde todas las máquinas virtuales de Exchange pueden conmutar por error como grupo), o para que determinadas máquinas siempre residan en hosts separados.

Microsoft ha realizado otras mejoras para la conmutación por error. Para empezar, los clústeres Hyper-V serán capaces de soportar hasta 63 servidores host y colectivamente albergar hasta 4000 máquinas virtuales. Más importante aún, Hyper-V 3.0 le permite dar prioridad a las máquinas virtuales en una situación de conmutación por error.

Supongamos por ejemplo que un servidor ha fallado y que todas las máquinas virtuales que se ejecutan en el host se trasladaron a otro servidor en el clúster. Si el servidor host restante ya está albergando algunas máquinas virtuales, puede que no disponga de los recursos del sistema para acoger todas las máquinas virtuales que se ejecutaban previamente en el servidor caído.

La priorización le permite especificar qué máquinas virtuales considera más importantes. Si hay una escasez de recursos del sistema, entonces las máquinas virtuales de alta prioridad, como los servidores de buzones, podrán tener prioridad sobre las máquinas virtuales menos importantes como los servidores concentradores de transporte redundantes.

Parece que finalmente Hyper-V se ha convertido en un hipervisor de verdadero nivel empresarial. No todas las organizaciones cambiarán a Hyper-V, pero con estas importantes mejoras, muchos negocios de Exchange estarán seguros de al menos evaluar un cambio desde VMware.

Acerca del autor:

Brien Posey ha sido ocho veces MVP de Microsoft con dos décadas de experiencia en TI. Antes de convertirse en escritor técnico freelance, trabajó como CIO de una cadena nacional de hospitales y centros de salud. También se ha desempeñado como administrador de redes para algunas de las compañías de seguro más grandes del país y para el Departamento de Defensa en Fort Knox.

Profundice más

Inicie la conversación

Envíenme notificaciones cuando otros miembros comenten sobre este artículo.

Por favor cree un Nombre de usuario para poder comentar.

- ANUNCIOS POR GOOGLE

Close