NetApp Tech OnTap
     

Exchange 2010 en VMware

Encontrar buenas razones para utilizar Microsoft® Exchange 2010 en VMware® es fácil:

  • Mejor utilización de los núcleos de procesador. Los grandes servidores de varios núcleos se están convirtiendo en la tendencia principal, pese a ello, la mayoría de las aplicaciones no aprovechan todos los núcleos en un servidor físico.
  • Aislamiento de funciones sin incremento de costes de hardware. Exchange 2010 ha evolucionado a una arquitectura modular con varias funciones de servidor que incluyen buzón, transporte periférico, transporte de concentradores y acceso a clientes. El aislamiento de estas funciones facilita enormemente la resolución de problemas con Exchange, pero también requiere un gran número de servidores físicos, especialmente en entornos pequeños.
  • Falta de aprovisionamiento excesivo. Siempre es complicado imaginar cómo afectará el futuro a los requisitos de Exchange. La utilización de Exchange en VMware implica que puede proporcionar los recursos apropiados ahora e ir añadiendo otros a medida que los necesite y evitar así costes innecesarios en aprovisionamiento excesivo.
  • Mayor cumplimiento de los requisitos de su empresa. El diseño de la implementación de Exchange depende de los requisitos específicos de cada caso. ¿Necesita un servidor de buzón independiente para cada departamento o unidad empresarial? La virtualización lo hace posible sin aumentar los costes de hardware ni el número de servidores físicos.
  • Aprovisionamiento rápido de un nuevo servidor de Exchange. El aprovisionamiento de un servidor físico es un proceso lento, incluso si ya cuenta con el hardware. Con VMware es fácil crear una plantilla para cada tipo de servidor de Exchange y guardarla para acelerar la implementación de servidores del mismo tipo más adelante.
  • Mantenimiento de un laboratorio de Exchange. ¿Necesita realizar el mantenimiento de un laboratorio para pruebas y resolución de problemas de Exchange? La virtualización de VMware es la base perfecta para los procesos de evaluación y pruebas de Exchange 2010.
  • Clonado para pruebas y resolución de problemas. Las copias y el clonado de Snapshot hacen posible el clonado rápido de cualquier equipo virtual concreto de Exchange destinado a la resolución de problemas.

A pesar de estas y otras ventajas, durante mis explicaciones sobre cómo utilizar Exchange en VMware, suelen surgir preguntas. En este artículo intentaré responder a las más frecuentes y compartir algunas de las mejores prácticas relacionadas con el uso de Exchange en entornos conjuntos de VMware y NetApp®.

¿Tengo asistencia?


El tema de la asistencia es bastante frecuente, ya que Microsoft a menudo ofrece productos de virtualización de la competencia. Recientemente, Microsoft realizó dos cambios en sus políticas de licencias y asistencia para VMware que se ocupan de muchas de las dudas que todavía persisten:

  • Compatibilidad de Exchange 2010 en una infraestructura de VMware/vSphere: VMware ESX™ 3.5 Update 2 fue el primer hipervisor que apareció en el Programa de validación de virtualización de servidor de Microsoft (SVVP). Este certificado proporciona a los usuarios de ESX 3.5 Update 2 o posterior (incluido vSphere), Windows® Server 2008 y Exchange Server 2007 SP1 o Exchange 2010 acceso a la asistencia técnica cooperativa de Microsoft y VMware.
  • Normativas más laxas para la movilidad de licencias de aplicación: Microsoft actualizó su normativa de concesión de licencias de Exchange para adaptarse mejor a su uso en un entorno virtual. Las licencias de aplicación todavía están ligadas a un servidor físico; sin embargo, Microsoft ha eliminado la cláusula que restringía la reasignación de un licencia de aplicación a una vez cada 90 días. Esto permite mantener el cumplimiento de normativas a la vez que se realizan migraciones de equipos virtuales y la alta disponibilidad en un entorno virtualizado.

Además de SVVP, también puede recibir asistencia directa para aplicaciones virtualizadas de Microsoft si se adhiere al programa Services Premier Support Program de Microsoft. Es posible que también disponga de soporte técnico a través de su proveedor OEM, soporte de servicios internacionales (GSS) de VMware y Technical Support Alliance Network (TSANet).

Encontrará más información sobre cómo obtener asistencia en la Guía de Microsoft Exchange 2010 sobre asistencia para VMware y licencias.

¿Se obtiene un buen rendimiento de Exchange en VMware?


Medición del rendimiento

En el caso de aplicaciones críticas como Exchange, es bien conocido el rendimiento que puede esperarse de un servidor físico, aunque todavía surgen dudas sobre el rendimiento en servidores virtualizados. La mejor manera de convencerse de que no habrá sorpresas desagradables respecto al rendimiento al virtualizar Exchange es observar las pruebas de rendimiento completas que se han realizado tanto en VMware como en NetApp. La mayoría se realizaron con Exchange 2007, pero creo que, dada la importante reducción de I/O en el paso de Exchange 2007 a Exchange 2010, puede estar seguro de que si el rendimiento con Exchange 2007 era bueno, lo seguirá siendo con Exchange 2010.

Observe un resumen del rendimiento de Exchange en VMware en la figura 1. Como ve, el rendimiento virtual siempre se encuentra en el 5% del rendimiento físico. Incluso con 4.000 usuarios, sólo se alcanzó un 25% del uso de CPU. El número de usuarios de uso intensivo escaló de forma lineal con CPU añadidas tanto en el caso físico como en el virtual.

Resumen del rendimiento de Exchange 2007 en entornos virtuales frente a físicos.

Figura 1) Resumen del rendimiento de Exchange 2007 en entornos virtuales frente a físicos.

Si quiere más información sobre mediciones de rendimiento, consulte un white paper reciente de VMware.

Mejores prácticas para VMware

VMware ha desarrollado un cuerpo completo de mejores prácticas para el uso de Exchange en entornos de VMware. Estas prácticas se resumen aquí. Para obtener todos los detalles, consulte la Guía de mejores prácticas de Microsoft Exchange 2010 en VMware.

Mejores prácticas para CPU virtuales (vCPU)

  • Asigne sólo varias vCPU a un equipo virtual si la carga de trabajo prevista de Exchange puede aprovechar realmente todas las vCPU.
  • Si no conoce la carga de trabajo exacta, empiece asignando un número menor de vCPU al equipo virtual y auméntelo más adelante si es necesario.
  • En el caso de equipos virtuales de Exchange de rendimiento crítico (por ejemplo, sistema de producción), intente que el número total de vCPU asignadas a los equipos virtuales es menor o igual que el número total de núcleos del equipo host ESX.

Mejores prácticas para la Memoria Virtual

  • No comprometa la memoria en exceso hasta que vCenter informe de que el uso constante es inferior a la cantidad de memoria física en el servidor.
  • Configure la reserva de memoria al tamaño configurado del equipo virtual para que resulte en un fichero intercambiable vmkernel de cero bytes por equipo virtual. Recuerde que establecer reservas puede limitar VMotion.
  • Es importante establecer el tamaño correcto de la memoria configurada de un equipo virtual. Se desperdiciará memoria si los equipos virtuales de Exchange no utilizan la memoria configurada.
  • Active Distributed Resource Scheduling (DRS) de VMware para asegurar que las cargas de trabajo se equilibran en el clúster de ESX. DRS y las reservas garantizan que las cargas de trabajo vitales cuentan con los recursos necesarios para funcionar a pleno rendimiento.
  • Para minimizar el intercambio de SO «guest», el tamaño configurado de los equipos virtuales debe ser mayor que el promedio de uso de memoria de Exchange que se ejecuta en el «guest». Siga las directrices de Microsoft para la configuración de ficheros de intercambio/página de equipos virtuales de Exchange.

Prácticas recomendadas de red

  • Asigne NICs/redes independientes para VMotion, tráfico de registro y gestión de acceso a la consola; también puede utilizar el etiquetaje VLAN.
  • Asigne al menos dos NICs para el tráfico de producción de Exchange para aprovechar las funciones conjuntas de NIC. Normalmente debe asignar al menos cuatro NICs por host ESX.
  • Utilice VMXNET3: un vNIC paravirtualizado que se instala con las herramientas de VMware. VMXNET3 está optimizado para entornos virtuales y diseñado para ofrecer un alto rendimiento.
  • Para dar soporte a VLANs en vSphere, la red virtual, o física, debe etiquetar los marcos Ethernet con etiquetas 802.1Q mediante etiquetaje de switch virtual (VST), etiquetaje de «guest» de equipos virtuales (VGT) o bien etiquejate de switch externo (EST). El modo VST es el más común.
  • Siga las directrices de diseño de redes en la sesión TA2105 de VMworld 2009: Conceptos de red virtual y mejores prácticas. Allí se incluyen diseños para gestionar correctamente varias redes y redundancia de adaptadores de red en hosts ESX.

Mejores prácticas para gestión de recursos y DRS

  • Los host ESX origen y destino deben estar conectados a la misma red gigabit y al mismo almacenamiento compartido.
  • Se recomienda una red gigabit dedicada para VMotion de VMware.
  • El host de destino debe contar con recursos suficientes.
  • El equipo virtual no debe utilizar dispositivos físicos como CD ROM o disco flexible.
  • Los hosts de origen y destino deben tener modelos de CPU compatibles; de lo contrario, la migración con VMotion de VMware no será posible.
  • Para minimizar el tráfico de red, se recomienda mantener unidos los equipos virtuales que se comunican entre sí (por ejemplo, buzón y GCs) en el mismo equipo de host.
  • Los equipos virtuales con tamaños de memoria más reducidos son más apropiados para la migración que los mayores.

Mejores prácticas de almacenamiento

  • Implemente equipos virtuales de Exchange en almacenamiento compartido para permitir VMotion, HA y DRS.
  • Acceso múltiple al almacenamiento: establezca un mínimo de cuatro accesos desde un servidor ESX a una cabina de almacenamiento (son necesarios al menos dos puertos HBA).
  • Cree sistemas de ficheros VMFS desde VirtualCenter para obtener la mejor alineación de particiones.

Mejores prácticas para el rendimiento con almacenamiento de NetApp

NetApp ha desarrollado mejores prácticas adicionales para el uso de Exchange 2010 con el almacenamiento de NetApp. Estas aparecen desarrolladas en un artículo reciente de Tech OnTap y de en un informe técnico detallado e incluyen los mejores métodos para aprovechar las ventajas de las funciones de eficiencia del almacenamiento de NetApp.

Por ejemplo, la combinación de la deduplicación de NetApp con thin provisioning puede aportar de un 40 a un 60% de ahorro en almacenamiento en entornos de Exchange 2010.

Existen trabajos recientes que se centran en métodos para optimizar el rendimiento de Exchange con almacenamiento de NetApp. Al realizar pruebas con Microsoft Exchange 2010, la adición de Flash Cache dobló la cantidad de OPs que se obtuvieron y aumentó el número de buzones admitidos en un 67%. Estos resultados se describen en TR-3867: Uso de Flash Cache para Exchange 2010 publicado en septiembre de 2010.

¿Cómo puedo conseguir HA y DR?


La creación de configuraciones flexibles de alta disponibilidad (HA) y recuperación ante desastres (DR) para Exchange 2010 es, en realidad, más fácil y económico en un entorno virtualizado. Hay más opciones y más flexibilidad para la protección de datos a todos los niveles.

Para poder configurar HA y DR, es necesario conocer primero los cambios significativos que Microsoft realizó en sus opciones de resistencia nativa para Exchange 2010.

Para sustituir las opciones de resistencia de servidor y datos de versiones anteriores de Exchange, Microsoft implementó el grupo de disponibilidad de bases de datos (DAG). DAG utiliza la misma función de transvase de registros que utilizaba la replicación continua en clúster (CCR) en Exchange 2007. Un DAG consta de entre 2 y 16 servidores de buzón. Cada servidor de buzón puede tener una o varias copias activas o pasivas de una base de datos. Cada base de datos tiene un estado diferente, por lo que un servidor puede alojar copias de varias bases de datos y tener sólo algunas de las copias activas a la vez.

DAG utiliza un nuevo componente de Exchange llamado Active Manager que facilita la recuperación tras fallos y la automática. En caso de fallo (incluidos los fallos en almacenamiento de base o en la conectividad del almacenamiento), Exchange 2010 "promociona" una de las copias de la base de datos al estado activo; la función de buzón toma la tarea de ofrecer los buzones en esa base de datos. La recuperación tras fallos se produce en menos de 30 segundos.

Protección contra fallos localizados

VMware ofrece una gran cantidad de mecanismos posibles para proteger la disponibilidad de Exchange 2010 contra fallos locales.

  • HA de VMware en sí mismo puede actuar de protección contra tiempos de inactividad causados por fallos en el hardware local.
  • La combinación de VMware y DAG le protege contra fallos de hardware y software, a la vez que reduce el periodo en el que la base de datos está desprotegida en comparación con el único uso de DAG.

Protección contra fallos del centro

Para protegerse contra este tipo de fallos, VMware sugiere la combinación de VMware Site Recovery Manager (SRM) con la función DAG. DAG ofrece protección local, mientras que la replicación basada en almacenamiento, como por ejemplo SnapMirror® de NetApp se utiliza para mantener una unidad DR sincronizada con el centro principal. SnapManager® para Exchange de NetApp ofrece una replicación que tiene en cuenta las aplicaciones para asegurar la consistencia. Si se inicia la recuperación en la unidad DR, SRM automatiza y acelera el proceso de recuperación. Colaboradores de VMware y NetApp explicaron los detalles de DR para aplicaciones de Microsoft (incluido Exchange) mediante SRM en una reciente Mesa redonda de Tech OnTap.

Arquitectura de replicación para SRM con software SnapMirror y SnapManager de NetApp.

Figura 2) Arquitectura de replicación para SRM con software SnapMirror y SnapManager de NetApp.

Estos y otros métodos para HA y DR se explican detalladamente en Microsoft Exchange 2010 en VMware: Opciones de disponibilidad y recuperación.

Mejores prácticas para NetApp

NetApp ha establecido algunas de las mejores prácticas que pueden aplicarse a entornos de Exchange que utilizan DAGs:

  • Microsoft recomienda un mínimo de tres copias de cada base de datos de buzón para limitar las exposiciones causadas por posibles fallos de almacenamiento, incluidos los fallos de dos discos. NetApp recomienda implementaciones de almacenamiento de NetApp mediante RAID-DP®, que puede proteger contra fallos de dos discos a la vez que reduce el número de copias de bases de datos del buzón. Se recomiendan dos copias de cada base de datos de buzón si las copias se encuentran en RAID-DP.
  • Cada copia de DAG está actualizada y como tal, no sustituye los backup. Para permitir las restauraciones puntuales, Microsoft recomienda una copia de base de datos adicional de "intervalo" que permita restauraciones puntuales de hasta 14 días atrás. Como alternativa, NetApp ofrece SnapManager para Exchange, que permite crear copias de Snapshot que permiten ahorrar espacio y realizar restauraciones en cualquier momento sin que sea necesaria una copia de intervalo.
  • El almacenamiento de copias activas y pasivas debería ser idéntico en capacidad y rendimiento.
  • Las copias activas y pasivas deben colocarse en volúmenes independientes.
  • Backups en uno de los nodos pasivos

Conclusión

Las tasas de adopción de Exchange 2010 han sido altas y se está prestando mucha atención a la virtualización. VMware ha trabajado para desarrollar una completa colección de material de referencia y otros recursos para ayudarle a virtualizar correctamente Exchange 2010. Acceda a toda la colección aquí. Encontrará información sobre planificación de capacidad, tamaños y muchos otros temas.

VMware también ha trabajado de forma significativa para probar y desarrollar soluciones de Exchange combinadas con partners importantes como NetApp. Tech OnTap ha publicado recientemente algunos artículos que se centran en la virtualización de Exchange y de otras aplicaciones de Microsoft. (Ver barra lateral). Acceda a la colección completa de recursos de NetApp en la página de Exchange de NetApp.

Comunidad de NetApp
 ¿Le gustaría opinar sobre Exchange 2010 en VMware con almacenamiento de NetApp?

Formule preguntas, intercambie ideas y comparta sus opiniones en las comunidades online de NetApp.

Scott Salyer

Scott Salyer
Diseñador Jefe-Microsoft Solutions
VMware

Scott es parte del grupo Solution Readiness de VMware, centrado en las mejores prácticas de virtualización para aplicaciones empresariales de Microsoft. Scott se unió a VMware en mayo de 2007 y es autor de numerosos white papers de Exchange y SQL Server® sobre la página web de aplicaciones críticas para empresas de VMware™. Antes de unirse a VMware, Scott trabajó 11 años como consultor de servicios profesionales de cara al cliente, ayudando a importantes clientes a diseñar e implementar soluciones centradas en la virtualización de VMware, aplicaciones de Microsoft y gestión de identidad/acceso.

 
En profundidad