In Google Cloud, puoi integrare le appliance di terze parti in modo estremamente scalabile. Per farlo, dovrai configurare una route statica personalizzata e impostare l'hop successivo sul bilanciatore del carico TCP/UDP interno di Google Cloud. In questo modo, il bilanciatore del carico può bilanciare il carico del traffico per un prefisso di destinazione a un pool di appliance VM di terze parti verificate.
Questa guida illustra un esempio per imparare a configurare un bilanciatore del carico TCP/UDP interno come hop successivo. Prima di seguire questa guida, acquisisci familiarità con quanto segue:
- Concetti relativi al bilanciamento del carico TCP/UDP interno
- Bilanciatori del carico TCP/UDP interni come hop successivi
Autorizzazioni
Per seguire questa guida, devi creare 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 di rete |
Aggiungi e rimuovi regole firewall | Amministratore sicurezza |
Creare istanze | Amministratore istanze Compute |
Per ulteriori informazioni, 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 appliance virtuali sottoposte a 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 filtri o pacchetti di
software di routing diversi.
I passaggi di questa sezione descrivono come configurare le seguenti risorse:
- Esempi di reti VPC e subnet personalizzate
- Regole firewall di 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 del bilanciatore del carico TCP/UDP interno:
- 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 in più NIC di backend, come descritto in Bilanciamento del carico in più NIC.
La topologia si presenta così:
Il diagramma mostra alcune delle risorse create dall'esempio:
- Le istanze dell'applicazione (in questo caso, le VM che eseguono il software
iptables
) dietro un bilanciatore del carico TCP/UDP interno (in questo esempio,fr-ilb1
). 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 da un intervallo IP alias o a un indirizzo IP di una regola di forwarding che risolve la VM. Il flagcan-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 anche il flusso di traffico:
- La rete VPC
testing
ha una route statica personalizzata per il traffico destinato alla subnet10.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 l'articolo dei bilanciatori del carico TCP/UDP interni come hop successivi.
Configurazione di reti, area geografica e subnet
Questo esempio utilizza le seguenti reti VPC, area geografica e subnet:
Reti: in questo esempio sono richieste 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 di questo esempio sono reti VPC in modalità personalizzata denominate
testing
eproduction
. La retetesting
in questo esempio contiene il client e il bilanciatore del carico. La reteproduction
contiene la VM di destinazione target.Area geografica: le subnet si trovano nell'area geografica
us-west1
. Le subnet devono trovarsi nella stessa area geografica perché le istanze VM sono risorse di zona.Subnet: le subnet
testing-subnet
eproduction-subnet
utilizzano rispettivamente gli intervalli di indirizzi IP principali10.30.1.0/24
e10.50.1.0/24
.
Per creare reti e subnet di esempio, segui questi passaggi.
console
Crea la rete testing
e testing-subnet
:
In Google Cloud Console, vai alla pagina Reti VPC.
Fai clic su Crea rete VPC.
Inserisci un Nome di
testing
.Nella sezione Subnet:
- Imposta la modalità di creazione subnet su Personalizzata.
- Nella sezione Nuova subnet, inserisci le seguenti informazioni:
- Nome:
testing-subnet
- Area geografica:
us-west1
- Intervallo di indirizzi IP:
10.30.1.0/24
- Fai clic su Fine.
- Nome:
Fai clic su Crea.
Crea la rete production
e production-subnet
:
In Google Cloud Console, vai alla pagina Reti VPC.
Fai clic su Crea rete VPC.
Inserisci un Nome di
production
.Nella sezione Subnet:
- Imposta la modalità di creazione subnet su Personalizzata.
- Nella sezione Nuova subnet, inserisci le seguenti informazioni:
- Nome:
production-subnet
- Area geografica:
us-west1
- Intervallo di indirizzi IP:
10.50.1.0/24
- Fai clic su Fine.
- Nome:
Fai clic su Crea.
gcloud
Crea le reti VPC personalizzate:
gcloud compute networks create testing --subnet-mode=custom
gcloud compute networks create production --subnet-mode=custom
Crea subnet nelle reti
testing
eproduction
nell'area geograficaus-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 retetesting
. Questa regola consente il traffico dalle origini negli intervalli di indirizzi IP di10.30.1.0/24
e10.50.1.0/24
. Questi due intervalli riguardano 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 reteproduction
. Questa regola consente il traffico dalle origini negli intervalli di indirizzi IP di10.30.1.0/24
e10.50.1.0/24
. Questi due intervalli riguardano 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 VPCtesting
. Questa regola consente la connettività SSH in entrata sulla porta TCP22
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 le sessioni SSH. Questo esempio utilizza il tag di destinazioneallow-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 VPCproduction
. Questa regola consente la connettività SSH in entrata sulla porta TCP22
da qualsiasi indirizzo. Come per la regolafw-allow-testing-ssh
, puoi scegliere un intervallo IP di origine più restrittivo.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
e35.191.0.0/16
). In questo esempio viene utilizzato il tag di destinazioneallow-health-check
per identificare le istanze a cui deve essere applicato.fw-allow-production-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
e35.191.0.0/16
). In questo esempio viene utilizzato il tag di destinazioneallow-health-check
per identificare le istanze a cui deve essere applicato.
Senza queste regole firewall, la regola predefinita per il traffico 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. Per ulteriori informazioni, consulta l'articolo sugli intervalli IP dei probe.
console
In Google Cloud Console, vai alla pagina Firewall.
Fai clic su Crea regola firewall e inserisci le seguenti informazioni per creare la regola per consentire alle VM di test di ricevere i pacchetti dai test e dalle subnet di produzione:
- Nome:
fw-allow-testing-from-both
- Rete:
testing
- Priorità:
1000
- Direzione del traffico: in entrata
- Azione in caso di corrispondenza: consenti
- Target: tutte le istanze della rete.
- Filtro di origine: intervalli IPv4
- Intervalli IPv4 di origine:
10.30.1.0/24
,10.50.1.0/24
- Protocolli e porte: consenti tutti
- Nome:
Fai clic su Crea.
Fai clic su Crea regola firewall e inserisci le informazioni seguenti per creare la regola in modo da 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
- Target: tutte le istanze della rete.
- Filtro di origine: intervalli IPv4
- Intervalli IPv4 di origine:
10.30.1.0/24
,10.50.1.0/24
- Protocolli e porte: consenti tutti
- Nome:
Fai clic su Crea.
Fai clic su Crea regola firewall per creare una regola che consenta 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 target 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
- Nome:
Fai clic su Crea.
Fai clic su Crea regola firewall per creare una regola che consenta 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 target 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
- Nome:
Fai clic su Crea.
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 target specificati
- Tag di destinazione:
allow-health-check
- Filtro di origine: intervalli IPv4
- Intervalli IPv4 di origine:
130.211.0.0/22
e35.191.0.0/16
- Protocolli e porte:
tcp
- Nome:
Fai clic su Crea.
Fai clic su Crea regola firewall per creare una regola che consenta 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 target specificati
- Tag di destinazione:
allow-health-check
- Filtro di origine: intervalli IPv4
- Intervalli IPv4 di origine:
130.211.0.0/22
e35.191.0.0/16
- Protocolli e porte:
tcp
- Nome:
Fai clic su Crea.
gcloud
Crea la regola firewall
fw-allow-testing-subnet
per consentire alle VM di test di ricevere i pacchetti dalle subnettesting
eproduction
: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
Crea la regola firewall
fw-allow-production-subnet
per consentire alle VM di produzione di ricevere pacchetti dalle subnettesting
eproduction
: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
Crea la regola firewall
fw-allow-testing-ssh
per consentire la connettività SSH alle VM con il tag di reteallow-ssh
. Se omettisource-ranges
, Google Cloud interpreta la regola per 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
Crea la regola firewall
fw-allow-production-ssh
per consentire la connettività SSH alle VM con il tag di reteallow-ssh
.gcloud compute firewall-rules create fw-allow-production-ssh \ --network=production \ --action=allow \ --direction=ingress \ --target-tags=allow-ssh \ --rules=tcp:22
Crea la regola
fw-allow-health-check
per consentire i controlli di integrità di Google Cloud alle VM dell'appliance di terze parti nella retetesting
.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
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 reteproduction
.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 passaggi seguenti spiegano come creare un modello di istanza e un gruppo di istanze regionali gestite mediante 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. Google Cloud Console non supporta al momento la creazione di modelli di istanza con più di un'interfaccia di rete.
gcloud
Crea un file locale denominato
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
Crea un modello di istanza per le tue 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 retitesting
eproduction
.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 \ --image-family=debian-10 \ --image-project=debian-cloud \ --can-ip-forward \ --metadata=startup-script="$(< config.sh)"
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 area geografica, 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 interno che iniziano con il controllo di integrità e il servizio di backend, quindi i componenti 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 questo servizio di backend di 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
In Google Cloud Console, vai alla pagina Bilanciamento del carico.
Fai clic su Crea bilanciatore del carico.
In Bilanciamento del carico TCP, fai clic su Avvia configurazione.
Nella sezione Solo per Internet o interno, seleziona Solo tra le mie VM.
Fai clic su Continua.
Imposta il Nome su
ilb1
.Fai clic su Configurazione backend e apporta le seguenti modifiche:
- Area geografica:
us-west1
- Rete:
testing
- In Backend, nella sezione Nuovo elemento, seleziona il gruppo di istanze
third-party-instance-group
e fai clic su Fine. - 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 richiesta:
/
Tieni presente che quando utilizzi Google Cloud Console per creare il bilanciatore del carico, il controllo di integrità è globale. Se vuoi creare un controllo di integrità regionale, utilizzagcloud
o l'API.
- Nome:
- In Affinità sessione, seleziona IP client.
- Verifica che sia presente un segno di spunta blu accanto a Configurazione backend prima di continuare. In caso contrario, rivedi questo passaggio.
- Area geografica:
Fai clic su Configurazione frontend. Nella sezione Nuovo IP e porta frontend, apporta le seguenti modifiche:
- Nome:
fr-ilb1
- Subnet:
testing-subnet
- In IP interno, scegli Prenota un indirizzo IP interno statico,
inserisci le seguenti informazioni e fai clic su Prenota:
- Nome:
ip-ilb
- Indirizzo IP statico: Fammi scegliere
- Indirizzo IP personalizzato:
10.30.1.99
- Nome:
- Porte: scegli Single (Singola) 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. - Prima di continuare, verifica che sia presente un segno di spunta blu accanto a Configurazione frontend. In caso contrario, rivedi questo passaggio.
- Nome:
Fai clic su Esamina e finalizza. Ricontrolla le impostazioni.
Fai clic su Crea.
Crea il secondo bilanciatore del carico
In Google Cloud Console, vai alla pagina Bilanciamento del carico.
Fai clic su Crea bilanciatore del carico.
In Bilanciamento del carico TCP, fai clic su Avvia configurazione.
Nella sezione Solo per Internet o interno, seleziona Solo tra le mie VM.
Fai clic su Continua.
Imposta il Nome su
ilb2
.Fai clic su Configurazione backend e apporta le seguenti modifiche:
- Area geografica:
us-west1
- Rete:
production
- In Backend, nella sezione Nuovo elemento, seleziona il gruppo di istanze
third-party-instance-group
e fai clic su Fine. - In Controllo di integrità, seleziona
hc-http-80
. - In Affinità sessione, seleziona IP client.
- Verifica che sia presente un segno di spunta blu accanto a Configurazione backend prima di continuare. In caso contrario, rivedi questo passaggio.
- Area geografica:
Fai clic su Configurazione frontend. Nella sezione Nuovo IP e porta frontend, apporta le seguenti modifiche:
- Nome:
fr-ilb2
- Subnet:
production-subnet
- In IP interno, scegli Prenota un indirizzo IP interno statico,
inserisci le seguenti informazioni e fai clic su Prenota:
- Nome:
ip-ilb2
- Indirizzo IP statico: Fammi scegliere
- Indirizzo IP personalizzato:
10.50.1.99
- Nome:
- Porte: scegli Single (Singola) 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. - Prima di continuare, verifica che sia presente un segno di spunta blu accanto a Configurazione frontend. In caso contrario, rivedi questo passaggio.
- Nome:
Fai clic su Esamina e finalizza. Ricontrolla le impostazioni.
Fai clic su Crea.
Configura le risorse del bilanciatore del carico nella rete VPC
production
.
gcloud
Crea un nuovo controllo di integrità HTTP per testare la connettività TCP per le VM su 80.
gcloud compute health-checks create http hc-http-80 \ --region=us-west1 \ --port=80
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
Aggiungi i gruppi di istanze contenenti le appliance virtuali di terze parti come backend nei 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
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 che vengono inoltrati alle istanze di backend (le 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
In Google Cloud Console, vai alla pagina Route.
Fai clic su Crea percorso.
Per il nome del percorso, inserisci
ilb-nhop-dest-10-50-1
.Seleziona la rete
testing
.In Intervallo IP di destinazione, inserisci
10.50.1.0/24
.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.
Specifica il nome della regola di forwarding. Per il nome della regola di forwarding, seleziona
fr-ilb1
.Fai clic su Crea.
Crea il secondo percorso
- Fai clic su Crea percorso.
- Per il nome del percorso, inserisci
ilb-nhop-dest-10-30-1
. - Seleziona la rete
testing
. - In Intervallo IP di destinazione, inserisci
10.30.1.0/24
. 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.
Per il nome della regola di forwarding, seleziona
fr-ilb2
.Fai clic su Crea.
gcloud
Crea route avanzate con l'hop successivo impostato su ciascuna 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 tra i peer senza dover esportare la route personalizzata. Nell'esempio, il primo percorso utilizza l'indirizzo IP 10.30.1.99
, mentre il secondo utilizza il nome della regola di forwarding fr-ilb12
.
Facoltativamente, puoi specificare uno o più tag di istanza nel percorso.
La route può essere applicata a VM specifiche se specifichi i tag di rete al suo interno. Se non specifichi alcun tag di rete, la route viene applicata a tutte le VM nella rete VPC. In questo esempio, la route utilizza
il tag di rete route my-network-tag
.
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 di testing
.
gcloud
Crea il
testing-vm
eseguendo questo comando.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 di production
.
gcloud
production-vm
può trovarsi in qualsiasi zona della stessa area geografica del bilanciatore del carico
e può utilizzare qualsiasi subnet dell'area geografica. In questo esempio, production-vm
si trova nella zona us-west1-a
.
Crea il
production-vm
eseguendo questo comando.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
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
Testa la connettività dalla VM
testing
.gcloud compute ssh testing-vm --zone=us-west1-a
curl http://10.50.1.100
exit
Testa la connettività dalla VM
production
.gcloud compute ssh production-vm --zone=us-west1-a
curl http://10.30.1.100
Abilitazione 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. denominato 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 maggiori informazioni, consulta la pagina Hash simmetrico.
Elimina e ricrea le regole di forwarding
console
Elimina la regola di forwarding e creane una nuova
In Google Cloud Console, vai alla pagina Bilanciamento del carico.
Fai clic sul bilanciatore del carico
be-ilb
e poi su Modifica.Fai clic su Configurazione frontend.
Tieni il puntatore sulla regola di forwarding, quindi fai clic su
Elimina per rimuoverlo.Fai clic su Aggiungi IP e porta frontend.
Nella sezione Nuovo IP e porta frontend, apporta le seguenti modifiche:
- Nome:
FORWARDING_RULE_NAME
- Subnet:
SUBNET_NAME
- In IP interno, seleziona
IP_ADDRESS
. - Porte:
PORT_NUMBER
oALL
. - Fai clic su Fine.
- Prima di continuare, verifica che sia presente un segno di spunta blu accanto a Configurazione frontend. In caso contrario, rivedi questo passaggio.
- Nome:
Fai clic su Esamina e finalizza. Ricontrolla le impostazioni.
Fai clic su Crea.
gcloud
Elimina le regole di forwarding esistenti.
gcloud compute forwarding-rules delete FORWARDING_RULE_NAME \ --region=REGION
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 non è richiesta la SNAT
Come illustrato nell'esempio precedente, la traduzione dell'indirizzo di rete di origine (SNAT) non è necessaria se tutte le seguenti condizioni sono vere:
- 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 a partire dal 22 giugno 2021.
- Il servizio di backend TCP/UDP interno non utilizza l'impostazione di affinità sessione
NONE
.
Puoi convertire una route bilanciatore del carico TCP/UDP interno hop successivo in modo che utilizzi l'hashing simmetrico seguendo questi passaggi:
Assicurati che il servizio di backend 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 questa route sostitutiva abbia una priorità più elevata rispetto a quella esistente.
Elimina la route esistente con priorità inferiore (fai riferimento alla regola di forwarding precedente) e poi elimina la regola di forwarding precedente.
Esegui la pulizia
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
Elimina i percorsi.
gcloud compute routes delete ilb-nhop-dest-10-50-1
gcloud compute routes delete ilb-nhop-dest-10-30-1
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
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
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
Elimina il gruppo di istanze gestite.
gcloud compute instance-groups managed delete third-party-instance-group \ --region=us-west1
Elimina i modelli di istanza.
gcloud compute instance-templates delete third-party-template
gcloud compute instance-templates delete third-party-template-multinic
Eliminare 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
- Per concetti fondamentali, consulta i concetti sul bilanciamento del carico TCP/UDP interno.
- Per informazioni importanti sul failover, consulta Concetti di failover per il bilanciamento del carico TCP/UDP interno.
- Per un esempio di configurazione del bilanciatore del carico TCP/UDP interno, consulta Configurazione del bilanciamento del carico TCP/UDP interno.
- Per ulteriori informazioni sulla configurazione di Cloud Logging e Cloud Monitoring per il bilanciamento del carico TCP/UDP interno, consulta Logging e monitoraggio del carico TCP/UDP interno.
- Consulta Bilanciamento del carico TCP/UDP interno e reti connesse per informazioni sull'accesso ai bilanciatori del carico TCP/UDP interni da reti peer collegate alla tua rete VPC.
- Per informazioni su come risolvere i problemi relativi al bilanciatore del carico TCP/UDP interno, consulta la sezione Risoluzione dei problemi relativi al bilanciamento del carico TCP/UDP interno.
- Pulisci la configurazione del bilanciatore del carico.