Exportar (0) Imprimir
Expandir todo

Soluciones probadas de Exchange 2010: 32 400 buzones en tres sitios ejecutando Hyper-V en servidores blade Cisco Unified Computing System y la solución de almacenamiento EMC CLARiiON

 

Última modificación del tema: 2012-03-05

Rob Simpson, Gerente del programa, Microsoft Exchange; Boris Voronin, Ingeniero de soluciones Sr., Ingeniería de soluciones de Exchange, EMC; Mike Mankovsky, Arquitecto de soluciones de Microsoft, Cisco

junio de 2011

En las soluciones comprobadas de Exchange 2010, Microsoft y los socios de la red, almacenamiento y servidores participantes examinan los escenarios comunes para los clientes y los puntos clave sobre la decisión del diseño que enfrentan los clientes que planean implementar Microsoft Exchange Server 2010. En esta serie de notas del producto, proporcionamos ejemplos de soluciones de Exchange 2010 rentables, bien diseñadas e implementadas en hardware suministrado por algunos de nuestros socios de la red, almacenamiento y servidores.

Puede descargar este documento del Centro de descargas de Microsoft.

Microsoft Exchange Server 2010 con Service Pack 1 (SP1)

Windows Server 2008 R2

Windows Server 2008 R2 Hyper-V

Tabla de contenido

En este documento, se ofrece un ejemplo de cómo diseñar, probar y validar una solución de Exchange Server 2010 que ejecuta la tecnología Windows Server 2008 R2 Hyper-V para el entorno de un cliente con 32 400 buzones implementados en servidores blade de Cisco Unified Computing System y las soluciones de almacenamiento EMC CLARiiON. Uno de los principales desafíos del diseño de entornos más grandes de Exchange 2010 es examinar las opciones de servidores y almacenamiento que están disponibles actualmente y tomar las decisiones de hardware adecuadas que ofrezcan el mayor valor sobre la vida útil prevista de la solución. Al seguir la metodología paso a paso en este documento, analizaremos los puntos importantes de la decisión del diseño que ayudan a abordar dichos desafíos clave y, al mismo tiempo, garantizan el cumplimiento de los requisitos empresariales básicos de los clientes. Después de determinar la solución óptima para este cliente, la solución atraviesa un proceso de validación estándar para garantizar el mantenimiento bajo cargas de trabajo de producción simuladas en escenarios normales de funcionamiento, mantenimiento y fallas.

Soluciones comprobadas de Exchange 2010

En las tablas siguientes, se resumen los principales componentes de hardware y de Exchange de esta solución.

Componentes de Exchange

Componente de Exchange Valor o descripción

Recuento de buzones de destino

32400

Tamaño promedio del buzón de destino

2 gigabytes (GB) [con aprovisionamiento fino de 600 megabytes (MB) de tamaño inicial]

Perfil de mensajes promedio de destino

100 mensajes por día

Número de copias de la base de datos

3

Copia de seguridad del Servicio de instantáneas de volumen (VSS)

Ninguno

Resistencia del sitio

Número de sitios

3

Modelo del grupo de disponibilidad de base de datos (DAG)

Distribución activa/activa (varios DAG)

Virtualización

Hyper-V

Número de servidores Exchange

4 máquinas virtuales (VM)

Número de servidores físicos

2

Componentes de hardware

Componente de hardware Valor o descripción

Socio del servidor

Cisco

Modelo de servidor

M200

Tipo de servidor

Blade

Procesador

Intel Xeon X5570

Socio de almacenamiento

EMC

Modelo de almacenamiento

CX4-480

Tipo de almacenamiento

Red de área de almacenamiento (SAN)

Tipo de disco

450 GB 15 000 SAS de 3,5"

Socio de equilibrio de carga

Cisco

Modelo de equilibrio de carga de hardware

Ace

Soluciones comprobadas de Exchange 2010

Uno de los primeros pasos más importantes en el diseño de una solución de Exchange consiste en resumir de forma precisa los requisitos empresariales y técnicos que resultan esenciales para tomar las decisiones correctas de diseño. En las siguientes secciones, se describen los requisitos de los clientes para esta solución.

Soluciones comprobadas de Exchange 2010

Determine los requisitos del perfil de buzón con la mayor precisión posible, ya que estos pueden afectar todos los demás componentes del diseño. Si no conoce Exchange, es posible que deba realizar ciertas suposiciones informadas. Si tiene un entorno de Exchange existente, puede usar la herramienta Microsoft Exchange Server Profile Analyzer para obtener asistencia en la recopilación de la mayor parte de esta información. En las siguientes tablas, se resumen los requisitos del perfil de buzón para esta solución.

Requisitos de recuento de buzones

Requisito de recuento de buzones Valor

Recuento de buzones (recuento total de buzones incluidos los buzones de recursos)

30000

Porcentaje de crecimiento proyectado (%) en el recuento de buzones (aumento proyectado en el recuento de buzones durante la vida útil de la solución)

8%

Concurrencia de buzones esperada % (número máximo de buzones activos en cualquier momento)

100%

Recuento de buzones de destino (recuento de buzones, incluida la concurrencia prevista de crecimiento x)

32400

Requisitos de tamaño del buzón

Requisito de tamaño del buzón Valor

Tamaño promedio del buzón en MB

600 MB

Tamaño promedio de archivo de buzón en MB

No aplicable

Crecimiento proyectado (%) en el tamaño de buzones en MB (aumento proyectado en el tamaño de buzones durante la vida útil de la solución)

230%

Tamaño promedio del buzón de destino en MB

2048 MB

Requisitos del perfil de buzón

Requisito del perfil de buzón Valor

Perfil de mensajes de destino (promedio del número total de mensajes enviados más recibidos por usuario por día)

100 mensajes por día

Tamaño de mensajes de destino promedio en kilobytes (KB)

75

% en modo en caché de MAPI

100

% en modo en línea de MAPI

0

% en modo en caché de Outlook Anywhere

0

% en Microsoft Office Outlook Web App (Outlook Web Access en Exchange 2007 y versiones anteriores)

0

% en Exchange ActiveSync

0

Soluciones comprobadas de Exchange 2010

La comprensión de la distribución de centros de datos y usuarios de buzones es importante en la toma de decisiones sobre diseño en relación con la alta disponibilidad y resistencia de sitios.

En la siguiente tabla, se describe la distribución geográfica de las personas que usarán el sistema Exchange.

Distribución geográfica de las personas

Requisito de sitio de usuario de buzones Valor

Número de sitios principales que contienen los usuarios de buzones

3

Número de usuarios de buzones en el sitio 1

10800

Número de usuarios de buzones en el sitio 2

10800

Número de usuarios de buzones en el sitio 3

10800

En la siguiente tabla, se describe la distribución geográfica de los centros de datos que podrían brindar compatibilidad a la infraestructura de correo electrónico de Exchange.

Distribución geográfica de los centros de datos

Requisito de sitio del centro de datos Valor

Número total de centros de datos

3

Número de buzones activos cerca del centro de datos 1

10800

Número de buzones activos cerca del centro de datos 2

10800

Número de buzones activos cerca del centro de datos 3

10800

Requisito para que Exchange resida en más de un centro de datos

Soluciones comprobadas de Exchange 2010

También es importante definir los requisitos de la protección de datos y el servidor para el entorno, ya que dichos requisitos respaldarán las decisiones de diseño en relación con la alta disponibilidad y resistencia de sitios.

En la siguiente tabla, se identifican los requisitos de protección del servidor.

Requisitos de protección del servidor

Requisito de protección del servidor Valor

Número de errores simultáneos en la máquina virtual o en el servidor dentro del sitio

1

Número de errores simultáneos en la máquina virtual o en el servidor durante la falla del sitio

0

En la siguiente tabla, se identifican los requisitos de protección de datos.

Requisitos de protección de datos

Requisito de protección de datos Valor o descripción

Requisito para mantener una copia de seguridad de las bases de datos de Exchange fuera del entorno Exchange (p. ej., solución de terceros)

No

Requisito para mantener copias de las bases de datos de Exchange dentro del entorno Exchange (p. ej., protección de datos nativos de Exchange)

Requisito para mantener varias copias de datos de buzones en el centro de datos principal

Requisito para mantener varias copias de datos de buzones en un centro de datos secundario

No

Requisito para mantener una copia retrasada de cualquier base de datos de Exchange

No

Período de copia retrasada en días

No aplicable

Número de destino de copias de la base de datos

3

Ventana de retención de la carpeta de elementos eliminados en días

14

Soluciones comprobadas de Exchange 2010

En esta sección, se incluye información que no se recopila de forma habitual como parte de los requisitos de los clientes pero es esencial para el diseño y el método de validación del diseño.

Soluciones comprobadas de Exchange 2010

En la siguiente tabla, se describen los objetivos de uso máximo del CPU en condiciones de funcionamiento normal y en condiciones de mantenimiento del servidor o de error del servidor del sitio.

Objetivos de uso del servidor

Hipótesis de diseño del objetivo de uso del CPU del servidor Valor

Funcionamiento normal de servidores de buzones

<70%

Funcionamiento normal de servidores de acceso de clientes

<70%

Funcionamiento normal de servidores de transporte de concentradores

<70%

Funcionamiento normal de varios roles de servidor (servidores de acceso de cliente, transporte de concentradores y buzón de correo)

<70%

Funcionamiento normal de varios roles de servidor (servidores de acceso de cliente y transporte de concentradores)

<70%

Error de nodo para servidores de buzones

<80%

Error de nodo para servidores de acceso de cliente

<80%

Error de nodo para servidores de transporte de concentradores

<80%

Error de nodo para varios roles de servidor (servidores de acceso de cliente, transporte de concentradores y buzón de correo)

<80%

Error de nodo para varios roles de servidor (servidores de acceso de cliente y transporte de concentradores)

<80%

Error del sitio para servidores de buzones

<80%

Error del sitio para servidores de acceso de cliente

<80%

Error del sitio para los servidores de transporte de concentradores

<80%

Error del sitio para varios roles de servidor (servidores de acceso de cliente, transporte de concentradores y buzón de correo)

<80%

Error del sitio para varios roles de servidor (servidores de acceso de cliente y transporte de concentradores)

<80%

Soluciones comprobadas de Exchange 2010

En las siguientes tablas, se resumen ciertas hipótesis sobre la entrada/salida (E/S) y la configuración de datos realizadas durante el diseño de la configuración de almacenamiento.

Hipótesis de configuración de datos

Hipótesis de configuración de datos Valor o descripción

Factor de sobrecarga de datos

20%

Movimientos de buzones por semana

1%

Mantenimiento dedicado o restauración del número de unidad lógica (LUN)

No

Espacio libre de LUN

20%

Compresión de trasvase de registros habilitada

Cifrado de trasvase de registros habilitado

Hipótesis de configuración de E/S

Hipótesis de configuración de E/S Valor o descripción

Factor de sobrecarga de E/S

20%

Requisitos de E/S adicionales

Ninguno

Soluciones comprobadas de Exchange 2010

En la siguiente sección, se proporciona una metodología paso a paso para diseñar esta solución. Esta metodología adopta las hipótesis de diseño y de requisitos de clientes y ofrece una guía por los puntos clave de la decisión del diseño que debe tomarse al diseñar un entorno de Exchange 2010.

Soluciones comprobadas de Exchange 2010

Al diseñar un entorno de Exchange 2010, varios puntos de la decisión del diseño para las estrategias de alta disponibilidad pueden afectar otros componentes de diseño. Recomendamos determinar la estrategia de alta disponibilidad como el primer paso en el proceso de diseño. Recomendamos que revise la siguiente información antes de comenzar con este paso:

Si tiene más de un centro de datos, debe decidir si se implementará la infraestructura de Exchange en un solo centro de datos o si se la distribuirá en dos o más centros de datos. Los acuerdos de nivel de servicio (SLA) de recuperación de la organización deben definir el nivel de servicio necesario después de un error en el centro de datos principal. Esta información debe servir de base para esta decisión.

*Punto de decisión de diseño*

En esta solución, hay tres ubicaciones de centros de datos físicos. El SLA indica que la resistencia de centros de datos es necesaria para todos los servicios críticos, incluido el correo electrónico. El diseño de Exchange 2010 se basará en una implementación de varios sitios con resistencia de sitios para los datos y el servicio de mensajería.

En este paso, examinamos si todos los usuarios de buzones se ubican principalmente en un sitio o si se distribuyen en varios sitios, y si dichos sitios están asociados con centros de datos. Si se distribuyen en varios sitios y si hay centros de datos asociados con dichos sitios, debe determinar si existen requisitos para mantener afinidad entre los usuarios de buzones y el centro de datos asociado con dicho sitio.

*Punto de decisión de diseño*

En este ejemplo, cada uno de los tres centros de datos comparte la ubicación con las oficinas regionales. Se desea mantener la afinidad entre la ubicación del usuario y la ubicación de la copia activa principal de sus buzones durante las condiciones de funcionamiento normal.

Dado que el cliente ha decidido implementar la infraestructura de Exchange en más de una ubicación física, el cliente debe determinar qué modelo de distribución de la base de datos satisface mejor las necesidades de la organización. Existen tres modelos de distribución de bases de datos:

  • Distribución activa/pasiva   Las copias de base de datos de buzones activas se implementan en el centro de datos principal y únicamente las copias de bases de datos pasivas se implementan en un centro de datos secundario. El centro de datos secundario sirve como un centro de datos en espera y no se hospedan buzones activos en el centro de datos en condiciones de funcionamiento normal. En caso de que una interrupción afecte el centro de datos principal, se realiza una conmutación manual y las bases de datos activas se alojan allí hasta que el centro de datos principal vuelve a conectarse.

    Distribución activa/pasiva

    Distribución de base de datos activa/pasiva
  • Distribución activa/pasiva (DAG único)   Las bases de datos de buzones activas se implementan en los centros de datos principal y secundario. Una copia pasiva correspondiente se ubica en el centro de datos alternativo. Todos los servidores de buzones forman parte de un DAG único. En este modelo, la conexión de la red de área extensa (WAN) entre dos centros de datos es un posible punto de error único. La pérdida de la conexión de WAN causa que los servidores de buzones en uno de los centros de datos ingresen en un estado de error debido a la pérdida de quórum.

    Distribución activa/activa (DAG único)

    Distribución de base de datos activa/activa con un único DAG
  • Distribución activa/activa (varios DAG)   Este modelo aprovecha varios DAG para quitar la conectividad WAN como un punto de error único. Un DAG tiene copias de base de datos activas en el primer centro de datos y sus correspondientes copias de las bases de datos pasivas en el segundo centro de datos. Un segundo DAG tiene copias de bases de datos activas en el segundo centro de datos y sus correspondientes copias de las bases de datos pasivas en el primer centro de datos. En el caso de que se pierda la conectividad WAN, las copias activas en cada sitio continúan suministrando disponibilidad de base de datos a los usuarios de buzones locales.

    Distribución activa/activa (varios DAG)

    Distribución activa/activa con varios DAG

*Punto de decisión de diseño*

En este ejemplo, como las bases de datos de buzones activas se implementarán en cada una de las tres ubicaciones del centro de datos, el modelo de distribución de base de datos será activo/activo con varios DAG. Existen ciertas consideraciones de diseño adicionales durante la implementación de un modelo de distribución de bases de datos activo/activo con varios DAG que se abordarán en un paso posterior.

Exchange 2010 incluye varias características nuevas y cambios principales que, cuando se implementan y se configuran de manera correcta, pueden ofrecer protección de datos nativos que elimina la necesidad de realizar copias de seguridad de datos tradicionales. Las copias de seguridad se usan tradicionalmente para la recuperación ante desastres, la recuperación de elementos eliminados en forma accidental, el almacenamiento de datos a largo plazo y la recuperación de base de datos de un momento determinado. Exchange 2010 puede abordar todos estos escenarios sin necesidad de copias de seguridad tradicionales:

  • Recuperación ante desastres   En caso de un error de hardware o software, varias copias de base de datos en un DAG ofrecen alta disponibilidad con conmutación por error rápida sin pérdida de datos. Los DAG se pueden extender a varios sitios y puede brindar resistencia contra errores del centro de datos.

  • Recuperación de elementos eliminados accidentalmente   Con la nueva carpeta de elementos recuperables en Exchange 2010 y la directiva de retención que puede aplicarse a ésta, es posible retener todos los datos eliminados y modificados para un período específico, a fin de que la recuperación de estos elementos sea más sencilla y rápida. Para obtener más información, consulte Directiva de mensajería y conformidad, Descripción de los elementos recuperables y Descripción de las etiquetas y directivas de retención (en inglés).

  • Almacenamiento de datos a largo plazo   En ocasiones, las copias de seguridad también cumplen la función de archivado. Generalmente, la cinta se usa para preservar las instantáneas de datos hasta un momento determinado durante períodos prolongados según los requisitos de cumplimiento. Las nuevas características de archivado, búsqueda en varios buzones y retención de mensajes en Exchange 2010 proporcionan un mecanismo para preservar datos eficazmente y de forma accesible para el usuario final durante períodos prolongados. Para obtener más información, consulte Descripción de archivos personales, Descripción de la búsqueda en varios buzones y Descripción de las etiquetas y directivas de retención (en inglés).

  • Instantánea de base de datos hasta un momento determinado   Si su organización requiere una copia de datos de buzones en un momento determinado que ya pasó, Exchange proporciona la capacidad de crear una copia atrasada en un entorno de DAG. Esto puede ser útil en eventos inusuales en donde existe una corrupción lógica que se replica a través de las bases de datos en el DAG, lo que provoca la necesidad de retornar a un momento anterior. También, puede ser útil en caso de que un administrador elimine, de manera accidental, los buzones de correo o los datos de usuario.

Antes de usar las características integradas de Exchange 2010 como un reemplazo para las copias de seguridad tradicionales, debe considerar los motivos técnicos y los diferentes problemas. Antes de tomar esta decisión, consulte Descripción de la copia de seguridad, restauración y recuperación ante desastres.

*Punto de decisión de diseño*

En este ejemplo, con la actual implementación de Exchange, el uso principal de la solución de copia de seguridad tradicional es la recuperación de la eliminación accidental de elementos de correo electrónico. El 80% de las solicitudes de recuperación de un solo elemento son de mensajes de menos de 15 días de antigüedad. Por lo tanto, el período de retención de elementos eliminados será de 14 días. Como las copias de seguridad de VSS tradicionales no son necesarias para restaurar un elemento único y no cumplen con el objetivo de tiempo de recuperación, se usarán las características de retención de la carpeta de elementos eliminados y la protección nativa de datos de Exchange como estrategia de resistencia de base de datos.

La siguiente decisión importante al definir su estrategia de resistencia de bases de datos es determinar el número de copias de bases de datos que se implementará. Se recomienda implementar un mínimo de tres copias de una base de datos de buzones de correo antes de eliminar formas tradicionales de protección para la base de datos, como la matriz redundante de discos independientes (RAID) o las copias de seguridad tradicionales basadas en VSS.

Antes de tomar esta decisión, consulte Descripción de copias de bases de datos de buzones de correo.

*Punto de decisión de diseño*

En este ejemplo, como no hay una solución de copia de seguridad de VSS tradicional implementada, se implementará un mínimo de tres copias de bases de datos para garantizar que se cumplan los requisitos del objetivo de tiempo de recuperación y el objetivo de punto de recuperación. Se ubicarán dos copias en el centro de datos principal y una tercera copia en un centro de datos alternativo para suministrar resistencia de sitios.

Hay dos tipos de copias de base de datos:

  • Copia de bases de datos de alta disponibilidad   Esta copia de base de datos está configurada con un retraso de reproducción igual a cero. Como su nombre lo indica, las copias de base de datos de alta disponibilidad se mantienen actualizadas por medio del sistema, pueden ser activadas automáticamente por el sistema y se usan para brindar alta disponibilidad a los datos y el servicio de buzones.

  • Copia de base de datos retrasada   Esta copia de base de datos está configurada para retrasar la reproducción del registro de transacciones durante un período. Las copias de base de datos retrasadas están diseñadas para brindar protección de un momento dado, que puede utilizarse para recuperarse de daños de lógica del almacén, errores administrativos (por ejemplo, eliminación o purgación de un buzón de correo desconectado) y errores de automatización (por ejemplo, purgación masiva de buzones de correo desconectados).

*Punto de decisión de diseño*

En este ejemplo, las tres copias de la base de datos de buzones se implementarán como copias de alta disponibilidad. El SLA no requiere una copia retrasada de los datos. Como no se experimentaron daños de lógica anteriormente y no se usan otras aplicaciones que manipulen los datos de mensajería, no es necesario realizar una copia retrasada. El único otro motivo por el cual sería necesario realizar una copia retrasada es ofrecer la capacidad de recuperar elementos únicos eliminados, pero es mucho más sencillo y rentable cumplir con estos requisitos mediante el uso de la característica de retención de la carpeta de elementos eliminados.

Exchange 2010 ha sido rediseñado para la resistencia de buzones. La protección de conmutación por error automática se ofrece ahora en el nivel de base de datos de buzones del nivel de servidor. Se pueden distribuir de forma estratégica copias de bases de datos activas y pasivas a los servidores de buzones dentro de un DAG. Un aspecto clave en la planificación de la capacidad de Exchange 2010 es determinar cuántas copias de bases de datos desea activar en cada servidor. Existen diferentes modelos de distribución de bases de datos que pueden implementarse pero, generalmente, se recomienda uno de los siguientes:

  • Diseño para todas las copias activadas   En este modelo, el tamaño del rol de servidor Buzón de correo se adapta en función de la activación de todas las copias de bases de datos en el servidor. Por ejemplo, un servidor de buzones puede alojar cuatro copias de la base de datos. Durante las condiciones de funcionamiento normal, es posible que el servidor tenga dos copias de bases de datos activas y dos copias de bases de datos pasivas. Durante un evento de mantenimiento o error, las cuatro copias de bases de datos se activarán en el servidor de buzones. Esta solución, por lo general, se implementa en pares. Por ejemplo, si se implementan cuatro servidores, el primer par está compuesto por los servidores MBX1 y MBX2 y el segundo, por los servidores MBX3 y MBX4. Asimismo, al diseñar este modelo, deberá adaptar el tamaño de cada servidor de buzones para que no supere el 40% de los recursos disponibles durante las condiciones de funcionamiento normales. En una implementación de resistencia de sitios con tres copias de bases de datos y seis servidores, este modelo puede implementarse en conjuntos de tres servidores y el tercer servidor puede residir en el centro de datos secundario. Este modelo suministra un bloque de creación de tres servidores para soluciones que usan un modelo de resistencia de sitios activo/pasivo.

    Este modelo puede usarse en los siguientes escenarios:

    • Configuración de varios sitios activa/pasiva en la que los dominios de errores (p. ej., bastidores, recintos blade y matrices de almacenamiento) requieren el aislamiento sencillo de las copias de bases de datos en el centro de datos principal

    • Configuración de varios sitios activa/pasiva en la que el crecimiento anticipado puede garantizar la incorporación sencilla de unidades de escala lógicas

    • Configuraciones que no son necesarias para superar la pérdida simultánea de dos servidores de buzones en el DAG

    Este modelo requiere la implementación de los servidores en pares para realizar implementaciones de sitio único y conjuntos de tres para realizar implementaciones de varios sitios. En la siguiente tabla, se proporciona un diseño de base de datos de muestra para este modelo.

    Diseño para todas las copias activadas

    Estrategia de resistencia del servidor de buzones

    En la tabla anterior, se aplica lo siguiente:

    • C1 = copia activa (valor de preferencia de activación de 1) durante las operaciones normales

    • C2 = copia pasiva (valor de preferencia de activación de 2) durante las operaciones normales

    • C3 = copia pasiva (valor de preferencia de activación de 3) durante el evento de falla del sitio

  • Diseño para los escenarios de error de destino   En este modelo, el rol de servidor Buzón de correo está diseñado para adaptarse a la activación de un subconjunto de copias de la base de datos en el servidor. La cantidad de copias de bases de datos en cada subconjunto dependerá del escenario de errores específico que está diseñando. El objetivo principal de este diseño es distribuir de forma pareja la carga de base de datos activa en los servidores de buzones restantes en el DAG.

    Este modelo debe usarse en los siguientes escenarios:

    • Todas las configuraciones de sitio único con tres o más copias de la base de datos

    • Configuraciones necesarias para superar la pérdida simultánea de dos servidores de buzones en el DAG

    El diseño de DAG para este modelo requiere entre 3 y 16 servidores de buzones. En la siguiente tabla, se proporciona un diseño de base de datos de muestra para este modelo.

    Diseño de escenarios de error de destino

    Estrategia de resistencia del servidor de buzones

    En la tabla anterior, se aplica lo siguiente:

    • C1 = copia activa (valor de preferencia de activación de 1) durante las operaciones normales

    • C2 = copia pasiva (valor de preferencia de activación de 2) durante las operaciones normales

    • C3 = copia pasiva (valor de preferencia de activación de 3) durante las operaciones normales

*Punto de decisión de diseño*

En un paso anterior, se decidió implementar un modelo de distribución de base de datos activo/activo con varios DAG. Como cada DAG en este modelo tiene una configuración activa/pasiva con solo dos copias de base de datos de alta disponibilidad en el centro de datos principal, la opción que mejor se adapta es una estrategia de resistencia del servidor de buzones diseñada para todas las copias que se están activando.

Un DAG es el componente básico del marco de alta disponibilidad y resistencia de sitios integrado en Exchange 2010. Un DAG es un grupo de hasta 16 servidores de buzones que aloja un conjunto de bases de datos replicadas y ofrece recuperación automática en el nivel de la base de datos después de fallas que afectan bases de datos o servidores individuales.

Un DAG es un límite para la replicación de bases de datos de buzones, las conmutaciones por error y los cambios de bases de datos y de servidores, así como para un componente interno denominado Active Manager. Active Manager es un componente de Exchange 2010 que administra cambios y conmutaciones por error. Active Manager se ejecuta en cada servidor en un DAG.

Desde una perspectiva de planificación, debería intentar minimizar la cantidad de DAG implementados. Debe considerar más de un DAG si:

  • Implementa más de 16 servidores de buzones.

  • Tiene usuarios de buzones activos en varios sitios (configuración de sitio activo/activo).

  • Necesita límites administrativos de nivel DAG independientes.

  • Tiene servidores de buzones en dominios independientes. (DAG está vinculado al dominio).

*Punto de decisión de diseño*

En un paso anterior, se decidió implementar un modelo de distribución de base de datos activo/activo. Podría implementarse un DAG único con usuarios de buzones activos en cada sitio. Sin embargo, en caso de que los miembros de un DAG de un sitio pierdan la conectividad en forma temporal con los miembros de un DAG de otro sitio, el clúster en dicho sitio perderá quórum y dejará de funcionar correctamente. Por esta razón, se implementarán tres DAG. Cada DAG incluirá servidores de buzones del centro de datos principal que alojarán las copias de bases de datos principales y secundarias. Cada DAG incluirá también servidores en uno de los centros de datos alternativos que alojarán la tercera copia de base de datos. El diseño obtenido es tres DAG activos/pasivos y cada centro de datos aloja las copias primarias y secundarias de un DAG, así como las terceras copias de otro DAG.

En este paso, debe determinar la cantidad mínima de servidores de buzones necesarios para ofrecer compatibilidad con el diseño del DAG. Este número puede ser diferente del número de servidores necesarios para ofrecer compatibilidad con la carga de trabajo; por lo tanto, la decisión final sobre el número de servidores se realiza en un paso posterior.

*Punto de decisión de diseño*

En un paso anterior, se decidió implementar tres DAG activos/pasivos y diseñar una estrategia de resistencia de servidores para todas las copias que se están activando. Cada DAG debe implementarse en incrementos de tres servidores (dos en el sitio principal y uno en un sitio alternativo). Como hay tres DAG implementados, la cantidad mínima de servidores necesarios para ofrecer compatibilidad con el diseño del DAG es nueve. La solución tendrá 9, 18 ó 27 servidores, según la cantidad de servidores necesarios para ofrecer compatibilidad con la carga de trabajo. En la siguiente tabla, se detallan las posibles configuraciones.

Número de servidores de buzón por DAG

Centro de datos principal de DAG1 Centro de datos secundario de DAG1 Centro de datos principal de DAG2 Centro de datos secundario de DAG2 Centro de datos principal de DAG3 Centro de datos secundario de DAG3 Recuento total de servidores de buzones

2

1

2

1

2

1

9

4

2

4

2

4

2

18

6

3

6

3

6

3

27

NotaNOTA:
En un modelo de DAG de tres nodos, si pierde los dos nodos del centro de datos principal, el clúster perderá el quórum y la activación automática. La tercera copia en el centro de datos secundario ofrecerá disponibilidad adicional de datos, pero la recuperación del servicio en el centro de datos secundario será una operación manual.

Soluciones comprobadas de Exchange 2010

Varios factores influyen en los requisitos de capacidad de almacenamiento para el rol de servidor Buzón de correo. Para obtener información adicional, le recomendamos consultar Descripción de los factores de capacidad de la base de datos de buzones de correo y de registro.

En los siguientes pasos, se describe cómo calcular los requisitos de capacidad de los buzones. Estos requisitos se usarán más adelante para tomar decisiones sobre qué opciones de soluciones de almacenamiento cumplen con los requisitos de capacidad. En una sección posterior, se abarcan los cálculos adicionales necesarios para diseñar de forma adecuada el almacenamiento de la plataforma de almacenamiento seleccionada.

Microsoft ha creado la calculadora de requisitos del rol de servidor Buzón de correo, que realizará la mayor parte de este trabajo por usted. Para descargar la calculadora, consulte Calculadora de requisitos del rol de servidor Buzón de correo de E2010. Para obtener información adicional sobre cómo usar la calculadora, consulte Calculadora de requisitos del rol de servidor Buzón de correo de Exchange 2010.

Antes de intentar determinar cuáles son sus requisitos totales de almacenamiento, debe conocer cuál será el tamaño del buzón en el disco. Un buzón completo con una cuota de 1 GB requiere más de 1 GB de espacio en disco, ya que debe tener en cuenta el límite de prohibición de envío/recepción, la cantidad de mensajes que el usuario envía o recibe por día, la ventana de retención de la carpeta de elementos eliminados (con o sin registro de la versión de calendario y recuperación de elementos individuales habilitado) y las variaciones diarias promedio en la base de datos por buzón. La calculadora de requisitos del rol de servidor Buzón de correo realiza estos cálculos por usted. También puede usar la siguiente información para realizar los cálculos manualmente.

Los siguientes cálculos se usan para determinar el tamaño del buzón en el disco para un buzón, con un límite de 2 GB para buzones en esta solución:

  • Espacio en blanco = 100 mensajes por día x 75 ÷ 1024 MB = 7,3 MB

  • Contenedor = (100 mensajes por día x 75 ÷ 1024 MB × 14 días) + (2048 MB × 0,012) + (2048 MB × 0,058) = 246 MB

  • Tamaño de buzones en disco = límite de buzones + espacio en blanco + contenedor

    = 2048 + 7.3 + 246

    = 2301 MB

En este paso, se determina la capacidad de almacenamiento de alto nivel necesario para todas las bases de datos de buzones. La capacidad calculada incluye el tamaño de la base de datos, el tamaño del índice de catálogo y el espacio libre del 20%.

Para determinar la capacidad de almacenamiento necesaria de todas las bases de datos, use las siguientes fórmulas:

  • Tamaño de la base de datos = (número de buzones x tamaño del buzón en disco x factor de crecimiento general de la base de datos) (20% de sobrecarga de datos)

    = (32400 × 2301 × 1) + (14910480)

    = 89.462.880 MB

    = 87.366 GB

  • Tamaño de índice de base de datos = 10% del tamaño de la base de datos

    = 87366 × 0.10

    = 8.737 GB

  • Capacidad total de base de datos= (tamaño de base de datos) + (tamaño de índice) ÷ 0,80 para agregar espacio libre del volumen del 20%

    = (87366 + 8737) ÷ 0.8

    = 120.128 GB

Para asegurarse de que el servidor de buzones de correo no sufra cortes como resultado de problemas de asignación de espacio, también es necesario ajustar los registros de transacciones para que puedan incluir todos los registros que se generarán durante el conjunto de copia de seguridad. Teniendo en cuenta que esta arquitectura aprovecha las funciones de resistencia y de recuperación de un único elemento de buzones, como la arquitectura de copia de seguridad, la capacidad de registro debe asignar tres veces la tasa diaria de generación de registros si una copia con errores no se repara en tres días. (Cualquier copia donde se produjo un error impide que el truncamiento de registro se realice). En caso de que el servidor no vuelva a estar en línea dentro de los tres días, es posible que desee quitar la copia temporalmente para permitir que se produzca el truncamiento.

Para determinar la capacidad de almacenamiento necesaria para todos los registros de transacción, use las siguientes fórmulas:

  • Tamaño de los archivos de registro = (tamaño del archivo de registro × cantidad de registros por buzón por día × cantidad de días necesarios para reemplazar la infraestructura con errores × cantidad de usuarios de buzones de correo) + (1% de sobrecarga de migración de buzones)

    = (1 MB × 20 × 4 × 32400) + (32400 × 0,01 × 2048 MB)

    = 3.255.552 MB

    = 3.179 GB

  • Capacidad total de registro = tamaño de los archivos de registro ÷ 0,80 para agregar 20% de espacio libre del volumen

    = (3179) ÷ 0.80

    = 3974

En la siguiente tabla, se resumen los requisitos de almacenamiento de alto nivel de esta solución. En un paso posterior, usaremos esta información para tomar decisiones sobre qué solución de almacenamientos debemos implementar. Deberá prestar atención a los requisitos específicos de almacenamiento más adelante.

Resumen de los requisitos de capacidad de almacenamiento

Requisitos de espacio en disco Valor

Tamaño promedio de buzón en disco (MB)

2301

Capacidad de base de datos requerida (GB)

120128

Capacidad de registro requerida (GB)

3974

Capacidad total requerida (GB)

124102

Capacidad total requerida para tres copias de bases de datos (GB)

372306

Capacidad total requerida para tres copias de bases de datos (terabytes)

364

Capacidad total requerida para cada sitio (terabytes)

122

Soluciones comprobadas de Exchange 2010

Cuando diseña un entorno de Exchange, debe comprender cómo funcionan los factores de rendimiento de las bases de datos y los registros. Le recomendamos consultar Descripción de las bases de datos y los factores de rendimiento del registro.

Debido a que es una de las métricas de E/S transaccional necesarias para ajustar el tamaño del almacenamiento adecuadamente, es importante comprender la cantidad de E/S de base de datos por segundo (IOPS) que cada usuario consume. Las operaciones de E/S puramente secuenciales no se incluyen en el cálculo de IOPS por servidor de buzones de correo debido a que los subsistemas de almacenamiento pueden administrar E/S secuenciales de forma mucho más eficaz que las E/S aleatorias. Estas operaciones incluyen el mantenimiento de la base de datos en segundo plano, E/S transaccional de registros y E/S de replicación de registros. En este paso, se calculan las IOPS necesarias para admitir todos los usuarios de buzones de correo con la siguiente fórmula:

  • IOPS calculadas por usuario del buzón = 0,10

  • IOPS totales requeridas = IOPS por usuario de buzón × cantidad de buzones × factor de sobrecarga de E/S

    = 0.10 × 32400 × 1.2

    = 3888

NotaNOTA:
Para determinar el perfil de IOPS para un perfil de mensajes distinto, consulte la tabla “Caché de base de datos e IOPS calculadas por buzón según la actividad de mensajería” en Descripción de las bases de datos y los factores de rendimiento del registro.

Debido a que es una implementación de varios sitios, debe considerar los requisitos de IOPS por sitio para medir apropiadamente el almacenamiento para cada sitio. En un paso anterior, se decidió que cada sitio alojaría las copias de la base de datos primaria y secundaria del DAG primario y la copia de la base de datos terciaria de un DAG alternativo. En este modelo, el peor escenario sería el fallo de un solo sitio donde 10 800 buzones del DAG primario y 10 800 del DAG alternativo están activos en el almacenamiento del sitio. Utilice el siguiente cálculo:

  • IOPS totales requeridas por sitio = IOPS por usuario de buzón × cantidad de buzones × factor de sobrecarga de E/S

    = 0.10 × 21600 × 1.2

    = 2592

Soluciones comprobadas de Exchange 2010

Exchange 2010 incluye mejoras en rendimiento, confiabilidad y alta disponibilidad que permiten a las organizaciones ejecutar Exchange en distintas opciones de almacenamiento.

Cuando se consideran las opciones de almacenamiento disponible, la capacidad de balancear los requisitos de rendimiento, capacidad, facilidad de administración y costo es esencial para lograr una solución de almacenamiento exitosa para Exchange.

Para obtener más información sobre la selección de almacenamientos para Exchange 2010, consulte Diseño del almacenamiento del servidor de buzones de correo.

Soluciones comprobadas de Exchange 2010

Existe una amplia variedad de almacenamientos disponibles para Exchange 2010. La lista de opciones se puede reducir determinando si se prefiere a implementar una solución de almacenamiento de conexión directa (DAS) (incluido el uso de un disco local) o una solución SAN. Existen muchas razones para elegir una opción o la otra. Por esta razón, debe trabajar con su proveedor para determinar qué solución satisface sus requerimientos empresariales y su costo total de propiedad.

*Punto de decisión de diseño*

En este ejemplo, se implementó una infraestructura SAN que se utiliza para almacenar todos los datos del entorno. Se seguirá utilizando solución de almacenamiento SAN y se explorarán opciones de implementación de Exchange 2010.

Soluciones comprobadas de Exchange 2010

Utilice los siguientes pasos para elegir una solución de almacenamiento.

En este ejemplo, se ha utilizado el almacenamiento EMC durante varios años y se utilizará una solución de almacenamiento EMC para la implementación de Exchange 2010. EMC Corporation ofrece matrices de almacenamiento de alto rendimiento como CLARiiON y Symmetric.

La familia EMC CLARiiON proporciona capas de almacenamiento múltiples, como unidades flash para empresas, Fibre Channel y Serial ATA (SATA), lo cual reduce los costos, ya que las capas múltiples se pueden administrar con una sola interfaz de administración.

CLARiiON Virtual Provisioning proporciona más beneficios que el aprovisionamiento fino tradicional, incluye una administración de almacenamiento simplificada y una capacidad de utilización mejorada. Puede presentar una gran cantidad de almacenamiento a un host y utilizar el espacio según lo necesite desde un grupo compartido.

La serie CLARiiON CX4 proporciona cuatro modelos con niveles de capacidad, funcionalidad y rendimiento flexibles. Las características de cada modelo se describen en la siguiente tabla.

Características de la serie CLARiiON CX4

Feature CX4 modelo 120 CX4 modelo 240 CX4 modelo 480 CX4 modelo 960

Máximo de discos

120

240

480

960

Procesadores de almacenamiento

2

2

2

2

Memoria física por procesador de almacenamiento

3 GB

4 GB

8 GB

16 GB

Memoria caché de escritura máxima

600 MB

1,264 GB

4,5 GB

10,764 GB

Cantidad máxima de iniciadores por sistema

256

512

512

1024

Hosts de alta disponibilidad

128

256

256

512

Tamaño de factor de forma mínima

6U

6U

6U

9U

Cantidad máxima de LUN estándar

1024

1024

4096

4096

Instantáneas de SnapView

Clones de SnapView

Copia de SAN

MirrorView/S

MirrorView/A

RecoverPoint/S

RecoverPoint/A

En este ejemplo, se eligen discos de 15 000 rpm de Fibre Channel de 450 GB disks que proporcionan un buen rendimiento de E/S y capacidad para satisfacer los requisitos iniciales del usuario de Exchange.

NotaNOTA:
Desde el momento de prueba, los discos de 600 GB y 10 000 rpm han bajado su costo y también representan una buena opción para esta implementación.

En este ejemplo, la solución debe proporcionar 122 terabytes de almacenamiento utilizable y 2592 IOPS. Cualquiera de las opciones de la tabla anterior cumplirá con los requisitos de IOPS. Por lo tanto, la decisión se basará en los requisitos de capacidad. El modelo 240 de CLARiiON CX4 solamente proporciona aproximadamente 100 terabytes de capacidad utilizable con discos de 450 GB en una configuración RAID-5. Se elije el modelo 480 de EMC CLARiiON CX4 porque proporciona la capacidad y el rendimiento de E/S necesarios para admitir todos los requisitos de Exchange 2010.

Soluciones comprobadas de Exchange 2010

El motor de almacenamiento extensible (ESE) usa la memoria caché de la base de datos para reducir las operaciones de E/S. En general, cuanta más memoria caché de bases de datos disponible haya, menos E/S se generan en un servidor de buzones de correo de Exchange 2010. Sin embargo, hay un punto en el que si se agrega caché de bases de datos adicional, no se reducen significativamente las IOPS. Por lo tanto, si agrega grandes cantidades de memoria física a su servidor Exchange sin determinar la cantidad óptima de memoria caché de la base de datos requerida, tendrá costos más altos con un beneficio mínimo de rendimiento.

Las IOPS que completó en un paso anterior suponen una cantidad mínima de caché de base de datos por buzón de correo. Las cantidades mínimas están resumidas en la tabla “Caché de base de datos e IOPS calculadas por buzón según la actividad de mensajería” en Descripción de la memoria caché de la base de datos de buzones.

En la siguiente tabla, se describe la memoria caché de base de datos por usuario para muchos perfiles de mensaje.

Caché de base de datos por usuario

Mensajes enviados o recibidos por buzón de correo por día (tamaño promedio de los mensajes de aproximadamente 75 KB) Caché de base de datos por usuario (MB)

50

3 MB

100

6 MB

150

9 MB

200

12 MB

En este paso, debe determinar los requisitos de memoria de alto nivel para el entorno completo. En un paso posterior, debe usar este resultado para determinar la cantidad de memoria física necesaria para cada servidor de buzón de correo. Utilice el siguiente cálculo:

  • Caché de base de datos = caché de base de datos específica de perfil × cantidad de usuarios de buzones de correo

    = 6 MB × 32400

    = 194.400 MB

    = 190 GB

Soluciones comprobadas de Exchange 2010

La planificación de la capacidad del servidor de buzón de correo ha cambiado significativamente con respecto a versiones anteriores de Exchange, debido al nuevo modelo de resistencia de base de datos del buzón de correo de Exchange 2010. Para obtener más información, consulte Planificación de la capacidad del procesador del servidor buzones de correo.

En los siguientes pasos, debe calcular los requisitos de megaciclo de alto nivel para las copias de bases de datos activas y pasivas. Estos requisitos se utilizarán en un paso posterior para determinar la cantidad de servidores de buzón de correo necesarios para admitir la carga de trabajo. Tenga en cuenta que la cantidad requerida de servidores de buzón de correo depende del modelo de resistencia y del diseño de la copia de la base de datos del servidor de buzón de correo.

El uso de los requisitos de megaciclos para determinar la cantidad de usuarios de buzones de correo que puede admitir un servidor de Buzón de Exchange no es una ciencia exacta. En entornos de prueba y producción, cierta cantidad de factores pueden producir resultados inesperados de megaciclos. Los megaciclos deben usarse únicamente como una aproximación de la cantidad de usuarios del buzón de correo que un servidor de Buzón de Exchange puede admitir. Siempre es mejor ser conservador durante la planificación de capacidad en los procesos de diseño.

Los siguientes cálculos se basan en cálculos publicados de megaciclos y resumidos en la siguiente tabla.

Cálculos de megaciclo

Mensajes enviados o recibidos por buzón de correo por día Megaciclos por buzón para base de datos activa de buzón Megaciclos por buzón para base de datos remota de buzón pasivo Megaciclos por buzón para buzón pasivo local

50

1

0.1

0.15

100

2

0.2

0.3

150

3

0.3

0.45

200

4

0.4

0.6

En este paso, debe calcular los megaciclos necesarios para admitir las copias de base de datos activas de la siguiente manera:

  • Megaciclos de buzón activo necesarios = megaciclos específicos de perfil × cantidad de usuarios de buzones

    = 2 × 32400

    = 64800

En un diseño con tres copias de cada base de datos, existe una sobrecarga del procesador asociada con los registros de envío necesarios para actualizar las copias de base de datos en los servidores remotos. La sobrecarga representa generalmente el 10% de los megaciclos del buzón activo para cada copia remota a la que se hace mantenimiento. Calcule los requisitos con la siguiente fórmula:

  • Megaciclos de copia remota necesarios = megaciclos específicos de perfil × cantidad de usuarios de buzones × cantidad de copias remotas

    = 0.1 × 32400 × 2

    = 6480

En un diseño con tres copias de cada base de datos, existe una sobrecarga del procesador asociada con el mantenimiento de las copias locales pasivas de cada base de datos. En este paso, se calcularán los megaciclos de alto nivel necesarios para admitir copias de bases de datos locales pasivas. Estos números se mejorarán en un paso posterior para que concuerden con la estrategia de resistencia del servidor y el diseño de copia de base de datos. Calcule los requisitos con la siguiente fórmula:

  • Megaciclos de buzón pasivo local necesarios = megaciclos específicos de perfil × cantidad de usuarios de buzones × cantidad de copias pasivas

    = 0.3 × 32400 × 2

    = 19440

Calcule los requisitos totales con la siguiente fórmula:

Total de megaciclos requeridos = buzón activo + pasivo remoto + local pasivo

= 64800 + 6480 + 19440

= 90720

Promedio de megaciclos por buzón = ÷ 90720 ÷ 32400 = 2,8

Soluciones comprobadas de Exchange 2010

En la siguiente tabla, se resume la cantidad de megaciclos y de caché de base de datos aproximados que se necesitan para este entorno. Esta información se utilizará más adelante para determinar qué servidores se implementarán en la solución.

Resumen de los requisitos de buzón

Requisitos de CPU del buzón de correo Valor

Megaciclos totales requeridos para todo el entorno

97200

Caché de base de datos total requerido para todo el entorno

190 GB

Soluciones comprobadas de Exchange 2010

Puede utilizar los siguientes pasos para determinar el modelo de servidor.

En esta solución, la plataforma preferida de servidor es Cisco Unified Computing System, una plataforma de centro de datos que unifica informática, redes, acceso a almacenamiento y virtualización en un sistema diseñado para reducir el costo total de propiedad y aumentar la flexibilidad. El sistema integra una red Ethernet unificada de 10 gigabits de latencia baja con servidores con arquitectura x86 de clase empresarial. Con un enfoque de sistemas a la arquitectura, la tecnología, las asociaciones y los servicios, Cisco Unified Computing System mejora los recursos de centro de datos, ofrece escalabilidad para los servicios de entrega y reduce la cantidad de dispositivos que requieren configuración, administración, energía, refrigeración y cableado.

Cisco Unified Computing System es un sistema servidor blade compuesto por cuatro componentes principales de sistema. Estos componentes de sistema son la interconexión de tejido, el chasis, extensores de tejido (módulos de E/S) y los servidores blade.

Los siguientes modelos de servidores blade son opciones posibles para esta solución.

Opción 1: B200 Blade Server

El B200 Blade Server de Cisco Unified Computing System es un servidor blade de dos sockets y ancho medio. El sistema utiliza dos procesadores Intel Xeon 5500 o 5600, hasta 96 GB de memoria DDR3, dos unidades de disco SAS opcionales de factor de forma pequeño de intercambio directo y un solo conector mezzanine para hasta 20 gigabits por segundo (Gbps) de rendimiento de E/S. El servidor balancea simplicidad, rendimiento y densidad de virtualización de nivel de producción y otras cargas de trabajo de centro de datos generales.

Opción 2: B250 Blade Server

El servidor Blade con memoria extendida de Cisco Unified Computing System B250 es un servidor blade de dos sockets y ancho completo que tiene tecnología de memoria extendida de Cisco. El sistema admite dos procesadores Intel Xeon 5500 o 5600, hasta 384 GB de memoria DDR3, dos unidades de disco SAS opcionales de factor de forma pequeño y dos conectores mezzanine para hasta 40 Gbps de rendimiento de E/S. El servidor aumenta el rendimiento y la capacidad para la virtualización y las cargas de trabajo de grandes conjuntos de datos.

Opción 3: B440 Blade Server

El B440 Blade Server de Cisco Unified Computing System está diseñado para alimentar aplicaciones empresariales, como grandes bases de datos con muchas transacciones, programas de planificación de recursos empresariales (ERP) y sistemas de ayuda de toma de decisiones (DSS). Potenciado por procesadores de rendimiento escalable y confiables Intel Xeon 7500, el B440 de Cisco Unified Computing System ayuda a ampliar el rango de virtualización de carga de trabajo y unifica las aplicaciones independientes de rendimiento intensivo dentro de una infraestructura integrada y simplificada. El B440 de Cisco Unified Computing System admite hasta 32 núcleos de procesadores y 256 GB de memoria principal con E/S combinada de hasta 40 Gbps.

Se seleccionó el B200 de Cisco Unified Computing System con procesadores Intel Xeon X5570 porque este servidor blade tiene el balance óptimo de capacidad de procesamiento, de capacidad de memoria y de factor de forma para esta implementación. La plataforma de servidor con dos sockets es generalmente una buena elección para implementaciones de Exchange 2010 según todos los factores relevantes, incluida la escalabilidad y el costo. El B250 de Cisco Unified Computing System admite una configuración con más memoria y mayor rendimiento de E/S, pero no es necesario para esta solución.

NotaNOTA:
Desde el momento de prueba, los discos de 600 GB y 10 000 rpm han bajado su costo y también representan una buena opción para esta implementación.

Soluciones comprobadas de Exchange 2010

En los pasos anteriores, calculó los megaciclos necesarios para admitir la cantidad de usuarios de buzón activos. En los siguientes pasos, determinará cuantos megaciclos disponibles pueden admitir el modelo de servidor y el procesador para determinar la cantidad de buzones activos que puede admitir cada servidor.

Debido a que los requisitos de megaciclos están basados en un modelo de procesador y servidor de línea de base, debe ajustar los megaciclos disponibles del servidor con la línea de base. Para esto, se usan referencias de rendimiento independientes mantenidas por Standard Performance Evaluation Corporation (SPEC). SPEC es una corporación sin fines de lucro formada para establecer, mantener y avalar un conjunto estandarizado de referencias relevantes que se pueden aplicar a la nueva generación de equipos de alto rendimiento.

Para ayudar a simplificar el proceso de obtención de un valor de referencia para su procesador y su servidor, le recomendamos que utilice la herramienta Exchange Processor Query tool. Esta herramienta automatiza los pasos manuales para determinar el valor SPECint 2006 de su procesador planificado. Para ejecutar esta herramienta, su equipo debe estar conectado a Internet. La herramienta usa su modelo de procesador planificado como entrada y, a continuación, ejecuta una consulta con el sitio web de Standard Performance Evaluation Corporation que devuelve todos los datos de las pruebas del modelo específico de procesador. La herramienta también calcula un promedio del valor de SPECint 2006 basado en la cantidad de procesadores que planifica usar en cada servidor de Buzón. Utilice el siguiente cálculo:

  • Procesador = Intel X5570 2,93 gigahercios (GHz)

  • Valor SPECint_rate2006 = 256

  • Valor de SPECint_rate2006 por núcleo de procesador = 256 ÷ 8

    = 32

En los pasos anteriores, calculó los megaciclos necesarios para el entorno completo según los cálculos de megaciclos por buzón. Estos cálculos se midieron en un sistema de línea base (HP DL380 G5 x5470 3.33 GHz, 8 núcleos) que tiene un valor SPECint_rate2006 de 150 (para un servidor de 8 núcleos) o 18,75 por núcleo.

En este paso, debe ajustar los megaciclos disponibles para el servidor y el procesador elegidos con el procesador de línea base para que los megaciclos requeridos se puedan utilizar para la planificación de capacidad.

Para determinar los megaciclos de la plataforma Cisco B200-M1 Intel X5570 2.93 GHz, utilice las siguientes fórmulas:

  • Megaciclos ajustados por núcleo = (nueva plataforma por valor de núcleo) × (hercios por núcleo de la plataforma de línea de base) ÷ (línea de base por valor de núcleo)

    = (32 × 3330) ÷ 18.75

    = 5683

  • Megaciclos ajustados por servidor = megaciclos ajustadas por núcleo x cantidad de núcleos

    = 5683 × 8

    = 45466

Ahora que conoce los megaciclos ajustados por servidor, debe ajustar el uso máximo de procesador que desea. En una sección anterior, se decidió no exceder el 80% del uso del procesador durante cargas de pico de trabajo o escenarios de falla. Utilice el siguiente cálculo:

  • Megaciclos disponibles ajustados = megaciclos disponibles por servidor x objetivo de uso máximo del procesador

    = 45466 × 0.80

    = 36372

Cada servidor tiene una capacidad utilizable de 36.372 megaciclos.

Soluciones comprobadas de Exchange 2010

Puede utilizar los pasos posteriores para determinar la cantidad de servidores físicos de buzones necesarios.

Para determinar la cantidad de buzones activos admitidos por el servidor de buzones, utilice el siguiente cálculo:

  • Cantidad de buzones activos = megaciclos disponibles por servidor ÷ megaciclos por buzón

    = 36372 ÷ 2.8

    = 12990

Cada DAG tiene 10 800 buzones activos. Para determinar la cantidad mínima de servidores de buzones necesarios para admitir todos los buzones en un DAG, utilice el siguiente cálculo:

  • Cantidad de servidores necesarios = cuenta total de buzones por DAG ÷ buzones activos por servidor

    = 10800 ÷ 12990

    = 0.83

Para cada DAG, es necesario un mínimo de un servidor de buzones para admitir la carga de trabajo de 10 800 buzones.

En un paso anterior, se determinó el diseño de todas las copias que se activan en un DAG activo/pasivo. Este modelo necesita que se implementen roles de servidor Buzón de correo en grupos de tres para cada DAG.

Cantidad de servidores de buzones y DAG

Centro de datos principal de DAG1 Centro de datos secundario de DAG1 Centro de datos principal de DAG2 Centro de datos secundario de DAG2 Centro de datos principal de DAG3 Centro de datos secundario de DAG3 Recuento total de servidores de buzones

2

1

2

1

2

1

9

4

2

4

2

4

2

18

6

3

6

3

6

3

27

De acuerdo con el diseño de DAG, se necesita un mínimo de tres servidores físicos de buzones en cada DAG o un total de nueve servidores físicos de buzones para los tres DAG.

Soluciones comprobadas de Exchange 2010

Puede seguir los siguientes pasos para determinar la cantidad de buzones activos por servidor de buzones en escenarios de operación normal y con fallos.

Para determinar la cantidad de buzones activos alojados por el servidor de buzones durante operaciones normales, utilice el siguiente cálculo:

  • Cantidad de buzones por servidor = cantidad total de servidores en DAG ÷ cantidad de servidores de buzones en el centro de datos principal

    = 10800 ÷ 2

    = 5400

En caso de que un servidor de buzones del centro de datos principal falle, los 5400 buzones del servidor que falla se convertirán en activos en el servidor restante. En este escenario, el servidor de buzones restante tendrá 10 800 buzones activos.

En caso de que el centro de datos principal se desconecte, los 10 800 buzones activos del centro de datos principal se activarán en el centro de datos secundario. En este escenario, el único servidor del centro de datos secundario tendrá 10 800 buzones activos.

Soluciones comprobadas de Exchange 2010

Cuando determina la cantidad de roles de servidores de acceso de clientes y de transporte de concentradores que debe implementar en un entorno con una cantidad menor de servidores, debe considerar la implementación de ambos roles en la misma máquina física. Esto reduce la cantidad de máquinas físicas que debe administrar, la cantidad de sistemas operativos de servidores que debe actualizar y mantener y la cantidad de licencias de Windows y Exchange que debe comprar. El otro beneficio de combinar los roles de servidores de acceso de clientes y de transporte de concentradores es que se simplifica el proceso de diseño. Cuando se implementan los roles por separado, recomendamos que implemente un procesador lógico de servidor de transporte de concentradores cada cuatro procesadores lógicos de servidores de buzones y tres procesadores lógicos de servidores de acceso de clientes cada cuatro procesadores lógicos de servidores de buzón de correo. Esto puede ser confuso, especialmente cuando tiene que proporcionar suficientes servidores de acceso de clientes y de transporte de concentradores durante escenarios de fallo de varios servidores físicos o de mantenimiento. Cuando implementa los servidores de acceso de clientes y transporte de concentradores y los servidores de buzones como servidores físicos o como máquinas virtuales, puede implementar una combinación de servidor de acceso de clientes y transporte de concentradores por cada servidor de buzón en el sitio.

*Punto de decisión de diseño*

En esta solución, se decidió reubicar los roles de servidor de acceso de clientes y de transporte de concentradores juntas en la misma máquina física. Esto reducirá la cantidad de sistemas operativos que debe administrar y facilitará la planificación de resistencia de servidores.

Soluciones comprobadas de Exchange 2010

En un paso anterior, determinó que eran necesarios tres servidores de buzones en cada sitio (dos del DAG para alojar los buzones activos del sitio y uno para un DAG alternativo que admite la resistencia del sitio en caso de fallas en el centro de datos principal del DAG).

Recomendamos que implemente una combinación de servidor de acceso de clientes y de transporte de concentradores por cada servidor de buzones, como se muestra en la siguiente tabla.

Cantidad de servidores físicos necesarios para la combinación de acceso de cliente y transporte de concentradores

Configuración de roles del servidor Relación recomendada de los núcleos de procesador

Buzón: rol combinado de servidor de acceso de cliente y transporte de concentradores

1:1

Cuando tiene más de un DAG representado en el mismo sitio, necesita examinar el peor escenario de fallo antes de determinar la cantidad de servidores necesarios para la combinación de acceso de cliente y transporte de concentradores. En esta solución, el peor escenario sería perder uno de los dos servidores de buzón en el DAG primario y tener un fallo simultáneo de los sitios donde los buzones activos de otro sitio se están alojando. En este caso, tendrá 21 600 buzones en el mismo sitio que se ejecutan en dos servidores de buzones y, por lo tanto, requerirán un mínimo de dos servidores de combinación de acceso de cliente y transporte de concentradores en cada sitio, como se muestra en la siguiente figura.

Servidores de acceso de cliente y transporte de concentradores

por determinar

Soluciones comprobadas de Exchange 2010

Hasta aquí, ha determinado que se necesitan 15 servidores físicos para admitir los roles de servidor de acceso de cliente, transporte de concentradores y buzón de correo para 32 400 buzones activos en tres centros de datos, como se muestra en la siguiente figura.

Cantidad de servidores físicos necesarios

por determinar

Soluciones comprobadas de Exchange 2010

Existen varios factores importantes a la hora de la virtualización de servidores para Exchange. Para obtener más información acerca de las configuraciones admitidas para la virtualización, consulte Requisitos del sistema de Exchange 2010.

Considere el uso de la virtualización con Exchange por las siguientes razones:

  • Si prevé que se utilizará menos que la capacidad de los servidores y anticipa una mejor utilización, puede comprar menos servidores debido a la virtualización.

  • Es posible que desee utilizar el equilibrio de carga de red (NLB) de Windows cuando implementa los roles de servidores de acceso de clientes, transporte de concentradores y buzón de correo en el mismo servidor físico.

  • Si su organización utiliza la virtualización en toda la infraestructura de servidores, es posible que desee utilizar la virtualización con Exchange para estar en consonancia con la política corporativa.

Para determinar si se debe utilizar la virtualización en este entorno, considere la utilización anticipada de procesadores y determine si es posible que los servidores se infrautilicen.

Para determinar la utilización de CPU de 5400 buzones activos en un solo servidor de buzones, utilice el siguiente cálculo:

  • Porcentaje del procesador (máximo funcionamiento normal) = megaciclos necesarios ÷ megaciclos disponibles

    = (5400 × 2.8) ÷ 45466

    = 33.2%

Para determinar la utilización de CPU de 10 800 buzones activos en un solo servidor de buzones, utilice el siguiente cálculo:

  • Porcentaje del procesador (condiciones máximas de fallo) = megaciclos necesarios ÷ megaciclos disponibles

    = (10800 × 2.8) ÷ 45466

    = 66.5%

*Punto de decisión de diseño*

Debido a que se proyecta como objetivo un porcentaje de utilización del servidor del 80% para el peor escenario de fallo, es posible que exista la oportunidad de reducir la cantidad de servidores mediante la virtualización. Esto se estudiará en mayor detalle en los pasos siguientes.

Soluciones comprobadas de Exchange 2010

En los siguientes pasos, determinará si se puede utilizar la virtualización para reducir la cantidad de servidores físicos necesarios para esta solución. Como plataforma de virtualización, se utilizará Microsoft Hyper-V.

En las pruebas, Microsoft Hyper-V admite un máximo de cuatro procesadores virtuales por máquina virtual. En el diseño físico, se implementó el rol de servidor Buzón de correo del DAG principal en dos servidores físicos, con un total de 16 procesadores lógicos. Al agregar la virtualización, el rol de servidor Buzón de correo del DAG principal se implementa en cuatro máquinas virtuales, cada una con cuatro procesadores virtuales, con un total de 16 procesadores virtuales.

En el diseño físico, se implementó el rol de servidor Buzón de correo en el DAG alternativo en un servidor físico, con ocho procesadores lógicos. Al agregar la virtualización, el rol de servidor Buzón de correo del DAG alternativo se implementa en cuatro máquinas virtuales, cada una con cuatro procesadores virtuales, con un total de ocho procesadores virtuales.

En el diseño físico, se implementó el servidor de combinación de acceso de cliente y transporte de concentradores en dos servidores físicos con un total de 16 procesadores lógicos. Al agregar la virtualización, los servidores de combinación de acceso de cliente y transporte de concentradores se implementan en cuatro máquinas virtuales, cada una con cuatro procesadores virtuales, con un total de 16 procesadores virtuales.

Cuando se utilizan servidores raíz de Hyper-V con ocho procesadores lógicos, implementar una máquina virtual de servidor de buzones y una máquina virtual de servidor de combinación de acceso de cliente y transporte de concentradores en cada servidor raíz de Hyper-V es una práctica recomendada.

Ahora, la solución tiene diez máquinas virtuales ejecutándose en cinco servidores físicos en cada sitio, como se muestra en la siguiente figura.

Máquinas virtuales

por determinar

Según los cálculos de los pasos anteriores, puede anticipar que cuatro servidores físicos puedan manejar los requisitos de megaciclos para el peor caso de carga de trabajo. En este paso, reducirá la cantidad de servidores físicos de cinco a cuatro y redistribuirá los servidores de buzones del DAG alternativo en los cuatro servidores físicos restantes. Para mantener la simetría en los cuatro servidores físicos, necesitará cambiar las dos máquinas virtuales de servidores de buzones (con cuatro procesadores virtuales) a cuatro máquinas virtuales de servidores de buzones (con dos procesadores virtuales).

Esto resultará en doce máquinas virtuales que se ejecutarán en cuatro servidores físicos en cada sitio, como se muestra en las siguientes figuras.

Máquinas virtuales

por determinar

Máquinas virtuales

por determinar

En este paso, calculará la cantidad de procesadores virtuales necesarios para cada máquina virtual. En los siguientes pasos, realizará los cálculos para comprobar las hipótesis.

Cada una de las cuatro máquinas virtuales de servidores de buzones en el DAG principal admitirá el 25% de los 10 800 buzones activos en el DAG en condiciones normales de funcionamiento, es decir, 2700 buzones cada uno. En caso de una falla de servidor, las máquinas virtuales de servidores de buzones que subsistan tendrán que admitir 5400 buzones activos.

En caso de fallo del sitio, cada una de las cuatro máquinas virtuales de servidores de buzones en el DAG principal admitirá el 25% de los 10 800 buzones activos en el DAG, es decir, 2700 buzones cada uno. En este escenario, los buzones de correo se ejecutarán en la tercera y última copia de la base de datos. En caso de una falla de servidor o de la máquina virtual, las máquinas virtuales que subsistan no tendrán que admitir 5400 buzones activos. La cantidad máxima de buzones de correo siempre será 2700.

Es lógico que las máquinas virtuales en el DAG alternativo tengan la mitad de los procesadores virtuales que las máquinas virtuales del DAG principal. En esta solución, se asignan cuatro procesadores a las máquinas virtuales del DAG principal y dos procesadores virtuales a las máquinas virtuales del DAG alternativo.

Si mantiene una relación 1:1 de procesadores virtuales lógicos, quedan dos procesadores virtuales para cada servidor de combinación de acceso de cliente y transporte de concentradores. Ya que desea mantener una relación 1:1 de núcleos de servidores de buzones respecto de los núcleos de servidores de combinación de acceso de cliente y transporte de concentradores, asigne cuatro procesadores virtuales a cada servidor de combinación de acceso de cliente y transporte de concentradores. Esto resulta en un escenario en el que la cantidad de procesadores virtuales excede la cantidad de procesadores físicos en el servidor raíz. A esto se lo conoce con el nombre de suscripción excesiva. En la mayoría de los casos, le recomendamos que no utilice la suscripción excesiva. Sin embargo, en esta solución, las máquinas virtuales de servidores de buzones en el DAG alternativo se usarán solamente durante los fallos de los sitios. Debido a que este es un evento de baja incidencia, un ligero exceso de suscripción está bien.

En la siguiente tabla, se muestran las asignaciones de procesadores virtuales propuestas.

Asignación del procesador virtual

Máquina virtual Recuento de procesador virtual

Combinación de acceso de clientes y transporte de concentradores

3

Buzón (DAG principal)

4

Buzón (DAG alternativo)

2

Total

9

Soluciones comprobadas de Exchange 2010

En los pasos anteriores, calculó los megaciclos necesarios para admitir la cantidad de usuarios de buzón activos. En los pasos siguientes, determinará la cantidad de megaciclos disponibles que pueden admitir el procesador y el modelo de servidor para poder determinar el número de buzones activos que puede admitir cada servidor virtual.

Soluciones comprobadas de Exchange 2010

Al implementar las máquinas virtuales el servidor raíz, debe considerar los megaciclos necesarios para admitir el hipervisor y la pila de virtualización. Esta sobrecarga varía de servidor a servidor y bajo diferentes cargas de trabajo. Se usará un cálculo conservador del 10% de los megaciclos disponibles, como se muestra en el siguiente cálculo:

  • Megaciclos disponibles ajustados = megaciclos disponibles × 0,90

    = 45466 × 0.90

    = 40919

Cada servidor tiene una capacidad utilizable para máquinas virtuales de 40 919 megaciclos.

La capacidad utilizable por procesador lógico es 5115 megaciclos.

Soluciones comprobadas de Exchange 2010

En un paso anterior, determinó la asignación del procesador virtual para estos tres tipos de máquinas virtuales, como se muestra en la siguiente tabla.

Asignación del procesador virtual

Máquina virtual Recuento de procesador virtual

Combinación de acceso de clientes y transporte de concentradores

3

Buzón (DAG principal)

4

Buzón (DAG alternativo)

2

Total

9

Dado que hay nueve procesadores virtuales en ejecución en un servidor raíz con ocho procesadores lógicos, la capacidad de megaciclos de un procesador virtual no es igual a la capacidad de megaciclos de un procesador lógico. En este paso, calcule los megaciclos disponibles por procesador virtual:

  • Megaciclos por procesador virtual = megaciclos por procesador lógico × (número de procesadores lógicos ÷ número de procesadores virtuales)

    = 5115 × (8 ÷ 9)

    = 4547

En este paso, para determinar los megaciclos disponibles por máquina virtual, consulte la siguiente tabla.

Megaciclos disponibles por máquina virtual

Máquina virtual Recuento de procesador virtual Megaciclos por procesador virtual Megaciclos disponibles

Combinación de acceso de clientes y transporte de concentradores

3

4547

13641

Buzón (DAG principal)

4

4547

18188

Buzón (DAG alternativo)

2

4547

9094

Dado que las hipótesis de diseño indican no superar el 80% de utilización del procesador, ajuste los megaciclos disponibles para reflejar el 80% objetivo, como se muestra en la siguiente tabla.

Megaciclos de destino disponibles por máquina virtual

Máquina virtual Megaciclos disponibles Utilización máxima del procesador Megaciclos de destino disponibles

Combinación de acceso de clientes y transporte de concentradores

13641

80%

10913

Buzón (DAG principal)

18188

80%

14550

Buzón (DAG alternativo)

9094

80%

7275

Soluciones comprobadas de Exchange 2010

Para comprobar la capacidad de la CPU de las máquinas virtuales del servidor de buzones principal, use los siguientes pasos.

El peor caso de carga de trabajo para el servidor de buzones principal es durante un escenario de mantenimiento o error del servidor, donde 5400 buzones están activos en el servidor de buzones principal y las copias remotas secundarias y terciarias se mantienen (por ejemplo, después de un evento de recuperación donde se actualizan las copias pasivas pero los buzones activos no se trasladaron de nuevo al servidor de destino). En este paso, se determinan los requisitos de megaciclos para la máquina virtual del servidor de buzones principal mediante el uso del siguiente cálculo:

  • Megaciclos de buzones necesarios = (número de usuarios de buzones × megaciclos específicos del perfil) + número de copias de bases de datos remotas × (número de usuarios de buzones × megaciclos específicos del perfil × 10%)

    = (5400 × 2) + 2 × (5400 × 2 × 0.1)

    = 10800 + 2160

    = 12960

En este paso, puede determinar si los megaciclos disponibles son mayores que los megaciclos necesarios. Necesita 12 960 megaciclos y tiene 14 550, de modo que la máquina virtual del servidor de buzones principal tiene la capacidad suficiente para admitir 5400 buzones activos.

Soluciones comprobadas de Exchange 2010

Para comprobar la capacidad de la CPU de las máquinas virtuales del servidor de buzones secundario, use los siguientes pasos.

El peor caso de carga de trabajo para el servidor de buzones secundario es durante un escenario de falla del sitio, donde 2700 buzones están activos en el servidor de buzones secundario y las copias remotas secundarias y terciarias se mantienen (por ejemplo, después de que un sitio original vuelve a conectarse cuando se actualizan las copias principales y secundarias pero los buzones activos no se trasladaron de nuevo al sitio original). En este paso, para determinar los requisitos de megaciclos para la máquina virtual del servidor de buzones secundario, use el siguiente cálculo:

  • Megaciclos de buzones necesarios = (número de usuarios de buzones × megaciclos específicos del perfil) + número de copias de bases de datos remotas × (número de usuarios de buzones × megaciclos específicos del perfil × 10%)

    = (2700 × 2) + 2 × (2700 × 2 × 0.1)

    = 5400 + 1080

    = 6480

En este paso, puede determinar si los megaciclos disponibles son mayores que los megaciclos necesarios. Necesita 6480 megaciclos y tiene 7275, de modo que la máquina virtual del servidor de buzones secundario tiene la capacidad suficiente para admitir 2700 buzones activos.

Soluciones comprobadas de Exchange 2010

Puede usar los siguientes pasos para determinar la memoria requerida por máquina virtual del servidor de buzones principal.

En un paso anterior, determinó que los requisitos de memoria caché de base de datos para todos los buzones era de 190 GB y la memoria caché promedio necesaria por buzón activo era de 6 MB.

Para realizar el diseño del escenario del peor caso de error, debe calcular la memoria caché de base de datos necesaria en 5400 buzones activos en las máquinas virtuales del servidor de buzones restante:

  • Memoria necesaria para la memoria caché de base de datos = número de buzones activos × memoria caché promedio por buzón

    = 5400 × 6 MB

    = 32.400 MB

    = 31,6 GB

En este paso, consulte la siguiente tabla para determinar la configuración de memoria recomendada.

Requisitos de memoria

Memoria física del servidor (RAM) Tamaño de memoria caché de base de datos (rol de servidor Buzón de correo únicamente)

24 GB

17,6 GB

32 GB

24,4 GB

48 GB

39,2 GB

La configuración de memoria recomendada para admitir 31,6 GB de memoria caché base de datos para un rol de servidor Buzón de correo es 48 GB.

Soluciones comprobadas de Exchange 2010

Puede usar los siguientes pasos para determinar la memoria requerida por máquina virtual del servidor de buzones secundario.

En un paso anterior, determinó que los requisitos de memoria caché de base de datos para todos los buzones era de 190 GB y la memoria caché promedio necesaria por buzón activo era de 6 MB.

Para realizar el diseño del escenario del peor caso de error, debe calcular la memoria caché de base de datos necesaria en 2700 buzones activos que residen en las máquinas virtuales del servidor de buzones secundario:

  • Memoria necesaria para la memoria caché de base de datos = número de buzones activos × memoria caché promedio por buzón

    = 2700 × 6 MB

    = 16.200 MB

    = 15,8 GB

En este paso, consulte la siguiente tabla para determinar la configuración de memoria recomendada.

Requisitos de memoria

Memoria física del servidor (RAM) Tamaño de memoria caché de base de datos (rol de servidor Buzón de correo únicamente) Tamaño de memoria caché de base de datos (varios roles de servidor; por ejemplo, roles de servidor Buzón de correo y transporte de concentradores)

24 GB

17,6 GB

14 GB

32 GB

24,4 GB

20 GB

48 GB

39,2 GB

32 GB

La configuración de memoria recomendada para admitir 15.8 GB de memoria caché base de datos para un rol de servidor Buzón de correo es 24 GB.

Soluciones comprobadas de Exchange 2010

Para determinar la configuración de memoria de la máquina virtual del servidor de combinación de acceso de clientes y transporte de concentradores, consulte la siguiente tabla.

Configuraciones de memoria para servidores de Exchange 2010 basadas en los roles de servidor instaladas

Rol del servidor de Exchange 2010 Mínimo admitido Máximo recomendado

Rol de servidor combinado de acceso de clientes y transporte de concentradores (roles de servidor de acceso de clientes y transporte de concentradores en ejecución en el mismo servidor físico)

4 GB

2 GB por núcleo (8 GB mínimo)

Dado que la máquina virtual del servidor de combinación de acceso de clientes y transporte de concentradores tiene tres procesadores virtuales, se asignan 6 GB de memoria a cada máquina virtual del servidor de combinación de acceso de clientes y transporte de concentradores.

Soluciones comprobadas de Exchange 2010

Para determinar la memoria requerida por servidor raíz de Hyper-V, use el siguiente cálculo:

  • Memoria del servidor raíz = memoria del sistema operativo raíz + memoria de la máquina virtual del servidor de combinación de acceso de clientes y transporte de concentradores + memoria de la máquina virtual del servidor de buzones principal + memoria de la máquina virtual del servidor de buzones secundario

    = 4 GB + 6 GB + 48 GB + 24 GB

    = 82 GB

El requisito de memoria física para el servidor raíz es 82 GB. Para realizar la alineación con las configuraciones de memoria física recomendadas, el servidor se completará con 96 GB.

Soluciones comprobadas de Exchange 2010

En un paso anterior, determinó que la solución incluiría tres DAG y que cada DAG abarcaría dos de las tres ubicaciones físicas. Ahora que determinó cuántos servidores de buzones se necesitan para admitir la carga de trabajo y los requisitos de DAG, puede continuar con el diseño de DAG.

Diseño de DAG

Por determinar

Soluciones comprobadas de Exchange 2010

Utilice los pasos siguientes para el diseño de disposición de la copia de base de datos.

Para determinar el número óptimo de bases de datos de Exchange para implementar, use la calculadora de requisitos del rol de servidor Buzón de correo Exchange 2010. Escriba la información apropiada en la ficha Entrada y seleccione en Calcular automáticamente el número de bases de datos/DAG. Para el campo de límite de tamaño de buzones, use la cuota de buzones completamente aprovisionados de 2048 MB.

Bases de datos de Exchange en el DAG

por determinar

En la ficha Requisitos de rol, aparece el número recomendado de bases de datos. Para esta solución, la calculadora recomienda que cada DAG tenga un mínimo de 24 bases de datos únicas.

*Punto de decisión de diseño*

Siguiendo las recomendaciones de la calculadora, se implementarán 24 bases de datos por DAG.

Dado que hay 24 bases de datos únicas por DAG y ocho servidores en el DAG, cada uno de los cuatro servidores en el sitio principal alojará seis copias de bases de datos activas en condiciones normales de funcionamiento.

Comience por agregar las copias de las bases de datos activas a los cuatro servidores, como se muestra en la siguiente tabla.

Diseño de base de datos en condiciones normales de funcionamiento

Base de datos MBX1 MBX2 MBX3 MBX4

DB1-6

A1

DB7-12

A1

DB13-18

A1

DB19-24

A1

En la tabla anterior, se aplica lo siguiente:

  • A1 = copia de base de datos activa

En un paso anterior, determinó que la estrategia de resistencia del servidor de buzones se diseñaría para la eficacia operativa. Los servidores de buzones se implementarían en pares.

Dado que hay cuatro servidores de buzones en el DAG, el servidor 1 y el 2 serán un par, y el servidor 3 y el 4 serán otro par. En este paso, agrega copias de bases de datos pasivas (P1) al servidor alternativo en cada par, como se muestra en la tabla siguiente.

Diseño de base de datos en condiciones normales de funcionamiento con copias pasivas

Base de datos MBX1 MBX2 MBX3 MBX4

DB1-6

A1

P1

DB7-12

P1

A1

DB13-18

A1

P1

DB19-24

P1

A1

En la tabla anterior, se aplica lo siguiente:

  • A1 = copia de base de datos activa

  • P1 = copia de base de datos pasiva

Durante un evento de mantenimiento o error del servidor, las copias P1 se activan en el servidor alternativo. La tabla siguiente ilustra esto cuando MBX2 y MBX4 están inactivos por mantenimiento.

Diseño de copia de bases de datos durante las condiciones de mantenimiento o error de servidor en el sitio

por determinar

En la tabla anterior, se aplica lo siguiente:

  • A1 = copia de base de datos activa

  • P1 = copia de base de datos pasiva

En este paso, agregue una tercera copia de la base de datos a los miembros del DAG en el centro de datos secundario para suministrar resistencia de sitios, como se muestra en la tabla siguiente.

Copias de la base de datos agregadas al centro de datos secundario para admitir la resistencia de sitios

Base de datos Sitio A MBX1 Sitio A MBX2 Sitio A MBX3 Sitio A MBX4 Sitio B MBX5 Sitio B MBX6 Sitio B MBX7 Sitio B MBX8

DB1-6

A1

P1

P2

DB7-12

P1

A1

P2

DB13-18

A1

P1

P2

DB19-24

P1

A1

P2

En la tabla anterior, se aplica lo siguiente:

  • A1 = copia de base de datos activa

  • P1 = copia de base de datos pasiva local

  • P2 = copia de base de datos pasiva remota

En caso de error en el centro de datos principal, las copias de P2 se activarán en el sitio secundario, como se muestra en la tabla siguiente. Tenga en cuenta que hasta que el sitio principal vuelva a conectarse, solo habrá una copia única de la base de datos.

Diseño de base de datos en condiciones de falla del sitio

por determinar

En la tabla anterior, se aplica lo siguiente:

  • A1 = copia de base de datos activa

  • P1 = copia de base de datos pasiva

  • P2 = copia de base de datos pasiva

Soluciones comprobadas de Exchange 2010

El modo de coordinación de activación de centro de datos (DAC) se usa para controlar el comportamiento de activación de un DAG cuando ocurre un error grave que lo afecta (por ejemplo, un error total de uno de los centros de datos). Cuando el modo DAC no se encuentra habilitado y ocurre un error que afecta a varios servidores de un DAG, al restaurarse la mayoría de los miembros del DAG después del error, el DAG se reiniciará e intentará montar bases de datos. En una configuración de varios centros de datos, este comportamiento podría causar el síndrome de cerebro dividido, problema que ocurre cuando se produce error en todas las redes y los miembros del DAG no pueden recibir señales de latido entre ellos. El síndrome de cerebro dividido también puede tener lugar cuando se interrumpe la conectividad de red entre los centros de datos. El síndrome de cerebro dividido se evita al requerir la disponibilidad e interacción de una mayoría de los miembros del DAG (y, en el caso de los DAG con un número par de miembros, del servidor testigo del DAG) de forma permanente para que el DAG esté en funcionamiento. Para obtener más información, consulte Descripción del modo de coordinación de activación del centro de datos.

*Punto de decisión de diseño*

El modo DAC se habilitará en los tres DAG del entorno para evitar el síndrome de cerebro dividido.

Soluciones comprobadas de Exchange 2010

En Exchange 2010, el DAG usa un conjunto mínimo de componentes del clúster de conmutación por error de Windows. Uno de esos componentes es el recurso de quórum, que ofrece una forma de arbitraje al determinar el estado del clúster y tomar decisiones de pertenencia. Es esencial que cada miembro del DAG tenga una vista uniforme de la forma en que está configurado el clúster subyacente del DAG. El quórum actúa como repositorio definitivo de toda la información de configuración relativa al clúster. El quórum se usa también como mecanismo para resolver empates con el fin de evitar el síndrome de cerebro dividido. El síndrome de cerebro dividido es una condición que ocurre cuando los miembros del DAG no pueden comunicarse entre ellos pero están disponibles y en ejecución. El síndrome de cerebro dividido se evita al requerir la disponibilidad e interacción de una mayoría de los miembros del DAG (y en el caso de los DAG con un número par de miembros, el servidor testigo del DAG) en forma permanente para que el DAG esté en funcionamiento.

Un servidor testigo es un servidor externo al DAG que aloja el testigo de recursos compartidos de archivos, que se usa para alcanzar y mantener quórum cuando el DAG cuenta con un número par de miembros. Los DAG con un número impar de miembros no usan un servidor testigo. Después de crear un DAG, el testigo de recursos compartidos de archivos se agrega en forma predeterminada al servidor de transporte de concentradores (que no tiene el rol de servidor Buzón de correo instalado) en el mismo sitio que el primer miembro del DAG. Si su servidor de transporte de concentradores está en ejecución en una máquina virtual que reside en el mismo servidor raíz que las máquinas virtuales que ejecutan el rol de servidor Buzón de correo, recomendamos que mueva la ubicación del testigo de recursos compartidos de archivos a otro servidor de alta disponibilidad. Puede mover el testigo de recursos compartidos de archivos a un controlador de dominio pero, debido a las implicaciones de seguridad, hágalo solo como último recurso.

En soluciones en las que el DAG abarca varios sitios, recomendamos que se defina un testigo de recursos compartidos de archivos para el sitio secundario. Esto permitirá que el clúster mantenga el quórum durante un evento de error del sitio con el modo DAC habilitado.

*Punto de decisión de diseño*

Dado que se decidieron implementar tres DAG y todos los DAG incluirán miembros en varios sitios, deben definirse tres directorios testigos principales y tres directorios testigos alternativos. Estos directorios se ubicarán en servidores de archivo dentro de cada sitio.

Soluciones comprobadas de Exchange 2010

Al planificar la organización de Exchange 2010, una de las decisiones más importantes que debe tomar es cómo ordenar el espacio de nombres externo de la organización. Un espacio de nombres es una estructura lógica que normalmente está representada por un nombre de dominio en el Sistema de nombres de dominio (DNS). Al definir el espacio de nombres, se deben tener en cuenta las diferentes ubicaciones de los clientes y los servidores que hospedan sus buzones. Además de las ubicaciones físicas de los clientes, se debe evaluar cómo se conectan a Exchange 2010. Las respuestas a estas cuestiones determinarán el número de espacios de nombres que debe tener. Normalmente, los espacios de nombres se alinean con la configuración DNS Se recomienda que cada sitio de Active Directory en una región que tenga uno o más servidores de acceso de cliente con conexión a Internet tenga un espacio de nombres único. Esto normalmente se representa en DNS con un registro A; por ejemplo, mail.contoso.com o mail.europe.contoso.com.

Para obtener más información, vea Descripción de los espacios de nombres de servidores de acceso de clientes.

Existen varias formas diferentes de organizar sus espacios de nombres externos pero, generalmente, sus requisitos pueden cumplirse con uno de los siguientes modelos de espacio de nombres:

  • Modelo de centro de datos consolidado   Este modelo consiste en un único sitio físico. Todos los servidores se ubican dentro del sitio y hay un solo espacio de nombres; por ejemplo, mail.contoso.com.

  • Espacio de nombres único con sitios proxy   Este modelo incluye varios sitios físicos. Sólo un sitio contiene un servidor de acceso de cliente abierto a Internet; Los demás sitios no están expuestos a Internet. Sólo hay un espacio de nombres para los sitios en este modelo, por ejemplo, mail.contoso.com.

  • Espacio de nombres único y varios sitios   Este modelo incluye varios sitios físicos. Cada sitio puede tener un servidor de acceso de cliente con conexión a Internet. Como alternativa, puede haber únicamente un solo sitio que incluya servidores de acceso de cliente con conexión a Internet. Sólo hay un espacio de nombres para los sitios en este modelo, por ejemplo, mail.contoso.com.

  • Espacios de nombres regionales   Este modelo consta de varios sitios físicos y varios espacios de nombres. Por ejemplo, un sitio ubicado en la ciudad de Nueva York tendría el espacio de nombres mail.usa.contoso.com, un sitio ubicado en Toronto tendría el espacio de nombres mail.canada.contoso.com y un sitio ubicado en Londres tendría el espacio de nombres mail.europe.contoso.com.

  • Varios bosques   Este modelo consta de varios bosques que tienen varios espacios de nombres. Una organización que usa este modelo podría estar formada por dos empresas asociadas; por ejemplo, Contoso y Fabrikam. Los espacios de nombres podrían incluir mail.usa.contoso.com, mail.europe.contoso.com, mail.asia.fabrikam.com y mail.europe.fabrikam.com.

*Punto de decisión de diseño*

Para este escenario, se selecciona el modelo de espacios de nombres regional, dado que es la mejor opción para las organizaciones con buzones activos en varios sitios.

La ventaja de este modelo es que se reduce la utilización de proxy, dado que un mayor porcentaje de usuarios podrá conectarse al servidor de acceso de cliente en el mismo sitio de Active Directory como su servidor de buzones. Esto mejorará la experiencia y el rendimiento del usuario final. Los usuarios que tienen buzones en un sitio que no tiene un servidor de acceso de cliente con conexión a Internet continuarán procesándose mediante proxy.

Esta solución también tiene los siguientes requisitos de configuración:

  • Se deben administrar varios registros DNS.

  • Se deben obtener, configurar y administrar varios certificados.

  • La administración de la seguridad es más compleja, dado que cada sitio con conexión a Internet requiere un equipo con Microsoft Forefront Threat Management Gateway u otra solución de firewall o proxy inverso.

  • Los usuarios deben conectarse a su propio espacio de nombres regional. Esto puede generar más llamadas al servicio de asistencia técnica y capacitación.

Soluciones comprobadas de Exchange 2010

En Exchange 2010, se incluyeron el servicio de acceso de cliente de RPC y el servicio de libreta de direcciones de Exchange en el rol de servidor de acceso de cliente para mejorar la experiencia de los usuarios con los buzones de correo cuando se mueve la copia de base de datos de buzones de correo activa a otro servidor de buzones de correo (p. ej., durante eventos de mantenimiento y errores de base de datos de buzones de correo). Los puntos finales de conexión para el acceso a buzones de Microsoft Outlook y otros clientes MAPI se han movido del rol de servidor Buzón de correo al rol de servidor de acceso de cliente. Por lo tanto, las conexiones de Outlook internas y externas ahora deben tener la carga equilibrada entre todos los servidores de acceso de cliente en el sitio para alcanzar la tolerancia a errores. Para asociar el extremo de MAPI con un grupo de servidores de acceso de cliente en lugar de un servidor de acceso de cliente específico, puede definir una matriz de servidores de acceso de cliente. Solo puede configurar una matriz por sitio de Active Directory y una matriz no puede abarcar más de un sitio de Active Directory. Para obtener más información, vea Descripción del acceso de clientes RPC y Understanding Load Balancing in Exchange.

*Punto de decisión de diseño*

Dado que existe una implementación de tres sitios con cuatro servidores que ejecutan el rol de servidor de acceso de cliente en cada sitio, habrá un total de tres matrices de servidores de acceso de cliente. Se usará una solución de equilibrio de carga de hardware para distribuir la carga en las matrices de servidores de acceso de cliente en cada sitio.

Soluciones comprobadas de Exchange 2010

Utilice los pasos siguientes para determinar una modelo de equilibrio de carga de hardware.

En este ejemplo, el proveedor preferido es Cisco, dado que la línea de productos de Cisco Application Control Engine (ACE) funciona con el sistema informático unificado de Cisco seleccionado para el servidor, la red y los componentes de conectividad de almacenamiento de esta solución.

La línea de productos ACE de Cisco suministra una solución de centro de datos altamente disponible y escalable de la cual puede beneficiarse el entorno de la aplicación Exchange 2010. Los productos ACE de Cisco ofrecen interoperabilidad, con las siguientes ventajas:

  • Rendimiento, escalabilidad, producción y disponibilidad de las aplicaciones

  • Diseño basado en estándares

  • Arquitectura virtual con partición de dispositivos

  • Administración basada en roles y administración centralizada

  • Servicios de seguridad mediante la inspección profunda de paquetes, listas de control de acceso (ACL), seguimiento del camino inverso de unidifusión y traducción de direcciones de red (NAT)/traducción de direcciones de puerto

La línea de productos ACE de Cisco incluye dos modelos de equilibrio de carga de hardware diferentes que cumplen con las necesidades de la solución del centro de datos altamente disponible y escalable, apropiada para el entorno de la aplicación Exchange 2010. Éstos son el dispositivo Cisco ACE 4710 y el módulo de servicio integrado en las plataformas de enrutamiento Cisco Catalyst 6500/Cisco 7600.

El dispositivo Cisco ACE 4710 ofrece un rendimiento de hasta 4 Gbps en un factor de forma de una unidad en bastidor (1RU), que puede ampliarse mediante licencias de software y ofrece escalabilidad y protección de inversión de largo plazo. En su base, el 4710 es un chasis en bastidor de una unidad con una tarjeta aceleradora Cavium Nitrox Octeon, que suministra cuatro puertos Gigabit Ethernet que pueden unirse mediante Cisco EtherChannel y conectarse a un conmutador. De forma predeterminada, el Cisco ACE 4710 admite la visualización con un dispositivo administrador y cinco dispositivos usuarios, ancho de banda de 1-Gbps, 1000 transacciones de capa de sockets seguros (SSL) por segundo y 100 megabits por segundo (Mbps) de compresión. La solución puede ampliarse sin necesidad de un equipo nuevo mediante las siguientes actualizaciones de licencia de software:

  • Rendimiento   El rendimiento predeterminado de 1 Gbps puede aumentarse a 2 ó 4 Gbps.

  • Dispositivos virtuales   El número de dispositivos virtuales puede aumentarse de 5 a 20 dispositivos virtuales.

  • Transacciones de SSL por segundo   El valor de las transacciones de SSL por segundo puede aumentarse de 1000 a 5000 ó 7500.

  • Compresión   La compresión puede aumentarse a 500 Mbps, 1 ó 2 Gbps de rendimiento.

  • Control de acceso basado en roles   La administración centralizada basada en roles se suministra mediante una GUI del administrador de redes de aplicaciones o interfaz de línea de comandos (CLI).

  • Alta disponibilidad   Se ofrece compatibilidad para configuraciones redundantes (dentro del dispositivo y entre contexto).

El dispositivo Cisco ACE de los conmutadores de la serie Cisco Catalyst 6500 o los enrutadores de la serie Cisco 7600 ofrecen un rendimiento de hasta 16 Gbps en un factor de forma de módulo de una ranura, que al igual que el dispositivo ACE 4710, pueden ampliarse mediante licencias de software. Pueden instalarse hasta cuatro módulo Cisco ACE en un único conmutador de la serie Cisco Catalyst 6500 o enrutador de la serie Cisco 7600. Cada uno puede admitir los procesos empresariales de varias unidades empresariales independientes y aprovechan la amplia gama variedad de opciones de conectividad disponibles en el conmutador o enrutador. El administrador del sistema determina los requisitos de aplicación y asigna los servicios de red pertinentes como contextos virtuales. Cada contexto contiene su propio conjunto de directivas, interfaces, recursos y administradores:

  • Rendimiento   Los servicios de equilibrio de carga ofrecen una capacidad de rendimiento de hasta 16 Gbps y 345 000 conexiones de nivel 4 por segundo.

  • Dispositivos virtuales   El número de dispositivos virtuales puede aumentarse de 5 a 250.

  • Transacciones de SSL por segundo   Las transacciones de SSL por segundo pueden aumentarse a 15 000 sesiones de DDL mediante licencias en módulos ACE20 y a 30 000 en módulos ACE30.

  • Compresión   La compresión puede aumentarse a 6 Gbps en módulos ACE30.

  • Control de acceso basado en roles   La administración centralizada basada en roles se suministra mediante una GUI del administrador de redes de aplicaciones o CLI.

  • Alta disponibilidad   Se ofrece compatibilidad para configuraciones redundantes (dentro del chasis, entre chasis y entre contexto).

Se selecciona el dispositivo Cisco ACE 4710, ya que ofrece una disponibilidad de aplicaciones maximizada, seguridad de aplicaciones integral y arquitectura visualizada, así como protección y valor de inversiones:

  • Disponibilidad de aplicaciones maximizada   El dispositivo Cisco ACE 4710 ayuda a garantizar la continuidad empresarial y el servicio a los usuarios finales mediante la mejora de la disponibilidad mediante el equilibrio de carga de nivel 4 altamente escalable y cambio de contenido de nivel 7, que también minimiza los efectos de errores del dispositivo o la aplicación.

  • Seguridad de aplicaciones integral   El Cisco ACE 4710 actúa como la última línea de defensa del servidor, ofrece protección contra las amenazas de aplicaciones y ataques de denegación de servicio (DoS) con características como la inspección profunda de paquetes, la seguridad de protocolos y redes y las capacidades de control de acceso altamente escalables.

  • Arquitectura virtualizada   La arquitectura virtualizada es un elemento de diseño principal de Cisco ACE y una proposición de venta única en contraste con las demás soluciones en el mercado. Los administradores de TI pueden configurar hasta 20 dispositivos virtuales en un solo dispositivo Cisco ACE 4710. El beneficio es una menor cantidad de dispositivos para administrar a medida que las implementaciones de aplicaciones aumentan, una reducción significativa en los gastos de alimentación y enfriamiento y un tiempo de servicio más rápido para las aplicaciones nuevas.

Soluciones comprobadas de Exchange 2010

Una solución de almacenamiento adecuadamente diseñada constituye un aspecto esencial de una implementación correcta del rol de servidor Buzón de correo de Exchange 2010. Para obtener más información, vea Diseño del almacenamiento del servidor de buzones de correo.

En la siguiente tabla, se resumen los requisitos de almacenamiento que se calcularon o determinaron en un paso de diseño anterior.

Resumen de requisitos de espacio en disco

Requisitos de espacio en disco Valor

Tamaño del buzón en el disco para un buzón de 2 GB (MB)

2301

Capacidad total de base de datos requerida (GB)

120128

Capacidad total de registro requerida (GB)

3974

Capacidad total requerida (GB)

124102

Capacidad total requerida para tres copias de bases de datos (GB)

372306

Capacidad total requerida para tres copias de bases de datos (terabytes)

364

Capacidad total requerida por sitio (terabytes)

122

Muchos clientes desean incrementar significativamente sus cuotas de buzones de correo cuando cambian a Exchange 2010. Sin embargo, puede tomar mucho tiempo para que el tamaño de los buzones pase de varios cientos de megabytes a varios gigabytes de tamaño. En este caso, puede ser bueno para algunas organizaciones intentar posponer compras de almacenamientos adicionales para el futuro, cuando el espacio de almacenamiento en disco sea más económico.

Muchos proveedores de almacenamiento ofrecen algunos tipos de soluciones de aprovisionamiento fino para que pueda tener más capacidad de almacenamiento para el servidor de Exchange de lo que está físicamente disponible y para que pueda incrementar el almacenamiento físico de forma dinámica a fin de satisfacer la creciente demanda sin sufrir interrupciones ni períodos de inactividad. Esto disminuye el costo total de propiedad, ya que reduce la asignación inicial de la capacidad de almacenamiento y simplifica su administración, ya que reduce los pasos necesarios para respaldar el crecimiento.

La implementación de almacenamiento unificado de aprovisionamiento fino de EMC está proporcionada por su característica de aprovisionamiento virtual, que admite la recuperación en caliente, la recuperación proactiva, la expansión fina de grupo no perjudicial y la capacidad de migrar entre LUN finos y LUN tradicionales y amplios sin períodos de inactividad. Esta flexibilidad separa el aprovisionamiento virtual de almacenamiento unificado de EMC, de las implementaciones típicas de aprovisionamiento fino.

*Punto de decisión de diseño*

La implementación actual de Exchange tiene una cuota de buzón definida de 200 MB. Después de cambiarse a Exchange 2010, se calcula que los tamaños de los buzones se incrementarán aproximadamente el 300% en los primeros 12 a 18 meses. El plan es comprar suficiente almacenamiento para albergar un promedio de tamaño de buzón de 600 MB. Durante la vida útil de la implementación de Exchange 2010, se espera que el promedio de los buzones de correo se acerque a 2 GB. Debido a que es caro pagar cuotas de buzones de 2 GB, se implementará el aprovisionamiento fino para que se implemente una cuota inicial de 600 MB. El almacenamiento físico subyacente se expandirá en presupuestos posteriores para satisfacer la demanda anticipada.

Cuando aprovecha el aprovisionamiento fino en el almacenamiento unificado de EMC para implementaciones de Exchange 2010, separar los archivos de registro de los archivos de bases de datos es una práctica recomendada. Si anticipa un crecimiento en el tamaño de los buzones pero no en el perfil de mensajes (mensajes enviados y recibidos por día), necesitará aumentar progresivamente los LUN de base de datos pero no los LUN de registro. No es recomendable poner los registros en LUN con aprovisionamiento fino.

La separación de los LUN de base de datos y registro también proporciona la flexibilidad de colocarlos en discos de distintos tipos o usar diferentes tipos de RAID.

*Punto de decisión de diseño*

En cumplimiento con las prácticas recomendadas de EMC, las bases de datos y los registros se separarán en LUN distintos. Debido a que se espera que el perfil de mensajes se mantenga medianamente constante en los siguientes tres años, colocar los registros en los LUN con aprovisionamiento fino no ofrece ningún beneficio.

Debido a que las restauraciones y las copias de seguridad basadas en VSS operan a nivel de LUN, la cantidad de bases de datos por LUN generalmente está determinada por la estrategia de copias de seguridad. En un paso anterior, se decidió no incluir las copias de seguridad basadas en VSS como parte de la estrategia de resistencia de bases de datos. La decisión de la cantidad de bases de datos por LUN se basará en otros factores. Según las prácticas recomendadas, debería implementar generalmente una sola base de datos por LUN. Tener más de una base de datos por LUN podría provocar lo siguiente:

  • Una base de datos sobrecargada que afecta a una base de datos correcta

  • Una operación de propagación en una base de datos que afecta a una base de datos correcta

  • E/S de base de datos pasiva que afecta a bases de datos activas

*Punto de decisión de diseño*

Debido a que no hay requisitos para implementar más de una base de datos por LUN, el diseño de almacenamiento se basará en un modelo que consiste en una sola base de datos por LUN.

En un paso anterior, determinó que cada servidor principal de buzones admitiría seis bases de datos activas y seis pasivas. Habrá un total de 24 LUN para cada servidor de buzones de centro de datos principal, como se describe en la siguiente tabla.

Cantidad de LUN requeridos por servidor de buzones

Tipos de LUN LUN por servidor

LUN de base de datos activa

6

LUN de registro activo

6

LUN de base de datos pasiva

6

LUN de registro pasivo

6

LUN totales

24

En un paso anterior, determinó que cada servidor secundario de buzones admitiría seis bases de datos pasivas. Habrá un total de 12 LUN para cada servidor de buzones de centro de datos secundario, como se describe en la siguiente tabla.

Cantidad de LUN requeridos por servidor de buzones

Tipos de LUN LUN por servidor

LUN de base de datos pasiva

6

LUN de registro pasivo

6

LUN totales

12

Para simplificar el resto de los pasos de diseño de almacenamiento, utilice un enfoque de creación de bloque. En esta solución, cada base de datos admite 450 buzones de correo activos. Cada servidor de buzones admite 6 bases de datos o 2700 buzones activos en 6 LUN de base de datos y 6 LUN de registro. Se utilizará un bloque de creación de 12 LUN que admita incrementos de 2700 buzones.

En este paso, calcule las IOPS transaccionales necesarias para admitir los 2700 usuarios de buzones de correo del bloque de creación. En un paso posterior, utilizará los requisitos de IOPS para determinar la cantidad mínima y máxima de ejes que debe implementar para el bloque de creación en la cuota de buzones inicial y completamente aprovisionada. Utilice el siguiente cálculo:

  • IOPS transaccionales totales requeridas para el bloque de creación = IOPS por usuario de buzón × cantidad de buzones × factor de sobrecarga de E/S

    = 0.10 × 2700 × 20%

    = 324 IOPS

En un paso anterior, calculó que el tamaño de los buzones en disco para un límite de cuota de buzones de 2048 MB es 2301 MB. Debido a que se utilizará el aprovisionamiento fino, calcule el tamaño en disco inicial de los buzones. Este valor se utilizará en pasos posteriores para determinar los requisitos de capacidad inicial.

Los siguientes cálculos se utilizan para determinar el tamaño inicial de los buzones para esta solución basada en una cuota de buzones de 600 MB:

  • Espacio en blanco = 100 mensajes por día x 75 ÷ 1024 MB = 7,3 MB

  • Contenedor = (100 mensajes por día × 75 ÷ 1024 MB × 14 días) + (600 MB × 0,012) + (600 MB × 0,058) = 144,2 MB

  • Tamaño de buzones en disco = límite de buzones + espacio en blanco + contenedor

    = 600 MB + 7,3 MB + 144,2 MB

    = 752 MB

Para determinar la capacidad de almacenamiento inicial necesaria para 2700 buzones con una cuota inicial de 600 MB, utilice los siguientes cálculos:

  • Capacidad de archivos de base de datos = (cantidad de buzones × tamaño de buzón en disco × factor crecimiento de sobrecarga de base de datos) + (20% de sobrecarga de datos)

    = (2700 × 752 × 1) + (406080)

    = 2.436.480 MB

    = 2.379 GB

  • Capacidad de catálogo de base de datos = 10% de la capacidad de los archivos de base de datos

    = 238 GB

  • Capacidad total de base de datos = (tamaño de archivos de base de datos) + (tamaño de índice) ÷ 0,80 para proporcionar un 20% de espacio libre del volumen

    = (2379 + 238) ÷ 0.8

    = 3.271 GB

Las seis bases de datos en el bloque de creación requieren 3271 GB de capacidad inicial de almacenamiento.

Para determinar la capacidad de almacenamiento totalmente aprovisionada necesaria para 2700 buzones con una cuota de 2048 MB, utilice los siguientes cálculos:

  • Capacidad de archivos de base de datos = (cantidad de buzones × tamaño de buzón en disco × factor crecimiento de sobrecarga de base de datos) + (20% de sobrecarga de datos)

    = (2700 × 2301 × 1) + (1242540)

    = 7.455.240 MB

    = 7.281 GB

  • Capacidad de catálogo de base de datos = 10% de la capacidad de los archivos de base de datos

    = 728 GB

  • Capacidad total de base de datos = (tamaño de archivos de base de datos) + (tamaño de índice) ÷ 0,80 para proporcionar un 20% de espacio libre del volumen

    = (7281 + 728) ÷ 0.8

    = 10.011 GB

Las seis bases de datos en el bloque de creación requieren 10 011 GB de capacidad de almacenamiento totalmente aprovisionada.

Para determinar la capacidad de almacenamiento de registros necesaria para 2700 buzones en el bloque de creación, utilice los siguientes cálculos:

  • Capacidad necesaria para los registros del bloque de creación = cantidad de usuarios de buzones de correo × cantidad de registros por buzón por día × tamaño de registro × (cantidad de días necesarios para reemplazar la infraestructura con errores) + (porcentaje de sobrecarga de migración de buzones)

    = (2700 × 20 × 1024 × 4) + (2700 × 0.01 × 2048)

    = 216.054 MB

    = 211 GB

  • Capacidad total de registro = capacidad de registro ÷ 0,80 para dar el 20% de espacio libre en el volumen

    = 211 ÷ 0.80

    = 264

Los seis conjuntos de registros en el bloque de creación requieren 264 GB de capacidad de almacenamiento.

NotaNOTA:
Debido a que los volúmenes de registro no tienen aprovisionamiento fino, la capacidad de almacenamiento calculada representa los requisitos de capacidad de registro de un entorno totalmente aprovisionado.

En este paso, determine la cantidad de ejes necesarios para admitir los requisitos de IOPS. En el siguiente paso, determinará la cantidad de ejes necesarios para cumplir los requisitos de capacidad.

En un paso anterior, se determinó que se necesitan 324 IOPS para admitir el bloque de creación de 2700 buzones. En este paso, calcule la cantidad de discos necesarios para cumplir los requisitos de IOPS usando el siguiente cálculo:

  • Cantidad de discos = (IOPS de usuario × relación de lectura) + penalización de escritura × (IOPS de usuario × relación de escritura) ÷ capacidad de IOPS del tipo de disco seleccionado

    = (324 × 0.6) + 4 × (324 × 0.4) ÷ 155

    = 4.6

Los requisitos de IOPS se pueden cumplir con cinco discos en una configuración RAID-5.

NotaNOTA:
Estos cálculos son específicos para esta solución de EMC. Debe consultar a su proveedor de almacenamiento para obtener ayuda acerca de los requisitos de ejes de la solución de almacenamiento que eligió.

En un paso anterior, se determinó que el bloque de creación de 2700 buzones para un buzón aprovisionado inicialmente de 600 MB necesita una capacidad de almacenamiento de 3271 GB. La capacidad utilizable por eje de 450 GB en una configuración RAID-5 en un CX4 modelo 480 es de aproximadamente 402 GB. Para determinar la cantidad de discos necesarios, utilice el siguiente cálculo:

  • Cantidad de discos = (capacidad total requerida) ÷ (capacidad utilizable por eje con RAID-5)

    = 3271 GB ÷ 402 GB

    = 8.1

Se pueden cumplir los requisitos iniciales de capacidad de base de datos con nueve discos.

La configuración de grupos finos RAID-5 de cinco discos es una de las prácticas recomendadas de EMC para implementar almacenamiento en el almacenamiento unificado de EMC con aprovisionamiento fino. Asigne 10 discos para un bloque de creación de 2700 buzones para que haya suficiente margen de espacio para el crecimiento futuro.

En un paso anterior, se determinó que el bloque de creación de 2700 buzones para un buzón aprovisionado inicialmente de 2048 MB necesita una capacidad de almacenamiento de 10 011 GB. La capacidad utilizable por eje de 450 GB en una configuración RAID-5 en un CX4 modelo 480 es de aproximadamente 402 GB. Para determinar la cantidad de discos necesarios, utilice el siguiente cálculo:

  • Cantidad de discos = (capacidad total requerida) ÷ (capacidad utilizable por eje con RAID-5)

    = 10 011 GB ÷ 402 GB

    = 24.9

Se pueden cumplir los requisitos de capacidad de base de datos totalmente aprovisionados con 25 discos.

En un paso anterior, se determinó que el bloque de creación de 2700 buzones necesita una capacidad de almacenamiento de registro de 264 GB. El uso de dos unidades de 450 GB en una configuración RAID-1/0 en un CX4-480 proporciona 402 GB de capacidad de almacenamiento utilizable. La configuración de dos discos satisface los requisitos de capacidad de registro del bloque de creación de 2700 buzones.

Ahora que ya ha determinado la cantidad de ejes necesarios para admitir las IOPS y los requisitos de capacidad del bloque de creación, debe determinar la mejor forma de aprovisionar los LUN en la matriz para el bloque de creación cuando utiliza el aprovisionamiento fino o virtual.

Existen tres modelos principales que puede utilizar cuando diseña los grupos finos para Exchange:

  • Grupo de almacenamiento simple: el modelo más simple que proporciona el mejor uso del espacio consta de un gran grupo de almacenamiento para las bases de datos y los registros de Exchange. Sin embargo, no se recomienda un solo grupo fino cuando en la misma matriz física se ubican varias copias de la misma base de datos.

  • Un grupo de almacenamiento por servidor: un grupo de almacenamiento por cada servidor de buzones de Exchange proporciona más granularidad cuando se disponen los LUN en la matriz. Si se diseña apropiadamente, proporciona aislamiento de las copias de las bases de datos en conjuntos de ejes separados y puede minimizar cualquier conflicto de discos que se produzcan durante las actividades de inicialización o reinicialización, copia de seguridad y mantenimiento en línea (mantenimiento de base de datos en segundo plano). Sin embargo, según la cantidad de servidores de buzones que tenga, este modelo puede dar como resultado varios grupos finos, lo cual puede ser más difícil de manejar.

  • Un grupo de almacenamiento por copia de base de datos: un grupo de almacenamiento para cada copia de base de datos garantiza que cada copia esté aislada en un conjunto diferente de ejes en la matriz. Debido a que la mayoría de las organizaciones están implementando entre dos y cuatro copias de bases de datos, la cantidad de grupos finos se mantiene en un número manejable. En este modelo, varios servidores de buzones tienen LUN de base de datos en el mismo grupo fino. Existe la posibilidad de que las actividades de inicialización o reinicialización, copia de seguridad y mantenimiento en línea (mantenimiento de base de datos en segundo plano) en un servidor de buzones puedan afectar el rendimiento de otro servidor de buzones.

*Punto de decisión de diseño*

Si bien los beneficios del modelo de un grupo de almacenamiento por servidor son atrayentes, esto provocaría que hubiera ocho grupos finos en cada sitio o un total de 24. Para que sea más sencillo, se utilizará el modelo de un grupo de almacenamiento por copia de base de datos, lo cual resulta en tres grupos finos en cada sitio y garantiza que cada base de datos esté contenida en un conjunto de ejes único. Esto también garantizará que se mantenga el aislamiento de las copias de las bases de datos durante cualquier caso en el que se deba agregar almacenamiento adicional para satisfacer el crecimiento.

El primer grupo fino contendrá un bloque de creación de 2700 buzones de cada uno de los cuatro servidores de buzones de correo del centro de datos principal en el sitio. En un paso anterior, se determinó que se necesitan diez ejes para admitir los requisitos de IOPS y la capacidad del bloque de creación. El primer grupo fino que admite 10 800 buzones activos requerirá 40 ejes.

El segundo grupo fino contendrá también un bloque de creación de 2700 buzones de cada uno de los cuatro servidores de buzones de correo del centro de datos principal en el sitio. El segundo grupo fino que admite 10 800 buzones activos requerirá 40 ejes.

El tercer grupo fino también contendrá un bloque de creación de 2700 buzones de cada uno de los cuatro servidores de buzones de correo del centro de datos principal en el sitio (los servidores de un DAG alternativo que admiten las copias de bases de datos resistentes de los sitios). El tercer grupo fino que admite 10 800 buzones activos requerirá 40 ejes.

Se necesita un total de 120 ejes por sitio para admitir los requisitos de capacidad inicial de bases de datos.

El primer grupo fino contendrá un bloque de creación de 2700 buzones de cada uno de los cuatro servidores de buzones de correo del centro de datos principal en el sitio. En un paso anterior, se determinó que se necesitan 25 ejes para admitir los requisitos de IOPS y capacidad totalmente aprovisionada del bloque de creación. El primer grupo fino que admite 10 800 buzones activos requerirá 100 ejes.

El segundo grupo fino contendrá también un bloque de creación de 2700 buzones de cada uno de los cuatro servidores de buzones de correo del centro de datos principal en el sitio. El segundo grupo fino que admite 10 800 buzones activos requerirá 100 ejes.

El tercer grupo fino también contendrá un bloque de creación de 2700 buzones de cada uno de los cuatro servidores de buzones de correo del centro de datos principal en el sitio (los servidores de un DAG alternativo que admiten las copias de bases de datos resistentes de los sitios). El tercer grupo fino que admite 10 800 buzones activos requerirá 100 ejes.

Se necesita un total de 300 ejes por sitio para admitir los requisitos de capacidad totalmente aprovisionada de bases de datos.

En un paso anterior, se determinó que cada bloque de creación de 2700 buzones requiere dos ejes para admitir los requisitos de LUN de registro.

Hay dos bloques de creación que admiten bases de datos de buzones activos en los servidores de buzones del centro de datos principal. El LUN de registro que admite 10 800 buzones activos requerirá ocho ejes.

Hay dos bloques de creación que admiten bases de datos de buzones pasivos en los servidores de buzones del centro de datos principal. El LUN de registro que admite 10 800 buzones pasivos requerirá ocho ejes.

Hay dos bloques de creación que admiten bases de datos de buzones pasivos en los servidores de buzones del centro de datos secundario. El LUN de registro que admite 10 800 buzones pasivos requerirá ocho ejes.

Para admitir los requisitos de los LUN de registro en un solo sitio, se necesitan 24 ejes.

En este paso, compruebe que la matriz de almacenamiento pueda admitir la cantidad total de ejes necesarios que eligió usando el siguiente cálculo:

  • Cantidad total de ejes necesarios por sitio = ejes necesarios para LUN de bases de datos + ejes necesarios para LUN de registros

    = 120 + 24

    = 144

Un CX4-480 con receptáculos de matrices de 10 discos tiene 150 ejes y satisface los requisitos.

En este paso, calcule la cantidad total de ejes necesarios para admitir el entorno totalmente aprovisionado usando el siguiente cálculo:

  • Cantidad total de ejes necesarios por sitio = ejes necesarios para LUN de bases de datos + ejes necesarios para LUN de registros

    = 300 + 24

    = 324

Un CX4-480 con receptáculos de matrices de 22 discos tiene 330 ejes y satisface los requisitos.

Soluciones comprobadas de Exchange 2010

En la sección anterior, se proporcionó información acerca de las decisiones de diseño que se realizaron a la hora de considerar la solución Exchange 2010. En la siguiente sección, se proporciona información general de la solución.

Soluciones comprobadas de Exchange 2010

Esta solución consiste en un total de 36 servidores de Exchange 2010 implementados en una tecnología multisitio. Doce de los 36 servidores ejecutan los roles de acceso de cliente y transporte de concentradores. Los otros 24 servidores ejecutan el rol de servidor Buzón de correo. Hay una matriz de servidores de acceso de cliente con cuatro servidores de combinación de acceso de cliente y transporte de concentradores en cada sitio. Hay tres DAG, cada uno con ocho servidores de buzones. Los servidores de archivos en cada sitio alojan a los servidores testigo alternativos de recursos compartidos de archivo de cada DAG.

Diagrama de la solución lógica

por determinar

Soluciones comprobadas de Exchange 2010

Cada uno de los cinco sitios contiene cuatro servidores blade Cisco B200 conectados a una matriz de almacenamiento EMC CLARiiON CX4 modelo 480 mediante conmutadores redundantes Cisco Fabric Interconnect 6120 y Cisco MDS 9134. Los conmutadores redundantes Ethernet Cisco Nexus 5010 proporcionan la infraestructura de red subyacente. El tráfico de clientes tiene equilibrio de carga en la matriz de servidores de acceso de clientes en cada sitio mediante dispositivos de equilibrio de cargas redundantes Cisco ACE 4710.

Diagrama de solución física

por determinar

Soluciones comprobadas de Exchange 2010

En la siguiente tabla, se resume el hardware de servidor físico utilizado en esta solución.

Resumen de Cisco Unified Computing System

Elemento Descripción

Servidor blade

4 × B200 M1

Procesadores

2 × Intel Zeon x5570 (2,93 GHz)

Memoria

96 GB de RAM (12 × 8 GB DIMM)

Adaptador de red convergente

M71KR-Q (2 × Ethernet de 10 gigabit y 2 × Fibre Channel de 4 GB/S)

Almacenamiento interno blade

2 x disco SAS de 146 GB a 10.000 RPM (RAID 1)

Chasis

5108 (6RU)

Extensor de tejido

2 × 2104XP

Interconexión de tejido

2 × 6120XP

Módulo de expansión de interconexión de tejido

2 × 8 puertos de Fibre Channel de 4 Gbps

En la siguiente tabla, se resume el hardware de almacenamiento y redes utilizado en esta solución.

Conmutadores LAN y SAN

Elemento Descripción

Conmutador Ethernet de 10 gigabit (GbE)

2 × Nexus 5010 (8 puertos fijos de 1 GbE/10 GbE, 12 puertos fijos de 10 GbE, puente de centro de datos)

Conmutador Fibre Channel

2 × MDS 9134 (32 puertos fijos de 4 Gbps)

En la siguiente tabla, se proporciona información acerca del software que se utiliza en esta solución.

Resumen de software de la solución

Elemento Descripción

Servidores host de hipervisor

Windows Server 2008 R2 Enterprise de Hyper-V

Máquinas virtuales de Exchange Server

Windows Server 2008 R2 Enterprise

Rol de servidor Buzón de correo de Exchange Server 2010

Enterprise Edition RU2

Rol de servidor acceso de cliente y transporte de concentradores de Exchange Server 2010

Standard Edition RU2

Balance de E/S y varias rutas

EMC PowerPath

Soluciones comprobadas de Exchange 2010

En la siguiente tabla, se resume la configuración de servidores de combinación de acceso de cliente y transporte de concentradores que utiliza esta solución.

Configuración de servidores de acceso de cliente y transporte de concentradores

Componente Valor o descripción

Físicos o virtuales

Máquina virtual Hyper-V

Procesadores virtuales

3

Memoria

8 GB

Almacenamiento

Disco rígido virtual en volumen de sistema operativo de servidor raíz

Sistema operativo

Windows Server 2008 R2

Versión de Exchange

Exchange Server 2010 Standard Edition

Nivel de actualización de Exchange

Paquete acumulativo de actualizaciones 2 de Exchange 2010

Software de terceros

Ninguno

Soluciones comprobadas de Exchange 2010

En la siguiente tabla, se resume la configuración del servidor principal de buzones (que aloja las copias principales y secundarias de las bases de datos en el sitio principal del DAG) que utiliza esta situación.

Configuración de servidor de buzones principal

Componente Valor o descripción

Físicos o virtuales

Máquina virtual Hyper-V

Procesadores virtuales

4

Memoria

53 GB

Almacenamiento

Disco rígido virtual en volumen de sistema operativo de servidor raíz

   

Sistema operativo

Windows Server 2008 R2

Versión de Exchange

Exchange Server 2010 Enterprise Edition

Nivel de actualización de Exchange

Paquete acumulativo de actualizaciones 2 de Exchange 2010

Software de terceros

Ninguno

En la siguiente tabla, se resume la configuración del servidor secundario de buzones (que aloja las copias terciarias de las bases de datos en el sitio secundario del DAG) que utiliza esta situación.

Configuración de servidor de buzones secundario

Componente Valor o descripción

Físicos o virtuales

Máquina virtual Hyper-V

Procesadores virtuales

2

Memoria

24 GB

Almacenamiento

Disco rígido virtual en volumen de sistema operativo de servidor raíz

Sistema operativo

Windows Server 2008 R2

Versión de Exchange

Exchange Server 2010 Enterprise Edition

Nivel de actualización de Exchange

Paquete acumulativo de actualizaciones 2 de Exchange 2010

Software de terceros

Ninguno

Soluciones comprobadas de Exchange 2010

En los siguientes diagramas, se resume el diseño de copia de bases de datos que se utiliza en esta solución durante condiciones normales de funcionamiento.

Diseño de copia de base de datos: 1

por determinar

Diseño de copia de base de datos: 2

por determinar

Diseño de copia de base de datos: 3

por determinar

Soluciones comprobadas de Exchange 2010

En la siguiente tabla, se proporciona información acerca del hardware de almacenamiento que se utiliza en esta solución.

Almacenamiento unificado NS-480 de EMC (CLARiiON CX4-480 integrado)

Elemento Descripción

Almacenamiento

3 CLARiiON CX4-480 (1 por sitio)

Conectividad de almacenamiento (Fibre Channel, SAS, SATA, iSCSI)

Canal de fibra

Caché de almacenamiento

32 GB (600 MB de memoria caché de lectura y 10 160 MB caché de escritura por puerto de almacenamiento)

Cantidad de controladores de almacenamiento

Dos por gabinete de almacenamiento

Cantidad de puertos de almacenamiento disponibles o usados

Ocho (cuatro por puerto de almacenamiento) disponibles por gabinete de almacenamiento, cuatro usados (dos por puerto de almacenamiento)

Ancho de banda máximo de conectividad de almacenamiento al host

8 × 4 Gbps

Cantidad total de discos probados en la solución

432 (360 para bases de datos y 72 para registros en tres sitios)

Cantidad máxima de ejes que pueden alojarse en el almacenamiento

480 en una sola matriz de discos

Soluciones comprobadas de Exchange 2010

Cada una de las matrices de almacenamiento CX4 modelo 480 que se utiliza en esta solución se configuró como se ilustra en la siguiente tabla.

Configuración de almacenamiento

Componente Valor o descripción

Cantidad total de receptáculos de almacenamiento

3

Cantidad total de receptáculos de almacenamiento por sitio

1

Cantidad total de discos por receptáculo

150

Cantidad total de grupos de almacenamiento por receptáculo

3

Cantidad total de discos por grupo de almacenamiento (inicial)

40

Cantidad total de discos por LUN de base de datos (inicial)

10

Cantidad de total de discos por LUN de registro

2

Cantidad total de discos utilizados por receptáculo

144

Tamaño de LUN para base de datos (inicial)

4.020 GB

Tamaño de LUN para registros

402 GB

Nivel de RAID para bases de datos

5

Nivel de RAID para registros

1/0

En la siguiente tabla, se ilustra cómo se diseñó y se asignó el almacenamiento disponible entre los tres sistemas de almacenamiento CX4 modelo 480.

Configuración de almacenamiento entre sistemas de almacenamiento CX4 modelo 480

Centro de datos DAG base de datos Matriz1 Matriz2 Matriz3

1

1

DB1-24

C1, C2

C3

2

2

DB25-48

C3

C1, C2

3

3

DB49-72

C3

C1, C2

Soluciones comprobadas de Exchange 2010

Antes de implementar una solución Exchange en un entorno de producción, compruebe que la solución se haya diseñado, se haya medido y se haya configurado apropiadamente. Esta comprobación debe incluir pruebas funcionales para garantizar que el sistema funcione adecuadamente y pruebas de rendimiento para garantizar que el sistema puede manipular la carga adecuada. En esta sección, se describe el enfoque y la metodología de prueba que se utiliza para validar el diseño de servidores y almacenamientos de esta solución. En particular, se definirán en detalle las siguientes pruebas:

  • Pruebas de rendimiento

    • Validación de rendimiento de almacenamiento (Jetstress)

    • Validación de rendimiento de servidores (Loadgen)

  • Pruebas funcionales

    • Validación de cambio de base de datos

    • Validación del cambio de servidor

    • Validación de conmutación por error del servidor

    • Validación del cambio de centro de datos

Soluciones comprobadas de Exchange 2010

El nivel de rendimiento y confiabilidad del subsistema de almacenamiento conectado con el rol de servidor Buzón de correo de Exchange tiene gran impacto en el buen funcionamiento general de la implementación Exchange. Además, el bajo rendimiento del almacenamiento causará gran latencia de transacción, que se refleja principalmente en una experiencia pobre del cliente cuando obtiene acceso al sistema Exchange. Para garantizar la mejor experiencia de cliente posible, compruebe el tamaño de almacenamiento y la configuración mediante el método descripto en esta sección.

Para validar el tamaño del almacenamiento y la configuración de Exchange, le recomendamos la herramienta Jetstress de Microsoft Exchange Server. La herramienta Jetstress está diseñada para simular una carga de trabajo de E/S de Exchange a nivel de la base de datos mediante la interacción directa con el ESE, también conocido como Jet. ESE es una tecnología de base de datos que usa Exchange para almacenar datos de mensajes en un rol de servidor Buzón de correo. Jetstress puede configurarse para evaluar el rendimiento máximo de E/S disponible en el subsistema del almacenamiento dentro de las restricciones de rendimiento obligatorias de Exchange. O puede aceptar un perfil de destino de cantidad de usuarios y de IOPS por usuario y validar que el subsistema del almacenamiento sea capaz de mantener un nivel aceptable de rendimiento con dicho perfil. La duración de la prueba puede ajustarse y ejecutarse durante un período mínimo para validar el rendimiento adecuado o por un período extenso para validar, además, la confiabilidad del subsistema de almacenamiento.

La herramienta Jetstress puede obtenerse en el Centro de descarga de Microsoft, en las siguientes ubicaciones:

En la documentación que se incluye con el instalador de Jetstress, se describe cómo configurar y ejecutar una prueba de validación de Jetstress en su hardware de servidores.

Existen dos tipos principales de configuraciones de almacenamiento:

  • DAS o escenarios de disco interno

  • Escenarios de SAN

Con DAS o escenarios de disco interno, únicamente un servidor obtiene acceso al subsistema de disco. Por lo tanto, las capacidades de rendimiento del subsistema de almacenamiento pueden validarse de forma aislada.

En los escenarios SAN, varios servidores pueden compartir el almacenamiento que utiliza la solución, y la infraestructura que conecta los servidores al almacenamiento también puede ser una dependencia compartida. Esto requiere pruebas adicionales, ya que el impacto de otros servidores en la infraestructura compartida debe simularse correctamente para validar el rendimiento y la funcionalidad.

Los siguientes casos de prueba de validación de almacenamiento se ejecutaron en la solución y deben considerarse como un punto de partida para la validación de almacenamiento. Es posible que las implementaciones específicas tengan otros requisitos de validación que se puedan cumplir con pruebas adicionales. Por lo tanto, esta lista no es exhaustiva:

  • Validación del peor escenario de cambio de base de datos:en este caso de prueba, se espera que, en el peor escenario de cambio, el subsistema de almacenamiento proporcione servicio al nivel de E/S. Según el tipo de subsistema de almacenamiento (DAS o SAN), es posible que sea necesario ejecutar esta prueba en varios hosts para garantizar que se puede sustentar la carga de la solución de un extremo a otro en el subsistema de almacenamiento.

  • Validación del rendimiento del almacenamiento en un escenario de fallo y recuperación de almacenamiento (por ejemplo, reemplazo y regeneración de un disco fallado):en este caso de prueba, se evalúa el rendimiento del subsistema de almacenamiento durante un escenario de fallo o regeneración para garantizar que se mantenga el nivel de rendimiento necesario para una experiencia óptima de cliente de Exchange. La misma advertencia se aplica para una implementación DAS o SAN: Si varios hosts dependen de un subsistema de almacenamiento compartido, la prueba debe incluir cargas de estos hosts para simular el efecto completo de la falla y la reconstrucción.

La herramienta Jetstress produce un archivo de informe después de que se completa cada prueba. Para ayudarlo a analizar el informe, utilice las instrucciones en Jetstress 2010 Test Summary Reports.

Específicamente, debe usar las instrucciones de la siguiente tabla cuando examine los datos de la tabla Resultados de pruebas del informe.

Análisis de resultados de Jetstress

Instancia de contador de rendimiento Instrucciones para la prueba de rendimiento

Latencia promedio de lecturas de base de datos de E/S (ms)

El valor promedio debe ser menor que 20 milisegundos (ms) (0,020 s) y los valores máximos deben ser menores que 50 ms.

Latencia promedio de escrituras de registros de E/S (ms)

Las escrituras de discos de registros son secuenciales. Por lo tanto, las latencias promedio de escritura deben ser menores que 10 ms, con un máximo menor que 50 ms.

% de tiempo de procesador

El promedio debe ser menor que el 80% y el máximo debe ser menor que el 90%.

Páginas de transición redirigidas/s (Windows Server 2003, Windows Server 2008, Windows Server 2008 R2)

El promedio debe ser menor que 100.

El archivo de informe muestra varias categorías de E/S realizadas por el sistema Exchange:

  • Rendimiento de E/S transaccional:esta tabla informa E/S que representa la actividad del usuario con la base de datos (por ejemplo, E/S generadas por Outlook). Estos datos se generan sustrayendo E/S en segundo plano de mantenimiento y E/S de replicación de registros del total de E/S medidas durante la prueba. Estos datos proporcionan las IOPS de base de datos reales junto con las mediciones de latencia de E/S necesarias para determinar si una prueba de rendimiento de Jetstress se aprueba o se desaprueba.

  • Rendimiento de E/S de mantenimiento de base de datos en segundo plano:esta tabla informa las E/S generadas por un mantenimiento de base de datos en segundo plano de ESE en ejecución.

  • Rendimiento de E/S de replicación de registro:esta tabla informa las E/S generadas en una replicación de registro simulada.

  • Rendimiento total de E/S:esta tabla informa el total de E/S generada durante la prueba Jetstress.

Soluciones comprobadas de Exchange 2010

Después de validar el rendimiento y la confiabilidad del subsistema de almacenamiento, asegúrese de que todos los componentes del sistema de mensajería se validen en forma conjunta en relación con la funcionalidad, el rendimiento y la escalabilidad. Esto significa realizar un movimiento ascendente en la pila para validar la interacción del software de cliente con el producto de Exchange, así como cualquier producto del servidor que interaccione con Exchange. Para garantizar que la experiencia del cliente de extremo a extremo sea aceptable y que la solución completa pueda admitir la carga del usuario deseada, el método descripto en esta sección puede aplicarse para la validación del diseño del servidor.

Para realizar la validación de la escalabilidad y el rendimiento de la solución de extremo a extremo, recomendamos la herramienta Microsoft Exchange Server Load Generator (Loadgen). La herramienta Loadgen está diseñada para producir una carga de trabajo de cliente simulada en una implementación Exchange. Esta carga de trabajo puede usarse para evaluar el rendimiento del sistema Exchange y para evaluar el efecto de diversos cambios de configuración en la solución general durante la carga del sistema. LoadGen puede simular actividad de cliente de Microsoft Office Outlook 2007 (en línea y en caché), Office Outlook 2003 (en línea y en caché), POP3, IMAP4, SMTP, ActiveSync y Outlook Web App (conocido en Exchange 2007 y versiones anteriores, como Outlook Web Access). Puede usarse para generar una carga de trabajo de protocolo único o estos protocolos de cliente pueden combinarse para generar una carga de trabajo de varios protocolos.

Puede obtener la herramienta Loadgen desde el Centro de descargas de Microsoft en una de las siguientes ubicaciones:

En la documentación incluida con el instalador de LoadGen, se describe cómo configurar y ejecutar una prueba de Loadgen en una implementación de Exchange.

Al validar el diseño de su servidor, pruebe el escenario del peor caso bajo una carga de trabajo máxima anticipada. En base a un número de conjuntos de datos de Microsoft IT y otros clientes, la carga máxima generalmente es igual al doble de la carga de trabajo promedio en todo el resto del día de trabajo. Esto se conoce como la relación entre la carga de trabajo máxima a promedio.

Monitor de rendimiento

Captura de pantalla del monitor de rendimiento

En esta instantánea del Monitor de rendimiento, que muestra varios contadores que representan la cantidad de trabajo de Exchange que se realiza con el paso del tiempo en un servidor de buzones de producción, el valor promedio de las operaciones RPC por segundo (la línea resaltada) es de aproximadamente 2386 en el cálculo del día completo. El promedio de este contador durante el período de máxima actividad de 10:00 a 11:00 es de aproximadamente 4.971, con una relación entre el período máximo y el promedio de 2,08.

Para garantizar que la solución de Exchange sea capaz de admitir la carga de trabajo generada durante el promedio máximo, modifique la configuración de Loadgen para generar una cantidad de carga constante en el nivel de promedio máximo en lugar de distribuir la carga de trabajo en el día de trabajo simulado completo. Los módulos de simulación basados en la tarea de Loadgen (como los módulos de simulación de Outlook) usan un perfil que define la cantidad de veces que se realizará cada tarea para un usuario promedio dentro de un día simulado.

El número total de tareas que deben ejecutarse durante un día simulado se calcula como el número de usuarios multiplicado por la suma del número de tareas en el perfil de tareas configurado. A continuación, Loadgen determina la velocidad a la cual deberían ejecutarse las tareas para el conjunto configurado de usuarios al dividir el número total de tareas para ejecutar en el día simulado por la longitud del día simulado. Por ejemplo, si Loadgen debe ejecutar 1.000.000 de tareas en un día simulado y un día simulado es igual a 8 horas (28 800 segundos), Loadgen debe ejecutar 1 000 000 ÷ 28 800 = 34,72 tareas por segundo para cumplir con la definición de carga de trabajo requerida. Para aumentar la cantidad de carga al promedio máximo deseado, divida la longitud simulada predeterminada (8 horas) por la relación entre el período máximo y el promedio (2) y use esto como la nueva longitud del día simulado.

Vuelva a utilizar el ejemplo de velocidad de las tareas, 1 000 000 ÷ 14 400 = 69,44 tareas por segundo. Esto reduce la longitud del día simulado a la mitad, lo que causa una duplicación de la ejecución real de la carga de trabajo en el servidor y cumple con nuestro objetivo de carga de trabajo promedio máxima. No se ajusta la duración de la longitud de ejecución de la prueba en la configuración de Loadgen. La duración de la longitud de la ejecución especifica la duración de la prueba y no afecta la velocidad a la cual las tareas se ejecutarán en el servidor de Exchange.

Los siguientes casos de prueba de validación de diseño del servidor se ejecutaron en la solución y deberían considerarse como punto de partida para la validación de diseño del servidor. Es posible que las implementaciones específicas tengan otros requisitos de validación que se puedan cumplir con pruebas adicionales. Por lo tanto, esta lista no es exhaustiva:

  • Condiciones normales de funcionamiento:en este caso de prueba, el diseño básico de la solución se valida con todos los componentes en su estado de funcionamiento normal (sin errores simulados). La carga de trabajo simulada se genera en la solución y el rendimiento general de la solución se valida en comparación con las métricas siguientes.

  • Error de servidor único o mantenimiento de servidor único (en el sitio): en este caso de prueba, un servidor único se desactiva para simular una operación de mantenimiento planificada del servidor o un error inesperado del servidor. La carga de trabajo que habitualmente se maneja mediante el servidor no disponible ahora se maneja mediante otros servidores en la topología de la solución y se valida el rendimiento general de la solución.

Los datos del rendimiento de Exchange tienen cierta variación natural dentro de las ejecuciones de prueba y entre las ejecuciones de prueba. Recomendamos que tome el promedio de varias ejecuciones para simplificar esta variación. Para las soluciones comprobadas de Exchange, se completó un mínimo de tres ejecuciones de pruebas independientes con duraciones de ocho horas. Se recopilaron los datos de rendimiento durante la duración completa de ocho horas de la prueba. Los datos de resumen de rendimiento se tomaron de un período estable de tres a cuatro horas (sin incluir las primeras dos horas y la última hora de la prueba). Para cada rol de servidor de Exchange, se promediaron los datos de resumen del rendimiento entre los servidores de cada ejecución de prueba y se obtuvo un valor de promedio único para cada punto de datos. Luego, los valores de cada ejecución se promediaron y se obtuvo un punto de datos único para todos los servidores de un rol de servidor semejante entre todas las ejecuciones de prueba.

Antes de observar cualquier contador de rendimiento o iniciar el análisis de validación de su rendimiento, compruebe que la carga de trabajo que esperaba ejecutar haya coincidido con la carga de trabajo que ejecutó realmente. Si bien existen varias formas de determinar si la carga de trabajo coincidía con la carga de trabajo esperada, la forma más sencilla y coherente de hacerlo es observar la velocidad de entrega de mensajes.

Cada perfil de mensajes incluye la suma del número promedio de mensajes enviados por día y el número promedio de mensajes recibidos por día. Para calcular la tasa de entrega de mensajes, seleccione el número promedio de mensajes recibidos por día de la tabla siguiente.

Tasa máxima de entrega de mensajes

Perfil de mensajes Mensajes enviados por día Mensajes recibidos por día

50

10

40

100

20

80

150

30

120

200

40

160

El siguiente ejemplo asume que cada servidor de buzones tiene 5000 buzones activos con un perfil de 150 mensajes por día (30 mensajes enviados y 120 mensajes recibidos por día).

Tasa máxima de entrega de mensajes de 5000 buzones activos

Descripción Cálculo Valor

Perfil de mensajes

Número de mensajes recibidos por día

120

Número de buzones activos por servidor de buzones

No aplicable

5000

Total de mensajes recibidos por día por servidor de buzones

5000 × 120

600000

Total de mensajes recibidos por segundo por servidor de buzones

600000 ÷ 28800

20.83

Total de mensajes ajustados a la carga máxima

20.83 × 2

41.67

Se espera la entrega de 41,67 mensajes por segundo en cada servidor de buzones que ejecuta 5000 buzones activos con un perfil de 150 mensajes por día durante la carga máxima.

Puede medir la tasa real de entrega de mensajes mediante el siguiente contador en cada servidor de buzones: MSExchangeIS Mailbox(_Total)\Mensajes entregados/s. Si la tasa de entrega de mensajes medida está dentro de uno o dos mensajes por segundo en relación con la tasa de entrega de mensajes objetivo, puede confiar en que el perfil de carga deseado se ejecutó adecuadamente.

En esta sección, se describen los contadores del Monitor de rendimiento y los umbrales usados para determinar si el tamaño del entorno de Exchange se especificó adecuadamente y si éste puede ejecutarse en un estado seguro durante períodos prolongados de carga de trabajo máxima. Para obtener más información acerca de los contadores apropiados para el rendimiento de Exchange, consulte Contadores y umbrales de rendimiento y escalabilidad.

Para validar los criterios de estado y rendimiento de un servidor raíz de Hyper-V y las aplicaciones que se ejecutan dentro de las máquinas virtuales, debe contar con conocimientos básicos de la arquitectura de Hyper-V y la forma en que esto impacta en la supervisión del rendimiento.

Hyper-V tiene tres componentes principales: la pila de virtualización, el hipervisor y los dispositivos. La pila de virtualización controla dispositivos emulados y las máquinas virtuales y brinda servicios de E/S. El hipervisor programa procesadores virtuales, administra las interrupciones, brinda servicios a los temporizadores y controla otras funciones de chip. El hipervisor no controla dispositivos ni E/S (por ejemplo, no hay controladores de hipervisor). Los dispositivos forman parte del servidor raíz o están instalados en servidores invitados como parte de los servicios de integración. Dado que el servidor raíz posee una vista completa del sistema y controla las máquinas virtuales, este también ofrece información de la supervisión mediante el Instrumental de administración de Windows (WMI) y los contadores de rendimiento.

Procesador

Al validar la utilización del procesador físico en el servidor raíz (o dentro de la máquina virtual invitada), el contador Procesador\% tiempo de procesador no es muy útil.

En su lugar, puede examinar el contador Procesador lógico del hipervisor Hyper-V\% de tiempo de ejecución total. Este contador muestra el porcentaje del tiempo empleado por el procesador en el tiempo de ejecución del hipervisor y de invitado y debería usarse para medir la utilización total del procesador por parte del hipervisor y todas las máquinas virtuales que se ejecutan en el servidor raíz. Este contador no debería exceder el 80% o cualquier objetivo de uso máximo para el que se haya diseñado.

 

Contador Destino

Procesador lógico del hipervisor Hyper-V\% de tiempo de ejecución total

<80%

Si le interesa conocer el porcentaje de tiempo del procesador dedicado al servicio de las máquinas virtuales invitadas, puede examinar el contador Procesador lógico del hipervisor Hyper-V\% de tiempo de ejecución del invitado. Si le interesa conocer el porcentaje de tiempo del procesador empleado en el hipervisor, puede observar el contador Procesador lógico del hipervisor Hyper-V\% de tiempo de ejecución del hipervisor. Este contador debe estar por debajo del 5%. El contador Procesador virtual raíz del hipervisor de Hyper-V\% de tiempo de ejecución del invitado muestra el porcentaje de tiempo que el procesador emplea en la pila de virtualización. Este contador también debe estar por debajo del 5%. Estos dos contadores pueden usarse para determinar el porcentaje de tiempo del procesador físico disponible utilizado para admitir la virtualización.

 

Contador Destino

Procesador lógico del hipervisor Hyper-V\% de tiempo de ejecución del invitado

<80%

Procesador lógico del hipervisor Hyper-V\% de tiempo de ejecución del hipervisor

<5%

Procesador virtual raíz del hipervisor de Hyper-V\% de tiempo de ejecución del invitado

<5%

Memoria

Debe asegurarse de que su servidor raíz Hyper-V disponga de memoria suficiente para admitir la memoria asignada a las máquinas virtuales. Hyper-V reserva automáticamente 512 MB (esto puede variar según las diferentes versiones de Hyper-V) para el sistema operativo raíz. Si no tiene memoria suficiente, Hyper-V impedirá el inicio de la última máquina virtual. En general, no debe preocuparse por validar la memoria en un servidor raíz Hyper-V. Preocúpese más por asegurar que haya suficiente memoria asignada a las máquinas virtuales para admitir los roles de Exchange.

Estado de la aplicación

Una forma sencilla de determinar si todas las máquinas virtuales presentan un estado normal es observar los contadores de Resumen de mantenimiento de máquinas virtuales de Hyper-V.

 

Contador Destino

Resumen de mantenimiento de máquinas virtuales de Hyper-V \Mantenimiento correcto

1

Resumen de mantenimiento de máquinas virtuales de Hyper-V \Mantenimiento crítico

0

Servidores de buzones de correo

Al validar si un servidor de buzones se dimensionó correctamente, concéntrese en el procesador, la memoria, el almacenamiento y el estado de la aplicación de Exchange. En esta sección, se describe el método de validación de cada uno de estos componentes.

Procesador

Durante el proceso de diseño, se calculó la capacidad de megaciclos ajustada de la plataforma del procesador o servidor. A continuación, se determinó el número máximo de buzones activos que el servidor podría admitir sin superar el 80% de la capacidad de megaciclos disponible. También determinó cuál debería ser el uso de CPU proyectado durante condiciones normales de funcionamiento y durante varios escenarios de error o mantenimiento del servidor.

Durante el proceso de validación, compruebe que el escenario del peor caso de carga de trabajo no supere el 80% de los megaciclos disponibles. Asimismo, compruebe que el uso real de la CPU se encuentre cerca del uso de CPU esperado durante condiciones normales de funcionamiento y durante varios escenarios de error o mantenimiento del servidor.

Para estas implementaciones de Exchange, use el contador Procesador(_Total)\% de tiempo de procesador y compruebe que dicho contador sea inferior al 80% en promedio.

 

Contador Destino

Processor(_Total)\% de tiempo de procesador

<80%

Para las implementaciones virtuales de Exchange, el contador Procesador(_Total)\% de tiempo de procesador se mide dentro de la máquina virtual. En este caso, el contador no mide el uso de la CPU física. Está midiendo la utilización de la CPU virtual proporcionada por el hipervisor. Por lo tanto, no ofrece una lectura precisa del procesador físico y no debería usarse para la validación de diseño. Para obtener más información, consulte Hyper-V: Los relojes mienten. ¿En qué contadores de rendimiento puede confiar?.

Para la validación de implementaciones de Exchange que ejecutan Microsoft Hyper-V, use el contador Procesador virtual del hipervisor de Hyper-V\% de tiempo de ejecución del invitado. Esto ofrece un valor más preciso de la cantidad de CPU física en uso por parte del sistema operativo invitado. Este contador debe ser inferior al 80% en promedio.

 

Contador Destino

Procesador virtual del hipervisor Hyper-V\% de tiempo de ejecución del invitado

<80%

Memoria

Durante el proceso de diseño, calculó el tamaño de caché de base de datos necesaria para admitir la cantidad máxima de bases de datos activas en cada servidor de buzones. Luego, determinó la configuración óptima de memoria física para cumplir con los requisitos de memoria del sistema y la memoria caché de la base de datos.

Validar si un servidor de buzones de Exchange tiene suficiente memoria para admitir una carga de trabajo de destino no es una tarea simple. El uso de contadores de memoria disponible para ver la cantidad de memoria física restante no es útil, ya que el administrador de memoria en Exchange está diseñado para usar prácticamente la totalidad de la memoria física disponible. El almacén de información (store.exe) reserva una gran parte de la memoria física para la caché de base de datos. La caché de base de datos se utiliza para almacenar páginas de base de datos en memoria. Cuando se obtiene acceso a una página en la memoria, no es necesario recuperar la información desde el disco ni reducir la E/S de lectura. La caché de base de datos se usa también para optimizar la E/S de escritura.

Cuando se modifica una página de la base de datos (conocida como página sucia), la página permanece en la caché durante un período. Cuanto más tiempo permanece en la caché, más probabilidades tiene la página de modificarse varias veces antes de que los cambios se escriban en el disco. El mantenimiento de páginas sucias en la caché también provoca la escritura de varias páginas en el disco en la misma operación (conocido como fusión de escritura). Exchange usa la mayor cantidad posible de la memoria disponible en el sistema, que es el motivo por el cual no hay grandes cantidades de memoria disponible en un servidor de buzones de Exchange.

Puede no ser sencillo saber si la configuración de la memoria en su servidor de buzones de Exchange es demasiado pequeña. Por lo general, el servidor de buzones aún funcionará, pero su perfil de E/S puede ser mucho mayor de lo esperado. Una mayor E/S puede ofrecer mayores latencias de escritura y escritura del disco, lo que puede ejercer un impacto en la experiencia de usuario del cliente y el estado de la aplicación. En la sección resultados, no hay ninguna referencia a los contadores de memoria. Los posibles problemas de memoria se identificarán en las secciones de resultados del estado de la aplicación y validación de almacenamiento, donde se detectan con mayor facilidad los problemas de memoria.

Almacenamiento

Si tiene problemas de rendimiento con su servidor de buzones de Exchange, es posible que estos estén relacionados con el almacenamiento. Los problemas de almacenamiento pueden estar causados por un número insuficiente de discos para cumplir con los requisitos de E/S, una infraestructura de conectividad de almacenamiento sobrecargada o con diseño deficiente o factores que cambian el perfil de E/S objetivo, p. ej., memoria insuficiente, como se analizó anteriormente.

El primer paso en la validación del almacenamiento es comprobar que las latencias de bases de datos estén por debajo de los umbrales de destino. En las versiones anteriores, los contadores de disco lógico determinaban la latencia de lectura y escritura del disco. En Exchange 2010, es probable que el servidor de buzones de Exchange que supervisa tenga una mezcla de copias activas y pasivas de base de datos de buzones. Las características de E/S de las copias activas y pasivas de la base de datos son diferentes. Dado que el tamaño de E/S es mucho mayor en las copias pasivas, habitualmente hay latencias mucho mayores en las copias pasivas. Los objetivos de latencia para las bases de datos pasivas son de 200 ms, que es 10 veces mayor que los destinos en las copias de base de datos activas. Esto no es de gran preocupación, ya que las latencias altas en bases de datos pasivas no tienen impacto en la experiencia del cliente. Sin embargo, si está usando los contadores de discos lógicos tradicionales para medir latencias, debe revisar los volúmenes individuales y separar los volúmenes con bases de datos activas y pasivas. En su lugar, recomendamos que use los nuevos contadores de base de datos de MSExchange en Exchange 2010.

Al validar latencias en los servidores de buzones de Exchange 2010, recomendamos el uso de contadores en la siguiente tabla para las bases de datos activas.

 

Contador Destino

Base de datos de MSExchange\Latencia promedio de lecturas (adjuntas) de base de datos de E/S

<20 ms

Base de datos de MSExchange\Latencia promedio de escrituras (adjuntas) en base de datos de E/S

<20 ms

Base de datos de MSExchange\Latencia promedio de escrituras en registro de E/S

<1 ms

Recomendamos el uso de contadores en la siguiente tabla para las bases de datos pasivas

 

Contador Destino

Base de datos de MSExchange\Latencia promedio de lecturas (recuperación) de base de datos de E/S

<200 ms

Base de datos de MSExchange\Latencia promedio de escrituras (recuperación) de base de datos de E/S

<200 ms

Base de datos de MSExchange\Latencia promedio de lectura en registro de E/S

<200 ms

NotaNOTA:
Para ver estos contadores en el Monitor de rendimiento, debe habilitar los contadores de bases de datos avanzados. Para obtener más información, consulte Cómo habilitar contadores de rendimiento de ESE extendidos.

Al validar latencias de discos en las implementaciones de Exchange en ejecución en Microsoft Hyper-V, tenga en cuenta que los contadores de latencia promedio de base de datos de E/S (al igual que con varios contadores basados en tiempo) pueden no ser precisos, ya que el concepto de tiempo dentro de la máquina virtual es diferente de aquel del servidor físico. El siguiente ejemplo muestra la latencia promedio de lecturas de la base de datos de E/S (adjunto) de 22,8 en la máquina virtual y 17,3 en un servidor físico para la misma carga de trabajo simulada. Si los valores de los contadores basados en tiempo están por encima de los umbrales objetivo, el servidor puede estar ejecutándose correctamente. Consulte todos los criterios del estado para tomar una decisión en relación con el estado del servidor cuando se implementa el rol de servidor Buzón de correo dentro de una máquina virtual.

Valores de los contadores de latencia de disco para servidores de buzones virtuales y físicos

Contador Servidor de buzones virtual Servidor de buzones físico

Base de datos de MSExchange/

Lecturas de la base de datos de E/S (adjunto)/Latencia promedio

22.792

17.250

Lecturas de la base de datos de E/S (adjunto)/s

17.693

18.131

Lecturas de la base de datos de E/S (recuperación)/Latencia promedio

34.215

27.758

Escrituras de la base de datos de E/S (recuperación)/s

10.829

  8.483

Escrituras de la base de datos de E/S (adjunto)/Latencia promedio

  0.944

  0.411

Escrituras de la base de datos de E/S (adjunto)/s

10.184

10.963

MSExchangeIS

   

Promedio de latencia de RPC

   1.966

   1.695

Operaciones RPC/seg.

334.371

341.139

Paquetes RPC/s

180.656

183.360

MSExchangeIS Mailbox

Mensajes entregados/s

2.062

2.065

Mensajes enviados/s

0.511

0.514

Además de las latencias de disco, consulte el contador de Base de datos/Paradas de error de páginas de base de datos/s. Este contador indica la tasa de errores de página que no pueden atenderse porque no existen páginas disponibles para asignar desde la memoria caché de la base de datos. Este contador debe ser de 0 en los servidores en buen estado.

 

Contador Destino

Base de datos\Paradas de error de páginas de base de datos/seg

<1

Asimismo, consulte el contador Base de datos\Detenciones de escritura en registro/s, que indica el número de escrituras en registro que no pueden agregarse a los búferes de registro por segundo porque estos están llenos. El promedio de este contador debe ser menor que 10.

 

Contador Destino

Base de datos\Paradas de escritura en registro/seg.

<10

Estado de aplicaciones de Exchange

Aún si no se presentan problemas evidentes con el procesador, la memoria y el disco, recomendamos que supervise los contadores estándar de estado de la aplicación para garantizar que el servidor de buzones de Exchange esté en buen estado.

El contador MSExchangeIS\Promedio de latencia de RPC ofrece la mejor indicación de si otros contadores con latencias de bases de datos altas realmente están impactando en la experiencia del cliente y el estado de Exchange. Con frecuencia, los promedios de latencia alta de RPC se asocian con un alto número de solicitudes de RPC, que deben ser inferiores a 70 permanentemente.

 

Contador Destino

MSExchangeIS\Promedio de latencia de RPC

<10 ms en promedio

MSExchangeIS\Solicitudes de RPC

<70 en todo momento

A continuación, asegúrese de que la capa de transporte esté en buen estado. Cualquier problema con el transporte o problemas indirectos del transporte que afectan la capa de transporte pueden detectarse con el contador MSExchangeIS Mailbox(_Total)\Mensajes en cola para envío. Este contador debe estar por debajo de 50 en todo momento. Puede haber aumentos temporales en este contador, pero el valor del contador no debería aumentar con el tiempo y no debería mantenerse por más de 15 minutos.

 

Contador Destino

MSExchangeIS Mailbox(_Total)\Mensajes en cola para envío

<50 en todo momento

A continuación, asegúrese de que el mantenimiento de las copias de las bases de datos esté en buen estado. Cualquier problema con el transporte o la reproducción de registros puede identificarse con los contadores MSExchange Replication(*)\Longitud de cola de copia y MSExchange Replication(*)\Longitud de cola de reproducción. La longitud de cola de copia muestra el número de archivos del registro de transacciones que están en espera para copiarse en la carpeta de archivos de registro de copia pasiva y debería ser menor que 1 permanentemente. La longitud de cola de reproducción muestra el número de archivos del registro de transacciones que están en espera para reproducirse en la copia pasiva y debería ser menor que 5. Los valores mayores no impactan en la experiencia del usuario pero causan tiempos de montaje de almacenamiento más largos al realizarse un relevo, una conmutación por error o una activación.

 

Contador Destino

MSExchange Replication(*)\Longitud de cola de copia

<1

MSExchange Replication(*)\Longitud de cola de reproducción

<5

Servidores de acceso de cliente

Para determinar si un servidor de acceso de cliente funciona correctamente, revise el procesador, la memoria y el estado de la aplicación. Para obtener una lista ampliada de contadores importantes, consulte Contadores de servidor de acceso de cliente.

Procesador

Para implementaciones físicas de Exchange, utilice el contador Procesador(_Total)\% de tiempo de procesador. Este contador debe ser inferior al 80% en promedio.

 

Contador Destino

Processor(_Total)\% de tiempo de procesador

<80%

Para la validación de implementaciones de Exchange que ejecutan Microsoft Hyper-V, use el contador Procesador virtual del hipervisor de Hyper-V\% de tiempo de ejecución del invitado. Esto ofrece un valor preciso de la cantidad de CPU física en uso por parte del sistema operativo invitado. Este contador debe ser inferior al 80% en promedio.

 

Contador Destino

Procesador virtual del hipervisor Hyper-V\% de tiempo de ejecución del invitado

<80%

Estado de la aplicación

Para determinar si la experiencia del cliente MAPI es aceptable, use el contador MSExchange RpcClientAccess\Promedio de latencia de RPC. Este contador debe estar por debajo de 250 ms. Las latencias altas pueden estar asociadas con un gran número de solicitudes de RPC. El contador MSExchange RpcClientAccess\Solicitudes de RPC debe ser inferior a 40 como promedio.

 

Contador Destino

MSExchange RpcClientAccess\Promedio de latencia de RPC

<250 ms

MSExchange RpcClientAccess\Solicitudes de RPC

<40

Servidores de transporte

Para determinar si un servidor de transporte funciona correctamente, revise el procesador, el disco y el estado de la aplicación. Para obtener una lista ampliada de contadores importantes, consulte Contadores de servidor de transporte.

Procesador

Para implementaciones físicas de Exchange, utilice el contador Procesador(_Total)\% de tiempo de procesador. Este contador debe ser inferior al 80% en promedio.

 

Contador Destino

Processor(_Total)\% de tiempo de procesador

<80%

Para la validación de implementaciones de Exchange que ejecutan Microsoft Hyper-V, use el contador Procesador virtual del hipervisor de Hyper-V\% de tiempo de ejecución del invitado. Esto ofrece un valor preciso de la cantidad de CPU física en uso por parte del sistema operativo invitado. Este contador debe ser inferior al 80% en promedio.

 

Contador Destino

Procesador virtual del hipervisor Hyper-V\% de tiempo de ejecución del invitado

<80%

Disco

Para determinar si el rendimiento del disco es aceptable, utilice el Disco lógico(*)\Promedio. Contadores de lectura y escritura de discos/s para los volúmenes que contienen registros de transporte y base de datos. Los dos contadores anteriores deben ser inferiores a 20 ms.

 

Contador Destino

Disco lógico(*)\Promedio. de segundos de disco/lectura

<20 ms

Disco lógico(*)\Promedio. de segundos de disco/Escritura

<20 ms

Estado de la aplicación

Para determinar si un servidor de transporte de concentradores se ha dimensionado correctamente y se ejecuta de forma correcta, examine los contadores Colas de transporte de MSExchange delineados en la siguiente tabla. Todas estas colas tendrán mensajes en diferentes ocasiones. Desea garantizar que la longitud de la cola no se mantenga ni crezca durante un período. Si se presentan longitudes de cola mayores, esto podría indicar un servidor de transporte de concentradores sobrecargado. O bien, quizás haya problemas de red o un servidor de buzones sobrecargado que no puede recibir mensajes. Deberá verificar otros componentes del entorno de Exchange para comprobarlo.

 

Contador Destino

Colas de MSExchangeTransport(_total)\Entrega agregada

<3000

Colas de MSExchangeTransport(_total)\Longitud de la cola de entrega remota activa

<250

Colas de MSExchangeTransport(_total)\Longitud de la cola de entrega del buzón activo

<250

Colas de MSExchangeTransport(_total)\Reintentar longitud de la cola de entrega del buzón

<100

Colas de MSExchangeTransport(_total)\Longitud de la cola de envío

<100

Soluciones comprobadas de Exchange 2010

Puede usar la información de las siguientes secciones para las pruebas de validación funcionales.

Soluciones comprobadas de Exchange 2010

Un cambio de base de datos es el proceso por el cual una base de datos activa individual se pasa a otra copia de la base de datos (una copia pasiva), y dicha copia de la base de datos se convierte en la nueva copia activa de la base de datos. Los cambios de base de datos pueden ocurrir tanto dentro de los centros de datos como entre ellos. Un cambio de base de datos puede realizarse usando la Consola de administración de Exchange (EMC) o el Shell de administración de Exchange.

Para validar que una copia pasiva de una base de datos pueda activarse correctamente en otro servidor, ejecute el siguiente comando.

Move-ActiveMailboxDatabase <DatabaseName> -ActivateOnServer <TargetServer>

Criterios de éxito: La base de datos del buzón activo está montada en el servidor de destino especificado. Este resultado puede confirmarse mediante la ejecución del siguiente comando.

Get-MailboxDatabaseCopyStatus <DatabaseName>

Soluciones comprobadas de Exchange 2010

Un cambio de servidor es el proceso por el cual todas las bases de datos activas en un miembro del DAG se activan en uno o más miembros del DAG. Al igual que los cambios de base de datos, un cambio de servidor puede ocurrir tanto dentro de un centro de datos como entre centros de datos, y puede ser iniciado mediante el uso de la EMC y el Shell.

  • Para validar que todas las copias pasivas de las bases de datos en un servidor puedan activarse correctamente en otros servidores que alojan una copia pasiva, ejecute el siguiente comando.

    Get-MailboxDatabase -Server <ActiveMailboxServer> | Move-ActiveMailboxDatabase -ActivateOnServer <TargetServer>
    

    Criterios de éxito: Las bases de datos activas de buzones se montan en el servidor de destino especificado. Esto puede confirmarse ejecutando el siguiente comando.

    Get-MailboxDatabaseCopyStatus <DatabaseName>
    
  • Para validar que una copia de cada una de las bases de datos activas pueda activarse correctamente en otro servidor de buzones que aloja copias pasivas de las bases de datos, cierre el servidor realizando la siguiente acción.

    Apague el servidor activo actual.

    Criterios de éxito: Las bases de datos activas de buzones se montan en el servidor de buzones en el DAG. Esto puede confirmarse ejecutando el siguiente comando.

    Get-MailboxDatabaseCopyStatus <DatabaseName>
    

Soluciones comprobadas de Exchange 2010

Una conmutación por error de servidor sucede cuando el miembro del DAG ya no puede reparar la red MAPI o cuando el servicio de clúster en un miembro del DAG ya no puede ponerse en contacto con los miembros del DAG restantes.

Para validar que una copia de cada una de las bases de datos activas pueda activarse correctamente en otro servidor de buzones que aloja copias pasivas de las bases de datos, apague el servidor realizando una de las siguientes acciones:

  • Mantenga presionado el botón de encendido en el servidor hasta que éste se apague.

  • Extraiga los cables de alimentación del servidor para apagar el servidor.

Criterios de éxito: Las bases de datos activas de buzones se montan en el servidor de buzones en el DAG. Esto puede confirmarse ejecutando el siguiente comando.

Get-MailboxDatabase -Server <MailboxServer> | Get-MailboxDatabaseCopyStatus

Soluciones comprobadas de Exchange 2010

Un error en el sitio o el centro de datos se administra de manera diferente de los tipos de errores que pueden provocar la conmutación por error de un servidor o una base de datos. En una configuración de alta disponibilidad, la recuperación automática es iniciada por el sistema, y el error, por lo general, deja el sistema de mensajería en un estado completamente funcional. Por otro lado, un error en el centro de datos se considera un evento de recuperación ante desastres y, como tal, la recuperación debe realizarse y completarse de forma manual para que el servicio de cliente se restaure y para que la interrupción finalice. El proceso que realiza se denomina cambio de centro de datos. Como sucede con muchas situaciones de recuperación ante desastres, la planificación y la preparación anticipadas de un cambio de centro de datos pueden simplificar el proceso de recuperación y reducir la duración de la interrupción.

Para obtener más información, además de instrucciones detalladas sobre cómo realizar un cambio de centro de datos, consulte Cambios en el centro de datos.

Existen cuatro pasos básicos que es necesario completar para realizar un cambio de centro de datos, tras tomar la decisión inicial de activar el segundo centro de datos:

  1. Terminar un centro de datos parcialmente en ejecución (con error).

  2. Validar y confirmar los requisitos previos para el segundo centro de datos.

  3. Activar los servidores de buzones.

  4. Activar los servidores de acceso de cliente.

En las siguientes secciones, se describen los pasos que se utilizan para validar un cambio de centro de datos.

Cuando el DAG esté en modo DAC, las acciones específicas para finalizar cualquier miembro DAG todavía activo en el centro de datos principal dependen del estado del centro de datos con error. Realice una de las siguientes opciones:

  • Si aún puede obtener acceso a los servidores de buzones del centro de datos con error (generalmente este no es el caso), ejecute el siguiente comando en cada servidor de buzones.

    Stop-DatabaseAvailabilityGroup -ActiveDirectorySite <insertsitename>
    
  • Si los servidores de buzones en el centro de datos con error no están disponibles pero Active Directory está en funcionamiento en el centro de datos principal, ejecute el siguiente comando en un controlador de dominio.

    Stop-DatabaseAvailabilityGroup -ActiveDirectorySite <insertsitename> -ConfigurationOnly
    
NotaNOTA:
Si no se pueden apagar los servidores de buzones en el centro de datos con error o no se puede ejecutar correctamente el comando Stop-DatabaseAvailabilityGroup en los servidores, es posible que se genere el síndrome de cerebro dividido entre los dos centros de datos. Para cumplir este requisito, es posible que deba apagar cada equipo por medio de dispositivos de administración de energía.

Criterios de éxito: Todos los servidores de buzones en el sitio con error se encuentran en un estado detenido. Puede comprobar esto ejecutando el siguiente comando en un servidor del centro de datos con error.

Get-DatabaseAvailabilityGroup | Format-List

Se debe actualizar el segundo centro de datos para que representen los servidores detenidos del centro de datos principal. Desde un servidor en el centro de datos secundario, ejecute el siguiente comando.

Stop-DatabaseAvailabilityGroup -ActiveDirectorySite <insertsitename> -ConfigurationOnly

La finalidad de este paso es informar a los servidores del segundo centro de datos sobre los servidores de buzones de correo que se pueden usar al restaurar el servicio.

Criterios de éxito: Todos los servidores de buzones de correo en el centro de datos que falló están en un estado detenido. Para comprobarlo, ejecute el siguiente comando desde un servidor del centro de datos secundario.

Get-DatabaseAvailabilityGroup | Format-List

Antes de activar los miembros DAG en el segundo centro de datos, recomendamos que compruebe que los servicios de infraestructura del segundo centro de datos estén listos para la activación del servicio de mensajería.

Cuando el DAG está en modo DAC, los pasos para completar la activación de los servidores de buzones de correo en el segundo centro de datos son los siguientes:

  1. Detenga el servicio de clúster en cada miembro de DAG del centro de datos secundario. Puede usar el comando cmdlet Stop-Service para detener el servicio (por ejemplo, Stop-Service ClusSvc), o net stop clussvc desde la ventana de símbolo de sistema.

  2. Para activar los servidores de buzones en el centro de datos secundario, ejecute el siguiente comando.

    Restore-DatabaseAvailabilityGroup -Identity <DAGname> -ActiveDirectorySite <insertsitename>
    

    Si este comando se ejecuta correctamente, los criterios de quórum se reducen a los servidores del centro de datos secundario. Si el número de servidores de ese centro de datos es par, el DAG pasará a usar el servidor testigo alternativo, según se identificó en la configuración del objeto DAG.

  3. Para activar las bases de datos, ejecute uno de los siguientes comandos.

    Get-MailboxDatabase <insertcriteriatoselectDBs> | Move-ActiveMailboxDatabase -ActivateOnServer <DAGMemberinPrimarySite>
    

    o

    Move-ActiveMailboxDatabase -Server <DAGMemberInSecondarySite> -ActivateOnServer <DAGMemberinPrimarySite>
    
  4. Compruebe los registros de eventos y revise todos los mensajes de error y las advertencias para asegurarse de que el sitio secundario esté en buenas condiciones. Debe hacer un seguimiento y corregir cualquier problema que se indique antes de montar las bases de datos.

  5. Para montar las bases de datos, ejecute el siguiente comando.

    Get-MailboxDatabase <DAGMemberInSecondarySite> | Mount-Database
    

Criterios de éxito: Las bases de datos de buzones activos se instalan en los servidores de buzones del sitio secundario. Para confirmar, ejecute el siguiente comando.

Get-MailboxDatabaseCopyStatus <DatabaseName>

Los clientes se conectan a extremos del servicio para obtener acceso a los servicios y los datos de Exchange. Por lo tanto, activar los servidores de acceso de cliente orientados a Internet implica modificar los registros DNS para que apunten a las nuevas direcciones IP que se configurarán para los nuevos extremos de servicio. Luego, los clientes se podrán conectar automáticamente a los nuevos extremos de servicio de dos maneras:

  • Los clientes seguirán intentando establecer la conexión y deberían conectarse automáticamente una vez que haya expirado el TTL para la entrada DNS original y la entrada de la memoria caché DNS del cliente. También pueden ejecutar el comando ipconfig /flushdns desde una ventana de símbolo de sistema para borrar manualmente la memoria caché DNS. Si usa Outlook Web App, es posible que deba cerrar y reiniciar el explorador Web para borrar la memoria caché DNS que usa el explorador. En Exchange 2010 SP1, puede solucionar este problema de la memoria caché del explorador mediante la configuración del parámetro FailbackURL del directorio virtual owa de Outlook Web App.

  • Los clientes que se inicien o reinicien realizarán una búsqueda DNS en el inicio y obtendrán la nueva dirección IP para el extremo de servicio, que será una matriz o un servidor de acceso de cliente en el segundo centro de datos.

Para validar el escenario con Loadgen, realice las siguientes acciones:

  1. Modifique la entrada DNS de la matriz de servidores de acceso de cliente para que apunte a la dirección IP virtual del equilibrio de carga de hardware en el sitio secundario.

  2. Ejecute el comando ipconfig /flushdns en todos los servidores Loadgen.

  3. Reinicie la prueba de Loadgen.

  4. Compruebe que los servidores de acceso de cliente en el sitio secundario estén realizando servicio a la carga.

Para validar el escenario con un cliente de Outlook 2007, realice las siguientes acciones:

  1. Modifique la entrada DNS de la matriz de servidores de acceso de cliente para que apunte a la dirección IP virtual del equilibrio de carga de hardware en el sitio secundario.

  2. Ejecute el comando ipconfig /flushdns en el cliente o espere a que expire el TTL.

  3. Espere a que el cliente de Outlook vuelva a conectarse.

Soluciones comprobadas de Exchange 2010

El proceso que consiste en restaurar el servicio en un centro de datos dañado se denomina conmutación por recuperación. Los pasos para realizar una conmutación por recuperación de un centro de datos son similares a los que se usan para realizar el cambio de un centro de datos. Una diferencia importante es que la conmutación por recuperación de un centro de datos se programa y que la duración de la interrupción suele ser mucho más breve.

Es importante que la conmutación por recuperación no se efectúe hasta que las dependencias de la infraestructura de Exchange se hayan reactivado y validado, y estén estables y en funcionamiento. Si estas dependencias no están disponibles o no son correctas, es probable que el proceso de conmutación por recuperación provoque una interrupción más prolongada que la necesaria o que el proceso falle por completo.

El rol de servidor Buzón de correo debe ser el primer rol en el que se efectúe la conmutación por recuperación al centro de datos principal. En los siguientes pasos, se detalla el proceso de conmutación por recuperación del rol de servidor Buzón de correo (suponiendo que DAG está en modo de DAC).

  1. Para reincorporar a los miembros de DAG en el sitio principal, ejecute el siguiente comando.

    Start-DatabaseAvailabilityGroup -Identity <DatabaseAvailabilityGroupIdParameter> -ActiveDirectorySite <insertsitename>
    
  2. Para comprobar el estado de las copias de la base de datos del centro de datos principal, ejecute el siguiente comando.

    Get-MailboxDatabaseCopyStatus
    

Una vez que se incorporaron los servidores de buzones de correo del centro de datos principal en el DAG, necesitarán tiempo para sincronizar las copias de bases de datos. Según la naturaleza del error, la duración de la interrupción y las acciones realizadas por un administrador durante la interrupción, es posible que se deban repropagar las copias de bases de datos. Por ejemplo, si durante la interrupción, quita las copias de bases de datos del centro de datos principal dañado para permitir el truncamiento del archivo de registro en las copias aún activas del segundo centro de datos, será necesaria la repropagación. En este momento, cada base de datos se puede sincronizar individualmente. Una vez que una copia de base de datos replicada del centro de datos principal tiene un estado normal, puede continuar con el siguiente paso.

  1. Durante el proceso de cambio del centro de datos, se configuró el DAG para que use un servidor testigo alternativo. Para volver a configurar el DAG para usar un servidor testigo en la base de datos del centro de datos principal, ejecute el siguiente comando.

    Set-DatabaseAvailabilityGroup -Identity <DAGName> -WitnessServer <PrimaryDatacenterWitnessServer>
    
  2. Las bases de datos que se reactivarán en el centro de datos principal deben desmontarse en el centro de datos secundario. Ejecute el siguiente comando.

    Get-MailboxDatabase | Dismount-Database
    
  3. Una vez desmontadas las bases de datos, los URL de los servidores de acceso de clientes deben migrarse del centro de daros secundario al principal. Para esto, cambie el registro de DNS de los URL para apuntar al servidor o la matriz de acceso de clientes del centro de datos principal.

    ImportanteImportante:
    No continúe con el siguiente paso hasta que se hayan movido las direcciones URL del servidor de acceso de cliente y hayan expirado el TTL y las entradas de la memoria caché DNS. Si se activan las bases de datos en el centro de datos principal antes de migrar las direcciones URL del servidor de acceso de cliente al centro de datos principal, se generará una configuración no válida (por ejemplo, una base de datos montada que no tiene servidores de acceso de cliente en su sitio de Active Directory).
  4. Para activar las bases de datos, ejecute uno de los siguientes comandos.

    Get-MailboxDatabase <insertcriteriatoselectDBs> | Move-ActiveMailboxDatabase -ActivateOnServer <DAGMemberinSecondSite>
    

    o

    Move-ActiveMailboxDatabase -Server <DAGMemberinPrimarySite> -ActivateOnServer <DAGMemberinSecondSite>
    
  5. Para montar las bases de datos, ejecute el siguiente comando.

    Get-MailboxDatabase <insertcriteriatoselectDBs> | Mount-Database
    

Criterios de éxito: Las bases de datos de buzones activos se instalan correctamente en los servidores de buzones del sitio principal. Para confirmar, ejecute el siguiente comando.

Get-MailboxDatabaseCopyStatus <DatabaseName>

Soluciones comprobadas de Exchange 2010

Las pruebas se realizaron en Microsoft Enterprise Engineering Center, que es un laboratorio de última generación para la validación de soluciones empresariales que se encuentra en el campus principal de Microsoft en Redmond, Washington.

Con más de 125 millones de dólares en hardware y con asociaciones sólidas con fabricantes de equipos originales (OEM) líderes en el sector, es posible replicar prácticamente cualquier entorno en el EEC. El EEC ofrece un entorno que permite una colaboración extensiva entre clientes, socios e ingenieros de productos Microsoft. Esto ayuda a garantizar que las soluciones integrales de Microsoft cumplen con las exigentes expectativas de los clientes.

Soluciones comprobadas de Exchange 2010

En la siguiente sección, se resumen los resultados de las pruebas de validación de rendimiento y funcionamiento.

Soluciones comprobadas de Exchange 2010

En la siguiente tabla, se resumen los resultados de las pruebas de validación del funcionamiento.

Resultados de la validación de funcionamiento

Caso de prueba Resultado Comments

Cambio de conexión de base de datos

Exitoso

Se completó sin errores

Cambio de servidor

Exitoso

Se completó sin errores

Error de servidor

Exitoso

Se completó sin errores

Falla en el sitio

Exitoso

Se completó sin errores

Soluciones comprobadas de Exchange 2010

Las pruebas de todos los discos por sitio en un solo gabinete de almacenamiento muestran que el CX4-480 maneja más de 8000 IOPS transaccionales de Exchange 2010 en ocho máquinas virtuales de Exchange configuradas con el perfil de usuario de 150 mensajes a 0,15 IOPS y un margen de espacio del 20%. El rendimiento excedió la línea base de 5832 IOPS necesarias para esta configuración y proporcionó un margen de espacio adicional para picos de carga. Todas las latencias de disco estuvieron dentro de los parámetros aceptables de acuerdo con las prácticas recomendadas de Microsoft para el rendimiento de Exchange 2010.

Resultados de la validación del diseño de almacenamiento

E/S de bases de datos Valores de destino 4 servidores de buzones en condiciones normales de funcionamiento (2700 usuarios por servidor de buzones) 4 servidores de buzones en una condición de transición (5400 usuarios por servidor de buzones) Total

IOPS transaccionales logrados (lecturas/s de base de datos de E/S + escrituras/s de base de datos de E/S)

1944 / 3888

IOPS 3576

IOPS 4488

IOPS 8064

Lecturas/s de base de datos de E/S

No aplicable

2193

2729

4922

Escrituras/s de base de datos de E/S

No aplicable

1439

1703

3142

Latencia promedio de lecturas de base de datos de E/S (ms)

<20 ms

14

18

16

Latencia promedio de escrituras de base de datos de E/S (ms)

No es un buen indicador de la latencia de cliente porque las escrituras de la base de datos son asincrónicas

14

18

16

   

Escrituras/s de registro de E/S

No aplicable

1238

1560

2798

Latencia promedio de lecturas de registro de E/S (ms)

<10 ms

2

2

2

Soluciones comprobadas de Exchange 2010

En las siguientes secciones, se resumen los resultados de la validación del diseño de servidores para los casos de prueba.

Validación de Loadgen: escenarios de prueba

Prueba Descripción

Funcionamiento normal

Se simuló una coincidencia de carga del 100% para 10 800 usuarios en un sitio, con 2700 usuarios en cada servidor de buzones.

Error de servidor único o mantenimiento de servidor único (en sitio)

Se simuló la falla de un único servidor de host de Hyper-V por sitio. Se ejecutó una coincidencia de carga del 100% en un solo host Hyper-V con una máquina virtual con 5400 usuarios. Solo tres servidores combinados de acceso de clientes y transporte de concentradores manejaron la carga.

Falla en el sitio

Se simuló una falla en el sitio y se activaron imágenes secundarias en máquinas virtuales de servidores de buzones en espera. Se ejecutó una coincidencia de carga del 100% en 21 600 usuarios en un solo sitio.

Este caso de prueba representa el mayor volumen de trabajo en condiciones normales de funcionamiento. Las condiciones normales de funcionamiento hacen referencia a un estado en el que todas las bases de datos activas y pasivas residen en servidores en los que está planificado que se ejecuten. Debido a que este caso de prueba no representa el peor caso de carga de trabajo, no es la prueba de validación de rendimiento clave. Proporciona una buena referencia de cómo debería funcionar este entorno fuera de una falla de servidores o de un mantenimiento. En esta prueba, el objetivo es validar todo el entorno de Exchange en condiciones normales de funcionamiento con picos de carga. Todas las máquinas virtuales de Exchange operaban en condiciones normales. Loadgen se configuró para simular el pico de carga. Se espera que el perfil de acción de 150 mensajes que se está ejecutando en modo máximo genere el doble de mensajes enviados y entregados por segundo.

La tasa de entrega de mensajes comprueba que la carga de trabajo probada coincida con la carga de trabajo de destino. La tasa de entrega de mensajes es un poco mayor que el objetivo, lo cual provoca una carga un poco mayor que el perfil deseado.

 

Contador Destino Resultados comprobados

Tasa de entrega de mensajes por buzón de correo

15.0

15.2

En las siguientes tablas, se muestran los resultados de la validación de las máquinas virtuales de servidores principales de buzones.

Procesador

La utilización del procesador es inferior al 70%, como se esperaba.

 

Contador Destino Resultados comprobados

Procesador virtual del hipervisor Hyper-V\% de tiempo de ejecución del invitado

<70%

69

Almacenamiento

Los resultados de almacenamiento son buenos. Todas las latencias están debajo de los valores de destino.

 

Contador Destino Resultados comprobados

Base de datos de MSExchange\Latencia promedio de lecturas (adjuntas) de base de datos de E/S

<20 ms

19

Base de datos de MSExchange\Latencia promedio de escrituras (adjuntas) en base de datos de E/S

<20 ms

<Promedio de lecturas

18

Base de datos\Paradas de error de páginas de base de datos/seg

0

0

Base de datos de MSExchange\Latencia promedio de escrituras en registro de E/S

<20 ms

5

Base de datos\Paradas de escritura en registro/seg.

0

0

Estado de la aplicación

El estado de Exchange es correcto y todos los contadores que se utilizan para determinar el estado de la aplicación están por debajo de los valores de destino.

 

Contador Destino Resultados comprobados

MSExchangeIS\Solicitudes de RPC

<70

3.0

MSExchangeIS\Promedio de latencia de RPC

<10 ms

2.0

MSExchangeIS Mailbox(_Total)\Mensajes en cola para envío

0

2.0

En las siguientes tablas, se muestran los resultados de la validación de las máquinas virtuales de servidores secundarios de buzones.

Procesador

La utilización del procesador es inferior al 70%, como se esperaba.

 

Contador Destino Resultados comprobados

Procesador virtual del hipervisor Hyper-V\% de tiempo de ejecución del invitado

<70%

26

Almacenamiento

Los resultados de almacenamiento son buenos. Todas las latencias están debajo de los valores de destino.

 

Contador Destino Resultados comprobados

Base de datos de MSExchange\Latencia promedio de lecturas (recuperación) de base de datos de E/S

<100 ms

0

Base de datos de MSExchange\Latencia promedio de escrituras (recuperación) de base de datos de E/S

<100 ms

<Promedio de lecturas

16

Base de datos\Paradas de error de páginas de base de datos/seg

0

0

Base de datos de MSExchange\Latencia promedio de escrituras en registro de E/S

<20 ms

3

Base de datos\Paradas de escritura en registro/seg.

0

0

Estado de la aplicación

Los servidores secundarios de buzones están manteniendo solamente las copias de bases de datos pasivas terciarias. Por lo tanto, los indicadores de estado estándar de la aplicación Exchange no se aplican a este escenario.

 

Contador Destino Resultados comprobados

MSExchangeIS\Solicitudes de RPC

<70

No aplicable

MSExchangeIS\Promedio de latencia de RPC

<10 ms

No aplicable

MSExchangeIS Mailbox(_Total)\Mensajes en cola para envío

0

No aplicable

En las siguientes tablas, se muestran los resultados de la validación de las máquinas virtuales de servidores de acceso de cliente y transporte de concentradores.

Procesador

La utilización del procesador es baja, como se esperaba.

 

Contador Destino Resultados comprobados

Procesador virtual del hipervisor Hyper-V\% de tiempo de ejecución del invitado

<70%

48

Almacenamiento

Los resultados de almacenamiento son correctos. Las latencias muy bajas no deben afectar el transporte de mensajes.

 

Contador Destino Resultados comprobados

Logical/Physical Disk(*)\Avg. de segundos de disco/lectura

<20 ms

0.001

Logical/Physical Disk(*)\Avg. de segundos de disco/Escritura

<20 ms

0.005

Estado de la aplicación

Los valores de latencia promedio de RPC confirman que los servidores de acceso de cliente están en buen estado y no afectan la experiencia del cliente.

 

Contador Destino Resultados comprobados

MSExchange RpcClientAccess\Promedio de latencia de RPC

<250 ms

8

MSExchange RpcClientAccess\Solicitudes de RPC

<40

3

Todos los contadores de colas de transporte están por debajo del valor de destino, lo cual confirma que los servidores de transporte de concentradores están en buen estado y pueden procesar y entregar los mensajes requeridos.

 

Contador Destino Resultados comprobados

\Colas de MSExchangeTransport(_total)\Longitud de la cola de entrega agregada (todas las colas)

<3000

2.5

\Colas de MSExchangeTransport(_total)\Longitud de la cola de entrega remota activa

<250

0

\Colas de MSExchangeTransport(_total)\Longitud de la cola de entrega del buzón activo

<250

2.3

\Colas de MSExchangeTransport(_total)\Longitud de la cola de envío

<100

0

\Colas de MSExchangeTransport(_total)\Reintentar longitud de la cola de entrega del buzón

<100

0.3

En las siguientes tablas, se muestran los resultados de la validación del servidor raíz Hyper-V.

Procesador

Como se esperaba, la utilización de los procesadores es muy baja y están muy por debajo de los umbrales de destino.

 

Contador Destino Resultados comprobados

Procesador lógico del hipervisor Hyper-V(_total)\% de tiempo de ejecución del invitado

<75%

66

Procesador lógico del hipervisor Hyper-V(_total)\% de tiempo de ejecución del hipervisor

<5%

2

Procesador lógico del hipervisor Hyper-V(_total)\% de tiempo de ejecución total

<80%

68

Procesador virtual raíz del hipervisor de Hyper-V(_total)\% de tiempo de ejecución del invitado

<5%

3

Estado de la aplicación

Los contadores de resumen del estado de las máquinas virtuales indican que todas las máquinas virtuales están en buen estado.

 

Contador Destino Resultados comprobados

Resumen de mantenimiento de máquinas virtuales de Hyper-V \Mantenimiento crítico

0

0

En esta prueba, el objetivo es validar todo el entorno de Exchange en condiciones de error físico de servidor raíz de Hyper-V o de mantenimiento con carga máxima. Todas las máquinas virtuales que se estaban ejecutando en uno de los servidores raíz de Hyper-V en el sitio se apagaron para simular una condición de mantenimiento de host. Esto provocó que las imágenes (copias) de base de datos migraran a otra máquina virtual de servidores de buzones, lo cual creó una condición de funcionamiento de 5400 usuarios por máquina virtual de servidores de buzones. Solamente la mitad de los servidores combinados de acceso de clientes y transporte de concentradores procesaron los accesos de clientes y las entregas de correo.

La tasa real de entrega de mensajes se mantuvo dentro del valor de destino.

 

Contador Destino Resultados comprobados

Tasa de entrega de mensajes por servidor

30

30

En las siguientes tablas, se muestran los resultados de la validación de las máquinas virtuales de servidores principales de buzones.

Procesador

La utilización del procesador es un poco mayor que el valor de destino. Este caso de prueba representa un escenario de falla o mantenimiento con carga máxima, por lo que sería un evento de baja incidencia. No es deseable una utilización tan alta del procesador por un período prolongado.

 

Contador Destino Resultados comprobados

Procesador virtual del hipervisor Hyper-V\% de tiempo de ejecución del invitado

<80%

83

Almacenamiento

Los resultados de almacenamiento son aceptables. La latencia promedio de lectura es un poco mayor que el valor de destino. La latencia promedio de escritura de base de datos es superior que la deseada. Esto se produce en el peor escenario de fallo con carga máxima, que es un evento de baja incidencia. Las latencias altas no superan los valores de destino de los contadores del estado de la aplicación, por lo que la experiencia de usuario debe ser aceptable aún. No es deseable que las latencias sean tan altas por un período prolongado.

 

Contador Destino Resultados comprobados

Base de datos de MSExchange\Latencia promedio de lecturas (adjuntas) de base de datos de E/S

<20 ms

20.5

Base de datos de MSExchange\Latencia promedio de escrituras (adjuntas) en base de datos de E/S

<20 ms

23

Base de datos\Paradas de error de páginas de base de datos/seg

0

0

Base de datos de MSExchange\Latencia promedio de escrituras en registro de E/S

<20 ms

8

Base de datos\Paradas de escritura en registro/seg.

0

0

Estado de la aplicación

Los contadores muestran que Exchange sigue estando razonablemente en buen estado. Se están produciendo algunas colas de mensajes durante cargas máximas. No es deseable que esta situación continúe por un período prolongado.

 

Contador Destino Resultados comprobados

MSExchangeIS\Solicitudes de RPC

<70

9.0

MSExchangeIS\Promedio de latencia de RPC

<10 ms

2.0

MSExchangeIS Mailbox(_Total)\Mensajes en cola para envío

0

77

En las siguientes tablas, se muestran los resultados de la validación de las máquinas virtuales de servidores secundarios de buzones.

Procesador

La utilización del procesador es inferior al 70%, como se esperaba.

 

Contador Destino Resultados comprobados

Procesador virtual del hipervisor Hyper-V\% de tiempo de ejecución del invitado

<70%

21

Almacenamiento

Los resultados de almacenamiento son buenos. Todas las latencias están debajo de los valores de destino.

 

Contador Destino Resultados comprobados

Base de datos de MSExchange\Latencia promedio de lecturas (recuperación) de base de datos de E/S

<100 ms

0

Base de datos de MSExchange\Latencia promedio de escrituras (recuperación) de base de datos de E/S

<100 ms

<Promedio de lecturas

21

Base de datos\Paradas de error de páginas de base de datos/seg

0

0

Base de datos de MSExchange\Latencia promedio de escrituras en registro de E/S

<20 ms

3

Base de datos\Paradas de escritura en registro/seg.

0

0

Estado de la aplicación

Los servidores secundarios de buzones están manteniendo solamente las copias de bases de datos pasivas terciarias. Por lo tanto, los indicadores de estado estándar de la aplicación Exchange no se aplican a este escenario.

 

Contador Destino Resultados comprobados

MSExchangeIS\Solicitudes de RPC

<70

No aplicable

MSExchangeIS\Promedio de latencia de RPC

<10 ms

No aplicable

MSExchangeIS Mailbox(_Total)\Mensajes en cola para envío

0

No aplicable

En las siguientes tablas, se muestran los resultados de la validación de las máquinas virtuales de servidores de acceso de cliente y transporte de concentradores.

Procesador

La utilización del procesador es inferior al 80%, como se esperaba.

 

Contador Destino Resultados comprobados

Procesador virtual del hipervisor Hyper-V\% de tiempo de ejecución del invitado

<80%

74

Almacenamiento

Los resultados de almacenamiento son correctos. Las latencias muy bajas no deben afectar el transporte de mensajes.

 

Contador Destino Resultados comprobados

Logical/Physical Disk(*)\Avg. de segundos de disco/lectura

<20 ms

0.001

Logical/Physical Disk(*)\Avg. de segundos de disco/Escritura

<20 ms

0.008

Estado de la aplicación

Los valores de latencia promedio de RPC confirman que los servidores de acceso de cliente están en buen estado y no afectan la experiencia del cliente.

 

Contador Destino Resultados comprobados

MSExchange RpcClientAccess\Promedio de latencia de RPC

<250 ms

18

MSExchange RpcClientAccess\Solicitudes de RPC

<40

14

Todos los contadores de colas de transporte están por debajo del valor de destino, lo cual confirma que los servidores de transporte de concentradores están en buen estado y pueden procesar y entregar los mensajes requeridos.

 

Contador Destino Resultados comprobados

\Colas de MSExchangeTransport(_total)\Longitud de la cola de entrega agregada (todas las colas)

<3000

49

\Colas de MSExchangeTransport(_total)\Longitud de la cola de entrega remota activa

<250

0

\Colas de MSExchangeTransport(_total)\Longitud de la cola de entrega del buzón activo

<250

43

\Colas de MSExchangeTransport(_total)\Longitud de la cola de envío

<100

53

\Colas de MSExchangeTransport(_total)\Reintentar longitud de la cola de entrega del buzón

<100

4

En las siguientes tablas, se muestran los resultados de la validación del servidor raíz Hyper-V.

Procesador

La utilización del procesador está cerca del umbral de destino, lo cual es previsible en el escenario de error o mantenimiento en condiciones de carga máxima.

 

Contador Destino Resultados comprobados

Procesador lógico del hipervisor Hyper-V(_total)\% de tiempo de ejecución del invitado

<75%

77

Procesador lógico del hipervisor Hyper-V(_total)\% de tiempo de ejecución del hipervisor

<5%

2

Procesador lógico del hipervisor Hyper-V(_total)\% de tiempo de ejecución total

<80%

79

Procesador virtual raíz del hipervisor de Hyper-V(_total)\% de tiempo de ejecución del invitado

<5%

3

Estado de la aplicación

Los contadores de resumen del estado de las máquinas virtuales indican que todas las máquinas virtuales están en buen estado.

 

Contador Destino Resultados comprobados

Resumen de mantenimiento de máquinas virtuales de Hyper-V \Mantenimiento crítico

0

0

Este caso de prueba simula un fallo en el sitio mediante el cambio de las bases de datos activas del sitio principal a bases de datos pasivas del sitio secundario, lo cual da como resultado 21 600 buzones activos en un sitio. Las cuatro máquinas virtuales principales de servidores de buzones en el sitio que subsiste funcionan con una carga de trabajo normal de 2700 buzones activos cada una. Las cuatro máquinas virtuales secundarias de servidores de buzones en el sitio que subsiste ahora funcionan con 2700 buzones activos cada una. Cada servidor raíz de Hyper-V aloja 5400 buzones de correo activos.

La tasa de entrega de mensajes es un poco mayor que el objetivo, lo cual provoca una carga un poco mayor que el perfil deseado.

 

Contador Destino Resultados comprobados

Tasa de entrega de mensajes por servidor

15

15.1

En las siguientes tablas, se muestran los resultados de la validación de las máquinas virtuales de servidores principales de buzones.

Procesador

Las máquinas virtuales principales de servidores de buzones funcionan con una carga de trabajo normal y están por debajo del valor de destino de utilización del procesador, como se esperaba.

 

Contador Destino Resultados comprobados

Procesador virtual del hipervisor Hyper-V\% de tiempo de ejecución del invitado

<70%

63

Almacenamiento

Los resultados de almacenamiento son buenos. Todas las latencias están debajo de los valores de destino.

 

Contador Destino Resultados comprobados

Base de datos de MSExchange\Latencia promedio de lecturas (adjuntas) de base de datos de E/S

<20 ms

12

Base de datos de MSExchange\Latencia promedio de escrituras (adjuntas) en base de datos de E/S

<20 ms

13

Base de datos\Paradas de error de páginas de base de datos/seg

0

0

Base de datos de MSExchange\Latencia promedio de escrituras en registro de E/S

<20 ms

4

Base de datos\Paradas de escritura en registro/seg.

0

0

Estado de la aplicación

El estado de Exchange es correcto y todos los contadores que se utilizan para determinar el estado de la aplicación están por debajo de los valores de destino.

 

Contador Destino Resultados comprobados

MSExchangeIS\Solicitudes de RPC

<70

3.0

MSExchangeIS\Promedio de latencia de RPC

<10 ms

2.0

MSExchangeIS Mailbox(_Total)\Mensajes en cola para envío

0

3

En las siguientes tablas, se muestran los resultados de la validación de las máquinas virtuales de servidores secundarios de buzones.

Procesador

La utilización del procesador es un poco mayor que el 80%. Es mayor que lo deseado, pero no parece afectar al resto de los contadores del estado de Exchange. Debido a que esta prueba representa cargas máximas durante un evento de fallo del sitio con baja incidencia, es aceptable. No es deseable una utilización tan alta del procesador por un período prolongado.

 

Contador Destino Resultados comprobados

Procesador virtual del hipervisor Hyper-V\% de tiempo de ejecución del invitado

<80%

84

Almacenamiento

Los resultados de almacenamiento son buenos. Todas las latencias están debajo de los valores de destino.

 

Contador Destino Resultados comprobados

Base de datos de MSExchange\Latencia promedio de lecturas (adjuntas) de base de datos de E/S

<20 ms

17

Base de datos de MSExchange\Latencia promedio de escrituras (adjuntas) en base de datos de E/S

<20 ms

<Promedio de lecturas

12

Base de datos\Paradas de error de páginas de base de datos/seg

0

0

Base de datos de MSExchange\Latencia promedio de escrituras en registro de E/S

<20 ms

3

Base de datos\Paradas de escritura en registro/seg.

0

0

Estado de la aplicación

Los contadores demuestran que Exchange funciona bien. Existe una pequeña cola.

 

Contador Destino Resultados comprobados

MSExchangeIS\Solicitudes de RPC

<70

3

MSExchangeIS\Promedio de latencia de RPC

<10 ms

2

MSExchangeIS Mailbox(_Total)\Mensajes en cola para envío

0

106

En las siguientes tablas, se muestran los resultados de la validación de las máquinas virtuales de servidores de acceso de cliente y transporte de concentradores.

Procesador

La utilización del procesador es inferior al 80%, como se esperaba.

 

Contador Destino Resultados comprobados

Procesador virtual del hipervisor Hyper-V\% de tiempo de ejecución del invitado

<70%

63

Almacenamiento

Los resultados de almacenamiento son correctos. Las latencias muy bajas no deben afectar el transporte de mensajes.

 

Contador Destino Resultados comprobados

Logical/Physical Disk(*)\Avg. de segundos de disco/lectura

<20 ms

0.002

Logical/Physical Disk(*)\Avg. de segundos de disco/Escritura

<20 ms

0.003

Estado de la aplicación

Los valores de latencia promedio de RPC confirman que los servidores de acceso de cliente están en buen estado y no afectan la experiencia del cliente.

 

Contador Destino Resultados comprobados

MSExchange RpcClientAccess\Promedio de latencia de RPC

<250 ms

9

MSExchange RpcClientAccess\Solicitudes de RPC

<40

7

Todos los contadores de colas de transporte están por debajo del valor de destino, lo cual confirma que los servidores de transporte de concentradores están en buen estado y pueden procesar y entregar los mensajes requeridos.

 

Contador Destino Resultados comprobados

\Colas de MSExchangeTransport(_total)\Longitud de la cola de entrega agregada (todas las colas)

<3000

5

\Colas de MSExchangeTransport(_total)\Longitud de la cola de entrega remota activa

<250

0

\Colas de MSExchangeTransport(_total)\Longitud de la cola de entrega del buzón activo

<250

4

\Colas de MSExchangeTransport(_total)\Longitud de la cola de envío

<100

0

\Colas de MSExchangeTransport(_total)\Reintentar longitud de la cola de entrega del buzón

<100

1

En las siguientes tablas, se muestran los resultados de la validación del servidor raíz Hyper-V.

Procesador

La utilización del procesador es mayor que el 80%. Debido a que esta prueba representa cargas máximas durante un evento de fallo del sitio con baja incidencia, es aceptable. No es deseable una utilización tan alta del procesador por un período prolongado.

 

Contador Destino Resultados comprobados

Procesador lógico del hipervisor Hyper-V(_total)\% de tiempo de ejecución del invitado

<75%

85

Procesador lógico del hipervisor Hyper-V(_total)\% de tiempo de ejecución del hipervisor

<5%

2

Procesador lógico del hipervisor Hyper-V(_total)\% de tiempo de ejecución total

<80%

87

Procesador virtual raíz del hipervisor de Hyper-V(_total)\% de tiempo de ejecución del invitado

<5%

3

Estado de la aplicación

Los contadores de resumen del estado de las máquinas virtuales indican que todas las máquinas virtuales están en buen estado.

 

Contador Destino Resultados comprobados

Resumen de mantenimiento de máquinas virtuales de Hyper-V \Mantenimiento crítico

0

0

Soluciones comprobadas de Exchange 2010

En esta nota del producto, se proporciona un ejemplo de cómo diseñar, probar y validar una solución Exchange 2010 para entornos de clientes con 32 400 buzones de correo en varios sitios implementados en hardware Cisco y EMC. La metodología paso por paso de este documento repasa los aspectos importantes para las decisiones de diseño, los cuales ayudan a abordar los desafíos clave y, al mismo tiempo, garantizan el cumplimiento de los requisitos empresariales centrales.

Soluciones comprobadas de Exchange 2010

Para obtener la documentación completa de Exchange 2010, consulte Exchange Server 2010.

Para obtener información adicional relacionada con Cisco y EMC, consulte los siguientes recursos:

Este documento se proporciona tal como está. La información y las vistas contenidas en este documento, incluidas las direcciones URL y las referencias a otros sitios web de Internet, están sujetas a modificaciones sin previo aviso. Usted es responsable de los riegos de su uso.

Este documento no le proporciona derechos legales de propiedad intelectual para ningún producto de Microsoft. Puede copiar y usar este documento para uso interno, con fines de referencia.

Soluciones comprobadas de Exchange 2010

 
¿Te ha resultado útil?
(Caracteres restantes: 1500)
Gracias por sus comentarios
Mostrar:
© 2014 Microsoft