"En esta entrada se presentan algunos de los problemas y soluciones cuando se necesita realizar un diseño que permita el movimiento de máquinas virtuales entre DCs, para lo cual se desglosan una serie de casos dentro de una arquitectura de red de ejemplo"
La arquitectura de ejemplo se compone de dos centros, los cuales poseen conectividad L3 y L2 entre ellos. También se incluyen balanceadores globales y locales.
La topología de conexión externa con los ISPs de la arquitectura de ejemplo no se encuentra extendida, ni tampoco se cuenta con la posibilidad de migrar una IP pública de un DC al otro (ver esta otra entrada en el blog sobre ejemplos de conectividad con ISPs), por lo que la única manera de balancear las peticiones externas es mediante un balanceador global o GSLB.
A continuación se expondrán algunos ejemplos de movimientos de servicios activo-pasivo en una arqutectura de varios Data Centers. El hecho de que sea activo-pasivo y no activo-activo es debido a que la complejidad de los movimientos de máquinas virtuales con este tipo de servicios es mucho mayor que si se tratase de activo-activo.
La topología de conexión externa con los ISPs de la arquitectura de ejemplo no se encuentra extendida, ni tampoco se cuenta con la posibilidad de migrar una IP pública de un DC al otro (ver esta otra entrada en el blog sobre ejemplos de conectividad con ISPs), por lo que la única manera de balancear las peticiones externas es mediante un balanceador global o GSLB.
A continuación se expondrán algunos ejemplos de movimientos de servicios activo-pasivo en una arqutectura de varios Data Centers. El hecho de que sea activo-pasivo y no activo-activo es debido a que la complejidad de los movimientos de máquinas virtuales con este tipo de servicios es mucho mayor que si se tratase de activo-activo.
Para simplificar la explicación, se considerarán únicamente dos DCs, aunque lo aquí expuesto se puede extender a más localizaciones.
Para el ejemplo expuesto, las IPs internas publicadas de servicio serán diferentes (ya que esto facilita el diseño), y para ello se disponen de dos métodos:
1. Tener un pool de servidores publicados tras una VIP balanceada (diferente en cada edificio).
En este caso existen dos vertientes, aquella en la que se necesite que la LAN de los servidores que conforman el pool sea extendida, porque se necesite una comunicación entre ellos, y el otro caso en el que dicha extensión no sea necesaria.
Normalmente los servidores de un mismo pool no tienen por qué contactar unos con otros así que en la mayoría de los casos no se tendrá por qué extender la LAN
Si se necesitase extender la LAN se deberán filtrar las monitorizaciones de los balanceadores entre los dos DCs, ya que si no, aunque los servidores estuviesen en el otro edificio, el balanceador los seguiría viendo localmente conectados.
En el primer ejemplo la LAN no está extendida así que en cuanto los servidores se mueven el balanceador dejará de tener visibilidad sobre ellos.
En el segundo ejemplo, para lograr la pérdida de visibilidad, se deberán filtrar con ACLs de VLAN, las monitorizaciones de los balanceadores entre los diferentes DCs.
Ilustración 1 – Ejemplo de movimiento de servidores de pool sin VLAN extendida
Ilustración 2 – Ejemplo de movimiento de servidores de pool con VLAN extendida
2. Realizar un NAT de las IP de servicio si no se encuentran en el DC local
Este tipo de tratamiento ya se deberá enmascarar la IP real por una IP de NAT para que se puedan distinguir los dos entornos (servicio en local o servicio en DC remoto).
Es importante resaltar que para estos ejemplos la IP que debe ser diferente es la IP publicada de servicio, no la IP del servidor interno.
En este apartado se exponen dos diseños atendiendo a los dos tipos de política que se puede adoptar en lo referente al movimiento de servicios activo-pasivo:
1. Política de permitir el tráfico cruzado permanente (traffic tromboning)
Cuando un servicio se mueve de un DC a otro, para poder llegar a él desde la misma IP pública, se ha de realizar un tráfico cruzado entre los edificios.
Esta primera política permitiría que se realizase este tráfico de forma permanente, tal vez porque se disponga de suficiente ancho de banda entre los DCs y se desee una máxima sencillez de la arquitectura.
2. Política de no permitir el tráfico cruzado permanente
El que no existan tráficos cruzados de servicio entre DCs, es decir, que el servicio final no esté alojado en el mismo Data Center que la IP pública a la que el cliente ha hecho la petición, puede necesitarse debido a que se quiera optimizar el uso de los enlaces entre DCs, de manera que se utilicen lo mínimo posible (tal vez para reducir el número de enlaces y minimizar su coste), o simplemente por facilitar la gestión y el troubleshooting o para garantizar una mayor interdependencia de entre los data Centers.
Una gran diferencia entre los dos despliegues es que, en el primero de ellos, donde se permite el tráfico cruzado, existirá el concepto de “residencia”, es decir, el lugar donde un servicio debería localizarse en condiciones normales de trabajo. Al mover un servicio residente en un DC es cuando surge el tráfico cruzado permanente.
En el diseño en el que no hay tráfico cruzado, ya no se deberá definir el lugar de residencia de ningún servicio, ya que la arquitectura se adaptará para evitar el tráfico cruzado, haciéndola “residente” en el nuevo Data Center al que ha sido movido.
Con tráfico cruzado en VLAN extendida permitido
Para estudiar este diseño, se mostrarán los diversos tipos de tráfico que pueden existir dentro de la arquitectura.
Tráfico dentro de la misma VLAN
No hace falta entrar en mucho detalle sobre este tipo de tráfico, ya que al ser una VLAN extendida, la comunicación se realiza directamente a nivel L2 entre los dos servidores:
Ilustración 3 – Conexión L2 entre dos servidores por VLAN extendida
Tráfico desde el servidor a redes externas
El diseño en esta solución en el que se permite el tráfico cruzado es simple, cada lugar de residencia tendrá asociado un default Gateway. De este modo, y según el esquema de la página siguiente, una máquina residente en DC1 tendrá como default Gateway la VIP 1, mientras que una residente en DC2 tendrá la VIP 2.
Al mover la máquina/servicio a otro DC, esta seguirá conservando el Default Gateway de su lugar de residencia, por lo que el tráfico de salida seguirá alcanzando al mismo clúster de firewalls, como se comprueba en el segundo esquema de la página siguiente:
Ilustración 4 – Salida con tráfico cruzado permitido I
Ilustración 5 – Salida con tráfico cruzado permitido II
Tráfico desde redes externas al servidor
El problema con el tráfico entrante es que, si por ejemplo un usuario conectado a las redes internas intenta realizar una conexión a un servicio que no está situado localmente sucederá lo siguiente:
1. La petición del usuario se encamina hacia la LAN con el direccionamiento del servidor a través del clúster de firewalls locales
2. Al estar la VLAN extendida, la petición llega al servidor que está situado en el otro DC
3. El servidor responde al usuario enviando la respuesta a su default Gateway, el clúster de firewalls donde es residente
4. El clúster, al no tener constancia del comienzo de la sesión (ya que transcurrió por el clúster del DC parejo) bloquea la comunicación.
Ilustración 6 – Problema de las respuestas asimétricas
El flujo que se necesitaría para que este tipo de conexión no fuese rechazada sería el siguiente:
Ilustración 7 – Solución al problema de las respuestas asimétricas
Para logar esto, se necesita que el enrutamiento que se produce en el Data Center de origen (DC2 en este ejemplo), reenvíe la petición de conexión a través del clúster de firewalls remoto, en lugar del local. Por ello debe ser capaz de distinguir el tramo de LAN extendida que es local a su propio DC del que está situado en el Data Center remoto (DC1).
Ya que las máquinas virtuales que se rigen bajo este esquema deben tener un lugar de residencia predeterminado, una solución simple para lograrlo es subdividir la LAN en dos redes diferenciadas por la máscara de red, y asignar a cada servidor el tramo de red concreto del Data Center en el que tengan que ser residentes.
Siguiendo el ejemplo de la página siguiente, una máquina residente en DC2, deberá tener configurado como default Gateway la VIP 2 (clúster de firewalls de DC2) y como dirección IP propia una de la segunda mitad de la red LAN, por ejemplo, si la red tuviese una máscara de red de 24, para estar en el segundo tramo deberá tener una IP acabada en el rango [129 - 254], que corresponde con la segunda subred con máscara 25 extraída de la red original (máscara 24).
Es importante que para conservar la posibilidad que presta la VLAN extendida de comunicar directamente mediante L2 los servidores de diferentes Data Centers (que sería al objetivo por el cual extender la LAN), los servidores deben conservar la máscara real, para el ejemplo comentado antes la máscara debería ser 24, mientras que son los firewalls los que deben anunciar rutas a sus respectivas redes con máscara 25.
Un punto problemático a la hora de desplegar este diseño, en el cual se permite el tráfico permanente de red, y se implementa esta distinción de redes, es que se ha de tener en cuenta el número de DCs que se posee o se va a poseer, ya que habrá que subdividir la LAN en tantos tramos como DCs existan.
En este caso, al haber dos edificios únicamente, la LAN se ha podido diferenciar como 1º mitad y 2º mitad, pero si se tuviese en proyecto añadir un nuevo DC, la LAN se debería dividir en tres.
Ilustración 8 – Ejemplos de accesos a servicios según la localización I
Ilustración 9 – Ejemplos de accesos a servicios según la localización II
Ilustración 10 – Ejemplos de accesos a servicios según la localización III
Con tráfico cruzado en VLAN extendida NO permitido
Este tipo de diseño es más difícil de implementar, pero garantiza que los flujos de tráficos siempre estarán optimizados a largo plazo, es decir, no existirán tráficos cruzados entre los DCs de manera permanente, aún con fallos o movimientos de máquinas que mantienen servicios activo-pasivo.
Para realizar este despliegue es necesaria la utilización de la capa intermedia que decida el DC destino, a modo de balanceo local de Data Centers. En los próximos esquemas esta capa aparecerá como "Solución LB de DC" y al final de la entrada se expondrán algunas alternativas para implementarla.
Tráfico dentro de la misma VLAN
Sobre el tráfico en la misma LAN no hay ninguna diferencia con el punto “Con tráfico cruzado en VLAN extendida permitido”, los servidores dentro de la misma LAN accederán vía L2 directamente entre ellos, independientemente del DC en el que se encuentren alojados.
Tráfico desde el servidor a redes externas
En este diseño no existe el concepto de “residencia” de una máquina, por lo que no puede haber parámetros vinculados a ella (en contraposición de las IPs y default Gateways que se debían configurar en las máquinas ejemplo del punto anterior), es por ello que la configuración de red de los servidores será independiente del lugar en donde se encuentren.
Según lo anterior, el default Gateway, así como el resto de parámetros de red configurados en los servidores serán los mismos.
Si se necesitase crear IPs virtuales entre los Gateway del mismo DC (para aumentar la HA), en el ejemplo mostrado los clúster de firewalls, se deberá crear un grupo FHRP en cada DC, pero presentando la misma IP virtual de Gateway a los servidores.
Ya que la LAN se encuentra extendida, será necesario bloquear las actualizaciones de los grupos FHRP que no sean locales a cada DC, ya que si no se detectaría la IP duplicada.
Según el despliegue anterior, cuando la máquina se mueva de un centro al otro, comenzará a enviar el tráfico de salida al clúster de firewalls más próximo, es decir, que el que sea local a su nueva situación, impidiendo el tráfico cruzado de salida.
Se puede ver un ejemplo de la configuración descrita en los siguientes dos esquemas de red.
Ilustración 11 – Salida con tráfico cruzado no permitido I
Ilustración 12 – Salida con tráfico cruzado no permitido II
Tráfico desde redes externas al servidor
Para gestionar el tráfico desde el exterior de manera que se evite el tráfico cruzado de manera permanente hay que realizar dos tareas principales:
1. Redirigir los clientes a la nueva IP Pública del servicio que esté situada de manera local al servicio interno activo
De este primer punto se encarga el balanceador global, el cual redirige a los clientes:
Ilustración 13 – Monitorización del balanceador global
2. Manejar el tráfico de clientes cacheados para que estos no sufran una pérdida continuada de servicio debido a la incapacidad de la aplicación de refrescar la IP pública de servicio.
Para esto se utilizará el balanceador local de Data Centers, de manera que aunque los usuarios no refresquen la IP pública, internamente el flujo de tráfico se redirigirá al punto correcto donde el servicio está activo.
Durante el periodo de tiempo en el que los usuarios sigan cacheados a la antigua IP pública existirá tráfico cruzado, pero a lo largo pase el tiempo, los usuarios dejarán de realizar peticiones a esa IP y se redirigirán a la nueva:
Ilustración 14 – Diferencia entre tráfico de aplicaciones de aplicaciones cacheadas y refrescadas I
Hay que recordar nuevamente que el NAT de la IP real del servicio es solo necesario si se tiene la misma IP de servicio en ambos DCs. En la mayoría de los servicios la realidad será que la IP es diferente (estará tras un balanceador), y por tanto el esquema que se tendrá es el siguiente:
Ilustración 15 – Diferencia entre tráfico de aplicaciones de aplicaciones cacheadas y refrescadas II
Movimiento con herramientas de orquestación
Existen otros medios para manejar los movimientos de máquinas virtuales a lo largo de la infraestructura y garantizar los flujos de manera optimizada.
Uno adicional a los ya mostrados sería la utilización de Software de orquestación que permitiese reconfiguraciones dinámicas de los equipos de red, dependiendo de la situación física de la máquina virtual así como de su estado.
Estos Software, monitorizarían parámetros de red y de la plataforma de virtualización y, atendiendo a las repuestas y a los cambios que se puedan introducir en la configuración de las máquinas virtuales, podrían modificar al vuelo la configuración de red de las máquinas virtuales, haciendo que una máquina que en el DC 1 tenía una IP y un default Gateway definidos, cuando se mueva al DC 2, tenga otra IP y otro Gateway.
Gracias a estos Software se podría simplificar el despliegue de las soluciones comentadas en este apartado, así como utilizando arquitecturas Software Defined Network (SDN).
Alternativas para implementación de balanceo local de DC
En este apartado se presentan algunas alternativas de diseño para dar solución al balanceo local de DC (necesario para dar servicio a los usuarios cacheados, tal y como se ha visto anteriormente).
Es importante que, para dimensionar la solución de balanceo local de DCs, se tengan definidos los servicios que deberán hacer uso de él ya que, aunque se podría utilizar para todos los servicios, esto podría hacer que los equipos que gestionan ese balanceo sean más costosos, ya que deberán manejar todas las conexiones de un Data Center.
Es por ello que se recomienda hacer el dimensionamiento para el caso de que manejen todas las conexiones y para el que solo lo hagan de unos cuantos tipos de tráfico y comprobar si existe un aumento de coste asumible en el primero de los casos.
Cuando se habla de plataforma de balanceo local de Data Center, en realidad no tiene por qué ser un balanceador físico, sino que hay varias opciones, siempre dependiendo del equipamiento disponible:
1. Balanceo en firewalls de acceso
Muchos de los actuales firewalls también proporcionan un servicio básico de balanceo, el cual puede ser utilizado para realizar este trabajo de balanceo de DCs de manera local:
Ilustración 16 – Balanceo local de Data Center en los firewalls de acceso
2. Balanceo local de DC en los balanceadores globales
Los balanceadores globales también suelen ser capaces de realizar tareas de balanceo local, por lo que pueden ser utilizados para este fin, no obstante, ya que deberán proporcionar también la función de balanceo global y para ello deberían estar en la DMZ externa, puede que se deba configurar un PBR para que las peticiones del balanceo local de DCs lleguen a estos equipos.
Ilustración 17 – Balanceo local de Data Center en los balanceadores globales
3. Balanceo local de DC en los balanceadores globales virtualizados
Si los balanceadores globales, aparte de permitir el balanceo local, tuviesen también la capacidad de virtualizarse, se podrían obtener unos balanceadores virtualizados para realizar el trabajo del balanceo local de DC. En el siguiente ejemplo se han situado in-line, pensando en hacer uso de ellos para todas las conexiones, no obstante si solo se requiriese este tipo de balanceo para unos cuantos servicios se podrían desplegar fuera de línea mediante PBR u otro mecanismo, al igual que se haría con un balanceador físico:
Ilustración 18 – Balanceo local de Data Center en balanceadores globales virtualizados
4. Balanceo local de DC en balanceadores dedicados
Aunque existen más posibilidades, esta es la última que se comentará, y es la adquisición de nuevo Hardware destinado únicamente al balanceo local de DC:
Ilustración 19 – Balanceo local de Data Center en balanceadores físicos
No hay comentarios:
Publicar un comentario