Exportar (0) Imprimir
Expandir todo
Este tema aún no ha recibido ninguna valoración - Valorar este tema

Descripción de los factores de capacidad de la base de datos de buzones de correo y de registro

Exchange 2010
 

Se aplica a: Exchange Server 2010 SP3, Exchange Server 2010 SP2

Última modificación del tema: 2012-02-24

En este tema se explican los factores que habría que tener en cuenta a la hora de planear la capacidad de registro y de la base de datos de buzones de correo como parte del diseño de almacenamiento de servidores de buzones de correo en Microsoft Exchange Server 2010.

La primera medición que hay que comprender es el límite de tamaño de almacenamiento, conocido como cuota de almacenamiento, que se usa en su organización. Conocer la cantidad de datos que un usuario final puede almacenar en su buzón permite determinar cuántos buzones de usuarios pueden hospedarse en el servidor. Aunque las cuotas de almacenamiento de buzones pueden cambiar como respuesta al cambio en las necesidades organizativas, tener un objetivo para la cuota de almacenamiento de buzones es el primer paso para determinar la capacidad necesaria para la base de datos de buzones.

Por ejemplo, si dispone de un servidor que contiene 5.000 buzones de usuario de 250 MB, necesita por lo menos 1,25 TB de espacio en disco, excluyendo los requisitos de espacio para los elementos recuperables. Si no hay especificado un límite para la cuota de almacenamiento de los buzones, le resultará difícil calcular la capacidad de la base de datos. Es necesario que las cuotas de almacenamiento de buzones para Exchange 2010 incluyan el espacio para el buzón principal y el buzón de archivo personal (si se utiliza). Para obtener más información, vea Administración de servidores de buzones y Administración de archivos personales.

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 almacenamiento de los buzones. Cuando la mayor parte de los usuarios no se acerca a su cuota de almacenamiento de buzón, las bases de datos consumen menos espacio y el espacio en blanco no supone ningún problema de capacidad. La propia base de datos siempre tendrá páginas o espacios en blanco. Durante el mantenimiento en segundo plano de la base de datos, se quitan de la base de datos los elementos marcados para su eliminación, lo que libera estas páginas. El porcentaje de espacio en blanco cambia constantemente, a causa de los esfuerzos del proceso permanente de desfragmentación con conexión.

Si conoce la cantidad de correo que los usuarios con buzones en la base de datos envían y reciben, puede calcular la cantidad de espacio blanco en la base de datos. Por ejemplo, si tiene cien buzones de 2 GB (un total de 200 GB) en una base de datos en la que 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). La cantidad de espacio en blanco puede superar ese cálculo, si el mantenimiento de la base de datos en segundo plano no consigue completar un recorrido completo.

Volver al principio

Cada base de datos tiene una característica de recuperación del elemento eliminado que almacena los elementos eliminados temporalmente. Como opción predeterminada, en Exchange 2010, los elementos eliminados temporalmente se almacenan durante 14 días, y los elementos de calendario se almacenan durante 120 días.

Además, Exchange 2010 incluye también la capacidad de evitar que se depuren los datos antes de que haya pasado la ventana de retención del elemento eliminado. Esta funcionalidad se conoce como recuperación de un único elemento. La recuperación de elementos individuales está deshabilitada de forma predeterminada. No obstante, cuando se habilita la recuperación de elementos individuales, hay un aumento adicional del 1,2 % en el tamaño del buzón, para una ventana de 14 días de retención del elemento eliminado. Para los datos de registro de la versión de calendario hay un aumento adicional del 3 % en el tamaño del buzón. Los datos de registro de la versión de calendario están habilitados de forma predeterminada.

La fórmula para determinar los requisitos de espacio que presenta la recuperación del elemento eliminado para 14 días de retención de elementos eliminados, con recuperación de un único elemento y registro de la versión de calendario habilitada, es la siguiente:

Tamaño de la característica de recuperación del elemento eliminado = (correo diario entrante y saliente x tamaño promedio de mensaje x ventana de retención de elemento eliminado) + (tamaño de cuota de buzón x 0,012) + (tamaño de cuota de buzón x 0,03)

Por ejemplo, si el tamaño del buzón es de 2 GB, para permitir la recuperación de un único elemento durante 14 días de retención del elemento eliminado es necesario un espacio adicional de 25 MB, y la característica de registro del calendario necesita 61 MB adicionales.

Para obtener más información al respecto, consulte los temas siguientes:

Con el tiempo, los buzones de usuario alcanzarán la cuota de almacenamiento del buzón, por lo que será necesario eliminar una cantidad equivalente de correo entrante para mantenerse por debajo de la cuota de almacenamiento de buzón. Este requisito significa que la recuperación del elemento eliminado aumentará hasta un tamaño máximo equivalente a la cantidad de correo enviado y recibido cada día, multiplicado por el número de días dentro de la ventana de retención del elemento eliminado. Si la mayoría de los usuarios no han alcanzado la cuota de almacenamiento, sólo se eliminará parte del correo entrante y saliente. Por lo tanto, el crecimiento se divide entre la recuperación del elemento eliminado y el aumento en el tamaño del buzón.

Para determinar el tamaño de la base de datos con un buzón de correo de 2 GB sin utilizar la función de archivo personal, consulte la sección "Requisitos de capacidad del buzón de correo" en el tema Ejemplo de diseño de roles del servidor Buzón de correo de Exchange 2010.

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. Divida el tamaño de buzón planeado por el tamaño recomendado para la base de datos. Este valor le ayudará a determinar cuántas bases de datos necesitará para administrar el recuento de usuarios proyectados, suponiendo que las bases de datos están 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.

La indización de contenido crea un índice o catálogo 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 2010 crea un índice con un 10 % del tamaño total de la base de datos, que se coloca en el mismo LUN que la base de datos. Por lo tanto, es necesario crear una capacidad adicional del 10 % en el tamaño del LUN de la base de datos para indizar el contenido.

Volver al principio

Una base de datos que debe compactarse cuando está desconectada necesita una capacidad igual al tamaño de la base de datos de destino más un 10 %. Tanto si asigna suficiente espacio para una única base de datos o para todo un conjunto de copias de seguridad, es necesario que haya espacio adicional para realizar estas operaciones.

importantImportante:
Los procedimientos del mantenimiento sin conexión sólo se deberán implementar a petición del servicio de soporte técnico y servicio al cliente de Microsoft, ya que dichos procedimientos invalidan todas las copias de la base de datos y requieren una reinicialización completa de la base de datos.

Si tiene previsto usar una base de datos de recuperación como parte de los planes de recuperación ante desastres, necesitará que haya capacidad suficiente para administrar todas las bases de datos que desee poder restaurar simultáneamente en ese servidor. Para obtener más información, consulte Bases de datos de recuperación.

El tamaño de la base de datos es lo que determina en última instancia cuántos buzones se implementan dentro de cada base de datos, y cuántas bases de datos se implementan. El tamaño de la base de datos que se implemente dependerá de varios factores:

  • Contratos de nivel de servicio (SLA) para copia de seguridad y restauración   El tamaño de la base de datos es lo que, en última instancia, determina la rapidez con la que se hacen copias de seguridad y restauraciones de los datos dentro de un período de tiempo razonable.

  • Arquitectura de alta disponibilidad   Si piensa tener varias copias de la base de datos, puede establecer que las bases de datos tengan 2 TB de tamaño, ya que las copias se convertirán en la primera línea de defensa en lo que se refiere a las operaciones de recuperación.

  • Arquitectura de almacenamiento   Si planea realizar la implementación con un almacenamiento JBOD (un disco contiene tanto la base de datos como sus correspondientes registros de transacción), el tamaño del disco que utilice será el que determine el tamaño máximo de la base de datos. Por ejemplo, en un disco de 1 TB (cuya capacidad después de darle formato es de 917 GB), también es necesario incluir espacio para los registros de transacciones y para el índice de contenido, así como asegurarse de que no consume todo el espacio disponible.

Una vez que se hayan considerado y calculado todos los factores, se recomienda incluir un factor de sobrecarga adicional del 20 % para el número de unidad lógica (LUN) de la base de datos. Este valor representa el resto de los datos incluidos en la base de datos que no necesariamente se ven al calcular los tamaños de buzón y el espacio en blanco.

Volver al principio

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 Exchange Server 2003, los archivos de registro de transacciones de Exchange 2010 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 calcular el número de registros de transacciones que se generan en un servidor de buzones de correo de Exchange 2010 donde el tamaño de mensaje medio sea de 75 KB.

El valor del Número de registros de transacciones generados al día se basa en el perfil seleccionado de los mensajes y en el tamaño promedio de los mensajes. Indica cuántos registros de transacciones se generarán por buzón de correo al día. Los números de generación de registro por perfil de los mensajes se cuentan para:

  • Impacto del tamaño del mensaje

  • Cantidad de datos enviados/recibidos

  • Operaciones de mantenimiento del estado de la base de datos

  • Operaciones de administración de registros

  • Datos almacenados en un buzón que no son mensajes (tareas, citas de calendario local, contactos)

  • Desplazamiento de registro forzado (un mecanismo que cierra periódicamente el archivo de registro de la transacción actual)

Número de registros de transacciones generados para cada perfil de buzón

 

Perfil de mensaje (75 KB de tamaño promedio de los mensajes) Número de registros de transacciones generados al día

50

10

100

20

150

30

200

40

250

50

300

60

350

70

400

80

450

90

500

100

Para comprender de qué modo el tamaño de los mensajes afecta a la tasa de generación de los registros de transacciones, puede utilizar las siguientes directrices:

  • Si el tamaño de mensaje medio dobla los 150 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 consiguiente, como el tamaño del mensaje se dobla y supera los 150 KB, la tasa de generación de registros por buzón también se dobla, y pasa del 1,9 al 3,8.

Por ejemplo, si tiene 100 mensajes al día y:

  • Un tamaño de mensaje medio de 150 KB, los registros generados por buzón son 20 × 1,9 = 38.

  • Un tamaño de mensaje medio de 300 KB, los registros generados por buzón son 20 × 3.8 = 76.

En las secciones siguientes se tratan los factores que influyen a la hora de planear la capacidad del registro:

El tamaño del LUN de registro depende en parte del diseño de la copia de seguridad y de la 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 una semana entera de espacio de archivo de registro para permitir tanto la copia de seguridad como la reproducción durante la restauración. La mayoría de las empresas que realizan una copia de seguridad completa durante la noche asignan el doble o el triple de la capacidad de generación de registro que se necesita a diario. Esa medida se toma para evitar que un error de copia de seguridad provoque que la unidad de registro se llene, lo que desmontaría la base de datos.

Si planea utilizar las características de resistencia del buzón y de recuperación de un único elemento dentro de Exchange 2010 como infraestructura para la copia de seguridad (con lo que se habilita el registro circular), como práctica recomendada, deberá asegurarse de que asigna el triple de la capacidad de generación de registro que se necesita a diario. De esa forma, se asegurará de que, si la replicación se suspende o no funciona bajo los parámetros normales, las bases de datos no se desmonten a causa de errores de truncamiento.

El movimiento de buzones es un factor de capacidad principal para implementaciones de buzones grandes. Muchas grandes empresas mueven cada noche o semanalmente un porcentaje de sus buzones de usuarios a otras bases de datos, servidores o sitios. Si su organización lo hace, puede que descubra que es necesario proporcionar capacidad adicional al LUN de registro, con el fin de incluir los movimientos de los buzones.

Pese a que el servidor de origen registra las eliminaciones de registros, que son pequeñas, el servidor de destino tiene que escribir todos los datos transferidos antes de escribir los registros de transacción. Si se generasen 10 GB de archivos de registro en un día y se mantuviera un búfer de tres días de 30 GB, al mover 50 buzones de 2 GB (100 GB) se llenaría el LUN de registros de destino y habría un periodo 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.

Para la mayoría de implementaciones, es aconsejable agregar 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 garantizar que habrá la capacidad necesaria en momentos de generación de registros inesperados.

La alta disponibilidad influye en los requisitos de capacidad del registro de tres maneras significativas:

  • Número de copias de la base de datos   La capacidad de registro de todo el sistema aumenta en función del número de copias de la base de datos que se haya elegido al implementar la alta disponibilidad. Si tiene tres copias de base de datos repartidas entre tres servidores, necesita suministrar capacidad de registro para cada copia en cada uno de los servidores.

  • Mecanismo de truncamiento de registro   La alta disponibilidad en Exchange 2010, con la posibilidad de tener hasta 16 copias de cada base de datos de buzones, proporciona la base para utilizar el registro circular de replicación continua como mecanismo de truncación y eliminación del registro, en lugar de tener que ejecutar copias de seguridad completas o incrementales para truncar o eliminar los registros más antiguos. Para obtener más información, consulte la sección "Truncamiento de registros sin copias de seguridad", en Descripción de la copia de seguridad, restauración y recuperación ante desastres, y Alta disponibilidad y resistencia de sitios.

  • Retraso de reproducción de la copia de la base de datos   La alta disponibilidad, en Exchange 2010, proporciona la opción de retardar la reproducción del registro en las copias pasivas de la base de datos (se configura para cada copia). Esta característica se utiliza para proporcionar cierto retraso en aquellas situaciones en las que los registros se reproducen en copias retardadas de la base de datos. Este retraso puede resultar útil para protegerse contra eventos que pudieran hacer que se replicara contenido no deseado en todas las copias de la base de datos. Se puede evitar que el contenido se reproduzca en la copia de base de datos retardada, al interrumpir la reproducción antes de que los registros con el contenido no deseado se reproduzcan en la base de datos.

    Cuando el retraso de reproducción está habilitado para una copia de la base de datos, los requisitos de capacidad del registro cambian en consecuencia. Si tiene configurado un retraso de 14 días, necesita tener previsto espacio para los registros correspondientes a 17 días. La capacidad de registro adicional sólo es necesaria para la copia de la base de datos que tiene configurado el retraso; las otras copias de esa base de datos que no tengan configurado un retraso, tendrán requisitos de registro normales (sin retraso).

Para obtener más información, consulte Descripción de los factores de alta disponibilidad.

Los requisitos de capacidad del LUN se basarán en el tamaño del conjunto de datos (base de datos, registros de transacción, índice de contenido y espacio para recuperación), y en algo de espacio libre adicional. La mayoría de los programas de administración de operaciones tienen umbrales de capacidad que proporcionan una alerta cuando un LUN se utiliza en más del 80 %.

Puede utilizar la siguiente fórmula para determinar el tamaño adecuado del LUN:

Capacidad LUN = Tamaño de los datos / (1 - Requisito de porcentaje de espacio libre)

Por ejemplo, si tiene un requisito de tamaño de datos de 3.000 MB y un requisito del 20 % de espacio libre, el LUN que hospeda esos datos deberá tener un tamaño de 3.750 MB.

Para evitar que se agote el espacio en disco de registro de transacciones, calcule primero una línea base del entorno para determinar la tasa normal de generación de registros al día. En segundo lugar, configure la supervisión y tome las acciones pertinentes en función de las alertas que se generen. Debe supervisar los siguientes elementos:

  • Espacio en disco de LUN de registro de transacciones. Configure varios umbrales y mecanismos de alerta. Por ejemplo, si conoce su línea base de generación de registros normal, puede configurar un umbral para informarle cuando se supere la línea base en un 20 por ciento.

  • Finalización correcta de las copias de seguridad (si no saca provecho de la protección de datos nativos de Exchange).

  • Truncamiento de eventos en el registro de aplicaciones.

  • Estado de replicación de la copia de la base de datos.

Para obtener ayuda sobre cómo solucionar los problemas por un crecimiento de registros de transacciones inexplicable, vea Administrar el crecimiento del registro de las bases de datos con el script DatabaseSpace.ps1 en el Shell.

 © 2010 Microsoft Corporation. Reservados todos los derechos.
¿Te ha resultado útil?
(Caracteres restantes: 1500)
Gracias por sus comentarios
Mostrar:
© 2014 Microsoft. Reservados todos los derechos.