Cambios COW en el control de versiones de Elementos recuperables en Exchange 2010 SP2 RU3

Artículo original publicado el viernes, 1 de junio de 2012

Durante los últimos meses, hemos recibido informes de un excesivo crecimiento de la carpeta Elementos recuperables (a la que muchos denominan Contenedor, pero nosotros ya no la llamamos así). Existen dos escenarios principales que pueden contribuir a este crecimiento excesivo.

1. Control de versiones en la recuperación de elementos únicos y la retención por juicio
2. Registro de versiones de calendario

Recuperación de elementos únicos y retención por juicio

La recuperación de elementos únicos y la retención por juicio permiten conservar los datos del buzón. Si no conoces estas características, consulta mi entrada anterior sobre la recuperación de elementos únicos en Exchange 2010 para obtener más información.

Además de conservar los datos del buzón, tanto la recuperación de elementos únicos como la retención por juicio habilitan el control de versiones. Fundamentalmente, cuando un elemento sufre un cambio, se realiza una copia en escritura (COW) para preservar la versión original del elemento. El elemento original se almacena en la carpeta Elementos recuperables\Versiones. Los usuarios no pueden ver esta carpeta.

Dado que Exchange 2010 incluye un cambio en el modo en que los clientes se conectan y tienen acceso a los datos relacionados con el buzón, la actividad de copia en escritura se produce en la capa Objetos de sistema de Exchange (XSO) del servidor de acceso de cliente.

¿Qué desencadena una copia en escritura?

• En los mensajes y entradas (IPM.Note* y IPM.Post*), la copia en escritura capta los cambios en el asunto, el cuerpo, los datos adjuntos, los remitentes y destinatarios y las fechas de envío y recepción.
• Para el resto de elementos, la copia en escritura capta cualquier cambio, salvo los movimientos entre carpetas y los cambios en el estado de leído y no leído.
• En los borradores no se aplica la copia en escritura para evitar que se realicen excesivas copias cuando se guardan automáticamente.

¿Qué puede provocar un crecimiento excesivo de la carpeta Elementos recuperables?

El comportamiento de la copia en escritura puede provocar un crecimiento excesivo. Hemos descubierto que el siguiente escenario con Microsoft Outlook es una causa principal de una excesiva copia en escritura:

1. Creas una cita de calendario.
2. Adjuntas un documento de Office a la cita y lo guardas.
3. Posteriormente, decides abrir la cita para hacer referencia a algo del documento de Office. Abres el documento.
4. En segundo plano, Outlook empieza a guardar automáticamente esta cita abierta y su correspondiente documento abierto (de forma predeterminada, Outlook guarda automáticamente cada 3 minutos).
5. Cada vez que se guarda automáticamente, se desencadena una copia en escritura. No obstante, como el guardado automático guarda tanto el documento de Office como la cita, hay dos eventos de copia en escritura. Para cada dato adjunto adicional también se crearía una versión de copia en escritura correspondiente.

Vaya, es verdad.

Dado que los datos adjuntos forman parte del mensaje, no tiene sentido crear una copia para cada dato adjunto del elemento. Básicamente, cuando guardas un elemento con un dato adjunto, Outlook realiza lo siguiente:

1. CreateAttachment
2. SaveAttachment
3. SaveMessage

La copia en escritura se produce tanto con SaveAttachment como con SaveMessage. Al profundizar en el código, descubrimos que la llamada a SaveAttachment llama en última instancia al método Flush (vaciado) (mediante el cual el cliente sincroniza el estado con el servidor) en el mensaje con el que está asociado tras guardar el dato adjunto. Es esta llamada a Flush la que señala al código de copia en escritura que actúe.

Tras un análisis más exhaustivo, observamos que la lógica de copia en escritura se desencadena en todas las llamadas a Flush. Este fue un descubrimiento muy esclarecedor ya que Flush se puede iniciar en múltiples escenarios, lo que puede ser la causa potencial de los miles de eventos de copia en escritura que vieron varios clientes en sus entornos.

En Exchange 2010 SP2 RU3 y versiones posteriores, la copia en escritura ahora comprende la diferencia entre las operaciones de vaciado y de guardado, y solo se desencadenará cuando se produzca una operación de guardado.

Registro de versiones de calendario

El registro de versiones de calendario es el proceso por el cual los cambios del calendario que se producen en un buzón se guardan mediante copia en escritura. Esta característica se introdujo en Exchange 2010 para ayudar a solucionar problemas y reparar incidencias de fiabilidad del calendario.

El diseño del registro de versiones de calendario está hecho para que se cree un registro cada vez que se modifica un elemento del calendario. Estos registros proporcionan un historial de la reunión. Puedes usar el cmdlet Get-CalendarDiagnosticLog para revisar el historial y determinar qué clientes realizaron una acción destructiva. El Asistente para reparar calendarios hace un segundo uso del registro de versiones de calendario, al utilizar los registros para intentar determinar el historial de un determinado elemento de calendario para detectar incoherencias.

El registro de versiones de calendario está habilitado de forma predeterminada en los buzones en Exchange 2010. Es posible deshabilitarlo o habilitarlo en un buzón mediante la propiedad CalendarVersionStoreDisabled. Ten en cuenta que el nombre de la propiedad es CalendarVersionStoreDisabled, por lo que el valor predeterminado $false indica que el registro de versiones de calendario está habilitado de forma predeterminada. El proceso para almacenar copias de los elementos del calendario es distinto en función de la configuración del buzón:

1. Si el buzón no está habilitado para recuperación de elementos únicos o retención por juicio, se conservarán versiones seccionadas de los elementos de calendario en la raíz de la carpeta Elementos recuperables durante 120 días. Las versiones seccionadas (se eliminan el cuerpo y los datos adjuntos de tipos de mensajes no incrustados o que no sean de primer nivel) se crean mediante copia en escritura.
2. Si el buzón está habilitado para recuperación de elementos únicos o retención por juicio, se guardarán copias completas de los elementos de calendario en las carpetas Elementos recuperables\Eliminaciones o Elementos recuperables\Versiones. La infraestructura de copia en escritura creará una versión seccionada cada vez que se realice una operación de eliminación permanente en el elemento de calendario de las carpetas Elementos recuperables\Eliminaciones o Elementos recuperables\Versiones. Esta versión seccionada se almacena en la raíz de la carpeta Elementos recuperables durante 120 días. La única vez que no se crea una versión seccionada es cuando el elemento de la carpeta Elementos recuperables\Eliminaciones o Elementos recuperables\Versiones tiene más de 134 días (120 + 14). Esto puede ocurrir si se cambia el período de retención, si no se ha ejecutado el asistente para carpetas de buzón, si la retención por juicio se encontraba deshabilitada, etc.).

Debido al problema mencionado anteriormente de que la lógica de copia en escritura no distinguía entre operaciones de vaciado y de guardado, en ciertos casos, el registro de versiones de calendario puede consumir un elevado porcentaje de la cuota de la carpeta Elementos recuperables (recuerda que el umbral de advertencia está en 20 GB y la cuota máxima es de 30 GB).

Aunque SP2 RU3 soluciona los problemas de copia en escritura, para resolver el problema de que el registro de versiones de calendario pueda consumir toda la cuota de la carpeta Elementos recuperables, introdujimos en SP2 RU2 un cambio en la arquitectura que hace que el registro de versiones de calendario ahora tenga en cuenta el tamaño de la carpeta Elementos recuperables antes de iniciar una copia en escritura.

Si el tamaño de la carpeta es superior al valor de RecoverableItemsWarningQuota, el registro de versiones de calendario se deshabilitará para el buzón. El valor RecoverableItemsWarningQuota que se use depende de la configuración del buzón:

1. Si el buzón tiene UseDatabaseQuotaDefaults establecido en $true, se usará el valor RecoverableItemsWarningQuotade la base de datos del buzón.
2. Si el buzón tiene UseDatabaseQuotaDefaults establecido en $false, se usará el valor RecoverableItemsWarningQuota del buzón.

Cuando el registro de versiones de calendario se encuentra deshabilitado, se genera el siguiente evento en el registro de eventos de la aplicación en el servidor de acceso de cliente:

Identificador de evento: 5003
Origen: Almacenamiento de nivel intermedio de MSExchange
Categoría de tarea: Copia en escritura
Nivel: Información
Descripción: El buzón del usuario <legacyExchangeDN> ha superado la cuota de advertencia del contenedor. El registro de calendario se ha deshabilitado para el buzón.

Y eso no es todo lo que hacemos. No me detendré en los aspectos específicos en esta temprana fase del desarrollo, pero estamos trabajando para mejorar el registro de versiones de calendario a fin de reducir el impacto que tiene esta característica en tu implementación. Compartiré más información en este blog en cuanto pueda.

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

Esta entrada de blog es una traducción. Puedes consultar el artículo original en Holy COW! Changes to Recoverable Items versioning in Exchange 2010 SP2 RU3