Práticas recomendadas para endereços IP flutuantes

Nesta solução, descrevemos alternativas ao uso de endereços IP flutuantes na migração de aplicativos para o Compute Engine a partir de um ambiente de rede local. Também chamados de endereços IP "compartilhados" ou "virtuais", os endereços IP flutuantes costumam ser usados para tornar os ambientes de rede locais altamente disponíveis. Usar endereços IP 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 endereços IP flutuantes em um ambiente do Compute Engine.

Endereços IP flutuantes em ambientes locais

O uso de endereços IP flutuantes é comum em ambientes locais. Na lista a seguir, descrevemos apenas alguns dos casos de uso de endereços IP flutuantes:

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

Há várias maneiras de implantar endereços IP 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 implantado por meio do uso do Virtual Router Redundancy Protocol (VRRP) (em inglês), mas também é possível 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 local típico

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 balanceamento de carga é o caminho preferido.

Desafios da migração de endereços IP 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 implantação típicos não costumam funcionar. 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 endereços IP 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 TCP/UDP 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 endereços IP flutuantes entre os dois servidores.

Nesse caso de uso, todas as quatro opções descritas nas seções a seguir são substitutos locais válidos para endereços IP flutuantes. Para outros casos de uso possivelmente mais complexos, talvez haja menos opções 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 (em inglês) 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 TCP/UDP. Na configuração de exemplo, esses back-ends atendem à configuração padrão do NGINX (em inglês).

Para implantar 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 nós 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 zonal 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 TCP/UDP 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 ela e verificar se é possível acessar o endereço IP do balanceamento de carga interno TCP/UDP:

    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 2 GB 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 o balanceamento de carga interno TCP/UDP

É possível 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 TCP/UDP e usando o endereço IP do balanceamento de carga interno TCP/UDP como endereço IP virtual, conforme mostrado na figura a seguir.

opção 1: balanceamento de carga interno TCP/UDP

Supõe-se que o serviço migrado local seja exposto apenas internamente. Se o serviço que está tentando migrar estiver disponível externamente, será possível implementar esse cenário de modo semelhante usando balanceamento de carga HTTP(S), proxy TCP, proxy SSL ou balanceamento de carga de rede.

As opções a seguir são somente Beta e também estão disponíveis:

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

O endereço IP do balanceamento de carga interno TCP/UDP funciona de forma semelhante aos endereços IP 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 nós, enquanto na configuração original o tráfego atinge apenas um nó 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 com os valores padrão, o failover geralmente leva de 15 a 20 segundos, mas isso pode ser reduzido com um ajuste nos parâmetros. No Compute Engine, os failovers dentro de zonas ou entre elas levam a mesma fração de tempo.

  • Verificação de integridade

    Quando usado no local, além de aguardar um sinal de atividade, 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 endereços IP flutuantes aceitam todo o tráfego. Para o balanceador de carga interno TCP/UDP, é necessário escolher uma das especificações de porta a seguir na regra de encaminhamento interno:

    • Especifique pelo menos uma e até cinco portas, por número.
    • Especifique ALL para encaminhar tráfego em todas as 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 compute instance-groups managed update \
        haproxy --health-check simple-check --zone us-central1-f
    
  3. Anexe um balanceador de carga interno TCP/UDP 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 é possível alcançar o HAProxy por meio de balanceamento de carga interno TCP/UDP:

    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 (em inglês) 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. O motivo é que é possível 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 TCP/UDP

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 TCP/UDP.

  • 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 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 a VM HAProxy 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 compute instance-groups managed update \
        haproxy-single --health-check simple-check --zone us-central1-f
    
  3. Teste se é possível alcançar o HAProxy por meio do IP de balanceamento de carga interno TCP/UDP:

    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 com o uso de rotas prioritárias diferentes

Quando não for possível usar o balanceamento de carga interno TCP/UDP para ativar o failover de tráfego entre duas instâncias, use duas rotas do Compute Engine com prioridades diferentes.

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 o tamanho estático 1, permitindo a recuperação automática do sistema.

Você precisa ativar o encaminhamento de IP em ambas as instâncias. 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 TCP/UDP

Usando a opção 3, é possível migrar casos de uso em que o balanceamento de carga interno TCP/UDP 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 TCP/UDP é 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 TCP/UDP 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 TCP/UDP.

  • 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 não esteja í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 interno TCP/UDP.

  • 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 compute instance-groups managed update \
        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 compute instance-groups managed update \
        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 TCP/UDP

Ao contrário do uso do balanceamento de carga interno TCP/UDP, a opção 4 oferece as seguintes 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 API Compute Engine ou chamadas gcloud para remover e definir uma nova rota usando a API Compute Engine. Construir essa lógica de modo confiável é muitas vezes complexo.

  • Tempo de failover

    Como são exigidas pelo menos duas chamadas da API Compute Engine 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 esse endereço será automaticamente criada e excluída pelo keepalived.

Primeiro, você cria duas instâncias HAProxy com haproxy e keepalived instalados usando endereços IP internos estáticos para ambas. Você também precisa ativar o encaminhamento de IP para poder encerrar a rota e exigir acesso à API Compute Engine. 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 que envolvem um conjunto de nós HAProxy que tomam decisões de roteamento complexas, a implantação recomendada do Compute Engine é a Opção 1: balanceamento de carga interno TCP/UDP. Isso 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 implantados no Compute Engine usando arquiteturas de escalonamento horizontal, minimizando o impacto de uma falha de nó único. A migração de um cenário local típico, como dois servidores com endereços IP flutuantes, é um desafio porque esse cenário não pode ser duplicado no Compute Engine. Conforme mencionado anteriormente, mover 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 TCP/UDP 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, há várias outras opções que não exigem mecanismos de roteamento sobrepostos complexos.

Próximas etapas

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

Enviar comentários sobre…

Documentação do Compute Engine