Pular para o conteúdo

Azure

Diagramas de infraestrutura Azure utilizando os pacotes de ícones HashiCorp Flight e Carbon para redes VNet, computação e serviços gerenciados.

VNet Azure com sub-redes de gateway, aplicação e dados. O Application Gateway distribui o tráfego para VM Scale Sets.

architecture-beta
  group vnet(carbon:virtual-private-cloud)[Azure VNet]
  group gwsub(carbon:ibm-cloud-subnets)[Gateway Subnet] in vnet
  group appsub(carbon:ibm-cloud-subnets)[App Subnet] in vnet
  group datasub(carbon:ibm-cloud-subnets)[Data Subnet] in vnet

  service appgw(carbon:gateway-security)[App Gateway] in gwsub
  service vm1(hashicorp-flight:azure-vms-color)[VM Scale Set] in appsub
  service vm2(hashicorp-flight:azure-vms-color)[VM Scale Set] in appsub
  service sqldb(carbon:data-base)[Azure SQL] in datasub

  appgw:R --> L:vm1
  appgw:B --> T:vm2
  vm1:R --> L:sqldb
  vm2:R --> L:sqldb

Azure Kubernetes Service gerenciado pelo F5 Distributed Cloud para conectividade e segurança de aplicações em múltiplas nuvens.

architecture-beta
  group xc(lucide:cloud)[F5 XC]
  group aks(hashicorp-flight:azure-aks-color)[AKS Cluster]

  service mcn(f5xc:multi-cloud-network-connect)[Network Connect] in xc
  service waap(f5xc:web-app-and-api-protection)[WAAP] in xc
  service ingress(carbon:gateway)[Ingress] in aks
  service app(hashicorp-flight:docker-color)[App Pods] in aks
  service cache(carbon:datastore)[Redis Cache] in aks
  service blob(hashicorp-flight:azure-blob-storage-color)[Blob Storage]

  mcn:R --> L:waap
  waap:R --> L:ingress
  ingress:R --> L:app
  app:B --> T:cache
  app:R --> L:blob

Arquitetura Hub-Spoke Azure com segurança centralizada e serviços compartilhados conectando múltiplas VNets spoke.

flowchart TD
  hub@{ icon: 'carbon:virtual-private-cloud', label: 'Hub VNet' }
  fw@{ icon: 'carbon:firewall', label: 'Azure Firewall' }
  vpn@{ icon: 'carbon:gateway-vpn', label: 'VPN Gateway' }
  spoke1@{ icon: 'carbon:ibm-cloud-subnets', label: 'Spoke 1 - Web' }
  spoke2@{ icon: 'carbon:ibm-cloud-subnets', label: 'Spoke 2 - App' }
  spoke3@{ icon: 'carbon:ibm-cloud-subnets', label: 'Spoke 3 - Dados' }
  onprem@{ icon: 'lucide:server', label: 'DC On-Premises' }

  onprem --> vpn
  vpn --> hub
  hub --> fw
  fw --> spoke1
  fw --> spoke2
  fw --> spoke3

Alta Disponibilidade de NVA com Load Balancer — Tráfego Internet

Seção intitulada “Alta Disponibilidade de NVA com Load Balancer — Tráfego Internet”

O tráfego de entrada da internet atinge um load balancer público, que distribui para instâncias de NVA no hub. O NVA encaminha o tráfego inspecionado para as cargas de trabalho nos spokes. O tráfego de retorno dos spokes é roteado por um load balancer interno de volta ao NVA para saída. As etapas numeradas mostram o caminho de entrada (1-3) e o caminho de retorno (4-6).

flowchart TD
  subgraph internet[Internet]
    cloud@{ icon: 'lucide:globe', label: 'Internet' }
  end
  subgraph hub[Hub VNet 10.0.0.0/24]
    subgraph gwsub[Gateway Subnet 10.0.0.0/27]
      gw@{ icon: 'azure:virtual-network-gateways', label: 'VPN/ER GW' }
    end
    subgraph nvasub[NVA Subnet 10.0.0.32/27]
      intlb@{ icon: 'azure:load-balancers', label: 'Internal LB 10.0.0.36' }
      nva@{ icon: 'azure:firewalls', label: 'NVA' }
    end
    publb@{ icon: 'azure:load-balancers', label: 'Public LB' }
  end
  subgraph spoke1[Spoke1 10.1.1.0/24]
    app1@{ icon: 'azure:virtual-machine', label: 'Servidor de Aplicação' }
  end
  subgraph spoke2[Spoke2 10.1.2.0/24]
    app2@{ icon: 'azure:virtual-machine', label: 'Servidor de Aplicação' }
  end
  onprem@{ icon: 'lucide:building', label: 'On-Premises 192.168.0.0/16' }

  cloud -->|1| publb
  publb -->|2| nva
  nva -->|3| app2
  app2 -->|4| intlb
  intlb -->|5| nva
  nva -->|6| cloud
  onprem --> gw
  gw --> intlb

Alta Disponibilidade de NVA com Load Balancer — Tráfego On-Premises

Seção intitulada “Alta Disponibilidade de NVA com Load Balancer — Tráfego On-Premises”

O tráfego on-premises entra por um gateway VPN ou ExpressRoute e é direcionado a um load balancer interno que gerencia múltiplas instâncias de NVA. O NVA inspeciona e encaminha o tráfego para as cargas de trabalho nos spokes. O tráfego de retorno percorre o mesmo load balancer interno para garantir a simetria do fluxo, evitando problemas de roteamento assimétrico.

flowchart TD
  subgraph hub[Hub VNet 10.0.0.0/24]
    subgraph gwsub[Gateway Subnet 10.0.0.0/27]
      gw@{ icon: 'azure:virtual-network-gateways', label: 'VPN/ER GW' }
    end
    subgraph nvasub[NVA Subnet 10.0.0.32/27]
      intlb@{ icon: 'azure:load-balancers', label: 'Internal LB 10.0.0.36' }
      nva1@{ icon: 'azure:firewalls', label: 'NVA' }
      nva2@{ icon: 'azure:firewalls', label: 'NVA' }
    end
  end
  subgraph spoke1[Spoke1 10.1.1.0/24]
    app1@{ icon: 'azure:virtual-machine', label: 'Servidor de Aplicação' }
  end
  subgraph spoke2[Spoke2 10.1.2.0/24]
    app2@{ icon: 'azure:virtual-machine', label: 'Servidor de Aplicação' }
  end
  onprem@{ icon: 'lucide:building', label: 'On-Premises 192.168.0.0/16' }

  onprem -->|1| gw
  gw -->|2| intlb
  intlb -->|3| nva1
  nva1 -->|4| app2
  app2 -->|5| intlb
  intlb -->|6| nva2
  nva2 -->|7| gw
  gw -->|8| onprem

Alta Disponibilidade de NVA com PIP/UDR — Ativo/Standby

Seção intitulada “Alta Disponibilidade de NVA com PIP/UDR — Ativo/Standby”

Par de NVA ativo/standby onde a instância ativa (NVA1) detém o endereço IP público. Em caso de falha, o NVA2 em standby aciona a API do Azure para reatribuir o IP público e atualizar as rotas definidas pelo usuário para apontarem para si mesmo. Essa abordagem dispensa load balancers, mas requer orquestração de failover no nível da API.

flowchart TD
  subgraph internet[Internet]
    cloud@{ icon: 'lucide:globe', label: 'Internet' }
  end
  subgraph hub[Hub VNet 10.0.0.0/24]
    pip@{ icon: 'azure:public-ip-addresses', label: 'IP Público' }
    subgraph gwsub[Gateway Subnet 10.0.0.0/27]
      gw@{ icon: 'azure:virtual-network-gateways', label: 'VPN/ER GW' }
    end
    subgraph nvasub[NVA Subnet 10.0.0.32/27]
      nva1@{ icon: 'azure:firewalls', label: 'NVA1 Ativo 10.0.0.37' }
      nva2@{ icon: 'azure:firewalls', label: 'NVA2 Standby 10.0.0.38' }
    end
  end
  subgraph spoke1[Spoke1 10.1.1.0/24]
    app1@{ icon: 'azure:virtual-machine', label: 'Servidor de Aplicação' }
  end
  subgraph spoke2[Spoke2 10.1.2.0/24]
    app2@{ icon: 'azure:virtual-machine', label: 'Servidor de Aplicação' }
  end
  onprem@{ icon: 'lucide:building', label: 'On-Premises 192.168.0.0/16' }

  cloud -->|1| pip
  pip -->|2| nva1
  nva1 -->|3| app2
  app2 -->|4| nva1
  nva1 -->|5| cloud
  onprem --> gw

Alta Disponibilidade de NVA com Azure Route Server

Seção intitulada “Alta Disponibilidade de NVA com Azure Route Server”

Alta disponibilidade baseada em BGP utilizando o Azure Route Server. O Route Server estabelece adjacências eBGP com ambas as instâncias de NVA e programa dinamicamente as rotas efetivas dos spokes. O ECMP distribui a carga entre os NVAs sem necessidade de rotas definidas pelo usuário. O Route Server injeta entradas de next-hop para ambos os IPs de NVA em todas as VNets emparelhadas.

flowchart TD
  subgraph internet[Internet]
    cloud@{ icon: 'lucide:globe', label: 'Internet' }
  end
  subgraph hub[Hub VNet 10.0.0.0/24]
    publb@{ icon: 'azure:load-balancers', label: 'Public LB' }
    subgraph gwsub[Gateway Subnet 10.0.0.0/27]
      gw@{ icon: 'azure:virtual-network-gateways', label: 'VPN/ER GW' }
    end
    subgraph nvasub[NVA Subnet 10.0.0.32/27]
      nva1@{ icon: 'azure:firewalls', label: 'NVA1 10.0.0.37' }
      nva2@{ icon: 'azure:firewalls', label: 'NVA2 10.0.0.38' }
    end
    subgraph rssub[Route Server Subnet 10.0.0.64/27]
      rs@{ icon: 'azure:virtual-router', label: 'Route Server' }
    end
  end
  subgraph spoke1[Spoke1 10.1.1.0/24]
    app1@{ icon: 'azure:virtual-machine', label: 'Servidor de Aplicação' }
  end
  subgraph spoke2[Spoke2 10.1.2.0/24]
    app2@{ icon: 'azure:virtual-machine', label: 'Servidor de Aplicação' }
  end

  cloud -->|1| publb
  publb -->|2| nva1
  nva1 -->|3| app2
  app2 -->|4| nva1
  nva1 -->|5| cloud
  rs <-.->|eBGP| nva1
  rs <-.->|eBGP| nva2
  gw --> rs

Alta Disponibilidade de NVA com Gateway Load Balancer

Seção intitulada “Alta Disponibilidade de NVA com Gateway Load Balancer”

Inserção transparente de NVA utilizando o Azure Gateway Load Balancer. O tráfego destinado à aplicação é transparentemente desviado do load balancer padrão público para o Gateway LB em uma VNet de NVA separada. Os NVAs inspecionam o tráfego e o devolvem ao Gateway LB, que o encaminha de volta à aplicação. Não são necessários peering de VNet nem UDRs entre as VNets de NVA e de aplicação.

flowchart TD
  subgraph internet[Internet]
    cloud@{ icon: 'lucide:globe', label: 'Internet' }
  end
  subgraph nvavnet[NVA VNet]
    gwlb@{ icon: 'azure:load-balancers', label: 'Gateway LB' }
    nva1@{ icon: 'azure:firewalls', label: 'NVA' }
    nva2@{ icon: 'azure:firewalls', label: 'NVA' }
  end
  subgraph appvnet[App VNet]
    publb@{ icon: 'azure:load-balancers', label: 'Public Std LB' }
    web@{ icon: 'azure:virtual-machine', label: 'Servidor Web' }
  end

  cloud -->|1| publb
  publb -->|2| gwlb
  gwlb -->|3| nva1
  nva1 -->|4| gwlb
  gwlb -->|5| publb
  publb -->|6| web
  gwlb --> nva2