Informazioni sulla migrazione a Google Cloud con Hybrid Subnets

Hybrid Subnets ti aiuta a eseguire la migrazione dei carichi di lavoro da un'altra rete, la rete di origine, a una subnet Virtual Private Cloud (VPC) senza dover modificare gli indirizzi IP. Combinando una subnet nella rete di origine con una subnet VPC, crei una singola subnet logica che ti consente di eseguire la migrazione di singoli carichi di lavoro e istanze di macchine virtuali (VM) nel tempo. Una volta eseguita la migrazione di tutti i carichi di lavoro e le VM, puoi ritirare la subnet di origine.

Hybrid Subnets supporta anche la migrazione delle VM da Google Cloud a una rete on-premise o tra due reti VPC.

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, una subnet ibrida fornisce la connettività tra i carichi di lavoro in una rete di origine e una rete VPC (fai clic per ingrandire).

Specifiche

Hybrid Subnets ha le seguenti specifiche.

  • Proprietà:
    • Una subnet ibrida è una singola subnet logica che combina un segmento di una rete di origine con una subnet in una rete VPC.
    • La connettività interna viene mantenuta tra tutte le VM e i carichi di lavoro in una subnet ibrida.
    • La rete di origine può essere una rete on-premise o un'altra rete VPC. Il segmento può essere una subnet intera o una parte di una subnet.
    • Le due parti di una subnet ibrida devono essere collegate da un prodotto di connettività di rete come Cloud VPN o Cloud Interconnect.
    • L'intervallo di indirizzi IPv4 primario della subnet VPC deve corrispondere all'intervallo del segmento della rete di origine utilizzato dalla subnet ibrida.
  • Configurazione della rete VPC:
    • Devi abilitare il routing della subnet ibrida per configurare una subnet VPC come parte di una subnet ibrida. Quando il routing della subnet ibrida è abilitato, le route personalizzate possono essere in conflitto (sovrapporsi) con gli intervalli di indirizzi IPv4 primari e secondari delle subnet.
    • Utilizza le route annunciate personalizzate del router Cloud per annunciare in modo selettivo gli indirizzi IP delle VM durante la migrazione alla subnet VPC. Per supportare il proxy ARP e la corrispondenza del prefisso più lungo, queste route devono essere più specifiche (avere una subnet mask più lunga) rispetto all'intervallo di indirizzi IP della subnet ibrida. Puoi utilizzare le route /32 per le singole VM.
  • Configurazione della rete di origine:
    • Devi configurare il proxy ARP nella rete di origine.
    • Devi configurare la rete di origine per annunciare l'intervallo di indirizzi IP della subnet ibrida.
Un router Cloud e un router on-premise gestiscono il routing tra le due parti di una subnet ibrida che utilizza un intervallo di indirizzi IP condiviso e sovrapposto.
Figura 2. Questo diagramma fornisce una panoramica dei passaggi per creare una subnet ibrida e di come un router Cloud e un router on-premise instradano i pacchetti tra le due parti di una subnet ibrida (fai clic per ingrandire).

Routing della subnet ibrida

Una subnet ibrida combina una subnet in una rete di origine con una subnet VPC per creare una singola subnet logica. I carichi di lavoro in entrambe le parti della subnet ibrida mantengono la connettività interna; un carico di lavoro può inviare traffico a una destinazione in una delle due parti della subnet ibrida come se fosse locale, indipendentemente dalla posizione della destinazione.

Routing della 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,tenta di consegnare il pacchetto utilizzando la route di subnet corrispondente. Google Cloud In una subnet normale, se la destinazione non è associata a una VM in esecuzione o a una regola di forwarding interno, il pacchetto viene eliminato e tutte le altre route vengono ignorate.

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

  • Se il pacchetto è associato a un'istanza VM in esecuzione o a una regola di forwarding interno nella subnet VPC, Google Cloud consegna il pacchetto in base alla route di subnet ibrida locale.
  • Se il pacchetto non è associato a una VM in esecuzione o a una regola di forwarding interno nella subnet VPC, Google Cloud utilizza una procedura di routing speciale per le risorse non corrispondenti. Questa procedura include il controllo delle route dinamiche e statiche personalizzate che si sovrappongono all'intervallo della subnet ibrida. In una subnet ibrida configurata correttamente, i pacchetti vengono instradati alla rete di origine utilizzando una route dinamica locale che il router Cloud apprende per la subnet di origine.
In una subnet ibrida, il pacchetto A viene instradato localmente e il pacchetto B viene instradato a una destinazione on-premise.
Figura 3. Le VM in una subnet ibrida possono raggiungere le destinazioni in una subnet on-premise e in una subnet di rete VPC, anche se entrambe le subnet condividono lo stesso intervallo di indirizzi IP sovrapposti (fai clic per ingrandire).

Ad esempio, nella figura 3, il pacchetto A viene instradato a una VM nella parte VPC di una subnet ibrida 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 interno nella parte VPC della subnet ibrida, quindi Google Cloud verifica la presenza di route personalizzate in conflitto. Viene trovata una corrispondenza e Google Cloud utilizza la route dinamica personalizzata sovrapposta per consegnare il pacchetto B alla rete di origine.

Routing della rete di origine

Quando un carico di lavoro nella rete di origine invia un pacchetto a una destinazione nell'intervallo di indirizzi IP della subnet ibrida, il router della rete di origine o il dispositivo di primo hop esegue una ricerca nella tabella di routing.

Se la destinazione è associata a un carico di lavoro nella rete di origine, il router non interviene con il proxy ARP. La destinazione riceve la richiesta ARP e risponde con il proprio indirizzo MAC e il pacchetto viene consegnato localmente.

Se la destinazione si trova nella parte VPC della subnet ibrida e il router ha appreso una route dinamica per la destinazione più specifica della route di subnet locale, il router seleziona la route dinamica utilizzando la corrispondenza del prefisso più lungo. Questa azione attiva la funzionalità proxy ARP del router. Il router risponde con il proprio indirizzo MAC e instrada il pacchetto al router Cloud nella rete VPC.

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

Limitazioni

Hybrid Subnets ha le seguenti limitazioni.

  • Limitazioni delle risorse:

    Queste limitazioni delle risorse non sono applicate da Google Cloud limiti o quote. Il superamento di questi limiti potrebbe causare problemi di connettività e stabilità.

  • Traffico e route non supportati:

    • I pacchetti vengono eliminati se l'hop successivo di una route in conflitto si trova in una regione diversa dalla subnet ibrida.
    • I seguenti tipi di route non sono supportati come route in conflitto:
      • Route predefinite generate dal sistema
      • Route basate su policy
      • Route statiche con tag di rete
      • Route con destinazioni che contengono o sono più ampie della route di subnet ibrida
    • NCC non è completamente supportato con Hybrid Subnets. Puoi configurare una rete VPC contenente una subnet ibrida come spoke di un hub NCC. Tuttavia, il traffico dagli spoke connessi all'intervallo di indirizzi IP della subnet ibrida ha un comportamento di routing imprevedibile.
    • Hybrid NAT non è supportato con Hybrid Subnets. Sebbene tu possa configurare una subnet ibrida per utilizzare Hybrid NAT, la funzionalità non viene applicata al traffico interessato dal routing della subnet ibrida.
    • Il routing della subnet ibrida non si applica al traffico IPv6.
    • Il traffico di broadcast e multicast all'interno di una subnet ibrida non è supportato.
    • Non puoi utilizzare le connessioni Partner Interconnect di livello 3 che non supportano l'annuncio delle route /32 con Hybrid Subnets.
    • Il router Cloud di una subnet ibrida non può superare il numero massimo di route annunciate personalizzate per sessione BGP.
    • I carichi di lavoro nella rete di origine non possono raggiungere le API di Google e i servizi utilizzando l'accesso privato Google.
    • I carichi di lavoro nella rete di origine non possono raggiungere gli endpoint Private Service Connect per le API di Google.

  • Scenari di migrazione non supportati:

  • Altre limitazioni:

    • Hybrid Subnets non rileva i conflitti di indirizzi IP tra la rete di origine e le parti VPC di una subnet ibrida. Assicurati che ogni indirizzo IP (ad eccezione del gateway predefinito) venga utilizzato una sola volta.
    • Hybrid Subnets non può ospitare carichi di lavoro agli indirizzi IP riservati nelle subnet IPv4.
    • I carichi di lavoro nella rete di origine non possono essere endpoint per i gruppi di endpoint di rete con connettività ibrida che utilizzano controlli di integrità centralizzati.
    • Il forwarding in entrata di Cloud DNS non risponde alle richieste DNS dei carichi di lavoro nella rete di origine.

Opzioni di migrazione

Google consiglia di utilizzare Migrate to Virtual Machines con Hybrid Subnets per automatizzare la procedura 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 ulteriori informazioni sulle opzioni di migrazione, consulta Risorse di migrazione.

Per ricevere 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.

Proxy ARP e Hybrid Subnets

Hybrid Subnets richiede che proxy ARP sia configurato sul router della rete di origine o sul dispositivo di primo hop (il punto in cui un host invia per la prima volta il traffico con una destinazione al di fuori della 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 il proxy ARP nella rete di origine:

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

Limitazione regionale

Affinché una subnet ibrida funzioni correttamente, tutte le route in conflitto (route personalizzate che si sovrappongono all'intervallo di indirizzi della subnet ibrida) devono avere tutti gli hop successivi nella stessa regione della subnet ibrida.

Se una route in conflitto ha hop successivi in una regione diversa:

  • Se la route ha un mix di hop successivi locali e remoti, il traffico viene eliminato ogni volta che ECMP seleziona un hop successivo in una regione remota. Questa eliminazione dei pacchetti si verifica anche se il pacchetto corrisponde anche a una route meno specifica con hop successivi nella stessa regione.
  • Se la route non ha hop successivi nella stessa regione della subnet ibrida, il pacchetto viene eliminato.

Assicurati che le seguenti risorse si trovino nella stessa regione:

  • La subnet VPC configurata come subnet ibrida
  • Il router Cloud che apprende le route alla rete di origine
  • I tunnel VPN ad alta affidabilità o i collegamenti VLAN che forniscono la connettività ibrida

Supponiamo, ad esempio, che esista una subnet ibrida con l'intervallo di indirizzi IP 192.0.2.0/24. La subnet VPC si trova nella regione us-central1. Il router Cloud ha appreso due route in conflitto:

  • Una route personalizzata con intervallo di destinazione 192.0.2.0/25 e un hop successivo nella regione us-central1
  • Una route personalizzata 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 interno nella subnet VPC, 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 ibrida, quindi il pacchetto viene eliminato.

Per ulteriori informazioni, consulta Risorse non corrispondenti nelle subnet ibride.

Peering di rete VPC

Puoi connettere una subnet ibrida a una rete VPC peer utilizzando il peering di rete VPC. La rete VPC della subnet ibrida deve essere configurata per esportare le route di subnet e personalizzate e la rete VPC in peering deve essere configurata per importarle.

Quando la rete VPC in peering ha programmato le route, può raggiungere le destinazioni all'interno dell'intervallo di indirizzi IP della subnet ibrida, indipendentemente dal fatto che esistano in Google Cloud o nella rete di origine.

Le route non verranno programmate per la rete in peering nei seguenti casi:

  • Una route di subnet locale nella rete in peering ha un intervallo di destinazione identico a quello della route importata.
  • La quota di route dinamiche per regione per gruppo di peering è stata superata.
  • Le due reti VPC non sono in peering diretto. Il peering di rete VPC non è transitivo.

Se una di queste condizioni è vera, la subnet ibrida non funzionerà correttamente dal punto di vista della rete VPC in peering.

Prestazioni di rete

Hybrid Subnets utilizza il livello 3 del modello OSI per instradare i pacchetti tra la rete di origine e le parti VPC di una subnet ibrida. Questo approccio aiuta Hybrid Subnets a evitare problemi di latenza, jitter e velocità effettiva che possono verificarsi durante le migrazioni quando alcuni carichi di lavoro esistono in una rete di origine, ma altri carichi di lavoro 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 una sovrapposizione di livello 2 aggiuntiva. 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.

L'approccio di routing di Hybrid Subnets significa che puoi aspettarti prestazioni da una subnet ibrida simili o uguali a quelle di una rete che non utilizza Hybrid Subnets.

Firewall e Hybrid Subnets

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

Non sono necessarie considerazioni speciali per utilizzare i firewall e le regole firewall esistenti con Hybrid Subnets. Tuttavia, potrebbe essere necessario configurare le regole firewall per assicurarti che le VM possano comunicare con i carichi di lavoro nella rete di origine. Google Cloud

Prezzi

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

Passaggi successivi