Caminho de design de rede "lift-and-shift"

Este guia fornece um caminho de leitura sequenciado por meio do Guia de Design de Rede Azure para clientes que migram cargas de trabalho locais para Azure IaaS (Infraestrutura como Serviço) sem arquitetar aplicativos novamente. Siga as etapas numeradas para criar sua rede do zero, tomando as decisões certas em cada estágio.

Overview

Uma migração do tipo lift-and-shift transfere cargas de trabalho locais existentes para máquinas virtuais (VMs) do Azure com alterações mínimas na arquitetura da aplicação. Seus aplicativos mantêm seus padrões de comunicação, dependências e configurações existentes. A rede que você cria em Azure deve dar suporte a esses padrões existentes, aproveitando Azure serviços nativos de segurança e conectividade.

Sua arquitetura de destino é uma topologia em estrela (hub-and-spoke) com serviços compartilhados centralizados. Uma VNet (rede virtual) de hub único hospeda sua conexão Gateway de VPN ou ExpressRoute de volta ao local, Azure Bastion para acesso seguro à VM, Firewall do Azure para inspeção de tráfego centralizada e encaminhamento de DNS. As VNets em estrela hospedam suas VMs de carga de trabalho migradas, isoladas umas das outras por padrão e conectadas por meio do hub para comunicação entre cargas de trabalho.

Este caminho de leitura leva você a 10 artigos essenciais em cinco fases. Cada artigo baseia-se nas decisões tomadas na etapa anterior. No final, você tem um design de rede pronto para produção que dá suporte às cargas de trabalho migradas com segurança e conectividade de defesa em profundidade.

Pré-requisitos

  • Leia a visão geral do planejamento e do design de rede do Azure para se orientar sobre os serviços disponíveis e a estrutura do guia.
  • Conclua um inventário de sua rede local existente: intervalos de IP, sub-redes, regras de firewall, zonas DNS e fluxos de tráfego entre aplicativos (você fará referência a esse inventário nos artigos fundamentais: VNets e sub-redes, planejamento de endereço IP e configuração de NSG).
  • Identifique quais cargas de trabalho você planeja migrar primeiro. Comece com um grupo piloto antes de migrar sua propriedade completa.
  • Documente seus requisitos de conectividade local: largura de banda para Azure, sensibilidade de latência e expectativas de failover.

Seu caminho de leitura

Siga estas fases na ordem. Cada fase se baseia nas decisões da anterior.

Fase 1: Fundações

Comece com os três artigos fundamentais. Essas decisões moldam tudo o que se segue.

1. Redes virtuais e sub-redes

Crie a VNet que hospeda suas VMs migradas. Mapeie seus segmentos de rede existentes em sub-redes Azure. Concentre-se nos limites de isolamento de sub-rede: quais cargas de trabalho compartilham uma sub-rede, que precisa de sua própria, e quantos endereços IP cada sub-rede precisa com base na contagem de VMs.

2. Planejamento de endereço IP

Evite a sobreposição de IP com seu ambiente local. Use um pool de Roteamento Interdomínio Sem Classe (CIDR) /16 por VNet para deixar espaço para crescimento. Se seus intervalos locais se sobrepuserem a endereços reservados do Azure ou a outras assinaturas do Azure, planeje uma estratégia de reendereçamento antes de migrar.

3. Grupos de segurança de rede e grupos de segurança de aplicativos

Espelhe suas regras de firewall existentes como Grupos de Segurança de Rede (NSGs). Traduza suas listas de controle de acesso (ACLs) locais em regras de NSG com uma postura de negação padrão. Use OSGs (Grupos de Segurança de Aplicativo) para agrupar VMs por função em vez de gerenciar endereços IP individuais.

Fase 2: Topologia

4. Topologia hub-and-spoke

A topologia hub-and-spoke é a topologia padrão para migrações lift-and-shift de múltiplas cargas de trabalho. Coloque serviços compartilhados na VNet do hub: Gateway de VPN, Azure Bastion, Firewall do Azure e encaminhadores DNS. Cada carga de trabalho recebe sua própria VNet spoke, conectada ao hub. Os spokes se comunicam através do firewall do hub, proporcionando controle de tráfego centralizado.

Fase 3: Conectividade

5. Conectividade híbrida

O Gateway de VPN ou o Azure ExpressRoute para o ambiente local é sua dependência de migração mais crítica. Sem essa conexão, as VMs migradas não podem acessar serviços locais dos quais dependem e seus usuários não podem acessar aplicativos migrados. Dimensione a largura de banda do gateway com base nos padrões de tráfego documentados em seu inventário.

6. Acesso de desenvolvedor e administrador

Azure Bastion fornece acesso seguro Área de Trabalho Remota Protocol (RDP) e Secure Shell (SSH) às VMs migradas sem expô-las à Internet pública. Implante o Bastion na VNet do hub para que todos os spokes compartilhem um único ponto de acesso. Substitua sua infraestrutura de jump-box existente por este serviço gerenciado.

Fase 4: Segurança

7. Segurança DNS e resolução de nomes privados

Preserve seu comportamento de nomenclatura DNS herdado durante a migração. As VMs migradas precisam resolver os nomes de host locais, e os sistemas locais precisam resolver os nomes hospedados no Azure. Configurar o Resolvedor Privado de DNS do Azure para encaminhamento bidirecional. Mantenha suas convenções de nomenclatura DNS existentes para evitar a reconfiguração do aplicativo.

8. Acesso de saída à internet

Centralize todo o tráfego de internet de saída por meio do firewall do hub. Desative o acesso de saída padrão nas VNets spoke e encaminhe o tráfego de saída por meio do Firewall do Azure usando rotas definidas pelo usuário (UDRs). Essa abordagem espelha seu modelo local existente, em que um firewall de perímetro controla todo o tráfego associado à Internet.

9. Firewall do Azure

Implante o Firewall do Azure na VNet do hub para controle de tráfego centralizado leste-oeste (entre os spokes) e norte-sul (saída). Traduza suas políticas de firewall locais em regras de Firewall do Azure. Use regras de rede para tráfego não HTTP e regras de aplicativo para filtragem de HTTP/HTTPS com destinos de Nome de Domínio Totalmente Qualificado (FQDN).

Fase 5: Operações

10. Monitoramento de rede e observabilidade

Configure Observador de Rede do Azure e Monitor da Conexão para validar sua linha de base de migração. Verifique se os caminhos de conectividade funcionam conforme o esperado. Medir a latência entre Azure VMs e sistemas locais e estabelecer parâmetros de comparação de desempenho antes de migrar cargas de trabalho de produção.

Artigos condicionais

Nem toda migração lift-and-shift precisa do mesmo conjunto de artigos. Inclua estes artigos com base em seus requisitos específicos:

Condition Artigo Quando incluir
Aplicativo voltado para a Internet Entrada da Internet Seu aplicativo migrado deve ser acessível da Internet
É necessário balanceamento de carga da Camada 7 (L7) Entrega e desempenho do aplicativo Sua carga de trabalho precisa de Gateway de Aplicativo do Azure ou Azure Front Door
Aplicativo Web público Firewall de Aplicativo Web Seu aplicativo migrado atende ao tráfego HTTP/HTTPS público
Exposição de IP público Proteção contra DDoS Você tem requisitos de disponibilidade para recursos com endpoints públicos
Suporte multirregional necessário Rede de várias regiões Recuperação de desastres ou implantação ativa-ativa são necessárias.
Conectividade entre regiões Conectividade entre regiões e multinuvem Outras regiões ou outras nuvens estão no escopo
Trânsito em escala de filial. WAN Virtual do Azure Você tem muitas filiais ou pontos de extremidade de conectividade
Componentes de PaaS Acesso privado de PaaS Alguns componentes de carga de trabalho são movidos para serviços de PaaS Azure
Grande conjunto de VNets. Gerenciamento de rede centralizado Sua migração cria um ambiente com várias VNets que exige governança centralizada

Resumo

Seguindo esse caminho de leitura, você projetou uma rede hub-and-spoke com serviços compartilhados centralizados, conectividade VPN ou ExpressRoute estabelecida de volta ao local, implantou Firewall do Azure para inspeção de tráfego centralizada, configurou o encaminhamento de DNS para resolução de nomes, acesso seguro à VM por meio de Azure Bastion e configurou o monitoramento para validar sua migração. Essa arquitetura dá suporte às cargas de trabalho migradas, proporcionando segurança centralizada e visibilidade operacional.

Próximas Etapas 

  • Last updated on