Diseño de la recuperación ante desastres
Virtual WAN le permite agregar, conectar, administrar centralmente y proteger todas las implementaciones globales. Las implementaciones globales pueden incluir cualquier combinación de distintas ramas, punto de presencia (PoP), usuarios privados, oficinas, redes virtuales de Azure y otras implementaciones multinube. Puede usar SD-WAN, VPN de sitio a sitio, VPN de punto a sitio y ExpressRoute para conectar los distintos sitios a un centro de conectividad virtual. Si tiene varios centros de conectividad virtuales, todos ellos se conectarían mediante una topología de malla completa en una implementación de Virtual WAN estándar.
En este artículo, vamos a analizar cómo diseñar diferentes tipos de opciones de conectividad de red como servicio que admite la Virtual WAN para la recuperación ante desastres.
Opciones de conectividad de red como servicio de la Virtual WAN
Virtual WAN admite las siguientes opciones de conectividad de back-end:
- Conectividad de usuarios remotos
- Rama/Office/SD-WAN/VPN de sitio a sitio
- Conectividad privada (emparejamiento privado de ExpressRoute)
Para cada una de estas opciones de conectividad, Virtual WAN implementa un conjunto independiente de instancias de puerta de enlace dentro de un centro de conectividad virtual.
Esencialmente, Virtual WAN está diseñado para ofrecer una solución de agregación de red de alta disponibilidad en el nivel del operador. Para lograr una alta disponibilidad, Virtual WAN crea instancias de varias instancias cada vez que uno de estos tipos diferentes de puertas de enlace se implementa en un centro de conectividad de Virtual WAN. Para más información sobre la alta disponibilidad de ExpressRoute, consulte Diseño de alta disponibilidad con ExpressRoute.
Con la puerta de enlace de VPN de punto a sitio, el número mínimo de instancias implementadas es dos. Con la puerta de enlace de VPN de punto a sitio, se elige la capacidad de rendimiento agregada de las puertas de enlace de punto a sitio y se aprovisionan automáticamente varias instancias. Se elige la capacidad agregada en función del número de clientes o usuarios que se pretende conectar al centro virtual. Desde la perspectiva de la conectividad del cliente, las instancias de VPN Gateway de punto a sitio se ocultan detrás del nombre de dominio completo (FQDN) de la puerta de enlace.
Para la instancia de VPN Gateway de sitio a sitio, se implementan dos instancias de la puerta de enlace en un centro de conectividad virtual. Cada una de las instancias de puerta de enlace se implementa con su propio conjunto de direcciones IP públicas y privadas. En la captura de pantalla siguiente se muestran las direcciones IP asociadas a las dos instancias de una configuración de VPN Gateway de sitio a sitio de ejemplo. En otras palabras, las dos instancias proporcionan dos puntos de conexión de túnel independientes para establecer la conectividad VPN de sitio a sitio desde las ramas. Para maximizar la alta disponibilidad, consulte Selección de rutas de acceso de Azure en varios vínculos de ISP.
Aumentar al máximo la alta disponibilidad de la arquitectura de red es un primer paso clave para la continuidad empresarial y la recuperación ante desastres (BCDR). En el resto de este artículo, como se indicó anteriormente, vamos a ir más allá de la alta disponibilidad y a analizar cómo diseñar la red de conectividad de Virtual WAN para BCDR.
Necesidad del diseño de la recuperación ante desastres
Un desastre puede producirse en cualquier momento y en cualquier lugar. Se puede producir un desastre en una red o región del proveedor de nube, en una red del proveedor de servicios o en una red local. El impacto regional en un servicio en la nube o de red debido a determinados factores como catástrofes naturales, errores humanos, guerras, terrorismo o configuraciones incorrectas, son difíciles de evitar. Por lo tanto, para la continuidad de las aplicaciones críticas para la empresa, debe tener un diseño de recuperación ante desastres. Para un diseño completo de la recuperación ante desastres, debe identificar todas las dependencias que posiblemente puedan producir un error en la ruta de comunicación de un extremo a otro y crear una redundancia que no se superponga para cada una de las dependencias.
Independientemente de si ejecuta sus aplicaciones críticas en una región de Azure, en una región local o en cualquier otro lugar, puede usar otra región de Azure como sitio de conmutación por error. En los siguientes artículos se explica la recuperación ante desastres desde las aplicaciones y las perspectivas de acceso de front-end:
- Recuperación ante desastres de escala empresarial
- Recuperación ante desastres de SMB con Azure Site Recovery
Desafíos del uso de conectividad redundante
Cuando interconecta el mismo conjunto de redes con más de una conexión, debe introducir rutas de acceso paralelas entre las redes. Las rutas de acceso paralelas, cuando no están correctamente diseñadas, podrían conducir a un enrutamiento asimétrico. Si tiene entidades con estado (por ejemplo, NAT, firewall) en la ruta de acceso, el enrutamiento asimétrico podría bloquear el flujo de tráfico. Normalmente, en la conectividad privada no encontrará entidades con estado, como NAT o Firewalls. Por lo tanto, el enrutamiento asimétrico mediante conectividad privada no tiene que bloquear necesariamente el flujo de tráfico.
Sin embargo, si equilibra la carga del tráfico entre rutas de acceso paralelas con redundancia geográfica, experimentaría un rendimiento de red incoherente debido a la diferencia en la ruta de acceso física de las conexiones paralelas. Por lo tanto, es necesario tener en cuenta el rendimiento del tráfico de red durante un estado estable (estado de no error) y durante un estado de error, como parte de nuestro diseño de recuperación ante desastres.
Acceso a la redundancia de red
La mayoría de los servicios de SD-WAN (soluciones administradas o de otro tipo) proporcionan conectividad de red mediante varios tipos de transporte (por ejemplo, banda ancha de Internet, MPLS, LTE). Para protegerse frente a errores de la red de transporte, elija conectividad a través de más de una red de transporte. En un escenario de un usuario doméstico, se puede considerar el uso de la red móvil como copia de seguridad para la conectividad de red de banda ancha.
Si no es posible la conectividad de red a través de un tipo de transporte diferente, elija conectividad de red a través de más de un proveedor de servicios. Si va a obtener conectividad mediante más de un proveedor de servicios, asegúrese de que los proveedores de servicios mantengan redes de acceso independientes que no se superpongan.
Consideraciones sobre la conectividad de los usuarios remotos
La conectividad de usuario remota se establece mediante VPN de punto a sitio entre un dispositivo final a una red. Después de un error de red, el dispositivo final se anularía y se intentaría restablecer el túnel VPN. Por lo tanto, para la VPN de punto a sitio, el diseño de recuperación ante desastres debe tener como objetivo minimizar el tiempo de recuperación después de un error. La siguiente redundancia de red ayudaría a minimizar el tiempo de recuperación. Dependiendo de la importancia de las conexiones, puede elegir algunas o todas estas opciones.
- Acceso a la redundancia de red (se ha descrito anteriormente).
- Administración de un centro de conectividad virtual redundante para la terminación VPN de punto a sitio. Cuando tiene varios centros de conectividad virtuales con puertas de enlace de punto a sitio, VWAN proporciona un perfil global que enumera todos los puntos de conexión de punto a sitio. Con el perfil global, los dispositivos finales podrían conectarse al centro de conectividad virtual más cercano disponible que ofrece el mejor rendimiento de red. Si todas las implementaciones de Azure están en una sola región y los dispositivos finales que se conectan están cerca de esta, puede tener centros de conectividad virtuales redundantes dentro de la región. Si la implementación y los dispositivos finales se reparten entre varias regiones, puede implementar un centro de conectividad virtual con una puerta de enlace de punto a sitio en cada una de las regiones seleccionadas. La Virtual WAN cuenta con un administrador de tráfico integrado que selecciona automáticamente el mejor hub para la conectividad de los usuarios remotos.
En el diagrama siguiente se muestra el concepto de administración del centro de conectividad virtual redundante con su puerta de enlace de punto a sitio respectiva dentro de una región.
En el diagrama anterior, las líneas verdes muestran las principales conexiones VPN de punto a sitio y las líneas amarillas discontinuas muestran las conexiones de copia de seguridad en espera. El perfil global de punto a sitio de VWAN selecciona conexiones principales y de copia de seguridad según el rendimiento de la red. Consulte Descarga de un perfil global para clientes VPN de usuario para más información sobre perfiles globales.
Consideraciones sobre la VPN de sitio a sitio
Veamos el ejemplo de conexión VPN de sitio a sitio que se muestra en el diagrama siguiente para nuestra explicación. Para establecer una conexión VPN de sitio a sitio con túneles activo-activo de alta disponibilidad, consulte Tutorial: Creación de una conexión de sitio a sitio mediante Azure Virtual WAN.
Nota
Para facilitar la comprensión de los conceptos que se analizan en la sección, no vamos a repetir la explicación de la característica de alta disponibilidad de VPN Gateway de sitio a sitio que le permite crear dos túneles a dos puntos de conexión diferentes para cada vínculo VPN que configure. Sin embargo, al implementar cualquiera de las arquitecturas sugeridas en la sección, no olvide configurar dos túneles para cada vínculo que establezca.
Topología de varios vínculos
Para protegerse frente a errores del equipo local del cliente (CPE) VPN en un sitio de la rama, puede configurar vínculos VPN paralelos a una instancia de VPN Gateway desde dispositivos CPE paralelos en el sitio de la rama. Además de protegerse frente a errores de red de un proveedor de servicios de recta final de la sucursal, puede configurar diferentes vínculos VPN a través de una red de proveedores de servicios diferente. En el diagrama siguiente se muestran varios vínculos VPN que se originan en dos CPE diferentes de un sitio de rama que finalizan en la misma instancia de VPN Gateway.
Puede configurar hasta cuatro vínculos a un sitio de rama desde una puerta de enlace de VPN del centro de conectividad virtual. Al configurar un vínculo a un sitio de la rama, puede identificar el proveedor de servicios y la velocidad de rendimiento asociada al vínculo. Al configurar vínculos paralelos entre un sitio de la rama y un centro de conectividad virtual, la puerta de enlace de VPN equilibra de forma predeterminada la carga del tráfico entre los vínculos paralelos. El equilibrio de carga del tráfico se realizaría de acuerdo con el enrutamiento multidireccional de igual costo (ECMP) por flujo.
Topología de varios vínculos y varios centros de conectividad
La topología de varios vínculos protege frente a varios errores de dispositivos CPE y frente a un error de red del proveedor de servicios en la ubicación de la rama local. Además, para protegerse frente a cualquier tiempo de inactividad de una puerta de enlace de VPN del centro de conectividad virtual, la topología de varios vínculos y varios centros de conectividad sería útil. En el diagrama siguiente se muestra la topología, en la que se configuran varios centros virtuales en una instancia de Virtual WAN dentro de una región:
En la topología anterior, dado que la latencia dentro de la región de Azure sobre la conexión entre los centros de conectividad es insignificante, puede usar todas las conexiones VPN de sitio a sitio entre el entorno local y los dos centros de conectividad virtuales en estado activo-activo mediante la distribución de las redes virtuales radiales entre los centros de conectividad. En la topología, de forma predeterminada, el tráfico entre el entorno local y una red virtual radial atravesaría directamente el centro de conectividad virtual al que está conectada la red virtual radial durante un estado estable y usaría otro centro de conectividad virtual como copia de seguridad solo durante un estado de error. El tráfico atravesaría directamente el centro conectado en un estado estable, ya que las rutas BGP anunciadas por el centro conectado directamente tendrían una ruta de acceso AS más corta en comparación con el centro de conectividad de copia de seguridad.
La topología de varios vínculos y varios centros de conectividad protege y proporciona continuidad empresarial frente a la mayoría de los escenarios de error. No obstante, si un error catastrófico afecta a toda la región de Azure, necesitará una "topología multirregional de varios vínculos" para resistir el error.
Topología multirregional de varios vínculos
La topología multirregional de varios vínculos protege incluso contra un error catastrófico que afecta a toda una región, además de las protecciones que ofrece la topología de varios vínculos y varios centros de conectividad que hemos analizado anteriormente. En el diagrama siguiente se muestra la topología multirregional de varios vínculos. Los centros virtuales de diferentes regiones se pueden configurar en la misma instancia de Virtual WAN.
Desde el punto de vista de la ingeniería del tráfico, debe tener en cuenta una diferencia sustancial entre tener centros de conectividad redundantes dentro de una región y tener el centro de conectividad de copia de seguridad en otra región. La diferencia es la latencia resultante de la distancia física entre las regiones primaria y secundaria. Por lo tanto, es posible que desee implementar los recursos de servicio con un estado estable en la región más cercana a los usuarios finales o a la rama, y usar la región remota exclusivamente para la copia de seguridad.
Si las ubicaciones de las ramas locales se distribuyen entre dos o más regiones de Azure, la topología multirregional de varios vínculos sería más eficaz para distribuir la carga y obtener una mejor experiencia de red durante el estado estable. En el diagrama siguiente se muestra una topología multirregional de varios vínculos con ramas en regiones diferentes. En este escenario, la topología proporcionaría además una continuidad empresarial y recuperación ante desastres (BCDR) eficaz.
Consideraciones sobre ExpressRoute
Las consideraciones sobre la recuperación ante desastres para el emparejamiento privado de ExpressRoute se analizan en Diseño para la recuperación ante desastres con el emparejamiento privado de ExpressRoute. Como se indica en el artículo, los conceptos descritos en él se aplican igualmente a las puertas de enlace de ExpressRoute creadas dentro de un centro de conectividad virtual. El uso de un centro de conectividad virtual redundante dentro de la región, como se muestra en el diagrama siguiente, es la única mejora de topología recomendada en Opciones de la red local pequeña a mediana.
En el diagrama anterior, ExpressRoute 2 finaliza en una puerta de enlace de ExpressRoute independiente dentro de un segundo centro de conectividad virtual dentro de la región.
Pasos siguientes
En este artículo, se ha analizado el diseño de recuperación ante desastres de Virtual WAN. En los siguientes artículos se explica la recuperación ante desastres desde las aplicaciones y las perspectivas de acceso de front-end:
- Recuperación ante desastres de escala empresarial
- Recuperación ante desastres de SMB con Azure Site Recovery
Para crear una conectividad de punto a sitio con Virtual WAN, consulte Tutorial: Creación de una conexión VPN de usuario mediante Azure Virtual WAN. Para crear una conectividad de sitio a sitio con Virtual WAN, consulte Tutorial: Creación de una conexión de sitio a sitio mediante Azure Virtual WAN. Para asociar un circuito de ExpressRoute a Virtual WAN, consulte Tutorial: Creación de una asociación de ExpressRoute mediante Azure Virtual WAN.