En este artículo vamos a ver los aspectos más relevantes a nivel de configuración de red en un entorno de DAG de Exchange.
A continuación algunas de las interrogantes más comunes respecto el tema:
-
Puedo configurar un DAG con una única tarjeta de red?
-
Si utilizo más de una tarjeta, en cual configuro el default gateway?
-
Cómo defino una red dedicada para replicación?
-
En que casos necesito utilizar rutas estáticas?
A tener en cuenta que a lo largo del artículo vamos a ver referencias a servidores Exchange 2010 / 2013 / 2016 en DAG. Con esto no quiero decir que se pueden combinar versiones, simplemente indicar que los conceptos aplican en cualquiera de los casos.
DAG con una única tarjeta de red?
Esta totalmente soportado configurar un DAG con una única tarjeta de red, de cualquier modo esto va a depender de los requerimientos.
En términos generales, la recomendación es ir por la configuración más simple (siempre y cuando cumpla con los requerimientos), es decir que si con una tarjeta de red es suficiente para nuestro escenario, por ejemplo a nivel de acceso de clientes y tráfico de replicación, esta sería la opción recomendada.
DAG con 2 tarjetas de red
Si deseamos separar el tráfico de replicación del tráfico de clientes partimos de la base de que necesitamos como mínimo 2 tarjetas de red. Para lograr este requerimiento tenemos que realizar configuraciones tanto desde el lado de Exchange como del de conectividad.
Primero que nada debemos configurar las tarjetas de red con un nombre que deje claro para que se utiliza cada una, en este ejemplo se configura con el nombre de “MAPI” la red de clientes y con el nombre “REPL” la red de replicación:
Posteriormente verificamos la prioridad de los adaptadores:
La red de replicación debe figurar debajo de la red MAPI, de lo contrario con las flechas a la derecha modificamos el orden:
A continuación configuramos la placa de replicación según las mejores prácticas de Microsoft:
En las propiedades de IPv4 verificamos que no haya un default gateway, ni servidor DNS, WINS, etc. En adición debemos desmarcar el checkbox de “Register this connection’s addresses in DNS”:
En caso de usar Exchange 2010 es necesario configurar las redes del DAG de forma manual, por ejemplo para indicar que la red MAPI no sea utilizada para replicación:
Set-DatabaseAvailabilityGroupNetwork -identity DAG01\MAPI -ReplicationEnabled:$false
Nota: Si la red de replicación por algún motivo no esta disponible , Exchange ignora el hecho de que se haya deshabilitado este seteo en la red dedicada a clientes y la utiliza para replicar.
Si utilizamos Exchange 2013 / 2016, la configuración de red en DAG es automática de forma predeterminada y esta es la recomendación. Para que esto funcione correctamente es necesario configurar los adaptadores de red, prioridades y rutas estáticas como se ve a lo largo del artículo.
Si por algún motivo se desea configurar de forma manual se debe setear en $true el parámetro «ManualDagNetworkConfiguration» de la configuración del DAG (Set-DatabaseAvailabilityGroup).
Ahora que tenemos la configuración base veamos un ejemplo
3 servidores en DAG distribuidos del siguiente modo:
MVD-EX1 – Exchange en DAG ubicado en el sitio principal
-
Placa de clientes – 192.168.1.10 /24 –> Default Gateway: 192.168.1.254
-
Placa de replicación – 10.1.1.10 /24
MVD-EX2 – Exchange en DAG ubicado en el sitio principal
-
Placa de clientes – 192.168.1.11 /24 –> Default Gateway: 192.168.1.254
-
Placa de replicación – 10.1.1.11 /24
CONT-EX1 – Exchange en DAG ubicado en sitio de contingencia
-
Placa de clientes – 192.168.2.10 /24 –> Default Gateway: 192.168.2.254
-
Placa de replicación – 10.1.2.10/24
Como se puede ver la puerta de enlace esta configurada en la placa de red principal (a la que se conectan los clientes entre otros servicios), entonces como llegamos desde la red de replicación de un sitio a la red de replicación del otro? A través del default gateway correcto?
Esto implica entonces que aunque se haya configurado una red para replicación y otra para clientes a nivel de Exchange, luego cuando se resuelva el ruteo a nivel de Windows va a ver que no tiene una ruta directa para la red de replicación del otro sitio por lo que no le queda otra opción que utilizar su puerta de enlace predeterminada por lo que en definitiva termina replicando por la red de clientes.
Cuál sería la solución en este caso?
“Rutas estáticas”
La idea es indicarle al servidor que todo trafico destinado a una red de replicación debe pasar por un gateway alternativo al configurado en la placa de red principal (no es posible configurar un default gateway diferente para cada placa, no funciona bien y tampoco esta soportado). En general se recomienda crear una VLAN separada para cada caso y que las redes de replicación y MAPI (de clientes) no sean ruteables entre sí.
Volvamos al ejemplo anterior ahora utilizando rutas estáticas
MVD-EX1
-
Placa de clientes – 192.168.1.10 /24 –> Default Gateway: 192.168.1.254
-
Placa de replicación – 10.1.1.10 /24 –> Ruta estática para llegar a la subred 10.1.2.0/24
MVD-EX2
-
Placa de clientes – 192.168.1.11 /24 –> Default Gateway: 192.168.1.254
-
Placa de replicación – 10.1.1.11 /24 –> Ruta estática para llegar a la subred 10.1.2.0/24
CONT-EX1
-
Placa de clientes – 192.168.2.10 /24 –> Default Gateway: 192.168.2.254
-
Placa de replicación – 10.1.2.10/24 –> Ruta estática para llegar a la subred 10.1.1.0/24
En Windows server 2003 y versiones anteriores el comando que se utilizaba para configurar rutás estáticas era el “route add”, así como para ver la tabla de ruteo el “route print”, etc. A partir de Windows Server 2008 se recomienda utilizar “netsh”. Si utilizamos “route add” va a funcionar pero puede derivar en problemas como por ejemplo que las rutas no persistan (aunque se especifique en el comando).
Veamos los comandos que debemos ejecutar en cada servidor:
MVD-EX1 y MVD-EX2
netsh interface ipv4 add route 10.1.2.0/24 “repl” 10.1.1.254
CONT-EX1
netsh interface ipv4 add route 10.1.1.0/24 “repl” 10.1.2.254
Una forma de validar que la ruta este en funcionamiento sería haciendo un tracert al otro servidor:
MVD-EX1 o MVD-EX2
tracert 10.1.2.10
CONT-EX1
tracert 10.1.1.10
En ambos casos tendríamos que ver que pasa por el gateway que le especificamos en la ruta estática en lugar del default, si no muestra esto es porque algo no quedó bien configurado.
Si por algún motivo debo eliminar una ruta, puedo hacerlo del siguiente modo:
netsh interface ipv4 delete route IP/Mascara “nombre de tarjeta” Gateway
Para visualizar las rutas cargadas:
netsh interface ipv4 show route
A partir de este momento es posible llegar desde las placas de red dedicadas a replicación en cada sitio a la red correspondiente del otro sin pasar por la placa principal.
Por más info sobre DAG ver el siguiente artículo:
Estimado Daniel.
me sale el siguiente error luego que he creado el DAG
«el testigo dag del grupo de disponibilidad de la base de datos se encuentra en estado de error. el grupo de disponibilidad de la base de datos necesita que el servidor testigo mantenga el quorum. Use el cmdlet set-DatabaseAvailabilityGroup para volver a crear el directorio y el servidor testigo».
que puedo hacer en este caso.
gracias de ante mano.
saludos.