Exportar (0) Imprimir
Expandir todo

Alta disponibilidad y resistencia de sitios

 

Se aplica a: Exchange Server 2013

Última modificación del tema: 2014-07-01

Las bases de datos de buzones y los datos que éstas contienen constituyen uno de los componentes más críticos (si no el más crítico de todos) de cualquier organización de Exchange. En Microsoft Exchange Server 2013, las bases de datos de buzones y los datos que hay en ellas se pueden proteger mediante la configuración de dichas bases de datos para que tengan una alta disponibilidad y resistencia de sitios. Exchange 2013 reduce el costo y la dificultad inherentes a la implementación de una solución de mensajería altamente disponible y resistente, al tiempo que proporciona mayores niveles de disponibilidad de extremo a extremo y admite buzones de mayor tamaño. La generación de funciones de replicación nativas y arquitectura de alta disponibilidad en Exchange 2010, Exchange 2013 permite a los clientes de todos los tamaños y todos los segmentos implementar de forma económica un servicio de continuidad de mensajería en su organización.

¿Está buscando tareas de administración relacionadas con la alta disponibilidad y la resistencia de sitios? Consulte Administración de la alta disponibilidad y la resistencia de sitios.

Contenido

Terminología básica

Grupos de disponibilidad de base de datos

Copias de bases de datos de buzones

Active Manager

Cambios en la alta disponibilidad de Exchange 2010

Resistencia de sitios

API de replicación de terceros

Documentación de alta disponibilidad y resistencia de sitios

Los siguientes términos clave son importantes a la hora de entender qué es la alta disponibilidad o la resistencia de sitios:

Active Manager

Componente interno de Exchange que se ejecuta en el servicio de replicación de Microsoft Exchange responsable de supervisar errores y de tomar acciones correctivas a través de la conmutación por error en un grupo de disponibilidad de bases de datos (DAG).

AutoDatabaseMountDial

Valor de propiedad de un servidor de buzones que determina si una copia de base de datos pasiva se monta automáticamente como una nueva copia activa, en función del número de archivos de registro que le falten a la copia que se va a montar.

Replicación continua, modo de bloque

En el modo de bloque, como cada actualización se escribe en el búfer de registro activo de la copia de base de datos activa, también se incluye en un búfer de registro de cada una de las copias de buzones pasivos en el modo de bloque. Cuando se llena el búfer de registro, cada copia de base de datos genera, inspecciona y crea el siguiente archivo de registro en la secuencia de generación.

Replicación continua, modo de archivo

En el modo de archivo, los archivos de registro de transacciones cerradas se transfieren de la copia de bases de datos activa a una o más copias de bases de datos pasivas.

Grupo de disponibilidad de base de datos

Grupo de hasta 16 servidores de buzones de correo de Exchange 2013 que hospeda un conjunto de bases de datos replicadas.

Movilidad de la base de datos

La capacidad de una base de datos de buzones de correo de Exchange 2013 de replicarse y montarse en otros servidores de buzones de correo de Exchange 2013.

Centro de datos

Normalmente, esto se refiere a un sitio de Active Directory, aunque también puede referirse a un sitio físico. En el contexto de esta documentación, el centro de datos equivale al sitio de Active Directory.

modo de coordinación de activación de centro de datos

Propiedad de la configuración del DAG que, cuando está habilitada, fuerza al servicio de replicación de Microsoft Exchange a que adquiera permisos para montar bases de datos en el inicio.

Recuperación ante desastres

Cualquier proceso que sirve para recuperarse manualmente de un error. Puede tratarse de un error que afecta a un único elemento o a toda la ubicación física.

API de replicación de terceros de Exchange

API que Exchange suministra y que permite usar la replicación sincrónica de terceros para un DAG en lugar de la replicación continua.

Alta disponibilidad

Solución que ofrece disponibilidad de servicio, disponibilidad de datos y recuperación automática de los errores que afectan al servicio o a los datos (como un error de red, de almacenamiento o de servidor).

Implementación incremental

La capacidad de implementar una alta disponibilidad y resistencia de sitios después de instalar Exchange 2013.

Copia de base de datos de buzones con retardo

Copia pasiva de una base de datos de buzones que presenta un tiempo de retardo de reproducción de registro superior a cero.

Copia de base de datos de buzones

Base de datos de buzones (archivo .edb y registros), ya sea en estado activo o pasivo.

Resistencia de buzón

Nombre de una solución unificada de alta disponibilidad y resistencia de sitios en Exchange 2013.

Disponibilidad administrada

Conjunto de procesos internos que consta de sondeos, monitores y respondedores que incorporan la supervisión y la alta disponibilidad en todos los roles de servidor y protocolos.

*over (pronounced "star over")

Abreviatura para cambio y conmutación por error. Un cambio consiste en la activación manual de una o varias copias de bases de datos. Una conmutación por error consiste en la activación automática de una o varias copias de bases de datos después de un error.

Red de seguridad

Antes conocida como contenedor de transporte, se trata de una característica del servicio de transporte que almacena una copia de todos los mensajes durante X días. La configuración predeterminada es 2 días.

Redundancia de instantánea

Característica de servidor de transporte que proporciona redundancia de mensajes para todo el tiempo que estos están en tránsito.

Resistencia de sitios

Configuración que amplía la infraestructura de mensajería a varios sitios de Active Directory para proporcionar una continuidad operativa al sistema de mensajería en el caso de que un error afecte a alguno de los sitios.

Terminología básica

Un DAG es el componente esencial del marco de alta disponibilidad y resistencia de sitios que hay integrado en Exchange 2013. Un DAG es un grupo de hasta 16 servidores de buzones de correo que hospeda 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, las redes o las bases de datos individuales. 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. Para obtener más información acerca de los DAG, consulte Grupos de disponibilidad de base de datos.

Terminología básica

Las funciones de alta disponibilidad y de resistencia de sitios se presentaron por primera vez en Exchange 2010 y se usan en Exchange 2013 para crear y mantener copias de bases de datos. Exchange 2013 también aprovecha el concepto de movilidad de bases de datos, que es la conmutación por error en el nivel de la base de datos administrada por Exchange.

La movilidad de la base de datos desconecta las bases de datos de los servidores y agrega compatibilidad para un máximo de 16 copias de una sola base de datos. También proporciona una experiencia nativa para crear copias de una base de datos.

El proceso por el cual una copia de base de datos se establece como la base de datos de buzones se denomina cambio. En esta misma línea, si se produce un error que afecta a una base de datos o al acceso a la misma y una nueva base de datos pasa a ser la copia activa, se produce lo que se conoce como conmutación por error. Este proceso también hace referencia a un error de servidor en el que uno o más servidores conectan las bases de datos que el servidor con el error se encargaba de conectar anteriormente. Cuando se produce un cambio o una conmutación por error, otros servidores de Exchange 2013 perciben dicho cambio casi al instante y redirigen el tráfico de mensajería y cliente a la nueva base de datos activa.

Por ejemplo, si se produce un error en una base de datos activa de un DAG debido a un error de almacenamiento subyacente, Active Manager efectuará una recuperación automática conmutando por error a una copia de base de datos en otro servidor de buzones de correo del DAG. En Exchange 2013, la disponibilidad administrada agrega nuevos comportamientos para recuperarse de la pérdida de acceso de protocolos a una base de datos, incluido el reciclado de los grupos de procesos de trabajo de aplicaciones, el reinicio de servicios y servidores, y el inicio de conmutaciones por error de bases de datos.

Para obtener más información acerca de las copias de bases de datos de buzones de correo, consulte Copias de bases de datos de buzones de correo.

Terminología básica

Exchange 2013 aprovecha el componente de Active Manager presentado en Exchange 2010 para administrar la replicación continua y el estado de bases de datos, copias de bases de datos y otros aspectos de la alta disponibilidad de servidores de buzones. Para obtener más información acerca de Active Manager, consulte Active Manager.

Terminología básica

Exchange 2013 usa DAG y copias de bases de datos de buzones, junto con otras funciones, tales como recuperación de un solo elemento, directivas de retención y copias de bases de datos retrasadas para suministrar protección de datos nativa de Exchange, alta disponibilidad y resistencia de sitios. La plataforma de alta disponibilidad, el Almacén de información de Exchange y el Motor de almacenamiento extensible (ESE) se han mejorado para suministrar una mayor disponibilidad, facilitar la administración y reducir los costos. Entre estas mejoras se incluyen:

  • Reducción de IOPS mediante Exchange 2010   Esto permite aprovechar discos más grandes en términos de capacidad y de E/S de disco máxima por segundo (IOPS) de la forma más eficiente posible.

  • Disponibilidad administrada Con la disponibilidad administrada, las funciones orientadas a la recuperación y supervisión interna se integran estrechamente para evitar errores, restaurar de manera proactiva los servicios, iniciar conmutaciones por error de servidores de forma automática o alertar a los administradores para que tomen medidas. El enfoque se centra en la supervisión y administración de la experiencia del usuario final y no solo en el tiempo activo de componente y servidor para ayudar a mantener el servicio disponible en forma continua.

  • Almacén administrado   Almacén administrado es el nombre de los procesos de almacén de información recientemente rescritos en Exchange 2013. El nuevo almacén administrado se escribe en C# y se integra estrechamente con el servicio de replicación de Microsoft Exchange (MSExchangeRepl.exe) para suministrar mayor disponibilidad mediante una resistencia mejorada.

  • Soporte para varias bases de datos por disco Exchange 2013 incluye mejoras que le permiten brindar soporte a varias bases de datos (combinaciones de copias activas y pasivas) en el mismo disco y así aprovechar discos más grandes en términos de capacidad de la manera más eficiente posible.

  • Restauración automática permite restaurar rápidamente la redundancia de base de datos después de un error en el disco. Si se produce un error en el disco, la copia de bases de datos almacenada en ese disco se copia desde la copia de base de datos activa a un disco de reserva en el mismo servidor. Si se almacenan varias copias de bases de datos en el disco con error, pueden volver a inicializarse todas automáticamente en un disco de reserva. Esto posibilita inicializaciones más rápidas dado que es probable que las bases de datos activas se encuentren en varios servidores y los datos se copien en paralelo.

  • Recuperación automática de errores de almacenamiento   Esta funcionalidad continúa la innovación introducida en Exchange 2010 para permitir que el sistema se recupere de errores que afectan la resistencia o la redundancia. Además de los comportamientos de comprobación de errores de Exchange 2010, Exchange 2013 incluye comportamientos de recuperación adicionales para tiempos de E/S largos, consumos excesivos de memoria por parte de MSExchangeRepl.exe y casos graves en los que el sistema se encuentra en un estado tan incorrecto que los subprocesos no pueden programarse.

  • Mejoras en copias retrasadas   Las copias retrasadas pueden ahora ocuparse en cierta medida de sí mismas restando importancia a los archivos de registro. Las copias calorifugadas automáticamente restarán importancia a los archivos de registro en una variedad de situaciones, como la aplicación de revisiones y los casos de poco espacio en el disco. Si el sistema detecta que la aplicación de revisiones es necesaria para una copia calorifugada, los registros se volverán a reproducir automáticamente en la copia calorifugada al realizar la aplicación de revisiones. Las copias calorifugadas también invocarán esta característica de reproducción automática cuando se alcance un umbral de espacio de disco bajo, y cuando la copia calorifugada se haya detectado como la única copia disponible durante un período de tiempo específico. Además, las copias calorifugadas pueden aprovechar la Red de seguridad, lo que hace que la recuperación o la activación sean más fáciles.

  • Mejoras en la alerta de copia única   La alerta de copia única introducida en Exchange 2010 ya no es un script programado por separado. Ahora está integrada en los componentes de disponibilidad administrada en el sistema y es una función nativa de Exchange.

  • Configuración automática de red de DAG   El sistema puede configurar automáticamente las redes de DAG basándose en las opciones de configuración. Además de las opciones de configuración manual, las redes DAG también pueden distinguir entre MAPI y redes de replicación y configurar redes de DAG automáticamente.

En Exchange 2010, las copias de bases de datos pasivas tienen una profundidad de punto de comprobación muy baja, lo cual es necesario para efectuar una conmutación por error rápida. Además, la copia pasiva realiza una lectura previa agresiva de los datos para mantener una profundidad de punto de comprobación de 5 megabytes (MB). Como resultado del uso de una profundidad de punto de comprobación baja, y de realizar estas operaciones agresivas de lectura previa, el valor de IOPS para una copia de base de datos pasiva es igual al de una copia activa en Exchange 2010.

En Exchange 2013, el sistema es capaz de proporcionar una conmutación por error rápida con una profundidad de punto de comprobación alta en la copia pasiva (100 MB). Como las copias pasivas tienen una profundidad de punto de comprobación de 100 MB, se han desajustado para que no sean tan agresivas. Debido al aumento de la profundidad de punto de comprobación y al desajuste de las lecturas previas agresivas, el porcentaje de IOPS para una copia pasiva es de un 50 % del IOPS de copias activas en Exchange 2013.

La presencia de una profundidad de punto de comprobación más alta en la copia pasiva también origina otros cambios. En la conmutación por error en Exchange 2010, la caché de la base de datos se descarga porque la base de datos se convierte de una copia pasiva a una activa. En Exchange 2013, se reescribió el registro de ESE para que la caché persista durante la transición de copia pasiva a activa. Dado que ESE no necesita descargar la cache, la conmutación por error se realiza más deprisa.

Otro de los cambios se realizó en el proceso de mantenimiento de bases de datos en segundo plano (BDM). BDM ahora procesa entre 1 y 2 MB por segundo y por copia.

Como consecuencia de todos estos cambios, Exchange 2013 ofrece una disminución del 50 % en IOPS respecto de Exchange 2010.

La disponibilidad administrada consta de la integración de una supervisión activa e integrada y de la plataforma de alta disponibilidad de Exchange 2013. Gracias a la disponibilidad administrada, el sistema puede tomar una decisión sobre cuándo conmutar por error una base de datos en función del estado del servicio. La disponibilidad administrada es una infraestructura interna que se implementa en los roles de servidor Buzón de correo y Acceso de cliente en Exchange 2013. Esta función incluye tres componentes principales asíncronos que funcionan de manera permanente. El primer componente es el motor de sondeo, responsable de tomar medidas en el servidor y recopilar los datos. Los resultados de estas medidas se reflejan en el segundo componente, el monitor. El monitor contiene la lógica empresarial que usa el sistema en función de lo que se considere como un estado correcto en los datos recopilados. De manera similar a un motor de reconocimiento de patrones, el monitor busca los diferentes patrones en todas las medidas recopiladas y, luego, decide si algo es correcto o no. Por último, existe el motor de respuesta, que es responsable de las acciones de recuperación. Cuando hay algo incorrecto, la primera acción es intentar recuperar dicho componente. Esto puede incluir acciones de recuperación de varias etapas; por ejemplo, el primer intento puede ser reiniciar el grupo de aplicaciones; el segundo, reiniciar el servicio; el tercero, reiniciar el servidor y, el próximo, desconectar el servidor de modo que ya no acepte tráfico. Si las acciones de recuperación fracasan, el sistema escala el problema a la persona a través de las notificaciones de registro de eventos.

La disponibilidad administrada se implementa mediante dos servicios:

  • Exchange Health Manager Service (MSExchangeHMHost.exe)   Es un proceso de controlador que se usa para gestionar procesos de trabajo. Se usa para crear, ejecutar e iniciar y detener procesos de trabajo, según sea necesario. También se usa para recuperar procesos de trabajo en caso de que se bloqueen, para evitar que los procesos de trabajo sean un punto único de error.

  • Proceso de Exchange Health Manager Worker (MSExchangeHMWorker.exe)   Es el proceso de trabajo responsable de realizar las tareas de tiempo de ejecución.

La disponibilidad administrada usa el almacenamiento persistente para realizar sus funciones:

  • Los archivos de configuración XML se utilizan para inicializar las definiciones de elementos de trabajo durante el inicio de los procesos de trabajo.

  • El registro se usa para almacenar datos de tiempo de ejecución, como los marcadores.

  • La infraestructura de registro de eventos del canal Crimson se usa para almacenar los resultados de los elementos de trabajo.

Para obtener más información acerca de la disponibilidad administrada, consulte Supervisión de grupos de disponibilidad de base de datos.

Si bien las mejoras en el almacenamiento de Exchange 2013 están diseñadas principalmente para las configuraciones de solo un montón de discos (JBOD), todas las configuraciones de almacenamiento compatibles pueden usarlas. Una de estas características es la capacidad para hospedar varias bases de datos en el mismo volumen. Esta característica está relacionada con la optimización de Exchange para discos de gran tamaño. Las optimizaciones permiten usar los discos de gran tamaño de manera mucho más eficiente en términos de capacidad, IOPS y tiempos de reinicialización, y tienen como objetivo afrontar los desafíos asociados a la ejecución en una configuración de almacenamiento JBOD:

  • Los tamaños de las bases de datos deben ser manejables.

  • Las operaciones de reinicialización deben ser rápidas y confiables.

  • Si bien la capacidad de almacenamiento está aumentando, IOPS no.

  • Los discos que hospedan copias de base de datos pasivas se desaprovechan en términos de IOPS.

  • Las copias retrasadas tienen requisitos de almacenamiento asimétricos.

  • La agilidad limitada existe para recuperarse de las condiciones de espacio en disco insuficiente.

La tendencia de aumentar la capacidad de almacenamiento continúa y se espera que pronto estén disponibles unidades de 8 terabytes. Al usar unidades de 8 terabytes junto a procedimientos recomendados en cuanto al tamaño máximo de bases de datos de Exchange (2 terabytes), se consumirían más de 5 terabytes de espacio en disco. Una solución sería, simplemente, aumentar el tamaño de las bases de datos, pero esto inhibe la administración, ya que agrega mayores tiempos de reinicialización, incluidos, en algunos casos, tiempos de reinicialización no administrables, y pone en riesgo la confiabilidad de la copia de la cantidad de datos en la red.

Además, en el modelo de Exchange 2010, el disco que almacena una copia pasiva queda desaprovechado en términos de IOPS. En el caso de las copias pasivas retrasadas, además de que el disco no se aprovecha del todo en cuanto a IOPS, también es asimétrico en lo que a su tamaño se refiere, en comparación con los discos que se usan para almacenar las copias activas y pasivas no retrasadas.

Siguiendo la práctica que se ha mantenido durante mucho tiempo, Exchange 2013 se ha optimizado para que pueda usar discos grandes (8 terabytes) en una configuración JBOD de manera más eficiente. En Exchange 2013 se incluyen varias bases de datos por disco, lo que permite tener discos del mismo tamaño que almacenen varias copias de bases de datos, incluidas copias retrasadas. El objetivo consiste en distribuir a los usuarios entre el número de volúmenes existente, lo que proporciona un diseño simétrico en el que, durante un funcionamiento normal, los miembros de DAG hospedan una combinación de copias activas, pasivas y retrasadas opcionales en los mismos volúmenes.

A continuación se muestra un ejemplo de una configuración que emplea varias bases de datos por volumen.

Configuración que usa varias bases de datos por volumen

Varias bases de datos por volumen

En la configuración anterior, se proporciona un diseño simétrico. Los cuatro servidores tienen las cuatro bases de datos hospedadas en un solo disco por servidor. La clave es que el número de copias de cada base de datos debe ser igual al número de copias de base de datos por disco. En el ejemplo anterior, hay cuatro copias de cada base de datos: una copia activa, dos copias pasivas y una copia retrasada. Como hay cuatro copias para cada base de datos, la configuración adecuada es la que tenga cuatro copias por volumen. Además, se configura la preferencia de activación para que se equilibre en el DAG y en los servidores. Por ejemplo, la copia activa tendrá un valor de preferencia de activación de 1, la primera copia pasiva tendrá un valor de preferencia de activación 2, la segunda copia pasiva, de 3 y la copia retrasada, de 4.

Además de conseguir una mejor distribución de los usuarios en los volúmenes existentes, otra ventaja del uso de varias bases de datos por disco consiste en que disminuye el tiempo que se tarda en restaurar la protección de datos en caso de que genere un error que precise una reinicialización (por ejemplo, un error de disco).

A medida que las bases de datos crecen, su reinicialización tarda cada vez más. Por ejemplo, una base de datos de 2 terabytes puede tardar 23 horas en reinicializarse, mientras que una de 8 terabytes puede tardar hasta 93 horas (casi 4 días). Ambas inicializaciones ocurrirían en unos 20 MB por segundo. Generalmente, esto significa que una base de datos muy grande no podría inicializarse dentro de un tiempo operativamente razonable.

En el caso de un escenario con una sola copia de base de datos por disco, la operación de inicialización se enlaza al origen, porque el disco siempre se inicializa desde un solo origen. Al dividir el volumen en varias copias de base de datos y tener la copia activa de las bases de datos pasivas en un volumen especificado almacenado en miembros de DAG independientes, el sistema deja de estar enlazado al origen en el contexto de la reinicialización del disco. Cuando se reemplaza un disco erróneo, se puede reinicializar desde varios orígenes. Esto permite al sistema reinicializar y restaurar la protección de datos para estas bases de datos en un espacio de tiempo mucho más breve.

Al usar varias bases de datos por volumen, se recomienda seguir las siguientes mejores prácticas y los siguientes requisitos:

  • Debe usarse una partición de disco lógico único por disco físico. No cree varias particiones en el disco. Las copias de base de datos y sus archivos complementarios (como los registros de transacción y el índice de contenido) se deben hospedar en un único directorio en la partición única.

  • El número de copias de base de datos configuradas por volumen debe ser igual al número de copias de cada base de datos. Por ejemplo, si tiene cuatro copias de bases de datos, debe usar cuatro copias de base de datos por volumen.

  • Las copias de la base de datos deben tener los mismos vecinos. (Por ejemplo, todos deben compartir el mismo disco en cada servidor).

  • La preferencia de activación en el DAG debe estar equilibrada, de modo que cada copia de base de datos en un disco determinado tenga un valor de preferencia de activación único.

La reinicialización automática, o reinicialización, es una característica que sustituye a las acciones que generalmente suele realizar un administrador como respuesta a un error en el disco, un evento de base de datos dañada u otro problema que precise reinicializar una copia de base de datos. La reinicialización automática se ha diseñado con el fin de restaurar automáticamente la redundancia de bases de datos después de un error en el disco mediante el uso de discos de reserva que se aprovisionan al sistema.

En una configuración de reinicialización automática se usa una estructura de presentación de almacenamiento estándar, y el administrador elige el punto de inicio. La reinicialización automática consiste en restaurar la redundancia lo antes posible cuando se produce un error en una unidad. Esto conlleva la preasignación de un conjunto de volúmenes (incluidos los volúmenes de reserva) y de bases de datos mediante puntos de montaje. En el caso de un error de disco en el que el disco ya no esté disponible para el sistema operativo, o no se pueda escribir en él, el sistema asigna un volumen de reserva y las copias de bases de datos afectadas se reinicializan automáticamente. La reinicialización automática utiliza el siguiente proceso:

  1. El servicio de replicación de Microsoft Exchange detecta copias de manera periódica que tengan el estado de FailedAndSuspended.

  2. Cuando encuentra una copia con ese estado, realiza algunas comprobaciones de requisitos previos, como si esta es una situación de copia única, si están disponibles reservas y si algo podría evitar que el sistema realice una reinicialización automática.

  3. Si las comprobaciones de requisitos previos resultan correctas, el servicio de replicación de Microsoft Exchange asigna una reserva.

  4. A continuación, se realiza la operación de reinicialización.

  5. Una vez completada la inicialización, el servicio de replicación de Microsoft Exchange comprueba que la copia recién inicializada es correcta.

En este momento, si el error fue un error de disco, se requiere la intervención manual de un operador o administrador para quitar y remplazar el disco erróneo y, luego, formatearlo, inicializarlo y volver a configurarlo como reserva.

La reinicialización automática se configura mediante tres propiedades del DAG. Dos de las propiedades se refieren a los dos puntos de montaje que están en uso. Exchange 2013 aprovecha el hecho de que Windows Server admite varios puntos de montaje por volumen. La propiedad AutoDagVolumesRootFolderPath hace referencia al punto de montaje que contiene todos los volúmenes disponibles. Esto incluye volúmenes que hospedan bases de datos y volúmenes de reserva. La propiedad AutoDagDatabasesRootFolderPath hace referencia al punto de montaje que contiene las bases de datos. La tercera propiedad de DAG, AutoDagDatabaseCopiesPerVolume, se usa para configurar el número de copias de base de datos por volumen.

A continuación se muestra un ejemplo de configuración de reinicialización automática.

Ejemplo de configuración de la reinicialización automática

Ejemplo de configuración de reinicialización automática

En este ejemplo hay tres volúmenes, dos de los cuales contienen bases de datos (VOL1 y VOL2) y uno de reserva que está vacío y formateado (VOL3).

Para configurar la reinicialización automática:

  1. Los tres volúmenes se montan en un solo punto de montaje. En este ejemplo, se usa un punto de montaje de C:\ExchVols. Este es el directorio utilizado para obtener el almacenamiento para las bases de datos de Exchange.

  2. Se monta el directorio raíz de las bases de datos de buzones de correo como otro punto de montaje. En este ejemplo, se usa un punto de montaje de C:\ExchDBs. A continuación, se crea una estructura de directorio para que se cree un directorio principal para la base de datos y, en este, se crean dos subdirectorios: un archivo de base de datos y uno para los archivos de registro.

  3. Se crean bases de datos. En el ejemplo anterior se muestra un diseño sencillo mediante el uso de una sola base de datos por volumen. Por lo tanto, en VOL1 hay tres directorios: el directorio principal y dos subdirectorios (uno para el archivo de la base de datos de MDB1 y otro para sus registros). Si bien no se muestra en la imagen de ejemplo, en VOL2, también habría tres directorios: el directorio principal y en él, un directorio para el archivo de la base de datos de MDB2 y uno para sus archivos de registro.

En esta configuración, si se produjera un error en MDB1 o en MDB2, se reinicializaría una copia de la base de datos con error a VOL3 automáticamente.

Para obtener más información acerca de la reinicialización automática, vea Configurar AutoReseed para un grupo de disponibilidad de base de datos.

La recuperación automática de errores de almacenamiento continúa con las novedades presentadas en Exchange 2010 para permitir que el sistema se recupere de los errores que afectan a la resistencia o a la redundancia. Además de los comportamientos de comprobación de errores de Exchange 2010, Exchange 2013 incluye otros comportamientos de recuperación para tiempos de E/S prolongados, un consumo excesivo de memoria por parte del servicio de replicación de Microsoft Exchange (MSExchangeRepl.exe) y otros casos graves en los que no se pueden programar subprocesos.

Incluso en entornos JBOD, los controladores de matrices de almacenamiento pueden tener problemas, como bloquearse o colgarse. Exchange 2010 incluía características de detección de E/S y de recuperación que proporcionaban resistencia mejorada. En la tabla siguiente se muestran estas características.

 

Name Comprobar Action Umbral

Detección de E/S de bloqueos de bases de datos de ESE

Comprobación de ESE de E/S pendientes

Genera un elemento de error en el canal Crimson para reiniciar el servidor

240 segundos

Latido de canal de elemento erróneo

Garantiza que los elementos erróneos se pueden escribir en el canal Crimson y leerse de él

El servicio de replicación late en el canal Crimson y reinicia el servidor con errores

30 segundos

Latido del disco de sistema

Comprueba el estado del disco de sistema del servidor

Envía periódicamente E/S sin búfer al disco del sistema; reinicia el servidor en el tiempo de espera del latido

120 segundos

Exchange 2013 mejora la resistencia de almacenamiento y del servidor mediante nuevos comportamientos para otras condiciones graves. Estas condiciones y comportamientos se describen en la tabla siguiente.

 

Name Comprobar Action Umbral

Estado incorrecto del sistema

No se pueden programar subprocesos, ni siquiera los que no están administrados

Reinicie el servidor

302 segundos

Largos tiempos de E/S

Mediciones de latencia de operación de E/S

Reinicie el servidor

41 segundos

Uso de la memoria del servicio de replicación

Medir el conjunto de trabajo de MSExchangeRepl.exe

  1. Registrar el evento 4395 en el canal Crimson con una solicitud de finalización del servicio

  2. Iniciar la finalización de MSExchangeRepl.exe

  3. Si se produce un error en la finalización del servicio, reinicie el servidor

4 gigabytes (GB)

Evento 129 del sistema (reinicialización del bus)

Comprobar el evento 129 en el registro de eventos del sistema

Reiniciar el servidor

Cuando ocurre el evento

Bloqueo de base de datos del clúster

El administrador de actualizaciones globales está bloqueado

Reiniciar el servidor

Cuando ocurre el evento

Entre las mejoras en las copias retrasadas, se incluyen la integración con Safety Net y la reproducción automática de archivos de registro en ciertos escenarios. Safety Net es una característica de transporte que reemplaza a la función de Exchange 2010 conocida como contenedor de transporte. Safety Net funciona de manera similar al contenedor de transporte, ya que consiste en una cola de entrega que se asocia al servicio de transporte en un buzón de servidores. Esta cola almacena copias de los mensajes que se entregaron correctamente a la base de datos de buzones activa en el servidor de buzones. Cada base de datos de buzones activa del servidor de buzones tiene su propia cola que almacena copias de los mensajes entregados. Puede especificar el tiempo que desea que Safety Net almacene copias de los mensajes entregados correctamente antes de que expiren o se eliminen de forma automática.

La red de seguridad asume parte de la responsabilidad de la redundancia de instantáneas en entornos de DAG. En estos entornos, la redundancia de instantáneas no necesita mantener otra copia del mensaje entregado en una cola de instantáneas mientras espera a que el mensaje entregado se replique en las copias pasivas de las bases de datos de buzones de correo en otros servidores de buzones del DAG. La copia del mensaje entregado ya está almacenada en Safety Net, por lo que la redundancia de instantáneas puede volver a entregar el mensaje desde Safety Net si fuera necesario.

Con la introducción de Safety Net, la activación de una copia de base de datos retrasada se ha facilitado enormemente. Por ejemplo, supongamos que tiene una copia retrasada con un retraso de reproducción de 2 días. En ese caso, tendría que configurar Safety Net para un período de 2 días. Si detecta una situación en la que tenga que usar la copia retrasada, puede suspender su replicación y copiarla dos veces (para mantener la naturaleza retrasada de la base de datos y crear una copia adicional por si la necesita). Después, tome la copia y elimine todos los archivos de registro, salvo los que se encuentren en el intervalo requerido. Monte la copia, lo que desencadenará una solicitud automática a Safety Net para volver a entregar los últimos dos días de correo. Con Safety Net, no es necesario que busque el punto de corrupción. Obtiene el correo de los dos últimos días, menos los datos perdidos comúnmente en una conmutación por error con pérdidas.

Las copias retrasadas se pueden administrar ahora a sí mismas mediante la invocación de la reproducción automática del registro para que reproduzca los archivos de registro en ciertos escenarios:

  • Cuando se alcance un umbral de espacio en disco insuficiente

  • Cuando la copia retrasada tiene un daño físico y se debe revisar por páginas

  • Cuando hay menos de tres copias correctas disponibles (activas o pasivas) durante más de 24 horas

En Exchange 2010, la revisión de páginas no está disponible para las copias retrasadas. En Exchange 2013, la revisión de páginas está disponible para las copias retrasadas a través de esta característica de reproducción automática. Si el sistema detecta que la aplicación de revisiones es necesaria para una copia retrasada, los registros se vuelven a reproducir automáticamente en la copia retrasada al realizar la aplicación de revisiones. Las copias retrasadas también invocan esta característica de reproducción automática cuando se alcanza un umbral de espacio de disco bajo y cuando la copia retrasada se detecta como la única copia disponible durante un período específico.

El comportamiento de reproducción de copias retrasadas está deshabilitado de manera predeterminada, pero se puede habilitar mediante la ejecución del siguiente comando.

Set-DatabaseAvailabilityGroup <DAGName> -ReplayLagManagerEnabled $true

Después de su habilitación, la reproducción ocurre cuando hay menos de tres copias. Puede cambiar el valor predeterminado de 3 mediante la modificación del siguiente valor del Registro.

HKLM\Software\Microsoft\ExchangeServer\v15\Replay\Parameters\ReplayLagManagerNumAvailableCopies

Para habilitar la reproducción en umbrales de espacio en disco insuficiente, debe configurar la siguiente entrada del Registro.

HKLM\Software\Microsoft\ExchangeServer\v15\Replay\Parameters\ReplayLagPlayDownPercentDiskFreeSpace

Los objetivos clave para las operaciones diarias de mensajería de Exchange 2013 son asegurarse de que los servidores funcionan de forma confiable y de que las copias de base de datos de buzones están en buen estado. Debe supervisar de manera activa el hardware, el sistema operativo Windows y los servicios de Exchange. No obstante, cuando se ejecuta en un entorno de resistencia de buzones de Exchange 2013, es importante supervisar el mantenimiento y el estado del DAG y de las copias de bases de datos de buzones de correo. Resulta de especial importancia realizar una supervisión y administración del riesgo de redundancia de datos en períodos durante los cuales una base de datos replicada se comporte como una copia única. Esto es especialmente fundamental en entornos que no usan la matriz redundante de discos independientes (RAID) y, en cambio, implementan configuraciones de JBOD. En entornos RAID, un error de un solo disco no afecta a las copias de base de datos de buzones de correo activas. Sin embargo, en un entorno JBOD, un error de disco desencadenará una conmutación por error de base de datos.

En Exchange 2010, se introdujo el script CheckDatabaseRedundancy.ps1. Como su nombre indica, la finalidad del script es supervisar la redundancia de las bases de datos de buzones de correo replicadas corroborando que, por lo menos, haya dos copias actuales configuradas que sean correctas, así como avisar a un administrador a través de la generación de registros de evento cuando solo 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.

Entre las condiciones de copia única se incluyen, entre otras, las siguientes:

  • Error de una copia activa para replicarse en cualquier copia pasiva.

  • Error de todas las copias pasivas, que incluye los estados FailedAndSuspended y Failed además de los estados correctos en los que la copia se retrasa en la reproducción o copia de registros. Tenga en cuenta que las copias retrasadas no se consideran como tal si sus registros se reproducen en un margen de diez minutos en comparación con su período de retraso.

  • Error del sistema para conocer de manera precisa la generación de archivos de registro actuales de la copia activa.

Dado que para los administradores resulta fundamental conocer cuándo disponen de una copia correcta de una base de datos, el script CheckDatabaseRedundancy.ps1 se ha reemplazado por una funcionalidad nativa e integrada que forma parte del conjunto de mantenimiento DataProtection de disponibilidad administrada.

Esta funcionalidad nativa también avisa a los administradores a través de notificaciones de registros de eventos aunque, para distinguir las alertas de Exchange 2013 de las de Exchange 2010, Exchange 2013 usa los siguientes identificadores de evento:

  • Evento 4138 (alerta roja)

  • Evento 4139 (alerta verde)

En Exchange 2013, la funcionalidad nativa se ha mejorado para reducir el nivel de ruido de alerta que puede ocurrir cuando varias bases de datos del mismo servidor pasan a una condición de copia única. En Exchange 2010, las alertas de copia única se generan por base de datos. Como resultado, cuando ocurre un problema en el servidor que afecta a varias bases de datos y copias de bases de datos, pueden producirse tormentas de alertas. Dado que varios errores, como los problemas de memoria o del controlador, son de todo el servidor, existe una probabilidad moderadamente alta de que dicha tormenta de alerta ocurra para cada incidente del servidor. En Exchange 2013, las alertas se generan ahora servidor por servidor. Cuando una interrupción afecta a todo el servidor y la redundancia de datos está en peligro para varias copias de base de datos, se genera una sola alerta por servidor.

Una red del DAG es un conjunto de una o más subredes usadas para el tráfico de replicación o el tráfico MAPI. Cada DAG contiene un máximo de una red MAPI y cero más redes de replicación. En Exchange 2010, el sistema crea las redes de DAG iniciales (por ejemplo, DAGNetwork01 y DAGNetwork02) en función de las subredes enumeradas por el servicio de clúster. En los entornos en los que se usan varias redes y las interfaces para una red específica (por ejemplo, la red MAPI) están en la misma subred, el administrador tiene que realizar muy pocas configuraciones adicionales. No obstante, en aquellos entornos en los que las interfaces para una red específica se encuentran en varias subredes, el administrador tiene que realizar una tarea denominada como contracción de redes de DAG.

En Exchange 2013, ya no es necesario contraer redes de DAG. Exchange 2013 sigue usando los mismos mecanismos de detección para distinguir entre la redes MAPI y de replicación, pero ahora contrae automáticamente las redes de DAG según sea necesario.

Además, el sistema administra ahora las redes de DAG de manera automática. Para ver las propiedades de una red de DAG mediante el Centro de administración de Exchange (EAC), configure el DAG para el control de red manual. Para ello, modifique las propiedades del DAG a través del EAC o mediante el cmdlet Set-DatabaseAvailabilityGroup para establecer el parámetro ManualDagNetworkConfiguration en True.

La selección de la mejor copia (BCS) es un proceso de algoritmo interno que permite buscar la mejor copia de una base de datos para activarla, y que se selecciona de una lista de posibles copias para activación que incluyen su mantenimiento y estado. Active Manager selecciona la mejor copia disponible (y desbloqueada) para que sea la nueva copia de base de datos activa cuando se produzca un error en la copia activa existente o cuando un administrador realice un cambio sin destino. En Exchange 2010, el proceso BCS evaluó varios aspectos de cada copia de base de datos para determinar la mejor copia para activar. Estos incluían:

  • Copiar longitud de cola

  • Repetir longitud de cola

  • Estado de la base de datos

  • Estado del contenido del índice

En Exchange 2013, Active Manager realiza los mismos pasos y comprobaciones que BCS para determinar el estado de replicación y, además, ahora incluye el uso de una restricción respecto al orden descendente de los estados de mantenimiento. Como resultado de estos cambios, BCS se denomina ahora selección de la mejor copia y servidor (BCSS).

BCSS incluye varias comprobaciones nuevas de estado que forman parte de los componentes de supervisión de disponibilidad administrada integrados en Exchange 2013. Existen cuatro nuevas comprobaciones adicionales que realiza Active Manager (se indican por orden de realización):

  1. Todo correcto   Comprueba un servidor que hospede una copia de la base de datos afectada que tenga todos los componentes de supervisión en un estado correcto.

  2. Hasta correcto normal   Comprueba un servidor que hospede una copia de la base de datos afectada que tenga todos los componentes de supervisión con prioridad "Normal" en un estado correcto.

  3. Todo mejor que el origen   Comprueba un servidor que hospede una copia de la base de datos afectada que tenga los componentes de supervisión en un estado que sea mejor que el servidor actual que hospeda la copia afectada.

  4. Igual que el origen   Comprueba un servidor que hospede una copia de la base de datos afectada que tenga los componentes de supervisión en un estado que sea igual que el servidor actual que hospeda la copia afectada.

Si se invoca BCSS como consecuencia de una conmutación por error desencadenada por un componente de supervisión de disponibilidad administrada (por ejemplo, un respondedor de conmutación por error), se aplica una restricción obligatoria adicional en la que el estado del componente del servidor de destino debe ser mejor que el del servidor en el que ocurrió la conmutación por error. Por ejemplo, si un error de Microsoft Office Outlook Web App desencadena una conmutación por error administrada mediante un respondedor de conmutación por error, BCSS debe seleccionar un servidor que hospede una copia de la base de datos afectada en la cual Outlook Web App sea correcto.

La actualización acumulada 2 (CU2) para la versión RTM de Exchange 2013 contiene un nuevo servicio en servidores de buzones de correo miembros de un DAG. Este servicio se denomina servicio de administración del DAG de Microsoft Exchange (MSExchangeDAGMgmt). Este nuevo servicio contiene funcionalidad de supervisión de DAG interna que anteriormente se ejecutaba dentro del servicio de replicación de Microsoft Exchange (MSExchangeRepl).

Todos los DAG que ejecutan Windows Server 2008 R2 o Windows Server 2012 requieren al menos una dirección IP en todas las subredes incluidas en la red MAPI. El clúster del DAG con el punto de acceso administrativo al clúster (también conocido como nombre de red del clúster) usa las direcciones IP asignadas al DAG para habilitar la resolución de nombres y la conectividad con el clúster (o de forma más precisa, la conectividad con el miembro del clúster que es propietario actualmente del grupo de recursos principal) usando el nombre del clúster. Windows Server 2012 R2 permite crear un clúster de conmutación por error sin un punto de acceso administrativo. Los clústeres de conmutación por error de Windows sin puntos de acceso administrativos tienen las siguientes características:

  • No hay ninguna dirección IP asignada al clúster y, por lo tanto, tampoco un recurso Dirección IP en el grupo de recursos principal del clúster.

  • No hay un nombre de red asignado al clúster y, por lo tanto, tampoco un recurso Nombre de red en el grupo de recursos principal del clúster

  • El nombre del clúster no está registrado en DNS y no se puede resolver en la red.

  • No hay un objeto de nombre clúster (CNO) creado en Active Directory.

  • El clúster de conmutación por error de Windows no se puede administrar con la herramienta Administración del clúster de conmutación por error. Se debe administrar mediante Windows PowerShell y los cmdlets de PowerShell se deben volver a ejecutar en cada miembro de clúster individual.

Cuando se ejecuta en Windows Server 2012 R2 o posteriores, el Service Pack 1 (SP1) para Exchange 2013 y posteriores permite crear un DAG sin un punto de acceso administrativo al clúster. Puede crear un DAG sin un punto de acceso administrativo mediante el Centro de administración de Exchange o el Shell. Para obtener más información, consulte Cómo crear grupos de disponibilidad de base de datos y Crear un grupo de disponibilidad de la base de datos.

Aunque en Exchange 2013 se siguen usando los DAG y los clústeres de conmutación por error de Windows para la resistencia de sitios y la alta disponibilidad del rol de servidor Buzones de correo, la resistencia de sitios no es igual en Exchange 2013. En Exchange 2013 la resistencia de sitios es mucho mejor porque se ha simplificado. Los cambios de arquitectura subyacentes que se efectuaron en Exchange 2013 tienen un impacto considerable en los aspectos de recuperación de una configuración de resistencia de sitios.

En Exchange 2010, la recuperación de buzones (DAG) y de acceso de cliente (matriz del servidor de acceso de cliente) se realizaba de manera conjunta. Si perdía todos los servidores de acceso de cliente, el VIP de la matriz o una parte importante del DAG, se enfrentaba a una situación en la que era necesario realizar un cambio de centro de datos. Este proceso está bien explicado y documentado, aunque conlleva bastante tiempo y requiere la intervención humana para poder iniciarse.

En Exchange 2013, si pierde una matriz de servidor de acceso de cliente por cualquier motivo (por ejemplo, un error en el equilibrador de carga), no es necesario realizar ningún cambio de centro de datos. Con la configuración correcta, la conmutación por error se produce en el nivel del cliente y los clientes se redireccionan automáticamente a un segundo centro de datos que tiene servidores de acceso de cliente operativos. Dichos servidores envían la comunicación mediante proxy de vuelta al servidor de buzones del usuario, al que no le afectará la interrupción (porque no se realiza ningún cambio). En lugar de centrarse en recuperar el servicio, éste se recupera de forma automática y usted podrá dedicarse a solucionar el problema principal (por ejemplo, reemplazar el equilibrador de carga erróneo).

Además, gracias a la simplificación de los espacios de nombres, a la consolidación de los roles de servidor, al desacoplamiento de los requisitos de los roles del servidor del sitio de Active Directory, a la separación de la matriz del servidor de acceso de cliente y la recuperación de DAG y a los cambios en el equilibrio de cargas, Exchange 2013 incorpora algunos cambios que ahora permiten habilitar la recuperación tanto del servidor de acceso de cliente como de DAG para que sea independiente y automática entre los sitios, lo que proporciona escenarios de conmutación por error de centros de datos cuando hay tres ubicaciones.

En Exchange 2010, podría implementar un DAG en dos centros de datos y hospedar el testigo en una tercera base de datos para habilitar la conmutación por error para el rol de servidor Buzón de correo para cualquiera de los centros de datos. Sin embargo, no obtendría la conmutación por error para la solución, porque aún debería cargarse manualmente el espacio de nombres para los roles de los servidores que no sean Buzón de correo.

En Exchange 2013, no es necesario mover el espacio de nombres con el DAG. Exchange aprovecha la tolerancia a errores incorporada en el espacio de nombre mediante el equilibrio de cargas de varias direcciones IP (y, de ser necesario, la capacidad de poner a los servidores fuera de servicio y en funcionamiento). Los clientes HTTP modernos funcionan con esta redundancia de manera automática. La pila HTTP puede aceptar varias direcciones IP para un nombre de dominio completo (FQDN) y, si la primera dirección IP que prueba tiene un error permanente (es decir, no se puede conectar), probará con la próxima dirección IP en la lista. En los errores temporales (la conexión se pierde después de que se establece la sesión, quizás debido a un error intermitente en el servicio en el que, por ejemplo, un dispositivo deja paquetes y debe colocarse fuera de servicio), es posible que el usuario deba actualizar el explorador.

Esto significa que el espacio de nombres ya no es un punto único de error, como sucedía en Exchange 2010. En Exchange 2010, el mayor punto único de error en el sistema de mensajería es posiblemente el FQDN que se proporciona a los usuarios porque les dice dónde ir. En el paradigma de Exchange 2010, cambiar el destino al que el FQDN se dirige no es sencillo porque se debe cambiar el DNS y, luego, controlar la latencia de DNS, lo que, en algunas partes del mundo, representa todo un desafío. También se deben administrar las cachés de nombres en los exploradores, lo que suele tardar aproximadamente 30 minutos.

Uno de los cambios incluidos en Exchange 2013 consiste en habilitar los clientes para que tengan más de un sitio al que dirigirse. Si suponemos que un cliente tiene la capacidad de usar más de un lugar al que dirigirse (casi todos los protocolos de acceso de cliente de Exchange 2013 están basados en HTTP, como Outlook, Outlook en cualquier lugar, EAS, EWS, OWA y EAC, y todos los clientes HTTP admitidos tienen la capacidad de usar varias direcciones IP), la conmutación por error se proporciona en el lado del cliente. Puede configurar DNS para entregar varias direcciones IP a un cliente durante la resolución de nombres. El cliente solicita mail.contoso.com y obtiene, por ejemplo, dos o cuatro direcciones IP. Sin embargo, el cliente usará muchas de las direcciones IP que obtiene de forma confiable. Esto mejora mucho la situación del cliente ya que, si se produce un error en una de las direcciones IP, tiene una o más direcciones IP a las que intentar conectarse. Si el cliente prueba una y genera un error, espera unos 20 segundos y, a continuación, prueba la siguiente de la lista. Por tanto, si pierde el VIP de la matriz de servidor de acceso de cliente, los clientes se recuperan automáticamente en 21 segundos aproximadamente.

Algunas de las ventajas son las siguientes:

  • En Exchange 2010, si perdía el equilibrador de carga en su centro de datos principal y no tenía otro en el sitio, debía hacer un cambio de centro de datos. En Exchange 2013, si pierde el equilibrador de carga en su centro de datos principal, simplemente, debe desconectarlo (o, quizás, desconectar el VIP) y repararlo o remplazarlo. Los clientes que aún no están usando el VIP en el centro de datos secundario realizarán una conmutación por error automática al VIP secundario sin cambiar el espacio de nombre ni realizar cambios en el DNS. Esto no solo significa que ya no deberá realizar un cambio, sino también que no volverá a perder el tiempo que normalmente perdía con la recuperación del cambio de un centro de datos. En Exchange 2010, debía controlar la latencia de DNS (por lo que se recomendaba establecer el Valor del período de vida (TTL) en 5 minutos, y la introducción de la URL de conmutación por recuperación). En Exchange 2013, esto no es necesario, gracias a la rápida conmutación por error (20 segundos) del espacio de nombre entre VIP (centros de datos).

  • Dado que puede realizar la conmutación por error del espacio de nombre entre centros de datos, lo único que se necesita para lograr una conmutación por error del centro de datos es un mecanismo para la conmutación por error del rol del servidor Buzón de correo en centros de datos. Para obtener una conmutación por error automática para el DAG, simplemente cree una solución donde el DAG se divida en partes iguales entre dos centros de datos y, luego, coloque el servidor testigo en una tercera ubicación para que los miembros del DAG puedan arbitrarla en cualquier centro de datos, independientemente del estado de la red entre los centros de datos que contienen los miembros del DAG.

  • En este escenario, los esfuerzos del administrador se enfocan simplemente en solucionar el problema y no se desperdician restaurando el servicio. Simplemente, se arregla el error, mientras el servicio continúa funcionando y se mantiene la integridad de los datos. La urgencia y el nivel de estrés que se sienten cuando se arregla un dispositivo dañado no se comparan con la urgencia y el nivel de estrés que se sienten cuando se trabaja para restaurar el servicio. Es mejor para el usuario final y menos estresante para el administrador.

Puede permitir que se produzcan conmutaciones por error sin tener que realizar retrocesos (a veces denominados conmutaciones por recuperación de manera incorrecta). Si pierde los servidores de acceso de cliente en el centro de datos principal y, como consecuencia, se produce una interrupción de 20 segundos para los clientes, no es necesario que se preocupe por las conmutaciones por recuperación. En este caso, su principal preocupación sería solucionar el problema principal (por ejemplo, reemplazar el equilibrador de carga erróneo). Una vez que esté de nuevo en línea y en funcionamiento, algunos clientes empezarán a usarlo y otros pueden permanecer operativos en el segundo centro de datos.

Exchange 2013 también ofrece una funcionalidad que permite a los administradores manejar los errores intermitentes. Un error intermitente es aquel en el que, por ejemplo, se puede establecer la conexión TCP, pero no ocurre nada después. Los errores intermitentes requieren realizar algún tipo de acción administrativa adicional porque pueden derivarse de un dispositivo de reemplazo que se ha puesto en funcionamiento. Mientras se produce el proceso de reparación, el dispositivo puede estar encendido y aceptar algunas solicitudes, pero puede que no esté listo del todo para prestar servicio a los clientes hasta que se realicen los pasos de configuración necesarios. En esta situación, el administrador puede realizar un cambio de espacio de nombres con tan solo quitar el VIP del dispositivo que se va a reemplazar del DNS. De este modo, durante ese período de servicio, ningún cliente intentará conectarse a él. Después de completarse el proceso de reemplazo, el administrador puede volver a agregar el VIP al DNS y los clientes podrán empezar a usarlo.

Para obtener información sobre cómo planear e implementar la resistencia de sitios, vea Planificación de alta disponibilidad y resistencia de sitios y Implementación de alta disponibilidad y resistencia de sitio.

Terminología básica

Exchange 2013 también incluye una API de replicación de terceros con la que las organizaciones pueden usar soluciones de replicación sincrónica de terceros en lugar de la característica integrada de replicación continua. Microsoft admite soluciones de otros fabricantes que usen esta API, siempre y cuando la solución aporte las funciones necesarias para reemplazar todas las características de replicación continua que se deshabilitan debido al uso de la API. Las soluciones se admiten únicamente si la API se usa con un DAG para administrar y activar copias de bases de datos de buzones. No se admite el uso de la API fuera de estos límites. Además, la solución debe cumplir los requisitos aplicables de compatibilidad de hardware de Windows. (No se requiere la validación de la prueba para la compatibilidad).

Al implementar una solución que usa la replicación integrada de otros fabricantes, debe comprobarse que el proveedor de dicha solución sea el responsable principal de la compatibilidad de la solución. Microsoft admite datos de Exchange para soluciones replicadas y no replicadas. Las soluciones que usan replicación de datos deben cumplir con la directiva de compatibilidad de Microsoft para replicación de datos, como se detalla en el artículo de Microsoft Knowledge Base 895847, Compatibilidad de la replicación de datos de varios sitios en Exchange Server. Además, las soluciones que utilizan el modelo de recurso de clúster de conmutación por error de Windows deben cumplir los requisitos de compatibilidad de clúster de Windows especificados en el artículo de Microsoft Knowledge Base 943984, Directiva de compatibilidad de Microsoft para clústeres de conmutación por error de Windows Server 2008 o Windows Server 2008 R2 o Directiva de compatibilidad de Microsoft para clústeres de conmutación por error de Windows Server 2012.

La directiva de compatibilidad de restauración y copia de seguridad de Microsoft para implementaciones que usan soluciones basadas en API de replicaciones de terceros es la misma que la aplicada en implementaciones de replicaciones continuas nativas.

Si es un socio y busca información sobre la API de replicación de terceros, póngase en contacto con su representante de Microsoft.

Terminología básica

En la siguiente tabla se incluyen vínculos a los temas que le proporcionarán más información acerca de cómo administrar DAG, sobre las copias de bases de datos de buzones, copias de seguridad y restauración para Exchange 2013.

 

Tema Descripción

Grupos de disponibilidad de base de datos

Obtener más información acerca de DAG, Active Manager, el modo de coordinación de activación de centros de datos (DAC) y las copias de bases de datos de buzones.

Planificación de alta disponibilidad y resistencia de sitios

Obtenga más información acerca de aspectos generales, hardware, redes, software, servidores testigo y otros requisitos y procedimientos recomendados para DAG.

Implementación de alta disponibilidad y resistencia de sitio

Consultar un escenario de implementación de ejemplo para implementar y configurar DAG.

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

Obtener más información acerca de las tareas de administración de DAG, cambios y conmutaciones por error y el modo de mantenimiento.

Supervisión de grupos de disponibilidad de base de datos

Obtener más información sobre los scripts y cmdlets integrados para supervisar DAG y copias de base de datos.

Copia de seguridad, restauración y recuperación ante desastres

Obtener más información acerca de la creación de copias de seguridad y restauración de bases de datos de Exchange, bases de datos de recuperación y la recuperación del servidor.

Terminología básica

 
¿Te ha resultado útil?
(Caracteres restantes: 1500)
Gracias por sus comentarios
Mostrar:
© 2014 Microsoft