Google Cloud 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 Google Cloud fornecem redes virtuais isoladas. As VNets do Azure são recursos regionais, enquanto as redes VPC do Google Cloud são recursos globais. No Azure e no Google Cloud, é possível criar várias redes dentro de uma determinada assinatura ou projeto, 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 Google Cloud, é possível expandir o intervalo de IPs da sub-rede sem afetar as VMs que estão nela. No entanto, não é possível reduzir uma sub-rede depois de criá-la ou expandir o intervalo de IPs dela.

O Google Cloud também permite compartilhar redes virtuais entre projetos agrupados na mesma organização do Cloud. 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 (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 (NIC, na sigla em inglês) associado a uma VM específica. O Azure suporta até 32 NICs 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 Google Cloud
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 Google Cloud 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 migração em tempo real, 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, na sigla em inglês). No Compute Engine, cada regra é configurada como uma regra de firewall.

Tanto no Google Cloud 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 determinada sub-rede ou placa de rede (NIC, na sigla em inglês). No Google Cloud, por sua vez, é 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) de endpoint, aplicáveis no nível da VM. O Google Cloud 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 deles.

Em um nível elevado, os componentes do balanceamento de carga do Azure são associados aos componentes do Google Cloud da seguinte maneira:

Componente Microsoft Azure Google Cloud
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 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 Google Cloud, por meio do balanceador de carga de rede do Compute Engine.

Esses serviços são associados 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, você pode alcançar resultados semelhantes, configurando o balanceamento de carga de proxy TCP ou o balanceamento de carga 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 gerenciados, como o Azure DNS e o 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

Os serviços de conectividade do Azure são comparados aos do Google Cloud da seguinte forma:

Recurso Azure Google Cloud
Peering de VPC Peering de VNet Peering de rede 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 Peering por operadora
Conexão direta dedicada N/A Peering direto
Peering da CDN N/A CDN Interconnect

VPN

O Azure e o Google Cloud fornecem um serviço de rede privada virtual (VPN). O Azure oferece o Gateway de VPN do Azure (em inglês), e o Google Cloud oferece o Cloud VPN como parte do Compute Engine. Em cada serviço, você cria um túnel de uma rede externa para a rede virtual interna do Azure ou do Compute Engine e estabelece uma conexão segura nesse túnel.

Para rotear o tráfego no Google Cloud, use o Cloud Router , que ativa atualizações dinâmicas de rota do BGP entre a rede do Compute Engine e a rede que não é do 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 Google Cloud proporcionam a capacidade de fazer o peering de uma ou mais redes virtuais. No Azure, esse recurso é chamado de VNet peering e no Google Cloud, 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 VNet peering do Azure é associado ao peering de rede VPC do Google Cloud da seguinte forma:

Recurso Azure Google Cloud
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 mesma forma, no Google Cloud, é possível fazer o peering entre redes VPC de diferentes projetos ou organizações. Para fazer o peering de redes VPC entre projetos, utilize uma rede VPC específica e uma rede VPC 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. Assim como o ExpressRoute e o Azure, o Cloud Interconnect possibilita a configuração de uma linha regional alocada no Google Cloud 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 Google Cloud também permite a conexão direta com a rede do Google, e não por meio de um parceiro terceirizado. O Azure não oferece esse serviço.

Peering da content delivery network (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 Google Cloud cobram uma taxa por hora pelos serviços de VPN.

No Cloud Interconnect, o custo do peering por 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.

O Google Cloud não cobra pelo peering direto.

Assim como no peering por operadora, os custos de peering de CDN do Google Cloud são definidos pelo parceiro do peering. O Google Cloud não cobra pelo CDN Interconnect.

A seguir

A seguir: armazenamento