Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
SE APLICA A:
2016 2019 Edición de suscripción
Exchange Server 2013 y versiones posteriores utilizan DAG y copias de base de datos de buzones de correo (junto con otras características como la recuperación de un solo elemento, las directivas de retención y las copias de base de datos retrasadas) para proporcionar alta disponibilidad, resistencia del sitio y protección de datos nativa de Exchange. La plataforma de alta disponibilidad, el almacén de información de Exchange y el motor de almacenamiento extensible (ESE) se han mejorado desde Exchange 2010 para proporcionar disponibilidad y una administración menos compleja, y para reducir los costos. Entre estas mejoras se incluyen:
Reducción de IOPS: esto le permite usar discos más grandes en términos de capacidad e IOPS de la manera más eficiente posible.
Disponibilidad administrada: con la disponibilidad administrada, las características orientadas a la supervisión interna y la recuperación están estrechamente integradas para ayudar a evitar errores, restaurar servicios de forma proactiva e iniciar conmutaciones por error del servidor automáticamente 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 del almacén de información reescritos en Exchange 2013 o posterior. El almacén administrado está escrito en C# y está estrechamente integrado con el servicio de replicación de Microsoft Exchange (MSExchangeRepl.exe) para proporcionar una mayor disponibilidad a través de una resistencia mejorada.
Compatibilidad con varias bases de datos por disco: las mejoras le permiten admitir varias bases de datos (mezclas de copias activas y pasivas) en el mismo disco, utilizando así discos más grandes en términos de capacidad e IOPS de la manera más eficiente posible.
AutoReseed: La capacidad de reinicialización automática permite restaurar rápidamente la redundancia de la 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 característica continúa la innovación introducida en Exchange 2010 para permitir que el sistema se recupere de errores que afectan a la resistencia o la redundancia. Exchange ahora incluye más comportamientos de recuperación para tiempos de E/S largos, consumo excesivo de memoria por MSExchangeRepl.exe y casos graves en los que el sistema está en un estado tan malo que no se pueden programar los subprocesos.
Mejoras de copia retrasada: las copias retrasadas ahora pueden cuidarse a sí mismas hasta cierto punto mediante la reproducción automática de registros. Las copias retrasadas reproducirán automáticamente los archivos de registro en diversas situaciones, como la aplicación de revisiones de página y escenarios de poco espacio en disco. Si el sistema detecta que se requiere aplicación de revisión de página para una copia retrasada, los registros se reproducirán automáticamente en la copia retrasada para aplicar revisiones a la página. Las copias retrasadas también invocarán esta característica de reproducción automática cuando se alcance un umbral de espacio en disco bajo, y cuando se detecte que la copia retrasada es la única copia disponible durante un período de tiempo específico. Además, las copias retrasadas pueden usar la red de seguridad, lo que facilita mucho la recuperación o activación.
Mejoras de la alerta de copia única: la alerta de copia única introducida en Exchange 2010 ya no es un script programado independiente. Ahora se integra en los componentes de disponibilidad administrada del sistema y es una función nativa en Exchange.
Configuración automática de la red DAG: el sistema puede configurar automáticamente las redes DAG en función de los ajustes 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.
Reducción de IOPS
En Exchange 2010, las copias pasivas de la base de datos tienen una profundidad de punto de control baja, necesaria para una conmutación por error rápida. Además, la copia pasiva realiza una lectura previa agresiva de los datos para mantenerse al día con una profundidad de punto de control de 5 megabytes (MB). Como resultado de usar una profundidad de punto de control baja y realizar estas operaciones agresivas de lectura previa, IOPS para una copia pasiva de la base de datos es igual a IOPS para una copia activa en Exchange 2010.
En Exchange 2013 o versiones posteriores, el sistema puede proporcionar una conmutación por error rápida mientras usa una profundidad de punto de control 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. Como resultado del aumento de la profundidad del punto de control y la desafinación de las lecturas previas agresivas, las IOPS para una copia pasiva son aproximadamente el 50 por ciento de las IOPS de copia activa.
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. A partir de Exchange 2013, el registro de ESE se reescribió para que la caché se conserve a través de la transición de 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 resultado de estos cambios, Exchange ofrece ahora una reducción significativa de IOPS respecto a Exchange 2010.
Disponibilidad administrada
La disponibilidad administrada es la integración de la supervisión activa integrada y la plataforma de alta disponibilidad de Exchange. 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 servicios de acceso de cliente (front-end) y los servicios back-end en servidores de buzones de correo. La disponibilidad administrada incluye tres componentes asincrónicos principales que funcionan constantemente:
El primer componente es el motor de sonda, que es responsable de tomar medidas en el servidor y recopilar 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, está 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 podría incluir acciones de recuperación en varias etapas; Por ejemplo:
Reinicie el grupo de aplicaciones.
Reinicie el servicio.
Reinicie el servidor.
Desconecte el servidor para que deje de aceptar 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:
Servicio de administrador de mantenimiento de Exchange (MSExchangeHMHost.exe): este es un proceso de controlador que se usa para administrar los 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 trabajo de Exchange Health Manager (MSExchangeHMWorker.exe): este es el proceso de trabajo responsable de realizar las tareas en tiempo de ejecución.
La disponibilidad administrada utiliza 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 sobre la disponibilidad administrada, consulte Disponibilidad administrada.
Almacén administrado
Exchange 2010 y versiones anteriores admiten la ejecución de una única instancia del proceso de almacén de información (Store.exe) en el rol de servidor Buzón de correo. Esta única instancia de Store hospeda todas las bases de datos del servidor: activa, pasiva, retrasada y de recuperación. En estas arquitecturas de Exchange, hay poco o ningún aislamiento entre las diferentes bases de datos hospedadas en un servidor de buzones de correo. Un problema con una sola base de datos de buzones puede afectar negativamente a todas las demás bases de datos, y los bloqueos resultantes de un buzón dañado pueden afectar al servicio de todos los usuarios cuyas bases de datos estén hospedadas en ese servidor.
Otro desafío con una sola instancia de Store es la falta de escalabilidad del procesador con el motor de almacenamiento extensible (ESE). ESE se escala bien a 8-12 núcleos de procesador, pero más allá de eso, los problemas de comunicación entre procesadores y sincronización de caché conducen a un rendimiento negativo. Dados los servidores actuales con 16+ sistemas de núcleos disponibles, esto impondría el desafío administrativo de administrar la afinidad de 8-12 núcleos para ESE y usar los otros núcleos para procesos que no son de Store (por ejemplo, Assistants, Search Foundation, Managed Availability, etc.). Además, la arquitectura anterior restringía el escalado vertical para el proceso de Store.
El proceso Store.exe ha evolucionado considerablemente con el transcurso de los años al igual que Exchange Server, pero como único proceso, su escalabilidad está limitada y representa un único punto de error. Debido a estos límites, Store.exe se quitó en Exchange 2013 y se reemplazó por el almacén administrado.
Para más información, vea Almacén administrado.
Varias bases de datos por volumen
Aunque las mejoras de almacenamiento en Exchange están diseñadas principalmente para configuraciones de solo un grupo de discos (JBOD), están disponibles para su uso en todas las configuraciones de almacenamiento compatibles. 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. Por ejemplo, la directriz de mejores prácticas de Exchange para el tamaño máximo de la base de datos (2 terabytes) en una unidad de 8 terabytes significa que desperdiciaría más de 5 terabytes de espacio en disco.
Una solución sería hacer crecer las bases de datos, pero eso inhibe la capacidad de administración porque podría introducir largos tiempos de inicialización (incluidos los tiempos de inicialización operativamente inmanejables) y comprometer la confiabilidad de copiar esa cantidad de datos a través de 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.
Exchange 2013 y versiones posteriores se han optimizado para usar discos grandes (8 terabytes) en una configuración JBOD de manera más eficiente. Con varias bases de datos por disco, ahora puede tener discos del mismo tamaño que almacenen varias copias de la base de datos, incluidas las 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
La configuración en el diagrama 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 la configuración del diagrama, 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 de 2.
La segunda copia pasiva tendrá un valor de preferencia de activación de 3.
La copia retrasada tendrá un valor de preferencia de activación de 4.
Además de tener una mejor distribución de los usuarios entre los volúmenes existentes, otra ventaja de usar varias bases de datos por disco es una reducción del tiempo de restauración de la protección de datos en caso de errores que requieran 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 estos procedimientos y requisitos recomendados:
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.
AutoReseed
La reinicialización automática (también conocida como AutoReseed) es la sustitución de lo que normalmente es una acción controlada por el administrador en respuesta a un fallo de disco, un evento de daño de la base de datos u otro problema que requiera la reinicialización de una copia de la base de datos. AutoReseed 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.
Para obtener más información, vea AutoReseed. Para obtener información detallada acerca de AutoReseed, vea Configurar un grupo de disponibilidad de la base de datos AutoReseed.
Recuperación automática de errores de almacenamiento
La recuperación automática de errores de almacenamiento permite que el sistema se recupere de errores que afectan a la resistencia o redundancia. Además de los comportamientos de comprobación de errores introducidos en Exchange 2010, Exchange incluye ahora comportamientos de recuperación adicionales para tiempos de E/S largos, un consumo excesivo de memoria por parte del servicio de replicación de Microsoft Exchange (MSExchangeRepl.exe) y 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. En la tabla siguiente se enumeran las características que proporcionan características de detección y recuperación de E/S suspendidas que proporcionan una mayor resistencia.
| Nombre | Cheque | Acción | 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 y versiones posteriores mejoran la resistencia del servidor y del almacenamiento al incluir comportamientos para otras condiciones graves. Estas condiciones y comportamientos se describen en la tabla siguiente.
| Nombre | Cheque | Acción | Umbral |
|---|---|---|---|
| Estado incorrecto del sistema | No se pueden programar subprocesos, ni siquiera los que no están administrados | Reiniciar el servidor | 302 segundos |
| Largos tiempos de E/S | Mediciones de latencia de operación de E/S | Reiniciar 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 carmesí con una solicitud de finalización del servicio 2: Iniciar la terminació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 |
Mejoras en las copias retrasadas
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. La red de seguridad se introdujo en Exchange 2013 para reemplazar la característica de Exchange 2010 conocida como contenedor de transporte. La red de seguridad es similar al contenedor de transporte, ya que es una cola de entrega asociada al servicio de transporte en un servidor de buzones de correo. Esta cola almacena copias de los mensajes que se entregaron correctamente a la base de datos de buzones de correo activa en el servidor de buzones de correo. Cada base de datos de buzones de correo activa del servidor de buzones de correo 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 de correo 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 red de seguridad, activar una copia de base de datos retrasada resulta más fácil. 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 te encuentras en una situación en la que necesitas usar la copia retrasada, puedes:
Suspenda la replicación en él.
Cópiela dos veces (para conservar el carácter retrasado de la base de datos y crear una copia adicional en caso de que la necesite).
Tome una copia y descarte todos los archivos de registro, excepto los del rango 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; las copias de bases de datos retrasadas no cuentan) 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 o posterior, la aplicación de revisiones de página 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 de páginas es necesaria para una copia retrasada, los registros se vuelven a reproducir automáticamente en la copia retrasada al realizar la aplicación de revisión de páginas. 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 modificando el siguiente valor DWORD del Registro.
HKLM\Software\Microsoft\ExchangeServer\v15\Replay\Parameters\ReplayLagManagerNumAvailableCopies
Para habilitar la reproducción cuando el espacio en disco insuficiente, debe configurar la siguiente entrada del Registro.
HKLM\Software\Microsoft\ExchangeServer\v15\Replay\Parameters\ReplayLagLowSpacePlaydownThresholdInMB
Después de configurar cualquiera de estas opciones del Registro, reinicie el servicio de administración de Microsoft Exchange DAG para que los cambios surtan efecto.
Como ejemplo, imagine un entorno en el que una base de datos determinada tiene cuatro copias (tres copias altamente disponibles y una copia retrasada) y se usa la configuración predeterminada para ReplayLagManagerNumAvailableCopies. Si una copia no retrasada está fuera de servicio por cualquier motivo (por ejemplo, se ha suspendido), la copia retrasada reproducirá automáticamente sus archivos de registro en 24 horas.
Mejoras en la alerta de copia única
Garantizar que los servidores funcionan de forma segura y que las copias de la base de datos de buzones de correo están en buen estado son objetivos principales de las operaciones diarias de mensajería de Exchange. Debe supervisar de manera activa el hardware, el sistema operativo Windows y los servicios de Exchange.
Sin embargo, en un entorno de resistencia de buzones de Exchange, es importante que supervise el mantenimiento y el estado del DAG y de las copias de la base 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 fundamental en entornos que no usan la matriz redundante de discos independientes (RAID) y, en su lugar, implementan configuraciones 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.
El script CheckDatabaseRedundancy.ps1 se introdujo en Exchange 2010. 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. Las copias retrasadas no se consideran atrasadas si están dentro de los 10 minutos en reproducir sus registros en 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.
La funcionalidad nativa sigue alertando a los administradores a través de las notificaciones del registro de eventos y, para distinguir las alertas de Exchange 2013 o posteriores de Exchange 2010, Exchange ahora usa los siguientes identificadores de evento:
Evento 4138 (alerta roja)
Evento 4139 (alerta verde)
La funcionalidad nativa se ha mejorado para reducir el ruido de alerta que se produce cuando varias bases de datos del mismo servidor entran en una sola condición de copia. En Exchange 2010, las alertas de copia única se generan por base de datos. Como resultado, un problema en todo el servidor que afectara a varias bases de datos y a varias copias de bases de datos podría provocar tormentas de alertas. Dado que varios errores afectan a todo el servidor (por ejemplo, problemas con el controlador o la memoria), había una buena posibilidad de que se produjera una tormenta de alertas para cada incidente del servidor.
Ahora las alertas se generan por servidor. Cuando una interrupción afecta a un servidor completo y la redundancia de datos corre el riesgo de varias copias de la base de datos, se genera una alerta única por servidor.
Configuración automática de redes de DAG
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 creó las redes DAG iniciales (por ejemplo, DAGNetwork01 y DAGNetwork02) en función de las subredes enumeradas por el servicio de clúster. Si tenía varias redes y las interfaces de una red especificada (por ejemplo, la red MAPI) estaban en la misma subred, se requería poca configuración adicional. Sin embargo, si las interfaces de una red especificada estaban en varias subredes, tenía que realizar una tarea conocida como contraer redes DAG.
En Exchange 2013 o versiones posteriores, ya no es necesario contraer redes DAG. Exchange sigue usando los mismos mecanismos de detección para distinguir entre MAPI y las redes de replicación, pero ahora colapsa automáticamente las redes DAG según corresponda.
Además, de forma predeterminada, el sistema administra automáticamente las redes de DAG. Para ver las propiedades de red del DAG mediante el Centro de administración de Exchange (EAC), debe configurar el DAG para el control manual de la red modificando las propiedades del DAG mediante el EAC o mediante el cmdlet Set-DatabaseAvailabilityGroup para establecer el parámetro ManualDagNetworkConfiguration en $true.
Cambios en la selección de la mejor copia
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 evalúa 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 índice de contenido
En Exchange 2013 y versiones posteriores, Active Manager realiza las mismas comprobaciones y fases de BCS para determinar el estado de la replicación, pero ahora también incluye el uso de una restricción del orden decreciente 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 de estado nuevas que ahora forman parte de los componentes integrados de supervisión de disponibilidad administrada en Exchange. Hay cuatro comprobaciones adicionales realizadas por Active Manager (enumeradas en el orden en que se realizan):
Todo en buen estado: comprueba si hay un servidor que hospede una copia de la base de datos afectada que tenga todos los componentes de supervisión en un estado correcto.
Hasta normal Correcto: comprueba si hay 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.
Todo mejor que el origen: Comprueba si hay un servidor que hospede una copia de la base de datos afectada que tenga componentes de supervisión en un estado mejor que el servidor actual que hospeda la copia afectada.
Igual que origen: Comprueba si hay un servidor que hospede una copia de la base de datos afectada que tenga componentes de supervisión en un estado 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 Outlook en la Web (anteriormente conocido como Outlook Web App) desencadena una conmutación por error de disponibilidad administrada a través de un respondedor de conmutación por error, BCSS debe seleccionar un servidor que hospede una copia de la base de datos afectada en la que Outlook en la Web esté en buen estado.
Servicio de administración del DAG
Exchange 2013 CU2 o posterior incluye el servicio de administración de DAG de Microsoft Exchange (MSExchangeDAGMgmt). Este servicio contiene la funcionalidad de supervisión interna del DAG que anteriormente se encontraba en el servicio de replicación de Microsoft Exchange (MSExchangeRepl).
DAG sin un punto de acceso administrativo al clúster
Todos los DAG de servidores Exchange que ejecuten Windows Server 2008 R2 o Windows Server 2012 requieren al menos una dirección IP en cada subred incluida 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 o posterior 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 se asigna ninguna dirección IP al clúster, por lo que no hay ningún recurso de dirección IP en el grupo de recursos principal del clúster.
No se asigna ningún nombre de red al clúster, por lo que no hay ningún recurso de nombre de red en el grupo de recursos principal del clúster.
El nombre del clúster no está registrado en DNS y el nombre del clúster no se puede resolver en la red.
No se crea un objeto de nombre de clúster (CNO) en Active Directory.
No se puede administrar el clúster de conmutación por error de Windows mediante la herramienta Administración de clústeres de conmutación por error. En su lugar, deberá usar Windows PowerShell y ejecutar los cmdlets de PowerShell en los miembros individuales del clúster.
Exchange 2013 SP1 o posterior que se ejecuta en Exchange en Windows Server 2012 R2 o posterior le permite crear un DAG sin un punto de acceso administrativo de clúster. Para más información, vea Cómo crear grupos de disponibilidad de base de datos y Crear un grupo de disponibilidad de base de datos.