Revista Informática

Configuración de red en DAG – Exchange 2010 / 2013

Publicado el 08 enero 2014 por Aprendiendoexchange

En este artículo vamos a ver los aspectos más relevantes a nivel de configuración de red de Exchange 2010 o 2013 en un entorno de DAG (Database Availability Group).

A continuación algunas de las interrogantes más comunes respecto el tema:

  • Puedo armar 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 en DAG. Con esto no quiero decir que pueden combinar versiones, simplemente indicar que los conceptos aplican en ambos casos.

DAG con una única tarjeta de red?

Si bien alcanza y esta totalmente soportado configurar un DAG con una única tarjeta de red, la recomendación es utilizar al menos 2; una para acceso de clientes, servicios de red y otra para replicación. De cualquier modo es un requerimiento que puede variar de cliente en cliente y no es extraño encontrarse con organizaciones con pocos buzones que requieran alta disponibilidad pero que no tengan interés en dedicar una red para replicación.

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:

ncpa.cpl - Conexiones de red

Posteriormente verificamos la prioridad de los adaptadores:

Conexiones de red - Advanced settings

La red de replicación debe figurar debajo de la red MAPI, de lo contrario con las flechas a la derecha modificamos el orden:

Conexiones de red - Adapters and bindings

A continuación configuramos la placa de replicación según las mejores prácticas de Microsoft:

image

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”:

image

Configuramos el DAG acorde a los requerimientos y  abrimos el Exchange Management Shell (EMS) para indicar que la red MAPI no debe ser utilizada para replicación:

Set-DatabaseAvailabilityGroupNetwork -identity DAG01\MAPI -ReplicationEnabled:$false

Set-DatabaseAvailabilityGroupNetwork - Replicación deshabilitada

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.

Ahora que tenemos la configuración base veamos un ejemplo:

3 servidores en DAG distribuidos del siguiente modo:

MVD-EX1 – Exchange 2010 / 2013 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 2010 / 2013 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 2010 / 2013 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 verán 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 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.  Me he encontrado en varias instalaciones que esto queda así hasta que alguien de redes llama la atención indicando que la red dedicada a replicación no esta siendo utilizada. Esto no es problema cuando los servidores están en la misma subred, pero si lo es cuando tenemos un sitio de contingencia. No me refiero a problema en el sentido de que no repliquen, sino que porque no estamos cumpliendo con el requerimiento de separar los distintos tipos de tráfico de red.

Cuál sería la solución en este caso? Seguro que ya les esta sonando: “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. Esto a partir de Windows Server 2008 cambió a utilizar el comando “netsh”. Si lo hacen con “route add” va a funcionar pero puede derivar en problemas como por ejemplo que las rutas no persistan (aunque le indiquen al comando que lo haga).

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

netsh interface ipv4 add route

CONT-EX1

netsh interface ipv4 add route 10.1.1.0/24 “repl” 10.1.2.254

netsh interface ipv4 add route

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

Tracert - Exchange

CONT-EX1

tracert 10.1.1.10

image

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 último les dejo algunos enlaces adicionales en relación a configuración de red en DAG, alta disponibilidad y contingencia:

http://blogs.technet.com/b/timmcmic/archive/2009/04/26/windows-2008-multi-subnet-clusters-and-using-static-routes.aspx

http://technet.microsoft.com/en-us/library/dd638104(v=exchg.150).aspx

http://technet.microsoft.com/en-us/library/dd297927(v=exchg.150).aspx


Volver a la Portada de Logo Paperblog