Informazioni sulla migrazione a Google Cloud con Hybrid Subnets

Le subnet ibride ti aiutano 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 alcun indirizzo 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 workload e istanze di macchine virtuali (VM) nel tempo. Una volta eseguita la migrazione di tutti i workload e le VM, puoi ritirare la subnet di origine.

Le subnet ibride supportano 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 subnet ibride.
Figura 1. Durante la migrazione, una subnet ibrida fornisce 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 un'intera subnet o una parte di una.
    • Le due parti di una subnet ibrida devono essere connesse da un prodotto di connettività di rete come Cloud VPN o Cloud Interconnect.
    • L'intervallo di indirizzi IPv4 principale della subnet VPC deve corrispondere all'intervallo del segmento della rete di origine utilizzato dalla subnet ibrida.
  • Configurazione della rete VPC:
    • Per configurare una subnet VPC come parte di una subnet ibrida, devi abilitare il routing della subnet ibrida. Quando il routing della subnet ibrida è abilitato, le route personalizzate possono entrare in conflitto (sovrapporsi) con gli intervalli di indirizzi IPv4 primari e secondari delle subnet.
    • Utilizzi le route annunciate personalizzate del router Cloud per annunciare in modo selettivo gli indirizzi IP delle VM man mano che le esegui 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 di 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 workload in entrambe le parti della subnet ibrida mantengono la connettività interna; un workload può inviare traffico a una destinazione in una delle due parti della subnet ibrida come se fosse locale, indipendentemente dalla posizione della destinazione.

Routing di 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 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 recapita il pacchetto in base alla route della 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 di route dinamiche e statiche personalizzate che si sovrappongono all'intervallo della subnet ibrida. In una subnet ibrida configurata correttamente, i pacchetti vengono indirizzati 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 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 controlla se esistono route personalizzate in conflitto. Viene trovata una corrispondenza e Google Cloud utilizza la route dinamica personalizzata sovrapposta per inviare il pacchetto B alla rete di origine.

Routing di rete di origine

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

Se la destinazione è associata a un workload 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 della subnet locale, il router seleziona la route dinamica utilizzando la corrispondenza del prefisso più lungo. In questo modo viene attivata 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 il proxy ARP 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

Le subnet ibride presentano le seguenti limitazioni.

  • Limitazioni delle risorse:

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

  • Traffico e percorsi non supportati:

    • I pacchetti vengono ignorati se l'hop successivo di una route in conflitto si trova in una regione diversa dalla subnet ibrida.
    • I seguenti tipi di itinerario non sono supportati come itinerari 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
    • Network Connectivity Center non è completamente supportato con le subnet ibride. Puoi configurare una rete VPC contenente una subnet ibrida in modo che sia uno spoke di un hub Network Connectivity Center. Tuttavia, il traffico dagli spoke connessi all'intervallo di indirizzi IP della subnet ibrida ha un comportamento di routing imprevedibile.
    • NAT ibrido non è supportato con le subnet ibride. Anche se puoi configurare una subnet ibrida per utilizzare NAT ibrido, la funzionalità non viene applicata al traffico interessato dal routing della subnet ibrida.
    • Il routing delle subnet ibrido 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 di route /32 con subnet ibride.
    • Il router Cloud di una subnet ibrida non può superare il numero massimo di route personalizzate annunciate per sessione BGP.
    • I carichi di lavoro nella rete di origine non possono raggiungere le API e i servizi di Google utilizzando l'accesso privato Google.
    • I workload nella rete di origine non possono raggiungere gli endpoint Private Service Connect per le API di Google.

  • Scenari di migrazione non supportati:

    • Le subnet ibride non supportano la migrazione dei carichi di lavoro da altri provider di servizi cloud.
    • Le subnet ibride non supportano la migrazione di VM da un'origine Azure o AWS.
    • Le subnet ibride non supportano il trasferimento di dati da sito a sito.
    • Le subnet ibride non supportano Google Cloud VMware Engine come destinazione di migrazione. Se VMware Engine è la destinazione della migrazione, ti consigliamo di migrare le VM VMware utilizzando VMware HCX.

  • Altre limitazioni:

    • Le subnet ibride non rilevano 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.
    • Le subnet ibride non possono ospitare carichi di lavoro negli indirizzi IP riservati nelle subnet IPv4.
    • I workload 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 dai carichi di lavoro nella rete di origine.

Opzioni di migrazione

Google consiglia di utilizzare Migrate to Virtual Machines con subnet ibride per automatizzare il processo di migrazione delle VM da una sorgente VMware o da una sorgente Google Cloud VMware Engine.

In alternativa, puoi utilizzare strumenti di migrazione di terze parti con le subnet ibride, a condizione che vengano soddisfatti i requisiti delle subnet ibride descritti in questo documento.

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

Per ulteriori informazioni sulle opzioni di migrazione, consulta Risorse per la migrazione.

Per ricevere assistenza per la 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 per l'utilizzo delle subnet ibride.

Proxy ARP e subnet ibride

Le subnet ibride richiedono che proxy ARP sia configurato sul router o sul dispositivo di primo hop della rete di origine (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 quanto segue per l'utilizzo di ARP proxy nella rete di origine:

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

Limitazione delle aree geografiche

Affinché una subnet ibrida funzioni correttamente, 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. Questo pacchetto viene eliminato anche se corrisponde 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 ignorato.

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 tua rete di origine
  • I tunnel VPN ad alta disponibilità o i collegamenti VLAN che forniscono connettività ibrida

Ad esempio, supponiamo 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 ignorato.

Per saperne di più, vedi 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 subnet e le route personalizzate, mentre 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 subnet locale nella rete in peering ha un intervallo di destinazione identico a quello della route importata.
  • La quota 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 con peering.

Prestazioni di rete

Le subnet ibride utilizzano 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 su una rete di origine, ma altri sono stati migrati nel cloud.

In particolare, evitare il tunneling di livello 2 contribuisce a prevenire il peggioramento delle prestazioni associato all'incapsulamento e alla crittografia di un overlay di livello 2 aggiuntivo. Inoltre, il routing di livello 3 consente alle subnet ibride 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 tromboning di rete.

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

Firewall e subnet ibride

Le subnet ibride evitano problemi relativi all'utilizzo di firewall con traffico incapsulato in overlay di livello 2. Per il traffico di livello 2, i firewall possono ispezionare i pacchetti solo in corrispondenza o oltre gli endpoint di overlay, 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 firewall e regole firewall esistenti con le subnet ibride. Tuttavia, potrebbe essere necessario configurare le regole firewall per assicurarti che le VM Google Cloud possano comunicare con i workload nella rete di origine.

Prezzi

Non sono previsti costi aggiuntivi per l'utilizzo delle subnet ibride. Tuttavia, ti vengono addebitati i costi per le risorse e il traffico di rete nella parte VPC di una subnet ibrida.

Per maggiori informazioni, consulta la pagina Prezzi di Virtual Private Cloud.

Passaggi successivi