O que você precisa saber ao usar mais de uma interface de rede no Google Cloud
O Load Balancer do Google Cloud, com um único IP global e uma porção de serviços de backend (VMs, pods do K8s, instâncias do Cloud Functions etc.), é hoje a forma predominante de expor sua aplicação para a World Wide Web. Ainda mais quando tudo o que você precisa é o bom e velho HTTP(S). Um único endereço IP para governar a todos costuma dar conta do recado.
Mas, vez ou outra, surge um cenário especial — ou digamos tradicional — em que você precisa que uma VM aceite tráfego em múltiplos IPs. Na maioria das vezes isso acontece via protocolo TCP, mas o clássico exemplo de virtual hosting HTTP baseado em IP também vem logo à cabeça.
No fim das contas, tudo isso se resume a "Como faço para ter uma VM no GCP com vários IPs?". Uma busca rápida na web provavelmente vai te levar pelo caminho de "VM no GCP com múltiplas interfaces de rede". Essa abordagem funciona como descrito — basta vincular um IP externo a cada Network Interface Card (NIC) da VM. Só que existem algumas limitações que você precisa conhecer:
- Cada Network Interface Card (NIC) exige uma rede VPC separada. Não é um problema em si, mas dá um certo trabalho de DevOps — não basta criar uma VPC e definir suas faixas de IP sem sobreposição; também é preciso criar regras de FW para cada VPC.
- Você pode ter no máximo 8 NICs por VM. Pode ser o suficiente para o seu caso, ou pode não ser.
- Você NÃO PODE alterar a quantidade de NICs depois que a VM é criada. Se começar com 5 IPs e quiser adicionar mais um depois, vai ter que recriar a VM.
- O número de vCPUs da VM precisa ser, no mínimo, igual ao número de NICs. É aqui que a brincadeira pode ficar cara. 1 ou 2 vCPUs podem ser suficientes para atender todo o seu tráfego, mas você ainda vai ter que pagar por máquinas de 8 vCPUs se quiser 8 IPs.
Tem um truque que dá pra compartilhar com você — crie uma VM com 8 vCPUs e 8 NICs, depois pare a VM, reduza o tipo de máquina e ligue de novo. Use com cautela, porque o GCP pode fechar essa brecha a qualquer momento.
Forwarding rules
O caminho mais barato e direto são as forwarding rules. Toda a rede do GCP é definida por software, então sua VM não pode simplesmente sair pegando IPs e anunciando-os via respostas ARP — na verdade, quase não há ARP envolvido. É localhost ou o gateway padrão para o resto. Até o tráfego para a VM "vizinha" na mesma VPC passa pelo gateway padrão.
me@my-vm:~$ ip route showdefault via 10.128.0.1 dev ens410.128.0.1 dev ens4 scope linkOu seja, precisamos "explicar" ao GCP que queremos mais IPs aceitando tráfego, e a forma de "explicar" isso é por meio das forwarding rules.
Uma forwarding rule no GCP é bem flexível. Ela pode escutar em qualquer combinação de IP, portas, protocolos, hosts e paths HTTP, e encaminhar o tráfego correspondente para um destino, que pode ser uma VM, um pool de VMs, um bucket do Cloud Storage, uma Cloud Function, um serviço K8s etc.
Forwarding rules custam dinheiro. Já já a gente fala disso.
No nosso caso, basta a forma mais simples — escutar em tcp:endereço:porta e encaminhar todo o tráfego para uma única instância de destino.
Forwarding rules em sua forma mais simples
A documentação do GCP tem um artigo muito bom e bem extenso sobre como configurar isso. Eles chamam essa abordagem de Protocol Forwarding. Praticamente não há suporte para isso no console do GCP. Se quiser configurar em uma região que não seja a padrão, fique atento e indique direitinho as regiões e zonas certas em cada comando (me avise nos comentários se quiser mais detalhes sobre esse ponto).
Felizmente, dá pra fazer de um jeito mais simples pela UI.
Vamos começar alocando alguns IPs:
OBSERVAÇÃO: garanta que seus IPs sejam regionais e estejam na mesma região da VM de destino.
A UI avisa que IPs externos estáticos não utilizados têm um preço mais alto do que os utilizados, mas a gente resolve isso em instantes.
Em seguida, crie uma VM — vamos chamá-la de "au-vm" na região australia-southeast1. Lembre-se de marcar "Allow HTTP traffic" ou de configurar as regras de firewall para permitir a porta em questão via TCP.
Agora, vamos às forwarding rules. No menu Network Services, escolha Load Balancing e comece a configuração de um novo TCP load balancer. Os valores padrão de "From Internet to my VMs", "Single region only" e "Target Pool or Target Instance" são exatamente o que precisamos.
Dê um nome ao seu load balancer e, na seção Backend configuration, selecione a instância au-vm que você já criou.
Pronto, a parte do destino está fechada. Agora clique em "Frontend configuration" para cuidar da parte de "escuta" e adicionar todos os IPs que você reservou.
Aqui adicionei todos os IPs que aloquei antes para escutar na porta 80
Clique em "Create" — e é isso! Espere alguns minutinhos até ficar online e, daí em diante, sua VM já aceita tráfego nos três IPs acima. Se não funcionar, confira se as regras de firewall estão liberando as portas necessárias.
Você pode editar seu load balancer para adicionar e remover IPs a qualquer momento.
Os processos da sua VM podem até fazer bind no endereço IP de destino desejado, mesmo que esse endereço não apareça configurado em nenhuma interface de rede do Linux (de acordo com o ip address show). Neste exemplo, o comando abaixo vai funcionar:
nc -s 34.87.204.138 -l -p 80O segredo por trás dessa mágica são os daemons do GCP rodando na sua máquina, configurando rotas no Linux para aceitar pacotes destinados aos endereços em questão:
me@au-vm:~$ ip route show table all...local 34.87.204.138 dev ens4 table local proto 66 scope hostlocal 34.87.228.28 dev ens4 table local proto 66 scope hostlocal 34.116.108.163 dev ens4 table local proto 66 scope host...Vamos falar de dinheiro
As forwarding rules funcionam muito bem e parecem uma resposta mais natural para o problema. Só que elas não são de graça.
O Google cobra uma taxa fixa de US$ 0,025/hora pelas 5 primeiras regras — ou seja, você paga o mesmo US$ 0,025/hora tendo 1 ou 5 regras. Para cada forwarding rule adicional, o preço é de US$ 0,01/hora. Resultado: ter 10 IPs em uma VM por um mês inteiro sai por US$ 55/mês, só de forwarding rules.
Infelizmente, não para por aí. Não faz muito tempo, o GCP começou a cobrar pelos IPs externos, inclusive os que estão em uso (e isso vale tanto para IPs usados por VMs quanto por forwarding rules). O preço de US$ 0,004/h por IP pode parecer insignificante, mas dá US$ 0,004*730h = US$ 2,92/mês e, multiplicado pelos 10 IPs do nosso exemplo, eleva o custo total de manter 10 IPs roteados para a nossa VM para:
US$ 55 + US$ 29,20 ~= US$ 85/mês — só de IPs, antes mesmo de pagar pela VM
Se isso é caro ou não, deixo essa decisão com você :-)
Obrigado pela leitura! Para acompanhar nossos conteúdos, siga-nos no DoiT Engineering Blog , no DoiT Linkedin Channel e no DoiT Twitter Channel . Para conhecer oportunidades de carreira, acesse https://careers.doit.com .