Recomendaciones para configurar el almacenamiento de servicios de fondo de Exchange

 

Última modificación del tema: 2006-05-09

Hay algunas recomendaciones que resultan útiles para ampliar la disponibilidad de los datos de Exchange en los servidores de servicios de fondo:

• Configuración de grupos de almacenamiento   Diseñe las configuraciones de grupos de almacenamiento y bases de datos para aumentar al máximo el rendimiento y la capacidad de recuperación.
• Dimensionamiento del almacenamiento del servidor de buzones   Calcule el tamaño de las bases de datos para garantizar una capacidad de recuperación y un rendimiento adecuados.
• Creación de particiones en el servidor de servicios de fondo   Almacene los archivos del sistema operativo Windows, los archivos de aplicaciones y de base de datos de Exchange, y los archivos de registro de transacciones en discos diferentes para mejorar la tolerancia a errores y optimizar la recuperación.
• Almacenamiento de datos de Exchange   Implemente soluciones de RAID en los discos para que coincidan con los tipos de datos de cada disco.
• Espacio en disco duro   Asegúrese de que tiene suficiente espacio en disco como para garantizar el rendimiento y la capacidad de recuperación.
• Rendimiento de disco y de E/S   Considere el rendimiento del disco duro como parte de la solución de almacenamiento.
• Desfragmentación de discos   Desfragmente los discos mediante la desfragmentación con conexión y, si es necesario, la desfragmentación sin conexión.
• Optimización de la memoria virtual   Considere la posibilidad de ajustar el servidor para garantizar una transferencia de mensajes eficiente y confiable.

Hay otras formas de mejorar la disponibilidad y el rendimiento de los servidores de servicios de fondo de Exchange 2003. Para obtener información acerca del ajuste de servidores de servicios de fondo de Exchange 2003, consulte la Guía de rendimiento y escalabilidad de Exchange Server 2003 (en inglés).

Configuración de grupos de almacenamiento

El almacén de Exchange utiliza dos tipos de bases de datos: almacenes de buzones y almacenes de carpetas públicas. Estos almacenes se organizan en grupos de almacenamiento. Todas las bases de datos de un grupo de almacenamiento comparten un único conjunto de archivos de registro de transacciones, un único programa de copia de seguridad y un único conjunto de parámetros para las utilidades de registro y copia de seguridad.

La estrategia de recuperación de desastres desempeña un papel importante a la hora de determinar el número de grupos de almacenamiento y de bases de datos que su solución de almacenamiento debe admitir. En concreto, el plan de recuperación debe indicar los requisitos de tiempo de restauración de la empresa. Éste es el requisito que dirige la configuración de almacenamiento. La forma de configurar los grupos de almacenamiento depende de la edición de Exchange 2003 que utilice:

• Si utiliza Exchange Server 2003 Standard Edition, cada servidor de Exchange puede tener un grupo de almacenamiento que contenga un almacén de buzones y un almacén de carpetas públicas.
• Si utiliza la versión Exchange Server 2003 Enterprise Edition, cada servidor puede tener hasta cuatro grupos de almacenamiento, cada uno de los cuales podrá contener hasta cinco bases de datos (ya sean almacenes de buzones o de carpetas públicas).

Tanto si utiliza Exchange Server 2003 Standard Edition como Exchange Server 2003 Enterprise Edition, puede crear un grupo de almacenamiento de recuperación además de los grupos de almacenamiento habituales. Los grupos de almacenamiento de recuperación se utilizan para recuperar información del buzón cuando se restauran datos a partir de una copia de seguridad. Para obtener información acerca de grupos de almacenamiento de recuperación, consulte Using Exchange Server 2003 Recovery Storage Groups (en inglés).

Almacenamiento de buzones

Si utiliza Exchange Server 2003 Enterprise Edition, puede emplear varios almacenes de buzones para aumentar la confiabilidad y la capacidad de recuperación de la organización de Exchange. Si los usuarios están diseminados por diversos almacenes de buzones, la pérdida de un único almacén sólo afectará a un subconjunto de usuarios, no a toda la organización. Además, la disminución del número de buzones por almacén reduce el tiempo necesario para recuperar un almacén dañado a partir de una copia de seguridad.

Almacenamiento de carpetas públicas

Para dispersar carpetas públicas en varios servidores puede utilizar varios almacenes de carpetas públicas. Además, para aumentar la capacidad del sistema para administrar el tráfico de usuarios puede colocar varias réplicas de la misma carpeta en varios servidores. Si tiene varios grupos de enrutamiento, quizás desee distribuir las carpetas entre esos grupos. De esta forma los usuarios tendrán un acceso sencillo a las carpetas que utilizan con más frecuencia.

Dimensionamiento del almacenamiento del servidor de buzones

Antes de seleccionar las opciones de diseño de servicio para los servidores de buzones debe determinar primero cuántos datos necesita almacenar. Si determina con precisión los volúmenes existentes y previstos de los datos de correo, puede diseñar correctamente los sistemas de almacenamiento de forma que no tenga que ampliarlos inmediatamente después de realizar la implementación.

Utilice la fórmula siguiente para calcular la cantidad de datos que puede almacenar en un único servidor:

(Número de buzones × tamaño máximo del límite de buzón) × factor de ajuste

El factor de ajuste (por ejemplo, un valor como 1,5) aporta espacio adicional para los datos que no se cuentan en las cuotas de buzones, incluyendo mensajes que se encuentran en el almacén de retención de elementos eliminados y en el almacén de retención de buzones eliminados. Las cuotas establecen patrones de uso del espacio mucho más previsibles. En los entornos de Exchange en los que no se utilizan cuotas de buzones, la habilitación de cuotas es una consideración importante. Además, la creación de bases de datos de buzones diferentes y el uso de varias directivas del sistema con distintos límites de cuota simplifica el proceso administrativo.

Puede utilizar todo el volumen de datos para hacer una estimación del espacio de disco que se necesita para el servidor. Sin embargo, el cálculo de esta estimación depende de cuántas bases de datos de buzones se vayan a alojar en el servidor.

Consideraciones de rendimiento para la copia de seguridad y la restauración

En Exchange 2003 Enterprise Edition no hay ningún límite establecido en cuanto al tamaño de una base de datos individual. La falta de límites integrados dificulta la decisión sobre el tamaño del servidor y cómo dividir los datos entre las bases de datos. Por tanto, para determinar cómo se deben dimensionar y dividir los datos del servidor, tenga en cuenta primero lo siguiente:

• ¿Cuáles son sus requisitos de tiempo para restaurar una única base de datos?
• ¿Cuál es la rapidez del mecanismo de restauración que ha elegido?

Para ilustrar este proceso, tenga en cuenta la situación siguiente:

Un SLA que ofrece un tiempo máximo de interrupción del servicio de cuatro horas se combina con un sistema de copia de seguridad que puede hacer copia de seguridad y restauración de 75 GB por hora. Como las recuperaciones suelen tardar en promedio el doble de tiempo que las copias de seguridad, el tamaño máximo de todos los datos de un servidor sería 150 GB. (Estos 150 GB representan la cantidad de datos que sería viable restaurar dentro de la ventana de dos horas).

Una vez determinado el tamaño máximo, debe decidir cómo dividir los 150 GB en bloques más pequeños. Como todos los usuarios del servidor están en una base de datos, la colocación de todos los datos en una única base de datos no aporta ninguna flexibilidad. La decisión no consiste en establecer particiones o no, sino en cuántas particiones utilizar. Una solución habitual sería tomar el tamaño máximo de datos del servidor y dividirlo equitativamente entre el número de bases de datos. Por ejemplo, podría dividir una base de datos de 150 GB en cinco bases de datos de 30 GB (siendo cinco el número máximo de bases de datos que puede haber dentro de un único grupo de almacenamiento). Desgraciadamente, esta solución impide realizar copias de seguridad y restauraciones simultáneas de varias bases de datos. Esta solución también impide montar bases de datos adicionales para realizar pruebas o reparaciones. Una solución mejor sería utilizar varios grupos de almacenamiento (en este caso, dos grupos de almacenamiento con cuatro bases de datos cada uno), donde cada base de datos podría utilizar unos 20 GB. Esta solución permitiría hacer copia de seguridad de dos bases de datos de distintos grupos de almacenamiento o restaurarlas simultáneamente (siempre y cuando disponga del hardware de copia de seguridad adecuado). Además, el pequeño tamaño de archivo de las bases de datos le permite mover fácilmente los archivos entre distintos volúmenes o servidores.

Consideraciones de almacenamiento de instancia única

También es importante que diseñe cómo agrupará los buzones en bases de datos de buzones. Como Exchange puede mantener un almacenamiento de instancia única dentro de las bases de datos individuales, los usuarios de un grupo de trabajo se mantienen en la misma base de datos siempre que es posible. Con el almacenamiento de instancia única puede restaurar ciertos grupos de usuarios más rápidamente. Por ejemplo, imagine un banco cuyas operaciones en divisas requieren mayores niveles de disponibilidad que las restantes operaciones. Utilizando el ejemplo anterior de un servidor de 150 GB, la creación de un grupo de almacenamiento adicional con una base de datos sólo para los buzones de los operadores de divisas permitiría unos procesos de copia de seguridad y restauración más rápidos. Para los buzones críticos, otra opción sería utilizar el servicio de instantáneas de volumen para ofrecer recuperaciones todavía más rápidas. Así se reduce la desventaja en cuanto a costo que suponen los requisitos de hardware del servicio de instantáneas de volumen.

Recomendaciones para crear particiones en los servidores de servicios de fondo

Para mejorar la tolerancia a errores y simplificar la solución de problemas debe crear particiones en los discos de forma que los archivos siguientes se encuentren en discos diferentes:

• Archivos de Windows Server 2003
• Archivos de aplicación de Exchange
• Archivos de base de datos de Exchange
• Archivos de registro de transacciones de Exchange

En general, la creación de estas particiones en los discos duros puede mejorar el rendimiento y reducir la cantidad de datos que debe restaurar. En el resto de esta sección se describen las ventajas que supone colocar cada uno de estos archivos en discos diferentes.

Ventajas de poner los archivos de aplicación de Exchange y los archivos de Windows Server 2003 en sus propios discos

La colocación de los archivos de aplicación de Exchange y de los archivos de Windows Server 2003 en sus propios discos presenta las ventajas siguientes:

• Mayor rendimiento   TSe consiguen mejoras de rendimiento notables en los servidores de Exchange 2003. Por ejemplo, el servidor puede leer archivos de Windows o de Exchange en cualquier orden que sea necesario sin mover el cabezal de la unidad de disco tanto como si las aplicaciones estuvieran en un disco.
• Mayor tolerancia a errores   Un único punto de error ya no supone ningún problema. Por ejemplo, si se produce un error en los discos donde se instaló Exchange 2003, Windows Server 2003 seguirá funcionando.

Ventajas de poner los archivos de base de datos y de registro de transacciones de Exchange en sus propios discos

En Exchange, el acceso a los archivos de registro de transacciones es secuencial, mientras que el acceso a las bases de datos es aleatorio. De acuerdo con los principios generales de almacenamiento, debe separar los archivos de registro de transacciones (E/S secuencial) de las bases de datos (E/S aleatoria) para maximizar el rendimiento de E/S y aumentar la tolerancia a errores. El almacenamiento separado de los archivos a los que se tiene acceso secuencialmente mantiene los cabezales de disco en un orden de entrada/salida secuencial, lo que reduce el tiempo necesario para localizar los datos. En concreto, debe mover cada conjunto de archivos de registro de transacciones a su propia matriz, separándolos de los grupos de almacenamiento y las bases de datos.

De manera predeterminada, Exchange almacena los archivos de base de datos y los archivos de registro de transacciones en la carpeta siguiente:

unidad:\Archivos de programa\Exchsrvr\MDBDATA

Esta carpeta existe en la misma partición en la que se instala Exchange 2003.

La colocación de los archivos de registro de transacciones y de los archivos de base de datos de Exchange en discos diferentes presenta las ventajas siguientes:

• Administración simplificada de los datos de Exchange   Se asigna una letra de unidad diferente a cada conjunto de archivos. El hecho de tener cada conjunto de archivos representado por su propia letra de unidad le ayuda a hacer un seguimiento de las particiones de las que debe hacer copias de seguridad de acuerdo con su método de recuperación de desastres.
• Mayor rendimiento   Mejora considerablemente el rendimiento de E/S de disco duro.
• Menor impacto de un desastre   Dependiendo del tipo de error de que se trate, la colocación de las bases de datos y los grupos de almacenamiento en discos diferentes puede reducir considerablemente la pérdida de datos. Por ejemplo, si guarda los archivos de registro de transacciones y las bases de datos de Exchange en el mismo disco duro físico y se producen errores en este disco, sólo podrá recuperar los datos existentes en la última copia de seguridad. Para obtener más información, consulte "Considering Locations of Your Transaction Log Files and Database Files" en Exchange Server 2003 Disaster Recovery Planning Guide (en inglés).

En la tabla y en la figura siguientes se ilustra un posible esquema de particiones de un servidor de Exchange que dispone de seis discos duros, incluidos dos grupos de almacenamiento que contienen cuatro bases de datos cada uno. Como el número de discos duros y de grupos de almacenamiento del servidor de Exchange puede ser diferente de los utilizados en este ejemplo, aplique la lógica de este ejemplo que sea conveniente de acuerdo con su configuración de servidor. En la tabla siguiente, tenga en cuenta que las unidades E, F, G y H pueden designar dispositivos de almacenamiento externos.

Esquema de particiones del disco duro en Exchange

Disco	Configuración de la unidad
Disco duro 1	Unidad C (NTFS): archivo de intercambio y archivos del sistema operativo Windows.
Disco duro 2	Unidad D (NTFS): aplicaciones adicionales del servidor y archivos de Exchange (como los kits de recursos y el software antivirus).
Disco duro 3	Unidad E (NTFS): archivos de registro de transacciones para el grupo de almacenamiento 1.
Disco duro 4	Unidad F (NTFS): archivos de bases de datos para el grupo de almacenamiento 1.
Disco duro 5	Unidad G (NTFS): archivos de registro de transacciones para el grupo de almacenamiento 2.
Disco duro 6	Unidad H (NTFS): archivos de bases de datos para el grupo de almacenamiento 2.

Tanto si almacena los archivos de base de datos de Exchange en un servidor como en una solución de almacenamiento avanzada como una SAN, puede aplicar las recomendaciones sobre las particiones presentadas en esta sección. Además, debe incorporar tecnologías como reflejo de disco (RAID-1) y seccionado de disco con paridad (RAID-5 o RAID-6, dependiendo del tipo de datos que se esté almacenando).

Para obtener más información acerca de los archivos de registro de transacciones, las bases de datos y los grupos de almacenamiento de Exchange 2003, consulte “Understanding Exchange 2003 Database Technology” Exchange Server 2003 Disaster Recovery Planning Guide (en inglés).

Almacenamiento de datos de Exchange

Esta sección contiene información que le ayudará a configurar correctamente la ubicación y los niveles de RAID para los siguientes tipos de datos de Exchange:

• Archivos de las bases de datos (archivos .edb y .stm)
• Archivos de registro de transacciones
• Datos del directorio de la cola SMTP
• Archivos de indización de contenido

Archivos de base de datos

Una base de datos de Exchange consta de un archivo .edb de texto enriquecido y un archivo .stm de contenido de Extensiones multipropósito de correo Internet (MIME).

El archivo .edb contiene los siguientes elementos:

• Todos los mensajes MAPI
• Las tablas utilizadas por el proceso Store.exe para localizar todos los mensajes
• Sumas de comprobación de los archivos .edb y .stm
• Punteros hacia los datos del archivo .stm

El archivo .stm contiene los mensajes que se transmiten con su contenido de Internet nativo. Como el acceso a estos archivos suele ser aleatorio, pueden situarse en el mismo disco.

De manera predeterminada, Exchange almacena los archivos de base de datos en la siguiente carpeta:

unidad:\Archivos de programa\Exchsrvr\MDBDATA

Esta carpeta existe en la misma partición en la que se instala Exchange 2003.

Consideraciones sobre los archivos de base de datos

Cuando diseñe la solución de almacenamiento para estos archivos, implemente una solución que garantice confiabilidad. RAID-0 no es una opción recomendada. Después de la confiabilidad, la solución de almacenamiento depende de la decisión entre optimizar el rendimiento (RAID-1) y optimizar la capacidad (RAID-5). Si es posible, utilice RAID-1 (o RAID-0+1) para estos archivos.

Puede almacenar carpetas públicas en una matriz RAID-5, ya que los datos de las carpetas públicas normalmente se escriben una vez y se leen varias veces. RAID-5 proporciona un rendimiento de lectura mejorado.

Archivos de registro de transacciones

La característica más importante de un grupo de almacenamiento son sus registros de transacciones. Incluso si utiliza sólo el Primer grupo de almacenamiento predeterminado, debe asegurarse de que la configuración del registro de transacciones es segura para que pueda recuperar la información en caso de producirse daños en los almacenes.

En el registro de transacciones estándar de Exchange, cada transacción de almacén (como crear o modificar un mensaje) de un grupo de almacenamiento se escribe en un archivo de registro y después en el almacén de Exchange. Todos los almacenes de un grupo de almacenamiento comparten un único conjunto de registros de transacciones. El proceso de registro asegura la existencia de los registros de las transacciones si un almacén resulta dañado entre la realización de copias de seguridad. En numerosas ocasiones, la recuperación de un almacén dañado supone tener que restaurar el almacén desde una copia de seguridad, reproducir todos los archivos de registro de los que se haya efectuado una copia de seguridad y reproducir los archivos de registro más recientes para recuperar las transacciones realizadas con posterioridad a la última copia de seguridad.

Si se produce un desastre y debe reconstruir un servidor, utilice los últimos archivos de registro de transacciones para recuperar las bases de datos. Si tiene acceso a la última copia de seguridad y a los archivos de registro de transacciones posteriores a la copia de seguridad, podrá recuperar todos los datos. Sin embargo, si perdió algún archivo de registro de transacciones, se perderán definitivamente los datos que no se hubieran confirmado en la base de datos desde que se hizo la última copia de seguridad.

De manera predeterminada, Exchange almacena los archivos de registro de transacciones datos en la siguiente carpeta:

unidad:\Archivos de programa\Exchsrvr\MDBDATA

Esta carpeta existe en la misma partición en la que se instala Exchange 2003.

Consideraciones sobre los archivos de registro de transacciones

Cuando piense la ubicación de los archivos de registro de transacciones de Exchange, tenga en cuenta lo siguiente:

• El rendimiento y la tolerancia a errores de los servidores de Exchange se pueden mejorar significativamente si se coloca cada conjunto de archivos de registro de transacciones en una unidad distintas.
• Como cada grupo de almacenamiento tiene su propio conjunto de archivos de registro de transacciones, el número de unidades dedicadas a los registros de transacciones del servidor debe coincidir con el número planeado de grupos de almacenamiento. Con una solución de SAN puede seleccionar un producto para repartir fácilmente el espacio virtualizado en unidades virtuales diferentes para los grupos de almacenamiento y los archivos de registro de transacciones.
• Además, dado que los archivos de registro de transacciones son críticos para el funcionamiento de un servidor, debe proteger las unidades de posibles errores. La mejor solución para esto es realizar reflejos de hardware mediante RAID. Se recomienda una configuración de RAID-0+1 (en la que los datos se reflejan y, a continuación, se seccionan).

A continuación se ofrece un ejemplo de configuración de disco:

• C:\ Sistema e inicio (conjunto reflejado)
• D:\ Archivo de paginación
• E:\ Archivos de registro de transacciones para el grupo de almacenamiento 1 (conjunto de reflejos)
• F:\ Archivos de registro de transacciones para el grupo de almacenamiento 2 (conjunto de reflejos)
• G:\ Archivos de base de datos para ambos grupos de almacenamiento (múltiples unidades configuradas como conjunto de bandas de hardware con paridad)

• Partición del sistema
• Partición que contiene los archivos binarios de Exchange
• Particiones que contienen los archivos de registro de transacciones
• Particiones que contienen archivos de base de datos
• Particiones que contienen otros archivos de Exchange

Directorio de cola SMTP

El directorio de cola SMTP desempeña una función importante en el proceso de puesta en cola de mensajes del Protocolo simple de transferencia de correo (SMTP). El directorio de cola SMTP almacena los mensajes SMTP hasta que se escriben en una base de datos (pública o privada, dependiendo del tipo de mensaje), o se envían a otro servidor o conector. Como el proceso de puesta en cola SMTP realiza muchas escrituras, es importante configurar el sistema para lograr el máximo rendimiento.

Normalmente, los mensajes se almacenan en la cola SMTP durante un breve período de tiempo. Sin embargo, en algunas situaciones (especialmente cuando se producen errores en los procesos indirectos) la cola SMTP puede resultar necesaria para almacenar un gran volumen de datos. Por tanto, la solución de almacenamiento para la cola SMTP debe optimizar el rendimiento antes que la capacidad y la confiabilidad.

De manera predeterminada, Exchange almacena los mensajes SMTP en la siguiente carpeta:

unidad:\Archivos de programa\Exchsrvr\Mailroot

Esta carpeta existe en la misma partición en la que se instala Exchange 2003. En algunos casos (por ejemplo, cuando configura un servidor cabeza de puente), puede mejorar el rendimiento del servidor de Exchange 2003 si mueve la carpeta Mailroot a otro disco duro o a otra partición diferente.

Consideraciones sobre la cola SMTP

Cuando piense la ubicación de los datos de la cola SMTP, tenga en cuenta lo siguiente:

• No dé por supuesto que una matriz RAID-0 es la mejor solución de almacenamiento para las colas SMTP. Normalmente, RAID-0 sólo resulta conveniente si la pérdida de correo es aceptable. RAID-1 es una buena solución, ya que proporciona más medios de confiabilidad mientras que ofrece un rendimiento adecuado. Sin embargo, si busca el máximo rendimiento y confiabilidad, merece la pena el uso de RAID-0+1 para la cola SMTP a pesar de la inversión adicional que supone.
• En Exchange 2003 puede utilizar ahora el Administrador del sistema de Exchange para cambiar la ubicación del directorio de cola. En el Administrador del sistema de Exchange, esta opción está disponible en la ficha Mensaje del objeto del servidor virtual SMTP.

Archivos de indización de contenido

La indización de contenido produce una paginación excesiva mientras se examinan las bases de datos, así como excesivas escrituras en el archivo de indización de contenido. Por tanto, el archivo de indización de contenido no debe estar en el mismo disco que el archivo de paginación (aunque es la ubicación predeterminada). Como el archivo de indización de contenido es un archivo de acceso aleatorio, puede colocarse en la misma unidad que las bases de datos, siempre y cuando el subsistema de disco pueda asumir esa carga.

Consideraciones de espacio del disco duro

Compruebe que dispone de la capacidad de disco duro apropiada para los servidores de Exchange. Debe tener espacio suficiente en el disco duro para restaurar los archivos de registro y de la base de datos.

Es posible que pudiera tener una copia de seguridad que fuera demasiado grande para restaurarla en su ubicación original. Por ejemplo, una copia de seguridad normal realizada una vez por semana más seis días de copias de seguridad diferenciales, puede requerir durante la restauración más espacio en disco del que dispone el servidor. Que la restauración requiera más espacio en disco del que dispone depende del número de archivos de registros generados durante una semana. Por ejemplo, un servidor que genera 2.000 archivos de registro por semana ocupa 10 GB de espacio en archivos de registro, además del espacio requerido para la base de datos.

La realización diaria de copias de seguridad reduce el volumen de espacio necesario para restaurar las bases de datos de Exchange. El motivo de esta reducción de espacio es que las copias de seguridad normales suprimen los archivos de registro de transacciones anteriores a la realización de la copia de seguridad. Si necesita restaurar las bases de datos de Exchange, realice copias de seguridad normales diariamente para asegurarse de que no tendrá que restaurar un volumen de archivos de registro superior al creado en un día.

Además, nunca debe permitir que la unidad de la base de datos (el disco duro que contiene los archivos .edb y .stm) esté ocupada en más de la mitad de su capacidad. Aunque en una unidad de base de datos que tenga ocupada la mitad de su capacidad haya espacio del disco que esté inutilizado, se puede reducir el tiempo de inactividad del servidor extendido por los siguientes motivos:

• Se pueden restaurar las bases de datos más rápido que con una unidad llena (especialmente si el sistema de archivos está fragmentado).

• Se puede realizar la desfragmentación sin conexión en el mismo disco físico en lugar de copiar las bases de datos a un servidor de mantenimiento (una tarea en la que se invierte mucho más tiempo que en copiar los archivos de base de datos a un directorio temporal del mismo disco duro físico).

• Se puede hacer copia de seguridad de una copia de las bases de datos en el mismo disco físico antes de restaurarlas, lo que permite intentar la reparación de las bases de datos en caso de que se produzca un problema durante el proceso de restauración (por ejemplo, si la copia de seguridad existente contiene errores). Por este motivo, resulta recomendable mover o copiar los archivos de registro y de la base de datos antes de restaurar una base de datos. Para obtener información acerca de la restauración de bases de datos de Exchange, consulte la Guía de operaciones para la recuperación de desastres de Exchange Server 2003.

  Nota

  Dado el gran tamaño que tiene una base de datos media, el proceso de copia de la base de datos más reciente a una unidad de disco físico diferente o a otro servidor, puede agregar varias horas al tiempo de inactividad. Sin embargo, si se dispone de espacio suficiente en el disco local de la misma unidad física, se pueden mover los archivos recientes de la base de datos a otra carpeta a través del símbolo del sistema o del Explorador de Windows antes de realizar la restauración.

Rendimiento de disco y de E/S

El hecho de tener suficiente rendimiento de E/S de disco como para atender a un número específico de usuarios es tan importante como tener suficiente espacio de disco. Esto resulta especialmente importante para las aplicaciones que hacen un uso intensivo del disco, como Exchange 2003. En general, la velocidad y el número de discos físicos son los factores que más influyen en el rendimiento global del sistema de almacenamiento. Si en una SAN se utilizan discos grandes o lentos para ofrecer el espacio de almacenamiento necesario, los requisitos de E/S de disco (no el espacio de almacenamiento) son el factor decisivo a la hora de dimensionar la configuración de almacenamiento. En tal caso, quizás sean necesarios más discos, no para el espacio de almacenamiento adicional, sino para la mayor E/S que generan los ejes adicionales.

Por ejemplo, suponga un número de unidad lógica (LUN) bien dimensionado y equilibrado compuesto por diez unidades de disco de 18 GB a 15.000 RPM para una base de datos que tiene establecida cuotas de buzones de 50 megabytes (MB). Cinco unidades de disco de 36 GB a 15.000 RPM proporcionarían la misma cantidad de almacenamiento pero con sólo la mitad de ejes de disco y, por tanto, sólo la mitad de operaciones de E/S por segundo (que puede ser un rendimiento de E/S de disco inadecuado). También es importante destacar que el hecho de duplicar el tamaño de LUN utilizando diez unidades de disco de 36 GB a 15.000 RPM no significa necesariamente que la cuota de buzón pueda pasar de 50 a 100 MB. Aunque es probable que una configuración de ese tipo ofrezca un rendimiento de E/S por segundo igual o mejor, la potencial duplicación de los tamaños de las bases de datos probablemente ampliará la ventana de recuperación de bases de datos más allá de lo que se indica en el SLA.

Según los supuestos de rendimiento establecidos en Exchange 2003 MAPI Messaging Benchmark versión 3 (MMB3), cada usuario genera en promedio 0,5 solicitudes de E/S por segundo en la base de datos que contiene su buzón. El análisis de las tasas de E/S de disco permite estimar el número de ejes necesario desde una perspectiva de E/S.

Para ayudar a explicar este concepto, en la tabla siguiente se muestran unas tasas de E/S de disco por segundo de ejemplo.

Tasas de E/S de disco por segundo de ejemplo

Velocidad del disco	E/S por segundo	Usuarios por disco de MMB3
7.200 RPM	100	200
10.000 RPM	125	250
15.000 RPM	166	332

Las tasas de E/S de disco para un disco de 7.200 RPM (que se muestran en la tabla 4.3) indican que un eje de 7.200 RPM ofrece suficiente E/S de disco para 200 usuarios simultáneos de MMB3. Un conjunto seccionado para un único grupo de almacenamiento que contenga 2.000 usuarios necesitaría diez discos de 7.200 RPM. En un conjunto de RAID 0+1 (que ofrece mucha mejor capacidad de recuperación que una simple matriz seccionada), se necesitan 20 discos para las bases de datos del grupo de almacenamiento de 2.000 usuarios.

Según indican los datos de la tabla 4.3, para atender a 2.000 usuarios de MMB3 (cada uno de los cuales tiene una cuota de buzón de 50 MB) en un grupo de almacenamiento utilizando discos de 36 GB a 10.000 RPM se necesitan ocho discos en un conjunto seccionado (o 16 en el caso de un conjunto de RAID 0+1). Ocho discos de 36 GB se traducen en un LUN de 288 GB, lo que supera con creces el requisito de almacenamiento de un LUN de 110 GB. En este caso, con discos de 360 GB a 10.000 RPM, los requisitos de E/S (no el tamaño de almacenamiento) dictan los requisitos globales de almacenamiento.

La optimización de la E/S de disco en la SAN es uno de los mayores pasos para mejorar el rendimiento que puede realizar en la organización de Exchange. Cada proveedor de SAN dispone de distintas opciones y requisitos para hacerlo. Por tanto, debe entender y diseñar las implementaciones de SAN teniendo en cuentas los requisitos concretos de E/S. Para Exchange, estos requisitos incluyen:

• Exchange utiliza páginas de 4 KB como tamaño nativo de E/S, incluso aunque muchas transacciones puedan dar como resultado solicitudes de lectura o escritura de varias páginas.
• Los LUN de los registros de transacciones deben optimizarse para las escrituras secuenciales porque siempre se escribe en los registros, y se leen, de manera secuencial.
• Los LUN de las bases de datos deben optimizarse para una relación apropiada de lecturas y escrituras aleatorias. Esta relación se puede determinar de manera experimental mediante las herramientas Exchange Stress and Performance (ESP) y Jetstress.
• La capacidad de recuperación y los requisitos del SLA no deben tenerse en cuenta.

Para obtener más información acerca de cómo diseñar el sistema de almacenamiento para ampliar al máximo el rendimiento y la disponibilidad, consulte Solution Accelerator for MSA Enterprise Messaging (en inglés).

Para obtener información acerca de cómo diseñar la arquitectura de almacenamiento, consulte “MSA Storage Architecture” en MSA Reference Architecture Kit (en inglés).

Desfragmentación del disco

La desfragmentación de disco implica la reorganización de los datos de los discos duros de un servidor para que los archivos sean más contiguos y las lecturas sean más eficaces. Al desfragmentar los discos duros aumenta el rendimiento de los discos, y se garantiza que los servidores de Exchange funcionan sin problemas y de manera eficiente.

Dado que una desfragmentación severa del disco puede ocasionar problemas de rendimiento, ejecute un programa de desfragmentación de discos (como Desfragmentador de disco) periódicamente o cuando los niveles de rendimiento sean más bajos de lo normal. Como se requieren más lecturas del disco cuando se hace copia de seguridad de un sistema de archivos muy fragmentado, asegúrese de que los discos se hayan desfragmentado recientemente.

Las bases de datos de Exchange también requieren desfragmentación. Sin embargo, la fragmentación de los datos de Exchange se produce dentro de la propia base de datos de Exchange. En concreto, la desfragmentación de la base de datos de Exchange se refiere a la reorganización de los datos de los almacenes de buzones y de carpetas públicas para llenar las páginas de la base de datos de manera más eficiente, eliminando el espacio de almacenamiento no utilizado.

Hay dos tipos de desfragmentación de la base de datos de Exchange: con conexión y sin conexión.

Desfragmentación con conexión

De manera predeterminada, en los servidores de Exchange 2003 la desfragmentación con conexión se realiza diariamente entre las 01:00 (1:00 a.m.) y las 05:00 (5:00 a.m.). La desfragmentación con conexión detecta y elimina automáticamente los objetos que ya no se utilizan. Este proceso libera más espacio de base de datos sin modificar realmente el tamaño de archivo de las bases de datos que se están desfragmentando.

Existen dos formas de programar la desfragmentación de la base de datos:

• Para programar la desfragmentación de una base de datos individual, utilice la opción Intervalo de mantenimiento de la ficha Base de datos de un objeto de almacén de buzones o de carpetas públicas.
• Para programar la desfragmentación de la base de datos para un conjunto de almacenes de buzones y de carpetas públicas, utilice la opción Intervalo de mantenimiento de la ficha Base de datos (directiva) de una directiva de almacén de buzones o de carpetas públicas.

Para obtener información acerca de cómo crear una directiva de almacén de buzones o de carpetas públicas, consulte “Creación de una directiva de almacén de buzones” y “Creación de una directiva de almacén público” en la Ayuda de Exchange 2003.

Desfragmentación sin conexión

La desfragmentación sin conexión implica el uso de las Utilidades de la base de datos de Exchange Server (Eseutil.exe). Eseutil.exe crea una base de datos nueva, copia los registros de la base de datos anterior a la nueva y descarta las páginas no utilizadas, lo que da como resultado un nuevo archivo de base de datos compacto. Para reducir el tamaño de archivo físico de las bases de datos debe realizar una desfragmentación sin conexión en las situaciones siguientes:

• Después de realizar una reparación de la base de datos (con Eseutil /p).
• Después de mover una cantidad considerable de datos desde una base de datos de Exchange.
• Cuando una base de datos de Exchange es mucho mayor de lo que debería.

Cuando utilice Eseutil.exe para desfragmentar las bases de datos de Exchange, tenga en cuenta lo siguiente:

• Para reconstruir la nueva base de datos desfragmentada en una ubicación alternativa, ejecute Eseutil.exe en modo de desfragmentación (mediante el comando Eseutil /d) e incluya el modificador /p. La inclusión del modificador /p adicional durante una operación de desfragmentación le permite conservar la base de datos desfragmentada original (por si necesita volver a esta base de datos). El uso de este modificador también reduce considerablemente el tiempo que se tarda en desfragmentar una base de datos.
• Puesto que la desfragmentación sin conexión altera totalmente las páginas de la base de datos, debe crear nuevas copias de seguridad de las bases de datos de Exchange 2003 inmediatamente después de realizar esta desfragmentación. Si emplea la utilidad Copia de seguridad para realizar las copias de seguridad de las bases de datos de Exchange, cree nuevas copias de seguridad normales de estas bases de datos. Si no crea nuevas copias de seguridad normales, las anteriores copias de seguridad incrementales o diferenciales no funcionarán porque hacen referencia a páginas de la base de datos que el proceso de desfragmentación reorganizó.

Optimización del uso de la memoria

Es importante tener en cuenta el espacio de direcciones virtuales a la hora de implementar un sistema de mensajería de Exchange. El uso de espacio de las direcciones virtuales de un servidor determina la escalabilidad y el rendimiento general de un servidor de buzones. Cuando se empieza a agotar la memoria virtual, el rendimiento disminuye de manera espectacular. Aunque Exchange 2003 optimiza automáticamente el uso de memoria en los servidores de tamaño pequeño a mediano, es necesario realizar ajustes adicionales para los servidores que tienen más de 1 GB de memoria física.

Para obtener información acerca de los efectos que tiene la fragmentación de la memoria virtual, así como instrucciones para optimizar el uso de la memoria, consulte la Guía de rendimiento y escalabilidad de Exchange Server 2003.

Otros problemas de configuración de Windows y Exchange

Hay muchas recomendaciones de configuración que debe tener en cuenta a la hora de diseñar un sistema de mensajería de alta disponibilidad. Sin embargo, una explicación detallada de estas recomendaciones queda fuera del ámbito de esta guía. Para obtener información completa acerca de cómo configurar el sistema de mensajería para lograr una disponibilidad, una escalabilidad y un rendimiento elevados, consulte la Guía de rendimiento y escalabilidad de Exchange Server 2003.