Supervisión de la alta disponibilidad y la resistencia de sitios

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

Última modificación del tema: 2015-03-09

Asegurarse de que los servidores funcionan de forma confiable y que las copias de base de datos están en buen estado son los objetivos clave para las operaciones diarias de mensajería. Para contribuir a garantizar la disponibilidad y confiabilidad de su organización de Microsoft Exchange Server 2010, deberá supervisar activamente el hardware, el sistema operativo de Windows y los servicios de Exchange 2010. La supervisión proactiva combinada con un mantenimiento preventivo le puede ayudar a identificar errores potenciales antes de que se produzca un problema grave que interfiera con el funcionamiento de la organización de Exchange.

La supervisión de la organización de Exchange implica la comprobación regular de problemas relacionados con servicios o datos. La supervisión suele incluir un sistema de notificaciones que envía advertencias cuando se producen problemas. Windows Server 2008 y Exchange 2010 incluyen algunas herramientas y servicios que le ayudan a garantizar que la organización de Exchange funciona sin problemas. Las principales ventajas respecto a la supervisión diaria son:

• Se cumplen los requisitos de los acuerdos de nivel de servicio (SLA).

• Se puede garantizar que las tareas administrativas específicas se completan correctamente (por ejemplo, las operaciones diarias de copia de seguridad)

• Se detectan y resuelven los problemas (por ejemplo, problemas que pueden afectar al servicio de mensajería o a la disponibilidad de datos)

Dentro de una organización de Exchange 2010, se deben formalizar los procedimientos, las funciones y las responsabilidades implicadas en las operaciones. Es importante comprender la relación entre el uso de prácticas y procedimientos eficaces y el buen estado de una infraestructura. Los procesos y procedimientos operativos completos y bien documentados ayudan a garantizar que todos los componentes del entorno de una organización de los que depende Exchange se administren de un modo eficaz y eficiente. 

Exchange 2010 incluye varias herramientas, scripts y características integrados que se pueden usar como parte de la supervisión proactiva regular cuando se configura Exchange para alta disponibilidad y resistencia de sitios. Los cmdlets de supervisión principales para la alta disponibilidad y la resistencia de sitios son Get-MailboxDatabaseCopyStatus y Test-ReplicationHealth. Además de disponer de cmdlets que realizan funciones de supervisión e informan sobre el estado, Exchange 2010 también incorpora una nueva secuencia de registro de eventos que permite aprovechar las capacidades del canal Crimson de Windows Server, así como scripts integrados que recopilan y analizan datos de dichos canales de eventos.

Puede usar la información de este tema para supervisar el estado de mantenimiento de las copias de la base de datos de buzones para grupos de disponibilidad de base de datos (DAG).

Contenido

Cmdlet Get-MailboxDatabaseCopyStatus

Cmdlet Test-ReplicationHealth

Registro de eventos de canal Crimson

Script CollectOverMetrics.ps1

Script de CollectReplicationMetrics.ps1

Script CheckDatabaseRedundancy.ps1

Cmdlet Get-MailboxDatabaseCopyStatus

Puede usar el cmdlet Get-MailboxDatabaseCopyStatus para ver información de estado de las copias de bases de datos de buzones. Este cmdlet permite ver información sobre todas las copias de una base de datos determinada, información sobre una copia específica de una base de datos en un servidor determinado o información sobre todas las copias de bases de datos de un servidor. La tabla siguiente describe los posibles valores del estado de una copia de base de datos de buzones de correo.

Estado de copia de base de datos

El cmdlet Get-MailboxDatabaseCopyStatus también incluye un parámetro denominado ConnectionStatus, que devuelve datos sobre las redes de replicación en uso. Si usa este parámetro, se rellenarán dos campos de salida adicionales, IncomingLogCopyingNetwork y SeedingNetwork en el resultado de la tarea.

Ejemplos de Get-MailboxDatabaseCopyStatus

Los ejemplos siguientes usan el cmdlet Get-MailboxDatabaseCopyStatus. Cada ejemplo envía los resultados al cmdlet Format-List para que los muestre en formato de lista.

En este ejemplo se devuelve información de estado para todas las copias de la base de datos DB2.

Get-MailboxDatabaseCopyStatus -Identity DB2 | Format-List

En este ejemplo se devuelve el estado de todas las copias de base de datos del servidor de buzones MBX2.

Get-MailboxDatabaseCopyStatus -Server MBX2 | Format-List

En este ejemplo se devuelve el estado de todas las copias de base de datos del servidor de buzones local.

Get-MailboxDatabaseCopyStatus -Local | Format-List

En este ejemplo se devuelve el estado, el envío de registros y la información de redes de propagación de la base de datos DB3 del servidor de buzones MBX1.

Get-MailboxDatabaseCopyStatus -Identity DB3\MBX1 -ConnectionStatus | Format-List

Para obtener más información acerca del cmdlet Get-MailboxDatabaseCopyStatus, consulte Get-MailboxDatabaseCopyStatus.

Cmdlet Get-MailboxDatabaseCopyStatus

Cmdlet Test-ReplicationHealth

Puede usar el cmdlet Test-ReplicationHealth para ver información de estado de la replicación continua de copias de bases de datos de buzones. Use el cmdlet para comprobar todos los aspectos del estado de replicación y reproducción con el fin de proporcionar una descripción general completa de un servidor de buzones de correo concreto de un grupo de disponibilidad de base de datos (DAG).

El cmdlet Test-ReplicationHealth está diseñado para realizar una supervisión proactiva de la replicación continua y de la canalización de replicación continua, la disponibilidad de Active Manager, el estado y el mantenimiento del servicio de clúster subyacente, así como de los componentes de quórum y de red. Se puede ejecutar de forma local o remota en cualquier servidor de buzones de un grupo de disponibilidad de base de datos. El cmdlet Test-ReplicationHealth realiza las pruebas que se enumeran en la tabla siguiente.

Pruebas del cmdlet Test-ReplicationHealth

Ejemplo de Test-ReplicationHealth

En este ejemplo se usa el cmdlet Test-ReplicationHealth para comprobar el mantenimiento de replicación del servidor de buzones de correo MBX1.

Test-ReplicationHealth -Identity MBX1

Cmdlet Get-MailboxDatabaseCopyStatus

Registro de eventos de canal Crimson

Windows Server 2008 incluye dos categorías de registros de eventos: Registros de Windows y registros de aplicaciones y servicios. La categoría de registros de Windows incluye los registros de eventos disponibles en versiones anteriores de Windows: Registros de eventos de aplicaciones, seguridad y sistema. También incluye dos nuevos registros: Setup y ForwardedEvents. Los registros de Windows tienen como objetivo almacenar eventos de aplicaciones heredadas y eventos que se aplican a todo el sistema.

Los registros de aplicaciones y servicios son una nueva categoría de registros de eventos. Estos registros almacenan eventos de una única aplicación o de un único componente, en lugar de eventos que pueden tener incidencia en todo el sistema. A esta nueva categoría de registros de eventos se alude como a un canal Crimson de aplicaciones.

La categoría de los registros de aplicaciones y servicios incluye cuatro subtipos: Registros administrativos, operativos, analíticos y de depuración. Los eventos de los registros administrativos son especialmente interesantes si el motivo por el que lleva un registro de eventos es para solucionar problemas. Los eventos en el registro administrativo deben proporcionar ayuda sobre cómo responder a los eventos. Los eventos del registro operativo también son útiles, pero quizá sea necesario un conocimiento más profundo. Los registros administrativos y de depuración no son especialmente sencillos para el usuario. Los registros analíticos (que aparecen ocultos o deshabilitados de manera predeterminada) almacenan eventos que hacen un seguimiento de un problema, y suele haber un número elevado de eventos registrado. Los registros de depuración son utilizados por los desarrolladores para depurar aplicaciones.

Exchange 2010 registra eventos en los canales Crimson del área de registros de aplicaciones y servicios. Puede ver estos canales si sigue los pasos que se detallan a continuación:

1. Abra el Visor de eventos:

2. En el árbol de la consola, vaya a Registros de aplicaciones y servicios > Microsoft > Exchange.

3. En Exchange, seleccione un canal Crimson: HighAvailability o MailboxDatabaseFailureItems.

El canal HighAvailability contiene eventos relacionados con el inicio y apagado del servicio de replicación de Microsoft Exchange, y los diferentes componentes que se ejecutan en el servicio de replicación de Microsoft Exchange, como Active Manager, una API de replicación sincrónica de otros fabricantes, el servidor RPC de tareas, el proceso de escucha TCP y el escritor del servicio de instantáneas de volumen (VSS). El canal HighAvailability también es utilizado por Active Manager para registrar eventos relacionados con la supervisión de funciones de Active Manager y eventos de acción de base de datos, como la operación de montaje de base de datos y la truncación de registros, y también para registrar eventos relacionados con el clúster subyacente del grupo de disponibilidad de bases de datos.

El canal MailboxDatabaseFailureItems se usa para registrar eventos asociados con errores que afectan a una base de datos de buzones de correo replicada.

Cmdlet Get-MailboxDatabaseCopyStatus

Script CollectOverMetrics.ps1

Exchange 2010 incluye un script denominado CollectOverMetrics.ps1, que puede encontrar en la carpeta Scripts. CollectOverMetrics.ps1 lee los registros de eventos de los miembros del DAG para recopilar información sobre las operaciones de base de datos (como montajes, movimientos y conmutación por error de bases de datos) durante un período de tiempo específico. Para cada operación, el script registra la información siguiente:

• Identidad de la base de datos

• La hora a la que ha comenzado y finalizado la operación

• Los servidores en los que se había montado la base de datos al inicio y al final de la operación

• La razón de la operación

• Si la operación se ha completado correctamente o si ha dado error y, en tal caso, se incluyen los detalles del error.

Este script escriba la información en archivos .csv con una operación por fila. Escribe un archivo .csv por separado para cada DAG.

El script admite parámetros que permiten personalizar el comportamiento y los resultados del mismo. Por ejemplo, los resultados se pueden restringir a un subconjunto especificado mediante el parámetro Database o ReportFilter. Solamente se incluirán en el informe HTML de resumen las operaciones que coincidan con estos filtros. En la tabla siguiente se muestran los parámetros disponibles:

Parámetros del script CollectOverMetrics.ps1

Ejemplos de CollectOverMetrics.ps1

En el ejemplo siguiente se recopila la métrica de todas las bases de datos que coinciden con DB* (la búsqueda incluye un carácter comodín) en un DAG denominado DAG1. Una vez recopilada la métrica, se genera y muestra un informe HTML.

CollectOverMetrics.ps1 -DatabaseAvailabilityGroup DAG1 -Database:"DB*" -GenerateHTMLReport -ShowHTMLReport

En los ejemplos siguientes se describen distintos métodos para filtrar el informe HTML de resumen. En el primero se usa el parámetro Database que toma una lista de nombres de bases de datos. El informe de resumen solamente contiene datos sobre estas bases de datos. En los dos ejemplos siguientes se usa la opción ReportFilter. En el último ejemplo se filtran todas las bases de datos predeterminadas.

CollectOverMetrics -SummariseCsvFiles (dir *.csv) -Database MailboxDatabase123,MailboxDatabase456
CollectOverMetrics -SummariseCsvFiles (dir *.csv) -ReportFilter { $_.DatabaseName -notlike "Mailbox Database*" }
CollectOverMetrics -SummariseCsvFiles (dir *.csv) -ReportFilter { ($_.ActiveOnStart -like "ServerXYZ*") -and ($_.ActiveOnEnd -notlike "ServerXYZ*") }

Cmdlet Get-MailboxDatabaseCopyStatus

Script de CollectReplicationMetrics.ps1

CollectReplicationMetrics.ps1 es otro script de métrica de estado incluido en Exchange 2010. Este script es un método activo de supervisión, porque recopila la métrica en tiempo real, mientras se ejecuta el script. CollectReplicationMetrics.ps1 recopila datos de contadores de rendimiento relacionados con la replicación de base de datos. El script reúne datos de varios servidores de buzones, escribe los datos de cada servidor en un archivo .csv y, a continuación, realiza un informe con varias estadísticas sobre todos los datos (por ejemplo, la cantidad de tiempo durante el cual cada copia estuvo en estado de error o suspendida, la longitud media de cola de copia o de reproducción, o la cantidad de tiempo durante el cual las copias no han cumplido los criterios de conmutación por error).

Puede especificar los servidores individualmente o bien especificar DAG enteros. Puede ejecutar el script para primero recopilar los datos y, a continuación, general el informe, o bien ejecutarlo para solamente reunir los datos o solamente generar el informe sobre los datos que ya se hayan recopilado. Puede especificar la frecuencia a la que debe realizarse el muestreo de los datos y la duración total para reunir los datos.

Los datos recopilados de cada servidor se escriben en un archivo llamado CounterData.<ServerName>.<TimeStamp>.csv. El informe de resumen se escribirá en un archivo denominado HaReplPerfReport.<DAGName>.<TimeStamp>.csv o HaReplPerfReport.<TimeStamp>.csv si no ejecutó el script con el parámetro DagName.

El script inicia trabajos de PowerShell para recopilar los datos de cada servidor. Estos trabajos se ejecutan durante todo el período en que se recopilan los datos. Si especifica una gran cantidad de servidores, puede que este proceso use una cantidad de memoria considerable. La fase final del proceso, cuando los datos se procesan en un informe de resumen, también puede llevar bastante tiempo si se trata de grandes cantidades de datos. Es posible ejecutar la fase de recopilación en un equipo y, a continuación, copiar los datos en otro lugar para su procesamiento.

El script CollectReplicationMetrics.ps1 admite parámetros que permiten personalizar el comportamiento y los resultados del mismo. En la tabla siguiente se muestran los parámetros disponibles:

Parámetros del script CollectReplicationMetrics.ps1

Ejemplo de CollectReplicationMetrics.ps1

En el ejemplo siguiente se reúnen los datos equivalentes a una hora de trabajo de todos los servidores que se encuentran en el DAG "DAG1", con un muestreo basado en intervalos de un minuto y, a continuación, se genera un informe de resumen. Asimismo, se usa el parámetro ReportPath, que hace que el script coloque todos los archivos en el directorio actual.

CollectReplicationMetrics.ps1 -DagName DAG1 -Duration "01:00:00" -Frequency "00:01:00" -ReportPath

En el ejemplo siguiente se leen los datos de todos los archivos que coincidan con "CounterData*" y se genera un informe de resumen.

CollectReplicationMetrics.ps1 -SummariseFiles (dir CounterData*) -Mode ProcessOnly -ReportPath

Cmdlet Get-MailboxDatabaseCopyStatus

Script CheckDatabaseRedundancy.ps1

Tal y como su nombre indica, la finalidad del script CheckDatabaseRedundancy.ps1 es supervisar la redundancia de las bases de datos de buzones replicadas corroborando que, por lo menos, haya dos copias actuales configuradas que sean correctas, así como avisarle cuando solamente exista una copia correcta de una base de datos replicada. En tal caso, tanto las copias activas como las pasivas se cuentan a la hora de determinar la redundancia.

Cuando se instala el rol de servidor Buzón de correo, Exchange configura automáticamente el script CheckDatabaseRedundancy.ps1 para ejecutar una tarea programada denominada Alerta de una copia de base de datos. De forma predeterminada, la tarea programada Alerta de una copia de base de datos está configurada para ejecutarse cada 60 minutos. Puede modificar este comportamiento y la configuración de la tarea programada en el Programador de tareas de Windows. El script está diseñado para comprobar en primer lugar la pertenencia a grupos de disponibilidad de base de datos (DAG), por lo que si el servidor de buzones no es miembro de un DAG, el script se elimina inmediatamente.

El script se puede también ejecutar interactivamente desde la carpeta de scripts. Al ejecutar el script de forma interactiva, debe especificar el nombre de una base de datos o el nombre de un miembro de un DAG. Para especificar una base de datos, debe usar el parámetro MailboxDatabaseName y para especificar un miembro de un DAG, el parámetro MailboxServerName. Cuando se ejecuta de forma interactiva en la consola, el script realiza la comprobación de redundancia una sola vez y muestra el valor de CurrentState (rojo o verde) en la pantalla.

Como otros scripts y cmdlets, CheckDatabaseRedundancy.ps1 también puede ejecutarse en modo de supervisión y generar eventos si se añade el parámetro MonitoringContext. La tarea programada creada por Exchange ejecuta el script en el modo de supervisión. Este modo permite además que el script se invoque mediante una solución de supervisión, como Microsoft System Center Operations Manager (SCOM). En el modo de supervisión, el script genera eventos de alerta roja y alerta verde en el registro de eventos de la aplicación del servidor local. Los eventos de alerta roja (Id. de evento 4113) solamente se generan si la base de datos ha estado en “rojo” durante 20 minutos más (en total, no necesariamente consecutivos) en la ejecución de una hora de duración del script, y los eventos de alerta verde (Id. de evento 4114) se generan cuando la base de datos ha estado en “verde” durante 10 minutos consecutivos. De forma predeterminada, cuando se genera un evento de alerta roja, continúa notificándose cada 15 minutos.

Asimismo, el script cuenta con algunas otras opciones útiles. Por ejemplo, puede agregar el parámetro ShowDetailedErrors para obtener más detalles sobre los errores que se produzcan y el parámetro Verbose para obtener información adicional sobre resolución de problemas. El script también incluye un parámetro SendSummaryMailTos, que puede usarse para enviar un informe de resumen por correo electrónico a una lista de direcciones de correo electrónico especificadas cuando el script haya acabado de ejecutarse. De esta forma, los administradores pueden echar un vistazo rápido a los informes por hora para ver si se ha producido algún problema de redundancia. Si usa la función de correo electrónico, deberá incluir el parámetro SummaryMailFrom siempre que use el parámetro SendSummaryMailTos.

Microsoft recomienda ejecutar este script con regularidad, como parte de las operaciones de supervisión habituales mediante la tarea programada automática o un sistema de supervisión como SCOM. Para garantizar que no existan largos períodos en los que la redundancia de base de datos esté en peligro, ejecute el script cada 60 minutos. El script incluye un parámetro llamado TerminateAfterDurationSecs, que si se establece en -1 o 0 al ejecutar el script, puede usarse para ejecutar el script durante un período de tiempo infinito.

Si no ejecuta una solución de supervisión como SCOM, se aconseja permitir a la tarea programada creada automáticamente automatizar y programar la ejecución del script.

Existen problemas conocidos en el Programador de tareas de Windows Server 2008 SP2 que pueden hacer que se bloquee si ha programado una tarea de larga duración. Estos problemas no existen en Windows Server 2008 R2; así que si es posible, ejecute el script desde Windows Server 2008 R2. Si no puede ejecutar el script desde Windows Server 2008 R2, y lo está ejecutando desde Windows Server 2008 SP2, se aconsejan dos modificaciones. En primer lugar, en lugar de ejecutar el script con la supresión transitoria integrada de 60 minutos, ejecútelo cada 5 minutos mediante los parámetros siguientes:

CheckDatabaseRedundancy.ps1 -MonitoringContext -SleepDurationBetweenIterationsSecs:0 -TerminateAfterDurationSecs:1 -SuppressGreenEventForSecs:0 -ReportRedEventAfterDurationSecs:0 -ReportRedEventIntervalSecs:0 -ShowDetailedErrors

En segundo lugar, si es posible, use SCOM para definir el comportamiento de supresión transitoria (por ejemplo, si se registran 3 eventos de alerta roja en un período de 20 minutos, debe generarse una alerta, y si se registra un evento de alerta verde, debe cambiarse el valor de CurrentState a verde).

Si se modifica o elimina la tarea programada Alerta de una copia de base de datos, puede eliminarla y volver a programarla si ejecuta el comando siguiente:

schtasks /create /TN "Check Database Redundancy" /TR "Powershell.exe -NonInteractive -WindowStyle Hidden -command 'C:\Program Files\Microsoft\Exchange Server\V14\bin\RemoteExchange.ps1'; Connect-ExchangeServer -auto; 'C:\Program Files\Microsoft\Exchange Server\V14\Scripts\CheckDatabaseRedundancy.ps1 -MonitoringContext -ShowDetailedErrors -SummaryMailFrom:'SMTPFromAddress@contoso.com' -SendSummaryMailTos:@('SMTPToAddress@contoso.com') -ErrorAction:Continue" /RU SYSTEM /SC HOURLY

Reemplace los parámetros del script anterior por los parámetros que quiera usar. En el script también se describen parámetros adicionales para el mismo.

Si usa la herramienta de línea de comandos schtasks para crear una tarea programada, la opción /TR tiene un límite de 261 caracteres. El ejemplo anterior supera dicho límite. Si los parámetros y las rutas de acceso que usa hacen que la opción /TR supere los 261 caracteres, cree manualmente la tarea programada mediante el applet del Programador de tareas en el menú Herramientas administrativas. También puede copiar y pegar el XML siguiente en el Bloc de notas, editarlo según sea pertinente, guardarlo como archivo XML e importarlo mediante el applet del Programador de tareas.

<?xml version="1.0" encoding="UTF-16"?>
<Task version="1.2" xmlns="https://schemas.microsoft.com/windows/2004/02/mit/task">
  <RegistrationInfo>
    <Date>2010-05-11T15:55:47</Date>
    <Author>administrator</Author>
  </RegistrationInfo>
  <Triggers>
    <TimeTrigger>
      <Repetition>
        <Interval>PT1H</Interval>
        <StopAtDurationEnd>false</StopAtDurationEnd>
      </Repetition>
      <StartBoundary>2010-05-11T15:55:00</StartBoundary>
      <Enabled>true</Enabled>
    </TimeTrigger>
  </Triggers>
  <Principals>
    <Principal id="Author">
      <UserId>SYSTEM</UserId>
      <RunLevel>HighestAvailable</RunLevel>
    </Principal>
  </Principals>
  <Settings>
    <IdleSettings>
      <Duration>PT10M</Duration>
      <WaitTimeout>PT1H</WaitTimeout>
      <StopOnIdleEnd>true</StopOnIdleEnd>
      <RestartOnIdle>false</RestartOnIdle>
    </IdleSettings>
    <MultipleInstancesPolicy>IgnoreNew</MultipleInstancesPolicy>
    <DisallowStartIfOnBatteries>true</DisallowStartIfOnBatteries>
    <StopIfGoingOnBatteries>true</StopIfGoingOnBatteries>
    <AllowHardTerminate>true</AllowHardTerminate>
    <StartWhenAvailable>false</StartWhenAvailable>
    <RunOnlyIfNetworkAvailable>false</RunOnlyIfNetworkAvailable>
    <AllowStartOnDemand>true</AllowStartOnDemand>
    <Enabled>true</Enabled>
    <Hidden>false</Hidden>
    <RunOnlyIfIdle>false</RunOnlyIfIdle>
    <WakeToRun>false</WakeToRun>
    <ExecutionTimeLimit>PT72H</ExecutionTimeLimit>
    <Priority>7</Priority>
  </Settings>
  <Actions Context="Author">
    <Exec>
      <Command>Powershell.exe</Command>
      <Arguments>-NonInteractive -WindowStyle Hidden -command 'C:\Program Files\Microsoft\Exchange Server\V14\bin\RemoteExchange.ps1'; Connect-ExchangeServer -auto; C:\Operations\CheckDatabaseRedundancy.ps1 -MonitoringContext -ShowDetailedErrors -SummaryMailFrom:'SMTPFromAddress@contoso.com' -SendSummaryMailTos:@('SMTPToAddress@contoso.com') -ErrorAction:Continue</Arguments>
    </Exec>
  </Actions>
</Task>

Cmdlet Get-MailboxDatabaseCopyStatus

 © 2010 Microsoft Corporation. Reservados todos los derechos.