Microsoft Exchange 2010: Cómo establecer un centro de datos virtual con Exchange 2010
Algunas prácticas recomendadas útiles para planificar e implementar una infraestructura virtual con Exchange.
Brien M. Posey
Virtualización de servidores se ha convertido en la norma, pero la planificación de la virtualización es todavía algo de una forma de arte. Esto es especialmente cierto cuando usted está planeando virtualizar Exchange Server. Tienes que implementar Exchange con rendimiento y tolerancia a fallas en la mente. Agregar el reto es el hecho de que abarcan la mayoría de las implementaciones de Exchange Server en múltiples servidores.
Debe tener en cuenta todas las recomendaciones presentadas aquí se basan en la plataforma de virtualización Hyper-V. No quiere decir que no se pueden utilizar otras plataformas de virtualización. El oficial Microsoft apoyar política Estados puede ejecutar Exchange en "cualquier tercero hipervisor que ha sido validado en el programa de validación de virtualización de servidor de Windows." En la actualidad, Citrix Systems Inc. VMware Inc. y un número de otros proveedores de virtualización participa en este programa.
La partición primaria
Al planear e implementar una infraestructura virtual de Exchange Server, es importante asignar recursos suficientes para la partición principal (que ejecuta la administración OS). No reservar recursos suficientes puede afectar a todos los servidores virtuales que se ejecutan en un servidor host.
Microsoft recomienda reservar al menos 1 GB de memoria para la partición primaria y la administración de OS. Si está ejecutando Hyper-V en la parte superior de una instalación completa de Windows Server 2008 o Windows Server 2008 R2, debe considerar nunca reserva 2 GB de memoria para la administración de OS para el sistema operativo funciona bajo en recursos.
Microsoft también recomienda dedicar un controlador de interfaz de red (NIC) para fines de gestión. Si se desea usar Live migración, debe dedicar una NIC para el proceso de migración en vivo. Cabe señalar que Microsoft no soporta migración en vivo de la función del servidor buzón de correo si el servidor de buzones es un miembro de un grupo de base de datos de disponibilidad (DAG).
Configuración de disco virtual
Exchange Server y Hyper-V son muy flexibles con respecto al aprovisionamiento de almacenamiento. Aún así, hay algunas mejores prácticas recomendadas de Microsoft en cuanto a configuración de almacenamiento para servidores virtualizados de Exchange.
Hyper-V crea con thin provisioning los discos duros virtuales (VHD) por defecto. Esto significa que independientemente de cuán grande creas tu VHD, Hyper-V creará inicialmente un archivo VHD que es menos de un gigabyte en tamaño. Este archivo VHD dinámicamente se expande cuando se agregan datos.
Aunque thin provisioning puede ayudar a reducir el consumo de espacio de disco, los discos duros virtuales con thin provisioning no realizar, así como discos de longitud fija. Ese es el caso, Microsoft recomienda que utilizar discos de longitud fija sólo para servidores virtualizados de Exchange.
La configuración del disco actual que debe utilizar variará dependiendo de la función de servidor, pero hay algunas pautas generales que tienen validez para todos los roles de servidor. Para empezar, Microsoft recomienda que dedicar un disco físico (LUN) a la administración de OS. Ello garantiza la gestión que no OS estarán compitiendo para recursos de disco con las máquinas virtuales (VMs).
Microsoft también recomienda proporcionar un LUN dedicado al sistema operativo en cada uno de los servidores virtuales. El VHD que contiene al sistema operativo huésped debe ser lo suficientemente grande como para almacenar Windows Server y el archivo de página. El tamaño del archivo de página generalmente es igual a la cantidad de RAM asignado a la máquina virtual.
Como tal, la recomendación de Microsoft es darle el invitado OS 15 GB, además de equivalente de espacio a la cantidad de memoria asignada a la máquina virtual. Por lo tanto, un servidor virtual de Exchange con 4 GB de RAM teóricamente tendría unos 19 GB de espacio en disco para el volumen que contiene el sistema operativo.
Antes de comenzar realmente asignar recursos de disco, hay un par de cosas a considerar. Observará que no he mencionado el espacio consumido por binarios de Exchange Server. El requisito de 15 GB toma esto en cuenta. Windows Server 2008 requiere un mínimo de 10 GB de espacio en disco. La instalación predeterminada de Exchange Server polivalente inicialmente consume aproximadamente unos 2,5 GB de espacio en disco (que puede cambiar como mover cosas).
Todavía es una buena idea para agrandar sus volúmenes de sistema operativo huésped un poco por dos razones. En primer lugar, la recomendación de 15 GB sólo cumple con requisitos de disco mínimo de Windows Server 2008. El requisitos del sistema para Windows Server 2008 recomienda específicamente 40 GB o más. Máquinas con más de 16 GB de RAM se requieren espacio adicional en disco para paginación, hibernación y archivos de volcado.
Planificar por adelantado
Los servidores virtuales son muy flexibles en términos de asignación de hardware. Puede agregar memoria a un servidor virtual en un capricho. Ese es el caso, es una buena idea comenzar con un VHD más grande que el que realmente necesita por lo que fácilmente puede acomodar la expansión de memoria futura. Estas recomendaciones se aplican a los VHD que contiene el equipo invitado OS y los binarios de Exchange. Microsoft también recomienda crear VHD adicional de uno o más de almacenamiento de datos.
Por ejemplo, si se crea un servidor concentrador de transporte, que desea crear un VHD secundario para dar cabida a las colas de mensajes. Para un servidor de buzón virtual, debe crear dos discos duros virtuales adicionales: uno para las bases de datos de buzones de correo y otra para los archivos de registro de transacciones.
Microsoft no parece subrayar el hardware de almacenamiento de información real, excepto con respecto a los servidores de buzones. Para ellos, Microsoft recomienda utilizar SCSI virtual. El método preferido implica el uso de paso de SCSI, pero también son aceptables los discos fijos.
Exchange también soporta almacenamiento iSCSI para servidores de buzones. Si elige almacenamiento iSCSI, Microsoft recomienda que configurar el iniciador iSCSI dentro de la administración de OS, en lugar de en los equipos cliente. Microsoft admite mediante el iniciador iSCSI dentro de una máquina de invitado, pero hacerlo así elimina el soporte de marco "Jumbo". También resulta menor rendimiento que se obtendría si se ejecutaba el iniciador iSCSI en la partición primaria.
Al configurar el iniciador iSCSI en la partición primaria, puede presentar los objetivos iSCSI conectados a sistemas operativos huéspedes. Quienes deben configurarse para tratar los objetivos iSCSI como discos de paso a través de SCSI.
Tolerancia a errores
Hyper-V y Exchange 2010 ofrecen sus propios fallos mecanismos de tolerancia. Hyper-V soporta clusters de failover basado en host. Exchange 2010 proporciona DAGs. Estas soluciones tolerantes a dos fallas trabajan de forma completamente diferente, por lo que es importante elegir la solución tolerante a fallas que funcionará mejor para su organización.
Si está familiarizado con DAGs, se trata de un mecanismo de intercambio 2010 en el que puede combinar hasta 16 servidores de buzones de correo en un solo grupo. Puede replicar bases de datos de buzones individuales para cualquiera de los miembros de DAG, proporcionando protección en el caso de una falla.
En contraste, obras clustering basado en host, Hyper-V, vinculando varios servidores Hyper-V para un clúster compartieron volumen. En el caso de una falla en el servidor host, las máquinas virtuales que residen en el host que ha fallado pueden hacer failover a un host alternativo.
¿Por lo tanto qué solución tolerante debe utilizar? El primer aspecto a considerar es el nivel de protección que cada uno proporciona. DAGs ofrecen protección de datos nativa Exchange, que proporciona control de failover automático en el nivel de base de datos. Como tal, DAGs pueden proteger contra fallas de servidor, red y base de datos.
Hyper-V Host-Based Failover Clustering opera a nivel de host de virtualización. No es una solución compatible con Exchange, por lo que no puede protegerle frente a un error de base de datos. Sólo puede proteger contra un servidor o un fallo en la red. Su dependencia de un volumen de clúster compartido significa que bajo las circunstancias correctas, el almacenamiento compartido podría convertirse en un punto único de falla.
Aunque estos factores pueden favorecer el uso de DAGs, hay otras consideraciones. Uno es que DAGs sólo pueden alojar servidores de buzones, no ofrecen protección a cualquier otras funciones de servidor de Exchange.No quiere decir que no pueden alcanzar un grado de tolerancia a nivel de intercambio para las otras funciones de servidor. Exchange utilizará automáticamente cualquier servidores de transporte de concentradores redundantes disponibles. Puede cargar saldo un servidor de transporte perimetral y servidor de acceso de cliente (CAS) mediante un DNS ronda instalación de robin, pero realmente no es una buen nivel de intercambio tolerante solución de fallas para estas funciones.
Dada la vulnerabilidad de los servidores de Exchange no buzón, su mejor opción podría ser el doble. Crear un DAG para servidores de correo y utilizar basado en Host de clúster de conmutación por error para proteger las otras funciones de servidor de Exchange. Sin embargo, lograr este tipo de protección no es tan sencillo.
Te vas a encontrar algunas restricciones al iniciar la virtualización miembros de DAG. Por un lado, no puede alojar a un miembro DAG virtualizado en un servidor de Hyper-V que es un miembro de un clúster de conmutación por error basada en Host. Exchange no le impide hacerlo, pero no es una configuración admitida. De hecho, Microsoft desaconseja mezcla DAGs y basado en Host y clústeres de conmutación por error.
La otra cosa es que usted realmente no puede salirse con poner a varias miembros de DAG en un servidor de host único. Ello socavaría completamente la protección que proporciona el DAG. Si el servidor host, cada servidor de buzones en el host también fallaría. En esta configuración, el servidor se convierte en un punto único de falla que potencialmente podría forzar todo el DAG sin conexión.
No hay empresa Microsoft directrices relativas a la disposición de los servidores de Exchange virtualizado para proporcionar la mejor tolerancia a errores, pero hay varias alternativas. Intente crear un clúster de conmutación por error basado en Host y utilizarlo para alojar el servidor de transporte perimetral y CAS. Si necesita proporcionar equilibrio a estas funciones de servidor de carga, considere crear clústeres de conmutación por error adicionales basado en Host y alojamiento de un servidor de transporte perimetral y un CAS en cada grupo. Puede utilizar una combinación de DNS round robin y redundantes registros MX para equilibrar la carga entre los servidores virtuales disponibles.
Tal vez ha notado ninguna mención de mensajería unificada. Derecho ahora, Microsoft no soporta servidores virtualizados Unified Messaging. Sin embargo, Exchange 2010 SP2 agregará este apoyo.
También puede crear servidores de Hyper-V no agrupado. Cada uno de estos servidores no agrupado debe alojar un servidor de buzones de correo y un servidor concentrador de transporte. Hacer que cada servidor buzón un miembro DAG y crear al menos dos concentrador de transporte servidores virtualizados para cada sitio de Active Directory.
Con esta configuración, los DAGs protegerá contra el servidor de buzones o error de base de datos de buzones individuales. Los servidores de transporte de concentradores redundante proporcionan redundancia de nivel de transporte.
Único lo que falta en esta arquitectura es un servidor de carpetas públicas. Durante algún tiempo Microsoft ha dicho que se van las carpetas públicas. Si se puede, esto sería un buen momento para comenzarles gradualmente. Si debe continuar utilizando las carpetas públicas, debe comprender por qué un DAG no puede proteger bases de datos de carpetas públicas. La única manera para proporcionar tolerancia a fallos para servidores de carpetas públicas es replicar las carpetas públicas en varios servidores de buzón.
Como puede ver, hay un montón de planificación que va a construir una infraestructura virtualizada de intercambio, con sus consideraciones principales ser hardware asignación y tolerancia a fallas. Teniendo presentes estos factores ayudará a guiarlo hacia el desarrollo de una infraestructura sólida y confiable.
.jpg)
**Brien M. Posey**es un profesional más valioso Microsoft y escritor técnico con miles de artículos y decenas de libros en su haber. Puede visitar su sitio Web en brienposey.com.
Contenido relacionado