Escolar Documentos
Profissional Documentos
Cultura Documentos
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.
Resistencia de sitios
Configuración que amplía la infraestructura de mensajería a varios sitios de Active Directory
para proporcionar una continuidad operativa al sistema de mensajería en el caso de que un
error afecte a alguno de los sitios.
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
Resistencia de sitios
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
Grupos de disponibilidad de
base de datos (DAG)
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].
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.
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.
Planificación de alta
disponibilidad y resistencia de
sitios
Intercambio 2016
Otras versiones
[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].
Requerimientos generales
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.
Requerimientos generales
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.
Requerimientos generales
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.
Requerimientos generales
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.
Requerimientos generales
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.
Implementación de alta
disponibilidad y resistencia de
sitios
Intercambio 2016
Otras versiones
[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].
Nota:
No es necesario usar la misma ruta; Contoso ha elegido hacer esto para estandarizar su
configuración.
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
disponibilidad y resistencia de
sitios
Exchange 2016
Otras versiones
[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: 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
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.
Administración del grupo de disponibilidad de base de datos
************************Copia de
seguridad, restauración y
recuperación ante desastres
Intercambio 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: 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
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.
Protección de datos nativos de Exchange