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:
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”:
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
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
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 último les dejo algunos enlaces adicionales en relación a configuración de red en DAG, alta disponibilidad y contingencia:
http://technet.microsoft.com/en-us/library/dd638104(v=exchg.150).aspx
http://technet.microsoft.com/en-us/library/dd297927(v=exchg.150).aspx
Puzzle Bobble
Karate Blazers
Puzzle De Bloques
Magical Cat Adventure