Descripción de grupos de disponibilidad de base de datos

 

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

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

Un grupo de disponibilidad de base de datos (DAG) es el componente básico del marco de alta disponibilidad y resistencia de sitio que ofrece Microsoft Exchange Server 2010. Se trata de un grupo de hasta 16 servidores de buzones de correo que aloja un conjunto de bases de datos y proporciona recuperación automática en el nivel de la base de datos de los errores que afectan a los servidores o bases de datos individuales.

Un DAG es un límite para la replicación de bases de datos de buzones de correo, las conmutaciones por error y los cambios de bases de datos y de servidores, así como para un componente de Exchange 2010 interno denominado Active Manager. Active Manager se ejecuta en cualquiera de los servidores de un DAG; administra cambios y conmutaciones por error. Para obtener más información acerca de Active Manager, consulte Descripción de Active Manager.

Cualquier servidor en un DAG puede hospedar una copia de una base de datos de buzones de correo de cualquier otro servidor en el DAG. Cuando se agrega un servidor a un DAG, funciona con otros servidores en el DAG para proporcionar recuperación automática de errores que afectan a las bases de datos de buzones de correo, como un error de disco o de servidor.

Contenido

Ciclo de vida de un grupo de disponibilidad de base de datos

Uso de un grupo de disponibilidad de base de datos para obtener alta disponibilidad

Uso de un grupo de disponibilidad de base de datos para obtener resistencia de sitio

Experiencia del cliente al usar grupos de disponibilidad de base de datos

Ciclo de vida de un grupo de disponibilidad de base de datos

Los DAG utilizan una característica de Exchange 2010 denominada implementación incremental, que es la capacidad de implementar la disponibilidad de servicios y datos en todos los servidores y bases de datos de buzones de correo una vez que se ha instalado Exchange. Tras la implementación de Exchange 2010, se puede crear un DAG, agregarle servidores de buzones de correo y, a continuación, replicar las bases de datos de buzones entre los miembros del DAG.

Los DAG se crean con el cmdlet New-DatabaseAvailabilityGroup. Inicialmente se crean como objetos vacíos en Active Directory. Este objeto de directorio se usa para almacenar información relevante acerca del DAG, como la información de suscripción del servidor. Al agregar el primer servidor a un DAG, se crea automáticamente un clúster de conmutación por error para el DAG. El DAG usa de manera exclusiva este clúster de conmutación por error; dicho clúster debe dedicarse al DAG. El uso del clúster no se permite para ninguna otra finalidad.

Además de crearse un clúster de conmutación por error, se inicia la infraestructura que supervisa los servidores en busca de errores en la red o el servidor. El mecanismo de latidos del clúster de conmutación por error y la base de datos del clúster se usan para administrar la información sobre el DAG que puede cambiar rápidamente (como el estado de montaje de la base de datos, el estado de replicación y la última ubicación de montaje) y para realizar un seguimiento de dicha información.

Mientras se crea, el DAG recibe un nombre único y una o varias direcciones IP estáticas, o bien se configura para que use el Protocolo de configuración dinámica de host (DHCP). Puede especificar una única dirección IP o una lista de direcciones IP separadas por comas, utilizando el parámetro DatabaseAvailabilityGroupIPAddresses.

Este ejemplo muestra un DAG que tendrá tres servidores. Dos servidores (EX1 y EX2) están en la misma subred (10.0.0.0); el tercero (EX3) está en otra (192.168.0.0).

New-DatabaseAvailabilityGroup -Name DAG1 -DatabaseAvailabilityGroupIPAddresses 10.0.0.5,192.168.0.5
Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer EX1
Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer EX2
Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer EX3

El clúster para DAG1 se crea al agregar EX1 al DAG. Durante la creación de clústeres, el cmdlet Add-DatabaseAvailabilityGroupServer recupera las direcciones IP configuradas para el DAG e ignora las que no coinciden con ninguna de las subredes halladas en EX1. En este ejemplo, el clúster para DAG1 se crea con la dirección IP 10.0.0.5, mientras que 192.168.0.5 no se tiene en cuenta.

A continuación, se agrega EX2 y el cmdlet Add-DatabaseAvailabilityGroupServer recupera de nuevo las direcciones IP configuradas para el DAG. Las direcciones IP del clúster no cambian porque EX2 está en la misma subred que EX1.

A continuación, se agrega EX3 y el cmdlet Add-DatabaseAvailabilityGroupServer recupera de nuevo las direcciones IP configuradas para el DAG. Puesto que en EX3 hay una subred que coincide con 192.168.0.5, la dirección 192.168.0.5 se agrega como recurso de dirección IP al grupo de clústeres. Además, se configura automáticamente una dependencia OR para el recurso Nombre de red de cada recurso de dirección IP. El clúster utilizará la dirección 192.168.0.5 cuando el grupo de clústeres se mueva a EX3.

La agrupación en clústeres de conmutación por error de Windows registra la dirección IP del clúster en el Sistema de nombres de dominio (DNS) cuando el recurso Nombre de red se pone en línea. Además, se crea un objeto de nombre de clúster (CNO) en Active Directory. El sistema usa solo a nivel interno el nombre, las direcciones IP y el CNO para el clúster a fin de proteger el DAG y permitir la comunicación interna. Los administradores y los usuarios finales no necesitan conectarse a la dirección IP ni al nombre del DAG, ni usarlos como interfaz.

Además de recibir un nombre y una o varias direcciones IP, el DAG se configura también para que utilice un servidor testigo y un directorio testigo. El sistema especifica automáticamente el servidor testigo y el directorio testigo, aunque también los puede especificar manualmente el administrador.

De manera predeterminada, un DAG se diseña para que utilice la característica integrada de replicación continua y replique las bases de datos de buzones entre sus servidores. Si utiliza una replicación de datos de terceros que admite la API de replicación de terceros de Exchange 2010, deberá crear el DAG en el modo de replicación de terceros mediante el cmdlet New-DatabaseAvailabilityGroup con el parámetro ThirdPartyReplication. Una vez habilitado este modo, no se puede deshabilitar.

Una vez creado el DAG, se le pueden agregar servidores de buzones de correo. Cuando se agrega el primer servidor al DAG, se forma un clúster para que el DAG lo utilice. Los DAG hacen un uso limitado de la tecnología de clústeres de conmutación por error de Windows, concretamente el latido de clúster, las redes de clústeres y la base de datos de clústeres (para almacenar datos que cambian, por ejemplo el estado de base de datos que cambia de activa a pasiva y viceversa, o de montada a desmontada y viceversa). Al irse agregando al DAG cada uno de los siguientes servidores, se une al clúster subyacente, el sistema ajusta automáticamente el modelo de quórum del clúster y el servidor se agrega al objeto DAG en Active Directory.

Una vez que se han agregado servidores de buzones de correo al DAG, se pueden configurar algunas de las propiedades de este último, por ejemplo si se debe usar el cifrado de red o la compresión de red para la replicación de bases de datos en el DAG. También se pueden configurar las redes de DAG y crear más.

Una vez que se han agregado miembros al DAG y éste se ha configurado, las bases de datos de buzones activas de cada servidor se pueden replicar en los demás miembros del DAG. Después de crear copias de las bases de datos de buzones, se puede supervisar su estado de mantenimiento con varias herramientas de supervisión integradas. Además, puede realizar cambios de base de datos y servidores.

Para obtener más información sobre la creación de DAG, la administración de los miembros de los DAG, la configuración de propiedades de los DAG, la creación y supervisión de copias de bases de datos de buzones, y la realización de cambios, consulte Administración de la alta disponibilidad y la resistencia de sitios.

Modelos de quórum de grupos de disponibilidad de base de datos

Debajo de cada DAG hay un clúster de conmutación por error de Windows. Los clústeres de conmutación por error utilizan el concepto de quórum, que emplea un consenso de votantes para garantizar que solamente un subconjunto de miembros del clúster (que podría ser todos los miembros o una mayoría de miembros) funcione a la vez. El quórum no es un concepto nuevo para Exchange 2010. Los servidores Buzón de correos de alta disponibilidad de versiones anteriores de Exchange usan también la agrupación en clústeres de conmutación por error y su concepto de quórum. El quórum representa una visión compartida de los miembros y los recursos. Además, el término quórum se utiliza para describir los datos físicos que representan la configuración dentro del clúster que se comparte entre todos los miembros del clúster. A consecuencia de ello, todos los DAG necesitan su clúster de conmutación por error subyacente para tener quórum. Si el clúster pierde quórum, todas las operaciones del DAG terminarán y todas las bases de datos albergadas en el mismo se desmontarán. En este caso, será necesario que intervenga el administrador para corregir el problema de quórum y restaurar las operaciones del DAG.

El quórum es importante para asegurar la coherencia, como mecanismo para resolver empates y como garantía de la capacidad de respuesta de los clústeres:

• Garantizar la coherencia   Un requisito fundamental para un clúster de conmutación por error de Windows es que cada uno de sus miembros tenga siempre una vista del clúster que sea coherente con los otros miembros. La sección del clúster actúa como repositorio definitivo de toda la información de configuración relativa al clúster. Si la sección del clúster no puede cargarse localmente en un miembro del DAG, el servicio del clúster no se inicia al no poder garantizar que el miembro cumpla el requisito de tener una vista del clúster que sea coherente con los otros miembros.

• Mecanismo para resolución de empates   Se usa en los DAG un recurso de testigo de quórum con un número par de miembros para evitar el síndrome de cerebro dividido y asegurarse de que solamente se considere oficial una colección de los miembros del DAG. Cuando el servidor testigo se necesita para quórum, cualquier miembro del DAG que pueda comunicarse con el servidor testigo puede colocar un bloqueo de Bloque de mensajes del servidor en el archivo witness.log del servidor testigo. El miembro del DAG que bloquea el servidor testigo (denominado nodo de bloqueo) retiene un voto adicional por motivos de quórum. Los miembros del DAG que están en contacto con el nodo de bloqueo son mayoría y mantienen el quórum. Cualquier miembro del DAG que no pueda estar en contacto con el nodo de bloqueo forma parte de la minoría y por lo tanto pierde el quórum.

• Asegurar la capacidad de respuesta   Para garantizar la capacidad de respuesta, el modelo de quórum se asegura de que, siempre que se ejecute el clúster, estén operativos y comunicativos suficientes miembros del sistema distribuido, y de que se garantice al menos una réplica del estado actual del clúster. No se necesita tiempo adicional para poner en conexión otros miembros ni para determinar si está garantizada un réplica en concreto.

Los DAG con un número par de miembros usan el modo de quórum Mayoría de recursos compartidos de archivos y nodo del clúster, que emplea un servidor testigo externo que ejerce de mecanismo para resolver empates. En este modo de quórum, cada miembro de DAG obtiene un voto. Asimismo, el servidor testigo se usa para proporcionar a un miembro de DAG un voto ponderado (por ejemplo, obtiene dos votos en vez de uno). Los datos del quórum de clúster se almacenan de forma predeterminada en el disco del sistema de cada miembro del DAG y se mantienen coherentes en esos discos. Sin embargo, no se guarda una copia de los datos del quórum en el servidor testigo. Se utiliza un archivo en el servidor testigo para mantener un seguimiento del miembro que tiene la copia de datos más actualizada, pero el servidor testigo no tiene una copia de los datos de quórum del clúster. En este modo, una mayoría de los votantes (los miembros del DAG más el servidor testigo) deben estar operativos y poderse comunicar entre sí para mantener el quórum. Si la mayoría de los votantes no pueden comunicarse entre sí, el clúster subyacente del DAG pierde el quórum y para que el DAG vuelva a estar operativo requerirá una intervención del administrador.

Los DAG con un número impar de miembros usan un modo de quórum de nodos mayoritarios. En este modo, cada miembro obtiene un voto y el disco del sistema local de cada miembro se usa para almacenar los datos de quórum del clúster. Si la configuración del clúster cambia, ese cambio se refleja en todos los discos. El cambio solamente se considera efectuado y permanente si se realiza en los discos de la mitad de los miembros (redondeado) más uno. Por ejemplo, en un DAG de cinco miembros, el cambio debe efectuarse en dos miembros más uno, o en un total de tres miembros.

El quórum precisa una mayoría de votantes para que puedan comunicarse entre sí. Suponga un DAG con cuatro miembros. Como este DAG tiene un número par de miembros, un servidor testigo externo se emplea para proporcionar a uno de los miembros del clúster un quinto voto que resuelva el empate. Para mantener una mayoría de votantes, y por lo tanto quórum, debe haber al menos tres votantes a fin de poder comunicarse entre sí. Un máximo de dos votantes puede estar sin conexión en cualquier momento sin que se interrumpa el servicio y el acceso a los datos. Si tres votantes o más están sin conexión, el DAG pierde el quórum y el servicio y el acceso a los datos se interrumpirán hasta que se resuelva el problema.

Volver al principio

Uso de un grupo de disponibilidad de base de datos para obtener alta disponibilidad

Consulte el ejemplo, en el que se usa un DAG con cinco miembros, para obtener información sobre cómo los DAG pueden proporcionar alta disponibilidad para las bases de datos de buzones. Este DAG se muestra en la siguiente figura.

DAG con cinco miembros

En la figura anterior, las bases de datos verdes son copias de bases de datos de buzones activas y las azules son copias de bases de datos de buzones pasivas. En este ejemplo, las copias de bases de datos no se reflejan en cada uno de los servidores, si no que se distribuyen por varios servidores. De esta forma se garantiza que no haya dos servidores en un DAG con el mismo conjunto de copias de bases de datos. Así, se proporciona al DAG una mayor resistencia ante errores, incluidos los que tienen lugar mientras otros componentes están inactivos por razones de mantenimiento.

Observe la siguiente situación, en la que se usa el ejemplo de DAG anterior, y que muestra la resistencia ante varios errores de bases de datos y servidores.

Inicialmente, el estado de todas las bases de datos y servidores es correcto. Es necesario instalar algunas actualizaciones del sistema operativo en EX2. Efectúe un cambio de servidor. De este modo, activa la copia de DB4 en otro servidor de buzones de correo. Un cambio de servidor traslada todas las copias de bases de datos de buzones activas del servidor actual a uno o varios servidores Buzón de correo del DAG, como preparación ante el apagón programado del servidor actual. Puede realizar un cambio de servidor con rapidez si ejecuta el comando siguiente en el Shell de administración de Exchange.

Move-ActiveMailboxDatabase -Server EX2

En este ejemplo, solo hay una base de datos de buzones activa en EX2 (DB4), por lo que únicamente se mueve una copia de base de datos de buzones activa. Mediante la omisión del parámetro ActivateOnServer en el comando anterior, el administrador decide que sea el sistema el que seleccione la mejor copia activa nueva, y el sistema selecciona la copia que está en EX5, como se muestra en la figura siguiente.

DAG con un servidor sin conexión por razones de mantenimiento

Mientras se realiza el mantenimiento en EX2, EX3 queda sin conexión como consecuencia de un error grave de hardware. Antes de quedar sin conexión, EX3 hospedaba la copia activa de DB2. Para recuperarse del error, el sistema activa automáticamente la copia de DB2 hospedada en EX1 en menos de 30 segundos. Se muestra en la siguiente figura.

DAG con un servidor sin conexión por motivos de mantenimiento y un servidor con error

Una vez finalizado el mantenimiento programado de EX2, lo vuelve a poner en línea. En el momento en que EX2 está disponible, los demás miembros del DAG reciben una notificación al respecto, y las copias de DB1, DB4 y DB5 hospedadas en EX2 se sincronizan automáticamente con la copia activa de cada base de datos. Se muestra en la siguiente figura.

DAG con un servidor restaurado que sincroniza sus copias de bases de datos

Una vez que se sustituye el componente de hardware dañado en EX3, éste se pone en línea. Una vez que EX3 está disponible, los demás miembros del DAG reciben una notificación al respecto, y las copias de DB2, DB3 y DB4 hospedadas en EX3 se sincronizan automáticamente con la copia activa de cada base de datos. Se muestra en la siguiente figura.

DAG con un servidor reparado que sincroniza sus copias de bases de datos

Volver al principio

Uso de un grupo de disponibilidad de base de datos para obtener resistencia de sitio

Además de proporcionar alta disponibilidad en un centro de datos, un DAG se puede ampliar a otros centros de datos en una configuración que proporcione resistencia de sitio para uno o varios centros de datos. En las figuras del ejemplo anterior, el DAG está ubicado en un único centro de datos y un único sitio de Active Directory. La implementación incremental se puede utilizar para ampliar este DAG a otro centro de datos (y otro sitio de Active Directory) implementando un servidor de buzones de correo y los recursos de soporte necesarios (uno o más servidores de Active Directory, y uno o más servidores de transporte de concentradores y de acceso de cliente). A continuación, se agrega el servidor de buzones de correo al DAG, tal como se indica en la figura siguiente.

DAG ampliado en dos sitios de Active Directory

En este ejemplo, una copia pasiva de cada base de datos activa del centro de datos de Redmond se configura en EX6 en el centro de datos de Dublín. No obstante hay muchos otros ejemplos de configuraciones de DAG que proporcionan resistencia de sitio. Por ejemplo:

• En lugar de hospedar solamente copias de bases de datos pasivas, EX6 podría hospedar todas las copias activas, o bien una combinación de activas y pasivas.

• Además de EX6, se podrían implementar varios miembros del DAG en el centro de datos de Dublín, lo que brindaría protección ante otros errores. Asimismo, esta configuración proporciona capacidad adicional, de modo que si se produce un error en el centro de datos de Redmond, el centro de datos de Dublín puede asumir una población mucho más grande de usuarios.

Utilizar varios grupos de disponibilidad de base de datos para resistencia de sitios

En el ejemplo anterior, un solo DAG se amplía en varios centros de datos, lo que proporciona resistencia de sitio para uno o los dos centros de datos. Si se usa un solo DAG para brindar resistencia de sitio en un entorno en el que cada centro de datos en el que se amplía el DAG tiene una población de usuarios activos, hay un solo punto de error en la conexión WAN. Eso se debe a que el quórum precisa una mayoría de votantes activos y que puedan comunicarse entre sí.

En el ejemplo anterior, la mayoría de los votantes se encuentra en el centro de datos de Redmond. Si el centro de datos de Dublín hospeda bases de datos de buzones activas y tiene una población de usuarios locales, una desconexión de la WAN interrumpiría el servicio de mensajería para los usuarios de Dublín. Si la conexión de la WAN se interrumpe, los miembros del DAG del centro de datos de Redmond son los únicos que mantienen el quórum y siguen prestando el servicio de mensajería.

Para eliminar la WAN como único punto de error cuando necesite proporcionar resistencia de sitios a varios centros de datos con poblaciones de usuarios activos, debe implementar varios DAG y que cada uno de ellos disponga de mayoría de votantes en un centro de datos por separado. Si se interrumpe la conexión de la WAN, la replicación se bloquea hasta que se restablezca la conexión. Los usuarios dispondrán de servicio de mensajería porque cada DAG sigue atendiendo a su población de usuarios locales.

Volver al principio

Experiencia del cliente al usar grupos de disponibilidad de base de datos

Los DAG son válidos para proporcionar alta disponibilidad y resistencia de sitio. La experiencia del cliente al usar un DAG depende del tipo y la versión del cliente, así como del protocolo que emplea para tener acceso a los datos del buzón de correo. Por ejemplo, si se produce una conmutación por error de base de datos en varios sitios, el comportamiento y la lógica de reconexión de un cliente POP3 o IMAP4 difieren de los que usa un cliente de Microsoft Outlook 2010.

En las siguientes secciones se describen el comportamiento y la lógica del cliente en varias situaciones hipotéticas. El comportamiento que se describe parte de los supuestos siguientes:

• El entorno contiene una sola matriz de servidores de acceso de cliente en cada sitio de Active Directory, y cada sitio contiene como mínimo dos servidores de acceso de cliente.

• Delante de la matriz de servidores de acceso de cliente está instalado y configurado un equilibrador de carga basado en hardware o software.

• La correspondiente planeación y configuración de certificados y espacios de nombres están completas, junto con los pertinentes registros DNS.

Comportamiento y lógica de Microsoft Outlook

En general, todas las versiones de Outlook se comportan igual ante la conmutación por error de base de datos que se da en un solo centro de datos y un solo sitio de Active Directory. A diferencia de las versiones anteriores de Exchange, en Exchange 2010, Outlook ya no se conecta directamente al almacén de Exchange en el servidor de buzón de correo. En lugar de ello, Outlook (y cualquier otro cliente MAPI) se conecta a los servicios de acceso de cliente RPC y de libreta de direcciones en el rol de servidor Acceso de clientes; asimismo, la instancia de Outlook del usuario se configura para conectarse con la matriz del servidor de acceso de cliente, que entonces se conecta el cliente con un servidor de acceso de cliente individual. Esta abstracción de la conexión de Outlook del servidor de buzón de correo aporta las ventajas siguientes:

• Si se produce una conmutación por error de base de datos, Outlook sigue conectado con el mismo servidor en la matriz de servidores de acceso de cliente. Cuando sucede esto, el cliente de Active Manager que se ejecuta en el servidor de acceso de cliente averigua qué miembro del DAG hospeda la copia de base de datos activa de Active Manager del DAG. A continuación, el servidor de acceso de cliente se conecta con ese servidor de buzón de correo y Outlook indica que está conectado al servidor Exchange.

• Si uno de los servidores de acceso de cliente de la matriz de servidores de acceso de cliente deja de estar disponible por una interrupción prevista o imprevista, los demás servidores de esa matriz se encargan de la carga de los clientes. Como Outlook se configura para conectarse con la matriz de servidores de acceso de cliente y no a un servidor determinado, los miembros de dicha matriz de servidores pueden estar sujetos a errores de manera individual o quedar sin conexión manualmente sin que ello afecte al perfil de Outlook del usuario. Esto puede pasar de forma automática (por ejemplo, reconfiguración automática de la matriz a partir de la supervisión realizada por la solución del equilibrador de carga delante de la matriz) o bien hacerse manualmente.

Todas las versiones de Outlook también se comportan así ante los cambios de centro de datos que se dan entre dos centros de datos y dos sitios de Active Directory. Los cambios de centro de datos conllevan el cambio de las direcciones IP usadas por espacios de nombres de acceso de cliente (como Microsoft Office Outlook Web App, SMTP, POP3, IMAP4, Detección automática, servicios web de Exchange o acceso de cliente RPC) de direcciones IP del centro de datos principal a direcciones IP del centro de datos secundario. Como consecuencia, el espacio de nombre que se emplea en el perfil de Outlook del usuario no cambia y la detección automática sigue señalando a los clientes al mismo espacio de nombre de matriz de servidor de acceso de cliente.

El comportamiento de Outlook tras una conmutación por error de base de datos en varios sitios es distinto del comportamiento tras una conmutación por error de base de datos en un solo sitio de Active Directory o después de un cambio de centro de datos.

Comportamiento de ejemplo de versiones de Outlook

Los ejemplos siguientes muestran el comportamiento de Outlook 2010, Office Outlook 2007 y Office Outlook 2003 tras una conmutación por error de base de datos en varios sitios. La topología que se usa en cada ejemplo es un DAG de cuatro miembros ampliado a dos sitios de Active Directory: Redmond y Portland. El buzón de correo del usuario se hospeda en DB1, la cual está replicada en cada uno de los servidores. En cada ejemplo, al producirse el error la copia activa de DB1 conmuta de MBX2 a MBX3.

Topología de ejemplo que muestra el comportamiento de Outlook tras una conmutación por error de base de datos en varios sitios

Cada cliente está configurado con CAS1 como servidor principal, lo que hace de Redmond el sitio de perfiles de Outlook. Como los clientes se encuentran en Redmond, la propiedad RPCClientAccessServer de DB1 está configurada para CAS1, lo que hace de Redmond el sitio de bases de datos preferido. Como DB1 ha tenido un error en MBX2 y se ha activado en MBX3, Portland es el sitio de bases de datos montadas.

Ejemplo de Outlook 2010 y Outlook 2007

Si un servidor de acceso de cliente está disponible en un sitio de Redmond, Outlook 2010 y Outlook 2007 continuarán conectándose a la matriz de acceso de cliente RPC en el sitio de Redmond. El servidor de acceso de cliente usado por el cliente se comunicará mediante RPC de MAPI con el servidor de buzones de correo del usuario en el sitio de Portland.

Si no hay servidores de acceso de cliente disponibles en el sitio de Redmond, se debe realizar un cambio de centro de datos de Redmond a Portland con el fin de restaurar el acceso al servicio y a los datos. Para obtener instrucciones detalladas acerca de cómo realizar un cambio de centro de datos, consulte Realizar un cambio de servidor.

Ejemplo de Outlook 2003

Cuando Outlook 2003 intenta conectarse con CAS1, también recibe como respuesta un mensaje de ecWrongServer. A diferencia de Outlook 2010 y Outlook 2007, Outlook 2003 no tiene la característica Detección automática y debe usar otros medios para actualizar el perfil de usuario. Outlook 2003 usa como mecanismo la redirección de perfiles MAPI. La redirección de perfiles MAPI requiere que el servidor de origen esté conectado. Si CAS1 no está disponible, y si tampoco lo están todos los demás servidores de acceso de cliente de la matriz (o si la matriz contiene únicamente CAS1), Outlook 2003 no puede realizar la redirección MAPI ni conectarse con la base de datos de buzones del usuario sin intervención manual.

Comportamiento y lógica de Outlook cuando se usan carpetas públicas

Aunque las bases de datos de carpetas públicas puedan hospedarse en servidores de buzón de correo que son miembros de un DAG, no usan la replicación continua, sino que usan la replicación de carpetas públicas para tener alta disponibilidad. El comportamiento de clientes de Outlook que se reconectan a una base de datos de carpetas públicas tras un error de base de datos de buzones no solo depende del tipo de error, sino también de los parámetros de configuración de la replicación de carpetas públicas, así como del estado y la vigencia de las bases de datos de carpetas públicas. Como la replicación continua no es válida para bases de datos de carpetas públicas, la alta disponibilidad de estas bases de datos se logra implementando varias bases de datos de carpetas públicas configuradas para que se repliquen entre sí. Se recomienda configurar más de una réplica de cada carpeta.

Comportamiento y lógica al margen de Outlook

En general, el comportamiento de los clientes y protocolos que no son de Outlook y MAPI varía según la aplicación y la situación hipotética del error. Como suele suceder con Outlook, las aplicaciones y los clientes típicos de Exchange (por ejemplo, Outlook Web App, Microsoft Exchange ActiveSync, POP3, IMAP4 y servicios web de Exchange) se comportan del mismo modo en la conmutación por error de base de datos que se da en un solo centro de datos y un solo sitio de Active Directory. Asimismo, todos estos clientes y protocolos (SMTP y Windows PowerShell incluidos) se comportan de la misma manera que Outlook tras un cambio de centro de datos.

Si se produce una conmutación por error de base de datos en varios sitios, el comportamiento difiere entre estos clientes y protocolos. En la tabla siguiente figura el comportamiento de estos clientes.

Comportamiento de conmutación por error de base de datos en varios sitios para clientes de Exchange típicos

Cliente o protocolo	Comportamiento
Outlook Web App	Redirección manual. En este caso, el espacio de nombres de clientes cambia de http://mailred.contoso.com a http://mailpdx.contoso.com. Una vez el usuario proporciona las credenciales de registro, se le redirige a CAS2 en el sitio de Portland a través de una página de redirección manual en la que se explica que se usó la dirección URL equivocada y que la dirección URL correcta es https://mailpdx.contoso.com/owa.
Exchange ActiveSync	Proxy o redirección. En este caso, el comportamiento de los clientes lo determinan la implementación y la versión del protocolo de Exchange ActiveSync en el dispositivo de cliente.
POP3 e IMAP4	Proxy. En este caso siempre requiere el servidor de acceso de cliente en funciones de proxy de servidores de acceso de cliente.
Servicios web de Exchange	Usa Detección automática para determinar el nuevo extremo de conexión.

Volver al principio

 © 2010 Microsoft Corporation. Reservados todos los derechos.