"Esta entrada hace referencia a algunos de los posibles métodos de conexión con Internet cuando se disponen arquitecturas MultiDataCenter, los cuales pueden dar algunas ideas para decidir el camino a seguir en el diseño final de la conectividad con los ISPs"
Se describen varios tipos de conexionado (sin ningún tipo de balanceador de líneas) ya que, dependiendo de la contratación con los proveedores, se podrá desplegar uno u otro.
Aunque siempre se desea el confinamiento de los errores dentro de un solo DC, y que estos no afecten al resto, dicho aislamiento puede provocar que, debido a incapacidades de algunas aplicaciones cliente al refrescar correctamente la IP de servicio tras fallo en un DC (ni por DNS ni por otros modos como señalizaciones IP redirect o HTTP redirect) o por el movimiento de las máquinas virtuales, lo cual provocaría un corte prolongado del servicio.
Para entender este punto se presenta de manera resumida el funcionamiento del balanceo global por DNS. Para poder conformar un comportamiento activo-activo y que las conexiones entrantes desde Internet puedan balancearse entre ambos Data Centers por este método, se ha de realizar el siguiente despliegue:
- En cada DC, existirá una infraestructura de DNS, en alta disponibilidad, de forma que se garantice el acceso continuado a este servicio, tanto para los usuarios corporativos, como para los usuarios externos.
- Para llevar a cabo la resolución de dominios de servicios, que sean publicados bajo el esquema GSLB (Global Server Load Balancing), los servidores DNS delegarán la respuesta de dichas preguntas, en la infraestructura de Balanceo Global. De este modo, cuando llega una consulta DNS sobre un dominio GSLB, el balanceador GSLB posee información tanto del DC local, como del DC espejo, y en base a las políticas de distribución configuradas (round-robin, least connections,…) decidirá cuál de las IPs Virtuales (VIPs) de servicio, asociada a la consulta DNS, será proporcionada como respuesta al cliente.
- En todo momento, los balanceadores globales se sincronizarán entre ellos. Asimismo, la infraestructura de Balanceo Global, se sincronizará con la infraestructura de Balanceo Local, para disponer en todo momento de la información correcta sobre las VIPs de las distintas granjas de servidores y el estado de los servicios disponibles en cada ubicación.
- También es importante destacar que para cada petición únicamente uno de los balanceadores globales responderá con la VIP acordada, evitando que ante una situación de fallo en la interconexión entre DCs, ambos equipos intenten responder de forma independiente. Esto se logra, entre otros, gracias a que los equipos se comunican entre sí a través de los enlaces WAN.
En el siguiente ejemplo, se muestran las elección de la IP pública del servicio, o lo que es lo mismo, la elección de uno de los dos Data Center:
Como primer paso, el cliente/usuario realizará una petición a su servidor DNS. La petición llegará a uno de los balanceadores globales de la infraestructura. Antes de devolver la IP a la que tenga que conectarse el cliente al servicio (la IP del DC 1 o la IP del DC 2), el balanceador global elegirá dicha IP atendiendo a la política configurada (cercanía del edificio al usuario, carga de los enlaces de Internet, carga de los servidores internos, etc ).
Ilustración 1 – Elección de IP pública por el balanceador global sin fallo
Ilustración 2 – Elección de IP pública por el balanceador global con fallo
Las aplicaciones preparadas para proporcionar alta disponibilidad del servicio, cuentan con métodos para dar soporte a incidencias completas de un DC, ya sea mediante el uso de IPs secundarias, refresco DNS tras fallo de conexión o mediante terceros métodos como puedan ser las redirecciones IP o HTTP. Si alguno de los aplicativos no dispone de esos métodos, se deberá tener en cuenta que, para minimizar el tiempo de corte, una de las soluciones más sencillas es que las IPs públicas de servicio se muevan de un DC a otro, de tal manera que la aplicación no tendría por qué refrescar la IP para continuar funcionando. Esto a su vez se puede hacer extendiendo o no el nivel 2 de conectividad con los ISPs.
Cada uno de los métodos, como se verá, tiene sus pros y sus contras.
Las opciones que se presentan aquí no son las únicas existentes, aunque sí algunas de las más comunes, y generalmente son los ISPs quienes pueden aportar las soluciones óptimas para cada caso.
Data Centers aislados frente a incidencias
En este punto se muestran los diseños en los que los Data Centers confinan los problemas que puedan surgir en ellos de manera local, es decir, en los que un problema en la capa de acceso a un Data Center no pueda afectar al otro, por ejemplo, por un bucle de red, un fallo en la configuración o un fallo en el funcionamiento de un único equipo.
Al no extender los problemas de un Data Center a otro, este esquema es el preferido frente a aquellos que extienden el acceso a ambos Data Centers (diseño comentado en el punto Data Centers no aislados frente a incidencias), no obstante, debido al comportamiento de los aplicativos, antes mencionado, el esquema de conectividad en el que las incidencias no están aisladas, será el que en ocasiones se tenga que desplegar a corto plazo, hasta que los aplicativos puedan evolucionar y dar soporte de alta disponibilidad.
Opción 1: Un router remoto y un solo ISP en cada DC
El primer caso es en el cual cada Data Center está conectado a un ISP y el proveedor solo es capaz de aportar conectividad a un router interno. Este esquema es habitual si no se poseen conexiones a diferentes centros del proveedor desde un mismo Data Center.
Ilustración 3 – Conexión de ISPs: Un router remoto y un solo ISP en cada DC
A continuación se muestran diferentes configuraciones, siguiendo este esquema de conexionado, para un funcionamiento activo-pasivo (tan solo se utiliza uno de los dos enlaces por cada DC), así como un activo-activo en el que se balancean las entradas y salidas por todas las líneas. Esto último se propone mediante la utilización únicamente de protocolos IGP de encaminamiento, y más tarde configurando el protocolo BGP, el cual añade complejidad pero garantiza un mejor balanceo y flexibilidad de enrutamiento en las entradas.
Activo-Pasivo
Para formar un activo-pasivo en esta configuración lo más sencillo es pedir al proveedor (ISP) que configure algún protocolo FHRP (ya sea HSRP o VRRP), y configurar dicha IP virtual como default Gateway, como aparece en las ilustraciones mostradas a continuación:
Ilustración 4 –Un router remoto y un solo ISP en cada DC activo-pasivo
Ilustración 5 –Un router remoto y un ISP en cada DC activo-pasivo – Flujo de conexiones
Activo-Activo con IGP
Se puede lograr la utilización de ambos enlaces para el tráfico de salida inyectando dos rutas por defecto mediante IGP (OSPF para estos ejemplo) a los routers/firewalls internos (firewalls en el ejemplo), de manera que este pueda balancear los paquetes uno a uno.
Ilustración 6 –Un router remoto y un solo ISP en cada DC activo-activo en salida
Para el balanceo del tráfico entrante se puede pedir al proveedor que configure las rutas primarias de la mitad de la LAN por un enlace y de la otra mitad por el otro (siempre teniendo en cada uno el enlace parejo como backup).
Ilustración 7 –Un router remoto y un solo ISP en cada DC activo-activo en entrada
Este despliegue no hace un balanceo en el cual se utilicen los enlaces por igual, ya que puede suceder que el 80% de los accesos se realicen a IPs de la primera mitad de la LAN, con lo que la utilización de los enlaces, para esa entrada de datos, sería de 80/20.
A continuación se puede ver un ejemplo del tráfico balanceado siguiendo este esquema:
Ilustración 8 –Un router remoto y un ISP en cada DC activo-activo – Flujo de conexiones
Como se puede apreciar, en el caso de acceso a una misma IP de manera recurrente, la entrada del paquete siempre utilizaría el mismo enlace, mientras que las respuestas, al estar balanceado por OSPF, utilizarían los dos, provocando tráfico asimétrico en el proveedor de acceso, punto que también deberá ser comentado con él en el momento del diseño final.
Activo-Activo con BGP
Para poder contar con un balanceo real de entrada, es necesaria la configuración del protocolo BGP del modo que se presenta a continuación:
Ilustración 9 –Un router remoto y un solo ISP en cada DC activo-activo con BGP
En este caso, el propio protocolo BGP puede configurarse para realizar el balanceo de tráfico de salida.
Para el balanceo de entrada, el proveedor debe permitir la modificación de la configuración del protocolo BGP de los routers de su central que conectan con los routers de acceso de cada Data Center, por ejemplo, activando el soporte multihop de BGP. Gracias a esas configuraciones, si el ISP permite que se realicen, se obtendría un balanceo casi 50/50 del tráfico de entrada.
Si a esto se le suma el 50/50 de utilización para la salida, se podría afirmar que con este despliegue se haría un uso óptimo de los enlaces.
El problema de la implementación está en las posibilidades que aporten los ISPs contratados cuando se les plantean modificaciones de configuración en equipos internos suyos.
Ilustración 10 –Un router remoto y un solo ISP en cada DC activo-activo con BGP - Trafico salida
Ilustración 11 –Un router remoto y un solo ISP en cada DC activo-activo con BGP - Trafico entrada
Un ejemplo del balanceo 50/50 comentado, podría ser el siguiente:
Ilustración 12 –Un router remoto y un solo ISP en cada DC activo-activo con BGP - Flujos
Opción 2: Dos routers remotos y un ISP en cada DC
Este tipo de conexión es muy parecida a la anterior, la diferencia radica en que el proveedor puede garantizar que los enlaces contratados acaban en equipamiento distinto. Esto añade un nivel más de redundancia frente al esquema anterior.
Ilustración 13 –Dos routers remotos y un solo ISP en cada DC
Del mismo modo que antes, se plantean los despliegues activo-pasivo, y activo-activo mediante la configuración de IGP o con la implementación de BGP.
Activo-Pasivo
Al igual que antes, para obtener un uso de los enlaces activo-pasivo, la manera más sencilla sería mediante la configuración de un protocolo FHRP.
Ilustración 14 –Dos routers remotos y un solo ISP en cada DC en activo-pasivo
Un ejemplo de los flujos de tráfico para un Data Centers sería el siguiente:
Ilustración 15 –Dos routers remotos y un solo ISP en cada DC en activo-pasivo - Flujos
Activo-Activo con IGP
Para conseguir el uso de ambos enlaces para la salida del tráfico se actuará del mismo modo que en el ejemplo inmediatamente anterior, inyectando dos rutas por defecto en los firewalls con mismo coste, de manera que estos balanceen automáticamente, mientras que para la entrada se subdividirá la red en dos.
Ilustración 16 –Dos routers remotos y un solo ISP en cada DC en activo-activo – Salida
Ilustración 17 –Dos routers remotos y un ISP en cada DC en activo-activo con IGP – Entrada
En el siguiente esquema se muestran los flujos de entra y salida con la red configurada tal y como se ha comentado. Se puede comprobar cómo los flujos de entrada (amarillo y rojo) utilizan el mismo enlace (si los dos fuesen destinados a la misma mitad del direccionamiento de la red), mientras que las vueltas saldrán indistintamente por las dos conexiones:
Ilustración 18 –Dos routers remotos y un solo ISP en cada DC en activo-activo con IGP – flujos
Activo-Activo con BGP
Al igual que antes, si se desea un balanceo más equitativo de la utilización de los enlaces en la entrada de datos, se ha de pedir al ISP que realice las configuraciones BGP pertinentes.
Para seleccionar el router de salida se puede configurar OSPF entre los firewalls y los routers de acceso a Internet o incluso un FHRP y que sea el router de acceso quien balancee hacia una u otro enlace. En el siguiente ejemplo se muestra este segundo despliegue:
Ilustración 19 –Dos routers remotos y un solo ISP en cada DC en activo-activo con BGP – salida
Ilustración 20 –Dos routers remotos y un solo ISP en cada DC en activo-activo con BGP – Entrada
En el ejemplo de los flujos, se puede ver que, aunque el destino sea incluso la misma IP, la entrada podrá estar balanceada por los dos enlaces contratados:
Ilustración 21 –Dos routers remotos y un solo ISP en cada DC en activo-activo con BGP – flujos
Opción 3: Dos routers remotos y dos ISP en cada DC
Este es el diseño de conectividad con los ISPs (con la política de contener las incidencias dentro de un mismo Data Center) más redundante que se puede desplegar, al existir al menos dos conexiones por edificio y cada una de ellas utilizar un ISP diferente, por lo que cada edificio estaría cubierto ante la caída completa de un ISP:
Ilustración 22 – Dos routers remotos y dos ISP en cada DC
Este es el mejor despliegue para obtener un balanceo de líneas y una gran redundancia, no obstante pueden existir problemas a la hora de la puesta en marcha, ya que los proveedores de servicio deben trabajar conjuntamente en su configuración, pues se requiere que equipos de un ISP se “hablen” con equipos de otro, así como que direccionamiento IP público adquirido a un ISP pueda ser accedido por el otro ISP. Esto puede plantear varios problemas políticos a la hora de las negociaciones con los proveedores.
Existe una posibilidad si es imposible que los equipos de un ISP y otro se hablen, y es incluir equipamiento propio que establezca a la vez las relaciones con cada uno de los routers de acceso de los ISPs (la conversación sería cliente-ISP, no ISP-ISP).
Existe una posibilidad si es imposible que los equipos de un ISP y otro se hablen, y es incluir equipamiento propio que establezca a la vez las relaciones con cada uno de los routers de acceso de los ISPs (la conversación sería cliente-ISP, no ISP-ISP).
En un diseño completamente aislado, las IPs de un Data Center no se publican en el otro pero, de ser necesario, por ejemplo por los problemas de refresco de los aplicativos que antes se han mencionado, es posible configurar otro esquema parecido pero en que se compartan IPs entre los dos Data Centers, aunque con la salvedad de no extender la red de interconexión externa (punto necesario en el esquema mostrado en el punto “Data Centers no aislados frente a incidencias”), lo cual eliminaría el riesgo de que algunos problemas se trasladasen de un edificio al otro aunque, de configurarse esa posible compartición de IPs, se daría pié a la existencia de alguna posibilidad de influir en el tráfico de ambos Data Centers con la configuración de equipos que estén situados solo en uno de ellos, por ejemplo, la configuración de BGP y la publicación de las IPs en Internet, por lo que no se llega al completo aislamiento de problemas que sí que existe en el esquema en el que cada centro tiene sus IPs propias.
A continuación se presentan los dos esquemas, uno en el que se comparten las IPs y otro en el que no. No se exponen, como se ha hecho en ejemplos anteriores, un despliegue activo-pasivo y uno activo-activo solo con protocolos de enrutamiento IGP, ya que para otorgar este nivel tan alto de redundancia y balanceo se requiere de por si la configuración de BGP.
Activo-Activo con BGP sin IPs publicas compartidas
Para este diseño, en el cual cada Data Center conserva su propio direccionamiento público y se mantienen controladas en un Data Center todas las incidencias de acceso, se ha de acordar con los ISPs las configuraciones a realizar en su equipamiento remoto. Para el equipamiento local existen dos posibilidades, que sean los propios ISPs quienes lo instalen, configuren y gestionen (generalmente uno de los dos ISPs contratados) o pueden ser propios, como en el ejemplo del siguiente esquema, lo que proporcionaría mayor flexibilidad a la hora de realizar cambios (no se ha de contar con el ISP) y no se tendría el problema de necesitar la comunicación de control ISP-ISP entre los routers de frontera, aunque también añadiría un punto más a tener en cuenta en la gestión de la infraestructura de red.
Ilustración 23 – Dos routers remotos y dos ISP en cada DC – Esquema global
La redundancia y balanceo que se pueden obtener con este despliegue son óptimos:
Ilustración 24 – Dos routers remotos y dos ISP en cada DC - Flujos
Para dejar más claro los flujos de entrada hasta el servicio para este caso concreto, se va a incluir en los siguientes esquemas el detalle de la información del flujo también detrás del firewall. En este caso se puede ver cómo una conexión a un servicio realizado desde Internet, es enrutada por el ISP1 hasta llegar al router frontera (ya situado en el Data Center). Este, a su vez, lo envía al clúster de firewalls, ya que posee esta ruta en su tabla debido a que ha sido recibida por las actualizaciones de OSPF lanzadas desde dichos firewalls.
Una vez recibida la conexión por el firewall, este realizará el NAT desde la IP pública a la IP privada, la cual podría, por ejemplo, ser una VIP publicada por un balanceador de Data Center. El balanceador, si el servicio está correctamente desplegado en ese mismo Data Center, lo enviará directamente (línea verde), mientras que si está en error o los servidores han sido desplazados al otro Data Center, lo reenviará mediante la interconexión de DC, teniendo en este caso que realizar un NAT de origen para que la vuelta sea gestionada por el mismo clúster de firewalls y balanceadores que recibieron la petición (si no el tráfico sería descartado).
Este balanceador, no tiene por qué ser un Hardware añadido, en realidad puede que sea un servicio del propio firewall o una virtualización de balanceador global por DNS.
Ilustración 25 – Dos routers remotos y dos ISP en cada DC – Conexiones hasta servicio
Al realizarse un NAT de origen, la información de la IP del cliente se enmascara, por lo que, debido a requisitos de seguridad, se almacenará dicha información ya sea mediante la realización de ficheros de log de los NATs realizados o, en el caso de las aplicaciones WEB, del uso de las cabeceas X-Forwarder-For u otro métodos que existen en diversos protocolos para hacer llegar la IP del cliente aunque se tenga que realizar NAT de la IP origen.
Todos los flujos de conexiones de entrada y salida serán vistos más adelante, cuando se traten los movimientos de máquinas entre edificios y la gestión de los fallos para proporcionar alta disponibilidad de la plataforma.
Todo estos flujos serían simplificados enormemente si, mediante un balanceador global, de detectase la localización de las máquinas situadas tras el balanceador y, de estar todas en el DC remoto, modificar la VIP a la que apuntan los clientes, para que estos realicen peticiones directamente al DC remoto, evitando el tráfico cruzado (linea azul) y el consiguiente traffic tromboning, tal y como se vio al principio de esta entrada.
Todo estos flujos serían simplificados enormemente si, mediante un balanceador global, de detectase la localización de las máquinas situadas tras el balanceador y, de estar todas en el DC remoto, modificar la VIP a la que apuntan los clientes, para que estos realicen peticiones directamente al DC remoto, evitando el tráfico cruzado (linea azul) y el consiguiente traffic tromboning, tal y como se vio al principio de esta entrada.
Activo-Activo con BGP con IPs publicas compartidas
Este punto muestra el mismo despliegue pero, en este caso, con la posibilidad de mantener las mismas IPs en los dos Data Centers:
Ilustración 26 – Dos routers remotos y dos ISP en cada DC sin aislamiento de IPs
Para logar esto, se utiliza también la inyección de rutas de las IPs públicas desde el clúster de firewalls mediante un protocolo de enrutamiento, OSPF en el ejemplo, el cual se comunicaría con los routers de frontera a través de una red de interconexión, diferente a las redes públicas que contienen las IPs de servicio, las cuales se encontrarán detrás de ambos firewalls.
Las IPs públicas anunciadas por los firewalls llegarán a los routers de frontera, los cuales anunciarán, mediante una actualización de BGP, su disponibilidad a ser enrutadas por parte del ISP.
Debido a que ambos edificios conservarían el mismo direccionamiento (como se ha explicado, para evitar los problemas del refresco de la IP de servicio en algunas aplicaciones), a los ISPs les llegarán los anuncios por diversos caminos (uno por cada Data Center), por lo que deberán gestionar mediante la configuración de BGP qué centro es el “primario” para esa IP/red. Esta configuración también puede realizarse en los routers de frontera, que si fuesen gestionados internamente en lugar de por el ISP, podrían modificar los “pesos” del lugar de residencia de la IP pública sin tener que contar con configuraciones hechas por el ISP, con la mejora de la flexibilidad ante cambios que eso aporta.
Según este esquema, en un estado normal de funcionamiento, todas las conexiones a una IP llegarán a un mismo Data Center (ya sea por un ISP u otro), mientas que solo llegarán al Data Center parejo en caso de un problema o de un cambio en la configuración de los “pesos” BGP:
Ilustración 27 – Dos routers remotos y dos ISP en cada DC sin aislamiento de IPs –Inyección de IP
Los “pesos”, para elegir una ruta frente a otra, pueden ser configurados de diversas maneras en el protocolo BGP, y este deberá ser un punto a discutir con los ISPs.
Según el esquema anterior, todos los accesos elegirían el centro de la izquierda para llegar a la IP1 en condiciones normales.
Si hubiese un fallo en la IP1 en el Data Center de la izquierda, la inyección de rutas de dicha IP en OSPF se detendría, con lo cual tampoco se haría en BGP, quedando solo la ruta a través del edificio de la derecha, tal y como se ven en el siguiente diagrama:
Ilustración 28 – Dos routers remotos y dos ISP en cada DC sin aislamiento de IPs –Inyección de IP II
Un punto importante a discutir también con los ISPs es el tiempo de refresco de BGP en el caso de dejar de inyectar la ruta por OSPF. Ese tiempo es el lapso que existe entre que la ruta se deja de inyectar en OSPF, y el tiempo que tarda BGP en actualizar, como ruta principal (y única) a la IP1, la conexión contra el edificio de la derecha. En el caso de que ese tiempo no fuese lo suficientemente reducido para los tiempos de parada debido a incidencia en los servicios, esta solución podría no ser válida.
Si el cambio de IP no se produjese por incidencia, sino porque por algún motivo se quisiese “mover”, de manera programada, una IP desde el centro en el que es primaria al otro DC, no habría tanto problema con los lapsos de tiempo, ya que se podrían cambiar los “pesos” BGP y continuar dando servicio, hasta que se actualice completamente la red de los ISPs, desde el Data Center origen.
Sobre este apartado, tan solo volver a incidir en que lo aquí mostrado es tan solo uno de los diseños posibles, y que siempre que se quiera realizar una conexión con ISPs, son los propios proveedores los que marcan las rutinas posibles en la conexión a sus redes, por lo que lo expuesto intenta ser tan solo una referencia a la hora de las negociaciones con dichos proveedores de conexión a Internet.
Data Centers no aislados frente a incidencias
El actual apartado hace referencia al tipo de conexión en el cual se dispone de enlaces redundados a ISPs diferentes en cada uno de los edificios pero, a diferencia de antes, ambos tienen las redes de interconexión externa extendidas, de manera que los accesos de cualquier router del borde exterior puede ser accedido por ambos clúster de firewalls, indistintamente del DC en el que se encuentren.
Este despliegue tiene la ventaja de que conserva la redundancia de ISPs, además de que se pueden compartir las IPs públicas en ambos Data Center, con mucha más sencillez que lo visto en el punto “Activo-Activo con BGP con IPs publicas compartidas” del apartado anterior.
Como contras, en comparación al esquema de Data Centers con las redes de acceso sin extender, es que pueden provocarse diversos problemas en uno de los DC y que estos afecten al parejo, como por ejemplo bucles, fallos de los protocolos FHRP, fallos en enrutamientos, etc.
Otro problema añadido con este despliegue aparecería en la incorporación de más Data Centers, ya que se complicaría el mantenimiento, existirían nuevos posibles problemas que podrían afectar a todos los DCs y añadiría mayor complejidad a la gestión, ya que habría que replicar las configuraciones de NATs de todas las IPs públicas, de todos los servicios, en el conjunto total de los clúster de firewalls de los Data Centers. En el caso de ser dos edificios únicamente puede suponer un trabajo adicional asumible, pero conforme el número de centros aumentase, la administración se complicaría exponencialmente.
No obstante, debido a la necesidad de compartir IPs públicas a lo largo de los Data Centers por la problemática comentada, y también teniendo en cuenta que este despliegue es menos complejo que el mostrado en “Activo-Activo con BGP con IPs publicas compartidas”, puede ser un esquema válido, a día de hoy, para dar acceso a los servicios en múltiples arquitecturas, aunque en primera instancia se prefiera un máximo aislamiento de las incidencias entre Data Centers.
Dos routers remotos y dos ISP acceso a DC extendido
A continuación se puede ver el esquema general de conectividad que se está comentando:
Ilustración 29 – Dos routers remotos y dos ISP en cada DC extendido
En este caso solo se muestra el caso de configuración con IGP, ya que en este esquema en concreto no es necesaria la complejidad añadida por BGP.
Activo-Activo con IGP con IPs publicas compartidas mediante extensión de LAN
Para el encaminamiento del tráfico de salida, entre otras soluciones, se puede configurar en los firewalls políticas PBR (o diferentes pesos con un protoclo IGP entre los routers de acceso del proveedor y los propios), de manera que todo aquellas respuestas a las peticiones que se cursaron hacia las IPs públicas de servicio del ISP1, sean devueltas al router de acceso de dicho ISP dentro del mismo Data Center, tal y como puede verse en este esquema:
Ilustración 30 – Dos routers remotos y dos ISP en cada DC extendido – Tráfico salida
Para añadir el componente de redundancia al del balanceo mostrado antes, en lugar de dirigir las rutas PBR hacia los switches físicos, se apuntarán a IPs virtuales de los protocolos FHRP que serían configurados por pares de routers, siempre incluyendo en un mismo grupo a routers de ISPs diferentes y situados en DC contrarios (ver ilustración anterior).
Siguiendo este método, se crearían dos grupos FHRP que serían: Router1_ISP1_DC1 contra Router1_ISP2_DC2, por un lado, y Router2_ISP1_DC1 contra Router2_ISP2_DC2 por el otro.
Para evitar tráficos cruzados (ya que el protocolo FHRP solo permite un router en modo activo a la vez), se crearían 4 grupos, 2 serían los comentados y los otros dos serían similares, pero con los pesos cambiados y que cada router fuese master en un grupo diferente.
Para representar este hecho en la ilustración anterior, se añade el nombre del grupo (FHRP_1, FHRP_2, FHRP_A o FHRP_B) más cerca del router que es master para ese grupo, y para mostrar el destino de las rutas PBR se añaden flechas naranjas hacia dichos nombres.
Con esa configuración se evita el tráfico cruzado, siempre y cuando no exista ninguna incidencia y, en caso de que existiese, se enviaría el tráfico al router del otro ISP en el otro Data Center.
Se podría haber elegido el Router del otro ISP en el mismo Data Center, pero de ese modo, aunque no existiese tráfico cruzado, no se estaría protegido ante un fallo total en el Data Center (por ejemplo que unas obras cortasen los cables de entrada al edificio).
También se podría haber optado por que en caso de fallo, los paquetes se enviasen al router del DC parejo pero que fuesen al mismo ISP, pero en este caso tampoco se estaría completamente protegido de incidencias, ya que si fallase completamente dicho ISP se perdería la conectividad.
Para el tráfico de entrada existen varios modos de lograr la redundancia, aunque la configuración final en todo caso será la de introducir en los routers de conexión a Internet dos rutas, una principal y otra backup, que sería utilizada solo en caso de la pérdida de la principal.
Este comportamiento se plasma en el diagrama siguiente marcando con una línea sólida la ruta principal y punteada la ruta backup.
Para introducir estas rutas se puede hacer uso de un protocolo de encaminamiento entre los clúster de firewalls y los routers de frontera, pudiendo de este modo hacer modificaciones sobre la el clúster de firewalls elegido como principal, lo que significaría mover las IPs de Data Center, sin tener que contar con los ISPs.
Para evitar, en la medida de lo posible, el tráfico cruzado, se debería acordar con los proveedores de acceso las preferencias de publicación de las rutas a las IPs públicas en su red mediante BGP, de manera que las IPs que fuesen a utilizarse, de manera habitual, en un Data Center, llegasen enrutadas por la red del ISP a los routers que se encuentran residentes en dicho Data Center, ya que si no el router lo deberá enviar a través del enlace interlink hasta el firewall que conserva la IP de servicio a la que se desea acceder en el Data Center parejo.
Ilustración 31 – Dos routers remotos y dos ISP en cada DC extendido – Tráfico entrada
Todo este diseño sería válido únicamente para la existencia de dos Data Centers. Si se incluyese un nuevo edificio habría que estudiar la incorporación de un protocolo IGP que eligiese tanto las rutas de salida como las de entrada.
Otro punto que podría ser estudiado, al disponer de una LAN extendida en el acceso, es la de formar entre los firewalls (en este ejemplo) un cluster extendido, es decir, que un miembro se encontrase en un DC y el otro en el DC parejo. Esto simplifica enormemente el traslado de las IPs entre los Data Centers pero incluye un punto único de fallo (el clúster) que afecta a ambos DCs, y también se tendría que tener presente las latencias entre DCs para el enlace de heartbeat, así como sopesar el mayor riesgo de split-brain dentro del cluster (ya que el heartbeat utiliza la WAN).
Otro punto que podría ser estudiado, al disponer de una LAN extendida en el acceso, es la de formar entre los firewalls (en este ejemplo) un cluster extendido, es decir, que un miembro se encontrase en un DC y el otro en el DC parejo. Esto simplifica enormemente el traslado de las IPs entre los Data Centers pero incluye un punto único de fallo (el clúster) que afecta a ambos DCs, y también se tendría que tener presente las latencias entre DCs para el enlace de heartbeat, así como sopesar el mayor riesgo de split-brain dentro del cluster (ya que el heartbeat utiliza la WAN).
