Configura il bilanciamento del carico TCP/UDP interno per appliance di terze parti

Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

In Google Cloud, puoi integrare appliance di terze parti in modo altamente disponibile e scalabile. Per farlo, devi configurare una route statica personalizzata e impostare l'hop successivo sul bilanciatore del carico TCP/UDP interno di Google Cloud. Ciò consente al bilanciatore del carico di eseguire il bilanciamento del carico del traffico per un prefisso di destinazione a un pool di appliance VM di terze parti con controllo di integrità.

Questa guida utilizza un esempio per aiutarti a configurare un bilanciatore del carico TCP/UDP interno come hop successivo. Prima di seguire questa guida, acquisisci familiarità con quanto segue:

Autorizzazioni

Per seguire questa guida, devi creare le istanze e modificare una rete in un progetto. Devi essere un proprietario o un editor del progetto oppure devi disporre di tutti i seguenti ruoli IAM di Compute Engine:

Attività Ruolo richiesto
Crea reti, subnet e componenti del bilanciatore del carico Amministratore rete
Aggiungere e rimuovere regole firewall Amministratore della sicurezza
Creazione delle istanze Amministratore istanze Compute

Per saperne di più, consulta le seguenti guide:

Configurazione di bilanciatori del carico TCP/UDP interni come hop successivi con backend comuni

Questa guida illustra come utilizzare un bilanciatore del carico TCP/UDP interno come hop successivo per una route statica personalizzata al fine di integrare le appliance virtuali scale out.

La soluzione descritta in questa guida crea VM dell'appliance che eseguono Debian Linux e iptables. Le VM di esempio non eseguono alcun filtro dei pacchetti, ma puoi aggiungere questa funzionalità modificando la configurazione iptables di questo esempio o utilizzando diversi software di filtro dei pacchetti o routing.

I passaggi di questa sezione descrivono come configurare le seguenti risorse:

  • Esempi di reti VPC e subnet personalizzate
  • Regole firewall Google Cloud che consentono le connessioni in entrata alle macchine virtuali (VM) dell'appliance di backend
  • Route statiche personalizzate
  • Due VM client per testare le connessioni
  • I seguenti componenti interni del bilanciatore del carico TCP/UDP:
    • VM di backend in un gruppo di istanze gestite (MIG)
    • Un controllo di integrità per le VM di backend
    • Un servizio di backend interno nell'area geografica us-west1 per gestire la distribuzione delle connessioni tra le VM di backend
    • Una regola di forwarding interno e un indirizzo IP interno per il frontend del bilanciatore del carico.

Questo esempio mostra il bilanciamento del carico su più NIC di backend, come descritto in Bilanciamento del carico in più NIC.

La topologia ha il seguente aspetto:

Esempio dettagliato di multi-NIC dell'hop successivo per il bilanciamento del carico TCP/UDP interno
Esempio dettagliato di multi-NIC dell'hop successivo per il bilanciamento del carico TCP/UDP interno (fai clic per ingrandire)

Il diagramma mostra alcune delle risorse create dall'esempio:

  • Le istanze dell'applicazione (in questo caso le VM che eseguono il software iptables) sono dietro a un bilanciatore del carico TCP/UDP interno (fr-ilb1, in questo esempio). Le istanze dell'applicazione hanno solo indirizzi IP interni.
  • Per ogni istanza dell'applicazione è abilitato il flag can-ip-forward. Senza questo flag, una VM di Compute Engine può trasmettere un pacchetto solo se l'indirizzo IP di origine del pacchetto corrisponde all'indirizzo IP interno della VM, a un indirizzo IP di un intervallo IP alias o all'indirizzo IP di una regola di forwarding che risolve la VM. Il flag can-ip-forward modifica questo comportamento in modo che la VM possa trasmettere pacchetti con qualsiasi indirizzo IP di origine.
  • Una route statica personalizzata con destinazione 10.50.1.0/24 e hop successivo impostati sulla regola di forwarding del bilanciatore del carico, fr-ilb1.

Il diagramma mostra inoltre il flusso di traffico:

  • La rete VPC testing ha una route statica personalizzata per il traffico destinato alla subnet 10.50.1.0/24. Questa route indirizza il traffico al bilanciatore del carico.
  • Il bilanciatore del carico inoltra il traffico a una delle istanze dell'applicazione in base all'affinità sessione configurata. (l'affinità sessione influisce solo sul traffico TCP).

Per altri casi d'uso, consulta i bilanciatori del carico TCP/UDP interni come hop successivi.

Configurazione di reti, aree geografiche e subnet

Questo esempio utilizza le reti, le regioni e le subnet VPC seguenti:

  • Reti: questo esempio richiede due reti, ciascuna con almeno una subnet. Ogni VM dell'appliance di terze parti di backend deve avere almeno due interfaccia di rete, una in ogni rete VPC. Le reti in questo esempio sono reti VPC in modalità personalizzata denominate testing e production. La rete testing in questo esempio contiene il client e il bilanciatore del carico. La rete production contiene la VM di destinazione.

  • Regione: le subnet si trovano nella regione us-west1. Le subnet devono trovarsi nella stessa regione perché le istanze VM sono risorse di zona.

  • Subnet: le subnet testing-subnet e production-subnet utilizzano rispettivamente gli intervalli di indirizzi IP principali 10.30.1.0/24 e 10.50.1.0/24.

Per creare reti e subnet di esempio, segui questi passaggi.

Console

Crea la rete testing e la testing-subnet:

  1. In Google Cloud Console, vai alla pagina Reti VPC.

    Vai a Reti VPC

  2. Fai clic su Crea rete VPC.

  3. Inserisci un Nome di testing.

  4. Nella sezione Subnet:

    • Imposta Modalità di creazione subnet su Personalizzata.
    • Nella sezione Nuova subnet, inserisci le seguenti informazioni:
      • Nome: testing-subnet
      • Regione: us-west1
      • Intervallo di indirizzi IP: 10.30.1.0/24
      • Fai clic su Fine.
  5. Fai clic su Create (Crea).

Crea la rete production e la production-subnet:

  1. In Google Cloud Console, vai alla pagina Reti VPC.

    Vai a Reti VPC

  2. Fai clic su Crea rete VPC.

  3. Inserisci un Nome di production.

  4. Nella sezione Subnet:

    • Imposta Modalità di creazione subnet su Personalizzata.
    • Nella sezione Nuova subnet, inserisci le seguenti informazioni:
      • Nome: production-subnet
      • Regione: us-west1
      • Intervallo di indirizzi IP: 10.50.1.0/24
      • Fai clic su Fine.
  5. Fai clic su Create (Crea).

gcloud

  1. Crea le reti VPC personalizzate:

    gcloud compute networks create testing --subnet-mode=custom
    
    gcloud compute networks create production --subnet-mode=custom
    
  2. Crea subnet nelle reti testing e production nell'area geografica us-west1:

    gcloud compute networks subnets create testing-subnet \
        --network=testing \
        --range=10.30.1.0/24 \
        --region=us-west1
    
    gcloud compute networks subnets create production-subnet \
        --network=production \
        --range=10.50.1.0/24 \
        --region=us-west1
    

Configurazione delle regole del firewall

In questo esempio vengono utilizzate le seguenti regole firewall:

  • fw-allow-testing-from-both: una regola in entrata, applicabile a tutti i target nella rete testing. Questa regola consente il traffico proveniente da origini incluse negli intervalli di indirizzi IP 10.30.1.0/24 e 10.50.1.0/24. Questi due intervalli coprono gli indirizzi IP interni principali delle VM in entrambe le reti.

  • fw-allow-production-from-both: una regola in entrata, applicabile a tutti i target nella rete production. Questa regola consente il traffico proveniente da origini incluse negli intervalli di indirizzi IP 10.30.1.0/24 e 10.50.1.0/24. Questi due intervalli coprono gli indirizzi IP interni principali delle VM in entrambe le reti.

  • fw-allow-testing-ssh: una regola in entrata applicata alle istanze VM nella rete VPC testing. Questa regola consente la connettività SSH in entrata sulla porta TCP 22 da qualsiasi indirizzo. Puoi scegliere un intervallo IP di origine più restrittivo per questa regola, ad esempio puoi specificare gli intervalli IP dei sistemi da cui prevedi di avviare sessioni SSH. In questo esempio viene utilizzato il tag di destinazione allow-ssh per identificare le VM a cui si applica la regola del firewall.

  • fw-allow-production-ssh: una regola in entrata applicata alle istanze VM nella rete VPC production. Questa regola consente la connettività SSH in entrata sulla porta TCP 22 da qualsiasi indirizzo. Come per la regola fw-allow-testing-ssh, puoi scegliere un intervallo IP di origine più restrittivo per questa regola.

  • fw-allow-health-check: una regola in entrata per le VM dell'appliance di terze parti in fase di bilanciamento del carico. Questa regola consente il traffico dai sistemi di controllo di integrità di Google Cloud (130.211.0.0/22 e 35.191.0.0/16). In questo esempio viene utilizzato il tag di destinazione allow-health-check per identificare le istanze a cui deve essere applicata.

  • fw-allow-production-health-check: una regola in entrata per le VM dell'appliance di terze parti che viene bilanciata del carico. Questa regola consente il traffico dai sistemi di controllo di integrità di Google Cloud (130.211.0.0/22 e 35.191.0.0/16). In questo esempio viene utilizzato il tag di destinazione allow-health-check per identificare le istanze a cui deve essere applicata.

Senza queste regole firewall, la regola default nega in entrata blocca il traffico in entrata verso le istanze di backend. Devi creare una regola firewall per consentire i controlli di integrità dagli intervalli IP dei sistemi di probe di Google Cloud. Fai riferimento agli intervalli IP del probe per ulteriori informazioni.

Console

  1. In Google Cloud Console, vai alla pagina Firewall.

    Vai a Firewall

  2. Fai clic su Crea regola firewall e inserisci le informazioni seguenti per creare la regola per consentire alle VM di test di ricevere pacchetti dalle subnet di test e di produzione:

    • Nome: fw-allow-testing-from-both
    • Rete: testing
    • Priorità: 1000
    • Direzione del traffico: in entrata
    • Azione in caso di corrispondenza: Consenti
    • Destinazioni: Tutte le istanze nella rete
    • Filtro di origine: Intervalli IPv4
    • Intervalli IPv4 di origine: 10.30.1.0/24, 10.50.1.0/24
    • Protocolli e porte: Consenti tutto
  3. Fai clic su Create (Crea).

  4. Fai clic su Crea regola firewall e inserisci le informazioni seguenti per creare la regola per consentire alle VM di produzione di ricevere pacchetti dai test e dalle subnet di produzione:

    • Nome: fw-allow-production-from-both
    • Rete: production
    • Priorità: 1000
    • Direzione del traffico: in entrata
    • Azione in caso di corrispondenza: Consenti
    • Destinazioni: Tutte le istanze nella rete
    • Filtro di origine: Intervalli IPv4
    • Intervalli IPv4 di origine: 10.30.1.0/24, 10.50.1.0/24
    • Protocolli e porte: Consenti tutto
  5. Fai clic su Create (Crea).

  6. Fai clic su Crea regola firewall per creare la regola per consentire le connessioni SSH in entrata nell'ambiente di test:

    • Nome: fw-allow-testing-ssh
    • Rete: testing
    • Priorità: 1000
    • Direzione del traffico: in entrata
    • Azione in caso di corrispondenza: Consenti
    • Target: Tag di destinazione specificati
    • Tag di destinazione: allow-ssh
    • Filtro di origine: Intervalli IPv4
    • Intervalli IPv4 di origine: 0.0.0.0/0
    • Protocolli e porte: scegli Protocolli e porte specificati e digita: tcp:22
  7. Fai clic su Create (Crea).

  8. Fai clic su Crea regola firewall per creare la regola per consentire le connessioni SSH in entrata nell'ambiente di produzione:

    • Nome: fw-allow-production-ssh
    • Rete: production
    • Priorità: 1000
    • Direzione del traffico: in entrata
    • Azione in caso di corrispondenza: Consenti
    • Target: Tag di destinazione specificati
    • Tag di destinazione: allow-ssh
    • Filtro di origine: Intervalli IPv4
    • Intervalli IPv4 di origine: 0.0.0.0/0
    • Protocolli e porte: scegli Protocolli e porte specificati e digita: tcp:22
  9. Fai clic su Create (Crea).

  10. Fai clic su Crea regola firewall per creare la regola per consentire i controlli di integrità di Google Cloud nell'ambiente di test:

    • Nome: fw-allow-health-check
    • Rete: testing
    • Priorità: 1000
    • Direzione del traffico: in entrata
    • Azione in caso di corrispondenza: Consenti
    • Target: Tag di destinazione specificati
    • Tag di destinazione: allow-health-check
    • Filtro di origine: Intervalli IPv4
    • Intervalli IPv4 di origine: 130.211.0.0/22 e 35.191.0.0/16
    • Protocolli e porte: tcp
  11. Fai clic su Create (Crea).

  12. Fai clic su Crea regola firewall per creare la regola per consentire i controlli di integrità di Google Cloud nell'ambiente di produzione:

    • Nome: fw-allow-production-health-check
    • Rete: production
    • Priorità: 1000
    • Direzione del traffico: in entrata
    • Azione in caso di corrispondenza: Consenti
    • Target: Tag di destinazione specificati
    • Tag di destinazione: allow-health-check
    • Filtro di origine: Intervalli IPv4
    • Intervalli IPv4 di origine: 130.211.0.0/22 e 35.191.0.0/16
    • Protocolli e porte: tcp
  13. Fai clic su Create (Crea).

gcloud

  1. Crea la regola firewall fw-allow-testing-subnet per consentire ai test delle VM di ricevere pacchetti dalle subnet testing e production:

    gcloud compute firewall-rules create fw-allow-testing-from-both \
        --network=testing \
        --action=allow \
        --direction=ingress \
        --source-ranges=10.30.1.0/24,10.50.1.0/24 \
        --rules=all
    
  2. Crea la regola firewall fw-allow-production-subnet per consentire alle VM di produzione di ricevere pacchetti dalle subnet testing e production:

    gcloud compute firewall-rules create fw-allow-production-from-both \
        --network=production \
        --action=allow \
        --direction=ingress \
        --source-ranges=10.30.1.0/24,10.50.1.0/24 \
        --rules=all
    
  3. Crea la regola firewall fw-allow-testing-ssh per consentire la connettività SSH alle VM con tag di rete allow-ssh. Quando ometti source-ranges, Google Cloud interpreta la regola in modo da indicare qualsiasi origine.

    gcloud compute firewall-rules create fw-allow-testing-ssh \
        --network=testing \
        --action=allow \
        --direction=ingress \
        --target-tags=allow-ssh \
        --rules=tcp:22
    
  4. Crea la regola firewall fw-allow-production-ssh per consentire la connettività SSH alle VM con il tag di rete allow-ssh.

    gcloud compute firewall-rules create fw-allow-production-ssh \
        --network=production \
        --action=allow \
        --direction=ingress \
        --target-tags=allow-ssh \
        --rules=tcp:22
    
  5. Crea la regola fw-allow-health-check per consentire i controlli di integrità di Google Cloud alle VM dell'appliance di terze parti nella rete testing.

    gcloud compute firewall-rules create fw-allow-testing-health-check \
        --network=testing \
        --action=allow \
        --direction=ingress \
        --target-tags=allow-health-check \
        --source-ranges=130.211.0.0/22,35.191.0.0/16 \
        --rules=tcp
    
  6. Crea la regola firewall fw-allow-production-health-check per consentire i controlli di integrità di Google Cloud alle VM dell'appliance di terze parti nella rete production.

    gcloud compute firewall-rules create fw-allow-production-health-check \
        --network=production \
        --action=allow \
        --direction=ingress \
        --target-tags=allow-health-check \
        --source-ranges=130.211.0.0/22,35.191.0.0/16 \
        --rules=tcp
    

Creazione di appliance virtuali di terze parti

I seguenti passaggi mostrano come creare un modello di istanza e un gruppo di istanze regionali gestite utilizzando il software iptables come appliance virtuale di terze parti.

Console

Devi utilizzare gcloud per questo passaggio perché devi creare un modello di istanza con più di un'interfaccia di rete. Al momento Google Cloud Console non supporta la creazione di modelli di istanza con più di un'interfaccia di rete.

gcloud

  1. Crea un file locale di nome config.sh e inserisci i seguenti contenuti:

    #!/bin/bash
    # Enable IP forwarding:
    echo 1 > /proc/sys/net/ipv4/ip_forward
    echo "net.ipv4.ip_forward=1" > /etc/sysctl.d/20-iptables.conf
    # Read VM network configuration:
    md_vm="http://169.254.169.254/computeMetadata/v1/instance/"
    md_net="$md_vm/network-interfaces"
    nic0_gw="$(curl $md_net/0/gateway -H "Metadata-Flavor:Google" )"
    nic0_mask="$(curl $md_net/0/subnetmask -H "Metadata-Flavor:Google")"
    nic0_addr="$(curl $md_net/0/ip -H "Metadata-Flavor:Google")"
    nic0_id="$(ip addr show | grep $nic0_addr | awk '{print $NF}')"
    nic1_gw="$(curl $md_net/1/gateway -H "Metadata-Flavor:Google")"
    nic1_mask="$(curl $md_net/1/subnetmask -H "Metadata-Flavor:Google")"
    nic1_addr="$(curl $md_net/1/ip -H "Metadata-Flavor:Google")"
    nic1_id="$(ip addr show | grep $nic1_addr | awk '{print $NF}')"
    # Source based policy routing for nic1
    echo "100 rt-nic1" >> /etc/iproute2/rt_tables
    sudo ip rule add pri 32000 from $nic1_gw/$nic1_mask table rt-nic1
    sleep 1
    sudo ip route add 35.191.0.0/16 via $nic1_gw dev $nic1_id table rt-nic1
    sudo ip route add 130.211.0.0/22 via $nic1_gw dev $nic1_id table rt-nic1
    # Use a web server to pass the health check for this example.
    # You should use a more complete test in production.
    sudo apt-get update
    sudo apt-get install apache2 -y
    sudo a2ensite default-ssl
    sudo a2enmod ssl
    echo "Example web page to pass health check" | \
    tee /var/www/html/index.html
    sudo systemctl restart apache2
    
  2. Crea un modello di istanza per le appliance virtuali di terze parti. Il modello di istanza deve includere il flag --can-ip-forward in modo che le istanze VM create dal modello possano inoltrare pacchetti da altre istanze nelle reti testing e production.

    gcloud compute instance-templates create third-party-template-multinic \
        --region=us-west1 \
        --network-interface subnet=testing-subnet,address="" \
        --network-interface subnet=production-subnet \
        --tags=allow-ssh,allow-health-check,my-network-tag \
        --image-family=debian-10 \
        --image-project=debian-cloud \
        --can-ip-forward \
        --metadata=startup-script="$(< config.sh)"
    
  3. Crea un gruppo di istanze gestite per le tue appliance virtuali di terze parti. Questo comando crea un gruppo di istanze gestite a livello di regione, che può essere scalato automaticamente, in us-west1.

    gcloud compute instance-groups managed create third-party-instance-group \
        --region=us-west1 \
        --template=third-party-template-multinic \
        --size=3
    

Creazione delle risorse di bilanciamento del carico

Questi passaggi configurano tutti i componenti del bilanciatore del carico TCP/UDP interni a partire dal controllo di integrità e dal servizio di backend e poi dai componenti del frontend:

  • Controllo di integrità: in questo esempio, il controllo di integrità HTTP controlla se è presente una risposta HTTP 200 (OK). Per ulteriori informazioni, consulta la sezione Controlli di integrità della panoramica del bilanciamento del carico TCP/UDP interno.

  • Servizio di backend: anche se il servizio di backend di questo esempio specifica il protocollo TCP, quando il bilanciatore del carico è l'hop successivo per una route, Google Cloud inoltra il traffico per tutti i protocolli (TCP, UDP e ICMP).

  • Regola di forwarding: anche se questa regola di forwarding di esempio specifica la porta TCP 80, quando il bilanciatore del carico è l'hop successivo per una route, il traffico su qualsiasi porta TCP o UDP viene inviato ai backend del bilanciatore del carico.

  • Indirizzo IP interno: l'esempio specifica un indirizzo IP interno, 10.30.1.99, per la regola di forwarding.

Console

Crea il primo bilanciatore del carico

  1. In Google Cloud Console, vai alla pagina Bilanciamento del carico.

    Vai a Bilanciamento del carico

  2. Fai clic su Crea bilanciatore del carico.

  3. In Bilanciamento del carico TCP, fai clic su Avvia configurazione.

  4. In Per Internet o solo interno seleziona Solo tra le mie VM.

  5. Fai clic su Continua.

  6. Imposta il Nome su ilb1.

  7. Fai clic su Configurazione backend e apporta le seguenti modifiche:

    1. Regione: us-west1
    2. Rete: testing
    3. In Backend, nella sezione Nuovo elemento, seleziona il gruppo di istanze third-party-instance-group e fai clic su Fine.
    4. In Controllo di integrità, scegli Crea un altro controllo di integrità, inserisci le seguenti informazioni e fai clic su Salva e continua:
      • Nome: hc-http-80
      • Protocollo: HTTP
      • Porta: 80
      • Protocollo proxy: NONE
      • Percorso di richiesta: / Tieni presente che quando utilizzi la console Google Cloud per creare il bilanciatore del carico, il controllo di integrità è globale. Se vuoi creare un controllo di integrità a livello di regione, utilizza gcloud o l'API.
    5. In Affinità sessione, seleziona IP client.
    6. Verifica che sia presente un segno di spunta blu accanto a Configurazione backend prima di continuare. In caso contrario, rivedi questo passaggio.
  8. Fai clic su Configurazione frontend. Nella sezione Nuovo IP e porta frontend apporta le seguenti modifiche:

    1. Nome: fr-ilb1
    2. Subnet: testing-subnet
    3. Da IP interno, scegli Prenota un indirizzo IP interno statico, inserisci le seguenti informazioni e fai clic su Prenota:
      • Nome: ip-ilb
      • Indirizzo IP statico: Scelta manuale
      • Indirizzo IP personalizzato: 10.30.1.99
    4. Porte: scegli Singolo e inserisci 80 come Numero di porta. Ricorda che la scelta di un protocollo e di una porta per il bilanciatore del carico non limita i protocolli e le porte utilizzati quando il bilanciatore del carico è l'hop successivo di una route.
    5. Verifica che sia presente un segno di spunta blu accanto a Configurazione frontend prima di continuare. In caso contrario, rivedi questo passaggio.
  9. Fai clic su Esamina e finalizza. Controlla le impostazioni.

  10. Fai clic su Create (Crea).

Crea il secondo bilanciatore del carico

  1. In Google Cloud Console, vai alla pagina Bilanciamento del carico.

    Vai a Bilanciamento del carico

  2. Fai clic su Crea bilanciatore del carico.

  3. In Bilanciamento del carico TCP, fai clic su Avvia configurazione.

  4. In Per Internet o solo interno, seleziona Solo tra le mie VM.

  5. Fai clic su Continua.

  6. Imposta il Nome su ilb2.

  7. Fai clic su Configurazione backend e apporta le seguenti modifiche:

    1. Regione: us-west1
    2. Rete: production
    3. In Backend, nella sezione Nuovo elemento, seleziona il gruppo di istanze third-party-instance-group e fai clic su Fine.
    4. In Controllo di integrità, seleziona hc-http-80.
    5. In Affinità sessione, seleziona IP client.
    6. Verifica che sia presente un segno di spunta blu accanto a Configurazione backend prima di continuare. In caso contrario, rivedi questo passaggio.
  8. Fai clic su Configurazione frontend. Nella sezione Nuovo IP e porta frontend apporta le seguenti modifiche:

    1. Nome: fr-ilb2
    2. Subnet: production-subnet
    3. Da IP interno, scegli Prenota un indirizzo IP interno statico, inserisci le seguenti informazioni e fai clic su Prenota:
      • Nome: ip-ilb2
      • Indirizzo IP statico: Scelta manuale
      • Indirizzo IP personalizzato: 10.50.1.99
    4. Porte: scegli Singolo e inserisci 80 come Numero di porta. Ricorda che la scelta di un protocollo e di una porta per il bilanciatore del carico non limita i protocolli e le porte utilizzati quando il bilanciatore del carico è l'hop successivo di una route.
    5. Verifica che sia presente un segno di spunta blu accanto a Configurazione frontend prima di continuare. In caso contrario, rivedi questo passaggio.
  9. Fai clic su Esamina e finalizza. Controlla le impostazioni.

  10. Fai clic su Create (Crea).

  11. Configura le risorse del bilanciatore del carico nella rete VPC production.

gcloud

  1. Crea un nuovo controllo di integrità HTTP per verificare la connettività TCP alle VM sull'80.

    gcloud compute health-checks create http hc-http-80 \
        --region=us-west1 \
        --port=80
    
  2. Crea due servizi di backend interni nell'area geografica us-west1.

    gcloud compute backend-services create ilb1 \
        --load-balancing-scheme=internal \
        --health-checks-region=us-west1 \
        --health-checks=hc-http-80 \
        --region=us-west1 \
        --network=testing \
        --session-affinity=CLIENT_IP
    
    gcloud compute backend-services create ilb2 \
        --load-balancing-scheme=internal \
        --health-checks-region=us-west1 \
        --health-checks=hc-http-80 \
        --region=us-west1 \
        --network=production \
        --session-affinity=CLIENT_IP
    
  3. Aggiungi i gruppi di istanze contenenti le appliance virtuali di terze parti come backend sui servizi di backend.

    gcloud compute backend-services add-backend ilb1 \
        --instance-group=third-party-instance-group \
        --instance-group-region=us-west1 \
        --region=us-west1
    
    gcloud compute backend-services add-backend ilb2 \
        --instance-group=third-party-instance-group \
        --instance-group-region=us-west1 \
        --region=us-west1
    
  4. Crea le regole di forwarding interno e collegale ai servizi di backend per completare la configurazione del bilanciatore del carico. Ricorda che il protocollo (TCP) e la porta (80) dei bilanciatori del carico non limitano le porte e i protocolli inoltrati alle istanze di backend (appliance virtuali di terze parti) quando i bilanciatori del carico vengono utilizzati come hop successivi delle route.

    gcloud compute forwarding-rules create fr-ilb1 \
        --load-balancing-scheme=internal \
        --ports=80 \
        --network=testing \
        --subnet=testing-subnet \
        --region=us-west1 \
        --backend-service=ilb1 \
        --address=10.30.1.99
    
    gcloud compute forwarding-rules create fr-ilb2 \
        --load-balancing-scheme=internal \
        --ports=80 \
        --network=production \
        --subnet=production-subnet \
        --region=us-west1 \
        --backend-service=ilb2 \
        --address=10.50.1.99
    

Creazione delle route statiche che definiscono i bilanciatori del carico come hop successivi

Crea due route statiche personalizzate mostrate: next-hop-ilb.

Console

Crea il primo percorso

  1. In Google Cloud Console, vai alla pagina Route.

    Vai a Route

  2. Fai clic su Crea route.

  3. Per il percorso Nome, inserisci ilb-nhop-dest-10-50-1.

  4. Seleziona la rete testing.

  5. In Intervallo IP di destinazione, inserisci 10.50.1.0/24.

  6. Per l'hop successivo della route, seleziona Specifica una regola di forwarding del bilanciatore del carico TCP/UDP interno.

    Per specificare l'indirizzo IP del bilanciatore del carico come hop successivo, utilizza l'interfaccia a riga di comando gcloud o l'API.

  7. Specifica il nome della regola di forwarding. Per il nome della regola di forwarding, seleziona fr-ilb1.

  8. Fai clic su Create (Crea).

Crea il secondo percorso

  1. Fai clic su Crea route.
  2. Per il percorso Nome, inserisci ilb-nhop-dest-10-30-1.
  3. Seleziona la rete testing.
  4. In Intervallo IP di destinazione, inserisci 10.30.1.0/24.
  5. Per l'hop successivo della route, seleziona Specifica una regola di forwarding del bilanciatore del carico TCP/UDP interno.

    Per specificare l'indirizzo IP del bilanciatore del carico come hop successivo, utilizza l'interfaccia a riga di comando gcloud o l'API.

  6. Per il nome della regola di forwarding, seleziona fr-ilb2.

  7. Fai clic su Create (Crea).

gcloud

Crea route avanzate con l'hop successivo impostato sulla regola di forwarding di ogni bilanciatore del carico e ogni intervallo di destinazione impostato di conseguenza.

Per il flag --next-hop-ilb, puoi specificare il nome della regola di forwarding o l'indirizzo IP. Se specifichi l'indirizzo IP, questo indirizzo IP può essere appreso da tutti i peer senza dover esportare la route personalizzata. Nell'esempio, la prima route utilizza l'indirizzo IP 10.30.1.99, mentre la seconda usa il nome della regola di forwarding fr-ilb12.

Facoltativamente, puoi specificare uno o più tag di istanza lungo il percorso. La route può essere applicata a VM specifiche se specifichi tag di rete sul percorso. Se non specifichi alcun tag di rete, la route viene applicata a tutte le VM nella rete VPC. In questo esempio, la route utilizza my-network-tag per il tag di rete del percorso.

gcloud compute routes create ilb-nhop-dest-10-50-1 \
    --network=testing \
    --destination-range=10.50.1.0/24 \
    --next-hop-ilb=10.30.1.99 \
    --tags=my-network-tag
gcloud compute routes create ilb-nhop-dest-10-30-1 \
    --network=production \
    --destination-range=10.30.1.0/24 \
    --next-hop-ilb=fr-ilb2 \
    --next-hop-ilb-region=us-west1

Creazione dell'istanza VM testing in corso...

In questo esempio viene creata un'istanza VM con l'indirizzo IP 10.30.1.100 in testing-subnet (10.30.1.0/24) nella rete VPC testing.

gcloud

  1. Crea il comando testing-vm eseguendo il comando seguente.

    gcloud compute instances create testing-vm \
        --zone=us-west1-a \
        --image-family=debian-10 \
        --image-project=debian-cloud \
        --tags=allow-ssh \
        --subnet=testing-subnet \
        --private-network-ip 10.30.1.100 \
        --metadata=startup-script='#! /bin/bash
        sudo apt-get update
        sudo apt-get install apache2 -y
        sudo a2ensite default-ssl
        sudo a2enmod ssl
        sudo vm_hostname="$(curl -H "Metadata-Flavor:Google" \
        http://169.254.169.254/computeMetadata/v1/instance/name)"
        echo "Page served from: $vm_hostname" | \
        tee /var/www/html/index.html
        sudo systemctl restart apache2'
    

Creazione dell'istanza VM production in corso...

In questo esempio viene creata un'istanza VM con l'indirizzo IP 10.50.1.100 in production-subnet (10.50.1.0/24) nella rete VPC production.

gcloud

Il production-vm può trovarsi in qualsiasi zona della stessa area geografica del bilanciatore del carico e può utilizzare qualsiasi subnet della stessa area geografica. In questo esempio, production-vm si trova nella zona us-west1-a.

  1. Crea il comando production-vm eseguendo il comando seguente.

    gcloud compute instances create production-vm \
        --zone=us-west1-a \
        --image-family=debian-10 \
        --image-project=debian-cloud \
        --tags=allow-ssh \
        --subnet=production-subnet \
        --private-network-ip 10.50.1.100 \
        --metadata=startup-script='#! /bin/bash
        sudo apt-get update
        sudo apt-get install apache2 -y
        sudo a2ensite default-ssl
        sudo a2enmod ssl
        sudo vm_hostname="$(curl -H "Metadata-Flavor:Google" \
        http://169.254.169.254/computeMetadata/v1/instance/name)"
        echo "Page served from: $vm_hostname" | \
        tee /var/www/html/index.html
        sudo systemctl restart apache2'
    

Test del bilanciamento del carico in un deployment con più NIC

  1. Verifica l'integrità dei backend del bilanciatore del carico.

    gcloud compute backend-services get-health ilb1 --region us-west1
    
    gcloud compute backend-services get-health ilb2 --region us-west1
    
  2. Verifica la connettività dalla VM testing.

    gcloud compute ssh testing-vm --zone=us-west1-a
    
    curl http://10.30.1.100
    
    exit
    
  3. Verifica la connettività dalla VM production.

    gcloud compute ssh production-vm --zone=us-west1-a
    
    curl http://10.50.1.100
    

Attivazione dell'hashing simmetrico

Durante il calcolo dell'hash mappato all'istanza di backend, Google Cloud ignora la direzione degli indirizzi IP e delle porte. Il valore hash coerente calcolato di un pacchetto TCP/UDP è lo stesso indipendentemente dalla direzione da cui ha origine il pacchetto. Questa procedura è chiamata hashing simmetrico.

Per abilitare questo comportamento di hashing sui bilanciatori del carico TCP/UDP interni esistenti, devi ricreare la regola di forwarding e la route dell'hop successivo.

Per scoprire di più, consulta la pagina Hash simmetrico.

Eliminare e ricreare le regole di forwarding

Console

Eliminare la regola di forwarding e crearne una nuova

  1. In Google Cloud Console, vai alla pagina Bilanciamento del carico.

    Vai a Bilanciamento del carico

  2. Fai clic sul bilanciatore del carico be-ilb e su Modifica.

  3. Fai clic su Configurazione frontend.

  4. Tieni il puntatore sopra la regola di forwarding, quindi fai clic su Elimina per rimuoverlo.

  5. Fai clic su Aggiungi IP e porta frontend.

  6. Nella sezione Nuovo IP e porta frontend apporta le seguenti modifiche:

    1. Nome: FORWARDING_RULE_NAME
    2. Subnet: SUBNET_NAME
    3. In IP interno, seleziona IP_ADDRESS.
    4. Porte: PORT_NUMBER o ALL.
    5. Fai clic su Fine.
    6. Verifica che sia presente un segno di spunta blu accanto a Configurazione frontend prima di continuare. In caso contrario, rivedi questo passaggio.
  7. Fai clic su Esamina e finalizza. Controlla le impostazioni.

  8. Fai clic su Create (Crea).

gcloud

  1. Elimina le regole di forwarding esistenti.

    gcloud compute forwarding-rules delete FORWARDING_RULE_NAME \
        --region=REGION
    
  2. Crea regole di forwarding sostitutive con lo stesso nome.

    gcloud compute forwarding-rules create FORWARDING_RULE_NAME \
        --load-balancing-scheme=internal \
        --ports=PORT_NUMBER or `ALL` \
        --network=NETWORK_NAME \
        --subnet=SUBNET_NAME \
        --region=REGION \
        --backend-service=BACKEND_SERVICE_NAME \
        --address=IP_ADDRESS
    

Quando la modalità SNAT non è richiesta

Come dimostrato nell'esempio precedente, la rete SNAT (Source Network Address Translation) non è richiesta se tutte le seguenti condizioni sono soddisfatte:

  • La regola di forwarding per il bilanciatore del carico TCP/UDP interno è stata creata il 22 giugno 2021 o in una data successiva.
  • La route statica personalizzata che fa riferimento alla regola di forwarding è stata creata il 22 giugno 2021 o in una data successiva.
  • Il servizio di backend del bilanciatore del carico TCP/UDP interno non utilizza l'impostazione di affinità sessione NONE.

Per convertire una route del bilanciatore del carico TCP/UDP interno esistente per utilizzare l'hashing simmetrico, segui questi passaggi:

  • Assicurati che il servizio di backend del bilanciatore del carico TCP/UDP interno non utilizzi l'impostazione di affinità sessione NONE

  • Creare una regola di forwarding sostitutiva che faccia riferimento allo stesso servizio di backend. La regola di forwarding sostitutiva utilizza un indirizzo IP diverso.

  • Crea una route statica personalizzata sostitutiva che faccia riferimento alla nuova regola di forwarding. Assicurati che la route sostitutiva abbia una priorità più elevata rispetto a quella esistente.

  • Elimina la route esistente a priorità inferiore (che fa riferimento alla regola di forwarding precedente), quindi elimina la regola di forwarding precedente.

Esegui la pulizia

  1. Nella configurazione del bilanciatore del carico, rimuovi il backend dai servizi di backend.

    gcloud compute backend-services remove-backend ilb1 \
        --instance-group=third-party-instance-group \
        --instance-group-region=us-west1 \
        --region=us-west1
    
    gcloud compute backend-services remove-backend ilb2 \
        --instance-group=third-party-instance-group \
        --instance-group-region=us-west1 \
        --region=us-west1
    
  2. Elimina i percorsi.

    gcloud compute routes delete ilb-nhop-dest-10-50-1
    
    gcloud compute routes delete ilb-nhop-dest-10-30-1
    
  3. Nelle configurazioni del bilanciatore del carico, elimina le regole di forwarding.

    gcloud compute forwarding-rules delete fr-ilb1 \
        --region=us-west1
    
    gcloud compute forwarding-rules delete fr-ilb2 \
        --region=us-west1
    
  4. Nelle configurazioni del bilanciatore del carico, elimina i servizi di backend.

    gcloud compute backend-services delete ilb1 \
        --region=us-west1
    
    gcloud compute backend-services delete ilb2 \
        --region=us-west1
    
  5. Nelle configurazioni del bilanciatore del carico, elimina il controllo di integrità.

    gcloud compute health-checks delete hc-http-80 \
        --region=us-west1
    

    Se hai utilizzato Google Cloud Console, il controllo di integrità è globale. Pertanto, il comando è il seguente:

    gcloud compute health-checks delete hc-http-80 \
         --global
    
  6. Elimina il gruppo di istanze gestite.

    gcloud compute instance-groups managed delete third-party-instance-group \
        --region=us-west1
    
  7. Elimina i modelli di istanza.

    gcloud compute instance-templates delete third-party-template
    
    gcloud compute instance-templates delete third-party-template-multinic
    
  8. Elimina le istanze di test e produzione.

    gcloud compute instances delete testing-vm \
        --zone=us-west1-a
    
    gcloud compute instances delete production-vm \
        --zone=us-west1-a
    

Passaggi successivi