Informazioni sulla migrazione a Google Cloud con Hybrid Subnets

Questa pagina descrive come utilizzare il routing di subnet ibride per eseguire la migrazione dei workload a Google Cloud.

Il routing di subnet ibride consente a una rete VPC di condividere un blocco CIDR con una rete on-premise connessa. Se un pacchetto corrisponde a una route di subnet ibrida, ma l'indirizzo IP di destinazione non è associato a una risorsa in quella subnet, Google Cloud può instradare il pacchetto alla rete on-premise utilizzando route dinamiche o statiche.

Questa configurazione ti aiuta a eseguire la migrazione dei workload in modo Google Cloud incrementale senza dover modificarne gli indirizzi IP. Durante la migrazione, i workload di cui è stata eseguita la migrazione alla rete VPC possono comunicare con quelli rimanenti nella rete on-premise utilizzando indirizzi IP interni. Dopo la migrazione di tutti i workload, puoi disattivare il routing di subnet ibride per ripristinare il normale comportamento di routing.

La migrazione a Google Cloud con Hybrid Subnets richiede tre componenti distinti che funzionano insieme:

  • Connettività: le reti on-premise e VPC devono essere connesse da un prodotto di connettività di rete come Cloud VPN o Cloud Interconnect. Hybrid Subnets non fornisce questa connettività da sola.
  • Routing di subnet ibride: devi attivare il routing di subnet ibride applicando il flag allow-cidr-routes-overlap a una risorsa subnet.
  • Strumento di migrazione: hai bisogno di uno strumento di migrazione come Migrate to Virtual Machines per eseguire la migrazione dei workload a Google Cloud.
Un diagramma in tre fasi illustra la migrazione dei workload da on-premise a Google Cloud utilizzando le Hybrid Subnets.
Figura 1. Durante la migrazione, il routing di subnet ibride consente ai workload in una rete on-premise di comunicare con i workload in una rete VPC connessa utilizzando indirizzi IP interni, anche se le subnet in entrambe le reti utilizzano lo stesso blocco CIDR (fai clic per ingrandire).

Specifiche

Per configurare Hybrid Subnets in modo che supporti la migrazione dei workload a Google Cloud da una rete on-premise, il tuo ambiente deve soddisfare i seguenti requisiti.

  • Requisiti di connettività:
  • Configurazione della rete VPC:
    • Un intervallo di indirizzi IPv4 della subnet con il routing di subnet ibride abilitato deve corrispondere a un blocco CIDR nella rete on-premise che ospita i workload di cui vuoi eseguire la migrazione. Nella maggior parte dei casi d'uso, l'intervallo di indirizzi IPv4 principale della subnet corrisponde a un blocco CIDR nella rete on-premise.
    • Devi attivare il routing di subnet ibride. Quando il routing di subnet ibride è abilitato, le regole per le interazioni tra le route di subnet e le route statiche e le regole per le interazioni tra le route di subnet e le route dinamiche non vengono applicate. Le route statiche o dinamiche locali e di peering possono esistere anche se le loro destinazioni corrispondono o rientrano nell'intervallo di indirizzi IPv4 principale della subnet o in uno dei suoi intervalli di indirizzi IPv4 secondari.
    • Devi configurare le route annunciate personalizzate del router Cloud per annunciare in modo selettivo gli indirizzi IP delle VM durante la migrazione alla rete VPC. Per supportare l'ARP proxy e la corrispondenza del prefisso più lungo, queste route annunciate personalizzate devono essere più specifiche (avere una subnet mask più lunga) rispetto all'intervallo di indirizzi IPv4 della subnet con il routing di subnet abilitato. Puoi utilizzare una route annunciata personalizzata /32 per ogni indirizzo IP di una VM di cui è stata eseguita la migrazione.
  • Configurazione della rete on-premise:
    • Devi configurare l'ARP proxy per il router on-premise.
    • Devi configurare il router on-premise per annunciare l'intervallo di indirizzi IP del blocco CIDR condiviso.
Un router Cloud e un router on-premise gestiscono il routing in un blocco CIDR condiviso tra le reti on-premise e VPC.
Figura 2. Questo diagramma riassume come configurare una rete VPC e una rete on-premise per mantenere la connettività interna su un blocco CIDR condiviso (fai clic per ingrandire).

Routing di subnet ibride

Una volta completata la configurazione descritta nelle specifiche di Hybrid Subnets, le VM in entrambe le reti possono comunicare utilizzando indirizzi IP interni.

Le sezioni seguenti descrivono il comportamento di routing nella rete VPC che contiene una subnet con il routing di subnet ibride abilitato e in una rete on-premise una volta che questa configurazione è attiva.

Routing nella rete VPC

Durante il passaggio di corrispondenza delle route di subnet del modello di routing VPC, se la destinazione di un pacchetto corrisponde a una route di subnet locale o di peering, Google Cloud tenta di recapitare il pacchetto utilizzando la route di subnet corrispondente. In una subnet normale, se la destinazione non è associata a una VM in esecuzione o a una regola di forwarding interna, il pacchetto viene eliminato e tutte le altre route vengono ignorate.

Tuttavia, se il routing di subnet ibride è abilitato per la subnet, la route di subnet diventa una route di subnet ibrida e il comportamento di routing è diverso:

  • Risorse corrispondenti: se la destinazione del pacchetto corrisponde all'interfaccia di rete di un'istanza VM in esecuzione o a una regola di forwarding interna nella subnet, Google Cloud recapita il pacchetto all'interfaccia o alla regola di forwarding. Questo comportamento è lo stesso di una subnet normale.
  • Risorse non corrispondenti: se la destinazione del pacchetto non corrisponde a una risorsa nella subnet, Google Cloud segue il processo delle risorse non corrispondenti nelle subnet ibride. Questo processo instrada i pacchetti agli hop successivi delle route statiche o dinamiche locali o di peering, purché abbiano hop successivi nella stessa regione della subnet ibrida. Le route statiche o dinamiche locali o di peering forniscono un percorso per recapitare il pacchetto alla rete on-premise.
In una subnet con il routing di subnet ibrida abilitato, il pacchetto A viene instradato localmente e il pacchetto B viene instradato a una destinazione on-premise.
Figura 3. In una subnet che utilizza il routing di subnet ibride, se la destinazione di un pacchetto corrisponde a una risorsa nella subnet, Google Cloud instrada il traffico a quella risorsa; per le risorse non corrispondenti, Google Cloud utilizza il processo delle risorse non corrispondenti nelle subnet ibride (fai clic per ingrandire).

Ad esempio, nella Figura 3, il pacchetto A viene instradato a una VM nella subnet locale utilizzando una route di subnet ibrida locale. La destinazione del pacchetto B non è associata a una VM in esecuzione o a una regola di forwarding interna in la subnet che utilizza il routing di subnet ibride, quindi Google Cloud verifica le route dinamiche o statiche che rientrano nell'intervallo di destinazione della route di subnet ibrida. Viene trovata una corrispondenza e Google Cloud utilizza la route dinamica per recapitare il pacchetto B alla rete on-premise.

Routing nella rete on-premise

Questa sezione descrive il comportamento di routing in una rete on-premise. In questo esempio, la rete on-premise è connessa a una rete VPC utilizzando tunnel Cloud VPN.

Quando una VM client nella rete on-premise invia un pacchetto a una VM server che si trova all'interno del blocco CIDR condiviso dalle due reti, il router o il dispositivo di primo hop della rete on-premise esegue una ricerca nella tabella di routing:

  • Se la VM server è associata a un indirizzo IP nella rete on-premise, il router on-premise non interviene con l'ARP proxy. La VM server risponde ai pacchetti ARP who-has dalla VM client con risposte che contengono l'indirizzo MAC del server. La VM client invia un frame Ethernet alla VM server.

  • Se la VM server non è associata a un indirizzo IP nella rete on-premise e il router on-premise ha ricevuto un annuncio di route personalizzata specifico dalle sessioni BGP del router Cloud dei tunnel Cloud VPN nella rete VPC, il router on-premise interviene con l'ARP proxy. Il router on-premise risponde ai pacchetti ARP who-has dalla VM client con risposte che contengono l'indirizzo MAC del router. La VM client invia un frame Ethernet al router on-premise, che estrae il pacchetto IP e lo inoltra a uno dei tunnel Cloud VPN. In questo modo, il pacchetto viene recapitato alla VM nella subnet con il routing di subnet ibride abilitato.

Un router on-premise utilizza ARP proxy per instradare un pacchetto da un carico di lavoro in una rete on-premise a una VM di cui è stata eseguita la migrazione a Google Cloud.
Figura 4. Un router on-premise utilizza l'ARP proxy per instradare un pacchetto da un workload nella rete on-premise a una VM di cui è stata eseguita la migrazione a Google Cloud (fai clic per ingrandire).

Limitazioni

Hybrid Subnets presenta le seguenti limitazioni.

  • Gestione degli indirizzi IP e traffico supportato:

    • IPv6: Hybrid Subnets non supporta il traffico IPv6.

    • Trasmissione e multicast: Hybrid Subnets non supporta il traffico di trasmissione e multicast.

    • Conflitti di indirizzi IP: Hybrid Subnets non rileva i conflitti di indirizzi IP tra le risorse nella rete on-premise e la rete VPC che contiene la subnet con il routing di subnet ibride abilitato. Assicurati che ogni indirizzo IP, ad eccezione del gateway predefinito, venga utilizzato una sola volta.

    • Indirizzi inutilizzabili: i primi due e gli ultimi due indirizzi IPv4 nell'intervallo di indirizzi IPv4 principale di una subnet non possono essere utilizzati da nessuna Google Cloud risorsa. Questa regola rimane in vigore anche se abiliti il routing di subnet ibride. Per saperne di più, consulta Indirizzi inutilizzabili negli intervalli di subnet IPv4.

  • Regioni non corrispondenti: i pacchetti vengono eliminati se l'hop successivo di una route statica o dinamica corrispondente all'interno dell'intervallo di destinazione della route di subnet ibrida corrispondente si trova in una regione diversa da quella della subnet. Per saperne di più, consulta Limitazione di regionalità.

  • Route statiche con tag di rete: assicurati che qualsiasi route statica corrispondente all'interno dell'intervallo di destinazione della route di subnet ibrida corrispondente non utilizzi tag di rete. Le route statiche corrispondenti che utilizzano i tag di rete comportano la perdita di pacchetti quando le frequenze dei pacchetti sono elevate.

  • Interazioni di prodotti non supportate: non utilizzare Hybrid Subnets con quanto segue.

    • Network Connectivity Center (NCC): NCC non è supportato con Hybrid Subnets. Google Cloudnon impedisce l'esportazione di subnet con il routing di subnet ibride abilitato a un hub NCC, ma questa operazione può comportare un comportamento di routing imprevedibile.

    • NEG di connettività ibrida: i sistemi di probe di controllo di integrità di Google per i controlli di integrità centralizzati non possono comunicare con gli endpoint in un NEG ibrido se gli endpoint rientrano in una route di subnet ibrida.

    • Hybrid NAT: Hybrid NAT non è supportato con Hybrid Subnets. Hybrid NAT non esegue il NAT di origine (SNAT) sui pacchetti inviati dalle VM alle destinazioni in una route statica o dinamica se viene trovata una corrispondenza con una route di subnet ibrida.

Tieni presente anche le seguenti limitazioni pratiche.

  • La rete on-premise deve supportare l'ARP proxy: Hybrid Subnets non supporta la migrazione dei workload da reti remote in altri provider di servizi cloud come Azure o AWS, perché queste reti remote non supportano l'ARP proxy.

  • La rete on-premise deve accettare gli annunci di route /32: se utilizzi Partner Interconnect di livello 3, verifica con il partner se supporta la ricezione di prefissi /32.

Opzioni di migrazione

Google consiglia di utilizzare Migrate to Virtual Machines con Hybrid Subnets per automatizzare il processo di migrazione delle VM da un' origine VMware o da un'origine Google Cloud VMware Engine.

In alternativa, puoi utilizzare strumenti di migrazione di terze parti con Hybrid Subnets, a condizione che vengano soddisfatti i requisiti di Hybrid Subnets descritti in questo documento.

Per informazioni sulla pianificazione di una migrazione con Migrate to Virtual Machines, consulta Percorso di migrazione con Migrate to VMs.

Per saperne di più sulle opzioni di migrazione, consulta Risorse di migrazione.

Per assistenza nella pianificazione di una migrazione a Google Cloud utilizzando Hybrid Subnets, invia una richiesta di assistenza.

Considerazioni sull'utilizzo di Hybrid Subnets

Le sezioni seguenti descrivono le considerazioni sull'utilizzo di Hybrid Subnets per eseguire la migrazione dei workload a Google Cloud.

ARP proxy e Hybrid Subnets

Hybrid Subnets richiede che l'ARP proxy sia configurato sul router o sul dispositivo di primo hop della rete on-premise (il punto in cui un host invia per la prima volta il traffico con una destinazione esterna alla rete locale).

Il dispositivo di primo hop può essere un router, un'appliance virtuale, un firewall o una VM che esegue una soluzione software come choparp.

Ti consigliamo di utilizzare l'ARP proxy nella rete on-premise:

  • Consulta il fornitore della struttura di rete per le best practice relative all'attivazione dell'ARP proxy e alla protezione dell'ambiente di rete.
  • Disattiva l'ARP proxy dopo aver completato la migrazione a Google Cloud.

Limitazione di regionalità

Questa limitazione si applica quando il traffico corrisponde a una route di subnet ibrida, ma l'indirizzo IP di destinazione non è associato a una VM in esecuzione o a una regola di forwarding interna. Durante il passaggio delle risorse non corrispondenti nelle subnet ibride del modello di selezione delle route di Google Cloud, le route vengono valutate come se l'origine di un pacchetto si trovasse nella stessa rete VPC della route di subnet ibrida.

Se una route statica o dinamica con un intervallo di destinazione che rientra in una route di subnet ibrida ha hop successivi in una regione diversa:

  • Se la route ha un mix di hop successivi, alcuni nella stessa regione della route di subnet ibrida e altri in altre regioni, il traffico viene eliminato ogni volta che ECMP seleziona un hop successivo in una regione diversa dalla subnet. Questa eliminazione dei pacchetti si verifica anche se il pacchetto corrisponde anche a una route meno specifica con hop successivi nella regione della subnet.
  • Se la route non ha hop successivi nella stessa regione della subnet che utilizza il routing di subnet ibride, il pacchetto viene eliminato.

Assicurati che le seguenti risorse si trovino nella stessa regione:

  • La subnet con il routing di subnet ibride abilitato
  • Il router Cloud che apprende le route alla tua rete on-premise
  • I tunnel VPN ad alta affidabilità o i collegamenti VLAN che forniscono la connettività ibrida

Supponiamo, ad esempio, che esista una subnet con l'intervallo di indirizzi IP 192.0.2.0/24 con il routing di subnet ibride abilitato. La subnet si trova nella regione us-central1. Il router Cloud ha appreso due route con intervalli di destinazione che rientrano nella route di subnet ibrida:

  • Una route dinamica con intervallo di destinazione 192.0.2.0/25 e un hop successivo nella regione us-central1
  • Una route dinamica con intervallo di destinazione 192.0.2.0/30 e un hop successivo nella regione us-west1.

Un pacchetto viene inviato alla destinazione 192.0.2.2. Questo indirizzo IP non è associato a una VM in esecuzione o a una regola di forwarding interna nella subnet locale, quindi il modello di selezione delle route seleziona la route personalizzata con la destinazione più specifica, ovvero 192.0.2.0/30. Questa route non ha un hop successivo nella regione della subnet, quindi il pacchetto viene eliminato.

Per saperne di più, consulta Risorse non corrispondenti nelle subnet ibride.

Peering di rete VPC

Puoi connettere una rete VPC contenente una subnet che utilizza il routing di subnet ibride a una rete VPC peer utilizzando il peering di rete VPC.

Il traffico dai client in una rete in peering può raggiungere le destinazioni all'interno del blocco CIDR condiviso, indipendentemente dal fatto che le destinazioni siano Google Cloud risorse o nella rete on-premise. Se un pacchetto da un client nella rete in peering ha una destinazione che corrisponde a una route di subnet ibrida di peering e la destinazione non corrisponde a una VM in esecuzione o a una regola di forwarding interna, il pacchetto può essere instradato utilizzando una route statica o dinamica nella rete VPC in peering.

Il routing tramite una route statica o dinamica nella rete VPC in peering non dipende dallo scambio di route personalizzate con la rete VPC che contiene il client. Tuttavia, quanto segue è ancora pertinente:

  • Assicurati che l'utilizzo della quota di route dinamiche per regione per gruppo di peering nella rete VPC che contiene il client sia inferiore al limite della quota.

  • Assicurati che non esistano altre route nella rete VPC del client per gli intervalli di destinazione che corrispondono alle route statiche o dinamiche nella rete in peering che rientrano nella route di subnet ibrida di peering.

Prestazioni di rete

Hybrid Subnets utilizza il livello 3 del modello OSI per instradare i pacchetti tra le reti on-premise e VPC. Questo approccio aiuta Hybrid Subnets a evitare problemi di latenza, jitter e throughput che possono verificarsi durante le migrazioni quando alcuni workload esistono in una rete on-premise, ma altri sono stati migrati al cloud.

In particolare, evitare il tunneling di livello 2 aiuta a prevenire il degrado delle prestazioni associato all'incapsulamento e alla crittografia di un overlay di livello 2 aggiuntivo. Inoltre, il routing di livello 3 consente a Hybrid Subnets di evitare un problema comune con il tunneling di livello 2, in cui il traffico viene inviato a un nodo centrale prima di raggiungere le destinazioni che possono essere vicine al punto di origine del traffico. Questo problema è talvolta chiamato network tromboning.

Poiché Hybrid Subnets utilizza questo approccio di routing, puoi aspettarti prestazioni simili o uguali a quelle di una rete che non utilizza Hybrid Subnets.

Firewall e Hybrid Subnets

Hybrid Subnets evita problemi relativi all'utilizzo dei firewall con il traffico incapsulato negli overlay di livello 2. Per il traffico di livello 2, i firewall possono ispezionare i pacchetti solo agli endpoint di overlay o oltre, a meno che non vengano adottate misure specifiche come la decrittografia trasparente o le ispezioni approfondite del traffico di overlay.

Non sono necessarie considerazioni speciali per utilizzare i firewall e le regole firewall esistenti con Hybrid Subnets. Tuttavia, devi configurare le regole firewall per assicurarti che Google Cloud le VM possano comunicare con i workload nella rete on-premise.

Prezzi

Per informazioni sui prezzi di Hybrid Subnets, consulta Prezzi di Virtual Private Cloud.

Passaggi successivi