Checklist Failover – Failback de Sitio Completo DAG | Exchange Server 2010 Service Pack 3

En esta oportunidad les traigo un checklist, tanto para realizar el failover de sitio completo de DAG hacia un sitio de contingencia como el failback hacia el sitio primario.

Primero responderemos dos preguntas esenciales:

¿Qué es un DAG?

Un DAG es el método por cual, a partir de Exchange 2010, se realiza la alta disponibilidad de las bases de datos.

¿Qué es un sitio de contingencia?

Exchange 2010 en adelante, nos brinda la capacidad de contar con un sitio de contingencia en una ubicación física distinta, gracias al apoyo de DAG.

Para mayor información sobre DAG, alta disponibilidad y sitio de contingencia:

https://technet.microsoft.com/en-us/library/dd979799(v=exchg.141).aspx

https://technet.microsoft.com/en-us/library/dd638121(v=exchg.141).aspx

Escenario

El escenario para el cual está preparado el checklist, es el siguiente:

Infraestructura general:

  • Organización de Exchange 2010 Service Pack 3 (sin coexistencia).
  • Conectividad por medio de MPLS entre los dos datacenters.
  • Cada Data Center cuenta con conectividad de internet en forma separada.
  • Dos sitios de Active Directory.
  • Se utiliza el mismo certificado en cada sitio para los servidores Exchange.
  • DAC Mode configurado en DagOnly

Sitio A:

  • Dos servidores de buzones con bases activas.
  • Dos servidores de acceso cliente que conforman un CAS Array balanceado por un equipo externo.
  • File Share Witness primario.

Sitio B:

  • Dos servidores de buzones con bases activas.
  • Dos servidores de acceso cliente que conforman un CAS Array balanceado por un equipo externo.
  • File Share Witness alternativo.

A continuación, les dejo un diagrama en alto nivel de la infraestructura:

Exchange2010- DAG extendido

Acceso cliente:

El acceso cliente está configurado mediante un balanceador de hardware de capa 7 en cada sitio, el cual detectara la inactividad y se encargara en forma automática de realizar el failover del sitio A hacia el sitio B.

La url de los directorios virtuales son las mismas para cada uno de los servicios (OWA, EWS, Active Sync, OAB, ECP) en ambos sitios, a excepción del nombre FQDN de los CASARRAY ya que debemos contar con uno para cada sitio de AD donde se aloja un servidor de buzón.

Los nombres de los CASArray no hace falta que este configurados en el certificado digital.

Al utilizar las mismas URL podemos marcar dos cosas:

• Se utiliza el mismo certificado para ambos sitios, en este caso un certificado del tipo SAN.
• Las bases deben estar activas o en un sitio o en otro, no podremos tener bases de datos activas en simultaneo en ambos sitios ya que para eso debemos contar con URL separadas para los servicios de Exchange y dos DAG.

Por ultimo vale destacar que los registros DNS públicos y privados están configurados con un TTL de 5 minutos por recomendación oficial de Microsoft y que en mi caso son manejados en forma automática por el balanceador para realizar el cambio, cuando se realizar el failover entre sitios.

Transporte:

En mi caso, están configurados junto a los servidores CAS y mediante un balanceador de hardware les indico en forma automática por cual servidor recibir correo en caso de failover entre sitios.

También puede lograrse un objetivo similar utilizando dos MX con diferentes prioridades, uno que apunte al sitio A y otro hacia el sitio B.

DAG:

Como se puede observar en el diagrama, el DAG está constituido por 4 servidores, 2 en el sitio A y 2 en el sitio B.

A su vez, se ha configurado el DAC en DagOnly para evitar un “split-brain”, es decir para evitar que cuando se esté trabajando sobre el sitio B por ejemplo por una caída en el sitio A y luego el sitio A levanta, no se produzca una pérdida de dueño de Cluster, es decir que los servidores de A quieran montar sus bases y los del B las tienen montadas y terminen por desmontarse todas!

Por último, hemos configurado en un servidor CAS, el Witness como primario en el sitio A y como alternativo un servidor CAS del sitio B. De esta forma podemos mantener el quorum en caso que falle el vínculo de internet entre sitios y no se desmontaran nuestras bases.

Checklist:

Como les prometí, les dejo el checklist para realizar el failover y failback de las bases de datos entre los sitios

Failover entre los sitios:

Failover

Failback entre sitios:

Failback

Descripción:

Como verán, los Excel están en ingles pero pueden traducir el título y el resultado esperado de las tareas con Bing o Google 😛

• En la primer columna está el orden de las tareas.
• En la segunda el título de la misma.
• En la siguiente el resultado esperado.
• En la cuarta el comando exacto a ejecutar por Powershell
• En la quinta columna el enlace oficial sobre cada comando.
• En la sexta el estado de la tarea, donde sí se ingresa un -1 aparece la X, si se ingresa un 0 aparece un signo de admiración y si se ingresa un 1 aparece una tilde verde para indicar que la tarea salió bien.

Estos checklist, les pueden ser de utilidad en caso que tengan que presentar un plan de trabajo a un jefe o a un cliente o para uso propio!

¿Desde dónde descargo los checklist?

Checklist Failback: https://gallery.technet.microsoft.com/Checklist-Failback-de-8df51c91

Checklist Failover: https://gallery.technet.microsoft.com/Checklist-Failover-de-ccc7e336

Saludos!!

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Create a free website or blog at WordPress.com.

Up ↑

%d bloggers like this: