Partager via

Planificación de capacidad. Sí, el espacio de registro de transacciones es fundamental para mantener las bases de datos montadas y en buen estado

  • Article

Artículo original publicado el miércoles 09 de noviembre de 2011

El otro día estaba conversando por chat con uno de nuestros directores de programas de compatibilidad, Nino Bilic, y mencionó algo que fue bastante alarmante: el motivo principal por el que nuestros mejores clientes abren las situaciones críticas de Exchange 2010 es porque las bases de datos del buzón se desmontan por falta de espacio en disco en el LUN de registro de transacciones.

Voy a dejar que se asuma la noticia por un momento. Naturalmente estoy conmocionado... para ser completamente honesto, pensaba que con la Calculadora de requisitos del buzón y nuestras instrucciones en TechNet, ya habíamos solucionado este problema. Después de compartir esta información conmigo, Nino decidió que yo, no él, escribiera un artículo de blog sobre el tema de planificación de capacidad de registro de transacciones (vaya, gracias Nino).

Planificación de capacidad 101

Para dar el tamaño adecuado a un LUN de registro de transacciones, necesitamos comprender algunas cosas sobre el entorno:

  1. ¿Cuántos buzones residirán en la base de datos?
  2. ¿Cuál es el perfil de mensaje de los buzones en la base de datos?
  3. ¿Cuál es el tamaño de mensaje promedio?
  4. ¿Cuál es el tamaño de buzón promedio?
  5. ¿Cuántos buzones se mueven por día?
  6. ¿Cuál es la solución de copia de seguridad y restauración?
  7. ¿Para la solución se debe tener en cuenta algún otro caso de error, como errores de red?

Para los fines de este análisis, supongamos que cada base de datos alojará 250 buzones. Cada buzón envía y recibe 150 mensajes por día, con un tamaño de mensaje promedio de 100 KB. Según la tabla de Descripción de los factores de capacidad de la base de datos de buzones de correo y de registro, sabemos que un perfil de 150 mensajes con un tamaño de mensaje promedio de 75 KB genera 30 registros de transacciones por día (período de 24 horas). Como nuestro tamaño de mensaje supera los 75 KB, necesitamos dar cuenta de ello en nuestros registros de transacciones por generación de buzón. Las instrucciones estipulan lo siguiente:

Si el tamaño de mensaje promedio se duplica a 150 KB, los registros generados por buzón aumentan en un factor de 1,9. Este número representa el porcentaje de la base de datos que contiene los adjuntos y las tablas de mensaje (adjuntos y cuerpos de mensaje).

Por lo tanto, podemos determinar el impacto que tiene nuestro tamaño de mensaje promedio de 100 KB con esta fórmula:

150 / 1,9 = [tamaño de mensaje promedio de perfil] / x

x = (100 * 1,9) / 150

x = 1,266666666666667 ~ 1,27

Entonces al tener un tamaño de mensaje que supera en 25 KB a la línea base, la cantidad de registros de transacciones generados por día por buzón aumenta en un factor de 1,27. Por lo tanto, 30 registros de transacciones * 1,27 = 39 registros de transacciones / día / buzón. Esto significa que, para una base de datos de 250 buzones, cada base de datos generará 39 * 250 = 9.750 registros de transacciones generados de buzón / día / base de datos.

Los movimientos de buzón también generan registros de transacciones. Cada buzón que se mueve a la base de datos de destino genera más o menos suficientes registros (en el destino, no el origen) que tienen el tamaño del buzón (incluido el contenido en las carpetas Elementos recuperables). Por ejemplo, mover 1 % de los buzones por día significará que 2,5 buzones se mueven a una base de datos todos los días. Si cada buzón tiene un tamaño promedio de 5,4 GB (incluida una retención de elementos eliminados de 14 días con Recuperación de elementos únicos habilitada), entonces 2,5 * 5,4 GB / 1024 = 13.888 registros de transacciones generados de movimientos de buzón / día / base de datos.

Desde una perspectiva de copia de seguridad y restauración, debemos tener en cuenta el tipo de arquitectura de copia de seguridad que estamos aprovechando. Con cada situación de copia de seguridad, existe una cantidad recomendada de días adicionales que debe aprovisionar desde una perspectiva de capacidad para sus registros de transacciones generados de buzón. Al aprovisionar espacio extra, puede superar varios errores sin sufrir una situación de interrupción. Para obtener más información sobre truncamiento de registros de transacciones, consulte Descripción de la copia de seguridad, restauración y recuperación ante desastres.

  Truncamiento de registros de transacciones Protección contra errores de copia de seguridad recomendada
Copia de seguridad completa diaria Diario 3 días
Copia de seguridad completa semanal / diaria incremental Diario 3 días
Copia de seguridad completa semanal / diaria diferencial Semanal 7 días
Copia de seguridad completa quincenal / diaria incremental Diario 3 días
Protección nativa de datos de Exchange En la medida en que ya no se requieren registros 3 días

Por supuesto, existen otros casos que posiblemente deba considerar. Por ejemplo, si está implementado un Grupo de disponibilidad de base de datos (DAG) expandido en dos centros de datos, el truncamiento de registros solo ocurrirá si el vínculo de red entre los dos centros de datos está en funcionamiento y las copias de bases de datos están en buen estado. Si sabe que una interrupción del vínculo de WAN podría tardar 5 días en repararse, debe ajustar la protección contra errores de bases de datos para tener eso en cuenta.

Para nuestro caso, supongamos que solo necesita asegurarse de que podamos superar 3 días de situaciones de errores de truncamiento. Esto significa que necesitamos 9.750 / 1024 * 3 = 28,5 GB de espacio en disco para nuestros registros de transacciones generados de buzón. .

Además, necesitamos dar cuenta de la cantidad de espacio en disco requerida para nuestras situaciones de movimiento de buzón para toda la semana: 13.888 / 1014 * 7 días = 94,9 GB de espacio en disco para nuestras operaciones de movimiento de buzón.

Una vez dicho todo, esto significa que cada base de datos necesita 123 GB de espacio en disco para registros de transacciones. También debemos incluir un factor de sobrecarga de datos, para dar cuenta de cualquier fenómeno imprevisto que pudiera ocurrir: 123 GB * 1,2 = 148 GB de espacio en disco para registros de transacciones.

Si está implementando un LUN dedicado para los registros de transacciones, no aprovisionaría un LUN de 150 GB ya que eso significaría que podríamos usar todo el espacio en disco si tuviéramos errores de copia de seguridad y movimientos excesivos de buzón. Generalmente, debe asegurarse de que cada LUN se aprovisione de modo tal que se utilice solo el 80 % de la capacidad de disco. La fórmula es:

Espacio de LUN = [utilización proyectada de espacio en disco] / (1 – [porcentaje deseado de espacio en disco])

Espacio de LUN = 148 GB / (1 – 0,2) = 148 GB / 0,8 = espacio de LUN de 185 GB para volumen dedicado de registros de transacciones

Si está implementando los registros de transacciones en el mismo LUN que la base de datos, simplemente combinaría los requisitos de espacio en disco de registros de transacciones con los requisitos de espacio en disco de bases de datos para el valor de [utilización proyectada de espacio en disco].

¿Cómo puedo impedir que se use todo el espacio en disco de registros de transacciones?

En primer lugar, debe obtener una línea base de su entorno para determinar la tasa de generación de registros típica por día. Además, debe configurar la supervisión y tomar medidas con respecto a cualquier alerta que se genere. La supervisión debe supervisar ante los siguientes casos:

  1. Espacio en disco de LUN de registros de transacciones. Configure varios umbrales y diferentes mecanismos de alerta. Su primera alerta no debe ser la que indica que se usó el 90 % del disco. Si conoce su línea base de generación de registros típica, puede configurar un umbral para que se informe si se supera el 20 %, por ejemplo.
  2. Supervisar que las copias de seguridad se completen correctamente (si no está aprovechando Protección nativa de datos de Exchange). La primera indicación de errores de bases de datos no debe ser cuando se agota el espacio en disco.
  3. Supervisar los casos de truncamiento en el Registro de aplicaciones.
  4. Supervisar el estado de replicación de copia de bases de datos

¿Qué sucede si tengo un crecimiento imprevisto en mis Registros de aplicaciones?

Mi amigo, Mike Lagase, escribió un excelente artículo sobre cómo solucionar problemas de este caso - https://blogs.technet.com/b/mikelag/archive/2009/07/12/troubleshooting-store-log-database-growth-issues.aspx (tenga en cuenta que el artículo se escribió con Exchange 2007 en mente, entonces es posible que varias de las herramientas o recomendaciones ya no correspondan a Exchange 2010). Además de los pasos que Mike menciona, puede utilizar lo siguiente en Exchange 2010 para ayudar a determinar el crecimiento de registros de transacciones imprevisto (gracias a Todd Luttinen por compilar esta lista):

  1. Puede usar el cmdlet de estadísticas de uso de almacenamiento (get-StoreUsageStatistics con DigestCategory = ‘LogBytes’) para identificar los buzones que generan alto recuento de bytes de registro. Tenga en cuenta que esto no siempre funciona para los casos en los que los bytes de registro no son generados por el propietario del buzón o la operación se lleva a cabo en nombre del cliente (como CopyOnWrite) y no incluye bytes de registro generados por servicios de sistema (informados en el Id. de evento 9826). Estas estadísticas proporcionan un resumen de los últimos 10 minutos de actividad para los buzones principales que generan actividad de registro (hasta 6 ejemplos que cubren la última hora). A continuación, se muestra cómo utilizar las estadísticas de uso de almacenamiento para encontrar los buzones principales que generan bytes de registro durante la última hora:

    [PS] C:\>$stats = Get-StoreUsageStatistics –Database <Nombre de base de datos>
    [PS] C:\>$stats | ? {$_.DigestCategory -eq 'LogBytes'} | group MailboxGuid |sort count -Descending | Select -first 1 -ExpandProperty Group | sort SampleTime | ft -a MailboxGuid,Sample*,Log*

    MailboxGuid SampleID SampleTime LogRecordCount LogRecordBytes
    c007c87a-e030-4414-b741-9cf61e88b9de 5 07/11/2011 16:25:05 237 274163
    c007c87a-e030-4414-b741-9cf61e88b9de 4 07/11/2011 16:35:05 451 387362
    c007c87a-e030-4414-b741-9cf61e88b9de 3 07/11/2011 16:45:06 483 144999
    c007c87a-e030-4414-b741-9cf61e88b9de 2 07/11/2011 16:55:06 734 293433
    c007c87a-e030-4414-b741-9cf61e88b9de 1 07/11/2011 17:05:06 933 411485
    c007c87a-e030-4414-b741-9cf61e88b9de 0 07/11/2011 17:15:06 247 209987

  2. También existen eventos de aplicaciones generados por clientes administrativos (Id. de evento 9826). Estas estadísticas representan 2 horas de actividad:

    A partir de <fecha/hora> servicio <nombre> realizó esta actividad en el servidor:
    Operaciones RPC: 24168.
    Páginas de base de datos leídas: 1329 (de las cuales 629 se habían leído previamente).
    Páginas de base de datos actualizadas: 12418 (de las cuales 11555 se volvieron a actualizar).
    Registros de bases de datos generados: 13906.
    Bytes de registros de bases de datos generados: 660331.
    Tiempo en servidor: 19142 ms.
    Tiempo en modo usuario: 6100 ms.
    Tiempo en modo kernel: 63 ms.

  3. El contador de supervisión de rendimiento “MSExchangeIS Client(*)\JET Log Record Bytes/sec” se puede usar para identificar qué tipo de cliente está ocasionando el crecimiento de registro.

Creo que todos entendemos la importancia de asegurarse de que haya capacidad suficiente para garantizar que la disponibilidad de las bases de datos no se vea afectada. Espero que esta información ayude en la planificación de la capacidad de registro de transacciones.

Ross Smith IV
Director principal de programas
Experiencia del usuario de Exchange

Esta entrada de blog es una traducción. Puede consultar el artículo original en Capacity Planning – Yes Transaction Log Space is Critical to Keeping your Databases Healthy and Mounted