Desmitificación de la virtualización de Exchange 2010 SP1

Artículo original publicado el martes 11 de octubre de 2011

Han pasado algunos meses desde que anunciamos algunos cambios importantes en nuestras declaraciones de compatibilidad de la virtualización para Exchange 2010 (véase Anuncio de compatibilidad de virtualización mejorada de hardware para Exchange 2010). Durante ese tiempo, he recibido bastantes preguntas interesantes sobre escenarios específicos de implementación y cómo estas implementaciones podrían afectar a los cambios en nuestras declaraciones de compatibilidad. Dado el volumen de preguntas, parecía un momento perfecto para publicar información y aclaraciones adicionales.

Antes que nada, un poco de antecedentes. Cuando hicimos los cambios a nuestras declaraciones de compatibilidad, quisimos asegurarnos principalmente de que nuestros clientes no se encontraran en una situación en que la disponibilidad del servicio de Exchange se viera reducida como resultado de usar una implementación virtualizada. Dicho de otra manera, quisimos asegurarnos de que el alto nivel de disponibilidad que se puede alcanzar con una implementación física del producto de Exchange 2010 no se redujera de ninguna manera por la implementación en una plataforma de virtualización. Por supuesto, también quisimos asegurarnos de que el producto mantuviera sus funciones y comprobamos que la funcionalidad adicional proporcionada por la pila de virtualización no supusiera la posibilidad de pérdida de datos de Exchange durante el funcionamiento normal.

Expuestos estos puntos, a continuación se incluye una introducción rápido a los cambios que realizamos y a su significado.

Con Exchange 2010 SP1 (o posterior) implementado:

• Todos los roles de servidor de Exchange 2010, incluida la Mensajería unificada, se admiten en una máquina virtual.
• Las máquinas virtuales con Mensajería unificada tienen los siguientes requisitos espaciales:
  • Se requieren cuatro procesadores virtuales para la máquina virtual. La memoria debe dimensionarse usando procedimientos recomendados estándar.
  • Hay disponibles cuatro núcleos de procesador físico para ser usados en todo momento por cada máquina virtual con rol de Mensajería unificada. Este requisito significa que no se puede usar ninguna sobresuscripción de procesador. Este requisito afecta a la capacidad de la máquina virtual con rol de Mensajería unificada para usar recursos de procesador físico.
• Las máquinas virtuales de servidor de Exchange (incluidas las máquinas virtuales con buzón de Exchange que forman parte de un DAG), se pueden combinar con clústeres de conmutación por error basados en host y tecnología de migración, siempre que las máquinas virtuales estén configuradas de modo que no guarden y restauren el estado en disco cuando se muevan o pasen a estar sin conexión. La actividad de conmutación por error debe resultar en un arranque en frío cuando la máquina virtual se active en el nodo de destino. La migración planificada debe resultar en el apagado o arranque en frío, o en una migración en línea que use una tecnología como la migración en vivo de Hyper-V. La migración del hipervisor de las máquinas virtuales es admitida por el proveedor del hipervisor; por lo tanto, debe asegurarse de que su proveedor de hipervisor haya probado y admita la migración de las máquinas virtuales de Exchange. Microsoft admite la migración en vivo de Hyper-V de estas máquinas virtuales.

Veamos algunas definiciones para asegurarnos de que todos pensamos del mismo modo con respecto a los términos de estas declaraciones de compatibilidad.

• Arranque en frío Hace referencia a la acción de llevar un sistema de un estado de desconexión a un inicio limpio del sistema operativo. En este caso no persiste ningún estado del sistema operativo.
• Estado guardado Cuando se desconecta una máquina virtual, los hipervisores normalmente tienen la capacidad de guardar el estado de la máquina virtual en ese momento determinado de modo que cuando la máquina se vuelve a conectar vuelve al estado en vez de ejecutarse un "arranque en frío". El "estado guardado" sería el resultado de la operación "Guardar" en Hyper-V.
• Migración planificada Cuando un administrador del sistema inicia el paso de una máquina virtual desde un host de hipervisor a otro se denomina migración planificada. Esta podría ser una sola migración, o el administrador del sistema podría configurar una automatización que se encargue de mover la máquina virtual conforme a un tiempo programado o como resultado de algún evento que se produzca en el sistema aparte de un error de hardware o software. La clave es que la máquina virtual de Exchange funcione con normalidad y que debe reubicarse por alguna razón: esto se puede realizar a través de una tecnología como la migración en vivo o vMotion. Si la máquina virtual de Exchange o el host de hipervisor en que se encuentra la VM experimenta algún tipo de estado de error, el resultado de esto no sería "planificado".

Virtualización de servidores con Mensajería unificada

Uno de los cambios realizados fue agregar la compatibilidad del rol de Mensajería unificada en Hyper-V y otros hipervisores admitidos. Como he mencionado al comienzo de este artículo, quisimos asegurarnos de que cualquier cambio que realizáramos en nuestra declaración de compatibilidad no afectara a la funcionalidad total del producto y proporcionara el mejor servicio posible a nuestros usuarios. A tal fin, necesitamos que Exchange Server 2010 SP1 se implemente para admitir la UM. La razón para ello es bastante sencilla. El rol de UM es dependiente en un componente multimedia proporcionado por el equipo de Microsoft Lync. Nuestros asociados de Lync hicieron un trabajo previo a la versión de Exchange 2010 SP1 para habilitar el procesamiento de audio en tiempo real de alta calidad en una implementación virtual, y en la versión de SP1 de Exchange 2010 integramos estos cambios en el rol de UM. Una vez realizado esto, hicimos una prueba adicional para asegurarnos de que la experiencia del usuario fuera lo más óptima posible y modificamos nuestra declaración de compatibilidad.

Como observará, tenemos requisitos específicos en torno a la configuración de la CPU para máquinas virtuales (y los equipos host de hipervisor) donde se ejecuta la UM. Este es un seguro adicional frente a la experiencia pobre del usuario (que se reflejaría con una calidad de voz pobre).

Clústeres de conmutación por error basados en host y migración

Gran parte de la confusión en torno a la declaración de compatibilidad modificada radica en los detalles sobre la combinación de clústeres de conmutación por error basados en host y la tecnología de migración con el DAG de Exchange 2010. La guía aquí es bastante sencilla.

• En primer lugar, abordaremos si se admite tecnología de migración de terceros (como vMotion de VMware). Microsoft no puede realizar declaraciones de “compatibilidad” para la integración de productos de hipervisor de terceros que usan estas tecnologías con Exchange 2010, ya que estas tecnologías no forman parte del Programa de validación de virtualización del servidor (SVVP) que cubre los otros aspectos de nuestra compatibilidad para hipervisores de terceros. Aquí realizamos una declaración genérica de compatibilidad pero, aparte, debe asegurarse de que su proveedor de hipervisor admita la combinación de su tecnología de migración/clústeres con Exchange 2010. Dicho de la manera más sencilla posible: si su proveedor de hipervisor admite su tecnología de migración con Exchange 2010, nosotros admitimos Exchange 2010 con su tecnología de migración.

• En segundo lugar, hablaremos de cómo definimos los clústeres de conmutación por error basados en host. Esto hace referencia a cualquier tipo de tecnología que proporciona la capacidad automática de reaccionar ante errores a nivel de host e iniciar VM afectadas en servidores alternativos. El uso de esta tecnología está totalmente admitido en la declaración de compatibilidad proporcionada teniendo en cuenta que, en un escenario de error, la VM viene de un arranque en frío en un host alternativo. Queremos asegurarnos de que la VM no vuelva nunca de un estado guardado que persiste en un disco, ya que quedará "obsoleta" en relación con el resto de los miembros del DAG.

• En tercer lugar, respecto a la tecnología de migración de la declaración de compatibilidad, hablamos de cualquier tipo de tecnología que permite un paso planificado de una VM desde un equipo host a otro. De manera adicional, este podría ser un paso automatizado que se produce como parte de un equilibro de carga de recursos (pero no está relacionado con un error en el sistema). Las migraciones están totalmente admitidas siempre que la VM no vuelva de un estado guardado que persiste en el disco. Esto significa que la tecnología que mueve una VM transportando el estado y la memoria de la VM por la red sin tiempo de inactividad percibido es compatible para su uso con Exchange 2010. Tenga en cuenta que un proveedor de hipervisor de terceros debe proporcionar la compatibilidad para la tecnología de migración, mientras que Microsoft proporcionará la compatibilidad para Exchange cuando se use en esta configuración. En el caso de Hyper-V de Microsoft, esto significaría que la migración en vivo es admitida, pero no lo es la migración rápida.

Con Hyper-V, es importante saber que el comportamiento predeterminado al seleccionar la operación “Mover” en una VM es, de hecho, realizar una migración rápida. Para permanecer en un estado admitido con los miembros del DAG de Exchange 2010 SP1, es primordial que ajuste este comportamiento tal como se muestra en la configuración de la VM a continuación (la configuración mostrada aquí representa cómo debería realizar la implementación con Hyper-V):

Figura 1: El comportamiento correcto de la máquina virtual Hyper-V para los miembros del Grupo de disponibilidad de base de datos

Recapitulemos. En Hyper-V, la migración en vivo es compatible para los miembros del DAG pero no la migración rápida. Visualmente, esto significa que se admite lo siguiente:

Figura 2: La migración en vivo de los miembros del Grupo de disponibilidad de base de datos en Hyper-V es compatible (ver captura de pantalla ampliada)

Y esto no es compatible

Figura 3: La migración rápida de los miembros del Grupo de disponibilidad de base de datos no es compatible

Esperamos que esto aclare nuestra declaración de compatibilidad y guía para los cambios de SP1. Esperamos cualquier comentario que nos quiera hacer llegar.

Jeff Mealiffe

Esta es una entrada de blog localizada. Puede encontrar el artículo original en Demystifying Exchange 2010 SP1 Virtualization