Buzones de una base de datos en cuarentena en un entorno con System Center Operations Manager
Artículo original publicado el jueves 28 de junio de 2012
Actualización del 03/07/2012 : Se expandió la sección de soluciones alternativas para incluir más información.
Queríamos llamar su atención sobre un problema que se ha estado observando recientemente en CSS en los que muchos buzones de la misma base de datos de buzones se ponían en cuarentena sin ninguna razón aparente. Al de inspeccionar el Registro de aplicaciones, verá muchos eventos 10018 con texto que contiene la siguiente información.
Nombre de registro: Aplicación
Origen: MSExchangeIS
Id. de evento: 10018
Categoría de tarea: General
Nivel: Error
Descripción:
El buzón del usuario <guid>: /o=Contoso /ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=UserMailbox se puso en cuarentena. Se restringirá el acceso de inicios de sesión administrativos a este buzón durante las próximas 6 horas.
Además de esto, aparecerá la siguiente Id. de evento 5410 en el registro de eventos Microsoft-Exchange-Troubleshooters/Operational para cada buzón que haya puesto en cuarentena el solucionador de problemas del espacio de la base de datos:
Nombre de registro: Microsoft-Exchange-Troubleshooters/Operational
Origen: Espacio de la base de datos
Id. de evento: 5410
Nivel: Advertencia
Palabras clave: Clásicas
Descripción:
El solucionador de problemas del espacio de la base de datos puso en cuarentena el buzón <guid> de la base de datos <DBName>.
La clave aquí es la última frase, "El solucionador de problemas del espacio de la base de datos". En entornos en los que se ha implementado System Center Operations Manager, existe un Monitor que comprueba por defecto el espacio libre en disco para la base de datos y los volúmenes de registros. Este monitor usa el script de PowerShell Troubleshoot-DatabaseSpace.ps1 , que se incluye en Exchange 2010 por defecto. Para más información sobre el script Troubleshoot-DatabaseSpace.ps1, consulte el siguiente artículo de TechNet:
Administrar el crecimiento de registros de la base de datos con el script Troubleshoot-DatabaseSpace.ps1 en el Shell
https://technet.microsoft.com/en-us/library/ff477617.aspx
El equipo de System Center publicó recientemente el Service Pack 2 para el Paquete de administración de Exchange. Entre otras cosas, esto ajustó un valor de tiempo de espera para ejecutar el script. Antes del Service Pack, el valor de tiempo de espera era de 300 segundos, y el monitor estaba configurado para funcionar cada 5 minutos. Esto significaba que, en muchas grandes organizaciones, estaba prácticamente garantizado que se agotase el tiempo de espera del script y, por consiguiente, que no se completase. Tras instalar la actualización, el nuevo valor de tiempo de espera es de 1200 segundos. Además, ahora el monitor realiza la ejecución una vez cada hora en lugar de una vez cada 5 minutos. La consecuencia de este cambio es que ahora el solucionador de problemas ejecuta de forma segura códigos que antes de la actualización SP2 no ejecutaba. Esto ha motivado que el solucionador de problemas encuentre un error en el contador de rendimiento del Almacén de información que usa para determinar la velocidad de la generación de bytes del registro para la base de datos (la velocidad de rendimiento puede exceder 1,0E+19 bytes/Hora). Cuando la velocidad por hora estimada de la generación de registros excede la capacidad del espacio libre en disco restante en la base de datos o el volumen de registros, el solucionador de problemas comienza a poner en cuarentena buzones para impedir que la generación de registros consuma todo el espacio libre y haga que se desmonte la base de datos. Parece que el solucionador de problemas hace esto cuando el contador de rendimiento tiene un valor falso (el contador de rendimiento se actualiza una vez por minuto y no es recomendable que tenga un valor falso durante más de 1 min.)… así que no ocurre con frecuencia pero sí con una probabilidad moderada.
¿Qué significa esto para usted?
Tal como se ha documentado en el artículo de TechNet, la función principal del script es hacer un seguimiento de la velocidad de generación de registros y comprobar el espacio libre en disco para la base de datos y los volúmenes de registros. Cuando se ejecuta el script, usa un contador de rendimiento del almacén para determinar la velocidad de la generación de registros y calcula si la velocidad actual hará que se agote el espacio en disco en un umbral de horas (la cantidad por defecto es de 12 horas). Si es el caso, empezará a poner buzones en cuarentena opcionalmente (hasta 150 a la vez) y el script pondrá también buzones en cuarentena opcionalmente cuando el porcentaje de espacio libre en disco se sitúe por debajo de un valor específico. El valor de porcentaje de espacio libre en disco que se usa por defecto es del 25%. Para poner en cuarentena buzones cuando no se cumple ninguna de estas condiciones, asegúrese de que incorpora el parámetro Cuarentena al script.
El monitor que usa SCOM 2007 y posteriores usa el parámetro Cuarentena por defecto y no hay ninguna opción compatible para cambiarlo porque el Paquete de administración está precintado. Esto significa que si el espacio libre en disco para la base de datos o el volumen de registros para una base de datos se sitúa por debajo del 25%, Y ADEMÁS la velocidad de generación de registros se calcula para consumir el espacio en disco restante dentro de las próximas 12 horas, se pondrá en cuarentena a los usuarios con mayor actividad. Cuando en una base de datos hay muchos buzones, esto puede significar que en un corto periodo de tiempo se han puesto en cuarentena muchos buzones.
¿Qué se puede hacer?
Evidentemente no es deseable tener muchos buzones en cuarentena, ya que provoca interrupciones a los usuarios, aunque es preferible a que se desmonte una base de datos entera porque falte espacio en disco, lo que provocará una interrupción para todos los usuarios de la base de datos en cuestión. A pesar de que los buzones en cuarentena pueden liberarse manualmente quitando el GUID de ese buzón del registro , esta no es una solución óptima, ya que la próxima vez que se ejecute el monitor esos mismos buzones podrían terminar poniéndose de nuevo en cuarentena.
Los buzones en cuarentena se identifican en la siguiente ubicación:
Hkey_Local_Machine\SYSTEM\CurrentControlSet\Services\MSexchangeIS\Servername\Private-<D Bguid>\Quarantined Mailboxes\ {Mailbox GUID}
Nos gustaría que sepa que somos conscientes de esta situación y de que estamos trabajando para implementar una corrección. Mientras trabajamos para llegar a la mejor manera de impedir que esto llegue a más, querríamos facilitarle una solución alternativa que puede implementarse para impedir que los buzones se pongan en cuarentena. Entretanto, para evitar que haya más clientes que se encuentren con este problema, hemos eliminado temporalmente el Paquete de administración SP2 de Exchange 2010 del Centro de descargas.
Solución alternativa
Crear una invalidación para deshabilitar los monitores que comprueban el espacio libre en disco. Esto impedirá que se ejecute el archivo Troubleshoot-DatabaseSpace.ps1.
Al crear invalidaciones, lo mejor es colocarlas en un paquete de administración nuevo específico para personalizaciones de System Center Operations Manager. Esto le permite administrar las invalidaciones u otras configuraciones personalizadas de un modo rápido y sencillo. Si todavía no tiene un paquete de administración para esto, puede crear uno siguiendo los pasos que se presentan a continuación:
- En la Consola de operaciones, haga clic en el botón Administración . En el Panel de administración, haga clic con el botón secundario en Paquetes de administración y después haga clic en Crear paquete de administración . Entonces aparece el asistente Crear un paquete de administración .
- En la página Propiedades generales , escriba un nombre para el paquete de administración en Nombre , el número de versión correcto en Versión y una breve descripción en Descripción . Haga clic en Siguiente y después en Crear .
Cuando haya designado un paquete de administración para las invalidaciones, necesitará crearlas para los 4 monitores que se enumeran aquí:
En System Center Operations Manager, vaya al módulo Creación y después a Monitores en Objetos del paquete de administración . Los monitores pueden deshabilitarse estableciendo una Invalidación y escogiendo deshabilitar el Monitor para todos los objetos de la clase Espacio en disco lógico BD de la copia de la base de datos (tal como se muestra a continuación):
Active el cuadro al lado de Habilitado y después modifique el valor de invalidación seleccionando Falso:
En el mismo cuadro de diálogo de las Propiedades de la Invalidación, asegúrese de seleccionar el paquete de administración designado para personalizaciones.
En este punto suponemos que se está viendo impactado porque los buzones se pongan en cuarentena; la opción de deshabilitar los Monitores es la única solución alternativa disponible. Somos conscientes de que esto puede evitar que los administradores reciban alertas cuando haya poco espacio en disco, pero consideramos que es la mejor opción para evitar que los buzones se pongan en cuarentena hasta que se publique una solución.
Tenga en cuenta que cuando hay poco Espacio de la base de datos se sigue recibiendo una alerta cuando la unidad de registro de transacciones coexiste con la base de datos, ya que se genera por una regla diferente basada exclusivamente en el rendimiento.
Ben Winzenz, Kevin Carker
Esta entrada de blog es una traducción. Puede encontrar el artículo original en Mailboxes on a database are Quarantined in an environment with System Center Operations Manager