Cambios en la alta disponibilidad y resistencia del sitio con respecto a las versiones anteriores de Exchange Server
Exchange Server 2013 y versiones posteriores usa DAG y copias de base de datos de buzones (junto con otras características como la recuperación de elementos únicos, 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 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 forma más eficaz posible.
Disponibilidad administrada: con la disponibilidad administrada, la supervisión interna y las características orientadas a la recuperación se integran estrechamente para ayudar a evitar errores, restaurar de forma proactiva los servicios e iniciar automáticamente las conmutaciones por error del servidor o alertar a los administradores para que realicen acciones. 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: el Almacén administrado es el nombre de los procesos reescritos del Almacén de información en Exchange 2013 o posterior. El Almacén administrado se escribe en C# y se integra estrechamente 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 permiten admitir varias bases de datos (mezclas de copias activas y pasivas) en el mismo disco, con lo que se usan discos más grandes en términos de capacidad e IOPS de la manera más eficaz posible.
AutoReseed: la funcionalidad de reseeding automático le 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 durante tiempos prolongados de E/S, consumo excesivo de memoria por MSExchangeRepl.exe y casos graves en los que el sistema está en un estado tan incorrecto que no se pueden programar subprocesos.
Mejoras de copia retrasada: las copias retrasadas ahora pueden cuidarse por sí mismas en cierta medida mediante la reproducción automática del registro. Las copias retrasadas reproducirán automáticamente los archivos de registro en varias situaciones, como la aplicación de revisiones de páginas y escenarios de poco espacio en disco. Si el sistema detecta que la aplicación de revisiones de página es necesaria para una copia retrasada, los registros se reproducirán automáticamente en la copia retrasada para realizar la aplicación de revisiones de 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 Safety Net, lo que facilita la recuperación o la activación.
Mejoras de alertas 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 red de DAG: el sistema puede configurar automáticamente las redes dag en función de 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.
Reducción de IOPS
En Exchange 2010, las copias pasivas de base de datos tienen una profundidad de punto de comprobación baja, que es 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 comprobación baja y realizar estas agresivas operaciones de lectura previa, IOPS para una copia pasiva de base de datos es igual a IOPS para una copia activa en Exchange 2010.
En Exchange 2013 o posterior, el sistema puede proporcionar una conmutación por error rápida mientras se usa 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. Como resultado de aumentar la profundidad del punto de control y desajustar las lecturas previas agresivas, las IOPS de una copia pasiva son aproximadamente el 50 por ciento de la 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, se reescribió el registro ESE para que la memoria caché se conserve durante la transición de pasivo a activo. 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 ahora proporciona una reducción significativa de IOPS con 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 servicios back-end en los servidores de buzones de correo. La disponibilidad administrada incluye tres componentes asincrónicos principales que realizan constantemente el trabajo:
El primer componente es el motor de sondeo, 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 del respondedor, 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 fases; por ejemplo:
Reinicie el grupo de aplicaciones.
Reinicie el servicio.
Reinicie el servidor.
Desconectar el servidor para 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:
Servicio Exchange Health Manager (MSExchangeHMHost.exe): se trata de 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 del Administrador de mantenimiento de Exchange (MSExchangeHMWorker.exe): este es el proceso de trabajo responsable de realizar las tareas en 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 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 del 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 recuperación. En estas arquitecturas de Exchange, hay poco aislamiento, si existe, entre las distintas bases de datos hospedadas en un servidor de buzones de correo. Un problema con una base de datos de buzón de correo única puede afectar negativamente al resto de bases de datos y los bloqueos resultantes de daños en el buzón pueden afectar al servicio de todos los usuarios cuyas bases de datos están hospedadas en ese servidor.
Otro desafío con una única 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 sincronización de caché y comunicación entre procesadores conducen a un rendimiento negativo. Dados los servidores de hoy en día con más de 16 sistemas principales disponibles, esto impondría el desafío administrativo de administrar la afinidad de 8 a 12 núcleos para ESE y usar los otros núcleos para procesos que no son de la Tienda (por ejemplo, Asistentes, Search Foundation, Disponibilidad administrada, etc.). Además, la arquitectura anterior restringió el escalado vertical para el proceso de la Tienda.
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 un montón de configuraciones de discos (JBOD), están disponibles para su uso en todas las configuraciones de almacenamiento admitidas. 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 del aumento de la capacidad de almacenamiento continúa. Por ejemplo, la guía de procedimientos recomendados de Exchange para el tamaño máximo de 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 aumentar el tamaño de las bases de datos, pero esto inhibe la capacidad de administración, ya que podría introducir tiempos de reutilización largos (incluidos los tiempos de reutilización operativamente inmanejables) y la confiabilidad comprometida 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 de JBOD de forma más eficaz. Con varias bases de datos por disco, ahora puede tener los mismos discos de tamaño que almacenan varias copias de 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 del 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 en los volúmenes existentes, otra ventaja de usar varias bases de datos por disco es una reducción en el tiempo necesario para restaurar la protección de datos para los errores que requieren una nueva inicializació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.
Cuando se usan varias bases de datos por volumen, se recomienda seguir estos procedimientos recomendados y 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.
AutoReseed
La reutilización automática (también conocida como AutoReseed) es el reemplazo de lo que normalmente es una acción controlada por el administrador en respuesta a un error de disco, un evento de daños en la base de datos u otro problema que requiere una nueva inicialización de una copia de 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 al sistema recuperarse de errores que afectan a la resistencia o redundancia. Además de los comportamientos de comprobación de errores introducidos en Exchange 2010, Exchange ahora incluye comportamientos de recuperación adicionales para tiempos de E/S largos, 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 bloqueadas que proporcionan resistencia mejorada.
| 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 el 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: Registro del evento 4395 en el canal carmesí con una solicitud de terminación de servicio 2: Iniciar la terminación de MSExchangeRepl.exe 3: Si se produce un error en la terminació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. Safety Net se introdujo en Exchange 2013 para reemplazar la característica de Exchange 2010 conocida como contenedor de transporte. Safety Net es similar al volcado de transporte, ya que es una cola de entrega asociada al servicio de transporte en un servidor de buzones. 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 Safety Net, la activación de 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 encuentra una situación en la que necesita usar la copia retrasada, puede hacer lo siguiente:
Suspenda la replicación en ella.
Cópielo dos veces (para conservar la naturaleza retrasada de la base de datos y para crear una copia adicional en caso de que la necesite).
Realice una copia y descarte todos los archivos de registro, excepto los del intervalo necesario.
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.
Por ejemplo, considere un entorno en el que una base de datos determinada tiene cuatro copias (tres copias de alta disponibilidad y una copia retrasada) y la configuración predeterminada se usa 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 funcionen de forma confiable 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.
Pero en un entorno de resistencia de buzón de Exchange, es importante supervisar el estado y el estado del DAG y 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 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.
El script de 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 detrás si están en un plazo de 10 minutos para 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 notificaciones de 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 alertas que se produce cuando varias bases de datos del mismo servidor entran en una condición de copia única. En Exchange 2010, las alertas de copia única se generan por base de datos. Como resultado, un problema en todo el servidor que afectaba a varias bases de datos y varias copias de base de datos podría provocar tormentas de alertas. Dado que hay varios errores en todo el servidor (por ejemplo, problemas de controlador o memoria), existe la posibilidad de que se produzca una tormenta de alertas para cada incidente del servidor.
Las alertas ahora se generan por servidor. Cuando una interrupción afecta a un servidor completo y la redundancia de datos se vuelve en riesgo para varias copias de base de datos, se genera una única alerta 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 cluster. Si tenía varias redes y las interfaces de una red especificada (por ejemplo, la red MAPI) se encontraban en la misma subred, se requiere poca configuración adicional. Sin embargo, si las interfaces de una red especificada se encontraban en varias subredes, tenía que realizar una tarea conocida como contraer redes DAG.
En Exchange 2013 o posterior, ya no es necesario contraer redes DAG. Exchange sigue usando los mismos mecanismos de detección para distinguir entre las redes MAPI y de replicación, pero ahora contrae automáticamente las redes DAG según corresponda.
Además, de forma predeterminada, el sistema administra automáticamente las redes 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 de red manual modificando las propiedades del DAG mediante 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 o posterior, Active Manager realiza las mismas comprobaciones y fases de BCS para determinar el estado de 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. Active Manager realiza cuatro comprobaciones adicionales (en el orden en que se realizan):
Todo correcto: busca 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 un servidor hospeda una copia de la base de datos afectada que tiene todos los componentes de supervisión con prioridad normal en un estado correcto.
Todo mejor que origen: busca un servidor que hospeda una copia de la base de datos afectada que tiene componentes de supervisión en un estado mejor que el servidor actual que hospeda la copia afectada.
Igual que origen: busca un servidor que hospeda una copia de la base de datos afectada que tiene componentes de supervisión en un estado que es el mismo 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 de DAG interna que estaba anteriormente dentro del servicio de replicación de Microsoft Exchange (MSExchangeRepl).
DAG sin un punto de acceso administrativo al clúster
Todos los DAG en servidores exchange que ejecutan 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 puede administrar el clúster de conmutación por error de Windows mediante la herramienta de administración de clústeres de conmutación por error. En su lugar, debe usar Windows PowerShell y debe 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.