Diseño de almacenamiento del servidor de transporte

 

Se aplica a: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007

Última modificación del tema: 2009-01-26

Los servidores de transporte de concentradores y transporte perimetral son las funciones de servidor que entregan:

• Correo dentro y fuera de la organización.

• Correo dentro y fuera de los servidores de buzones.

• Mensajes de correo de voz enviados mediante servidores de mensajería unificada.

Para asegurar un flujo de correo y reparto eficaces por toda la organización de Exchange, los servidores de transporte de concentradores y de transporte perimetral deberán tener una solución de almacenamiento correctamente diseñada.

En este tema se proporciona información y ejemplos que ayudan a determinar los requisitos de capacidad y de entrada/salida (E/S) para los servidores de transporte de concentradores y de transporte perimetral.

Requisitos de E/S y de capacidad del servidor de transporte perimetral

Los servidores de transporte perimetral deben estar diseñados para que cumplan los requisitos de capacidad y de E/S transaccionales de cada organización. Es muy importante mantener correctamente el crecimiento de la cola y enrutar el correo lo más rápido posible, para que los contratos de licencia de servicios (SLA) no se vean afectados negativamente. Hay varios factores que afectan a la capacidad total de un servidor de transporte perimetral:

• Registros de seguimiento de mensajes

• Registros de protocolo

• Base de datos de buzones

• Registros de conectividad

• Registros de agentes

Debe existir un mínimo de 500 megabytes (MB) de espacio disponible y espacio disponible en la base de datos en la unidad que contiene la base de datos de cola de mensajes, o bien el sistema de transporte activará la presión de reserva, un recurso de sistema que supervisa la característica del servicio de transporte de Microsoft Exchange Server 2007 .

El parámetro PercentageDatabaseDiskSpaceUsedHighThreshold controla el valor predeterminado de la presión de reserva, que se puede modificar si es necesario. Para obtener más información acerca de la presión de reserva y las opciones para configurarla, consulte Descripción de la presión de reserva.

Si los registros de seguimiento de mensajes están habilitados, es necesaria capacidad adicional. Los requisitos de capacidad de seguimiento de mensajes dependen del número de mensajes que recibe el servidor de transporte. Si la organización usa actualmente Microsoft Exchange Server 2003, podrá determinar el nivel actual de generación de registros y establecer un límite estricto de días para conservar los datos, como por ejemplo 10 días. Microsoft genera 220 megabytes (MB) de registros de seguimiento de mensajes cada día laborable (menos durante el fin de semana) y asegura la capacidad suficiente para una semana de registros (1.3 GB, aproximadamente). El tamaño de los registros de agentes, conectividad y protocolo varía según la actividad. Como punto de referencia, los servidores de transporte de producción en Microsoft generan:

• De 5 a 15 GB de registros de protocolo al día en los servidores de transporte perimetral. Hay capacidad suficiente garantizada para la cuota de registro de protocolo, que es de 15 GB.

• 100 MB de registros de conectividad al día en los servidores de transporte perimetral. Hay capacidad garantizada para una semana de registros, que es de 600 MB aproximadamente.

• 250 MB de registros de agente al día en los servidores de transporte perimetral. Hay capacidad garantizada para una semana de registros, que es de 1,5 GB aproximadamente.

Los registros de transacciones no necesitan mucha capacidad de disco porque el uso del registro circular limita la creación del registro normal. Como resultado, los registros de transacciones se pueden colocar en el número de unidad lógica (LUN) que contiene el sistema operativo. Microsoft utiliza un reflejo de dos discos para este LUN.

La base de datos (mail.que) no almacena elementos de manera indefinida y la capacidad reservada deberá ser el tamaño promedio de cada mensaje multiplicado por la cola máxima, en el caso en el que la cola esté al máximo y el servidor esté apagado. Una cola de 500.000 elementos con un tamaño promedio de mensajes de 50 kilobytes (KB) tiene aproximadamente 25 GB de datos en la base de datos.

Los servidores de transporte perimetral que ejecutan antivirus necesitan espacio suficiente para la cuarentena antivirus. Los requisitos de recursos de E/S de disco dependen del porcentaje de correo entrante infectado por virus, que suele ser pequeño. La cantidad de adjuntos y mensajes infectados y el tiempo que permanecen en cuarentena dictan la cantidad de espacio que necesita la cuarentena. Un GB de espacio en disco es un buen punto de partida, aunque las necesidades reales de cada organización difieren.

Para la mayoría de las implementaciones de servidores de transporte perimetral, se recomienda que agregue un factor de sobrecarga del 20 por ciento al tamaño de la base de datos (una vez que se hayan considerado todos los demás factores). Este valor contará para estructuras internas dentro de la base de datos y asegura el espacio adecuado si un pico o un cambio en el flujo de correo produce un crecimiento de la base de datos.

Ejemplo de capacidad para un servidor de transporte perimetral

En este ejemplo, los registros de transacciones están almacenados en la partición del sistema operativo (C:), hospedado por un controlador de matriz redundante con caché y batería de discos independientes (RAID). Los requisitos de capacidad son pequeños (en el intervalo de varios megabytes).

Determinar la capacidad de un servidor de transporte perimetral es un proceso de dos pasos. Primero, calcule el tamaño de la base de datos y, a continuación, determine el tamaño del registro de transacciones.

Paso 1: Tamaño de la base de datos

Considere un servidor de transporte perimetral que recibe un promedio de 5 mensajes por segundo (con un tamaño medio de 50 KB) en un periodo de 24 horas, con un máximo de cola de 500.000 elementos. Una vez agregados todos los otros factores, se incluye una sobrecarga del 20 por ciento adicional y el tamaño total en disco es de 58 GB, tal como se muestra en la tabla siguiente.

Tamaño de la base de datos

Máximo de cola	Capacidad de cola	Registros de protocolo	Registros de seguimiento de mensajes	Cuarentena del antivirus	Registros de conectividad	Registros de agentes	Espacio disponible	Tamaño total en disco
500,000	Aproximadamente 25 GB (500.000 × 50 KB)	15 GB	1,3 GB	1 GB	600 MB	1,5 GB	4 GB	58 GB (48 GB + 20%)

Paso 2: Tamaño del registro de transacciones

Para determinar el tamaño del registro de transacciones, debe tener en cuenta la E/S transaccional, otras E/S de disco y la E/S de bases de datos por segundo (IOPS) por mensaje.

E/S transaccional

Si el servidor tiene suficiente memoria disponible, el correo entrante se almacenará en RAM y en el registro de transacciones, minimizando el impacto en disco. Cuando los recursos de memoria son bajos, sólo los primeros 128 KB del mensaje se almacenan en memoria y en el registro de transacciones. El resto del mensaje se almacena en la base de datos. Durante la conversión de contenido, los datos se transmiten a una ubicación temporal para su procesamiento. Esa ubicación temporal se especifica mediante la opción TemporaryStoragePath del archivo EdgeTransport.exe.config. De forma predeterminada, a la opción TemporaryStoragePath se le da el valor C:\Archivos de programa\Microsoft\Exchange Server\TransportRoles\data\Temp.

Es importante colocar el directorio temporal en el mismo LUN que la base de datos. Es importante también establecer la memoria caché del controlador de almacenamiento en 50 por ciento de lectura y 50 por ciento de escritura. Cuando no hay una gran cola creciente, pocas E/S en disco serán operaciones de lectura. Cuando hay una cola, el mensaje puede que no esté en la memoria caché de la base de datos, lo que requerirá más E/S de disco.

Otras E/S de disco

Además de E/S transaccionales, puede haber otras E/S de disco en el sistema. Por ejemplo:

• Habilitar registros de seguimiento de mensajes necesita un 2–5 por ciento de sobrecarga adicional en E/S de disco.

• Habilitar registros de conectividad y protocolo tiene una pequeña sobrecarga en las E/S de disco que depende de la cantidad de correo entrante.

• Habilitar los registros de agentes predeterminados tiene una pequeña sobrecarga en E/S de disco, aunque si los agentes personalizados están en uso, puede que se necesiten más recursos del disco.

• Las operaciones del antivirus y contra el correo no deseado tienen lugar en la memoria, necesitando más recursos de CPU.

Durante la prueba que espera usar en producción, asegúrese de comprobar los servidores de transporte perimetral con todos los servicios ejecutándose.

IOPS de bases de datos por mensaje

Durante la prueba interna en Microsoft el tamaño promedio de mensaje usado fue de 60 KB. Muchas organizaciones miden sus servidores de transporte teniendo en cuenta una tasa de mensajes concreta, por ejemplo 20 segundos por segundo. Esta velocidad de mensajes necesitaría 140 (20 × (4,5 + 2,5)) E/S en bases de datos y 220 (20 × 11) E/S en registro.

Cuando se forma una cola, se necesitan más lecturas, especialmente en el caso de RAID-1/0, porque cada disco físico responde a las solicitudes de lectura, tal como se muestra en la siguiente tabla.

IOPS de bases de datos por mensaje

E/S de base de datos de transporte perimetral (periodo de estabilización)	E/S perimetrales aproximadas
IOPS totales por mensaje (aproximadamente 60 KB)	18
E/S de escritura de registros por mensaje (secuencial)	11
E/S de escritura de la base de datos por mensaje (aleatoria)	4.5
E/S de lectura de la base de datos por mensaje (aleatoria)	2.5

Aplicar directrices de tamaño al diseño de hardware para un servidor de transporte perimetral

Una vez que tenga los requisitos de capacidad y de E/S transaccionales para un servidor de transporte perimetral, puede aplicarlos a un diseño de hardware propuesto. Para configuraciones de procesador y memoria, consulte Planeación de configuraciones del procesador y Diseño de configuraciones de memoria. Al diseñar un servidor de transporte perimetral, es importante tener suficiente RAM (cada mensaje necesita 8 o 9 KB de memoria) en el sistema para evitar el almacenamiento temporal en caché de los cuerpos del mensaje en cola en el disco.

Un servidor de transporte perimetral usa una base de datos del motor de almacenamiento extensible (ESE). Para el mejor rendimiento y la recuperación es importante separar los archivos de registro y de bases de datos en los propios discos físicos en entornos donde habrá una cola larga . En implementaciones más pequeñas que tengan menos requisitos de E/S de disco, puede que sea más factible colocar los archivos de registro y de transacciones en el mismo LUN. El servidor de transporte perimetral, como el servidor Buzón, necesita tiempos de respuesta de E/S inferiores a 20 milisegundos.

Es importante usar controladores RAID con caché y con baterías y realizar un mantenimiento nocturno de las bases de datos. Asegúrese además de que el tipo de disco elegido proporcionará el equilibrio correcto entre capacidad y rendimiento.

Ejemplo de tamaño de diseño de hardware para un servidor de transporte perimetral

En este ejemplo se muestra cómo diseñar el almacenamiento según los mensajes esperados por segundo. En este ejemplo, hay un servidor de transporte perimetral que maneja 20 mensajes por segundo y que necesita 140 IOPS para el LUN de base de datos y 220 IOPS para el LUN de registro. Agregue siempre un factor de crecimiento del 20 por ciento para el rendimiento de E/S de disco para que pueda manejar volúmenes mayores a los de los días normales. El diseño de disco es RAID10. Para los resultados sobre el tamaño del hardware, consulte la tabla siguiente.

Tamaño del hardware

Diseño RAID1, discos (1) y (2)	Diseño RAID10, discos (3), (4), (5) y (6)
Sistema operativo y registros de transacciones 220 + 20% = 264 IOPS	Registros de bases de datos, protocolo y seguimiento de mensajes y cuarentena del antivirus 140 + 20% = 168 IOPS

Este ejemplo tiene un requisito de capacidad de LUN de la base de datos de 70 GB aproximadamente para una semana de datos. Deberá doblar el requisito de capacidad a 140 GB si necesita dos semanas de datos. El uso de discos físicos de 146 GB permitiría un LUN de 292 GB en una configuración RAID10.

Requisitos de E/S y de capacidad del servidor de transporte de concentradores

Además, los servidores de transporte de concentradores deben estar diseñados para que cumplan los requisitos de E/S transaccionales y de capacidad de la organización. Con el servidor de transporte perimetral también debe existir un mínimo de 500 MB de espacio disponible en el disco en la unidad que contiene la base de datos de cola de mensajes o el sistema de transporte activará la presión de reserva. Puede modificar el valor predeterminado para el parámetro PercentageDatabaseDiskSpaceUsedHighThreshold en los servidores de transporte de concentradores.

La capacidad de registro de seguimiento de mensajes depende del número de mensajes que recibe el servidor de transporte. Si la organización usa actualmente Exchange 2003, podrá determinar el nivel actual de generación de registros y establecer un límite estricto de días para conservar los datos, como por ejemplo 10 días. Microsoft genera 700 MB de registros de seguimiento de mensajes cada día laborable (menos durante el fin de semana) en los servidores de transporte de concentradores y asegura la capacidad suficiente para una semana de registros (4,5 GB aproximadamente).

El tamaño de los registros de protocolo varía en función de la actividad. Microsoft genera 2,7 GB de registros de protocolo al día en los servidores de transporte de concentradores y asegura que hay capacidad suficiente para una semana de registros, 16 GB aproximadamente.

Los registros de transacciones no necesitan mucha capacidad de disco porque el uso del registro circular limita la creación del registro normal. Como resultado, los registros de transacciones se pueden colocar en el LUN del sistema operativo. Microsoft usa un reflejo de dos discos para este LUN.

La base de datos (mail.que) no almacena elementos de manera indefinida y la capacidad reservada deberá ser el tamaño promedio de cada mensaje multiplicado por la cola máxima, en el caso en el que la cola esté al máximo y el servidor esté apagado. Una cola de 500.000 elementos con un tamaño promedio de mensajes de 50 KB tiene aproximadamente 25 GB de datos en la base de datos.

Para la mayoría de las implementaciones de servidores de transporte de concentradores, se recomienda que agregue también una sobrecarga extra del 20 por ciento al tamaño de la base de datos una vez que todos los demás factores se hayan considerado.

Volcado de archivos de transporte

Es necesaria una consideración especial para los servidores de transporte de concentradores en sitios que contengan:

• Servidores de buzones de correo en clústeres implementados en un entorno de replicación continua en clúster (CCR) que utilicen Exchange Server 2007 RTM o Exchange 2007 SP1.

• Servidores Buzón que están ejecutando Exchange 2007 (SP1) que tengan uno o más grupos de almacenamiento habilitados para la replicación continua local (LCR).

Al implementar alguno de los entornos anteriores, asegúrese de que diseña el servidor de transporte de concentradores con la capacidad suficiente para almacenar correo lo suficientemente extenso para todos los grupos de almacenamiento en el sitio, de modo que los mensajes se puedan recuperar en caso de una interrupción no programada del nodo activo. Esta característica se conoce como volcado de archivos de transporte.

La sobrecarga de E/S del volcado de archivos de transporte es similar a agrandar una cola. Hay dos parámetros que puede usar para controlar el tiempo que un mensaje permanece en el volcado de archivos de transporte: MaxDumpsterSizePerStorageGroup y MaxDumpsterTime. El valor predeterminado para MaxDumpsterSizePerStorageGroup es de 18 MB. Para especificar correctamente el tamaño del volcado de archivos de transporte para el entorno, tome el mayor tamaño de mensajes que pueda asumir y aumente ese tamaño un 50 por ciento. Por ejemplo, si la cuota de mensaje es de 10 MB, desearía establecer la MaxDumpsterSizePerStorageGroup en 15 MB. Si hay más de un servidor de transporte de concentradores en el mismo sitio del servicio de directorio de Active Directory que el servidor de buzones de correo en clúster en el entorno CCR o un entorno LCR que ejecute Exchange 2007 SP1, el almacenamiento agregado para los grupos de almacenamiento en ese servidor de buzones de correo en clúster se esparcen por todos los servidores de transporte de concentradores. Por ejemplo, si tiene servidores de transporte de concentradores con un volcado de archivos de transporte de 15 MB, habrá un volcado de archivos de transporte de 60 MB para ese grupo de almacenamiento.

Para organizaciones sin límites de tamaño de mensajes, es recomendable establecer el MaxDumpsterSizePerStorageGroup en un valor de 1,5 veces el tamaño medio de los mensajes enviados en la organización. Además, si no se ha establecido un límite de tamaño, no puede garantizar la vuelta de ese mensaje después de una interrupción no programada en un entorno CCR ni después de una activación de la copia pasiva en un entorno LCR que esté ejecutando Exchange 2007 SP1.

Le recomendamos que establezca MaxDumpsterTime en 7 días, que es el valor predeterminado.

La capacidad que consume el volcado de archivos de transporte será el número de grupos de almacenamiento multiplicado por el tamaño máximo del volcado de archivos de transporte. Si el tamaño máximo de volcado de archivos de transporte es de 15 MB y el servidor de transporte de concentradores da servicio a 100 grupos de almacenamiento en un entorno LCR (Exchange 2007 SP1) o CCR (Exchange 2007 RTM ), se deberán asignar 1,5 GB para el volcado de archivos de transporte.

Ejemplo de tamaño del volcado de archivos de transporte

En este ejemplo, los registros de transacciones están en el disco que contiene la partición del sistema operativo (C:), hospedados por un controlador RAID con caché y baterías. Los requisitos de capacidad serán pequeños (en el intervalo de megabytes). Para los resultados sobre el tamaño, consulte las tablas siguientes.

Determinar la capacidad que necesita la característica de volcado de archivos de transporte es un proceso de dos pasos. Primero, calcule el tamaño de la base de datos y, a continuación, determine el tamaño del registro de transacciones.

Paso 1: Tamaño de la base de datos

Considere un servidor de transporte de concentradores que recibe un promedio de 5 mensajes por segundo en un período de 24 horas y con una cola máxima de 500.000 elementos.

Tamaño del volcado de archivos de transporte

Máximo de cola	Capacidad de cola	Registros de protocolo	Registros de seguimiento de mensajes	Volcado de archivos de transporte	Tamaño total en disco
500,000	25 GB (500.000 × 50 KB)	15 GB	4,5 GB	1,5 GB	55 GB (46 GB + 20%)

Paso 2: Tamaño del registro de transacciones

Para determinar el tamaño del registro de transacciones, debe tener en cuenta las E/S transaccionales, otras E/S en disco y las IOPS por mensaje.

E/S transaccional

Las mismas pautas sobre las E/S transaccionales citadas anteriormente para los servidores de transporte perimetral se aplican a los servidores de transporte de concentradores. Como se ha mencionado anteriormente, resulta especialmente importante configurar los valores de la memoria caché en el controlador de almacenamiento, como se indica a continuación: 50 por ciento de lectura, 50 por ciento de escritura.

E/S de volcado de archivos de transporte

Cuando se ha habilitado el volcado de archivos de transporte, aumenta la E/S en disco. Aunque las escrituras en base de datos aumentan, las lecturas de base de datos también se producen ahora, lo que en los servidores de producción de Microsoft tiene un promedio aproximado de tres lecturas por mensaje.

Otras E/S de disco

Las mismas pautas sobre otras E/S citadas anteriormente para los servidores de transporte perimetral se aplican a los servidores de transporte de concentradores. Durante la prueba que espera usar en producción, es especialmente importante comprobar los servidores de transporte de concentradores con todos los servicios ejecutándose.

IOPS de bases de datos por mensaje

En la prueba interna en Microsoft con un tamaño medio de mensajes de 40 KB, habilitar el volcado de archivos de transporte necesita más recursos del disco en el servidor de transporte de concentradores. Muchas empresas miden sus servidores de transporte suponiendo una tasa de mensajes concreta, por ejemplo 20 segundos por segundo. Si el volcado de archivos de transporte está habilitado, necesitaría 200 E/S de bases de datos (20 × (7 + 3)) y 140 E/S de registros (20 × 7) para dar servicio a una velocidad de mensajes entrantes de 20 mensajes por segundo. Con el volcado de archivos de transporte deshabilitado, esto necesitaría 40 E/S de bases de datos (20 × (2 + 40)) y 140 E/S de registros (20 × 2) para dar servicio a una velocidad de mensajes entrantes de 20 mensajes por segundo.

Cuando se forma una cola, se necesitan más lecturas, especialmente en el caso de RAID10, porque cada disco físico responde a las solicitudes de lectura. Para obtener más información, consulte los siguientes temas.

Tamaño del registro de transacciones

E/S de base de datos del servidor de transporte de concentradores (periodo de estabilización)	Volcado de archivos de transporte habilitado	Volcado de archivos de transporte deshabilitado
IOPS totales por mensaje (aproximadamente 40 KB)	17	4
E/S de escritura de registros por mensaje (secuencial)	7	2
E/S de escritura de la base de datos por mensaje (aleatoria)	7	2
E/S de lectura de la base de datos por mensaje (aleatoria)	3	0

Aplicar directrices de tamaño al diseño de hardware para un servidor de transporte de concentradores

Una vez que tenga los requisitos de capacidad y de E/S transaccionales para un servidor de transporte de concentradores, puede aplicarlos a un diseño de hardware propuesto. Para configuraciones de procesador y memoria para los servidores de transporte de concentradores, consulte Planeación de configuraciones del procesador y Diseño de configuraciones de memoria. Al diseñar un servidor de transporte de concentradores, es importante tener suficiente RAM (cada mensaje necesita 8 o 9 KB de memoria) en el sistema para evitar el almacenamiento temporal en caché de los cuerpos del mensaje en cola en el disco.

Un servidor de transporte de concentradores usa una base de datos de ESE. Para el mejor rendimiento es importante separar los archivos de registro y de bases de datos en los propios discos físicos en entornos donde haya una cola larga o al utilizar el volcado de archivos de transporte. Para implementaciones más pequeñas con menos requisitos de E/S en disco, puede que sea más factible colocar los registros de transacciones y la base de datos en el mismo LUN. El servidor de transporte de concentradores, como el servidor de transporte perimetral, necesita tiempos de respuesta de E/S inferiores a 20 milisegundos.

Ejemplos de tamaño de diseño de hardware para un servidor de transporte de concentradores

Es importante para diseñar el almacenamiento de los mensajes esperados por segundo. En este ejemplo, un servidor de transporte de concentradores maneja 20 mensajes por segundo con el volcado de archivos de transporte deshabilitado y necesita 40 IOPS para el LUN de la base de datos y 40 IOPS para el LUN de registro. Agregue siempre un factor de crecimiento del 20 por ciento para el rendimiento de E/S de disco para que pueda manejar volúmenes mayores a los de los días normales. El diseño de disco sería RAID1. Este ejemplo tiene un requisito de capacidad de LUN de la base de datos de 55 GB aproximadamente para una semana de datos. Deberá doblar el requisito de capacidad a 110 GB si necesita dos semanas de datos. El uso de discos físicos de 140 GB proporcionaría un LUN de base de datos de 140 GB en una configuración RAID1 y un LUN de registro de 140 GB en una configuración RAID1. Para ver los resultados, consulte la siguiente tabla.

Tamaño del hardware para un servidor de transporte de concentradores que maneje 20 mensajes por segundo con el volcado de archivos de transporte deshabilitado

Diseño RAID1, discos (1) y (2)	Diseño RAID1, discos (3) y (4)
Sistema operativo y registros de transacciones 40 + 20% = 48 IOPS	Base de datos, protocolo y registro de seguimiento de mensajes y cuarentena de antivirus 40 + 20% = 48 IOPS

En este ejemplo siguiente, hay un servidor de transporte de concentradores con el volcado de archivos de transporte deshabilitado que maneja 20 mensajes por segundo. Esta configuración necesita 200 IOPS para el LUN de base de datos y 140 IOPS para el LUN de registro más el 20 por ciento extra de factor de crecimiento. El diseño de disco es RAID10. Este ejemplo tiene un requisito de capacidad de LUN de la base de datos de 55 GB aproximadamente para una semana de datos o 110 GB si se necesitan dos semanas de datos. El uso de discos físicos de 140 GB proporcionaría un LUN de base de datos de 280 GB en una configuración RAID10 y un LUN de registro de 140 GB en una configuración RAID1.

Tamaño del hardware para un servidor de transporte de concentradores que maneje 20 mensajes por segundo con el volcado de archivos de transporte habilitado

Diseño RAID1, discos (1) y (2)	Diseño RAID10, discos (3), (4), (5) y (6)
Sistema operativo y registros de transacciones 140 + 20% = 168 IOPS	Base de datos, protocolo y registro de seguimiento de mensajes y cuarentena de antivirus 200 + 20% = 240 IOPS