Diseño del almacenamiento del servidor de buzones

 

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

Última modificación del tema: 2009-04-03

Tener una capacidad suficiente es fundamental. Cuando un disco de base de datos se queda sin espacio, la base de datos se desconecta. Cuando un disco de registro de transacción se queda sin espacio, esto provoca que todas las bases de datos de ese grupo de almacenamiento se desconecten. A menudo, es difícil proporcionar espacio adicional rápidamente y realizar una compactación fuera de línea para recuperar espacio puede tardar mucho tiempo. En la mayoría de los casos, quedarse sin espacio provoca una interrupción de la disponibilidad de una o más bases de datos durante un periodo de tiempo que normalmente supera la mayoría de los objetivos de tiempo de recuperación (RTO).

En este tema se presenta la siguiente información:

• Calculadora de almacenamiento de buzones para Exchange 2007

• Capacidad de LUN de base de datos

• Capacidad de LUN de registro

• E/S transaccional

• Predicción de la ESPS de línea base de Exchange 2007

• E/S no transaccional

• LUN y discos físicos

• Impacto de la replicación continua en el diseño del almacenamiento

Calculadora de almacenamiento de buzones para Exchange 2007

La calculadora de requisitos de almacenamiento de la función del servidor Buzón de correo de Exchange Server 2007 (calculadora de almacenamiento) permite determinar sus requisitos de almacenamiento (capacidad y rendimiento E/S) y un diseño de número de unidad lógica (LUN) basado en un conjunto de factores de entrada. Existen numerosos factores de entrada que deben tenerse en cuenta antes de diseñar una solución de almacenamiento óptima para un servidor de buzones de Exchange 2007. Estos factores de entrada se describen a lo largo de este tema.

La calculadora de almacenamiento permite introducir valores específicos para su organización y le ofrece recomendaciones para los requisitos E/S, los requisitos de capacidad y el diseño LUN óptimo.

Para obtener más información acerca de la calculadora de almacenamiento, incluidos detalles sobre cómo usarla, consulte Calculadora de requisitos de almacenamiento de la función del servidor Buzón de correo de Exchange 2007 (en inglés) - donde también puede descargar la calculadora - del blog del equipo de Exchange.

Capacidad de LUN de base de datos

Existen varios puntos de datos que se usarán para establecer cómo determinar el tamaño de un LUN de base de datos. Además, hay que tener en cuenta otros factores. Una vez que se hayan considerado y calculado todos los factores, se recomienda incluir un factor de sobrecarga adicional al LUN de la base de datos del 20%. Este valor justificará el resto de los datos incluidos en la base de datos que no se ven necesariamente al calcular los tamaños de buzón y el espacio en blanco. Por ejemplo, la estructura de los datos (tablas, vistas e índices internos) aumenta el tamaño global de la base de datos. Por ejemplo, si después de leer las secciones siguientes determina que necesita 120 gigabytes (GB), recomendamos que aprovisione 144 GB, lo que representa un 20% de sobrecarga de seguridad para ese LUN de base de datos de grupo de almacenamiento.

Cuota de buzón

El primer indicador que debe entenderse es el tamaño de buzón. Conocer la cantidad de datos que un usuario final puede almacenar en su buzón permite determinar cuántos usuarios pueden hospedarse en el servidor. Pese a que los tamaños y cuotas del buzón final cambian, el primer paso para determinar la capacidad necesaria es tener un objetivo. Por ejemplo, si tiene 5.000 usuarios en un servidor con una cuota de buzón de 250 megabytes (MB), necesitará como mínimo 1,25 terabytes (TB) de espacio en disco. Si no establece un límite estricto en las cuotas de buzón, será difícil estimar la capacidad que necesitará.

Espacio en blanco en la base de datos

El tamaño de la base de datos del disco físico no es sólo el número de usuarios multiplicado por la cuota de usuarios. Cuando la mayor parte de los usuarios estén cerca de su cuota de buzón, las bases de datos consumirán menos espacio y el espacio en blanco no representará un problema de capacidad. La propia base de datos siempre tiene páginas o espacios en blanco. Durante el mantenimiento en línea, se quitan los elementos marcados para su eliminación de la base de datos, lo que libera estas páginas. El porcentaje de espacio en blanco cambia constantemente con el porcentaje mayor inmediatamente después del mantenimiento en línea y el porcentaje menor justo antes del mantenimiento en línea.

El tamaño del espacio en blanco en la base de datos se puede calcular aproximadamente según la cantidad de correo enviado y recibido por los usuarios que tengan buzones en la base de datos. Por ejemplo, si tiene cien buzones de 100 GB (un total de 200 GB) en una base de datos donde los usuarios envían y reciben una media de 10 MB de correo al día, el espacio en blanco es aproximadamente de 1 GB (100 buzones * 10 MB por buzón).

El espacio en blanco puede crecer por encima de esta aproximación si el mantenimiento en línea no consigue completar un pase completo. Es importante que las actividades operativas incluyan tiempo suficiente para que el mantenimiento en línea se ejecute cada noche, de forma que pueda completarse un pase completo en una semana o menos.

Contenedor de base de datos

Cada base de datos tiene un contenedor que almacena elementos eliminados temporalmente. De forma predeterminada, en Microsoft Exchange Server 2007 los elementos se almacenan durante 14 días. Se incluyen elementos quitados de la carpeta de elementos eliminados. De forma predeterminada, en comparación con Exchange Server 2003, Exchange 2007 aumenta la sobrecarga que consume el contenedor de base de datos, ya que los elementos eliminados se almacenan dos veces. La cantidad actual del contenedor dependerá del tamaño de cada elemento y de su configuración de retención específica para la organización.

Una vez transcurrido el periodo de retención, estos elementos se eliminarán de la base de datos durante un ciclo de mantenimiento en línea. Finalmente, se alcanzará un período de estabilización en el que el tamaño del contenedor será equivalente a 2 semanas de correo entrante/saliente como porcentaje del tamaño de su base de datos. El porcentaje exacto depende de la cantidad de correo eliminado y de los tamaños de los buzones individuales.

El contenedor agrega un porcentaje de sobrecarga a la base de datos que depende del tamaño del buzón y de la velocidad de entrega de mensajes para ese buzón. Por ejemplo, con una velocidad de entrega de mensajes constante de 52 MB por semana, un buzón con un perfil muy pesado de 250 MB almacenará aproximadamente 104 MB en el contenedor, lo que agrega una sobrecarga del 41%. Un buzón de 1 GB que almacene los mismos 104 MB en el contendor agrega una sobrecarga del 10%.

Tamaño real del buzón

Con el tiempo, los buzones de usuario alcanzarán la cuota de buzón, por lo que será necesario eliminar una cantidad equivalente de correo entrante para mantenerse por debajo de la cuota de buzón. Esto significa que el contenedor aumentará a un tamaño máximo equivalente a dos semanas de correo entrante/saliente. Si la mayoría de usuarios no han alcanzado la cuota de buzón, sólo se eliminarán algunos de los mensajes de correo entrantes/salientes, por lo que el crecimiento se dividirá entre el contenedor y el aumento del tamaño del buzón. Por ejemplo, un buzón con un perfil de mensajes muy pesado de 250 MB que recibe 52 MB de correo a la semana (con un tamaño de mensaje medio de 50 kilobytes (KB)) también consumirá 104 MB en el contenedor (41%), y 7,3 MB de espacio en blanco, para un tamaño de buzón total de 360 MB. Otro ejemplo sería un buzón con un perfil de mensajes muy pesado de 2 GB que recibe 52 MB de correo a la semana, que consume 104 MB en el contenedor (5%) y 7,3 MB de espacio en blanco para un tamaño de buzón total de 2,11 GB. Cincuenta buzones de 2 GB en un grupo de almacenamiento sumarán un total de 105,6 GB.

A continuación, se muestra una fórmula para calcular el tamaño de la base de datos con un buzón de 2 GB:

Tamaño del buzón = Cuota de buzón + Espacio en blanco + (Correo entrante semanal × 2)

Tamaño del buzón = 2,048 MB + (7.3 MB) + (52 MB × 2)

2,159 MB = 2,048 MB + 7.3 MB + 104 MB (5% mayor que la cuota)

Cuando haya determinado el tamaño real del buzón proyectado, puede usar dicho valor para determinar el número máximo de usuarios por base de datos. Tome el tamaño del buzón proyectado y divídalo por el tamaño de base de datos máximo recomendado. Esto le ayudará a determinar cuántas bases de datos necesita para administrar el recuento de usuarios proyectados, con bases de datos completas. Recuerde que la entrada/salida (E/S) no transaccional o las limitaciones de hardware pueden obligar a modificar el número de usuarios ubicados en un solo servidor. Algunos administradores preferirán usar más bases de datos para reducir el tamaño de la base de datos. Esta opción puede facilitarle la copia de seguridad y la restauración de ventanas a cambio de una mayor complejidad al tener que administrar más bases de datos por servidor.

Indización de contenido

La indización de contenido crea un índice que permite a los usuarios realizar búsquedas de manera sencilla y rápida en los elementos de correo, en lugar de tener que buscarlos manualmente por el buzón. Exchange 2007 crea un índice de alrededor del 5% del tamaño total de la base de datos, que se coloca en el mismo LUN que la base de datos. Es necesario crear una capacidad adicional del 5% en el tamaño del LUN de la base de datos para indizar el contenido.

Mantenimiento

Una base de datos que debe repararse o compactarse cuando está desconectada necesitará una capacidad igual al tamaño de la base de datos de destino más un 10%. Si asigna suficiente espacio para una única base de datos, un grupo de almacenamiento o un conjunto de copia de seguridad, necesitará espacio adicional para realizar estas operaciones.

Grupo de almacenamiento de recuperación

Si tiene previsto usar un grupo de almacenamiento de recuperación como parte de los planes de recuperación ante desastres, necesitará que haya capacidad suficiente para manipular todas las bases de datos que desee restaurar simultáneamente en ese servidor.

Copia de seguridad a disco

Muchos administradores realizan copias de seguridad en línea de transmisión por secuencias a un disco de destino. Si su diseño de copias de seguridad y restauraciones incluye copias de seguridad a disco, necesita suficiente capacidad disponible en el servidor para hospedar la copia de seguridad. Dependiendo del tipo de copia de seguridad que use, esta capacidad puede ser tan pequeña como la base de datos y los registros o tan grande como la base de datos y todos los registros desde la última copia de seguridad completa.

Capacidad de LUN de registro

Los archivos de registro de transacciones son un registro de todas las transacciones realizadas con el motor de base de datos. Todas las transacciones se escriben primero en el registro y, a continuación, se escriben lentamente en la base de datos. A diferencia de las versiones anteriores de Exchange, los archivos de registro de transacciones de Exchange 2007 han reducido su tamaño de 5 MB a 1 MB. Este cambio se ha realizado para admitir las características de replicación continua y para minimizar la cantidad de datos perdidos si el almacenamiento principal sufre un error.

Puede usar la siguiente tabla para estimar el número de registros de transacciones que se generarán en un servidor de buzones de Exchange 2007 donde el tamaño de mensaje medio es de 50 KB.

Número de registros de transacciones generados para cada perfil de buzones

Perfil de buzones	Perfil de mensajes	Registros generados / buzón
Leve	5 envíos/20 recepciones	6
Promedio	10 envíos/40 recepciones	12
Intenso	20 envíos/80 recepciones	24
Muy intenso	30 envíos/120 recepciones	36
Extremadamente intenso	40 envíos/160 recepciones	48

Las siguientes directrices se han establecido para determinar cómo afecta el tamaño del mensaje a la tasa de generación de registros:

• Si el tamaño de mensaje medio dobla los 100 KB, los registros generados por buzón aumentan multiplicándose por 1,9. Este número representa el porcentaje de la base de datos que contiene los datos adjuntos y las tablas de mensajes (cuerpos del mensaje y datos adjuntos).

• Por tanto, como el tamaño del mensaje se dobla y supera los 100 KB, la tasa de generación de registros por buzón también se dobla.

Por ejemplo:

• Si tiene un perfil de buzones pesado y un tamaño de mensaje medio de 100 KB, los registros generados por buzón son 24 × 1,9 = 46.

• Si tiene un perfil de buzones pesado y un tamaño de mensaje medio de 200 KB, los registros generados por buzón son 24 × 3,8 = 91.

Factores de copia de seguridad y restauración

La mayoría de las empresas que realizan una copia de seguridad completa por la noche asignarán la capacidad de 3 días aproximadamente de archivos de registro en un grupo de almacenamiento del LUN de registro de transacciones. Esto se realiza para evitar que un error de copia de seguridad provoque que la unidad de registro se llene, lo que desmontaría el grupo de almacenamiento.

El tamaño del LUN de registro es algo que depende de su diseño de copia de seguridad y restauración. Por ejemplo, si el diseño permite retroceder dos semanas y reproducir todos los registros generados desde entonces, necesitará un espacio de archivo de registro para dos semanas. Si su diseño de copia de seguridad incluye copias de seguridad completas semanales y diferenciales diarias, el LUN de registro tendrá que ser mayor que a una semana entera de espacio de archivo de registro para permitir tanto la copia de seguridad como la reproducción durante la restauración.

Operaciones de movimiento de buzón

El movimiento de buzones es un factor de capacidad principal para implementaciones de buzones grandes. Muchas empresas grandes mueven un porcentaje de sus usuarios sobre una base nocturna o semanal a bases de datos, servidores o sitios distintos. Si su organización lo hace, puede que encuentre necesario para ofrecer capacidad adicional al LUN de registro para acomodar las migraciones de usuarios. Pese a que el servidor de origen registrará las eliminaciones registradas, que son pequeñas, el servidor de destino debe escribir todos los datos transferidos antes de los registros de transacción. Si generara 10 GB de archivos de registro en un día y mantuviera un búfer de 3 días de 30 GB, al mover 50 buzones de 2 GB (100 GB) llenaría el LUN de registros de destino y provocaría un tiempo de inactividad. En casos como estos, puede que tenga que asignar capacidad adicional para los LUN de registro a fin de acomodar sus prácticas de movimiento de buzón.

Factor de crecimiento del registro

Para la mayoría de implementaciones, es aconsejable que agregue un factor de sobrecarga del 20% al tamaño del registro (una vez considerados el resto de factores) al crear el LUN de registro para asegurarse de que exista la capacidad necesaria en momentos de generación de registros inesperados.

Ejemplo de planeamiento de la capacidad de los buzones

En el ejemplo siguiente se muestra el tamaño adecuado para un entorno con 4000 buzones de 1 GB buzones con perfil de mensajes muy pesado en un solo servidor de buzones de correo en clúster de un entorno de replicación continua en clúster (CCR). Estos buzones reciben una media de 52 MB de correo no deseado a la semana, con un tamaño de mensaje medio de 50 KB. En la siguiente tabla se proporcionan valores de ejemplo que determinan el tamaño real del buzón.

Ejemplo valores de ejemplo para determinar el tamaño real del buzón en disco

Tamaño del buzón	Tamaño del contenedor (2 semanas)	Espacio en blanco	Tamaño total en disco
1 GB	104 MB (2 × 52 MB)	7,3 MB	1,11 GB (+ 11%)

En este entorno, cada usuario consumirá 1,11 GB de espacio en disco. El tamaño de base de datos máximo recomendado en un entorno CCR es de 200 GB, el servidor no debe hospedar más de 180 buzones por base de datos. Para admitir 4000 buzones, son necesarias 23 bases de datos y, en este entorno, habría también 23 grupos de almacenamiento. Dado que un entorno CCR requiere una base de datos por grupo de almacenamiento, cada base de datos se encuentra en su propio grupo de almacenamiento. El resultado es un buzón final por 174 grupos de almacenamiento. Según el número de buzones y el tamaño actual de los mismos, el tamaño de la base de datos es de 193 GB, como se muestra en la siguiente tabla.

Requisitos de capacidad de base de datos

Buzones por base de datos	Número total de bases de datos	Requisitos de tamaño de base de datos
174	23	193 GB

Para asegurarse de que el servidor de buzones 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. Muchas organizaciones usan una estrategia de copia de seguridad completa diaria y programan en tres veces la tasa diaria de generación de registros si la copia de seguridad da error. Si se usa una copia de seguridad completa semanal y, a continuación, una copia de seguridad incremental o diferencial, es necesaria, como mínimo, la capacidad de registro de una semana para administrar la restauración. Sabiendo que un buzón de perfil de mensaje muy pesado genera de media 42 registros de transacciones diarios, un servidor de 4.000 buzones generará 168.000 registros de transacciones diarios. Es decir, cada grupo de almacenamiento generará 7.304 registros. El 10% de los buzones se mueven un día (sábado) por semana y el régimen de copia de seguridad incluye copias de seguridad completas semanales e incrementales diarias. Además, el servidor puede tolerar tres días sin truncamiento del registro. Como se muestra en la siguiente tabla, este servidor necesita 38,8 GB de espacio para cada grupo de almacenamiento.

Requisitos de capacidad del registro

Registros por grupo de almacenamiento	Tamaño del archivo de registro	Tamaño del registro diario	Tamaño de mover buzón	Tamaño de restauración incremental	Requisitos del tamaño del registro
7,304	1 MB	7,13 GB	17 GB (17 × 1 GB)	21,4 GB (3 × 7,13 GB)	38,8 GB (17.4 + 21.4)

El LUN de registro de transacciones debe ser lo suficientemente grande para administrar los registros generados por la operación de movimiento del buzón y tener espacio suficiente para restaurar los registros de toda una semana.

E/S transaccional

La E/S transaccional son las E/S del disco que originan usuarios que usan el servidor. Por ejemplo, la recepción, el envío y la eliminación de elementos provocan la E/S en disco. Los usuarios de Microsoft Outlook que no usen el modo caché de Exchange se ven directamente afectados por una latencia de disco insuficiente, uno de los problemas más importantes del diseño de almacenamiento. En lo que respecta al almacenamiento, se han reducido los requisitos de E/S transaccional, y con la replicación continua, una alta disponibilidad ya no implica usar un almacenamiento de canal de fibra caro (aunque ésta continúa siendo una buena solución).

Descripción de IOPS

En versiones anteriores de Exchange Server, uno de los indicadores clave necesarios para determinar el tamaño del almacenamiento es la cantidad de E/S de base de datos por segundo (IOPS) consumida por cada usuario. Para medir sus IOPS de usuario, tome la cantidad de E/S (lecturas y escrituras) en el LUN de base de datos para un grupo de almacenamiento y divídala por el número de usuarios de ese grupo de almacenamiento. Por ejemplo, 1.000 usuarios que causen 1.000 E/S en el LUN de base de datos significa que tiene una IOPS de 1,0 por usuario.

Medición de IOPS de línea base

Si está usando una versión anterior de Exchange Server y ha calculado la Entrada/Salida por segundo (ESPS) de línea de base, tenga en cuenta que Exchange 2007 afectará a la línea de base de la siguiente manera:

• El número de usuarios del servidor afectará a la memoria caché de base de datos global por usuario.

• La cantidad de RAM influye en el crecimiento de la memoria caché de base de datos y una caché de base de datos mayor afecta más a la lectura de caché, con lo que se reduce su E/S de lectura de base de datos.

La clave está en que conocer su ESPS en un servidor determinado no es suficiente para planear una organización completa, ya que la cantidad de RAM, el número de usuarios y el número de grupos de almacenamiento serán probablemente diferentes en cada servidor. Una vez que tenga los números ESPS reales, aplique siempre un factor de sobrecarga de E/S del 20% a los cálculos para disponer de cierto margen. Lo que no quiere es que la experiencia de usuario sea insuficiente debido a que la actividad sea un más intensa de lo normal.

Caché de base de datos

Un sistema operativo Windows Server de 64 bits que ejecute la versión de 64 bits de Exchange 2007 aumenta sustancialmente el espacio de dirección virtual y permite a Exchange aumentar la memoria caché de base de datos, reducir la E/S de lectura de base de datos y habilitar hasta 50 bases de datos por servidor.

La reducción de lectura de la base de datos depende de la cantidad de caché de base de datos disponible en el servidor y del perfil de mensajes del usuario. Para obtener instrucciones sobre la memoria y los grupos de almacenamiento, consulte Planeación de configuraciones del procesador. Si sigue las instrucciones de ese tema, obtendrá hasta un 70% de reducción de E/S transaccional en Exchange 2003. La cantidad de caché de base de datos por usuario es un factor clave en la reducción real de E/S.

En la tabla siguiente se muestra el aumento de la memoria caché de base de datos real por usuario cuando se comparan los 900 MB predeterminados de Exchange 2003 con los 5 MB de la memoria caché de base de datos por usuario en Exchange 2007. Ésta es la memoria caché de base de datos adicional que permite más lecturas en caché, con lo que se reducen las lecturas de base de datos en el disco.

Tamaños de caché de base de datos basados en el número de buzones

Número de buzones	Buzón/caché de base de datos de Exchange 2003 (MB)	Buzón/caché de base de datos de Exchange 2007 (MB)	Aumento de la memoria caché de base de datos en Exchange 2003
4,000	0.225	5	23 veces
2,000	0.45	5	11 veces
1,000	0.9	5	6 veces
500	1.8	5	3 veces

Predicción de la ESPS de línea base de Exchange 2007

Los dos factores mayores que se pueden usar para predecir las ESPS de las base de datos de Exchange 2007 son la cantidad de caché de base de datos por usuario y el número de mensajes que envía y recibe cada usuario al día. La fórmula siguiente se basa en un trabajador estándar que usa Office Outlook 2007 en modo caché de Exchange, y se ha probado su precisión en un más o menos 20%. Otros tipos de clientes y situaciones pueden generar resultados imprecisos. Las predicciones sólo son válidas para tamaños de caché de base de datos entre 2 MB y 5 MB. La fórmula no se ha validado con usuarios que envíen y reciban más de 150 mensajes al día. El tamaño de mensaje medio para validar la fórmula fue 50 KB, aunque el tamaño del mensaje no es un factor principal de ESPS.

En la siguiente tabla se proporcionan valores estimados para ESPS por usuario que se pueden usar para predecir los requisitos de ESPS de línea base de Exchange 2007.

Caché de base de datos e ESPS estimadas por usuario según perfil de usuario y actividad de mensajes

Tipo de usuario (perfil de uso)	Enviar/recibir un volumen de mensajes diario de aproximadamente 50 KB	Caché de base de datos por usuario	ESPS estimada por usuario
Leve	5 envíos/20 recepciones	2 MB	0.11
Promedio	10 envíos/40 recepciones	3,5 MB	0.18
Intenso	20 envíos/80 recepciones	5 MB	0.32
Muy intenso	30 envíos/120 recepciones	5 MB	0.48
Extremadamente intenso	40 envíos/160 recepciones	5 MB	0.64

Para calcular el tamaño de caché de base de datos aproximado, reste 2,048 MB o 3,072 MB si usa la replicación continua local (LCR), de la cantidad total de memoria instalada en el servidor de Exchange y divida dicha cantidad por el número de usuarios. Por ejemplo, para un servidor con 3,000 usuarios y 16 GB de RAM, reste 2 GB para el sistema y deje 14 GB de RAM o 4.66 MB por usuario (14 GB ÷ 3,000 = 4.66 MB).

Sabiendo que el tamaño medio de caché de base de datos por usuario es de 4,66 MB y que el promedio de mensajes enviados y recibidos al día es 60, puede calcular aproximadamente las lecturas y escrituras en la base de datos:

• Lecturas de la base de datos   Multiplique los 60 mensajes diarios por 0,0048, lo que da como resultado 0,288. A continuación, eleve la cantidad de caché de base de datos por buzón (4,66 MB) a la -0,65ª potencia (5 ^ -0,65); el resultado es 0,3622. Por último, multiplique las dos cifras; el resultado es 0,104 lecturas de la base de datos por usuario (0,288 × 0,3622 = 0,104).

• Escrituras de la base de datos   Multiplique el número de mensajes por usuario (60) por 0,00152; el resultado es 0,0912 escrituras en la base de datos por usuario.

La fórmula es:

((0.0048 × M) × (D ^ -0,65)) + (0,00152 × M) = ESPS de base de datos totales

donde M es el número de mensajes y D, la memoria caché de la base de datos por usuario. El número total de ESPS de base de datos por usuario es la suma de las lecturas y las escrituras, en este ejemplo, 0,189 ESPS:

((0.0048 × 60) × (4.66 ^ -0.65)) + (0.00152 × 60) = 0.189

El siguiente gráfico muestra la reducción de escrituras y lecturas de las bases de datos obtenidas al ejecutar Exchange 2007 con 4000 de 250 MB simulando Outlook 2007 en modo caché de Exchange y la memoria de servidor recomendada.

Reducción de IOPS en Exchange Server 2007 comparada con Exchange Server 2003

Efecto de los clientes de modo en línea

A diferencia de los clientes en modo caché de Exchange, todas las operaciones de cliente del modo en línea se realizan contra la base de datos. Como resultados, las operaciones de E/S de lectura aumentan contra la base de datos. Por este motivo, se han establecido las siguientes directivas en caso de que la mayoría de clientes funcione en modo en línea:

• Los clientes del modo en línea de 250 MB aumentarán las operaciones de lectura de la base de datos multiplicándolas por 1,5 comparados con los clientes del modo caché de Exchange. Por debajo de 250 MB, el impacto es insignificante.

• Como el tamaño del buzón se dobla, los IOPS de lectura de la base de datos también lo hacen (asumiendo que se mantiene la misma distribución de elementos entre las carpetas clave).

El siguiente gráfico ilustra el IOPS basado en el tamaño del buzón.

El IOPS de lectura de la base de datos aumenta a medida que aumenta el tamaño del buzón

Las pruebas también han demostrado que aumentar la memoria caché de la base de datos por encima de 5 MB no reducirá significativamente los requisitos de E/S de lectura de la base de datos. El siguiente gráfico muestra los buzones de 2 GB que usan clientes de modo en línea y el efecto que el aumento de la memoria caché por encima de 5 MB tiene sobre los requisitos de E/S de lectura de la base de datos.

El IPOS de lecturas de la base de datos se reduce, el tamaño de la memoria caché por buzón aumenta

Como resultado de estos datos, podemos realizar dos recomendaciones:

• Implemente los clientes del modo caché cuando sea apropiado. Consulte la sección "Número de elementos por carpeta" más adelante para obtener información.

• Asegúrese de que los requisitos de E/S se tienen en cuenta a la hora de diseñar el almacenamiento de la base de datos.

Para factores de IOPS adicionales, como clientes de terceros, consulte Optimización del almacenamiento para Exchange Server 2003 (en inglés).

Proporciones de lectura/escritura de base de datos

En Exchange 2003, la proporción de lectura/escritura de base de datos normalmente es de 2:1 ó 66% de lecturas. Con Exchange 2007, una caché de base de datos mayor reduce el número de lecturas de la base de datos en el disco y hace que las lecturas se reduzcan como un porcentaje de las E/S totales. Si sigue las pautas de memoria recomendadas y usa el modo caché de Exchange, la proporción lectura/escritura estará cerca de 1:1 ó 50% de lecturas.

Cuando use Outlook en el modo en línea, o cuando use motores de búsqueda de escritorio, la proporción lectura/escritura aumentará ligeramente en favor de las lecturas (dependiendo del tamaño del buzón). Tener más escrituras como un porcentaje de las E/S totales tiene implicaciones determinadas al seleccionar un tipo de matriz redundante de discos independientes (RAID) que tenga costos significativos asociados con las escrituras, tales como RAID5 o RAID6. Para obtener más información acerca de cómo seleccionar la solución RAID apropiada para sus servidores, consulte Tecnología de almacenamiento.

Proporción de registro/base de datos

En Exchange 2003, un registro de transacciones para un grupo de almacenamiento requiere aproximadamente el 10% de las E/S de las bases de datos del grupo de almacenamiento. Por ejemplo, si el LUN de la base de datos está usando 1.000 E/S, el LUN del registro usará aproximadamente 100 E/S. Con la reducción de lecturas de base de datos de Exchange 2007, combinada con el menor tamaño de archivo de registro y la capacidad de tener más grupos de almacenamiento, la proporción de escritura registro/base de datos es de aproximadamente 3:4. Por ejemplo, si el LUN de la base de datos consume 500 E/S de escritura, el LUN del registro consumirá aproximadamente 375 E/S de escritura.

Después de medir o predecir las E/S de registro transaccional, aplique un factor de sobrecarga de E/S del 20% para garantizar el margen adecuado para períodos con más trabajo de lo normal. Asimismo, cuando use la replicación continua, los registros de transacción cerrados se deben leer y enviar a una segunda ubicación. Esta sobrecarga es de un 10% adicional en las lecturas de registro. Si el registro de transacción de un grupo de almacenamiento está consumiendo 375 E/S de escritura, puede contar con 37,5 E/S de lectura adicionales cuando use la replicación continua.

Número de elementos por carpeta

En Descripción del impacto que ejercen sobre el rendimiento las cantidades elevadas de elementos y las vistas restringidas se explica cómo afecta el número de elementos de las carpetas críticas y el tipo y el modo de cliente que se utiliza, en el rendimiento del disco de algunos usuarios.

Una forma de reducir las E/S de servidor es usar Outlook 2007 en modo caché de Exchange. La sincronización inicial de los buzones es una operación costosa pero, con el tiempo, a medida que el tamaño del buzón aumenta, la carga del subsistema de discos cambia del servidor de Exchange al cliente de Outlook. Esto quiere decir que tener un gran número de elementos en una bandeja de entrada de usuario o que un usuario haga una búsqueda en un buzón causa poco efecto en el servidor. Esto significa también que los usuarios del modo caché de Exchange con buzones grandes pueden necesitar equipos más rápidos que los que tengan buzones pequeños (dependiendo del umbral de usuario particular para un rendimiento aceptable). Al implementar equipos cliente que ejecutan Outlook 2007 en modo caché de Exchange, tenga en cuenta lo siguiente con relación al tamaño de los archivos /.OST del buzón:

• Hasta 5 gigabytes (GB): este tamaño proporciona buenos resultados al usuario con la mayor parte del hardware.

• Entre 5 GB y 10 GB: este tamaño generalmente depende del hardware. Por ello, si tiene un disco duro rápido y una gran cantidad de memoria RAM, los resultados serán mejores. Sin embargo, los discos duros más lentos, como los que se suelen encontrar en los equipos portátiles, o en las unidades de estado sólido (SSD) de las primeras generaciones, pueden experimentar pausas en la aplicación cuando responden las unidades de disco duro.

• Más de 10 GB: con este tamaño, se empiezan a producir breves pauses en la mayoría del hardware.

• Muy grande, por ejemplo, 25 GB o superior: con este tamaño, aumenta la frecuencia de las pausas breves, sobre todo al descargar nuevo correo electrónico. También se pueden utilizar grupos de envío o recepción para sincronizar el correo electrónico de forma manual.

Si tiene problemas relacionados con el rendimiento con la implementación de Outlook 2007 en modo caché de Exchange, consulte el artículo 940226 de Knowledge Base, Cómo solucionar problemas de rendimiento en Outlook 2007.

Tanto Outlook Web Access como Outlook en modo en línea almacenan índices y búsquedas de la copia de datos del servidor. En buzones de tamaño moderado, esto da como resultado aproximadamente el doble de ESPS por buzón que un cliente en modo caché de Exchange de un tamaño comparable. La IOPS por buzón para buzones grandes es incluso mayor. La primera vez que clasifica una vista de un modo nuevo, se crea un índice, lo que causa muchas E/S de lectura en el LUN de base de datos. Las clasificaciones posteriores de un índice activo son poco costosas.

Una situación que resulta bastante tediosa es cuando un usuario ha superado el número de índices que Exchange almacena, que en Exchange 2007 es de 11 índices. Si el usuario elige realizar la clasificación de una manera nueva, creando así un 12º índice, provoca más E/S de disco. Como el índice no se almacena, el costo de E/S se produce cada vez que se realiza la clasificación. En esta situación también se puede generar una E/S elevada, por lo que es altamente recomendable no almacenar más de 20.000 elementos en las carpetas básicas, como la bandeja de entrada y las carpetas de elementos enviados. La creación de más carpetas de nivel superior, o de subcarpetas bajo las carpetas Bandeja de entrada o Elementos enviados, reducirá significativamente los costos asociados con esta creación de índices, siempre que el número de elementos de las carpetas no supere los 20.000. Para obtener más información acerca de cómo afectará el número de elementos al rendimiento del servidor de buzones, consulte Recommended Mailbox Size Limits (página en inglés) y Descripción del impacto que ejercen sobre el rendimiento las cantidades elevadas de elementos y las vistas restringidas.

Para obtener más información acerca de las mejoras disponibles, consulte el artículo 968009 de Knowledge Base, Mejoras de Outlook 2007 en la actualización de febrero de 2009 acumulativa.

E/S no transaccional

La E/S transaccional se produce en respuesta a una acción directa del usuario y normalmente tiene la prioridad más alta y es el centro del diseño de almacenamiento. La reducción de la E/S transaccional otorga mayor importancia a la E/S no transaccional. Con buzones grandes, especialmente en el caso de buzones de 2 GB, muchas empresas no doblan la capacidad de usuario, pero en algunos casos la aumentan diez veces. Un ejemplo sería pasar de 200 MB a 2 GB. Cuando se produzca un incremento tan significativo en la cantidad de datos en disco, deberá considerar y justificar la E/S no transaccional al planear el diseño de almacenamiento.

Indización de contenido

En Exchange 2007, los mensajes se indizan a medida que se reciben, lo que provoca una sobrecarga de E/S en disco pequeña. La búsqueda en el índice de Exchange 2007 es aproximadamente 30 veces más rápida que en Exchange 2003.

Administración de registros de mensajería

Administración de registros de mensajería (MRM) es una nueva característica de Exchange 2007 que ayuda a los administradores y usuarios a administrar los buzones. Pueden establecerse directivas para mover o eliminar correo que cumpla umbrales determinados, tales como la antigüedad. MRM es una ralentización programada que se ejecuta en la base de datos en una operación de lectura sincrónica similar a la copia de seguridad y al mantenimiento en línea. El costo de disco de la MRM depende del número de elementos que requieran alguna acción (por ejemplo, eliminar o mover).

Se recomienda no ejecutar la MRM a la vez que la copia de seguridad o el mantenimiento en línea. Si usa la replicación continua, puede descargar copias de seguridad VSS (servicio de instantáneas de volumen) a la copia pasiva, lo que permite más tiempo para el mantenimiento en línea y la MRM, de forma que no entren en conflicto y no afecten a los usuarios.

Mantenimiento en línea

Cuando la base de datos ejecuta el mantenimiento en línea se realizan muchas tareas: por ejemplo, se quitan permanentemente los elementos eliminados y se realiza la desfragmentación en línea de la base de datos. El mantenimiento provoca lecturas, mientras que la desfragmentación en línea provoca lecturas y escrituras. El tiempo que se tarda en realizar el mantenimiento es proporcional al tamaño de la base de datos y puede ser un factor que limite el crecimiento de las bases de datos. Para obtener más información acerca del mantenimiento en línea, consulte Procesos de almacenamiento de fondo Parte I (en inglés).

Copia de seguridad y restauración

El administrador tiene a su disposición muchos métodos de copia de seguridad y restauración diferentes. El indicador clave para la copia de seguridad y la restauración es el rendimiento, o el número de megabytes por segundo que pueden copiarse a los LUN de producción y desde ellos. Una vez que haya determinado el rendimiento, tendrá que decidir si es suficiente para cumplir el SLA (Acuerdo de nivel de servicio) de copia de seguridad y restauración. Por ejemplo, si necesita poder completar la copia de seguridad en 4 horas, es posible que necesite agregar más hardware para lograrlo. Dependiendo de su configuración de hardware, existen varias ventajas que pueden lograrse cambiando el tamaño de la unidad de asignación. Esto puede ayudar tanto en las copias de seguridad en línea de transmisión por secuencias como en la comprobación de la integridad de las utilidades de bases de datos de Exchange Server (Eseutil.exe) de Exchange que se produce durante una copia de seguridad VSS.

Con 2.000 usuarios en un servidor, mover un buzón de 200 MB a 2 GB aumenta diez veces el tamaño de la base de datos. Muchos administradores no están acostumbrados a tener que tratar con grandes cantidades de datos en un único servidor. Piense en un servidor con dos 2.000 buzones de 2 GB. Con la sobrecarga descrita anteriormente, son más de 4 terabytes de datos. Suponiendo que puede lograr una velocidad de copia de seguridad de 175 GB por hora (48 MB por minuto), tardará como mínimo 23 horas en realizar la copia de seguridad del servidor. Una alternativa para los servidores que no usen LCR o CCR podría ser llevar a cabo una copia de seguridad completa de 1/7 de las bases de datos cada día y una copia de seguridad incremental del resto, tal como se muestra en la siguiente tabla.

Ejemplo de rutina de copia de seguridad semanal

Tipo de copia de seguridad	Día 1	Día 2	Día 3	Día 4	Día 5	Día 6	Día 7
Completa	DB 1–2	DB 3–4	DB 5–6	DB 7–8	DB 9–10	DB 11–12	DB 13–14
Incremental	DB 3–14	DB 1–2 DB 5–14	DB 1–4 DB 7–14	DB 1–6 DB 9–14	DB 1–8 DB 11–14	DB 1–10 DB 13–14	DB 1-12

Como se ve en la tabla anterior, la cantidad total de datos copiados cada noche es de 650 GB aproximadamente, que podría realizarse en 3,7 horas suponiendo una tasa de 175 GB por hora. Algunas soluciones pueden lograr más o menos rendimiento. Sin embargo, los buzones grandes requieren métodos diferentes.

Con LCR y CCR, la copia pasiva es la primera línea de defensa. Sólo se lleva a cabo la restauración de la copia de seguridad si tanto la copia activa como la copia pasiva dan error o no están disponibles. La recuperación de varios días de registros incrementales puede agregarse al tiempo que tarda la recuperación. Por esta razón, la copia de seguridad incremental rara vez se usa en una solución de recuperación rápida, como los clones de CCR o VSS. En un clon VSS, la recuperación de los datos es rápida y puede ser aceptable agregar un poco de tiempo para reproducir registros a fin de mantener los tiempos de copia de seguridad dentro del SLA de copia de seguridad.

Copia de seguridad en línea de transmisión por secuencias

Con las copias de seguridad de transmisión por secuencias, se aconseja separar las E/S de una transmisión por secuencias (origen y destino) para que varios grupos de almacenamiento de los que se esté realizando la copia de seguridad al mismo tiempo no compitan por los mismos recursos de disco. Tanto si el destino es un disco o una cinta, habrá un límite de rendimiento en los discos físicos y controladores exclusivo para cada solución de hardware. Puede que sea necesario aislar algunos grupos de almacenamiento de otros para maximizar el número de operaciones de copia de seguridad concurrentes y el rendimiento para minimizar el tamaño de la ventana de copia de seguridad. En la siguiente tabla se muestra un ejemplo de dos copias de seguridad simultáneas de 14 bases de datos.

Ejemplo de rutina de copia de seguridad simultánea

Número de copia de seguridad	LUN 1	LUN 2	LUN 3	LUN 4	LUN 5	LUN 6	LUN 7
Primera copia de seguridad	grupo de almacenamiento (SG) 1	SG 2	SG 3	SG 4	SG 5	SG 6	SG 7
Segunda copia de seguridad	SG 8	SG 9	SG 10	SG 11	SG 12	SG 13	SG 14

Puede ejecutar copias de seguridad de transmisión por secuencias simultáneamente, una desde cada LUN, si aísla los LUN de grupo de almacenamiento entre sí, tal como se muestra en la tabla anterior. Los trabajos de copia de seguridad se deben completar en el primer grupo de almacenamiento de cada LUN antes de que el segundo grupo empiece a realizar la copia de seguridad y aislar las secuencias de copia de seguridad. Es posible que dos trabajos de copia de seguridad de transmisión por secuencias en los mismos discos físicos no sean el doble de rápidos, pero deberían ser más rápidos que un solo trabajo de copia de seguridad de transmisión por secuencias en cuando a megabytes por segundo.

Copia de seguridad VSS

Exchange 2007 usa VSS incluido en Windows Server 2003 para realizar instantáneas de volumen de las bases de datos y de los archivos de registro de transacción. Para obtener más información acerca de VSS, incluidas las técnicas de clonación e instantánea, consulte Prácticas recomendadas para usar el servicio de instantáneas de volumen con Exchange Server 2003 (en inglés). Exchange 2007 incluye una característica nueva que permite realizar copias de seguridad VSS de la copia pasiva de grupos de almacenamiento que se ejecuten en un entorno LCR o CCR. En estos entornos, al realizar una instantánea VSS de la copia pasiva, se quita la carga de disco de los LUN activos durante la fase de integridad de suma de comprobación de la copia de seguridad y la copia posterior en cinta o disco. También libera más tiempo en los LUN activos para ejecutar el mantenimiento en línea, la MRM y otras tareas.

LUN y discos físicos

En muchos casos, el disco físico o el LUN que reconoce el sistema operativo se abstrae del hardware usado para presentar el disco al sistema operativo. Por motivos de rendimiento y recuperación, siempre ha sido fundamental separar los archivos de registro de transacciones de los archivos de bases de datos en los niveles de LUN y de disco físico. La mezcla de una E/S en disco aleatoria o secuencial en el mismo disco físico reduce considerablemente el rendimiento y, desde el punto de vista de la recuperación, la separación de los archivos de registro y de base de datos de un grupo de almacenamiento garantiza que un error catastrófico en uno de los discos físicos no provoque la pérdida de los archivos de base de datos y de registro.

En Exchange 2007, es una práctica recomendada ubicar todas las bases de datos en un grupo de almacenamiento del mismo LUN físico. Otra práctica recomendada es no incluir más de una base de datos en cada grupo de almacenamiento. La E/S de base de datos de Exchange es aleatoria y la mayoría de los subsistemas de almacenamiento se benefician de que los discos físicos procesen la misma carga de trabajo. Muchas matrices de almacenamiento se han diseñado de modo que varios discos físicos se agrupan primero en un grupo de discos y, a continuación, se crean LUN a partir del espacio disponible en dicho grupo de discos y se distribuyen equitativamente en cada disco físico. Es aceptable que los discos físicos que realizan una copia de seguridad de los LUN de base de datos del grupo de almacenamiento realicen además una copia de seguridad de otros LUN que incluyen bases de datos para otros grupos y servidores de almacenamiento. Además, no es imprescindible aislar cada LUN de registro de transacciones del grupo de almacenamiento en rotaciones físicas independientes incluso aunque la pérdida de E/S secuencial afecte ligeramente al rendimiento.

En caso de que se configure un máximo de 50 grupos de almacenamiento en un solo servidor, cada grupo de almacenamiento obtendrá su propio LUN de registro de transacciones y de base de datos. Esto supera el número de letras de unidad disponibles y se deben usar puntos de montaje de volumen del sistema de archivos NTFS. La configuración de 50 grupos de almacenamiento para la replicación continua requiere 200 LUN, lo que supera la capacidad máxima de algunas matrices de almacenamiento, sobre todo en el caso de la LCR, donde los 200 LUN se deben presentar en un solo servidor. A medida que aumenta el número de LUN, la supervisión adquiere mayor importancia debido a que la falta de espacio en disco puede provocar el desmontaje del grupo de almacenamiento.

Diseño LUN

En muchos casos, el LUN que reconocen el sistema operativo se abstrae del hardware físico que hay realmente detrás de ese disco. Siempre ha sido fundamental separar los registros de transacciones de la base de datos en los niveles de LUN y de disco físico por motivos de rendimiento y recuperación. En algunas matrices de almacenamiento, la mezcla de una E/S aleatoria y secuencial en los mismos discos físicos puede reducir el rendimiento. Desde el punto de vista de recuperación, la separación de los registros de transacciones de un grupo de almacenamiento y las bases de datos garantiza que un error catastrófico de un conjunto determinado de discos físicos no cause una perdida de la base de datos y los registros de transacciones.

La E/S de base de datos de Exchange es aleatoria y la mayoría de los subsistemas de almacenamiento se benefician de que los discos físicos procesen la misma carga de trabajo. Muchas matrices de almacenamiento usan el almacenamiento virtual de modo que varios discos físicos se agrupan primero en un grupo de discos y, a continuación, los LUN se crean a partir del espacio disponible en dicho grupo de discos y se distribuyen equitativamente entre todos los discos físicos. Cuando no se usa la replicación continua, es aceptable que los discos físicos que realizan una copia de seguridad de los LUN de base de datos del grupo de almacenamiento realicen además una copia de seguridad de otros LUN que incluyen bases de datos para otros grupos y servidores de almacenamiento. Además, no es imprescindible aislar cada LUN de registro de transacciones del grupo de almacenamiento en rotaciones físicas independientes incluso aunque la pérdida de E/S secuencial afecte ligeramente al rendimiento. Es importante separar el registro y los LUN de la base de datos del mismo grupo de almacenamiento en discos físicos independientes. No es realista dedicar dos o cuatro discos físicos de 500 GB a un único LUN de registro de transacciones de un grupo de almacenamiento si necesita 30 ESPS y el 5% de la capacidad.

Pese a que existen muchas formas de diseñar los LUN en Exchange 2007, recomendamos los dos diseños siguientes para limitar la complejidad:

• Dos LUN por grupo de almacenamiento

• Dos LUN por conjunto de copia de seguridad

Dos LUN por grupo de almacenamiento

La creación de dos LUN (uno para registros y otro para bases de datos) para un grupo de almacenamiento era la práctica estándar recomendada en Exchange 2003. En Exchange 2007, y en caso de un máximo de 50 grupos de almacenamiento, el número de LUN que aprovisione dependerá de la estrategia de copia de seguridad. Si su RTO es pequeño, o si usa clones de VSS para una recuperación rápida, puede que sea mejor colocar cada grupo de almacenamiento en su propio LUN de registro de transacción y su propio LUN de base de datos. Esta operación superará el número de letras de unidad disponibles, por lo que deberá usar puntos de montaje de volumen.

Entre las ventajas de esta estrategia se incluyen:

• Permite los VSS basados en hardware en un nivel de grupo de almacenamiento, lo que proporciona una copia de seguridad y restauración de un único grupo de almacenamiento.

• Flexibilidad para aislar el rendimiento entre grupos de almacenamiento.

• Fiabilidad aumentada. Un problema de capacidad, daño o virus en un único LUN sólo afectará a un grupo de almacenamiento.

Entre los problemas de esta estrategia se incluyen:

• Cincuenta grupos de almacenamiento que usen la replicación continua podrán necesitar 200 LUN, lo que superaría algunos máximos de matrices de almacenamiento, especialmente en el caso de la LCR, en la que sería necesario 200 LUN para un único servidor.

• Un LUN independiente para cada grupo de almacenamiento causa más LUN por servidor, lo que aumenta los costos administrativos.

Dos LUN por conjunto de copia de seguridad

Un conjunto de copias de seguridad es el número de bases de datos de las que se hace la copia de seguridad completa en una noche. Una solución que realice una copia de seguridad completa de 1/7 de las bases de datos por la noche podría reducir la complejidad colocando todos los grupos de almacenamiento de los que se va a realizar la copia de seguridad en el mismo LUN de registro y de base de datos. De este modo puede reducirse el número de LUN del servidor.

Entre las ventajas de esta estrategia se incluyen:

• Administración de almacenamiento simplificada debido a que hay menos LUN que administrar.

• Reducción potencial del número de trabajos de copia de seguridad.

Entre los problemas de esta estrategia se incluyen:

• Limitación de la posibilidad de realizar copias de seguridad y restauraciones VSS basadas en hardware.

• Limitación de la escalabilidad de la capacidad de esta estrategia, debido al límite de 2 terabytes de la partición de registro de arranque maestro (MBR).

Puntos de montaje de volumen

Hay muchos casos, por ejemplo en clústeres de copia única de varios nodos (SCC), en los que se necesitan más LUN que las letras de unidad que hay disponibles. En estos casos, debe usar puntos de montaje de volumen. Las letras de unidad son una función heredada del sistema operativo MS-DOS para reconocer particiones o discos y es preferible evitar el uso de demasiadas letras de unidad. Es mucho más sencillo colocar todos los LUN de registro de transacción y de base de datos en un punto de montaje de volumen para facilitar la administración. Si tiene 20 grupos de almacenamiento, cada uno con una base de datos, es difícil recordar la letra asignada a la base de datos 17. En la tabla siguiente se muestra un ejemplo de uso de puntos de montaje de volumen.

Diseño de carpeta de ejemplo con puntos de montaje de volumen

Registros de transacciones (L:)	Bases de datos (P:)
L:\SG1LOG	P:\SG1DB
L:\SG2LOG	P:\SG2DB
L:\SG3LOG	P:\SG3DB
L:\SG4LOG	P:\SG4DB

En este ejemplo, L: y P: son LUN ancla que hospedan todos los LUN de registro y de base de datos respectivamente. Cada carpeta de estas unidades es un punto de montaje de volumen para un LUN diferente.

VSS basado en hardware

Cuando use un VSS basado en hardware, existen varias recomendaciones para colocar los datos de Exchange en los LUN. En una solución VSS basada en hardware, cada LUN de registro de transacción y de base de datos sólo deberá hospedar los archivos del conjunto de copias de seguridad elegido. Si desea restaurar un grupo de almacenamiento sin repercutir en ningún otro grupo de almacenamiento, necesitará un LUN de registro de transacciones y un LUN de registro de base de datos independientes para cada grupo de almacenamiento. Si está dispuesto a adoptar otras bases de datos y grupos de almacenamiento sin conexión para restaurar una única base de datos, coloque varios grupos de almacenamiento en un único LUN de registro de transacciones y en un LUN de base de datos.

VSS basado en software

Cuando use VSS basado en software, especialmente con buzones grandes y replicación continua, su copia de seguridad será una estrategia de dos pasos. En primer lugar, realice una instantánea VSS y, a continuación, transmita los archivos planos al disco o cinta.

Fiabilidad de LUN

Siempre es importante colocar los registros de transacción y las bases de datos de un grupo de almacenamiento en discos físicos independientes ya que, al hacerlo, aumenta la fiabilidad. Con la replicación continua, también es importante separar los LUN activos y pasivos en medios de almacenamiento completamente separados. Con CCR y LCR, es conveniente contar con una resistencia de almacenamiento en caso de error catastrófico del almacenamiento primario.

Ejemplo de LUN

Tenga en cuenta la situación siguiente, basada en el ejemplo de capacidad anterior y que aplica dicha información a la creación de un LUN. En este ejemplo, el régimen de copia de seguridad es una copia de seguridad diaria completa. Se desea habilitar la indización de contenido, y colocará en el LUN de la base de datos. El 5% de 193 GB es, aproximadamente, 10 GB. Se debe agregar esta cifra al tamaño final de LUN. El factor de crecimiento para 193 GB debería ser el 20% del tamaño final de la base de datos. El 20% de 193 GB es aproximadamente 39 GB. Los resultados se muestran en las tablas siguientes.

Valores de ejemplo para determinar el tamaño del LUN de la base de datos

Tamaño de la base de datos	Factor de crecimiento	Indización de contenido	Tamaño de LUN de la base de datos
193 GB	39 GB	10 GB	241 GB

Cada grupo de almacenamiento crea 7,13 GB de registros al día y se desea almacenar, como mínimo, los registros de 3 días.

Valores de ejemplo para determinar el tamaño del LUN del registro

Registros (1 día)	Registros (3 días)
7,13 GB	21,4 GB

Mover buzón

La organización de ejemplo mueve el 5% de los buzones por semana y realiza los desplazamiento el sábado. Por lo tanto, el LUN de registros debe controlar toda la carga en un día. Una de las estrategias de movimiento de buzón usada en Microsoft consiste en distribuir los usuarios entrantes equitativamente entre todos los grupos de almacenamiento. Esto significa que el servidor de ejemplo con 4.000 usuarios moverá, aproximadamente, 400 usuarios cada sábado. Si hay 23 grupos de almacenamiento, cada grupo de almacenamiento debe recibir 17 buzones de 1 GB, como se muestra en la siguiente tabla.

Valores de ejemplo para determinar el tamaño del LUN del registro de mover buzón

Registros (3 días)	Movimientos de buzones	Tamaño del LUN de registro
21,4 GB	17,64 GB (17 usuarios de 1 GB)	46,6 GB (38,8 GB + 20%)

Con este diseño, nunca se moverán más de 17 usuarios a un grupo de almacenamiento en un solo día. Por lo tanto, quizá sea preferible aumentar el tamaño del LUN de registro por si necesita mover más del 10% un día determinado.

Impacto de la replicación continua en el diseño del almacenamiento

La replicación continua es un función nueva de Exchange 2007 en que los archivos de base de datos y registro de un grupo de almacenamiento se copian en una ubicación secundaria. A medida que se cierran o llenan los registros de transacciones, se copian en una ubicación secundaria, validada y reproducida en una copia pasiva de la base de datos. Para garantizar la resistencia del almacenamiento, se recomienda ubicar la copia pasiva en una matriz de almacenamiento totalmente aislada de los LUN de producción activos. Dado que depende de la copia pasiva para procesar la carga de producción en caso de error, su almacenamiento se debe corresponder con el rendimiento y la capacidad de la solución de almacenamiento usada por la copia activa del grupo de almacenamiento.

Cada grupo de almacenamiento sólo puede contener una base de datos al usar la replicación continua de modo que cada copia de la base de datos requiera cuatro LUN. Cada copia de la base de datos se encuentra en su propio grupo de almacenamiento, que necesita un LUN de registro y base de datos independiente para la copia activa y otro LUN de registro y base de datos independiente para la copia pasiva.

Es una práctica recomendada:

• Separar el almacenamiento en LUN individuales en el nivel de hardware y no crear varias particiones lógicas de un LUN en el sistema operativo.

• Separar los registros de transacciones y las bases de datos y hospedarlos en discos físicos independientes para aumentar la tolerancia a errores.

• Separar los LUN activos y pasivos en matrices de almacenamiento totalmente distintas para que el almacenamiento no se a un punto de error único.

• Si hospeda grupos de almacenamiento o bases de datos de varios servidores de buzones de correo en clúster en la misma matriz de almacenamiento, debe asegurarse de que cada LU se cree usando discos físicos diferentes.

El diseño del almacenamiento debe maximizar la tolerancia a errores mediante la separación de los controladores de almacenamiento en un bus de interconexión de componentes periféricos (PCI) distinto. Además, debe diseñar el almacenamiento para la copia pasiva de modo que se corresponda con el almacenamiento usado por la copia activa en términos de capacidad y rendimiento. El almacenamiento de la copia pasiva es la primera línea de defensa en caso de error catastrófico del almacenamiento de la copia activa y, en caso de conmutación por error, la copia pasiva se convierte en la copia activa. La inclusión de los LUN de la copia pasiva en un hardware de almacenamiento completamente distinto garantiza que las acciones realizadas en la copia pasiva no afectan a la copia activa.

Con la replicación continua, se producen más E/S transaccionales. Este factor se debe tener en cuenta al determinar el tamaño del servidor. El registro de transacciones activo, que consiste en una escritura secuencial, también debe leer el registro una vez cerrado y copiado en la carpeta en cuarentena de LUN de registro de transacciones. A continuación, el registro se debe revisar en la ubicación de la replicación y mover a su destino final en el LUN de replicación. Finalmente, el registro se lee y reproduce en la base de datos. Los LUN de registro de transacciones activos y de replicación se deben leer y escribir frente a la actividad de escritura secuencial de casi el 100 por ciento de un servidor de buzones independiente. Este cambio en el comportamiento puede requerir una evaluación de la configuración de la memoria caché en el controlador de almacenamiento. La configuración recomendada es del 25 por ciento de lectura y del 75 por ciento de escritura en un controlador de almacenamiento con batería.

Replicación continua y tamaño de base de datos

Es posible usar un tamaño de base de datos máximo mayor si se usa la replicación continua. Recomendamos los tamaños de base de datos máximos siguientes para Exchange 2007:

• Bases de datos hospedadas en un servidor de buzones sin replicación continua: 100 GB

• Bases de datos hospedadas en un servidor de buzones con replicación continua y Gigabit Ethernet: 200 GB

  Nota

  Es posible que las grandes bases de datos también requieran una tecnología de almacenamiento nueva para un mayor ancho de banda para las situaciones de reparación.

  Importante

  El tamaño máximo real de las bases de datos está determinado por el SLA vigente de la organización. Para determinar el tamaño máximo de las bases de datos, debe determinar el tamaño máximo de base de datos que se puede copiar y restaurar en el período de tiempo especificado en el SLA de la organización.

Opciones de almacenamiento LCR

LCR permite el envío de registros en un solo servidor. En caso de error catastrófico del almacenamiento que incluye la copia activa de los archivos de base de datos o registro, el administrador puede activar manualmente la copia pasiva de la base de datos. El almacenamiento de la copia pasiva debe estar totalmente separado del almacenamiento de la copia activa. Además:

• Las tarjetas controladoras deben estar en un bus PCI distinto.

• Cada solución de almacenamiento debe tener su propio sistema de alimentación ininterrumpida (SAI).

• Cada solución de almacenamiento debe estar en un circuito de alimentación independiente.

Opciones de almacenamiento CCR

CCR permite el envío de registros a un nodo pasivo en un clúster de conmutación por error activo o pasivo. Al enviar los registros a una copia pasiva y mantener dicha copia en un servidor distinto, el impacto operativo en el nodo activo se reduce y dispone de tolerancia a errores en el servidor.

En una implementación de CCR dispersa geográficamente, la copia pasiva puede estar en un nodo que se encuentra en una ubicación física distinta de la del nodo activo y, por tanto, proporcionar resistencia en el sitio. Aunque la información del artículo sobre las directrices de implementación para la replicación de datos en varios sitios para Exchange Server (en inglés) se sigue aplicando, la tecnología basada en la extracción de la replicación continua implica que una latencia alta no afecta a la experiencia del usuario. Esto contrasta en gran medida con la solución de clústeres dispersos geográficamente dado que la latencia de la replicación sincrónica afecta negativamente al servidor activo. Con CCR, el proceso de replicación puede ejecutarse de forma subyacente, lo que aumenta la cantidad de tiempo durante el cual no están sincronizadas la copia activa y la copia pasiva. Sin embargo, si un desastre afecta a la copia activa, los mensajes no replicados en el nodo pasivo no se pueden recuperar debido a la función de contendor de transporte del servidor de transporte de concentradores.

Opciones de almacenamiento de clúster de copia única

El hardware usado para un SCC se debe incluir en la categoría de clúster del catálogo de servidor de Windows. El hardware usado para los SCC dispersos geográficamente se debe incluir en la categoría de clústeres dispersos geográficamente del catálogo de servidor de Windows para ser compatible.

Un servidor de buzones de correo en clúster que use un almacenamiento compartido presenta las mismas consideraciones por lo que respecta al almacenamiento que un servidor independiente. Si se usa la replicación sincrónica, la latencia de disco puede aumentar de forma artificial por el proceso de replicación. Se recomienda maximizar los puntos de replicación en la matriz de almacenamiento. Para obtener más información acerca de la replicación de SCC, consulte la página que incluye las Directrices de implementación para la replicación de datos en varios sitios para Exchange Server (en inglés).