Google Cloud Platform para profissionais do Azure: rede

Atualizado em 18 de julho de 2017

Compare os serviços de rede do Azure e do Google nos respectivos ambientes em nuvem. Com esses serviços, você tem conectividade entre máquinas virtuais, outros serviços em nuvem e servidores locais.

Rede virtual

Redes e sub-redes

O Azure e o Cloud Platform fornecem redes virtuais isoladas. As VNets do Azure são recursos regionais e as redes VPC do Cloud Platform são recursos globais. Tanto no Azure como no Cloud Platform, é possível criar diversas redes dentro de uma assinatura ou um projeto específico, bem como segmentar essas redes em uma ou mais sub-redes. Além disso, as VMs implantadas em uma rede virtual se comunicam sem qualquer configuração adicional, seja qual for a sub-rede em que residam.

No Azure, só é possível reduzir ou ampliar o intervalo de IPs da sub-rede se ela ainda não incluir VMs ou serviços. Por outro lado, no Cloud Platform, é possível expandir o intervalo de IPs da sub-rede sem afetar as VMs nela. No entanto, não é possível reduzir uma sub-rede depois de criá-la ou expandir o intervalo de IPs dela.

No Cloud Platform, você compartilha redes virtuais entre projetos agrupados na mesma organização. Esse recurso é chamado de Rede VPC compartilhada. Com a VPC compartilhada, os administradores da organização no Cloud concedem permissão para que diversos projetos usem uma única rede VPC e os recursos de rede correspondentes. Para mais informações sobre esse recurso, veja Visão geral das Redes VPC compartilhadas. No Azure, não há um recurso correspondente ao compartilhamento de VPC.

Interfaces de rede e endereços IP

Em um nível alto, as redes VPC e as VNnets do Azure tratam os endereços IP de maneiras semelhantes. Na inicialização, todas as VMs têm um IP interno privado. Como alternativa, você pode associar um IP externo, que pode ser estático ou dinâmico, à sua VM. No entanto, há pequenas diferenças nos detalhes de cada serviço.

Azure

No Azure, as interfaces de rede (NICs) e todos os tipos de endereços IP são tratados como recursos. Você associa um recurso de endereço IP público a um recurso de placa de rede que está associado a uma VM específica. O Azure suporta até 32 placas de rede por máquina, dependendo do tipo de máquina. Cada NIC permite até 50 configurações de IP e cada uma delas pode ser associada a um único endereço IP público e outro particular.

Por padrão, seu endereço IP público é temporário. Quando você dissocia um recurso de endereço IP público de um recurso NIC, o recurso é mantido, mas o endereço IP é descartado. Quando o recurso de endereço IP público é associado a uma nova VM, um novo endereço é conectado ao recurso.

O endereço IP privado da VM também é temporário. Quando você para ou desativa a VM, o endereço IP privado é removido. Quando ela é reiniciada, um novo endereço IP é atribuído.

Também é possível configurar o endereço IP público ou privado como estático. Quando o endereço IP é estático, ele é mantido mesmo quando o recurso de endereço IP não está associado a nenhuma NIC.

Compute Engine

No Compute Engine, as NICs não são tratadas como recursos separados. Em vez disso, elas são vinculadas diretamente a uma determinada instância de VM. As instâncias de VM do Compute Engine aceitam até oito NICs, dependendo do tipo de máquina. Cada NIC pode ser associada a um único endereço IP externo e um interno.

No Compute Engine, como no Azure, cada instância de VM recebe um endereço IP interno, além de ser possível anexar um endereço IP externo temporário ou estático. Os endereços IP internos e os externos temporários fazem parte da sua instância de VM, não são recursos distintos. No entanto, ao converter o IP externo de temporário para estático, ele se torna um recurso independente que pode ser separado da VM.

Ao contrário do que ocorre no Azure, o endereço IP interno da instância da VM é reservado para a vida útil da instância.

Com o Compute Engine, você também atribui um intervalo de endereços IP como alias ao endereço IP primário da instância de uma VM. Esse recurso permite a atribuição de IPs distintos a serviços distintos executados na mesma instância de VM. Isso é particularmente útil em casos de uso que envolvem o uso de contêineres. Além disso, é possível configurar um intervalo CIDR secundário na sub-rede para ser usado na atribuição de IPs do alias para essa sub-rede.

Tipo de IP Azure Cloud Platform
IP permanente IP estático público IP estático
IP temporário IP dinâmico público IP temporário
IP interno IP privado IP interno

Migração de VM

No Azure, a migração das VMs é processada automaticamente quando o hardware subjacente está sendo atualizado ou apresenta falha. Embora esse processo costume ocorrer sem interrupções, pode ser necessário reiniciar a VM para que as atualizações entrem em vigor. Em alguns casos raros, o Azure força a reinicialização da VM.

Da mesma forma, o Cloud Platform conta com a migração em tempo real, que consiste em migrar de maneira automática e transparente as instâncias da VM quando o hardware do host precisar de manutenção ou substituição. Tal como acontece no processo de migração do Azure, a migração em tempo real em geral é sem interrupções, mas requer uma reinicialização da instância da VM em casos esparsos. A migração em tempo real está ativada por padrão para a maioria dos tipos de máquinas. No entanto, as máquinas com GPUs anexadas não usam esse tipo de migração porque elas são conectadas diretamente ao hardware do host. Para mais informações sobre esse recurso, veja a postagem do blog.

Firewalls

No Azure e no Compute Engine, os usuários configuram as políticas de firewall com estado para permitir e negar seletivamente o tráfego nos recursos em rede. Nos dois ambientes, cada rede virtual bloqueia por padrão o tráfego recebido de fora da rede por padrão. Para permitir o acesso a um recurso específico, use regras. No Azure, cada regra é configurada como um grupo de segurança de rede (NSG). No Compute Engine, cada regra é configurada como uma regra de firewall.

Tanto no Cloud Platform quanto no Azure, é possível associar tags às regras de NSG ou de firewall. Desse modo, você consegue aplicar regras aos recursos que usam uma determinada tag. No Azure, é possível associar apenas um único NSG a uma sub-rede ou NIC. Por outro lado, no Cloud Platform, é possível aplicar várias regras de firewall a um recurso, permitindo um gerenciamento mais granular do seu firewall.

O Azure também permite que os usuários configurem regras de firewall sem estado, criando listas de controle de acesso (ACLs) do ponto de extremidade, aplicáveis no nível da VM. O Cloud Platform não é compatível com regras de firewall sem estado.

Balanceamento de carga

Os balanceadores de carga distribuem tráfego de entrada entre várias instâncias. Quando configurados corretamente, os balanceadores de carga deixam os aplicativos tolerantes a falhas e aumentam a disponibilidade do aplicativo.

Em um nível elevado, os componentes do balanceamento de carga do Azure são mapeados para os componentes do Cloud Platform da seguinte forma:

Componente Microsoft Azure Google Cloud Platform
Balanceamento de carga HTTP Gateway de aplicativo (é possível fazer o pareamento com o Gerenciador de tráfego para balanceamento de carga entre regiões) Balanceador de carga HTTP(S) do Compute Engine
Balanceamento de carga TCP/UDP Azure Load Balancer (balanceador de carga voltado para Internet) Balanceador de carga de rede, balanceador de carga do proxy TCP (entre regiões)
Balanceamento de carga interno Azure Load Balancer (balanceador de carga interno) Balanceador de carga interno do Compute Engine
Balanceamento de carga SSL Gateway de aplicativo (tráfego HTTPS) Balanceador de carga HTTP(S) do Compute Engine (tráfego HTTPS), balanceador de carga do proxy SSL (tráfego não HTTP criptografado)

Balanceamento de carga de HTTP(S)

No Azure e no Compute Engine, o balanceamento de carga fornecido é o de camada 7, que distribui solicitações de clientes na camada do aplicativo para possibilitar um roteamento mais sofisticado do que o de camada 4. No Azure, este serviço é oferecido por meio do Gateway de aplicativo e, no Compute Engine, pelo balanceador de carga HTTP(S). Esses serviços são mapeados da seguinte maneira:

Recurso Gateway de aplicativo Balanceador de carga HTTP(S) do Compute Engine
Balanceamento de carga HTTP Sim Sim
IP único e global entre regiões Não Sim, IPv4 e IPv6
Balanceamento de carga entre regiões Quando pareado com o Gerenciador de tráfego (baseado em DNS) Suporte nativo (baseado em IP)
Balanceamento de carga com base no conteúdo Sim Sim
Afinidade da sessão Sim (baseado em cookies) Sim (baseado em cookies e IP)
Terminação SSL Sim Sim
SSL de ponta a ponta Sim Sim
Suporte a WebSocket Sim Sim
Monitoramento de integridade Sim Sim
Logging Sim Sim (atualmente na versão Alfa)
Distribuição de carga Round robin Utilização da CPU ou solicitações por segundo (RPS)
Escalonamento automático Não Sim

Balanceamento de carga HTTP(S) entre regiões

No Gateway de aplicativo e no Compute Engine, você encontra maneiras de executar o balanceamento de carga HTTP(S) entre as regiões.

No Azure, para configurar o balanceamento de carga HTTP(S) entre regiões, basta colocar o Gerenciador de tráfego, serviço do Azure para roteamento de tráfego baseado em DNS, para administrar os vários pontos de extremidade do Gateway de aplicativo. O Gerenciador de tráfego encaminha o tráfego até o ponto de extremidade do Gateway do aplicativo mais próximo do usuário final, de acordo com a estratégia de roteamento escolhida.

Ao contrário do Gateway de aplicativo, o balanceamento de carga HTTP(S) do Compute Engine é compatível nativamente com o balanceamento de carga HTTP(S) entre regiões. Ao criar o balanceador de carga HTTP(S), configure uma regra de encaminhamento global que mantém um único ponto de entrada de IP global. Essa regra envia o tráfego por meio de um proxy de destino que distribui esse tráfego para os back-ends relevantes. O balanceador de carga HTTP(S) direciona o tráfego para os back-ends mais próximos do usuário final. No entanto, o balanceamento de carga baseado em IP global do Compute Engine oferece benefícios de desempenho significativos:

  • O balanceamento de carga baseado em IP é gerenciado de acordo com a carga. É possível configurar o balanceador de carga global do Compute Engine para distribuir o tráfego com base na utilização da CPU ou nas solicitações por segundo. Por outro lado, o balanceamento de carga baseado em DNS não é gerenciado de acordo com a carga e roteia o tráfego com base em estratégias de roteamento gerais.
  • O balanceamento de carga baseado em DNS depende dos ISPs. Para que uma alteração de DNS entre em vigor, ela precisa ser registrada no ISP. Como os ISPs costumam armazenar os registros DNS em cache por horas, talvez eles não detectem as alterações de DNS em tempo hábil, fazendo com que os usuários finais sejam encaminhados para um serviço de back-end sobrecarregado ou até mesmo ineficaz. O balanceamento de carga baseado em IP global ajuda a evitar essa fonte de possíveis problemas.

Afinidade da sessão

A afinidade de sessão permite mapear um cliente específico para um back-end específico, potencialmente economizando recursos do lado do servidor.

No Gateway de aplicativo, você tem a afinidade de sessão baseada em cookies, que associa um cliente a uma VM de back-end específica, armazenando um cookie do lado do cliente.

No balanceador de carga HTTP(S) do Compute Engine, você também encontra a afinidade baseada em cookies, além da afinidade baseada em IP, que encaminha todas as solicitações de um endereço IP de cliente específico para a mesma instância de VM.

Escalonamento

No Gateway de aplicativo, é necessário adicionar VMs manualmente quando a capacidade de veiculação do balanceador de carga for excedida. Por outro lado, no balanceador de carga HTTP(S) do Compute Engine, a autenticação de instâncias de VM com base na capacidade de atendimento do balanceador de carga é fornecida, o que permite manipular o excesso de tráfego sem a necessidade de intervenção manual. Esse escalonamento automático ocorre instantaneamente, sem necessidade de pré-aquecimento. Para mais informações, veja Balanceamento e escalonamento de carga.

Balanceamento de carga TCP/UDP

No Azure e no Compute Engine, o balanceamento de carga de camada 4 é fornecido. As solicitações de clientes são distribuídas dentro de uma região na camada de transporte de rede. No Azure, este serviço é disponibilizado por meio do Azure Load Balancer e, no Cloud Platform, isso é feito pelo balanceador de carga de rede do Compute Engine.

Esses serviços são mapeados da seguinte maneira:

Recurso Azure Load Balancer Balanceador de carga de rede do Compute Engine
Balanceamento de carga TCP/UDP Sim Sim
Balanceamento de carga interno Sim Sim
Balanceamento de carga voltado para a Internet Sim Sim
Protocolos de camada de aplicativo compatíveis Todos Todos
Pontos de extremidade compatíveis VMs do Azure (exceto VMs básicas), instâncias de papéis dos serviços do Cloud Pools de destino, instâncias de VM de destino, serviços de back-end (apenas balanceamento de carga interno)
Monitoramento de integridade Sim Sim
Modo padrão de balanceamento de carga 5 tuplas (IP de origem e IPs de destino, portas de origem e destino, tipo de protocolo) 5 tuplas (IPs de origem e de destino, portas de origem e de destino, tipo de protocolo)
Modos de afinidade de sessão 2 tuplas (IPs de origem e de destino), 3 tuplas (IPs de origem e de destino, porta) 2 tuplas (IPs de origem e de destino), 3 tuplas (IPs de origem e de destino, tipo de protocolo)

Balanceamento de carga TCP/UDP entre regiões

No Azure, para melhorar a latência do usuário final, basta colocar o Gerenciador de Tráfego para administrar os Azure Load Balancers e configurar o roteamento dinâmico para os endereços IP públicos. Essa disposição permite o uso de uma única configuração de DNS para rotear o tráfego para as VMs mais próximas dos usuários.

No Compute Engine, para conseguir resultados semelhantes, basta configurar o balanceamento de carga de proxy TCP ou de proxy SSL. Esses serviços são projetados de maneira semelhante ao balanceador de carga HTTP(S) do Compute Engine, mas são compatíveis com uma variedade maior de protocolos de camadas de aplicativo. Tal como no balanceador HTTP(S), você usa um único endereço IP global para distribuir o tráfego entre as instâncias de VM mais próximas dos usuários.

O balanceamento de carga baseado em IP oferece vantagens significativas de desempenho em relação ao baseado em DNS, incluindo a distribuição de tráfego baseada em carga e um desempenho mais consistente. Consulte a seção Balanceamento de carga HTTP(S) entre regiões para mais informações.

Custos

As taxas do Azure Load Balancer estão incluídas no preço das máquinas virtuais Azure.

No Gateway de aplicativo, uma taxa por hora é cobrada para cada gateway e uma taxa específica por GB para o tráfego processado pelo gateway.

No Compute Engine, uma taxa por hora é cobrada para cada regra de encaminhamento e uma taxa por GB específica para o tráfego processado pelo balanceador de carga.

DNS

Um serviço de DNS traduz nomes de domínio que podem ser lidos por pessoas nos endereços IP que os servidores usam na conexão entre eles. Os serviços de DNS gerenciado, como o DNS do Azure e o Google Cloud DNS, oferecem DNS gerenciado escalonável na nuvem.

O DNS do Azure e o Cloud DNS são muito semelhantes. Ambos são compatíveis com os tipos de registros DNS mais comuns, bem como veiculação baseada em anycast. Atualmente, nenhum dos serviços é compatível com DNSSEC.

Conectividade

Aqui está uma comparação dos serviços de conectividade do Azure os serviços do Cloud Platform:

Recurso Azure Cloud Platform
Peering de VPC Peering de VNet Peering de redes VPC
Rede particular virtual Gateways de VPN do Azure Cloud VPN
Conexão particular dedicada por operadora parceira ExpressRoute N/A
Conexão pública dedicada por operadora parceira N/A Carrier Interconnect
Conexão direta dedicada N/A Peering direto
Peering da CDN N/A CDN Interconnect

VPN

O Azure e o Cloud Platform fornecem um serviço de rede privada virtual (VPN, na sigla em inglês). No Azure, esse serviço é oferecido no gateway de VPN do Azure. No Cloud Platform, ele é oferecido no Google Cloud VPN como parte do Compute Engine. Em cada serviço, você cria um túnel de uma rede externa para sua rede virtual interna do Azure ou do Compute Engine e estabelece uma conexão segura nesse túnel.

Para rotear o tráfego no Cloud Platform, use o Google Cloud Router. Ele ativa atualizações de rotas de BGP entre a rede do Compute Engine e a rede não Google. No Azure, um serviço de roteamento semelhante é fornecido como parte do serviço Gateway de VPN do Azure.

Peering de rede virtual

O Azure e o Cloud Platform oferecem a capacidade de compartilhar uma ou mais redes virtuais. No Azure, esse recurso é chamado de peering da VNet e no Cloud Platform, peering da rede VPC. O peering de rede virtual tem várias vantagens em relação aos endereços IP ou VPNs externos, incluindo:

  • latência mais baixa do que a rede IP pública;
  • maior segurança, já que os proprietários de serviços conseguem evitar a exposição pública dos serviços na Internet com os riscos associados.

O peering da VNet do Azure é mapeado para o da rede VPC do Cloud Platform da seguinte maneira:

Recurso Azure Cloud Platform
Restrições de localidade As redes com peering precisam estar na mesma região Sem restrições
Serviços compatíveis VMs, serviços em nuvem Compute Engine, ambiente flexível do App Engine
Número máximo de redes com peering por rede Até 10 por padrão e máximo de 50, mediante solicitação Até 25
Sobreposição de endereços IP Incompatível Incompatível
Peering transitivo Incompatível Incompatível

Peering entre unidades

No Azure, é possível fazer o peering de VNets que estão em diferentes assinaturas. Da maneira semelhante, no Cloud Platform, isso pode ser feito em redes VPC existentes em diferentes projetos ou organizações. Para fazer o peering de redes VPC entre projetos, utilize uma rede específica e uma rede compartilhada. Entre organizações, faça o peering com redes existentes em projetos dentro dessas organizações.

Interconexão dedicada

Em alguns cenários, uma VPN local para nuvem talvez não forneça a velocidade ou segurança necessária para uma determinada carga de trabalho. Para essas situações, o Azure e o Google, em conjunto com parceiros, disponibilizam a alocação de uma linha de rede com nível de capacidade garantido.

Peering de operadora

O Azure oferece o ExpressRoute. Com ele, você configura uma linha particular alocada no Azure por meio de uma instalação da operadora parceira. Cada local do parceiro atende a uma determinada região.

O Google oferece um serviço equivalente, o Cloud Interconnect. Tal como no ExpressRoute e no Azure, o Cloud Interconnect possibilita a configuração de uma linha regional alocada no Cloud Platform por meio de uma instalação de parceiros. No entanto, a linha usa redes públicas.

Peering direto

Além do peering da operadora, o Cloud Platform também permite a conexão direta com a rede do Google, não por um parceiro terceirizado. O Azure não oferece esse serviço.

Peering da rede de fornecimento de conteúdo (CDN)

O peering da content delivery network (CDN) oferece uma conexão entre os recursos na nuvem e um provedor da CDN por meio de locais de extremidade da rede. O Google fornece o peering da CDN para diversos fornecedores de CDN pelo serviço CDN Interconnect.

O peering de CDN não é oferecido como serviço pelo Azure. No entanto, ele tem conexões dedicadas com os CDNs da Akamai e da Verizon, como parte do serviço CDN do Azure.

Custos

O Azure e o Cloud Platform cobram uma taxa por hora pelos serviços de VPN.

No Cloud Interconnect, o custo do peering da operadora é definido pelo parceiro que aloca a linha. No ExpressRoute, há dois modelos de faturamento que o Azure oferece:

  • Dados ilimitados: você paga uma taxa mensal por transferência ilimitada de dados.
  • Dados medidos: você paga uma taxa mensal menor, mas a cobrança também é feita com base na saída da rede por GB.

No Cloud Platform, o peering direto não é cobrado.

Assim como no peering da operadora, os custos de peering da CDN do Cloud Platform são definidos pelo parceiro do peering. No Cloud Platform, CDN Interconnect não é cobrado.

A seguir

A seguir: armazenamento