Exchange: 2016 DAG lab paso a paso

En este post veremos como implementar un laboratorio de dos servidores con Exchange Server 2016 y DAG (Database Availability Group) sobre las bases de datos.

¿Qué son los DAG?


Los DAG (Database Availability Group), nos permiten replicar las bases de datos que contienen los buzones (ficheros EDB) a uno o mas servidores de Exchange.

Puede haber mas de una réplica de un mismo EDB a otros servidores de Exchange. Solo un EDB replicado estará activo.

El modelo de réplica de base de datos basado en DAG es introducido en Exchange Server 2010 y utiliza los servicios de clúster de Windows Server: MSCS (Microsoft Cluster Service).

A pesar de utilizar MSCS, no es necesario instalar el servicio y luego instalar Exchange. Exchange utilizará el servicio de forma transparente. Tampoco se requiere situar las bases de datos un storage compartido (SAN).

¿Qué versiones de Windows Server y Exchange son necesarias?


Los DAG pueden montarse con la edición de Exchange Standard, no es necesario Enterprise.

La versión de Windows Server, requiere capacidades de clúster (servicio MSCS), por ejemplo en Windows Server 2008 R2, se requiere edición Enterprise ya que Windows Server 2008 R2 Standard no incorpora MSCS. A partir de Windows Server 2012, puede utilizarse la edición Standard.

En el caso de Exchange Server 2016, como la versión mínima de Windows Server donde puede instalarse es Windows Server 2012, con la edición Standard de Windows Server podremos configurar DAG.

¿Con dos servidores de Exchange, puedo montar un DAG?


Sí, pero hemos de tener en cuenta:

  • Los servidores de Exchange que formen parte del DAG, no pueden ser al mismo tiempo controladores de dominio (DC).
  • Es recomendable, no imprescindible, una red dedicada a la réplica de los EDB, distinta a la red que utilizan los clientes para comunicar con Exchange.
  • Se necesita un servidor testigo (witness), que no puede ser miembro de los DAG, este se encargará de monitorizar. El servidor testigo puede ser un DC, pero no se recomienda. Se recomienda que el servidor testigo sea un servidor de Exchange de transporte, pero también puede ser un servidor miembro.
  • Las versiones de Exchange (2010, 2013, 2016) y nivel de parches, deben ser las mismas en ambos servidores.
  • Si existe o no DAG queda guardado en Active Directory: CN=Database Availability Groups,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=,DC=

¿Como funciona la réplica?


La replicación utiliza los logs de transacciones para replicar. Existen dos tipos de replicación: a nivel de fichero y a nivel de bloque. En una primera replicación, se utiliza la replicación a nivel de fichero y para replicas posteriores, a nivel de bloque.

Según nuestro escenario: ¿Es buena idea montar un DAG?


Debemos realizar un profundo análisis antes de implementar en producción DAG.

Especial atención a los recursos necesarios para dimensionar de forma correcta.

Algunos puntos a tener en cuenta en un escenario de dos nodos:

  • Para conseguir una alta disponibilidad completa: Hay que redundar no solo los EDB, tengamos en cuenta: DCs, transporte, etc. El DAG solo redunda EDBs.
  • Necesitaremos el doble de espacio disponible: La máquina donde tenemos Exchange con los EDBs, tendremos que multiplicar por dos el espacio que ocupa, en el caso de querer solo dos nodos.
  • Parches, tareas administrativas, etc, multiplicamos por dos.
  • Los Exchange, utilizarán más recursos: La réplica se hace de forma continua: Más uso de CPU, disco, etc.
  • Debemos realizar copias de seguridad de los dos Exchange: Necesitamos espacio y ventana en nuestro sistema de backups.

 

Veamos como configurar un laboratorio para probar el uso de DAG sobre Exchange Server 2016:


Escenario de laboratorio:

  • DC1 - Windows Server 2012 - Controlador de dominio del dominio D1.local.
  • EX1 - Exchange Server 2016 - Servidor Exchange, con todos los roles.
  • EX2 - Exchange Server 2016 - Servidor Exchange, con todos los roles.

La instalación de Exchange Server 2016 sobre Windows Server 2012 se ha realizado utilizando el siguiente procedimiento:


Vista servidores de Exchange Server 2016 en Exchange Control Panel:

Pasos a seguir:

1) Añadimos una NIC adicional a cada servidor de Exchange Server 2016, teniendo en cuenta lo siguiente:

Sobre las NICs añadidas:

  • TCP/IP: Configuramos un segmento de red distinto al que acceden los clientes. No configuraremos puerta de enlace predeterminada.
  • Deshabilitamos IPv6. (Propiedades interface de red)
  • Deshabilitamos "NetBios sobre TCP/IP".
    (Propiedades interface de red > TCP/IPv4 > "Opciones avanzadas" > "Pestaña WINS")
  • Configuramos el orden correcto de los adaptadores, primero la NIC a la que conectan los clientes, segundo la NIC de la réplica (ncpa.cpl > tecla Alt, menú "Opciones avanzadas" > "Configuración avanzada")
  • Deshabilitamos el registro automático en el DNS Server. (Propiedades interface de red > TCP/IPv4 > "Opciones avanzadas" > "Pestaña DNS")

Este paso es opcional, pero de esta forma conseguimos que el tráfico de la réplica no pase por las NICs donde conectan los clientes.

2) En el servidor testigo:

El grupo de dominio “Exchange  Trusted Subsystem” debe añadirse al grupo local de “Administradores”.

Si el servidor testigo es un DC (no recomendado): dsa.msc > contenedor Builtin > editamos el grupo administradores y añadimos: “Exchange  Trusted Subsystem”

Si el servidor testigo es un servidor miembro: lusrmgr.msc > Grupos > editamos el grupo administradores y añadimos: “Exchange  Trusted Subsystem”

Si el servidor testigo es un servidor de Exchange: por ejemplo, un Exchange con el rol de transporte, no es necesario realizar este paso.

3) Montamos el DAG:

Podemos realizar el procedimiento, utilizando Exchange Control Panel o Exchange Management Shell.

El procedimiento consta de dos apartados:

1) La creación del DAG, donde introduciremos el nombre del DAG, el servidor y directorio del servidor testigo y la dirección IP del DAG.

2) Después añadiremos el servidor Exchange: EX1 y EX2 dentro del DAG.

Para realizar el procedimiento vía Exchange Management Shell:

Creamos el DAG:

New-DatabaseAvailabilityGroup -Name DAG1 -WitnessServer DC1.D1.local -WitnessDirectory c:\testigo  -DatabaseAvailabilityGroupIpAddresses 172.20.0.3

Añadimos servidores de Exchange al DAG:

Add-DatabaseAvailabilityGroupServer DAG1 -MailboxServer EX1
Add-DatabaseAvailabilityGroupServer DAG1 -MailboxServer EX2

Ver configuración:

Get-DatabaseAvailabilityGroup DAG1|fl

Para realizar el procedimiento vía Exchange Control Panel:

Servidores > Grupos de disponibilidad de base de datos > +


Añadimos servidores de Exchange al DAG:


Consideraciones:

El proceso de creación del DAG, nos creará un CNO (Cluster Name Object), podemos ver el objeto de equipo en el contenedor "computers" de Active Directory:


Si disponemos de Exchange Server 2013 SP1 o superior sobre Windows Server 2012 R2 o superior, no es necesario especificar una IP dedicada al clúster, podremos especificar: 0.0.0.0, tampoco se procederá a la creación de CNO de forma automática.

En el ejemplo descrito en este post, disponemos de Exchange Server 2016 pero funcionando sobre Windows Server 2012, así que es necesaria la dirección IP dedicada al clúster y la creación del CNO.

4) Configuramos las réplicas:

Una vez realizados los pasos anteriores, ya podemos ver la opción "Agregar copia de base de datos", al situamos sobre una base de datos y pulsar "···":

Utilizando esta opción, indicaremos para cada base de datos, el servidor de Exchange miembro del DAG, al que se replicará.

3 comentarios:

  1. Hola Xavier
    Acabo de conocer tu sitio y nos resulta fantástico !!!
    Quiero aprovechar para consultarte por el como queda la configuración de la NIC LAN, si en los detalles (Network Connetion Details) de la misma debe aparecer la dirección IP del servidor testigo, tenemos un DAG con seis servidores y 5 de ellos presentan un flag solicitando reiniciar para solucionar el driver, pero ya son varias las reiniciadas y nada, el 6to, quien no presenta el flag, tiene en los detalles de la NIC LAN su IP y la IP del servidor testigo. Sería fantástico enviarte imágenes.
    Bien desde ya mil gracias por todo y saludos !!!

    ResponderEliminar
  2. Excelente post.
    Tengo una duda:
    Si no hay Ip de cluster....como se conectan los clientes al exchange? o debo poner un round robin o hardware para el balanceo?

    gracias

    ResponderEliminar
    Respuestas
    1. Hola Oscar,

      Los clientes se conectan al CAS (client access server), es decir, se conectan al IIS para acceder a los buzones.

      Piensa que con DNS round robin, no podrás detectar la caída del nodo y redirigir el tráfico al nodo activo.

      Un saludo,

      Xavi.

      Eliminar