Panoramica del bilanciatore del carico di rete passthrough esterno basato sul servizio di backend

I bilanciatori del carico di rete passthrough esterni sono bilanciatori del carico di livello 4 regionali che distribuiscono il traffico esterno tra i backend (gruppi di istanze o gruppi di endpoint di rete (NEG)) nella stessa regione del bilanciatore del carico. Questi backend devono trovarsi nella stessa regione e nello stesso progetto, ma possono trovarsi in reti VPC diverse. Questi bilanciatori del carico sono basati su Maglev e sullo stack di virtualizzazione di rete Andromeda.

I bilanciatori del carico di rete passthrough esterni possono ricevere traffico da:

  • Qualsiasi client su internet
  • Google Cloud VM con IP esterni
  • Google Cloud VM che hanno accesso a internet tramite Cloud NAT o NAT basata su istanza

I bilanciatori del carico di rete passthrough esterni non sono proxy. Il bilanciatore del carico stesso non termina le connessioni utente. I pacchetti con bilanciamento del carico vengono inviati alle VM di backend con indirizzi IP di origine e destinazione, protocollo e, se applicabile, porte invariati. Le VM di backend terminano quindi le connessioni utente. Le risposte dalle VM di backend vanno direttamente ai client, non tornano al bilanciatore del carico. Questa procedura è nota come restituzione diretta al server (DSR).

I bilanciatori del carico di rete passthrough esterni basati sui servizi di backend supportano le seguenti funzionalità:

  • Backend di gruppi di istanze gestite e non gestite. I bilanciatori del carico di rete passthrough esterni basati sui servizi di backend supportano gruppi di istanze gestite e non gestite come backend. I gruppi di istanze gestite automatizzano alcuni aspetti della gestione del backend e offrono una scalabilità e un'affidabilità migliori rispetto ai gruppi di istanze non gestite.
  • Backend di NEG a livello di zona. I bilanciatori del carico di rete passthrough esterni basati sui servizi di backend supportano l'utilizzo di NEG di zona con endpoint GCE_VM_IP. Gli endpoint NEG GCE_VM_IP a livello di zona ti consentono di:
    • Inoltra i pacchetti a qualsiasi interfaccia di rete, non solo a nic0.
    • Inserisci lo stesso endpoint GCE_VM_IP in due o più NEG di zona connessi a servizi di backend diversi.
  • Supporto per più protocolli. I bilanciatori del carico di rete passthrough esterni basati sul servizio di backend possono bilanciare il carico del traffico TCP, UDP, ESP, GRE, ICMP e ICMPv6.
  • Supporto per la connettività IPv6. I bilanciatori del carico di rete passthrough esterni basati sui servizi di backend possono gestire il traffico IPv4 e IPv6.
  • Controllo granulare della distribuzione del traffico. Un servizio di backend consente di distribuire il traffico in base alle impostazioni di affinità sessione, al criterio di monitoraggio delle connessioni e al bilanciamento del carico ponderato configurati. Il servizio di backend può anche essere configurato per abilitare lo svuotamento della connessione e designare i backend di failover per il bilanciatore del carico. La maggior parte di queste impostazioni ha valori predefiniti che ti consentono di iniziare rapidamente. Per saperne di più, consulta Distribuzione del traffico per i bilanciatori del carico di rete passthrough esterni.
  • Supporto dei controlli di integrità regionali non legacy. I bilanciatori del carico di rete passthrough esterni basati sui servizi di backend supportano i controlli di integrità regionali, che possono utilizzare qualsiasi protocollo di controllo di integrità supportato.
  • Integrazione di Google Cloud Armor. Cloud Armor supporta la protezione DDoS di rete avanzata per i bilanciatori del carico di rete passthrough esterni. Per saperne di più, consulta Configura la protezione DDoS di rete avanzata.

  • Integrazione di GKE. Se crei applicazioni in GKE, ti consigliamo di utilizzare il controller di servizio GKE integrato, che esegue il deployment dei sistemi di bilanciamento del caricoGoogle Cloud per conto degli utenti GKE. Questa è uguale all'architettura di bilanciamento del carico autonoma descritta in questa pagina, tranne per il fatto che il suo ciclo di vita è completamente automatizzato e controllato da GKE.

    Documentazione di GKE correlata:

Architettura

Il seguente diagramma illustra i componenti di un bilanciatore del carico di rete passthrough esterno:

Bilanciatore del carico di rete passthrough esterno con un servizio di backend regionale
Bilanciatore del carico di rete passthrough esterno con un servizio di backend regionale

Il bilanciatore del carico è composto da diversi componenti di configurazione. Un singolo bilanciatore del carico può avere:

  • Uno o più indirizzi IP esterni regionali
  • Una o più regole di forwarding esterno regionali
  • Un servizio di backend esterno regionale
  • Uno o più backend: tutti i gruppi di istanze o tutti i backend NEG a livello di zona (endpoint GCE_VM_IP)
  • Controllo di integrità associato al servizio di backend

Inoltre, devi creare regole firewall che consentano al traffico di bilanciamento del carico e ai probe del controllo di integrità di raggiungere le VM di backend.

Indirizzo IP

Un bilanciatore del carico di rete passthrough esterno richiede almeno una regola di forwarding. La regola di forwarding fa riferimento a un indirizzo IP esterno regionale accessibile da qualsiasi punto di internet.

  • Per il traffico IPv4, la regola di forwarding fa riferimento a un singolo indirizzo IPv4 esterno regionale. Gli indirizzi IPv4 esterni regionali provengono da un pool univoco per ogni Google Cloud regione. L'indirizzo IPv4 può essere assegnato specificando un indirizzo IP esterno riservato o consentendo a Google Cloud di assegnare automaticamente un indirizzo IPv4 temporaneo.

  • Per il traffico IPv6, la regola di forwarding fa riferimento a un intervallo /96 di indirizzi IPv6 di una subnet dual-stack o solo IPv6. La subnet deve avere un intervallo di subnet IPv6 esterno assegnato nella rete VPC. Gli indirizzi IPv6 esterni sono disponibili solo nel livello Premium.

    L'intervallo di indirizzi IPv6 /96 può essere assegnato specificando un indirizzo IPv6 esterno riservato, specificando un indirizzo IPv6 temporaneo personalizzato o consentendo a Google Cloud di assegnare automaticamente un indirizzo IPv6 temporaneo.

    Per specificare un indirizzo IPv6 temporaneo personalizzato, devi utilizzare gcloud CLI o l'API. La console Google Cloud non supporta la specifica di indirizzi IPv6 temporanei personalizzati per le regole di forwarding.

    Per maggiori dettagli sul supporto IPv6, consulta la documentazione di VPC su Intervalli di subnet IPv6 e Indirizzi IPv6.

Utilizza un indirizzo IP riservato per la regola di forwarding se devi mantenere l'indirizzo associato al tuo progetto per il riutilizzo dopo aver eliminato una regola di forwarding o se hai bisogno che più regole di forwarding facciano riferimento allo stesso indirizzo IP.

I bilanciatori del carico di rete passthrough esterni supportano sia il livello Standard che Premium per gli indirizzi IPv4 esterni regionali. Sia l'indirizzo IP che la regola di inoltro devono utilizzare lo stesso livello di rete. Gli indirizzi IPv6 esterni regionali sono disponibili solo nel livello Premium.

Regola di forwarding

Una regola di forwarding esterno regionale specifica il protocollo e le porte su cui il bilanciatore del carico accetta il traffico. Poiché i bilanciatori del carico di rete passthrough esterni non sono proxy, trasferiscono il traffico ai backend sullo stesso protocollo e sulle stesse porte, se il pacchetto contiene informazioni sulla porta. La regola di forwarding, in combinazione con l'indirizzo IP, forma il frontend del bilanciatore del carico.

Il bilanciatore del carico conserva gli indirizzi IP di origine dei pacchetti in entrata. L'indirizzo IP di destinazione per i pacchetti in entrata è un indirizzo IP associato alla regola di forwarding del bilanciatore del carico.

Il traffico in entrata viene associato a una regola di forwarding, che è una combinazione di un indirizzo IP specifico (un indirizzo IPv4 o un intervallo di indirizzi IPv6), un protocollo e, se il protocollo è basato su porta, una o più porte, un intervallo di porte o tutte le porte. La regola di forwarding indirizza quindi il traffico al servizio di backend del bilanciatore del carico.

  • Se la regola di forwarding fa riferimento a un indirizzo IPv4, non è associata ad alcuna subnet. ovvero il suo indirizzo IP proviene dall'esterno di qualsiasi intervallo di subnetGoogle Cloud .

  • Se la regola di forwarding fa riferimento a un intervallo di indirizzi IPv6 /96, deve essere associata a una subnet e questa subnet deve essere (a) a doppio stack e (b) avere un intervallo di subnet IPv6 esterno (--ipv6-access-type impostato su EXTERNAL). La subnet a cui fa riferimento la regola di forwarding può essere la stessa utilizzata dalle istanze di backend; tuttavia, le istanze di backend possono utilizzare una subnet separata, se scelta. Quando le istanze di backend utilizzano una subnet separata, devono essere soddisfatte le seguenti condizioni:

Un bilanciatore del carico di rete passthrough esterno richiede almeno una regola di forwarding. Le regole di forwarding possono essere configurate per indirizzare il traffico proveniente da un intervallo specifico di indirizzi IP di origine a un servizio di backend (o istanza di destinazione) specifico. Per maggiori dettagli, vedi steering del traffico. Puoi definire più regole di forwarding per lo stesso bilanciatore del carico, come descritto in Più regole di forwarding.

Se vuoi che il bilanciatore del carico gestisca il traffico IPv4 e IPv6, crea due regole di forwarding: una regola per il traffico IPv4 che rimanda ai backend IPv4 (o a doppio stack) e una regola per il traffico IPv6 che rimanda solo ai backend a doppio stack. È possibile che una regola di forwarding IPv4 e una IPv6 facciano riferimento allo stesso servizio di backend, ma il servizio di backend deve fare riferimento a backend dual-stack.

Protocolli delle regole di forwarding

I bilanciatori del carico di rete passthrough esterni supportano le seguenti opzioni di protocollo per ogni regola di forwarding: TCP, UDP e L3_DEFAULT.

Utilizza le opzioni TCP e UDP per configurare il bilanciamento del carico TCP o UDP. L'opzione del protocollo L3_DEFAULT consente a un bilanciatore del carico di rete passthrough esterno di bilanciare il carico del traffico TCP, UDP, ESP, GRE, ICMP e ICMPv6.

Oltre a supportare protocolli diversi da TCP e UDP, L3_DEFAULT consente a una singola regola di forwarding di gestire più protocolli. Ad esempio, i servizi IPsec in genere gestiscono una combinazione di traffico ESP e IKE e NAT-T basato su UDP. L'opzione L3_DEFAULT consente di configurare una singola regola di forwarding per elaborare tutti questi protocolli.

Le regole di forwarding che utilizzano i protocolli TCP o UDP possono fare riferimento a un servizio di backend utilizzando lo stesso protocollo della regola di forwarding o un servizio di backend il cui protocollo è UNSPECIFIED. Le regole di forwarding L3_DEFAULT possono fare riferimento solo a un servizio di backend con protocollo UNSPECIFIED.

Se utilizzi il protocollo L3_DEFAULT, devi configurare la regola di inoltro in modo che accetti il traffico su tutte le porte. Per configurare tutte le porte, imposta --ports=ALL utilizzando Google Cloud CLI oppure imposta allPorts su True utilizzando l'API.

La seguente tabella riepiloga come utilizzare queste impostazioni per diversi protocolli.

Traffico da bilanciare Protocollo della regola di forwarding Protocollo del servizio di backend
TCP TCP TCP o UNSPECIFIED
L3_DEFAULT UNSPECIFIED
UDP UDP UDP o UNSPECIFIED
L3_DEFAULT UNSPECIFIED
ESP, GRE, ICMP/ICMPv6 (solo richiesta di echo) L3_DEFAULT UNSPECIFIED

Più regole di forwarding

Puoi configurare più regole di forwarding esterno regionali per lo stesso bilanciatore del carico di rete passthrough esterno. Ogni regola di forwarding può avere un indirizzo IP esterno regionale diverso oppure più regole di forwarding possono avere lo stesso indirizzo IP esterno regionale.

La configurazione di più regole di inoltro esterne regionali può essere utile per questi casi d'uso:

  • Devi configurare più di un indirizzo IP esterno per lo stesso servizio di backend.
  • Devi configurare protocolli diversi o porte o intervalli di porte non sovrapposti per lo stesso indirizzo IP esterno.
  • Devi indirizzare il traffico da determinati indirizzi IP di origine a backend specifici del bilanciatore del carico.

Google Cloud richiede che i pacchetti in entrata corrispondano a una sola regola di forwarding. Ad eccezione delle regole di forwarding di steering, trattate nella sezione successiva, due o più regole di forwarding che utilizzano lo stesso indirizzo IP esterno regionale devono avere combinazioni di protocollo e porta univoche in base a questi vincoli:

  • Una regola di forwarding configurata per tutte le porte di un protocollo impedisce la creazione di altre regole di forwarding che utilizzano lo stesso protocollo e lo stesso indirizzo IP. Le regole di inoltro che utilizzano i protocolli TCP o UDP possono essere configurate per utilizzare tutte le porte oppure possono essere configurate per porte specifiche. Ad esempio, se crei una regola di forwarding utilizzando l'indirizzo IP 198.51.100.1, il protocollo TCP e tutte le porte, non puoi creare altre regole di forwarding utilizzando l'indirizzo IP 198.51.100.1 e il protocollo TCP. Puoi creare due regole di forwarding, entrambe utilizzando l'indirizzo IP 198.51.100.1 e il protocollo TCP, se ognuna ha porte uniche o intervalli di porte non sovrapposti. Ad esempio, puoi creare due regole di forwarding utilizzando l'indirizzo IP 198.51.100.1 e il protocollo TCP, dove le porte di una regola di forwarding sono 80,443 e l'altra utilizza l'intervallo di porte 81-442.
  • Per ogni indirizzo IP può essere creata una sola regola di forwarding L3_DEFAULT. Questo perché il protocollo L3_DEFAULT utilizza tutte le porte per definizione. In questo contesto, il termine tutte le porte include i protocolli senza informazioni sulla porta.

  • Una singola regola di forwarding L3_DEFAULT può coesistere con altre regole di forwarding che utilizzano protocolli specifici (TCP o UDP). La regola di forwarding L3_DEFAULT può essere utilizzata come ultima risorsa quando esistono regole di forwarding che utilizzano lo stesso indirizzo IP, ma protocolli più specifici. Una regola di forwarding L3_DEFAULT elabora i pacchetti inviati al suo indirizzo IP di destinazione se e solo se l'indirizzo IP di destinazione, il protocollo e la porta di destinazione del pacchetto non corrispondono a una regola di forwarding specifica del protocollo.

    Per illustrare questo concetto, considera questi due scenari. Le regole di inoltro in entrambi gli scenari utilizzano lo stesso indirizzo IP 198.51.100.1.

    • Scenario 1. La prima regola di forwarding utilizza il protocollo L3_DEFAULT. La seconda regola di forwarding utilizza il protocollo TCP e tutte le porte. I pacchetti TCP inviati a qualsiasi porta di destinazione di 198.51.100.1 vengono elaborati dalla seconda regola di forwarding. I pacchetti che utilizzano protocolli diversi vengono elaborati dalla prima regola di forwarding.
    • Scenario 2. La prima regola di forwarding utilizza il protocollo L3_DEFAULT. La seconda regola di forwarding utilizza il protocollo TCP e la porta 8080. I pacchetti TCP inviati a 198.51.100.1:8080 vengono elaborati dalla seconda regola di forwarding. Tutti gli altri pacchetti, inclusi i pacchetti TCP inviati a porte di destinazione diverse, vengono elaborati dalla prima regola di forwarding.

Selezione della regola di forwarding

Google Cloud seleziona una o zero regole di forwarding per elaborare un pacchetto in entrata utilizzando questo processo di eliminazione, a partire dall'insieme di candidati per le regole di forwarding che corrispondono all'indirizzo IP di destinazione del pacchetto:

  • Elimina le regole di forwarding il cui protocollo non corrisponde a quello del pacchetto, ad eccezione delle regole di forwarding L3_DEFAULT. Le regole di forwarding che utilizzano il protocollo L3_DEFAULT non vengono mai eliminate in questo passaggio perché L3_DEFAULT corrisponde a tutti i protocolli. Ad esempio, se il protocollo del pacchetto è TCP, vengono eliminate solo le regole di forwarding che utilizzano il protocollo UDP.

  • Elimina le regole di forwarding la cui porta non corrisponde a quella del pacchetto. Le regole di forwarding configurate per tutte le porte non vengono mai eliminate in questo passaggio perché una regola di forwarding per tutte le porte corrisponde a qualsiasi porta.

  • Se i candidati rimanenti per le regola di forwarding includono sia regole di forwarding L3_DEFAULT sia regole di forwarding specifiche per il protocollo, elimina le regole di forwarding L3_DEFAULT. Se i candidati rimanenti per le regola di forwarding sono tutti regole di forwarding L3_DEFAULT, nessuno viene eliminato in questo passaggio.

  • A questo punto, i candidati rimanenti per le regola di forwarding rientrano in una delle seguenti categorie:

    • Rimane una sola regola di forwarding che corrisponde all'indirizzo IP di destinazione, al protocollo e alla porta del pacchetto e viene utilizzata per instradare il pacchetto.
    • Rimangono due o più regola di forwarding candidate che corrispondono all'indirizzo IP di destinazione, al protocollo e alla porta del pacchetto. Ciò significa che i candidati alla regola di forwarding rimanenti includono le regole di forwarding di reindirizzamento (descritte nella sezione successiva). Seleziona la regola di forwardingo dello steering il cui intervallo origine include il CIDR più specifico (corrispondenza del prefisso più lungo) contenente l'indirizzo IP di origine del pacchetto. Se nessuna regola di forwarding dello steering ha un intervallo di origine che include l'indirizzo IP di origine del pacchetto, seleziona la regola di forwarding principale.
    • Non sono rimasti candidati per la regola di forwarding e il pacchetto viene eliminato.

Quando utilizzi più regole di forwarding, assicurati di configurare il software in esecuzione sulle VM di backend in modo che si associ a tutti gli indirizzi IP esterni delle regola di forwarding del bilanciatore del carico.

Steering del traffico

Le regole di forwarding per i bilanciatori del carico di rete passthrough esterni possono essere configurate per indirizzare il traffico proveniente da un indirizzo IP di origine specifico o da un intervallo di indirizzi IP a un servizio di backend specifico (o a un'istanza di destinazione).

Il routing del traffico è utile per la risoluzione dei problemi e per le configurazioni avanzate. Con l'indirizzamento del traffico, puoi indirizzare determinati client a un insieme diverso di backend, a una configurazione diversa del servizio di backend o a entrambi. Ad esempio:

  • Lo steering del traffico consente di creare due regole di forwarding che indirizzano il traffico allo stesso backend (gruppo di istanze o NEG) tramite due servizi di backend. I due servizi di backend possono essere configurati con controlli di integrità diversi, affinità sessione diverse o criteri di controllo della distribuzione del traffico diversi (monitoraggio della connessione, svuotamento della connessione e failover).
  • L'indirizzamento del traffico consente di creare una regola di forwarding per reindirizzare il traffico da un servizio di backend a bassa larghezza di banda a un servizio di backend ad alta larghezza di banda. Entrambi i servizi di backend contengono lo stesso insieme di VM o endpoint di backend, ma il carico viene bilanciato con pesi diversi utilizzando il bilanciamento del carico ponderato.
  • L'indirizzamento del traffico consente di creare due regole di forwarding che indirizzano il traffico a servizi di backend diversi, con backend diversi (gruppi di istanze o NEG). Ad esempio, un backend potrebbe essere configurato utilizzando diversi tipi di macchine per elaborare meglio il traffico proveniente da determinati indirizzi IP di origine.

La distribuzione del traffico è configurata con un parametro API della regola di forwarding chiamato sourceIPRanges. Le regole di forwarding che hanno almeno un intervallo IP di origine configurato sono chiamate regole di forwarding per l'indirizzamento.

Una regola di forwarding dello steering può utilizzare il parametro sourceIPRanges per specificare un elenco separato da virgole di un massimo di 64 indirizzi IP di origine o intervalli di indirizzi IP. Puoi aggiornare questo elenco di intervalli di indirizzi IP di origine in qualsiasi momento.

Ogni regola di forwarding dello sterzo richiede la creazione di una regola di forwarding principale. Le regole di forwarding principali e di steering condividono lo stesso indirizzo IP esterno regionale, lo stesso protocollo IP e le stesse informazioni sulla porta. Tuttavia, la regola di forwarding principale non contiene informazioni sull'indirizzo IP di origine. Ad esempio:

  • Regola di forwarding principale: indirizzo IP: 198.51.100.1, protocollo IP: TCP, porte: 80
  • Regola di forwarding dello steering: indirizzo IP: 198.51.100.1, protocollo IP: TCP, porte: 80, sourceIPRanges: 203.0.113.0/24

Una regola di forwarding principale che punta a un servizio di backend può essere associata a una regola di forwarding di steering che punta a un servizio di backend o a un'istanza di destinazione.

Per una determinata regola di forwarding padre, due o più regole di forwarding per l'indirizzamento possono avere intervalli di indirizzi IP di origine e indirizzi IP sovrapposti, ma non identici. Ad esempio, una regola di forwarding di steering può avere l'intervallo IP di origine 203.0.113.0/24 e un'altra regola di forwarding di steering per lo stesso elemento principale può avere l'indirizzo IP di origine 203.0.113.0.

Prima di eliminare la regola di inoltro principale da cui dipendono, devi eliminare tutte le regole di inoltro dello sterzo.

Per scoprire come vengono elaborati i pacchetti in entrata quando vengono utilizzate le regole di forwarding di steering, consulta Selezione delle regole di forwarding.

Comportamento dell'affinità sessione in seguito a modifiche allo sterzo

Questa sezione descrive le condizioni in base alle quali l'affinità sessione potrebbe interrompersi quando vengono aggiornati gli intervalli di indirizzi IP di origine configurati per una regola di forwarding dello steering:

  • Se una connessione esistente continua a corrispondere alla stessa regola di forwarding dopo aver modificato gli intervalli IP di origine per una regola di forwarding di steering, l'affinità di sessione non viene interrotta. Se la modifica comporta la corrispondenza di una connessione esistente con unaregola di forwardingo diversa, allora:
  • L'affinità sessione viene sempre interrotta nelle seguenti circostanze:
    • La regola di forwarding appena trovata indirizza una connessione stabilita a un servizio di backend (o istanza di destinazione) che non fa riferimento alla VM di backend selezionata in precedenza.
    • La regola di forwarding appena trovata indirizza una connessione stabilita a un servizio di backend che fa riferimento alla VM di backend selezionata in precedenza, ma il servizio di backend non è configurato per mantenere le connessioni quando i backend non sono integri e la VM di backend non supera il controllo di integrità del servizio di backend.
  • L'affinità di sessione potrebbe interrompersi quando la regola di forwarding appena abbinata indirizza una connessione stabilita a un servizio di backend e il servizio di backend fa riferimento alla VM selezionata in precedenza, ma la combinazione di affinità sessione e modalità di monitoraggio della connessione del servizio di backend genera un hash di monitoraggio della connessione diverso.

Preservare l'affinità sessione in caso di modifiche allo sterzo

Questa sezione descrive come evitare di interrompere l'affinità sessione quando vengono aggiornati gli intervalli IP di origine per le regole di forwarding dello steering:

  • Regole di forwarding di steering che puntano ai servizi di backend. Se sia la regola di forwarding principale sia quella di steering puntano ai servizi di backend, devi assicurarti manualmente che le impostazioni di affinità di sessione e norme di monitoraggio delle connessioni siano identiche.Google Cloud non rifiuta automaticamente le configurazioni se non sono identiche.
  • Regole di forwarding dello sterzo che puntano alle istanze di destinazione. Una regola di forwarding principale che punta a un servizio di backend può essere associata a una regola di forwarding di steering che punta a un'istanza di destinazione. In questo caso, la regola di forwarding di steering eredita le impostazioni di affinità di sessione e policy di monitoraggio della connessione dalla regola di forwarding principale.

Per istruzioni su come configurare la distribuzione del traffico, vedi Configurare la distribuzione del traffico.

Servizio di backend regionale

Ogni bilanciatore del carico di rete passthrough esterno ha un servizio di backend regionale che definisce il comportamento del bilanciatore del carico e la modalità di distribuzione del traffico ai relativi backend. Il nome del servizio di backend è il nome del bilanciatore del carico di rete passthrough esterno mostrato nella console Google Cloud .

Ogni servizio di backend definisce i seguenti parametri di backend:

  • Protocollo. Un servizio di backend accetta il traffico sull'indirizzo IP e sulle porte (se configurate) specificati da una o più regole di forwarding esterno regionali. Il servizio di backend passa i pacchetti alle VM di backend mantenendo gli indirizzi IP di origine e di destinazione, il protocollo e, se il protocollo è basato sulla porta, le porte di origine e di destinazione.

    I servizi di backend utilizzati con i bilanciatori del carico di rete passthrough esterni supportano le seguenti opzioni di protocollo: TCP, UDP o UNSPECIFIED.

    I servizi di backend con il protocollo UNSPECIFIED possono essere utilizzati con qualsiasi regola di forwarding, indipendentemente dal protocollo della regola di forwarding. I servizi di backend con un protocollo specifico (TCP o UDP) possono essere referenziati solo da regole di forwarding con lo stesso protocollo (TCP o UDP). Le regole di forwarding con il protocollo L3_DEFAULT possono fare riferimento solo a servizi di backend con il protocollo UNSPECIFIED.

    Consulta la sezione Specifica del protocollo della regola di forwarding per una tabella con le possibili combinazioni di protocolli di regole di forwarding e servizio di backend.

  • Distribuzione del traffico. Un servizio di backend consente di distribuire il traffico in base alle impostazioni di affinità sessione, al criterio di monitoraggio delle connessioni e al bilanciamento del carico ponderato configurati. Il servizio di backend può anche essere configurato per abilitare lo svuotamento della connessione e designare i backend di failover per il bilanciatore del carico. La maggior parte di queste impostazioni ha valori predefiniti che ti consentono di iniziare rapidamente. Per saperne di più, consulta Distribuzione del traffico per i bilanciatori del carico di rete passthrough esterni.

  • Controllo di integrità. Un servizio di backend deve avere un controllo di integrità regionale associato.

  • Backend. Ogni servizio di backend opera in una singola regione e distribuisce il traffico a gruppi di istanze o NEG di zona nella stessa regione. Puoi utilizzare gruppi di istanze o NEG di zona, ma non una combinazione di entrambi, come backend per un bilanciatore del carico di rete passthrough esterno:

    • Se scegli gruppi di istanze, puoi utilizzare gruppi di istanze non gestite, gruppi di istanze gestite a livello di zona, gruppi di istanze gestite a livello di regione o una combinazione di tipi di gruppi di istanze.
    • Se scegli NEG a livello di zona, devi utilizzare NEG a livello di zona GCE_VM_IP.

    Ogni gruppo di istanze o backend NEG ha una rete VPC associata, anche se il gruppo di istanze o il NEG non è ancora stato connesso a un servizio di backend. Per ulteriori informazioni su come una rete è associata a ogni tipo di backend, consulta Backend di gruppi di istanze e interfacce di rete e Backend NEG di zona e interfacce di rete.

Gruppi di istanze

Un bilanciatore del carico di rete passthrough esterno distribuisce le connessioni tra le VM di backend contenute in gruppi di istanze gestite o non gestite. I gruppi di istanze possono essere regionali o a livello di zona.

Ogni gruppo di istanze ha una rete VPC associata, anche se non è ancora stato connesso a un servizio di backend. Per ulteriori informazioni su come una rete è associata ai gruppi di istanze, vedi Backend dei gruppi di istanze e interfacce di rete.

Il bilanciatore del carico di rete passthrough esterno è progettato per essere a disponibilità elevata. Non sono necessari passaggi speciali per rendere il bilanciatore del carico ad alta disponibilità, perché il meccanismo non si basa su un singolo dispositivo o istanza VM. Devi solo assicurarti che le istanze VM di backend siano distribuite in più zone in modo che il bilanciatore del carico possa aggirare potenziali problemi in una determinata zona.

  • Gruppi di istanze gestite a livello di regione. Utilizza i gruppi di istanze gestite regionali se puoi eseguire il deployment del software utilizzando i modelli di istanza. I gruppi di istanze gestite regionali distribuiscono automaticamente il traffico tra più zone, fornendo l'opzione migliore per evitare potenziali problemi in una determinata zona.

    Di seguito è riportato un deployment di esempio che utilizza un gruppo di istanze gestite a livello di regione. Il gruppo di istanze ha un modello di istanza che definisce il modo in cui devono essere sottoposte a provisioning le istanze e ogni gruppo esegue il deployment delle istanze in tre zone della regione us-central1.

    Bilanciatore del carico di rete passthrough esterno con un gruppo di istanze gestite regionale
    Bilanciatore del carico di rete passthrough esterno con un gruppo di istanze gestite regionale

  • Gruppi di istanze gestite o non gestite a livello di zona. Utilizza gruppi di istanze di zona in zone diverse (nella stessa regione) per proteggerti da potenziali problemi in una determinata zona.

    Di seguito è riportato un esempio di deployment che utilizza gruppi di istanze zonali. Questo bilanciatore del carico fornisce disponibilità in due zone.

    Bilanciatore del carico di rete passthrough esterno con gruppi di istanze di zona
    Bilanciatore del carico di rete passthrough esterno con gruppi di istanze di zona

NEG a livello di zona

Un bilanciatore del carico di rete passthrough esterno distribuisce le connessioni tra gli endpoint GCE_VM_IP contenuti all'interno dei gruppi di endpoint di rete zonali. Questi endpoint devono trovarsi nella stessa regione del bilanciatore del carico. Per alcuni casi d'uso consigliati per i NEG a livello di zona, consulta la panoramica sui gruppi di endpoint di rete a livello di zona.

Gli endpoint nel NEG devono essere indirizzi IPv4 interni principali delle interfacce di rete VM che si trovano nella stessa subnet e zona del NEG di zona. L'indirizzo IPv4 interno principale di qualsiasi interfaccia di rete di un'istanza VM con più NIC può essere aggiunto a un NEG, purché si trovi nella subnet del NEG.

I NEG di zona supportano sia le VM IPv4 che quelle a doppio stack (IPv4 e IPv6). Per le VM IPv4 e a doppio stack, è sufficiente specificare solo l'istanza VM quando colleghi un endpoint a un NEG. Non è necessario specificare l'indirizzo IP dell'endpoint. L'istanza VM deve sempre trovarsi nella stessa zona del NEG.

Ogni NEG di zona ha una rete VPC e una subnet associate, anche se non è ancora stato connesso a un servizio di backend. Per ulteriori informazioni su come una rete è associata ai NEG di zona, consulta Backend NEG di zona e interfacce di rete.

Backend di gruppi di istanze e interfacce di rete

All'interno di un determinato gruppo di istanze (gestito o non gestito), tutte le istanze VM devono avere le interfacce di rete nic0 nella stessa rete VPC.

  • Per i gruppi di istanze gestite (MIG), la rete VPC per il gruppo di istanze è definita nel modello di istanza.
  • Per i gruppi di istanze non gestite, la rete VPC per il gruppo di istanze è definita come la rete VPC utilizzata dall'interfaccia di rete nic0 della prima istanza VM che aggiungi al gruppo di istanze non gestite.
I servizi di backend non possono distribuire il traffico alle VM membro del gruppo di istanze su interfacce non nic0. Se vuoi ricevere traffico su un'interfaccia di rete non nic0 (vNIC o interfacce di rete dinamiche), devi utilizzare NEG di zona con endpoint GCE_VM_IP.

Backend e interfacce di rete NEG a livello di zona

Quando crei un nuovo NEG zonale con endpoint GCE_VM_IP, devi associare esplicitamente il NEG a una subnet di una rete VPC prima di poter aggiungere endpoint al NEG. Né la subnet né la rete VPC possono essere modificate dopo la creazione del NEG.

All'interno di un determinato NEG, ogni endpoint GCE_VM_IP rappresenta in realtà un'interfaccia di rete. L'interfaccia di rete deve trovarsi nella subnet associata al NEG. Dal punto di vista di un'istanza Compute Engine, l'interfaccia di rete può utilizzare qualsiasi identificatore. Dal punto di vista di un endpoint in un NEG, l'interfaccia di rete viene identificata utilizzando il suo indirizzo IPv4 interno principale.

Esistono due modi per aggiungere un endpoint GCE_VM_IP a un NEG:

  • Se specifichi solo un nome VM (senza alcun indirizzo IP) quando aggiungi un endpoint, Google Cloud richiede che la VM abbia un'interfaccia di rete nella subnet associata al NEG. L'indirizzo IP che Google Cloud sceglie per l'endpoint è l'indirizzo IPv4 interno principale dell'interfaccia di rete della VM nella subnet associata al NEG.
  • Se specifichi sia un nome VM sia un indirizzo IP quando aggiungi un endpoint, l'indirizzo IP che fornisci deve essere un indirizzo IPv4 interno principale per una delle interfacce di rete della VM. Questa interfaccia di rete deve trovarsi nella subnet associata al NEG. Tieni presente che specificare un indirizzo IP è ridondante perché può esistere una sola interfaccia di rete nella subnet associata al NEG.

Una NIC dinamica non può essere eliminata se è un endpoint di un gruppo di endpoint di rete con bilanciamento del carico.

Servizi di backend e reti VPC

Il servizio di backend non è associato ad alcuna rete VPC; tuttavia, ogni gruppo di istanza di backend o NEG di zona è associato a una rete VPC, come indicato in precedenza. Se tutti i backend si trovano nella stessa regione e nello stesso progetto e sono tutti dello stesso tipo (gruppi di istanze o NEG di zona), puoi aggiungere backend che utilizzano la stessa rete VPC o reti VPC diverse.

Per distribuire i pacchetti a un'interfaccia non nic0, devi utilizzare i backend NEG a livello di zona (con endpoint GCE_VM_IP).

Backend a doppio stack (IPv4 e IPv6)

Se vuoi che il bilanciatore del carico utilizzi backend a doppio stack che gestiscono sia il traffico IPv4 che IPv6, tieni presente i seguenti requisiti:

  • I backend devono essere configurati in subnet dual-stack che si trovano nella stessa regione della regola di forwarding IPv6 del bilanciatore del carico. Per i backend, puoi utilizzare una subnet con ipv6-access-type impostato su EXTERNAL o INTERNAL. Se ipv6-access-type della subnet di backend è impostato su INTERNAL, devi utilizzare una subnet solo IPv6 o una subnet a doppio stack diversa con ipv6-access-type impostato su EXTERNAL per la regola di forwarding esterno del bilanciatore del carico.
  • I backend devono essere configurati per essere dual-stack con stack-type impostato su IPV4_IPV6. Se ipv6-access-type della subnet di backend è impostato su EXTERNAL, devi impostare anche --ipv6-network-tier su PREMIUM. Per istruzioni, consulta Crea un template di istanza con indirizzi IPv6.

Backend solo IPv6

Se vuoi che il bilanciatore del carico utilizzi backend solo IPv6, tieni presente i seguenti requisiti:

  • Le istanze solo IPv6 sono supportate nei gruppi di istanze gestite e non gestite. Non è supportato nessun altro tipo di backend.
  • I backend devono essere configurati in subnet a doppio stack o solo IPv6 che si trovano nella stessa regione della regola di forwarding IPv6 del bilanciatore del carico. Per i backend, puoi utilizzare una subnet con ipv6-access-type impostato su INTERNAL o EXTERNAL. Se ipv6-access-type della subnet di backend è impostato su INTERNAL, devi utilizzare una subnet solo IPv6 diversa con ipv6-access-type impostato su EXTERNAL per la regola di forwarding esterno del bilanciatore del carico.
  • I backend devono essere configurati in modo da essere solo IPv6 con la VM stack-type impostata su IPV6_ONLY. Se ipv6-access-type della subnet di backend è impostato su EXTERNAL, devi impostare anche --ipv6-network-tier su PREMIUM. Per istruzioni, consulta Crea un template di istanza con indirizzi IPv6.

Tieni presente che le VM solo IPv6 possono essere create sia in subnet a doppio stack sia solo IPv6, ma le VM a doppio stack non possono essere create in subnet solo IPv6.

Controlli di integrità

Le informazioni sui controlli di integrità vengono utilizzate per determinare i backend idonei per le nuove connessioni e puoi controllare se le connessioni esistenti persistono sui backend non integri. Per saperne di più sui backend idonei, consulta Distribuzione del traffico per i bilanciatori del carico di rete passthrough esterni.

Tipo, protocollo e porta del controllo di integrità

Il servizio di backend del bilanciatore del carico deve fare riferimento a un controllo di integrità regionale, utilizzando qualsiasi protocollo e porta di controllo di integrità supportati. I dettagli del protocollo e della porta del controllo di integrità non devono corrispondere al protocollo del servizio di backend del bilanciatore del carico e alle informazioni sulla porta IP della regola di forwarding.

Poiché tutti i protocolli di controllo di integrità supportati si basano su TCP, quando utilizzi un bilanciatore del carico di rete pass-through esterno per bilanciare le connessioni e il traffico per altri protocolli, le VM di backend devono eseguire un server basato su TCP per rispondere ai probe di controllo di integrità. Ad esempio, puoi utilizzare un controllo di integrità HTTP combinato con l'esecuzione di un server HTTP su ogni VM di backend. In questo esempio, i tuoi script o software sono responsabili della configurazione del server HTTP in modo che restituisca lo stato 200 solo quando il software in ascolto delle connessioni bilanciate del carico è operativo.

Per saperne di più sui protocolli e sulle porte per il controllo di integrità supportati, consulta Protocolli, porte e categorie per il controllo di integrità e Come funzionano i controlli di integrità.

Pacchetti di controllo di integrità

Per i backend dei gruppi di istanze, i probe di controllo di integrità inviano pacchetti all'interfaccia di rete di ogni VM di backend.nic0 Per i backend NEG zonali GCE_VM_IP, i probe di controllo dell'integrità inviano pacchetti all'interfaccia di rete nella rete VPC del NEG. I pacchetti di controllo di integrità hanno le seguenti caratteristiche:

  • Indirizzo IP di origine dall'intervallo IP del probe del controllo di integrità pertinente.
  • Indirizzo IP di destinazione che corrisponde a ogni indirizzo IP di una regola di forwarding che fa riferimento al servizio di backend del bilanciatore del carico di rete passthrough esterno.
  • Porta di destinazione corrispondente al numero di porta specificato nel controllo di integrità.

Il software in esecuzione sulle VM di backend deve essere associato e ascoltare le combinazioni di indirizzo IP e porta pertinenti. Il modo più semplice per farlo è configurare il software in modo che si associ e ascolti le porte pertinenti di uno qualsiasi degli indirizzi IP della VM (0.0.0.0). Per ulteriori informazioni, consulta Destinazione dei pacchetti di probe.

Regole firewall

Poiché i bilanciatori del carico di rete passthrough esterni sono bilanciatori del carico passthrough, controlli l'accesso ai backend del bilanciatore del carico utilizzando le regole firewall Google Cloud . Devi creare regole firewall in entrata di tipo Consenti o un criterio firewall gerarchico in entrata di tipo Consenti per consentire i controlli di integrità e il traffico che stai bilanciando.

Le regole di forwarding e di ingresso consentono alle regole firewall o alle policy del firewall gerarchiche di funzionare insieme nel seguente modo: una regola di forwarding specifica i requisiti di protocollo e, se definiti, di porta che un pacchetto deve soddisfare per essere inoltrato a una VM di backend. Le regole firewall di autorizzazione in entrata controllano se i pacchetti inoltrati vengono recapitati alla VM o eliminati. Tutte le reti VPC hanno una regola firewall implicita per negare tutto il traffico in entrata che blocca i pacchetti in entrata da qualsiasi origine. La Google Cloud rete VPC predefinita include un insieme limitato di regole firewall di autorizzazione in entrata precompilate.

  • Per accettare il traffico da qualsiasi indirizzo IP su internet, devi creare una regola firewall di autorizzazione in entrata con l'intervallo di origine 0.0.0.0/0. Per consentire il traffico solo da determinati intervalli di indirizzi IP, utilizza intervalli di origine più restrittivi.

  • Come best practice per la sicurezza, le regole firewall di autorizzazione in entrata devono consentire solo i protocolli e le porte IP necessari. Limitare la configurazione del protocollo (e, se possibile, della porta) è particolarmente importante quando si utilizzano regole di forwarding il cui protocollo è impostato su L3_DEFAULT. Le regole di forwarding L3_DEFAULT inoltrano i pacchetti per tutti i protocolli IP supportati (su tutte le porte se il protocollo e il pacchetto contengono informazioni sulla porta).

  • I bilanciatori del carico di rete passthrough esterni utilizzano i controlli di integrità. Google Cloud Pertanto, devi sempre consentire il traffico proveniente dagli intervalli di indirizzi IP di controllo di integrità. Queste regole firewall di autorizzazione in entrata possono essere rese specifiche per il protocollo e le porte del controllo di integrità del bilanciatore del carico.

Indirizzi IP per i pacchetti di richiesta e di ritorno

Quando una VM di backend riceve un pacchetto con bilanciamento del carico da un client, l'origine e la destinazione del pacchetto sono le seguenti:

  • Origine: l'indirizzo IP esterno associato a una VM Google Cloud o l'indirizzo IP instradabile su internet di un sistema che si connette al bilanciatore del carico.
  • Destinazione: l'indirizzo IP della regola di forwarding del bilanciatore del carico.

Poiché il bilanciatore del carico è un bilanciatore del carico passthrough (non un proxy), i pacchetti arrivano con l'indirizzo IP di destinazione della regola di forwarding del bilanciatore del carico. Configura il software in esecuzione sulle VM di backend in modo che:

  • Ascolta (collega) l'indirizzo IP della regola di forwarding del bilanciatore del carico o qualsiasi indirizzo IP (0.0.0.0 o ::).
  • Se il protocollo della regola di forwarding del bilanciatore del carico supporta le porte: ascolta (collega) una porta inclusa nella regola di forwarding del bilanciatore del carico

I pacchetti di ritorno vengono inviati direttamente dalle VM di backend del bilanciatore del carico al client. Gli indirizzi IP di origine e di destinazione del pacchetto di ritorno dipendono dal protocollo:

  • TCP è orientato alla connessione, quindi le VM di backend devono rispondere con pacchetti i cui indirizzi IP di origine corrispondono all'indirizzo IP della regola di forwarding in modo che il client possa associare i pacchetti di risposta alla connessione TCP appropriata.
  • UDP, ESP, GRE e ICMP non prevedono connessioni. Le VM di backend possono inviare pacchetti di risposta i cui indirizzi IP di origine corrispondono all'indirizzo IP della regola di forwarding o a qualsiasi indirizzo IP esterno assegnato alla VM. In pratica, la maggior parte dei client si aspetta che la risposta provenga dallo stesso indirizzo IP a cui ha inviato i pacchetti.

La tabella seguente riepiloga le origini e le destinazioni dei pacchetti di risposta:

Tipo di traffico Origine Destinazione
TCP L'indirizzo IP della regola di forwarding del bilanciatore del carico L'origine del pacchetto di richiesta
UDP, ESP, GRE, ICMP Per la maggior parte dei casi d'uso, l'indirizzo IP della regola di forwarding del bilanciatore del carico 1 L'origine del pacchetto di richiesta.

1 Quando una VM ha un indirizzo IP esterno o quando utilizzi Cloud NAT, è anche possibile impostare l'indirizzo IP di origine del pacchetto di risposta sull'indirizzo IPv4 interno principale della NIC della VM. Google Cloud o Cloud NAT modifica l'indirizzo IP di origine del pacchetto di risposta impostandolo sull'indirizzo IPv4 esterno della NIC o su un indirizzo IPv4 esterno Cloud NAT per inviare il pacchetto di risposta all'indirizzo IP esterno del client. Il mancato utilizzo dell'indirizzo IP della regola di forwarding come origine è uno scenario avanzato perché il client riceve un pacchetto di risposta da un indirizzo IP esterno che non corrisponde all'indirizzo IP a cui ha inviato un pacchetto di richiesta.

Percorso di ritorno

I bilanciatori del carico di rete passthrough esterni utilizzano route speciali al di fuori della rete VPC per indirizzare le richieste in entrata e i probe di controllo di integrità a ogni VM di backend.

Il bilanciatore del carico conserva gli indirizzi IP di origine dei pacchetti. Le risposte delle VM di backend vanno direttamente ai client, non di nuovo tramite il bilanciatore del carico. Il termine del settore per questa operazione è restituzione diretta del server.

Connettività internet in uscita dai backend

Le istanze VM configurate come endpoint di backend di un bilanciatore del carico di rete passthrough esterno possono avviare connessioni a internet utilizzando l'indirizzo IP della regola di forwarding del bilanciatore del carico come indirizzo IP di origine della connessione in uscita.

In genere, un'istanza VM utilizza sempre il proprio indirizzo IP esterno o Cloud NAT per avviare le connessioni. Utilizzi l'indirizzo IP della regola di forwarding per avviare le connessioni dagli endpoint di backend solo in scenari speciali, ad esempio quando hai bisogno che le istanze VM originino e ricevano connessioni allo stesso indirizzo IP esterno e hai anche bisogno della ridondanza del backend fornita dal bilanciatore del carico di rete passthrough esterno per le connessioni in entrata.

I pacchetti in uscita inviati dalle VM di backend direttamente a internet non hanno limitazioni per protocolli e porte del traffico. Anche se un pacchetto in uscita utilizza l'indirizzo IP della regola di forwarding come origine, il protocollo e la porta di origine del pacchetto non devono corrispondere alla specifica di protocollo e porta della regola di forwarding. Tuttavia, i pacchetti di risposta in entrata devono corrispondere all'indirizzo IP, al protocollo e alla porta di destinazione della regola di forwarding. Per saperne di più, consulta Percorsi per i bilanciatori del carico di rete passthrough esterni e l'inoltro di protocollo esterno.

Inoltre, tutte le risposte alle connessioni in uscita della VM sono soggette al bilanciamento del carico, proprio come tutti gli altri pacchetti in entrata destinati al bilanciatore del carico. Ciò significa che le risposte potrebbero non arrivare sulla stessa VM di backend che ha avviato la connessione a internet. Se le connessioni in uscita e quelle in entrata bilanciate condividono protocolli e porte comuni, puoi provare uno dei seguenti suggerimenti:

  • Sincronizza lo stato della connessione in uscita tra le VM di backend, in modo che le connessioni possano essere gestite anche se le risposte arrivano a una VM di backend diversa da quella che ha avviato la connessione.

  • Utilizza una configurazione di failover con una singola VM principale e una singola VM di backup. Quindi, la VM di backend attiva che avvia le connessioni in uscita riceve sempre i pacchetti di risposta.

Questo percorso di connettività a internet dai backend di un bilanciatore del carico di rete passthrough esterno è il comportamento predefinito previsto in base alle regole firewall implicite di Google Cloud. Tuttavia, se hai preoccupazioni per la sicurezza riguardo al mantenimento di questo percorso aperto, puoi utilizzare regole firewall per il traffico in uscita mirato per bloccare il traffico in uscita non richiesto verso internet.

Architettura VPC condiviso

Ad eccezione dell'indirizzo IP, tutti i componenti di un bilanciatore del carico di rete passthrough esterno devono esistere nello stesso progetto. La tabella seguente riepiloga i componenti VPC condiviso per i bilanciatori del carico di rete passthrough esterni:

Indirizzo IP Regola di forwarding Componenti di backend
Un indirizzo IP esterno regionale deve essere definito nello stesso progetto del bilanciatore del carico o nel progetto host VPC condiviso. Una regola di forwarding esterno regionale deve essere definita nello stesso progetto delle istanze nel servizio di backend.

Il servizio di backend regionale deve essere definito nello stesso progetto e nella stessa regione in cui esistono i backend (gruppo di istanze o NEG zonale).

I controlli di integrità associati al servizio di backend devono essere definiti nello stesso progetto e nella stessa regione del servizio di backend.

Distribuzione del traffico

I bilanciatori del carico di rete passthrough esterni supportano una serie di opzioni di personalizzazione della distribuzione del traffico, tra cui affinità sessione, monitoraggio delle connessioni, bilanciamento del carico ponderato e failover. Per informazioni dettagliate su come i bilanciatori del carico di rete passthrough esterni distribuiscono il traffico e su come queste opzioni interagiscono tra loro, consulta Distribuzione del traffico per i bilanciatori del carico di rete passthrough esterni.

Limitazioni

  • Non puoi utilizzare la console Google Cloud per eseguire le seguenti attività:

    • Crea o modifica un bilanciatore del carico di rete passthrough esterno la cui regola di forwarding utilizza il protocollo L3_DEFAULT.
    • Crea o modifica un bilanciatore del carico di rete passthrough esterno il cui protocollo del servizio di backend è impostato su UNSPECIFIED.
    • Crea o modifica un bilanciatore del carico di rete passthrough esterno che configuri una policy di monitoraggio delle connessioni.
    • Crea o modifica l'indirizzamento del traffico basato sull'IP di origine per una regola di forwarding.

    Utilizza Google Cloud CLI o l'API REST.

  • I bilanciatori del carico di rete passthrough esterni non supportano il peering di rete VPC.

Prezzi

Per informazioni sui prezzi, consulta la pagina Prezzi.

Passaggi successivi