Be Geek My Friend

Daniel Matey, Ingeniero Preventa Datacenter, Microsoft

Virtualizando Exchange 2010

 

En este post voy a intentar responder a las cuestiones mas comunes que nos preguntáis acerca de la virtualización de Exchange 2010 que además son casi todas extrapolables a Exchange 2007.

¿Recomiendas virtualizar Exchange?

Lo que de verdad, de verdad recomendamos todos es que tu Exchange este diseñado, dimensionado y desplegado conforme a las buenas practicas y recomendaciones, esto es independiente de si lo virtualizas o no.

Un arquitectura de Exchange bien diseñada y dimensionada que sea desplegada sobre una plataforma de virtualización bien diseñada, dimensionada y gestionada funcionara tan bien como una desplegada sobre servidores físicos, sin embargo un Exchange virtualizado sobre una plataforma de virtualización improvisada seguro que nos da algún quebradero de cabeza y esto será igual virtualicemos con lo que virtualicemos ya sea Hyper-V u otro producto.

¿En que afecta el virtualizar o no virtualizar al diseño de Exchange?

En los documentos de diseño de Exchange 2010 veras que se suele decir que en nada, que debes realizar el diseño de igual forma que si fuera en físico.

Sin embargo en mi opinión si que afecta en dos cosas principalmente:

  • Probablemente vas a querer que ningún servidor virtual tenga mas de 4 procesadores virtuales, si trabajas para una empresa con miles y miles de buzones esto tendrá implicaciones para el numero máximo de buzones por servidor y en general para el numero de servidores que tendrás que desplegar.
  • Tu diseño tendrá que contemplar un capitulo mas que hable de como vas a alinear el despliegue de Exchange con el diseño actual de plataforma de virtualización y si es necesario algún cambio.

Espera, espera ¿Estas hablando de virtualizar también los servidores de Mailbox?

Todos los roles de Exchange con la excepción del rol de mensajería unificada están soportados virtualizados, esto incluye los servidores de Mailbox.

Sin embargo un rendimiento deficiente de los servidores de buzones seria horrible para tu servicio de correo y si vas a virtualizar este rol tienes que tener especial cuidado.

Si tienes varios miles de buzones a tu cargo probablemente elegir virtualizar tus servidores de buzones implicara que tengas algún servidor mas en virtual de lo que habrías tenido de desplegarlo en físico, sin embargo para muchos clientes las ventajas de gestión, alineamiento con la estrategia de arquitectura de la compañía, recuperación ante desastres, etc. hacen que puedas querer virtualizar estos servidores.

¿Que debo tener en cuenta especialmente al virtualizar un servidor de Mailbox?

El proceso es muy simple:

Toma tus decisiones en cuanto a las bases de datos de tu Exchange como si fueran físicos, ten en cuenta las copias que habrá en tu DAG, las copias de seguridad,  tipos de discos, etc.

Usa el Exchange Profile Analyzer (EPA) para entender el perfil de uso del correo en tu sistema actual (http://www.microsoft.com/downloads/en/details.aspx?familyid=C009C049-9F4C-4519-A389-69C281B2ABDA&displaylang=en ).

Con los datos del EPA usa el Exchange Storage Calculator (http://msexchangeteam.com/archive/2010/01/22/453859.aspx ) para calcular los requisitos de storage.

image

A mi me gusta ir mas que sobre seguro así que suelo aumentar el parámetro de sobrecarga de IO en el storage calculator en 10% mas.

image

Es muy importante que rellenemos todos los campos con la información mas ajustada posible y que realicéis varios cálculos con diferentes opciones, por ejemplo un aspecto muy importante son los tipos de discos:

image

El tamaño de las bases de datos tiene un impacto brutal en la carga esperada del sistema, RAM requerida, etc. seguir las recomendaciones que podéis encontrar en la technet y realizar varias simulaciones con diferentes tamaños hasta dar con el que se adecua a vuestros requisitos y por favor tener en cuenta los tiempos de recuperación al definir el tamaño estándar de vuestras bases de datos.

Por supuesto tenéis que especificar también el asunto de los 4 procesadores y los megaciclos que tienen vuestros procesadores (ojo con los ratios de consolidación, luego hablare de ello, lo de los megaciclos se explica en el blog del equipo de producto de Exchange, es fácil de calcular):

image

Algo que va a hacer la calculadora por nosotros es recomendarnos el nivel de Raid que tenemos que usar (si es que la cabina nos deja especificarlo) y finalmente en función de todos los parámetros introducidos nos dará las IOps:

image

Bien, pues aquí viene el aspecto clave de todo esto, tenemos que asegurarnos de que nuestros servidores de buzones tendrán las IOps que requieren.

Para ello la mejor forma es desplegar y configurar nuestras maquinas virtuales y su correspondiente almacenamiento y empezar a probar.

Yo lo hago así:

-Para terminar de diseñar el almacenamiento realizo unas primeras comparativas entre las diferentes opciones usando IOMeter con un perfil de IOPs parecido al de Exchange.

-Cuando ya tengo una decisión preliminar uso el JetStress para realizar la prueba definitiva con las mismas configuraciones de DAG, etc. que voy a desplegar en producción (http://www.microsoft.com/downloads/en/details.aspx?displaylang=en&FamilyID=13267027-8120-48ed-931b-29eb0aa52aa6) esta herramienta es la definitiva si el nivel de IOps esta por encima del que necesitamos podemos continuar adelante, si no tendremos que seguir haciendo cambios (una vez mas me gusta añadir un pequeño margen de seguridad)

Hay algunas consideraciones a tener en cuenta al diseñar el almacenamiento:

  • El numero de copias definirá si usas JBOD o no, si es que no, deberías usar RAID, esto es muy importante por que cada tipo de RAID como sabes tiene su impacto en las IOps.
  • Si usas FATA de 7200Rpm no uses RAID 5
  • Formatea los discos (tanto los físicos como los virtuales) con un allocation unit de 64Kb.
  • Alinea los discos si es necesario para tu storage, podemos estar hablando de una sobrecarga importante si los discos no están alineados.
  • Usa discos pass-through si puedes, si no puedes usa VHD fijo.
  • NUNCA, NUNCA uses discos virtuales que no sean de tamaño fijo y nunca uses instantáneas en los discos duros virtuales de las bases de datos o logs.
  • Dependiendo del diseño que hagas puede no ser necesario separar logs y bases de datos, tenlo en cuenta para reducir LUNs.

Exchange virtualizado tendrá que convivir en un mismo host con otras cargas, por favor ten en cuenta:

  • No esta soportado que el ratio de consolidación de procesadores virtuales sobre cores físicos en los hosts donde estén virtualizados lo Exchange sean mayor que 2:1 o sea en un host de 2 procesadores de 4 cores no deberías tener mas de 16 procesadores virtuales en total.
    • Yo no te recomendaría mas de 15 en realidad
    • Esto es igual uses Hyper-V, VMWare, lo que sea…
    • La calculadora de storage te dará una aproximación sobre la carga de micro que puedes esperar:

image

  •  
    •  
      • Asegúrate de sumar lo que necesites para el antivirus, agentes de monitorización, etc., suma un margen “prudencial” y si te da mas del 50% entonces tu ratio de consolidación procesadores virtuales/cores físicos deberá ser evaluado acorde.
  • En los servidores de buzones no uses técnicas de memoria dinámica, sobrecarga de memoria, swap o lo que sea, no tiene ningún sentido por como funciona Exchange 2010 en relación con la memoria.
  • No es normal que tengas problemas de contención con las HBA o la red, pero revisa el estado de capacity de tu plataforma de virtualización antes de sumar una carga tan importante.

Si vas a usar DAG, ten en cuenta que no esta soportado virtualizar los Mailbox con DAG sobre plataformas de virtualización que aporten su propia alta disponibilidad, esto una vez mas es igual para Hyper-V que para otras plataformas de virtualización con independencia de lo que te puedan decir, al final quien soporta o no Exchange es Microsoft asi que es a Microsoft a quien debemos hacer caso sobre lo que esta o no soportado.

Si vas a usar CSV, por favor no uses un CSV para todo, separa los sistemas operativos, las bases de datos, etc. en diferentes CSV, como buena practica proponte un tamaño de CSV estándar de entre 380Gb y 500GB y no los sobresatures.

Bien ya tengo mi Exchange 2010 virtualizado en producción, ¿cual es el consejo mas importante que me darías?

No hay ninguna duda: Monitoriza, monitoriza, monitoriza.

Usa una herramienta experta capaz de entender perfectamente Exchange y tu plataforma de virtualización, a ser posible que entienda también tu hardware, HBAs, cabinas, etc y que analice en tiempo real el rendimiento de tus servidores incluido el flujo de correo.

Si me preguntas, solo se de una que haga todo esto tanto para Hyper-V como para VMWare y es System Center Operations Manager 2007 R2, si no tienes la suerte de poder usarlo ni evaluarlo asegúrate de contar con la mejor monitorización que puedas.

Exchange virtualizado sin monitorizar no es una buena idea., de hecho virtualizar sin monitorizar no es una buena idea.

¿Junto o por separado?

Si tienes unos cuantos miles de buzones si sumas todos los roles en alta disponibilidad seguramente te darán suficientes VMs como para llenar 2 hosts normales así que te surgirá la pregunta de si juntar todos los roles o no.

Seria algo como esto por ejemplo:

image

En principio esta alternativa de diseño tiene de bueno que Exchange no se ve afectado por otras cargas y que el dimensionamiento por tanto es seguro.

En contra desde luego tiene que si pierdes un host pierdes mucha de la infraestructura y que el otro servidor asumirá toda la carga, pero se supone que para eso esta dimensionado.

Otra cosa a tener en cuenta sobre esta alternativa de diseño es que es muy poco “cómoda” para administrar, cuando tienes que reiniciar un host por algo tiene sus implicaciones y requerirá trabajo.

¿Y los EDGE?

Ningún problema virtualizalos también, son grandes candidatos para ello, pero por favor ten en cuenta que los EDGE tienen que estar en la DMZ y que DMZ y redes internas no redes tan diferentes a nivel de seguridad que te recomendaría encarecidamente que despliegues en la DMZ servidores específicos de virtualización sin conexión con tus redes internas.

Con el tiempo espero escribir un post sobre virtualización en DMZ.

¿Por que creemos que debes valorar Hyper-V R2 para virtualizar Exchange?

Si ya usas Hyper-V no me harás esta pregunta Winking smile si aun no lo usas aquí tienes los puntos que creo debes considerar:

  • Hyper-V al igual que Exchange son productos de Microsoft, esto implica grandísimas ventajas a tener en cuenta a la hora de virtualizar un servicio tan critico:
    • Como es lógico desde el comienzo del desarrollo los equipos de Microsoft realizan sus pruebas, despliegues y desarrollos sobre Hyper-V, esto implica que al final del desarrollo esta mas que garantizado que Exchange funcionara perfectamente sobre Hyper-V y que tendrá un fantástico rendimiento.
    • Por la misma razón es de esperar que nuevos Service Packs, parches, etc., siempre estarán probados sobre Hyper-V.
    • Si alguna vez tienes un problema y tienes que acudir a soporte de Microsoft por un problema con un Exchange sobre Hyper-V, el proceso de resolución como es lógico es mas eficiente comparación con otras soluciones, los técnicos de soporte especializados de Exchange estarán en contacto con los técnicos especializados de Hyper-V y Windows Server, el trabajo en equipo y el conocimiento en profundidad de todas las tecnologías implicadas es obvio que ayuda cuando estamos hablando de incidencias complicadas.
    • Por supuesto aplican las mismas razones generales de Hyper-V, mejores herramientas de gestión, ahorro de coste, etc, etc.

Y si de momento no voy a usar Hyper-V, ¿puedo virtualizar Exchange?

Claro, todo lo que he contado en este post aplica también a otras plataformas de virtualización.

Puedes consultar si la tuya esta soportada o no en este enlace: http://windowsservercatalog.com/svvp.aspx?svvppage=svvp.htm 

Conclusiones

Virtualiza si es tu decisión de arquitectura pero hazlo con garantías y criterio.

Espero que el post os haya sido de ayuda.

Un saludo para todos.

Crossposting from blogs.technet.com/dmatey

Posted: 9/12/2010 11:09 por Daniel Matey | con no comments
Comparte este post: