Alta Disponibilidad y Resistencia de Sitios

Alta disponibilidad y
resistencia de sitios
Exchange 2016
[Este tema es documentación previa y, por lo tanto, está sujeto a cambios en versiones futuras. Los
temas en blanco se incluyen como marcadores. Si tiene comentarios, nos encantaría escucharlos.
Envíenos un correo electrónico a ExchangeHelpFeedback@microsoft.com].
Se aplica a:Exchange Server 2016
Resumen: acerca de la alta disponibilidad y sitio resistencia capacidades disponibles en Exchange
2016.
Puede proteger sus bases de datos del buzón de Exchange Server 2016 y los datos que contienen
mediante la configuración de los servidores de Exchange de 2016 y bases de datos de alta
disponibilidad y resistencia de sitios. Intercambio de 2016 minimiza el costo y la complejidad de la
implementación de una solución de mensajería altamente disponible y sea resistente al tiempo que
proporciona altos niveles de servicio y disponibilidad de datos y soporte para buzones muy
grandes.
2016 de Exchange permite a los clientes de todos los tamaños y en todos los segmentos
económicamente implementar un servicio de mensajería de continuidad en su organización al
basarse en las capacidades de replicación nativa y la arquitectura de alta disponibilidad que se
introdujo por primera vez en Exchange 2010. Para obtener una lista de cambios desde Exchange
2010, consulte Cambios en la alta disponibilidad y resistencia de sitios respecto a versiones
anteriores.
Contenido
Terminología clave
Grupos de disponibilidad de la base de datos
Copias de la base de datos de buzones
Gestor activo
Resistencia de sitios
API de replicación de otros fabricantes
Documentación de resistencia alta disponibilidad y sitio
Terminología básica
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 de correo 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
Un grupo de hasta 16 servidores de 2016 de Exchange que aloja un conjunto de bases de
datos replicadas.
Movilidad de la base de datos
La capacidad de una base de datos de buzón de Exchange 2016 para replicarse en y
montado en otros servidores de Exchange de 2016.
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 para implementar alta disponibilidad y elasticidad de sitio después de instalar
Exchange 2016.
Copia de base de datos de buzones de correo con retardo
Copia pasiva de una base de datos de buzones de correo que presenta un tiempo de
retardo de reproducción de registro superior a cero.
Copia de base de datos de buzones de correo
Base de datos de buzones de correo (archivo .edb y registros), ya sea en estado activo o
pasivo.
Resistencia de buzón
El nombre de una alta disponibilidad y sitio resistencia solución unificada en Exchange
2016.
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.
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.
Key terminology
Grupos de disponibilidad de base de datos

Un DAG es el componente base de alta disponibilidad y sitio resistencia framework integrado en
Exchange 2016. Un DAG es un grupo de hasta 16 servidores de 2016 de Exchange que alojan un
conjunto de bases de datos y proporciona recuperación automática, nivel de base de datos de
errores que afectan a servidores, redes o bases de datos individuales. Cualquier servidor en un DAG
puede alojar una copia de una base de datos de buzones desde cualquier otro servidor de la DAG.
Cuando se agrega un servidor a un DAG, funciona con los demás servidores de la DAG para
proporcionar la recuperación automática de errores que afectan a las bases de datos de buzón,
como un error de disco o errores de servidor. Para obtener más información sobre DAGs,
consulte Grupos de disponibilidad de base de datos (DAG).
Key terminology
Copias de bases de datos de buzones de correo

Las características de resistencia alta de un sitio y disponibilidad usados introducidos en primer
Exchange 2010 se utilizan en Exchange 2016 para crear y mantener copias de la base de datos.
Exchange 2016 también aprovecha el concepto de movilidad de la base de datos, que es Exchange-
managed conmutaciones por error de nivel de base de datos.
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.
Configuración de una copia de la base de datos como la base de datos de buzón activo se conoce
como un cambio. Cuando se produce un error que afecta a una base de datos o el acceso a una
base de datos y una base de datos se convierte en la copia activa, este proceso se conoce como
una conmutación por error. Este proceso también se refiere a un error del servidor en el que uno o
más servidores de poner en línea las bases de datos previamente en línea en el servidor que ha
fallado. Cuando se produce un cambio o la conmutación por error, otros servidores Exchange 2016
conozcan el cambio casi de inmediato y redirección el tráfico a la nueva base de datos activa de
mensajería y cliente.
Por ejemplo, si una base de datos activa en un DAG falla debido a un error de almacenamiento de
información subyacente, se recuperará automáticamente administrador Active por conmutación por
error a una copia de la base de datos en otro servidor en el DAG. En Exchange 2016, disponibilidad
administrada proporciona comportamientos para recuperarse de la pérdida del acceso de protocolo
para una base de datos, incluyendo grupos de trabajo de aplicaciones de reciclaje, reiniciar los
servicios y los servidores y el inicio de conmutaciones por error de base de datos.
Para obtener más información acerca de copias de la base de datos de buzones, consulte Copias de
bases de datos de buzones.
Key terminology
Active Manager
Exchange 2016 aprovecha Active Manager para administrar la base de datos y estado de la copia de
la base de datos, estado, replicación continua y otros aspectos de alta disponibilidad. Para obtener
más información acerca del Administrador de activo, consulte Active Manager.
Key terminology
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 2016, el espacio de nombres no necesita mover con el DAG. Exchange aprovecha la
tolerancia a errores integrada en el espacio de nombres a través de varias direcciones IP, carga
equilibrio (y si fuera necesario, la capacidad de tener servidores dentro y fuera de servicio). Los
clientes HTTP modernos funcionan con esta redundancia automáticamente. La pila HTTP puede
aceptar varias direcciones IP para un nombre de dominio completo (FQDN), y si la primera dirección
IP intenta falla de disco duro (es decir, no se puede conectar), probará la siguiente dirección IP en la
lista. En un fallo leve (la conexión se pierde una vez establecida la sesión, quizás debido a un error
intermitente en el servicio donde, por ejemplo, un dispositivo descarta paquetes y debe realizarse
fuera de servicio), el usuario puede necesitar actualizar su 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.
En Exchange 2016, los clientes tienen más de un lugar. Casi todos los clientes acceso a protocolos
en Exchange 2016 están basados en HTTP. Algunos ejemplos son Outlook, EAS, EWS, Outlook en el
web y CEF). Todos los clientes HTTP compatibles tienen la posibilidad de utilizar varias direcciones
IP, lo que proporciona conmutación por error en el cliente. Puede configurar DNS para distribuir
varias direcciones IP a un cliente durante la resolución de nombres. El cliente solicita
mail.contoso.com y recibe dos direcciones IP o cuatro direcciones IP, por ejemplo. Sin embargo,
muchas direcciones IP que el cliente recibe se utilizará de forma confiable por el cliente. Esto hace
que mucho mejores porque si se produce un error en una de las direcciones IP, el cliente tiene uno
o más alternativas direcciones IP para intentar conectar con el cliente. Si un cliente intenta uno y se
produce un error, espera unos 20 segundos y, a continuación, intenta lo siguiente en la lista. Por lo
tanto, si se pierde a la dirección VIP de la matriz de servicio de acceso de cliente, recuperación de
los clientes sucede automáticamente y en unos 21 segundos.
Algunas de las ventajas son las siguientes:
 En Exchange 2016, si pierde el equilibrador de carga del sitio principal, puede simplemente
activar off (o tal vez apagar la dirección VIP) y reparar o reemplazarlo. Los clientes que ya no
están utilizando a la dirección VIP en el centro de datos secundario se conmutar por error
automáticamente a la dirección VIP secundaria sin cambio de espacio de nombres y sin
ningún cambio en el DNS. No sólo significa eso ya no tendrá que realizar un cambio, pero
también significa que todo el tiempo que normalmente se asocian con una recuperación de
cambio de centro de datos no está invertido. En Exchange 2010, tenía que controlar la
latencia DNS (por lo tanto, la recomendación para establecer el tiempo de vida (TTL) a 5
minutos y la introducción de la dirección URL de la conmutación por recuperación). En
Exchange 2016, no necesita hacerlo porque obtendrá un failover rápido (20 segundos) del
espacio de nombres entre VIPs (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. Si solo
tiene dos centros de datos y no dispone de una tercera la ubicación física, puede colocar el
servidor testigo en una máquina virtual de Microsoft Azure. Vea Usar una máquina virtual
de Microsoft Azure como un servidor testigo del DAG para más información.
 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 la conmutación por error se produzca sin tener que realizar zigzag (en ocasiones
erróneamente denomina failbacks). Si pierde los servidores en su centro de datos principal, dando
como resultado una interrupción del segundo 20 para los clientes, que podría incluso interesen
failback. En este punto, su principal preocupación debería ser solucionar el problema de core (por
ejemplo, reemplazando el equilibrador de carga fallida). Una vez nuevamente en línea y
funcionando, algunos clientes comenzar a utilizarla y otros clientes podrían permanecer en
funcionamiento a través del segundo centro de datos.
Exchange 2016 también proporciona funcionalidad que permite a los administradores ocuparse de
errores intermitentes. Un fallo intermitente es donde, por ejemplo, la conexión TCP inicial puede
realizarse, pero no ocurre nada después. Un fallo intermitente requiere a algún tipo de acción
administrativa adicional que deban adoptarse porque podría ser el resultado de su puesto en
servicio un dispositivo de repuesto. Mientras se está produciendo este proceso de reparación, el
dispositivo podría ser accionado en y aceptando algunas solicitudes, pero no está listo para servir a
clientes hasta que se realizan los pasos de configuración necesarios realmente. En este escenario, el
administrador puede realizar un cambio de espacio de nombres simplemente quitando la dirección
VIP para el dispositivo se reemplazó de DNS. A continuación, durante ese período de servicio,
ningún cliente intentará conectarse a él. Una vez finalizado el proceso de reemplazo, el
administrador puede agregar a la dirección VIP a DNS y los clientes iniciarán finalmente utilizarlo.
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 sitios.
Key terminology
API de replicación de terceros

Exchange 2016 incluye una API que permite a las organizaciones utilizar soluciones de replicación
sincrónica de terceros en lugar de la característica de replicación continua incorporada de
replicación de terceros. Microsoft es compatible con soluciones de otros fabricantes que utilizan
esta API, siempre que la solución proporciona la funcionalidad necesaria para reemplazar toda la
funcionalidad de replicación continua nativa está deshabilitada debido al uso de la API. Soluciones
sólo son compatibles cuando se utiliza la API dentro de un DAG para administrar y activar copias de
la base 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.
(Validación de la prueba no es necesario para compatibilidad con).
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.
Key terminology
Documentación de alta disponibilidad y resistencia de

sitios
En la tabla siguiente contiene vínculos a temas que le ayudarán a conocer y administrar DAGs,
copias de la base de datos de buzones y backup y restore para Exchange 2016.
/////////////////////////////////////////////
Grupos de disponibilidad de
base de datos (DAG)
Exchange 2016

Resumen: Para obtener más información sobre los grupos de disponibilidad de base de datos,
consulte Exchange 2016.
Un grupo de disponibilidad de base de datos (DAG) es el componente básico del marco de alta
disponibilidad y resistencia de sitios del servidor de buzones que ofrece Microsoft Exchange Server
2016. Se trata de un grupo de hasta 16 servidores de buzones de correo que aloja un conjunto de
bases de datos y proporciona recuperación automática en el nivel de la base de datos de los errores
que afectan a los servidores o bases de datos individuales.
Importante:
Todos los servidores que haya en un DAG deben ejecutar la misma versión de Exchange. No se
pueden mezclar servidores de Exchange de 2013 y Exchange 2016 en el mismo DAG.
Un DAG es un límite para la replicación de bases de datos de buzones, los cambios de bases de
datos y de servidores, y las conmutaciones por error así como para un componente interno
denominado Active Manager. Active Manager, que se ejecuta en todos los servidores de buzones,
administra los cambios y las conmutaciones por error en el DAG. Para obtener más información
acerca de Active Manager, consulte Active Manager.
Cualquier servidor en un DAG puede hospedar una copia de una base de datos de buzones de
correo de cualquier otro servidor en el DAG. Cuando se agrega un servidor a un DAG, funciona con
los otros servidores del DAG para proporcionar recuperación automática de errores que afectan a
las bases de datos de buzones, como un error de disco, de servidor o de red.
Nota:
Para obtener más información sobre la creación de DAG, la administración de los miembros de los
DAG, la configuración de propiedades de los DAG, la creación y supervisión de copias de bases de
datos de buzones, y la realización de cambios, consulte Administración de alta disponibilidad y
resistencia de sitios.
Ciclo de vida del grupo de disponibilidad de base de

datos
Los DAG aprovechan el concepto de la implementación incremental, que es la capacidad de
implementar la disponibilidad de servicios y datos en todos los servidores y bases de datos de
buzones una vez que se haya instalado Exchange. Tras la implementación de los servidores Buzón
de correo de Exchange 2016, se puede crear un DAG, agregar servidores de buzones de correo y, a
continuación, replicar las bases de datos de buzones entre los miembros del DAG.
Nota:
Admite la creación de un DAG que contenga una combinación de servidores de buzones de correo
físicos y servidores de buzones de correo virtualizados, siempre y cuando los servidores y la
solución cumplan con Requisitos del sistema para Exchange 2016 y los requisitos establecidos
en Virtualización de Exchange 2016. Como en todas las configuraciones de alta disponibilidad de
Exchange, se debe garantizar que el tamaño de todos los servidores de buzones de correo del DAG
se haya determinado adecuadamente para poder controlar la carga de trabajo necesaria durante
interrupciones programadas y no programadas.
Los DAG se crean con el cmdlet New-DatabaseAvailabilityGroup. Inicialmente se crean como

objetos vacíos en Active Directory. Este objeto de directorio se usa para almacenar información
relevante acerca del DAG, como la información de suscripción del servidor y algunas
configuraciones del DAG. Al agregar el primer servidor a un DAG, se crea automáticamente un
clúster de conmutación por error para el DAG. El DAG usa de manera exclusiva este clúster de
conmutación por error; dicho clúster debe dedicarse al DAG. El uso del clúster no se permite para
ninguna otra finalidad.
Además de crearse un clúster de conmutación por error, se inicia la infraestructura que supervisa los
servidores en busca de errores en la red o el servidor. El mecanismo de latidos del clúster de
conmutación por error y la base de datos del clúster se usan para administrar la información sobre
el DAG que puede cambiar rápidamente (como el estado de montaje de la base de datos, el estado
de replicación y la última ubicación de montaje) y para realizar un seguimiento de dicha
información.
Cuando se crea, el DAG recibe un nombre único y una o varias direcciones IP estáticas, o bien se
configura para que use el Protocolo de configuración dinámica de host (DHCP) o se crea sin un
punto de acceso administrativo del clúster. Solo podrá crear los DAG sin ningún punto de acceso
administrativo en servidores que ejecuten Exchange 2016 o Exchange 2013 Service Pack 1 o una
versión posterior con Windows Server 2012 R2, versión Standard o Datacenter. Estas son las
características de los DAG sin puntos de acceso administrativo del clúster:
 No hay ninguna dirección IP asignada al clúster o al DAG y, por lo tanto, tampoco hay un
recurso de 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 o del DAG no están registrados 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 no se puede administrar mediante 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.
Este ejemplo muestra cómo usar el Shell de administración de Exchange para crear un DAG con un
punto de acceso administrativo del clúster que tendrá tres servidores. Dos servidores (EX1 y EX2)
están en la misma subred (10.0.0.0) y el tercero (EX3) está en otra (192.168.0.0).
New-DatabaseAvailabilityGroup -Name DAG1 -WitnessServer EX4 -
DatabaseAvailabilityGroupIPAddresses 10.0.0.5,192.168.0.5
Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer EX1
Los comandos para crear un DAG sin un punto de acceso administrativo del clúster son muy
similares:
New-DatabaseAvailabilityGroup -Name DAG1 -WitnessServer EX4 -
DatabaseAvailabilityGroupIPAddresses ([System.Net.IPAddress])::None
El clúster para DAG1 se crea al agregar EX1 al DAG. Durante la creación de clústeres, el cmdlet Add-
DatabaseAvailabilityGroupServer recupera las direcciones IP configuradas para el DAG e ignora
las que no coinciden con ninguna de las subredes halladas en EX1. En el primer ejemplo, el clúster
para DAG1 se crea con la dirección IP 10.0.0.5, mientras que 192.168.0.5 no se tiene en cuenta. En el
segundo ejemplo de arriba, el valor del parámetro DatabaseAvailabilityGroupIPAddresses indica a la
tarea que cree un clúster de conmutación por error para el DAG que no tiene punto de acceso
administrativo. Por tanto, el clúster se crea con un recurso de dirección IP o de nombre de red en el
grupo de recursos principal del clúster.
A continuación, se agrega EX2 y el cmdlet Add-DatabaseAvailabilityGroupServer recupera de
nuevo las direcciones IP configuradas para el DAG. Las direcciones IP del clúster no cambian porque
EX2 está en la misma subred que EX1.
A continuación, se agrega EX3 y el cmdlet Add-DatabaseAvailabilityGroupServer recupera de
nuevo las direcciones IP configuradas para el DAG. Puesto que en EX3 hay una subred que coincide
con 192.168.0.5, la dirección 192.168.0.5 se agrega como recurso de dirección IP al grupo de
clústeres. Además, se configura automáticamente una dependencia OR para el recurso Nombre de
red de cada recurso de dirección IP. El clúster usará la dirección 192.168.0.5 cuando el grupo de
recursos principal del clúster se mueva a EX3.
Para los DAG con puntos de acceso administrativo del clúster, la agrupación en clústeres de
conmutación por error de Windows registra las direcciones IP del clúster en el Sistema de nombres
de dominio (DNS) cuando el recurso Nombre de red se pone en línea. Además, cuando EX1 se
agrega al clúster, se crea un objeto de nombre de clúster (CNO) en Active Directory. El nombre de
red, las direcciones IP y el CNO para el clúster no se usan en los roles del DAG. Los administradores
y los usuarios finales no necesitan conectarse a la dirección IP ni al nombre del DAG o del clúster, ni
usarlos como interfaz. Algunas aplicaciones de terceros se conectan al punto de acceso
administrativo del clúster para realizar tareas de administración, como copia de seguridad o
supervisión. Si no usa ninguna aplicación de terceros que requiera un punto de acceso
administrativo del clúster, y el DAG se ejecuta Exchange 2016 en Windows Server 2012 R2, le
recomendamos que cree un DAG sin un punto de acceso administrativo. Conseguirá que el proceso
de configuración del DAG sea más sencillo, ya no necesitará una o varias direcciones IP y reducirá la
superficie de ataque del DAG.
Los DAG también se configuran para usar un servidor testigo y un directorio testigo. El sistema
configura automáticamente el servidor testigo y el directorio testigo, aunque también los puede
configurar manualmente el administrador. En los ejemplos anteriores, EX4 (un servidor que no
forma parte del DAG ni lo hará en el futuro) se está configurando manualmente como el servidor
testigo del DAG.
De manera predeterminada, un DAG se diseña para que utilice la característica integrada de
replicación continua y replique las bases de datos de buzones entre sus servidores. Si utiliza una
replicación de datos de terceros que admite la API de replicación de terceros de Exchange 2016,
deberá crear el DAG en el modo de replicación de terceros mediante el cmdlet New-
DatabaseAvailabilityGroup con el parámetro ThirdPartyReplication. Una vez habilitado este modo,
no se puede deshabilitar.
Una vez creado el DAG, se le pueden agregar servidores de buzones de correo. Cuando se agrega el
primer servidor al DAG, se forma un clúster para que el DAG lo utilice. Los DAG hacen uso de la
tecnología de clúster de conmutación por error de Windows, como el latido de clúster, las redes de
clústeres y la base de datos de clústeres (para almacenar datos que cambian, por ejemplo el estado
de base de datos que cambia de activa a pasiva y viceversa, o de montada a desmontada y
viceversa). Al irse agregando al DAG cada uno de los siguientes servidores, se une al clúster
subyacente, el Exchange ajusta automáticamente el modelo de quórum del clúster y el servidor se
agrega al objeto DAG en Active Directory.
Una vez que se han agregado servidores de buzones de correo al DAG, se pueden configurar
algunas de las propiedades de este último, por ejemplo si se debe usar el cifrado de red o la
compresión de red para la replicación de bases de datos en el DAG. También se pueden configurar
las redes de DAG y crear más.
Una vez que se han agregado miembros al DAG y éste se ha configurado, las bases de datos de
buzones activas de cada servidor se pueden replicar en los demás miembros del DAG. Después de
crear copias de las bases de datos de buzones, se puede supervisar su estado de mantenimiento
con varias herramientas de supervisión integradas. Además, puede realizar cambios de base de
datos y servidores.
Modelos de quórum de grupos de disponibilidad de base de datos
Debajo de cada DAG hay un clúster de conmutación por error de Windows. Los clústeres de
conmutación por error utilizan el concepto de quórum, que emplea un consenso de votantes para
garantizar que solamente un subconjunto de miembros del clúster (que podría ser todos los
miembros o una mayoría de miembros) funcione a la vez. El quórum no es un concepto nuevo para
Exchange 2016. Los servidores Buzón de correos de alta disponibilidad de versiones anteriores de
Exchange usan también la agrupación en clústeres de conmutación por error y su concepto de
quórum. El quórum representa una visión compartida de los miembros y los recursos, y el quórum
de término también se utiliza para describir los datos físicos que representan la configuración
dentro del clúster que se comparte entre todos los miembros del mismo. A consecuencia de ello,
todos los DAG necesitan su clúster de conmutación por error subyacente para tener quórum. Si el
clúster pierde quórum, todas las operaciones del DAG terminarán y todas las bases de datos
albergadas en el mismo se desmontarán. En este caso, es necesario que intervenga el administrador
para corregir el problema de quórum y restaurar las operaciones del DAG.
El quórum es importante para asegurar la coherencia, como mecanismo para resolver empates y
como garantía de la capacidad de respuesta de los clústeres:
 Garantizar la coherencia Un requisito fundamental para un clúster de conmutación por
error de Windows es que cada uno de sus miembros tenga siempre una vista del clúster
que sea coherente con los otros miembros. La sección del clúster actúa como repositorio
definitivo de toda la información de configuración relativa al clúster. Si la sección del clúster
no puede cargarse localmente en un miembro del DAG, el servicio del clúster no se inicia al
no poder garantizar que el miembro cumpla el requisito de tener una vista del clúster que
sea coherente con los otros miembros.
 Mecanismo para resolución de empates Se usa en los DAG un recurso de testigo de
quórum con un número par de miembros para evitar el síndrome de cerebro dividido y
asegurarse de que solamente se considere oficial una colección de los miembros del DAG.
Cuando el servidor testigo se necesita para quórum, cualquier miembro del DAG que pueda
comunicarse con el servidor testigo puede colocar un bloqueo de Bloque de mensajes del
servidor en el archivo witness.log del servidor testigo. El miembro del DAG que bloquea el
servidor testigo (denominado nodo de bloqueo) retiene un voto adicional por motivos de
quórum. Los miembros del DAG que están en contacto con el nodo de bloqueo son
mayoría y mantienen el quórum. Cualquier miembro del DAG que no pueda estar en
contacto con el nodo de bloqueo forma parte de la minoría y por lo tanto pierde el
quórum.
 Asegurar la capacidad de respuesta Para garantizar la capacidad de respuesta, el modelo
de quórum se asegura de que, siempre que se ejecute el clúster, estén operativos y
comunicativos suficientes miembros del sistema distribuido, y de que se garantice al menos
una réplica del estado actual del clúster. No se necesita tiempo adicional para poner en
conexión otros miembros ni para determinar si está garantizada un réplica en concreto.
Los DAG con un número par de miembros usan el modo de quórum Mayoría de recursos
compartidos de archivos y nodo del clúster, que emplea un servidor testigo externo que ejerce de
mecanismo para resolver empates. En este modo de quórum, cada miembro de DAG obtiene un
voto. Asimismo, el servidor testigo se usa para proporcionar a un miembro de DAG un voto
ponderado (por ejemplo, obtiene dos votos en vez de uno). Los datos del quórum de clúster se
almacenan de forma predeterminada en el disco del sistema de cada miembro del DAG y se
mantienen coherentes en esos discos. Sin embargo, no se guarda una copia de los datos del
quórum en el servidor testigo. Se utiliza un archivo en el servidor testigo para mantener un
seguimiento del miembro que tiene la copia de datos más actualizada, pero el servidor testigo no
tiene una copia de los datos de quórum del clúster. En este modo, una mayoría de los votantes (los
miembros del DAG más el servidor testigo) deben estar operativos y poderse comunicar entre sí
para mantener el quórum. Si la mayoría de los votantes no pueden comunicarse entre sí, el clúster
subyacente del DAG pierde el quórum y para que el DAG vuelva a estar operativo requerirá una
intervención del administrador.
Los DAG con un número impar de miembros usan un modo de quórum de nodos mayoritarios. En
este modo, cada miembro obtiene un voto y el disco del sistema local de cada miembro se usa para
almacenar los datos de quórum del clúster. Si la configuración del clúster cambia, ese cambio se
refleja en todos los discos. El cambio solamente se considera efectuado y permanente si se realiza
en los discos de la mitad de los miembros (redondeado) más uno. Por ejemplo, en un DAG de cinco
miembros, el cambio debe efectuarse en dos miembros más uno, o en un total de tres miembros.
El quórum precisa una mayoría de votantes para que puedan comunicarse entre sí. Suponga un
DAG con cuatro miembros. Como este DAG tiene un número par de miembros, un servidor testigo
externo se emplea para proporcionar a uno de los miembros del clúster un quinto voto que
resuelva el empate. Para mantener una mayoría de votantes, y por lo tanto quórum, debe haber al
menos tres votantes a fin de poder comunicarse entre sí. Un máximo de dos votantes puede estar
sin conexión en cualquier momento sin que se interrumpa el servicio y el acceso a los datos. Si tres
votantes o más están sin conexión, el DAG pierde el quórum y el servicio y el acceso a los datos se
interrumpirán hasta que se resuelva el problema.
Planificación de alta
disponibilidad y resistencia de
sitios
Intercambio 2016
Otras versiones

Resumen: qué elementos de alta disponibilidad y resiliencia del sitio debe incorporar en su plan de
implementación de Exchange 2016.
Durante la fase de planificación, los arquitectos del sistema, los administradores y otras partes
interesadas clave deben identificar los requisitos del negocio y los requisitos arquitectónicos para la
implementación; en particular, los requisitos sobre alta disponibilidad y resistencia del sitio.
Hay requisitos generales que deben cumplirse para implementar estas características, así como los
requisitos de hardware, software y redes que también deben cumplirse.
Contenido
Requerimientos generales
Requisitos de hardware
Requisitos de almacenamiento
Requisitos de Software
Requisitos de red
Requisitos del servidor testigo
Planificación para la resistencia del sitio
Antes de implementar un grupo de disponibilidad de base de datos (DAG) y crear copias de la base
de datos del buzón, asegúrese de que se cumplan las siguientes recomendaciones para todo el
sistema:
 El Sistema de nombres de dominio (DNS) debe estar ejecutándose. Idealmente, el servidor
DNS debería aceptar actualizaciones dinámicas. Si el servidor DNS no acepta
actualizaciones dinámicas, debe crear un registro de host DNS (A) para cada servidor de
Exchange. De lo contrario, Exchange no funcionará correctamente.
 Cada servidor de buzones en un DAG debe ser un servidor miembro en el mismo dominio.
 No se admite agregar un servidor de buzón de Exchange 2016 que también sea un servidor
de directorio a un DAG.
 El nombre que asigne al DAG debe ser un nombre de computadora válido, disponible y
exclusivo de 15 caracteres o menos.
Requisitos de hardware
Generally, there are no special hardware requirements specific to DAGs or mailbox database copies.
The servers used must meet all of the requirements set forth in Requisitos previos de Exchange
2016and Requisitos del sistema para Exchange 2016.
Requisitos de almacenamiento
En general, no existen requisitos especiales de almacenamiento específicos para DAG o copias de
bases de datos de buzones. Los DAG no requieren ni usan almacenamiento compartido
administrado por clúster. El almacenamiento compartido administrado por clúster solo se admite en
un DAG cuando el DAG está configurado para usar una solución que aprovecha la API de
replicación de terceros integrada en Exchange 2016.
Requisitos de Software
Cada miembro de un DAG debe ejecutar el mismo sistema operativo. Exchange 2016 es compatible
con los sistemas operativos Windows Server 2008 R2, Windows Server 2012 y Windows Server 2012
R2. Dentro de un DAG específico, todos los miembros deben estar ejecutando el mismo sistema
operativo compatible.
Además de cumplir con los requisitos previos para la instalación de Exchange 2016, existen
requisitos del sistema operativo que deben cumplirse. Los DAG utilizan la tecnología Windows
Failover Clustering y, como resultado, requieren la versión Enterprise o Datacenter de Windows
Server 2008 R2, o la versión Standard o Datacenter de los sistemas operativos Windows Server 2012
o Windows Server 2012 R2.
Requisitos de red
Existen requisitos específicos de red que deben cumplirse para cada DAG y para cada miembro del
DAG. Cada DAG debe tener una única red MAPI , que es utilizada por un miembro de DAG para
comunicarse con otros servidores (por ejemplo, otros servidores de Exchange 2016 o servidores de
directorio) y cero o más redes de replicación , que son redes dedicadas al envío y la siembra de
registros .
En versiones anteriores de Exchange, recomendamos al menos dos redes (una red MAPI y una red
de Replicación) para DAG. En Exchange 2016, se admiten varias redes, pero nuestra recomendación
depende de la topología de su red física. Si tiene varias redes físicas entre miembros de DAG que
están físicamente separadas una de la otra, el uso de una red de replicación y MAPI independiente
proporciona redundancia adicional. Si tiene varias redes que están parcialmente separadas
físicamente pero convergen en una única red física (por ejemplo, un único enlace WAN), se
recomienda usar una única red (preferiblemente Ethernet de 10 gigabits) para el tráfico MAPI y
Replicación. Esto proporciona simplicidad para la red y la ruta de la red.
Considere lo siguiente al diseñar la infraestructura de red para su DAG:
 Cada miembro del DAG debe tener al menos un adaptador de red que pueda comunicarse
con todos los demás miembros del DAG. Si está utilizando una sola ruta de red, le
recomendamos que utilice un mínimo de 1 gigabit Ethernet, pero preferiblemente 10
gigabit Ethernet. Además, al usar un único adaptador de red en cada miembro de DAG,
recomendamos que diseñe la solución general teniendo en cuenta el adaptador de red y la
ruta.
 El uso de dos adaptadores de red en cada miembro de DAG le proporciona una red MAPI y
una red de replicación, con redundancia para la red de replicación y los siguientes
comportamientos de recuperación:
o En el caso de una falla que afecte a la red MAPI, se producirá una conmutación por
error del servidor (suponiendo que haya copias de base de datos de buzones de
correo saludables que se puedan activar).
o En el caso de una falla que afecte a la red de replicación, si la red MAPI no se ve
afectada por la falla, las operaciones de envío y siembra de registros volverán a
utilizar la red MAPI, incluso si la red MAPI tiene
su propiedad ReplicationEnabled establecida en False. Cuando la red de Replicación
fallida se restablece y está lista para reanudar las operaciones de envío y
segmentación de registros, debe cambiar manualmente a la red de
Replicación. Para cambiar la replicación de la red MAPI a una red de Replicación
restaurada, puede suspender y reanudar la replicación continua
utilizando Suspend-MailboxDatabaseCopy y Resume-
MailboxDatabaseCopycmdlets o reinicie el servicio de replicación de Microsoft
Exchange. Recomendamos utilizar las operaciones de suspender y reanudar para
evitar la breve interrupción causada por el reinicio del servicio de replicación de
Microsoft Exchange.
 Cada miembro del DAG debe tener el mismo número de redes. Por ejemplo, si planea usar
un solo adaptador de red en un miembro de DAG, todos los miembros del DAG también
deben usar un único adaptador de red.
 Cada DAG no debe tener más de una red MAPI. La red MAPI debe proporcionar
conectividad a otros servidores de Exchange y a otros servicios, como Active Directory y
DNS.
 Se pueden agregar redes de Replicación adicionales, según sea necesario. También puede
evitar que un adaptador de red individual sea un único punto de falla mediante el uso de
equipos de adaptadores de red o una tecnología similar. Sin embargo, incluso cuando se
utiliza el trabajo en equipo, esto no impide que la red sea un punto único de falla. Además,
el trabajo en equipo agrega complejidad innecesaria al DAG.
 Cada red en cada servidor miembro de DAG debe estar en su propia subred de red. Cada
servidor en el DAG puede estar en una subred diferente, pero las redes MAPI y Replicación
deben ser enrutables y proporcionar conectividad, de modo que:
o Cada red en cada servidor miembro de DAG está en su propia subred de red que
está separada de la subred utilizada por cada otra red en el servidor.
o La red MAPI de cada servidor miembro DAG puede comunicarse entre sí con la red
MAPI del miembro DAG.
o La red de replicación de cada servidor miembro DAG puede comunicarse entre sí
con la red de replicación del miembro DAG.
o No hay un enrutamiento directo que permita el tráfico de latidos de la red de
replicación en un servidor miembro de DAG a la red MAPI en otro servidor
miembro de DAG, o viceversa, o entre múltiples redes de replicación en el DAG.
 Independientemente de su ubicación geográfica en relación con otros miembros del DAG,
cada miembro del DAG debe tener una latencia de red de ida y vuelta no superior a 500
milisegundos entre cada miembro. A medida que aumenta la latencia de ida y vuelta entre
dos servidores de buzón que alojan copias de una base de datos, también aumenta el
potencial de replicación no actualizada. Independientemente de la latencia de la solución,
los clientes deben validar que las redes entre todos los miembros del DAG son capaces de
satisfacer los objetivos de protección y disponibilidad de datos de la implementación. Las
configuraciones con valores de latencia más altos pueden requerir ajustes especiales de
DAG, replicación y parámetros de red, como aumentar el número de bases de datos o
disminuir el número de buzones de correo por base de datos, para lograr los objetivos
deseados.
 Los requisitos de latencia de ida y vuelta pueden no ser los requisitos más estrictos de
ancho de banda y latencia de la red para una configuración de centro de datos
múltiple. Debe evaluar la carga total de la red, que incluye acceso de cliente, Active
Directory, transporte, replicación continua y otro tráfico de aplicaciones, para determinar los
requisitos de red necesarios para su entorno.
 Las redes DAG son compatibles con el protocolo de Internet versión 4 (IPv4) e IPv6. IPv6
solo es compatible cuando también se usa IPv4; un entorno de IPv6 puro no es
compatible. El uso de direcciones IPv6 y rangos de direcciones IP solo se admite cuando
tanto IPv6 como IPv4 están habilitados en esa computadora, y la red admite ambas
versiones de la dirección IP. Si Exchange 2016 se implementa en esta configuración, todas
las funciones del servidor pueden enviar y recibir datos de dispositivos, servidores y clientes
que usan direcciones IPv6.
 El direccionamiento IP privado automático (APIPA) es una característica de Windows que
asigna automáticamente direcciones IP cuando no hay un servidor de protocolo de
configuración dinámica de host (DHCP) disponible en la red. Las direcciones APIPA
(incluidas las direcciones asignadas manualmente desde el rango de direcciones APIPA) no
son compatibles con el uso de DAG ni de Exchange 2016.
DAG nombre y requisitos de la dirección IP
Durante la creación, a cada DAG se le asigna un nombre único, y se le asigna una o más direcciones
IP estáticas, o se configura para usar DHCP. Independientemente de si usa direcciones estáticas o
dinámicamente asignadas, cualquier dirección IP asignada al DAG debe estar en la red MAPI.
Cada DAG que se ejecuta en Windows Server 2008 R2 o Windows Server 2012 requiere un mínimo
de una dirección IP en la red MAPI. Un DAG requiere direcciones IP adicionales cuando la red MAPI
se extiende a través de múltiples subredes. Los DAG que se ejecutan en Windows Server 2012 R2
que se crean sin un punto de acceso administrativo de clúster no requieren una dirección IP.
La siguiente figura ilustra un DAG donde todos los nodos en el DAG tienen la red MAPI en la misma
subred.
DAG con red MAPI en la misma subred
En este ejemplo, la red MAPI en cada miembro del DAG está en el 172.19.18. x subred. Como
resultado, el DAG requiere una sola dirección IP en esa subred.
La siguiente figura ilustra un DAG que tiene una red MAPI que se extiende a través de dos subredes:
172.19.18. x y 172.19.19. x .
DAG con red MAPI en múltiples subredes
En este ejemplo, la red MAPI en cada miembro del DAG está en una subred separada. Como
resultado, el DAG requiere dos direcciones IP, una para cada subred en la red MAPI.
Cada vez que la red MAPI del DAG se extiende a través de una subred adicional, se debe configurar
una dirección IP adicional para esa subred para el DAG. Cada dirección IP configurada para el DAG
se asigna y utiliza por el clúster de conmutación por error subyacente del DAG. El nombre del DAG
también se usa como el nombre del clúster de conmutación por error subyacente.
En cualquier momento específico, el clúster del DAG usará solo una de las direcciones IP
asignadas. El clúster de conmutación por error de Windows registra esta dirección IP en DNS
cuando los recursos de la dirección IP del clúster y del nombre de la red se ponen en línea. Además
de utilizar una dirección IP y un nombre de red, se crea un objeto de nombre de clúster (CNO) en
Active Directory. El nombre, la dirección IP y CNO para el clúster son utilizados internamente por el
sistema para asegurar el DAG y para fines de comunicación interna. Los administradores y usuarios
finales no necesitan conectarse o conectarse con el nombre o la dirección IP del DAG.
Nota:
Aunque el sistema usa internamente la dirección IP y el nombre de la red del clúster, no existe una
dependencia fuerte en Exchange 2016 de que estos recursos estén disponibles. Incluso si el punto
de acceso administrativo del clúster subyacente (por ejemplo, su dirección IP y recursos de
Nombre de red) está fuera de línea, la comunicación interna aún se produce dentro del DAG
utilizando los nombres del servidor miembro del DAG. Sin embargo, le recomendamos que
controle periódicamente la disponibilidad de estos recursos para asegurarse de que no estén
desconectados durante más de 30 días. Si el clúster subyacente está fuera de línea durante más de
30 días, la cuenta CNO del clúster puede ser invalidada por el mecanismo de recolección de basura
en Active Directory.
Configuración del adaptador de red para DAG

Cada adaptador de red debe configurarse correctamente en función del uso previsto. Un adaptador
de red que se utiliza para una red MAPI se configura de forma diferente a un adaptador de red que
se usa para una red de replicación. Además de configurar cada adaptador de red correctamente,
también debe configurar el orden de conexión de red en Windows para que la red MAPI se
encuentre en la parte superior del orden de conexión. Para conocer los pasos detallados sobre
cómo modificar el orden de conexión de la red, consulte Modificar los enlaces de protocolo y el
orden del proveedor de red .
Configuración del adaptador de red MAPI
Un adaptador de red diseñado para ser utilizado por una red MAPI se debe configurar como se
describe en la siguiente tabla.
Funciones de red Configuraciones
Cliente para redes Microsoft Habilitado
agendador de paquetes de QoS Opcionalmente

habilitado
Uso compartido de archivos e impresoras para redes Microsoft Habilitado
Protocolo de Internet versión 6 (TCP / IP v6) Habilitado
Controlador de E / S de Topology Discovery Mapper de la capa Habilitado

de enlace
Respondedor de descubrimiento de topología de capa de enlace Habilitado

Las propiedades de TCP / IP v4 para un adaptador de red MAPI se configuran de la siguiente
manera:
 La dirección IP de la red MAPI de un miembro del DAG se puede asignar o configurar
manualmente para usar DHCP. Si se usa DHCP, recomendamos usar reservas persistentes
para la dirección IP del servidor.
 La red MAPI generalmente usa una puerta de enlace predeterminada, aunque no se
requiere una.
 Se debe configurar al menos una dirección de servidor DNS. Se recomienda el uso de
múltiples servidores DNS para la redundancia.
 Se debe seleccionar la casilla Registrar las direcciones de esta conexión en el DNS .
Configuración del adaptador de red de replicación
Un adaptador de red diseñado para su uso por una red de Replicación debe configurarse como se
describe en la siguiente tabla.
Funciones de red Configuraciones
Cliente para redes Microsoft Discapacitado
agendador de paquetes de QoS Opcionalmente

habilitado
Uso compartido de archivos e impresoras para redes Microsoft Discapacitado
Controlador de E / S de Topology Discovery Mapper de la capa Habilitado

de enlace
Respondedor de descubrimiento de topología de capa de enlace Habilitado

Las propiedades de TCP / IP v4 para un adaptador de red de replicación se configuran de la
siguiente manera:
 La dirección IP de la red de replicación de un miembro de DAG se puede asignar o
configurar manualmente para usar DHCP. Si se usa DHCP, recomendamos usar reservas
persistentes para la dirección IP del servidor.
 Las redes de replicación generalmente no tienen puertas de enlace predeterminadas, y si la
red MAPI tiene una puerta de enlace predeterminada, ninguna otra red debería tener
puertas de enlace predeterminadas. El enrutamiento del tráfico de red en una red de
Replicación se puede configurar mediante rutas persistentes y estáticas a la red
correspondiente en otros miembros de DAG que usan direcciones de puerta de enlace que
tienen la capacidad de enrutar entre las redes de Duplicación. El resto del tráfico que no
coincida con esta ruta será manejado por la puerta de enlace predeterminada configurada
en el adaptador para la red MAPI.
 Las direcciones del servidor DNS no deben configurarse.
 Las direcciones de conexiones en DNS Registro casilla de verificación no deben ser
seleccionados.
Requisitos del servidor testigo

Un servidor testigo es un servidor externo a un DAG que se utiliza para lograr y mantener el quórum
cuando el DAG tiene un número par de miembros. Los DAG con un número impar de miembros no
usan un servidor testigo. Todos los DAG con un número par de miembros deben usar un servidor
testigo. El servidor testigo puede ser cualquier computadora que ejecute Windows Server. No es
necesario que la versión del sistema operativo Windows Server del servidor testigo coincida con el
sistema operativo utilizado por los miembros del DAG.
El quórum se mantiene en el nivel del clúster, debajo del DAG. Un DAG tiene quórum cuando la
mayoría de sus miembros están en línea y pueden comunicarse con los otros miembros en línea del
DAG. Esta noción de quórum es un aspecto del concepto de quórum en el clúster de conmutación
por error de Windows. Un aspecto relacionado y necesario para el quórum en los clústeres de
conmutación por error es el recurso de quórum . El recurso de quórum es un recurso dentro de un
clúster de conmutación por error que proporciona un medio para el arbitraje que conduce al estado
del clúster y las decisiones de membresía. El recurso de quórum también proporciona
almacenamiento persistente para almacenar información de configuración. Un compañero del
recurso de quórum es el registro de quórum, que es una base de datos de configuración para el
clúster. El registro de quórum contiene información tal como qué servidores son miembros del
clúster, qué recursos están instalados en el clúster y el estado de esos recursos (por ejemplo, en
línea o fuera de línea).
Es fundamental que cada miembro de DAG tenga una visión coherente de cómo se configura el
clúster subyacente del DAG. El quórum actúa como el repositorio definitivo para toda la información
de configuración relacionada con el clúster. El quórum también se usa como un desempate para
evitar el síndrome del cerebro dividido . El síndrome del cerebro dividido es una afección que ocurre
cuando los miembros del DAG no se pueden comunicar entre ellos pero se están ejecutando. El
síndrome del cerebro dividido se evita requiriendo siempre que la mayoría de los miembros del
DAG (y en el caso de los DAG con un número par de miembros, el servidor testigo del DAG) estén
disponibles e interactúen para que el DAG esté operativo.
Planificación para la resistencia del sitio

Cada día, más empresas reconocen que el acceso a un sistema de mensajería confiable y disponible
es fundamental para su éxito. Para muchas organizaciones, el sistema de mensajería es parte de los
planes de continuidad del negocio, y su implementación de servicio de mensajería está diseñada
teniendo en cuenta la capacidad de recuperación del sitio. Fundamentalmente, muchas soluciones
resilientes del sitio implican la implementación de hardware en un segundo centro de datos.
En última instancia, el diseño general de un DAG, que incluye el número de miembros del DAG y el
número de copias de la base de datos del buzón, dependerá de los acuerdos de nivel de servicio de
recuperación (SLA) de cada organización que cubran varios escenarios de falla. Durante la etapa de
planificación, los arquitectos y administradores de la solución identifican los requisitos para la
implementación, incluidos, en particular, los requisitos para la resistencia del sitio. Identifican las
ubicaciones que se utilizarán y los objetivos de SLA de recuperación requeridos. El SLA identificará
dos elementos específicos que deberían ser la base para el diseño de una solución que proporcione
alta disponibilidad y resistencia del sitio: el objetivo del tiempo de recuperación y el objetivo del
punto de recuperación. Ambos valores se miden en minutos. El objetivo del tiempo de recuperación
es cuánto tiempo lleva restablecer el servicio. El objetivo del punto de recuperación se refiere a qué
tan actual es la información una vez que se ha completado la operación de recuperación. También
se puede definir un SLA para restaurar el centro de datos primario al servicio completo después de
que se corrijan sus problemas.
Los arquitectos y administradores de la solución también identificarán qué conjunto de usuarios
requieren protección de resistencia del sitio y determinarán si la solución de múltiples sitios será
una configuración activa / pasiva o activa / activa. En una configuración activa / pasiva,
normalmente no hay usuarios alojados en el centro de datos en espera. En una configuración activa
/ activa, los usuarios se alojan en ambas ubicaciones, y un porcentaje del número total de bases de
datos dentro de la solución tiene una ubicación activa preferida en un segundo centro de
datos. Cuando falla el servicio para los usuarios de un centro de datos, esos usuarios se activan en el
otro centro de datos.
La construcción de los SLA apropiados a menudo requiere responder las siguientes preguntas
básicas:
 ¿Qué nivel de servicio se requiere después de que falla el centro de datos principal?
 ¿Los usuarios necesitan sus datos o solo los servicios de mensajería?
 ¿Qué tan rápido se requieren los datos?
 ¿Cuántos usuarios deben ser compatibles?
 ¿Cómo accederán los usuarios a sus datos?
 ¿Qué es el SLA de activación del centro de datos en espera?
 ¿Cómo se traslada el servicio al centro de datos primario?
 ¿Los recursos están dedicados a la solución de resiliencia del sitio?
Al responder estas preguntas, comienza a dar forma a un diseño resistente para su solución de
mensajería. Un requisito fundamental para la recuperación de una falla del sitio es crear una
solución que obtenga los datos necesarios para el centro de datos de respaldo que aloja el servicio
de mensajes de respaldo.
Planificación de certificados
No existen consideraciones de diseño únicas o especiales para los certificados cuando se
implementa un DAG en un solo centro de datos. Sin embargo, al extender un DAG a través de
múltiples centros de datos en una configuración resiliente de sitio, existen algunas consideraciones
específicas con respecto a los certificados. En general, el diseño de su certificado dependerá de los
clientes en uso, así como de los requisitos del certificado de otras aplicaciones que usen
certificados. Pero hay algunas recomendaciones específicas y mejores prácticas que debe seguir con
respecto al tipo y número de certificados.
Como práctica recomendada, debe minimizar el número de certificados que utiliza para sus
servidores de Exchange y servidores proxy inversos. Recomendamos usar un solo certificado para
todos estos puntos finales de servicio en cada centro de datos. Este enfoque minimiza la cantidad
de certificados que se necesitan, lo que reduce tanto el costo como la complejidad de la solución.
Para los clientes de Outlook en cualquier lugar, recomendamos que use un certificado de nombre
alternativo único (SAN) para cada centro de datos, e incluya varios nombres de host en el
certificado. Para garantizar la conectividad de Outlook en cualquier lugar después de una base de
datos, servidor o centro de datos, debe usar el mismo nombre principal de certificado en cada
certificado y configurar el objeto de configuración de proveedor de Outlook en Active Directory con
el mismo nombre principal en Microsoft-Standard Form (msstd) . Por ejemplo, si usa un nombre
principal de certificado de mail.contoso.com, debe configurar el atributo de la siguiente manera.
Set-OutlookProvider EXPR -CertPrincipalName "msstd:mail.contoso.com"
Algunas aplicaciones que se integran con Exchange tienen requisitos de certificado específicos que
pueden requerir el uso de certificados adicionales. Exchange 2016 puede coexistir con Office
Communications Server (OCS). OCS requiere certificados con certificados de 1024 bits o superiores
que usen el nombre del servidor OCS para el Nombre principal del certificado. Debido a que el uso
de un nombre de servidor OCS para el Nombre principal del certificado evitaría que Outlook
Anywhere funcione correctamente, necesitaría usar un certificado adicional y separado para el
entorno OCS.
Planificación de red
Además de los requisitos específicos de red que deben cumplirse para cada DAG, así como para
cada servidor que es miembro de un DAG, existen algunos requisitos y recomendaciones que son
específicos de las configuraciones de resistencia del sitio. Al igual que con todos los DAG, ya sea
que los miembros del DAG estén implementados en un único sitio o en varios sitios, la latencia de la
red de retorno de ida y vuelta entre los miembros del DAG no debe superar los 500
milisegundos. Además, hay configuraciones de configuración específicas que se recomiendan para
los DAG que se extienden a través de múltiples sitios:
 Las redes MAPI deben estar aisladas de las redes de replicación. Las políticas de red
de Windows, las políticas de firewall de Windows o las listas de control de acceso del
enrutador (ACL) se deben usar para bloquear el tráfico entre la red MAPI y las redes de
replicación. Esta configuración es necesaria para evitar el diálogo cruzado de latidos en la
red.
 Los registros DNS orientados al cliente deben tener un valor Time to Live (TTL) de 5
minutos. La cantidad de tiempo de inactividad que experimentan los clientes depende no
solo de cuán rápido puede ocurrir una conmutación, sino también de cuán rápido se
produce la replicación DNS y los clientes consultan información actualizada de DNS. Los
registros DNS para todos los servicios cliente de Exchange, incluida Microsoft Office
Outlook Web App, Microsoft Exchange ActiveSync, servicios web de Exchange, Outlook
Anywhere, SMTP, POP3 e IMAP4 en los servidores DNS internos y externos se deben
configurar con un TTL de 5 minutos.
 Utilice rutas estáticas para configurar la conectividad en las redes de replicación Para
proporcionar conectividad de red entre cada uno de los adaptadores de red de replicación,
use rutas estáticas persistentes. Esta es una configuración rápida y única que se realiza en
cada miembro del DAG cuando se usan direcciones IP estáticas. Si usa DHCP para obtener
direcciones IP para sus redes de Replicación, también puede usarlo para asignar rutas
estáticas para la replicación, simplificando así el proceso de configuración.
Planificación general de resiliencia del sitio
Además de los requisitos enumerados anteriormente para la alta disponibilidad, existen otras
recomendaciones para implementar Exchange 2016 en una configuración flexible para el sitio (por
ejemplo, extendiendo un DAG a través de múltiples centros de datos). Lo que haga durante la fase
de planificación afectará directamente el éxito de la solución de resiliencia de su sitio. Por ejemplo,
un diseño de espacio de nombres deficiente puede causar dificultades con los certificados, y una
configuración de certificado incorrecta puede impedir que los usuarios accedan a los servicios.
Para minimizar el tiempo que lleva activar un segundo centro de datos y permitir que el segundo
centro de datos aloje los puntos finales del servicio de un centro de datos con errores, se debe
completar la planificación adecuada. Los siguientes son ejemplos:
 Los objetivos de SLA para la solución de resiliencia del sitio deben ser bien entendidos y
documentados.
 Los servidores en el segundo centro de datos deben tener capacidad suficiente para alojar
la población de usuarios combinados de ambos centros de datos.
 El segundo centro de datos debe tener todos los servicios habilitados que se proporcionan
en el centro de datos principal (a menos que el servicio no esté incluido como parte del SLA
de resistencia del sitio). Esto incluye Active Directory, infraestructura de red (por ejemplo,
DNS o TCP / IP), servicios de telefonía (si la mensajería unificada está en uso) e
infraestructura del sitio (como alimentación o refrigeración).
 Para que algunos servicios puedan dar servicio a los usuarios del centro de datos fallado,
deben tener los certificados de servidor adecuados configurados. Algunos servicios no
permiten la creación de instancias (por ejemplo, POP3 e IMAP4) y solo permiten el uso de
un solo certificado. En estos casos, el certificado debe ser un certificado SAN que incluya
varios nombres o los nombres múltiples deben ser lo suficientemente similares para que se
pueda usar un certificado comodín (suponiendo que las políticas de seguridad de la
organización permitan el uso de certificados comodín).
 Los servicios necesarios deben definirse en el segundo centro de datos. Por ejemplo, si el
primer centro de datos tiene tres URL SMTP diferentes en diferentes servidores de
transporte, se debe definir la configuración adecuada en el segundo centro de datos para
habilitar al menos un servidor de transporte (si no los tres) para alojar la carga de trabajo.
 La configuración de red necesaria debe estar en su lugar para admitir el cambio de centro
de datos. Esto puede significar asegurarse de que las configuraciones de equilibrio de carga
estén en su lugar, que el DNS global esté configurado y que la conexión a Internet esté
habilitada con el enrutamiento adecuado configurado.
 Debe entenderse la estrategia para habilitar los cambios de DNS necesarios para un cambio
de centro de datos. Los cambios específicos de DNS, incluida su configuración TTL, se
deben definir y documentar para que sean compatibles con el SLA vigente.
 Una estrategia para probar la solución también debe establecerse y tenerse en cuenta en el
SLA. La validación periódica de la implementación es la única forma de garantizar que la
calidad y la viabilidad de la implementación no se degraden con el tiempo. Después de
validar la implementación, recomendamos que la parte de la configuración que afecta
directamente el éxito de la solución se documente explícitamente. Además, recomendamos
que mejore sus procesos de gestión de cambios en torno a esos segmentos de la
implementación.
Implementación de alta
sitios
Intercambio 2016
Otras versiones

Resumen: cómo implementar Exchange Server 2016 con alta disponibilidad y resistencia del sitio.
Microsoft Exchange Server 2016 utiliza el concepto conocido como implementación
incremental para alta disponibilidad y resistencia del sitio. Simplemente instala dos o más servidores
de buzones de correo Exchange 2016 como servidores independientes y luego los configura de
forma incremental y bases de datos de buzones para una alta disponibilidad y resistencia del sitio,
según sea necesario.
Descripción general del proceso de implementación

Si bien los pasos reales utilizados por cada organización pueden variar ligeramente, el proceso
general para implementar Exchange 2016 en una configuración altamente disponible o resiliente en
el sitio es generalmente el mismo. Después de realizar las tareas de planificación y diseño necesarias
para crear y desplegar un grupo de disponibilidad de base de datos (DAG) y crear copias de bases
de datos de buzones, usted:
1. Crea un DAG. Para conocer los pasos detallados, consulte Crear un grupo de disponibilidad
de base de datos . Es importante tener en cuenta que todos los servidores dentro de un
DAG deben ejecutar la misma versión de Exchange. No puede mezclar los servidores de
Exchange 2013 y Exchange 2016 en el mismo DAG.
2. Si es necesario, prepare previamente el objeto del nombre del clúster (CNO). Se requiere
preinstalar el CNO al implementar un DAG con servidores de buzones que ejecutan
Windows Server 2012. Si está implementando un DAG sin un punto de acceso
administrativo usando servidores de buzones que ejecutan Windows Server 2012 R2,
entonces no es necesario preparar previamente un CNO . La etapa previa también se
requiere en entornos donde la creación de cuentas de computadora está restringida o
donde las cuentas de computadora se crean en un contenedor que no sea el contenedor de
computadoras predeterminado. Para conocer los pasos detallados,
consulte Preconfiguración del objeto de nombre de clúster para un grupo de disponibilidad
de base de datos .
3. Add two or more Mailbox servers to the DAG. For detailed steps, see Administración de la
pertenencia a grupos de disponibilidad de base de datos.
4. Configure las propiedades DAG según sea necesario:
a. Optionally configure DAG encryption and compression, replication port, DAG IP
addresses, and other DAG properties. For detailed steps, see Configurar las
propiedades del grupo de disponibilidad de base de datos.
b. Habilite el modo de coordinación de activación del centro de datos (DAC) para el
DAG. Esto protege al DAG de las condiciones cerebrales divididas a nivel de base de
datos durante la conmutación al centro de datos primario después de que se haya
realizado una conmutación del centro de datos, y permite el uso de los cmdlets de
recuperación de DAG incorporados. Para más información, ver Modo de
coordinación de activación de centro de datos .
5. Add mailbox database copies across Mailbox servers in the DAG. For detailed steps,
see Adición de una copia de base de datos de buzones.
Implementación de ejemplo: DAG de cuatro miembros
en dos centros de datos
Este ejemplo detalla cómo una organización, Contoso, Ltd., está configurando e implementando un
DAG de cuatro miembros que se extenderá a través de dos ubicaciones físicas: Boston y Oklahoma
City.
Base infrastructure
Cada ubicación contiene los elementos de infraestructura que son necesarios para operar una
infraestructura de mensajería basada en Exchange 2016, a saber:
 Servicios de directorio (Active Directory o Servicios de dominio de Active Directory (AD DS))
 Resolución de nombre del Sistema de nombres de dominio (DNS)
 Múltiples servidores de Exchange 2016 que ejecutan servicios de acceso de cliente
 Múltiples servidores de buzones de Exchange 2016
La siguiente figura ilustra la configuración de Contoso.
Configuración de la red
Como se ilustra en la figura anterior, la solución implica el uso de múltiples subredes y redes
múltiples. Cada servidor de buzón en el DAG tiene dos adaptadores de red en subredes
separadas. En cada servidor de buzones, un adaptador de red se utiliza para la red MAPI
(192.168. X . X ) y un adaptador de red se utiliza para la red de replicación (10.0. X . X ). Solo la red
MAPI brinda conectividad a Active Directory, servicios DNS y otros servidores y clientes de
Exchange. El adaptador utilizado para la red de Replicación en cada miembro proporciona
conectividad solo a los adaptadores de red de Replicación en los otros miembros del DAG.
La configuración para cada adaptador de red en cada nodo se detalla en la siguiente tabla.
Dirección Máscara de Puerta de enlace

Nombre
IPv4 subred predeterminada
MBX1 (MAPI) 192.168.1.4 255.255.255.0 192.168.1.1
MBX2 (MAPI) 192.168.1.5 255.255.255.0 192.168.1.1
MBX3 (MAPI) 192.168.2.4 255.255.255.0 192.168.2.1
MBX4 (MAPI) 192.168.2.5 255.255.255.0 192.168.2.1
MBX1 10.0.1.4 255.255.0.0 Ninguna

(Replicación)
MBX2 10.0.1.5 255.255.0.0 Ninguna

(Replicación)
MBX3 10.0.2.4 255.255.0.0 Ninguna

(Replicación)
MBX4 10.0.2.5 255.255.0.0 Ninguna

(Replicación)
Como se muestra en la tabla anterior, los adaptadores utilizados para las redes de Replicación no
usan puertas de enlace predeterminadas. Para proporcionar conectividad de red entre cada uno de
los adaptadores de red de Replicación, Contoso usa rutas estáticas persistentes, que configuran
mediante la herramienta Netsh.exe.
Para configurar el enrutamiento para los adaptadores de red de replicación en MBX1 y MBX2, se
ejecutó el siguiente comando en cada servidor.
interfaz netsh ipv4 agregar la ruta 10.0.2.0/24 <NetworkName> 10.0.1.254
Para configurar el enrutamiento para los adaptadores de red de replicación en MBX3 y MBX4, se
ejecutó el siguiente comando en cada servidor.
interfaz netsh ipv4 agregar la ruta 10.0.1.0/24 <NetworkName> 10.0.2.254
La siguiente configuración de red adicional también se ha configurado:
 La casilla Registrar las direcciones de esta conexión en DNS se selecciona para el
adaptador de red MAPI de cada miembro del DAG y se borra para cada adaptador de red
de Replicación.
 Al menos una dirección de servidor DNS está configurada para cada adaptador de red MAPI
del miembro DAG, y ninguna está configurada para los adaptadores de red de
Replicación. Para la redundancia, Contoso está usando múltiples direcciones de servidor
DNS para sus adaptadores de red MAPI.
 Contoso no usa el Firewall de Windows y lo ha desactivado en sus servidores.
Después de configurar los adaptadores de red, Contoso está listo para crear un DAG y agregar los
servidores de buzones al DAG.
Creación y configuración de grupo de disponibilidad de base de datos
El administrador ha decidido crear un script de interfaz de línea de comandos de Windows
PowerShell que realiza varias tareas:
 Utiliza el cmdlet New-DatabaseAvailabilityGroup para crear el DAG. Debido a que BOSTON
se considera el centro de datos principal, Contoso ha elegido usar un servidor testigo en el
mismo centro de datos, es decir, MBX5.
 Utiliza el cmdlet Set-DatabaseAvailabilityGroup para preconfigurar un servidor de testigo
alternativo y un directorio de testigo alternativo en caso de que alguna vez se necesite un
cambio de centro de datos.
 Utiliza el cmdlet Add-DatabaseAvailabilityGroupServer para agregar cada uno de los cuatro
servidores de buzones al DAG.
 It uses the Set-DatabaseAvailabilityGroup cmdlet to configure the DAG for DAC mode. For
more information about DAC mode, see Modo de coordinación de activación de centro de
datos.
Los siguientes son los comandos usados en el script:
New-DatabaseAvailabilityGroup -Name DAG1 -WitnessServer MBX5 -
WitnessDirectory C:\DAGWitness\DAG1.contoso.com -
DatabaseAvailabilityGroupIPAddresses 192.168.1.8,192.168.2.8
El comando anterior crea el DAG DAG1, configura MBX5 para que actúe como el servidor testigo,
configura un directorio testigo específico (C: \ DAGWitness \ DAG1.contoso.com) y configura dos
direcciones IP para el DAG (una para cada subred en el Red MAPI).
Set-DatabaseAvailabilityGroup -Identity DAG1 -AlternateWitnessDirectory
C:\DAGWitness\DAG1.contoso.com -AlternateWitnessServer MBX10
El comando anterior configura DAG1 para usar un servidor testigo alternativo de MBX10 y un
directorio testigo alternativo en MBX10 que usa la misma ruta que se configuró en MBX5.
Nota:
No es necesario usar la misma ruta; Contoso ha elegido hacer esto para estandarizar su
configuración.
Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer MBX1

Los comandos anteriores agregan cada uno de los servidores de buzones, uno a la vez, al DAG. Los
comandos también instalan el componente Windows Failover Clustering en cada servidor de
buzones de correo (si aún no está instalado), crean un clúster de conmutación por error y unen cada
servidor de buzones al clúster recién creado.
Set-DatabaseAvailabilityGroup -Identity DAG1 -DatacenterActivationMode
DagOnly
El comando anterior habilita el modo DAC para el DAG.
Copias de bases de datos de buzones y bases de datos
Después de crear el DAG y agregar los servidores de buzones al DAG, Contoso se prepara para crear
bases de datos de buzones y copias de bases de datos de buzones. Para cumplir con sus criterios de
resistencia a fallas, Contoso planea configurar cada base de datos de buzones con tres copias de
bases de datos no rezagadas y una copia de base de datos rezagada. La copia rezagada tendrá un
retraso de reproducción de registro configurado de tres días.
Esta configuración proporciona un total de cuatro copias para cada base de datos (una activa, dos
pasivas no retardadas y una pasiva retrasada). Contoso planea tener cuatro bases de datos activas
por servidor. Por lo tanto, la solución Contoso contiene 16 copias de bases de datos totales.
Como se muestra en la siguiente figura, Contoso está adoptando un enfoque equilibrado para el
diseño de su base de datos.
Diseño de copia de la base de datos para Contoso, Ltd
Cada servidor de buzones de correo alberga una copia de base de datos de buzones de correo
activa, dos copias de bases de datos pasivas no rezagadas y una copia de base de datos pasiva
rezagada. La copia rezagada de cada base de datos de buzón de correo activa se aloja en un
servidor de buzón en el otro sitio.
Para crear esta configuración, el administrador ejecuta varios comandos.
En MBX1, ejecute los siguientes comandos.
Add-MailboxDatabaseCopy -Identity DB1 -MailboxServer MBX2
Add-MailboxDatabaseCopy -Identity DB1 -MailboxServer MBX3 -ReplayLagTime
3.00: 00: 00 -SeedingPostponed
Suspend-MailboxDatabaseCopy -Identity DB1 \ MBX3 -SuspendComment "Seed
from MBX4" -Confirm: $ False
Update-MailboxDatabaseCopy -Identity DB1 \ MBX3 -SourceServer MBX4
Suspend-MailboxDatabaseCopy -Identity DB1 \ MBX3 -ActivationOnly
En los ejemplos anteriores para el cmdlet Add-MailboxDatabaseCopy ,
el parámetro ActivationPreference no se ha especificado. La tarea aumenta automáticamente el
número de preferencia de activación con cada copia que se agrega. La base de datos original
siempre tiene un número de preferencia de 1. La primera copia agregada con Add-
MailboxDatabaseCopyAl cmdlet se le asigna automáticamente un número de preferencia de 2.
Suponiendo que no se eliminen las copias, a la siguiente copia agregada se le asigna
automáticamente un número de preferencia de 3, y así sucesivamente. Por lo tanto, en los ejemplos
anteriores, la copia pasiva en el mismo centro de datos que la copia activa tiene un número de
preferencia de activación de 2; la copia pasiva no retrasada en el centro de datos remoto tiene un
número de preferencia de activación de 3, y la copia pasiva rezagada en el centro de datos remoto
tiene un número de preferencia de activación de 4.
Aunque hay dos copias de cada base de datos activa en la WAN en la otra ubicación, la siembra
sobre la WAN solo se realizó una vez. Esto se debe a que Contoso está aprovechando la capacidad
de Exchange 2016 de utilizar una copia pasiva de una base de datos como fuente para la creación
de semillas. El uso del cmdlet Add-MailboxDatabaseCopy con el parámetro SeedingPostponed evita
que la tarea se propague automáticamente a la nueva copia de la base de datos que se está
creando. Luego, el administrador puede suspender la copia no sembrada y usar el cmdlet Update-
MailboxDatabaseCopy con SourceServerparámetro, el administrador puede especificar la copia local
de la base de datos como fuente de la operación de inicialización. Como resultado, el inicio de la
segunda copia de la base de datos agregada a cada ubicación ocurre localmente y no a través de la
WAN.
Nota:
En el ejemplo anterior, la copia de la base de datos no rezagada se deriva a través de la WAN, y
esa copia se usa para inicializar la copia retrasada de la base de datos que está en el mismo centro
de datos que la copia no rezagada.
Contoso ha configurado una de las copias pasivas de cada base de datos de buzones como una
copia de base de datos rezagada para brindar protección contra el caso extremadamente raro pero
catastrófico de corrupción lógica de la base de datos. Como resultado, el administrador está
configurando las copias rezagadas como bloqueadas para la activación mediante el uso
del cmdlet Suspend-MailboxDatabaseCopy con el parámetro ActivationOnly . Esto garantiza que las
copias de base de datos retrasadas no se activarán si se produce una conmutación por error de
base de datos o servidor.
Validar la solución
Una vez implementada y configurada la solución, el administrador realiza varias tareas que validan
la preparación de la solución antes de mover los buzones de producción a las bases de datos en el
DAG. La solución debe probarse e inspeccionarse utilizando varios métodos, incluidas las
simulaciones de fallas. Para validar la solución, el administrador realiza varias tareas.
Para verificar el estado general del DAG, el administrador ejecuta el cmdlet Test-
ReplicationHealth . Este cmdlet comprueba varios aspectos de la replicación y el estado de la
reproducción para proporcionar información sobre cada servidor de buzón y copia de la base de
datos en el DAG.
Para verificar la actividad de replicación y reproducción, el administrador ejecuta el cmdlet Get-
MailboxDatabaseCopyStatus . Este cmdlet puede proporcionar información de estado en tiempo
real sobre una copia de base de datos de buzón específica o para todas las copias de bases de
datos de buzones en un servidor específico. Para obtener más información sobre cómo supervisar el
estado y el estado de las bases de datos replicadas en un DAG, consulte Supervisión de grupos de
disponibilidad de base de datos .
Para verificar que los cambios funcionen como se espera, el administrador usa el cmdlet Move-
ActiveMailboxDatabase para realizar una serie de cambios de bases de datos y cambios de
servidor. Cuando estas tareas se han completado con éxito, el administrador usa el mismo cmdlet
para mover las copias de la base de datos activa a sus ubicaciones originales.
Para verificar los comportamientos esperados en varios escenarios de falla, el administrador realiza
varias tareas que simulan fallas o que realmente causan fallas. Por ejemplo, el administrador puede:
 Desenchufe el cable de alimentación en MBX1, desencadenando así una conmutación por
error del servidor. El administrador luego verifica que el DB1 se active en otro servidor
(preferiblemente MBX2, en función de los valores de preferencia de activación).
 Desconecte el cable de red para el adaptador de red MAPI en MBX2, desencadenando así
una conmutación por error del servidor. El administrador verifica que DB2 se active en otro
servidor (preferiblemente MBX1, según los valores de preferencia de activación).
 Tome el disco utilizado por la copia activa de DB3 fuera de línea, desencadenando así una
conmutación por error de la base de datos. El administrador luego verifica que DB3 se
active en otro servidor (preferiblemente MBX4, según los valores de preferencia de
activación).
Puede haber otros escenarios de falla que sean probados por una organización, en función de las
necesidades del negocio. Después de simular una sola falla (como desconectar el cable de
alimentación) y verificar el comportamiento de recuperación de la solución, el administrador puede
revertir la solución a su configuración original. En algunos casos, la solución puede probarse para
múltiples fallas concurrentes. En última instancia, su plan de prueba de solución determinará si la
solución se revierte a su configuración original después de que se completó cada simulación de
falla.
Además, un administrador puede decidir desconectar la conexión de red entre los dos centros de
datos, simulando así una falla en el sitio. Realizar un cambio de centro de datos es un proceso
mucho más complicado y coordinado; sin embargo, recomendamos el proceso si la solución que se
está implementando tiene la intención de proporcionar resistencia del sitio para los servicios y datos
de mensajería.
Transición a operaciones
Una vez implementada la solución, puede extenderse aún más utilizando la implementación
incremental. En este punto, la administración de la solución también pasaría a procesos de
operación, en los cuales se realizarían las siguientes tareas:
 Monitor the health and status of DAGs and mailbox database copies. For more information,
see Supervisión de grupos de disponibilidad de base de datos.
 Perform database switchovers as needed. For detailed steps about how to perform a
database switchover, see Activación de una copia de base de datos de buzones.
dministración de alta
sitios
Exchange 2016
Otras versiones
Resumen: Las tareas operativas de administrar DAG, copias de bases de datos de buzones de
correo y otros elementos de alta disponibilidad de Exchange 2016.
Tras construir, validar e implementar una solución de alta disponibilidad y resistencia de sitios de
Microsoft Exchange Server 2016, la solución pasa de la fase de implementación a la fase operativa
dentro del ciclo de vida general de la misma. La fase operativa consta de varias tareas, todas ellas
relacionadas con una de las áreas siguientes: grupos de disponibilidad de base de datos (DAG),
copias de bases de datos de buzones, supervisión proactiva de rendimiento y administración de
conmutación y conmutación por error.
Contenido
Administración del grupo de disponibilidad de base de datos
Administración de copias de base de datos de buzones de correo
Supervisión proactiva
Cambios y conmutaciones por error
Administración del grupo de disponibilidad de base de

datos
Las tareas de administración operativa asociadas a los grupos de disponibilidad de base de datos
incluyen:
 Creación de uno o más grupos de disponibilidad de base de datos La creación de un
grupo de disponibilidad de base de datos suele ser un procedimiento que se realiza una vez
durante la fase de implementación del ciclo de vida de la solución. Sin embargo, durante la
fase operativa puede haber muchos motivos para crear grupos de disponibilidad de base
de datos (DAG), por ejemplo:
o El DAG está configurado para el modo de replicación de otros fabricantes y desea
volver a usar la replicación continua. No se puede cambiar un DAG para la
replicación continua; es necesario crear un grupo nuevo.
o Tiene servidores en varios dominios. Todos los miembros de un DAG deben ser
también miembros del mismo dominio.
 Administración de la pertenencia a un grupo de disponibilidad de base de
datos Administrar miembros de un grupo de disponibilidad de base de datos (DAG) es
una tarea que se realiza en raras ocasiones durante la fase de implementación del ciclo de
vida de la solución. Sin embargo, debido a la flexibilidad que aporta la implementación
incremental, también se puede administrar la pertenencia a grupos de disponibilidad de
base de datos a lo largo del ciclo de vida de la solución.
 Configuración de las propiedades de un grupo de disponibilidad de base de
datos Cada grupo de disponibilidad de base de datos (DAG) dispone de varias
propiedades que pueden configurarse según sea necesario. Entre estas propiedades se
incluyen:
o Servidor testigo y directorio testigo El servidor testigo es un servidor externo al
grupo de disponibilidad de base de datos (DAG) que actúa como votante de
quórum cuando un DAG contiene un número par de miembros. El directorio testigo
es un directorio creado y compartido en el servidor testigo que usa el sistema para
mantener un quórum.
o Direcciones IP Cada grupo de disponibilidad de base de datos dispone de una o
más direcciones IPv4 y, opcionalmente, de una o más direcciones IPv6. Las
direcciones IP asignadas al DAG las usa el clúster subyacente del DAG. El número
de direcciones IPv4 asignadas al DAG es igual al número de subredes que
componen la red MAPI que usa el DAG. Puede configurar el DAG para que use
direcciones IP estáticas, o bien obtener direcciones de forma automática mediante
el Protocolo de configuración dinámica de host (DHCP).
o Modo de coordinación de activación de centros de datos El modo de
coordinación de activación de centros de datos es una configuración de propiedad
en un DAG que está diseñada para prevenir la falta de comunicación entre los
nodos de un clúster en el nivel de la base de datos, en un escenario en el que se
restaura un servicio a un centro de datos principal después de realizar un cambio
de centro de datos. Para obtener más información acerca del modo de
coordinación de activación de centros de datos, consulte Modo de coordinación de
activación de centro de datos.
o Servidor testigo alternativo y directorio testigo alternativo El servidor testigo
alternativo y el directorio testigo alternativo son valores que se pueden
preconfigurar como parte del proceso de planeación para un cambio de centros de
datos. Se refieren al servidor testigo y al directorio testigo que se usarán cuando se
realiza un cambio de centro de datos.
o Puerto de replicación De forma predeterminada, todos los grupos de
disponibilidad de base de datos usan el puerto TCP 64327 para la replicación
continua. Puede modificar el grupo de disponibilidad de base de datos para que
use otro puerto TCP para la replicación mediante el parámetro ReplicationPort del
cmdlet Set-DatabaseAvailabilityGroup.
o Detección de redes Puede forzar a un grupo de disponibilidad para que detecte
redes e interfaces de red. Esta operación se usa cuando se agregan o quitan redes,
o cuando se introducen nuevas subredes. Se puede forzar que se vuelvan a detectar
las redes de DAG mediante el parámetro DiscoverNetworks del cmdlet Set-
DatabaseAvailabilityGroup.
o Compresión de red De forma predeterminada, los grupos de disponibilidad de
base de datos usan compresión solamente entre redes DAG de diferentes subredes.
Puede habilitar la compresión de todas las redes DAG o solo para operaciones de
propagación, o bien puede deshabilitar la compresión de todas las redes DAG.
o Cifrado de red De forma predeterminada, los grupos de disponibilidad de base
de datos usan cifrado solamente entre redes DAG de diferentes subredes. Puede
habilitar el cifrado de todas las redes DAG o solo para operaciones de propagación,
o bien puede deshabilitar el cifrado de todas las redes DAG.
 Apagado de miembros de grupos de disponibilidad de base de datos La solución de
alta disponibilidad de Exchange 2016 está integrada en el proceso de apagado de
Windows. Si un administrador o una aplicación inician el apagado de un servidor Windows
en un DAG con una base de datos montada que se replica en uno o más miembros del
DAG, el sistema intentará activar otra copia de las bases de datos montada antes de
permitir que se complete el proceso de apagado. Sin embargo, este nuevo comportamiento
no garantiza que todas las bases de datos del servidor que se va a apagar experimenten
una activación sin pérdida. Por lo tanto, es mejor realizar una conmutación de servidor
antes de apagar un servidor miembro de un grupo de disponibilidad de base de datos.
Para obtener instrucciones detalladas acerca de cómo crear un grupo de disponibilidad de base de
datos, consulte Crear un grupo de disponibilidad de base de datos. Para obtener instrucciones
detalladas sobre cómo configurar DAG y las propiedades de un DAG, consulte Configurar las
propiedades del grupo de disponibilidad de base de datos. Para obtener más información acerca de
cada una de las tareas anteriores, y sobre la administración de grupos de disponibilidad de base de
datos en general, consulte Administrar grupos de disponibilidad de base de datos.
Administración de copias de base de datos de buzones

de correo
Las tareas de administración operativa asociadas con las copias de base de datos de buzones
incluyen:
 Agregar copias de bases de datos de buzones Cuando agrega una copia a la base de
datos de buzones, se habilita automáticamente la replicación continua entre la base de
datos existente y la copia de la base de datos.
 Configurar las propiedades de la copia de base de datos de buzones Puede configurar
diferentes propiedades como, por ejemplo, la directiva de activación de base de datos, el
periodo de retardo de reproducción y truncamiento (si lo hubiera) y la preferencia de
activación para la copia de base de datos.
 Suspender o reanudar una copia de base de datos de buzones Puede suspender una
copia de base de datos de buzones que se esté preparando para la propagación, o para
otro tipo de tarea de mantenimiento. También puede suspender una copia de base de
datos de buzones solo para activación. Esta configuración evita que el sistema active
automáticamente la copia como resultado de un error, pero permite que el sistema
mantenga actualizada la copia de la base de datos con respecto al envío y la reproducción
de registros.
 Actualizar una copia de base de datos de buzones La actualización, también
denominada propagación, es el proceso en el que se agrega una base de datos de buzones
a otro servidor de buzones. Se convierte en la base de datos de línea de base para la copia.
Tras la propagación inicial de la línea de base de la copia de base de datos, no será
necesario volver a propagar la base de datos, salvo raras excepciones.
 Activar una copia de base de datos de buzones La activación de una copia de base de
datos de buzones consiste en designar una determinada copia pasiva como la nueva copia
activa de una base de datos de buzones. Se hace referencia a este proceso
como conmutación. Para obtener más información, consulte "Conmutaciones y
conmutaciones por error" más adelante en este tema.
 Quitar una copia de base de datos de buzones de correo En ocasiones, puede que sea
necesario quitar una copia de una base de datos de buzones de correo. Por ejemplo, no
puede quitar un servidor de buzones de un DAG hasta que se eliminen del servidor todas
las copias de bases de datos de buzones. Además, tiene que quitar todas las copias de una
base de datos de buzones de correo antes de cambiar la ruta de una base de datos de
buzones.
Para obtener más información sobre cómo agregar una copia de base de datos de buzones,
consulte Adición de una copia de base de datos de buzones. Para obtener instrucciones detalladas
acerca de cómo configurar copias de bases de datos de buzones, consulte Configuración de las
propiedades de una copia de base de datos de buzones. Para obtener más información acerca de
cada una de las tareas anteriores, y sobre la administración de copias de bases de datos de buzones
en general, consulte Administración de copias de bases de datos de buzones de correo. Para
obtener más información sobre cómo quitar una copia de base de datos de buzones,
consulte Eliminación de una copia de base de datos de buzones.
Supervisión proactiva
Asegurarse de que los servidores funcionan de forma confiable y que las copias de base de datos
están en buen estado son los objetivos clave para las operaciones diarias de mensajería. Exchange
2016 incluye una serie de características que se pueden usar para realizar diferentes tareas de
supervisión de mantenimiento en grupos de disponibilidad de base de datos y copias de bases de
datos de buzones, incluidas las siguientes:
 Get-MailboxDatabaseCopyStatus
 Test-ReplicationHealth
 Registro de eventos de canal Crimson
Además de supervisar el mantenimiento y el estado, también es importante supervisar las
situaciones que pueden poner en peligro la disponibilidad. Por ejemplo, se recomienda que
supervise la redundancia de las bases de datos replicadas. Esto es fundamental para evitar
situaciones en las que solamente dispone de una copia de una base de datos. Este escenario debe
tratarse con la máxima prioridad y resolverse lo antes posible.
Para obtener información detallada acerca de cómo supervisar el estado y el mantenimiento de
grupos de disponibilidad de base de datos y copias de bases de datos de buzones,
consulte Supervisión de grupos de disponibilidad de base de datos.
Cambios y conmutaciones por error

Una conmutación es un proceso manual en el que un administrador activa una o más copias de una
base de datos de buzones. Estas conmutaciones, que se pueden producir en la base de datos o en
el servidor, suelen realizarse como parte de la preparación de actividades de mantenimiento. La
administración de las conmutaciones implica realizar conmutaciones en bases de datos y servidores,
según sea necesario. Por ejemplo, si necesita realizar el mantenimiento en un servidor de buzones
de un grupo de disponibilidad de base de datos, primero haría una conmutación de servidor para
que el servidor no hospede ninguna copia de base de datos activa. Para obtener instrucciones
detalladas acerca de cómo realizar un cambio de base de datos, consulte Activación de una copia
de base de datos de buzones. Los cambios se pueden realizar en los centros de datos.
Una conmutación por error es la activación automática por parte del sistema de una o más copias de
base de datos en respuesta a un error. Por ejemplo, la pérdida de una unidad de disco en un
entorno sin RAID desencadenará un error de la base de datos. La pérdida de la red MAPI o una
conmutación por error de energía desencadenarán una conmutación por error de servidor.
Administración del grupo de disponibilidad de base de dato
************************Copia de
seguridad, restauración y
recuperación ante desastres
Intercambio 2016
Resumen: una descripción general de las características de Exchange que puede usar para proteger
sus datos.
La planificación de protección de datos es un proceso complejo que depende de muchas decisiones
que usted toma durante la fase de planificación de su implementación. Como parte de su
planificación, es importante que comprenda las formas en que se pueden proteger los datos y
determinar qué método se adapta mejor a las necesidades de su organización.
Tradicionalmente, las copias de seguridad se han utilizado para los siguientes escenarios:
 Recuperación ante desastres En el caso de una falla de hardware o software, las copias
de bases de datos múltiples en un DAG permiten una alta disponibilidad con failover rápido
y poca o ninguna pérdida de datos. Esto elimina el tiempo de inactividad y la productividad
perdida resultante, que es un costo significativo de recuperación de una copia de seguridad
en un disco o cinta en el pasado. Los DAG se pueden extender a múltiples sitios y pueden
brindar resistencia contra fallas de discos, servidores, redes y centros de datos.
 Recuperación de elementos eliminados accidentalmente Históricamente, en una
situación en la que un usuario eliminaba elementos que luego se tenían que recuperar,
implicaba encontrar los medios de copia de seguridad en los que se almacenaban los datos
que se necesitaban recuperar y obtener de algún modo los elementos deseados y
proporcionarlos para el usuario. Con la nueva carpeta Elementos recuperables en Exchange
2016 y la Política de retención que se puede aplicar a ella, es posible conservar todos los
datos eliminados y modificados durante un período de tiempo específico, por lo que la
recuperación de estos elementos es más fácil y más rápida. Esto reduce la carga en los
administradores de Exchange y en el departamento de ayuda de TI al permitir que los
usuarios finales recuperen los elementos eliminados accidentalmente ellos mismos,
reduciendo así la complejidad y los costos administrativos asociados con la recuperación de
un solo elemento. Para más información, verDirectiva de mensajería y conformidad en
Exchange 2016 and Prevención de pérdida de datos en Exchange 2016.
 Almacenamiento de datos a largo plazo Las copias de seguridad también se han
utilizado como archivo y, por lo general, la cinta se usa para preservar instantáneas de datos
puntuales durante periodos de tiempo prolongados, tal como se rige por los requisitos de
conformidad. Las nuevas características de archivado, búsqueda de buzón múltiple y
retención de mensajes en Exchange 2016 proporcionan un mecanismo para preservar de
manera eficiente los datos de una manera accesible para el usuario final durante períodos
prolongados. Esto elimina costosas restauraciones de la cinta y aumenta la
productividad. Para obtener más información, consulte Archivado local en Exchange
2016 , Exhibición de documentos electrónicos locales en Exchange 2016 y Conservación
local y retención por juicio en Exchange 2016 .
 Instantánea de la base de datos de punto en el tiempo Si una copia pasada de un
punto en el tiempo de los datos del buzón es un requisito para su organización, Exchange
ofrece la posibilidad de crear una copia de base de datos rezagada en un entorno de
DAG. Esto puede ser útil en el raro caso de que la corrupción lógica de la tienda se replique
en varias copias de bases de datos en el DAG, lo que da como resultado la necesidad de
volver a un punto anterior en el tiempo. También puede ser útil si un administrador elimina
accidentalmente buzones o datos de usuario. La recuperación de una copia rezagada puede
ser más rápida que la restauración desde una copia de seguridad porque las copias
rezagadas no requieren un proceso de copia que consume mucho tiempo desde el servidor
de respaldo al servidor de Exchange. Esto puede reducir significativamente el costo total de
propiedad al reducir el tiempo de inactividad.
Debido a que hay características nativas de Exchange 2016 que cumplen con cada uno de estos
escenarios de una manera eficiente y rentable, es posible que pueda reducir o eliminar el uso de
copias de seguridad tradicionales en su entorno.
Protección de datos nativos de Exchange
Tecnologías de respaldo compatibles
Escritor de VSS de Exchange 2013
Recuperación de Exchange Server
Unified Contact Store Recovery
Base de datos
Portabilidad de base de datos
Dial Tone Portability

Arquitectura preferida de Microsoftpara Exchange Server 2016 aprovecha un concepto conocido
como Protección de datos nativa de Exchange. Exchange Native Data Protection se basa en las
características integradas de Exchange para proteger los datos de su buzón de correo, sin el uso de
copias de seguridad (aunque aún puede usar esas características y realizar copias de
seguridad). Exchange 2016 incluye varias características que, cuando se implementan y configuran
correctamente, pueden proporcionar protección de datos nativa que elimina la necesidad de
realizar copias de seguridad tradicionales de sus datos. El uso de las funciones de alta disponibilidad
integradas en Exchange 2016 para minimizar el tiempo de inactividad y la pérdida de datos en caso
de desastre también puede reducir el costo total de propiedad del sistema de mensajería. Al
combinar estas funciones con otras funciones incorporadas, como la retención legal, puede reducir
o eliminar el uso de copias de seguridad tradicionales puntuales y reducir los costos asociados.
Además de determinar si Exchange 2016 le permite alejarse de las copias de seguridad tradicionales
puntuales, le recomendamos que evalúe el costo de su infraestructura de respaldo actual. Considere
el costo del tiempo de inactividad del usuario final y la pérdida de datos al intentar recuperarse de
un desastre utilizando su infraestructura de respaldo existente. Además, incluya los costos de
hardware, instalación y licencia, así como los costos de administración asociados con la
recuperación de datos y el mantenimiento de las copias de seguridad. Dependiendo de los
requisitos de su organización, es bastante probable que un entorno puro de Exchange 2016 con al
menos tres copias de bases de datos de buzones proporcione un menor costo total de propiedad
que uno con copias de seguridad.
Hay varias cuestiones que debe tener en cuenta antes de utilizar las funciones incorporadas en
Exchange 2016 como reemplazo de las copias de seguridad tradicionales. También puede haber
consideraciones únicas para su organización. Considere los siguientes problemas y tenga en cuenta
que esta no es una lista exhaustiva:
 Debe determinar cuántas copias de la base de datos se deben
implementar. Recomendamos encarecidamente implementar un mínimo de tres copias (sin
retraso) de una base de datos de buzones antes de eliminar las formas tradicionales de
protección para la base de datos, como la matriz redundante de discos independientes
(RAID) o las copias de seguridad tradicionales basadas en VSS.
 Debe definir claramente el objetivo del tiempo de recuperación y los objetivos objetivos del
punto de recuperación, y debe establecerlo utilizando un conjunto combinado de
características integradas en lugar de copias de seguridad tradicionales para permitirle
cumplir con estos objetivos.
 Debe determinar cuántas copias de cada base de datos se necesitan para cubrir los diversos
escenarios de fallas contra los cuales su sistema está diseñado para proteger.
 Debe determinar si la eliminación del uso de un DAG o de algunos de sus miembros
captura los costos suficientes para respaldar una solución de copia de seguridad
tradicional. De ser así, debe determinar si esa solución mejora su objetivo de tiempo de
recuperación o los acuerdos de nivel de servicio objetivo (SLA) de punto de recuperación.
 Debe determinar si puede permitirse perder una copia puntual en caso de que el miembro
del DAG que aloja la copia experimente una falla que afecte la copia o la integridad de la
copia.
 Exchange 2016 le permite implementar buzones de correo mucho más grandes, con un
tamaño de base de datos máximo recomendado de 2 terabytes (cuando se utilizan dos o
más copias de bases de datos de buzones de correo altamente disponibles). Según los
buzones de correo más grandes que la mayoría de las organizaciones puedan implementar,
debe determinar su objetivo de punto de recuperación si debe volver a reproducir una gran
cantidad de archivos de registro al activar una copia de base de datos o una copia de base
de datos rezagada.
 Debe determinar cómo detectará y evitará que la corrupción lógica en una copia de base de
datos activa se replique en las copias pasivas de la base de datos. Esto incluye determinar el
plan de recuperación para esta situación y con qué frecuencia ha ocurrido este escenario en
el pasado. Si la corrupción lógica ocurre con frecuencia en su organización, le
recomendamos que factorice ese escenario en su diseño mediante el uso de una o más
copias retrasadas, con una ventana de repetición suficiente para permitirle detectar y actuar
ante la corrupción lógica cuando ocurra, pero antes de eso la corrupción se replica en otras
copias de bases de datos.
Una de las funciones que se realizan al final de una copia de seguridad completa o incremental
exitosa es el truncamiento de los archivos de registro de transacciones que ya no son necesarios
para la recuperación de la base de datos. Si no se realizan copias de seguridad, no se realizará el
truncamiento del registro. Para evitar la acumulación de archivos de registro, habilite el registro
circular para sus bases de datos replicadas. Cuando combina el registro circular con la replicación
continua, tiene un nuevo tipo de registro circular denominado registro circular de replicación
continua (CRCL), que es diferente del registro circular de Motor de almacenamiento extensible
(ESE). Mientras que el registro circular ESE es realizado y administrado por el servicio Almacén de
información de Microsoft Exchange, el servicio de replicación de Microsoft Exchange realiza y
administra CRCL. Cuando está habilitado, el registro circular de ESE no t genera archivos de registro
adicionales y, en su lugar, sobrescribe el archivo de registro actual cuando sea necesario. Sin
embargo, en un entorno de replicación continua, los archivos de registro son necesarios para el
envío y la reproducción de registros. Como resultado, cuando habilita CRCL, el archivo de registro
actual no se sobrescribe y se generan archivos de registro cerrados para el proceso de envío y
reproducción del registro.
Específicamente, el servicio de replicación de Microsoft Exchange administra CRCL para que la
continuidad del registro se mantenga y los registros no se eliminen si aún se necesitan para la
replicación. El servicio de replicación de Microsoft Exchange y el servicio de almacén de información
de Microsoft Exchange se comunican mediante llamadas a procedimientos remotos (RPC) con
respecto a qué archivos de registro se pueden eliminar.
Para que se produzca el truncamiento en copias de bases de datos de buzones de correo altamente
disponibles (sin retraso), debe cumplirse lo siguiente:
 El archivo de registro se ha copiado o CRCL está habilitado.
 El archivo de registro está debajo del punto de control.
 Las otras copias de la base de datos no retenidas están de acuerdo con la eliminación.
 El archivo de registro ha sido inspeccionado por todas las copias rezagadas de la base de
datos.
Para que se produzca el truncamiento en las copias de bases de datos rezagadas, debe cumplirse lo
siguiente:
 El archivo de registro está debajo del punto de control.
 El archivo de registro es anterior a ReplayLagTime + TruncationLagTime.
 El archivo de registro se elimina en la copia activa de la base de datos.
Tecnologías de respaldo compatibles

Exchange 2016 solo admite copias de seguridad basadas en VSS y basadas en Exchange. Exchange
2016 incluye un complemento para Windows Server Backup que le permite realizar y restaurar
copias de seguridad basadas en VSS de datos de Exchange. Para hacer una copia de seguridad y
restaurar Exchange 2016, debe usar una aplicación compatible con Exchange que admita el escritor
de VSS para Exchange 2016, como Windows Server Backup (con el complemento VSS), Microsoft
System Center 2012 - Data Protection Manager, o un aplicación basada en VSS basada en Exchange
de terceros.
For detailed steps about how to back up and restore Exchange data using Windows Server Backup,
see Uso de copias de seguridad de Windows Server para realizar copias de seguridad y restaurar
datos de Exchange.
Exchange VSS Writer

Las versiones anteriores de Exchange incluían dos escritores de VSS: uno dentro del servicio
Almacén de información de Microsoft Exchange (store.exe) y otro dentro del servicio de replicación
de Microsoft Exchange (msexchangerepl.exe). De regreso en Exchange 2013, la funcionalidad del
escritor de VSS que anteriormente se encontraba en el servicio Almacén de información de
Microsoft Exchange se movió al servicio de replicación de Microsoft Exchange. Esta arquitectura
sigue siendo la misma en Exchange 2016. Las aplicaciones basadas en VSS compatibles con
Exchange utilizan este escritor, denominado Microsoft Exchange Writer, para realizar copias de
seguridad de copias de bases de datos activas y pasivas, y para restaurar copias de seguridad de
bases de datos. Aunque el escritor se ejecuta en el servicio de replicación de Microsoft Exchange,
requiere que se ejecute el servicio Almacén de información de Microsoft Exchange para que se
publique el escritor. Como resultado,
Recuperación de Exchange Server

Casi todas las configuraciones de los servidores de buzones y los servicios de acceso de clientes se
almacenan en Active Directory. Al igual que las versiones anteriores de Exchange, Exchange 2016
incluye un parámetro de configuración para recuperar servidores perdidos. Este parámetro, / m:
RecoverServer , se utiliza para reconstruir y volver a crear un servidor perdido mediante la
configuración y la información de configuración almacenada en Active Directory. Sin embargo,
tenga en cuenta que hay varios ajustes que no se restauran, como cambios en el archivo web.config
local y otros archivos de configuración. Además, las entradas de registro personalizadas no se
restauran. Recomendamos que utilice un proceso confiable de administración de cambios para
rastrear y recrear estos cambios.
Para conocer los pasos detallados sobre cómo realizar una recuperación de servidor de un servidor
de Exchange 2016 perdido, vea Recuperar un servidor de Exchange . Para conocer los pasos
detallados sobre cómo recuperar un servidor perdido que es miembro de un grupo de
disponibilidad de base de datos (DAG), vea Recuperar un servidor miembro de un grupo de
disponibilidad de base de datos .
Unified Contact Store Recovery

Cuando se usa Microsoft Lync Server 2013 o Skype Empresarial Server 2015 en un entorno de
Exchange 2016, la información de contacto de Lync / Skype Empresarial del usuario se almacena en
una carpeta de contactos especiales en el buzón del usuario. Esto se conoce como el almacén de
contacto unificado (UCS). Si restaura un buzón migrado UCS, la lista de contactos de mensajería
instantánea para el usuario de destino puede verse afectada. Si el usuario se migró después de la
última copia de seguridad, al restaurar el buzón se perderá por completo la lista de contactos del
usuario. En casos menos graves, las modificaciones a la lista de contactos realizadas por el usuario
desde la última copia de seguridad se perderán. Para mitigar esta posible pérdida de datos,
asegúrese de que el usuario vuelva a migrar al servidor de mensajería instantánea antes de restaurar
el buzón.
Base de datos
Una base de datos de recuperación es un tipo especial de base de datos de buzones que le permite
montar una base de datos de buzones restaurada y extraer datos de la base de datos restaurada
como parte de una operación de recuperación. Puede usar el cmdlet New-
MailboxRestoreRequest para extraer datos de una base de datos de recuperación. Después de la
extracción, los datos se pueden exportar a una carpeta o fusionarse en un buzón existente. Las
bases de datos de recuperación le permiten recuperar datos de una copia de seguridad o copia de
una base de datos sin alterar el acceso de los usuarios a los datos actuales.
No se admite el uso de una base de datos de recuperación para una base de datos de buzón de
ninguna versión anterior de Exchange. Además, el buzón de destino utilizado para las fusiones y
extracción de datos debe estar en el mismo bosque de Active Directory que la base de datos
montada en la base de datos de recuperación.
For more information, see Bases de datos de recuperación. For detailed steps about how to create a
recovery database, see Creación de una base de datos de recuperación. For detailed steps about
how to use a recovery database, see Restauración de datos mediante una base de datos de
recuperación.
Portabilidad de base de datos

La portabilidad de la base de datos es una función que permite que una base de datos de buzones
de Exchange 2016 se mueva y se monte en cualquier otro servidor de buzones de Exchange 2016 en
la misma organización. Al utilizar la portabilidad de la base de datos, la confiabilidad se mejora al
eliminar varios pasos manuales propensos a errores de los procesos de recuperación. Además, la
portabilidad de la base de datos reduce los tiempos de recuperación generales para varios
escenarios de falla.
For more information, see Portabilidad de bases de datos. For detailed steps to use database
portability, see Mover una base de datos de buzones mediante la portabilidad de bases de datos.
Dial Tone Portability

La portabilidad del tono de marcado es una función que proporciona una solución de continuidad
comercial limitada para fallas que afectan una base de datos de buzones, un servidor o un sitio
completo. La portabilidad del tono de marcado permite que un usuario tenga un buzón de correo
temporal para enviar y recibir correo electrónico mientras se restaura o repara el buzón original. El
buzón temporal puede estar en el mismo servidor de buzones de Exchange 2016 o en cualquier
otro servidor de buzones de Exchange 2016 en su organización. Esto permite que un servidor
alternativo aloje los buzones de los usuarios que estaban anteriormente en un servidor que ya no
está disponible. Los clientes que admiten Autodiscover, como Microsoft Outlook, se redirigen
automáticamente al nuevo servidor sin tener que actualizar manualmente el perfil de escritorio del
usuario. Después de que se restauraron los datos originales del buzón del usuario, un administrador
puede fusionar un usuario '
El proceso para utilizar la portabilidad de tono de marcado se llama recuperación de tono de
marcado . Una recuperación de tono de marcado implica crear una base de datos vacía en un
servidor de buzón para reemplazar una base de datos fallida. Esta base de datos vacía,
denominada base de datos de tonos de marcado , permite a los usuarios enviar y recibir correos
electrónicos mientras se recupera la base de datos fallida. Después de que se recupera la base de
datos fallida, la base de datos de marcado y la base de datos recuperada se intercambian, y luego
los datos de la base de datos de tono de marcado se combinan en la base de datos recuperada.
For more information, see Portabilidad del tono de marcado. For detailed steps to perform a dial
tone recovery, see Realizar una recuperación del tono de marcado.

Alta Disponibilidad y Resistencia de Sitios

Transféré par

Informations du document

Description originale:

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Alta Disponibilidad y Resistencia de Sitios

Transféré par

Droits d'auteur :

Formats disponibles

Alta disponibilidad y

Grupos de disponibilidad de base de datos

Copias de bases de datos de buzones de correo

API de replicación de terceros

Documentación de alta disponibilidad y resistencia de

Se aplica a:Exchange Server 2016

Ciclo de vida del grupo de disponibilidad de base de

Los DAG se crean con el cmdlet New-DatabaseAvailabilityGroup. Inicialmente se crean como

Se aplica a:Exchange Server 2016

Configuración del adaptador de red para DAG

Funciones de red Configuraciones

Cliente para redes Microsoft Habilitado

agendador de paquetes de QoS Opcionalmente

Uso compartido de archivos e impresoras para redes Microsoft Habilitado

Protocolo de Internet versión 6 (TCP / IP v6) Habilitado

Protocolo de Internet versión 4 (TCP / IP v4) Habilitado

Controlador de E / S de Topology Discovery Mapper de la capa Habilitado

Respondedor de descubrimiento de topología de capa de enlace Habilitado

Funciones de red Configuraciones

Cliente para redes Microsoft Discapacitado

agendador de paquetes de QoS Opcionalmente

Uso compartido de archivos e impresoras para redes Microsoft Discapacitado

Protocolo de Internet versión 6 (TCP / IP v6) Habilitado

Protocolo de Internet versión 4 (TCP / IP v4) Habilitado

Controlador de E / S de Topology Discovery Mapper de la capa Habilitado

Respondedor de descubrimiento de topología de capa de enlace Habilitado

Requisitos del servidor testigo

Planificación para la resistencia del sitio

Se aplica a:Exchange Server 2016

Descripción general del proceso de implementación

Dirección Máscara de Puerta de enlace

MBX1 (MAPI) 192.168.1.4 255.255.255.0 192.168.1.1

MBX2 (MAPI) 192.168.1.5 255.255.255.0 192.168.1.1

MBX3 (MAPI) 192.168.2.4 255.255.255.0 192.168.2.1

MBX4 (MAPI) 192.168.2.5 255.255.255.0 192.168.2.1

MBX1 10.0.1.4 255.255.0.0 Ninguna

MBX2 10.0.1.5 255.255.0.0 Ninguna

MBX3 10.0.2.4 255.255.0.0 Ninguna

MBX4 10.0.2.5 255.255.0.0 Ninguna

Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer MBX1

Administración del grupo de disponibilidad de base de

Administración de copias de base de datos de buzones

Cambios y conmutaciones por error

Protección de datos nativos de Exchange

Tecnologías de respaldo compatibles

Exchange VSS Writer

Recuperación de Exchange Server

Unified Contact Store Recovery

Portabilidad de base de datos

Dial Tone Portability

Vous aimerez peut-être aussi