Práticas recomendadas para endereços IP flutuantes

Neste documento, descrevemos alternativas ao uso de endereços IP flutuantes ao migrar aplicativos para o Google Compute Engine de um ambiente de rede local. Também conhecidos como endereços IP "compartilhados" ou "virtuais", os IPs flutuantes são muitas vezes usados ​​para deixar os ambientes de rede locais altamente disponíveis. Usar IPs flutuantes permite que você passe um endereço IP entre vários servidores físicos ou virtuais configurados de maneira idêntica, o que permite o failover ou o upgrade do software de produção. No entanto, não é possível implementar diretamente IPs flutuantes em um ambiente do Compute Engine.

IPs flutuantes em ambientes locais

O uso de IPs flutuantes é comum ​em ambientes locais. Na lista a seguir, descrevemos apenas alguns dos casos de uso de IPs flutuantes:

  • Aparelhos físicos altamente disponíveis, como um conjunto de firewalls ou balanceadores de carga, geralmente utilizam IPs flutuantes para failovers.
  • Os servidores que exigem alta disponibilidade normalmente usam IPs flutuantes. Por exemplo, bancos de dados relacionais mestre-escravo, como o Microsoft SQL Server, que usam Grupos de disponibilidade sempre ativados.
  • Os ambientes Linux que implementam balanceadores de carga ou proxies reversos usam IPs flutuantes, como IPVS, HAProxy ou NGINX. Para detectar falhas de nó e mover IPs flutuantes entre instâncias, esses ambientes usam daemons como heartbeat, pacemaker ou keepalived.
  • IPs flutuantes permitem alta disponibilidade com os Serviços Windows por meio do uso do Clustering de failover do Windows Server.

Há várias maneiras de implementar IPs flutuantes em um ambiente local. Em todos os casos, os servidores que compartilham o endereço IP também precisam compartilhar o estado um do outro por meio de um mecanismo de sinal de funcionamento. Esse mecanismo permite aos servidores comunicar o estado de integridade deles um ao outro. Ele também permite que o servidor secundário assuma o endereço IP flutuante depois que o servidor vinculado falhar. Esse esquema é frequentemente implementado por meio do uso do Virtual Router Redundancy Protocol (VRRP), mas você também pode usar outros mecanismos semelhantes.

Depois que um failover de IP é iniciado, o servidor que assume o endereço IP flutuante adiciona o endereço à interface de rede dele. O servidor anuncia essa aquisição para outros dispositivos usando a Camada 2 por meio do envio de um frame gratuito de Protocolo de resolução de endereço (ARP, na sigla em inglês). Como uma abordagem alternativa, o endereço IP às vezes é anunciado por um protocolo de roteamento, como Abrir o caminho mais curto primeiro (OSPF, na sigla em inglês) para o roteador de upstream da Camada 3.

No diagrama a seguir, mostraremos uma configuração típica em um ambiente local.

ambiente típico no local

Você usa uma configuração um pouco diferente com soluções de balanceamento de carga no local, como o Balanceamento de carga de rede do Windows ou o Balanceamento de carga do Linux com resposta do servidor direto - por exemplo, IP Virtual Server (IPVS). Nesses casos, o serviço também envia frames ARP gratuitos, mas com um endereço MAC de outro servidor como fonte ARP gratuita, que essencialmente faz o spoofing dos frames ARP e assume o endereço de origem de outro servidor. Esse tipo de configuração está fora do escopo dessa solução. Em quase todos os casos, a migração para o Balanceamento de carga é o caminho preferido.

Desafios com a migração de IPs flutuantes para o Compute Engine

O Compute Engine usa uma pilha de rede virtualizada em uma Nuvem privada virtual (VPC, na sigla em inglês). Portanto, mecanismos de implementação típicos não funcionam desde o início. Por exemplo, a rede VPC lida com solicitações ARP com base na topologia de roteamento configurada e ignora frames ARP gratuitos. Além disso, é impossível modificar diretamente a tabela de roteamento de rede VPC com protocolos de roteamento padrão, como OSPF ou Border Gateway Protocol (BGP).

Você pode usar uma rede de sobreposição para criar uma configuração que permita a comunicação completa da Camada 2 e a aquisição de IP por meio do uso de solicitações ARP. No entanto, configurar uma rede de sobreposição é complexo e dificulta o gerenciamento de recursos de rede do Compute Engine. Essa abordagem também está fora do escopo dessa solução. Em vez disso, ela oferece abordagens alternativas para implementar cenários de failover em um ambiente de rede nativo do Compute Engine.

Nesta solução, descreveremos as formas de migrar a maioria dos casos de uso abordados no Compute Engine.

Os seguintes guias passo a passo já existem para casos de uso mais específicos:

Caso de uso de exemplo para migração

Nesta solução, descreveremos quatro opções de migração diferentes para fazer a mudança de IPs flutuantes locais para o Compute Engine.

O caso de uso envolve a migração de dois servidores HAProxy internos que direcionam o tráfego para back-ends diferentes, dependendo da correspondência e da substituição complexas do cabeçalho da Camada 7. Devido às regras complexas envolvidas, não é possível substituir esse conjunto de servidores pelo balanceamento de carga interno ou mesmo pelo balanceamento de carga HTTP. Na figura a seguir, mostramos uma visão geral desse caso de uso.

caso de uso de migração

Os servidores HAProxy usam o software keepalived no local para verificar a disponibilidade usando uma conexão cruzada separada e passar os IPs flutuantes entre os dois servidores.

Para este caso de uso, as quatro opções descritas nas seções a seguir são substituições locais válidas para IPs flutuantes. Para outros casos de uso possivelmente mais complexos, poucas opções podem ser relevantes. Depois de descrever essas opções, essa solução fornece orientações sobre opções preferenciais com base em casos de uso específicos.

Na próxima seção, discutiremos como migrar esse cenário de caso de uso para o Compute Engine.

Como fazer implementações usando o Compute Engine

Nesta seção, descreveremos várias maneiras de migrar o cenário local para o Compute Engine. Para reduzir a complexidade, em vez de usar a correspondência baseada em cabeçalho descrita anteriormente, todas as solicitações são encaminhadas para um único grupo de back-ends NGINX com uma configuração de back-end mínima.

Para todos os exemplos, o tráfego é direcionado do HAProxy para um grupo de back-ends do Compute Engine colocado em um grupo de instâncias de escalonamento automático. Esses back-ends são acessados ​​com o uso de um balanceador de carga interno. Na configuração de exemplo, esses back-ends atendem a configuração padrão do NGINX.

Para implementar o caso de uso do exemplo, use um projeto dedicado para teste.

Como configurar os back-ends

Nesta seção, você configura os back-ends NGINX a serem acessados ​​pelos nodes do HAProxy. Como prática recomendada, você cria esses back-ends em uma VPC dedicada a essa implantação em vez da rede padrão.

Para configurar os back-ends, siga estas etapas:

  1. Defina sua zona padrão, por exemplo:

    gcloud config set compute/zone us-central1-f
    
  2. Configure uma rede para testar e definir regras de firewall para permitir o tráfego interno e use o comando ssh para se comunicar com a rede:

    gcloud compute networks create ip-failover
    
    gcloud compute firewall-rules create failover-internal \
        --network ip-failover --allow all --source-ranges 10.128.0.0/11
    
    gcloud compute firewall-rules create failover-ssh \
        --network ip-failover --allow tcp:22 --source-ranges 0.0.0.0/0
    
  3. Crie um modelo de instância para os back-ends NGINX:

    gcloud compute instance-templates create www \
        --machine-type n1-standard-1 --network ip-failover \
        --metadata startup-script="apt-get -y install nginx"
    
  4. Crie um grupo de instâncias gerenciadas por zona de escalonamento automático com base no modelo:

    gcloud compute instance-groups managed create www \
        --template www --size 1 --zone us-central1-f
    
    gcloud compute instance-groups managed set-autoscaling www \
        --max-num-replicas 10 --min-num-replicas 1 \
        --target-cpu-utilization 0.8 --zone us-central1-f
    
  5. Anexe um balanceador de carga interno com um endereço IP fixo (10.128.2.2) a esse grupo de instâncias:

    gcloud compute health-checks create http simple-check
    
    gcloud compute backend-services create www-lb \
        --load-balancing-scheme internal \
        --region us-central1 \
        --health-checks simple-check \
        --protocol tcp
    
    gcloud compute backend-services add-backend www-lb\
        --instance-group www \
        --instance-group-zone us-central1-f \
        --region us-central1
    
    gcloud compute forwarding-rules create www-rule \
        --load-balancing-scheme internal \
        --ports 80 \
        --network ip-failover \
        --region us-central1 \
        --address 10.128.2.2 \
        --backend-service www-lb
    
  6. Crie uma instância para teste e use o comando ssh para se conectar a ele e verifique se você pode alcançar o IP de balanceamento de carga interno:

    gcloud compute instances create testing \
        --machine-type n1-standard-1 --zone us-central1-f \
        --network ip-failover --scopes compute-ro
    
    gcloud compute ssh testing --zone us-central1-f
    

    username@testing:~$ curl 10.128.2.2
    <!DOCTYPE html>
    [...]

    username@testing:~$ exit

Esta configuração de exemplo usa instâncias n1-standard-1, que são limitadas por uma capacidade de rede de dois gigabytes por segundo por instância. Em uma implantação real, você dimensionaria as instâncias de acordo com suas necessidades.

Além disso, as instâncias são criadas com endereços IP externos para que possam fazer o download dos pacotes necessários usando scripts de inicialização. Em uma configuração de produção, você criaria imagens personalizadas e instâncias sem endereços IP externos.

Opção 1: como usar balanceamento de carga interno

Você pode implementar o cenário local no Compute Engine colocando os dois servidores HAProxy em um grupo de instâncias gerenciadas atrás do balanceamento de carga interno e usando o IP de balanceamento de carga interno como um IP virtual, como mostra a figura a seguir.

opção 1: balanceamento de carga interno

Diferenças em comparação com uma configuração local

O IP de balanceamento de carga interno funciona de modo semelhante aos IPs flutuantes no ambiente local, com algumas diferenças notáveis:

  • Distribuição de tráfego

    A diferença mais notável é que o tráfego é compartilhado entre os dois nodes, enquanto na configuração original o tráfego atinge apenas um node por vez. Essa abordagem está correta em um cenário em que o tráfego é direcionado dependendo do conteúdo da solicitação em si, mas não funciona se houver um estado da máquina que não seja sincronizado constantemente, por exemplo, um banco de dados mestre-escravo.

  • Tempo de failover

    O uso de keepalived em um ambiente local quando pareado com ARP gratuito pode apresentar falha em um IP em alguns segundos. No ambiente do Compute Engine, o tempo médio de recuperação depende do modo de falha. Caso a instância da máquina virtual (VM, na sigla em inglês) ou o serviço da instância de VM falhe, o tráfego de tempo médio do failover dependerá de parâmetros de verificação de integridade como Check Interval e Unhealthy Threshold. Com esses parâmetros definidos para os valores padrão, o failover geralmente leva de 15 a 20 segundos, mas pode ser reduzido ao ajustá-los. No Compute Engine, os failovers dentro de zonas ou entre elas levam a mesma quantidade de tempo.

  • Verificação de integridade

    Quando usado no local, além de aguardar um sinal vivo, o keepalived pode verificar a integridade da máquina host de diferentes maneiras, como monitorar a disponibilidade do processo HAProxy. No Compute Engine, a verificação de integridade precisa ser acessada de fora do host usando uma porta HTTP/ HTTPS/TCP ou SSL. Se as especificações do host tiverem que ser verificadas, você precisará instalar um serviço simples na instância para expor essas especificações, ou escolher uma opção alternativa.

  • Portas

    Em uma configuração local, os IPs flutuantes aceitam todo o tráfego, embora o balanceamento de carga interno limite o encaminhamento para um máximo de cinco portas.

Como implementar a opção 1

Para implementar esta solução, conclua as etapas a seguir:

  1. Crie um modelo de instância para seus servidores HAProxy encaminhando as solicitações:

    gcloud compute instance-templates create haproxy \
        --machine-type n1-standard-1 --network ip-failover \
        --metadata "startup-script=
        sudo apt-get install -y haproxy
        cat << EOF >> /etc/haproxy/haproxy.cfg
        frontend www
            bind :80
            option http-server-close
            default_backend web-backend
        backend web-backend
            server web-1 10.128.2.2:80 check
        EOF
        service haproxy restart"
    
  2. Crie um grupo de instâncias zonal com base nos modelos de instância com um tamanho estático de dois. Anexe uma política de recuperação automática às instâncias usando a verificação de integridade criada anteriormente:

    gcloud compute instance-groups managed create haproxy \
        --template haproxy --size 2 --zone us-central1-f
    
    gcloud beta compute instance-groups managed set-autohealing \
        haproxy --health-check simple-check --zone us-central1-f
    
  3. Anexe um balanceador de carga interno aos servidores HAProxy com uma verificação de integridade:

    gcloud compute backend-services create haproxy-lb \
        --load-balancing-scheme internal \
        --region us-central1 \
        --health-checks simple-check \
        --protocol tcp
    gcloud compute backend-services add-backend haproxy-lb\
        --instance-group haproxy \
        --instance-group-zone us-central1-f \
        --region us-central1
    
    gcloud compute forwarding-rules create haproxy-rule \
        --load-balancing-scheme internal \
        --ports 80 \
        --network ip-failover \
        --region us-central1 \
        --address 10.128.1.1 \
        --backend-service haproxy-lb
    
  4. Teste se você pode alcançar o HAProxy por meio de balanceamento de carga interno:

    gcloud compute ssh testing --zone us-central1-f
    

    username@testing:~$ curl 10.128.1.1
    <!DOCTYPE html>
    [...]
    username@testing:~$ exit
    

Depois de excluir uma das instâncias HAProxy por meio do console ou interromper o processo HAProxy em uma das instâncias, o curl ainda será bem-sucedido após um curto tempo de failover.

Opção 2: como usar uma única instância gerenciada

Dependendo dos requisitos de tempo de recuperação, a migração com uma única instância de VM pode ser uma opção viável do Compute Engine, mesmo que vários servidores tenham sido usados no local. A razão é que você pode criar uma nova instância do Compute Engine em minutos, enquanto as falhas no local geralmente exigem horas ou até dias para serem corrigidas.

opção 2: instância gerenciada única

Comparação da opção 2 com a opção 1: balanceamento de carga interno

A opção 2 tem grandes vantagens e desvantagens em relação à opção 1.

Vantagens:

  • Distribuição de tráfego

    Como há apenas uma instância, todo o tráfego atinge uma única instância, semelhante a um cenário de mestre-escravo no local.

  • Economias de custo

    Usar uma única instância de VM em vez de duas pode reduzir o custo da implementação pela metade.

  • Simplicidade

    Essa solução é fácil de implementar e apresenta pouca sobrecarga.

Desvantagens:

  • Tempo de failover

    Depois que as verificações de integridade detectam uma falha na máquina, a exclusão e a recriação da instância que apresentou o problema leva pelo menos um minuto, mas muitas vezes um tempo consideravelmente maior. Esse processo é muito mais lento que a remoção de uma instância do balanceamento de carga interno.

  • Reação a falhas de zona

    Um grupo de instâncias gerenciadas com tamanho 1 não sobrevive a uma falha de zona. Para reagir a falhas de zona, adicione um alerta do Stackdriver Monitoring quando o serviço apresentar falha e crie manualmente um grupo de instâncias em outra zona após uma falha de zona.

Como implementar a opção 2

Complete as etapas a seguir para implementar a opção 2:

  1. Crie um modelo de instância para sua instância de VM HAProxy:

    gcloud compute instance-templates create haproxy-single \
        --machine-type n1-standard-1 --network ip-failover \
        --metadata "startup-script=
        sudo apt-get install -y haproxy
        cat << EOF >> /etc/haproxy/haproxy.cfg
        frontend www
            bind :80
            option http-server-close
            default_backend web-backend
        backend web-backend
            server web-1 10.128.2.2:80 check
        EOF
        service haproxy restart"
    
  2. Crie um grupo de instâncias gerenciadas de tamanho 1 para o HAProxy VM e anexe uma política de recuperação automática:

    gcloud compute instance-groups managed create haproxy-single \
        --template haproxy-single --size 1 --zone us-central1-f
    
    gcloud beta compute instance-groups managed set-autohealing \
        haproxy-single --health-check simple-check --zone us-central1-f
    
  3. Teste se você pode alcançar o HAProxy por meio do IP de balanceamento de carga interno:

    gcloud compute ssh testing --zone us-central1-f
    

    username@testing:~$ instance=$(gcloud compute instances list |awk '$1 ~ /^haproxy-single/ { print $1 }')

    username@testing:~$ curl $instance <!DOCTYPE html> [...]

    username@testing:~$ exit

    Quando você exclui a instância HAProxy ou interrompe o processo dela usando o console, a instância precisa se recuperar automaticamente após um atraso com o mesmo endereço IP e nome da instância.

Opção 3: failover usando rotas prioritárias diferentes

Duas rotas do Compute Engine com prioridades diferentes oferecem outra maneira de ativar o failover de tráfego entre duas instâncias quando não é possível usar o balanceamento de carga interno.

Nesta seção, você cria duas instâncias de VM e as coloca em um grupo de instâncias gerenciadas de recuperação automática com um tamanho estático de 1, o que faz com que o sistema se corrija automaticamente.

Você precisa ativar o encaminhamento de IP em ambas as instâncias. Então, depois de criar as instâncias, você desvia todo o tráfego de IP flutuante para essas duas instâncias, configurando duas rotas com prioridades diferentes para controlar o tráfego.

opção 3: rotas prioritárias diferentes

Comparação da opção 3 com a opção 1: balanceamento de carga interno

Usando a opção 3, você pode migrar casos de uso em que o balanceamento de carga interno não pode ser usado facilmente. Essa opção tem as seguintes vantagens:

  • Distribuição de tráfego

    O tráfego sempre flui para a instância de VM com a menor prioridade. Quando essa instância de VM não está disponível, o tráfego usa a próxima melhor rota. Essa arquitetura se assemelha a um ambiente local em que apenas um servidor está ativo em um determinado momento.

  • Protocolos

    O balanceamento de carga interno é aplicado apenas a um conjunto específico de protocolos ou portas, enquanto as rotas se aplicam a todo o tráfego para um destino específico.

  • Regionalidade

    O balanceamento de carga interno está disponível apenas em uma região, enquanto as rotas podem ser criadas globalmente.

A opção 3 apresenta desvantagens em comparação com a opção 1, que utiliza o balanceamento de carga interno.

  • Verificação de integridade

    Com a opção 3, nenhuma verificação de integridade está anexada a qualquer uma das duas rotas. As rotas são usadas independentemente da integridade dos serviços de VM subjacentes. O tráfego é direcionado para instâncias, mesmo que o serviço esteja em estado não íntegro. Anexar uma política de recuperação automática a essas instâncias as encerra após um período específico de não integridade, mas, depois que elas reiniciam, o tráfego é retomado antes mesmo do serviço, o que pode levar a possíveis erros durante o período em que as instâncias não íntegras ainda estiverem suprindo o tráfego ou no processo de reinicialização.

  • Tempo de failover

    Depois de excluir ou interromper uma instância de VM, a rota será removida automaticamente. No entanto, devido à falta de verificações de integridade, enquanto a instância ainda estiver disponível, a rota ainda será usada. Além disso, interromper a instância leva tempo, então o tempo de failover é consideravelmente maior do que com a abordagem de balanceamento de carga interna.

  • Seleção de endereço IP flutuante

    Você pode definir rotas apenas para endereços IP que não fazem parte de nenhuma sub-rede. O endereço IP flutuante precisa ser escolhido fora de todos os intervalos de sub-rede existentes.

  • Peering de rede VPC

    As instâncias de VMs podem usar apenas as rotas da própria rede VPC e não de redes VPC emparelhadas.

Como implementar a opção 3

Durante a implementação, você usará o endereço IP 10.191.1.1, que está fora de todas as sub-redes ativas na rede ip-failover. Conclua as etapas a seguir:

  1. Crie um modelo de instância para seus servidores HAProxy encaminhando as solicitações:

    gcloud compute instance-templates create haproxy-route \
        --machine-type n1-standard-1 --network ip-failover \
        --metadata "startup-script=
        apt-get update
        apt-get install -y haproxy
        cat << EOF >> /etc/haproxy/haproxy.cfg
        frontend www
            bind :80
            option http-server-close
            default_backend web-backend
        backend web-backend
            server web-1 10.128.2.2:80 check
        EOF
        cat << EOF >> /etc/network/interfaces
        auto eth0:0
        iface eth0:0 inet static
            address 10.191.1.1
            netmask 255.255.255.255
        EOF
        service haproxy restart
        service networking restart" --can-ip-forward
    
  2. Crie dois grupos de instâncias gerenciadas, ambos de tamanho 1, para suas instâncias de VM HAProxy e anexe a eles uma política de recuperação automática:

    gcloud compute instance-groups managed create haproxy-r1 \
        --template haproxy-route --size 1 --zone us-central1-f
    
    gcloud beta compute instance-groups managed set-autohealing \
        haproxy-r1 --health-check simple-check --zone us-central1-f
    
    gcloud compute instance-groups managed create haproxy-r2 \
        --template haproxy-route --size 1 --zone us-central1-b
    
    gcloud beta compute instance-groups managed set-autohealing \
        haproxy-r2 --health-check simple-check --zone us-central1-b
    
  3. Crie uma rota primária e de backup para essas instâncias de VM após serem inicializadas:

    haproxy1=$(gcloud compute instances list |awk '$1 \
        ~ /^haproxy-r1/ { print $1 }')
        #save the instance name of the first HAproxy instance
    
    haproxy2=$(gcloud compute instances list |awk '$1 \
        ~ /^haproxy-r2/ { print $1 }')
        #save the instance name of the second HAproxy instance
    
    gcloud compute routes create haproxy-route1 \
        --destination-range 10.191.1.1/32 --network ip-failover \
        --priority 500 --next-hop-instance-zone us-central1-f \
        --next-hop-instance $haproxy1
    
    gcloud compute routes create haproxy-route2 \
        --destination-range 10.191.1.1/32 --network ip-failover \
        --priority 600 --next-hop-instance-zone us-central1-b \
        --next-hop-instance $haproxy2
    
  4. Teste se você pode alcançar o HAProxy por meio da rota:

    gcloud compute ssh testing --zone us-central1-f
    

    username@testing:~$ curl 10.191.1.1

    <!DOCTYPE html> [...]

    username@testing:~$ exit

    Quando você exclui a instância HAProxy principal por meio do console, a rota para a instância secundária precisa ser usada assim que a instância estiver completamente desativada.

Opção 4: failover com o uso de chamadas de API de rotas

Como a opção 3, a opção 4 também usa rotas, mas difere de maneiras importantes. Em vez da recuperação automática e da recriação de instâncias, o keepalived ou outros scripts usam chamadas de API para adicionar uma rota a uma nova instância íntegra ou remover uma rota de uma instância não íntegra. Essa abordagem é útil em situações em que não é possível usar as verificações de integridade do Compute Engine para rastrear a integridade do aplicativo ou determinar qual máquina virtual é a principal. Qualquer lógica de aplicativo pode acionar a reprogramação dinâmica de rotas.

O uso de chamadas de API de rotas como um método de failover também é útil quando as falhas do aplicativo são investigadas e as instâncias são colocadas on-line novamente de modo manual. No entanto, como as VMs precisam registrar todas as falhas e ser substituídas automaticamente à medida que se tornam íntegras, não investigue as falhas manualmente no Compute Engine.

opção 4: failover com o uso de chamadas de API de rotas

Comparação das diferenças da opção 4: balanceamento de carga interno

Em contraste com o uso do balanceamento de carga interno, a opção 4 oferece estas vantagens:

  • Distribuição de tráfego

    Tal como acontece com as opções 2 e 3, o tráfego atinge apenas uma instância de VM por vez.

  • Nenhuma dependência de verificações de integridade do Compute Engine

    O failover pode ser acionado por qualquer lógica de aplicativo personalizado. Com a opção 4, você usa um script para gerenciar reações do keepalived a falhas de comunicação entre HAProxies primários e secundários. Essa é a única opção que funciona quando não é possível ou não é desejável usar as verificações de integridade do Compute Engine.

A opção 4 também tem grandes desvantagens:

  • Complexidade

    Esta opção precisa ser criada de maneira personalizada usando a Compute Engine API ou chamadas gcloud para remover e definir uma nova rota usando a Compute Engine API. Construir essa lógica de modo confiável é muitas vezes complexo.

  • Tempo de failover

    Como são exigidas pelo menos duas chamadas da Compute Engine API por um script personalizado para remover e criar uma nova rota no Compute Engine, o failover é ligeiramente mais lento do que com um balanceador de carga interno.

  • Seleção de endereço IP flutuante

    Você pode definir rotas apenas para endereços IP que não fazem parte de nenhuma sub-rede. Os endereços IP flutuantes precisam ser escolhidos fora de todos os intervalos de sub-rede existentes.

  • Peering de rede VPC

    As instâncias de VMs podem usar apenas as rotas da própria rede VPC e não de redes VPC emparelhadas.

Como implementar a opção 4

Esta implementação usa o endereço IP 10.190.1.1, que está fora de todas as sub-redes ativas na rede ip-failover. A rota para este endereço será automaticamente criada e excluída pelo keepalived.

Primeiro, você cria duas instâncias HAProxy com haproxy e keepalived instalados usando IPs internos estáticos para ambas. Você também precisa ativar o encaminhamento de IP para poder encerrar a rota e exigir acesso à Compute Engine API. Para facilitar o processo, você não usará grupos e modelos de instâncias neste exemplo.

Crie a opção 4 com as seguintes etapas:

  1. Crie a instância principal com um endereço IP estático de 10.128.4.100:

    gcloud compute instances create haproxy-a \
        --machine-type n1-standard-1 --network ip-failover \
        --can-ip-forward --private-network-ip=10.128.4.100 \
        --scopes compute-rw --zone us-central1-f \
        --metadata 'startup-script=
        apt-get update
        apt-get install -y haproxy keepalived
        cat << EOF >> /etc/haproxy/haproxy.cfg
        frontend www
            bind :80
            option http-server-close
            default_backend web-backend
        backend web-backend
            server web-1 10.128.2.2:80 check
        EOF
        cat << EOF >> /etc/network/interfaces
        auto eth0:0
        iface eth0:0 inet static
            address 10.190.1.1
            netmask 255.255.255.255
        EOF
        cat << EOF >> /etc/keepalived/keepalived.conf
        vrrp_script haproxy {
            script "/bin/pidof haproxy"
            interval 2
        }
    
        vrrp_instance floating_ip {
            state MASTER
            interface eth0
            track_script {
                haproxy
            }
            unicast_src_ip 10.128.4.100
            unicast_peer {
                10.128.4.200
            }
            virtual_router_id 50
            priority 100
            authentication {
                auth_type PASS
                auth_pass yourpassword
            }
            notify_master /etc/keepalived/takeover.sh
        }
        EOF
        cat << EOF >> /etc/keepalived/takeover.sh
        #!/bin/bash
        gcloud compute routes delete floating --quiet
        gcloud compute routes create floating \
            --destination-range 10.190.1.1/32 --network ip-failover \
            --priority 500 --next-hop-instance-zone us-central1-f \
            --next-hop-instance haproxy-a --quiet
        EOF
        chmod +x /etc/keepalived/takeover.sh
        service haproxy restart
        service networking restart
        service keepalived start'
    
  2. Crie a instância secundária com um endereço IP estático de 10.128.4.200:

    gcloud compute instances create haproxy-b \
        --machine-type n1-standard-1 --network ip-failover \
        --can-ip-forward --private-network-ip=10.128.4.200 \
        --scopes compute-rw --zone us-central1-c \
        --metadata 'startup-script=
        apt-get update
        apt-get install -y haproxy keepalived
        cat << EOF >> /etc/haproxy/haproxy.cfg
        frontend www
            bind :80
            option http-server-close
            default_backend web-backend
        backend web-backend
            server web-1 10.128.2.2:80 check
        EOF
        cat << EOF >> /etc/network/interfaces
        auto eth0:0
        iface eth0:0 inet static
            address 10.190.1.1
            netmask 255.255.255.255
        EOF
        cat << EOF >> /etc/keepalived/keepalived.conf
        vrrp_script haproxy {
            script "/bin/pidof haproxy"
            interval 2
        }
    
        vrrp_instance floating_ip {
            state BACKUP
            interface eth0
            track_script {
                haproxy
            }
            unicast_src_ip 10.128.4.200
            unicast_peer {
                10.128.4.100
            }
            virtual_router_id 50
            priority 50
            authentication {
                auth_type PASS
                auth_pass yourpassword
            }
            notify_master /etc/keepalived/takeover.sh
        }
        EOF
        cat << EOF >> /etc/keepalived/takeover.sh
        #!/bin/bash
        gcloud compute routes delete floating --quiet
        gcloud compute routes create floating \
            --destination-range 10.190.1.1/32 --network ip-failover \
            --priority 500 --next-hop-instance-zone us-central1-c \
            --next-hop-instance haproxy-b --quiet
        EOF
        chmod +x /etc/keepalived/takeover.sh
        service haproxy restart
        service networking restart
        service keepalived start'
    
  3. Teste se você pode alcançar o HAProxy por meio da rota:

    gcloud compute ssh testing --zone us-central1-f
    

    username@testing:~$ curl 10.190.1.1

    <!DOCTYPE html> [...]

    username@testing:~$ exit

    Quando o HAProxy na instância haproxy-a é eliminado ou a instância é bloqueada, os sinais de funcionamento do VRRP desaparecem e a instância haproxy-b invoca o script takeover.sh. Esse script move a rota para 10.190.1.1 de haproxy-a para haproxy-b, e o teste ainda funcionará.

Como escolher a melhor opção para seu caso de uso

Para os casos de uso de exemplo envolvendo um conjunto de nodes de HAProxy que tomam decisões de roteamento complexas, a implementação preferida do Compute Engine é a Opção 1: balanceamento de carga interno. Isso ocorre porque as instâncias de VM são sem estado e podem funcionar facilmente em um cenário ativo-ativo. Além disso, as verificações de integridade do Compute Engine podem ser usadas. Com outros casos de uso, a opção 1 pode não ser a melhor escolha.

Além das vantagens e desvantagens listadas anteriormente para cada opção, a árvore de decisão a seguir pode ajudar você a escolher um esquema de implementação.

árvore de decisão

Aplicativos altamente disponíveis e confiáveis ​​são melhor implementados no Compute Engine usando arquiteturas de escalonamento horizontal, minimizando o impacto de uma falha de node único. A migração de um cenário local típico, como dois servidores com IPs flutuantes, é um desafio porque esse cenário não pode ser duplicado no Compute Engine. Conforme mencionado anteriormente, o deslocamento de endereços IP entre máquinas diferentes em subseções que usam ARP gratuito não funciona devido à natureza da infraestrutura do roteamento virtual.

O balanceamento de carga interno permite que muitos casos de uso sejam transferidos de maneira simples e confiável para o Compute Engine. Nos casos em que não é possível usar um balanceador de carga interno, você pode implementar várias outras opções que não exigem mecanismos de roteamento de sobreposição complexos.

Próximas etapas

Esta página foi útil? Conte sua opinião sobre:

Enviar comentários sobre…

Documentação do Compute Engine