Vía de diseño de redes lift-and-shift

En esta guía se proporciona una ruta de lectura secuenciada a través de la Guía de diseño de redes de Azure para los clientes que migran cargas de trabajo locales a Azure Infraestructura como servicio (IaaS) sin volver a diseñar aplicaciones. Siga los pasos numerados para crear su red desde cero y tomar las decisiones adecuadas en cada etapa.

Overview

Una migración de tipo lift-and-shift traslada las cargas de trabajo existentes del entorno local a máquinas virtuales de Azure (VM) con cambios mínimos en la arquitectura de la aplicación. Las aplicaciones mantienen sus patrones de comunicación, dependencias y configuraciones existentes. La red que compila en Azure debe admitir estos patrones existentes mientras aprovecha los servicios de conectividad y seguridad nativos de Azure.

Tu arquitectura de destino es una topología hub-and-spoke con servicios compartidos centralizados. Una sola red virtual central (VNet) aloja la conexión de VPN Gateway o ExpressRoute de vuelta al entorno local, Azure Bastion para el acceso seguro a máquinas virtuales, Azure Firewall para la inspección centralizada del tráfico y el reenvío de DNS. Las VNet spoke hospedan las máquinas virtuales de las cargas de trabajo migradas, aisladas entre sí de forma predeterminada y conectadas a través del hub para la comunicación entre cargas de trabajo.

Esta ruta de lectura le lleva a través de 10 artículos esenciales en cinco fases. Cada artículo se basa en las decisiones que ha tomado en el paso anterior. Al final, dispondrá de un diseño de red listo para producción que admite sus cargas de trabajo migradas con seguridad y conectividad de defensa en profundidad.

Prerequisites

  • Lea la introducción a la planificación y el diseño de redes de Azure para orientarse sobre los servicios disponibles y la estructura de la guía.
  • Complete un inventario de la red local existente: intervalos IP, subredes, reglas de firewall, zonas DNS y flujos de tráfico entre aplicaciones (hará referencia a este inventario en los artículos fundamentales: redes virtuales y subredes, planeamiento de direcciones IP y configuración de NSG).
  • Identifique las cargas de trabajo que planea migrar primero. Comience con un grupo piloto antes de migrar todo su entorno.
  • Documente los requisitos de conectividad local: ancho de banda para Azure, sensibilidad de latencia y expectativas de conmutación por error.

Ruta de lectura

Siga estas fases en este orden. Cada fase se basa en las decisiones del anterior.

Fase 1: Fundamentos

Comience con los tres artículos fundamentales. Estas decisiones dan forma a todo lo que sigue.

1. Redes virtuales y subredes

Cree la red virtual que hospeda las máquinas virtuales migradas. Asigna los segmentos de red existentes en subredes de Azure. Céntrese en los límites de aislamiento de subred: qué cargas de trabajo comparten una subred, que necesitan sus propias direcciones IP y cuántas direcciones IP necesita cada subred en función del recuento de máquinas virtuales.

2. Planificación de direcciones IP

Evite la superposición de IP con el entorno local. Utiliza un bloque de direcciones CIDR (enrutamiento entre dominios sin clases) de clase /16 por VNet para dejar margen de crecimiento. Si los rangos locales se superponen con las direcciones reservadas de Azure o con otras suscripciones de Azure, planifique una estrategia de reasignación de direcciones antes de migrar.

3. Grupos de seguridad de red y grupos de seguridad de aplicaciones

Replica tus reglas de firewall existentes como grupos de seguridad de red (NSG). Convierte tus listas de control de acceso (ACL) locales en reglas de NSG con una directiva de denegación por defecto. Use grupos de seguridad de aplicaciones (ASG) para agrupar máquinas virtuales por rol en lugar de administrar direcciones IP individuales.

Fase 2: Topología

4. Topología hub-and-spoke

La topología hub-and-spoke es la predeterminada para las migraciones de tipo lift-and-shift de múltiples cargas de trabajo. Coloque servicios compartidos en la red virtual del concentrador: VPN Gateway, Azure Bastion, Azure Firewall y reenviadores DNS. Cada carga de trabajo dispone de su propia VNet spoke conectada al hub. Las redes spoke se comunican a través del firewall del hub, lo que te permite un control centralizado del tráfico.

Fase 3: Conectividad

5. Conectividad híbrida

La VPN Gateway o Azure ExpressRoute hacia el entorno local es tu dependencia más crítica para la migración. Sin esta conexión, las máquinas virtuales migradas no pueden acceder a los servicios locales de los que dependen y los usuarios no pueden acceder a las aplicaciones migradas. Dimensione el ancho de banda de la puerta de enlace en función de los patrones de tráfico que ha documentado en su inventario.

6. Acceso de desarrollador y administrador

Azure Bastion proporciona acceso seguro Escritorio remoto Protocol (RDP) y Secure Shell (SSH) a las máquinas virtuales migradas sin exponerlas a la red pública de Internet. Implemente Bastion en la VNet central para que todas las redes periféricas compartan un único punto de acceso. Sustituya su infraestructura actual de jump boxes por este servicio gestionado.

Fase 4: Seguridad

7. Seguridad DNS y resolución de nombres privados

Conserve el comportamiento de nomenclatura de DNS heredado durante la migración. Las máquinas virtuales migradas deben resolver los nombres de host del entorno local, y los sistemas del entorno local deben resolver los nombres alojados en Azure. Configurar el Resolutor privado de Azure DNS para el reenvío bidireccional. Mantenga las convenciones de nomenclatura dns existentes para evitar la reconfiguración de la aplicación.

8. Acceso saliente a Internet

Centralice todo el tráfico saliente de Internet a través del firewall del concentrador. Desactive el acceso saliente predeterminado en sus VNet spoke y enrute el tráfico saliente a través de Azure Firewall utilizando rutas definidas por el usuario (UDR). Este enfoque refleja el modelo local existente en el que un firewall perimetral controla todo el tráfico enlazado a Internet.

9. Azure Firewall

Implemente Azure Firewall en la VNet hub para un control centralizado del tráfico este-oeste (entre spokes) y norte-sur (saliente). Convierta las directivas de firewall locales en reglas de Azure Firewall. Use reglas de red para el tráfico no HTTP y reglas de aplicación para el filtrado de HTTP/HTTPS con destinos con nombre de dominio completo (FQDN).

Fase 5: Operaciones

10. Supervisión de red y observabilidad

Configure Azure Network Watcher y Connection Monitor para validar la línea base de migración. Compruebe que las rutas de acceso de conectividad funcionan según lo previsto. Mida la latencia entre las máquinas virtuales de Azure y los sistemas locales y establezca pruebas comparativas de rendimiento antes de migrar las cargas de trabajo de producción.

Artículos condicionales

No todas las migraciones de tipo lift-and-shift necesitan el mismo conjunto de artículos. Incluya estos artículos en función de sus requisitos específicos:

Condition Artículo Cuándo incluir
Aplicación accesible desde Internet Entrada de Internet La aplicación migrada debe ser accesible desde Internet.
Se necesita balanceo de carga de capa 7 (L7) Entrega y rendimiento de aplicaciones La carga de trabajo necesita Azure Application Gateway o Azure Front Door
Aplicación web pública Firewall de aplicaciones web La aplicación migrada atiende el tráfico HTTP/HTTPS público.
Exposición pública de la IP Protección contra DDoS Tiene requisitos de tiempo de actividad para recursos con puntos de conexión públicos
Se necesita varias regiones Redes de varias regiones Se requiere recuperación ante desastres o despliegue activo-activo
Conectividad entre regiones Conectividad entre regiones y multinube Otras regiones u otras nubes están incluidas en el ámbito de aplicación
Tránsito a escala de sucursal Azure Virtual WAN Tiene muchas sucursales o puntos de conectividad
Componentes de PaaS Acceso privado de PaaS Algunos componentes de carga de trabajo se mueven a los servicios paaS de Azure
Gran parque de VNet Administración de red centralizada La migración da lugar a un entorno de varias redes virtuales (VNet) que requiere una gobernanza centralizada.

Resumen

Siguiendo esta ruta de lectura, ha diseñado una red de tipo hub-and-spoke con servicios compartidos centralizados, ha establecido conectividad VPN o ExpressRoute con el entorno local, ha implementado Azure Firewall para la inspección centralizada del tráfico, ha configurado el reenvío de DNS para la resolución de nombres, ha protegido el acceso a las máquinas virtuales mediante Azure Bastion y ha configurado la supervisión para validar su migración. Esta arquitectura admite las cargas de trabajo migradas a la vez que proporciona visibilidad operativa y de seguridad centralizadas.

Pasos siguientes

  • Last updated on