Descripción de Active Manager

 

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

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

Microsoft Exchange Server 2010 incluye un componente nuevo denominado Active Manager que proporciona funcionalidad para sustituir las características de administración de conmutación por error y modelos de recurso que venían con la integración del Servicio de clúster en versiones anteriores de Exchange. Exchange ya no utiliza el modelo de recurso de clúster para lograr alta disponibilidad. Los recursos de clúster de Exchange proporcionados por exres.dll ya no existen, incluyendo la construcción denominada "servidor de buzones de correo en clúster". Exchange utiliza un clúster de conmutación por error de Windows, pero no hay grupos de clústeres para Exchange y el clúster no contiene recursos de almacenamiento. Por lo tanto, si se examina el clúster mediante herramientas de administración de clústeres, sólo verá los principales recursos del clúster (dirección IP, nombre de red y, si es necesario, recurso de quórum). También estarán los nodos y las redes del clúster, pero éstos se administran desde Exchange y no desde el clúster o las herramientas de clústeres.

Active Manager se ejecuta como un rol en todos los servidores de buzones. Los servidores de buzones que no están configurados para la alta disponibilidad, solamente disponen de un rol de Active Manager: Active Manager independiente. En los servidores que son miembros de un grupo de disponibilidad de base de datos (DAG), existen dos roles de Active Manager: Primary Active Manager (PAM) y Standby Active Manager (SAM). PAM es el Active Manager de un DAG que decide qué copias son activas y qué copias son pasivas. PAM se encarga de recibir las notificaciones de cambio de topología y de reaccionar a los errores de servidor. El miembro de DAG que posee el rol de PAM siempre es aquél que actualmente posee el recurso de quórum de clúster (grupo de clústeres predeterminado). Si el servidor que posee el recurso de quórum de clúster experimenta un error, el rol de PAM pasa automáticamente a un servidor subsistente que se apropia del recurso de quórum de clúster. Además, si necesita desconectar el servidor que hospeda el recurso de quórum de clúster para realizar tareas de mantenimiento o una actualización, primero deberá mover el PAM a otro servidor del DAG. El PAM controla todo el movimiento de las designaciones activas entre las copias de una base de datos (sólo puede haber una copia activa a la vez, que puede estar montada o desmontada). El PAM también realiza las funciones del rol de SAM en el sistema local (detección de errores en bases de datos locales y almacenes de información locales).

El SAM proporciona información acerca del servidor que hospeda la copia activa de una base de datos de buzones de correo a otros componentes de Exchange que ejecutan un componente de cliente de Active Manager (por ejemplo, un servicio de acceso de cliente RPC o un servidor Transporte de concentradores). El SAM detecta los errores de bases de datos locales y el almacén de información local. Reacciona a los errores solicitando al PAM que inicie un proceso de conmutación por error (si se ha replicado la base de datos). Un SAM no determina el destino de una conmutación por error ni actualiza el estado de ubicación de una base de datos en el PAM. Obtendrá acceso al estado de ubicación de la copia de base de datos activa para responder a las consultas que recibe sobre la copia activa de la base de datos.

Nota

Exchange 2010 no es una aplicación agrupada en clúster. En lugar de ello, utiliza las funciones de la biblioteca de clústeres implementadas en clusapi.dll para clústeres, grupos, redes de clústeres (latentes), administración de nodos, registro de clústeres y varias funciones de códigos de control. Además, Active Manager almacena la información actual de bases de datos de buzones de correo (por ejemplo, datos activos y pasivos, y datos montados) en la base de datos del clúster. Aunque la información se almacena directamente en la base de datos de clúster, ningún otro componente tiene acceso directo a ésta.

En Exchange 2010, el servicio de replicación de Microsoft Exchange supervisa periódicamente el mantenimiento de todas las bases de datos montadas. También supervisa el Motor de almacenamiento extensible (ESE) para detectar errores o problemas de E/S. Cuando el servicio detecta un error, lo notifica a Active Manager. A continuación, Active Manager determina qué copia de base de datos se debe montar y qué se requiere para hacerlo. Además, realiza un seguimiento de la copia activa de una base de datos de buzones de correo (en base a la última copia montada de la base de datos) y proporciona la información de los resultados del seguimiento al componente de acceso de cliente RPC en el servidor de acceso de cliente al cual éste está conectado.

Selección de la mejor copia por parte de Active Manager

Cuando se produce un error que afecta a una base de datos de buzones replicada, Active Manager lleva a cabo varios pasos para recuperarse del error seleccionando la mejor copia posible de la base de datos errónea que se debe activar. El proceso general tiene lugar en el siguiente orden:

  1. Active Manager detecta el error.

  2. El PAM ejecuta un algoritmo interno denominado selección de la mejor copia (BCS).

  3. Se lleva a cabo un proceso llamado intento de copia de los últimos registros (ACLL), que intenta copiar los archivos de registro que falten del servidor que hospedaba la copia de la base de datos activa antes de que se produjera el error.

  4. Una vez completado el proceso ACLL, el PAM emite una solicitud de montaje al Almacén de información de Microsoft Exchange mediante llamada a procedimiento remoto (RPC). Llegados a este punto, existen dos posibilidades:

    1. Se monta la base de datos y pasa a estar disponible para los clientes.

    2. No se monta la base de datos y el PAM realiza los pasos 3 y 4 en la siguiente mejor copia (si hay alguna disponible).

Cuando se busca la mejor copia posible, el PAM usa hasta diez conjuntos de criterios independientes para determinar la mejor copia para la activación. Una vez localizada la mejor copia posible, se ejecuta el proceso ACLL. Una vez completado el proceso ACLL, si se han copiado todos los archivos de registro que faltaban de la copia activa anterior, la base de datos se monta sin pérdidas de datos. Esto se conoce como conmutación por error sin pérdidas. Si el proceso ACLL no se realiza correctamente, se consulta el valor configurado para AutoDatabaseMountDial. Para obtener más información acerca de AutoDatabaseMountDial, consulte Set-MailboxServer. Si el número de registros perdidos se encuentra dentro del valor configurado para AutoDatabaseMountDial, se monta la base de datos. Si el número de registros perdidos se encuentra fuera del valor configurado para AutoDatabaseMountDial, la base de datos no se monta hasta que no se recuperen los archivos de registro que faltan o hasta que un administrador monte explícitamente la base de datos y acepte la mayor pérdida de datos. Si la base de datos no se monta automáticamente, el PAM seleccionará la siguiente mejor copia (si hay alguna disponible). Existen como mínimo tres razones por las que la copia de base de datos seleccionada inicialmente no se monta de forma automática:

  1. El número de archivos de registro perdidos es mayor que el valor configurado para AutoDatabaseMountDial.

  2. El servidor en que se haya realizado el intento de montaje está configurado con un valor máximo bajo para el número activo de bases de datos y se ha alcanzado el número máximo de copias de bases de datos activas en el servidor.

  3. La copia de la base de datos está suspendida para la activación.

Proceso de selección de la mejor copia

Active Manager inicia el proceso de selección de la mejor copia creando una lista de copias de base de datos que son posibles candidatas para la activación. Las copias de base de datos a las que no se pueda obtener acceso o que estén bloqueadas administrativamente para la activación (mediante el uso de la propiedad DatabaseCopyAutoActivationPolicy del cmdlet Set-MailboxServer) se ignoran y no se usan durante el proceso de selección. El orden de la lista depende de la versión de Exchange 2010:

  • En la versión RTM de Exchange 2010, Active Manager ordena la lista de resultados usando la longitud de cola de la copia como clave principal. El cálculo se basa en LastLogInspected (desde el punto de vista de la copia), por lo que la lista de posibles copias se ordena según el valor más alto para LastLogInspected (que será la copia con la longitud de cola de copia menor). A continuación, Active Manager ordena la lista por segunda vez, con el valor para ActivationPreference como clave secundaria. La copia con el valor de ActivationPreference más bajo tiene la máxima prioridad en la lista.

  • En Exchange 2010 Service Pack 1 (SP1), el comportamiento es el mismo que en la versión RTM, excepto en el caso de los servidores configurados con el valor de marcado automático de montaje de la base de datos Lossless. Cuando se usa este valor, Active Manager ordena la lista de resultados en orden ascendente usando el valor para ActivationPreference como clave principal. Este comportamiento es intencionado, con el objetivo de que el desequibilibrio de la base de datos se minimice mediante las operaciones de movimiento (como los cambios o la ejecución de StartDagServerMaintenance.ps1).

A continuación, Active Manager intenta localizar una copia de la base de datos de buzones en la lista cuyo estado sea Healthy, DisconnectedAndHealthy, DisconnectedAndResynchronizing o SeedingSource y evalúa el potencial de activación de cada una de las copias de la lista mediante un conjunto ordenado de diez criterios. Active Manager determina si alguno de las copias candidatas para la activación cumple el primer conjunto de criterios:

  • Tiene un índice de contenido con un estado Correcto.

  • Tiene una longitud de la cola de copia inferior a 10 archivos de registro.

  • Tiene una longitud de la cola de reproducción inferior a 50 archivos de registro.

Si ninguna de las copias de base de datos cumple el primer conjunto de criterios, Active Manager intenta localizar una copia de base de datos que cumpla el segundo conjunto de criterios:

  • Tiene un índice de contenido con un estado de rastreo.

  • Tiene una longitud de la cola de copia inferior a 10 archivos de registro.

  • Tiene una longitud de la cola de reproducción inferior a 50 archivos de registro.

Si ninguna de las copias de base de datos cumple el segundo conjunto de criterios, Active Manager intenta localizar una copia de base de datos que cumpla el tercer conjunto de criterios:

  • Tiene un índice de contenido con un estado Correcto.

  • Tiene una longitud de la cola de reproducción inferior a 50 archivos de registro.

Si ninguna de las copias de base de datos cumple el tercer conjunto de criterios, Active Manager intenta localizar una copia de base de datos que cumpla el cuarto conjunto de criterios:

  • Tiene un índice de contenido con un estado de rastreo.

  • Tiene una longitud de la cola de reproducción inferior a 50 archivos de registro.

Si ninguna de las copias de base de datos cumple el cuarto conjunto de criterios, Active Manager intenta localizar una copia de base de datos que cumpla el quinto conjunto de criterios:

  • Tiene una longitud de la cola de reproducción inferior a 50 archivos de registro.

Si ninguna de las copias de base de datos cumple el quinto conjunto de criterios, Active Manager intenta localizar una copia de base de datos que cumpla el sexto conjunto de criterios:

  • Tiene un índice de contenido con un estado Correcto.

  • Tiene una longitud de la cola de copia inferior a 10 archivos de registro.

Si ninguna de las copias de base de datos cumple el sexto conjunto de criterios, Active Manager intenta localizar una copia de base de datos que cumpla el séptimo conjunto de criterios:

  • Tiene un índice de contenido con un estado de Crawling.

  • Tiene una longitud de cola de copia inferior a 10 archivos de registro.

Si ninguna de las copias de base de datos cumple el séptimo conjunto de criterios, Active Manager intenta localizar una copia de base de datos que cumpla el octavo conjunto de criterios:

  • Tiene un índice de contenido con un estado Correcto.

Si ninguna de las copias de base de datos cumple el octavo conjunto de criterios, Active Manager intenta localizar una copia de base de datos que cumpla el noveno conjunto de criterios:

  • Tiene un índice de contenido con un estado de rastreo.

Si ninguna de las copias de base de datos cumple el noveno conjunto de criterios, Active Manager intenta activar cualquier copia de base de datos que tenga el estado Healthy, DisconnectedAndHealthy, DisconnectedAndResynchronizing o SeedingSource (el décimo conjunto de criterios). Si no encuentra ninguna copia de base de datos que cumpla el décimo conjunto de criterios, no podrá activar automáticamente ninguna copia de base de datos.

Una vez localizadas una o más copias que cumplan uno o más conjuntos de criterios, se ejecuta el proceso ACLL para copiar los archivos de registro de la copia original a la nueva posible copia activa. Una vez completado el proceso ACLL, el PAM emite una solicitud de montaje y se monta la base de datos, que pasa a estar disponible para los clientes, o bien no se monta la base de datos y el PAM busca la siguiente mejor copia (si hay alguna disponible).

Ejemplos de selección de la mejor copia

En la sección siguiente se muestran algunos ejemplos del proceso de selección y activación de la mejor copia de Active Manager.

Ejemplo 1: Escenario básico

En este ejemplo, hay cuatro copias de la base de datos de buzones DB1. DB1 actualmente está activa en Server1, donde se ha producido un error de hardware. En la tabla siguiente se muestra el estado actual de las copias de base de datos de DB1 en Server2, Server3 y Server4.

Copia de base de datos Preferencia de activación Longitud de cola de copia Longitud de cola de reproducción Estado del índice de contenido Estado de la base de datos Activación bloqueada

Server2\DB1

2

4

0

Healthy

Healthy

No

Server3\DB1

3

2

2

Healthy

DisconnectedAndHealthy

No

Server4\DB1

4

10

0

Crawling

Healthy

No

Si las copias disponibles se ordenan según la longitud de la cola de copia (usando Preferencia de activación, si es preciso) el resultado es una lista ordenada del siguiente modo:

  • Server3\DB1

  • Server2\DB1

  • Server4\DB1

En esta lista solamente dos copias de base de datos cumplen el primer conjunto de criterios para la activación:

  • La copia de Server3, que tiene el estado de base de datos Disconnectedandhealthy, una longitud de cola de copia inferior a 10, una longitud de cola de reproducción inferior a 50 y un índice de contenido correcto.

  • La copia de Server2, que tiene el estado de base de datos Healthy, una longitud de cola de copia inferior a 10, una longitud de cola de reproducción inferior a 50 y un índice de contenido correcto.

Entre estas dos copias, la copia de Server3 tiene la longitud de cola de copia más baja; por tanto, Server3 se selecciona como la copia para intentar activar ya que es a la que le faltan menos datos.

Una vez activada la copia de Server3, el servicio de replicación de Microsoft Exchange de Server3 lleva a cabo el proceso ACLL e intenta copiar los archivos de registro que faltan del servidor activo anterior (en este caso, Server1). Una vez completado el proceso ACLL, se notifican al PAM los resultados del proceso ACLL. Si todos los registros se copian correctamente, la base de datos se marcará como copia activa y se montará sin pérdida de datos. Si faltan uno o más registros, se consulta el valor del parámetro AutoDatabaseMountDial. Si la pérdida de datos queda contemplada en el valor configurado, la base de datos se marcará como copia activa y se montará con pérdida de datos. En tal caso, la mayoría de los datos que falten se recuperará del contenedor de transporte.

Si Active Manager no envía una solicitud de montaje al Almacén de información y la operación de montaje no se completa correctamente, Active Manager volverá a la lista ordenada anterior e intentará activar la mejor copia siguiente (en este caso, Server2).

Ejemplo 2: Dos copias con la misma longitud de cola de copia

En este ejemplo, hay cuatro copias de la base de datos de buzones DB2. DB2 actualmente está activa en Server1, donde se ha producido un error de hardware. En la tabla siguiente se muestra el estado actual de las copias de base de datos de DB2 en Server2, Server3 y Server4.

Copia de base de datos Preferencia de activación Longitud de cola de copia Longitud de cola de reproducción Estado del índice de contenido Estado de la base de datos Activación bloqueada

Server2\DB2

2

2

0

Healthy

Healthy

No

Server3\DB2

3

2

2

Healthy

DisconnectedAndHealthy

No

Server4\DB2

4

10

0

Crawling

Healthy

No

Si las copias disponibles se ordenan según la longitud de la cola de copia (usando Preferencia de activación, si es preciso) el resultado es una lista ordenada del siguiente modo:

  • Server2\DB2

  • Server3\DB2

  • Server4\DB2

En esta lista solamente dos copias de base de datos cumplen el primer conjunto de criterios para la activación:

  • La copia de Server2, que tiene el estado de base de datos Healthy, una longitud de cola de copia inferior a 10, una longitud de cola de reproducción inferior a 50 y un índice de contenido correcto.

  • La copia de Server3, que tiene el estado de base de datos DisconnectedandHealthy, una longitud de cola de copia inferior a 10, una longitud de cola de reproducción inferior a 50 y un índice de contenido correcto.

Entre estas dos copias, la copia de Server2 tiene una longitud de cola de copia igual a la de la copia de Server3, pero también tiene un valor de Preferencia de activación más bajo; por tanto, la copia de Server2 está al principio de la lista y se selecciona como la copia para intentar activar puesto que es a la que le faltan una menor cantidad de datos y que tiene el valor de Preferencia de activación más bajo.

Ejemplo 3: Copias con el estado de base de datos idéntico y el estado de índice de contenido diferente

En este ejemplo, hay cuatro copias de la base de datos de buzones DB3. DB3 actualmente está activa en Server1, donde se ha producido un error de hardware. En la tabla siguiente se muestra el estado actual de las copias de base de datos de DB3 en Server2, Server3 y Server4.

Copia de base de datos Preferencia de activación Longitud de cola de copia Longitud de cola de reproducción Estado del índice de contenido Estado de la base de datos Activación bloqueada

Server2\DB3

2

0

3

Crawling

Healthy

No

Server3\DB3

3

0

3

Healthy

DisconnectedAndHealthy

No

Server4\DB3

4

0

0

Healthy

Healthy

No

Si las copias disponibles se ordenan según la longitud de la cola de copia (usando Preferencia de activación, si es preciso) el resultado es una lista ordenada del siguiente modo:

  • Server2\DB3

  • Server3\DB3

  • Server4\DB3

Las tres copias de base de datos hospedadas en los servidores anteriores cumplen los criterios para la activación. A pesar de que Server2 tiene un valor de Preferencia de activación más bajo, su estado de índice de contenido es Crawling; por lo tanto, cuando Active Manager compruebe la lista conforme al primer conjunto de criterios (que incluye el estado de índice de contenido Healthy), se preferirá la copia de base de datos de Server3, puesto que su estado de índice de contenido es Healthy.

Ejemplo 4: Efecto de AutoDatabaseMountDial en la selección de la mejor copia

En este ejemplo, hay cuatro copias de la base de datos de buzones DB4. DB4 está actualmente activa en Server1, donde se ha producido un error que hace que se reinicie. En la tabla siguiente se muestra el estado actual de las copias de base de datos de DB4 en Server2, Server3 y Server4. El parámetro AutoDatabaseMountDial para todos los servidores de buzones del DAG se configura como Lossless (la longitud de cola de copia es 0).

Copia de base de datos Preferencia de activación Longitud de cola de copia Longitud de cola de reproducción Estado del índice de contenido Estado de la base de datos Activación bloqueada

Server2\DB4

2

0

4523

Healthy

Healthy

No

Server3\DB4

3

100

25

Crawling

Healthy

No

Server4\DB4

4

6

62

Healthy

Healthy

No

Puesto que el valor de marcado de montaje automático de la base de datos está definido en Lossless, Active Manager usa Preferencia de activación en lugar de la longitud de cola de la copia como clave principal de ordenación. Al ordenar las copias disponibles según sus resultados de Preferencia de activación, se obtiene una lista ordenada del modo siguiente:

  • Server2\DB4

  • Server3\DB4

  • Server4\DB4

Ninguna de las bases de datos cumplen el primero, segundo o tercer conjunto de criterios, pero la copia de base de datos de Server3 cumple el cuarto conjunto de criterios (tiene un estado de índice de contenido Crawling y una longitud de cola de reproducción inferior a 50). La copia de base de datos de Server3 tiene una longitud de cola de copia de 100, pero como Server1 todavía no ha acabado de reiniciarse, el proceso ACLL no puede copiar los archivos de registro que faltan en Server3. El proceso ACLL indica al PAM que la cantidad de datos que faltan no se encuentra dentro del valor configurado para el parámetro AutoDatabaseMountDial y, por tanto, el PAM selecciona la siguiente mejor copia disponible.

En el escenario anterior, las copias de base de datos de Server2 y Server4 cumplen el sexto conjunto de criterios (tienen una base de datos y un índice de contenido correctos, así como una longitud de cola de copia inferior a 10). Como se encuentra en una posición más alta en la lista ordenada de copias disponibles, se prueba con la copia de base de datos de Server2. El proceso ACLL se ejecuta en Server2, pero Server1 todavía no se comunica en la red y el proceso ACLL no puede copiar los registros. No obstante, como la longitud de cola de copia se encuentra dentro del valor configurado para el parámetro AutoDatabaseMountDial, ACLL envía un mensaje de operación correcta al PAM y éste emite una solicitud de montaje de base de datos a través de RPC.

 © 2010 Microsoft Corporation. Reservados todos los derechos.