Gua de cambio de centro de

datos

PASE A SITIO DE CONTINGENCIA EXCHANGE SERVER 2013

PREPARADO PARA:
PROFUTURO AFP

PREPARADO POR:
FED YUNIS ZAPATA
TECHNICAL SOLUTION SPECIALIST

CONTRIBUIDORES:

MARVIN ORTEGA SILVA

FECHA:
VERSIN: 2.0

HOJA DE REVISIN

REGISTRO DE CAMBIOS
Fecha

Autor

Versin

Referencia de
cambios
Elaboracin de
documento
Resolucin de
problemas conocidos

06/11/2015

Fed Yunis Zapata

1.0

06/15/2015

Fed Yunis Zapata

2.0

Posicin

Fecha

Fed Yunis Zapata

Versin
Aprobada
1.0

06/11/2015

Fed Yunis Zapata

2.0

Technical Solution
Specialist
Technical Solution
Specialist

REVISORES
Nombre

06/15/2015

Client Name: Profuturo AFP | Publish Date Gua de cambio de centro de datos | Confidential SoftwareONE

1. INTRODUCCIN
Este documento tiene como finalidad mostrar la estrategia y el paso a paso a seguir para
realizar un pase a contingencia al servicio de correo MS Exchange Server 2013.
Exchange 2013 Terminologa:
Se deben conocer los siguientes trminos para tener un panorama claro de las
actividades que se estn realizando, en base a cada ambiente:

Primary Active Manager (PAM), se ejecuta en el interior del servicio de

replicacin de Microsoft Exchange para notificar y reaccionar en caso de fallo del
servidor. PAM posee el recurso de qurum de clster y mantiene la informacin
sobre bases de datos activas, pasivas y montadas.

Standby Active Manager (SAM), proporciona informacin del servidor que

aloja la copia activa de una base de datos de buzones a los servicios de acceso
de cliente o de transporte.

Datacenter Activation Coordination (DAC), utiliza un protocolo llamado

Datacenter Activation Coordination Protocol (DACP) para evitar el sndrome Split
Brain. Cuando un DAG se ejecuta en modo DAC, cuando se reinicia el servidor, el
Active Manager pone en marcha el bit como 0 (estado Desmontar base de datos).
Se comunica con otros miembros del DAG y cuando uno responder el bit cambia a
1 y permite montar la base de datos.

En una configuracin de alta disponibilidad con sitio de contingencia, la recuperacin

automtica en respuesta a un fallo a nivel de sitio puede ocurrir dentro de un DAG,
permitiendo que el sistema de mensajera para permanecer en un estado funcional. Esta
configuracin requiere al menos tres lugares, ya que requiere el despliegue de miembros
del DAG en dos ubicaciones y servidor testigo del DAG en una tercera ubicacin.
Si usted no tiene tres lugares, o incluso si usted tiene tres lugares, pero desea controlar
las acciones de recuperacin a nivel de centro de datos, puede configurar un DAG para
la recuperacin manual en el caso de un fallo a nivel de sitio. En ese caso, usted
realizara un proceso llamado una conmutacin de centros de datos (Switchover
Datacenter).
Al igual que con muchos escenarios de recuperacin de desastres, la planificacin previa
y la preparacin para una conmutacin de centros de datos puede simplificar su proceso
de recuperacin y reducir la duracin de la interrupcin.

2. CONMUTACIN DE CENTRO DE DATOS (SWITCHOVER DATACENTER)

Para realizar una conmutacin de centro datos, se deben los siguientes pasos luego de
apagar los servidores MS Exchange del sitio PRINCIPAL:

Client Name: Profuturo AFP | Publish Date Gua de cambio de centro de datos | Confidential SoftwareONE

1. Terminar con los servicios ejecutndose parcialmente en el centro de datos.

Este primero paso involucra terminar con los servicios de MS Exchange Server
que se encuentren ejecutndose de manera parcial y/o an se estn ejecutando
en el centro de datos PRINCIPAL. Esto quiere decir que debemos terminar con los
miembros del DAG que se encuentran en el centro de datos cado.
Importante:
La validacin de la configuracin de los parmetros del DAG se debe realizar en el caso de una simulacin, y/o
pase una conmutacin de centro de datos planeada.
Se debe realizar antes del apagado de servidores del sitio PRINCIPAL.
En caso de una cada real del centro de datos este punto se puede obviar.

Antes de detener los servicios, debemos validar la configuracin de los

parmetros del DAG:

Validar el Primary Active Manager (PAM)

Ejecutamos el siguiente comando:
Get-DatabaseAvailabilityGroup PROFUTURODAG -status | fl Name,
PrimaryActiveManager

Validar el Datacenter Activation Coordination (DAC)

Ejecutamos el siguiente commando:
Get-DatabaseAvailabilityGroup Identity PROFUTURODAG
Name, DatacenterActivationMode

Validamos el tipo de Quorum y servidor testigo (Witness)

Ejecutamos uno de los siguientes comandos:
Cluster /quorum
Get-ClusterQuorum | fl

Client Name: Profuturo AFP | Publish Date Gua de cambio de centro de datos | Confidential SoftwareONE

fl

Validar la ubicacin lgica de los servidores a nivel de Active Directory

Ejecutamos el siguiente comando:
Get-ExchangeServer Status | fl name, site

Validar el estado de las bases de datos

Ejecutamos el siguiente comando:
Get-MailboxDatabaseCopyStatus Identity DB* | select name,
status, SelectcontentIndexState | sort Status | ft auto

Una vez que hemos validado que los parmetros del DAG se encuentran
correctamente configurados, podemos proceder con el apagado de los servidores
MS Exchange del sitio PRINCIPAL.
Una vez apagados los servidores, procedemos validar el estado de las bases de
datos nuevamente:
Get-MailboxDatabaseCopyStatus Identity DB* | select name, status,
SelectcontentIndexState | sort Status | ft auto

Client Name: Profuturo AFP | Publish Date Gua de cambio de centro de datos | Confidential SoftwareONE

Esta vez observamos que el estado de las copias de base de datos en el servidor
PROFUTUROMBX es ServiceDown, esto se debe a que el servidor se encuentra
apagado.
A su vez tambin se observa que el estado de las copias de base de datos para el
servidor CTGMBX es Dismounted, esto se debe que no se tiene comunicacin
con el servidor testigo (Witness), dado que el servidor PROFUTUROCAS (Witness
Server) se encuentra apagado.
Ahora procedemos a terminar con todo los servicios MS Exchange que se
encuentren ejecutndose parcialmente en el centro de datos PRINCIPAL, para esto
ejecutamos el siguiente comando:
Stop-DatabaseAvailabilityGroup PROFUTURODAG ActiveDirectorySite
PRINCIPAL
-ConfigurationOnly
Con este comando estamos poniendo a todos los miembros del DAG ubicados en
el sitio PRINCIPAL en estado Stopped.
Importante:
El parmetro ConfigurationOnly se debe ejecutar cuando el servidor con rol de Mailbox NO se encuentra
disponiblie y el controlador de dominio se encuentra operando el sitio PRINCIPAL.

Ahora procedemos a validar el estado de los servidores, ejecutando el siguiente

comando:
Get-DatabaseAvailabilityGroup
PROFUTURODAG
|
FL
Name,StoppedMailboxServers,StartedMailboxServers

Podemos observar que el servidor PROFUTUROMBX se encuentra en estado

Stopped y el servidor CTGMBX se encuentra en estado Started.

Client Name: Profuturo AFP | Publish Date Gua de cambio de centro de datos | Confidential SoftwareONE

2. Activar los servidores de buzones (Mailbox Server)

Para activar los servidores de buzones en el sitio de contingencia, debemos
realizar las siguientes actividades:

El servicio de Cluster debe ser detenido en cada servidor miembro del DAG
ubicado en el sitio de contingencia. Ejecutamos uno de los siguientes
comandos o simplemente desde la consola de servicios:
Stop-Service ClusSvc
Net stop clussvc

Ahora procedemos a restaurar la configuracin del DAG en el sitio de

CONTINGENCIA, para esto ejecutamos el siguiente comando:
Restore-DatabaseAvailabilityGroup
PROFUTURODAG
-ActiveDirectorySite CONTINGENCIA

Este comando realiza varias operaciones que afectan la estructura y

membresa del DAG (cluster), como son las ms importantes y necesarias:
o

o
o

Retira
a
la
fuerza
los
servidores
marcados
como
StoppedMailboxServers
del
DAG
(cluster),
as
como
restableciendo el quorum para el cluster permitiendo a los
miembros supervivientes del DAG iniciar y brindar servicio.
Configura el DAG para que utilice el servidor testigo alterno
(Alternate Witness).
Fuerza la replicacin a nivel de ADDS y Exchange, para que sitio de
contingencia reconozca los cambios en los diferentes servicios.

En este punto, que ya hemos restaurado el DAG en el sitio de CONTINGENCIA,

validamos los siguientes parmetros:

Primary Active Manager (PAM)

Ejecutamos el siguiente comando:
Get-DatabaseAvailabilityGroup PROFUTURODAG -status | fl Name,
PrimaryActiveManager

Ahora se observar que el PAM ahora se encuentra en el servidor CTGMBX

(servidor con el rol de mailbox ubicado el sitio de CONTINGENCIA). Esto
permitir que las bases de datos detecten el PAM activo y por ende el
servidor CTGMBX pasa a ser el propietario de los recursos del cluster.

Client Name: Profuturo AFP | Publish Date Gua de cambio de centro de datos | Confidential SoftwareONE

Importante:

Hay veces que el PAM sigue ubicado en el servidor que se encuentra cado, en esos
casos se puede usar el siguiente comando para mover el PAM hacia el servidor ubicado
en el sitio de contingencia.
Comando: Move-ClusterGroup -Name "Cluster Group" -Node CTGMBX

Validamos el Quorum y el servidor testigo (Witness)

Ejecutamos el siguiente comando:
Get-DatabaseAvailabilityGroup PROFUTURODAG status | fl Name,
Witness*, Alternate*

Se observar que el DAG se encuentra utilizando el servidor testigo alterno,

lo cual permitir que las bases de datos se activen y puedan brindar
servicio de correo.

Validamos el estado de las bases de datos y las copias

Ejecutamos el siguiente comando:
Get-MailboxDatabaseCopyStatus Identity DB* | select Name,
Status, SelectcontentIndexState | sort Status | ft auto

Finalmente podemos observar que las bases de datos se encuentran

montadas en el servidor CTGMBX.
Importante:

En caso las bases de datos no se logren montar, se deben montar (forzado)

manualmente con el siguiente comando:
Move-ActiveMailboxDatabase <Database Name>
-ActivateOnServer <DR
Server Name> -MountDialOverride:None

Client Name: Profuturo AFP | Publish Date Gua de cambio de centro de datos | Confidential SoftwareONE

3. Activar servidores con el de acceso de cliente

Para realizar este proceso, se deben realizar las siguientes actividades:

Cambiar los registros DNS de la zona profuturo.com.pe, para que

apunten al servidor (CTGCAS) con rol acceso de cliente ubicado el sitio de
CONTINGENCIA.
Se debe realizar el cambio al siguiente registro:
o Mail

Se debe realizar el cambio en el antispam perimetral, para que ahora

entregue correos al servidor CTGCAS.

Importante:

Cuando el sitio PRINCIPAL vuelve a estar activo, se deben regresar los registros DNS a la
configuracin anterior, es decir que vuelven apuntar al servidor PROFUTUROCAS,
ubicado en el sitio PRINCIPAL.

4. Retorno a centro de datos PRINCIPAL (SwitchBack)

Una vez que el sitio PRINCIPAL vuelve a entrar en funcionamiento, se deben
realizar las siguientes actividades para reincorporar los servidores Exchange con
el rol de mailbox (PROFUTUROMBX) al DAG.
Para esto ejecutamos el siguiente comando:
Start-DatabaseAvailabilityGroup PROFUTURODAG
PRINCIPAL

-ActiveDirectorySite

Finalmente para asegurarnos que el DAG vuelva a usar la configuracin de

parmetros correcta y sobre todo use el correcto modelo de quorum, ejecutamos
el siguiente comando:
Set-DatabaseAvailabilityGroup -Identity PROFUTURODAG
Una vez ejecutados estos comandos, se debe esperar aproximadamente unos 20
min para que las bases de datos vuelvan a sincronizar

3. RESOLUCIN DE PROBLEMAS CONOCIDOS

Durante un proceso de pase a contingencia planeado y/o no planeado, se pueden
presentar diferentes problemas a nivel del servicio de correo, los ms conocidos son:

Client Name: Profuturo AFP | Publish Date Gua de cambio de centro de datos | Confidential SoftwareONE

Las bases de datos no se montan en el sitio de contingencia

o Se debe validar que el DAG est utilizando el servidor y directorio testigo
alterno (Alternate Witness).
o Se debe validar que el PAM se encuentre alojado el sitio de contingencia,
en uno de los servidores miembros del DAG.
Error:

El PAM permanece en el sitio principal (servidor cado y/o apagado)

o Esto se debe a que la replicacin no fue adecuada, ocasionando un objeto
hurfano a nivel de ADDS, el cul evita que el PAM pueda ser reconocido
en el sitio de contingencia.
o Se debe validar el estado del PAM
Error:

El PAM no reconoce un servidor mailbox y queda en estado Failed (en blanco)

o Se debe validar el estado de los servicios.
o Se debe validar el acceso al servidor y directorio testigo.
Error:

Como pueden observar los 03 problemas estn relacionados, y muchas veces con
resolver un punto se solucionan el resto. A continuacin vamos a detallar los comandos
que se pueden utilizar para lograr la solucin:
1. Primero se debe validar el acceso a la ruta \\ctgcas\DagWitness desde el servidor
CTGMBX. Esto permite saber si el DAG puede llegar al directorio testigo para
obtener el voto necesario.
2. Segundo se validar el estado de los servicios de replicacin (DAG), ejecutamos el
siguiente comando: Test-ReplicationHealth
Este comando nos ayudar a saber el estado del servicio ActiveManager y
ClusterService. Estos 02 servicios son los necesarios para que pueda iniciar el
DAG y las bases de datos.
3. Finalmente para volver activar estos servicios ejecutamos el siguiente comando:
Start-DatabaseAvailabilityGroup MailboxServer CTGMBX
Con este comando refrescamos la membresa del servidor CTGMBX para el DAG,
de tal forma que el PAM pueda ubicar un servidor.

10

Client Name: Profuturo AFP | Publish Date Gua de cambio de centro de datos | Confidential SoftwareONE

4. REFERENCIAS
Para mayor referencia, conocimiento del funcionamiento de alta disponibilidad en
Exchange Server 2013 y entendimiento del procedimiento, se recomienda leer los
siguientes enlaces:

Datacenter SwitchOver
https://technet.microsoft.com/en-us/library/dd351049(v=exchg.150).aspx

Dynamic Quorum for two Node DAG

https://social.technet.microsoft.com/Forums/office/en-US/ee5bac97-45af-47388753-6ef5322bc590/how-does-dynamic-quorum-work-for-a-two-node-dag?
forum=exchangesvravailabilityandisasterrecovery

Exchange 2010 / 2013 PAM and the Cluster Core Resources

http://blogs.technet.com/b/timmcmic/archive/2014/08/04/exchange-2010-2013pam-and-the-cluster-core-resources.aspx

High Availability Misconceptions Addressed

http://blogs.technet.com/b/exchange/archive/2011/05/31/exchange-2010-highavailability-misconceptions-addressed.aspx

Verifying the file share witness server

http://blogs.technet.com/b/timmcmic/archive/2012/03/12/verifying-the-file-sharewitness-server-directory-in-use-for-exchange-2010.aspx
DATACENTER ACTIVATION COORDINATION

11

Client Name: Profuturo AFP | Publish Date Gua de cambio de centro de datos | Confidential SoftwareONE

12

Part 1: My databases do not mount automatically after I enabled Datacenter

Activation Coordination (http://aka.ms/F6k65e)
Part 2: Datacenter Activation Coordination and the File Share Witness
(http://aka.ms/Wsesft)
Part 3: Datacenter Activation Coordination and the Single Node Cluster
(http://aka.ms/N3ktdy)
Part 4: Datacenter Activation Coordination and the Prevention of Split Brain
(http://aka.ms/C13ptq)
Part 5: Datacenter Activation Coordination: How do I Force Automount
Concensus? (http://aka.ms/T5sgqa)
Part
6:
Datacenter
Activation
Coordination:
Who
has
a
say?
(http://aka.ms/W51h6n)
Part
7:
Datacenter
Activation
Coordination:
When
to
run
startdatabaseavailabilitygroup to bring members back into the DAG after a datacenter
switchover. (http://aka.ms/Oieqqp)
Part 8: Datacenter Activation Coordination: Stop! In the Name of DAG...
(http://aka.ms/Uzogbq)
Part 9: Datacenter Activation Coordination: An error cause a change in the
current set of domain controllers (http://aka.ms/Qlt035)

Client Name: Profuturo AFP | Publish Date Gua de cambio de centro de datos | Confidential SoftwareONE