Informazioni su 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 gli indirizzi IP. Questo processo di migrazione è chiamato Migrazione di Motion. 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. Dopo aver eseguito la migrazione di tutti i workload e le VM, puoi ritirare la sottorete di origine.

In una subnet ibrida, un router in una rete di origine e un router Cloud in una rete VPC pubblicizzano le route utilizzando il protocollo BGP (Border Gateway Protocol) (fai clic per ingrandire).

Opzioni di migrazione

Ti consigliamo di utilizzare Migrate to Virtual Machines con le sottoreti ibride per automatizzare il processo di migrazione delle VM da un'origine VMware o da un'origine Google Cloud VMware Engine.

Le sottoreti ibride non supportano Google Cloud VMware Engine come destinazione della migrazione. Se VMware Engine è la destinazione della migrazione, consigliamo di eseguire la migrazione delle VM VMware utilizzando VMware HCX. Non è necessario configurare le sottoreti ibride quando utilizzi VMware HCX per eseguire la migrazione a Google Cloud VMware Engine.

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

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

Per informazioni su come pianificare una migrazione con Migra a VM, consulta Percorso di migrazione con Migra a VM.

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

Specifiche

  • Le sottoreti ibride richiedono un prodotto di connettività di rete come Cloud VPN o Cloud Interconnect.
  • ARP proxy deve essere configurato nella rete di origine.
  • La rete di origine deve essere configurata per pubblicizzare l'intervallo di indirizzi IP della subnet ibrida.
  • L'intervallo di indirizzi IPv4 principale della subnet VPC deve corrispondere all'intervallo di indirizzi IP della subnet di origine.
  • Per configurare una subnet come subnet ibrida, devi attivare il flag allow-cidr-routes-overlap di una subnet VPC. Quando allow-cidr-routes-overlap è attivato, Google Cloud consente alle route personalizzate di sovrapporsi agli intervalli di indirizzi IP delle subnet.
  • Il flag allow-cidr-routes-overlap si applica agli intervalli di subnet IPv4 primari e secondari.
  • La connettività interna viene mantenuta tra tutte le VM e i carichi di lavoro in una sottorete ibrida.
  • Utilizzi le route annunciate personalizzate del router Cloud per annunciare in modo selettivo gli indirizzi IP delle VM durante la migrazione alla subnet VPC.
  • Durante la migrazione dei carichi di lavoro da una rete di origine a Google Cloud, aggiorna le route annunciate personalizzate del router Cloud in modo da includere gli indirizzi IP delle VM di cui è stata eseguita la migrazione.
  • Puoi connettere una subnet ibrida a una rete VPC peer utilizzando il peering di rete VPC. La configurazione del peering per la rete VPC contenente la subnet ibrida deve essere configurata per esportare le route personalizzate. La configurazione del peering per l'altra rete VPC deve essere configurata per importare le route personalizzate.

Limitazioni

  • Le reti VPC che utilizzano le subnet ibride hanno le seguenti limitazioni delle risorse:

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

  • Il router Cloud di una subnet ibrida non può superare il numero massimo di route pubblicizzate personalizzate per sessione BGP.

  • Il traffico broadcast e multicast all'interno di una sottorete ibrida non è supportato.

  • Non puoi utilizzare le connessioni Partner Interconnect di livello 3 che non supportano l'annuncio di route /32 con subnet ibride.

  • Le subnet ibride non supportano IPv6.

  • Le subnet ibride non possono ospitare carichi di lavoro agli indirizzi IP riservati nelle subnet IPv4.

  • Il forwarding in entrata di Cloud DNS non risponde alle richieste DNS provenienti dai carichi di lavoro nella rete di origine.

  • 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.

  • I carichi di lavoro nella rete di origine non possono essere endpoint per gruppi di endpoint di rete con connettività ibrida che utilizzano controlli di integrità centralizzati.

  • Le sottoreti ibride non supportano il trasferimento di dati site-to-site.

  • Non puoi collegare una subnet ibrida a un'altra subnet ibrida.

  • Le subnet ibride non rilevano i conflitti di indirizzi IP tra la rete di origine e le parti VPC di una subnet ibrida. Assicurati che ogni indirizzo IP (tranne il gateway predefinito) venga utilizzato una sola volta.

  • Le sottoreti ibride non supportano Google Cloud VMware Engine come destinazione della migrazione.

  • Le subnet ibride non supportano la migrazione delle VM da un'origine Azure o AWS.

  • Le sottoreti ibride non supportano la migrazione dei carichi di lavoro da altri provider di servizi cloud.

  • Le subnet ibride non supportano Network Connectivity Center.

Considerazioni per l'utilizzo di Hybrid Subnets

Le sezioni seguenti descrivono le considerazioni per l'utilizzo delle sottoreti ibride.

Proxy ARP e subnet ibride

Le sottoreti ibride richiedono la configurazione di ARP proxy sul dispositivo di primo hop della rete di origine. Un dispositivo di primo hop è il punto in cui un host invia per la prima volta il traffico con una destinazione esterna alla sua rete locale. L'ARP proxy consente al dispositivo di rispondere con il proprio indirizzo MAC quando riceve richieste ARP per le VM che si trovano nella parte VPC di una subnet ibrida. Il dispositivo può quindi inoltrare i pacchetti alle VM nella subnet VPC utilizzando i blocchi CIDR che ha appreso dalle route pubblicizzate personalizzate della sessione BGP (Border Gateway Protocol) sul router Cloud.

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

Per l'utilizzo di ARP proxy nella rete di origine, ti consigliamo quanto segue:

  • Rivolgiti al fornitore della tua struttura di rete di origine per conoscere 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.

Prestazioni della 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 consente a Hybrid Subnets di evitare i problemi di latenza, jitter e throughput che possono verificarsi durante le migrazioni quando alcuni carichi di lavoro esistono in una rete di origine, ma altri sono stati migrati al cloud.

In particolare, evitare il tunneling di livello 2 consente di evitare 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 sottoreti 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 destinazioni che possono essere vicine al punto di origine del traffico. Questo problema è a volte chiamato network tromboning.

L'approccio di Hybrid Subnets al routing ti consente di aspettarti un rendimento da una subnet ibrida simile o uguale a quello di una rete che non utilizza Hybrid Subnets.

Firewall e subnet ibride

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

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

Prezzi

Non è previsto alcun costo aggiuntivo per l'utilizzo delle sottoreti ibride. Tuttavia, ti vengono addebitati le risorse e il traffico di rete nella parte VPC di una subnet ibrida.

Per ulteriori informazioni, consulta Prezzi di Virtual Private Cloud.

Passaggi successivi