Percurso de conceção de rede lift-and-shift

Este guia fornece um caminho de leitura sequencial através do Azure Networking Design Guide para clientes que migram cargas de trabalho on-premises para o Azure Infrastructure as a Service (IaaS) sem necessidade de reestruturar aplicações. Siga os passos numerados para construir a sua rede desde o início, tomando as decisões certas em cada etapa.

Descrição geral

Uma migração “lift-and-shift” transfere cargas de trabalho on-premises existentes para máquinas virtuais (VMs) do Azure, com alterações mínimas na arquitetura da aplicação. As suas aplicações mantêm os seus padrões de comunicação, dependências e configurações existentes. A rede que constróis no Azure deve suportar estes padrões existentes, aproveitando ao mesmo tempo os serviços de segurança e conectividade nativos do Azure.

A tua arquitetura alvo é uma topologia hub e spoke com serviços partilhados centralizados. Uma rede virtual de hub única (VNet) acolhe o Gateway de VPN ou a ligação ExpressRoute para ligação às infraestruturas no local, o Azure Bastion para acesso seguro às VMs, o Azure Firewall para inspeção centralizada do tráfego e o reencaminhamento de DNS. Os VNets spoke alojam as suas VMs de carga de trabalho migradas, isoladas umas das outras por defeito e ligadas através do hub para comunicação entre cargas de trabalho.

Este percurso de leitura leva-o por 10 artigos essenciais em cinco fases. Cada artigo baseia-se nas decisões que tomou na etapa anterior. No final, dispõe de um design de rede pronto para produção que suporta as suas cargas de trabalho migradas com segurança em profundidade e conectividade.

Pré-requisitos

  • Leia o plano de rede do Azure e a visão geral do design para orientação sobre os serviços disponíveis e a estrutura do guia.
  • Complete um inventário da sua rede local existente: intervalos de IP, sub-redes, regras de firewall, zonas DNS e fluxos de tráfego entre aplicações (irá referenciar este inventário nos artigos fundamentais: VNets e subredes, planeamento de endereços IP e configuração NSG).
  • Identifique primeiro quais as cargas de trabalho que planeia migrar. Comece com um grupo piloto antes de migrar todo o seu espólio.
  • Documente as suas necessidades de conectividade local: largura de banda para o Azure, sensibilidade à latência e expectativas de failover.

O teu percurso de leitura

Trabalhe estas fases por ordem. Cada fase baseia-se nas decisões da anterior.

Fase 1: Fundações

Comece pelos três artigos fundamentais. Estas decisões moldam tudo o que se segue.

1. Redes e sub-redes virtuais

Cria o VNet que aloja as tuas VMs migradas. Mapeie os seus segmentos de rede existentes para sub-redes do Azure. Foca-te nos limites de isolamento das sub-redes: que cargas de trabalho partilham uma sub-rede, quais precisam da sua própria e quantos endereços IP cada sub-rede precisa com base no número de VMs.

2. Planeamento de endereços IP

Evite a sobreposição de IP com o seu ambiente local. Use um pool de Inter-Domain Routing (CIDR) sem classes /16 por VNet para deixar espaço para crescimento. Se os seus intervalos on-premises coincidirem com endereços reservados no Azure ou com outras subscrições do Azure, planeie uma estratégia de reendereçamento antes de migrar.

3. Grupos de segurança de rede e grupos de segurança de aplicações

Espelhe as suas regras de firewall existentes sob a forma de Grupos de Segurança de Rede (NSGs). Converta as suas listas de controlo de acesso locais (ACLs) em regras de NSG com uma política de negação por predefinição. Use Grupos de Segurança de Aplicações (ASGs) para agrupar VMs por função em vez de gerir endereços IP individuais.

Fase 2: Topologia

4. Topologia hub-and-spoke

Hub-and-spoke é a topologia padrão para migrações de elevação e deslocamento com múltiplas cargas de trabalho. Coloque serviços partilhados no hub VNet: Gateway de VPN, Azure Bastion, Azure Firewall e encaminhadores DNS. Cada carga de trabalho tem a sua própria VNet satélite emparelhada com o hub. Os spokes comunicam através da firewall do hub, proporcionando controlo centralizado do tráfego.

Fase 3: Conectividade

5. Conectividade híbrida

Gateway de VPN ou Azure ExpressRoute para on-premises é a sua dependência de migração mais crítica. Sem esta ligação, as VMs migradas não conseguem aceder aos serviços on-premises dos quais dependem, e os seus utilizadores não conseguem aceder às aplicações migradas. Dimensione a largura de banda do seu gateway com base nos padrões de tráfego que documentou no seu inventário.

6. Acesso para programadores e administradores

O Azure Bastion fornece acesso seguro ao Ambiente de Trabalho Remoto Protocol (RDP) e Secure Shell (SSH) às suas VMs migradas sem as expor à internet pública. Implemente o Bastion na VNet de hub para que todas as redes spokes partilhem um único ponto de acesso. Substitua a sua infraestrutura de jump-box existente por este serviço gerido.

Fase 4: Segurança

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

Preserva o teu comportamento de nomeação DNS antigo durante a migração. As suas VMs migradas precisam de resolver nomes de host on-premises e os sistemas on-premises precisam de resolver nomes hospedados no Azure. Configure o DNS do Azure Private Resolver para encaminhamento bidirecional. Mantém as convenções de nomes DNS existentes para evitar reconfiguração de aplicações.

8. Acesso de saída à Internet

Centralize todo o tráfego de internet de saída através do firewall do hub. Desligue o acesso de saída predefinido nas suas VNets spoke e encaminhe o tráfego de saída através do Azure Firewall com Rotas Definidas pelo Utilizador (UDRs). Esta abordagem espelha o seu modelo local existente, onde um firewall perimetral controla todo o tráfego na internet.

9. Azure Firewall

Implemente o Azure Firewall na VNet de hub para um controlo centralizado do tráfego este-oeste (entre os spokes) e norte-sul (de saída). Traduza as suas políticas de firewall on-premises em regras do Azure Firewall. Use regras de rede para tráfego não HTTP e regras de aplicação para filtragem HTTP/HTTPS com alvos de Nome de Domínio Totalmente Qualificado (FQDN).

Fase 5: Operações

10. Monitorização e observabilidade da rede

Configura o Observador de Rede do Azure e o Monitor de Ligação para validar a tua base de migração. Verifica se os caminhos de conectividade funcionam como esperado. Meça a latência entre VMs Azure e sistemas on-premises e estabeleça benchmarks de desempenho antes de migrar cargas de trabalho em produção.

Artigos condicionais

Nem todas as migrações lift-and-shift requerem o mesmo conjunto de artigos. Inclua estes artigos com base nas suas necessidades específicas:

Condição Artigo Quando incluir
Aplicação voltada para a Internet Entrada na Internet A sua candidatura migrada deve estar acessível pela internet
É necessário balanceamento de carga da Camada 7 (L7) Entrega e desempenho da aplicação A sua carga de trabalho precisa de Gateway de Aplicação do Azure ou Azure Front Door
Aplicação web pública Firewall de aplicativos Web A sua aplicação migrada serve tráfego público HTTP/HTTPS
Exposição pública de propriedade intelectual Proteção DDoS Tens requisitos de tempo de atividade para recursos com endpoints públicos
Multirregião necessária Rede multi-região É necessária recuperação de desastres ou implementação ativa-ativa
Conectividade entre regiões Conectividade entre regiões e multicloud Outras regiões ou outras plataformas de cloud estão incluídas no âmbito
Trânsito em escala de ramal WAN Virtual do Azure Tem várias filiais ou vários pontos periféricos de conectividade
Componentes PaaS Acesso privado PaaS Alguns componentes da carga de trabalho passam para os serviços PaaS do Azure
Ambiente de VNets de grande dimensão Gestão centralizada da rede A sua migração cria um património multi-VNet que requer governação centralizada

Resumo

Ao seguir este percurso de leitura, desenhou uma rede hub-and-spoke com serviços partilhados centralizados, estabeleceu conectividade VPN ou ExpressRoute de volta ao local, implementou o Azure Firewall para inspeção centralizada de tráfego, configurou o encaminhamento DNS para resolução de nomes, garantiu o acesso à VM através do Azure Bastion e configurou monitorização para validar a sua migração. Esta arquitetura suporta as suas cargas de trabalho migradas, oferecendo-lhe segurança centralizada e visibilidade operacional.

Passos seguintes

  • Last updated on